* [PATCH v2 2/2] spi: mt65xx: support wider tick delay field on IPM v59
2026-09-29 6:25 [PATCH v2 1/2] spi: dt-bindings: add SPI IPM v59 compatible for mt7987 and mt7989 Tim Kuo
@ 2026-09-29 6:25 ` Tim Kuo
2026-09-30 10:36 ` [PATCH v2 1/2] spi: dt-bindings: add SPI IPM v59 compatible for mt7987 and mt7989 Krzysztof Kozlowski
1 sibling, 0 replies; 3+ messages in thread
From: Tim Kuo @ 2026-09-29 6:25 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-spi, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Steven Liu, Sky Huang, Tim Kuo
The IPM v59 SPI IP widens the tick delay field in SPI_CMD_REG from
3 bits (bits 24:22) to 7 bits (bits 28:22), so the field width can no
longer be hardcoded in mtk_spi_hw_init().
Add a tick_dly_mask member to struct mtk_spi_compatible and use
field_prep() with the per-SoC mask instead of the open-coded
mask-and-shift, then add a mtk_ipm_v59_compat entry carrying the wider
mask along with a "mediatek,spi-ipm-v59" compatible. Any further changes
related to IPM v59 can be modified based on this compatible.
Existing IPM designs keep GENMASK(24, 22) and are functionally
unchanged.
Signed-off-by: Tim Kuo <Tim.Kuo@mediatek.com>
---
v2: remove unused tickdly offset deadcode
drivers/spi/spi-mt65xx.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index b845a599f7c6..e9ec58ce1e1f 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -4,6 +4,7 @@
* Author: Leilk Liu <leilk.liu@mediatek.com>
*/
+#include <linux/bitfield.h>
#include <linux/clk.h>
#include <linux/device.h>
#include <linux/err.h>
@@ -78,9 +79,9 @@
#define SPI_CMD_PAUSE_IE BIT(17)
#define SPI_CMD_IPM_NONIDLE_MODE BIT(19)
#define SPI_CMD_IPM_SPIM_LOOP BIT(21)
-#define SPI_CMD_IPM_GET_TICKDLY_OFFSET 22
#define SPI_CMD_IPM_GET_TICKDLY_MASK GENMASK(24, 22)
+#define SPI_CMD_IPM_V59_GET_TICKDLY_MASK GENMASK(28, 22)
#define PIN_MODE_CFG(x) ((x) / 2)
@@ -120,6 +121,7 @@
* @dma_ext: DMA address extension supported
* @no_need_unprepare: Don't unprepare the SPI clk during runtime
* @ipm_design: Adjust/extend registers to support IPM design IP features
+ * @tick_dly_mask: Tick delay field of SPI_CMD_REG, IPM designs only
*/
struct mtk_spi_compatible {
bool need_pad_sel;
@@ -128,6 +130,7 @@ struct mtk_spi_compatible {
bool dma_ext;
bool no_need_unprepare;
bool ipm_design;
+ u32 tick_dly_mask;
};
/**
@@ -187,6 +190,15 @@ static const struct mtk_spi_compatible mtk_ipm_compat = {
.enhance_timing = true,
.dma_ext = true,
.ipm_design = true,
+ .tick_dly_mask = SPI_CMD_IPM_GET_TICKDLY_MASK,
+};
+
+/* Every SoC with IPM v59 or newer shares this */
+static const struct mtk_spi_compatible mtk_ipm_v59_compat = {
+ .enhance_timing = true,
+ .dma_ext = true,
+ .ipm_design = true,
+ .tick_dly_mask = SPI_CMD_IPM_V59_GET_TICKDLY_MASK,
};
static const struct mtk_spi_compatible mt6765_compat = {
@@ -226,6 +238,7 @@ static const struct mtk_spi_compatible mt6991_compat = {
.enhance_timing = true,
.dma_ext = true,
.ipm_design = true,
+ .tick_dly_mask = SPI_CMD_IPM_GET_TICKDLY_MASK,
};
/*
@@ -241,6 +254,9 @@ static const struct of_device_id mtk_spi_of_match[] = {
{ .compatible = "mediatek,spi-ipm",
.data = (void *)&mtk_ipm_compat,
},
+ { .compatible = "mediatek,spi-ipm-v59",
+ .data = (void *)&mtk_ipm_v59_compat,
+ },
{ .compatible = "mediatek,mt2701-spi",
.data = (void *)&mtk_common_compat,
},
@@ -366,7 +382,7 @@ static int mtk_spi_hw_init(struct spi_controller *host,
struct spi_device *spi)
{
u16 cpha, cpol;
- u32 reg_val;
+ u32 reg_val, mask;
struct mtk_chip_config *chip_config = spi->controller_data;
struct mtk_spi *mdata = spi_controller_get_devdata(host);
@@ -443,10 +459,10 @@ static int mtk_spi_hw_init(struct spi_controller *host,
/* tick delay */
if (mdata->dev_comp->enhance_timing) {
if (mdata->dev_comp->ipm_design) {
+ mask = mdata->dev_comp->tick_dly_mask;
reg_val = readl(mdata->base + SPI_CMD_REG);
- reg_val &= ~SPI_CMD_IPM_GET_TICKDLY_MASK;
- reg_val |= ((chip_config->tick_delay & 0x7)
- << SPI_CMD_IPM_GET_TICKDLY_OFFSET);
+ reg_val &= ~mask;
+ reg_val |= field_prep(mask, chip_config->tick_delay);
writel(reg_val, mdata->base + SPI_CMD_REG);
} else {
reg_val = readl(mdata->base + SPI_CFG1_REG);
--
2.45.2
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH v2 1/2] spi: dt-bindings: add SPI IPM v59 compatible for mt7987 and mt7989
2026-09-29 6:25 [PATCH v2 1/2] spi: dt-bindings: add SPI IPM v59 compatible for mt7987 and mt7989 Tim Kuo
2026-09-29 6:25 ` [PATCH v2 2/2] spi: mt65xx: support wider tick delay field on IPM v59 Tim Kuo
@ 2026-09-30 10:36 ` Krzysztof Kozlowski
1 sibling, 0 replies; 3+ messages in thread
From: Krzysztof Kozlowski @ 2026-09-30 10:36 UTC (permalink / raw)
To: Tim Kuo
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, linux-spi,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Steven Liu, Sky Huang
On Tue, Sep 29, 2026 at 02:25:15PM +0800, Tim Kuo wrote:
> MTK mt7987 and mt7989 SPI hardware has been updated to IPM v59 SPI IP and
> it differs from earlier IPM designs, most visibly in the tick delay field
> of SPI_CMD_REG, so it needs its own fallback compatible rather than reusing
> "mediatek,spi-ipm".
>
> Signed-off-by: Tim Kuo <Tim.Kuo@mediatek.com>
> ---
> v2: Add mt7987 and mt7989 real device compatible
>
> .../devicetree/bindings/spi/mediatek,spi-mt65xx.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
> index 3bf3eb1f8728..d2c740572d85 100644
> --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
> +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml
> @@ -39,6 +39,11 @@ properties:
> - mediatek,mt7988-spi-single
> - mediatek,mt8188-spi-ipm
> - const: mediatek,spi-ipm
> + - items:
> + - enum:
> + - mediatek,mt7987-spi
> + - mediatek,mt7989-spi
> + - const: mediatek,spi-ipm-v59
No, look at the binding and recent commits. This should be a specific
compatible. Git history easily tells you that.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 3+ messages in thread