linux-stable.git/drivers/soc/qcom, branch v5.8

Merge tag 'rproc-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc

2020-06-08T20:01:08+00:00

Pull remoteproc updates from Bjorn Andersson:
 "This introduces device managed versions of functions used to register
  remoteproc devices, add support for remoteproc driver specific
  resource control, enables remoteproc drivers to specify ELF class and
  machine for coredumps. It integrates pm_runtime in the core for
  keeping resources active while the remote is booted and holds a wake
  source while recoverying a remote processor after a firmware crash.

  It refactors the remoteproc device's allocation path to simplify the
  logic, fix a few cleanup bugs and to not clone const strings onto the
  heap. Debugfs code is simplifies using the DEFINE_SHOW_ATTRIBUTE and a
  zero-length array is replaced with flexible-array.

  A new remoteproc driver for the JZ47xx VPU is introduced, the Qualcomm
  SM8250 gains support for audio, compute and sensor remoteprocs and the
  Qualcomm SC7180 modem support is cleaned up and improved.

  The Qualcomm glink subsystem-restart driver is merged into the main
  glink driver, the Qualcomm sysmon driver is extended to properly
  notify remote processors about all other remote processors' state
  transitions"

* tag 'rproc-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc: (43 commits)
  remoteproc: Fix an error code in devm_rproc_alloc()
  MAINTAINERS: Add myself as reviewer for Ingenic rproc driver
  remoteproc: ingenic: Added remoteproc driver
  remoteproc: Add support for runtime PM
  dt-bindings: Document JZ47xx VPU auxiliary processor
  remoteproc: wcss: Fix arguments passed to qcom_add_glink_subdev()
  remoteproc: Fix and restore the parenting hierarchy for vdev
  remoteproc: Fall back to using parent memory pool if no dedicated available
  remoteproc: Replace zero-length array with flexible-array
  remoteproc: wcss: add support for rpmsg communication
  remoteproc: core: Prevent system suspend during remoteproc recovery
  remoteproc: qcom_q6v5_mss: Remove unused q6v5_da_to_va function
  remoteproc: qcom_q6v5_mss: map/unmap mpss segments before/after use
  remoteproc: qcom_q6v5_mss: Drop accesses to MPSS PERPH register space
  dt-bindings: remoteproc: qcom: Replace halt-nav with spare-regs
  remoteproc: qcom: pas: Add SM8250 PAS remoteprocs
  dt-bindings: remoteproc: qcom: pas: Add SM8250 remoteprocs
  remoteproc: qcom_q6v5_mss: Extract mba/mpss from memory-region
  dt-bindings: remoteproc: qcom: Use memory-region to reference memory
  remoteproc: qcom: pas: Add SC7180 Modem support
  ...

Merge tag 'arm-drivers-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2020-06-05T02:56:20+00:00

Pull ARM/SoC driver updates from Arnd Bergmann:
 "These are updates to SoC specific drivers that did not have another
  subsystem maintainer tree to go through for some reason:

   - Some bus and memory drivers for the MIPS P5600 based Baikal-T1 SoC
     that is getting added through the MIPS tree.

   - There are new soc_device identification drivers for TI K3, Qualcomm
     MSM8939

   - New reset controller drivers for NXP i.MX8MP, Renesas RZ/G1H, and
     Hisilicon hi6220

   - The SCMI firmware interface can now work across ARM SMC/HVC as a
     transport.

   - Mediatek platforms now use a new driver for their "MMSYS" hardware
     block that controls clocks and some other aspects in behalf of the
     media and gpu drivers.

   - Some Tegra processors have improved power management support,
     including getting woken up by the PMIC and cluster power down
     during idle.

   - A new v4l staging driver for Tegra is added.

   - Cleanups and minor bugfixes for TI, NXP, Hisilicon, Mediatek, and
     Tegra"

* tag 'arm-drivers-5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (155 commits)
  clk: sprd: fix compile-testing
  bus: bt1-axi: Build the driver into the kernel
  bus: bt1-apb: Build the driver into the kernel
  bus: bt1-axi: Use sysfs_streq instead of strncmp
  bus: bt1-axi: Optimize the return points in the driver
  bus: bt1-apb: Use sysfs_streq instead of strncmp
  bus: bt1-apb: Use PTR_ERR_OR_ZERO to return from request-regs method
  bus: bt1-apb: Fix show/store callback identations
  bus: bt1-apb: Include linux/io.h
  dt-bindings: memory: Add Baikal-T1 L2-cache Control Block binding
  memory: Add Baikal-T1 L2-cache Control Block driver
  bus: Add Baikal-T1 APB-bus driver
  bus: Add Baikal-T1 AXI-bus driver
  dt-bindings: bus: Add Baikal-T1 APB-bus binding
  dt-bindings: bus: Add Baikal-T1 AXI-bus binding
  staging: tegra-video: fix V4L2 dependency
  tee: fix crypto select
  drivers: soc: ti: knav_qmss_queue: Make knav_gp_range_ops static
  soc: ti: add k3 platforms chipid module driver
  dt-bindings: soc: ti: add binding for k3 platforms chipid module
  ...

cpuidle: Convert Qualcomm SPM driver to a generic CPUidle driver

2020-05-26T08:46:01+00:00

The Qualcomm SPM cpuidle driver seems to be the last driver still
using the generic ARM CPUidle infrastructure.

Converting it actually allows us to simplify the driver,
and we end up being able to remove more lines than adding new ones:

  - We can parse the CPUidle states in the device tree directly
    with dt_idle_states (and don't need to duplicate that
    functionality into the spm driver).

  - Each "saw" device managed by the SPM driver now directly
    registers its own cpuidle driver, removing the need for
    any global (per cpu) state.

The device tree binding is the same, so the driver stays
compatible with all old device trees.

Signed-off-by: Stephan Gerhold 
Reviewed-by: Lina Iyer 
Reviewed-by: Ulf Hansson 
Acked-by: Bjorn Andersson 
Signed-off-by: Rafael J. Wysocki

Revert "soc: qcom: rpmh: Allow RPMH driver to be loaded as a module"

2020-05-18T06:13:00+00:00

Attempting to compile rpmh-rsc.c as a module with TRACING enabled causes
a build error as no _rcuidle function is generated for tracepoints when
CONFIG_MODULE is set.

Attempts has been made, but no resolution has been agreed upon, so lets
revert this commit for now.

This reverts commit 1d3c6f86fd3f8b88c707f56d8c3f94e014b40e83.

Reported-by: Stephen Rothwell 
Signed-off-by: Bjorn Andersson

soc: qcom: rpmh-rsc: Remove the pm_lock

2020-05-15T18:45:21+00:00

It has been postulated that the pm_lock is bad for performance because
a CPU currently running rpmh_flush() could block other CPUs from
coming out of idle.  Similarly CPUs coming out of / going into idle
all need to contend with each other for the spinlock just to update
the variable tracking who's in PM.

Let's optimize this a bit.  Specifically:

- Use a count rather than a bitmask.  This is faster to access and
  also means we can use the atomic_inc_return() function to really
  detect who the last one to enter PM was.
- Accept that it's OK if we race and are doing the flush (because we
  think we're last) while another CPU is coming out of idle.  As long
  as we block that CPU if/when it tries to do an active-only transfer
  we're OK.

Signed-off-by: Douglas Anderson 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20200504104917.v6.5.I295cb72bc5334a2af80313cbe97cb5c9dcb1442c@changeid
Signed-off-by: Bjorn Andersson

soc: qcom: rpmh-rsc: Simplify locking by eliminating the per-TCS lock

2020-05-15T18:44:58+00:00

The rpmh-rsc code had both a driver-level lock (sometimes referred to
in comments as drv->lock) and a lock per-TCS.  The idea was supposed
to be that there would be times where you could get by with just
locking a TCS lock and therefor other RPMH users wouldn't be blocked.

The above didn't work out so well.

Looking at tcs_write() the bigger drv->lock was held for most of the
function anyway.  Only the __tcs_buffer_write() and
__tcs_set_trigger() calls were called without holding the drv->lock.
It actually turns out that in tcs_write() we don't need to hold the
drv->lock for those function calls anyway even if the per-TCS lock
isn't there anymore.  From the newly added comments in the code, this
is because:
- We marked "tcs_in_use" under lock.
- Once "tcs_in_use" has been marked nobody else could be writing
  to these registers until the interrupt goes off.
- The interrupt can't go off until we trigger w/ the last line
  of __tcs_set_trigger().
Thus, from a tcs_write() point of view, the per-TCS lock was useless.

Looking at rpmh_rsc_write_ctrl_data(), only the per-TCS lock was held.
It turns out, though, that this function already needs to be called
with the equivalent of the drv->lock held anyway (we either need to
hold drv->lock as we will in a future patch or we need to know no
other CPUs could be running as happens today).  Specifically
rpmh_rsc_write_ctrl_data() might be writing to a TCS that has been
borrowed for writing an active transation but it never checks this.

Let's eliminate this extra overhead and avoid possible AB BA locking
headaches.

Suggested-by: Maulik Shah 
Signed-off-by: Douglas Anderson 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20200504104917.v6.4.Ib8dccfdb10bf6b1fb1d600ca1c21d9c0db1ef746@changeid
Signed-off-by: Bjorn Andersson

soc: qcom: rpmh-rsc: We aren't notified of our own failure w/ NOTIFY_BAD

2020-05-15T18:42:58+00:00

When a PM Notifier returns NOTIFY_BAD it doesn't get called with
CPU_PM_ENTER_FAILED.  It only get called for CPU_PM_ENTER_FAILED if
someone else (further down the notifier chain) returns NOTIFY_BAD.

Handle this case by taking our CPU out of the list of ones that have
entered PM.  Without this it's possible we could detect that the last
CPU went down (and we would flush) even if some CPU was alive.  That's
not good since our flushing routines currently assume they're running
on the last CPU for mutual exclusion.

Fixes: 985427f997b6 ("soc: qcom: rpmh: Invoke rpmh_flush() for dirty caches")
Signed-off-by: Douglas Anderson 
Reviewed-by: Maulik Shah 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20200504104917.v6.2.I1927d1bca2569a27b2d04986baf285027f0818a2@changeid
Signed-off-by: Bjorn Andersson

soc: qcom: rpmh-rsc: Correctly ignore CPU_CLUSTER_PM notifications

2020-05-15T18:42:29+00:00

Our switch statement doesn't have entries for CPU_CLUSTER_PM_ENTER,
CPU_CLUSTER_PM_ENTER_FAILED, and CPU_CLUSTER_PM_EXIT and doesn't have
a default.  This means that we'll try to do a flush in those cases but
we won't necessarily be the last CPU down.  That's not so ideal since
our (lack of) locking assumes we're on the last CPU.

Luckily this isn't as big a problem as you'd think since (at least on
the SoC I tested) we don't get these notifications except on full
system suspend.  ...and on full system suspend we get them on the last
CPU down.  That means that the worst problem we hit is flushing twice.
Still, it's good to make it correct.

Reviewed-by: Stephen Boyd 
Fixes: 985427f997b6 ("soc: qcom: rpmh: Invoke rpmh_flush() for dirty caches")
Reported-by: Stephen Boyd 
Signed-off-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20200504104917.v6.1.Ic7096b3b9b7828cdd41cd5469a6dee5eb6abf549@changeid
Signed-off-by: Bjorn Andersson

soc: qcom: rpmh-rsc: Timeout after 1 second in write_tcs_reg_sync()

2020-05-12T17:36:23+00:00

If our data still isn't there after 1 second, shout and give up.

Reported-by: Joe Perches 
Signed-off-by: Douglas Anderson 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20200415095953.v3.2.I8550512081c89ec7a545018a7d2d9418a27c1a7a@changeid
Signed-off-by: Bjorn Andersson

soc: qcom: rpmh-rsc: Factor "tcs_reg_addr" and "tcs_cmd_addr" calculation

2020-05-12T17:36:10+00:00

We can make some of the register access functions more readable by
factoring out the calculations a little bit.

Suggested-by: Joe Perches 
Signed-off-by: Douglas Anderson 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20200415095953.v3.1.Ic70288f256ff0be65cac6a600367212dfe39f6c9@changeid
Signed-off-by: Bjorn Andersson