Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
To:     "Lu, Brent" <brent.lu@intel.com>,
        Adam Thomson <Adam.Thomson.Opensource@diasemi.com>,
        "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
CC:     Support Opensource <Support.Opensource@diasemi.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Mark Brown <broonie@kernel.org>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] ASoC: da7219: remove SRM lock check retry
Thread-Topic: [PATCH] ASoC: da7219: remove SRM lock check retry
Thread-Index: AQHVqaxDP6cBrmECm0aX2T25rtDQx6eoJvjggAAPtwCAAAQYEA==
Date:   Tue, 3 Dec 2019 10:57:44 +0000
Message-ID: <AM5PR1001MB09946C295B8DAD5F9C8D191080420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
References: <1575358265-17905-1-git-send-email-brent.lu@intel.com>
 <AM5PR1001MB0994EB497D3BC7D0F4C6FD9080420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
 <CF33C36214C39B4496568E5578BE70C7403CA7B2@PGSMSX108.gar.corp.intel.com>
In-Reply-To: <CF33C36214C39B4496568E5578BE70C7403CA7B2@PGSMSX108.gar.corp.intel.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [165.225.80.228]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ac2d88cd-086b-4d90-c5cb-08d777dfa070
x-ms-traffictypediagnostic: AM5PR1001MB1140:
x-ms-exchange-sharedmailbox-routingagent-processed: True
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM5PR1001MB11407788D6C20771D3FF179CA7420@AM5PR1001MB1140.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02408926C4
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(136003)(396003)(39860400002)(346002)(366004)(376002)(199004)(189003)(99286004)(6506007)(25786009)(14454004)(76176011)(52536014)(316002)(966005)(8936002)(81166006)(110136005)(8676002)(478600001)(54906003)(4326008)(74316002)(86362001)(6246003)(81156014)(7736002)(305945005)(2501003)(76116006)(229853002)(5660300002)(446003)(3846002)(33656002)(66946007)(9686003)(6116002)(55016002)(6306002)(66556008)(6436002)(11346002)(66446008)(66476007)(186003)(64756008)(256004)(14444005)(2906002)(102836004)(71190400001)(55236004)(53546011)(7696005)(71200400001)(26005);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR1001MB1140;H:AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:0;MX:1;
received-spf: None (protection.outlook.com: diasemi.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xTyDvUMwp1shUYml2fgCzU2RoFLuNpIYa2AiZ489gs5iSxbBhmyggZVLi7bQzcr7JXZzaD/uh5daFPiSfxROLXHL+0RNNyrsQDBJ9LPJwT+w5NKgoPA3ciDOiUzE2/UiiH0jsOcVsELvBOHDyzCnT2e/vPgMCoip18odfcSqtUCuQwfVer5m4fydWzkPmTrs+wWEkTzz+CaMky48sITdClvn95s0ZBEvvcHZq0XVR6YcxGyLUte1DPCqglNt1Te/Ox7xALNRLmMgQxNUCuEMQUHA6batrNphTbRhjmbGJEu7HBnRmRmiZ8AMSgk+EiYc/6tRX9BzYHxfvQSkywkdw+eBDHmnM2FkdBMx2PMGoVCA4n5qLZsaOntXoYcRbFhrN19tqrsgjYO1eVCztjMTb/ageoZWwJd3xgR8I3rjZ9eXIoIZ1xtQ3E/SYKT0HEcWg0hL3b7bbm9jrINIsg9ABvYvQnDaPjMi/cc0i72syUU=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: diasemi.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ac2d88cd-086b-4d90-c5cb-08d777dfa070
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2019 10:57:44.7412
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 511e3c0e-ee96-486e-a2ec-e272ffa37b7c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QxWzkHEj0WRmqeYM4PQNKy38Floubko2VSDGbrhV5HCwhAgXleSI2RirS6fsn3BlOgxpSWGYOYnKeChPmPEy82Fd6Rlaw6CnG3VpGgY4knU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR1001MB1140
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03 December 2019 10:33, Brent Lu wrote:

> > We can potentially reduce the timings here for something shorter althou=
gh
> > I'd need to speak with the HW team as to what, if any reduction is feas=
ible.
> > However this is not a real fix as there's potential for audible noises =
when you
> > don't enable WCLK first. As far as I can tell the Intel platforms are c=
apable of
> > enabling clocks early, as can be seen in this board file with early SCL=
K enable:
> >
> > https://elixir.bootlin.com/linux/latest/source/sound/soc/intel/boards/k=
bl_rt
> > 5663_max98927.c#L99
> >
> > I think there's a need to find some method to enable the WCLK signal
> > otherwise there's the potential for audible artefacts when SRM finally =
locks
> > which is not going to be pleasant.
> >
>=20
> Hi Adam,
>=20
> Thanks for reply. This patch is not fixing any bug. It just shorten the a=
udio latency
> on our boards. Basically we are idling there for 400ms then print a warni=
ng
> message
> about SRM not being locked. It seems to me that 400ms is too much even fo=
r
> those
> platforms which are able to provide WCLK before calling snd_soc_dai_set_p=
ll()
> function but it relies on your HW team to provide the number.

But on platforms where they can enable the WCLK early they shouldn't be loo=
ping
around here for anything like 400ms. In an ideal world when that widget is
run SRM should hopefully be already locked but the code does allow for some
delay. Actually, having a long delay also helps show the user that somethin=
g
isn't right here so I'm somewhat loathed to change this.

Even if you do reduce the retry timings what you're still not protecting
against is the possibility of audio artefacts when SRM finally locks. You w=
ant
this to lock before the any of the audio path is up so I think we need to f=
ind
a way to resolve that rather than relying on getting lucky with a smooth
power-up.

>=20
> On KBL platform we have interface to control MCLK and I2S clocks like the=
 link
> you mentioned but WCLK seems not working on my board. I can try to ask if
> someone is working on it but since we are moving to SOF. The chance is sl=
im for
> legacy firmware.
>=20
>=20
> Regards,
> Brent