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

[jonsmirl at gmail.com]

On Wed, Jun 5, 2013 at 7:26 PM, luke.leighton <luke.leighton at gmail.com> wrote:
> On Thu, Jun 6, 2013 at 12:07 AM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton <luke.leighton at gmail.com> wrote:
>>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
>>> <henrik at henriknordstrom.net> wrote:
>>>
>>>>>  .... and then there's the boot0 and boot1 loaders, these *do* have
>>>
>>>> no, these are not tiny. boot0 is 24KB to fit the initial embedded SRAM
>>>> (not cache), but boot1 is on pair with u-boot in size and runs from
>>>> DRAM.
>>>
>>>  btw, please listen to henrik: he knows what he's talking about, as
>>> you can see :)   henrik, thank you for correcting my technical
>>> misunderstandings, i'll try to remember them and not propagate
>>> incorrect stuff.
>>
>> This is not about the fex syntax or uboot. The root problem is needing
>> two sets of binding for every device driver in the kernel. Pick a
>> random driver like gpio-pca953x.c and look at the source. In that file
>> there are #ifdef CONFIG_OF_ sections. Those sections are directly
>> reading the FDT binary via calls like of_get_property(node,
>> "linux,gpio-base", &size);. If fex is added to the kernel every driver
>> driver will now need both a #ifdef CONFIG_OF_ section and also a
>> #ifdef CONFIG_FEX_ section. Doing that is just crazy.
>
>  yes.  which is why they haven't done it.
>
>> Is Allwinner
>> going to add fex support to every single device driver in the kernel?
>
>  no john - they've only added it to the multiplexed sections of the
> drivers which they themselves have written.  such as
> drivers/usb/sun{N}i_usb/*.[ch], drivers/block/nand/sun{N}_i,
> arch/arm/mach-sun{N}i and so on.
>
> even the touchscreen driver that they wrote, that's got nothing to do
> with any other code in the touchscreen linux kernel source tree: it's
> more of a "meta-"driver which even has the name of the linux kernel
> module that needs to be loaded and what I2C address, GPIO options etc.
> to pass in [normally done as modprobe options in userspace].
>
>  to be honest, there are better people to fully answer this question
> (alejandro and henrik are two that spring to mind) but you're
> definitely off-base, jon.  the script.fex system deals with the pinmux
> issue in a very neat way that:

I have a Cubieboard and I have a pca9532 on my desk. Now I want to
attach this pca9532 to the Cubieboard so I wire them together on I2C.

How is the Allwinner kernel going to load the driver for the pca9532?
The mainline pca9532 driver does not understand fex so it can't read
the necessary initialization data.

Luke, you of all people should see what is going on. Take an EOMA
module based on an A10. Now plug it into ten different hosts with
widely varying hardware support - like each of the ten hosts has a
different lm-sensor type chip. Where are the fex drivers for those ten
different lm-sensor chips going to come from? We already have DT
support for them.

fex is only supported on the small number of peripheral chips
Allwinner has blessed. Use any chip outside of that set and it isn't
going to boot.

>
>   a) has very little impact on the rest of the kernel tree [citation
> needed!  i'm saying that: could someone please confirm if it's true]
>
>   b) the linux kernel developers could, instead of criticising it,
> actually learn a great deal from.
>
> l.



--
Jon Smirl
jonsmirl at gmail.com