LPC313x support - how to do it right?

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Tue Feb 12 06:50:14 EST 2013


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



More information about the Kernelnewbies mailing list