The CSI IP found inside the Renesas RZ/V2M SoC supports
both SPI host and SPI target roles.
When working in target mode, the CSI IP has the option
of using its Slave Selection (SS) pin to enable TX and RX
operations. Since the SPI target cannot control the clock,
when working as target it's best not to stop operations
during a transfer, as by doing so the IP will not send or
receive data, regardless of clock and active level on pin SS.
A side effect from not stopping operations is that the RX
FIFO needs to be flushed, word by word, when RX data needs
to be discarded.
Finally, when in target mode timings are tighter, as missing a
deadline translates to errors being thrown, resulting in
aborting the transfer. In order to speed things up, we can
avoid waiting for the TX FIFO to be empty, we can just wait
for the RX FIFO to contain at least the number of words that
we expect.
Add target support to the currently existing CSI driver.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Link: https://lore.kernel.org/r/20230927162508.328736-3-fabrizio.castro.jz@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
"unsigned int" is more appropriate than "int" for the members
of "struct rzv2m_csi_priv".
Using void* rather than u8* for txbuf and rxbuf allows for
the removal of some type casting.
Remove the unnecessary casting of "data" to "struct rzv2m_csi_priv*"
in function "rzv2m_csi_irq_handler".
Also, members "bytes_per_word" and "errors" introduce gaps
in the structure.
Adjust "struct rzv2m_csi_priv" and its members usage accordingly.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230718192453.543549-3-fabrizio.castro.jz@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Clock "csiclk" gets divided by 2 * CSI_CLKSEL_CKS in order to generate
the serial clock (output from master), with CSI_CLKSEL_CKS ranging from
0x1 (that means "csiclk" is divided by 2) to 0x3FFF ("csiclk" is divided
by 32766). CSI_CKS_MAX is used for referring to the setting
corresponding to the maximum frequency divider.
Value 0x3FFF for CSI_CKS_MAX doesn't really means much to the reader
without an explanation and a more readable definition.
Add a comment with a meaningful description and also replace value
0x3FFF with the corresponding GENMASK, to make it very clear what the
macro means.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20230715010407.1751715-4-fabrizio.castro.jz@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230707071119.3394198-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
