From: jeffy.chen@rock-chips.com (jeffy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] ASoC: rockchip: Parse dai links from dts
Date: Thu, 17 Aug 2017 12:45:13 +0800 [thread overview]
Message-ID: <59951F59.3010101@rock-chips.com> (raw)
In-Reply-To: <20170816235058.GA173745@google.com>
Hi Matthias,
On 08/17/2017 07:50 AM, Matthias Kaehlcke wrote:
> El Thu, Aug 17, 2017 at 06:55:20AM +0800 jeffy ha dit:
>
>> hi matthias,
>>
>> thanks for your suggestion.
>>
>> On 08/17/2017 05:59 AM, Matthias Kaehlcke wrote:
>>> El Thu, Aug 10, 2017 at 12:54:56PM +0800 Jeffy Chen ha dit:
>>>
>>>>> Refactor rockchip_sound_probe, parse dai links from dts instead of
>>>>> hard coding them.
>>> Mark doesn't seem to be overly convinced that 'rockchip,codec-names'
>>> is a good idea (https://lkml.org/lkml/2017/8/10/511).
>>>
>>> How about using something like this instead:
>>>
>>> static const char *dailink_compat[] = {
>>> [DAILINK_MAX98357A] = "maxim,max98357a",
>>> [DAILINK_RT5514] = "realtek,rt5514",
>>> [DAILINK_DA7219] = "dlg,da7219",
>>> };
>> i've thought about this too, but i'm working on converting rt5514
>> dsp(spi) from codec name matching to of_node, and it would have the
>> same compatible with rt5514(i2c)
>
> Bummer!
>
> I wonder if a relatively inoffensive DT hack would be an appropriate
> solution in this case, since the conflicting compatible string is a
> somewhat special case and this change only affects the DT and the
> driver/glue of a specific device (family).
>
> The hack would consist in adding an additional 'compatible' entry to
> the DT entry of the codec, which is ignored by the rt5514 driver, and
> only used by the sound glue to identify it:
>
> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
> @@ -671,7 +671,7 @@ ap_i2c_mic: &i2c1 {
> i2c-scl-rising-time-ns = <300>;
>
> headsetcodec: rt5514 at 57 {
> - compatible = "realtek,rt5514";
> + compatible = "realtek,rt5514", "realtek,rt5514-i2c";
>
>
> And then use "realtek,rt5514-i2c" in dailink_compat.
this should work, i'll do that in new version, thanks.
>
> Mark, would you prefer a hack like this over the list of codec names
> or do you have any other suggestions?
>
> Matthias
>
>
>
next prev parent reply other threads:[~2017-08-17 4:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-10 4:54 [PATCH v2 0/3] ASoC: rockchip: Parse dai links from dts Jeffy Chen
2017-08-10 4:54 ` [PATCH v2 1/3] " Jeffy Chen
2017-08-16 21:59 ` Matthias Kaehlcke
2017-08-16 22:55 ` jeffy
2017-08-16 23:50 ` Matthias Kaehlcke
2017-08-17 4:45 ` jeffy [this message]
2017-08-10 4:54 ` [PATCH v2 2/3] arm64: dts: rockchip: Add rockchip, codec-names property Jeffy Chen
2017-08-10 4:54 ` [PATCH v2 3/3] dt-bindings: ASoC: " Jeffy Chen
2017-08-10 14:56 ` [PATCH v2 3/3] dt-bindings: ASoC: rockchip: Add rockchip,codec-names property Mark Brown
2017-08-11 1:30 ` [PATCH v2 3/3] dt-bindings: ASoC: rockchip: Add rockchip, codec-names property jeffy
2017-08-17 15:10 ` [PATCH v2 3/3] dt-bindings: ASoC: rockchip: Add rockchip,codec-names property Rob Herring
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=59951F59.3010101@rock-chips.com \
--to=jeffy.chen@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).