linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: "Jean-François Dagenais"
	<jeff.dagenais-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>,
	lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org,
	wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org
Subject: Re: [lm-sensors] i2c multimaster and the device driver detect function
Date: Mon, 13 May 2013 10:11:50 +0200	[thread overview]
Message-ID: <20130513101150.0c9e4d30@endymion.delvare> (raw)
In-Reply-To: <3322BACE-9434-4249-8621-C1AD0D340A8A-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Salut Jean-François, hi Guenter,

Sorry for jumping in a little late, I am just back from vacation.

On Thu, 9 May 2013 08:38:28 -0400, Jean-François Dagenais wrote:
> On 2013-05-08, at 11:53 PM, Guenter Roeck wrote:
> > Is one of the I2C adapter drivers your own ? If so, you can disable auto-detection
> > in the adapter code by setting the adapter class to 0 (specifically, don't set it
> > to I2C_CLASS_HWMON). You can do the same in the Kontron driver if you have the
> > source (it is GPL so you should be able to find it). While not perfect, that should
> > be better than disabling auto-detection in the affected chip drivers.
> 
> That's great advice!! I will look into this, thanks!

Guenter is right. You never have to disable auto-detection in the slave
drivers (jc42 etc.) All these slave drivers do is claim "I _can_ do
auto-detection", not "I _will_ do auto-detection." It's always up to the
I2C adapter driver, whether auto-detection will happen or not. And it
is disabled by default. So if you don't want it, just do not enable it
in the bus driver. You can even set it per adapter, when the driver
controls more than one adapter, and per bus segment, when multiplexing
is taking place.

Please also note: the jc42 driver now uses I2C_CLASS_SPD not
I2C_CLASS_HWMON, because memory modules typically use a single chip for
SPD EEPROM and JEDEC JC42.2 temperature sensor. Think of I2C_CLASS_SPD
as "I2C class for memory modules."

> > Note that the Kontron driver also sets I2C_CLASS_SPD, which means EEPROMs are
> > auto-detected on address 0x50.
> 
> Funny, I had to explicitly inject "I2C_BOARD_INFO("24c32", 0x50)" to see
> Kontron's JIDA chip.

The only EEPROMs which are auto-detected are SPD and EDID EEPROMs. The
legacy eeprom driver is used for these. The 24C32 is a larger EEPROM,
you must use the at24 driver for it and it doesn't support
auto-detection (this is simply not possible.)

In the long run, the legacy eeprom driver could be killed, but not
before someone verifies that the at24 driver can take over completely,
including the auto-detection feature, performance optimizations and
corner case coverage.

> > (...)
> > Sure, it does work, I am just not sure what the benefits are of having two
> > masters in this scenario.
> 
> My thoughts exactly. I would have avoided it. Right now I am trying to improve
> and existing design.

It might be a little late now, but you may want to look into the
PCA9541, for which Guenter has written a driver.

-- 
Jean Delvare

  parent reply	other threads:[~2013-05-13  8:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130212164811.GV8668@pengutronix.de>
     [not found] ` <20130212164811.GV8668-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2013-05-08 15:57   ` i2c multimaster and the device driver detect function Jean-François Dagenais
     [not found]     ` <3D8D1B67-2846-4B78-B402-6B9FD1CB10E6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-05-08 17:54       ` [lm-sensors] " Guenter Roeck
     [not found]         ` <20130508175417.GB29689-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-05-09  1:50           ` Jean-François Dagenais
2013-05-09  3:53             ` Guenter Roeck
     [not found]               ` <20130509035313.GA26817-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2013-05-09 12:38                 ` [lm-sensors] " Jean-François Dagenais
     [not found]                   ` <3322BACE-9434-4249-8621-C1AD0D340A8A-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-05-09 13:30                     ` Guenter Roeck
2013-05-13  8:11                     ` Jean Delvare [this message]
     [not found]                       ` <20130513101150.0c9e4d30-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2013-05-13 13:54                         ` Jean-François Dagenais
     [not found]                           ` <E43DA0E6-A130-4837-8343-EEC182A12EE6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-05-13 14:14                             ` Jean Delvare
     [not found]                               ` <20130513161413.58ebc9e8-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2013-05-13 14:56                                 ` Guenter Roeck

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=20130513101150.0c9e4d30@endymion.delvare \
    --to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=jeff.dagenais-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).