PWM waveform, axi-pwmgen backport #2640

This should help reduce future merge conflicts as more gets backported from upstream, since backporting the rename from there doesn't apply cleanly and might cause issues with other backports. Signed-off-by: Trevor Gamblin <[email protected]>

core.c includes sysfs.c logic now, so remove the latter. Signed-off-by: Trevor Gamblin <[email protected]>

Signed-off-by: Trevor Gamblin <[email protected]>

Origin: v6.12-rc5 commit: b0cde62 This allows to simplify drivers that use clk_rate_exclusive_get() in their probe routine as calling clk_rate_exclusive_put() is cared for automatically. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Russell King (Oracle) <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Backport from upstream so that the axi-pwmgen driver can continue making use of it. Signed-off-by: Trevor Gamblin <[email protected]>

Signed-off-by: Trevor Gamblin <[email protected]>

Origin: pwm/duty_offset-for-6.13-rc1 commit: 1cc2e1f This ensures that a pwm_chip that has no corresponding driver isn't used and that a driver doesn't go away while a callback is still running. In the presence of device links this isn't necessary yet (so this is no fix) but for pwm character device support this is needed. To not serialize all pwm_apply_state() calls, this introduces a per chip lock. An additional complication is that for atomic chips a mutex cannot be used (as pwm_apply_atomic() must not sleep) and a spinlock cannot be held while calling an operation for a sleeping chip. So depending on the chip being atomic or not a spinlock or a mutex is used. An additional change implemented here is that on driver remove the .free() callback is called for each requested pwm_device. This is the right time because later (e.g. when the consumer calls pwm_put()) the free function is (maybe) not available any more. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/026aa891c8270a11723a1ba7e4256f456f7e1e86.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <[email protected]> Backport from upstream and adjust to apply without the __counted_by() macro. Signed-off-by: Trevor Gamblin <[email protected]>

Origin: pwm/duty_offset-for-6.13-rc1, commit: 17e40c2 Up to now the configuration of a PWM setting is described exclusively by a struct pwm_state which contains information about period, duty_cycle, polarity and if the PWM is enabled. (There is another member usage_power which doesn't completely fit into pwm_state, I ignore it here for simplicity.) Instead of a polarity the new abstraction has a member duty_offset_ns that defines when the rising edge happens after the period start. This is more general, as with a pwm_state the rising edge can only happen at the period's start or such that the falling edge is at the end of the period (i.e. duty_offset_ns == 0 or duty_offset_ns == period_length_ns - duty_length_ns). A disabled PWM is modeled by .period_length_ns = 0. In my eyes this is a nice usage of that otherwise unusable setting, as it doesn't define anything about the future which matches the fact that consumers should consider the state of the output as undefined and it's just there to say "No further requirements about the output, you can save some power.". Further I renamed period and duty_cycle to period_length_ns and duty_length_ns. In the past there was confusion from time to time about duty_cycle being measured in nanoseconds because people expected a percentage of period instead. With "length_ns" as suffix the semantic should be more obvious to people unfamiliar with the pwm subsystem. period is renamed to period_length_ns for consistency. The API for consumers doesn't change yet, but lowlevel drivers can implement callbacks that work with pwm_waveforms instead of pwm_states. A new thing about these callbacks is that the calculation of hardware settings needed to implement a certain waveform is separated from actually writing these settings. The motivation for that is that this allows a consumer to query the hardware capabilities without actually modifying the hardware state. The rounding rules that are expected to be implemented in the round_waveform_tohw() are: First pick the biggest possible period not bigger than wf->period_length_ns. For that period pick the biggest possible duty setting not bigger than wf->duty_length_ns. Third pick the biggest possible offset not bigger than wf->duty_offset_ns. If the requested period is too small for the hardware, it's expected that a setting with the minimal period and duty_length_ns = duty_offset_ns = 0 is returned and this fact is signaled by a return value of 1. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Trevor Gamblin <[email protected]> Link: https://lore.kernel.org/r/df0faa33bf9e7c9e2e5eab8d31bbf61e861bd401.1726819463.git.u.kleine-koenig@baylibre.com [ukleinek: Update pwm_check_rounding() to return bool instead of int.] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Trevor Gamblin <[email protected]>

Origin: pwm/duty_offset-for-6.13-rc1, commit: 6c5126c Provide API functions for consumers to work with waveforms. Note that one relevant difference between pwm_get_state() and pwm_get_waveform*() is that the latter yields the actually configured hardware state, while the former yields the last state passed to pwm_apply*() and so doesn't account for hardware specific rounding. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Trevor Gamblin <[email protected]> Link: https://lore.kernel.org/r/6c97d27682853f603e18e9196043886dd671845d.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Trevor Gamblin <[email protected]>

Origin: pwm/duty_offset-for-6.13-rc1, commit: 1afd01d This adds trace events for the recently introduced waveform callbacks. With the introduction of some helper macros consistency among the different events is ensured. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/1d71879b0de3bf01459c7a9d0f040d43eb5ace56.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Trevor Gamblin <[email protected]>

Origin: pwm/duty_offset-for-6.13-rc1, commit: eb18504 Convert the axi-pwmgen driver to use the new callbacks for hardware programming. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Trevor Gamblin <[email protected]> Link: https://lore.kernel.org/r/922277f07b1d1fb9c9cd915b1ec3fdeec888a916.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Trevor Gamblin <[email protected]>

Origin: pwm/duty_offset-for-6.13-rc1, commit: 65406de This moves pwm_get() and friends above the functions handling registration of pwmchips. The motivation is that character device support needs pwm_get() and pwm_put() and so ideally is defined below these and when a pwmchip is registered this registers the character device. So the natural order is pwm_get() and friend pwm character device symbols pwm_chip functions . The advantage of having these in their natural order is that static functions don't need to be forward declared. Note that the diff that git produces for this change some functions are moved down instead. This is technically equivalent, but not how this change was created. Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/193b3d933294da34e020650bff93b778de46b1c5.1726819463.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Trevor Gamblin <[email protected]>

Origin: pwm/duty_offset-for-6.13-rc1, commit: dab9cd4 The callbacks for lowlevel pwm drivers were expanded to handle the new waveform abstraction. When doing that I missed to expand the kernel doc description. This is catched up here. Reported-by: Stephen Rothwell <[email protected]> Link: https://lore.kernel.org/linux-next/[email protected] Fixes: 17e40c2 ("pwm: New abstraction for PWM waveforms") Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Trevor Gamblin <[email protected]>

…from a chip Origin: pwm/for-next, commit: 22f032c7900c Compared to direct calls to pwmchip_get_drvdata() a dedicated function has two upsides: A better name and the right type. So the code becomes easier to read and the new function is harder to use wrongly. Another side effect (which is the secret motivation for this patch, but shhh) is that the driver becomes a bit easier to backport to kernel versions that don't have devm_pwmchip_alloc() yet. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Trevor Gamblin <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ukleinek: added an * to the new function's prototype to make the compiler happy] Signed-off-by: Uwe Kleine-König <[email protected]>

Origin: pwm/for-next, commit: 2e82d58c7ba8 Rename the 0x10 register from REG_CONFIG to REG_RSTN. Also rename the associated bit macros accordingly. While touching this, move the bit macros close to the register address macro for better organization. According to [1], the name of the 0x10 register is REG_RSTN, and there is a different register named REG_CONFIG (0x18). So we should not be using REG_CONFIG for the 0x10 register to avoid confusion. [1]: http://analogdevicesinc.github.io/hdl/library/axi_pwm_gen/index.html Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/20241009-pwm-axi-pwmgen-enable-force_align-v1-1-5d6ad8cbf5b4@baylibre.com Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Trevor Gamblin <[email protected]>

Origin: pwm/for-next, commit: 15effedc481e Enable the FORCE_ALIGN flag by default in the AXI PWMGEN driver. This flag makes the behavior of the PWM output consistent with the description at the top of the driver file. * Limitations: * - The writes to registers for period and duty are shadowed until * LOAD_CONFIG is written to AXI_PWMGEN_REG_RSTN, at which point * they take effect. * - Writing LOAD_CONFIG also has the effect of re-synchronizing all * enabled channels, which could cause glitching on other channels. It * is therefore expected that channels are assigned harmonic periods * and all have a single user coordinating this. Without this flag, the PWM output does not change until the period of all PWM output channels has run out, which makes the PWM impossible to use in some cases because it takes too long to change the output. Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/20241009-pwm-axi-pwmgen-enable-force_align-v1-2-5d6ad8cbf5b4@baylibre.com Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Trevor Gamblin <[email protected]>

It is being set but likely isn't used, so remove it to avoid build errors now that the new PWM waveform API is included. Signed-off-by: Trevor Gamblin <[email protected]>

Signed-off-by: Trevor Gamblin <[email protected]>

Also change AD4630_TQUIET_CNV_DELAY_PS to AD4630_TQUIET_CNV_DELAY_NS and the nearest appropriate value, so that we don't have to round when calculating PWM offsets now. Signed-off-by: Trevor Gamblin <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PWM waveform, axi-pwmgen backport #2640

PWM waveform, axi-pwmgen backport #2640

Commits on Nov 21, 2024

PWM waveform, axi-pwmgen backport #2640

Are you sure you want to change the base?

PWM waveform, axi-pwmgen backport #2640

Commits on Nov 21, 2024