linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ezequiel@vanguardiasur.com.ar (Ezequiel García)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init
Date: Wed, 25 Jun 2014 11:32:46 -0300	[thread overview]
Message-ID: <20140625143246.GA743@arch.cereza> (raw)
In-Reply-To: <20140625130042.GK3705@n2100.arm.linux.org.uk>

(Ccing Guido back)

Hello Russell, Darren,

On 25 Jun 02:00 PM, Russell King - ARM Linux wrote:
> On Tue, Jun 24, 2014 at 05:04:36PM -0500, Darren Etheridge wrote:
> > On 06/17/2014 09:17 AM, Guido Mart?nez wrote:
> >> Use module_init instead of late_initcall, as is the norm for modular
> >> drivers.
> >>
> >> module_init was used until 6e8de0bd6a51fdeebd5d975c4fcc426f730b339b
> >> ("drm/tilcdc: add encoder slave (v2)") changed it to a late_initcall,
> >> but it does not explain why. Tests show it's working properly with
> >> module_init.
> >>
> >
> > If I recall, the late_initcall stuff was done to try and make sure the  
> > tda998x/i2c subsystem came up before tilcdc.

That doesn't make any sense. Using late_initcall for the tilcdc DRM
driver would make the tilcdc DRM get probed before any other regular
module_init driver, including the tda998x encoder.

> > However it didn't always  
> > work so we added commit: 39de6194131c155901f96686a063212656d80c2e to try  
> > and ensure the ordering.  This might be why changing back to module_init  
> > is fine (and I agree with your assessment from my testing).

That commit is adds a proper probe deferal mechanism in case the
i2c is not available. OMAP is special because it has its own nasty initcall
to probe the i2c busses. However, that should be fixed and then i2c would be
always probed *after* the DRM, as per the ordering in drivers/Makefile.

> 
> There's a solution to that...

A solution to *what* ?

> I have patches which convert the tda998x
> driver to also register into the component helpers as well as remaining
> as a drm slave device.  This makes it possible to transition tilcdc to
> use the component helper to solve the initialisation ordering.
> 

AFAIK, there's no issue with the initialisation ordering, except that the
DRM driver is currently probed before the TDA998x encoder and so the probe
is defered. Unless I'm missing something that's very easy to fix, you just
need to change the link order to guarantee that i2c encoders are probed
*before* the DRM drivers that require them.

I have just posted a very simple patch to fix it, but it seems Thierry wasn't
happy with it, not sure why yet [1].

[1] http://www.spinics.net/lists/dri-devel/msg61987.html
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

  parent reply	other threads:[~2014-06-25 14:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1402110128-30471-1-git-send-email-guido@vanguardiasur.com.ar>
2014-06-17 14:17 ` [PATCH/RESEND 0/9] drm: tilcdc driver fixes Guido Martínez
2014-06-17 14:17   ` [PATCH/RESEND 1/9] drm/i2c: tda998x: move drm_i2c_encoder_destroy call Guido Martínez
2014-06-24 16:38     ` Russell King - ARM Linux
2014-06-25  3:55       ` Guido Martínez
2014-06-17 14:17   ` [PATCH/RESEND 2/9] drm/tilcdc: panel: fix dangling sysfs connector node Guido Martínez
2014-06-17 14:17   ` [PATCH/RESEND 3/9] drm/tilcdc: slave: " Guido Martínez
2014-06-17 14:17   ` [PATCH/RESEND 4/9] drm/tilcdc: tfp410: " Guido Martínez
2014-06-17 14:17   ` [PATCH/RESEND 5/9] drm/tilcdc: panel: fix leak when unloading the module Guido Martínez
2014-06-17 14:17   ` [PATCH/RESEND 6/9] drm/tilcdc: fix release order on exit Guido Martínez
2014-06-17 14:17   ` [PATCH/RESEND 7/9] drm/tilcdc: fix double kfree Guido Martínez
2014-06-17 14:17   ` [PATCH/RESEND 8/9] drm/tilcdc: remove submodule destroy calls Guido Martínez
2014-06-24 22:06     ` Darren Etheridge
2014-06-25  3:53       ` Guido Martínez
2014-06-25 14:53       ` Ezequiel García
2014-06-17 14:17   ` [PATCH/RESEND 9/9] drm/tilcdc: replace late_initcall with module_init Guido Martínez
2014-06-24 22:04     ` Darren Etheridge
2014-06-25 13:00       ` Russell King - ARM Linux
2014-06-25 13:13         ` Russell King - ARM Linux
2014-06-25 14:32         ` Ezequiel García [this message]
2014-06-25 14:46           ` Russell King - ARM Linux
2014-06-25 15:48             ` Ezequiel García
2014-06-19 13:41   ` [PATCH/RESEND 0/9] drm: tilcdc driver fixes Darren Etheridge
2014-06-19 16:25     ` Guido Martínez
2014-06-24  0:26   ` Guido Martínez
2014-06-27 22:08   ` Darren Etheridge
2014-06-28 10:51     ` Rob Clark
2014-07-08 10:03       ` Daniel Vetter
2014-07-01 23:39     ` Guido Martínez
2014-07-02  2:31       ` Darren Etheridge
2014-07-02  4:08         ` Dave Airlie
2014-07-02 20:38           ` Ezequiel García
2014-07-08  1:32             ` Dave Airlie
2014-07-01 23:52   ` Guido Martínez

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=20140625143246.GA743@arch.cereza \
    --to=ezequiel@vanguardiasur.com.ar \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).