[Top] [All Lists]

Re: [PATCH] MIPS: Octeon: Register EEPROM device on the I2C bus

To: Jean Delvare <>
Subject: Re: [PATCH] MIPS: Octeon: Register EEPROM device on the I2C bus
From: Michael Lawnick <>
Date: Fri, 05 Mar 2010 11:09:34 +0100
Cc: Yang Shi <>, Wolfram Sang <>,,,,,, Konstantin Lazarev <>
In-reply-to: <20100305095040.6ab4612c@hyperion.delvare>
Original-recipient: rfc822;
References: <> <> <> <> <> <20100305095040.6ab4612c@hyperion.delvare>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
Jean Delvare said the following:
> Hi Yang, Wolfram,
> On Fri, 05 Mar 2010 15:53:44 +0800, Yang Shi wrote:
>> Wolfram Sang 写道:
>> >>> Is the use of 'eeprom' instead of 'at24' intentional?
>> >>>   
>> >>>       
>> >> Unfortunately, at24 driver can't work on this board, I must use legacy
>> >> eeprom.
>> >>     
>> >
>> > Well, you are of course free to choose here :)
>> >
>> > I'd just be interested if there is a software limitation which prevents 
>> > you from
>> > using AT24. Because, it _should_ work with all kind of eeproms the legacy 
>> > driver
>> > deals with. Otherwise it is probably a bug which needs to be fixed.
>> >   
>> Thanks to point out this. Let me take a look at this.
> One limitation of the at24 driver is that it needs the underlying
> controller to support either raw I2C access or at least I2C block
> transactions. Konstantin Lazarev complained about that one month ago
> already.
> I am currently working on improving the at24 driver so that it falls
> back to byte transactions when block transactions are not available. I
> might also add word transaction support (as the eeprom driver has) as
> it is often the best performance/compatibility trade-off. I'll post the
> patch when I'm done.
> I'm not yet sure what will happen to the legacy eeprom driver in the
> long run, but I would prefer new designs to not rely on it.

If I don't get all wrong, my 2 Cents:
i2c-octeon will/should be based on raw i2c from kernel version .34 on.
(my patch :-) ) So it should support all transfer modes that i2c can.
Currently it is limited to 8 bytes per transaction.

If I misunderstood something, please ignore the noise.


<Prev in Thread] Current Thread [Next in Thread>