31 Mar, 2020

1 commit

  • Pull power management updates from Rafael Wysocki:
    "These clean up and rework the PM QoS API, address a suspend-to-idle
    wakeup regression on some ACPI-based platforms, clean up and extend a
    few cpuidle drivers, update multiple cpufreq drivers and cpufreq
    documentation, and fix a number of issues in devfreq and several other
    things all over.

    Specifics:

    - Clean up and rework the PM QoS API to simplify the code and reduce
    the size of it (Rafael Wysocki).

    - Fix a suspend-to-idle wakeup regression on Dell XPS13 9370 and
    similar platforms where the USB plug/unplug events are handled by
    the EC (Rafael Wysocki).

    - CLean up the intel_idle and PSCI cpuidle drivers (Rafael Wysocki,
    Ulf Hansson).

    - Extend the haltpoll cpuidle driver so that it can be forced to run
    on some systems where it refused to load (Maciej Szmigiero).

    - Convert several cpufreq documents to the .rst format and move the
    legacy driver documentation into one common file (Mauro Carvalho
    Chehab, Rafael Wysocki).

    - Update several cpufreq drivers:

    * Extend and fix the imx-cpufreq-dt driver (Anson Huang).

    * Improve the -EPROBE_DEFER handling and fix unwanted CPU
    overclocking on i.MX6ULL in imx6q-cpufreq (Anson Huang,
    Christoph Niedermaier).

    * Add support for Krait based SoCs to the qcom driver (Ansuel
    Smith).

    * Add support for OPP_PLUS to ti-cpufreq (Lokesh Vutla).

    * Add platform specific intermediate callbacks support to
    cpufreq-dt and update the imx6q driver (Peng Fan).

    * Simplify and consolidate some pieces of the intel_pstate
    driver and update its documentation (Rafael Wysocki, Alex
    Hung).

    - Fix several devfreq issues:

    * Remove unneeded extern keyword from a devfreq header file and
    use the DEVFREQ_GOV_UPDATE_INTERNAL event name instead of
    DEVFREQ_GOV_INTERNAL (Chanwoo Choi).

    * Fix the handling of dev_pm_qos_remove_request() result
    (Leonard Crestez).

    * Use constant name for userspace governor (Pierre Kuo).

    * Get rid of doc warnings and fix a typo (Christophe JAILLET).

    - Use built-in RCU list checking in some places in the PM core to
    avoid false-positive RCU usage warnings (Madhuparna Bhowmik).

    - Add explicit READ_ONCE()/WRITE_ONCE() annotations to low-level PM
    QoS routines (Qian Cai).

    - Fix removal of wakeup sources to avoid NULL pointer dereferences in
    a corner case (Neeraj Upadhyay).

    - Clean up the handling of hibernate compat ioctls and fix the
    related documentation (Eric Biggers).

    - Update the idle_inject power capping driver to use variable-length
    arrays instead of zero-length arrays (Gustavo Silva).

    - Fix list format in a PM QoS document (Randy Dunlap).

    - Make the cpufreq stats module use scnprintf() to avoid potential
    buffer overflows (Takashi Iwai).

    - Add pm_runtime_get_if_active() to PM-runtime API (Sakari Ailus).

    - Allow no domain-idle-states DT property in generic PM domains (Ulf
    Hansson).

    - Fix a broken y-axis scale in the intel_pstate_tracer utility (Doug
    Smythies)"

    * tag 'pm-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (78 commits)
    cpufreq: intel_pstate: Simplify intel_pstate_cpu_init()
    tools/power/x86/intel_pstate_tracer: fix a broken y-axis scale
    ACPI: PM: s2idle: Refine active GPEs check
    ACPICA: Allow acpi_any_gpe_status_set() to skip one GPE
    PM: sleep: wakeup: Skip wakeup_source_sysfs_remove() if device is not there
    PM / devfreq: Get rid of some doc warnings
    PM / devfreq: Fix handling dev_pm_qos_remove_request result
    PM / devfreq: Fix a typo in a comment
    PM / devfreq: Change to DEVFREQ_GOV_UPDATE_INTERVAL event name
    PM / devfreq: Remove unneeded extern keyword
    PM / devfreq: Use constant name of userspace governor
    ACPI: PM: s2idle: Fix comment in acpi_s2idle_prepare_late()
    cpufreq: qcom: Add support for krait based socs
    cpufreq: imx6q-cpufreq: Improve the logic of -EPROBE_DEFER handling
    cpufreq: Use scnprintf() for avoiding potential buffer overflow
    cpuidle: psci: Split psci_dt_cpu_init_idle()
    PM / Domains: Allow no domain-idle-states DT property in genpd when parsing
    PM / hibernate: Remove unnecessary compat ioctl overrides
    PM: hibernate: fix docs for ioctls that return loff_t via pointer
    Documentation: intel_pstate: update links for references
    ...

    Linus Torvalds
     

30 Mar, 2020

1 commit

  • * pm-qos: (30 commits)
    PM: QoS: annotate data races in pm_qos_*_value()
    Documentation: power: fix pm_qos_interface.rst format warning
    PM: QoS: Make CPU latency QoS depend on CONFIG_CPU_IDLE
    Documentation: PM: QoS: Update to reflect previous code changes
    PM: QoS: Update file information comments
    PM: QoS: Drop PM_QOS_CPU_DMA_LATENCY and rename related functions
    sound: Call cpu_latency_qos_*() instead of pm_qos_*()
    drivers: usb: Call cpu_latency_qos_*() instead of pm_qos_*()
    drivers: tty: Call cpu_latency_qos_*() instead of pm_qos_*()
    drivers: spi: Call cpu_latency_qos_*() instead of pm_qos_*()
    drivers: net: Call cpu_latency_qos_*() instead of pm_qos_*()
    drivers: mmc: Call cpu_latency_qos_*() instead of pm_qos_*()
    drivers: media: Call cpu_latency_qos_*() instead of pm_qos_*()
    drivers: hsi: Call cpu_latency_qos_*() instead of pm_qos_*()
    drm: i915: Call cpu_latency_qos_*() instead of pm_qos_*()
    x86: platform: iosf_mbi: Call cpu_latency_qos_*() instead of pm_qos_*()
    cpuidle: Call cpu_latency_qos_limit() instead of pm_qos_request()
    PM: QoS: Add CPU latency QoS API wrappers
    PM: QoS: Adjust pm_qos_request() signature and reorder pm_qos.h
    PM: QoS: Simplify definitions of CPU latency QoS trace events
    ...

    Rafael J. Wysocki
     

27 Mar, 2020

2 commits


24 Mar, 2020

2 commits

  • The current codebase makes use of the zero-length array language
    extension to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning
    in case the flexible array does not occur last in the structure, which
    will help us prevent some kind of undefined behavior bugs from being
    inadvertently introduced[3] to the codebase from now on.

    Also, notice that, dynamic memory allocations won't be affected by
    this change:

    "Flexible array members have incomplete type, and so the sizeof operator
    may not be applied. As a quirk of the original implementation of
    zero-length arrays, sizeof evaluates to zero."[1]

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Link: https://lore.kernel.org/r/20200320232515.GA24800@embeddedor.com
    Signed-off-by: Mark Brown

    Gustavo A. R. Silva
     
  • The current codebase makes use of the zero-length array language
    extension to the C90 standard, but the preferred mechanism to declare
    variable-length types such as these ones is a flexible array member[1][2],
    introduced in C99:

    struct foo {
    int stuff;
    struct boo array[];
    };

    By making use of the mechanism above, we will get a compiler warning
    in case the flexible array does not occur last in the structure, which
    will help us prevent some kind of undefined behavior bugs from being
    inadvertently introduced[3] to the codebase from now on.

    Also, notice that, dynamic memory allocations won't be affected by
    this change:

    "Flexible array members have incomplete type, and so the sizeof operator
    may not be applied. As a quirk of the original implementation of
    zero-length arrays, sizeof evaluates to zero."[1]

    This issue was found with the help of Coccinelle.

    [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
    [2] https://github.com/KSPP/linux/issues/21
    [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

    Signed-off-by: Gustavo A. R. Silva
    Reviewed-by: Andi Shyti
    Link: https://lore.kernel.org/r/20200320232556.GA24989@embeddedor.com
    Signed-off-by: Mark Brown

    Gustavo A. R. Silva
     

21 Mar, 2020

1 commit

  • Fix all functions and structure descriptions to have the driver
    warning free when built with W=1.

    Signed-off-by: Alain Volmat
    Reviewed-by: Amelie Delaunay
    Link: https://lore.kernel.org/r/1584711857-9162-1-git-send-email-alain.volmat@st.com
    Signed-off-by: Mark Brown

    Alain Volmat
     

20 Mar, 2020

1 commit

  • This feature should not be enabled in release but can be useful for
    developers who need to monitor register accesses at some specific places.

    Helped me identify a bug in u-boot, by comparing the register accesses
    from the linux driver with the ones from its u-boot variant.

    Signed-off-by: Tudor Ambarus
    Link: https://lore.kernel.org/r/20200320065058.891221-1-tudor.ambarus@microchip.com
    Signed-off-by: Mark Brown

    Tudor Ambarus
     

19 Mar, 2020

10 commits

  • This is similar to the DSPI instantiation on LS1028A, except that:
    - The A-011218 erratum has been fixed, so DMA works
    - The endianness is different, which has implications on XSPI mode

    Some benchmarking with the following command:

    spidev_test --device /dev/spidev2.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000

    shows that in DMA mode, it can achieve around 2400 kbps, and in XSPI
    mode, the same command goes up to 4700 kbps. This is somewhat to be
    expected, since the DMA buffer size is extremely small at 8 bytes, the
    winner becomes whomever can prepare the buffers for transmission
    quicker, and DMA mode has higher overhead there. So XSPI FIFO mode has
    been chosen as the operating mode for this chip.

    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-11-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • The operating mode (DMA, XSPI, EOQ) is not going to change across the
    lifetime of the device. So it makes no sense to keep writing to SPI_RSER
    on each message. Move this configuration to dspi_init instead.

    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-10-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • Interrupts are not necessary for DMA functionality, since the completion
    event is provided by the DMA driver.

    But if the driver fails to request the IRQ defined in the device tree,
    it will call dspi_poll which would make the driver hang waiting for data
    to become available in the RX FIFO.

    Fixes: c55be3059159 ("spi: spi-fsl-dspi: Use poll mode in case the platform IRQ is missing")
    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-9-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • The driver does not create the dspi->dma structure unless operating in
    DSPI_DMA_MODE, so it makes sense to check for that.

    Fixes: f4b323905d8b ("spi: Introduce dspi_slave_abort() function for NXP's dspi SPI driver")
    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-8-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • Currently the driver puts the process in interruptible sleep waiting for
    the interrupt train to finish transfer to/from the tx_buf and rx_buf.

    But exiting the process with ctrl-c may make the kernel panic: the
    wait_event_interruptible call will return -ERESTARTSYS, which a proper
    driver implementation is perhaps supposed to handle, but nonetheless
    this one doesn't, and aborts the transfer altogether.

    Actually when the task is interrupted, there is still a high chance that
    the dspi_interrupt is still triggering. And if dspi_transfer_one_message
    returns execution all the way to the spi_device driver, that can free
    the spi_message and spi_transfer structures, leaving the interrupts to
    access a freed tx_buf and rx_buf.

    hexdump -C /dev/mtd0
    00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff
    |.uhu............|
    00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    |................|
    *
    ^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed!
    [ 38.503097] spi_master spi2: failed to transfer one message from queue
    [ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377
    [ 38.517676] Mem abort info:
    [ 38.520474] ESR = 0x96000045
    [ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits
    [ 38.528861] SET = 0, FnV = 0
    [ 38.531921] EA = 0, S1PTW = 0
    [ 38.535067] Data abort info:
    [ 38.537952] ISV = 0, ISS = 0x00000045
    [ 38.541797] CM = 0, WnR = 1
    [ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000
    [ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000
    [ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP
    [ 38.565819] Modules linked in:
    [ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193
    [ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
    [ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO)
    [ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110
    [ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90
    [ 38.601203] sp : ffff800010003d90
    [ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000
    [ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400
    [ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0
    [ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377
    [ 38.625841] x21: 000000000000146e x20: ffff8000120c3000
    [ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948
    [ 38.636498] x17: 0000000000000000 x16: 0000000000000000
    [ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720
    [ 38.647155] x13: 0720072007200765 x12: 0775076507750771
    [ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040
    [ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8
    [ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60
    [ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377
    [ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0
    [ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026
    [ 38.684454] Call trace:
    [ 38.686905] ktime_get_real_ts64+0x3c/0x110
    [ 38.691100] spi_take_timestamp_pre+0x40/0x90
    [ 38.695470] dspi_fifo_write+0x58/0x2c0
    [ 38.699315] dspi_interrupt+0xbc/0xd0
    [ 38.702987] __handle_irq_event_percpu+0x78/0x2c0
    [ 38.707706] handle_irq_event_percpu+0x3c/0x90
    [ 38.712161] handle_irq_event+0x4c/0xd0
    [ 38.716008] handle_fasteoi_irq+0xbc/0x170
    [ 38.720115] generic_handle_irq+0x2c/0x40
    [ 38.724135] __handle_domain_irq+0x68/0xc0
    [ 38.728243] gic_handle_irq+0xc8/0x160
    [ 38.732000] el1_irq+0xb8/0x180
    [ 38.735149] spi_nor_spimem_read_data+0xe0/0x140
    [ 38.739779] spi_nor_read+0xc4/0x120
    [ 38.743364] mtd_read_oob+0xa8/0xc0
    [ 38.746860] mtd_read+0x4c/0x80
    [ 38.750007] mtdchar_read+0x108/0x2a0
    [ 38.753679] __vfs_read+0x20/0x50
    [ 38.757002] vfs_read+0xa4/0x190
    [ 38.760237] ksys_read+0x6c/0xf0
    [ 38.763471] __arm64_sys_read+0x20/0x30
    [ 38.767319] el0_svc_common.constprop.3+0x90/0x160
    [ 38.772125] do_el0_svc+0x28/0x90
    [ 38.775449] el0_sync_handler+0x118/0x190
    [ 38.779468] el0_sync+0x140/0x180
    [ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0)
    [ 38.788910] ---[ end trace 55da560db4d6bef7 ]---
    [ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt
    [ 38.799914] SMP: stopping secondary CPUs
    [ 38.803849] Kernel Offset: disabled
    [ 38.807344] CPU features: 0x10002,20006008
    [ 38.811451] Memory Limit: none
    [ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

    So it is clear that the "interruptible" part isn't handled correctly.
    When the process receives a signal, one could either attempt a clean
    abort (which appears to be difficult with this hardware) or just keep
    restarting the sleep until the wait queue really completes. But checking
    in a loop for -ERESTARTSYS is a bit too complicated for this driver, so
    just make the sleep uninterruptible, to avoid all that nonsense.

    The wait queue was actually restructured as a completion, after polling
    other drivers for the most "popular" approach.

    Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
    Reported-by: Michael Walle
    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • dspi->words_in_flight is a variable populated in the *_write functions
    and used in the dspi_fifo_read function. It is also used in
    dspi_fifo_write, immediately after transmission, to update the
    message->actual_length variable used by higher layers such as spi-mem
    for integrity checking.

    But it may happen that the IRQ which calls dspi_fifo_read to be
    triggered before the updating of message->actual_length takes place. In
    that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
    and that will cause an invalid modification of message->actual_length.

    For that, we make the simplest fix possible: to not decrement the actual
    shared variable in dspi->words_in_flight from dspi_fifo_read, but
    actually a copy of it which is on stack.

    But even if dspi_fifo_read from the next IRQ does not interfere with the
    dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
    can. So we must assume that everything after the last write to the TX
    FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
    function must be safe against that. This means refactoring the 2
    flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
    the number of words to be written is common and happens a priori. This
    way, the code for updating the message->actual_length variable works
    with a copy and not with the volatile dspi->words_in_flight.

    After some interior debate, the dspi->progress variable used for
    software timestamping was *not* backed up against preemption in a copy
    on stack. Because if preemption does occur between
    spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
    point in trying to save anything. The first-in-time
    spi_take_timestamp_post call with a dspi->progress higher than the
    requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
    anyway and will close the deal.

    To understand the above a bit better, consider a transfer with
    xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
    xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
    controller timestamps in chunks of 4 bytes at a time, and preemption
    occurs in the middle of timestamping the first chunk:

    spi_take_timestamp_pre(0)
    .
    . (preemption)
    .
    . spi_take_timestamp_pre(4)
    .
    . spi_take_timestamp_post(7)
    .
    spi_take_timestamp_post(3)

    So the reason I'm not bothering to back up dspi->progress for that
    spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
    to (a) be more honest, (b) provide better accuracy and (c) already
    render the spi_take_timestamp_post(3) into a noop by setting
    xfer->timestamped = true anyway.

    Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
    Reported-by: Michael Walle
    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • If dspi->words_in_flight is populated with the hardware FIFO size,
    then in dspi_fifo_read it will attempt to read more data at the end of a
    buffer that is not a multiple of 16 bytes in length. It will probably
    time out attempting to do so.

    So limit the num_fifo_entries variable to the actual number of FIFO
    entries that is going to be used.

    Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-5-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • In DMA mode, dspi_setup_accel does not get called, which results in the
    dspi->oper_word_size variable (which is used by dspi_dma_xfer) to not be
    initialized properly.

    Because oper_word_size is zero, a few calculations end up being
    incorrect, and the DMA transfer eventually times out instead of sending
    anything on the wire.

    Set up native transfers (or 8-on-16 acceleration) using dspi_setup_accel
    for DMA mode too.

    Also take the opportunity and simplify the DMA buffer handling a little
    bit.

    Fixes: 6c1c26ecd9a3 ("spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible")
    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-4-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • In XSPI mode, the 32-bit PUSHR register can be written to separately:
    the higher 16 bits are for commands and the lower 16 bits are for data.

    This has nicely been hacked around, by defining a second regmap with a
    width of 16 bits, and effectively splitting a 32-bit register into 2
    16-bit ones, from the perspective of this regmap_pushr.

    The problem is the assumption about the controller's endianness. If the
    controller is little endian (such as anything post-LS1046A), then the
    first 2 bytes, in the order imposed by memory layout, will actually hold
    the TXDATA, and the last 2 bytes will hold the CMD.

    So take the controller's endianness into account when performing split
    writes to PUSHR. The obvious and simple solution would have been to call
    regmap_get_val_endian(), but that is an internal regmap function and we
    don't want to change regmap just for this. Therefore, we just re-read
    the "big-endian" device tree property.

    Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     
  • The SPI_MCR_PCSIS macro assumes that the controller has a number of chip
    select signals equal to 6. That is not always the case, but actually is
    described through the driver-specific "spi-num-chipselects" device tree
    binding. LS1028A for example only has 4 chip selects.

    Don't write to the upper bits of the PCSIS field, which are reserved in
    the reference manual.

    Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
    Signed-off-by: Vladimir Oltean
    Tested-by: Michael Walle
    Link: https://lore.kernel.org/r/20200318001603.9650-2-olteanv@gmail.com
    Signed-off-by: Mark Brown

    Vladimir Oltean
     

17 Mar, 2020

1 commit

  • This driver is not using any symbols from the GPIO .h files
    so drop them.

    It was however implicitly using
    so include that instead.

    Cc: Fabio Estevam
    Signed-off-by: Linus Walleij
    Link: https://lore.kernel.org/r/20200317092457.264055-1-linus.walleij@linaro.org
    Signed-off-by: Mark Brown

    Linus Walleij
     

13 Mar, 2020

10 commits

  • … Armstrong <narmstrong@baylibre.com>:

    The SPICC controller in Amlogic AXG & G12A is capable of driving the
    CLK/MOSI/SS signal lines through the idle state which avoid the signals
    floating in unexpected state, is capable of using linear clock divider
    to reach a much fine tuned range of clocks, while the old controller only
    uses a power of two clock divider, result at a more coarse clock range and
    finally is capable of running at 80M clock.

    The SPICC controller in Amlogic G12A takes the source clock from a specific
    clock instead of the bus clock and has a different FIFO size and doesn't
    handle the RX Half interrupt the same way as GXL & AXG variants. Thus
    the burst management is simplified and takes in account a variable FIFO
    size.

    Now the controller can support frequencies higher than 30MHz, we need
    the setup the I/O line delays in regard of the SPI clock frequency.

    Neil Armstrong (7):
    spi: meson-spicc: remove unused variables
    spi: meson-spicc: support max 80MHz clock
    spi: meson-spicc: add min sclk for each compatible
    spi: meson-spicc: setup IO line delay
    spi: meson-spicc: adapt burst handling for G12A support
    dt-bindings: spi: amlogic,meson-gx-spicc: add Amlogic G12A compatible
    spi: meson-spicc: add support for Amlogic G12A

    Sunny Luo (2):
    spi: meson-spicc: enhance output enable feature
    spi: meson-spicc: add a linear clock divider support

    .../bindings/spi/amlogic,meson-gx-spicc.yaml | 22 +
    drivers/spi/Kconfig | 1 +
    drivers/spi/spi-meson-spicc.c | 496 +++++++++++++-----
    3 files changed, 392 insertions(+), 127 deletions(-)

    --
    2.22.0

    _______________________________________________
    linux-amlogic mailing list
    linux-amlogic@lists.infradead.org
    http://lists.infradead.org/mailman/listinfo/linux-amlogic

    Mark Brown
     
  • to_spi_device() already checks 'dev'. No need to do it before calling
    it.

    Signed-off-by: Wolfram Sang
    Reviewed-by: Geert Uytterhoeven
    Reviewed-by: Niklas Söderlund
    Link: https://lore.kernel.org/r/20200312134507.10000-1-wsa@the-dreams.de
    Signed-off-by: Mark Brown

    Wolfram Sang
     
  • Add support for the SPICC controllers on the Amlogic G12A SoCs family.

    The G12A SPICC controllers inherit from the AXG enhanced registers but
    takes an external pclk for the baud rate generator and can achieve up to
    166MHz SCLK.

    Signed-off-by: Neil Armstrong
    Link: https://lore.kernel.org/r/20200312133131.26430-10-narmstrong@baylibre.com
    Signed-off-by: Mark Brown

    Neil Armstrong
     
  • The G12A SPICC controller variant has a different FIFO size and doesn't
    handle the RX Half interrupt the same way as GXL & AXG variants.

    Thus simplify the burst management and take in account a variable FIFO
    size.

    Signed-off-by: Neil Armstrong
    Link: https://lore.kernel.org/r/20200312133131.26430-8-narmstrong@baylibre.com
    Signed-off-by: Mark Brown

    Neil Armstrong
     
  • Now the controller can support frequencies higher than 30MHz, we need
    the setup the I/O line delays in regard of the SPI clock frequency.

    Signed-off-by: Neil Armstrong
    Link: https://lore.kernel.org/r/20200312133131.26430-7-narmstrong@baylibre.com
    Signed-off-by: Mark Brown

    Neil Armstrong
     
  • The G12A SPICC controller variant takes the source clock from a specific
    clock instead of the bus clock.
    The minimal clock calculus won't work with the G12A support, thus add the
    minimal supported clock for each variant and pass this to the SPI core.

    Signed-off-by: Neil Armstrong
    Link: https://lore.kernel.org/r/20200312133131.26430-6-narmstrong@baylibre.com
    Signed-off-by: Mark Brown

    Neil Armstrong
     
  • The SPICC controller in Meson-AXG is capable of running at 80M clock.
    The ASIC IP is improved and the clock is actually running higher than
    previous old SoCs.

    Signed-off-by: Neil Armstrong
    Signed-off-by: Yixun Lan
    Signed-off-by: Sunny Luo
    Link: https://lore.kernel.org/r/20200312133131.26430-5-narmstrong@baylibre.com
    Signed-off-by: Mark Brown

    Neil Armstrong
     
  • The SPICC controller in Meson-AXG SoC is capable of using
    a linear clock divider to reach a much fine tuned range of clocks,
    while the old controller only use a power of two clock divider,
    result at a more coarse clock range.

    Also convert the clock registration into Common Clock Framework.

    Signed-off-by: Neil Armstrong
    Signed-off-by: Yixun Lan
    Signed-off-by: Sunny Luo
    Link: https://lore.kernel.org/r/20200312133131.26430-4-narmstrong@baylibre.com
    Signed-off-by: Mark Brown

    Sunny Luo
     
  • The SPICC controller in Meson-AXG is capable of driving the CLK/MOSI/SS
    signal lines through the idle state (between two transmission operation),
    which avoid the signals floating in unexpected state.

    Signed-off-by: Neil Armstrong
    Signed-off-by: Yixun Lan
    Signed-off-by: Sunny Luo
    Link: https://lore.kernel.org/r/20200312133131.26430-3-narmstrong@baylibre.com
    Signed-off-by: Mark Brown

    Sunny Luo
     
  • Remove unused variables from spicc data struct.

    Signed-off-by: Neil Armstrong
    Link: https://lore.kernel.org/r/20200312133131.26430-2-narmstrong@baylibre.com
    Signed-off-by: Mark Brown

    Neil Armstrong
     

12 Mar, 2020

5 commits

  • The platform_get_resource_byname() function returns NULL on error, it
    doesn't return error pointers.

    Fixes: d166a73503ef ("spi: fspi: dynamically alloc AHB memory")
    Signed-off-by: Dan Carpenter
    Link: https://lore.kernel.org/r/20200312113154.GC20562@mwanda
    Signed-off-by: Mark Brown

    Dan Carpenter
     
  • …broonie/spi into spi-5.7

    spi: Rewrite mtk-quadspi spi-nor driver with spi-mem

    This patchset from Chuanhong Guo <gch981213@gmail.com> adds a spi-mem
    driver for Mediatek SPI-NOR controller, which already has limited
    support by mtk-quadspi. This new driver can make use of full quadspi
    capability of this controller.

    Mark Brown
     
  • 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: Chuanhong Guo
    Link: https://lore.kernel.org/r/20200306085052.28258-3-gch981213@gmail.com
    Signed-off-by: Mark Brown

    Chuanhong Guo
     
  • We only need a spi-max-frequency when we specifically request a
    spi frequency lower than the max speed of spi host.
    This property is already documented as optional property and current
    host drivers are implemented to operate at highest speed possible
    when spi->max_speed_hz is 0.
    This patch makes spi-max-frequency an optional property so that
    we could just omit it to use max controller speed.

    Signed-off-by: Chuanhong Guo
    Link: https://lore.kernel.org/r/20200306085052.28258-2-gch981213@gmail.com
    Signed-off-by: Mark Brown

    Chuanhong Guo
     
  • 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: John Garry

    Link: https://lore.kernel.org/r/1583948115-239907-1-git-send-email-john.garry@huawei.com
    Signed-off-by: Mark Brown

    John Garry
     

11 Mar, 2020

1 commit

  • Use the correct device to request the DMA mapping. Otherwise the IOMMU
    doesn't get the mapping and it will generate a page fault.

    The error messages look like:
    [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
    [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8

    This was tested on a custom board with a LS1028A SoC.

    Signed-off-by: Michael Walle
    Link: https://lore.kernel.org/r/20200310073313.21277-1-michael@walle.cc
    Signed-off-by: Mark Brown

    Michael Walle
     

10 Mar, 2020

4 commits

  • This series adds a dts binding and a driver for a new SPI controller that is
    accessed over FSI bus.

    Eddie James (2):
    dt-bindings: fsi: Add FSI2SPI bindings
    spi: Add FSI-attached SPI controller driver

    .../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 36 ++
    MAINTAINERS | 7 +
    drivers/spi/Kconfig | 7 +
    drivers/spi/Makefile | 1 +
    drivers/spi/spi-fsi.c | 558 ++++++++++++++++++
    5 files changed, 609 insertions(+)
    create mode 100644 Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml
    create mode 100644 drivers/spi/spi-fsi.c

    --
    2.24.0

    Mark Brown
     
  • 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
     
  • The Rockchip spi binding is updated to yaml and new models
    were added. The spi on px30,rk3308 and rk3328 are the same as
    other Rockchip based SoCs, so add compatible string for it.

    Signed-off-by: Johan Jonker
    Link: https://lore.kernel.org/r/20200309151004.7780-1-jbx6244@gmail.com
    Signed-off-by: Mark Brown

    Johan Jonker
     
  • There exists a set of SPI controllers on some POWER processors that may
    be accessed through the FSI bus. Add a driver to traverse the FSI CFAM
    engine that can access and drive the SPI controllers. This driver would
    typically be used by a baseboard management controller (BMC).

    The SPI controllers operate by means of programming a sequencing engine
    which automatically manages the usual SPI protocol buses. The driver
    programs each transfer into the sequencer as various operations
    specifying the slave chip and shifting data in and out on the lines.

    Signed-off-by: Eddie James
    Link: https://lore.kernel.org/r/20200306194118.18581-3-eajames@linux.ibm.com
    Signed-off-by: Mark Brown

    Eddie James
     

07 Mar, 2020

1 commit

  • Pull spi fixes from Mark Brown:
    "A selection of small fixes, mostly for drivers, that have arrived
    since the merge window. None of them are earth shattering in
    themselves but all useful for affected systems"

    * tag 'spi-fix-v5.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
    spi: spi_register_controller(): free bus id on error paths
    spi: bcm63xx-hsspi: Really keep pll clk enabled
    spi: atmel-quadspi: fix possible MMIO window size overrun
    spi/zynqmp: remove entry that causes a cs glitch
    spi: pxa2xx: Add CS control clock quirk
    spi: spidev: Fix CS polarity if GPIO descriptors are used
    spi: qup: call spi_qup_pm_resume_runtime before suspending
    spi: spi-omap2-mcspi: Support probe deferral for DMA channels
    spi: spi-omap2-mcspi: Handle DMA size restriction on AM65x

    Linus Torvalds