On 01/31/2019 01:55 PM, Boris Brezillon wrote:
> On Wed, 30 Jan 2019 15:08:47 +0000
> <tudor.amba...@microchip.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?
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?
>
>> + }
>> +
>> + /* 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;
>> +}
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
