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

[Dennis Lan (dlan)]

On Saturday, June 8, 2013, luke.leighton wrote:

> right - too many people contributed to this, input from jon smirl,
> wookie, maxime, tomasz, henrik, i've made a start here and will
> continue editing: this is notes for me to put forward an agenda for
> discussion:
>
> http://hands.com/~lkcl/allwinner_linux_proposal.txt
>
> i'm setting a rule that each section *has* to have a list of clear
> benefits, otherwise it'll have to be removed before it goes on to
> their Directors.
>
> so - even if there are any allwinner engineers reading this who would
> like something put forward please also speak up! :)
>
> l.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


Hi luke
     I'm not a allwinner employer :-)$. but pretty much in the same
position as they are.

     I'd like to add a few comments about the risk of adopting the device
tree(from allwinner side)
1) current using fdt in bootloader(uboot) is not mature, I'm not saying
about passing the fdt data to kernel.
  But the bootloader itself need information from device tree, say boot0/1
phase (boot device type, DDR initialization...)
  since fdt is not ready, and SRAM space is very limited ... I'm afraid
'fex' may co-exist with device tree.
  still, they receive benefits if they can adopt device tree, at
least minimal the kernel side migration effort
  Generally this info already been pointed out by steppen warren in
previous email...

2) device tree may not been understood by third vendors (who previus
produce shoes or ? :-$),
  they are real old 'Fex' scheme user, they like edit the data in windows
with dos format
  So, how to fill this gaps, make them happy? Creat another tool to handle
device tree modification?
  Then it's another price they have to pay...


Dennis Lan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130608/599ec055/attachment.html>