[PATCH] serial: samsung: Add poll_get_char poll_put_char
From: Julien Pichon pichon@gmail.com
The following patch allows users to use KGDB over serial console on
board based on Samsung SOC. It has been tested on a board using
exynos5.
Signed-off-by: Julien Pichon pichon@gmail.com
Signed-off-by: Doug Anderson diand...@chromium.org
(dianders changed poll to return NO_POLL_CHAR, which appears to
fix 'help' in kgdb; also updated commit message)
---
This is pulled from an email on linux-samsung-soc@vger.kernel.org
from Feb 18, 2012. It's never landed anywhere. I've made a small modification
that make it so that kgdb's help doesn't crash.
See: http://comments.gmane.org/gmane.linux.kernel.samsung-soc/9477
drivers/tty/serial/samsung.c | 47 ++
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 8eef114..7f04717 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -876,11 +876,24 @@ s3c24xx_serial_verify_port(struct uart_port *port, struct
serial_struct *ser)
static struct console s3c24xx_serial_console;
+static int __init s3c24xx_serial_console_init(void)
+{
+ register_console(s3c24xx_serial_console);
+ return 0;
+}
+console_initcall(s3c24xx_serial_console_init);
+
#define S3C24XX_SERIAL_CONSOLE s3c24xx_serial_console
#else
#define S3C24XX_SERIAL_CONSOLE NULL
#endif
+#ifdef CONFIG_CONSOLE_POLL
+static int s3c24xx_serial_get_poll_char(struct uart_port *port);
+static void s3c24xx_serial_put_poll_char(struct uart_port *port,
+unsigned char c);
+#endif
+
static struct uart_ops s3c24xx_serial_ops = {
.pm = s3c24xx_serial_pm,
.tx_empty = s3c24xx_serial_tx_empty,
@@ -899,6 +912,10 @@ static struct uart_ops s3c24xx_serial_ops = {
.request_port = s3c24xx_serial_request_port,
.config_port= s3c24xx_serial_config_port,
.verify_port= s3c24xx_serial_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_get_char = s3c24xx_serial_get_poll_char,
+ .poll_put_char = s3c24xx_serial_put_poll_char,
+#endif
};
static struct uart_driver s3c24xx_uart_drv = {
@@ -1316,6 +1333,36 @@ s3c24xx_serial_console_txrdy(struct uart_port *port,
unsigned int ufcon)
return (utrstat S3C2410_UTRSTAT_TXE) ? 1 : 0;
}
+#ifdef CONFIG_CONSOLE_POLL
+/*
+ * Console polling routines for writing and reading from the uart while
+ * in an interrupt or debug context.
+ */
+
+static int s3c24xx_serial_get_poll_char(struct uart_port *port)
+{
+ struct s3c24xx_uart_port *ourport = to_ourport(port);
+ unsigned int ufstat;
+
+ ufstat = rd_regl(port, S3C2410_UFSTAT);
+ if (s3c24xx_serial_rx_fifocnt(ourport, ufstat) == 0)
+ return NO_POLL_CHAR;
+
+ return rd_regb(port, S3C2410_URXH);
+}
+
+static void s3c24xx_serial_put_poll_char(struct uart_port *port,
+ unsigned char c)
+{
+ unsigned int ufcon = rd_regl(cons_uart, S3C2410_UFCON);
+
+ while (!s3c24xx_serial_console_txrdy(port, ufcon))
+ cpu_relax();
+ wr_regb(cons_uart, S3C2410_UTXH, c);
+}
+
+#endif /* CONFIG_CONSOLE_POLL */
+
static void
s3c24xx_serial_console_putchar(struct uart_port *port, int ch)
{
--
1.7.7.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
[PATCH 1/2] ARM: dts: exynos: Move the dwmmc aliases from smdk5250 dts to exynos
The aliases for dwmmc were placed in the SMDK5250 dts file but really
should be common for all exynos5250 boards. Move it to the common CPU
file.
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 12
arch/arm/boot/dts/exynos5250.dtsi | 12
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 405009c..541fe39 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -17,10 +17,6 @@
compatible = samsung,smdk5250, samsung,exynos5250;
aliases {
- mshc0 = dwmmc_0;
- mshc1 = dwmmc_1;
- mshc2 = dwmmc_2;
- mshc3 = dwmmc_3;
};
memory {
@@ -97,7 +93,7 @@
};
};
- dwmmc_0: dwmmc0@1220 {
+ dwmmc0@1220 {
num-slots = 1;
supports-highspeed;
broken-cd;
@@ -118,11 +114,11 @@
};
};
- dwmmc_1: dwmmc1@1221 {
+ dwmmc1@1221 {
status = disabled;
};
- dwmmc_2: dwmmc2@1222 {
+ dwmmc2@1222 {
num-slots = 1;
supports-highspeed;
fifo-depth = 0x80;
@@ -143,7 +139,7 @@
};
};
- dwmmc_3: dwmmc3@1223 {
+ dwmmc3@1223 {
status = disabled;
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index cf6a02d..7c5664b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -31,6 +31,10 @@
gsc1 = gsc_1;
gsc2 = gsc_2;
gsc3 = gsc_3;
+ mshc0 = dwmmc_0;
+ mshc1 = dwmmc_1;
+ mshc2 = dwmmc_2;
+ mshc3 = dwmmc_3;
};
gic:interrupt-controller@10481000 {
@@ -206,7 +210,7 @@
#size-cells = 0;
};
- dwmmc0@1220 {
+ dwmmc_0: dwmmc0@1220 {
compatible = samsung,exynos5250-dw-mshc;
reg = 0x1220 0x1000;
interrupts = 0 75 0;
@@ -214,7 +218,7 @@
#size-cells = 0;
};
- dwmmc1@1221 {
+ dwmmc_1: dwmmc1@1221 {
compatible = samsung,exynos5250-dw-mshc;
reg = 0x1221 0x1000;
interrupts = 0 76 0;
@@ -222,7 +226,7 @@
#size-cells = 0;
};
- dwmmc2@1222 {
+ dwmmc_2: dwmmc2@1222 {
compatible = samsung,exynos5250-dw-mshc;
reg = 0x1222 0x1000;
interrupts = 0 77 0;
@@ -230,7 +234,7 @@
#size-cells = 0;
};
- dwmmc3@1223 {
+ dwmmc_3: dwmmc3@1223 {
compatible = samsung,exynos5250-dw-mshc;
reg = 0x1223 0x1000;
interrupts = 0 78 0;
--
1.7.7.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
[PATCH 2/2] ARM: dts: snow: Add board dts file for Snow board (ARM Chromebook)
This dts file is based on the Snow dts file in the Chromium OS kernel
tree with the following changes:
* Some details have been updated to match the exynos5250-smdk5250.dts
file from linux-next (as of
c11068538994430547722dc9fb515a0ceefd5cb9).
* This file doesn't include references to hardware whose upstream
support isn't quite there yet. That includes most i2c devices.
Note that most i2c busses have been included with no devices.
The Snow dts file is mostly just an include of the cros5250 dts file
which describes a class of similar boards. Support for other boards
has not yet been send upstream.
With this file and a change to use UART3 for serial output I can:
* Boot to a command line using either SD or EMMC as a root filesystem
* See the power button and lid switch using evtest.
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/cros5250-common.dtsi | 184
arch/arm/boot/dts/exynos5250-snow.dts | 43
3 files changed, 229 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/boot/dts/cros5250-common.dtsi
create mode 100644 arch/arm/boot/dts/exynos5250-snow.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 701388b..7d43a13 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -36,7 +36,8 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
exynos4412-smdk4412.dtb \
- exynos5250-smdk5250.dtb
+ exynos5250-smdk5250.dtb \
+ exynos5250-snow.dtb
dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
ecx-2000.dtb
dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
new file mode 100644
index 000..fddd174
--- /dev/null
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -0,0 +1,184 @@
+/*
+ * Common device tree include for all Exynos 5250 boards based off of Daisy.
+ *
+ * Copyright (c) 2012 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+ aliases {
+ };
+
+ memory {
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ };
+
+ i2c@12C6 {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 378000;
+ gpios = gpb3 0 2 3 0,
+ gpb3 1 2 3 0;
+ };
+
+ i2c@12C7 {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 378000;
+ gpios = gpb3 2 2 3 0,
+ gpb3 3 2 3 0;
+ };
+
+ i2c@12C8 {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 66000;
+
+ /*
+* Disabled pullups since external part has its own pullups and
+* double-pulling gets us out of spec in some cases.
+*/
+ gpios = gpa0 6 3 0 0,
+ gpa0 7 3 0 0;
+
+ hdmiddc@50 {
+ compatible = samsung,exynos5-hdmiddc;
+ reg = 0x50;
+ };
+ };
+
+ i2c@12C9 {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 66000;
+ gpios = gpa1 2 3 3 0,
+ gpa1 3 3 3 0;
+ };
+
+ i2c@12CA {
+ status = disabled;
+ };
+
+ i2c@12CB {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 66000;
+ gpios = gpa2 2 3 3 0,
+ gpa2 3 3 3 0;
+ };
+
+ i2c@12CC {
+ status = disabled;
+ };
+
+ i2c@12CD {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 66000;
+ gpios = gpb2 2 3 3 0,
+ gpb2 3 3 3 0;
+ };
+
+ i2c@12CE {
+ samsung,i2c-sda-delay = 100;
+ samsung,i2c-max-bus-freq = 378000;
+
+ hdmiphy@38 {
+ compatible = samsung,exynos5-hdmiphy;
+ reg = 0x38;
+ };
+ };
+
+ dwmmc0@1220 {
+ num-slots = 1;
+ supports-highspeed;
+ broken-cd;
+ fifo-depth = 0x80;
+ card-detect-delay = 200;
+ samsung,dw-mshc-ciu-div = 3;
+ samsung,dw-mshc-sdr-timing = 2 3 3;
+ samsung,dw-mshc-ddr-timing = 1 2 3;
+
+ slot@0 {
+ reg = 0;
+ bus-width = 8;
+ gpios = gpc0 0 2 0 3, gpc0 1 2 0 3,
+ gpc1 0 2 3 3
[PATCH] ARM: exynos: dt: add all i2c busses to auxdata
From: Olof Johansson o...@lixom.net
Needed to match device ids for clocks, etc.
Signed-off-by: Olof Johansson o...@lixom.net
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/mach-exynos/mach-exynos5-dt.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index ed37273..e1491f7 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -52,6 +52,16 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
s3c2440-i2c.1, NULL),
OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS5_PA_IIC(2),
s3c2440-i2c.2, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS5_PA_IIC(3),
+ s3c2440-i2c.3, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS5_PA_IIC(4),
+ s3c2440-i2c.4, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS5_PA_IIC(5),
+ s3c2440-i2c.5, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS5_PA_IIC(6),
+ s3c2440-i2c.6, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS5_PA_IIC(7),
+ s3c2440-i2c.7, NULL),
OF_DEV_AUXDATA(samsung,s3c2440-hdmiphy-i2c, EXYNOS5_PA_IIC(8),
s3c2440-hdmiphy-i2c, NULL),
OF_DEV_AUXDATA(samsung,exynos5250-dw-mshc, EXYNOS5_PA_DWMCI0,
--
1.7.7.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
[PATCH 1/2] ARM: EXYNOS: Add aliases for i2c controller for exynos4
This is similar to a recent commit for exynos5250 titled:
ARM: EXYNOS: Add aliases for i2c controller
Adding aliases will be useful to prevent warnings in a future
change. See:
i2c: s3c2410: Get the i2c bus number from alias id
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/exynos4.dtsi | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index a26c3dd..824d362 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -28,6 +28,14 @@
spi0 = spi_0;
spi1 = spi_1;
spi2 = spi_2;
+ i2c0 = i2c_0;
+ i2c1 = i2c_1;
+ i2c2 = i2c_2;
+ i2c3 = i2c_3;
+ i2c4 = i2c_4;
+ i2c5 = i2c_5;
+ i2c6 = i2c_6;
+ i2c7 = i2c_7;
};
gic:interrupt-controller@1049 {
@@ -121,7 +129,7 @@
status = disabled;
};
- i2c@1386 {
+ i2c_0: i2c@1386 {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
@@ -130,7 +138,7 @@
status = disabled;
};
- i2c@1387 {
+ i2c_1: i2c@1387 {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
@@ -139,7 +147,7 @@
status = disabled;
};
- i2c@1388 {
+ i2c_2: i2c@1388 {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
@@ -148,7 +156,7 @@
status = disabled;
};
- i2c@1389 {
+ i2c_3: i2c@1389 {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
@@ -157,7 +165,7 @@
status = disabled;
};
- i2c@138A {
+ i2c_4: i2c@138A {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
@@ -166,7 +174,7 @@
status = disabled;
};
- i2c@138B {
+ i2c_5: i2c@138B {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
@@ -175,7 +183,7 @@
status = disabled;
};
- i2c@138C {
+ i2c_6: i2c@138C {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
@@ -184,7 +192,7 @@
status = disabled;
};
- i2c@138D {
+ i2c_7: i2c@138D {
#address-cells = 1;
#size-cells = 0;
compatible = samsung,s3c2440-i2c;
--
1.7.7.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
[PATCH] ARM: exynos: add UART3 to DEBUG_LL ports
From: Olof Johansson o...@lixom.net UART3 is used for debugging on exynos5250-snow. [dianders: cleaned commit message.] Signed-off-by: Olof Johansson o...@lixom.net Signed-off-by: Doug Anderson diand...@chromium.org --- arch/arm/Kconfig.debug| 11 +++ arch/arm/plat-samsung/Kconfig |1 + 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 33a8930..35ba7dc 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -355,6 +355,17 @@ choice The uncompressor code port configuration is now handled by CONFIG_S3C_LOWLEVEL_UART_PORT. + config DEBUG_S3C_UART3 + depends on PLAT_SAMSUNG + bool Use S3C UART 3 for low-level debug + help + Say Y here if you want the debug print routines to direct + their output to UART 3. The port must have been initialised + by the boot-loader before use. + + The uncompressor code port configuration is now handled + by CONFIG_S3C_LOWLEVEL_UART_PORT. + config DEBUG_SOCFPGA_UART depends on ARCH_SOCFPGA bool Use SOCFPGA UART for low-level debug diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 59401e1..d342ed0 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -502,5 +502,6 @@ config DEBUG_S3C_UART default 0 if DEBUG_S3C_UART0 default 1 if DEBUG_S3C_UART1 default 2 if DEBUG_S3C_UART2 + default 3 if DEBUG_S3C_UART3 endif -- 1.7.7.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
[PATCH v2] ARM: exynos: add UART3 to DEBUG_LL ports
From: Olof Johansson o...@lixom.net Add support for using UART3 for DEBUG_LL on exynos. [dianders: added depend on ARCH_EXYNOS.] Signed-off-by: Olof Johansson o...@lixom.net Signed-off-by: Doug Anderson diand...@chromium.org --- Changes in v2: - Matched Olof's commit message. - Added ARCH_EXYNOS to depend list. arch/arm/Kconfig.debug| 11 +++ arch/arm/plat-samsung/Kconfig |1 + 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 33a8930..f54f170 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -355,6 +355,17 @@ choice The uncompressor code port configuration is now handled by CONFIG_S3C_LOWLEVEL_UART_PORT. + config DEBUG_S3C_UART3 + depends on PLAT_SAMSUNG ARCH_EXYNOS + bool Use S3C UART 3 for low-level debug + help + Say Y here if you want the debug print routines to direct + their output to UART 3. The port must have been initialised + by the boot-loader before use. + + The uncompressor code port configuration is now handled + by CONFIG_S3C_LOWLEVEL_UART_PORT. + config DEBUG_SOCFPGA_UART depends on ARCH_SOCFPGA bool Use SOCFPGA UART for low-level debug diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 59401e1..d342ed0 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -502,5 +502,6 @@ config DEBUG_S3C_UART default 0 if DEBUG_S3C_UART0 default 1 if DEBUG_S3C_UART1 default 2 if DEBUG_S3C_UART2 + default 3 if DEBUG_S3C_UART3 endif -- 1.7.7.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
Re: [PATCH] ARM: exynos: add UART3 to DEBUG_LL ports
On Tue, Nov 20, 2012 at 11:29 PM, Olof Johansson o...@lixom.net wrote: On Tue, Nov 20, 2012 at 02:48:58PM -0800, Doug Anderson wrote: From: Olof Johansson o...@lixom.net UART3 is used for debugging on exynos5250-snow. [dianders: cleaned commit message.] Signed-off-by: Olof Johansson o...@lixom.net Signed-off-by: Doug Anderson diand...@chromium.org --- arch/arm/Kconfig.debug| 11 +++ arch/arm/plat-samsung/Kconfig |1 + 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 33a8930..35ba7dc 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -355,6 +355,17 @@ choice The uncompressor code port configuration is now handled by CONFIG_S3C_LOWLEVEL_UART_PORT. + config DEBUG_S3C_UART3 + depends on PLAT_SAMSUNG Sorry, the reason I hadn't re-posted this is that Kukjin had proposed to protect users of = 3 UART platforms to select it. An added Depends on ARCH_EXYNOS4 || ARCH_EXYNOS5 should cover that. Can you add and repost, please? Doh! I hadn't even noticed that you'd already posted this--I got mine from the Chrome OS tree directly. Sorry about that... I've added an for ARCH_EXYNOS which seems reasonable. I left PLAT_SAMSUNG as a depend though technically ARCH_EXYNOS does select PLAT_SAMSUNG through a convoluted series of other config options. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add automatic bus number support for i2c busses with device tree
This was suggested by Mark Brown in response to a patch for adding this functionality only for the s3c2410 bus: https://lkml.org/lkml/2012/11/20/681 I have also modified the i2c-pxa driver to use this new functionality but have no good way to test that patch. Hopefully someone else can test and ack. The patch adding the generic functionality could go in even if the i2c-pxa patch needs changes. Doug Anderson (2): i2c-core: dt: Pick i2c bus number from i2c alias if present i2c: pxa: Use i2c-core to get bus number now drivers/i2c/busses/i2c-pxa.c |8 +--- drivers/i2c/i2c-core.c | 105 ++--- 2 files changed, 78 insertions(+), 35 deletions(-) -- 1.7.7.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
[PATCH 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
i2c0 = i2c_0;
i2c1 = i2c_1;
};
Signed-off-by: Doug Anderson diand...@chromium.org
CC: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/i2c/i2c-core.c | 105 +++-
1 files changed, 77 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a7edf98..71deb2a2 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -915,13 +915,81 @@ out_list:
}
/**
+ * i2c_get_number_from_dt - get the adapter number based on dt alias
+ * @adap: the adapter to look at
+ *
+ * Check whether there's an alias in the FDT that gives an ID for this i2c
+ * device. Use an alias like i2cnr, like:
+ * aliases {
+ * i2c0 = i2c_0;
+ * i2c1 = i2c_1;
+ * };
+ *
+ * Returns the ID if found. If no alias is found returns -1.
+ */
+static int i2c_get_number_from_dt(struct i2c_adapter *adap)
+{
+ struct device *dev = adap-dev;
+ int id;
+
+ if (!dev-of_node)
+ return -1;
+
+ id = of_alias_get_id(dev-of_node, i2c);
+ if (id 0)
+ return -1;
+ return id;
+}
+
+/**
+ * _i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap-nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int _i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ int id;
+ int status;
+
+ /* Handled by wrappers */
+ BUG_ON(adap-nr == -1);
+
+ if (adap-nr ~MAX_IDR_MASK)
+ return -EINVAL;
+
+retry:
+ if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
+ return -ENOMEM;
+
+ mutex_lock(core_lock);
+ /* above here means above or equal to, sigh;
+* we need the equal to result to force the result
+*/
+ status = idr_get_new_above(i2c_adapter_idr, adap, adap-nr, id);
+ if (status == 0 id != adap-nr) {
+ status = -EBUSY;
+ idr_remove(i2c_adapter_idr, id);
+ }
+ mutex_unlock(core_lock);
+ if (status == -EAGAIN)
+ goto retry;
+
+ if (status == 0)
+ status = i2c_register_adapter(adap);
+ return status;
+}
+
+/**
* i2c_add_adapter - declare i2c adapter, use dynamic bus number
* @adapter: the adapter to add
* Context: can sleep
*
* This routine is used to declare an I2C adapter when its bus number
- * doesn't matter. Examples: for I2C adapters dynamically added by
- * USB links or PCI plugin cards.
+ * doesn't matter or when its bus number is specified by an dt alias.
+ * Examples of bases when the bus number doesn't matter: I2C adapters
+ * dynamically added by USB links or PCI plugin cards.
*
* When this returns zero, a new bus number was allocated and stored
* in adap-nr, and the specified adapter became available for clients.
@@ -931,6 +999,12 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
{
int id, res = 0;
+ id = i2c_get_number_from_dt(adapter);
+ if (id = 0) {
+ adapter-nr = id;
+ return _i2c_add_numbered_adapter(adapter);
+ }
+
retry:
if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
return -ENOMEM;
@@ -977,34 +1051,9 @@ EXPORT_SYMBOL(i2c_add_adapter);
*/
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
{
- int id;
- int status;
-
if (adap-nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
- if (adap-nr ~MAX_IDR_MASK)
- return -EINVAL;
-
-retry:
- if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
- return -ENOMEM;
-
- mutex_lock(core_lock);
- /* above here means above or equal to, sigh;
-* we need the equal to result to force the result
-*/
- status = idr_get_new_above(i2c_adapter_idr, adap, adap-nr, id);
- if (status == 0 id != adap-nr) {
- status = -EBUSY;
- idr_remove(i2c_adapter_idr, id);
- }
- mutex_unlock(core_lock);
- if (status == -EAGAIN)
- goto retry;
-
- if (status == 0)
- status = i2c_register_adapter(adap);
- return status;
+ return _i2c_add_numbered_adapter(adap);
}
EXPORT_SYMBOL_GPL(i2c_add_numbered_adapter);
--
1.7.7.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
[PATCH 2/2] i2c: pxa: Use i2c-core to get bus number now
The commit: i2c-core: dt: Pick i2c bus number from i2c alias if
present adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/i2c/busses/i2c-pxa.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..8ee9fa0 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1053,16 +1053,10 @@ static int i2c_pxa_probe_dt(struct platform_device
*pdev, struct pxa_i2c *i2c,
struct device_node *np = pdev-dev.of_node;
const struct of_device_id *of_id =
of_match_device(i2c_pxa_dt_ids, pdev-dev);
- int ret;
if (!of_id)
return 1;
- ret = of_alias_get_id(np, i2c);
- if (ret 0) {
- dev_err(pdev-dev, failed to get alias id, errno %d\n, ret);
- return ret;
- }
- pdev-id = ret;
+ pdev-id = -1;
if (of_get_property(np, mrvl,i2c-polling, NULL))
i2c-use_pio = 1;
if (of_get_property(np, mrvl,i2c-fast-mode, NULL))
--
1.7.7.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
Re: [PATCH 2/2] i2c: s3c2410: Get the i2c bus number from alias id
On Tue, Nov 20, 2012 at 8:09 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 20, 2012 at 02:27:04PM -0800, Doug Anderson wrote: From: Padmavathi Venna padm...@samsung.com Get the i2c bus number that the device is connected to using the alias id. This makes debugging / grokking of kernel messages much easier. This doesn't look like a s3c2410 specific change - it's a generic device tree issue. This suggests that it sohuld be implemented in the framework so that all I2C controllers with DT can use it. Good suggestion. I have posted a series with the title Add automatic bus number support for i2c busses with device tree. It contains the i2c-core patch as well as a patch removing similar code from the pxa i2c driver. Kukjin: please consider this patch abandoned and superseded by the new i2c-core patch. As Olof said, the patch for adding aliases for exynos4 should still be fine to apply. Thanks! -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mmc: dw_mmc: Handle wp-gpios from device tree
On some SoCs (like exynos5250) you need to use an external GPIO for
write protect. Add support for wp-gpios to the core dw_mmc driver
since it could be useful across multiple SoCs.
With this change I am able to make use of the write protect for the
external SD slot on exynos5250-snow.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mmc/host/dw_mmc.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 5b41348..9c79870 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -34,6 +34,7 @@
#include linux/regulator/consumer.h
#include linux/workqueue.h
#include linux/of.h
+#include linux/of_gpio.h
#include dw_mmc.h
@@ -74,6 +75,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @wp_gpio: If gpio_is_valid() we'll use this to read write protect.
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +90,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int wp_gpio;
+
u32 ctype;
struct mmc_request *mrq;
@@ -832,6 +836,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
read_only = 0;
else if (brd-get_ro)
read_only = brd-get_ro(slot-id);
+ else if (gpio_is_valid(slot-wp_gpio))
+ read_only = gpio_get_value(slot-wp_gpio);
else
read_only =
mci_readl(slot-host, WRTPRT) (1 slot-id) ? 1 : 0;
@@ -1802,6 +1808,29 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev, u8
slot)
as 1\n);
return bus_wd;
}
+
+/* find the write protect gpio for a given slot; or -1 if none specified */
+static u32 dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int gpio;
+
+ if (!np)
+ return -1;
+
+ gpio = of_get_named_gpio(np, wp-gpios, 0);
+
+ /* Having a missing entry is valid; return silently */
+ if (!gpio_is_valid(gpio))
+ return -1;
+
+ if (devm_gpio_request(dev, gpio, dw-mci-wp)) {
+ dev_warn(dev, gpio [%d] request failed\n, gpio);
+ return -1;
+ }
+
+ return gpio;
+}
#else /* CONFIG_OF */
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
@@ -1811,6 +1840,10 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
{
return NULL;
}
+static u32 dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ return -1;
+}
#endif /* CONFIG_OF */
static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
@@ -1923,6 +1956,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
else
clear_bit(DW_MMC_CARD_PRESENT, slot-flags);
+ slot-wp_gpio = dw_mci_of_get_wp_gpio(host-dev, slot-id);
+
mmc_add_host(mmc);
#if defined(CONFIG_DEBUG_FS)
--
1.7.7.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
Re: [PATCH 2/2] mmc: dw_mmc: Handle wp-gpios from device tree
On Wed, Nov 21, 2012 at 5:42 PM, Seungwon Jeon tgih@samsung.com wrote: Hi, wp-gpios has been implemented in dw_mmc-exynos.c It can be reused for EXYNOS platform? We need to modify some though. Yup, I've seen that. Patch 1/2 (mmc: dw_mmc: exynos: Stop claiming wp-gpio) addressed that. For some reason I can't find that on LKML.org yet. Strange. :-/ I'll forward it on to you shortly. In any case: I found that the exynos code didn't actually work. It claimed the GPIO but didn't ever look at it. I have the beginnings of the code to implement this properly in the exynos code but I stopped working on it when I decided that other SoCs could also benefit from the code and it fit better in the general dw_mmc driver. If you disagree and would like me to cleanup the version of this patch that's just in the exynos driver and post that, I will. Just let me know. Thanks for the review! -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mmc: dw_mmc: Handle wp-gpios from device tree
Jaehoon,
Thanks for the review. See below for comments. I'll plan on a new
patch either Monday or Tuesday when I have a chance to spin and
re-test.
On Wed, Nov 21, 2012 at 5:55 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
On 11/22/2012 07:03 AM, Doug Anderson wrote:
On some SoCs (like exynos5250) you need to use an external GPIO for
write protect. Add support for wp-gpios to the core dw_mmc driver
since it could be useful across multiple SoCs.
With this change I am able to make use of the write protect for the
external SD slot on exynos5250-snow.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mmc/host/dw_mmc.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 5b41348..9c79870 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -34,6 +34,7 @@
#include linux/regulator/consumer.h
#include linux/workqueue.h
#include linux/of.h
+#include linux/of_gpio.h
#include dw_mmc.h
@@ -74,6 +75,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @wp_gpio: If gpio_is_valid() we'll use this to read write protect.
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +90,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int wp_gpio;
+
u32 ctype;
struct mmc_request *mrq;
@@ -832,6 +836,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
read_only = 0;
else if (brd-get_ro)
read_only = brd-get_ro(slot-id);
+ else if (gpio_is_valid(slot-wp_gpio))
+ read_only = gpio_get_value(slot-wp_gpio);
else
read_only =
mci_readl(slot-host, WRTPRT) (1 slot-id) ? 1 :
0;
@@ -1802,6 +1808,29 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev,
u8 slot)
as 1\n);
return bus_wd;
}
+
+/* find the write protect gpio for a given slot; or -1 if none specified */
+static u32 dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int gpio;
+
+ if (!np)
+ return -1;
I think good that use the error number instead of -1. Also the below code.
In this case it's not really returning an error code which is why I
chose -1. It's returning a gpio number or anything that is a sentinel
value indicating that the GPIO is not valid.
...but you're right, an error code would work. I'll replace with
-EINVAL in my next patch.
+
+ gpio = of_get_named_gpio(np, wp-gpios, 0);
+
+ /* Having a missing entry is valid; return silently */
+ if (!gpio_is_valid(gpio))
+ return -1;
+
+ if (devm_gpio_request(dev, gpio, dw-mci-wp)) {
+ dev_warn(dev, gpio [%d] request failed\n, gpio);
+ return -1;
+ }
+
+ return gpio;
gpio is int type, but return type is u32?
Good catch. Will fix.
Best Regards,
Jaehoon Chung
+}
#else /* CONFIG_OF */
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
@@ -1811,6 +1840,10 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
{
return NULL;
}
+static u32 dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ return -1;
+}
#endif /* CONFIG_OF */
static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
@@ -1923,6 +1956,8 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
else
clear_bit(DW_MMC_CARD_PRESENT, slot-flags);
+ slot-wp_gpio = dw_mci_of_get_wp_gpio(host-dev, slot-id);
+
mmc_add_host(mmc);
#if defined(CONFIG_DEBUG_FS)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] mmc: dw_mmc: exynos: Stop claiming wp-gpio
The exynos code claimed wp-gpio with devm_gpio_request() but never did
anything with it. That meant that anyone using a write protect GPIO
would effectively be write protected all the time.
A future change will move the wp-gpio support to the core dw_mmc.c
file. Now the exynos-specific code won't claim the GPIO but will
just set the DW_MCI_QUIRK_NO_WRITE_PROTECT quirk if write protect
won't be used.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Nothing new in this patch
drivers/mmc/host/dw_mmc-exynos.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 4d50da6..58cc03e 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -175,12 +175,12 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
}
}
- gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
- if (gpio_is_valid(gpio)) {
- if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
- dev_info(host-dev, gpio [%d] request failed\n,
- gpio);
- } else {
+ /*
+* If there are no write-protect GPIOs present then we assume no write
+* protect. The mci_readl() in dw_mmc.c won't work since it's not
+* hooked up on exynos.
+*/
+ if (!of_find_property(slot_np, wp-gpios, NULL)) {
dev_info(host-dev, wp gpio not available);
host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
}
--
1.7.7.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
[PATCH v2 2/2] mmc: dw_mmc: Handle wp-gpios from device tree
On some SoCs (like exynos5250) you need to use an external GPIO for
write protect. Add support for wp-gpios to the core dw_mmc driver
since it could be useful across multiple SoCs.
With this change I am able to make use of the write protect for the
external SD slot on exynos5250-snow.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Fixed return type from u32 to int
- Return -EINVAL instead of -1
drivers/mmc/host/dw_mmc.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 5b41348..42d4f19 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -34,6 +34,7 @@
#include linux/regulator/consumer.h
#include linux/workqueue.h
#include linux/of.h
+#include linux/of_gpio.h
#include dw_mmc.h
@@ -74,6 +75,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @wp_gpio: If gpio_is_valid() we'll use this to read write protect.
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +90,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int wp_gpio;
+
u32 ctype;
struct mmc_request *mrq;
@@ -832,6 +836,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
read_only = 0;
else if (brd-get_ro)
read_only = brd-get_ro(slot-id);
+ else if (gpio_is_valid(slot-wp_gpio))
+ read_only = gpio_get_value(slot-wp_gpio);
else
read_only =
mci_readl(slot-host, WRTPRT) (1 slot-id) ? 1 : 0;
@@ -1802,6 +1808,29 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev, u8
slot)
as 1\n);
return bus_wd;
}
+
+/* find the write protect gpio for a given slot; or -1 if none specified */
+static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int gpio;
+
+ if (!np)
+ return -EINVAL;
+
+ gpio = of_get_named_gpio(np, wp-gpios, 0);
+
+ /* Having a missing entry is valid; return silently */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+
+ if (devm_gpio_request(dev, gpio, dw-mci-wp)) {
+ dev_warn(dev, gpio [%d] request failed\n, gpio);
+ return -EINVAL;
+ }
+
+ return gpio;
+}
#else /* CONFIG_OF */
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
@@ -1811,6 +1840,10 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
{
return NULL;
}
+static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ return -EINVAL;
+}
#endif /* CONFIG_OF */
static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
@@ -1923,6 +1956,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
else
clear_bit(DW_MMC_CARD_PRESENT, slot-flags);
+ slot-wp_gpio = dw_mci_of_get_wp_gpio(host-dev, slot-id);
+
mmc_add_host(mmc);
#if defined(CONFIG_DEBUG_FS)
--
1.7.7.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
[PATCH 1/2] mmc: dw_mmc: exynos: Stop claiming wp-gpio
The exynos code claimed wp-gpio with devm_gpio_request() but never did
anything with it. That meant that anyone using a write protect GPIO
would effectively be write protected all the time.
A future change will move the wp-gpio support to the core dw_mmc.c
file. Now the exynos-specific code won't claim the GPIO but will
just set the DW_MCI_QUIRK_NO_WRITE_PROTECT quirk if write protect
won't be used.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mmc/host/dw_mmc-exynos.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 4d50da6..58cc03e 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -175,12 +175,12 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
}
}
- gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
- if (gpio_is_valid(gpio)) {
- if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
- dev_info(host-dev, gpio [%d] request failed\n,
- gpio);
- } else {
+ /*
+* If there are no write-protect GPIOs present then we assume no write
+* protect. The mci_readl() in dw_mmc.c won't work since it's not
+* hooked up on exynos.
+*/
+ if (!of_find_property(slot_np, wp-gpios, NULL)) {
dev_info(host-dev, wp gpio not available);
host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
}
--
1.7.7.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
[PATCH] ARM: EXYNOS: Avoid early use of of_machine_is_compatible()
The recent commit ARM: EXYNOS: add support for EXYNOS5440 SoC broke
support for exynos5250 because of_machine_is_compatible() was used too
early in the boot process. It also probably meant that the exynos5440
failed to use the proper iotable. Switch to use
of_flat_dt_is_compatible() in both of these cases.
The failure I was seeing in exynos5250 because of this was:
Division by zero in kernel.
[80015ed4] (unwind_backtrace+0x0/0xec) from [8045c7a4]
(dump_stack+0x20/0x24)
[8045c7a4] (dump_stack+0x20/0x24) from [80012990] (__div0+0x20/0x28)
[80012990] (__div0+0x20/0x28) from [8021ab04] (Ldiv0_64+0x8/0x18)
[8021ab04] (Ldiv0_64+0x8/0x18) from [80068560]
(__clocksource_updatefreq_scale+0x54/0x134)
[80068560] (__clocksource_updatefreq_scale+0x54/0x134) from [8006865c]
(__clocksource_register_scale+0x1c/0x54)
[8006865c] (__clocksource_register_scale+0x1c/0x54) from [80612a18]
(exynos_timer_init+0x100/0x1e8)
[80612a18] (exynos_timer_init+0x100/0x1e8) from [8060d184]
(time_init+0x28/0x38)
[8060d184] (time_init+0x28/0x38) from [8060a754]
(start_kernel+0x1e0/0x3c8)
[8060a754] (start_kernel+0x1e0/0x3c8) from [40008078] (0x40008078)
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/mach-exynos/common.c |5 -
arch/arm/mach-exynos/mach-exynos5-dt.c |4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 73b940f..b919f5f 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -18,6 +18,7 @@
#include linux/sched.h
#include linux/serial_core.h
#include linux/of.h
+#include linux/of_fdt.h
#include linux/of_irq.h
#include linux/export.h
#include linux/irqdomain.h
@@ -335,8 +336,10 @@ void __init exynos_init_late(void)
void __init exynos_init_io(struct map_desc *mach_desc, int size)
{
+ unsigned long root = of_get_flat_dt_root();
+
/* initialize the io descriptors we need for initialization */
- if (of_machine_is_compatible(samsung,exynos5440))
+ if (of_flat_dt_is_compatible(root, samsung,exynos5440))
iotable_init(exynos5440_iodesc, ARRAY_SIZE(exynos5440_iodesc));
else
iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 67fa3c2..7b76c3f 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -122,9 +122,11 @@ static const struct of_dev_auxdata
exynos5440_auxdata_lookup[] __initconst = {
static void __init exynos5_dt_map_io(void)
{
+ unsigned long root = of_get_flat_dt_root();
+
exynos_init_io(NULL, 0);
- if (of_machine_is_compatible(samsung,exynos5250))
+ if (of_flat_dt_is_compatible(root, samsung,exynos5250))
s3c24xx_init_clocks(2400);
}
--
1.7.7.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
Re: [PATCH] ARM: EXYNOS: Avoid early use of of_machine_is_compatible()
Olof / Kukjin,
On Tue, Nov 27, 2012 at 10:05 PM, Olof Johansson o...@lixom.net wrote:
On Wed, Nov 28, 2012 at 02:23:09PM +0900, Kukjin Kim wrote:
Olof Johansson wrote:
On Tue, Nov 27, 2012 at 2:27 PM, Kukjin Kim kgene@samsung.com wrote:
On 11/28/12 07:11, Olof Johansson wrote:
On Tue, Nov 27, 2012 at 11:53 AM, Doug Andersondiand...@chromium.org
wrote:
The recent commit ARM: EXYNOS: add support for EXYNOS5440 SoC broke
support for exynos5250 because of_machine_is_compatible() was used too
early in the boot process. It also probably meant that the exynos5440
failed to use the proper iotable. Switch to use
of_flat_dt_is_compatible() in both of these cases.
The failure I was seeing in exynos5250 because of this was:
Division by zero in kernel.
[80015ed4] (unwind_backtrace+0x0/0xec) from [8045c7a4]
(dump_stack+0x20/0x24)
[8045c7a4] (dump_stack+0x20/0x24) from [80012990]
(__div0+0x20/0x28)
[80012990] (__div0+0x20/0x28) from [8021ab04]
(Ldiv0_64+0x8/0x18)
[8021ab04] (Ldiv0_64+0x8/0x18) from [80068560]
(__clocksource_updatefreq_scale+0x54/0x134)
[80068560] (__clocksource_updatefreq_scale+0x54/0x134) from
[8006865c] (__clocksource_register_scale+0x1c/0x54)
[8006865c] (__clocksource_register_scale+0x1c/0x54) from
[80612a18] (exynos_timer_init+0x100/0x1e8)
[80612a18] (exynos_timer_init+0x100/0x1e8) from [8060d184]
(time_init+0x28/0x38)
[8060d184] (time_init+0x28/0x38) from [8060a754]
(start_kernel+0x1e0/0x3c8)
[8060a754] (start_kernel+0x1e0/0x3c8) from [40008078]
(0x40008078)
Signed-off-by: Doug Andersondiand...@chromium.org
Thanks Doug.
Kukjin, I'll apply this directly on top of the previous branch in
arm-soc, if that's OK with you.
Sure, go ahead with my ack if you want,
Acked-by: Kukjin Kim kgene@samsung.com
Note, actually there was a fix which uses soc_is_exynos5440() in my
local
:-) I'm not sure which one is better at this moment, but I'm OK on this.
Ok, applied. Thanks all.
Olof, just note, happens build error with exynos4_defconfig because of
non-DT.
Ick, thanks for catching that.
Sorry for this! I will try to be more diligent about trying
exynos4_defconfig before submitting future patches to these files.
Following can resolve it or we should create null function for
of_get_flat_dt_root() and of_flat_dt_is_compatible()...
8---
From: Kukjin Kim kgene@samsung.com
Subject: ARM: EXYNOS: fix a build error with non-DT for exynos4
This fixes following in case of non-DT:
arch/arm/mach-exynos/common.c: In function 'exynos_init_io':
arch/arm/mach-exynos/common.c:339: error: implicit declaration of function
'of_get_flat_dt_root'
arch/arm/mach-exynos/common.c:342: error: implicit declaration of function
'of_flat_dt_is_compatible'
make[1]: *** [arch/arm/mach-exynos/common.o] Error 1
Signed-off-by: Kukjin Kim kgene@samsung.com
---
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index b919f5f..2110091 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -336,12 +336,14 @@ void __init exynos_init_late(void)
void __init exynos_init_io(struct map_desc *mach_desc, int size)
{
+#ifdef CONFIG_OF
unsigned long root = of_get_flat_dt_root();
/* initialize the io descriptors we need for initialization */
if (of_flat_dt_is_compatible(root, samsung,exynos5440))
iotable_init(exynos5440_iodesc,
ARRAY_SIZE(exynos5440_iodesc));
else
+#endif
iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
I really don't like splitting an if/else with an ifdef like this, it's fragile
code and can be hard to follow.
Agree.
There's also a second build error with exynos_defconfig in the
exynos5-dt.c board file due to a missing include. Teaches me to just apply
patches without trying to build. :(
In the tree I was testing against (the arm-soc/for-next branch at
659b19ca3a77e2ac32fe84d95242653c75dd07c7) I see the include file in
the exynos5-dt.c file already. In my tree it was added by 2eae613b:
ARM: EXYNOS: Add MFC device tree support.
Your patch applies cleanly on mine but I end up with:
#include linux/of_platform.h
#include linux/of_fdt.h
#include linux/serial_core.h
#include linux/io.h
#include linux/memblock.h
#include linux/of_fdt.h
I'll squash this into Doug's original patch, if that's OK?
No objection to squashing a fix and your CL is better than what I
have, but see below for an issue.
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 796e0c9..77e7c5b 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -122,6 +122,7 @@ static struct map_desc exynos_iodesc[] __initdata = {
},
};
+#ifdef CONFIG_ARCH_EXYNOS5
Are you sure you want this #ifdef? If so it should
Re: [PATCH v2 1/2] mmc: dw_mmc: exynos: Stop claiming wp-gpio
Seungwon,
Thanks for the review. See below for comments. If you'd like me to
respin then please let me know. Otherwise I look forward to your ack.
On Wed, Nov 28, 2012 at 1:29 AM, Seungwon Jeon tgih@samsung.com wrote:
Yes. pin of write protection is common property.
This change is good. I have some suggestion below.
Could you check it?
On Friday, November 23, 2012, Doug Anderson wrote:
The exynos code claimed wp-gpio with devm_gpio_request() but never did
anything with it. That meant that anyone using a write protect GPIO
would effectively be write protected all the time.
A future change will move the wp-gpio support to the core dw_mmc.c
file. Now the exynos-specific code won't claim the GPIO but will
just set the DW_MCI_QUIRK_NO_WRITE_PROTECT quirk if write protect
won't be used.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Nothing new in this patch
drivers/mmc/host/dw_mmc-exynos.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c
b/drivers/mmc/host/dw_mmc-exynos.c
index 4d50da6..58cc03e 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -175,12 +175,12 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
}
}
- gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
- if (gpio_is_valid(gpio)) {
- if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
- dev_info(host-dev, gpio [%d] request failed\n,
- gpio);
- } else {
+ /*
+ * If there are no write-protect GPIOs present then we assume no write
+ * protect. The mci_readl() in dw_mmc.c won't work since it's not
+ * hooked up on exynos.
+ */
+ if (!of_find_property(slot_np, wp-gpios, NULL)) {
dev_info(host-dev, wp gpio not available);
host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
}
All card types need this quirk in case wp-gpio property is empty?
I think wp-pin is valid for SD card, not eMMC/SDIO.
Right. It is only checked right now by the SD code (mmc/core/sd.c).
It doesn't particularly hurt to set it the quirk in other cases though
and it seems nice not to add special cases. I could imagine someone
extending the MMC code at some point to support write protect (via
GPIO) for eMMC, so there's even a slight justification for avoiding
the special case.
Of course, I know origin code did it.
How about removing whole checking routine?
Instead, new definition for this quirk can be added into
'dw_mci_of_quirks'(dw_mmc.c) and dts file.
On _exynos_ all SD cards need this quirk if there is no wp-gpio
property. However this is not generally true for all users of dw_mmc.
The DesignWare IP Block actually has a write protect input that can
be read with mci_readl(slot-host, WRTPRT) but on exynos the
DesignWare write protect line isn't exposed on any physical pins.
That means that the only possible way to do write protect on exynos is
using a GPIO.
The above means that on exynos if the GPIO isn't defined we will
assume no write protect. On other platforms if the GPIO isn't defined
we'll assume that the mci_readl will work and we'll use that.
If people would prefer it I can code up an alternate solution that
doesn't touch any exynos code but that would introduce a new device
tree binding. We could accomplish what's needed for exynos using a
property like broken-internal-wp.
Please let me know if you'd like me to submit a new patch with this
solution or if you like the existing solution.
Thanks,
Seungwon Jeon
--
1.7.7.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
[PATCH v3 3/4] mmc: dw_mmc: exynos: Remove code for wp-gpios
The exynos code claimed the write protect with devm_gpio_request() but
never did anything with it. That meant that anyone using a write
protect GPIO would effectively be write protected all the time.
The handling for wp-gpios belongs in the main dw_mmc driver and has
been moved there.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- Totally removed wp-gpios handling from exynos code.
Changes in v2: None
drivers/mmc/host/dw_mmc-exynos.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 4d50da6..72fd0f2 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -175,16 +175,6 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
}
}
- gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
- if (gpio_is_valid(gpio)) {
- if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
- dev_info(host-dev, gpio [%d] request failed\n,
- gpio);
- } else {
- dev_info(host-dev, wp gpio not available);
- host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
- }
-
if (host-pdata-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
return 0;
--
1.7.7.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
[PATCH v3 4/4] mmc: dw_mmc: Handle wp-gpios from device tree
On some SoCs (like exynos5250) you need to use an external GPIO for
write protect. Add support for wp-gpios to the core dw_mmc driver
since it could be useful across multiple SoCs.
With this change I am able to make use of the write protect for the
external SD slot on exynos5250-snow.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3: None
Changes in v2:
- Fixed return type from u32 to int
- Return -EINVAL instead of -1
drivers/mmc/host/dw_mmc.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b47b1e9..8f8bac5 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -34,6 +34,7 @@
#include linux/regulator/consumer.h
#include linux/workqueue.h
#include linux/of.h
+#include linux/of_gpio.h
#include dw_mmc.h
@@ -75,6 +76,7 @@ struct idmac_desc {
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
* @quirks: Slot-level quirks (DW_MCI_SLOT_QUIRK_XXX)
+ * @wp_gpio: If gpio_is_valid() we'll use this to read write protect.
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -90,6 +92,7 @@ struct dw_mci_slot {
struct dw_mci *host;
int quirks;
+ int wp_gpio;
u32 ctype;
@@ -836,6 +839,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
read_only = 0;
else if (brd-get_ro)
read_only = brd-get_ro(slot-id);
+ else if (gpio_is_valid(slot-wp_gpio))
+ read_only = gpio_get_value(slot-wp_gpio);
else
read_only =
mci_readl(slot-host, WRTPRT) (1 slot-id) ? 1 : 0;
@@ -1830,6 +1835,29 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev, u8
slot)
as 1\n);
return bus_wd;
}
+
+/* find the write protect gpio for a given slot; or -1 if none specified */
+static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int gpio;
+
+ if (!np)
+ return -EINVAL;
+
+ gpio = of_get_named_gpio(np, wp-gpios, 0);
+
+ /* Having a missing entry is valid; return silently */
+ if (!gpio_is_valid(gpio))
+ return -EINVAL;
+
+ if (devm_gpio_request(dev, gpio, dw-mci-wp)) {
+ dev_warn(dev, gpio [%d] request failed\n, gpio);
+ return -EINVAL;
+ }
+
+ return gpio;
+}
#else /* CONFIG_OF */
static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
{
@@ -1843,6 +1871,10 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
{
return NULL;
}
+static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
+{
+ return -EINVAL;
+}
#endif /* CONFIG_OF */
static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
@@ -1960,6 +1992,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
else
clear_bit(DW_MMC_CARD_PRESENT, slot-flags);
+ slot-wp_gpio = dw_mci_of_get_wp_gpio(host-dev, slot-id);
+
mmc_add_host(mmc);
#if defined(CONFIG_DEBUG_FS)
--
1.7.7.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
Re: [PATCH v2 1/2] mmc: dw_mmc: exynos: Stop claiming wp-gpio
Seungwon,
On Wed, Nov 28, 2012 at 11:46 PM, Seungwon Jeon tgih@samsung.com wrote:
Hi Doug,
On Thursday, November 29, 2012, Doug Anderson wrote:
Seungwon,
Thanks for the review. See below for comments. If you'd like me to
respin then please let me know. Otherwise I look forward to your ack.
On Wed, Nov 28, 2012 at 1:29 AM, Seungwon Jeon tgih@samsung.com wrote:
Yes. pin of write protection is common property.
This change is good. I have some suggestion below.
Could you check it?
On Friday, November 23, 2012, Doug Anderson wrote:
The exynos code claimed wp-gpio with devm_gpio_request() but never did
anything with it. That meant that anyone using a write protect GPIO
would effectively be write protected all the time.
A future change will move the wp-gpio support to the core dw_mmc.c
file. Now the exynos-specific code won't claim the GPIO but will
just set the DW_MCI_QUIRK_NO_WRITE_PROTECT quirk if write protect
won't be used.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Nothing new in this patch
drivers/mmc/host/dw_mmc-exynos.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c
b/drivers/mmc/host/dw_mmc-exynos.c
index 4d50da6..58cc03e 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -175,12 +175,12 @@ static int dw_mci_exynos_setup_bus(struct dw_mci
*host,
}
}
- gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
- if (gpio_is_valid(gpio)) {
- if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
- dev_info(host-dev, gpio [%d] request failed\n,
- gpio);
- } else {
+ /*
+ * If there are no write-protect GPIOs present then we assume no
write
+ * protect. The mci_readl() in dw_mmc.c won't work since it's not
+ * hooked up on exynos.
+ */
+ if (!of_find_property(slot_np, wp-gpios, NULL)) {
dev_info(host-dev, wp gpio not available);
host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
}
All card types need this quirk in case wp-gpio property is empty?
I think wp-pin is valid for SD card, not eMMC/SDIO.
Right. It is only checked right now by the SD code (mmc/core/sd.c).
It doesn't particularly hurt to set it the quirk in other cases though
and it seems nice not to add special cases. I could imagine someone
extending the MMC code at some point to support write protect (via
GPIO) for eMMC, so there's even a slight justification for avoiding
the special case.
Of course, I know origin code did it.
How about removing whole checking routine?
Instead, new definition for this quirk can be added into
'dw_mci_of_quirks'(dw_mmc.c) and dts file.
On _exynos_ all SD cards need this quirk if there is no wp-gpio
property. However this is not generally true for all users of dw_mmc.
The DesignWare IP Block actually has a write protect input that can
be read with mci_readl(slot-host, WRTPRT) but on exynos the
DesignWare write protect line isn't exposed on any physical pins.
That means that the only possible way to do write protect on exynos is
using a GPIO.
The above means that on exynos if the GPIO isn't defined we will
assume no write protect. On other platforms if the GPIO isn't defined
we'll assume that the mci_readl will work and we'll use that.
If people would prefer it I can code up an alternate solution that
doesn't touch any exynos code but that would introduce a new device
tree binding. We could accomplish what's needed for exynos using a
property like broken-internal-wp.
Please let me know if you'd like me to submit a new patch with this
solution or if you like the existing solution.
Write protect is additional interface related with SD socket.
WP switch appears in SD standard size card.
In case EMMC/SDIO spec, there is no mentions about this WP pin.
As you mentioned above, that's why 'ger_ro' is called only in sd
path(mmc/core/sd.c).
So, I meant that we don't need to consider WP pin status about non-SD type.
Ah, I understand now. This is a good point. I have updated the
documentation in the latest patch to mention this. Thanks!
Such as exynos5250, there is no exposed interface from host controller for
write protection pin.
In that case, if general gpio pin is connected like your board environment,
we can define wp-gpio.
Otherwise, 'broken-internal-wp' property will be good solution.
Latest patch (just about to send out) adds a per-slot disable-wp
property for dw_mmc. See the patch for why I've chosen to do it that
way. Hopefully it looks OK to you.
Please feel free to modify.
If you will do, I'll be happy.
Thanks,
Seungwon Jeon
--
1.7.7.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body
[PATCH v3 1/4] mmc: dw_mmc: Add disable-wp device tree property
The disable-wp property is used to specify that a given SD card slot
doesn't have a concept of write protect. This eliminates the need for
special case code for SD slots that should never be write protected
(like a micro SD slot or a dev board).
The dw_mmc driver is special in needing to specify disable-wp
because the lack of a wp-gpios property means to use the special
purpose write protect line. On some other mmc devices the lack of
wp-gpios means that write protect should be disabled.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- New for this version of the patch series. Chose disable-wp rather
than the discussed broken-internal-wp since it mapped more cleanly
to an existing quirk (and the only reason to specify that the
internal wp is broken is if you're disabling the write protect
anyway).
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt | 12 +-
drivers/mmc/host/dw_mmc.c | 36 +++-
include/linux/mmc/dw_mmc.h |4 ++
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 06cd32d08..726fd21 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -26,8 +26,16 @@ Required Properties:
* bus-width: as documented in mmc core bindings.
* wp-gpios: specifies the write protect gpio line. The format of the
- gpio specifier depends on the gpio controller. If the write-protect
- line is not available, this property is optional.
+ gpio specifier depends on the gpio controller. If a GPIO is not used
+ for write-protect, this property is optional.
+
+ * disable-wp: If the wp-gpios property isn't present then (by default)
+ we'd assume that the write protect is hooked up directly to the
+ controller's special purpose write protect line (accessible via
+ the WRTPRT register). However, it's possible that we simply don't
+ want write protect. In that case specify 'disable-wp'.
+ NOTE: This property is not required for slots known to always
+ connect to eMMC or SDIO cards.
Optional properties:
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 7342029..b47b1e9 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -74,6 +74,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @quirks: Slot-level quirks (DW_MCI_SLOT_QUIRK_XXX)
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +89,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int quirks;
+
u32 ctype;
struct mmc_request *mrq;
@@ -828,7 +831,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
struct dw_mci_board *brd = slot-host-pdata;
/* Use platform get_ro function, else try on board write protect */
- if (brd-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT)
+ if ((brd-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) ||
+ (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (brd-get_ro)
read_only = brd-get_ro(slot-id);
@@ -1788,6 +1792,30 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
return NULL;
}
+static struct dw_mci_of_slot_quirks {
+ char *quirk;
+ int id;
+} of_slot_quirks[] = {
+ {
+ .quirk = disable-wp,
+ .id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+ },
+};
+
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int quirks = 0;
+ int idx;
+
+ /* get quirks */
+ for (idx = 0; idx ARRAY_SIZE(of_slot_quirks); idx++)
+ if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+ quirks |= of_slot_quirks[idx].id;
+
+ return quirks;
+}
+
/* find out bus-width for a given slot */
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
@@ -1803,6 +1831,10 @@ static u32 dw_mci_of_get_bus_wd(struct device *dev, u8
slot)
return bus_wd;
}
#else /* CONFIG_OF */
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ return 0;
+}
static u32 dw_mci_of_get_bus_wd(struct device *dev, u8 slot)
{
return 1;
@@ -1831,6 +1863,8 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned
int id)
slot-host = host;
host-slot[id] = slot;
+ slot
[PATCH v3 2/4] ARM: dts: Add disable-wp for sd card slot on smdk5250
The next change will remove the code from the dw_mmc-exynos that added the DW_MCI_QUIRK_NO_WRITE_PROTECT. Keep existing functionality of having no write protect pin on smdk5250 by adding the disable-wp property. Signed-off-by: Doug Anderson diand...@chromium.org --- Changes in v3: - New for this version of the patch series. arch/arm/boot/dts/exynos5250-smdk5250.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts index f30ca18..5538b13 100644 --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts @@ -146,6 +146,7 @@ reg = 0; bus-width = 4; samsung,cd-pinmux-gpio = gpc3 2 2 3 3; + disable-wp; gpios = gpc3 0 2 0 3, gpc3 1 2 0 3, gpc3 3 2 3 3, gpc3 4 2 3 3, gpc3 5 2 3 3, gpc3 6 2 3 3, -- 1.7.7.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
Re: [PATCH v2] ARM: DTS: CROS5250: Add max77686 device tree support
= 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ };
+
+ buck1_reg: BUCK1 {
+ regulator-name = vdd_mif;
+ regulator-min-microvolt = 95;
+ regulator-max-microvolt = 130;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = vdd_arm;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 135;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck3_reg: BUCK3 {
+ regulator-name = vdd_int;
+ regulator-min-microvolt = 90;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck4_reg: BUCK4 {
+ regulator-name = vdd_g3d;
+ regulator-min-microvolt = 85;
+ regulator-max-microvolt = 130;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck5_reg: BUCK5 {
+ regulator-name = P1.8V_BUCK_OUT5;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ buck6_reg: BUCK6 {
+ regulator-name = P1.35V_BUCK_OUT6;
+ regulator-min-microvolt = 135;
+ regulator-max-microvolt = 135;
+ regulator-always-on;
+ };
+
+ buck7_reg: BUCK7 {
+ regulator-name = P2.0V_BUCK_OUT7;
+ regulator-min-microvolt = 200;
+ regulator-max-microvolt = 200;
+ regulator-always-on;
+ };
+
+ buck8_reg: BUCK8 {
+ regulator-name = P2.85V_BUCK_OUT8;
+ regulator-min-microvolt = 285;
+ regulator-max-microvolt = 285;
+ regulator-always-on;
+ };
+ };
+ };
};
i2c@12C7 {
--
1.6.6.1
...would love to see LDO7 name fixed up, but otherwise looks good to
me. Thanks!
Acked-by: Doug Anderson diand...@chromium.org
--
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 1/4] ARM: EXYNOS: Update move usb-phy types to generic include layer
Vivek,
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
Updating the names of usb-phy types to more generic names:
USB_PHY_TYPE_DEIVCE USB_PHY_TYPE_HOST; and further update
its dependencies.
Since you're changing the name, I would have expected to see a removal
of the old enum type in this patch. I don't see it. After applying
all of your patches I find that S5P_USB_PHY_HOST and
S5P_USB_PHY_DEVICE are still defined and used.
$ git grep S5P_USB_PHY_HOST
arch/arm/mach-exynos/setup-usb-phy.c: else if (type == S5P_USB_PHY_HOST)
arch/arm/mach-exynos/setup-usb-phy.c: else if (type == S5P_USB_PHY_HOST)
arch/arm/plat-samsung/include/plat/usb-phy.h: S5P_USB_PHY_HOST,
I believe that those usages of the old enum should also be switched
over and the old enum removed.
Signed-off-by: Praveen Paneri p.pan...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/host/ehci-s5p.c |9 +
drivers/usb/host/ohci-exynos.c |9 +
include/linux/usb/samsung_usb_phy.h | 16
3 files changed, 26 insertions(+), 8 deletions(-)
create mode 100644 include/linux/usb/samsung_usb_phy.h
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 319dcfa..46ca5ef 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -17,6 +17,7 @@
#include linux/platform_device.h
#include linux/of_gpio.h
#include linux/platform_data/usb-ehci-s5p.h
+#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
#define EHCI_INSNREG00(base) (base + 0x90)
@@ -164,7 +165,7 @@ static int s5p_ehci_probe(struct platform_device *pdev)
}
if (pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ehci = hcd_to_ehci(hcd);
ehci-caps = hcd-regs;
@@ -198,7 +199,7 @@ static int s5p_ehci_remove(struct platform_device *pdev)
usb_remove_hcd(hcd);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(s5p_ehci-clk);
@@ -229,7 +230,7 @@ static int s5p_ehci_suspend(struct device *dev)
rc = ehci_suspend(hcd, do_wakeup);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(s5p_ehci-clk);
@@ -246,7 +247,7 @@ static int s5p_ehci_resume(struct device *dev)
clk_prepare_enable(s5p_ehci-clk);
if (pdata pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
/* DMA burst Enable */
writel(EHCI_INSNREG00_ENABLE_DMA_BURST, EHCI_INSNREG00(hcd-regs));
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index aa3b884..804fb62 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -15,6 +15,7 @@
#include linux/of.h
#include linux/platform_device.h
#include linux/platform_data/usb-exynos.h
+#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
struct exynos_ohci_hcd {
@@ -153,7 +154,7 @@ static int exynos_ohci_probe(struct platform_device *pdev)
}
if (pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ohci = hcd_to_ohci(hcd);
ohci_hcd_init(ohci);
@@ -184,7 +185,7 @@ static int exynos_ohci_remove(struct platform_device
*pdev)
usb_remove_hcd(hcd);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(exynos_ohci-clk);
@@ -229,7 +230,7 @@ static int exynos_ohci_suspend(struct device *dev)
clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
if (pdata pdata-phy_exit)
- pdata-phy_exit(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
clk_disable_unprepare(exynos_ohci-clk);
@@ -249,7 +250,7 @@ static int exynos_ohci_resume(struct device *dev)
clk_prepare_enable(exynos_ohci-clk);
if (pdata pdata-phy_init)
- pdata-phy_init(pdev, S5P_USB_PHY_HOST);
+ pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
ohci_resume(hcd, false);
diff --git a/include/linux/usb/samsung_usb_phy.h
b/include/linux/usb/samsung_usb_phy.h
new file mode 100644
index 000..9167826
--- /dev/null
+++ b/include/linux/usb/samsung_usb_phy.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics Co.Ltd
+ * http://www.samsung.com/
+ *
+ * Defines phy types for samsung usb phy controllers - HOST or DEIVCE.
+ *
+ * This program is free
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Vivek, I don't really have a good 1 foot view about how all of the USB bits fit together, but a few detail-oriented comments below. On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote: This patch adds host phy support to samsung-usbphy.c and further adds support for samsung's exynos5250 usb-phy. Signed-off-by: Praveen Paneri p.pan...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- .../devicetree/bindings/usb/samsung-usbphy.txt | 25 +- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 465 ++-- include/linux/usb/samsung_usb_phy.h| 13 + 4 files changed, 454 insertions(+), 51 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt index a7b28b2..2ec5400 100644 --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -1,23 +1,38 @@ * Samsung's usb phy transceiver -The Samsung's phy transceiver is used for controlling usb otg phy for -s3c-hsotg usb device controller. +The Samsung's phy transceiver is used for controlling usb phy for +s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers +across Samsung SOCs. TODO: Adding the PHY binding with controller(s) according to the under developement generic PHY driver. Required properties: + +Exynos4210: - compatible : should be samsung,exynos4210-usbphy - reg : base physical address of the phy registers and length of memory mapped region. +Exynos5250: +- compatible : should be samsung,exynos5250-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. + Optional properties: - samsung,usb-phyhandle : should point to usb-phyhandle sub-node which provides binding data to enable/disable device PHY handled by - PMU register. + PMU register; or to configure usb2.0 phy handled by + SYSREG. Required properties: - compatible : should be samsung,usbdev-phyctrl for - DEVICE type phy. + DEVICE type phy; or + should be samsung,usbhost-phyctrl for + HOST type phy; or + should be samsung,usb-phycfg for + USB2.0 PHY_CFG. - samsung,phyhandle-reg: base physical address of - PHY_CONTROL register in PMU. +PHY_CONTROL register in PMU; +or USB2.0 PHY_CFG register +in SYSREG. - samsung,enable-mask : should be '1' diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 17ad743..13c0eaf 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -47,7 +47,7 @@ config USB_RCAR_PHY config SAMSUNG_USBPHY bool Samsung USB PHY controller Driver - depends on USB_S3C_HSOTG + depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS select USB_OTG_UTILS help Enable this to support Samsung USB phy controller for samsung diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c index 4ceabe3..621348a 100644 --- a/drivers/usb/phy/samsung-usbphy.c +++ b/drivers/usb/phy/samsung-usbphy.c @@ -5,7 +5,8 @@ * * Author: Praveen Paneri p.pan...@samsung.com * - * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * Samsung USB-PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and + * OHCI-EXYNOS controllers. * * 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 @@ -24,7 +25,7 @@ #include linux/err.h #include linux/io.h #include linux/of.h -#include linux/usb/otg.h +#include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h /* Register definitions */ @@ -56,6 +57,103 @@ #define RSTCON_HLINK_SWRST (0x1 1) #define RSTCON_SWRST (0x1 0) +/* EXYNOS5 */ +#define EXYNOS5_PHY_HOST_CTRL0 (0x00) + +#define HOST_CTRL0_PHYSWRSTALL (0x1 31) + +#define HOST_CTRL0_REFCLKSEL_MASK (0x3) +#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19) +#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 19) +#define HOST_CTRL0_REFCLKSEL_CLKCORE (0x2 19) + +#define HOST_CTRL0_FSEL_MASK (0x7 16)
Re: [PATCH v5 3/4] USB: ehci-s5p: Add phy driver support
Vivek,
Again, not a high-level review, but...
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
Adding the phy driver to ehci-s5p. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/ehci-s5p.c | 70
++-
1 files changed, 49 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
index 46ca5ef..50c93af 100644
--- a/drivers/usb/host/ehci-s5p.c
+++ b/drivers/usb/host/ehci-s5p.c
@@ -17,6 +17,7 @@
#include linux/platform_device.h
#include linux/of_gpio.h
#include linux/platform_data/usb-ehci-s5p.h
+#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include plat/usb-phy.h
@@ -33,6 +34,8 @@ struct s5p_ehci_hcd {
struct device *dev;
struct usb_hcd *hcd;
struct clk *clk;
+ struct usb_phy *phy;
+ struct s5p_ehci_platdata *pdata;
};
static const struct hc_driver s5p_ehci_hc_driver = {
@@ -66,6 +69,30 @@ static const struct hc_driver s5p_ehci_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static void s5p_ehci_phy_enable(struct s5p_ehci_hcd *s5p_ehci)
+{
+ struct platform_device *pdev = to_platform_device(s5p_ehci-dev);
+
+ if (s5p_ehci-phy) {
+ samsung_usbphy_set_type(s5p_ehci-phy, USB_PHY_TYPE_HOST);
This confuses me. Why are you setting the type to host here?
+ usb_phy_init(s5p_ehci-phy);
+ } else if (s5p_ehci-pdata-phy_init) {
+ s5p_ehci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
+ }
+}
+
+static void s5p_ehci_phy_disable(struct s5p_ehci_hcd *s5p_ehci)
+{
+ struct platform_device *pdev = to_platform_device(s5p_ehci-dev);
+
+ if (s5p_ehci-phy) {
+ samsung_usbphy_set_type(s5p_ehci-phy, USB_PHY_TYPE_HOST);
...and why set it to host here?
+ usb_phy_shutdown(s5p_ehci-phy);
+ } else if (s5p_ehci-pdata-phy_exit) {
+ s5p_ehci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
+ }
+}
+
static void s5p_setup_vbus_gpio(struct platform_device *pdev)
{
int err;
@@ -88,20 +115,15 @@ static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
static int s5p_ehci_probe(struct platform_device *pdev)
{
- struct s5p_ehci_platdata *pdata;
+ struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci;
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
+ struct usb_phy *phy;
int irq;
int err;
- pdata = pdev-dev.platform_data;
- if (!pdata) {
- dev_err(pdev-dev, No platform data defined\n);
- return -EINVAL;
- }
-
/*
* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
@@ -119,6 +141,19 @@ static int s5p_ehci_probe(struct platform_device *pdev)
if (!s5p_ehci)
return -ENOMEM;
+ phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR_OR_NULL(phy)) {
+ /* Fallback to pdata */
+ if (!pdata) {
+ dev_err(pdev-dev, no platform data or transceiver
defined\n);
+ return -EPROBE_DEFER;
Shouldn't you return -EINVAL like the old code did?
+ } else {
+ s5p_ehci-pdata = pdata;
+ }
+ } else {
+ s5p_ehci-phy = phy;
+ }
+
s5p_ehci-dev = pdev-dev;
hcd = usb_create_hcd(s5p_ehci_hc_driver, pdev-dev,
@@ -164,8 +199,7 @@ static int s5p_ehci_probe(struct platform_device *pdev)
goto fail_io;
}
- if (pdata-phy_init)
- pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
+ s5p_ehci_phy_enable(s5p_ehci);
ehci = hcd_to_ehci(hcd);
ehci-caps = hcd-regs;
@@ -176,13 +210,15 @@ static int s5p_ehci_probe(struct platform_device *pdev)
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
dev_err(pdev-dev, Failed to add USB HCD\n);
- goto fail_io;
+ goto fail_add_hcd;
}
platform_set_drvdata(pdev, s5p_ehci);
return 0;
+fail_add_hcd:
+ s5p_ehci_phy_disable(s5p_ehci);
fail_io:
clk_disable_unprepare(s5p_ehci-clk);
fail_clk:
@@ -192,14 +228,12 @@ fail_clk:
static int s5p_ehci_remove(struct platform_device *pdev)
{
- struct s5p_ehci_platdata *pdata = pdev-dev.platform_data;
struct s5p_ehci_hcd *s5p_ehci = platform_get_drvdata(pdev);
struct usb_hcd *hcd = s5p_ehci-hcd;
usb_remove_hcd(hcd);
- if (pdata
Re: [PATCH v3 1/4] mmc: dw_mmc: Add disable-wp device tree property
Chris, On Fri, Nov 30, 2012 at 3:57 AM, Seungwon Jeon tgih@samsung.com wrote: Doug, Thanks to work. Looks good to me with other patches. Acked-by: Seungwon Jeon tgih@samsung.com Does this series look reasonable to you? I can check back later when things are less hectic, but I wanted to make sure this wasn't forgotten. Thanks much! :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/4] ARM: EXYNOS: Update move usb-phy types to generic include layer
Vivek, On Wed, Dec 19, 2012 at 9:51 PM, Vivek Gautam gautamvivek1...@gmail.com wrote: Hi Doug, On Thu, Dec 20, 2012 at 3:18 AM, Doug Anderson diand...@chromium.org wrote: Vivek, Since you're changing the name, I would have expected to see a removal of the old enum type in this patch. I don't see it. After applying all of your patches I find that S5P_USB_PHY_HOST and S5P_USB_PHY_DEVICE are still defined and used. True that we should have removed the earlier defined enums, infact i did the same in patchset v4 for this series. But since in this patchset i separated out drivers and architecture part, i thought it would be easier to remove them in one shot in a latter commit which will actually touch upon all architecture related code (mach-exynos/setup-usb-phy.c, mach-s5pv210/setup-usb-phy.c, and include/plat/usb-phy.h) once this approach is accepted. $ git grep S5P_USB_PHY_HOST arch/arm/mach-exynos/setup-usb-phy.c: else if (type == S5P_USB_PHY_HOST) arch/arm/mach-exynos/setup-usb-phy.c: else if (type == S5P_USB_PHY_HOST) arch/arm/plat-samsung/include/plat/usb-phy.h: S5P_USB_PHY_HOST, I believe that those usages of the old enum should also be switched over and the old enum removed. Sure, those enums need to be removed. If you say i will submit a patch for the same. It would be nice to add it to the patch series in the next version. Thanks! -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/4] USB: ehci-s5p: Add phy driver support
On Wed, Dec 19, 2012 at 10:37 PM, Vivek Gautam
gautamvivek1...@gmail.com wrote:
On Thu, Dec 20, 2012 at 5:00 AM, Doug Anderson diand...@chromium.org wrote:
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam gautam.vi...@samsung.com
wrote:
+static void s5p_ehci_phy_enable(struct s5p_ehci_hcd *s5p_ehci)
+{
+ struct platform_device *pdev = to_platform_device(s5p_ehci-dev);
+
+ if (s5p_ehci-phy) {
+ samsung_usbphy_set_type(s5p_ehci-phy, USB_PHY_TYPE_HOST);
This confuses me. Why are you setting the type to host here?
Being in host controller, before calling usb_phy_init() we set type to
Host since, with certain SOCs
like 4210, same register has different bit settings for HOST type and
device type. So setting this
to Host type here make the flow of usb_phy_init to go in the direction of
Host.
OK. I think I need to study the code more...
+ phy = devm_usb_get_phy(pdev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR_OR_NULL(phy)) {
+ /* Fallback to pdata */
+ if (!pdata) {
+ dev_err(pdev-dev, no platform data or
transceiver defined\n);
+ return -EPROBE_DEFER;
Shouldn't you return -EINVAL like the old code did?
We are deferring the probe since the usb-phy transceiver may get
probed after ehci/ohci controllers.
And if we return -EINVAL like the previous code, we would end up not
setting the phy.
OK. Something is wrong here then, since this really isn't an error:
* It should be commented about why you're deferring.
* You shouldn't have a dev_err for something that's not fatal.
Ideally we'd want something that would force probing to happen in the
right order. I spent a little time looking and didn't see anything,
but maybe I'm missing something obvious. If nothing pops out, the
defer seems OK as long as it is commented well.
--
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] usb: phy: samsung: Add support to set pmu isolation
Vivek,
Nothing really serious below and things look good to me, but figured
I'd put a few nits in (sorry!).
On Fri, Dec 21, 2012 at 12:16 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 7b26e2d..09f06f8 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -9,3 +9,31 @@ Required properties:
- compatible : should be samsung,exynos4210-usbphy
- reg : base physical address of the phy registers and length of memory
mapped
region.
+- #address-cells: should be 1.
+- #size-cells: should be 0.
Doesn't match your example. Probably should be 1.
diff --git a/drivers/usb/phy/samsung-usbphy.c
b/drivers/usb/phy/samsung-usbphy.c
index 5c5e1bb5..2260029 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
/*
+ * struct samsung_usbphy_drvdata - driver data for various SoC variants
+ * @cpu_type: machine identifier
+ * @devphy_en_mask: device phy enable mask for PHY CONTROL register
+ * @hostphy_en_mask: host phy enable mask for PHY CONTROL register
+ *
+ * having different mask for host and device type phy
+ * helps in setting independent masks in case of SoCs like
+ * S5PV210 in which PHY0 and PHY1 enable bits belong to same
+ * register placed at [0] and [1] respectively.
+ * Although for newer SoCs like exynos these bits belong to
+ * different registers altogether placed at [0].
+ */
+struct samsung_usbphy_drvdata {
+ int cpu_type;
+ int devphy_en_mask;
This is really a devphy_dis_mask, isn't it? AKA: setting to 1
disables the phy and setting to 0 enables the phy.
+ int hostphy_en_mask;
Code below always uses devphy and only ever inits devphy. I assume
future code will init / use hostphy? Worth moving the hostphy part in
that patch?
struct samsung_usbphy {
struct usb_phy phy;
@@ -81,12 +104,66 @@ struct samsung_usbphy {
struct device *dev;
struct clk *clk;
void __iomem*regs;
+ void __iomem*phyctrl_pmureg;
int ref_clk_freq;
- int cpu_type;
+ struct samsung_usbphy_drvdata *drv_data;
nit: const
+static int samsung_usbphy_parse_dt_param(struct samsung_usbphy *sphy)
+{
+ struct device_node *usbphy_pmu;
+ u32 reg[2];
+ int ret;
+
+ if (!sphy-dev-of_node) {
+ dev_err(sphy-dev, Can't get usb-phy node\n);
+ return -ENODEV;
+ }
+
+ usbphy_pmu = of_get_child_by_name(sphy-dev-of_node, usbphy-pmu);
+ if (!usbphy_pmu)
+ dev_warn(sphy-dev, Can't get usb-phy pmu control node\n);
+
+ ret = of_property_read_u32_array(usbphy_pmu, reg, reg, 2);
nit: use ARRAY_SIZE(reg)
+ if (!ret)
+ sphy-phyctrl_pmureg = ioremap(reg[0], reg[1]);
+
+ of_node_put(usbphy_pmu);
+
+ if (IS_ERR_OR_NULL(sphy-phyctrl_pmureg)) {
+ dev_err(sphy-dev, Can't get usb-phy pmu control
register\n);
I don't think there's any cases where it matters (you'll error out of
the driver if you return an error here), but seems like it might be
nice to set sphy-phyctrl_pmureg to NULL here since other places test
this member against NULL only.
+static inline struct samsung_usbphy_drvdata
+*samsung_usbphy_get_driver_data(struct platform_device *pdev)
{
if (pdev-dev.of_node) {
const struct of_device_id *match;
match = of_match_node(samsung_usbphy_dt_match,
pdev-dev.of_node);
- return (int) match-data;
+ return (struct samsung_usbphy_drvdata *) match-data;
nit: no need for a cast here, I believe.
}
- return platform_get_device_id(pdev)-driver_data;
+ return ((struct samsung_usbphy_drvdata *)
+ platform_get_device_id(pdev)-driver_data);
nit: no need for a cast here, I believe.
+static struct samsung_usbphy_drvdata usbphy_s3c64xx = {
+ .cpu_type = TYPE_S3C64XX,
+ .devphy_en_mask = S3C64XX_USBPHY_ENABLE,
+};
+
+static struct samsung_usbphy_drvdata usbphy_exynos4 = {
+ .cpu_type = TYPE_EXYNOS4210,
+ .devphy_en_mask = EXYNOS_USBPHY_ENABLE,
+};
+
nit: static const for these structs?
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] usb: exynos: Fix compatible strings used for device
On Fri, Dec 21, 2012 at 12:14 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Wed, Dec 19, 2012 at 7:16 PM, Vivek Gautam gautamvivek1...@gmail.com wrote: On Sat, Dec 15, 2012 at 12:50 PM, Grant Likely grant.lik...@secretlab.ca wrote: On Thu, 13 Dec 2012 20:22:26 +0530, Vivek Gautam gautam.vi...@samsung.com wrote: Using chip specific compatible string as it should be. So fixing this for ehci-s5p, ohci-exynos and dwc3-exynos which till now used a generic 'exynos' in their compatible strings. This goes as per the discussion happened in the thread for [PATCH v2] ARM: Exynos5250: Enabling dwc3-exynos driver available at: http://www.spinics.net/lists/linux-usb/msg74145.html Vivek Gautam (2): usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device usb: dwc3-exynos: Fix compatible strings for the device for both patches: Acked-by: Grant Likely grant.lik...@secretlab.ca Any more thought about this patch-set? Or does this change seems fine? These two changes look good to me. For both of them: Reviewed-by: Doug Anderson diand...@chromium.org -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: correct the dw-mshc timing properties as per binding
Alim, On Mon, Jan 7, 2013 at 3:19 AM, Alim Akhtar alim.akh...@samsung.com wrote: As per the current exynos-dw-mshc bindings, dw-mshc-sdr-timing and dw-mshc-ddr-timing properties are having only two cells, these properties are wrongly set for exynos5250 based cros5250 and smdk5250 platfroms. This patch corrects above timing propreties for above platfroms Thanks for catching this. Given that this just removes a number from the dts file that isn't read by the code, I don't expect any functional change and I don't see any. I also double-checked usage and compared to the current Chrome OS tree. The third number (that you removed) is already correctly specified in the dts as samsung,dw-mshc-ciu-div. :) Signed-off-by: Alim Akhtar alim.akh...@samsung.com Tested-by: Doug Anderson diand...@chromium.org Acked-by: Doug Anderson diand...@chromium.org -- 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
[REPOST PATCH v3 2/4] ARM: dts: Add disable-wp for sd card slot on smdk5250
The next change will remove the code from the dw_mmc-exynos that added the DW_MCI_QUIRK_NO_WRITE_PROTECT. Keep existing functionality of having no write protect pin on smdk5250 by adding the disable-wp property. Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Seungwon Jeon tgih@samsung.com --- Changes in v3: - New for this version of the patch series. arch/arm/boot/dts/exynos5250-smdk5250.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts index 942d576..75b9d83 100644 --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts @@ -146,6 +146,7 @@ reg = 0; bus-width = 4; samsung,cd-pinmux-gpio = gpc3 2 2 3 3; + disable-wp; gpios = gpc3 0 2 0 3, gpc3 1 2 0 3, gpc3 3 2 3 3, gpc3 4 2 3 3, gpc3 5 2 3 3, gpc3 6 2 3 3, -- 1.7.7.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
Re: [REPOST PATCH v3 1/4] mmc: dw_mmc: Add disable-wp device tree property
Olof, Thanks for your comments. On Thu, Jan 10, 2013 at 3:01 PM, Olof Johansson o...@lixom.net wrote: The previous code used the controller-common quirk field to set a per-controller DW_MCI_QUIRK_NO_WRITE_PROTECT. Is there really need to do this per-slot? And if so, please explain in the commit message why there is need for a brand new quirk for the same functionality. I'm happy to move back to using a per-controller quirk here--it simplifies the code quite a bit since it can use all of the preexisting quirks code. I originally coded it up as per-slot since generally each slot needs its own write-protect line. Without ever seeing any hardware using multiple slots per controller I can't say how common this would be, so it may be overkill to handle that situation. Note that I think of the new code as being the device-tree equivalent of the non-device-tree brd-get_ro(slot_id) function. That function is per-slot. I will wait a day or two to see if others have feedback. If I hear no feedback I'll send up a patch that moves this to be at the controller level. Thanks! -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/5] mmc: dw_mmc: Add disable-wp device tree property
The disable-wp property is used to specify that a given SD card slot
doesn't have a concept of write protect. This eliminates the need for
special case code for SD slots that should never be write protected
(like a micro SD slot or a dev board).
The dw_mmc driver is special in needing to specify disable-wp
because the lack of a wp-gpios property means to use the special
purpose write protect line. On some other mmc devices the lack of
wp-gpios means that write protect should be disabled.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Seungwon Jeon tgih@samsung.com
---
Changes in v4:
- Added a comment about the fact that a future patch will remove the
controller-level quirk; the comments and quirk will be removed in
the future change mmc: dw_mmc: Remove
DW_MCI_QUIRK_NO_WRITE_PROTECT. I split the patch up this way to
preserve bisectability and also to keep changes logically separated.
I will squash if desired.
Changes in v3:
- New for this version of the patch series. Chose disable-wp rather
than the discussed broken-internal-wp since it mapped more cleanly
to an existing quirk (and the only reason to specify that the
internal wp is broken is if you're disabling the write protect
anyway).
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt | 12 +-
drivers/mmc/host/dw_mmc.c | 41 +++-
include/linux/mmc/dw_mmc.h |9
3 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 06cd32d08..726fd21 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -26,8 +26,16 @@ Required Properties:
* bus-width: as documented in mmc core bindings.
* wp-gpios: specifies the write protect gpio line. The format of the
- gpio specifier depends on the gpio controller. If the write-protect
- line is not available, this property is optional.
+ gpio specifier depends on the gpio controller. If a GPIO is not used
+ for write-protect, this property is optional.
+
+ * disable-wp: If the wp-gpios property isn't present then (by default)
+ we'd assume that the write protect is hooked up directly to the
+ controller's special purpose write protect line (accessible via
+ the WRTPRT register). However, it's possible that we simply don't
+ want write protect. In that case specify 'disable-wp'.
+ NOTE: This property is not required for slots known to always
+ connect to eMMC or SDIO cards.
Optional properties:
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 323c502..90f7d99 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -74,6 +74,7 @@ struct idmac_desc {
* struct dw_mci_slot - MMC slot state
* @mmc: The mmc_host representing this slot.
* @host: The MMC controller this slot is using.
+ * @quirks: Slot-level quirks (DW_MCI_SLOT_QUIRK_XXX)
* @ctype: Card type for this slot.
* @mrq: mmc_request currently being processed or waiting to be
* processed, or NULL when the slot is idle.
@@ -88,6 +89,8 @@ struct dw_mci_slot {
struct mmc_host *mmc;
struct dw_mci *host;
+ int quirks;
+
u32 ctype;
struct mmc_request *mrq;
@@ -825,7 +828,13 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
struct dw_mci_board *brd = slot-host-pdata;
/* Use platform get_ro function, else try on board write protect */
- if (brd-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT)
+
+ /*
+* NOTE: DW_MCI_QUIRK_NO_WRITE_PROTECT will be removed in a future
+* patch in the series once reference to it is removed.
+*/
+ if ((brd-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) ||
+ (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT))
read_only = 0;
else if (brd-get_ro)
read_only = brd-get_ro(slot-id);
@@ -1785,6 +1794,30 @@ static struct device_node
*dw_mci_of_find_slot_node(struct device *dev, u8 slot)
return NULL;
}
+static struct dw_mci_of_slot_quirks {
+ char *quirk;
+ int id;
+} of_slot_quirks[] = {
+ {
+ .quirk = disable-wp,
+ .id = DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT,
+ },
+};
+
+static int dw_mci_of_get_slot_quirks(struct device *dev, u8 slot)
+{
+ struct device_node *np = dw_mci_of_find_slot_node(dev, slot);
+ int quirks = 0;
+ int idx;
+
+ /* get quirks */
+ for (idx = 0; idx ARRAY_SIZE(of_slot_quirks); idx++)
+ if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
+ quirks |= of_slot_quirks[idx].id;
+
+ return quirks;
+}
+
/* find
[REPOST PATCH 0/2] Add automatic bus number support for i2c busses with device tree
This was suggested by Mark Brown in response to a patch for adding this functionality only for the s3c2410 bus: https://lkml.org/lkml/2012/11/20/681 I have also modified the i2c-pxa driver to use this new functionality. As Haojian Zhuang has Acked this patch, I believe that this has now been tested. Reposting (with Haojian Zhuang's ack) in the hopes that a maintainer will pick it up. :) Doug Anderson (2): i2c-core: dt: Pick i2c bus number from i2c alias if present i2c: pxa: Use i2c-core to get bus number now drivers/i2c/busses/i2c-pxa.c |8 +--- drivers/i2c/i2c-core.c | 105 ++--- 2 files changed, 78 insertions(+), 35 deletions(-) -- 1.7.7.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
[REPOST PATCH 2/2] i2c: pxa: Use i2c-core to get bus number now
The commit: i2c-core: dt: Pick i2c bus number from i2c alias if
present adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Haojian Zhuang haojian.zhu...@gmail.com
---
drivers/i2c/busses/i2c-pxa.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..8ee9fa0 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1053,16 +1053,10 @@ static int i2c_pxa_probe_dt(struct platform_device
*pdev, struct pxa_i2c *i2c,
struct device_node *np = pdev-dev.of_node;
const struct of_device_id *of_id =
of_match_device(i2c_pxa_dt_ids, pdev-dev);
- int ret;
if (!of_id)
return 1;
- ret = of_alias_get_id(np, i2c);
- if (ret 0) {
- dev_err(pdev-dev, failed to get alias id, errno %d\n, ret);
- return ret;
- }
- pdev-id = ret;
+ pdev-id = -1;
if (of_get_property(np, mrvl,i2c-polling, NULL))
i2c-use_pio = 1;
if (of_get_property(np, mrvl,i2c-fast-mode, NULL))
--
1.7.7.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
[REPOST PATCH 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
i2c0 = i2c_0;
i2c1 = i2c_1;
};
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Haojian Zhuang haojian.zhu...@gmail.com
---
drivers/i2c/i2c-core.c | 105 +++-
1 files changed, 77 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index e388590..a60ed6d 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -921,13 +921,81 @@ out_list:
}
/**
+ * i2c_get_number_from_dt - get the adapter number based on dt alias
+ * @adap: the adapter to look at
+ *
+ * Check whether there's an alias in the FDT that gives an ID for this i2c
+ * device. Use an alias like i2cnr, like:
+ * aliases {
+ * i2c0 = i2c_0;
+ * i2c1 = i2c_1;
+ * };
+ *
+ * Returns the ID if found. If no alias is found returns -1.
+ */
+static int i2c_get_number_from_dt(struct i2c_adapter *adap)
+{
+ struct device *dev = adap-dev;
+ int id;
+
+ if (!dev-of_node)
+ return -1;
+
+ id = of_alias_get_id(dev-of_node, i2c);
+ if (id 0)
+ return -1;
+ return id;
+}
+
+/**
+ * _i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap-nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int _i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ int id;
+ int status;
+
+ /* Handled by wrappers */
+ BUG_ON(adap-nr == -1);
+
+ if (adap-nr ~MAX_IDR_MASK)
+ return -EINVAL;
+
+retry:
+ if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
+ return -ENOMEM;
+
+ mutex_lock(core_lock);
+ /* above here means above or equal to, sigh;
+* we need the equal to result to force the result
+*/
+ status = idr_get_new_above(i2c_adapter_idr, adap, adap-nr, id);
+ if (status == 0 id != adap-nr) {
+ status = -EBUSY;
+ idr_remove(i2c_adapter_idr, id);
+ }
+ mutex_unlock(core_lock);
+ if (status == -EAGAIN)
+ goto retry;
+
+ if (status == 0)
+ status = i2c_register_adapter(adap);
+ return status;
+}
+
+/**
* i2c_add_adapter - declare i2c adapter, use dynamic bus number
* @adapter: the adapter to add
* Context: can sleep
*
* This routine is used to declare an I2C adapter when its bus number
- * doesn't matter. Examples: for I2C adapters dynamically added by
- * USB links or PCI plugin cards.
+ * doesn't matter or when its bus number is specified by an dt alias.
+ * Examples of bases when the bus number doesn't matter: I2C adapters
+ * dynamically added by USB links or PCI plugin cards.
*
* When this returns zero, a new bus number was allocated and stored
* in adap-nr, and the specified adapter became available for clients.
@@ -937,6 +1005,12 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
{
int id, res = 0;
+ id = i2c_get_number_from_dt(adapter);
+ if (id = 0) {
+ adapter-nr = id;
+ return _i2c_add_numbered_adapter(adapter);
+ }
+
retry:
if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
return -ENOMEM;
@@ -983,34 +1057,9 @@ EXPORT_SYMBOL(i2c_add_adapter);
*/
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
{
- int id;
- int status;
-
if (adap-nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
- if (adap-nr ~MAX_IDR_MASK)
- return -EINVAL;
-
-retry:
- if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
- return -ENOMEM;
-
- mutex_lock(core_lock);
- /* above here means above or equal to, sigh;
-* we need the equal to result to force the result
-*/
- status = idr_get_new_above(i2c_adapter_idr, adap, adap-nr, id);
- if (status == 0 id != adap-nr) {
- status = -EBUSY;
- idr_remove(i2c_adapter_idr, id);
- }
- mutex_unlock(core_lock);
- if (status == -EAGAIN)
- goto retry;
-
- if (status == 0)
- status = i2c_register_adapter(adap);
- return status;
+ return _i2c_add_numbered_adapter(adap);
}
EXPORT_SYMBOL_GPL(i2c_add_numbered_adapter);
--
1.7.7.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
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Vivek,
On Fri, Jan 11, 2013 at 4:40 AM, Vivek Gautam gautamvivek1...@gmail.com wrote:
+#define HOST_CTRL0_REFCLKSEL_MASK (0x3)
+#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19)
+#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 19)
+#define HOST_CTRL0_REFCLKSEL_CLKCORE (0x2 19)
+
+#define HOST_CTRL0_FSEL_MASK (0x7 16)
+#define HOST_CTRL0_FSEL(_x)((_x) 16)
+#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7)
+#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5)
+#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4)
+#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3)
+#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2)
+#define HOST_CTRL0_FSEL_CLKSEL_10M (0x1)
+#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0)
Add the shifts to the #defines and remove HOST_CTRL0_FSEL(_x). That
makes it match the older phy more closely.
Wouldn't it hamper the readability when shifts are used ??
I mean if we have something like this -
phyhost |= HOST_CTRL0_FSEL(phyclk)
so, if we are using the shifts then
phyhost |= (HOST_CTRL0_FSEL_CLKSEL_24M HOST_CTRL0_FSEL_SHIFT)
I was actually suggesting modifying the #defines like this:
#define HOST_CTRL0_FSEL_SHIFT 16
#define HOST_CTRL0_FSEL_MASK (0x7 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_10M (0x1 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0 HOST_CTRL0_FSEL_SHIFT)
...then the code doesn't need to think about shifts, right?
if (IS_ERR(ref_clk)) {
dev_err(sphy-dev, Failed to get reference clock\n);
return PTR_ERR(ref_clk);
}
- switch (clk_get_rate(ref_clk)) {
- case 12 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_12M;
- break;
- case 24 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_24M;
- break;
- case 48 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_48M;
- break;
- default:
- if (sphy-cpu_type == TYPE_S3C64XX)
- refclk_freq = PHYCLK_CLKSEL_48M;
- else
+ if (sphy-cpu_type == TYPE_EXYNOS5250) {
+ /* set clock frequency for PLL */
+ switch (clk_get_rate(ref_clk)) {
+ case 96 * 10:
nit: change to 9600 * KHZ to match; below too.
sure.
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_9600K;
Why |= with 0?
kept this just to keep things look similar :-). will remove this line,
My comment was about keeping things similar. Right now the 5250 code
has the |= and the non-5250 code doesn't. I don't care which is
picked but the two sides of the if should be symmetric.
See parts of the patch below.
+ break;
+ case 10 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_10M;
+ break;
+ case 12 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_12M;
+ break;
+ case 192 * 10:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_19200K;
+ break;
+ case 20 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_20M;
+ break;
+ case 50 * MHZ:
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_50M;
+ break;
+ case 24 * MHZ:
+ default:
+ /* default reference clock */
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_24M;
+ break;
+ }
+ } else {
+ switch (clk_get_rate(ref_clk)) {
+ case 12 * MHZ:
+ refclk_freq = PHYCLK_CLKSEL_12M;
+ break;
+ case 24 * MHZ:
refclk_freq = PHYCLK_CLKSEL_24M;
- break;
+ break;
+ case 48 * MHZ:
+ refclk_freq = PHYCLK_CLKSEL_48M;
+ break;
+ default:
+ if (sphy-cpu_type == TYPE_S3C64XX)
+ refclk_freq = PHYCLK_CLKSEL_48M;
+ else
+ refclk_freq = PHYCLK_CLKSEL_24M;
+ break;
+ }
}
clk_put(ref_clk);
return refclk_freq;
}
-Doug
--
To
Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT
Will, On Mon, Jan 14, 2013 at 2:47 AM, Will Newton will.new...@gmail.com wrote: These changes look ok to me. I don't know if patch 4 made it to the list, I only got a copy via the cc and the only archive I can find of linux-mmc (gmane) seems to be missing a lot of messages besides this one. It seems to have made it onto patchwork, in any case. Here's the link: https://patchwork.kernel.org/patch/1966771/ The whole bundle of all 5 patches at v4 is here: http://patchwork.kernel.org/bundle/dianders/mmc_wp/ So for the dw_mmc parts: Acked-by: Will Newton will.new...@imgtec.com Thank you for your review and your ack. :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REPOST PATCH 2/2] i2c: pxa: Use i2c-core to get bus number now
Sylwester,
Thanks for the review...
On Fri, Jan 11, 2013 at 2:12 PM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
- ret = of_alias_get_id(np, i2c);
- if (ret 0) {
- dev_err(pdev-dev, failed to get alias id, errno %d\n,
ret);
- return ret;
- }
- pdev-id = ret;
+ pdev-id = -1;
I think assignments like this are illegal. At this point the device is
already registered and modifying pdev-id can cause issues at the core
code.
Good catch. I think the old code is just as illegal since it was also
assigning to pdev-id, but I'm happy to spin the patch.
It might be better to have the bus number stored in struct pxa_i2c,
initialized with pdev-id value for non-dt and now with -1 for dt case.
I'll just init i2c-adap.nr before calling i2c_pxa_probe_dt(). Then
i2c_pxa_probe_dt() can adjust the number. Hopefully this is OK.
I realize it is not something your patch is intended to deal with,
but since you're touching this code maybe it's worth to fix that issue
as well ?
Sure, I've spun it. While doing this I realized a few other issues
relating to the ID number. Specifically:
* We were using the id (as %u) when creating 'i2c-adap.name'. This
probably gave a very nonsensical ID. I'm just going to remove the
device number from the adap.name. That matches what i2c-s3c2410.c
does. As far as I can tell the adap.name isn't actually used for
much.
* The name was being used in request_irq(). I've changed this to be
like i2c-s3c2410 and use dev_name(). On my current board that means
that the name comes from the table in of_platform_populate(). ...but
that table is supposed to be going away. If I remove that i2c parts
of that table I get names like '12c6.i2c', which should be fine
for passing to request_irq().
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Add automatic bus number support for i2c busses with device tree
This was suggested by Mark Brown in response to a patch for adding this functionality only for the s3c2410 bus: https://lkml.org/lkml/2012/11/20/681 I have also modified the i2c-pxa driver to use this new functionality. Changes in v2: - No longer tweak pdev-id as per Sylwester Nawrocki. - No longer add the dev ID to the adap.name. Other drivers don't include the device ID here and it doesn't make sense with dynamically (or automatically) allocated IDs. - Use dev_name(dev-dev) to register for the IRQ; this matches what the i2c-s3c2410.c does and handles dynamically allocated IDs. - This change was only compile-tested (corgi_defconfig), since I don't have access to a board that uses this driver. Doug Anderson (2): i2c-core: dt: Pick i2c bus number from i2c alias if present i2c: pxa: Use i2c-core to get bus number now drivers/i2c/busses/i2c-pxa.c | 20 drivers/i2c/i2c-core.c | 105 ++--- 2 files changed, 86 insertions(+), 39 deletions(-) -- 1.7.7.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
[PATCH v2 2/2] i2c: pxa: Use i2c-core to get bus number now
The commit: i2c-core: dt: Pick i2c bus number from i2c alias if
present adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- No longer tweak pdev-id as per Sylwester Nawrocki.
- No longer add the dev ID to the adap.name. Other drivers don't
include the device ID here and it doesn't make sense with
dynamically (or automatically) allocated IDs.
- Use dev_name(dev-dev) to register for the IRQ; this matches what
the i2c-s3c2410.c does and handles dynamically allocated IDs.
- This change was only compile-tested (corgi_defconfig), since I don't
have access to a board that uses this driver.
drivers/i2c/busses/i2c-pxa.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..705cc9f 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1053,16 +1053,13 @@ static int i2c_pxa_probe_dt(struct platform_device
*pdev, struct pxa_i2c *i2c,
struct device_node *np = pdev-dev.of_node;
const struct of_device_id *of_id =
of_match_device(i2c_pxa_dt_ids, pdev-dev);
- int ret;
if (!of_id)
return 1;
- ret = of_alias_get_id(np, i2c);
- if (ret 0) {
- dev_err(pdev-dev, failed to get alias id, errno %d\n, ret);
- return ret;
- }
- pdev-id = ret;
+
+ /* For device tree we always use the dynamic or alias-assigned ID */
+ i2c-adap.nr = -1;
+
if (of_get_property(np, mrvl,i2c-polling, NULL))
i2c-use_pio = 1;
if (of_get_property(np, mrvl,i2c-fast-mode, NULL))
@@ -1100,6 +1097,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
goto emalloc;
}
+ /* Default adapter num to device id; i2c_pxa_probe_dt can override. */
+ i2c-adap.nr = dev-id;
+
ret = i2c_pxa_probe_dt(dev, i2c, i2c_type);
if (ret 0)
ret = i2c_pxa_probe_pdata(dev, i2c, i2c_type);
@@ -1124,9 +1124,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
spin_lock_init(i2c-lock);
init_waitqueue_head(i2c-wait);
- i2c-adap.nr = dev-id;
- snprintf(i2c-adap.name, sizeof(i2c-adap.name), pxa_i2c-i2c.%u,
-i2c-adap.nr);
+ strlcpy(i2c-adap.name, pxa_i2c-i2c, sizeof(i2c-adap.name));
i2c-clk = clk_get(dev-dev, NULL);
if (IS_ERR(i2c-clk)) {
@@ -1169,7 +1167,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
} else {
i2c-adap.algo = i2c_pxa_algorithm;
ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
- i2c-adap.name, i2c);
+ dev_name(dev-dev), i2c);
if (ret)
goto ereqirq;
}
--
1.7.7.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
[PATCH v2 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
i2c0 = i2c_0;
i2c1 = i2c_1;
};
Signed-off-by: Doug Anderson diand...@chromium.org
Acked-by: Haojian Zhuang haojian.zhu...@gmail.com
---
Changes in v2: None
drivers/i2c/i2c-core.c | 105 +++-
1 files changed, 77 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index e388590..a60ed6d 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -921,13 +921,81 @@ out_list:
}
/**
+ * i2c_get_number_from_dt - get the adapter number based on dt alias
+ * @adap: the adapter to look at
+ *
+ * Check whether there's an alias in the FDT that gives an ID for this i2c
+ * device. Use an alias like i2cnr, like:
+ * aliases {
+ * i2c0 = i2c_0;
+ * i2c1 = i2c_1;
+ * };
+ *
+ * Returns the ID if found. If no alias is found returns -1.
+ */
+static int i2c_get_number_from_dt(struct i2c_adapter *adap)
+{
+ struct device *dev = adap-dev;
+ int id;
+
+ if (!dev-of_node)
+ return -1;
+
+ id = of_alias_get_id(dev-of_node, i2c);
+ if (id 0)
+ return -1;
+ return id;
+}
+
+/**
+ * _i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap-nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int _i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ int id;
+ int status;
+
+ /* Handled by wrappers */
+ BUG_ON(adap-nr == -1);
+
+ if (adap-nr ~MAX_IDR_MASK)
+ return -EINVAL;
+
+retry:
+ if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
+ return -ENOMEM;
+
+ mutex_lock(core_lock);
+ /* above here means above or equal to, sigh;
+* we need the equal to result to force the result
+*/
+ status = idr_get_new_above(i2c_adapter_idr, adap, adap-nr, id);
+ if (status == 0 id != adap-nr) {
+ status = -EBUSY;
+ idr_remove(i2c_adapter_idr, id);
+ }
+ mutex_unlock(core_lock);
+ if (status == -EAGAIN)
+ goto retry;
+
+ if (status == 0)
+ status = i2c_register_adapter(adap);
+ return status;
+}
+
+/**
* i2c_add_adapter - declare i2c adapter, use dynamic bus number
* @adapter: the adapter to add
* Context: can sleep
*
* This routine is used to declare an I2C adapter when its bus number
- * doesn't matter. Examples: for I2C adapters dynamically added by
- * USB links or PCI plugin cards.
+ * doesn't matter or when its bus number is specified by an dt alias.
+ * Examples of bases when the bus number doesn't matter: I2C adapters
+ * dynamically added by USB links or PCI plugin cards.
*
* When this returns zero, a new bus number was allocated and stored
* in adap-nr, and the specified adapter became available for clients.
@@ -937,6 +1005,12 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
{
int id, res = 0;
+ id = i2c_get_number_from_dt(adapter);
+ if (id = 0) {
+ adapter-nr = id;
+ return _i2c_add_numbered_adapter(adapter);
+ }
+
retry:
if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
return -ENOMEM;
@@ -983,34 +1057,9 @@ EXPORT_SYMBOL(i2c_add_adapter);
*/
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
{
- int id;
- int status;
-
if (adap-nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
- if (adap-nr ~MAX_IDR_MASK)
- return -EINVAL;
-
-retry:
- if (idr_pre_get(i2c_adapter_idr, GFP_KERNEL) == 0)
- return -ENOMEM;
-
- mutex_lock(core_lock);
- /* above here means above or equal to, sigh;
-* we need the equal to result to force the result
-*/
- status = idr_get_new_above(i2c_adapter_idr, adap, adap-nr, id);
- if (status == 0 id != adap-nr) {
- status = -EBUSY;
- idr_remove(i2c_adapter_idr, id);
- }
- mutex_unlock(core_lock);
- if (status == -EAGAIN)
- goto retry;
-
- if (status == 0)
- status = i2c_register_adapter(adap);
- return status;
+ return _i2c_add_numbered_adapter(adap);
}
EXPORT_SYMBOL_GPL(i2c_add_numbered_adapter);
--
1.7.7.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
Re: [PATCH] usb: phy: samsung: Add support to set pmu isolation
Vivek,
Sorry for being so absent from these reviews. I'll try to look over a
few patches today, but please don't hold up anything on account of my
reviews. I'm definitely a bit of an interested bystander in USB land.
;)
In general things look pretty good here. :) One last comment below...
On Fri, Jan 11, 2013 at 12:08 AM, Vivek Gautam
gautam.vi...@samsung.com wrote: +static int
samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
+{
+ struct device_node *usbphy_sys;
+
+ /* Getting node for system controller interface for usb-phy */
+ usbphy_sys = of_get_child_by_name(sphy-dev-of_node, usbphy-sys);
+ if (!usbphy_sys)
+ dev_warn(sphy-dev, No sys-controller interface for
usb-phy\n);
Seems like you ought to return with an error here. Calling of_iomap()
with a NULL value seems undesirable.
+
+ sphy-pmuregs = of_iomap(usbphy_sys, 0);
+
+ of_node_put(usbphy_sys);
+
+ if (sphy-pmuregs == NULL) {
+ dev_err(sphy-dev, Can't get usb-phy pmu control
register\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+/*
+ * Set isolation here for phy.
+ * Here 'on = true' would mean USB PHY block is isolated, hence
+ * de-activated and vice-versa.
+ */
Thank you very much for this comment. :) This explains one of the
confusions I had earlier...
Once you fix the one error condition above you can add my
Reviewed-by. Thanks!
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Vivek, On Mon, Jan 14, 2013 at 12:06 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: Is it fine if we don't use macro for SHIFT, earlier code also doesn't use it. Can we just do like this .. #define HOST_CTRL0_FSEL_MASK (0x7 16) #define HOST_CTRL0_FSEL_CLKSEL_50M(0x7 16) #define HOST_CTRL0_FSEL_CLKSEL_24M(0x5 16) #define HOST_CTRL0_FSEL_CLKSEL_20M(0x4 16) #define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3 16) #define HOST_CTRL0_FSEL_CLKSEL_12M(0x2 16) #define HOST_CTRL0_FSEL_CLKSEL_10M(0x1 16) #define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0 16) I don't have a problem with just putting the 16 there... Actually missed one thing here, this HOST_CTRL0_FSEL_CLKSEL_XX is being used by HOST/OTG blocks to prepare reference clock, that's the reason we kept #define HOST_CTRL0_FSEL(_x) ((_x) 16) and #define OTG_SYS_FSEL(_x) ((_x) 4) where (_x) is the reference clock returned from samsung_usbphy_get_refclk_freq(). I feel like samsung_usbphy_get_refclk_freq() is supposed to be returning an already shifted value. ...at least that's how it appears to work with existing code. Why does it feel like that? ...because with existing code we have: #define PHYCLK_CLKSEL_MASK (0x3 0) #define PHYCLK_CLKSEL_48M (0x0 0) #define PHYCLK_CLKSEL_12M (0x2 0) #define PHYCLK_CLKSEL_24M (0x3 0) Those #defines are what are returned by samsung_usbphy_get_refclk_freq(). The fact that the 0 is there implies (to me) that the existing function would return shifted values if it were applicable. For exynos you are having the same function return things like: #define FSEL_CLKSEL_50M (0x7) #define FSEL_CLKSEL_24M (0x5) #define FSEL_CLKSEL_20M (0x4) ...to me that means that the exynos code is returning unshifted values. If you say that samsung_usbphy_get_refclk_freq() is in charge of returning shifted values then you no longer need the HOST_CTRL0_FSEL() macro. In any case, I will defer to whatever Felipe thinks is best here (if he has an opinion on it). I am only pointing out that the exynos code and existing code seem to be specifying things differently. That's weird to me. so we can change this to something like case 10 * MHZ: refclk_freq = FSEL_CLKSEL_10M; break; and so on. will this be fine ? Seems good to me. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iio: adc: add exynos5 adc driver under iio framwork
Lars, On Wed, Jan 23, 2013 at 4:52 AM, Lars-Peter Clausen l...@metafoo.de wrote: Few doubts regarding the mappings and child device handling. Kindly, suggest me better methods. The patch looks mostly good now. As for the mappings, the problem is that we currently do not have any device tree bindings for IIO. So a proper solution would be to add dt bindings for IIO. Can you explain more how you think this would work? It seems like just having child nodes as platform drivers would be OK (to me) and having them instantiated with of_platform_populate() seems reasonable. ...but the one thing that is missing is a way for children to get access to the channel properly. The children have access to the ADC struct device (it is their parent device) and have a channel number (their reg field), but there is no API call to map this to a struct iio_channel. Is that all that's needed in this case? ...or are you envisioning something more? Thanks! :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] iio: adc: add exynos5 adc driver under iio framwork
Lars,
Thank you for your comments / thoughts...
On Thu, Jan 24, 2013 at 1:54 AM, Lars-Peter Clausen l...@metafoo.de wrote:
adc: adc@12D1 {
#io-channel-cells = 1;
io-channel-output-names = adc1, adc2, ...;
ncp15wb473@0 {
compatible = ntc,ncp15wb473;
...
io-channels = adc 0; // First ADC channel
I'm not an expert, but I think the typical way is:
* No need to include a handle to adc. It's logically our parent. In
a similar way i2c devices don't specify their parent bus--they are
just listed under it.
* The 0 should be specified with reg = 0
Everything else about this syntax looks good.
To implement this I'd imagine that we'll need a new API call, right?
In this case the thermistor driver won't know the name of the channel.
It can find the ADC (the struct device and probably other things) and
knows a channel index. Am I understanding properly?
I think Naveen expressed the same question, though he said it a bit
differently than me.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: Providing hooks for i2c multimaster bus arbitration.
Yavaraj, On Mon, Feb 4, 2013 at 1:03 AM, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote: This RFC patch is w.r.t multimaster bus arbitration which is already being discussing in the mainline. This patch provides hooks for the i2c multimaster bus arbitration and to have the arbitration parameters. I may have missed something in all the threads, but my recollection was that the request was that this should be implemented without touching the i2c core code. Your patch modifies the i2c core code. My impression was that the best solution was to use the infrastructure in place for i2c multiplexing. ...but in your case you would only multiplex one thing. This was suggested by Grant Likely and seems the cleanest... [apologies for double-email; darn gmail and HTML email] -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: Providing hooks for i2c multimaster bus arbitration.
Wolfram, On Sun, Feb 10, 2013 at 10:17 AM, Wolfram Sang w.s...@pengutronix.de wrote: On Mon, Feb 04, 2013 at 02:33:15PM +0530, Yuvaraj Kumar C D wrote: This RFC patch is w.r.t multimaster bus arbitration which is already being discussing in the mainline. This patch provides hooks for the i2c multimaster bus arbitration and to have the arbitration parameters. I still haven't understood why the arbitration specified in the I2C standard is not enough for you. Or what you would need to make use of it. At the moment perhaps the strongest argument for why this particular arbitration scheme is needed is that's what the EC (embedded controller) on the ARM Chromebook uses. There have been several arguments in-house about whether this was the most ideal way to structure things, but that's what we shipped with. Thus, if we want to be able to talk to i2c devices on this bus (contains the keyboard, battery, and a bunch of power switches) we need something in the system that implements this arbitration scheme. As a side note: I'm trying to code up a quick arbitrator now using the muxing framework as Grant suggested. I will play with this and post it if I can get it to work. It's quite short so far. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
i2c0 = i2c_0;
i2c1 = i2c_1;
};
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3:
- Addressed Wolfram's feedback; rebased atop idr-cleanup series.
Changes in v2: None
drivers/i2c/i2c-core.c | 54 +-
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 0b599f2..5204818 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -921,13 +921,41 @@ out_list:
}
/**
+ * __i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap-nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int __i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ int id;
+
+ /* Handled by wrappers */
+ if (WARN_ON(adap-nr == -1))
+ return -EINVAL;
+
+ if (adap-nr ~MAX_IDR_MASK)
+ return -EINVAL;
+
+ mutex_lock(core_lock);
+ id = idr_alloc(i2c_adapter_idr, adap, adap-nr, adap-nr + 1,
+ GFP_KERNEL);
+ mutex_unlock(core_lock);
+ if (id 0)
+ return id == -ENOSPC ? -EBUSY : id;
+ return i2c_register_adapter(adap);
+}
+
+/**
* i2c_add_adapter - declare i2c adapter, use dynamic bus number
* @adapter: the adapter to add
* Context: can sleep
*
* This routine is used to declare an I2C adapter when its bus number
- * doesn't matter. Examples: for I2C adapters dynamically added by
- * USB links or PCI plugin cards.
+ * doesn't matter or when its bus number is specified by an dt alias.
+ * Examples of bases when the bus number doesn't matter: I2C adapters
+ * dynamically added by USB links or PCI plugin cards.
*
* When this returns zero, a new bus number was allocated and stored
* in adap-nr, and the specified adapter became available for clients.
@@ -935,8 +963,17 @@ out_list:
*/
int i2c_add_adapter(struct i2c_adapter *adapter)
{
+ struct device *dev = adapter-dev;
int res;
+ if (dev-of_node) {
+ res = of_alias_get_id(dev-of_node, i2c);
+ if (res = 0) {
+ adapter-nr = res;
+ return __i2c_add_numbered_adapter(adapter);
+ }
+ }
+
mutex_lock(core_lock);
res = idr_alloc(i2c_adapter_idr, adapter,
__i2c_first_dynamic_bus_num, 0, GFP_KERNEL);
@@ -974,20 +1011,9 @@ EXPORT_SYMBOL(i2c_add_adapter);
*/
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
{
- int id;
-
if (adap-nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
- if (adap-nr ~MAX_IDR_MASK)
- return -EINVAL;
-
- mutex_lock(core_lock);
- id = idr_alloc(i2c_adapter_idr, adap, adap-nr, adap-nr + 1,
- GFP_KERNEL);
- mutex_unlock(core_lock);
- if (id 0)
- return id == -ENOSPC ? -EBUSY : id;
- return i2c_register_adapter(adap);
+ return __i2c_add_numbered_adapter(adap);
}
EXPORT_SYMBOL_GPL(i2c_add_numbered_adapter);
--
1.8.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
[PATCH v3 2/2] i2c: pxa: Use i2c-core to get bus number now
The commit: i2c-core: dt: Pick i2c bus number from i2c alias if
present adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v3: None
Changes in v2:
- No longer tweak pdev-id as per Sylwester Nawrocki.
- No longer add the dev ID to the adap.name. Other drivers don't
include the device ID here and it doesn't make sense with
dynamically (or automatically) allocated IDs.
- Use dev_name(dev-dev) to register for the IRQ; this matches what
the i2c-s3c2410.c does and handles dynamically allocated IDs.
- This change was only compile-tested (corgi_defconfig), since I don't
have access to a board that uses this driver.
drivers/i2c/busses/i2c-pxa.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..705cc9f 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1053,16 +1053,13 @@ static int i2c_pxa_probe_dt(struct platform_device
*pdev, struct pxa_i2c *i2c,
struct device_node *np = pdev-dev.of_node;
const struct of_device_id *of_id =
of_match_device(i2c_pxa_dt_ids, pdev-dev);
- int ret;
if (!of_id)
return 1;
- ret = of_alias_get_id(np, i2c);
- if (ret 0) {
- dev_err(pdev-dev, failed to get alias id, errno %d\n, ret);
- return ret;
- }
- pdev-id = ret;
+
+ /* For device tree we always use the dynamic or alias-assigned ID */
+ i2c-adap.nr = -1;
+
if (of_get_property(np, mrvl,i2c-polling, NULL))
i2c-use_pio = 1;
if (of_get_property(np, mrvl,i2c-fast-mode, NULL))
@@ -1100,6 +1097,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
goto emalloc;
}
+ /* Default adapter num to device id; i2c_pxa_probe_dt can override. */
+ i2c-adap.nr = dev-id;
+
ret = i2c_pxa_probe_dt(dev, i2c, i2c_type);
if (ret 0)
ret = i2c_pxa_probe_pdata(dev, i2c, i2c_type);
@@ -1124,9 +1124,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
spin_lock_init(i2c-lock);
init_waitqueue_head(i2c-wait);
- i2c-adap.nr = dev-id;
- snprintf(i2c-adap.name, sizeof(i2c-adap.name), pxa_i2c-i2c.%u,
-i2c-adap.nr);
+ strlcpy(i2c-adap.name, pxa_i2c-i2c, sizeof(i2c-adap.name));
i2c-clk = clk_get(dev-dev, NULL);
if (IS_ERR(i2c-clk)) {
@@ -1169,7 +1167,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
} else {
i2c-adap.algo = i2c_pxa_algorithm;
ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
- i2c-adap.name, i2c);
+ dev_name(dev-dev), i2c);
if (ret)
goto ereqirq;
}
--
1.8.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
Re: [PATCH v2 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
Wolfram,
Thanks for the review. New patch was just sent. :)
On Sun, Feb 10, 2013 at 4:19 AM, Wolfram Sang w.s...@pengutronix.de wrote:
+static int i2c_get_number_from_dt(struct i2c_adapter *adap)
i2c_get_id_from_dt()?
Done.
+ if (!dev-of_node)
+ return -1;
-ESOMETHING?
Function has been removed, as per below.
+
+ id = of_alias_get_id(dev-of_node, i2c);
+ if (id 0)
+ return -1;
+ return id;
Simply 'return of_alias_get_id(...)'? Even more, since this function
boils down to calling of_alias_get_id only and is only used once, I'd
think we can implement that directly and drop this function. That
shouldn't hurt readability.
Good point. Done.
+/**
+ * _i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap-nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int _i2c_add_numbered_adapter(struct i2c_adapter *adap)
All other internal functions are prefixed with '__'.
Done.
+{
+ int id;
+ int status;
+
+ /* Handled by wrappers */
+ BUG_ON(adap-nr == -1);
Is that a reason to halt the kernel? WARN and bailing out would do IMO.
Done.
+
+ if (adap-nr ~MAX_IDR_MASK)
+ return -EINVAL;
Note the idr-cleanup series from Tejun Heo. Given that his series is
scheduled for v3.9, I'd like to have your patches on top of his.
Done.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] Add automatic bus number support for i2c busses with device tree
This was suggested by Mark Brown in response to a patch for adding this functionality only for the s3c2410 bus: https://lkml.org/lkml/2012/11/20/681 I have also modified the i2c-pxa driver to use this new functionality. The i2c-pxa driver changes have only been compile-tested and are just for cleanup purposes. Changes in v3: - Addressed Wolfram's feedback; rebased atop idr-cleanup series. Changes in v2: - No longer tweak pdev-id as per Sylwester Nawrocki. - No longer add the dev ID to the adap.name. Other drivers don't include the device ID here and it doesn't make sense with dynamically (or automatically) allocated IDs. - Use dev_name(dev-dev) to register for the IRQ; this matches what the i2c-s3c2410.c does and handles dynamically allocated IDs. - This change was only compile-tested (corgi_defconfig), since I don't have access to a board that uses this driver. Doug Anderson (2): i2c-core: dt: Pick i2c bus number from i2c alias if present i2c: pxa: Use i2c-core to get bus number now drivers/i2c/busses/i2c-pxa.c | 20 drivers/i2c/i2c-core.c | 54 2 files changed, 49 insertions(+), 25 deletions(-) -- 1.8.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
Re: [PATCH] ARM: exynos: move exynos4210-combiner to drivers/irqchip
Rob / Olof, On Tue, Feb 12, 2013 at 2:52 PM, Olof Johansson o...@lixom.net wrote: On Tue, Feb 12, 2013 at 04:04:52PM -0600, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com Exynos boot is broken with commit 0529e315 (ARM: use common irqchip_init for GIC init). This commit split the irqchip initialization into 2 calls to of_irq_init. This does not work because of_irq_init requires interrupt parents to be in the match list. Rather than reverting exynos changes, make it do the proper thing by using IRQCHIP_DECLARE. This requires moving the combiner code to drivers/irqchip. Reported-by: Doug Anderson diand...@chromium.org Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Kukjin Kim kgene@samsung.com Cc: Russell King li...@arm.linux.org.uk Cc: Thomas Gleixner t...@linutronix.de Cc: linux-samsung-soc@vger.kernel.org --- I thought there may be other platforms broken in the same way, but I checked and exynos is the only one. This is based on my gic/vic irqchip branch in arm-soc. Applied to next/cleanup. I synced up to next-20130213 and the problem is fixed. :) ...that label doesn't exactly boot but the problems are unrelated to this problem now (there are problems with the OF conversions to raw spinlocks)... I haven't done any review of this code (I'm assuming that Olof already looked it over and Samsung engineers will give it a thorough review), but it's definitely tested. :) Tested-by: Doug Anderson diand...@chromium.org Thanks! -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Add automatic bus number support for i2c busses with device tree
Wolfram, On Mon, Feb 11, 2013 at 4:48 PM, Doug Anderson diand...@chromium.org wrote: This was suggested by Mark Brown in response to a patch for adding this functionality only for the s3c2410 bus: https://lkml.org/lkml/2012/11/20/681 I have also modified the i2c-pxa driver to use this new functionality. The i2c-pxa driver changes have only been compile-tested and are just for cleanup purposes. Changes in v3: - Addressed Wolfram's feedback; rebased atop idr-cleanup series. Changes in v2: - No longer tweak pdev-id as per Sylwester Nawrocki. - No longer add the dev ID to the adap.name. Other drivers don't include the device ID here and it doesn't make sense with dynamically (or automatically) allocated IDs. - Use dev_name(dev-dev) to register for the IRQ; this matches what the i2c-s3c2410.c does and handles dynamically allocated IDs. - This change was only compile-tested (corgi_defconfig), since I don't have access to a board that uses this driver. Doug Anderson (2): i2c-core: dt: Pick i2c bus number from i2c alias if present i2c: pxa: Use i2c-core to get bus number now drivers/i2c/busses/i2c-pxa.c | 20 drivers/i2c/i2c-core.c | 54 2 files changed, 49 insertions(+), 25 deletions(-) Is there anything else needed for this patch series? It's been hanging around for quite a while and it would be nice to see it land. If you're waiting for additional acks or reviews I'll ask around and see if I can get them... Thanks! :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] Add automatic bus number support for i2c busses with device tree
Wolfram, On Thu, Feb 28, 2013 at 3:25 PM, Wolfram Sang w...@the-dreams.de wrote: Regarding patch 1, I was waiting for the idr changes to hit mainline. They are mainline now, but since the removal of MAX_IDR_MASK your patch doesn't apply anymore :( Can you rebase and retest, please? I'd like to get it into 3.9, still. Yes, I'll rebase/retest tomorrow. I'll let you make the call between 3.9 and 3.10. Obviously I'd love to see it in 3.9 but I'm OK with either. I was just hoping not to find out at the end of the 3.10 cycle that it needs fixes and need to wait for 3.11. I wanted to make sure all my ducks were in a row. ;-) For patch 2, some Tested-by would be nice; but it will probably make it into my for-next somewhen after rc1 is out. I have no urgent need for patch 2 to land but it seemed nice to tidy up the pxa driver and I felt it was my obligation to post it together with patch set #1 (plus it's always nice to remove code). Putting it into your for-next seems like a very good solution. That gives people some time to test it and make sure it works for them. Thanks! -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] Add automatic bus number support for i2c busses with device tree
This was suggested by Mark Brown in response to a patch for adding this functionality only for the s3c2410 bus: https://lkml.org/lkml/2012/11/20/681 I have also modified the i2c-pxa driver to use this new functionality. The i2c-pxa driver changes have only been compile-tested and are just for cleanup purposes. Changes in v4: - Rebased atop the removal of MAX_IDR_MASK. Changes in v3: - Addressed Wolfram's feedback; rebased atop idr-cleanup series. Changes in v2: - No longer tweak pdev-id as per Sylwester Nawrocki. - No longer add the dev ID to the adap.name. Other drivers don't include the device ID here and it doesn't make sense with dynamically (or automatically) allocated IDs. - Use dev_name(dev-dev) to register for the IRQ; this matches what the i2c-s3c2410.c does and handles dynamically allocated IDs. - This change was only compile-tested (corgi_defconfig), since I don't have access to a board that uses this driver. Doug Anderson (2): i2c-core: dt: Pick i2c bus number from i2c alias if present i2c: pxa: Use i2c-core to get bus number now drivers/i2c/busses/i2c-pxa.c | 20 -- drivers/i2c/i2c-core.c | 49 +--- 2 files changed, 46 insertions(+), 23 deletions(-) -- 1.8.1.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
[PATCH v4 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
i2c0 = i2c_0;
i2c1 = i2c_1;
};
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v4:
- Rebased atop the removal of MAX_IDR_MASK.
Changes in v3:
- Addressed Wolfram's feedback; rebased atop idr-cleanup series.
Changes in v2: None
drivers/i2c/i2c-core.c | 49 +
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 991d38d..66c5252 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -921,13 +921,38 @@ out_list:
}
/**
+ * __i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap-nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int __i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ int id;
+
+ /* Handled by wrappers */
+ if (WARN_ON(adap-nr == -1))
+ return -EINVAL;
+
+ mutex_lock(core_lock);
+ id = idr_alloc(i2c_adapter_idr, adap, adap-nr, adap-nr + 1,
+ GFP_KERNEL);
+ mutex_unlock(core_lock);
+ if (id 0)
+ return id == -ENOSPC ? -EBUSY : id;
+ return i2c_register_adapter(adap);
+}
+
+/**
* i2c_add_adapter - declare i2c adapter, use dynamic bus number
* @adapter: the adapter to add
* Context: can sleep
*
* This routine is used to declare an I2C adapter when its bus number
- * doesn't matter. Examples: for I2C adapters dynamically added by
- * USB links or PCI plugin cards.
+ * doesn't matter or when its bus number is specified by an dt alias.
+ * Examples of bases when the bus number doesn't matter: I2C adapters
+ * dynamically added by USB links or PCI plugin cards.
*
* When this returns zero, a new bus number was allocated and stored
* in adap-nr, and the specified adapter became available for clients.
@@ -935,8 +960,17 @@ out_list:
*/
int i2c_add_adapter(struct i2c_adapter *adapter)
{
+ struct device *dev = adapter-dev;
int id;
+ if (dev-of_node) {
+ id = of_alias_get_id(dev-of_node, i2c);
+ if (id = 0) {
+ adapter-nr = id;
+ return __i2c_add_numbered_adapter(adapter);
+ }
+ }
+
mutex_lock(core_lock);
id = idr_alloc(i2c_adapter_idr, adapter,
__i2c_first_dynamic_bus_num, 0, GFP_KERNEL);
@@ -975,18 +1009,9 @@ EXPORT_SYMBOL(i2c_add_adapter);
*/
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
{
- int id;
-
if (adap-nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
-
- mutex_lock(core_lock);
- id = idr_alloc(i2c_adapter_idr, adap, adap-nr, adap-nr + 1,
- GFP_KERNEL);
- mutex_unlock(core_lock);
- if (id 0)
- return id == -ENOSPC ? -EBUSY : id;
- return i2c_register_adapter(adap);
+ return __i2c_add_numbered_adapter(adap);
}
EXPORT_SYMBOL_GPL(i2c_add_numbered_adapter);
--
1.8.1.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
[PATCH v4 2/2] i2c: pxa: Use i2c-core to get bus number now
The commit: i2c-core: dt: Pick i2c bus number from i2c alias if
present adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- No longer tweak pdev-id as per Sylwester Nawrocki.
- No longer add the dev ID to the adap.name. Other drivers don't
include the device ID here and it doesn't make sense with
dynamically (or automatically) allocated IDs.
- Use dev_name(dev-dev) to register for the IRQ; this matches what
the i2c-s3c2410.c does and handles dynamically allocated IDs.
- This change was only compile-tested (corgi_defconfig), since I don't
have access to a board that uses this driver.
drivers/i2c/busses/i2c-pxa.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1e88e8d..ea6d45d 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1053,16 +1053,13 @@ static int i2c_pxa_probe_dt(struct platform_device
*pdev, struct pxa_i2c *i2c,
struct device_node *np = pdev-dev.of_node;
const struct of_device_id *of_id =
of_match_device(i2c_pxa_dt_ids, pdev-dev);
- int ret;
if (!of_id)
return 1;
- ret = of_alias_get_id(np, i2c);
- if (ret 0) {
- dev_err(pdev-dev, failed to get alias id, errno %d\n, ret);
- return ret;
- }
- pdev-id = ret;
+
+ /* For device tree we always use the dynamic or alias-assigned ID */
+ i2c-adap.nr = -1;
+
if (of_get_property(np, mrvl,i2c-polling, NULL))
i2c-use_pio = 1;
if (of_get_property(np, mrvl,i2c-fast-mode, NULL))
@@ -1100,6 +1097,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
goto emalloc;
}
+ /* Default adapter num to device id; i2c_pxa_probe_dt can override. */
+ i2c-adap.nr = dev-id;
+
ret = i2c_pxa_probe_dt(dev, i2c, i2c_type);
if (ret 0)
ret = i2c_pxa_probe_pdata(dev, i2c, i2c_type);
@@ -1124,9 +1124,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
spin_lock_init(i2c-lock);
init_waitqueue_head(i2c-wait);
- i2c-adap.nr = dev-id;
- snprintf(i2c-adap.name, sizeof(i2c-adap.name), pxa_i2c-i2c.%u,
-i2c-adap.nr);
+ strlcpy(i2c-adap.name, pxa_i2c-i2c, sizeof(i2c-adap.name));
i2c-clk = clk_get(dev-dev, NULL);
if (IS_ERR(i2c-clk)) {
@@ -1169,7 +1167,7 @@ static int i2c_pxa_probe(struct platform_device *dev)
} else {
i2c-adap.algo = i2c_pxa_algorithm;
ret = request_irq(irq, i2c_pxa_handler, IRQF_SHARED,
- i2c-adap.name, i2c);
+ dev_name(dev-dev), i2c);
if (ret)
goto ereqirq;
}
--
1.8.1.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
State of pinctrl and exynos5250?
Thomas and Tomasz, I'm trying to get my head wrapped around the state of pinctrl for exynos5250. I see various patches that have floated around at times but it doesn't look like anything has landed. It would be really nice to get this resolved since I think it blocks getting eint support landed for exynos5250 and that blocks getting many peripherals working on the ARM Chromebook. I'm still a little new to the world on pinctrl so hopefully nothing below is too stupidly wrong... --- Patches that seem to be relevant (NOTE: all of these need pinctrl-exynos5250 fixed to exynos5250-pinctrl): pinctrl: exynos: add exynos5250 SoC specific data - https://patchwork.kernel.org/patch/1871901/ gpio: samsung: skip gpiolib registration if pinctrl support is enabled for exynos5250 - https://patchwork.kernel.org/patch/1871911/ arm: exynos: skip wakeup interrupt registration for exynos5250 if pinctrl is enabled - https://patchwork.kernel.org/patch/1871921/ ARM: dts: add pinctrl nodes for Exynos5250 SoC - https://patchwork.kernel.org/patch/1871991/ -- NOTE: Appears to be missing pinctrl_1 and pinctrl_2. That prevents me from compiling with i2c arbitration patches landed since I need gpf0. -- NOTE: Appears (IIRC) to have incorrect interrupt for pinctrl_3. I believe that 45 is pinctrl_1. Maybe 3 is 47? -- NIT NOTE: It appears sd0_busN is strangely specified. Specifically sd0_bus4 includes the pins for sd0_bus1 but sd0_bus8 doesn't. --- I've got all of the above patches fixed up in my local tree (including adding really basic support for pinctrl_1 and pinctrl_2). ...but my machine doesn't boot all the way. I think that's because many of the peripherals don't yet understand pinctrl. Specifically I get delightful looking error messages at bootup that look like: [0.44] _gpio_request: gpio-36 (i2c-bus) status -16 [0.445000] s3c-i2c s3c2440-i2c.0: gpio [36] request failed I then replaced some of the muxing via GPIO with muxing via pinctrl for i2c parts, like: - gpios = gpb3 0 2 3 0, - gpb3 1 2 3 0; + pinctrl-0 = i2c0_bus; + pinctrl-names = default; ...and I got rid of those errors, but it looks like we're missing pinctrl support for the ever-important dw_mmc. [0.91] Synopsys Designware Multimedia Card Interface Driver [0.915000] dwmmc_exynos dw_mmc.0: Using internal DMA controller. [0.92] dwmmc_exynos dw_mmc.0: DW MMC controller at irq 107, 32 bit host data width, 128 deep fifo [0.93] of_get_named_gpio_flags exited with status 40 [0.935000] of_get_named_gpio_flags: can't parse gpios property [0.94] dwmmc_exynos dw_mmc.0: invalid gpio: -2 [0.945000] dwmmc_exynos: probe of dw_mmc.0 failed with error -22 We also need it for spi-s3c64xx.c but that's less of a critical component. [0.405000] of_get_named_gpio_flags exited with status 18 [0.41] /spi@12d3: could not get #gpio-cells for /pinctrl@1140/i2c0-bus [0.415000] of_get_named_gpio_flags: can't parse gpios property [0.42] s3c64xx-spi exynos4210-spi.1: invalid gpio[1]: -22 [0.425000] s3c64xx-spi: probe of exynos4210-spi.1 failed with error -16 Those are the drivers that have their muxing state defined using the old hacky samsung gpio descriptor. Hmmm, it also looks like I need to update other gpio references too (gpio-keys, i2c-arbitrator, hpd-gpio) since the GPIO specifier has changed now that it's based on pinmux. I guess you either need to move a whole architecture (all of exynos5250) at once since you can't mix and match. IMHO that means we've got the following work ahead of us: 1. Add pinctrl support to dw_mmc-exynos (with backward compability for GPIO specifier) 2. Add pinctrl support to spi-s3c64xx.c (with backward compability for GPIO specifier) 3. In one fell swoop convert all exynos5 dts / dtsi files over to use pinctrl since things will be broken with a half conversion. Assuming I'm understanding #3 above, I guess that means that I NAK the ARM: dts: add pinctrl nodes for Exynos5250 SoC patch since it doesn't include fixup for all of the exynos5250 platforms (smdk5250 and snow) out there. --- I'd appreciate any thoughts that you have. I'd also appreciate a timeframe for when this work will be picked back up, since the old patches are 2.5 months old now... I may be able to help a little (especially with bits relevant to the ARM Chromebook) but I'm not sure I can do all of the heavy lifting... ...and I'd hate to rebase/repost Thomas's patches myself without checking... NOTE: I've actually hacked something together that seems to get dw_mmc happy with pinmuxing and I can boot the system, so I guess that proves that the above can't all be wrong. ;) Thanks much and sorry for the super long email! :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: State of pinctrl and exynos5250?
Tomasz, Thanks for your response. On Sat, Mar 2, 2013 at 3:48 AM, Tomasz Figa tomasz.f...@gmail.com wrote: The 4 patches above are already merged in Kgene's for-next-next (for 3.10) branch. Excellent. I see them now. I haven't yet seen them show up in linux-next (which is where I tend to look first), though... ARM: dts: add pinctrl nodes for Exynos5250 SoC - https://patchwork.kernel.org/patch/1871991/ This one is not merged yet. Since I do not know much about Exynos 5250, I could not verify any hardware-specific details in the patch, just the general correctness of the patch. OK, good. That means you guys came to the same conclusions that I did. :) IMHO that means we've got the following work ahead of us: 1. Add pinctrl support to dw_mmc-exynos (with backward compability for GPIO specifier) 2. Add pinctrl support to spi-s3c64xx.c (with backward compability for GPIO specifier) There is a patch that should be already merged that makes the driver core set default pinctrl state for a device before entering driver's probe callback. In case when the driver doesn't require more states than just the default one you don't have to add pinctrl support to the driver at all, just specify appropriate pinctrl properties in device tree (with only one state listed in pinctrl-names called default). However in some drivers this might be prevented by legacy pin configuration code which would fail. Nice to know about. In the very least I'm pretty sure that we'll need a patch to make the GPIO settings optional. Looking at dw_mci_exynos_setup_bus it's a fatal error if the GPIOs are missing. The dw_mmc stuff will also be interesting since we'll need to figure out if the muxing needs to be specified on a per-slot level. I think that most of the automatic stuff won't work in that case. It sounds like Thomas is planning on taking this on? -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of pinctrl and exynos5250?
Thomas, On Mon, Mar 4, 2013 at 6:04 AM, Thomas Abraham thomas.abra...@linaro.org wrote: Ok. I will repost this patch again with pinctrl_1 and pinctrl_2 included. I had not included this in the earlier patch since I was not sure of the best pin grouping for the camera and c2c interface. OK, thanks. -- NOTE: Appears (IIRC) to have incorrect interrupt for pinctrl_3. I believe that 45 is pinctrl_1. Maybe 3 is 47? I can't verify this, unfortunately. The documentation does not state this clearly. I will recheck on this and correct as needed. OK. Let me know if you can't find it. I spent a bunch of time digging in this area and wrote up my findings, but I certainly could be wrong. ;) I have posted i2c pinctrl support patch based on LinusW's pin grab by device core patch. If that is acceptable, I can post pinctrl support patches for other other controllers as well. OK, I see that. https://patchwork.kernel.org/patch/2212731/. That particular patch isn't strictly required, right? Even without that patch I can specify pinctrl for the i2c nodes and it will work OK--this just removes the old gpio nodes. One problem I see with taking this approach for DW_MMC and for SPI is that it will make bisecting hard. If you land a change to take out GPIO stuff from dw_mmc and the spi driver then it will make the transition difficult. exynos5 boards will stop booting until the device tree support is also landed. ...and it would be an awfully big patch to add all the device tree stuff in the same patch as the dw_mmc and spi driver changes... -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of pinctrl and exynos5250?
Thomas,
On Tue, Mar 5, 2013 at 3:49 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
Yes, I am currently held up with supporting default pin states at slot
level. One option that could be considered is to list out the default
pin states for all slots in the parent node of the slots. So it would
be something like below as an example.
dwmmc2@1222 {
pinctrl-names = slot0-default, slot1-default;
pinctrl-0 = sd2_clk sd2_cmd sd2_cd sd2_bus4;
pinctrl-1 = sd2_clk sd2_cmd sd2_cd sd2_bus4 sd2_bus8;
slot@0 {
reg = 0;
bus-width = 4;
disable-wp;
};
slot@1 {
reg = 0;
bus-width = 8;
disable-wp;
};
};
Then, during the initial slot setup stage, the driver, knowing the
current slot number that is being setup, can setup the pin state for
the particular slot using the devm_pinctrl_get_select API. pinctrl
subsystem would not setup the default pin state in this case.
Does this look like a hack?
That feels like a hack to me. The right place for the slot data is
under the slot node, not in the parent. ...but I would certainly
defer to any experts that might have a different opinion.
For now, I have prepared patches without
this approach, since Exynos5250 has just one slot, I have just listed
only one default pin state, which the pinctrl framework helps to setup
during driver bind.
That actually doesn't seem awful to me. It's basically saying that we
are describing pinmux at a device level and not a slot level. It
would make it a pain to dynamically adjust pinmux on a slot-by-slot
basis, but is that a terrible thing?
In the two-slot case you could just do:
pinctrl-0 = sd1_clk sd1_cmd sd1_cd sd2_bus4 sd2_clk sd2_cmd
sd1_cd sd1_bus4;
pinctrl-names = default;
In other words the default state just sets up pin muxing for all the
whole controller (AKA all slots).
...but maybe someone will yell at me for that suggestion. It's really
hard to justify all this extra work for the multiple slot case when
there are no current users that I know of...
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of pinctrl and exynos5250?
Thomas, On Tue, Mar 5, 2013 at 4:01 PM, Thomas Abraham thomas.abra...@linaro.org wrote: So now I have: pinctrl_0 is SPI[46], pinctrl_1 is SPI[45], pinctrl_2 is SPI[50] and pinctrl_3 is SPI[47]. I am yet to test this and confirm. If you feel these are wrong, could you please let me know. Yes, that matches my findings / guesses. ;) Right, I did not pay attention to the bisecting problem. What I have now is, a set of individual patches that migrate i2c, sdhci, dwmmc, i2s, spi and keypad drivers to pinctrl based pin-configuration. In addition to that, two patches that add default pin-state information for Exynos4 and Exynos5 platforms. Since there are multiple drivers involved, is it okay to keep them as separate patches? My own personal opinion is that it's worth keeping bisect working and also a good idea to keep the patches to the individual drivers separate. That would mean adding support for either pinctrl or gpio in the short term (like Linus did for i2c). Once everything is moved over then killing gpio support would be OK by me. I'd feel most strongly about not killing dw_mmc since that is such a critical driver for booting. i2s/spi/keypad are a little less critical and I'd be more OK with them breaking as long as it was clear in the commit message that breakage is expected. I'm a bit of a latecomer to this conversation, though, so I'm not sure my ack / nak holds much weight. If someone else thinks it's more important to kill the old GPIO stuff (or more important to avoid useless churn) then their opinion ought to hold. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of pinctrl and exynos5250?
Linus, +dw_mmc folks and Stephen Warren : for context here, we are discussing device tree bindings for pinmux for dw_mmc. The issue at hand is whether they belong under the slot node or under the top-level device node. On Wed, Mar 6, 2013 at 11:57 PM, Linus Walleij linus.wall...@linaro.org wrote: I don't quite understand the above. Is it such that there is one device, with two slots, and in the device model you have represented this two-slot device with a single struct device? Yes, that's the issue. That's dw_mmc that has been in the kernel for a bit of time now (looks like Jan 2011) and has had a single struct device for as long as I've been looking at it. Relevant links for convenience: * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/dw_mmc.c * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos5250.dtsi#n243 * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/cros5250-common.dtsi#n92 Have you considered just registering one device for each slot? That would make things quite a lot simpler, just a single pinctrl handle per device, right? I don't know why the original decision was made to just have one struct device. ...that would be a pretty big code change at this point, I think. ...I think the most important issue at hand is the device tree bindings for pinmux on this device. It sounds like you are in agreement that the best thing is to have a pinmux specified per-slot. If the code is a bit awkward now (due to not having a struct device per slot) then that's just something we have to live with. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: State of pinctrl and exynos5250?
Linus, On Thu, Mar 7, 2013 at 6:04 PM, Linus Walleij linus.wall...@linaro.org wrote: On Thu, Mar 7, 2013 at 5:13 PM, Doug Anderson diand...@chromium.org wrote: ...I think the most important issue at hand is the device tree bindings for pinmux on this device. It sounds like you are in agreement that the best thing is to have a pinmux specified per-slot. I don't know, Stephen's point to have one single pinctrl set-up for the entire device seems perfectly valid, why do you need to specify it per-slot at all? OK by me. It seemed more pure to specify it per-slot (in case we ever did have a struct device per slot, it would make live easier). ...but it doesn't seem incorrect to have it once for the entire device. :) -Doug P.S. sorry for double mail for some people... -- 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: dts: add pin state information in client nodes for Exynos5 platforms
Thomas,
Thank you for doing this! :)
On Wed, Mar 6, 2013 at 4:36 AM, Thomas Abraham
thomas.abra...@linaro.org wrote:
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 17dd951..434e440 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -35,9 +50,8 @@
*/
dwmmc3@1223 {
slot@0 {
- gpios = gpc4 0 2 0 0, gpc4 1 2 3 0,
- gpc4 3 2 3 0, gpc4 4 2 3 0,
- gpc4 5 2 3 0, gpc4 6 2 3 0;
+ pinctrl-names = default;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
nit: Move comment about EMI to the pinctrl@1140 that you added
earlier in this file. ...then move the pinctrl-names and pinctrl-0 to
cros5250.dtsi. This is not major and could be done in a follow-up
patch.
I done basic testing of this patch series on exynos5250-snow atop
linux-next 20130307. By series I mean these patchwork IDs:
2224531 New mmc: sdhci-s3c: let device core setup the default
pin configuration
2224621 New spi: s3c64xx: let device core setup the default
pin configuration
2224731 New input: samsung-keypad: let device core setup the
default pin configuration
2224801 New ASoC: samsung: let device core setup the default
pin configuration
2224851 New mmc: dwmmc: let device core setup the default pin
configuration
2225141 New [1/2] ARM: dts: add pin state information in
client nodes for Exynos4 platforms
2225151 New [2/2] ARM: dts: add pin state information in
client nodes for Exynos5 platforms
Tested-by: Doug Anderson diand...@chromium.org
This patch looks good to me with or without the above nit fix.
Reviewed-by: Doug Anderson diand...@chromium.org
--
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] spi: s3c64xx: let device core setup the default pin configuration
Thomas, On Wed, Mar 6, 2013 at 3:42 AM, Thomas Abraham thomas.abra...@linaro.org wrote: With device core now able to setup the default pin configuration, the pin configuration code based on the deprecated Samsung specific gpio bindings is removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- .../devicetree/bindings/spi/spi-samsung.txt|8 +-- drivers/spi/spi-s3c64xx.c | 66 +-- 2 files changed, 6 insertions(+), 68 deletions(-) With https://patchwork.kernel.org/patch/2225151/ on exynos5250-snow (ARM Chromebook): Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dwmmc: let device core setup the default pin configuration
Thomas, On Wed, Mar 6, 2013 at 4:04 AM, Thomas Abraham thomas.abra...@linaro.org wrote: With device core now able to setup the default pin configuration, the pin configuration code based on the deprecated Samsung specific gpio bindings is removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- drivers/mmc/host/dw_mmc-exynos.c | 38 -- 1 files changed, 0 insertions(+), 38 deletions(-) It would be good to address Seungwon Jeon's comments (change prefix to dw_mmc and remove setup_bus), but in general this looks good to me, so... With https://patchwork.kernel.org/patch/2225151/ on exynos5250-snow (ARM Chromebook): Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] iio: adc: exynos5_adc: fix compilation warnings
Naveen,
On Wed, Mar 6, 2013 at 7:09 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
- unsigned intversion;
+ unsigned intversion;
Given that you've changed exynos_adc_get_version() to return an int,
shouldn't this be an int too (not unsigned)?
-static inline unsigned int exynos_adc_get_version(struct platform_device
*pdev)
+static inline int exynos_adc_get_version(struct platform_device *pdev)
{
const struct of_device_id *match;
match = of_match_node(exynos_adc_match, pdev-dev.of_node);
- return (unsigned int)match-data;
+ return (int)match-data;
Given that you're now checking for an error code below it seems like
you ought to generate one here. ;)
...AKA: return an error if match is NULL--don't dereference NULL.
static int exynos_read_raw(struct iio_dev *indio_dev,
@@ -117,7 +117,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
long mask)
{
struct exynos_adc *info = iio_priv(indio_dev);
- unsigned long timeout;
+ int timeout;
Why change this to an int when
wait_for_completion_interruptible_timeout() returns a long? I agree
with the removal of the unsigned, though.
+ version = exynos_adc_get_version(pdev);
+ if (version 0) {
+ dev_err(pdev-dev, no matching of_node, err = %d\n,
version);
+ ret = version;
+ goto err_iio;
+ }
+
+ info-version = version;
Optional (and perhaps a matter of preference): I'd eliminate the
version variable here and just re-use ret for storing the result
of exynos_adc_get_version().
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-s5p: Fix phy reset
Alexander,
On Tue, Mar 12, 2013 at 6:09 PM, Alexander Graf ag...@suse.de wrote:
- err = gpio_request_one(gpio, GPIOF_OUT_INIT_HIGH, ehci_vbus_gpio);
- if (err)
+ /* reset pulls the line down, then up again */
+ err = gpio_request_one(gpio, GPIOF_OUT_INIT_LOW, ehci_vbus_gpio);
+ if (err) {
dev_err(pdev-dev, can't request ehci vbus gpio %d, gpio);
+ return;
+ }
+ mdelay(1);
+ __gpio_set_value(gpio, 1);
+ gpio_free(gpio);
Freeing the gpio is a little on the iffy side since you actually care
about keeping the value. Perhaps you can change this to
devm_gpio_request_one() and avoid the free? I was about to submit a
patch to do just that (since otherwise you run into trouble if you
ever defer the probe) but then ran across your patch.
Thanks!
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ehci-s5p: Fix phy reset
Alexander, On Wed, Mar 13, 2013 at 10:45 AM, Alexander Graf ag...@suse.de wrote: + gpio_free(gpio); Freeing the gpio is a little on the iffy side since you actually care about keeping the value. Perhaps you can change this to devm_gpio_request_one() and avoid the free? I was about to submit a patch to do just that (since otherwise you run into trouble if you ever defer the probe) but then ran across your patch. I could also just return it when the function exits and only free it when we exit the probe function with a negative value. The reason I put it in here was that on probe deferral, the pin simply gets blocked. However, I could probably also just completely take the gpio_free() out of this patch and resubmit, as it should be pretty much unrelated. Then you can patch it properly. Sure, if you want to resubmit without the gpio_free() I'll submit a new patch atop yours with the change to devm and people can see if they like it... -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] iio: adc: exynos5_adc: fix compilation warnings
Naveen, On Tue, Mar 12, 2013 at 9:48 PM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: Doug, There was a comment from Lars regarding the match not being NULL, if driver depends on CONFIG_OF. So, i've removed the NULL check in v2 of this patch. https://patchwork.kernel.org/patch/841/ I'm checking the return value of get_version() for -ve values before assigning to info-version. So, i left the (unsigned int) unchanged. Hmmm, I guess this was the point that confused me. I went back and agree with Lars--it can't be NULL. ...but that means that exynos_adc_get_version() can't return an error, so why are we checking for an error? -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] iio: adc: exynos5_adc: fix compilation warnings
Lars, On Wed, Mar 13, 2013 at 11:11 AM, Lars-Peter Clausen l...@metafoo.de wrote: Agreed. Adding the dependency on OF in Kconfig should be all that is needed. I think changing the timeout from 'unsigned long' to 'long' is also legit (to match the actual type returned) and a good idea. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] iio: adc: exynos5_adc: fix compilation warnings
Lars, On Wed, Mar 13, 2013 at 11:40 AM, Lars-Peter Clausen l...@metafoo.de wrote: Yes, but that's a different issue and to be honest I didn't even realize that the patch was trying to fix this as well. In my opinion it's best to split this up into two patches one which fixes the OF dependency. The other fixing the timeout issue. Cause there is more to it than just changing the type. Sounds fair to split into two patches. ;) wait_for_completion_interruptible_timeout() may return 1) 0, if there was a timeout, waiting for the completion 2) 0, if the completion was completeted, the returned value the remaining time. 3) 0, If it was interrupt while waiting for the completion The code currently only handles 1) and 2), but it also needs to handle 3). Since the completion has not been completed in case 3. E.g. something like this should work: if (timeout == 0) return -ETIMEDOUT; else if(timeout 0) return timeout; return 0; Good catch. Yes, that looks right to me. I just saw, there is another issue related to this. The driver should call INIT_COMPLETION(info-completion) before starting the conversion. Otherwise there may be a problem if we got interrupted while waiting for the interrupt. E.g. imagine the following sequence. 1) Start conversion 2) Wait for completion 3) Abort waiting 4) Interrupt kicks in and marks the completion as done Now if another conversion is started the completion will already be completed and wait_for_completion_interruptible_timeout() will return right away without waiting for the conversion to be finished. Another good catch. ...but are you sure that your solution is enough? It seems like we'd also want to lock a spinlock in the ISR and to consider the completion protected by the lock. If we don't do that it seems like you could get an interrupt _right_ after you re-init the completion. Notes: * I thought we could perhaps just disable the interrupt after wait_for_completion_interruptible_timeout() returns, but I'm not sure that's guaranteed to work in a multiprocessor environment. * I don't see any other iio/adc drivers using a spin_lock so maybe there's a better way to do it (or I'm misunderstanding). A quick scan shows only two other iio/adc drivers even use request_irq(). at91_adc.c appears to suffer from similar problems to what we're discussing here (only init the completion in probe). ad_sigma_delta at lest calls INIT_COMPLETION before waiting but seems like it still has a small window of race (I'd have to dig more to be sure). Perhaps someone will tell me that I'm just confused. ;) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: ehci-s5p: Fix phy reset
Alexander, On Wed, Mar 13, 2013 at 4:59 PM, Alexander Graf ag...@suse.de wrote: On my Exynos 5 based Arndale system, I need to pull the reset line down and then let it go up again to actually perform a reset. Without that reset, I can't find any USB hubs on my bus, rendering the USB controller useless. We also only need to reset the line after the phy node has been found. This way we don't accidently reserve the vbus GPIO pin, but later on defer the creation of our controller, because the phy device tree node hasn't been probed yet. This patch implements the above logic, making EHCI and OHCI work on Arndale systems for me. Signed-off-by: Alexander Graf ag...@suse.de CC: Vivek Gautam gautam.vi...@samsung.com CC: Jingoo Han jg1@samsung.com CC: Alan Stern st...@rowland.harvard.edu CC: Kukjin Kim kgene@samsung.com CC: Felipe Balbi ba...@ti.com CC: Greg Kroah-Hartman gre...@linuxfoundation.org CC: Doug Anderson diand...@chromium.org --- v1 - v2: - remove gpio_free call - move reset logic after phy node search Seems fine to me. I guess the earlier problem you wrote about was the probe failure, then? I think that the reason I don't tend to get the probe failure is that I've got my device tree ordered differently so that the phy gets initted in a different order. I'll send up the devm_ patch atop this. Reviewed-by: Doug Anderson diand...@chromium.org Thanks! :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: ehci-s5p: Fix phy reset
Hi, On Thu, Mar 14, 2013 at 7:58 AM, Thomas Abraham thomas.abra...@linaro.org wrote: I can see your point, but as I mentioned earlier there seems to be some timing issue here. By simply doing the reset a few ms earlier (in the first probe, before the driver detects that it needs to defer probing), I already can't find the hub on the bus later. So I'm assuming that the same thing would also happen if I put it even earlier in machine init. True, I missed that point. The usb hub connected over hsic interface, after power-on-reset, might have initiated the 'connect' state on seeing the idle condition on the bus and since the host/phy controller is not ready yet, the connect might have failed. So the correct sequence would be, after the usb host controller and the phy controllers are initialized, the 'reset' pin on the on-board usb hub should be asserted. Upon releasing that reset, the usb hub would initiate the 'connect' state on the HSIC bus. I think we ran into similar issues on one of our boards that had a hub attached to the HSIC port. We had to make our fix in a version of the code that's nowhere near what landed upstream (so our change is not relevant), but we're definitely interested in whatever solution you come up with. :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] iio: adc: Kconfig: exynos_adc depends on CONFIG_OF
Naveen, On Fri, Mar 15, 2013 at 9:23 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: As the exynos_adc driver only supports device tree registration. Making driver depend on CONFIG_OF solves possible errors during probe. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Reported-by: Dan Carpenter dan.carpen...@oracle.com Cc: Doug Anderson diand...@chromium.org Cc: Lars-Peter Clausen l...@metafoo.de --- Discussion thread for this patch can be found at http://www.gossamer-threads.com/lists/linux/kernel/1693284?page=last drivers/iio/adc/Kconfig |1 + 1 file changed, 1 insertion(+) Reviewed-by: Doug Anderson diand...@chromium.org -- 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: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
On Fri, Mar 15, 2013 at 2:53 PM, Lars-Peter Clausen l...@metafoo.de wrote: What exactly is the spinlock protecting against here? Concurrent runs of exynos_adc_isr? This is probably not issue in the first place. What you want to protect against is that completion is completed between the call to INIT_COMPLETION() and the start of a new conversion. So the sections that need to be under the spinlock are the complete call here and the point from INIT_COMPLETION until the transfer is started in exynos_read_raw(). Make sure to use spin_lock_irq there. ...and at that point I _think_ you won't also need the mutex. A reasonable way to test to see if you've got this all correct would be to: * Start two processes that are reading from different ADCs that will report very different values (maybe add a device tree node for adc1 or adc7 and use those since they're not really connected to thermistors?). * Have your two processes read as fast as they can. This could just be while true; do cat /sys/class/hwmon/hwmon0/device/temp1_input; done * Decrease your timeout and maybe(?) sprinkle some random udelays in the irq handler so that the timeouts happen sometimes but not others. * Periodically cancel one of the readers with Ctrl-C If all is working well then you should always get back the right value from the right reader (and get no crashes). -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] These two patches to s3c_pm_arch_prepare_irqs() were part of the work
to make suspend/resume reliable on the ARM Chromebook (exynos5250-snow). A few more details: - The first patch is not strictly needed but was a nice cleanup. Our understanding was that EINT0 was originally turned on for exynos evt0 silicon and not needed for evt1. - The second patch is more important and (also) more obvious. The function was modifying the S5P_WAKEUP_MASK register and then clobbering its own modifications. For some history, see: - https://gerrit.chromium.org/gerrit/31337 - https://gerrit.chromium.org/gerrit/31341 Jonathan Kliegman (2): arm: exynos: Remove hardcode wakeup unmask for EINT_0 arm: exynos: Clear ENABLE_WAKEUP_SW bit when entering suspend arch/arm/mach-exynos/include/mach/pm-core.h | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) -- 1.8.1.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
[PATCH 1/2] arm: exynos: Remove hardcode wakeup unmask for EINT_0
From: Jonathan Kliegman kli...@chromium.org For legacy reasons EINT_0 was being forced on for all exynos systems as a wake interrupt. For boards that need EINT_0 they should probably enable it with enable_irq_wake Signed-off-by: Jonathan Kliegman kli...@chromium.org Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Doug Anderson diand...@chromium.org Reviewed-by: Thomas Abraham thomas...@samsung.com --- arch/arm/mach-exynos/include/mach/pm-core.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-exynos/include/mach/pm-core.h b/arch/arm/mach-exynos/include/mach/pm-core.h index a67ecfa..9d8da51e3 100644 --- a/arch/arm/mach-exynos/include/mach/pm-core.h +++ b/arch/arm/mach-exynos/include/mach/pm-core.h @@ -33,7 +33,7 @@ static inline void s3c_pm_arch_prepare_irqs(void) __raw_writel(tmp, S5P_WAKEUP_MASK); __raw_writel(s3c_irqwake_intmask, S5P_WAKEUP_MASK); - __raw_writel(s3c_irqwake_eintmask 0xFFFE, S5P_EINT_WAKEUP_MASK); + __raw_writel(s3c_irqwake_eintmask, S5P_EINT_WAKEUP_MASK); } static inline void s3c_pm_arch_stop_clocks(void) -- 1.8.1.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
[PATCH 2/2] arm: exynos: Clear ENABLE_WAKEUP_SW bit when entering suspend
From: Jonathan Kliegman kli...@chromium.org
Setting this bit to 0 causes the system to wait until suspended
to use the wakeup masks. With it being set high previously,
masked interrupts were being received and processed before the
EINT_WAKEUP_MASK was configured.
Signed-off-by: Jonathan Kliegman kli...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
---
arch/arm/mach-exynos/include/mach/pm-core.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/pm-core.h
b/arch/arm/mach-exynos/include/mach/pm-core.h
index 9d8da51e3..7dbbfec 100644
--- a/arch/arm/mach-exynos/include/mach/pm-core.h
+++ b/arch/arm/mach-exynos/include/mach/pm-core.h
@@ -27,13 +27,8 @@ static inline void s3c_pm_debug_init_uart(void)
static inline void s3c_pm_arch_prepare_irqs(void)
{
- unsigned int tmp;
- tmp = __raw_readl(S5P_WAKEUP_MASK);
- tmp = ~(1 31);
- __raw_writel(tmp, S5P_WAKEUP_MASK);
-
- __raw_writel(s3c_irqwake_intmask, S5P_WAKEUP_MASK);
__raw_writel(s3c_irqwake_eintmask, S5P_EINT_WAKEUP_MASK);
+ __raw_writel(s3c_irqwake_intmask ~(1 31), S5P_WAKEUP_MASK);
}
static inline void s3c_pm_arch_stop_clocks(void)
--
1.8.1.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
Re: [PATCH] mmc: dwmmc: let device core setup the default pin configuration
Thomas, On Mon, Mar 11, 2013 at 10:53 AM, Doug Anderson diand...@google.com wrote: It would be good to address Seungwon Jeon's comments (change prefix to dw_mmc and remove setup_bus), but in general this looks good to me, so... Are you planning on doing this? I noticed that Chris pulled your sdhci-s3c change in recently but apparently skipped this one since it had outstanding comments. Can you address comments and re-send? This is blocking pinmux dts stuff from landing (I think) and that blocks a lot of other things from landing. The comments are pretty trivial, so I could always fix them and re-send myself, but it would be better if you could do it... :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: dwmmc: let device core setup the default pin configuration
Thomas, On Mon, Mar 25, 2013 at 9:56 AM, Doug Anderson diand...@google.com wrote: Are you planning on doing this? I noticed that Chris pulled your sdhci-s3c change in recently but apparently skipped this one since it had outstanding comments. Can you address comments and re-send? This is blocking pinmux dts stuff from landing (I think) and that blocks a lot of other things from landing. The comments are pretty trivial, so I could always fix them and re-send myself, but it would be better if you could do it... :) I didn't hear anything last week and it's getting pretty late in the process. I'll post something tomorrow if I don't hear from you... -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mmc: dwmmc: let device core setup the default pin configuration
Thomas, On Mon, Apr 1, 2013 at 11:09 PM, Thomas Abraham thomas.abra...@linaro.org wrote: With device core now able to setup the default pin configuration, the pin configuration code based on the deprecated Samsung specific gpio bindings is removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org Acked-by: Linus Walleij linus.wall...@linaro.org Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org You missed Seungwon's other feedback. Please change the title from mmc: dwmmc: let device core setup the default pin configuration to mmc: dw_mmc: let device core setup the default pin configuration. He requested that the tag have the underscore in it for consistency. If you're resending, it also seems like it might be nice to rebase this atop: 0f6e73d mmc: dw_mmc: Add MSHC compatible for Exynos4412 ...just to avoid the simple merge conflict when applying? Otherwise everything here looks great... -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Lars, On Sat, Mar 16, 2013 at 7:41 AM, Lars-Peter Clausen l...@metafoo.de wrote: I think you still need the mutex for serialization, otherwise the requests would just cancel each other out. Btw. what happens if you start a conversion while another is still in progress? Is it possible to abort a conversion? I was thinking that the spinlock would just replace the mutex for the purposes of serialization. I stepped back a bit, though, and I'm wondering if we're over-thinking things. The timeout case should certainly be handled properly (thanks for pointing it out), but getting a timeout is really not expected and adding a lot of extra overhead to handle it elegantly seems a bit much? Specifically, the mutex means that we have one user of the ADC at a time, and ADC conversion has nothing variable about it. The user manual that I have access to talks about 12-bit conversion happening in 1 microsecond with a 5MHz input clock or 5 microseconds with a 1MHz input clock. Even if someone has clocks configured very differently, it would be hard to imagine a conversion actually taking a full second. ...so that means that if the timeout actually fires then something else fairly drastic has gone wrong. It's _very_ unlikely that the IRQ will still go off for this conversion sometime in the future. To me, total modifications to what's landed already ought to be: * Change timeout to long (from unsigned long) * Make sure we return errors (negative results) from wait_for_completion_interruptible_timeout() properly. * If we get back a value of 0 from wait_for_completion_interruptible_timeout() then we should print a warning and attempt machinations to reset the ADC. Without ever seeing real-world situtations that would cause a real timeout these machinations would be a bit of a guess (is resetting the adc useful when it's more likely that someone accidentally messed with the clock tree or power gated the ADC?)... ...or perhaps a warning and a TODO in the code would be enough? Thoughts? -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] These two patches to s3c_pm_arch_prepare_irqs() were part of the work
Kukjin, On Tue, Apr 2, 2013 at 7:16 PM, Kukjin Kim kgene@samsung.com wrote: Applied with 1st one, BTW, do you want to send this for stable tree? I don't have any need for it to be in stable tree. The ARM Chromebook hasn't reached critical functionality on any released/upstram Linux versions so it doesn't make much sense to backport fixes. If someone else wants it in stable (and can confirm that it helps them) then I certainly wouldn't object! One more note, just now I discussed Jaecheol Lee about the bit, ENABLE_WAKEUP_SW, as the patch fixed, it should be cleared but used to be set s3c_irqwake_intmask. Let me check again, then if any updates I'll let you know. OK, thanks. If there is a reason that ENABLE_WAKEUP_SW needs to be set then it would be good to understand that case. :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: PATCH 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Lars, On Fri, Apr 5, 2013 at 1:53 AM, Lars-Peter Clausen l...@metafoo.de wrote: Since we sleep inside the protected section we need to use a mutex. Ah, good point. It's not the timeout case I'm worried about, but the case where the transfer is interrupted by the user. Even though it is rather unlikely for the problem to occur we should still try to avoid it, this is one of these annoying heisenbugs that happen once in a while and nobody is able to reproduce them. Yes, of course. Then we can also get extra confidence that the reset logic works well by stressing out this case... :) This makes me think, though. Given how fast we expect the ADC transaction to finish, would there be any benefit to making the wait non-interruptible and then shortening the timeout a whole lot. If we shortened to 1ms then we're really not non-interruptible for very long and there's less chance of subtle bugs in the way that reset works. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mmc: dw_mmc: let device core setup the default pin configuration
Thomas, Since I commented on previous versions of this patch, I would have loved to have been CCed on this new version. ;) On Fri, Apr 5, 2013 at 6:53 AM, Thomas Abraham thomas.abra...@linaro.org wrote: With device core now able to setup the default pin configuration, the pin configuration code based on the deprecated Samsung specific gpio bindings is removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- Changes since v2: - Changed patch subject from mmc: dwmmc: let... to mmc: dw_mmc: let... - Rebased to Chris's latest mmc-next branch. drivers/mmc/host/dw_mmc-exynos.c | 38 -- drivers/mmc/host/dw_mmc.c| 12 ++-- drivers/mmc/host/dw_mmc.h|3 --- 3 files changed, 2 insertions(+), 51 deletions(-) This patch applies fine but fails to compile on linux-next next-20130408. You lost the race with: f2f942c mmc: dw_mmc: Check return value of regulator_enable ...that patch adds a goto err_setup_bus and you've renamed that label. I guess you get another fun rebase. NOTE: this patch is even more urgent than it was before. It looks like pincontrol stuff has now landed in linux-next which means that Exynos5 devices that need eMMC/SD will no longer boot until this patch goes in. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts
The display timing node was added:
7ed2077 ARM: dts: Add display timing node to exynos5250-smdk5250.dts
...and looks OK there. ...but it looks like we lost a }; in the
merge and it no longer compiles. Fix it.
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 4be14df..26d856b 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -239,6 +239,7 @@
vback-porch = 4;
vfront-porch = 4;
vsync-len = 4;
+ };
};
fixed-rate-clocks {
--
1.8.1.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
[PATCH] ARM: dts: Disable the RTC by default on exynos5
This change makes the rtc on the exynos5250 and 5440 disabled by
default to match exynos4.
Ever since the common clock framework came in came in, exynos5250
boards have dumped lots of warnings in the boot log. It turns out
that we don't see those on exynos4 since the rtc is disabled by
default. While we need to get to the bottom of the problems with the
RTC, it still makes sense to have the default state of the RTC on
exynos boards match.
For the record, warnings look like this:
[ cut here ]
WARNING: at /.../drivers/clk/clk.c:771 __clk_enable+0x34/0xb0()
Modules linked in:
[80015bfc] (unwind_backtrace+0x0/0xec) from [804717f0]
(dump_stack+0x20/0x24)
[804717f0] (dump_stack+0x20/0x24) from [80023cd0]
(warn_slowpath_common+0x5c/0x7c)
[80023cd0] (warn_slowpath_common+0x5c/0x7c) from [80023d1c]
(warn_slowpath_null+0x2c/0x34)
[80023d1c] (warn_slowpath_null+0x2c/0x34) from [8035ddb0]
(__clk_enable+0x34/0xb0)
[8035ddb0] (__clk_enable+0x34/0xb0) from [8035de54] (clk_enable+0x28/0x3c)
[8035de54] (clk_enable+0x28/0x3c) from [8031a160]
(s3c_rtc_probe+0xf4/0x434)
[8031a160] (s3c_rtc_probe+0xf4/0x434) from [8028e288]
(platform_drv_probe+0x24/0x28)
[8028e288] (platform_drv_probe+0x24/0x28) from [8028ce10]
(driver_probe_device+0xbc/0x22c)
[8028ce10] (driver_probe_device+0xbc/0x22c) from [8028cff8]
(__driver_attach+0x78/0x9c)
[8028cff8] (__driver_attach+0x78/0x9c) from [8028bdfc]
(bus_for_each_dev+0x64/0xac)
[8028bdfc] (bus_for_each_dev+0x64/0xac) from [8028c7e0]
(driver_attach+0x28/0x30)
[8028c7e0] (driver_attach+0x28/0x30) from [8028c43c]
(bus_add_driver+0xe0/0x234)
[8028c43c] (bus_add_driver+0xe0/0x234) from [8028d55c]
(driver_register+0xac/0x13c)
[8028d55c] (driver_register+0xac/0x13c) from [8028e4f4]
(platform_driver_register+0x54/0x68)
[8028e4f4] (platform_driver_register+0x54/0x68) from [8065c944]
(s3c_rtc_driver_init+0x14/0x1c)
[8065c944] (s3c_rtc_driver_init+0x14/0x1c) from [800086d8]
(do_one_initcall+0x60/0x138)
[800086d8] (do_one_initcall+0x60/0x138) from [80633a8c]
(kernel_init_freeable+0x108/0x1d0)
[80633a8c] (kernel_init_freeable+0x108/0x1d0) from [8046d2f8]
(kernel_init+0x1c/0xf4)
[8046d2f8] (kernel_init+0x1c/0xf4) from [8000e358]
(ret_from_fork+0x14/0x20)
---[ end trace 4bcdc801c868d73f ]---
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/exynos5250.dtsi | 1 +
arch/arm/boot/dts/exynos5440.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index dc55e33..892b724 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -183,6 +183,7 @@
interrupts = 0 43 0, 0 44 0;
clocks = clock 337;
clock-names = rtc;
+ status = disabled;
};
tmu@1006 {
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 25c6134..a8ceef4 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -181,5 +181,6 @@
interrupts = 0 17 0, 0 16 0;
clocks = clock 21;
clock-names = rtc;
+ status = disabled;
};
};
--
1.8.1.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
Re: [PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts
Kukjin, On Mon, Apr 8, 2013 at 11:23 AM, Kukjin Kim kgene@samsung.com wrote: Thanks for your pointing out. But it should be fixed with re-sorting out the branch. No problem with however you want to solve it. ;) Seemed that the patch was the easiest way to report the problem in any case... -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts
Kukjin, On Mon, Apr 8, 2013 at 11:29 AM, Kukjin Kim kgene@gmail.com wrote: BTW, if any problems on current for-next, please kindly let me know. I usually try to check linux-next at least once a week, but sometimes it's more or less often. At the moment I'm trying to track something weird down but it seems like it has some userspace component to it. I'll post a separate thread if I find a kernel problem there. Aside from the RTC, my biggest problem right now is that reboot stopped working at the same time as the common clock. The exynos5_restart() function is essentially behaving as a no-op since the clock to the IP block that handles reset has been gated. :( The bit CLK_PMU_APBIF is gated in CLK_GATE_IP_PERIS. This used to be ungated in exynos5_clk_ip_peris_ctrl(). I'm happy to test a patch that fixes this but I haven't yet had time to try to fix it cleanly myself. -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts
Tomasz, On Mon, Apr 8, 2013 at 12:27 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Common Clock Framework by default automatically gates unused clocks, just like regulator core does with unused regulators. Maybe this is the cause? Yes, I'm nearly certain that's the case here. The reset code doesn't belong to any driver (it's in mach-exynos/common.c) it certainly doesn't grab any clock. I tried quickly to see if there was an easy clock to grab but got a bit stuck. In the old way of doing things clocks could be global and grabbed without a dev node. That may still be possible now, but in the 15 minutes I spent I couldn't figure it out and so it went to the back burner. ...or we could make a real reset device, but that might be overkill? There is a CLK_IGNORE_UNUSED flag which disables this behavior for all clocks which have it set. Maybe it should be set for the problematic clock? Didn't know about that one, thanks! It seems like a bit annoying that we'd have to keep this clock all the time just to get reset working, though. I guess in 3.4 that's what we did, though I don't know if it was intentional... -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mmc: dw_mmc: let device core setup the default pin configuration
Thomas,
On Mon, Apr 8, 2013 at 10:59 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
@@ -2002,7 +1994,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
if (ret) {
dev_err(host-dev,
failed to enable regulator: %d\n, ret);
- goto err_setup_bus;
+ return ret;
It seems like you'd need a mmc_free_host(mmc); in this case don't
you? AKA: this should be a goto and not a return.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
