From: Stephen Warren <swarren@wwwdotorg•org>
To: Mark Brown <broonie@kernel•org>
Cc: mark.rutland@arm•com, devicetree@vger•kernel.org,
alsa-devel@alsa-project•org, lars@metafoo•de, festevam@gmail•com,
s.hauer@pengutronix•de, Nicolin Chen <b42378@freescale•com>,
timur@tabi•org, rob.herring@calxeda•com, tomasz.figa@gmail•com,
p.zabel@pengutronix•de, R65777@freescale•com,
shawn.guo@linaro•org, linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver
Date: Tue, 20 Aug 2013 09:48:46 -0600 [thread overview]
Message-ID: <52138FDE.3080007@wwwdotorg.org> (raw)
In-Reply-To: <20130820001858.GF30073@sirena.org.uk>
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.
next prev parent reply other threads:[~2013-08-20 15:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-19 12:08 [PATCH v8 0/2] Add freescale S/PDIF CPU DAI and machine drivers Nicolin Chen
2013-08-19 12:08 ` [PATCH v8 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver Nicolin Chen
2013-08-19 12:34 ` Sascha Hauer
2013-08-20 2:21 ` Nicolin Chen
2013-08-19 21:35 ` Stephen Warren
2013-08-20 2:28 ` Nicolin Chen
2013-08-20 15:49 ` Stephen Warren
2013-08-19 12:08 ` [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver Nicolin Chen
2013-08-19 21:39 ` Stephen Warren
2013-08-20 0:18 ` Mark Brown
2013-08-20 15:48 ` Stephen Warren [this message]
2013-08-20 19:07 ` Mark Brown
2013-08-20 19:53 ` Stephen Warren
2013-08-20 22:28 ` Mark Brown
2013-08-21 2:18 ` [alsa-devel] " Nicolin Chen
2013-08-21 16:08 ` Stephen Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52138FDE.3080007@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=R65777@freescale$(echo .)com \
--cc=alsa-devel@alsa-project$(echo .)org \
--cc=b42378@freescale$(echo .)com \
--cc=broonie@kernel$(echo .)org \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=festevam@gmail$(echo .)com \
--cc=lars@metafoo$(echo .)de \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mark.rutland@arm$(echo .)com \
--cc=p.zabel@pengutronix$(echo .)de \
--cc=rob.herring@calxeda$(echo .)com \
--cc=s.hauer@pengutronix$(echo .)de \
--cc=shawn.guo@linaro$(echo .)org \
--cc=timur@tabi$(echo .)org \
--cc=tomasz.figa@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox