From: Michael Lawnick <ml.lawnick@gmx.de>
To: Jean Delvare <khali@linux-fr.org>
Cc: Yang Shi <yang.shi@windriver.com>,
Wolfram Sang <w.sang@pengutronix.de>,
ddaney@caviumnetworks.com, ben-linux@fluff.org,
ralf@linux-mips.org, linux-mips@linux-mips.org,
linux-i2c@vger.kernel.org,
Konstantin Lazarev <klazarev@sbcglobal.net>
Subject: Re: [PATCH] MIPS: Octeon: Register EEPROM device on the I2C bus
Date: Fri, 05 Mar 2010 11:09:34 +0100 [thread overview]
Message-ID: <4B90D85E.6040308@gmx.de> (raw)
In-Reply-To: <20100305095040.6ab4612c@hyperion.delvare>
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
next prev parent reply other threads:[~2010-03-05 10:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-05 7:08 [PATCH] MIPS: Octeon: Register EEPROM device on the I2C bus Yang Shi
2010-03-05 7:11 ` Wolfram Sang
2010-03-05 7:31 ` Yang Shi
2010-03-05 7:41 ` Wolfram Sang
2010-03-05 7:53 ` Yang Shi
2010-03-05 8:50 ` Jean Delvare
2010-03-05 10:09 ` Michael Lawnick [this message]
2010-03-05 10:39 ` Yang Shi
2010-03-05 10:52 ` Jean Delvare
[not found] ` <4B90E83A.5020106@gmx.de>
[not found] ` <20100305124200.6f6eccfc@hyperion.delvare>
2010-03-08 4:43 ` Yang Shi
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=4B90D85E.6040308@gmx.de \
--to=ml.lawnick@gmx.de \
--cc=ben-linux@fluff.org \
--cc=ddaney@caviumnetworks.com \
--cc=khali@linux-fr.org \
--cc=klazarev@sbcglobal.net \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=w.sang@pengutronix.de \
--cc=yang.shi@windriver.com \
/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).