Re: SoC child devices strike back, was Re: H2200 - Red charging LED is not working

On 7/6/07, Paul Sokolovsky <pmiscml_at_gmail.com> wrote:
> > Yes, that and IRQs.
> > I wonder if there is a third way to do that.
> > IRQ and GPIO resources are (and could be, respectively) requested
> > via request_irq and gpio_request. What if the IRQ/GPIO infrastructures
> > were augmented to recognize such a request for a supported but not
> > yet registered (because not internal to the CPU) IRQ or GPIO and
> > trying to initialize the corresponding mfd device?
>
> Well, not sure if this a way to go. IRQ and GPIO infrastructure
> manage IRQs and GPIOs, not devices.

You have a point. So if all GPIO/IRQ requests should do if the
corresponding mfd driver isn't loaded yet is failing, we'd indeed
need that dependency support on a lower level, or not at all.

[...]
> So, we could do following:
> 1. Add more init priorities, in the end, just make them continuous
> range. Drawback: would need to assign them manually (we could do that
> in our case, but generally it doesn't scale).

Agreed. We have very clear cut dependencies here.

> 2. Allow to just represent actual dependency information for devices,
> which is of course DAG, by allowing any device to specify its parent.
> But again, that was already discussed. And it doesn't take to be
> prophet to imagine that we won't be able to push that to mainline.
> They simply won't want to understand problem (for example, Linux-ARM
> maintainer's response is easily forecastable as that SoC drivers are
> part of platform, period).

I wouldn't know how to counter that, except I don't see how
IRQ/GPIO chips that are on i2c bus or similar would fit into
this view. If upstream is adamant that mfd IRQ and GPIO providers
are part of the platform, there is not much we can do about it,
or is there?

[...]
> > Would it still require hacks if we had a consistent GPIO API that included
> > support for external GPIOs on mfd chips? As I understand, the problem here
> > is that the CPU-internal devices are unconditionally initialized before all
> > other platform devices, currently.
>
> No, the problem is that a device can be used only after it is
> initialized. API you use for accessing it doesn't matter. And Linux
> has flat model of dependencies, when there's a "platform" which is
> implicitly present and initialized, and other devices ready to use it
> at any time. But we have extra layer between them - SoC, and
> essentially discuss if the right way is to flatten it into platform;
> keep using our adhoc dependency tracking mechanism, but now use it
> consistently, making it mandatory for any SoC driver; or teach Linux
> that world is non-flat.

Same deal, while UDC is probed, the EGPIO chip is not yet initialized.

> >> So, both approaches have drawbacks. Besides mentioned, child
> >> devices approach also apparently introduce new concept to mainline,
> >> while static SoC is not very well bound - for example, what if UDC
> >> pull-up pins are on some I2C GPIO extender? Patch it to allow adhoc
> >> initialization and make whole I2C subsystem builtin? (OTOH, child
> >> devices support for it would need patching either).
>
> > That's why I'd prefer to make the existing infrastructure more intelligent,
> > because conceptually, the CPU internal UDC is not really a "child device"
> > to the EGPIO chip, although it makes use of resources provided by it.
>
> That depends on what concept you mean and how you like terms. Let's
> drop "child", and use "dependent". Then, it must be pretty correct
> definition that one device depends on another if uses its resources,
> right? And a UDC which uses chip's EGPIO is dependent on it for the
> purpose we discuss now.

What I meant was that for example your UDC doesn't depend on a certain
mfd device, but it depends on a certain GPIO. You remember I was
confused earlier about whether resources are provided or needed resources.
I think it would be sane to have a way to distinguish between provided and
required IRQs/GPIOs (no idea about memory ranges - could a driver be
needed to actually initialize some iomem range?).
Then the driver infrastructure could be made aware that certain resources
are only available if driver x is loaded. Just in case there is really some
driver that depends on a GPIO on an i2c gpio extender, it just doesn't make
sense to me to consider the whole I2C infrastructure as part of the platform
that has to be built-in and completely initialized before anything else.

I think the problem with upstream is that currently GPIOs are not considered
resources like IRQs, and that IRQs are considered to be a platform property
that, as you said, is always available. Unfortunately I'm missing the big view -
what happens outside our little uniprocessor ARM world regarding CPU
hotplugging on multiprocessor machines? Don't they have IRQs coming
and going, too?

> >> So, please let's decide on this matter this time, as it keeps
> >> popping up again and again.
>
> > Ah, not easy :)
>
> Yes, but even more frustrating that we keep hitting this issue again
> and again, discuss it, can't decide on solution, then forget, then hit
> next time and reinvent possible solutions again ;-).

Indeed.

regards
Philipp
Received on Fri Jul 06 2007 - 09:36:02 EDT