* [PATCH v6 09/16] soc: mediatek: cmdq: add write_s_mask function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
add write_s_mask function in cmdq helper functions which
writes value contains in internal register to address
with mask and large dma access support.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 23 +++++++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h | 19 ++++++++++++++++++-
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ee24c0ec0a24..58a414790471 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -241,6 +241,29 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s);
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask)
+{
+ struct cmdq_instruction inst = { {0} };
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.mask = 0;
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.src_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.src_reg = src_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index ee67dd3b86f5..8ef87e1bd03b 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -60,6 +60,7 @@ enum cmdq_code {
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
CMDQ_CODE_WRITE_S = 0x90,
+ CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index d623f1aa7814..ca9c75fd8125 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -110,7 +110,6 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
* @high_addr_reg_idx: internal register ID which contains high address of pa
* @addr_low: low address of pa
* @src_reg_idx: the CMDQ internal register ID which cache source value
- * @mask: the specified target address mask, use U32_MAX if no need
*
* Return: 0 for success; else the error code is returned
*
@@ -122,6 +121,24 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx);
+/**
+ * cmdq_pkt_write_s_mask() - append write_s with mask command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @src_reg_idx: the CMDQ internal register ID which cache source value
+ * @mask: the specified target address mask, use U32_MAX if no need
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask);
+
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
--
2.18.0
^ permalink raw reply related
* [PATCH v6 06/16] soc: mediatek: cmdq: add address shift in jump
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add address shift when compose jump instruction
to compatible with 35bit format.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index c67081759728..98f23ba3ba47 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -291,7 +291,8 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
/* JUMP to end */
inst.op = CMDQ_CODE_JUMP;
- inst.value = CMDQ_JUMP_PASS;
+ inst.value = CMDQ_JUMP_PASS >>
+ cmdq_mbox_shift(((struct cmdq_client *)pkt->cl)->chan);
err = cmdq_pkt_append_command(pkt, inst);
return err;
--
2.18.0
^ permalink raw reply related
* [PATCH v6 15/16] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add clear parameter to let client decide if
event should be clear to 0 after GCE receive it.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
drivers/soc/mediatek/mtk-cmdq-helper.c | 5 +++--
include/linux/mailbox/mtk-cmdq-mailbox.h | 3 +--
include/linux/soc/mediatek/mtk-cmdq.h | 5 +++--
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 7daaabc26eb1..a065b3a412cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -488,7 +488,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
if (mtk_crtc->cmdq_client) {
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
- cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
+ cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
mtk_crtc_ddp_config(crtc, cmdq_handle);
cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 5cf9e71b7900..9e9a4c81553a 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -315,15 +315,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
{
struct cmdq_instruction inst = { {0} };
+ u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
inst.op = CMDQ_CODE_WFE;
- inst.value = CMDQ_WFE_OPTION;
+ inst.value = CMDQ_WFE_OPTION | clear_option;
inst.event = event;
return cmdq_pkt_append_command(pkt, inst);
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 3f6bc0dfd5da..42d2a30e6a70 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -27,8 +27,7 @@
* bit 16-27: update value
* bit 31: 1 - update, 0 - no update
*/
-#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | \
- CMDQ_WFE_WAIT_VALUE)
+#define CMDQ_WFE_OPTION (CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE)
/** cmdq event maximum */
#define CMDQ_MAX_EVENT 0x3ff
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 9494b293bad9..3216ccfff4a9 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -183,11 +183,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
- * @event: the desired event type to "wait and CLEAR"
+ * @event: the desired event type to wait
+ * @clear: clear event or not after event arrive
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
/**
* cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
--
2.18.0
^ permalink raw reply related
* [PATCH v6 13/16] soc: mediatek: cmdq: export finalize function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Export finalize function to client which helps append eoc and jump
command to pkt. Let client decide call finalize or not.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Acked-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 0dfcd1787e65..7daaabc26eb1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
mtk_crtc_ddp_config(crtc, cmdq_handle);
+ cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
}
#endif
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 4b07da56c7bb..ebcdd30cd783 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -391,7 +391,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
}
EXPORT_SYMBOL(cmdq_pkt_assign);
-static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
+int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction inst = { {0} };
int err;
@@ -411,6 +411,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
return err;
}
+EXPORT_SYMBOL(cmdq_pkt_finalize);
static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
{
@@ -445,10 +446,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
unsigned long flags = 0;
struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
- err = cmdq_pkt_finalize(pkt);
- if (err < 0)
- return err;
-
pkt->cb.cb = cb;
pkt->cb.data = data;
pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 28a50c3cf6a1..703cffcd55bd 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -244,6 +244,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
*/
int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
+/**
+ * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
+ * @pkt: the CMDQ packet
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
+
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
* packet and call back at the end of done packet
--
2.18.0
^ permalink raw reply related
* [PATCH v6 12/16] soc: mediatek: cmdq: add write_s_mask value function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
add write_s_mask_value function in cmdq helper functions which
writes a constant value to address with mask and large dma
access support.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 21 +++++++++++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 15 +++++++++++++++
2 files changed, 36 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 12095a1b701b..4b07da56c7bb 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -293,6 +293,27 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask)
+{
+ struct cmdq_instruction inst = { {0} };
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index bb36750be58c..28a50c3cf6a1 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -165,6 +165,21 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
u16 addr_low, u32 value);
+/**
+ * cmdq_pkt_write_s_mask_value() - append write_s command with mask to the CMDQ
+ * packet which write value to a physical
+ * address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ * @mask: the specified target mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask);
+
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
--
2.18.0
^ permalink raw reply related
* [PATCH v6 03/16] mailbox: cmdq: support mt6779 gce platform definition
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add gce v4 hardware support with different thread number and shift.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/mailbox/mtk-cmdq-mailbox.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 4dbee9258127..9994ac9426d6 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -572,10 +572,12 @@ static const struct dev_pm_ops cmdq_pm_ops = {
static const struct gce_plat gce_plat_v2 = {.thread_nr = 16};
static const struct gce_plat gce_plat_v3 = {.thread_nr = 24};
+static const struct gce_plat gce_plat_v4 = {.thread_nr = 24, .shift = 3};
static const struct of_device_id cmdq_of_ids[] = {
{.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
{.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
+ {.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
{}
};
--
2.18.0
^ permalink raw reply related
* [PATCH v6 11/16] soc: mediatek: cmdq: add write_s value function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
add write_s function in cmdq helper functions which
writes a constant value to address with large dma
access support.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 14 ++++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 13 +++++++++++++
2 files changed, 27 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 02ac0ca23f6e..12095a1b701b 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -279,6 +279,20 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value)
+{
+ struct cmdq_instruction inst = { {0} };
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index c07baa1534ca..bb36750be58c 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -152,6 +152,19 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx, u32 mask);
+/**
+ * cmdq_pkt_write_s_value() - append write_s command to the CMDQ packet which
+ * write value to a physical address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value);
+
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
--
2.18.0
^ permalink raw reply related
* [PATCH v6 01/16] dt-binding: gce: add gce header file for mt6779
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add documentation for the mt6779 gce.
Add gce header file defined the gce hardware event,
subsys number and constant for mt6779.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
.../devicetree/bindings/mailbox/mtk-gce.txt | 8 +-
include/dt-bindings/gce/mt6779-gce.h | 222 ++++++++++++++++++
2 files changed, 227 insertions(+), 3 deletions(-)
create mode 100644 include/dt-bindings/gce/mt6779-gce.h
diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
index 7b13787ab13d..82c0a83fed09 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -9,7 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to
mailbox.txt for generic information about mailbox device-tree bindings.
Required properties:
-- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce"
+- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or
+ "mediatek,mt6779-gce".
- reg: Address range of the GCE unit
- interrupts: The interrupt signal from the GCE block
- clock: Clocks according to the common clock binding
@@ -36,8 +37,9 @@ Optional properties for a client device:
start_offset: the start offset of register address that GCE can access.
size: the total size of register address that GCE can access.
-Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'
-or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids.
+Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h',
+'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as
+sub-system ids, thread priority, event ids.
Example:
diff --git a/include/dt-bindings/gce/mt6779-gce.h b/include/dt-bindings/gce/mt6779-gce.h
new file mode 100644
index 000000000000..06101316ace4
--- /dev/null
+++ b/include/dt-bindings/gce/mt6779-gce.h
@@ -0,0 +1,222 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Dennis-YC Hsieh <dennis-yc.hsieh@mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_GCE_MT6779_H
+#define _DT_BINDINGS_GCE_MT6779_H
+
+#define CMDQ_NO_TIMEOUT 0xffffffff
+
+/* GCE HW thread priority */
+#define CMDQ_THR_PRIO_LOWEST 0
+#define CMDQ_THR_PRIO_1 1
+#define CMDQ_THR_PRIO_2 2
+#define CMDQ_THR_PRIO_3 3
+#define CMDQ_THR_PRIO_4 4
+#define CMDQ_THR_PRIO_5 5
+#define CMDQ_THR_PRIO_6 6
+#define CMDQ_THR_PRIO_HIGHEST 7
+
+/* GCE subsys table */
+#define SUBSYS_1300XXXX 0
+#define SUBSYS_1400XXXX 1
+#define SUBSYS_1401XXXX 2
+#define SUBSYS_1402XXXX 3
+#define SUBSYS_1502XXXX 4
+#define SUBSYS_1880XXXX 5
+#define SUBSYS_1881XXXX 6
+#define SUBSYS_1882XXXX 7
+#define SUBSYS_1883XXXX 8
+#define SUBSYS_1884XXXX 9
+#define SUBSYS_1000XXXX 10
+#define SUBSYS_1001XXXX 11
+#define SUBSYS_1002XXXX 12
+#define SUBSYS_1003XXXX 13
+#define SUBSYS_1004XXXX 14
+#define SUBSYS_1005XXXX 15
+#define SUBSYS_1020XXXX 16
+#define SUBSYS_1028XXXX 17
+#define SUBSYS_1700XXXX 18
+#define SUBSYS_1701XXXX 19
+#define SUBSYS_1702XXXX 20
+#define SUBSYS_1703XXXX 21
+#define SUBSYS_1800XXXX 22
+#define SUBSYS_1801XXXX 23
+#define SUBSYS_1802XXXX 24
+#define SUBSYS_1804XXXX 25
+#define SUBSYS_1805XXXX 26
+#define SUBSYS_1808XXXX 27
+#define SUBSYS_180aXXXX 28
+#define SUBSYS_180bXXXX 29
+#define CMDQ_SUBSYS_OFF 32
+
+/* GCE hardware events */
+#define CMDQ_EVENT_DISP_RDMA0_SOF 0
+#define CMDQ_EVENT_DISP_RDMA1_SOF 1
+#define CMDQ_EVENT_MDP_RDMA0_SOF 2
+#define CMDQ_EVENT_MDP_RDMA1_SOF 3
+#define CMDQ_EVENT_MDP_RSZ0_SOF 4
+#define CMDQ_EVENT_MDP_RSZ1_SOF 5
+#define CMDQ_EVENT_MDP_TDSHP_SOF 6
+#define CMDQ_EVENT_MDP_WROT0_SOF 7
+#define CMDQ_EVENT_MDP_WROT1_SOF 8
+#define CMDQ_EVENT_DISP_OVL0_SOF 9
+#define CMDQ_EVENT_DISP_2L_OVL0_SOF 10
+#define CMDQ_EVENT_DISP_2L_OVL1_SOF 11
+#define CMDQ_EVENT_DISP_WDMA0_SOF 12
+#define CMDQ_EVENT_DISP_COLOR0_SOF 13
+#define CMDQ_EVENT_DISP_CCORR0_SOF 14
+#define CMDQ_EVENT_DISP_AAL0_SOF 15
+#define CMDQ_EVENT_DISP_GAMMA0_SOF 16
+#define CMDQ_EVENT_DISP_DITHER0_SOF 17
+#define CMDQ_EVENT_DISP_PWM0_SOF 18
+#define CMDQ_EVENT_DISP_DSI0_SOF 19
+#define CMDQ_EVENT_DISP_DPI0_SOF 20
+#define CMDQ_EVENT_DISP_POSTMASK0_SOF 21
+#define CMDQ_EVENT_DISP_RSZ0_SOF 22
+#define CMDQ_EVENT_MDP_AAL_SOF 23
+#define CMDQ_EVENT_MDP_CCORR_SOF 24
+#define CMDQ_EVENT_DISP_DBI0_SOF 25
+#define CMDQ_EVENT_ISP_RELAY_SOF 26
+#define CMDQ_EVENT_IPU_RELAY_SOF 27
+#define CMDQ_EVENT_DISP_RDMA0_EOF 28
+#define CMDQ_EVENT_DISP_RDMA1_EOF 29
+#define CMDQ_EVENT_MDP_RDMA0_EOF 30
+#define CMDQ_EVENT_MDP_RDMA1_EOF 31
+#define CMDQ_EVENT_MDP_RSZ0_EOF 32
+#define CMDQ_EVENT_MDP_RSZ1_EOF 33
+#define CMDQ_EVENT_MDP_TDSHP_EOF 34
+#define CMDQ_EVENT_MDP_WROT0_W_EOF 35
+#define CMDQ_EVENT_MDP_WROT1_W_EOF 36
+#define CMDQ_EVENT_DISP_OVL0_EOF 37
+#define CMDQ_EVENT_DISP_2L_OVL0_EOF 38
+#define CMDQ_EVENT_DISP_2L_OVL1_EOF 39
+#define CMDQ_EVENT_DISP_WDMA0_EOF 40
+#define CMDQ_EVENT_DISP_COLOR0_EOF 41
+#define CMDQ_EVENT_DISP_CCORR0_EOF 42
+#define CMDQ_EVENT_DISP_AAL0_EOF 43
+#define CMDQ_EVENT_DISP_GAMMA0_EOF 44
+#define CMDQ_EVENT_DISP_DITHER0_EOF 45
+#define CMDQ_EVENT_DISP_DSI0_EOF 46
+#define CMDQ_EVENT_DISP_DPI0_EOF 47
+#define CMDQ_EVENT_DISP_RSZ0_EOF 49
+#define CMDQ_EVENT_MDP_AAL_FRAME_DONE 50
+#define CMDQ_EVENT_MDP_CCORR_FRAME_DONE 51
+#define CMDQ_EVENT_DISP_POSTMASK0_FRAME_DONE 52
+#define CMDQ_EVENT_MUTEX0_STREAM_EOF 130
+#define CMDQ_EVENT_MUTEX1_STREAM_EOF 131
+#define CMDQ_EVENT_MUTEX2_STREAM_EOF 132
+#define CMDQ_EVENT_MUTEX3_STREAM_EOF 133
+#define CMDQ_EVENT_MUTEX4_STREAM_EOF 134
+#define CMDQ_EVENT_MUTEX5_STREAM_EOF 135
+#define CMDQ_EVENT_MUTEX6_STREAM_EOF 136
+#define CMDQ_EVENT_MUTEX7_STREAM_EOF 137
+#define CMDQ_EVENT_MUTEX8_STREAM_EOF 138
+#define CMDQ_EVENT_MUTEX9_STREAM_EOF 139
+#define CMDQ_EVENT_MUTEX10_STREAM_EOF 140
+#define CMDQ_EVENT_MUTEX11_STREAM_EOF 141
+#define CMDQ_EVENT_DISP_RDMA0_UNDERRUN 142
+#define CMDQ_EVENT_DISP_RDMA1_UNDERRUN 143
+#define CMDQ_EVENT_DISP_RDMA2_UNDERRUN 144
+#define CMDQ_EVENT_DISP_RDMA3_UNDERRUN 145
+#define CMDQ_EVENT_DSI0_TE 146
+#define CMDQ_EVENT_DSI0_IRQ_EVENT 147
+#define CMDQ_EVENT_DSI0_DONE_EVENT 148
+#define CMDQ_EVENT_DISP_POSTMASK0_RST_DONE 150
+#define CMDQ_EVENT_DISP_WDMA0_RST_DONE 151
+#define CMDQ_EVENT_MDP_WROT0_RST_DONE 153
+#define CMDQ_EVENT_MDP_RDMA0_RST_DONE 154
+#define CMDQ_EVENT_DISP_OVL0_RST_DONE 155
+#define CMDQ_EVENT_DISP_OVL0_2L_RST_DONE 156
+#define CMDQ_EVENT_DISP_OVL1_2L_RST_DONE 157
+#define CMDQ_EVENT_DIP_CQ_THREAD0_EOF 257
+#define CMDQ_EVENT_DIP_CQ_THREAD1_EOF 258
+#define CMDQ_EVENT_DIP_CQ_THREAD2_EOF 259
+#define CMDQ_EVENT_DIP_CQ_THREAD3_EOF 260
+#define CMDQ_EVENT_DIP_CQ_THREAD4_EOF 261
+#define CMDQ_EVENT_DIP_CQ_THREAD5_EOF 262
+#define CMDQ_EVENT_DIP_CQ_THREAD6_EOF 263
+#define CMDQ_EVENT_DIP_CQ_THREAD7_EOF 264
+#define CMDQ_EVENT_DIP_CQ_THREAD8_EOF 265
+#define CMDQ_EVENT_DIP_CQ_THREAD9_EOF 266
+#define CMDQ_EVENT_DIP_CQ_THREAD10_EOF 267
+#define CMDQ_EVENT_DIP_CQ_THREAD11_EOF 268
+#define CMDQ_EVENT_DIP_CQ_THREAD12_EOF 269
+#define CMDQ_EVENT_DIP_CQ_THREAD13_EOF 270
+#define CMDQ_EVENT_DIP_CQ_THREAD14_EOF 271
+#define CMDQ_EVENT_DIP_CQ_THREAD15_EOF 272
+#define CMDQ_EVENT_DIP_CQ_THREAD16_EOF 273
+#define CMDQ_EVENT_DIP_CQ_THREAD17_EOF 274
+#define CMDQ_EVENT_DIP_CQ_THREAD18_EOF 275
+#define CMDQ_EVENT_DIP_DMA_ERR_EVENT 276
+#define CMDQ_EVENT_AMD_FRAME_DONE 277
+#define CMDQ_EVENT_MFB_DONE 278
+#define CMDQ_EVENT_WPE_A_EOF 279
+#define CMDQ_EVENT_VENC_EOF 289
+#define CMDQ_EVENT_VENC_CMDQ_PAUSE_DONE 290
+#define CMDQ_EVENT_JPEG_ENC_EOF 291
+#define CMDQ_EVENT_VENC_MB_DONE 292
+#define CMDQ_EVENT_VENC_128BYTE_CNT_DONE 293
+#define CMDQ_EVENT_ISP_FRAME_DONE_A 321
+#define CMDQ_EVENT_ISP_FRAME_DONE_B 322
+#define CMDQ_EVENT_ISP_FRAME_DONE_C 323
+#define CMDQ_EVENT_ISP_CAMSV_0_PASS1_DONE 324
+#define CMDQ_EVENT_ISP_CAMSV_0_2_PASS1_DONE 325
+#define CMDQ_EVENT_ISP_CAMSV_1_PASS1_DONE 326
+#define CMDQ_EVENT_ISP_CAMSV_2_PASS1_DONE 327
+#define CMDQ_EVENT_ISP_CAMSV_3_PASS1_DONE 328
+#define CMDQ_EVENT_ISP_TSF_DONE 329
+#define CMDQ_EVENT_SENINF_0_FIFO_FULL 330
+#define CMDQ_EVENT_SENINF_1_FIFO_FULL 331
+#define CMDQ_EVENT_SENINF_2_FIFO_FULL 332
+#define CMDQ_EVENT_SENINF_3_FIFO_FULL 333
+#define CMDQ_EVENT_SENINF_4_FIFO_FULL 334
+#define CMDQ_EVENT_SENINF_5_FIFO_FULL 335
+#define CMDQ_EVENT_SENINF_6_FIFO_FULL 336
+#define CMDQ_EVENT_SENINF_7_FIFO_FULL 337
+#define CMDQ_EVENT_TG_OVRUN_A_INT_DLY 338
+#define CMDQ_EVENT_TG_OVRUN_B_INT_DLY 339
+#define CMDQ_EVENT_TG_OVRUN_C_INT 340
+#define CMDQ_EVENT_TG_GRABERR_A_INT_DLY 341
+#define CMDQ_EVENT_TG_GRABERR_B_INT_DLY 342
+#define CMDQ_EVENT_TG_GRABERR_C_INT 343
+#define CMDQ_EVENT_CQ_VR_SNAP_A_INT_DLY 344
+#define CMDQ_EVENT_CQ_VR_SNAP_B_INT_DLY 345
+#define CMDQ_EVENT_CQ_VR_SNAP_C_INT 346
+#define CMDQ_EVENT_DMA_R1_ERROR_A_INT_DLY 347
+#define CMDQ_EVENT_DMA_R1_ERROR_B_INT_DLY 348
+#define CMDQ_EVENT_DMA_R1_ERROR_C_INT 349
+#define CMDQ_EVENT_APU_GCE_CORE0_EVENT_0 353
+#define CMDQ_EVENT_APU_GCE_CORE0_EVENT_1 354
+#define CMDQ_EVENT_APU_GCE_CORE0_EVENT_2 355
+#define CMDQ_EVENT_APU_GCE_CORE0_EVENT_3 356
+#define CMDQ_EVENT_APU_GCE_CORE1_EVENT_0 385
+#define CMDQ_EVENT_APU_GCE_CORE1_EVENT_1 386
+#define CMDQ_EVENT_APU_GCE_CORE1_EVENT_2 387
+#define CMDQ_EVENT_APU_GCE_CORE1_EVENT_3 388
+#define CMDQ_EVENT_VDEC_EVENT_0 416
+#define CMDQ_EVENT_VDEC_EVENT_1 417
+#define CMDQ_EVENT_VDEC_EVENT_2 418
+#define CMDQ_EVENT_VDEC_EVENT_3 419
+#define CMDQ_EVENT_VDEC_EVENT_4 420
+#define CMDQ_EVENT_VDEC_EVENT_5 421
+#define CMDQ_EVENT_VDEC_EVENT_6 422
+#define CMDQ_EVENT_VDEC_EVENT_7 423
+#define CMDQ_EVENT_VDEC_EVENT_8 424
+#define CMDQ_EVENT_VDEC_EVENT_9 425
+#define CMDQ_EVENT_VDEC_EVENT_10 426
+#define CMDQ_EVENT_VDEC_EVENT_11 427
+#define CMDQ_EVENT_VDEC_EVENT_12 428
+#define CMDQ_EVENT_VDEC_EVENT_13 429
+#define CMDQ_EVENT_VDEC_EVENT_14 430
+#define CMDQ_EVENT_VDEC_EVENT_15 431
+#define CMDQ_EVENT_FDVT_DONE 449
+#define CMDQ_EVENT_FE_DONE 450
+#define CMDQ_EVENT_RSC_EOF 451
+#define CMDQ_EVENT_DVS_DONE_ASYNC_SHOT 452
+#define CMDQ_EVENT_DVP_DONE_ASYNC_SHOT 453
+#define CMDQ_EVENT_DSI0_TE_INFRA 898
+
+#endif
--
2.18.0
^ permalink raw reply related
* [PATCH v6 07/16] soc: mediatek: cmdq: add assign function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add assign function in cmdq helper which assign constant value into
internal register by index.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 24 +++++++++++++++++++++++-
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h | 14 ++++++++++++++
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 98f23ba3ba47..33153d17c9d9 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -12,6 +12,7 @@
#define CMDQ_WRITE_ENABLE_MASK BIT(0)
#define CMDQ_POLL_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_EN BIT(0)
+#define CMDQ_REG_TYPE 1
struct cmdq_instruction {
union {
@@ -21,8 +22,17 @@ struct cmdq_instruction {
union {
u16 offset;
u16 event;
+ u16 reg_dst;
+ };
+ union {
+ u8 subsys;
+ struct {
+ u8 sop:5;
+ u8 arg_c_t:1;
+ u8 arg_b_t:1;
+ u8 dst_t:1;
+ };
};
- u8 subsys;
u8 op;
};
@@ -277,6 +287,18 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_poll_mask);
+int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
+{
+ struct cmdq_instruction inst = { {0} };
+
+ inst.op = CMDQ_CODE_LOGIC;
+ inst.dst_t = CMDQ_REG_TYPE;
+ inst.reg_dst = reg_idx;
+ inst.value = value;
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_assign);
+
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index dfe5b2eb85cc..121c3bb6d3de 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -59,6 +59,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_LOGIC = 0xa0,
};
enum cmdq_cb_status {
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index a74c1d5acdf3..83340211e1d3 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -152,6 +152,20 @@ int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
*/
int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
+
+/**
+ * cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask GCE
+ * to execute an instruction that set a constant value into
+ * internal register and use as value, mask or address in
+ * read/write instruction.
+ * @pkt: the CMDQ packet
+ * @reg_idx: the CMDQ internal register ID
+ * @value: the specified value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
+
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
* packet and call back at the end of done packet
--
2.18.0
^ permalink raw reply related
* [PATCH v6] support gce on mt6779 platform
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao
This patch support gce on mt6779 platform.
Change since v5:
- spearate address shift code in client helper and mailbox controller
- separate write_s/write_s_mask and write_s_value/write_s_mask_value so that
client can decide use mask or not
- fix typo in header
Change since v4:
- do not clear disp event again in drm driver
- symbolize value 1 to jump relative
[... snip ...]
Dennis YC Hsieh (16):
dt-binding: gce: add gce header file for mt6779
mailbox: cmdq: variablize address shift in platform
mailbox: cmdq: support mt6779 gce platform definition
mailbox: mediatek: cmdq: clear task in channel before shutdown
soc: mediatek: cmdq: return send msg error code
soc: mediatek: cmdq: add address shift in jump
soc: mediatek: cmdq: add assign function
soc: mediatek: cmdq: add write_s function
soc: mediatek: cmdq: add write_s_mask function
soc: mediatek: cmdq: add read_s function
soc: mediatek: cmdq: add write_s value function
soc: mediatek: cmdq: add write_s_mask value function
soc: mediatek: cmdq: export finalize function
soc: mediatek: cmdq: add jump function
soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
soc: mediatek: cmdq: add set event function
.../devicetree/bindings/mailbox/mtk-gce.txt | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +-
drivers/mailbox/mtk-cmdq-mailbox.c | 101 ++++++--
drivers/soc/mediatek/mtk-cmdq-helper.c | 163 ++++++++++++-
include/dt-bindings/gce/mt6779-gce.h | 222 ++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 10 +-
include/linux/soc/mediatek/mtk-cmdq.h | 125 +++++++++-
7 files changed, 599 insertions(+), 33 deletions(-)
create mode 100644 include/dt-bindings/gce/mt6779-gce.h
--
2.18.0
^ permalink raw reply
* Re: [PATCH v2 1/4] ARM: dts: dove: Make the DT compliant with the ti,tfp410 binding
From: Rob Herring @ 2020-05-28 17:37 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: Laurent.pinchart, kernel, devicetree, dri-devel, linux-arm-kernel,
jason, tomi.valkeinen, airlied, shawnguo
In-Reply-To: <20200514143612.2094-2-ricardo.canuelo@collabora.com>
On Thu, May 14, 2020 at 04:36:09PM +0200, Ricardo Cañuelo wrote:
> Define a 'ports' node for 'dvi: video@39' and use the proper naming for
> the powerdown-gpios property to make it compliant with the ti,tfp410
> binding.
>
> This fills the minimum requirements to meet the binding requirements,
> port endpoints are not defined.
Just make 'ports' optional. This isn't really any better unless you add
endpoints too.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> arch/arm/boot/dts/dove-sbc-a510.dts | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/dove-sbc-a510.dts b/arch/arm/boot/dts/dove-sbc-a510.dts
> index 2bb85a9b7614..32804c981625 100644
> --- a/arch/arm/boot/dts/dove-sbc-a510.dts
> +++ b/arch/arm/boot/dts/dove-sbc-a510.dts
> @@ -132,7 +132,18 @@
> dvi: video@39 {
> compatible = "ti,tfp410";
> reg = <0x39>;
> - powerdown-gpio = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCHv3 0/2] Add support for replicators which loses context on clock removal
From: Mathieu Poirier @ 2020-05-28 17:40 UTC (permalink / raw)
To: Rob Herring
Cc: Sai Prakash Ranjan, Suzuki K Poulose, Mike Leach, devicetree,
linux-arm-kernel, linux-kernel, linux-arm-msm, Stephen Boyd
In-Reply-To: <20200528144803.GA36440@bogus>
On Thu, May 28, 2020 at 08:48:03AM -0600, Rob Herring wrote:
> On Mon, May 25, 2020 at 10:15:53AM -0600, Mathieu Poirier wrote:
> > Hi Sai,
> >
> > On Sat, May 23, 2020 at 12:06:50AM +0530, Sai Prakash Ranjan wrote:
> > > This series is mainly to add support for replicators
> > > which lose context on removing AMBA clock like on SC7180
> > > SoC where replicator in AOSS domain loses context.
> > >
> >
> > I am good with this set but need a reviewed-by on the DT binding before I can
> > add it to my tree. The same goes for your other set[1].
>
> Then why is it already in linux-next?
I wanted the patches to get exposure to linux-next before sending them on to
Greg for inclusion in the next merge window. Rest assured that I would not have
moved forward without your consent.
>
> In any case,
>
> Acked-by: Rob Herring <robh@kernel.org>
Thank you for that.
Mathieu
^ permalink raw reply
* [PATCH 0/1] Add fuel gauge to Pinbook Pro dts
From: Tobias Schramm @ 2020-05-28 17:25 UTC (permalink / raw)
To: Rob Herring, Heiko Stuebner
Cc: devicetree, linux-rockchip, linux-kernel, Tobias Schramm
Hi,
since the cw2015 fuel gauge will be supported in 5.8 this patch
adds a node for it to the Pinbook Pro device tree.
Best regards,
Tobias
Tobias Schramm (1):
arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts
.../boot/dts/rockchip/rk3399-pinebook-pro.dts | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
--
2.26.0
^ permalink raw reply
* [PATCH 1/1] arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts
From: Tobias Schramm @ 2020-05-28 17:25 UTC (permalink / raw)
To: Rob Herring, Heiko Stuebner
Cc: devicetree, linux-rockchip, linux-kernel, Tobias Schramm
In-Reply-To: <20200528172550.2324722-1-t.schramm@manjaro.org>
This commit adds cw2015 fuel gauge and battery to the Pinebook Pro dts.
Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
---
.../boot/dts/rockchip/rk3399-pinebook-pro.dts | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index 5ea281b55fe2..28afe89ca283 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
@@ -28,6 +28,13 @@ backlight: edp-backlight {
pwms = <&pwm0 0 740740 0>;
};
+ bat: battery {
+ compatible = "simple-battery";
+ charge-full-design-microamp-hours = <9800000>;
+ voltage-max-design-microvolt = <4350000>;
+ voltage-min-design-microvolt = <3000000>;
+ };
+
edp_panel: edp-panel {
compatible = "boe,nv140fhmn49";
backlight = <&backlight>;
@@ -740,6 +747,24 @@ usbc_dp: endpoint {
};
};
};
+
+ cw2015@62 {
+ compatible = "cellwise,cw2015";
+ reg = <0x62>;
+ cellwise,battery-profile = /bits/ 8 <
+ 0x17 0x67 0x80 0x73 0x6E 0x6C 0x6B 0x63
+ 0x77 0x51 0x5C 0x58 0x50 0x4C 0x48 0x36
+ 0x15 0x0C 0x0C 0x19 0x5B 0x7D 0x6F 0x69
+ 0x69 0x5B 0x0C 0x29 0x20 0x40 0x52 0x59
+ 0x57 0x56 0x54 0x4F 0x3B 0x1F 0x7F 0x17
+ 0x06 0x1A 0x30 0x5A 0x85 0x93 0x96 0x2D
+ 0x48 0x77 0x9C 0xB3 0x80 0x52 0x94 0xCB
+ 0x2F 0x00 0x64 0xA5 0xB5 0x11 0xF0 0x11
+ >;
+ cellwise,monitor-interval-ms = <5000>;
+ monitored-battery = <&bat>;
+ power-supplies = <&mains_charger>, <&fusb0>;
+ };
};
&i2s1 {
--
2.26.0
^ permalink raw reply related
* Re: [PATCH net-next 1/2] dt-bindings: net: dp83822: Add TI dp83822 phy
From: Rob Herring @ 2020-05-28 17:48 UTC (permalink / raw)
To: Dan Murphy
Cc: andrew, f.fainelli, hkallweit1, davem, netdev, linux-kernel,
devicetree
In-Reply-To: <20200514173055.15013-2-dmurphy@ti.com>
On Thu, May 14, 2020 at 12:30:54PM -0500, Dan Murphy wrote:
> Add a dt binding for the TI dp83822 ethernet phy device.
>
> CC: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> .../devicetree/bindings/net/ti,dp83822.yaml | 49 +++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,dp83822.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml
> new file mode 100644
> index 000000000000..60afd43ad3b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/net/ti,dp83822.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: TI DP83822 ethernet PHY
> +
> +allOf:
> + - $ref: "ethernet-controller.yaml#"
Not an ethernet controller. Drop. (The ethernet-phy.yaml schema will be
applied based on node name).
> +
> +maintainers:
> + - Dan Murphy <dmurphy@ti.com>
> +
> +description: |
> + The DP83822 is a low-power, single-port, 10/100 Mbps Ethernet PHY. It
> + provides all of the physical layer functions needed to transmit and receive
> + data over standard, twisted-pair cables or to connect to an external,
> + fiber-optic transceiver. Additionally, the DP83822 provides flexibility to
> + connect to a MAC through a standard MII, RMII, or RGMII interface
> +
> + Specifications about the charger can be found at:
> + http://www.ti.com/lit/ds/symlink/dp83822i.pdf
> +
> +properties:
> + reg:
> + maxItems: 1
> +
> + ti,signal-polarity-low:
What signal?
> + type: boolean
> + description: |
> + DP83822 PHY in Fiber mode only.
> + Sets the DP83822 to detect a link drop condition when the signal goes
> + high. If not set then link drop will occur when the signal goes low.
The naming is not clear that low is for link drop. So maybe:
ti,link-loss-low
Rob
^ permalink raw reply
* Re: [PATCH v1.2 4/4] dt-bindings: display: bridge: renesas, lvds: Convert binding to YAML
From: Rob Herring @ 2020-05-28 17:50 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-renesas-soc, dri-devel, Geert Uytterhoeven,
Rob Herring
In-Reply-To: <20200514214211.9036-1-laurent.pinchart+renesas@ideasonboard.com>
On Fri, 15 May 2020 00:42:11 +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car LVDS encoder text binding to YAML.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Acked-by: Maxime Ripard <mripard@kernel.org>
> ---
> Changes since v1:
>
> - Mention RZ/G1 and R2/G2 explicitly
> - Drop the part numbers in comments, only keep the SoC names
> - Use one address and size cell in the examples
> ---
> .../bindings/display/bridge/renesas,lvds.txt | 85 ------
> .../bindings/display/bridge/renesas,lvds.yaml | 248 ++++++++++++++++++
> 2 files changed, 248 insertions(+), 85 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 10/10] dt-bindings: power: supply: Cleanup charger-manager bindings
From: Rob Herring @ 2020-05-28 17:54 UTC (permalink / raw)
To: Jonathan Bakker
Cc: sre, krzk, jonghwa3.lee, tglx, kstewart, baolin.wang7, linux-pm,
devicetree, linux-kernel
In-Reply-To: <BN6PR04MB0660E57423994D19C84370A3A3BC0@BN6PR04MB0660.namprd04.prod.outlook.com>
On Thu, May 14, 2020 at 04:04:35PM -0700, Jonathan Bakker wrote:
> The bindings for charger-manager were very unclear and didn't
> specify allowable values in many cases. Clean these up to show
> what each value does and make sure all properties are documented
> here rather than using wildcards.
>
> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
> ---
> .../bindings/power/supply/charger-manager.txt | 30 ++++++++++++-------
> 1 file changed, 20 insertions(+), 10 deletions(-)
I guess you're just documenting what already exists, but I think this is
not really a binding we want to continue using...
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: renesas,du: Convert binding to YAML
From: Rob Herring @ 2020-05-28 18:52 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: dri-devel, devicetree, linux-renesas-soc, Kieran Bingham
In-Reply-To: <20200515003340.18191-1-laurent.pinchart+renesas@ideasonboard.com>
On Fri, May 15, 2020 at 03:33:40AM +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car DU text binding to YAML.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../bindings/display/renesas,du.txt | 139 ---
> .../bindings/display/renesas,du.yaml | 915 ++++++++++++++++++
A 'normal' conversion is about double the lines. I guess this is a sign
that the original was not well specified.
Maybe this can be split to reduce some of the if/then? One way is define
a common 'include' file that each specific instance can reference
[...]
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
> new file mode 100644
> index 000000000000..ca48065afe1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> @@ -0,0 +1,915 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/renesas,du.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car Display Unit (DU)
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> +
> +description: |
> + These DT bindings describe the Display Unit embedded in the Renesas R-Car
> + Gen1, R-Car Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs.
> +
> +properties:
> + compatible:
> + enum:
> + - renesas,du-r8a7743 # for RZ/G1M compatible DU
> + - renesas,du-r8a7744 # for RZ/G1N compatible DU
> + - renesas,du-r8a7745 # for RZ/G1E compatible DU
> + - renesas,du-r8a77470 # for RZ/G1C compatible DU
> + - renesas,du-r8a774a1 # for RZ/G2M compatible DU
> + - renesas,du-r8a774b1 # for RZ/G2N compatible DU
> + - renesas,du-r8a774c0 # for RZ/G2E compatible DU
> + - renesas,du-r8a7779 # for R-Car H1 compatible DU
> + - renesas,du-r8a7790 # for R-Car H2 compatible DU
> + - renesas,du-r8a7791 # for R-Car M2-W compatible DU
> + - renesas,du-r8a7792 # for R-Car V2H compatible DU
> + - renesas,du-r8a7793 # for R-Car M2-N compatible DU
> + - renesas,du-r8a7794 # for R-Car E2 compatible DU
> + - renesas,du-r8a7795 # for R-Car H3 compatible DU
> + - renesas,du-r8a7796 # for R-Car M3-W compatible DU
> + - renesas,du-r8a77965 # for R-Car M3-N compatible DU
> + - renesas,du-r8a77970 # for R-Car V3M compatible DU
> + - renesas,du-r8a77980 # for R-Car V3H compatible DU
> + - renesas,du-r8a77990 # for R-Car E3 compatible DU
> + - renesas,du-r8a77995 # for R-Car D3 compatible DU
> +
> + reg:
> + maxItems: 1
> +
> + # See compatible-specific constraints below.
> + clocks: true
> + clock-names: true
> + interrupts: true
> + resets: true
> + reset-names: true
> +
> + ports:
> + type: object
> + description: |
> + The connections to the DU output video ports are modeled using the OF
> + graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> + The number of ports and their assignment are model-dependent. Each port
> + shall have a single endpoint.
> +
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^port@[0-3]$":
> + type: object
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + endpoint:
> + type: object
> +
> + properties:
> + remote-endpoint:
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + required:
> + - remote-endpoint
> +
> + additionalProperties: false
> +
> + additionalProperties: false
You can drop this and assume there's a generic check for this. Though I
guess this does ensure only 'remote-endpoint' is present which a generic
schema couldn't do.
> +
> + required:
> + - port@0
> + - port@1
> +
> + additionalProperties: false
> +
> + renesas,cmms:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> + description:
> + A list of phandles to the CMM instances present in the SoC, one for each
> + available DU channel.
> +
> + renesas,vsps:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> + description:
> + A list of phandle and channel index tuples to the VSPs that handle the
> + memory interfaces for the DU channels. The phandle identifies the VSP
> + instance that serves the DU channel, and the channel index identifies
> + the LIF instance in that VSP.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> + - resets
> + - ports
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,du-r8a7779
> + then:
> + properties:
> + clocks:
> + minItems: 1
> + maxItems: 3
> + items:
> + - description: Functional clock
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 1
> + maxItems: 3
> + items:
> + - const: du.0
> + - enum:
> + - dclkin.0
> + - dclkin.1
Here and elsewhere:
- pattern: "^dclkin\.[01]$"
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: DPAD 1
> + # port@2 is TCON, not supported yet
Does that matter?
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - interrupts
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7743
> + - renesas,du-r8a7744
> + - renesas,du-r8a7791
> + - renesas,du-r8a7793
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: LVDS 0
> + # port@2 is TCON, not supported yet
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7745
> + - renesas,du-r8a7792
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: DPAD 1
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7794
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: DPAD 1
> + # port@2 is TCON, not supported yet
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a77470
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: DPAD 1
> + port@2:
> + description: LVDS 0
> + # port@3 is DVENC, not supported yet
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7790
> + then:
> + properties:
> + clocks:
> + minItems: 3
> + maxItems: 6
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: Functional clock for DU2
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> + - description: DU_DOTCLKIN2 input clock
> +
> + clock-names:
> + minItems: 3
> + maxItems: 6
> + items:
> + - const: du.0
> + - const: du.1
> + - const: du.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> +
> + interrupts:
> + maxItems: 3
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: LVDS 0
> + port@2:
> + description: LVDS 1
> + # port@3 is TCON, not supported yet
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7795
> + then:
> + properties:
> + clocks:
> + minItems: 4
> + maxItems: 8
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: Functional clock for DU2
> + - description: Functional clock for DU4
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> + - description: DU_DOTCLKIN2 input clock
> + - description: DU_DOTCLKIN3 input clock
> +
> + clock-names:
> + minItems: 4
> + maxItems: 8
> + items:
> + - const: du.0
> + - const: du.1
> + - const: du.2
> + - const: du.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - dclkin.3
> +
> + interrupts:
> + maxItems: 4
> +
> + resets:
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: du.0
> + - const: du.2
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: HDMI 0
> + port@2:
> + description: HDMI 1
> + port@3:
> + description: LVDS 0
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> + - port@3
> +
> + renesas,cmms:
> + minItems: 4
> +
> + renesas,vsps:
> + minItems: 4
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a774a1
> + - renesas,du-r8a7796
> + then:
> + properties:
> + clocks:
> + minItems: 3
> + maxItems: 6
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: Functional clock for DU2
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> + - description: DU_DOTCLKIN2 input clock
> +
> + clock-names:
> + minItems: 3
> + maxItems: 6
> + items:
> + - const: du.0
> + - const: du.1
> + - const: du.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> +
> + interrupts:
> + maxItems: 3
> +
> + resets:
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: du.0
> + - const: du.2
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: HDMI 0
> + port@2:
> + description: LVDS 0
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + renesas,cmms:
> + minItems: 3
> +
> + renesas,vsps:
> + minItems: 3
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a774b1
> + - renesas,du-r8a77965
> + then:
> + properties:
> + clocks:
> + minItems: 3
> + maxItems: 6
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: Functional clock for DU3
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> + - description: DU_DOTCLKIN3 input clock
> +
> + clock-names:
> + minItems: 3
> + maxItems: 6
> + items:
> + - const: du.0
> + - const: du.1
> + - const: du.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.3
> +
> + interrupts:
> + maxItems: 3
> +
> + resets:
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: du.0
> + - const: du.3
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: HDMI 0
> + port@2:
> + description: LVDS 0
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + renesas,cmms:
> + minItems: 3
> +
> + renesas,vsps:
> + minItems: 3
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a77970
> + - renesas,du-r8a77980
> + then:
> + properties:
> + clocks:
> + minItems: 1
> + maxItems: 2
> + items:
> + - description: Functional clock for DU0
> + - description: DU_DOTCLKIN0 input clock
> +
> + clock-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + - const: du.0
> + - const: dclkin.0
> +
> + interrupts:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: LVDS 0
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + renesas,vsps:
> + minItems: 1
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a774c0
> + - renesas,du-r8a77990
> + - renesas,du-r8a77995
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: LVDS 0
> + port@2:
> + description: LVDS 1
> + # port@3 is TCON, not supported yet
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + renesas,cmms:
> + minItems: 2
> +
> + renesas,vsps:
> + minItems: 2
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> +additionalProperties: false
> +
> +examples:
> + # R-Car H3 ES2.0 DU
> + - |
> + #include <dt-bindings/clock/renesas-cpg-mssr.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + display@feb00000 {
> + compatible = "renesas,du-r8a7795";
> + reg = <0xfeb00000 0x80000>;
> + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 724>,
> + <&cpg CPG_MOD 723>,
> + <&cpg CPG_MOD 722>,
> + <&cpg CPG_MOD 721>;
> + clock-names = "du.0", "du.1", "du.2", "du.3";
> + resets = <&cpg 724>, <&cpg 722>;
> + reset-names = "du.0", "du.2";
> +
> + renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
> + renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + endpoint {
> + remote-endpoint = <&adv7123_in>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + endpoint {
> + remote-endpoint = <&dw_hdmi0_in>;
> + };
> + };
> + port@2 {
> + reg = <2>;
> + endpoint {
> + remote-endpoint = <&dw_hdmi1_in>;
> + };
> + };
> + port@3 {
> + reg = <3>;
> + endpoint {
> + remote-endpoint = <&lvds0_in>;
> + };
> + };
> + };
> + };
> +
> +...
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* Re: [PATCH v6 15/18] mtd: nand: Introduce the ECC engine abstraction
From: Boris Brezillon @ 2020-05-28 18:52 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Julien Su, Weijie Gao,
Paul Cercueil, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528113113.9166-16-miquel.raynal@bootlin.com>
On Thu, 28 May 2020 13:31:10 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Create a generic ECC engine object.
>
> Later the ecc.c file will receive more generic code coming from
> the raw NAND specific part. This is a base to instantiate ECC engine
> objects.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/mtd/nand/Kconfig | 7 ++
> drivers/mtd/nand/Makefile | 2 +
> drivers/mtd/nand/ecc.c | 138 ++++++++++++++++++++++++++++++++++++++
> include/linux/mtd/nand.h | 67 ++++++++++++++++++
> 4 files changed, 214 insertions(+)
> create mode 100644 drivers/mtd/nand/ecc.c
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index c1a45b071165..a4478ffa279d 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -9,4 +9,11 @@ source "drivers/mtd/nand/onenand/Kconfig"
> source "drivers/mtd/nand/raw/Kconfig"
> source "drivers/mtd/nand/spi/Kconfig"
>
> +menu "ECC engine support"
> +
> +config MTD_NAND_ECC
> + bool
> +
> +endmenu
> +
> endmenu
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 7ecd80c0a66e..981372953b56 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -6,3 +6,5 @@ obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> obj-y += onenand/
> obj-y += raw/
> obj-y += spi/
> +
> +nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
> diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
> new file mode 100644
> index 000000000000..e4f2b6fcbb12
> --- /dev/null
> +++ b/drivers/mtd/nand/ecc.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Generic Error-Correcting Code (ECC) engine
> + *
> + * Copyright (C) 2019 Macronix
> + * Author:
> + * Miquèl RAYNAL <miquel.raynal@bootlin.com>
> + *
> + *
> + * This file describes the abstraction of any NAND ECC engine. It has been
> + * designed to fit most cases, including parallel NANDs and SPI-NANDs.
> + *
> + * There are three main situations where instantiating this ECC engine makes
> + * sense:
> + * - "external": The ECC engine is outside the NAND pipeline, typically this
I'm not sure why you put quotes around those names.
> + * is a software ECC engine. One can also imagine a generic
^ or an hardware
engine that's outside the NAND controller pipeline.
You can the drop the "One can also imagine ..." since it's more than a
theoretical use case, we already have a few engines that fall in this
category.
> + * hardware ECC engine which would be an IP itself. Interacting
> + * with a SPI-NAND device without on-die ECC could be achieved
^can
> + * thanks to the use of such external engine.
But I think I would simply drop this last sentence.
> + * - "pipelined": The ECC engine is inside the NAND pipeline, ie. on the
> + * controller's side. This is the case of most of the raw NAND
> + * controllers. These controllers usually embed an hardware ECC
> + * engine which is managed thanks to the same register set as
> + * the controller's.
Again, I would drop the last sentence here. I think saying the ECC
bytes are generated/data corrected on the fly when a page is
written/read would be more useful.
> + * - "ondie": The ECC engine is inside the NAND pipeline, on the chip's side.
> + * Some NAND chips can correct themselves the data. The on-die
> + * correction can be enabled, disabled and the status of the
> + * correction after a read may be retrieved with a NAND command
> + * (may be vendor specific).
"The on-die correction can be enabled, disabled" -> this is true for
any kind of ECC engine :P.
> + *
> + * Besides the initial setup and final cleanups, the interfaces are rather
> + * simple:
> + * - "prepare": Prepare an I/O request, check the ECC engine is enabled or
^if/whether
> + * disabled as requested before the I/O. In case of software
How about "Enable/disable the ECC engine based on the I/O request type."
> + * correction, this step may involve to derive the ECC bytes and
> + * place them in the OOB area before a write.
This is also true for external hardware ECC engines.
> + * - "finish": Finish an I/O request, check the status of the operation ie.
> + * the data validity in case of a read (report to the upper layer
> + * any bitflip/errors).
It's all about correcting/reporting errors, right. Let's try to put
that into simple words: "Correct the data in case of a read request and
report the number of corrected bits/uncorrectable errors. Most likely
empty for write operations, unless you have hardware specific stuff to
do, like shutting down the engine to save some power"
> + *
> + * Both prepare/finish callbacks are supposed to enclose I/O request and will
"The I/O request should be enclosed in a prepare()/finish() pair of
calls" or "The prepare/finish call should surround the I/O request".
> + * behave differently depending on the desired correction:
^requested I/O type
> + * - "raw": Correction disabled
> + * - "ecc": Correction enabled
> + *
> + * The request direction is impacting the logic as well:
> + * - "read": Load data from the NAND chip
> + * - "write": Store data in the NAND chip
> + *
> + * Mixing all this combinations together gives the following behavior.
Mention that those are just examples, and drivers are free to add
custom steps in their prepare/finish hooks.
> + *
> + * ["external" ECC engine]
> + * - external + prepare + raw + read: do nothing
> + * - external + finish + raw + read: do nothing
> + * - external + prepare + raw + write: do nothing
> + * - external + finish + raw + write: do nothing
> + * - external + prepare + ecc + read: do nothing
> + * - external + finish + ecc + read: calculate expected ECC bytes, extract
> + * ECC bytes from OOB buffer, correct
> + * and report any bitflip/error
> + * - external + prepare + ecc + write: calculate ECC bytes and store them at
> + * the right place in the OOB buffer based
> + * on the OOB layout
> + * - external + finish + ecc + write: do nothing
> + *
> + * ["pipelined" ECC engine]
> + * - pipelined + prepare + raw + read: disable the controller's ECC engine if
> + * activated
> + * - pipelined + finish + raw + read: do nothing
> + * - pipelined + prepare + raw + write: disable the controller's ECC engine if
> + * activated
> + * - pipelined + finish + raw + write: do nothing
> + * - pipelined + prepare + ecc + read: enable the controller's ECC engine if
> + * deactivated
> + * - pipelined + finish + ecc + read: check the status, report any
> + * error/bitflip
> + * - pipelined + prepare + ecc + write: enable the controller's ECC engine if
> + * deactivated
> + * - pipelined + finish + ecc + write: do nothing
> + *
> + * ["ondie" ECC engine]
> + * - ondie + prepare + raw + read: send commands to disable the on-chip ECC
> + * engine if activated
> + * - ondie + finish + raw + read: do nothing
> + * - ondie + prepare + raw + write: send commands to disable the on-chip ECC
> + * engine if activated
> + * - ondie + finish + raw + write: do nothing
> + * - ondie + prepare + ecc + read: send commands to enable the on-chip ECC
> + * engine if deactivated
> + * - ondie + finish + ecc + read: send commands to check the status, report
> + * any error/bitflip
> + * - ondie + prepare + ecc + write: send commands to enable the on-chip ECC
> + * engine if deactivated
> + * - ondie + finish + ecc + write: do nothing
> + */
> +
> +#include <linux/module.h>
> +#include <linux/mtd/nand.h>
> +
Shouldn't we have kernel-docs for those functions?
> +int nand_ecc_init_ctx(struct nand_device *nand)
> +{
> + if (!nand->ecc.engine->ops->init_ctx)
> + return 0;
> +
> + return nand->ecc.engine->ops->init_ctx(nand);
> +}
> +EXPORT_SYMBOL(nand_ecc_init_ctx);
> +
> +void nand_ecc_cleanup_ctx(struct nand_device *nand)
> +{
> + if (nand->ecc.engine->ops->cleanup_ctx)
> + nand->ecc.engine->ops->cleanup_ctx(nand);
> +}
> +EXPORT_SYMBOL(nand_ecc_cleanup_ctx);
> +
> +int nand_ecc_prepare_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req)
> +{
> + if (!nand->ecc.engine->ops->prepare_io_req)
> + return 0;
> +
> + return nand->ecc.engine->ops->prepare_io_req(nand, req);
> +}
> +EXPORT_SYMBOL(nand_ecc_prepare_io_req);
> +
> +int nand_ecc_finish_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req)
> +{
> + if (!nand->ecc.engine->ops->finish_io_req)
> + return 0;
> +
> + return nand->ecc.engine->ops->finish_io_req(nand, req);
> +}
> +EXPORT_SYMBOL(nand_ecc_finish_io_req);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
> +MODULE_DESCRIPTION("Generic ECC engine");
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 2e9af24936cd..0be260fd2f86 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -221,6 +221,73 @@ struct nand_ops {
> bool (*isbad)(struct nand_device *nand, const struct nand_pos *pos);
> };
>
> +/**
> + * struct nand_ecc_context - Context for the ECC engine
> + * @conf: basic ECC engine parameters
> + * @total: Total number of bytes used for storing ECC codes, this is used by
Sometimes you start your description with an uppercase, sometimes not.
> + * generic OOB layouts
> + * @priv: ECC engine driver private data
> + */
> +struct nand_ecc_context {
> + struct nand_ecc_props conf;
> + unsigned int total;
> + void *priv;
> +};
> +
> +/**
> + * struct nand_ecc_engine_ops - Generic ECC engine operations
^s/Generic//
> + * @init_ctx: given a desired user configuration for the pointed NAND device,
> + * requests the ECC engine driver to setup a configuration with
> + * values it supports.
> + * @cleanup_ctx: clean the context initialized by @init_ctx.
> + * @prepare_io_req: is called before reading/writing a page to prepare the I/O
> + * request to be performed with ECC correction.
> + * @finish_io_req: is called after reading/writing a page to terminate the I/O
> + * request and ensure proper ECC correction.
> + */
> +struct nand_ecc_engine_ops {
> + int (*init_ctx)(struct nand_device *nand);
> + void (*cleanup_ctx)(struct nand_device *nand);
> + int (*prepare_io_req)(struct nand_device *nand,
> + struct nand_page_io_req *req);
> + int (*finish_io_req)(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +};
> +
> +/**
> + * struct nand_ecc_engine - Generic ECC engine abstraction for NAND devices
^s/Generic//
> + * @ops: ECC engine operations
> + */
> +struct nand_ecc_engine {
> + struct nand_ecc_engine_ops *ops;
> +};
> +
> +int nand_ecc_init_ctx(struct nand_device *nand);
> +void nand_ecc_cleanup_ctx(struct nand_device *nand);
> +int nand_ecc_prepare_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +int nand_ecc_finish_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +
> +/**
> + * struct nand_ecc - High-level ECC object
I think you can drop the "High-level" and just say "Information
relative to the ECC"
> + * @defaults: Default values, depend on the underlying subsystem
> + * @requirements: ECC requirements from the NAND chip perspective
> + * @user_conf: User desires in terms of ECC parameters
> + * @ctx: ECC context for the ECC engine, derived from the device @requirements
> + * the @user_conf and the @defaults
> + * @ondie_engine: On-die ECC engine reference, if any
> + * @engine: ECC engine actually bound
> + */
> +struct nand_ecc {
> + struct nand_ecc_props defaults;
> + struct nand_ecc_props requirements;
> + struct nand_ecc_props user_conf;
> + struct nand_ecc_context ctx;
> + struct nand_ecc_engine *ondie_engine;
> + struct nand_ecc_engine *engine;
> +};
> +
> /**
> * struct nand_device - NAND device
> * @mtd: MTD instance attached to the NAND device
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Rob Herring @ 2020-05-28 19:20 UTC (permalink / raw)
To: Viresh Kumar
Cc: Jassi Brar, Arnd Bergmann, Frank Rowand, Bjorn Andersson,
Vincent Guittot, linux-arm-kernel, Sudeep Holla, devicetree,
linux-kernel
In-Reply-To: <0a50f0cf5593baeb628dc8606c523665e5e2ae6c.1589519600.git.viresh.kumar@linaro.org>
On Fri, May 15, 2020 at 10:47:38AM +0530, Viresh Kumar wrote:
> From: Sudeep Holla <sudeep.holla@arm.com>
>
> Hi Rob, Arnd and Jassi,
>
> This stuff has been doing rounds on the mailing list since several years
> now with no agreed conclusion by all the parties. And here is another
> attempt to get some feedback from everyone involved to close this once
> and for ever. Your comments will very much be appreciated.
>
> The ARM MHU is defined here in the TRM [1] for your reference, which
> states following:
>
> "The MHU drives the signal using a 32-bit register, with all 32
> bits logically ORed together. The MHU provides a set of
> registers to enable software to set, clear, and check the status
> of each of the bits of this register independently. The use of
> 32 bits for each interrupt line enables software to provide more
> information about the source of the interrupt. For example, each
> bit of the register can be associated with a type of event that
> can contribute to raising the interrupt."
>
> On few other platforms, like qcom, similar doorbell mechanism is present
> with separate interrupt for each of the bits (that's how I understood
> it), while in case of ARM MHU, there is a single interrupt line for all
> the 32 bits. Also in case of ARM MHU, these registers and interrupts
> have 3 copies for different priority levels, i.e. low priority
> non-secure, high priority non-secure and secure channels.
>
> For ARM MHU, both the dt bindings and the Linux driver support 3
> channels for the different priorities right now and support sending a 32
> bit data on every transfer in a locked fashion, i.e. only one transfer
> can be done at once and the other have to wait for it to finish first.
>
> Here are the point of view of the parties involved on this subject:
>
> Jassi's viewpoint:
>
> - Virtualization of channels should be discouraged in software based on
> specific usecases of the application. This may invite other mailbox
> driver authors to ask for doing virtualization in their drivers.
>
> - In mailbox's terminology, every channel is equivalent to a signal,
> since there is only one signal generated here by the MHU, there should
> be only one channel per priority level.
>
> - The clients should send data (of just setting 1 bit or many in the 32
> bit word) using the existing mechanism as the delays due to
> serialization shouldn't be significant anyway.
>
> - The driver supports 90% of the users with the current implementation
> and it shouldn't be extended to support doorbell and implement two
> different modes by changing value of #mbox-cells field in bindings.
>
> Sudeep (ARM) and myself as well to some extent:
>
> - The hardware gives us the capability to write the register in
> parallel, i.e. we can write 0x800 and 0x400 together without any
> software locks, and so these 32 bits should be considered as separate
> channel even if only one interrupt is issued by the hardware finally.
> This shouldn't be called as virtualization of the channels, as the
> hardware supports this (as clearly mentioned in the TRM) and it takes
> care of handling the signal properly.
>
> - With serialization, if we use only one channel as today at every
> priority, if there are 5 requests to send signal to the receiver and
> the dvfs request is the last one in queue (which may be called from
> scheduler's hot path with fast switching), it unnecessarily needs to
> wait for the first four transfers to finish due to the software
> locking imposed by the mailbox framework. This adds additional delay,
> maybe of few ms only, which isn't required by the hardware but just by
> the software and few ms can be important in scheduler's hotpath.
>
> - With the current approach it isn't possible to assign different bits
> (or doorbell numbers) to clients from DT and the only way of doing
> that without adding new bindings is by extending #mbox-cells to accept
> a value of 2 as done in this patch.
>
> Jassi and Sudeep, I hope I was able to represent both the view points
> properly here. Please correct me if I have made a mistake here.
>
> This is it. It would be nice to get the views of everyone now on this
> and how should this be handled.
I am perfectly fine with adding another cell which seems appropriate
here. You can have 5 cells for all I care if that makes sense for
the h/w. That has nothing to do with the Linux design. Whether Linux
requires serializing mailbox accesses is a separate issue. On that side,
it seems silly to not allow driving the h/w in the most efficient way
possible.
Rob
^ permalink raw reply
* [PATCH 3/4] pinctrl: bcm2835: Match BCM7211 compatible string
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-1-f.fainelli@gmail.com>
The BCM7211 SoC uses the same pinconf_ops as the ones defined for the
BCM2711 SoC, match the compatible string and use the correct set of
options.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 06bd2b70af3c..e8ad1824c6b3 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -1137,6 +1137,10 @@ static const struct of_device_id bcm2835_pinctrl_match[] = {
.compatible = "brcm,bcm2711-gpio",
.data = &bcm2711_plat_data,
},
+ {
+ .compatible = "brcm,bcm7211-gpio",
+ .data = &bcm2711_pinconf_ops,
+ },
{}
};
--
2.17.1
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: pinctrl: Document 7211 compatible for brcm,bcm2835-gpio.txt
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-1-f.fainelli@gmail.com>
Document the brcm,bcm7211-gpio compatible string in the
brcm,bcm2835-gpio.txt document.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index 3cab7336a326..dfc67b90591c 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -9,6 +9,7 @@ Required properties:
"brcm,bcm2835-gpio" - BCM2835 compatible pinctrl
"brcm,bcm7211-gpio" - BCM7211 compatible pinctrl
"brcm,bcm2711-gpio" - BCM2711 compatible pinctrl
+ "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl
- reg: Should contain the physical address of the GPIO module's registers.
- gpio-controller: Marks the device node as a GPIO controller.
- #gpio-cells : Should be two. The first cell is the pin number and the
--
2.17.1
^ permalink raw reply related
* [PATCH 4/4] pinctrl: bcm2835: Add support for wake-up interrupts
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-1-f.fainelli@gmail.com>
Leverage the IRQCHIP_MASK_ON_SUSPEND flag in order to avoid having to
specifically treat the GPIO interrupts during suspend and resume, and
simply implement an irq_set_wake() callback that is responsible for
enabling the parent wake-up interrupt as a wake-up interrupt.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 58 ++++++++++++++++++++++++++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index e8ad1824c6b3..367fd8e19f92 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -19,6 +19,7 @@
#include <linux/irq.h>
#include <linux/irqdesc.h>
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of.h>
#include <linux/of_irq.h>
@@ -76,6 +77,7 @@
struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
+ int wake_irq[BCM2835_NUM_IRQS];
/* note: locking assumes each bank will have its own unsigned long */
unsigned long enabled_irq_map[BCM2835_NUM_BANKS];
@@ -435,6 +437,11 @@ static void bcm2835_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(host_chip, desc);
}
+static irqreturn_t bcm2835_gpio_wake_irq_handler(int irq, void *dev_id)
+{
+ return IRQ_HANDLED;
+}
+
static inline void __bcm2835_gpio_irq_config(struct bcm2835_pinctrl *pc,
unsigned reg, unsigned offset, bool enable)
{
@@ -634,6 +641,31 @@ static void bcm2835_gpio_irq_ack(struct irq_data *data)
bcm2835_gpio_set_bit(pc, GPEDS0, gpio);
}
+static int bcm2835_gpio_irq_set_wake(struct irq_data *data, unsigned int on)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct bcm2835_pinctrl *pc = gpiochip_get_data(chip);
+ unsigned gpio = irqd_to_hwirq(data);
+ unsigned int irqgroup;
+ int ret = -EINVAL;
+
+ if (gpio <= 27)
+ irqgroup = 0;
+ else if (gpio >= 28 && gpio <= 45)
+ irqgroup = 1;
+ else if (gpio >= 46 && gpio <= 53)
+ irqgroup = 2;
+ else
+ return ret;
+
+ if (on)
+ ret = enable_irq_wake(pc->wake_irq[irqgroup]);
+ else
+ ret = disable_irq_wake(pc->wake_irq[irqgroup]);
+
+ return ret;
+}
+
static struct irq_chip bcm2835_gpio_irq_chip = {
.name = MODULE_NAME,
.irq_enable = bcm2835_gpio_irq_enable,
@@ -642,6 +674,8 @@ static struct irq_chip bcm2835_gpio_irq_chip = {
.irq_ack = bcm2835_gpio_irq_ack,
.irq_mask = bcm2835_gpio_irq_disable,
.irq_unmask = bcm2835_gpio_irq_enable,
+ .irq_set_wake = bcm2835_gpio_irq_set_wake,
+ .flags = IRQCHIP_MASK_ON_SUSPEND,
};
static int bcm2835_pctl_get_groups_count(struct pinctrl_dev *pctldev)
@@ -1221,8 +1255,30 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
* bank that was firing the IRQ and look up the per-group
* and bank data.
*/
- for (i = 0; i < BCM2835_NUM_IRQS; i++)
+ for (i = 0; i < BCM2835_NUM_IRQS; i++) {
+ int len;
+ char *name;
+
girq->parents[i] = irq_of_parse_and_map(np, i);
+ /* Skip over the all banks interrupts */
+ pc->wake_irq[i] = irq_of_parse_and_map(np, i +
+ BCM2835_NUM_IRQS + 1);
+
+ len = strlen(dev_name(pc->dev)) + 16;
+ name = devm_kzalloc(pc->dev, len, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+
+ snprintf(name, len, "%s:bank%d", dev_name(pc->dev), i);
+
+ /* These are optional interrupts */
+ err = devm_request_irq(dev, pc->wake_irq[i],
+ bcm2835_gpio_wake_irq_handler,
+ IRQF_SHARED, name, pc);
+ if (err)
+ dev_warn(dev, "unable to request wake IRQ %d\n",
+ pc->wake_irq[i]);
+ }
girq->default_type = IRQ_TYPE_NONE;
girq->handler = handle_level_irq;
--
2.17.1
^ permalink raw reply related
* [PATCH 0/4] pinctrl: bcm2835: Support for wake-up interrupts
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
Hi Linus,
This patch series updates the bcm2835 pinctrl driver to support
the BCM7211 SoC which is quite similar to 2711 (Raspberry Pi 4)
except that it also supports wake-up interrupts.
Thanks!
Florian Fainelli (4):
dt-bindings: pinctrl: Document 7211 compatible for
brcm,bcm2835-gpio.txt
dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
pinctrl: bcm2835: Match BCM7211 compatible string
pinctrl: bcm2835: Add support for wake-up interrupts
.../bindings/pinctrl/brcm,bcm2835-gpio.txt | 5 +-
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 62 ++++++++++++++++++-
2 files changed, 65 insertions(+), 2 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-1-f.fainelli@gmail.com>
BCM7211 supports wake-up interrupts in the form of optional interrupt
lines, one per bank, plus the "all banks" interrupt line.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index dfc67b90591c..5682b2010e50 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -16,7 +16,9 @@ Required properties:
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- interrupts : The interrupt outputs from the controller. One interrupt per
- individual bank followed by the "all banks" interrupt.
+ individual bank followed by the "all banks" interrupt. For BCM7211, an
+ additional set of per-bank interrupt line and an "all banks" wake-up
+ interrupt may be specified.
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox