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.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
index 34a7044927fd,39c616737232..000000000000
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
diff --cc arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
index 8780b5b3d2b9,6096dfb7e17a..000000000000
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
@@@ -1317,15 -1303,6 +1317,16 @@@
clock-frequency = <100000>;
};
+ sata@70020000 {
+ status = "okay";
+ phys = <&{/padctl@7009f000/pads/sata/lanes/sata-0}>;
+ };
+
+ hda@70030000 {
++ nvidia,model = "jetson-tx1-hda";
+ status = "okay";
+ };
+
usb@70090000 {
phys = <&{/padctl@7009f000/pads/usb2/lanes/usb2-0}>,
<&{/padctl@7009f000/pads/usb2/lanes/usb2-1}>,
On Mon, Feb 25, 2019 at 2:36 AM Stephen Rothwell <[email protected]> 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?
(added ASoC maintainers to Cc for insight).
Arnd
On Mon, 25 Feb 2019 10:19:15 +0100,
Arnd Bergmann wrote:
>
> On Mon, Feb 25, 2019 at 2:36 AM Stephen Rothwell <[email protected]> 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.
thanks,
Takashi
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 <[email protected]> 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
On Mon, Feb 25, 2019 at 12:24 PM Sameer Pujar <[email protected]> wrote:
> 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 <[email protected]> wrote:
> >> 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.
It is not extremely bad, but it is at the minimum surprising.
> 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]
I see, I had not noticed those before. They do seem a little unusual,
and inconsistent, as the samsung sames are always names the board
there, but rockchip doesn't: one board names it just "I2C", the other
one uses "VEYRON-I2S", and the example in the documentation lists
"ROCKCHIP-I2S" and "Analog audio output", each of them following
different naming systems.
In Documentation/devicetree/bindings/sound/qcom,apq8096.txt, a
"qcom,model" property is listeds as "Obsolete", and replaced by
a "model" property. This is in turn also used on amlogic, freescale,
and some samsung platforms.
My impression here is that the idea of passing a model name
through DT is well established, but for new stuff, we probably
want to standardize on plain "model" rather than "$vendor,model".
Arnd
On Mon, Feb 25, 2019 at 02:38:50PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 25, 2019 at 12:24 PM Sameer Pujar <[email protected]> wrote:
> > 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]
It's also useful since sound cards can be electically identical but
prefer different configuration due to the plastics (eg, a smaller
speaker was fitted, different outputs have different labels or playing
the speaker at full volume causes some models to have unpleasant effects
while others handle it fine).
> My impression here is that the idea of passing a model name
> through DT is well established, but for new stuff, we probably
> want to standardize on plain "model" rather than "$vendor,model".
Yes.