On 10/28/2022 11:55 AM, Mika Westerberg wrote:
Hi,
On Fri, Oct 28, 2022 at 11:42:09AM +0530, Gole, Dhruva wrote:
Hi Mika,
On 10/25/2022 12:16 PM, Mika Westerberg wrote:
This allows us to get rid of the checks in the intel_spi_[sh]w_cycle()
and makes it possible for the SPI-NOR core to split the transaction into
smaller chunks as needed.
If I understand correctly, the controller ops are called from spi-mem.c, and
spi_mem_adjust_op does exist and on it's own does "split a data transfer
operation into multiple ones"
So is this really something that you require the controller to do and
can we not rely on spi-mem.c to do it's thing instead?
How does it know the size supported by the hardware? I think this is the
reason spi_mem_adjust_op was introduced but I may be mistaken.'
The following piece of code might help:
op->data.nbytes = min3((size_t)op->data.nbytes,
spi_max_transfer_size(mem->spi),
spi_max_message_size(mem->spi)
I believe this will help it know the size supported by the hardware.
and on the controller side:
in case of cadence I have seen it pickup the fifo depth from DTSI, for eg.
arch/arm64/boot/dts/ti/k3-am62-main.dtsi: cdns,fifo-depth = <256>;
I would like to point you to another controller spi-cadence-quadspi.c
that also doesn't have it's own adjust_op_size but I haven't seen any issues
as such
inspite. This is because everything first goes through spi-mem.c then onto
the controllers drivers.
Well Intel SPI driver did not not have any issues previously either
because it handled the read/write split internally but SFDP read is done
through "register read side" which only supported max 64-byte read until
now :-)
--
Regards,
Dhruva Gole <d-gole@xxxxxx>
