From: Stephen Warren <swarren@wwwdotorg•org>
To: Nicolin Chen <b42378@freescale•com>
Cc: mark.rutland@arm•com, devicetree@vger•kernel.org,
alsa-devel@alsa-project•org, lars@metafoo•de, festevam@gmail•com,
s.hauer@pengutronix•de, timur@tabi•org, rob.herring@calxeda•com,
tomasz.figa@gmail•com, broonie@kernel•org,
p.zabel@pengutronix•de, R65777@freescale•com,
shawn.guo@linaro•org, linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH v10 2/2] ASoC: fsl: Add S/PDIF machine driver
Date: Thu, 22 Aug 2013 13:56:32 -0600 [thread overview]
Message-ID: <52166CF0.9080402@wwwdotorg.org> (raw)
In-Reply-To: <20130822114027.GA4258@MrMyself>
On 08/22/2013 05:40 AM, Nicolin Chen wrote:
> Hi Stephen,
>
> On Wed, Aug 21, 2013 at 12:30:59PM -0600, Stephen Warren wrote:
>> I still don't think those two properties are correct.
>>
>> Exactly what node will those phandles point at?
>>
>> There definitely should not be a DT node for any "dummy CODEC",
>> irrespective of whether this binding calls the other node a "CODEC" or a
>> "dummy CODEC".
>>
>> If these properties are to contain phandles, it would be acceptable for
>> the referenced node to be:
>>
>> * A node representing the physical connector/jack on the board.
>>
>> * A node representing some other IP block on the board, such as an HDMI
>> encoder/display-controller
>>
>> I think those options are unlikely in general, so I think instead these
>> properties should just be Boolean indicating that "something" is
>> connector to the S/PDIF RX/TX, without specifying what that "something"
>> is. It doesn't matter what at least in the connector/jack case, although
>> perhaps it does in the HDMI encoder/display-controller?
>
> Documentation/devicetree/bindings/sound/spdif-receiver.txt
> If I understand correctly, this doc for the dummy codec should be invalid?
Yes, I'm not convinced that binding is a good idea; it describes
something that often doesn't actually exist in HW. (Sometimes there's a
real S/PDIF receiving device on board, but sometimes there's nothing
except a jack/connector).
It'd be useful if other DT binding maintainers could weigh in on this to
confirm/deny my thoughts.
> But this patch, the spdif machine driver, is based on this codec driver,
> pls check the following code:
>
> 164 + codec_rx_np = of_parse_phandle(np, "spdif-receiver", 0);
> 165 + if (codec_rx_np) {
> 169 + data->dai[num_links].codec_of_node = codec_rx_np;
> 173 + }
>
> Accordingly, the binding I planned to add in DT:
>
> 27 + spdif_rx_codec: spdif-receiver {
> 28 + compatible = "linux,spdif-dir";
> 29 + };
> 30 +
> 31 + sound-spdif {
> 32 + compatible = "fsl,imx-audio-spdif",
> 33 + "fsl,imx-sabreauto-spdif";
> 34 + model = "imx-spdif";
> 35 + spdif-controller = <&spdif>;
> 37 + spdif-receiver = <&spdif_rx_codec>;
> 38 + };
>
> So if the DT can't allow me to include this codec node, how could I
> handle it in the current baseline.
I would expect the machine driver's probe routine to create the dummy
S/PDIF receiver object itself, and register it by calling
snd_soc_register_codec(). That way, only the machine driver code need
know it (dummy CODEC) exists.
next prev parent reply other threads:[~2013-08-22 19:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 3:13 [PATCH v10 0/2] Add freescale S/PDIF CPU DAI and machine drivers Nicolin Chen
2013-08-21 3:13 ` [PATCH v10 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver Nicolin Chen
2013-08-21 18:26 ` Stephen Warren
2013-08-22 9:45 ` Mark Brown
2013-08-21 3:13 ` [PATCH v10 2/2] ASoC: fsl: Add S/PDIF machine driver Nicolin Chen
2013-08-21 18:30 ` Stephen Warren
2013-08-21 18:54 ` Tomasz Figa
2013-08-21 22:14 ` Stephen Warren
2013-08-22 11:40 ` Nicolin Chen
2013-08-22 19:56 ` Stephen Warren [this message]
2013-08-22 20:05 ` Mark Brown
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=52166CF0.9080402@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