On Sat, Jun 8, 2013 at 12:09 AM, Dennis Lan (dlan) <dennis.y...@gmail.com> wrote: > > > 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-ker...@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. -- 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/
