Re: [PATCH 2/2] use symbolic names for spitz/pxa GPIOs (ported resend)

["eric miao" <eric.y.miao@xxxxxxxxx>]

On Thu, Jul 24, 2008 at 6:05 PM, Stanislav Brabec <utx@xxxxxxxxxx> wrote:> Dmitry Baryshkov wrote:>> eric miao wrote:>>> > The issue of not using symbolic GPIO names is a minor issue compared>> > with the problem of its still using the deprecated pxa_gpio_mode(), I>> > hope that issue can be addressed first if someone gets a spitz to test>> > out.>>>> All zaurus except tosa suffer from using deprecated calls (pxa_gpio_mode>> (), scoop_gpio_*()) I'm working on cleaning spitz, however testing is>> limited to quemu mostly (and that is good, because I can't test other>> zaurii even in quemu).>> This patch might be only a step 1 for future search and replace.>> I can test changes physically on my spitz (SL-C3200). Implementing of> akita support in qemu would not be complicated (just to emulate simple> ioexp chip instead of scoop2).>> There is another problem: read_scoop_reg does not look well. Especially> for scoop2, missing level of abstraction complicates drivers:>> For example sound drivers use "if (machine_is_borzoi() ||> machine_is_spitz())", but spitz.c has two nearly equal functions -> spitz_bl_set_intensity and akita_bl_set_intensity.>> My idea was getting rid of scoop GPIOs and mapping all of them to> generic GPIO API.>> Or at least create an additional level of abstraction, which would allow> developers to not care about scoop2 x ioexp differences. These> differences are only on GPIO programming level and the rest is> physically connected on the PCB (except unused wires).>> Generic GPIO spitz & akita map may look as following:>> GPIO   0-118 -> map to PXA registers> GPIO 119-127 -> map to SCOOP1 PA11-PA19> GPIO 128-137 -> on spitz: map to SCOOP2 PA11-PA19> GPIO 128-136 -> on akita: map to IOEXP using translation table>
This does not sound like a good idea to me. Leave GPIO 0 - 127 to PXAbuilt-in GPIO please. Otherwise you are breaking the gpio_to_irq() andirq_to_gpio() macros.
And if scoop1/scoop2/akita does not exist all together on a single board,allocating GPIOs for something that doesn't exist at run-time isn't a goodidea either.
Introducing variables recording the GPIO seems inevitable to mein this case, please reference zylonite.c, where some GPIOs areinitialized dynamically depending on the processor on it(zylonite_pxa300.c or zylonite_pxa320.c).
> The spitz<->akita translation table would allow to use one command> independently, whether it is akita or spitz and simplify the code.>> Hopefully only 5 GPIO lines on scoop2 is actually used, so it would mean> only 10 code cleanups.>> --> Best Regards / S pozdravem,>> Stanislav Brabec> software developer> ---------------------------------------------------------------------> SUSE LINUX, s. r. o.                          e-mail: sbrabec@xxxxxxx> Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747> 190 00 Praha 9                                  fax: +420 284 028 951> Czech Republic                                    http://www.suse.cz/>>


-- Cheers- eric-------------------------------------------------------------------List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernelFAQ:        http://www.arm.linux.org.uk/mailinglists/faq.phpEtiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php