[U-Boot] (G)PIO access trends, architecture independant solutions?

[U-Boot] (G)PIO access trends, architecture independant solutions?

[Reinhard Meyer]

Hello all,

recently a patch for soft-i2c has been accepted that uses gpio_* functions.
Supposedly they are generic, but grep-ing shows that such functions
only exist in the nios2 architecture.

Every architecture seems to have their own similiar but not identical way
for gpio access. At91 even has two ways where the IMHO better way is
depreciated...

The better way IMHO is when Port and Bit are together in one parameter.

I also like the possibility of some solutions to 'request' a pin.

So, before potentially reworking the at91 solution(s), I'd like to have some
input/insight if there is a tendency towards a generalization across all
architectures?

Ideally, that could start with introducing a "gpio.h" header file outside an
architecture specific path.

Naturally, the multitude of designs of GPIO ports might make it difficult to
unify the access functions...

Reinhard

[U-Boot] (G)PIO access trends, architecture independant solutions?

[Mike Frysinger]

On Wed, Aug 11, 2010 at 6:02 PM, Reinhard Meyer wrote:
> recently a patch for soft-i2c has been accepted that uses gpio_* functions.
> Supposedly they are generic, but grep-ing shows that such functions
> only exist in the nios2 architecture.

grep harder ... other ports implement the common gpio layer

> So, before potentially reworking the at91 solution(s), I'd like to have some
> input/insight if there is a tendency towards a generalization across all
> architectures?

the Linux GPIO API is the adopted one.  use that.
-mike