* [PATCH v14 01/10] dt-binding: gce: remove thread-num property
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-1-bibby.hsieh@mediatek.com>
"thread-num" is an unused property so we remove it from example.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
index 7d72b21c9e94..cfe40b01d164 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -39,7 +39,6 @@ Example:
interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
clocks = <&infracfg CLK_INFRA_GCE>;
clock-names = "gce";
- thread-num = CMDQ_THR_MAX_COUNT;
#mbox-cells = <3>;
};
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 06/10] soc: mediatek: cmdq: clear the event in cmdq initial flow
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-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 f3ae45d02e80..9618debb9ceb 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 04/10] mailbox: mediatek: cmdq: move the CMDQ_IRQ_MASK into cmdq driver data
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-1-bibby.hsieh@mediatek.com>
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@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 10/10] arm64: dts: add gce node for mt8183
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-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 66aaa07f6cec..52b9af38a00a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -9,6 +9,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/power/mt8183-power.h>
+#include <dt-bindings/gce/mt8183-gce.h>
#include "mt8183-pinfunc.h"
/ {
@@ -321,6 +322,15 @@
status = "disabled";
};
+ gce: mailbox@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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 03/10] dt-binding: gce: add binding for gce client reg property
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-1-bibby.hsieh@mediatek.com>
cmdq driver provide a function that get the relationship
of sub system number from device node for client.
add specification for #subsys-cells, mediatek,gce-client-reg.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/mailbox/mtk-gce.txt | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
index 1f7f8f2a3f49..7b13787ab13d 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -25,8 +25,16 @@ Required properties:
Required properties for a client device:
- mboxes: Client use mailbox to communicate with GCE, it should have this
property and list of phandle, mailbox specifiers.
-- mediatek,gce-subsys: u32, specify the sub-system id which is corresponding
- to the register address.
+Optional properties for a client device:
+- mediatek,gce-client-reg: Specify the sub-system id which is corresponding
+ to the register address, it should have this property and list of phandle,
+ sub-system specifiers.
+ <&phandle subsys_number start_offset size>
+ phandle: Label name of a gce node.
+ subsys_number: specify the sub-system id which is corresponding
+ to the register address.
+ 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.
@@ -48,9 +56,9 @@ Example for a client device:
compatible = "mediatek,mt8173-mmsys";
mboxes = <&gce 0 CMDQ_THR_PRIO_LOWEST 1>,
<&gce 1 CMDQ_THR_PRIO_LOWEST 1>;
- mediatek,gce-subsys = <SUBSYS_1400XXXX>;
mutex-event-eof = <CMDQ_EVENT_MUTEX0_STREAM_EOF
CMDQ_EVENT_MUTEX1_STREAM_EOF>;
-
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x3000 0x1000>,
+ <&gce SUBSYS_1401XXXX 0x2000 0x100>;
...
};
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 05/10] mailbox: mediatek: cmdq: support mt8183 gce function
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 06/10] mailbox: mediatek: cmdq: clear the event in cmdq initial flow
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-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>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/mailbox/mtk-cmdq-mailbox.c | 5 +++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 3 +++
include/linux/soc/mediatek/mtk-cmdq.h | 3 ---
3 files changed, 8 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..e6f54ef6698b 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -20,6 +20,9 @@
#define CMDQ_WFE_WAIT BIT(15)
#define CMDQ_WFE_WAIT_VALUE 0x1
+/** cmdq event maximum */
+#define CMDQ_MAX_EVENT 0x3ff
+
/*
* CMDQ_CODE_MASK:
* set write mask
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index f3ae45d02e80..9618debb9ceb 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 09/10] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-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>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Houlong Wei <houlong.wei@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 bec7bb6c3988..3037fbf206ef 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 = (u8)spec.args[0];
+ client_reg->offset = (u16)spec.args[1];
+ client_reg->size = (u16)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 92bd5b5c6341..a74c1d5acdf3 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;
@@ -24,6 +30,21 @@ struct cmdq_client {
u32 timeout_ms; /* in unit of microsecond */
};
+/**
+ * cmdq_dev_get_client_reg() - parse cmdq client reg from the device
+ * node of CMDQ client
+ * @dev: device of CMDQ mailbox client
+ * @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 parsing 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);
+
/**
* cmdq_mbox_create() - create CMDQ mailbox client and channel
* @dev: device of CMDQ mailbox client
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 02/10] dt-binding: gce: add gce header file for mt8183
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-1-bibby.hsieh@mediatek.com>
Add documentation for the mt8183 gce.
Add gce header file defined the gce hardware event,
subsys number and constant for mt8183.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/mailbox/mtk-gce.txt | 6 +-
include/dt-bindings/gce/mt8183-gce.h | 175 ++++++++++++++++++
2 files changed, 178 insertions(+), 3 deletions(-)
create mode 100644 include/dt-bindings/gce/mt8183-gce.h
diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
index cfe40b01d164..1f7f8f2a3f49 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -9,7 +9,7 @@ CMDQ driver uses mailbox framework for communication. Please refer to
mailbox.txt for generic information about mailbox device-tree bindings.
Required properties:
-- compatible: Must be "mediatek,mt8173-gce"
+- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce"
- reg: Address range of the GCE unit
- interrupts: The interrupt signal from the GCE block
- clock: Clocks according to the common clock binding
@@ -28,8 +28,8 @@ Required properties for a client device:
- mediatek,gce-subsys: u32, specify the sub-system id which is corresponding
to the register address.
-Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'. Such as
-sub-system ids, thread priority, event ids.
+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.
Example:
diff --git a/include/dt-bindings/gce/mt8183-gce.h b/include/dt-bindings/gce/mt8183-gce.h
new file mode 100644
index 000000000000..29c967476f73
--- /dev/null
+++ b/include/dt-bindings/gce/mt8183-gce.h
@@ -0,0 +1,175 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Bibby Hsieh <bibby.hsieh@mediatek.com>
+ *
+ */
+
+#ifndef _DT_BINDINGS_GCE_MT8183_H
+#define _DT_BINDINGS_GCE_MT8183_H
+
+#define CMDQ_NO_TIMEOUT 0xffffffff
+
+/* GCE HW thread priority */
+#define CMDQ_THR_PRIO_LOWEST 0
+#define CMDQ_THR_PRIO_HIGHEST 1
+
+/* GCE SUBSYS */
+#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_EVENT_DISP_RDMA0_SOF 0
+#define CMDQ_EVENT_DISP_RDMA1_SOF 1
+#define CMDQ_EVENT_MDP_RDMA0_SOF 2
+#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_WDMA0_SOF 8
+#define CMDQ_EVENT_DISP_OVL0_SOF 9
+#define CMDQ_EVENT_DISP_OVL0_2L_SOF 10
+#define CMDQ_EVENT_DISP_OVL1_2L_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_RSZ_SOF 22
+#define CMDQ_EVENT_MDP_AAL_SOF 23
+#define CMDQ_EVENT_MDP_CCORR_SOF 24
+#define CMDQ_EVENT_DISP_DBI_SOF 25
+#define CMDQ_EVENT_DISP_RDMA0_EOF 26
+#define CMDQ_EVENT_DISP_RDMA1_EOF 27
+#define CMDQ_EVENT_MDP_RDMA0_EOF 28
+#define CMDQ_EVENT_MDP_RSZ0_EOF 30
+#define CMDQ_EVENT_MDP_RSZ1_EOF 31
+#define CMDQ_EVENT_MDP_TDSHP_EOF 32
+#define CMDQ_EVENT_MDP_WROT0_EOF 33
+#define CMDQ_EVENT_MDP_WDMA0_EOF 34
+#define CMDQ_EVENT_DISP_OVL0_EOF 35
+#define CMDQ_EVENT_DISP_OVL0_2L_EOF 36
+#define CMDQ_EVENT_DISP_OVL1_2L_EOF 37
+#define CMDQ_EVENT_DISP_WDMA0_EOF 38
+#define CMDQ_EVENT_DISP_COLOR0_EOF 39
+#define CMDQ_EVENT_DISP_CCORR0_EOF 40
+#define CMDQ_EVENT_DISP_AAL0_EOF 41
+#define CMDQ_EVENT_DISP_GAMMA0_EOF 42
+#define CMDQ_EVENT_DISP_DITHER0_EOF 43
+#define CMDQ_EVENT_DSI0_EOF 44
+#define CMDQ_EVENT_DPI0_EOF 45
+#define CMDQ_EVENT_DISP_RSZ_EOF 47
+#define CMDQ_EVENT_MDP_AAL_EOF 48
+#define CMDQ_EVENT_MDP_CCORR_EOF 49
+#define CMDQ_EVENT_DBI_EOF 50
+#define CMDQ_EVENT_MUTEX_STREAM_DONE0 130
+#define CMDQ_EVENT_MUTEX_STREAM_DONE1 131
+#define CMDQ_EVENT_MUTEX_STREAM_DONE2 132
+#define CMDQ_EVENT_MUTEX_STREAM_DONE3 133
+#define CMDQ_EVENT_MUTEX_STREAM_DONE4 134
+#define CMDQ_EVENT_MUTEX_STREAM_DONE5 135
+#define CMDQ_EVENT_MUTEX_STREAM_DONE6 136
+#define CMDQ_EVENT_MUTEX_STREAM_DONE7 137
+#define CMDQ_EVENT_MUTEX_STREAM_DONE8 138
+#define CMDQ_EVENT_MUTEX_STREAM_DONE9 139
+#define CMDQ_EVENT_MUTEX_STREAM_DONE10 140
+#define CMDQ_EVENT_MUTEX_STREAM_DONE11 141
+#define CMDQ_EVENT_DISP_RDMA0_BUF_UNDERRUN_EVEN 142
+#define CMDQ_EVENT_DISP_RDMA1_BUF_UNDERRUN_EVEN 143
+#define CMDQ_EVENT_DSI0_TE_EVENT 144
+#define CMDQ_EVENT_DSI0_IRQ_EVENT 145
+#define CMDQ_EVENT_DSI0_DONE_EVENT 146
+#define CMDQ_EVENT_DISP_WDMA0_SW_RST_DONE 150
+#define CMDQ_EVENT_MDP_WDMA_SW_RST_DONE 151
+#define CMDQ_EVENT_MDP_WROT0_SW_RST_DONE 152
+#define CMDQ_EVENT_MDP_RDMA0_SW_RST_DONE 154
+#define CMDQ_EVENT_DISP_OVL0_FRAME_RST_DONE_PULE 155
+#define CMDQ_EVENT_DISP_OVL0_2L_FRAME_RST_DONE_ULSE 156
+#define CMDQ_EVENT_DISP_OVL1_2L_FRAME_RST_DONE_ULSE 157
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_0 257
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_1 258
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_2 259
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_3 260
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_4 261
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_5 262
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_6 263
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_7 264
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_8 265
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_9 266
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_10 267
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_11 268
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_12 269
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_13 270
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_14 271
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_15 272
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_16 273
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_17 274
+#define CMDQ_EVENT_ISP_FRAME_DONE_P2_18 275
+#define CMDQ_EVENT_AMD_FRAME_DONE 276
+#define CMDQ_EVENT_DVE_DONE 277
+#define CMDQ_EVENT_WMFE_DONE 278
+#define CMDQ_EVENT_RSC_DONE 279
+#define CMDQ_EVENT_MFB_DONE 280
+#define CMDQ_EVENT_WPE_A_DONE 281
+#define CMDQ_EVENT_SPE_B_DONE 282
+#define CMDQ_EVENT_OCC_DONE 283
+#define CMDQ_EVENT_VENC_CMDQ_FRAME_DONE 289
+#define CMDQ_EVENT_JPG_ENC_CMDQ_DONE 290
+#define CMDQ_EVENT_JPG_DEC_CMDQ_DONE 291
+#define CMDQ_EVENT_VENC_CMDQ_MB_DONE 292
+#define CMDQ_EVENT_VENC_CMDQ_128BYTE_DONE 293
+#define CMDQ_EVENT_ISP_FRAME_DONE_A 321
+#define CMDQ_EVENT_ISP_FRAME_DONE_B 322
+#define CMDQ_EVENT_CAMSV0_PASS1_DONE 323
+#define CMDQ_EVENT_CAMSV1_PASS1_DONE 324
+#define CMDQ_EVENT_CAMSV2_PASS1_DONE 325
+#define CMDQ_EVENT_TSF_DONE 326
+#define CMDQ_EVENT_SENINF_CAM0_FIFO_FULL 327
+#define CMDQ_EVENT_SENINF_CAM1_FIFO_FULL 328
+#define CMDQ_EVENT_SENINF_CAM2_FIFO_FULL 329
+#define CMDQ_EVENT_SENINF_CAM3_FIFO_FULL 330
+#define CMDQ_EVENT_SENINF_CAM4_FIFO_FULL 331
+#define CMDQ_EVENT_SENINF_CAM5_FIFO_FULL 332
+#define CMDQ_EVENT_SENINF_CAM6_FIFO_FULL 333
+#define CMDQ_EVENT_SENINF_CAM7_FIFO_FULL 334
+#define CMDQ_EVENT_IPU_CORE0_DONE0 353
+#define CMDQ_EVENT_IPU_CORE0_DONE1 354
+#define CMDQ_EVENT_IPU_CORE0_DONE2 355
+#define CMDQ_EVENT_IPU_CORE0_DONE3 356
+#define CMDQ_EVENT_IPU_CORE1_DONE0 385
+#define CMDQ_EVENT_IPU_CORE1_DONE1 386
+#define CMDQ_EVENT_IPU_CORE1_DONE2 387
+#define CMDQ_EVENT_IPU_CORE1_DONE3 388
+
+#endif
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 08/10] soc: mediatek: cmdq: add polling function
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-1-bibby.hsieh@mediatek.com>
add polling function in cmdq helper functions
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Houlong Wei <houlong.wei@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 30 ++++++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h | 32 ++++++++++++++++++++++++
3 files changed, 63 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 9472526ab076..bec7bb6c3988 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -211,6 +211,36 @@ 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)
+{
+ struct cmdq_instruction inst;
+
+ inst.op = CMDQ_CODE_POLL;
+ inst.value = value;
+ inst.offset = offset;
+ inst.subsys = subsys;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_poll);
+
+int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value, u32 mask)
+{
+ struct cmdq_instruction inst = { {0} };
+ int err = 0;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ offset = offset | 0x1;
+ err |= cmdq_pkt_poll(pkt, subsys, offset, value);
+
+ return err;
+}
+EXPORT_SYMBOL(cmdq_pkt_poll_mask);
+
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 678760548791..a4dc45fbec0a 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -55,6 +55,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..92bd5b5c6341 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -99,6 +99,38 @@ 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 w/o mask.
+ * 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
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
+ u16 offset, u32 value);
+
+/**
+ * cmdq_pkt_poll_mask() - 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 w/ mask.
+ * 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_mask(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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v14 07/10] soc: mediatek: cmdq: define the instruction struct
From: Bibby Hsieh @ 2019-08-29 1:48 UTC (permalink / raw)
To: Jassi Brar, Matthias Brugger, Rob Herring, CK HU
Cc: devicetree, Nicolas Boichat, srv_heupstream, linux-kernel,
Houlong Wei, Dennis-YC Hsieh, linux-mediatek, Bibby Hsieh,
linux-arm-kernel
In-Reply-To: <20190829014817.25482-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>
Reviewed-by: Houlong Wei <houlong.wei@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 77 ++++++++++++++++--------
include/linux/mailbox/mtk-cmdq-mailbox.h | 10 +++
2 files changed, 61 insertions(+), 26 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 7aa0517ff2f3..9472526ab076 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,10 @@ 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 int cmdq_pkt_append_command(struct cmdq_pkt *pkt,
+ struct cmdq_instruction inst)
{
- u64 *cmd_ptr;
+ struct cmdq_instruction *cmd_ptr;
if (unlikely(pkt->cmd_buf_size + CMDQ_INST_SIZE > pkt->buf_size)) {
/*
@@ -129,8 +141,9 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
__func__, (u32)pkt->buf_size);
return -ENOMEM;
}
+
cmd_ptr = pkt->va_base + pkt->cmd_buf_size;
- (*cmd_ptr) = (u64)((code << CMDQ_OP_CODE_SHIFT) | arg_a) << 32 | arg_b;
+ *cmd_ptr = inst;
pkt->cmd_buf_size += CMDQ_INST_SIZE;
return 0;
@@ -138,24 +151,31 @@ static int cmdq_pkt_append_command(struct cmdq_pkt *pkt, enum cmdq_code code,
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.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 cmdq_pkt_append_command(pkt, inst);
}
EXPORT_SYMBOL(cmdq_pkt_write);
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask)
{
- u32 offset_mask = offset;
+ struct cmdq_instruction inst = { {0} };
+ u16 offset_mask = offset;
int err = 0;
if (mask != 0xffffffff) {
- err = cmdq_pkt_append_command(pkt, CMDQ_CODE_MASK, 0, ~mask);
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
offset_mask |= CMDQ_WRITE_ENABLE_MASK;
}
- err |= cmdq_pkt_write(pkt, value, subsys, offset_mask);
+ err |= cmdq_pkt_write(pkt, subsys, offset_mask, value);
return err;
}
@@ -163,43 +183,48 @@ EXPORT_SYMBOL(cmdq_pkt_write_mask);
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
- u32 arg_b;
+ struct cmdq_instruction inst = { {0} };
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.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 cmdq_pkt_append_command(pkt, inst);
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
+ struct cmdq_instruction inst = { {0} };
+
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
- return cmdq_pkt_append_command(pkt, CMDQ_CODE_WFE, event,
- CMDQ_WFE_UPDATE);
+ inst.op = CMDQ_CODE_WFE;
+ inst.value = CMDQ_WFE_UPDATE;
+ inst.event = event;
+
+ return cmdq_pkt_append_command(pkt, inst);
}
EXPORT_SYMBOL(cmdq_pkt_clear_event);
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
- int err;
+ struct cmdq_instruction inst = { {0} };
+ int err = 0;
/* 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;
+ err = cmdq_pkt_append_command(pkt, inst);
/* JUMP to end */
- err |= cmdq_pkt_append_command(pkt, CMDQ_CODE_JUMP, 0, CMDQ_JUMP_PASS);
+ inst.op = CMDQ_CODE_JUMP;
+ inst.value = CMDQ_JUMP_PASS;
+ err |= cmdq_pkt_append_command(pkt, inst);
return err;
}
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index e6f54ef6698b..678760548791 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -20,6 +20,16 @@
#define CMDQ_WFE_WAIT BIT(15)
#define CMDQ_WFE_WAIT_VALUE 0x1
+/*
+ * 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
+ */
+#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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Xiaowei Bao @ 2019-08-29 2:03 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, kishon@ti.com, M.h. Lian,
robh+dt@kernel.org, gustavo.pimentel@synopsys.com,
jingoohan1@gmail.com, bhelgaas@google.com, Leo Li,
shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828090105.GR14582@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年8月28日 17:01
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support for
> ls1088a and ls2088a
>
> On Wed, Aug 28, 2019 at 04:29:32AM +0000, Xiaowei Bao wrote:
> >
> >
> > > -----Original Message-----
> > > From: Andrew Murray <andrew.murray@arm.com>
> > > Sent: 2019年8月27日 21:34
> > > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > > lorenzo.pieralisi@arm.co; arnd@arndb.de; gregkh@linuxfoundation.org;
> M.h.
> > > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode support
> > > for ls1088a and ls2088a
> > >
> > > On Mon, Aug 26, 2019 at 09:49:35AM +0000, Xiaowei Bao wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Andrew Murray <andrew.murray@arm.com>
> > > > > Sent: 2019年8月23日 22:28
> > > > > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > > Cc: bhelgaas@google.com; robh+dt@kernel.org;
> > > > > mark.rutland@arm.com; shawnguo@kernel.org; Leo Li
> > > > > <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.co;
> > > > > arnd@arndb.de; gregkh@linuxfoundation.org;
> > > M.h.
> > > > > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>;
> > > > > Roy Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > > > > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > > > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > > linux-arm-kernel@lists.infradead.org;
> > > > > linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: [PATCH v2 08/10] PCI: layerscape: Add EP mode
> > > > > support for ls1088a and ls2088a
> > > > >
> > > > > On Thu, Aug 22, 2019 at 07:22:40PM +0800, Xiaowei Bao wrote:
> > > > > > Add PCIe EP mode support for ls1088a and ls2088a, there are
> > > > > > some difference between LS1 and LS2 platform, so refactor the
> > > > > > code of the EP driver.
> > > > > >
> > > > > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > > > > ---
> > > > > > v2:
> > > > > > - New mechanism for layerscape EP driver.
> > > > >
> > > > > Was there a v1 of this patch?
> > > > >
> > > > > >
> > > > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 76
> > > > > > ++++++++++++++++++++------
> > > > > > 1 file changed, 58 insertions(+), 18 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > index 7ca5fe8..2a66f07 100644
> > > > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > @@ -20,27 +20,29 @@
> > > > > >
> > > > > > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > > > > >
> > > > > > -struct ls_pcie_ep {
> > > > > > - struct dw_pcie *pci;
> > > > > > - struct pci_epc_features *ls_epc;
> > > > > > +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > > +
> > > > > > +struct ls_pcie_ep_drvdata {
> > > > > > + u32 func_offset;
> > > > > > + const struct dw_pcie_ep_ops *ops;
> > > > > > + const struct dw_pcie_ops *dw_pcie_ops;
> > > > > > };
> > > > > >
> > > > > > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > > +struct ls_pcie_ep {
> > > > > > + struct dw_pcie *pci;
> > > > > > + struct pci_epc_features *ls_epc;
> > > > > > + const struct ls_pcie_ep_drvdata *drvdata; };
> > > > > >
> > > > > > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > > > > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > > > > .start_link = ls_pcie_establish_link, };
> > > > > >
> > > > > > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > > > - { .compatible = "fsl,ls-pcie-ep",},
> > > > > > - { },
> > > > > > -};
> > > > > > -
> > > > > > static const struct pci_epc_features*
> > > > > > ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -82,10
> > > > > > +84,44 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep,
> u8 func_no,
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > > > > +static unsigned int ls_pcie_ep_func_conf_select(struct
> > > > > > +dw_pcie_ep
> > > *ep,
> > > > > > + u8 func_no)
> > > > > > +{
> > > > > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > > > > + u8 header_type;
> > > > > > +
> > > > > > + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > > > > > +
> > > > > > + if (header_type & (1 << 7))
> > > > > > + return pcie->drvdata->func_offset * func_no;
> > > > > > + else
> > > > > > + return 0;
> > > > >
> > > > > It looks like there isn't a PCI define for multi function, the
> > > > > nearest I could find was PCI_HEADER_TYPE_MULTIDEVICE in
> > > > > hotplug/ibmphp.h. A comment above the test might be helpful to
> > > > > explain
> > > the test.
> > > >
> > > > OK, I will add a comment above this code.
> > > >
> > > > >
> > > > > As the ls_pcie_ep_drvdata structures are static, the unset
> > > > > .func_offset will be initialised to 0, so you could just drop the test
> above.
> > > >
> > > > Due to the different PCIe controller have different property, e.g.
> > > > PCIe controller1 support multiple function feature, but PCIe
> > > > controller2 don't support this feature, so I need to check which
> > > > controller support it and return the correct offset value, but
> > > > each board only
> > > have one ls_pcie_ep_drvdata, ^_^.
> > >
> > > Yes but if they don't support the feature then func_offset will be 0.
> > >
> > > >
> > > > >
> > > > > However something to the effect of the following may help spot
> > > > > misconfiguration:
> > > > >
> > > > > WARN_ON(func_no && !pcie->drvdata->func_offset); return
> > > > > pcie->drvdata->func_offset * func_no;
> > > > >
> > > > > The WARN is probably quite useful as if you are attempting to
> > > > > use non-zero functions and func_offset isn't set - then things
> > > > > may appear to work normally but actually will break horribly.
> > > >
> > > > As discussion before, I think the func_offset should not depends
> > > > on the function number, even if other platforms of NXP may be use
> > > > write registers way to access the different function config space.
> > >
> > > I agree that func_offset is an optional parameter. But if you are
> > > attempting to determine the offset of a function and you are given a
> > > non-zero function number - then something has gone wrong if func_offset
> is 0.
> >
> > I have understood you means, maybe I need to set a flag in the
> > driver_data struct, because I may add other platform of NXP, these
> > platform use the write register method to access different function, e.g.
> > write func_num to register, then we can access this func_num config space.
> >
> > I will modify the code like this? Do you have better advice?
> > Case1:
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index 004a7e8..8a0d6df 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -23,6 +23,7 @@
> > #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> >
> > struct ls_pcie_ep_drvdata {
> > + u8 func_config_flag;
> > u32 func_offset;
> > const struct dw_pcie_ep_ops *ops;
> > const struct dw_pcie_ops *dw_pcie_ops;
> > @@ -97,8 +98,14 @@ static unsigned int
> ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> > * Read the Header Type register of config space to check
> > * whether this PCI device support the multiple function.
> > */
> > - if (header_type & (1 << 7))
> > - return pcie->drvdata->func_offset * func_no;
> > + if (header_type & (1 << 7)) {
> > + if (pcie->drvdata->func_config_flag) {
> > + iowrite32((func_num << n), pci->dbi_base +
> PCI_XXXX_XXX);
> > + } else {
> > + WARN_ON(func_no
> && !pcie->drvdata->func_offset);
> > + return pcie->drvdata->func_offset * func_no;
> > + }
> > + }
> >
> > return 0;
> > }
> >
> > Of course, I don't need to set the flag this time, because I don't use
> > the second method(write register method), so the code like this:
> > case2:
> > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> > +*ep,
> > u8 func_no) {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > u8 header_type;
> >
> > of course, this code is not requied, due to the
> > pcie->drvdata->func_offset is 0, but I think this is more clear
> > if use this code.
> > header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> >
> > /*
> > * Read the Header Type register of config space to check
> > * whether this PCI device support the multiple function.
> > */
> > if (header_type & (1 << 7)) {
> > WARN_ON(func_no && !pcie->drvdata->func_offset);
> > return pcie->drvdata->func_offset * func_no;
> > }
> >
> > return 0;
> > }
> >
> > Or like this:
> > Case3:
> > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> > +*ep,
> > u8 func_no) {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> >
> > WARN_ON(func_no && !pcie->drvdata->func_offset);
> > return pcie->drvdata->func_offset * func_no;
>
> This is better. Given there is only currently one method of calculating an offset
> for layerscape, I'd recommend you add additional methods when the need
> arises.
OK, thanks
>
> Thanks,
>
> Andrew Murray
>
> >
> > }
> > Of course, we can return a -1 by adjuring the (func_no &&
> > !pcie->drvdata->func_offset) Valu in case1
> >
> > Thanks
> > Xiaowei
> >
> > >
> > > Thanks,
> > >
> > > Andrew Murray
> > >
> > > >
> > > > I have added the comments above the code, as follow, do you have
> > > > any
> > > advice?
> > > > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep
> *ep,
> > > > + u8 func_no)
> {
> > > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > > + u8 header_type;
> > > > +
> > > > + header_type = ioread8(pci->dbi_base + PCI_HEADER_TYPE);
> > > > +
> > > > + /*
> > > > + * Read the Header Type register of config space to check
> > > > + * whether this PCI device support the multiple function.
> > > > + */
> > > > + if (header_type & (1 << 7))
> > > > + return pcie->drvdata->func_offset * func_no;
> > > > +
> > > > + return 0;
> > > > +}
> > > >
> > > > Thanks a lot for your detail comments.
> > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Andrew Murray
> > > > >
> > > > > > +}
> > > > > > +
> > > > > > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > > > > > .ep_init = ls_pcie_ep_init,
> > > > > > .raise_irq = ls_pcie_ep_raise_irq,
> > > > > > .get_features = ls_pcie_ep_get_features,
> > > > > > + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > > > > > +
> > > > > > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > > > > > + .ops = &ls_pcie_ep_ops,
> > > > > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > > > > > +
> > > > > > +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > > > > > + .func_offset = 0x20000,
> > > > > > + .ops = &ls_pcie_ep_ops,
> > > > > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops, };
> > > > > > +
> > > > > > +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > > > + { .compatible = "fsl,ls1046a-pcie-ep", .data =
> &ls1_ep_drvdata },
> > > > > > + { .compatible = "fsl,ls1088a-pcie-ep", .data =
> &ls2_ep_drvdata },
> > > > > > + { .compatible = "fsl,ls2088a-pcie-ep", .data =
> &ls2_ep_drvdata },
> > > > > > + { },
> > > > > > };
> > > > > >
> > > > > > static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@
> > > > > > -98,7
> > > > > > +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep
> > > > > > +*pcie,
> > > > > > int ret;
> > > > > >
> > > > > > ep = &pci->ep;
> > > > > > - ep->ops = &pcie_ep_ops;
> > > > > > + ep->ops = pcie->drvdata->ops;
> > > > > >
> > > > > > res = platform_get_resource_byname(pdev,
> IORESOURCE_MEM,
> > > > > "addr_space");
> > > > > > if (!res)
> > > > > > @@ -137,14 +173,11 @@ static int __init
> > > > > > ls_pcie_ep_probe(struct
> > > > > platform_device *pdev)
> > > > > > if (!ls_epc)
> > > > > > return -ENOMEM;
> > > > > >
> > > > > > - dbi_base = platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM,
> > > > > "regs");
> > > > > > - pci->dbi_base = devm_pci_remap_cfg_resource(dev,
> dbi_base);
> > > > > > - if (IS_ERR(pci->dbi_base))
> > > > > > - return PTR_ERR(pci->dbi_base);
> > > > > > + pcie->drvdata = of_device_get_match_data(dev);
> > > > > >
> > > > > > - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > > > > pci->dev = dev;
> > > > > > - pci->ops = &ls_pcie_ep_ops;
> > > > > > + pci->ops = pcie->drvdata->dw_pcie_ops;
> > > > > > +
> > > > > > pcie->pci = pci;
> > > > > >
> > > > > > ls_epc->linkup_notifier = false, @@ -152,6 +185,13 @@ static
> > > > > > int __init ls_pcie_ep_probe(struct platform_device *pdev)
> > > > > >
> > > > > > pcie->ls_epc = ls_epc;
> > > > > >
> > > > > > + dbi_base = platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM,
> > > > > "regs");
> > > > > > + pci->dbi_base = devm_pci_remap_cfg_resource(dev,
> dbi_base);
> > > > > > + if (IS_ERR(pci->dbi_base))
> > > > > > + return PTR_ERR(pci->dbi_base);
> > > > > > +
> > > > > > + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > > > > +
> > > > > > platform_set_drvdata(pdev, pcie);
> > > > > >
> > > > > > ret = ls_add_pcie_ep(pcie, pdev);
> > > > > > --
> > > > > > 2.9.5
> > > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: rockchip: Properly handle optional regulators【请注意，邮件由linux-rockchip-bounces+shawn.lin=rock-chips.com@lists.infradead.org代发】
From: Shawn Lin @ 2019-08-29 2:31 UTC (permalink / raw)
To: Thierry Reding, Lorenzo Pieralisi, Bjorn Helgaas
Cc: Heiko Stuebner, linux-pci, shawn.lin, Vidya Sagar, linux-rockchip,
Andrew Murray, linux-arm-kernel
In-Reply-To: <20190828150737.30285-1-thierry.reding@gmail.com>
On 2019/8/28 23:07, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> regulator_get_optional() can fail for a number of reasons besides probe
> deferral. It can for example return -ENOMEM if it runs out of memory as
> it tries to allocate data structures. Propagating only -EPROBE_DEFER is
> problematic because it results in these legitimately fatal errors being
> treated as "regulator not specified in DT".
>
> What we really want is to ignore the optional regulators only if they
> have not been specified in DT. regulator_get_optional() returns -ENODEV
> in this case, so that's the special case that we need to handle. So we
> propagate all errors, except -ENODEV, so that real failures will still
> cause the driver to fail probe.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
LGTM,
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
> drivers/pci/controller/pcie-rockchip-host.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> index 8d20f1793a61..ef8e677ce9d1 100644
> --- a/drivers/pci/controller/pcie-rockchip-host.c
> +++ b/drivers/pci/controller/pcie-rockchip-host.c
> @@ -608,29 +608,29 @@ static int rockchip_pcie_parse_host_dt(struct rockchip_pcie *rockchip)
>
> rockchip->vpcie12v = devm_regulator_get_optional(dev, "vpcie12v");
> if (IS_ERR(rockchip->vpcie12v)) {
> - if (PTR_ERR(rockchip->vpcie12v) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie12v) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie12v);
> dev_info(dev, "no vpcie12v regulator found\n");
> }
>
> rockchip->vpcie3v3 = devm_regulator_get_optional(dev, "vpcie3v3");
> if (IS_ERR(rockchip->vpcie3v3)) {
> - if (PTR_ERR(rockchip->vpcie3v3) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie3v3) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie3v3);
> dev_info(dev, "no vpcie3v3 regulator found\n");
> }
>
> rockchip->vpcie1v8 = devm_regulator_get_optional(dev, "vpcie1v8");
> if (IS_ERR(rockchip->vpcie1v8)) {
> - if (PTR_ERR(rockchip->vpcie1v8) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie1v8) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie1v8);
> dev_info(dev, "no vpcie1v8 regulator found\n");
> }
>
> rockchip->vpcie0v9 = devm_regulator_get_optional(dev, "vpcie0v9");
> if (IS_ERR(rockchip->vpcie0v9)) {
> - if (PTR_ERR(rockchip->vpcie0v9) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + if (PTR_ERR(rockchip->vpcie0v9) != -ENODEV)
> + return PTR_ERR(rockchip->vpcie0v9);
> dev_info(dev, "no vpcie0v9 regulator found\n");
> }
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-08-29 2:46 UTC (permalink / raw)
To: Stefano Stabellini
Cc: linux@armlinux.org.uk, linux-kernel@vger.kernel.org, dl-linux-imx,
van.freenix@gmail.com, xen-devel@lists.xenproject.org,
Robin Murphy, linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.DEB.2.21.1908281103290.25361@sstabellini-ThinkPad-T480s>
Hi Stefano,
> Subject: RE: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
>
> On Wed, 28 Aug 2019, Peng Fan wrote:
> > Hi Robin,
> >
> > > Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> > >
> > > On 09/07/2019 09:22, Peng Fan wrote:
> > > > arm64 shares some code under arch/arm/xen, including mm.c.
> > > > However ZONE_DMA is removed by commit
> > > > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > > > So to ARM64, need use __GFP_DMA32.
>
> Hi Peng,
>
> Sorry for being so late in replying, this email got lost in the noise.
>
>
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > > arch/arm/xen/mm.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > > > e1d44b903dfc..a95e76d18bf9 100644
> > > > --- a/arch/arm/xen/mm.c
> > > > +++ b/arch/arm/xen/mm.c
> > > > @@ -27,7 +27,7 @@ unsigned long
> > > > xen_get_swiotlb_free_pages(unsigned
> > > > int order)
> > > >
> > > > for_each_memblock(memory, reg) {
> > > > if (reg->base < (phys_addr_t)0xffffffff) {
> > > > - flags |= __GFP_DMA;
> > > > + flags |= __GFP_DMA | __GFP_DMA32;
> > >
> > > Given the definition of GFP_ZONE_BAD, I'm not sure this combination
> > > of flags is strictly valid, but rather is implicitly reliant on only
> > > one of those zones ever actually existing. As such, it seems liable
> > > to blow up if the plans to add ZONE_DMA to arm64[1] go ahead.
> >
> > How about this, or do you have any suggestions?
> > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > d33b77e9add3..f61c29a4430f 100644
> > --- a/arch/arm/xen/mm.c
> > +++ b/arch/arm/xen/mm.c
> > @@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > int order)
> >
> > for_each_memblock(memory, reg) {
> > if (reg->base < (phys_addr_t)0xffffffff) {
> > +#ifdef CONFIG_ARM64
> > + flags |= __GFP_DMA32; #else
> > flags |= __GFP_DMA;
> > +#endif
> > break;
> > }
> > }
>
> Yes I think this is the way to go, but we are trying not to add any #ifdef
> CONFIG_ARM64 under arch/arm. Maybe you could introduce a static inline
> function to set GFP_DMA:
>
> static inline void xen_set_gfp_dma(gfp_t *flags)
>
> it could be implemented under arch/arm/include/asm/xen/page.h for arm
> and under arch/arm64/include/asm/xen/page.h for arm64 using __GFP_DMA
> for the former and __GFP_DMA32 for the latter.
Thanks for your suggestion. I'll use this in V2.
Thanks,
Peng.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: arm/arm64: vgic: Allow more than 256 vcpus for KVM_IRQ_LINE
From: Zenghui Yu @ 2019-08-29 2:46 UTC (permalink / raw)
To: Marc Zyngier, Peter Maydell, James Morse, Julien Thierry,
Suzuki K Poulose
Cc: Eric Auger, qemu-arm, kvmarm, linux-arm-kernel, kvm
In-Reply-To: <20190818140710.23920-1-maz@kernel.org>
Hi Marc,
On 2019/8/18 22:07, Marc Zyngier wrote:
> While parts of the VGIC support a large number of vcpus (we
> bravely allow up to 512), other parts are more limited.
>
> One of these limits is visible in the KVM_IRQ_LINE ioctl, which
> only allows 256 vcpus to be signalled when using the CPU or PPI
> types. Unfortunately, we've cornered ourselves badly by allocating
> all the bits in the irq field.
>
> Since the irq_type subfield (8 bit wide) is currently only taking
> the values 0, 1 and 2 (and we have been careful not to allow anything
> else), let's reduce this field to only 4 bits, and allocate the
> remaining 4 bits to a vcpu2_index, which acts as a multiplier:
>
> vcpu_id = 256 * vcpu2_index + vcpu_index
>
> With that, and a new capability (KVM_CAP_ARM_IRQ_LINE_LAYOUT_2)
> allowing this to be discovered, it becomes possible to inject
> PPIs to up to 4096 vcpus. But please just don't.
>
> Reported-by: Zenghui Yu <yuzenghui@huawei.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
And tested together with Eric's patches (KVM+QEMU).
Thanks,
zenghui
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [arm:for-next 13/25] include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
From: kbuild test robot @ 2019-08-29 0:49 UTC (permalink / raw)
To: Leo Yan; +Cc: Russell King, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
head: d0d54dc04e37be14a9e51d9a2e431f302948e99d
commit: 566c290c6498b2fdc04a54556c4e8747f0298c7b [13/25] ARM: 8899/1: arm/arm64: Add support for function error injection
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 566c290c6498b2fdc04a54556c4e8747f0298c7b
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from include/linux/module.h:22:0,
from drivers/pps/pps.c:11:
>> include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
#include <asm/error-injection.h>
^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +7 include/linux/error-injection.h
540adea3809f61 Masami Hiramatsu 2018-01-13 6
540adea3809f61 Masami Hiramatsu 2018-01-13 @7 #include <asm/error-injection.h>
540adea3809f61 Masami Hiramatsu 2018-01-13 8
:::::: The code at line 7 was first introduced by commit
:::::: 540adea3809f61115d2a1ea4ed6e627613452ba1 error-injection: Separate error-injection from kprobe
:::::: TO: Masami Hiramatsu <mhiramat@kernel.org>
:::::: CC: Alexei Starovoitov <ast@kernel.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 71416 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] sched/rt: avoid contend with CFS task
From: Jing-Ting Wu @ 2019-08-29 3:15 UTC (permalink / raw)
To: Peter Zijlstra, Matthias Brugger
Cc: linux-arm-kernel, Jing-Ting Wu, linux-mediatek, linux-kernel,
wsd_upstream
At original linux design, RT & CFS scheduler are independent.
Current RT task placement policy will select the first cpu in
lowest_mask, even if the first CPU is running a CFS task.
This may put RT task to a running cpu and let CFS task runnable.
So we select idle cpu in lowest_mask first to avoid preempting
CFS task.
Signed-off-by: Jing-Ting Wu <jing-ting.wu@mediatek.com>
---
kernel/sched/rt.c | 42 +++++++++++++++++-------------------------
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index a532558..626ca27 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1388,7 +1388,6 @@ static void yield_task_rt(struct rq *rq)
static int
select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags)
{
- struct task_struct *curr;
struct rq *rq;
/* For anything but wake ups, just return the task_cpu */
@@ -1398,33 +1397,15 @@ static void yield_task_rt(struct rq *rq)
rq = cpu_rq(cpu);
rcu_read_lock();
- curr = READ_ONCE(rq->curr); /* unlocked access */
/*
- * If the current task on @p's runqueue is an RT task, then
- * try to see if we can wake this RT task up on another
- * runqueue. Otherwise simply start this RT task
- * on its current runqueue.
- *
- * We want to avoid overloading runqueues. If the woken
- * task is a higher priority, then it will stay on this CPU
- * and the lower prio task should be moved to another CPU.
- * Even though this will probably make the lower prio task
- * lose its cache, we do not want to bounce a higher task
- * around just because it gave up its CPU, perhaps for a
- * lock?
- *
- * For equal prio tasks, we just let the scheduler sort it out.
- *
- * Otherwise, just let it ride on the affined RQ and the
- * post-schedule router will push the preempted task away
- *
- * This test is optimistic, if we get it wrong the load-balancer
- * will have to sort it out.
+ * If the task p is allowed to put more than one CPU or
+ * it is not allowed to put on this CPU.
+ * Let p use find_lowest_rq to choose other idle CPU first,
+ * instead of choose this cpu and preempt curr cfs task.
*/
- if (curr && unlikely(rt_task(curr)) &&
- (curr->nr_cpus_allowed < 2 ||
- curr->prio <= p->prio)) {
+ if ((p->nr_cpus_allowed > 1) ||
+ (!cpumask_test_cpu(cpu, p->cpus_ptr))) {
int target = find_lowest_rq(p);
/*
@@ -1648,6 +1629,7 @@ static int find_lowest_rq(struct task_struct *task)
struct cpumask *lowest_mask = this_cpu_cpumask_var_ptr(local_cpu_mask);
int this_cpu = smp_processor_id();
int cpu = task_cpu(task);
+ int i;
/* Make sure the mask is initialized first */
if (unlikely(!lowest_mask))
@@ -1659,6 +1641,16 @@ static int find_lowest_rq(struct task_struct *task)
if (!cpupri_find(&task_rq(task)->rd->cpupri, task, lowest_mask))
return -1; /* No targets found */
+ /* Choose previous cpu if it is idle and it fits lowest_mask */
+ if (cpumask_test_cpu(cpu, lowest_mask) && idle_cpu(cpu))
+ return cpu;
+
+ /* Choose idle_cpu among lowest_mask */
+ for_each_cpu(i, lowest_mask) {
+ if (idle_cpu(i))
+ return i;
+ }
+
/*
* At this point we have built a mask of CPUs representing the
* lowest priority tasks in the system. Now we want to elect
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH netdev] net: stmmac: dwmac-rk: Don't fail if phy regulator is absent
From: Chen-Yu Tsai @ 2019-08-29 3:17 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, David S. Miller,
Heiko Stuebner
Cc: linux-rockchip, Chen-Yu Tsai, linux-kernel, linux-arm-kernel,
netdev
From: Chen-Yu Tsai <wens@csie.org>
The devicetree binding lists the phy phy as optional. As such, the
driver should not bail out if it can't find a regulator. Instead it
should just skip the remaining regulator related code and continue
on normally.
Skip the remainder of phy_power_on() if a regulator supply isn't
available. This also gets rid of the bogus return code.
Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
On a separate note, maybe we should add this file to the Rockchip
entry in MAINTAINERS?
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 4644b2aeeba1..e2e469c37a4d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1194,10 +1194,8 @@ static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
int ret;
struct device *dev = &bsp_priv->pdev->dev;
- if (!ldo) {
- dev_err(dev, "no regulator found\n");
- return -1;
- }
+ if (!ldo)
+ return 0;
if (enable) {
ret = regulator_enable(ldo);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v2 0/7] soc: renesas: rcar-gen3-sysc: Fix power request conflicts
From: Yoshihiro Shimoda @ 2019-08-29 4:14 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm
Cc: linux-renesas-soc@vger.kernel.org, Simon Horman,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, August 28, 2019 8:36 PM
>
> Hi all,
>
> Recent R-Car Gen3 SoCs added an External Request Mask Register to the
> System Controller (SYSC). This register allows to mask external power
> requests for CPU or 3DG domains, to prevent conflicts between powering
> off CPU cores or the 3D Graphics Engine, and changing the state of
> another power domain through SYSC, which could lead to CPG state machine
> lock-ups.
>
> This patch series starts making use of this register. Note that the
> register is optional, and that its location and contents are
> SoC-specific.
>
> This was inspired by a patch in the BSP by Dien Pham
> <dien.pham.ry@renesas.com>.
>
> Note that the issue fixed cannot happen in the upstream kernel, as
> upstream has no support for graphics acceleration yet. SoCs lacking the
> External Request Mask Register may need a different mitigation in the
> future.
>
> Changes compared to v1[1]:
> - Improve description of cover letter and first patch.
>
> Changes compared to RFC[2]:
> - Rebased.
>
> This has been boot-tested on R-Car H3 ES1.0, H3 ES2.0, M3-W ES1.0, M3-N,
> V3M, and E3 (only the last 3 have this register!), and regression-tested
> on R-Car Gen2.
>
> This has not been tested on R-Car H3 ES3.0, M3-W ES2.0, and V3H.
I also boot-tested on R-Car H3 ES3.0 and M3-W ES3.0.
And I reviewed all patches, so:
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Best regards,
Yoshihiro Shimoda
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] [RFC] i2c: imx: make use of format specifier %dE
From: Uwe Kleine-König @ 2019-08-29 4:29 UTC (permalink / raw)
To: Wolfram Sang, Oleksij Rempel
Cc: Jani Nikula, Petr Mladek, Sergey Senozhatsky, Jonathan Corbet,
Shawn Guo, linux-doc, linux-kernel, Steven Rostedt,
Enrico Weigelt, NXP Linux Team, kernel, Andrew Morton,
Fabio Estevam, linux-arm-kernel, linux-i2c
I created a patch that teaches printk et al to emit a symbolic error
name for an error valued integer[1]. With that applied
dev_err(&pdev->dev, "can't enable I2C clock, ret=%dE\n", ret);
emits
... can't enable I2C clock, ret=EIO
if ret is -EIO. Petr Mladek (i.e. one of the printk maintainers) had
concerns if this would be well received and worth the effort. He asked
to present it to a few subsystems. So for now, this patch converting the
i2c-imx driver shouldn't be applied yet but it would be great to get
some feedback about if you think that being able to easily printk (for
example) "EIO" instead of "-5" is a good idea. Would it help you? Do you
think it helps your users?
Thanks
Uwe
[1] https://lkml.org/lkml/2019/8/27/1456
---
drivers/i2c/busses/i2c-imx.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 15f6cde6452f..359e911cb891 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -289,7 +289,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
if (IS_ERR(dma->chan_tx)) {
ret = PTR_ERR(dma->chan_tx);
if (ret != -ENODEV && ret != -EPROBE_DEFER)
- dev_err(dev, "can't request DMA tx channel (%d)\n", ret);
+ dev_err(dev, "can't request DMA tx channel (%dE)\n", ret);
goto fail_al;
}
@@ -300,7 +300,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
dma_sconfig.direction = DMA_MEM_TO_DEV;
ret = dmaengine_slave_config(dma->chan_tx, &dma_sconfig);
if (ret < 0) {
- dev_err(dev, "can't configure tx channel (%d)\n", ret);
+ dev_err(dev, "can't configure tx channel (%dE)\n", ret);
goto fail_tx;
}
@@ -308,7 +308,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
if (IS_ERR(dma->chan_rx)) {
ret = PTR_ERR(dma->chan_rx);
if (ret != -ENODEV && ret != -EPROBE_DEFER)
- dev_err(dev, "can't request DMA rx channel (%d)\n", ret);
+ dev_err(dev, "can't request DMA rx channel (%dE)\n", ret);
goto fail_tx;
}
@@ -319,7 +319,7 @@ static void i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
dma_sconfig.direction = DMA_DEV_TO_MEM;
ret = dmaengine_slave_config(dma->chan_rx, &dma_sconfig);
if (ret < 0) {
- dev_err(dev, "can't configure rx channel (%d)\n", ret);
+ dev_err(dev, "can't configure rx channel (%dE)\n", ret);
goto fail_rx;
}
@@ -964,7 +964,7 @@ static int i2c_imx_xfer(struct i2c_adapter *adapter,
pm_runtime_put_autosuspend(i2c_imx->adapter.dev.parent);
out:
- dev_dbg(&i2c_imx->adapter.dev, "<%s> exit with: %s: %d\n", __func__,
+ dev_dbg(&i2c_imx->adapter.dev, "<%s> exit with: %s: %dE\n", __func__,
(result < 0) ? "error" : "success msg",
(result < 0) ? result : num);
return (result < 0) ? result : num;
@@ -1100,7 +1100,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
ret = clk_prepare_enable(i2c_imx->clk);
if (ret) {
- dev_err(&pdev->dev, "can't enable I2C clock, ret=%d\n", ret);
+ dev_err(&pdev->dev, "can't enable I2C clock, ret=%dE\n", ret);
return ret;
}
@@ -1108,7 +1108,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, irq, i2c_imx_isr, IRQF_SHARED,
pdev->name, i2c_imx);
if (ret) {
- dev_err(&pdev->dev, "can't claim irq %d\n", irq);
+ dev_err(&pdev->dev, "can't claim irq %dE\n", irq);
goto clk_disable;
}
@@ -1230,7 +1230,7 @@ static int __maybe_unused i2c_imx_runtime_resume(struct device *dev)
ret = clk_enable(i2c_imx->clk);
if (ret)
- dev_err(dev, "can't enable I2C clock, ret=%d\n", ret);
+ dev_err(dev, "can't enable I2C clock, ret=%dE\n", ret);
return ret;
}
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] drm: dw-hdmi-i2s: enable audio clock in audio_startup
From: Cheng-Yi Chiang @ 2019-08-29 4:29 UTC (permalink / raw)
To: linux-kernel
Cc: alsa-devel, tzungbi, zhengxing, kuninori.morimoto.gx, a.hajda,
airlied, jeffy.chen, dianders, dri-devel, cain.cai,
linux-rockchip, eddie.cai, Laurent.pinchart, daniel,
enric.balletbo, dgreid, sam, linux-arm-kernel, cychiang
In the designware databook, the sequence of enabling audio clock and
setting format is not clearly specified.
Currently, audio clock is enabled in the end of hw_param ops after
setting format.
On some monitors, there is a possibility that audio does not come out.
Fix this by enabling audio clock in audio_startup ops
before hw_param ops setting format.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 5cbb71a866d5..08b4adbb1ddc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -69,6 +69,14 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
hdmi_write(audio, conf0, HDMI_AUD_CONF0);
hdmi_write(audio, conf1, HDMI_AUD_CONF1);
+ return 0;
+}
+
+static int dw_hdmi_i2s_audio_startup(struct device *dev, void *data)
+{
+ struct dw_hdmi_i2s_audio_data *audio = data;
+ struct dw_hdmi *hdmi = audio->hdmi;
+
dw_hdmi_audio_enable(hdmi);
return 0;
@@ -105,6 +113,7 @@ static int dw_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
}
static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
+ .audio_startup = dw_hdmi_i2s_audio_startup,
.hw_params = dw_hdmi_i2s_hw_params,
.audio_shutdown = dw_hdmi_i2s_audio_shutdown,
.get_dai_id = dw_hdmi_i2s_get_dai_id,
--
2.23.0.187.g17f5b7556c-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] [RFC] tty/serial: imx: make use of format specifier %dE
From: Uwe Kleine-König @ 2019-08-29 4:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: Jani Nikula, Petr Mladek, linux-serial, Jonathan Corbet,
Shawn Guo, linux-doc, linux-kernel, Steven Rostedt,
Enrico Weigelt, NXP Linux Team, kernel, Andrew Morton,
Fabio Estevam, linux-arm-kernel, Sergey Senozhatsky
I created a patch that teaches printk et al to emit a symbolic error
name for an error valued integer[1]. With that applied
dev_err(&pdev->dev, "failed to get ipg clk: %dE\n", ret);
emits
... failed to get ipg clk: EPROBE_DEFER
if ret is -EPROBE_DEFER. Petr Mladek (i.e. one of the printk
maintainers) had concerns if this would be well received and worth the
effort. He asked to present it to a few subsystems. So for now, this
patch converting the imx UART driver shouldn't be applied yet but it
would be great to get some feedback about if you think that being able
to easily printk (for example) "EIO" instead of "-5" is a good idea.
Would it help you? Do you think it helps your users?
Thanks
Uwe
[1] https://lkml.org/lkml/2019/8/27/1456
---
drivers/tty/serial/imx.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 57d6e6ba556e..a3dbb9378e8b 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2143,7 +2143,7 @@ static int imx_uart_probe_dt(struct imx_port *sport,
ret = of_alias_get_id(np, "serial");
if (ret < 0) {
- dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
+ dev_err(&pdev->dev, "failed to get alias id, error %dE\n", ret);
return ret;
}
sport->port.line = ret;
@@ -2236,14 +2236,14 @@ static int imx_uart_probe(struct platform_device *pdev)
sport->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
if (IS_ERR(sport->clk_ipg)) {
ret = PTR_ERR(sport->clk_ipg);
- dev_err(&pdev->dev, "failed to get ipg clk: %d\n", ret);
+ dev_err(&pdev->dev, "failed to get ipg clk: %dE\n", ret);
return ret;
}
sport->clk_per = devm_clk_get(&pdev->dev, "per");
if (IS_ERR(sport->clk_per)) {
ret = PTR_ERR(sport->clk_per);
- dev_err(&pdev->dev, "failed to get per clk: %d\n", ret);
+ dev_err(&pdev->dev, "failed to get per clk: %dE\n", ret);
return ret;
}
@@ -2252,7 +2252,7 @@ static int imx_uart_probe(struct platform_device *pdev)
/* For register access, we only need to enable the ipg clock. */
ret = clk_prepare_enable(sport->clk_ipg);
if (ret) {
- dev_err(&pdev->dev, "failed to enable per clk: %d\n", ret);
+ dev_err(&pdev->dev, "failed to enable per clk: %dE\n", ret);
return ret;
}
@@ -2330,7 +2330,7 @@ static int imx_uart_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_rxint, 0,
dev_name(&pdev->dev), sport);
if (ret) {
- dev_err(&pdev->dev, "failed to request rx irq: %d\n",
+ dev_err(&pdev->dev, "failed to request rx irq: %dE\n",
ret);
return ret;
}
@@ -2338,7 +2338,7 @@ static int imx_uart_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, txirq, imx_uart_txint, 0,
dev_name(&pdev->dev), sport);
if (ret) {
- dev_err(&pdev->dev, "failed to request tx irq: %d\n",
+ dev_err(&pdev->dev, "failed to request tx irq: %dE\n",
ret);
return ret;
}
@@ -2346,7 +2346,7 @@ static int imx_uart_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
dev_name(&pdev->dev), sport);
if (ret) {
- dev_err(&pdev->dev, "failed to request rts irq: %d\n",
+ dev_err(&pdev->dev, "failed to request rts irq: %dE\n",
ret);
return ret;
}
@@ -2354,7 +2354,7 @@ static int imx_uart_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
dev_name(&pdev->dev), sport);
if (ret) {
- dev_err(&pdev->dev, "failed to request irq: %d\n", ret);
+ dev_err(&pdev->dev, "failed to request irq: %dE\n", ret);
return ret;
}
}
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] Add fixes to iProc GPIO driver
From: Srinath Mannam @ 2019-08-29 4:52 UTC (permalink / raw)
To: Linus Walleij, Ray Jui, Scott Branden
Cc: Srinath Mannam, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel
This patch series adds the following fixes to the iProc GPIO driver
- Fix Warning message given for shared irqchip data structure
- Fix pinconfig of pull-up/down and drive strength for AON/CRMU GPIOs
This patch set is based on Linux-5.2-rc4.
Changes from v1:
- Add Fixes tags in both patches
Li Jin (1):
gpio: iproc-gpio: Fix incorrect pinconf configurations
Rayagonda Kokatanur (1):
gpio: iproc-gpio: Handle interrupts for multiple instances
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 117 +++++++++++++++++++++++--------
1 file changed, 88 insertions(+), 29 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] gpio: iproc-gpio: Fix incorrect pinconf configurations
From: Srinath Mannam @ 2019-08-29 4:52 UTC (permalink / raw)
To: Linus Walleij, Ray Jui, Scott Branden
Cc: Li Jin, bcm-kernel-feedback-list, linux-kernel, linux-arm-kernel
In-Reply-To: <1567054348-19685-1-git-send-email-srinath.mannam@broadcom.com>
From: Li Jin <li.jin@broadcom.com>
Fix drive strength for AON/CRMU controller; fix pull-up/down setting
for CCM/CDRU controller.
Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
Signed-off-by: Li Jin <li.jin@broadcom.com>
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 96 +++++++++++++++++++++++++-------
1 file changed, 77 insertions(+), 19 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index b70058c..20b9864 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -54,8 +54,12 @@
/* drive strength control for ASIU GPIO */
#define IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
-/* drive strength control for CCM/CRMU (AON) GPIO */
-#define IPROC_GPIO_DRV0_CTRL_OFFSET 0x00
+/* pinconf for CCM GPIO */
+#define IPROC_GPIO_PULL_DN_OFFSET 0x10
+#define IPROC_GPIO_PULL_UP_OFFSET 0x14
+
+/* pinconf for CRMU(aon) GPIO and CCM GPIO*/
+#define IPROC_GPIO_DRV_CTRL_OFFSET 0x00
#define GPIO_BANK_SIZE 0x200
#define NGPIOS_PER_BANK 32
@@ -76,6 +80,12 @@ enum iproc_pinconf_param {
IPROC_PINCON_MAX,
};
+enum iproc_pinconf_ctrl_type {
+ IOCTRL_TYPE_AON = 1,
+ IOCTRL_TYPE_CDRU,
+ IOCTRL_TYPE_INVALID,
+};
+
/*
* Iproc GPIO core
*
@@ -100,6 +110,7 @@ struct iproc_gpio {
void __iomem *base;
void __iomem *io_ctrl;
+ enum iproc_pinconf_ctrl_type io_ctrl_type;
raw_spinlock_t lock;
@@ -461,20 +472,44 @@ static const struct pinctrl_ops iproc_pctrl_ops = {
static int iproc_gpio_set_pull(struct iproc_gpio *chip, unsigned gpio,
bool disable, bool pull_up)
{
+ void __iomem *base;
unsigned long flags;
+ unsigned int shift;
+ u32 val_1, val_2;
raw_spin_lock_irqsave(&chip->lock, flags);
-
- if (disable) {
- iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio, false);
+ if (chip->io_ctrl_type == IOCTRL_TYPE_CDRU) {
+ base = chip->io_ctrl;
+ shift = IPROC_GPIO_SHIFT(gpio);
+
+ val_1 = readl(base + IPROC_GPIO_PULL_UP_OFFSET);
+ val_2 = readl(base + IPROC_GPIO_PULL_DN_OFFSET);
+ if (disable) {
+ /* no pull-up or pull-down */
+ val_1 &= ~BIT(shift);
+ val_2 &= ~BIT(shift);
+ } else if (pull_up) {
+ val_1 |= BIT(shift);
+ val_2 &= ~BIT(shift);
+ } else {
+ val_1 &= ~BIT(shift);
+ val_2 |= BIT(shift);
+ }
+ writel(val_1, base + IPROC_GPIO_PULL_UP_OFFSET);
+ writel(val_2, base + IPROC_GPIO_PULL_DN_OFFSET);
} else {
- iproc_set_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio,
- pull_up);
- iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio, true);
+ if (disable) {
+ iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio,
+ false);
+ } else {
+ iproc_set_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio,
+ pull_up);
+ iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio,
+ true);
+ }
}
raw_spin_unlock_irqrestore(&chip->lock, flags);
-
dev_dbg(chip->dev, "gpio:%u set pullup:%d\n", gpio, pull_up);
return 0;
@@ -483,14 +518,35 @@ static int iproc_gpio_set_pull(struct iproc_gpio *chip, unsigned gpio,
static void iproc_gpio_get_pull(struct iproc_gpio *chip, unsigned gpio,
bool *disable, bool *pull_up)
{
+ void __iomem *base;
unsigned long flags;
+ unsigned int shift;
+ u32 val_1, val_2;
raw_spin_lock_irqsave(&chip->lock, flags);
- *disable = !iproc_get_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio);
- *pull_up = iproc_get_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio);
+ if (chip->io_ctrl_type == IOCTRL_TYPE_CDRU) {
+ base = chip->io_ctrl;
+ shift = IPROC_GPIO_SHIFT(gpio);
+
+ val_1 = readl(base + IPROC_GPIO_PULL_UP_OFFSET) & BIT(shift);
+ val_2 = readl(base + IPROC_GPIO_PULL_DN_OFFSET) & BIT(shift);
+
+ *pull_up = val_1 ? true : false;
+ *disable = (val_1 | val_2) ? false : true;
+
+ } else {
+ *disable = !iproc_get_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio);
+ *pull_up = iproc_get_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio);
+ }
raw_spin_unlock_irqrestore(&chip->lock, flags);
}
+#define DRV_STRENGTH_OFFSET(gpio, bit, type) ((type) == IOCTRL_TYPE_AON ? \
+ ((2 - (bit)) * 4 + IPROC_GPIO_DRV_CTRL_OFFSET) : \
+ ((type) == IOCTRL_TYPE_CDRU) ? \
+ ((bit) * 4 + IPROC_GPIO_DRV_CTRL_OFFSET) : \
+ ((bit) * 4 + IPROC_GPIO_REG(gpio, IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET)))
+
static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
unsigned strength)
{
@@ -505,11 +561,8 @@ static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
if (chip->io_ctrl) {
base = chip->io_ctrl;
- offset = IPROC_GPIO_DRV0_CTRL_OFFSET;
} else {
base = chip->base;
- offset = IPROC_GPIO_REG(gpio,
- IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET);
}
shift = IPROC_GPIO_SHIFT(gpio);
@@ -520,11 +573,11 @@ static int iproc_gpio_set_strength(struct iproc_gpio *chip, unsigned gpio,
raw_spin_lock_irqsave(&chip->lock, flags);
strength = (strength / 2) - 1;
for (i = 0; i < GPIO_DRV_STRENGTH_BITS; i++) {
+ offset = DRV_STRENGTH_OFFSET(gpio, i, chip->io_ctrl_type);
val = readl(base + offset);
val &= ~BIT(shift);
val |= ((strength >> i) & 0x1) << shift;
writel(val, base + offset);
- offset += 4;
}
raw_spin_unlock_irqrestore(&chip->lock, flags);
@@ -541,11 +594,8 @@ static int iproc_gpio_get_strength(struct iproc_gpio *chip, unsigned gpio,
if (chip->io_ctrl) {
base = chip->io_ctrl;
- offset = IPROC_GPIO_DRV0_CTRL_OFFSET;
} else {
base = chip->base;
- offset = IPROC_GPIO_REG(gpio,
- IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET);
}
shift = IPROC_GPIO_SHIFT(gpio);
@@ -553,10 +603,10 @@ static int iproc_gpio_get_strength(struct iproc_gpio *chip, unsigned gpio,
raw_spin_lock_irqsave(&chip->lock, flags);
*strength = 0;
for (i = 0; i < GPIO_DRV_STRENGTH_BITS; i++) {
+ offset = DRV_STRENGTH_OFFSET(gpio, i, chip->io_ctrl_type);
val = readl(base + offset) & BIT(shift);
val >>= shift;
*strength += (val << i);
- offset += 4;
}
/* convert to mA */
@@ -734,6 +784,7 @@ static int iproc_gpio_probe(struct platform_device *pdev)
u32 ngpios, pinconf_disable_mask = 0;
int irq, ret;
bool no_pinconf = false;
+ enum iproc_pinconf_ctrl_type io_ctrl_type = IOCTRL_TYPE_INVALID;
/* NSP does not support drive strength config */
if (of_device_is_compatible(dev->of_node, "brcm,iproc-nsp-gpio"))
@@ -764,8 +815,15 @@ static int iproc_gpio_probe(struct platform_device *pdev)
dev_err(dev, "unable to map I/O memory\n");
return PTR_ERR(chip->io_ctrl);
}
+ if (of_device_is_compatible(dev->of_node,
+ "brcm,cygnus-ccm-gpio"))
+ io_ctrl_type = IOCTRL_TYPE_CDRU;
+ else
+ io_ctrl_type = IOCTRL_TYPE_AON;
}
+ chip->io_ctrl_type = io_ctrl_type;
+
if (of_property_read_u32(dev->of_node, "ngpios", &ngpios)) {
dev_err(&pdev->dev, "missing ngpios DT property\n");
return -ENODEV;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] gpio: iproc-gpio: Handle interrupts for multiple instances
From: Srinath Mannam @ 2019-08-29 4:52 UTC (permalink / raw)
To: Linus Walleij, Ray Jui, Scott Branden
Cc: Rayagonda Kokatanur, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel
In-Reply-To: <1567054348-19685-1-git-send-email-srinath.mannam@broadcom.com>
From: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
When multiple instance of iproc-gpio chips are present, a fix up
message[1] is printed during the probe of second and later instances.
This issue is because driver sharing same irq_chip data structure
among multiple instances of driver.
Fix this by allocating irq_chip data structure per instance of
iproc-gpio.
[1] fix up message addressed by this patch
[ 7.862208] gpio gpiochip2: (689d0000.gpio): detected irqchip that
is shared with multiple gpiochips: please fix the driver.
Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index 20b9864..8729f47 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -114,6 +114,7 @@ struct iproc_gpio {
raw_spinlock_t lock;
+ struct irq_chip irqchip;
struct gpio_chip gc;
unsigned num_banks;
@@ -302,14 +303,6 @@ static int iproc_gpio_irq_set_type(struct irq_data *d, unsigned int type)
return 0;
}
-static struct irq_chip iproc_gpio_irq_chip = {
- .name = "bcm-iproc-gpio",
- .irq_ack = iproc_gpio_irq_ack,
- .irq_mask = iproc_gpio_irq_mask,
- .irq_unmask = iproc_gpio_irq_unmask,
- .irq_set_type = iproc_gpio_irq_set_type,
-};
-
/*
* Request the Iproc IOMUX pinmux controller to mux individual pins to GPIO
*/
@@ -875,14 +868,22 @@ static int iproc_gpio_probe(struct platform_device *pdev)
/* optional GPIO interrupt support */
irq = platform_get_irq(pdev, 0);
if (irq) {
- ret = gpiochip_irqchip_add(gc, &iproc_gpio_irq_chip, 0,
+ chip->irqchip.name = "bcm-iproc-gpio";
+ chip->irqchip.irq_ack = iproc_gpio_irq_ack;
+ chip->irqchip.irq_mask = iproc_gpio_irq_mask;
+ chip->irqchip.irq_unmask = iproc_gpio_irq_unmask;
+ chip->irqchip.irq_set_type = iproc_gpio_irq_set_type;
+ chip->irqchip.irq_enable = iproc_gpio_irq_unmask;
+ chip->irqchip.irq_disable = iproc_gpio_irq_mask;
+
+ ret = gpiochip_irqchip_add(gc, &chip->irqchip, 0,
handle_simple_irq, IRQ_TYPE_NONE);
if (ret) {
dev_err(dev, "no GPIO irqchip\n");
goto err_rm_gpiochip;
}
- gpiochip_set_chained_irqchip(gc, &iproc_gpio_irq_chip, irq,
+ gpiochip_set_chained_irqchip(gc, &chip->irqchip, irq,
iproc_gpio_irq_handler);
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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