05 Sep, 2016

1 commit

  • 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
    Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
    Signed-off-by: Thierry Reding

    David Hsu
     

25 Jul, 2016

1 commit


10 Jun, 2016

2 commits

  • 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
    [thierry.reding@gmail.com: make capture data unsigned int for symmetry]
    Signed-off-by: Thierry Reding

    Lee Jones
     
  • 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: 5ec803edcb70 ("pwm: Add core infrastructure to allow atomic updates")
    Signed-off-by: Brian Norris
    Acked-by: Boris Brezillon
    Signed-off-by: Thierry Reding

    Brian Norris
     

17 May, 2016

11 commits

  • Thierry Reding
     
  • Thierry Reding
     
  • 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
    Signed-off-by: Boris Brezillon
    [thierry.reding@gmail.com: use more spaces in debugfs output]
    Signed-off-by: Thierry Reding

    Heiko Stübner
     
  • Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls
    by pwm_get/apply_state().

    Signed-off-by: Boris Brezillon
    Signed-off-by: Thierry Reding

    Boris Brezillon
     
  • 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
    [thierry.reding@gmail.com: fix a couple of typos]
    Signed-off-by: Thierry Reding

    Boris Brezillon
     
  • 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
    Signed-off-by: Thierry Reding

    Boris Brezillon
     
  • 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
    Signed-off-by: Thierry Reding

    Boris Brezillon
     
  • 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
    Signed-off-by: Thierry Reding

    Boris Brezillon
     
  • 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
    Signed-off-by: Thierry Reding

    Boris Brezillon
     
  • 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
    Signed-off-by: Thierry Reding

    Boris BREZILLON
     
  • 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 e39c0df1be5a ("pwm: Introduce the pwm_args concept").

    Signed-off-by: Boris Brezillon
    Fixes: e39c0df1be5a ("pwm: Introduce the pwm_args concept")
    Signed-off-by: Thierry Reding

    Boris Brezillon
     

03 May, 2016

3 commits

  • kcalloc() should be preferred for allocations of arrays over kzalloc()
    with multiplication.

    Signed-off-by: Thierry Reding

    Thierry Reding
     
  • 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
     
  • 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
    [thierry.reding@gmail.com: reword kerneldoc comments]
    Signed-off-by: Thierry Reding

    Boris Brezillon
     

21 Jan, 2016

1 commit

  • Commit d1cd21427747 ("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
     

10 Nov, 2015

2 commits

  • 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
     
  • 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
    Reviewed-by: Dmitry Torokhov
    Signed-off-by: Jonathan Richardson
    [thierry.reding@gmail.com: add missing kerneldoc for the lock]
    Signed-off-by: Thierry Reding

    Jonathan Richardson
     

17 Aug, 2015

2 commits


20 Jul, 2015

1 commit

  • 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
    Signed-off-by: Thierry Reding

    Boris Brezillon
     

12 Jun, 2015

1 commit

  • 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
    Signed-off-by: Jonathan Richardson
    [thierry.reding@gmail.com: export pwmchip_add_with_polarity()]
    Signed-off-by: Thierry Reding

    Tim Kryger
     

06 May, 2015

1 commit


23 Apr, 2015

1 commit

  • 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
    Cc: Linus Walleij
    Cc: Alexandre Courbot
    Cc: Thierry Reding
    Signed-off-by: Shobhit Kumar
    Signed-off-by: Thierry Reding

    Shobhit Kumar
     

03 Feb, 2015

1 commit


29 Aug, 2014

1 commit

  • 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: d717ea73e36dd565 ("pwm: Fix period and polarity in pwm_get() for non-perfect matches")
    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Thierry Reding

    Geert Uytterhoeven
     

25 Aug, 2014

1 commit

  • 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
    Signed-off-by: Thierry Reding

    Xiubo Li
     

18 Aug, 2014

1 commit

  • 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: 3796ce1d4d4b ("pwm: add period and polarity to struct pwm_lookup")
    Signed-off-by: Geert Uytterhoeven
    Cc: stable@vger.kernel.org
    Signed-off-by: Thierry Reding

    Geert Uytterhoeven
     

21 May, 2014

1 commit


20 Dec, 2013

1 commit


03 Sep, 2013

1 commit


21 Jun, 2013

1 commit

  • Add a simple sysfs interface to the generic PWM framework.

    /sys/class/pwm/
    `-- pwmchipN/ for each PWM chip
    |-- export (w/o) ask the kernel to export a PWM channel
    |-- npwm (r/o) number of PWM channels in this PWM chip
    |-- pwmX/ for each exported PWM channel
    | |-- duty_cycle (r/w) duty cycle (in nanoseconds)
    | |-- enable (r/w) enable/disable PWM
    | |-- period (r/w) period (in nanoseconds)
    | `-- polarity (r/w) polarity of PWM (normal/inversed)
    `-- unexport (w/o) return a PWM channel to the kernel

    Based on work by Lars Poeschel.

    Signed-off-by: H Hartley Sweeten
    Cc: Thierry Reding
    Cc: Lars Poeschel
    Cc: Ryan Mallon
    Cc: Rob Landley
    Signed-off-by: Thierry Reding

    H Hartley Sweeten
     

10 Jun, 2013

1 commit


27 Feb, 2013

1 commit

  • Pull PWM changes from Thierry Reding:
    "A new driver has been added to support the PWM mode of the timer
    counter blocks found on Atmel AT91 SoCs. The VT8500 driver now
    supports changing the PWM signal polarity and the TI drivers (EHRPWM
    and ECAP) gained suspend and resume functionality.

    User drivers can now query the core for whether access to a PWM device
    will sleep (if the PWM chip is on a slow bus such as I2C or SPI).

    The pwm-backlight driver now handles the backlight BL_CORE_FBBLANK
    state in addition to the FB layer's blanking states.

    To round things off, a few fixes and cleanups are also included"

    * tag 'for-3.9-rc1' of git://gitorious.org/linux-pwm/linux-pwm:
    pwm: twl: Use to_twl() instead of container_of()
    pwm: tegra: assume CONFIG_OF
    pwm_backlight: Validate dft_brightness in main probe function
    pwm: Export pwm_{set,get}_chip_data()
    pwm: Make Kconfig entries more consistent
    pwm: Add can_sleep property to drivers
    pwm: Add pwm_can_sleep() as exported API to users
    pwm-backlight: handle BL_CORE_FBBLANK state
    pwm: pwm-tiecap: Low power sleep support
    pwm: pwm-tiehrpwm: Low power sleep support
    pwm: pwm-tiehrpwm: Update the clock handling of pwm-tiehrpwm driver
    pwm: vt8500: Add polarity support
    pwm: vt8500: Register write busy test performed incorrectly
    pwm: atmel: add Timer Counter Block PWM driver

    Linus Torvalds
     

02 Feb, 2013

2 commits


30 Jan, 2013

1 commit