Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4876897imm; Tue, 26 Jun 2018 02:00:04 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLuYbSySHISytcE6eifidZYMdoRnEBzynAmfneg3862TEfuLFZ/a2u99TIiyGr7EXhpdT27 X-Received: by 2002:a17:902:a518:: with SMTP id s24-v6mr729283plq.144.1530003604634; Tue, 26 Jun 2018 02:00:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530003604; cv=none; d=google.com; s=arc-20160816; b=t6Uj/e8VcAzXiDLXQ7IkhX7O04fkUACnC5k55PSHR0vxGxDzU1bHr1NrCWlh2JLrY6 qXayeEC6pQKjKQxYD4/ltLhMZdtd/XjHsvbuRovhaQmClHOJsLepXGv/lDqWWuWRhla2 8MpUK5QUNJXaQcsJjQVWrx2ZjAmHguGJKOwaFFlW813luNA4esebfCC3eYPLHooriGWQ f+4d4513Mfky2lrZG4kTJupOYyVdAFnIPqf49c+qtYZtWhqYlz2WZb+lZgthTG4i8FgF xEJ23wHK3bd2yqGeZviXpPVVYdcZLaC/pkIaoMilzpacIo9sidXziKb7+VGZX6Rp+9Fh Bzvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=+HePdy1XXWWJh2AoQ6XGeX1+mgQ5My9brBKj+G1lBoo=; b=VGG+8ksxh6n6pljwwbaJ0hidL0v4RS4BiLsK1qruCrkVNR9nuwDGVuBBu+eXkpLOuU rF/4fpjhL4WZXlXuobpCHl5nAMDzfIb4mCzDQrgXYAYWkp7rNQYOfIMXay5YFJjNgoRV HuTIE+pCtUtdcOgM/3lI49AajMycEqeZfEyb74kQcJtGyEQFmJRff/F1BaLOrUeeg9Sb 7iJRcphLcOJBqqyX3cMKcMkfQKzgW6MEbTv+VMzRTn4GVj191C69Wv0+1D5L2E4XCvWH jRh91Klb0kwNwoQGwkCv6DZZLSi08NK1RcPpMfOMDfluPinHMUchWh2B2ykOEwOKaMRs xyQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@as-electronics.de header.s=strato-dkim-0002 header.b="c9rDhbw/"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d36-v6si611321pla.484.2018.06.26.01.59.49; Tue, 26 Jun 2018 02:00:04 -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; dkim=fail header.i=@as-electronics.de header.s=strato-dkim-0002 header.b="c9rDhbw/"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933478AbeFZI7B (ORCPT + 99 others); Tue, 26 Jun 2018 04:59:01 -0400 Received: from mo4-p05-ob.smtp.rzone.de ([85.215.255.136]:16782 "EHLO mo4-p05-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932210AbeFZI66 (ORCPT ); Tue, 26 Jun 2018 04:58:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1530003534; s=strato-dkim-0002; d=as-electronics.de; h=In-Reply-To:Date:Message-ID:From:References:Cc:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=+HePdy1XXWWJh2AoQ6XGeX1+mgQ5My9brBKj+G1lBoo=; b=c9rDhbw/l3ylGORdZlO3Il27tzpUx1fdPTE1vKq9rG16lzn2u6gP/lIVlGdJ8l6xKh z+aFxLzzYh/zttTJCXYapJWKo+ZQvKJ3rhajD1KUmXBO+cdjl1Vc/A+AmDYjfjf99fiT UOy65Hj7bHXXip7bD+Vlkx/nhTBZ1Vmm1Yg4Ovr8w4kwTgeBN1TO02+Nr5B/77yIZIBi 39vw0GDF7Bp5JlLyH+ugTl9TV/RsLzaNsj2REguUbJ+slw381cTIOeIK4tzsRGVG2GFw C9WPZrDd5ycRmMJxYngXkKFFiH/Y7sAprXS+xiZhkMPLYFWhDY1GTUH+3P0RCnfJipVL NUnQ== X-RZG-AUTH: ":LX8JdEmkW/4tAFwMkcNJIloh1hrA5u3owhPk7bdT5Fx2zAOrX/r2ZbrrxoyMly7vtKoBCSu4zR9/f0shzjGSYbJY5KbsbrlTGd0CtJA=" X-RZG-CLASS-ID: mo05 Received: from [IPv6:2003:a:e7a:6200:246c:2a8b:f45a:a33d] by smtp.strato.de (RZmta 43.11 AUTH) with ESMTPSA id 608bdcu5Q8wOHQU (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 26 Jun 2018 10:58:24 +0200 (CEST) Subject: Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller To: Boris Brezillon , Yogesh Narayan Gaur Cc: "marek.vasut@gmail.com" , "broonie@kernel.org" , Fabio Estevam , David Wolfe , "dwmw2@infradead.org" , "richard@nod.at" , Prabhakar Kushwaha , Han Xu , "linux-kernel@vger.kernel.org" , "linux-spi@vger.kernel.org" , "linux-mtd@lists.infradead.org" , "miquel.raynal@bootlin.com" , "computersforpeace@gmail.com" References: <1527686082-15142-1-git-send-email-frieder.schrempf@exceet.de> <20180611121618.40f4b609@bbrezillon> <20180612091328.67734adb@bbrezillon> <20180615145019.734f23a9@bbrezillon> <20180615155541.4f43e9bb@bbrezillon> <20180618211536.0bf44f55@bbrezillon> <20180619092832.3b6c8f22@bbrezillon> <20180619104627.31cfd22e@bbrezillon> From: Frieder Schrempf Message-ID: Date: Tue, 26 Jun 2018 10:58:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180619104627.31cfd22e@bbrezillon> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Boris, hi Yogesh, first, thank you for testing and debugging the new driver. On 19.06.2018 10:46, Boris Brezillon wrote: > On Tue, 19 Jun 2018 08:31:25 +0000 > Yogesh Narayan Gaur wrote: > [...] >>> >>> On Tue, 19 Jun 2018 07:10:37 +0000 >>> Yogesh Narayan Gaur wrote: >>> >>>> Let us take below layout of memory address space map. >>>> QuadSPI Controller can access range from 0x2000_0000 - >>>> 0x2FFF_FFFF i.e. 256 >>> MB address space reserved and it is having 4 slave devices >>> connected. >>>> These slave devices[of size 64MB, 64MB, 32MB and 64MB ] are >>>> connected at below address 0x2000_0000, 0x2400_0000, 0x2A00_0000, >>>> 0x2C00_0000 i.e. there is gap of 32MB from 0x2800_0000 to >>>> 0x29FF_FFFF. >>> >>> Okay, I'm fine with pre-reserving 32MB per chip select. >>> >>>> >>>> As per my understanding of the controller, flash XX top address, >>>> register should >>> have below values: >>>> QUADSPI_SFA1AD - 0x0 >>>> QUADSPI_SFA2AD - 0x400_0000 >>>> QUADSPI_SFB1AD - 0xA00_0000 >>>> QUADSPI_SFB2AD - 0xC00_0000 >>>> And Register QUADSPI_SFAR should point to the range for the flash >>>> in which >>> operation is happening. >> >> My mistake values of these register would be for said case are: >> QUADSPI_SFA1AD - 0x400_0000 >> QUADSPI_SFA2AD - 0x800_0000 >> QUADSPI_SFB1AD - 0xC00_0000 >> QUADSPI_SFB2AD - 0x1000_0000 >> >> i.e. as per controller each register is having the Top address for >> serial flash connected at A1/A2/B1/B2 respectively. > > This is still wrong ;-). I guess you mean: > > QUADSPI_SFA1AD - 0x2400_0000 > QUADSPI_SFA2AD - 0x2800_0000 > QUADSPI_SFB1AD - 0x2C00_0000 > QUADSPI_SFB2AD - 0x3000_0000 > >> >>> >>> Wait, I thought it was supposed to be an absolute address, not one >>> relative to the 0x20000000 offset. >>> >>>> >>>> Please check Table10-32, page 1657, in [1] for more details on >>>> flash address >>> assignment. >>> >>> Yes, I still don't see where it says that having one of the range >>> with a zero size is forbidden, or anything mentioning a required >>> alignment. >>>> >>>> But say if I assign address to register QUADSPI_SFA2AD as "0 + 2 >>>> * - >>>> ahb_buf_size" then this address value is not correct as per the >>>> value range >>> explained in above mentioned table. >>> >>> Why? If the SFA1AD is set to zero, that should not, right? >> What this table says that for TOP_ADDR_MEMA1 defines the top address >> for flash connected at A1 and any address space between >> TOP_ADDR_MEMA1 and QSPI_AMBA_BASE will be routed to Serial Flash A1. >> In my example case TOP_ADDR_MEMA1 is 0x400_0000 If assign value to >> SFAR register is "0 + 2 * ->ahb_buf_size", then this would lie in >> access range of Serial Flash A1 and access happens to A1 flash >> whereas we want access to A2 flash. > > No, not if SFA1AD is 0x20000000, because then the address range for CS0 > would be 0x20000000 -> 0x20000000. > > If you look at the code, you'll see that I adjust the CS mapping > dynamically, making the one being access use the range > 0x20000000 -> (0x20000000 + 2 * ->ahb_buf_size) and assigning a 0-size > range for the other ones (either 0x20000000 -> 0x20000000 or > (0x20000000 + 2 * ->ahb_buf_size) -> (0x20000000 + 2 * ->ahb_buf_size)) > >> >> For access of serial flash A2, any address space access between >> TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1 would be routed to serial flash A2. >> Thus to access A2 flash, SFAR would be in range from 0x400_0000 and >> 0x800_0000 > > I understand what you're explaining, what I don't get is why the QSPI > IP doesn't cope with a 0-size range. If you have SFA1AD set to > 0x20000000 and SFA2AD set so 0x20000800, I would except any access to > the 0x20000000 -> 0x20000800 range to be routed to CS1 not CS0. But > apparently it's not working like that. But it should definitely be possible to have 0-size ranges in the mapping. At least the RM for the i.MX6UL says: "In case single die flash devices, TOP_ADDR_MEMA2 and TOP_ADDR_MEMB2 should be initialized/programmed to TOP_ADDR_MEMA1 and TOP_ADDR_MEMB1 respectively- in effect, setting the size of these devices to 0. This would ensure that the complete memory map is assigned to only one flash device." Yogesh, can you test if it works with the fixed mapping proposed above, reserving a fixed range of 2 * ahb_buf_size for each chip? Thanks, Frieder