[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190131125504.3eff449d@bbrezillon>
Date: Thu, 31 Jan 2019 12:55:19 +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:
> +
> +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?
> + }
> +
> + /* Set data enable */
> + if (op->data.nbytes)
> + cfg->ifr |= QSPI_IFR_DATAEN;
> +
> + ret = atmel_qspi_set_address_mode(cfg, op);
> + if (ret)
> + return ret;
>
> /* Clear pending interrupts */
> (void)atmel_qspi_readl(aq, QSPI_SR);
>
> /* Set QSPI Instruction Frame registers */
> - atmel_qspi_writel(aq, QSPI_IAR, iar);
> - atmel_qspi_writel(aq, QSPI_ICR, icr);
> - atmel_qspi_writel(aq, QSPI_IFR, ifr);
> + atmel_qspi_writel(aq, QSPI_IAR, cfg->iar);
> + if (op->data.dir == SPI_MEM_DATA_OUT)
> + atmel_qspi_writel(aq, QSPI_ICR, cfg->icr);
> + else
> + atmel_qspi_writel(aq, QSPI_RICR, cfg->icr);
> + atmel_qspi_writel(aq, QSPI_IFR, cfg->ifr);
> +
> + return 0;
> +}
Powered by blists - more mailing lists