linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Ian Molton <spyro@f2s.com>
Subject: Fw: Initialisation sequencing.
Date: Wed, 2 Mar 2005 16:41:29 -0800	[thread overview]
Message-ID: <20050302164129.4e7e26e6.akpm@osdl.org> (raw)



Begin forwarded message:

Date: Wed, 02 Mar 2005 23:32:51 +0000
From: Ian Molton <spyro@f2s.com>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Initialisation sequencing.


Hi.

I have a problem. It affects both modular and non modular builds, and I 
dont see an obviously correct solution.

The problem is that I have a video chip which supports some GPIOs and an 
LCD display.

some LCD functions are controlled via the GPIOs, like backlighting.

so the driver is split into a video driver which exports three GPIO 
related functions, and a backlight driver which requires them to work. 
Both are on the platform bus.

the problem occurs when the backlight driver gets probed before the 
video driver. it tries to access the GPIO functions, which try to write 
to random locations as the memory hasnt been ioremap()ed by the as yet 
unprobed video driver, and it all predictably falls over in a gibbering 
heap.

I cant spin at this point without deadlocking the video driver and 
ending up never being able to call the gpio functions, for obvious reasons.

I've tried making the backlight driver a child of the video driver, 
hoping the probe functions are called in 'bus order', ie. parents first. 
This failed.

I could make the backlight driver initialise late, but that seems like a 
hack. scheduling work risks deadlock.

what is the correct solution? does one exist?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

             reply	other threads:[~2005-03-03  0:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-03  0:41 Andrew Morton [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-03-03  6:38 Fw: Initialisation sequencing Antonino A. Daplas
2005-03-03  9:18 ` Ian Molton
2005-03-03 20:07   ` Antonino A. Daplas
2005-03-04  0:03     ` Ian Molton
2005-03-04  0:45       ` Antonino A. Daplas

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=20050302164129.4e7e26e6.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=spyro@f2s.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;
as well as URLs for NNTP newsgroup(s).