In general we should avoid calling malloc() and free() repeatedly in
U-Boot lest we turn it into tianocore. In SPL this can make SPI flash
unusable since free() is often a nop and allocation space is limited.
In any case, these seems no need for malloc() since the number of bytes
is very small, perhaps less than 8.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: d13f5b254a (spi: Extend the core to ease integration of SPI
memory controllers)
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
(cherry picked from commit ca2abb75a086d8b0bdb51689f331ba8f1a146379)
Change-Id: Ia76abf7491780b1984eb81c6c78796bcc0141095
Add check if exec_op is set before calling it.
At the moment it is called unconditionally, which leads to a crash if it
is not set correctly.
Signed-off-by: Bernhard Messerklinger <bernhard.messerklinger@br-automation.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
(cherry picked from commit 567a3eb7956f98af4ed065499898c6d0ac6443c7)
Change-Id: Ie9fdf0cbee364fc33965e3234d7457702bd0120f
It is necessary to call spi_claim_bus() before starting any SPI
transactions and this restriction would also apply when calling spi-mem
operations. Therefore claim and release bus before requesting transfer
via exec_op.
Change-Id: I27bb7e70536178101e26c28b28d1c64b0d07f064
Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> #zynq-microzed
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
(cherry picked from commit 76094485e462d1bed6c37ed465d1fcb341d94531)
Extend spi_mem_adjust_op_size() to take spi->max_write_size and
spi->max_read_size into account.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> #zynq-microzed
Change-Id: I22b4bf3f6f35de38297aa86edd38d4bc401fb23e
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
(cherry picked from commit 12563f768ed7357d52bc15773b76cbeca6407d92)
SPI controllers support all types of SPI modes including dual/quad bus
widths. Therefore remove constraint wrt SPI mode from spi-mem layer.
Change-Id: I120f8ff89e1342fc615899d6e4b997d6d96e41c1
Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> #zynq-microzed
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
(cherry picked from commit 6d373e523f899c5a8f8808327215e3b9eb3f92f4)
Some controllers are exposing high-level interfaces to access various
kind of SPI memories. Unfortunately they do not fit in the current
spi_controller model and usually have drivers placed in
drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI
memories in general.
This is an attempt at defining a SPI memory interface which works for
all kinds of SPI memories (NORs, NANDs, SRAMs).
Change-Id: I5b907d51232777b54366a589a75b3b1ce1f54dd2
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jagan Teki <jagan@openedev.com>
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
(cherry picked from commit e0bc8d8542f7bd34e5a6722d3ae41bcf9ca044af)
Jon Lin
Simon Glass
Bernhard Messerklinger
Vignesh R
Boris Brezillon