On Wed, Jun 05, 2019 at 12:30:31PM +0100, Jon Hunter wrote: > > On 31/05/2019 15:58, Jon Hunter wrote: > > > > On 29/05/2019 14:46, Thierry Reding wrote: > >> On Wed, May 29, 2019 at 10:18:21AM +0100, Jon Hunter wrote: > >>> Currently the default clock rates for the HDA and HDA2CODEC_2X clocks > >>> are both 19.2MHz. However, the default rates for these clocks should > >>> actually be 51MHz and 48MHz, respectively. Correct the default clock > >>> rates for these clocks by specifying them in the clock init table for > >>> Tegra210. > >>> > >>> Signed-off-by: Jon Hunter <jonathanh@xxxxxxxxxx> > >>> --- > >>> drivers/clk/tegra/clk-tegra210.c | 2 ++ > >>> 1 file changed, 2 insertions(+) > >> > >> Does this fix anything? Should this be backported to stable releases? > > > > Good point. We are aligning the clock configuration with what we ship. > > So I thought for completeness it would be good to test HDA playback > > across the various sample-rates we support (32kHz to 192kHz) but with or > > without this patch I am not hearing anything. Let me check on this with > > Sameer as I would like to see if we need to mark this for stable or not. > > > >> Acked-by: Thierry Reding <treding@xxxxxxxxxx> > > I have confirmed that this does fix HDA playback on Tegra210. Without > this fix, I am seeing the following messages during playback and > playback is distorted ... > > Write error: -32,Broken pipe > [ 15.069335] tegra-mc 70019000.memory-controller: hdar: read > @0x0000000000000000: EMEM address decode error (EMEM decode error) > Write error: -32,Broken pipe > [ 15.465362] tegra-mc 70019000.memory-controller: hdar: read > @0x0000000000000000: EMEM address decode error (EMEM decode error) > Write error: -32,Broken pipe > [ 15.858615] tegra-mc 70019000.memory-controller: hdar: read > @0x0000000000000000: EMEM address decode error (EMEM decode error) > W > > Do you want me to update the change and resend? Honestly I'm not sure if it's worth it. I haven't seen any bug reports for this and we haven't had audio over HDMI support for very long, so a backport may not be necessary. I guess there'd be some use to backport this so that our stable kernel testing passes these. So it's really up to you. I have a slight tendency towards backporting, because it's really tiny and then we just have it out of the way and it's not going to haunt us. Thierry
Attachment:
signature.asc
Description: PGP signature
