drivers/spi/spi-dw-core.c

96 	 * proceed with data transfer. So in order to activate the SPI
225 	 * final stage of the transfer. By doing so we'll get the next IRQ
239 	 * have the TXE IRQ flood at the final stage of the transfer.
362 	 * will be adjusted at the final stage of the IRQ-based SPI transfer
377  * The iterative procedure of the poll-based transfer is simple: write as much
382  * Note this method the same way as the IRQ-based transfer won't work well for
387 				struct spi_transfer *transfer)
400 		spi_delay_exec(&delay, transfer);
414 			       struct spi_transfer *transfer)
419 		.dfs = transfer->bits_per_word,
420 		.freq = transfer->speed_hz,
425 	dws->n_bytes = roundup_pow_of_two(BITS_TO_BYTES(transfer->bits_per_word));
426 	dws->tx = (void *)transfer->tx_buf;
427 	dws->tx_len = transfer->len / dws->n_bytes;
428 	dws->rx = transfer->rx_buf;
438 	transfer->effective_speed_hz = dws->current_freq;
440 	/* Check if current transfer is a DMA transaction */
441 	if (host->can_dma && host->can_dma(host, spi, transfer))
448 		ret = dws->dma_ops->dma_setup(dws, transfer);
456 		return dws->dma_ops->dma_transfer(dws, transfer);
458 		return dw_spi_poll_transfer(dws, transfer);
500 	 * Calculate the total length of the EEPROM command transfer and
517 	 * buffer. If it's a transfer with data to be sent, also copy it into the
704 	 * fatal, since the transfer procedure preemption may cause the Tx FIFO
706 	 * transfer will most likely cause the data loss. Secondly the
707 	 * EEPROM-read or Read-only DW SPI transfer modes imply the incoming
719 	 * here just won't keep up with the SPI bus data transfer. Such
737 	 * would be due to an error detected on the data transfer.