* Re: [PATCH 2/4] arm: dts: sun8i: a83t: Add registers needed for MCPM
From: Maxime Ripard @ 2017-12-13 10:50 UTC (permalink / raw)
To: Mylène Josserand
Cc: wens, linux, robh+dt, mark.rutland, linux-arm-kernel,
linux-kernel, devicetree, thomas.petazzoni
In-Reply-To: <20171211075001.6100-3-mylene.josserand@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
Hi,
On Mon, Dec 11, 2017 at 08:49:59AM +0100, Mylène Josserand wrote:
> Add 3 registers needed for MCPM (ie SMP): prcm, cpucfg and r_cpucfg.
> prcm and cpucfg are identical with sun9i-a80. The only difference
> is the r_cpucfg that does not exist on sun9i.
>
> Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index a384b766f3dc..eeb2e7d0d6dc 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -323,6 +323,16 @@
> #reset-cells = <1>;
> };
> + cpucfg@01700000 {
Please drop the leading zero here, it generates a warning in dtc.
> + compatible = "allwinner,sun9i-a80-cpucfg";
There's some significant differences between the A83t and the A80 IPs,
you should use a different compatible.
> + reg = <0x01700000 0x100>;
the size is 1k (0x400)
> + };
> +
> + r_cpucfg@1f01c00 {
> + compatible = "allwinner,sun8i-a83t-r-cpucfg";
> + reg = <0x1f01c00 0x100>;
You should order the nodes by physical address
> + };
> +
> pio: pinctrl@1c20800 {
> compatible = "allwinner,sun8i-a83t-pinctrl";
> interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
> @@ -493,6 +503,11 @@
> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> + prcm@1f01400 {
> + compatible = "allwinner,sun9i-a80-prcm";
That block is significantly different on the A83t. Please use a
different compatible.
> + reg = <0x1f01400 0x200>;
> + };
> +
The size is 1k, again.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] arm: dts: sun8i: a83t: Add CCI-400 node
From: Maxime Ripard @ 2017-12-13 10:52 UTC (permalink / raw)
To: Mylène Josserand
Cc: wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20171211075001.6100-4-mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]
Hi,
On Mon, Dec 11, 2017 at 08:50:00AM +0100, Mylène Josserand wrote:
> Add CCI-400 node and control-port on CPUs needed by MCPM (ie SMP).
>
> Signed-off-by: Mylène Josserand <mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 41 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index eeb2e7d0d6dc..3e2aad537972 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -62,48 +62,56 @@
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0>;
> + cci-control-port = <&cci_control0>;
> };
>
> cpu@1 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <1>;
> + cci-control-port = <&cci_control0>;
> };
>
> cpu@2 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <2>;
> + cci-control-port = <&cci_control0>;
> };
>
> cpu@3 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <3>;
> + cci-control-port = <&cci_control0>;
> };
>
> cpu@100 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0x100>;
> + cci-control-port = <&cci_control1>;
> };
>
> cpu@101 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0x101>;
> + cci-control-port = <&cci_control1>;
> };
>
> cpu@102 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0x102>;
> + cci-control-port = <&cci_control1>;
> };
>
> cpu@103 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0x103>;
> + cci-control-port = <&cci_control1>;
> };
> };
>
> @@ -314,6 +322,39 @@
> status = "disabled";
> };
>
> + cci: cci@1790000 {
You're not using that label, and you should order the node by physical
address.
> + compatible = "arm,cci-400";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x01790000 0x1000>;
The size is 0x10000.
> + ranges = <0x0 0x01790000 0x10000>;
> +
> + cci_control0: slave-if@4000 {
> + compatible = "arm,cci-400-ctrl-if";
> + interface-type = "ace";
> + reg = <0x4000 0x1000>;
> + };
> +
> + cci_control1: slave-if@5000 {
> + compatible = "arm,cci-400-ctrl-if";
> + interface-type = "ace";
> + reg = <0x5000 0x1000>;
> + };
> +
> + pmu@9000 {
> + compatible = "arm,cci-400-pmu,r1";
> + reg = <0x9000 0x5000>;
> + interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 0/2] Add thermal support for iWave RZ/G1M board
From: Biju Das @ 2017-12-13 10:57 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Zhang Rui, Eduardo Valentin
Cc: Simon Horman, Magnus Damm, Chris Paterson, devicetree,
linux-renesas-soc, linux-pm, Biju Das
This series aims to add thermal support for iWave RZ/G1M board.
This patch series based on renesas tag renesas-devel-20171211-v4.15-rc3.
Biju Das (2):
dt-bindings: thermal: rcar: Add device tree support for r8a7743
ARM: dts: r8a7743: Add thermal device to DT
.../devicetree/bindings/thermal/rcar-thermal.txt | 1 +
arch/arm/boot/dts/r8a7743.dtsi | 32 ++++++++++++++++++++++
2 files changed, 33 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] dt-bindings: thermal: rcar: Add device tree support for r8a7743
From: Biju Das @ 2017-12-13 10:57 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Zhang Rui, Eduardo Valentin
Cc: Simon Horman, Magnus Damm, Chris Paterson, devicetree,
linux-renesas-soc, linux-pm, Biju Das
In-Reply-To: <1513162673-31531-1-git-send-email-biju.das@bp.renesas.com>
Add thermal sensor support for r8a7743 SoC. The Renesas RZ/G1M
(r8a7743) thermal sensor module is identical to the R-Car Gen2 family.
No driver change is needed due to the fallback compatible value
"renesas,rcar-gen2-thermal".
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
Documentation/devicetree/bindings/thermal/rcar-thermal.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
index a8e52c8..349e635 100644
--- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
@@ -6,6 +6,7 @@ Required properties:
"renesas,rcar-thermal" (without thermal-zone) as fallback.
Examples with soctypes are:
- "renesas,thermal-r8a73a4" (R-Mobile APE6)
+ - "renesas,thermal-r8a7743" (RZ/G1M)
- "renesas,thermal-r8a7779" (R-Car H1)
- "renesas,thermal-r8a7790" (R-Car H2)
- "renesas,thermal-r8a7791" (R-Car M2-W)
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: r8a7743: Add thermal device to DT
From: Biju Das @ 2017-12-13 10:57 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Zhang Rui, Eduardo Valentin
Cc: Simon Horman, Magnus Damm, Chris Paterson, devicetree,
linux-renesas-soc, linux-pm, Biju Das
In-Reply-To: <1513162673-31531-1-git-send-email-biju.das@bp.renesas.com>
This patch instantiates the thermal sensor module with thermal-zone
support.
This patch is based on the commit cac68a56e34b
("ARM: dts: r8a7791: enable to use thermal-zone") by Kuninori Morimoto.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 0e2834a..e056bc5 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -250,6 +250,38 @@
resets = <&cpg 407>;
};
+ thermal: thermal@e61f0000 {
+ compatible = "renesas,thermal-r8a7743",
+ "renesas,rcar-gen2-thermal",
+ "renesas,rcar-thermal";
+ reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
+ interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 522>;
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 522>;
+ #thermal-sensor-cells = <0>;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
+ thermal-sensors = <&thermal>;
+
+ trips {
+ cpu-crit {
+ temperature = <95000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ };
+ };
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 4/4] arm: dts: sun8i: a83t: Set timer node to use phy timer
From: Maxime Ripard @ 2017-12-13 10:59 UTC (permalink / raw)
To: Mylène Josserand
Cc: wens, linux, robh+dt, mark.rutland, linux-arm-kernel,
linux-kernel, devicetree, thomas.petazzoni
In-Reply-To: <20171211075001.6100-5-mylene.josserand@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]
Hi,
On Mon, Dec 11, 2017 at 08:50:01AM +0100, Mylène Josserand wrote:
> By default, virtual timers are used. These timers need an offset
> that must be set by firmware, for example. In case of SMP support,
> after a reset, this offset is in "unknown" state and produced
> a hang of the kernel.
>
> Use "arm,cpu-registers-not-fw-configured" property allows to use
> physical timers instead of virtual ones.
>
> Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
Your commit log could be a little better, something like:
"
The ARM architected timers use an offset between their physical and
virtual counters. That offset should be configured by the bootloader
in CNTVOFF.
However, the A83t bootloader fails to do so, and we end up with an
undefined offset (which in our case is random), meaning that each CPU
will have a different time, which isn't working very well.
Fix that by setting the arm,cpu-registers-not-fw-configured that will
make Linux use the physical timers instead of the virtual ones. One
possible side effect would be that the virtualization features would
be disabled. However, due to the way the GIC has been integrated in
the system, it is already unusable so we're effectively not losing any
feature.
"
The commit title should be improved too.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 04/12] clk: qcom: Add HFPLL driver
From: Sricharan R @ 2017-12-13 11:10 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-pm, linux-arm-msm, mturquette, sboyd,
linux-kernel, viresh.kumar, linux-arm-kernel
In-Reply-To: <20171212203515.gpnu7cnxilkdz4hc@rob-hp-laptop>
Hi Rob,
Thanks for the review.
On 12/13/2017 2:05 AM, Rob Herring wrote:
> On Fri, Dec 08, 2017 at 03:12:22PM +0530, Sricharan R wrote:
>> From: Stephen Boyd <sboyd@codeaurora.org>
>>
>> On some devices (MSM8974 for example), the HFPLLs are
>> instantiated within the Krait processor subsystem as separate
>> register regions. Add a driver for these PLLs so that we can
>> provide HFPLL clocks for use by the system.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>> .../devicetree/bindings/clock/qcom,hfpll.txt | 40 ++++++++
>> drivers/clk/qcom/Kconfig | 8 ++
>> drivers/clk/qcom/Makefile | 1 +
>> drivers/clk/qcom/hfpll.c | 106 +++++++++++++++++++++
>> 4 files changed, 155 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>> create mode 100644 drivers/clk/qcom/hfpll.c
>>
>> diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>> new file mode 100644
>> index 0000000..fee92bb
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt
>> @@ -0,0 +1,40 @@
>> +High-Frequency PLL (HFPLL)
>> +
>> +PROPERTIES
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <string>
>> + Definition: must be "qcom,hfpll"
>
> Fine for a fallback, but please add SoC specific compatibles.
>
sure, will all add them.
>> +
>> +- reg:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: address and size of HPLL registers. An optional second
>> + element specifies the address and size of the alias
>> + register region.
>> +
>> +- clock-output-names:
>> + Usage: required
>> + Value type: <string>
>> + Definition: Name of the PLL. Typically hfpllX where X is a CPU number
>> + starting at 0. Otherwise hfpll_Y where Y is more specific
>> + such as "l2".
>> +
>> +Example:
>> +
>> +1) An HFPLL for the L2 cache.
>> +
>> + clock-controller@f9016000 {
>> + compatible = "qcom,hfpll";
>> + reg = <0xf9016000 0x30>;
>> + clock-output-names = "hfpll_l2";
>> + };
>> +
>> +2) An HFPLL for CPU0. This HFPLL has the alias register region.
>> +
>> + clock-controller@f908a000 {
>> + compatible = "qcom,hfpll";
>> + reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
>> + clock-output-names = "hfpll0";
>> + };
>> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
>> index 20b5d6f..6c811bd 100644
>> --- a/drivers/clk/qcom/Kconfig
>> +++ b/drivers/clk/qcom/Kconfig
>> @@ -205,3 +205,11 @@ config SPMI_PMIC_CLKDIV
>> Technologies, Inc. SPMI PMIC. It configures the frequency of
>> clkdiv outputs of the PMIC. These clocks are typically wired
>> through alternate functions on GPIO pins.
>> +
>> +config QCOM_HFPLL
>> + tristate "High-Frequency PLL (HFPLL) Clock Controller"
>> + depends on COMMON_CLK_QCOM
>> + help
>> + Support for the high-frequency PLLs present on Qualcomm devices.
>> + Say Y if you want to support CPU frequency scaling on devices
>> + such as MSM8974, APQ8084, etc.
>> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
>> index 4795e21..4a4bf38 100644
>> --- a/drivers/clk/qcom/Makefile
>> +++ b/drivers/clk/qcom/Makefile
>> @@ -36,3 +36,4 @@ obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
>> obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
>> obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
>> obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
>> +obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
>> diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom/hfpll.c
>> new file mode 100644
>> index 0000000..7405bb6
>> --- /dev/null
>> +++ b/drivers/clk/qcom/hfpll.c
>> @@ -0,0 +1,106 @@
>> +/*
>> + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
>
> It's 2017.
>
ok.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>
> Use SPDX tags.
>
ok.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH v4 05/12] clk: qcom: Add MSM8960/APQ8064's HFPLLs
From: Sricharan R @ 2017-12-13 11:10 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
viresh.kumar-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171212203631.kyruwhtpmigkwfat@rob-hp-laptop>
Hi Rob,
On 12/13/2017 2:06 AM, Rob Herring wrote:
> On Fri, Dec 08, 2017 at 03:12:23PM +0530, Sricharan R wrote:
>> From: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>
>> Describe the HFPLLs present on MSM8960 and APQ8064 devices.
>>
>> Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>> drivers/clk/qcom/gcc-msm8960.c | 172 +++++++++++++++++++++++++++
>> include/dt-bindings/clock/qcom,gcc-msm8960.h | 2 +
>
> For the binding,
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
Thanks.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 09/12] clk: qcom: Add Krait clock controller driver
From: Sricharan R @ 2017-12-13 11:11 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, linux-pm, linux-arm-msm, mturquette, sboyd,
linux-kernel, viresh.kumar, linux-arm-kernel
In-Reply-To: <20171212205104.vnnjr3w56w4mrfh6@rob-hp-laptop>
Hi Rob,
On 12/13/2017 2:21 AM, Rob Herring wrote:
> On Fri, Dec 08, 2017 at 03:12:27PM +0530, Sricharan R wrote:
>> From: Stephen Boyd <sboyd@codeaurora.org>
>>
>> The Krait CPU clocks are made up of a primary mux and secondary
>> mux for each CPU and the L2, controlled via cp15 accessors. For
>> Kraits within KPSSv1 each secondary mux accepts a different aux
>> source, but on KPSSv2 each secondary mux accepts the same aux
>> source.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>> .../devicetree/bindings/clock/qcom,krait-cc.txt | 22 ++
>
> Please make bindings a separate patch.
>
ok.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH v4 1/2] Input: Add driver for Cypress Generation 5 touchscreen
From: kbuild test robot @ 2017-12-13 11:37 UTC (permalink / raw)
Cc: kbuild-all, dmitry.torokhov, robh+dt, mark.rutland, linux-kernel,
linux-input, devicetree, mylene.josserand, thomas.petazzoni,
maxime.ripard
In-Reply-To: <20171201153957.13053-2-mylene.josserand@free-electrons.com>
Hi Mylène,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on input/next]
[also build test WARNING on v4.15-rc3 next-20171213]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Myl-ne-Josserand/Input-Add-driver-for-Cypress-Generation-5-touchscreen/20171203-203557
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH] Input: hid_cmd_state can be static
From: kbuild test robot @ 2017-12-13 11:37 UTC (permalink / raw)
Cc: kbuild-all, dmitry.torokhov, robh+dt, mark.rutland, linux-kernel,
linux-input, devicetree, mylene.josserand, thomas.petazzoni,
maxime.ripard
In-Reply-To: <20171201153957.13053-2-mylene.josserand@free-electrons.com>
Fixes: 68d0bd1e4815 ("Input: Add driver for Cypress Generation 5 touchscreen")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
cyttsp5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/cyttsp5.c b/drivers/input/touchscreen/cyttsp5.c
index a41feea..9694ae41 100644
--- a/drivers/input/touchscreen/cyttsp5.c
+++ b/drivers/input/touchscreen/cyttsp5.c
@@ -139,7 +139,7 @@ struct cyttsp5_sensing_conf_data {
u8 max_tch;
};
-enum { HID_CMD_DONE, HID_CMD_BUSY } hid_cmd_state;
+static enum { HID_CMD_DONE, HID_CMD_BUSY } hid_cmd_state;
enum cyttsp5_tch_abs { /* for ordering within the extracted touch data array */
CY_TCH_X, /* X */
^ permalink raw reply related
* Re: [PATCH v4 08/12] clk: qcom: Add KPSS ACC/GCC driver
From: Sricharan R @ 2017-12-13 11:42 UTC (permalink / raw)
To: Rob Herring
Cc: mturquette, sboyd, devicetree, linux-pm, linux-arm-msm,
linux-kernel, viresh.kumar, linux-arm-kernel
In-Reply-To: <20171212203813.f3fkjw4uvxm43yok@rob-hp-laptop>
Hi Rob,
On 12/13/2017 2:08 AM, Rob Herring wrote:
> On Fri, Dec 08, 2017 at 03:12:26PM +0530, Sricharan R wrote:
>> From: Stephen Boyd <sboyd@codeaurora.org>
>>
>> The ACC and GCC regions present in KPSSv1 contain registers to
>> control clocks and power to each Krait CPU and L2. For CPUfreq
>> purposes probe these devices and expose a mux clock that chooses
>> between PXO and PLL8.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 7 ++
>> .../devicetree/bindings/arm/msm/qcom,kpss-gcc.txt | 28 +++++++
>
> Please make bindings a separate patch.
ok.
>
>> drivers/clk/qcom/Kconfig | 8 ++
>> drivers/clk/qcom/Makefile | 1 +
>> drivers/clk/qcom/kpss-xcc.c | 96 ++++++++++++++++++++++
>> 5 files changed, 140 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>> create mode 100644 drivers/clk/qcom/kpss-xcc.c
>>
>> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>> index 1333db9..382a574 100644
>> --- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>> @@ -21,10 +21,17 @@ PROPERTIES
>> the register region. An optional second element specifies
>> the base address and size of the alias register region.
>>
>> +- clock-output-names:
>> + Usage: optional
>> + Value type: <string>
>> + Definition: Name of the output clock. Typically acpuX_aux where X is a
>> + CPU number starting at 0.
>> +
>> Example:
>>
>> clock-controller@2088000 {
>> compatible = "qcom,kpss-acc-v2";
>> reg = <0x02088000 0x1000>,
>> <0x02008000 0x1000>;
>> + clock-output-names = "acpu0_aux";
>> };
>> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>> new file mode 100644
>> index 0000000..d1e12f1
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt
>> @@ -0,0 +1,28 @@
>> +Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
>> +
>> +PROPERTIES
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <string>
>> + Definition: should be one of:
>> + "qcom,kpss-gcc"
>
> Only one implementation?
hmm, missed "qcom,kpss-acc-v1", will add that too.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH v11 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)
From: Shameer Kolothum @ 2017-12-13 11:58 UTC (permalink / raw)
To: lorenzo.pieralisi, robin.murphy, marc.zyngier, will.deacon
Cc: joro, john.garry, xuwei5, guohanjun, iommu, linux-arm-kernel,
linux-acpi, devicetree, linuxarm, Shameer Kolothum
On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.
The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.
This patch implements an ACPI based quirk to reserve the hw msi regions
in the smmu-v3 driver which means these address regions will not be
translated and will be excluded from iova allocations.
To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve and reserve
the associated ITS base address from a device IORT node. The function
has a check for smmu model to determine whether the platform requires
the HW MSI reservation or not.
2. Added smmu node entries and explicitly disabled them in hip06/hip07
dts files so that users are warned about the non-DT support for this
erratum.
Changelog:
v10 --> v11
-Addressed comments from Lorenzo(patch#1)
-Added Robin's Reviewed-by to patch #2
v9 --> v10
Addressed comments:
-Moved smmu model check to iort helper function to selectively apply
the msi reservation which will make the fn call generic from iommu-dma.
-Removed PCI blacklisting patch, instead added smmu nodes(disabled)
with comments to hip06/hip07 dts file.
v8 --> v9
-Thanks to Marc, fixed IORT helper function to reserve the ITS
translater region only.
-Removed the DT support for MSI reservation and blacklisted
HiSilicon PCIe controllers on DT based systems when SMMUv3 is
enabled.
v7 --> v8
Addressed comments from Rob and Lorenzo:
-Modified to use DT compatible string for errata.
-Changed logic to retrieve the msi-parent for DT case.
v6 --> v7
Addressed request from Will to add DT support for the erratum:
- added bt binding
- add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions
v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
is not applicable. Provided a generic function in iommu code and added
back the quirk implementation in SMMU v3 driver(patch#3)
v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward
HW topologies are handled while reserving ITS regions(patch #1).
v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into
iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).
v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
iort helper function.
v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.
RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead
of vendor specific CSRT table.
Shameer Kolothum (3):
ACPI/IORT: Add msi address regions reservation helper
iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 55 +++++++++++++++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 24 +++++++
drivers/acpi/arm64/iort.c | 112 ++++++++++++++++++++++++++++++-
drivers/iommu/dma-iommu.c | 8 ++-
drivers/irqchip/irq-gic-v3-its.c | 3 +-
include/linux/acpi_iort.h | 7 +-
6 files changed, 203 insertions(+), 6 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v11 1/3] ACPI/IORT: Add msi address regions reservation helper
From: Shameer Kolothum @ 2017-12-13 11:58 UTC (permalink / raw)
To: lorenzo.pieralisi, robin.murphy, marc.zyngier, will.deacon
Cc: joro, john.garry, xuwei5, guohanjun, iommu, linux-arm-kernel,
linux-acpi, devicetree, linuxarm, Shameer Kolothum
In-Reply-To: <20171213115830.61872-1-shameerali.kolothum.thodi@huawei.com>
On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.
Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device <-> ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations. The function checks for the smmu model number and
only applies the msi reservation if the platform requires it.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
drivers/acpi/arm64/iort.c | 112 +++++++++++++++++++++++++++++++++++++--
drivers/irqchip/irq-gic-v3-its.c | 3 +-
include/linux/acpi_iort.h | 7 ++-
3 files changed, 117 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 95255ec..3e0ce65 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -39,6 +39,7 @@
struct iort_its_msi_chip {
struct list_head list;
struct fwnode_handle *fw_node;
+ phys_addr_t base_addr;
u32 translation_id;
};
@@ -161,14 +162,16 @@ typedef acpi_status (*iort_find_node_callback)
static DEFINE_SPINLOCK(iort_msi_chip_lock);
/**
- * iort_register_domain_token() - register domain token and related ITS ID
- * to the list from where we can get it back later on.
+ * iort_register_domain_token() - register domain token along with related
+ * ITS ID and base address to the list from where we can get it back later on.
* @trans_id: ITS ID.
+ * @base: ITS base address.
* @fw_node: Domain token.
*
* Returns: 0 on success, -ENOMEM if no memory when allocating list element
*/
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+ struct fwnode_handle *fw_node)
{
struct iort_its_msi_chip *its_msi_chip;
@@ -178,6 +181,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
its_msi_chip->fw_node = fw_node;
its_msi_chip->translation_id = trans_id;
+ its_msi_chip->base_addr = base;
spin_lock(&iort_msi_chip_lock);
list_add(&its_msi_chip->list, &iort_msi_chip_list);
@@ -581,6 +585,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
return -ENODEV;
}
+static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
+{
+ struct iort_its_msi_chip *its_msi_chip;
+ int ret = -ENODEV;
+
+ spin_lock(&iort_msi_chip_lock);
+ list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
+ if (its_msi_chip->translation_id == its_id) {
+ *base = its_msi_chip->base_addr;
+ ret = 0;
+ break;
+ }
+ }
+ spin_unlock(&iort_msi_chip_lock);
+
+ return ret;
+}
+
/**
* iort_dev_find_its_id() - Find the ITS identifier for a device
* @dev: The device.
@@ -740,6 +762,25 @@ static int __maybe_unused __get_pci_rid(struct pci_dev *pdev, u16 alias,
return 0;
}
+static __maybe_unused struct acpi_iort_node *iort_get_msi_resv_iommu(
+ struct device *dev)
+{
+ struct acpi_iort_node *iommu;
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+ iommu = iort_get_iort_node(fwspec->iommu_fwnode);
+
+ if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
+ struct acpi_iort_smmu_v3 *smmu;
+
+ smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
+ if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X)
+ return iommu;
+ }
+
+ return NULL;
+}
+
static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
struct fwnode_handle *fwnode,
const struct iommu_ops *ops)
@@ -782,6 +823,69 @@ static inline int iort_add_device_replay(const struct iommu_ops *ops,
return err;
}
+
+/**
+ * iort_iommu_msi_get_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @head: Reserved region list from iommu_get_resv_regions()
+ *
+ * Returns: Number of msi reserved regions on success (0 if platform
+ * doesn't require the reservation or no associated msi regions),
+ * appropriate error value otherwise. The ITS interrupt translation
+ * spaces (ITS_base + SZ_64K, SZ_64K) associated with the device
+ * are the msi reserved regions.
+ */
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{
+ struct acpi_iort_its_group *its;
+ struct acpi_iort_node *iommu_node, *its_node = NULL;
+ int i, resv = 0;
+
+ iommu_node = iort_get_msi_resv_iommu(dev);
+ if (!iommu_node)
+ return 0;
+
+ /*
+ * Current logic to reserve ITS regions relies on HW topologies
+ * where a given PCI or named component maps its IDs to only one
+ * ITS group; if a PCI or named component can map its IDs to
+ * different ITS groups through IORT mappings this function has
+ * to be reworked to ensure we reserve regions for all ITS groups
+ * a given PCI or named component may map IDs to.
+ */
+
+ for (i = 0; i < dev->iommu_fwspec->num_ids; i++) {
+ its_node = iort_node_map_id(iommu_node,
+ dev->iommu_fwspec->ids[i],
+ NULL, IORT_MSI_TYPE);
+ if (its_node)
+ break;
+ }
+
+ if (!its_node)
+ return 0;
+
+ /* Move to ITS specific data */
+ its = (struct acpi_iort_its_group *)its_node->node_data;
+
+ for (i = 0; i < its->its_count; i++) {
+ phys_addr_t base;
+
+ if (!iort_find_its_base(its->identifiers[i], &base)) {
+ int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+ struct iommu_resv_region *region;
+
+ region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
+ prot, IOMMU_RESV_MSI);
+ if (region) {
+ list_add_tail(®ion->list, head);
+ resv++;
+ }
+ }
+ }
+
+ return (resv == its->its_count) ? resv : -ENODEV;
+}
#else
static inline const struct iommu_ops *iort_fwspec_iommu_ops(
struct iommu_fwspec *fwspec)
@@ -789,6 +893,8 @@ static inline const struct iommu_ops *iort_fwspec_iommu_ops(
static inline int iort_add_device_replay(const struct iommu_ops *ops,
struct device *dev)
{ return 0; }
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return 0; }
#endif
static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 4039e64..d4cff12 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3450,7 +3450,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
return -ENOMEM;
}
- err = iort_register_domain_token(its_entry->translation_id, dom_handle);
+ err = iort_register_domain_token(its_entry->translation_id, res.start,
+ dom_handle);
if (err) {
pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
&res.start, its_entry->translation_id);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 2f7a292..38cd77b 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -26,7 +26,8 @@
#define IORT_IRQ_MASK(irq) (irq & 0xffffffffULL)
#define IORT_IRQ_TRIGGER_MASK(irq) ((irq >> 32) & 0xffffffffULL)
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+ struct fwnode_handle *fw_node);
void iort_deregister_domain_token(int trans_id);
struct fwnode_handle *iort_find_domain_token(int trans_id);
#ifdef CONFIG_ACPI_IORT
@@ -38,6 +39,7 @@
/* IOMMU interface */
void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
const struct iommu_ops *iort_iommu_configure(struct device *dev);
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
#else
static inline void acpi_iort_init(void) { }
static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
@@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
static inline const struct iommu_ops *iort_iommu_configure(
struct device *dev)
{ return NULL; }
+static inline
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return 0; }
#endif
#endif /* __ACPI_IORT_H__ */
--
1.9.1
^ permalink raw reply related
* [PATCH v11 2/3] iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
From: Shameer Kolothum @ 2017-12-13 11:58 UTC (permalink / raw)
To: lorenzo.pieralisi, robin.murphy, marc.zyngier, will.deacon
Cc: joro, john.garry, xuwei5, guohanjun, iommu, linux-arm-kernel,
linux-acpi, devicetree, linuxarm, Shameer Kolothum
In-Reply-To: <20171213115830.61872-1-shameerali.kolothum.thodi@huawei.com>
Modified iommu_dma_get_resv_regions() to include GICv3 ITS
region on ACPI based ARM platfiorms which may require HW MSI
reservations.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/dma-iommu.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 25914d3..f05f3cf 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi_iort.h>
#include <linux/device.h>
#include <linux/dma-iommu.h>
#include <linux/gfp.h>
@@ -167,13 +168,18 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
*
* IOMMU drivers can use this to implement their .get_resv_regions callback
* for general non-IOMMU-specific reservations. Currently, this covers host
- * bridge windows for PCI devices.
+ * bridge windows for PCI devices and GICv3 ITS region reservation on ACPI
+ * based ARM platforms that may require HW MSI reservation.
*/
void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
{
struct pci_host_bridge *bridge;
struct resource_entry *window;
+ if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
+ iort_iommu_msi_get_resv_regions(dev, list) < 0)
+ return;
+
if (!dev_is_pci(dev))
return;
--
1.9.1
^ permalink raw reply related
* [PATCH v11 3/3] arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
From: Shameer Kolothum @ 2017-12-13 11:58 UTC (permalink / raw)
To: lorenzo.pieralisi, robin.murphy, marc.zyngier, will.deacon
Cc: joro, john.garry, xuwei5, guohanjun, iommu, linux-arm-kernel,
linux-acpi, devicetree, linuxarm, Shameer Kolothum
In-Reply-To: <20171213115830.61872-1-shameerali.kolothum.thodi@huawei.com>
The HiSilicon erratum 161010801 describes the limitation of
HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
for MSI transactions.
PCIe controller on these platforms has to differentiate the
MSI payload against other DMA payload and has to modify the
MSI payload. This makes it difficult for these platforms to
have SMMU translation for MSI. In order to workaround this,
ARM SMMUv3 driver requires a quirk to treat the MSI regions
separately. Such a quirk is currently missing for DT based
systems and therefore we need to explicitly disable the
hip06/hip07 smmu entries in dts.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 55 ++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 24 ++++++++++++++
2 files changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..d0d5933 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -291,6 +291,13 @@
#interrupt-cells = <2>;
num-pins = <128>;
};
+
+ mbigen_pcie0: intc_pcie0 {
+ msi-parent = <&its_dsa 0x40085>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <10>;
+ };
};
mbigen_dsa@c0080000 {
@@ -312,6 +319,30 @@
};
};
+ /** HiSilicon erratum 161010801: This describes the limitation
+ * of HiSilicon platforms hip06/hip07 to support the SMMUv3
+ * mappings for PCIe MSI transactions.
+ * PCIe controller on these platforms has to differentiate the
+ * MSI payload against other DMA payload and has to modify the
+ * MSI payload. This makes it difficult for these platforms to
+ * have a SMMU translation for MSI. In order to workaround this,
+ * ARM SMMUv3 driver requires a quirk to treat the MSI regions
+ * separately. Such a quirk is currently missing for DT based
+ * systems. Hence please make sure that the smmu pcie node on
+ * hip06 is disabled as this will break the PCIe functionality
+ * when iommu-map entry is used along with the PCIe node.
+ * Refer:https://www.spinics.net/lists/arm-kernel/msg602812.html
+ */
+ smmu0: smmu_pcie {
+ compatible = "arm,smmu-v3";
+ reg = <0x0 0xa0040000 0x0 0x20000>;
+ #iommu-cells = <1>;
+ dma-coherent;
+ smmu-cb-memtype = <0x0 0x1>;
+ hisilicon,broken-prefetch-cmd;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -676,6 +707,30 @@
<637 1>,<638 1>,<639 1>;
status = "disabled";
};
+
+ pcie0: pcie@a0090000 {
+ compatible = "hisilicon,hip06-pcie-ecam";
+ reg = <0 0xb0000000 0 0x2000000>,
+ <0 0xa0090000 0 0x10000>;
+ bus-range = <0 31>;
+ msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
+ msi-map-mask = <0xffff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0
+ 0x5ff0000 0x01000000 0 0 0 0xb7ff0000
+ 0 0x10000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
+ 0x0 0 0 2 &mbigen_pcie0 650 4
+ 0x0 0 0 3 &mbigen_pcie0 650 4
+ 0x0 0 0 4 &mbigen_pcie0 650 4>;
+ status = "disabled";
+ };
+
};
};
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2c01a21..58fe013 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1083,6 +1083,30 @@
};
};
+ /** HiSilicon erratum 161010801: This describes the limitation
+ * of HiSilicon platforms hip06/hip07 to support the SMMUv3
+ * mappings for PCIe MSI transactions.
+ * PCIe controller on these platforms has to differentiate the
+ * MSI payload against other DMA payload and has to modify the
+ * MSI payload. This makes it difficult for these platforms to
+ * have a SMMU translation for MSI. In order to workaround this,
+ * ARM SMMUv3 driver requires a quirk to treat the MSI regions
+ * separately. Such a quirk is currently missing for DT based
+ * systems. Hence please make sure that the smmu pcie node on
+ * hip06 is disabled as this will break the PCIe functionality
+ * when iommu-map entry is used along with the PCIe node.
+ * Refer:https://www.spinics.net/lists/arm-kernel/msg602812.html
+ */
+ smmu0: smmu_pcie {
+ compatible = "arm,smmu-v3";
+ reg = <0x0 0xa0040000 0x0 0x20000>;
+ #iommu-cells = <1>;
+ dma-coherent;
+ smmu-cb-memtype = <0x0 0x1>;
+ hisilicon,broken-prefetch-cmd;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v10 08/13] regmap: add SLIMbus support
From: Mark Brown @ 2017-12-13 12:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mark Rutland, devicetree, alsa-devel, Jonathan Corbet,
linux-arm-msm, linux-doc, j.neuschaefer, linux-kernel,
Rob Herring, srinivas.kandagatla, pombredanne, sdharia
In-Reply-To: <20171213092537.GB12631@kroah.com>
[-- Attachment #1.1: Type: text/plain, Size: 241 bytes --]
On Wed, Dec 13, 2017 at 10:25:37AM +0100, Greg Kroah-Hartman wrote:
> Mark, can I get an Ack for this patch so I can take it through my tree
> with the other patches in this series?
Not until I've reviewed it (and the rest of the series).
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH 0/2] sunxi: Add Capture support for sun8i-a33
From: Mylène Josserand @ 2017-12-13 12:34 UTC (permalink / raw)
To: lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Hello everyone,
Here is a first series to add support for the capture for
Allwinner Sun8I-A33 SoC (sun8i-codec).
These patches have been tested on Sun8i-r16 parrot board and
the two microphones are working well.
Noticed that the DAPM route is not correct: "Right/Left Digital
ADC Mixer" widgets should be after the "Right ADC" (according to what I
understood from the datasheet). This is currently not the case but when
I tried to update it, I got an error about "failing to add routes".
I will investigate why in next weeks (and send a V2) but as it
can take time, I think it is better to send a V1 and got reviews
(because it is the first time I am implementing such features).
Thank you in advance,
Best regards,
Mylène
Mylène Josserand (2):
ASoC: sun8i-codec: Add ADC support for a33
ARM: dts: sun8i: Add ADC routing
arch/arm/boot/dts/sun8i-a33.dtsi | 10 ++++-
sound/soc/sunxi/sun8i-codec.c | 82 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 89 insertions(+), 3 deletions(-)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33
From: Mylène Josserand @ 2017-12-13 12:34 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, maxime.ripard, wens, robh+dt,
mark.rutland, linux
Cc: thomas.petazzoni, devicetree, alsa-devel, linux-kernel,
mylene.josserand, linux-arm-kernel
In-Reply-To: <20171213123408.10422-1-mylene.josserand@free-electrons.com>
Add ADC support for the sun8i-codec driver.
This driver uses microphones widgets and routes provided by the
analog part (sun8i-codec-analog).
Some digital configurations are needed by creating new ADC widgets
and routes.
Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
---
sound/soc/sunxi/sun8i-codec.c | 82 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 80 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index 3dd183be08a4..7a15df924316 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -37,9 +37,11 @@
#define SUN8I_SYSCLK_CTL_SYSCLK_SRC 0
#define SUN8I_MOD_CLK_ENA 0x010
#define SUN8I_MOD_CLK_ENA_AIF1 15
+#define SUN8I_MOD_CLK_ENA_ADC 3
#define SUN8I_MOD_CLK_ENA_DAC 2
#define SUN8I_MOD_RST_CTL 0x014
#define SUN8I_MOD_RST_CTL_AIF1 15
+#define SUN8I_MOD_RST_CTL_ADC 3
#define SUN8I_MOD_RST_CTL_DAC 2
#define SUN8I_SYS_SR_CTRL 0x018
#define SUN8I_SYS_SR_CTRL_AIF1_FS 12
@@ -54,9 +56,25 @@
#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ 4
#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16 (1 << 4)
#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT 2
+#define SUN8I_AIF1_ADCDAT_CTRL 0x044
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA 15
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA 14
#define SUN8I_AIF1_DACDAT_CTRL 0x048
#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA 15
#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA 14
+#define SUN8I_AIF1_MXR_SRC 0x04c
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L 15
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL 14
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL 13
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR 12
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R 11
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR 10
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR 9
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL 8
+#define SUN8I_ADC_DIG_CTRL 0x100
+#define SUN8I_ADC_DIG_CTRL_ENDA 15
+#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS 2
+#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY 1
#define SUN8I_DAC_DIG_CTRL 0x120
#define SUN8I_DAC_DIG_CTRL_ENDA 15
#define SUN8I_DAC_MXR_SRC 0x130
@@ -338,10 +356,30 @@ static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
};
+static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
+ SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
+ SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
+ SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
+ SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch",
+ SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
+ SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch",
+ SUN8I_AIF1_MXR_SRC,
+ SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
+ SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
+};
+
static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
- /* Digital parts of the DACs */
+ /* Digital parts of the DACs and ADC */
SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("ADC", SUN8I_ADC_DIG_CTRL, SUN8I_ADC_DIG_CTRL_ENDA,
+ 0, NULL, 0),
/* Analog DAC AIF */
SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left", "Playback", 0,
@@ -351,17 +389,31 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
SUN8I_AIF1_DACDAT_CTRL,
SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
- /* DAC Mixers */
+ /* Analog ADC AIF */
+ SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left ADC", "Capture", 0,
+ SUN8I_AIF1_ADCDAT_CTRL,
+ SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA, 0),
+ SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Right ADC", "Capture", 0,
+ SUN8I_AIF1_ADCDAT_CTRL,
+ SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA, 0),
+
+ /* DAC and ADC Mixers */
SOC_MIXER_ARRAY("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
sun8i_dac_mixer_controls),
SOC_MIXER_ARRAY("Right Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
sun8i_dac_mixer_controls),
+ SOC_MIXER_ARRAY("Left Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
+ sun8i_input_mixer_controls),
+ SOC_MIXER_ARRAY("Right Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
+ sun8i_input_mixer_controls),
/* Clocks */
SND_SOC_DAPM_SUPPLY("MODCLK AFI1", SUN8I_MOD_CLK_ENA,
SUN8I_MOD_CLK_ENA_AIF1, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("MODCLK DAC", SUN8I_MOD_CLK_ENA,
SUN8I_MOD_CLK_ENA_DAC, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MODCLK ADC", SUN8I_MOD_CLK_ENA,
+ SUN8I_MOD_CLK_ENA_ADC, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("AIF1", SUN8I_SYSCLK_CTL,
SUN8I_SYSCLK_CTL_AIF1CLK_ENA, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("SYSCLK", SUN8I_SYSCLK_CTL,
@@ -378,6 +430,12 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
SUN8I_MOD_RST_CTL_AIF1, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("RST DAC", SUN8I_MOD_RST_CTL,
SUN8I_MOD_RST_CTL_DAC, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("RST ADC", SUN8I_MOD_RST_CTL,
+ SUN8I_MOD_RST_CTL_ADC, 0, NULL, 0),
+
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("Mic", NULL),
+
};
static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
@@ -387,11 +445,16 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
{ "RST AIF1", NULL, "AIF1 PLL" },
{ "MODCLK AFI1", NULL, "RST AIF1" },
{ "DAC", NULL, "MODCLK AFI1" },
+ { "ADC", NULL, "MODCLK AFI1" },
{ "RST DAC", NULL, "SYSCLK" },
{ "MODCLK DAC", NULL, "RST DAC" },
{ "DAC", NULL, "MODCLK DAC" },
+ { "RST ADC", NULL, "SYSCLK" },
+ { "MODCLK ADC", NULL, "RST ADC" },
+ { "ADC", NULL, "MODCLK ADC" },
+
/* DAC Routes */
{ "AIF1 Slot 0 Right", NULL, "DAC" },
{ "AIF1 Slot 0 Left", NULL, "DAC" },
@@ -401,6 +464,12 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
"AIF1 Slot 0 Left"},
{ "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
"AIF1 Slot 0 Right"},
+
+ /* ADC routes */
+ { "Left Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
+ "AIF1 Slot 0 Left ADC" },
+ { "Right Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
+ "AIF1 Slot 0 Right ADC" },
};
static const struct snd_soc_dai_ops sun8i_codec_dai_ops = {
@@ -418,6 +487,15 @@ static struct snd_soc_dai_driver sun8i_codec_dai = {
.rates = SNDRV_PCM_RATE_8000_192000,
.formats = SNDRV_PCM_FMTBIT_S16_LE,
},
+ /* capture capabilities */
+ .capture = {
+ .stream_name = "Capture",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_8000_192000,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
+ .sig_bits = 24,
+ },
/* pcm operations */
.ops = &sun8i_codec_dai_ops,
};
--
2.11.0
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: sun8i: Add ADC routing
From: Mylène Josserand @ 2017-12-13 12:34 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, maxime.ripard, wens, robh+dt,
mark.rutland, linux
Cc: mylene.josserand, alsa-devel, linux-arm-kernel, linux-kernel,
devicetree, thomas.petazzoni
In-Reply-To: <20171213123408.10422-1-mylene.josserand@free-electrons.com>
Add the ADC route between the analog and the digital parts
of sun8i A33. Configure the MIC1 to use MBIAS and MIC2 to use HBIAS.
Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
---
arch/arm/boot/dts/sun8i-a33.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 22660919bd08..1841eecd5993 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -191,7 +191,15 @@
simple-audio-card,aux-devs = <&codec_analog>;
simple-audio-card,routing =
"Left DAC", "AIF1 Slot 0 Left",
- "Right DAC", "AIF1 Slot 0 Right";
+ "Right DAC", "AIF1 Slot 0 Right",
+ "AIF1 Slot 0 Left ADC", "Left ADC",
+ "AIF1 Slot 0 Right ADC", "Right ADC",
+ "Left ADC", "ADC",
+ "Right ADC", "ADC",
+ "Mic", "MBIAS",
+ "Headset Mic", "HBIAS",
+ "MIC1", "Mic",
+ "MIC2", "Headset Mic";
status = "disabled";
simple-audio-card,cpu {
--
2.11.0
^ permalink raw reply related
* RE: [PATCH 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
From: Alexandre TORGUE @ 2017-12-13 12:50 UTC (permalink / raw)
To: Vladimir Murzin, Maxime Coquelin, arnd@arndb.de,
robh+dt@kernel.org, mark.rutland@arm.com, linux@armlinux.org.uk,
Patrice CHOTARD, lee.jones@linaro.org
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <ab9a2ef4-4944-c935-af6e-12503b477879@arm.com>
-----Original Message-----
From: Alexandre TORGUE
Sent: mercredi 13 décembre 2017 11:28
To: 'Vladimir Murzin' <vladimir.murzin@arm.com>; Maxime Coquelin <mcoquelin.stm32@gmail.com>; arnd@arndb.de; robh+dt@kernel.org; mark.rutland@arm.com; linux@armlinux.org.uk; Patrice CHOTARD <patrice.chotard@st.com>; lee.jones@linaro.org
Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Subject: RE: [PATCH 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
-----Original Message-----
From: Vladimir Murzin [mailto:vladimir.murzin@arm.com]
Sent: mercredi 13 décembre 2017 11:07
To: Alexandre TORGUE <alexandre.torgue@st.com>; Maxime Coquelin <mcoquelin.stm32@gmail.com>; arnd@arndb.de; robh+dt@kernel.org; mark.rutland@arm.com; linux@armlinux.org.uk; Patrice CHOTARD <patrice.chotard@st.com>; lee.jones@linaro.org
Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
On 12/12/17 18:02, Alexandre Torgue wrote:
> On cortex-M7 MCU, DMA have to use a non cache-able memory area. For
> this reason a dedicated memory pool is created for DMA.
> This patch creates a DMA memory pool of 1MB of each STM32 MCU which
> embeds a cortex-M7 expect stm32f746-disco. Indeed, as stm32f746-disco
> has
^^^^^^
except?
Sorry, Is there a typo issue (or just wording issue) ?
Sorry I was not awake this morning. If no v2 I will fix this typo when I will apply patch on my tree.
> only a 8MB SDRAM and it's tricky to reduce memory used by Kernel.
I guess that 1MB is a kind of "should be enough" estimate, probably something along with [1] would give you exact numbers...
Exactly, 1MB is a kind "should be enough" and code is here to show that we need a dedicated memory area for DMA. But this value has to be adapt regarding to use case needed by users. Thanks for the lkml link. It will help users to adapt DMA area and thanks for reviewing.
Regards
Alex
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>
> diff --git a/arch/arm/boot/dts/stm32746g-eval.dts
> b/arch/arm/boot/dts/stm32746g-eval.dts
> index 2d4e717..3f52a7b 100644
> --- a/arch/arm/boot/dts/stm32746g-eval.dts
> +++ b/arch/arm/boot/dts/stm32746g-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xc0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32f769-disco.dts
> b/arch/arm/boot/dts/stm32f769-disco.dts
> index 4463ca1..08699a2 100644
> --- a/arch/arm/boot/dts/stm32f769-disco.dts
> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xC0000000 0x1000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc0f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts
> b/arch/arm/boot/dts/stm32h743i-disco.dts
> index 79e841d..104545a 100644
> --- a/arch/arm/boot/dts/stm32h743i-disco.dts
> +++ b/arch/arm/boot/dts/stm32h743i-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart2;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts
> b/arch/arm/boot/dts/stm32h743i-eval.dts
> index 9f0e72c..5bd4b16 100644
> --- a/arch/arm/boot/dts/stm32h743i-eval.dts
> +++ b/arch/arm/boot/dts/stm32h743i-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
>
Usage of dma-default looks correct to me, so FWIW
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
[1] https://lkml.org/lkml/2017/7/7/296
Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt: bindings: as3645a: Update dt node example with standard
From: Dan Murphy @ 2017-12-13 12:55 UTC (permalink / raw)
To: Laurent Pinchart
Cc: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel,
sakari.ailus, devicetree, linux-kernel, linux-leds
In-Reply-To: <4192002.yKJgEXTVKE@avalon>
Laurent
On 12/13/2017 02:09 AM, Laurent Pinchart wrote:
> Hi Dan,
>
> Thank you for the patch.
>
> On Tuesday, 12 December 2017 23:50:23 EET Dan Murphy wrote:
>> Update the DT binding to remove the device name from
>> the DT parent node as well as removing the device
>> name from the label. The LED label will be generated
>> based off the id name stored in the local driver so
>> the LED function can be indicated in the label DT
>> entry.
>>
>> Also removed the indentation on the example.
>
> This makes the patch a bit harder to review and seems to be a matter of style.
>
I debated whether to remove the extra tabs. The changes below came from comments
from a recent LED driver I submitted.
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> .../devicetree/bindings/leds/ams,as3645a.txt | 36 ++++++++++---------
>> 1 file changed, 18 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
>> b/Documentation/devicetree/bindings/leds/ams,as3645a.txt index
>> fc7f5f9f234c..122aa7165cf3 100644
>> --- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
>> +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
>> @@ -58,22 +58,22 @@ label : The label of the indicator LED.
>
> I believe you should expand the documentation of the label property to detail
> how it should be formed. It's nice to update the example, but the bindings
> should be understandable without it.
OK. I will add a reference to Documentation/devicetree/bindings/leds/common.txt
label formation will be undergoing some changes. I wanted to make sure there were
some good examples in the LED tree for other developers to reference.
>
>> Example
>> =======
>>
>> - as3645a@30 {
>> - compatible = "ams,as3645a";
>> - #address-cells = <1>;
>> - #size-cells = <0>;
>> - reg = <0x30>;
>> - flash@0 {
>> - reg = <0x0>;
>> - flash-timeout-us = <150000>;
>> - flash-max-microamp = <320000>;
>> - led-max-microamp = <60000>;
>> - ams,input-max-microamp = <1750000>;
>> - label = "as3645a:flash";
>> - };
>> - indicator@1 {
>> - reg = <0x1>;
>> - led-max-microamp = <10000>;
>> - label = "as3645a:indicator";
>> - };
>> +led-controller@30 {
>
> This change looks fine to me.
>
>> + compatible = "ams,as3645a";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0x30>;
>> + led@0 {
>
> What's the rationale for changing the node name here ? It should be explained
> in the commit message, and in the DT bindings documentation.
In my patch to the DT maintainers Rob H indicated
"Actually, it should be led-controller and led or leds be used for the
LED child nodes (and gpio-led or pwd-led bindings)"
Here is the patch that the node naming conventions took place
https://patchwork.kernel.org/patch/10093757
>
>> + reg = <0x0>;
>> + flash-timeout-us = <150000>;
>> + flash-max-microamp = <320000>;
>> + led-max-microamp = <60000>;
>> + ams,input-max-microamp = <1750000>;
>> + label = "flash";
>> };
>> + led@1 {
>> + reg = <0x1>;
>> + led-max-microamp = <10000>;
>> + label = "indicator";
>> + };
>> +};
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH] leds: as3645a: Fix checkpatch warnings
From: Pavel Machek @ 2017-12-13 12:56 UTC (permalink / raw)
To: Dan Murphy
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, sakari.ailus-X3B1VOXEql0,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171212215011.30066-1-dmurphy-l0cyMroinI0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Tue 2017-12-12 15:50:11, Dan Murphy wrote:
> Fix two checkpatch warnings for 80 char
> length and for a quoted string across multiple
> line warnings.
>
> Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> ---
> drivers/leds/leds-as3645a.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/leds/leds-as3645a.c b/drivers/leds/leds-as3645a.c
> index 9a257f969300..f883616d9e60 100644
> --- a/drivers/leds/leds-as3645a.c
> +++ b/drivers/leds/leds-as3645a.c
> @@ -360,7 +360,8 @@ static int as3645a_set_flash_brightness(struct led_classdev_flash *fled,
> {
> struct as3645a *flash = fled_to_as3645a(fled);
>
> - flash->flash_current = as3645a_current_to_reg(flash, true, brightness_ua);
> + flash->flash_current = as3645a_current_to_reg(flash, true,
> + brightness_ua);
>
> return as3645a_set_current(flash);
> }
> @@ -455,8 +456,8 @@ static int as3645a_detect(struct as3645a *flash)
>
> /* Verify the chip model and version. */
> if (model != 0x01 || rfu != 0x00) {
> - dev_err(dev, "AS3645A not detected "
> - "(model %d rfu %d)\n", model, rfu);
> + dev_err(dev, "AS3645A not detected (model %d rfu %d)\n",
> + model, rfu);
> return -ENODEV;
> }
>
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: thermal: rcar: Add device tree support for r8a7743
From: Geert Uytterhoeven @ 2017-12-13 13:34 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, Zhang Rui, Eduardo Valentin,
Simon Horman, Magnus Damm, Chris Paterson,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas, Linux PM list
In-Reply-To: <1513162673-31531-2-git-send-email-biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
On Wed, Dec 13, 2017 at 11:57 AM, Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> wrote:
> Add thermal sensor support for r8a7743 SoC. The Renesas RZ/G1M
> (r8a7743) thermal sensor module is identical to the R-Car Gen2 family.
>
> No driver change is needed due to the fallback compatible value
> "renesas,rcar-gen2-thermal".
>
> Signed-off-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> Reviewed-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/6] ARM: sun4i: Convert to CCU
From: Maxime Ripard @ 2017-12-13 13:44 UTC (permalink / raw)
To: Kevin Hilman
Cc: Priit Laes, Chen-Yu Tsai, lkml, linux-arm-kernel, devicetree,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng, Russell King,
Mark Rutland, Rob Herring, Stephen Boyd, Michael Turquette,
Philipp Zabel, Olof Johansson
In-Reply-To: <CAOi56cUeRrKQnJ-akJPB160-60aBzy64bDgFeoqMpHRJSCnDeQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]
On Tue, Dec 12, 2017 at 01:24:52PM -0800, Kevin Hilman wrote:
> On Tue, Dec 12, 2017 at 9:26 AM, Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org> wrote:
> > On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote:
> >> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org> wrote:
> >> > Convert sun4i-a10.dtsi to new CCU driver.
> >> >
> >> > Signed-off-by: Priit Laes <plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
> >>
> >> I finally got around to bisecting a mainline boot failure on
> >> sun4i-a10-cubieboard that's been happening for quite a while. Based
> >> on on kernelci.org, it showed up sometime during the v4.15 merge
> >> window[1]. It bisected down to this commit (in mainline as commit
> >> 41193869f2bdb585ce09bfdd16d9482aadd560ad).
> >>
> >> When it fails, there is no output on the serial console, so I don't
> >> know exactly how it's failing, just that it no longer boots.
> >
> > We tried out latest 4.15 with various compilers and it works:
> > - gcc version 7.1.1 20170622 (Red Hat Cross 7.1.1-3) (GCC) - A10 Gemei G9 tablet
> > - gcc 7.2.0-debian - A10 Cubieboard
>
> And you can reproduce the bug with gcc5 or gcc6?
>
> Very strange that a DT only patch would cause a gcc related regression
> and if it does, it should be investigated. I don't think requiring
> gcc7 is an appropriate solution.
>
> @Chen-Yu, @Maxime: are you guys OK with requiring gcc7 for working
> upstream boot for A10?
I'd rather not set that kind of constraints and fix the issue instead.
Priit, can you test with an older compiler?
You can find one here:
http://toolchains.free-electrons.com/
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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