* [PATCH v2 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-11 10:14 UTC (permalink / raw)
To: rui.zhang, edubezval, robh+dt, mark.rutland, jun.nie
Cc: linux-pm, devicetree, linux-kernel, linux-arm-kernel, shawnguo,
baoyou.xie, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <1484129651-17531-1-git-send-email-baoyou.xie@linaro.org>
Add the zx2967 thermal drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 64f04df..2593296 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1981,6 +1981,7 @@ S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
F: drivers/soc/zte/
+F: drivers/thermal/zx*
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
F: Documentation/devicetree/bindings/soc/zte/
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] dt: bindings: add documentation for zx2967 family thermal sensor
From: Baoyou Xie @ 2017-01-11 10:14 UTC (permalink / raw)
To: rui.zhang, edubezval, robh+dt, mark.rutland, jun.nie
Cc: linux-pm, devicetree, linux-kernel, linux-arm-kernel, shawnguo,
baoyou.xie, xie.baoyou, chen.chaokai, wang.qiang01
This patch adds dt-binding documentation for zx2967 family thermal sensor.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
.../devicetree/bindings/thermal/zx2967-thermal.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
new file mode 100644
index 0000000..86f941c
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
@@ -0,0 +1,21 @@
+* ZTE zx2967 family Thermal
+
+Required Properties:
+- compatible: should be one of the following.
+ * zte,zx296718-thermal
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "gate" for the topcrm clock.
+ "pclk" for the apb clock.
+- #thermal-sensor-cells: must be 0.
+
+Example:
+
+ tempsensor: tempsensor@148a000 {
+ compatible = "zte,zx296718-thermal";
+ reg = <0x0148a000 0x20>;
+ clocks = <&topcrm TEMPSENSOR_GATE>, <&audiocrm AUDIO_TS_PCLK>;
+ clock-names = "gate", "pclk";
+ #thermal-sensor-cells = <0>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-11 10:10 UTC (permalink / raw)
To: xypron.glpk, khilman, carlo
Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.
The memory node is also moved from the dtsi files into the proper dts files
to handle variants memory sizes.
This patch also fixes the memory sizes for the following platforms :
- gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +++++++++
17 files changed, 106 insertions(+), 18 deletions(-)
Changes since resent v2 at [4]:
- Fix invalid comment of useable memory attributes
Changes since original v2 at [3]:
- Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
Changes since v2 at [2]:
- Moved all memory node out of dtsi
- Added comment about useable memory
- Fixed comment about secmon reserved zone
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong@baylibre.com
[2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong@baylibre.com
[3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong@baylibre.com
[4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong@baylibre.com
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..360ec0d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -54,11 +54,6 @@
stdout-path = "serial0:115200n8";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
- };
-
vddio_boot: regulator-vddio_boot {
compatible = "regulator-fixed";
regulator-name = "VDDIO_BOOT";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..66677b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 2MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon: secmon {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..54ffbff 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..1b474ba 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
index 03e3d76..af7b151 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p200", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P200 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
&i2c_B {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
index 39bb037..215096c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
@@ -49,4 +49,13 @@
/ {
compatible = "amlogic,p201", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P201 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f..8052a39 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -53,11 +53,6 @@
stdout-path = "serial0:115200n8";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
- };
-
usb_pwr: regulator-usb-pwrs {
compatible = "regulator-fixed";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
index 62fb496..8d6cfb9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
index 9a9663a..543e03a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
index 2fe167b..9a76fb5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index cea4a3e..ac874ac 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -60,7 +60,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index f66939c..2e2b821 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p230", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P230 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+ };
};
/* P230 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
index 95992cf..d252da9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p231", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P231 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
/* P231 has only internal PHY port */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
index 9639f01..86f7db0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
@@ -59,7 +59,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 5a337d3..2b65e06 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -62,7 +62,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio-boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
index 5dbc660..cdfe618 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,q200", "amlogic,s912", "amlogic,meson-gxm";
model = "Amlogic Meson GXM (S912) Q200 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+ };
};
/* Q200 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
index 95e11d7..9047ffa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,q201", "amlogic,s912", "amlogic,meson-gxm";
model = "Amlogic Meson GXM (S912) Q201 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB of the DDR memory zone
+ * is reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
/* Q201 has only internal PHY port */
--
1.9.1
^ permalink raw reply related
* Re: [PATCHv3 3/8] rtc: add STM32 RTC driver
From: Amelie DELAUNAY @ 2017-01-11 10:07 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Alessandro Zummo, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre TORGUE, Russell King,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Gabriel FERNANDEZ
In-Reply-To: <20170111000803.mlie6kizcsj2o7lh-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
Hi Alexandre,
On 01/11/2017 01:08 AM, Alexandre Belloni wrote:
> Looks good to me, however...
>
>
> On 05/01/2017 at 14:43:24 +0100, Amelie Delaunay wrote :
>> +struct stm32_rtc {
>> + struct rtc_device *rtc_dev;
>> + void __iomem *base;
>> + struct clk *ck_rtc;
>> + spinlock_t lock; /* Protects registers accesses */
>
> This spinlock seems to be useless, the rtc ops_lock is already
> protecting everywhere it is taken.
>
After having a deeper look on ops_lock, it seems this one is sufficient,
so I'll remove all spinlock uses in this driver.
>> + int irq_alarm;
>> +};
>> +
>
> [...]
>
>> +static int stm32_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
>> +{
>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>> + struct rtc_time *tm = &alrm->time;
>> + unsigned long irqflags;
>> + unsigned int cr, isr, alrmar;
>> + int ret = 0;
>> +
>> + if (rtc_valid_tm(tm)) {
>> + dev_err(dev, "Alarm time not valid.\n");
>> + return -EINVAL;
>
> This will never happen, tm is already checked multiple times (up to
> three) in the core before this function can be called.
>
You're right. I'll remove all rtc_valid_tm calls.
>> + }
>> +
>
> You don't need to resend the whole series, just this patch. I'll take
> 2/8 and 3/8, the other ones can go through the stm32 tree.
>
Thanks for reviewing. I send a v4 for this patch right now.
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [RESEND PATCH v3] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-11 9:55 UTC (permalink / raw)
To: xypron.glpk-Mmb7MZpHnFY, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.
The memory node is also moved from the dtsi files into the proper dts files
to handle variants memory sizes.
This patch also fixes the memory sizes for the following platforms :
- gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
- gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +++++++++
17 files changed, 106 insertions(+), 18 deletions(-)
Changes since original v2 at [3]:
- Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
Changes since v2 at [2]:
- Moved all memory node out of dtsi
- Added comment about useable memory
- Fixed comment about secmon reserved zone
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
[2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
[3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..360ec0d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -54,11 +54,6 @@
stdout-path = "serial0:115200n8";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
- };
-
vddio_boot: regulator-vddio_boot {
compatible = "regulator-fixed";
regulator-name = "VDDIO_BOOT";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..66677b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 2MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon: secmon {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..adcaf0b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..9d45fe6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
index 03e3d76..8ce7cc1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p200", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P200 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
&i2c_B {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
index 39bb037..0de22c7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
@@ -49,4 +49,13 @@
/ {
compatible = "amlogic,p201", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P201 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f..8052a39 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -53,11 +53,6 @@
stdout-path = "serial0:115200n8";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
- };
-
usb_pwr: regulator-usb-pwrs {
compatible = "regulator-fixed";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
index 62fb496..9d27e4f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
index 9a9663a..0112205 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
index 2fe167b..16bad57 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index cea4a3e..b9a354a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -60,7 +60,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index f66939c..d96d0c3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p230", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P230 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+ };
};
/* P230 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
index 95992cf..e21d3ff 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p231", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P231 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
/* P231 has only internal PHY port */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
index 9639f01..71c5a40 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
@@ -59,7 +59,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 5a337d3..2568e33 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -62,7 +62,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio-boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
index 5dbc660..2ef5e20 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,q200", "amlogic,s912", "amlogic,meson-gxm";
model = "Amlogic Meson GXM (S912) Q200 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+ };
};
/* Q200 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
index 95e11d7..017b9af 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,q201", "amlogic,s912", "amlogic,meson-gxm";
model = "Amlogic Meson GXM (S912) Q201 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
/* Q201 has only internal PHY port */
--
1.9.1
--
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 related
* Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: hoegeun kwon @ 2017-01-11 9:51 UTC (permalink / raw)
To: Andrzej Hajda, krzk, robh, thierry.reding, airlied, kgene
Cc: devicetree, linux-samsung-soc, linux-kernel, dri-devel, cw00.choi,
jh80.chung, andi.shyti, Hyungwon Hwang, Hoegeun Kwon
In-Reply-To: <f292435b-8faa-d2e9-17f6-99a4d00173c5@samsung.com>
On 01/11/2017 04:46 PM, Andrzej Hajda wrote:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang <human.hwang@samsung.com>
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>> compatible = "samsung,tm2", "samsung,exynos5433";
>> };
>>
>> +&dsi {
>> + panel@0 {
>> + compatible = "samsung,s6e3ha2";
>> + reg = <0>;
>> + vdd3-supply = <&ldo27_reg>;
>> + vci-supply = <&ldo28_reg>;
>> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.
Hi Andrzej,
Thanks for your quick review.
Reasonable to remove te-gpios property,
The Tizen public already has [1] your patch applied and te-gpios removed.
So I will add [1] to the V9 patch.
[1]
https://review.tizen.org/gerrit/gitweb?p=platform/kernel/linux-exynos.git;a=commitdiff;h=468769bf6abbaaed2547b8c43e989ab5dc787900
Best Regards,
Hoegeun
>
> Regards
> Andrzej
>> + };
>> +};
>> +
>> &hsi2c_9 {
>> status = "okay";
>>
>
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: da850: Add the cppi41 dma node
From: Sekhar Nori @ 2017-01-11 9:49 UTC (permalink / raw)
To: Alexandre Bailon, Sergei Shtylyov, khilman-rdvid1DuHRBWk0Htik3J/w
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0, david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <885f6118-16e8-2386-3016-6056d3259ad9-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Tuesday 10 January 2017 07:15 PM, Alexandre Bailon wrote:
> On 01/09/2017 07:26 PM, Sergei Shtylyov wrote:
>>> + 0x201000 0x1000
>>> + 0x202000 0x1000
>>> + 0x204000 0x4000>;
>>> + reg-names = "glue", "controller",
>>> + "scheduler", "queuemgr";
>>> + interrupts = <58>;
>>> + interrupt-names = "glue";
>>> + #dma-cells = <2>;
>>> + #dma-channels = <4>;
>>> + #dma-requests = <256>;
>>> + status = "disabled";
>>
>> Why disabled? It doesn't use any external pins...
> Will fix it.
Please keep it disabled. See the other thread on this.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v3] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-11 9:48 UTC (permalink / raw)
To: xypron.glpk-Mmb7MZpHnFY, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: Neil Armstrong, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds this reserved zone and redefines the usable memory range.
The memory node is also moved from the dtsi files into the proper dts files
to handle variants memory sizes.
This patch also fixes the memory sizes for the following platforms :
- gxl-s905x-p212 : 2GiB instead of 4GiB, a proper 4GiB dts should be pushed
- gxm-s912-q201 : 2GiB instead of 4GiB, a proper 4GiB dts should be pushed
- gxl-s905d-p231 : 2GiB instead of 4GiB, a proper 4GiB dts should be pushed
- gxl-nexbox-a95x : 2GiB instead of 4GiB, a proper 4GiB dts should be pushed
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -----
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +++++-
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +++++++++
17 files changed, 106 insertions(+), 18 deletions(-)
Changes since v2 at [2]:
- Moved all memory node out of dtsi
- Added comment about useable memory
- Fixed comment about secmon reserved zone
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
[2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..360ec0d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -54,11 +54,6 @@
stdout-path = "serial0:115200n8";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
- };
-
vddio_boot: regulator-vddio_boot {
compatible = "regulator-fixed";
regulator-name = "VDDIO_BOOT";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..66677b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,18 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 2MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon: secmon {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 4cbd626..adcaf0b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..9d45fe6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
index 03e3d76..8ce7cc1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p200", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P200 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
&i2c_B {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
index 39bb037..0de22c7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts
@@ -49,4 +49,13 @@
/ {
compatible = "amlogic,p201", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P201 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 4a96e0f..8052a39 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -53,11 +53,6 @@
stdout-path = "serial0:115200n8";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
- };
-
usb_pwr: regulator-usb-pwrs {
compatible = "regulator-fixed";
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
index 62fb496..9d27e4f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
index 9a9663a..0112205 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
index 2fe167b..16bad57 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
@@ -50,6 +50,10 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index cea4a3e..b9a354a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -60,7 +60,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index f66939c..d96d0c3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p230", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P230 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+ };
};
/* P230 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
index 95992cf..e21d3ff 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,p231", "amlogic,s905d", "amlogic,meson-gxl";
model = "Amlogic Meson GXL (S905D) P231 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
/* P231 has only internal PHY port */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
index 9639f01..71c5a40 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
@@ -59,7 +59,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 5a337d3..2568e33 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -62,7 +62,11 @@
memory@0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio-boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
index 5dbc660..2ef5e20 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,q200", "amlogic,s912", "amlogic,meson-gxm";
model = "Amlogic Meson GXM (S912) Q200 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
+ };
};
/* Q200 has exclusive choice between internal or external PHY */
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
index 95e11d7..017b9af 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts
@@ -49,6 +49,15 @@
/ {
compatible = "amlogic,q201", "amlogic,s912", "amlogic,meson-gxm";
model = "Amlogic Meson GXM (S912) Q201 Development Board";
+
+ memory@0 {
+ device_type = "memory";
+ /*
+ * The first 16MiB and last 16MiB of the DDR memory
+ * are reserved to the Hardware ROM Firmware
+ */
+ linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
+ };
};
/* Q201 has only internal PHY port */
--
1.9.1
--
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 related
* Re: [PATCH v1 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-11 9:46 UTC (permalink / raw)
To: Shawn Guo
Cc: rui.zhang, Eduardo Valentin, Rob Herring, mark.rutland, Jun Nie,
Greg KH, davem, geert+renesas, akpm, mchehab, Guenter Roeck,
linux-pm, devicetree, Linux Kernel Mailing List, linux-arm-kernel,
xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <20170109030023.GK20956@dragon>
[-- Attachment #1: Type: text/plain, Size: 10633 bytes --]
On 9 January 2017 at 11:00, Shawn Guo <shawnguo@kernel.org> wrote:
> On Sat, Jan 07, 2017 at 01:38:08PM +0800, Baoyou Xie wrote:
> > This patch adds thermal driver for ZTE's zx2967 family.
> >
> > Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> > ---
> > drivers/thermal/Kconfig | 6 +
> > drivers/thermal/Makefile | 1 +
> > drivers/thermal/zx2967_thermal.c | 241 ++++++++++++++++++++++++++++++
> +++++++++
> > 3 files changed, 248 insertions(+)
> > create mode 100644 drivers/thermal/zx2967_thermal.c
> >
> > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > index 18f2de6..0dd597e 100644
> > --- a/drivers/thermal/Kconfig
> > +++ b/drivers/thermal/Kconfig
> > @@ -445,3 +445,9 @@ config BCM2835_THERMAL
> > Support for thermal sensors on Broadcom bcm2835 SoCs.
> >
> > endif
> > +
> > +config ZX2967_THERMAL
> > + tristate "Thermal sensors on zx2967 SoC"
> > + depends on ARCH_ZX
> > + help
> > + Support for thermal sensors on ZTE zx2967 SoCs.
> > diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> > index 677c6d9..c00c05e 100644
> > --- a/drivers/thermal/Makefile
> > +++ b/drivers/thermal/Makefile
> > @@ -57,3 +57,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
> > obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
> > obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
> > obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
> > +obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
> > diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_
> thermal.c
> > new file mode 100644
> > index 0000000..1aef070
> > --- /dev/null
> > +++ b/drivers/thermal/zx2967_thermal.c
> > @@ -0,0 +1,241 @@
> > +/*
> > + * ZTE's zx2967 family thermal sensor driver
> > + *
> > + * Copyright (C) 2017 ZTE Ltd.
> > + *
> > + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> > + *
> > + * License terms: GNU General Public License (GPL) version 2
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/device.h>
> > +#include <linux/io.h>
> > +#include <linux/err.h>
> > +#include <linux/clk.h>
> > +#include <linux/delay.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/thermal.h>
> > +
> > +/* DCF Control Register */
> > +#define ZX2967_THERMAL_DCF 0x4
> > +
> > +/* Selection Register */
> > +#define ZX2967_THERMAL_SEL 0x8
> > +
> > +/* Control Register */
> > +#define ZX2967_THERMAL_CTRL 0x10
> > +
> > +#define ZX2967_THERMAL_ID_MASK (0x18)
> > +
> > +struct zx2967_thermal_sensor {
> > + struct zx2967_thermal_priv *priv;
> > + struct thermal_zone_device *tzd;
> > + int id;
> > +};
> > +
> > +#define NUM_SENSORS 1
> > +
> > +struct zx2967_thermal_priv {
> > + struct zx2967_thermal_sensor sensors[NUM_SENSORS];
>
> What's the point of defining an array with only one element?
>
> we might support 2 sensors in future, so I suggest to remain it.
> > + struct mutex lock;
> > + struct clk *clk_gate;
> > + struct clk *pclk;
> > + void __iomem *regs;
>
> > + struct pinctrl *pinmux_dvi0_d3;
> > + struct pinctrl *pinmux_dvi0_d4;
> > + struct pinctrl *pinmux_dvi0_d5;
>
> These three pointers are not used.
>
> > +};
> > +
> > +static int zx2967_thermal_suspend(struct device *dev)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
> > +
> > + if (priv && priv->pclk)
> > + clk_disable_unprepare(priv->pclk);
> > +
> > + if (priv && priv->clk_gate)
> > + clk_disable_unprepare(priv->clk_gate);
> > + dev_info(dev, "suspended\n");
>
> Noisy message.
>
> > +
> > + return 0;
> > +}
> > +
> > +static int zx2967_thermal_resume(struct device *dev)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
> > + int error;
> > +
> > + error = clk_prepare_enable(priv->clk_gate);
> > + if (error)
> > + return error;
> > +
> > + error = clk_prepare_enable(priv->pclk);
> > + if (error)
> > + return error;
>
> clk_disable_unprepare() should be called for priv->clk_gate before
> returning here.
>
> > +
> > + dev_info(dev, "resumed\n");
> > +
> > + return 0;
> > +}
> > +
> > +static int zx2967_thermal_get_temp(void *data, int *temp)
> > +{
> > + void __iomem *regs;
> > + struct zx2967_thermal_sensor *sensor = data;
> > + struct zx2967_thermal_priv *priv = sensor->priv;
> > + unsigned long timeout = jiffies + msecs_to_jiffies(100);
> > + u32 val, sel_id;
> > +
> > + regs = priv->regs;
> > + mutex_lock(&priv->lock);
> > +
> > + writel_relaxed(0, regs);
>
> I suggest we have a macro for register at offset 0 as well to improve
> the readability.
>
> > + writel_relaxed(2, regs + ZX2967_THERMAL_DCF);
> > +
> > + val = readl_relaxed(regs + ZX2967_THERMAL_SEL);
> > + val &= ~ZX2967_THERMAL_ID_MASK;
> > + sel_id = sensor->id ? 8 : 0x10;
> > + val |= sel_id;
> > + writel_relaxed(val, regs + ZX2967_THERMAL_SEL);
> > +
> > + usleep_range(100, 300);
> > + while (!(readl_relaxed(regs + ZX2967_THERMAL_CTRL) & 0x1000)) {
> > + if (time_after(jiffies, timeout)) {
> > + pr_err("*** Thermal sensor %d data timeout\n",
> > + sensor->id);
>
> dev_err? And drop "*** ".
>
> oh, we don't hold device reference here.
> > + mutex_unlock(&priv->lock);
> > + return -EIO;
>
> -ETIMEDOUT?
>
> > + }
> > + }
> > +
> > + writel_relaxed(3, regs + ZX2967_THERMAL_DCF);
> > + val = readl_relaxed(regs + ZX2967_THERMAL_CTRL) & 0xfff;
> > + writel_relaxed(1, regs);
> > +
> > + /** Calculate temperature */
> > + *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);
> > +
> > + mutex_unlock(&priv->lock);
> > +
> > + return 0;
> > +}
> > +
> > +static struct thermal_zone_of_device_ops zx2967_of_thermal_ops = {
> > + .get_temp = zx2967_thermal_get_temp,
> > +};
> > +
> > +static int zx2967_thermal_probe(struct platform_device *pdev)
> > +{
> > + struct zx2967_thermal_priv *priv;
> > + struct resource *res;
> > + int ret, i;
> > +
> > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->regs = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(priv->regs))
> > + return PTR_ERR(priv->regs);
> > +
> > + priv->clk_gate = devm_clk_get(&pdev->dev, "tempsensor_gate");
> > + if (IS_ERR(priv->clk_gate)) {
> > + ret = PTR_ERR(priv->clk_gate);
> > + dev_err(&pdev->dev, "failed to get clock gate: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(priv->clk_gate);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to enable converter clock:
> %d\n",
> > + ret);
> > + return ret;
> > + }
> > +
> > + priv->pclk = devm_clk_get(&pdev->dev, "tempsensor_pclk");
> > + if (IS_ERR(priv->pclk)) {
> > + ret = PTR_ERR(priv->pclk);
> > + dev_err(&pdev->dev, "failed to get apb clock: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + ret = clk_prepare_enable(priv->pclk);
> > + if (ret) {
> > + dev_err(&pdev->dev, "failed to enable converter clock:
> %d\n",
> > + ret);
> > + return ret;
>
> The use count of enable and prepare on priv->clk_gate will be
> unbalanced.
>
> we called devm_clk_get, thus when it fails, the framework will happy to
release it.
> > + }
> > +
> > + mutex_init(&priv->lock);
> > + for (i = 0; i < NUM_SENSORS; i++) {
> > + struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
> > +
> > + sensor->priv = priv;
> > + sensor->id = i;
> > + sensor->tzd = thermal_zone_of_sensor_register(&pdev->dev,
> > + i,
> > + sensor,
> > + &zx2967_of_thermal_ops);
> > + if (IS_ERR(sensor->tzd)) {
> > + ret = PTR_ERR(sensor->tzd);
> > + dev_err(&pdev->dev, "failed to register sensor %d:
> %d\n",
> > + i, ret);
> > + goto remove_ts;
> > + }
> > + }
> > + platform_set_drvdata(pdev, priv);
> > +
> > + return 0;
> > +
> > +remove_ts:
> > + for (i--; i >= 0; i--)
> > + thermal_zone_of_sensor_unregister(&pdev->dev,
> > + priv->sensors[i].tzd);
> > +
> > + return ret;
>
> Unbalanced clk_prepare_enable(priv->pclk).
>
> Shawn
>
> > +}
> > +
> > +static int zx2967_thermal_exit(struct platform_device *pdev)
> > +{
> > + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
> > + int i;
> > +
> > + for (i = 0; i < NUM_SENSORS; i++) {
> > + struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
> > +
> > + thermal_zone_of_sensor_unregister(&pdev->dev,
> sensor->tzd);
> > + }
> > + clk_disable_unprepare(priv->pclk);
> > + clk_disable_unprepare(priv->clk_gate);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id zx2967_thermal_id_table[] = {
> > + { .compatible = "zte,zx2967-thermal" },
> > + { .compatible = "zte,zx296718-thermal" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, zx2967_thermal_id_table);
> > +
> > +static SIMPLE_DEV_PM_OPS(zx2967_thermal_pm_ops,
> > + zx2967_thermal_suspend, zx2967_thermal_resume);
> > +
> > +static struct platform_driver zx2967_thermal_driver = {
> > + .probe = zx2967_thermal_probe,
> > + .remove = zx2967_thermal_exit,
> > + .driver = {
> > + .name = "zx2967_thermal",
> > + .of_match_table = zx2967_thermal_id_table,
> > + .pm = &zx2967_thermal_pm_ops,
> > + },
> > +};
> > +module_platform_driver(zx2967_thermal_driver);
> > +
> > +MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
> > +MODULE_DESCRIPTION("ZTE zx2967 thermal driver");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.7.4
> >
>
[-- Attachment #2: Type: text/html, Size: 15367 bytes --]
^ permalink raw reply
* Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Andrzej Hajda @ 2017-01-11 9:39 UTC (permalink / raw)
To: Inki Dae, Hoegeun Kwon, krzk, robh, thierry.reding, airlied,
kgene
Cc: dri-devel, linux-kernel, devicetree, linux-samsung-soc, cw00.choi,
jh80.chung, andi.shyti, Hyungwon Hwang
In-Reply-To: <5875EF69.1070803@samsung.com>
On 11.01.2017 09:40, Inki Dae wrote:
>
> 2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
>> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>>> From: Hyungwon Hwang <human.hwang@samsung.com>
>>>
>>> This patch add the panel device tree node for S6E3HA2 display
>>> controller to TM2 dts.
>>>
>>> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
>>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> index ddba2f8..6d362f9 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> @@ -18,6 +18,18 @@
>>> compatible = "samsung,tm2", "samsung,exynos5433";
>>> };
>>>
>>> +&dsi {
>>> + panel@0 {
>>> + compatible = "samsung,s6e3ha2";
>>> + reg = <0>;
>>> + vdd3-supply = <&ldo27_reg>;
>>> + vci-supply = <&ldo28_reg>;
>>> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>>> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>>> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
>> The same here (as in 1st comment) , te-gpios should be dropper - decon
>> uses hw-trigger.
> Reasonable to remove te-gpios property but this change would make MIPI-DSI driver probing to be failed so MIPI-DSI driver should be fixed together.
>
> Thanks.
OK, I forgot it was not yet ported to mainline.
Regards
Andrzej
>
>> Regards
>> Andrzej
>>> + };
>>> +};
>>> +
>>> &hsi2c_9 {
>>> status = "okay";
>>>
>>
>>
>>
>
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-11 9:36 UTC (permalink / raw)
To: Rob Clark
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-arm-msm, Sricharan R, Jordan Crouse, Mark Rutland,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAF6AEGsCJ6L-wmBHFYy2jfQ1bfq_d2wmiWVUXno344US9ikLVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Jan 10, 2017 at 02:20:13PM -0500, Rob Clark wrote:
> On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
> >> Hmm, well we install the fault handler on the iommu_domain.. perhaps
> >> maybe a combo of dts property (or deciding based on more specific
> >> compat string), plus extra param passed in to
> >> iommu_set_fault_hander(). The dts property or compat string to
> >> indicate whether the iommu (and how it is wired up) can handle stalls,
> >> and enable_stall param when fault handler is registered to indicate
> >> whether the device itself can cope.. if either can't do stalling, then
> >> don't set CFCFG.
> >
> > I thought about this some more, and I think you're right. Having
> > iommu_set_fault_handler take a flags parameter indicating that, for example,
> > the fault handler can deal with paging, is all we need to implement the
> > per-master opt-in functionality for stalling faults. There's no real
> > requirement to standardise a generic firmware property for that (but
> > we still need *something* that says stalling is usable on the SMMU --
> > perhaps just the compatible string is ok).
>
> btw, it occurred to me that maybe it should be flags param to
> iommu_attach_device() (just in case fault handler not installed?)
> otoh stalling without a fault handler is silly, but I guess we need it
> to infer whether stalling can be supported by other devices on same
> iommu.. tbh I'm on a bit shaky ground when it comes to multiple
> devices per iommu since the SoC's I'm familiar with do it the other
> way around. But I guess you have thought more about the multi-device
> case, so figured I should suggest it..
I don't think it works at attach time, because the stalling property belongs
to the domain, rather than the individual devices within it. Similarly, I
don't think we should allow this property to be toggled once devices have
been attached.
Will
--
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 08/11] dmaengine: cppi41: Implement the glue for da8xx
From: Sekhar Nori @ 2017-01-11 9:35 UTC (permalink / raw)
To: Tony Lindgren, Alexandre Bailon
Cc: Grygorii Strashko, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, khilman-rdvid1DuHRBWk0Htik3J/w,
ptitiano-rdvid1DuHRBWk0Htik3J/w,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170110154929.GU2630-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tuesday 10 January 2017 09:19 PM, Tony Lindgren wrote:
> * Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> [170110 07:23]:
>> On 01/10/2017 11:05 AM, Sekhar Nori wrote:
>>> On DA8xx, CPPI 4.1 DMAengine is not an independent system resource, but
>>> embedded within the USB 2.0 controller. So, I think all that is needed
>>> is for MUSB DA8xx glue to trigger probe of CPPI 4.1 dmaengine driver
>>> when it is ready. I am not sure all this DA850-specific clock handling
>>> is really necessary.
>> Actually, we have a circular dependency.
>> USB core tries to get DMA channels during the probe, which fails because
>> CPPI 4.1 driver is not ready.
>> But it will never be ready because the USB clock must be enabled before
>> DMA driver probe, what will not happen because USB driver have disabled
>> the clock when probe failed.
>>
>> Someone in the office suggested me to use the component API,
>> that could help me to probe the DMA from the USB probe.
>>
>> Another way to workaround the dependency would be to do defer the
>> function calls that access to hardware to avoid to control clock from
>> DMA driver.
>
> Or you really have some wrapper IP block around musb and cppi41 just
> like am335x has.
>
> See drivers/usb/musb/musb_am335x.c and compatible properties for
> "ti,am33xx-usb" and it's children in am33xx.dtsi.
This looks like what will will need to da850 too.
Alexandre,
If the wrapper is going to work, can you see if it will end up breaking
DT compatibility once introduced? If yes, I suggest reverting the usb1
DT node in da850-lcdk.dts so we don't get into a DT compatibility
problem once v4.10 releases.
Thanks,
Sekhar
--
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 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Wang @ 2017-01-11 9:27 UTC (permalink / raw)
To: Andi Shyti
Cc: kbuild test robot, kbuild-all, mchehab, hdegoede, hkallweit1,
robh+dt, mark.rutland, matthias.bgg, hverkuil, sean,
ivo.g.dimitrov.75, linux-media, devicetree, linux-mediatek,
linux-arm-kernel, linux-kernel, keyhaede
In-Reply-To: <20170110224543.uuoa7ofkvolz6inp@gangnam.samsung>
okay, I will continue to work based on your changes unless someone else
has concerns
On Wed, 2017-01-11 at 07:45 +0900, Andi Shyti wrote:
> Hi Sean,
>
> > include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
> > >> drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for function devm_rc_allocate_device
> > drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
> > drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function 'devm_rc_allocate_device'
> > ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> > ^~~~~~~~~~~~~~~~~~~~~~~
> > In file included from drivers/media/rc/mtk-cir.c:22:0:
> > include/media/rc-core.h:213:16: note: declared here
> > struct rc_dev *devm_rc_allocate_device(struct device *dev);
> > ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > vim +/devm_rc_allocate_device +215 drivers/media/rc/mtk-cir.c
> >
> > 209 ir->base = devm_ioremap_resource(dev, res);
> > 210 if (IS_ERR(ir->base)) {
> > 211 dev_err(dev, "failed to map registers\n");
> > 212 return PTR_ERR(ir->base);
> > 213 }
> > 214
> > > 215 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
>
> this error comes because the patches I pointed out have not been
> applied yet. I guess you can ignore them as long as you tested
> yours on top those patches.
>
> Andi
^ permalink raw reply
* Re: [PATCH 08/11] dmaengine: cppi41: Implement the glue for da8xx
From: Alexandre Bailon @ 2017-01-11 9:24 UTC (permalink / raw)
To: Sergei Shtylyov, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <2d8b3a2b-859d-bfda-74cf-f22471927fc4-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On 01/10/2017 06:53 PM, Sergei Shtylyov wrote:
> On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
>
>> The da8xx has a cppi41 dma controller.
>
> It's called CPPI 4.1. :-)
>
>> This is add the glue layer required to make it work on da8xx,
>> as well some changes in driver (e.g to manage clock).
>>
>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> drivers/dma/cppi41.c | 95
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 95 insertions(+)
>>
>> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
>> index 939398e..4318e53 100644
>> --- a/drivers/dma/cppi41.c
>> +++ b/drivers/dma/cppi41.c
> [...]
>> @@ -86,10 +87,19 @@
>>
>> #define USBSS_IRQ_PD_COMP (1 << 2)
>>
>> +/* USB DA8XX */
>> +#define DA8XX_INTR_SRC_MASKED 0x38
>> +#define DA8XX_END_OF_INTR 0x3c
>> +
>> +#define DA8XX_QMGR_PENDING_MASK (0xf << 24)
>> +
>> +
>> +
>
> One empty line is enough.
>
>> /* Packet Descriptor */
>> #define PD2_ZERO_LENGTH (1 << 19)
>>
>> #define AM335X_CPPI41 0
>> +#define DA8XX_CPPI41 1
>>
>> struct cppi41_channel {
>> struct dma_chan chan;
> [...]
>> @@ -366,6 +393,26 @@ static irqreturn_t am335x_cppi41_irq(int irq,
>> void *data)
>> return cppi41_irq(cdd);
>> }
>>
>> +static irqreturn_t da8xx_cppi41_irq(int irq, void *data)
>> +{
>> + struct cppi41_dd *cdd = data;
>> + u32 status;
>> + u32 usbss_status;
>> +
>> + status = cppi_readl(cdd->qmgr_mem + QMGR_PEND(0));
>> + if (status & DA8XX_QMGR_PENDING_MASK)
>> + cppi41_irq(cdd);
>> + else
>> + return IRQ_NONE;
>
> Seems correct...
>
>> +
>> + /* Re-assert IRQ if there no usb core interrupts pending */
>> + usbss_status = cppi_readl(cdd->usbss_mem + DA8XX_INTR_SRC_MASKED);
>> + if (!usbss_status)
>> + cppi_writel(0, cdd->usbss_mem + DA8XX_END_OF_INTR);
>
> I don't understand this...
Well, it might not be necessary anymore.
I had an issue with teardown. After a teardown, USB were not working
anymore.
It was because an interrupt was fired on teardown completion but
because the completion queue was empty, interrupt was ignored by the
interrupt handler. And in USB driver, because the interrupt was not
fired by USB core, then interrupt was ignored and never re-asserted.
But I guess the change I made in patch 11 should prevent this issue.
>
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> static dma_cookie_t cppi41_tx_submit(struct dma_async_tx_descriptor *tx)
>> {
>> dma_cookie_t cookie;
> [...]
>
> MBR, Sergei
>
--
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] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-11 9:19 UTC (permalink / raw)
To: Heinrich Schuchardt, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5c99bc3d-58ae-0434-4b68-bc0445f928ad-Mmb7MZpHnFY@public.gmane.org>
On 12/30/2016 03:51 PM, Heinrich Schuchardt wrote:
> On 12/30/2016 02:40 PM, Neil Armstrong wrote:
>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>> this patch adds this reserved zone and redefines the usable memory range.
>>
>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> Changes since v1 at [1] :
>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>> - only kept secmon memory zone
>>
>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
>>
>> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
>> arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
>> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
>> 11 files changed, 22 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> index 7a078be..ca3c7fa 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
>> @@ -56,7 +56,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x80000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> vddio_boot: regulator-vddio_boot {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> index eada0b5..7f244b5 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -55,6 +55,18 @@
>> #address-cells = <2>;
>> #size-cells = <2>;
>>
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + /* global autoconfigured region for contiguous allocations */
>
> This comment does not make sense here. It is what you would write over a
> compatible to "shared-dma-pool" region. Cf. hi6220-hikey.dts
>
> I suggest you use
> /* Amlogic Meson GXBB/GXL/GXM secure monitor reserved memory */
> instead.
Yes, will fix this in a similar manner.
>
> Doesn't firmware/meson/meson_sm.c already reserve a communication area
> to secmon with quite a different address range?
> So where is this new region secmon set up? And where is it used?
Yes, it gets the memory zone from the secure monitor and reserves it, only if enabled and very late.
Neil
>
> Best regards
>
> Heinrich
>
>> + secmon: secmon {
>> + reg = <0x0 0x10000000 0x0 0x200000>;
>> + no-map;
>> + };
>> + };
>> +
>> cpus {
>> #address-cells = <0x2>;
>> #size-cells = <0x0>;
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> index 4cbd626..c7f008a 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
>> @@ -62,7 +62,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x40000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
>> };
>>
>> leds {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> index 238fbea..546cbe4 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
>> @@ -61,7 +61,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x80000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> usb_otg_pwr: regulator-usb-pwrs {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> index 4a96e0f..1fdf6da 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
>> @@ -55,7 +55,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x40000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
>> };
>>
>> usb_pwr: regulator-usb-pwrs {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
>> index 62fb496..6ac5c89 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
>> @@ -50,6 +50,6 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x80000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>> };
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
>> index 9a9663a..58be8b4 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
>> @@ -50,6 +50,6 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x40000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
>> };
>> };
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
>> index 2fe167b..010cb29 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
>> @@ -50,6 +50,6 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x80000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>> };
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> index cea4a3e..fb4a89b 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
>> @@ -60,7 +60,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x80000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> vddio_card: gpio-regulator {
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
>> index 9639f01..908894c 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
>> @@ -59,7 +59,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x80000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>> };
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> index 5a337d3..2077385 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
>> @@ -62,7 +62,7 @@
>>
>> memory@0 {
>> device_type = "memory";
>> - reg = <0x0 0x0 0x0 0x80000000>;
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> vddio_boot: regulator-vddio-boot {
>>
>
--
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 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Wang @ 2017-01-11 9:19 UTC (permalink / raw)
To: Sean Young
Cc: mchehab-JPH+aEBZ4P+UEJcrhfAQsw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170110172355.GA27008-3XSxi2G4b3iXFJAUJl40Xg@public.gmane.org>
On Tue, 2017-01-10 at 17:23 +0000, Sean Young wrote:
> Hi Sean,
>
> > >
> > > The kernel guarantees that calls to the interrupt handler are serialised,
> > > no need to disable the interrupt in the handler.
> >
> > agreed. I will save the mtk irq disable/enable and retest again.
> >
> >
> > > > +
> > > > + /* Reset decoder state machine */
> > > > + ir_raw_event_reset(ir->rc);
> > >
> > > Not needed.
> >
> >
> > two reasons I added the line here
> >
> > 1)
> > I thought it is possible the decoder goes to the
> > middle state when getting the data not belonged
> > to the protocol. If so, that would cause the decoding
> > fails in the next time receiving the valid protocol data.
>
> The last IR event submitted will always be a long space, that's enough
> to reset the decoders. Adding a ir_raw_event_reset() will do this
> more explicitly, rather than their state machines resetting themselves
> through the trailing space.
thanks for the detailed explanation :) i got it
but some hardware limitation let me can't do it in implicit way :(
reset decoder state machine explicitly is needed because
1) the longest duration for space MTK IR hardware can record is not
safely long. e.g 12ms if rx resolution is 46us by default. There is
still the risk to satisfying every decoder to reset themselves through
long enough trailing spaces
2) the IRQ handler called guarantees that start of IR message is always
contained in and starting from register MTK_CHKDATA_REG(0).
I will add these words for hardware limitation into comments in the
driver
> > 2)
> > the mtk hardware register always contains the start of
> > IR message. So force to sync the state between
> > HW and ir-core.
> >
> >
> >
> > > > +
> > > > + /* First message must be pulse */
> > > > + rawir.pulse = false;
> > >
> > > pulse = true?
> >
> > becasue of rawir.pulse = !rawir.pulse does as below
> > so the initial value is set as false.
>
> Ah, sorry, of course. :)
>
> > > > +
> > > > + /* Handle all pulse and space IR controller captures */
> > > > + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > > > + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > > > + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > > > +
> > > > + for (j = 0 ; j < 4 ; j++) {
> > > > + wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
> > > > + rawir.pulse = !rawir.pulse;
> > > > + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > > > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > > > + }
> > >
> > > In v1 you would break out of the loop if the ir message was shorter, but
> > > now you are always passing on 68 pulses and spaces. Is that right?
> >
> > as I asked in the previous mail list as below i copied from it, so i
> > made some changes ...
> >
> > """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> > > I had another question. I found multiple and same IR messages being
> > > received when using SONY remote controller. Should driver needs to
> > > report each message or only one of these to the upper layer ?
> >
> > In general the driver shouldn't try to change any IR message, this
> > should be done in rc-core if necessary.
> >
> > rc-core should handle this correctly. If the same key is received twice
> > within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
> > layer.
> > """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> >
> > for example:
> > the 68 pulse/spaces might contains 2.x IR messages when I
> > pressed one key on SONY remote control.
> >
> > the v1 proposed is passing only one IR message into ir-core ;
> > the v2 done is passing all IR messages even including the last
> > incomplete message into ir-core.
>
> Yes, agreed. Sorry if I wasn't clear. I just wanted to make sure you've
> thought about what happens when the IR message is short (e.g. rc-5 with
> 23 pulse-spaces). Are the remaining registers 0 or do we get stale data
> from a previous transmit?
Before exit from this IRQ handler , mtk_w32_mask(ir, 0x1, MTK_IRCLR,
MTK_IRCLR_REG) would be done that causes all registers used to store
pulses and spaces to be cleared, so no stale data appears in the next
transmit.
> > But I was still afraid the state machine can't go back to initial state
> > after receiving these incomplete data.
> >
> > So the ir_raw_event_reset() call in the beginning of ISR seems becoming
> > more important.
> >
> > > > + }
> > > > +
> > > > + /* The maximum number of edges the IR controller can
> > > > + * hold is MTK_CHKDATA_SZ * 4. So if received IR messages
> > > > + * is over the limit, the last incomplete IR message would
> > > > + * be appended trailing space and still would be sent into
> > > > + * ir-rc-raw to decode. That helps it is possible that it
> > > > + * has enough information to decode a scancode even if the
> > > > + * trailing end of the message is missing.
> > > > + */
> > > > + if (!MTK_IR_END(wid, rawir.pulse)) {
> > > > + rawir.pulse = false;
> > > > + rawir.duration = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> > > > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > > > + }
>
> See here you add a long space if one was not added already.
>
> > > > +
> > > > + ir_raw_event_handle(ir->rc);
> > > > +
> > > > + /* Restart controller for the next receive */
> > > > + mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
> > > > +
> > > > + /* Clear interrupt status */
> > > > + mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
> > > > +
> > > > + /* Enable interrupt */
> > > > + mtk_irq_enable(ir, MTK_IRINT_EN);
> > > > +
> > > > + return IRQ_HANDLED;
> > > > +}
> > > > +
> > > > +static int mtk_ir_probe(struct platform_device *pdev)
> > > > +{
> > > > + struct device *dev = &pdev->dev;
> > > > + struct device_node *dn = dev->of_node;
> > > > + struct resource *res;
> > > > + struct mtk_ir *ir;
> > > > + u32 val;
> > > > + int ret = 0;
> > > > + const char *map_name;
> > > > +
> > > > + ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
> > > > + if (!ir)
> > > > + return -ENOMEM;
> > > > +
> > > > + ir->dev = dev;
> > > > +
> > > > + if (!of_device_is_compatible(dn, "mediatek,mt7623-cir"))
> > > > + return -ENODEV;
> > > > +
> > > > + ir->clk = devm_clk_get(dev, "clk");
> > > > + if (IS_ERR(ir->clk)) {
> > > > + dev_err(dev, "failed to get a ir clock.\n");
> > > > + return PTR_ERR(ir->clk);
> > > > + }
> > > > +
> > > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > + ir->base = devm_ioremap_resource(dev, res);
> > > > + if (IS_ERR(ir->base)) {
> > > > + dev_err(dev, "failed to map registers\n");
> > > > + return PTR_ERR(ir->base);
> > > > + }
> > > > +
> > > > + ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> > > > + if (!ir->rc) {
> > > > + dev_err(dev, "failed to allocate device\n");
> > > > + return -ENOMEM;
> > > > + }
> > > > +
> > > > + ir->rc->priv = ir;
> > > > + ir->rc->input_name = MTK_IR_DEV;
> > > > + ir->rc->input_phys = MTK_IR_DEV "/input0";
> > > > + ir->rc->input_id.bustype = BUS_HOST;
> > > > + ir->rc->input_id.vendor = 0x0001;
> > > > + ir->rc->input_id.product = 0x0001;
> > > > + ir->rc->input_id.version = 0x0001;
> > > > + map_name = of_get_property(dn, "linux,rc-map-name", NULL);
> > > > + ir->rc->map_name = map_name ?: RC_MAP_EMPTY;
> > > > + ir->rc->dev.parent = dev;
> > > > + ir->rc->driver_name = MTK_IR_DEV;
> > > > + ir->rc->allowed_protocols = RC_BIT_ALL;
> > > > + ir->rc->rx_resolution = MTK_IR_SAMPLE;
> > > > + ir->rc->timeout = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> > > > +
> > > > + ret = devm_rc_register_device(dev, ir->rc);
> > >
> > > Here you do devm_rc_register_device()
> >
> > does it have problem ?
>
> Sorry, no. I just wanted to highlight wrt a comment below.
> >
> >
> > > > + if (ret) {
> > > > + dev_err(dev, "failed to register rc device\n");
> > > > + return ret;
> > > > + }
> > > > +
> > > > + platform_set_drvdata(pdev, ir);
> > > > +
> > > > + ir->irq = platform_get_irq(pdev, 0);
> > > > + if (ir->irq < 0) {
> > > > + dev_err(dev, "no irq resource\n");
> > > > + return -ENODEV;
> > > > + }
> > > > +
> > > > + /* Enable interrupt after proper hardware
> > > > + * setup and IRQ handler registration
> > > > + */
> > > > + if (clk_prepare_enable(ir->clk)) {
> > > > + dev_err(dev, "try to enable ir_clk failed\n");
> > > > + ret = -EINVAL;
> > > > + goto exit_clkdisable_clk;
> > > > + }
> > > > +
> > > > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > > > +
> > > > + ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
> > > > + if (ret) {
> > > > + dev_err(dev, "failed request irq\n");
> > > > + goto exit_clkdisable_clk;
> > > > + }
> > > > +
> > > > + /* Enable IR and PWM */
> > > > + val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
> > > > + val |= MTK_PWM_EN | MTK_IR_EN;
> > > > + mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
> > > > +
> > > > + /* Setting sample period */
> > > > + mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
> > > > + MTK_CONFIG_LOW_REG);
> > > > +
> > > > + mtk_irq_enable(ir, MTK_IRINT_EN);
> > > > +
> > > > + dev_info(dev, "Initialized MT7623 IR driver, sample period = %luus\n",
> > > > + DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, 1000));
> > > > +
> > > > + return 0;
> > > > +
> > > > +exit_clkdisable_clk:
> > > > + clk_disable_unprepare(ir->clk);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int mtk_ir_remove(struct platform_device *pdev)
> > > > +{
> > > > + struct mtk_ir *ir = platform_get_drvdata(pdev);
> > > > +
> > > > + /* Avoid contention between remove handler and
> > > > + * IRQ handler so that disabling IR interrupt and
> > > > + * waiting for pending IRQ handler to complete
> > > > + */
> > > > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > > > + synchronize_irq(ir->irq);
> > > > +
> > > > + clk_disable_unprepare(ir->clk);
> > > > +
> > > > + rc_unregister_device(ir->rc);
> > >
> > > Yet here you explicitly call rc_unregister_device(). Since it was registered
> > > with the devm call, this call is not needed and will lead to double frees etc
> >
> > bug :( . I will fix it ..
> >
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static const struct of_device_id mtk_ir_match[] = {
> > > > + { .compatible = "mediatek,mt7623-cir" },
> > > > + {},
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, mtk_ir_match);
> > > > +
> > > > +static struct platform_driver mtk_ir_driver = {
> > > > + .probe = mtk_ir_probe,
> > > > + .remove = mtk_ir_remove,
> > > > + .driver = {
> > > > + .name = MTK_IR_DEV,
> > > > + .of_match_table = mtk_ir_match,
> > > > + },
> > > > +};
> > > > +
> > > > +module_platform_driver(mtk_ir_driver);
> > > > +
> > > > +MODULE_DESCRIPTION("Mediatek IR Receiver Controller Driver");
> > > > +MODULE_AUTHOR("Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>");
> > > > +MODULE_LICENSE("GPL");
> > > > --
> > > > 2.7.4
> > > >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 v1 1/1] iio: adc: tlc4541: add support for TI tlc4541 adc
From: Peter Meerwald-Stadler @ 2017-01-11 9:17 UTC (permalink / raw)
To: Phil Reid
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5f800162-a404-09fa-ce1b-c95f5b73ac56-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
On Wed, 11 Jan 2017, Phil Reid wrote:
> Oops, title should be PATCH V2.
>
> On 11/01/2017 14:51, Phil Reid wrote:
> > This adds TI's tlc4541 16-bit ADC driver. Which is a single channel
> > ADC. Supports raw and trigger buffer access.
> > Also supports the tlc3541 14-bit device, which has not been tested.
> > Implementation of the tlc3541 is fairly straight forward thou.
comments below
>
> > Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
> > ---
> >
> > Notes:
> > Changes from v1:
> > - Add tlc3541 support and chan spec.
> > - remove fields that where already 0 from TLC4541_V_CHAN macro
> > - Increase rx_buf size in tlc4541_state to avoid copy in
> > tlc4541_trigger_handle
> > - Remove erroneous be16_to_cpu in tlc4541_trigger_handle
> > - Docs/binding: spi -> SPI & add ti,tlc3541
> >
> > I haven't add Rob's Ack due to adding a new compatible string.
> >
> > I tried to ".index = 1" from the spec as suggested by Peter, but that
> > didn't
> > seem to work. Perhaps remove of .channel was the intended target.
the only between index = 0/1 should be that the channel is called
in_voltage0_raw vs in_voltage_raw in sysfs -- maybe there is an issue in
iio_readdev?
> > Example output from iio_readdev
> >
> > with ".index = 1"
> > root@cyclone5:~# mkdir /sys/kernel/config/iio/triggers/hrtimer/hr1
> > root@cyclone5:~# iio_readdev -t hr1 -b 32 -s 10 tlc4541 | hexdump
> > WARNING: High-speed mode not enabled
> > 0000000 af00 0000 0000 0000 b922 ca99 93da 1492
> > 0000010 a800 00ff 0000 0000 b246 cb30 93da 1492
> > 0000020 a900 0000 0000 0000 4f9c cbc9 93da 1492
> > 0000030 aa00 00ff 0000 0000 bd2c cc61 93da 1492
> > 0000040 aa00 00ff 0000 0000 544c ccfa 93da 1492
> > 0000050 ab00 00ff 0000 0000 e806 cd92 93da 1492
> > 0000060 a900 00ff 0000 0000 846c ce2b 93da 1492
> > 0000070 ab00 0000 0000 0000 2efc cec8 93da 1492
> > 0000080 a800 00ff 0000 0000 b090 cf5c 93da 1492
> > 0000090 a900 00ff 0000 0000 476a cff5 93da 1492
> >
> > without .index
> > root@cyclone5:~# mkdir /sys/kernel/config/iio/triggers/hrtimer/hr1
> > root@cyclone5:~# iio_readdev -t hr1 -b 32 -s 10 tlc4541 | hexdump
> > WARNING: High-speed mode not enabled
> > 0000000 6db0 eeb6 93e3 1492 35e0 ef4f 93e3 1492
> > 0000010 4b34 efe5 93e3 1492 e9f2 f07d 93e3 1492
> > 0000020 6182 f116 93e3 1492 090a f1af 93e3 1492
> > 0000030 409c f249 93e3 1492 6c1a f2e0 93e3 1492
> > 0000040 cd02 f378 93e3 1492 9582 f411 93e3 1492
> >
> > .../devicetree/bindings/iio/adc/ti-tlc4541.txt | 17 ++
> > drivers/iio/adc/Kconfig | 11 +
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/ti-tlc4541.c | 276
> > +++++++++++++++++++++
> > 4 files changed, 305 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-tlc4541.txt
> > create mode 100644 drivers/iio/adc/ti-tlc4541.c
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/ti-tlc4541.txt
> > b/Documentation/devicetree/bindings/iio/adc/ti-tlc4541.txt
> > new file mode 100644
> > index 0000000..e1de2bd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/adc/ti-tlc4541.txt
> > @@ -0,0 +1,17 @@
> > +* Texas Instruments' TLC4541
> > +
> > +Required properties:
> > + - compatible: Should be one of
> > + * "ti,tlc4541"
> > + * "ti,tlc3541"
> > + - reg: SPI chip select number for the device
> > + - vref-supply: The regulator supply for ADC reference voltage
> > + - spi-max-frequency: Max SPI frequency to use (<= 200000)
> > +
> > +Example:
> > +adc@0 {
> > + compatible = "ti,adc0832";
pasto here, should be ti,tlc4541 probably
> > + reg = <0>;
> > + vref-supply = <&vdd_supply>;
> > + spi-max-frequency = <200000>;
> > +};
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 99c0514..4dda3f0 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -525,6 +525,17 @@ config TI_AM335X_ADC
> > To compile this driver as a module, choose M here: the module will
> > be
> > called ti_am335x_adc.
> >
> > +config TI_TLC4541
> > + tristate "Texas Instruments TLC4541 ADC driver"
> > + depends on SPI
> > + select IIO_BUFFER
> > + select IIO_TRIGGERED_BUFFER
> > + help
> > + Say yes here to build support for Texas Instruments TLC4541 ADC
mention TLC3541 here as well?
> > chip.
> > +
> > + This driver can also be built as a module. If so, the module will be
> > + called ti-tlc4541.
> > +
> > config TWL4030_MADC
> > tristate "TWL4030 MADC (Monitoring A/D Converter)"
> > depends on TWL4030_CORE
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 7a40c04..9bf2377 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -49,6 +49,7 @@ obj-$(CONFIG_TI_ADC161S626) += ti-adc161s626.o
> > obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
> > obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
> > obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> > +obj-$(CONFIG_TI_TLC4541) += ti-tlc4541.o
> > obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> > obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> > obj-$(CONFIG_VF610_ADC) += vf610_adc.o
> > diff --git a/drivers/iio/adc/ti-tlc4541.c b/drivers/iio/adc/ti-tlc4541.c
> > new file mode 100644
> > index 0000000..a0cd5e1
> > --- /dev/null
> > +++ b/drivers/iio/adc/ti-tlc4541.c
> > @@ -0,0 +1,276 @@
> > +/*
> > + * TI tlc4541 ADC Driver
> > + *
> > + * Copyright (C) 2017 Phil Reid
> > + *
> > + * Datasheets can be found here:
> > + * http://www.ti.com/lit/gpn/tlc3541
> > + * http://www.ti.com/lit/gpn/tlc4541
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * The tlc4541 requires 24 clock cycles to start a transfer.
> > + * Conversion then takes 2.94us to complete before data is ready
> > + * Data is returned MSB first.
> > + */
> > +
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/iio/iio.h>
> > +#include <linux/iio/sysfs.h>
> > +#include <linux/iio/buffer.h>
> > +#include <linux/iio/trigger_consumer.h>
> > +#include <linux/iio/triggered_buffer.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/slab.h>
> > +#include <linux/spi/spi.h>
> > +#include <linux/sysfs.h>
> > +
> > +struct tlc4541_state {
> > + struct spi_device *spi;
> > + struct regulator *reg;
> > + struct spi_transfer scan_single_xfer[3];
> > + struct spi_message scan_single_msg;
> > +
> > + /*
> > + * DMA (thus cache coherency maintenance) requires the
> > + * transfer buffers to live in their own cache lines.
> > + * 2 bytes data + 6 bytes padding + 8 bytes timestamp when
> > + * call iio_push_to_buffers_with_timestamp.
> > + */
> > + __be16 rx_buf[8] ____cacheline_aligned;
> > +};
> > +
> > +struct tlc4541_chip_info {
> > + const struct iio_chan_spec *channels;
> > + unsigned int num_channels;
> > +};
> > +
> > +enum tlc4541_id {
> > + TLC3541,
> > + TLC4541,
> > +};
> > +
> > +#define TLC4541_V_CHAN(bits, bitshift) { \
> > + .type = IIO_VOLTAGE, \
> > + .indexed = 1, \
shouldn't be needed
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> > + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> > + .scan_type = { \
> > + .sign = 'u', \
> > + .realbits = (bits), \
> > + .storagebits = 16, \
> > + .shift = bitshift, \
(bitshift)
> > + .endianness = IIO_BE, \
> > + }, \
> > + }
> > +
> > +#define DECLARE_TLC4541_CHANNELS(name, bits, bitshift) \
> > +const struct iio_chan_spec name ## _channels[] = { \
> > + TLC4541_V_CHAN(bits, bitshift), \
> > + IIO_CHAN_SOFT_TIMESTAMP(1), \
> > +}
> > +
> > +static DECLARE_TLC4541_CHANNELS(tlc4541, 16, 0);
> > +static DECLARE_TLC4541_CHANNELS(tlc3541, 14, 2);
maybe always keep the chip variants in the same order, the enum has 3541
first
> > +
> > +static const struct tlc4541_chip_info tlc4541_chip_info[] = {
> > + [TLC4541] = {
> > + .channels = tlc4541_channels,
> > + .num_channels = ARRAY_SIZE(tlc4541_channels),
> > + },
> > + [TLC3541] = {
> > + .channels = tlc3541_channels,
> > + .num_channels = ARRAY_SIZE(tlc3541_channels),
> > + },
> > +};
> > +
> > +static irqreturn_t tlc4541_trigger_handler(int irq, void *p)
> > +{
> > + struct iio_poll_func *pf = p;
> > + struct iio_dev *indio_dev = pf->indio_dev;
> > + struct tlc4541_state *st = iio_priv(indio_dev);
> > + int ret;
> > +
> > + ret = spi_sync(st->spi, &st->scan_single_msg);
> > + if (ret < 0)
> > + goto done;
> > +
> > + iio_push_to_buffers_with_timestamp(indio_dev, st->rx_buf,
> > + iio_get_time_ns(indio_dev));
> > +
> > +done:
> > + iio_trigger_notify_done(indio_dev->trig);
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int tlc4541_get_range(struct tlc4541_state *st)
> > +{
> > + int vref;
> > +
> > + vref = regulator_get_voltage(st->reg);
> > + if (vref < 0)
> > + return vref;
> > +
> > + vref /= 1000;
> > +
> > + return vref;
> > +}
> > +
> > +static int tlc4541_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + int *val,
> > + int *val2,
> > + long m)
> > +{
> > + int ret = 0;
> > + struct tlc4541_state *st = iio_priv(indio_dev);
> > +
> > + switch (m) {
> > + case IIO_CHAN_INFO_RAW:
> > + ret = iio_device_claim_direct_mode(indio_dev);
> > + if (ret)
> > + return ret;
> > + ret = spi_sync(st->spi, &st->scan_single_msg);
> > + iio_device_release_direct_mode(indio_dev);
> > + if (ret < 0)
> > + return ret;
> > + *val = be16_to_cpu(st->rx_buf[0]);
> > + *val = *val >> chan->scan_type.shift;
> > + *val &= GENMASK(chan->scan_type.realbits - 1, 0);
is the GENMASK() necessary?, the trigger handler doesn't do it
> > + return IIO_VAL_INT;
> > + case IIO_CHAN_INFO_SCALE:
> > + ret = tlc4541_get_range(st);
> > + if (ret < 0)
> > + return ret;
> > + *val = ret;
> > + *val2 = chan->scan_type.realbits;
> > + return IIO_VAL_FRACTIONAL_LOG2;
> > + }
> > + return -EINVAL;
> > +}
> > +
> > +static const struct iio_info tlc4541_info = {
> > + .read_raw = &tlc4541_read_raw,
> > + .driver_module = THIS_MODULE,
> > +};
> > +
> > +static int tlc4541_probe(struct spi_device *spi)
> > +{
> > + struct tlc4541_state *st;
> > + struct iio_dev *indio_dev;
> > + const struct tlc4541_chip_info *info;
> > + int ret;
> > + int8_t device_init = 0;
> > +
> > + indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
wondering what happens to the cache aligned rx_buf here?
> > + if (indio_dev == NULL)
> > + return -ENOMEM;
> > +
> > + st = iio_priv(indio_dev);
> > +
> > + spi_set_drvdata(spi, indio_dev);
> > +
> > + st->spi = spi;
> > +
> > + info = &tlc4541_chip_info[spi_get_device_id(spi)->driver_data];
> > +
> > + indio_dev->name = spi_get_device_id(spi)->name;
> > + indio_dev->dev.parent = &spi->dev;
> > + indio_dev->modes = INDIO_DIRECT_MODE;
> > + indio_dev->channels = info->channels;
> > + indio_dev->num_channels = info->num_channels;
> > + indio_dev->info = &tlc4541_info;
> > +
> > + /* perform reset */
> > + spi_write(spi, &device_init, 1);
> > +
> > + /* Setup default message */
> > + st->scan_single_xfer[0].rx_buf = &st->rx_buf[0];
> > + st->scan_single_xfer[0].len = 3;
> > + st->scan_single_xfer[1].delay_usecs = 3;
> > + st->scan_single_xfer[2].rx_buf = &st->rx_buf[0];
> > + st->scan_single_xfer[2].len = 2;
> > +
> > + spi_message_init(&st->scan_single_msg);
> > + spi_message_add_tail(&st->scan_single_xfer[0], &st->scan_single_msg);
> > + spi_message_add_tail(&st->scan_single_xfer[1], &st->scan_single_msg);
> > + spi_message_add_tail(&st->scan_single_xfer[2], &st->scan_single_msg);
> > +
> > + st->reg = devm_regulator_get(&spi->dev, "vref");
> > + if (IS_ERR(st->reg))
> > + return PTR_ERR(st->reg);
> > +
> > + ret = regulator_enable(st->reg);
> > + if (ret)
> > + return ret;
> > +
> > + ret = iio_triggered_buffer_setup(indio_dev, NULL,
> > + &tlc4541_trigger_handler, NULL);
> > + if (ret)
> > + goto error_disable_reg;
> > +
> > + ret = iio_device_register(indio_dev);
> > + if (ret)
> > + goto error_cleanup_buffer;
> > +
> > + return 0;
> > +
> > +error_cleanup_buffer:
> > + iio_triggered_buffer_cleanup(indio_dev);
> > +error_disable_reg:
> > + regulator_disable(st->reg);
> > +
> > + return ret;
> > +}
> > +
> > +static int tlc4541_remove(struct spi_device *spi)
> > +{
> > + struct iio_dev *indio_dev = spi_get_drvdata(spi);
> > + struct tlc4541_state *st = iio_priv(indio_dev);
> > +
> > + iio_device_unregister(indio_dev);
> > + iio_triggered_buffer_cleanup(indio_dev);
> > + regulator_disable(st->reg);
> > +
> > + return 0;
> > +}
> > +
> > +#ifdef CONFIG_OF
maybe drop the newlines here?
> > +
> > +static const struct of_device_id tlc4541_dt_ids[] = {
> > + { .compatible = "ti,tlc3541", },
> > + { .compatible = "ti,tlc4541", },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, tlc4541_dt_ids);
> > +
> > +#endif
> > +
> > +static const struct spi_device_id tlc4541_id[] = {
> > + {"tlc3541", TLC3541},
> > + {"tlc4541", TLC4541},
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(spi, tlc4541_id);
> > +
> > +static struct spi_driver tlc4541_driver = {
> > + .driver = {
> > + .name = "tlc4541",
> > + .of_match_table = of_match_ptr(tlc4541_dt_ids),
> > + },
> > + .probe = tlc4541_probe,
> > + .remove = tlc4541_remove,
> > + .id_table = tlc4541_id,
> > +};
> > +module_spi_driver(tlc4541_driver);
> > +
> > +MODULE_AUTHOR("Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>");
> > +MODULE_DESCRIPTION("Texas Instruments TLC4541 ADC");
> > +MODULE_LICENSE("GPL v2");
> >
>
>
>
--
Peter Meerwald-Stadler
+43-664-2444418 (mobile)
^ permalink raw reply
* Re: [PATCH 08/11] dmaengine: cppi41: Implement the glue for da8xx
From: Alexandre Bailon @ 2017-01-11 9:16 UTC (permalink / raw)
To: Sekhar Nori, Grygorii Strashko, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, khilman-rdvid1DuHRBWk0Htik3J/w,
ptitiano-rdvid1DuHRBWk0Htik3J/w, tony-4v6yS6AI5VpBDgjK7y7TUQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <43b9585d-a22f-a2ff-15d4-5d878bd1586a-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/10/2017 04:22 PM, Alexandre Bailon wrote:
> On 01/10/2017 11:05 AM, Sekhar Nori wrote:
>> On Tuesday 10 January 2017 03:08 PM, Alexandre Bailon wrote:
>>> On 01/09/2017 07:08 PM, Grygorii Strashko wrote:
>>>>
>>>>
>>>> On 01/09/2017 10:06 AM, Alexandre Bailon wrote:
>>>>> The da8xx has a cppi41 dma controller.
>>>>> This is add the glue layer required to make it work on da8xx,
>>>>> as well some changes in driver (e.g to manage clock).
>>>>>
>>>>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>>> ---
>>>>> drivers/dma/cppi41.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 95 insertions(+)
>>>>>
>>>>> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
>>>>> index 939398e..4318e53 100644
>>>>> --- a/drivers/dma/cppi41.c
>>>>> +++ b/drivers/dma/cppi41.c
>>>>> @@ -1,3 +1,4 @@
>>>>> +#include <linux/clk.h>
>>>>> #include <linux/delay.h>
>>>>> #include <linux/dmaengine.h>
>>>>> #include <linux/dma-mapping.h>
>>>>> @@ -86,10 +87,19 @@
>>>>>
>>>>> #define USBSS_IRQ_PD_COMP (1 << 2)
>>>>>
>>>>> +/* USB DA8XX */
>>>>> +#define DA8XX_INTR_SRC_MASKED 0x38
>>>>> +#define DA8XX_END_OF_INTR 0x3c
>>>>> +
>>>>> +#define DA8XX_QMGR_PENDING_MASK (0xf << 24)
>>>>> +
>>>>> +
>>>>> +
>>>>> /* Packet Descriptor */
>>>>> #define PD2_ZERO_LENGTH (1 << 19)
>>>>>
>>>>> #define AM335X_CPPI41 0
>>>>> +#define DA8XX_CPPI41 1
>>>>>
>>>>> struct cppi41_channel {
>>>>> struct dma_chan chan;
>>>>> @@ -158,6 +168,9 @@ struct cppi41_dd {
>>>>>
>>>>> /* context for suspend/resume */
>>>>> unsigned int dma_tdfdq;
>>>>> +
>>>>> + /* da8xx clock */
>>>>> + struct clk *clk;
>>>>> };
>>>>>
>>>>> static struct chan_queues am335x_usb_queues_tx[] = {
>>>>> @@ -232,6 +245,20 @@ static const struct chan_queues am335x_usb_queues_rx[] = {
>>>>> [29] = { .submit = 30, .complete = 155},
>>>>> };
>>>>>
>>>>> +static const struct chan_queues da8xx_usb_queues_tx[] = {
>>>>> + [0] = { .submit = 16, .complete = 24},
>>>>> + [1] = { .submit = 18, .complete = 24},
>>>>> + [2] = { .submit = 20, .complete = 24},
>>>>> + [3] = { .submit = 22, .complete = 24},
>>>>> +};
>>>>> +
>>>>> +static const struct chan_queues da8xx_usb_queues_rx[] = {
>>>>> + [0] = { .submit = 1, .complete = 26},
>>>>> + [1] = { .submit = 3, .complete = 26},
>>>>> + [2] = { .submit = 5, .complete = 26},
>>>>> + [3] = { .submit = 7, .complete = 26},
>>>>> +};
>>>>> +
>>>>> struct cppi_glue_infos {
>>>>> irqreturn_t (*isr)(int irq, void *data);
>>>>> const struct chan_queues *queues_rx;
>>>>> @@ -366,6 +393,26 @@ static irqreturn_t am335x_cppi41_irq(int irq, void *data)
>>>>> return cppi41_irq(cdd);
>>>>> }
>>>>>
>>>>> +static irqreturn_t da8xx_cppi41_irq(int irq, void *data)
>>>>> +{
>>>>> + struct cppi41_dd *cdd = data;
>>>>> + u32 status;
>>>>> + u32 usbss_status;
>>>>> +
>>>>> + status = cppi_readl(cdd->qmgr_mem + QMGR_PEND(0));
>>>>> + if (status & DA8XX_QMGR_PENDING_MASK)
>>>>> + cppi41_irq(cdd);
>>>>> + else
>>>>> + return IRQ_NONE;
>>>>> +
>>>>> + /* Re-assert IRQ if there no usb core interrupts pending */
>>>>> + usbss_status = cppi_readl(cdd->usbss_mem + DA8XX_INTR_SRC_MASKED);
>>>>> + if (!usbss_status)
>>>>> + cppi_writel(0, cdd->usbss_mem + DA8XX_END_OF_INTR);
>>>>> +
>>>>> + return IRQ_HANDLED;
>>>>> +}
>>>>> +
>>>>> static dma_cookie_t cppi41_tx_submit(struct dma_async_tx_descriptor *tx)
>>>>> {
>>>>> dma_cookie_t cookie;
>>>>> @@ -972,8 +1019,19 @@ static const struct cppi_glue_infos am335x_usb_infos = {
>>>>> .platform = AM335X_CPPI41,
>>>>> };
>>>>>
>>>>> +static const struct cppi_glue_infos da8xx_usb_infos = {
>>>>> + .isr = da8xx_cppi41_irq,
>>>>> + .queues_rx = da8xx_usb_queues_rx,
>>>>> + .queues_tx = da8xx_usb_queues_tx,
>>>>> + .td_queue = { .submit = 31, .complete = 0 },
>>>>> + .first_completion_queue = 24,
>>>>> + .qmgr_num_pend = 2,
>>>>> + .platform = DA8XX_CPPI41,
>>>>> +};
>>>>> +
>>>>> static const struct of_device_id cppi41_dma_ids[] = {
>>>>> { .compatible = "ti,am3359-cppi41", .data = &am335x_usb_infos},
>>>>> + { .compatible = "ti,da8xx-cppi41", .data = &da8xx_usb_infos},
>>>>> {},
>>>>> };
>>>>> MODULE_DEVICE_TABLE(of, cppi41_dma_ids);
>>>>> @@ -995,6 +1053,13 @@ static int is_am335x_cppi41(struct device *dev)
>>>>> return cdd->platform == AM335X_CPPI41;
>>>>> }
>>>>>
>>>>> +static int is_da8xx_cppi41(struct device *dev)
>>>>> +{
>>>>> + struct cppi41_dd *cdd = dev_get_drvdata(dev);
>>>>> +
>>>>> + return cdd->platform == DA8XX_CPPI41;
>>>>> +}
>>>>> +
>>>>> #define CPPI41_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
>>>>> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
>>>>> BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
>>>>> @@ -1058,6 +1123,21 @@ static int cppi41_dma_probe(struct platform_device *pdev)
>>>>> cdd->first_completion_queue = glue_info->first_completion_queue;
>>>>> cdd->platform = glue_info->platform;
>>>>>
>>>>> + if (is_da8xx_cppi41(dev)) {
>>>>> + cdd->clk = devm_clk_get(&pdev->dev, "usb20");
>>>>> + ret = PTR_ERR_OR_ZERO(cdd->clk);
>>>>> + if (ret) {
>>>>> + dev_err(&pdev->dev, "failed to get clock\n");
>>>>> + goto err_clk_en;
>>>>> + }
>>>>> +
>>>>> + ret = clk_prepare_enable(cdd->clk);
>>>>> + if (ret) {
>>>>> + dev_err(dev, "failed to enable clock\n");
>>>>> + goto err_clk_en;
>>>>> + }
>>>>> + }
>>>>
>>>> if this is functional clock then why not to use ./arch/arm/mach-davinci/pm_domain.c ?
>>>> wouldn't it work for use if you will just rename "usb20" -> "fck" -
>>>> so PM runtime should manage this clock for you?
>>> As is, I don't think it will work.
>>> The usb20 is shared by the cppi41 and the usb otg.
>>> So, if we rename "usb20" to "fck", clk_get() won't be able to find the
>>> clock.
>>> But may be adding "usb20" to "con_ids" in
>>> arch/arm/mach-davinci/pm_domain.c could work.
>>> But I think it will require some changes in da8xx musb driver.
>>> I will take look.
>>
>> On DA8xx, CPPI 4.1 DMAengine is not an independent system resource, but
>> embedded within the USB 2.0 controller. So, I think all that is needed
>> is for MUSB DA8xx glue to trigger probe of CPPI 4.1 dmaengine driver
>> when it is ready. I am not sure all this DA850-specific clock handling
>> is really necessary.
> Actually, we have a circular dependency.
> USB core tries to get DMA channels during the probe, which fails because
> CPPI 4.1 driver is not ready.
> But it will never be ready because the USB clock must be enabled before
> DMA driver probe, what will not happen because USB driver have disabled
> the clock when probe failed.
>
> Someone in the office suggested me to use the component API,
> that could help me to probe the DMA from the USB probe.
>
> Another way to workaround the dependency would be to do defer the
> function calls that access to hardware to avoid to control clock from
> DMA driver.
>>
>> Even in DT, the CPPI 4.1 node should be a child node of USB 2.0 node.
> I agree, it should a child but it would require some changes in CPPI 4.1
> driver. But except to have a better hardware description, I don't see
> any benefit to do it.
Finally, I have been able to do it and there is real benefit to do it
(unlike I thought).
Now that the CPPI 4.1 is a child of USB 2.0, I only have to update
the DA8xx glue driver to support PM runtime and let PM runtime do
everything in CPPI 4.1 driver.
>>
>> Thanks,
>> sekhar
>>
> Thanks,
> Alexandre
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v1 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-11 8:54 UTC (permalink / raw)
To: Jun Nie
Cc: rui.zhang, Eduardo Valentin, Rob Herring, mark.rutland, Greg KH,
davem, geert+renesas, akpm, mchehab, Guenter Roeck, linux-pm,
devicetree, Linux Kernel Mailing List, linux-arm-kernel,
Shawn Guo, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <843c634a-c624-e7db-99f6-8efdc19d7243@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 11032 bytes --]
On 9 January 2017 at 11:00, Jun Nie <jun.nie@linaro.org> wrote:
> On 2017年01月07日 13:38, Baoyou Xie wrote:
>
>> This patch adds thermal driver for ZTE's zx2967 family.
>>
>> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
>> ---
>> drivers/thermal/Kconfig | 6 +
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/zx2967_thermal.c | 241 ++++++++++++++++++++++++++++++
>> +++++++++
>> 3 files changed, 248 insertions(+)
>> create mode 100644 drivers/thermal/zx2967_thermal.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 18f2de6..0dd597e 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -445,3 +445,9 @@ config BCM2835_THERMAL
>> Support for thermal sensors on Broadcom bcm2835 SoCs.
>>
>> endif
>> +
>> +config ZX2967_THERMAL
>> + tristate "Thermal sensors on zx2967 SoC"
>> + depends on ARCH_ZX
>> + help
>> + Support for thermal sensors on ZTE zx2967 SoCs.
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 677c6d9..c00c05e 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -57,3 +57,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>> obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
>> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
>> obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
>> +obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
>> diff --git a/drivers/thermal/zx2967_thermal.c
>> b/drivers/thermal/zx2967_thermal.c
>> new file mode 100644
>> index 0000000..1aef070
>> --- /dev/null
>> +++ b/drivers/thermal/zx2967_thermal.c
>> @@ -0,0 +1,241 @@
>> +/*
>> + * ZTE's zx2967 family thermal sensor driver
>> + *
>> + * Copyright (C) 2017 ZTE Ltd.
>> + *
>> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
>> + *
>> + * License terms: GNU General Public License (GPL) version 2
>> + */
>> +
>> +#include <linux/module.h>
>>
> Please follow alphabet sequence.
>
> +#include <linux/device.h>
>> +#include <linux/io.h>
>> +#include <linux/err.h>
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/thermal.h>
>> +
>> +/* DCF Control Register */
>> +#define ZX2967_THERMAL_DCF 0x4
>> +
>> +/* Selection Register */
>> +#define ZX2967_THERMAL_SEL 0x8
>> +
>> +/* Control Register */
>> +#define ZX2967_THERMAL_CTRL 0x10
>> +
>> +#define ZX2967_THERMAL_ID_MASK (0x18)
>> +
>> +struct zx2967_thermal_sensor {
>> + struct zx2967_thermal_priv *priv;
>> + struct thermal_zone_device *tzd;
>> + int id;
>> +};
>> +
>> +#define NUM_SENSORS 1
>> +
>> +struct zx2967_thermal_priv {
>> + struct zx2967_thermal_sensor sensors[NUM_SENSORS];
>> + struct mutex lock;
>> + struct clk *clk_gate;
>> + struct clk *pclk;
>> + void __iomem *regs;
>> + struct pinctrl *pinmux_dvi0_d3;
>> + struct pinctrl *pinmux_dvi0_d4;
>> + struct pinctrl *pinmux_dvi0_d5;
>>
>
> I do not see usage of pinmux_div0_d*, please remove it.
>
>
> +};
>> +
>> +static int zx2967_thermal_suspend(struct device *dev)
>> +{
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
>> +
>> + if (priv && priv->pclk)
>> + clk_disable_unprepare(priv->pclk);
>> +
>> + if (priv && priv->clk_gate)
>> + clk_disable_unprepare(priv->clk_gate);
>> + dev_info(dev, "suspended\n");
>> +
>> + return 0;
>> +}
>> +
>> +static int zx2967_thermal_resume(struct device *dev)
>> +{
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
>> + int error;
>> +
>> + error = clk_prepare_enable(priv->clk_gate);
>> + if (error)
>>
> Use IS_ERR(ret) to check error.
>
>> + return error;
>> +
>> + error = clk_prepare_enable(priv->pclk);
>> + if (error)
>>
> Ditto.
>
>> + return error;
>> +
>> + dev_info(dev, "resumed\n");
>> +
>> + return 0;
>> +}
>> +
>> +static int zx2967_thermal_get_temp(void *data, int *temp)
>> +{
>> + void __iomem *regs;
>> + struct zx2967_thermal_sensor *sensor = data;
>> + struct zx2967_thermal_priv *priv = sensor->priv;
>> + unsigned long timeout = jiffies + msecs_to_jiffies(100);
>> + u32 val, sel_id;
>> +
>> + regs = priv->regs;
>> + mutex_lock(&priv->lock);
>> +
>> + writel_relaxed(0, regs);
>> + writel_relaxed(2, regs + ZX2967_THERMAL_DCF);
>> +
>> + val = readl_relaxed(regs + ZX2967_THERMAL_SEL);
>> + val &= ~ZX2967_THERMAL_ID_MASK;
>> + sel_id = sensor->id ? 8 : 0x10;
>>
>
> You can define a macro for 8 and 0x10. BTW: NUM_SENSORS is 1 currently,
> you can change it to 2 if hardware support it. Or you can add TODO mark for
> later work.
>
> we can't change NUM_SENSORS to 2, cause of hardware supports only 1 sensor
now. BTW: it can support 2 sensor, so we're happy to remain this code.
> + val |= sel_id;
>> + writel_relaxed(val, regs + ZX2967_THERMAL_SEL);
>> +
>> + usleep_range(100, 300);
>> + while (!(readl_relaxed(regs + ZX2967_THERMAL_CTRL) & 0x1000)) {
>> + if (time_after(jiffies, timeout)) {
>> + pr_err("*** Thermal sensor %d data timeout\n",
>> + sensor->id);
>> + mutex_unlock(&priv->lock);
>> + return -EIO;
>> + }
>> + }
>> +
>> + writel_relaxed(3, regs + ZX2967_THERMAL_DCF);
>> + val = readl_relaxed(regs + ZX2967_THERMAL_CTRL) & 0xfff;
>>
>
> Define 0xfff as a macro.
>
>
> + writel_relaxed(1, regs);
>> +
>> + /** Calculate temperature */
>> + *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);
>> +
>> + mutex_unlock(&priv->lock);
>> +
>> + return 0;
>> +}
>> +
>> +static struct thermal_zone_of_device_ops zx2967_of_thermal_ops = {
>> + .get_temp = zx2967_thermal_get_temp,
>> +};
>> +
>> +static int zx2967_thermal_probe(struct platform_device *pdev)
>> +{
>> + struct zx2967_thermal_priv *priv;
>> + struct resource *res;
>> + int ret, i;
>> +
>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>> + if (!priv)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + priv->regs = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(priv->regs))
>> + return PTR_ERR(priv->regs);
>> +
>> + priv->clk_gate = devm_clk_get(&pdev->dev, "tempsensor_gate");
>> + if (IS_ERR(priv->clk_gate)) {
>> + ret = PTR_ERR(priv->clk_gate);
>> + dev_err(&pdev->dev, "failed to get clock gate: %d\n",
>> ret);
>> + return ret;
>> + }
>> +
>> + ret = clk_prepare_enable(priv->clk_gate);
>> + if (ret) {
>>
> Use IS_ERR(ret) to check error.
>
> + dev_err(&pdev->dev, "failed to enable converter clock:
>> %d\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + priv->pclk = devm_clk_get(&pdev->dev, "tempsensor_pclk");
>> + if (IS_ERR(priv->pclk)) {
>> + ret = PTR_ERR(priv->pclk);
>> + dev_err(&pdev->dev, "failed to get apb clock: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = clk_prepare_enable(priv->pclk);
>> + if (ret) {
>>
> Ditto.
>
> + dev_err(&pdev->dev, "failed to enable converter clock:
>> %d\n",
>> + ret);
>> + return ret;
>> + }
>> +
>> + mutex_init(&priv->lock);
>> + for (i = 0; i < NUM_SENSORS; i++) {
>> + struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
>> +
>> + sensor->priv = priv;
>> + sensor->id = i;
>> + sensor->tzd = thermal_zone_of_sensor_register(&pdev->dev,
>> + i,
>> + sensor,
>>
> No need to create new line.
>
>
> + &zx2967_of_thermal_ops);
>> + if (IS_ERR(sensor->tzd)) {
>> + ret = PTR_ERR(sensor->tzd);
>> + dev_err(&pdev->dev, "failed to register sensor
>> %d: %d\n",
>> + i, ret);
>> + goto remove_ts;
>> + }
>> + }
>> + platform_set_drvdata(pdev, priv);
>> +
>> + return 0;
>> +
>> +remove_ts:
>> + for (i--; i >= 0; i--)
>> + thermal_zone_of_sensor_unregister(&pdev->dev,
>> + priv->sensors[i].tzd);
>> +
>> + return ret;
>> +}
>> +
>> +static int zx2967_thermal_exit(struct platform_device *pdev)
>> +{
>> + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
>> + int i;
>> +
>> + for (i = 0; i < NUM_SENSORS; i++) {
>> + struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
>> +
>> + thermal_zone_of_sensor_unregister(&pdev->dev,
>> sensor->tzd);
>> + }
>> + clk_disable_unprepare(priv->pclk);
>> + clk_disable_unprepare(priv->clk_gate);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id zx2967_thermal_id_table[] = {
>> + { .compatible = "zte,zx2967-thermal" },
>> + { .compatible = "zte,zx296718-thermal" },
>>
>
> Does the sensors that maps to the two compatibles have any difference? If
> yes, we can add the difference with data member. If not, we can use the
> same compatible string.
>
>
> + {}
>> +};
>> +MODULE_DEVICE_TABLE(of, zx2967_thermal_id_table);
>> +
>> +static SIMPLE_DEV_PM_OPS(zx2967_thermal_pm_ops,
>> + zx2967_thermal_suspend, zx2967_thermal_resume);
>> +
>> +static struct platform_driver zx2967_thermal_driver = {
>> + .probe = zx2967_thermal_probe,
>> + .remove = zx2967_thermal_exit,
>> + .driver = {
>> + .name = "zx2967_thermal",
>> + .of_match_table = zx2967_thermal_id_table,
>> + .pm = &zx2967_thermal_pm_ops,
>> + },
>> +};
>> +module_platform_driver(zx2967_thermal_driver);
>> +
>> +MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
>> +MODULE_DESCRIPTION("ZTE zx2967 thermal driver");
>> +MODULE_LICENSE("GPL");
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 15492 bytes --]
^ permalink raw reply
* Re: [PATCH v8 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Inki Dae @ 2017-01-11 8:40 UTC (permalink / raw)
To: Andrzej Hajda, Hoegeun Kwon, krzk-DgEjT+Ai2ygdnm+yROfE0A,
robh-DgEjT+Ai2ygdnm+yROfE0A,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, airlied-cv59FeDIM0c,
kgene-DgEjT+Ai2ygdnm+yROfE0A
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
cw00.choi-Sze3O3UU22JBDgjK7y7TUQ,
jh80.chung-Sze3O3UU22JBDgjK7y7TUQ,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ, Hyungwon Hwang
In-Reply-To: <f292435b-8faa-d2e9-17f6-99a4d00173c5-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017년 01월 11일 16:46에 Andrzej Hajda 이(가) 쓴 글:
> On 11.01.2017 07:33, Hoegeun Kwon wrote:
>> From: Hyungwon Hwang <human.hwang-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>
>> This patch add the panel device tree node for S6E3HA2 display
>> controller to TM2 dts.
>>
>> Signed-off-by: Hyungwon Hwang <human.hwang-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index ddba2f8..6d362f9 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,18 @@
>> compatible = "samsung,tm2", "samsung,exynos5433";
>> };
>>
>> +&dsi {
>> + panel@0 {
>> + compatible = "samsung,s6e3ha2";
>> + reg = <0>;
>> + vdd3-supply = <&ldo27_reg>;
>> + vci-supply = <&ldo28_reg>;
>> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
>> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
>> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> The same here (as in 1st comment) , te-gpios should be dropper - decon
> uses hw-trigger.
Reasonable to remove te-gpios property but this change would make MIPI-DSI driver probing to be failed so MIPI-DSI driver should be fixed together.
Thanks.
>
> Regards
> Andrzej
>> + };
>> +};
>> +
>> &hsi2c_9 {
>> status = "okay";
>>
>
>
>
>
--
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 4/4] arm: dts: mt2701: Add auxadc device node.
From: Erin Lo @ 2017-01-11 8:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-mediatek,
srv_heupstream, Zhiyong Tao, Erin Lo
In-Reply-To: <1484123924-8946-1-git-send-email-erin.lo@mediatek.com>
From: Zhiyong Tao <zhiyong.tao@mediatek.com>
Add auxadc device node for MT2701.
Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 1182c43..4f52019 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -208,6 +208,15 @@
<0 0x10216000 0 0x2000>;
};
+ auxadc: adc@11001000 {
+ compatible = "mediatek,mt2701-auxadc";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&pericfg CLK_PERI_AUXADC>;
+ clock-names = "main";
+ #io-channel-cells = <1>;
+ status = "disabled";
+ };
+
uart0: serial@11002000 {
compatible = "mediatek,mt2701-uart",
"mediatek,mt6577-uart";
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] arm: dts: mt2701: Add nand device node
From: Erin Lo @ 2017-01-11 8:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-mediatek,
srv_heupstream, Xiaolei Li, Erin Lo
In-Reply-To: <1484123924-8946-1-git-send-email-erin.lo@mediatek.com>
From: Xiaolei Li <xiaolei.li@mediatek.com>
Add mt2701 nand device node, include nfi and bch ecc.
Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 87be52c..1182c43 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -261,6 +261,28 @@
status = "disabled";
};
+ nandc: nfi@1100d000 {
+ compatible = "mediatek,mt2701-nfc";
+ reg = <0 0x1100d000 0 0x1000>;
+ interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_NFI>,
+ <&pericfg CLK_PERI_NFI_PAD>;
+ clock-names = "nfi_clk", "pad_clk";
+ status = "disabled";
+ ecc-engine = <&bch>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ bch: ecc@1100e000 {
+ compatible = "mediatek,mt2701-ecc";
+ reg = <0 0x1100e000 0 0x1000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&pericfg CLK_PERI_NFI_ECC>;
+ clock-names = "nfiecc_clk";
+ status = "disabled";
+ };
+
spi1: spi@11016000 {
compatible = "mediatek,mt2701-spi";
#address-cells = <1>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] arm: dts: mt2701: Add iommu/smi device node
From: Erin Lo @ 2017-01-11 8:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-mediatek,
srv_heupstream, Honghui Zhang, Erin Lo
In-Reply-To: <1484123924-8946-1-git-send-email-erin.lo@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
Add the device node of iommu and smi for MT2701.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 54 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index eb4c6fd..87be52c 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -17,6 +17,7 @@
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/mt2701-resets.h>
+#include <dt-bindings/memory/mt2701-larb-port.h>
#include "skeleton64.dtsi"
#include "mt2701-pinfunc.h"
@@ -161,6 +162,16 @@
clock-names = "system-clk", "rtc-clk";
};
+ smi_common: smi@1000c000 {
+ compatible = "mediatek,mt2701-smi-common";
+ reg = <0 0x1000c000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_SMI>,
+ <&mmsys CLK_MM_SMI_COMMON>,
+ <&infracfg CLK_INFRA_SMI>;
+ clock-names = "apb", "smi", "async";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
sysirq: interrupt-controller@10200100 {
compatible = "mediatek,mt2701-sysirq",
"mediatek,mt6577-sysirq";
@@ -170,6 +181,16 @@
reg = <0 0x10200100 0 0x1c>;
};
+ iommu: mmsys_iommu@10205000 {
+ compatible = "mediatek,mt2701-m4u";
+ reg = <0 0x10205000 0 0x1000>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_M4U>;
+ clock-names = "bclk";
+ mediatek,larbs = <&larb0 &larb1 &larb2>;
+ #iommu-cells = <1>;
+ };
+
apmixedsys: syscon@10209000 {
compatible = "mediatek,mt2701-apmixedsys", "syscon";
reg = <0 0x10209000 0 0x1000>;
@@ -272,18 +293,51 @@
#clock-cells = <1>;
};
+ larb0: larb@14010000 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x14010000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <0>;
+ clocks = <&mmsys CLK_MM_SMI_LARB0>,
+ <&mmsys CLK_MM_SMI_LARB0>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
imgsys: syscon@15000000 {
compatible = "mediatek,mt2701-imgsys", "syscon";
reg = <0 0x15000000 0 0x1000>;
#clock-cells = <1>;
};
+ larb2: larb@15001000 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x15001000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <2>;
+ clocks = <&imgsys CLK_IMG_SMI_COMM>,
+ <&imgsys CLK_IMG_SMI_COMM>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+ };
+
vdecsys: syscon@16000000 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x16000000 0 0x1000>;
#clock-cells = <1>;
};
+ larb1: larb@16010000 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x16010000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ mediatek,larbidx = <1>;
+ clocks = <&vdecsys CLK_VDEC_CKGEN>,
+ <&vdecsys CLK_VDEC_LARB>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
+ };
+
hifsys: syscon@1a000000 {
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a000000 0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] arm: dts: mt2701: Add spi device node
From: Erin Lo @ 2017-01-11 8:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-mediatek,
srv_heupstream, Leilk Liu, Erin Lo
In-Reply-To: <1484123924-8946-1-git-send-email-erin.lo@mediatek.com>
From: Leilk Liu <leilk.liu@mediatek.com>
Add spi device node for MT2701.
Signed-off-by: Leilk Liu <leilk.liu@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm/boot/dts/mt2701.dtsi | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..eb4c6fd 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,45 @@
status = "disabled";
};
+ spi0: spi@1100a000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x1100a000 0 0x100>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+ <&topckgen CLK_TOP_SPI0_SEL>,
+ <&pericfg CLK_PERI_SPI0>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ spi1: spi@11016000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x11016000 0 0x100>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+ <&topckgen CLK_TOP_SPI1_SEL>,
+ <&pericfg CLK_PERI_SPI1>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
+ spi2: spi@11017000 {
+ compatible = "mediatek,mt2701-spi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0 0x11017000 0 0x1000>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+ <&topckgen CLK_TOP_SPI2_SEL>,
+ <&pericfg CLK_PERI_SPI2>;
+ clock-names = "parent-clk", "sel-clk", "spi-clk";
+ status = "disabled";
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] Add spi/iommu/nand/auxadc DT nodes for Mediatek MT2701
From: Erin Lo @ 2017-01-11 8:38 UTC (permalink / raw)
To: Matthias Brugger
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w
This patch series base on v4.10-rc2, include MT2701 spi/iommu/nand/auxadc DT nodes.
Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1].
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html
Honghui Zhang (1):
arm: dts: mt2701: Add iommu/smi device node
Leilk Liu (1):
arm: dts: mt2701: Add spi device node
Xiaolei Li (1):
arm: dts: mt2701: Add nand device node
Zhiyong Tao (1):
arm: dts: mt2701: Add auxadc device node.
arch/arm/boot/dts/mt2701.dtsi | 124 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 124 insertions(+)
--
1.9.1
--
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
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