On Mon, Jun 23, 2014 at 12:29:09PM -0300, Ezequiel Garcia wrote: > Hi Thierry, > > Thanks for looking at this. > > On 23 Jun 04:58 PM, Thierry Reding wrote: > > On Sun, Jun 22, 2014 at 10:14:36PM -0300, Ezequiel Garcia wrote: > > > Given panels and I2C-connected encoders are required by DRM drivers, > > > we need to change the link order so these are probed first. This commit > > > moves all the i2c, panel and bridge helper drivers so they are probed > > > before the DRM drivers. > > > > No. We don't need to change the link order. > > Could you clarify why? I guess you have some case in mind where changing > the link order breaks things or makes something mis-behave. I said we don't need to change the link order because there is a better mechanism in the kernel to handle this type of situation. Saying "we need to change" makes it sound like there's a bug that needs to be fixed by changing the link order. That's not so. If link order breaks some drivers then its those drivers that are broken. > > What we need to do is make > > sure that modules deal properly with situations where their resources > > aren't available yet (i.e. EPROBE_DEFER). There are factors other than > > link order that influence probe ordering. > > > > While I understand defering is more robust, it would be systematically > defering the probe when the DRM driver needs an I2C encoder. > > Just to name one example, the tilcdc, armada and others requiring TDA998x > encoder will always defered the probe of the DRM, and then re-probe() once > the encoder is ready. > > So, unless we have a good reason not to do this, it sounds a bit silly > to me. The problem that I have with working around this issue by changing the link order is that it hides bugs in drivers. It's not like probe deferral is a very expensive operation, so I very much prefer this as a way of forcing drivers to be fixed rather than optimizing for a few microseconds of boot time. Also note that even if TDA998x is probed first that doesn't mean the probe will succeed. It could equally well be deferred. Thierry
Attachment:
pgpJBfqGfk26V.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
