On 08/19/2013 06:18 PM, Mark Brown wrote: > On Mon, Aug 19, 2013 at 03:39:26PM -0600, Stephen Warren wrote: >> On 08/19/2013 06:08 AM, Nicolin Chen wrote: >>> 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. >> >>> diff --git >>> a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt >>> b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt > >>> +Optional properties: > >>> + - spdif-transmitter : The phandle of the spdif-transmitter >>> dummy codec + - spdif-receiver : The phandle of the >>> spdif-receiver dummy codec > >>> +* Note: At least one of these two properties should be set in >>> the DT binding. > >> 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. >> 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
