Looking for ARM SoC porting guidelines

[Maxime Ripard]

Hi,

On Thu, Nov 13, 2014 at 10:41:25AM -0800, Mike Thompson wrote:
> On Thu, Nov 13, 2014 at 12:40 AM, Maxime Ripard <
> maxime.ripard at free-electrons.com> wrote:
> 
> > > As a guide, I've been using other ARM SoCs for examples and a number of
> > > very useful presentations on ARM SoC support from the Free Electron
> > folks.
> > > Although presentations such as the "ARM SoC Linux Support Check-list" are
> > > very useful, they don't go into much detail.
> > >
> > > My question is two fold.  Is there detailed information of all the things
> > > that need to be covered in the code to introduce a new ARM SoC into the
> > > kernel?
> >
> > Usually "enough so that it boots", which means: timers, interrupts,
> > UARTs, and that's pretty much it.
> >
> > Any additional feature is of course welcome, but I'd suggest to just
> > post that for the first set of patches. There will probably
> > significant changes to make to your base drivers (and I would include
> > clocks and pinctrl into these drivers), and these will impact any
> > further developments. You don't want to have too much dependency :)
> >
> > Start small, then build on top of what's accepted.
> >
> 
> OK, that is pretty much from what I expected. I'll begin this process soon
> as I have added similar base support for the N32926 which is a bigger
> brother to the N32905.  I figure it's best to lay the foundation for
> multiple chips in the Nuvoton N329 family from the start.
> 
> I've been using the iMX23 and iMX26 SoC support as the model for code
> placement, naming and such.  These chips are useful in the way they share
> drivers similar to what I would like to do.  Are these SoCs known to be
> following current best ARM SoC practices for me to follow in their path?

I guess you meant imx28, but yeah, they have a quite good support with
regard to the usual best practices.

However, they do have quite some history that won't be needed. You'd
better start looking at the platforms that were introduced
recently. Off the top of my head, I'd say the amlogic or alpscale SoCs
that have been merged, or not that far.

> Concerning how I should arrange my code in a git repository, currently
> everything is in a single branch.  I guess I'll want to peel out just the
> minimal set of drivers from which I'll submit patches and then do the work
> on the more advanced SoC drivers in another set of branches so everything
> isn't all mixed together.

Yeah, it's up to you, but I guess it's the common workflow. I've
looked into your git repo, and it seems like there's been quite some
work and it has some history already. Don't carry that history when
sending patches, just post the patches to add the current code you
have.

> > Then, is there a description of how I start to go about contributing
> > > support for this chip into the Linux kernel? I honestly don't really
> > > know where to begin.
> >
> > Like I said, send the minimum amount of patches to have Linux boot an
> > initramfs on your SoC. Apart from that, there is nothing out of the
> > ordinary on how to submit patches, everything is detailed in
> > Documentation/SubmittingPatches. Basically, it will involve sending
> > patches to the linux-arm-kernel mailing list and the ARM SoC kernel
> > maintainers. Make sure that everything has no warning in
> > scripts/checkpatch.pl, and you're good to go.
> >
> > Maxime
> >
> 
> Got it.  Hopefully I'll start with the first set of patches within in the
> next few weeks and cross my fingers I'm not chased away with a stick for
> being such a newbie :-).
> 
> Before submitting the first set of patches, would it be useful for me to
> post a link to them here on this mailing list so someone could look them
> over as a sanity check before a submission to the linux-arm-kernel mailing
> list?  I'm a bit nervous about making a good first impression.

Don't worry about this :)

It's completely fine to be a newbie, we've all been there at some
point. People won't flame you if you are one, and will even usually
guide you to stop doing the mistakes you're making. However, you will
piss people off if you ignore these advices and keep doing the same
mistakes over and over again :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141114/4267b0c7/attachment-0001.bin