Add minidump id for modem in sm8150 chipset so that the regions to be
included in the coredump generated upon a crash is based on the minidump
tables in SMEM instead of those in the ELF header.
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by, Reviewed-by or Tested-by that you received previously.:
Signed-off-by: NSiddharth Gupta <sidgup@codeaurora.org>
Link: https://lore.kernel.org/r/1605819935-10726-5-git-send-email-sidgup@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

This patch adds support for collecting minidump in the event of remoteproc
crash. Parse the minidump table based on remoteproc's unique minidump-id,
read all memory regions from the remoteproc's minidump table entry and
expose the memory to userspace. The remoteproc platform driver can choose
to collect a full/mini dump by specifying the coredump op.
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Co-developed-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Co-developed-by: NGurbir Arora <gurbaror@codeaurora.org>
Signed-off-by: NGurbir Arora <gurbaror@codeaurora.org>
Signed-off-by: NSiddharth Gupta <sidgup@codeaurora.org>
Link: https://lore.kernel.org/r/1605819935-10726-4-git-send-email-sidgup@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

This change adds a new kind of core dump mechanism which instead of dumping
entire program segments of the firmware, dumps sections of the remoteproc
memory which are sufficient to allow debugging the firmware. This function
thus uses section headers instead of program headers during creation of the
core dump elf.
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Co-developed-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: NSiddharth Gupta <sidgup@codeaurora.org>
Link: https://lore.kernel.org/r/1605819935-10726-3-git-send-email-sidgup@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Each remoteproc might have different requirements for coredumps and might
want to choose the type of dumps it wants to collect. This change allows
remoteproc drivers to specify their own custom dump function to be executed
in place of rproc_coredump. If the coredump op is not specified by the
remoteproc driver it will be set to rproc_coredump by default.
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NSiddharth Gupta <sidgup@codeaurora.org>
Link: https://lore.kernel.org/r/1605819935-10726-2-git-send-email-sidgup@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The correct MT8192 CFG register base is 0x20000 off.  Changes the
registers accordingly.

Fixes: fd0b6c1f ("remoteproc/mediatek: Add support for mt8192 SCP")
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201210054109.587795-1-tzungbi@google.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The K3 J721E family of SoCs have a revised version of the AM65x ICSSG IP
and contains two instances of this newer ICSSG IP. Each ICSSG processor
subsystem contains 2 primary PRU cores, 2 auxiliary PRU cores called RTUs,
and 2 new auxiliary cores called Transmit PRUs (Tx_PRUs).

Enhance the existing PRU remoteproc driver to support these new PRU
and RTU cores by using specific compatibles. The cores have the same
memory copying limitations as on AM65x, so reuses the custom memcpy
function within the driver's ELF loader implementation. The initial
names for the firmware images for each PRU core are retrieved from
DT nodes, and can be adjusted through sysfs if required.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Co-developed-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201208141002.17777-7-grzegorz.jaszczyk@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem, commonly referred to as ICSSG. Each ICSSG processor
subsystem on AM65x SR1.0 contains two primary PRU cores and two new
auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised
ICSSG IP that is based off the subsequent IP revision used on J721E
SoCs. This IP instance has two new custom auxiliary PRU cores called
Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs.

Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than
a PRU), Control and debug feature sets, but is different in terms of
sub-modules integrated around it and does not have the full capabilities
associated with a PRU core. The RTU core is typically used to aid a
PRU core in accelerating data transfers, while the Tx_PRU cores is
normally used to control the TX L2 FIFO if enabled in Ethernet
applications. Both can also be used to run independent applications.
The RTU and Tx_PRU cores though share the same Data RAMs as the PRU
cores, so the memories have to be partitioned carefully between different
applications. The new cores also support a new sub-module called Task
Manager to support two different context thread executions.

Enhance the existing PRU remoteproc driver to support these new PRU, RTU
and Tx PRU cores by using specific compatibles. The initial names for the
firmware images for each PRU core are retrieved from DT nodes, and can
be adjusted through sysfs if required.

The PRU remoteproc driver has to be specifically modified to use a
custom memcpy function within its ELF loader implementation for these
new cores in order to overcome a limitation with copying data into each
of the core's IRAM memories. These memory ports support only 4-byte
writes, and any sub-word order byte writes clear out the remaining
bytes other than the bytes being written within the containing word.
The default ARM64 memcpy also cannot be used as it throws an exception
when the preferred 8-byte copy operation is attempted. This choice is
made by using a state flag that is set only on K3 SoCs.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Co-developed-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201208141002.17777-6-grzegorz.jaszczyk@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The remoteproc core creates certain standard debugfs entries,
that does not give a whole lot of useful information for the
PRUs. The PRU remoteproc driver is enhanced to add additional
debugfs entries for PRU. These will be auto-cleaned up when
the parent rproc debug directory is removed.

The enhanced debugfs support adds two new entries: 'regs' and
'single_step'. The 'regs' dumps out the useful CTRL sub-module
registers as well as each of the 32 GPREGs and CT_REGs registers.
The GPREGs and CT_REGs though are printed only when the PRU is
halted and accessible as per the IP design.

The 'single_step' utilizes the single-step execution of the PRU
cores. Writing a non-zero value performs a single step, and a
zero value restores the PRU to execute in the same mode as the
mode before the first single step. (note: if the PRU is halted
because of a halt instruction, then no change occurs).

Logic for setting the PC and jumping over a halt instruction shall
be added in the future.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201208141002.17777-5-grzegorz.jaszczyk@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The firmware blob can contain optional ELF sections: .resource_table
section and .pru_irq_map one. The second one contains the PRUSS
interrupt mapping description, which needs to be setup before powering
on the PRU core. To avoid RAM wastage this ELF section is not mapped to
any ELF segment (by the firmware linker) and therefore is not loaded to
PRU memory.

The PRU interrupt configuration is handled within the PRUSS INTC irqchip
driver and leverages the system events to interrupt channels and host
interrupts mapping configuration. Relevant irq routing information is
passed through a special .pru_irq_map ELF section (for interrupts routed
to and used by PRU cores) or via the PRU application's device tree node
(for interrupts routed to and used by the main CPU). The mappings are
currently programmed during the booting/shutdown of the PRU.

The interrupt configuration passed through .pru_irq_map ELF section is
optional. It varies on specific firmware functionality and therefore
have to be unwinded during PRU stop and performed again during
PRU start.
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Co-developed-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Link: https://lore.kernel.org/r/20201208141002.17777-4-grzegorz.jaszczyk@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The Programmable Real-Time Unit Subsystem (PRUSS) consists of
dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)
for program execution. This patch adds a remoteproc platform
driver for managing the individual PRU RISC cores life cycle.

The PRUs do not have a unified address space (have an Instruction
RAM and a primary Data RAM at both 0x0). The PRU remoteproc driver
therefore uses a custom remoteproc core ELF loader ops. The added
.da_to_va ops is only used to provide translations for the PRU
Data RAMs. This remoteproc driver does not have support for error
recovery and system suspend/resume features. Different compatibles
are used to allow providing scalability for instance-specific device
data if needed. The driver uses a default firmware-name retrieved
from device-tree for each PRU core, and the firmwares are expected
to be present in the standard Linux firmware search paths. They can
also be adjusted by userspace if required through the sysfs interface
provided by the remoteproc core.

The PRU remoteproc driver uses a client-driven boot methodology: it
does _not_ support auto-boot so that the PRU load and boot is dictated
by the corresponding client drivers for achieving various usecases.
This allows flexibility for the client drivers or applications to set
a firmware name (if needed) based on their desired functionality and
boot the PRU. The sysfs bind and unbind attributes have also been
suppressed so that the PRU devices cannot be unbound and thereby
shutdown a PRU from underneath a PRU client driver.

The driver currently supports the AM335x, AM437x, AM57xx and 66AK2G
SoCs, and support for other TI SoCs will be added in subsequent
patches.
Co-developed-by: NAndrew F. Davis <afd@ti.com>
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Co-developed-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Signed-off-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201208141002.17777-3-grzegorz.jaszczyk@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit
RISC cores (Programmable Real-Time Units, or PRUs) for program execution.

The K3 AM65x amd J721E SoCs have the next generation of the PRU-ICSS IP,
commonly called ICSSG. The ICSSG IP on AM65x SoCs has two PRU cores,
two auxiliary custom PRU cores called Real Time Units (RTUs). The K3
AM65x SR2.0 and J721E SoCs have a revised version of the ICSSG IP, and
include two additional custom auxiliary PRU cores called Transmit PRUs
(Tx_PRUs).

This patch adds the bindings for these PRU cores. The binding covers the
OMAP architecture SoCs - AM33xx, AM437x and AM57xx; Keystone 2 architecture
based 66AK2G SoC; and the K3 architecture based SoCs - AM65x and J721E. The
Davinci based OMAPL138 SoCs will be covered in a future patch.
Reviewed-by: NRob Herring <robh@kernel.org>
Co-developed-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NGrzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org>
Link: https://lore.kernel.org/r/20201208141002.17777-2-grzegorz.jaszczyk@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

There is a spelling mistake in the Kconfig help text. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201204193411.1152006-1-colin.king@canonical.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The latest version of sysmon_stop() starts by initializing
the sysmon->shutdown_acked variable, but then overwrites it
with an uninitialized variable later:

drivers/remoteproc/qcom_sysmon.c:551:11: error: variable 'acked' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
        else if (sysmon->ept)
                 ^~~~~~~~~~~
drivers/remoteproc/qcom_sysmon.c:554:27: note: uninitialized use occurs here
        sysmon->shutdown_acked = acked;
                                 ^~~~~

Remove the local 'acked' variable again and set the state directly.

Fixes: 5c212aaf ("remoteproc: sysmon: Expose the shutdown result")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20201204193740.3162065-1-arnd@kernel.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The J7200 SoCs have a revised R5FSS IP that adds a unique feature w.r.t
TCM sizing. Each R5F core in a cluster typically has 32 KB each of ATCM
and BTCM, with only the Core0 TCMs usable in LockStep mode. This revised
IP however doubles the total available TCM in LockStep mode by making the
Core1 TCM visible immediately after the corresponding Core0 TCM.

The R5F DT nodes on the J7200 SoCs define double (64 KB) the normal TCM
size (32 KB) for R5F Core0 for each of ATCM and BTCM to represent the
above. This increased TCM memory is only usable in LockStep-mode, and
has to be adjusted to the normal 32 KB size in Split mode. Enhance the
TI K3 R5F remoteproc for this logic through a new function. The adjustment
is a no-op on prior SoCs and relies on the correct DTS node sizes in
LockStep-mode on applicable SoCs.
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20201119010531.21083-4-s-anna@ti.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The K3 J7200 SoC family has a revised R5F sub-system and contains a
subset of the R5F clusters present on J721E SoCs. The K3 J7200 SoCs
only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
each. One cluster is present within the MCU voltage domain (MCU_R5FSS0),
while the other is present in the MAIN voltage domain (MAIN_R5FSS0).

The revised IP has the following two new features:
 1. TCMs are auto-initialized during module power-up, and the behavior
    is programmable through a MMR bit.
 2. The LockStep-mode allows the Core1 TCMs to be combined with the
    Core0 TCMs effectively doubling the amount of TCMs available.
    The LockStep-mode on previous SoCs could only use the Core0 TCMs.
    This combined TCMs appear contiguous at the respective Core0 TCM
    addresses.

Extend the support to these clusters in the K3 R5F remoteproc driver
using J7200 specific compatibles. Logic for the second feature is
added in the next patch. The integration of these clusters is very
much similar to J721E SoCs otherwise.
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20201119010531.21083-3-s-anna@ti.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The TI K3 J7200 SoCs have two dual-core Arm R5F clusters/subsystems,
with 2 R5F cores each, one in each of the MCU and MAIN voltage domains.

These clusters are a revised IP version compared to those present on
J721E SoCs. Update the K3 R5F remoteproc bindings with the compatible
info relevant to these R5F clusters/subsystems on K3 J7200 SoCs.
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20201119010531.21083-2-s-anna@ti.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

A new API, rproc_set_firmware() is added to allow the remoteproc platform
drivers and remoteproc client drivers to be able to configure a custom
firmware name that is different from the default name used during
remoteproc registration. This function is being introduced to provide
a kernel-level equivalent of the current sysfs interface to remoteproc
client drivers, and can only change firmwares when the remoteproc is
offline. This allows some remoteproc drivers to choose different firmwares
at runtime based on the functionality the remote processor is providing.
The TI PRU Ethernet driver will be an example of such usage as it
requires to use different firmwares for different supported protocols.

Also, update the firmware_store() function used by the sysfs interface
to reuse this function to avoid code duplication.
Reviewed-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Link: https://lore.kernel.org/r/20201121032042.6195-1-s-anna@ti.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Improve the style of a few of the error messages printed by the sysmon
implementation and fix the copy-pasted shutdown error in the send-event
function.
Tested-by: NSteev Klimaszewski <steev@kali.org>
Reviewed-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Link: https://lore.kernel.org/r/20201122054135.802935-5-bjorn.andersson@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Requesting a graceful shutdown through the shared memory state signals
will not be acked in the event that sysmon has already successfully shut
down the remote firmware. So extend the stop request API to optionally
take the remoteproc's sysmon instance and query if there's already been
a successful shutdown attempt, before doing the signal dance.
Tested-by: NSteev Klimaszewski <steev@kali.org>
Reviewed-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Link: https://lore.kernel.org/r/20201122054135.802935-4-bjorn.andersson@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

A graceful shutdown of the Qualcomm remote processors where
traditionally performed by invoking a shared memory state signal and
waiting for the associated ack.

This was later superseded by the "sysmon" mechanism, where some form of
shared memory bus is used to send a "graceful shutdown request" message
and one of more signals comes back to indicate its success.

But when this newer mechanism is in effect the firmware is shut down by
the time the older mechanism, implemented in the remoteproc drivers,
attempts to perform a graceful shutdown - and as such it will never
receive an ack back.

This patch therefor track the success of the latest shutdown attempt in
sysmon and exposes a new function in the API that the remoteproc driver
can use to query the success and the necessity of invoking the older
mechanism.
Tested-by: NSteev Klimaszewski <steev@kali.org>
Reviewed-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Link: https://lore.kernel.org/r/20201122054135.802935-3-bjorn.andersson@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The reliance on the remoteproc's state for determining when to send
sysmon notifications to a remote processor is racy with regard to
concurrent remoteproc operations.

Further more the advertisement of the state of other remote processor to
a newly started remote processor might not only send the wrong state,
but might result in a stream of state changes that are out of order.

Address this by introducing state tracking within the sysmon instances
themselves and extend the locking to ensure that the notifications are
consistent with this state.

Fixes: 1f36ab3f ("remoteproc: sysmon: Inform current rproc about all active rprocs")
Fixes: 1877f54f ("remoteproc: sysmon: Add notifications for events")
Fixes: 1fb82ee8 ("remoteproc: qcom: Introduce sysmon")
Cc: stable@vger.kernel.org
Reviewed-by: NRishabh Bhatnagar <rishabhb@codeaurora.org>
Link: https://lore.kernel.org/r/20201122054135.802935-2-bjorn.andersson@linaro.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The application processor accessing the MBA region after assigning it to
the remote Q6 would lead to an XPU violation. Fix this by un-mapping the
MBA region post firmware copy and MBA text log dumps.
Signed-off-by: NSibi Sankar <sibis@codeaurora.org>
Link: https://lore.kernel.org/r/1604473422-29639-2-git-send-email-sibis@codeaurora.org
[bjorn: Renamed "ptr" to "mba_region"]
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Fix the sparse warnings reported by the kernel test bot by replacing
ioremap calls with memremap.
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NSibi Sankar <sibis@codeaurora.org>
Link: https://lore.kernel.org/r/1604473422-29639-1-git-send-email-sibis@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The only usage of qmi_indication_handler[] is to pass its address to
qmi_handle_init() which accepts a const pointer. Make it const to allow
the compiler to put it in read-only memory.
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20201122234540.34623-1-rikard.falkeborn@gmail.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The main purpose of the loop is to load the memory to the SCP SRAM.
If filesz is 0, can go to next program header directly.

We don't need to try to validate the FW binary for those filesz==0
segments.
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201116084413.3312631-3-tzungbi@google.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

It is valid if offset+length == sram_size.

For example, sram_size=100, offset=99, length=1.  Accessing offset 99
with length 1 is valid.
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201116084413.3312631-2-tzungbi@google.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Fixes the following sparse errors on dma_alloc_coherent() and
dma_free_coherent().

On drivers/remoteproc/mtk_scp.c:559:23:
warning: incorrect type in assignment (different address spaces)
   expected void [noderef] __iomem *cpu_addr
   got void *

On drivers/remoteproc/mtk_scp.c:572:56:
warning: incorrect type in argument 3 (different address spaces)
   expected void *cpu_addr
   got void [noderef] __iomem *cpu_addr

The cpu_addr is not a __iomem address.  Removes the marker.
Reviewed-by: NNicolas Boichat <drinkcat@chromium.org>
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201116082537.3287009-3-tzungbi@google.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Fixes the following sparse errors on sram power on and off:

On drivers/remoteproc/mtk_scp.c:306:17:
warning: incorrect type in argument 2 (different address spaces)
   expected void volatile [noderef] __iomem *addr
   got void *addr

On drivers/remoteproc/mtk_scp.c:307:9:
warning: incorrect type in argument 2 (different address spaces)
   expected void volatile [noderef] __iomem *addr
   got void *addr

On drivers/remoteproc/mtk_scp.c:314:9:
warning: incorrect type in argument 2 (different address spaces)
   expected void volatile [noderef] __iomem *addr
   got void *addr

On drivers/remoteproc/mtk_scp.c:316:17:
warning: incorrect type in argument 2 (different address spaces)
   expected void volatile [noderef] __iomem *addr
   got void *addr
Reviewed-by: NNicolas Boichat <drinkcat@chromium.org>
Reviewed-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NTzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20201116082537.3287009-2-tzungbi@google.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The only usage of st_rproc_ops is to pass its address to rproc_alloc()
which accepts a const pointer. Make it const to allow the compiler to
put it in read-only memory.
Acked-by: NArnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20201107233630.9728-3-rikard.falkeborn@gmail.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The only usage of ingenic_rproc_ops is to pass its address to
devm_rproc_alloc(), which accepts a const pointer. Make it const to
allow the compiler to put it in read-only memory.
Acked-by: NPaul Cercueil <paul@crapouillou.net>
Signed-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20201107233630.9728-2-rikard.falkeborn@gmail.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The function cast causes a warning with "make W=1"

drivers/remoteproc/ti_k3_r5_remoteproc.c: In function 'k3_r5_probe':
drivers/remoteproc/ti_k3_r5_remoteproc.c:1368:12: warning: cast between incompatible function types from 'int (*)(struct platform_device *)' to 'void (*)(void *)' [-Wcast-function-type]

Rewrite the code to avoid the cast, and fix the incorrect return
type of the callback.

Fixes: 6dedbd1d ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20201026160533.3705998-1-arnd@kernel.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Align other syscon descriptions with st,syscfg-m4-state and
st,syscfg-rsc-tbl descriptions by suppressing the cells
description.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NArnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20201014125441.2457-4-arnaud.pouliquen@st.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Add new properties description used to attach to a pre-loaded
firmware according to the commit 9276536f
("remoteproc: stm32: Parse syscon that will manage M4 synchronisation")
which updates the driver part.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NArnaud Pouliquen <arnaud.pouliquen@st.com>
Link: https://lore.kernel.org/r/20201014125441.2457-3-arnaud.pouliquen@st.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Since commit ad440432 ("dt-bindings: mfd: Ensure 'syscon' has a
more specific compatible")
It is required to provide at least 2 compatibles string for syscon node.
This patch documents the new compatible for stm32 SoC to support
TAMP registers access.
Signed-off-by: NArnaud Pouliquen <arnaud.pouliquen@st.com>
Acked-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201014125441.2457-2-arnaud.pouliquen@st.comSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

So far we have been doing all proxy votes by voting for raw voltages/load
through the regulator interface. But actually VDDCX and VDDMX represent
power domains that should be preferably managed using corner votes
through the power domain interface.

Looking closer the code was actually never doing the proxy votes
correctly: The vddcx regulator is specified as:

	{ "vddcx", .super_turbo = true },

which is supposed to say that we should vote for the maximum corner
of the VDDCX power domain. But actually "super_turbo" is unused so
all we did so far is to enable the power domain. We did not vote for
it to scale to the maximum performance state.

Using them through the power domain interface allows voting for the
maximum performance state. However, we still need to support using
them through the regulator interface for old device trees.

The way this is implemented here is that we check if attaching the
two power domain succeeds. If yes, we skip the first "num_pd_vregs"
regulators in the "vregs" list and only request the remaining ones.
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-9-stephan@gerhold.netSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

So far we have been doing all proxy votes by voting for raw voltages/load
through the regulator interface. But actually VDDCX and VDDMX represent
power domains that should be preferably managed using corner votes
through the power domain interface.

Document that those should be specified as power domains for
qcom,pronto-v1/2-pil and deprecate using them through the regulator
interface.
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-8-stephan@gerhold.netSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Newer platforms vote for necessary power domains through the power
domain subsystem. For historical reasons older platforms like MSM8916
or MSM8974 still control these as regulators.

Managing them as power domains is preferred since that allows us
to vote for corners instead of raw voltages.

Make it possible for MSM8916 and MSM8974 to manage these as power
domains. For compatibility with old device trees we still need to
support falling back to the regulators when necessary.

The way this is implemented here is that the deprecated regulators
are defined as "fallback_proxy_supply". Only if attaching the power
domains fails because they are not specified (-ENODATA) we request
and manage the fallback regulators instead.
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-7-stephan@gerhold.netSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Newer platforms vote for necessary power domains through the power
domain subsystem. For historical reasons older platforms like MSM8916
or MSM8974 still control these as regulators.

Managing them as power domains is preferred since that allows us
to vote for corners instead of raw voltages. Document that those
should be specified as power domains and deprecate using them
through the regulator interface.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200916104135.25085-6-stephan@gerhold.netSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Use a more generic form for __section that requires quotes to avoid
complications with clang and gcc differences.

Remove the quote operator # from compiler_attributes.h __section macro.

Convert all unquoted __section(foo) uses to quoted __section("foo").
Also convert __attribute__((section("foo"))) uses to __section("foo")
even if the __attribute__ has multiple list entry forms.

Conversion done using the script at:

    https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.plSigned-off-by: NJoe Perches <joe@perches.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@gooogle.com>
Reviewed-by: NMiguel Ojeda <ojeda@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>