On Mon, Apr 18, 2011 at 05:41:14PM +0300, Tony Lindgren wrote: > * Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> [110418 16:54]: > > I do think that a flat lines of code criterion isn't terribly helpful as > > it isn't *really* what we're trying to optimise and will needlessly > > peanalise newer architectures which have good reasons for active > Sure. But for an existing platform it can tell something indirectly. Right, but my point is that it's being treated as gospel not an indicator. > > I think we need the append support for all platforms - the idea of > > having the description of the CPU in each board device tree just doesn't > > seem sensible to me. > I think the CPU or SoC can be just included into the board description > file. Or do you have something else in mind for that? There's the device tree bits that represent the internals of the CPU (there was a push to use device tree there too) - that needs to be merged with the off-chip definitions from the board. > > You can easily be pushing at something in four digits by the time you > > map out a large board, it's certainly not a trivial amount of code to go > > trying to save especially when that's not really directly relevant to > > improving the reuse for board drivers and you get into diminishing > > returns fairly rapidly. > I guess I'd rather stick to only minimal board additions for now. > At least for me merging anything larger means that later on I may > have deal with sorting it out which is not nice.. Like I say right now we're just flat out refusing to accept boards at all so it's all rather moot. > BTW, this issue can be already avoided for most part by creating > generic platform init code, like what we have for gpmc-*.c for > any devices connected to the GPMC bus on omaps. And that's something > that can be done already for various platforms. That doesn't really achieve a huge amount for platforms where it really is just providing resources for the device rather than doing any bus configuration like gpmc does - on some platforms you just spec the memory regions and IRQ ranges and you're done. TBH for those systems it doesn't seem like a valuable use of time to implement this when device tree is (probably) just round the corner as for these systems it's only factoring out data, not actual code. > > This does also come back to the whole thing about pointing at relevant > > work that people can do - we're not telling people the code they're > > submitting is problematic and they need to address things with it, we're > > saying that we're not even willing to look at the code or talk about > > things that would make it OK. That's a really negative response that's > > essentially impossible to work with. > I don't think that's the intention.. But I agree with you, we > need to coordinate things on the mailing lists so everybody knows > what can be done. And also so that when people can see what they're aiming for. > Maybe let's try to come up with some checklist on what people > can already help with? How about: > - Is there already generic code posted for review that could > be used insted? > - Can the platform specific code and defconfigs be combined > within the platform? > - Is the platform specific data separate from code so that > the data can be eventually be passed from bootloader using > device tree? > - Can the new code be made generic? > - Can the new code be made into a loadable module under > drivers directory? That looks pretty sensible to me - I'd probably merge the "can it be generic" with the first point but other than that it looks OK and mostly also covers drivers as well. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
