* [PATCH v15 1/4] soc: mediatek: cmdq: define the instruction struct
From: Bibby Hsieh @ 2019-09-27 11:42 UTC (permalink / raw)
To: 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: <20190927114254.6258-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 | 106 +++++++++++++++++------
include/linux/mailbox/mtk-cmdq-mailbox.h | 10 +++
2 files changed, 90 insertions(+), 26 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 7aa0517ff2f3..7af327b98d25 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,42 @@ 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 = kzalloc(sizeof(*inst), GFP_KERNEL);
+ int err = 0;
+
+ 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);
+ err = cmdq_pkt_append_command(pkt, inst);
+ kfree(inst);
+
+ return err;
}
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 = kzalloc(sizeof(*inst), GFP_KERNEL);
+ u16 offset_mask = offset;
int err = 0;
+ if (!inst)
+ return -ENOMEM;
+
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);
+ kfree(inst);
return err;
}
@@ -163,43 +194,66 @@ EXPORT_SYMBOL(cmdq_pkt_write_mask);
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
- u32 arg_b;
+ struct cmdq_instruction *inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+ int err = 0;
+
+ if (!inst)
+ return -ENOMEM;
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);
+ err = cmdq_pkt_append_command(pkt, inst);
+ kfree(inst);
+
+ return err;
}
EXPORT_SYMBOL(cmdq_pkt_wfe);
int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
{
+ struct cmdq_instruction *inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+ int err = 0;
+
+ if (!inst)
+ return -ENOMEM;
+
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;
+
+ err = cmdq_pkt_append_command(pkt, inst);
+ kfree(inst);
+
+ return err;
}
EXPORT_SYMBOL(cmdq_pkt_clear_event);
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
- int err;
+ struct cmdq_instruction *inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+ int err = 0;
+
+ 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;
+ 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);
+ kfree(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
* [PATCH v15 4/4] arm64: dts: add gce node for mt8183
From: Bibby Hsieh @ 2019-09-27 11:42 UTC (permalink / raw)
To: 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: <20190927114254.6258-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 v15 2/4] soc: mediatek: cmdq: add polling function
From: Bibby Hsieh @ 2019-09-27 11:42 UTC (permalink / raw)
To: 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: <20190927114254.6258-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 | 41 ++++++++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h | 32 ++++++++++++++++++
3 files changed, 74 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 7af327b98d25..8b301f01ff4b 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -236,6 +236,47 @@ 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 = kzalloc(sizeof(*inst), GFP_KERNEL);
+ int err = 0;
+
+ if (!inst)
+ return -ENOMEM;
+
+ inst->op = CMDQ_CODE_POLL;
+ inst->value = value;
+ inst->offset = offset;
+ inst->subsys = subsys;
+
+ err = cmdq_pkt_append_command(pkt, inst);
+ kfree(inst);
+
+ return err;
+}
+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 = kzalloc(sizeof(*inst), GFP_KERNEL);
+ int err = 0;
+
+ if (!inst)
+ return -ENOMEM;
+
+ 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);
+ kfree(inst);
+
+ return err;
+}
+EXPORT_SYMBOL(cmdq_pkt_poll_mask);
+
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction *inst = kzalloc(sizeof(*inst), GFP_KERNEL);
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 v15 0/4] support gce on mt8183 platform
From: Bibby Hsieh @ 2019-09-27 11:42 UTC (permalink / raw)
To: 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
Changes since v14:
- change input argument as pointer in append_commend()
Changes since v13:
- separate poll function as poll w/ & w/o mask function
- directly pass inst into append_command function instead
of returns a pointer
- fixup coding style
- rebase onto 5.3-rc1
[... snip ...]
Bibby Hsieh (4):
soc: mediatek: cmdq: define the instruction struct
soc: mediatek: cmdq: add polling function
soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
arm64: dts: add gce node for mt8183
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 ++
drivers/soc/mediatek/mtk-cmdq-helper.c | 176 +++++++++++++++++++----
include/linux/mailbox/mtk-cmdq-mailbox.h | 11 ++
include/linux/soc/mediatek/mtk-cmdq.h | 53 +++++++
4 files changed, 224 insertions(+), 26 deletions(-)
--
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
* [PATCH v15 3/4] soc: mediatek: cmdq: add cmdq_dev_get_client_reg function
From: Bibby Hsieh @ 2019-09-27 11:42 UTC (permalink / raw)
To: 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: <20190927114254.6258-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 8b301f01ff4b..301b50934510 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
* Re: [v2, 2/2] gpio: dts: aspeed: Add SGPIO driver
From: Linus Walleij @ 2019-09-27 11:50 UTC (permalink / raw)
To: Hongwei Zhang
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Arnd Bergmann, linux-aspeed, Bartosz Golaszewski, Andrew Jeffery,
linux-kernel@vger.kernel.org, Ard Biesheuvel, Russell King,
Mike Rapoport, open list:GPIO SUBSYSTEM, Rob Herring,
Joel Stanley, Benjamin Gaignard, Mauro Carvalho Chehab,
Doug Anderson, Andrew Morton, Linux ARM, Masahiro Yamada
In-Reply-To: <1569439337-10482-3-git-send-email-hongweiz@ami.com>
On Wed, Sep 25, 2019 at 9:22 PM Hongwei Zhang <hongweiz@ami.com> wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
I sent a separate patch to fix this up the way I want it with the file
named gpio-aspeed-sgpio.c and CONFIG_GPIO_ASPEED_SGPIO.
I don't want to mix up the namespaces of something Aspeed-generic
with the namespace of the GPIO subsystem. SGPIO is the name
of a specific Aspeed component.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: chapoly acceleration hardware [Was: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API]
From: Pascal Van Leeuwen @ 2019-09-27 12:18 UTC (permalink / raw)
To: Dave Taht
Cc: Jason A. Donenfeld, Toke Høiland-Jørgensen,
Catalin Marinas, Herbert Xu, Arnd Bergmann, Ard Biesheuvel,
Greg KH, Eric Biggers, Willy Tarreau, Samuel Neves, Will Deacon,
Netdev, Linux Crypto Mailing List, Andy Lutomirski, Marc Zyngier,
Dan Carpenter, Linus Torvalds, David Miller, linux-arm-kernel
In-Reply-To: <CAA93jw5__kXT-WAPBjseZP1kkkftH5nfVOiFA6BZrNS9sLGdoQ@mail.gmail.com>
> -----Original Message-----
> From: Dave Taht <dave.taht@gmail.com>
> Sent: Friday, September 27, 2019 1:14 AM
> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
> Cc: Jason A. Donenfeld <Jason@zx2c4.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>;
> Linux Crypto Mailing List <linux-crypto@vger.kernel.org>; linux-arm-kernel <linux-arm-
> kernel@lists.infradead.org>; Herbert Xu <herbert@gondor.apana.org.au>; David Miller
> <davem@davemloft.net>; Greg KH <gregkh@linuxfoundation.org>; Linus Torvalds
> <torvalds@linux-foundation.org>; Samuel Neves <sneves@dei.uc.pt>; Dan Carpenter
> <dan.carpenter@oracle.com>; Arnd Bergmann <arnd@arndb.de>; Eric Biggers
> <ebiggers@google.com>; Andy Lutomirski <luto@kernel.org>; Will Deacon <will@kernel.org>;
> Marc Zyngier <maz@kernel.org>; Catalin Marinas <catalin.marinas@arm.com>; Willy Tarreau
> <w@1wt.eu>; Netdev <netdev@vger.kernel.org>; Toke Høiland-Jørgensen <toke@toke.dk>
> Subject: Re: chapoly acceleration hardware [Was: Re: [RFC PATCH 00/18] crypto: wireguard
> using the existing crypto API]
>
> On Thu, Sep 26, 2019 at 6:52 AM Pascal Van Leeuwen
> <pvanleeuwen@verimatrix.com> wrote:
> >
> > > -----Original Message-----
> > > From: Jason A. Donenfeld <Jason@zx2c4.com>
> > > Sent: Thursday, September 26, 2019 1:07 PM
> > > To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
> > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Linux Crypto Mailing List <linux-
> > > crypto@vger.kernel.org>; linux-arm-kernel <linux-arm-kernel@lists.infradead.org>;
> > > Herbert Xu <herbert@gondor.apana.org.au>; David Miller <davem@davemloft.net>; Greg
> KH
> > > <gregkh@linuxfoundation.org>; Linus Torvalds <torvalds@linux-foundation.org>; Samuel
> > > Neves <sneves@dei.uc.pt>; Dan Carpenter <dan.carpenter@oracle.com>; Arnd Bergmann
> > > <arnd@arndb.de>; Eric Biggers <ebiggers@google.com>; Andy Lutomirski
> <luto@kernel.org>;
> > > Will Deacon <will@kernel.org>; Marc Zyngier <maz@kernel.org>; Catalin Marinas
> > > <catalin.marinas@arm.com>; Willy Tarreau <w@1wt.eu>; Netdev
> <netdev@vger.kernel.org>;
> > > Toke Høiland-Jørgensen <toke@toke.dk>; Dave Taht <dave.taht@gmail.com>
> > > Subject: chapoly acceleration hardware [Was: Re: [RFC PATCH 00/18] crypto: wireguard
> > > using the existing crypto API]
> > >
> > > [CC +willy, toke, dave, netdev]
> > >
> > > Hi Pascal
> > >
> > > On Thu, Sep 26, 2019 at 12:19 PM Pascal Van Leeuwen
> > > <pvanleeuwen@verimatrix.com> wrote:
> > > > Actually, that assumption is factually wrong. I don't know if anything
> > > > is *publicly* available, but I can assure you the silicon is running in
> > > > labs already. And something will be publicly available early next year
> > > > at the latest. Which could nicely coincide with having Wireguard support
> > > > in the kernel (which I would also like to see happen BTW) ...
> > > >
> > > > Not "at some point". It will. Very soon. Maybe not in consumer or server
> > > > CPUs, but definitely in the embedded (networking) space.
> > > > And it *will* be much faster than the embedded CPU next to it, so it will
> > > > be worth using it for something like bulk packet encryption.
> > >
> > > Super! I was wondering if you could speak a bit more about the
> > > interface. My biggest questions surround latency. Will it be
> > > synchronous or asynchronous?
> > >
> > The hardware being external to the CPU and running in parallel with it,
> > obviously asynchronous.
> >
> > > If the latter, why?
> > >
> > Because, as you probably already guessed, the round-trip latency is way
> > longer than the actual processing time, at least for small packets.
> >
> > Partly because the only way to communicate between the CPU and the HW
> > accelerator (whether that is crypto, a GPU, a NIC, etc.) that doesn't
> > keep the CPU busy moving data is through memory, with the HW doing DMA.
> > And, as any programmer should now, round trip times to memory are huge
> > relative to the processing speed.
> >
> > And partly because these accelerators are very similar to CPU's in
> > terms of architecture, doing pipelined processing and having multiple
> > of such pipelines in parallel. Except that these pipelines are not
> > working on low-level instructions but on full packets/blocks. So they
> > need to have many packets in flight to keep those pipelines fully
> > occupied. And packets need to move through the various pipeline stages,
> > so they incur the time needed to process them multiple times. (just
> > like e.g. a multiply instruction with a throughput of 1 per cycle
> > actually may need 4 or more cycles to actually provide its result)
> >
> > Could you do that from a synchronous interface? In theory, probably,
> > if you would spawn a new thread for every new packet arriving and
> > rely on the scheduler to preempt the waiting threads. But you'd need
> > as many threads as the HW accelerator can have packets in flight,
> > while an async would need only 2 threads: one to handle the input to
> > the accelerator and one to handle the output (or at most one thread
> > per CPU, if you want to divide the workload)
> >
> > Such a many-thread approach seems very inefficient to me.
> >
> > > What will its latencies be?
> > >
> > Depends very much on the specific integration scenario (i.e. bus
> > speed, bus hierarchy, cache hierarchy, memory speed, etc.) but on
> > the order of a few thousand CPU clocks is not unheard of.
> > Which is an eternity for the CPU, but still only a few uSec in
> > human time. Not a problem unless you're a high-frequency trader and
> > every ns counts ...
> > It's not like the CPU would process those packets in zero time.
> >
> > > How deep will its buffers be?
> > >
> > That of course depends on the specific accelerator implementation,
> > but possibly dozens of small packets in our case, as you'd need
> > at least width x depth packets in there to keep the pipes busy.
> > Just like a modern CPU needs hundreds of instructions in flight
> > to keep all its resources busy.
> >
> > > The reason I ask is that a
> > > lot of crypto acceleration hardware of the past has been fast and
> > > having very deep buffers, but at great expense of latency.
> > >
> > Define "great expense". Everything is relative. The latency is very
> > high compared to per-packet processing time but at the same time it's
> > only on the order of a few uSec. Which may not even be significant on
> > the total time it takes for the packet to travel from input MAC to
> > output MAC, considering the CPU will still need to parse and classify
> > it and do pre- and postprocessing on it.
> >
> > > In the networking context, keeping latency low is pretty important.
> > >
> > I've been doing this for IPsec for nearly 20 years now and I've never
> > heard anyone complain about our latency, so it must be OK.
>
> Well, it depends on where your bottlenecks are. On low-end hardware
> you can and do tend to bottleneck on the crypto step, and with
> uncontrolled, non-fq'd non-aqm'd buffering you get results like this:
>
> http://blog.cerowrt.org/post/wireguard/
>
> so in terms of "threads" I would prefer to think of flows entering
> the tunnel and attempting to multiplex them as best as possible
> across the crypto hard/software so that minimal in-hw latencies are experienced
> for most packets and that the coupled queue length does not grow out of control,
>
> Adding fq_codel's hashing algo and queuing to ipsec as was done in
> commit: 264b87fa617e758966108db48db220571ff3d60e to leverage
> the inner hash...
>
> Had some nice results:
>
> before: http://www.taht.net/~d/ipsec_fq_codel/oldqos.png (100ms spikes)
> After: http://www.taht.net/~d/ipsec_fq_codel/newqos.png (2ms spikes)
>
> I'd love to see more vpn vendors using the rrul test or something even
> nastier to evaluate their results, rather than dragstrip bulk throughput tests,
> steering multiple flows over multiple cores.
>
> > We're also doing (fully inline, no CPU involved) MACsec cores, which
> > operate at layer 2 and I know it's a concern there for very specific
> > use cases (high frequency trading, precision time protocol, ...).
> > For "normal" VPN's though, a few uSec more or less should be a non-issue.
>
> Measured buffering is typically 1000 packets in userspace vpns. If you
> can put data in, faster than you can get it out, well....
>
We don't buffer anywhere near 1000 packets in the hardware itself.
In fact, our buffers are designed to be carefully tunable to accept
the minimum number of packets required by the system as a whole.
But we do need to potentially keep a deep & wide pipeline busy, so for
the big, high-speed engines some double-digit buffering is inevitable.
It won't get anywhere near even a 100 packets though, let alone 1000.
Also, the whole point of crypto HW acceleration is ensure the crypto
is *not* the bottleneck, not even for those pesky small TCP ACK packets
when they come back-to-back (although I doubt the crypto itself is the
bottleneck there, as there is actually very little crypto to do then).
We work very hard to ensure decent *small* packet performance and
generally you should scale your crypto HW to be able to keep up with
the worst case there, with margin to spare ...
> > > Already
> > > WireGuard is multi-threaded which isn't super great all the time for
> > > latency (improvements are a work in progress). If you're involved with
> > > the design of the hardware, perhaps this is something you can help
> > > ensure winds up working well? For example, AES-NI is straightforward
> > > and good, but Intel can do that because they are the CPU. It sounds
> > > like your silicon will be adjacent. How do you envision this working
> > > in a low latency environment?
> > >
> > Depends on how low low-latency is. If you really need minimal latency,
> > you need an inline implementation. Which we can also provide, BTW :-)
> >
> > Regards,
> > Pascal van Leeuwen
> > Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
> > www.insidesecure.com
>
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
_______________________________________________
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: dts: stm32: Enable high resolution timer
From: Benjamin GAIGNARD @ 2019-09-27 12:36 UTC (permalink / raw)
To: Marc Zyngier
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Alexandre TORGUE, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <da48ce9633441cd0186518fa7ce1d528@www.loen.fr>
On 9/27/19 1:22 PM, Marc Zyngier wrote:
> On 2019-09-27 09:48, Benjamin Gaignard wrote:
>> Adding always-on makes arm arch_timer claim to be an high resolution
>> timer.
>> That is possible because power mode won't stop clocking the timer.
>
> The "always-on" is not about the clock. It is about the comparator.
> The clock itself is *guaranteed* to always tick. If it didn't, that'd be
> an integration bug, and a pretty bad one.
>
> What you're claiming here is that your CPU never enters a low-power mode?
> Ever? I find this very hard to believe.
>
> Furthermore, claiming that always-on is the way to force the arch-timer
> to be an hrtimer is factually wrong. This is what happens *if* this is
> the only timer in the system. The only case this is true is for virtual
> machines. Anything else has a global timer somewhere that will allow
> the arch timers to be used as an hrtimer.
>
> I'm pretty sure you too have a global timer somewhere in your system.
> Enable it, and enjoy hrtimers without having to lie about the properties
> of your system! ;-)
Hi Marc,
This SoC doesn't have any other global timer. Use arch_time is the only
we have to provide hrtimer on this system.
Benjamin
>
> M.
>
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@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 9b11654a0a39..74f64745d60d 100644
>> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
>> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
>> @@ -50,6 +50,7 @@
>> <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) |
>> IRQ_TYPE_LEVEL_LOW)>,
>> <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) |
>> IRQ_TYPE_LEVEL_LOW)>;
>> interrupt-parent = <&intc>;
>> + always-on;
>> };
>>
>> clocks {
>
_______________________________________________
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: dts: stm32: Enable high resolution timer
From: Marc Zyngier @ 2019-09-27 12:41 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: mark.rutland, devicetree, Alexandre TORGUE, linux-kernel, robh+dt,
linux-stm32, linux-arm-kernel
In-Reply-To: <341949c8-7864-5d65-2797-988022724a4c@st.com>
On 2019-09-27 13:36, Benjamin GAIGNARD wrote:
> On 9/27/19 1:22 PM, Marc Zyngier wrote:
>> On 2019-09-27 09:48, Benjamin Gaignard wrote:
>>> Adding always-on makes arm arch_timer claim to be an high
>>> resolution
>>> timer.
>>> That is possible because power mode won't stop clocking the timer.
>>
>> The "always-on" is not about the clock. It is about the comparator.
>> The clock itself is *guaranteed* to always tick. If it didn't,
>> that'd be
>> an integration bug, and a pretty bad one.
>>
>> What you're claiming here is that your CPU never enters a low-power
>> mode?
>> Ever? I find this very hard to believe.
>>
>> Furthermore, claiming that always-on is the way to force the
>> arch-timer
>> to be an hrtimer is factually wrong. This is what happens *if* this
>> is
>> the only timer in the system. The only case this is true is for
>> virtual
>> machines. Anything else has a global timer somewhere that will allow
>> the arch timers to be used as an hrtimer.
>>
>> I'm pretty sure you too have a global timer somewhere in your
>> system.
>> Enable it, and enjoy hrtimers without having to lie about the
>> properties
>> of your system! ;-)
>
> Hi Marc,
>
> This SoC doesn't have any other global timer. Use arch_time is the
> only
> we have to provide hrtimer on this system.
And you don't have any form of power management either? What happens
when
your CPU goes into idle? If your system does any form of power
management
*and* doesn't have a separate timer, it is remarkably broken.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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: dts: stm32: Enable high resolution timer
From: Benjamin GAIGNARD @ 2019-09-27 12:44 UTC (permalink / raw)
To: Marc Zyngier
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Alexandre TORGUE, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <ff11797da8f049b354797689754fde52@www.loen.fr>
On 9/27/19 2:41 PM, Marc Zyngier wrote:
> On 2019-09-27 13:36, Benjamin GAIGNARD wrote:
>> On 9/27/19 1:22 PM, Marc Zyngier wrote:
>>> On 2019-09-27 09:48, Benjamin Gaignard wrote:
>>>> Adding always-on makes arm arch_timer claim to be an high resolution
>>>> timer.
>>>> That is possible because power mode won't stop clocking the timer.
>>>
>>> The "always-on" is not about the clock. It is about the comparator.
>>> The clock itself is *guaranteed* to always tick. If it didn't,
>>> that'd be
>>> an integration bug, and a pretty bad one.
>>>
>>> What you're claiming here is that your CPU never enters a low-power
>>> mode?
>>> Ever? I find this very hard to believe.
>>>
>>> Furthermore, claiming that always-on is the way to force the arch-timer
>>> to be an hrtimer is factually wrong. This is what happens *if* this is
>>> the only timer in the system. The only case this is true is for virtual
>>> machines. Anything else has a global timer somewhere that will allow
>>> the arch timers to be used as an hrtimer.
>>>
>>> I'm pretty sure you too have a global timer somewhere in your system.
>>> Enable it, and enjoy hrtimers without having to lie about the
>>> properties
>>> of your system! ;-)
>>
>> Hi Marc,
>>
>> This SoC doesn't have any other global timer. Use arch_time is the only
>> we have to provide hrtimer on this system.
>
> And you don't have any form of power management either? What happens when
> your CPU goes into idle? If your system does any form of power management
> *and* doesn't have a separate timer, it is remarkably broken.
Even in low-power modes this timer is always powered and clocked so it
is working fine.
>
> M.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 0/7] Add support of New Amlogic temperature sensor for G12 SoCs
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
This patchs series add support of New Amlogic temperature sensor and minimal
thermal zone for SEI510 and ODROID-N2 boards.
First implementation was doing on IIO[1] but after comments i move on thermal framework.
Formulas and calibration values come from amlogic.
Changes since v4:
- Move thermal-zone in soc dtsi file
- Remove critical trip point and add passive one
- fix commit message
- use devm_platform_ioremap_resource instead of platform_get_resource
Changes since v3:
- Add cooling map and trip point for hot type
- move compatible on g12a instead of g12 to be aligned with others
- add all reviewer, sorry for this mistake
Changes since v2:
- fix yaml documention
- remove unneeded status variable for temperature-sensor node
- rework driver after Martin review
- add some information in commit message
Changes since v1:
- fix enum vs const in documentation
- fix error with thermal-sensor-cells value set to 1 instead of 0
- add some dependencies needed to add cooling-maps
Dependencies :
- patch 3,4 & 5: depends on Neil's patch and series :
- missing dwc2 phy-names[2]
- patchsets to add DVFS on G12a[3] which have deps on [4] and [5]
[1] https://lore.kernel.org/linux-amlogic/20190604144714.2009-1-glaroque@baylibre.com/
[2] https://lore.kernel.org/linux-amlogic/20190625123647.26117-1-narmstrong@baylibre.com/
[3] https://lore.kernel.org/linux-amlogic/20190729132622.7566-1-narmstrong@baylibre.com/
[4] https://lore.kernel.org/linux-amlogic/20190731084019.8451-5-narmstrong@baylibre.com/
[5] https://lore.kernel.org/linux-amlogic/20190729132622.7566-3-narmstrong@baylibre.com/
Guillaume La Roque (7):
dt-bindings: thermal: Add DT bindings documentation for Amlogic
Thermal
thermal: amlogic: Add thermal driver to support G12 SoCs
arm64: dts: amlogic: g12: add temperature sensor
arm64: dts: meson: g12: Add minimal thermal zone
arm64: dts: amlogic: g12a: add cooling properties
arm64: dts: amlogic: g12b: add cooling properties
MAINTAINERS: add entry for Amlogic Thermal driver
.../bindings/thermal/amlogic,thermal.yaml | 54 +++
MAINTAINERS | 9 +
.../boot/dts/amlogic/meson-g12-common.dtsi | 66 ++++
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 24 ++
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 29 ++
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile | 1 +
drivers/thermal/amlogic_thermal.c | 333 ++++++++++++++++++
8 files changed, 527 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
create mode 100644 drivers/thermal/amlogic_thermal.c
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/7] dt-bindings: thermal: Add DT bindings documentation for Amlogic Thermal
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Adding the devicetree binding documentation for the Amlogic temperature
sensor found in the Amlogic Meson G12A and G12B SoCs.
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
.../bindings/thermal/amlogic,thermal.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
new file mode 100644
index 000000000000..f761681e4c0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/amlogic,thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Amlogic Thermal
+
+maintainers:
+ - Guillaume La Roque <glaroque@baylibre.com>
+
+description: Binding for Amlogic Thermal
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - amlogic,g12a-cpu-thermal
+ - amlogic,g12a-ddr-thermal
+ - const: amlogic,g12a-thermal
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ amlogic,ao-secure:
+ description: phandle to the ao-secure syscon
+ $ref: '/schemas/types.yaml#/definitions/phandle'
+
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - amlogic,ao-secure
+
+examples:
+ - |
+ cpu_temp: temperature-sensor@ff634800 {
+ compatible = "amlogic,g12a-cpu-thermal",
+ "amlogic,g12a-thermal";
+ reg = <0xff634800 0x50>;
+ interrupts = <0x0 0x24 0x0>;
+ clocks = <&clk 164>;
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
+...
--
2.17.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
* [PATCH v5 2/7] thermal: amlogic: Add thermal driver to support G12 SoCs
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Amlogic G12A and G12B SoCs integrate two thermal sensors
with the same design. One is located close to the DDR controller
and the other one is located close to the PLLs (between the CPU and GPU).
The calibration data for each of the thermal sensors instance is stored
in a different location within the AO region.
Implement reading the temperature from each thermal sensor.
The IP block has more functionality, which may be added to this driver
in the future:
- chip reset when the temperature exceeds a configurable threshold
- up to four interrupts when the temperature has risen above a
configurable threshold
- up to four interrupts when the temperature has fallen below a
configurable threshold
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile | 1 +
drivers/thermal/amlogic_thermal.c | 333 ++++++++++++++++++++++++++++++
3 files changed, 345 insertions(+)
create mode 100644 drivers/thermal/amlogic_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 9966364a6deb..0f31bb4bc372 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -348,6 +348,17 @@ config MTK_THERMAL
Enable this option if you want to have support for thermal management
controller present in Mediatek SoCs
+config AMLOGIC_THERMAL
+ tristate "Amlogic Thermal Support"
+ default ARCH_MESON
+ depends on OF && ARCH_MESON
+ help
+ If you say yes here you get support for Amlogic Thermal
+ for G12 SoC Family.
+
+ This driver can also be built as a module. If so, the module will
+ be called amlogic_thermal.
+
menu "Intel thermal drivers"
depends on X86 || X86_INTEL_QUARK || COMPILE_TEST
source "drivers/thermal/intel/Kconfig"
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 74a37c7f847a..baeb70bf0568 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -54,3 +54,4 @@ obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
+obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
new file mode 100644
index 000000000000..8a9e9bc421c6
--- /dev/null
+++ b/drivers/thermal/amlogic_thermal.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Amlogic Thermal Sensor Driver
+ *
+ * Copyright (C) 2017 Huan Biao <huan.biao@amlogic.com>
+ * Copyright (C) 2019 Guillaume La Roque <glaroque@baylibre.com>
+ *
+ * Register value to celsius temperature formulas:
+ * Read_Val m * U
+ * U = ---------, Uptat = ---------
+ * 2^16 1 + n * U
+ *
+ * Temperature = A * ( Uptat + u_efuse / 2^16 )- B
+ *
+ * A B m n : calibration parameters
+ * u_efuse : fused calibration value, it's a signed 16 bits value
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+
+#include "thermal_core.h"
+
+#define TSENSOR_CFG_REG1 0x4
+ #define TSENSOR_CFG_REG1_RSET_VBG BIT(12)
+ #define TSENSOR_CFG_REG1_RSET_ADC BIT(11)
+ #define TSENSOR_CFG_REG1_VCM_EN BIT(10)
+ #define TSENSOR_CFG_REG1_VBG_EN BIT(9)
+ #define TSENSOR_CFG_REG1_OUT_CTL BIT(6)
+ #define TSENSOR_CFG_REG1_FILTER_EN BIT(5)
+ #define TSENSOR_CFG_REG1_DEM_EN BIT(3)
+ #define TSENSOR_CFG_REG1_CH_SEL GENMASK(1, 0)
+ #define TSENSOR_CFG_REG1_ENABLE \
+ (TSENSOR_CFG_REG1_FILTER_EN | \
+ TSENSOR_CFG_REG1_VCM_EN | \
+ TSENSOR_CFG_REG1_VBG_EN | \
+ TSENSOR_CFG_REG1_DEM_EN | \
+ TSENSOR_CFG_REG1_CH_SEL)
+
+#define TSENSOR_STAT0 0x40
+
+#define TSENSOR_STAT9 0x64
+
+#define TSENSOR_READ_TEMP_MASK GENMASK(15, 0)
+#define TSENSOR_TEMP_MASK GENMASK(11, 0)
+
+#define TSENSOR_TRIM_SIGN_MASK BIT(15)
+#define TSENSOR_TRIM_TEMP_MASK GENMASK(14, 0)
+#define TSENSOR_TRIM_VERSION_MASK GENMASK(31, 24)
+
+#define TSENSOR_TRIM_VERSION(_version) \
+ FIELD_GET(TSENSOR_TRIM_VERSION_MASK, _version)
+
+#define TSENSOR_TRIM_CALIB_VALID_MASK (GENMASK(3, 2) | BIT(7))
+
+#define TSENSOR_CALIB_OFFSET 1
+#define TSENSOR_CALIB_SHIFT 4
+
+/**
+ * struct amlogic_thermal_soc_calib_data
+ * @A, B, m, n: calibration parameters
+ * This structure is required for configuration of amlogic thermal driver.
+ */
+struct amlogic_thermal_soc_calib_data {
+ int A;
+ int B;
+ int m;
+ int n;
+};
+
+/**
+ * struct amlogic_thermal_data
+ * @u_efuse_off: register offset to read fused calibration value
+ * @calibration_parameters: calibration parameters structure pointer
+ * @regmap_config: regmap config for the device
+ * This structure is required for configuration of amlogic thermal driver.
+ */
+struct amlogic_thermal_data {
+ int u_efuse_off;
+ const struct amlogic_thermal_soc_calib_data *calibration_parameters;
+ const struct regmap_config *regmap_config;
+};
+
+struct amlogic_thermal {
+ struct platform_device *pdev;
+ const struct amlogic_thermal_data *data;
+ struct regmap *regmap;
+ struct regmap *sec_ao_map;
+ struct clk *clk;
+ struct thermal_zone_device *tzd;
+ u32 trim_info;
+};
+
+/*
+ * Calculate a temperature value from a temperature code.
+ * The unit of the temperature is degree milliCelsius.
+ */
+static int amlogic_thermal_code_to_millicelsius(struct amlogic_thermal *pdata,
+ int temp_code)
+{
+ const struct amlogic_thermal_soc_calib_data *param =
+ pdata->data->calibration_parameters;
+ int temp;
+ s64 factor, Uptat, uefuse;
+
+ uefuse = pdata->trim_info & TSENSOR_TRIM_SIGN_MASK ?
+ ~(pdata->trim_info & TSENSOR_TRIM_TEMP_MASK) + 1 :
+ (pdata->trim_info & TSENSOR_TRIM_TEMP_MASK);
+
+ factor = param->n * temp_code;
+ factor = div_s64(factor, 100);
+
+ Uptat = temp_code * param->m;
+ Uptat = div_s64(Uptat, 100);
+ Uptat = Uptat * BIT(16);
+ Uptat = div_s64(Uptat, BIT(16) + factor);
+
+ temp = (Uptat + uefuse) * param->A;
+ temp = div_s64(temp, BIT(16));
+ temp = (temp - param->B) * 100;
+
+ return temp;
+}
+
+static int amlogic_thermal_initialize(struct amlogic_thermal *pdata)
+{
+ int ret = 0;
+ int ver;
+
+ regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
+ &pdata->trim_info);
+
+ ver = TSENSOR_TRIM_VERSION(pdata->trim_info);
+
+ if ((ver & TSENSOR_TRIM_CALIB_VALID_MASK) == 0) {
+ ret = -EINVAL;
+ dev_err(&pdata->pdev->dev,
+ "tsensor thermal calibration not supported: 0x%x!\n",
+ ver);
+ }
+
+ return ret;
+}
+
+static int amlogic_thermal_enable(struct amlogic_thermal *data)
+{
+ int ret;
+
+ ret = clk_prepare_enable(data->clk);
+ if (ret)
+ return ret;
+
+ regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
+ TSENSOR_CFG_REG1_ENABLE, TSENSOR_CFG_REG1_ENABLE);
+
+ return 0;
+}
+
+static int amlogic_thermal_disable(struct amlogic_thermal *data)
+{
+ regmap_update_bits(data->regmap, TSENSOR_CFG_REG1,
+ TSENSOR_CFG_REG1_ENABLE, 0);
+ clk_disable_unprepare(data->clk);
+
+ return 0;
+}
+
+static int amlogic_thermal_get_temp(void *data, int *temp)
+{
+ unsigned int tval;
+ struct amlogic_thermal *pdata = data;
+
+ if (!data)
+ return -EINVAL;
+
+ regmap_read(pdata->regmap, TSENSOR_STAT0, &tval);
+ *temp =
+ amlogic_thermal_code_to_millicelsius(pdata,
+ tval & TSENSOR_READ_TEMP_MASK);
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops amlogic_thermal_ops = {
+ .get_temp = amlogic_thermal_get_temp,
+};
+
+static const struct regmap_config amlogic_thermal_regmap_config_g12a = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = TSENSOR_STAT9,
+};
+
+static const struct amlogic_thermal_soc_calib_data amlogic_thermal_g12a = {
+ .A = 9411,
+ .B = 3159,
+ .m = 424,
+ .n = 324,
+};
+
+static const struct amlogic_thermal_data amlogic_thermal_g12a_cpu_param = {
+ .u_efuse_off = 0x128,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
+static const struct amlogic_thermal_data amlogic_thermal_g12a_ddr_param = {
+ .u_efuse_off = 0xf0,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
+static const struct of_device_id of_amlogic_thermal_match[] = {
+ {
+ .compatible = "amlogic,g12a-ddr-thermal",
+ .data = &amlogic_thermal_g12a_ddr_param,
+ },
+ {
+ .compatible = "amlogic,g12a-cpu-thermal",
+ .data = &amlogic_thermal_g12a_cpu_param,
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
+
+static int amlogic_thermal_probe(struct platform_device *pdev)
+{
+ struct amlogic_thermal *pdata;
+ struct device *dev = &pdev->dev;
+ void __iomem *base;
+ int ret;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->data = of_device_get_match_data(dev);
+ pdata->pdev = pdev;
+ platform_set_drvdata(pdev, pdata);
+
+ base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(base)) {
+ dev_err(dev, "failed to get io address\n");
+ return PTR_ERR(base);
+ }
+
+ pdata->regmap = devm_regmap_init_mmio(dev, base,
+ pdata->data->regmap_config);
+ if (IS_ERR(pdata->regmap))
+ return PTR_ERR(pdata->regmap);
+
+ pdata->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(pdata->clk)) {
+ if (PTR_ERR(pdata->clk) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get clock\n");
+ return PTR_ERR(pdata->clk);
+ }
+
+ pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
+ (pdev->dev.of_node, "amlogic,ao-secure");
+ if (IS_ERR(pdata->sec_ao_map)) {
+ dev_err(dev, "syscon regmap lookup failed.\n");
+ return PTR_ERR(pdata->sec_ao_map);
+ }
+
+ pdata->tzd = devm_thermal_zone_of_sensor_register(&pdev->dev,
+ 0,
+ pdata,
+ &amlogic_thermal_ops);
+ if (IS_ERR(pdata->tzd)) {
+ ret = PTR_ERR(pdata->tzd);
+ dev_err(dev, "Failed to register tsensor: %d\n", ret);
+ return ret;
+ }
+
+ ret = amlogic_thermal_initialize(pdata);
+ if (ret)
+ return ret;
+
+ ret = amlogic_thermal_enable(pdata);
+
+ return ret;
+}
+
+static int amlogic_thermal_remove(struct platform_device *pdev)
+{
+ struct amlogic_thermal *data = platform_get_drvdata(pdev);
+
+ return amlogic_thermal_disable(data);
+}
+
+static int __maybe_unused amlogic_thermal_suspend(struct device *dev)
+{
+ struct amlogic_thermal *data = dev_get_drvdata(dev);
+
+ return amlogic_thermal_disable(data);
+}
+
+static int __maybe_unused amlogic_thermal_resume(struct device *dev)
+{
+ struct amlogic_thermal *data = dev_get_drvdata(dev);
+
+ return amlogic_thermal_enable(data);
+}
+
+static SIMPLE_DEV_PM_OPS(amlogic_thermal_pm_ops,
+ amlogic_thermal_suspend, amlogic_thermal_resume);
+
+static struct platform_driver amlogic_thermal_driver = {
+ .driver = {
+ .name = "amlogic_thermal",
+ .pm = &amlogic_thermal_pm_ops,
+ .of_match_table = of_amlogic_thermal_match,
+ },
+ .probe = amlogic_thermal_probe,
+ .remove = amlogic_thermal_remove,
+};
+
+module_platform_driver(amlogic_thermal_driver);
+
+MODULE_AUTHOR("Guillaume La Roque <glaroque@baylibre.com>");
+MODULE_DESCRIPTION("Amlogic thermal driver");
+MODULE_LICENSE("GPL v2");
--
2.17.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
* [PATCH v5 3/7] arm64: dts: amlogic: g12: add temperature sensor
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Add cpu and ddr temperature sensors for G12 Socs
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
.../boot/dts/amlogic/meson-g12-common.dtsi | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 38d70ce1cfc7..0660d9ef6a86 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -1353,6 +1353,26 @@
};
};
+ cpu_temp: temperature-sensor@34800 {
+ compatible = "amlogic,g12a-cpu-thermal",
+ "amlogic,g12a-thermal";
+ reg = <0x0 0x34800 0x0 0x50>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
+
+ ddr_temp: temperature-sensor@34c00 {
+ compatible = "amlogic,g12a-ddr-thermal",
+ "amlogic,g12a-thermal";
+ reg = <0x0 0x34c00 0x0 0x50>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,ao-secure = <&sec_AO>;
+ };
+
usb2_phy0: phy@36000 {
compatible = "amlogic,g12a-usb2-phy";
reg = <0x0 0x36000 0x0 0x2000>;
--
2.17.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
* [PATCH v5 4/7] arm64: dts: meson: g12: Add minimal thermal zone
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Add minimal thermal zone for two temperature sensor
One is located close to the DDR and the other one is
located close to the PLLs (between the CPU and GPU)
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
.../boot/dts/amlogic/meson-g12-common.dtsi | 46 +++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 0660d9ef6a86..f98171949fcb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -12,6 +12,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/amlogic,meson-axg-audio-arb.h>
#include <dt-bindings/reset/amlogic,meson-g12a-reset.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&gic>;
@@ -94,6 +95,50 @@
#size-cells = <2>;
ranges;
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&cpu_temp>;
+
+ trips {
+ cpu_passive: cpu-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ cpu_hot: cpu-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ };
+ };
+
+ ddr_thermal: ddr-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&ddr_temp>;
+
+ trips {
+ ddr_passive: ddr-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&ddr_passive>;
+ cooling-device = <&mali THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
ethmac: ethernet@ff3f0000 {
compatible = "amlogic,meson-axg-dwmac",
"snps,dwmac-3.70a",
@@ -2412,6 +2457,7 @@
assigned-clock-rates = <0>, /* Do Nothing */
<800000000>,
<0>; /* Do Nothing */
+ #cooling-cells = <2>;
};
};
--
2.17.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
* [PATCH v5 5/7] arm64: dts: amlogic: g12a: add cooling properties
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Add missing #colling-cells field for G12A SoC
Add cooling-map for passive and hot trip point
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 24 +++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
index 733a9d46fc4b..3ab6497548ca 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
@@ -18,6 +18,7 @@
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -26,6 +27,7 @@
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -34,6 +36,7 @@
reg = <0x0 0x2>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -42,6 +45,7 @@
reg = <0x0 0x3>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
l2: l2-cache0 {
@@ -113,3 +117,23 @@
&sd_emmc_a {
amlogic,dram-access-quirk;
};
+
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ trip = <&cpu_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+
+ map1 {
+ trip = <&cpu_hot>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
--
2.17.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
* [PATCH v5 6/7] arm64: dts: amlogic: g12b: add cooling properties
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Add missing #colling-cells field for G12B SoC
Add cooling-map for passive and hot trip point
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 29 +++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
index 98ae8a7c8b41..4bb89bce758f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
@@ -49,6 +49,7 @@
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -57,6 +58,7 @@
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu100: cpu@100 {
@@ -65,6 +67,7 @@
reg = <0x0 0x100>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu101: cpu@101 {
@@ -73,6 +76,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu102: cpu@102 {
@@ -81,6 +85,7 @@
reg = <0x0 0x102>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu103: cpu@103 {
@@ -89,6 +94,7 @@
reg = <0x0 0x103>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
l2: l2-cache0 {
@@ -219,3 +225,26 @@
&sd_emmc_a {
amlogic,dram-access-quirk;
};
+
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ trip = <&cpu_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ map1 {
+ trip = <&cpu_hot>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
--
2.17.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
* [PATCH v5 5/7] arm64: dts: amlogic: g12a: add missing cooling info
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Add missing #colling-cells field for G12A SoC
Add cooling-map for passive and hot trip point
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 24 +++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
index 733a9d46fc4b..3ab6497548ca 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12a.dtsi
@@ -18,6 +18,7 @@
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -26,6 +27,7 @@
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -34,6 +36,7 @@
reg = <0x0 0x2>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -42,6 +45,7 @@
reg = <0x0 0x3>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
l2: l2-cache0 {
@@ -113,3 +117,23 @@
&sd_emmc_a {
amlogic,dram-access-quirk;
};
+
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ trip = <&cpu_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+
+ map1 {
+ trip = <&cpu_hot>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
--
2.17.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
* [PATCH v5 7/7] MAINTAINERS: add entry for Amlogic Thermal driver
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Add myself as maintainer for Amlogic Thermal driver.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 390c3194ee93..bdc30d740342 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15932,6 +15932,15 @@ F: Documentation/driver-api/thermal/cpu-cooling-api.rst
F: drivers/thermal/cpu_cooling.c
F: include/linux/cpu_cooling.h
+THERMAL DRIVER FOR AMLOGIC SOCS
+M: Guillaume La Roque <glaroque@baylibre.com>
+L: linux-pm@vger.kernel.org
+L: linux-amlogic@lists.infradead.org
+W: http://linux-meson.com/
+S: Supported
+F: drivers/thermal/amlogic_thermal.c
+F: Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+
THINKPAD ACPI EXTRAS DRIVER
M: Henrique de Moraes Holschuh <ibm-acpi@hmh.eng.br>
L: ibm-acpi-devel@lists.sourceforge.net
--
2.17.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
* [PATCH v5 6/7] arm64: dts: amlogic: g12b: add missing cooling info
From: Guillaume La Roque @ 2019-09-27 12:47 UTC (permalink / raw)
To: amit.kucheria, rui.zhang, edubezval, daniel.lezcano
Cc: devicetree, linux-amlogic, linux-kernel, linux-arm-kernel,
linux-pm
In-Reply-To: <20190927124750.12467-1-glaroque@baylibre.com>
Add missing #colling-cells field for G12B SoC
Add cooling-map for passive and hot trip point
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 29 +++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
index 98ae8a7c8b41..4bb89bce758f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
@@ -49,6 +49,7 @@
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -57,6 +58,7 @@
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu100: cpu@100 {
@@ -65,6 +67,7 @@
reg = <0x0 0x100>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu101: cpu@101 {
@@ -73,6 +76,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu102: cpu@102 {
@@ -81,6 +85,7 @@
reg = <0x0 0x102>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
cpu103: cpu@103 {
@@ -89,6 +94,7 @@
reg = <0x0 0x103>;
enable-method = "psci";
next-level-cache = <&l2>;
+ #cooling-cells = <2>;
};
l2: l2-cache0 {
@@ -219,3 +225,26 @@
&sd_emmc_a {
amlogic,dram-access-quirk;
};
+
+&cpu_thermal {
+ cooling-maps {
+ map0 {
+ trip = <&cpu_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ map1 {
+ trip = <&cpu_hot>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
--
2.17.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 1/1] arm64/sve: Fix wrong free for task->thread.sve_state
From: Dave Martin @ 2019-09-27 12:52 UTC (permalink / raw)
To: Masayoshi Mizuma
Cc: Masayoshi Mizuma, Catalin Marinas, linux-kernel, Julien Grall,
Will Deacon, linux-arm-kernel
In-Reply-To: <20190926190846.3072-2-msys.mizuma@gmail.com>
On Thu, Sep 26, 2019 at 03:08:46PM -0400, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>
> The system which has SVE feature crashed because of
> the memory pointed by task->thread.sve_state was destroyed
> by someone.
>
> That is because sve_state is freed while the forking the
> child process. The child process has the pointer of sve_state
> which is same as the parent's because the child's task_struct
> is copied from the parent's one. If the copy_process()
> fails as an error on somewhere, for example, copy_creds(),
> then the sve_state is freed even if the parent is alive.
> The flow is as follows.
>
> copy_process
> p = dup_task_struct
> => arch_dup_task_struct
> *dst = *src; // copy the entire region.
> :
> retval = copy_creds
> if (retval < 0)
> goto bad_fork_free;
> :
> bad_fork_free:
> ...
> delayed_free_task(p);
> => free_task
> => arch_release_task_struct
> => fpsimd_release_task
> => __sve_free
> => kfree(task->thread.sve_state);
> // free the parent's sve_state
>
> Add a flag in task->thread which shows the fork is in progress.
> If the fork is in progress, that means the child has the pointer
> to the parent's sve_state, doesn't free the sve_state.
>
> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> Reported-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
> ---
> arch/arm64/include/asm/processor.h | 1 +
> arch/arm64/kernel/fpsimd.c | 6 ++++--
> arch/arm64/kernel/process.c | 2 ++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 5623685c7d13..3ca3e350145a 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -143,6 +143,7 @@ struct thread_struct {
> unsigned long fault_address; /* fault info */
> unsigned long fault_code; /* ESR_EL1 value */
> struct debug_info debug; /* debugging */
> + unsigned int fork_in_progress;
> #ifdef CONFIG_ARM64_PTR_AUTH
> struct ptrauth_keys keys_user;
> #endif
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 37d3912cfe06..8641db4cb062 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -202,8 +202,10 @@ static bool have_cpu_fpsimd_context(void)
> */
> static void __sve_free(struct task_struct *task)
> {
> - kfree(task->thread.sve_state);
> - task->thread.sve_state = NULL;
> + if (!task->thread.fork_in_progress) {
> + kfree(task->thread.sve_state);
> + task->thread.sve_state = NULL;
> + }
> }
>
> static void sve_free(struct task_struct *task)
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index a47462def04b..8ac0ee4e5f76 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -347,6 +347,7 @@ int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
> if (current->mm)
> fpsimd_preserve_current_state();
> *dst = *src;
> + dst->thread.fork_in_progress = 1;
>
> return 0;
> }
> @@ -365,6 +366,7 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
> * and disable discard SVE state for p:
> */
> clear_tsk_thread_flag(p, TIF_SVE);
> + p->thread.fork_in_progress = 0;
> p->thread.sve_state = NULL;
There's definitely a problem here, but a simpler fix is probably to
NULL sve_state and clear TIF_SVE for dst at the same time.
Once upon a time, I had to cope with the thread_flags not being copied
as part of task_struct here, which is one reason why the code is the
(broken) way it is, but this is ancient history...
Commit c02433dd6de3 ("arm64: split thread_info from task stack") was
merged in v4.10 and predates SVE support anyway.
So can just do the following (untested) and delete the confusing
comments?
Cheers
---Dave
--8<--
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index f674f28..6937f59 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -323,22 +323,16 @@ void arch_release_task_struct(struct task_struct *tsk)
fpsimd_release_task(tsk);
}
-/*
- * src and dst may temporarily have aliased sve_state after task_struct
- * is copied. We cannot fix this properly here, because src may have
- * live SVE state and dst's thread_info may not exist yet, so tweaking
- * either src's or dst's TIF_SVE is not safe.
- *
- * The unaliasing is done in copy_thread() instead. This works because
- * dst is not schedulable or traceable until both of these functions
- * have been called.
- */
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
{
if (current->mm)
fpsimd_preserve_current_state();
*dst = *src;
+ BUILD_BUG_ON(!IS_ENABLED(CONFIG_THREAD_INFO_IN_TASK));
+ dst->thread.sve_state = NULL;
+ clear_tsk_thread_flag(dst, TIF_SVE);
+
return 0;
}
@@ -352,13 +346,6 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
memset(&p->thread.cpu_context, 0, sizeof(struct cpu_context));
/*
- * Unalias p->thread.sve_state (if any) from the parent task
- * and disable discard SVE state for p:
- */
- clear_tsk_thread_flag(p, TIF_SVE);
- p->thread.sve_state = NULL;
-
- /*
* In case p was allocated the same task_struct pointer as some
* other recently-exited task, make sure p is disassociated from
* any cpu that may have run that now-exited task recently.
_______________________________________________
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 2/2] clk: meson: a1: add support for Amlogic A1 clock driver
From: Jerome Brunet @ 2019-09-27 12:56 UTC (permalink / raw)
To: Jian Hu
Cc: Rob Herring, Jianxin Pan, devicetree, Stephen Boyd, Kevin Hilman,
Michael Turquette, Neil Armstrong, linux-kernel,
Martin Blumenstingl, Qiufang Dai, linux-amlogic, linux-clk,
linux-arm-kernel, Jerome Brunet
In-Reply-To: <8351489a-f91e-be08-7fcc-e2a90c6e87f0@amlogic.com>
On Fri 27 Sep 2019 at 05:11, Jian Hu <jian.hu@amlogic.com> wrote:
> Hi, Stephen
>
> Thank you for review
>
> On 2019/9/25 21:12, Stephen Boyd wrote:
>> Quoting Jian Hu (2019-09-25 04:44:48)
>>> The Amlogic A1 clock includes three parts:
>>> peripheral clocks, pll clocks, CPU clocks.
>>> sys pll and CPU clocks will be sent in next patch.
>>>
>>> Unlike the previous series, there is no EE/AO domain
>>> in A1 CLK controllers.
>>>
>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>> Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
>>
>> This second name didn't send the patch. Please follow the signoff
>> procedures documented in Documentation/process/submitting-patches.rst
>>
>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>> index 16d7614..a48f67d 100644
>>> --- a/arch/arm64/Kconfig.platforms
>>> +++ b/arch/arm64/Kconfig.platforms
>>> @@ -138,6 +138,7 @@ config ARCH_MESON
>>> select COMMON_CLK_AXG
>>> select COMMON_CLK_G12A
>>> select MESON_IRQ_GPIO
>>> + select COMMON_CLK_A1
>>
>> Sort?
> ok, I will put it behind COMMON_CLK_AXG
>>
>>> help
>>> This enables support for the arm64 based Amlogic SoCs
>>> such as the s905, S905X/D, S912, A113X/D or S905X/D2
>>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>>> index dabeb43..e6cb4c3 100644
>>> --- a/drivers/clk/meson/Kconfig
>>> +++ b/drivers/clk/meson/Kconfig
>>> @@ -107,3 +107,13 @@ config COMMON_CLK_G12A
>>> help
>>> Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
>>> devices, aka g12a. Say Y if you want peripherals to work.
>>> +
>>> +config COMMON_CLK_A1
>>
>> Probably should be placed somewhere alphabetically in this file?
> ok, I will put it behind COMMON_CLK_AXG_AUDIO
>>
>>> + bool
>>> + depends on ARCH_MESON
>>> + select COMMON_CLK_MESON_REGMAP
>>> + select COMMON_CLK_MESON_DUALDIV
>>> + select COMMON_CLK_MESON_PLL
>>> + help
>>> + Support for the clock controller on Amlogic A113L device,
>>> + aka a1. Say Y if you want peripherals to work.
>>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>>> index 3939f21..6be3a8f 100644
>>> --- a/drivers/clk/meson/Makefile
>>> +++ b/drivers/clk/meson/Makefile
>>> @@ -19,3 +19,4 @@ obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
>>> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
>>> obj-$(CONFIG_COMMON_CLK_G12A) += g12a.o g12a-aoclk.o
>>> obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
>>> +obj-$(CONFIG_COMMON_CLK_A1) += a1.o
>>
>> I would guess this should be sorted on Kconfig name in this file?
> ok, I will put it behind COMMON_CLK_AXG_AUDIO
>>
>>> diff --git a/drivers/clk/meson/a1.c b/drivers/clk/meson/a1.c
>>> new file mode 100644
>>> index 0000000..26edae0f
>>> --- /dev/null
>>> +++ b/drivers/clk/meson/a1.c
>>> @@ -0,0 +1,2617 @@
>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>> +/*
>>> + * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
>>> + */
>>> +
>>> +#include <linux/clk-provider.h>
>>> +#include <linux/init.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/of_address.h>
>>> +#include "clk-mpll.h"
>>> +#include "clk-pll.h"
>>> +#include "clk-regmap.h"
>>> +#include "vid-pll-div.h"
>>> +#include "clk-dualdiv.h"
>>> +#include "meson-eeclk.h"
>>> +#include "a1.h"
>>> +
>> [...]
>>> +
>>> +/*
>>> + * The Meson A1 HIFI PLL is 614.4M, it requires
>>> + * a strict register sequence to enable the PLL.
>>> + * set meson_clk_pcie_pll_ops as its ops
>>
>> Please remove this last line as it's obvious from the code what ops are
>> used.
>>
> ok, I will remove it.
>>> + */
>>> +static struct clk_regmap a1_hifi_pll = {
>>> + .data = &(struct meson_clk_pll_data){
>>> + .en = {
>>> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
>>> + .shift = 28,
>>> + .width = 1,
>>> + },
>>> + .m = {
>>> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
>>> + .shift = 0,
>>> + .width = 8,
>>> + },
>>> + .n = {
>>> + .reg_off = ANACTRL_HIFIPLL_CTRL0,
>>> + .shift = 10,
>>> + .width = 5,
>>> + },
>>> + .frac = {
>>> + .reg_off = ANACTRL_HIFIPLL_CTRL1,
>>> + .shift = 0,
>>> + .width = 19,
>>> + },
>>> + .l = {
>>> + .reg_off = ANACTRL_HIFIPLL_STS,
>>> + .shift = 31,
>>> + .width = 1,
>>> + },
>>> + .table = a1_hifi_pll_params_table,
>>> + .init_regs = a1_hifi_init_regs,
>>> + .init_count = ARRAY_SIZE(a1_hifi_init_regs),
>>> + },
>>> + .hw.init = &(struct clk_init_data){
>>> + .name = "hifi_pll",
>>> + .ops = &meson_clk_pcie_pll_ops,
>>> + .parent_hws = (const struct clk_hw *[]) {
>>> + &a1_xtal_hifipll.hw
>>> + },
>>> + .num_parents = 1,
>>> + },
>>> +};
>>> +
>> [..]
>>> +
>>> +static struct clk_regmap a1_fclk_div2 = {
>>> + .data = &(struct clk_regmap_gate_data){
>>> + .offset = ANACTRL_FIXPLL_CTRL0,
>>> + .bit_idx = 21,
>>> + },
>>> + .hw.init = &(struct clk_init_data){
>>> + .name = "fclk_div2",
>>> + .ops = &clk_regmap_gate_ops,
>>> + .parent_hws = (const struct clk_hw *[]) {
>>> + &a1_fclk_div2_div.hw
>>> + },
>>> + .num_parents = 1,
>>> + /*
>>> + * add CLK_IS_CRITICAL flag to avoid being disabled by clk core
>>> + * or its children clocks.
>>
>> This comment is useless. Please replace it with an actual reason for
>> keeping the clk on instead of describing what the flag does.
>>
> ok, The actual reason is it should not change at runtime.
Yeah, from the flag we understand that you want to keep this on. What we
are after is why ? What device is using this clock and cannot tolerate
this gate to turn off ?
This is important and this is kind of comment we are after.
These flag should be viewed as "mid term work around". In the end, there
should be a driver for your device which claims the clock and properly
manage it
>>> + */
>>> + .flags = CLK_IS_CRITICAL,
>>> + },
>>> +};
>>> +
>> [..]
>>> +static struct clk_regmap a1_dmc = {
>>> + .data = &(struct clk_regmap_gate_data){
>>> + .offset = DMC_CLK_CTRL,
>>> + .bit_idx = 8,
>>> + },
>>> + .hw.init = &(struct clk_init_data) {
>>> + .name = "dmc",
>>> + .ops = &clk_regmap_gate_ops,
>>> + .parent_hws = (const struct clk_hw *[]) {
>>> + &a1_dmc_sel2.hw
>>> + },
>>> + .num_parents = 1,
>>> + /*
>>> + * add CLK_IGNORE_UNUSED to avoid hangup
>>> + * DDR clock should not change at runtime
>>> + */
>>> + .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
>>
>> So not CLK_IS_CRITICAL?
> Yes, CLK_IS_CRITICAL is better, I will change it.
Same comment as above.
>>
>>> + },
>>> +};
>>> +
>> [...]
>>> +
>>> +/*
>>> + * cpu clock register base address is 0xfd000080
>>> + */
>>> +static struct clk_regmap *const a1_cpu_clk_regmaps[] = {
>>> + /* TODO */
>>
>> Can it be done?
> I plan to compelte cpu clock with the DVFS verified. And Some peripheral
> devices rely on this patch to send. I prefer to do it in the next patch.
>>
>>> +};
>>
>> .
>>
_______________________________________________
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: dts: stm32: Enable high resolution timer
From: Marc Zyngier @ 2019-09-27 12:59 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: mark.rutland, devicetree, Alexandre TORGUE, linux-kernel, robh+dt,
linux-stm32, linux-arm-kernel
In-Reply-To: <69af57d1-13a9-9e35-78f2-4a0d17bdaf6d@st.com>
On 2019-09-27 13:44, Benjamin GAIGNARD wrote:
> On 9/27/19 2:41 PM, Marc Zyngier wrote:
>> On 2019-09-27 13:36, Benjamin GAIGNARD wrote:
>>> On 9/27/19 1:22 PM, Marc Zyngier wrote:
>>>> On 2019-09-27 09:48, Benjamin Gaignard wrote:
>>>>> Adding always-on makes arm arch_timer claim to be an high
>>>>> resolution
>>>>> timer.
>>>>> That is possible because power mode won't stop clocking the
>>>>> timer.
>>>>
>>>> The "always-on" is not about the clock. It is about the
>>>> comparator.
>>>> The clock itself is *guaranteed* to always tick. If it didn't,
>>>> that'd be
>>>> an integration bug, and a pretty bad one.
>>>>
>>>> What you're claiming here is that your CPU never enters a
>>>> low-power
>>>> mode?
>>>> Ever? I find this very hard to believe.
>>>>
>>>> Furthermore, claiming that always-on is the way to force the
>>>> arch-timer
>>>> to be an hrtimer is factually wrong. This is what happens *if*
>>>> this is
>>>> the only timer in the system. The only case this is true is for
>>>> virtual
>>>> machines. Anything else has a global timer somewhere that will
>>>> allow
>>>> the arch timers to be used as an hrtimer.
>>>>
>>>> I'm pretty sure you too have a global timer somewhere in your
>>>> system.
>>>> Enable it, and enjoy hrtimers without having to lie about the
>>>> properties
>>>> of your system! ;-)
>>>
>>> Hi Marc,
>>>
>>> This SoC doesn't have any other global timer. Use arch_time is the
>>> only
>>> we have to provide hrtimer on this system.
>>
>> And you don't have any form of power management either? What happens
>> when
>> your CPU goes into idle? If your system does any form of power
>> management
>> *and* doesn't have a separate timer, it is remarkably broken.
>
> Even in low-power modes this timer is always powered and clocked so
> it
> is working fine.
You're missing the point again. It is not about the clock, but the
comparator
that is internal to the CPU, and not functional when the CPU is in its
lowest
power mode. See also the verbiage in [1] (44.3 STGEN functional
description),
which indicates that the clock source actually dies in low-power mode
(going
against the architecture which mandates it to be always-on).
Also, coming back to your earlier assertion ("This SoC doesn't have any
other
global timer"): The documentation at [1] shows at least 17 timers that
could
be used and avoid this dirty hack.
So for what it is worth, NAK to this patch.
M.
[1] https://www.st.com/resource/en/reference_manual/dm00366355.pdf
--
Jazz is not dead. It just smells funny...
_______________________________________________
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: dts: stm32: Enable high resolution timer
From: Sudeep Holla @ 2019-09-27 12:59 UTC (permalink / raw)
To: Benjamin GAIGNARD
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
Alexandre TORGUE, Marc Zyngier, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <69af57d1-13a9-9e35-78f2-4a0d17bdaf6d@st.com>
On Fri, Sep 27, 2019 at 12:44:55PM +0000, Benjamin GAIGNARD wrote:
[...]
>
> Even in low-power modes this timer is always powered and clocked so it
> is working fine.
>
Is that tested ? I see only cpu_{on,off} available on this platform with
PSCI v0.1. Did you add cpu_suspend, idle-states and then gave it a spin ?
Or do you have some other idle driver with which this is tested ?
Also I don't understand how "always-on" is linked to hrtimer. Always on
timers are just selected to be broadcast timer without sacrificing(simply
keeping) a cpu to be always active for broadcast purposes.
--
Regards,
Sudeep
_______________________________________________
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] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y
From: Dmitry Vyukov @ 2019-09-27 13:07 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, linux-mediatek, LKML, kasan-dev, Linux-MM,
Alexander Potapenko, Matthias Brugger, Andrey Ryabinin, Linux ARM
In-Reply-To: <20190927034338.15813-1-walter-zh.wu@mediatek.com>
On Fri, Sep 27, 2019 at 5:43 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
>
> memmove() and memcpy() have missing underflow issues.
> When -7 <= size < 0, then KASAN will miss to catch the underflow issue.
> It looks like shadow start address and shadow end address is the same,
> so it does not actually check anything.
>
> The following test is indeed not caught by KASAN:
>
> char *p = kmalloc(64, GFP_KERNEL);
> memset((char *)p, 0, 64);
> memmove((char *)p, (char *)p + 4, -2);
> kfree((char*)p);
>
> It should be checked here:
>
> void *memmove(void *dest, const void *src, size_t len)
> {
> check_memory_region((unsigned long)src, len, false, _RET_IP_);
> check_memory_region((unsigned long)dest, len, true, _RET_IP_);
>
> return __memmove(dest, src, len);
> }
>
> We fix the shadow end address which is calculated, then generic KASAN
> get the right shadow end address and detect this underflow issue.
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=199341
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> ---
> lib/test_kasan.c | 36 ++++++++++++++++++++++++++++++++++++
> mm/kasan/generic.c | 8 ++++++--
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index b63b367a94e8..8bd014852556 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -280,6 +280,40 @@ static noinline void __init kmalloc_oob_in_memset(void)
> kfree(ptr);
> }
>
> +static noinline void __init kmalloc_oob_in_memmove_underflow(void)
> +{
> + char *ptr;
> + size_t size = 64;
> +
> + pr_info("underflow out-of-bounds in memmove\n");
> + ptr = kmalloc(size, GFP_KERNEL);
> + if (!ptr) {
> + pr_err("Allocation failed\n");
> + return;
> + }
> +
> + memset((char *)ptr, 0, 64);
> + memmove((char *)ptr, (char *)ptr + 4, -2);
> + kfree(ptr);
> +}
> +
> +static noinline void __init kmalloc_oob_in_memmove_overflow(void)
> +{
> + char *ptr;
> + size_t size = 64;
> +
> + pr_info("overflow out-of-bounds in memmove\n");
> + ptr = kmalloc(size, GFP_KERNEL);
> + if (!ptr) {
> + pr_err("Allocation failed\n");
> + return;
> + }
> +
> + memset((char *)ptr, 0, 64);
> + memmove((char *)ptr + size, (char *)ptr, 2);
> + kfree(ptr);
> +}
> +
> static noinline void __init kmalloc_uaf(void)
> {
> char *ptr;
> @@ -734,6 +768,8 @@ static int __init kmalloc_tests_init(void)
> kmalloc_oob_memset_4();
> kmalloc_oob_memset_8();
> kmalloc_oob_memset_16();
> + kmalloc_oob_in_memmove_underflow();
> + kmalloc_oob_in_memmove_overflow();
> kmalloc_uaf();
> kmalloc_uaf_memset();
> kmalloc_uaf2();
> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> index 616f9dd82d12..34ca23d59e67 100644
> --- a/mm/kasan/generic.c
> +++ b/mm/kasan/generic.c
> @@ -131,9 +131,13 @@ static __always_inline bool memory_is_poisoned_n(unsigned long addr,
> size_t size)
> {
> unsigned long ret;
> + void *shadow_start = kasan_mem_to_shadow((void *)addr);
> + void *shadow_end = kasan_mem_to_shadow((void *)addr + size - 1) + 1;
>
> - ret = memory_is_nonzero(kasan_mem_to_shadow((void *)addr),
> - kasan_mem_to_shadow((void *)addr + size - 1) + 1);
> + if ((long)size < 0)
> + shadow_end = kasan_mem_to_shadow((void *)addr + size);
Hi Walter,
Thanks for working on this.
If size<0, does it make sense to continue at all? We will still check
1PB of shadow memory? What happens when we pass such huge range to
memory_is_nonzero?
Perhaps it's better to produce an error and bail out immediately if size<0?
Also, what's the failure mode of the tests? Didn't they badly corrupt
memory? We tried to keep tests such that they produce the KASAN
reports, but don't badly corrupt memory b/c/ we need to run all of
them.
> + ret = memory_is_nonzero(shadow_start, shadow_end);
>
> if (unlikely(ret)) {
> unsigned long last_byte = addr + size - 1;
> --
> 2.18.0
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20190927034338.15813-1-walter-zh.wu%40mediatek.com.
_______________________________________________
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