aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2025-02-28pwm: Check for CONFIG_PWM using IS_REACHABLE() in main headerUwe Kleine-König1-2/+2
Preparing CONFIG_PWM becoming tristate the right magic to check for the availability of the pwm functions is using IS_REACHABLE() and not IS_ENABLED(). The latter gives the wrong result for built-in code with CONFIG_PWM=m. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250217102504.687916-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-02-28dt-bindings: pwm: rockchip: Add rockchip,rk3562-pwmKever Yang1-0/+1
The PWM core on Rockchip's RK3562 is the same as the one already included in RK3328. Extend the binding accordingly to allow compatible = "rockchip,rk3562-pwm", "rockchip,rk3328-pwm"; Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Acked-by: Uwe Kleine-König <ukleinek@kernel.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250227111913.2344207-11-kever.yang@rock-chips.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-02-15pwm: Strengthen dependency for PWM_SIFIVEUwe Kleine-König1-1/+1
Back when the sifive pwm driver was added there was no symbol for sifive SoCs yet. Today there is ARCH_SIFIVE however. Let PWM_SIFIVE depend on that to ensure the driver is only build for platforms where there is a chance that the hardware is available. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250127105001.587610-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-02-15pwm: clps711x: Drop of_match_ptr() usage for .of_match_tableUwe Kleine-König1-2/+2
The pwm-clps711x driver depends on ARCH_CLPS711X || COMPILE_TEST. With the former being an ARCH_MULTI_V4T platform, there is always OF=y when ARCH_CLPS711X=y, so in practise clps711x_pwm_dt_ids[] is always used. (And in the case COMPILE_TEST=y + OF=n this only increases the driver size a bit but still compiles.) So drop the usage of of_match_ptr(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250214163442.192006-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-02-15pwm: pca9685: Drop ACPI_PTR() and of_match_ptr()Andy Shevchenko1-7/+2
Drop rather useless use of ACPI_PTR() and of_match_ptr(). It also removes the necessity to be dependent acpi.h inclusion. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250214154031.3395014-1-andriy.shevchenko@linux.intel.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-02-12pwm: Add support for pwm nexus dt bindingsHerve Codina1-2/+1
Platforms can have a standardized connector/expansion slot that exposes signals like PWMs to expansion boards in an SoC agnostic way. The support for nexus node [1] has been added to handle those cases in commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a nexus node"). This commit introduced of_parse_phandle_with_args_map() to handle nexus nodes in a generic way and the gpio subsystem adopted the support in commit c11e6f0f04db ("gpio: Support gpio nexus dt bindings"). A nexus node allows to remap a phandle list in a consumer node through a connector node in a generic way. With this remapping supported, the consumer node needs to knwow only about the nexus node. Resources behind the nexus node are decoupled by the nexus node itself. This is particularly useful when this consumer is described in a device-tree overlay. Indeed, to have the exact same overlay reused with several base systems the overlay needs to known only about the connector is going to be applied to without any knowledge of the SoC (or the component providing the resource) available in the system. As an example, suppose 3 PWMs connected to a connector. The connector PWM 0 and 2 comes from the PWM 1 and 3 of the pwm-controller1. The connector PWM 1 comes from the PWM 4 of the pwm-controller2. An expansion device is connected to the connector and uses the connector PMW 1. Nexus node support in PWM allows the following description: soc { soc_pwm1: pwm-controller1 { #pwm-cells = <3>; }; soc_pwm2: pwm-controller2 { #pwm-cells = <3>; }; }; connector: connector { #pwm-cells = <3>; pwm-map = <0 0 0 &soc_pwm1 1 0 0>, <1 0 0 &soc_pwm2 4 0 0>, <2 0 0 &soc_pwm1 3 0 0>; pwm-map-mask = <0xffffffff 0x0 0x0>; pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>; }; expansion_device { pwms = <&connector 1 57000 0>; }; >From the expansion device point of view, the PWM requested is the PWM 1 available at the connector regardless of the exact PWM wired to this connector PWM 1. Thanks to nexus node remapping described at connector node, this PWM is the PWM 4 of the pwm-controller2. The nexus node remapping handling consists in handling #pwm-cells, pwm-map, pwm-map-mask and pwm-map-pass-thru properties. This is already supported by of_parse_phandle_with_args_map() thanks to its stem_name parameter. Add support for nexus node device-tree binding and the related remapping in the PWM subsystem by simply using of_parse_phandle_with_args_map() instead of of_parse_phandle_with_args(). [1] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping Signed-off-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20250205095547.536083-3-herve.codina@bootlin.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>