LPC313x support - how to do it right?

LPC313x support - how to do it right?

[Zoltan Gyarmati]

Hi,


in the last days i managed to rework and split up to more or less 
logical units the patch provided by NXP (see here: 
http://ics.nxp.com/support/software/lpc313x.bsp.linux/) for the LPC313x 
platform to work with linux 3.7. Hence the original patch was against 
2.6.33,  it doesn't have any device tree bindings, and anyway needs a 
lot of cleanup, but at this point it works. I'm willing to add the 
LPC313x support to the mainline kernel (well, if the community doesn't 
advice against:), but i'm not totally sure about the workflow i'm 
supposed to follow, so here are my first questions (which probably will 
be followed by others later on):

1. Do i think right that to get it into the mainline, it needs to 
support device trees?

2. If so (and i think yes), is there any tutorial regarding to the 
porting old machine support code and drivers to use device trees? (i 
checked the kernel documentation and some other machine support code, so 
i have some idea, but there are lot of unclear details of course...)

3. Regarding to the drivers, my biggest concern is the serial driver: 
the hw is close to the traditional 8250, but the NXP driver uses DMA 
access to handle it, which results a lot of changes in the 
drivers/tty/serial/8250/8250.c (see in the linked kernel tree below). 
What is the best strategy to follow in such a case? Adding this 
modifications to the original 8250 and define config macros to handle 
the differences(which will be kinda messy...), or create separated 
driver code (which will duplicate some code from the original 8250 
driver...)


The patchset is available in this Gitorious repo:
https://gitorious.org/linux-3-7-gnublin/linux-3-7-gnublin/commits/gnublin-support
in the gnublin-support branch.
Currently it provides support for the serial port, the i2c bus, usb host 
and gadget, and mmc.

Thx in advance

-- 
br,
Zoltan Gyarmati
mail: mr.zoltan.gyarmati at gmail.com
freenode nick: zgyarmati

LPC313x support - how to do it right?

[Thomas Petazzoni]

Dear Zoltan Gyarmati,

On Tue, 05 Feb 2013 23:08:44 +0100, Zoltan Gyarmati wrote:

> in the last days i managed to rework and split up to more or less 
> logical units the patch provided by NXP (see here: 
> http://ics.nxp.com/support/software/lpc313x.bsp.linux/) for the
> LPC313x platform to work with linux 3.7. Hence the original patch was
> against 2.6.33,  it doesn't have any device tree bindings, and anyway
> needs a lot of cleanup, but at this point it works. I'm willing to
> add the LPC313x support to the mainline kernel (well, if the
> community doesn't advice against:), but i'm not totally sure about
> the workflow i'm supposed to follow, so here are my first questions
> (which probably will be followed by others later on):
> 
> 1. Do i think right that to get it into the mainline, it needs to 
> support device trees?

Yes. No new ARM sub-architecture is accepted if it doesn't use the
Device Tree.

> 2. If so (and i think yes), is there any tutorial regarding to the 
> porting old machine support code and drivers to use device trees? (i 
> checked the kernel documentation and some other machine support code,
> so i have some idea, but there are lot of unclear details of
> course...)

No real tutorial, but you can look at the slides of my presentation at
http://elinux.org/images/a/ad/Arm-soc-checklist.pdf.

> 3. Regarding to the drivers, my biggest concern is the serial driver: 
> the hw is close to the traditional 8250, but the NXP driver uses DMA 
> access to handle it, which results a lot of changes in the 
> drivers/tty/serial/8250/8250.c (see in the linked kernel tree below). 
> What is the best strategy to follow in such a case? Adding this 
> modifications to the original 8250 and define config macros to handle 
> the differences(which will be kinda messy...), or create separated 
> driver code (which will duplicate some code from the original 8250 
> driver...)

Hard to say without looking in details at the changes involved.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

LPC313x support - how to do it right?

[Zoltan Gyarmati]

Hallo Thomas,
On 02/12/2013 12:50 PM, Thomas Petazzoni wrote:
> Dear Zoltan Gyarmati,
>
> On Tue, 05 Feb 2013 23:08:44 +0100, Zoltan Gyarmati wrote:
>
>> in the last days i managed to rework and split up to more or less
>> logical units the patch provided by NXP (see here:
>> http://ics.nxp.com/support/software/lpc313x.bsp.linux/) for the
>> LPC313x platform to work with linux 3.7. Hence the original patch was
>> against 2.6.33,  it doesn't have any device tree bindings, and anyway
>> needs a lot of cleanup, but at this point it works. I'm willing to
>> add the LPC313x support to the mainline kernel (well, if the
>> community doesn't advice against:), but i'm not totally sure about
>> the workflow i'm supposed to follow, so here are my first questions
>> (which probably will be followed by others later on):
>>
>> 1. Do i think right that to get it into the mainline, it needs to
>> support device trees?
> Yes. No new ARM sub-architecture is accepted if it doesn't use the
> Device Tree.
>
>> 2. If so (and i think yes), is there any tutorial regarding to the
>> porting old machine support code and drivers to use device trees? (i
>> checked the kernel documentation and some other machine support code,
>> so i have some idea, but there are lot of unclear details of
>> course...)
> No real tutorial, but you can look at the slides of my presentation at
> http://elinux.org/images/a/ad/Arm-soc-checklist.pdf.
Hah, pity i didn't find it earlier, seems to be really useful, thx.
>
>> 3. Regarding to the drivers, my biggest concern is the serial driver:
>> the hw is close to the traditional 8250, but the NXP driver uses DMA
>> access to handle it, which results a lot of changes in the
>> drivers/tty/serial/8250/8250.c (see in the linked kernel tree below).
>> What is the best strategy to follow in such a case? Adding this
>> modifications to the original 8250 and define config macros to handle
>> the differences(which will be kinda messy...), or create separated
>> driver code (which will duplicate some code from the original 8250
>> driver...)
> Hard to say without looking in details at the changes involved.

Unfortunately in the linked kernel tree the serial port changes in the 
same commit as the machine support, so it's a bit chaotic
(here: 
https://gitorious.org/linux-3-7-gnublin/linux-3-7-gnublin/commit/e7100238b785c299acd6413f41a23eeab2811ff8/diffs 
), i'll start the play around with the machine support first, and later 
come back with cleaned up diffs and more specific questions.

>
> Best regards,
>
> Thomas
Thank you,

-- 
br,
Zoltan Gyarmati
mail: mr.zoltan.gyarmati at gmail.com
freenode nick: zgyarmati