From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: Change link order to load modules first
Date: Fri, 27 Jun 2014 10:54:37 -0300 [thread overview]
Message-ID: <20140627135437.GA4736@arch.cereza> (raw)
In-Reply-To: <20140627051438.GA9258@ulmo>
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
prev parent reply other threads:[~2014-06-27 13:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 1:14 [PATCH] drm: Change link order to load modules first Ezequiel Garcia
2014-06-23 14:58 ` Thierry Reding
2014-06-23 15:29 ` Ezequiel Garcia
2014-06-27 5:14 ` Thierry Reding
2014-06-27 13:54 ` Ezequiel Garcia [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140627135437.GA4736@arch.cereza \
--to=ezequiel@vanguardiasur.com.ar \
--cc=dri-devel@lists.freedesktop.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox