Pull pwm updates from Thierry Reding:
 "This adds support for the PWM controller found on Toshiba Visconti
  SoCs and converts a couple of drivers to the atomic API.

  There's also a bunch of cleanups and minor fixes across the board"

* tag 'pwm/for-5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (35 commits)
  pwm: Reword docs about pwm_apply_state()
  pwm: atmel: Improve duty cycle calculation in .apply()
  pwm: atmel: Fix duty cycle calculation in .get_state()
  pwm: visconti: Add Toshiba Visconti SoC PWM support
  dt-bindings: pwm: Add bindings for Toshiba Visconti PWM Controller
  arm64: dts: rockchip: Remove clock-names from PWM nodes
  ARM: dts: rockchip: Remove clock-names from PWM nodes
  dt-bindings: pwm: rockchip: Add more compatible strings
  dt-bindings: pwm: Convert pwm-rockchip.txt to YAML
  pwm: mediatek: Remove unused function
  pwm: pca9685: Improve runtime PM behavior
  pwm: pca9685: Support hardware readout
  pwm: pca9685: Switch to atomic API
  pwm: lpss: Don't modify HW state in .remove callback
  pwm: sti: Free resources only after pwmchip_remove()
  pwm: sti: Don't modify HW state in .remove callback
  pwm: lpc3200: Don't modify HW state in .remove callback
  pwm: lpc18xx-sct: Free resources only after pwmchip_remove()
  pwm: bcm-kona: Don't modify HW state in .remove callback
  pwm: bcm2835: Free resources only after pwmchip_remove()
  ...

Pull MFD updates from Lee Jones:
 "Core Framework:
   - Add support for Software Nodes to MFD Core
   - Remove support for Device Properties from MFD Core
   - Use standard APIs in MFD Core

  New Drivers:
   - Add support for ROHM BD9576MUF and BD9573MUF PMICs
   - Add support for Netronix Embedded Controller, PWM and RTC
   - Add support for Actions Semi ATC260x PMICs and OnKey

  New Device Support:
   - Add support for DG1 PCIe Graphics Card to Intel PMT
   - Add support for ROHM BD71815 PMIC to ROHM BD71828
   - Add support for Tolino Shine 2 HD to Netronix Embedded Controller
   - Add support for AX10 BMC Secure Updates to Intel M10 BMC

  Removed Device Support:
   - Remove Arizona Extcon support from MFD
   - Remove ST-E AB8500 Power Supply code from MFD
   - Remove AB3100 altogether

  New Functionality:
   - Add support for SMBus and I2C modes to Dialog DA9063
   - Switch to using Software Nodes in Intel (various)

  New/converted Device Tree bindings:
   - rohm bd71815-pmic, rohm bd9576-pmic, netronix ntxec, actions
     atc260x, ricoh rn5t618, qcom pm8xxx

- Fix-ups:
   - Fix error handling/path; intel_pmt
   - Simplify code; rohm-bd718x7, ab8500-core, intel-m10-bmc
   - Trivial clean-ups (reordering, spelling); rohm-generic, rn5t618,
     max8997
   - Use correct data-type; db8500-prcmu
   - Remove superfluous code; lp87565, intel_quark_i2c_gpi, lpc_sch, twl
   - Use generic APIs/defines; lm3533-core, intel_quark_i2c_gpio
   - Regmap related fix-ups; intel-m10-bmc, sec-core
   - Reorder resource freeing during remove; intel_quark_i2c_gpio
   - Make table indexing more robust; intel_quark_i2c_gpio
   - Fix reference imbalances; arizona-irq
   - Staticify and (un)constify things; arizona-spi, stmpe, ene-kb3930,
     intel-lpss-acpi, intel-lpss-pci, atc260x-i2c, intel_quark_i2c_gpio

  Bug Fixes:
   - Fix incorrect (register) values; intel-m10-bmc
   - Kconfig related fixes; ABX500_CORE
   - Do not clear the Auto Reload Register; stm32-timers"

* tag 'mfd-next-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (84 commits)
  mfd: intel-m10-bmc: Add support for MAX10 BMC Secure Updates
  Revert "mfd: max8997: Add of_compatible to Extcon and Charger mfd_cell"
  mfd: twl: Remove unused inline function twl4030charger_usb_en()
  dt-bindings: mfd: Convert pm8xxx bindings to yaml
  dt-bindings: mfd: Add compatible for pmk8350 rtc
  i2c: designware: Get rid of legacy platform data
  mfd: intel_quark_i2c_gpio: Convert I²C to use software nodes
  mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000"
  mfd: arizona: Fix rumtime PM imbalance on error
  mfd: max8997: Replace 8998 with 8997
  mfd: core: Use acpi_find_child_device() for child devices lookup
  mfd: intel_quark_i2c_gpio: Don't play dirty trick with const
  mfd: intel_quark_i2c_gpio: Enable MSI interrupt
  mfd: intel_quark_i2c_gpio: Reuse BAR definitions for MFD cell indexing
  mfd: ntxec: Support for EC in Tolino Shine 2 HD
  mfd: stm32-timers: Avoid clearing auto reload register
  mfd: intel_quark_i2c_gpio: Replace I²C speeds with descriptive definitions
  mfd: intel_quark_i2c_gpio: Remove unused struct device member
  mfd: intel_quark_i2c_gpio: Unregister resources in reversed order
  mfd: Kconfig: ABX500_CORE should depend on ARCH_U8500
  ...

In the calculation of the register value determining the duty cycle the
requested period is used instead of the actually implemented period which
results in suboptimal settings.

The following example assumes an input clock of 133333333 Hz on one of
the SoCs with 16 bit period.

When the following state is to be applied:

        .period = 414727681
        .duty_cycle = 652806

the following register values used to be  calculated:

        PRES = 10
        CPRD = 54000
        CDTY = 53916

which yields an actual duty cycle of a bit more than 645120 ns.

The setting

        PRES = 10
        CPRD = 54000
        CDTY = 53915

however yields a duty of 652800 ns which is between the current result
and the requested value and so is a better approximation.

The reason for this error is that for the calculation of CDTY the
requested period was used instead of the actually implemented one.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

The CDTY register contains the number of inactive cycles. .apply() does
this correctly, however .get_state() got this wrong.

Fixes: 651b510a74d4 ("pwm: atmel: Implement .get_state()")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

Add driver for the PWM controller on Toshiba Visconti ARM SoC.

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: fix up a couple of checkpatch warnings]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

Fix the following clang warning:

drivers/pwm/pwm-mediatek.c:110:19: warning: unused function
'pwm_mediatek_readl' [-Wunused-function].

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

The chip does not come out of POR in active state but in sleep state.
To be sure (in case the bootloader woke it up) we force it to sleep in
probe.

If runtime PM is disabled, we instead wake the chip in .probe and put it
to sleep in .remove.

Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

Implement .get_state to read-out the current hardware state.

The hardware readout may return slightly different values than those
that were set in apply due to the limited range of possible prescale and
counter register values.

Also note that although the datasheet mentions 200 Hz as default
frequency when using the internal 25 MHz oscillator, the calculated
period from the default prescaler register setting of 30 is 5079040ns.

Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

The switch to the atomic API goes hand in hand with a few fixes to
previously experienced issues:
- The duty cycle is no longer lost after disable/enable (previously the
  OFF registers were cleared in disable and the user was required to
  call config to restore the duty cycle settings)
- If one sets a period resulting in the same prescale register value,
  the sleep and write to the register is now skipped
- Previously, only the full ON bit was toggled in GPIO mode (and full
  OFF cleared if set to high), which could result in both full OFF and
  full ON not being set and on=0, off=0, which is not allowed according
  to the datasheet
- The OFF registers were reset to 0 in probe, which could lead to the
  forbidden on=0, off=0. Fixed by resetting to POR default (full OFF)

Signed-off-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

A consumer is expected to disable a PWM before calling pwm_put(). And if
they didn't there is hopefully a good reason (or the consumer needs
fixing). Also if disabling an enabled PWM was the right thing to do,
this should better be done in the framework instead of in each low level
driver.

So drop the hardware modification from the .remove() callback.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>