Re: [PATCH] drm: Change link order to load modules first

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2135 bytes --]

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 #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel