[U-Boot-Users] "7.at91rm9200dk":(1 of 1) [PATCH][ARM] Add PIOcontrol for at91rm9200dk LEDs and Mux.

[Ulf Samuelsson <ulf@atmel.com>]

>> [PATCH][ARM] Add PIO control for at91rm9200dk LEDs and Mux.
>> 
>> Author: Ulf Samuelsson <ulf@atmel.com>
>> Date:     2007-03-27
>> 
>> Subject: "7.at91rm9200dk":(1 of  1)     [PATCH][ARM] 
>> Add PIO control for at91rm9200dk LEDs and Mux.
>> 
>> CHANGELOG:
>>     [PATCH][ARM] Add PIO control for at91rm9200dk LEDs and Mux.
>>     Introduce a new command CFG_CMD_MUX 0x8000000000000000ULL
>>
> Ulf
> Thanks for your patch. It will be useful for other at91rm9200dk
> users
> to see your post. 
> 
> However, I shall not be submitting it for inclusion in the main U-Boot tree.
> 
> Your patch removes the last remaing CFG_CMD bit for a board specific use.
> 
> Does at91rm9200dk  already use CFG_CMD_BSP and CFG_CMD_PORTIO?  
> 

The CFG_CMD_PORTIO is useful to wrap around bothe the "led" and the "mux" functions.
These commands will then also generate do_portio_in and do_portio_out functions which are x86 specific.

If CONFIG_X86 is not set, the functions does not do anything.
Most SoC's memory map this anyway so that means that you do not need port I/O.

Having commands which configures the board is however quite convenient
since you typically have to do a few writes to enable/disable board specific.

My suggestion is that I use CFG_CMD_PORTIO to build the LED/MUX
commands and then further qualify them inside with CONFIG_MUX and CONFIG_LED.

"cmd_portio.c" needs to change to ensure it is empty if CONFIG_X86 is not set.
The last fix is of course non-ARM specific so other may want to comment.

Then again, there is not a single board using CFG_CMD_PORTIO, 
so the change should be quite OK.



> Regards
> 
> Peter Pearse
> 


Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57