linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frieder Schrempf <frieder.schrempf@exceet.de>
To: Boris Brezillon <boris.brezillon@bootlin.com>,
	Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>
Cc: "marek.vasut@gmail.com" <marek.vasut@gmail.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	David Wolfe <david.wolfe@nxp.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"richard@nod.at" <richard@nod.at>,
	Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>,
	Han Xu <han.xu@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>
Subject: Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller
Date: Tue, 26 Jun 2018 10:58:24 +0200	[thread overview]
Message-ID: <bc772ef1-5f3b-518b-3a02-ffcf7143d36d@exceet.de> (raw)
In-Reply-To: <20180619104627.31cfd22e@bbrezillon>

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 <yogeshnarayan.gaur@nxp.com> wrote:
>
[...]
>>>
>>> On Tue, 19 Jun 2018 07:10:37 +0000
>>> Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> 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

  reply	other threads:[~2018-06-26  8:59 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1527686082-15142-1-git-send-email-frieder.schrempf@exceet.de>
2018-05-30 13:14 ` [PATCH 01/11] spi: spi-mem: Extend the SPI mem interface to set a custom memory name Frieder Schrempf
2018-05-30 14:32   ` Boris Brezillon
2018-05-30 15:12     ` Frieder Schrempf
2018-05-30 13:14 ` [PATCH 02/11] mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name Frieder Schrempf
2018-05-30 13:14 ` [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller Frieder Schrempf
2018-05-30 13:50   ` Yogesh Narayan Gaur
2018-05-30 14:24     ` Boris Brezillon
2018-06-01  9:14       ` Frieder Schrempf
2018-05-30 14:58   ` Boris Brezillon
2018-05-30 15:13     ` Frieder Schrempf
2018-06-05 15:00   ` Boris Brezillon
2018-06-08 11:54   ` Yogesh Narayan Gaur
2018-06-08 12:51     ` Boris Brezillon
2018-06-11  6:31       ` Yogesh Narayan Gaur
2018-06-11  7:46         ` Boris Brezillon
2018-06-11  9:38           ` Yogesh Narayan Gaur
2018-06-11 10:16             ` Boris Brezillon
2018-06-11 10:21               ` Yogesh Narayan Gaur
2018-06-12  6:42                 ` Yogesh Narayan Gaur
2018-06-12  7:13                   ` Boris Brezillon
2018-06-12  8:51                     ` Yogesh Narayan Gaur
2018-06-15 12:50                       ` Boris Brezillon
2018-06-15 13:42                         ` Yogesh Narayan Gaur
2018-06-15 13:55                           ` Boris Brezillon
2018-06-15 13:58                             ` Boris Brezillon
2018-06-18 13:32                             ` Yogesh Narayan Gaur
2018-06-18 19:15                               ` Boris Brezillon
2018-06-19  7:10                                 ` Yogesh Narayan Gaur
2018-06-19  7:28                                   ` Boris Brezillon
2018-06-19  8:31                                     ` Yogesh Narayan Gaur
2018-06-19  8:46                                       ` Boris Brezillon
2018-06-26  8:58                                         ` Frieder Schrempf [this message]
2018-06-08 20:27     ` Andy Shevchenko
2018-06-26 12:26       ` Frieder Schrempf
2018-06-26 13:18         ` Andy Shevchenko
2018-06-26 13:47           ` Boris Brezillon
2018-06-26 15:42             ` Andy Shevchenko
2018-06-18 19:27   ` Boris Brezillon
2018-05-30 13:14 ` [PATCH 04/11] dt-bindings: spi: Move and adjust the bindings for the fsl-qspi driver Frieder Schrempf
2018-05-30 15:06   ` Boris Brezillon
2018-05-30 15:14     ` Frieder Schrempf
2018-05-30 13:14 ` [PATCH 05/11] ARM: dts: Reflect change of FSL QSPI driver and remove unused properties Frieder Schrempf
2018-05-30 15:10   ` Boris Brezillon
2018-06-01  9:27     ` Frieder Schrempf
2018-05-30 13:14 ` [PATCH 06/11] arm64: " Frieder Schrempf
2018-05-30 13:14 ` [PATCH 07/11] ARM: defconfig: Use the new FSL QSPI driver under the SPI framework Frieder Schrempf
2018-05-30 13:14 ` [PATCH 08/11] mtd: fsl-quadspi: Remove the driver as it was replaced by spi-fsl-qspi.c Frieder Schrempf
2018-05-30 13:14 ` [PATCH 09/11] ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used Frieder Schrempf
2018-05-30 13:14 ` [PATCH 10/11] ARM64: dts: ls1046a: " Frieder Schrempf
2018-05-30 13:14 ` [PATCH 11/11] MAINTAINERS: Move the Freescale QSPI driver to the SPI framework Frieder Schrempf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc772ef1-5f3b-518b-3a02-ffcf7143d36d@exceet.de \
    --to=frieder.schrempf@exceet.de \
    --cc=boris.brezillon@bootlin.com \
    --cc=broonie@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=david.wolfe@nxp.com \
    --cc=dwmw2@infradead.org \
    --cc=fabio.estevam@nxp.com \
    --cc=han.xu@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=prabhakar.kushwaha@nxp.com \
    --cc=richard@nod.at \
    --cc=yogeshnarayan.gaur@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).