1. 19 Apr, 2017 2 commits
  2. 16 Apr, 2017 7 commits
    • Wolfram Sang's avatar
      Merge branch 'i2c/for-INT33FE' into i2c/for-4.12 · c99a30d8
      Wolfram Sang authored
      Pull in the immutable branch with I2C ACPI core extensions to support
      the INT33FE driver.
      c99a30d8
    • Hans de Goede's avatar
      i2c: core: Allow drivers to disable i2c-core irq mapping · d1d84bb9
      Hans de Goede authored
      By default the i2c-core will try to get an irq with index 0 on ACPI / of
      instantiated devices. This is troublesome on some ACPI systems where the
      irq info at index 0 in the CRS table may contain nonsense and/or point
      to an irqchip for which there is no Linux driver.
      
      If this happens then before this commit the driver's probe method would
      never get called because i2c_device_probe will try to get an irq by
      calling acpi_dev_gpio_irq_get which will always return -EPROBE in this
      case, as it waits for a matching irqchip driver to load. Thus causing
      the driver to not get a chance to bind.
      
      This commit adds a new disable_i2c_core_irq_mapping flag to struct
      i2c_driver which a driver can set to tell the core to skip irq mapping.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      d1d84bb9
    • Hans de Goede's avatar
      i2c: core: Add new i2c_acpi_new_device helper function · 605f8fc2
      Hans de Goede authored
      By default the i2c subsys creates an i2c-client for the first I2cSerialBus
      resource of an acpi_device, but some acpi_devices have multiple
      I2cSerialBus resources and we may want to instantiate i2c-clients for
      the others.
      
      This commit adds a new i2c_acpi_new_device function which can be used to
      create an i2c-client for any I2cSerialBus resource of an acpi_device.
      
      Note that the other resources may even be on a different i2c bus, so just
      retrieving the client address is not enough.
      
      Here is an example DSDT excerpt from such a device:
      
      Device (WIDR)
      {
          Name (_HID, "INT33FE" /* XPOWER Battery Device */)
          Name (_CID, "INT33FE" /* XPOWER Battery Device */)
          Name (_DDN, "WC PMIC Battery Device")
      <snip>
          Name (RBUF, ResourceTemplate ()
          {
              I2cSerialBusV2 (0x005E, ControllerInitiated, 0x000186A0,
                  AddressingMode7Bit, "\\_SB.PCI0.I2C7",
                  0x00, ResourceConsumer, , Exclusive,
                  )
              I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
                  AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                  0x00, ResourceConsumer, , Exclusive,
                  )
              I2cSerialBusV2 (0x0022, ControllerInitiated, 0x00061A80,
                  AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                  0x00, ResourceConsumer, , Exclusive,
                  )
              I2cSerialBusV2 (0x0054, ControllerInitiated, 0x00061A80,
                  AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                  0x00, ResourceConsumer, , Exclusive,
                  )
              GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
                  "\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
                  )
                  {   // Pin list
              0x0012
                  }
              GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
                  "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                  )
                  {   // Pin list
              0x0005
                  }
              GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
                  "\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
                  )
                  {   // Pin list
              0x0013
                  }
          })
          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
          {
              Return (RBUF) /* \_SB_.PCI0.I2C7.WIDR.RBUF */
          }
      <snip>
      }
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      605f8fc2
    • Hans de Goede's avatar
      i2c: core: Allow getting ACPI info by index · 417f7843
      Hans de Goede authored
      Modify struct i2c_acpi_lookup and i2c_acpi_fill_info() to allow
      using them to get the info from a certain index in the ACPI-resource
      list rather then taking the first I2cSerialBus resource.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      417f7843
    • Geliang Tang's avatar
      i2c: img-scb: use setup_timer · 879bce22
      Geliang Tang authored
      Use setup_timer() instead of init_timer() to simplify the code.
      Signed-off-by: default avatarGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      879bce22
    • Edgar Cherkasov's avatar
      i2c: i2c-scmi: add a MS HID · e058e7a4
      Edgar Cherkasov authored
      Description of the problem:
       - i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM";
       - the fist HID (SMBUS01) is clearly defined in "SMBus Control Method
         Interface Specification, version 1.0": "Each device must specify
         'SMBUS01' as its _HID and use a unique _UID value";
       - unfortunately, BIOS vendors (like AMI) seem to ignore this requirement
         and implement "SMB0001" HID instead of "SMBUS01";
       - I speculate that they do this because only "SMB0001" is hard coded in
         Windows SMBus driver produced by Microsoft.
      
      This leads to following situation:
       - SMBus works out of box in Windows but not in Linux;
       - board vendors are forced to add correct "SMBUS01" HID to BIOS to make
         SMBus work in Linux. Moreover the same board vendors complain that
         tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier
         and produce errors.  So they need to constantly patch the compiler for
         each new version of BIOS.
      
      As it is very unlikely that BIOS vendors implement a correct HID in
      future, I would propose to consider whether it is possible to work around
      the problem by adding MS HID to the Linux i2c-scmi driver.
      
      v2: move the definition of the new HID to the driver itself.
      Signed-off-by: default avatarEdgar Cherkasov <echerkasov@dev.rtsoft.ru>
      Signed-off-by: default avatarMichael Brunner <Michael.Brunner@kontron.com>
      Acked-by: default avatarViktor Krasnov <vkrasnov@dev.rtsoft.ru>
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      e058e7a4
    • Wolfram Sang's avatar
      Merge branch 'i2c-mux/for-next' of https://github.com/peda-r/i2c-mux into i2c/for-4.12 · 69e620f8
      Wolfram Sang authored
      Pull in changes from the i2c-mux subsubsystem:
      
      "Here are a new LTC4306/5 driver, a fix needed by the RT kernel and some
      error message cleanup."
      69e620f8
  3. 12 Apr, 2017 2 commits
  4. 03 Apr, 2017 7 commits
  5. 30 Mar, 2017 10 commits
  6. 23 Mar, 2017 4 commits
  7. 22 Mar, 2017 5 commits
  8. 20 Mar, 2017 3 commits