This series updates Sameer's patch to repartition the graph card binding
schema and incorporate the OF graph schema. The schema was also mixing
card node and DAI node properties, so I've split the DAI part (the
'port' node) into a separate schema.
There's another problem that 'frame-master' and 'bitclock-master' have
inconsistent types of boolean and phandle. Having the properties just
point to the local or remote endpoint within an endpoint node is kind of
pointless. We should have gone with just boolean, but looks like we
already have several users. MMP OLPC is the one platform using boolean,
but it happens to work because the properties are effectively ignored
and CPU DAI as the master is the default.
Rob
Rob Herring (3):
ASoC: dt-bindings: Use OF graph schema
ASoC: dt-bindings: marvell,mmp-sspa: Use audio-graph-port schema
ASoC: dt-bindings: Refine 'frame-master' and 'bitclock-master' type
Sameer Pujar (1):
ASoC: audio-graph-card: Refactor schema
.../bindings/sound/audio-graph-card.yaml | 106 +-----------------
.../bindings/sound/audio-graph-port.yaml | 72 ++++++++++++
.../bindings/sound/audio-graph.yaml | 45 ++++++++
.../bindings/sound/marvell,mmp-sspa.yaml | 25 +----
.../bindings/sound/renesas,rsnd.yaml | 12 +-
.../bindings/sound/simple-card.yaml | 6 +-
6 files changed, 132 insertions(+), 134 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/audio-graph-port.yaml
create mode 100644 Documentation/devicetree/bindings/sound/audio-graph.yaml
base-commit: e2e99930ec006c6fe1d62af339a765ade71a0d9a
--
2.25.1
There can be customized sound cards which are based on generic audio
graph. In such cases most of the stuff is reused from generic audio
graph. To facilitate this, refactor audio graph schema into multiple
files and the base schema can be reused for specific sound cards.
The graph card nodes and port nodes are separate entities, so they
should be separate schemas.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
[robh: Split out port schema. Add graph.yaml in subsequent commit]
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/20201117013349.2458416-2-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
All the items in the TODO list were addressed, uapi was reviewed,
documentation written, checkpatch errors fixed, several bugs fixed.
There is no big reason to keep this driver in staging, so move it out.
Dt-bindings Verified with:
make ARCH=arm64 dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/media/rockchip-isp1.yaml
Fields of MAINTAINERS file sorted according to output of
./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS
--order
[dt-bindings: media: rkisp1: move rockchip-isp1 bindings out of staging]
[dt-bindings: media: rkisp1: move rockchip-isp1 bindings out of staging]
[hverkuil: fix various checkpatch alignment warnings]
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
I have put Michael as maintainer on this one. Happy to change it to
someone else though.
One issue in here, is I cannot have an example with a negative
limit on the range. There are very few such yaml bindings in existence
but the thermal-zones.yaml has the same problem. If there is
any means of fixing this let me know. For now I'm sticking to
positive range values in the example.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Michael Hennerich <Michael.Hennerich@analog.com>
Link: https://lore.kernel.org/r/20201031134110.724233-24-jic23@kernel.org
Converted to maintain the requirement for Vdd-supply as per original file.
It is possible we could relax this requirement to make it at least one
of Vdd-supply and REF-supply. We need to establish the scaling of the
output channel and if REF-supply is provided that is used instead of
Vdd-supply, hence I cannot see why a dummy regulator cannot be used for
Vdd-supply if this happens.
For now, let us keep it simple.
Drop adi,use-external-reference from binding example as no such binding
exists.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20201031134110.724233-18-jic23@kernel.org
This one is a bit interesting because the binding was moved from
misc a while back, but the linux support for this device is
provided via the ad5446 DAC driver which doesn't currently
have a binding.
For now, lets just convert this file over, but we may want to
think about consolidating this with proper documentation of
the bindings for the other parts supported by the ad5446 driver.
As Daniel Mack does not seem to have been active since 2015,
I've put myself as maintainer of this binding for now.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031134110.724233-15-jic23@kernel.org
A few tweaks in this conversion.
* The example didn't have the I2C address of 4C in the node name so
fixed that.
* The reference voltage in the txt file is an optional binding, but
the driver is making use of it to provide the scaling of the output
channels. As such I have made it required going forwards.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Sean Nyekjaer <sean@geanix.com>
Link: https://lore.kernel.org/r/20201031134110.724233-13-jic23@kernel.org
Simple conversion. There hasn't been much activity around this driver
for a long time and I don't think I have any up to date contact details
for the original authors. As such, I've listed myself as the binding
maintainer. More than happy to hand it off to someone more relevant though!
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20201031134110.724233-10-jic23@kernel.org
The conversion is straight forward, but leaves an open question.
The compatible for this device has never had a vendor.
Harald Geyer has identified as probably being made by aosong,
but we have no current match to any of their more specific part
numbers. As such, this is noted in the file but the
compatible doesn't include the vendor prefix.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-By: Harald Geyer <harald@ccbib.org>
Link: https://lore.kernel.org/r/20201031134110.724233-5-jic23@kernel.org
