[Lenny400] Some tentative changes to the mainline kernel

[Dr. H. Nikolaus Schaller]

Hi Paul,

Am 04.04.2015 um 14:11 schrieb Paul Boddie <paul at boddie.org.uk>:

> 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. 

Yes, there seems to be quite some stuff here:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/jz4740?id=refs/tags/v4.0-rc6

But I don’t know how far it is compared to all the work-in-progress trees.

> 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!

Or they argue that all jz processors should share a directory - as long as they
are reasonably similar.

> 
> [...]
> 
>> 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/

Oh nice! So it will come in 3-4 iterations.

> 
> [...]
> 
>> 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.

Great.

> 
>>> 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?)

No, they should be quite independent. The branch above is a torvalds/linux
plus approx. 140 differences to make it work on the GTA04.

And we regularily merge in linus/master so that we keep up to date.

Do you know which exact release (tag) you did base your work on?

Then we can quite easily rebase to 4.0-rc6 and merge things together.

> 
>>> 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.

Yes, of course. But I think the biggest hurdle is to start :)

> 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! :-)

Great! I can wait some more minutes :)

BR,
NIkolaus