* [PATCH 1/2] clk: tegra30: Add hda clock default rates to clock driver
2020-12-25 1:20 [PATCH 0/2] fix tegra-hda on tegra30 devices Peter Geis
@ 2020-12-25 1:20 ` Peter Geis
2021-01-05 10:12 ` Jon Hunter
2020-12-25 1:20 ` [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc Peter Geis
2021-01-04 14:25 ` [PATCH 0/2] fix tegra-hda on tegra30 devices Takashi Iwai
2 siblings, 1 reply; 11+ messages in thread
From: Peter Geis @ 2020-12-25 1:20 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Peter De Schrijver,
Prashant Gaikwad, Thierry Reding, Jonathan Hunter,
Jaroslav Kysela, Takashi Iwai, Sameer Pujar, Mohan Kumar
Cc: alsa-devel, linux-kernel, Ion Agorria, Peter Geis, linux-tegra,
linux-clk
Current implementation defaults the hda clocks to clk_m.
This causes hda to run too slow to operate correctly.
Fix this by defaulting to pll_p and setting the frequency to the correct rate.
This matches upstream t124 and downstream t30.
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Tested-by: Ion Agorria <ion@agorria.com>
---
drivers/clk/tegra/clk-tegra30.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 37244a7e68c2..9cf249c344d9 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1256,6 +1256,8 @@ static struct tegra_clk_init_table init_table[] __initdata = {
{ TEGRA30_CLK_I2S3_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
{ TEGRA30_CLK_I2S4_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
{ TEGRA30_CLK_VIMCLK_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
+ { TEGRA30_CLK_HDA, TEGRA30_CLK_PLL_P, 102000000, 0 },
+ { TEGRA30_CLK_HDA2CODEC_2X, TEGRA30_CLK_PLL_P, 48000000, 0 },
/* must be the last entry */
{ TEGRA30_CLK_CLK_MAX, TEGRA30_CLK_CLK_MAX, 0, 0 },
};
--
2.25.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH 1/2] clk: tegra30: Add hda clock default rates to clock driver
2020-12-25 1:20 ` [PATCH 1/2] clk: tegra30: Add hda clock default rates to clock driver Peter Geis
@ 2021-01-05 10:12 ` Jon Hunter
0 siblings, 0 replies; 11+ messages in thread
From: Jon Hunter @ 2021-01-05 10:12 UTC (permalink / raw)
To: Peter Geis, Michael Turquette, Stephen Boyd, Peter De Schrijver,
Prashant Gaikwad, Thierry Reding, Jaroslav Kysela, Takashi Iwai,
Sameer Pujar, Mohan Kumar
Cc: linux-tegra, alsa-devel, Ion Agorria, linux-clk, linux-kernel
On 25/12/2020 01:20, Peter Geis wrote:
> Current implementation defaults the hda clocks to clk_m.
> This causes hda to run too slow to operate correctly.
> Fix this by defaulting to pll_p and setting the frequency to the correct rate.
>
> This matches upstream t124 and downstream t30.
>
> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> Tested-by: Ion Agorria <ion@agorria.com>
> ---
> drivers/clk/tegra/clk-tegra30.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
> index 37244a7e68c2..9cf249c344d9 100644
> --- a/drivers/clk/tegra/clk-tegra30.c
> +++ b/drivers/clk/tegra/clk-tegra30.c
> @@ -1256,6 +1256,8 @@ static struct tegra_clk_init_table init_table[] __initdata = {
> { TEGRA30_CLK_I2S3_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
> { TEGRA30_CLK_I2S4_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
> { TEGRA30_CLK_VIMCLK_SYNC, TEGRA30_CLK_CLK_MAX, 24000000, 0 },
> + { TEGRA30_CLK_HDA, TEGRA30_CLK_PLL_P, 102000000, 0 },
> + { TEGRA30_CLK_HDA2CODEC_2X, TEGRA30_CLK_PLL_P, 48000000, 0 },
> /* must be the last entry */
> { TEGRA30_CLK_CLK_MAX, TEGRA30_CLK_CLK_MAX, 0, 0 },
> };
This looks good to me. So ...
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
2020-12-25 1:20 [PATCH 0/2] fix tegra-hda on tegra30 devices Peter Geis
2020-12-25 1:20 ` [PATCH 1/2] clk: tegra30: Add hda clock default rates to clock driver Peter Geis
@ 2020-12-25 1:20 ` Peter Geis
2021-01-05 6:30 ` Sameer Pujar
2021-01-04 14:25 ` [PATCH 0/2] fix tegra-hda on tegra30 devices Takashi Iwai
2 siblings, 1 reply; 11+ messages in thread
From: Peter Geis @ 2020-12-25 1:20 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Peter De Schrijver,
Prashant Gaikwad, Thierry Reding, Jonathan Hunter,
Jaroslav Kysela, Takashi Iwai, Sameer Pujar, Mohan Kumar
Cc: alsa-devel, linux-kernel, Ion Agorria, Peter Geis, linux-tegra,
linux-clk
Currently hda on tegra30 fails to open a stream with an input/output error.
This is similar to the issue referenced in [1].
For example:
speaker-test -Dhw:0,3 -c 2
speaker-test 1.2.2
Playback device is hw:0,3
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 16384
Period size range from 32 to 8192
Using max buffer size 16384
Periods = 4
was set period_size = 4096
was set buffer_size = 16384
0 - Front Left
Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Input/output error
[1] states "Due to a legacy HW design problem", implying the issue applies to all previous tegra-hda devices.
The tegra-hda device was introduced in tegra30 but only utilized in tegra124 until now.
For this reason it is unknown when this issue first manifested.
Applying the fix in [1] universally resolves this issue on tegra30.
Tested on the Ouya game console and the tf201 tablet.
[1] 60019d8c650d ("ALSA: hda/tegra: workaround playback failure on Tegra194")
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Tested-by: Ion Agorria <ion@agorria.com>
---
sound/pci/hda/hda_tegra.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
index 70164d1428d4..f8d61e677a09 100644
--- a/sound/pci/hda/hda_tegra.c
+++ b/sound/pci/hda/hda_tegra.c
@@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx *chip, struct platform_device *pdev)
* in powers of 2, next available ratio is 16 which can be
* used as a limiting factor here.
*/
- if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
- chip->bus.core.sdo_limit = 16;
+ chip->bus.core.sdo_limit = 16;
/* codec detection */
if (!bus->codec_mask) {
--
2.25.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
2020-12-25 1:20 ` [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc Peter Geis
@ 2021-01-05 6:30 ` Sameer Pujar
2021-01-06 21:21 ` Peter Geis
0 siblings, 1 reply; 11+ messages in thread
From: Sameer Pujar @ 2021-01-05 6:30 UTC (permalink / raw)
To: Peter Geis, Michael Turquette, Stephen Boyd, Peter De Schrijver,
Prashant Gaikwad, Thierry Reding, Jonathan Hunter,
Jaroslav Kysela, Takashi Iwai, Mohan Kumar
Cc: linux-tegra, alsa-devel, Ion Agorria, linux-clk, linux-kernel
On 12/25/2020 6:50 AM, Peter Geis wrote:
> External email: Use caution opening links or attachments
>
>
> Currently hda on tegra30 fails to open a stream with an input/output error.
> This is similar to the issue referenced in [1].
>
> For example:
> speaker-test -Dhw:0,3 -c 2
>
> speaker-test 1.2.2
>
> Playback device is hw:0,3
> Stream parameters are 48000Hz, S16_LE, 2 channels
> Using 16 octaves of pink noise
> Rate set to 48000Hz (requested 48000Hz)
> Buffer size range from 64 to 16384
> Period size range from 32 to 8192
> Using max buffer size 16384
> Periods = 4
> was set period_size = 4096
> was set buffer_size = 16384
> 0 - Front Left
> Write error: -5,Input/output error
> xrun_recovery failed: -5,Input/output error
> Transfer failed: Input/output error
>
> [1] states "Due to a legacy HW design problem", implying the issue applies to all previous tegra-hda devices.
> The tegra-hda device was introduced in tegra30 but only utilized in tegra124 until now.
> For this reason it is unknown when this issue first manifested.
>
> Applying the fix in [1] universally resolves this issue on tegra30.
> Tested on the Ouya game console and the tf201 tablet.
>
> [1] 60019d8c650d ("ALSA: hda/tegra: workaround playback failure on Tegra194")
This issue was never seen on Tegra210/Tegra186 and hence at that time it
was thought to be specific to Tegra194. I never tested this on Tegra30
since I don't have this device. I will clarify this with HW folks if
workaround is safer for all chips.
>
> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> Tested-by: Ion Agorria <ion@agorria.com>
> ---
> sound/pci/hda/hda_tegra.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
> index 70164d1428d4..f8d61e677a09 100644
> --- a/sound/pci/hda/hda_tegra.c
> +++ b/sound/pci/hda/hda_tegra.c
> @@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx *chip, struct platform_device *pdev)
> * in powers of 2, next available ratio is 16 which can be
> * used as a limiting factor here.
> */
> - if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
> - chip->bus.core.sdo_limit = 16;
> + chip->bus.core.sdo_limit = 16;
Future Tegra chips address this problem and hence cannot be enforced by
default. May be we can have like below:
if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
chip->bus.core.sdo_limit = 16;
>
> /* codec detection */
> if (!bus->codec_mask) {
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
2021-01-05 6:30 ` Sameer Pujar
@ 2021-01-06 21:21 ` Peter Geis
2021-01-08 8:00 ` Sameer Pujar
0 siblings, 1 reply; 11+ messages in thread
From: Peter Geis @ 2021-01-06 21:21 UTC (permalink / raw)
To: Sameer Pujar
Cc: alsa-devel, Prashant Gaikwad, Mohan Kumar, Stephen Boyd,
linux-kernel, Michael Turquette, linux-clk, Takashi Iwai,
Jonathan Hunter, Thierry Reding, Ion Agorria, linux-tegra,
Peter De Schrijver
On Tue, Jan 5, 2021 at 1:30 AM Sameer Pujar <spujar@nvidia.com> wrote:
>
>
>
> On 12/25/2020 6:50 AM, Peter Geis wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > Currently hda on tegra30 fails to open a stream with an input/output error.
> > This is similar to the issue referenced in [1].
> >
> > For example:
> > speaker-test -Dhw:0,3 -c 2
> >
> > speaker-test 1.2.2
> >
> > Playback device is hw:0,3
> > Stream parameters are 48000Hz, S16_LE, 2 channels
> > Using 16 octaves of pink noise
> > Rate set to 48000Hz (requested 48000Hz)
> > Buffer size range from 64 to 16384
> > Period size range from 32 to 8192
> > Using max buffer size 16384
> > Periods = 4
> > was set period_size = 4096
> > was set buffer_size = 16384
> > 0 - Front Left
> > Write error: -5,Input/output error
> > xrun_recovery failed: -5,Input/output error
> > Transfer failed: Input/output error
> >
> > [1] states "Due to a legacy HW design problem", implying the issue applies to all previous tegra-hda devices.
> > The tegra-hda device was introduced in tegra30 but only utilized in tegra124 until now.
> > For this reason it is unknown when this issue first manifested.
> >
> > Applying the fix in [1] universally resolves this issue on tegra30.
> > Tested on the Ouya game console and the tf201 tablet.
> >
> > [1] 60019d8c650d ("ALSA: hda/tegra: workaround playback failure on Tegra194")
>
> This issue was never seen on Tegra210/Tegra186 and hence at that time it
> was thought to be specific to Tegra194. I never tested this on Tegra30
> since I don't have this device. I will clarify this with HW folks if
> workaround is safer for all chips.
So this is confirmed to not affect Tegra210 and Tegra186, but it does
affect Tegra194 and Tegra30.
Is it possible for the hardware team to pitch on on where the fix was
implemented?
>
> >
> > Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> > Tested-by: Ion Agorria <ion@agorria.com>
> > ---
> > sound/pci/hda/hda_tegra.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
> > index 70164d1428d4..f8d61e677a09 100644
> > --- a/sound/pci/hda/hda_tegra.c
> > +++ b/sound/pci/hda/hda_tegra.c
> > @@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx *chip, struct platform_device *pdev)
> > * in powers of 2, next available ratio is 16 which can be
> > * used as a limiting factor here.
> > */
> > - if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
> > - chip->bus.core.sdo_limit = 16;
> > + chip->bus.core.sdo_limit = 16;
>
> Future Tegra chips address this problem and hence cannot be enforced by
> default. May be we can have like below:
>
> if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
> chip->bus.core.sdo_limit = 16;
>
It will need to be a bit more complicated than that, since the
tegra186 and tegra210 device trees have "nvidia,tegra30-hda" as a
fallback.
Looking at the generation map, tegra30-hda can be the fallback for the
broken implementation and tegra210-hda can be the fallback for the
working implementation.
Does that work for you?
> >
> > /* codec detection */
> > if (!bus->codec_mask) {
> > --
> > 2.25.1
> >
>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
2021-01-06 21:21 ` Peter Geis
@ 2021-01-08 8:00 ` Sameer Pujar
2021-01-08 10:54 ` Jon Hunter
0 siblings, 1 reply; 11+ messages in thread
From: Sameer Pujar @ 2021-01-08 8:00 UTC (permalink / raw)
To: Peter Geis
Cc: alsa-devel, Prashant Gaikwad, Mohan Kumar, Stephen Boyd,
linux-kernel, Michael Turquette, linux-clk, Takashi Iwai,
Jonathan Hunter, Thierry Reding, Ion Agorria, linux-tegra,
Peter De Schrijver
On 1/7/2021 2:51 AM, Peter Geis wrote:
> External email: Use caution opening links or attachments
>
>
> On Tue, Jan 5, 2021 at 1:30 AM Sameer Pujar <spujar@nvidia.com> wrote:
>>
>>
>> On 12/25/2020 6:50 AM, Peter Geis wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Currently hda on tegra30 fails to open a stream with an input/output error.
>>> This is similar to the issue referenced in [1].
>>>
>>> For example:
>>> speaker-test -Dhw:0,3 -c 2
>>>
>>> speaker-test 1.2.2
>>>
>>> Playback device is hw:0,3
>>> Stream parameters are 48000Hz, S16_LE, 2 channels
>>> Using 16 octaves of pink noise
>>> Rate set to 48000Hz (requested 48000Hz)
>>> Buffer size range from 64 to 16384
>>> Period size range from 32 to 8192
>>> Using max buffer size 16384
>>> Periods = 4
>>> was set period_size = 4096
>>> was set buffer_size = 16384
>>> 0 - Front Left
>>> Write error: -5,Input/output error
>>> xrun_recovery failed: -5,Input/output error
>>> Transfer failed: Input/output error
>>>
>>> [1] states "Due to a legacy HW design problem", implying the issue applies to all previous tegra-hda devices.
>>> The tegra-hda device was introduced in tegra30 but only utilized in tegra124 until now.
>>> For this reason it is unknown when this issue first manifested.
>>>
>>> Applying the fix in [1] universally resolves this issue on tegra30.
>>> Tested on the Ouya game console and the tf201 tablet.
>>>
>>> [1] 60019d8c650d ("ALSA: hda/tegra: workaround playback failure on Tegra194")
>> This issue was never seen on Tegra210/Tegra186 and hence at that time it
>> was thought to be specific to Tegra194. I never tested this on Tegra30
>> since I don't have this device. I will clarify this with HW folks if
>> workaround is safer for all chips.
> So this is confirmed to not affect Tegra210 and Tegra186, but it does
> affect Tegra194 and Tegra30.
> Is it possible for the hardware team to pitch on on where the fix was
> implemented?
I discussed this with HW team. The issue is applicable to all Tegra chips.
Below is the striping formula referenced from HD audio spec.
{ ((num_channels * bits_per_sample) / number of SDOs) >= 8 }
The current issue is seen because Tegra HW has a problem with boundary
condition (= 8) for striping. The reason why it is not seen on
Tegra210/Tegra186 is because it uses max 2SDO lines. Max SDO lines is
read from GCAP register.
For the given stream (channels = 2, bps = 16);
ratio = (channels * bps) / NSDO = 32 / NSDO;
On Tegra30, ratio = 32/4 = 8 (FAIL)
On Tegra210/186, ratio = 32/2 = 16 (PASS)
On Tegra194, ratio = 32/4 = 8 (FAIL) ==> Earlier workaround was
applied for it
If Tegra210/186 is forced to use 4SDO, it fails there as well. So the
behavior is consistent across all these chips.
>>> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
>>> Tested-by: Ion Agorria <ion@agorria.com>
>>> ---
>>> sound/pci/hda/hda_tegra.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
>>> index 70164d1428d4..f8d61e677a09 100644
>>> --- a/sound/pci/hda/hda_tegra.c
>>> +++ b/sound/pci/hda/hda_tegra.c
>>> @@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx *chip, struct platform_device *pdev)
>>> * in powers of 2, next available ratio is 16 which can be
>>> * used as a limiting factor here.
>>> */
>>> - if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
>>> - chip->bus.core.sdo_limit = 16;
>>> + chip->bus.core.sdo_limit = 16;
>> Future Tegra chips address this problem and hence cannot be enforced by
>> default. May be we can have like below:
>>
>> if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
>> chip->bus.core.sdo_limit = 16;
>>
> It will need to be a bit more complicated than that, since the
> tegra186 and tegra210 device trees have "nvidia,tegra30-hda" as a
> fallback.
> Looking at the generation map, tegra30-hda can be the fallback for the
> broken implementation and tegra210-hda can be the fallback for the
> working implementation.
> Does that work for you?
As per above explanation, it is fine to apply the workaround for
Tegra210/186 as well. So it simplifies things for all existing chips.
>>> /* codec detection */
>>> if (!bus->codec_mask) {
>>> --
>>> 2.25.1
>>>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
2021-01-08 8:00 ` Sameer Pujar
@ 2021-01-08 10:54 ` Jon Hunter
2021-01-08 11:33 ` Jon Hunter
0 siblings, 1 reply; 11+ messages in thread
From: Jon Hunter @ 2021-01-08 10:54 UTC (permalink / raw)
To: Sameer Pujar, Peter Geis
Cc: alsa-devel, Prashant Gaikwad, Mohan Kumar, Stephen Boyd,
linux-kernel, Michael Turquette, linux-clk, Takashi Iwai,
Thierry Reding, Ion Agorria, linux-tegra, Peter De Schrijver
On 08/01/2021 08:00, Sameer Pujar wrote:
...
>>>> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
>>>> Tested-by: Ion Agorria <ion@agorria.com>
>>>> ---
>>>> sound/pci/hda/hda_tegra.c | 3 +--
>>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>>
>>>> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
>>>> index 70164d1428d4..f8d61e677a09 100644
>>>> --- a/sound/pci/hda/hda_tegra.c
>>>> +++ b/sound/pci/hda/hda_tegra.c
>>>> @@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx
>>>> *chip, struct platform_device *pdev)
>>>> * in powers of 2, next available ratio is 16 which can be
>>>> * used as a limiting factor here.
>>>> */
>>>> - if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
>>>> - chip->bus.core.sdo_limit = 16;
>>>> + chip->bus.core.sdo_limit = 16;
>>> Future Tegra chips address this problem and hence cannot be enforced by
>>> default. May be we can have like below:
>>>
>>> if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
>>> chip->bus.core.sdo_limit = 16;
>>>
>> It will need to be a bit more complicated than that, since the
>> tegra186 and tegra210 device trees have "nvidia,tegra30-hda" as a
>> fallback.
>> Looking at the generation map, tegra30-hda can be the fallback for the
>> broken implementation and tegra210-hda can be the fallback for the
>> working implementation.
>> Does that work for you?
>
> As per above explanation, it is fine to apply the workaround for
> Tegra210/186 as well. So it simplifies things for all existing chips.
FYI ... we now have minimal support for Tegra234 in upstream that should
not require this. Given that the Tegra234 device-tree does not include
support for HDA yet, I think it is fine to apply this as-is. However,
once we do add support for Tegra234 HDA, then we should ensure that this
is not applied. So that said ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
2021-01-08 10:54 ` Jon Hunter
@ 2021-01-08 11:33 ` Jon Hunter
2021-01-08 12:19 ` Peter Geis
0 siblings, 1 reply; 11+ messages in thread
From: Jon Hunter @ 2021-01-08 11:33 UTC (permalink / raw)
To: Sameer Pujar, Peter Geis
Cc: alsa-devel, Prashant Gaikwad, Mohan Kumar, Stephen Boyd,
linux-kernel, Michael Turquette, linux-clk, Takashi Iwai,
Thierry Reding, Ion Agorria, linux-tegra, Peter De Schrijver
On 08/01/2021 10:54, Jon Hunter wrote:
>
> On 08/01/2021 08:00, Sameer Pujar wrote:
>
> ...
>
>>>>> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
>>>>> Tested-by: Ion Agorria <ion@agorria.com>
>>>>> ---
>>>>> sound/pci/hda/hda_tegra.c | 3 +--
>>>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
>>>>> index 70164d1428d4..f8d61e677a09 100644
>>>>> --- a/sound/pci/hda/hda_tegra.c
>>>>> +++ b/sound/pci/hda/hda_tegra.c
>>>>> @@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx
>>>>> *chip, struct platform_device *pdev)
>>>>> * in powers of 2, next available ratio is 16 which can be
>>>>> * used as a limiting factor here.
>>>>> */
>>>>> - if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
>>>>> - chip->bus.core.sdo_limit = 16;
>>>>> + chip->bus.core.sdo_limit = 16;
>>>> Future Tegra chips address this problem and hence cannot be enforced by
>>>> default. May be we can have like below:
>>>>
>>>> if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
>>>> chip->bus.core.sdo_limit = 16;
>>>>
>>> It will need to be a bit more complicated than that, since the
>>> tegra186 and tegra210 device trees have "nvidia,tegra30-hda" as a
>>> fallback.
>>> Looking at the generation map, tegra30-hda can be the fallback for the
>>> broken implementation and tegra210-hda can be the fallback for the
>>> working implementation.
>>> Does that work for you?
>>
>> As per above explanation, it is fine to apply the workaround for
>> Tegra210/186 as well. So it simplifies things for all existing chips.
>
>
> FYI ... we now have minimal support for Tegra234 in upstream that should
> not require this. Given that the Tegra234 device-tree does not include
> support for HDA yet, I think it is fine to apply this as-is. However,
> once we do add support for Tegra234 HDA, then we should ensure that this
> is not applied. So that said ...
>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Sorry I was chatting with Sameer offline and we think if we just switch
the test to the following then this will take care of Tegra234 when we
add it ...
if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
Peter, would you be able to send a V2 with this?
Thanks!
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc
2021-01-08 11:33 ` Jon Hunter
@ 2021-01-08 12:19 ` Peter Geis
0 siblings, 0 replies; 11+ messages in thread
From: Peter Geis @ 2021-01-08 12:19 UTC (permalink / raw)
To: Jon Hunter
Cc: alsa-devel, Prashant Gaikwad, Mohan Kumar, Stephen Boyd,
linux-kernel, Peter De Schrijver, linux-clk, Takashi Iwai,
Michael Turquette, Thierry Reding, Ion Agorria, linux-tegra,
Sameer Pujar
On Fri, Jan 8, 2021 at 6:33 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 08/01/2021 10:54, Jon Hunter wrote:
> >
> > On 08/01/2021 08:00, Sameer Pujar wrote:
> >
> > ...
> >
> >>>>> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> >>>>> Tested-by: Ion Agorria <ion@agorria.com>
> >>>>> ---
> >>>>> sound/pci/hda/hda_tegra.c | 3 +--
> >>>>> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
> >>>>> index 70164d1428d4..f8d61e677a09 100644
> >>>>> --- a/sound/pci/hda/hda_tegra.c
> >>>>> +++ b/sound/pci/hda/hda_tegra.c
> >>>>> @@ -388,8 +388,7 @@ static int hda_tegra_first_init(struct azx
> >>>>> *chip, struct platform_device *pdev)
> >>>>> * in powers of 2, next available ratio is 16 which can be
> >>>>> * used as a limiting factor here.
> >>>>> */
> >>>>> - if (of_device_is_compatible(np, "nvidia,tegra194-hda"))
> >>>>> - chip->bus.core.sdo_limit = 16;
> >>>>> + chip->bus.core.sdo_limit = 16;
> >>>> Future Tegra chips address this problem and hence cannot be enforced by
> >>>> default. May be we can have like below:
> >>>>
> >>>> if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
> >>>> chip->bus.core.sdo_limit = 16;
> >>>>
> >>> It will need to be a bit more complicated than that, since the
> >>> tegra186 and tegra210 device trees have "nvidia,tegra30-hda" as a
> >>> fallback.
> >>> Looking at the generation map, tegra30-hda can be the fallback for the
> >>> broken implementation and tegra210-hda can be the fallback for the
> >>> working implementation.
> >>> Does that work for you?
> >>
> >> As per above explanation, it is fine to apply the workaround for
> >> Tegra210/186 as well. So it simplifies things for all existing chips.
> >
> >
> > FYI ... we now have minimal support for Tegra234 in upstream that should
> > not require this. Given that the Tegra234 device-tree does not include
> > support for HDA yet, I think it is fine to apply this as-is. However,
> > once we do add support for Tegra234 HDA, then we should ensure that this
> > is not applied. So that said ...
> >
> > Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
>
>
> Sorry I was chatting with Sameer offline and we think if we just switch
> the test to the following then this will take care of Tegra234 when we
> add it ...
>
> if (of_device_is_compatible(np, "nvidia,tegra30-hda"))
>
> Peter, would you be able to send a V2 with this?
>
> Thanks!
> Jon
>
> --
> nvpublic
Certainly, thank you all!
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] fix tegra-hda on tegra30 devices
2020-12-25 1:20 [PATCH 0/2] fix tegra-hda on tegra30 devices Peter Geis
2020-12-25 1:20 ` [PATCH 1/2] clk: tegra30: Add hda clock default rates to clock driver Peter Geis
2020-12-25 1:20 ` [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc Peter Geis
@ 2021-01-04 14:25 ` Takashi Iwai
2 siblings, 0 replies; 11+ messages in thread
From: Takashi Iwai @ 2021-01-04 14:25 UTC (permalink / raw)
To: Peter Geis
Cc: alsa-devel, Prashant Gaikwad, Sameer Pujar, Stephen Boyd,
linux-kernel, Michael Turquette, linux-clk, Takashi Iwai,
Jonathan Hunter, Thierry Reding, linux-tegra, Mohan Kumar,
Peter De Schrijver
On Fri, 25 Dec 2020 02:20:24 +0100,
Peter Geis wrote:
>
> The following patches fix tegra-hda on legacy tegra devices.
> Two issues were discovered preventing tegra-hda from functioning:
> The hda clocks on tegra30 were assigned to clk_m and running at too low of a rate to function.
> The tegra-hda encounters an input/output error when opening a stream.
>
> Since the only mainline device that used tegra-hda previously was the t124, it is unknown exactly when this was broken.
> Fortunately a recent patch was submitted that fixed the issue only on t194 devices.
> We can apply it universally to the tegra-hda device to resolve the issues across the board.
> Note that downstream devices used the spdif device instead of hda for hdmi audio.
> The spdif device lacks a driver on mainline.
>
> Peter Geis (2):
> clk: tegra30: Add hda clock default rates to clock driver
> ALSA: hda/tegra: fix tegra-hda on tegra30 soc
Can Nvidia people look at those?
thanks,
Takashi
>
> drivers/clk/tegra/clk-tegra30.c | 2 ++
> sound/pci/hda/hda_tegra.c | 3 +--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 11+ messages in thread