Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4223704imm; Mon, 30 Jul 2018 10:42:07 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf6gyapzSc+JFrUC5BDZ1xAL3GLkSHrsRlsT9wEryu/F5sC9eTikjrQl3SID0N8oyQxI3/6 X-Received: by 2002:a17:902:d716:: with SMTP id w22-v6mr17101161ply.98.1532972527598; Mon, 30 Jul 2018 10:42:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532972527; cv=none; d=google.com; s=arc-20160816; b=NbBRrrYvw0HW6dCMoeQFsSASz5Pe82jEXccCwumZo2XQBieonw19egxMt1Sqd/06l+ JwMAfhFxYEIDI5TpOH5tSlbK15aAU+PqMvPUi3Z9eLOYkHacyhG6VsqW+5Hnr2r0EiAR cDC6ZEPNIwz1Xs9tybPxwwQ1Pg63yuXL0P0TlOItDYQ+0uBvTTX2N+dzO9bCa/Xfb/F5 UUbI9oP4wSxBmMXBD06PLT6qLag2kuDXLstDxUPKvwkuXvTkTYkR8Cwww1klTvMTp6In M/KW2rF66YZ67FA0LCnHQ9eM+uMEqjm/N+oeBH1NUfi6ujhwNPXooOvFaMiEdnJZsSaE R4ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:arc-authentication-results; bh=vqIoOBqksBMS28U038G+9kVo2qBAYYpcWitIh7dpysY=; b=e1w//+LUczXKMGrWeNGqCfYo2nfACI8BDJeFwTEW0UGpEQuWUH7Fj6LKfmfXLM6pBE OA1M8MU3QPvxXzqBRExtn68mwIGdE/EH0c+obeh0tcuLduG1FH3McEv+uHJM3zoMKclI cjXOvIZMb1tiQ92hCIDGgjFqpubok+7fRsBTpPCfpDqbCepBW0LqtnraNDI+MEIIypWG Loos8QEGusmOD77vHzO9YaPEkOXYKRRAinIGJ9LtaPdFqKLO6v07RbgdC1HAmS6o828g NvuN7DYY/4lWfipJ/oLQG7XAhY4/sW4zXtSHiLM4CnMp9nRuuZOWHQ4RMMAoG1oW68Wr 1bpA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f7-v6si10048572pgp.496.2018.07.30.10.41.53; Mon, 30 Jul 2018 10:42:07 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731851AbeG3TQB (ORCPT + 99 others); Mon, 30 Jul 2018 15:16:01 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:46204 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727037AbeG3TQB (ORCPT ); Mon, 30 Jul 2018 15:16:01 -0400 Received: from [192.168.122.135] (helo=_) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1fkC9A-0003nV-Hq; Mon, 30 Jul 2018 18:39:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 30 Jul 2018 18:39:52 +0100 From: Ben Dooks To: Mark Brown Cc: Jon Hunter , linux-kernel@lists.codethink.co.uk, alsa-devel@alsa-project.org, lgirdwood@gmail.com, linux-kernel@vger.kernel.org, thierry.reding@gmail.com, linux-tegra@vger.kernel.org Subject: Re: [Linux-kernel] [PATCH 2/4] ASoC: tegra: Add a TDM configuration callback In-Reply-To: <20180730150749.GK5789@sirena.org.uk> References: <20180727125931.9794-1-jorge.sanjuan@codethink.co.uk> <20180727125931.9794-3-jorge.sanjuan@codethink.co.uk> <2392df6f-12bc-74fe-ec0f-50dbb7b9a33a@nvidia.com> <20180730101800.GF5789@sirena.org.uk> <2a91268d-351b-d342-42bd-8ffbf33a316e@nvidia.com> <20180730150749.GK5789@sirena.org.uk> Message-ID: X-Sender: ben.dooks@codethink.co.uk User-Agent: Roundcube Webmail/1.1.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-07-30 16:07, Mark Brown wrote: > On Mon, Jul 30, 2018 at 03:04:46PM +0100, Jon Hunter wrote: >> On 30/07/18 11:18, Mark Brown wrote: > >> > DSP modes only care about the rising edge of the LRCLK, the pulse can be >> > any width without causing interoperability problems. > >> OK, thanks I was not able to find a spec that defines this, but I saw >> a >> lot of codecs use a single bit clock width. So then equally making the >> default '1' should also be fine. > > There's not really a spec for this, it's just what tends to be > implemented. > >> I still do not like configuring the fsync width in this function. The >> fsync width needs to be configured for both DSP modes and normal I2S >> modes and so it seems it would be more appropriate to do this in the >> hw_params function for this driver. > > You *could* just always use the I2S width, it's going to look odd when > people use a scope but it will work most of the time. We did this as we were dealing with a legacy system in which we didn't know if this was important setting or not, so we tried to make the settings as close as possible to the original nvidia supplied source. -- Ben