[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