Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 14
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 6月, 2018 1 次提交
  3. 24 5月, 2018 1 次提交
  5. 17 4月, 2018 1 次提交
    • V
      spi: sh-msiof: Simplify calculation of divisors for transfer rate · 51093cba
      由 Vladimir Zapolskiy 提交于 
      The change updates sh_msiof_spi_set_clk_regs() function by iterating
over BRDV power values. Note that the change is a functional one, namely
prescaler output x 1/1 set in BRDV bit field (0b111) for MSO division
rate set to 2 is substituted by BRDV = 0b000 and BRPS = 0b0, in terms
of written values to TSCR setting of 0x0107 is substituted by 0x0000,
and for all input parameter cases this is the only functional change,
which touches the controller.

As a result of the rework the function is supposed to be slightly more
efficient and more readable and maintainable in case of any further
extensions.
Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      51093cba
  7. 16 4月, 2018 1 次提交
  9. 22 3月, 2018 1 次提交
    • G
      spi: sh-msiof: Use correct enum for DMA transfer direction · da779513
      由 Geert Uytterhoeven 提交于 
      Use enum dma_transfer_direction as required by dmaengine_prep_slave_sg()
instead of enum dma_data_direction.  This won't change behavior in
practice as the enum values are equivalent.

This fixes two warnings when building with clang:
  drivers/spi/spi-sh-msiof.c:755:27: warning: implicit conversion from enumeration
      type 'enum dma_data_direction' to different enumeration type
      'enum dma_transfer_direction' [-Wenum-conversion]
					rx->sgl, rx->nents, DMA_FROM_DEVICE,
							    ^~~~~~~~~~~~~~~
  drivers/spi/spi-sh-msiof.c:772:27: warning: implicit conversion from enumeration
      type 'enum dma_data_direction' to different enumeration type
      'enum dma_transfer_direction' [-Wenum-conversion]
					tx->sgl, tx->nents, DMA_TO_DEVICE,
							    ^~~~~~~~~~~~~

Based on commit 768d59f5 ("spi: rspi: use correct enum for DMA
transfer direction").
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NMark Brown <broonie@kernel.org>
      da779513
  11. 04 1月, 2018 1 次提交
    • G
      spi: sh-msiof: Fix timeout failures for TX-only DMA transfers · 89434c3c
      由 Geert Uytterhoeven 提交于 
      When using RX (with or without TX), the DMA interrupt triggers
completion when the RX FIFO has been emptied, i.e. after the full
transfer has finished.

However, when using TX without RX, the DMA interrupt triggers completion
as soon as the DMA engine has filled the TX FIFO, i.e. before the full
transfer has finished.  Then sh_msiof_modify_ctr_wait() will spin until
the transfer has really finished and the TFSE bit is cleared, for at
most 1 ms.  For slow speeds and/or large transfers, this may cause
timeouts and transfer failures:

    spi_sh_msiof e6e10000.spi: failed to shut down hardware
    74x164 spi2.0: SPI transfer failed: -110
    spi_master spi2: failed to transfer one message from queue
    74x164 spi2.0: Failed writing: -110

Fix this by waiting explicitly until the TX FIFO has been emptied.

Based on a patch in the BSP by Hiromitsu Yamasaki.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
      89434c3c
  13. 14 12月, 2017 3 次提交
    • G
      spi: sh-msiof: Implement cs-gpios configuration · b8761434
      由 Geert Uytterhoeven 提交于 
      The current support for GPIO chip selects assumes the GPIOs have been
configured by platform code or the boot loader.  This includes pinmux
setup and GPIO direction.  Hence it does not work as expected when just
described in DT using the "cs-gpios" property.

Fix this by:
  1. using devm_gpiod_get_index() to request the GPIO, and thus
     configure pinmux, if needed,
  2. configuring the GPIO direction is the spi_master.setup() callback.

Use gpio_is_valid() instead of a check on positive numbers.

Note that when using GPIO chip selects, at least one native chip select
must be left unused, as that native chip select will be driven anyway,
and (global) native chip select polarity must be taken into account.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
      b8761434
    • G
      spi: sh-msiof: Extend support to 3 native chip selects · 9cce882b
      由 Geert Uytterhoeven 提交于 
      Currently only the MSIOF_SYNC signal can be used as a native chip
select.  Extend support to up to 3 native chipselects using the
MSIOF_SS1 and MSIOF_SS2 signals.

Inspired by a patch in the BSP by Hiromitsu Yamasaki.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
      9cce882b
    • G
      spi: sh-msiof: Avoid writing to registers from spi_master.setup() · 7ff0b53c
      由 Geert Uytterhoeven 提交于 
      The spi_master.setup() callback must not change configuration registers,
as that could corrupt I/O that is in progress for other SPI slaves.

The only exception is the configuration of the native chip select
polarity in SPI master mode, as a wrong chip select polarity will cause
havoc during all future transfers to any other SPI slave.

Hence stop writing to registers in sh_msiof_spi_setup(), unless it is
the first call for a controller using a native chip select, or unless
native chip select polarity has changed (note that you'll loose anyway
if I/O is in progress).  Even then, only do what is strictly necessary,
instead of calling sh_msiof_spi_set_pin_regs().
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
      7ff0b53c
  15. 01 12月, 2017 1 次提交
  17. 04 11月, 2017 1 次提交
  19. 02 11月, 2017 1 次提交
  21. 04 10月, 2017 1 次提交
  23. 26 9月, 2017 1 次提交
  25. 17 7月, 2017 1 次提交
  27. 26 5月, 2017 1 次提交
  29. 05 1月, 2017 1 次提交
  31. 20 12月, 2016 1 次提交
  33. 15 12月, 2016 1 次提交
    • S
      spi: sh-msiof: Add R-Car Gen 2 and 3 fallback bindings · 4286db84
      由 Simon Horman 提交于 
      In the case of Renesas R-Car hardware we know that there are generations of
SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the
relationship between IP blocks might be. For example, I believe that
r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
descendant of the former or vice versa.

We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.

For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme is being adopted for
drivers for Renesas SoCs.

Also:
* Deprecate renesas,sh-msiof. It seems poorly named as it is only
  compatible with SH-Mobile. It also appears unused in mainline.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
      4286db84
  35. 22 11月, 2016 1 次提交
  37. 05 8月, 2016 1 次提交
  39. 22 6月, 2016 1 次提交
  41. 31 8月, 2015 1 次提交
  43. 07 7月, 2015 1 次提交
  45. 02 5月, 2015 1 次提交
  47. 23 2月, 2015 1 次提交
  49. 05 2月, 2015 1 次提交
  51. 03 2月, 2015 1 次提交
  53. 08 1月, 2015 1 次提交
  55. 06 1月, 2015 1 次提交
  57. 24 12月, 2014 1 次提交
  59. 16 12月, 2014 1 次提交
  61. 20 10月, 2014 1 次提交
  63. 31 8月, 2014 1 次提交
  65. 29 8月, 2014 1 次提交
  67. 17 8月, 2014 5 次提交