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

Hello pHilipp,

Friday, July 6, 2007, 4:35:58 PM, you wrote:

> 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,

Yes, except that what we actually doing is ensuring that GPIO/IRQ
requests for an MFD are simply never made at all before the
corresponding MFD is loaded.

> 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.

This approach would be truly generic and will work for any type of
device. Indeed, it would work on struct device, and only on that
level, and basic algorithm would be:

1. A device which has at least one non-initialized parent, cannot be
initialized itself. Such devices go into queue. (Of course, when we
speak about device initialization, it's binding to a driver; having
been initialized means it run thru driver's probe()).

2. When some device got initialized, any childs of it got "woken up"
to see if they can be initialized now.

As you see, nothing depends here on bus or driver type. It's truly
*device* dependency management framework.

> 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?

It's of course just me who likes analyze previous attempts
and forecast trends, but I vividly imagine following dialog with RMK

- We face GPIO/IRQ issues, we need flexible device
dependency management.
- Don't say silly things, GPIO/IRQ handling is platform thing. Look at
sa1111.c - I did it myself, it works great.
- Yes, but we're looking into building modular cross-device kernel,
and having unbound set of SoC drivers on platform, builtin level
doesn't scale.
- "cross-device kernel"? what's that. Just in case, you can't build
one kernel for two different machines.
- ah yes, but we're looking into changing that
- So how this all relates? If you want to add device dependency
handling, you need to describe how it is needed in the current kernel,
and likely it is not. If you want to add support for building single
kernel for few machines, its another story, and you still need to
show how it is useful for Linux kernel, not your local hacks. And in
this regard, I may assure that I'm completely out of need to build
single kernel for Mainstone and Trizeps boards, so try really hard to
find good arguments.

> [...]
>> > 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, the right solution is to let us control its initialization order.
For now, we just use semi-hacky solution of replacing platform_data
*after* it is 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.

  I doubt that kernel will ever want to track such reverse
dependencies.

> 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.

  Yes. But it's kernel, and it's all about pragmatics. So far,
there're no such machine which has "intrinsic" GPIO like UDC pullup on
i2c extender, so telling RMK that his "platform" approach doesn't
scale would return only laugh, I guess ;-).

> 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?

  Me missing that too. I really hoped that during GPIODEV/SoC drivers
discussion someone will point out how it is handled in those cases.
Noone did. So, my speculative hypothesis is that it is handled in more
or less adhoc way on the level of specific arch. For example, consider
alloc_irq_space() call which is en route to be dropped. Ok, in our
case we can do static assignment of base IRQs, but such call would be
really needed for hot-pluggable CPUs/APICs, right? Not necessarily.
Instead, we can just set that we have IRQ space for X slots of Y IRQ,
starting at some base Z. Then, a hotplugged CPU just gets such slot,
base IRQ of a slot is calculated by arch manager, and passed into
needed drivers by injection. So, it does IRQ space management on
another level, not directly on irq_desc, like alloc_irq_space() does.
And again, sorry for for speculative hypotheses - it's fun to ponder
how it can be done away from the box, but with keyboard at hands,
there're more useful things to do than dig in x86 darkness ;-)

>> >> 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

-- 
Best regards,
 Paul                            mailto:pmiscml_at_gmail.com