<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/pwm, branch linux-4.20.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.20.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.20.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-10-16T11:16:15+00:00</updated>
<entry>
<title>pwm: lpss: Only set update bit if we are actually changing the settings</title>
<updated>2018-10-16T11:16:15+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-10-14T15:12:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2153bbc12f77fb2203276befc0f0dddbfb023bb1'/>
<id>urn:sha1:2153bbc12f77fb2203276befc0f0dddbfb023bb1</id>
<content type='text'>
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 &lt;hdegoede@redhat.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>pwm: lpss: Force runtime-resume on suspend on Cherry Trail</title>
<updated>2018-10-16T11:15:57+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-10-14T15:12:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4743765babb278a7d399df5733fc8a6b6bbedf3e'/>
<id>urn:sha1:4743765babb278a7d399df5733fc8a6b6bbedf3e</id>
<content type='text'>
On Cherry Trail devices under Windows the PWM controller used for the
backlight is considered part of the GPU even though it is part of the LPSS
block and thus is an entirely different independent hardware unit.

Because of this on Cherry Trail the GPU's (GFX0 ACPI node) _PS3 and _PS0
methods save and restore the PWM controller registers.

If userspace blanks the screen before suspending, such as e.g. GNOME
does, then the PWM controller will be runtime-suspended when the suspend
starts. This causes the GFX0 _PS? methods to save a value of 0xffffffff
for the PWM control register and to restore this value on resume.

0xffffffff is not a valid value for the register and writing this causes
problems such as e.g. a flickering backlight.

This commit adds a prepare method to the dev_pm_ops and makes it return 0
on Cherry Trail devices forcing a runtime-resume before other device's
suspend methods run. This fixes the reading and writing back of 0xffffffff.

Since we now always runtime-resume the device on suspend, it will be
resumed on resume too and we no longer need to check for the GFX0 _PS0
method having resumed it underneath us, so this commit removes the now no
longer necessary complete dev_pm_op.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>pwm: Enable TI ECAP driver for ARCH_K3</title>
<updated>2018-10-16T11:14:52+00:00</updated>
<author>
<name>Vignesh R</name>
<email>vigneshr@ti.com</email>
</author>
<published>2018-10-16T06:04:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6f37709fb0a61f09ca96348044c5bb13e333e518'/>
<id>urn:sha1:6f37709fb0a61f09ca96348044c5bb13e333e518</id>
<content type='text'>
K3 devices have the same ECAP IP as OMAP SoCs. Enable driver to be built
for K3 devices. Also, drop reference to AM33xx in help text, as IP is
found on multiple TI SoCs.

Signed-off-by: Vignesh R &lt;vigneshr@ti.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>pwm: Send a uevent on the pwmchip device upon channel sysfs (un)export</title>
<updated>2018-10-12T11:51:33+00:00</updated>
<author>
<name>Fabrice Gasnier</name>
<email>fabrice.gasnier@st.com</email>
</author>
<published>2018-10-01T13:23:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=552c02e3e7cfe2744b59de285aaea70021ae95c9'/>
<id>urn:sha1:552c02e3e7cfe2744b59de285aaea70021ae95c9</id>
<content type='text'>
This patch sends a uevent (KOBJ_CHANGE) on the pwmchipN device,
everytime a pwmX channel has been exported/unexported via sysfs. This
allows udev to implement rules on such events, like:

SUBSYSTEM=="pwm*", PROGRAM="/bin/sh -c '\
        chown -R root:gpio /sys/class/pwm &amp;&amp; chmod -R 770 /sys/class/pwm;\
        chown -R root:gpio
/sys/devices/platform/soc/*.pwm/pwm/pwmchip* &amp;&amp; chmod -R 770
/sys/devices/platform/soc/*.pwm/pwm/pwmchip*\
'"

This is a replacement patch for commit 7e5d1fd75c3d ("pwm: Set class for
exported channels in sysfs"), see [1].

basic testing:
$ udevadm monitor --environment &amp;
$ echo 0 &gt; /sys/class/pwm/pwmchip0/export
KERNEL[197.321736] change   /devices/.../pwm/pwmchip0 (pwm)
ACTION=change
DEVPATH=/devices/.../pwm/pwmchip0
EXPORT=pwm0
SEQNUM=2045
SUBSYSTEM=pwm

[1] https://lkml.org/lkml/2018/9/25/713

Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@st.com&gt;
Tested-by: Gottfried Haider &lt;gottfried.haider@gmail.com&gt;
Tested-by: Michal Vokáč &lt;michal.vokac@ysoft.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>Revert "pwm: Set class for exported channels in sysfs"</title>
<updated>2018-10-12T11:51:11+00:00</updated>
<author>
<name>Fabrice Gasnier</name>
<email>fabrice.gasnier@st.com</email>
</author>
<published>2018-10-01T13:23:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c289d6625237aa785b484b4e94c23b3b91ea7e60'/>
<id>urn:sha1:c289d6625237aa785b484b4e94c23b3b91ea7e60</id>
<content type='text'>
This reverts commit 7e5d1fd75c3dde9fc10c4472b9368089d1b81d00 ("pwm: Set
class for exported channels in sysfs") as it causes regression with
multiple pwm chip[1], when exporting a pwm channel (echo X &gt; export):

- ABI (Documentation/ABI/testing/sysfs-class-pwm) states pwmX should be
  created in /sys/class/pwm/pwmchipN/pwmX
- Reverted patch causes new entry to be also created directly in
  /sys/class/pwm/pwmX
- 1st time, exporting pwmX will create an entry in /sys/class/pwm/pwmX
- class attributes are added under pwmX folder, such as export, unexport
  npwm, symlinks. This is wrong as it belongs to pwmchipN. It may cause
  bad behavior and report wrong values.
- when another export happens on another pwmchip, it can't be created
  (e.g. -EEXIST). This is causing the issue with multiple pwmchip.

Example on stm32 (stm32429i-eval) platform:
$ ls /sys/class/pwm
pwmchip0 pwmchip4

$ cd /sys/class/pwm/pwmchip0/
$ echo 0 &gt; export
$ ls /sys/class/pwm
pwm0 pwmchip0 pwmchip4

$ cd /sys/class/pwm/pwmchip4/
$ echo 0 &gt; export
sysfs: cannot create duplicate filename '/class/pwm/pwm0'
...Exception stack follows...

This is also seen on other platform [2]

[1] https://lkml.org/lkml/2018/9/25/713
[2] https://lkml.org/lkml/2018/9/25/447

Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@st.com&gt;
Tested-by: Gottfried Haider &lt;gottfried.haider@gmail.com&gt;
Tested-by: Michal Vokáč &lt;michal.vokac@ysoft.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>pwm: Use SPDX identifier for Renesas drivers</title>
<updated>2018-10-12T11:35:45+00:00</updated>
<author>
<name>Wolfram Sang</name>
<email>wsa+renesas@sang-engineering.com</email>
</author>
<published>2018-08-21T22:02:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e4ab5172ea6be4d3a95411d7a7867f3c2be12754'/>
<id>urn:sha1:e4ab5172ea6be4d3a95411d7a7867f3c2be12754</id>
<content type='text'>
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Reviewed-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>pwm: lpss: Add get_state callback</title>
<updated>2018-10-12T10:33:02+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-10-12T10:12:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=280fec4c3ad6701567d7d840506b9b1463a48b71'/>
<id>urn:sha1:280fec4c3ad6701567d7d840506b9b1463a48b71</id>
<content type='text'>
Add a get_state callback so that the initial state correctly reflects
the actual hardware state.

Cc: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>pwm: lpss: Release runtime-pm reference from the driver's remove callback</title>
<updated>2018-10-12T10:32:12+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-10-12T10:12:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=42885551cedb45961879d2fc3dc3c4dc545cc23e'/>
<id>urn:sha1:42885551cedb45961879d2fc3dc3c4dc545cc23e</id>
<content type='text'>
For each pwm output which gets enabled through pwm_lpss_apply(), we do a
pm_runtime_get_sync().

This commit adds pm_runtime_put() calls to pwm_lpss_remove() to balance
these when the driver gets removed with some of the outputs still enabled.

Fixes: f080be27d7d9 ("pwm: lpss: Add support for runtime PM")
Acked-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>pwm: lpss: Check PWM powerstate after resume on Cherry Trail devices</title>
<updated>2018-10-12T10:31:58+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-10-12T10:12:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a425ecd19a2c0e19a501323216ecf987de07841'/>
<id>urn:sha1:6a425ecd19a2c0e19a501323216ecf987de07841</id>
<content type='text'>
The _PS0 method for the integrated graphics on some Cherry Trail devices
(observed on a HP Pavilion X2 10-p0XX) turns on the PWM chip (puts it in
D0), causing an inconsistency between the state the pm-core thinks it is
in (left runtime suspended as it was before the suspend/resume) and the
state it actually is in.

Interestingly enough this is done on a device where the pwm controller is
not used for the backlight at all, since it uses an eDP panel. On devices
where the PWM is used this is not a problem since we will resume it
ourselves anyways.

This inconsistency causes us to never suspend the pwm controller again,
which causes the device to not be able to reach S0ix states when suspended.

This commit adds a resume-complete handler, which when we think the device
is still run-time suspended checks the actual power-state and if necessary
updates the rpm-core's internal state.

This fixes the Pavilion X2 10-p0XX not reaching S0ix states when suspended.

Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
<entry>
<title>pwm: lpss: Move struct pwm_lpss_chip definition to the header file</title>
<updated>2018-10-12T10:31:01+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-10-12T10:12:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9dc419b6c7e4bb67c0966758c1e4c9a9c9a4309d'/>
<id>urn:sha1:9dc419b6c7e4bb67c0966758c1e4c9a9c9a4309d</id>
<content type='text'>
Move struct pwm_lpss_chip definition from pwm-lpss.c to pwm-lpss.h,
so that the pci/platform drivers can access the info member
(struct pwm_lpss_boardinfo *).

This is a preparation patch for adding platform specific quirks, which
the drivers need access to, to pwm_lpss_boardinfo.

Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
</content>
</entry>
</feed>
