[PATCHv2 0/5] ARM: dts: exynos: Add missing dt data to bring kernel of Exynos4x12
This patch add missing dt data of Exynos4x12 to bring up kernel feature and code clean. This patchset is based on 'v3.15-next/dt-clk-exynos' branch. - git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git exynos4x12/exynos4412/exynos4212.dtsi - Add ADC (Analog and Digital Converter) to get raw data - Add PMU (Performance Monitoring Unit) for perf event - Add gps_alive power domain to remove power leakage when gps-alive isn't used - Remove duplicate dt data of interrput combiner controller exynos4412-trats.dts - Add ADC dt data with ntc thermistor child to read temperature Changes from v1: - Use clock macro name for Exynos4 instead of constant for ADC - Remove unnecessary description about patch content - Move gps-alive power domain's dt data from exynos4x12.dts to exynos4.dts - Move thermistor dt node outside of ADC dt node and modify node name of thermistor Chanwoo Choi (5): ARM: dts: exynos4x12: Add ADC's dt data to read raw data ARM: dts: exynos4x12: Add PMU dt data to support PMU(Perforamnce Monitoring Unit) ARM: dts: exynos4x12: Add GPS_ALIVE power domain ARM: dts: exynos: Move common dt data for interrupt combiner controller ARM: dts: exynos4412-trats2: Add ADC/themistor dt data to get temperature of SoC/battery arch/arm/boot/dts/exynos4.dtsi | 5 + arch/arm/boot/dts/exynos4212.dtsi | 13 - arch/arm/boot/dts/exynos4412-trats2.dts | 21 + arch/arm/boot/dts/exynos4412.dtsi | 14 -- arch/arm/boot/dts/exynos4x12.dtsi | 26 ++ 5 files changed, 60 insertions(+), 19 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/5] ARM: dts: exynos4x12: Add GPS_ALIVE power domain
This patch add GPS_ALIVE power domain for Exynos4x12 SoC. GPS_ALIVE power domain
include GPS_BLK for GPS IP. Exynos SoC used generic power-domain driver to
control power domain. After completed kernel booting, Exynos power-domain driver
disable un-used power domain to reduce power-consumption/leak.
If GPS_ALIVE power domain isn't registered to Exynos power-domain driver,
happen power-leakage because GPS_ALIVE_CONFIGURATION is default power on state.
- 0x10023D00 : GPS_ALIVE_CONFIGURATION register address
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 28b5ec7..0401f4d 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -86,6 +86,11 @@
reg = <0x10023CE0 0x20>;
};
+ pd_gps_alive: gps-alive-power-domain@10023D00 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10023D00 0x20>;
+ };
+
gic: interrupt-controller@1049 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 5/5] ARM: dts: exynos4412-trats2: Add ADC/themistor dt data to get temperature of SoC/battery
This patch use ADC to get the temperature of SoC/battery by using NTC thermistor
driver in hwmon. NTC thermistor driver covnvert ADC's raw data to temperature
by using following variables:
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-trats2.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..3228506 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -106,6 +106,11 @@
};
};
+ adc: adc@126C {
+ vdd-supply = <&ldo3_reg>;
+ status = "okay";
+ };
+
i2c@1389 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -589,4 +594,20 @@
};
};
};
+
+ thermistor-ap@0 {
+ compatible = "ntc,ncp15wb473";
+ pullup-uv = <180>; /* VCC_1.8V_AP */
+ pullup-ohm = <10>; /* 100K */
+ pulldown-ohm = <10>; /* 100K */
+ io-channels = <&adc 1>; /* AP temperature */
+ };
+
+ thermistor-battery@1 {
+ compatible = "ntc,ncp15wb473";
+ pullup-uv = <180>; /* VCC_1.8V_AP */
+ pullup-ohm = <10>; /* 100K */
+ pulldown-ohm = <10>; /* 100K */
+ io-channels = <&adc 2>; /* Battery temperature */
+ };
};
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/5] ARM: dts: exynos: Move common dt data for interrupt combiner controller
This patch move common dt data of interrupt combiner controller to
exynos4x12.dtsi. Each Exynos4x12 SoC has different number of interrput combiner
as following:
- Exynos4212 : interrput combiner 18(0 ~ 17)
- Exynos4412 : interrput combiner 20(0 ~ 19)
The exynos combiner driver initialize interrupt according to specific number
of interrput combiner.
- samsung,combiner-nr : The number of interrput combiners supported.
Also,
This patch arrange again the dt data according to register address
in exynos4212/exynos4412.dtsi.
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/exynos4212.dtsi | 13 -
arch/arm/boot/dts/exynos4412.dtsi | 14 --
arch/arm/boot/dts/exynos4x12.dtsi | 8
3 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 94a43f9..ceefc71 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -22,16 +22,11 @@
/ {
compatible = "samsung,exynos4212";
- gic: interrupt-controller@1049 {
- cpu-offset = <0x8000>;
+ combiner: interrupt-controller@1044 {
+ samsung,combiner-nr = <18>;
};
- interrupt-controller@1044 {
- samsung,combiner-nr = <18>;
- interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
-<0 107 0>, <0 108 0>;
+ gic: interrupt-controller@1049 {
+ cpu-offset = <0x8000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 87b339c..a40b6e2 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -22,17 +22,11 @@
/ {
compatible = "samsung,exynos4412";
- gic: interrupt-controller@1049 {
- cpu-offset = <0x4000>;
- };
-
- interrupt-controller@1044 {
+ combiner: interrupt-controller@1044 {
samsung,combiner-nr = <20>;
- interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
-<0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
};
+ gic: interrupt-controller@1049 {
+ cpu-offset = <0x4000>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index a1e76ec..c4a9306 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -68,6 +68,14 @@
};
};
+ combiner: interrupt-controller@1044 {
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
+<0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
+ };
+
pinctrl_0: pinctrl@1140 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x1140 0x1000>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/5] ARM: dts: exynos4x12: Add ADC's dt data to read raw data
This patch add ADC(Analog to Digital Converter)'s dt data to get raw data
with IIO subsystem. Usually, ADC is used to check temperature, jack type
and so on.
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index e0eb6bb..eec1e30 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -80,6 +80,18 @@
};
};
+ adc: adc@126C {
+ compatible = "samsung,exynos-adc-v1";
+ reg = <0x126C 0x100>, <0x10020718 0x4>;
+ interrupt-parent = <&combiner>;
+ interrupts = <10 3>;
+ clocks = <&clock CLK_TSADC>;
+ clock-names = "adc";
+ #io-channel-cells = <1>;
+ io-channel-ranges;
+ status = "disabled";
+ };
+
pinctrl_2: pinctrl@0386 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x0386 0x1000>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/5] ARM: dts: exynos4x12: Add PMU dt data to support PMU(Perforamnce Monitoring Unit)
ARM CPU has its own performance profiling unit(PMU, Perforamnce Monitoring
Unit).
This patch add PMU dt data to support PMU which count cache hit and miss events.
PMU interrput list of Exynos4212
- <2 2> : INTG2[2] - PMUIRQ[0] for CPU0
- <3 2> : INTG3[2] - PMUIRQ[1] for CPU1
PMU interrput list of Exynos4412
- <2 2> : INTG2[2], PMUIRQ[0] for CPU0
- <3 2> : INTG3[2], PMUIRQ[1] for CPU1
- <18 2> : INTG18[2], PMUIRQ[2] : CPU2
- <19 2> : INTG19[2], PMUIRQ[3] : CPU3
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
Reviewed-by: Tomasz Figa
---
arch/arm/boot/dts/exynos4x12.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index eec1e30..a1e76ec 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -31,6 +31,12 @@
mshc0 = &mshc_0;
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
+ };
+
pd_isp: isp-power-domain@10023CA0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: exynos4412-trats2: Add ADC's dt data to get temperature of SoC/battery
Hi Tomasz,
On 03/11/2014 10:09 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 11.03.2014 08:54, Chanwoo Choi wrote:
>> This patch use ADC to get the temperature of SoC/battery by using NTC
>> thermistor
>> driver in hwmon. NTC thermistor driver covnvert ADC's raw data to temperature
>> by using following variables:
>>
>> - pullup-uv: Voltage
>> - pullup-ohm : Pull-up resistance
>> - pulldown-ohm : Pull-down resistance
>> - io-channels : It means ADC channel.
>>
>
> Those properties are well-defined in "ntc,ncp15wb473" DT bindings
> documentation. There is no need to repeat them here.
>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4412-trats2.dts | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
>> b/arch/arm/boot/dts/exynos4412-trats2.dts
>> index 4f851cc..fc517c3 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -106,6 +106,27 @@
>> };
>> };
>>
>> +adc: adc@126C {
>> +vdd-supply = <&ldo3_reg>;
>> +status = "okay";
>> +
>> +ncp15wb473@0 {
>
> style: Nodes should have generic names, e.g. thermistor@0.
>
> Also if node name is suffixed with @unit-address, then the node should have a
> reg property with its first entry corresponding to the unit-address. Now
> there is no physical unit-address definition for those thermistors, so they
> shouldn't use this naming pattern, but rather something like "thermistor-0"
> or "thermistor-ap".
OK I'll rename thermistor dt name.
>
>> +compatible = "ntc,ncp15wb473";
>> +pullup-uv = <180>; /* VCC_1.8V_AP */
>> +pullup-ohm = <10>; /* 100K */
>> +pulldown-ohm = <10>; /* 100K */
>> +io-channels = <&adc 1>; /* AP temperature */
>> +};
>> +
>> +ncp15wb473@1 {
>> +compatible = "ntc,ncp15wb473";
>> +pullup-uv = <180>; /* VCC_1.8V_AP */
>> +pullup-ohm = <10>; /* 100K */
>> +pulldown-ohm = <10>; /* 100K */
>> +io-channels = <&adc 2>; /* Battery temperature */
>> +};
>
> Anyway, I don't think it is correct to place IIO consumers under IIO provider
> node, because IIO is not a control bus, but rather a resource provider, like
> GPIO, clock, etc. So both thermistor nodes should be placed outside the adc
> node. (They might be grouped in a simple-bus subnode, though, to improve
> readability.)
OK, I'll move ntc_thermistor node outside of ADC dt node.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
Mark Rutland wrote:
>
Hi Mark,
> On Mon, Mar 10, 2014 at 10:51:17PM +, Kukjin Kim wrote:
> > Signed-off-by: Kukjin Kim
> > Reviewed-by: Thomas Abraham
> > Cc: Catalin Marinas
> > ---
> > arch/arm64/boot/dts/samsung-gh7.dtsi | 106
> +++
> > arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26
> > 2 files changed, 132 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi
> > create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts
> >
> > diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi
> b/arch/arm64/boot/dts/samsung-gh7.dtsi
> > new file mode 100644
> > index 000..b5e8488
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi
> > @@ -0,0 +1,106 @@
> > +/*
> > + * SAMSUNG GH7 SoC device tree source
> > + *
> > + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> > + * http://www.samsung.com
> > + *
> > + * 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.
> > +*/
> > +
> > +/memreserve/ 0x8000 0x0C40;
>
> Please have a comment as to what this memreserve is intended to protect.
> This is very large, and we don't want pointless memreserves.
>
Well, you mean I need to comment about each reserved memory area?
We need the reserved memory for EL3 monitor, UEFI services, secure
interpreter, hypervisor and Scan-chain for debug...BTW isn't it depending on
each hardware platform and usage model?
Just note, I will change the reserve memory area and size. From at
0xf800 and size is 128MB(0x800).
> What address does the kernel end up getting loaded at on this board?
>
We load the kernel image from at 0x8008 after changing the reserve
memory area.
> > +
> > +/ {
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + aliases {
> > + serial0 = "/amba/uart@12c0";
> > + };
> > +
> > + cpus {
> > + #address-cells = <2>;
> > + #size-cells = <0>;
> > +
> > + cpu@000 {
> > + device_type = "cpu";
> > + compatible = "arm,armv8";
>
> The "arm,armv8" should be a fallback rather than the only entry. The
> precise core should be first (see arch/arm64/boot/dts/apm-storm.dtsi for
> an example).
>
Well, do I really need another name if GH7 has just 'ARMv8 core' exactly?
> > + reg = <0x0 0x000>;
>
> Any reason for padding these to three hexadecimal digits (in both the
> reg and unit-address)?
>
Yes, I already commented on Olof's question before, other cores will be
added and it should be separated from this.
> > + enable-method = "spin-table";
> > + cpu-release-addr = <0x0 0x8000fff8>;
> > + };
> > + cpu@001 {
> > + device_type = "cpu";
> > + compatible = "arm,armv8";
> > + reg = <0x0 0x001>;
> > + enable-method = "spin-table";
> > + cpu-release-addr = <0x0 0x8000fff8>;
> > + };
> > + cpu@002 {
> > + device_type = "cpu";
> > + compatible = "arm,armv8";
> > + reg = <0x0 0x002>;
> > + enable-method = "spin-table";
> > + cpu-release-addr = <0x0 0x8000fff8>;
> > + };
> > + cpu@003 {
> > + device_type = "cpu";
> > + compatible = "arm,armv8";
> > + reg = <0x0 0x003>;
> > + enable-method = "spin-table";
> > + cpu-release-addr = <0x0 0x8000fff8>;
> > + };
> > + };
> > +
> > + gic: interrupt-controller@1C00 {
> > + compatible = "arm,cortex-a15-gic";
>
> We should have a more specific compatible string early in the list here
> too.
>
Well, I think more specific compatible string is not required for gic, there
were discussion about using another compatible string for gic-v2. And
cortex-a15-gic should be fine at this moment and if another name is required
as per previous discussion, we will then.
> > + #interrupt-cells = <3>;
> > + interrupt-controller;
> > + reg = <0x0 0x1C001000 0 0x1000>,/* GIC Dist */
> > + <0x0 0x1C002000 0 0x1000>,/* GIC CPU */
> > + <0x0 0x1C004000 0 0x2000>,/* GIC VCPU Control
*/
> > + <0x0 0x1C006000 0 0x2000>;/* GIC VCPU */
> > + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupts = <1 13 0xff01>, /* Secure Phys IRQ */
> > +<1 14 0xff01>, /* Non-secure Phys IRQ */
> > +<1 11 0xff01>, /* Virt IRQ */
> > +
[PATCH v2 4/4] ARM: S3C24XX: remove S3C24XX specific clock Kconfig options
This patch removes S3C24XX specific clock Kconfig options as it has been moved into "drivers/clk/samsung/Kconfig" also removes COMMON_CLK selection as COMMON_CLK_SAMSUNG is selecting it's dependency. CC: Ben Dooks CC: Kukjin Kim CC: Russell King Signed-off-by: Pankaj Dubey --- arch/arm/mach-s3c24xx/Kconfig | 14 -- 1 file changed, 14 deletions(-) diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index 80373da..2d1232e 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -39,7 +39,6 @@ config CPU_S3C2410 config CPU_S3C2412 bool "SAMSUNG S3C2412" - select COMMON_CLK select CPU_ARM926T select CPU_LLSERIAL_S3C2440 select S3C2412_COMMON_CLK @@ -50,7 +49,6 @@ config CPU_S3C2412 config CPU_S3C2416 bool "SAMSUNG S3C2416/S3C2450" - select COMMON_CLK select CPU_ARM926T select CPU_LLSERIAL_S3C2440 select S3C2416_PM if PM @@ -88,7 +86,6 @@ config CPU_S3C244X config CPU_S3C2443 bool "SAMSUNG S3C2443" - select COMMON_CLK select CPU_ARM920T select CPU_LLSERIAL_S3C2440 select S3C2443_COMMON_CLK @@ -364,11 +361,6 @@ config S3C2412_PM_SLEEP if CPU_S3C2412 -config S3C2412_COMMON_CLK - bool - help - Build the s3c2412 clock driver based on the common clock framework. - config CPU_S3C2412_ONLY bool depends on !CPU_S3C2410 && !CPU_S3C2416 && !CPU_S3C2440 && \ @@ -651,12 +643,6 @@ endif # CPU_S3C2442 if CPU_S3C2443 || CPU_S3C2416 -config S3C2443_COMMON_CLK - bool - help - Temporary symbol to build the clock driver based on the common clock - framework. - config S3C2443_DMA bool help -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] ARM: select COMMON_CLK_SAMSUNG for ARCH_EXYNOS and ARCH_S3C64XX
This patch selects COMMON_CLK_SAMSUNG for EXYNOS and S3C64XX SoC and removes COMMON_CLK selection as COMMON_CLK_SAMSUNG selects it's dependency. CC: Russell King Signed-off-by: Pankaj Dubey --- arch/arm/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e254198..0c15aa7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -755,7 +755,7 @@ config ARCH_S3C64XX select ARM_VIC select CLKDEV_LOOKUP select CLKSRC_SAMSUNG_PWM - select COMMON_CLK + select COMMON_CLK_SAMSUNG select CPU_V6K select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG @@ -834,7 +834,7 @@ config ARCH_EXYNOS select ARCH_REQUIRE_GPIOLIB select ARCH_SPARSEMEM_ENABLE select ARM_GIC - select COMMON_CLK + select COMMON_CLK_SAMSUNG select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_S3C2410_I2C if I2C -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] clk: samsung: add new Kconfig for Samsung common clock options
This patch adds new Kconfig file for adding new config option as COMMON_CLK_SAMSUNG for Samsung common clock. This patch also moves S3C24XX specific clock options here in this file. Signed-off-by: Pankaj Dubey --- drivers/clk/samsung/Kconfig | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 drivers/clk/samsung/Kconfig diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig new file mode 100644 index 000..26eb446 --- /dev/null +++ b/drivers/clk/samsung/Kconfig @@ -0,0 +1,11 @@ +config COMMON_CLK_SAMSUNG + bool + select COMMON_CLK + +config S3C2412_COMMON_CLK + bool + select COMMON_CLK_SAMSUNG + +config S3C2443_COMMON_CLK + bool + select COMMON_CLK_SAMSUNG -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] Introduce new Kconfig for Samsung common clock
Introduce a new Kconfig file for Samsung common clock infrastructure related config options. As current Samsung common clock gets compiled based on PLAT_SAMSUNG, but moving ahead with ARM64 we can not have any more such config options, so this patch introduce new COMMON_CLK_SAMSUNG invisible option. This option also select COMMON_CLK so ARCH Kconfig just need to select COMMON_CLK_SAMSUNG in case they want to use Samsung common clock. This series is based on Kukjin's for-next branch. V2: 1) Adding new Kconfig file for Samsung common clock. 2) Make COMMON_CLK_SAMSUNG option invisible. (as suggested by Tomasz Figa) 3) Let COMMON_CLK_SAMSUNG select COMMON_CLK. (as suggested by Tomasz Figa) 4) Move S3C24XX clock config option in new Kconfig file. Pankaj Dubey (4): clk: samsung: add new Kconfig for Samsung common clock options drivers: clk: use CONFIG_COMMON_CLK_SAMSUNG for Samsung clock support ARM: select COMMON_CLK_SAMSUNG for ARCH_EXYNOS and ARCH_S3C64XX ARM: S3C24XX: remove S3C24XX specific clock Kconfig options arch/arm/Kconfig |4 ++-- arch/arm/mach-s3c24xx/Kconfig | 14 -- drivers/clk/Kconfig |2 ++ drivers/clk/Makefile |2 +- drivers/clk/samsung/Kconfig | 11 +++ 5 files changed, 16 insertions(+), 17 deletions(-) create mode 100644 drivers/clk/samsung/Kconfig -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] drivers: clk: use CONFIG_COMMON_CLK_SAMSUNG for Samsung clock support
This patch includes Samsung clock Kconfig file, and replaces PLAT_SAMSUNG with COMMON_CLK_SAMSUNG for Samsung common clock support. Any Samsung SoC want to use Samsung common clock infrastructure can simply select COMMON_CLK_SAMSUNG. Signed-off-by: Pankaj Dubey --- drivers/clk/Kconfig |2 ++ drivers/clk/Makefile |2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 7641965..f2b6179 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -112,3 +112,5 @@ source "drivers/clk/qcom/Kconfig" endmenu source "drivers/clk/mvebu/Kconfig" + +source "drivers/clk/samsung/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index a367a98..f1da6ee 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -38,7 +38,7 @@ obj-$(CONFIG_PLAT_ORION) += mvebu/ obj-$(CONFIG_ARCH_MXS) += mxs/ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/ obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ -obj-$(CONFIG_PLAT_SAMSUNG) += samsung/ +obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/ obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/ obj-$(CONFIG_ARCH_SIRF)+= sirf/ obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] of/irq: Fix irq-mapping in of_irq_parse_raw()
On Tue, Mar 11, 2014 at 1:15 PM, Jason Gunthorpe
wrote:
> On Tue, Mar 04, 2014 at 06:54:24AM -0800, Tim Harvey wrote:
>> When an interrupt-map contains multiple entries an imap pointer arithmetic
>> bug can cause only the first entry to be properly evaluated and causes
>> the out_irq parameters to be incorrect depending on the #interrupt-cells
>> and #address-cells of the parent interrupt controller.
>
> Tim,
>
> I took a bit closer look at this for you, and I suspect the root fix
> is this:
>
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -55,7 +55,6 @@ Example:
> intc: interrupt-controller@fff11000 {
> compatible = "arm,cortex-a9-gic";
> #interrupt-cells = <3>;
> - #address-cells = <1>;
> interrupt-controller;
> reg = <0xfff11000 0x1000>,
> <0xfff10100 0x100>;
> (plus the corresponding purge from the .dt files)
>
> It looks like the implementation does follow the OF specification:
>
> Each mapping entry consists of a 3-tuple of (child-interrupt,
> interrupt-parent, parent-interrupt). The number of cells for the
> child-interrupt specifier is determined by the "#address-cells" and
> "#interrupt-cells"property of this node. The number of cells for the
> parent-interrupt value is determined by the "#address-cells"and
> "#interrupt-cells"property values of this node's
> interrupt-parent.
Ok - I see I misunderstood the spec with regards to what the
address-cells related to.
>
> So by specifying interrupt-cells = 3, address-cells = 1, the GIC is
> requiring 4 DWs for its interrupt specifier.
Agreed, and the interrupt mapping for the imx6 pcie host controller:
interrupt-map = <0 0 0 1 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 2 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 3 &intc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 4 &intc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
has only 3 cells for the parent interrupt, and only 3 are needed so I
suppose there is no 'address' necessary.
>
> I see no reason why it doesn't have an address-cells = 0 like other
> interrupt controllers..
I agree, and I see that as well for other cortex-a9 gic interrupt controllers.
>
> Setting #address-cells to 0 in the GIC node should be functionally
> equivalent to your patch below, since newaddrsize will == 0.
yes, it does. I'll verify and post a followup patch tomorrow for the
invalid dtsi's. Thanks for digging into this!
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: dts: exynos4x12: Add ADC's dt data to read raw data
Hi Tomasz,
On 03/11/2014 09:20 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 11.03.2014 08:54, Chanwoo Choi wrote:
>> This patch add ADC(Analog to Digital Converter)'s dt data to get raw data
>> with IIO subsystem. Usually, ADC is used to check temperature, jack type, and
>> so on.
>>
>
> 8< ---
>
>> Register map
>> - <0x126C 0x100> : ADC register's base address
>> - <0x10020718 0x4> : ADC_PHY_CONTROL, TS-ADC control register address
>>
>> Clock
>> - <&clock 326> : ADC clock (clock name :'tsadc')
>>
>> Interrupt
>> - INTG10[3] : ADC for General ADC
>
> --- >8
>
> I don't think there is a need to include such data in commit message. A
> commit message should say what is done and why it's done (and sometimes how
> it's done, in case of some complex code being added) and I guess that's all.
OK, I'll remove it on patch description.
>
>>
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 5c412aa..5a3e551 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -80,6 +80,18 @@
>> };
>> };
>>
>> +adc: adc@126C {
>> +compatible = "samsung,exynos-adc-v1";
>> +reg = <0x126C 0x100>, <0x10020718 0x4>;
>> +interrupt-parent = <&combiner>;
>> +interrupts = <10 3>;
>> +clocks = <&clock 326>;
>
> Please use clock macros instead of numbers, as introduced by Andrzej Hajda's
> patches merged to Kgene's tree.
>
OK, I'll modify it.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: dts: exynos4x12: Add GPS_ALIVE power domain
Hi Tomasz,
On 03/11/2014 09:28 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 11.03.2014 08:54, Chanwoo Choi wrote:
>> This patch add GPS_ALIVE power domain for Exynos4x12 SoC. GPS_ALIVE power
>> domain
>> include GPS_BLK for GPS IP. Exynos SoC used generic power-domain driver to
>> control power domain. After completed kernel booting, Exynos power-domain
>> driver
>> disable un-used power domain to reduce power-consumption/leak.
>>
>> If GPS_ALIVE power domain isn't registered to Exynos power-domain driver,
>> happen power-leakage because GPS_ALIVE_CONFIGURATION is default power on
>> state.
>>
>> - 0x10023D00 : GPS_ALIVE_CONFIGURATION register address
>>
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 1ec77f6..066eb35 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -41,6 +41,11 @@
>> compatible = "samsung,exynos4210-pd";
>> reg = <0x10023CA0 0x20>;
>> };
>> +
>> +pd_gps_alive: gps-alive-power-domain@10023D00 {
>> +compatible = "samsung,exynos4210-pd";
>> +reg = <0x10023D00 0x20>;
>> +};
>>
>
> Exynos4210 seems to have this power domain as well, so I guess this change
> should be done to exynos4.dtsi instead.
>
You are right. I will modify it.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7] add new Samsung xgmac driver
Ben Hutchings wrote: > > On Wed, 2014-03-05 at 20:28 +0900, Byungho An wrote: > > Hi all, > > > > This series adds Samsung xgmac driver. > [...] > > Calxeda already took that driver name. Be more original. > Hmm...ok, I see. I will use "sxgmac" as per your suggestion. Thank you, Byungho An -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] arm64: defconfig: Enable ARCH_GH7 by default
On 03/11/14 21:01, Catalin Marinas wrote: On Mon, Mar 10, 2014 at 10:51:18PM +, Kukjin Kim wrote: This patch adds support for Samsung GH7 SoC in arm64/Kconfig and enable Samsung GH7 based SSDK_GH7 in single defconfig for arm64. Signed-off-by: Kukjin Kim Cc: Catalin Marinas --- arch/arm64/Kconfig | 3 +++ arch/arm64/boot/dts/Makefile | 1 + arch/arm64/configs/defconfig | 1 + 3 files changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index dd4327f..f0f2bf2 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -111,6 +111,9 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_GH7 + bool You should add some text here so that people can disable it. The aim is single Image by default but I think we should let people disable certain platforms for more targeted deployments. OK, I'll add and re-submit with Cc'ing dt mailing list. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] of/irq: Fix irq-mapping in of_irq_parse_raw()
On Tue, Mar 04, 2014 at 06:54:24AM -0800, Tim Harvey wrote:
> When an interrupt-map contains multiple entries an imap pointer arithmetic
> bug can cause only the first entry to be properly evaluated and causes
> the out_irq parameters to be incorrect depending on the #interrupt-cells
> and #address-cells of the parent interrupt controller.
Tim,
I took a bit closer look at this for you, and I suspect the root fix
is this:
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -55,7 +55,6 @@ Example:
intc: interrupt-controller@fff11000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
- #address-cells = <1>;
interrupt-controller;
reg = <0xfff11000 0x1000>,
<0xfff10100 0x100>;
(plus the corresponding purge from the .dt files)
It looks like the implementation does follow the OF specification:
Each mapping entry consists of a 3-tuple of (child-interrupt,
interrupt-parent, parent-interrupt). The number of cells for the
child-interrupt specifier is determined by the "#address-cells" and
"#interrupt-cells"property of this node. The number of cells for the
parent-interrupt value is determined by the "#address-cells"and
"#interrupt-cells"property values of this node's
interrupt-parent.
So by specifying interrupt-cells = 3, address-cells = 1, the GIC is
requiring 4 DWs for its interrupt specifier.
I see no reason why it doesn't have an address-cells = 0 like other
interrupt controllers..
Setting #address-cells to 0 in the GIC node should be functionally
equivalent to your patch below, since newaddrsize will == 0.
Regards,
Jason
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 9bcf2cf..8829197 100644
> +++ b/drivers/of/irq.c
> @@ -237,11 +237,11 @@ int of_irq_parse_raw(const __be32 *addr, struct
> of_phandle_args *out_irq)
> /* Check for malformed properties */
> if (WARN_ON(newaddrsize + newintsize >
> MAX_PHANDLE_ARGS))
> goto fail;
> - if (imaplen < (newaddrsize + newintsize))
> + if (imaplen < newintsize)
> goto fail;
>
> - imap += newaddrsize + newintsize;
> - imaplen -= newaddrsize + newintsize;
> + imap += newintsize;
> + imaplen -= newintsize;
>
> pr_debug(" -> imaplen=%d\n", imaplen);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
On Mon, Mar 10, 2014 at 10:51:17PM +, Kukjin Kim wrote:
> Signed-off-by: Kukjin Kim
> Reviewed-by: Thomas Abraham
> Cc: Catalin Marinas
> ---
> arch/arm64/boot/dts/samsung-gh7.dtsi | 106
> +++
> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26
> 2 files changed, 132 insertions(+)
> create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi
> create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts
>
> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi
> b/arch/arm64/boot/dts/samsung-gh7.dtsi
> new file mode 100644
> index 000..b5e8488
> --- /dev/null
> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi
> @@ -0,0 +1,106 @@
> +/*
> + * SAMSUNG GH7 SoC device tree source
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * 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.
> +*/
> +
> +/memreserve/ 0x8000 0x0C40;
Please have a comment as to what this memreserve is intended to protect.
This is very large, and we don't want pointless memreserves.
What address does the kernel end up getting loaded at on this board?
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = "/amba/uart@12c0";
> + };
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu@000 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
The "arm,armv8" should be a fallback rather than the only entry. The
precise core should be first (see arch/arm64/boot/dts/apm-storm.dtsi for
an example).
> + reg = <0x0 0x000>;
Any reason for padding these to three hexadecimal digits (in both the
reg and unit-address)?
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x8000fff8>;
> + };
> + cpu@001 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x001>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x8000fff8>;
> + };
> + cpu@002 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x002>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x8000fff8>;
> + };
> + cpu@003 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x003>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x8000fff8>;
> + };
> + };
> +
> + gic: interrupt-controller@1C00 {
> + compatible = "arm,cortex-a15-gic";
We should have a more specific compatible string early in the list here
too.
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x0 0x1C001000 0 0x1000>,/* GIC Dist */
> + <0x0 0x1C002000 0 0x1000>,/* GIC CPU */
> + <0x0 0x1C004000 0 0x2000>,/* GIC VCPU Control */
> + <0x0 0x1C006000 0 0x2000>;/* GIC VCPU */
> + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <1 13 0xff01>, /* Secure Phys IRQ */
> + <1 14 0xff01>, /* Non-secure Phys IRQ */
> + <1 11 0xff01>, /* Virt IRQ */
> + <1 10 0xff01>; /* Hyp IRQ */
> + };
> +
> + pmu {
> + compatible = "arm,armv8-pmuv3";
This is missing a specific compatible string.
> + interrupts = <0 294 0>,
> + <0 295 0>,
> + <0 296 0>,
> + <0 297 0>,
> + <0 298 0>,
> + <0 299 0>,
> + <0 300 0>,
> + <0 301 0>;
> + };
There are four CPUs described, yet eight interrupts here. There should
be one per CPU.
> +
> + amba {
> + compatible = "arm,amba-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + serial@12c0 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0 0x12c0 0 0x1>;
> + interrupts = <0 418 0>;
> + };
> +
> + serial@12c2 {
> + compatible = "
Re: [PATCH v6 03/10] Documentation: devicetree: Update Samsung FIMC DT binding
Hi Sylwester,
On Tuesday 11 March 2014 14:38:37 Sylwester Nawrocki wrote:
> Hi Laurent,
>
> Thanks for your review.
You're welcome.
> On 11/03/14 13:30, Laurent Pinchart wrote:
> [...]
>
> >> ---
> >>
> >> .../devicetree/bindings/media/samsung-fimc.txt | 34 +-
> >> 1 file changed, 26 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> b/Documentation/devicetree/bindings/media/samsung-fimc.txt index
> >> 96312f6..dbd4020 100644
> >> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> @@ -32,6 +32,21 @@ way around.
> >>
> >> The 'camera' node must include at least one 'fimc' child node.
> >>
> >> +Optional properties:
> >> +
> >> +- #clock-cells: from the common clock bindings
> >> (../clock/clock-bindings.txt),
> >> + must be 1. A clock provider is associated with the 'camera' node and
> >> it should
> >> + be referenced by external sensors that use clocks provided by the SoC
> >> on
> >> + CAM_*_CLKOUT pins. The clock specifier cell stores an index of a
> >> clock.
> >> + The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks
> >> respectively.
> >> +
> >> +- clock-output-names: from the common clock bindings, should contain
> >> names of
> >> + clocks registered by the camera subsystem corresponding to
> >> CAM_A_CLKOUT,
> >> + CAM_B_CLKOUT output clocks respectively.
> >
> > Wouldn't it be better to document the "cam_mclk_a" and "cam_mclk_b" names
> > explicitly ? Or do you expect different names to be used in different DT
> > files ? And as they correspond to the CAM_A_CLKOUT and CAM_B_CLKOUT pins,
> > shouldn't they be named "cam_a_clkout" and "cam_b_clkout" ?
>
> Basically I could use fixed names for these clocks, I just wanted to keep
> a possibility to override them in dts to avoid any possible clock name
> collisions, rather than keep a list of different names per SoC in the
> driver. Right now fixed names could also be used for all SoCs I'm aware of,
> nevertheless I would prefer to keep the clock-output-names property.
> "cam_a_clkout", "cam_b_clkout" may be indeed better names, I'll change
> that.
OK, variable names are fine with me.
> >> +Note: #clock-cells and clock-output-names are mandatory properties if
> >> external
> >> +image sensor devices reference 'camera' device node as a clock provider.
> >> +
> >
> > What's the reason not to make them always mandatory ? Backward
> > compatibility only ? If so wouldn't it make sense to document the
> > properties as mandatory from now on, and treating them as optional in the
> > driver for backward compatibility ?
>
> Yes, it's for backwards compatibility only. It may be a good idea to just
> document them as required, since this is how the device is expected to be
> described in DT from now. I'll just make these a required properties,
> the driver already handles them as optional.
OK.
> >> 'fimc' device nodes
> >> ---
> >>
> >> @@ -97,8 +112,8 @@ Image sensor nodes
> >>
> >> The sensor device nodes should be added to their control bus controller
> >>
> >> (e.g. I2C0) nodes and linked to a port node in the csis or the
> >> parallel-ports node, using the common video interfaces bindings, defined
> >> in video-interfaces.txt.
> >> -The implementation of this bindings requires clock-frequency property to
> >> be
> >> -present in the sensor device nodes.
> >> +An optional clock-frequency property needs to be present in the sensor
> >> device
> >> +nodes. Default value when this property is not present is 24 MHz.
> >
> > This bothers me. Having the FIMC driver read the clock-frequence property
> > from the sensor DT nodes feels like a layering violation. Shouldn't the
> > sensor drivers call clk_set_rate() explicitly instead ?
>
> It is supposed to do so, after this whole patch series. So the camera
> controller driver will not need such properties. What do you think about
> removing this sentence altogether ?
Sure. As the FIMC won't access the clock-frequency property of the sensor
anymore after this patch series, let's just drop the mention of clock-
frequency.
> >> Example:
> >> @@ -114,7 +129,7 @@ Example:
> >>vddio-supply = <...>;
> >>
> >>clock-frequency = <2400>;
> >>
> >> - clocks = <...>;
> >> + clocks = <&camera 1>;
> >>
> >>clock-names = "mclk";
> >>
> >>port {
> >>
> >> @@ -135,7 +150,7 @@ Example:
> >>vddio-supply = <...>;
> >>
> >>clock-frequency = <2400>;
> >>
> >> - clocks = <...>;
> >> + clocks = <&camera 0>;
> >>
> >>clock-names = "mclk";
> >>
> >>port {
> >>
> >> @@ -149,12 +164,15 @@ Example:
> >>
Re: [PATCH v6 03/10] Documentation: devicetree: Update Samsung FIMC DT binding
Hi Laurent,
Thanks for your review.
On 11/03/14 13:30, Laurent Pinchart wrote:
[...]
>> ---
>> .../devicetree/bindings/media/samsung-fimc.txt | 34 -
>> 1 file changed, 26 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
>> b/Documentation/devicetree/bindings/media/samsung-fimc.txt index
>> 96312f6..dbd4020 100644
>> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
>> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
>> @@ -32,6 +32,21 @@ way around.
>>
>> The 'camera' node must include at least one 'fimc' child node.
>>
>> +Optional properties:
>> +
>> +- #clock-cells: from the common clock bindings
>> (../clock/clock-bindings.txt),
>> + must be 1. A clock provider is associated with the 'camera' node and it
>> should
>> + be referenced by external sensors that use clocks provided by the SoC on
>> + CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock.
>> + The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
>> +
>> +- clock-output-names: from the common clock bindings, should contain names
>> of
>> + clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT,
>> + CAM_B_CLKOUT output clocks respectively.
>
> Wouldn't it be better to document the "cam_mclk_a" and "cam_mclk_b" names
> explicitly ? Or do you expect different names to be used in different DT
> files
> ? And as they correspond to the CAM_A_CLKOUT and CAM_B_CLKOUT pins, shouldn't
> they be named "cam_a_clkout" and "cam_b_clkout" ?
Basically I could use fixed names for these clocks, I just wanted to keep
a possibility to override them in dts to avoid any possible clock name
collisions, rather than keep a list of different names per SoC in the driver.
Right now fixed names could also be used for all SoCs I'm aware of,
nevertheless I would prefer to keep the clock-output-names property.
"cam_a_clkout", "cam_b_clkout" may be indeed better names, I'll change
that.
>> +Note: #clock-cells and clock-output-names are mandatory properties if
>> external
>> +image sensor devices reference 'camera' device node as a clock provider.
>> +
>
> What's the reason not to make them always mandatory ? Backward compatibility
> only ? If so wouldn't it make sense to document the properties as mandatory
> from now on, and treating them as optional in the driver for backward
> compatibility ?
Yes, it's for backwards compatibility only. It may be a good idea to just
document them as required, since this is how the device is expected to be
described in DT from now. I'll just make these a required properties,
the driver already handles them as optional.
>> 'fimc' device nodes
>> ---
>>
>> @@ -97,8 +112,8 @@ Image sensor nodes
>> The sensor device nodes should be added to their control bus controller
>> (e.g. I2C0) nodes and linked to a port node in the csis or the
>> parallel-ports node, using the common video interfaces bindings, defined in
>> video-interfaces.txt.
>> -The implementation of this bindings requires clock-frequency property to be
>> -present in the sensor device nodes.
>> +An optional clock-frequency property needs to be present in the sensor
>> device
>> +nodes. Default value when this property is not present is 24 MHz.
>
> This bothers me. Having the FIMC driver read the clock-frequence property
> from
> the sensor DT nodes feels like a layering violation. Shouldn't the sensor
> drivers call clk_set_rate() explicitly instead ?
It is supposed to do so, after this whole patch series. So the camera
controller driver will not need such properties. What do you think about
removing this sentence altogether ?
>> Example:
>>
>> @@ -114,7 +129,7 @@ Example:
>> vddio-supply = <...>;
>>
>> clock-frequency = <2400>;
>> -clocks = <...>;
>> +clocks = <&camera 1>;
>> clock-names = "mclk";
>>
>> port {
>> @@ -135,7 +150,7 @@ Example:
>> vddio-supply = <...>;
>>
>> clock-frequency = <2400>;
>> -clocks = <...>;
>> +clocks = <&camera 0>;
>> clock-names = "mclk";
>>
>> port {
>> @@ -149,12 +164,15 @@ Example:
>>
>> camera {
>> compatible = "samsung,fimc", "simple-bus";
>> -#address-cells = <1>;
>> -#size-cells = <1>;
>> -status = "okay";
>> -
>> +clocks = <&clock 132>, <&clock 133>;
>> +clock-names = "sclk_cam0", "sclk_cam1";
>
> The documentation mentions that clock-names must contain "sclk_cam0",
> "sclk_cam1", "pxl_async0", "pxl_async1". Are the last two optional ? If so I
> think you should clarify the description of the clock-names property. This
> can
> be done in a separate patch.
"pxl_async0", "pxl_async1" are mandatory, I'l
Re: [PATCH 7/7] PCI: designware: split samsung and fsl bindings
On Tuesday 04 March 2014, Lucas Stach wrote: > > > On i.MX6 the clock names (which I have to agree are pretty bad) map as > > > follows: > > > pcie_axi: host controller main register/bus access clock > > > pcie_ref_125m: pcie phy reference clock > > > > > > sata_ref_100m: pcie bus 100MHz reference clock > > > > That doesn't explain why it's called "sata_ref_100m". > > > I agree this is bad naming. It's called this way because someone decided > to name it like the internal clock it is sourced from on most boards. > This really should be pcie_ref, or something. I suspect this corresponds > to the pcie_bus clock in the Exynos binding in which case we should just > name it this way. Ok, so Exynos is missing one of the other clocks then? Or is the pcie_ref_125m clock something that should actually be listed under the node of the PHY? > > > lvds_gate: bad abstraction. Decides if the reference clock is sourced > > > internal (i.e. the 100MHz ref clock above) or from an SoC external > > > source. We should really find a better way of representing this in the > > > clock tree. > > > > I don't understand this description at all. Can you try to explain that > > with different words? > > > On i.MX6 the PCIe reference clock is routed through a generic clock pad, > which can be configured either as input or output. When the i.MX is the > PCI master we source the clock from sata_ref_100m and configure this pad > as clock output. > Somebody decided to abstract the input/output switch as a gate, which is > arguably wrong, this should be a mux deciding between internal or > external clock source. > > The PCIe host driver should really only need the clk pad clock, > activation of the sata_ref_100m clock should be handled through > parent<->child relationship of those clocks in the clock tree, which > isn't properly handled right now. I'll try to fix this up, but it won't > be backward compatible in any way. Is it possible to treat this clock as a "global" clock rather than a device specific one, and pass NULL as the device for clk_get? That's not nice, but at least it gives you a way to keep it out of the binding, and "just" creates a dependency between the specific PCI host controller and the way that clock is wired up on a particular SoC. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: exynos4412-trats2: Add ADC's dt data to get temperature of SoC/battery
Hi Chanwoo,
On 11.03.2014 08:54, Chanwoo Choi wrote:
This patch use ADC to get the temperature of SoC/battery by using NTC thermistor
driver in hwmon. NTC thermistor driver covnvert ADC's raw data to temperature
by using following variables:
- pullup-uv: Voltage
- pullup-ohm : Pull-up resistance
- pulldown-ohm : Pull-down resistance
- io-channels : It means ADC channel.
Those properties are well-defined in "ntc,ncp15wb473" DT bindings
documentation. There is no need to repeat them here.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-trats2.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..fc517c3 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -106,6 +106,27 @@
};
};
+ adc: adc@126C {
+ vdd-supply = <&ldo3_reg>;
+ status = "okay";
+
+ ncp15wb473@0 {
style: Nodes should have generic names, e.g. thermistor@0.
Also if node name is suffixed with @unit-address, then the node should
have a reg property with its first entry corresponding to the
unit-address. Now there is no physical unit-address definition for those
thermistors, so they shouldn't use this naming pattern, but rather
something like "thermistor-0" or "thermistor-ap".
+ compatible = "ntc,ncp15wb473";
+ pullup-uv = <180>; /* VCC_1.8V_AP */
+ pullup-ohm = <10>; /* 100K */
+ pulldown-ohm = <10>; /* 100K */
+ io-channels = <&adc 1>; /* AP temperature */
+ };
+
+ ncp15wb473@1 {
+ compatible = "ntc,ncp15wb473";
+ pullup-uv = <180>; /* VCC_1.8V_AP */
+ pullup-ohm = <10>; /* 100K */
+ pulldown-ohm = <10>; /* 100K */
+ io-channels = <&adc 2>; /* Battery temperature */
+ };
Anyway, I don't think it is correct to place IIO consumers under IIO
provider node, because IIO is not a control bus, but rather a resource
provider, like GPIO, clock, etc. So both thermistor nodes should be
placed outside the adc node. (They might be grouped in a simple-bus
subnode, though, to improve readability.)
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode.
Hi Kamil,
On Tue, Mar 11, 2014 at 4:59 PM, Kamil Debski wrote:
> Hi Arun,
>
>> From: Arun Kumar K [mailto:arunkk.sams...@gmail.com] On Behalf Of Arun
>> Kumar K
>> Sent: Friday, March 07, 2014 9:26 AM
>>
>> From: Pawel Osciak
>>
>> Currently, for formats that are not H264, MFC driver will check the
>> consumed stream size returned by the firmware and, based on that, will
>> try to decide whether the bitstream buffer contained more than one
>> frame. If the size of the buffer is larger than the consumed stream, it
>> assumes that there are more frames in the buffer and that the buffer
>> should be resubmitted for decode. This rarely works though and actually
>> introduces problems, because:
>>
>> - v7 firmware will always return consumed stream size equal to whatever
>> the driver passed to it when running decode (which is the size of the
>> whole buffer), which means we will never try to resubmit, because the
>> firmware will always tell us that it consumed all the data we passed to
>> it;
>
> This does sound like a hardware bug/feature. So in v7 the buffer is never
> resubmitted, yes? And this patch makes no difference for v7?
>
To give some background to this - I have added this patch [1] so that
multi-frame input buffer is supported by the driver.
[1] https://patchwork.linuxtv.org/patch/15448/
This patch was added to address one test case in VP8 decoding where
2 frames used to come in a single buffer. Without this patch, it used to
skip decoding of the 2nd frame even though firmware returned
consumed bytes as only 1 frame size.
Now this concept gave issues when we tried to decode the VP8 stream
encoded using v7 firmware. In that case, an arbitrary amount of padding
bytes were added by the firmware after every frame which is allowed as
per VP8 standard. While decoding this using v6, firmware returns less
consumed bytes than the input buffer, but the remaining bytes are just
padding. So firmware used to throw error if we re-submit this stuffing bytes
as a new frame. In v7 firmware, this problem doesnt exist as it consumes
(atleast indicates that it consumed) all the input buffer.
So we came to the conclusion that the testcase of giving multiple frames
in one input buffer itself was wrong and hence it was removed.
Now this concept is needed only for MPEG4 packed PB case which this
code for resubmitting input buffer was meant for (before my patch made
it generic).
>>
>> - v6 firmware will return the number of consumed bytes, but will not
>> include the padding ("stuffing") bytes that are allowed after the frame
>> in VP8. Since there is no way of figuring out how many of those bytes
>> follow the frame without getting the frame size from IVF headers (or
>> somewhere else, but not from the stream itself), the driver tries to
>> guess that padding size is not larger than 4 bytes, which is not always
>> true;
>
> How about v5 of MFC? I need to do some additional testing, as I don't want
> to introduce any regressions. I remember that this check was a result of a
> fair amount of work and testing with v5.
>
I hope it wont give any issues in v5 also as it was never meant to handle
multiple frames in one input buffer.
>> The only way to make it work is to queue only one frame per buffer from
>> userspace and the check in the kernel is useless and wrong for VP8.
>> MPEG4 still seems to require it, so keep it only for that format.
>
> Is your goal to give more than one frame in a single buffer and have the
> buffer resubmitted? Or the opposite - you are getting the frame resubmitted
> without the need? By the contents of this patch I guess the latter, on the
> other hand I do remember that at some point the idea was to be able to queue
> more than one frame per buffer. I don't remember exactly who was opting for
> the ability to queue more frames in a single buffer...
>
I hope now it is clear. We want to disallow multiple frames in one buffer as the
behavior is not consistent in v6 and its not allowed anyway from v7 onwards.
Regards
Arun
> Best wishes,
> --
> Kamil Debski
> Samsung R&D Institute Poland
>
>>
>> Signed-off-by: Pawel Osciak
>> Signed-off-by: Arun Kumar K
>> ---
>> drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> index e2aac59..66c1775 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>> @@ -360,7 +360,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx
>> *ctx,
>> list);
>> ctx->consumed_stream += s5p_mfc_hw_call(dev->mfc_ops,
>> get_consumed_stream, dev);
>> - if (ctx->codec_mode != S5P_MFC_CODEC_H264_DEC &&
>> + if (ctx->codec_mode == S5P_MFC_CODEC_MPEG4_DEC &&
>> ctx->consumed_stream + STUFF_BYTE <
Re: [PATCH 4/5] ARM: dts: exynos: Move common dt data for interrupt combiner controller
Hi Chanwoo,
On 11.03.2014 08:54, Chanwoo Choi wrote:
This patch move common dt data of interrupt combiner controller to
exynos4x12.dtsi. Each Exynos4x12 SoC has different number of interrput combiner
as following:
- Exynos4212 : interrput combiner 18(0 ~ 17)
- Exynos4412 : interrput combiner 20(0 ~ 19)
The exynos combiner driver initialize interrupt according to specific number
of interrput combiner.
- samsung,combiner-nr : The number of interrput combiners supported.
Also,
This patch arrange again the dt data according to register address
in exynos4212/exynos4412.dtsi.
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4212.dtsi | 13 -
arch/arm/boot/dts/exynos4412.dtsi | 14 --
arch/arm/boot/dts/exynos4x12.dtsi | 8
3 files changed, 16 insertions(+), 19 deletions(-)
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 94a43f9..ceefc71 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -22,16 +22,11 @@
/ {
compatible = "samsung,exynos4212";
- gic: interrupt-controller@1049 {
- cpu-offset = <0x8000>;
+ combiner: interrupt-controller@1044 {
+ samsung,combiner-nr = <18>;
};
- interrupt-controller@1044 {
- samsung,combiner-nr = <18>;
- interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
-<0 107 0>, <0 108 0>;
+ gic: interrupt-controller@1049 {
+ cpu-offset = <0x8000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 87b339c..a40b6e2 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -22,17 +22,11 @@
/ {
compatible = "samsung,exynos4412";
- gic: interrupt-controller@1049 {
- cpu-offset = <0x4000>;
- };
-
- interrupt-controller@1044 {
+ combiner: interrupt-controller@1044 {
samsung,combiner-nr = <20>;
- interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
-<0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
};
+ gic: interrupt-controller@1049 {
+ cpu-offset = <0x4000>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 066eb35..6e17034 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -73,6 +73,14 @@
};
};
+ combiner: interrupt-controller@1044 {
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
+<0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
+ };
+
pinctrl_0: pinctrl@1140 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x1140 0x1000>;
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 03/10] Documentation: devicetree: Update Samsung FIMC DT binding
Hi Sylwester,
Thank you for the patch.
On Thursday 06 March 2014 17:20:12 Sylwester Nawrocki wrote:
> This patch documents following updates of the Exynos4 SoC camera subsystem
> devicetree binding:
>
> - addition of #clock-cells property to 'camera' node - the #clock-cells
>property is needed when the sensor sub-devices use clock provided by
>the camera host interface,
> - addition of an optional clock-output-names property,
> - change of the clock-frequency at image sensor node from mandatory to
>an optional property - the sensor devices can now control their clock
>themselves and there should be no need to require this property by the
>camera host device binding, a default frequency value can often be used.
>
> Signed-off-by: Sylwester Nawrocki
> Acked-by: Kyungmin Park
> ---
> Changes since v5:
> - none.
>
> Changes since v4:
> - dropped a requirement of specific order of values in clocks/
>clock-names properties (Mark) and reference to clock-names in
>clock-output-names property description (Mark).
> ---
> .../devicetree/bindings/media/samsung-fimc.txt | 34 -
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> b/Documentation/devicetree/bindings/media/samsung-fimc.txt index
> 96312f6..dbd4020 100644
> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> @@ -32,6 +32,21 @@ way around.
>
> The 'camera' node must include at least one 'fimc' child node.
>
> +Optional properties:
> +
> +- #clock-cells: from the common clock bindings
> (../clock/clock-bindings.txt),
> + must be 1. A clock provider is associated with the 'camera' node and it
> should
> + be referenced by external sensors that use clocks provided by the SoC on
> + CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock.
> + The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
> +
> +- clock-output-names: from the common clock bindings, should contain names
> of
> + clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT,
> + CAM_B_CLKOUT output clocks respectively.
Wouldn't it be better to document the "cam_mclk_a" and "cam_mclk_b" names
explicitly ? Or do you expect different names to be used in different DT files
? And as they correspond to the CAM_A_CLKOUT and CAM_B_CLKOUT pins, shouldn't
they be named "cam_a_clkout" and "cam_b_clkout" ?
> +
> +Note: #clock-cells and clock-output-names are mandatory properties if
> external
> +image sensor devices reference 'camera' device node as a clock provider.
> +
What's the reason not to make them always mandatory ? Backward compatibility
only ? If so wouldn't it make sense to document the properties as mandatory
from now on, and treating them as optional in the driver for backward
compatibility ?
> 'fimc' device nodes
> ---
>
> @@ -97,8 +112,8 @@ Image sensor nodes
> The sensor device nodes should be added to their control bus controller
> (e.g. I2C0) nodes and linked to a port node in the csis or the
> parallel-ports node, using the common video interfaces bindings, defined in
> video-interfaces.txt.
> -The implementation of this bindings requires clock-frequency property to be
> -present in the sensor device nodes.
> +An optional clock-frequency property needs to be present in the sensor
> device
> +nodes. Default value when this property is not present is 24 MHz.
This bothers me. Having the FIMC driver read the clock-frequence property from
the sensor DT nodes feels like a layering violation. Shouldn't the sensor
drivers call clk_set_rate() explicitly instead ?
> Example:
>
> @@ -114,7 +129,7 @@ Example:
> vddio-supply = <...>;
>
> clock-frequency = <2400>;
> - clocks = <...>;
> + clocks = <&camera 1>;
> clock-names = "mclk";
>
> port {
> @@ -135,7 +150,7 @@ Example:
> vddio-supply = <...>;
>
> clock-frequency = <2400>;
> - clocks = <...>;
> + clocks = <&camera 0>;
> clock-names = "mclk";
>
> port {
> @@ -149,12 +164,15 @@ Example:
>
> camera {
> compatible = "samsung,fimc", "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - status = "okay";
> -
> + clocks = <&clock 132>, <&clock 133>;
> + clock-names = "sclk_cam0", "sclk_cam1";
The documentation mentions that clock-names must contain "sclk_cam0",
"sclk_cam1", "pxl_async0", "pxl_async1". Are the last two optional ? If so I
think you should clarify the description of the clock-names property. This can
be done in a separate patch.
> + #clock-cells = <1>;
> +
Re: [PATCH 3/5] ARM: dts: exynos4x12: Add GPS_ALIVE power domain
Hi Chanwoo,
On 11.03.2014 08:54, Chanwoo Choi wrote:
This patch add GPS_ALIVE power domain for Exynos4x12 SoC. GPS_ALIVE power domain
include GPS_BLK for GPS IP. Exynos SoC used generic power-domain driver to
control power domain. After completed kernel booting, Exynos power-domain driver
disable un-used power domain to reduce power-consumption/leak.
If GPS_ALIVE power domain isn't registered to Exynos power-domain driver,
happen power-leakage because GPS_ALIVE_CONFIGURATION is default power on state.
- 0x10023D00 : GPS_ALIVE_CONFIGURATION register address
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 1ec77f6..066eb35 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -41,6 +41,11 @@
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
};
+
+ pd_gps_alive: gps-alive-power-domain@10023D00 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10023D00 0x20>;
+ };
Exynos4210 seems to have this power domain as well, so I guess this
change should be done to exynos4.dtsi instead.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ARM: dts: exynos4x12: Add PMU dt data to support PMU(Perforamnce Monitoring Unit)
Hi Chanwoo, On 11.03.2014 08:54, Chanwoo Choi wrote: ARM CPU has its own performance profiling unit(PMU, Perforamnce Monitoring Unit). This patch add PMU dt data to support PMU which count cache hit and miss events. PMU interrput list of Exynos4212 - <2 2> : INTG2[2] - PMUIRQ[0] for CPU0 - <3 2> : INTG3[2] - PMUIRQ[1] for CPU1 PMU interrput list of Exynos4412 - <2 2> : INTG2[2], PMUIRQ[0] for CPU0 - <3 2> : INTG3[2], PMUIRQ[1] for CPU1 - <18 2> : INTG18[2], PMUIRQ[2] : CPU2 - <19 2> : INTG19[2], PMUIRQ[3] : CPU3 Signed-off-by: Chanwoo Choi Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4x12.dtsi | 6 ++ 1 file changed, 6 insertions(+) Reviewed-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: dts: exynos4x12: Add ADC's dt data to read raw data
Hi Chanwoo,
On 11.03.2014 08:54, Chanwoo Choi wrote:
This patch add ADC(Analog to Digital Converter)'s dt data to get raw data
with IIO subsystem. Usually, ADC is used to check temperature, jack type, and
so on.
8< ---
Register map
- <0x126C 0x100> : ADC register's base address
- <0x10020718 0x4> : ADC_PHY_CONTROL, TS-ADC control register address
Clock
- <&clock 326> : ADC clock (clock name :'tsadc')
Interrupt
- INTG10[3] : ADC for General ADC
--- >8
I don't think there is a need to include such data in commit message. A
commit message should say what is done and why it's done (and sometimes
how it's done, in case of some complex code being added) and I guess
that's all.
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 5c412aa..5a3e551 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -80,6 +80,18 @@
};
};
+ adc: adc@126C {
+ compatible = "samsung,exynos-adc-v1";
+ reg = <0x126C 0x100>, <0x10020718 0x4>;
+ interrupt-parent = <&combiner>;
+ interrupts = <10 3>;
+ clocks = <&clock 326>;
Please use clock macros instead of numbers, as introduced by Andrzej
Hajda's patches merged to Kgene's tree.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] Documentation: DT: add new entry for Samsung GH7 SoC and SSDK board
On Mon, Mar 10, 2014 at 10:51:19PM +, Kukjin Kim wrote: > Signed-off-by: Kukjin Kim > Reviewed-by: Thomas Abraham > Cc: Catalin Marinas Same here, please cc the devicetree list. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] arm64: defconfig: Enable ARCH_GH7 by default
On Mon, Mar 10, 2014 at 10:51:18PM +, Kukjin Kim wrote: > This patch adds support for Samsung GH7 SoC in arm64/Kconfig and > enable Samsung GH7 based SSDK_GH7 in single defconfig for arm64. > > Signed-off-by: Kukjin Kim > Cc: Catalin Marinas > --- > arch/arm64/Kconfig | 3 +++ > arch/arm64/boot/dts/Makefile | 1 + > arch/arm64/configs/defconfig | 1 + > 3 files changed, 5 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index dd4327f..f0f2bf2 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -111,6 +111,9 @@ source "kernel/Kconfig.freezer" > > menu "Platform selection" > > +config ARCH_GH7 > + bool You should add some text here so that people can disable it. The aim is single Image by default but I think we should let people disable certain platforms for more targeted deployments. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
On Mon, Mar 10, 2014 at 10:51:17PM +, Kukjin Kim wrote: > Signed-off-by: Kukjin Kim > Reviewed-by: Thomas Abraham > Cc: Catalin Marinas This patch should go to the devicetree list as well to get some reviews/acks from the DT maintainers. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode.
Hi Arun,
> From: Arun Kumar K [mailto:arunkk.sams...@gmail.com] On Behalf Of Arun
> Kumar K
> Sent: Friday, March 07, 2014 9:26 AM
>
> From: Pawel Osciak
>
> Currently, for formats that are not H264, MFC driver will check the
> consumed stream size returned by the firmware and, based on that, will
> try to decide whether the bitstream buffer contained more than one
> frame. If the size of the buffer is larger than the consumed stream, it
> assumes that there are more frames in the buffer and that the buffer
> should be resubmitted for decode. This rarely works though and actually
> introduces problems, because:
>
> - v7 firmware will always return consumed stream size equal to whatever
> the driver passed to it when running decode (which is the size of the
> whole buffer), which means we will never try to resubmit, because the
> firmware will always tell us that it consumed all the data we passed to
> it;
This does sound like a hardware bug/feature. So in v7 the buffer is never
resubmitted, yes? And this patch makes no difference for v7?
>
> - v6 firmware will return the number of consumed bytes, but will not
> include the padding ("stuffing") bytes that are allowed after the frame
> in VP8. Since there is no way of figuring out how many of those bytes
> follow the frame without getting the frame size from IVF headers (or
> somewhere else, but not from the stream itself), the driver tries to
> guess that padding size is not larger than 4 bytes, which is not always
> true;
How about v5 of MFC? I need to do some additional testing, as I don't want
to introduce any regressions. I remember that this check was a result of a
fair amount of work and testing with v5.
> The only way to make it work is to queue only one frame per buffer from
> userspace and the check in the kernel is useless and wrong for VP8.
> MPEG4 still seems to require it, so keep it only for that format.
Is your goal to give more than one frame in a single buffer and have the
buffer resubmitted? Or the opposite - you are getting the frame resubmitted
without the need? By the contents of this patch I guess the latter, on the
other hand I do remember that at some point the idea was to be able to queue
more than one frame per buffer. I don't remember exactly who was opting for
the ability to queue more frames in a single buffer...
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
>
> Signed-off-by: Pawel Osciak
> Signed-off-by: Arun Kumar K
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index e2aac59..66c1775 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -360,7 +360,7 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx
> *ctx,
> list);
> ctx->consumed_stream += s5p_mfc_hw_call(dev->mfc_ops,
> get_consumed_stream, dev);
> - if (ctx->codec_mode != S5P_MFC_CODEC_H264_DEC &&
> + if (ctx->codec_mode == S5P_MFC_CODEC_MPEG4_DEC &&
> ctx->consumed_stream + STUFF_BYTE <
> src_buf->b->v4l2_planes[0].bytesused) {
> /* Run MFC again on the same buffer */
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] s5p-mfc: add init buffer cmd to MFCV6
From: avnd kiran
Latest MFC v6 firmware requires tile mode and loop filter
setting to be done as part of Init buffer command, in sync
with v7. Since there are two versions of v6 firmware with
different interfaces, it is differenciated using the version
number read back from firmware which is a hexadecimal value
based on the firmware date.
Signed-off-by: avnd kiran
Signed-off-by: Arun Kumar K
---
Changes from v1
---
- Check for v6 firmware date for differenciating old and new firmware
as per comments from Kamil and Sylwester.
---
drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 +
drivers/media/platform/s5p-mfc/regs-mfc-v7.h|2 --
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |8 +++---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 30 ---
5 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 8d0b686..b47567c 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -132,6 +132,7 @@
#define S5P_FIMV_D_METADATA_BUFFER_ADDR_V6 0xf448
#define S5P_FIMV_D_METADATA_BUFFER_SIZE_V6 0xf44c
#define S5P_FIMV_D_NUM_MV_V6 0xf478
+#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V6 0xf47c
#define S5P_FIMV_D_CPB_BUFFER_ADDR_V6 0xf4b0
#define S5P_FIMV_D_CPB_BUFFER_SIZE_V6 0xf4b4
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
index ea5ec2a..82c96fa 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
@@ -18,8 +18,6 @@
#define S5P_FIMV_CODEC_VP8_ENC_V7 25
/* Additional registers for v7 */
-#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V7 0xf47c
-
#define S5P_FIMV_E_SOURCE_FIRST_ADDR_V70xf9e0
#define S5P_FIMV_E_SOURCE_SECOND_ADDR_V7 0xf9e4
#define S5P_FIMV_E_SOURCE_THIRD_ADDR_V70xf9e8
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 4d17df9..f5404a6 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -287,6 +287,7 @@ struct s5p_mfc_priv_buf {
* @warn_start:hardware error code from which warnings start
* @mfc_ops: ops structure holding HW operation function pointers
* @mfc_cmds: cmd structure holding HW commands function pointers
+ * @ver: firmware sub version
*
*/
struct s5p_mfc_dev {
@@ -330,6 +331,7 @@ struct s5p_mfc_dev {
int warn_start;
struct s5p_mfc_hw_ops *mfc_ops;
struct s5p_mfc_hw_cmds *mfc_cmds;
+ int ver;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 2475a3c..ba1d302 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -240,7 +240,6 @@ static inline void s5p_mfc_clear_cmds(struct s5p_mfc_dev
*dev)
/* Initialize hardware */
int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
{
- unsigned int ver;
int ret;
mfc_debug_enter();
@@ -302,12 +301,13 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
return -EIO;
}
if (IS_MFCV6_PLUS(dev))
- ver = mfc_read(dev, S5P_FIMV_FW_VERSION_V6);
+ dev->ver = mfc_read(dev, S5P_FIMV_FW_VERSION_V6);
else
- ver = mfc_read(dev, S5P_FIMV_FW_VERSION);
+ dev->ver = mfc_read(dev, S5P_FIMV_FW_VERSION);
mfc_debug(2, "MFC F/W version : %02xyy, %02xmm, %02xdd\n",
- (ver >> 16) & 0xFF, (ver >> 8) & 0xFF, ver & 0xFF);
+ (dev->ver >> 16) & 0xFF, (dev->ver >> 8) & 0xFF,
+ dev->ver & 0xFF);
s5p_mfc_clock_off();
mfc_debug_leave();
return 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 90edb19..356cfe5 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -14,6 +14,7 @@
#undef DEBUG
+#include
#include
#include
#include
@@ -1269,6 +1270,29 @@ static int s5p_mfc_set_enc_params_vp8(struct s5p_mfc_ctx
*ctx)
return 0;
}
+/* Check if newer v6 firmware with changed init buffer interface */
+static bool s5p_mfc_is_v6_new(struct s5p_mfc_dev *dev)
+{
+ unsigned long cur_fw, v6_new_fw;
+ unsigned int y, m, d;
+
+ if (IS_MFCV7(dev))
+ return false;
+
+ y = bcd2bin((dev->ver >> 16) & 0xFF) + 2000;
+ m = bcd2bin((dev->ver >> 8) & 0xFF);
+ d = bcd2bin(dev->ver & 0xFF);
+
+ cur_fw = mktime(y, m, d, 0, 0, 0);
+ /*
+* Firmware versi
[PATCH 1/5] ARM: dts: exynos4x12: Add ADC's dt data to read raw data
This patch add ADC(Analog to Digital Converter)'s dt data to get raw data
with IIO subsystem. Usually, ADC is used to check temperature, jack type, and
so on.
Register map
- <0x126C 0x100> : ADC register's base address
- <0x10020718 0x4> : ADC_PHY_CONTROL, TS-ADC control register address
Clock
- <&clock 326> : ADC clock (clock name :'tsadc')
Interrupt
- INTG10[3] : ADC for General ADC
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 5c412aa..5a3e551 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -80,6 +80,18 @@
};
};
+ adc: adc@126C {
+ compatible = "samsung,exynos-adc-v1";
+ reg = <0x126C 0x100>, <0x10020718 0x4>;
+ interrupt-parent = <&combiner>;
+ interrupts = <10 3>;
+ clocks = <&clock 326>;
+ clock-names = "adc";
+ #io-channel-cells = <1>;
+ io-channel-ranges;
+ status = "disabled";
+ };
+
pinctrl_2: pinctrl@0386 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x0386 0x1000>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: dts: exynos4412-trats2: Add ADC's dt data to get temperature of SoC/battery
This patch use ADC to get the temperature of SoC/battery by using NTC thermistor
driver in hwmon. NTC thermistor driver covnvert ADC's raw data to temperature
by using following variables:
- pullup-uv: Voltage
- pullup-ohm : Pull-up resistance
- pulldown-ohm : Pull-down resistance
- io-channels : It means ADC channel.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-trats2.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 4f851cc..fc517c3 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -106,6 +106,27 @@
};
};
+ adc: adc@126C {
+ vdd-supply = <&ldo3_reg>;
+ status = "okay";
+
+ ncp15wb473@0 {
+ compatible = "ntc,ncp15wb473";
+ pullup-uv = <180>; /* VCC_1.8V_AP */
+ pullup-ohm = <10>; /* 100K */
+ pulldown-ohm = <10>; /* 100K */
+ io-channels = <&adc 1>; /* AP temperature */
+ };
+
+ ncp15wb473@1 {
+ compatible = "ntc,ncp15wb473";
+ pullup-uv = <180>; /* VCC_1.8V_AP */
+ pullup-ohm = <10>; /* 100K */
+ pulldown-ohm = <10>; /* 100K */
+ io-channels = <&adc 2>; /* Battery temperature */
+ };
+ };
+
i2c@1389 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: dts: exynos4x12: Add GPS_ALIVE power domain
This patch add GPS_ALIVE power domain for Exynos4x12 SoC. GPS_ALIVE power domain
include GPS_BLK for GPS IP. Exynos SoC used generic power-domain driver to
control power domain. After completed kernel booting, Exynos power-domain driver
disable un-used power domain to reduce power-consumption/leak.
If GPS_ALIVE power domain isn't registered to Exynos power-domain driver,
happen power-leakage because GPS_ALIVE_CONFIGURATION is default power on state.
- 0x10023D00 : GPS_ALIVE_CONFIGURATION register address
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 1ec77f6..066eb35 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -41,6 +41,11 @@
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
};
+
+ pd_gps_alive: gps-alive-power-domain@10023D00 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10023D00 0x20>;
+ };
clock: clock-controller@1003 {
compatible = "samsung,exynos4412-clock";
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: dts: exynos: Move common dt data for interrupt combiner controller
This patch move common dt data of interrupt combiner controller to
exynos4x12.dtsi. Each Exynos4x12 SoC has different number of interrput combiner
as following:
- Exynos4212 : interrput combiner 18(0 ~ 17)
- Exynos4412 : interrput combiner 20(0 ~ 19)
The exynos combiner driver initialize interrupt according to specific number
of interrput combiner.
- samsung,combiner-nr : The number of interrput combiners supported.
Also,
This patch arrange again the dt data according to register address
in exynos4212/exynos4412.dtsi.
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4212.dtsi | 13 -
arch/arm/boot/dts/exynos4412.dtsi | 14 --
arch/arm/boot/dts/exynos4x12.dtsi | 8
3 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index 94a43f9..ceefc71 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -22,16 +22,11 @@
/ {
compatible = "samsung,exynos4212";
- gic: interrupt-controller@1049 {
- cpu-offset = <0x8000>;
+ combiner: interrupt-controller@1044 {
+ samsung,combiner-nr = <18>;
};
- interrupt-controller@1044 {
- samsung,combiner-nr = <18>;
- interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
-<0 107 0>, <0 108 0>;
+ gic: interrupt-controller@1049 {
+ cpu-offset = <0x8000>;
};
};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 87b339c..a40b6e2 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -22,17 +22,11 @@
/ {
compatible = "samsung,exynos4412";
- gic: interrupt-controller@1049 {
- cpu-offset = <0x4000>;
- };
-
- interrupt-controller@1044 {
+ combiner: interrupt-controller@1044 {
samsung,combiner-nr = <20>;
- interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
-<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
-<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
-<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
-<0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
};
+ gic: interrupt-controller@1049 {
+ cpu-offset = <0x4000>;
+ };
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 066eb35..6e17034 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -73,6 +73,14 @@
};
};
+ combiner: interrupt-controller@1044 {
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
+<0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
+<0 107 0>, <0 108 0>, <0 48 0>, <0 42 0>;
+ };
+
pinctrl_0: pinctrl@1140 {
compatible = "samsung,exynos4x12-pinctrl";
reg = <0x1140 0x1000>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: dts: exynos4x12: Add PMU dt data to support PMU(Perforamnce Monitoring Unit)
ARM CPU has its own performance profiling unit(PMU, Perforamnce Monitoring
Unit).
This patch add PMU dt data to support PMU which count cache hit and miss events.
PMU interrput list of Exynos4212
- <2 2> : INTG2[2] - PMUIRQ[0] for CPU0
- <3 2> : INTG3[2] - PMUIRQ[1] for CPU1
PMU interrput list of Exynos4412
- <2 2> : INTG2[2], PMUIRQ[0] for CPU0
- <3 2> : INTG3[2], PMUIRQ[1] for CPU1
- <18 2> : INTG18[2], PMUIRQ[2] : CPU2
- <19 2> : INTG19[2], PMUIRQ[3] : CPU3
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 5a3e551..1ec77f6 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -31,6 +31,12 @@
mshc0 = &mshc_0;
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
+ };
+
pd_isp: isp-power-domain@10023CA0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] ARM: dts: exynos: Add missing dt data to bring kernel of Exynos4x12
This patch add missing dt data of Exynos4x12 to bring up kernel feature and code clean. exynos4x12/exynos4412/exynos4212.dtsi - Add ADC (Analog and Digital Converter) to get raw data - Add PMU (Performance Monitoring Unit) for perf event - Add gps_alive power domain to remove power leakage when gps-alive isn't used - Remove duplicate dt data of interrput combiner controller exynos4412-trats.dts - Add ADC dt data with ntc thermistor child to read temperature Chanwoo Choi (5): ARM: dts: exynos4x12: Add ADC's dt data to read raw data ARM: dts: exynos4x12: Add PMU dt data to support PMU(Perforamnce Monitoring Unit) ARM: dts: exynos4x12: Add GPS_ALIVE power domain ARM: dts: exynos: Move common dt data for interrupt combiner controller ARM: dts: exynos4412-trats2: Add ADC's dt data to get temperature of SoC/battery arch/arm/boot/dts/exynos4212.dtsi | 13 - arch/arm/boot/dts/exynos4412-trats2.dts | 21 + arch/arm/boot/dts/exynos4412.dtsi | 14 -- arch/arm/boot/dts/exynos4x12.dtsi | 31 +++ 4 files changed, 60 insertions(+), 19 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
