On 28.02.2008 19:40, ron minnich wrote:
I have no idea if this helps. But there's been discussion of "DRAM settings in DTS" and "where does CARBASE go" and so on, so I think we need to try to document some rules. Here is a first cut.
[...] Kconfig
Kconfig has two uses. First, Kconfig is used to select a mainboard and set build options for the mainboard, e.g. whether compression is used or not. Kconfig can also set runtime parameters, such as baud rate for the console. Kconfig should rarely, if ever, be used to set device options that belong in the dts;
There is a problem with that approach. I disagree that baud rate for the console is different from the address of the serial port when you consider their scope. So it does not make sense to have one in Kconfig and one in the dts. Sure, the baud rate is going to be changed more often, but the amount of change a variable is going to see during configuration is not a consideration of the dts/Kconfig placing decision yet.
The address of the serial port is the poster child for how complicated the interaction between Kconfig and code and dts is: mainboard/pcengines/alix1c/stage1.c:#define SERIAL_IOBASE 0x3f8 superio/winbond/w83627hf/dts: com1io = "0x3f8"; We need the #define in stage1 code because we have to access to the device tree yet. However, we also store the value in the dts. We also could place this in Kconfig (I'm against that) and control this centrally.
How about a way to mark a dts property "must be available as #define in stage1"?
Regards, Carl-Daniel