dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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