Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
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-arm-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cakon4oyyrf4z46ryjfdwuwo4l52z8bgsh0czdr2gderw4id...@mail.gmail.com
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
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: [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 luke.leigh...@gmail.com wrote: On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström hen...@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. 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-arm-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: [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 luke.leigh...@gmail.com wrote:
On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com jonsm...@gmail.com
wrote:
On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton luke.leigh...@gmail.com
wrote:
On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
hen...@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:
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-arm-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 7:26 PM, luke.leighton luke.leigh...@gmail.com wrote:
On Thu, Jun 6, 2013 at 12:07 AM, jonsm...@gmail.com jonsm...@gmail.com
wrote:
On Wed, Jun 5, 2013 at 6:47 PM, luke.leighton luke.leigh...@gmail.com
wrote:
On Wed, Jun 5, 2013 at 10:59 PM, Henrik Nordström
hen...@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
jonsm...@gmail.com
--
To UNSUBSCRIBE, email to debian-arm-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
