Re: [PATCH] ARM: dts: add board dts file for Exynos3250-based Monk board
+ Adding ARM maintainers.
I know it's too late. just to know we trying to push product board
support at mainline.
Thank you,
Kyungmin Park
On Thu, Oct 2, 2014 at 9:50 AM, YoungJun Cho yj44@samsung.com wrote:
From: Youngjun Cho yj44@samsung.com
This patch adds new board dts file to support Samsung Monk board which is
based on Exynos3250 SoC and has different H/W configuration from Rinato.
This patch is based on linux-samsung.git for-next branch and depends on
[PATCH 0/2] ARM: dts: Add new board dts file for Exynos3250-based Rinato
board[1]
This dts file support following features:
- eMMC
- Main PMIC (Samsung S2MPS14)
- Interface PMIC (Maxim MAX77836, MUIC, fuel-gauge, charger)
- RTC of Exynos3250
- ADC of Exynos3250 with NTC thermistor
- I2S of Exynos3250
- TMU of Exynos3250
- Secure firmware for Exynos3250 secondary cpu boot
- Serial ports of Exynos3250
- gpio-key for power key
[1] http://www.spinics.net/lists/arm-kernel/msg366849.html
Signed-off-by: Youngjun Cho yj44@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/Makefile| 3 +-
arch/arm/boot/dts/exynos3250-monk.dts | 592
++
2 files changed, 594 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/exynos3250-monk.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5728918..0c8ae64 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -64,7 +64,8 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
-dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-rinato.dtb \
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-monk.dtb \
+ exynos3250-rinato.dtb \
exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
new file mode 100644
index 000..9e94294
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -0,0 +1,592 @@
+/*
+ * Samsung's Exynos3250 based Monk board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Device tree source file for Samsung's Monk board which is based on
+ * Samsung Exynos3250 SoC.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include exynos3250.dtsi
+#include dt-bindings/input/input.h
+
+/ {
+ model = Samsung Monk board;
+ compatible = samsung,monk, samsung,exynos3250, samsung,exynos3;
+
+ aliases {
+ i2c7 = i2c_max77836;
+ };
+
+ memory {
+ reg = 0x4000 0x0800
+ 0x4800 0x0800
+ 0x5000 0x0800
+ 0x5800 0x07F0;
+ };
+
+ chosen {
+ bootargs = console=ttySAC1,115200N8 root=/dev/mmcblk0p15
rootwait earlyprintk panic=5;
+ };
+
+ firmware@0205F000 {
+ compatible = samsung,secure-firmware;
+ reg = 0x0205F000 0x1000;
+ } ;
+
+ gpio_keys {
+ compatible = gpio-keys;
+
+ power_key {
+ interrupt-parent = gpx2;
+ interrupts = 7 0;
+ gpios = gpx2 7 1;
+ linux,code = KEY_POWER;
+ label = power key;
+ debounce-interval = 10;
+ gpio-key,wakeup;
+ };
+ };
+
+ regulators {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ vemmc_reg: voltage-regulator-0 {
+ compatible = regulator-fixed;
+ regulator-name = V_EMMC_2.8V-fixed;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ gpio = gpk0 2 0;
+ enable-active-high;
+ };
+ };
+
+ i2c_max77836: i2c-gpio-0 {
+ compatible = i2c-gpio;
+ gpios = gpd0 2 0, gpd0 3 0;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ max77836: subpmic@25 {
+ compatible = maxim,max77836;
+ interrupt-parent = gpx1;
+ interrupts = 5 0
Re: [PATCH 0/2] ARM: dts: Add new board dts file for Exynos3250-based Rinato board
+ ARM maintainers. It's Gear 2 board support. Thank you, Kyungmin Park On Tue, Sep 30, 2014 at 8:07 PM, Chanwoo Choi cw00.c...@samsung.com wrote: This patchset adds new board dts file for Samsung Rinato board (Gear 2) which is based on Exynos3250 SoC and adds sleep mode pin configuration using pinctrl subsystem to reduce leakage power-consumption in sleep state. This patchset is based on linux-samsung.git (for-next branch). Chanwoo Choi (2): ARM: dts: Add board dts file for Exynos3250-based Rinato board ARM: dts: Add sleep mode pin configuration for exynos3250-rinato arch/arm/boot/dts/Makefile| 3 +- arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 16 + arch/arm/boot/dts/exynos3250-rinato.dts | 595 ++ 3 files changed, 613 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/exynos3250-rinato.dts -- 1.8.0 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related clocks
On Mon, Sep 29, 2014 at 4:22 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
Hi,
On Monday, September 29, 2014 9:07 AM, Kyungmin Park wrote,
To: Pankaj Dubey
Cc: Chanwoo Choi; Kukjin Kim; Russell King - ARM Linux;
naus...@samsung.com;
Tomasz Figa; linux-samsung-soc; robh...@kernel.org; Sylwester Nawrocki;
Mike
Turquette; arm-linux
Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related
clocks
On Mon, Sep 29, 2014 at 11:47 AM, Pankaj Dubey pankaj.du...@samsung.com
wrote:
Hi Chanwoo,
On Monday, September 29, 2014 7:42 AM, Chanwoo Choi wrote,
To: Pankaj Dubey
Cc: linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org;
kgene@samsung.com; tomasz.f...@gmail.com; robh...@kernel.org;
li...@arm.linux.org.uk; naus...@samsung.com; Mike Turquette;
Sylwester Nawrocki
Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3
related
clocks
Hi Pankaj,
On 09/27/2014 01:58 PM, Pankaj Dubey wrote:
Exynos3250 has four UART channels UART0,1,2 and 3. This patch adds
missing clock entries for UART2 and UART3.
CC: Mike Turquette mturque...@linaro.org
CC: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
drivers/clk/samsung/clk-exynos3250.c | 11 +++
include/dt-bindings/clock/exynos3250.h | 10 +-
2 files changed, 20 insertions(+), 1 deletion(-)
Exynos3250 has only two UART(0,1) port. Exynos3250 don't support UART
2,3.
As per Exynos3250 user manual that I have with me it supports
UART(0,1,2,3).
It has been mentioned
which UM do you use? There are two UARTs at rev0.01
I am using Rev 2.0.
I received the latest manual from LSI. but it's still v1.40.
Thanks,
Pankaj Dubey
in UART Chapter as well as CMU IP details also mentioned about the
clock entries. We have tested it also on Espresso3250 board which is
based on Exynos3250 SoC.
I can't find it at my UM.
Kyungmin Park
Thanks,
Pankaj Dubey
Thanks,
Chanwoo Choi
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index dc85f8e..0722fef 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -357,6 +357,8 @@ static struct samsung_mux_clock mux_clks[]
__initdata =
{
MUX(CLK_MOUT_MMC0, mout_mmc0, group_sclk_p, SRC_FSYS, 0,
3),
/* SRC_PERIL0 */
+ MUX(CLK_MOUT_UART3, mout_uart3, group_sclk_p, SRC_PERIL0,
12, 4),
+ MUX(CLK_MOUT_UART2, mout_uart2, group_sclk_p, SRC_PERIL0,
8,
4),
MUX(CLK_MOUT_UART1, mout_uart1, group_sclk_p, SRC_PERIL0,
4,
4),
MUX(CLK_MOUT_UART0, mout_uart0, group_sclk_p, SRC_PERIL0,
0,
4),
@@ -439,6 +441,8 @@ static struct samsung_div_clock div_clks[]
__initdata = {
DIV(CLK_DIV_MMC0, div_mmc0, mout_mmc0, DIV_FSYS1, 0, 4),
/* DIV_PERIL0 */
+ DIV(CLK_DIV_UART3, div_uart3, mout_uart3, DIV_PERIL0, 12,
4),
+ DIV(CLK_DIV_UART2, div_uart2, mout_uart2, DIV_PERIL0, 8,
+ 4),
DIV(CLK_DIV_UART1, div_uart1, mout_uart1, DIV_PERIL0, 4, 4),
DIV(CLK_DIV_UART0, div_uart0, mout_uart0, DIV_PERIL0, 0,
4),
@@ -601,6 +605,10 @@ static struct samsung_gate_clock gate_clks[]
__initdata
= {
GATE_SCLK_PERIL, 7, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_SPI0, sclk_spi0, div_spi0_pre,
GATE_SCLK_PERIL, 6, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UART3, sclk_uart3, div_uart3,
+ GATE_SCLK_PERIL, 3, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UART2, sclk_uart2, div_uart2,
+ GATE_SCLK_PERIL, 2, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART1, sclk_uart1, div_uart1,
GATE_SCLK_PERIL, 1, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART0, sclk_uart0, div_uart0, @@ -679,6
+687,7
@@
static struct samsung_gate_clock gate_clks[] __initdata = {
GATE(CLK_USBOTG, usbotg, div_aclk_200, GATE_IP_FSYS, 13,
0,
0),
GATE(CLK_USBHOST, usbhost, div_aclk_200, GATE_IP_FSYS, 12,
0, 0),
GATE(CLK_SROMC, sromc, div_aclk_200, GATE_IP_FSYS, 11, 0,
0),
+ GATE(CLK_SDMMC2, sdmmc2, div_aclk_200, GATE_IP_FSYS, 7,
0,
0),
GATE(CLK_SDMMC1, sdmmc1, div_aclk_200, GATE_IP_FSYS, 6,
0,
0),
GATE(CLK_SDMMC0, sdmmc0, div_aclk_200, GATE_IP_FSYS, 5,
0,
0),
GATE(CLK_PDMA1, pdma1, div_aclk_200, GATE_IP_FSYS, 1, 0,
0),
@@
-698,6 +707,8 @@ static struct samsung_gate_clock gate_clks[]
__initdata
= {
GATE(CLK_I2C2, i2c2, div_aclk_100, GATE_IP_PERIL, 8, 0, 0),
GATE(CLK_I2C1, i2c1, div_aclk_100, GATE_IP_PERIL, 7, 0, 0),
GATE(CLK_I2C0, i2c0, div_aclk_100, GATE_IP_PERIL, 6, 0, 0),
+ GATE(CLK_UART3, uart3, div_aclk_100, GATE_IP_PERIL, 3, 0,
0),
+ GATE(CLK_UART2, uart2, div_aclk_100, GATE_IP_PERIL, 2, 0,
+ 0),
GATE(CLK_UART1, uart1, div_aclk_100, GATE_IP_PERIL, 1, 0, 0),
GATE(CLK_UART0, uart0
Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related clocks
On Mon, Sep 29, 2014 at 11:47 AM, Pankaj Dubey pankaj.du...@samsung.com wrote:
Hi Chanwoo,
On Monday, September 29, 2014 7:42 AM, Chanwoo Choi wrote,
To: Pankaj Dubey
Cc: linux-arm-ker...@lists.infradead.org;
linux-samsung-soc@vger.kernel.org;
kgene@samsung.com; tomasz.f...@gmail.com; robh...@kernel.org;
li...@arm.linux.org.uk; naus...@samsung.com; Mike Turquette; Sylwester
Nawrocki
Subject: Re: [PATCH 1/2] clk: samsung: exynos3250: add uart2/3 related
clocks
Hi Pankaj,
On 09/27/2014 01:58 PM, Pankaj Dubey wrote:
Exynos3250 has four UART channels UART0,1,2 and 3. This patch adds
missing clock entries for UART2 and UART3.
CC: Mike Turquette mturque...@linaro.org
CC: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
drivers/clk/samsung/clk-exynos3250.c | 11 +++
include/dt-bindings/clock/exynos3250.h | 10 +-
2 files changed, 20 insertions(+), 1 deletion(-)
Exynos3250 has only two UART(0,1) port. Exynos3250 don't support UART 2,3.
As per Exynos3250 user manual that I have with me it supports UART(0,1,2,3).
It has been mentioned
which UM do you use? There are two UARTs at rev0.01
in UART Chapter as well as CMU IP details also mentioned about the clock
entries. We have tested it
also on Espresso3250 board which is based on Exynos3250 SoC.
I can't find it at my UM.
Kyungmin Park
Thanks,
Pankaj Dubey
Thanks,
Chanwoo Choi
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index dc85f8e..0722fef 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -357,6 +357,8 @@ static struct samsung_mux_clock mux_clks[]
__initdata =
{
MUX(CLK_MOUT_MMC0, mout_mmc0, group_sclk_p, SRC_FSYS, 0, 3),
/* SRC_PERIL0 */
+ MUX(CLK_MOUT_UART3, mout_uart3, group_sclk_p, SRC_PERIL0,
12, 4),
+ MUX(CLK_MOUT_UART2, mout_uart2, group_sclk_p, SRC_PERIL0, 8,
4),
MUX(CLK_MOUT_UART1, mout_uart1, group_sclk_p, SRC_PERIL0, 4,
4),
MUX(CLK_MOUT_UART0, mout_uart0, group_sclk_p, SRC_PERIL0, 0,
4),
@@ -439,6 +441,8 @@ static struct samsung_div_clock div_clks[]
__initdata = {
DIV(CLK_DIV_MMC0, div_mmc0, mout_mmc0, DIV_FSYS1, 0, 4),
/* DIV_PERIL0 */
+ DIV(CLK_DIV_UART3, div_uart3, mout_uart3, DIV_PERIL0, 12, 4),
+ DIV(CLK_DIV_UART2, div_uart2, mout_uart2, DIV_PERIL0, 8, 4),
DIV(CLK_DIV_UART1, div_uart1, mout_uart1, DIV_PERIL0, 4, 4),
DIV(CLK_DIV_UART0, div_uart0, mout_uart0, DIV_PERIL0, 0, 4),
@@ -601,6 +605,10 @@ static struct samsung_gate_clock gate_clks[]
__initdata
= {
GATE_SCLK_PERIL, 7, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_SPI0, sclk_spi0, div_spi0_pre,
GATE_SCLK_PERIL, 6, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UART3, sclk_uart3, div_uart3,
+ GATE_SCLK_PERIL, 3, CLK_SET_RATE_PARENT, 0),
+ GATE(CLK_SCLK_UART2, sclk_uart2, div_uart2,
+ GATE_SCLK_PERIL, 2, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART1, sclk_uart1, div_uart1,
GATE_SCLK_PERIL, 1, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_UART0, sclk_uart0, div_uart0, @@ -679,6 +687,7
@@
static struct samsung_gate_clock gate_clks[] __initdata = {
GATE(CLK_USBOTG, usbotg, div_aclk_200, GATE_IP_FSYS, 13, 0,
0),
GATE(CLK_USBHOST, usbhost, div_aclk_200, GATE_IP_FSYS, 12,
0, 0),
GATE(CLK_SROMC, sromc, div_aclk_200, GATE_IP_FSYS, 11, 0, 0),
+ GATE(CLK_SDMMC2, sdmmc2, div_aclk_200, GATE_IP_FSYS, 7, 0,
0),
GATE(CLK_SDMMC1, sdmmc1, div_aclk_200, GATE_IP_FSYS, 6, 0,
0),
GATE(CLK_SDMMC0, sdmmc0, div_aclk_200, GATE_IP_FSYS, 5, 0,
0),
GATE(CLK_PDMA1, pdma1, div_aclk_200, GATE_IP_FSYS, 1, 0, 0),
@@
-698,6 +707,8 @@ static struct samsung_gate_clock gate_clks[] __initdata
= {
GATE(CLK_I2C2, i2c2, div_aclk_100, GATE_IP_PERIL, 8, 0, 0),
GATE(CLK_I2C1, i2c1, div_aclk_100, GATE_IP_PERIL, 7, 0, 0),
GATE(CLK_I2C0, i2c0, div_aclk_100, GATE_IP_PERIL, 6, 0, 0),
+ GATE(CLK_UART3, uart3, div_aclk_100, GATE_IP_PERIL, 3, 0, 0),
+ GATE(CLK_UART2, uart2, div_aclk_100, GATE_IP_PERIL, 2, 0, 0),
GATE(CLK_UART1, uart1, div_aclk_100, GATE_IP_PERIL, 1, 0, 0),
GATE(CLK_UART0, uart0, div_aclk_100, GATE_IP_PERIL, 0, 0, 0),
}; diff --git a/include/dt-bindings/clock/exynos3250.h
b/include/dt-bindings/clock/exynos3250.h
index b535e9d..ffeb695 100644
--- a/include/dt-bindings/clock/exynos3250.h
+++ b/include/dt-bindings/clock/exynos3250.h
@@ -78,6 +78,8 @@
#define CLK_MOUT_CORE 58
#define CLK_MOUT_APLL 59
#define CLK_MOUT_ACLK_266_SUB 60
+#define CLK_MOUT_UART2 61
+#define CLK_MOUT_UART3 62
/* Dividers */
#define CLK_DIV_GPL64
@@ -126,6 +128,8 @@
#define CLK_DIV_CORE 107
#define
Re: [PATCH] drm/exynos: fix nested calls to lock mutex in drm resume
add Mr. Dae On Thu, May 22, 2014 at 11:16 PM, Rahul Sharma rahul.sha...@samsung.com wrote: Hi Inki, This is another one which has not got reviewed. Please review. Regards, Rahul Sharma On 30 April 2014 19:11, Rahul Sharma rahul.sha...@samsung.com wrote: From: Rahul Sharma rahul.sha...@samsung.com While testing S2R on exynos board, system is hanging and rebooting due to nested mutex_lock calls in exynos drm resume callback. Changing the order of the calls is fixing the issue. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- Based on exynos-drm-next branch in Inki Dae's tree. drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index bb7dfee..2bb6233 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -184,8 +184,8 @@ static int exynos_drm_resume(struct drm_device *dev) connector-funcs-dpms(connector, connector-dpms); } - drm_helper_resume_force_mode(dev); drm_modeset_unlock_all(dev); + drm_helper_resume_force_mode(dev); return 0; } -- 1.7.9.5 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12
On Sat, Mar 15, 2014 at 2:35 AM, Tomasz Figa t.f...@samsung.com wrote: Hi Chanwoo, Mark, On 14.03.2014 11:56, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 07:35 PM, Mark Rutland wrote: On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 02:53 AM, Mark Rutland wrote: On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote: This patch add busfreq driver for Exynos4210/Exynos4x12 memory interface and bus to support DVFS(Dynamic Voltage Frequency Scaling) according to PPMU counters. PPMU (Performance Profiling Monitorings Units) of Exynos4 SoC provides PPMU counters for DMC(Dynamic Memory Controller) to check memory bus utilization and then busfreq driver adjusts dynamically the operating frequency/voltage by using DEVFREQ Subsystem. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com --- .../devicetree/bindings/devfreq/exynos4_bus.txt| 49 ++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/exynos4_bus.txt diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt new file mode 100644 index 000..2a83fcc --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt @@ -0,0 +1,49 @@ + +Exynos4210/4x12 busfreq driver +- + +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus frequency/voltage +scaling according to PPMU counters of memory controllers + +Required properties: +- compatible : should contain Exynos4 SoC type as follwoing: + - samsung,exynos4x12-busfreq for Exynos4x12 + - samsung,exynos4210-busfreq for Exynos4210 Is there a device called busfreq? What device does this binding describe? I'll add detailed description of busfreq as following: busfreq(bus frequendcy) driver means that busfreq driver control dynamically memory bus frequency/voltage by checking memory bus utilization to optimize power-consumption. When checking memeory bus utilization, exynos4_busfreq driver would use PPMU(Performance Profiling Monitoring Units). This still sounds like a description of the _driver_, not the _device_. The binding should describe the hardware, now the high level abstraction that software is going to build atop of it. It sounds like this is a binding for the DMC PPMU? Is the PPMU a component of the DMC, or is it bolted on the side? PPMU(Performance Profiling Monitoring Unit) is to profile performance event of various IP on Exynos4. Each PPMU provide perforamnce event for each IP. We can check various PPMU as following: PPMU_3D PPMU_ACP PPMU_CAMIF PPMU_CPU PPMU_DMC0 PPMU_DMC1 PPMU_FSYS PPMU_IMAGE PPMU_LCD0 PPMU_LCD1 PPMU_MFC_L PPMU_MFC_R PPMU_TV PPMU_LEFT_BUS PPMU_RIGHT_BUS DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4 SoC. If we need to get memory bust utilization of DMC, we can get memory bus utilization from PPMU_DMC0/PPMU_DMC1. So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various PPMU list. Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs. Busfreq/devfreq is just a Linux-specific abstraction responsible for collecting data using PPMUs and controlling frequencies and voltages of appropriate power planes, vdd_int responsible for powering DMC0 and DMC1 blocks in this case. I'm afraid that the binding you're proposing is unfortunately incorrect, because it represents the software abstraction, not the real hardware. Instead, this should be separated into several independent bindings: - PPMU bindings to list all the PPMU instances present in the SoC and resources they need, - power plane bindings, which define a power plane in which multiple IP blocks might reside, can be monitored by one or more PPMU units and frequency and voltage of which can be configured according to determined performance level. Needed resources will be clocks and regulators to scale and probably also operating points. Then, exynos-busfreq driver should bind to such power planes, parse necessary data from DT (list of PPMUs and IP blocks, clocks, regulators and operating points) and register a devfreq entity. How about to use component DT like DRM? Best regards, Tomasz -- 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] iommu/exynos: Remove driver
On Fri, Feb 14, 2014 at 9:17 AM, Cho KyongHo pullip@samsung.com wrote: -Original Message- From: Olof Johansson [mailto:o...@lixom.net] Sent: Friday, February 14, 2014 4:34 AM On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim kgene@gmail.com wrote: Just adding KyongHo Cho. If he can fixup for this time, it would be best solution because he knows well than others, I think. It's not so much a matter of fixup for this time, it's a about having ownership of the driver, making sure it works (and keeps working if there is related development). The posted patches have not been followed through on and the result is a broken driver. :( I definitely appreciate his expertise, and we should make sure that he gets to review the code, but if someone else is able to spend time on reworking the driver (or rewriting a newer one) and maintaining it longer-term, then we should not stop them from doing so. And there is no reason to keep broken stale code in the kernel meanwhile. Thank you for your concerning. I also definitely agree with you that the driver must work. I am always concerning about it but it was not easy to make some time for the patches. I will continue to post the next version of patches, of course. I think it is not far from now to show it. Lots of time is going from last reply. there are two options. 1. just waiting more 2. remove it as patch and start it again by someone. what's the opinions? Thank you, Kyungmin Park -- 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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 11:59 AM, Doug Anderson wrote: On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 10:15 AM, Tomasz Figa wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... I haven't followed all of the previous discussions, but I know I've run into scenarios where something like this would be useful. The one that comes to mind is: * We've got GPIOs that default at bootup to a pulled up input since the default state of the pin should be high. * These pins are really intended to be outputs, like an enable, reset, or power down line for a peripheral. The pullup is strong enough to give us a good default state but we really want outputs. * We'd like to provide this GPIO to a peripheral through device tree. ...and we'd like all the pinmux to be setup automatically so we use pinctrl-names = default. * If we set the pinmux up as output then there's a chance that the line will glitch at bootup since the pinmux happens (changing the pin to output) before the driver has a chance to run. I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. Thank you, Kyungmin Park the SoC's GPIO driver communicate with the pinctrl driver (which might be the same driver; not sure here) so that gpio_direction_output() causes the pinctrl HW to be programmed as output only after the GPIO HW is programmed as output and with the correct output value. In this scenario, the pinctrl default state wouldn't touch the pin's input/output setting; that operation would be deferred until the driver set up the GPIO as an output. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks
On Tue, Nov 5, 2013 at 5:04 PM, Tushar Behera tushar.beh...@linaro.org wrote:
On 5 November 2013 13:27, Kyungmin Park kmp...@infradead.org wrote:
On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera tushar.beh...@linaro.org
wrote:
On 31 October 2013 21:46, Lee Jones lee.jo...@linaro.org wrote:
On Thu, 31 Oct 2013, Tushar Behera wrote:
S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
supported by s2mps11-clk driver.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/sec-core.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 34c18fb..020b86b 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
.name = s5m8767-pmic,
}, {
.name = s5m-rtc,
- },
+ }, {
+ .name = s5m8767-clk,
Do you want to handle these as clock? previous time, it's
implemented at regulator. please see drivers/regulator/max* series.
Thank you,
Kyungmin Park
There is already a clock-implementation available for this kind of
device (through clk-s2mps11). I would like to extend that support.
Also for MAX77686, it is implemented through clock subsystem.
Yes it's possible, but losts of MAX chips are implemented already with
regulator.
but in case of maxim chip. it's voltage instead of clock. doesn't
better to use regulaor?
Ah I confused between 32KHz and Safeout. okay it's 32KHz clock. okay
it's better to use clock.
Ignore previous comments.
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks
On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera tushar.beh...@linaro.org wrote:
On 31 October 2013 21:46, Lee Jones lee.jo...@linaro.org wrote:
On Thu, 31 Oct 2013, Tushar Behera wrote:
S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
supported by s2mps11-clk driver.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/sec-core.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 34c18fb..020b86b 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
.name = s5m8767-pmic,
}, {
.name = s5m-rtc,
- },
+ }, {
+ .name = s5m8767-clk,
Do you want to handle these as clock? previous time, it's
implemented at regulator. please see drivers/regulator/max* series.
Thank you,
Kyungmin Park
+ }
};
static struct mfd_cell s2mps11_devs[] = {
Acked-by: Lee Jones lee.jo...@linaro.org
Thanks.
I'd prefer to take this patch in via the MFD tree once you have
support from the other maintainers for the set.
Ok. I will let you know once I get the clock patches through.
--
Tushar Behera
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
On Tue, Oct 15, 2013 at 3:23 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
on a fixed 66 MHz peripheral clock, and therefore is completely
independent of the cpu frequency.
Thus, registering for a CPU freq notifier is very wasteful.
This patch modifes the code such that, i2c bus registers to
cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
This change should save a bunch of cpufreq transitions calls
which does not apply to exynos SoCs.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v1:
Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ !CONFIG_EXYNOS)
As commented by Tomasz
drivers/i2c/busses/i2c-s3c2410.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index cab1c91..97f14f7 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -123,7 +123,7 @@ struct s3c24xx_i2c {
struct s3c2410_platform_i2c *pdata;
int gpios[2];
struct pinctrl *pctrl;
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_CPU_FREQ_S3C24XX)
struct notifier_block freq_transition;
#endif
};
@@ -843,7 +843,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c,
unsigned int *got)
return 0;
}
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_CPU_FREQ_S3C24XX)
#define freq_to_i2c(_n) container_of(_n, struct s3c24xx_i2c, freq_transition)
--
1.7.10.4
--
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 v2 1/2] MAINTAINERS: Add Samsung pinctrl entries
On Mon, Jun 17, 2013 at 7:17 AM, Doug Anderson diand...@chromium.org wrote: It's convenient if get_maintainer suggests sending samsung/exynos pinctrl changes to linux-samsung-soc and to Tomasz and Thomas. Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- Changes in v2: - Updated with Thomas and Tomasz; removed Linus since he's already there as part of the general pinctrl match. MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8d97b3e..f55e3c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6284,6 +6284,16 @@ L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: drivers/pinctrl/pinctrl-at91.c +PIN CONTROLLER - SAMSUNG +M: Tomasz Figa t.f...@samsung.com +M: Thomas Abraham thomas.abra...@linaro.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) +S: Maintained +F: drivers/pinctrl/pinctrl-exynos.* +F: drivers/pinctrl/pinctrl-s3c* +F: drivers/pinctrl/pinctrl-samsung.* + PIN CONTROLLER - ST SPEAR M: Viresh Kumar viresh.li...@gmail.com L: spear-de...@list.st.com -- 1.8.3 -- 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 02/30] ARM: exynos: prepare for sparse IRQ
On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann a...@arndb.de wrote: When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in the machine_desc for legacy IRQ domains, and any file referring to the number of interrupts or a specific number must include the mach/irqs.h header file explicitly. It's really wanted feature. Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/dev-uart.c | 1 + arch/arm/mach-exynos/include/mach/irqs.h | 5 - arch/arm/mach-exynos/mach-armlex4210.c | 2 ++ arch/arm/mach-exynos/mach-exynos4-dt.c | 3 +++ arch/arm/mach-exynos/mach-exynos5-dt.c | 2 ++ arch/arm/mach-exynos/mach-nuri.c | 2 ++ arch/arm/mach-exynos/mach-origen.c | 2 ++ arch/arm/mach-exynos/mach-smdk4x12.c | 2 ++ arch/arm/mach-exynos/mach-smdkv310.c | 3 +++ arch/arm/plat-samsung/irq-vic-timer.c| 1 + arch/arm/plat-samsung/pm.c | 1 + arch/arm/plat-samsung/s5p-irq.c | 1 + 12 files changed, 24 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c index 7c42f4b..c48aff0 100644 --- a/arch/arm/mach-exynos/dev-uart.c +++ b/arch/arm/mach-exynos/dev-uart.c @@ -20,6 +20,7 @@ #include asm/mach/irq.h #include mach/hardware.h #include mach/map.h +#include mach/irqs.h #include plat/devs.h diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h index 35fe6d5..c72f59d 100644 --- a/arch/arm/mach-exynos/include/mach/irqs.h +++ b/arch/arm/mach-exynos/include/mach/irqs.h @@ -467,7 +467,10 @@ #define IRQ_TIMER_BASE (IRQ_GPIO_END + 64) /* Set the default NR_IRQS */ +#define EXYNOS_NR_IRQS (IRQ_TIMER_BASE + IRQ_TIMER_COUNT) -#define NR_IRQS(IRQ_TIMER_BASE + IRQ_TIMER_COUNT) +#ifndef CONFIG_SPARSE_IRQ +#define NR_IRQSEXYNOS_NR_IRQS +#endif #endif /* __ASM_ARCH_IRQS_H */ diff --git a/arch/arm/mach-exynos/mach-armlex4210.c b/arch/arm/mach-exynos/mach-armlex4210.c index 2c23b65..a503e02 100644 --- a/arch/arm/mach-exynos/mach-armlex4210.c +++ b/arch/arm/mach-exynos/mach-armlex4210.c @@ -25,6 +25,7 @@ #include plat/regs-srom.h #include plat/sdhci.h +#include mach/irqs.h #include mach/map.h #include common.h @@ -196,6 +197,7 @@ static void __init armlex4210_machine_init(void) MACHINE_START(ARMLEX4210, ARMLEX4210) /* Maintainer: Alim Akhtar alim.akh...@samsung.com */ .atag_offset= 0x100, + .nr_irqs= EXYNOS_NR_IRQS, .smp= smp_ops(exynos_smp_ops), .init_irq = exynos4_init_irq, .map_io = armlex4210_map_io, diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c index b9ed834..5f23682 100644 --- a/arch/arm/mach-exynos/mach-exynos4-dt.c +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c @@ -20,6 +20,8 @@ #include asm/mach/arch.h #include plat/mfc.h +#include mach/irqs.h + #include common.h @@ -54,6 +56,7 @@ static void __init exynos4_reserve(void) } DT_MACHINE_START(EXYNOS4210_DT, Samsung Exynos4 (Flattened Device Tree)) /* Maintainer: Thomas Abraham thomas.abra...@linaro.org */ + .nr_irqs= EXYNOS_NR_IRQS, .smp= smp_ops(exynos_smp_ops), .init_irq = exynos4_init_irq, .map_io = exynos4_dt_map_io, diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c index 753b94f..8b7456a 100644 --- a/arch/arm/mach-exynos/mach-exynos5-dt.c +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c @@ -16,6 +16,7 @@ #include linux/clocksource.h #include asm/mach/arch.h +#include mach/irqs.h #include mach/regs-pmu.h #include plat/cpu.h @@ -76,6 +77,7 @@ static void __init exynos5_reserve(void) DT_MACHINE_START(EXYNOS5_DT, SAMSUNG EXYNOS5 (Flattened Device Tree)) /* Maintainer: Kukjin Kim kgene@samsung.com */ + .nr_irqs= EXYNOS_NR_IRQS, .init_irq = exynos5_init_irq, .smp= smp_ops(exynos_smp_ops), .map_io = exynos5_dt_map_io, diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index 0c10852..fbae331 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -53,6 +53,7 @@ #include plat/fimc-core.h #include plat/camport.h +#include mach/irqs.h #include mach/map.h #include common.h @@ -1376,6 +1377,7 @@ static void __init nuri_machine_init(void) MACHINE_START(NURI, NURI) /* Maintainer: Kyungmin Park kyungmin.p...@samsung.com */ .atag_offset= 0x100, + .nr_irqs= EXYNOS_NR_IRQS, .smp= smp_ops(exynos_smp_ops), .init_irq = exynos4_init_irq, .map_io
Re: [PATCH 15/30] mtd: onenand/samsung: make regs-onenand.h file local
Thanks Arnd.
On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann a...@arndb.de wrote:
Nothing uses the NAND register definitions other than the
actual driver, so we can move the header file into the
same local directory, which lets us build it in a multiplatform
configuration.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-...@lists.infradead.org
Cc: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: David Woodhouse dw...@infradead.org
---
drivers/mtd/onenand/samsung.c | 4
++--
.../include/plat/regs-onenand.h = drivers/mtd/onenand/samsung.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
rename arch/arm/plat-samsung/include/plat/regs-onenand.h =
drivers/mtd/onenand/samsung.h (98%)
diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index 33f2a8f..2cf7408 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -23,11 +23,11 @@
#include linux/mtd/partitions.h
#include linux/dma-mapping.h
#include linux/interrupt.h
+#include linux/io.h
#include asm/mach/flash.h
-#include plat/regs-onenand.h
-#include linux/io.h
+#include samsung.h
enum soc_type {
TYPE_S3C6400,
diff --git a/arch/arm/plat-samsung/include/plat/regs-onenand.h
b/drivers/mtd/onenand/samsung.h
similarity index 98%
rename from arch/arm/plat-samsung/include/plat/regs-onenand.h
rename to drivers/mtd/onenand/samsung.h
index 930ea8b..c4a80e6 100644
--- a/arch/arm/plat-samsung/include/plat/regs-onenand.h
+++ b/drivers/mtd/onenand/samsung.h
@@ -11,8 +11,6 @@
#ifndef __SAMSUNG_ONENAND_H__
#define __SAMSUNG_ONENAND_H__
-#include mach/hardware.h
-
/*
* OneNAND Controller
*/
--
1.8.1.2
__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] clk: samsung: always allocate the clk_table
On Tue, Mar 12, 2013 at 10:48 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: On 03/12/2013 12:46 PM, Thomas Abraham wrote: And, you mentioned Exynos4 will be dt-only from 3.10. Does that mean we just drop support for universal and nuri non-dt board support? Or, will there be a equivalent dt support added for these boards? I think Tomasz has some initial dts files for Universal_c210 ready, and Nuri could probably just be dropped. But we need Kyungmin's opinion on that. Agree. Tomasz will send unviersal DT files soon. Thank you, Kyungmin Park I'm not sure about other boards, they look pretty basic though. So it shouldn't be difficult to replace them with corresponding dts files. Currently there are: arch/arm/mach-exynos/mach-smdk4x12.c arch/arm/mach-exynos/mach-origen.c arch/arm/mach-exynos/mach-nuri.c arch/arm/mach-exynos/mach-universal_c210.c arch/arm/mach-exynos/mach-armlex4210.c arch/arm/mach-exynos/mach-smdkv310.c And there are dts files for: arch/arm/boot/dts/exynos4210-smdkv310.dts arch/arm/boot/dts/exynos4210-origen.dts arch/arm/boot/dts/exynos5250-smdk5250.dts arch/arm/boot/dts/exynos5250-snow.dts arch/arm/boot/dts/exynos4210-trats.dts arch/arm/boot/dts/exynos5440-ssdk5440.dts arch/arm/boot/dts/exynos4412-smdk4412.dts So except Universal_c210 and Nuri the only ones not supporting booting from DT are these two simple boards, which seem to be maintained by Samsung: arch/arm/mach-exynos/mach-smdk4x12.c arch/arm/mach-exynos/mach-armlex4210.c It would be nice to make Exynos DT only in this kernel release. I guess there was enough time to get all boards converted to DT already. -- Regards, Sylwester ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 07/16] ARM: Exynos: Initialize the clocks prior to timer initialization
= mct_init,
+ .init_time = exynos_init_time,
.reserve= origen_reserve,
.restart= exynos4_restart,
MACHINE_END
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c
b/arch/arm/mach-exynos/mach-smdk4x12.c
index c56cc21..71422ad 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -377,7 +377,7 @@ MACHINE_START(SMDK4212, SMDK4212)
.map_io = smdk4x12_map_io,
.handle_irq = gic_handle_irq,
.init_machine = smdk4x12_machine_init,
- .init_time = mct_init,
+ .init_time = exynos_init_time,
.restart= exynos4_restart,
.reserve= smdk4x12_reserve,
MACHINE_END
@@ -392,7 +392,7 @@ MACHINE_START(SMDK4412, SMDK4412)
.handle_irq = gic_handle_irq,
.init_machine = smdk4x12_machine_init,
.init_late = exynos_init_late,
- .init_time = mct_init,
+ .init_time = exynos_init_time,
.restart= exynos4_restart,
.reserve= smdk4x12_reserve,
MACHINE_END
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c
b/arch/arm/mach-exynos/mach-smdkv310.c
index 9d511f5..eb51c06 100644
--- a/arch/arm/mach-exynos/mach-smdkv310.c
+++ b/arch/arm/mach-exynos/mach-smdkv310.c
@@ -424,7 +424,7 @@ MACHINE_START(SMDKV310, SMDKV310)
.map_io = smdkv310_map_io,
.handle_irq = gic_handle_irq,
.init_machine = smdkv310_machine_init,
- .init_time = mct_init,
+ .init_time = exynos_init_time,
.reserve= smdkv310_reserve,
.restart= exynos4_restart,
MACHINE_END
@@ -438,7 +438,7 @@ MACHINE_START(SMDKC210, SMDKC210)
.handle_irq = gic_handle_irq,
.init_machine = smdkv310_machine_init,
.init_late = exynos_init_late,
- .init_time = mct_init,
+ .init_time = exynos_init_time,
.reserve= smdkv310_reserve,
.restart= exynos4_restart,
MACHINE_END
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 3998c81..53de074 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -1144,6 +1144,12 @@ static void __init universal_machine_init(void)
platform_add_devices(universal_devices,
ARRAY_SIZE(universal_devices));
}
+static void __init universal_init_time(void)
+{
+ exynos4_clk_init(NULL);
+ mct_init();
No, It's not support MCT timer at universal board, please don't modify
universal board at this time.
Others are okay.
Thank you,
Kyungmin Park
+}
+
MACHINE_START(UNIVERSAL_C210, UNIVERSAL_C210)
/* Maintainer: Kyungmin Park kyungmin.p...@samsung.com */
.atag_offset= 0x100,
@@ -1153,7 +1159,7 @@ MACHINE_START(UNIVERSAL_C210, UNIVERSAL_C210)
.handle_irq = gic_handle_irq,
.init_machine = universal_machine_init,
.init_late = exynos_init_late,
- .init_time = samsung_timer_init,
+ .init_time = universal_init_time,
.reserve= universal_reserve,
.restart= exynos4_restart,
MACHINE_END
--
1.7.5.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 00/12] ARM: samsung-time: Prepare for multiplatform support
On Sun, Feb 10, 2013 at 10:32 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Seems like several mail addresses of board maintainers are no longer valid. guillaume.gou...@nexvision.tv mentioned in: arch/arm/mach-s3c24xx/mach-nexcoder.c arch/arm/mach-s3c24xx/mach-otom.c arhu...@freaks-unidos.net mentioned in: arch/arm/mach-s3c24xx/mach-gta02.c dand...@amltd.com mentioned in: arch/arm/mach-s3c24xx/mach-amlm5900.c arch/arm/mach-s3c24xx/mach-tct_hammer.c bh...@samsung.com mentioned in: arch/arm/mach-s5pc100/mach-smdkc100 and a bunch of files in arch/arm/mach-s5pc100 FYI: He's left the company. and he doesn't work it anymore, so you can drop him. Thank you, Kyungmin Park I wonder if we should do anything with them? Best regards, Tomasz On Sunday 10 of February 2013 14:20:11 Tomasz Figa wrote: This series is an attempt to make the samsung-time clocksource driver ready for multiplatform kernels. It moves the driver to drivers/clocksource, cleans it up from uses of static platform-specific definitions, simplifies timer interrupt handling and adds Device Tree support. Tested on a Tiny6410 board (Mini6410-compatible) both with and without Devicee Tree (with my DT patches for S3C64xx). Compile tested for other related archs. Tomasz Figa (12): ARM: SAMSUNG: Move samsung-time to drivers/clocksource clocksource: samsung-time: Set platform-specific parameters at runtime clocksource: samsung-time: Drop useless defines from public header clocksource: samsung-time: Move samsung-time.h header to include/linux clocksource: samsung-time: Use local register definitions clocksource: samsung-time: Remove use of static register mapping clocksource: samsung-time: Use clk_get_sys for getting clocks ARM: SAMSUNG: devs: Drop unnecessary IRQ resources of timer devices clocksource: samsung-time: Do not use static IRQ definition clocksource: samsung-time: Move IRQ mask/ack handling to the driver ARM: SAMSUNG: Remove unused PWM timer IRQ chip code clocksource: samsung-time: Add Device Tree support .../devicetree/bindings/arm/samsung-timer.txt | 32 ++ arch/arm/Kconfig | 1 - arch/arm/mach-exynos/include/mach/irqs.h | 3 +- arch/arm/mach-exynos/mach-universal_c210.c | 15 +- arch/arm/mach-s3c24xx/common.c | 14 + arch/arm/mach-s3c24xx/mach-amlm5900.c | 2 +- arch/arm/mach-s3c24xx/mach-anubis.c| 2 +- arch/arm/mach-s3c24xx/mach-at2440evb.c | 2 +- arch/arm/mach-s3c24xx/mach-bast.c | 2 +- arch/arm/mach-s3c24xx/mach-gta02.c | 2 +- arch/arm/mach-s3c24xx/mach-h1940.c | 2 +- arch/arm/mach-s3c24xx/mach-jive.c | 2 +- arch/arm/mach-s3c24xx/mach-mini2440.c | 2 +- arch/arm/mach-s3c24xx/mach-n30.c | 2 +- arch/arm/mach-s3c24xx/mach-nexcoder.c | 2 +- arch/arm/mach-s3c24xx/mach-osiris.c| 2 +- arch/arm/mach-s3c24xx/mach-otom.c | 2 +- arch/arm/mach-s3c24xx/mach-qt2410.c| 2 +- arch/arm/mach-s3c24xx/mach-rx1950.c| 2 +- arch/arm/mach-s3c24xx/mach-rx3715.c| 2 +- arch/arm/mach-s3c24xx/mach-smdk2410.c | 2 +- arch/arm/mach-s3c24xx/mach-smdk2413.c | 2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c | 2 +- arch/arm/mach-s3c24xx/mach-smdk2440.c | 2 +- arch/arm/mach-s3c24xx/mach-smdk2443.c | 2 +- arch/arm/mach-s3c24xx/mach-tct_hammer.c| 2 +- arch/arm/mach-s3c24xx/mach-vr1000.c| 2 +- arch/arm/mach-s3c24xx/mach-vstms.c | 2 +- arch/arm/mach-s3c64xx/common.c | 19 +- arch/arm/mach-s3c64xx/include/mach/irqs.h | 8 - arch/arm/mach-s3c64xx/mach-anw6410.c | 2 +- arch/arm/mach-s3c64xx/mach-crag6410.c | 2 +- arch/arm/mach-s3c64xx/mach-hmt.c | 2 +- arch/arm/mach-s3c64xx/mach-mini6410.c | 2 +- arch/arm/mach-s3c64xx/mach-ncp.c | 2 +- arch/arm/mach-s3c64xx/mach-real6410.c | 2 +- arch/arm/mach-s3c64xx/mach-smartq.c| 2 +- arch/arm/mach-s3c64xx/mach-smartq5.c | 2 +- arch/arm/mach-s3c64xx/mach-smartq7.c | 2 +- arch/arm/mach-s3c64xx/mach-smdk6400.c | 2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +- arch/arm/mach-s5p64x0/common.c | 15 + arch/arm/mach-s5p64x0/include/mach/irqs.h | 2 - arch/arm/mach-s5p64x0/mach-smdk6440.c | 2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c | 2
Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
On Wed, Feb 6, 2013 at 9:42 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren swar...@wwwdotorg.org wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
Binding looks sane to me.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
#ifdef CONFIG_OF
static struct of_device_id hdmi_match_types[] = {
{
- .compatible = samsung,exynos5-hdmi,
- .data = (void *)HDMI_TYPE14,
+ .compatible = samsung,exynos4-hdmi,
}, {
/* end node */
}
Why not fill in all the base compatible values there (I think you need
this anyway so that DTs don't all have to be compatible with
samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
values, then ...
At the moment, all DTs have to be compatible with exynos4-hdmi since
it provides the base for the current driver. The driver uses 4210 and
4212 to differentiate between different register addresses and
features, but most things are just exynos4-hdmi compatible.
I would like to distinguish between 4210 and 4x12. since it has
different features. e.g., HDMI v1.3 and v1.4.
and I also want to use 4412 instead of 4212. there's no board to use
4212 at mainline until this time.
Thank you,
Kyungmin Park
The DT nodes should include only the compatible values that the HW is
actually compatible with. If the HW isn't compatible with exynos4-hdmi,
that value shouldn't be in the compatible property, but instead whatever
the base value that the HW really is compatible with. The driver can
support multiple base compatible values from this table.
@@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)
+
+ if (of_device_is_compatible(dev-of_node, samsung,exynos4210-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS4210;
+ if (of_device_is_compatible(dev-of_node, samsung,exynos4212-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS4212;
+ if (of_device_is_compatible(dev-of_node, samsung,exynos5250-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS5250;
Instead of that, do roughly:
match = of_match_device(hdmi_match_types, pdev-dev);
if (match)
hdata-version |= (int)match-data;
That way, it's all table-based. Any future additions to
hdmi_match_types[] won't require another if statement to be added to
probe().
I don't think it's that easy. of_match_device returns the first match
from the device table, so I'd still need to iterate through the
matches. I could still break this out into a table, but I don't think
of_match_device is the right way to probe it.
You shouldn't have to iterate over multiple matches. of_match_device()
is supposed to return the match for the first entry in the compatible
property, then if there was no match, move on to looking at the next
entry in the compatible property, etc. In practice, I think it's still
not implemented quite correctly for this, but you can make it work by
putting the newest compatible value first in the match table.
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] I2C: EXYNOS: Add slave support to i2c
Hi,
On Mon, Dec 3, 2012 at 9:16 PM, Giridhar Maruthy
giridhar.maru...@linaro.org wrote:
This patch adds slave support to i2c. The dt entry i2c-mode
decides at probe time if the controller needs to work in
slave mode and the controller is accordingly programmed.
Signed-off-by: Giridhar Maruthy giridhar.maru...@linaro.org
---
drivers/i2c/busses/i2c-s3c2410.c | 100
++
1 file changed, 68 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index e93e7d6..d83a6d7 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -53,6 +53,9 @@
/* Max time to wait for bus to become idle after a xfer (in us) */
#define S3C2410_IDLE_TIMEOUT 5000
+/* To find the master/slave mode of current controller */
+#define is_master(i2c) (!i2c-i2c_mode)
+
/* i2c controller state */
enum s3c24xx_i2c_state {
STATE_IDLE,
@@ -89,6 +92,8 @@ struct s3c24xx_i2c {
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
+ /* i2c_mode: 0 is for master; and 1 is for slave */
+ unsigned inti2c_mode;
If it's used for master or not, doesn't better to use 'is_master' or
'is_slave'? what's the meaning of 'i2c_mode'?
and
#define is_master(i2c) (i2c-is_master)
Thank you,
Kyungmin Park
};
static struct platform_device_id s3c24xx_driver_ids[] = {
@@ -202,11 +207,21 @@ static void s3c24xx_i2c_message_start(struct
s3c24xx_i2c *i2c,
stat = 0;
stat |= S3C2410_IICSTAT_TXRXEN;
- if (msg-flags I2C_M_RD) {
- stat |= S3C2410_IICSTAT_MASTER_RX;
- addr |= 1;
- } else
- stat |= S3C2410_IICSTAT_MASTER_TX;
+ if (is_master(i2c)) {
+ /* Master mode */
+ if (msg-flags I2C_M_RD) {
+ stat |= S3C2410_IICSTAT_MASTER_RX;
+ addr |= 1;
+ } else
+ stat |= S3C2410_IICSTAT_MASTER_TX;
+ } else {
+ /* Slave mode */
+ if (msg-flags I2C_M_RD) {
+ stat |= S3C2410_IICSTAT_SLAVE_RX;
+ addr |= 1;
+ } else
+ stat |= S3C2410_IICSTAT_SLAVE_TX;
+ }
if (msg-flags I2C_M_REV_DIR_ADDR)
addr ^= 1;
@@ -228,8 +243,10 @@ static void s3c24xx_i2c_message_start(struct
s3c24xx_i2c *i2c,
dev_dbg(i2c-dev, iiccon, %08lx\n, iiccon);
writel(iiccon, i2c-regs + S3C2410_IICCON);
- stat |= S3C2410_IICSTAT_START;
- writel(stat, i2c-regs + S3C2410_IICSTAT);
+ if (is_master(i2c)) {
+ stat |= S3C2410_IICSTAT_START;
+ writel(stat, i2c-regs + S3C2410_IICSTAT);
+ }
}
static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c *i2c, int ret)
@@ -272,14 +289,19 @@ static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c
*i2c, int ret)
* devices, the host as Master and the HDMIPHY device as the slave.
* Skipping the STOP condition has been tested on this bus and
works.
*/
- if (i2c-quirks QUIRK_HDMIPHY) {
- /* Stop driving the I2C pins */
- iicstat = ~S3C2410_IICSTAT_TXRXEN;
- } else {
- /* stop the transfer */
- iicstat = ~S3C2410_IICSTAT_START;
+ if (is_master(i2c)) {
+ if (i2c-quirks QUIRK_HDMIPHY) {
+ /* Stop driving the I2C pins */
+ iicstat = ~S3C2410_IICSTAT_TXRXEN;
+ } else {
+ /* stop the transfer */
+ if (is_master(i2c)) {
+ /* Start/Stop required only for master */
+ iicstat = ~S3C2410_IICSTAT_START;
+ }
+ }
+ writel(iicstat, i2c-regs + S3C2410_IICSTAT);
}
- writel(iicstat, i2c-regs + S3C2410_IICSTAT);
i2c-state = STATE_STOP;
@@ -348,7 +370,8 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
unsigned long iicstat)
*/
if (iicstat S3C2410_IICSTAT_LASTBIT
- !(i2c-msg-flags I2C_M_IGNORE_NAK)) {
+ !(i2c-msg-flags I2C_M_IGNORE_NAK)
+ is_master(i2c)) {
/* ack was not received... */
dev_dbg(i2c-dev, ack was not received\n);
@@ -380,7 +403,7 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
unsigned long iicstat)
* end of the message, and if so, work out what to do
*/
- if (!(i2c-msg-flags I2C_M_IGNORE_NAK)) {
+ if (!(i2c-msg-flags I2C_M_IGNORE_NAK) is_master(i2c))
{
if (iicstat S3C2410_IICSTAT_LASTBIT
Re: [PATCH 1/2] i2c-s3c2410: Leave the bus disabled unless it is in use
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
On Thu, Nov 29, 2012 at 2:05 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
From: Simon Glass s...@chromium.org
There is a rather odd feature of the exynos i2c controller that if it
is left enabled, it can lock itself up with the clk line held low.
This makes the bus unusable.
Unfortunately, the s3c24xx_i2c_set_master() function does not notice
this, and reports a timeout. From then on the bus cannot be used until
the AP is rebooted.
The problem happens when any sort of interrupt occurs (e.g. due to a
bus transition) when we are not in the middle of a transaction. We
have seen many instances of this when U-Boot leaves the bus apparently
happy, but Linux cannot access it.
The current code is therefore pretty fragile.
This fixes things by leaving the bus disabled unless we are actually
in a transaction. We enable the bus at the start of the transaction and
disable it at the end. That way we won't get interrupts and will not
lock up the bus.
It might be possible to clear pending interrupts on start-up, but this
seems to be a more robust solution. We can't service interrupts when
we are not in a transaction, and anyway would rather not lock up the
bus while we try.
Signed-off-by: Simon Glass s...@chromium.org
Cc: Grant Grundler grund...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/i2c/busses/i2c-s3c2410.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index e93e7d6..2fd346d 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -186,6 +186,31 @@ static inline void s3c24xx_i2c_enable_irq(struct
s3c24xx_i2c *i2c)
writel(tmp | S3C2410_IICCON_IRQEN, i2c-regs + S3C2410_IICCON);
}
+/*
+ * Disable the bus so that we won't get any interrupts from now on, or try
+ * to drive any lines. This is the default state when we don't have
+ * anything to send/receive.
+ *
+ * If there is an event on the bus, or we have a pre-existing event at
+ * kernel boot time, we may not notice the event and the I2C controller
+ * will lock the bus with the I2C clock line low indefinitely.
+ */
+static inline void s3c24xx_i2c_disable_bus(struct s3c24xx_i2c *i2c)
+{
+ unsigned long tmp;
+
+ /* Stop driving the I2C pins */
+ tmp = readl(i2c-regs + S3C2410_IICSTAT);
+ tmp = ~S3C2410_IICSTAT_TXRXEN;
+ writel(tmp, i2c-regs + S3C2410_IICSTAT);
+
+ /* We don't expect any interrupts now, and don't want send acks */
+ tmp = readl(i2c-regs + S3C2410_IICCON);
+ tmp = ~(S3C2410_IICCON_IRQEN | S3C2410_IICCON_IRQPEND |
+ S3C2410_IICCON_ACKEN);
+ writel(tmp, i2c-regs + S3C2410_IICCON);
+}
+
/* s3c24xx_i2c_message_start
*
@@ -646,7 +671,11 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
s3c24xx_i2c_wait_idle(i2c);
+ s3c24xx_i2c_disable_bus(i2c);
+
out:
+ i2c-state = STATE_IDLE;
+
return ret;
}
@@ -912,7 +941,6 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
*i2c)
static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
{
- unsigned long iicon = S3C2410_IICCON_IRQEN | S3C2410_IICCON_ACKEN;
struct s3c2410_platform_i2c *pdata;
unsigned int freq;
@@ -926,12 +954,12 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
dev_info(i2c-dev, slave address 0x%02x\n, pdata-slave_addr);
- writel(iicon, i2c-regs + S3C2410_IICCON);
+ writel(0, i2c-regs + S3C2410_IICCON);
+ writel(0, i2c-regs + S3C2410_IICSTAT);
/* we need to work out the divisors for the clock... */
if (s3c24xx_i2c_clockrate(i2c, freq) != 0) {
- writel(0, i2c-regs + S3C2410_IICCON);
dev_err(i2c-dev, cannot meet bus frequency required\n);
return -EINVAL;
}
@@ -939,7 +967,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
/* todo - check that the i2c lines aren't being dragged anywhere */
dev_info(i2c-dev, bus frequency set to %d KHz\n, freq);
- dev_dbg(i2c-dev, S3C2410_IICCON=0x%02lx\n, iicon);
+ dev_dbg(i2c-dev, S3C2410_IICCON=0x%02x\n,
+ readl(i2c-regs + S3C2410_IICCON));
return 0;
}
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: Exynos: Remove unused non-dt support for dwmci controller
On 11/26/12, Thomas Abraham thomas.abra...@linaro.org wrote:
With device tree support enabled for dwmci controller, the unused non-dt
support
for dwmci controller can be removed.
Are there no problem to use legacy board? e.g., universal_c210.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/mach-exynos/Makefile |1 -
arch/arm/mach-exynos/dev-dwmci.c | 75
-
arch/arm/mach-exynos/include/mach/dwmci.h | 20
3 files changed, 0 insertions(+), 96 deletions(-)
delete mode 100644 arch/arm/mach-exynos/dev-dwmci.c
delete mode 100644 arch/arm/mach-exynos/include/mach/dwmci.h
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index c12ed6a..b189881 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -50,7 +50,6 @@ obj-$(CONFIG_MACH_EXYNOS5_DT) +=
mach-exynos5-dt.o
obj-y+= dev-uart.o
obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o
obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
-obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
obj-$(CONFIG_EXYNOS_DEV_DMA) += dma.o
obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI) += dev-ohci.o
obj-$(CONFIG_EXYNOS_DEV_SYSMMU) += dev-sysmmu.o
diff --git a/arch/arm/mach-exynos/dev-dwmci.c
b/arch/arm/mach-exynos/dev-dwmci.c
deleted file mode 100644
index 7903501..000
--- a/arch/arm/mach-exynos/dev-dwmci.c
+++ /dev/null
@@ -1,75 +0,0 @@
-/*
- * linux/arch/arm/mach-exynos4/dev-dwmci.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * Platform device for Synopsys DesignWare Mobile Storage IP
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include linux/kernel.h
-#include linux/dma-mapping.h
-#include linux/platform_device.h
-#include linux/interrupt.h
-#include linux/ioport.h
-#include linux/mmc/dw_mmc.h
-
-#include plat/devs.h
-
-#include mach/map.h
-
-static int exynos4_dwmci_get_bus_wd(u32 slot_id)
-{
- return 4;
-}
-
-static int exynos4_dwmci_init(u32 slot_id, irq_handler_t handler, void
*data)
-{
- return 0;
-}
-
-static struct resource exynos4_dwmci_resource[] = {
- [0] = DEFINE_RES_MEM(EXYNOS4_PA_DWMCI, SZ_4K),
- [1] = DEFINE_RES_IRQ(EXYNOS4_IRQ_DWMCI),
-};
-
-static struct dw_mci_board exynos4_dwci_pdata = {
- .num_slots = 1,
- .quirks = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
- .bus_hz = 80 * 1000 * 1000,
- .detect_delay_ms= 200,
- .init = exynos4_dwmci_init,
- .get_bus_wd = exynos4_dwmci_get_bus_wd,
-};
-
-static u64 exynos4_dwmci_dmamask = DMA_BIT_MASK(32);
-
-struct platform_device exynos4_device_dwmci = {
- .name = dw_mmc,
- .id = -1,
- .num_resources = ARRAY_SIZE(exynos4_dwmci_resource),
- .resource = exynos4_dwmci_resource,
- .dev= {
- .dma_mask = exynos4_dwmci_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = exynos4_dwci_pdata,
- },
-};
-
-void __init exynos4_dwmci_set_platdata(struct dw_mci_board *pd)
-{
- struct dw_mci_board *npd;
-
- npd = s3c_set_platdata(pd, sizeof(struct dw_mci_board),
- exynos4_device_dwmci);
-
- if (!npd-init)
- npd-init = exynos4_dwmci_init;
- if (!npd-get_bus_wd)
- npd-get_bus_wd = exynos4_dwmci_get_bus_wd;
-}
diff --git a/arch/arm/mach-exynos/include/mach/dwmci.h
b/arch/arm/mach-exynos/include/mach/dwmci.h
deleted file mode 100644
index 7ce6574..000
--- a/arch/arm/mach-exynos/include/mach/dwmci.h
+++ /dev/null
@@ -1,20 +0,0 @@
-/* linux/arch/arm/mach-exynos4/include/mach/dwmci.h
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- *
- * Synopsys DesignWare Mobile Storage for EXYNOS4210
- *
- * 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.
- */
-
-#ifndef __ASM_ARM_ARCH_DWMCI_H
-#define __ASM_ARM_ARCH_DWMCI_H __FILE__
-
-#include linux/mmc/dw_mmc.h
-
-extern void exynos4_dwmci_set_platdata(struct dw_mci_board *pd);
-
-#endif /* __ASM_ARM_ARCH_DWMCI_H */
--
1.7.5.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from
Re: [PATCH] ARM: dts: add initial dts file for ORIGEN4QUAD
Hi,
On 11/26/12, chlrb...@gmail.com chlrb...@gmail.com wrote:
From: Kyuho Choi kh.c...@insignal.co.kr
This patch adds initial dts file for ORIGEN4QUAD board.
ORIGEN4QUAD board based on Samsung EXYNOS4412 SoC.
More properties will be added later.
Signed-off-by: Kyuho Choi kh.c...@insignal.co.kr
---
arch/arm/boot/dts/exynos4412-origen4quad.dts | 45
++
1 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-origen4quad.dts
diff --git a/arch/arm/boot/dts/exynos4412-origen4quad.dts
b/arch/arm/boot/dts/exynos4412-origen4quad.dts
new file mode 100644
index 000..390a2ab
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-origen4quad.dts
@@ -0,0 +1,45 @@
+/*
+ * Samsung's Exynos4412 based Origen4Quad board device tree source
+ *
+ * Copyright (c) 2012-2013 Isnignal Co., Ltd.
+ * http://www.insignal.co.kr
+ *
+ * Device tree source file for Insignal's Origen4Quad board which is based
on
+ * Samsung's Exynos4412 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ exynos4412.dtsi
+
+/ {
+ model = Insignal Origen4Quad board based on Exynos4412;
+ compatible = insignal,origen4quad, samsung,exynos4412;
+
+ memory {
+ reg = 0x4000 0x4000;
+ };
does it test to boot with this dts file?
does it support 1GiB memory section?
Thank you,
Kyungmin Park
+
+ chosen {
+ bootargs =root=/dev/ram0 rw ramdisk=32768 initrd=0x4100,32M
console=ttySAC2,115200 init=/linuxrc;
+ };
+
+ serial@1380 {
+ status = okay;
+ };
+
+ serial@1381 {
+ status = okay;
+ };
+
+ serial@1382 {
+ status = okay;
+ };
+
+ serial@1383 {
+ status = okay;
+ };
+};
--
1.7.5.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
On Fri, Nov 9, 2012 at 8:54 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Tue, Oct 30, 2012 at 10:27:32AM +0530, Praveen Paneri wrote: Changes from v6: Modified register definitions according to the existing ones. Changed default PHY clk selection for SoCs. Improved binding text and rebased to the latest usb-next. Changes from v5: Moved clk_get() to driver's probe function. Now reference clock frequency selection value is stored in samsung_usbphy structure for later use. Used IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data(). Changes from v4: Moved header file contents to driver's source file Removed unnecessary print message from driver's probe function Dropped the Free Software Foundation address from the header Changed the platform data code to use __initdata Changes from v3: Replaced susbsys_initcall()/module_exit() by module_platform_driver(). Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver is registered Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove. Changes from v2: Changed the driver filenames to samsung-usbphy Changed 's3c' to 'samsung' for platform device as well as platform data Moved platform data structure to a separate file Rectified coding style related errors Changes from v1: Rebased patches to latest usb-next branch Changed the name 'sec_usbphy' to 'samsung_usbphy' This patch set introduces a phy driver for samsung SoCs. It uses the existing transceiver infrastructure to provide phy control functions. Use of this driver can be extended for usb host phy as well. Over the period of time all the phy related code for most of the samsung SoCs can be integrated here. Removing the existing phy code from mach-s3c64xx. Same can be done for other SoCs when they start supporting this phy driver. This driver is tested with smdk6410 and Exynos4210(with DT). Praveen Paneri (5): usb: phy: samsung: Introducing usb phy driver for hsotg usb: s3c-hsotg: Adding phy driver support For usb parts: Acked-by: Kyungmin Park kyungmin.p...@samsung.com ARM: S3C64XX: Removing old phy setup code ARM: S3C64XX: Enabling samsung-usbphy driver ARM: Exynos4210: Enabling samsung-usbphy driver guys I can't wait any longer. If I don't get proper Acks today, I will go ahead without all the PHY changes from Samsung :-s To Praveen, To remove these dependency and merge issue, please send patches for each subsystem. In this case, usb patches for usb tree and others are for arm arch. Thank you, Kyungmin Park -- balbi ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] pinctrl: samsung: Add support for Exynos4x12
On 10/29/12, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Oct 24, 2012 at 4:37 PM, Tomasz Figa t.f...@samsung.com wrote: This patch extends the driver with any necessary SoC-specific definitions to support Exynos4x12 SoCs. Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Linus Walleij linus.wall...@linaro.org I guess you need all of this to go into my Samsung branch? I need and ACK from the Samsung maintainer and preferably Thomas A as well. Hi, Now we're trying to send the standalone patches to avoid the conflict. and hope to merge patches via proper subsystem. In this case, pinctl. Thank you, Kyungmin Park Yours, Linus Walleij ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: EXYNOS: exynos4-dt: Set .smp field of machine descriptor
+ Arnd, Olof,
Tomasz,
I think it's better to add arm-soc maintainers at CC when send the patches.
Samsung patches doesn't handled or merged with proper time.
Thank you,
Kyungmin Park
On 10/22/12, Tomasz Figa tomasz.f...@gmail.com wrote:
On Friday 12 of October 2012 11:49:38 Tomasz Figa wrote:
This patch adds missing initializer of .smp field of machine descriptor
of Exynos 4 DT machine.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c index 7222e3c..d6bdcfb 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -119,6 +119,7 @@ static char const *exynos4_dt_compat[] __initdata =
{
DT_MACHINE_START(EXYNOS4210_DT, Samsung Exynos4 (Flattened Device
Tree)) /* Maintainer: Thomas Abraham thomas.abra...@linaro.org */
+.smp= smp_ops(exynos_smp_ops),
.init_irq = exynos4_init_irq,
.map_io = exynos4_dt_map_io,
.handle_irq = gic_handle_irq,
Ping. I think this should be considered a fix.
Best regards,
Tomasz Figa
--
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
--
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 v3 0/6] arm: exynos: add dt based support for exynos5 hdmi
Hi, It's common case, one topic but two different tree. So I suggest merge it at samsung sub-soc tree and drm parts will be merged after arm-soc tree is merged. since arm-soc tree collect arm soc-soc and merged early at merge window. then drm tree will be merged later. Until that time, drm patches are hold only at local git. How do you think? Thank you, Kyungmin Park On 10/16/12, Rahul Sharma r.sh.o...@gmail.com wrote: Hi Mr. Park, Mr. Kim, I had a suggestion here from Tomasz about dividing this patch-set into 2 portions: 1) DT related (patches 1-4) for samsung-dt branch. 2) Clocks, Arch data related to Exynos5. (patches 5,6) for exynos-drm-fixes branch. Rationale behind this is kgene tree with all 6 patches applied will have broken drm exynos4 and incomplete drm exynos5. I want to know your opinion on this. regards, Rahul Sharma On Tue, Oct 16, 2012 at 3:01 PM, Tomasz Figa t.f...@samsung.com wrote: Hi Rahul, On Tuesday 16 of October 2012 05:00:28 Rahul Sharma wrote: This patch set adds the DT based support for Samsung's Exynos5250. It adds device tree nodes for hdmi, mixer, hdmiphy and hdmiddc. The name of these devices are changed to the one matching with drivers. Exynos-drm and exynos hdmi-drm-commmon devices are removed from machine init code. Exynos-drm and exynos hdmi-drm-commmon devices are removed from machine init code. Patch set which adds this code is posted to dri-devel list at http://comments.gmane.org/gmane.comp.video.dri.devel/75121. This patchset is based on linux v3.6-rc6, branch v3.7-next/dt-samsung at git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v1: - dropped patch for hpd gpio initialisation from machine init. - dropped patch for platform device registration. - removed platform device registration from non-dt platforms. v2: - removed version information from hdmi, mixer dt nodes. - added DT binding documentation for hdmi, mixer, hdmiphy and hdmiddc. v3: - corrected indentations. - changed dt node names to name@address format. Rahul Sharma (6): dts: exynos: add device tree support for exynos5 hdmi dts: exynos: add device tree support for exynos5 mixer dts: exynos: add device tree support for exynos5 hdmiphy dts: exynos: add device tree support for exynos5 hdmiddc arm: exynos: add clocks for exynos5 hdmi arm: exynos: removing exynos-drm device registration from non-dt platforms .../devicetree/bindings/drm/exynos/hdmi.txt | 22 +++ .../devicetree/bindings/drm/exynos/hdmiddc.txt | 12 .../devicetree/bindings/drm/exynos/hdmiphy.txt | 12 .../devicetree/bindings/drm/exynos/mixer.txt | 15 ++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 24 +++- arch/arm/boot/dts/exynos5250.dtsi | 20 + arch/arm/mach-exynos/Makefile | 1 - arch/arm/mach-exynos/clock-exynos5.c | 14 - arch/arm/mach-exynos/dev-drm.c | 29 arch/arm/mach-exynos/include/mach/map.h | 2 + arch/arm/mach-exynos/mach-exynos5-dt.c | 8 + arch/arm/mach-exynos/mach-nuri.c | 3 -- arch/arm/mach-exynos/mach-origen.c | 3 -- arch/arm/mach-exynos/mach-smdk4x12.c | 3 -- arch/arm/mach-exynos/mach-smdkv310.c | 3 -- arch/arm/mach-exynos/mach-universal_c210.c | 3 -- arch/arm/plat-samsung/include/plat/devs.h | 2 - 17 files changed, 126 insertions(+), 50 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmi.txt create mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt create mode 100644 Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt create mode 100644 Documentation/devicetree/bindings/drm/exynos/mixer.txt delete mode 100644 arch/arm/mach-exynos/dev-drm.c The patches look fine, but Kukjin's tree doesn't contain all the dependencies for them to be usable. Shouldn't they be based on exynos-drm-next branch of Kyungmin's tree at infradead instead: http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-next Best regards, -- Tomasz Figa Samsung Poland RD Center -- 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 -- 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] usb: phy: samsung: Introducing usb phy driver for hsotg
+ Tomasz Figa, Acked-by: Kyungmin Park kyungmin.p...@samsung.com On Mon, Oct 15, 2012 at 10:28 PM, Felipe Balbi ba...@ti.com wrote: On Fri, Oct 12, 2012 at 03:45:34PM +0530, Praveen Paneri wrote: platform_set_drvdata() required for driver's remove function, so adding it back. From v6: Added TODO for phy bindings with controller Dropped platform_set_drvdata() from driver probe This driver uses usb_phy interface to interact with s3c-hsotg. Supports phy_init and phy_shutdown functions to enable/disable phy. Tested with smdk6410 and smdkv310. More SoCs can be brought under later. this commit log needs improvement. There are stuff there which shouldn't go to git's history. I would like to get Tested-bys and Acked-by from DT maintainers. Signed-off-by: Praveen Paneri p.pan...@samsung.com Acked-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/usb/samsung-usbphy.txt | 11 + drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/samsung-usbphy.c | 357 include/linux/platform_data/samsung-usbphy.h | 27 ++ 5 files changed, 404 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/samsung-usbphy.c create mode 100644 include/linux/platform_data/samsung-usbphy.h diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file mode 100644 index 000..7b26e2d --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -0,0 +1,11 @@ +* Samsung's usb phy transceiver + +The Samsung's phy transceiver is used for controlling usb otg phy for +s3c-hsotg usb device controller. +TODO: Adding the PHY binding with controller(s) according to the under +developement generic PHY driver. + +Required properties: +- compatible : should be samsung,exynos4210-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 63c339b..313685f 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -32,3 +32,11 @@ config MV_U3D_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. + +config SAMSUNG_USBPHY + bool Samsung USB PHY controller Driver + depends on USB_S3C_HSOTG + select USB_OTG_UTILS + help + Enable this to support Samsung USB phy controller for samsung + SoCs. diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index b069f29..55dcfc1 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o obj-$(CONFIG_USB_ISP1301)+= isp1301.o obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c new file mode 100644 index 000..14c182f --- /dev/null +++ b/drivers/usb/phy/samsung-usbphy.c @@ -0,0 +1,357 @@ +/* linux/drivers/usb/phy/samsung-usbphy.c + * + * Copyright (c) 2012 Samsung Electronics Co., Ltd. + * http://www.samsung.com + * + * Author: Praveen Paneri p.pan...@samsung.com + * + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h +#include linux/of.h +#include linux/usb/otg.h +#include linux/platform_data/samsung-usbphy.h + +/* Register definitions */ + +#define S3C_PHYPWR (0x00) + +#define S3C_PHYPWR_NORMAL_MASK (0x19 0) +#define S3C_PHYPWR_OTG_DISABLE (1 4) +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 3) +#define S3C_PHYPWR_FORCE_SUSPEND (1 1) +/* For Exynos4 */ +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 0) +#define EXYNOS4_PHYPWR_SLEEP (1 5) + +#define S3C_PHYCLK (0x04) + +#define S3C_PHYCLK_MODE_SERIAL (1 6) +#define S3C_PHYCLK_EXT_OSC (1 5) +#define
Re: [PATCH v2 00/15] pinctrl: samsung: Usability and extensibiltiy improvements
Hi, On Thu, Oct 11, 2012 at 5:11 PM, Tomasz Figa t.f...@samsung.com wrote: This patch series is a work on improving usability and extensibiltiy of the pinctrl-samsung driver. It consists of three main parts: - improving flexibility of SoC-specific data specification - converting the driver to one GPIO chip and IRQ domain per pin bank - improving wake-up IRQ setup and handling Really good job! and it solved mess GPIOs H/W configurations of Samsung SoC. Basically Samsung SoC GPIOs don't have generic rules. Even worse, pin name is mixed but offset is still increased. With DT support. we can solve this issue and use generic pinctrl drivers. For all series. Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com 1) What the first part does, in addition to various related fixes, is removing any unnecessary static data from pinctrl-exynos driver. This is achieved mostly thanks to assigning pin numbers dynamically, with help of only pin counts of particular banks. It also simplifies adding next SoC variants, since much less static data needs to be specified. 2) The second part attempts to simplify usage of the driver and fix several problems of current implementation, in particular: - Simplifies GPIO pin specification in device tree by using pin namespace local to pin bank instead of local to pin controller, e.g. gpios = gpj0 3 0; instead of gpios = pinctrl0 115 0; - Simplifies GPIO interrupt specification in device tree by using namespace local to pin bank (and equal to GPIO namespace), e.g. interrupt-parent = gpj0; interrupts = 3 0; instead of interrupt-parent = pinctrl0; interrupts = 115 0; - Simplifies internal GPIO pin to bank translation thanks to correspondence of particular GPIO chips to pin banks. This allows to remove the (costly in case of GPIO bit-banging drivers) lookup over all banks to find the one that the pin is from. 3) Third part is focused on removing the hard-coded description of wake-up interrupt layout. It moves wake-up interrupt description to bank struct and device tree, which allows to specify which pin banks support wake-up interrupts and how they are handled (direct or multiplexed/chained). See particular patches for more detailed descriptions and the last patch for updated device tree bindings. Changes since v1: - dropped moving SoC-specific data to device tree (might be added in further patches) - dropped per-bank specification of configuration register offsets (thus limiting scope of the driver to Exynos SoCs; will be added in further patches) Tomasz Figa (15): pinctrl: samsung: Detect and handle unsupported configuration types pinctrl: samsung: Do not pass gpio_chip to pin_to_reg_bank pinctrl: samsung: Assing pin numbers dynamically pinctrl: samsung: Remove static pin enumerations pinctrl: samsung: Distinguish between pin group and bank nodes ARM: dts: exynos4210-pinctrl: Add nodes for pin banks pinctrl: samsung: Match pin banks with their device nodes pinctrl: samsung: Hold pointer to driver data in bank struct pinctrl: samsung: Include bank-specific eint offset in bank struct pinctrl: exynos: Use one IRQ domain per pin bank pinctrl: samsung: Use one GPIO chip per pin bank pinctrl: samsung: Use per-bank IRQ domain for wake-up interrupts pinctrl: exynos: Set pin function to EINT in irq_set_type of wake-up EINT pinctrl: samsung: Add GPIO to IRQ translation Documentation: Update samsung-pinctrl device tree bindings documentation .../bindings/pinctrl/samsung-pinctrl.txt | 118 +-- arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 278 arch/arm/boot/dts/exynos4210.dtsi | 241 +- drivers/pinctrl/pinctrl-exynos.c | 367 ++--- drivers/pinctrl/pinctrl-exynos.h | 170 ++ drivers/pinctrl/pinctrl-samsung.c | 203 drivers/pinctrl/pinctrl-samsung.h | 29 +- 7 files changed, 741 insertions(+), 665 deletions(-) -- 1.7.12 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] pinctrl: samsung: Detect and handle unsupported configuration types
Hi Linus, On Thu, Oct 11, 2012 at 10:57 PM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, Oct 11, 2012 at 10:11 AM, Tomasz Figa t.f...@samsung.com wrote: This patch modifies the pinctrl-samsung driver to detect when width of a bit field is set to zero (which means that such configuraton type is not supported) and return an error instead of trying to modify an inexistent register. Signed-off-by: Tomasz Figa t.f...@samsung.com I'm quite happy with these 17 patches, but I'd like to have Thomas Abraham's definitive ACK before I merge anything. Thomas did ACK at [00/17] ... mail. Thank you, Kyungmin Park Yours, Linus Walleij -- 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 -- 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: [Linaro-mm-sig] [PATCHv9 00/25] Integration of videobuf2 with DMABUF
On 10/10/12, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi, Em Tue, 02 Oct 2012 16:27:11 +0200 Tomasz Stanislawski t.stanisl...@samsung.com escreveu: Hello everyone, This patchset adds support for DMABUF [2] importing and exporting to V4L2 stack. v9: - rebase on 3.6 - change type for fs to __s32 - add support for vb2_ioctl_expbuf - remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING', it will be posted as a separate patch - fix typos and style in Documentation (from Hans Verkuil) - only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig - use data_offset and length while queueing DMABUF - return the most recently used fd at VIDIOC_DQBUF - use (buffer-type, index, plane) tuple instead of mem_offset to identify a for exporting (from Hans Verkuil) - support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart) - add testing alignment of vaddr and size while verifying userptr against DMA capabilities (from Laurent Pinchart) - substitute VM_DONTDUMP with VM_RESERVED - simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart) For now, NACK. See below. Sad news! It's failed to merge by very poor samsung board support at mainline. CC arm samsung mailing list. Thank you, Kyungmin Park I spent 4 days trying to setup an environment that would allow testing DMABUF with video4linux without success (long story, see below). Also, Laurent tried the same without any luck, and it seems that it even corrupted his test machine. Basically Samsung generously donated me two boards that it could be used on this test (Origen and SMDK310). None of them actually worked with the upstream kernel: patches are needed to avoid OOPSes on Origen; both Origen/SMDK310 defconfigs are completely broken, and drivers don't even boot if someone tries to use the Kernel's defconfigs. Even after spending _days_ trying to figure out the needed .config options (as the config files are not easily available), both boards have... issues: - lack of any display output driver at SMDK310; - lack of any network driver at Origen: it seems that none of the available network options on Origen was upstreamed: no Bluetooth, no OTG, no Wifi. The only test I was able to do (yesterday, late night), the DMABUF caused an OOPS at the Origen board. So, for sure it is not ready for upstream. It is now, too late for 3.7. I might consider it to 3.8, if something can be done to fix the existing issues, and setup a proper setup, using the upstream Kernel. Regards, Mauro ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- 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 0/6] ARM: EXYNOS: Add secure firmware support
Hi Arnd or Olof, Can you pick up for v3.7? To Tomasz, Can you rebase it on the latest arm-soc tree? Thank you, Kyungmin Park On Tue, Oct 2, 2012 at 6:13 PM, Tomasz Figa t.f...@samsung.com wrote: Hi, On Monday 24 of September 2012 16:28:27 Tomasz Figa wrote: Some Exynos-based boards are running with secure firmware running in TrustZone secure world, which changes the way some things have to be initialized. This series adds support for specifying firmware operations, implements some firmware operations for Exynos secure firmware and adds a method of enabling secure firmware operations on Exynos-based boards through board file and device tree. Changes since v1 http://thread.gmane.org/gmane.linux.kernel.samsung-soc/12583/focus=12820 - Changed return types of all operations to int - Defined all operations to return 0 on success, -ENOSYS when not implemented or appropriate error code on error Tomasz Figa (6): ARM: Add interface for registering and calling firmware-specific operations ARM: EXYNOS: Add support for secure monitor calls ARM: EXYNOS: Add support for secondary CPU bring-up on Exynos4412 ARM: EXYNOS: Add IO mapping for non-secure SYSRAM. ARM: EXYNOS: Add support for Exynos secure firmware ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up .../devicetree/bindings/arm/samsung-boards.txt | 8 arch/arm/common/Makefile | 2 + arch/arm/common/firmware.c | 18 arch/arm/include/asm/firmware.h| 31 + arch/arm/mach-exynos/Makefile | 6 +++ arch/arm/mach-exynos/common.c | 34 ++ arch/arm/mach-exynos/common.h | 2 + arch/arm/mach-exynos/exynos-smc.S | 22 + arch/arm/mach-exynos/firmware.c| 54 ++ arch/arm/mach-exynos/include/mach/map.h | 3 ++ arch/arm/mach-exynos/mach-exynos4-dt.c | 1 + arch/arm/mach-exynos/platsmp.c | 36 --- arch/arm/mach-exynos/smc.h | 31 + arch/arm/plat-samsung/include/plat/map-s5p.h | 1 + 14 files changed, 243 insertions(+), 6 deletions(-) create mode 100644 arch/arm/common/firmware.c create mode 100644 arch/arm/include/asm/firmware.h create mode 100644 arch/arm/mach-exynos/exynos-smc.S create mode 100644 arch/arm/mach-exynos/firmware.c create mode 100644 arch/arm/mach-exynos/smc.h Any comments, nitpicks or acks on this patchset? Best regards, -- Tomasz Figa Samsung Poland RD Center -- 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 -- 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 6/8] arm: exynos: config exynos5 hdmi-hpd gpio
On 10/5/12, Rahul Sharma rahul.sha...@samsung.com wrote:
This patch adds support for the configuration of exynos5 hdmi-hpd gpio.
It sets the gpio fucntion to EINT which is required for recieving
external hpd interrupt in drm hdmi driver.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/mach-exynos/mach-exynos5-dt.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 003963c..9a6d569 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -11,6 +11,7 @@
#include linux/of_platform.h
#include linux/serial_core.h
+#include linux/gpio.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
@@ -18,6 +19,7 @@
#include plat/cpu.h
#include plat/regs-serial.h
+#include plat/gpio-cfg.h
#include common.h
@@ -81,10 +83,17 @@ static void __init exynos5250_dt_map_io(void)
s3c24xx_init_clocks(2400);
}
+static void smdk_hpd_setup(void)
+{
+ s3c_gpio_cfgpin(EXYNOS5_GPX3(7), S3C_GPIO_SFN(0xf));
+ s3c_gpio_setpull(EXYNOS5_GPX3(7), S3C_GPIO_PULL_DOWN);
+}
these should be described at dts file instead of here. and name is not
good. smdk...
Thank you,
Kyungmin Park
+
static void __init exynos5250_dt_machine_init(void)
{
of_platform_populate(NULL, of_default_bus_match_table,
exynos5250_auxdata_lookup, NULL);
+ smdk_hpd_setup();
}
static char const *exynos5250_dt_compat[] __initdata = {
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ARM: Add interface for registering and calling firmware-specific operations
On 9/22/12, Olof Johansson o...@lixom.net wrote:
On Thu, Sep 13, 2012 at 10:13:35AM +0200, Tomasz Figa wrote:
Some boards are running with secure firmware running in TrustZone secure
world, which changes the way some things have to be initialized.
This patch adds an interface for platforms to specify available firmware
operations and call them.
A wrapper macro, call_firmware_op(), checks if the operation is provided
and calls it if so, otherwise returns 0.
By default no operations are provided.
This is a follow-up on the patch by Kyungmin Park:
[PATCH v5 1/2] ARM: Make a compile firmware conditionally
http://thread.gmane.org/gmane.linux.ports.arm.kernel/183607/focus=183988
Example of use:
In code using firmware ops:
__raw_writel(virt_to_phys(exynos4_secondary_startup),
CPU1_BOOT_REG);
/* Call Exynos specific smc call */
do_firmware_op(cpu_boot, cpu);
gic_raise_softirq(cpumask_of(cpu), 1);
In board-/platform-specific code:
static int platformX_do_idle(void)
{
/* tell platformX firmware to enter idle */
return 0;
}
static void platformX_cpu_boot(int i)
{
/* tell platformX firmware to boot CPU i */
}
static const struct firmware_ops platformX_firmware_ops __initdata = {
.do_idle= exynos_do_idle,
.cpu_boot = exynos_cpu_boot,
/* cpu_boot_reg not available on platformX */
};
static void __init board_init_early(void)
{
register_firmware_ops(platformX_firmware_ops);
}
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/common/Makefile| 2 ++
arch/arm/common/firmware.c | 18 ++
arch/arm/include/asm/firmware.h | 30 ++
3 files changed, 50 insertions(+)
create mode 100644 arch/arm/common/firmware.c
create mode 100644 arch/arm/include/asm/firmware.h
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..55d4182 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -2,6 +2,8 @@
# Makefile for the linux kernel.
#
+obj-y += firmware.o
+
obj-$(CONFIG_ARM_GIC) += gic.o
obj-$(CONFIG_ARM_VIC) += vic.o
obj-$(CONFIG_ICST) += icst.o
diff --git a/arch/arm/common/firmware.c b/arch/arm/common/firmware.c
new file mode 100644
index 000..27ddccb
--- /dev/null
+++ b/arch/arm/common/firmware.c
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics.
+ * Kyungmin Park kyungmin.p...@samsung.com
+ * Tomasz Figa t.f...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/suspend.h
+
+#include asm/firmware.h
+
+static const struct firmware_ops default_firmware_ops;
+
+const struct firmware_ops *firmware_ops = default_firmware_ops;
diff --git a/arch/arm/include/asm/firmware.h
b/arch/arm/include/asm/firmware.h
new file mode 100644
index 000..ed51b02
--- /dev/null
+++ b/arch/arm/include/asm/firmware.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics.
+ * Kyungmin Park kyungmin.p...@samsung.com
+ * Tomasz Figa t.f...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_ARM_FIRMWARE_H
+#define __ASM_ARM_FIRMWARE_H
+
+struct firmware_ops {
+int (*do_idle)(void);
+void (*cpu_boot)(int cpu);
+void __iomem *(*cpu_boot_reg)(int cpu);
+};
+
+extern const struct firmware_ops *firmware_ops;
+
+#define call_firmware_op(op, ...) \
+((firmware_ops-op) ? firmware_ops-op(__VA_ARGS__) : 0)
I think this will cause sparse warnings for call_firmware_op(cpu_boot_reg)
if there are no ops defined, since the '0' isn't annotated as __iomem. And
you can't annotate it since the other function pointers don't need it.
I think you might be better off with stub functions as fallbacks instead of
allowing and checking for NULL here.
do you mean like this?
#Ifdef CONFIG_ARM_FIRMWARE
#define call_firmware_op(op, ...) ((firmware_ops-op) ?
firmware_ops-op(__VA_ARGS__) : 0)
#else
#define call_firmware_op(op, ...) do { } while (0)
#endif
No problem to modify it.
Thank you,
Kyungmin Park
-Olof
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message
Re: [PATCH 4/5] ARM: EXYNOS: Add support for Exynos secure firmware
On 9/22/12, Olof Johansson o...@lixom.net wrote:
On Fri, Sep 21, 2012 at 10:57 PM, Kyungmin Park
kyungmin.p...@samsung.com wrote:
On 9/22/12, Olof Johansson o...@lixom.net wrote:
On Wed, Sep 19, 2012 at 3:10 AM, Tomasz Figa t.f...@samsung.com wrote:
Hi Olof,
On Saturday 15 of September 2012 17:44:55 Olof Johansson wrote:
On Thu, Sep 13, 2012 at 10:13:37AM +0200, Tomasz Figa wrote:
+static void __iomem *exynos_cpu_boot_reg(int cpu)
+{
+ return S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+}
This communication area in sysram should probably be seen as a part of
the firmware interface. It should thus be defined as part of the
binding
instead, i.e. through a reg property or similar there. That also
would
make it easy to convert to using ioremap() instead of iodesc tables,
which always a nice thing.
The problem with SYSRAM_NS is that it might be also used in other code,
not
related to firmware only. I don't know exactly all the use cases for
it.
If you don't know the use cases, and the use cases are not in the
kernel tree that we care about here (upstream), then there's really
nothing to worry about. It's after all just a define that's moved to
an ioremap, if there's some out of tree code that needs the old legacy
define then it can be added in whatever out-of-tree code that uses it.
Right?
Now this address is used at cpu boot, cpuidle, inform at this time.
As it touched at several places, it's defined at iodesc. if it changed
with ioremap, it has to export remaped address and each codes should
use it.
Won't you have to push down all the references to VA_SYSRAM vs
VA_SYSRAM_NS into the firmware interface anyway, since you will need
to use different addresses for whether you have firmware enabled or
not? I.e. you'll have a firmware call at the appropriate level for
the non-trustzone cases that uses the equivalent of VA_SYSRAM, and for
the trustzone firmware op you'll use VA_SYSRAM_NS?
Right, in case of no firmware, it uses VA_SYSRAM, but VA_SYSRAM_NS is
used at firmware case.
As I wrote at cover letter, if you want to use ioremap, it can be
modified. however can you merge firmware codes itself? since ioremap
is not related with trustzone or firmware issues and it's exynos
specific implementation issues. Right?
I'm not quite sure which part you are asking me to merge, if it's the
infrastructure pieces or the exynos-specific pieces.
Either way, one isn't really usable without the other, and it doesn't
make sense to merge code that can't be used. Infrastructure is best
merged together with the first user of it.
Okay, we will fix it.
Thank you,
Kyungmin Park
--
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/5] ARM: EXYNOS: Add secure firmware support
On 9/19/12, Tomasz Figa t.f...@samsung.com wrote: Hi, On Thursday 13 of September 2012 10:13:33 Tomasz Figa wrote: Some Exynos-based boards are running with secure firmware running in TrustZone secure world, which changes the way some things have to be initialized. This series adds support for specifying firmware operations, implements some firmware operations for Exynos secure firmware and adds a method of enabling secure firmware operations on Exynos-based boards through board file and device tree. This is a continuation of the patch series by Kyungmin Park: [PATCH v5 1/2] ARM: Make a compile firmware conditionally http://thread.gmane.org/gmane.linux.ports.arm.kernel/183607 [PATCH v5 2/2] ARM: EXYNOS: SMC instruction (aka firmware) support http://thread.gmane.org/gmane.linux.ports.arm.kernel/183608/focus=184109 Tomasz Figa (5): ARM: EXYNOS: Add IO mapping for non-secure SYSRAM. ARM: Add interface for registering and calling firmware-specific operations ARM: EXYNOS: Add support for secure monitor calls ARM: EXYNOS: Add support for Exynos secure firmware ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up .../devicetree/bindings/arm/samsung-boards.txt | 8 arch/arm/common/Makefile | 2 + arch/arm/common/firmware.c | 18 arch/arm/include/asm/firmware.h| 30 + arch/arm/mach-exynos/Makefile | 6 +++ arch/arm/mach-exynos/common.c | 34 ++ arch/arm/mach-exynos/common.h | 2 + arch/arm/mach-exynos/exynos-smc.S | 22 + arch/arm/mach-exynos/firmware.c| 52 ++ arch/arm/mach-exynos/include/mach/map.h | 3 ++ arch/arm/mach-exynos/mach-exynos4-dt.c | 1 + arch/arm/mach-exynos/platsmp.c | 8 arch/arm/mach-exynos/smc.h | 31 + arch/arm/plat-samsung/include/plat/map-s5p.h | 1 + 14 files changed, 218 insertions(+) create mode 100644 arch/arm/common/firmware.c create mode 100644 arch/arm/include/asm/firmware.h create mode 100644 arch/arm/mach-exynos/exynos-smc.S create mode 100644 arch/arm/mach-exynos/firmware.c create mode 100644 arch/arm/mach-exynos/smc.h Any further comments for this series? Maybe we could merge it for 3.7? Hi Arnd, Olof, Can you merge it for 3.7? If exynos implementation still has issues, it's okay only merge firmware implementation. Can you give your opinions? Thank you, Kyungmin Park -- 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/5] ARM: EXYNOS: Add support for Exynos secure firmware
On 9/22/12, Olof Johansson o...@lixom.net wrote:
On Wed, Sep 19, 2012 at 3:10 AM, Tomasz Figa t.f...@samsung.com wrote:
Hi Olof,
On Saturday 15 of September 2012 17:44:55 Olof Johansson wrote:
On Thu, Sep 13, 2012 at 10:13:37AM +0200, Tomasz Figa wrote:
+static void __iomem *exynos_cpu_boot_reg(int cpu)
+{
+ return S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+}
This communication area in sysram should probably be seen as a part of
the firmware interface. It should thus be defined as part of the binding
instead, i.e. through a reg property or similar there. That also would
make it easy to convert to using ioremap() instead of iodesc tables,
which always a nice thing.
The problem with SYSRAM_NS is that it might be also used in other code,
not
related to firmware only. I don't know exactly all the use cases for it.
If you don't know the use cases, and the use cases are not in the
kernel tree that we care about here (upstream), then there's really
nothing to worry about. It's after all just a define that's moved to
an ioremap, if there's some out of tree code that needs the old legacy
define then it can be added in whatever out-of-tree code that uses it.
Right?
Now this address is used at cpu boot, cpuidle, inform at this time.
As it touched at several places, it's defined at iodesc. if it changed
with ioremap, it has to export remaped address and each codes should
use it.
As I wrote at cover letter, if you want to use ioremap, it can be
modified. however can you merge firmware codes itself? since ioremap
is not related with trustzone or firmware issues and it's exynos
specific implementation issues. Right?
Thank you,
Kyungmin Park
Is it really a big problem or we could let it be for now, merge the
patches
for firmware and then convert SYSRAM_NS to dynamic mapping when its
situation clarifies?
What do you expect is required to clarify the situation, and when do
you expect that to happen?
-Olof
--
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
--
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 V4 2/2] video: drm: exynos: Add device tree support
Hi,
On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala
l.kris...@samsung.com wrote:
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95
-
2 files changed, 173 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..4ff1829
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fb for
Doesn't better to use single word? fimd or fb?. I think 'fb' is used
for framebuffer historically.
but now it's used both fb and drm, so fimd is neutral and architecture
specific.
To do this, Modify arch-exynos first and update it at each drivers it properly.
Thank you,
Kyungmin Park
+ fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+ specified in the following order.
+ - VSYNC interrupt
+ - FIFO level interrupt
+ - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+ display device node which holds the video interface timing with the
+ below mentioned properties.
+
+ - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+ - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+ The following is an example for the fimd controller is split into
+ two portions. The SoC specific portion can be specified in the SoC
+ specific dts file. The board specific portion can be specified in the
+ board specific dts file.
+
+ - SoC Specific portion
+
+ fimd {
+ compatible = samsung,exynos5-fimd;
+ interrupt-parent = combiner;
+ reg = 0x1440 0x4;
+ interrupts = 18 5, 18 4, 18 6;
+ };
+
+ - Board Specific portion
+
+ lcd_fimd0: lcd_panel0 {
+ lcd-htiming = 4 4 4 480;
+ lcd-vtiming = 4 4 4 320;
+ supports-mipi-panel;
+ };
+
+ fimd {
+ samsung,fimd-display = lcd_fimd0;
+ samsung,fimd-vidout-rgb;
+ samsung,fimd-inv-vclk;
+ samsung,fimd-frame-rate = 60;
+ samsung,default-window = 0;
+ samsung,fimd-win-bpp = 32;
+ };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 3701fbe..a4fa8e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/pm_runtime.h
+#include linux/of.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
};
+static const struct of_device_id fimd_dt_match[];
+
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
{
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_ptr(fimd_dt_match);
+ return (struct fimd_driver_data *)match-data;
+ }
+#endif
return (struct fimd_driver_data
Re: [PATCH 1/2] ARM: exynos: delete redundant HAVE_SCHED_CLOCK option in Kconfig
Hi, then where select it HAVE_SCHED_CLOCK? apart from other exynos board, universal have to use another clock. Thank you, Kyungmin Park On 8/31/12, Barry Song barry.s...@csr.com wrote: From: Barry Song baohua.s...@csr.com Signed-off-by: Barry Song baohua.s...@csr.com --- arch/arm/mach-exynos/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index b5b4c8c..3fd4ab3 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -243,7 +243,6 @@ config MACH_UNIVERSAL_C210 select CPU_EXYNOS4210 select S5P_HRT select CLKSRC_MMIO - select HAVE_SCHED_CLOCK select S5P_GPIO_INT select S5P_DEV_FIMC0 select S5P_DEV_FIMC1 -- 1.7.0.4 Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: exynos: delete redundant HAVE_SCHED_CLOCK option in Kconfig
Acked-by: Kyungmin Park kyungmin.p...@samsung.com # git grep HAVE_SCHED_CLOCK arch/arm/ arch/arm/Kconfig: select HAVE_SCHED_CLOCK arch/arm/mach-exynos/Kconfig: select HAVE_SCHED_CLOCK On 8/31/12, Barry Song 21cn...@gmail.com wrote: 2012/8/31 Kyungmin Park kmp...@infradead.org: Hi, then where select it HAVE_SCHED_CLOCK? apart from other exynos board, universal have to use another clock. The old arch/arm/kernel/Makefile: obj-$(CONFIG_HAVE_SCHED_CLOCK) += sched_clock.o has become: obj-y += sched_clock.o Thank you, Kyungmin Park On 8/31/12, Barry Song barry.s...@csr.com wrote: From: Barry Song baohua.s...@csr.com Signed-off-by: Barry Song baohua.s...@csr.com --- arch/arm/mach-exynos/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index b5b4c8c..3fd4ab3 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -243,7 +243,6 @@ config MACH_UNIVERSAL_C210 select CPU_EXYNOS4210 select S5P_HRT select CLKSRC_MMIO - select HAVE_SCHED_CLOCK select S5P_GPIO_INT select S5P_DEV_FIMC0 select S5P_DEV_FIMC1 -- 1.7.0.4 -barry -- 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 -- 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] ARM: EXYNOS: Add support for Trats board using device tree
+ Thomas Abraham, -Original Message- From: Tomasz Figa [mailto:t.f...@samsung.com] Sent: Wednesday, August 29, 2012 10:13 PM To: linux-samsung-soc@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; kyungmin.p...@samsung.com; kgene@samsung.com; jy0922.s...@samsung.com; Tomasz Figa Subject: [PATCH 0/6] ARM: EXYNOS: Add support for Trats board using device tree This patch series adds basic device tree support for Samsung Trats board along with any necessary prerequisites. In addition it refactors Exynos4 dts include files to split parts common to the whole Exynos4 part from parts specific to Exynos4210 to allow further extension of Exynos4210 dts include file and addition of include files for other SoCs from Exynos4 line. Dependencies: - [PATCH v5] mmc: sdhci-s3c: Add device tree support http://www.spinics.net/lists/linux-samsung-soc/msg12056.html - [PATCH v5 2/2] regulator: add device tree support for max8997 http://www.spinics.net/lists/kernel/msg1328117.html Tomasz Figa (6): ARM: dts: Move parts common to Exynos4 from Exynos4210.dtsi to Exynos4.dtsi ARM: EXYNOS: exynos4-dt: Use exynos4 prefix instead of exynos4210 ARM: Exynos4: dts: Specify address and size cells for i2c controllers ARM: Exynos4: Add OF compatibility lookups for Exynos4 i2c adapters ARM: EXYNOS: Increase maximum possible memory bank size to 512MiB ARM: Exynos: Add basic dts file for Samsung Trats board arch/arm/boot/dts/exynos4.dtsi | 418 + arch/arm/boot/dts/exynos4210-trats.dts | 287 arch/arm/boot/dts/exynos4210.dtsi | 377 +- arch/arm/mach-exynos/Makefile.boot | 2 +- arch/arm/mach-exynos/include/mach/memory.h | 4 +- arch/arm/mach-exynos/mach-exynos4-dt.c | 34 ++- 6 files changed, 734 insertions(+), 388 deletions(-) create mode 100644 arch/arm/boot/dts/exynos4.dtsi create mode 100644 arch/arm/boot/dts/exynos4210-trats.dts -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: EXYNOS: Use EXYNOS4210_GPEx instead of EXYNOS4_GPEx
On 8/29/12, Kukjin Kim kgene@samsung.com wrote:
On 08/28/12 03:06, Tomasz Figa wrote:
The GPEx gpios are specific to Exynos4210 and do not exist on Exynos4x12.
Redefine them to use the exact SoC name.
Based on ARM: EXYYNOS: Use EXYNOS4210_GPEx instead of EXYNOS4_GPEx by
Joonyoung Shim, see:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/100738.html
Signed-off-by: Tomasz Figat.f...@samsung.com
---
arch/arm/mach-exynos/include/mach/gpio.h | 32
+++---
arch/arm/mach-exynos/mach-nuri.c | 16 +++
arch/arm/mach-exynos/mach-origen.c | 6 +++---
arch/arm/mach-exynos/mach-trats.c | 4 ++--
arch/arm/mach-exynos/mach-universal_c210.c | 32
+++---
arch/arm/mach-exynos/setup-fimc.c | 4 ++--
drivers/gpio/gpio-samsung.c| 20 +--
7 files changed, 57 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/gpio.h
b/arch/arm/mach-exynos/include/mach/gpio.h
index eb24f1e..21c9bf1 100644
--- a/arch/arm/mach-exynos/include/mach/gpio.h
+++ b/arch/arm/mach-exynos/include/mach/gpio.h
@@ -26,11 +26,11 @@
#define EXYNOS4_GPIO_C1_NR (5)
#define EXYNOS4_GPIO_D0_NR (4)
#define EXYNOS4_GPIO_D1_NR (4)
-#define EXYNOS4_GPIO_E0_NR (5)
-#define EXYNOS4_GPIO_E1_NR (8)
-#define EXYNOS4_GPIO_E2_NR (6)
-#define EXYNOS4_GPIO_E3_NR (8)
-#define EXYNOS4_GPIO_E4_NR (8)
+#define EXYNOS4210_GPIO_E0_NR (5)
+#define EXYNOS4210_GPIO_E1_NR (8)
+#define EXYNOS4210_GPIO_E2_NR (6)
+#define EXYNOS4210_GPIO_E3_NR (8)
+#define EXYNOS4210_GPIO_E4_NR (8)
Please see my comments on Joonyoung Shim's previous patch...
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-May/101522.html
It's perference issue. some person like this style. others doesn't.
Moreever vender, System LSI, provided codes have whole different style.
It lists up whole gpios for each SoCs.
EXYNOS4210_{A0, Z}
EXYNOS4412_{A0, V4}
EXYNOS5250_{A0, Z}
anyway, just remain it as broken, and try to use pinctl as Thomas mentioned.
Thank you,
Kyungmin Park
[...]
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
--
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: EXYNOS: Use non-secure MDMA1
On 8/29/12, Kukjin Kim kgene@samsung.com wrote:
On 08/28/12 04:08, Tomasz Figa wrote:
Using secure MDMA1 on TrustZone-enabled boards causes early boot crash,
so use non-secure instead.
Signed-off-by: Tomasz Figat.f...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/dma.c | 2 +-
arch/arm/mach-exynos/include/mach/map.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
index f60b66d..8858df5 100644
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@ -261,7 +261,7 @@ static struct dma_pl330_platdata exynos_mdma1_pdata =
{
};
static AMBA_AHB_DEVICE(exynos_mdma1, dma-pl330.2, 0x00041330,
-EXYNOS4_PA_MDMA1, {EXYNOS4_IRQ_MDMA1},exynos_mdma1_pdata);
+EXYNOS4_PA_NS_MDMA1, {EXYNOS4_IRQ_MDMA1},exynos_mdma1_pdata);
static int __init exynos_dma_init(void)
{
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
exynos/include/mach/map.h
index 51943f2..5df5910 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -89,7 +89,8 @@
#define EXYNOS4_PA_L2CC0x10502000
#define EXYNOS4_PA_MDMA0 0x1081
-#define EXYNOS4_PA_MDMA10x1284
+#define EXYNOS4_PA_S_MDMA1 0x1284
+#define EXYNOS4_PA_NS_MDMA1 0x1285
#define EXYNOS4_PA_PDMA0 0x1268
#define EXYNOS4_PA_PDMA1 0x1269
#define EXYNOS5_PA_MDMA0 0x1080
Cc'ed Boojin Kim.
Well, just fix the address is enough like exynos5 stuff? I don't have
any idea why we need secure mdma and non-secure mdma both here...
Did you see the datasheet and your team codes?
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index c72b675..c941053 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -89,7 +89,7 @@
#define EXYNOS4_PA_L2CC0x10502000
#define EXYNOS4_PA_MDMA00x1081
-#define EXYNOS4_PA_MDMA1 0x1284
+#define EXYNOS4_PA_MDMA1 0x1285
#define EXYNOS4_PA_PDMA00x1268
#define EXYNOS4_PA_PDMA10x1269
#define EXYNOS5_PA_MDMA00x1080
--
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] ODROID-X: hkdk4412: Add new hardware based on Exynos4412
On 8/7/12, Thomas Abraham thomas.abra...@linaro.org wrote: On 7 August 2012 07:58, Olof Johansson o...@lixom.net wrote: Hi, On Mon, Aug 6, 2012 at 7:05 PM, Dongjin Kim dongjin@agreeyamobility.net wrote: Hello, I am trying to understand what I have to do for device tree. In order to create dts file for ODROID-X hardware, it seems I may need dts file of EXYNOS4412 SoC. But maybe exynos4412.dtsi is not merged yet or not exist, like exynos4210.dtsi or exynos5250.dtsi. Obviously it seems not easy to create such a file without SoC datasheet, and I do not have it. So do I wait for the file to be merged by Samsung or better to create initial dts file cloned from exynos4210.dtsi and modify to have verified nodes with the source/header files? Ideally they already have one waiting to be submitted, but that might not be the case. Given that the origenboard design with 4412 is not yet shipping, I'm guessing the Linaro Samsung engineers might not have done much work on 4412 yet. Kukjin? Thomas? What's your suggestion? The alternative is to use the data you have available -- i.e. sources and patches, and craft the device tree from there. The design of 4412 is a derivative from 4210, so that's a good start. Next step would be to describe the board on top of the SoC, peripherals, etc. Take a look at how the origen board support was added, and so on. I ordered an odroid-x several weeks ago but I haven't have a confirmed shipping date yet. :( I'm not sure how long it'll be before I can help out, unfortunately. -Olof Most of the Exynos4210 device tree support can be reused for Exynos4412 as well. Looking at the hardware differences between the two, it might be better to create a new exynos4.dtsi file (kind of creating it out of the existing exynos4210.dtsi) which will have all the common bits across all SoC's in the Exynos4 family. Further, there can be exynos4210.dtsi and exynos4412.dtsi which would specify SoC specific differences such as the GIC cpu-offset property and the additional groups available in the interrupt combiner. There are differences in the gpio/pinmux controllers as well which have to be described using device tree. The current gpio/pinmux device tree support depends entirely on the gpio-samsung driver which handles both gpio and pinmux but requires listing all the banks available in Exynos4412. I would prefer not to do that since we are switching over to using a pin controller driver and I am currently working on this driver. The pin controller driver is important without which the gpio/pinmux/pinconf setting for devices such as i2c and sdhci controller cannot be setup. The basic pinctrl driver for Exynos4 has already been posted and now I am working on adding gpio and wakeup interrupt support into that driver (hoping to complete it this week). So the probable steps in getting started with using device tree for Exynos4412 would be 1. Create a new exynos4.dtsi file with all the Exynos4 common properties for all dt supported controllers. 2. Update the exynos4210.dtsi file accordingly and add the new exynos4412.dtsi file. 3. With this, it will be possible to boot the kernel and test peripherals that do not depend on gpio/pinmux (rtc, wdt, etc). 4. When the Exynos4 pinctrl driver is available, start adding device nodes for i2c and sdhci controllers. 5. Incrementally add device tree coverage for the board and other peripherals on Exynos4412. Nice! Good plan as I thnk. Thank you, Kyungmin Park -- 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 5/5] ARM: exynos: add thermal sensor driver platform data support
On Fri, Jul 13, 2012 at 8:10 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
Add necessary default platform data support needed for TMU driver. This
dt/non-dt values are tested for origen exynos4210 and smdk exynos5250
platforms.
Looks good to me.
just nitpicks below.
Thank you,
Kyungmin Park
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
Cc: Donggeun Kim dg77@samsung.com
Acked-by: Guenter Roeck guenter.ro...@ericsson.com
Cc: SangWook Ju sw...@samsung.com
Cc: Durgadoss durgados...@intel.com
Cc: Len Brown l...@kernel.org
Cc: Jean Delvare kh...@linux-fr.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/thermal/exynos_thermal.c | 111
+-
1 files changed, 110 insertions(+), 1 deletions(-)
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
index 9ef8c37..07736ea 100644
--- a/drivers/thermal/exynos_thermal.c
+++ b/drivers/thermal/exynos_thermal.c
@@ -662,14 +662,121 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
static struct thermal_sensor_conf exynos_sensor_conf = {
.name = exynos-therm,
.read_temperature = (int (*)(void *))exynos_tmu_read,
+};
+
+#if defined(CONFIG_CPU_EXYNOS4210)
BTW, doesn't it same as exynos4412? does it different from exynos4412?
If it's same, it's better to use CONFIG_SOC_EXYNOS4?
+static struct exynos_tmu_platform_data const exynos4_default_tmu_data = {
+ .threshold = 80,
+ .trigger_levels[0] = 5,
+ .trigger_levels[1] = 20,
+ .trigger_levels[2] = 30,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 15,
+ .reference_voltage = 7,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 100,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS4,
+};
+#define EXYNOS4_TMU_DRV_DATA (exynos4_default_tmu_data)
+#else
+#define EXYNOS4_TMU_DRV_DATA (NULL)
+#endif
+
+#if defined(CONFIG_SOC_EXYNOS5250)
similar.
+static struct exynos_tmu_platform_data const exynos5_default_tmu_data = {
+ .trigger_levels[0] = 85,
+ .trigger_levels[1] = 103,
+ .trigger_levels[2] = 110,
+ .trigger_level0_en = 1,
+ .trigger_level1_en = 1,
+ .trigger_level2_en = 1,
+ .trigger_level3_en = 0,
+ .gain = 8,
+ .reference_voltage = 16,
+ .noise_cancel_mode = 4,
+ .cal_type = TYPE_ONE_POINT_TRIMMING,
+ .efuse_value = 55,
+ .freq_tab[0] = {
+ .freq_clip_max = 800 * 1000,
+ .temp_level = 85,
+ },
+ .freq_tab[1] = {
+ .freq_clip_max = 200 * 1000,
+ .temp_level = 103,
+ },
+ .freq_tab_count = 2,
+ .type = SOC_ARCH_EXYNOS5,
+};
+#define EXYNOS5_TMU_DRV_DATA (exynos5_default_tmu_data)
+#else
+#define EXYNOS5_TMU_DRV_DATA (NULL)
+#endif
+
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_tmu_match[] = {
+ {
+ .compatible = samsung,exynos4-tmu,
+ .data = (void *)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .compatible = samsung,exynos5-tmu,
+ .data = (void *)EXYNOS5_TMU_DRV_DATA,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_tmu_match);
+#else
+#define exynos_tmu_match NULL
+#endif
+
+static struct platform_device_id exynos_tmu_driver_ids[] = {
+ {
+ .name = exynos4-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS4_TMU_DRV_DATA,
+ },
+ {
+ .name = exynos5-tmu,
+ .driver_data= (kernel_ulong_t)EXYNOS5_TMU_DRV_DATA,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, exynos4_tmu_driver_ids);
+
+static inline struct exynos_tmu_platform_data *exynos_get_driver_data(
+ struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+ if (pdev-dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(exynos_tmu_match, pdev-dev.of_node);
+ if (!match)
+ return NULL;
+ return (struct exynos_tmu_platform_data *) match-data;
+ }
+#endif
+ return (struct exynos_tmu_platform_data *)
+ platform_get_device_id(pdev)-driver_data;
}
-;
static int __devinit exynos_tmu_probe(struct platform_device *pdev)
{
struct exynos_tmu_data *data;
struct exynos_tmu_platform_data *pdata = pdev-dev.platform_data;
int ret, i;
+ if (!pdata)
+ pdata = exynos_get_driver_data(pdev
Re: [PATCH 05/20] ARM: EXYNOS: Redefine IRQ_MCT_L0,1 definition
Hi,
On Tue, May 1, 2012 at 4:14 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
From: Changhwan Youn chaos.y...@samsung.com
Redefine IRQ_MCT_L0,1 irq definition as it is changed in rev1 of EXYNOS5.
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Signed-off-by: Kukjin Kim kgene@samsung.com
---
 arch/arm/mach-exynos/include/mach/irqs.h |   4 ++--
 arch/arm/mach-exynos/mct.c        |  17 +++--
 2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/irqs.h
b/arch/arm/mach-exynos/include/mach/irqs.h
index 591e7852..ef52f61 100644
--- a/arch/arm/mach-exynos/include/mach/irqs.h
+++ b/arch/arm/mach-exynos/include/mach/irqs.h
@@ -331,6 +331,8 @@
 #define EXYNOS5_IRQ_SATA        IRQ_SPI(115)
 #define EXYNOS5_IRQ_NFCON        IRQ_SPI(116)
+#define EXYNOS5_IRQ_MCT_L0 Â Â Â Â Â Â IRQ_SPI(120)
+#define EXYNOS5_IRQ_MCT_L1 Â Â Â Â Â Â IRQ_SPI(121)
 #define EXYNOS5_IRQ_MMC44        IRQ_SPI(123)
 #define EXYNOS5_IRQ_MDMA1        IRQ_SPI(124)
 #define EXYNOS5_IRQ_FIMC_LITE0     IRQ_SPI(125)
@@ -410,8 +412,6 @@
 #define EXYNOS5_IRQ_FIMD1_SYSTEM    COMBINER_IRQ(18, 6)
 #define EXYNOS5_IRQ_EINT0        COMBINER_IRQ(23, 0)
-#define EXYNOS5_IRQ_MCT_L0 Â Â Â Â Â Â COMBINER_IRQ(23, 1)
-#define EXYNOS5_IRQ_MCT_L1 Â Â Â Â Â Â COMBINER_IRQ(23, 2)
 #define EXYNOS5_IRQ_MCT_G0       COMBINER_IRQ(23, 3)
 #define EXYNOS5_IRQ_MCT_G1       COMBINER_IRQ(23, 4)
 #define EXYNOS5_IRQ_MCT_G2       COMBINER_IRQ(23, 5)
diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index 897d9a9..b601fb8 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -388,6 +388,7 @@ static int __cpuinit exynos4_local_timer_setup(struct
clock_event_device *evt)
 {
    struct mct_clock_event_device *mevt;
    unsigned int cpu = smp_processor_id();
+ Â Â Â int mct_lx_irq;
    mevt = this_cpu_ptr(percpu_mct_tick);
    mevt-evt = evt;
@@ -414,14 +415,18 @@ static int __cpuinit exynos4_local_timer_setup(struct
clock_event_device *evt)
    if (mct_int_type == MCT_INT_SPI) {
        if (cpu == 0) {
+ Â Â Â Â Â Â Â Â Â Â Â mct_lx_irq = soc_is_exynos4210() ? EXYNOS4_IRQ_MCT_L0
:
+ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â EXYNOS5_IRQ_MCT_L0;
Does it still valid for exynos4x12?. It means exynos4x12 uses
EXYNOS5_IRQ_MCT_L0?
            mct_tick0_event_irq.dev_id = mevt;
- Â Â Â Â Â Â Â Â Â Â Â evt-irq = EXYNOS4_IRQ_MCT_L0;
- Â Â Â Â Â Â Â Â Â Â Â setup_irq(EXYNOS4_IRQ_MCT_L0, mct_tick0_event_irq);
+ Â Â Â Â Â Â Â Â Â Â Â evt-irq = mct_lx_irq;
+ Â Â Â Â Â Â Â Â Â Â Â setup_irq(mct_lx_irq, mct_tick0_event_irq);
        } else {
+ Â Â Â Â Â Â Â Â Â Â Â mct_lx_irq = soc_is_exynos4210() ? EXYNOS4_IRQ_MCT_L1
:
+ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â EXYNOS5_IRQ_MCT_L1;
ditto
            mct_tick1_event_irq.dev_id = mevt;
- Â Â Â Â Â Â Â Â Â Â Â evt-irq = EXYNOS4_IRQ_MCT_L1;
- Â Â Â Â Â Â Â Â Â Â Â setup_irq(EXYNOS4_IRQ_MCT_L1, mct_tick1_event_irq);
- Â Â Â Â Â Â Â Â Â Â Â irq_set_affinity(EXYNOS4_IRQ_MCT_L1, cpumask_of(1));
+ Â Â Â Â Â Â Â Â Â Â Â evt-irq = mct_lx_irq;
+ Â Â Â Â Â Â Â Â Â Â Â setup_irq(mct_lx_irq, mct_tick1_event_irq);
+ Â Â Â Â Â Â Â Â Â Â Â irq_set_affinity(mct_lx_irq, cpumask_of(1));
        }
    } else {
        enable_percpu_irq(EXYNOS_IRQ_MCT_LOCALTIMER, 0);
@@ -473,7 +478,7 @@ static void __init exynos4_timer_resources(void)
 static void __init exynos4_timer_init(void)
 {
- Â Â Â if (soc_is_exynos4210())
+ Â Â Â if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
        mct_int_type = MCT_INT_SPI;
    else
        mct_int_type = MCT_INT_PPI;
BTW exynos4x12 uses MCT_INT_PPI?
Kyungmin Park
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v3 0/2] regulator: Add initial suport for max77686
Hi Mark, BTW, do you know that you're reviewing the same device driver patch from different person? One from Mr. Lee and another from Yadwinder. I wonder how to handle it finally. which one is choose? Thank you, Kyungmin Park On 5/22/12, yadi.bra...@gmail.com yadi.bra...@gmail.com wrote: From: Yadwinder Singh Brar yadi.b...@samsung.com This patch series adds support for max77686 which is a multifunction device which includes regulator (pmic), rtc and charger sub-blocks within it. The support for mfd driver and regulator driver are added by this patch series. This patch series also includes device tree and irqdomain support for mfd and regulator portions. Implemented the required modification, stated in the recieved review comments. changes since v1: -added regmap support. -implemented .get_voltage_sel, .set_voltage_sel and .set_voltage_time_sel after removing .get_voltage and .set_voltage in regulator driver. -used of_regulator_match() for parsing DT. -added Documentation for Devive Tree binding. changes since v2: -converted to use regulator_get_voltage_sel_regmap, regulator_set_voltage_sel_regmap, regulator_enable_regmap, regulator_disable_regmap, regulator_is_enabled_regmap. This patch series is based on mark_regulator/for-next and has been tested on GAIA board. Yadwinder Singh Brar (2): mfd: Add support for MAX77686. regulator: Add support for MAX77686. Documentation/devicetree/bindings/mfd/max77686.txt | 61 +++ drivers/mfd/Kconfig| 21 + drivers/mfd/Makefile |1 + drivers/mfd/max77686-irq.c | 255 + drivers/mfd/max77686.c | 322 drivers/regulator/Kconfig |9 + drivers/regulator/Makefile |1 + drivers/regulator/max77686.c | 389 include/linux/mfd/max77686-private.h | 282 ++ include/linux/mfd/max77686.h | 100 + 10 files changed, 1441 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/max77686.txt create mode 100644 drivers/mfd/max77686-irq.c create mode 100644 drivers/mfd/max77686.c create mode 100644 drivers/regulator/max77686.c create mode 100644 include/linux/mfd/max77686-private.h create mode 100644 include/linux/mfd/max77686.h -- 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 -- 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/3] Add support for DRM display subsystem
On 5/10/12, Kukjin Kim kgene@samsung.com wrote: Marek Szyprowski wrote: Hello, This patch set adds support for Exynos DRM display subsystem for Universal C210 and NURI boards. Exynos DRM driver has been merged to 3.3 kernel tree and provides unified and more powerful alternative for s3c-fb and s5p-tv drivers. V2 includes update for the latest changes in platform data structure (added 'panel' entry). Best regards Marek Szyprowski Samsung Poland RD Center Patch summary: Marek Szyprowski (3): ARM: Exynos: add platform device for core DRM subsystem ARM: Exynos: Add DRM core device support for Universal C210 board ARM: Exynos: Add DRM core support for NURI board arch/arm/mach-exynos/Kconfig |7 ++ arch/arm/mach-exynos/Makefile |1 + arch/arm/mach-exynos/dev-drm.c | 29 arch/arm/mach-exynos/mach-nuri.c | 33 arch/arm/mach-exynos/mach-universal_c210.c | 33 arch/arm/plat-samsung/include/plat/devs.h |2 + 6 files changed, 105 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-exynos/dev-drm.c -- 1.7.1.569.g6f426 Well, 2nd and 3rd patches can break multi-platform for EXYNOS SoCs with one kernel image. And I won't apply new feature for non-dt board file from now on. I think, we need to support DT in mach-exynos/ instead of non-DT and DT together, so please consider to move on dt supporting for Samsung mobile boards. Probably you misunderstand Arnd word. From the statements made so far, I can see no clear policy that we can apply to everyone. My take on this is that for any work I spend on multiplatform kernel, I concentrate on the DT-based board files and get them to work together first, but leave it up to the individual subarch maintainers whether they want to add other board files into the mix. It doesn't mean add new feature to non-DT board. don't add new board file. In this case, DRM is not yet ready to support DT. Okay, you can just drop this patches. but please note that this patches are posted at Mar 13 before you decide. BR, Kyungmin Park Note that I have a plan to replace board files with DT supporting in mach-exynos/ next time. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
On 5/10/12, Thomas Abraham thomas.abra...@linaro.org wrote:
Dear Mr. Park,
On 2 May 2012 12:25, Kyungmin Park kmp...@infradead.org wrote:
Hi,
On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
Add device tree based discovery support.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
drivers/mmc/host/dw_mmc-pltfm.c| 24 +++
drivers/mmc/host/dw_mmc.c | 181
+++-
drivers/mmc/host/dw_mmc.h | 10 +
include/linux/mmc/dw_mmc.h |2 +
5 files changed, 296 insertions(+), 6 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
new file mode 100644
index 000..c1ed70e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
@@ -0,0 +1,85 @@
+* Synopsis Designware Mobile Storage Host Controller
+
+The Synopsis designware mobile storage host controller is used to
interface
+a SoC with storage medium such as eMMC or SD/MMC cards.
+
+Required Properties:
+
+* compatible: should be one of the following
+ - synopsis,dw-mshc: for controllers compliant with synopsis
dw-mshc.
I googled the Synopsis Designware Mobile Storage Host Controller and
Synopsis released it as this name. but still I like the 'dw-mmc'
instead of'dw-mshc'.
Ok. Synopsis abbreviates this controller as MSHC in their datasheets
available online. Since device tree is more about describing the
hardware, using MSHC as the abbreviation will help with correlating
hardware specs with the dts file. So I would prefer to continue using
mshc as the abbreviation.
Then why author of this file uses dw-mmc instead of dw-mshc? and
it uses 'dw_mci' prefix at functions. I just worried and don't want to
give confusion to users who uses this device.
+
+* reg: physical base address of the dw-mshc controller and size of its
memory
+ region.
+
+* interrupts: interrupt specifier for the controller. The format and
value
of
+ the interrupt specifier depends on the interrupt parent for the
controller.
+
+# Slots: The slot specific information are contained within child-nodes
with
+ each child-node representing a supported slot. There should be
atleast
one
+ child node representing a card slot. The name of the slot child node
should
+ be 'slot{n}' where n is the unique number of the slot connnected to
the
+ controller. The following are optional properties which can be
included
in
+ the slot child node.
+
+ * bus-width: specifies the width of the data bus connected from
the
+ controller to the card slot. The value should be 1, 4 or 8. In
case
+ this property is not specified, a default value of 1 is assumed
for
+ this property.
+
+ * cd-gpios: specifies the card detect gpio line. The format of the
+ gpio specifier depends on the gpio controller.
+
+ * wp-gpios: specifies the write protect gpio line. The format of
the
+ gpio specifier depends on the gpio controller.
+
+ * gpios: specifies a list of gpios used for command, clock and
data
+ bus. The first gpio is the command line and the second gpio is
the
+ clock line. The rest of the gpios (depending on the bus-width
+ property) are the data lines in no particular order. The format
of
+ the gpio specifier depends on the gpio controller.
+
+Optional properties:
+
+* fifo-depth: The maximum size of the tx/rx fifo's. If this property is
not
+ specified, the default value of the fifo size is determined from the
+ controller registers.
+
+* card-detect-delay: Delay in milli-seconds before detecting card
after
card
+ insert event. The default value is 0.
+
+* supports-highspeed: Enables support for high speed cards (upto 50MHz)
+
+* card-detection-broken: The card detection functionality is not
available
on
+ any of the slots.
+
+* no-write-protect: The write protect pad of the controller is not
connected
+ to the write protect pin on the slot.
+
+Example:
+
+ The MSHC controller node can be split into two portions, SoC specific
and
+ board specific portions as listed below.
+
+ dwmmc0@1220 {
+ compatible = synopsis,dw-mshc;
+ reg = 0x1220 0x1000;
+ interrupts = 0 75 0;
+ };
+
+ dwmmc0@1220 {
+ supports-highspeed;
+ card-detection-broken;
+ no-write-protect;
+ fifo-depth = 0x80;
+ card-detect-delay = 200;
+
+ slot0 {
+ bus-width = 8;
+ cd-gpios = gpc0 2 2 3 3;
+ gpios = gpc0 0 2 0 3, gpc0 1 2 0 3
Re: [PATCHv2 0/3] Add support for DRM display subsystem
On Thu, May 10, 2012 at 10:48 PM, Arnd Bergmann a...@arndb.de wrote: On Thursday 10 May 2012, Kyungmin Park wrote: And I won't apply new feature for non-dt board file from now on. I think, we need to support DT in mach-exynos/ instead of non-DT and DT together, so please consider to move on dt supporting for Samsung mobile boards. Probably you misunderstand Arnd word. From the statements made so far, I can see no clear policy that we can apply to everyone. My take on this is that for any work I spend on multiplatform kernel, I concentrate on the DT-based board files and get them to work together first, but leave it up to the individual subarch maintainers whether they want to add other board files into the mix. It doesn't mean add new feature to non-DT board. don't add new board file. This is a completely separate discussion, the problem at hand doesn't have anything to do with building a kernel for multiple mach-* directories combined that I was referring to in the text you quote. In this case, DRM is not yet ready to support DT. Okay, you can just drop this patches. but please note that this patches are posted at Mar 13 before you decide. I think it's a good idea to make new features DT-only because this way we don't get any regressions and everyone who want to use the new feature will be able to test the DT support on his board. The 'new feature' is some misleading word. In this case DRM drivers are used from v3.2 at drivers. but not registered it at board file. Basically agree to move DT and used it finally. Before that bring up the board using DRM based graphics. This of course requires that basic DT support is available for the systems in question so we don't regress when moving away from the old board files. My impression is that we're getting close to that point on exynos thanks to Thomas' work on this. AFAICT we don't have a DT binding for screen timings yet, so you will still have to use auxdata for that or put the timings into the driver. I'm also thanks to Thomas, he did a lot of works for eyxnos. but most parts are missing at least exynos platform. e.g., Please see the origen.dts. I wonder it's booted with any graphical user interface platform, android or ubuntu. Maybe not. Anyway, as discussed in multi-platform support mail threads, we're also moving to DT in the big picture. but still want to use existing boards as is. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] mmc: dw_mmc: add device tree support
Hi,
On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
Add device tree based discovery support.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/mmc/synposis-dw-mshc.txt | 85 +
drivers/mmc/host/dw_mmc-pltfm.c| 24 +++
drivers/mmc/host/dw_mmc.c | 181
+++-
drivers/mmc/host/dw_mmc.h | 10 +
include/linux/mmc/dw_mmc.h |2 +
5 files changed, 296 insertions(+), 6 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
new file mode 100644
index 000..c1ed70e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
@@ -0,0 +1,85 @@
+* Synopsis Designware Mobile Storage Host Controller
+
+The Synopsis designware mobile storage host controller is used to
interface
+a SoC with storage medium such as eMMC or SD/MMC cards.
+
+Required Properties:
+
+* compatible: should be one of the following
+ - synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
I googled the Synopsis Designware Mobile Storage Host Controller and
Synopsis released it as this name. but still I like the 'dw-mmc'
instead of'dw-mshc'.
+
+* reg: physical base address of the dw-mshc controller and size of its
memory
+ region.
+
+* interrupts: interrupt specifier for the controller. The format and value
of
+ the interrupt specifier depends on the interrupt parent for the
controller.
+
+# Slots: The slot specific information are contained within child-nodes
with
+ each child-node representing a supported slot. There should be atleast
one
+ child node representing a card slot. The name of the slot child node
should
+ be 'slot{n}' where n is the unique number of the slot connnected to the
+ controller. The following are optional properties which can be included
in
+ the slot child node.
+
+ * bus-width: specifies the width of the data bus connected from the
+ controller to the card slot. The value should be 1, 4 or 8. In case
+ this property is not specified, a default value of 1 is assumed for
+ this property.
+
+ * cd-gpios: specifies the card detect gpio line. The format of the
+ gpio specifier depends on the gpio controller.
+
+ * wp-gpios: specifies the write protect gpio line. The format of the
+ gpio specifier depends on the gpio controller.
+
+ * gpios: specifies a list of gpios used for command, clock and data
+ bus. The first gpio is the command line and the second gpio is the
+ clock line. The rest of the gpios (depending on the bus-width
+ property) are the data lines in no particular order. The format of
+ the gpio specifier depends on the gpio controller.
+
+Optional properties:
+
+* fifo-depth: The maximum size of the tx/rx fifo's. If this property is
not
+ specified, the default value of the fifo size is determined from the
+ controller registers.
+
+* card-detect-delay: Delay in milli-seconds before detecting card after
card
+ insert event. The default value is 0.
+
+* supports-highspeed: Enables support for high speed cards (upto 50MHz)
+
+* card-detection-broken: The card detection functionality is not available
on
+ any of the slots.
+
+* no-write-protect: The write protect pad of the controller is not
connected
+ to the write protect pin on the slot.
+
+Example:
+
+ The MSHC controller node can be split into two portions, SoC specific
and
+ board specific portions as listed below.
+
+ dwmmc0@1220 {
+ compatible = synopsis,dw-mshc;
+ reg = 0x1220 0x1000;
+ interrupts = 0 75 0;
+ };
+
+ dwmmc0@1220 {
+ supports-highspeed;
+ card-detection-broken;
+ no-write-protect;
+ fifo-depth = 0x80;
+ card-detect-delay = 200;
+
+ slot0 {
+ bus-width = 8;
+ cd-gpios = gpc0 2 2 3 3;
+ gpios = gpc0 0 2 0 3, gpc0 1 2 0 3,
+ gpc1 0 2 3 3, gpc1 1 2 3 3,
+ gpc1 2 2 3 3, gpc1 3 2 3 3,
+ gpc0 3 2 3 3, gpc0 4 2 3 3,
+ gpc0 5 2 3 3, gpc0 6 2 3 3;
+ };
+ };
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
b/drivers/mmc/host/dw_mmc-pltfm.c
index 92ec3eb..2b2c9bd 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -19,8 +19,24 @@
#include linux/mmc/host.h
#include linux/mmc/mmc.h
#include linux/mmc/dw_mmc.h
+#include linux/of.h
#include dw_mmc.h
+#ifdef CONFIG_OF
+static struct dw_mci_drv_data synopsis_drv_data = {
+
Re: [PATCH 4/7] mmc: dw_mmc: add samsung exynos5250 specific extentions
Hi,
On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
The instantiation of the Synopsis Designware controller on Exynos5250
include extension for SDR and DDR specific tx/rx phase shift timing
and CIU internal divider. In addition to that, the option to skip the
command hold stage is also introduced. Add support for these Exynos5250
specfic extenstions.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/mmc/synposis-dw-mshc.txt | 33
+++-
drivers/mmc/host/dw_mmc-pltfm.c|8 +
drivers/mmc/host/dw_mmc.c | 32
++-
drivers/mmc/host/dw_mmc.h | 13
include/linux/mmc/dw_mmc.h |6 +++
5 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
index c1ed70e..465fc31 100644
--- a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
@@ -7,6 +7,8 @@ Required Properties:
* compatible: should be one of the following
- synopsis,dw-mshc: for controllers compliant with synopsis dw-mshc.
+ - synopsis,dw-mshc-exynos5250: for controllers with Samsung
+ Exynos5250 specific extentions.
* reg: physical base address of the dw-mshc controller and size of its
memory
region.
@@ -55,13 +57,40 @@ Optional properties:
* no-write-protect: The write protect pad of the controller is not
connected
to the write protect pin on the slot.
+Samsung Exynos5250 specific properties:
+
+* samsung,dw-mshc-sdr-timing: Specifies the value of CUI clock divider,
CIU
+ clock phase shift value in transmit mode and CIU clock phase shift value
in
+ receive mode for single data rate mode operation. Refer notes of the
valid
+ values below.
+
+* samsung,dw-mshc-ddr-timing: Specifies the value of CUI clock divider,
CIU
+ clock phase shift value in transmit mode and CIU clock phase shift value
in
+ receive mode for double data rate mode operation. Refer notes of the
valid
+ values below. The order of the cells should be
+
+- First Cell:CIU clock divider value.
+- Second Cell: CIU clock phase shift value for tx mode.
+- Third Cell:CIU clock phase shift value for rx mode.
+
+ Valid values for SDR and DDR CIU clock timing:
+
+- valid values for CIU clock divider, tx phase shift and rx phase
shift
+ is 0 to 7.
+
+- When CIU clock divider value is set to 3, all possible 8 phase shift
+ values can be used.
+
+- If CIU clock divider value is 0 (that is divide by 1), both tx and
rx
+ phase shift clocks should be 0.
+
Example:
The MSHC controller node can be split into two portions, SoC specific
and
board specific portions as listed below.
dwmmc0@1220 {
- compatible = synopsis,dw-mshc;
+ compatible = synopsis,dw-mshc-exynos5250;
reg = 0x1220 0x1000;
interrupts = 0 75 0;
};
@@ -72,6 +101,8 @@ Example:
no-write-protect;
fifo-depth = 0x80;
card-detect-delay = 200;
+ samsung,dw-mshc-sdr-timing = 2 3 3;
+ samsung,dw-mshc-ddr-timing = 1 2 3;
slot0 {
bus-width = 8;
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c
b/drivers/mmc/host/dw_mmc-pltfm.c
index 2b2c9bd..35056fd 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -27,9 +27,17 @@ static struct dw_mci_drv_data synopsis_drv_data = {
.ctrl_type = DW_MCI_TYPE_SYNOPSIS,
};
+static struct dw_mci_drv_data exynos5250_drv_data = {
+ .ctrl_type = DW_MCI_TYPE_EXYNOS5250,
+ .caps = MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
+ MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
These caps should be board specific. So it's not proper place. Esp.,
MMC_CAP_8_BIT_DATA.
+};
+
static const struct of_device_id dw_mci_pltfm_match[] = {
{ .compatible = synopsis,dw-mshc,
.data = (void *)synopsis_drv_data, },
+ { .compatible = synopsis,dw-mshc-exynos5250,
+ .data = (void *)exynos5250_drv_data, },
{},
};
MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index bcf66d7..9174a69 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -236,6 +236,7 @@ static void dw_mci_set_timeout(struct dw_mci *host)
static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command
*cmd)
{
struct mmc_data *data;
+ struct dw_mci_slot *slot = mmc_priv(mmc);
u32 cmdr;
cmd-error = -EINPROGRESS;
@@
Re: [PATCH 5/7] ARM: Samsung: Add support for MSHC controller clocks
Hi Thomas,
I suggest to split the patches into mmc part and samsung specific
part. As you know previous time there's mismatch between mmc and
samsung. So split the patches and send it separately to avoid merge
conflict and mismatch.
I think regardless mmc changes, it can be merged into samsung tree directly.
Thank you,
Kyungmin Park
On 5/2/12, Thomas Abraham thomas.abra...@linaro.org wrote:
Add clock instances for bus interface unit clock and card interface unit
clock of the all four MSHC controller instances.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/mach-exynos/clock-exynos5.c | 45
--
1 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 7c0f810..4e17131 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -524,35 +524,30 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_peris_ctrl,
.ctrlbit= (1 19),
}, {
- .name = hsmmc,
- .devname= exynos4-sdhci.0,
+ .name = biu,
+ .devname= dw_mmc.0,
.parent = exynos5_clk_aclk_200.clk,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1 12),
}, {
- .name = hsmmc,
- .devname= exynos4-sdhci.1,
+ .name = biu,
+ .devname= dw_mmc.1,
.parent = exynos5_clk_aclk_200.clk,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1 13),
}, {
- .name = hsmmc,
- .devname= exynos4-sdhci.2,
+ .name = biu,
+ .devname= dw_mmc.2,
.parent = exynos5_clk_aclk_200.clk,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1 14),
}, {
- .name = hsmmc,
- .devname= exynos4-sdhci.3,
+ .name = biu,
+ .devname= dw_mmc.3,
.parent = exynos5_clk_aclk_200.clk,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit= (1 15),
}, {
- .name = dwmci,
- .parent = exynos5_clk_aclk_200.clk,
- .enable = exynos5_clk_ip_fsys_ctrl,
- .ctrlbit= (1 16),
- }, {
.name = sata,
.devname= ahci,
.enable = exynos5_clk_ip_fsys_ctrl,
@@ -882,8 +877,8 @@ static struct clksrc_clk exynos5_clk_sclk_uart3 = {
static struct clksrc_clk exynos5_clk_sclk_mmc0 = {
.clk= {
- .name = sclk_mmc,
- .devname= exynos4-sdhci.0,
+ .name = ciu,
+ .devname= dw_mmc.0,
.parent = exynos5_clk_dout_mmc0.clk,
.enable = exynos5_clksrc_mask_fsys_ctrl,
.ctrlbit= (1 0),
@@ -893,8 +888,8 @@ static struct clksrc_clk exynos5_clk_sclk_mmc0 = {
static struct clksrc_clk exynos5_clk_sclk_mmc1 = {
.clk= {
- .name = sclk_mmc,
- .devname= exynos4-sdhci.1,
+ .name = ciu,
+ .devname= dw_mmc.1,
.parent = exynos5_clk_dout_mmc1.clk,
.enable = exynos5_clksrc_mask_fsys_ctrl,
.ctrlbit= (1 4),
@@ -904,8 +899,8 @@ static struct clksrc_clk exynos5_clk_sclk_mmc1 = {
static struct clksrc_clk exynos5_clk_sclk_mmc2 = {
.clk= {
- .name = sclk_mmc,
- .devname= exynos4-sdhci.2,
+ .name = ciu,
+ .devname= dw_mmc.2,
.parent = exynos5_clk_dout_mmc2.clk,
.enable = exynos5_clksrc_mask_fsys_ctrl,
.ctrlbit= (1 8),
@@ -915,8 +910,8 @@ static struct clksrc_clk exynos5_clk_sclk_mmc2 = {
static struct clksrc_clk exynos5_clk_sclk_mmc3 = {
.clk= {
- .name = sclk_mmc,
- .devname= exynos4-sdhci.3,
+ .name = ciu,
+ .devname= dw_mmc.3,
.parent = exynos5_clk_dout_mmc3.clk,
.enable = exynos5_clksrc_mask_fsys_ctrl,
.ctrlbit= (1 12),
@@ -927,14 +922,6 @@ static struct clksrc_clk exynos5_clk_sclk_mmc3 = {
static struct clksrc_clk exynos5_clksrcs[] = {
{
.clk
Re: [PATCH] drivers: genpd: let platform code to register devices into disabled domains
On 5/2/12, Rafael J. Wysocki r...@sisk.pl wrote:
On Sunday, April 29, 2012, Rafael J. Wysocki wrote:
On Friday, April 06, 2012, Marek Szyprowski wrote:
Some bootloaders disable power domains on boot and the platform startup
code registers them in the 'disabled' state. Current gen_pd code
assumed
that the devices can be registered only to the power domain which is in
'enabled' state and these devices are active at the time of the
registration. This is not correct in our case. This patch lets drivers
to be registered into 'disabled' power domains and finally solves
mysterious freezes and lack of resume/suspend calls on Samsung Exynos4
NURI and UniversalC210 platforms.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/base/power/domain.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 73ce9fb..05f5799f 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1211,11 +1211,6 @@ int __pm_genpd_add_device(struct
generic_pm_domain *genpd, struct device *dev,
genpd_acquire_lock(genpd);
- if (genpd-status == GPD_STATE_POWER_OFF) {
- ret = -EINVAL;
- goto out;
- }
-
if (genpd-prepared_count 0) {
ret = -EAGAIN;
goto out;
@@ -1239,7 +1234,7 @@ int __pm_genpd_add_device(struct generic_pm_domain
*genpd, struct device *dev,
dev_pm_get_subsys_data(dev);
dev-power.subsys_data-domain_data = gpd_data-base;
gpd_data-base.dev = dev;
- gpd_data-need_restore = false;
+ gpd_data-need_restore = true;
I think that should be:
+gpd_data-need_restore = genpd-status == GPD_STATE_POWER_OFF;
Otherwise, on the next domain power off the device's state won't be
saved.
Ping?
Hi Rafael,
Now Marek is on vacation util 6 May. He'll answer at that time.
Sorry.
Thank you,
Kyungmin Park
--
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
--
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 03/12] ARM: Exynos5: Add watchdog timer clock instance
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
Add watchdog timer clock instance for Exynos5 watchdog controller.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/mach-exynos/clock-exynos5.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index ad3bec4..662615d 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -474,6 +474,11 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_peris_ctrl,
.ctrlbit= (1 20),
}, {
+ .name = watchdog,
+ .parent = exynos5_clk_aclk_66.clk,
+ .enable = exynos5_clk_ip_peris_ctrl,
+ .ctrlbit= (1 19),
Hi,
Can you place this in order? It has same exynos5_clk_ip_peris_ctrl,
but located under (1 20).
Thank you,
Kyungmin Park
+ }, {
.name = hsmmc,
.devname= exynos4-sdhci.0,
.parent = exynos5_clk_aclk_200.clk,
--
1.6.6.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
--
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 06/12] rtc-s3c: Fix breakage introduced by S3C2443/S3C2416 support
Hi,
It's already merged with different patch,
#ifdef CONFIG_OF
static const struct of_device_id s3c_rtc_dt_match[] = {
{
.compatible = samsung,s3c2410-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2410],
}, {
.compatible = samsung,s3c2416-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2416],
}, {
.compatible = samsung,s3c2443-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2443],
}, {
.compatible = samsung,s3c6410-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C64XX],
},
{},
};
MODULE_DEVICE_TABLE(of, s3c_rtc_dt_match);
#else
#define s3c_rtc_dt_match NULL
#endif
Thank you,
Kyungmin Park
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
From: Heiko Stuebner he...@sntech.de
Commits 7006ee4f (rtc-s3c: make room for more variants in devicetree block)
and 6c0a2365 (rtc-s3c: add variants for S3C2443 and S3C2416)
introduced build-failures with enabled CONFIG_USE_OF option.
This patch fixes missing , in s3c_rtc_dt_match and wrong handling of
the of_device_id.data property.
Reported-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/rtc/rtc-s3c.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 9ccea13..c792b6d 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -449,7 +449,7 @@ static inline int s3c_rtc_get_driver_data(struct
platform_device *pdev)
if (pdev-dev.of_node) {
const struct of_device_id *match;
match = of_match_node(s3c_rtc_dt_match, pdev-dev.of_node);
- return match-data;
+ return (int)match-data;
}
#endif
return platform_get_device_id(pdev)-driver_data;
@@ -667,17 +667,17 @@ static int s3c_rtc_resume(struct platform_device
*pdev)
#ifdef CONFIG_OF
static const struct of_device_id s3c_rtc_dt_match[] = {
{
- .compatible = samsung,s3c2410-rtc
- .data = TYPE_S3C2410,
+ .compatible = samsung,s3c2410-rtc,
+ .data = (void *)TYPE_S3C2410,
}, {
- .compatible = samsung,s3c2416-rtc
- .data = TYPE_S3C2416,
+ .compatible = samsung,s3c2416-rtc,
+ .data = (void *)TYPE_S3C2416,
}, {
- .compatible = samsung,s3c2443-rtc
- .data = TYPE_S3C2443,
+ .compatible = samsung,s3c2443-rtc,
+ .data = (void *)TYPE_S3C2443,
}, {
- .compatible = samsung,s3c6410-rtc
- .data = TYPE_S3C64XX,
+ .compatible = samsung,s3c6410-rtc,
+ .data = (void *)TYPE_S3C64XX,
},
{},
};
--
1.6.6.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
--
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 07/12] ARM: Exynos5: Modify the GIC physical address for static io-mapping
Hi,
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
From: Changhwan Youn chaos.y...@samsung.com
Adapt to changes in GIC physical address in rev1 of Exynos5.
Does it different from rev0 and rev1? and does it support the rev1 only?
Thank you,
Kyungmin Park
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
---
arch/arm/mach-exynos/common.c |4 ++--
arch/arm/mach-exynos/include/mach/map.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 35ac675..457d031 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -265,12 +265,12 @@ static struct map_desc exynos5_iodesc[] __initdata = {
}, {
.virtual= (unsigned long)S5P_VA_GIC_CPU,
.pfn= __phys_to_pfn(EXYNOS5_PA_GIC_CPU),
- .length = SZ_64K,
+ .length = SZ_8K,
.type = MT_DEVICE,
}, {
.virtual= (unsigned long)S5P_VA_GIC_DIST,
.pfn= __phys_to_pfn(EXYNOS5_PA_GIC_DIST),
- .length = SZ_64K,
+ .length = SZ_4K,
.type = MT_DEVICE,
},
};
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 0e2292d..648d59b 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -78,8 +78,8 @@
#define EXYNOS4_PA_GIC_CPU 0x1048
#define EXYNOS4_PA_GIC_DIST 0x1049
-#define EXYNOS5_PA_GIC_CPU 0x1048
-#define EXYNOS5_PA_GIC_DIST 0x1049
+#define EXYNOS5_PA_GIC_CPU 0x10482000
+#define EXYNOS5_PA_GIC_DIST 0x10481000
#define EXYNOS4_PA_COREPERI 0x1050
#define EXYNOS4_PA_TWD 0x10500600
--
1.6.6.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
--
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/12] gpio/samsung: add GPC4 bank instance
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
From: Sangsu Park sangsu4u.p...@samsung.com
Add GPC4 bank instance which is included in rev1 of Exynos5.
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Sangsu Park sangsu4u.p...@samsung.com
---
arch/arm/mach-exynos/include/mach/gpio.h |9 ++---
drivers/gpio/gpio-samsung.c |8
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/gpio.h
b/arch/arm/mach-exynos/include/mach/gpio.h
index d7498af..df5612b 100644
--- a/arch/arm/mach-exynos/include/mach/gpio.h
+++ b/arch/arm/mach-exynos/include/mach/gpio.h
@@ -153,10 +153,11 @@ enum exynos4_gpio_number {
#define EXYNOS5_GPIO_B2_NR (4)
#define EXYNOS5_GPIO_B3_NR (4)
#define EXYNOS5_GPIO_C0_NR (7)
-#define EXYNOS5_GPIO_C1_NR (7)
+#define EXYNOS5_GPIO_C1_NR (4)
#define EXYNOS5_GPIO_C2_NR (7)
#define EXYNOS5_GPIO_C3_NR (7)
-#define EXYNOS5_GPIO_D0_NR (8)
+#define EXYNOS5_GPIO_C4_NR (8)
+#define EXYNOS5_GPIO_D0_NR (4)
#define EXYNOS5_GPIO_D1_NR (8)
#define EXYNOS5_GPIO_Y0_NR (6)
#define EXYNOS5_GPIO_Y1_NR (4)
@@ -199,7 +200,8 @@ enum exynos5_gpio_number {
EXYNOS5_GPIO_C1_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C0),
EXYNOS5_GPIO_C2_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C1),
EXYNOS5_GPIO_C3_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C2),
- EXYNOS5_GPIO_D0_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C3),
+ EXYNOS5_GPIO_C4_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C3),
+ EXYNOS5_GPIO_D0_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_C4),
EXYNOS5_GPIO_D1_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_D0),
EXYNOS5_GPIO_Y0_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_D1),
EXYNOS5_GPIO_Y1_START = EXYNOS_GPIO_NEXT(EXYNOS5_GPIO_Y0),
@@ -242,6 +244,7 @@ enum exynos5_gpio_number {
#define EXYNOS5_GPC1(_nr)(EXYNOS5_GPIO_C1_START + (_nr))
#define EXYNOS5_GPC2(_nr)(EXYNOS5_GPIO_C2_START + (_nr))
#define EXYNOS5_GPC3(_nr)(EXYNOS5_GPIO_C3_START + (_nr))
+#define EXYNOS5_GPC4(_nr)(EXYNOS5_GPIO_C4_START + (_nr))
#define EXYNOS5_GPD0(_nr)(EXYNOS5_GPIO_D0_START + (_nr))
#define EXYNOS5_GPD1(_nr)(EXYNOS5_GPIO_D1_START + (_nr))
#define EXYNOS5_GPY0(_nr)(EXYNOS5_GPIO_Y0_START + (_nr))
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 4627787..0153bb9 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -2452,6 +2452,12 @@ static struct samsung_gpio_chip exynos5_gpios_1[] = {
},
}, {
.chip = {
+ .base = EXYNOS5_GPC4(0),
+ .ngpio = EXYNOS5_GPIO_C4_NR,
+ .label = GPC4,
+ },
+ }, {
+ .chip = {
.base = EXYNOS5_GPD0(0),
.ngpio = EXYNOS5_GPIO_D0_NR,
.label = GPD0,
@@ -2880,6 +2886,8 @@ static __init int samsung_gpiolib_init(void)
for (i = 0; i 4; i++, chip++, gpx_base += 0x20)
chip-base = gpx_base;
+ exynos5_gpios_1[11].base = gpio_base1 + 0x2E0;
'11' seems dangerous. I think you add comments here and above to know
'11' meaning.
+
chip = exynos5_gpios_1;
nr_chips = ARRAY_SIZE(exynos5_gpios_1);
--
1.6.6.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
--
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 06/12] rtc-s3c: Fix breakage introduced by S3C2443/S3C2416 support
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
On 17 April 2012 12:00, Kyungmin Park kmp...@infradead.org wrote:
Hi,
It's already merged with different patch,
This is a repost of the patch from Heiko Stuebner which would be
required to fix compilation issue for rtc driver. I think you are
referring to that patch but it is not merged yet. So I am reposting it
with this series.
No it's 3.4.0-rc3. it's already included.
Thanks,
Thomas.
#ifdef CONFIG_OF
static const struct of_device_id s3c_rtc_dt_match[] = {
{
.compatible = samsung,s3c2410-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2410],
}, {
.compatible = samsung,s3c2416-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2416],
}, {
.compatible = samsung,s3c2443-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C2443],
}, {
.compatible = samsung,s3c6410-rtc,
.data = s3c_rtc_drv_data_array[TYPE_S3C64XX],
},
{},
};
MODULE_DEVICE_TABLE(of, s3c_rtc_dt_match);
#else
#define s3c_rtc_dt_match NULL
#endif
Thank you,
Kyungmin Park
On 4/17/12, Thomas Abraham thomas.abra...@linaro.org wrote:
From: Heiko Stuebner he...@sntech.de
Commits 7006ee4f (rtc-s3c: make room for more variants in devicetree
block)
and 6c0a2365 (rtc-s3c: add variants for S3C2443 and S3C2416)
introduced build-failures with enabled CONFIG_USE_OF option.
This patch fixes missing , in s3c_rtc_dt_match and wrong handling of
the of_device_id.data property.
Reported-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/rtc/rtc-s3c.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 9ccea13..c792b6d 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -449,7 +449,7 @@ static inline int s3c_rtc_get_driver_data(struct
platform_device *pdev)
if (pdev-dev.of_node) {
const struct of_device_id *match;
match = of_match_node(s3c_rtc_dt_match, pdev-dev.of_node);
- return match-data;
+ return (int)match-data;
}
#endif
return platform_get_device_id(pdev)-driver_data;
@@ -667,17 +667,17 @@ static int s3c_rtc_resume(struct platform_device
*pdev)
#ifdef CONFIG_OF
static const struct of_device_id s3c_rtc_dt_match[] = {
{
- .compatible = samsung,s3c2410-rtc
- .data = TYPE_S3C2410,
+ .compatible = samsung,s3c2410-rtc,
+ .data = (void *)TYPE_S3C2410,
}, {
- .compatible = samsung,s3c2416-rtc
- .data = TYPE_S3C2416,
+ .compatible = samsung,s3c2416-rtc,
+ .data = (void *)TYPE_S3C2416,
}, {
- .compatible = samsung,s3c2443-rtc
- .data = TYPE_S3C2443,
+ .compatible = samsung,s3c2443-rtc,
+ .data = (void *)TYPE_S3C2443,
}, {
- .compatible = samsung,s3c6410-rtc
- .data = TYPE_S3C64XX,
+ .compatible = samsung,s3c6410-rtc,
+ .data = (void *)TYPE_S3C64XX,
},
{},
};
--
1.6.6.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
--
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
--
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] Exynos: fix SYSMMU driver to work with power domains
On 4/16/12, KyongHo Cho pullip@samsung.com wrote: On Sun, Apr 15, 2012 at 12:51 AM, Kukjin Kim kgene@samsung.com wrote: On 04/12/12 01:19, KyongHo Cho wrote: On Wed, Apr 11, 2012 at 11:34 PM, Marek Szyprowski m.szyprow...@samsung.com wrote: Hi! These two patches fixes operation of the SYSMMU driver (v12 version [1]) with the new power domain driver based on generic power domains and runtime pw, which has been merged to Linux kernel v3.4-rc1. Thanks, Marek. Your way of power gating is right and I will look into the changed runtime PM scheme in Exynos tree. KyongHo, Do you want to upstream this series with your previous sysmmu (cleanup and moving) patches? Yes I hope so. Marek's patch corrects run-time power management in Exynos4 with System MMU. Hi, Next time, if you give Acked-By or Reviewed_by, then it's more helpful to determine to merge or not. Thank you, Kyungmin Park Thank you. KyongHo -- 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 -- 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: EXYNOS: autodetect enabled serial port in uncompress
Hi,
On Tue, Apr 3, 2012 at 4:17 AM, Kukjin Kim kgene@samsung.com wrote:
From: Colin Cross ccr...@android.com
Check the ULCON register of each serial port to determine if
it has been enabled by the bootloader. Â If only one serial port
is found enabled, use that one. Â Otherwise, use the value from
CONFIG_S3C_LOWLEVEL_UART_PORT.
Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
 arch/arm/mach-exynos/include/mach/uncompress.h |  25 ++-
 1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/uncompress.h
b/arch/arm/mach-exynos/include/mach/uncompress.h
index 2979995..0d17a43 100644
--- a/arch/arm/mach-exynos/include/mach/uncompress.h
+++ b/arch/arm/mach-exynos/include/mach/uncompress.h
@@ -25,6 +25,25 @@ static unsigned int __raw_readl(unsigned int ptr)
    return *((volatile unsigned int *)ptr);
 }
+static volatile u8 *exynos_autodetect_uart(volatile u8 *base)
+{
+ Â Â Â int i;
+ Â Â Â int found = 0;
+ Â Â Â int port;
+
+ Â Â Â for (i = 0; i CONFIG_SERIAL_SAMSUNG_UARTS; i++) {
+ Â Â Â Â Â Â Â if (__raw_readl((unsigned int)base + S3C_UART_OFFSET * i)) {
1. Even though ULCON has offset 0, it's better to add ULCON_OFFSET.
2. In our case, we disable the unused UART at bootloader except the
debug uart, then does it possible to read this value at kernel?
I think it's hang at here. So read it correctly it should enable the
required uart clock before read it.
3. As similar tegra, how about to read specific value from RX
register. e.g., 'D'?
+ Â Â Â Â Â Â Â Â Â Â Â port = i;
+ Â Â Â Â Â Â Â Â Â Â Â found++;
To match the description, it should brake at here. if not it detects
the last uart at several detected uarts.
BR,
kmpark
+ Â Â Â Â Â Â Â }
+ Â Â Â }
+
+ Â Â Â if (found != 1)
+ Â Â Â Â Â Â Â port = CONFIG_S3C_LOWLEVEL_UART_PORT;
+
+ Â Â Â return base + S3C_UART_OFFSET * port;
+}
+
 static void arch_detect_cpu(void)
 {
    u32 chip_id = __raw_readl(EXYNOS_PA_CHIPID);
@@ -38,9 +57,11 @@ static void arch_detect_cpu(void)
    chip_id = 0xf;
    if (chip_id == 0x5)
- Â Â Â Â Â Â Â uart_base = (volatile u8 *)EXYNOS5_PA_UART + (S3C_UART_OFFSET
* CONFIG_S3C_LOWLEVEL_UART_PORT);
+ Â Â Â Â Â Â Â uart_base = (volatile u8 *)EXYNOS5_PA_UART;
    else
- Â Â Â Â Â Â Â uart_base = (volatile u8 *)EXYNOS4_PA_UART + (S3C_UART_OFFSET
* CONFIG_S3C_LOWLEVEL_UART_PORT);
+ Â Â Â Â Â Â Â uart_base = (volatile u8 *)EXYNOS4_PA_UART;
+
+ Â Â Â uart_base = exynos_autodetect_uart(uart_base);
    /*
    * For preventing FIFO overrun or infinite loop of UART console,
--
1.7.2.3
--
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
--
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/3 v2] Updates for exynos4210 and DT-based systems
+CC another i2c subsystem maintainer, Wolfram Sang. On 3/14/12, Karol Lewandowski k.lewando...@samsung.com wrote: Changes since v1: - Move unrelated code fragment to separate patch (of_match_ptr()) - Move device-type handling to separate function and rework its internals a bit This patchset reworks i2c-s3c2410 driver a bit to better handle device tree-enabled platforms and adds two quirks required by exynos4210-specific I2C controller used by s5p-hdmi driver. This patchset is based on i2c-bjdooks/for-34/i2c/i2c-samsung branch taken from: git://git.fluff.org/bjdooks/linux.git Karol Lewandowski (3): i2c-s3c2410: Drop unused define i2c-s3c2410: Rework device type handling i2c-s3c2410: Add HDMIPHY quirk for S3C2440 .../devicetree/bindings/i2c/samsung-i2c.txt| 10 ++- drivers/i2c/busses/i2c-s3c2410.c | 93 +++- 2 files changed, 77 insertions(+), 26 deletions(-) -- 1.7.9 -- 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 -- 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: Exynos: Add DRM core device support for Universal C210 board
On 3/13/12, Sachin Kamat sachin.ka...@linaro.org wrote:
Hi Marek,
Thanks for the patch.
On 09/03/2012, Marek Szyprowski m.szyprow...@samsung.com wrote:
Add core DRM device and alternative platform device data for FIMD DRM
subdriver. Based on the initial patch by Joonyoung Shim
jy0922.s...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/mach-universal_c210.c | 31
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 5a26944..c73eeba 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -257,6 +257,7 @@ config MACH_UNIVERSAL_C210
select S5P_DEV_ONENAND
select S5P_DEV_TV
select EXYNOS4_DEV_DMA
+select EXYNOS_DEV_DRM
select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_I2C3
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 322b272..30a3ff3 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -23,6 +23,7 @@
#include linux/i2c-gpio.h
#include linux/i2c/mcs.h
#include linux/i2c/atmel_mxt_ts.h
+#include drm/exynos_drm.h
#include asm/mach/arch.h
#include asm/hardware/gic.h
@@ -811,6 +812,27 @@ static struct i2c_board_info i2c1_devs[] __initdata =
{
/* Gyro, To be updated */
};
+#ifdef CONFIG_DRM_EXYNOS
+static struct exynos_drm_fimd_pdata drm_fimd_pdata = {
+.timing = {
+.left_margin= 16,
+.right_margin = 16,
+.upper_margin = 2,
+.lower_margin = 28,
+.hsync_len = 2,
+.vsync_len = 1,
+.xres = 480,
+.yres = 800,
+.refresh= 55,
+},
Shouldn't this be:
Right, recently we added the panel information. It should be drm-next soon.
Thank you,
Kyungmin Park
.panel = {
.timing = {
.left_margin= 16,
.right_margin = 16,
.upper_margin = 2,
.lower_margin = 28,
.hsync_len = 2,
.vsync_len = 1,
.xres = 480,
.yres = 800,
.refresh= 55,
},
},
+.vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB |
+ VIDCON0_CLKSEL_LCD,
+.vidcon1= VIDCON1_INV_VCLK | VIDCON1_INV_VDEN
+ | VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+.default_win= 3,
+.bpp= 32,
+};
+#else
/* Frame Buffer */
static struct s3c_fb_pd_win universal_fb_win0 = {
.win_mode = {
@@ -838,6 +860,7 @@ static struct s3c_fb_platdata universal_lcd_pdata
__initdata = {
| VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
.setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
};
+#endif
static struct regulator_consumer_supply cam_vt_dio_supply =
REGULATOR_SUPPLY(vdd_core, 0-003c);
@@ -1046,6 +1069,9 @@ static struct platform_device *universal_devices[]
__initdata = {
universal_gpio_keys,
s5p_device_onenand,
s5p_device_fimd0,
+#ifdef CONFIG_DRM_EXYNOS
+exynos_device_drm,
+#endif
s5p_device_mfc,
s5p_device_mfc_l,
s5p_device_mfc_r,
@@ -1091,7 +1117,12 @@ static void __init universal_machine_init(void)
s5p_i2c_hdmiphy_set_platdata(NULL);
i2c_register_board_info(5, i2c5_devs, ARRAY_SIZE(i2c5_devs));
+#ifdef CONFIG_DRM_EXYNOS
+s5p_device_fimd0.dev.platform_data = drm_fimd_pdata;
+exynos4_fimd0_gpio_setup_24bpp();
+#else
s5p_fimd0_set_platdata(universal_lcd_pdata);
+#endif
universal_touchkey_init();
i2c_register_board_info(I2C_GPIO_BUS_12, i2c_gpio12_devs,
--
1.7.1.569.g6f426
--
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
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] mmc: sdhci-s3c: setup pins using pinctrl interface
On 3/11/12, Thomas Abraham thomas.abra...@linaro.org wrote:
The platform specific callback to setup the sdhci pin mux and pin config
is removed and the pinctrl subsystem interface is used to setup the
mux and config.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/mmc/host/sdhci-s3c.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index ea0767e..76c1c36 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -22,6 +22,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/pinctrl/consumer.h
#include linux/mmc/host.h
@@ -50,6 +51,7 @@ struct sdhci_s3c {
struct platform_device *pdev;
struct resource *ioarea;
struct s3c_sdhci_platdata *pdata;
+ struct pinctrl *pinctrl;
unsigned intcur_clk;
int ext_cd_irq;
int ext_cd_gpio;
@@ -529,6 +531,9 @@ static inline struct sdhci_s3c_drv_data
*sdhci_s3c_get_driver_data(
platform_get_device_id(pdev)-driver_data;
}
+#include plat/map-s5p.h
+#include plat/map-base.h
Why this header files are required?
+
static int __devinit sdhci_s3c_probe(struct platform_device *pdev)
{
struct s3c_sdhci_platdata *pdata;
@@ -538,6 +543,7 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
struct sdhci_s3c *sc;
struct resource *res;
int ret, irq, ptr, clks;
+ char *pstate;
if (!pdev-dev.platform_data !pdev-dev.of_node) {
dev_err(dev, no device data specified\n);
@@ -643,8 +649,13 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
}
/* Ensure we have minimal gpio selected CMD/CLK/Detect */
- if (pdata-cfg_gpio)
- pdata-cfg_gpio(pdev, pdata-max_width);
+ pstate = pdata-max_width ? sdhci-pcfg8 : sdhci-pcfg4;
You should check pdata-max_width == 8 instead of max_width itself.
BTW if platform set the amx_width as 1. How do you handle this?
Thank you,
Kyungmin Park
+ sc-pinctrl = pinctrl_get_select(pdev-dev, pstate);
+ if (IS_ERR(sc-pinctrl)) {
+ dev_err(dev, failed to setup pin configuration\n);
+ ret = -ENXIO;
+ goto err_req_regs;
+ }
host-hw_name = samsung-hsmmc;
host-ops = sdhci_s3c_ops;
--
1.6.6.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
--
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 04/11] ARM: EXYNOS: add interrupt definitions for EXYNOS5250
On Wed, Mar 7, 2012 at 10:12 PM, Kukjin Kim kgene@samsung.com wrote: On 03/06/12 10:55, Olof Johansson wrote: Hi, On Tue, Feb 21, 2012 at 2:35 AM, Kukjin Kimkgene@samsung.com  wrote: Yes, as you said, it brakes single zImage for EXYNOS4 + EXYNOS5 (mach-exynos). So I'm working on regarding resource for EXYNOS SoCs and I think, it can resolve the problem you said before v3.4 merge window. If any updates, let you know. Just a friendly reminder; the time is close to running out for staging new code for 3.4. Hi Olof, Thanks for your kindly reminder but I couldn't finish it yet because it is required to touch most of samsung stuff, and it's a big change. Frankly, I need more time... So how about sending current exynos5 stuff for now and then sorting out single kernel for exynos4 and exynos5 next time? Actually, this exynos5 arch part is _really_ needed for developing/contribution of drivers on exynos5. No, I heard too many times. we have plan to support ... but I didn't see any progress. it's general rules. you should fix it correctly and merged correctly instead of not now Thank you, Kyungmin Park Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 -- 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 v10 2/3] ARM: EXYNOS: Change System MMU platform device definitions
Hi, On 3/6/12, KyongHo Cho pullip@samsung.com wrote: Handling System MMUs with an identifier is not flexible to manage System MMU platform devices because of the following reasons: 1. A device driver which needs to handle System MMU must know the ID. 2. A System MMU may not present in some implementations of Exynos family. 3. Handling System MMU with IOMMU API does not require an ID. This patch is the result of removing ID of System MMUs. Instead, a device driver that needs to handle its System MMU must use IOMMU API while its descriptor of platform device is given. This patch also includes the following enhanclements: - A System MMU device becomes a child if its power domain device. - clkdev Signed-off-by: KyongHo Cho pullip@samsung.com --- arch/arm/mach-exynos/Kconfig| 11 +- arch/arm/mach-exynos/Makefile |2 +- arch/arm/mach-exynos/clock-exynos4.c| 79 ++-- arch/arm/mach-exynos/clock-exynos4.h|2 + arch/arm/mach-exynos/clock-exynos4210.c | 11 + arch/arm/mach-exynos/clock-exynos4212.c | 28 ++- arch/arm/mach-exynos/clock-exynos5.c| 90 + arch/arm/mach-exynos/dev-sysmmu.c | 457 -- arch/arm/mach-exynos/include/mach/irqs.h| 179 +- arch/arm/mach-exynos/include/mach/map.h | 38 ++ arch/arm/mach-exynos/include/mach/regs-clock.h |5 + arch/arm/mach-exynos/include/mach/regs-sysmmu.h | 28 -- arch/arm/mach-exynos/include/mach/sysmmu.h | 84 +++-- arch/arm/mach-exynos/mach-armlex4210.c |1 - arch/arm/mach-exynos/mach-smdkv310.c|1 - 15 files changed, 612 insertions(+), 404 deletions(-) delete mode 100644 arch/arm/mach-exynos/include/mach/regs-sysmmu.h diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index c49d450..d5a6a29 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -88,10 +88,10 @@ config EXYNOS4_SETUP_FIMD0 help Common setup code for FIMD0. -config EXYNOS4_DEV_SYSMMU +config EXYNOS_DEV_SYSMMU bool help - Common setup code for SYSTEM MMU in EXYNOS4 + Common setup code for SYSTEM MMU in EXYNOS platforms config EXYNOS4_DEV_DWMCI bool @@ -201,12 +201,12 @@ config MACH_SMDKV310 select S3C_DEV_HSMMC2 select S3C_DEV_HSMMC3 select SAMSUNG_DEV_BACKLIGHT + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_AHCI select SAMSUNG_DEV_KEYPAD select EXYNOS4_DEV_DMA select SAMSUNG_DEV_PWM select EXYNOS4_DEV_USB_OHCI - select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_KEYPAD @@ -225,7 +225,6 @@ config MACH_ARMLEX4210 select S3C_DEV_HSMMC3 select EXYNOS4_DEV_AHCI select EXYNOS4_DEV_DMA - select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_SDHCI help Machine support for Samsung ARMLEX4210 based on EXYNOS4210 @@ -251,6 +250,7 @@ config MACH_UNIVERSAL_C210 select S5P_DEV_MFC select S5P_DEV_ONENAND select S5P_DEV_TV + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_DMA select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 @@ -320,6 +320,7 @@ config MACH_ORIGEN select S5P_DEV_USB_EHCI select SAMSUNG_DEV_BACKLIGHT select SAMSUNG_DEV_PWM + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_DMA select EXYNOS4_DEV_USB_OHCI select EXYNOS4_SETUP_FIMD0 @@ -343,6 +344,7 @@ config MACH_SMDK4212 select SAMSUNG_DEV_BACKLIGHT select SAMSUNG_DEV_KEYPAD select SAMSUNG_DEV_PWM + select EXYNOS_DEV_SYSMMU select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_I2C3 select EXYNOS4_SETUP_I2C7 @@ -368,6 +370,7 @@ comment EXYNOS5250 Boards config MACH_SMDK5250 bool SMDK5250 select SOC_EXYNOS5250 + select EXYNOS_DEV_SYSMMU help Machine support for Samsung SMDK5250 endif diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index 6fd8dd9..8b655e9 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -52,7 +52,7 @@ obj-$(CONFIG_MACH_SMDK5250) += mach-smdk5250.o obj-y+= dev-uart.o obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o -obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o +obj-$(CONFIG_EXYNOS_DEV_SYSMMU) += dev-sysmmu.o obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o obj-$(CONFIG_EXYNOS4_DEV_DMA)+= dma.o obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI) += dev-ohci.o diff --git a/arch/arm/mach-exynos/clock-exynos4.c b/arch/arm/mach-exynos/clock-exynos4.c index d72a1fe..18c48f0 100644 --- a/arch/arm/mach-exynos/clock-exynos4.c +++
Re: [PATCH 2/3] ARM: Exynos: fix SDHCI device names in regulator definitions
On 3/6/12, Kukjin Kim kgene@samsung.com wrote:
On 03/01/12 00:40, Marek Szyprowski wrote:
Patch 189eb7407 ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci
controllers changed the names of the SDHCI devices, but the author forgot
to update the definitions for the regulator subsystem. This patch fixes
this issue.
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c |4 ++--
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 8c0479f..dd26581 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -117,7 +117,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply emmc_supplies[] = {
-REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
REGULATOR_SUPPLY(vmmc, dw_mmc),
};
@@ -417,7 +417,7 @@ static struct regulator_consumer_supply __initdata
max8997_ldo12_[] = {
REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
};
static struct regulator_consumer_supply __initdata max8997_ldo13_[] = {
-REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
+REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
};
static struct regulator_consumer_supply __initdata max8997_ldo14_[] = {
REGULATOR_SUPPLY(inmotor, max8997-haptic),
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 908624c..7cd738c 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -750,7 +750,7 @@ static struct s3c_sdhci_platdata universal_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply mmc0_supplies[] = {
-REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
};
static struct regulator_init_data mmc0_fixed_voltage_init_data = {
(Cc'ed Jaehoon Chung)
Oops, I looked at same patch from Jaehoon Chung just now and it could
be. However, including same Signed-off-by from Kyungmin Park, it seems
wrong. What's happened in your side?
As your delayed work, we did the same thing from both side.
Most of all, exynos4-sdhci patchset should contains these change also.
as wrong merge, it breaks all sdhci support at least exynos4 series.
Thank you,
Kyungmin Park
--
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: Exynos: fix SDHCI device names in regulator definitions
On 3/6/12, Kukjin Kim kgene@samsung.com wrote:
On 03/06/12 02:13, Kyungmin Park wrote:
On 3/6/12, Kukjin Kimkgene@samsung.com wrote:
On 03/01/12 00:40, Marek Szyprowski wrote:
Patch 189eb7407 ARM: EXYNOS: use 'exynos4-sdhci' as device name for
sdhci
controllers changed the names of the SDHCI devices, but the author
forgot
to update the definitions for the regulator subsystem. This patch fixes
this issue.
Signed-off-by: Marek Szyprowskim.szyprow...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
arch/arm/mach-exynos/mach-nuri.c |4 ++--
arch/arm/mach-exynos/mach-universal_c210.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c
b/arch/arm/mach-exynos/mach-nuri.c
index 8c0479f..dd26581 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -117,7 +117,7 @@ static struct s3c_sdhci_platdata nuri_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply emmc_supplies[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
REGULATOR_SUPPLY(vmmc, dw_mmc),
};
@@ -417,7 +417,7 @@ static struct regulator_consumer_supply __initdata
max8997_ldo12_[] = {
REGULATOR_SUPPLY(vddio, 6-003c), /* HDC802 */
};
static struct regulator_consumer_supply __initdata max8997_ldo13_[] =
{
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.2), /* TFLASH */
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.2), /* TFLASH */
};
static struct regulator_consumer_supply __initdata max8997_ldo14_[] =
{
REGULATOR_SUPPLY(inmotor, max8997-haptic),
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
b/arch/arm/mach-exynos/mach-universal_c210.c
index 908624c..7cd738c 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -750,7 +750,7 @@ static struct s3c_sdhci_platdata
universal_hsmmc0_data
__initdata = {
};
static struct regulator_consumer_supply mmc0_supplies[] = {
- REGULATOR_SUPPLY(vmmc, s3c-sdhci.0),
+ REGULATOR_SUPPLY(vmmc, exynos4-sdhci.0),
};
static struct regulator_init_data mmc0_fixed_voltage_init_data = {
(Cc'ed Jaehoon Chung)
Oops, I looked at same patch from Jaehoon Chung just now and it could
be. However, including same Signed-off-by from Kyungmin Park, it seems
wrong. What's happened in your side?
As your delayed work, we did the same thing from both side.
NO! As I remember, there was same case from your side before. My concern
is still how your sign can be added in duplication same patches but
other author?
Most of all, exynos4-sdhci patchset should contains these change also.
as wrong merge, it breaks all sdhci support at least exynos4 series.
Wrong merge? what's that?
That's problem. you don't know what you did. Did you test the
exynos4-sdhci patchset from Thomas?
and think why this patch is required.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
--
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 v10 3/3] iommu/exynos: Add iommu driver for Exynos Platforms
Hi,
some not critical comments.
Thank you,
Kyungmin Park
On Tue, Mar 6, 2012 at 5:31 PM, KyongHo Cho pullip@samsung.com wrote:
HAALgBjAGgAbwBAAHMAYQBtAHMAdQBuAGcALgBjAG8AbQA=;Tue,
 06 Mar 2012 08:31:29
GMT;WwBQAEEAVABDAEgAIAB2ADEAMAAgADMALwAzAF0AIABpAG8AbQBtAHUALwBlAHgAeQBuAG8AcwA6ACAAQQBkAGQAIABpAG8AbQBtAHUAIABkAHIAaQB2AGUAcgAgAGYAbwByACAARQB4AHkAbgBvAHMAIABQAGwAYQB0AGYAbwByAG0AcwA=
x-cr-puzzleid: {CF0AAF04-8639-4D69-B4E1-BF71EA1B0A70}
What's this?
This is the System MMU driver and IOMMU API implementation for
Exynos SOC platforms. Exynos platforms has more than 10 System
MMUs dedicated for each multimedia accellerators.
The System MMU driver is already in arc/arm/plat-s5p but it is
moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers
there
Any device driver in Exynos platforms that needs to control its
System MMU must call platform_set_sysmmu() to inform System MMU
driver who will control it.
platform_set_sysmmu() is defined in mach/sysmmu.h
Does it really required? if we can remove it. it can be compiled
without arch dependency.
Cc: Joerg Roedel joerg.roe...@amd.com
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: KyongHo Cho pullip@samsung.com
---
 drivers/iommu/Kconfig     |  21 +
 drivers/iommu/Makefile    |   1 +
 drivers/iommu/exynos-iommu.c | 1088
++
 3 files changed, 1110 insertions(+), 0 deletions(-)
 create mode 100644 drivers/iommu/exynos-iommu.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 6bea696..25d3eed 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -142,4 +142,25 @@ config OMAP_IOMMU_DEBUG
     Say N unless you know you need this.
+config EXYNOS_IOMMU
+ Â Â Â bool Exynos IOMMU Support
+ Â Â Â depends on EXYNOS_DEV_SYSMMU
+ Â Â Â select IOMMU_API
+ Â Â Â help
+ Â Â Â Â Support for the IOMMU(System MMU) of Samsung Exynos application
+ Â Â Â Â processor family. This enables H/W multimedia accellerators to see
+ Â Â Â Â non-linear physical memory chunks as a linear memory in their
+ Â Â Â Â address spaces
+
+ Â Â Â Â If unsure, say N here.
+
+config EXYNOS_IOMMU_DEBUG
+ Â Â Â bool Debugging log for Exynos IOMMU
+ Â Â Â depends on EXYNOS_IOMMU
+ Â Â Â help
+ Â Â Â Â Select this to see the detailed log message that shows what
+ Â Â Â Â happens in the IOMMU driver
+
+ Â Â Â Â Say N unless you need kernel log message for IOMMU debugging
+
 endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 0e36b49..5a8fd97 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_IRQ_REMAP) += intr_remapping.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
 obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
 obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
new file mode 100644
index 000..4c1c48a
--- /dev/null
+++ b/drivers/iommu/exynos-iommu.c
@@ -0,0 +1,1088 @@
+/* linux/drivers/iommu/exynos_iommu.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * Â Â Â Â Â Â http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifdef CONFIG_EXYNOS_IOMMU_DEBUG
+#define DEBUG
+#endif
If it's used only at here. you can add it at Makefile.
ifeq ($(CONFIG_EXYNOS_IOMMU_DEBUG),y)
CFLAGS-exynos-iommu+= -DDEBUG
endif
Of course you can select as your preference.
+
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/mm.h
+#include linux/iommu.h
+#include linux/errno.h
+#include linux/list.h
+#include linux/memblock.h
+#include linux/export.h
+
+#include asm/cacheflush.h
+#include asm/pgtable.h
+
+#include mach/sysmmu.h
+
+#define S5P_MMU_CTRL Â Â Â Â Â Â Â Â Â 0x000
+#define S5P_MMU_CFG Â Â Â Â Â Â Â Â Â Â 0x004
+#define S5P_MMU_STATUS Â Â Â Â Â Â Â Â 0x008
+#define S5P_MMU_FLUSH Â Â Â Â Â Â Â Â Â 0x00C
+#define S5P_PT_BASE_ADDR Â Â Â Â Â Â Â 0x014
+#define S5P_INT_STATUS Â Â Â Â Â Â Â Â 0x018
+#define S5P_INT_CLEAR Â Â Â Â Â Â Â Â Â 0x01C
+#define S5P_PAGE_FAULT_ADDR Â Â Â Â Â Â 0x024
+#define S5P_AW_FAULT_ADDR Â Â Â Â Â Â Â 0x028
+#define S5P_AR_FAULT_ADDR Â Â Â Â Â Â Â 0x02C
+#define S5P_DEFAULT_SLAVE_ADDR Â Â Â Â 0x030
+#define S5P_MMU_VERSION Â Â Â Â Â Â Â Â Â Â Â Â 0x034
+#define S5P_PB0_SADDR Â Â Â Â Â Â Â Â Â 0x04C
+#define S5P_PB0_EADDR Â Â Â Â Â Â Â Â Â 0x050
+#define S5P_PB1_SADDR Â Â Â Â Â Â Â Â Â 0x054
+#define S5P_PB1_EADDR Â Â Â Â Â Â Â Â Â 0x058
+
+#define SECT_ORDER 20
+#define LPAGE_ORDER 16
+#define SPAGE_ORDER 12
+
+#define SECT_SIZE (1 SECT_ORDER)
+#define
Re: [PATCH v9 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
Hi, Some comments. 1. It's not same patch series. since it has additional feature, exynos5 series support which don't covered at previous time. 2. It assumes that name conversion is based on exynos5 as default. now you use gsc at exynos4 even though there's no gsc block. It should be fimc. So I suggest to send exynos4 series patch as before and send additional exynos5 patch series next. Thank you, Kyungmin Park On 2/28/12, KyongHo Cho pullip@samsung.com wrote: Changes since v8: - exynos_iommu_map/unmap() just works for the page sizes that System MMU supports. (Joerg's comment) - 1 platform device for 1 H/W though a multimedia accelerator with several System MMUs attached. This make controlling System MMU simpler. - Information between System MMU and the accelerators: Shifted to accelerator's device structure from System MMU's Changes since v7: - Rebased with the recent commits of the following git branches * git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/next * git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/for-next - Changed magic numbers into macros - Setting owner of a System MMU in 'iommu' field of dev_archdata - Verbose message in the default fault handler - Some bug fixes. Changes since v6: - Totally rewrite exynos_iommu_map() and exynos_iommu_unmap() according to the change in iommu_map() and iommu_unmap(). - Change special slab for Lv2 page table to kmalloc(). Changes since v5: - Relation between device and a domain become n:1 (Joerg's comment) - Implements iommu_commit(). -- Removed Changes since v4: - exynos_iommu_unmap()returns unmapped size in page order (Ohad Ben-Cohen's comment) - Fixed typo error of resource names - Fixed missing #includemach/sysmmu.h in arch/arm/mach-exynos4/mach-armlex4210.c Changes since v3: - Used DEFINE_RES_MEM and DEFINE_RES_IRQ macros to define resources of System MMU (Russell King's comment) - Fixed removal of CONFIG_S5P_SLEEP definition (Sylwester Nawrocki's comment) Changes since v2: - Add lock for System MMU private data. And fixes the following problems pointed by Joerg Rodel: - Fix wrong argument to kmalloc() and get_free_pages() - Merged patches into 2 due to bisectability Changes since v1: Fixes of the following problems pointed by Russell King.: - Missing unlocking a spinlock in exynos_iommu_attach_dev(). - atomic_t - int in sysmmu_drvdata.activations - sysmmu_platdata - sysmmu_drvdata - Change in error messages in irq handler - Removed casting in format of error message - omap_iommu_ops - exynos_iommu_ops in the last patch Patch Summary: [PATCH v8 1/2] ARM: EXYNOS: Change System MMU platform device definitions [PATCH v8 2/2] iommu/exynos: Add iommu driver for Exynos Platforms The first patche enhances System MMU platform device definition: - Removed System MMU for MDMA0 in TOP block because it is not used. Use MDMA2 in LCD block. - Removed System MMU ID. Instead, a System MMU is bound to a device that the System MMU is dedicated during machin initialization. If a device driver wants to handle System MMU, it must bind its device with System MMU with sysmmu_set_owner(). - clkdev The last patch implements IOMMU API: - System MMU device driver is removed from arch/arm/plat-s5p to move it to driver/iommu directory. - Implements IOMMU API and System MMU driver that is moved from arch/arm/plat-s5p. Diffstats: arch/arm/mach-exynos/Kconfig| 11 +- arch/arm/mach-exynos/Makefile |2 +- arch/arm/mach-exynos/clock-exynos4.c| 74 +- arch/arm/mach-exynos/clock-exynos4.h|2 + arch/arm/mach-exynos/clock-exynos4210.c | 11 + arch/arm/mach-exynos/clock-exynos4212.c | 28 +- arch/arm/mach-exynos/clock-exynos5.c| 85 ++ arch/arm/mach-exynos/dev-sysmmu.c | 454 ++- arch/arm/mach-exynos/include/mach/irqs.h| 179 ++-- arch/arm/mach-exynos/include/mach/map.h | 38 + arch/arm/mach-exynos/include/mach/memory.h |1 + arch/arm/mach-exynos/include/mach/regs-clock.h |5 + arch/arm/mach-exynos/include/mach/regs-sysmmu.h | 28 - arch/arm/mach-exynos/include/mach/sysmmu.h | 83 +- arch/arm/mach-exynos/mach-armlex4210.c |1 - arch/arm/mach-exynos/mach-smdkv310.c|1 - arch/arm/plat-s5p/Kconfig |8 - arch/arm/plat-s5p/Makefile |1 - arch/arm/plat-s5p/sysmmu.c | 313 --- arch/arm/plat-samsung/include/plat/devs.h |1 - arch/arm/plat-samsung/include/plat/sysmmu.h | 95 -- drivers/iommu/Kconfig | 22 + drivers/iommu/Makefile |1 + drivers/iommu/exynos-iommu.c| 1076 +++ 24 files changed, 1698 insertions(+), 822 deletions
Re: [PATCH v9 1/2] ARM: EXYNOS: Change System MMU platform device definitions
Hi, On 2/28/12, KyongHo Cho pullip@samsung.com wrote: Handling System MMUs with an identifier is not flexible to manage System MMU platform devices because of the following reasons: 1. A device driver which needs to handle System MMU must know the ID. 2. A System MMU may not present in some implementations of Exynos family. 3. Handling System MMU with IOMMU API does not require an ID. This patch is the result of removing ID of System MMUs. Instead, a device driver that needs to handle its System MMU must use IOMMU API while its descriptor of platform device is given. This patch also includes the following enhancements: - A System MMU device becomes a child if its power domain device. - clkdev Signed-off-by: KyongHo Cho pullip@samsung.com --- arch/arm/mach-exynos/Kconfig| 11 +- arch/arm/mach-exynos/Makefile |2 +- arch/arm/mach-exynos/clock-exynos4.c| 79 ++-- arch/arm/mach-exynos/clock-exynos4.h|2 + arch/arm/mach-exynos/clock-exynos4210.c | 11 + arch/arm/mach-exynos/clock-exynos4212.c | 28 ++- arch/arm/mach-exynos/clock-exynos5.c| 90 + arch/arm/mach-exynos/dev-sysmmu.c | 451 --- arch/arm/mach-exynos/include/mach/irqs.h| 179 +- arch/arm/mach-exynos/include/mach/map.h | 38 ++ arch/arm/mach-exynos/include/mach/regs-clock.h |5 + arch/arm/mach-exynos/include/mach/regs-sysmmu.h | 28 -- arch/arm/mach-exynos/include/mach/sysmmu.h | 84 +++-- arch/arm/mach-exynos/mach-armlex4210.c |1 - arch/arm/mach-exynos/mach-smdkv310.c|1 - arch/arm/plat-s5p/sysmmu.c | 13 +- arch/arm/plat-samsung/include/plat/devs.h |1 - 17 files changed, 618 insertions(+), 406 deletions(-) It's too big to cover these changes. Can you make it more small changes. 1. Remove existing ones since no user at this time. 2. Add new define and data structures. 3. Support new system mmu features based on generic iommu. delete mode 100644 arch/arm/mach-exynos/include/mach/regs-sysmmu.h diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 40ad6b4..f7eabaf 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -95,10 +95,10 @@ config EXYNOS4_DEV_PD help Compile in platform device definitions for Power Domain -config EXYNOS4_DEV_SYSMMU +config EXYNOS_DEV_SYSMMU It's simple example. The renaming is one candidate patch. bool help - Common setup code for SYSTEM MMU in EXYNOS4 + Common setup code for SYSTEM MMU in EXYNOS platforms config EXYNOS4_DEV_DWMCI bool @@ -212,9 +212,9 @@ config MACH_SMDKV310 select SAMSUNG_DEV_KEYPAD select SAMSUNG_DEV_PWM select EXYNOS_DEV_DMA + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_PD select EXYNOS4_DEV_USB_OHCI - select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_KEYPAD @@ -233,7 +233,6 @@ config MACH_ARMLEX4210 select S3C_DEV_HSMMC3 select EXYNOS_DEV_DMA select EXYNOS4_DEV_AHCI - select EXYNOS4_DEV_SYSMMU select EXYNOS4_SETUP_SDHCI help Machine support for Samsung ARMLEX4210 based on EXYNOS4210 @@ -259,6 +258,7 @@ config MACH_UNIVERSAL_C210 select S5P_DEV_ONENAND select S5P_DEV_TV select EXYNOS_DEV_DMA + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_PD select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 @@ -326,6 +326,7 @@ config MACH_ORIGEN select SAMSUNG_DEV_BACKLIGHT select SAMSUNG_DEV_PWM select EXYNOS_DEV_DMA + select EXYNOS_DEV_SYSMMU select EXYNOS4_DEV_PD select EXYNOS4_DEV_USB_OHCI select EXYNOS4_SETUP_FIMD0 @@ -350,6 +351,7 @@ config MACH_SMDK4212 select SAMSUNG_DEV_KEYPAD select SAMSUNG_DEV_PWM select EXYNOS_DEV_DMA + select EXYNOS_DEV_SYSMMU select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_I2C3 select EXYNOS4_SETUP_I2C7 @@ -376,6 +378,7 @@ config MACH_SMDK5250 bool SMDK5250 select SOC_EXYNOS5250 select EXYNOS_DEV_DMA + select EXYNOS_DEV_SYSMMU help Machine support for Samsung SMDK5250 endif diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index 08b4eb1..aac02a8 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -52,7 +52,7 @@ obj-y += dev-uart.o obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o -obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o +obj-$(CONFIG_EXYNOS_DEV_SYSMMU) += dev-sysmmu.o
Re: Subject: [PATCH] MAINTAINERS: add maintainer entry for SAMSUNG EXYNOS DeviceTree
Hi, I agree adding Thomas as DT maintainer. but I didn't see any activity with Mr. Kim at least DT area. Partially Ack. On 2/22/12, Kukjin Kim kgene@samsung.com wrote: Add Samsung EXYNOS DT maintainer Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Kukjin Kim kgene@samsung.com --- MAINTAINERS | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9a648eb..5ac5aaf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1065,6 +1065,16 @@ S: Maintained F: arch/arm/mach-s5p*/ F: arch/arm/mach-exynos*/ +ARM/SAMSUNG EXYNOS DEVICE TREE +M: Thomas Abraham thomas.abra...@linaro.org +M: Kukjin Kim kgene@samsung.com +L: devicetree-disc...@lists.ozlabs.org (moderated for non-subscribers) +L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) +S: Maintained +F: arch/arm/boot/dts/exynos* +F: arch/arm/mach-exynos/*dt.c +F: Documentation/devicetree/*/*/*samsung* + ARM/SAMSUNG MOBILE MACHINE SUPPORT M: Kyungmin Park kyungmin.p...@samsung.com L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 1.7.1 -- 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 -- 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 08/11] ARM: EXYNOS: add support for ARCH_EXYNOS5 and EXYNOS5250
#define EXYNOS4_PA_COREPERI 0x1050
#define EXYNOS4_PA_TWD 0x10500600
@@ -91,7 +104,6 @@
#define EXYNOS4_PA_SPI1 0x1393
#define EXYNOS4_PA_SPI2 0x1394
-
#define EXYNOS4_PA_GPIO1 0x1140
#define EXYNOS4_PA_GPIO2 0x1100
#define EXYNOS4_PA_GPIO3 0x0386
@@ -109,6 +121,7 @@
#define EXYNOS4_PA_SATAPHY_CTRL 0x126B
#define EXYNOS4_PA_SROMC 0x1257
+#define EXYNOS5_PA_SROMC 0x1225
#define EXYNOS4_PA_EHCI 0x1258
#define EXYNOS4_PA_OHCI 0x1259
@@ -116,6 +129,7 @@
#define EXYNOS4_PA_MFC 0x1340
#define EXYNOS4_PA_UART 0x1380
+#define EXYNOS5_PA_UART 0x12C0
#define EXYNOS4_PA_VP0x12C0
#define EXYNOS4_PA_MIXER 0x12C1
@@ -124,6 +138,7 @@
#define EXYNOS4_PA_IIC_HDMIPHY 0x138E
#define EXYNOS4_PA_IIC(x)(0x1386 + ((x) * 0x1))
+#define EXYNOS5_PA_IIC(x)(0x12C6 + ((x) * 0x1))
#define EXYNOS4_PA_ADC 0x1391
#define EXYNOS4_PA_ADC1 0x13911000
@@ -133,8 +148,10 @@
#define EXYNOS4_PA_SPDIF 0x139B
#define EXYNOS4_PA_TIMER 0x139D
+#define EXYNOS5_PA_TIMER 0x12DD
#define EXYNOS4_PA_SDRAM 0x4000
+#define EXYNOS5_PA_SDRAM 0x4000
/* Compatibiltiy Defines */
diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h
b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 4fff8e9..4c53f38 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -31,6 +31,7 @@
#define S5P_USE_STANDBYWFE_ISP_ARM (1 26)
#define S5P_SWRESET S5P_PMUREG(0x0400)
+#define EXYNOS_SWRESET S5P_PMUREG(0x0400)
Please use just one.
Thank you,
Kyungmin Park
#define S5P_WAKEUP_STAT S5P_PMUREG(0x0600)
#define S5P_EINT_WAKEUP_MASK S5P_PMUREG(0x0604)
diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
index 10e235cc7..88795ea 100644
--- a/arch/arm/plat-s5p/Kconfig
+++ b/arch/arm/plat-s5p/Kconfig
@@ -9,8 +9,8 @@ config PLAT_S5P
bool
depends on (ARCH_S5P64X0 || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
default y
- select ARM_VIC if !ARCH_EXYNOS4
- select ARM_GIC if ARCH_EXYNOS4
+ select ARM_VIC if !ARCH_EXYNOS
+ select ARM_GIC if ARCH_EXYNOS
select GIC_NON_BANKED if ARCH_EXYNOS4
select NO_IOPORT
select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 73cb3cf..787ceac 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -42,6 +42,9 @@ extern unsigned long samsung_cpu_id;
#define EXYNOS4412_CPU_ID0xE4412200
#define EXYNOS4_CPU_MASK 0xFFFE
+#define EXYNOS5250_SOC_ID0x4352
+#define EXYNOS5_SOC_MASK 0xF000
+
#define IS_SAMSUNG_CPU(name, id, mask) \
static inline int is_samsung_##name(void)\
{\
@@ -58,6 +61,7 @@ IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
+IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2412) || \
defined(CONFIG_CPU_S3C2416) || defined(CONFIG_CPU_S3C2440) || \
@@ -120,6 +124,12 @@ IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID,
EXYNOS4_CPU_MASK)
#define EXYNOS4210_REV_1_0 (0x10)
#define EXYNOS4210_REV_1_1 (0x11)
+#if defined(CONFIG_SOC_EXYNOS5250)
+# define soc_is_exynos5250() is_samsung_exynos5250()
+#else
+# define soc_is_exynos5250() 0
+#endif
+
#define IODESC_ENT(x) { (unsigned long)S3C24XX_VA_##x,
__phys_to_pfn(S3C24XX_PA_##x), S3C24XX_SZ_##x, MT_DEVICE }
#ifndef MHZ
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: EXYNOS: Adds Samsung TRATS board support
+ Karol for DT support later On Fri, Feb 10, 2012 at 3:58 AM, Thomas Abraham thomas.abra...@linaro.org wrote: Dear Mr. HeungJun Kim, On 27 January 2012 00:21, HeungJun, Kim riverful@samsung.com wrote: This patch adds Samsung Mobile TRATS board support. Signed-off-by: HeungJun, Kim riverful@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com ---  arch/arm/mach-exynos/Kconfig    |  11 ++  arch/arm/mach-exynos/Makefile   |   1 +  arch/arm/mach-exynos/mach-trats.c |  344 +  3 files changed, 356 insertions(+), 0 deletions(-)  create mode 100644 arch/arm/mach-exynos/mach-trats.c The exynos4 dt-enabled board file can support most of the features added in this board file. The other option that could be considered here would be to add DT support for this board file, and use AUX_DATA to supply platform data for drivers that do not have dt support yet. It would be better to use dt support for new board support that we add. Thanks, Thomas. (snip) -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: SAMSUNG: Add support for EXYNOS SS USB 3.0 DRD controller
On Mon, Feb 6, 2012 at 5:11 PM, Anton Tikhomirov av.tikhomi...@samsung.com wrote: Cc: Kukjin Kim kgene.kim at samsung.com Cc: Greg Kroah-Hartman gregkh at suse.de Cc: Felipe Balbi balbi at ti.com Adds DRD global register definitions and related platform data. Signed-off-by: Anton Tikhomirov av.tikhomi...@samsung.com Hi, ---  .../include/plat/regs-usb3-exynos-drd.h       |  305 If special reason, please move to the proper drivers/usb. Thank you, Kyungmin Park  arch/arm/plat-samsung/include/plat/udc-ss.h     |  21 ++  arch/arm/plat-samsung/include/plat/usb-phy.h    |   1 +  3 files changed, 327 insertions(+), 0 deletions(-)  create mode 100644 arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h  create mode 100644 arch/arm/plat-samsung/include/plat/udc-ss.h diff --git a/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h b/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h new file mode 100644 index 000..7006dc4 --- /dev/null +++ b/arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h @@ -0,0 +1,305 @@ +/* arch/arm/plat-samsung/include/plat/regs-usb3-exynos-drd.h + * + * Copyright (c) 2011 Samsung Electronics Co. Ltd + * Author: Anton Tikhomirov av.tikhomi...@samsung.com + * + * Exynos SuperSpeed USB 3.0 DRD Controller Global registers + * + * 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. + */ + +#ifndef __SAMSUNG_PLAT_REGS_USB3_EXYNOS_DRD_H +#define __SAMSUNG_PLAT_REGS_USB3_EXYNOS_DRD_H __FILE__ + +#define EXYNOS_USB3_REG(x) (x) + +#define EXYNOS_USB3_GSBUSCFG0      EXYNOS_USB3_REG(0xC100) +#define EXYNOS_USB3_GSBUSCFG0_SBusStoreAndForward    (1 12) +#define EXYNOS_USB3_GSBUSCFG0_DatBigEnd             (1 11) +#define EXYNOS_USB3_GSBUSCFG0_INCR256BrstEna      (1 7) +#define EXYNOS_USB3_GSBUSCFG0_INCR128BrstEna      (1 6) +#define EXYNOS_USB3_GSBUSCFG0_INCR64BrstEna       (1 5) +#define EXYNOS_USB3_GSBUSCFG0_INCR32BrstEna       (1 4) +#define EXYNOS_USB3_GSBUSCFG0_INCR16BrstEna       (1 3) +#define EXYNOS_USB3_GSBUSCFG0_INCR8BrstEna       (1 2) +#define EXYNOS_USB3_GSBUSCFG0_INCR4BrstEna       (1 1) +#define EXYNOS_USB3_GSBUSCFG0_INCRBrstEna        (1 0) + +#define EXYNOS_USB3_GSBUSCFG1      EXYNOS_USB3_REG(0xC104) +#define EXYNOS_USB3_GSBUSCFG1_EN1KPAGE         (1 12) +#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT_MASK      (0xf 8) +#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT_SHIFT      8 +#define EXYNOS_USB3_GSBUSCFG1_BREQLIMIT(_x)       ((_x) 8) + + +#define EXYNOS_USB3_GTXTHRCFG      EXYNOS_USB3_REG(0xC108) +#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCntSel      (1 29) +#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt_MASK     (0xf 24) +#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt_SHIFT         24 +#define EXYNOS_USB3_GTXTHRCFG_USBTxPktCnt(_x)      ((_x) 24) +#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize_MASK  (0xff 16) +#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize_SHIFT  16 +#define EXYNOS_USB3_GTXTHRCFG_USBMaxTxBurstSize(_x)   ((_x) 16) + + +#define EXYNOS_USB3_GRXTHRCFG      EXYNOS_USB3_REG(0xC10C) +#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCntSel      (1 29) +#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt_MASK     (0xf 24) +#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt_SHIFT         24 +#define EXYNOS_USB3_GRXTHRCFG_USBRxPktCnt(_x)      ((_x) 24) +#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize_MASK  (0x1f 19) +#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize_SHIFT  19 +#define EXYNOS_USB3_GRXTHRCFG_USBMaxRxBurstSize(_x)   ((_x) 19) + + +#define EXYNOS_USB3_GCTL        EXYNOS_USB3_REG(0xC110) +#define EXYNOS_USB3_GCTL_PwrDnScale_MASK        (0x1fff 19) +#define EXYNOS_USB3_GCTL_PwrDnScale_SHIFT        19 +#define EXYNOS_USB3_GCTL_PwrDnScale(_x)             ((_x) 19) +#define EXYNOS_USB3_GCTL_U2RSTECN            (1 16) +#define EXYNOS_USB3_GCTL_FRMSCLDWN_MASK             (0x3 14) +#define EXYNOS_USB3_GCTL_FRMSCLDWN_SHIFT        14 +#define EXYNOS_USB3_GCTL_FRMSCLDWN(_x)         ((_x) 14) +#define EXYNOS_USB3_GCTL_PrtCapDir_MASK             (0x3 12) +#define EXYNOS_USB3_GCTL_PrtCapDir_SHIFT        12 +#define EXYNOS_USB3_GCTL_PrtCapDir(_x)         ((_x) 12) +#define EXYNOS_USB3_GCTL_CoreSoftReset         (1 11) +#define EXYNOS_USB3_GCTL_LocalLpBkEn          (1 10) +#define EXYNOS_USB3_GCTL_LpbkEn                 (1 9) +#define EXYNOS_USB3_GCTL_DebugAttach          (1 8) +#define EXYNOS_USB3_GCTL_RAMClkSel_MASK             (0x3 6) +#define EXYNOS_USB3_GCTL_RAMClkSel_SHIFT        6 +#define EXYNOS_USB3_GCTL_RAMClkSel(_x
Re: [PATCH 1/2] ARM: EXYNOS: Add files about definition of C2C
On Sat, Feb 4, 2012 at 5:13 PM, Kisang Lee kisang80@samsung.com wrote:
Cc: Arnd Bergmann arnd at arndb.de
Cc: Greg Kroah-Hartman greg at kroah.com
Following files are added for C2C driver
c2c.h : Definition of C2C platform data and mode
regs-c2c.h : Definition of C2C registers
Signed-off-by: Kisang Lee kisang80@samsung.com
---
Hi,
 arch/arm/mach-exynos/include/mach/c2c.h    |  65 +++
One nit. some parts are c2c common and gpio and platform setup codes
are exynos specific.
 arch/arm/mach-exynos/include/mach/regs-c2c.h |  71
++
Are there any reason to put here? I think you can merge with 2/2
patch. I mean you can move it under drivers/misc/c2c.
Thank you,
Kyungmin Park
 2 files changed, 136 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-exynos/include/mach/c2c.h
 create mode 100644 arch/arm/mach-exynos/include/mach/regs-c2c.h
diff --git a/arch/arm/mach-exynos/include/mach/c2c.h
b/arch/arm/mach-exynos/include/mach/c2c.h
new file mode 100644
index 000..c3d6131
--- /dev/null
+++ b/arch/arm/mach-exynos/include/mach/c2c.h
@@ -0,0 +1,65 @@
+/* linux/arch/arm/mach-exynos/include/mach/c2c.h
+ *
+ * Copyright 2011 Samsung Electronics Co., Ltd.
+ * Â Â Â Â Â Â http://www.samsung.com/
+ *
+ * Platform header file for Samsung C2C Interface driver
+ *
+ * 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.
+*/
+#ifndef __ASM_PLAT_C2C_H
+#define __ASM_PLAT_C2C_H __FILE__
+
+#define C2C_SHAREDMEM_BASE 0x6000
+
+enum c2c_opp_mode {
+ Â Â Â C2C_OPP0 = 0,
+ Â Â Â C2C_OPP25 = 1,
+ Â Â Â C2C_OPP50 = 2,
+ Â Â Â C2C_OPP100 = 3,
+};
+
+enum c2c_buswidth {
+ Â Â Â C2C_BUSWIDTH_8 = 0,
+ Â Â Â C2C_BUSWIDTH_10 = 1,
+ Â Â Â C2C_BUSWIDTH_16 = 2,
+};
+
+enum c2c_shrdmem_size {
+ Â Â Â C2C_MEMSIZE_4 = 0,
+ Â Â Â C2C_MEMSIZE_8 = 1,
+ Â Â Â C2C_MEMSIZE_16 = 2,
+ Â Â Â C2C_MEMSIZE_32 = 3,
+ Â Â Â C2C_MEMSIZE_64 = 4,
+ Â Â Â C2C_MEMSIZE_128 = 5,
+ Â Â Â C2C_MEMSIZE_256 = 6,
+ Â Â Â C2C_MEMSIZE_512 = 7,
+};
+
+struct exynos_c2c_platdata {
+ Â Â Â void (*setup_gpio)(enum c2c_buswidth rx_width,
+ Â Â Â Â Â Â Â Â Â Â Â enum c2c_buswidth tx_width);
+
+ Â Â Â u32 shdmem_addr;
+ Â Â Â enum c2c_shrdmem_size shdmem_size;
+
+ Â Â Â void __iomem *ap_sscm_addr;
+ Â Â Â void __iomem *cp_sscm_addr;
+
+ Â Â Â enum c2c_buswidth rx_width;
+ Â Â Â enum c2c_buswidth tx_width;
+ Â Â Â u32 clk_opp100; /* clock of OPP100 mode */
+ Â Â Â u32 clk_opp50; Â /* clock of OPP50 mode */
+ Â Â Â u32 clk_opp25; Â /* clock of OPP25 */
+ Â Â Â enum c2c_opp_mode default_opp_mode;
+
+ Â Â Â void __iomem *c2c_sysreg; Â Â Â /* System Register address for C2C */
+ Â Â Â char *c2c_clk;
+};
+
+extern void exynos_c2c_set_platdata(struct exynos_c2c_platdata *pd);
+extern void exynos_c2c_cfg_gpio(enum c2c_buswidth rx_width,
+ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â enum c2c_buswidth tx_width);
+#endif /*__ASM_PLAT_C2C_H */
diff --git a/arch/arm/mach-exynos/include/mach/regs-c2c.h
b/arch/arm/mach-exynos/include/mach/regs-c2c.h
new file mode 100644
index 000..0c3d005
--- /dev/null
+++ b/arch/arm/mach-exynos/include/mach/regs-c2c.h
@@ -0,0 +1,71 @@
+/* linux/arch/arm/mach-exynos/include/mach/regs-c2c.h
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Register definition file for Samsung C2C
+ *
+ * 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.
+*/
+
+#ifndef __ASM_ARM_REGS_S5P_C2C_H
+#define __ASM_ARM_REGS_S5P_C2C_H
+
+/***/
+/* C2C Registers part              */
+/***/
+#define EXYNOS_C2C_REVISION Â Â Â Â Â Â 0x0
+#define EXYNOS_C2C_SYSCONFIG Â Â Â Â Â 0x4
+#define EXYNOS_C2C_SYSSTATUS Â Â Â Â Â 0x8
+#define EXYNOS_C2C_PORTCONFIG Â Â Â Â Â 0xc
+#define EXYNOS_C2C_MIRRORMODE Â Â Â Â Â 0x10
+#define EXYNOS_C2C_IRQ_RAW_STAT0 Â Â Â 0x14
+#define EXYNOS_C2C_IRQ_RAW_STAT1 Â Â Â 0x18
+#define EXYNOS_C2C_IRQ_EN_STAT0 Â Â Â Â 0x1c
+#define EXYNOS_C2C_IRQ_EN_STAT1 Â Â Â Â 0x20
+#define EXYNOS_C2C_IRQ_EN_SET0 Â Â Â Â 0x24
+#define EXYNOS_C2C_IRQ_EN_SET1 Â Â Â Â 0x28
+#define EXYNOS_C2C_IRQ_EN_CLEAR0 Â Â Â 0x2c
+#define EXYNOS_C2C_IRQ_EN_CLEAR1 Â Â Â 0x30
+#define EXYNOS_C2C_IRQ_EOI Â Â Â Â Â Â 0x34
+
+#define EXYNOS_C2C_FCLK_FREQ Â Â Â Â Â 0x40
+#define EXYNOS_C2C_RX_MAX_FREQ Â Â Â Â 0x44
+#define EXYNOS_C2C_TX_MAX_FREQ Â Â Â Â 0x48
+#define EXYNOS_C2C_RX_MAX_FREQ_ACK Â Â 0x4c
+#define EXYNOS_C2C_WAKE_REQ Â Â Â Â Â Â 0x50
+#define EXYNOS_C2C_WAKE_ACK Â Â Â Â Â Â 0x54
+#define EXYNOS_C2C_STANDBY Â Â Â Â Â Â 0x60
+#define EXYNOS_C2C_STANDBY_IN
Re: [PATCH 2/2] ARM: Exynos4: Convert exynos4-dt to CONFIG_MULTI_IRQ_HANDLER
restart is also required. On 1/31/12, Karol Lewandowski k.lewando...@samsung.com wrote: Commit 4e44d2cb95bd (ARM: exynos4: convert to CONFIG_MULTI_IRQ_HANDLER) converted all exynos boards but exynos4-dt.c. This commit fixes that omission. Signed-off-by: Karol Lewandowski k.lewando...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Thomas Abraham thomas.abra...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Marc Zyngier marc.zyng...@arm.com --- arch/arm/mach-exynos/mach-exynos4-dt.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c index 98e79c9..8aef6aa 100644 --- a/arch/arm/mach-exynos/mach-exynos4-dt.c +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c @@ -15,6 +15,7 @@ #include linux/serial_core.h #include asm/mach/arch.h +#include asm/hardware/gic.h #include mach/map.h #include plat/cpu.h @@ -83,4 +84,5 @@ DT_MACHINE_START(EXYNOS4210_DT, Samsung Exynos4 (Flattened Device Tree)) .init_machine = exynos4210_dt_machine_init, .timer = exynos4_timer, .dt_compat = exynos4210_dt_compat, + .handle_irq = gic_handle_irq, MACHINE_END -- 1.7.8.3 -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: EXYNOS: add support GPIO for EXYNOS5250
On 2/1/12, Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Wed, Feb 01, 2012 at 12:50:39AM +0900, Kukjin Kim wrote:
From: Sangsu Park sangsu4u.p...@samsung.com
This patch adds follwing.
- IO-map for EXYNOS5250 GPIO support
- EXYNOS5250 GPIO bank size/number definitions
- memory map definition for S5P GPIO4
Signed-off-by: Sangsu Park sangsu4u.p...@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
Do you actually need these static mapping definitions? The samsung
gpiolib initialization is called from a core_initcall(), and at this
time ioremap() is fully capable of working.
If it assumes it has 8 gpios, you can make it simple calculate it like this.
enum exynos5_gpios {
EXYNOS5_GPIO_A,
...
};
EXYNOS5_GPIO_A_START(n) (EXYNOS5_GPIO_A * 8)
with this one, it can make a simple gpio driver when using irq domain for GPIO.
Thank you,
Kyungmin Park
--
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
--
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/9] ARM: EXYNOS: use exynos_init_uarts() instead of exynos4_init_uarts()
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
Since exynos4_init_uarts() can be used for EXYNOS5 SoCs,
this patch changes the name of function to exynos_init_uarts().
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/common.c |8
arch/arm/mach-exynos/common.h |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index c59e188..a168533 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -56,7 +56,7 @@ static struct cpu_table cpu_ids[] __initdata = {
.idmask = EXYNOS4_CPU_MASK,
.map_io = exynos4_map_io,
.init_clocks= exynos4_init_clocks,
- .init_uarts = exynos4_init_uarts,
+ .init_uarts = exynos_init_uarts,
.init = exynos_init,
.name = name_exynos4210,
}, {
@@ -64,7 +64,7 @@ static struct cpu_table cpu_ids[] __initdata = {
.idmask = EXYNOS4_CPU_MASK,
.map_io = exynos4_map_io,
.init_clocks= exynos4_init_clocks,
- .init_uarts = exynos4_init_uarts,
+ .init_uarts = exynos_init_uarts,
.init = exynos_init,
.name = name_exynos4212,
}, {
@@ -72,7 +72,7 @@ static struct cpu_table cpu_ids[] __initdata = {
.idmask = EXYNOS4_CPU_MASK,
.map_io = exynos4_map_io,
.init_clocks= exynos4_init_clocks,
- .init_uarts = exynos4_init_uarts,
+ .init_uarts = exynos_init_uarts,
.init = exynos_init,
.name = name_exynos4412,
},
@@ -476,7 +476,7 @@ int __init exynos_init(void)
/* uart registration process */
-void __init exynos4_init_uarts(struct s3c2410_uartcfg *cfg, int no)
+void __init exynos_init_uarts(struct s3c2410_uartcfg *cfg, int no)
{
struct s3c2410_uartcfg *tcfg = cfg;
u32 ucnt;
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 8c1efe6..2d79aba 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -36,15 +36,15 @@ extern struct sys_timer exynos4_timer;
#ifdef CONFIG_ARCH_EXYNOS
extern int exynos_init(void);
+extern void exynos_init_uarts(struct s3c2410_uartcfg *cfg, int no);
extern void exynos4_map_io(void);
extern void exynos4_init_clocks(int xtal);
-extern void exynos4_init_uarts(struct s3c2410_uartcfg *cfg, int no);
Are there any cases build without CONFIG_ARCH_EXYNOS?
I think it's always defined CONFIG_ARCH_EXYNOS.
Thank you,
Kyungmin Park
#else
-#define exynos4_init_clocks NULL
-#define exynos4_init_uarts NULL
-#define exynos4_map_io NULL
#define exynos_init NULL
+#define exynos_init_uarts NULL
+#define exynos4_map_io NULL
+#define exynos4_init_clocks NULL
#endif
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/9] ARM: EXYNOS: add clock part for EXYNOS5250 SoC
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/clock-exynos5.c | 1258
arch/arm/mach-exynos/include/mach/regs-clock.h | 62 ++
Doesn't it better split the three header files?
regs-clock.h as wrapper. regs-clock-exynos4.h, regs-clock-exynos5.h
like clock C files.
arch/arm/plat-s5p/clock.c | 36 +
arch/arm/plat-samsung/include/plat/s5p-clock.h |6 +
4 files changed, 1362 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos/clock-exynos5.c
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
new file mode 100644
index 000..b0c4478
--- /dev/null
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -0,0 +1,1258 @@
+/* linux/arch/arm/mach-exynos/clock-exynos5.c
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS5 - Clock support
+ *
+ * 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.
+*/
+
+#include linux/kernel.h
+#include linux/err.h
+#include linux/io.h
+#include linux/syscore_ops.h
+
+#include plat/cpu-freq.h
+#include plat/clock.h
+#include plat/cpu.h
+#include plat/pll.h
+#include plat/s5p-clock.h
+#include plat/clock-clksrc.h
+#include plat/pm.h
+
+#include mach/map.h
+#include mach/regs-clock.h
+#include mach/sysmmu.h
+
+#include common.h
+
+#ifdef CONFIG_PM_SLEEP
+static struct sleep_save exynos5_clock_save[] = {
+ /* will be implemented */
+};
+#endif
+
+static struct clk exynos5_clk_sclk_dptxphy = {
+ .name = sclk_dptx,
+};
+
+static struct clk exynos5_clk_sclk_hdmi24m = {
+ .name = sclk_hdmi24m,
+ .rate = 2400,
+};
+
+static struct clk exynos5_clk_sclk_hdmi27m = {
+ .name = sclk_hdmi27m,
+ .rate = 2700,
+};
+
+static struct clk exynos5_clk_sclk_hdmiphy = {
+ .name = sclk_hdmiphy,
+};
+
+static struct clk exynos5_clk_sclk_usbphy = {
+ .name = sclk_usbphy,
+ .rate = 4800,
+};
+
+static int exynos5_clksrc_mask_top_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_TOP, clk, enable);
+}
+
+static int exynos5_clksrc_mask_disp1_0_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_DISP1_0, clk, enable);
+}
+
+static int exynos5_clksrc_mask_fsys_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_FSYS, clk, enable);
+}
+
+static int exynos5_clksrc_mask_gscl_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_GSCL, clk, enable);
+}
+
+static int exynos5_clksrc_mask_peric0_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_PERIC0, clk, enable);
+}
+
+static int exynos5_clk_ip_acp_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_ACP, clk, enable);
+}
+
+static int exynos5_clk_ip_core_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_CORE, clk, enable);
+}
+
+static int exynos5_clk_ip_disp1_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_DISP1, clk, enable);
+}
+
+static int exynos5_clk_ip_fsys_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_FSYS, clk, enable);
+}
+
+static int exynos5_clk_gate_block(struct clk *clk, int enable)
exynos5_clk_block_ctrl?
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_BLOCK, clk, enable);
+}
+
+static int exynos5_clk_ip_gen_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_GEN, clk, enable);
+}
+
+static int exynos5_clk_ip_gps_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_GPS, clk, enable);
+}
+
+static int exynos5_clk_ip_mfc_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_MFC, clk, enable);
+}
+
+static int exynos5_clk_ip_peric_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_PERIC, clk, enable);
+}
+
+static int exynos5_clk_ip_peris_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(EXYNOS5_CLKGATE_IP_PERIS, clk, enable);
+}
+
+/* Core list of CMU_CPU side */
+
+static struct clksrc_clk exynos5_clk_mout_apll = {
+ .clk= {
+ .name = mout_apll,
+ },
+ .sources = clk_src_apll,
+ .reg_src = { .reg = EXYNOS5_CLKSRC_CPU, .shift = 0, .size = 1 },
+};
+
+static struct clksrc_clk exynos5_clk_sclk_apll = {
+ .clk= {
+ .name = sclk_apll,
+ .parent = exynos5_clk_mout_apll.clk,
+ },
+ .reg_div
Re: [PATCH 3/9] ARM: EXYNOS: add initial setup-i2c0 for EXYNOS5
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/Makefile |2 +-
arch/arm/mach-exynos/setup-i2c0.c | 13 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 995e7cc..2117f02 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -52,7 +52,7 @@ obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
obj-$(CONFIG_EXYNOS4_DEV_DMA)+= dma.o
obj-$(CONFIG_EXYNOS4_DEV_USB_OHCI) += dev-ohci.o
-obj-$(CONFIG_ARCH_EXYNOS4) += setup-i2c0.o
+obj-$(CONFIG_ARCH_EXYNOS)+= setup-i2c0.o
obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
obj-$(CONFIG_EXYNOS4_SETUP_FIMD0)+= setup-fimd0.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C1) += setup-i2c1.o
diff --git a/arch/arm/mach-exynos/setup-i2c0.c
b/arch/arm/mach-exynos/setup-i2c0.c
index d395bd1..3244f3e 100644
--- a/arch/arm/mach-exynos/setup-i2c0.c
+++ b/arch/arm/mach-exynos/setup-i2c0.c
@@ -1,7 +1,7 @@
/*
- * linux/arch/arm/mach-exynos4/setup-i2c0.c
+ * linux/arch/arm/mach-exynos/setup-i2c0.c
*
- * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2009-2012 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*
* I2C0 GPIO configuration.
@@ -18,9 +18,14 @@ struct platform_device; /* don't need the contents */
#include linux/gpio.h
#include plat/iic.h
#include plat/gpio-cfg.h
+#include plat/cpu.h
void s3c_i2c0_cfg_gpio(struct platform_device *dev)
{
- s3c_gpio_cfgall_range(EXYNOS4_GPD1(0), 2,
- S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+ if (soc_is_exynos5250())
+ ;
+ /* will be implemented with gpio function */
Do you want to include both exynos4-gpio and exynos5-gpio?
+ else
+ s3c_gpio_cfgall_range(EXYNOS4_GPD1(0), 2,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/9] ARM: EXYNOS: add support for ARCH_EXYNOS5 and EXYNOS5250
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/Makefile|1 +
arch/arm/mach-exynos/Kconfig | 13 ++
arch/arm/mach-exynos/Makefile|1 +
arch/arm/mach-exynos/common.c| 163
--
arch/arm/mach-exynos/common.h| 19 +++
arch/arm/mach-exynos/include/mach/map.h | 21 +++-
arch/arm/mach-exynos/include/mach/regs-pmu.h |1 +
arch/arm/plat-s5p/Kconfig|4 +-
arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
9 files changed, 217 insertions(+), 16 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 40319d9..a0a5031 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -181,6 +181,7 @@ machine-$(CONFIG_ARCH_S5P64X0):= s5p64x0
machine-$(CONFIG_ARCH_S5PC100) := s5pc100
machine-$(CONFIG_ARCH_S5PV210) := s5pv210
machine-$(CONFIG_ARCH_EXYNOS4) := exynos
+machine-$(CONFIG_ARCH_EXYNOS5) := exynos
It already has CONFIG_ARCH_EXYNOS so it's enough
machine-$(CONFIG_ARCH_EXYNOS) := exynos
machine-$(CONFIG_ARCH_SA1100):= sa1100
machine-$(CONFIG_ARCH_SHARK) := shark
machine-$(CONFIG_ARCH_SHMOBILE) := shmobile
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 5d602f6..60905d5 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -22,6 +22,12 @@ config ARCH_EXYNOS4
help
Samsung EXYNOS4 SoCs based systems
+config ARCH_EXYNOS5
+ bool SAMSUNG EXYNOS5
+ select HAVE_SMP
+ help
+ Samsung EXYNOS5 SoCs based systems
It's helpful to add which ARM core is used. in case of exynos4 has
CA9, exynos5 has CA15.
+
endchoice
comment EXYNOS SoCs
@@ -53,6 +59,13 @@ config SOC_EXYNOS4412
help
Enable EXYNOS4412 SoC support
+config SOC_EXYNOS5250
+ bool SAMSUNG EXYNOS5250
+ default y
default y?
+ depends on ARCH_EXYNOS5
+ help
+ Enable EXYNOS5250 SoC support
+
config EXYNOS4_MCT
bool
default y
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 2117f02..33d27d4 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -14,6 +14,7 @@ obj-:=
obj-$(CONFIG_ARCH_EXYNOS)+= common.o
obj-$(CONFIG_ARCH_EXYNOS4) += clock-exynos4.o
+obj-$(CONFIG_ARCH_EXYNOS5) += clock-exynos5.o
obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index a168533..6ab3c5a 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -49,6 +49,7 @@
static const char name_exynos4210[] = EXYNOS4210;
static const char name_exynos4212[] = EXYNOS4212;
static const char name_exynos4412[] = EXYNOS4412;
+static const char name_exynos5250[] = EXYNOS5250;
static struct cpu_table cpu_ids[] __initdata = {
{
@@ -75,6 +76,14 @@ static struct cpu_table cpu_ids[] __initdata = {
.init_uarts = exynos_init_uarts,
.init = exynos_init,
.name = name_exynos4412,
+ }, {
+ .idcode = EXYNOS5250_SOC_ID,
+ .idmask = EXYNOS5_SOC_MASK,
+ .map_io = exynos5_map_io,
+ .init_clocks= exynos5_init_clocks,
+ .init_uarts = exynos_init_uarts,
+ .init = exynos_init,
+ .name = name_exynos5250,
},
};
@@ -83,10 +92,14 @@ static struct cpu_table cpu_ids[] __initdata = {
static struct map_desc exynos_iodesc[] __initdata = {
{
.virtual= (unsigned long)S5P_VA_CHIPID,
- .pfn= __phys_to_pfn(EXYNOS4_PA_CHIPID),
+ .pfn= __phys_to_pfn(EXYNOS_PA_CHIPID),
.length = SZ_4K,
.type = MT_DEVICE,
- }, {
+ },
+};
+
+static struct map_desc exynos4_iodesc[] __initdata = {
+ {
.virtual= (unsigned long)S3C_VA_SYS,
.pfn= __phys_to_pfn(EXYNOS4_PA_SYSCON),
.length = SZ_64K,
@@ -136,11 +149,7 @@ static struct map_desc exynos_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS4_PA_UART),
.length = SZ_512K,
.type = MT_DEVICE,
- },
-};
-
-static struct map_desc exynos4_iodesc[] __initdata = {
- {
+ }, {
.virtual= (unsigned long)S5P_VA_CMU,
.pfn= __phys_to_pfn(EXYNOS4_PA_CMU),
.length = SZ_128K,
@@ -201,6 +210,70 @@ static struct map_desc
Re: [PATCH 5/9] ARM: EXYNOS: add board file for SMDK5250
As I remember only DT based board file is acceptable for mainline?
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/Kconfig | 11
arch/arm/mach-exynos/Makefile|2 +
arch/arm/mach-exynos/mach-smdk5250.c | 94
++
3 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos/mach-smdk5250.c
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 60905d5..89b8e17 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -364,6 +364,17 @@ config MACH_SMDK4412
Machine support for Samsung SMDK4412
endif
+if ARCH_EXYNOS5
+
+comment EXYNOS5250 Boards
+
+config MACH_SMDK5250
+ bool SMDK5250
+ select SOC_EXYNOS5250
+ help
+ Machine support for Samsung SMDK4412
+endif
+
comment Flattened Device Tree based board for Exynos4 based SoC
config MACH_EXYNOS4_DT
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 33d27d4..1b12345 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -43,6 +43,8 @@ obj-$(CONFIG_MACH_SMDK4412) += mach-smdk4x12.o
obj-$(CONFIG_MACH_EXYNOS4_DT)+= mach-exynos4-dt.o
+obj-$(CONFIG_MACH_SMDK5250) += mach-smdk5250.o
+
# device support
obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o
diff --git a/arch/arm/mach-exynos/mach-smdk5250.c
b/arch/arm/mach-exynos/mach-smdk5250.c
new file mode 100644
index 000..0fe4a0b
--- /dev/null
+++ b/arch/arm/mach-exynos/mach-smdk5250.c
@@ -0,0 +1,94 @@
+/*
+ * linux/arch/arm/mach-exynos/mach-smdk5250.c
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/platform_device.h
+#include linux/serial_core.h
+
+#include asm/mach/arch.h
+#include asm/hardware/gic.h
+#include asm/mach-types.h
+
+#include plat/clock.h
+#include plat/cpu.h
+#include plat/regs-serial.h
+
+#include mach/map.h
+
+#include common.h
+
+/* Following are default values for UCON, ULCON and UFCON UART registers */
+#define SMDK5250_UCON_DEFAULT(S3C2410_UCON_TXILEVEL |\
+ S3C2410_UCON_RXILEVEL |\
+ S3C2410_UCON_TXIRQMODE | \
+ S3C2410_UCON_RXIRQMODE | \
+ S3C2410_UCON_RXFIFO_TOI | \
+ S3C2443_UCON_RXERR_IRQEN)
+
+#define SMDK5250_ULCON_DEFAULT S3C2410_LCON_CS8
+
+#define SMDK5250_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE | \
+ S5PV210_UFCON_TXTRIG4 |\
+ S5PV210_UFCON_RXTRIG4)
+
+static struct s3c2410_uartcfg smdk5250_uartcfgs[] __initdata = {
+ [0] = {
+ .hwport = 0,
+ .flags = 0,
+ .ucon = SMDK5250_UCON_DEFAULT,
+ .ulcon = SMDK5250_ULCON_DEFAULT,
+ .ufcon = SMDK5250_UFCON_DEFAULT,
+ },
+ [1] = {
+ .hwport = 1,
+ .flags = 0,
+ .ucon = SMDK5250_UCON_DEFAULT,
+ .ulcon = SMDK5250_ULCON_DEFAULT,
+ .ufcon = SMDK5250_UFCON_DEFAULT,
+ },
+ [2] = {
+ .hwport = 2,
+ .flags = 0,
+ .ucon = SMDK5250_UCON_DEFAULT,
+ .ulcon = SMDK5250_ULCON_DEFAULT,
+ .ufcon = SMDK5250_UFCON_DEFAULT,
+ },
+ [3] = {
+ .hwport = 3,
+ .flags = 0,
+ .ucon = SMDK5250_UCON_DEFAULT,
+ .ulcon = SMDK5250_ULCON_DEFAULT,
+ .ufcon = SMDK5250_UFCON_DEFAULT,
+ },
+};
+
+static void __init smdk5250_map_io(void)
+{
+ clk_xusbxti.rate = 2400;
+
+ exynos_init_io(NULL, 0);
+ s3c24xx_init_clocks(clk_xusbxti.rate);
+ s3c24xx_init_uarts(smdk5250_uartcfgs, ARRAY_SIZE(smdk5250_uartcfgs));
+}
+
+static void __init smdk5250_machine_init(void)
+{
+ /* nothing here yet */
+}
+
+MACHINE_START(SMDK5250, SMDK5250)
+ .atag_offset= 0x100,
+ .init_irq = exynos5_init_irq,
+ .map_io = smdk5250_map_io,
+ .handle_irq = gic_handle_irq,
+ .init_machine = smdk5250_machine_init,
+ .timer = exynos4_timer,
+ .restart= exynos5_restart,
+MACHINE_END
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of
Re: [PATCH 6/9] serial: samsung: Add support for EXYNOS5250
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Greg Kroah-Hartman gre...@suse.de
Signed-off-by: Kukjin Kim kgene@samsung.com
---
drivers/tty/serial/samsung.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 3b07fb9..c55e5fb 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1594,7 +1594,7 @@ static struct s3c24xx_serial_drv_data
s5pv210_serial_drv_data = {
#endif
#if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212) || \
- defined(CONFIG_SOC_EXYNOS4412)
+ defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
I think you can make it simple just use #ifdef CONFIG_ARCH_EXYNOS
static struct s3c24xx_serial_drv_data exynos4210_serial_drv_data = {
.info = (struct s3c24xx_uart_info) {
.name = Samsung Exynos4 UART,
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 8/9] ARM: EXYNOS: temporary add map definitions for uart
On 2/1/12, Kukjin Kim kgene@samsung.com wrote: Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/mach-exynos/include/mach/map.h | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h index f88acaf..300ed7e 100644 --- a/arch/arm/mach-exynos/include/mach/map.h +++ b/arch/arm/mach-exynos/include/mach/map.h @@ -167,9 +167,10 @@ #define S3C_PA_IIC5 EXYNOS4_PA_IIC(5) #define S3C_PA_IIC6 EXYNOS4_PA_IIC(6) #define S3C_PA_IIC7 EXYNOS4_PA_IIC(7) + #define S3C_PA_RTC EXYNOS4_PA_RTC #define S3C_PA_WDT EXYNOS4_PA_WATCHDOG -#define S3C_PA_UART EXYNOS4_PA_UART + #define S3C_PA_SPI0 EXYNOS4_PA_SPI0 #define S3C_PA_SPI1 EXYNOS4_PA_SPI1 #define S3C_PA_SPI2 EXYNOS4_PA_SPI2 @@ -198,9 +199,17 @@ /* Compatibility UART */ +#ifdef CONFIG_ARCH_EXYNOS4 +#define S3C_PA_UART EXYNOS4_PA_UART +#endif + +#ifdef CONFIG_ARCH_EXYNOS5 +#define S3C_PA_UART EXYNOS5_PA_UART +#endif If it selects the both ARCH_EXYNOS4 and ARCH_EXYNOS5, how to handle this one? I think it's time to clean up these macro magic. + #define S3C_VA_UARTx(x) (S3C_VA_UART + ((x) * S3C_UART_OFFSET)) -#define S5P_PA_UART(x) (EXYNOS4_PA_UART + ((x) * S3C_UART_OFFSET)) +#define S5P_PA_UART(x) (S3C_PA_UART + ((x) * S3C_UART_OFFSET)) #define S5P_PA_UART0 S5P_PA_UART(0) #define S5P_PA_UART1 S5P_PA_UART(1) #define S5P_PA_UART2 S5P_PA_UART(2) -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 9/9] ARM: EXYNOS: temporary fixup regarding get_core_count()
On 2/1/12, Kukjin Kim kgene@samsung.com wrote:
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/platsmp.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 683aec7..dfb4630 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -165,7 +165,10 @@ void __init smp_init_cpus(void)
void __iomem *scu_base = scu_base_addr();
unsigned int i, ncores;
- ncores = scu_base ? scu_get_core_count(scu_base) : 1;
+ if (soc_is_exynos5250())
+ ncores = 2;
I saw the related mail thread, I wonder then how to handle this at
other A15 board? Device Tree?
+ else
+ ncores = scu_base ? scu_get_core_count(scu_base) : 1;
/* sanity check */
if (ncores nr_cpu_ids) {
@@ -182,8 +185,8 @@ void __init smp_init_cpus(void)
void __init platform_smp_prepare_cpus(unsigned int max_cpus)
{
-
- scu_enable(scu_base_addr());
+ if (!soc_is_exynos5250())
+ scu_enable(scu_base_addr());
/*
* Write the address of secondary startup into the
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: EXYNOS: Add alias name of 'fimd' clock for 'lcd' clock
On 1/19/12, Jingoo Han jg1@samsung.com wrote: This patch adds alias name of 'fimd' clock for 'lcd' clock. While 'lcd' clock is used for s3c-fb driver, 'fimd' clock is defined for Exynos fimd ip. Therefore, 'fimd' clock can be called by using clk_add_alias(). Hi, Doesn't it better to add common.c? Are there any reason to add each board files? Thank you, Kyungmin Park Cc: Jonghwan Choi jhbird.c...@samsung.com Signed-off-by: Jingoo Han jg1@samsung.com --- arch/arm/mach-exynos/mach-nuri.c |2 ++ arch/arm/mach-exynos/mach-origen.c |2 ++ arch/arm/mach-exynos/mach-smdkv310.c |2 ++ arch/arm/mach-exynos/mach-universal_c210.c |3 +++ 4 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index 3df8bf4..06c22e0 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -1310,6 +1310,8 @@ static void __init nuri_machine_init(void) i2c9_devs[I2C9_MAX17042].irq = gpio_to_irq(EXYNOS4_GPX2(3)); i2c_register_board_info(9, i2c9_devs, ARRAY_SIZE(i2c9_devs)); + dev_set_name(s5p_device_fimd0.dev, exynos4-fb.0); + clk_add_alias(lcd, exynos4-fb.0, fimd, s5p_device_fimd0.dev); s5p_fimd0_set_platdata(nuri_fb_pdata); nuri_camera_init(); diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c index b453464..7cea0be 100644 --- a/arch/arm/mach-exynos/mach-origen.c +++ b/arch/arm/mach-exynos/mach-origen.c @@ -722,6 +722,8 @@ static void __init origen_machine_init(void) s5p_tv_setup(); s5p_i2c_hdmiphy_set_platdata(NULL); + dev_set_name(s5p_device_fimd0.dev, exynos4-fb.0); + clk_add_alias(lcd, exynos4-fb.0, fimd, s5p_device_fimd0.dev); s5p_fimd0_set_platdata(origen_lcd_pdata); platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices)); diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-exynos/mach-smdkv310.c index bf2094e..eccd96d 100644 --- a/arch/arm/mach-exynos/mach-smdkv310.c +++ b/arch/arm/mach-exynos/mach-smdkv310.c @@ -370,6 +370,8 @@ static void __init smdkv310_machine_init(void) samsung_keypad_set_platdata(smdkv310_keypad_data); samsung_bl_set(smdkv310_bl_gpio_info, smdkv310_bl_data); + dev_set_name(s5p_device_fimd0.dev, exynos4-fb.0); + clk_add_alias(lcd, exynos4-fb.0, fimd, s5p_device_fimd0.dev); s5p_fimd0_set_platdata(smdkv310_lcd0_pdata); smdkv310_ehci_init(); diff --git a/arch/arm/mach-exynos/mach-universal_c210.c b/arch/arm/mach-exynos/mach-universal_c210.c index c38e18d..fe554f1 100644 --- a/arch/arm/mach-exynos/mach-universal_c210.c +++ b/arch/arm/mach-exynos/mach-universal_c210.c @@ -31,6 +31,7 @@ #include plat/cpu.h #include plat/devs.h #include plat/iic.h +#include plat/clock.h #include plat/gpio-cfg.h #include plat/fb.h #include plat/mfc.h @@ -1029,6 +1030,8 @@ static void __init universal_machine_init(void) s5p_i2c_hdmiphy_set_platdata(NULL); i2c_register_board_info(5, i2c5_devs, ARRAY_SIZE(i2c5_devs)); + dev_set_name(s5p_device_fimd0.dev, exynos4-fb.0); + clk_add_alias(lcd, exynos4-fb.0, fimd, s5p_device_fimd0.dev); s5p_fimd0_set_platdata(universal_lcd_pdata); universal_touchkey_init(); -- 1.7.1 -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: Exynos: Hook up power domains to generic power domain infrastructure
On 1/7/12, Thomas Abraham thomas.abra...@linaro.org wrote:
Add support for generic power domain for Exynos4 platforms and remove the
Samsung specific power domain control for Exynos4.
The generic power domain infrastructure is used to control the power domains
available on Exynos4. For non-dt platforms, the power domains are statically
instantiated. For dt platforms, the power domain nodes found in the device
tree are instantiated.
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kukjin Kim kgene@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
This patch is mainly derived from Mark Brown's work on generic power domain
support for s3c64xx platforms.
arch/arm/mach-exynos/Kconfig | 10 +--
arch/arm/mach-exynos/Makefile |2 +-
arch/arm/mach-exynos/dev-pd.c | 139 -
arch/arm/mach-exynos/mach-nuri.c | 11 --
arch/arm/mach-exynos/mach-origen.c | 14 --
arch/arm/mach-exynos/mach-smdkv310.c | 12 --
arch/arm/mach-exynos/mach-universal_c210.c | 17 ---
arch/arm/mach-exynos/pm_domains.c | 183
8 files changed, 185 insertions(+), 203 deletions(-)
delete mode 100644 arch/arm/mach-exynos/dev-pd.c
create mode 100644 arch/arm/mach-exynos/pm_domains.c
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index e931924..5dec134 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -32,6 +32,7 @@ config CPU_EXYNOS4210
select ARM_CPU_SUSPEND if PM
select S5P_PM if PM
select S5P_SLEEP if PM
+ select PM_GENERIC_DOMAINS
help
Enable EXYNOS4210 CPU support
@@ -72,11 +73,6 @@ config EXYNOS4_SETUP_FIMD0
help
Common setup code for FIMD0.
-config EXYNOS4_DEV_PD
- bool
- help
- Compile in platform device definitions for Power Domain
-
config EXYNOS4_DEV_SYSMMU
bool
help
@@ -194,7 +190,6 @@ config MACH_SMDKV310
select EXYNOS4_DEV_AHCI
select SAMSUNG_DEV_KEYPAD
select EXYNOS4_DEV_DMA
- select EXYNOS4_DEV_PD
select SAMSUNG_DEV_PWM
select EXYNOS4_DEV_USB_OHCI
select EXYNOS4_DEV_SYSMMU
@@ -243,7 +238,6 @@ config MACH_UNIVERSAL_C210
select S5P_DEV_ONENAND
select S5P_DEV_TV
select EXYNOS4_DEV_DMA
- select EXYNOS4_DEV_PD
select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_I2C3
@@ -277,7 +271,6 @@ config MACH_NURI
select S5P_DEV_USB_EHCI
select S5P_SETUP_MIPIPHY
select EXYNOS4_DEV_DMA
- select EXYNOS4_DEV_PD
select EXYNOS4_SETUP_FIMC
select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_I2C1
@@ -310,7 +303,6 @@ config MACH_ORIGEN
select SAMSUNG_DEV_BACKLIGHT
select SAMSUNG_DEV_PWM
select EXYNOS4_DEV_DMA
- select EXYNOS4_DEV_PD
select EXYNOS4_DEV_USB_OHCI
select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index db527ab..b7e4eca 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_EXYNOS4) += irq-eint.o pmu.o
obj-$(CONFIG_CPU_EXYNOS4210) += clock-exynos4210.o
obj-$(CONFIG_SOC_EXYNOS4212) += clock-exynos4212.o
obj-$(CONFIG_PM) += pm.o
+obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
@@ -43,7 +44,6 @@ obj-$(CONFIG_MACH_EXYNOS4_DT) +=
mach-exynos4-dt.o
obj-$(CONFIG_ARCH_EXYNOS4) += dev-audio.o
obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
-obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
obj-$(CONFIG_EXYNOS4_DEV_DMA)+= dma.o
diff --git a/arch/arm/mach-exynos/dev-pd.c b/arch/arm/mach-exynos/dev-pd.c
deleted file mode 100644
index 3273f25..000
--- a/arch/arm/mach-exynos/dev-pd.c
+++ /dev/null
@@ -1,139 +0,0 @@
-/* linux/arch/arm/mach-exynos4/dev-pd.c
- *
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4 - Power Domain support
- *
- * 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.
-*/
-
-#include linux/io.h
-#include linux/kernel.h
-#include linux/platform_device.h
-#include linux/delay.h
-
-#include mach/regs-pmu.h
-
-#include plat/pd.h
-
-static int exynos4_pd_enable(struct device *dev)
-{
- struct
Re: [PATCH] ARM: EXYNOS: Fix build error which was from common.c and old cpu.c
On 1/9/12, Kukjin Kim kgene@samsung.com wrote:
This fixes build error and wrong merge conflicts.
arch/arm/mach-exynos/common.c: In function 'exynos4_gic_irq_fix_base':
arch/arm/mach-exynos/common.c:393: error: dereferencing pointer to
incomplete type
arch/arm/mach-exynos/common.c:396: error: dereferencing pointer to
incomplete type
Following A and B have been created from different base and the build
error was casued in the process of merging and should be fixed in this
merge window.
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Do the same job. boot tested.
A. commit db0d4db (ARM: gic: allow GIC to support non-banked setups),
commit 4e44d2c (ARM: exynos4: convert to CONFIG_MULTI_IRQ_HANDLER)
and commit 69676c3 (ARM: exynos4: Fix build error due to
'gic_bank_offset' undeclared)
B. commit cc511b8 (ARM: 7257/1: EXYNOS: introduce arch/arm/mach-exynos/
common.[ch]) introduced common.[ch])
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Axel Lin axel@gmail.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Kukjin Kim kgene@samsung.com
---
Hi Russell,
This should be fixed, I'm sending this to patch system.
If you're ok with this, please pick it up for this merge window.
Thanks.
arch/arm/mach-exynos/common.c | 20 +++-
1 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index b6ac6ee..647c843 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -19,6 +19,7 @@
#include linux/serial_core.h
#include asm/proc-fns.h
+#include asm/exception.h
Not needed.
#include asm/hardware/cache-l2x0.h
#include asm/hardware/gic.h
#include asm/mach/map.h
@@ -43,8 +44,6 @@
#include common.h
-unsigned int gic_bank_offset __read_mostly;
-
static const char name_exynos4210[] = EXYNOS4210;
static const char name_exynos4212[] = EXYNOS4212;
static const char name_exynos4412[] = EXYNOS4412;
@@ -386,27 +385,14 @@ static void __init combiner_init(unsigned int
combiner_nr, void __iomem *base,
}
}
-static void exynos4_gic_irq_fix_base(struct irq_data *d)
-{
- struct gic_chip_data *gic_data = irq_data_get_irq_chip_data(d);
-
- gic_data-cpu_base = S5P_VA_GIC_CPU +
- (gic_bank_offset * smp_processor_id());
-
- gic_data-dist_base = S5P_VA_GIC_DIST +
- (gic_bank_offset * smp_processor_id());
-}
-
void __init exynos4_init_irq(void)
{
int irq;
+ unsigned int gic_bank_offset;
gic_bank_offset = soc_is_exynos4412() ? 0x4000 : 0x8000;
- gic_init(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU);
- gic_arch_extn.irq_eoi = exynos4_gic_irq_fix_base;
- gic_arch_extn.irq_unmask = exynos4_gic_irq_fix_base;
- gic_arch_extn.irq_mask = exynos4_gic_irq_fix_base;
+ gic_init_bases(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU,
gic_bank_offset);
for (irq = 0; irq MAX_COMBINER_NR; irq++) {
--
1.7.1
--
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
--
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: EXYNOS: Adds Samsung TRATS board support
On 12/27/11, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: On 12/24/11, Kukjin Kim kgene@samsung.com wrote: HeungJun, Kim wrote: This patch adds Samsung Mobile TRATS board support. Signed-off-by: HeungJun, Kim riverful@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/Kconfig | 11 ++ arch/arm/mach-exynos/Makefile |1 + arch/arm/mach-exynos/board-trats.c | 340 3 files changed, 352 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-exynos/board-trats.c If this is for v3.3, unfortunately, it's a little late to add board file and since many things have changed I don't want to cause the conflicts with others now. BTW, why is the name board-xxx not mach-xxx like others? It's mentioned several times, How do you talk with other when talk about the smdk? I'm using the smdk machine and it's based on smdk machine? As board is more proper word and it's easy to know when find the board at source code. So hope to use the board if it's not big deal. Yes, we say 'SMDK board blah blah' so it can be no big deal, but I don't want to make a confusion between CONFIG_MACH_XXX and mach-xxx.c yet even though there is a similar situation of arch/arm/mach-xxx/ directory and CONFIG_ARCH_XXX. In addition, the machine_is_xxx() is used to distinguish board in the kernel. Anyway, I think, if to use board-xxx.c is required, we can change it all at once and let me think again. Don't think, use the current way. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 -- 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: EXYNOS: Adds Samsung TRATS board support
On 12/27/11, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: On 12/27/11, Kukjin Kim kgene@samsung.com wrote: Kyungmin Park wrote: On 12/24/11, Kukjin Kim kgene@samsung.com wrote: HeungJun, Kim wrote: This patch adds Samsung Mobile TRATS board support. Signed-off-by: HeungJun, Kim riverful@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/Kconfig | 11 ++ arch/arm/mach-exynos/Makefile |1 + arch/arm/mach-exynos/board-trats.c | 340 3 files changed, 352 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-exynos/board-trats.c If this is for v3.3, unfortunately, it's a little late to add board file and since many things have changed I don't want to cause the conflicts with others now. BTW, why is the name board-xxx not mach-xxx like others? It's mentioned several times, How do you talk with other when talk about the smdk? I'm using the smdk machine and it's based on smdk machine? As board is more proper word and it's easy to know when find the board at source code. So hope to use the board if it's not big deal. Yes, we say 'SMDK board blah blah' so it can be no big deal, but I don't want to make a confusion between CONFIG_MACH_XXX and mach-xxx.c yet even though there is a similar situation of arch/arm/mach-xxx/ directory and CONFIG_ARCH_XXX. In addition, the machine_is_xxx() is used to distinguish board in the kernel. Anyway, I think, if to use board-xxx.c is required, we can change it all at once and let me think again. Don't think, use the current way. You seem not to have the common courtesy to discuss something here. I also have same opinion on you. Discussion(?) with you is meaningless and don't see any progress. BR -- 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: EXYNOS: Adds Samsung TRATS board support
On 12/24/11, Kukjin Kim kgene@samsung.com wrote:
HeungJun, Kim wrote:
This patch adds Samsung Mobile TRATS board support.
Signed-off-by: HeungJun, Kim riverful@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/Kconfig | 11 ++
arch/arm/mach-exynos/Makefile |1 +
arch/arm/mach-exynos/board-trats.c | 340
3 files changed, 352 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos/board-trats.c
If this is for v3.3, unfortunately, it's a little late to add board file and
since many things have changed I don't want to cause the conflicts with
others now.
BTW, why is the name board-xxx not mach-xxx like others?
It's mentioned several times,
How do you talk with other when talk about the smdk?
I'm using the smdk machine and it's based on smdk machine?
As board is more proper word and it's easy to know when find the board
at source code.
So hope to use the board if it's not big deal.
BR,
Kyungmin Park
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 0afcc3b..3bbbef8 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -304,6 +304,17 @@ config MACH_ORIGEN
help
Machine support for ORIGEN based on Samsung EXYNOS4210
+config MACH_TRATS
+bool Mobile TRATS Board
+select CPU_EXYNOS4210
+select S3C_DEV_WDT
+select S3C_DEV_HSMMC
+select S3C_DEV_I2C5
+select EXYNOS4_SETUP_I2C5
+select EXYNOS4_SETUP_SDHCI
+help
+ Machine support for Samsung Mobile TRATS Board.
+
comment EXYNOS4212 Boards
config MACH_SMDK4212
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 57e5296..f3bdda9 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_ARMLEX4210) += mach-
armlex4210.o
obj-$(CONFIG_MACH_UNIVERSAL_C210) += mach-universal_c210.o
obj-$(CONFIG_MACH_NURI) += mach-nuri.o
obj-$(CONFIG_MACH_ORIGEN) += mach-origen.o
+obj-$(CONFIG_MACH_TRATS)+= board-trats.o
obj-$(CONFIG_MACH_SMDK4212) += mach-smdk4x12.o
obj-$(CONFIG_MACH_SMDK4412) += mach-smdk4x12.o
diff --git a/arch/arm/mach-exynos/board-trats.c b/arch/arm/mach-
exynos/board-trats.c
new file mode 100644
index 000..4c13dfc
--- /dev/null
+++ b/arch/arm/mach-exynos/board-trats.c
@@ -0,0 +1,340 @@
+/*
+ * linux/arch/arm/mach-exynos4/board-trats.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ *
+ * 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.
+ */
+
+#include linux/platform_device.h
+#include linux/serial_core.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/regulator/machine.h
+#include linux/regulator/fixed.h
+#include linux/mfd/max8997.h
+#include linux/mfd/max8997-private.h
+#include linux/mmc/host.h
+
+#include asm/mach/arch.h
+#include asm/mach-types.h
+
+#include plat/regs-serial.h
+#include plat/exynos4.h
+#include plat/cpu.h
+#include plat/devs.h
+#include plat/sdhci.h
+#include plat/clock.h
+#include plat/gpio-cfg.h
+#include plat/iic.h
+
+#include mach/map.h
+
+/* Following are default values for UCON, ULCON and UFCON UART registers
*/
+#define TRATS_UCON_DEFAULT (S3C2410_UCON_TXILEVEL |\
+ S3C2410_UCON_RXILEVEL |\
+ S3C2410_UCON_TXIRQMODE | \
+ S3C2410_UCON_RXIRQMODE | \
+ S3C2410_UCON_RXFIFO_TOI | \
+ S3C2443_UCON_RXERR_IRQEN)
+
+#define TRATS_ULCON_DEFAULT S3C2410_LCON_CS8
+
+#define TRATS_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE | \
+ S5PV210_UFCON_TXTRIG256 | \
+ S5PV210_UFCON_RXTRIG256)
+
+enum fixed_regulator_id {
+FIXED_REG_ID_MMC = 0,
+};
+
+static struct s3c2410_uartcfg trats_uartcfgs[] __initdata = {
+{
+.hwport = 0,
+.ucon = TRATS_UCON_DEFAULT,
+.ulcon = TRATS_ULCON_DEFAULT,
+.ufcon = TRATS_UFCON_DEFAULT,
+},
+{
+.hwport = 1,
+.ucon = TRATS_UCON_DEFAULT,
+.ulcon = TRATS_ULCON_DEFAULT,
+.ufcon = TRATS_UFCON_DEFAULT,
+},
+{
+.hwport = 2,
+.ucon = TRATS_UCON_DEFAULT,
+.ulcon = TRATS_ULCON_DEFAULT,
+.ufcon = TRATS_UFCON_DEFAULT,
+},
+{
+.hwport = 3,
+.ucon = TRATS_UCON_DEFAULT,
+.ulcon
Re: [PATCH 1/4] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
Hi Mr. Kim,
It's maybe missing for v3.3 merge at samsung soc.
Please give your opinion, how to handle it?
If you don't mind it, it can merge it by devfreq.
Thank you,
Kyungmin Park
On 12/1/11, MyungJoo Ham myungjoo@samsung.com wrote:
- Add DMC1
- Enlarge address space for DMC from 4k to 64k so that PPMU registers
may be accessed.
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/cpu.c |7 ++-
arch/arm/mach-exynos/include/mach/map.h |1 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index 90ec247..8bdcba9 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata = {
}, {
.virtual= (unsigned long)S5P_VA_DMC0,
.pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
- .length = SZ_4K,
+ .length = SZ_64K,
+ .type = MT_DEVICE,
+ }, {
+ .virtual= (unsigned long)S5P_VA_DMC1,
+ .pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
+ .length = SZ_64K,
.type = MT_DEVICE,
}, {
.virtual= (unsigned long)S5P_VA_SROMC,
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 058541d..870a980 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -57,6 +57,7 @@
#define EXYNOS4_PA_KEYPAD0x100A
#define EXYNOS4_PA_DMC0 0x1040
+#define EXYNOS4_PA_DMC1 0x1041
#define EXYNOS4_PA_COMBINER 0x1044
--
1.7.4.1
--
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
--
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] s5p-g2d: add G2D to mach-nuri
On 12/12/11, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
On Fri, Dec 09, 2011 at 05:04:41PM +0100, Kamil Debski wrote:
index 236bbe1..5251e91 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -1262,6 +1262,7 @@ static struct platform_device *nuri_devices[]
__initdata = {
s3c_device_i2c3,
i2c9_gpio,
s3c_device_adc,
+s5p_device_g2d,
For devices like g2d which are always part of the SoC and which don't
require any external wiring on the board I was thinking we should just
have the core code for the SoC register the device rather than including
it in each board individually. It'd save effort and ensure that people
automatically get to use the feature.
I'm welcome to use these scheme. make a common.c and register it automatically.
but I'm not sure we're ready to use this scheme. and I hope to start
these work at smdk board instead of this patch.
Thank you,
Kyungmin Park
The crypto accelerators are another example of this - it's not really
board specific if they're useful.
--
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
--
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/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Tue, Dec 6, 2011 at 9:13 PM, KyongHo Cho pullip@samsung.com wrote: On Tue, Dec 6, 2011 at 8:24 AM, Kyungmin Park kmp...@infradead.org wrote: On 12/6/11, Joerg Roedel joerg.roe...@amd.com wrote: On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote: Patch Summary: [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms Okay, I merged it into arm/exynos, but it is not pushed yet. Actually there were conflicts while merging, which I resolved. What I failed to find is a config for Exynos that actually builds for upstream Linux. Probably I havn't tried hard enough to find one... Can you provide a kernel config that I can use for my testing and that builds a current 3.2-rc4 kernel for Exynos? and I hope to see the real example how to use it with exynos platform. Now I can't find the interface between exynos platform and generic exynos iommu. In [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions patch, you can find sysmmu_init(). It stores associations between a system MMU and a peripheral device in platform data of platform device descriptor. If Exynos IOMMU driver finds the association while probing, then the driver can control the system MMU. Maybe it's still call the function directly instead of using struct dev field as OMAP did. Even though generic DMA mapping IOMMU doesn't used, you can connect the iommu field at arch/arm/include/asm/device.h BR, Kyungmin Park BTW, how do you test it at mainline kernel? I merged IOMMU mainline branch to our kernel branch and tested it with our FIMC, MFC, JPEG, 2D. -- 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] backlight: add regulator support for platform_lcd driver
On 12/5/11, Thomas Abraham thomas.abra...@linaro.org wrote:
The power source to the lcd panel or the lcd interface such as lvds
transmitters could be controlled by a regulator supply. Add support
for enabling/disabling the regulator when switching power to lcd.
Two new elements 'min_uV' and 'max_uV' in the platform data are added
to allow platform code to specifiy the desired output voltage from the
regulator.
Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/video/backlight/platform_lcd.c | 29 +
include/video/platform_lcd.h |7 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/video/backlight/platform_lcd.c
b/drivers/video/backlight/platform_lcd.c
index 302330a..ffa8108 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
@@ -17,6 +17,8 @@
#include linux/backlight.h
#include linux/lcd.h
#include linux/slab.h
+#include linux/regulator/consumer.h
+#include linux/regulator/machine.h
#include video/platform_lcd.h
@@ -44,11 +46,38 @@ static int platform_lcd_get_power(struct lcd_device
*lcd)
static int platform_lcd_set_power(struct lcd_device *lcd, int power)
{
struct platform_lcd *plcd = to_our_lcd(lcd);
+ struct regulator *lcd_regulator;
int lcd_power = 1;
if (power == FB_BLANK_POWERDOWN || plcd-suspended)
lcd_power = 0;
+ /*
+ * If power to lcd and/or lcd interface is controlled using a regulator,
+ * enable or disable the regulator based in the power setting.
+ */
+ lcd_regulator = regulator_get(plcd-us, vcc_lcd);
+ if (IS_ERR(lcd_regulator)) {
+ dev_info(plcd-us, could not get regulator\n);
+ goto set_power;
+ }
Recent regulator discussion. it should be failed instead fall through
gracefully.
+
+ if (lcd_power) {
+ if (plcd-pdata-min_uV || plcd-pdata-max_uV)
+ if (regulator_set_voltage(lcd_regulator,
+ plcd-pdata-min_uV, plcd-pdata-max_uV))
+ dev_info(plcd-us,
+ regulator voltage set failed\n);
Are there case to change the voltage? Doesn't it easy to set the
voltage at board file? I mean don't need to setup at drivers?
Thank you,
Kyungmin Park
+
+ if (regulator_enable(lcd_regulator))
+ dev_info(plcd-us, failed to enable regulator\n);
+ } else {
+ regulator_disable(lcd_regulator);
+ }
+
+ regulator_put(lcd_regulator);
+
+set_power:
plcd-pdata-set_power(plcd-pdata, lcd_power);
plcd-power = power;
diff --git a/include/video/platform_lcd.h b/include/video/platform_lcd.h
index ad3bdfe..acd5d21 100644
--- a/include/video/platform_lcd.h
+++ b/include/video/platform_lcd.h
@@ -14,8 +14,15 @@
struct plat_lcd_data;
struct fb_info;
+/**
+ * struct plat_lcd_data - platform data for platform_lcd driver.
+ * @min_uV: Minimum required voltage output from the regulator.
+ * @max_uV: Maximum acceptable voltage output from the regulator.
+ */
struct plat_lcd_data {
void(*set_power)(struct plat_lcd_data *, unsigned int power);
int (*match_fb)(struct plat_lcd_data *, struct fb_info *);
+ int min_uV;
+ int max_uV;
};
--
1.6.6.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
--
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: exynos: allow platform-lcd driver to control lcd regulator source on origen
On 12/5/11, Thomas Abraham thomas.abra...@linaro.org wrote:
The buck7 regulator of max8997 pmic which provides the power source to lcd
panel
and the lvds transmitter is allowed to be controlled by the platform-lcd
driver.
It is not required to apply the voltage source by default. Also, the voltage
range for buck7 regulator is modified as the per the values in the
datasheet.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/mach-exynos/mach-origen.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index f56d027..5456254 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -126,7 +126,7 @@ static struct regulator_consumer_supply __initdata
buck3_consumer[] = {
REGULATOR_SUPPLY(vdd_g3d, mali_drm), /* G3D */
};
static struct regulator_consumer_supply __initdata buck7_consumer[] = {
- REGULATOR_SUPPLY(vcc, platform-lcd), /* LCD */
+ REGULATOR_SUPPLY(vcc_lcd, platform-lcd.0), /* LCD */
};
static struct regulator_init_data __initdata max8997_ldo1_data = {
@@ -379,11 +379,11 @@ static struct regulator_init_data __initdata
max8997_buck5_data = {
static struct regulator_init_data __initdata max8997_buck7_data = {
.constraints= {
.name = VDD_LCD_3.3V,
- .min_uV = 330,
- .max_uV = 330,
+ .min_uV = 75,
+ .max_uV = 390,
It can support the voltage change at buck itself, but in board it's
fixed. I'm not sure it's correct usage at board file.
I think original code is better to understand and use it as name, it's
fixed v3.3 voltage.
Thank you,
Kyungmin Park
.boot_on= 1,
- .apply_uV = 1,
- .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS |
+ REGULATOR_CHANGE_VOLTAGE,
.state_mem = {
.disabled = 1
},
@@ -562,6 +562,8 @@ static void lcd_hv070wsa_set_power(struct plat_lcd_data
*pd, unsigned int power)
static struct plat_lcd_data origen_lcd_hv070wsa_data = {
.set_power = lcd_hv070wsa_set_power,
+ .min_uV = 330,
+ .max_uV = 330,
};
static struct platform_device origen_lcd_hv070wsa = {
--
1.6.6.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
--
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/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On 12/6/11, Joerg Roedel joerg.roe...@amd.com wrote: On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote: Patch Summary: [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms Okay, I merged it into arm/exynos, but it is not pushed yet. Actually there were conflicts while merging, which I resolved. What I failed to find is a config for Exynos that actually builds for upstream Linux. Probably I havn't tried hard enough to find one... Can you provide a kernel config that I can use for my testing and that builds a current 3.2-rc4 kernel for Exynos? and I hope to see the real example how to use it with exynos platform. Now I can't find the interface between exynos platform and generic exynos iommu. BTW, how do you test it at mainline kernel? Thank you, Kyungmin Park Thanks, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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 -- 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/4] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
On 12/2/11, Kukjin Kim kgene@samsung.com wrote:
MyungJoo Ham wrote:
- Add DMC1
- Enlarge address space for DMC from 4k to 64k so that PPMU registers
may be accessed.
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/cpu.c |7 ++-
arch/arm/mach-exynos/include/mach/map.h |1 +
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index 90ec247..8bdcba9 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata =
{
}, {
.virtual= (unsigned long)S5P_VA_DMC0,
.pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
-.length = SZ_4K,
+.length = SZ_64K,
+.type = MT_DEVICE,
+}, {
+.virtual= (unsigned long)S5P_VA_DMC1,
+.pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
+.length = SZ_64K,
.type = MT_DEVICE,
}, {
.virtual= (unsigned long)S5P_VA_SROMC,
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
exynos/include/mach/map.h
index 058541d..870a980 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -57,6 +57,7 @@
#define EXYNOS4_PA_KEYPAD 0x100A
#define EXYNOS4_PA_DMC0 0x1040
+#define EXYNOS4_PA_DMC1 0x1041
If required, so just '.length = SZ_128K'?...
Doesn't it more confuse and difficult to use?
Even though there's not much definitions. it defines the offset concept.
arch/arm/mach-exynos/include/mach/regs-mem.h
BR,
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: S3C64XX: Implement basic power domain support
Hi Mark,
I'm not sure what's the next step at s3c64xx for generic power domain.
Related with exysno4 series, it's helpful to read following threads.
http://68.183.106.108/lists/linux-pm/msg26291.html
I don't think we should control/gate the clocks with regarding power
domain from Mr. Kim
Thank you,
Kyungmin Park
On 12/2/11, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
The S3C64xx SoCs contain a set of gateable power domains which can be
enabled and disabled at runtime in order to save power. Use the generic
power domain code to implement support for these in software, enabling
runtime control of most domains:
- ETM (not supported in mainline).
- Domain G: 3D acceleration (no mainline support).
- Domain V: MFC (no mainline support).
- Domain I: JPEG and camera interface (no mainline support).
- Domain P: 2D acceleration, TV encoder and scaler (no mainline support)
- Domain S: Security (no mainline support).
- Domain F: LCD (driver already uses runtime PM), post processing and
rotation (no mainline support).
The IROM domain is marked as always enabled as we should arrange for it
to be enabled when we suspend which will need a bit more work.
Due to all the conditional device registration that the platform does
wrap s3c_pm_init() with s3c64xx_pm_init() which actually puts the device
into the power domain after the machines have registered, looking for
platform data to tell if the device was registered. Since currently only
Cragganmore actually sets up PM that is the only machine updated.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
Kikjin, this superceeds my previous patch unconditionally disabling some
of the domains. I've given it quite a bit of testing and it appears to
be working well on my systems though I'm not sure the power saving is
really all that much to write home about.
arch/arm/mach-s3c64xx/Kconfig |1 +
arch/arm/mach-s3c64xx/mach-crag6410.c |2 +-
arch/arm/mach-s3c64xx/pm.c | 173
++-
arch/arm/plat-samsung/include/plat/pm.h |6 +
4 files changed, 179 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 4d8c489..5c6c22e 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -8,6 +8,7 @@ config PLAT_S3C64XX
bool
depends on ARCH_S3C64XX
select SAMSUNG_WAKEMASK
+ select PM_GENERIC_DOMAINS
default y
help
Base platform code for any Samsung S3C64XX device
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 98d42b3..4ce4a74 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -743,7 +743,7 @@ static void __init crag6410_machine_init(void)
regulator_has_full_constraints();
- s3c_pm_init();
+ s3c64xx_pm_init();
}
MACHINE_START(WLF_CRAGG_6410, Wolfson Cragganmore 6410)
diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
index b375cd5..aa7b5d1 100644
--- a/arch/arm/mach-s3c64xx/pm.c
+++ b/arch/arm/mach-s3c64xx/pm.c
@@ -17,10 +17,12 @@
#include linux/serial_core.h
#include linux/io.h
#include linux/gpio.h
+#include linux/pm_domain.h
#include mach/map.h
#include mach/irqs.h
+#include plat/devs.h
#include plat/pm.h
#include plat/wakeup-mask.h
@@ -31,6 +33,145 @@
#include mach/regs-gpio-memport.h
#include mach/regs-modem.h
+struct s3c64xx_pm_domain {
+ char *const name;
+ u32 ena;
+ u32 pwr_stat;
+ struct generic_pm_domain pd;
+};
+
+static int s3c64xx_pd_off(struct generic_pm_domain *domain)
+{
+ struct s3c64xx_pm_domain *pd;
+ u32 val;
+
+ pd = container_of(domain, struct s3c64xx_pm_domain, pd);
+
+ val = __raw_readl(S3C64XX_NORMAL_CFG);
+ val = ~(pd-ena);
+ __raw_writel(val, S3C64XX_NORMAL_CFG);
+
+ return 0;
+}
+
+static int s3c64xx_pd_on(struct generic_pm_domain *domain)
+{
+ struct s3c64xx_pm_domain *pd;
+ u32 val;
+ long retry = 100L;
+
+ pd = container_of(domain, struct s3c64xx_pm_domain, pd);
+
+ val = __raw_readl(S3C64XX_NORMAL_CFG);
+ val |= pd-ena;
+ __raw_writel(val, S3C64XX_NORMAL_CFG);
+
+ /* Not all domains provide power status readback */
+ if (pd-pwr_stat) {
+ while (retry--)
+ if (__raw_readl(S3C64XX_BLK_PWR_STAT) pd-pwr_stat)
+ break;
+ if (!retry) {
+ pr_err(Failed to start domain %s\n, pd-name);
+ return -EBUSY;
+ }
+ }
+
+ return 0;
+}
+
+static struct s3c64xx_pm_domain s3c64xx_pm_irom = {
+ .name = IROM,
+ .ena = S3C64XX_NORMALCFG_IROM_ON,
+ .pd = {
+ .power_off = s3c64xx_pd_off,
+ .power_on = s3c64xx_pd_on,
+ },
+};
+
+static
Re: [GIT PULL] Samsung fixes for v3.2
Hi, Don't you fix the mct compiler error if LOCAL_TIMERS are not defined? arch/arm/mach-exynos/mct.c: In function 'exynos4_timer_resources': arch/arm/mach-exynos/mct.c:451: error: 'exynos4_mct_tick_isr' undeclared (first use in this function) arch/arm/mach-exynos/mct.c:451: error: (Each undeclared identifier is reported only once arch/arm/mach-exynos/mct.c:451: error: for each function it appears in.) make[1]: *** [arch/arm/mach-exynos/mct.o] Error 1 Thank you, Kyungmin Park On 11/21/11, Kukjin Kim kgene@samsung.com wrote: Hi Arnd, Please pull samsung-fixes for v3.2 from: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git samsung-fixes This includes fix of inclusion header. If any problems, please let me know. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5: Linux 3.2-rc1 (2011-11-07 16:16:02 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git samsung-fixes Axel Lin (1): ARM: SAMSUNG: include linux/types.h at gpio-cfg.h Kukjin Kim (2): ARM: S5P: Fix export.h inclusion ARM: SAMSUNG: inclusion export.h instead of module.h Kyungmin Park (1): ARM: EXYNOS: Fix compiler error with THIS_MODULE arch/arm/mach-exynos/cpuidle.c|2 ++ arch/arm/mach-s3c64xx/mach-crag6410-module.c |2 +- arch/arm/plat-s3c24xx/cpu-freq-debugfs.c |2 +- arch/arm/plat-s5p/sysmmu.c|1 + arch/arm/plat-samsung/include/plat/gpio-cfg.h |2 ++ arch/arm/plat-samsung/pd.c|2 +- arch/arm/plat-samsung/pwm.c |2 +- 7 files changed, 9 insertions(+), 4 deletions(-) -- 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 -- 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
