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: Mon, 23 Jun 2014 12:29:09 -0300 [thread overview]
Message-ID: <20140623152909.GA16870@arch.cereza> (raw)
In-Reply-To: <20140623145809.GC16725@ulmo>
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.
> 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.
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
next prev parent reply other threads:[~2014-06-23 15:29 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 [this message]
2014-06-27 5:14 ` Thierry Reding
2014-06-27 13:54 ` Ezequiel Garcia
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=20140623152909.GA16870@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