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

[Yang Shi <yang.shi-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>]

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