From: Jean Delvare <jdelvare@suse.de>
To: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: Linux I2C <linux-i2c@vger.kernel.org>,
Seth Heasley <seth.heasley@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: i2c-i801 partially broken on Lynx Point PCH?
Date: Thu, 19 May 2016 13:29:33 +0200 [thread overview]
Message-ID: <20160519132933.1202b6be@endymion> (raw)
In-Reply-To: <573D9D61.5070500@linux.intel.com>
Hi Jarkko,
On Thu, 19 May 2016 14:02:57 +0300, Jarkko Nikula wrote:
> On 18.05.2016 16:20, Jean Delvare wrote:
>
> > If anyone can think of any better solution, please let me know.
>
> I had an offline chat with Mika and although we didn't figure out any
> additional solution we were thinking what would be the practical penalty
> if we drop the block read when write protection is enabled? I mean if
> SMBUS connected EEPROMs are small like 256 bytes or so does the effect
> doing smaller reads get noticeable?
Reading one SPD EEPROM takes 33 ms using I2C Block reads and 81 ms
using Word reads (to which the eeprom and at24 drivers will fall back.)
Large machines can have 16 memory slots and as many SPD EEPROMs. On
such a machine, without I2C Block read support, decode-dimms would take
1.3 second instead of 0.5 second. So while this isn't the end of the
world, it will be noticeable, which is why I'd rather avoid it if
possible.
Also note that it could penalize other devices on the SMBus
("grep -r I2C_FUNC_SMBUS_READ_I2C_BLOCK drivers" will show you a list
of affected drivers) unless we implement a per-slave-address
functionality callback. That's possible and not difficult but would
make Wolfram sad ;-)
> > 4* It could be that the sentence in the datasheet that claims the slave
> > address register bit 0 must be set to 0 (write) for I2C Block Reads
> > is a left-over from previous incarnations of the chipset, and this no
> > longer holds true today. Out of curiosity I tried setting bit 0 to 1
> > (as it should normally be for a read) and it seems to work just
> > fine. And then it is no longer affected by the SPD write protection
> > mechanism. However I don't know if there is any problem or negative
> > side effect I may have missed.
> >
> > Mika/Jarkko, can you check with your hardware guys if that statement on
> > page 215 still holds for 8-Series/C220 and later?
> >
> We'll ping around.
Great, thank you.
--
Jean Delvare
SUSE L3 Support
prev parent reply other threads:[~2016-05-19 11:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-11 7:34 i2c-i801 partially broken on Lynx Point PCH? Jean Delvare
2016-05-11 8:43 ` Jean Delvare
2016-05-11 16:15 ` Heasley, Seth
2016-05-11 17:34 ` Jean Delvare
2016-05-11 17:46 ` Heasley, Seth
2016-05-18 12:05 ` Jean Delvare
2016-05-18 13:02 ` Wolfram Sang
2016-05-18 13:20 ` Jean Delvare
2016-05-19 11:02 ` Jarkko Nikula
2016-05-19 11:29 ` Jean Delvare [this message]
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=20160519132933.1202b6be@endymion \
--to=jdelvare@suse.de \
--cc=jarkko.nikula@linux.intel.com \
--cc=linux-i2c@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=seth.heasley@intel.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).