From: Clemens Koller <clemens.koller@anagramm•de>
To: Scott Wood <scottwood@freescale•com>
Cc: Alessandro Zummo <alessandro.zummo@towertech•it>,
rtc-linux@googlegroups•com, linuxppc-embedded@ozlabs•org
Subject: Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Date: Tue, 04 Dec 2007 12:42:41 +0100 [thread overview]
Message-ID: <47553D31.4080306@anagramm.de> (raw)
In-Reply-To: <20071203204652.GB4850@loki.buserror.net>
Hi, Scott!
Scott Wood schrieb:
> On Mon, Dec 03, 2007 at 08:35:29PM +0100, Clemens Koller wrote:
>> 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...
>
> That's precisely what we do, via the device tree. It is not practical to do
> it with kconfig.
It's propably not practical to do it with kconfig right now, but
creating a separate configuration repository with strong relation
to the kernel config is IMO the wrong way to do it.
> Again putting aside multiplatform kernels for the moment,
> what would you do in kconfig to describe the addresses of multiple chips
> without having a fixed-size list of possibilities?
I don't see
> How would you tell the
> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c bus
> 0, and a "bar" chip at address 0x68 on i2c bus 1?
I would prefer to not tell the driver for 'foo' that it should attach to 0-0068
because it should attach to the first i2c bus (0) it finds per default.
Then I would need to tell 'bar' to attach to 1-0068. Where is the problem?
The 0068 is already redundant in the case of these RTCs because they are fixed.
There is already an example in the kernel for a very similar configuration
issue: see CONFIG_RTC_HCTOSYS_DEVICE.
The structure for this already present in kconfig, and I don't see any
road block not to be able to use it. If later on, we want to have OF to
be able to reconfigure it in the form of a DT structure, we could
still feed a tool like the dtc with the .config and generate one.
Just let me make the point clear, why I got so upset here:
Having two different non-independent repositories make the
configuration much more error-prone, especially if the second
one (the DT) is partially redundant and not sufficiently documented.
Example:
I need to use the PCF8563 on the MPC8540' I2C as well (*) - it
was just working in 2.6.22. Now, somebody
a) has to enable it in the kernel config
b) then add it to the i2c_driver_device struct in fsl_soc.c
c) then add it to the DTS.
Step b and c are not difficult at all, but completely non-obvious
and undocumented for non-developers. You actually have to dig in
the code to find out that you need it and this s****.
linux-2.6/Documentation/powerpc$ grep "rtc" *
only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, btw.).
which could give a clue what's going on here.
linux-2.6/Documentation/powerpc$ grep "fsl_soc" *
- nothing -
The configuration process is away from KISS - I would simply
state: it's broken - or - it's a regression from 2.6.22.
(*) Patch will follow, let me see if I guess it right. :-)
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
next prev parent reply other threads:[~2007-12-04 11:42 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-28 18:25 DS1337 RTC on I2C broken Clemens Koller
2007-11-28 18:43 ` Alessandro Zummo
2007-11-28 19:20 ` Clemens Koller
2007-11-28 19:36 ` Clemens Koller
2007-11-28 20:34 ` [rtc-linux] " Alessandro Zummo
2007-11-29 11:24 ` Clemens Koller
2007-11-29 11:34 ` raul.moreno
2007-11-29 12:43 ` Clemens Koller
2007-11-29 20:03 ` Clemens Koller
2007-11-29 20:19 ` Alessandro Zummo
2007-11-30 11:04 ` Clemens Koller
2007-11-30 11:20 ` [rtc-linux] " Alessandro Zummo
2007-11-30 14:12 ` Clemens Koller
2007-12-01 12:24 ` Alessandro Zummo
2007-12-02 20:25 ` Olof Johansson
2007-11-30 18:12 ` Clemens Koller
2007-12-01 12:16 ` Alessandro Zummo
2007-12-03 15:14 ` Clemens Koller
2007-12-03 16:07 ` Bartlomiej Sieka
2007-12-03 16:38 ` Clemens Koller
2007-12-03 16:09 ` solved: " Clemens Koller
2007-12-03 16:48 ` Scott Wood
2007-12-03 17:41 ` OT: " Clemens Koller
2007-12-03 18:07 ` Scott Wood
2007-12-03 19:35 ` Clemens Koller
2007-12-03 20:05 ` Grant Likely
2007-12-03 20:46 ` Scott Wood
2007-12-04 11:42 ` Clemens Koller [this message]
2007-12-04 13:08 ` Scott Wood
2007-12-04 15:32 ` Clemens Koller
2007-12-04 16:08 ` Scott Wood
2007-12-05 10:27 ` Clemens Koller
2007-12-04 17:19 ` Jon Smirl
2007-12-05 10:30 ` Clemens Koller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47553D31.4080306@anagramm.de \
--to=clemens.koller@anagramm$(echo .)de \
--cc=alessandro.zummo@towertech$(echo .)it \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
--cc=rtc-linux@googlegroups$(echo .)com \
--cc=scottwood@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox