public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: mikedunn@newsguy•com (Mike Dunn)
To: linux-arm-kernel@lists•infradead.org
Subject: gpio-pxa initcall level change and machine init breakage
Date: Fri, 26 Apr 2013 05:38:57 -0700	[thread overview]
Message-ID: <517A7561.1080606@newsguy.com> (raw)
In-Reply-To: <87ppxiz9l5.fsf@free.fr>

On 04/25/2013 12:36 PM, Robert Jarzmik wrote:
> Linus Walleij <linus.walleij@linaro•org> writes:
> 
>> On Tue, Apr 23, 2013 at 9:42 PM, Mike Dunn <mikedunn@newsguy•com> wrote:
>>
>>> On a more general note... I'm surprised that gpiolib can not run earlier, for
>>> something so low-level.
>>
>> Well I think the patch we're discussing is making it run less early, and it
>> can actually run as arch_initcall() or similar if you wish (it's up to the
>> driver).
>>
>> However that is beside the point, Haojian is still doing the right thing
>> trying to push this to driver init (==module_init) level. The reason is
>> that basically all hardware drivers should be initialized at this level
>> because the other init levels are basically for other things and driver
>> deps are just shoehorned into them.
>>
>> Instead of relying on things to be set up early one shall rely on
>> deferred probe.
> Hi Linus,
> 
> Even if that is the long term goal, and I agree with that goal, let me quote
> Documentation/gpio.txt : "However, for spinlock-safe GPIOs it's OK to use them
> before tasking is enabled, as part of early board setup.".
> 
> When gpio abstraction was written, it was assumed GPIO usage was usable in early
> platform setup code. As this was granted, we (board maintainers) coded
> accordingly.
> 
> Now this patch breaks boards. I disagree in having my board code broken without
> notice. What I would find less intrusive would be to :
>  (a) revert the patch
>  (b) inform board maintainers that they must fix their board code (for example
>  give them 1 window)
>  (c) put back the patch. Board maintainers who did not amend their board
>  code cannot say anymore they didn't know it. Board maintainers will also have
>  time to rise objections if they think they cannot change their board code
>  (which I do not believe is possible, but who knows ...)


Yes, thank you Robert.  More than a few boards were broken.  Old architectures
get no respect ;)

Some drivers may need rework, not just board support code.  For the pxa27x lcd
driver (pxafb), I am thinking that the board will have to pass a callback
function to the driver by way of platform_data, which the driver will call from
its probe function.  Advice gratefully received!


> Ah and change the Documentation too I think, if you want GPIO to be only usable
> from device initcall level.


As Linus mentioned, it depends on the driver.  There is no standard initcall
level for them.  Do 'grep initcall drivers/gpio/*.c' and you'll see the variety.
 This is a problem with the gpio abstraction that should be addressed, at least
in the documentation.  I wouldn't mind helping, but I'm pretty clueless at this
point.

Thanks,
Mike

  parent reply	other threads:[~2013-04-26 12:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-20 15:26 gpio-pxa initcall level change and machine init breakage Mike Dunn
2013-04-21  6:02 ` Haojian Zhuang
2013-04-21 22:23   ` Mike Dunn
2013-04-22  0:58     ` Haojian Zhuang
2013-04-23  7:26       ` Linus Walleij
2013-04-23  7:49         ` Haojian Zhuang
2013-04-23 19:42         ` Mike Dunn
2013-04-24 19:37           ` Linus Walleij
2013-04-25 19:36             ` Robert Jarzmik
2013-04-25 21:22               ` Linus Walleij
2013-04-26 17:48                 ` Robert Jarzmik
2013-04-26 12:38               ` Mike Dunn [this message]
2013-04-24 16:07   ` Mike Dunn

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=517A7561.1080606@newsguy.com \
    --to=mikedunn@newsguy$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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