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
...
Pull devicetree updates from Rob Herring:
- Refactor powerpc and arm64 kexec DT handling to common code. This
enables IMA on arm64.
- Add kbuild support for applying DT overlays at build time. The first
user are the DT unittests.
- Fix kerneldoc formatting and W=1 warnings in drivers/of/
- Fix handling 64-bit flag on PCI resources
- Bump dtschema version required to v2021.2.1
- Enable undocumented compatible checks for dtbs_check. This allows
tracking of missing binding schemas.
- DT docs improvements. Regroup the DT docs and add the example schema
and DT kernel ABI docs to the doc build.
- Convert Broadcom Bluetooth and video-mux bindings to schema
- Add QCom sm8250 Venus video codec binding schema
- Add vendor prefixes for AESOP, YIC System Co., Ltd, and Siliconfile
Technologies Inc.
- Cleanup of DT schema type references on common properties and
standard unit properties
* tag 'devicetree-for-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (64 commits)
powerpc: If kexec_build_elf_info() fails return immediately from elf64_load()
powerpc: Free fdt on error in elf64_load()
of: overlay: Fix kerneldoc warning in of_overlay_remove()
of: linux/of.h: fix kernel-doc warnings
of/pci: Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses
dt-bindings: bcm4329-fmac: add optional brcm,ccode-map
docs: dt: update writing-schema.rst references
dt-bindings: media: venus: Add sm8250 dt schema
of: base: Fix spelling issue with function param 'prop'
docs: dt: Add DT API documentation
of: Add missing 'Return' section in kerneldoc comments
of: Fix kerneldoc output formatting
docs: dt: Group DT docs into relevant sub-sections
docs: dt: Make 'Devicetree' wording more consistent
docs: dt: writing-schema: Include the example schema in the doc build
docs: dt: writing-schema: Remove spurious indentation
dt-bindings: Fix reference in submitting-patches.rst to the DT ABI doc
dt-bindings: ddr: Add optional manufacturer and revision ID to LPDDR3
dt-bindings: media: video-interfaces: Drop the example
devicetree: bindings: clock: Minor typo fix in the file armada3700-tbg-clock.txt
...
Pull devicetree fixes from Rob Herring:
- Cleanups on properties with standard unit suffixes
- Fix overwriting dma_range_map if there's no 'dma-ranges' property
- Fix a bug when creating a /chosen node from ARM ATAGs
- Add missing properties for TI j721e USB binding
- Several doc reference updates due to DT schema conversions
* tag 'devicetree-fixes-for-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
dt-bindings: Cleanup standard unit properties
of/device: Update dma_range_map only when dev has valid dma-ranges
ARM: zImage: atags_to_fdt: Fix node names on added root nodes
dt-bindings: usb: j721e: add ranges and dma-coherent props
dt-bindings:iio:adc: update adc.yaml reference
dt-bindings: memory: mediatek: update mediatek,smi-larb.yaml references
dt-bindings: display: mediatek: update mediatek,dpi.yaml reference
ASoC: audio-graph-card: update audio-graph-card.yaml reference
PM8009 has special revision (P=1), which is to be used for sm8250
platform. The major difference is the S2 regulator which supplies 0.95 V
instead of 2.848V. Declare regulators data to be used for this chip
revision. The datasheet calls the chip just pm8009-1, so use the same
name.
base-commit: 5c8fe583cc
The pf8x00 driver supports three devices, the DT compatible strings
and I2C IDs should enumerate these specifically rather than using a
wildcard so that we don't collide with anything incompatible in the
same ID range in the future and so that we can handle any software
visible differences between the variants we find.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20201215132024.13356-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Update bindings for the Dialog Semiconductor DA9121 voltage regulator to
add device variants.
Because several variants have multiple regulators, and to regard potential
to add GPIO support in future, the 'regulators' sub-node is added,
following the precedent set by other multi-regulator devices, including
the DA9211 family. This breaks compatibility with the original submission
by Vincent Whitchurch - but as this is still in for-next, the alignment
could be made before upstreaming occurs.
Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/0606d3ded5fef4c38760246146f197db4ce3a374.1606755367.git.Adam.Ward.opensource@diasemi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
RFC for adding a support for typical voltage scaling connection
In few occasions there has been a need to scale the voltage output
from bucks on BD71837. Usually this is done when buck8 is used to
power specific GPU which can utilize voltages down to 0.7V. As lowest
the buck8 on BD71837 can go is 0.8V, and external connection is used to
scale the voltages.
The BD71837, BD71847 and BD71850 bucks can be adjusted by pulling up the
feedback pin using suitable voltage/resistors.
|---------------|
| buck 8 |-------+----->Vout
| | |
|---------------| |
| |
| |
+-------+--R2----+
|
R1
|
V FB-pull-up
This will scale the voltage as follows:
- Vout_o = Vo - (Vpu - Vo)*R2/R1
- Linear_step = step_orig*(R1+R2)/R1
where:
Vout_o is adjusted voltage output at vsel reg value 0
Vo is original voltage output at vsel reg value 0
Vpu is the pull-up voltage V FB-pull-up in the picture
R1 and R2 are resistor values.
>From HW point of view this does not need to be limited to buck 8. This
connection can be used to adjust output from any of the bucks on
BD71837/47/50.
As this seems to be a 'de-facto' way to scale the voltages on BD71837 it
might be a good idea to support computing the new voltage ranges for
bucks based on the V-pull-up and resistor R1/R2 values given from
device-tree. This allows describing the external HW connection using DT
to correctly scale the voltages.
This RFC uses "rohm,feedback-pull-up-r1-ohms" and
"rohm,feedback-pull-up-r2-ohms" to provide the resistor values - but
these names (without the picture) might not be too descriptive. I am
grateful for all suggestions as better and more descriptive names.
This patch series is an RFC because this connection feels somewhat
"hacky". OTOH - when hack becomes widely used, it is less of an hack and
more of a standard - and occasionally supporting HW hacks using SW may
benefit us all, right? :)
The other thing some projects do is allowing the change of BD71837 buck8
voltages when buck8 is enabled. This however will introduce voltage
spikes as buck8 was not originally designed for this. The specific HW
platform must be evaluated to be able to tolerate these spikes. Thus
this patch series does not support buck8 voltage changes when buck8 is
enabled. I wonder if this should be allowed per some config option(?) I
don't want to help people frying their boards... Opinions? Is there
suggested way of allowing this type of features at own risk? Config or
even Some #ifdef which is not listed in Kconfig? Device-tree property?
If you have (good) suggestions I could add the optional (non default)
DVS support for non DVS bucks on BD71837.
Matti Vaittinen (3):
dt-bindings: regulator: BD71837 support commonly used feedback
connection
dt-bindings: regulator: BD71847 support commonly used feedback
connection
regulator: bd718x7: Support external connection to scale voltages
.../regulator/rohm,bd71837-regulator.yaml | 48 +++++
.../regulator/rohm,bd71847-regulator.yaml | 49 ++++++
drivers/regulator/bd718x7-regulator.c | 164 +++++++++++++++++-
3 files changed, 254 insertions(+), 7 deletions(-)
base-commit: 3cea11cd5e
--
2.21.3
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
Another round of wack-a-mole. The json-schema default is additional
unknown properties are allowed, but for DT all properties should be
defined.
Signed-off-by: Rob Herring <robh@kernel.org>
In cases where we don't reference another schema, 'additionalProperties'
can be used instead. This is preferred for now as 'unevaluatedProperties'
support isn't implemented yet.
In a few cases, this means adding some missing property definitions of
which most are for SPI bus properties. 'unevaluatedProperties' is not going
to work for the SPI bus properties anyways as they are evaluated from the
parent node, not the SPI child node.
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20201005183830.486085-3-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
This doesn't yet do anything in the tools, but make it explicit so we can
check either 'unevaluatedProperties' or 'additionalProperties' is present
in schemas.
'unevaluatedProperties' is appropriate when including another schema (via
'$ref') and all possible properties and/or child nodes are not
explicitly listed in the schema with the '$ref'.
This is in preparation to add a meta-schema to check for missing
'unevaluatedProperties' or 'additionalProperties'. This has been a
constant source of review issues.
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Wolfram Sang <wsa@kernel.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-By: Vinod Koul <vkoul@kernel.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20201005183830.486085-2-robh@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
The PM660 and PM660L combo is found on boards featuring the
SDM630, SDM636, SDM660 (and SDA variants) and it is used to
give power to practically everything, from core to peripherals.
Document the SMD-RPM regulator entries for both.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-8-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The PM660 and PM660L combo is found on boards featuring the
SDM630, SDM636, SDM660 (and SDA variants) and it is used to
give power to practically everything, from core to peripherals.
Document the SPMI regulator bindings for both.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-5-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>