All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.