The legacy sd modulator driver registers the sigma delta modulator as
an IIO channel provider. This implementation is not convenient when the
SD modulator has to be cascaded with another IIO device. The scaling
information is distributed across devices, which makes it difficult to
report consistent scaling data on IIO devices.
The solution is to expose these cascaded IIO devices as an aggregate
device, which report global scaling information.
Add IIO backend support to SD modulator to allow scaling information
management.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20240730084640.1307938-6-olivier.moysan@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Change the DFSDM binding to use the new IIO backend framework,
along with the adoption of IIO generic channels.
This binding change allows to add scaling support to the DFSDM.
Keep the legacy binding as deprecated for backward compatibility.
The io-backends property is supported only in generic IIO channel
binding.
- Channel description with the generic binding (Audio and Analog):
Properties superseded by generic properties:
st,adc-channels: becomes "reg" property in channel node
st,adc-channel-names: becomes "label" property in channel node
Properties moved to channel child node:
st,adc-channel-types: becomes st,adc-channel-type
st,adc-channel-clk-src, st,adc-alt-channel
- Analog binding:
DFSDM filter channel is configured as an IIO backend consumer.
Add io-backends property in channel child nodes.
DFSDM is no more configured as a channel consumer from SD modulator.
Use of io-channels in DFSDM node is deprecated.
- Audio binding:
DFSDM audio DAI is configured as a channel consumer from DFSDM filter.
No change compare to legacy.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20240730084640.1307938-5-olivier.moysan@foss.st.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Internal clock of AD719X devices can be made available on MCLK2 pin. Add
clock provider to support this functionality when clock cells property
is present.
The clock source can be either provided externally or the internal clock
is used. Pair of clocks and clock-names property is mutally exclusive
with #clock-cells property.
Modify second example to showcase the mode where internal clock is used.
Signed-off-by: Alisa-Dariana Roman <alisa.roman@analog.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20240717212535.8348-4-alisa.roman@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There are actually 4 configuration modes of clock source for AD719X
devices. Either a crystal can be attached externally between MCLK1 and
MCLK2 pins, or an external CMOS-compatible clock can drive the MCLK2
pin. The other 2 modes make use of the 4.92MHz internal clock.
To configure external clock as either a crystal or a CMOS-compatible
clock, changing the register settings is necessary. Therefore, add clock
name xtal alongside mclk. By selecting one or the other, the register is
configured.
The presence of an external clock source is optional, not required. When
both clocks and clock-names properties are present, an external clock
source is used. If the intention is to use the internal clock, both
properties should be absent. Modify required properties accordingly.
Signed-off-by: Alisa-Dariana Roman <alisa.roman@analog.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20240717212535.8348-2-alisa.roman@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Since the driver supports several parts that present differences in
their layout and behaviour, it is necessary to describe the differences
from one chip to another.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Guillaume Stols <gstols@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The 'single-channel' property is an uint32, not an array, so 'items' is
an incorrect constraint. This didn't matter until dtschema recently
changed how properties are decoded. This results in this warning:
Documentation/devicetree/bindings/iio/adc/adi,ad7192.example.dtb: adc@0: \
channel@1:single-channel: 1 is not of type 'array'
Fixes: caf7b7632b ("dt-bindings: iio: adc: ad7192: Add AD7194 support")
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240723230904.1299744-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Devices that have both single-ended channels and differential channels
cause a bit of confusion when the channels are configured in the
devicetree.
Clarify difference between these two types of channels for such devices
by adding single-channel property alongside diff-channels. They should
be mutually exclusive.
Devices that have only single-ended channels can still use reg property
to reference a channel like before.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Alisa-Dariana Roman <alisa.roman@analog.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240514120222.56488-5-alisa.roman@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Pull char/misc and other driver subsystem updates from Greg KH:
"Here is the big set of char/misc and other driver subsystem updates
for 6.10-rc1. Nothing major here, just lots of new drivers and updates
for apis and new hardware types. Included in here are:
- big IIO driver updates with more devices and drivers added
- fpga driver updates
- hyper-v driver updates
- uio_pruss driver removal, no one uses it, other drivers control the
same hardware now
- binder minor updates
- mhi driver updates
- excon driver updates
- counter driver updates
- accessability driver updates
- coresight driver updates
- other hwtracing driver updates
- nvmem driver updates
- slimbus driver updates
- spmi driver updates
- other smaller misc and char driver updates
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (319 commits)
misc: ntsync: mark driver as "broken" to prevent from building
spmi: pmic-arb: Add multi bus support
spmi: pmic-arb: Register controller for bus instead of arbiter
spmi: pmic-arb: Make core resources acquiring a version operation
spmi: pmic-arb: Make the APID init a version operation
spmi: pmic-arb: Fix some compile warnings about members not being described
dt-bindings: spmi: Deprecate qcom,bus-id
dt-bindings: spmi: Add X1E80100 SPMI PMIC ARB schema
spmi: pmic-arb: Replace three IS_ERR() calls by null pointer checks in spmi_pmic_arb_probe()
spmi: hisi-spmi-controller: Do not override device identifier
dt-bindings: spmi: hisilicon,hisi-spmi-controller: clean up example
dt-bindings: spmi: hisilicon,hisi-spmi-controller: fix binding references
spmi: make spmi_bus_type const
extcon: adc-jack: Document missing struct members
extcon: realtek: Remove unused of_gpio.h
extcon: usbc-cros-ec: Convert to platform remove callback returning void
extcon: usb-gpio: Convert to platform remove callback returning void
extcon: max77843: Convert to platform remove callback returning void
extcon: max3355: Convert to platform remove callback returning void
extcon: intel-mrfld: Convert to platform remove callback returning void
...
access-controllers is an optional property that allows a peripheral to
refer to one or more domain access controller(s).
Description of this property is added to all peripheral binding files of
the peripheral under the STM32 firewall controller. It allows an accurate
representation of the hardware, where various peripherals are connected
to a firewall bus. The firewall can then check the peripheral accesses
before allowing its device to probe.
Signed-off-by: Gatien Chevallier <gatien.chevallier@foss.st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The AD7173 family offer a complete integrated Sigma-Delta ADC solution
which can be used in high precision, low noise single channel applications
or higher speed multiplexed applications. The Sigma-Delta ADC is intended
primarily for measurement of signals close to DC but also delivers
outstanding performance with input bandwidths out to ~10kHz.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Dumitru Ceclan <mitrutzceclan@gmail.com>
Link: https://lore.kernel.org/r/20240228110622.25114-1-mitrutzceclan@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
'adi,adc-dev' is now deprecated and must not be used anymore. Hence,
also remove it from being required.
The reason why it's being deprecated is because the axi-adc CORE is now
an IIO service provider hardware (IIO backends) for consumers to make use
of. Before, the logic with 'adi,adc-dev' was the opposite (it was kind
of consumer referencing other nodes/devices) and that proved to be wrong
and to not scale.
Now, IIO consumers of this hardware are expected to reference it using the
io-backends property. Hence, the new '#io-backend-cells' is being added
so the device is easily identified as a provider.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240210-iio-backend-v11-2-f5242a5fb42a@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
