Hi,
On 12/24/20 03:39, Chuanhong Guo wrote:
On Thu, Dec 24, 2020 at 12:52 AM Rafaël Carré <fun...@videolan.org> wrote:
diff --git
a/target/linux/ramips/patches-5.4/304-HACK-spi-mt7621-rt6855a-fix.patch
b/target/linux/ramips/patches-5.4/304-HACK-spi-mt7621-rt6855a-fix.patch
new file mode 100644
index 0000000000..972e969fc4
--- /dev/null
+++ b/target/linux/ramips/patches-5.4/304-HACK-spi-mt7621-rt6855a-fix.patch
@@ -0,0 +1,35 @@
+From cbc220c515f2b387462795b730b52dea96687885 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Rafa=C3=ABl=20Carr=C3=A9?= <fun...@videolan.org>
+Date: Wed, 23 Dec 2020 14:18:31 +0100
+Subject: [PATCH 2/5] HACK: spi-mt7621: rt6855a fix
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+TODO: no idea what this does or if it's needed on other targets
+using this driver.
This spi controller doesn't provide us with chipselect control, so
the maximum transfer size is limited to the buffer size of
MOREBUF mode.
In order to get rid of that limit, we need to hold chipselect pins
ourselves. It's accomplished in spi-mt7621.c this way:
1. set RS_SLAVE_SEL to 7 so that controller controls
nonexistent CS7 for every transfer.
2. set actual chipselect pins by configuring CS polarity
in SPI_CS_POLAR register.
Now we can trigger the controller to do multiple transfers
without deactivating chipselects in between, thus the
transfer size limit is lifted for this controller.
Datasheet for MT7688 is publicly available:
https://labs.mediatek.com/en/download/50WkbgbH
and you can find register details there.
Thanks for the explanation.
I had a look at the datasheet, also at the commits log of spi-mt7621.c.
This also explains why I had to use dd bs=32 to get correct MTD reads.
I am still a bit confused by the difference between chipselect and
slaveselect.
On my target "rs_slave_sel" needs to have value "0 (default is flash)"
to be able to read flash.
https://en.wikipedia.org/wiki/Chip_select starts with "Chip select (CS)
or slave select (SS)" so they can be synonymous. I guess in this case
the rs_slave_sel does something different from toggling the chipselect
pin of the (flash) SPI slave.
I also tried different values of cs_polar in SPI_CS_POLAR, but they
don't seem to have any effect, the flash can always be read as long as
rs_slave_sel stays 0.
I am not sure what else to try or where to look at.
Should I try a different version of vendor driver (bbu_spiflash.c)
maybe, to gather some more informations on this rt6855a SoC ?
Another thing, I noticed "master->num_chipselect = 2;" in the driver,
is there a reason for this limit, rather than 8 as rs_slave_sel is 3
bits? (or 7 to keep device 7 as non-existent) ?
+
+Signed-off-by: Rafaël Carré <fun...@videolan.org>
+---
+ drivers/spi/spi-mt7621.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/spi/spi-mt7621.c b/drivers/spi/spi-mt7621.c
+index 2c3b7a2a1ec7..58fb028ed776 100644
+--- a/drivers/spi/spi-mt7621.c
++++ b/drivers/spi/spi-mt7621.c
+@@ -87,7 +87,10 @@ static void mt7621_spi_set_cs(struct spi_device *spi, int
enable)
+ * reliably)
+ */
+ master = mt7621_spi_read(rs, MT7621_SPI_MASTER);
+- master |= MASTER_RS_SLAVE_SEL | MASTER_MORE_BUFMODE;
++ master |= MASTER_MORE_BUFMODE;
++#ifndef CONFIG_SOC_RT6855A
++ master |= MASTER_RS_SLAVE_SEL;
++#endif
+ master &= ~MASTER_FULL_DUPLEX;
+ mt7621_spi_write(rs, MT7621_SPI_MASTER, master);
+
+--
+2.27.0
+
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
