summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-08-18Merge tag 'renesas-drivers-for-v5.15-tag2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/drivers Renesas driver updates for v5.15 (take two) - Prefer memcpy() over strcpy(). * tag 'renesas-drivers-for-v5.15-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: Prefer memcpy() over strcpy() Link: https://lore.kernel.org/r/cover.1628849625.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'tegra-for-5.15-soc' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/drivers soc/tegra: Changes for v5.15-rc1 Implements runtime PM support for the FUSE block and prepares the driver to work better in conjunction with the CPUIDLE driver. * tag 'tegra-for-5.15-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: soc/tegra: fuse: Enable fuse clock on suspend for Tegra124 soc/tegra: fuse: Add runtime PM support soc/tegra: fuse: Clear fuse->clk on driver probe failure soc/tegra: pmc: Prevent racing with cpuilde driver soc/tegra: bpmp: Remove unused including <linux/version.h> Link: https://lore.kernel.org/r/20210813162157.2820913-3-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-18Merge tag 'tegra-for-5.15-firmware' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/drivers firmware: tegra: Changes for v5.15-rc1 This contains a single fix to stop a slight abuse of the seq_buf API. * tag 'tegra-for-5.15-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: firmware: tegra: Stop using seq_get_buf() Link: https://lore.kernel.org/r/20210813162157.2820913-2-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12Merge tag 'scmi-updates-5.15' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/drivers SCMI Updates for v5.15 The bulk of the addition this time is mainly refactoring to add support for Virtio transport for SCMI and the addition of the support itself. The refactoring includes allowing transport specific init/exit calls, making each transport as compile time configurable, supporting monotonically increasing tokens instead of using the next available free buffer index as the token for scmi messages which eases handling concurrent and out-of-order messages which is a must have for virtio transport. Virtio support itself is conformant to the virtio SCMI device spec [1]. Virtio device id 32 has been reserved for the SCMI device [2]. Other than the virtio support, there is one bug fix in the probe failure clean up path. [1] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex [2] https://www.oasis-open.org/committees/ballot.php?id=3496 * tag 'scmi-updates-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Use WARN_ON() to check configured transports firmware: arm_scmi: Fix boolconv.cocci warnings firmware: arm_scmi: Free mailbox channels if probe fails firmware: arm_scmi: Add virtio transport firmware: arm_scmi: Add priv parameter to scmi_rx_callback dt-bindings: arm: Add virtio transport for SCMI firmware: arm_scmi: Add optional link_supplier() transport op firmware: arm_scmi: Add message passing abstractions for transports firmware: arm_scmi: Add method to override max message number firmware: arm_scmi: Make shmem support optional for transports firmware: arm_scmi: Make SCMI transports configurable firmware: arm_scmi: Make polling mode optional firmware: arm_scmi: Make .clear_channel optional firmware: arm_scmi: Handle concurrent and out-of-order messages firmware: arm_scmi: Introduce monotonically increasing tokens firmware: arm_scmi: Add optional transport_init/exit support firmware: arm_scmi: Remove scmi_dump_header_dbg() helper firmware: arm_scmi: Add support for type handling in common functions Link: https://lore.kernel.org/r/20210811075743.707961-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12Merge tag 'drivers_soc_for_5.15' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone into arm/drivers soc: Keystone SOC drivers for v5.15 The pull request contains: - ICSSG subsystem support for Keystone3 AM64x SOCs - Removes smartrefelx PM dependency for deeper low power states * tag 'drivers_soc_for_5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone: dt-bindings: soc: ti: pruss: Add dma-coherent property soc: ti: Remove pm_runtime_irq_safe() usage for smartreflex soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM64x SoCs dt-bindings: soc: ti: pruss: Update bindings for K3 AM64x SoCs Link: https://lore.kernel.org/r/0A637A41-2353-4900-962C-DBE50BBDE75A@oracle.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12Merge tag 'memory-controller-drv-5.15' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/drivers Memory controller drivers for v5.15 Few minor fixes: maintainer pattern, unused-function warning in Tegra186 and suspend/resume in OMAP GPMC. * tag 'memory-controller-drv-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl: memory: omap-gpmc: Drop custom PM calls with cpu_pm notifier memory: omap-gpmc: Clear GPMC_CS_CONFIG7 register on restore if unused MAINTAINERS: update arm,pl353-smc.yaml reference memory: tegra: fix unused-function warning Link: https://lore.kernel.org/r/20210809152639.110576-1-krzysztof.kozlowski@canonical.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12Merge tag 'v5.14-next-soc' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into arm/drivers pm-domains: - correct mask define if used for update on TOPAXI bus - mt8173: enable regulator befor turning on MFG_ASYNC mmsys: - add a mask property to the routing information - add support for MT8365 - add UFOE routing for MT8173 * tag 'v5.14-next-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: soc: mediatek: mmsys: Fix missing UFOE component in mt8173 table routing soc: mediatek: mmsys: add MT8365 support soc: mmsys: mediatek: add mask to mmsys routes soc: mediatek: pm-domains: Add domain_supply cap for mfg_async PD soc: mediatek: pm-domains: Use correct mask for bus_prot_clr Link: https://lore.kernel.org/r/49fc7bef-20db-b98c-9437-dd9e4d00e870@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12Merge tag 'imx-ecspi-5.15' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/drivers i.MX eCSPI errata handling for 5.15: It includes all required changes for handling i.MX6/7 eCSPI errata ERR009165, which causes FIFO transfer to be sent twice in DMA mode. Both SPI and DMA maintainers agree to merge it through arm-soc tree. * tag 'imx-ecspi-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: dmaengine: imx-sdma: add terminated list for freed descriptor in worker dmaengine: imx-sdma: add uart rom script dma: imx-sdma: add i.mx6ul compatible name dmaengine: imx-sdma: remove ERR009165 on i.mx6ul spi: imx: remove ERR009165 workaround on i.mx6ul spi: imx: fix ERR009165 dmaengine: imx-sdma: add mcu_2_ecspi script dmaengine: dma: imx-sdma: add fw_loaded and is_ram_script dmaengine: imx-sdma: remove duplicated sdma_load_context Revert "dmaengine: imx-sdma: refine to load context only once" Revert "ARM: dts: imx6: Use correct SDMA script for SPI cores" Revert "ARM: dts: imx6q: Use correct SDMA script for SPI5 core" Link: https://lore.kernel.org/r/20210809071838.GF30984@dragon Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12bus: ixp4xx: return on error in ixp4xx_exp_probe()Dan Carpenter
This code was intended to return an error code if regmap_read() fails but the return statement was missing. Fixes: 1c953bda90ca ("bus: ixp4xx: Add a driver for IXP4xx expansion bus") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210807230016.3607666-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12Merge tag 'omap-for-v5.15/ti-sysc-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/drivers Driver changes for ti-sysc for v5.15 Few ti-sysc changes to handle quirk for McASP SIDLE mode, correct documentation for sysc_ioremap(), and start using pm_runtime_resume_and_get(). * tag 'omap-for-v5.15/ti-sysc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: bus: ti-sysc: Add quirk for OMAP4 McASP to disable SIDLE mode bus: ti-sysc: using pm_runtime_resume_and_get instead of pm_runtime_get_sync bus: ti-sysc: Correct misdocumentation of 'sysc_ioremap()' bus: ti-sysc: Fix gpt12 system timer issue with reserved status Link: https://lore.kernel.org/r/pull-1628153040-834155@atomide.com-2 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12soc: renesas: Prefer memcpy() over strcpy()Len Baker
strcpy() performs no bounds checking on the destination buffer. This could result in linear overflows beyond the end of the buffer, leading to all kinds of misbehaviors. So, use memcpy() as a safe replacement. This is a previous step in the path to remove the strcpy() function entirely from the kernel. Signed-off-by: Len Baker <len.baker@gmx.com> Link: https://lore.kernel.org/r/20210808125012.4715-3-len.baker@gmx.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-08-11firmware: tegra: Stop using seq_get_buf()Christoph Hellwig
Opencode a copy of mrq_debug_read() in bpmp_debug_show() so that it can use seq_write() directly instead of poking holes into the seq_file abstractions using seq_get_buf(). Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-08-11soc/tegra: fuse: Enable fuse clock on suspend for Tegra124Dmitry Osipenko
The FUSE clock should be enabled during suspend on Tegra124. Currently clk driver enables it on all SoCs, but FUSE may require a higher core voltage on Tegra30 while enabled. Move the quirk into the FUSE driver and make it specific to Tegra124. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-08-11soc/tegra: fuse: Add runtime PM supportDmitry Osipenko
The Tegra FUSE belongs to the core power domain and we're going to enable GENPD support for the core domain. Now FUSE device must be resumed using runtime PM API in order to initialize the FUSE power state. Add runtime PM support to the FUSE driver. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-08-11soc/tegra: fuse: Clear fuse->clk on driver probe failureDmitry Osipenko
The fuse->clk must be cleared if FUSE driver fails to probe, otherwise tegra_fuse_readl() will crash. It's unlikely to happen in practice, nevertheless let's correct it for completeness. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-08-11soc/tegra: pmc: Prevent racing with cpuilde driverDmitry Osipenko
Both PMC and cpuidle drivers are probed at the same init level and cpuidle depends on the PMC suspend mode. Add new default suspend mode that indicates whether PMC driver has been probed and reset the mode in a case of deferred probe of the PMC driver. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-08-11soc/tegra: bpmp: Remove unused including <linux/version.h>Cai Huoqing
Remove including <linux/version.h> that don't need it. V1->V2: Split the patch in two Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-08-10dt-bindings: soc: ti: pruss: Add dma-coherent propertySuman Anna
Update the PRUSS schema file to include the dma-coherent property that indicates the coherency of the IP. The PRUSS IPs on 66AK2G SoCs do use this property. The new added dma-coherent property is a required property _only_ for 66AK2G SoCs and is not required/applicable for other SoCs, so the binding is backward compatible for other SoCs. This update is being done before the corresponding dts nodes can be added for 66AK2G SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-08-10soc: ti: Remove pm_runtime_irq_safe() usage for smartreflexTony Lindgren
For the smartreflex device, we need to disable smartreflex on SoC idle, and have been using pm_runtime_irq_safe() to do that. But we want to remove the irq_safe usage as PM runtime takes a permanent usage count on the parent device with it. In order to remove the need for pm_runtime_irq_safe(), let's gate the clock directly in the driver. This removes the need to call PM runtime during idle, and allows us to switch to using CPU_PM in the following patch. Note that the smartreflex interconnect target module is configured for smart idle, but the clock does not have autoidle capability, and needs to be gated manually. If the clock supported autoidle, we would not need to even gate the clock. With this change, we can now remove the related quirk flags for ti-sysc also. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-08-10soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM64x SoCsSuman Anna
The K3 AM64x family of SoCs have a similar version of the PRU-ICSS (ICSSG) processor subsystem present on K3 J721E and K3 AM65x SR2.0 SoCs. These SoCs contain typically two ICSSG instances named ICSSG0 and ICSSG1. The two ICSSGs are identical to each other for the most part with minor SoC integration differences and capabilities. SGMII mode is not supported at all on these SoCs (unlike specific instances on AM65x, J721E). The ICSSG1 also has limited pins connected on some sub-modules compared to ICSSG0. There is no change in the Interrupt Controller w.r.t either of AM65x or J721E SoCs. All other integration aspects are also very similar to the existing SoCs. The existing pruss platform driver has been updated to support these similar ICSSG instances through a new AM64x specific compatible. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-08-10dt-bindings: soc: ti: pruss: Update bindings for K3 AM64x SoCsSuman Anna
The K3 AM64x SoCs also have the Gigabit Ethernet capable PRU-ICSS IP that is present on existing K3 AM65x and J721E SoCs (ICSSG). The IP is similar to the ones used on K3 J721E or AM65x SR2.0 SoCs. Update the PRUSS bindings for these ICSSG instances. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2021-08-09firmware: arm_scmi: Use WARN_ON() to check configured transportsCristian Marussi
Use a WARN_ON() when SCMI stack is loaded to check the consistency of configured SCMI transports instead of the current compile-time check BUILD_BUG_ON() to avoid breaking bot-builds on random bad configs. Bail-out early and noisy during SCMI stack initialization if no transport was enabled in configuration since SCMI cannot work without at least one enabled transport and such constraint cannot be enforced in Kconfig due to circular dependency issues. Link: https://lore.kernel.org/r/20210809092245.8730-1-cristian.marussi@arm.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-09firmware: arm_scmi: Fix boolconv.cocci warningskernel test robot
drivers/firmware/arm_scmi/virtio.c:225:40-45: WARNING: conversion to bool not needed here Remove unneeded conversion to bool Semantic patch information: Relational and logical operators evaluate to bool, explicit conversion is overly verbose and unneeded. Generated by: scripts/coccinelle/misc/boolconv.cocci Link: https://lore.kernel.org/r/20210807173127.GA43248@a24dbc127934 CC: Igor Skalkin <igor.skalkin@opensynergy.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-06soc: mediatek: mmsys: Fix missing UFOE component in mt8173 table routingEnric Balletbo i Serra
The UFOE (data compression engine) component needs to be enabled to have the imgtec gpu driver working. If we don't enable it we see a black screen. Looks like when we switched to use and array for setting the routing registers in commit 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers") we missed to add this component in the new routing table, it was present before that commit, so fix it by adding this component in the mt8173 routing table. Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers") Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Eizan Miyamoto <eizan@chromium.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210625062448.3462177-1-enric.balletbo@collabora.com [mb: taking into account mask value] Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-08-06soc: mediatek: mmsys: add MT8365 supportFabien Parent
Add DSI mmsys connections for the MT8365 SoC. Signed-off-by: Fabien Parent <fparent@baylibre.com> Link: https://lore.kernel.org/r/20210519161847.3747352-3-fparent@baylibre.com [mb: take the mask field into account] Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-08-05firmware: arm_scmi: Free mailbox channels if probe failsRishabh Bhatnagar
Mailbox channels for the base protocol are setup during probe. There can be a scenario where probe fails to acquire the base protocol due to a timeout leading to cleaning up of all device managed memory including the scmi_mailbox structure setup during mailbox_chan_setup function. | arm-scmi soc:qcom,scmi: timed out in resp(caller: version_get+0x84/0x140) | arm-scmi soc:qcom,scmi: unable to communicate with SCMI | arm-scmi: probe of soc:qcom,scmi failed with error -110 Now when a message arrives at cpu slightly after the timeout, the mailbox controller will try to call the rx_callback of the client and might end up accessing freed memory. | rx_callback+0x24/0x160 | mbox_chan_received_data+0x44/0x94 | __handle_irq_event_percpu+0xd4/0x240 This patch frees the mailbox channels setup during probe and adds some more error handling in case the probe fails. Link: https://lore.kernel.org/r/1628111999-21595-1-git-send-email-rishabhb@codeaurora.org Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add virtio transportIgor Skalkin
This transport enables communications with an SCMI platform through virtio; the SCMI platform will be represented by a virtio device. Implement an SCMI virtio driver according to the virtio SCMI device spec [1]. Virtio device id 32 has been reserved for the SCMI device [2]. The virtio transport has one Tx channel (virtio cmdq, A2P channel) and at most one Rx channel (virtio eventq, P2A channel). The following feature bit defined in [1] is not implemented: VIRTIO_SCMI_F_SHARED_MEMORY. The number of messages which can be pending simultaneously is restricted according to the virtqueue capacity negotiated at probing time. As soon as Rx channel message buffers are allocated or have been read out by the arm-scmi driver, feed them back to the virtio device. Since some virtio devices may not have the short response time exhibited by SCMI platforms using other transports, set a generous response timeout. SCMI polling mode is not supported by this virtio transport since deemed meaningless: polling mode operation is offered by the SCMI core to those transports that could not provide a completion interrupt on the TX path, which is never the case for virtio whose core callbacks can easily call into core scmi_rx_callback upon messages reception. [1] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex [2] https://www.oasis-open.org/committees/ballot.php?id=3496 Link: https://lore.kernel.org/r/20210803131024.40280-16-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: simplified driver logic, changed link_supplier and channel available/setup logic, removed dummy callbacks ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add priv parameter to scmi_rx_callbackCristian Marussi
Add a new opaque void *priv parameter to scmi_rx_callback which can be optionally provided by the transport layer when invoking scmi_rx_callback and that will be passed back to the transport layer in xfer->priv. This can be used by transports that needs to keep track of their specific data structures together with the valid xfers. Link: https://lore.kernel.org/r/20210803131024.40280-15-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05dt-bindings: arm: Add virtio transport for SCMIIgor Skalkin
Document the properties for arm,scmi-virtio compatible nodes. The backing virtio SCMI device is described in patch [1]. While doing that, make shmem property required only for pre-existing mailbox and smc transports, since virtio-scmi does not need it. [1] https://lists.oasis-open.org/archives/virtio-comment/202102/msg00018.html Link: https://lore.kernel.org/r/20210803131024.40280-14-cristian.marussi@arm.com Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: converted to yaml format, moved shmen required property. ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add optional link_supplier() transport opPeter Hilber
Some transports are also effectively registered with other kernel subsystem in order to be properly probed and initialized; as a consequence such kind of transports, and their related devices, might still not have been probed and initialized at the time the main SCMI core driver is probed. Add an optional .link_supplier() transport operation which can be used by the core SCMI stack to dynamically check if the transport is ready and dynamically link its device to the SCMI platform instance device. Link: https://lore.kernel.org/r/20210803131024.40280-13-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: reworded commit message ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add message passing abstractions for transportsPeter Hilber
Add abstractions for future transports using message passing, such as virtio. Derive the abstractions from the shared memory abstractions. Abstract the transport SDU through the opaque struct scmi_msg_payld. Also enable the transport to determine all other required information about the transport SDU. Link: https://lore.kernel.org/r/20210803131024.40280-12-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Adapted to new SCMI Kconfig layout, updated Copyrights ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add method to override max message numberIgor Skalkin
The maximum number of simultaneously pending messages is a transport specific quantity that is usually described statically in struct scmi_desc. Some transports, though, can calculate such number only at run-time after some initial transport specific setup and probing is completed; moreover the resulting max message numbers could also be different between rx and tx channels. Add an optional get_max_msg() operation so that a transport can report more accurate max message numbers for each channel type. The value in scmi_desc.max_msg is still used as default when transport does not provide any get_max_msg() method. Link: https://lore.kernel.org/r/20210803131024.40280-11-cristian.marussi@arm.com Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: refactored how get_max_msg() is used to minimize core changes ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Make shmem support optional for transportsIgor Skalkin
Upcoming new SCMI transports won't need any kind of shared memory support. Compile shmem.c only if a shmem based transport is selected. Link: https://lore.kernel.org/r/20210803131024.40280-10-cristian.marussi@arm.com Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Adapted patch/commit_msg to new SCMI Kconfig layout ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Make SCMI transports configurableCristian Marussi
Add configuration options to be able to select which SCMI transports have to be compiled into the SCMI stack. Mailbox and SMC are by default enabled if their related dependencies are satisfied. While doing that move all SCMI related config options in their own dedicated submenu. Link: https://lore.kernel.org/r/20210803131024.40280-9-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Make polling mode optionalCristian Marussi
Add a check for the presence of .poll_done transport operation so that transports that do not need to support polling mode have no need to provide a dummy .poll_done callback either and polling mode can be disabled in the SCMI core for that tranport. Link: https://lore.kernel.org/r/20210803131024.40280-8-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Make .clear_channel optionalCristian Marussi
Make transport operation .clear_channel optional since some transports do not need it and so avoid to have them implement dummy callbacks. Link: https://lore.kernel.org/r/20210803131024.40280-7-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Handle concurrent and out-of-order messagesCristian Marussi
Even though in case of asynchronous commands an SCMI platform is constrained to emit the delayed response message only after the related message response has been sent, the configured underlying transport could still deliver such messages together or in inverted order, causing races due to the concurrent or out-of-order access to the underlying xfer. Introduce a mechanism to grant exclusive access to an xfer in order to properly serialize concurrent accesses to the same xfer originating from multiple correlated messages. Add additional state information to xfer descriptors so as to be able to identify out-of-order message deliveries and act accordingly: - when a delayed response is expected but delivered before the related response, the synchronous response is considered as successfully received and the delayed response processing is carried on as usual. - when/if the missing synchronous response is subsequently received, it is discarded as not congruent with the current state of the xfer, or simply, because the xfer has been already released and so, now, the monotonically increasing sequence number carried by the late response is stale. Link: https://lore.kernel.org/r/20210803131024.40280-6-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Introduce monotonically increasing tokensCristian Marussi
Tokens are sequence numbers embedded in the each SCMI message header: they are used to correlate commands with responses (and delayed responses), but their usage and policy of selection is entirely up to the caller (usually the OSPM agent), while they are completely opaque to the callee (i.e. SCMI platform) which merely copies them back from the command into the response message header. This also means that the platform does not, can not and should not enforce any kind of policy on received messages depending on the contained sequence number: platform can perfectly handle concurrent requests carrying the same identifiying token if that should happen. Moreover the platform is not required to produce in-order responses to agent requests, the only constraint in these regards is that in case of an asynchronous message the delayed response must be sent after the immediate response for the synchronous part of the command transaction. Currenly the SCMI stack of the OSPM agent selects a token for the egressing commands picking the lowest possible number which is not already in use by an existing in-flight transaction, which means, in other words, that we immediately reuse any token after its transaction has completed or it has timed out: this policy indeed does simplify management and lookup of tokens and associated xfers. Under the above assumptions and constraints, since there is really no state shared between the agent and the platform to let the platform know when a token and its associated message has timed out, the current policy of early reuse of tokens can easily lead to the situation in which a spurious or late received response (or delayed_response), related to an old stale and timed out transaction, can be wrongly associated to a newer valid in-flight xfer that just happens to have reused the same token. This misbehaviour on such late/spurious responses is more easily exposed on those transports that naturally have an higher level of parallelism in processing multiple concurrent in-flight messages. This commit introduces a new policy of selection of tokens for the OSPM agent: each new command transfer now gets the next available, monotonically increasing token, until tokens are exhausted and the counter rolls over. Such new policy mitigates the above issues with late/spurious responses since the tokens are now reused as late as possible (when they roll back ideally) and so it is much easier to identify such late/spurious responses to stale timed out transactions: this also helps in simplifying the specific transports implementation since stale transport messages can be easily identified and discarded early on in the rx path without the need to cross check their actual state with the core transport layer. This mitigation is even more effective when, as is usually the case, the maximum number of pending messages is capped by the platform to a much lower number than the whole possible range of tokens values (2^10). This internal policy change in the core SCMI transport layer is fully transparent to the specific transports so it has not and should not have any impact on the transports implementation. Link: https://lore.kernel.org/r/20210803131024.40280-5-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add optional transport_init/exit supportCristian Marussi
Some SCMI transport could need to perform some transport specific setup before they can be used by the SCMI core transport layer: typically this early setup consists in registering with some other kernel subsystem. Add the optional capability for a transport to provide a couple of init and exit functions that are assured to be called early during the SCMI core initialization phase, well before the SCMI core probing step. [ Peter: Adapted RFC patch by Cristian for submission to upstream. ] Link: https://lore.kernel.org/r/20210803131024.40280-4-cristian.marussi@arm.com Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: Fixed scmi_transports_exit point of invocation ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Remove scmi_dump_header_dbg() helperCristian Marussi
Being a while that we have SCMI trace events in the SCMI stack, remove this debug helper and its call sites. Link: https://lore.kernel.org/r/20210803131024.40280-3-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-05firmware: arm_scmi: Add support for type handling in common functionsCristian Marussi
Add SCMI type handling to pack/unpack_scmi_header common helper functions. Initialize hdr.type properly when initializing a command xfer. Link: https://lore.kernel.org/r/20210803131024.40280-2-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-08-04soc: mmsys: mediatek: add mask to mmsys routesCK Hu
SOUT has many bits and need to be cleared before set new value. Write only could do the clear, but for MOUT, it clears bits that should not be cleared. So use a mask to reset only the needed bits. this fixes HDMI issues on MT7623/BPI-R2 since 5.13 Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers") Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Link: https://lore.kernel.org/r/20210729070549.5514-1-linux@fw-web.de Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-08-04Merge tag 'ixp4xx-drivers-arm-soc-v5.15-1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik into arm/drivers IXP4xx driver updates for modernizing the IXP4xx platforms, taregeted for v5.15: - Add DT bindings to the expansion bus and PATA libata driver. - Add a new expansion bus driver. - Rewrite the watchdog driver to use the watchdog core and spawn from the timer (clocksource) driver. - Refactor the PATA/libata driver to probe from the device tree and use the expansion bus driver to manipulate chip select timings directly. * tag 'ixp4xx-drivers-arm-soc-v5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik: pata: ixp4xx: Rewrite to use device tree pata: ixp4xx: Add DT bindings pata: ixp4xx: Refer to cmd and ctl rather than csN pata: ixp4xx: Use IS_ENABLED() to determine endianness pata: ixp4xx: Use local dev variable watchdog: ixp4xx: Rewrite driver to use core bus: ixp4xx: Add a driver for IXP4xx expansion bus bus: ixp4xx: Add DT bindings for the IXP4xx expansion bus Link: https://lore.kernel.org/r/CACRpkdZaCosXsgp02nuUbd_nEvdxm5-z0+d0oSA97UTWQ0RQQg@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-04pata: ixp4xx: Rewrite to use device treeLinus Walleij
This rewrites the IXP4xx CF (IDE) libata driver to use the device tree exclusively to look up its resources: - Probe exclusively from the device tree and look up all resources from there. - Allocate a local state container with devres and pass this around in .private_data. - Initialize with struct ata_port_info. - Use the .set_piomode() callback instead of the much wider .set_mode(), we only support PIO after all. - Bump driver version number from 0.2 to 1.0 to reflect this wider change. - Get a handle on the expansion bus syscon regmap to alter the timings on the chip select. - Put in the more elaborate timing adjustment code for PIO0 to PIO4 in 8 and 16bit mode from the downstream OpenWrt patch. The board file initialization path and platform data include is dropped because the board files will be deleted at the same time as this patch is merged. The platform data file is not deleted right now so as not to conflict with the removal of board files. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-08-04pata: ixp4xx: Add DT bindingsLinus Walleij
This adds device tree bindings for the Intel IXP4xx compact flash card interface. Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-08-04pata: ixp4xx: Refer to cmd and ctl rather than csNLinus Walleij
The two "cs0" and "cs1" are "chip selects" but on some platforms such as GW2358 they are actually both in CS3 making this terminology very confusing. Call the addresses "cmd" and "ctl" after function instead. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-08-04pata: ixp4xx: Use IS_ENABLED() to determine endiannessLinus Walleij
Instead of an ARM-specific ifdef, use the global CPU config and if (IS_ENABLED()). Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-08-04pata: ixp4xx: Use local dev variableLinus Walleij
Let's simplify all &pdev->dev references by creating a local struct device *dev variable. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-08-04watchdog: ixp4xx: Rewrite driver to use coreLinus Walleij
This rewrites the IXP4xx watchdog driver as follows: - Spawn the watchdog driver as a platform device from the timer driver. It's one device in the hardware, and the fact that Linux splits the handling into two different devices is a Linux pecularity, and thus it becomes a Linux pecularity to spawn a separate watchdog driver. - Spawn the watchdog driver from the timer driver at probe(). This is well after the timer driver as actually registered and started and we know the register base is available. - Instead of looping back callbacks to the timer drivers for all watchdog calls, pass the register base to the watchdog driver and manage the registers there. The two drivers aren't even interested in the same register so the spinlock is totally surplus, delete it. - Replace pretty much all of the content in the watchdog driver with a simple, modern watchdog driver utilizing the watchdog core instead of registering its own misc device and ioctl() handling. - Drop module parameters as the same already exist in the watchdog core. What remains is a slim elegant (IMO) watchdog driver using the watchdog core, spawning from device tree or boardfile alike. Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-08-04bus: ixp4xx: Add a driver for IXP4xx expansion busLinus Walleij
The Intel IXP4xx SoCs have an expansion bus that is usually just used for flash memory and configured by the boot loaders and can be accessed using the "simple-bus". However some devices need more elaborate configuration and then we need to provide a proper 3-unit address space indicating chip select for each device and provide timing and similar information. Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>