* [PATCH v11 04/12] mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
From: Bibby Hsieh @ 2019-07-29 7:00 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Nicolas Boichat, Philipp Zabel,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Daoyuan Huang,
Sascha Hauer, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Dennis-YC Hsieh, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Houlong Wei, Sascha Hauer, Jiaguang Zhang, Bibby Hsieh,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ginny.chen-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <20190729070106.9332-1-bibby.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
The interrupt mask and thread number has positive correlation,
so we move the CMDQ_IRQ_MASK into cmdq driver data and calculate
it by thread number.
Signed-off-by: Bibby Hsieh <bibby.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Reviewed-by: CK Hu <ck.hu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/mailbox/mtk-cmdq-mailbox.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 00d5219094e5..8fddd26288e8 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -18,7 +18,6 @@
#include <linux/of_device.h>
#define CMDQ_OP_CODE_MASK (0xff << CMDQ_OP_CODE_SHIFT)
-#define CMDQ_IRQ_MASK 0xffff
#define CMDQ_NUM_CMD(t) (t->cmd_buf_size / CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
@@ -72,6 +71,7 @@ struct cmdq {
void __iomem *base;
u32 irq;
u32 thread_nr;
+ u32 irq_mask;
struct cmdq_thread *thread;
struct clk *clock;
bool suspended;
@@ -285,11 +285,11 @@ static irqreturn_t cmdq_irq_handler(int irq, void *dev)
unsigned long irq_status, flags = 0L;
int bit;
- irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & CMDQ_IRQ_MASK;
- if (!(irq_status ^ CMDQ_IRQ_MASK))
+ irq_status = readl(cmdq->base + CMDQ_CURR_IRQ_STATUS) & cmdq->irq_mask;
+ if (!(irq_status ^ cmdq->irq_mask))
return IRQ_NONE;
- for_each_clear_bit(bit, &irq_status, fls(CMDQ_IRQ_MASK)) {
+ for_each_clear_bit(bit, &irq_status, cmdq->thread_nr) {
struct cmdq_thread *thread = &cmdq->thread[bit];
spin_lock_irqsave(&thread->chan->lock, flags);
@@ -473,6 +473,9 @@ static int cmdq_probe(struct platform_device *pdev)
dev_err(dev, "failed to get irq\n");
return -EINVAL;
}
+
+ cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
+ cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler, IRQF_SHARED,
"mtk_cmdq", cmdq);
if (err < 0) {
@@ -489,7 +492,6 @@ static int cmdq_probe(struct platform_device *pdev)
return PTR_ERR(cmdq->clock);
}
- cmdq->thread_nr = (u32)(unsigned long)of_device_get_match_data(dev);
cmdq->mbox.dev = dev;
cmdq->mbox.chans = devm_kcalloc(dev, cmdq->thread_nr,
sizeof(*cmdq->mbox.chans), GFP_KERNEL);
--
2.18.0
^ permalink raw reply related
* [PATCH v11 05/12] mailbox: mediatek: cmdq: support mt8183 gce function
From: Bibby Hsieh @ 2019-07-29 7:00 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, YT Shen, Daoyuan Huang,
Jiaguang Zhang, Dennis-YC Hsieh, Houlong Wei, ginny.chen,
Bibby Hsieh
In-Reply-To: <20190729070106.9332-1-bibby.hsieh@mediatek.com>
add mt8183 compatible name for supporting gce function
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/mailbox/mtk-cmdq-mailbox.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 8fddd26288e8..69daaadc3a5f 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -539,6 +539,7 @@ static const struct dev_pm_ops cmdq_pm_ops = {
static const struct of_device_id cmdq_of_ids[] = {
{.compatible = "mediatek,mt8173-gce", .data = (void *)16},
+ {.compatible = "mediatek,mt8183-gce", .data = (void *)24},
{}
};
--
2.18.0
^ permalink raw reply related
* [PATCH v11 06/12] soc: mediatek: cmdq: clear the event in cmdq initial flow
From: Bibby Hsieh @ 2019-07-29 7:01 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, YT Shen, Daoyuan Huang,
Jiaguang Zhang, Dennis-YC Hsieh, Houlong Wei, ginny.chen,
Bibby Hsieh
In-Reply-To: <20190729070106.9332-1-bibby.hsieh@mediatek.com>
GCE hardware stored event information in own internal sysram,
if the initial value in those sysram is not zero value
it will cause a situation that gce can wait the event immediately
after client ask gce to wait event but not really trigger the
corresponding hardware.
In order to make sure that the wait event function is
exactly correct, we need to clear the sysram value in
cmdq initial flow.
Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/mailbox/mtk-cmdq-mailbox.c | 5 +++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 ++
include/linux/soc/mediatek/mtk-cmdq.h | 3 ---
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 69daaadc3a5f..9a6ce9f5a7db 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -21,6 +21,7 @@
#define CMDQ_NUM_CMD(t) (t->cmd_buf_size / CMDQ_INST_SIZE)
#define CMDQ_CURR_IRQ_STATUS 0x10
+#define CMDQ_SYNC_TOKEN_UPDATE 0x68
#define CMDQ_THR_SLOT_CYCLES 0x30
#define CMDQ_THR_BASE 0x100
#define CMDQ_THR_SIZE 0x80
@@ -104,8 +105,12 @@ static void cmdq_thread_resume(struct cmdq_thread *thread)
static void cmdq_init(struct cmdq *cmdq)
{
+ int i;
+
WARN_ON(clk_enable(cmdq->clock) < 0);
writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
+ for (i = 0; i <= CMDQ_MAX_EVENT; i++)
+ writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
clk_disable(cmdq->clock);
}
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index ccb73422c2fa..911475da7a53 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -19,6 +19,8 @@
#define CMDQ_WFE_UPDATE BIT(31)
#define CMDQ_WFE_WAIT BIT(15)
#define CMDQ_WFE_WAIT_VALUE 0x1
+/** cmdq event maximum */
+#define CMDQ_MAX_EVENT 0x3ff
/*
* CMDQ_CODE_MASK:
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 54ade13a9b15..4e8899972db4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -13,9 +13,6 @@
#define CMDQ_NO_TIMEOUT 0xffffffffu
-/** cmdq event maximum */
-#define CMDQ_MAX_EVENT 0x3ff
-
struct cmdq_pkt;
struct cmdq_client {
--
2.18.0
^ permalink raw reply related
* [PATCH v11 07/12] soc: mediatek: cmdq: reorder the parameter
From: Bibby Hsieh @ 2019-07-29 7:01 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, YT Shen, Daoyuan Huang,
Jiaguang Zhang, Dennis-YC Hsieh, Houlong Wei, ginny.chen,
Bibby Hsieh
In-Reply-To: <20190729070106.9332-1-bibby.hsieh@mediatek.com>
The order of gce instructions is [subsys offset value]
so reorder the parameter of cmdq_pkt_write_mask
and cmdq_pkt_write function.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 6 +++---
include/linux/soc/mediatek/mtk-cmdq.h | 10 +++++-----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ff9fef5a032b..082b8978651e 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
return 0;
}
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
{
u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
(subsys << CMDQ_SUBSYS_SHIFT);
@@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset)
}
EXPORT_SYMBOL(cmdq_pkt_write);
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask)
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask)
{
u32 offset_mask = offset;
int err = 0;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 4e8899972db4..39d813dde4b4 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -60,26 +60,26 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
/**
* cmdq_pkt_write() - append write command to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys: the CMDQ sub system code
* @offset: register offset from CMDQ sub system
+ * @value: the specified target register value
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 value, u32 subsys, u32 offset);
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
/**
* cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
* @pkt: the CMDQ packet
- * @value: the specified target register value
* @subsys: the CMDQ sub system code
* @offset: register offset from CMDQ sub system
+ * @value: the specified target register value
* @mask: the specified target register mask
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 value,
- u32 subsys, u32 offset, u32 mask);
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
+ u32 offset, u32 value, u32 mask);
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
--
2.18.0
^ permalink raw reply related
* [PATCH v11 08/12] soc: mediatek: cmdq: change the type of input parameter
From: Bibby Hsieh @ 2019-07-29 7:01 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, YT Shen, Daoyuan Huang,
Jiaguang Zhang, Dennis-YC Hsieh, Houlong Wei, ginny.chen,
Bibby Hsieh
In-Reply-To: <20190729070106.9332-1-bibby.hsieh@mediatek.com>
According to the cmdq hardware design, the subsys is u8,
the offset is u16 and the event id is u16.
This patch changes the type of subsys, offset and event id
to the correct type.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 10 +++++-----
include/linux/soc/mediatek/mtk-cmdq.h | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 082b8978651e..7aa0517ff2f3 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -136,7 +136,7 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
return 0;
}
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
{
u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
(subsys << CMDQ_SUBSYS_SHIFT);
@@ -145,8 +145,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value)
}
EXPORT_SYMBOL(cmdq_pkt_write);
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
- u32 offset, u32 value, u32 mask)
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask)
{
u32 offset_mask = offset;
int err = 0;
@@ -161,7 +161,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
u32 arg_b;
@@ -181,7 +181,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event)
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
-int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event)
+int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 39d813dde4b4..9618debb9ceb 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -66,7 +66,7 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
+int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value);
/**
* cmdq_pkt_write_mask() - append write command with mask to the CMDQ packet
@@ -78,8 +78,8 @@ int cmdq_pkt_write(struct cmdq_pkt *pkt, u32 subsys, u32 offset, u32 value);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
- u32 offset, u32 value, u32 mask);
+int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask);
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
@@ -88,7 +88,7 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u32 subsys,
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
/**
* cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
@@ -97,7 +97,7 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u32 event);
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u32 event);
+int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
--
2.18.0
^ permalink raw reply related
* [PATCH v11 09/12] soc: mediatek: cmdq: define the instruction struct
From: Bibby Hsieh @ 2019-07-29 7:01 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, YT Shen, Daoyuan Huang,
Jiaguang Zhang, Dennis-YC Hsieh, Houlong Wei, ginny.chen,
Bibby Hsieh
In-Reply-To: <20190729070106.9332-1-bibby.hsieh@mediatek.com>
Define an instruction structure for gce driver to append command.
This structure can make the client's code more readability.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 103 +++++++++++++++--------
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
2 files changed, 72 insertions(+), 33 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 7aa0517ff2f3..0886c4967ca4 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -9,12 +9,24 @@
#include <linux/mailbox_controller.h>
#include <linux/soc/mediatek/mtk-cmdq.h>
-#define CMDQ_ARG_A_WRITE_MASK 0xffff
#define CMDQ_WRITE_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_EN BIT(0)
#define CMDQ_EOC_CMD ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
<< 32 | CMDQ_EOC_IRQ_EN)
+struct cmdq_instruction {
+ union {
+ u32 value;
+ u32 mask;
+ };
+ union {
+ u16 offset;
+ u16 event;
+ };
+ u8 subsys;
+ u8 op;
+};
+
static void cmdq_client_timeout(struct timer_list *t)
{
struct cmdq_client *client = from_timer(client, t, timer);
@@ -110,10 +122,8 @@ void cmdq_pkt_destroy(struct cmdq_pkt *pkt)
}
EXPORT_SYMBOL(cmdq_pkt_destroy);
-static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
- u32 arg_a, u32 arg_b)
+static struct cmdq_instruction *cmdq_pkt_append_command(struct cmdq_pkt *pkt)
{
- u64 *cmd_ptr;
if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
/*
@@ -127,81 +137,108 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
pkt->cmd_buf_size += CMDQ_INST_SIZE;
WARN_ONCE(1, "%s: buffer size %u is too small !\n",
__func__, (u32)pkt->buf_size);
- return -ENOMEM;
+ return NULL;
}
- cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
- (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
+
pkt->cmd_buf_size += CMDQ_INST_SIZE;
- return 0;
+ return pkt->va_base + pkt->cmd_buf_size - CMDQ_INST_SIZE;
}
int cmdq_pkt_write(struct cmdq_pkt *pkt, u8 subsys, u16 offset, u32 value)
{
- u32 arg_a = (offset & CMDQ_ARG_A_WRITE_MASK) |
- (subsys << CMDQ_SUBSYS_SHIFT);
+ struct cmdq_instruction *inst;
+
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WRITE;
+ inst->value = value;
+ inst->offset = offset;
+ inst->subsys = subsys;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WRITE, arg_a, value);
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_write);
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask)
{
+ struct cmdq_instruction *inst;
u32 offset_mask = offset;
- int err = 0;
if (mask != 0xffffffff) {
- err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_MASK;
+ inst->mask = ~mask;
offset_mask |= CMDQ_WRITE_ENABLE_MASK;
}
- err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
- return err;
+ return cmdq_pkt_write(pkt, subsys, offset_mask, value);
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
- u32 arg_b;
+ struct cmdq_instruction *inst;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- /*
- * WFE arg_b
- * bit 0-11: wait value
- * bit 15: 1 - wait, 0 - no wait
- * bit 16-27: update value
- * bit 31: 1 - update, 0 - no update
- */
- arg_b = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WFE;
+ inst->value = CMDQ_WFE_OPTION;
+ inst->event = event;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event, arg_b);
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
+ struct cmdq_instruction *inst;
+
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
- CMDQ_WFE_UPDATE);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_WFE;
+ inst->value = CMDQ_WFE_UPDATE;
+ inst->event = event;
+
+ return 0;
}
EXPORT_SYMBOL(cmdq_pkt_clear_event);
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
- int err;
+ struct cmdq_instruction *inst;
+
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
- /* insert EOC and generate IRQ for each command iteration */
- err = cmdq_pkt_append_command(pkt, CMDQ_CODE_EOC, 0, CMDQ_EOC_IRQ_EN);
+ inst->op = CMDQ_CODE_EOC;
+ inst->value = CMDQ_EOC_IRQ_EN;
- /* JUMP to end */
- err |= cmdq_pkt_append_command(pkt, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_JUMP;
+ inst->value = CMDQ_JUMP_PASS;
- return err;
+ return 0;
}
static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 911475da7a53..c8adedefaf42 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -19,6 +19,8 @@
#define CMDQ_WFE_UPDATE BIT(31)
#define CMDQ_WFE_WAIT BIT(15)
#define CMDQ_WFE_WAIT_VALUE 0x1
+#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | \
+ CMDQ_WFE_WAIT_VALUE)
/** cmdq event maximum */
#define CMDQ_MAX_EVENT 0x3ff
--
2.18.0
^ permalink raw reply related
* [PATCH v11 10/12] soc: mediatek: cmdq: add polling function
From: Bibby Hsieh @ 2019-07-29 7:01 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Nicolas Boichat, Philipp Zabel,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Daoyuan Huang,
Sascha Hauer, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Dennis-YC Hsieh, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Houlong Wei, Sascha Hauer, Jiaguang Zhang, Bibby Hsieh,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
ginny.chen-NuS5LvNUpcJWk0Htik3J/w
In-Reply-To: <20190729070106.9332-1-bibby.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
add polling function in cmdq helper functions
Signed-off-by: Bibby Hsieh <bibby.hsieh-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Reviewed-by: CK Hu <ck.hu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 28 ++++++++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h | 15 +++++++++++++
3 files changed, 44 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 0886c4967ca4..70ad4d806fac 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -220,6 +220,34 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
}
EXPORT_SYMBOL(cmdq_pkt_clear_event);
+int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask)
+{
+ struct cmdq_instruction *inst;
+
+ if (mask != 0xffffffff) {
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_MASK;
+ inst->value = ~mask;
+ offset = offset | 0x1;
+ }
+
+ inst = cmdq_pkt_append_command(pkt);
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_POLL;
+ inst->value = value;
+ inst->offset = offset;
+ inst->subsys = subsys;
+
+ return 0;
+}
+EXPORT_SYMBOL(cmdq_pkt_poll);
+
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction *inst;
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index c8adedefaf42..9e3502945bc1 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -46,6 +46,7 @@
enum cmdq_code {
CMDQ_CODE_MASK = 0x02,
CMDQ_CODE_WRITE = 0x04,
+ CMDQ_CODE_POLL = 0x08,
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index 9618debb9ceb..a345870a6d10 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -99,6 +99,21 @@ int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
*/
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
+/**
+ * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
+ * execute an instruction that wait for a specified hardware
+ * register to check for the value. All GCE hardware
+ * threads will be blocked by this instruction.
+ * @pkt: the CMDQ packet
+ * @subsys: the CMDQ sub system code
+ * @offset: register offset from CMDQ sub system
+ * @value: the specified target register value
+ * @mask: the specified target register mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask);
/**
* 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 v11 11/12] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Bibby Hsieh @ 2019-07-29 7:01 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, YT Shen, Daoyuan Huang,
Jiaguang Zhang, Dennis-YC Hsieh, Houlong Wei, ginny.chen,
Bibby Hsieh
In-Reply-To: <20190729070106.9332-1-bibby.hsieh@mediatek.com>
GCE cannot know the register base address, this function
can help cmdq client to get the cmdq_client_reg structure.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 29 ++++++++++++++++++++++++++
include/linux/soc/mediatek/mtk-cmdq.h | 21 +++++++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 70ad4d806fac..9695b75cfc89 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -27,6 +27,35 @@ struct cmdq_instruction {
u8 op;
};
+int cmdq_dev_get_client_reg(struct device *dev,
+ struct cmdq_client_reg *client_reg, int idx)
+{
+ struct of_phandle_args spec;
+ int err;
+
+ if (!client_reg)
+ return -ENOENT;
+
+ err = of_parse_phandle_with_fixed_args(dev->of_node,
+ "mediatek,gce-client-reg",
+ 3, idx, &spec);
+ if (err < 0) {
+ dev_err(dev,
+ "error %d can't parse gce-client-reg property (%d)",
+ err, idx);
+
+ return err;
+ }
+
+ client_reg->subsys = spec.args[0];
+ client_reg->offset = spec.args[1];
+ client_reg->size = spec.args[2];
+ of_node_put(spec.np);
+
+ return 0;
+}
+EXPORT_SYMBOL(cmdq_dev_get_client_reg);
+
static void cmdq_client_timeout(struct timer_list *t)
{
struct cmdq_client *client = from_timer(client, t, timer);
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index a345870a6d10..be402c4c740e 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -15,6 +15,12 @@
struct cmdq_pkt;
+struct cmdq_client_reg {
+ u8 subsys;
+ u16 offset;
+ u16 size;
+};
+
struct cmdq_client {
spinlock_t lock;
u32 pkt_cnt;
@@ -142,4 +148,19 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
*/
int cmdq_pkt_flush(struct cmdq_pkt *pkt);
+/**
+ * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
+ * node of CMDQ client
+ * @dev: device of CMDQ mailbox clienti
+ * @client_reg: CMDQ client reg pointer
+ * @idx: the index of desired reg
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Help CMDQ client pasing the cmdq client reg
+ * from the device node of CMDQ client.
+ */
+int cmdq_dev_get_client_reg(struct device *dev,
+ struct cmdq_client_reg *client_reg, int idx);
+
#endif /* __MTK_CMDQ_H__ */
--
2.18.0
^ permalink raw reply related
* [PATCH v11 12/12] arm64: dts: add gce node for mt8183
From: Bibby Hsieh @ 2019-07-29 7:01 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, YT Shen, Daoyuan Huang,
Jiaguang Zhang, Dennis-YC Hsieh, Houlong Wei, ginny.chen,
Bibby Hsieh
In-Reply-To: <20190729070106.9332-1-bibby.hsieh@mediatek.com>
add gce device node for mt8183
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 08274bfcebd8..98d17d0bdebf 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/mt8183-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gce/mt8183-gce.h>
/ {
compatible = "mediatek,mt8183";
@@ -212,6 +213,15 @@
clock-names = "spi", "wrap";
};
+ gce: gce@10238000 {
+ compatible = "mediatek,mt8183-gce";
+ reg = <0 0x10238000 0 0x4000>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
+ #mbox-cells = <3>;
+ clocks = <&infracfg CLK_INFRA_GCE>;
+ clock-names = "gce";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt8183-uart",
"mediatek,mt6577-uart";
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 5/6] pwm: sun4i: Add support to output source clock directly
From: Uwe Kleine-König @ 2019-07-29 7:06 UTC (permalink / raw)
To: Jernej Skrabec
Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
mripard-DgEjT+Ai2ygdnm+yROfE0A, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20190726184045.14669-6-jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
On Fri, Jul 26, 2019 at 08:40:44PM +0200, Jernej Skrabec wrote:
> PWM core has an option to bypass whole logic and output unchanged source
> clock as PWM output. This is achieved by enabling bypass bit.
>
> Note that when bypass is enabled, no other setting has any meaning, not
> even enable bit.
>
> This mode of operation is needed to achieve high enough frequency to
> serve as clock source for AC200 chip, which is integrated into same
> package as H6 SoC.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> ---
> drivers/pwm/pwm-sun4i.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 9e0eca79ff88..848cff26f385 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -120,6 +120,19 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
>
> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>
> + /*
> + * PWM chapter in H6 manual has a diagram which explains that if bypass
> + * bit is set, no other setting has any meaning. Even more, experiment
> + * proved that also enable bit is ignored in this case.
> + */
> + if (val & BIT_CH(PWM_BYPASS, pwm->hwpwm)) {
> + state->period = DIV_ROUND_CLOSEST_ULL(NSEC_PER_SEC, clk_rate);
> + state->duty_cycle = state->period / 2;
> + state->polarity = PWM_POLARITY_NORMAL;
> + state->enabled = true;
> + return;
> + }
> +
> if ((PWM_REG_PRESCAL(val, pwm->hwpwm) == PWM_PRESCAL_MASK) &&
> sun4i_pwm->data->has_prescaler_bypass)
> prescaler = 1;
> @@ -211,7 +224,8 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> {
> struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
> struct pwm_state cstate;
> - u32 ctrl;
> + u32 ctrl, clk_rate;
> + bool bypass;
> int ret;
> unsigned int delay_us;
> unsigned long now;
> @@ -226,6 +240,16 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> }
> }
>
> + /*
> + * Although it would make much more sense to check for bypass in
> + * sun4i_pwm_calculate(), value of bypass bit also depends on "enabled".
> + * Period is allowed to be rounded up or down.
> + */
Every driver seems to implement rounding the way its driver considers it
sensible. @Thierry: This is another patch where it would be good to have
a global directive about how rounding is supposed to work to provide the
users an reliable and uniform way to work with PWMs.
> + clk_rate = clk_get_rate(sun4i_pwm->clk);
> + bypass = (state->period == NSEC_PER_SEC / clk_rate ||
> + state->period == DIV_ROUND_UP(NSEC_PER_SEC, clk_rate)) &&
> + state->enabled;
Not sure if the compiler is clever enough to notice the obvious
optimisation with this code construct, but you can write this test in a
more clever way which has zero instead of up to two divisions. Something
like:
bypass = ((state->period * clk_rate >= NSEC_PER_SEC &&
state->period * clk_rate < NSEC_PER_SEC + clk_rate) &&
state->enabled);
In the commit log you write the motivation for using bypass is that it
allows to implement higher frequency then with the "normal" operation.
As you don't skip calculating the normal parameters requesting such a
high-frequency setting either errors out or doesn't catch the impossible
request. In both cases there is something to fix.
> +
> spin_lock(&sun4i_pwm->ctrl_lock);
> ctrl = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>
> @@ -273,6 +297,11 @@ static int sun4i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> ctrl &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> }
>
> + if (bypass)
> + ctrl |= BIT_CH(PWM_BYPASS, pwm->hwpwm);
> + else
> + ctrl &= ~BIT_CH(PWM_BYPASS, pwm->hwpwm);
> +
Does switching on (or off) the bypass bit complete the currently running
period?
> sun4i_pwm_writel(sun4i_pwm, ctrl, PWM_CTRL_REG);
>
> spin_unlock(&sun4i_pwm->ctrl_lock);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190729070605.vlu7kgzn362ph2q3%40pengutronix.de.
^ permalink raw reply
* Re: [PATCH 2/6] pwm: sun4i: Add a quirk for reset line
From: Uwe Kleine-König @ 2019-07-29 7:12 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Jernej Skrabec, Thierry Reding, Maxime Ripard, Rob Herring,
Mark Rutland, linux-pwm-u79uwXL29TY76Z2rM5mHXA, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi, Philipp Zabel
In-Reply-To: <CAGb2v65KOpivHQNkg+R2=D=ejCJYnPdVcyHJZW-GJCR8j0Yk0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello,
On Mon, Jul 29, 2019 at 02:43:23PM +0800, Chen-Yu Tsai wrote:
> On Mon, Jul 29, 2019 at 2:36 PM Uwe Kleine-König
> <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > On Fri, Jul 26, 2019 at 08:40:41PM +0200, Jernej Skrabec wrote:
> > > @@ -371,6 +374,14 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
> > > if (IS_ERR(pwm->clk))
> > > return PTR_ERR(pwm->clk);
> > >
> > > + if (pwm->data->has_reset) {
> > > + pwm->rst = devm_reset_control_get(&pdev->dev, NULL);
> > > + if (IS_ERR(pwm->rst))
> > > + return PTR_ERR(pwm->rst);
> > > +
> > > + reset_control_deassert(pwm->rst);
> > > + }
> > > +
> >
> > I wonder why there is a need to track if a given chip needs a reset
> > line. I'd just use devm_reset_control_get_optional() and drop the
> > .has_reset member in struct sun4i_pwm_data.
>
> Because it's not optional for this platform, i.e. it won't work if
> the reset control (or clk, in the next patch) is somehow missing from
> the device tree.
If the device tree is wrong it is considered ok that the driver doesn't
behave correctly. So this is not a problem you need (or should) care
about.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190729071218.bukw7vxilqy523k3%40pengutronix.de.
^ permalink raw reply
* RE: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT
From: Anson Huang @ 2019-07-29 7:14 UTC (permalink / raw)
To: Daniel Baluta
Cc: Abel Vesa, rui.zhang@intel.com, edubezval@gmail.com,
daniel.lezcano@linaro.org, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Lucas Stach, Andrey Smirnov,
Angus Ainslie (Purism), Carlo Caione, Guido Günther,
Leonard Crestez, linux-pm
In-Reply-To: <CAEnQRZB6tmYFA8wwh0Fm49LTTDuCLq-SWVfrcUkRWWBo=0U13w@mail.gmail.com>
Hi, Daniel
> On Mon, Jul 29, 2019 at 4:29 AM Anson Huang <anson.huang@nxp.com>
> wrote:
> >
> > Hi, Abel/Daniel
> >
> > > On 19-07-27 09:33:10, Daniel Baluta wrote:
> > > > On Sat, Jul 27, 2019 at 9:19 AM Anson Huang <anson.huang@nxp.com>
> > > wrote:
> > > > >
> > > > > Hi, Daniel
> > > > >
> > > > > > Subject: Re: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL
> > > > > > flag for IMX8MQ_CLK_TMU_ROOT
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > latest linux-next hangs at boot.
> > > > > >
> > > > > > commit fde50b96be821ac9673a7e00847cc4605bd88f34 (HEAD ->
> > > master, tag:
> > > > > > next-20190726, origin/master, origin/HEAD)
> > > > > > Author: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > Date: Fri Jul 26 15:18:02 2019 +1000
> > > > > >
> > > > > > Add linux-next specific files for 20190726
> > > > > >
> > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > >
> > > > > >
> > > > > > I know this is crazy but reverting commit:
> > > > > >
> > > > > > commit 431bdd1df48ee2896ea9980d9153e3aeaf0c81ef
> > > (refs/bisect/bad)
> > > > > > Author: Anson Huang <Anson.Huang@nxp.com>
> > > > > > Date: Fri Jul 5 12:56:11 2019 +0800
> > > > > >
> > > > > > clk: imx8mq: Remove CLK_IS_CRITICAL flag for
> > > > > > IMX8MQ_CLK_TMU_ROOT
> > > > > >
> > > > > > IMX8MQ_CLK_TMU_ROOT is ONLY used for thermal module, the
> > > driver
> > > > > > should manage this clock, so no need to have CLK_IS_CRITICAL
> flag
> > > > > > set.
> > > > > >
> > > > > >
> > > > > >
> > > > > > makes the boot work again.
> > > > > >
> > > > > > Any idea?
> > > > >
> > > > > I just found if disabling SDMA1, then kernel can boot up, it
> > > > > does NOT make sense TMU clock is related to SDMA1, I will check
> > > > > with design
> > > and get back to you soon.
> > > > >
> > > >
> > > > Hi Anson,
> > > >
> > > > Applying Abel's patch:
> > > >
> > > > commit 8816c47db6a82f55bb4d64f62fd9dd3af680f0e4 (HEAD -> master)
> > > > Author: Abel Vesa <abel.vesa@nxp.com>
> > > > Date: Tue Jun 25 12:01:56 2019 +0300
> > > >
> > > > clk: imx8mq: Mark AHB clock as critical
> > > >
> > > > Keep the AHB clock always on since there is no driver to control it and
> > > > all the other clocks that use it as parent rely on it being always
> enabled.
> > > >
> > > >
> > > >
> > > > The kernel boots up again.
> > > >
> > > > It make some sense. I don't understand though why having
> > > > IMX8MQ_CLK_TMU_ROOT as critical also "unhangs" the kernel.
> > > >
> > >
> > > OK, so this is how it works.
> > >
> > > By removing the critical flag from TMU, the AHB doesn't stay always on.
> > > With my patch the AHB is marked as critical and therefore stays on.
> > >
> > > The sdma1_clk has as parent the ipg_root which in turn has as parent
> > > the ahb clock. And I think what happens is some read from the sdma
> > > registers hangs because, for whatever reason, enabling the sdma1_clk
> > > doesn't propagate to enable the ahb clock. I might be wrong though.
> > >
> >
> > I can explain why Abel's patch can fix this issue, the AHB clock is a
> > MUST always ON for system bus, while it does NOT have CLK_IS_CRITICAL
> > flag set for now, when SDMA1 is probed, it will enable its clock, and
> > the clk path is sdma1_clk->ipg_root->ahb, after SDMA1 probed done, it
> > will disable its clock since no one use it, and it will trigger the
> > ahb clock to be OFF, as its usecount is added by 1 when probe and
> > decreased by 1 after
> > SDMA1 probe done, so usecount=0 will trigger AHB clock to be OFF.
> >
> > So I think the best solution should be applying Abel's patch as you
> > mentioned upper, the TMU clock patch is NOT the root cause, it just
> > triggers this issue accidently☹
> >
> > But I saw Abel's AHB patch is still under discussion, so I think we
> > need to speed it up and make kernel boot up work for development.
> AHB/IPG are always critical for i.MX SoCs.
>
> Thanks Anson,
>
> Your explanation makes a lot of sense. We will take care today of Abel's
> patch.
> What do you think about Fabio's patch? I also think this is a valid patch:
>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.b
> ulix.org%2Fpd88jp-
> 812381&data=02%7C01%7Canson.huang%40nxp.com%7C23b4c21e3cbc
> 4fcf2a3c08d713f131a8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> 7C636999798949622961&sdata=Jx9B40rJKpQvakOCfx%2B3v80NTxPqUw
> D4pdGojQxVIoY%3D&reserved=0
Hmm, when did Fabio sent out this patch? I can NOT find it...
I also have a patch in this series (#4/6) doing same thing on July 5th...
https://patchwork.kernel.org/patch/11032783/
Thanks.
Anson
^ permalink raw reply
* Re: Controllers with several interface options - one or more drivers?
From: Josef Luštický @ 2019-07-29 7:19 UTC (permalink / raw)
To: Sam Ravnborg
Cc: devicetree, Dave Airlie, dri-devel, Thierry Reding,
Laurent Pinchart
In-Reply-To: <20190726161403.GA25593@ravnborg.org>
Hello,
I am happy to see this discussion.
I like Noralf's late work to move mipi_dbi to drm/ and remove tinydrm.
This helps to simplify implementation and maintenance of drivers for
displays that conform to MIPI_DBI set of commands,
no matter if they use MIPI_DBI to transfer the image data or not.
There are already MIPI_DBI compliant panels in drm/panel, but until
Noralf's refactor they needed to implement custom
functions (on top SPI) to initialize the display. See the following
drivers as examples:
- drm/panel/panel-sitronix-st7789v.c
- drivers/gpu/drm/panel/panel-tpo-tpg110.c
- drivers/gpu/drm/panel/panel-lg-lg4573.c
- drivers/gpu/drm/panel/panel-samsung-ld9040.c
- drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
there may be more...
There are also at least two drivers for the same chip ili9341. See:
- drm/tinydrm/mi0283qt.c
- drm/tinydrm/ili9341.c
+ another driver for the same chip, but with parallel RGB initial
configuration, was submitted
I think there should be a single driver supporting all of the chip's
capabilities / configurations
to avoid maintenance burden and user confusion:
As a user, I can see the following use cases if a display conforms to MIPI_DBI.
a) it has its internal GRAM and MIPI_DBI can be used to transfer image data
b) internal GRAM is not present, parallel RGB must be used to transfer
image data
c) the display supports both - ili9341 case (but also others available)
As a user I want to specify displays that are going to use option a)
and/or b) - i.e.
I can have multiple ili9341 displays connected to the same parallel
RGB MCU interface,
but on a different SPI bus (or just different chip_select).
The same image data can be transferred to the displays over the parallel RGB
or I can switch some of the displays to use the MIPI_DBI (SPI) for
different image data transfer.
Kind regards
Josef Lusticky
pá 26. 7. 2019 v 18:14 odesílatel Sam Ravnborg <sam@ravnborg.org> napsal:
>
> Hi Daniel.
>
> Added Noralf - somehow I missed him on the original mail.
>
> On Fri, Jul 26, 2019 at 05:06:03PM +0200, Daniel Vetter wrote:
> > Also probably should add a few more (drm_bridge) people, I think
> > that's also somewhat relevant here.
> > -Daniel
> >
> > On Fri, Jul 26, 2019 at 4:55 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Fri, Jul 26, 2019 at 02:25:10PM +0200, Sam Ravnborg wrote:
> > > > Hi Josef, Daniel et al.
> > > >
> > > > The driver that triggered this reply is a driver that adds parallel
> > > > support to ili9341 in a dedicated panel driver.
> > > > The issue here is that we already have a tiny driver that supports the
> > > > ili9341 controller - but with a slightly different configuration.
> > > >
> > > > The ili9341 supports several interfaces - from the datasheet:
> > > > "ILI9341 supports parallel 8-/9-/16-/18-bit data bus
> > > > MCU interface, 6-/16-/18-bit data bus RGB interface and
> > > > 3-/4-line serial peripheral interface (SPI)"
> > > >
> > > > Noralf - in another mail explained:
> > > > "
> > > > The MIPI Alliance has lots of standards some wrt. display controller
> > > > interfaces:
> > > > - MIPI DBI - Display Bus Interface (used for commands and optionally pixels)
> > > > - MIPI DPI - Display Pixel Interface (also called RGB interface or
> > > > DOTCLK interface)
> > > > - MIPI DSI - Display Serial Interface (commands and pixels)
> > > >
> > > > The ili9341 supports both MIPI DBI and DPI.
> > > > "
> > > >
> > > > MIPI DPI - is a good fit for a drm_panel driver.
> > > > MIPI DBI - requires a full display controller driver.
> > > >
> > > > There are many other examples of driver SoC that in the same way
> > > > can be seen only as a panel or as a full display controller driver.
> > > >
> > > > The open question here is if we should try to support both cases in the
> > > > same driver / file. Or shall we implment two different drivers.
> > > > One for the panel use-case. And one for the display controller usecase?
> > > >
> > > > Not sure - so asking for feedback.
> > >
> > > I'm not sure. Currently we do have DSI and dumb RGB panels all in
> > > drm/panel. I don't think we have DBI panels in there yet, but then
> > > drm/tiny is the only one supporting these.
> > >
> > > I guess we could look into move some of the DBI panel drivers into panel
> > > drivers, but that needs a bit more glue all around. I'm honestly not sure
> > > how the current DSI drivers in drm_panel work exactly, especially for
> > > command mode.
> > >
> > > Or maybe we need a new interface for command mode.
> If I get around to do a driver for the ssd1306 then I will try to sewhat
> makes sense then. For now we shall not stall the ili9341 driver.
> > >
> > > Wrt sharing code between drivers for the same chip, but different
> > > interfaces: I wouldn't worry too much about that. Maybe try to have a
> > > shared header file at least for registers.
> This part should be the minimum. Somthing like include/drm/mipi/?
>
> Sam
>
> > > Long term we could end up with
> > > one driver module which exposes different flavours of the same chip, so
> > > multiple drm_panel drivers, or maybe we'll get something more specific for
> > > dsi/dbi.
> > > -Daniel
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT
From: Daniel Baluta @ 2019-07-29 7:20 UTC (permalink / raw)
To: Anson Huang
Cc: Abel Vesa, rui.zhang@intel.com, edubezval@gmail.com,
daniel.lezcano@linaro.org, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Lucas Stach, Andrey Smirnov,
Angus Ainslie (Purism), Carlo Caione, Guido Günther,
Leonard Crestez, linux-pm
In-Reply-To: <DB3PR0402MB391627F725AA7237BCACBE87F5DD0@DB3PR0402MB3916.eurprd04.prod.outlook.com>
<snip>
> > Your explanation makes a lot of sense. We will take care today of Abel's
> > patch.
> > What do you think about Fabio's patch? I also think this is a valid patch:
> >
<snip>
>
> Hmm, when did Fabio sent out this patch? I can NOT find it...
> I also have a patch in this series (#4/6) doing same thing on July 5th...
>
> https://patchwork.kernel.org/patch/11032783/
He didn't send the patch yet. It was just a request for test here:
http://code.bulix.org/pd88jp-812381
But, now I see is exactly like your patch here:
^ permalink raw reply
* Re: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT
From: Daniel Baluta @ 2019-07-29 7:21 UTC (permalink / raw)
To: Anson Huang
Cc: Abel Vesa, rui.zhang@intel.com, edubezval@gmail.com,
daniel.lezcano@linaro.org, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Lucas Stach, Andrey Smirnov,
Angus Ainslie (Purism), Carlo Caione, Guido Günther,
Leonard Crestez, linux-pm
In-Reply-To: <CAEnQRZBrmikenTvnh7syhy=PDPcTL3fn2TJ+ya=ToZ+SFmH5tw@mail.gmail.com>
On Mon, Jul 29, 2019 at 10:20 AM Daniel Baluta <daniel.baluta@gmail.com> wrote:
>
> <snip>
> > > Your explanation makes a lot of sense. We will take care today of Abel's
> > > patch.
> > > What do you think about Fabio's patch? I also think this is a valid patch:
> > >
> <snip>
>
> >
> > Hmm, when did Fabio sent out this patch? I can NOT find it...
> > I also have a patch in this series (#4/6) doing same thing on July 5th...
> >
> > https://patchwork.kernel.org/patch/11032783/
>
> He didn't send the patch yet. It was just a request for test here:
>
> http://code.bulix.org/pd88jp-812381
>
> But, now I see is exactly like your patch here:
... pressed send to early.
https://lkml.org/lkml/2019/7/5/19
We are all set then. Thanks Anson for clarifications!
^ permalink raw reply
* Re: [PATCH 0/5] Add missing pwm-cells to STM32 timers PWM
From: Alexandre Torgue @ 2019-07-29 7:22 UTC (permalink / raw)
To: Fabrice Gasnier, thierry.reding, robh+dt
Cc: mark.rutland, linux, mcoquelin.stm32, devicetree,
linux-arm-kernel, linux-kernel, linux-pwm, benjamin.gaignard,
linux-stm32
In-Reply-To: <1560937925-8990-1-git-send-email-fabrice.gasnier@st.com>
Hi Fabrice
On 6/19/19 11:52 AM, Fabrice Gasnier wrote:
> This series adds missing generic 3-cells PWM to STM32 timers dt-bindings,
> PWM driver, and the relevant dtsi files for STM32F4, STM32F7 and STM32MP1.
>
> Fabrice Gasnier (5):
> dt-bindings: pwm-stm32: add #pwm-cells
> pwm: stm32: use 3 cells ->of_xlate()
> ARM: dts: stm32: add pwm cells to stm32mp157c
> ARM: dts: stm32: add pwm cells to stm32f429
> ARM: dts: stm32: add pwm cells to stm32f746
>
> Documentation/devicetree/bindings/pwm/pwm-stm32.txt | 3 +++
> arch/arm/boot/dts/stm32f429.dtsi | 12 ++++++++++++
> arch/arm/boot/dts/stm32f746.dtsi | 12 ++++++++++++
> arch/arm/boot/dts/stm32mp157c.dtsi | 12 ++++++++++++
> drivers/pwm/pwm-stm32.c | 2 ++
> 5 files changed, 41 insertions(+)
>
DT patches applied on stm32-next.
regards
Alex
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: dts: stm32: add syscfg to ADC on stm32mp157c
From: Alexandre Torgue @ 2019-07-29 7:23 UTC (permalink / raw)
To: Fabrice Gasnier, jic23, robh+dt
Cc: mark.rutland, devicetree, lars, mcoquelin.stm32, linux-iio,
linux-kernel, pmeerw, knaack.h, linux-stm32, linux-arm-kernel
In-Reply-To: <1562148496-26789-4-git-send-email-fabrice.gasnier@st.com>
Hi fabrice
On 7/3/19 12:08 PM, Fabrice Gasnier wrote:
> On stm32mp157c, the ADC inputs are multiplexed with analog switches which
> have reduced performances when their supply is below 2.7V (vdda by
> default).
> Add syscfg registers that can be used on stm32mp157c, to get full ADC
> analog performances.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
> index 2dd5162..b9a5b58 100644
> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
> @@ -862,6 +862,7 @@
> clocks = <&rcc ADC12>, <&rcc ADC12_K>;
> clock-names = "bus", "adc";
> interrupt-controller;
> + st,syscfg = <&syscfg>;
> #interrupt-cells = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
Applied on stm32-next.
Thanks.
Alex
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add audio codec support on stm32mp157a-dk1 board
From: Alexandre Torgue @ 2019-07-29 7:23 UTC (permalink / raw)
To: Olivier MOYSAN, linux-stm32@st-md-mailman.stormreply.com,
robh@kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <f43b8af7-e2c0-6193-d666-9fa60050e07d@st.com>
On 7/25/19 11:41 AM, Olivier MOYSAN wrote:
>
>
> On 7/24/19 6:40 PM, Alexandre Torgue wrote:
>> Hi Olivier
>>
>> On 7/5/19 1:53 PM, Olivier Moysan wrote:
>>> Add support of Cirrus cs42l51 audio codec on stm32mp157a-dk1 board.
>>> Configuration overview:
>>> - SAI2A is the CPU interface used for the codec audio playback
>>> - SAI2B is the CPU interface used for the codec audio record
>>> - SAI2A is configured as a clock provider for the audio codec
>>> - SAI2A&B are configured as slave of the audio codec
>>> - SAI2A&B share the same interface of the audio codec
>>>
>>> Note:
>>> In master mode, cs42l51 audio codec provides a bitclock
>>> at 64 x FS, regardless of data width. This means that
>>> slot width is always 32 bits.
>>> Set slot width to 32 bits and slot number to 2
>>> in SAI2A&B endpoint nodes, to match this constraint.
>>> dai-tdm-slot-num and dai-tdm-slot-width properties are used here,
>>> assuming that i2s is a special case of tdm, where slot number is 2.
>>>
>>> Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
>>> ---
>>> arch/arm/boot/dts/stm32mp157a-dk1.dts | 89 +++++++++++++++++++++++++++++++++++
>>> 1 file changed, 89 insertions(+)
>>>
>>
>> ...
>>
>>>
>>> +&sai2 {
>>> + clocks = <&rcc SAI2>, <&rcc PLL3_Q>, <&rcc PLL3_R>;
>>> + clock-names = "pclk", "x8k", "x11k";
>>> + pinctrl-names = "default", "sleep";
>>> + pinctrl-0 = <&sai2a_pins_a>, <&sai2b_pins_b>;
>>> + pinctrl-1 = <&sai2a_sleep_pins_a>, <&sai2b_sleep_pins_b>;
>>> + status = "okay";
>>> +
>>> + sai2a: audio-controller@4400b004 {
>>> + #clock-cells = <0>;
>>> + dma-names = "tx";
>>> + clocks = <&rcc SAI2_K>;
>>> + clock-names = "sai_ck";
>>> + status = "okay";
>>> +
>>> + sai2a_port: port {
>>> + sai2a_endpoint: endpoint {
>>> + remote-endpoint = <&cs42l51_tx_endpoint>;
>>> + format = "i2s";
>>> + mclk-fs = <256>;
>>> + dai-tdm-slot-num = <2>;
>>> + dai-tdm-slot-width = <32>;
>>> + };
>>> + };
>>> + };
>>> +
>> You could use label to overload sai2a and sai2b. no ?
> I propose to keep it unchanged for better readability
>>
Ok. Applied on stm32-next.
Regards
Alex
^ permalink raw reply
* Re: [v2,2/2] PCI: mediatek: Add controller support for MT7629
From: Jianjun Wang @ 2019-07-29 7:38 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Ryder Lee
Cc: Mark Rutland, devicetree, linux-pci, youlin.pei, linux-kernel,
jianjun.wang, Rob Herring, linux-mediatek, Matthias Brugger,
linux-arm-kernel
In-Reply-To: <20190628073425.25165-3-jianjun.wang@mediatek.com>
On Fri, 2019-06-28 at 15:34 +0800, Jianjun Wang wrote:
> MT7629 is an ARM platform SoC which has the same PCIe IP with MT7622.
>
> The HW default value of its Device ID is invalid, fix its Device ID to
> match the hardware implementation.
>
> Acked-by: Ryder Lee <ryder.lee@mediatek.com>
> Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
> ---
> drivers/pci/controller/pcie-mediatek.c | 18 ++++++++++++++++++
> include/linux/pci_ids.h | 1 +
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> index 80601e1b939e..e5e6740b635d 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -73,6 +73,7 @@
> #define PCIE_MSI_VECTOR 0x0c0
>
> #define PCIE_CONF_VEND_ID 0x100
> +#define PCIE_CONF_DEVICE_ID 0x102
> #define PCIE_CONF_CLASS_ID 0x106
>
> #define PCIE_INT_MASK 0x420
> @@ -141,12 +142,16 @@ struct mtk_pcie_port;
> /**
> * struct mtk_pcie_soc - differentiate between host generations
> * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> + * @need_fix_device_id: whether this host's Device ID needed to be fixed or not
> + * @device_id: Device ID which this host need to be fixed
> * @ops: pointer to configuration access functions
> * @startup: pointer to controller setting functions
> * @setup_irq: pointer to initialize IRQ functions
> */
> struct mtk_pcie_soc {
> bool need_fix_class_id;
> + bool need_fix_device_id;
> + unsigned int device_id;
> struct pci_ops *ops;
> int (*startup)(struct mtk_pcie_port *port);
> int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> @@ -696,6 +701,9 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> writew(val, port->base + PCIE_CONF_CLASS_ID);
> }
>
> + if (soc->need_fix_device_id)
> + writew(soc->device_id, port->base + PCIE_CONF_DEVICE_ID);
> +
> /* 100ms timeout value should be enough for Gen1/2 training */
> err = readl_poll_timeout(port->base + PCIE_LINK_STATUS_V2, val,
> !!(val & PCIE_PORT_LINKUP_V2), 20,
> @@ -1216,11 +1224,21 @@ static const struct mtk_pcie_soc mtk_pcie_soc_mt7622 = {
> .setup_irq = mtk_pcie_setup_irq,
> };
>
> +static const struct mtk_pcie_soc mtk_pcie_soc_mt7629 = {
> + .need_fix_class_id = true,
> + .need_fix_device_id = true,
> + .device_id = PCI_DEVICE_ID_MEDIATEK_7629,
> + .ops = &mtk_pcie_ops_v2,
> + .startup = mtk_pcie_startup_port_v2,
> + .setup_irq = mtk_pcie_setup_irq,
> +};
> +
> static const struct of_device_id mtk_pcie_ids[] = {
> { .compatible = "mediatek,mt2701-pcie", .data = &mtk_pcie_soc_v1 },
> { .compatible = "mediatek,mt7623-pcie", .data = &mtk_pcie_soc_v1 },
> { .compatible = "mediatek,mt2712-pcie", .data = &mtk_pcie_soc_mt2712 },
> { .compatible = "mediatek,mt7622-pcie", .data = &mtk_pcie_soc_mt7622 },
> + { .compatible = "mediatek,mt7629-pcie", .data = &mtk_pcie_soc_mt7629 },
> {},
> };
>
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 70e86148cb1e..aa32962759b2 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2131,6 +2131,7 @@
> #define PCI_VENDOR_ID_MYRICOM 0x14c1
>
> #define PCI_VENDOR_ID_MEDIATEK 0x14c3
> +#define PCI_DEVICE_ID_MEDIATEK_7629 0x7629
>
> #define PCI_VENDOR_ID_TITAN 0x14D2
> #define PCI_DEVICE_ID_TITAN_010L 0x8001
Hi Bjorn & Lorenzo,
Is this patch ok or is there anything I need to fixed?
Thanks.
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: rcar-{csi2,vin}: Rename bindings documentation files
From: Simon Horman @ 2019-07-29 7:43 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Rob Herring, devicetree, linux-media, linux-renesas-soc,
Geert Uytterhoeven, Ulrich Hecht
In-Reply-To: <20190712071703.GE9317@wyvern>
On Fri, Jul 12, 2019 at 04:17:03PM +0900, Niklas Söderlund wrote:
> Hi,
>
> A gentle ping on this patch. I assume if it could get a ack from Rob it
> could be taken in thru the media-tree?
Given the lack of interest I think it could also be taken through
Geert's tree.
>
> On 2019-06-12 23:12:41 +0200, Niklas Söderlund wrote:
> > Renesas media binding documentation files uses a naming schema of
> > 'renesas,<module>.txt'. Rename VIN and CSI-2 files to match this
> > pattern.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
> > ---
> > .../media/{renesas,rcar-csi2.txt => renesas,csi2.txt} | 0
> > .../bindings/media/{rcar_vin.txt => renesas,vin.txt} | 0
> > MAINTAINERS | 4 ++--
> > 3 files changed, 2 insertions(+), 2 deletions(-)
> > rename Documentation/devicetree/bindings/media/{renesas,rcar-csi2.txt => renesas,csi2.txt} (100%)
> > rename Documentation/devicetree/bindings/media/{rcar_vin.txt => renesas,vin.txt} (100%)
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt b/Documentation/devicetree/bindings/media/renesas,csi2.txt
> > similarity index 100%
> > rename from Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > rename to Documentation/devicetree/bindings/media/renesas,csi2.txt
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/renesas,vin.txt
> > similarity index 100%
> > rename from Documentation/devicetree/bindings/media/rcar_vin.txt
> > rename to Documentation/devicetree/bindings/media/renesas,vin.txt
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 6a3bac28ebb47830..a0d21ff13c8e8989 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9807,8 +9807,8 @@ L: linux-media@vger.kernel.org
> > L: linux-renesas-soc@vger.kernel.org
> > T: git git://linuxtv.org/media_tree.git
> > S: Supported
> > -F: Documentation/devicetree/bindings/media/renesas,rcar-csi2.txt
> > -F: Documentation/devicetree/bindings/media/rcar_vin.txt
> > +F: Documentation/devicetree/bindings/media/renesas,csi2.txt
> > +F: Documentation/devicetree/bindings/media/renesas,vin.txt
> > F: drivers/media/platform/rcar-vin/
> >
> > MEDIA DRIVERS FOR RENESAS - VSP1
> > --
> > 2.21.0
> >
>
> --
> Regards,
> Niklas Söderlund
>
^ permalink raw reply
* [PATCH] dt-bindings: rcar-imr: Rename bindings documentation file
From: Simon Horman @ 2019-07-29 7:47 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Rob Herring, Mark Rutland, Magnus Damm, Geert Uytterhoeven,
linux-media, devicetree, linux-renesas-soc, Simon Horman,
Niklas Söderlund
Renesas media binding documentation files uses a naming schema of
'renesas,<module>.txt'. Rename IMR file to match this pattern.
Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/media/{rcar_imr.txt => renesas,imr.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/media/{rcar_imr.txt => renesas,imr.txt} (100%)
diff --git a/Documentation/devicetree/bindings/media/rcar_imr.txt b/Documentation/devicetree/bindings/media/renesas,imr.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/rcar_imr.txt
rename to Documentation/devicetree/bindings/media/renesas,imr.txt
--
2.11.0
^ permalink raw reply
* RE: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT
From: Anson Huang @ 2019-07-29 7:49 UTC (permalink / raw)
To: Daniel Baluta
Cc: Abel Vesa, rui.zhang@intel.com, edubezval@gmail.com,
daniel.lezcano@linaro.org, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Lucas Stach, Andrey Smirnov,
Angus Ainslie (Purism), Carlo Caione, Guido Günther,
Leonard Crestez, linux-pm
In-Reply-To: <CAEnQRZDSjmcU8Q7+kMeFf12tx0NuMNjrcsgnXayvHpu4ChwHGA@mail.gmail.com>
Hi, Daniel
> On Mon, Jul 29, 2019 at 10:20 AM Daniel Baluta <daniel.baluta@gmail.com>
> wrote:
> >
> > <snip>
> > > > Your explanation makes a lot of sense. We will take care today of
> > > > Abel's patch.
> > > > What do you think about Fabio's patch? I also think this is a valid patch:
> > > >
> > <snip>
> >
> > >
> > > Hmm, when did Fabio sent out this patch? I can NOT find it...
> > > I also have a patch in this series (#4/6) doing same thing on July 5th...
> > >
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> > >
> tchwork.kernel.org%2Fpatch%2F11032783%2F&data=02%7C01%7Canso
> n.hu
> > >
> ang%40nxp.com%7C048d8695b3dc4ceef6bd08d713f55e8a%7C686ea1d3bc2
> b4c6fa
> > >
> 92cd99c5c301635%7C0%7C0%7C636999816880118674&sdata=1HIMQ0l
> iKpEFS
> > > 6P2WSG%2FH9evspxIdxAvFmaklH1woDk%3D&reserved=0
> >
> > He didn't send the patch yet. It was just a request for test here:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.
> > bulix.org%2Fpd88jp-
> 812381&data=02%7C01%7Canson.huang%40nxp.com%7C0
> >
> 48d8695b3dc4ceef6bd08d713f55e8a%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0
> > %7C0%7C636999816880118674&sdata=p70mgCDucCgLJ8TTRMn3a%2
> Fk68FXGQeiR
> > FR0fVSV7Jlo%3D&reserved=0
> >
> > But, now I see is exactly like your patch here:
>
> ... pressed send to early.
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.o
> rg%2Flkml%2F2019%2F7%2F5%2F19&data=02%7C01%7Canson.huang%
> 40nxp.com%7C048d8695b3dc4ceef6bd08d713f55e8a%7C686ea1d3bc2b4c6f
> a92cd99c5c301635%7C0%7C0%7C636999816880118674&sdata=ciWj8y
> WPvkIZ5ni%2BohZuaqAXf9Pb2FCWhp9GQhpMwAY%3D&reserved=0
>
> We are all set then. Thanks Anson for clarifications!
Thanks, so we are all clear about this issue, need to wait thermal maintainer to review
the rest patch in this series, but I did NOT receive any response from thermal sub-system
maintainer for really long time, NOT sure when the thermal patches can be accepted.
Anson
^ permalink raw reply
* [PATCH] ASoC: meson: g12a-tohdmitx: override codec2codec params
From: Jerome Brunet @ 2019-07-29 8:01 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Kevin Hilman
Cc: Jerome Brunet, alsa-devel, devicetree, linux-kernel,
linux-amlogic
So far, forwarding the hw_params of the input to output relied on the
.hw_params() callback of the cpu side of the codec2codec link to be called
first. This is a bit weak.
Instead, override the stream params of the codec2codec to link to set it up
correctly.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
sound/soc/meson/g12a-tohdmitx.c | 34 ++++++++++++++++-----------------
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/sound/soc/meson/g12a-tohdmitx.c b/sound/soc/meson/g12a-tohdmitx.c
index 707ccb192e4c..9943c807ec5d 100644
--- a/sound/soc/meson/g12a-tohdmitx.c
+++ b/sound/soc/meson/g12a-tohdmitx.c
@@ -28,7 +28,7 @@
#define CTRL0_SPDIF_CLK_SEL BIT(0)
struct g12a_tohdmitx_input {
- struct snd_pcm_hw_params params;
+ struct snd_soc_pcm_stream params;
unsigned int fmt;
};
@@ -225,26 +225,17 @@ static int g12a_tohdmitx_input_hw_params(struct snd_pcm_substream *substream,
{
struct g12a_tohdmitx_input *data = dai->playback_dma_data;
- /* Save the stream params for the downstream link */
- memcpy(&data->params, params, sizeof(*params));
+ data->params.rates = snd_pcm_rate_to_rate_bit(params_rate(params));
+ data->params.rate_min = params_rate(params);
+ data->params.rate_max = params_rate(params);
+ data->params.formats = 1 << params_format(params);
+ data->params.channels_min = params_channels(params);
+ data->params.channels_max = params_channels(params);
+ data->params.sig_bits = dai->driver->playback.sig_bits;
return 0;
}
-static int g12a_tohdmitx_output_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params,
- struct snd_soc_dai *dai)
-{
- struct g12a_tohdmitx_input *in_data =
- g12a_tohdmitx_get_input_data(dai->capture_widget);
-
- if (!in_data)
- return -ENODEV;
-
- memcpy(params, &in_data->params, sizeof(*params));
-
- return 0;
-}
static int g12a_tohdmitx_input_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
@@ -266,6 +257,14 @@ static int g12a_tohdmitx_output_startup(struct snd_pcm_substream *substream,
if (!in_data)
return -ENODEV;
+ if (WARN_ON(!rtd->dai_link->params)) {
+ dev_warn(dai->dev, "codec2codec link expected\n");
+ return -EINVAL;
+ }
+
+ /* Replace link params with the input params */
+ rtd->dai_link->params = &in_data->params;
+
if (!in_data->fmt)
return 0;
@@ -278,7 +277,6 @@ static const struct snd_soc_dai_ops g12a_tohdmitx_input_ops = {
};
static const struct snd_soc_dai_ops g12a_tohdmitx_output_ops = {
- .hw_params = g12a_tohdmitx_output_hw_params,
.startup = g12a_tohdmitx_output_startup,
};
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 01/19] phy: mvebu-cp110-comphy: Add clocks support
From: Grzegorz Jaszczyk @ 2019-07-29 8:06 UTC (permalink / raw)
To: Miquel Raynal
Cc: Gregory Clement, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Kishon Vijay Abraham I, devicetree, Thomas Petazzoni,
Antoine Tenart, Maxime Chevallier, Nadav Haklai, Rob Herring,
Russell King, linux-arm-kernel
In-Reply-To: <20190627095104.22529-2-miquel.raynal@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 3079 bytes --]
Hi Miquel,
czw., 27 cze 2019 o 11:51 Miquel Raynal <miquel.raynal@bootlin.com>
napisał(a):
> +static int mvebu_comphy_init_clks(struct mvebu_comphy_priv *priv)
> +{
> + int ret;
> +
> + priv->mg_domain_clk = devm_clk_get(priv->dev, "mg_clk");
> + if (IS_ERR(priv->mg_domain_clk))
> + return PTR_ERR(priv->mg_domain_clk);
> +
> + ret = clk_prepare_enable(priv->mg_domain_clk);
> + if (ret < 0)
> + return ret;
> +
> + priv->mg_core_clk = devm_clk_get(priv->dev, "mg_core_clk");
> + if (IS_ERR(priv->mg_core_clk)) {
> + ret = PTR_ERR(priv->mg_core_clk);
> + goto dis_mg_domain_clk;
> + }
> +
> + ret = clk_prepare_enable(priv->mg_core_clk);
> + if (ret < 0)
> + goto dis_mg_domain_clk;
> +
> + priv->axi_clk = devm_clk_get(priv->dev, "axi_clk");
> + if (IS_ERR(priv->axi_clk)) {
> + ret = PTR_ERR(priv->axi_clk);
> + goto dis_mg_core_clk;
> + }
> +
> + ret = clk_prepare_enable(priv->axi_clk);
> + if (ret < 0)
> + goto dis_mg_core_clk;
> +
> + return 0;
> +
> +dis_mg_core_clk:
> + clk_disable_unprepare(priv->mg_core_clk);
> +
> +dis_mg_domain_clk:
> + clk_disable_unprepare(priv->mg_domain_clk);
> +
> + priv->mg_domain_clk = NULL;
> + priv->mg_core_clk = NULL;
> + priv->axi_clk = NULL;
> +
> + return ret;
> +};
> +
> +static void mvebu_comphy_disable_unprepare_clks(struct mvebu_comphy_priv
> *priv)
> +{
> + if (priv->axi_clk)
> + clk_disable_unprepare(priv->axi_clk);
> +
> + if (priv->mg_core_clk)
> + clk_disable_unprepare(priv->mg_core_clk);
> +
> + if (priv->mg_domain_clk)
> + clk_disable_unprepare(priv->mg_domain_clk);
> +}
> +
> static int mvebu_comphy_probe(struct platform_device *pdev)
> {
> struct mvebu_comphy_priv *priv;
> struct phy_provider *provider;
> struct device_node *child;
> struct resource *res;
> + int ret;
>
> priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> @@ -607,10 +671,17 @@ static int mvebu_comphy_probe(struct platform_device
> *pdev)
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
>
> + /*
> + * Ignore error if clocks have not been initialized properly for DT
> + * compatibility reasons.
> + */
> + ret = mvebu_comphy_init_clks(priv);
> + if (ret)
> + dev_warn(&pdev->dev, "cannot initialize clocks\n");
> +
>
Please request probe retry when clocks are not ready, e.g.:
- if (ret)
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ return ret;
dev_warn(&pdev->dev, "cannot initialize clocks\n");
+ }
After that you can put:
Tested-by: Grzegorz Jaszczyk <jaz@semihalf.com>
regards,
Grzegorz
[-- Attachment #2: Type: text/html, Size: 4146 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/19] phy: mvebu-cp110-comphy: Add clocks support
From: Grzegorz Jaszczyk @ 2019-07-29 8:10 UTC (permalink / raw)
To: Miquel Raynal
Cc: Andrew Lunn, Jason Cooper, devicetree, Antoine Tenart,
Gregory Clement, Russell King, Kishon Vijay Abraham I,
Nadav Haklai, Rob Herring, Thomas Petazzoni, Maxime Chevallier,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190627095104.22529-2-miquel.raynal@bootlin.com>
Hi Miquel
czw., 27 cze 2019 o 11:51 Miquel Raynal <miquel.raynal@bootlin.com> napisał(a):
> +static int mvebu_comphy_init_clks(struct mvebu_comphy_priv *priv)
> +{
> + int ret;
> +
> + priv->mg_domain_clk = devm_clk_get(priv->dev, "mg_clk");
> + if (IS_ERR(priv->mg_domain_clk))
> + return PTR_ERR(priv->mg_domain_clk);
> +
> + ret = clk_prepare_enable(priv->mg_domain_clk);
> + if (ret < 0)
> + return ret;
> +
> + priv->mg_core_clk = devm_clk_get(priv->dev, "mg_core_clk");
> + if (IS_ERR(priv->mg_core_clk)) {
> + ret = PTR_ERR(priv->mg_core_clk);
> + goto dis_mg_domain_clk;
> + }
> +
> + ret = clk_prepare_enable(priv->mg_core_clk);
> + if (ret < 0)
> + goto dis_mg_domain_clk;
> +
> + priv->axi_clk = devm_clk_get(priv->dev, "axi_clk");
> + if (IS_ERR(priv->axi_clk)) {
> + ret = PTR_ERR(priv->axi_clk);
> + goto dis_mg_core_clk;
> + }
> +
> + ret = clk_prepare_enable(priv->axi_clk);
> + if (ret < 0)
> + goto dis_mg_core_clk;
> +
> + return 0;
> +
> +dis_mg_core_clk:
> + clk_disable_unprepare(priv->mg_core_clk);
> +
> +dis_mg_domain_clk:
> + clk_disable_unprepare(priv->mg_domain_clk);
> +
> + priv->mg_domain_clk = NULL;
> + priv->mg_core_clk = NULL;
> + priv->axi_clk = NULL;
> +
> + return ret;
> +};
> +
> +static void mvebu_comphy_disable_unprepare_clks(struct mvebu_comphy_priv *priv)
> +{
> + if (priv->axi_clk)
> + clk_disable_unprepare(priv->axi_clk);
> +
> + if (priv->mg_core_clk)
> + clk_disable_unprepare(priv->mg_core_clk);
> +
> + if (priv->mg_domain_clk)
> + clk_disable_unprepare(priv->mg_domain_clk);
> +}
> +
> static int mvebu_comphy_probe(struct platform_device *pdev)
> {
> struct mvebu_comphy_priv *priv;
> struct phy_provider *provider;
> struct device_node *child;
> struct resource *res;
> + int ret;
>
> priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> @@ -607,10 +671,17 @@ static int mvebu_comphy_probe(struct platform_device *pdev)
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
>
> + /*
> + * Ignore error if clocks have not been initialized properly for DT
> + * compatibility reasons.
> + */
> + ret = mvebu_comphy_init_clks(priv);
> + if (ret)
> + dev_warn(&pdev->dev, "cannot initialize clocks\n");
> +
Please request probe retry when clocks are not ready, e.g.:
- if (ret)
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ return ret;
dev_warn(&pdev->dev, "cannot initialize clocks\n");
+ }
After that you can put:
Tested-by: Grzegorz Jaszczyk <jaz@semihalf.com>
regards,
Grzegorz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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