linux-toradex.git/drivers/pwm, branch v5.0

pwm: imx: Add ipg clock operation

2018-12-24T11:06:56+00:00

i.MX PWM module's ipg_clk_s is for PWM register access, on most of i.MX
SoCs, this ipg_clk_s is from system ipg clock or perclk which is always
enabled, but on i.MX7D, the ipg_clk_s is from PWM1_CLK_ROOT which is
controlled by CCGR132, that means the CCGR132 MUST be enabled first
before accessing PWM registers on i.MX7D. This patch adds ipg clock
operation to make sure register access successfully on i.MX7D and it
fixes Linux kernel boot up hang during PWM driver probe.

Fixes: 4a23e6ee9f69 ("ARM: dts: imx7d-sdb: Restore pwm backlight support")
Signed-off-by: Anson Huang 
Signed-off-by: Thierry Reding

pwm: clps711x: Switch to SPDX identifier

2018-12-24T11:06:56+00:00

Adopt the SPDX license identifier headers to ease license compliance
management.

Signed-off-by: Alexander Shiyan 
Signed-off-by: Thierry Reding

pwm: clps711x: Fix period calculation

2018-12-24T11:06:55+00:00

Commit e39c0df1be5a ("pwm: Introduce the pwm_args concept") has
changed the variable for the period for clps711x-pwm driver, so now
pwm_get/set_period() works with pwm->state.period variable instead
of pwm->args.period.
This patch changes the period variable in other places where it is used.

Signed-off-by: Alexander Shiyan 
Signed-off-by: Thierry Reding

pwm: bcm2835: Switch to SPDX identifier

2018-12-24T11:06:55+00:00

Adopt the SPDX license identifier headers to ease license compliance
management.

Cc: Bart Tanghe 
Signed-off-by: Stefan Wahren 
Reviewed-by: Eric Anholt 
Signed-off-by: Thierry Reding

pwm: Enable Kona PWM to be built for the Cygnus architecture

2018-12-24T11:06:47+00:00

The Cygnus architecture uses a Kona PWM. This is already present in the
device tree but can't be built actually. Hence, allow the Kona PWM to
be built for the Cygnus architecture.

Signed-off-by: Clément Péron 
Reviewed-by: Florian Fainelli 
Reviewed-by: Scott Branden 
Acked-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding

pwm: imx: Implement get_state() function for hardware readout

2018-12-12T10:52:47+00:00

Implement the get_state() function and set the initial state to reflect
real state of the hardware. This allows to keep the PWM running if it was
enabled in bootloader. It is very similar to the GPIO behavior. GPIO pin
set as output in bootloader keep the same setting in Linux unless it is
reconfigured.

If we find the PWM block enabled we need to prepare and enable its source
clock otherwise the clock will be disabled late in the boot as unused.
That will leave the PWM in enabled state but with disabled clock. That has
a side effect that the PWM output is left at its current level at which
the clock was disabled. It is totally non-deterministic and it may be LOW
or HIGH.

Signed-off-by: Michal Vokáč 
Signed-off-by: Thierry Reding

pwm: imx: Use bitops and bitfield macros to define register values

2018-12-12T10:52:32+00:00

Use existing macros to define register fields instead of manually shifting
the bit masks. Also define some more register bits.

Signed-off-by: Michal Vokáč 
Signed-off-by: Thierry Reding

pwm: imx: Sort include files

2018-12-12T10:51:15+00:00

Sort included header files alphabetically.

Signed-off-by: Michal Vokáč 
Signed-off-by: Thierry Reding

pwm: lpc18xx-sct: Don't reconfigure PWM in .request and .free

2018-11-16T10:02:47+00:00

Regarding the .request case: The consumer might be interested in taking
over the configured state from the boot loader. So the initially
configured state should be retained.

For the free case the PWM consumer is responsible for disabling the PWM
before calling pwm_put() and there are three subcases to consider:

 a) The PWM is already off. Then there is no gain in disabling the PWM
    once more.
 b) The PWM is still running and there is a good reason for that. (Not
    sure this is a valid case, I cannot imagine such a good reason.)
    Then it is counterproductive to disable the PWM.
 c) The PWM is still running because the consumer failed to disable the
    PWM. Then the consumer needs fixing and there is little incentive to
    paper over the problem in the backend driver.

This aligns the lpc18xx-sct driver to the other PWM drivers that also
don't reconfigure the hardware in .request and .free.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Thierry Reding

pwm: lpss: Only set update bit if we are actually changing the settings

2018-10-16T11:16:15+00:00

According to the datasheet the update bit must be set if the on-time-div
or the base-unit changes.

Now that we properly order device resume on Cherry Trail so that the GFX0
_PS0 method no longer exits with an error, we end up with a sequence of
events where we are writing the same values twice in a row.

First the _PS0 method restores the duty cycle of 0% the GPU driver set
on suspend and then the GPU driver first updates just the enabled bit in
the pwm_state from 0 to 1, causing us to write the same values again,
before restoring the pre-suspend duty-cycle in a separate pwm_apply call.

When writing the update bit the second time, without changing any of
the values the update bit clears immediately / instantly, instead of
staying 1 for a while as usual. After this the next setting of the update
bit seems to be ignored, causing the restoring of the pre-suspend
duty-cycle to not get applied. This makes the backlight come up with
a 0% dutycycle after suspend/resume.

Any further brightness changes after this do work.

This commit moves the setting of the update bit into pwm_lpss_prepare()
and only sets the bit if we have actually changed any of the values.

This avoids the setting of the update bit the second time we configure
the PWM to 0% dutycycle, this fixes the backlight coming up with 0%
duty-cycle after a suspend/resume.

Signed-off-by: Hans de Goede 
Signed-off-by: Thierry Reding