camus has quit [Read error: Connection reset by peer]
camus has joined #u-boot
camus has quit [Ping timeout: 268 seconds]
camus has joined #u-boot
LeSpocky has quit [Ping timeout: 245 seconds]
LeSpocky has joined #u-boot
Gravis has quit [Ping timeout: 245 seconds]
vagrantc has quit [Quit: leaving]
Xeroine has joined #u-boot
Xeroine has quit [Ping timeout: 245 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
ldevulder has joined #u-boot
crb_ has quit [*.net *.split]
bryanb has quit [*.net *.split]
foxtrot has quit [*.net *.split]
qsx has quit [*.net *.split]
xypron has quit [*.net *.split]
rburton has quit [*.net *.split]
milkylainen has quit [*.net *.split]
xypron has joined #u-boot
bryanb has joined #u-boot
qsx has joined #u-boot
rburton has joined #u-boot
southey2 has joined #u-boot
crb has joined #u-boot
southey2 is now known as foxtrot
eternalforms has quit [*.net *.split]
derRichard has quit [*.net *.split]
narmstrong has quit [*.net *.split]
kabel has quit [*.net *.split]
dgilmore has quit [*.net *.split]
marex has quit [*.net *.split]
johang_ has quit [*.net *.split]
tpw_rules has quit [*.net *.split]
eternalforms has joined #u-boot
derRichard has joined #u-boot
dgilmore has joined #u-boot
kabel has joined #u-boot
dgilmore has joined #u-boot
dgilmore has quit [Changing host]
narmstrong has joined #u-boot
tpw_rules has joined #u-boot
guillaume_g has joined #u-boot
marex has joined #u-boot
johang has joined #u-boot
guillaume has joined #u-boot
matthias_bgg has joined #u-boot
guillaume_g has quit [Ping timeout: 268 seconds]
guillaume is now known as guillaume_g
frieder has joined #u-boot
persmule has quit [Remote host closed the connection]
Xeroine has joined #u-boot
guillaume has joined #u-boot
foxtrot has quit [Remote host closed the connection]
guillaume_g has quit [Ping timeout: 255 seconds]
foxtrot has joined #u-boot
sszy has joined #u-boot
stefanro has quit [Ping timeout: 272 seconds]
stefanro has joined #u-boot
<paulbarker>
Hi folks, I'm having some difficulties writing test cases which use the sandbox spi driver
<paulbarker>
The sandbox spi flash driver is initialized using device_bind() instead of device_probe()
<paulbarker>
The device_bind() function doesn't call device_alloc_priv() and so calling dev_get_parent_priv() on the resulting device returns NULL
<paulbarker>
On real hardware where the SPI device was initialized via device tree, dev_get_parent_priv() gives me a populated struct spi_slave
<paulbarker>
Without a spi_slave object I can't query things like max_read_size, max_write_size & wordlen for the SPI bus. I want to keep my code generic so it handles both real hw and the sandbox drivers so I can't just assume values for these
<paulbarker>
Any ideas why the sandbox SPI flash driver is initialized this way? It seems very awkward
monstr has joined #u-boot
<hramrach>
actually, I am facing similar problem on real hardware - when a device is added many drivers only bind but don't probe
<hramrach>
from the discussion probe happens when u-boot considers the device 'necessary' but I have no idea how that happens oe why it happens for some drivers and not others
Xeroine has quit [Ping timeout: 245 seconds]
<hramrach>
so if it gets bound and used but not probed then it's probably a bug somewhere but I am completely at a loss how to debug DM. it's so convoluted with so many layers that I have absolutely no idea about actual execution path
<paulbarker>
hramrach: It definitely took me a couple of hours to figure out how the sandbox SPI drivers initialize
<paulbarker>
I would say that failing to allocate & initialize the device private data feels like a bug
<paulbarker>
Trying to fix that would affect lots of drivers though and would be a complex piece of work
<paulbarker>
The alternative for the SPI driver would be to move fields from `struct spi_slave` to `struct dm_spi_slave_plat` since the platform data does seem to be setup correctly in device_bind()
<paulbarker>
I would appreciate input from anyone more familiar with the u-boot device model
<paulbarker>
Ok, I spotted one thing I missed. There is a call to `device_probe(emul)` for the emulated SPI device. However, it's in sandbox_spi_xfer() and so the device isn't fully probed until a transfer occurs
<paulbarker>
There may be a simpler solution here in moving that probe call out to an appropriate initialization function
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
<marex>
hramrach: whenever user needs a service from driver that is bound and not probed, the driver gets probed
<marex>
hramrach: it's lazy probing, that's all
<hramrach>
what I don't understand is how adding an additional device makes suddenly a lot of unrelated devices not needed
<marex>
you need to be more specific than that
<hramrach>
when rk808 sysreset is added in ad607512f5757f4485968efd5bcf2c0245a8a235 regulatrs are no longer probed
<hramrach>
also no systeset devices are found in the uclass anymore although there was one before and now there should be two but there is none
<hramrach>
that is the dm uclass lists them but the sysreset walk does not find any
<marex>
macromorgan: ^
<hramrach>
sure enough dm_dump_uclass uses uclass_foreach_dev() but uclass_first_device() and uclass_next_device()
<hramrach>
it's known problem, and a revert is posted
<hramrach>
it looks like the problem is not in the driver which is very similar to other sysreset drivers but in the infra, though
<hramrach>
or it's in subtle interaction of the rk drivers and the infra which cannot be understood without understanding what's going on in the infra first
<hramrach>
*sysreset_walk uses uclass_first_device() and uclass_next_device()
Xeroine has joined #u-boot
matthias_bgg has quit [Quit: Leaving]
<marex>
hramrach: try and talk to macromorgan about the change, really
<marex>
I dunno their timezone, but give it a try
GNUtoo has quit [Remote host closed the connection]
<hramrach>
they have no idea why it broke stuff and posted a revert
<hramrach>
so yes, I can cherry-pick that revert and the regression will be fixed but the cause is not clear
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
thopiekar has quit [Ping timeout: 240 seconds]
ad__ is now known as bigendian
lucascastro has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
persmule has quit [Remote host closed the connection]
<paulbarker>
I think I've found a way around my issue - When iterating through SPI devices I can check `device_active(dev)` and if it isn't active I can call `device_probe(dev)`
<macromorgan>
marex: Something I found (to the "interaction theory") is that while testing on my rk3326 based device these issues never popped up, but for the rk3566 based devices they do.
<macromorgan>
Given the behavior I really wanted with the two patches I submitted was a "power off on plug-in" and I got that without the sysreset driver, for now until it's understood better what's going on I will just revert the patch adding the sysreset driver
<macromorgan>
I'll resubmit again today or tomorrow
persmule has joined #u-boot
frieder has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 252 seconds]
sukbeom has quit [Ping timeout: 240 seconds]
<marex>
macromorgan: can't you cooperate with hramrach and sort it out ?
<hramrach>
I have no problem with the new sysreset not getting probed - I have problem with the previously available sysreset not getting probed anymore, nor the regulatros
<hramrach>
marex: ^
<hramrach>
I don't particularly care about hte new device, the board worked OK without it
<hramrach>
what really bothers me is that adding a new device breaks *a lot* of previously working devices
astroid has quit [Ping timeout: 240 seconds]
<macromorgan>
does it have anything to do with the pmic driver being dm-pre-reloc?
<macromorgan>
I wonder if we ifdef that sysreset driver so it doesn't load during SPL?
<macromorgan>
again though for some reason (I haven't gotten into the specifics just yet) I cannot reproduce this issue on my rk3326 based device... the rk3566 device I have can reproduce it intermittently, but the branch I use deviates so far from mainline I'm not sure how useful that is...
<macromorgan>
it's mainline with about 20 patches on top to support the device I'm on, the rk3566... hopefully one day that can be mainlined too
<hramrach>
for u-boot 20 patches is normal, the question is if htey touch the area ;-)