Re: [PATCH] video: fbdev: s3c2410fb: Move to clk_prepare_enable/clk_disable_unprepare

[Tomi Valkeinen]

On 30/06/14 22:14, Vasily Khoruzhick wrote:
 Use clk_prepare_enable/clk_disable_unprepare to make the driver
 work properly with common clock framework.
 
 Signed-off-by: Vasily Khoruzhick anars...@gmail.com
 ---
  drivers/video/fbdev/s3c2410fb.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

Thanks, queued for 3.17.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 06/17] video: fbdev: s3c-fb: remove s5p64x0 related fimd codes

[Tomi Valkeinen]

On 01/07/14 00:32, Kukjin Kim wrote:
 This patch removes fimd codes for s5p6440 and s5p6450 SoCs.
 
 Signed-off-by: Kukjin Kim kgene@samsung.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 ---
  .../devicetree/bindings/video/samsung-fimd.txt |1 -
  drivers/video/fbdev/Kconfig|2 +-
  drivers/video/fbdev/s3c-fb.c   |   30 
 
  3 files changed, 1 insertion(+), 32 deletions(-)

Shall I queue this and patch 15/17 via fbdev tree, or are there
dependencies and the whole series should go as one?

If the latter, for this and 15/17:

Acked-by: Tomi Valkeinen tomi.valkei...@ti.com

 Tomi




signature.asc
Description: OpenPGP digital signature

[PATCH] ARM: dts: exynos4412-odroid: add support for GPIO buttons

[Marek Szyprowski]

This patch adds support for simple GPIO-based button availabled on
Exynos4 based Odroid boards. All supported boards have POWER button,
which has been defined in exynos4412-odroid-common.dtsi. X/X2 boards
also have additional user-configurable button which has been mapped to
KEY_HOME. All defined keys have been marked as possible wakeup source.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
Hello,

This patch is a continuation of the '[PATCH v2 0/4] Add Exynos4412 based
Odroid X2 and U2/U3/U3+ support' series
(http://www.spinics.net/lists/linux-samsung-soc/msg33115.html).

Best regards
Marek Szyprowski
Samsung RD Institute Poland
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 
 arch/arm/boot/dts/exynos4412-odroidx.dts| 21 +
 2 files changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index ad2cb32a3439..d1b33a8efa9d 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -7,6 +7,7 @@
  * published by the Free Software Foundation.
 */
 
+#include dt-bindings/input/input.h
 #include exynos4412.dtsi
 
 / {
@@ -15,6 +16,22 @@
reg = 0x0204F000 0x1000;
};
 
+   gpio_keys {
+   compatible = gpio-keys;
+   pinctrl-names = default;
+   pinctrl-0 = gpio_power_key;
+
+   power_key {
+   interrupt-parent = gpx1;
+   interrupts = 3 0;
+   gpios = gpx1 3 1;
+   linux,code = KEY_POWER;
+   label = power key;
+   debounce-interval = 10;
+   gpio-key,wakeup;
+   };
+   };
+
mmc@1255 {
pinctrl-0 = sd4_clk sd4_cmd sd4_bus4 sd4_bus8;
pinctrl-names = default;
@@ -316,3 +333,10 @@
status = okay;
};
 };
+
+pinctrl_1 {
+   gpio_power_key: power_key {
+   samsung,pins = gpx1-3;
+   samsung,pin-pud = 0;
+   };
+};
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 990a04760313..18c567f5dbea 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -46,6 +46,20 @@
status = okay;
};
 
+   gpio_keys {
+   pinctrl-0 = gpio_power_key gpio_home_key;
+
+   home_key {
+   interrupt-parent = gpx2;
+   interrupts = 2 0;
+   gpios = gpx2 2 0;
+   linux,code = KEY_HOME;
+   label = home key;
+   debounce-interval = 10;
+   gpio-key,wakeup;
+   };
+   };
+
regulator_p3v3 {
compatible = regulator-fixed;
regulator-name = p3v3_en;
@@ -62,3 +76,10 @@
status = okay;
};
 };
+
+pinctrl_1 {
+   gpio_home_key: home_key {
+   samsung,pins = gpx2-2;
+   samsung,pin-pud = 0;
+   };
+};
-- 
1.9.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 7/7] ARM: dts: exynos4210-universal_c210: enable hdmi support

[Marek Szyprowski]

From: Tomasz Stanislawski t.stanisl...@samsung.com

This patch adds configuration of hw modules required to enable HDMI
support on Universal C210 board.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 65 +
 1 file changed, 65 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d50eb3aa708e..585082397d5a 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -43,6 +43,14 @@
};
};
 
+   lcd0-power-domain@10023C80 {
+   domain-always-on;
+   };
+
+   tv-power-domain@10023C20 {
+   domain-always-on;
+   };
+
mct@1005 {
compatible = none;
};
@@ -487,6 +495,63 @@
status = okay;
};
};
+
+   hdmi_en: voltage-regulator-hdmi-5v {
+   compatible = regulator-fixed;
+   regulator-name = HDMI_5V;
+   regulator-min-microvolt = 500;
+   regulator-max-microvolt = 500;
+   gpio = gpe0 1 0;
+   enable-active-high;
+   };
+
+   hdmi_ddc: i2c-ddc {
+   compatible = i2c-gpio;
+   gpios = gpe4 2 0 gpe4 3 0;
+   i2c-gpio,delay-us = 100;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   pinctrl-0 = i2c_ddc_bus;
+   pinctrl-names = default;
+   status = okay;
+   };
+
+   mixer@12C1 {
+   status = okay;
+   };
+
+   hdmi@12D0 {
+   hpd-gpio = gpx3 7 0;
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_hpd;
+   hdmi-en-supply = hdmi_en;
+   vdd-supply = ldo3_reg;
+   vdd_osc-supply = ldo4_reg;
+   vdd_pll-supply = ldo3_reg;
+   ddc = hdmi_ddc;
+   status = okay;
+   };
+
+   i2c@138E {
+   status = okay;
+   };
+};
+
+pinctrl_1 {
+   hdmi_hpd: hdmi-hpd {
+   samsung,pins = gpx3-7;
+   samsung,pin-pud = 0;
+   };
+};
+
+pinctrl_0 {
+   i2c_ddc_bus: i2c-ddc-bus {
+   samsung,pins = gpe4-2, gpe4-3;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 3;
+   samsung,pin-drv = 0;
+   };
 };
 
 mdma1 {
-- 
1.9.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/7] drm: exynos: hdmi: make 'hdmi-en' regulator optional and keep it enabled

[Marek Szyprowski]

HDMI_EN regulator is additional regulator for providing voltage source
for DCC lines available on HDMI connector. When there is no power
provided for DDC epprom, some TV-sets do not pulls up HPD (hot plug
detect) line, what causes HDMI block to stay turned off. This patch
enables HDMI_EN regulator (if available) on driver probe and keep it
enabled all the time to let TV-set correctly signal HPD event.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index aa259b0a873a..a9a87d024c56 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -84,6 +84,7 @@ struct hdmi_resources {
struct clk  *sclk_hdmiphy;
struct clk  *mout_hdmi;
struct regulator_bulk_data  *regul_bulk;
+   struct regulator*reg_hdmi_en;
int regul_count;
 };
 
@@ -2168,7 +2169,6 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
struct device *dev = hdata-dev;
struct hdmi_resources *res = hdata-res;
static char *supply[] = {
-   hdmi-en,
vdd,
vdd_osc,
vdd_pll,
@@ -2228,6 +2228,20 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
}
res-regul_count = ARRAY_SIZE(supply);
 
+   res-reg_hdmi_en = devm_regulator_get(dev, hdmi-en);
+   if (IS_ERR(res-reg_hdmi_en)  PTR_ERR(res-reg_hdmi_en) != -ENOENT) {
+   DRM_ERROR(failed to get hdmi-en regulator\n);
+   return PTR_ERR(res-reg_hdmi_en);
+   }
+   if (!IS_ERR(res-reg_hdmi_en)) {
+   ret = regulator_enable(res-reg_hdmi_en);
+   if (ret) {
+   DRM_ERROR(failed to enable hdmi-en regulator\n);
+   return ret;
+   }
+   } else
+   res-reg_hdmi_en = NULL;
+
return ret;
 fail:
DRM_ERROR(HDMI resource init - failed\n);
@@ -2494,6 +2508,9 @@ static int hdmi_remove(struct platform_device *pdev)
 
cancel_delayed_work_sync(hdata-hotplug_work);
 
+   if (hdata-res.reg_hdmi_en)
+   regulator_disable(hdata-res.reg_hdmi_en);
+
put_device(hdata-hdmiphy_port-dev);
put_device(hdata-ddc_adpt-dev);
 
-- 
1.9.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 6/7] ARM: dts: exynos4412-odroid: enable hdmi support

[Marek Szyprowski]

This patch adds nodes specific to Exynos4412 based Odroid X/X2/U2/U3
boards required for enabling HDMI display.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 52 +
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index d1b33a8efa9d..2856242d640a 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -52,6 +52,14 @@
};
};
 
+   lcd0-power-domain@10023C80 {
+   domain-always-on;
+   };
+
+   tv-power-domain@10023C20 {
+   domain-always-on;
+   };
+
watchdog@1006 {
status = okay;
};
@@ -186,6 +194,20 @@
regulator-always-on;
};
 
+   ldo8_reg: ldo@8 {
+   regulator-compatible = LDO8;
+   regulator-name = VDD10_HDMI_1.0V;
+   regulator-min-microvolt = 100;
+   regulator-max-microvolt = 100;
+   };
+
+   ldo10_reg: ldo@10 {
+   regulator-compatible = LDO10;
+   regulator-name = VDDQ_MIPIHSI_1.8V;
+   regulator-min-microvolt = 180;
+   regulator-max-microvolt = 180;
+   };
+
ldo11_reg: LDO11 {
regulator-name = VDD18_ABB1_1.8V;
regulator-min-microvolt = 180;
@@ -332,6 +354,31 @@
ehci: ehci@1258 {
status = okay;
};
+
+   mixer: mixer@12C1 {
+   status = okay;
+   };
+
+   hdmi@12D0 {
+   hpd-gpio = gpx3 7 0;
+   pinctrl-names = default;
+   pinctrl-0 = hdmi_hpd;
+   vdd-supply = ldo8_reg;
+   vdd_osc-supply = ldo10_reg;
+   vdd_pll-supply = ldo8_reg;
+   ddc = hdmi_ddc;
+   status = okay;
+   };
+
+   hdmi_ddc: i2c@1388 {
+   status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = i2c2_bus;
+   };
+
+   i2c@138E {
+   status = okay;
+   };
 };
 
 pinctrl_1 {
@@ -339,4 +386,9 @@
samsung,pins = gpx1-3;
samsung,pin-pud = 0;
};
+
+   hdmi_hpd: hdmi-hpd {
+   samsung,pins = gpx3-7;
+   samsung,pin-pud = 1;
+   };
 };
-- 
1.9.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 5/7] ARM: dts: exynos4: add hdmi related nodes

[Marek Szyprowski]

This patch adds entries for HDMI, Mixer and i2c with hdmi-phy modules
found in Exynos 4210 and 4x12 SoCs.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
 arch/arm/boot/dts/exynos4.dtsi| 37 +
 arch/arm/boot/dts/exynos4210.dtsi |  5 +
 arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
 3 files changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 933bd2141601..5b55c4de7e6f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -38,6 +38,7 @@
i2c5 = i2c_5;
i2c6 = i2c_6;
i2c7 = i2c_7;
+   i2c8 = i2c_8;
csis0 = csis_0;
csis1 = csis_1;
fimc0 = fimc_0;
@@ -527,6 +528,22 @@
status = disabled;
};
 
+   i2c_8: i2c@138E {
+   #address-cells = 1;
+   #size-cells = 0;
+   compatible = samsung,s3c2440-hdmiphy-i2c;
+   reg = 0x138E 0x100;
+   interrupts = 0 93 0;
+   clocks = clock CLK_I2C_HDMI;
+   clock-names = i2c;
+   status = disabled;
+
+   hdmi_i2c_phy: hdmiphy@38 {
+   compatible = exynos4210-hdmiphy;
+   reg = 0x38;
+   };
+   };
+
spi_0: spi@1392 {
compatible = samsung,exynos4210-spi;
reg = 0x1392 0x100;
@@ -634,4 +651,24 @@
samsung,power-domain = pd_lcd0;
status = disabled;
};
+
+   hdmi: hdmi@12D0 {
+   compatible = samsung,exynos4210-hdmi;
+   reg = 0x12D0 0x7;
+   interrupts = 0 92 0;
+   clock-names = hdmi, sclk_hdmi, sclk_pixel, 
sclk_hdmiphy, mout_hdmi;
+   clocks = clock CLK_HDMI, clock CLK_SCLK_HDMI, clock 
CLK_SCLK_PIXEL, clock CLK_SCLK_HDMIPHY, clock CLK_MOUT_HDMI;
+   phy = hdmi_i2c_phy;
+   samsung,power-domain = pd_tv;
+   samsung,syscon-phandle = pmu_system_controller;
+   status = disabled;
+   };
+
+   mixer: mixer@12C1 {
+   compatible = samsung,exynos4210-mixer;
+   interrupts = 0 91 0;
+   reg = 0x12C1 0x2100, 0x12c0 0x300;
+   samsung,power-domain = pd_tv;
+   status = disabled;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f38821..d32063d00ad7 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -171,4 +171,9 @@
samsung,lcd-wb;
};
};
+
+   mixer: mixer@12C1 {
+   clock-names = mixer, sclk_hdmi, vp, mout_mixer, 
sclk_mixer;
+   clocks = clock CLK_MIXER, clock CLK_SCLK_HDMI, clock 
CLK_VP, clock CLK_MOUT_MIXER, clock CLK_SCLK_MIXER;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index c5a943df1cd7..856cd45b696b 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -270,4 +270,14 @@
compatible = samsung,exynos4x12-usb2-phy;
samsung,sysreg-phandle = sys_reg;
};
+
+   hdmi: hdmi@12D0 {
+   compatible = samsung,exynos4212-hdmi;
+   };
+
+   mixer: mixer@12C1 {
+   compatible = samsung,exynos4212-mixer;
+   clock-names = mixer, sclk_hdmi, vp;
+   clocks = clock CLK_MIXER, clock CLK_SCLK_HDMI, clock 
CLK_VP;
+   };
 };
-- 
1.9.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 0/7] Exynos4: enable HDMI support for Odroid and UniversalC210

[Marek Szyprowski]

Hello,

This is a long awaited patch series enabling support for HDMI output
available on Exynos4412-based Odroid boards (X/X2/U2/U3/U3+) and
Exynos4210 Universal C210 board.

This patch consists of 3 groups of patches, which are aimed to be merged
to respective maintainer kernel trees.

First patch (clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER
clocks) adds missing device tree support for hdmi related clocks. It is
prepared for clk kernel tree.

Next two patches (drm: exynos: hdmi: make 'hdmi-en' regulator optional
and keep it enabled and drm: hdmi/mixer: enable exynos 4210 and 4x12
soc support) add proper support for Exynos4 SoCs to Exynos DRM drivers.
Those patches should go to exynos-drm kernel tree.

Last patches (Exynos: add support for 'domain-always-on' property,
ARM: dts: exynos4: add hdmi related nodes, ARM: dts:
exynos4412-odroid: enable hdmi support and ARM: dts:
exynos4210-universal_c210: enable hdmi support) adds changes to all DTS
files and adds 'domain-always-on' property to Exynos power-domain
driver. This property is needed to resolve the non-trivial dependences
between TV and LCD0 power domains and the power on/off sequence of the
TV and mixer modules.

Patches are prepared on top of v3.16-rc3 with '[PATCH v2 0/4] Add
Exynos4412 based Odroid X2 and U2/U3/U3+ support' series and '[PATCH]
ARM: dts: exynos4412-odroid: add support for GPIO buttons' patch
applied:
http://www.spinics.net/lists/linux-samsung-soc/msg33115.html
http://www.spinics.net/lists/linux-samsung-soc/msg33497.html

Kernel tree with all Odroid related patches is available at
http://git.linaro.org/git-ro/people/marek.szyprowski/linux-srpol.git
on v3.16-odroid branch.

Best regards
Marek Szyprowski
Samsung RD Institute Poland

Marek Szyprowski (6):
  clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks
  drm: exynos: hdmi: make 'hdmi-en' regulator optional and keep it
enabled
  drm: hdmi/mixer: enable exynos 4210 and 4x12 soc support
  Exynos: add support for 'domain-always-on' property
  ARM: dts: exynos4: add hdmi related nodes
  ARM: dts: exynos4412-odroid: enable hdmi support

Tomasz Stanislawski (1):
  ARM: dts: exynos4210-universal_c210: enable hdmi support

 .../bindings/arm/exynos/power_domain.txt   |  2 +
 .../devicetree/bindings/video/exynos_mixer.txt |  5 +-
 arch/arm/boot/dts/exynos4.dtsi | 37 
 arch/arm/boot/dts/exynos4210-universal_c210.dts| 65 ++
 arch/arm/boot/dts/exynos4210.dtsi  |  5 ++
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 52 +
 arch/arm/boot/dts/exynos4x12.dtsi  | 10 
 arch/arm/mach-exynos/pm_domains.c  |  6 +-
 drivers/clk/samsung/clk-exynos4.c  |  4 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   | 29 +-
 drivers/gpu/drm/exynos/exynos_mixer.c  | 51 -
 include/dt-bindings/clock/exynos4.h|  2 +
 12 files changed, 247 insertions(+), 21 deletions(-)

-- 
1.9.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 1/7] clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks

[Marek Szyprowski]

This patch adds support for exporting mout_hdmi and mout_mixer to device
tree. Access to those clocks is required to correctly setup HDMI module
on Exynos 4210 and 4x12 SoCs.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Mike Turquette mturque...@linaro.org
CC: Tomasz Figa t.f...@samsung.com
---
 drivers/clk/samsung/clk-exynos4.c   | 4 ++--
 include/dt-bindings/clock/exynos4.h | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index 4f150c9dd38c..a30a779869eb 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -440,7 +440,7 @@ static struct samsung_fixed_rate_clock 
exynos4210_fixed_rate_clks[] __initdata =
 static struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
MUX_FA(CLK_MOUT_APLL, mout_apll, mout_apll_p, SRC_CPU, 0, 1,
CLK_SET_RATE_PARENT, 0, mout_apll),
-   MUX(0, mout_hdmi, mout_hdmi_p, SRC_TV, 0, 1),
+   MUX(CLK_MOUT_HDMI, mout_hdmi, mout_hdmi_p, SRC_TV, 0, 1),
MUX(0, mout_mfc1, sclk_evpll_p, SRC_MFC, 4, 1),
MUX(0, mout_mfc, mout_mfc_p, SRC_MFC, 8, 1),
MUX_F(CLK_MOUT_G3D1, mout_g3d1, sclk_evpll_p, SRC_G3D, 4, 1,
@@ -463,7 +463,7 @@ static struct samsung_mux_clock exynos4210_mux_clks[] 
__initdata = {
MUX(0, mout_aclk100, sclk_ampll_p4210, SRC_TOP0, 16, 1),
MUX(0, mout_aclk160, sclk_ampll_p4210, SRC_TOP0, 20, 1),
MUX(0, mout_aclk133, sclk_ampll_p4210, SRC_TOP0, 24, 1),
-   MUX(0, mout_mixer, mout_mixer_p4210, SRC_TV, 4, 1),
+   MUX(CLK_MOUT_MIXER, mout_mixer, mout_mixer_p4210, SRC_TV, 4, 1),
MUX(0, mout_dac, mout_dac_p4210, SRC_TV, 8, 1),
MUX(0, mout_g2d0, sclk_ampll_p4210, E4210_SRC_IMAGE, 0, 1),
MUX(0, mout_g2d1, sclk_evpll_p, E4210_SRC_IMAGE, 4, 1),
diff --git a/include/dt-bindings/clock/exynos4.h 
b/include/dt-bindings/clock/exynos4.h
index 1106ca540a96..5bfb3509ee3c 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -229,6 +229,8 @@
 #define CLK_MOUT_G3D1  393
 #define CLK_MOUT_G3D   394
 #define CLK_ACLK400_MCUISP 395 /* Exynos4x12 only */
+#define CLK_MOUT_HDMI  396
+#define CLK_MOUT_MIXER 397
 
 /* div clocks */
 #define CLK_DIV_ISP0   450 /* Exynos4x12 only */
-- 
1.9.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: [PATCHv2 0/5] ARM: remove the sub-node and deprecated supports-highspeed property for dwmmc.

[Sachin Kamat]

Hi Jaehoon,

On Mon, Jun 30, 2014 at 5:19 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Since used the mmc_of_parse(), didn't parse the sub-node.
 So we can remove the sub-node, because almost SoC used the only one card per 
 a host.
 And supports-highspeed can be replaced to cap-mmc/sd-highspeed property.

 Jaehoon Chung (5):
   mmc: dw_mmc: modify the dt-binding for removing slot-node and
 supports-highspeed
   ARM: dts: exynos: unuse the slot-node and deprecated the
 supports-highspeed for dw-mmc
   ARM: dts: socfpga: unuse the slot-node and deprecated the
 supports-highspeed for dw-mmc
   ARM: dts: rockchip: unuse the slot-node and deprecated the
 supports-highspeed for dw-mmc
   mmc: dw_mmc: replace disable-wp from slot's quirk to host's quirk

It is a good practice to include revision history for subsequent versions.

Tested on Exynos 5250 based Snow and Arndale boards. Works fine now.

Tested-by: Sachin Kamat sachin.ka...@samsung.com

-- 
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

Re: [PATCH] drm/exynos: Fix NULL pointer exception when suspending without components

[Inki Dae]

On 2014년 06월 30일 22:25, Krzysztof Kozlowski wrote:
 Fix a NULL pointer exception when main exynos drm driver was probed
 successfully but no components were added (e.g. by incomplete DTS). In
 such case the exynos_drm_load() is never called and drvdata is NULL.
 

Right, it's good report. Applied.

Thanks,
Inki Dae


 The NULL pointer exception may theoretically also happen as a effect of race 
 between
 adding components and main driver: if suspend of the driver happens
 before adding components.
 
 Trace:
 [1.190295] [drm] Initialized drm 1.1.0 20060810
 [1.195209] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
 (...)
 [   24.001743] PM: Syncing filesystems ... done.
 [   24.002177] Freezing user space processes ... (elapsed 0.000 seconds) done.
 [   24.007403] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
 done.
 [   24.032559] Unable to handle kernel NULL pointer dereference at virtual 
 address 0134
 [   24.035007] pgd = dedd8000
 [   24.037734] [0134] *pgd=5ee13831, *pte=, *ppte=
 [   24.043953] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
 [   24.049329] Modules linked in:
 [   24.052371] CPU: 0 PID: 1 Comm: sh Not tainted 
 3.16.0-rc3-00035-geba20bbdde04-dirty #51
 [   24.060354] task: df478000 ti: df48 task.ti: df48
 [   24.065743] PC is at mutex_lock+0x10/0x50
 [   24.069733] LR is at drm_modeset_lock_all+0x30/0xbc
 [   24.074590] pc : [c048516c]lr : [c02a14b4]psr: a013
 [   24.074590] sp : df481db8  ip :   fp : c05e524c
 [   24.086045] r10: 0002  r9 : c02c1fe4  r8 : deca5e44
 [   24.091253] r7 :   r6 :   r5 : 014c  r4 : 0134
 [   24.097763] r3 :   r2 :   r1 :   r0 : 0134
 [   24.104275] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
 user
 [   24.111391] Control: 10c53c7d  Table: 5edd806a  DAC: 0015
 [   24.117120] Process sh (pid: 1, stack limit = 0xdf480240)
 [   24.122502] Stack: (0xdf481db8 to 0xdf482000)
 [   24.126843] 1da0:   
 dee01d80 c02a14b4
 [   24.135004] 1dc0:   c07aff98 c02aec7c 0002  
  c07aff98
 [   24.143164] 1de0: deca5e10 c02aecf4 c02aecd4 c02c2010  c02c9470 
  
 [   24.151322] 1e00:   deca5e10 deca5e10  c07aff98 
 0002 deca5e44
 [   24.159482] 1e20: c06d8f78 c06fb800 deca5e78 c02ca660 df7baf00 007b0aa0 
 deca5e10 c06fb7c8
 [   24.167641] 1e40: c07aff98  0002 c02cbe18 9757aec5 0005 
 9757aec5 0005
 [   24.175801] 1e60: ded1d380 0003 0003 c05c74d8 ded1d380 c07209d4 
 c05c7514 c07105d8
 [   24.183960] 1e80: 01e2a738 c0068a74  c05c7514 ded1d380 c071c6e0 
 0004 c07105d8
 [   24.192119] 1ea0: 01e2a738 c047f1e0 c0600cc0 df481ec4 0003  
 0003 c05c74d8
 [   24.200278] 1ec0: ded1d380 c071c6e0 c05c7514 c07105d8 01e2a738 c0069444 
 c06d905c 0003
 [   24.208438] 1ee0: 0003 ded1d380 c06d9064 0004 c05c3fc0 c0067d4c 
 df535ab0 ded1d380
 [   24.216596] 1f00: df481f80 ded1d380 0004 ded1d1cc ded1d1c0 c0221724 
 0004 c016ca6c
 [   24.224756] 1f20: c016ca28   c016c1d4   
 b6f37000 df481f80
 [   24.232915] 1f40: decedd80 0004 df48 df48 b6f37000 c0110920 
 df47839c 6013
 [   24.241074] 1f60:   decedd80 decedd80 0004 df48 
 b6f37000 c0110da8
 [   24.249233] 1f80:   0004 b6edf5d8 0004 b6f37000 
 0004 c000f2a8
 [   24.257393] 1fa0: 1000 c000f0e0 b6edf5d8 0004 0001 b6f37000 
 0004 
 [   24.265551] 1fc0: b6edf5d8 0004 b6f37000 0004 0004 0001 
  01e2a738
 [   24.273711] 1fe0:  beba0a20 b6e1f4f0 b6e7022c 6010 0001 
  
 [   24.281885] [c048516c] (mutex_lock) from [c02a14b4] 
 (drm_modeset_lock_all+0x30/0xbc)
 [   24.289950] [c02a14b4] (drm_modeset_lock_all) from [c02aec7c] 
 (exynos_drm_suspend+0xc/0x64)
 [   24.298627] [c02aec7c] (exynos_drm_suspend) from [c02aecf4] 
 (exynos_drm_sys_suspend+0x20/0x34)
 [   24.307568] [c02aecf4] (exynos_drm_sys_suspend) from [c02c2010] 
 (platform_pm_suspend+0x2c/0x54)
 [   24.316597] [c02c2010] (platform_pm_suspend) from [c02c9470] 
 (dpm_run_callback+0x48/0x170)
 [   24.325188] [c02c9470] (dpm_run_callback) from [c02ca660] 
 (__device_suspend+0x128/0x39c)
 [   24.333606] [c02ca660] (__device_suspend) from [c02cbe18] 
 (dpm_suspend+0x5c/0x314)
 [   24.341506] [c02cbe18] (dpm_suspend) from [c0068a74] 
 (suspend_devices_and_enter+0x8c/0x598)
 [   24.350185] [c0068a74] (suspend_devices_and_enter) from [c0069444] 
 (pm_suspend+0x4c4/0x5d0)
 [   24.358862] [c0069444] (pm_suspend) from [c0067d4c] 
 (state_store+0x70/0xd4)
 [   24.366156] [c0067d4c] (state_store) from [c0221724] 
 (kobj_attr_store+0x14/0x20)
 [   24.373885] [c0221724] (kobj_attr_store) from [c016ca6c] 
 (sysfs_kf_write+0x44/0x48)
 [   24.381867] 

Re: [PATCH 1/7] clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks

[Tobias Jakobi]

Hello Marek,

I think this particular clock setup should already be handled by this patch:
http://www.spinics.net/lists/arm-kernel/msg320013.html

Or am I missing something here?

With best wishes,
Tobias


Marek Szyprowski wrote:
 This patch adds support for exporting mout_hdmi and mout_mixer to device
 tree. Access to those clocks is required to correctly setup HDMI module
 on Exynos 4210 and 4x12 SoCs.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 CC: Mike Turquette mturque...@linaro.org
 CC: Tomasz Figa t.f...@samsung.com
 ---
  drivers/clk/samsung/clk-exynos4.c   | 4 ++--
  include/dt-bindings/clock/exynos4.h | 2 ++
  2 files changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/clk/samsung/clk-exynos4.c 
 b/drivers/clk/samsung/clk-exynos4.c
 index 4f150c9dd38c..a30a779869eb 100644
 --- a/drivers/clk/samsung/clk-exynos4.c
 +++ b/drivers/clk/samsung/clk-exynos4.c
 @@ -440,7 +440,7 @@ static struct samsung_fixed_rate_clock 
 exynos4210_fixed_rate_clks[] __initdata =
  static struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
   MUX_FA(CLK_MOUT_APLL, mout_apll, mout_apll_p, SRC_CPU, 0, 1,
   CLK_SET_RATE_PARENT, 0, mout_apll),
 - MUX(0, mout_hdmi, mout_hdmi_p, SRC_TV, 0, 1),
 + MUX(CLK_MOUT_HDMI, mout_hdmi, mout_hdmi_p, SRC_TV, 0, 1),
   MUX(0, mout_mfc1, sclk_evpll_p, SRC_MFC, 4, 1),
   MUX(0, mout_mfc, mout_mfc_p, SRC_MFC, 8, 1),
   MUX_F(CLK_MOUT_G3D1, mout_g3d1, sclk_evpll_p, SRC_G3D, 4, 1,
 @@ -463,7 +463,7 @@ static struct samsung_mux_clock exynos4210_mux_clks[] 
 __initdata = {
   MUX(0, mout_aclk100, sclk_ampll_p4210, SRC_TOP0, 16, 1),
   MUX(0, mout_aclk160, sclk_ampll_p4210, SRC_TOP0, 20, 1),
   MUX(0, mout_aclk133, sclk_ampll_p4210, SRC_TOP0, 24, 1),
 - MUX(0, mout_mixer, mout_mixer_p4210, SRC_TV, 4, 1),
 + MUX(CLK_MOUT_MIXER, mout_mixer, mout_mixer_p4210, SRC_TV, 4, 1),
   MUX(0, mout_dac, mout_dac_p4210, SRC_TV, 8, 1),
   MUX(0, mout_g2d0, sclk_ampll_p4210, E4210_SRC_IMAGE, 0, 1),
   MUX(0, mout_g2d1, sclk_evpll_p, E4210_SRC_IMAGE, 4, 1),
 diff --git a/include/dt-bindings/clock/exynos4.h 
 b/include/dt-bindings/clock/exynos4.h
 index 1106ca540a96..5bfb3509ee3c 100644
 --- a/include/dt-bindings/clock/exynos4.h
 +++ b/include/dt-bindings/clock/exynos4.h
 @@ -229,6 +229,8 @@
  #define CLK_MOUT_G3D1393
  #define CLK_MOUT_G3D 394
  #define CLK_ACLK400_MCUISP   395 /* Exynos4x12 only */
 +#define CLK_MOUT_HDMI396
 +#define CLK_MOUT_MIXER   397
  
  /* div clocks */
  #define CLK_DIV_ISP0 450 /* Exynos4x12 only */
 

--
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 4/7] Exynos: add support for 'domain-always-on' property

[Tobias Jakobi]

Hello Marek,

I think you had a similar patch in the tizen tree, but according to
Tomasz Figa, it was considered a hack. I don't quite see how this is
different.

Also, if I have been following the discussion correctly, then the
powerdomain issue essentially is about the question which SoC block
needs the LCD0 domain and how the proper power on/off sequences should
look like.

At least the mixer power issue, which I pointed out some time ago, seems
to be deal with now:
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-nextid=381be025ac1a6dc8efebdf146ced0d4a6007f77b

With best wishes,
Tobias




Marek Szyprowski wrote:
 This patch adds support for domain-always-on property to Exynos power
 domain driver. Domains with this property as always kept enabled.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 ---
  Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 2 ++
  arch/arm/mach-exynos/pm_domains.c | 6 +-
  2 files changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
 b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 index 5216b419016a..b25d9b1ce471 100644
 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
 @@ -8,6 +8,8 @@ Required Properties:
  * samsung,exynos4210-pd - for exynos4210 type power domain.
  - reg: physical base address of the controller and length of memory mapped
  region.
 +Optional properties:
 +- domain-always-on:  keeps the domain always enabled
  
  Node of a device using power domains must have a samsung,power-domain 
 property
  defined with a phandle to respective power domain.
 diff --git a/arch/arm/mach-exynos/pm_domains.c 
 b/arch/arm/mach-exynos/pm_domains.c
 index fe6570ebbdde..279b008de02f 100644
 --- a/arch/arm/mach-exynos/pm_domains.c
 +++ b/arch/arm/mach-exynos/pm_domains.c
 @@ -151,6 +151,7 @@ static __init int exynos4_pm_init_power_domain(void)
   struct device_node *np;
  
   for_each_compatible_node(np, NULL, samsung,exynos4210-pd) {
 + struct dev_power_governor *gov = NULL;
   struct exynos_pm_domain *pd;
   int on;
  
 @@ -163,6 +164,9 @@ static __init int exynos4_pm_init_power_domain(void)
   return -ENOMEM;
   }
  
 + if (of_property_read_bool(np, domain-always-on))
 + gov = pm_domain_always_on_gov;
 +
   pd-pd.name = kstrdup(np-name, GFP_KERNEL);
   pd-name = pd-pd.name;
   pd-base = of_iomap(np, 0);
 @@ -174,7 +178,7 @@ static __init int exynos4_pm_init_power_domain(void)
  
   on = __raw_readl(pd-base + 0x4)  S5P_INT_LOCAL_PWR_EN;
  
 - pm_genpd_init(pd-pd, NULL, !on);
 + pm_genpd_init(pd-pd, gov, !on);
   }
  
   bus_register_notifier(platform_bus_type, platform_nb);
 

--
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/7] clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks

[Marek Szyprowski]

Hello,

On 2014-07-01 10:46, Tobias Jakobi wrote:

Hello Marek,

I think this particular clock setup should already be handled by this patch:
http://www.spinics.net/lists/arm-kernel/msg320013.html

Or am I missing something here?


The patch you have pointed requires adding support for SET_PARENT_PARENT
feature to clock core, which has not been accepted yet. Only then Exynod
DRM drivers can be updated to correctly handle the changed clock tree.

My approach is to introduce minimal changes and use the code which is
already in the exynos drm/hdmi driver (it already manages 'mout_hdmi/mixer'
clocks). If other solution is finally accepted, the code can be simplified
and mout_hdmi/mixer clocks simply ignored. For now - my changes are needed
to get HDMI output working and have least dependencies.

Best regards
--
Marek Szyprowski, PhD
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 4/7] Exynos: add support for 'domain-always-on' property

[Marek Szyprowski]

Hello,

On 2014-07-01 10:52, Tobias Jakobi wrote:

Hello Marek,

I think you had a similar patch in the tizen tree, but according to
Tomasz Figa, it was considered a hack. I don't quite see how this is
different.

Also, if I have been following the discussion correctly, then the
powerdomain issue essentially is about the question which SoC block
needs the LCD0 domain and how the proper power on/off sequences should
look like.

At least the mixer power issue, which I pointed out some time ago, seems
to be deal with now:
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-nextid=381be025ac1a6dc8efebdf146ced0d4a6007f77b


Well, that patch solves power on/off sequence issue with mixer and hdmi,
but it didn't solve the issue with additional managing of power domain
on/off. You can check that if you remove always on property, system will
freeze when hdmi cable is connected for the second time. I've investigated
it for some time, but right now I didn't find any 100% reliable solution
other than keeping the power domain enabled all the time. At least for
now, this patch lets you use HDMI without any stability issues.

I've only found that there are still at least 2 issues with power domains.
One is Mixer/Video Processor dependency on LCD0 domain, second is the proper
power on/off sequence of HDMI/Mixer and TV domain. Forcing both domains to
'always on' workarounds both issues for now. Right now I have no better
idea.

Later, once the proper sequence is found we can remove those properties
from Odroid DTS.

Best regards
--
Marek Szyprowski, PhD
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] phy: phy-samsung-usb2: Change phy power on/power off sequence

[Kishon Vijay Abraham I]

Hi Kamil,

On Tuesday 24 June 2014 06:24 PM, Kamil Debski wrote:
 The Exynos4412 USB 2.0 PHY hardware differs from the description provided
 in the documentation. Some register bits have different function. This
 patch fixes the defines of register bits and changes the way how phys are
 powered on and off.
 
 Signed-off-by: Kamil Debski k.deb...@samsung.com

Can you fix these checkpatch warnings?

WARNING: space prohibited before semicolon
#149: FILE: drivers/phy/phy-exynos4x12-usb2.c:227:
+   EXYNOS_4x12_URSTCON_HOST_LINK_P1 ;

WARNING: line over 80 characters
#200: FILE: drivers/phy/phy-exynos4x12-usb2.c:278:
+   
exynos4x12_power_on_internal(drv-instances[EXYNOS4x12_DEVICE]);

WARNING: line over 80 characters
#210: FILE: drivers/phy/phy-exynos4x12-usb2.c:288:
+   
exynos4x12_power_on_internal(drv-instances[EXYNOS4x12_DEVICE]);

WARNING: line over 80 characters
#220: FILE: drivers/phy/phy-exynos4x12-usb2.c:297:
+static void exynos4x12_power_off_internal(struct samsung_usb2_phy_instance 
*inst)

WARNING: line over 80 characters
#249: FILE: drivers/phy/phy-exynos4x12-usb2.c:319:
+   
exynos4x12_power_off_internal(drv-instances[EXYNOS4x12_DEVICE]);

WARNING: line over 80 characters
#253: FILE: drivers/phy/phy-exynos4x12-usb2.c:323:
+   
exynos4x12_power_off_internal(drv-instances[EXYNOS4x12_DEVICE]);

total: 0 errors, 6 warnings, 182 lines checked

Thanks
Kishon
--
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] ARM: dts: disable MDMA1 node for exynos5420

[Tushar Behera]

From: Seungwon Jeon tgih@samsung.com

commit e6015c1f8a9032c2aecb78d23edf49582563bd47 upstream.

This change places MDMA1 in disabled node for Exynos5420.
If MDMA1 region is configured with secure mode, it makes
the boot failure with the following on smdk5420 board.
(Unhandled fault: imprecise external abort (0x1406) at 0x)
Thus, arndale-octa board don't need to do the same thing anymore.

Signed-off-by: Seungwon Jeon tgih@samsung.com
Tested-by: Javi Merino javi.mer...@arm.com
Signed-off-by: Kukjin Kim kgene@samsung.com
Signed-off-by: Tushar Behera tusha...@samsung.com
---

Tested on top of v3.14.10.
Fixes issue reported at [1].
[1]
http://armcloud.us/kernel-ci/stable/v3.14.10/arm-exynos_defconfig/boot-exynos5420-arndale-octa.html

 arch/arm/boot/dts/exynos5420.dtsi |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8db792b..15eb8d4 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -323,6 +323,13 @@
#dma-cells = 1;
#dma-channels = 8;
#dma-requests = 1;
+   /*
+* MDMA1 can support both secure and non-secure
+* AXI transactions. When this is enabled in the kernel
+* for boards that run in secure mode, we are getting
+* imprecise external aborts causing the kernel to oops.
+*/
+   status = disabled;
};
};
 
-- 
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 2/2] arm: Add back maximum bank limit

[Grant Likely]

On Mon, Jun 30, 2014 at 7:03 PM, Laura Abbott lau...@codeaurora.org wrote:
 On 6/30/2014 3:43 AM, Grant Likely wrote:

 Instead of splitting early_init_dt_scan(), the call to
 early_init_dt_scan() could probably be moved after the
 of_flat_dt_match_machine() call. It's at least worth a try. Looking at
 the code I don't see anything obvious that requires the
 early_init_dt_scan() code to run first.


 of_flat_dt_match_machine - of_flat_dt_match which uses
 initial_boot_params which isn't set until early_init_dt_scan. I had the
 same thought about just rearranging but we still need something to be
 set before doing the scan, hence the split.

Fair enough.

 Once you've got the mdesc pointer, you've could set the limit before
 doing the full scan. Or, better yet because this is a fix for broken
 data, you could call a dt_fixup hook on the mdesc. Then exynos is the
 only platform that needs special treatment. The best thing for exynos to
 do is fix the buggy data by clearing the bogus entries. Then there's no
 need to reintroduce early_init_dt_add_memory_arch() for ARM.


 The fixup hook does sound better. The flow would become

 setup_machine_fdt
 - early_init_dt_verify
 - of_flat_dt_match_machine
 - mdesc-dt_fixup
 - early_init_dt_scan_all

 I notice that powerpc already has a DT fixup infrastructure but I don't see
 any such thing for ARM. How much of that do you think could and should be
 leveraged for ARM?

Not much. The PowerPC fixup infrastructure is based on having an
OpenFirmware implementation and the fixups are performed by executing
Forth commands in OFW before flattening the tree and killing OFW
context. For ARM, any DT fixup hooks should directly use libfdt calls.

g.
--
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 08/17] ARM: S5PC100: no more support S5PC100 SoC

[Arnd Bergmann]

On Tuesday 01 July 2014 19:21:16 Kukjin Kim wrote:
 --- a/arch/arm/plat-samsung/Kconfig
 +++ b/arch/arm/plat-samsung/Kconfig
 @@ -15,7 +15,7 @@ config PLAT_SAMSUNG
  
  config PLAT_S5P
 bool
 -   depends on (ARCH_S5PC100 || ARCH_S5PV210)
 +   depends on ARCH_S5PV210
 default y
 select ARCH_REQUIRE_GPIOLIB
 select ARM_VIC
 @@ -78,14 +78,14 @@ config SAMSUNG_CLKSRC
   used by newer systems such as the S3C64XX.
  
  config S5P_CLOCK
 -   def_bool (ARCH_S5PC100 || ARCH_S5PV210)
 +   def_bool ARCH_S5PV210
 help
   Support common clock part for ARCH_S5P and ARCH_EXYNOS SoCs
  
  # options for IRQ support
  
  config S5P_IRQ
 -   def_bool (ARCH_S5PC100 || ARCH_S5PV210)
 +   def_bool ARCH_S5PV210
 help
   Support common interrupt part for ARCH_S5P SoCs
  
 @@ -142,7 +142,7 @@ config S3C_GPIO_TRACK
  
  config S5P_DEV_UART
 def_bool y
 -   depends on (ARCH_S5PC100 || ARCH_S5PV210)
 +   depends on ARCH_S5PV210
  
  # ADC driver
  

I guess the next logical step would be to either remove these entirely
after the move to DT-only ARCH_S5PV210 obsoletes them, or to move the
code back to mach-s5pv210, right?

 
  config SAMSUNG_DMADEV
bool Use legacy Samsung DMA abstraction
 -   depends on CPU_S5PV210 || CPU_S5PC100 || ARCH_S3C64XX
 +   depends on CPU_S5PV210 || ARCH_S3C64XX
 select DMADEVICES
 default y
help

It would be good to just kill this one off now, as nothing uses it
any more, but that's also a separate patch.

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 v7 0/6] add cpuidle support for Exynos5420

[Kukjin Kim]

Chander Kashyap wrote:
 
 Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores.
 
 This patchset adds cpuidle support for Exynos5420 SoC based on
 generic big.little cpuidle driver.
 
 Tested on SMDK5420.
 Rebased on 3.16-rc1
 
 Changelog is in respective patches.
 Chander Kashyap (5):
   driver: cpuidle-big-little: add of_device_id structure
   arm: exynos: add generic function to calculate cpu number
   cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little
 driver
   driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
   exynos: cpuidle: do not allow cpuidle registration for Exynos5420
   mcpm: exynos: populate suspend and powered_up callbacks
 
  arch/arm/mach-exynos/exynos.c|4 +++-
  arch/arm/mach-exynos/mcpm-exynos.c   |   36 
 ++
  arch/arm/mach-exynos/regs-pmu.h  |9 +
  drivers/cpuidle/Kconfig.arm  |2 +-
  drivers/cpuidle/cpuidle-big_little.c |   12 +++-
  5 files changed, 60 insertions(+), 3 deletions(-)
 

+ Nicolas

Hi,

This series looks good to me and I asked Chander to test this series with
Nico's mcpm patches on smdk5420 and he said it works fine. So I will apply
this into samsung tree if Nicolas has no objection on 6/6.

BTW, one more, there are duplicated sign-off from Chander with different
e-mail address, I'm not sure it should be fine or not because I didn't see
same thing before.

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 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/27/2014 08:18 PM, Kevin Hilman wrote:
 On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman khil...@linaro.org wrote:
 On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera trbli...@gmail.com wrote:

 Would you please provide me the environment setting of your u-boot?
 U-boot environment on my board has been over-written, I would like to
 set it same as yours and try to reproduce the issue at my end. With only
 'sound init', I don't seem to hit this issue anymore.

 Attached is a full boot log using v3.16-rc2 with my patch adding
 CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
 boot log, you'll see the output of 'printenv' inside u-boot where the
 environment is dumped.
 
 Oops, I sent you a boot log for the octa board.  Here's the one for
 peach-pi with the same kernel (built with upstream exynos_defconfig)
 
 Kevin
 

The u-boot version is a little different on my Peach-Pi as compared to
the market release version. Not sure if that is making any difference.

Peach # version

U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
4.8.x-google 20130905 (prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22

-- 
Tushar Behera
--
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 08/17] ARM: S5PC100: no more support S5PC100 SoC

[Kukjin Kim]

Arnd Bergmann wrote:
 
 On Tuesday 01 July 2014 19:21:16 Kukjin Kim wrote:
  --- a/arch/arm/plat-samsung/Kconfig
  +++ b/arch/arm/plat-samsung/Kconfig
  @@ -15,7 +15,7 @@ config PLAT_SAMSUNG
 
   config PLAT_S5P
  bool
  -   depends on (ARCH_S5PC100 || ARCH_S5PV210)
  +   depends on ARCH_S5PV210
  default y
  select ARCH_REQUIRE_GPIOLIB
  select ARM_VIC
  @@ -78,14 +78,14 @@ config SAMSUNG_CLKSRC
used by newer systems such as the S3C64XX.
 
   config S5P_CLOCK
  -   def_bool (ARCH_S5PC100 || ARCH_S5PV210)
  +   def_bool ARCH_S5PV210
  help
Support common clock part for ARCH_S5P and ARCH_EXYNOS SoCs
 
   # options for IRQ support
 
   config S5P_IRQ
  -   def_bool (ARCH_S5PC100 || ARCH_S5PV210)
  +   def_bool ARCH_S5PV210
  help
Support common interrupt part for ARCH_S5P SoCs
 
  @@ -142,7 +142,7 @@ config S3C_GPIO_TRACK
 
   config S5P_DEV_UART
  def_bool y
  -   depends on (ARCH_S5PC100 || ARCH_S5PV210)
  +   depends on ARCH_S5PV210
 
   # ADC driver
 
 
 I guess the next logical step would be to either remove these entirely
 after the move to DT-only ARCH_S5PV210 obsoletes them, or to move the
 code back to mach-s5pv210, right?
 
Yeah both are possible, but the latter would be more possible at this moment,
I think. I will cleanup stuff in plat-samsung as you suggested :-)

 
   config SAMSUNG_DMADEV
 bool Use legacy Samsung DMA abstraction
  -   depends on CPU_S5PV210 || CPU_S5PC100 || ARCH_S3C64XX
  +   depends on CPU_S5PV210 || ARCH_S3C64XX
  select DMADEVICES
  default y
 help
 
 It would be good to just kill this one off now, as nothing uses it
 any more, but that's also a separate patch.
 
Maybe it is still used for s5pv210 and s3c64xx? If I misunderstand your
comments, please kindly let me know.

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: mwifiex card reset

[Yuvaraj Cd]

On Tue, Jul 1, 2014 at 12:27 PM, James Cameron qu...@laptop.org wrote:
 On Mon, Jun 30, 2014 at 11:44:29PM -0700, Bing Zhao wrote:
 I may have missed something, but doesn't the MMC_POWER_OFF and
 MMC_POWER_ON|UP handling in controller driver help?
 Anyway the clocks/GPIOs/regulators are sort of platform
 dependent. Would it be better putting it in /arch/arm/mach-x/?

 Wouldn't device tree for mmc be better?
I have come across same problem.Below is the thread in which more
discussions happened on this.
 http://patchwork.ozlabs.org/patch/312444/
I am adding few more those who are interested in this solution.

 --
 James Cameron
 http://quozl.linux.org.au/
 --
 To unsubscribe from this list: send the line unsubscribe linux-mmc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 08/17] ARM: S5PC100: no more support S5PC100 SoC

[Arnd Bergmann]

On Tuesday 01 July 2014 21:18:07 Kukjin Kim wrote:
  
config SAMSUNG_DMADEV
  bool Use legacy Samsung DMA abstraction
   -   depends on CPU_S5PV210 || CPU_S5PC100 || ARCH_S3C64XX
   +   depends on CPU_S5PV210 || ARCH_S3C64XX
   select DMADEVICES
   default y
  help
  
  It would be good to just kill this one off now, as nothing uses it
  any more, but that's also a separate patch.
  
 Maybe it is still used for s5pv210 and s3c64xx? If I misunderstand your
 comments, please kindly let me know.

samsung-dmadev used to be used in a number of device drivers, but I believe
they have all been converted to using dmaengine interfaces now.

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 08/17] ARM: S5PC100: no more support S5PC100 SoC

[Jason Cooper]

Kukjin,

On Tue, Jul 01, 2014 at 07:21:16PM +0900, Kukjin Kim wrote:
 This patch removes supporting codes for s5pc100 because no more used
 now.
 
 Signed-off-by: Kukjin Kim kgene@samsung.com
 Cc: Russell King rmk+ker...@arm.linux.org.uk
 ---
...
  drivers/irqchip/Kconfig|1 -

Acked-by: Jason Cooper ja...@lakedaemon.net

thx,

Jason.
--
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] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420

[Abhilash Kesavan]

Hi Nicolas,

On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
 On Mon, 30 Jun 2014, Abhilash Kesavan wrote:

 Use the MCPM layer to handle core suspend/resume on Exynos5420.
 Also, restore the entry address setup code post-resume.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 ---
 [...]

 Could you tell me more about this?

 @@ -150,7 +153,13 @@ static void exynos_power_down(void)
   BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
   cpu_use_count[cpu][cluster]--;
   if (cpu_use_count[cpu][cluster] == 0) {
 - exynos_cpu_power_down(cpunr);
 + /*
 +  * Bypass power down for CPU0 during suspend. This is being
 +  * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
 +  */
 + if ((cpunr != 0) ||
 + (__raw_readl(pmu_base_addr + S5P_INFORM1) != S5P_CHECK_SLEEP))
 + exynos_cpu_power_down(cpunr);

 What happens if CPU0 is the first in the cluster to be idled?  Will it
 remain powered up until all the others have gone idle too?
This check is only for handling the S2R CPU0 case. In case of
idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
there would be no change in behavior for them.
During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
PMU when the CPU0 is ready to be suspended. This in conjunction with
the sleep state core configuration (setting SYS_PWR_REG low) causes
the CPU0 to go down. We should not write to the CPU0 power
configuration register (exynos_cpu_power_down) along with this during
suspend.

Regards,
Abhilash


 Nicolas
--
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] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420

[Lorenzo Pieralisi]

On Tue, Jul 01, 2014 at 02:14:49PM +0100, Abhilash Kesavan wrote:
 Hi Nicolas,
 
 On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre nicolas.pi...@linaro.org 
 wrote:
  On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
 
  Use the MCPM layer to handle core suspend/resume on Exynos5420.
  Also, restore the entry address setup code post-resume.
 
  Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
  ---
  [...]
 
  Could you tell me more about this?
 
  @@ -150,7 +153,13 @@ static void exynos_power_down(void)
BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
cpu_use_count[cpu][cluster]--;
if (cpu_use_count[cpu][cluster] == 0) {
  - exynos_cpu_power_down(cpunr);
  + /*
  +  * Bypass power down for CPU0 during suspend. This is being
  +  * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
  +  */
  + if ((cpunr != 0) ||
  + (__raw_readl(pmu_base_addr + S5P_INFORM1) != 
  S5P_CHECK_SLEEP))
  + exynos_cpu_power_down(cpunr);
 
  What happens if CPU0 is the first in the cluster to be idled?  Will it
  remain powered up until all the others have gone idle too?
 This check is only for handling the S2R CPU0 case. In case of
 idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
 there would be no change in behavior for them.
 During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
 PMU when the CPU0 is ready to be suspended. This in conjunction with
 the sleep state core configuration (setting SYS_PWR_REG low) causes
 the CPU0 to go down. We should not write to the CPU0 power
 configuration register (exynos_cpu_power_down) along with this during
 suspend.

I think this should be part of a refactoring that includes the exynos MCPM
suspend call parameters. In particular, at the moment there is no code in
the back-end to detect if the last man should request core gating or cluster
gating (ie last man _always_ request cluster gating, that might not be what
we want), there is the residency value that can be also be used to imply a
S2R request (eg residency = ~0 ?).

The command sent must be implied by the state that is entered, not by
peeking at registers that should contain magic values, and that's true
not only for exynos but for all ARM platforms out there.

What I mean is: we can pass the requested state as a suspend parameter
and the power_down state machine will send the required command
accordingly.

It can be done using the residency value or by passing the power state index
as suspend parameter, the power down MCPM code will do a look-up and send
the respective command.

Thoughts appreciated.

Lorenzo

--
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/6] Various Samsung fixes for v3.16-rc3

[Tomasz Figa]

Hi,

On 24.06.2014 15:57, Tomasz Figa wrote:
 This series inteds to fix various issues spotted while testing v3.16-rc2.
 The patches should be reasonably independent from each other and so could be
 picked to respective trees. See descriptions of individual patches for more
 information.
 
 Tested on Exynos4412-based Trats2 and Exynos4210-based Trats boards.
 
 AFAIK there is no need to backport those fixes to stable.
 
 Tomasz Figa (6):
   mmc: sdhci-s3c: Fix local I/O clock gating
   ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
   clk: samsung: exynos4: Remove SRC_MASK_ISP gates
   ARM: SAMSUNG: Restore Samsung PM Debug functionality
   ARM: EXYNOS: Fix suspend/resume sequencies
   ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250
 
  arch/arm/mach-exynos/exynos.c |  6 ++
  arch/arm/mach-exynos/hotplug.c| 10 ++
  arch/arm/mach-exynos/platsmp.c| 34 +++---
  arch/arm/mach-exynos/pm.c | 20 
  arch/arm/plat-samsung/Kconfig |  8 +++-
  arch/arm/plat-samsung/pm-debug.c  |  1 +
  drivers/clk/samsung/clk-exynos4.c | 16 
  drivers/mmc/host/sdhci-s3c.c  | 17 ++---
  8 files changed, 53 insertions(+), 59 deletions(-)
 

Gentle ping.

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

[PATCH 0/2] cpuidle fixes and cleanup

[Chander Kashyap]

This patch series fixes the cpuidle for different states. Also removes arm
diagnostic and power register save/restore code as it is made generic.

Based on:
ARM: save/restore diagnostic register on Cortex-A9 suspend/resume
 http://www.spinics.net/lists/arm-kernel/msg340506.html

ARM: save/restore power control register on Cortex-A9 suspend/resume
 http://www.spinics.net/lists/arm-kernel/msg343320.html

Chander Kashyap (2):
  ARM: Exynos: remove arm diagnostic and power register save/restore
code
  cpuidle: Exynos: fix cpuidle for all states

 arch/arm/mach-exynos/common.h|2 +-
 arch/arm/mach-exynos/pm.c|   95 +-
 drivers/cpuidle/cpuidle-exynos.c |7 ++-
 3 files changed, 17 insertions(+), 87 deletions(-)

-- 
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 2/2] cpuidle: Exynos: fix cpuidle for all states

[Chander Kashyap]

Pre/post platform specific cpuidle operations are handled by pm_notifier.
But these operations are not same for all cpuidle states. Handle this by
moving cpuidle specific code from pm_notifier to cpuidle specific function.

Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
 arch/arm/mach-exynos/common.h|2 +-
 arch/arm/mach-exynos/pm.c|   45 ++
 drivers/cpuidle/cpuidle-exynos.c |7 --
 3 files changed, 17 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 1ee9176..7769f58 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -166,7 +166,7 @@ extern int  exynos_cpu_power_state(int cpu);
 extern void exynos_cluster_power_down(int cluster);
 extern void exynos_cluster_power_up(int cluster);
 extern int  exynos_cluster_power_state(int cluster);
-extern void exynos_enter_aftr(void);
+extern void exynos_enter_aftr(int entering_idle);
 
 extern void s5p_init_cpu(void __iomem *cpuid_addr);
 extern unsigned int samsung_rev(void);
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index a092cc3..328644f 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -188,14 +188,6 @@ static void exynos_cpu_set_boot_vector(long flags)
__raw_writel(flags, EXYNOS_BOOT_VECTOR_FLAG);
 }
 
-void exynos_enter_aftr(void)
-{
-   exynos_set_wakeupmask(0xff3e);
-   exynos_cpu_set_boot_vector(S5P_CHECK_AFTR);
-   /* Set value of power down register for aftr mode */
-   exynos_sys_powerdown_conf(SYS_AFTR);
-}
-
 static int exynos_cpu_suspend(unsigned long arg)
 {
 #ifdef CONFIG_CACHE_L2X0
@@ -386,40 +378,25 @@ static const struct platform_suspend_ops 
exynos_suspend_ops = {
.valid  = suspend_valid_only_mem,
 };
 
-static int exynos_cpu_pm_notifier(struct notifier_block *self,
- unsigned long cmd, void *v)
+void exynos_enter_aftr(int entering_idle)
 {
-   int cpu = smp_processor_id();
-
-   switch (cmd) {
-   case CPU_PM_ENTER:
-   if (cpu == 0)
-   exynos_pm_central_suspend();
-   break;
-
-   case CPU_PM_EXIT:
-   if (cpu == 0) {
-   if (read_cpuid_part_number() ==
-   ARM_CPU_PART_CORTEX_A9)
-   scu_enable(S5P_VA_SCU);
-   exynos_pm_central_resume();
-   }
-   break;
+   if (entering_idle) {
+   exynos_set_wakeupmask(0xff3e);
+   exynos_cpu_set_boot_vector(S5P_CHECK_AFTR);
+   /* Set value of power down register for aftr mode */
+   exynos_sys_powerdown_conf(SYS_AFTR);
+   exynos_pm_central_suspend();
+   } else {
+   if (scu_a9_has_base())
+   scu_enable(S5P_VA_SCU);
+   exynos_pm_central_resume();
}
-
-   return NOTIFY_OK;
 }
 
-static struct notifier_block exynos_cpu_pm_notifier_block = {
-   .notifier_call = exynos_cpu_pm_notifier,
-};
-
 void __init exynos_pm_init(void)
 {
u32 tmp;
 
-   cpu_pm_register_notifier(exynos_cpu_pm_notifier_block);
-
/* Platform-specific GIC callback */
gic_arch_extn.irq_set_wake = exynos_irq_set_wake;
 
diff --git a/drivers/cpuidle/cpuidle-exynos.c b/drivers/cpuidle/cpuidle-exynos.c
index 7c01512..1196ca7 100644
--- a/drivers/cpuidle/cpuidle-exynos.c
+++ b/drivers/cpuidle/cpuidle-exynos.c
@@ -18,11 +18,10 @@
 #include asm/suspend.h
 #include asm/cpuidle.h
 
-static void (*exynos_enter_aftr)(void);
+static void (*exynos_enter_aftr)(int);
 
 static int idle_finisher(unsigned long flags)
 {
-   exynos_enter_aftr();
cpu_do_idle();
 
return 1;
@@ -32,8 +31,12 @@ static int exynos_enter_core0_aftr(struct cpuidle_device 
*dev,
struct cpuidle_driver *drv,
int index)
 {
+   int entering_idle = true;
cpu_pm_enter();
+   exynos_enter_aftr(entering_idle);
cpu_suspend(0, idle_finisher);
+   entering_idle = false;
+   exynos_enter_aftr(entering_idle);
cpu_pm_exit();
 
return index;
-- 
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 0/2] cpuidle fixes and cleanup

[Russell King - ARM Linux]

On Tue, Jul 01, 2014 at 08:02:36PM +0530, Chander Kashyap wrote:
 This patch series fixes the cpuidle for different states. Also removes arm
 diagnostic and power register save/restore code as it is made generic.
 
 Based on:
 ARM: save/restore diagnostic register on Cortex-A9 suspend/resume
  http://www.spinics.net/lists/arm-kernel/msg340506.html

As there is an outstanding issue with this patch, we can't proceed with
this set of changes until we know what's going on there.

Also, bear in mind that I have changes which conflict with this in my
tree (which I've just updated.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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] clk: s2mps11: Fix clk_ops

[Karol Wrona]

s32mps11 clocks had registered callbacks for prepare ,unprepare and is_enable
what was wrong and caused i.e. that unused clocks were not disabled.

Regmap_read is cached so it can be called in is_prepare callback
to achieve this information. Enabled field was removed from struct s2mps11_clk.

Change-Id: I4a850aef9034ece4e45760291d0a6fdceffb3304
Signed-off-by: Karol Wrona k.wr...@samsung.com
---
 drivers/clk/clk-s2mps11.c |   33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index b5274a9..5df99a4 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -45,7 +45,6 @@ struct s2mps11_clk {
struct clk *clk;
struct clk_lookup *lookup;
u32 mask;
-   bool enabled;
unsigned int reg;
 };
 
@@ -62,8 +61,6 @@ static int s2mps11_clk_prepare(struct clk_hw *hw)
ret = regmap_update_bits(s2mps11-iodev-regmap_pmic,
 s2mps11-reg,
 s2mps11-mask, s2mps11-mask);
-   if (!ret)
-   s2mps11-enabled = true;
 
return ret;
 }
@@ -75,32 +72,32 @@ static void s2mps11_clk_unprepare(struct clk_hw *hw)
 
ret = regmap_update_bits(s2mps11-iodev-regmap_pmic, s2mps11-reg,
   s2mps11-mask, ~s2mps11-mask);
-
-   if (!ret)
-   s2mps11-enabled = false;
 }
 
-static int s2mps11_clk_is_enabled(struct clk_hw *hw)
+static int s2mps11_clk_is_prepared(struct clk_hw *hw)
 {
+   int ret;
+   u32 val;
struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
 
-   return s2mps11-enabled;
+   ret = regmap_read(s2mps11-iodev-regmap_pmic,
+   s2mps11-reg, val);
+   if (ret  0)
+   return -EINVAL;
+
+   return val  s2mps11-mask;
 }
 
 static unsigned long s2mps11_clk_recalc_rate(struct clk_hw *hw,
 unsigned long parent_rate)
 {
-   struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
-   if (s2mps11-enabled)
-   return 32768;
-   else
-   return 0;
+   return 32768;
 }
 
 static struct clk_ops s2mps11_clk_ops = {
.prepare= s2mps11_clk_prepare,
.unprepare  = s2mps11_clk_unprepare,
-   .is_enabled = s2mps11_clk_is_enabled,
+   .is_prepared= s2mps11_clk_is_prepared,
.recalc_rate= s2mps11_clk_recalc_rate,
 };
 
@@ -174,7 +171,6 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
unsigned int s2mps11_reg;
struct clk_init_data *clks_init;
int i, ret = 0;
-   u32 val;
 
s2mps11_clks = devm_kzalloc(pdev-dev, sizeof(*s2mps11_clk) *
S2MPS11_CLKS_NUM, GFP_KERNEL);
@@ -213,13 +209,6 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
s2mps11_clk-mask = 1  i;
s2mps11_clk-reg = s2mps11_reg;
 
-   ret = regmap_read(s2mps11_clk-iodev-regmap_pmic,
- s2mps11_clk-reg, val);
-   if (ret  0)
-   goto err_reg;
-
-   s2mps11_clk-enabled = val  s2mps11_clk-mask;
-
s2mps11_clk-clk = devm_clk_register(pdev-dev,
s2mps11_clk-hw);
if (IS_ERR(s2mps11_clk-clk)) {
-- 
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: mwifiex card reset

[Doug Anderson]

+Olof who posted the patch that Yuvaraj referenced.

On Tue, Jul 1, 2014 at 5:20 AM, Yuvaraj Cd yuvaraj.l...@gmail.com wrote:
 On Tue, Jul 1, 2014 at 12:27 PM, James Cameron qu...@laptop.org wrote:
 On Mon, Jun 30, 2014 at 11:44:29PM -0700, Bing Zhao wrote:
 I may have missed something, but doesn't the MMC_POWER_OFF and
 MMC_POWER_ON|UP handling in controller driver help?
 Anyway the clocks/GPIOs/regulators are sort of platform
 dependent. Would it be better putting it in /arch/arm/mach-x/?

 Wouldn't device tree for mmc be better?
 I have come across same problem.Below is the thread in which more
 discussions happened on this.
  http://patchwork.ozlabs.org/patch/312444/
 I am adding few more those who are interested in this solution.

Thanks to Yuvaraj for referencing the old thread.

It seems like there are already enough chefs in the kitchen so I'm not
going to add any more suggestions myself.  I'll point out that on all
ARM Chromebooks (which to date have a Marvell part connected via SDIO)
all face the same problem.  In production kernels we've continued to
get by with various hacks.  The current kernels use a hack with
regulator chaining and assumptions about 32K clocks already being on.
This is less egregious than the hacks in older kernels which initted
WiFi in the LCD backlight function (dont ask) but is still a hack.

-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: [PATCH v5 07/14] mfd: Add driver for Maxim 77802 Power Management IC

[Lee Jones]

On Thu, 26 Jun 2014, Javier Martinez Canillas wrote:

 Maxim MAX77802 is a power management chip that contains 10 high
 efficiency Buck regulators, 32 Low-dropout (LDO) regulators used
 to power up application processors and peripherals, a 2-channel
 32kHz clock outputs, a Real-Time-Clock (RTC) and a I2C interface
 to program the individual regulators, clocks outputs and the RTC.
 
 This patch adds the core support for MAX77802 PMIC and is based
 on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Tested-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 ---
 
 Changes since v4:
  - Use consistent expressions when checking for NULL values.
Suggested by Krzysztof Kozlowski.
  - Remove unused defines. Suggested by Krzysztof Kozlowski.
  - Explain why IRQ is disabled on suspend. Suggested by Krzysztof Kozlowski.
 
 Changes since v3:
  - Remove unnecessary OOM error message since the mm subsystem already logs 
 it. 
 
 Changes since v2:
  - Split the DT binding docs in a separate patch and improve the 
 documentation.
Suggested by Mark Brown.
  - Add all the devices in the MFD driver instead of doing in separate patches.
Suggested by Mark Brown.
 
 Changes since v1:
  - Convert max77{686,802} to regmap irq API and get rid of 
 max77{686,802}-irq.c
Suggested by Krzysztof Kozlowski.
  - Don't protect max77802 mfd_cells using Kconfig options since mfd core omits
devices that don't match. Suggested by Lee Jones.
  - Change mfd driver to be tristate instead of boolean. Suggested by Mark 
 Brown.
  - Change binding voltage-regulators property to regulators to be 
 consistent
with other PMIC drivers. Suggested by Mark Brown.
  - Use regulators node names instead of the deprecated regulator-compatible
property. Suggested by Mark Brown.
  - Use the new descriptor-based GPIO interface instead of the deprecated
integer based GPIO one. Suggested by Mark Brown.
  - Remove the type parameter from i2c_device_id table since was not used.
  - Fix device not found error message and remove unneeded device found 
 message.
 
  drivers/mfd/Kconfig  |  14 ++
  drivers/mfd/Makefile |   1 +
  drivers/mfd/max77802.c   | 366 ++

I don't think this needs it's own, brand new file.  You can just as
easy slot the enablement into max77686, which I suggest you do.

  include/linux/mfd/max77802-private.h | 307 +
  include/linux/mfd/max77802.h | 121 
  5 files changed, 809 insertions(+)
  create mode 100644 drivers/mfd/max77802.c
  create mode 100644 include/linux/mfd/max77802-private.h
  create mode 100644 include/linux/mfd/max77802.h

[...]

 +#ifdef CONFIG_OF
 +static struct of_device_id max77802_pmic_dt_match[] = {
 + {.compatible = maxim,max77802, .data = NULL},

Space before .compatible.

No need to set .data to NULL, just omit it.

 + {},
 +};
 +
 +static void max77802_dt_parse_dvs_gpio(struct device *dev,
 +struct max77802_platform_data *pd,
 +struct device_node *np)

No need to overload these parameters by passing np, you can extract it
from dev.  Same goes for pd if you populate platform_data _before_
calling this function.

 +{
 + int i;
 +
 + /*
 +  * NOTE: we don't consider GPIO errors fatal; board may have some lines
 +  * directly pulled high or low and thus doesn't specify them.
 +  */
 + for (i = 0; i  ARRAY_SIZE(pd-buck_gpio_dvs); i++)
 + pd-buck_gpio_dvs[i] =
 + devm_gpiod_get_index(dev, max77802,pmic-buck-dvs, i);
 +
 + for (i = 0; i  ARRAY_SIZE(pd-buck_gpio_selb); i++)
 + pd-buck_gpio_selb[i] =
 + devm_gpiod_get_index(dev, max77802,pmic-buck-selb, i);
 +}
 +
 +static struct max77802_platform_data *max77802_i2c_parse_dt_pdata(struct 
 device
 +   *dev)
 +{
 + struct device_node *np = dev-of_node;
 + struct max77802_platform_data *pd;
 +
 + pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
 + if (!pd)
 + return NULL;
 +
 + /* Read default index and ignore errors, since default is 0 */
 + of_property_read_u32(np, max77802,pmic-buck-default-dvs-idx,
 +  pd-buck_default_idx);
 +
 + max77802_dt_parse_dvs_gpio(dev, pd, np);
 +
 + dev-platform_data = pd;
 + return pd;
 +}
 +#else
 +static struct max77802_platform_data *max77802_i2c_parse_dt_pdata(struct 
 device
 +   *dev)
 +{
 + return 0;
 +}
 +#endif

No need for dummy functions.

Use if (IS_ENABLED(CONFIG_OF)  i2c-dev.of_node) instead.

 +static int max77802_i2c_probe(struct i2c_client *i2c,
 +

[PATCH v2] phy: phy-samsung-usb2: Change phy power on/power off sequence

[Kamil Debski]

The Exynos4412 USB 2.0 PHY hardware differs from the description provided
in the documentation. Some register bits have different function. This
patch fixes the defines of register bits and changes the way how phys are
powered on and off.

Signed-off-by: Kamil Debski k.deb...@samsung.com
---
 drivers/phy/phy-exynos4x12-usb2.c |  112 +
 drivers/phy/phy-exynos5250-usb2.c |2 -
 drivers/phy/phy-samsung-usb2.h|3 +-
 3 files changed, 77 insertions(+), 40 deletions(-)

diff --git a/drivers/phy/phy-exynos4x12-usb2.c 
b/drivers/phy/phy-exynos4x12-usb2.c
index d92a7cc..63134d8 100644
--- a/drivers/phy/phy-exynos4x12-usb2.c
+++ b/drivers/phy/phy-exynos4x12-usb2.c
@@ -86,13 +86,23 @@
 #define EXYNOS_4x12_URSTCON_OTG_HLINK  BIT(1)
 #define EXYNOS_4x12_URSTCON_OTG_PHYLINKBIT(2)
 #define EXYNOS_4x12_URSTCON_HOST_PHY   BIT(3)
+/* The following bit defines are presented in the
+ * order taken from the Exynos4412 reference manual.
+ *
+ * During experiments with the hardware and debugging
+ * it was determined that the hardware behaves contrary
+ * to the manual.
+ *
+ * The following bit values were chaned accordingly to the
+ * results of real hardware experiments.
+ */
 #define EXYNOS_4x12_URSTCON_PHY1   BIT(4)
-#define EXYNOS_4x12_URSTCON_HSIC0  BIT(5)
-#define EXYNOS_4x12_URSTCON_HSIC1  BIT(6)
+#define EXYNOS_4x12_URSTCON_HSIC0  BIT(6)
+#define EXYNOS_4x12_URSTCON_HSIC1  BIT(5)
 #define EXYNOS_4x12_URSTCON_HOST_LINK_ALL  BIT(7)
-#define EXYNOS_4x12_URSTCON_HOST_LINK_P0   BIT(8)
+#define EXYNOS_4x12_URSTCON_HOST_LINK_P0   BIT(10)
 #define EXYNOS_4x12_URSTCON_HOST_LINK_P1   BIT(9)
-#define EXYNOS_4x12_URSTCON_HOST_LINK_P2   BIT(10)
+#define EXYNOS_4x12_URSTCON_HOST_LINK_P2   BIT(8)
 
 /* Isolation, configured in the power management unit */
 #define EXYNOS_4x12_USB_ISOL_OFFSET0x704
@@ -188,6 +198,7 @@ static void exynos4x12_setup_clk(struct 
samsung_usb2_phy_instance *inst)
clk = readl(drv-reg_phy + EXYNOS_4x12_UPHYCLK);
clk = ~EXYNOS_4x12_UPHYCLK_PHYFSEL_MASK;
clk |= drv-ref_reg_val  EXYNOS_4x12_UPHYCLK_PHYFSEL_OFFSET;
+   clk |= EXYNOS_4x12_UPHYCLK_PHY1_COMMON_ON;
writel(clk, drv-reg_phy + EXYNOS_4x12_UPHYCLK);
 }
 
@@ -198,27 +209,22 @@ static void exynos4x12_phy_pwr(struct 
samsung_usb2_phy_instance *inst, bool on)
u32 phypwr = 0;
u32 rst;
u32 pwr;
-   u32 mode = 0;
-   u32 switch_mode = 0;
 
switch (inst-cfg-id) {
case EXYNOS4x12_DEVICE:
phypwr =EXYNOS_4x12_UPHYPWR_PHY0;
rstbits =   EXYNOS_4x12_URSTCON_PHY0;
-   mode =  EXYNOS_4x12_MODE_SWITCH_DEVICE;
-   switch_mode =   1;
break;
case EXYNOS4x12_HOST:
phypwr =EXYNOS_4x12_UPHYPWR_PHY1;
-   rstbits =   EXYNOS_4x12_URSTCON_HOST_PHY;
-   mode =  EXYNOS_4x12_MODE_SWITCH_HOST;
-   switch_mode =   1;
+   rstbits =   EXYNOS_4x12_URSTCON_HOST_PHY |
+   EXYNOS_4x12_URSTCON_PHY1 |
+   EXYNOS_4x12_URSTCON_HOST_LINK_P0;
break;
case EXYNOS4x12_HSIC0:
phypwr =EXYNOS_4x12_UPHYPWR_HSIC0;
-   rstbits =   EXYNOS_4x12_URSTCON_HSIC1 |
-   EXYNOS_4x12_URSTCON_HOST_LINK_P0 |
-   EXYNOS_4x12_URSTCON_HOST_PHY;
+   rstbits =   EXYNOS_4x12_URSTCON_HSIC0 |
+   EXYNOS_4x12_URSTCON_HOST_LINK_P1;
break;
case EXYNOS4x12_HSIC1:
phypwr =EXYNOS_4x12_UPHYPWR_HSIC1;
@@ -228,11 +234,6 @@ static void exynos4x12_phy_pwr(struct 
samsung_usb2_phy_instance *inst, bool on)
};
 
if (on) {
-   if (switch_mode)
-   regmap_update_bits(drv-reg_sys,
-  EXYNOS_4x12_MODE_SWITCH_OFFSET,
-  EXYNOS_4x12_MODE_SWITCH_MASK, mode);
-
pwr = readl(drv-reg_phy + EXYNOS_4x12_UPHYPWR);
pwr = ~phypwr;
writel(pwr, drv-reg_phy + EXYNOS_4x12_UPHYPWR);
@@ -253,41 +254,78 @@ static void exynos4x12_phy_pwr(struct 
samsung_usb2_phy_instance *inst, bool on)
}
 }
 
-static int exynos4x12_power_on(struct samsung_usb2_phy_instance *inst)
+static void exynos4x12_power_on_int(struct samsung_usb2_phy_instance *inst)
 {
-   struct samsung_usb2_phy_driver *drv = inst-drv;
+   if (inst-int_cnt++  0)
+   return;
 
-   inst-enabled = 1;
exynos4x12_setup_clk(inst);
-   exynos4x12_phy_pwr(inst, 1);
exynos4x12_isol(inst, 0);
+   exynos4x12_phy_pwr(inst, 1);
+}
+
+static int exynos4x12_power_on(struct 

Re: [PATCH v5 07/14] mfd: Add driver for Maxim 77802 Power Management IC

[Javier Martinez Canillas]

Hello Lee,

Thanks a lot for your feedback.

On 07/01/2014 05:15 PM, Lee Jones wrote:
 On Thu, 26 Jun 2014, Javier Martinez Canillas wrote:
 
 Maxim MAX77802 is a power management chip that contains 10 high
 efficiency Buck regulators, 32 Low-dropout (LDO) regulators used
 to power up application processors and peripherals, a 2-channel
 32kHz clock outputs, a Real-Time-Clock (RTC) and a I2C interface
 to program the individual regulators, clocks outputs and the RTC.
 
 This patch adds the core support for MAX77802 PMIC and is based
 on a driver added by Simon Glass to the Chrome OS kernel 3.8 tree.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Tested-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
 ---
 
 Changes since v4:
  - Use consistent expressions when checking for NULL values.
Suggested by Krzysztof Kozlowski.
  - Remove unused defines. Suggested by Krzysztof Kozlowski.
  - Explain why IRQ is disabled on suspend. Suggested by Krzysztof Kozlowski.
 
 Changes since v3:
  - Remove unnecessary OOM error message since the mm subsystem already logs 
 it. 
 
 Changes since v2:
  - Split the DT binding docs in a separate patch and improve the 
 documentation.
Suggested by Mark Brown.
  - Add all the devices in the MFD driver instead of doing in separate 
 patches.
Suggested by Mark Brown.
 
 Changes since v1:
  - Convert max77{686,802} to regmap irq API and get rid of 
 max77{686,802}-irq.c
Suggested by Krzysztof Kozlowski.
  - Don't protect max77802 mfd_cells using Kconfig options since mfd core 
 omits
devices that don't match. Suggested by Lee Jones.
  - Change mfd driver to be tristate instead of boolean. Suggested by Mark 
 Brown.
  - Change binding voltage-regulators property to regulators to be 
 consistent
with other PMIC drivers. Suggested by Mark Brown.
  - Use regulators node names instead of the deprecated regulator-compatible
property. Suggested by Mark Brown.
  - Use the new descriptor-based GPIO interface instead of the deprecated
integer based GPIO one. Suggested by Mark Brown.
  - Remove the type parameter from i2c_device_id table since was not used.
  - Fix device not found error message and remove unneeded device found 
 message.
 
  drivers/mfd/Kconfig  |  14 ++
  drivers/mfd/Makefile |   1 +
  drivers/mfd/max77802.c   | 366 
 ++
 

 I don't think this needs it's own, brand new file.  You can just as
 easy slot the enablement into max77686, which I suggest you do.


Since the series convert max77686 to use regmap IRQ and gets rid of
max77686-irq.c, the mfd max77{802,686} drivers are quite small now and are
composed mostly of data structures definitions (regmap_config and accessors
function handlers, regmap_irq, i2c_driver, etc) and the probe function.

So I thought that it was more maintainable and readable to keep them in separate
files than having lots of conditionals in the max77686 driver.

But since you think that is better to extend the max77686, I'll do it on the
next version of the patch-set. I'll try to keep it as clean as possible.

  include/linux/mfd/max77802-private.h | 307 +
  include/linux/mfd/max77802.h | 121 
  5 files changed, 809 insertions(+)
  create mode 100644 drivers/mfd/max77802.c
  create mode 100644 include/linux/mfd/max77802-private.h
  create mode 100644 include/linux/mfd/max77802.h
 
 [...]
 
 +#ifdef CONFIG_OF
 +static struct of_device_id max77802_pmic_dt_match[] = {
 +{.compatible = maxim,max77802, .data = NULL},
 
 Space before .compatible.


Ok.

 No need to set .data to NULL, just omit it.
 

Ok, I'll have to use .data though now that I'll extend max77686 to support
max77802 too.

 +{},
 +};
 +
 +static void max77802_dt_parse_dvs_gpio(struct device *dev,
 +   struct max77802_platform_data *pd,
 +   struct device_node *np)
 
 No need to overload these parameters by passing np, you can extract it
 from dev.  Same goes for pd if you populate platform_data _before_
 calling this function.
 

Right, I'll change that and just get it from dev.

 +{
 +int i;
 +
 +/*
 + * NOTE: we don't consider GPIO errors fatal; board may have some lines
 + * directly pulled high or low and thus doesn't specify them.
 + */
 +for (i = 0; i  ARRAY_SIZE(pd-buck_gpio_dvs); i++)
 +pd-buck_gpio_dvs[i] =
 +devm_gpiod_get_index(dev, max77802,pmic-buck-dvs, i);
 +
 +for (i = 0; i  ARRAY_SIZE(pd-buck_gpio_selb); i++)
 +pd-buck_gpio_selb[i] =
 +devm_gpiod_get_index(dev, max77802,pmic-buck-selb, i);
 +}
 +
 +static struct max77802_platform_data *max77802_i2c_parse_dt_pdata(struct 
 device
 +  *dev)
 +{
 +struct 

Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

[Måns Rullgård]

Russell King rmk+ker...@arm.linux.org.uk writes:

 ARMv6 and greater introduced a new instruction (bx) which can be used
 to return from function calls.  Recent CPUs perform better when the
 bx lr instruction is used rather than the mov pc, lr instruction,
 and this sequence is strongly recommended to be used by the ARM
 architecture manual (section A.4.1.1).

 We provide a new macro ret with all its variants for the condition
 code which will resolve to the appropriate instruction.

When the source register is not lr the name ret is a misnomer since
only the bx lr instruction is predicted as a function return.  The
bx instruction with other source registers uses the normal prediction
mechanisms, leaving the return stack alone, and should not be used for
function returns.  Any code currently using another register to return
from a function should probably be modified to use lr instead, unless
there are special reasons for doing otherwise.  If code jumping to an
address in a non-lr register is not a return, using the ret name will
make for some rather confusing reading.

I would suggest either using a more neutral name than ret or adding an
alias to be used for non-return jumps so as to make the intent clearer.

-- 
Måns Rullgård
m...@mansr.com
--
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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

[Russell King - ARM Linux]

On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
 Russell King rmk+ker...@arm.linux.org.uk writes:
 
  ARMv6 and greater introduced a new instruction (bx) which can be used
  to return from function calls.  Recent CPUs perform better when the
  bx lr instruction is used rather than the mov pc, lr instruction,
  and this sequence is strongly recommended to be used by the ARM
  architecture manual (section A.4.1.1).
 
  We provide a new macro ret with all its variants for the condition
  code which will resolve to the appropriate instruction.
 
 When the source register is not lr the name ret is a misnomer since
 only the bx lr instruction is predicted as a function return.  The
 bx instruction with other source registers uses the normal prediction
 mechanisms, leaving the return stack alone, and should not be used for
 function returns.  Any code currently using another register to return
 from a function should probably be modified to use lr instead, unless
 there are special reasons for doing otherwise.  If code jumping to an
 address in a non-lr register is not a return, using the ret name will
 make for some rather confusing reading.
 
 I would suggest either using a more neutral name than ret or adding an
 alias to be used for non-return jumps so as to make the intent clearer.

If you read the patch, the branches which are changed are those which
do indeed return in some way.  There are those which do this having
moved lr to a different register.

As you point out, bx lr /may/ be treated specially (I've actually been
discussing this with Will Deacon over the last couple of days, who has
also been talking to the hardware people in ARM, and Will is happy with
this patch as in its current form.)  This is why I've changed all
mov pc, reg instructions which return in some way to use this macro,
and left others (those which are used to call some function and return
back to the same point) alone.

I have thought about introducing a call macro for those other sites,
but as there are soo few of them, I've left them as-is for the time
being (this patch is already large enough.)

If there are any in the patch which you have specific concerns about,
please specifically point them out those which give you a concern.

Thanks.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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: s2mps11: Fix clk_ops

[Karol Wrona]

s2mps11 clocks had registered callbacks for prepare ,unprepare and is_enabled.
During disabling unused clocks the lack of is_prepared caused that unused
s2mps11 clocks were not unprepared and stayed active.

Regmap_read is cached so it can be called in is_prepare callback
to achieve this information. Enabled field was removed from struct s2mps11_clk.

Signed-off-by: Karol Wrona k.wr...@samsung.com
---
 drivers/clk/clk-s2mps11.c |   33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index b5274a9..5df99a4 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -45,7 +45,6 @@ struct s2mps11_clk {
struct clk *clk;
struct clk_lookup *lookup;
u32 mask;
-   bool enabled;
unsigned int reg;
 };
 
@@ -62,8 +61,6 @@ static int s2mps11_clk_prepare(struct clk_hw *hw)
ret = regmap_update_bits(s2mps11-iodev-regmap_pmic,
 s2mps11-reg,
 s2mps11-mask, s2mps11-mask);
-   if (!ret)
-   s2mps11-enabled = true;
 
return ret;
 }
@@ -75,32 +72,32 @@ static void s2mps11_clk_unprepare(struct clk_hw *hw)
 
ret = regmap_update_bits(s2mps11-iodev-regmap_pmic, s2mps11-reg,
   s2mps11-mask, ~s2mps11-mask);
-
-   if (!ret)
-   s2mps11-enabled = false;
 }
 
-static int s2mps11_clk_is_enabled(struct clk_hw *hw)
+static int s2mps11_clk_is_prepared(struct clk_hw *hw)
 {
+   int ret;
+   u32 val;
struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
 
-   return s2mps11-enabled;
+   ret = regmap_read(s2mps11-iodev-regmap_pmic,
+   s2mps11-reg, val);
+   if (ret  0)
+   return -EINVAL;
+
+   return val  s2mps11-mask;
 }
 
 static unsigned long s2mps11_clk_recalc_rate(struct clk_hw *hw,
 unsigned long parent_rate)
 {
-   struct s2mps11_clk *s2mps11 = to_s2mps11_clk(hw);
-   if (s2mps11-enabled)
-   return 32768;
-   else
-   return 0;
+   return 32768;
 }
 
 static struct clk_ops s2mps11_clk_ops = {
.prepare= s2mps11_clk_prepare,
.unprepare  = s2mps11_clk_unprepare,
-   .is_enabled = s2mps11_clk_is_enabled,
+   .is_prepared= s2mps11_clk_is_prepared,
.recalc_rate= s2mps11_clk_recalc_rate,
 };
 
@@ -174,7 +171,6 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
unsigned int s2mps11_reg;
struct clk_init_data *clks_init;
int i, ret = 0;
-   u32 val;
 
s2mps11_clks = devm_kzalloc(pdev-dev, sizeof(*s2mps11_clk) *
S2MPS11_CLKS_NUM, GFP_KERNEL);
@@ -213,13 +209,6 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
s2mps11_clk-mask = 1  i;
s2mps11_clk-reg = s2mps11_reg;
 
-   ret = regmap_read(s2mps11_clk-iodev-regmap_pmic,
- s2mps11_clk-reg, val);
-   if (ret  0)
-   goto err_reg;
-
-   s2mps11_clk-enabled = val  s2mps11_clk-mask;
-
s2mps11_clk-clk = devm_clk_register(pdev-dev,
s2mps11_clk-hw);
if (IS_ERR(s2mps11_clk-clk)) {
-- 
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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

[Måns Rullgård]

Russell King - ARM Linux li...@arm.linux.org.uk writes:

 On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
 Russell King rmk+ker...@arm.linux.org.uk writes:
 
  ARMv6 and greater introduced a new instruction (bx) which can be used
  to return from function calls.  Recent CPUs perform better when the
  bx lr instruction is used rather than the mov pc, lr instruction,
  and this sequence is strongly recommended to be used by the ARM
  architecture manual (section A.4.1.1).
 
  We provide a new macro ret with all its variants for the condition
  code which will resolve to the appropriate instruction.
 
 When the source register is not lr the name ret is a misnomer since
 only the bx lr instruction is predicted as a function return.  The
 bx instruction with other source registers uses the normal prediction
 mechanisms, leaving the return stack alone, and should not be used for
 function returns.  Any code currently using another register to return
 from a function should probably be modified to use lr instead, unless
 there are special reasons for doing otherwise.  If code jumping to an
 address in a non-lr register is not a return, using the ret name will
 make for some rather confusing reading.
 
 I would suggest either using a more neutral name than ret or adding an
 alias to be used for non-return jumps so as to make the intent clearer.

 If you read the patch, the branches which are changed are those which
 do indeed return in some way.  There are those which do this having
 moved lr to a different register.

The patch is huge, and it wasn't obvious (to me) from the diff context
what the non-lr jumps were doing.

 As you point out, bx lr /may/ be treated specially (I've actually been

Most, if not all, Cortex-A cores do this according the public TRMs.
They also do the same thing for mov pc, lr so there will probably be
no performance gain from this change.  It's still a good idea though,
since we don't know what future cores will do.

 discussing this with Will Deacon over the last couple of days, who has
 also been talking to the hardware people in ARM, and Will is happy with
 this patch as in its current form.)  This is why I've changed all
 mov pc, reg instructions which return in some way to use this macro,
 and left others (those which are used to call some function and return
 back to the same point) alone.

In that case the patch should be fine.  Your patch description didn't
make it clear that only actual returns were being changed.

-- 
Måns Rullgård
m...@mansr.com
--
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 05/14] clk: Add generic driver for Maxim PMIC clocks

[Mike Turquette]

Quoting Yadwinder Singh Brar (2014-06-29 21:01:36)
 Hi Javier,
 
 On Thu, Jun 26, 2014 at 11:45 PM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
  Maxim Integrated Power Management ICs are very similar with
  regard to their clock outputs. Most of the clock drivers for
  these chips are duplicating code and are simpler enough that
  can be converted to use a generic driver to consolidate code
  and avoid duplication.
 
  Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
  Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
  ---
 
  Changes since v4:
   - Return recalc 0 if clock isn't enabled in Suggested by Yadwinder Singh 
  Brar.
 
 
 It seems you didn't implement or posted same patch again :) .
 
  Changes since v3:
   - Add current copyright information. Suggested by Krzysztof Kozlowski
   - Do a single allocation for struct max_gen_clk. Suggested by Krzysztof 
  Kozlowski
   - Add EXPORT_SYMBOL() for exported symbols. Suggested by Krzysztof 
  Kozlowski
 
   drivers/clk/Kconfig   |   3 +
   drivers/clk/Makefile  |   1 +
   drivers/clk/clk-max-gen.c | 195 
  ++
   drivers/clk/clk-max-gen.h |  32 
   4 files changed, 231 insertions(+)
   create mode 100644 drivers/clk/clk-max-gen.c
   create mode 100644 drivers/clk/clk-max-gen.h
 
 
 [ .. ]
 
  +
  +static unsigned long max_gen_recalc_rate(struct clk_hw *hw,
  +unsigned long parent_rate)
  +{
  +   return 32768;
  +}
 
 Its still same here.

Changing this would be a new behavior. I do not know of any other clock
drivers that conditionally returns a rate of 0 based on whether or not
the clock is gated.

It is also buggy since calls to clk_enable and clk_disable do not invoke
.recalc_rate, so the rate of your clock would not be updated from the
framework's perspective until some later point where you call
clk_set_rate or something.

If your driver needs to know whether or not the clock is enabled then we
could introduce a new bool clk_is_enabled(struct clk *clk); to clk.h,
but I'd rather not do that. Instead if a driver needs a clock then it
calls clk_enable on it without any knowledge about the internal state of
the clock enable_count.

Regards,
Mike

 
  +
  +struct clk_ops max_gen_clk_ops = {
  +   .prepare= max_gen_clk_prepare,
  +   .unprepare  = max_gen_clk_unprepare,
  +   .is_prepared= max_gen_clk_is_prepared,
  +   .recalc_rate= max_gen_recalc_rate,
  +};
  +EXPORT_SYMBOL_GPL(max_gen_clk_ops);
  +
  +static struct clk *max_gen_clk_register(struct device *dev,
  +   struct max_gen_clk *max_gen)
  +{
  +   struct clk *clk;
  +   struct clk_hw *hw = max_gen-hw;
  +
  +   clk = clk_register(dev, hw);
  +   if (IS_ERR(clk))
  +   return clk;
  +
  +   max_gen-lookup = kzalloc(sizeof(struct clk_lookup), GFP_KERNEL);
 
 As I suggested in other patch[1] also, its better to use
 clkdev_alloc() instead of kzalloc() here.
 
  +   if (!max_gen-lookup)
  +   return ERR_PTR(-ENOMEM);
  +
  +   max_gen-lookup-con_id = hw-init-name;
 
 Also IMO,  init-name should be over-written if name is provided in DT,
 otherwise generic clock-output-names property will go futile,
 perhaps it should be done before clk_register.
 
 Regards,
 Yadwinder
 
 [1] : https://lkml.org/lkml/2014/6/27/197
 
  +   max_gen-lookup-clk = clk;
  +
  +   clkdev_add(max_gen-lookup);
  +
  +   return clk;
  +}
  +
  +int max_gen_clk_probe(struct platform_device *pdev, struct regmap *regmap,
  + u32 reg, struct clk_init_data *clks_init, int 
  num_init)
  +{
  +   int i, ret;
  +   struct max_gen_clk *max_gen_clks;
  +   struct clk **clocks;
  +   struct device *dev = pdev-dev;
  +
  +   clocks = devm_kzalloc(dev, sizeof(struct clk *) * num_init, 
  GFP_KERNEL);
  +   if (!clocks)
  +   return -ENOMEM;
  +
  +   max_gen_clks = devm_kzalloc(dev, sizeof(struct max_gen_clk)
  +   * num_init, GFP_KERNEL);
  +   if (!max_gen_clks)
  +   return -ENOMEM;
  +
  +   for (i = 0; i  num_init; i++) {
  +   max_gen_clks[i].regmap = regmap;
  +   max_gen_clks[i].mask = 1  i;
  +   max_gen_clks[i].reg = reg;
  +   max_gen_clks[i].hw.init = clks_init[i];
  +
  +   clocks[i] = max_gen_clk_register(dev, max_gen_clks[i]);
  +   if (IS_ERR(clocks[i])) {
  +   ret = PTR_ERR(clocks[i]);
  +   dev_err(dev, failed to register %s\n,
  +   max_gen_clks[i].hw.init-name);
  +   goto err_clocks;
  +   }
  +   }
  +
  +   platform_set_drvdata(pdev, clocks);
  +
  +   if (dev-of_node) {
  +   struct clk_onecell_data *of_data;
  +
  +   

Re: [PATCH v5 04/14] clk: max77686: Improve Maxim 77686 PMIC clocks binding

[Mike Turquette]

Quoting Javier Martinez Canillas (2014-06-26 11:15:36)
 Like most clock drivers, the Maxim 77686 PMIC clock binding
 follows the convention that the #clock-cells property is
 used to specify the number of cells in a clock provider.
 
 But the binding document is not clear enough that it shall
 be set to 1 since the PMIC support multiple clocks outputs.
 
 Also, explain that the clocks identifiers are defined in a
 header file that can be included by Device Tree source with
 client nodes to avoid using magic numbers.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Reviewed-by: Doug Anderson diand...@chromium.org

Looks good to me.

Regards,
Mike

 ---
 
 Changes since v4: None
 
 Changes since v3:
  - Don't change clock-names property to make clear that it's
the consumer clock name and should not match the producer clock.
Suggested by Doug Anderson.
 
  Documentation/devicetree/bindings/clock/maxim,max77686.txt | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/clock/maxim,max77686.txt 
 b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
 index 96ce71b..48e00bb 100644
 --- a/Documentation/devicetree/bindings/clock/maxim,max77686.txt
 +++ b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
 @@ -9,13 +9,18 @@ The MAX77686 contains three 32.768khz clock outputs that 
 can be controlled
  Following properties should be presend in main device node of the MFD chip.
  
  Required properties:
 -- #clock-cells: simple one-cell clock specifier format is used, where the
 -  only cell is used as an index of the clock inside the provider. Following
 -  indices are allowed:
 +
 +- #clock-cells: from common clock binding; shall be set to 1.
 +
 +Each clock is assigned an identifier and client nodes can use this identifier
 +to specify the clock which they consume. Following indices are allowed:
  - 0: 32khz_ap clock,
  - 1: 32khz_cp clock,
  - 2: 32khz_pmic clock.
  
 +Clocks are defined as preprocessor macros in 
 dt-bindings/clock/maxim,max77686.h
 +header and can be used in device tree sources.
 +
  Example: Node of the MFD chip
  
 max77686: max77686@09 {
 @@ -34,5 +39,5 @@ Example: Clock consumer node
 compatible = bar,foo;
 /* ... */
 clock-names = my-clock;
 -   clocks = max77686 2;
 +   clocks = max77686 MAX77686_CLK_PMIC;
 };
 -- 
 2.0.0.rc2
 
--
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 03/14] clk: max77686: Add DT include for MAX77686 PMIC clock

[Mike Turquette]

Quoting Javier Martinez Canillas (2014-06-26 11:15:35)
 This patch adds a dt-binding include for Maxim 77686
 PMIC clock IDs that can be to be shared between the
 clk-max77686 clock driver and DeviceTree source files.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Looks good to me.

Regards,
Mike

 ---
 
 Changes since v4: None
 
 Changes since v3: None
 
  drivers/clk/clk-max77686.c |  7 +--
  include/dt-bindings/clock/maxim,max77686.h | 23 +++
  2 files changed, 24 insertions(+), 6 deletions(-)
  create mode 100644 include/dt-bindings/clock/maxim,max77686.h
 
 diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
 index 3d7e8dd..185b611 100644
 --- a/drivers/clk/clk-max77686.c
 +++ b/drivers/clk/clk-max77686.c
 @@ -30,12 +30,7 @@
  #include linux/mutex.h
  #include linux/clkdev.h
  
 -enum {
 -   MAX77686_CLK_AP = 0,
 -   MAX77686_CLK_CP,
 -   MAX77686_CLK_PMIC,
 -   MAX77686_CLKS_NUM,
 -};
 +#include dt-bindings/clock/maxim,max77686.h
  
  struct max77686_clk {
 struct max77686_dev *iodev;
 diff --git a/include/dt-bindings/clock/maxim,max77686.h 
 b/include/dt-bindings/clock/maxim,max77686.h
 new file mode 100644
 index 000..7b28b09
 --- /dev/null
 +++ b/include/dt-bindings/clock/maxim,max77686.h
 @@ -0,0 +1,23 @@
 +/*
 + * Copyright (C) 2014 Google, Inc
 + *
 + * 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.
 + *
 + * Device Tree binding constants clocks for the Maxim 77686 PMIC.
 + */
 +
 +#ifndef _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H
 +#define _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H
 +
 +/* Fixed rate clocks. */
 +
 +#define MAX77686_CLK_AP0
 +#define MAX77686_CLK_CP1
 +#define MAX77686_CLK_PMIC  2
 +
 +/* Total number of clocks. */
 +#define MAX77686_CLKS_NUM  (MAX77686_CLK_PMIC + 1)
 +
 +#endif /* _DT_BINDINGS_CLOCK_MAXIM_MAX77686_CLOCK_H */
 -- 
 2.0.0.rc2
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

[Will Deacon]

Hi Mans,

On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
 Russell King - ARM Linux li...@arm.linux.org.uk writes:
  As you point out, bx lr /may/ be treated specially (I've actually been
 
 Most, if not all, Cortex-A cores do this according the public TRMs.
 They also do the same thing for mov pc, lr so there will probably be
 no performance gain from this change.  It's still a good idea though,
 since we don't know what future cores will do.

Funnily enough, that's not actually true (and is more or less what prompted
this patch after discussion with Russell). There are cores out there that
don't predict mov pc, lr at all (let alone do anything with the return
stack).

  discussing this with Will Deacon over the last couple of days, who has
  also been talking to the hardware people in ARM, and Will is happy with
  this patch as in its current form.)  This is why I've changed all
  mov pc, reg instructions which return in some way to use this macro,
  and left others (those which are used to call some function and return
  back to the same point) alone.
 
 In that case the patch should be fine.  Your patch description didn't
 make it clear that only actual returns were being changed.

I'm led to believe that some predictors require lr in order to update the
return stack, whilst others don't. That part is all horribly
micro-architectural, so the current patch is doing the right thing by
sticking to the ARM ARM but enabling us to hook into other registers later
on if we choose.

Cheers,

Will
--
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/7] clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks

[Tobias Jakobi]

Hi,


Marek Szyprowski wrote:
 Hello,
 
 On 2014-07-01 10:46, Tobias Jakobi wrote:
 Hello Marek,

 I think this particular clock setup should already be handled by this
 patch:
 http://www.spinics.net/lists/arm-kernel/msg320013.html

 Or am I missing something here?
 
 The patch you have pointed requires adding support for SET_PARENT_PARENT
 feature to clock core, which has not been accepted yet. Only then Exynod
 DRM drivers can be updated to correctly handle the changed clock tree.
I'm aware of this, but my point is: Wouldn't it be better to get the
SET_PARENT_PARENT upstream instead of applying a work-around (I am
assuming of course that SET_PARENT_PARENT is the correct way of handling
these clocks), which would be reverted later anyway?

Also this looks like similar to the work duplication issue that was
raised before here on the ml. Different groups working on the same
thing, but with no or little coordination between them. Might be just me
though...


 My approach is to introduce minimal changes and use the code which is
 already in the exynos drm/hdmi driver (it already manages 'mout_hdmi/mixer'
 clocks). If other solution is finally accepted, the code can be simplified
 and mout_hdmi/mixer clocks simply ignored. For now - my changes are needed
 to get HDMI output working and have least dependencies.
 
 Best regards


With best wishes,
Tobias

--
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 4/7] Exynos: add support for 'domain-always-on' property

[Tobias Jakobi]

Hi,


Marek Szyprowski wrote:
 Hello,
 
 On 2014-07-01 10:52, Tobias Jakobi wrote:
 Hello Marek,

 I think you had a similar patch in the tizen tree, but according to
 Tomasz Figa, it was considered a hack. I don't quite see how this is
 different.

 Also, if I have been following the discussion correctly, then the
 powerdomain issue essentially is about the question which SoC block
 needs the LCD0 domain and how the proper power on/off sequences should
 look like.

 At least the mixer power issue, which I pointed out some time ago, seems
 to be deal with now:
 https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-nextid=381be025ac1a6dc8efebdf146ced0d4a6007f77b

 
 Well, that patch solves power on/off sequence issue with mixer and hdmi,
 but it didn't solve the issue with additional managing of power domain
 on/off. You can check that if you remove always on property, system will
 freeze when hdmi cable is connected for the second time. I've investigated
 it for some time, but right now I didn't find any 100% reliable solution
 other than keeping the power domain enabled all the time. At least for
 now, this patch lets you use HDMI without any stability issues.
Hmm, I have also applied a similar hack to force TV and LCD0 pd on on my
system, but I didn't experience this behaviour (cable reconnecting).
Guess I have to recheck with some more recent tree to make sure.


 I've only found that there are still at least 2 issues with power domains.
 One is Mixer/Video Processor dependency on LCD0 domain, second is the
 proper
 power on/off sequence of HDMI/Mixer and TV domain. Forcing both domains to
 'always on' workarounds both issues for now. Right now I have no better
 idea.
I had the impression that the patch from above, plus this one
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-nextid=245f98f269714c08dc6d66d021d166cf36059bc4
were supposed to fix these issues. I haven't tested them yet, because of
lack of time, but Rahul's patch appears to fix mixer poweroff, and
Inki's patch the sequencing (VP, Mixer and last but not least, the HDMI).


 Later, once the proper sequence is found we can remove those properties
 from Odroid DTS.
I dunno, because you would have to support the property to the end of
time then, even though it's not used anymore. Isn't that the kind of
thing that shouldn't end up in DT bindings specs?



 
 Best regards


With best wishes,
Tobias

--
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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

[Stephen Warren]

On 07/01/2014 10:19 AM, Russell King wrote:
 ARMv6 and greater introduced a new instruction (bx) which can be used
 to return from function calls.  Recent CPUs perform better when the
 bx lr instruction is used rather than the mov pc, lr instruction,
 and this sequence is strongly recommended to be used by the ARM
 architecture manual (section A.4.1.1).
 
 We provide a new macro ret with all its variants for the condition
 code which will resolve to the appropriate instruction.
 
 Rather than doing this piecemeal, and miss some instances, change all
 the mov pc instances to use the new macro, with the exception of
 the movs instruction and the kprobes code.  This allows us to detect
 the mov pc, lr case and fix it up - and also gives us the possibility
 of deploying this for other registers depending on the CPU selection.

Tested-by: Stephen Warren swar...@nvidia.com

(On an NVIDIA Tegra Jetson TK1 board, both CPU hotplug and system sleep
were tested, which are the use-cases that actually use the edited
assembly files)
--
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] ARM: EXYNOS: Use MCPM call-backs to support S2R on Exynos5420

[Nicolas Pitre]

On Tue, 1 Jul 2014, Lorenzo Pieralisi wrote:

 On Tue, Jul 01, 2014 at 02:14:49PM +0100, Abhilash Kesavan wrote:
  Hi Nicolas,
  
  On Tue, Jul 1, 2014 at 9:49 AM, Nicolas Pitre nicolas.pi...@linaro.org 
  wrote:
   On Mon, 30 Jun 2014, Abhilash Kesavan wrote:
  
   Use the MCPM layer to handle core suspend/resume on Exynos5420.
   Also, restore the entry address setup code post-resume.
  
   Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
   ---
   [...]
  
   Could you tell me more about this?
  
   @@ -150,7 +153,13 @@ static void exynos_power_down(void)
 BUG_ON(__mcpm_cluster_state(cluster) != CLUSTER_UP);
 cpu_use_count[cpu][cluster]--;
 if (cpu_use_count[cpu][cluster] == 0) {
   - exynos_cpu_power_down(cpunr);
   + /*
   +  * Bypass power down for CPU0 during suspend. This is being
   +  * taken care by the SYS_PWR_CFG bit in CORE0_SYS_PWR_REG.
   +  */
   + if ((cpunr != 0) ||
   + (__raw_readl(pmu_base_addr + S5P_INFORM1) != 
   S5P_CHECK_SLEEP))
   + exynos_cpu_power_down(cpunr);
  
   What happens if CPU0 is the first in the cluster to be idled?  Will it
   remain powered up until all the others have gone idle too?
  This check is only for handling the S2R CPU0 case. In case of
  idle/switching the S5P_CHECK_SLEEP flag would not be set and hence
  there would be no change in behavior for them.
  During suspend, we enable the ARM_USE_STANDBY_WFI0 bit which tells the
  PMU when the CPU0 is ready to be suspended. This in conjunction with
  the sleep state core configuration (setting SYS_PWR_REG low) causes
  the CPU0 to go down. We should not write to the CPU0 power
  configuration register (exynos_cpu_power_down) along with this during
  suspend.
 
 I think this should be part of a refactoring that includes the exynos MCPM
 suspend call parameters. In particular, at the moment there is no code in
 the back-end to detect if the last man should request core gating or cluster
 gating (ie last man _always_ request cluster gating, that might not be what
 we want), there is the residency value that can be also be used to imply a
 S2R request (eg residency = ~0 ?).
 
 The command sent must be implied by the state that is entered, not by
 peeking at registers that should contain magic values, and that's true
 not only for exynos but for all ARM platforms out there.
 
 What I mean is: we can pass the requested state as a suspend parameter
 and the power_down state machine will send the required command
 accordingly.
 
 It can be done using the residency value or by passing the power state index
 as suspend parameter, the power down MCPM code will do a look-up and send
 the respective command.
 
 Thoughts appreciated.

I agree.  Having the MCPM abstraction having to rely on some magic value 
to be set in a register beforehand for things to work properly is not 
nice.


Nicolas
--
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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

[Måns Rullgård]

Will Deacon will.dea...@arm.com writes:

 Hi Mans,

 On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
 Russell King - ARM Linux li...@arm.linux.org.uk writes:
  As you point out, bx lr /may/ be treated specially (I've actually been
 
 Most, if not all, Cortex-A cores do this according the public TRMs.
 They also do the same thing for mov pc, lr so there will probably be
 no performance gain from this change.  It's still a good idea though,
 since we don't know what future cores will do.

 Funnily enough, that's not actually true (and is more or less what prompted
 this patch after discussion with Russell). There are cores out there that
 don't predict mov pc, lr at all (let alone do anything with the return
 stack).

Even ones where the TRM says they do?  I suppose the only way to know
for sure is to measure it.

  discussing this with Will Deacon over the last couple of days, who has
  also been talking to the hardware people in ARM, and Will is happy with
  this patch as in its current form.)  This is why I've changed all
  mov pc, reg instructions which return in some way to use this macro,
  and left others (those which are used to call some function and return
  back to the same point) alone.
 
 In that case the patch should be fine.  Your patch description didn't
 make it clear that only actual returns were being changed.

 I'm led to believe that some predictors require lr in order to update the
 return stack, whilst others don't. That part is all horribly
 micro-architectural, so the current patch is doing the right thing by
 sticking to the ARM ARM but enabling us to hook into other registers later
 on if we choose.

Agreed.

-- 
Måns Rullgård
m...@mansr.com
--
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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

[Robert Jarzmik]

Russell King rmk+ker...@arm.linux.org.uk writes:

 ARMv6 and greater introduced a new instruction (bx) which can be used
 to return from function calls.  Recent CPUs perform better when the
 bx lr instruction is used rather than the mov pc, lr instruction,
 and this sequence is strongly recommended to be used by the ARM
 architecture manual (section A.4.1.1).

For ARMv5 - XScale, and more specificaly the mioa701_bootresume.S path (suspend
to RAM) :
Tested-by: Robert Jarzmik robert.jarz...@free.fr

Cheers.

--
Robert
--
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] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250

[Chanwoo Choi]

On 07/01/2014 01:10 PM, Sachin Kamat wrote:
 Hi Chanwoo,
 
 On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
 Hi Sachin,

 On 07/01/2014 12:33 PM, Sachin Kamat wrote:
 Hi Chanwoo,

 On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patch add TMU (Thermal Management Unit) dt node to monitor the high
 temperature for Exynos3250.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 This patch has a dependency on following patch [1]:
  [1] https://lkml.org/lkml/2014/6/30/805

  arch/arm/boot/dts/exynos3250.dtsi | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
 b/arch/arm/boot/dts/exynos3250.dtsi
 index 3660cab..1e566af 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -192,6 +192,16 @@
 status = disabled;
 };

 +   tmu: tmu@100C {
 +   compatible = samsung,exynos3250-tmu;
 +   interrupt-parent = gic;
 +   reg = 0x100C 0x100;
 +   interrupts = 0 216 0;
 +   clocks = cmu CLK_TMU_APBIF;
 +   clock-names = tmu_apbif;
 +   status = disabled;

 I don't think there would be any board specific properties needed. Hence
 leave the status as enabled (by deleting the above line).


 I think that if specific board need TMU feature, dts file for specific board
 should include tmu dt node with 'okay' status. The specific board based on
 Exynos3250 might not need TMU feature.
 
 The status field in DT node is not meant for stating the build configuration 
 but
 represents the readiness of the hardware for usage on the platform. If
 a particular
 board does not need this feature it needs to be disabled in the build
 config and only
 for any special requirements disable it in board file.

TMU (Thermal Management Unit) needs specific regulator for TMU power as 
following:
The regulator for TMU is dependent on board.

For exmaple: in board dts file including tmu dt

tmu {
vtmu-supply = ldo7_reg;
status = okay;
};


--
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/3] of: Add memory limiting function for flattened devicetrees

[Laura Abbott]

Buggy bootloaders may pass bogus memory entries in the devicetree.
Add of_fdt_limit_memory to add an upper bound on the number of
entries that can be present in the devicetree.

Signed-off-by: Laura Abbott lau...@codeaurora.org
---
 drivers/of/fdt.c   | 48 
 include/linux/of_fdt.h |  1 +
 2 files changed, 49 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 55bfca9..fd5db5a 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -26,6 +26,54 @@
 #include asm/setup.h  /* for COMMAND_LINE_SIZE */
 #include asm/page.h
 
+/*
+ * of_fdt_limit_memory - limit the number of regions in the /memory node
+ * @limit: maximum entries
+ *
+ * Adjust the flattened device tree to have at most 'limit' number of
+ * memory entries in the /memory node. This function may be called
+ * any time after initial_boot_param is set.
+ */
+void of_fdt_limit_memory(int limit)
+{
+   int memory;
+   int len;
+   const void *val;
+   int nr_address_cells = OF_ROOT_NODE_ADDR_CELLS_DEFAULT;
+   int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
+   const uint32_t *addr_prop;
+   const uint32_t *size_prop;
+   int root_offset;
+   int cell_size;
+
+   root_offset = fdt_path_offset(initial_boot_params, /);
+   if (root_offset  0)
+   return;
+
+   addr_prop = fdt_getprop(initial_boot_params, root_offset,
+   #address-cells, NULL);
+   if (addr_prop)
+   nr_address_cells = fdt32_to_cpu(*addr_prop);
+
+   size_prop = fdt_getprop(initial_boot_params, root_offset,
+   #size-cells, NULL);
+   if (size_prop)
+   nr_size_cells = fdt32_to_cpu(*size_prop);
+
+   cell_size = sizeof(uint32_t)*(nr_address_cells + nr_size_cells);
+
+   memory = fdt_path_offset(initial_boot_params, /memory);
+   if (memory  0) {
+   val = fdt_getprop(initial_boot_params, memory, reg, len);
+   if (len  limit*cell_size) {
+   len = limit*cell_size;
+   pr_debug(Limiting number of entries to %d\n, limit);
+   fdt_setprop(initial_boot_params, memory, reg, val,
+   len);
+   }
+   }
+}
+
 /**
  * of_fdt_is_compatible - Return true if given node from the given blob has
  * compat in its compatible list
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index d600993..1aea25c 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -86,6 +86,7 @@ extern void unflatten_and_copy_device_tree(void);
 extern void early_init_devtree(void *);
 extern void early_get_first_memblock_info(void *, phys_addr_t *);
 extern u64 fdt_translate_address(const void *blob, int node_offset);
+extern void of_fdt_limit_memory(int limit);
 #else /* CONFIG_OF_FLATTREE */
 static inline void early_init_fdt_scan_reserved_mem(void) {}
 static inline const char *of_flat_dt_get_machine_name(void) { return NULL; }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
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/3] of: Split early_init_dt_scan into two parts

[Laura Abbott]

Currently, early_init_dt_scan validates the header, sets the
boot params, and scans for chosen/memory all in one function.
Split this up into two separate functions (validation/setting
boot params in one, scanning in another) to allow for
additional setup between boot params and scanning the memory.

Signed-off-by: Laura Abbott lau...@codeaurora.org
---
 drivers/of/fdt.c   | 18 +-
 include/linux/of_fdt.h |  2 ++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c4cddf0..55bfca9 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -922,7 +922,7 @@ int __init __weak 
early_init_dt_reserve_memory_arch(phys_addr_t base,
 }
 #endif
 
-bool __init early_init_dt_scan(void *params)
+bool __init early_init_dt_verify(void *params)
 {
if (!params)
return false;
@@ -936,6 +936,12 @@ bool __init early_init_dt_scan(void *params)
return false;
}
 
+   return true;
+}
+
+
+void __init early_init_dt_scan_all(void)
+{
/* Retrieve various information from the /chosen node */
of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
 
@@ -944,7 +950,17 @@ bool __init early_init_dt_scan(void *params)
 
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
+}
+
+bool __init early_init_dt_scan(void *params)
+{
+   bool status;
+
+   status = early_init_dt_verify(params);
+   if (!status)
+   return false;
 
+   early_init_dt_scan_all();
return true;
 }
 
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 0511789..d600993 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -73,6 +73,8 @@ extern int early_init_dt_scan_root(unsigned long node, const 
char *uname,
   int depth, void *data);
 
 extern bool early_init_dt_scan(void *params);
+extern bool early_init_dt_verify(void *params);
+extern void early_init_dt_scan_all(void);
 
 extern const char *of_flat_dt_get_machine_name(void);
 extern const void *of_flat_dt_match_machine(const void *default_match,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
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/3] arm: Add devicetree fixup machine function

[Laura Abbott]

Commit 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76
(ARM: 8025/1: Get rid of meminfo) dropped the upper bound on
the number of memory banks that can be added as there was no
technical need in the kernel. It turns out though, some bootloaders
(specifically the arndale-octa exynos boards) may pass invalid memory
information and rely on the kernel to not parse this data. This is a
bug in the bootloader but we still need to work around this.
Work around this by introducing a dt_fixup function. This function
gets called before the flattened devicetree is scanned for memory
and the like. In this fixup function for exynos, limit the maximum
number of memory regions in the devicetree.

Signed-off-by: Laura Abbott lau...@codeaurora.org
---
 arch/arm/include/asm/mach/arch.h |  1 +
 arch/arm/kernel/devtree.c|  7 ++-
 arch/arm/mach-exynos/exynos.c| 10 ++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 060a75e..0406cb3 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -50,6 +50,7 @@ struct machine_desc {
struct smp_operations   *smp;   /* SMP operations   */
bool(*smp_init)(void);
void(*fixup)(struct tag *, char **);
+   void(*dt_fixup)(void);
void(*init_meminfo)(void);
void(*reserve)(void);/* reserve mem blocks  */
void(*map_io)(void);/* IO mapping function  */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index e94a157..893db60 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -212,7 +212,7 @@ const struct machine_desc * __init 
setup_machine_fdt(unsigned int dt_phys)
mdesc_best = __mach_desc_GENERIC_DT;
 #endif
 
-   if (!dt_phys || !early_init_dt_scan(phys_to_virt(dt_phys)))
+   if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
return NULL;
 
mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
@@ -237,6 +237,11 @@ const struct machine_desc * __init 
setup_machine_fdt(unsigned int dt_phys)
dump_machine_table(); /* does not return */
}
 
+   if (mdesc-dt_fixup)
+   mdesc-dt_fixup();
+
+   early_init_dt_scan_all();
+
/* Change machine number to match the mdesc we're using */
__machine_arch_type = mdesc-nr;
 
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index f38cf7c..5a7b5c3 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -337,6 +337,15 @@ static void __init exynos_reserve(void)
 #endif
 }
 
+static void __init exynos_dt_fixup(void)
+{
+   /*
+* Some versions of uboot pass garbage entries in the memory node,
+* use the old CONFIG_ARM_NR_BANKS
+*/
+   of_fdt_limit_memory(8);
+}
+
 DT_MACHINE_START(EXYNOS_DT, SAMSUNG EXYNOS (Flattened Device Tree))
/* Maintainer: Thomas Abraham thomas.abra...@linaro.org */
/* Maintainer: Kukjin Kim kgene@samsung.com */
@@ -350,4 +359,5 @@ DT_MACHINE_START(EXYNOS_DT, SAMSUNG EXYNOS (Flattened 
Device Tree))
.dt_compat  = exynos_dt_compat,
.restart= exynos_restart,
.reserve= exynos_reserve,
+   .dt_fixup   = exynos_dt_fixup,
 MACHINE_END
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
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] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250

[Sachin Kamat]

On Wed, Jul 2, 2014 at 5:22 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
 On 07/01/2014 01:10 PM, Sachin Kamat wrote:
 Hi Chanwoo,

 On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
 Hi Sachin,

 On 07/01/2014 12:33 PM, Sachin Kamat wrote:
 Hi Chanwoo,

 On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
 This patch add TMU (Thermal Management Unit) dt node to monitor the high
 temperature for Exynos3250.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 This patch has a dependency on following patch [1]:
  [1] https://lkml.org/lkml/2014/6/30/805

  arch/arm/boot/dts/exynos3250.dtsi | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
 b/arch/arm/boot/dts/exynos3250.dtsi
 index 3660cab..1e566af 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -192,6 +192,16 @@
 status = disabled;
 };

 +   tmu: tmu@100C {
 +   compatible = samsung,exynos3250-tmu;
 +   interrupt-parent = gic;
 +   reg = 0x100C 0x100;
 +   interrupts = 0 216 0;
 +   clocks = cmu CLK_TMU_APBIF;
 +   clock-names = tmu_apbif;
 +   status = disabled;

 I don't think there would be any board specific properties needed. Hence
 leave the status as enabled (by deleting the above line).


 I think that if specific board need TMU feature, dts file for specific board
 should include tmu dt node with 'okay' status. The specific board based on
 Exynos3250 might not need TMU feature.

 The status field in DT node is not meant for stating the build configuration 
 but
 represents the readiness of the hardware for usage on the platform. If
 a particular
 board does not need this feature it needs to be disabled in the build
 config and only
 for any special requirements disable it in board file.

 TMU (Thermal Management Unit) needs specific regulator for TMU power as 
 following:
 The regulator for TMU is dependent on board.

In this case it makes sense to leave it disabled in dtsi.

-- 
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

Re: [PATCH 0/2] cpuidle fixes and cleanup

[Chander Kashyap]

On Tue, Jul 1, 2014 at 8:22 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Tue, Jul 01, 2014 at 08:02:36PM +0530, Chander Kashyap wrote:
 This patch series fixes the cpuidle for different states. Also removes arm
 diagnostic and power register save/restore code as it is made generic.

 Based on:
 ARM: save/restore diagnostic register on Cortex-A9 suspend/resume
  http://www.spinics.net/lists/arm-kernel/msg340506.html

 As there is an outstanding issue with this patch, we can't proceed with
 this set of changes until we know what's going on there.

Sure, I will wait for the conclusion.


 Also, bear in mind that I have changes which conflict with this in my
 tree (which I've just updated.)

I will resend after your changes are posted.

Thanks

 --
 FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
 improving, and getting towards what was expected from it.
 --
 To unsubscribe from this list: send the line unsubscribe linux-pm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

[Nicolas Pitre]

On Tue, 1 Jul 2014, Will Deacon wrote:

 Hi Mans,
 
 On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
  Russell King - ARM Linux li...@arm.linux.org.uk writes:
   As you point out, bx lr /may/ be treated specially (I've actually been
  
  Most, if not all, Cortex-A cores do this according the public TRMs.
  They also do the same thing for mov pc, lr so there will probably be
  no performance gain from this change.  It's still a good idea though,
  since we don't know what future cores will do.
 
 Funnily enough, that's not actually true (and is more or less what prompted
 this patch after discussion with Russell). There are cores out there that
 don't predict mov pc, lr at all (let alone do anything with the return
 stack).
 
   discussing this with Will Deacon over the last couple of days, who has
   also been talking to the hardware people in ARM, and Will is happy with
   this patch as in its current form.)  This is why I've changed all
   mov pc, reg instructions which return in some way to use this macro,
   and left others (those which are used to call some function and return
   back to the same point) alone.
  
  In that case the patch should be fine.  Your patch description didn't
  make it clear that only actual returns were being changed.
 
 I'm led to believe that some predictors require lr in order to update the
 return stack, whilst others don't. That part is all horribly
 micro-architectural, so the current patch is doing the right thing by
 sticking to the ARM ARM but enabling us to hook into other registers later
 on if we choose.

May I suggest to have a patch with only the macro definition in it and 
all this discussion in the commit log please?  The usage sites should be 
done in a separate patch to make it clearer.


Nicolas

Re: [RFC 0/4] ARM: dts: exynos: Prepare Spring

[Andreas Färber]

Am 23.06.2014 23:24, schrieb Andreas Färber:
 Am 23.06.2014 22:11, schrieb Benson Leung:
 On Mon, Jun 23, 2014 at 12:57 PM, Doug Anderson diand...@chromium.org 
 wrote:
 Also when the screen stayed on, the embedded controller's keymap seems
 hardcoded to US English with system settings not taking effect; but
 surely we don't want per-keyboard device tree files to remedy that.

 +Benson may be able to answer this.  I believe generally non-US
 keyboard layouts are handled at a higher level.

 There's no such thing as a notion of US versus non-US keyboard layouts
 at the embedded controller level or even in the kernel. Indeed, this
 should all be handled in user space.

 The chromeos firmware and kernel should return the correct key codes
 for every key pressed on keyboards with the ANSI layout (US based), or
 ISO (UK and most other countries).

 The only differences are :
 * the ISO keyboard has an extra key, which is immediately to the right
 of the Left Shift key. This must return KEY_102ND key code from the
 input layer.
 * the ISO keyboard has a  different location for the | \ key, which
 accomodates the upside L shaped Enter key on the right side of the
 keyboard. The keycode for this key is KEY_BACKSLASH.

 Basically, all of this should be verified using evtest to test that
 the ec and kernel have the keys right.
 
 Hm, we may be talking about two different things here? I have been doing
 a minimum system bring-up for 3.16, with openSUSE userspace.
 My YaST-selected system keymap (German with deadkeys) is not taking
 effect on German Spring at the *framebuffer console* (tty1) - evdev is
 not involved at that level AIUI.
 
 Backspace and L-shaped enter keys work okay. The keymap here should be
 identical to that in the original German device and seemed to match that
 in the exynos5250-snow.dts file.
 
 I just checked (w/ dp-controller, hdmi, fimd commented out in my patch):
 * An external USB keyboard does not work correctly either.
 * In X11 (xdm), both internal and USB keyboard work as expected.

Another observation: Ctrl+o does not work on the Chromebook keyboard,
whereas o and Shift+o or Ctrl+x do work as expected. On an external USB
keyboard it works just fine. Same at the console and in X11.

Testcases are nano (saving) and gEdit (opening).

I tried the new cros-ec-keyboard.dtsi, no change; and given that the key
itself works okay, I assume it's not the dt linux,keymap.

Anyone any suggestion how to debug?

Thanks,
Andreas

 Similar situation in ChromeOS IIRC, with keymap correct at graphical
 login but not on the right-arrow console - although I don't know the
 ChromeOS userland too well to judge if it was configured correctly.
 
 If you are having other problems with keyboard layout being stuck to
 US QWERTY, please check your user space.
 
 On my Raspberry Pi for instance, the equivalent openSUSE Factory works
 just fine with German keymap for USB keyboard. Might any related kernel
 config options be missing in exynos_defconfig? Anything in particular I
 should check in user space?
 
 Cheers,
 Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250

[Chanwoo Choi]

Hi Sachin,

On 07/02/2014 12:09 PM, Sachin Kamat wrote:
 On Wed, Jul 2, 2014 at 5:22 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
 On 07/01/2014 01:10 PM, Sachin Kamat wrote:
 Hi Chanwoo,

 On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
 Hi Sachin,

 On 07/01/2014 12:33 PM, Sachin Kamat wrote:
 Hi Chanwoo,

 On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi cw00.c...@samsung.com 
 wrote:
 This patch add TMU (Thermal Management Unit) dt node to monitor the high
 temperature for Exynos3250.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 This patch has a dependency on following patch [1]:
  [1] https://lkml.org/lkml/2014/6/30/805

  arch/arm/boot/dts/exynos3250.dtsi | 10 ++
  1 file changed, 10 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
 b/arch/arm/boot/dts/exynos3250.dtsi
 index 3660cab..1e566af 100644
 --- a/arch/arm/boot/dts/exynos3250.dtsi
 +++ b/arch/arm/boot/dts/exynos3250.dtsi
 @@ -192,6 +192,16 @@
 status = disabled;
 };

 +   tmu: tmu@100C {
 +   compatible = samsung,exynos3250-tmu;
 +   interrupt-parent = gic;
 +   reg = 0x100C 0x100;
 +   interrupts = 0 216 0;
 +   clocks = cmu CLK_TMU_APBIF;
 +   clock-names = tmu_apbif;
 +   status = disabled;

 I don't think there would be any board specific properties needed. Hence
 leave the status as enabled (by deleting the above line).


 I think that if specific board need TMU feature, dts file for specific 
 board
 should include tmu dt node with 'okay' status. The specific board based on
 Exynos3250 might not need TMU feature.

 The status field in DT node is not meant for stating the build 
 configuration but
 represents the readiness of the hardware for usage on the platform. If
 a particular
 board does not need this feature it needs to be disabled in the build
 config and only
 for any special requirements disable it in board file.

 TMU (Thermal Management Unit) needs specific regulator for TMU power as 
 following:
 The regulator for TMU is dependent on board.
 
 In this case it makes sense to leave it disabled in dtsi.
 

Thanks for your review.

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] ARM: dts: Remove outdated usb2 phy entry from exynos5250.dtsi

[Andreas Färber]

+ kgene, devicetree

Am 27.06.2014 17:04, schrieb Sjoerd Simons:
 The exynos5250.dtsi has two entries for describing the usb2 phy. One for
 the newer driver using the generic PHY framework and one for its
 predecessor. The older node is only referenced by the arndale dts, which
 seems redundant given starting from dba2f05880c the common dtsi also
 includes the phy entries.
 
 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5250-arndale.dts |  4 
  arch/arm/boot/dts/exynos5250.dtsi| 15 ---
  2 files changed, 19 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
 b/arch/arm/boot/dts/exynos5250-arndale.dts
 index d0de1f5..dad8f9b 100644
 --- a/arch/arm/boot/dts/exynos5250-arndale.dts
 +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
 @@ -570,8 +570,4 @@
   connect-gpios = gpd1 7 1;
   };
   };
 -
 - usb@1211 {
 - usb-phy = usb2_phy;
 - };
  };
 diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
 b/arch/arm/boot/dts/exynos5250.dtsi
 index 834fb5a..7c545d50 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -600,21 +600,6 @@
   };
   };
  
 - usb2_phy: usbphy@1213 {
 - compatible = samsung,exynos5250-usb2phy;
 - reg = 0x1213 0x100;
 - clocks = clock CLK_FIN_PLL, clock CLK_USB2;
 - clock-names = ext_xtal, usbhost;
 - #address-cells = 1;
 - #size-cells = 1;
 - ranges;
 -
 - usbphy-sys {
 - reg = 0x10040704 0x8,
 -   0x10050230 0x4;
 - };
 - };
 -
   usb2_phy_gen: phy@1213 {
   compatible = samsung,exynos5250-usb2-phy;
   reg = 0x1213 0x100;

I've stumbled over the same duplication in the .dtsi, LGTM,

Reviewed-by: Andreas Färber afaer...@suse.de

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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