Messages in this thread | | | Date | Tue, 14 Oct 2008 09:23:22 +0200 | From | Anders Blomdell <> | Subject | Re: [PATCH] Make ATNGW100 serial ports configurable |
| |
Haavard Skinnemoen wrote: > On Mon, 13 Oct 2008 20:08:21 +0200 > Anders Blomdell <anders.blomdell@control.lth.se> wrote: > >> Dropped the kernel list CC on previous post, sorry. >> >> Haavard Skinnemoen wrote: >>> Oh, that stuff. Yeah, when an expansion board needs to disable features >>> on the motherboard, it gets a bit messy. >> How should this be handled with device tree? > > By simply leaving those pins out. Or perhaps there's some mechanism for > disabling them. > >>> That's why you should send it upstream so that it can be kept in sync >>> whenever something changes. Also note that the same applies to your >>> out-of-tree module. >> Which is what I'm trying to do, but the maintainer is complaining :-) > > No, you're trying to push a mechanism which will allow you to avoid > doing that, at the expense of less readable board code for everyone > else. > >> But we probably don't want to add everyones prototype boards to the kernel tree! > > Well, why not? It's not like it takes up much space. And it can always > be removed later when the prototype gets reassigned to collecting dust > at the top of some shelf. > > It might even be a nice experience for later when you want support for > your production board upstream... > >>> But I do think device trees along with a nice graphical editor, or a >>> few u-boot commands, would go a long way towards this goal. If we >>> manage to get something like that working, you won't even have to >>> recompile anything. >> As far as I can see, the device trees will push the conflict resolution to >> run-time instead of compile-time, which I belive is bad for both memory >> footprint as well as performance (as well as predictability, this kernel worked >> yesterday; who added which device which makes it crash today...) > > Any conflict resolution _today_ happens at run time in the form of a > friendly error message and a stack dump if you try to assign the same > pin to two different devices. > > And with your patch, some device might suddenly stop working because > you enabled a USART which conflicts with some other device that gets > initialized later (the USARTs are initialized very early). How is that > any better? > > As for performance and memory footprint, I think the impact will be > minimal. This is init code that we're talking about -- it gets run once > and then discarded. > > Oh, and the device tree stuff comes with some nice infrastructure which > would make it quite easy to write a static validator for pin assignments > and such. That would actually move the conflict resolution from > run-time to compile-time. > >>>> But personally I would be happy with a generic ap7000 >>>> board, where I could pick all the options I like and the ngw100 and stk100x >>>> would just be an instance of this board with all/most options preselected. That >>>> #ifdefs are messy to read is something we agree about... >>> Right, I also want more generic board support. But I don't think >>> Kconfig is the way to go. There are just too many variables. >> Wouldn't there be as many variables with a device tree? > > Yes, but you're exposing them to the right audience: The board vendors, > not the users. In the case of hobbyists creating their own boards, > they're of course the same people, but they are definitely power users. > > Also, I believe that, if the device tree layout is carefully designed, > it might be possible to turn bits of it on and off at run-time. That > would be great for configurable boards like the STK1000 -- with a bit > of extra support from u-boot, you should be able to do something like > > switch 5 on > > to select between two different mux settings (e.g. second ethernet > controller vs. LCD). > >> A graphical board-configurator against the Kconfig should certainly be possible? > > It will probably be just as easy to have the board configurator > generate C code, or a device tree. > >> I'm also not (yet) convinced that your approach makes the configuration any simpler. > > I guess we'll just have to implement it and find out. Until then, > there's really no way to tell -- you may of course be right. OK, I'll wait for the device tree to appear...
>> How about putting each needed extension in a separate file (with a specified >> format), and use some kind of preprocessor to generate Kconfig's, Makefiles, >> setup.c, etc from those files (and generating the appropriate at32_reserve_*, >> at32_select* as well). I.e. something like: > > If you're generating code, why bother with Kconfig at all? Because that is the way I'm used to select drivers when I configure a kernel (call me old fashioned if you will :-).
>> USART2.def: >> >> %PINS { >> PA08, PA09 >> } >> >> %GLOBAL { >> platform device *usart2; >> } >> >> %INIT { >> usart2 = at32_add_device_usart(2); >> } >> >> %SETUP { >> new_at32_map_usart(usart2, at_32_last_mapped_usart++); >> } > > You've already written most of the board code, and added quite a bit of > additional noise. Why not write it in C instead of some > yet-another-weird-configuration-language? Oh, that leads to lots of noise^H^H^H^H^H^H #ifdefs :-)
> Hey, why not use XML? I'm sure lots of LKML subscribers would be > absolutely thrilled! ;-) XML is OK with me...
-- Anders Blomdell Email: anders.blomdell@control.lth.se Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden
| |