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

On Sat, Jun 8, 2013 at 12:09 AM, Dennis Lan (dlan)
[off-list ref] wrote:

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

quoted

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.

 thanks for chipping in.

     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.

 mmmm.... fdt.  could you provide some context here?  what is it?
(apart from being a TLA)

  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...

 ... which i have to admit i may have missed the significance of or
possibly just missed it entirely.

 what's the main concern you have, here; what's the potential
solution, and what's the benefit of that potential solution, to
allwinner [direct or indirect]?

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...

 yehh... that kinda looks unavoidable, although it would ultimately
only inconvenience the developers of the proprietary firmware-flashing
tools [livesuite, phoenix] and so would be transparent to the
factories and so on.  i've mentioned the idea of having an in-kernel
translation tool rather than an external (pre-runtime) one, i've yet
to get some feedback on that.

 l.