24 Sep, 2020

1 commit


02 Jun, 2020

3 commits

  • The PWM hardware in the JZ4725B works the same as in the JZ4740, but has
    only six channels available.

    Signed-off-by: Paul Cercueil
    Signed-off-by: Thierry Reding

    Paul Cercueil
     
  • The PWM in Ingenic SoCs starts in inactive state until the internal
    timer reaches the duty value, then becomes active until the timer
    reaches the period value. In theory, we should then use (period - duty)
    as the real duty value, as a high duty value would otherwise result in
    the PWM pin being inactive most of the time.

    This is the reason why the duty value was inverted in the driver until
    now, but it still had the problem that it would not start with the
    active part.

    To address this remaining issue, the common trick is to invert the
    duty, and invert the polarity when the PWM is enabled.

    Since the duty was already inverted, and we invert it again, we now
    program the hardware for the requested duty, and simply invert the
    polarity when the PWM is enabled.

    Signed-off-by: Paul Cercueil
    Signed-off-by: Thierry Reding

    Paul Cercueil
     
  • Calculating the hardware value for the duty from the hardware value of
    the period resulted in a precision loss versus calculating it from the
    clock rate directly.

    (Also remove a cast that doesn't really need to be here)

    Fixes: f6b8a5700057 ("pwm: Add Ingenic JZ4740 support")
    Cc:
    Suggested-by: Uwe Kleine-König
    Reviewed-by: Uwe Kleine-König
    Signed-off-by: Paul Cercueil
    Signed-off-by: Thierry Reding

    Paul Cercueil
     

31 Mar, 2020

4 commits

  • The TCU channels 0 and 1 were previously reserved for system tasks, and
    thus unavailable for PWM.

    Signed-off-by: Paul Cercueil
    Tested-by: Mathieu Malaterre
    Tested-by: Artur Rojek
    Signed-off-by: Thierry Reding

    Paul Cercueil
     
  • The TCU registers are shared between a handful of drivers, accessing
    them through the same regmap.

    While this driver is devicetree-compatible, it is never (as of now)
    probed from devicetree, so this change does not introduce a ABI problem
    with current devicetree files.

    Signed-off-by: Paul Cercueil
    Tested-by: Mathieu Malaterre
    Tested-by: Artur Rojek
    Signed-off-by: Thierry Reding

    Paul Cercueil
     
  • The previous algorithm hardcoded details about how the TCU clocks work.
    The new algorithm will use clk_round_rate to find the perfect clock rate
    for the PWM channel.

    This code relies on the fact that clk_round_rate() will always round
    down, which is not a valid assumption given by the clk API, but only
    happens to be true with the clk drivers used for Ingenic SoCs.

    Right now, there is no alternative as the clk API does not have a
    round-down function (and won't have one for a while), but if it ever
    comes to light, a round-down function should be used instead.

    Signed-off-by: Paul Cercueil
    Tested-by: Mathieu Malaterre
    Tested-by: Artur Rojek
    Signed-off-by: Thierry Reding

    Paul Cercueil
     
  • The ingenic-timer "TCU" driver provides us with clocks, that can be
    (un)gated, reparented or reclocked from devicetree, instead of having
    these settings hardcoded in this driver.

    The new code now uses a clk pointer per PWM (instead of a clk per
    pwm-chip before). So the pointer is stored in per-pwm data now.
    The calls to arch-specific timer code is replaced with standard
    clock API calls to start and stop each channel's clock.

    While this driver is devicetree-compatible, it is never (as of now)
    probed from devicetree, so this change does not introduce a ABI problem
    with current devicetree files.

    Signed-off-by: Paul Cercueil
    Tested-by: Mathieu Malaterre
    Tested-by: Artur Rojek
    Signed-off-by: Thierry Reding

    Paul Cercueil
     

21 Sep, 2019

2 commits

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

    Uwe Kleine-König
     
  • The JZ4740 PWM implementation doesn't fulfill the (up to now
    insufficiently documented) requirements of the PWM API. At least
    document them in the driver.

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

    Uwe Kleine-König
     

09 Jul, 2019

1 commit

  • …erry.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
    ...

    Linus Torvalds
     

26 Jun, 2019

1 commit

  • When the PWM mode of TCU2 channels is disabled, their corresponding pin
    does not always return to its initial level. Force this by using a small
    trick: we set duty > period, which is an invalid configuration for the
    hardware, which then correctly resets the pin to the initial level.

    Signed-off-by: Paul Cercueil
    Signed-off-by: Thierry Reding

    Paul Cercueil
     

25 Jun, 2019

2 commits


31 May, 2019

1 commit

  • 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 of the license or at
    your option any later version you should have received a copy of the
    gnu general public license along with this program if not write to
    the free software foundation inc 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 35 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Armijn Hemel
    Reviewed-by: Richard Fontana
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.655028468@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

28 Mar, 2018

3 commits


22 May, 2017

1 commit

  • Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on
    the pins being properly configured before the driver probes.

    One inherent problem of this new approach is that the pinctrl framework
    does not allow us to configure each pin on demand, when the various PWM
    channels are requested or released. For instance, the PWM channels can
    be configured from sysfs, which would require all PWM pins to be configured
    properly beforehand for the PWM function, eventually causing conflicts
    with other platform or board drivers.

    The proper solution here would be to modify the pwm-jz4740 driver to
    handle only one PWM channel, and create an instance of this driver
    for each one of the 8 PWM channels. Then, it could use the pinctrl
    framework to dynamically configure the PWM pin it controls.

    Until this can be done, the only jz4740 board supported upstream
    (Qi lb60) can configure all of its connected PWM pins in PWM function
    mode, since those are not used by other drivers nor by GPIOs on the
    board.

    Signed-off-by: Paul Cercueil
    Acked-by: Thierry Reding
    Signed-off-by: Linus Walleij

    Paul Cercueil
     

20 Oct, 2014

1 commit


12 Dec, 2013

2 commits


29 Nov, 2012

3 commits


06 Oct, 2012

1 commit