Hi,
On 7/2/07, Paul Sokolovsky <pmiscml_at_gmail.com> wrote:
> Hello Gerhard,
>
> Monday, July 2, 2007, 9:03:51 PM, you wrote:
>
> []
> >> > Switching on Bluetooth gives me the lines:
> >> > hamcop_set_led: LED number 2, 1, 31
> >> > hamcop_set_led: LED number 2, 0, 0
> >> > The blue LED is flashing!
> >>
> >> Bluetooth LED is working just because it access hamcop in old adhoc
> >> way, that needs to be fixed once leds-hamcop is debugged.
> >>
> >> > Putting h2200 into craddle or give power to the plug I see that the
> >> > battery gets loaded but nothing happens. No LED is flashing, no dmesg
> >> > output is created in leds-hamcop.c.
> >> >
> >> > leds-hamcop.c seems not to be the problem.
> > I see that there are a lot of pr_debug statements in leds-hamcop.c but as I
> > told you yesterday, the above two lines are the only thing I got by switching
> > Bluetooth on and off. No additional lines could be found in dmesg file.
>
> Woops. I only finally "noticed":
>
> EXPORT_SYMBOL_GPL(hamcop_leds_register);
> EXPORT_SYMBOL_GPL(hamcop_leds_unregister);
>
> Anton, please remind me, why do we have such hack in all our leds
> drivers instead of
>
> module_init(hamcop_leds_register);
> module_exit(hamcop_leds_unregister);
>
> ? It's all that child devices problem, right? And it's time to solve
> it via existing child devices patterns? And note that we have two
> different methods to deal with child devices after all:
>
> 1. Making SoC driver register its subblocks per its own internal list.
Exactly. This makes most sense for all functionality internal to the mfd chip,
for example ds1wm or led devices in ASIC3 or PASIC3 chips. If certain
parts of a mfd are unused, this can be configured via plaform_data or
resources (for example no ds1wm irq resource given -> no ds1wm device
registered).
> 2. Making SoC driver register externally passed list of
> platform_devices.
>
> And let's consider when we use one or another, and if we need two of
> them. So, first take advantage that we don't need to repeat subblock
> definition for each client machine. We also handle bus_shift this way,
> but well, there's apparently nothing impossible in making it work for
> externally passed platform_device list.
>
> Second method is used when we have separate device, not really a
> part of SoC, but which still depends on some SoC-provided resource.
> As we must ensure that this resource is available before this separate
> device is used, we must postpone its registration until we sure that
> the SoC is up. And of course, in most, if not only, cases this
> resource is SoC-provided EGPIO. That's the sole purpose of this second
> method.
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?
> And here's the crucial question - should we consider SoCs
> in question a normal device or after all an unalienable part of platform,
> always available. If make the second choice, no such parent-child
> hierarchies are required, but at the same time, modular SoC drivers
> are not allowed, and when we come to building cross-device modular
> kernels (hopefully soon), all SoC drivers must be compiled in.
I believe the right way to do it is to handle them as normal devices, and
I'd really like to see the gpio/irq/driver infrastructure to somehow learn
about those resource dependencies.
> Making first choice, we need to add child devices support
> consistently for all SoC drivers, and accept the fact that the same
> device will be initialized at different times on different machines.
> And some hacks will still be required, for example for devices which
> are builtin to CPU (and thus registered in adhoc ways), but which
> depend on SoC EGPIO (example: UDC on h4000).
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.
> 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.
> So, please let's decide on this matter this time, as it keeps
> popping up again and again.
Ah, not easy :)
regards
Philipp
Received on Fri Jul 06 2007 - 06:59:19 EDT
This archive was generated by hypermail 2.2.0 : Fri Jul 06 2007 - 06:59:40 EDT