Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1137207pxu; Wed, 6 Jan 2021 13:24:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJwES2CblUKYKXT3KTWO+c34TrIv81DUlXAikXk+MJbvwFrQHOJ8+HsffP5V1r1Aqisf3Ooy X-Received: by 2002:a17:906:d19b:: with SMTP id c27mr4339683ejz.234.1609968248040; Wed, 06 Jan 2021 13:24:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609968248; cv=none; d=google.com; s=arc-20160816; b=HeW7PVdylN2LDHfkVNzliJRd8Xjlqbv2ZiGZHLPaWaU8OkRHfd+6jcPbc9D8jP4u71 1bkoquwi3aRr+HOgkPX7IxYqBWfNiNrziosrAU8paCdswCcg5igaEGfCEjD+6ngUpoHc N9tpSzTmr1vpm0T1AgokCgckBI+UxKnr1QPm5JFmJis/LuTsxyCQCLNRSn/X71I5seSM oWdd7/tr24mw7zdQROEVv91XywvjyspEFpHYItFyNuGn97YIoHdUFxGPFnhl4uNc2Cr0 tg9n7KLBzbUUVdO4AVoSvf1DcY+51imHu6pWOlloCiXtQlep3WxafIya2v40ONUq04yX T2Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=+kJUG3qmiqeI4v/rmszW5dftC3twkY4ThLEn2qVvnz0=; b=rtXUYa4u+iw/gKOK5JxwYThOmD1/2eO1GHQmR+4AYojLlcBWmyVFYRtKllouhdREnF /ljLG+D+RHnrJLaw5YXm4fUNfSA9PNJ5YoauLG/eca2FAKbj+8icKinbuKKEAW1aFsTv EnrigzbIl6HCB+A+Om9aPTsTGu8rrtlRk9ssb/ieq6jaXG9pWjfCegcfePv2PcUsH0cc taenjgkRy8ozIMwD77gLQbn09c+ZKsu05XE4yCJKWSzWlThbmTzv6b+IFHA7wvKR2LAE Z3YMrLxWJs3jDBGN5HgNQnTnLRC+sZgafr6WHFukR362GrgB0CutIVvluttb/se+q311 3pcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=U6s8cl75; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lm18si1339577ejb.160.2021.01.06.13.23.44; Wed, 06 Jan 2021 13:24:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=U6s8cl75; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726300AbhAFVWf (ORCPT + 99 others); Wed, 6 Jan 2021 16:22:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725788AbhAFVWe (ORCPT ); Wed, 6 Jan 2021 16:22:34 -0500 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 721F6C061575; Wed, 6 Jan 2021 13:21:54 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id j16so5788430edr.0; Wed, 06 Jan 2021 13:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kJUG3qmiqeI4v/rmszW5dftC3twkY4ThLEn2qVvnz0=; b=U6s8cl75dKrBs9QfcuFlDuFoqgtm4dXCWSl/9JbH5m46Fu+a0bBYgVgnZAzr0BgCG8 XOJL3WifF7TNjqWD/qF/zFaDNFkH46Oj2ZjN49gnAQzEnK3lGX45T2HRhwSrFEIC/B5b ojdBtbHJnTuPAmXOvQ9EtDY7hya91o5Xo/IWf+JRw2070ynd9fD4fNwDsy0B/qLy/nBf cgEGpx0o8Rw2yzavl/j7pWYZxoxtJnkbqwWIjTwUChRA2FUlC3PdiZcdNP4AJAKZieht 9ZlKUWlOLIj4nwZg1SeUIG1jjQT4cXwhOYcPKJpBPe7ETJxzQav7/NWcgHt93m0DvtoF BloQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+kJUG3qmiqeI4v/rmszW5dftC3twkY4ThLEn2qVvnz0=; b=kGGFb00Ruy1tpQPIkWSDmN3QF69JSabNBXE0mxjYzOOPrzl1opC5Us4ik7P4jlc1uV Phez3SXMICitCdqszvSxv6zBvM+WmUAv9QkNZX/bhYF5N6qBYWOfoAFztPirbxshoESJ llFHzpnQlKPOTyT1hfSFZd5xQdonO3tcnFVnNcNfLH9h6EnTqaLyuH34/6M/Lp/GNPGz 98q9AkBYvbnAoIi8vKUGj8+oEgGbpUWXAilsTW0RPvf8Pb288/4je98r6xjFo13VZsPy dp16Cm03fqE8hP7JRf0NpsYQ4+d/e4wYvXPfEVMqZEchq09w2s9Ir0y+yp1S5HAiAMb4 mGrA== X-Gm-Message-State: AOAM531EPNTkE2ey0jlGD6XAsIKVGrSrEmW0dkqyD8SkrOOuiQuRH2k6 iL+ABHgIUY1ZcuxJgExXXQG++odOPl2g9trbMD3wKv31ca24tP0ZlcU= X-Received: by 2002:aa7:d846:: with SMTP id f6mr5217613eds.55.1609968112943; Wed, 06 Jan 2021 13:21:52 -0800 (PST) MIME-Version: 1.0 References: <20201225012025.507803-1-pgwipeout@gmail.com> <20201225012025.507803-3-pgwipeout@gmail.com> <0c3665b2-bac6-546a-bdd4-0ab7a90adf7c@nvidia.com> In-Reply-To: <0c3665b2-bac6-546a-bdd4-0ab7a90adf7c@nvidia.com> From: Peter Geis Date: Wed, 6 Jan 2021 16:21:41 -0500 Message-ID: Subject: Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc To: Sameer Pujar Cc: Michael Turquette , Stephen Boyd , Peter De Schrijver , Prashant Gaikwad , Thierry Reding , Jonathan Hunter , Jaroslav Kysela , Takashi Iwai , Mohan Kumar , linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, Ion Agorria Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 5, 2021 at 1:30 AM Sameer Pujar 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 > > Tested-by: Ion Agorria > > --- > > 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 > > >