- 03 Nov, 2023 1 commit
-
-
Uwe Kleine-König authored
My earlier commit reworking how driver data is tracked added a new member to struct samsung_pwm_chip but failed to add matching documentation. Make up leeway. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310130404.uQ33q5Dk-lkp@intel.com/ Fixes: e3fe982b ("pwm: samsung: Put per-channel data into driver data") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com>
-
- 13 Oct, 2023 31 commits
-
-
Florian Fainelli authored
Similar to other drivers, we need to make sure that the clock is disabled during suspend and re-enabled during resume. Reported-by:
Angus Clark <angus.clark@broadcom.com> Signed-off-by:
Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
-
Florian Fainelli authored
Check the clk_prepare_enable() return value and propagate it. Suggested-by:
-
Florian Fainelli authored
The suspend/resume functions currently utilize clk_disable()/clk_enable() respectively which may be no-ops with certain clock providers such as SCMI. Fix this to use clk_disable_unprepare() and clk_prepare_enable() respectively as we should. Fixes: 3a9f5957 ("pwm: Add Broadcom BCM7038 PWM controller support") Signed-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Uwe Kleine-König authored
Using devm_pwmchip_add() allows to drop pwmchip_remove() from the remove function which makes this function empty. Then there is no user of drvdata left and platform_set_drvdata() can be dropped, too. Further simplify and improve error returning using dev_err_probe(). Link: https://lore.kernel.org/r/20230929161918.2410424-12-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The driver uses mostly "chip" to name samsung_pwm_chip pointers: $ git grep -Pho 'samsung_pwm_chip \*[a-zA-Z0-9_]+(*nla:[a-zA-Z0-9_(])' v6.5-rc1 -- drivers/pwm/pwm-samsung.c | sort | uniq -c 10 samsung_pwm_chip *chip 6 samsung_pwm_chip *our_chip 1 samsung_pwm_chip *pwm However "chip" is supposed to be used for struct pwm_chip pointers and "pwm" for struct pwm_device pointers. So consistently use "our_chip". Link: https://lore.kernel.org/r/20230929161918.2410424-11-u.kleine-koenig@pengutronix.deSigned-off-by: -
Uwe Kleine-König authored
With devm_clk_get_prepared() the call to clk_unprepare() can be dropped from the error path and the remove callback. With devm_pwmchip_add() pwmchip_remove() can be dropped. Then the remove callback is empty and can go away, too. With vt8500_pwm_remove() the last user of platform_get_drvdata() is gone and so platform_set_drvdata() can be dropped, too. Also use dev_err_probe() for simplified (and improved) error reporting. Link: https://lore.kernel.org/r/20230929161918.2410424-10-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Using devm_pwmchip_add() allows to drop pwmchip_remove() from the remove function which makes this function empty. Then there is no user of drvdata left and platform_set_drvdata() can be dropped, too. Further simplify and improve error returning using dev_err_probe(). Link: https://lore.kernel.org/r/20230929161918.2410424-9-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Similar to most other PWM drivers provide a static inline function to calculate driver data from a given pwmchip. Link: https://lore.kernel.org/r/20230929161918.2410424-8-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
With devm_clk_get_prepared() the call to clk_unprepare() can be dropped from the error path and the remove callback. With devm_pwmchip_add() pwmchip_remove() can be dropped. Then the remove callback is empty and can go away, too. With spear_pwm_remove() the last user of platform_get_drvdata() is gone and so platform_set_drvdata() can be dropped, too. Also use dev_err_probe() for simplified (and improved) error reporting. Link: https://lore.kernel.org/r/20230929161918.2410424-7-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
With devm_pwmchip_add() pwmchip_remove() can be dropped from the remove callback. Then the remove callback is empty and can go away, too. With mtk_disp_pwm_remove() the last user of platform_get_drvdata() is gone and so platform_set_drvdata() can be dropped, too. Also use dev_err_probe() for simplified (and improved) error reporting. Link: https://lore.kernel.org/r/20230929161918.2410424-6-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
With devm_clk_get_enabled() the call to clk_disable_unprepare() can be dropped from the error path and the remove callback. With devm_pwmchip_add() pwmchip_remove() can be dropped. Then the remove callback is empty and can go away, too. Also use dev_err_probe() for simplified (and improved) error reporting. Link: https://lore.kernel.org/r/20230929161918.2410424-5-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
With devm_clk_get_enabled() the call to clk_disable_unprepare() can be dropped from the error path and the remove callback. With devm_pwmchip_add() pwmchip_remove() can be dropped. Then the remove callback is empty and can go away, too. Also use dev_err_probe() for simplified (and improved) error reporting. Link: https://lore.kernel.org/r/20230929161918.2410424-4-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
With devm_clk_get_enabled() the call to clk_disable_unprepare() can be dropped from the error path and the remove callback. With devm_pwmchip_add() pwmchip_remove() can be dropped. Then the remove callback is empty and can go away, too. With bcm2835_pwm_remove() the only user of platform_get_drvdata() is gone and so platform_set_drvdata() can be dropped from .probe(), too. Also use dev_err_probe() for simplified (and improved) error reporting. Link: https://lore.kernel.org/r/20230929161918.2410424-3-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
With devm_clk_get_enabled() the call to clk_disable_unprepare() can be dropped from the error path and the remove callback. With devm_pwmchip_add() pwmchip_remove() can be dropped. Then the remove callback is empty and can go away, too. Also use dev_err_probe() for simplified (and improved) error reporting. Link: https://lore.kernel.org/r/20230929161918.2410424-2-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Most low-level PWM drivers support duty_cycle == period, and so does the sysfs API. Also polarity can be changed for enabled PWMs since commit 39100cee ("pwm: Switch to the atomic API"). Reported-by:
Jens Gehrlein <J.Gehrlein@eckelmann.de> Link: https://lore.kernel.org/r/20230911154454.675057-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Ben Dooks authored
If we are not in PWM mode, then the output is technically a 50% output based on a single timer instead of the high-low based on the two counters. Add a check for the PWM mode in dwc_pwm_get_state() and if DWC_TIM_CTRL_PWM is not set, then return a 50% cycle. This may only be an issue on initialisation, as the rest of the code currently assumes we're always going to have the extended PWM mode using two counters. Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by:
-
Ben Dooks authored
Add a configurable clock base rate for the pwm as when being built for non-PCI the block may be sourced from an internal clock. Signed-off-by:
-
Ben Dooks authored
Moving towards adding non-pci support for the driver, move the pci parts out of the core into their own module. This is partly due to the module_driver() code only being allowed once in a module and also to avoid a number of #ifdef if we build a single file in a system without pci support. Signed-off-by:
-
Uwe Kleine-König authored
With devm_clk_get_enabled() the call to clk_disable_unprepare() can be dropped from the error path and the remove callback. With devm_pwmchip_add() pwmchip_remove() can be dropped. Then the remove callback is empty and can go away, too. Link: https://lore.kernel.org/r/20230718175545.3946935-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The semantic of chip_data is a bit surprising as it's cleared when pwm_put() is called. Also there is a big overlap with the standard driver data. All drivers were adapted to not make use of chip_data any more, so it can go away. Link: https://lore.kernel.org/r/20230705080650.2353391-9-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Instead of an allocation of a single u16 per channel, allocate them all in a single chunk which greatly reduces memory fragmentation and also the overhead to track the allocated memory. Also put the channel data in driver data where it's cheaper to determine the address (no function call involved, just a trivial pointer addition). This also allows to get rid of the request and free callbacks. The only cost is that the channel data is allocated early, and even for unused channels. Reviewed-by:
Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230705080650.2353391-8-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Instead of using one allocation per capture channel, use a single one. Also store it in driver data instead of chip data. This has several advantages: - driver data isn't cleared when pwm_put() is called - Reduces memory fragmentation Also register the pwm chip only after the per capture channel data is initialized as the capture callback relies on this initialization and it might be called even before pwmchip_add() returns. It would be still better to have struct sti_pwm_compat_data and the per-channel data struct sti_cpt_ddata in a single memory chunk, but that's not easily possible because the number of capture channels isn't known yet when the driver data struct is allocated. Fixes: e926b12c ("pwm: Clear chip_data in pwm_put()") Reported-by:
George Stark <gnstark@sberdevices.ru> Fixes: c97267ae ("pwm: sti: Add PWM capture callback") Link: https://lore.kernel.org/r/20230705080650.2353391-7-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Instead of distributing the driver's bookkeeping over 5 (i.e. TPU_CHANNEL_MAX + 1) separately allocated memory chunks, put all together in struct tpu_device. This reduces the number of memory allocations and so fragmentation and maybe even the number of cache misses. Also &tpu->tpd[pwm->hwpwm] is cheaper to evaluate than pwm_get_chip_data(pwm) as the former is just an addition in machine code while the latter involves a function call. Link: https://lore.kernel.org/r/20230705080650.2353391-6-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Instead of distributing the driver's bookkeeping over 3 (i.e. LP3943_NUM_PWMS + 1) separately allocated memory chunks, put all together in struct lp3943_pwm. This reduces the number of memory allocations and so fragmentation and maybe even the number of cache misses. Also &lp3943_pwm->pwm_map[pwm->hwpwm] is cheaper to evaluate than pwm_get_chip_data(pwm) as the former is just an addition in machine code while the latter involves a function call. Link: https://lore.kernel.org/r/20230705080650.2353391-5-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Stop using chip_data which is about to go away. Instead track the per-channel clk in struct jz4740_pwm_chip. Reviewed-by:
Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20230705080650.2353391-4-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Instead of allocating extra data in .request() provide the needed memory in struct samsung_pwm_chip. This reduces the number of allocations. Even though now all 5 channel structs are allocated this is probably outweighed by the reduced overhead to track up to 6 smaller allocations. Link: https://lore.kernel.org/r/20230705080650.2353391-3-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
Instead of allocating extra data in .request() provide the needed memory in struct berlin_pwm_chip. This reduces the number of allocations. A side effect is that on suspend and resume the state for all four channels is always saved and restored. This is easier (and probably quicker) than looking up the matching pwm_device and checking its PWMF_REQUESTED bit. Link: https://lore.kernel.org/r/20230705080650.2353391-2-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The driver compiles just fine as a module. The parent driver's Kconfig symbol already depends on X86 || COMPILE_TEST, so X86 can just be dropped from the dependencies allowing compilation on other platforms than x86. Link: https://lore.kernel.org/r/20230804142707.412137-3-u.kleine-koenig@pengutronix.deReviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Uwe Kleine-König authored
Instead of requiring each driver to care for assigning the owner member of struct pwm_ops, handle that implicitly using a macro. Note that the owner member has to be moved to struct pwm_chip, as the ops structure usually lives in read-only memory and so cannot be modified. The upside is that new low level drivers cannot forget the assignment and save one line each. The pwm-crc driver didn't assign .owner, that's not a problem in practice though as the driver cannot be compiled as a module. Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # Intel LPSS Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> # pwm-{bcm,brcm}*.c Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> # sun4i Acked-by:Andi Shyti <andi.shyti@kernel.org> Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> # pwm-visconti Acked-by: Heiko Stuebner <heiko@sntech.de> # pwm-rockchip Acked-by: Michael Walle <michael@walle.cc> # pwm-sl28cpld Acked-by: Neil Armstrong <neil.armstrong@linaro.org> # pwm-meson Reviewed-by:
-
Uwe Kleine-König authored
Most but not all pointers to driver data are already called "jz": $ git grep 'struct jz4740_pwm_chip \*' v6.5-rc1 -- drivers/pwm/pwm-jz4740.c v6.5-rc1:drivers/pwm/pwm-jz4740.c:static inline struct jz4740_pwm_chip *to_jz4740(struct pwm_chip *chip) v6.5-rc1:drivers/pwm/pwm-jz4740.c:static bool jz4740_pwm_can_use_chn(struct jz4740_pwm_chip *jz, v6.5-rc1:drivers/pwm/pwm-jz4740.c: struct jz4740_pwm_chip *jz = to_jz4740(chip); v6.5-rc1:drivers/pwm/pwm-jz4740.c: struct jz4740_pwm_chip *jz = to_jz4740(chip); v6.5-rc1:drivers/pwm/pwm-jz4740.c: struct jz4740_pwm_chip *jz = to_jz4740(chip); v6.5-rc1:drivers/pwm/pwm-jz4740.c: struct jz4740_pwm_chip *jz4740 = to_jz4740(pwm->chip); v6.5-rc1:drivers/pwm/pwm-jz4740.c: struct jz4740_pwm_chip *jz4740; Adapt the two variables called "jz4740" to use the same name for consistency. Reviewed-by:
-
- 06 Oct, 2023 5 commits
-
-
Conor Dooley authored
As part of converting RISC-V SOC_FOO symbols to ARCH_FOO to match the use of such symbols on other architectures, convert the Microchip FPGA PWM driver to use the new symbol. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Acked-by:
-
Fabio Estevam authored
The 'clocks' property is mandatory for the PWM to operate. Document it. Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
-
Fabio Estevam authored
imx28 uses the same PWM block that is found on imx23. Add an entry for fsl,imx28-pwm. Signed-off-by:
-
Ruan Jinjie authored
The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by:
-
Ruan Jinjie authored
The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by:
-
- 10 Sep, 2023 3 commits
-
-
Linus Torvalds authored
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm ci scripts from Dave Airlie: "This is a bunch of ci integration for the freedesktop gitlab instance where we currently do upstream userspace testing on diverse sets of GPU hardware. From my perspective I think it's an experiment worth going with and seeing how the benefits/noise playout keeping these files useful. Ideally I'd like to get this so we can do pre-merge testing on PRs eventually. Below is some info from danvet on why we've ended up making the decision and how we can roll it back if we decide it was a bad plan. Why in upstream? - like documentation, testcases, tools CI integration is one of these things where you can waste endless amounts of time if you accidentally have a version that doesn't match your source code - but also like the above, there's a balance, this is the initial cut of what we think makes sense to keep in sync vs out-of-tree, probably needs adjustment - gitlab supports out-of-repo gitlab integration and that's what's been used for the kernel in drm, but it results in per-driver fragmentation and lots of duplicated effort. the simple act of smashing an arbitrary winner into a topic branch already started surfacing patches on dri-devel and sparking good cross driver team discussions Why gitlab? - it's not any more shit than any of the other CI - drm userspace uses it extensively for everything in userspace, we have a lot of people and experience with this, including integration of hw testing labs - media userspace like gstreamer is also on gitlab.fd.o, and there's discussion to extend this to the media subsystem in some fashion Can this be shared? - there's definitely a pile of code that could move to scripts/ if other subsystem adopt ci integration in upstream kernel git. other bits are more drm/gpu specific like the igt-gpu-tests/tools integration - docker images can be run locally or in other CI runners Will we regret this? - it's all in one directory, intentionally, for easy deletion - probably 1-2 years in upstream to see whether this is worth it or a Big Mistake. that's roughly what it took to _really_ roll out solid CI in the bigger userspace projects we have on gitlab.fd.o like mesa3d" * tag 'topic/drm-ci-2023-08-31-1' of git://anongit.freedesktop.org/drm/drm: drm: ci: docs: fix build warning - add missing escape drm: Add initial ci/ subdirectory -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Ingo Molnar: "Fix preemption delays in the SGX code, remove unnecessarily UAPI-exported code, fix a ld.lld linker (in)compatibility quirk and make the x86 SMP init code a bit more conservative to fix kexec() lockups" * tag 'x86-urgent-2023-09-10' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sgx: Break up long non-preemptible delays in sgx_vepc_release() x86: Remove the arch_calc_vm_prot_bits() macro from the UAPI x86/build: Fix linker fill bytes quirk/incompatibility for ld.lld x86/smp: Don't send INIT to non-present and non-booted CPUs
-
