From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D5E4C433EF for ; Sat, 16 Oct 2021 15:50:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0DEFD6101D for ; Sat, 16 Oct 2021 15:50:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239638AbhJPPwr (ORCPT ); Sat, 16 Oct 2021 11:52:47 -0400 Received: from gloria.sntech.de ([185.11.138.130]:45836 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231824AbhJPPwp (ORCPT ); Sat, 16 Oct 2021 11:52:45 -0400 Received: from p508fce7c.dip0.t-ipconnect.de ([80.143.206.124] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mblx1-0007WI-5i; Sat, 16 Oct 2021 17:50:23 +0200 From: Heiko Stuebner To: Nicolas Frattaroli , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , Philipp Zabel , Nicolas Frattaroli Cc: linux-rockchip@lists.infradead.org, alsa-devel@alsa-project.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] ASoC: rockchip: i2s-tdm: Strip out direct CRU use Date: Sat, 16 Oct 2021 17:50:22 +0200 Message-ID: <1782571.1Dz21PRzoM@phil> In-Reply-To: <20211016105354.116513-2-frattaroli.nicolas@gmail.com> References: <20211016105354.116513-1-frattaroli.nicolas@gmail.com> <20211016105354.116513-2-frattaroli.nicolas@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Samstag, 16. Oktober 2021, 12:53:50 CEST schrieb Nicolas Frattaroli: > In cases where both rx and tx lrck are synced to the same source, > the resets for rx and tx need to be triggered simultaneously, > according to the downstream driver. > > As there is no reset API to atomically bulk (de)assert two resets > at once, what the driver did was implement half a reset controller > specific to Rockchip, which tried to write the registers for the > resets within one write ideally or several writes within an irqsave > section. > > This of course violates abstractions quite badly. The driver should > not write to the CRU's registers directly. > > In practice, for the cases I tested the driver with, which is audio > playback, replacing the synchronised asserts with just individual > ones does not seem to make any difference. > > If it turns out that this breaks something in the future, it should > be fixed through the specification and implementation of an atomic > bulk reset API, not with a CRU hack. > > Signed-off-by: Nicolas Frattaroli Reviewed-by: Heiko Stuebner