aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-03-29firmware: arm_scmi: Introduce new devres notification opsCristian Marussi2-5/+146
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/[email protected] Tested-by: Florian Fainelli <[email protected]> Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2021-03-29firmware: arm_scmi: Make notifications aware of protocols usersCristian Marussi1-7/+44
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/[email protected] Tested-by: Florian Fainelli <[email protected]> Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2021-03-29firmware: arm_scmi: Introduce devres get/put protocols operationsCristian Marussi2-0/+103
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/[email protected] Tested-by: Florian Fainelli <[email protected]> Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2021-03-29firmware: arm_scmi: Introduce protocol handle definitionsCristian Marussi2-0/+104
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/[email protected] Tested-by: Florian Fainelli <[email protected]> Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2021-03-29firmware: arm_scmi: Extend protocol registration interfacesCristian Marussi12-43/+332
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/[email protected] Tested-by: Florian Fainelli <[email protected]> Signed-off-by: Cristian Marussi <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
2021-03-29firmware: imx: scu-pd: add missed ADC1 pdFrank Li1-1/+1
ADC1 is not defined in pd driver on 8QM. Signed-off-by: Frank Li <[email protected]> Reviewed-by: Dong Aisheng <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2021-03-29firmware: imx: scu-pd: Update comments for single global power domainUlf Hansson1-2/+9
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 <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2021-03-26soc/tegra: pmc: Print out domain name when reset fails to acquireDmitry Osipenko1-1/+2
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 <[email protected]> # Ouya T30 Tested-by: Nicolas Chauvet <[email protected]> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <[email protected]> # Ouya T30 Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-03-26soc/tegra: pmc: Ensure that clock rates aren't too highDmitry Osipenko1-2/+90
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 <[email protected]> # Ouya T30 Tested-by: Nicolas Chauvet <[email protected]> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <[email protected]> # Ouya T30 Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-03-26soc/tegra: pmc: Fix completion of power-gate togglingDmitry Osipenko1-5/+65
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 <[email protected]> # Ouya T30 Tested-by: Nicolas Chauvet <[email protected]> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <[email protected]> # Ouya T30 Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-03-26soc/tegra: pmc: Fix imbalanced clock disabling in error code pathDmitry Osipenko1-1/+1
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 <[email protected]> # Ouya T30 Tested-by: Nicolas Chauvet <[email protected]> # PAZ00 T20 and TK1 T124 Tested-by: Matt Merhar <[email protected]> # Ouya T30 Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-03-26soc/tegra: regulators: Fix locking up when voltage-spread is out of rangeDmitry Osipenko1-1/+1
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: [email protected] Reported-by: Peter Geis <[email protected]> Tested-by: Peter Geis <[email protected]> # Ouya T30 Tested-by: Matt Merhar <[email protected]> # Ouya T30 Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-03-26soc/tegra: pmc: Provide USB sleepwalk register mapJC Kuo1-0/+94
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 <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-03-25soc: bcm: bcm-pmb: add BCM63138 SATA supportRafał Miłecki2-0/+31
BCM63138 has SATA controller that needs to be powered up using PMB. Signed-off-by: Rafał Miłecki <[email protected]> Signed-off-by: Florian Fainelli <[email protected]>
2021-03-25dt-bindings: power: bcm-pmb: add BCM63138 bindingRafał Miłecki1-0/+1
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 <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Florian Fainelli <[email protected]>
2021-03-24clk: tegra: Don't enable PLLE HW sequencer at initJC Kuo1-12/+0
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 <[email protected]> Acked-by: Thierry Reding <[email protected]> Acked-by: Stephen Boyd <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-03-24clk: tegra: Add PLLE HW power sequencer controlJC Kuo2-2/+55
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 <[email protected]> Acked-by: Thierry Reding <[email protected]> Acked-by: Stephen Boyd <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2021-03-24bus: ti-sysc: Use kzalloc for allocating only one thingZheng Yongjun1-1/+1
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 <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2021-03-24bus: ti-sysc: remove unneeded semicolonYang Li1-2/+2
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 <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2021-03-24ARM: OMAP2+: Make symbol 'pdata_quirks_init_clocks' staticWei Yongjun1-1/+1
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 <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2021-03-23Merge tag 'renesas-drivers-for-v5.13-tag1' of ↵Arnd Bergmann1-2/+2
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/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2021-03-23Merge tag 'optee-tracepoints-for-v5.13' of ↵Arnd Bergmann2-0/+71
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 <[email protected]>
2021-03-23ARM: socfpga: drop ARCH_SOCFPGAKrzysztof Kozlowski3-8/+4
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23reset: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCsKrzysztof Kozlowski1-2/+2
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23i2c: altera: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCsKrzysztof Kozlowski1-1/+1
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 <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23fpga: altera: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCsKrzysztof Kozlowski1-3/+3
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 <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23dmaengine: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCsKrzysztof Kozlowski1-1/+1
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 <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23clk: socfpga: use ARCH_INTEL_SOCFPGA also for 32-bit ARM SoCs (and compile test)Krzysztof Kozlowski2-3/+7
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23clk: socfpga: allow compile testing of Stratix 10 / Agilex clocksKrzysztof Kozlowski2-4/+13
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23arm64: socfpga: merge Agilex and N5X into ARCH_INTEL_SOCFPGAKrzysztof Kozlowski8-28/+13
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23EDAC: altera: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski2-7/+12
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23clk: socfpga: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski1-2/+1
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23clk: socfpga: build together Stratix 10, Agilex and N5X clock driversKrzysztof Kozlowski2-7/+6
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23net: stmmac: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski1-2/+2
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23mfd: altera: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski1-2/+2
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 <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23ARM: socfpga: introduce common ARCH_INTEL_SOCFPGAKrzysztof Kozlowski7-7/+15
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-23clk: socfpga: allow building N5X clocks with ARCH_N5XKrzysztof Kozlowski4-2/+10
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 <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]>
2021-03-22pwm: Add Raspberry Pi Firmware based PWM busNicolas Saenz Julienne3-0/+216
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 <[email protected]> Reviewed-by: Uwe Kleine-König <[email protected]> Acked-by: Thierry Reding <[email protected]>
2021-03-22dt-bindings: pwm: Add binding for RPi firmware PWM busNicolas Saenz Julienne2-0/+33
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 <[email protected]> Reviewed-by: Rob Herring <[email protected]>
2021-03-22input: raspberrypi-ts: Release firmware handle when not neededNicolas Saenz Julienne1-1/+1
There is no use for the firmware interface after getting the touch buffer address, so release it. Signed-off-by: Nicolas Saenz Julienne <[email protected]> Acked-by: Dmitry Torokhov <[email protected]> Reviewed-by: Florian Fainelli <[email protected]>
2021-03-22staging: vchiq: Release firmware handle on unbindNicolas Saenz Julienne1-1/+1
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 <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]>
2021-03-22soc: bcm: raspberrypi-power: Release firmware handle on unbindNicolas Saenz Julienne1-1/+1
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 <[email protected]> Reviewed-by: Florian Fainelli <[email protected]>
2021-03-22reset: raspberrypi: Release firmware handle on unbindNicolas Saenz Julienne1-1/+1
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 <[email protected]> Reviewed-by: Florian Fainelli <[email protected]>
2021-03-22gpio: raspberrypi-exp: Release firmware handle on unbindNicolas Saenz Julienne1-1/+1
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 <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]>
2021-03-22clk: bcm: rpi: Release firmware handle on unbindNicolas Saenz Julienne1-1/+1
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 <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Acked-by: Stephen Boyd <[email protected]> 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 Julienne2-0/+37
It'll simplify the firmware handling for most consumers. Suggested-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Nicolas Saenz Julienne <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]>
2021-03-22firmware: raspberrypi: Keep count of all consumersNicolas Saenz Julienne2-3/+39
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 <[email protected]> Signed-off-by: Nicolas Saenz Julienne <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]>
2021-03-17soc: mediatek: add mtk mutex support for MT8183Yongqiang Niu1-0/+50
Add mtk mutex support for MT8183 SoC. Signed-off-by: Yongqiang Niu <[email protected]> Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matthias Brugger <[email protected]>
2021-03-15Merge branch 'ib-iio-scmi-5.12-rc2-take3' of ↵Sudeep Holla7-1/+715
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 Mazzucato1-20/+54
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/[email protected] Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Nicola Mazzucato <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.