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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 5C411C169C4 for ; Thu, 31 Jan 2019 13:13:09 +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 3124F20B1F for ; Thu, 31 Jan 2019 13:13:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eqCpLaRP"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="gEry/j8c" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3124F20B1F 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=VymsEJotYRvnO/Mn5cCEFrFnl9bCeg4Bkz5mnSUae8E=; b=eqCpLaRPaXxJuO +84oACxGrTVKiZ3FsrVgjEBbrzU8FsEC/b8lzRI0j2e0MrqvLilHDQhbAN/oeEB/FILtTq+xSUdC4 zqYN/9JIOWCsaGiD4/lltL7EU3ramUPN+Y/5cUInmImfeLbWivAyuipQBF8r96wu9RoyJHQINHxTq X3M5GJyc7oG4H1r001DG+QXpOHVR8RI7R8+rAL1Jdm82wFHAP1KTo7+fLVuItTGRMcjW/tCTVZLlo mX7Iya50s3oaXIjVH5XlxqGsYCE5Mhx5kE/jkC1dgxuNNBRuV7gB2G8Q0rorP2pbJSIg7DCJTNlFH BSfqFYNv3CU7+rk41BYg==; 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 1gpC9R-0008VO-IR; Thu, 31 Jan 2019 13:13:05 +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 1gpC9C-0008Hk-Ds; Thu, 31 Jan 2019 13:12:51 +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 E072F2087F; Thu, 31 Jan 2019 13:12:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548940368; bh=l+hMYyleZdMvs+nKECj68JvNPAZLYxFaw+dcGnDGAs4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gEry/j8ctx5y7ogEtPv/kKAh/Aq9UGxP7DPURymMwibOP2Q7787qslVCFEy6508TY +1u1FJKhQtXe4k5HG8Nv4Rt7CJQTvTU0K++ggUmIqJR1zHbqsYkqcPwD6K+kdaoMXu thKSvbyp7NEUh+nWAqQLxn6qvV2nS9iWMqC/cSh4= Date: Thu, 31 Jan 2019 14:12:35 +0100 From: Boris Brezillon To: Subject: Re: [PATCH 9/9] spi: atmel-quadspi: add support for sam9x60 qspi controller Message-ID: <20190131141235.418e8e9c@bbrezillon> In-Reply-To: <5a91b6b2-0fed-f411-6e96-568e610f15fa@microchip.com> References: <20190130150818.24902-1-tudor.ambarus@microchip.com> <20190130150818.24902-10-tudor.ambarus@microchip.com> <20190131125504.3eff449d@bbrezillon> <5a91b6b2-0fed-f411-6e96-568e610f15fa@microchip.com> 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-20190131_051250_484289_561ADAED X-CRM114-Status: GOOD ( 16.75 ) 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: alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, Ludovic.Desroches@microchip.com, broonie@kernel.org, linux-mtd@lists.infradead.org, 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 Thu, 31 Jan 2019 12:40:04 +0000 wrote: > On 01/31/2019 01:55 PM, Boris Brezillon wrote: > > On Wed, 30 Jan 2019 15:08:47 +0000 > > wrote: > > > >> + > >> +static int atmel_sam9x60_qspi_set_cfg(struct atmel_qspi *aq, > >> + const struct spi_mem_op *op, > >> + struct atmel_qspi_cfg *cfg) > >> +{ > >> + int ret = atmel_qspi_set_mode(cfg, op); > >> + > >> + if (ret) > >> + return ret; > >> + > >> + cfg->icr = QSPI_ICR_INST(op->cmd.opcode); > >> + > >> + if (!op->addr.nbytes) { > >> + cfg->ifr |= QSPI_IFR_TFRTYP_TRSFR_REG; > >> + if (op->data.dir == SPI_MEM_DATA_OUT) > >> + cfg->ifr |= QSPI_IFR_APBTFRTYP_WRITE; > >> + else > >> + cfg->ifr |= QSPI_IFR_APBTFRTYP_READ; > >> + } else { > >> + cfg->ifr |= QSPI_IFR_TFRTYP_TRSFR_MEM; > > > > Why do you use a MEM transfer here? What's the difference with a > > regular transfer? > > QSPI_IFR_TFRTYP_TRSFR_MEM must be set when one wants to read/write in the serial > memory, and particularly a memory data. > > QSPI_IFR_TFRTYP_TRSFR_REG must be set when one wants to read or write to serial > memory, but not a memory data. > Read examples: JEDEC_ID or QSPI_SR > Write examples: writing the configuration or the QSPI_SR. > > Does this answers your question? Not really :-). From the SPI bus perspective, there's no difference between a read/write from/to actual memory blocks or a read/write reg/param-page, so there must be something different on the controller side. I think regular transfers should work for anything, which is why I initially suggested to use that in the ->exec_op() implementation. If memory accesses are optimized somehow and do not work for all accesses, then we should keep them for the dirmap implementation. After reading the sama5d2 datasheet, I have the feeling that the only difference is the fact that the address is directly extracted from the AHB window offset when using mem accesses (instead of being taken from the IAR register), plus the possibility to enable the data scrambler/randomize. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/