From: Guenter Roeck <linux@roeck-us.net> To: Wolfram Sang <wsa@the-dreams.de> Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters Date: Wed, 4 Feb 2015 16:26:30 -0800 [thread overview] Message-ID: <20150205002630.GA396@roeck-us.net> (raw) In-Reply-To: <20150204233516.GA1677@katana> On Thu, Feb 05, 2015 at 12:35:16AM +0100, Wolfram Sang wrote: > On Wed, Feb 04, 2015 at 11:08:19AM -0800, Guenter Roeck wrote: > > On Wed, Feb 04, 2015 at 06:47:23PM +0100, Wolfram Sang wrote: > > > > > > On Wed, Feb 04, 2015 at 08:23:37AM -0800, Guenter Roeck wrote: > > > > Large EEPROMS (24c32 and larger) require a two-byte data address > > > > instead of just a single byte. Implement support for such EEPROMs > > > > with SMBus commands. > > > > > > > > Support has limitations (reads are not multi-master safe) and is slow, > > > > but it works. Practical use is for a system with 24c32 connected to > > > > Intel 82801I (ICH9). > > > > > > Can't you simply use i2c-dev to access the EEPROM? In multi-master > > > environments, things can really go wrong, so I wouldn't like to add > > > something dangerous by default. Maybe with a module parameter named > > > "allow-multimaster-unsafe-access-to-large-eeproms-with-smbus" which is > > > default off. But I'd really prefer the i2c-dev solution. Hooking a 16bit > > > EEPROM to SMBus is daring, after all. SMBus is multi-master, too. > > > > > Hi Wolfram, > > > > At the same time multi-master access is quite rare. > > It should still work in those rare cases. A setup of an SoC, an EC > (those like to be masters, as well), and an EEPROM is not very far off. > It won't work if the 24c32 is connected to a controller which only supports SMBus transactions. Also, there is no problem if it is connected to a controller supporting direct i2c accesses. The only real solution is to not use an SMBus-only controller together with 24c32 or any similar chip in such situations. > > Also, many of the kernel's i2c drivers are not multi-master-access > > clean. In many cases that isn't even possible due to the chip > > architecture (a good example are chips with multiple 'pages', where > > the page address is set with one i2c command and the actual access > > occurs with subsequent commands). > > Huh, using i2c_transfer to ensure 'repeated start' between messages > should do the trick, no? Drivers doing this via SMBus calls are broken > and should be fixed. > That would require all those drivers to have two separate implementations, or to declare that any such chips must only be connected to controllers supporting direct i2c accesses. Both isn't really practical and defies the real world, where any kind of chip will be connected to SMBus-only controllers. A worse situation would occur if the chip specifically (only) supports SMBus transactions and thus doesn't explicitly support repeated start after completion of one transaction. This may or may not work depending on the chip or even chip revision, and it usually would not be specified as a valid transaction in the chip datasheet. Guenter
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org> To: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters Date: Wed, 4 Feb 2015 16:26:30 -0800 [thread overview] Message-ID: <20150205002630.GA396@roeck-us.net> (raw) In-Reply-To: <20150204233516.GA1677@katana> On Thu, Feb 05, 2015 at 12:35:16AM +0100, Wolfram Sang wrote: > On Wed, Feb 04, 2015 at 11:08:19AM -0800, Guenter Roeck wrote: > > On Wed, Feb 04, 2015 at 06:47:23PM +0100, Wolfram Sang wrote: > > > > > > On Wed, Feb 04, 2015 at 08:23:37AM -0800, Guenter Roeck wrote: > > > > Large EEPROMS (24c32 and larger) require a two-byte data address > > > > instead of just a single byte. Implement support for such EEPROMs > > > > with SMBus commands. > > > > > > > > Support has limitations (reads are not multi-master safe) and is slow, > > > > but it works. Practical use is for a system with 24c32 connected to > > > > Intel 82801I (ICH9). > > > > > > Can't you simply use i2c-dev to access the EEPROM? In multi-master > > > environments, things can really go wrong, so I wouldn't like to add > > > something dangerous by default. Maybe with a module parameter named > > > "allow-multimaster-unsafe-access-to-large-eeproms-with-smbus" which is > > > default off. But I'd really prefer the i2c-dev solution. Hooking a 16bit > > > EEPROM to SMBus is daring, after all. SMBus is multi-master, too. > > > > > Hi Wolfram, > > > > At the same time multi-master access is quite rare. > > It should still work in those rare cases. A setup of an SoC, an EC > (those like to be masters, as well), and an EEPROM is not very far off. > It won't work if the 24c32 is connected to a controller which only supports SMBus transactions. Also, there is no problem if it is connected to a controller supporting direct i2c accesses. The only real solution is to not use an SMBus-only controller together with 24c32 or any similar chip in such situations. > > Also, many of the kernel's i2c drivers are not multi-master-access > > clean. In many cases that isn't even possible due to the chip > > architecture (a good example are chips with multiple 'pages', where > > the page address is set with one i2c command and the actual access > > occurs with subsequent commands). > > Huh, using i2c_transfer to ensure 'repeated start' between messages > should do the trick, no? Drivers doing this via SMBus calls are broken > and should be fixed. > That would require all those drivers to have two separate implementations, or to declare that any such chips must only be connected to controllers supporting direct i2c accesses. Both isn't really practical and defies the real world, where any kind of chip will be connected to SMBus-only controllers. A worse situation would occur if the chip specifically (only) supports SMBus transactions and thus doesn't explicitly support repeated start after completion of one transaction. This may or may not work depending on the chip or even chip revision, and it usually would not be specified as a valid transaction in the chip datasheet. Guenter
next prev parent reply other threads:[~2015-02-05 0:26 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-04 16:23 [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters Guenter Roeck 2015-02-04 16:23 ` Guenter Roeck 2015-02-04 17:47 ` Wolfram Sang 2015-02-04 19:08 ` Guenter Roeck 2015-02-04 19:08 ` Guenter Roeck 2015-02-04 23:35 ` Wolfram Sang 2015-02-05 0:26 ` Guenter Roeck [this message] 2015-02-05 0:26 ` Guenter Roeck 2015-02-05 14:40 ` Wolfram Sang 2015-02-05 17:53 ` Guenter Roeck 2015-02-12 4:01 ` Guenter Roeck 2015-02-12 4:01 ` Guenter Roeck 2015-02-16 12:09 ` Wolfram Sang 2015-02-16 15:37 ` Guenter Roeck 2015-03-17 4:20 ` Guenter Roeck 2015-03-17 4:20 ` Guenter Roeck 2015-03-18 13:27 ` Wolfram Sang 2015-03-19 3:24 ` Guenter Roeck 2015-03-19 8:16 ` Wolfram Sang 2015-03-19 8:16 ` Wolfram Sang 2015-03-19 13:30 ` Guenter Roeck 2015-03-19 13:30 ` Guenter Roeck 2015-03-19 17:43 ` Guenter Roeck 2015-03-19 17:43 ` Guenter Roeck 2015-03-19 21:39 ` Wolfram Sang 2015-03-25 14:11 ` Guenter Roeck 2015-03-25 16:15 ` Wolfram Sang 2015-03-25 16:15 ` Wolfram Sang 2015-03-25 16:37 ` Guenter Roeck 2015-03-25 16:37 ` Guenter Roeck 2015-03-27 8:09 ` Wolfram Sang 2015-03-27 12:51 ` Guenter Roeck 2015-03-27 13:01 ` Wolfram Sang 2015-03-27 13:14 ` Guenter Roeck 2015-03-27 15:27 ` Wolfram Sang 2015-03-27 15:42 ` Guenter Roeck 2015-03-27 15:42 ` Guenter Roeck 2015-02-04 20:33 ` Guenter Roeck
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=20150205002630.GA396@roeck-us.net \ --to=linux@roeck-us.net \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=wsa@the-dreams.de \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.