i2c-yosemite

i2c-yosemite

[Jean Delvare]

Hi Manish,

I saw that there is a new driver named i2c-yosemite in Linux 2.6.3-mm2.
Quoting your words in the header:

"Currently, this Linux driver wont be integrated into the generic Linux
I2C framework."

Why that?

If everyone reimplements what already exists, the kernel is likely to go
bigger with no benefit. Also, you won't be able to use all user-space
tools that already exist, and will also have to write specific chip
drivers for the chips present on the yosemite bus, although these
drivers (Atmel 24C32 EEPROM and MAX 1619) already exist.

Please explain to us why you cannot/don't want to use the existing i2c
subsystem.

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Re: i2c-yosemite

[Christoph Hellwig]

On Sun, Feb 22, 2004 at 10:41:06AM +0100, Jean Delvare wrote:
> If everyone reimplements what already exists, the kernel is likely to go
> bigger with no benefit. Also, you won't be able to use all user-space
> tools that already exist, and will also have to write specific chip
> drivers for the chips present on the yosemite bus, although these
> drivers (Atmel 24C32 EEPROM and MAX 1619) already exist.
> 
> Please explain to us why you cannot/don't want to use the existing i2c
> subsystem.

Yupp.  While we're at it what should we do with the i2c reimplementations
in alsa and dvb?

Re: i2c-yosemite

[Michael Hunold]

Hello,

On 22.02.2004 11:30, Christoph Hellwig wrote:
> On Sun, Feb 22, 2004 at 10:41:06AM +0100, Jean Delvare wrote:
> 
>>If everyone reimplements what already exists, the kernel is likely to go
>>bigger with no benefit. Also, you won't be able to use all user-space
>>tools that already exist,

Agreed.

>>Please explain to us why you cannot/don't want to use the existing i2c
>>subsystem.

> Yupp.  While we're at it what should we do with the i2c reimplementations
> in alsa and dvb?

The current dvb "i2c" implementation is only about 10k straight-forward 
code. Besides the name, there isn't much code duplication, because 
essential stuff (for example struct i2c_msg) is already hijacked from i2c.h.

The problem with dvb i2c is, that the very first engineers didn't think 
of the bus as a general purpose bus, but more like "hey, we know what 
we're doing".

In former times when DVB wasn't in the kernel, we tried to use the 
in-kernel i2c subsystem. One problem was, that all kind of drivers tried 
to probe the DVB i2c busses, which really confused some i2c adapters. I 
admit that this has been solved lately with the newly introduced "usage 
ids".

There isn't much code duplication for the i2c helper chipsets drivers 
either, because it's very unlikely that you'll find them outside 
so-called DVB frontends.

The biggest problem is, however, that some of the used chipsets (mainly 
the demodulators) encapsulate all i2c traffic that has to go "beyond" 
them (mainly to the tuners). They have a thing called "i2c repeater" 
which has to be enabled and disabled by special i2c commands, sometimes 
in a magic fashion.

This is possible if you know exactly what i2c mesages you are sending, 
but the guy who wrote the code told me that he wasn't able to get it 
fully running with the kernel i2c system.

This might have changed in the past, but it hasn't been checked lately.

For the long term (ie. 2.7 and 2.8), we're planning to use kernel i2c 
again, but currently nobody dares to touch the code because it's running 
very stable.

CU
Michael.

RE: i2c-yosemite

[Manish Lachwani]

Hi Jean

Couple of things. First of all, I did not have an idea that a driver existed for Atmel 24C32 EEPROM. In case of the Yosemite chip, the MAC address of the Gigabit subsystem is stored in the EEPROM. It needs to be fetched by the Gige driver using the I2C protocol. I could not find the driver in the 2.4 tree and hence wrote one for the yosemite. I could use the existing driver, which would make sense. 

Secondly, the reason why I mentioned:

"Currently, this Linux driver wont be integrated into the generic Linux
I2C framework."

is because at the time the driver was written, the chip did not exist. The idea was that once the chip is released and the driver tested, it could be checked in the generic i2c framework along with the driver for the MAX 1619 sensors chip. Now that the drivers already exist, I will use them instead. 

Thanks
Manish

-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org]
Sent: Sunday, February 22, 2004 1:41 AM
To: Manish Lachwani
Cc: LM Sensors; LKML; Greg KH
Subject: i2c-yosemite


Hi Manish,

I saw that there is a new driver named i2c-yosemite in Linux 2.6.3-mm2.
Quoting your words in the header:

"Currently, this Linux driver wont be integrated into the generic Linux
I2C framework."

Why that?

If everyone reimplements what already exists, the kernel is likely to go
bigger with no benefit. Also, you won't be able to use all user-space
tools that already exist, and will also have to write specific chip
drivers for the chips present on the yosemite bus, although these
drivers (Atmel 24C32 EEPROM and MAX 1619) already exist.

Please explain to us why you cannot/don't want to use the existing i2c
subsystem.

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Re: i2c-yosemite

[Jean Delvare]

> Couple of things. First of all, I did not have an idea that a driver
> existed for Atmel 24C32 EEPROM.

Actually, I read you a bit fast. I think our driver only supports 24C02
and 24C04, because 24C08 and bigger require 2-byte addressing.

> In case of the Yosemite chip, the MAC address of the Gigabit
> subsystem is stored in the EEPROM. It needs to be fetched by the Gige
> driver using the I2C protocol.

I didn't know about that. Funnily enough, a user reported today about a
strange EEPROM on his I2C bus, and it turns out that it holds a MAC
address (or at least it really looks like that).

> I could not find the driver in the 2.4 tree and hence wrote one for
> the yosemite. I could use the existing driver, which would make
> sense. 

The driver wasn't part of Linux 2.4 itself, because the lm_sensors
drivers were never integrated there. But they are in 2.6.

> The idea was that once the chip is released and the driver tested, it
> could be checked in the generic i2c framework along with the driver
> for the MAX 1619 sensors chip. Now that the drivers already exist, I
> will use them instead.

Aha, I read a bit too fast here too :/ We support the MAX1617(A), not
the MAX1619. That said, I took a look at the datasheet and the chips are
said to be very similar, so extending the driver should be quite
straightforward.

Anyway, the point isn't wether the exact drivers already exist or not.
The point is that using the existing i2c subsystem means that other
people needing support for similar chips will be able to use the same
drivers as you. This also means that all existing user-space tools will
work out-of-the-box, which is a great benefit IMHO.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/