Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 4月, 2021 1 次提交
  3. 21 4月, 2021 2 次提交
  5. 01 4月, 2021 1 次提交
  7. 22 1月, 2021 1 次提交
  9. 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
  11. 16 1月, 2021 1 次提交
  13. 13 1月, 2021 1 次提交
  15. 06 1月, 2021 1 次提交
  17. 05 1月, 2021 1 次提交
  19. 04 1月, 2021 1 次提交
  21. 27 11月, 2020 1 次提交
  23. 17 11月, 2020 1 次提交
  25. 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
  27. 08 9月, 2020 1 次提交
  29. 20 8月, 2020 1 次提交
  31. 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
  33. 22 7月, 2020 1 次提交
  35. 17 7月, 2020 2 次提交
  37. 19 6月, 2020 2 次提交
  39. 16 6月, 2020 3 次提交
  41. 29 5月, 2020 3 次提交
  43. 12 5月, 2020 1 次提交
  45. 27 4月, 2020 1 次提交
  47. 13 3月, 2020 1 次提交
  49. 12 3月, 2020 2 次提交
    • C
      spi: add support for mediatek spi-nor controller · 881d1ee9
      由 Chuanhong Guo 提交于 
      This is a driver for mtk spi-nor controller using spi-mem interface.
The same controller already has limited support provided by mtk-quadspi
driver under spi-nor framework and this new driver is a replacement
for the old one.

Comparing to the old driver, this driver has following advantages:
1. It can handle any full-duplex spi transfer up to 6 bytes, and
   this is implemented using generic spi interface.
2. It take account into command opcode properly. The reading routine
   in this controller can only use 0x03 or 0x0b as opcode on 1-1-1
   transfers, but old driver doesn't implement this properly. This
   driver checks supported opcode explicitly and use (1) to perform
   unmatched operations.
3. It properly handles SFDP reading. Old driver can't read SFDP
   due to the bug mentioned in (2).
4. It can do 1-2-2 and 1-4-4 fast reading on spi-nor. These two ops
   requires parsing SFDP, which isn't possible in old driver. And
   the old driver is only flagged to support 1-1-2 mode.
5. It takes advantage of the DMA feature in this controller for
   long reads and supports IRQ on DMA requests to free cpu cycles
   from polling status registers on long DMA reading. It achieves
   up to 17.5MB/s reading speed (1-4-4 mode) which is way faster
   than the old one. IRQ is implemented as optional to maintain
   backward compatibility.
Signed-off-by: NChuanhong Guo <gch981213@gmail.com>
Link: https://lore.kernel.org/r/20200306085052.28258-3-gch981213@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>
      881d1ee9
    • J
      spi: Stop selecting MTD_SPI_NOR for SPI_HISI_SFC_V3XX · caef2df1
      由 John Garry 提交于 
      By selecting MTD_SPI_NOR for SPI_HISI_SFC_V3XX, we may introduce unmet
dependencies:

WARNING: unmet direct dependencies detected for MTD_SPI_NOR
  Depends on [m]: MTD [=m] && SPI_MASTER [=y]
  Selected by [y]:
  - SPI_HISI_SFC_V3XX [=y] && SPI [=y] && SPI_MASTER [=y] && (ARM64 && ACPI [=y] || COMPILE_TEST [=y]) && HAS_IOMEM [=y]

Since MTD_SPI_NOR is only selected by SPI_HISI_SFC_V3XX for practical
reasons - slave devices use the spi-nor driver, enabled by MTD_SPI_NOR -
just drop it.
Signed-off-by: NJohn Garry <john.garry@huawei.com>

Link: https://lore.kernel.org/r/1583948115-239907-1-git-send-email-john.garry@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>
      caef2df1
  51. 10 3月, 2020 1 次提交
  53. 06 3月, 2020 1 次提交
  55. 13 2月, 2020 1 次提交
  57. 11 2月, 2020 2 次提交
  59. 10 1月, 2020 1 次提交