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

Ezequiel Garcia ezequiel at vanguardiasur.com.ar
Fri Jun 27 06:54:37 PDT 2014


On 27 Jun 07:14 AM, Thierry Reding wrote:
> On Mon, Jun 23, 2014 at 12:29:09PM -0300, Ezequiel Garcia wrote:
> > > 
> > > 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.
> 

Ah, OK. I understand your point now. On a second read, my commit log isn't
too clear explaining why I want to change the order.

> > > 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.
> 

That's true. However, in this particular case, I'm not worried about the
extra microseconds wasted in the defered operation, but about the unneeded
delay introduced in the DRM probe.

I know that relying in some particular order is very fragile, but I don't
agree with knowingly and even explicitly have a sub-optimal order of the
drivers.

Or maybe it's just that I dislike deferals a lot.

Anyway, thanks for feedback.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar


More information about the dri-devel mailing list