linux-kernel - Re: [RESEND x3][PATCH v4] arm64: dts: hi6220: Add k3-dma and i2s/hdmi audio support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALAqxLXkkwzo32nFwEJjDRy9X3YY5KWAVc_dp0FNY49Zy79KFg@mail.gmail.com>
Date:   Tue, 13 Jun 2017 12:40:28 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc:     Mark Brown <broonie@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Zhangfei Gao <zhangfei.gao@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, Wei Xu <xuwei5@...ilicon.com>,
        Rob Herring <robh+dt@...nel.org>,
        Andy Green <andy@...mcat.com>,
        Dave Long <dave.long@...aro.org>,
        Guodong Xu <guodong.xu@...aro.org>,
        Antonio Borneo <borneo.antonio@...il.com>,
        Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [RESEND x3][PATCH v4] arm64: dts: hi6220: Add k3-dma and i2s/hdmi
 audio support

On Mon, Jun 12, 2017 at 7:09 PM, Kuninori Morimoto
<kuninori.morimoto.gx@...esas.com> wrote:
>
> Hi John
>
>> On Mon, Jun 12, 2017 at 3:10 PM, Mark Brown <broonie@...nel.org> wrote:
>> > On Mon, Jun 12, 2017 at 01:52:46PM -0700, John Stultz wrote:
>> >
>> >> +     sound {
>> >> +             compatible = "simple-audio-card";
>> >> +             simple-audio-card,name = "hikey-hdmi";
>> >
>> > Now the graph card has been merged it's probably a good idea to be using
>> > that, it's generally a better idea for pretty much all use cases.
>>
>> I've taken a shot today trying to convert over to the audio-graph-card
>> method (which isn't yet upstream, but in -next), but I've been running
>> into some quirks.
>>
>> Part of the issue is the adv7533 bridge already has a endpoint port
>> entry for the dsi output. So when I add the codec_endpoint port, it
>> wants the two port entries to be enumerated, so I get something like:
>>
>> port@0 {
>>     adv7533_in: endpoint {
>>         remote-endpoint = <&dsi_out0>;
>>     };
>> };
>> port@1 {
>>     codec_endpoint: endpoint {
>>         remote-endpoint = <&i2s0_cpu_endpoint>;
>>     };
>> };
>>
>> But this causes it to try to link to hdmi-hifi.1 (which doesn't exist)
>> instead of hdmi-hifi.0.
>>
>> If I instead swap the entries, so the codec_endpoint is first on port
>> 0, then the the audio link is properly setup, but the dsi
>> initialization falls over.
>
> I think you want to exchange port@1 as ID=0 for ALSA SoC ?
> If so, we already has .of_xlate_dai_id callback for this purpose.
>
> Does below help your issue ?
>
>         commit 73b17f1a65c881fcf97109d77056006da2d40152
>         commit a180e8b988437b3e84a1b501ac4d073467602ca6
>
> Samplle codes are
>
>         linux/sound/soc/codecs/hdmi-codec.c :: hdmi_of_xlate_dai_id
>         https://patchwork.kernel.org/patch/9732285/ (I posted, but not yet applied)

:/ So with the above approach I did manage to get it working. And I'm
not opposed to migrating to this, but it doesn't really feel finished
at the moment (the magic hard coding of port 2 ==> 0 feels a bit
hackish, but I'm not sure how else one can use the same port style dts
description across the two namespaces of display and audio).  While
I'm sure for many cases the graph approach is much cleaner, I'm not
sure for this one how its improving over the much simpler
simple-audio-card binding.

So yea, I'm ok with migrating to this, but I'm also not super
enthusiastic about delaying (I'm guessing likely to 4.14 since we have
new unqueued code dependencies to get in) the enabling of this
functionality in order to moving to something that at least for this
case "seems" a bit more hackish.

The simple-audio-card bindings are still valid, so maybe could we
merge the proposed dts change I've submitted and then look at
migrating over to the audio-card-graph once the dependencies are all
in place?

thanks
-john