[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190131130137.52b592f8@bbrezillon>
Date: Thu, 31 Jan 2019 13:01:50 +0100
From: Boris Brezillon <bbrezillon@...nel.org>
To: <Tudor.Ambarus@...rochip.com>
Cc: <broonie@...nel.org>, <Nicolas.Ferre@...rochip.com>,
<alexandre.belloni@...tlin.com>, <Ludovic.Desroches@...rochip.com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-spi@...r.kernel.org
Subject: Re: [PATCH 9/9] spi: atmel-quadspi: add support for sam9x60 qspi
controller
On Wed, 30 Jan 2019 15:08:47 +0000
<Tudor.Ambarus@...rochip.com> wrote:
> +/*
> + * atmel_qspi_set_address_mode() - set address mode.
> + * @cfg: contains register values
> + * @op: describes a SPI memory operation
> + *
> + * The controller allows 24 and 32-bit addressing while NAND-flash requires
> + * 16-bit long. Handling 8-bit long addresses is done using the option field.
> + * For the 16-bit addresses, the workaround depends of the number of requested
> + * dummy bits. If there are 8 or more dummy cycles, the address is shifted and
> + * sent with the first dummy byte. Otherwise opcode is disabled and the first
> + * byte of the address contains the command opcode (works only if the opcode and
> + * address use the same buswidth). The limitation is when the 16-bit address is
> + * used without enough dummy cycles and the opcode is using a different buswidth
> + * than the address.
Too bad they didn't patch the IP to support 1 to 4 address bytes
instead of only 3 or 4 :-(.
Powered by blists - more mailing lists