summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-03-29firmware: arm_scmi: Introduce new devres notification opsCristian Marussi
Expose to the SCMI drivers a new alternative devres managed notifications API based on protocol handles. All drivers still keep using the old API, no functional change. Link: https://lore.kernel.org/r/20210316124903.35011-6-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-03-29firmware: arm_scmi: Make notifications aware of protocols usersCristian Marussi
Account for any active registered notifier against the proper related protocol, do not consider pending event handlers, only active handlers will concur to protocol usage accounting. Link: https://lore.kernel.org/r/20210316124903.35011-5-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-03-29firmware: arm_scmi: Introduce devres get/put protocols operationsCristian Marussi
Expose to the SCMI drivers a new devres managed common protocols API based on generic get/put methods and protocol handles. All drivers still keep using the old API, no functional change. Link: https://lore.kernel.org/r/20210316124903.35011-4-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-03-29firmware: arm_scmi: Introduce protocol handle definitionsCristian Marussi
Add basic protocol handles definitions and private data helpers. A protocol handle identifies a protocol instance initialized against a specific handle, it embeds all the references to the core SCMI transfer methods that will be needed by a protocol implementation to build and send its own protocol specific messages using common core methods. As such, in the interface, a protocol handle will be passed down from the core to the protocol specific initialization callback at init time. Anyways, at this point only definitions are introduced, all protocols initialization code and SCMI drivers probing is still based on the old interface, so no functional change. Link: https://lore.kernel.org/r/20210316124903.35011-3-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-03-29firmware: arm_scmi: Extend protocol registration interfacesCristian Marussi
Extend common protocol registration routines and provide some new generic protocols get/put helpers that can track protocols usage and automatically perform the proper initialization and de-initialization on demand when required. Convert all standard protocols to use this new registration scheme while keeping them all still using the usual initialization logic bound to SCMI devices probing. Link: https://lore.kernel.org/r/20210316124903.35011-2-cristian.marussi@arm.com Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-03-29firmware: imx: scu-pd: add missed ADC1 pdFrank Li
ADC1 is not defined in pd driver on 8QM. Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-03-29firmware: imx: scu-pd: Update comments for single global power domainUlf Hansson
Since the introduction of the PM domain support for the scu-pd, the genpd framework has been continuously improved. More preciously, using a single global power domain can quite easily be deployed for imx platforms. To avoid confusions, let's therefore make an update to the comments about the missing pieces. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2021-03-26soc/tegra: pmc: Print out domain name when reset fails to acquireDmitry Osipenko
Print out domain name when reset fails to acquire for debugging purposes and to make formatting of GENPD errors consistent in the driver. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-26soc/tegra: pmc: Ensure that clock rates aren't too highDmitry Osipenko
Switch all clocks of a power domain to a safe rate which is suitable for all possible voltages in order to ensure that hardware constraints aren't violated when power domain state toggles. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-26soc/tegra: pmc: Fix completion of power-gate togglingDmitry Osipenko
The SW-initiated power gate toggling is dropped by PMC if there is contention with a HW-initiated toggling, i.e. when one of CPU cores is gated by cpuidle driver. Software should retry the toggling after 10 microseconds on Tegra20/30 SoCs, hence add the retrying. On Tegra114+ the toggling method was changed in hardware, the TOGGLE_START bit indicates whether PMC is busy or could accept the command to toggle, hence handle that bit properly. The problem pops up after enabling dynamic power gating of 3D hardware, where 3D power domain fails to turn on/off "randomly". The programming sequence and quirks are documented in TRMs, but PMC driver obliviously re-used the Tegra20 logic for Tegra30+, which strikes back now. The 10 microseconds and other timeouts aren't documented in TRM, they are taken from downstream kernel. Link: https://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=commit;h=311dd1c318b70e93bcefec15456a10ff2b9eb0ff Link: https://nv-tegra.nvidia.com/gitweb/?p=linux-3.10.git;a=commit;h=7f36693c47cb23730a6b2822e0975be65fb0c51d Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-26soc/tegra: pmc: Fix imbalanced clock disabling in error code pathDmitry Osipenko
The tegra_powergate_power_up() has a typo in the error code path where it will try to disable clocks twice, fix it. In practice that error never happens, so this is a minor correction. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-26soc/tegra: regulators: Fix locking up when voltage-spread is out of rangeDmitry Osipenko
Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn't have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree. Fixes: 783807436f36 ("soc/tegra: regulators: Add regulators coupler for Tegra30") Cc: stable@vger.kernel.org Reported-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-26soc/tegra: pmc: Provide USB sleepwalk register mapJC Kuo
This commit implements a register map which grants USB (UTMI and HSIC) sleepwalk registers access to USB PHY drivers. The USB sleepwalk logic is in PMC hardware block but USB PHY drivers have the best knowledge of proper programming sequence. Signed-off-by: JC Kuo <jckuo@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-25soc: bcm: bcm-pmb: add BCM63138 SATA supportRafał Miłecki
BCM63138 has SATA controller that needs to be powered up using PMB. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2021-03-25dt-bindings: power: bcm-pmb: add BCM63138 bindingRafał Miłecki
PMB can be also found on bcm63xx chipsets. It uses difference device addresses so a new binding is required. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2021-03-24clk: tegra: Don't enable PLLE HW sequencer at initJC Kuo
PLLE hardware power sequencer references PEX/SATA UPHY PLL hardware power sequencers' output to enable/disable PLLE. PLLE hardware power sequencer has to be enabled only after PEX/SATA UPHY PLL's sequencers are enabled. Signed-off-by: JC Kuo <jckuo@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-24clk: tegra: Add PLLE HW power sequencer controlJC Kuo
PLLE has a hardware power sequencer logic which is a state machine that can power on/off PLLE without any software intervention. The sequencer has two inputs, one from XUSB UPHY PLL and the other from SATA UPHY PLL. PLLE provides reference clock to XUSB and SATA UPHY PLLs. When both of the downstream PLLs are powered-off, PLLE hardware power sequencer will automatically power off PLLE for power saving. XUSB and SATA UPHY PLLs also have their own hardware power sequencer logic. XUSB UPHY PLL is shared between XUSB SuperSpeed ports and PCIE controllers. The XUSB UPHY PLL hardware power sequencer has inputs from XUSB and PCIE. When all of the XUSB SuperSpeed ports and PCIE controllers are in low power state, XUSB UPHY PLL hardware power sequencer automatically power off PLL and flags idle to PLLE hardware power sequencer. Similar applies to SATA UPHY PLL. PLLE hardware power sequencer has to be enabled after both downstream sequencers are enabled. This commit adds two helper functions: 1. tegra210_plle_hw_sequence_start() for XUSB PADCTL driver to enable PLLE hardware sequencer at proper time. 2. tegra210_plle_hw_sequence_is_enabled() for XUSB PADCTL driver to check whether PLLE hardware sequencer has been enabled or not. Signed-off-by: JC Kuo <jckuo@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-24bus: ti-sysc: Use kzalloc for allocating only one thingZheng Yongjun
Use kzalloc rather than kcalloc(1,...) The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ @@ - kcalloc(1, + kzalloc( ...) // </smpl> Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-24bus: ti-sysc: remove unneeded semicolonYang Li
Eliminate the following coccicheck warning: ./drivers/bus/ti-sysc.c:1595:2-3: Unneeded semicolon ./drivers/bus/ti-sysc.c:2833:3-4: Unneeded semicolon Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-24ARM: OMAP2+: Make symbol 'pdata_quirks_init_clocks' staticWei Yongjun
The sparse tool complains as follows: arch/arm/mach-omap2/pdata-quirks.c:578:1: warning: symbol 'pdata_quirks_init_clocks' was not declared. Should it be static? This symbol is not used outside of pdata-quirks.c, so this commit marks it static. Fixes: a15de032a72d ("ARM: OMAP2+: Init both prm and prcm nodes early for clocks") Reported-by: Hulk Robot <hulkci@huawei.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2021-03-23Merge tag 'renesas-drivers-for-v5.13-tag1' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/drivers Renesas driver updates for v5.13 - Prepare rmobile-sysc for fw_devlink=on, - A minor cleanup. * tag 'renesas-drivers-for-v5.13-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: soc: renesas: rmobile-sysc: Mark fwnode when PM domain is added soc: renesas: rmobile-sysc: Remove unneeded platform includes Link: https://lore.kernel.org/r/20210319085146.2709844-4-geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-03-23Merge tag 'optee-tracepoints-for-v5.13' of ↵Arnd Bergmann
git://git.linaro.org/people/jens.wiklander/linux-tee into arm/drivers Add tracepoints around calls to secure world * tag 'optee-tracepoints-for-v5.13' of git://git.linaro.org/people/jens.wiklander/linux-tee: tee: optee: add invoke_fn tracepoints Link: https://lore.kernel.org/r/20210315113733.GA1944243@jade Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-03-23ARM: socfpga: drop ARCH_SOCFPGAKrzysztof Kozlowski
Simplify 32-bit and 64-bit Intel SoCFPGA Kconfig options by having only one for both of them. After conversion of all drivers to use the new ARCH_INTEL_SOCFPGA, the remaining ARM option can be removed. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23reset: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCsKrzysztof Kozlowski
ARCH_SOCFPGA is being renamed to ARCH_INTEL_SOCFPGA so adjust the 32-bit ARM drivers to rely on new symbol. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23i2c: altera: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCsKrzysztof Kozlowski
ARCH_SOCFPGA is being renamed to ARCH_INTEL_SOCFPGA so adjust the 32-bit ARM drivers to rely on new symbol. The side effect is that the I2C_ALTERA will now be available for both 32-bit and 64-bit Intel SoCFPGA, even though it is used only for 32-bit. Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23fpga: altera: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCsKrzysztof Kozlowski
ARCH_SOCFPGA is being renamed to ARCH_INTEL_SOCFPGA so adjust the 32-bit ARM drivers to rely on new symbol. Acked-by: Moritz Fischer <mdf@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23dmaengine: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCsKrzysztof Kozlowski
ARCH_SOCFPGA is being renamed to ARCH_INTEL_SOCFPGA so adjust the 32-bit ARM drivers to rely on new symbol. Acked-By: Vinod Koul <vkoul@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23clk: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs (and compile test)Krzysztof Kozlowski
ARCH_SOCFPGA is being renamed to ARCH_INTEL_SOCFPGA so adjust the 32-bit ARM drivers to rely on new symbol. There is little point to share clock controller drivers between 32-bit and 64-bit platforms because there will not be a generic image for both of them. Therefore add a new Kconfig entry for building 32-bit clock driverss, similar to one for 64-bit. This allows enabling compile testing. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23clk: socfpga: allow compile testing of Stratix 10 / Agilex clocksKrzysztof Kozlowski
The Stratix 10 / Agilex / N5X clocks do not use anything other than OF or COMMON_CLK so they should be compile testable on most of the platforms. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23arm64: socfpga: merge Agilex and N5X into ARCH_INTEL_SOCFPGAKrzysztof Kozlowski
Agilex, N5X and Stratix 10 share all quite similar arm64 hard cores and SoC-part. Up to a point that N5X uses the same DTSI as Agilex. From the Linux kernel point of view these are flavors of the same architecture so there is no need for three top-level arm64 architectures. Simplify this by merging all three architectures into ARCH_INTEL_SOCFPGA and dropping the other ARCH* arm64 Kconfig entries. The side effect is that the INTEL_STRATIX10_SERVICE will now be available for both 32-bit and 64-bit Intel SoCFPGA, even though it is used only for 64-bit. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23EDAC: altera: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski
Simplify 32-bit and 64-bit Intel SoCFPGA Kconfig options by having only one for both of them. This the common practice for other platforms. Additionally, the ARCH_SOCFPGA is too generic as SoCFPGA designs come from multiple vendors. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23clk: socfpga: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski
Simplify 32-bit and 64-bit Intel SoCFPGA Kconfig options by having only one for both of them. This the common practice for other platforms. Additionally, the ARCH_SOCFPGA is too generic as SoCFPGA designs come from multiple vendors. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23clk: socfpga: build together Stratix 10, Agilex and N5X clock driversKrzysztof Kozlowski
On a multiplatform kernel there is little benefit in splitting each clock driver per platform because space savings are minimal. Such split also complicates the code, especially after adding compile testing. Build all arm64 Intel SoCFPGA clocks together with one entry in Makefile. This also removed duplicated line in the Makefile (selecting common part of clocks per platform). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23net: stmmac: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski
Simplify 32-bit and 64-bit Intel SoCFPGA Kconfig options by having only one for both of them. This the common practice for other platforms. Additionally, the ARCH_SOCFPGA is too generic as SoCFPGA designs come from multiple vendors. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23mfd: altera: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski
Simplify 32-bit and 64-bit Intel SoCFPGA Kconfig options by having only one for both of them. This the common practice for other platforms. Additionally, the ARCH_SOCFPGA is too generic as SoCFPGA designs come from multiple vendors. The side effect is that the MFD_ALTERA_A10SR will now be available for both 32-bit and 64-bit Intel SoCFPGA, even though it is used only for 32-bit. Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23ARM: socfpga: introduce common ARCH_INTEL_SOCFPGAKrzysztof Kozlowski
Simplify 32-bit and 64-bit Intel SoCFPGA Kconfig options by having only one for both of them. This the common practice for other platforms. Additionally, the ARCH_SOCFPGA is too generic as SoCFPGA designs come from multiple vendors. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23clk: socfpga: allow building N5X clocks with ARCH_N5XKrzysztof Kozlowski
The Intel's eASIC N5X (ARCH_N5X) architecture shares a lot with Agilex (ARCH_AGILEX) so it uses the same socfpga_agilex.dtsi, with minor changes. Also the clock drivers are the same. However the clock drivers won't be build without ARCH_AGILEX. One could assume that ARCH_N5X simply depends on ARCH_AGILEX but this was not modeled in Kconfig. In current stage the ARCH_N5X is simply unbootable. Add a separate Kconfig entry for clocks used by both ARCH_N5X and ARCH_AGILEX so the necessary objects will be built if either of them is selected. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-22pwm: Add Raspberry Pi Firmware based PWM busNicolas Saenz Julienne
Adds support to control the PWM bus available in official Raspberry Pi PoE HAT. Only RPi's co-processor has access to it, so commands have to be sent through RPi's firmware mailbox interface. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Thierry Reding <thierry.reding@gmail.com>
2021-03-22dt-bindings: pwm: Add binding for RPi firmware PWM busNicolas Saenz Julienne
The PWM bus controlling the fan in RPi's official PoE hat can only be controlled by the board's co-processor. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Rob Herring <robh@kernel.org>
2021-03-22input: raspberrypi-ts: Release firmware handle when not neededNicolas Saenz Julienne
There is no use for the firmware interface after getting the touch buffer address, so release it. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
2021-03-22staging: vchiq: Release firmware handle on unbindNicolas Saenz Julienne
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware interface when unbinding the device. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-22soc: bcm: raspberrypi-power: Release firmware handle on unbindNicolas Saenz Julienne
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware interface when unbinding the device. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
2021-03-22reset: raspberrypi: Release firmware handle on unbindNicolas Saenz Julienne
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware interface when unbinding the device. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
2021-03-22gpio: raspberrypi-exp: Release firmware handle on unbindNicolas Saenz Julienne
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware interface when unbinding the device. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-03-22clk: bcm: rpi: Release firmware handle on unbindNicolas Saenz Julienne
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware interface when unbinding the device. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Stephen Boyd <sboyd@kernel.org> drivers/clk/bcm/clk-raspberrypi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
2021-03-22firmware: raspberrypi: Introduce devm_rpi_firmware_get()Nicolas Saenz Julienne
It'll simplify the firmware handling for most consumers. Suggested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-03-22firmware: raspberrypi: Keep count of all consumersNicolas Saenz Julienne
When unbinding the firmware device we need to make sure it has no consumers left. Otherwise we'd leave them with a firmware handle pointing at freed memory. Keep a reference count of all consumers and introduce rpi_firmware_put() which will permit automatically decrease the reference count upon unbinding consumer drivers. Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-03-17soc: mediatek: add mtk mutex support for MT8183Yongqiang Niu
Add mtk mutex support for MT8183 SoC. Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://lore.kernel.org/r/20210129092209.2584718-8-hsinyi@chromium.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-03-15Merge branch 'ib-iio-scmi-5.12-rc2-take3' of ↵Sudeep Holla
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into for-next/scmi * 'ib-iio-scmi-5.12-rc2-take3' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio/scmi: Adding support for IIO SCMI Based Sensors
2021-03-15scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EMNicola Mazzucato
By design, SCMI performance domains define the granularity of performance controls, they do not describe any underlying hardware dependencies (although they may match in many cases). It is therefore possible to have some platforms where hardware may have the ability to control CPU performance at different granularity and choose to describe fine-grained performance control through SCMI. In such situations, the energy model would be provided with inaccurate information based on controls, while it still needs to know the performance boundaries. To restore correct functionality, retrieve information of CPUs under the same performance domain from operating-points-v2 in DT, and pass it on to EM. Link: https://lore.kernel.org/r/20210218222326.15788-3-nicola.mazzucato@arm.com Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
generated by cgit (git 2.34.1) at 2025-10-01 03:49:05 +0000