* [PATCH 2/3] ARM: dts: NSP: Fix PCIe controllers interrupt types
From: Florian Fainelli @ 2018-06-11 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611224714.7007-1-f.fainelli@gmail.com>
The interrupts for the PCIe controllers should all be of type
IRQ_TYPE_LEVEL_HIGH instead of IRQ_TYPE_NONE.
Fixes: d71eb9412088 ("ARM: dts: NSP: Add MSI support on PCI")
Fixes: 522199029fdc ("ARM: dts: NSP: Fix PCIE DT issue")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index c6aa62386941..09ba85046322 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -496,7 +496,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 131 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <0>;
@@ -519,10 +519,10 @@
compatible = "brcm,iproc-msi";
msi-controller;
interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>,
- <GIC_SPI 128 IRQ_TYPE_NONE>,
- <GIC_SPI 129 IRQ_TYPE_NONE>,
- <GIC_SPI 130 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
brcm,pcie-msi-inten;
};
};
@@ -533,7 +533,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 137 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <1>;
@@ -556,10 +556,10 @@
compatible = "brcm,iproc-msi";
msi-controller;
interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 133 IRQ_TYPE_NONE>,
- <GIC_SPI 134 IRQ_TYPE_NONE>,
- <GIC_SPI 135 IRQ_TYPE_NONE>,
- <GIC_SPI 136 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
brcm,pcie-msi-inten;
};
};
@@ -570,7 +570,7 @@
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 143 IRQ_TYPE_NONE>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
linux,pci-domain = <2>;
@@ -593,10 +593,10 @@
compatible = "brcm,iproc-msi";
msi-controller;
interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 139 IRQ_TYPE_NONE>,
- <GIC_SPI 140 IRQ_TYPE_NONE>,
- <GIC_SPI 141 IRQ_TYPE_NONE>,
- <GIC_SPI 142 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
brcm,pcie-msi-inten;
};
};
--
2.14.1
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: NSP: Fix i2c controller interrupt type
From: Florian Fainelli @ 2018-06-11 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611224714.7007-1-f.fainelli@gmail.com>
The i2c controller should use IRQ_TYPE_LEVEL_HIGH instead of
IRQ_TYPE_NONE.
Fixes: 0f9f27a36d09 ("ARM: dts: NSP: Add I2C support to the DT")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index dcc55aa84583..c6aa62386941 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -391,7 +391,7 @@
reg = <0x38000 0x50>;
#address-cells = <1>;
#size-cells = <0>;
- interrupts = <GIC_SPI 89 IRQ_TYPE_NONE>;
+ interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
clock-frequency = <100000>;
dma-coherent;
status = "disabled";
--
2.14.1
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: IRQ_TYPE_NONE fixes for NSP and HR2
From: Florian Fainelli @ 2018-06-11 22:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This patch series fixes incorrect interrupt type specifiers for the
NSP and HR2 SoCs.
Florian Fainelli (3):
ARM: dts: NSP: Fix i2c controller interrupt type
ARM: dts: NSP: Fix PCIe controllers interrupt types
ARM: dts: HR2: Fix interrupt types for i2c and PCIe
arch/arm/boot/dts/bcm-hr2.dtsi | 24 ++++++++++++------------
arch/arm/boot/dts/bcm-nsp.dtsi | 32 ++++++++++++++++----------------
2 files changed, 28 insertions(+), 28 deletions(-)
--
2.14.1
^ permalink raw reply
* [PATCH 3/6] arm: dts: Change PCIe INTx mapping for Cygnus
From: Florian Fainelli @ 2018-06-11 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-4-git-send-email-ray.jui@broadcom.com>
On 05/29/2018 02:58 PM, Ray Jui wrote:
> Change the PCIe INTx mapping to model the 4 INTx interrupts in the
> IRQ domain of the iProc PCIe controller itself
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 699fdf9..6de21ef 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -254,9 +254,14 @@
> compatible = "brcm,iproc-pcie";
> reg = <0x18012000 0x1000>;
>
> + interrupt-controller;
> #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &pcie0 1>,
> + <0 0 0 2 &pcie0 2>,
> + <0 0 0 3 &pcie0 3>,
> + <0 0 0 4 &pcie0 4>;
> + interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
You would want to fix those IRQ_TYPE_NONE values as well because since
commit 83a86fbb5b56b5eed8a476cc3fe214077d7c4f49 ("irqchip/gic: Loudly
complain about the use of IRQ_TYPE_NONE") this is going to create some
nice warnings on boot.
I am about to send fixes for NSP and HR2 since that's what I have access
to at the moment, but it would be good if you could send updates to the
Cygnus and NS2 DTS files?
Thanks
>
> linux,pci-domain = <0>;
>
> @@ -289,9 +294,14 @@
> compatible = "brcm,iproc-pcie";
> reg = <0x18013000 0x1000>;
>
> + interrupt-controller;
> #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &pcie1 1>,
> + <0 0 0 2 &pcie1 2>,
> + <0 0 0 3 &pcie1 3>,
> + <0 0 0 4 &pcie1 4>;
> + interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
>
> linux,pci-domain = <1>;
>
>
--
Florian
^ permalink raw reply
* [PATCH 08/20] coresight: dts: Cleanup device tree graph bindings
From: Mathieu Poirier @ 2018-06-11 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0a213578-c7d7-0ed3-ffc1-afc97d8d1516@arm.com>
On 11 June 2018 at 10:55, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
> On 11/06/18 17:52, Mathieu Poirier wrote:
>>
>> On 11 June 2018 at 03:22, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
>>>
>>> On 08/06/18 22:22, Mathieu Poirier wrote:
>>>>
>>>>
>>>> On Tue, Jun 05, 2018 at 10:43:19PM +0100, Suzuki K Poulose wrote:
>>>>>
>>>>>
>>>>> The coresight drivers relied on default bindings for graph
>>>>> in DT, while reusing the "reg" field of the "ports" to indicate
>>>>> the actual hardware port number for the connections. However,
>>>>> with the rules getting stricter w.r.t to the address mismatch
>>>>> with the label, it is no longer possible to use the port address
>>>>> field for the hardware port number. Hence, we add an explicit
>>>>> property to denote the hardware port number, "coresight,hwid"
>>>>> which must be specified for each "endpoint".
>>>>>
>>>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>>> ---
>>>>> .../devicetree/bindings/arm/coresight.txt | 29
>>>>> ++++++++++---
>>>>> drivers/hwtracing/coresight/of_coresight.c | 49
>>>>> +++++++++++++++++-----
>>>>> 2 files changed, 62 insertions(+), 16 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
>>>>> b/Documentation/devicetree/bindings/arm/coresight.txt
>>>>> index ed6b555..bf75ab3 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>>>> @@ -108,8 +108,13 @@ following properties to uniquely identify the
>>>>> connection details.
>>>>> "slave-mode"
>>>
>>>
>>>
>>>
>>>>> };
>>>>
>>>>
>>>>
>>>> For the binding part:
>>>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
>
> ...
>
>>>>> @@ -140,9 +166,6 @@ static int of_coresight_parse_endpoint(struct
>>>>> device_node *ep,
>>>>> rparent = of_graph_get_port_parent(rep);
>>>>> if (!rparent)
>>>>> break;
>>>>> - if (of_graph_parse_endpoint(rep, &rendpoint))
>>>>> - break;
>>>>> -
>>>>> /* If the remote device is not available, defer
>>>>> probing
>>>>> */
>>>>> rdev = of_coresight_get_endpoint_device(rparent);
>>>>> if (!rdev) {
>>>>> @@ -150,9 +173,15 @@ static int of_coresight_parse_endpoint(struct
>>>>> device_node *ep,
>>>>> break;
>>>>> }
>>>>> - conn->outport = endpoint.port;
>>>>> + child_port = of_coresight_endpoint_get_port_id(rdev,
>>>>> rep);
>>>>> + if (child_port < 0) {
>>>>> + ret = 0;
>>>>
>>>>
>>>>
>>>> Why returning '0' on an error condition? Same for 'local_port' above.
>>>>
>>>
>>> If we are unable to parse a port, we can simply ignore the port and
>>> continue, which
>>> is what we have today with the existing code. I didn't change it and
>>> still
>>> think
>>> it is the best effort thing. We could spit a warning for such cases, if
>>> really needed.
>>> Also, the parsing code almost never fails at the moment. If it fails to
>>> find
>>> "reg" field,
>>> it is assumed to be '0'. Either way ignoring it seems harmless. That said
>>> I
>>> am open
>>> to suggestions.
>>
>>
>> Looking at the original code I remember not mandating enpoints to be
>> valid for debugging purposes. That certainly helps when building up a
>> device tree file but also has the side effect of silently overlooking
>> specification problems. Fortunately the revamping you did on that
>> part of the code makes it very easy to change that, something I think
>> we should take advantage of (it can only lead to positive scenarios
>> where defective specifications get pointed out).
>>
>> That being said and because the original behaviour is just as
>> permissive, you can leave as is.
>
>
> Thanks. So can I assume the Reviewed-by applies for the code now ?
Yes
>
> Suzuki
^ permalink raw reply
* [PATCH 2/2] ASoC: pxa: add devicetree support
From: Robert Jarzmik @ 2018-06-11 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611202211.15501-1-robert.jarzmik@free.fr>
Add the devicetree support, so that the driver can be used in a
devictree platform.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
sound/arm/pxa2xx-ac97-lib.c | 11 +++++++++++
sound/soc/pxa/pxa2xx-ac97.c | 10 ++++++++++
2 files changed, 21 insertions(+)
diff --git a/sound/arm/pxa2xx-ac97-lib.c b/sound/arm/pxa2xx-ac97-lib.c
index 5950a9e218d9..17c3f26b92b9 100644
--- a/sound/arm/pxa2xx-ac97-lib.c
+++ b/sound/arm/pxa2xx-ac97-lib.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/io.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <sound/pxa2xx-lib.h>
@@ -337,6 +338,16 @@ int pxa2xx_ac97_hw_probe(struct platform_device *dev)
dev_err(&dev->dev, "Invalid reset GPIO %d\n",
pdata->reset_gpio);
}
+ } else if (!pdata && dev->dev.of_node) {
+ pdata = devm_kzalloc(&dev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ pdata->reset_gpio = of_get_named_gpio(dev->dev.of_node,
+ "reset-gpio", 0);
+ if (pdata->reset_gpio == -ENOENT)
+ pdata->reset_gpio = -1;
+ else if (pdata->reset_gpio < 0)
+ return pdata->reset_gpio;
} else {
if (cpu_is_pxa27x())
reset_gpio = 113;
diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c
index bd36578ceb86..8fda29262ef1 100644
--- a/sound/soc/pxa/pxa2xx-ac97.c
+++ b/sound/soc/pxa/pxa2xx-ac97.c
@@ -231,6 +231,15 @@ static const struct snd_soc_component_driver pxa_ac97_component = {
.name = "pxa-ac97",
};
+#ifdef CONFIG_OF
+static const struct of_device_id pxa2xx_ac97_dt_ids[] = {
+ { .compatible = "marvell,pxa2xx-ac97", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pxa2xx_ac97_dt_ids);
+
+#endif
+
static int pxa2xx_ac97_dev_probe(struct platform_device *pdev)
{
int ret;
@@ -298,6 +307,7 @@ static struct platform_driver pxa2xx_ac97_driver = {
#ifdef CONFIG_PM_SLEEP
.pm = &pxa2xx_ac97_pm_ops,
#endif
+ .of_match_table = of_match_ptr(pxa2xx_ac97_dt_ids),
},
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] ASoC: pxa: add binding for pxa2xx-ac97 audio complex
From: Robert Jarzmik @ 2018-06-11 20:22 UTC (permalink / raw)
To: linux-arm-kernel
This adds a binding for the Marvell PXA audio complex, available in
pxa2xx and pxa3xx variants.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
.../bindings/sound/marvell,pxa2xx-ac97.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
diff --git a/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
new file mode 100644
index 000000000000..b3f2882d9c7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
@@ -0,0 +1,25 @@
+Marvell PXA2xx audio complex
+
+This descriptions matches the AC97 controller found in pxa2xx and pxa3xx series.
+
+Required properties:
+ - compatible: "marvell,pxa2xx-ac97"
+ - reg: device MMIO address space
+ - interrupts: single interrupt generated by AC97 IP
+ - clocks: input clock of the AC97 IP, refer to clock-bindings.txt
+
+Optional properties:
+ - pinctrl-names, pinctrl-0: refer to pinctrl-bindings.txt
+ - reset-gpio: gpio used for AC97 reset, refer to gpio.txt
+
+Example:
+ ac97: sound at 40500000 {
+ compatible = "marvell,pxa2xx-ac97";
+ reg = < 0x40500000 0x1000 >;
+ interrupts = <14>;
+ reset-gpio = <&gpio 113 GPIO_ACTIVE_HIGH>;
+ #sound-dai-cells = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = < &pmux_ac97_default >;
+ status = "okay";
+ };
--
2.11.0
^ permalink raw reply related
* [RESEND v2] dmaengine: pxa: add a default requestor policy
From: Robert Jarzmik @ 2018-06-11 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611042125.GD2452@vkoul-mobl>
Vinod Koul <vinod.koul@linaro.org> writes:
> On 09-06-18, 14:43, Robert Jarzmik wrote:
>> Robert Jarzmik <robert.jarzmik@free.fr> writes:
>>
>> > As what former drcmr -1 value meant, add a this as a default to each
>> > channel, ie. that by default no requestor line is used.
>> >
>> > This is specifically used for network drivers smc91x and smc911x, and
>> > needed for their port to slave maps.
>> >
>> > Cc: Arnd Bergmann <arnd@arndb.de>
>> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> > ---
>> > Since v1: changed -1 to U32_MAX
>> Hi Vinod,
>>
>> Could I have your ack on this so that I add this one to the dma slave map serie
>> after the merge window is closed please ?
>
> Sorry I was thinking it would go thru dmaengine tree, please do
> indicate if that is not the case. Nevertheless
>
> Acked-by: Vinod Koul <vkoul@kernel.org>
Thanks.
As this is a dependency to the serie, I'd rather take it, unless you insist, in
which case I'll rely on the fact that it will hit 4.19 cycle.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 1/1] ARM: dts: s5pv210: Add missing interrupt-controller property to gph2
From: Paweł Chmiel @ 2018-06-11 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPcVqaeYoU=tht5GSyEunnboG-+Mxo96LCDewbqDjCfy-A@mail.gmail.com>
On Monday, June 11, 2018 2:43:59 PM CEST Krzysztof Kozlowski wrote:
> On Sun, Jun 10, 2018 at 4:15 PM, Pawe? Chmiel
> <pawel.mikolaj.chmiel@gmail.com> wrote:
> > This commit adds missing interrupt-controller property to gph2 block,
>
> Just "Add missing". See:
> https://elixir.bootlin.com/linux/latest/source/Documentation/process/submitting-patches.rst#L151
>
> > to silence following warnings during build
> > /soc/pinctrl at e0200000/gph2: Missing interrupt-controller or interrupt-map property
> >
> > Observed on not yet mainlined, an S5PV210 based
> > Samsung Galaxy S (i9000) phone.
>
> The warning is not reproduceable (as you mentioned board is not
> present in mainline) thus please skip it. Instead, either describe
> existing reason for this change (e.g. because bindings require it for
> node of every bank of pins supporting GPIO interrupts) or include this
> in series mainlining new board (where the reason will be - it will be
> used by new board etc).
>
> Best regards,
> Krzysztof
>
Ok, I'll send this patch (fixed) with other patches adding new board.
Thanks
^ permalink raw reply
* [v3, 03/10] dt-binding: ptp_qoriq: add DPAA FMan support
From: Rob Herring @ 2018-06-11 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607092050.46128-4-yangbo.lu@nxp.com>
On Thu, Jun 07, 2018 at 05:20:43PM +0800, Yangbo Lu wrote:
> This patch is to add bindings description for DPAA
> FMan 1588 timer, and also remove its description in
> fsl-fman dt-bindings document.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> Changes for v2:
> - None.
> Changes for v3:
> - None.
> ---
> Documentation/devicetree/bindings/net/fsl-fman.txt | 25 +-------------------
> .../devicetree/bindings/ptp/ptp-qoriq.txt | 15 +++++++++--
> 2 files changed, 13 insertions(+), 27 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 2/6] clk: ti: dra7: Add clkctrl clock data for the mcan clocks
From: Rob Herring @ 2018-06-11 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606060826.14671-3-faiz_abbas@ti.com>
On Wed, Jun 06, 2018 at 11:38:22AM +0530, Faiz Abbas wrote:
> Add clkctrl data for the m_can clocks and register it within the
> clkctrl driver
>
> CC: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> drivers/clk/ti/clk-7xx.c | 1 +
> include/dt-bindings/clock/dra7.h | 1 +
Acked-by: Rob Herring <robh@kernel.org>
> 2 files changed, 2 insertions(+)
>
^ permalink raw reply
* [PATCH v3 3/4] dt-bindings: soc: Add TmFifo binding for Mellanox BlueField SoC
From: Rob Herring @ 2018-06-11 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527863467-45472-3-git-send-email-lsun@mellanox.com>
On Fri, Jun 01, 2018 at 10:31:06AM -0400, Liming Sun wrote:
> Add devicetree bindings for the TmFifo which is found on Mellanox
> BlueField SoCs.
>
> Reviewed-by: David Woods <dwoods@mellanox.com>
> Signed-off-by: Liming Sun <lsun@mellanox.com>
> ---
> .../devicetree/bindings/soc/mellanox/tmfifo.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/mellanox/tmfifo.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v6 3/5] dt-bindings: timer: add i.MX EPIT timer binding
From: Rob Herring @ 2018-06-11 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607140544.22268-4-peron.clem@gmail.com>
On Thu, Jun 07, 2018 at 04:05:42PM +0200, Cl?ment P?ron wrote:
> From: Cl?ment Peron <clement.peron@devialet.com>
>
> Add devicetree binding document for NXP's i.MX SoC specific
> EPIT timer driver.
>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
> .../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v1] ARM: imx: add imx7d-m4
From: Oleksij Rempel @ 2018-06-11 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <610391dc49d481debe1c71bd3070c73b@agner.ch>
On Mon, Jun 11, 2018 at 02:41:29PM +0200, Stefan Agner wrote:
> On 11.06.2018 13:53, Oleksij Rempel wrote:
> > On 11.06.2018 13:48, Stefan Agner wrote:
> >> On 11.06.2018 10:35, Lucas Stach wrote:
> >>> Hi Shawn,
> >>>
> >>> Am Montag, den 11.06.2018, 16:20 +0800 schrieb Shawn Guo:
> >>>> On Mon, Jun 11, 2018 at 10:02:53AM +0200, Oleksij Rempel wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> this patch was send 05.04.2018. Any comments?
> >>>>>
> >>>>> @Shawn, can you please take it?
> >>>>
> >>>> Honestly I'm not sure how useful it will be.??If we can have some i.MX
> >>>> developers ACK on it, I will be more comfortable to take it.
> >>>
> >>> This is all highly experimental and in PoC stage, but we see some value
> >>> in running a second Linux system on the M4 coprocessor. There are lots
> >>> of things that still need to be figured out, but we are working on this
> >>> from time to time when there are some hours to spare.
> >>>
> >>> This patch seems like a good step in the right direction and IMHO the
> >>> amount of code and changes is small enough to carry it upstream without
> >>> impacting anything else. I would be happy if this could be pulled in.
> >>
> >> I agree with Lucas here, this is rather minimal and not invasive.
> >>
> >>
> >> Out of interest, on what memory region do you run Linux? Do you use
> >> caches? In some experiments a while ago I noticed that only 2MiB/(or
> >> 4MiB) of DDR memory can use caches, which is somewhat tight to run Linux
> >> on.
> >>
> >> https://blog.printk.io/2017/05/i-mx-7-cortex-m4-memory-locations-and-performance/
> >
> > here is DT part for master system on Cortex A7 to run Linux on Cortex M4:
> >
> > memory {
> > device_type = "memory";
> > reg = <0x80000000 0x40000000>;
> > };
> >
> > reserved-memory {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges;
> >
> > m4_reserved_sysmem1: rproc at 88000000 {
> > reg = <0x88000000 0x4000000>;
> > no-map;
> > };
>
> So I guess that is where Linux on the M4 goes? Afaik this is in the
> uncacheable area, so it is rather slow?
I didn't made any performance optimization or comparison.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180611/ccc21651/attachment.sig>
^ permalink raw reply
* [PATCH] net: stmmac: dwmac-meson8b: Fix an error handling path in 'meson8b_dwmac_probe()'
From: Christophe JAILLET @ 2018-06-11 17:52 UTC (permalink / raw)
To: linux-arm-kernel
If 'of_device_get_match_data()' fails, we need to release some resources as
done in the other error handling path of this function.
Fixes: efacb568c962 ("net: stmmac: dwmac-meson: extend phy mode setting")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 4ff231df7322..c5979569fd60 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -334,9 +334,10 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
dwmac->data = (const struct meson8b_dwmac_data *)
of_device_get_match_data(&pdev->dev);
- if (!dwmac->data)
- return -EINVAL;
-
+ if (!dwmac->data) {
+ ret = -EINVAL;
+ goto err_remove_config_dt;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
dwmac->regs = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(dwmac->regs)) {
--
2.17.0
^ permalink raw reply related
* A72 access to cache syndrome registers (arm64)
From: Joe Dougherty @ 2018-06-11 17:21 UTC (permalink / raw)
To: linux-arm-kernel
Hello -
Is there any current support for reading "CPU Memory Error Syndrome"
and L2 Memory Error Syndrome" registers from userspace? I am
monitoring for particular cache related events. I'm trying to avoid
writing a kernel module but it looks like that may be my only option
as I am not seeing support for access to these registers. Would a perf
driver be more appropriate? Any advice/input appreciated.
My Linux kernel is 4.14 but I could adjust is support is available elsewhere.
Thanks,
Joe
^ permalink raw reply
* [PATCH v7 2/2] regulator: add QCOM RPMh regulator driver
From: Matthias Kaehlcke @ 2018-06-11 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <36e91ad9edeeee2adfe7a4d92675a1d6950f5002.1528498807.git.collinsd@codeaurora.org>
On Fri, Jun 08, 2018 at 04:44:15PM -0700, David Collins wrote:
> Add the QCOM RPMh regulator driver to manage PMIC regulators
> which are controlled via RPMh on some Qualcomm Technologies, Inc.
> SoCs. RPMh is a hardware block which contains several
> accelerators which are used to manage various hardware resources
> that are shared between the processors of the SoC. The final
> hardware state of a regulator is determined within RPMh by
> performing max aggregation of the requests made by all of the
> processors.
>
> Add support for PMIC regulator control via the voltage regulator
> manager (VRM) and oscillator buffer (XOB) RPMh accelerators.
> VRM supports manipulation of enable state, voltage, and mode.
> XOB supports manipulation of enable state.
>
> Signed-off-by: David Collins <collinsd@codeaurora.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/qcom-rpmh-regulator.c | 753 ++++++++++++++++++++++++++++++++
> 3 files changed, 763 insertions(+)
> create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
^ permalink raw reply
* [PATCH 08/20] coresight: dts: Cleanup device tree graph bindings
From: Suzuki K Poulose @ 2018-06-11 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkwGmUpHKRZYJ=pGbEKOAGT6O=+u0_mpAJOyoONuqpXO4g@mail.gmail.com>
On 11/06/18 17:52, Mathieu Poirier wrote:
> On 11 June 2018 at 03:22, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
>> On 08/06/18 22:22, Mathieu Poirier wrote:
>>>
>>> On Tue, Jun 05, 2018 at 10:43:19PM +0100, Suzuki K Poulose wrote:
>>>>
>>>> The coresight drivers relied on default bindings for graph
>>>> in DT, while reusing the "reg" field of the "ports" to indicate
>>>> the actual hardware port number for the connections. However,
>>>> with the rules getting stricter w.r.t to the address mismatch
>>>> with the label, it is no longer possible to use the port address
>>>> field for the hardware port number. Hence, we add an explicit
>>>> property to denote the hardware port number, "coresight,hwid"
>>>> which must be specified for each "endpoint".
>>>>
>>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>> .../devicetree/bindings/arm/coresight.txt | 29 ++++++++++---
>>>> drivers/hwtracing/coresight/of_coresight.c | 49
>>>> +++++++++++++++++-----
>>>> 2 files changed, 62 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
>>>> b/Documentation/devicetree/bindings/arm/coresight.txt
>>>> index ed6b555..bf75ab3 100644
>>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>>> @@ -108,8 +108,13 @@ following properties to uniquely identify the
>>>> connection details.
>>>> "slave-mode"
>>
>>
>>
>>>> };
>>>
>>>
>>> For the binding part:
>>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
...
>>>> @@ -140,9 +166,6 @@ static int of_coresight_parse_endpoint(struct
>>>> device_node *ep,
>>>> rparent = of_graph_get_port_parent(rep);
>>>> if (!rparent)
>>>> break;
>>>> - if (of_graph_parse_endpoint(rep, &rendpoint))
>>>> - break;
>>>> -
>>>> /* If the remote device is not available, defer probing
>>>> */
>>>> rdev = of_coresight_get_endpoint_device(rparent);
>>>> if (!rdev) {
>>>> @@ -150,9 +173,15 @@ static int of_coresight_parse_endpoint(struct
>>>> device_node *ep,
>>>> break;
>>>> }
>>>> - conn->outport = endpoint.port;
>>>> + child_port = of_coresight_endpoint_get_port_id(rdev,
>>>> rep);
>>>> + if (child_port < 0) {
>>>> + ret = 0;
>>>
>>>
>>> Why returning '0' on an error condition? Same for 'local_port' above.
>>>
>>
>> If we are unable to parse a port, we can simply ignore the port and
>> continue, which
>> is what we have today with the existing code. I didn't change it and still
>> think
>> it is the best effort thing. We could spit a warning for such cases, if
>> really needed.
>> Also, the parsing code almost never fails at the moment. If it fails to find
>> "reg" field,
>> it is assumed to be '0'. Either way ignoring it seems harmless. That said I
>> am open
>> to suggestions.
>
> Looking at the original code I remember not mandating enpoints to be
> valid for debugging purposes. That certainly helps when building up a
> device tree file but also has the side effect of silently overlooking
> specification problems. Fortunately the revamping you did on that
> part of the code makes it very easy to change that, something I think
> we should take advantage of (it can only lead to positive scenarios
> where defective specifications get pointed out).
>
> That being said and because the original behaviour is just as
> permissive, you can leave as is.
Thanks. So can I assume the Reviewed-by applies for the code now ?
Suzuki
^ permalink raw reply
* [PATCH] drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()'
From: Christophe JAILLET @ 2018-06-11 16:53 UTC (permalink / raw)
To: linux-arm-kernel
If 'platform_get_resource_byname()' fails, we should release some resources
before leaving, as already done in the other error handling path of the
function.
Fixes: acaa3f13b8dd ("drm/meson: Fix potential NULL dereference in meson_drv_bind_master()")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/gpu/drm/meson/meson_drv.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
index 32b1a6cdecfc..d3443125e661 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -197,8 +197,10 @@ static int meson_drv_bind_master(struct device *dev, bool has_components)
priv->io_base = regs;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hhi");
- if (!res)
- return -EINVAL;
+ if (!res) {
+ ret = -EINVAL;
+ goto free_drm;
+ }
/* Simply ioremap since it may be a shared register zone */
regs = devm_ioremap(dev, res->start, resource_size(res));
if (!regs) {
@@ -215,8 +217,10 @@ static int meson_drv_bind_master(struct device *dev, bool has_components)
}
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dmc");
- if (!res)
- return -EINVAL;
+ if (!res) {
+ ret = -EINVAL;
+ goto free_drm;
+ }
/* Simply ioremap since it may be a shared register zone */
regs = devm_ioremap(dev, res->start, resource_size(res));
if (!regs) {
--
2.17.0
^ permalink raw reply related
* [PATCH 08/20] coresight: dts: Cleanup device tree graph bindings
From: Mathieu Poirier @ 2018-06-11 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f616c825-b459-397d-3e61-70c1f1790f4f@arm.com>
On 11 June 2018 at 03:22, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
> On 08/06/18 22:22, Mathieu Poirier wrote:
>>
>> On Tue, Jun 05, 2018 at 10:43:19PM +0100, Suzuki K Poulose wrote:
>>>
>>> The coresight drivers relied on default bindings for graph
>>> in DT, while reusing the "reg" field of the "ports" to indicate
>>> the actual hardware port number for the connections. However,
>>> with the rules getting stricter w.r.t to the address mismatch
>>> with the label, it is no longer possible to use the port address
>>> field for the hardware port number. Hence, we add an explicit
>>> property to denote the hardware port number, "coresight,hwid"
>>> which must be specified for each "endpoint".
>>>
>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> ---
>>> .../devicetree/bindings/arm/coresight.txt | 29 ++++++++++---
>>> drivers/hwtracing/coresight/of_coresight.c | 49
>>> +++++++++++++++++-----
>>> 2 files changed, 62 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
>>> b/Documentation/devicetree/bindings/arm/coresight.txt
>>> index ed6b555..bf75ab3 100644
>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>> @@ -108,8 +108,13 @@ following properties to uniquely identify the
>>> connection details.
>>> "slave-mode"
>
>
>
>>> };
>>
>>
>> For the binding part:
>> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>
>>> diff --git a/drivers/hwtracing/coresight/of_coresight.c
>>> b/drivers/hwtracing/coresight/of_coresight.c
>>> index d01a9ce..d23d7dd 100644
>>> --- a/drivers/hwtracing/coresight/of_coresight.c
>>> +++ b/drivers/hwtracing/coresight/of_coresight.c
>
>
> ...
>
>>> +/*
>>> * of_coresight_parse_endpoint : Parse the given output endpoint @ep
>>> * and fill the connection information in *@pconn.
>>> *
>>> @@ -109,11 +134,11 @@ EXPORT_SYMBOL_GPL(of_coresight_get_cpu);
>>> * 0 - If the parsing completed without any fatal errors.
>
>
> Please note the return value description here. Further comments below.
>
>>> * -Errno - Fatal error, abort the scanning.
>>> */
>>> -static int of_coresight_parse_endpoint(struct device_node *ep,
>>> +static int of_coresight_parse_endpoint(struct device *dev,
>>> + struct device_node *ep,
>>> struct coresight_connection
>>> **pconn)
>>> {
>>> - int ret = 0;
>>> - struct of_endpoint endpoint, rendpoint;
>>> + int ret = 0, local_port, child_port;
>>> struct device_node *rparent = NULL;
>>> struct device_node *rep = NULL;
>>> struct device *rdev = NULL;
>>> @@ -128,7 +153,8 @@ static int of_coresight_parse_endpoint(struct
>>> device_node *ep,
>>> break;
>>> /* Parse the local port details */
>>> - if (of_graph_parse_endpoint(ep, &endpoint))
>>> + local_port = of_coresight_endpoint_get_port_id(dev, ep);
>>> + if (local_port < 0)
>>> break;
>>> /*
>>> * Get a handle on the remote endpoint and the device it
>>> is
>>> @@ -140,9 +166,6 @@ static int of_coresight_parse_endpoint(struct
>>> device_node *ep,
>>> rparent = of_graph_get_port_parent(rep);
>>> if (!rparent)
>>> break;
>>> - if (of_graph_parse_endpoint(rep, &rendpoint))
>>> - break;
>>> -
>>> /* If the remote device is not available, defer probing
>>> */
>>> rdev = of_coresight_get_endpoint_device(rparent);
>>> if (!rdev) {
>>> @@ -150,9 +173,15 @@ static int of_coresight_parse_endpoint(struct
>>> device_node *ep,
>>> break;
>>> }
>>> - conn->outport = endpoint.port;
>>> + child_port = of_coresight_endpoint_get_port_id(rdev,
>>> rep);
>>> + if (child_port < 0) {
>>> + ret = 0;
>>
>>
>> Why returning '0' on an error condition? Same for 'local_port' above.
>>
>
> If we are unable to parse a port, we can simply ignore the port and
> continue, which
> is what we have today with the existing code. I didn't change it and still
> think
> it is the best effort thing. We could spit a warning for such cases, if
> really needed.
> Also, the parsing code almost never fails at the moment. If it fails to find
> "reg" field,
> it is assumed to be '0'. Either way ignoring it seems harmless. That said I
> am open
> to suggestions.
Looking at the original code I remember not mandating enpoints to be
valid for debugging purposes. That certainly helps when building up a
device tree file but also has the side effect of silently overlooking
specification problems. Fortunately the revamping you did on that
part of the code makes it very easy to change that, something I think
we should take advantage of (it can only lead to positive scenarios
where defective specifications get pointed out).
That being said and because the original behaviour is just as
permissive, you can leave as is.
Thanks,
Mathieu
>
> Cheers
> Suzuki
^ permalink raw reply
* [PATCH v2 03/40] iommu/sva: Manage process address spaces
From: Kenneth Lee @ 2018-06-11 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525093959.000040a7@huawei.com>
On Fri, May 25, 2018 at 09:39:59AM +0100, Jonathan Cameron wrote:
> Date: Fri, 25 May 2018 09:39:59 +0100
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> CC: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
> "xieyisheng1 at huawei.com" <xieyisheng1@huawei.com>, "kvm at vger.kernel.org"
> <kvm@vger.kernel.org>, "linux-pci at vger.kernel.org"
> <linux-pci@vger.kernel.org>, "xuzaibo at huawei.com" <xuzaibo@huawei.com>,
> Will Deacon <Will.Deacon@arm.com>, "okaya at codeaurora.org"
> <okaya@codeaurora.org>, "linux-mm at kvack.org" <linux-mm@kvack.org>,
> "yi.l.liu at intel.com" <yi.l.liu@intel.com>, "ashok.raj at intel.com"
> <ashok.raj@intel.com>, "tn at semihalf.com" <tn@semihalf.com>,
> "joro at 8bytes.org" <joro@8bytes.org>, "robdclark at gmail.com"
> <robdclark@gmail.com>, "bharatku at xilinx.com" <bharatku@xilinx.com>,
> "linux-acpi at vger.kernel.org" <linux-acpi@vger.kernel.org>,
> "liudongdong3 at huawei.com" <liudongdong3@huawei.com>, "rfranz at cavium.com"
> <rfranz@cavium.com>, "devicetree at vger.kernel.org"
> <devicetree@vger.kernel.org>, "kevin.tian at intel.com"
> <kevin.tian@intel.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>,
> "alex.williamson at redhat.com" <alex.williamson@redhat.com>,
> "rgummal at xilinx.com" <rgummal@xilinx.com>, "thunder.leizhen at huawei.com"
> <thunder.leizhen@huawei.com>, "linux-arm-kernel at lists.infradead.org"
> <linux-arm-kernel@lists.infradead.org>, "shunyong.yang at hxt-semitech.com"
> <shunyong.yang@hxt-semitech.com>, "dwmw2 at infradead.org"
> <dwmw2@infradead.org>, "liubo95 at huawei.com" <liubo95@huawei.com>,
> "jcrouse at codeaurora.org" <jcrouse@codeaurora.org>,
> "iommu at lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
> Robin Murphy <Robin.Murphy@arm.com>, "christian.koenig at amd.com"
> <christian.koenig@amd.com>, "nwatters at codeaurora.org"
> <nwatters@codeaurora.org>, "baolu.lu at linux.intel.com"
> <baolu.lu@linux.intel.com>, liguozhu at hisilicon.com,
> kenneth-lee-2012 at foxmail.com
> Subject: Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces
> Message-ID: <20180525093959.000040a7@huawei.com>
> Organization: Huawei
> X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; x86_64-w64-mingw32)
>
> +CC Kenneth Lee
>
> On Fri, 25 May 2018 09:33:11 +0300
> Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
>
> > On Thu, May 24, 2018 at 04:04:39PM +0100, Jean-Philippe Brucker wrote:
> > > On 24/05/18 12:50, Ilias Apalodimas wrote:
> > > >> Interesting, I hadn't thought about this use-case before. At first I
> > > >> thought you were talking about mdev devices assigned to VMs, but I think
> > > >> you're referring to mdevs assigned to userspace drivers instead? Out of
> > > >> curiosity, is it only theoretical or does someone actually need this?
> > > >
> > > > There has been some non upstreamed efforts to have mdev and produce userspace
> > > > drivers. Huawei is using it on what they call "wrapdrive" for crypto devices and
> > > > we did a proof of concept for ethernet interfaces. At the time we choose not to
> > > > involve the IOMMU for the reason you mentioned, but having it there would be
> > > > good.
> > >
> > > I'm guessing there were good reasons to do it that way but I wonder, is
> > > it not simpler to just have the kernel driver create a /dev/foo, with a
> > > standard ioctl/mmap/poll interface? Here VFIO adds a layer of
> > > indirection, and since the mediating driver has to implement these
> > > operations already, what is gained?
> > The best reason i can come up with is "common code". You already have one API
> > doing that for you so we replicate it in a /dev file?
> > The mdev approach still needs extentions to support what we tried to do (i.e
> > mdev bus might need yo have access on iommu_ops), but as far as i undestand it's
> > a possible case.
Hi, Jean, Please allow me to share my understanding here:
https://zhuanlan.zhihu.com/p/35489035
The reason we do not use the /dev/foo scheme is that the devices to be
shared are programmable accelerators. We cannot fix up the kernel driver for
them.
> > >
> > > Thanks,
> > > Jean
>
>
(p.s. I sent this mail on May 26 from my public email count. But it
seems the email server is blocked. I resent it from my company count until my
colleague told me just now. Sorry for inconvenience)
--
-Kenneth(Hisilicon)
^ permalink raw reply
* [PATCH v2 5/5] arm64: perf: Add support for chaining event counters
From: Suzuki K Poulose @ 2018-06-11 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611142431.4svc26y27scgzfcg@lakrids.cambridge.arm.com>
On 11/06/18 15:24, Mark Rutland wrote:
> On Mon, Jun 11, 2018 at 02:54:16PM +0100, Suzuki K Poulose wrote:
>> On 08/06/18 15:46, Suzuki K Poulose wrote:
>>> On 06/06/2018 07:01 PM, Mark Rutland wrote:
>>>> On Tue, May 29, 2018 at 11:55:56AM +0100, Suzuki K Poulose wrote:
>>
>>>>> -??????? value |= 0xffffffff00000000ULL;
>>>>> +??????? if (!armv8pmu_event_is_64bit(event))
>>>>> +??????????? value |= 0xffffffff00000000ULL;
>>>>> ????????? write_sysreg(value, pmccntr_el0);
>>>>> -??? } else if (armv8pmu_select_counter(idx) == idx)
>>>>> -??????? write_sysreg(value, pmxevcntr_el0);
>>>>> +??? } else
>>>>> +??????? armv8pmu_write_hw_counter(event, value);
>>>>> ? }
>>>>
>>>>> +static inline void armv8pmu_write_event_type(struct perf_event *event)
>>>>> +{
>>>>> +??? struct hw_perf_event *hwc = &event->hw;
>>>>> +??? int idx = hwc->idx;
>>>>> +
>>>>> +??? /*
>>>>> +???? * For chained events, write the the low counter event type
>>>>> +???? * followed by the high counter. The high counter is programmed
>>>>> +???? * with CHAIN event code with filters set to count at all ELs.
>>>>> +???? */
>>>>> +??? if (armv8pmu_event_is_chained(event)) {
>>>>> +??????? u32 chain_evt = ARMV8_PMUV3_PERFCTR_CHAIN |
>>>>> +??????????????? ARMV8_PMU_INCLUDE_EL2;
>>>>> +
>>>>> +??????? armv8pmu_write_evtype(idx - 1, hwc->config_base);
>>>>> +??????? isb();
>>>>> +??????? armv8pmu_write_evtype(idx, chain_evt);
>>>>
>>>> The ISB isn't necessary here, AFAICT. We only do this while the PMU is
>>>> disabled; no?
>>>
>>> You're right. I was just following the ARM ARM.
>>
>> Taking another look, it is not clear about the semantics of "pmu->enable()"
>> and pmu->disable() callbacks.
>
> I was talking about pmu::{pmu_disable,pmu_enable}(), so I'm not sure I
> follow how arm_pmu::{enable,disable}() are relevant here.>
> The arm_pmu::{enable,disable}() callbacks enable or disable individual
> counters. For example, leaving unused counters disabled may save power,
> even if the PMU as a whole is enabled.
Ah, I mistook cpu_pmu->enable/disable for the core pmu ops. My bad.
Sorry about the noise.
Suzuki
^ permalink raw reply
* [PATCH] arm/twd: avoid waking deeply sleeping CPUs for rate change notifier
From: Lucas Stach @ 2018-06-11 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180417104627.29643-1-l.stach@pengutronix.de>
Hi all,
Am Dienstag, den 17.04.2018, 12:46 +0200 schrieb Lucas Stach:
> The current clock notifier sends an IPI to all CPUs, even if they are in
> deep sleep state with the local timer disabled and switched to tick
> broadcast. This needlessly cuts the CPU sleep times, as nothing is gained
> from updating a disabled TWDs rate.
>
> Keep track of the enabled TWDs and only send an IPI to those CPUs with an
> active local timer. As disabled TWDs may now miss a CPU frequency update
> we need to make sure to refresh the rate on re-enabling of the timer.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
I would appreciate some feedback to this patch.
FWIW, I've been running some systems with this patch applied for quite
some time now with no issues spotted so far.
Regards,
Lucas
> ---
> ?arch/arm/kernel/smp_twd.c | 31 +++++++++++++++++++++++++++++--
> ?1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index b30eafeef096..a3be30d30cc2 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -32,6 +32,8 @@ static struct clk *twd_clk;
> ?static unsigned long twd_timer_rate;
> ?static DEFINE_PER_CPU(bool, percpu_setup_called);
> ?
> +static cpumask_var_t active_twd_mask;
> +
> ?static struct clock_event_device __percpu *twd_evt;
> ?static unsigned int twd_features =
> > ? CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
> @@ -39,12 +41,24 @@ static int twd_ppi;
> ?
> ?static int twd_shutdown(struct clock_event_device *clk)
> ?{
> > + cpumask_clear_cpu(smp_processor_id(), active_twd_mask);
> +
> > ? writel_relaxed(0, twd_base + TWD_TIMER_CONTROL);
> > ? return 0;
> ?}
> ?
> ?static int twd_set_oneshot(struct clock_event_device *clk)
> ?{
> > + cpumask_set_cpu(smp_processor_id(), active_twd_mask);
> +
> > + /*
> > + ?* When going from shutdown to oneshot we might have missed some
> > + ?* frequency updates if the CPU was sleeping. Make sure to update
> > + ?* the timer frequency with the current rate.
> > + ?*/
> > + if (clockevent_state_shutdown(clk))
> > + clockevents_update_freq(clk, twd_timer_rate);
> +
> > ? /* period set, and timer enabled in 'next_event' hook */
> > ? writel_relaxed(TWD_TIMER_CONTROL_IT_ENABLE | TWD_TIMER_CONTROL_ONESHOT,
> > ? ???????twd_base + TWD_TIMER_CONTROL);
> @@ -57,6 +71,16 @@ static int twd_set_periodic(struct clock_event_device *clk)
> > ? ?????TWD_TIMER_CONTROL_IT_ENABLE |
> > ? ?????TWD_TIMER_CONTROL_PERIODIC;
> ?
> > + cpumask_set_cpu(smp_processor_id(), active_twd_mask);
> +
> > + /*
> > + ?* When going from shutdown to periodic we might have missed some
> > + ?* frequency updates if the CPU was sleeping. Make sure to update
> > + ?* the timer frequency with the current rate.
> > + ?*/
> > + if (clockevent_state_shutdown(clk))
> > + clockevents_update_freq(clk, twd_timer_rate);
> +
> > ? writel_relaxed(DIV_ROUND_CLOSEST(twd_timer_rate, HZ),
> > ? ???????twd_base + TWD_TIMER_LOAD);
> > ? writel_relaxed(ctrl, twd_base + TWD_TIMER_CONTROL);
> @@ -124,8 +148,8 @@ static int twd_rate_change(struct notifier_block *nb,
> > ? ?* changing cpu.
> > ? ?*/
> > ? if (flags == POST_RATE_CHANGE)
> > - on_each_cpu(twd_update_frequency,
> > - ??(void *)&cnd->new_rate, 1);
> > + on_each_cpu_mask(active_twd_mask, twd_update_frequency,
> > + ?(void *)&cnd->new_rate, 1);
> ?
> > ? return NOTIFY_OK;
> ?}
> @@ -326,6 +350,9 @@ static int __init twd_local_timer_common_register(struct device_node *np)
> ?{
> > ? int err;
> ?
> > + if (!zalloc_cpumask_var(&active_twd_mask, GFP_KERNEL))
> > + return -ENOMEM;
> +
> > ? twd_evt = alloc_percpu(struct clock_event_device);
> > ? if (!twd_evt) {
> > ? err = -ENOMEM;
^ permalink raw reply
* [PATCH] Documentation: Fix reference to stm.txt
From: Mathieu Poirier @ 2018-06-11 16:15 UTC (permalink / raw)
To: linux-arm-kernel
Commit "1606f8d8e75b trace doc: convert trace/stm.txt to rst format"
changed stm.txt to stm.rst but references to it in other files have not
been modified, something that is corrected in this patch.
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
Documentation/trace/coresight.txt | 2 +-
Documentation/trace/intel_th.rst | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 1d74ad0202b6..efbc832146e7 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -426,5 +426,5 @@ root at genericarmv8:~#
Details on how to use the generic STM API can be found here [2].
[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-[2]. Documentation/trace/stm.txt
+[2]. Documentation/trace/stm.rst
[3]. https://github.com/Linaro/perf-opencsd
diff --git a/Documentation/trace/intel_th.rst b/Documentation/trace/intel_th.rst
index 990f13265178..fdb34114ee20 100644
--- a/Documentation/trace/intel_th.rst
+++ b/Documentation/trace/intel_th.rst
@@ -38,7 +38,7 @@ description is at Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth.
STH registers an stm class device, through which it provides interface
to userspace and kernelspace software trace sources. See
-Documentation/trace/stm.txt for more information on that.
+Documentation/trace/stm.rst for more information on that.
MSU can be configured to collect trace data into a system memory
buffer, which can later on be read from its device nodes via read() or
@@ -89,7 +89,7 @@ Quick example
$ echo 1 > /sys/bus/intel_th/devices/0-msc0/active
-# .. send data to master 33, see stm.txt for more details ..
+# .. send data to master 33, see stm.rst for more details ..
# .. wait for traces to pile up ..
# .. and stop the trace::
--
2.7.4
^ permalink raw reply related
* [PATCH v2 03/40] iommu/sva: Manage process address spaces
From: Kenneth Lee @ 2018-06-11 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526022445.GA6069@kllp05>
On Sat, May 26, 2018 at 10:24:45AM +0800, Kenneth Lee wrote:
> Date: Sat, 26 May 2018 10:24:45 +0800
> From: Kenneth Lee <Kenneth-Lee-2012@foxmail.com>
> To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>, Jean-Philippe Brucker
> <jean-philippe.brucker@arm.com>, "xieyisheng1 at huawei.com"
> <xieyisheng1@huawei.com>, "kvm at vger.kernel.org" <kvm@vger.kernel.org>,
> "linux-pci at vger.kernel.org" <linux-pci@vger.kernel.org>,
> "xuzaibo at huawei.com" <xuzaibo@huawei.com>, Will Deacon
> <Will.Deacon@arm.com>, "okaya at codeaurora.org" <okaya@codeaurora.org>,
> "linux-mm at kvack.org" <linux-mm@kvack.org>, "yi.l.liu at intel.com"
> <yi.l.liu@intel.com>, "ashok.raj at intel.com" <ashok.raj@intel.com>,
> "tn at semihalf.com" <tn@semihalf.com>, "joro at 8bytes.org" <joro@8bytes.org>,
> "robdclark at gmail.com" <robdclark@gmail.com>, "bharatku at xilinx.com"
> <bharatku@xilinx.com>, "linux-acpi at vger.kernel.org"
> <linux-acpi@vger.kernel.org>, "liudongdong3 at huawei.com"
> <liudongdong3@huawei.com>, "rfranz at cavium.com" <rfranz@cavium.com>,
> "devicetree at vger.kernel.org" <devicetree@vger.kernel.org>,
> "kevin.tian at intel.com" <kevin.tian@intel.com>, Jacob Pan
> <jacob.jun.pan@linux.intel.com>, "alex.williamson at redhat.com"
> <alex.williamson@redhat.com>, "rgummal at xilinx.com" <rgummal@xilinx.com>,
> "thunder.leizhen at huawei.com" <thunder.leizhen@huawei.com>,
> "linux-arm-kernel at lists.infradead.org"
> <linux-arm-kernel@lists.infradead.org>, "shunyong.yang at hxt-semitech.com"
> <shunyong.yang@hxt-semitech.com>, "dwmw2 at infradead.org"
> <dwmw2@infradead.org>, "liubo95 at huawei.com" <liubo95@huawei.com>,
> "jcrouse at codeaurora.org" <jcrouse@codeaurora.org>,
> "iommu at lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
> Robin Murphy <Robin.Murphy@arm.com>, "christian.koenig at amd.com"
> <christian.koenig@amd.com>, "nwatters at codeaurora.org"
> <nwatters@codeaurora.org>, "baolu.lu at linux.intel.com"
> <baolu.lu@linux.intel.com>, liguozhu at hisilicon.com
> Subject: Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces
> Message-ID: <20180526022445.GA6069@kllp05>
>
> On Fri, May 25, 2018 at 09:39:59AM +0100, Jonathan Cameron wrote:
> > Date: Fri, 25 May 2018 09:39:59 +0100
> > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > CC: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
> > "xieyisheng1 at huawei.com" <xieyisheng1@huawei.com>, "kvm at vger.kernel.org"
> > <kvm@vger.kernel.org>, "linux-pci at vger.kernel.org"
> > <linux-pci@vger.kernel.org>, "xuzaibo at huawei.com" <xuzaibo@huawei.com>,
> > Will Deacon <Will.Deacon@arm.com>, "okaya at codeaurora.org"
> > <okaya@codeaurora.org>, "linux-mm at kvack.org" <linux-mm@kvack.org>,
> > "yi.l.liu at intel.com" <yi.l.liu@intel.com>, "ashok.raj at intel.com"
> > <ashok.raj@intel.com>, "tn at semihalf.com" <tn@semihalf.com>,
> > "joro at 8bytes.org" <joro@8bytes.org>, "robdclark at gmail.com"
> > <robdclark@gmail.com>, "bharatku at xilinx.com" <bharatku@xilinx.com>,
> > "linux-acpi at vger.kernel.org" <linux-acpi@vger.kernel.org>,
> > "liudongdong3 at huawei.com" <liudongdong3@huawei.com>, "rfranz at cavium.com"
> > <rfranz@cavium.com>, "devicetree at vger.kernel.org"
> > <devicetree@vger.kernel.org>, "kevin.tian at intel.com"
> > <kevin.tian@intel.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>,
> > "alex.williamson at redhat.com" <alex.williamson@redhat.com>,
> > "rgummal at xilinx.com" <rgummal@xilinx.com>, "thunder.leizhen at huawei.com"
> > <thunder.leizhen@huawei.com>, "linux-arm-kernel at lists.infradead.org"
> > <linux-arm-kernel@lists.infradead.org>, "shunyong.yang at hxt-semitech.com"
> > <shunyong.yang@hxt-semitech.com>, "dwmw2 at infradead.org"
> > <dwmw2@infradead.org>, "liubo95 at huawei.com" <liubo95@huawei.com>,
> > "jcrouse at codeaurora.org" <jcrouse@codeaurora.org>,
> > "iommu at lists.linux-foundation.org" <iommu@lists.linux-foundation.org>,
> > Robin Murphy <Robin.Murphy@arm.com>, "christian.koenig at amd.com"
> > <christian.koenig@amd.com>, "nwatters at codeaurora.org"
> > <nwatters@codeaurora.org>, "baolu.lu at linux.intel.com"
> > <baolu.lu@linux.intel.com>, liguozhu at hisilicon.com,
> > kenneth-lee-2012 at foxmail.com
> > Subject: Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces
> > Message-ID: <20180525093959.000040a7@huawei.com>
> >
> > +CC Kenneth Lee
> >
> > On Fri, 25 May 2018 09:33:11 +0300
> > Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote:
> >
> > > On Thu, May 24, 2018 at 04:04:39PM +0100, Jean-Philippe Brucker wrote:
> > > > On 24/05/18 12:50, Ilias Apalodimas wrote:
> > > > >> Interesting, I hadn't thought about this use-case before. At first I
> > > > >> thought you were talking about mdev devices assigned to VMs, but I think
> > > > >> you're referring to mdevs assigned to userspace drivers instead? Out of
> > > > >> curiosity, is it only theoretical or does someone actually need this?
> > > > >
> > > > > There has been some non upstreamed efforts to have mdev and produce userspace
> > > > > drivers. Huawei is using it on what they call "wrapdrive" for crypto devices and
> > > > > we did a proof of concept for ethernet interfaces. At the time we choose not to
> > > > > involve the IOMMU for the reason you mentioned, but having it there would be
> > > > > good.
> > > >
> > > > I'm guessing there were good reasons to do it that way but I wonder, is
> > > > it not simpler to just have the kernel driver create a /dev/foo, with a
> > > > standard ioctl/mmap/poll interface? Here VFIO adds a layer of
> > > > indirection, and since the mediating driver has to implement these
> > > > operations already, what is gained?
> > > The best reason i can come up with is "common code". You already have one API
> > > doing that for you so we replicate it in a /dev file?
> > > The mdev approach still needs extentions to support what we tried to do (i.e
> > > mdev bus might need yo have access on iommu_ops), but as far as i undestand it's
> > > a possible case.
>
> Hi, Jean, Please allow me to share my understanding here:
> https://zhuanlan.zhihu.com/p/35489035
>
> The reason we do not use the /dev/foo scheme is that the devices to be
> shared are programmable accelerators. We cannot fix up the kernel driver for them.
> > > >
> > > > Thanks,
> > > > Jean
> >
> >
>
> --
> -Kenneth Lee (Hisilicon)
I just found this mail was missed in the mailing list. I tried it once
again.
--
-Kenneth Lee (Hisilicon)
^ 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