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

[Clemens Koller <clemens.koller@anagramm.de>]

Hello, Scott!

Scott Wood schrieb:
 > Clemens Koller wrote:
 >> [OT+sarcasm on]
 >>
 >> So, the time is over, where you just enable a driver in the kernel
 >> config and
 >> the device gets probed and - if it's probed successfully - it usually
 >> works.
 >
 > The problem is the "probed successfully" bit -- i2c can't be
 > automatically detected like PCI can, and the probing that was being done
 > before was very error-prone.

I think I understood the original purpose of device trees, or it's
intended advantage but don't see much of this yet.

Before (2.6.22) everything was working fine just by enabling the proper
kernel config. But in it's current implementation I primarily see the
an additional, duplicate, badly documented configuration step for
these - in my case - stupid, usually trivial to handle RTC chips.

 > That's the simplest way, but not the only way.  You could also have a
 > wrapper platform that chooses the proper device tree based on something
 > you detect.

Here is the problem:
something it detects = probing (what we planned to avoid)
something I detect = configurating (currently duplicated work).
This wrapper platform doesn't really exist yet in practice.

 >> Hmmm... this just s****!
 >
 > There are some growing pains, but the old method of blindly poking at
 > i2c addresses and hoping that the first driver to ask for a port that
 > something responds to is actually the right driver for that port is just
 > shit.

That's not a good example: Of course, blindly poking is bad...
therefore there is the (kernel.)configuration step to have only
the relevant drivers enabled:
The Philips PCF8563 is on address 0x51 and the DS13x7 on 0x68.
The drivers don't touch foreign addresses at all and they are
fixed. No issues there... proved by 2.6.22.

Well, I don't want to start a flamewar on this since we have had
already enough pro & contra Device Tree discussions. I just want
to point out that the current situation doesn't really follow
the KISS principle at all in my eyes.

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?

Regards,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com