Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp4915735rdh; Wed, 29 Nov 2023 14:46:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IEX0zKrTAAqWjZLC71Lu8KL+GLnKoZ7pvLALk9HS/AgoMn9BzkyC1ZJCUTtkBXqdv9THrhd X-Received: by 2002:a05:6a20:da8b:b0:18d:9ac:7964 with SMTP id iy11-20020a056a20da8b00b0018d09ac7964mr5600968pzb.26.1701297966851; Wed, 29 Nov 2023 14:46:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701297966; cv=none; d=google.com; s=arc-20160816; b=iyCiUHZErQOEUxsOKvYlzZxObJnDS4CgJVPBPoFIFpHiGn/7SbNIWbKfvfMiq0fyBK GxvrN2XnL9lgibIkCgyor8m8nMEGUHDZ+JyMmvisuiNEfATeyGH3iU3vxLPIke6xpY5d yjRvox9UMFw1cAd6jOnxiogJcvwzsG3QAbp6mXF5nheDFPuG/Y7DaTEVcrdxA6/qKo5/ 6TofHEz9ZgVXFpJxHWcERwQ2IZ2h37gKJMa/L1+gOfyFt7dFTarLtrl6lJO/RHjxAo39 1gELXam1yI3I4WgAgHrmarJ+0oMUfZOtNDgbx7vDNnGvPlf0BVsKf0M5N6tQGlnCclh+ OHUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=3/RdWbl1/Y7109L7deJTqux8rPtQXt1q7C4U6mcb2AM=; fh=yDkQzEl6IxZLQSJVtYl4ZVgHjrQZ2Js7dKd11NaUo5c=; b=HeBcX5FQSqLOVcO8KW3R3K1K+fubyxtjnhsigSAaCgHC+inxrR5WWJNaAYZ3nvTYEi 81KaSVhb2hLdtmweNBsp+lvzrB1snoOxRqn2hJO1zv9RXE+aIlRex56NN0Uv3oG7Xvk8 C3EIO9l4c0zIplSx9WLZmdUXZf4srxEHLmx1+fp8xYwVtzv7xHMQLfRv+CTzwYIpoMF3 bk8eyZgpf7PB5yoGTZzvrAitUgxGlWzQpm3lYjSWgakiGGCbwY1hjVl2ou0YQwx/bFQT fF2IJ6w+LovHi4VzrwQtNOJIqkY0vdJ1xTvw3qLruARY0UQ8bR1bsQloP64E246ujpmz fB0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeconstruct.com.au header.s=2022a header.b=HKhhAUwU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=codeconstruct.com.au Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id t25-20020a6564d9000000b005b8dd557b38si14929654pgv.14.2023.11.29.14.46.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Nov 2023 14:46:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@codeconstruct.com.au header.s=2022a header.b=HKhhAUwU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=codeconstruct.com.au Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 40A558076E50; Wed, 29 Nov 2023 14:45:09 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229907AbjK2Wov (ORCPT + 99 others); Wed, 29 Nov 2023 17:44:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229658AbjK2Wou (ORCPT ); Wed, 29 Nov 2023 17:44:50 -0500 Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39FA4122; Wed, 29 Nov 2023 14:44:50 -0800 (PST) Received: from [192.168.68.112] (ppp118-210-131-38.adl-adc-lon-bras33.tpg.internode.on.net [118.210.131.38]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 2A2642014A; Thu, 30 Nov 2023 06:44:38 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1701297884; bh=3/RdWbl1/Y7109L7deJTqux8rPtQXt1q7C4U6mcb2AM=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=HKhhAUwUL/rIv0NFaMEyE2NscNboxbaKpc7q+jumnKREr/4dyPS0lTIGAoUtjzfqI +ZJn2JIvPHsZz3k7RVK6CUo9GZENgHOgcOzuUx0XI0hQoafGnNX/xgV265OxHK35Ir SQi66MjFYqk027UQfs8101rerH89LCnVaUhBb+qM6yr6n0RZp5Xqkebh4Nc7oxpyJX G5xKKjNRd9fVJgifEa1f2Tc3PxXfHtWCmoGpnBbOtowN/T/Ia0sZSkFnn28f3bkOlP sP5IWPBvU3wOQ+wjR/7Jt0CmAIBwT0bpO7DypAUHs/f0z2F6k3adv4wQTGKzhrr1ah ck2dkrKQPNUQQ== Message-ID: Subject: Re: [PATCH v2 RESEND 2/2] i2c: aspeed: Acknowledge Tx done with and without ACK irq late From: Andrew Jeffery To: Quan Nguyen , Brendan Higgins , Benjamin Herrenschmidt , Joel Stanley , Andi Shyti , Wolfram Sang , Jae Hyun Yoo , Guenter Roeck , linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org Cc: Cosmo Chou , Open Source Submission , Phong Vo , "Thang Q . Nguyen" Date: Thu, 30 Nov 2023 09:14:37 +1030 In-Reply-To: <66dcea57-db0b-4686-9eaf-746db637f31c@os.amperecomputing.com> References: <20231128075236.2724038-1-quan@os.amperecomputing.com> <20231128075236.2724038-3-quan@os.amperecomputing.com> <2186c3b9ac92f03c68e8a2dd9fda871f80a6d664.camel@codeconstruct.com.au> <66dcea57-db0b-4686-9eaf-746db637f31c@os.amperecomputing.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 29 Nov 2023 14:45:09 -0800 (PST) On Wed, 2023-11-29 at 16:02 +0700, Quan Nguyen wrote: >=20 > On 29/11/2023 07:33, Andrew Jeffery wrote: > > On Tue, 2023-11-28 at 14:52 +0700, Quan Nguyen wrote: > > > diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c= -aspeed.c > > > index 79476b46285b..3231f430e335 100644 > > > --- a/drivers/i2c/busses/i2c-aspeed.c > > > +++ b/drivers/i2c/busses/i2c-aspeed.c > > > @@ -611,8 +611,9 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, vo= id *dev_id) > > > =20 > > > spin_lock(&bus->lock); > > > irq_received =3D readl(bus->base + ASPEED_I2C_INTR_STS_REG); > > > - /* Ack all interrupts except for Rx done */ > > > - writel(irq_received & ~ASPEED_I2CD_INTR_RX_DONE, > > > + /* Ack all interrupts except for Rx done and Tx done with/without A= CK */ > >=20 > > I'm not a huge fan of this comment, it just says what the code does. It > > would be much better to explain *why* the code does what it does. > >=20 > > I realise describing what the code does was already the gist of the > > comment and that you're just updating it to match the change to the > > code, but that's my entire problem with it. We'd be better off deleting > > it if we're not going to explain why the masking is necessary. > >=20 >=20 > Thanks for the comment Andrew. >=20 > I would prefer to delete it. >=20 > But if to put some comment, how about: >=20 > /* Early ack INTR_RX_DONE, INTR_TX_[ACK|NAK] would indicate HW to start= =20 > receiving/sending new data and may cause a race condition as irq handler= =20 > not yet to handle these irqs but being acked. Let ack them late in the= =20 > end of irq handler when those are truly processed */ Please update the patch with this comment. It at least goes some way to explain why. >=20 > > > + writel(irq_received & > > > + ~(ASPEED_I2CD_INTR_RX_DONE | ASPEED_I2CD_INTR_TX_ACK | ASPEE= D_I2CD_INTR_TX_NAK), > > > bus->base + ASPEED_I2C_INTR_STS_REG); > > > readl(bus->base + ASPEED_I2C_INTR_STS_REG); > > > irq_received &=3D ASPEED_I2CD_INTR_RECV_MASK; > > > @@ -657,12 +658,12 @@ static irqreturn_t aspeed_i2c_bus_irq(int irq, = void *dev_id) > > > "irq handled !=3D irq. expected 0x%08x, but was 0x%08x\n", > > > irq_received, irq_handled); > > > =20 > > > - /* Ack Rx done */ > > > - if (irq_received & ASPEED_I2CD_INTR_RX_DONE) { > > > - writel(ASPEED_I2CD_INTR_RX_DONE, > > > - bus->base + ASPEED_I2C_INTR_STS_REG); > > > - readl(bus->base + ASPEED_I2C_INTR_STS_REG); > > > - } > > > + /* Ack Rx done and Tx done with/without ACK */ > > > + writel(irq_received & > > > + (ASPEED_I2CD_INTR_RX_DONE | ASPEED_I2CD_INTR_TX_ACK | ASPEED= _I2CD_INTR_TX_NAK), > > > + bus->base + ASPEED_I2C_INTR_STS_REG); > > > + readl(bus->base + ASPEED_I2C_INTR_STS_REG); > >=20 > > I'm not sure why the write was conditional, but I'm not sure that > > making it unconditional is valid either? Why the change? Why not add > > the extra interrupt bits to the condition in addition to the value mask > > for the write? > >=20 >=20 > In original code, only INTR_RX_DONE was acked late. So the check=20 > (irq_received & ASPEED_I2CD_INTR_RX_DONE) is need and that help to save= =20 > one write() then read() if there was no such irq. >=20 > In the new code, there is no such check and the drawback is that there= =20 > always be one write() and one read() for all cases, include the case=20 > where there is no irq at all, ie writing 0 into ASPEED_I2C_INTR_STS_REG. >=20 > And yes, your concern maybe right, we can not say of writing 0 into=20 > ASPEED_I2C_INTR_STS_REG is good or not. >=20 > I checked back my debug log and seeing that irq always come with at=20 > least one of INTR_RX_DONE BIT(2), INTR_TX_ACK BIT(0), INTR_TX_NAK BIT(1)= =20 > raised. So it seems like the case of writing 0 into=20 > ASPEED_I2C_INTR_STS_REG is indeed rarely to happen. >=20 > Do you think we should change it to: >=20 > if (irq_received & (INTR_RX_DONE | INTR_TX_ACK | INTR_TX_NAK)) { > writel( irq_received & (INTR_RX_DONE| INTR_TX_ACK| INTR_TX_NAK), > bus->base + ASPEED_I2C_INTR_STS_REG); > readl(bus->base + ASPEED_I2C_INTR_STS_REG); > } This is less different from the existing strategy and doesn't require any explanation beyond what you're already trying to achieve in the patch, so I think you should switch to this approach. If someone wants to work out why it was done conditionally and argue for its removal then they can do that separately. Cheers, Andrew