| 2528eec7 | 05-Mar-2025 |
Abel Vesa <[email protected]> |
leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs
When determining the actual best period by looping through all
possible PWM configs, the resolution currently used is based on
bi
leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs
When determining the actual best period by looping through all
possible PWM configs, the resolution currently used is based on
bit shift value which is off-by-one above the possible maximum
PWM value allowed.
So subtract one from the resolution before determining the best
period so that the maximum duty cycle requested by the PWM user
won't result in a value above the maximum allowed by the selected
resolution.
Cc: [email protected] # 6.4
Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-3-bfe124a53a9f@linaro.org
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| b7881eac | 05-Mar-2025 |
Abel Vesa <[email protected]> |
leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs
Ideally, the requested duty cycle should never translate to a PWM
value higher than the selected resolution (PWM size), but currently
leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs
Ideally, the requested duty cycle should never translate to a PWM
value higher than the selected resolution (PWM size), but currently the
best matched period is never reported back to the PWM consumer, so the
consumer will still be using the requested period which is higher than
the best matched one. This will result in PWM consumer requesting
duty cycle values higher than the allowed PWM value.
For example, a consumer might request a period of 5ms while the best
(closest) period the PWM hardware will do is 4.26ms. For this best
matched resolution, if the selected resolution is 8-bit wide, when
the consumer asks for a duty cycle of 5ms, the PWM value will be 300,
which is outside of what the resolution allows. This will happen with
all possible resolutions when selected.
Since for these Hi-Res PWMs, the current implementation is capping the PWM
value at a 15-bit resolution, even when lower resolutions are selected,
the value will be wrapped around by the HW internal logic to the selected
resolution.
Fix the issue by capping the PWM value to the maximum value allowed by
the selected resolution.
Cc: [email protected] # 6.4
Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-2-bfe124a53a9f@linaro.org
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| 2fc21e4d | 05-Mar-2025 |
Abel Vesa <[email protected]> |
leds: rgb: leds-qcom-lpg: Fix pwm resolution max for normal PWMs
Ideally, the requested duty cycle should never translate to a PWM
value higher than the selected resolution (PWM size), but currently
leds: rgb: leds-qcom-lpg: Fix pwm resolution max for normal PWMs
Ideally, the requested duty cycle should never translate to a PWM
value higher than the selected resolution (PWM size), but currently the
best matched period is never reported back to the PWM consumer, so the
consumer will still be using the requested period which is higher than
the best matched one. This will result in PWM consumer requesting
duty cycle values higher than the allowed PWM value.
For example, a consumer might request a period of 5ms while the best
(closest) period the PWM hardware will do is 4.26ms. For this best
matched resolution, if the selected resolution is 9-bit wide, when
the consumer asks for a duty cycle of 5ms, the PWM value will be 600,
which is outside of what the resolution allows. Similar will happen
if the 6-bit resolution is selected.
Since for these normal PWMs (non Hi-Res), the current implementation is
capping the PWM value at a 9-bit resolution, even when the 6-bit
resolution is selected, the value will be wrapped around to 6-bit value
by the HW internal logic.
Fix the issue by capping the PWM value to the maximum value allowed by
the selected resolution.
Fixes: 7a3350495d9a ("leds: rgb: leds-qcom-lpg: Add support for 6-bit PWM resolution")
Suggested-by: Anjelique Melendez <[email protected]>
Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-1-bfe124a53a9f@linaro.org
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| bf3fba72 | 26-Sep-2024 |
Javier Carrasco <[email protected]> |
leds: rgb: mt6370: Switch to device_for_each_child_node_scoped()
Switch to device_for_each_child_node_scoped() to simplify the code by
removing the need for calls to fwnode_handle_put() in the error
leds: rgb: mt6370: Switch to device_for_each_child_node_scoped()
Switch to device_for_each_child_node_scoped() to simplify the code by
removing the need for calls to fwnode_handle_put() in the error paths.
This also prevents possible memory leaks if new error paths are added
without the required call to fwnode_handle_put().
After switching to the scoped variant, there is no longer need for a
jump to 'fwnode_release', as an immediate return is possible. Given that
the loop is called in the probe function, and it already uses
dev_err_probe(), the common "dev_err() + return" has been updated as
well.
Signed-off-by: Javier Carrasco <[email protected]>
Link: https://lore.kernel.org/r/20240927-leds_device_for_each_child_node_scoped-v1-18-95c0614b38c8@gmail.com
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| 7e776e21 | 07-Jun-2024 |
Anjelique Melendez <[email protected]> |
leds: rgb: leds-qcom-lpg: Add PPG check for setting/clearing PBS triggers
Currently, all LED LPG devices will call lpg_{set,clear}_pbs_trigger()
when setting brightness regardless of if they support
leds: rgb: leds-qcom-lpg: Add PPG check for setting/clearing PBS triggers
Currently, all LED LPG devices will call lpg_{set,clear}_pbs_trigger()
when setting brightness regardless of if they support PPG and have PBS
triggers. Check if device supports PPG before setting/clearing PBS
triggers.
Fixes: 6ab1f766a80a ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM")
Fixes: 5e9ff626861a ("leds: rgb: leds-qcom-lpg: Include support for PPG with dedicated LUT SDAM")
Signed-off-by: Anjelique Melendez <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| e1b08c6f | 31-May-2024 |
Hans de Goede <[email protected]> |
leds: rgb: leds-ktd202x: Initialize mutex earlier
The mutex must be initialized before the LED class device is registered
otherwise there is a race where it may get used before it is initialized:
leds: rgb: leds-ktd202x: Initialize mutex earlier
The mutex must be initialized before the LED class device is registered
otherwise there is a race where it may get used before it is initialized:
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 2 PID: 2045 at kernel/locking/mutex.c:587 __mutex_lock
...
RIP: 0010:__mutex_lock+0x7db/0xc10
...
set_brightness_delayed_set_brightness.part.0+0x17/0x60
set_brightness_delayed+0xf1/0x100
process_one_work+0x222/0x5a0
Move the mutex_init() call earlier to avoid this race condition and
switch to devm_mutex_init() to avoid the need to add error-exit
cleanup to probe() if probe() fails later on.
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| f2994f53 | 28-Apr-2024 |
Christophe JAILLET <[email protected]> |
leds: mt6370: Remove unused field 'reg_cfgs' from 'struct mt6370_priv'
In 'struct mt6370_priv', the 'reg_cfgs' field is unused. Moreover
'struct reg_cfg' isn't defined anywhere, so remove it.
Found
leds: mt6370: Remove unused field 'reg_cfgs' from 'struct mt6370_priv'
In 'struct mt6370_priv', the 'reg_cfgs' field is unused. Moreover
'struct reg_cfg' isn't defined anywhere, so remove it.
Found with cppcheck, unusedStructMember.
Signed-off-by: Christophe JAILLET <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Link: https://lore.kernel.org/r/e389be5e1012dc05fc2641123883ca3b0747525a.1714328839.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| 45066c4b | 05-Mar-2024 |
Abdel Alkuor <[email protected]> |
leds: ncp5623: Add MS suffix to time defines
To make the time macro defines clearer, add MS as a suffix.
Signed-off-by: Abdel Alkuor <[email protected]>
Link: https://lore.kernel.org/r/2024030513382
leds: ncp5623: Add MS suffix to time defines
To make the time macro defines clearer, add MS as a suffix.
Signed-off-by: Abdel Alkuor <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| bfa0f02d | 12-Feb-2024 |
Arnd Bergmann <[email protected]> |
leds: qcom-lpg: Add QCOM_PBS dependency
The lpg driver fails to link now when the pbs driver is in a loadable module:
x86_64-linux-ld: drivers/leds/rgb/leds-qcom-lpg.o: in function `lpg_brightness_
leds: qcom-lpg: Add QCOM_PBS dependency
The lpg driver fails to link now when the pbs driver is in a loadable module:
x86_64-linux-ld: drivers/leds/rgb/leds-qcom-lpg.o: in function `lpg_brightness_set':
leds-qcom-lpg.c:(.text+0xe7f): undefined reference to `qcom_pbs_trigger_event'
x86_64-linux-ld: drivers/leds/rgb/leds-qcom-lpg.o: in function `lpg_probe':
leds-qcom-lpg.c:(.text+0x16a5): undefined reference to `get_pbs_client_device'
Add a dependency to avoid the broken configuration. Apparently there is still
a use for lpg with pbs disabled entirely for certain chips, so allow both
but not LEDS_QCOM_LPG=y with QCOM_PBS=m.
Fixes: 214110175679 ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Jean Delvare <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| ec9aa897 | 06-Feb-2024 |
Aren Moynihan <[email protected]> |
leds: rgb: leds-group-multicolor: Allow LEDs to stay on in suspend
If none of the managed LEDs enable LED_CORE_SUSPENDRESUME, then we
shouldn't need to set it here. This makes it possible to use mul
leds: rgb: leds-group-multicolor: Allow LEDs to stay on in suspend
If none of the managed LEDs enable LED_CORE_SUSPENDRESUME, then we
shouldn't need to set it here. This makes it possible to use multicolor
groups with GPIO LEDs that enable retain-state-suspended in the device
tree.
Signed-off-by: Aren Moynihan <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[Lee: Changed the comment to respect proper grammar]
Signed-off-by: Lee Jones <[email protected]>
show more ...
|
| c47d1454 | 21-Dec-2023 |
Anjelique Melendez <[email protected]> |
leds: rgb: Update PM8350C lpg_data to support two-nvmem PPG Scheme
Update the pm8350c lpg_data struct so that pm8350c devices are treated as
PWM devices that support two-nvmem PPG scheme.
Signed-of
leds: rgb: Update PM8350C lpg_data to support two-nvmem PPG Scheme
Update the pm8350c lpg_data struct so that pm8350c devices are treated as
PWM devices that support two-nvmem PPG scheme.
Signed-off-by: Anjelique Melendez <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
show more ...
|