On Mon, 2019-04-29 at 08:50 +0800, Weijie Gao wrote:
On Sun, 2019-04-28 at 17:30 +0530, Jagan Teki wrote:
On Sun, Apr 28, 2019 at 6:54 AM Weijie Gao weijie.gao@mediatek.com wrote:
On Sat, 2019-04-27 at 21:38 +0530, Jagan Teki wrote:
On Fri, Apr 26, 2019 at 2:53 PM Weijie Gao weijie.gao@mediatek.com wrote:
This patch adds spi-mem driver for MediaTek MT7629 SoC to access SPI-NOR and SPI-NAND flashes.
Cc: Jagan Teki jagan@openedev.com Signed-off-by: Weijie Gao weijie.gao@mediatek.com
drivers/spi/Kconfig | 9 ++ drivers/spi/Makefile | 1 + drivers/spi/mtk_spimem.c | 325 +++++++++++++++++++++++++++++++++++++++++++++++
Do we really need spimen on the name? I prefer spi as it is, what is the notation used by Linux I think spi itself, please check it.
This controller is originally designed for accessing SPI-NAND flashes. How about the name mtk-snfi, which means Serial NAND(NOR) flash interface?
is the same name used in Linux?
This driver currently doesn't exist in Linux.
Linux kernel still uses the original mtk_qspi driver (mtk-quadspi), because the spi-nor framework in kernel provides abstract interfaces (not spi-mem) for high-level spi flash controllers.
Before u-boot switched to the spi-nor framework from kernel, the mtk_qspi was able to work only with the old spi flash driver, with some hacks.
We have to introduce new spi-mem driver to replace mtk_qspi for u-boot because its spi-nor framework doesn't provide abstract interfaces and uses only spi-mem interface. mtk_qspi can no longer work and can not be modified for spi-mem framework.
For MT7629, the spi-nor controller (mtk_qspi) and spi-nand controller (mtk-snfi) share the same spi pins controlled by a pinmux. This is the reason we choose the snfi to control the spi-nor flash, by implementing it as a spi-mem driver.
This new driver switches pinmux to snfi before transmission and back to snor after transmission. So there's no side effects on other modules.