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

[mike.valk at gmail.com]

2013/6/11 Oliver Schinagl <oliver+list at schinagl.nl>:
> 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! ;)

Currently the most supported in Linux is VDPAU.
Intel is betting on their own VA API (libav)
Android has set to OpenMax.

But there are more out there like Marvell's vMeta core and 'Dove'
drivers. (eg SolidRun Cubox)

I guess OpenMax is the best bet in the long run as it is platform
independent and a royalty free and open standard. VDPAU and VA API
have strong ties into X11. Which may become obsolete when/if the
switch to Wayland/Mir/SurfaceFlinger is made.

I believe XBMC has/wants support for OpenMax as well.

But I'm no video decoder expert. I'm still trying to grasp what all
drivers and do and don't. Each time I think I get it it seems I don't.

But trying to pus CedarX as the 'new' standard seems a bad idea too
me. Just another fish in the pond.

>
>>
>>
>>> 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.
>>
>
>
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk