Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

["Grant Likely" <grant.likely@secretlab.ca>]

On 12/3/07, Clemens Koller <clemens.koller@anagramm.de> 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.
grant.likely@secretlab.ca
(403) 399-0195