[U-Boot] [RFC PATCH 1/3] at91: add new gpio pin macros

Andreas Bießmann
2013-10-30T18:59:08Z

Hi Jens,

On 30.10.13 18:19, Jens Scharsig wrote:
> Am 30.10.2013 11:39, schrieb Andreas Bie?mann:
>> Hi Bo,
>>
>> +Jens, he did the rewrite of the at91 gpio driver.
>>
>
>>
>> I think this is a job for gpio_is_valid() then. How is this case handled
>> in kernel?
>>
>> Here are a few things to discuss. First of all I'd like to get some
>> insights why the at91 gpio API was changed back in 2010. It was a plain
>> number before and was changed to PORT + PIN as two separate parameters.
>> Jens, could you please shed some light on this?
>>
>
> Sorry, but I don't remember me why we do this. I think, it was a
> compromise between number of changes and code size.

found it:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/74579

---8<---
Jens Scharsig wrote:
> +#endif
> +
> +#define AT91_PIN_TO_MASK(x) (1<<x)
> +#define AT91_PORTPIN(PORT, PIN) ((0x0##PORT - 9) * 32 + ((PIN) & 0x1F))
> +#define AT91_PIO_PORTA 0x0
> +#define AT91_PIO_PORTB 0x1
> +#define AT91_PIO_PORTC 0x2
> +#define AT91_PIO_PORTD 0x3
> +#define AT91_PIO_PORTE 0x4
> +

Tom.Rix at windriver.com:
Is this necessary?
You are packing arguments that you are passing to the gpio functions.
It would be better if there were seperate port, pin parameters than
combining and then uncombining.
Please change this.
--->8---

I think we should shift toward the linux kernel at91_pio API which uses
a single number for identifying the GPIO. Any complaints?

I think it would make sense to retain some PORT + MASK functions to
easily switch multiple I/O in one go. What do you think about?

Best regards

Andreas Bie?mann