Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton wrote: > augh. ok. solutions. what are the solutions here? Luke if you really want to fix this a good solution is to have Allwinner join Linaro and provide an engineer to the Linaro effort. That engineer will get educated on the right way to do kernel development and he can pass that knowledge back to Allwinner each day as he learns it. Allwinner has expressed interest in the past in joining Linaro but the price was too high. I believe there are cheaper options now for joining. The benefits Allwinner receives from joining will far exceed the cost of joining. The net result will likely be a reduction in the amount they need to spend on in-house development since they will learn how to better leverage other developer's work. -- Jon Smirl jonsm...@gmail.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakon4oxpdpn3btc9gwp44exdskazgj5oecpup37vrnnvxwu...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 7:26 PM, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com
> wrote:
>> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton
>> wrote:
>>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
>>> 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
jonsm...@gmail.com
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKON4Oz79hUE_ReAqjeynwL6ZWntX2W1uw3YOg0G2AiY7Gjs=g...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 7:26 PM, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com
> wrote:
>> On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton
>> wrote:
>>> On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
>>> 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:
>
> 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
jonsm...@gmail.com
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKON4OyWaUod8m-7Fn5qdjnMs8o+ajqdOJ=XRmw_vl00...@mail.gmail.com
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton wrote: > On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström > 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. Is Allwinner going to add fex support to every single device driver in the kernel? Of course not, that task is far too large. What Allwinner needs to do is come onto the common API that everyone else is using. So consider what is going to happen if you try to use a pca953x chip in an Allwinner system. You're going to have to rewrite part of the device driver. You're going to have to do that for every chip you try to use. Those forks won't be accepted back into the kernel, etc. And you'll end up as yet another port and forget embedded developer. As for uboot I hope you are using the SPL support and haven't reimplemented it. If the full uboot has been modified to dynamically read a script.bin then it shouldn't be much of a stretch to teach it about FDT instead. That would be a useful feature to add to mainline uboot. As for fex2bin and bin2fex you already have the equivalent tool on your machine. It is called dtc. Check out scripts/dtc. So if you are in love with fex syntax write a script that converts it into device tree syntax. Then compile the DTS using dtc into a DTB. When the DTB is in memory it is a FDT (flattened device tree). It's that FDT format in memory that has become fixed in stone. -- Jon Smirl jonsm...@gmail.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakon4oxwyv2f_iteb5rnp_azc7essxpdku_ty5wlwxn7usi...@mail.gmail.com
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
behind that is, > i believe, an expectation that if you *don't* convert to Device Tree, > you can kiss upstream submission goodbye. and, in allwinner's case, > that's simply not going to happen. > > add to this the fact that they've already taken *five* near-identical > copies of each version of their drivers (for sun3i up to sun7i) - if > you do a recursive diff in the drivers/usb/sun7i_usb and > drivers/usb/sun4i_usb directories, the discrepancies are negligeable > (and are in many cases a regression, reintroducing known or new > bugs!), you can start to see that they simply have no idea how to work > with the free software community (they're too busy) and that they're > not really about to start, either. > > ... and yet they're unbelievably successful, despite making a dog's > dinner of things as far as upstream integration is concerned, > precisely because they really really do only need to get one single > kernel compiled (for *all* their multi-million-dollar clients) and > err... that's it. everything else goes into a per-client (per > product) customized script.fex. > Device tree on ARM's goal is to achieve a single kernel across vendors, not just a single kernel for a single vendor. > so, i don't have all the answers, but i can clearly see that there > needs to be some discussion and dialog - we can't have the world's > most successful SoC vendor *not* supported upstream: that's just a > ridiculous situation that is not helping any of the linux distros to > be an easy install option on some of the world's highest > price-performance ratio hardware. > > thoughts and discussion appreciated. > > l. > > > [*0] > http://hardware.slashdot.org/story/13/05/08/1636217/chinas-allwinner-outsold-intel-qualcomm-in-tablet-processors-in-2012 > [*1] - fex guide for SoCs up to but excluding the Allwinner A20 > http://linux-sunxi.org/Fex_Guide > [*2] http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-June/007619.htmland > > http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-June/007611.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Jon Smirl jonsm...@gmail.com
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
behind that is, > i believe, an expectation that if you *don't* convert to Device Tree, > you can kiss upstream submission goodbye. and, in allwinner's case, > that's simply not going to happen. > > add to this the fact that they've already taken *five* near-identical > copies of each version of their drivers (for sun3i up to sun7i) - if > you do a recursive diff in the drivers/usb/sun7i_usb and > drivers/usb/sun4i_usb directories, the discrepancies are negligeable > (and are in many cases a regression, reintroducing known or new > bugs!), you can start to see that they simply have no idea how to work > with the free software community (they're too busy) and that they're > not really about to start, either. > > ... and yet they're unbelievably successful, despite making a dog's > dinner of things as far as upstream integration is concerned, > precisely because they really really do only need to get one single > kernel compiled (for *all* their multi-million-dollar clients) and > err... that's it. everything else goes into a per-client (per > product) customized script.fex. Device tree on ARM's goal is to achieve a single kernel across vendors, not just a single kernel for a single vendor. > > so, i don't have all the answers, but i can clearly see that there > needs to be some discussion and dialog - we can't have the world's > most successful SoC vendor *not* supported upstream: that's just a > ridiculous situation that is not helping any of the linux distros to > be an easy install option on some of the world's highest > price-performance ratio hardware. > > thoughts and discussion appreciated. > > l. > > > [*0] > http://hardware.slashdot.org/story/13/05/08/1636217/chinas-allwinner-outsold-intel-qualcomm-in-tablet-processors-in-2012 > [*1] - fex guide for SoCs up to but excluding the Allwinner A20 > http://linux-sunxi.org/Fex_Guide > [*2] http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-June/007619.html and > http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-June/007611.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Jon Smirl jonsm...@gmail.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakon4oyyrf4z46ryjfdwuwo4l52z8bgsh0czdr2gderw4id...@mail.gmail.com
