- 30 Jun, 2021 13 commits
-
-
Andy Shevchenko authored
Historically we have two different approaches on how to check type of fwnode. Unify them using the latest and greatest fwnode related APIs. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Andy Shevchenko authored
In ACPI case we may use matching by fwnode as provided via fwnode_to_pwmchip(). This makes device_to_pwmchip() not needed anymore. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Andy Shevchenko authored
When we traverse the list of the registered PWM controllers, use fwnode to match. This will help for further cleanup. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Andy Shevchenko authored
When PWM support for ACPI has been added into the kernel, it missed the documentation update. Hence update documentation here. Fixes: 4a6ef8e3 ("pwm: Add support referencing PWMs from ACPI") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Lokesh Vutla authored
Add compatible string for AM64 SoC in device tree binding. IP is compatible with ti,am3352-ecap, so adding the AM64 compatible under enum of one of the compatible list entry. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Lokesh Vutla authored
Convert the tiecap binding to DT schema format using json-schema. Along with this conversion the following changes are included: - 'clock' and 'clock-names' properties are marked required as driver fails to probe without these properties - Dropped ti,am33xx-ecap as it is no longer applicable. - 'power-domains' property is introduced and marked as optional. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
pwmchip_remove() returns always 0. Don't use the value to make it possible to eventually change the function to return void. This is a good thing as pwmchip_remove() is usually called from a remove function (mostly for platform devices) and their return value is ignored by the device core anyhow. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Zou Wei authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
In most functions the driver data variable is called pc. Do the same in the two remaining functions. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
The .remove() function is only called after .probe() returned successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so platfrom_get_drvdata() returns the same non-NULL value. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
pwmchip_remove() always returns 0. Don't use the value to make it possible to eventually change the function to return void. This is a good thing as pwmchip_remove() is usually called from a remove function (mostly for platform devices) and their return value is ignored by the device core anyhow. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). This just pushes down a slightly optimized variant of how legacy drivers are handled in the core. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
A struct berlin_pwm_chip * is now always called "bpc" (instead of "pwm" which is usually used for struct pwm_device * or "chip" which is usually used for struct pwm_chip *). The struct pwm_device * variables were named "pwm_dev" or "pwm"; they are now always called "pwm". Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
- 28 Jun, 2021 10 commits
-
-
Uwe Kleine-König authored
To eventually get rid of all legacy drivers convert this driver to the modern world implementing .apply(). This just pushes down a slightly optimized variant of how legacy drivers are handled in the core. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
ecap_pwm_free is only called when a consumer releases the PWM (using pwm_put() or pwm_free()). The consumer is expected to disable the PWM before doing that. It's not clear if a warning about that is justified, but if it is this is independent of the actual driver and can better be done in the core. Also if there is a good reason it's wrong to disable the hardware and so the call to pm_runtime_put_sync() should be dropped. Moreover there is no matching pwm_runtime_get call and so the runtime usage counter might become negative. Fixes: 8e0cb05b ("pwm: pwm-tiecap: PWM driver support for ECAP APWM") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
Since the PWM core uses device links (commit b2c200e3 ("pwm: Add consumer device link")) each consumer driver that requested the PWMs is already gone. If they called pwm_put() (as they should) the PWMF_REQUESTED bit is not set. If they failed (which is a bug) the PWMF_REQUESTED bit might still be set, but the driver that cared is gone, so nothing bad happens if the PWM chip goes away even if the PWMF_REQUESTED is still present. So the check can be dropped. With this change pwmchip_remove() returns always 0, so lowlevel drivers don't need to check the return code any more. Once all drivers dropped this check this function can be changed to return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
The .remove() callback disables clocks that were not enabled in .probe(). So just probing and then unbinding the driver results in a clk enable imbalance. So just drop the call to disable the clocks. (Which BTW was also in the wrong order because the call makes the PWM unfunctional and so should have come only after pwmchip_remove()). Fixes: 9f4c8f96 ("pwm: imx: Add ipg clock operation") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
With devm_pwmchip_add() we can drop pwmchip_remove() from the device remove callback. The latter can then go away, too and as this is the only user of platform_get_drvdata(), the respective call to platform_set_drvdata() can go, too. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
This potentially simplifies low-level PWM drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
- 04 Jun, 2021 6 commits
-
-
Lokesh Vutla authored
Add compatible string for AM64 SoC in device tree binding. EPWM IP in AM64 does not support High resolution, so named epwm instead of ehrpwm in compatible. However IP is till compatible with features supported by driver with ti,am3352-ehrpwm compatible. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Lokesh Vutla authored
Convert the tiehrpwm binding to DT schema format using json-schema. Along with this conversion the following changes are included: - 'clock' and 'clock-names' properties are marked as required as driver fails to probe without these properties - Dropped ti,am33xx-ehrpwm as it is no longer applicable. - 'power-domains' property is introduced and marked as optional. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Clemens Gruber authored
Regmap operations can fail if the underlying subsystem is not working properly (e.g. hogged I2C bus, etc.) As this is useful information for the user, print an error message if it happens. Let probe fail if the first regmap_read or the first regmap_write fails. Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Clemens Gruber authored
Previously, the last used PWM channel could change the global prescale setting, even if other channels are already in use. Fix it by only allowing the first enabled PWM to change the global chip-wide prescale setting. If there is more than one channel in use, the prescale settings resulting from the chosen periods must match. GPIOs do not count as enabled PWMs as they are not using the prescaler and can't change it. Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Clemens Gruber authored
If usage_power is set, the pca9685 driver will phase shift the individual channels relative to their channel number. This improves EMI because the enabled channels no longer turn on at the same time, while still maintaining the configured duty cycle / power output. Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Clemens Gruber authored
If usage_power is set, the PWM driver is only required to maintain the power output but has more freedom regarding signal form. If supported, the signal can be optimized, for example to improve EMI by phase shifting individual channels. Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
- 25 May, 2021 8 commits
-
-
Uwe Kleine-König authored
Just using the previous callbacks to implment a similar procedure as the legacy handling in the core. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
Before pwmchip_remove() returns the PWM is expected to be functional. So remove the pwmchip before disabling the clocks. The check for pwmchip_remove()'s return value is dropped as this function returns effectively always 0 and returning an error in a remove callback is useless anyhow (as the device core ignores it and drops devm allocated resources). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
With the original code a request for period = 65536000 ns and period = 32768000 ns yields the same register settings (which results in 32768000 ns) because the value for pwmc0 was miscalculated. Also simplify using that fls(0) is 0. Fixes: 721b5957 ("pwm: visconti: Add Toshiba Visconti SoC PWM support") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
With the previous commit there is no need for the lowlevel driver any more to specify it it uses two or three cells. So simplify accordingly. The only non-trival change affects the pwm-rockchip driver: It used to only support three cells if the hardware supports polarity. Now the default number depends on the device tree which has to match hardware anyhow (and if it doesn't the error is just a bit delayed as a PWM handle with an inverted setting is catched when pwm_apply_state() is called). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
This allows to simplify all drivers that use three pwm-cells. The only ugly side effect is that if a driver specified of_pwm_n_cells = 2 it suddenly supports device trees that use #pwm-cells = <3>. This however isn't a bad thing because the driver doesn't need explicit support for three cells as the core handles all the details. Also there is no such in-tree driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
Since the previous commit the latter function can do everything that the former does. So simplify accordingly. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
Uwe Kleine-König authored
The two functions of_pwm_simple_xlate() and of_pwm_xlate_with_flags() are quite similar. of_pwm_simple_xlate() only supports two-cell PWM specifiers while of_pwm_xlate_with_flags() only supports PWM specifiers with 3 or more cells. The latter can easily be modified to behave identically to of_pwm_simple_xlate() for two-cell PWM specifiers. This is implemented here and allows to drop of_pwm_simple_xlate() in the next commit. There is a small detail that is different now in the two-cell specifier case in of_pwm_xlate_with_flags(): pwm->args.polarity is unconditionally initialized to PWM_POLARITY_NORMAL in the latter. I didn't find a case where this matters and doing that explicitly is the more robust approach. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [thierry.reding@gmail.com: fix up checkpatch warnings] Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
-
- 09 May, 2021 3 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Commit b9d79e4c ("fbmem: Mark proc_fb_seq_ops as __maybe_unused") places the '__maybe_unused' in an entirely incorrect location between the "struct" keyword and the structure name. It's a wonder that gcc accepts that silently, but clang quite reasonably warns about it: drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute declaration must precede definition [-Wignored-attributes] static const struct __maybe_unused seq_operations proc_fb_seq_ops = { ^ Fix it. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://anongit.freedesktop.org/drm/drmLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Bit later than usual, I queued them all up on Friday then promptly forgot to write the pull request email. This is mainly amdgpu fixes, with some radeon/msm/fbdev and one i915 gvt fix thrown in. amdgpu: - MPO hang workaround - Fix for concurrent VM flushes on vega/navi - dcefclk is not adjustable on navi1x and newer - MST HPD debugfs fix - Suspend/resumes fixes - Register VGA clients late in case driver fails to load - Fix GEM leak in user framebuffer create - Add support for polaris12 with 32 bit memory interface - Fix duplicate cursor issue when using overlay - Fix corruption with tiled surfaces on VCN3 - Add BO size and stride check to fix BO size verification radeon: - Fix off-by-one in power state parsing - Fix possible memory leak in power state parsing msm: - NULL ptr dereference fix fbdev: - procfs disabled warning fix i915: - gvt: Fix a possible division by zero in vgpu display rate calculation" * tag 'drm-next-2021-05-10' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: Use device specific BO size & stride check. drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode. drm/amd/pm: initialize variable drm/radeon: Avoid power table parsing memory leaks drm/radeon: Fix off-by-one power_state index heap overwrite drm/amd/display: Fix two cursor duplication when using overlay drm/amdgpu: add new MC firmware for Polaris12 32bit ASIC fbmem: Mark proc_fb_seq_ops as __maybe_unused drm/msm/dpu: Delete bonkers code drm/i915/gvt: Prevent divided by zero when calculating refresh rate amdgpu: fix GEM obj leak in amdgpu_display_user_framebuffer_create drm/amdgpu: Register VGA clients after init can no longer fail drm/amdgpu: Handling of amdgpu_device_resume return value for graceful teardown drm/amdgpu: fix r initial values drm/amd/display: fix wrong statement in mst hpd debugfs amdgpu/pm: set pp_dpm_dcefclk to readonly on NAVI10 and newer gpus amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID drm/amdgpu: fix concurrent VM flushes on Vega/Navi v2 drm/amd/display: Reject non-zero src_y and src_x for video planes
-