some more updates from the software part

Lars-Peter Clausen lars at
Thu Sep 24 14:40:28 EDT 2009


Wolfgang Spraul wrote:
> Lars,
>> They use a more evolutionary approach when it comes to patching the
>> Ingenic sources, it's not that much of a cleanup or rewrite as opposed
>> to what we did.
> OK got it.
> Let me explain my plan a bit and see what you think:
> Right now, Ingenic is publishing their work on the Linux kernel on a daily
> basis, through our servers. Cross your fingers that it keeps working, but
> right now I see updates until 2 days ago, so it seems to work.
> Ingenic works on two kernel versions, and 2.6.27.
> The way I see it is that people like you, Mirko, and many other upstream
> Linux folks have abilities that the in-house Ingenic engineers don't have,
> and will not have in the foreseeable future.
> Such as English skills, and ability to quickly communicate with upstream,
> understand the 'big picture' kernel architecture and interface changes.
> Whereas the Ingenic engineers know their chips much better than we do, so
> they can fix specific bugs much more effectively, and bring out the features
> of the chips.
> I like that you do a more radical approach to cleaning up the Ingenic
> patches, because when we have reached a good enough level and completeness,
> I can ask Ingenic to re-base their work on top of our kernel.
> It gives us the chance to define the architecture and interfaces for them,
> and they fill in the details.
> That way I believe we are all working with our respective strengths.
> What do you think? Does this make sense?
> I understand we only work on 1 board right now (the Ben NanoNote), and only
> care for a few peripherals (well you have the 4740 EVB as well now...)
I think for basic support for the peripherals found in the nanonote we
are feature complete. But beyond that there is no support.

> But at which point do you believe would it make sense for us to ask
> Ingenic to up-level to our kernel?
> Should we introduce some more 'boilerplate' code for them, just take some
> more drivers over into a better architectural structure, even if those
> drivers don't work or have commented-out code. And then ask Ingenic
> to see whether they want to continue on that basis?
I don't know when it would make sense to ask Ingenic when to use our
kernel as a base. That's because I don't know what Ingenic needs support
for before they consider it. In my opinion you should ask them what it
would take for them to switch.

But actually I'm not sure if they will consider a switch anyway, because
on the short term apparently their approach seems to work well enough
for them. Switching on the other hand would require additional work and
resources, which they might not be willing to invest.

- Lars
> Right now they will continue on the and 2.6.27 trees. They mostly
> run Android on the 2.6.27 tree (that's the reason they started with this
> kernel version in the first place).
> This is basically what I had in mind. Any thoughts?
> Wolfgang
> On Wed, Sep 23, 2009 at 08:03:08PM +0200, Lars-Peter Clausen wrote:
>>> Hi, just thought I point you to this other git repository with
>>> quite a bit of Ingenic hacking going on:
>>> The OpenInkpot guys are working on a 4740 based Hanvon N516 e-book,
>>>  and are doing some cleaning up and rewriting of Ingenic drivers as
>>> well. I have heard about work in the I2C driver, USB client, LCM
>>> and NAND. I just thought I pass the URL along in case it's not
>>> known yet... Wolfgang
>> Hi
>> Yup, I've been monitoring their repository for some time now.
>> Unfortunately I didn't had the chance to take to Yauhen Kharuzhy yet.
>> They use a more evolutionary approach when it comes to patching the
>> Ingenic sources, it's not that much of a cleanup or rewrite as opposed
>> to what we did. And most of the things they do are not relevant for
>> the nanonote anyway.
>> Never the less we should strive towards a common code base. I'll try
>> to make contact in the next days. We'll see then what will necessary
>> to archive this.
>> - Lars

More information about the discussion mailing list