[PATCH] uart: make *_UART_NR platform independent

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Wolfram Sang wolfram at the-dreams.de
Sat May 7 07:15:55 UTC 2011


On 07/05/11 07:21, Sylvain Munaut wrote:
> Hi,
>
>> * convert *_UART_NR to enum uart_type in uart.h
>> * make uart-functions use uart_type consistently
>>   (was uint8_t and int)
>> * map uart_type to correct uart for mtk
>> * (remove forgotten calypso-include for mtk while we are here)
>>
>> Binaries have been successfully tested with a Sciphone G2 and a Motorola C155.
>>
>> Signed-off-by: Wolfram Sang<wolfram at the-dreams.de>
>> ---
>
>
> This looks very weird to me ...

Sorry, then my descriptive text was not good enough :(

> The uart paraemeter is not a 'type', it's the index of the UART. And
> we use define so we can easily change if we use UART0 or UART1 for the
> console / sercomm.

That was what I intentionally wanted to change, because it caused 
problems for MTK.

> With your modification you have to change the order of the enum if you
> want to swap them ? (like it's required on the freerunner)

The enums should never be changed; that is the meaning of it all. The 
idea is to have consistent ids for the type of uart across the whole 
tree and have it mapped to the correct uart only in the platform 
specific uart.c just before accessing the registers. So, this is some 
kind of virtual UART_NR which gets mapped to the internal uart very 
late. Probaby they should be renamed to simply CONS_UART (instead of 
CONS_UART_NR) then.

MTK also needs them to be swapped. This is why I can't first compile 
'firmware' and then 'mtk-firmware', because lib/console.c won't get 
recompiled and will still use the non-swapped *_UART_NR. And IMO it 
should not be recompiled, thus the added layer of abstraction.

The freerunner should have the same problem, but I can't find the code 
which swaps the uarts?

> There is someclean up to be made, but IMHO that's not it at all.

Yup, found some local uart-variables. Do you mean that?

Thanks,

    Wolfram




More information about the baseband-devel mailing list