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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 527D3C282D7 for ; Sat, 2 Feb 2019 13:20:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F06B72173B for ; Sat, 2 Feb 2019 13:20:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SqqUB23j"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yvn9i/T2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F06B72173B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=efo8ZUTAnM1l2tnj1nIO7ayCPusnVsvpIz/XWy10mZc=; b=SqqUB23jljEmlM AGg6SjqVFJ9ua3e8TV2lIe3QDrURn78VEvdkFxJ469UPIvkYMQu95wOx8+xiS4QDEkXH76wwI/Eqc siMFBdnUJwF4h34k7+b+SI0q2yMWdUP6VfSxK/NJ16/a/CfuhkGE3MrWumSumvXNFBTXZiI1BIvEg VVpxpglpl49Hqc0h3ZnITU74uIpLLZeODTVK54i/p1vp+0EJDWcTKHTJlsjUA09aJgaws3R8tQJRA ptPLcm/uWNFqh7/y/nNC59xOB/55tmL6VDzXoDOQBOzc40ZGt3PilGDeLV7L/xvtA652brPNNwCSF zF2LY4Sx2FDB+XChr9sw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gpvE6-0003tf-BC; Sat, 02 Feb 2019 13:20:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gpvDv-0003ln-OP; Sat, 02 Feb 2019 13:20:45 +0000 Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9F9682173B; Sat, 2 Feb 2019 13:20:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549113641; bh=KsuDKuKlJQAE474thXEYS0gFc9Y879d0/apCZUyA2BU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Yvn9i/T2YxRQ61YiDLwBBRswAL47uWfTMzRseCidx4/oSP5KHtFEi4EqDwqd2vnMH BXlWwtA8Jn3yaPKxyNZ3MdUcPWwt7lCFAJppVeqndFKVzXmHvtyIrvHtQrAwUr3XNj iayI1CXdSAhgQf2EiWgoD48l/4oVA6cr2v3UFo0M= Date: Sat, 2 Feb 2019 14:20:29 +0100 From: Boris Brezillon To: Subject: Re: [PATCH v3 01/13] spi: atmel-quadspi: cache MR value to avoid a write access Message-ID: <20190202142029.76ac36b6@bbrezillon> In-Reply-To: References: <20190202040653.1217-1-tudor.ambarus@microchip.com> <20190202040653.1217-2-tudor.ambarus@microchip.com> <20190202080650.44becc2d@bbrezillon> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190202_052043_852625_80089E9B X-CRM114-Status: GOOD ( 23.30 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, alexandre.belloni@bootlin.com, broonie@kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-spi@vger.kernel.org, Ludovic.Desroches@microchip.com, Cyrille.Pitchen@microchip.com, linux-mtd@lists.infradead.org, bugalski.piotr@gmail.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Sat, 2 Feb 2019 08:38:40 +0000 wrote: > On 02/02/2019 09:06 AM, Boris Brezillon wrote: > > On Sat, 2 Feb 2019 04:07:13 +0000 > > wrote: > > > >> From: Tudor Ambarus > >> > >> Cache Serial Memory Mode (SMM) value to avoid write access when > >> setting the controller in serial memory mode. SMM is set in > >> exec_op() and not at probe time, to let room for future regular > >> SPI support. > >> > >> Signed-off-by: Tudor Ambarus > >> --- > >> v3: update smm value when different. rename mr/smm > >> v2: cache MR value instead of moving the write access at probe > >> > >> drivers/spi/atmel-quadspi.c | 7 ++++++- > >> 1 file changed, 6 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c > >> index ddc712410812..645284c6ec9a 100644 > >> --- a/drivers/spi/atmel-quadspi.c > >> +++ b/drivers/spi/atmel-quadspi.c > >> @@ -155,6 +155,7 @@ struct atmel_qspi { > >> struct clk *clk; > >> struct platform_device *pdev; > >> u32 pending; > >> + u32 smm; > >> struct completion cmd_completion; > >> }; > >> > >> @@ -238,7 +239,11 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > >> icr = QSPI_ICR_INST(op->cmd.opcode); > >> ifr = QSPI_IFR_INSTEN; > >> > >> - qspi_writel(aq, QSPI_MR, QSPI_MR_SMM); > >> + /* Set the QSPI controller in Serial Memory Mode */ > >> + if (aq->smm != QSPI_MR_SMM) { > > > > Sorry, I think I misunderstood your previous suggestion, I thought the > > reg was called SMM. If the reg is called MR and the value you expect in > > there is SMM, then the field should be named ->mr as it caches the > > whole reg, not only the SMM bit. So it's actually: > > > > if (aq->mr != QSPI_MR_SMM) { > > No worries. When keeping the reg name, and not the bit itself, I would expect to > do the check as in v2, to let room for checking other bits too: > > + if (!(aq->mr & QSPI_MR_SMM)) > > I don't have any problems to keep "mr" name, but I would like to understand your > reasons. Either you want to only set the SMM bit and keep the other bits untouched or you want to make sure the register contains the value you expect for all bitfields. If you're trying to achieve the former, you should only update SMM instead of setting SMM + clearing all other bits. In the other hand, if you want to apply a new MR setting where you know exactly that only SMM should be set, that means you should test the value in the cache (->mr) against the value you expect, and not only the check that QSPI_MR_SMM is set. BTW, you should probably initialize ->mr at probe time (using a readl_relaxed()). ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Brezillon Subject: Re: [PATCH v3 01/13] spi: atmel-quadspi: cache MR value to avoid a write access Date: Sat, 2 Feb 2019 14:20:29 +0100 Message-ID: <20190202142029.76ac36b6@bbrezillon> References: <20190202040653.1217-1-tudor.ambarus@microchip.com> <20190202040653.1217-2-tudor.ambarus@microchip.com> <20190202080650.44becc2d@bbrezillon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, alexandre.belloni@bootlin.com, broonie@kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-spi@vger.kernel.org, Ludovic.Desroches@microchip.com, Cyrille.Pitchen@microchip.com, linux-mtd@lists.infradead.org, bugalski.piotr@gmail.com, linux-arm-kernel@lists.infradead.org To: Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org List-Id: linux-spi.vger.kernel.org On Sat, 2 Feb 2019 08:38:40 +0000 wrote: > On 02/02/2019 09:06 AM, Boris Brezillon wrote: > > On Sat, 2 Feb 2019 04:07:13 +0000 > > wrote: > > > >> From: Tudor Ambarus > >> > >> Cache Serial Memory Mode (SMM) value to avoid write access when > >> setting the controller in serial memory mode. SMM is set in > >> exec_op() and not at probe time, to let room for future regular > >> SPI support. > >> > >> Signed-off-by: Tudor Ambarus > >> --- > >> v3: update smm value when different. rename mr/smm > >> v2: cache MR value instead of moving the write access at probe > >> > >> drivers/spi/atmel-quadspi.c | 7 ++++++- > >> 1 file changed, 6 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c > >> index ddc712410812..645284c6ec9a 100644 > >> --- a/drivers/spi/atmel-quadspi.c > >> +++ b/drivers/spi/atmel-quadspi.c > >> @@ -155,6 +155,7 @@ struct atmel_qspi { > >> struct clk *clk; > >> struct platform_device *pdev; > >> u32 pending; > >> + u32 smm; > >> struct completion cmd_completion; > >> }; > >> > >> @@ -238,7 +239,11 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > >> icr = QSPI_ICR_INST(op->cmd.opcode); > >> ifr = QSPI_IFR_INSTEN; > >> > >> - qspi_writel(aq, QSPI_MR, QSPI_MR_SMM); > >> + /* Set the QSPI controller in Serial Memory Mode */ > >> + if (aq->smm != QSPI_MR_SMM) { > > > > Sorry, I think I misunderstood your previous suggestion, I thought the > > reg was called SMM. If the reg is called MR and the value you expect in > > there is SMM, then the field should be named ->mr as it caches the > > whole reg, not only the SMM bit. So it's actually: > > > > if (aq->mr != QSPI_MR_SMM) { > > No worries. When keeping the reg name, and not the bit itself, I would expect to > do the check as in v2, to let room for checking other bits too: > > + if (!(aq->mr & QSPI_MR_SMM)) > > I don't have any problems to keep "mr" name, but I would like to understand your > reasons. Either you want to only set the SMM bit and keep the other bits untouched or you want to make sure the register contains the value you expect for all bitfields. If you're trying to achieve the former, you should only update SMM instead of setting SMM + clearing all other bits. In the other hand, if you want to apply a new MR setting where you know exactly that only SMM should be set, that means you should test the value in the cache (->mr) against the value you expect, and not only the check that QSPI_MR_SMM is set. BTW, you should probably initialize ->mr at probe time (using a readl_relaxed()). 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 X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55681C282D7 for ; Sat, 2 Feb 2019 13:20:48 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 14FCD2173B for ; Sat, 2 Feb 2019 13:20:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SKe7WK1A"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yvn9i/T2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 14FCD2173B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=juVafX/rqi0LSMYZSIKwZb1+m2YCYWCpHvTgGQDw6cA=; b=SKe7WK1AbQ+CFs cbRsoYGgri/BLYbF1M8jxYvcwG9fu+lUT5PwfF1lWrCp3ibovtLM2zBEJUE3NB0JPu9F+fEgFHCrq h0I1XSt0MRr5lHIFpe6JhLj+mALEuqguEa7tNTsCJx2LLmUBm6d/zji0/5ygn8KL/rSoBd/fXIqox eIE1qXqi/kJaVE5DYg9OxJMCnhjAKd/qN/2s/swLgTsOh5cUZxxbWJb2SZbdMAOdnqiuL8hYCLkyt q3l6GE3zVfNH/HB+z7m+MCXCRVrlCWMwSU68AHqdJdhayl1UcaVK/yvByRHvowTxAEIjQ9NAlZIFk jUiPTi1V7bgPCNOZa1yw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gpvDz-0003mB-1J; Sat, 02 Feb 2019 13:20:47 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gpvDv-0003ln-OP; Sat, 02 Feb 2019 13:20:45 +0000 Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9F9682173B; Sat, 2 Feb 2019 13:20:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549113641; bh=KsuDKuKlJQAE474thXEYS0gFc9Y879d0/apCZUyA2BU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Yvn9i/T2YxRQ61YiDLwBBRswAL47uWfTMzRseCidx4/oSP5KHtFEi4EqDwqd2vnMH BXlWwtA8Jn3yaPKxyNZ3MdUcPWwt7lCFAJppVeqndFKVzXmHvtyIrvHtQrAwUr3XNj iayI1CXdSAhgQf2EiWgoD48l/4oVA6cr2v3UFo0M= Date: Sat, 2 Feb 2019 14:20:29 +0100 From: Boris Brezillon To: Subject: Re: [PATCH v3 01/13] spi: atmel-quadspi: cache MR value to avoid a write access Message-ID: <20190202142029.76ac36b6@bbrezillon> In-Reply-To: References: <20190202040653.1217-1-tudor.ambarus@microchip.com> <20190202040653.1217-2-tudor.ambarus@microchip.com> <20190202080650.44becc2d@bbrezillon> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190202_052043_852625_80089E9B X-CRM114-Status: GOOD ( 23.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, alexandre.belloni@bootlin.com, broonie@kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-spi@vger.kernel.org, Ludovic.Desroches@microchip.com, Cyrille.Pitchen@microchip.com, linux-mtd@lists.infradead.org, bugalski.piotr@gmail.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 2 Feb 2019 08:38:40 +0000 wrote: > On 02/02/2019 09:06 AM, Boris Brezillon wrote: > > On Sat, 2 Feb 2019 04:07:13 +0000 > > wrote: > > > >> From: Tudor Ambarus > >> > >> Cache Serial Memory Mode (SMM) value to avoid write access when > >> setting the controller in serial memory mode. SMM is set in > >> exec_op() and not at probe time, to let room for future regular > >> SPI support. > >> > >> Signed-off-by: Tudor Ambarus > >> --- > >> v3: update smm value when different. rename mr/smm > >> v2: cache MR value instead of moving the write access at probe > >> > >> drivers/spi/atmel-quadspi.c | 7 ++++++- > >> 1 file changed, 6 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c > >> index ddc712410812..645284c6ec9a 100644 > >> --- a/drivers/spi/atmel-quadspi.c > >> +++ b/drivers/spi/atmel-quadspi.c > >> @@ -155,6 +155,7 @@ struct atmel_qspi { > >> struct clk *clk; > >> struct platform_device *pdev; > >> u32 pending; > >> + u32 smm; > >> struct completion cmd_completion; > >> }; > >> > >> @@ -238,7 +239,11 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > >> icr = QSPI_ICR_INST(op->cmd.opcode); > >> ifr = QSPI_IFR_INSTEN; > >> > >> - qspi_writel(aq, QSPI_MR, QSPI_MR_SMM); > >> + /* Set the QSPI controller in Serial Memory Mode */ > >> + if (aq->smm != QSPI_MR_SMM) { > > > > Sorry, I think I misunderstood your previous suggestion, I thought the > > reg was called SMM. If the reg is called MR and the value you expect in > > there is SMM, then the field should be named ->mr as it caches the > > whole reg, not only the SMM bit. So it's actually: > > > > if (aq->mr != QSPI_MR_SMM) { > > No worries. When keeping the reg name, and not the bit itself, I would expect to > do the check as in v2, to let room for checking other bits too: > > + if (!(aq->mr & QSPI_MR_SMM)) > > I don't have any problems to keep "mr" name, but I would like to understand your > reasons. Either you want to only set the SMM bit and keep the other bits untouched or you want to make sure the register contains the value you expect for all bitfields. If you're trying to achieve the former, you should only update SMM instead of setting SMM + clearing all other bits. In the other hand, if you want to apply a new MR setting where you know exactly that only SMM should be set, that means you should test the value in the cache (->mr) against the value you expect, and not only the check that QSPI_MR_SMM is set. BTW, you should probably initialize ->mr at probe time (using a readl_relaxed()). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Brezillon Subject: Re: [PATCH v3 01/13] spi: atmel-quadspi: cache MR value to avoid a write access Date: Sat, 2 Feb 2019 14:20:29 +0100 Message-ID: <20190202142029.76ac36b6@bbrezillon> References: <20190202040653.1217-1-tudor.ambarus@microchip.com> <20190202040653.1217-2-tudor.ambarus@microchip.com> <20190202080650.44becc2d@bbrezillon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Tudor.Ambarus@microchip.com Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, alexandre.belloni@bootlin.com, broonie@kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, linux-spi@vger.kernel.org, Ludovic.Desroches@microchip.com, Cyrille.Pitchen@microchip.com, linux-mtd@lists.infradead.org, bugalski.piotr@gmail.com, linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org On Sat, 2 Feb 2019 08:38:40 +0000 wrote: > On 02/02/2019 09:06 AM, Boris Brezillon wrote: > > On Sat, 2 Feb 2019 04:07:13 +0000 > > wrote: > > > >> From: Tudor Ambarus > >> > >> Cache Serial Memory Mode (SMM) value to avoid write access when > >> setting the controller in serial memory mode. SMM is set in > >> exec_op() and not at probe time, to let room for future regular > >> SPI support. > >> > >> Signed-off-by: Tudor Ambarus > >> --- > >> v3: update smm value when different. rename mr/smm > >> v2: cache MR value instead of moving the write access at probe > >> > >> drivers/spi/atmel-quadspi.c | 7 ++++++- > >> 1 file changed, 6 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c > >> index ddc712410812..645284c6ec9a 100644 > >> --- a/drivers/spi/atmel-quadspi.c > >> +++ b/drivers/spi/atmel-quadspi.c > >> @@ -155,6 +155,7 @@ struct atmel_qspi { > >> struct clk *clk; > >> struct platform_device *pdev; > >> u32 pending; > >> + u32 smm; > >> struct completion cmd_completion; > >> }; > >> > >> @@ -238,7 +239,11 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > >> icr = QSPI_ICR_INST(op->cmd.opcode); > >> ifr = QSPI_IFR_INSTEN; > >> > >> - qspi_writel(aq, QSPI_MR, QSPI_MR_SMM); > >> + /* Set the QSPI controller in Serial Memory Mode */ > >> + if (aq->smm != QSPI_MR_SMM) { > > > > Sorry, I think I misunderstood your previous suggestion, I thought the > > reg was called SMM. If the reg is called MR and the value you expect in > > there is SMM, then the field should be named ->mr as it caches the > > whole reg, not only the SMM bit. So it's actually: > > > > if (aq->mr != QSPI_MR_SMM) { > > No worries. When keeping the reg name, and not the bit itself, I would expect to > do the check as in v2, to let room for checking other bits too: > > + if (!(aq->mr & QSPI_MR_SMM)) > > I don't have any problems to keep "mr" name, but I would like to understand your > reasons. Either you want to only set the SMM bit and keep the other bits untouched or you want to make sure the register contains the value you expect for all bitfields. If you're trying to achieve the former, you should only update SMM instead of setting SMM + clearing all other bits. In the other hand, if you want to apply a new MR setting where you know exactly that only SMM should be set, that means you should test the value in the cache (->mr) against the value you expect, and not only the check that QSPI_MR_SMM is set. BTW, you should probably initialize ->mr at probe time (using a readl_relaxed()). 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 X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53164C282DA for ; Sat, 2 Feb 2019 13:21:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 22D802173B for ; Sat, 2 Feb 2019 13:21:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549113663; bh=KsuDKuKlJQAE474thXEYS0gFc9Y879d0/apCZUyA2BU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=leeXLH/yj+q+vs1uMa84pwjXgsckiwA9RC8S4Dr5P3SMld7no66glaVJUIJgtNUq7 Cgjq3K4d5IirjaCwGTkqmaUMkg7OqHmMXJxI+hnhgcZJ9OHTjIvhyMNgOpmfdTKdjk zXAz+WGKLsCPK4NOMbTJbQyjximGi0fo274KaA8w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728036AbfBBNUn (ORCPT ); Sat, 2 Feb 2019 08:20:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:37772 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727847AbfBBNUn (ORCPT ); Sat, 2 Feb 2019 08:20:43 -0500 Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9F9682173B; Sat, 2 Feb 2019 13:20:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549113641; bh=KsuDKuKlJQAE474thXEYS0gFc9Y879d0/apCZUyA2BU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Yvn9i/T2YxRQ61YiDLwBBRswAL47uWfTMzRseCidx4/oSP5KHtFEi4EqDwqd2vnMH BXlWwtA8Jn3yaPKxyNZ3MdUcPWwt7lCFAJppVeqndFKVzXmHvtyIrvHtQrAwUr3XNj iayI1CXdSAhgQf2EiWgoD48l/4oVA6cr2v3UFo0M= Date: Sat, 2 Feb 2019 14:20:29 +0100 From: Boris Brezillon To: Cc: , , , , , , , , , , , Subject: Re: [PATCH v3 01/13] spi: atmel-quadspi: cache MR value to avoid a write access Message-ID: <20190202142029.76ac36b6@bbrezillon> In-Reply-To: References: <20190202040653.1217-1-tudor.ambarus@microchip.com> <20190202040653.1217-2-tudor.ambarus@microchip.com> <20190202080650.44becc2d@bbrezillon> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2 Feb 2019 08:38:40 +0000 wrote: > On 02/02/2019 09:06 AM, Boris Brezillon wrote: > > On Sat, 2 Feb 2019 04:07:13 +0000 > > wrote: > > > >> From: Tudor Ambarus > >> > >> Cache Serial Memory Mode (SMM) value to avoid write access when > >> setting the controller in serial memory mode. SMM is set in > >> exec_op() and not at probe time, to let room for future regular > >> SPI support. > >> > >> Signed-off-by: Tudor Ambarus > >> --- > >> v3: update smm value when different. rename mr/smm > >> v2: cache MR value instead of moving the write access at probe > >> > >> drivers/spi/atmel-quadspi.c | 7 ++++++- > >> 1 file changed, 6 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c > >> index ddc712410812..645284c6ec9a 100644 > >> --- a/drivers/spi/atmel-quadspi.c > >> +++ b/drivers/spi/atmel-quadspi.c > >> @@ -155,6 +155,7 @@ struct atmel_qspi { > >> struct clk *clk; > >> struct platform_device *pdev; > >> u32 pending; > >> + u32 smm; > >> struct completion cmd_completion; > >> }; > >> > >> @@ -238,7 +239,11 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > >> icr = QSPI_ICR_INST(op->cmd.opcode); > >> ifr = QSPI_IFR_INSTEN; > >> > >> - qspi_writel(aq, QSPI_MR, QSPI_MR_SMM); > >> + /* Set the QSPI controller in Serial Memory Mode */ > >> + if (aq->smm != QSPI_MR_SMM) { > > > > Sorry, I think I misunderstood your previous suggestion, I thought the > > reg was called SMM. If the reg is called MR and the value you expect in > > there is SMM, then the field should be named ->mr as it caches the > > whole reg, not only the SMM bit. So it's actually: > > > > if (aq->mr != QSPI_MR_SMM) { > > No worries. When keeping the reg name, and not the bit itself, I would expect to > do the check as in v2, to let room for checking other bits too: > > + if (!(aq->mr & QSPI_MR_SMM)) > > I don't have any problems to keep "mr" name, but I would like to understand your > reasons. Either you want to only set the SMM bit and keep the other bits untouched or you want to make sure the register contains the value you expect for all bitfields. If you're trying to achieve the former, you should only update SMM instead of setting SMM + clearing all other bits. In the other hand, if you want to apply a new MR setting where you know exactly that only SMM should be set, that means you should test the value in the cache (->mr) against the value you expect, and not only the check that QSPI_MR_SMM is set. BTW, you should probably initialize ->mr at probe time (using a readl_relaxed()).