04 Jan, 2021
1 commit
-
This is the 5.10.4 stable release
* tag 'v5.10.4': (717 commits)
Linux 5.10.4
x86/CPU/AMD: Save AMD NodeId as cpu_die_id
drm/edid: fix objtool warning in drm_cvt_modes()
...Signed-off-by: Jason Liu
Conflicts:
drivers/gpu/drm/imx/dcss/dcss-plane.c
drivers/media/i2c/ov5640.c
30 Dec, 2020
4 commits
-
[ Upstream commit 6eefb79d6f5bc4086bd02c76f1072dd4a8d9d9f6 ]
Commit d3817a647059 ("pwm: sun4i: Remove redundant needs_delay") changed
the logic of an else branch so that the PWM_EN and PWM_CLK_GATING bits
are now cleared if the PWM is to be disabled, whereas previously the
condition was always false, and hence the branch never got executed.This code is reported causing backlight issues on boards based on the
Allwinner A20 SoC. Fix this by removing the else branch, which restores
the behaviour prior to the offending commit.Note that the PWM_EN and PWM_CLK_GATING bits still get cleared later in
sun4i_pwm_apply() if the PWM is to be disabled.Fixes: d3817a647059 ("pwm: sun4i: Remove redundant needs_delay")
Reported-by: Taras Galchenko
Suggested-by: Taras Galchenko
Tested-by: Taras Galchenko
Reviewed-by: Uwe Kleine-König
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin -
[ Upstream commit 1ce65396e6b2386b4fd54f87beff0647a772e1cd ]
The second parameter of do_div is an u32 and NSEC_PER_SEC * prescale
overflows this for bigger periods. Assuming the usual pwm input clk rate
of 66 MHz this happens starting at requested period > 606060 ns.Splitting the division into two operations doesn't loose any precision.
It doesn't need to be feared that c / NSEC_PER_SEC doesn't fit into the
unsigned long variable "duty_cycles" because in this case the assignment
above to period_cycles would already have been overflowing as
period >= duty_cycle and then the calculation is moot anyhow.Fixes: aef1a3799b5c ("pwm: imx27: Fix rounding behavior")
Signed-off-by: Uwe Kleine-König
Tested-by: Johannes Pointner
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin -
[ Upstream commit 1f0f1e80fdd3aa9631f6c22cda4f8550cfcfcc3e ]
When there are other PWM controllers enabled along with pwm-lp3943,
pwm-lp3942 is failing to probe with -EEXIST error. This is because
other PWM controllers are probed first and assigned PWM base 0 and
pwm-lp3943 is requesting for 0 again.In order to avoid this, assign the chip base with -1, so that it is
dynamically allocated.Fixes: af66b3c0934e ("pwm: Add LP3943 PWM driver")
Signed-off-by: Lokesh Vutla
Reviewed-by: Uwe Kleine-König
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin -
[ Upstream commit 269effd03f6142df4c74814cfdd5f0b041b30bf9 ]
zx_pwm_probe() called clk_prepare_enable() before; this must be undone
in the error path.Fixes: 4836193c435c ("pwm: Add ZTE ZX PWM device driver")
Signed-off-by: Uwe Kleine-König
Acked-by: Shawn Guo
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
14 Dec, 2020
2 commits
-
During suspend, all the tpm registers will loose values.
So the 'real_period' value of struct 'imx_tpm_pwm_chip'
should be forced to be zero to force the period update
code can be executed after system resume back.Signed-off-by: Fancy Fang
-
The PWM in i.MX8qxp MIPI subsystem needs to use the
'32k' clock to work properly. This patch gets this
clock in the PWM driver and uses it if it is supplied.Signed-off-by: Liu Ying
04 Dec, 2020
1 commit
-
Currently .get_state() and .apply() use dev_get_drvdata() on the struct
device related to the pwm chip. This only works after .probe() called
platform_set_drvdata() which in this driver happens only after
pwmchip_add() and so comes possibly too late.Instead of setting the driver data earlier use the traditional
container_of approach as this way the driver data is conceptually and
computational nearer.Fixes: 9db33d221efc ("pwm: Add support for sl28cpld PWM controller")
Tested-by: Michael Walle
Signed-off-by: Uwe Kleine-König
Signed-off-by: Linus Torvalds
25 Oct, 2020
1 commit
-
Pull ARM SoC platform updates from Olof Johansson:
"SoC changes, a substantial part of this is cleanup of some of the
older platforms that used to have a bunch of board files.In particular:
- Remove non-DT i.MX platforms that haven't seen activity in years,
it's time to remove them.- A bunch of cleanup and removal of platform data for TI/OMAP
platforms, moving over to genpd for power/reset control (yay!)- Major cleanup of Samsung S3C24xx and S3C64xx platforms, moving them
closer to multiplatform support (not quite there yet, but getting
close).There are a few other changes too, smaller fixlets, etc. For new
platform support, the primary ones are:- New SoC: Hisilicon SD5203, ARM926EJ-S platform.
- Cpufreq support for i.MX7ULP"
* tag 'armsoc-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (121 commits)
ARM: mstar: Select MStar intc
ARM: stm32: Replace HTTP links with HTTPS ones
ARM: debug: add UART early console support for SD5203
ARM: hisi: add support for SD5203 SoC
ARM: omap3: enable off mode automatically
clk: imx: imx35: Remove mx35_clocks_init()
clk: imx: imx31: Remove mx31_clocks_init()
clk: imx: imx27: Remove mx27_clocks_init()
ARM: imx: Remove unused definitions
ARM: imx35: Retrieve the IIM base address from devicetree
ARM: imx3: Retrieve the AVIC base address from devicetree
ARM: imx3: Retrieve the CCM base address from devicetree
ARM: imx31: Retrieve the IIM base address from devicetree
ARM: imx27: Retrieve the CCM base address from devicetree
ARM: imx27: Retrieve the SYSCTRL base address from devicetree
ARM: s3c64xx: bring back notes from removed debug-macro.S
ARM: s3c24xx: fix Wunused-variable warning on !MMU
ARM: samsung: fix PM debug build with DEBUG_LL but !MMU
MAINTAINERS: mark linux-samsung-soc list non-moderated
ARM: imx: Remove remnant board file support pieces
...
24 Oct, 2020
1 commit
-
…kernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung:
"cros-ec:
- Error code cleanup across cros-ec by Guenter
- Remove cros_ec_cmd_xfer in favor of cros_ec_cmd_xfer_statuscros_ec_typec:
- Landed initial USB4 support in typec connector class driver for
cros_ec
- Role switch bugfix on disconnect, and reordering configuration
stepscros_ec_lightbar:
- Fix buffer outsize and result for get_lightbar_versionmisc:
- Remove config MFD_CROS_EC, now that transition from MFD is complete
- Enable KEY_LEFTMETA in new location on arm based cros-ec-keyboard
keymap"* tag 'tag-chrome-platform-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
ARM: dts: cros-ec-keyboard: Add alternate keymap for KEY_LEFTMETA
platform/chrome: Use kobj_to_dev() instead of container_of()
platform/chrome: cros_ec_proto: Drop cros_ec_cmd_xfer()
platform/chrome: cros_ec_proto: Update cros_ec_cmd_xfer() call-sites
platform/chrome: Kconfig: Remove the transitional MFD_CROS_EC config
platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command
platform/chrome: cros_ec_trace: Add fields to command traces
platform/chrome: cros_ec_typec: Re-order connector configuration steps
platform/chrome: cros_ec_typec: Avoid setting usb role twice during disconnect
platform/chrome: cros_ec_typec: Send enum values to usb_role_switch_set_role()
platform/chrome: cros_ec_typec: USB4 support
pwm: cros-ec: Simplify EC error handling
platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPT
pwm: cros-ec: Accept more error codes from cros_ec_cmd_xfer_status
platform/chrome: cros_ec_sysfs: Report range of error codes from EC
cros_ec_lightbar: Accept more error codes from cros_ec_cmd_xfer_status
iio: cros_ec: Accept -EOPNOTSUPP as 'not supported' error code
23 Oct, 2020
1 commit
-
…ierry.reding/linux-pwm
Pull pwm updates from Thierry Reding:
"This release cycle's updates are mostly cleanup and some minor fixes"* tag 'pwm/for-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
dt-bindings: pwm: renesas,pwm-rcar: Add r8a7742 support
dt-bindings: pwm: renesas,tpu-pwm: Document r8a7742 support
pwm: Allow store 64-bit duty cycle from sysfs interface
pwm: img: Fix null pointer access in probe
pwm: pca9685: Disable unused alternative addresses
pwm: pca9685: Use BIT() macro instead of shift
pwm: pca9685: Make comments more consistent
pwm: sun4i: Simplify with dev_err_probe()
pwm: sprd: Simplify with dev_err_probe()
pwm: sifive: Simplify with dev_err_probe()
pwm: rockchip: Simplify with dev_err_probe()
pwm: jz4740: Simplify with dev_err_probe()
pwm: bcm2835: Simplify with dev_err_probe()
pwm: Convert to use DEFINE_SEQ_ATTRIBUTE macro
pwm: rockchip: Keep enabled PWMs running while probing
dt-bindings: pwm: renesas,pwm-rcar: Add r8a774e1 support
16 Oct, 2020
1 commit
-
Pull drm updates from Dave Airlie:
"Not a major amount of change, the i915 trees got split into display
and gt trees to better facilitate higher level review, and there's a
major refactoring of i915 GEM locking to use more core kernel concepts
(like ww-mutexes). msm gets per-process pagetables, older AMD SI cards
get DC support, nouveau got a bump in displayport support with common
code extraction from i915.Outside of drm this contains a couple of patches for hexint
moduleparams which you've acked, and a virtio common code tree that
you should also get via it's regular path.New driver:
- Cadence MHDP8546 DisplayPort bridge drivercore:
- cross-driver scatterlist cleanups
- devm_drm conversions
- remove drm_dev_init
- devm_drm_dev_alloc conversionttm:
- lots of refactoring and cleanupsbridges:
- chained bridge support in more driverspanel:
- misc new panelsscheduler:
- cleanup priority levelsdisplayport:
- refactor i915 code into helpers for nouveaui915:
- split into display and GT trees
- WW locking refactoring in GEM
- execbuf2 extension mechanism
- syncobj timeline support
- GEN 12 HOBL display powersaving
- Rocket Lake display additions
- Disable FBC on Tigerlake
- Tigerlake Type-C + DP improvements
- Hotplug interrupt refactoringamdgpu:
- Sienna Cichlid updates
- Navy Flounder updates
- DCE6 (SI) support for DC
- Plane rotation enabled
- TMZ state info ioctl
- PCIe DPC recovery support
- DC interrupt handling refactor
- OLED panel fixesamdkfd:
- add SMI events for thermal throttling
- SMI interface events ioctl update
- process eviction countersradeon:
- move to dma_ for allocations
- expose sclk via sysfsmsm:
- DSI support for sm8150/sm8250
- per-process GPU pagetable support
- Displayport supportmediatek:
- move HDMI phy driver to PHY
- convert mtk-dpi to bridge API
- disable mt2701 tmdstegra:
- bridge supportexynos:
- misc cleanupsvc4:
- dual display cleanupsast:
- cleanupsgma500:
- conversion to GPIOd APIhisilicon:
- misc reworksingenic:
- clock handling and format improvementsmcde:
- DSI supportmgag200:
- desktop g200 supportmxsfb:
- i.MX7 + i.MX8M
- alpha plane supportpanfrost:
- devfreq support
- amlogic SoC supportps8640:
- EDID from eDP retrievaltidss:
- AM65xx YUV workaroundvirtio:
- virtio-gpu exported resourcesrcar-du:
- R8A7742, R8A774E1 and R8A77961 support
- YUV planar format fixes
- non-visible plane handling
- VSP device reference count fix
- Kconfig fix to avoid displaying disabled options in .config"* tag 'drm-next-2020-10-15' of git://anongit.freedesktop.org/drm/drm: (1494 commits)
drm/ingenic: Fix bad revert
drm/amdgpu: Fix invalid number of character '{' in amdgpu_acpi_init
drm/amdgpu: Remove warning for virtual_display
drm/amdgpu: kfd_initialized can be static
drm/amd/pm: setup APU dpm clock table in SMU HW initialization
drm/amdgpu: prevent spurious warning
drm/amdgpu/swsmu: fix ARC build errors
drm/amd/display: Fix OPTC_DATA_FORMAT programming
drm/amd/display: Don't allow pstate if no support in blank
drm/panfrost: increase readl_relaxed_poll_timeout values
MAINTAINERS: Update entry for st7703 driver after the rename
Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
drm/amd/display: HDMI remote sink need mode validation for Linux
drm/amd/display: Change to correct unit on audio rate
drm/amd/display: Avoid set zero in the requested clk
drm/amdgpu: align frag_end to covered address space
drm/amdgpu: fix NULL pointer dereference for Renoir
drm/vmwgfx: fix regression in thp code due to ttm init refactor.
drm/amdgpu/swsmu: add interrupt work handler for smu11 parts
drm/amdgpu/swsmu: add interrupt work function
...
24 Sep, 2020
13 commits
-
PWM core was converted to u64 by the commit a9d887dc1c60 ("pwm: Convert
period and duty cycle to u64") but did not change the duty_cycle_store()
so it will error out if trying to pass a numeric string bigger than
2^32-1.Fix this by using u64 and kstrtou64() in duty_cycle_store().
Signed-off-by: Jarkko Nikula
Acked-by: Guru Das Srinagesh
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
dev_get_drvdata() is called in img_pwm_runtime_resume() before the
driver data is set.
When pm_runtime_enabled() returns false in img_pwm_probe() it calls
img_pwm_runtime_resume() which results in a null pointer access.This patch fixes the problem by setting the driver data earlier in the
img_pwm_probe() function.This crash was seen when booting the Imagination Technologies Creator
Ci40 (Marduk) with kernel 5.4 in OpenWrt.Fixes: e690ae526216 ("pwm: img: Add runtime PM")
Signed-off-by: Hauke Mehrtens
Acked-by: Lee Jones
Signed-off-by: Thierry Reding -
The PCA9685 supports listening to 1 or more alternative I2C chip addresses
for some special features that this driver does not support.
By default the LED ALLCALL address is active (default 0x70), which causes
this chip to respond to address 0x70 in addition to its main address
(0x41). This is not desireable if there is another device on the same bus
that uses this address (like a TMP103 for example).
Since this feature is not supported by this driver, it is best to disable
these addresses in the chip to avoid unsuspected bus collisions.Signed-off-by: David Jander
Signed-off-by: Thierry Reding -
Signed-off-by: David Jander
Signed-off-by: Thierry Reding -
Make all explanatory comments start with an uppercase char.
Signed-off-by: David Jander
Signed-off-by: Thierry Reding -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Acked-by: Chunyan Zhang
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Acked-by: Palmer Dabbelt
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Acked-by: Florian Fainelli
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code.
Signed-off-by: Liu Shixin
Acked-by: Uwe Kleine-König
Signed-off-by: Thierry Reding -
Following commit cfc4c189bc70 ("pwm: Read initial hardware state at
request time") the Rockchip PWM driver can no longer assume a device's
pwm_state structure has been populated after a call to pwmchip_add().
Consequently, the test in rockchip_pwm_probe() intended to prevent the
driver from stopping PWM devices already enabled by the bootloader no
longer functions reliably and this can lead to the kernel hanging
during startup, particularly on devices like the Pinebook Pro that use
a PWM-controlled backlight for their display.Avoid this by querying the device directly at probe time to determine
whether or not it is enabled.Fixes: cfc4c189bc70 ("pwm: Read initial hardware state at request time")
Signed-off-by: Simon South
Reviewed-by: Uwe Kleine-König
Reviewed-by: Heiko Stuebner
Signed-off-by: Thierry Reding
17 Sep, 2020
1 commit
-
Add support for the PWM controller of the sl28cpld board management
controller. This is part of a multi-function device driver.The controller has one PWM channel and can just generate four distinct
frequencies.Signed-off-by: Michael Walle
Acked-by: Thierry Reding
Reviewed-by: Uwe Kleine-König
Signed-off-by: Lee Jones
12 Sep, 2020
1 commit
-
Sync drm-intel-gt-next here so we can have an unified fixes flow.
Signed-off-by: Rodrigo Vivi
06 Sep, 2020
11 commits
-
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-14-hdegoede@redhat.com -
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-13-hdegoede@redhat.com -
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN registerSo far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set it again on re-enable.Acked-by: Uwe Kleine-König
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-12-hdegoede@redhat.com -
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN registerThe BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable pin for LCD panels, this GPO is part of the PMIC's
"Display Panel Control Block." . This pin should probably be moved over
to a GPIO provider driver (and consumers modified accordingly), but that
is something for an(other) patch.Enabling / disabling the actual PWM output is controlled by the
PWM_OUTPUT_ENABLE bit of the PWM0_CLK_DIV register.As the comment in the old code already indicates we must disable the PWM
before we can change the clock divider. But the crc_pwm_disable() and
crc_pwm_enable() calls the old code make for this only change the
BACKLIGHT_EN register; and the value of that register does not matter for
changing the period / the divider. What does matter is that the
PWM_OUTPUT_ENABLE bit must be cleared before a new value can be written.This commit modifies crc_pwm_config() to clear PWM_OUTPUT_ENABLE instead
when changing the period, so that period changes actually work.Note this fix will cause a significant behavior change on some devices
using the CRC PWM output to drive their backlight. Before the PWM would
always run with the output frequency configured by the BIOS at boot, now
the period time specified by the i915 driver will actually be honored.Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-11-hdegoede@redhat.com -
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested frequency was so high that the
calculation has already resulted in a (rounded) divider value of 0.Note that before this fix, setting a period of PWM_MAX_PERIOD_NS which
corresponds to the max. divider value of 128 could have resulted in a
bug where the code would use 128 as divider-register value which would
have resulted in an actual divider value of 0 (and the enable bit being
set). A rounding error stopped this bug from actually happen. This
same rounding error means that after the subtraction of 1 it is impossible
to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow
setting a divider of 128 (register-value 127).Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-10-hdegoede@redhat.com -
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.The pwm-crc code before this commit assumed that a clock-divider
setting of 1 means that the PWM output is running at 6 MHZ, if that
is true, where do these 256 duty-cycle steps come from?This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that
seems unlikely for a PMIC which is using a silicon process optimized for
power-switching transistors. It is way more likely that there is an 8
bit counter for the duty cycle which acts as an extra fixed divider
wrt the PWM output frequency.The main user of the pwm-crc driver is the i915 GPU driver which uses it
for backlight control. Lets compare the PWM register values set by the
video-BIOS (the GOP), assuming the extra fixed divider is present versus
the PWM frequency specified in the Video-BIOS-Tables:Device: PWM Hz set by BIOS PWM Hz specified in VBT
Asus T100TA 200 200
Asus T100HA 200 200
Lenovo Miix 2 8 23437 20000
Toshiba WT8-A 23437 20000So as we can see if we assume the extra division by 256 then the register
values set by the GOP are an exact match for the VBT values, where as
otherwise the values would be of by a factor of 256.This commit fixes the period / duty_cycle calculations to take the
extra division by 256 into account.Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-9-hdegoede@redhat.com -
PWM controller drivers should not restore the PWM state on resume. The
convention is that PWM consumers do this by calling pwm_apply_state(),
so that it can be done at the exact moment when the consumer needs
the state to be stored, avoiding e.g. backlight flickering.The only in kernel consumers of the pwm-lpss code, the i915 driver
and the pwm-class sysfs interface code both correctly restore the
state on resume, so there is no need to do this in the pwm-lpss code.More-over the removed resume handler is buggy, since it blindly
restores the ctrl-register contents without setting the update
bit, which is necessary to get the controller to actually use/apply
the restored base-unit and on-time-div values.Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-8-hdegoede@redhat.com -
Before this commit pwm_lpss_apply() was assuming 2 pre-conditions
were met by the existing hardware state:1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the desired values.2. That the controller is enabled when the cached
pwm_state.enabled says that the controller is enabled.As the long history of fixes for subtle (often suspend/resume)
lpss-pwm issues shows, these assumptions are not necessary
always true.1. Specifically is not true on some (*) Cherry Trail devices
with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
b. sets the base-unit to 0 and writes the update bit to apply/commit
c. restores the original ctrl value without setting the update bit,
so that the 0 base-unit value is still in use.2. Assumption 2. currently is true, but only because of the code which
saves/restores the state on suspend/resume. By convention restoring the
PWM state should be done by the PWM consumer and the presence of this
code in the pmw-lpss driver is a bug. Therefor the save/restore code will
be dropped in the next patch in this series, after which this assumption
also is no longer true.This commit changes the pwm_lpss_apply() to not make any assumptions about
the state the hardware is in. Instead it makes pwm_lpss_apply() always
fully program the PWM controller, making it much less fragile.*) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
and various Medion models.Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-7-hdegoede@redhat.com -
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enabled -> enabled transition there, so that we can error check
the entire transition in a single place and only have one pm_runtime_put()
on failure call site.While working on this I noticed that the enabled -> enabled (update
settings) path was quite similar, so I've added an enable parameter to
the new pwm_lpss_prepare_enable() helper, which allows using it in that
path too.Suggested-by: Andy Shevchenko
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-6-hdegoede@redhat.com -
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:base_unit &= (base_unit_range - 1);
But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com -
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input clock-cycles the counter has been increased from 0 to
65535 and it will overflow on the next cycle, so it will overflow after
every 65536 clock cycles and thus the calculations done in
pwm_lpss_prepare() should use 65536 and not 65535.This commit fixes this. Note this also aligns the calculations in
pwm_lpss_prepare() with those in pwm_lpss_get_state().Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid
potential overflow of base_unit"). The next patch in this series really
fixes the potential overflow of the base_unit value.Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko
Acked-by: Uwe Kleine-König
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-4-hdegoede@redhat.com
24 Aug, 2020
2 commits
-
With enhanced error reporting from cros_ec_cmd_xfer_status() in place,
we can fully use it and no longer rely on EC error codes.Acked-by: Uwe Kleine-König
Reviewed-by: Brian Norris
Signed-off-by: Guenter Roeck
Signed-off-by: Enric Balletbo i Serra -
Since commit c5cd2b47b203 ("platform/chrome: cros_ec_proto: Report command
not supported") we can no longer assume that cros_ec_cmd_xfer_status()
reports -EPROTO for all errors returned by the EC itself. A follow-up
patch will change cros_ec_cmd_xfer_status() to report additional errors
reported by the EC as distinguished Linux error codes.Handle this change by no longer assuming that only -EPROTO is used
to report all errors returned by the EC itself. Instead, support both
the old and the new error codes.Add a comment describing cros_ec_num_pwms() to explain its functionality.
Cc: Gwendal Grignou
Cc: Yu-Hsuan Hsu
Cc: Prashant Malani
Cc: Brian Norris
Acked-by: Thierry Reding
Acked-by: Uwe Kleine-König
Signed-off-by: Guenter Roeck
Signed-off-by: Enric Balletbo i Serra
