linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sameer Pujar <spujar@nvidia.com>
To: Takashi Iwai <tiwai@suse.de>, Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Mark Brown <broonie@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Olof Johansson <olof@lixom.net>,
	Thierry Reding <treding@nvidia.com>,
	ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: linux-next: manual merge of the sound tree with the arm-soc tree
Date: Mon, 25 Feb 2019 16:54:37 +0530	[thread overview]
Message-ID: <e2aaed45-0fb1-c9c8-76d4-3b97b36cada6@nvidia.com> (raw)
In-Reply-To: <s5hr2bw2k7m.wl-tiwai@suse.de>


On 2/25/2019 4:44 PM, Takashi Iwai wrote:
> On Mon, 25 Feb 2019 10:19:15 +0100,
> Arnd Bergmann wrote:
>> On Mon, Feb 25, 2019 at 2:36 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> Hi Takashi,
>>>
>>> Today's linux-next merge of the sound tree got conflicts in:
>>>
>>>    arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
>>>    arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
>>>
>>> between commits:
>>>
>>>    5eef17ee764d ("arm64: tegra: p2972: Sort nodes properly")
>>>    be4f0dd347ad ("arm64: tegra: p2597: Sort nodes by unit-address")
>>>
>>> from the arm-soc tree and commit:
>>>
>>>    11ce4308307c ("arm64: tegra: custom name for hda sound card")
>>>
>>> from the sound tree.
>>>
>>> I fixed it up (see below - in tegra194-p2972-0000.dts. the line added
>>> just needed to be moved up a few lines) and can carry the fix as
>>> necessary. This is now fixed as far as linux-next is concerned, but any
>>> non trivial conflicts should be mentioned to your upstream maintainer
>>> when your tree is submitted for merging.  You may also want to consider
>>> cooperating with the maintainer of the conflicting tree to minimise any
>>> particularly complex conflicts.
>> The merge looks fine to me, but I wonder about that commit
>> in the alsa tree, why does the sound card need a board specific
>> name?
>>
>> I see this property being used in commit c0bde003a013 ("ALSA:
>> hda/tegra: sound card name from device tree"), which removes
>> a questionable use of the root compatible property, replacing
>> it with the new 'nvidia,model' property. We don't do this for any
>> other subsystem, so why does the sound subsystem export
>> information about the board as a string here?
> The sound subsystem exports merely some understandable name string
> for the given sound card object, and that was composed from the
> compatible string in the past, which turned out to be useless on some
> configs.
>
> But this kind of addition is an extremely bad manner, I'm fine to
> revert these (at best with a better alternative).  This isn't about
> any functionality but rather some readable information that isn't a
> part of API.
>
The motivation for adding custom sound card name is following,
1. When for boards, multiple HDMI/DP ports are exposed, it is sometimes
    necessary to know the default port or any customization for that matter.
    Audio userspace can distinguish based on the sound card names.
2. Multiple sound cards can coexist for a platform, the indication of 
particular
    audio path is useful.
3. It can help to customize audio paths.
    Generally people use "*,model" property in DT to name the sound complex.
    Ex: "samsung,model" [sound/soc/samsung/snow.c]
        "rockchip,model" [sound/soc/rockchip/rockchip_rt5645.c]

Thanks,
Sameer.
> thanks,
>
> Takashi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-02-25 11:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-25  1:36 linux-next: manual merge of the sound tree with the arm-soc tree Stephen Rothwell
2019-02-25  9:19 ` Arnd Bergmann
2019-02-25 11:14   ` Takashi Iwai
2019-02-25 11:24     ` Sameer Pujar [this message]
2019-02-25 13:38       ` Arnd Bergmann
2019-02-25 16:43         ` Mark Brown
2023-02-17  0:23 Stephen Rothwell
2023-02-20 22:27 ` Stephen Rothwell
2023-02-21 22:12   ` Stephen Rothwell

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=e2aaed45-0fb1-c9c8-76d4-3b97b36cada6@nvidia.com \
    --to=spujar@nvidia.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=sfr@canb.auug.org.au \
    --cc=tiwai@suse.de \
    --cc=treding@nvidia.com \
    /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).