On 01/31/2019 01:55 PM, Boris Brezillon wrote: > On Wed, 30 Jan 2019 15:08:47 +0000 > <Tudor.Ambarus@xxxxxxxxxxxxx> 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-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >