Eric Lee / smarc-fsl-linux-kernel

21 Aug, 2020

7 commits

  • c31979747   spi: rspi: Fill in controller speed limits ... Browse Code »

    Fill in the controller speed limits, so the SPI core can use them for
    validating SPI transfers, and adjusting them where needed.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200819125904.20938-8-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     
  • cb5882541   spi: rspi: Fill in spi_transfer.effective_speed_hz ... Browse Code »

    Fill in the effective bit rate used for transfers, so the SPI core can
    calculate instead of estimate delays.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200819125904.20938-7-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     
  • 6a195f24f   spi: rspi: Increase bit rate range for QSPI ... Browse Code »

    Increase bit rate range for QSPI by extending the range of supported
    dividers:
    1. QSPI supports a divider of 1, by setting SPBR to zero, increasing
    the upper limit from 48.75 to 97.5 MHz on R-Car Gen2,
    2. Make use of the Bit Rate Frequency Division Setting field in
    Command Registers, to decrease the lower limit from 191 to 24 kbps
    on R-Car Gen2.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200819125904.20938-6-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     
  • 4e71d926a   spi: rspi: Increase bit rate range for RSPI on SH ... Browse Code »

    Increase bit rate range for RSPI on legacy SH by making use of the Bit
    Rate Frequency Division Setting field in Command Registers, just like is
    already done on RZ/A. This decreases the lower limit by a factor of 8.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200819125904.20938-5-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     
  • feace9023   spi: rspi: Increase bit rate accuracy on RZ/A ... Browse Code »

    rspi_rz_set_config_register() favors high values of "brdv" over high
    values of "spbr". As "brdv" is not a plain divider, but controls a
    power-of-two divider, this may cause the selection of non-optimal
    divider values. E.g. on RSK+RZA1, when 3.8 MHz is requested, the actual
    configured bit rate is 2.08 MHz (spbr = 1, brdv = 3), while 3.7 MHz
    would be possible (spbr = 8, brdv = 0).

    Fix this by only resorting to higher "brdv" values when really needed.
    This makes the driver always pick optimal divider values on RZ/A.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200819125904.20938-4-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     
  • 8dd716986   spi: rspi: Clean up Bit Rate Division Setting handling ... Browse Code »

    Add a macro for configuring the Bit Rate Division Setting field in
    Command Registers, instead of open-coding the same operation using a
    hardcoded shift.
    Rename "div" to "brdv", as it is not a plain divider value, but controls
    a power-of-two divider.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200819125904.20938-3-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     
  • 7ffe363bb   spi: rspi: Remove useless .set_config_register() check ... Browse Code »

    Not implementing spi_ops.set_config_register() is a driver bug that
    would prevent the driver from working at all.
    Hence remove the run-time check.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200819125904.20938-2-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     

09 Jun, 2020

1 commit

  • e0fe70051   spi: rspi: Use requested instead of maximum bit rate ... Browse Code »

    Currently, the RSPI driver always tries to use the maximum configured
    bit rate for communicating with a slave device, even if the transfer(s)
    in the current message specify a lower rate.

    Use the mininum rate specified in the message instead.
    Rename rspi_data.max_speed_hz accordingly.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200608095940.30516-3-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     

10 Mar, 2020

1 commit

  • f3a14a3a4   spi: rspi: Add support for active-high chip selects ... Browse Code »

    All RSPI variants support setting the polarity of the SSL signal.
    Advertize support for active-high chip selects, and configure polarity
    according to the state of the flag.

    Signed-off-by: Geert Uytterhoeven
    Link: https://lore.kernel.org/r/20200309171537.21551-1-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     

19 Feb, 2020

2 commits

08 Jan, 2020

4 commits

12 Dec, 2019

1 commit

  • 851c902fd   spi: rspi: Remove obsolete platform_device_id entries ... Browse Code »

    Since commits 05104c266ae9a167 ("ARM: shmobile: r7s72100: genmai: Remove
    legacy board file") and a483dcbfa21f919c ("ARM: shmobile: lager: Remove
    legacy board support", RZ/A1 and R-Car Gen2 SoCs are only supported in
    generic DT-only ARM multi-platform builds. The driver doesn't need to
    match platform devices by name anymore for these platforms, hence remove
    the corresponding platform_device_id entries.

    The platform_device_id entry for "rspi" is retained, as it is used by
    the SH7757 platform, which hasn't been converted to DT yet.

    Signed-off-by: Geert Uytterhoeven
    Acked-by: Simon Horman
    Link: https://lore.kernel.org/r/20191211131553.23960-1-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     

19 Oct, 2019

1 commit

  • 2de860b4a   spi: rspi: Use platform_get_irq_byname_optional() for optional irqs ... Browse Code »

    As platform_get_irq_byname() now prints an error when the interrupt
    does not exist, scary warnings may be printed for optional interrupts:

    renesas_spi e6b10000.spi: IRQ rx not found
    renesas_spi e6b10000.spi: IRQ mux not found

    Fix this by calling platform_get_irq_byname_optional() instead.
    Remove the no longer needed printing of platform_get_irq errors, as the
    remaining calls to platform_get_irq() and platform_get_irq_byname() take
    care of that.

    Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to platform_get_irq*()")
    Signed-off-by: Geert Uytterhoeven
    Reviewed-by: Stephen Boyd
    Link: https://lore.kernel.org/r/20191016143101.28738-1-geert+renesas@glider.be
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     

02 May, 2019

1 commit

  • 7e95b1662   spi: rspi: Fix handling of QSPI code when transmit and receive ... Browse Code »

    Process handling QSPI when transmit/receive at qspi_trigger_transfer_out_in() as follows:
    Setting the trigger, is the number of bytes in the FIFO buffer to determine
    when there is an interrupt. Then check if the value of triggering number is
    32-bytes or 1-byte, there will be corresponding processing
    Handling (if (n == QSPI_BUFFER_SIZE) esle) this is unnecessary, leads to the
    same processing of data transmission or reception, The difference here are with
    ret = rspi_wait_for_tx_empty(rspi);
    ret = rspi_wait_for_rx_full(rspi);

    When the nummber trigger is 32 bytes, we only write into FIFO when the FIFO is completely empty
    (interrupt transmission), and only receive if FIFO is full of 32 bytes of data.

    In the case of a nummber trigger that is 1 byte, in principle we still need to process
    rspi_wait_for_tx_empty/full so that FIFO is empty only with the amount of data we need to write to
    or equal to the number of bytes we need to receive, There is currently no processing of this.
    And in the current case with this patch, at this time it only needs at least 1 byte received in
    FIFO that has interrupt received, or FIFO at least 1bytes free can be written into FIFO,
    This patch therefore does not affect this processing.
    So we need to eliminate unnecessary waste processing (if (n == QSPI_BUFFER_SIZE) esle),
    more precisely in waiting for FIFO status.
    The same with handling in qspi_transfer_out()/qspi_transfer_in().

    Signed-off-by: Hoan Nguyen An
    Signed-off-by: Mark Brown

    Hoan Nguyen An
     

16 Mar, 2019

2 commits

  • 26843bb12   spi: rspi: Fix sequencer reset during initialization ... Browse Code »

    While the sequencer is reset after each SPI message since commit
    880c6d114fd79a69 ("spi: rspi: Add support for Quad and Dual SPI
    Transfers on QSPI"), it was never reset for the first message, thus
    relying on reset state or bootloader settings.

    Fix this by initializing it explicitly during configuration.

    Fixes: 0b2182ddac4b8837 ("spi: add support for Renesas RSPI")
    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     
  • 42bdaaece   spi: rspi: Fix register initialization while runtime-suspended ... Browse Code »

    The Renesas RSPI/QSPI driver performs SPI controller register
    initialization in its spi_operations.setup() callback, without calling
    pm_runtime_get_sync() first, which may cause spurious failures.

    So far this went unnoticed, as this SPI controller is typically used
    with a single SPI NOR FLASH containing the boot loader:
    1. If the device's module clock is still enabled (left enabled by the
    bootloader, and not yet disabled by the clk_disable_unused() late
    initcall), register initialization succeeds,
    2. If the device's module clock is disabled, register writes don't
    seem to cause lock-ups or crashes.
    Data received in the first SPI message may be corrupted, though.
    Subsequent SPI messages seem to be OK.
    E.g. on r8a7791/koelsch, one bit is lost while receiving the 6th
    byte of the JEDEC ID for the s25fl512s FLASH, corrupting that byte
    and all later bytes. But until commit a2126b0a010905e5 ("mtd:
    spi-nor: refine Spansion S25FL512S ID"), the 6th byte was not
    considered for FLASH identification.

    Fix this by moving all initialization from the .setup() to the
    .prepare_message() callback. The latter is always called after the
    device has been runtime-resumed by the SPI core.

    This also makes the driver follow the rule that .setup() must not change
    global driver state or register values, as that might break a transfer
    in progress.

    Fixes: 490c97747d5dc77d ("spi: rspi: Add runtime PM support, using spi core auto_runtime_pm")
    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     

08 Feb, 2019

1 commit

05 Nov, 2018

1 commit

22 Oct, 2018

1 commit

05 Sep, 2018

2 commits

  • 8dbbaa47b   spi: rspi: Fix interrupted DMA transfers ... Browse Code »

    When interrupted, wait_event_interruptible_timeout() returns
    -ERESTARTSYS, and the SPI transfer in progress will fail, as expected:

    m25p80 spi0.0: SPI transfer failed: -512
    spi_master spi0: failed to transfer one message from queue

    However, as the underlying DMA transfers may not have completed, all
    subsequent SPI transfers may start to fail:

    spi_master spi0: receive timeout
    qspi_transfer_out_in() returned -110
    m25p80 spi0.0: SPI transfer failed: -110
    spi_master spi0: failed to transfer one message from queue

    Fix this by calling dmaengine_terminate_all() not only for timeouts, but
    also for errors.

    This can be reproduced on r8a7991/koelsch, using "hd /dev/mtd0" followed
    by CTRL-C.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown
    Cc: stable@vger.kernel.org

    Geert Uytterhoeven
     
  • c1ca59c22   spi: rspi: Fix invalid SPI use during system suspend ... Browse Code »

    If the SPI queue is running during system suspend, the system may lock
    up.

    Fix this by stopping/restarting the queue during system suspend/resume,
    by calling spi_master_suspend()/spi_master_resume() from the PM
    callbacks. In-kernel users will receive an -ESHUTDOWN error while
    system suspend/resume is in progress.

    Based on a patch for sh-msiof by Gaku Inami.

    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown
    Cc: stable@vger.kernel.org

    Geert Uytterhoeven
     

29 Aug, 2018

1 commit

20 Mar, 2018

1 commit

  • 768d59f5d   spi: rspi: use correct enum for DMA transfer direction ... Browse Code »

    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-rspi.c:538:26: 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-rspi.c:558:26: 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,
    ^~~~~~~~~~~~~

    Signed-off-by: Stefan Agner
    Signed-off-by: Mark Brown

    Stefan Agner
     

07 Dec, 2017

1 commit

  • b458a3490   spi: rspi: Do not set SPCR_SPE in qspi_set_config_register() ... Browse Code »

    The R-Car Gen2 Hardware User Manual Rev. 2.00 states:

    If the master/slave mode select bit (MSTR) is modified while the SPI
    function enable bit (SPE) is set to 1 (that is, this module is
    enabled), the subsequent operation cannot be guaranteed.

    Hence do not set SPCR_SPE when setting SPCR_MSTR, just like the
    .set_config_register() implementations for other RSPI variants do.

    Note that when booted from QSPI, the boot loader will have set SPCR_MSTR
    already, hence usually the bit is never modified by the Linux driver.

    Reported-by: Yoshihiro Shimoda
    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    Geert Uytterhoeven
     

04 Oct, 2017

1 commit

20 Feb, 2017

1 commit

17 Feb, 2017

2 commits

  • ad16d4a83   spi: rspi: Replaces "n" by "len" in qspi_transfer_*() ... Browse Code »

    This patch replaced "n" by "len" bytes of data in qspi_transfer_in() and
    qspi_transfer_out() function. This will make improving readability.

    Signed-off-by: DongCV
    Reviewed-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    DongCV
     
  • 7264abc70   spi: rspi: Fixes bogus received byte in qspi_transfer_in() ... Browse Code »

    In qspi_transfer_in(), when receiving the last n (or len) bytes of data,
    one bogus byte was written in the receive buffer.
    This code leads to a buffer overflow.

    "jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
    at 0x03b40000: 0x1900 instead
    jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
    at 0x03b40004: 0x000c instead"

    The error message above happens when trying to mount, unmount,
    and remount a jffs2-formatted device.
    This patch removed the bogus write to fixes: 3be09bec42a800d4
    "spi: rspi: supports 32bytes buffer for DUAL and QUAD"

    And here is Geert's comment:

    "spi: rspi: Fix bogus received byte in qspi_transfer_in()
    When there are less than QSPI_BUFFER_SIZE remaining bytes to be received,
    qspi_transfer_in() writes one bogus byte in the receive buffer, possibly
    leading to a buffer overflow.
    This can be reproduced by mounting, unmounting, and remounting a
    jffs2-formatted device, causing lots of warnings like:

    "jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
    at 0x03b40000: 0x1900 instead"

    Remove the bogus write to fix this. "

    Signed-off-by: DongCV
    Reviewed-by: Geert Uytterhoeven
    Signed-off-by: Mark Brown

    DongCV
     

05 Jan, 2017

1 commit

09 Nov, 2016

1 commit

  • db3008381   spi: rspi: avoid uninitialized variable access ... Browse Code »

    The newly introduced rspi_pio_transfer_in_or_our() function must
    take either a valid 'rx' or 'tx' pointer, and has undefined behavior
    if both are NULL, as found by 'gcc -Wmaybe-unintialized':

    drivers/spi/spi-rspi.c: In function 'rspi_pio_transfer_in_or_our':
    drivers/spi/spi-rspi.c:558:5: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized]

    The analysis of the function is correct in principle, but the code
    is currently safe because both callers always pass exactly one
    of the two pointers.

    Looking closer at this function shows that having a combined
    method for rx and tx here actually increases the complexity
    and the size of the file. This simplifies it again by keeping
    the two separate, which then ends up avoiding that warning.

    Fixes: 3be09bec42a8 ("spi: rspi: supports 32bytes buffer for DUAL and QUAD")
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Mark Brown

    Arnd Bergmann
     

05 Nov, 2016

1 commit

  • 3be09bec4   spi: rspi: supports 32bytes buffer for DUAL and QUAD ... Browse Code »

    This patch supports 32bytes of buffer for DUAL and QUAD in QSPI by
    Using Transmit/Receive Buffer Data Triggering Number.
    In order to improve the DUAL and QUAD's performance of SPI
    while transferring data in PIO mode, it sends/receives each 32bytes
    data instead of each byte data as current situation.

    Signed-off-by: Hiep Cao Minh
    Signed-off-by: Mark Brown

    Hiep Cao Minh
     

08 Aug, 2016

1 commit

  • aeb8f8cb1   spi: rspi: Increase accuracy of bit rate for RZ ... Browse Code »

    When you leave the clock divider at 0, 130kHz is the lowest you can go.
    Also, by adjusting the clock divider you can get more accurate resolutions
    for clock speeds lower than 16MHz. This patch uses the clock divider as
    part of the bit rate setup.

    Signed-off-by: Chris Brandt
    Signed-off-by: Mark Brown

    Chris Brandt
     

03 Jul, 2015

2 commits

02 Jun, 2015

2 commits