[Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

[Oliver Schinagl]

On 08-06-13 11:17, luke.leighton wrote:
> On Sat, Jun 8, 2013 at 9:41 AM, Oliver Schinagl <oliver+list at schinagl.nl> wrote:
>> Removing all the other lists, as it's only noise on their radar.
>
>   ack.
>
>> Anyway, with all the negativity settled, I do understand what you are
>> trying, working from the topside. So lets look your proposal.
>
>   great.
>
>>
>> On 08-06-13 01:07, luke.leighton wrote:
>>>
>>> On Fri, Jun 7, 2013 at 11:08 PM, Maxime Ripard
>>> <maxime.ripard at free-electrons.com> wrote:
>>>>
>>>> On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote:
>>>>>
>>>>>    maxime: we need to talk :)
>>>>>
>>>>>    please tell me in 4 or 5 sentences what you've managed to do so far,
>>>>> expanding a little on what thomas says below, more specifically what
>>>>> it achieves and/or allows rather than technically what it does
>>>>> (suitable for managers and directors in other words), and what plans
>>>>> you'd like to see happen.
>>>>
>>>>
>>>> You mean something like http://linux-sunxi.org/Linux_mainlining_effort ?
>>>
>>>
>>>    ahh, fantastic.  with references too.  magic.  exactly what i need.
>>> thank you.  listed now at
>>> http://hands.com/~lkcl/allwinner_linux_proposal.txt
>>
>>
>> Look for ===== markers below
>>
>> Proposal: conversion to device-tree (from script.fex)
>> ---------
>> ==========
>> Should be rather obvious why this is a good thing by now. Free updates; free
>> maintance; Future merging will harder and harder; When android gets fully
>> merged, it'll be harder to 'stay behind'. (with us doing quite some
>> mainlining.
>> ==========
>> <snip>
>>
>>
>> Proposal: funding of free-electrons.com and sunxi community
>> --------- to continue mainline Linux Kernel work
>> ==========
>> One other thing that's maybe equally important is a technical support
>> channel. For really technical questions.
>>
>> Example: While digging into the SID, I was looking for 2 things, what does
>> the pre-written value mean, we know it has something like a serial number
>> and the chip ID in there (some where actually zero) and how do you program
>> it? Does it have anything to do with Pin T9, EFUSE_VDD?
>>
>> The reply? "What is your number of sales, what is the size of your
>> market/company" etc. I mentioned we where writing stuff as linux-sunxi etc.
>>
>> They can whitelist only free-electrons or linux-sunxi.org e-mail addresses.
>> Have only 1 or two leisons that they willingly talk to, but we sometimes
>> have tons of technical questions that are simply unanswerable by us. This
>> will be low-volume of course. Not a real burden, but really technical.
>
>   ok - i think this will come about naturally, if the developers are
> permitted to interact freely with the free software community.  that's
> just been added this morning btw.  if you disagree and have something
> more specific in mind, please could you create a separate section that
> i can drop into the proposal?
Well being able to talk directly to their team will be an open door for 
questions, so if we can ask them, yeah that'll work just as well. They 
can then internally find out if they don't know.

>
>
>> Benefit: Us actually being ABLE to write code (for free :( ).
>> ==========
>> Current status
>> (more fully described here: http://linux-sunxi.org/Linux_mainlining_effort)
>> <snip>
>>
>>
>>
>> Proposal: Provide full documentation on the NAND Flash workings
>> --------
>> ==========
>> Also needed: Very badly: DOCUMENTATION TO EVERYTHING! ACCURATE UP TO DATE
>> DOCS.
>>
>> We have some usermanuals for this chip with that missing, some other chip
>> with others missing. But no definitive proper register guide. Things like
>> 'this is XXX IP is used for this' would help a lot to merge with existing
>> driver of course.
>>
>> Benefit to them? THEIR ENGINEERS NEED IT JUST AS MUCH AS WE! As said above,
>> we need docs to write proper drivers, as do they.
>
>   *lol* - you mean... they don't _have_ any??  that would be... shocking! :)
I wouldn't be surprised if their docs are as crap as ours :p Though they 
surely have the missing bits occasionally filled in.
>
>> ==========
>>
>> <snip>
>>
>> Proposal: Provide full source and tools for CEDARX
>> --------
>> ==========
>> All is pretty much listed below. While this is less looking like kernel work
>> (their cedar kernel and disp!!! kernel drivers are a horrible HORRIBLE
>> mess); even the userspace bits (not mali of course) are just as important to
>> have full access too. As you point out.
>> ==========
>
>   *sigh* :)  ok.  this may be true, but i need to put it a better way
> :)  would you be happy to throw some words together that can go
> directly into the proposal?
Not this late I suppose.

Something like:

The display driver requires some heavy clean up as it's very 
UN-maintainable and more importantly, un-mergeable adhering to no 
framework I think.

As for CedarX, the problem herein lies, we don't have a kernel framework 
for this yet. I know there's the broadcom CrystalHD driver in the 
staging area, but even there its said 'we kinda don't have anything for 
this yet, as its the only one driver doing it'. So actually, AW could be 
putting their foot down, make an appearance by having an acceleration 
framework in the kernel. Kinda like here, we mean business, we wrote 
this, it's beautiful, it's awesome and its for everyone to use, we've 
ported our cedarX engine to work with it and see, this broadcom driver, 
with this patch works brilliantly too. A sign of good faith if you will? 
Heck, with all the developers time saved by doing all of the other 
points, they could do this and still fire some! ;)
>
>
>> I was a little dissapointed and shocked to have found out you missed our
>> work. Linux-sunxi mailing list, while not perfect, does see those patches.
>
>   i'm not on it for many reasons, the key personal one being that i
> wasn't involved in the creation of linux-sunxi.org: i found out that
> it existed several *months* after it was set up, so i'm still a bit
> pissed at that.  the key "professional" one is that it would be
> another list with specific technical discussions and user-related
> questions that would completely overwhelm my ability to manage the
> other things going on.
>