Eric Lee / smarc-fsl-linux-kernel

26 Aug, 2016

1 commit

  • b2d57b560   i2c: mux: add support for 'i2c-mux', 'i2c-arb' and 'i2c-gate' DT subnodes ... Browse Code »

    Backwards compatibility is preserved; the subnodes are in practice
    optional.

    However, the mux core needs to know what subnode it should examine, so add
    a couple of new flags for i2c_mux_alloc for this purpose.

    The rule is that if the mux core finds a 'reg' property in the appropriate
    subnode, e.g. if 'reg' exists in the 'i2c-mux' subnode, then the mux core
    will assume that this is an old style entry and not an i2c-mux subnode
    (correspondingly for arbitrators and gates with 'i2c-arb' and 'i2c-gate').

    Reviewed-by: Wolfram Sang
    Signed-off-by: Peter Rosin

    Peter Rosin
     

05 May, 2016

1 commit

  • 6ef91fcca   i2c: mux: relax locking of the top i2c adapter during mux-locked muxing ... Browse Code »

    With a i2c topology like the following

    GPIO ---| ------ BAT1
    | v /
    I2C -----+----------+---- MUX
    | \
    EEPROM ------ BAT2

    there is a locking problem with the GPIO controller since it is a client
    on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1)
    will lock the whole i2c bus prior to attempting to switch the mux to the
    correct i2c segment. In the above case, the GPIO device is an I/O expander
    with an i2c interface, and since the GPIO subsystem knows nothing (and
    rightfully so) about the lockless needs of the i2c mux code, this results
    in a deadlock when the GPIO driver issues i2c transfers to modify the
    mux.

    So, observing that while it is needed to have the i2c bus locked during the
    actual MUX update in order to avoid random garbage on the slave side, it
    is not strictly a must to have it locked over the whole sequence of a full
    select-transfer-deselect mux client operation. The mux itself needs to be
    locked, so transfers to clients behind the mux are serialized, and the mux
    needs to be stable during all i2c traffic (otherwise individual mux slave
    segments might see garbage, or worse).

    Introduce this new locking concept as "mux-locked" muxes, and call the
    pre-existing mux locking scheme "parent-locked".

    Modify the i2c mux locking so that muxes that are "mux-locked" locks only
    the muxes on the parent adapter instead of the whole i2c bus when there is
    a transfer to the slave side of the mux. This lock serializes transfers to
    the slave side of the muxes on the parent adapter.

    Add code to i2c-mux-gpio and i2c-mux-pinctrl that checks if all involved
    gpio/pinctrl devices have a parent that is an i2c adapter in the same
    adapter tree that is muxed, and request a "mux-locked mux" if that is the
    case.

    Modify the select-transfer-deselect code for "mux-locked" muxes so
    that each of the select-transfer-deselect ops locks the mux parent
    adapter individually.

    Signed-off-by: Peter Rosin
    Signed-off-by: Wolfram Sang

    Peter Rosin
     

22 Apr, 2016

2 commits

  • 23fe440c5   i2c: mux: drop old unused i2c-mux api ... Browse Code »

    All i2c mux users are using an explicit i2c mux core, drop support
    for implicit i2c mux cores.

    Signed-off-by: Peter Rosin
    Signed-off-by: Wolfram Sang

    Peter Rosin
     
  • a7ab72390   i2c: mux: add common data for every i2c-mux instance ... Browse Code »

    All i2c-muxes have a parent adapter and one or many child
    adapters. A mux also has some means of selection. Previously,
    this was stored per child adapter, but it is only needed
    to keep track of this per mux.

    Add an i2c mux core, that keeps track of this consistently.

    Also add some glue for users of the old interface, which will
    create one implicit mux core per child adapter.

    Signed-off-by: Peter Rosin
    Tested-by: Antti Palosaari
    Tested-by: Crestez Dan Leonard
    Signed-off-by: Wolfram Sang

    Peter Rosin
     

02 Apr, 2013

1 commit

  • 51d95709d   i2c: Make the return type of i2c_del_mux_adapter() void ... Browse Code »

    i2c_del_mux_adapter always returns 0 and none of it current users check its
    return value anyway. It is also an essential requirement of the Linux device
    driver model, that functions which may be called from a device's remove callback
    to free resources provided by the device, are not allowed to fail. This is the
    case for i2c_del_mux_adapter(), so make its return type void to make the
    fact that it won't fail explicit.

    Signed-off-by: Lars-Peter Clausen
    Reviewed-by: Jean Delvare
    Signed-off-by: Wolfram Sang

    Lars-Peter Clausen
     

06 Oct, 2012

1 commit

  • eee543e82   i2c-mux: Add support for device auto-detection ... Browse Code »

    Let I2C bus segments behind multiplexers have a class. This allows for
    device auto-detection on these segments. As long as parent segments
    don't share the same class, it should be fine.

    I implemented support in drivers i2c-mux-gpio and i2c-mux-pca954x. I
    left i2c-mux-pca9541 and i2c-mux-pinctrl alone for the moment as I
    don't know if this feature makes sense for the use cases of these
    drivers.

    Signed-off-by: Jean Delvare
    Cc: Peter Korsgaard
    Cc: David Daney
    Cc: Michael Lawnick
    Cc: Rodolfo Giometti

    Jean Delvare
     

12 May, 2012

1 commit

27 Mar, 2012

1 commit

12 Aug, 2010

1 commit