[Lenny400] Some tentative changes to the mainline kernel

[Paul Boddie]

On Saturday 4. April 2015 10.34.58 Dr. H. Nikolaus Schaller wrote:
> Hi Paul,
> 
> Am 04.04.2015 um 02:34 schrieb Paul Boddie <paul at boddie.org.uk>:
> > Hello,
> > 
> > I was recently persuaded (or managed to convince myself) to take a look
> > at building a kernel for the Letux400, already having a Ben NanoNote and
> > wanting to see if I could build a mainline kernel for that. It turned
> > out that the jz4740 support in the mainline is mostly complete
> 
> yes, it looks to be quite mature - but the only jz47xx chip that is
> supported at all.

Yes, as I understand it, some very motivated people managed to get the 
jz4720/jz4740 support ported to the mainline kernel APIs a while ago. 
Certainly, support for 3.12 started here:

http://lists.en.qi-hardware.com/pipermail/discussion/2013-November/010406.html

And this work has continued right through last year:

http://lists.en.qi-hardware.com/pipermail/discussion/2014-
September/010705.html

There were surely many previous releases that I wasn't paying attention to. 
;-)

[...]

> I think there should be a mach-jt47xx directory. Like for ARM there is
> arch/arm/mach-omap2 (covering OMAP2, OMAP3, OMAP4, OMAP5
> and at least 30 different variants).

I don't know the reasoning for the objection to a separate mach-jz4730 
directory. Maybe it just seems like unnecessary proliferation of directories!

[...]

> OMAP has the same “problem”. The number and base addresses of the
> GPIO controllers differ.
> 
> It is solved by a mixture of code and the device tree. The DT can specify
> different base addresses and the number of gpio controller instances. And
> can control through the “compatible” property how the driver uses these
> addresses to cover such differences.
> 
> But we have no DT in MIPS. Or would it be possible to just use introduce it
> for the JZ chips? Basically DT is not restricted to a specific
> architecture. Except by really using it.

The MIPS Creator kernel developers are supposedly going to introduce DT 
support, and various branches in various repositories also promise such 
support. For instance, the qi-kernel repository appears to have a branch for 
3.18 with DT support, although it is likely to be a work in progress:

http://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/jz-3.18-dt/

[...]

> Backlight wouldn’t be my main concern in the beginning. It could just be
> turned always on - until the main parts are working.

Yes, U-Boot seems to take care of this, anyway.

> > Since my patch isn't very large, I intend to send it to this list,
> > although I suppose I could also push it or share it somewhere.
> 
> Yes, it is no problem to send it to this list.

OK, I'll send a separate message with the entire set of changes.

> > I rather dislike git and
> > don't have a GitHub account, so I can't claim to be seamlessly
> > interoperable with those who like both those things, but I will
> > cooperate with anyone who wants to correct my work and to test it. I
> > also don't tend to work with the Linux kernel, so you can probably also
> > expect lots of mistakes and bad practices. ;-)
> 
> What I can offer is that we update the l400 branch of the gta04 kernel
> (http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/3.12-
> wip-letux400) and at some point it can simply be merged into the gta04
> master branch and continued to be maintained (and upstreamed) there.
> 
> BTW: it is mirrored to github, so it will be there as well:
> 
> https://github.com/goldelico/gta04-kernel/tree/3.12-wip-letux400

I don't really mind where the patch ends up, but note that I started from 
"torvalds/linux" meaning that it branches out from a very recent kernel, not 
from the above branch, although I did see that before and decided not to start 
with it. (I don't think the Letux400 functionality is really combined with the 
rest of the code, is it?)

> > I'd like to see the jz4730 supported in the mainline kernel or a close
> > derivative because it would also give me some confidence that other
> > jz47xx variants would be sustainable choices for new hardware. For
> > instance, the EOMA68 initiative intends to produce hardware using the
> > jz4775 that could even be considered "FSF-endorseable", and it just
> > isn't sustainable to use these "code drop" ancient kernels that Ingenic
> > seems to provide for the basis of a software distribution or for
> > anything needing a reasonable period of support.
> 
> Yes, this matches with the ideas I have for the gta04-kernel. It should
> (and is already not) focussed on the GTA04 device any more (it already
> supports the OpenPandora and Pyra Handheld, as well as the BeagleBoards).
> So iot is more and more becoming a maintained “distribution kernel”, i.e.
> adds some parts on top of kenrel.org to make it useful for daily work.
> And, we regularily try to upstream things to kernel.org (which is
> sometimes tough work).

I foresee a lot of difficulty trying to get stuff into the "proper" kernel, 
especially with the continuous churn, and the DT stuff will be the next hurdle 
to overcome after people decide that any new functionality must use DT. But I 
feel that as long as we start out a lot closer to the current state of 
development, we have a chance of merging, and if we are able to make as much 
use of existing functionality as possible, the patches shouldn't be very 
controversial at all.

> So you are welcome to submit your patches to this list here and I can
> integrate it into git.

Expect a message with these shortly! :-)

Paul