Re: [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver

On 08/19/2013 06:18 PM, Mark Brown wrote:

On Mon, Aug 19, 2013 at 03:39:26PM -0600, Stephen Warren wrote:

quoted

On 08/19/2013 06:08 AM, Nicolin Chen wrote:

quoted

This patch implements a device-tree-only machine driver for
Freescale i.MX series Soc. It works with
spdif_transmitter/spdif_receiver and fsl_spdif.c drivers.

quoted

diff --git
a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt

quoted

quoted

+Optional properties:

quoted

quoted

+  - spdif-transmitter : The phandle of the spdif-transmitter
dummy codec +  - spdif-receiver : The phandle of the
spdif-receiver dummy codec

quoted

quoted

+* Note: At least one of these two properties should be set in
the DT binding.

quoted

Those object truly don't exist in HW and only exist due to
internal details of Linux's ASoC subsystem.

They will physically exist if they're usefully present on the board
(in the sense that they're there and can be pointed at) - there
will be either a TOSLINK optical connector or (less commonly) an
electrical connector breaking the signal out to go elsewhere though
they don't have any interaction with software usually which is more
what you mean here.

Sure, the S/PDIF signal is connected to something, but it is not a
"dummy CODEC"; a "dummy CODEC" is purely something internal to ASoC
and absolutely nothing to do with HW.

quoted

Or, to map the properties more directly to HW, perhaps name the
property "spdif-tx-jack-exists", or even "spdif-tx-jack" and make
it a phandle to a node that represents the actual S/PDIF
connector?

S/PDIF is also sometimes used as an interconnect between devices -
some CODECs have S/PDIF I/O (more normally used as an external
connector on the box).  This is most frequently seen as a way to
plumb HDMI in since some HDMI devices seem to provide this as a
legacy interconnect, though it can get used just for regular CODECs
as well.  Using this machine driver would probably be a bit of an
abuse for some applications, though with things like the HDMI one
the goal of the hardware is to be dropped into a driver like this
so perhaps it makes sense and is useful anyway.

Equally well it'd be good to get this stuff actually merged, it
seems to have been surprisingly time consuming thus far...

That's not a good argument for an incorrect binding.