An error occurred fetching the project authors.
  1. 24 Aug, 2018 1 commit
  2. 17 Aug, 2018 2 commits
  3. 16 Aug, 2018 1 commit
  4. 14 Aug, 2018 1 commit
  5. 11 Aug, 2018 1 commit
  6. 09 Aug, 2018 1 commit
    • Hans de Goede's avatar
      platform/x86: Add ACPI i2c-multi-instantiate pseudo driver · e64e8498
      Hans de Goede authored
      On systems with ACPI instantiated i2c-clients, normally there is 1 fw_node
      per i2c-device and that fw-node contains 1 I2cSerialBus resource for that 1
      i2c-device.
      
      But in some rare cases the manufacturer has decided to describe multiple
      i2c-devices in a single ACPI fwnode with multiple I2cSerialBus resources.
      
      An earlier attempt to fix this in the i2c-core resulted in a lot of extra
      code to support this corner-case.
      
      This commit introduces a new i2c-multi-instantiate driver which fixes this
      in a different way. This new driver can be built as a module which will
      only loaded on affected systems.
      
      This driver will instantiate a new i2c-client per I2cSerialBus resource,
      using the driver_data from the acpi_device_id it is binding to to tell it
      which chip-type (and optional irq-resource) to use when instantiating.
      
      Note this driver depends on a platform device being instantiated for the
      ACPI fwnode, see the i2c_multi_instantiate_ids list of ACPI device-ids in
      drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
      Acked-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e64e8498
  7. 08 Aug, 2018 1 commit
  8. 07 Aug, 2018 1 commit
  9. 02 Aug, 2018 4 commits
  10. 01 Aug, 2018 2 commits
  11. 31 Jul, 2018 2 commits
  12. 30 Jul, 2018 1 commit
  13. 27 Jul, 2018 3 commits
  14. 26 Jul, 2018 1 commit
  15. 25 Jul, 2018 5 commits
  16. 24 Jul, 2018 3 commits
  17. 23 Jul, 2018 2 commits
  18. 21 Jul, 2018 1 commit
  19. 20 Jul, 2018 3 commits
  20. 19 Jul, 2018 1 commit
  21. 18 Jul, 2018 3 commits
    • Krzysztof Kozlowski's avatar
      MAINTAINERS: Drop inactive Vitaly Bordug's email · a2ec9d14
      Krzysztof Kozlowski authored
      The Vitaly Bordug's email bounces ("ru.mvista.com: Name or service not
      known") and there was no activity (ack, review, sign) since 2009.
      
      Cc: Vitaly Bordug <vitb@kernel.crashing.org>
      Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2ec9d14
    • Nishanth Menon's avatar
      arm64: dts: ti: Add support for AM654 EVM base board · d0a064be
      Nishanth Menon authored
      The EValuation Module(EVM) platform for AM654 consists of a
      common Base board + one or more of daughter cards, which include:
      a) "Personality Modules", which can be specific to a profile, such as
       ICSSG enabled or Multi-media (including audio).
      b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
      c) Camera daughter card
      d) various display panels
      
      Among other options. There are two basic configurations defined which
      include an "EVM" configuration and "IDK" (Industrial development kit)
      which differ in the specific combination of daughter cards that are
      used.
      
      To simplify support, we choose to support just the base board as the
      core device tree file and all daughter cards would be expected to be
      device tree overlays.
      Reviewed-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      d0a064be
    • Nishanth Menon's avatar
      arm64: dts: ti: Add Support for AM654 SoC · ea47eed3
      Nishanth Menon authored
      The AM654 SoC is a lead device of the K3 Multicore SoC architecture
      platform, targeted for broad market and industrial control with aim to
      meet the complex processing needs of modern embedded products.
      
      Some highlights of this SoC are:
      * Quad ARMv8 A53 cores split over two clusters
      * GICv3 compliant GIC500
      * Configurable L3 Cache and IO-coherent architecture
      * Dual lock-step capable R5F uC for safety-critical applications
      * High data throughput capable distributed DMA architecture under NAVSS
      * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
        PRUs and dual RTUs
      * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
      * Centralized System Controller for Security, Power, and Resource
        management.
      * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
      * Flash subsystem with OSPI and Hyperbus interfaces
      * Multimedia capability with CAL, DSS7-UL, SGX544, McASP
      * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
        GPIO
      
      See AM65x Technical Reference Manual (SPRUID7, April 2018)
      for further details: http://www.ti.com/lit/pdf/spruid7
      
      NOTE:
      1. AM654 is the first of the device variants, hence we introduce a
         generic am65.dtsi.
      2. We indicate the proper bus topology, the ranges are elaborated in
         each bus segment instead of using the top level ranges to make sure
         that peripherals in each segment use the address space accurately.
      3. Peripherals in each bus segment is maintained in a separate dtsi
         allowing for reuse in different bus segment representation from a
         different core such as R5. This is also the reason for maintaining a
         1-1 address map in the ranges.
      4. Cache descriptions follow the ARM64 standard description.
      
      Further tweaks may be necessary as we introduce more complex devices,
      but can be introduced in context of the device introduction.
      Reviewed-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarBenjamin Fair <b-fair@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      ea47eed3