1
0
Fork 0
Commit Graph

73 Commits (redonkable)

Author SHA1 Message Date
Thierry Reding 40a6b9a009 Revert "pwm: Let pwm_get_state() return the last implemented state"
It turns out that commit 01ccf903ed ("pwm: Let pwm_get_state() return
the last implemented state") causes backlight failures on a number of
boards. The reason is that some of the drivers do not write the full
state through to the hardware registers, which means that ->get_state()
subsequently does not return the correct state. Consumers which rely on
pwm_get_state() returning the current state will therefore get confused
and subsequently try to program a bad state.

Before this change can be made, existing drivers need to be more
carefully audited and fixed to behave as the framework expects. Until
then, keep the original behaviour of returning the software state that
was applied rather than reading the state back from hardware.

Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Michal Vokáč <michal.vokac@ysoft.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-10-21 16:48:52 +02:00
Uwe Kleine-König 71523d1812 pwm: Ensure pwm_apply_state() doesn't modify the state argument
It is surprising for a PWM consumer when the variable holding the
requested state is modified by pwm_apply_state(). Consider for example a
driver doing:

        #define PERIOD 5000000
        #define DUTY_LITTLE 10
        ...
        struct pwm_state state = {
                .period = PERIOD,
                .duty_cycle = DUTY_LITTLE,
                .polarity = PWM_POLARITY_NORMAL,
                .enabled = true,
        };

        pwm_apply_state(mypwm, &state);
        ...
        state.duty_cycle = PERIOD / 2;
        pwm_apply_state(mypwm, &state);

For sure the second call to pwm_apply_state() should still have
state.period = PERIOD and not something the hardware driver chose for a
reason that doesn't necessarily apply to the second call.

So declare the state argument as a pointer to a const type and adapt all
drivers' .apply callbacks.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21 03:25:10 +02:00
Uwe Kleine-König 01ccf903ed pwm: Let pwm_get_state() return the last implemented state
When pwm_apply_state() is called the lowlevel driver usually has to
apply some rounding because the hardware doesn't support nanosecond
resolution. So let pwm_get_state() return the actually implemented state
instead of the last applied one if possible.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21 01:48:54 +02:00
Uwe Kleine-König fc3c5512e3 pwm: Introduce local struct pwm_chip in pwm_apply_state()
pwm->chip is dereferenced several times in the pwm_apply_state()
function. Introducing a local variable for it helps keeping some lines a
bit shorter.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-09-21 01:48:54 +02:00
Hans de Goede 6cf9481b44 pwm: Fallback to the static lookup-list when acpi_pwm_get fails
Commit 4a6ef8e37c ("pwm: Add support referencing PWMs from ACPI")
made pwm_get unconditionally return the acpi_pwm_get return value if
the device passed to pwm_get has an ACPI fwnode.

But even if the passed in device has an ACPI fwnode, it does not
necessarily have the necessary ACPI package defining its pwm bindings,
especially since the binding / API of this ACPI package has only been
introduced very recently.

Up until now X86/ACPI devices which use a separate pwm controller for
controlling their LCD screen's backlight brightness have been relying
on the static lookup-list to get their pwm.

pwm_get unconditionally returning the acpi_pwm_get return value breaks
this, breaking backlight control on these devices.

This commit fixes this by making pwm_get fall back to the static
lookup-list if acpi_pwm_get returns -ENOENT.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=96571
Reported-by: youling257@gmail.com
Fixes: 4a6ef8e37c ("pwm: Add support referencing PWMs from ACPI")
Cc: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-08-08 13:17:38 +02:00
Linus Torvalds 6e2bbb688a pwm: Changes for v5.3-rc1
This set of changes contains a new driver for SiFive SoCs as well as
 enhancements to the core (device links are used to track dependencies
 between PWM providers and consumers, support for PWM controllers via
 ACPI, sysfs will now suspend/resume PWMs that it has claimed) and
 various existing drivers.
 -----BEGIN PGP SIGNATURE-----
 
 iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAl0V/lAZHHRoaWVycnku
 cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zoS+uD/0cJqcVhX1c2S/pHg1k4QFh
 wREnEbxMqWghcsSZcO0gk0hoRyxMNBM3iOldaKc3b5LVtEJOv/R7W6RB+FMcvPKA
 AtW/ydyfRZiqL9bIXs0hhaW4Fo0WCq6gZksDU5cOoq4KMHfkEp7D7U158ItsEtga
 ufDigs8fv/Z6c5DaEfoJ10I+VCy/We2YnCdIVZuL/MElFHlUupzRpGZv6uMRQ4WI
 z2/SEtHURoW103a3UrEmjqv0GeoHPrHwEP9kZTUuakyMxPmUtrSUJRybi79Cf27B
 jLYql8bXSkTsV6rUBtTRNtqQjD3hdjcFYaEdOle8n52/pYFohycmVvB/3xvr9tDC
 Wildg4Rniv4lcteB1hqB0M5km/szXGjPx5wozvmctwOia5sogG+8DWGp0fZO8Gsp
 vaF+GbTrM4LV1AzGJW7icTRFQG7VFUcZAglNW4o82hcXN1j9GpQ/qSOY3vgBigx+
 vyWrbCHBH2zjJNh1sSl68zi5q90T9IlXFfgR61kujbHYws+KrO3BJE2SW7qsLhsf
 HJnMBBxpoxvusBS/kbsWsDCnoGi4UsCeKUbmbfY1OjpCNlpp+cHSk6b4134Fmi66
 D8B+a4C1I/CNhcV72P+hAdrva4UXB6oJi4hZDE2/tEioXQB2wJO4AwWzjpifqzBY
 nGxZVPV7TuXj2KwCXDQnvw==
 =nseo
 -----END PGP SIGNATURE-----

Merge tag 'pwm/for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

Pull pwm updates from Thierry Reding:
 "This set of changes contains a new driver for SiFive SoCs as well as
  enhancements to the core (device links are used to track dependencies
  between PWM providers and consumers, support for PWM controllers via
  ACPI, sysfs will now suspend/resume PWMs that it has claimed) and
  various existing drivers"

* tag 'pwm/for-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (37 commits)
  pwm: fsl-ftm: Make sure to unlock mutex on failure
  pwm: fsl-ftm: Use write protection for prescaler & polarity
  pwm: fsl-ftm: More relaxed permissions for updating period
  pwm: atmel-hlcdc: Add compatible for SAM9X60 HLCDC's PWM
  pwm: bcm2835: Improve precision of PWM
  leds: pwm: Support ACPI via firmware-node framework
  pwm: Add support referencing PWMs from ACPI
  pwm: rcar: Remove suspend/resume support
  pwm: sysfs: Add suspend/resume support
  pwm: Add power management descriptions
  pwm: meson: Add documentation to the driver
  pwm: meson: Add support PWM_POLARITY_INVERSED when disabling
  pwm: meson: Don't cache struct pwm_state internally
  pwm: meson: Read the full hardware state in meson_pwm_get_state()
  pwm: meson: Simplify the calculation of the pre-divider and count
  pwm: meson: Move pwm_set_chip_data() to meson_pwm_request()
  pwm: meson: Add the per-channel register offsets and bits in a struct
  pwm: meson: Add the meson_pwm_channel data to struct meson_pwm
  pwm: meson: Pass struct pwm_device to meson_pwm_calc()
  pwm: meson: Don't duplicate the polarity internally
  ...
2019-07-09 08:57:45 -07:00
Nikolaus Voss 4a6ef8e37c pwm: Add support referencing PWMs from ACPI
In analogy to referencing a GPIO using the "gpios" property from ACPI,
support referencing a PWM using the "pwms" property.

ACPI entries must look like
 Package () {"pwms", Package ()
     { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}

In contrast to the DT implementation, only _one_ PWM entry in the "pwms"
property is supported. As a consequence "pwm-names"-property and
con_id lookup aren't supported.

Support for ACPI is added via the firmware-node framework which is an
abstraction layer on top of ACPI/DT. To keep this patch clean, DT and
ACPI paths are kept separate. The firmware-node framework could be used
to unify both paths in a future patch.

To support leds-pwm driver, an additional method devm_fwnode_pwm_get()
which supports both ACPI and DT configuration is exported.

Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
[thierry.reding@gmail.com: fix build failures for !ACPI]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-26 11:39:11 +02:00
Fabrice Gasnier b2c200e3f2 pwm: Add consumer device link
Add a device link between the PWM consumer and the PWM provider. This
enforces the PWM user to get suspended before the PWM provider. It
allows proper synchronization of suspend/resume sequences: the PWM user
is responsible for properly stopping PWM, before the provider gets
suspended: see [1]. Add the device link in:
- of_pwm_get()
- pwm_get()
- devm_*pwm_get() variants
as it requires a reference to the device for the PWM consumer.

[1] https://lkml.org/lkml/2019/2/5/770

Suggested-by: Thierry Reding <thierry.reding@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-06-25 14:51:43 +02:00
Thomas Gleixner c82ee6d3be treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 18
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 or at your option any
  later version this program is distributed in the hope that it will
  be useful but without any warranty without even the implied warranty
  of merchantability or fitness for a particular purpose see the gnu
  general public license for more details you should have received a
  copy of the gnu general public license along with this program see
  the file copying if not write to the free software foundation 675
  mass ave cambridge ma 02139 usa

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 52 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jilayne Lovejoy <opensource@jilayne.com>
Reviewed-by: Steve Winslow <swinslow@gmail.com>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190519154042.342335923@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-21 11:28:46 +02:00
Uwe Kleine-König e926b12c61 pwm: Clear chip_data in pwm_put()
After a PWM is disposed by its user the per chip data becomes invalid.
Clear the data in common code instead of the device drivers to get
consistent behaviour. Before this patch only three of nine drivers
cleaned up here.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-05-09 17:09:54 +02:00
Phong Hoang 347ab94803 pwm: Fix deadlock warning when removing PWM device
This patch fixes deadlock warning if removing PWM device
when CONFIG_PROVE_LOCKING is enabled.

This issue can be reproceduced by the following steps on
the R-Car H3 Salvator-X board if the backlight is disabled:

 # cd /sys/class/pwm/pwmchip0
 # echo 0 > export
 # ls
 device  export  npwm  power  pwm0  subsystem  uevent  unexport
 # cd device/driver
 # ls
 bind  e6e31000.pwm  uevent  unbind
 # echo e6e31000.pwm > unbind

[   87.659974] ======================================================
[   87.666149] WARNING: possible circular locking dependency detected
[   87.672327] 5.0.0 #7 Not tainted
[   87.675549] ------------------------------------------------------
[   87.681723] bash/2986 is trying to acquire lock:
[   87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
[   87.694528]
[   87.694528] but task is already holding lock:
[   87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
[   87.707405]
[   87.707405] which lock already depends on the new lock.
[   87.707405]
[   87.715574]
[   87.715574] the existing dependency chain (in reverse order) is:
[   87.723048]
[   87.723048] -> #1 (pwm_lock){+.+.}:
[   87.728017]        __mutex_lock+0x70/0x7e4
[   87.732108]        mutex_lock_nested+0x1c/0x24
[   87.736547]        pwm_request_from_chip.part.6+0x34/0x74
[   87.741940]        pwm_request_from_chip+0x20/0x40
[   87.746725]        export_store+0x6c/0x1f4
[   87.750820]        dev_attr_store+0x18/0x28
[   87.754998]        sysfs_kf_write+0x54/0x64
[   87.759175]        kernfs_fop_write+0xe4/0x1e8
[   87.763615]        __vfs_write+0x40/0x184
[   87.767619]        vfs_write+0xa8/0x19c
[   87.771448]        ksys_write+0x58/0xbc
[   87.775278]        __arm64_sys_write+0x18/0x20
[   87.779721]        el0_svc_common+0xd0/0x124
[   87.783986]        el0_svc_compat_handler+0x1c/0x24
[   87.788858]        el0_svc_compat+0x8/0x18
[   87.792947]
[   87.792947] -> #0 (kn->count#58){++++}:
[   87.798260]        lock_acquire+0xc4/0x22c
[   87.802353]        __kernfs_remove+0x258/0x2c4
[   87.806790]        kernfs_remove_by_name_ns+0x50/0xa0
[   87.811836]        remove_files.isra.1+0x38/0x78
[   87.816447]        sysfs_remove_group+0x48/0x98
[   87.820971]        sysfs_remove_groups+0x34/0x4c
[   87.825583]        device_remove_attrs+0x6c/0x7c
[   87.830197]        device_del+0x11c/0x33c
[   87.834201]        device_unregister+0x14/0x2c
[   87.838638]        pwmchip_sysfs_unexport+0x40/0x4c
[   87.843509]        pwmchip_remove+0xf4/0x13c
[   87.847773]        rcar_pwm_remove+0x28/0x34
[   87.852039]        platform_drv_remove+0x24/0x64
[   87.856651]        device_release_driver_internal+0x18c/0x21c
[   87.862391]        device_release_driver+0x14/0x1c
[   87.867175]        unbind_store+0xe0/0x124
[   87.871265]        drv_attr_store+0x20/0x30
[   87.875442]        sysfs_kf_write+0x54/0x64
[   87.879618]        kernfs_fop_write+0xe4/0x1e8
[   87.884055]        __vfs_write+0x40/0x184
[   87.888057]        vfs_write+0xa8/0x19c
[   87.891887]        ksys_write+0x58/0xbc
[   87.895716]        __arm64_sys_write+0x18/0x20
[   87.900154]        el0_svc_common+0xd0/0x124
[   87.904417]        el0_svc_compat_handler+0x1c/0x24
[   87.909289]        el0_svc_compat+0x8/0x18
[   87.913378]
[   87.913378] other info that might help us debug this:
[   87.913378]
[   87.921374]  Possible unsafe locking scenario:
[   87.921374]
[   87.927286]        CPU0                    CPU1
[   87.931808]        ----                    ----
[   87.936331]   lock(pwm_lock);
[   87.939293]                                lock(kn->count#58);
[   87.945120]                                lock(pwm_lock);
[   87.950599]   lock(kn->count#58);
[   87.953908]
[   87.953908]  *** DEADLOCK ***
[   87.953908]
[   87.959821] 4 locks held by bash/2986:
[   87.963563]  #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
[   87.971044]  #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
[   87.978872]  #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
[   87.988001]  #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
[   87.995481]
[   87.995481] stack backtrace:
[   87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
[   88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
[   88.012791] Call trace:
[   88.015235]  dump_backtrace+0x0/0x190
[   88.018891]  show_stack+0x14/0x1c
[   88.022204]  dump_stack+0xb0/0xec
[   88.025514]  print_circular_bug.isra.32+0x1d0/0x2e0
[   88.030385]  __lock_acquire+0x1318/0x1864
[   88.034388]  lock_acquire+0xc4/0x22c
[   88.037958]  __kernfs_remove+0x258/0x2c4
[   88.041874]  kernfs_remove_by_name_ns+0x50/0xa0
[   88.046398]  remove_files.isra.1+0x38/0x78
[   88.050487]  sysfs_remove_group+0x48/0x98
[   88.054490]  sysfs_remove_groups+0x34/0x4c
[   88.058580]  device_remove_attrs+0x6c/0x7c
[   88.062671]  device_del+0x11c/0x33c
[   88.066154]  device_unregister+0x14/0x2c
[   88.070070]  pwmchip_sysfs_unexport+0x40/0x4c
[   88.074421]  pwmchip_remove+0xf4/0x13c
[   88.078163]  rcar_pwm_remove+0x28/0x34
[   88.081906]  platform_drv_remove+0x24/0x64
[   88.085996]  device_release_driver_internal+0x18c/0x21c
[   88.091215]  device_release_driver+0x14/0x1c
[   88.095478]  unbind_store+0xe0/0x124
[   88.099048]  drv_attr_store+0x20/0x30
[   88.102704]  sysfs_kf_write+0x54/0x64
[   88.106359]  kernfs_fop_write+0xe4/0x1e8
[   88.110275]  __vfs_write+0x40/0x184
[   88.113757]  vfs_write+0xa8/0x19c
[   88.117065]  ksys_write+0x58/0xbc
[   88.120374]  __arm64_sys_write+0x18/0x20
[   88.124291]  el0_svc_common+0xd0/0x124
[   88.128034]  el0_svc_compat_handler+0x1c/0x24
[   88.132384]  el0_svc_compat+0x8/0x18

The sysfs unexport in pwmchip_remove() is completely asymmetric
to what we do in pwmchip_add_with_polarity() and commit 0733424c9b
("pwm: Unexport children before chip removal") is a strong indication
that this was wrong to begin with. We should just move
pwmchip_sysfs_unexport() where it belongs, which is right after
pwmchip_sysfs_unexport_children(). In that case, we do not need
separate functions anymore either.

We also really want to remove sysfs irrespective of whether or not
the chip will be removed as a result of pwmchip_remove(). We can only
assume that the driver will be gone after that, so we shouldn't leave
any dangling sysfs files around.

This warning disappears if we move pwmchip_sysfs_unexport() to
the top of pwmchip_remove(), pwmchip_sysfs_unexport_children().
That way it is also outside of the pwm_lock section, which indeed
doesn't seem to be needed.

Moving the pwmchip_sysfs_export() call outside of that section also
seems fine and it'd be perfectly symmetric with pwmchip_remove() again.

So, this patch fixes them.

Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
[shimoda: revise the commit log and code]
Fixes: 76abbdde2d ("pwm: Add sysfs interface")
Fixes: 0733424c9b ("pwm: Unexport children before chip removal")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Hoan Nguyen An <na-hoan@jinso.co.jp>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-03-20 12:21:31 +01:00
Uwe Kleine-König cc2d224777 pwm: Drop per-chip dbg_show callback
This callback was introduced in commit 62099abf67 ("pwm: Add debugfs
interface") in 2012 and up to now there is not a single user. So drop
this unused code.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: remove kerneldoc for ->dbg_show()]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-01-10 09:34:12 +01:00
Uwe Kleine-König 309b32fb97 pwm: Don't use memcmp() to compare state variables
Given that struct pwm_state is sparse (at least on some platforms),
variables of this type might represent the same state because all fields
are pairwise identical but still memcmp() returns a difference because
some of the unused bits are different.

To prevent surprises compare member by member instead of the whole
occupied memory.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-01-10 09:32:23 +01:00
Jerome Brunet 93c292ef3c pwm: Silently error out on EPROBE_DEFER
In of_pwm_get(), if we fail to get the PWM chip due to probe deferal, we
shouldn't print an error message. Just be silent in this case.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2017-07-06 08:29:16 +02:00
Hans de Goede b526a31426 pwm: Try to load modules during pwm_get()
Add a module name string to the pwm_lookup struct and if specified try
to load the module using request_module() if pwmchip_find_by_name() is
unable to find the PWM chip.

This is a last resort to work around drivers that can't - and can't be
made to - deal with deferred probe.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[thierry.reding@gmail.com: rename new macro, reword commit message]
[thierry.reding@gmail.com: add comment explaining use-case]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2017-01-30 09:36:42 +01:00
Hans de Goede 69efb3439c pwm: Don't hold pwm_lookup_lock longer than necessary
There is no need to hold pwm_lookup_lock after we're done with looping
over pwm_lookup_list, so release it earlier.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2017-01-30 09:19:26 +01:00
Lothar Wassmann 42883cbc08 pwm: Make the PWM_POLARITY flag in DTB optional
Change the PWM chip driver registration so that a chip driver that
supports polarity inversion can still be used with DTBs that don't
provide the polarity flag as part of the specifier.

This is done to provide polarity inversion support for the pwm-imx
driver without having to modify all existing DTS files.

Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Suggested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2017-01-30 09:13:34 +01:00
Lothar Wassmann f2dafc0950 pwm: Print error messages with pr_err() instead of pr_debug()
Make the messages that are printed in case of fatal errors actually
visible to the user without having to recompile the driver with
debugging enabled.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2017-01-30 09:13:30 +01:00
Thierry Reding fe2858c8c6 pwm: Remove pwm_can_sleep()
The last user of this function has been removed, so it is no longer
needed.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2017-01-04 09:39:52 +01:00
David Hsu 0733424c9b pwm: Unexport children before chip removal
Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.

Signed-off-by: David Hsu <davidhsu@google.com>
Fixes: 76abbdde2d ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-09-05 16:45:39 +02:00
Thierry Reding bd2686122d Merge branch 'for-4.8/capture' into for-next 2016-07-25 16:23:39 +02:00
Lee Jones 3a3d1a4e32 pwm: Add PWM capture support
Supply a PWM capture callback op in order to pass back information
obtained by running analysis on a PWM signal. This would normally (at
least during testing) be called from the sysfs routines with a view to
printing out PWM capture data which has been encoded into a string.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
[thierry.reding@gmail.com: make capture data unsigned int for symmetry]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-06-10 16:01:35 +02:00
Brian Norris ef2bf4997f pwm: Improve args checking in pwm_apply_state()
It seems like in the process of refactoring pwm_config() to utilize the
newly-introduced pwm_apply_state() API, some args/bounds checking was
dropped.

In particular, I noted that we are now allowing invalid period
selections, e.g.:

  # echo 1 > /sys/class/pwm/pwmchip0/export
  # cat /sys/class/pwm/pwmchip0/pwm1/period
  100
  # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
  [... driver may or may not reject the value, or trigger some logic bug ...]

It's better to see:

  # echo 1 > /sys/class/pwm/pwmchip0/export
  # cat /sys/class/pwm/pwmchip0/pwm1/period
  100
  # echo 101 > /sys/class/pwm/pwmchip0/pwm1/duty_cycle
  -bash: echo: write error: Invalid argument

This patch reintroduces some bounds checks in both pwm_config() (for its
signed parameters; we don't want to convert negative values into large
unsigned values) and in pwm_apply_state() (which fix the above described
behavior, as well as other potential API misuses).

Fixes: 5ec803edcb ("pwm: Add core infrastructure to allow atomic updates")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-06-10 14:21:00 +02:00
Thierry Reding 18c588786c Merge branch 'for-4.7/pwm-atomic' into for-next 2016-05-17 14:57:58 +02:00
Thierry Reding bf5dd9abcb Merge branch 'for-4.7/pwm-args' into for-next 2016-05-17 14:57:47 +02:00
Heiko Stübner 23e3523f5d pwm: Add information about polarity, duty cycle and period to debugfs
The PWM states make it possible to also output the polarity, duty cycle
and period information in the debugfs summary output. This simplifies
gathering information about PWMs without needing to walk through the
sysfs attributes of every PWM.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: use more spaces in debugfs output]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:05 +02:00
Boris Brezillon 39100ceea7 pwm: Switch to the atomic API
Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls
by pwm_get/apply_state().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:04 +02:00
Boris Brezillon 5ec803edcb pwm: Add core infrastructure to allow atomic updates
Add an ->apply() method to the pwm_ops struct to allow PWM drivers to
implement atomic updates. This method is preferred over the ->enable(),
->disable() and ->config() methods if available.

Add the pwm_apply_state() function to the PWM user API.

Note that the pwm_apply_state() does not guarantee the atomicity of the
update operation, it all depends on the availability and implementation
of the ->apply() method.

pwm_enable/disable/set_polarity/config() are now implemented as wrappers
around the pwm_apply_state() function.

pwm_adjust_config() is allowing smooth handover between the bootloader
and the kernel. This function tries to adapt the current PWM state to
the PWM arguments coming from a PWM lookup table or a DT definition
without changing the duty_cycle/period proportion.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: fix a couple of typos]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:03 +02:00
Boris Brezillon 15fa8a43c1 pwm: Add hardware readout infrastructure
Add a ->get_state() function to the pwm_ops struct to let PWM drivers
initialize the PWM state attached to a PWM device.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:03 +02:00
Boris Brezillon 09a7e4a3d9 pwm: Move the enabled/disabled info into pwm_state
Prepare the transition to PWM atomic update by moving the enabled and
disabled state into the pwm_state struct. This way we can easily update
the whole PWM state by copying the new state in the ->state field.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:02 +02:00
Boris Brezillon 43a276b003 pwm: Introduce the pwm_state concept
The PWM state, represented by its period, duty_cycle and polarity is
currently directly stored in the PWM device. Declare a pwm_state
structure embedding those field so that we can later use this struct
to atomically update all the PWM parameters at once.

All pwm_get_xxx() helpers are now implemented as wrappers around
pwm_get_state().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:48:02 +02:00
Boris Brezillon a8c3862551 pwm: Keep PWM state in sync with hardware state
Before the introduction of pwm_args, the core was resetting the PWM
period and polarity states to the reference values (those provided
through the DT, a PWM lookup table or hardcoded in the driver).

Now that all PWM users are correctly using pwm_args to configure their
PWM device, we can safely remove the pwm_apply_args() call in pwm_get()
and of_pwm_get().

We can also get rid of the pwm_set_period() call in pwm_apply_args(),
because PWM users are now directly using pargs->period instead of
pwm_get_period(). By doing that we avoid messing with the current PWM
period.

The only remaining bit in pwm_apply_args() is the initial polarity
setting, and it should go away when all PWM users have been patched to
use the atomic API (with this API the polarity will be set along with
other PWM arguments when configuring the PWM).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:47:30 +02:00
Boris BREZILLON 459a25afe9 pwm: Get rid of pwm->lock
PWM devices are not protected against concurrent accesses. The lock in
struct pwm_device might let PWM users think it is, but it's actually
only protecting the enabled state.

Removing this lock should be fine as long as all PWM users are aware
that accesses to the PWM device have to be serialized, which seems to be
the case for all of them except the sysfs interface. Patch the sysfs
code by adding a lock to the pwm_export struct and making sure it's
taken for all relevant accesses to the exported PWM device.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:44:59 +02:00
Boris Brezillon fbd45a1298 pwm: Fix pwm_apply_args() call sites
pwm_apply_args() is supposed to initialize a PWM device according to the
arguments provided by the DT or the PWM lookup, but this function was
called inside pwm_device_request(), which in turn was called before the
core had a chance to initialize the pwm->args fields.

Fix that by calling pwm_apply_args directly in pwm_get() and of_pwm_get()
after initializing pwm->args field.

This commit also fixes an invalid pointer dereference introduced by
commit e39c0df1be ("pwm: Introduce the pwm_args concept").

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: e39c0df1be ("pwm: Introduce the pwm_args concept")
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-17 14:41:18 +02:00
Thierry Reding 2907f8abb7 pwm: Use kcalloc() instead of kzalloc()
kcalloc() should be preferred for allocations of arrays over kzalloc()
with multiplication.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-03 13:57:05 +02:00
Thierry Reding 83a98864ff pwm: Add missing newline
checkpatch requires that declarations be separated from code by a blank
line. Add one for readability and to silence the warning.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-03 13:57:03 +02:00
Boris Brezillon e39c0df1be pwm: Introduce the pwm_args concept
Currently the PWM core mixes the current PWM state with the per-platform
reference config (specified through the PWM lookup table, DT definition
or directly hardcoded in PWM drivers).

Create a struct pwm_args to store this reference configuration, so that
PWM users can differentiate between the current and reference
configurations.

Patch all places where pwm->args should be initialized. We keep the
pwm_set_polarity/period() calls until all PWM users are patched to use
pwm_args instead of pwm_get_period/polarity().

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[thierry.reding@gmail.com: reword kerneldoc comments]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-05-03 13:44:37 +02:00
Thierry Reding ff01c944cf pwm: Mark all devices as "might sleep"
Commit d1cd214277 ("pwm: Set enable state properly on failed call to
enable") introduced a mutex that is needed to protect internal state of
PWM devices. Since that mutex is acquired in pwm_set_polarity() and in
pwm_enable() and might potentially block, all PWM devices effectively
become "might sleep".

It's rather pointless to keep the .can_sleep field around, but given
that there are external users let's postpone the removal for the next
release cycle.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2016-01-21 15:04:59 +01:00
Thierry Reding 655a03554c pwm: Return -ENODEV if no PWM lookup match is found
When looking up a PWM using the lookup table, assume that all entries
will have been added already, so failure to find a match means that no
corresponding entry has been registered.

This fixes an issue where -EPROBE_DEFER would be returned if the PWM
lookup table is empty. After this fix, -EPROBE_DEFER is reserved for
situations where no provider has yet registered for a matching entry.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-11-10 13:06:42 +01:00
Jonathan Richardson d1cd214277 pwm: Set enable state properly on failed call to enable
The pwm_enable() function didn't clear the enabled bit if a call to the
driver's ->enable() callback returned an error. The result was that the
state of the PWM core was wrong. Clearing the bit when enable returns
an error ensures the state is properly set.

Tested-by: Jonathan Richardson <jonathar@broadcom.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jonathan Richardson <jonathar@broadcom.com>
[thierry.reding@gmail.com: add missing kerneldoc for the lock]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-11-10 13:06:16 +01:00
Thierry Reding 0488380276 pwm: Clean up kerneldoc
Clean up kerneldoc in preparation for including the PWM documentation in
DocBook.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-08-17 15:40:20 +02:00
Thierry Reding 6bc7064a69 pwm: Remove useless whitespace
Remove useless tabs used for padding in structure definitions as well as
some blank lines.

Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-08-17 15:40:19 +02:00
Boris Brezillon 5c31252c4a pwm: Add the pwm_is_enabled() helper
Some PWM drivers are testing the PWMF_ENABLED flag. Create a helper
function to hide the logic behind enabled test. This will allow us to
smoothly move from the current approach to an atomic PWM update
approach.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-07-20 09:46:06 +02:00
Tim Kryger b6a00fae97 pwm: Add pwmchip_add_with_polarity() API
Add a new function to register a PWM chip with channels that have their
initial polarity as specified by an additional parameter. This benefits
drivers of controllers that by default operate with inversed polarity
by removing the need to modify the polarity during initialization.

Signed-off-by: Tim Kryger <tim.kryger@gmail.com>
Signed-off-by: Jonathan Richardson <jonathar@broadcom.com>
[thierry.reding@gmail.com: export pwmchip_add_with_polarity()]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-06-12 11:36:30 +02:00
Shobhit Kumar efb0de55b6 pwm: Add support to remove registered consumer lookup tables
In case some drivers are unloading, they can remove lookup tables which
they had registered during their load time to avoid redundant entries if
loaded again.

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-05-06 14:19:35 +02:00
Shobhit Kumar c264f1110d pwm: Remove __init initializer for pwm_add_table()
For platforms that don't support DT, some early MFD modules can register
lookup tables. Remove the __init annotation so that this works. This is
similar to gpio_add_lookup_table() which allows late additions.

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-04-23 14:50:52 +02:00
Markus Elfring 8d6cc07385 pwm: Remove unnecessary check before of_node_put()
The of_node_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2015-02-03 12:56:54 +01:00
Geert Uytterhoeven 70145f8713 pwm: Fix uninitialized warnings in pwm_get()
With some versions of gcc (e.g. 4.1.2):

drivers/pwm/core.c: In function ‘pwm_get’:
drivers/pwm/core.c:610: warning: ‘polarity’ may be used uninitialized in this function
drivers/pwm/core.c:609: warning: ‘period’ may be used uninitialized in this function

While these are false positives, we can get rid of them by refactoring
the code to store a pointer to the best match, as suggested before by
Thierry Reding. This does require moving the mutex_unlock() down.

Fixes: d717ea73e3 ("pwm: Fix period and polarity in pwm_get() for non-perfect matches")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2014-08-29 10:18:19 +02:00
Xiubo Li 533acc0e8d pwm: Fix possible ZERO_SIZE_PTR pointer dereferencing error.
Since we cannot make sure the 'chip->npwm' will always be none zero here,
and then if either equal to zero, the kzalloc() will return ZERO_SIZE_PTR,
which equals to ((void *)16).

So this patch fix this with just doing the zero check before calling kzalloc().

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2014-08-25 14:38:12 +02:00
Geert Uytterhoeven d717ea73e3 pwm: Fix period and polarity in pwm_get() for non-perfect matches
If pwm_get() finds a look-up entry with a perfect match (both dev_id and
con_id match), the loop is aborted, and "p" still points to the correct
struct pwm_lookup.

If only an entry with a matching dev_id or con_id is found, the loop
terminates after traversing the whole list, and "p" now points to
arbitrary memory, not part of the pwm_lookup list.
Then pwm_set_period() and pwm_set_polarity() will set random values for
period resp. polarity.

To fix this, save period and polarity when finding a new best match,
just like is done for chip (for the provider) and index.

This fixes the LCD backlight on r8a7740/armadillo-legacy, which was fed
period 0 and polarity -1068821144 instead of 33333 resp. 1.

Fixes: 3796ce1d4d ("pwm: add period and polarity to struct pwm_lookup")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2014-08-18 10:58:43 +02:00