[U-Boot] [PATCH v2] gpio: omap_gpio: Fix valid gpio range for AM33XX

[Lubomir Popov]

Hi Heiko, Axel,

On 21/06/13 11:44, Heiko Schocher wrote:
> Hello Lubomir,
> 
> Am 21.06.2013 09:44, schrieb Lubomir Popov:
>> One more thing that perhaps seems more reasonable in general:
>>
>> These OMAP_MAX_GPIO defines could go into the corresponding .../arch-omap*.h
>> files, where the base addresses are defined, and the number of GPIOs is
>> implicitly obvious. And we shall have no ugly #ifdefs in the GPIO driver.
> 
> This sounds good. I vote for doing it this way ...

Sure, but for things to work on the OMAP5 SoCs, the GPIO modules 7 & 8
clocks have to be enabled as well, otherwise we get a Data Abort
exception. This requires one more fix in arch/arm/cpu/armv7/omap5/hw_data.c:

		(*prcm)->cm_l4per_gpio7_clkctrl,
		(*prcm)->cm_l4per_gpio8_clkctrl,

have to be added to the clk_modules_hw_auto_essential[] array.

I'm not mentioning here that, in order to test this in U-Boot, the pads that
are intended to be used as GPIO have to be properly configured (the GPIO mux
mode selected). For me the easiest way to do this was by again defining
CONFIG_SYS_ENABLE_PADS_ALL (which is being descoped) because my board mux
file has quite a lot of pads set to GPIO in the non_essential array.

I have some additional concerns as well: on the different SoCs we have
different GPIOs that are input-only or output-only, and this is currently
not handled by the driver in any way. We have just to hope that users are
educated enough... Unfortunately my experience tells me that very few
people care to read these thousands of pages long tech docs :( .
Anyway, I guess we shall have to leave this as is for now...

I would suggest that Axel withdraws V3 and makes a V4 (and, please,
cleanly based on master branch, not incremental), where:

1. The OMAP_MAX_GPIO defines are moved to all
arch/arm/include/asm/arch-omap*/gpio.h files, and

2. The fix to arch/arm/cpu/armv7/omap5/hw_data.c is made - this
affects OMAP54XX and DRA7XX.

Or perhaps an entirely new patch subject (that is, new V1 patch), so that
no confusion happens - we have actually shifted the scope a bit with
these additional fixes. Something like

ARM: OMAP: GPIO: Fix valid range and enable usage of all GPIOs on OMAP5

Otherwise, functionally tested on a custom OMAP5430 board with some
GPIOs > 191, works OK (with all discussed fixes applied manually).
Shall give my "Tested-by:" when I apply the final version as a patch
and test again.

> 
> bye,
> Heiko
> 
Regards,
Lubo