Re: I2C block reads with i2c-viapro: testers wanted

From: Jean Delvare (khali_at_linux-fr.org)
Date: 08/11/05

  • Next message: Sonny Rao: "lpfc driver in 2.6.13-rc6 broken on ppc64 ?"
    Date:	Thu, 11 Aug 2005 21:59:29 +0200
    To: Krzysztof Halasa <khc@pm.waw.pl>
    
    

    Hi Krzysztof,

    > Forgive my ignorance, but does it depend on the south bridge at all?
    > Isn't the block read capability just a function of EEPROM chip on
    > (I assume) RAM module?

    EEPROMs can be read using three different access modes: data byte reads
    (each transaction asks for one byte at a given offset), continuous byte
    reads (first transaction sets offset to 0, each subsequent transaction
    reads one byte and the offset auto-increments), and I2C block reads (one
    single transaction sets the initial offset and reads the whole block
    [1]).

    Now, just because most EEPROMs support these three modes doesn't mean
    you can always use them. It depends on which bus the EEPROM is sitting
    on, and which driver is used to control that bus.

    If the bus is a true I2C bus, most of which are known as bit-banging and
    are driven by the i2c-algo-bit driver, then all three types of accesses
    will work, and we'll use I2C block reads because it's faster. However,
    EEPROMs are also often found on SMBus busses, those controller only
    implement a subset of all possible I2C commands. Where this subset
    includes I2C block reads, we can implement it in the driver and use it.
    This is exactly what I am doing with i2c-viapro right now.

    More generally, for an I2C/SMBus command to be usable, both the target
    chip and the bus controller must support it, and the bus controller
    driver must implement it.

    I hope it's clearer now :)

    [1] Due to an internal limitation in the Linux kernel, the maximum block
    size that can be read is actually 32 bytes, so several block reads are
    needed to retrieve larger chunks of data.

    -- 
    Jean Delvare
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Sonny Rao: "lpfc driver in 2.6.13-rc6 broken on ppc64 ?"

    Relevant Pages

    • EEPROMs
      ... These EEPROMs and flash parts are connected in various ... drivers to talk to many of them for at least experimental purposes. ... AT45DB642, for example, lives on either a SPI bus or a parallel bus). ...
      (freebsd-arch)
    • [PATCH] I2C: New max6875 driver may corrupt EEPROMs
      ... New max6875 driver may corrupt EEPROMs ... data write operation, but for a standard EEPROM, this instead means ...
      (Linux-Kernel)
    • EEPROM infrastructure (was: [PATCH] eeprom_93cx6: Add write support)
      ... this also moves some duplicate code into seperate functions. ... it per driver or subsystem. ... On embedded platforms these EEPROMs ...
      (Linux-Kernel)
    • Re: [PATCH] I2C patches for 2.6.10
      ... While working on EEPROMs, DDC/EDID and the like these last few days, I ... wanted to use your i2c-stub driver to test my code. ... -types of SMBus commands: write quick, (r/w) byte data, and word data. ...
      (Linux-Kernel)
    • Re: checksum in (i2c) eeprom driver
      ... DDC monitor EEPROMs *are* EEPROMs so there is no reason to exclude them ... We used to have a specific driver for these ... There are not that many non-EEPROMs chips in the 0x50-0x57 range, ...
      (Linux-Kernel)