Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 4月, 2022 1 次提交
  3. 25 4月, 2022 1 次提交
    • 周
      spi: ingenic: Add support for new Ingenic SoCs. · 6d72b114
      由 周琰杰 (Zhou Yanjie) 提交于 
      1.Since it would be dangerous to specify a newer SoC's compatible
  string as the fallback of an older SoC's compatible string, we
  add support for the "ingenic,jz4775-spi" compatible string in
  the driver.

  This will permit to support the JZ4775 by having:
  compatible = "ingenic,jz4775-spi";

  Instead of doing:
  compatible = "ingenic,jz4775-spi", "ingenic,jz4780-spi";

2.Add support for probing the spi-ingenic driver on the X1000 SoC
  from Ingenic. From the X1000 SoC onwards, the maximum frequency
  allowed by the SSI module of Ingenic SoCs has been changed from
  54MHz to 50MHz. So "max_speed_hz" is introduced in "jz_soc_info"
  to set different maximum frequency values.

3.Add support for probing the spi-ingenic driver on the X2000 SoC
  from Ingenic. The X2000 SoC has only one native chip select line,
  so "max_native_cs" is introduced in "jz_soc_info" to set different
  maximum number of native chip select lines.

4.Because of the introduction of support for the X-series SoCs, the
  current driver is not only applicable to the JZ-series SoCs, so
  the description texts has been modified to avoid misunderstanding.
Signed-off-by: N周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Reviewed-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/1650724725-93758-4-git-send-email-zhouyanjie@wanyeetech.comSigned-off-by: NMark Brown <broonie@kernel.org>
      6d72b114
  5. 14 2月, 2022 1 次提交
  7. 10 2月, 2022 1 次提交
  9. 25 1月, 2022 1 次提交
  11. 15 11月, 2021 1 次提交
  13. 27 9月, 2021 2 次提交
  15. 13 9月, 2021 1 次提交
  17. 17 8月, 2021 1 次提交
  19. 04 6月, 2021 1 次提交
  21. 28 4月, 2021 1 次提交
  23. 21 4月, 2021 2 次提交
  25. 01 4月, 2021 1 次提交
  27. 22 1月, 2021 1 次提交
  29. 20 1月, 2021 1 次提交
    • A
      ARM: remove u300 platform · ce1380c9
      由 Arnd Bergmann 提交于 
      The Ericsson U300 platform was one of two ARM929 based SoC platforms for
mobile phones in ST-Ericsson after the merger of Ericsson with ST-NXP
into ST-Ericsson, the other one being the ST Nomadik.

The platform was not widely adopted in Linux based systems and was
replaced with the far superior ST-Ericsson U8500 in 2011, but Linus
Walleij kept maintaining the code for the whole time.

Linus continues to use the Nomadik machine, but decided to drop
u300 from the kernel as part of this year's spring cleaning.
Thanks for having maintained it all these years.

Cc: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/lkml/CACRpkdbJkiHR9FSfJTH_5d_qRU1__dRXHM1TL40iqNRKbGQfrQ@mail.gmail.com/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      ce1380c9
  31. 16 1月, 2021 1 次提交
  33. 13 1月, 2021 1 次提交
  35. 06 1月, 2021 1 次提交
  37. 05 1月, 2021 1 次提交
  39. 04 1月, 2021 1 次提交
  41. 27 11月, 2020 1 次提交
  43. 17 11月, 2020 1 次提交
  45. 09 10月, 2020 2 次提交
    • S
      spi: dw: Add Baikal-T1 SPI Controller glue driver · abf00907
      由 Serge Semin 提交于 
      Baikal-T1 is equipped with three DW APB SSI-based MMIO SPI controllers.
Two of them are pretty much normal: with IRQ, DMA, FIFOs of 64 words
depth, 4x CSs, but the third one as being a part of the Baikal-T1 System
Boot Controller has got a very limited resources: no IRQ, no DMA, only a
single native chip-select and Tx/Rx FIFO with just 8 words depth
available. In order to provide a transparent initial boot code execution
the Boot SPI controller is also utilized by an vendor-specific IP-block,
which exposes an SPI flash direct mapping interface. Since both direct
mapping and SPI controller normal utilization are mutual exclusive only
one of these interfaces can be used to access an external SPI slave
device. That's why a dedicated mux is embedded into the System Boot
Controller. All of that is taken into account in the Baikal-T1-specific DW
APB SSI glue driver implemented by means of the DW SPI core module.
Co-developed-by: NRamil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Signed-off-by: NRamil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-22-Sergey.Semin@baikalelectronics.ruSigned-off-by: NMark Brown <broonie@kernel.org>
      abf00907
    • S
      spi: dw: Add memory operations support · 6423207e
      由 Serge Semin 提交于 
      Aside from the synchronous Tx-Rx mode, which has been utilized to create
the normal SPI transfers in the framework of the DW SSI driver, DW SPI
controller supports Tx-only and EEPROM-read modes. The former one just
enables the controller to transmit all the data from the Tx FIFO ignoring
anything retrieved from the MISO lane. The later mode is so called
write-then-read operation: DW SPI controller first pushes out all the data
from the Tx FIFO, after that it'll automatically receive as much data as
has been specified by means of the CTRLR1 register. Both of those modes
can be used to implement the memory operations supported by the SPI-memory
subsystem.

The memory operation implementation is pretty much straightforward, except
a few peculiarities we have had to take into account to make things
working. Since DW SPI controller doesn't provide a way to directly set and
clear the native CS lane level, but instead automatically de-asserts it
when a transfer going on, we have to make sure the Tx FIFO isn't empty
during entire Tx procedure. In addition we also need to read data from the
Rx FIFO as fast as possible to prevent it' overflow with automatically
fetched incoming traffic. The denoted peculiarities get to cause even more
problems if DW SSI controller is equipped with relatively small FIFO and
is connected to a relatively slow system bus (APB) (with respect to the
SPI bus speed). In order to workaround the problems for as much as it's
possible, the memory operation execution procedure collects all the Tx
data into a single buffer and disables the local IRQs to speed the
write-then-optionally-read method up.

Note the provided memory operations are utilized by default only if
a glue driver hasn't provided a custom version of ones and this is not
a DW APB SSI controller with fixed automatic CS toggle functionality.
Co-developed-by: NRamil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Signed-off-by: NRamil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ruSigned-off-by: NMark Brown <broonie@kernel.org>
      6423207e
  47. 08 9月, 2020 1 次提交
  49. 20 8月, 2020 1 次提交
  51. 03 8月, 2020 1 次提交
    • L
      spi: Prevent adding devices below an unregistering controller · ddf75be4
      由 Lukas Wunner 提交于 
      CONFIG_OF_DYNAMIC and CONFIG_ACPI allow adding SPI devices at runtime
using a DeviceTree overlay or DSDT patch.  CONFIG_SPI_SLAVE allows the
same via sysfs.

But there are no precautions to prevent adding a device below a
controller that's being removed.  Such a device is unusable and may not
even be able to unbind cleanly as it becomes inaccessible once the
controller has been torn down.  E.g. it is then impossible to quiesce
the device's interrupt.

of_spi_notify() and acpi_spi_notify() do hold a ref on the controller,
but otherwise run lockless against spi_unregister_controller().

Fix by holding the spi_add_lock in spi_unregister_controller() and
bailing out of spi_add_device() if the controller has been unregistered
concurrently.

Fixes: ce79d54a ("spi/of: Add OF notifier handler")
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v3.19+
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Octavian Purdila <octavian.purdila@intel.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Link: https://lore.kernel.org/r/a8c3205088a969dc8410eec1eba9aface60f36af.1596451035.git.lukas@wunner.deSigned-off-by: NMark Brown <broonie@kernel.org>
      ddf75be4
  53. 22 7月, 2020 1 次提交
  55. 17 7月, 2020 2 次提交
  57. 19 6月, 2020 2 次提交
  59. 16 6月, 2020 3 次提交
  61. 29 5月, 2020 3 次提交