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

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

[Yang Shi]

An EEPROM resides on 0x50 of I2C bus on CN56xx/57xx board,
register this device.

Signed-off-by: Yang Shi <yang.shi@windriver.com>
---
 arch/mips/cavium-octeon/octeon-platform.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/mips/cavium-octeon/octeon-platform.c b/arch/mips/cavium-octeon/octeon-platform.c
index 62ac30e..5bfa513 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -164,6 +164,9 @@ static struct i2c_board_info __initdata octeon_i2c_devices[] = {
 	{
 		I2C_BOARD_INFO("ds1337", 0x68),
 	},
+	{
+		I2C_BOARD_INFO("eeprom", 0x50),
+	},
 };
 
 static int __init octeon_i2c_devices_init(void)
-- 
1.6.3.3

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

> +	{
> +		I2C_BOARD_INFO("eeprom", 0x50),
> +	},

Is the use of 'eeprom' instead of 'at24' intentional?

Regards

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Yang Shi]

Wolfram Sang 写道:
>> +	{
>> +		I2C_BOARD_INFO("eeprom", 0x50),
>> +	},
>>     
>
> Is the use of 'eeprom' instead of 'at24' intentional?
>   

Unfortunately, at24 driver can't work on this board, I must use legacy
eeprom.

My config:

#CONFIG_EEPROM_AT24 is not set
CONFIG_EEPROM_LEGACY=y

Regards,
Yang

> Regards
>
>   

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

> > 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.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Yang Shi]

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.

Regards,
Yang

> Regards,
>
>    Wolfram
>
>   

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

[Jean Delvare]

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.

-- 
Jean Delvare

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

[Michael Lawnick]

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.

-- 
KR
Michael

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

[Yang Shi]

Hi guys,

Thanks for you guys kind advice. I think I find the cause. I coded a 
wrong eeprom type, "at24" can't work here, it should be "24c64". It 
works with AT24 eeprom driver, but I'm not sure if this is the right type.

So, a possible correct to the patch is that:

+{
+    I2C_BOARD_INFO("24c64",·0x50),
+},

Regards,
Yang

Michael Lawnick 写道:
> 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.
>
>   

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

[Jean Delvare]

On Fri, 05 Mar 2010 18:39:04 +0800, Yang Shi wrote:
> Hi guys,
> 
> Thanks for you guys kind advice. I think I find the cause. I coded a 
> wrong eeprom type, "at24" can't work here, it should be "24c64". It 
> works with AT24 eeprom driver, but I'm not sure if this is the right type.

Actually, "at24" can work but you have to provide extra parameters
detailing the size, page size etc. of the EEPROM. All the "24cXX" names
are shortcuts with predefined sizes.

> 
> So, a possible correct to the patch is that:
> 
> +{
> +    I2C_BOARD_INFO("24c64",·0x50),
> +},

Well, what EEPROM type do you have exactly? 24c64 is for 64 kbit (8
kByte) EEPROMs using 16-bit addressing. You must use the correct type,
otherwise the at24 driver will misbehave. I am a little surprised
because originally you went for "eeprom" which is not compatible with
"24c64" (8-bit vs. 16-bit addressing).

Also note that you may want to provide specific page size if you have
tight control over what hardware is used and you intend to write to the
EEPROM on a regular basis. The driver defaults to safe but slow
settings.

OTOH, if you do _not_ want to write to the EEPROM, you want to provide
the AT24_FLAG_READONLY flag.

-- 
Jean Delvare

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

[Yang Shi]

Jean Delvare 写道:
> Hi Michael,
>
> On Fri, 05 Mar 2010 12:17:14 +0100, Michael Lawnick wrote:
>   
>> Jean Delvare said the following:
>>     
>>> Well, what EEPROM type do you have exactly? 24c64 is for 64 kbit (8
>>> kByte) EEPROMs using 16-bit addressing. You must use the correct type,
>>> otherwise the at24 driver will misbehave. I am a little surprised
>>> because originally you went for "eeprom" which is not compatible with
>>> "24c64" (8-bit vs. 16-bit addressing).
>>>       
>> Furthermore this brings up another issue:
>> 0x50 typically is SPD-eeprom (DDR initialisation). Corrupting the
>> contents might make your board unbootable - and using a 16bit driver
>> instead of an 8-bit one can corrupt your contents already on
>> (positioned) reading!
>>     
>
> This is totally correct, but better said loud to the list and the
> original poster than only privately to me ;)
>   

Thanks a lot to point out this.

I double checked the manual, the eeprom is SPD of the DIMMs.

I will rework my patch, then send V2 soon.

Regards,
Yang