[PATCH v3 0/9] ARM: dts: exynos: add support for hdmi subsystem
Common properties for I2C and Hdmi Subsystem is moved to exynos5 dtsi file. It also adds Device tree nodes and clocks information for exynos5420 and exynos5250 SoCs. It adds pinctrl node for hdmi hpd gpio and update binding documents. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. v3: 1) Rebase to kgene for-next based on 3.11-rc1. 2) Changes clock numbers as per updated clocks file for exyno5250 and exynos5420. 3) Dropped Sachin patch as already got merged. v2: 1) Added patch for moving common i2c properties to exynos5.dtsi 2) Added patch for moving common hdmi, mixer properties to exynos5.dtsi 3) moved hpd pinctrl node to board file. 4) Added Sachin's patch to update binding document for hdmi with hpd information. Andrew Bresticker (1): ARM: dts: exynos5420: add i2c device nodes Rahul Sharma (7): ARM: dts: exynos5250: add clocks to hdmi dt node ARM: dts: exynos5250: move common i2c properties to exynos5 dtsi ARM: dts: exynos5250: move common hdmi properties to exynos5 dtsi ARM: dts: exynos5420: add dt nodes for hdmi subsystem ARM: dts: exynos5420: add clocks for hdmi subsystem ARM: dts: exynos5420: add hdmi hpd gpio pinctrl node of/documentation: update with clock information for exynos hdmi subsystem Sean Paul (1): ARM: dts: exynos5250: add mixer clocks to mixer node .../devicetree/bindings/video/exynos_hdmi.txt | 14 +- .../devicetree/bindings/video/exynos_mixer.txt |4 ++ arch/arm/boot/dts/cros5250-common.dtsi |2 +- arch/arm/boot/dts/exynos5.dtsi | 48 arch/arm/boot/dts/exynos5250-arndale.dts |8 +++- arch/arm/boot/dts/exynos5250-smdk5250.dts | 10 +++- arch/arm/boot/dts/exynos5250-snow.dts |8 arch/arm/boot/dts/exynos5250.dtsi | 36 +++ arch/arm/boot/dts/exynos5420-smdk5420.dts | 31 + arch/arm/boot/dts/exynos5420.dtsi | 46 +++ 10 files changed, 174 insertions(+), 33 deletions(-) -- 1.7.10.4 -- 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 v3 2/9] ARM: dts: exynos5250: add clocks to hdmi dt node
Fix wrong clock numbers in hdmi dt node. Removed hdmiphy
clock which was a dummy clock earlier and not required now.
Also added mux clock to change the clock parent.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 1dfd3ad..93d6cc5 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -602,10 +602,10 @@
compatible = samsung,exynos4212-hdmi;
reg = 0x1453 0x7;
interrupts = 0 95 0;
- clocks = clock 333, clock 136, clock 137,
- clock 333, clock 333;
+ clocks = clock 344, clock 136, clock 137,
+ clock 159, clock 1024;
clock-names = hdmi, sclk_hdmi, sclk_pixel,
- sclk_hdmiphy, hdmiphy;
+ sclk_hdmiphy, mout_hdmi;
};
mixer {
--
1.7.10.4
--
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 v3 5/9] ARM: dts: exynos5250: move common hdmi properties to exynos5 dtsi
Hdmi Subsystem nodes shares many properties across exynos5 SoCs
(exynos5250 and exyno5420). Common code is moved to exynos5.dtsi
which is included in exyno5250 and exynos5420 SoC files.
It also renames the hdmi and mixer nodes as per dt naming
convention in the format name@phy_add.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/cros5250-common.dtsi|2 +-
arch/arm/boot/dts/exynos5.dtsi| 12
arch/arm/boot/dts/exynos5250-arndale.dts |7 ++-
arch/arm/boot/dts/exynos5250-smdk5250.dts |7 ++-
arch/arm/boot/dts/exynos5250-snow.dts |8
arch/arm/boot/dts/exynos5250.dtsi |8 ++--
6 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index dc259e8b..bef56fa 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -299,7 +299,7 @@
status = disabled;
};
- hdmi {
+ hdmi@1453 {
hpd-gpio = gpx3 7 0;
};
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 1ae179e..dcb4943 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -144,4 +144,16 @@
#size-cells = 0;
status = disabled;
};
+
+ hdmi@1453 {
+ reg = 0x1453 0x7;
+ interrupts = 0 95 0;
+ status = disabled;
+ };
+
+ mixer@1445 {
+ reg = 0x1445 0x1;
+ interrupts = 0 94 0;
+ status = disabled;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 83ab780..955ecfc 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -471,13 +471,18 @@
};
};
- hdmi {
+ hdmi@1453 {
+ status = okay;
hpd-gpio = gpx3 7 2;
vdd_osc-supply = ldo10_reg;
vdd_pll-supply = ldo8_reg;
vdd-supply = ldo8_reg;
};
+ mixer@1445 {
+ status = okay;
+ };
+
regulators {
compatible = simple-bus;
#address-cells = 1;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 945e6cc..1cce2e8 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -221,10 +221,15 @@
status = disabled;
};
- hdmi {
+ hdmi@1453 {
+ status = okay;
hpd-gpio = gpx3 7 0;
};
+ mixer@1445 {
+ status = okay;
+ };
+
codec@1100 {
samsung,mfc-r = 0x4300 0x80;
samsung,mfc-l = 0x5100 0x80;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index e79331d..b1378af 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -196,4 +196,12 @@
clock-frequency = 2400;
};
};
+
+ hdmi@1453 {
+ status = okay;
+ };
+
+ mixer@1445 {
+ status = okay;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index de54b38..f587cd7 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -578,20 +578,16 @@
clock-names = gscl;
};
- hdmi {
+ hdmi@1453 {
compatible = samsung,exynos4212-hdmi;
- reg = 0x1453 0x7;
- interrupts = 0 95 0;
clocks = clock 344, clock 136, clock 137,
clock 159, clock 1024;
clock-names = hdmi, sclk_hdmi, sclk_pixel,
sclk_hdmiphy, mout_hdmi;
};
- mixer {
+ mixer@1445 {
compatible = samsung,exynos5250-mixer;
- reg = 0x1445 0x1;
- interrupts = 0 94 0;
clocks = clock 343, clock 136;
clock-names = mixer, sclk_hdmi;
};
--
1.7.10.4
--
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 v3 7/9] ARM: dts: exynos5420: add clocks for hdmi subsystem
Add clocks for hdmi and mixer for exynos5420 SoC.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 93caef7..5fa4093 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -180,9 +180,15 @@
hdmi@1453 {
compatible = samsung,exynos4212-hdmi;
+ clocks = clock 413, clock 143, clock 144,
+ clock 158, clock 1024;
+ clock-names = hdmi, sclk_hdmi, sclk_pixel,
+ sclk_hdmiphy, mout_hdmi;
};
mixer@1445 {
compatible = samsung,exynos5420-mixer;
+ clocks = clock 431, clock 143;
+ clock-names = mixer, sclk_hdmi;
};
};
--
1.7.10.4
--
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 v3 1/9] ARM: dts: exynos5250: add mixer clocks to mixer node
From: Sean Paul seanp...@chromium.org
This patch adds the mixer clocks to the mixer node in the
exynos 5250 dts file.
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..1dfd3ad 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -612,6 +612,8 @@
compatible = samsung,exynos5250-mixer;
reg = 0x1445 0x1;
interrupts = 0 94 0;
+ clocks = clock 343, clock 136;
+ clock-names = mixer, sclk_hdmi;
};
dp-controller {
--
1.7.10.4
--
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 v3 9/9] of/documentation: update with clock information for exynos hdmi subsystem
Adding information about clocks to the binding documentation
for exynos mixer and hdmi.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt | 14 +-
Documentation/devicetree/bindings/video/exynos_mixer.txt |4
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 323983b..94aaa7d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -12,7 +12,19 @@ Required properties:
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
-
+- clocks: list of clock IDs from SoC clock driver.
+ a) hdmi: It is required for gate operation on aclk_200_disp1 clock
+ which clocks the display1 block.
+ b) sclk_hdmi: It is required for gate operation on sclk_hdmi clock
+ which clocks hdmi IP.
+ c) sclk_pixel: Parent for mux mout_hdmi.
+ d) sclk_hdmiphy: Parent for mux mout_hdmi.
+ e) mout_hdmi: It is required by the driver to switch between the 2
+ parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
+ after configuration, parent is set to sclk_hdmiphy else
+ sclk_pixel.
+- clock-names: aliases as per driver requirements for above clock IDs:
+ hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and mout_hdmi.
Example:
hdmi {
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 3334b0a..94b40b6 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -10,6 +10,10 @@ Required properties:
- reg: physical base address of the mixer and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
+- clocks: list of clock IDs from SoC clock driver.
+ a) mixer: It is required for gate operation on aclk_200_disp1 clock
+ which clocks the display1 block.
+ b) sclk_hdmi: Parent for mux mout_mixer.
Example:
--
1.7.10.4
--
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 v3 6/9] ARM: dts: exynos5420: add dt nodes for hdmi subsystem
Add hdmi, mixer, ddc device tree nodes for Exynos 5420 SoC.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 20
arch/arm/boot/dts/exynos5420.dtsi |8
2 files changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 08607df..fcd0f69 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -30,4 +30,24 @@
clock-frequency = 2400;
};
};
+
+ hdmi@1453 {
+ status = okay;
+ hpd-gpio = gpx3 7 0;
+ };
+
+ mixer@1445 {
+ status = okay;
+ };
+
+ i2c_2: i2c@12C8 {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 66000;
+ status = okay;
+
+ hdmiddc@50 {
+ compatible = samsung,exynos4210-hdmiddc;
+ reg = 0x50;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 953f877..93caef7 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -177,4 +177,12 @@
pinctrl-names = default;
pinctrl-0 = i2c3_bus;
};
+
+ hdmi@1453 {
+ compatible = samsung,exynos4212-hdmi;
+ };
+
+ mixer@1445 {
+ compatible = samsung,exynos5420-mixer;
+ };
};
--
1.7.10.4
--
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 v3 4/9] ARM: dts: exynos5420: add i2c device nodes
From: Andrew Bresticker abres...@chromium.org
This adds device-tree nodes for the i2c busses on Exynos
5420 platforms.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..953f877 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -24,6 +24,10 @@
pinctrl2 = pinctrl_2;
pinctrl3 = pinctrl_3;
pinctrl4 = pinctrl_4;
+ i2c0 = i2c_0;
+ i2c1 = i2c_1;
+ i2c2 = i2c_2;
+ i2c3 = i2c_3;
};
cpus {
@@ -145,4 +149,32 @@
clocks = clock 260, clock 131;
clock-names = uart, clk_uart_baud0;
};
+
+ i2c_0: i2c@12C6 {
+ clocks = clock 261;
+ clock-names = i2c;
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_bus;
+ };
+
+ i2c_1: i2c@12C7 {
+ clocks = clock 262;
+ clock-names = i2c;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_bus;
+ };
+
+ i2c_2: i2c@12C8 {
+ clocks = clock 263;
+ clock-names = i2c;
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_bus;
+ };
+
+ i2c_3: i2c@12C9 {
+ clocks = clock 264;
+ clock-names = i2c;
+ pinctrl-names = default;
+ pinctrl-0 = i2c3_bus;
+ };
};
--
1.7.10.4
--
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 v3 8/9] ARM: dts: exynos5420: add hdmi hpd gpio pinctrl node
Add pinctrl node for hdmi-hpd gpio pin to exynos5420
device tree files.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index fcd0f69..0f98eab 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -31,9 +31,20 @@
};
};
+ pinctrl@1340 {
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
hdmi@1453 {
status = okay;
hpd-gpio = gpx3 7 0;
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_hpd_irq;
};
mixer@1445 {
--
1.7.10.4
--
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 v3 3/9] ARM: dts: exynos5250: move common i2c properties to exynos5 dtsi
I2C nodes shares many properties across exynos5 SoCs (exynos5250
and exyno5420). Common code is moved to exynos5.dtsi which is
included in exyno5250 and exynos5420 SoC files.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5.dtsi| 36 +
arch/arm/boot/dts/exynos5250-arndale.dts |1 +
arch/arm/boot/dts/exynos5250-smdk5250.dts |3 +++
arch/arm/boot/dts/exynos5250.dtsi | 20
4 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index f65e124..1ae179e 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -108,4 +108,40 @@
interrupts = 0 42 0;
status = disabled;
};
+
+ i2c_0: i2c@12C6 {
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C6 0x100;
+ interrupts = 0 56 0;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ i2c_1: i2c@12C7 {
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C7 0x100;
+ interrupts = 0 57 0;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ i2c_2: i2c@12C8 {
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C8 0x100;
+ interrupts = 0 58 0;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ i2c_3: i2c@12C9 {
+ compatible = samsung,s3c2440-i2c;
+ reg = 0x12C9 0x100;
+ interrupts = 0 59 0;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 96d528d..83ab780 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -31,6 +31,7 @@
};
i2c@12C6 {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
samsung,i2c-slave-addr = 0x66;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 49f18c2..945e6cc 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -28,6 +28,7 @@
};
i2c@12C6 {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
@@ -62,6 +63,7 @@
};
i2c@12C7 {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
@@ -101,6 +103,7 @@
};
i2c@12C8 {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 93d6cc5..de54b38 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -217,11 +217,6 @@
};
i2c_0: i2c@12C6 {
- compatible = samsung,s3c2440-i2c;
- reg = 0x12C6 0x100;
- interrupts = 0 56 0;
- #address-cells = 1;
- #size-cells = 0;
clocks = clock 294;
clock-names = i2c;
pinctrl-names = default;
@@ -229,11 +224,6 @@
};
i2c_1: i2c@12C7 {
- compatible = samsung,s3c2440-i2c;
- reg = 0x12C7 0x100;
- interrupts = 0 57 0;
- #address-cells = 1;
- #size-cells = 0;
clocks = clock 295;
clock-names = i2c;
pinctrl-names = default;
@@ -241,11 +231,6 @@
};
i2c_2: i2c@12C8 {
- compatible = samsung,s3c2440-i2c;
- reg = 0x12C8 0x100;
- interrupts = 0 58 0;
- #address-cells = 1;
- #size-cells = 0;
clocks = clock 296;
clock-names = i2c;
pinctrl-names = default;
@@ -253,11 +238,6 @@
};
i2c_3: i2c@12C9 {
- compatible = samsung,s3c2440-i2c;
- reg = 0x12C9 0x100;
- interrupts = 0 59 0;
- #address-cells = 1;
- #size-cells = 0;
clocks = clock 297;
clock-names = i2c;
pinctrl-names = default;
--
1.7.10.4
--
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
Re: [PATCH v3 07/22] ARM: dts: Remove '0x's from Exynos4210 DTSI file
On Wed, 24 Jul 2013, Tomasz Figa wrote:
On Wednesday 24 of July 2013 16:09:37 Lee Jones wrote:
... for the sake of consistency and assumed convention.
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi index b7f358a..53e2527 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -72,7 +72,7 @@
};
};
- clock: clock-controller@0x1003 {
+ clock: clock-controller@1003 {
compatible = samsung,exynos4210-clock;
reg = 0x1003 0x2;
#clock-cells = 1;
Acked-by: Tomasz Figa t.f...@samsung.com
Thanks Tomasz.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Kishon Vijay Abraham I wrote: On Thursday 25 July 2013 12:02 AM, Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. The OMAP3 platforms still needs to be supported for non-dt :-s Can't you leave the existing PHY handling for legacy OMAP3 USB PHY until they are all converted? I don't expect that to take a long time now that the OMAP4 board files have been removed. Are there still drivers without DT bindings that hold up the removal of the OMAP3 board files? Otherwise I'd suggest delaying the phy subsystem by another merge window, until that is resolved. 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 01/15] drivers: phy: add generic PHY framework
On Wed, Jul 24, 2013 at 08:32:03PM +0200, Arnd Bergmann wrote: Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. There's a bunch of non-DT architectures that are in active use (blackfin for example) and I'd really hope that this is useful for some of them. The pushback here was about the fact that the subsystem was doing odd things with selecting device names which is odd in itself, I don't know if that had bled over into the DT bindings but it sounded like it might've done so. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Arnd, On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a *new* framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? -- Regards, Laurent Pinchart -- 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/3] watchdog: s3c2410_wdt: parse watchdog dt node to read PMU registers adresses
Hi Leela,
On Wednesday 24 of July 2013 15:08:17 Leela Krishna Amudala wrote:
This patch parses the watchdog node to read pmu wdt sys registers
addresses and do mask/unmask enable/disable of WDT in probe and s2r
scenarios.
Reviewed-by: Doug Anderson diand...@chromium.org
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
.../devicetree/bindings/watchdog/samsung-wdt.txt | 14 -
drivers/watchdog/s3c2410_wdt.c | 56
2 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt index
2aa486c..4c798e3 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -7,8 +7,20 @@ occurred.
Required properties:
- compatible : should be samsung,s3c2410-wdt
- reg : base physical address of the controller and length of memory
mapped - region.
+ region and the optional (addresses and length of memory mapped regions
+ of) PMU registers for masking/unmasking WDT.
- interrupts : interrupt number to the cpu.
I don't think PMU registers should be passed like this, even if USB PHY
driver currently does it - it needs to be fixed. Every time you are mapping
a single 4-byte register, you are creating new mapping for the whole page
(4K) containing it. In addition, this makes the WDT driver map IO memory
that does not belong to the IP block it handles, which is not nice.
I would suggest looking into regmap helpers to implement a driver for the
PMU that can share PMU registers with interested drivers.
Optional properties:
- timeout-sec : contains the watchdog timeout in seconds.
+- reset-mask-bit: bit number in the PMU registers to program mask/unmask
WDT. +
+Example:
If WDT of Exynos 5420 needs special masking, it is no longer compatible
with samsung,s3c2410-wdt. You need to create separate compatible for it
(samsung,exynos5420-wdt) and do this special masking only for devices
using it.
+watchdog {
+ compatible = samsung,s3c2410-wdt;
+ reg = 0x101D 0x100, 0x10040408 0x4, 0x1004040c 0x4;
+ interrupts = 0 42 0;
+ status = disabled;
+ reset-mask-bit = 0;
+};
By the way, you need to Cc devicet...@vger.kernel.org mailing if you modify
device tree bindings.
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 01/15] drivers: phy: add generic PHY framework
On Thursday 25 July 2013, Laurent Pinchart wrote: On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote: On Tuesday 23 July 2013, Tomasz Figa wrote: On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Sorry for jumping in to the middle of the discussion, but why does a new framework even bother defining an interface for board files? Can't we just drop any interfaces for platform data passing in the phy framework and put the burden of adding those to anyone who actually needs them? All the platforms we are concerned with here (exynos and omap, plus new platforms) can be booted using DT anyway. What about non-DT architectures such as MIPS (still widely used in consumer networking equipments from what I've heard) ? * Vendors of such equipment have started moving on to ARM (e.g. Broadcom bcm47xx) * Some of the modern MIPS platforms are now using DT * Legacy platforms probably won't migrate to either DT or the generic PHY framework I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. 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 01/15] drivers: phy: add generic PHY framework
On Thu, Jul 25, 2013 at 01:00:49PM +0200, Arnd Bergmann wrote: I'm not saying that we can't support legacy board files with the common PHY framework, but I'd expect things to be much easier if we focus on those platforms that are actively being worked on for now, to bring an end to the pointless API discussion. Well, it seemed like Greg's concerns had already been addressed anyway. signature.asc Description: Digital signature
Re: [PATCH v5 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag
Hi James, On 06/13/2013 06:06 PM, James Hogan wrote: Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes being reparented during clk_set_rate. To avoid breaking existing platforms, all callers of clk_register_mux() are adjusted to pass the new flag. Platform maintainers are encouraged to remove the flag if they wish to allow mux reparenting on set_rate. [..] Changes in v3: * rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move to this new patch. * patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of clk_register_mux. If you don't mind your clocks being reparented in response to set_rate please let me know and I'll drop the relevant portion of the patch. Why is this better to change current behaviour of the clock core and modify all drivers instead of having, e.g. CLK_SET_RATE_REPARENT set in drivers of hardware that supports clock re-parenting while setting clock rate ? Is there intention to just have the automatic clock re-parenting as a default feature in the common clock API ? My apologies if this has already been answered, I haven't been following this thread. Thanks, Sylwester arch/arm/mach-imx/clk.h | 5 +- drivers/clk/mmp/clk-mmp2.c | 39 +--- drivers/clk/mmp/clk-pxa168.c | 40 +--- drivers/clk/mmp/clk-pxa910.c | 31 +++--- drivers/clk/mxs/clk.h| 4 +- drivers/clk/samsung/clk.h| 2 +- drivers/clk/spear/spear1310_clock.c | 179 ++- drivers/clk/spear/spear1340_clock.c | 97 ++- drivers/clk/spear/spear3xx_clock.c | 57 +++ drivers/clk/spear/spear6xx_clock.c | 35 +++ drivers/clk/sunxi/clk-sunxi.c| 3 +- drivers/clk/tegra/clk-tegra114.c | 36 --- drivers/clk/tegra/clk-tegra20.c | 6 +- drivers/clk/tegra/clk-tegra30.c | 33 --- drivers/clk/versatile/clk-vexpress.c | 4 +- include/linux/clk-provider.h | 1 + 16 files changed, 334 insertions(+), 238 deletions(-) -- Sylwester Nawrocki Samsung RD Institute Poland -- 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 v5 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag
Hi Sylwester On 25/07/13 13:34, Sylwester Nawrocki wrote: On 06/13/2013 06:06 PM, James Hogan wrote: Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes being reparented during clk_set_rate. To avoid breaking existing platforms, all callers of clk_register_mux() are adjusted to pass the new flag. Platform maintainers are encouraged to remove the flag if they wish to allow mux reparenting on set_rate. [..] Changes in v3: * rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move to this new patch. * patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of clk_register_mux. If you don't mind your clocks being reparented in response to set_rate please let me know and I'll drop the relevant portion of the patch. Why is this better to change current behaviour of the clock core and modify all drivers instead of having, e.g. CLK_SET_RATE_REPARENT set in drivers of hardware that supports clock re-parenting while setting clock rate ? See this message from Mike Turquette which first suggested it: http://marc.info/?l=linux-kernelm=136847508109344w=2 Is there intention to just have the automatic clock re-parenting as a default feature in the common clock API ? Yes, that would be the result (except where explicitly disallowed). Unfortunately where such policy should ideally be defined is still up in the air. It's not a property of the hardware, but then it is arguably a property of the environment the bootloader has configured (like the stuff in the /chosen device tree node). Presuming that the usual reason not to reparent a mux is because other important clocks depend on it, the kernel might know enough to work out whether it's safe (unless of course there are other cores/threads in the SoC using the clock that Linux isn't aware of, which brings us back to it being a bootloader environment thing). My apologies if this has already been answered, I haven't been following this thread. No problem :) Cheers James -- 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
XCLKOUT in exynos5250 clock driver
I appear to be missing something in the clock driver for the exynos5250. I'm looking at the Arndale schematic and I see that the audio master clock is connected to XCLKOUT on the SoC. However I can't see any reference to XCLKOUT or anything similar in the clock driver or any of the DTS files - where is this clock exposed by the clock driver? Unfortunately I haven't been able to get access to the datasheet for the part so I can't check this myself. signature.asc Description: Digital signature
Re: [PATCH] V4L: Add driver for Samsung S5K5BAF camera sensor
On Wed 24 July 2013 19:51:03 Sylwester Nawrocki wrote:
From: Andrzej Hajda a.ha...@samsung.com
This patch adds V4L2 subdev driver for Samsung S5K5BAF CMOS
image sensor with embedded SoC ISP.
The driver exposes two V4L2 subdevices:
- S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format,
no controls.
- S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200,
pre/post ISP cropping, downscaling via selection API, controls.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
v4:
- endpoint node presence is now optional,
- added asynchronous subdev registration support and clock
handling,
- GPL changed to GPLv2,
- bitfields replaced by u8,
- corrected s_stream flow,
- gpio pins are no longer exported,
- added I2C addresses to subdev names,
- CIS subdev registration postponed after succesfull
HW initialization,
- added enums for pads,
- selections are initialized only during probe,
- default resolution changed to 1600x1200,
- state-error pattern removed from few other functions,
- entity link creation moved to registered callback,
- some cosmetic changes.
v3:
- narrowed state-error usage to i2c and power errors,
- private gain controls replaced by red/blue balance user controls,
- added checks to devicetree gpio node parsing
v2:
- lower-cased driver name,
- removed underscore from regulator names,
- removed platform data code,
- v4l controls grouped in anonymous structs,
- added s5k5baf_clear_error function,
- private controls definitions moved to uapi header file,
- added v4l2-controls.h reservation for private controls,
- corrected subdev registered/unregistered code,
- .log_status sudbev op set to v4l2 helper,
- moved entity link creation to probe routines,
- added cleanup on error to probe function.
---
.../devicetree/bindings/media/samsung-s5k5baf.txt | 58 +
MAINTAINERS|7 +
drivers/media/i2c/Kconfig |7 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k5baf.c| 2048
5 files changed, 2121 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/samsung-s5k5baf.txt
create mode 100644 drivers/media/i2c/s5k5baf.c
snip
+
+enum selection_rect { R_CIS, R_CROP_SINK, R_COMPOSE, R_CROP_SOURCE,
R_INVALID };
+
+static enum selection_rect s5k5baf_get_sel_rect(u32 pad, u32 target)
+{
+ switch (target) {
+ case V4L2_SEL_TGT_CROP_BOUNDS:
+ return pad ? R_COMPOSE : R_CIS;
+ case V4L2_SEL_TGT_CROP:
+ return pad ? R_CROP_SOURCE : R_CROP_SINK;
+ case V4L2_SEL_TGT_COMPOSE_BOUNDS:
+ return pad ? R_INVALID : R_CROP_SINK;
+ case V4L2_SEL_TGT_COMPOSE:
+ return pad ? R_INVALID : R_COMPOSE;
+ default:
+ return R_INVALID;
+ }
+}
+
+static int s5k5baf_is_bound_target(u32 target)
+{
+ return (target == V4L2_SEL_TGT_CROP_BOUNDS ||
+ target == V4L2_SEL_TGT_COMPOSE_BOUNDS);
+}
+
+static int s5k5baf_get_selection(struct v4l2_subdev *sd,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_selection *sel)
+{
+ static enum selection_rect rtype;
+ struct s5k5baf *state = to_s5k5baf(sd);
+
+ rtype = s5k5baf_get_sel_rect(sel-pad, sel-target);
+
+ switch (rtype) {
+ case R_INVALID:
+ return -EINVAL;
+ case R_CIS:
+ sel-r = s5k5baf_cis_rect;
+ return 0;
+ default:
+ break;
+ }
+
+ if (sel-which == V4L2_SUBDEV_FORMAT_TRY) {
+ if (rtype == R_COMPOSE)
+ sel-r = *v4l2_subdev_get_try_compose(fh, sel-pad);
+ else
+ sel-r = *v4l2_subdev_get_try_crop(fh, sel-pad);
+ return 0;
+ }
+
+ mutex_lock(state-lock);
+ switch (rtype) {
+ case R_CROP_SINK:
+ sel-r = state-crop_sink;
+ break;
+ case R_COMPOSE:
+ sel-r = state-compose;
+ break;
+ case R_CROP_SOURCE:
+ sel-r = state-crop_source;
+ break;
+ default:
+ break;
+ }
+ if (s5k5baf_is_bound_target(sel-target)) {
+ sel-r.left = 0;
+ sel-r.top = 0;
+ }
+ mutex_unlock(state-lock);
+
+ return 0;
+}
+
+/* bounds range [start, start+len) to [0, max) and aligns to 2 */
+static void s5k5baf_bound_range(u32 *start, u32 *len, u32 max)
+{
+ if (*len max)
+ *len = max;
+ if (*start + *len max)
+ *start = max - *len;
+ *start = ~1;
+ *len = ~1;
+ if (*len S5K5BAF_WIN_WIDTH_MIN)
+ *len = S5K5BAF_WIN_WIDTH_MIN;
+}
+
+static void
[PATCHv2 1/2] iommu/exynos: add devices attached to the System MMU to an IOMMU group
IOMMU groups are expected by certain users of the IOMMU API,
e.g. VFIO. Since each device is behind its own System MMU, we
can allocate a new IOMMU group for each device.
This patch depends on Cho KyongHo's patch series titled [PATCH v7 00/12]
iommu/exynos: Fixes and Enhancements of System MMU driver with DT,
applied on a Linux 3.10.1 kernel. It has been tested on the Arndale board.
Changes since in v2:
- Removed possibility for minor memory leak in case of
misbehaving platform drivers
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/iommu/exynos-iommu.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 51d43bb..c7dd4b5 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1134,6 +1134,32 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
iommu_domain *domain,
return phys;
}
+static int exynos_iommu_add_device(struct device *dev)
+{
+ struct iommu_group *group;
+ int ret;
+
+ group = iommu_group_get(dev);
+
+ if (!group) {
+ group = iommu_group_alloc();
+ if (IS_ERR(group)) {
+ dev_err(dev, Failed to allocate IOMMU group\n);
+ return PTR_ERR(group);
+ }
+ }
+
+ ret = iommu_group_add_device(group, dev);
+ iommu_group_put(group);
+
+ return ret;
+}
+
+static void exynos_iommu_remove_device(struct device *dev)
+{
+ iommu_group_remove_device(dev);
+}
+
static struct iommu_ops exynos_iommu_ops = {
.domain_init = exynos_iommu_domain_init,
.domain_destroy = exynos_iommu_domain_destroy,
@@ -1142,6 +1168,8 @@ static struct iommu_ops exynos_iommu_ops = {
.map = exynos_iommu_map,
.unmap = exynos_iommu_unmap,
.iova_to_phys = exynos_iommu_iova_to_phys,
+ .add_device = exynos_iommu_add_device,
+ .remove_device = exynos_iommu_remove_device,
.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
};
--
1.8.1.2
--
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/2] iommu/exynos: Follow kernel coding style for __sysmmu_enable return type
On success, the __sysmmu_enable returns 1 instead of 0, which does not
respect the convention described in Chapter 16 of the Linux kernel coding
style.
In fact, this return value is propagated all the way up to
iommu_attach_device() and iommu_attach_device() in drivers/iommu.c,
which results into inconsistent behavior of the IOMMU API with Exynos
systems, compared to other IOMMUs.
This patch replaces the return value with 0, which makes the Exynos'
IOMMU driver behavior consistent with that of other IOMMUs.
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/iommu/exynos-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index c7dd4b5..4ea3abb 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -504,7 +504,7 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data,
dev_dbg(data-sysmmu, Enabled\n);
} else {
- ret = (pgtable == data-pgtable) ? 1 : -EBUSY;
+ ret = (pgtable == data-pgtable) ? 0 : -EBUSY;
dev_dbg(data-sysmmu, already enabled\n);
}
--
1.8.1.2
--
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] V4L: Add driver for Samsung S5K5BAF camera sensor
Hi Hans, On 07/25/2013 04:42 PM, Hans Verkuil wrote: Would it be an idea to create a library with rectangle manipulation functions? Looking at this driver and similar ones as well that I had to deal with that support cropping/scaling/composing I see a lot of rectangle manipulation. Moving that into a separate source that can be shared should simplify development. Yes, I talked before about this exactly with Andrzej. We will consider creating such a library, but I can't tell at the moment when we can start working on this. There is still a few basic unsupported features of those cameras to take care of. :) Thanks, Sylwester -- 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 v5 4/5] clk: add CLK_SET_RATE_NO_REPARENT flag
Quoting James Hogan (2013-07-25 05:55:09) Hi Sylwester On 25/07/13 13:34, Sylwester Nawrocki wrote: On 06/13/2013 06:06 PM, James Hogan wrote: Add a CLK_SET_RATE_NO_REPARENT clock flag, which will prevent muxes being reparented during clk_set_rate. To avoid breaking existing platforms, all callers of clk_register_mux() are adjusted to pass the new flag. Platform maintainers are encouraged to remove the flag if they wish to allow mux reparenting on set_rate. [..] Changes in v3: * rename/invert CLK_SET_RATE_REMUX to CLK_SET_RATE_NO_REPARENT and move to this new patch. * patch 3: add CLK_SET_RATE_NO_REPARENT flag to all callers of clk_register_mux. If you don't mind your clocks being reparented in response to set_rate please let me know and I'll drop the relevant portion of the patch. Why is this better to change current behaviour of the clock core and modify all drivers instead of having, e.g. CLK_SET_RATE_REPARENT set in drivers of hardware that supports clock re-parenting while setting clock rate ? See this message from Mike Turquette which first suggested it: http://marc.info/?l=linux-kernelm=136847508109344w=2 Is there intention to just have the automatic clock re-parenting as a default feature in the common clock API ? Yes, that would be the result (except where explicitly disallowed). Unfortunately where such policy should ideally be defined is still up in the air. It's not a property of the hardware, but then it is arguably a property of the environment the bootloader has configured (like the stuff in the /chosen device tree node). I'm happy to get feedback on this decision. Looking back on CLK_SET_RATE_PARENT flag I wish I had made that behavior the default. Instead there would only be a flag for the case where you explicitly do not wish to propagate the rate change request up the tree. Another thing to consider here is that only users of .determine_rate are affected. If your mux clock implements .set_parent and .round_rate, but not .determine_rate then you are not affected by this change. The whole thing gets messy because we're pushing policy into the clock framework, but there is no way to avoid that if we're going to achieve the goal of having drivers know only about the leaf clocks they consume and not requiring those drivers to understand the greater clock tree topology. Regards, Mike Presuming that the usual reason not to reparent a mux is because other important clocks depend on it, the kernel might know enough to work out whether it's safe (unless of course there are other cores/threads in the SoC using the clock that Linux isn't aware of, which brings us back to it being a bootloader environment thing). My apologies if this has already been answered, I haven't been following this thread. No problem :) Cheers James -- 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/3] ARM: exynos5420: dt: add clock entries to watchdog node
On 07/24/2013 07:14 AM, Tomasz Figa wrote: On Wednesday 24 of July 2013 16:51:06 Sachin Kamat wrote: ... This is contrary to the fact that we disable everything by default in the top level dt files and only enable them as required in the board dts files. No, we don't disable everything. We disable things that require board specific setup or can't work without other support from board side. If there is some hardware disabled in SoC level dtsi that can work without any support from board side, then it is a BUG() and must be fixed. To illustrate the problem please consider that in the end, a dtb file will be fused into board ROM (or at most flash memory) and passed to the kernel by the bootloader. If you disable some hardware on DT level even if it can be physically used on the board, there will be no way to reenable it, if some user wanted to use it, because that would require editing the fused dtb. I believe some h/w will be disabled in dt only if it should not be used for whatever reason. If there is no reason then ofcourse they would be enabled IMHO. Yes. This is what I meant. However the reason must be valid - e.g. hardware does not allow such configuration, not like some very important manager decided that this board should not use this. Whatever be the case the choice of enabling or disabling should be done at the leaf node (at board level). No? It depends. For components that don't require any support from board side it can be globally enabled on SoC level. If a SoC component requires support from board side (like regulators, GPIOs, etc.) then it should be disabled on SoC level and enabled on board level only if all the dependencies are provided. I tend to agree with Tomasz. One note though: This is talking about the *.dts files, which may be different from the DTB that gets passed to the kernel. In other words, I don't think that the SoC or board .dtsi file (at least public versions that are hosted outside company-internal/downstream branches) have any business disabling HW based on policy or use-cases, rather than actual HW issues such as requiring other HW to support it that isn't present or doesn't work. However, I don't think anyone can influence what e.g.a bootloader does to the DTB before passing it to the kernel; it could add status=disabled to some nodes based on policy, and nobody in the Linux kernel has any absolute right to influence it, although there's sure a right to complain about it and point out why it's a bad idea. Equally, if somebody is creating a BSP (ick!) for a specific product's production flash image, rather than contributing to upstream SW support for that HW board, we probably don't have too much say in what they do. -- 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] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the Exynos4x12 ISP clocks
From: Sylwester Nawrocki s.nawro...@samsung.com
The ISP clock registers belong to the ISP power domain and may change
their values if this power domain is switched off/on. Add
CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached
data when setting or getting frequency of those clocks.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Rebased onto v3.11-rc2.
drivers/clk/samsung/clk-exynos4.c | 64 +++-
1 files changed, 34 insertions(+), 30 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 1bdb882..4e57397 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -581,11 +581,15 @@ struct samsung_div_clock exynos4x12_div_clks[] __initdata
= {
DIV(none, div_spi1_isp, mout_spi1_isp, E4X12_DIV_ISP, 16, 4),
DIV(none, div_spi1_isp_pre, div_spi1_isp, E4X12_DIV_ISP, 20, 8),
DIV(none, div_uart_isp, mout_uart_isp, E4X12_DIV_ISP, 28, 4),
- DIV(div_isp0, div_isp0, aclk200, E4X12_DIV_ISP0, 0, 3),
- DIV(div_isp1, div_isp1, aclk200, E4X12_DIV_ISP0, 4, 3),
+ DIV_F(div_isp0, div_isp0, aclk200, E4X12_DIV_ISP0, 0, 3,
+ CLK_GET_RATE_NOCACHE, 0),
+ DIV_F(div_isp1, div_isp1, aclk200, E4X12_DIV_ISP0, 4, 3,
+ CLK_GET_RATE_NOCACHE, 0),
DIV(none, div_mpwm, div_isp1, E4X12_DIV_ISP1, 0, 3),
- DIV(div_mcuisp0, div_mcuisp0, aclk400_mcuisp, E4X12_DIV_ISP1, 4, 3),
- DIV(div_mcuisp1, div_mcuisp1, div_mcuisp0, E4X12_DIV_ISP1, 8, 3),
+ DIV_F(div_mcuisp0, div_mcuisp0, aclk400_mcuisp, E4X12_DIV_ISP1,
+ 4, 3, CLK_GET_RATE_NOCACHE, 0),
+ DIV_F(div_mcuisp1, div_mcuisp1, div_mcuisp0, E4X12_DIV_ISP1,
+ 8, 3, CLK_GET_RATE_NOCACHE, 0),
DIV(sclk_fimg2d, sclk_fimg2d, mout_g2d, DIV_DMC1, 0, 4),
};
@@ -863,57 +867,57 @@ struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
GATE_DA(i2s0, samsung-i2s.0, i2s0, aclk100,
E4X12_GATE_IP_MAUDIO, 3, 0, 0, iis),
GATE(fimc_isp, isp, aclk200, E4X12_GATE_ISP0, 0,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(fimc_drc, drc, aclk200, E4X12_GATE_ISP0, 1,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(fimc_fd, fd, aclk200, E4X12_GATE_ISP0, 2,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(fimc_lite0, lite0, aclk200, E4X12_GATE_ISP0, 3,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(fimc_lite1, lite1, aclk200, E4X12_GATE_ISP0, 4,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(mcuisp, mcuisp, aclk200, E4X12_GATE_ISP0, 5,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(gicisp, gicisp, aclk200, E4X12_GATE_ISP0, 7,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(smmu_isp, smmu_isp, aclk200, E4X12_GATE_ISP0, 8,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(smmu_drc, smmu_drc, aclk200, E4X12_GATE_ISP0, 9,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(smmu_fd, smmu_fd, aclk200, E4X12_GATE_ISP0, 10,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(smmu_lite0, smmu_lite0, aclk200, E4X12_GATE_ISP0, 11,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(smmu_lite1, smmu_lite1, aclk200, E4X12_GATE_ISP0, 12,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(ppmuispmx, ppmuispmx, aclk200, E4X12_GATE_ISP0, 20,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(ppmuispx, ppmuispx, aclk200, E4X12_GATE_ISP0, 21,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(mcuctl_isp, mcuctl_isp, aclk200, E4X12_GATE_ISP0, 23,
- CLK_IGNORE_UNUSED, 0),
+ CLK_IGNORE_UNUSED | CLK_GET_RATE_NOCACHE, 0),
GATE(mpwm_isp, mpwm_isp, aclk200, E4X12_GATE_ISP0, 24,
Re: [PATCH] clk: exynos4: Add CLK_GET_RATE_NOCACHE flag for the Exynos4x12 ISP clocks
On 07/25/2013 10:23 PM, Mike Turquette wrote: Quoting Sylwester Nawrocki (2013-07-22 05:14:40) On 06/24/2013 08:42 PM, Sylwester Nawrocki wrote: The ISP clock registers belong to the ISP power domain and may change their values if this power domain is switched off/on. Add CLK_GET_RATE_NOCACHE flags to ensure we do not rely on invalid cached data when setting or getting frequency of those clocks. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com Mike, would you consider queueing that patch for current -rc cycle ? Sylwester, Can you rebase this onto -rc2? It does not apply cleanly onto my -fixes branch. Sure, I've just posted an updated version. Thanks, Sylwester -- 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/3] watchdog: s3c2410_wdt: parse watchdog dt node to read PMU registers adresses
Tomasz, On Thu, Jul 25, 2013 at 3:27 AM, Tomasz Figa t.f...@samsung.com wrote: Hi Leela, On Wednesday 24 of July 2013 15:08:17 Leela Krishna Amudala wrote: This patch parses the watchdog node to read pmu wdt sys registers addresses and do mask/unmask enable/disable of WDT in probe and s2r scenarios. Reviewed-by: Doug Anderson diand...@chromium.org Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- .../devicetree/bindings/watchdog/samsung-wdt.txt | 14 - drivers/watchdog/s3c2410_wdt.c | 56 2 files changed, 69 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt index 2aa486c..4c798e3 100644 --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt @@ -7,8 +7,20 @@ occurred. Required properties: - compatible : should be samsung,s3c2410-wdt - reg : base physical address of the controller and length of memory mapped - region. + region and the optional (addresses and length of memory mapped regions + of) PMU registers for masking/unmasking WDT. - interrupts : interrupt number to the cpu. I don't think PMU registers should be passed like this, even if USB PHY driver currently does it - it needs to be fixed. Every time you are mapping a single 4-byte register, you are creating new mapping for the whole page (4K) containing it. In addition, this makes the WDT driver map IO memory that does not belong to the IP block it handles, which is not nice. I would suggest looking into regmap helpers to implement a driver for the PMU that can share PMU registers with interested drivers. We've done this in some other drivers as well. I remember someone suggested that this was fine when I posted the change to the ADC driver for something similar. Do you really think it's worth adding a level of abstraction here? The argument I remember in the past was that it was fine as long as the register itself was used only by this driver. If we want to do as you say, we'll have to figure out whether you want to create a new generic interface for this or reuse an existing one. You could kinda think of these bits as enabling power, so you could use the regulator framework. ...but that framework often gets abused. Olof: I think I got your advice when I did the ADC work. Do you have any advice here? Thanks! -Doug -- 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: [PATCHv2 1/2] iommu/exynos: add devices attached to the System MMU to an IOMMU group
Hi Antonios,
On 25 July 2013 21:04, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
IOMMU groups are expected by certain users of the IOMMU API,
e.g. VFIO. Since each device is behind its own System MMU, we
can allocate a new IOMMU group for each device.
This patch depends on Cho KyongHo's patch series titled [PATCH v7 00/12]
iommu/exynos: Fixes and Enhancements of System MMU driver with DT,
applied on a Linux 3.10.1 kernel.
This kind of meta information should go after the --- line below.
It has been tested on the Arndale board.
Changes since in v2:
- Removed possibility for minor memory leak in case of
misbehaving platform drivers
Signed-off-by: Antonios Motakis a.mota...@virtualopensystems.com
---
drivers/iommu/exynos-iommu.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 51d43bb..c7dd4b5 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1134,6 +1134,32 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
iommu_domain *domain,
return phys;
}
+static int exynos_iommu_add_device(struct device *dev)
+{
+ struct iommu_group *group;
+ int ret;
+
+ group = iommu_group_get(dev);
+
+ if (!group) {
+ group = iommu_group_alloc();
+ if (IS_ERR(group)) {
+ dev_err(dev, Failed to allocate IOMMU group\n);
+ return PTR_ERR(group);
+ }
+ }
+
+ ret = iommu_group_add_device(group, dev);
+ iommu_group_put(group);
+
+ return ret;
+}
+
+static void exynos_iommu_remove_device(struct device *dev)
+{
+ iommu_group_remove_device(dev);
+}
+
static struct iommu_ops exynos_iommu_ops = {
.domain_init = exynos_iommu_domain_init,
.domain_destroy = exynos_iommu_domain_destroy,
@@ -1142,6 +1168,8 @@ static struct iommu_ops exynos_iommu_ops = {
.map = exynos_iommu_map,
.unmap = exynos_iommu_unmap,
.iova_to_phys = exynos_iommu_iova_to_phys,
+ .add_device = exynos_iommu_add_device,
+ .remove_device = exynos_iommu_remove_device,
.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
};
--
1.8.1.2
--
With warm regards,
Sachin
--
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
