From: Wolfgang Grandegger <wg@grandegger.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Linuxppc-dev@ozlabs.org, Alan Clucas <alanc@pipstechnology.co.uk>,
Detlev Zundel <dzu@denx.de>,
lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] [PATCH] Support for DS75 thermal sensor
Date: Wed, 16 Jul 2008 09:12:50 +0000 [thread overview]
Message-ID: <487DBB92.1070100@grandegger.com> (raw)
In-Reply-To: <20080711145613.14380360@hyperion.delvare>
Hi Jean,
Jean Delvare wrote:
> Hi Wolfgang,
>
> On Fri, 11 Jul 2008 14:40:58 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> There's no "detection" involved for the new-style i2c devices.
>>> Presumably you are still using the old binding model, not taking
>>> benefit of the patch at all. Use i2c_register_board_info() to
>>> instantiate your "ds75" i2c device from you board's platform code, and
>>> it should work.
>> I have some general question on I2C device probing. Our board does have
>> two I2C buses. On the first on, there is an RTC at addr 0x32 and a DS75
>> at 0x4c. Both are defined in the Flattened Device Tree and therefore
>> i2c_register_board_info() will be called for them. On the second bus,
>> there are other I2C devices. Nevertheless, probing for RTC and DS75 at
>> addr 0x32 and 0x4c will be performed also on that bus. Is this the
>> normal/intended behavior? Can such probing be suppressed?
>
> Probing isn't supposed to happen at all for RTC chips. There are a few
> drivers which remain to be converted though (rtc-ds1672, rtc-max6900,
> rtc-pcf8583.) If you use one of these and would like to help converting
> it, please tell me (and Alessandro Zummo.)
OK. We ported an old RTC driver for the Epson RX8025 for our board.
Unfortunately, it did not use the new bindings but I fixed that in the
meantime. It will be posted for kernel inclusion soon.
> For hwmon chips, probing only occurs if the i2c adapter accepts to be
> probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
> you do not want a given i2c bus to be probed, then do not set the flag
> for that bus.
I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
for the MPC:
http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
If I disable it, the LM75 driver only probes the addresses of the I2C
nodes defined in the FDT DTS file. I wonder if this should not be the
default behaviour for kernels using OF platform description. For this
reason, I have put Linuxppc-dev ML on CC. I also realized, that there
are some patches for OF I2C pending. I will check.
Wolfgang.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
WARNING: multiple messages have this Message-ID (diff)
From: Wolfgang Grandegger <wg@grandegger.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Linuxppc-dev@ozlabs.org, Alan Clucas <alanc@pipstechnology.co.uk>,
Detlev Zundel <dzu@denx.de>,
lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] [PATCH] Support for DS75 thermal sensor
Date: Wed, 16 Jul 2008 11:12:50 +0200 [thread overview]
Message-ID: <487DBB92.1070100@grandegger.com> (raw)
In-Reply-To: <20080711145613.14380360@hyperion.delvare>
Hi Jean,
Jean Delvare wrote:
> Hi Wolfgang,
>
> On Fri, 11 Jul 2008 14:40:58 +0200, Wolfgang Grandegger wrote:
>> Jean Delvare wrote:
>>> There's no "detection" involved for the new-style i2c devices.
>>> Presumably you are still using the old binding model, not taking
>>> benefit of the patch at all. Use i2c_register_board_info() to
>>> instantiate your "ds75" i2c device from you board's platform code, and
>>> it should work.
>> I have some general question on I2C device probing. Our board does have
>> two I2C buses. On the first on, there is an RTC at addr 0x32 and a DS75
>> at 0x4c. Both are defined in the Flattened Device Tree and therefore
>> i2c_register_board_info() will be called for them. On the second bus,
>> there are other I2C devices. Nevertheless, probing for RTC and DS75 at
>> addr 0x32 and 0x4c will be performed also on that bus. Is this the
>> normal/intended behavior? Can such probing be suppressed?
>
> Probing isn't supposed to happen at all for RTC chips. There are a few
> drivers which remain to be converted though (rtc-ds1672, rtc-max6900,
> rtc-pcf8583.) If you use one of these and would like to help converting
> it, please tell me (and Alessandro Zummo.)
OK. We ported an old RTC driver for the Epson RX8025 for our board.
Unfortunately, it did not use the new bindings but I fixed that in the
meantime. It will be posted for kernel inclusion soon.
> For hwmon chips, probing only occurs if the i2c adapter accepts to be
> probed, by setting the I2C_CLASS_HWMON flag in i2c_adapter.class. If
> you do not want a given i2c bus to be probed, then do not set the flag
> for that bus.
I see. My problem is that I2C_CLASS_HWMON is set in the I2C bus driver
for the MPC:
http://lxr.linux.no/linux+v2.6.26/drivers/i2c/busses/i2c-mpc.c#L314
If I disable it, the LM75 driver only probes the addresses of the I2C
nodes defined in the FDT DTS file. I wonder if this should not be the
default behaviour for kernels using OF platform description. For this
reason, I have put Linuxppc-dev ML on CC. I also realized, that there
are some patches for OF I2C pending. I will check.
Wolfgang.
next prev parent reply other threads:[~2008-07-16 9:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-08 9:22 [lm-sensors] [PATCH] Support for DS75 thermal sensor Wolfgang Grandegger
2008-07-08 9:53 ` Jean Delvare
2008-07-08 13:09 ` Wolfgang Grandegger
2008-07-08 13:29 ` Jean Delvare
2008-07-08 13:38 ` Wolfgang Grandegger
2008-07-11 12:40 ` Wolfgang Grandegger
2008-07-11 12:56 ` Jean Delvare
2008-07-16 9:12 ` Wolfgang Grandegger [this message]
2008-07-16 9:12 ` Wolfgang Grandegger
2008-07-16 9:33 ` Jean Delvare
2008-07-16 9:33 ` Jean Delvare
2008-07-16 9:50 ` [lm-sensors] " Wolfgang Grandegger
2008-07-16 9:50 ` Wolfgang Grandegger
2008-07-16 10:10 ` [lm-sensors] " Jean Delvare
2008-07-16 10:10 ` Jean Delvare
2008-07-16 10:23 ` [lm-sensors] " Wolfgang Grandegger
2008-07-16 10:23 ` Wolfgang Grandegger
2008-07-16 14:08 ` [lm-sensors] " Grant Likely
2008-07-16 14:08 ` Grant Likely
2008-07-16 14:18 ` [lm-sensors] " Jon Smirl
2008-07-16 14:18 ` Jon Smirl
2008-07-16 14:29 ` [lm-sensors] " Jean Delvare
2008-07-16 14:29 ` Jean Delvare
2008-07-17 7:31 ` [lm-sensors] " Wolfgang Grandegger
2008-07-17 7:31 ` Wolfgang Grandegger
2008-07-17 7:33 ` [lm-sensors] " Grant Likely
2008-07-17 7:33 ` Grant Likely
2008-07-17 10:39 ` [lm-sensors] " Wolfgang Grandegger
2008-07-17 10:39 ` Wolfgang Grandegger
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=487DBB92.1070100@grandegger.com \
--to=wg@grandegger.com \
--cc=Linuxppc-dev@ozlabs.org \
--cc=alanc@pipstechnology.co.uk \
--cc=dzu@denx.de \
--cc=khali@linux-fr.org \
--cc=lm-sensors@lm-sensors.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.