On 12/3/07, Clemens Koller <[EMAIL PROTECTED]> wrote: > Hello, Scott! > > Scott Wood schrieb: > >> Here, the next idea which comes to my mind: > >> Maybe we should think about a kernel-config -> dts compiler for > >> the future where the enabled drivers generate their default dts > >> entries automagically? > > > > Sorry, there's just not enough information in .config for that. > > If there is really the need to put more information (which I don't > see in the case of the RTCs) to .config, it might be an idea to > extend the current structure for this use instead of duplicating > and maintaining a second repository. > > And regarding the DS1337 (or the PCF8563 and similar RTCs): > It's address (0x68) is immutable fixed by the manufacturer > of that device. So, why do we include it in the DT, when we > already told the kernel what driver we want to use?
I2C is an odd bus in that it is only partially probeable; you can probe for presence, but you can't trust that you know what is there. The device tree approach sidesteps that uncertainty by just mandating that you specify that address and type of each device. This is neither hard or onerous on the developer to do. If we *could* trust the i2c probing (like we can on PCI), then i2c devices would *not* need to be in the device tree. > Even if I have an eeprom which can have varying addresses, > I can simply tell the driver/the kernel .config what address > it should use... If I want to be able to alter that address > for whatever reason by OF, I still don't want to touch a > separate file in the kernel tree. Kconfig was never designed for that type of board level detail and it would be awkward to shoehorn that in (not to mention that it doesn't solve the problem of one kernel running on many boards.) Historically we solved the config problem with board specific code in .c files. A solution I'm sure you'll agree might work, but it's not sustainable in the long run. As for modifying the device tree; you've got many choices; choose what works best for you. For example, you could: a. write a separate .dts file per board varient, or b. write single .dts files which only contains the common properties and the bootloader populates the board specific ones, or c. write a single .dts file which contains all possible nodes and the bootloader deletes the nodes which are irrelevant. Regardless of what method you choose, you just need to make sure that the device tree that the kernel receives is an accurate representation of the hardware (ie. no nodes for non-present devices) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
