Message-ID: <48F448EA.8060400@control.lth.se>
Date:	Tue, 14 Oct 2008 09:23:22 +0200
From:	Anders Blomdell <anders.blomdell@...trol.lth.se>
To:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Make ATNGW100 serial ports configurable

Haavard Skinnemoen wrote:
> On Mon, 13 Oct 2008 20:08:21 +0200
> Anders Blomdell <anders.blomdell@...trol.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@...trol.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists