Re: [PATCH 1/2] ARM: EXYNOS: Add EHCI AHB burst function

[Thomas Abraham]

Hi Sangwook,

On 29 February 2012 18:11, Sangwook Lee  wrote:
> Enable burst transfer from AHB for EHCI.
> This fixes data transfer of USB Ethernet with EHCI.
> Without this patch, scp hardly works.
>
> Signed-off-by: Sangwook Lee 
> ---
>  arch/arm/mach-exynos/setup-usb-phy.c      |    6 ++
>  arch/arm/plat-samsung/devs.c              |    2 ++
>  arch/arm/plat-samsung/include/plat/ehci.h |   19 +++
>  3 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/setup-usb-phy.c 
> b/arch/arm/mach-exynos/setup-usb-phy.c
> index 41743d2..5a20460 100644
> --- a/arch/arm/mach-exynos/setup-usb-phy.c
> +++ b/arch/arm/mach-exynos/setup-usb-phy.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static atomic_t host_usage;
>
> @@ -149,3 +150,8 @@ int s5p_usb_phy_exit(struct platform_device *pdev, int 
> type)
>
>        return -EINVAL;
>  }
> +
> +void s5p_ehci_burst_enable(struct platform_device *pdev, void __iomem *base)
> +{
> +       writel(EHCI_INSNREG00_ENABLE_BURST, base + EHCI_INSNREG00);
> +}

This functionality can be added in ehci-s5p itself and avoid adding a
new platform callback in platform data. If this is specific to exynos,
driver data could be added in ehci-s5p to indicate platforms that need
this to be enabled.

Thanks,
Thomas.

[...]

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v2 1/2] ARM: EXYNOS: Add USB HOST register definitions

[Thomas Abraham]

On 1 March 2012 21:40, Sangwook Lee  wrote:
[...]

>  I found out some code related to this burst function.
>
>  the snip from ehci-s5pv210.c, 2.6.35 kernel
>
>     /* Mark hardware accessible again as we are out of D3 state by now
> */
>     set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> #if defined(CONFIG_ARCH_S5PV210) || defined(CONFIG_ARCH_S5P6450)
>     ehci_writel(ehci, 0x000F, (void __iomem *)ehci->caps + 0x90);
> #endif
>
> #if defined(CONFIG_ARCH_S5PV310)
>     ehci_writel(ehci, 0x03C0, (void __iomem *)ehci->caps + 0x90);
> #endif
>     if (ehci_readl(ehci, &ehci->regs->configured_flag) == FLAG_CF) {
>
> From this code, this burst function seems to be depending on CPUs,
> The driver by itself is not good idea because echi-s5p.c will have defined.
>
> Which is the better place to pus this CPU specific definition either
> drivers/usb/host/ehci-s5p.h is
> or mach/xx.h or  include/linux/usb/xxx.h ?  I am not clear about this.

Any configuration that is controller specific should be in the driver.
If that configuration has a SoC specific behavior, a id_table can be
provided to the platform_driver which can provide any SoC specific
information. The samsung keypad driver is an example of how this can
be handled (drivers/input/keyboard/samsung.c).

Thanks,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 0/6] Add basic device tree support for Samsung's Exynos4 platform

[Thomas Abraham]

This patch series adds a basic device tree based boot for Samsung's Exynos4
platforms and specifically for smdkv310 board. Device tree based driver
probe is added for uart, sdhci and watchdog drivers. These patches
enable booting to console on smdkv310 board with some of the devices
initialized with data from the device tree.

This patch series is based on
git.secretlab.ca/git/linux-2.6.git devicetree/test

and depends on the following patches which are not yet available in
the devicetree/test branch.

1. [PATCH] ARM: EXYNOS4: Fix card detection for sdhci 0 and 2
[http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04704.html]

2. [PATCH] ARM: EXYNOS4: Fix missing S5P_VA_AUDSS definition
[http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04866.html]

3. [PATCH 0/9] Add clkdev support for Samsung platforms
[http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04874.html]

4. Consolidate the clkdev header files
[http://patchwork.ozlabs.org/patch/97862/]

Thomas Abraham (6):
  serial: samsung: Keep a copy of platform data in driver's private data
  serial: samsung: Add device tree support for s5pv210 uart driver
  watchdog: s3c2410: Add support for device tree based probe
  mmc: sdhci-s3c: Add support for device tree based probe
  arm: dts: Add nodes in smdkv310 device tree source file
  arm: exynos4: Add a new Exynos4 device tree enabled machine

 Documentation/devicetree/bindings/arm/samsung.txt  |3 +-
 .../bindings/tty/serial/samsung_uart.txt   |   50 +++
 .../devicetree/bindings/watchdog/samsung-wdt.txt   |   12 ++
 arch/arm/boot/dts/exynos4-smdkv310.dts |  135 +++-
 arch/arm/mach-exynos4/Kconfig  |   11 ++
 arch/arm/mach-exynos4/Makefile |1 +
 arch/arm/mach-exynos4/mach-exynos4-dt.c|   94 ++
 drivers/mmc/host/sdhci-s3c.c   |   11 ++
 drivers/tty/serial/s5pv210.c   |   39 +-
 drivers/tty/serial/samsung.c   |  114 -
 drivers/tty/serial/samsung.h   |4 +-
 drivers/watchdog/s3c2410_wdt.c |   10 ++
 12 files changed, 473 insertions(+), 11 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/tty/serial/samsung_uart.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
 create mode 100644 arch/arm/mach-exynos4/mach-exynos4-dt.c


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 3/6] watchdog: s3c2410: Add support for device tree based probe

[Thomas Abraham]

This patch adds the of_match_table to enable s3c2410-wdt driver
to be probed when watchdog device node is found in the device tree.

Signed-off-by: Thomas Abraham 
---
 .../devicetree/bindings/watchdog/samsung-wdt.txt   |   12 
 drivers/watchdog/s3c2410_wdt.c |   10 ++
 2 files changed, 22 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/watchdog/samsung-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
new file mode 100644
index 000..f2617e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -0,0 +1,12 @@
+* Samsung's Watchdog Timer Controller
+
+The Samsung's Watchdog controller is used for resuming system operation
+after a preset amount of time during which the WDT reset event has not
+occured.
+
+Required properties:
+- compatible : should be "samsung,s3c2410-wdt"
+- reg : base physical address of the controller and length of memory mapped
+   region.
+- interrupts : interrupt number to the cpu.
+
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index f7f5aa0..30da88f 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -589,6 +589,15 @@ static int s3c2410wdt_resume(struct platform_device *dev)
 #define s3c2410wdt_resume  NULL
 #endif /* CONFIG_PM */
 
+#ifdef CONFIG_OF
+static const struct of_device_id s3c2410_wdt_match[] = {
+   { .compatible = "samsung,s3c2410-wdt" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
+#else
+#define s3c2410_wdt_match NULL
+#endif
 
 static struct platform_driver s3c2410wdt_driver = {
.probe  = s3c2410wdt_probe,
@@ -599,6 +608,7 @@ static struct platform_driver s3c2410wdt_driver = {
.driver = {
.owner  = THIS_MODULE,
.name   = "s3c2410-wdt",
+   .of_match_table = s3c2410_wdt_match,
},
 };
 
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 4/6] mmc: sdhci-s3c: Add support for device tree based probe

[Thomas Abraham]

Add of_match_table to enable sdhci-s3c driver to be probed when a compatible
sdhci device node is found in device tree.

Signed-off-by: Thomas Abraham 
---
This is temporary patch. sdhci-s3c driver has to be moved to sdhci-pltfm
based driver.

 drivers/mmc/host/sdhci-s3c.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 69e3ee3..5ccbee0 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -629,6 +629,16 @@ static int sdhci_s3c_resume(struct platform_device *dev)
 #define sdhci_s3c_resume NULL
 #endif
 
+#ifdef CONFIG_OF
+static const struct of_device_id s3c_sdhci_match[] = {
+   { .compatible = "samsung,s3c-sdhci" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, s3c_sdhci_match);
+#else
+#define s3c_sdhci_match NULL
+#endif
+
 static struct platform_driver sdhci_s3c_driver = {
.probe  = sdhci_s3c_probe,
.remove = __devexit_p(sdhci_s3c_remove),
@@ -637,6 +647,7 @@ static struct platform_driver sdhci_s3c_driver = {
.driver = {
.owner  = THIS_MODULE,
.name   = "s3c-sdhci",
+   .of_match_table = s3c_sdhci_match,
},
 };
 
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 2/6] serial: samsung: Add device tree support for s5pv210 uart driver

[Thomas Abraham]

For device tree based probe, the dependecy on pdev->id to attach a
corresponding default port info to the driver's private data is
removed. The fifosize parameter is obtained from the device tree
node and the next available instance of port info is updated
with the fifosize value and attached to the driver's private data.

The samsung uart core driver is also modified to parse the device
tree node and pick up the platform data from the node.

Signed-off-by: Thomas Abraham 
---
 .../bindings/tty/serial/samsung_uart.txt   |   50 +++
 drivers/tty/serial/s5pv210.c   |   27 ++-
 drivers/tty/serial/samsung.c   |   90 
 3 files changed, 166 insertions(+), 1 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/tty/serial/samsung_uart.txt

diff --git a/Documentation/devicetree/bindings/tty/serial/samsung_uart.txt 
b/Documentation/devicetree/bindings/tty/serial/samsung_uart.txt
new file mode 100644
index 000..4c0783d
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/samsung_uart.txt
@@ -0,0 +1,50 @@
+* Samsung's UART Controller
+
+The Samsung's UART controller is used for serial communications on all of
+Samsung's s3c24xx, s3c64xx and s5p series application processors.
+
+Required properties:
+- compatible : should be specific to the application processor
+   - "samsung,s5pv210-uart" , for s5pc110, s5pv210 and Exynos4 family.
+   - "samsung,s3c6400-uart", for s3c64xx, s5p64xx and s5pc100.
+   - "samsung,s3c2410-uart", for s3c2410.
+   - "samsung,s3c2412-uart", for s3c2412.
+   - "samsung,s3c2440-uart", for s3c244x.
+
+- reg :base physical address of the controller and length of memory 
mapped
+   region.
+
+- interrupts : Three interrupt numbers should be specified in the following
+   order - TX interrupt, RX interrupt, Error Interrupt.
+
+- hwport : Instance number of the UART controller in the processor.
+   (ToDo: Remove this from the driver).
+
+- flags : Not used, but set value as 0. (ToDo: Remove this flag from driver).
+
+- uart_flags : Additional serial core flags to passed to the serial core
+   when the driver is registred. For example: UPF_CONS_FLOW.
+
+- has_fracval : Set to 1, if the controller supports fractional part of
+   for the baud divisor, otherwise, set to 0.
+
+- ucon_default : Default board specific setting of UCON register.
+
+- ulcon_default : Default board specific setting of ULCON register.
+
+- ufcon_default : Default board specific setting of UFCON register.
+
+- uart_clksrc : One or more child nodes representing the clock sources that
+   could be used to derive the buad rate. Each of these child nodes
+   has four required properties.
+
+   - name : Name of the parent clock.
+   - divisor : divisor from the clock to the uart controller.
+   - min_baud : Minimum baud rate for which this clock can be used.
+   Set to zero, if there is no limitation.
+   - max_buad : Maximum baud rate for which this clock can be used.
+   Set to zero, if there is no limitation.
+
+Optional properties:
+- fifosize: Size of the tx/rx fifo used in the controller. If not specified,
+   the default value of the fifosize is 16.
diff --git a/drivers/tty/serial/s5pv210.c b/drivers/tty/serial/s5pv210.c
index 3b2021a..9aacbda 100644
--- a/drivers/tty/serial/s5pv210.c
+++ b/drivers/tty/serial/s5pv210.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -131,15 +132,39 @@ static struct s3c24xx_uart_info *s5p_uart_inf[] = {
 /* device management */
 static int s5p_serial_probe(struct platform_device *pdev)
 {
-   return s3c24xx_serial_probe(pdev, s5p_uart_inf[pdev->id]);
+   const void *prop;
+   unsigned int port = pdev->id;
+   unsigned int fifosize = 16;
+   static unsigned int probe_index;
+
+   if (pdev->dev.of_node) {
+   prop = of_get_property(pdev->dev.of_node, "fifosize", NULL);
+   if (prop)
+   fifosize = be32_to_cpu(*(u32 *)prop);
+   s5p_uart_inf[probe_index]->fifosize = fifosize;
+   port = probe_index++;
+   }
+
+   return s3c24xx_serial_probe(pdev, s5p_uart_inf[port]);
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id s5pv210_uart_match[] = {
+   { .compatible = "samsung,s5pv210-uart" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, s5pv210_uart_match);
+#else
+#define s5pv210_uart_match NULL
+#endif
+
 static struct platform_driver s5p_serial_driver = {
.probe  = s5p_serial_probe,
.remove = __devexit_p(s3c24xx_serial_remove),
.driver = {
.name   = "s5pv210-uart",
.owner  = THIS_MODULE,
+   .of_match_table = s5pv210_u

[PATCH 5/6] arm: dts: Add nodes in smdkv310 device tree source file

[Thomas Abraham]

Include device tree nodes for watchdog timer, sdhci instance 0 and 1,
and uart instances 0 to 3.

Signed-off-by: Thomas Abraham 
---
 arch/arm/boot/dts/exynos4-smdkv310.dts |  135 +++-
 1 files changed, 133 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4-smdkv310.dts 
b/arch/arm/boot/dts/exynos4-smdkv310.dts
index dd6c80a..721563f 100644
--- a/arch/arm/boot/dts/exynos4-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4-smdkv310.dts
@@ -1,11 +1,142 @@
+/*
+ * Samsung's Exynos4 based smdkv310 board device tree source.
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ * www.linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
 /dts-v1/;
 /include/ "skeleton.dtsi"
 
 / {
model = "Samsung Exynos4 SMDKV310 eval board";
-   compatible = "samsung,smdkv310", "samsung,s5pv310";
+   compatible = "samsung,smdkv310", "samsung,s5pv310", 
"samsung,exynos4210";
 
memory {
-   reg = <0x4000 0x0800>;
+   reg = <0x4000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "root=/dev/mmcblk0p1 rootfstype=ext3 rootwait 
console=ttySAC1,115200";
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <&intc>;
+   compatible = "simple-bus";
+   ranges;
+
+   intc:interrupt-controller@0x10501000 {
+   compatible = "samsung,exynos4-gic","arm,cortex-a9-gic";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   reg = <0x10501000 0x1000>, <0x10500100 0x100>;
+   irq-start = <61>;
+   };
+
+   watchdog@0x1006 {
+   compatible = "samsung,s3c2410-wdt";
+   reg = <0x1006 0x400>;
+   interrupts = <552>;
+   };
+
+   sdhci@0x1253 {
+   compatible = "samsung,s3c-sdhci";
+   reg = <0x1253 0x1000>;
+   interrupts = <362>;
+   };
+
+   sdhci@0x1251 {
+   compatible = "samsung,s3c-sdhci";
+   reg = <0x1251 0x1000>;
+   interrupts = <360>;
+   };
+
+   serial@0x1380 {
+   compatible = "samsung,s5pv210-uart";
+   reg = <0x1380 0x100>;
+   interrupts = <16 18 17>;
+   fifosize = <256>;
+   hwport = <0>;
+   flags = <0>;
+   uart_flags = <0>;
+   has_fracval = <1>;
+   ucon_default = <0x3c5>;
+   ulcon_default = <0x3>;
+   ufcon_default = <0x111>;
+   uart_clksrc0 {
+   clk_name = "uclk1";
+   divisor = <1>;
+   min_baud = <0>;
+   max_baud = <0>;
+   };
+   };
+
+   serial@0x1381 {
+   compatible = "samsung,s5pv210-uart";
+   reg = <0x1381 0x100>;
+   interrupts = <20 22 21>;
+   fifosize = <64>;
+   hwport = <1>;
+   flags = <0>;
+   uart_flags = <0>;
+   has_fracval = <1>;
+   ucon_default = <0x3c5>;
+   ulcon_default = <0x3>;
+   ufcon_default = <0x111>;
+   uart_clksrc0 {
+   clk_name = "uclk1";
+   divisor = <1>;
+   min_baud = <0>;
+   max_baud = <0>;
+   };
+   };
+
+   serial@0x1382 {
+   compatible = "samsung,s5pv210-uart";
+   reg = <0x1382 0x100>;
+   interrupts = <24 26 25>;
+   fifosize = <16>;
+  

[PATCH 1/6] serial: samsung: Keep a copy of platform data in driver's private data

[Thomas Abraham]

The driver depends on pdev->dev.platform_data to retrive information
about the platform data even after the initialization. To add device
tree support, this has to be changed in way that the platform data
is avialable from driver's private data. This patch adds support
for keeping a copy of the plaform data in s3c24xx_uart_info and using
it when needed after the initialization.

Signed-off-by: Thomas Abraham 
---
 drivers/tty/serial/s5pv210.c |   12 ++--
 drivers/tty/serial/samsung.c |   24 
 drivers/tty/serial/samsung.h |4 +++-
 3 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/s5pv210.c b/drivers/tty/serial/s5pv210.c
index d6b2423..3b2021a 100644
--- a/drivers/tty/serial/s5pv210.c
+++ b/drivers/tty/serial/s5pv210.c
@@ -27,9 +27,13 @@
 static int s5pv210_serial_setsource(struct uart_port *port,
struct s3c24xx_uart_clksrc *clk)
 {
-   struct s3c2410_uartcfg *cfg = port->dev->platform_data;
+   struct s3c24xx_uart_port *ourport;
+   struct s3c2410_uartcfg *cfg;
unsigned long ucon = rd_regl(port, S3C2410_UCON);
 
+   ourport = container_of(port, struct s3c24xx_uart_port, port);
+   cfg = &ourport->info->cfg;
+
if ((cfg->clocks_size) == 1)
return 0;
 
@@ -50,9 +54,13 @@ static int s5pv210_serial_setsource(struct uart_port *port,
 static int s5pv210_serial_getsource(struct uart_port *port,
struct s3c24xx_uart_clksrc *clk)
 {
-   struct s3c2410_uartcfg *cfg = port->dev->platform_data;
+   struct s3c24xx_uart_port *ourport;
+   struct s3c2410_uartcfg *cfg;
u32 ucon = rd_regl(port, S3C2410_UCON);
 
+   ourport = container_of(port, struct s3c24xx_uart_port, port);
+   cfg = &ourport->info->cfg;
+
clk->divisor = 1;
 
if ((cfg->clocks_size) == 1)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 7ead421..77d900f 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -169,10 +170,13 @@ static inline struct s3c24xx_uart_info 
*s3c24xx_port_to_info(struct uart_port *p
 
 static inline struct s3c2410_uartcfg *s3c24xx_port_to_cfg(struct uart_port 
*port)
 {
+   struct s3c24xx_uart_port *ourport;
+
if (port->dev == NULL)
return NULL;
 
-   return (struct s3c2410_uartcfg *)port->dev->platform_data;
+   ourport = container_of(port, struct s3c24xx_uart_port, port);
+   return &ourport->info->cfg;
 }
 
 static int s3c24xx_serial_rx_fifocnt(struct s3c24xx_uart_port *ourport,
@@ -1053,7 +1057,7 @@ static int s3c24xx_serial_init_port(struct 
s3c24xx_uart_port *ourport,
struct platform_device *platdev)
 {
struct uart_port *port = &ourport->port;
-   struct s3c2410_uartcfg *cfg;
+   struct s3c2410_uartcfg *cfg = platdev->dev.platform_data;
struct resource *res;
int ret;
 
@@ -1062,14 +1066,24 @@ static int s3c24xx_serial_init_port(struct 
s3c24xx_uart_port *ourport,
if (platdev == NULL)
return -ENODEV;
 
-   cfg = s3c24xx_dev_to_cfg(&platdev->dev);
-
if (port->mapbase != 0)
return 0;
 
+   if (cfg) {
+   memcpy((void *)&info->cfg, cfg, sizeof(struct s3c2410_uartcfg));
+   info->cfg.clocks = kzalloc(sizeof(struct s3c24xx_uart_clksrc) *
+   cfg->clocks_size, GFP_KERNEL);
+   if (!info->cfg.clocks)
+   return -ENOMEM;
+   memcpy(info->cfg.clocks, cfg->clocks,
+   sizeof(struct s3c24xx_uart_clksrc) * cfg->clocks_size);
+   }
+
+   cfg = &info->cfg;
if (cfg->hwport > CONFIG_SERIAL_SAMSUNG_UARTS) {
printk(KERN_ERR "%s: port %d bigger than %d\n", __func__,
   cfg->hwport, CONFIG_SERIAL_SAMSUNG_UARTS);
+   kfree(info->cfg.clocks);
return -ERANGE;
}
 
@@ -1181,11 +1195,13 @@ EXPORT_SYMBOL_GPL(s3c24xx_serial_probe);
 int __devexit s3c24xx_serial_remove(struct platform_device *dev)
 {
struct uart_port *port = s3c24xx_dev_to_port(&dev->dev);
+   struct s3c24xx_uart_info *info = s3c24xx_port_to_info(port);
 
if (port) {
s3c24xx_serial_cpufreq_deregister(to_ourport(port));
device_remove_file(&dev->dev, &dev_attr_clock_source);
uart_remove_one_port(&s3c24xx_uart_drv, port);
+   kfree(info->cfg.clocks);
}
 
return 0;
diff --git a/drivers/tty/serial/samsung.h b/drivers/tty/serial/samsung.h
index a69d9a5..4f2f6f5 100644
--- a/drivers/tty/serial/samsun

[PATCH 6/6] arm: exynos4: Add a new Exynos4 device tree enabled machine

[Thomas Abraham]

Basic Exynos4 machine with device tree support that can boot on a Exynos4
based smdkv310 board and bring up the console.

Signed-off-by: Thomas Abraham 
---
 Documentation/devicetree/bindings/arm/samsung.txt |3 +-
 arch/arm/mach-exynos4/Kconfig |   11 +++
 arch/arm/mach-exynos4/Makefile|1 +
 arch/arm/mach-exynos4/mach-exynos4-dt.c   |   94 +
 4 files changed, 108 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-exynos4/mach-exynos4-dt.c

diff --git a/Documentation/devicetree/bindings/arm/samsung.txt 
b/Documentation/devicetree/bindings/arm/samsung.txt
index 594cb97..80d29bb 100644
--- a/Documentation/devicetree/bindings/arm/samsung.txt
+++ b/Documentation/devicetree/bindings/arm/samsung.txt
@@ -4,6 +4,7 @@ Samsung Exynos4 S5PV310 SoC based SMDKV310 eval board
 Samsung's Exynos4 family of application processors.
 
 Required root node properties:
-- compatible = "samsung,smdkv310","samsung,s5pv310"
+- compatible = "samsung,smdkv310","samsung,s5pv310", "samsung,exynos4210'.
 (a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
 (b) "samsung,s5pv310"  - for boards based on S5PV310 SoC.
+   (c) "samsung,exynos4210" - for boards based on Exynos4210 processor.
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 1435fc3..412e0c5 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -186,6 +186,17 @@ config MACH_NURI
help
  Machine support for Samsung Mobile NURI Board.
 
+config MACH_EXYNOS4_DT
+   bool "Samsung's Exynos4 Machine with DT support"
+   select CPU_EXYNOS4210
+   select USE_OF
+   select S3C_DEV_WDT
+   select S3C_DEV_HSMMC
+   select S3C_DEV_HSMMC2
+   select EXYNOS4_SETUP_SDHCI
+   help
+ Machine support for Samsung Exynos4 machine with device tree enabled.
+
 endmenu
 
 comment "Configuration for HSMMC bus width"
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 60fe5ec..6491e5b 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_MACH_SMDKV310)   += mach-smdkv310.o
 obj-$(CONFIG_MACH_ARMLEX4210)  += mach-armlex4210.o
 obj-$(CONFIG_MACH_UNIVERSAL_C210)  += mach-universal_c210.o
 obj-$(CONFIG_MACH_NURI)+= mach-nuri.o
+obj-$(CONFIG_MACH_EXYNOS4_DT)  += mach-exynos4-dt.o
 
 # device support
 
diff --git a/arch/arm/mach-exynos4/mach-exynos4-dt.c 
b/arch/arm/mach-exynos4/mach-exynos4-dt.c
new file mode 100644
index 000..34267d8
--- /dev/null
+++ b/arch/arm/mach-exynos4/mach-exynos4-dt.c
@@ -0,0 +1,94 @@
+/*
+ * Samsung's Exynos4210 device tree enabled machine.
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ * www.linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static struct s3c_sdhci_platdata smdkv310_hsmmc0_pdata __initdata = {
+   .cd_type= S3C_SDHCI_CD_INTERNAL,
+   .clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
+   .max_width  = 8,
+   .host_caps  = MMC_CAP_8_BIT_DATA,
+#endif
+};
+
+static struct s3c_sdhci_platdata smdkv310_hsmmc2_pdata __initdata = {
+   .cd_type= S3C_SDHCI_CD_INTERNAL,
+   .clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH2_8BIT
+   .max_width  = 8,
+   .host_caps  = MMC_CAP_8_BIT_DATA,
+#endif
+};
+
+static const struct of_dev_auxdata exynos4_auxdata_lookup[] __initconst = {
+   OF_DEV_AUXDATA("samsung,s3c-sdhci", EXYNOS4_PA_HSMMC(2),
+   "s3c-sdhci.2", &s3c_hsmmc2_def_platdata),
+   OF_DEV_AUXDATA("samsung,s3c-sdhci", EXYNOS4_PA_HSMMC(0),
+   "s3c-sdhci.0", &s3c_hsmmc0_def_platdata),
+   OF_DEV_AUXDATA("samsung,s5pv210-uart", S5P_PA_UART0,
+   "s5pv210-uart.0", NULL),
+   OF_DEV_AUXDATA("samsung,s5pv210-uart", S5P_PA_UART1,
+   "s5pv210-uart.1", NULL),
+   {},
+};
+
+static void __init exynos4_dt_map_io(void)
+{
+   s5p_init_io(NULL, 0, S5P_VA_CHIPID);
+   s3c24xx_init_clocks(2400);
+}
+
+static const struct of_device_id intc_of_match[] __initconst = {

Re: [PATCH 1/6] serial: samsung: Keep a copy of platform data in driver's private data

[Thomas Abraham]

Hi Grant,

On 20 June 2011 21:24, Grant Likely  wrote:
> On Mon, Jun 20, 2011 at 5:02 AM, Thomas Abraham
>  wrote:
>> The driver depends on pdev->dev.platform_data to retrive information
>> about the platform data even after the initialization. To add device
>> tree support, this has to be changed in way that the platform data
>> is avialable from driver's private data. This patch adds support
>> for keeping a copy of the plaform data in s3c24xx_uart_info and using
>> it when needed after the initialization.
>>
>> Signed-off-by: Thomas Abraham 
>> ---
>>  drivers/tty/serial/s5pv210.c |   12 ++--
>>  drivers/tty/serial/samsung.c |   24 
>>  drivers/tty/serial/samsung.h |    4 +++-
>>  3 files changed, 33 insertions(+), 7 deletions(-)
>
> Hi Thomas.
>
> Don't forget you need to cc Alan Cox and the linux-serial mailing list
> for tty driver patches.

Ok. I will do that when I submit the next version of the patch.

>
> Comments below...
>
>>
>> diff --git a/drivers/tty/serial/s5pv210.c b/drivers/tty/serial/s5pv210.c
>> index d6b2423..3b2021a 100644
>> --- a/drivers/tty/serial/s5pv210.c
>> +++ b/drivers/tty/serial/s5pv210.c
>> @@ -27,9 +27,13 @@



>> +       if (cfg) {
>> +               memcpy((void *)&info->cfg, cfg, sizeof(struct 
>> s3c2410_uartcfg));
>
> "info->cfg = *cfg;" should be sufficient.
>
>> +               info->cfg.clocks = kzalloc(sizeof(struct 
>> s3c24xx_uart_clksrc) *
>> +                                       cfg->clocks_size, GFP_KERNEL);
>> +               if (!info->cfg.clocks)
>> +                       return -ENOMEM;
>> +               memcpy(info->cfg.clocks, cfg->clocks,
>> +                       sizeof(struct s3c24xx_uart_clksrc) * 
>> cfg->clocks_size);
>> +       }
>
> ewwh. There has to be a better way to do this.  Part of the point of
> putting a copy of pdata into the private data structure is to simplify
> the driver so that kzallocing wouldn't be necessary.  With that clock
> table, the driver actually gets more complex because both DT and
> non-DT paths now need to kzalloc a clock array.
>
> From what I can tell, the list of clocks on all mainlined platforms is
> a static array of one or two entries; min & max baud are always set to
> 0, and names are one of:
> - uclk & pclk
> - uclk
> - uclk1
> - fclk (with divisor either 10 or 0)
> - pclk_low & uclk1
>
> You could also make the clock structure a static array of 2 elements
> in the private data structure.  That would simplify both this code and
> the followon DT patch.
>
> Also, peaking forward at what the 2nd patch does, I think that it
> might just be a little premature to try and decode the clock info from
> the DT.  But I'll address that issue when replying to the second
> patch.

Thanks for the suggestion. I had not thought about these issues. One
possible option in this case is using Sylwester's suggestion of
changing exynos4 clkdev support to be similar to the omap clkdev
support. That way, an additional level of indirection is possible. The
uart driver could than be modified to lookup clock with generic names
like "uart_clksrc0", "uart_clksrc1" and "uart_clksrc2". With this,
there will be no need to pass clock names to the uart driver. I will
check if this can be done.

>
>> +
>> +       cfg = &info->cfg;
>>        if (cfg->hwport > CONFIG_SERIAL_SAMSUNG_UARTS) {
>>                printk(KERN_ERR "%s: port %d bigger than %d\n", __func__,
>>                       cfg->hwport, CONFIG_SERIAL_SAMSUNG_UARTS);
>> +               kfree(info->cfg.clocks);
>>                return -ERANGE;
>>        }
>>
>> @@ -1181,11 +1195,13 @@ EXPORT_SYMBOL_GPL(s3c24xx_serial_probe);
>>  int __devexit s3c24xx_serial_remove(struct platform_device *dev)
>>  {
>>        struct uart_port *port = s3c24xx_dev_to_port(&dev->dev);
>> +       struct s3c24xx_uart_info *info = s3c24xx_port_to_info(port);
>>
>>        if (port) {
>>                s3c24xx_serial_cpufreq_deregister(to_ourport(port));
>>                device_remove_file(&dev->dev, &dev_attr_clock_source);
>>                uart_remove_one_port(&s3c24xx_uart_drv, port);
>> +               kfree(info->cfg.clocks);
>>        }
>>
>>        return 0;
>> diff --git a/drivers/tty/serial/samsung.h b/drivers/tty/serial/samsung.h
>> index a69d9a5..4f2f6f5 100644
>> --- a/drivers/tty/serial/samsung.h
>> +++ b/drivers/tty/serial/samsung.h
>> @@ -24,6 +24,9 @@ struct s3c24xx_uart_info {
>>
>>        unsigned int            has_divslot:1;
>>
>> +       /* copy of platform data */
>
> I'd change this to "copy of /configuration/ data" since the data
> doesn't necessarily come from the platform_data pointer anymore.

Ok. I will change this. Thanks for reviewing the patches.

Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/6] serial: samsung: Add device tree support for s5pv210 uart driver

[Thomas Abraham]

Hi Grant,

On 20 June 2011 22:13, Grant Likely  wrote:
>
> For custom properties, you should prefix the property name with 'samsung,'.
>
> This looks very much like directly encoding the Linux flags into the
> device tree.  The binding should be completely contained within
> itself, and not refer to OS implementation details.  It is fine to use
> the same values that Linux happens to use, but they need to still be
> explicitly documented as to what they mean.  Also, a 'flags' property
> usually isn't very friendly to mere-mortals when the explicit
> behaviour can be enabled with the presence of a named property.  For
> example; something like a "samsung,uart-has-rtscts" to enable rts/cts.

I will ensure that the next version of the patch do not have any linux
specific bindings.

>
>> +
>> +- has_fracval : Set to 1, if the controller supports fractional part of
>> +       for the baud divisor, otherwise, set to 0.
>
> Boolean stuff often doesn't need a value.  If the property is present,
> it is a '1'.  If it isn't, then it is a '0'.
>
>> +
>> +- ucon_default : Default board specific setting of UCON register.
>> +
>> +- ulcon_default : Default board specific setting of ULCON register.
>> +
>> +- ufcon_default : Default board specific setting of UFCON register.
>
> I think I've commented on this before, but I do try to avoid direct
> coding registers into the DT.  That said, sometimes there really isn't
> a nice human-friendly way of encoding things and direct register
> values is the best approach.

Instead of default register values, is it acceptable to include custom
properties like "samsung,txfifo-trig-level" and then convert it to
corresponding register settings?

>
>> +
>> +- uart_clksrc : One or more child nodes representing the clock sources that
>> +       could be used to derive the buad rate. Each of these child nodes
>> +       has four required properties.
>> +
>> +       - name : Name of the parent clock.
>> +       - divisor : divisor from the clock to the uart controller.
>> +       - min_baud : Minimum baud rate for which this clock can be used.
>> +                       Set to zero, if there is no limitation.
>> +       - max_buad : Maximum baud rate for which this clock can be used.
>
> typo: s/buad/baud/
>
>> +                       Set to zero, if there is no limitation.
>
> This looks to be directly encoding the current Linux implementation
> details into the device tree (it is a direct copy of the config
> structure members), and it doesn't use the common clock binding.  It's
> fine to use sub nodes for each clock attachment, particularly because
> it looks like the uart is able to apply it's own divisor to the clock
> input, but I would definitely encode the data using the existing
> struct clock binding.
>
>> +
>> +Optional properties:
>> +- fifosize: Size of the tx/rx fifo used in the controller. If not specified,
>> +       the default value of the fifosize is 16.
>> diff --git a/drivers/tty/serial/s5pv210.c b/drivers/tty/serial/s5pv210.c
>> index 3b2021a..9aacbda 100644
>> --- a/drivers/tty/serial/s5pv210.c
>> +++ b/drivers/tty/serial/s5pv210.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -131,15 +132,39 @@ static struct s3c24xx_uart_info *s5p_uart_inf[] = {
>>  /* device management */
>>  static int s5p_serial_probe(struct platform_device *pdev)
>>  {
>> -       return s3c24xx_serial_probe(pdev, s5p_uart_inf[pdev->id]);
>> +       const void *prop;
>> +       unsigned int port = pdev->id;
>> +       unsigned int fifosize = 16;
>> +       static unsigned int probe_index;
>> +
>> +       if (pdev->dev.of_node) {
>> +               prop = of_get_property(pdev->dev.of_node, "fifosize", NULL);
>> +               if (prop)
>> +                       fifosize = be32_to_cpu(*(u32 *)prop);
>
> Okay, this is getting ugly (not your fault, but this pattern has
> become too common.  Can you craft and post a patch that adds the
> following functions to drivers/of/base.c and include/linux/of.h
>
> /* offset in cells, not bytes */
> int dt_decode_u32(struct *property, int offset, u32 *out_val)
> {
>        if (!property || !property->value)
>                return -EINVAL;
>        if ((offset + 1) * 4 > property->length)
>                return -EINVAL;
>        *out_val = of_read_number(property->value + (offset * 4), 1);
>        return 0;
> }
> int dt_decode_u64(struct *property, int offset, u64 *out_val)
> {
> ...
> }
> int dt_decode_string(struct *property, int index, char **out_string);
> {
> ...
> }
>
> Plus a set of companion functions:
> int dt_getprop_u32(struct device_node *np, char *propname, int offset,
> u32 *out_val)
> {
>        return dt_decode_u32(of_find_property(np, propname, NULL),
> offset, out_val);
> }
> int dt_getprop_u64(struct *device_node, char *propname, int offset,
> u64 *out_val);
> {
> ...
> }
> int dt_getprop_string(struct *device_node, char *propname, int index,
> char **out_string);
> {
> ..

Re: [PATCH 6/6] arm: exynos4: Add a new Exynos4 device tree enabled machine

[Thomas Abraham]

On 20 June 2011 22:25, Grant Likely  wrote:



>> +
>> +static const struct of_dev_auxdata exynos4_auxdata_lookup[] __initconst = {
>> +       OF_DEV_AUXDATA("samsung,s3c-sdhci", EXYNOS4_PA_HSMMC(2),
>> +                               "s3c-sdhci.2", &s3c_hsmmc2_def_platdata),
>> +       OF_DEV_AUXDATA("samsung,s3c-sdhci", EXYNOS4_PA_HSMMC(0),
>> +                               "s3c-sdhci.0", &s3c_hsmmc0_def_platdata),
>> +       OF_DEV_AUXDATA("samsung,s5pv210-uart", S5P_PA_UART0,
>> +                               "s5pv210-uart.0", NULL),
>> +       OF_DEV_AUXDATA("samsung,s5pv210-uart", S5P_PA_UART1,
>> +                               "s5pv210-uart.1", NULL),
>> +       {},
>> +};



>> +static void __init exynos4_dt_machine_init(void)
>> +{
>> +       s3c_sdhci0_set_platdata(&smdkv310_hsmmc0_pdata);
>> +       s3c_sdhci2_set_platdata(&smdkv310_hsmmc2_pdata);
>
> Are these two lines still necessary?

Yes, but these are temporary. The data from smdkv310_hsmmc0_pdata is
copied to s3c_hsmmc2_def_platdata which is then used as platform data.
I will remove them in the next version of the patch.

Thanks,
Thomas.

>
> Otherwise, the patch looks good to me.
>
> g.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/6] serial: samsung: Add device tree support for s5pv210 uart driver

[Thomas Abraham]

Hi Grant,

On 20 June 2011 22:13, Grant Likely  wrote:
> Okay, this is getting ugly (not your fault, but this pattern has
> become too common.  Can you craft and post a patch that adds the
> following functions to drivers/of/base.c and include/linux/of.h
>
> /* offset in cells, not bytes */
> int dt_decode_u32(struct *property, int offset, u32 *out_val)
> {
>        if (!property || !property->value)
>                return -EINVAL;
>        if ((offset + 1) * 4 > property->length)
>                return -EINVAL;
>        *out_val = of_read_number(property->value + (offset * 4), 1);
>        return 0;
> }
> int dt_decode_u64(struct *property, int offset, u64 *out_val)
> {
> ...
> }
> int dt_decode_string(struct *property, int index, char **out_string);
> {
> ...
> }
>
> Plus a set of companion functions:
> int dt_getprop_u32(struct device_node *np, char *propname, int offset,
> u32 *out_val)
> {
>        return dt_decode_u32(of_find_property(np, propname, NULL),
> offset, out_val);
> }
> int dt_getprop_u64(struct *device_node, char *propname, int offset,
> u64 *out_val);
> {
> ...
> }
> int dt_getprop_string(struct *device_node, char *propname, int index,
> char **out_string);
> {
> ...
> }
>
> Then you'll be able to simply do the following to decode each
> property, with fifosize being left alone if the property cannot be
> found or decoded:
>
> dt_getprop_u32(pdev->dev.of_node, "samsung,fifosize", &fifosize);

I have added the functions as you have suggested and the diff is
listed below. Could you please review the diff and suggest any changes
required.


 drivers/of/base.c  |  129 
 include/linux/of.h |   10 
 2 files changed, 139 insertions(+), 0 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 632ebae..73f0144 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -596,6 +596,135 @@ struct device_node
*of_find_node_by_phandle(phandle handle)
 EXPORT_SYMBOL(of_find_node_by_phandle);

 /**
+ * of_read_property_u32 - Reads a indexed 32-bit property value
+ * @prop:  property to read from.
+ * @offset:cell number to read.
+ * value:  returned cell value
+ *
+ * Returns a indexed 32-bit value of a property cell, -EINVAL in case the cell
+ * does not exist
+ */
+int of_read_property_u32(struct property *prop, u32 offset, u32 *value)
+{
+   if (!prop || !prop->value)
+   return -EINVAL;
+   if ((offset + 1) * 4 > prop->length)
+   return -EINVAL;
+
+   *value = of_read_ulong(prop->value + (offset * 4), 1);
+   return 0;
+}
+EXPORT_SYMBOL(of_read_property_u32);
+
+/**
+ * of_getprop_u32 - Find a property in a device node and read a 32-bit value
+ * @np:device node from which the property value is to be read.
+ * @propname   name of the property to be searched.
+ * @offset:cell number to read.
+ * @value: returned value of the cell
+ *
+ * Search for a property in a device node and read a indexed 32-bit value of a
+ * property cell. Returns the 32-bit cell value, -EINVAL in case the
property or
+ * the indexed cell does not exist.
+ */
+int
+of_getprop_u32(struct device_node *np, char *propname, int offset, u32 *value)
+{
+   return of_read_property_u32(of_find_property(np, propname, NULL),
+   offset, value);
+}
+EXPORT_SYMBOL(of_getprop_u32);
+
+/**
+ * of_read_property_u64 - Reads a indexed 64-bit property value
+ * @prop:  property to read from.
+ * @offset:cell number to read (each cell is 64-bits).
+ * @value: returned cell value
+ *
+ * Returns a indexed 64-bit value of a property cell, -EINVAL in case the cell
+ * does not exist
+ */
+int of_read_property_u64(struct property *prop, int offset, u64 *value)
+{
+   if (!prop || !prop->value)
+   return -EINVAL;
+   if ((offset + 1) * 8 > prop->length)
+   return -EINVAL;
+
+   *value = of_read_number(prop->value + (offset * 8), 2);
+   return 0;
+}
+EXPORT_SYMBOL(of_read_property_u64);
+
+/**
+ * of_getprop_u64 - Find a property in a device node and read a 64-bit value
+ * @np:device node from which the property value is to be read.
+ * @propname   name of the property to be searched.
+ * @offset:cell number to read (each cell is 64-bits).
+ * @value: returned value of the cell
+ *
+ * Search for a property in a device node and read a indexed 64-bit value of a
+ * property cell. Returns the 64-bit cell value, -EINVAL in case the
property or
+ * the indexed cell does not exist.
+ */
+int
+of_getprop_u64(struct device_node *np, char *propname, int offset, u64 *value)
+{
+   return of_read_property_u64(of_find_property(np, propname, NULL),
+   offset, value);
+}
+EXPORT_SYMBOL(of_getprop_u64);
+
+/**
+ * of_read_property_string - Returns a pointer to a indexed null terminated
+ * property value string
+ * @prop:  prope

Re: [PATCH 2/6] serial: samsung: Add device tree support for s5pv210 uart driver

[Thomas Abraham]

Hi Grant,

On 24 June 2011 01:38, Grant Likely  wrote:
> Despite the fact that this is exactly what I asked you to write, this
> ends up being rather ugly.  (I originally put in the '*4' to match the
> behaviour of the existing of_read_number(), but that was a mistake.
> tglx also pointed it out).  How about this instead:

Your draft implementation below is suggesting that the offset should
be in bytes and not cells and so maybe you are suggesting the new
approach to support multi-format property values. I have changed the
implementation as per your code below.

>
> int of_read_property_u32(struct property *prop, unsigned int offset,
> u32 *out_value)
> {
>        if (!prop || !out_value)
>                return -EINVAL;
>        if (!prop->value)
>                return -ENODATA;
>        if (offset + sizeof(*out_value) > prop->length)
>                return -EOVERFLOW;
>        *out_value = be32_to_cpup(prop->data + offset);
>        return 0;
> }

[...]

>> +/**
>> + * of_read_property_string - Returns a pointer to a indexed null terminated
>> + *                             property value string
>> + * @prop:      property to read from.
>> + * @offset:    index of the property string to be read.
>> + * @string:    pointer to a null terminated string, valid only if the return
>> + *             value is 0.
>> + *
>> + * Returns a pointer to a indexed null terminated property cell string, 
>> -EINVAL
>> + * in case the cell does not exist.
>> + */
>> +int of_read_property_string(struct property *prop, int offset, char 
>> **string)
>> +{
>> +       char *c;
>> +
>> +       if (!prop || !prop->value)
>> +               return -EINVAL;
>
> Ditto here about return values.
>
>> +
>> +       c = (char *)prop->value;
>
> You don't need the cast.  prop->value is a void* pointer.  However,
> 'c' does need to be const char.
>
>> +       while (offset--)
>> +               while (*c++)
>> +                       ;
>
> Rather than open coding this, you should use the string library
> functions.  Something like:
>
>        c = prop->value;
>        while (offset-- && (c - prop->value) < prop->size)
>                c += strlen(c) + 1;
>        if ((c - prop->value) + strlen(c) >= prop->size)
>                return -EOVERFLOW;
>        *out_value = c;
>
> Plus it catches more error conditions that way.

If we change the offset to represent bytes and not cell index in the
u32 and u64 versions, shouldn't offset represent bytes for the string
version as well? In case of multi-format property values, there could
be u32 or u64 values intermixed with string values. So, some
modifications have been made to your above implementation of the
string version.

The new diff is listed below. Would there be any changes required. If
this is acceptable, I will submit a separate patch.

 drivers/of/base.c  |  142 
 include/linux/of.h |   12 
 2 files changed, 154 insertions(+), 0 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 632ebae..e9acbea 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -596,6 +596,148 @@ struct device_node
*of_find_node_by_phandle(phandle handle)
 EXPORT_SYMBOL(of_find_node_by_phandle);

 /**
+ * of_read_property_u32 - Reads a 32-bit property value
+ * @prop:  property to read from.
+ * @offset:offset into property value to read from (in bytes).
+ * @out_value: returned value.
+ *
+ * Returns a 32-bit value from a property. Returns -EINVAL, if the
property does
+ * not exist, -ENODATA, if property does not have a value, -EOVERFLOW, if
+ * reading from offset overshoots the length of the property.
+ */
+int of_read_property_u32(struct property *prop, u32 offset, u32 *out_value)
+{
+   if (!prop || !out_value)
+   return -EINVAL;
+   if (!prop->value)
+   return -ENODATA;
+   if (offset + sizeof(*out_value) > prop->length)
+   return -EOVERFLOW;
+
+   *out_value = be32_to_cpup(prop->value + offset);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_read_property_u32);
+
+/**
+ * of_getprop_u32 - Find a property in a device node and read a 32-bit value
+ * @np:device node from which the property value is to be read.
+ * @propname   name of the property to be searched.
+ * @offset:offset into property value to read from (in bytes).
+ * @out_value: returned value.
+ *
+ * Search for a property in a device node and read a 32-bit value from a
+ * property. Returns -EINVAL, if the property does not exist, -ENODATA, if
+ * property does not have a value, -EOVERFLOW, if reading from offset
overshoots
+ * the length of the property.
+ */
+int of_getprop_u32(struct device_node *np, char *propname, int offset,
+   u32 *out_value)
+{
+   return of_read_property_u32(of_find_property(np, propname, NULL),
+   offset, out_value);
+}
+EXPORT_SYMBOL_GPL(of_getprop_u32);
+
+/**
+ * of_read_property_u64 - Reads a 6

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Thomas Abraham]

On 17 November 2011 13:38, Linus Walleij  wrote:
>> Linus,
>> Is there a plan to move even the data that exists in the pinmux
>> drivers today (including the function/pin-groups definition)
>> eventually to DT? Or is it just the 'mapping' data to map
>> devices to functions (that today is done from board files) which
>> alone will be moved?
>
> Not for the U300 driver, for the simple reason that it cannot
> use device tree. So both methods of providing the data need
> to be allowed - either as static data (the U300 driver does not
> even have platform data, the pin data is encoded in the driver
> itself since it's tied to U300 and not used for any other systems
> or variants) or as device tree lookups.
>
> That said I have no clue on how to make the DT bindings
> FTM, patches and suggestions welcome.

For now, the Samsung GPIO, Pinconfig and Pinmux information is
represented in device tree as listed below.

i2c@1C004000 {
  compatible = "...";
  reg = <0x... 0x..>;
   gpios = <&gpa0 2 2 3 0>,
  <&gpa0 3 2 3 0>;
  ...
};

The format of the gpio specifier is
<[Pad Controller phandle] [pin number within the controller] [Pin Mux
Function] [Pull Up/Down] [Drive Strength]>

>From a perspective of writing a 'gpios' property for a device node,
this is quite simple. Looking up the hardware manual of the SoC can
provide all the values that should be used in the gpio specifier.

The GPIO/PinCtrl driver can provide a translate function that picks up
the values for the gpio specifier and writes the same value to the
pad-controller registers. But, this a deviation from the existing
pinctrl subsystem code which mainly relies on name of the pin-group
and pin-function.

Does this seem to be a feasible option for specifying
gpio/pinconfig/pinmux dt bindings?

Thanks.
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Thomas Abraham]

Hi Linus,

On 17 November 2011 19:27, Linus Walleij  wrote:
> On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
>  wrote:
>
>> For now, the Samsung GPIO, Pinconfig and Pinmux information is
>> represented in device tree as listed below.
>
> Does this mean that the understanding of this format is merged into
> the mainline kernel drivers or is it keps out-of-tree?


All existing dt support in samsung drivers use this format and it
works fine. But I could not complete work on time and pull request for
samsung-dt support for 3.2 was delayed and hence rejected. So for now,
it is out of tree but available in linux-next.

>
>> i2c@1C004000 {
>>          compatible = "...";
>>          reg = <0x... 0x..>;
>>           gpios = <&gpa0 2 2 3 0>,
>>                      <&gpa0 3 2 3 0>;
>>          ...
>> };
>>
>> The format of the gpio specifier is
>> <[Pad Controller phandle] [pin number within the controller] [Pin Mux
>> Function] [Pull Up/Down] [Drive Strength]>
>>
>> From a perspective of writing a 'gpios' property for a device node,
>> this is quite simple. Looking up the hardware manual of the SoC can
>> provide all the values that should be used in the gpio specifier.
>
> That may not be as simple as it seems if all you have is the
> device tree and no manual, but I get the picture.
>
>> The GPIO/PinCtrl driver can provide a translate function that picks up
>> the values for the gpio specifier and writes the same value to the
>> pad-controller registers. But, this a deviation from the existing
>> pinctrl subsystem code which mainly relies on name of the pin-group
>> and pin-function.
>>
>> Does this seem to be a feasible option for specifying
>> gpio/pinconfig/pinmux dt bindings?
>
> I would prefer the above to use the nice generic enums from the
> pin control subsystem's pinmux and pinconf properties in the
> end so the device tree on its own is understandable without
> any manual whatsoever, but we'll see about that.


This may lead to linux specific information getting into the device
tree. And that might not be acceptable.

>
> Maybe I'm mistaken about the device tree ambitions, but
> I was sort of hoping that it would not contain too much
> custom magic numbers that need to be cross-referenced
> elsewhere ... or rather - the more understandable the device
> tree is, the more we win.

Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.

If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.

Thanks,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: For the device tree topic, is there anything I can do in the 11.12 (28th November 2011 - 18th November 2011)?

[Thomas Abraham]

Hi Botao,

On 30 November 2011 09:36, Botao Sun  wrote:
> Hi Angus & Grant,
>
> Because the Linaro Android 11.11 release has been done successfully, I have
> some time to continue to work on device tree topic, here is my blue print
> for it:
>
> https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-origen-device-tree
>
> Therefore, I would like to know what I can do for this in the 11.12 cycle -
> from now to the 18th December 2011. For Samsung Origen Android build, the
> latest kernel version I got is still 3.0.4+, so I think there is no any
> device tree stuff in it.
>
> @Angus, Would you give me a brief about the device tree support status on
> our current 3.0.4+ kernel? Will you upgrade it to the 3.1 in 11.12 cycle?
>
> @Thomas, In this blue print:
> https://blueprints.launchpad.net/linaro-android/+spec/linaro-platforms-lc4.11-android-device-tree,
> Tony mentioned that you has upstreamed the initial support for device tree.
> However, it depends on the 3.1 kernel upgrade. I would like to know that is
> there any possible that I can do something without the kernel upgrade?

All the existing Exynos4210 device tree patches are based on
linux-3.2-rc1. There are about 35+ device tree support patches
covering about 10 peripherals. Most of these patches will not apply
cleanly to a previous version of the kernel. And in some cases, these
patches depend on other patches merged during 3.2 merge window (like
the GIC dt support). Though it might be possible to backport these
patches, the effort would huge and not recommended.

Thanks,
Thomas.

>
> I currently feel that this work highly depends on the outcome of landing
> team and kernel group, so before I get something from them, I'm afraid that
> I can't do any "real" work on this.
>
> Thank you all for your help!
>
>
> BR
> Botao Sun
>
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v5 3/4] regulator: pass additional of_node to regulator_register()

[Thomas Abraham]

Hi Rajendra,

On 18 November 2011 16:47, Rajendra Nayak  wrote:
> With device tree support for regulators, its needed that the
> regulator_dev->dev device has the right of_node attached.
> To be able to do this add an additional parameter to the
> regulator_register() api, wherein the dt-adapted driver can
> then pass this additional info onto the regulator core.
>
> Signed-off-by: Rajendra Nayak 
> Acked-by: Mark Brown 
> Cc: Michael Hennerich 
> Cc: Ian Lartey 
> Cc: Dimitris Papastamos 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: Wolfram Sang 
> Cc: Zeng Zhaoming 
> Cc: Dan Carpenter 
> ---
>  drivers/regulator/88pm8607.c           |    2 +-
>  drivers/regulator/aat2870-regulator.c  |    2 +-
>  drivers/regulator/ab3100.c             |    2 +-
>  drivers/regulator/ab8500.c             |    2 +-
>  drivers/regulator/ad5398.c             |    2 +-
>  drivers/regulator/bq24022.c            |    2 +-
>  drivers/regulator/core.c               |    3 ++-
>  drivers/regulator/da903x.c             |    2 +-
>  drivers/regulator/db8500-prcmu.c       |    2 +-
>  drivers/regulator/dummy.c              |    2 +-
>  drivers/regulator/fixed.c              |    2 +-
>  drivers/regulator/isl6271a-regulator.c |    2 +-
>  drivers/regulator/lp3971.c             |    2 +-
>  drivers/regulator/lp3972.c             |    2 +-
>  drivers/regulator/max1586.c            |    2 +-
>  drivers/regulator/max8649.c            |    2 +-
>  drivers/regulator/max8660.c            |    2 +-
>  drivers/regulator/max8925-regulator.c  |    2 +-
>  drivers/regulator/max8952.c            |    2 +-
>  drivers/regulator/max8997.c            |    2 +-
>  drivers/regulator/max8998.c            |    2 +-
>  drivers/regulator/mc13783-regulator.c  |    2 +-
>  drivers/regulator/mc13892-regulator.c  |    2 +-
>  drivers/regulator/pcap-regulator.c     |    2 +-
>  drivers/regulator/pcf50633-regulator.c |    2 +-
>  drivers/regulator/tps6105x-regulator.c |    3 ++-
>  drivers/regulator/tps65023-regulator.c |    2 +-
>  drivers/regulator/tps6507x-regulator.c |    2 +-
>  drivers/regulator/tps6524x-regulator.c |    2 +-
>  drivers/regulator/tps6586x-regulator.c |    2 +-
>  drivers/regulator/tps65910-regulator.c |    2 +-
>  drivers/regulator/tps65912-regulator.c |    2 +-
>  drivers/regulator/twl-regulator.c      |    2 +-
>  drivers/regulator/wm831x-dcdc.c        |    8 
>  drivers/regulator/wm831x-isink.c       |    2 +-
>  drivers/regulator/wm831x-ldo.c         |    6 +++---
>  drivers/regulator/wm8350-regulator.c   |    2 +-
>  drivers/regulator/wm8400-regulator.c   |    2 +-
>  drivers/regulator/wm8994-regulator.c   |    2 +-
>  include/linux/regulator/driver.h       |    2 +-
>  sound/soc/codecs/sgtl5000.c            |    2 +-
>  41 files changed, 48 insertions(+), 46 deletions(-)

Documentation/power/regulator/regulator.txt would also require an
update the reflect the change in api.

Thanks,
Thomas.

[...]

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data

[Thomas Abraham]

On 18 November 2011 16:47, Rajendra Nayak  wrote:
> The helper routine is meant to be used by the regulator drivers
> to extract the regulator_init_data structure from the data
> that is passed from device tree.
> 'consumer_supplies' which is part of regulator_init_data is not extracted
> as the regulator consumer mappings are passed through DT differently,
> implemented in subsequent patches.
> Similarly the regulator<-->parent/supply mapping is handled in
> subsequent patches.
>
> Also add documentation for regulator bindings to be used to pass
> regulator_init_data struct information from device tree.
>
> Some of the regulator properties which are linux and board specific,
> are left out since its not clear if they can
> be in someway embedded into the kernel or passed in from DT.
> They will be revisited later.
>
> Signed-off-by: Rajendra Nayak 
> ---
>  .../devicetree/bindings/regulator/regulator.txt    |   54 +
>  drivers/regulator/Makefile                         |    1 +
>  drivers/regulator/of_regulator.c                   |   81 
> 
>  include/linux/regulator/of_regulator.h             |   20 +
>  4 files changed, 156 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
>  create mode 100644 drivers/regulator/of_regulator.c
>  create mode 100644 include/linux/regulator/of_regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
> b/Documentation/devicetree/bindings/regulator/regulator.txt
> new file mode 100644
> index 000..82bef20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -0,0 +1,54 @@
> +Voltage/Current Regulators
> +
> +Optional properties:
> +- regulator-name: A string used as a descriptive name for regulator outputs
> +- regulator-min-microvolt: smallest voltage consumers may set
> +- regulator-max-microvolt: largest voltage consumers may set
> +- regulator-microvolt-offset: Offset applied to voltages to compensate for 
> voltage drops
> +- regulator-min-microamp: smallest current consumers may set
> +- regulator-max-microamp: largest current consumers may set
> +- regulator-always-on: boolean, regulator should never be disabled
> +- regulator-boot-on: bootloader/firmware enabled regulator
> +- -supply: phandle to the parent supply/regulator node

For regulators that are not turned on by bootloader, and which require
'apply_uV' constraint, is there any alternative for turning on the
regulator when using dt?

Or, how about adding a additional check as below.

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5baa196..25a6781 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -816,8 +816,9 @@ static int machine_constraints_voltage(struct
regulator_dev *rdev,
int ret;

/* do we need to apply the constraint voltage */
-   if (rdev->constraints->apply_uV &&
-   rdev->constraints->min_uV == rdev->constraints->max_uV) {
+   if ((rdev->constraints->apply_uV &&
+   rdev->constraints->min_uV == rdev->constraints->max_uV) ||
+   (!rdev->constraints->boot_on && rdev->constraints->always_on)) {
ret = _regulator_do_set_voltage(rdev,
rdev->constraints->min_uV,
rdev->constraints->max_uV);

Thanks,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data

[Thomas Abraham]

Hi Mark,

On 4 December 2011 21:24, Mark Brown
 wrote:
> On Sun, Dec 04, 2011 at 06:51:23PM +0530, Thomas Abraham wrote:
>
>> For regulators that are not turned on by bootloader, and which require
>> 'apply_uV' constraint, is there any alternative for turning on the
>> regulator when using dt?
>
> If the regulator isn't software managed then always_on covers this - the
> regulator core will enable any always_on regulators that haven't been
> enabled already.

Thanks for the hint. I was trying to deal with a regulator that was
not software managed but also required the voltage level to be set to
certain level. That was possible with 'apply_uV' constraint in non-dt
case. Anyway, I have modified the code to manage the regulator and
this works fine in dt case as well without the 'apply_uV' constraint.

>
>>       /* do we need to apply the constraint voltage */
>> -     if (rdev->constraints->apply_uV &&
>> -         rdev->constraints->min_uV == rdev->constraints->max_uV) {
>> +     if ((rdev->constraints->apply_uV &&
>> +         rdev->constraints->min_uV == rdev->constraints->max_uV) ||
>> +             (!rdev->constraints->boot_on && rdev->constraints->always_on)) 
>> {
>>               ret = _regulator_do_set_voltage(rdev,
>>                                               rdev->constraints->min_uV,
>>                                               rdev->constraints->max_uV);
>
> I'm not sure I understand the intended logic there.  Voltage constraints
> and enable/disable constraints are orthogonal here.

Ok. I guess the above change is incorrect then.

Thanks,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data

[Thomas Abraham]

On 5 December 2011 16:04, Mark Brown
 wrote:
> On Mon, Dec 05, 2011 at 02:40:50PM +0530, Thomas Abraham wrote:
>> On 4 December 2011 21:24, Mark Brown
>
>> > If the regulator isn't software managed then always_on covers this - the
>> > regulator core will enable any always_on regulators that haven't been
>> > enabled already.
>
>> Thanks for the hint. I was trying to deal with a regulator that was
>> not software managed but also required the voltage level to be set to
>> certain level. That was possible with 'apply_uV' constraint in non-dt
>> case. Anyway, I have modified the code to manage the regulator and
>> this works fine in dt case as well without the 'apply_uV' constraint.
>
> With the regulator device tree bindings if the regulator is configured
> to run a single voltage the bindings will set apply_uV unconditionally
> so there's no need for a separate constraint.
>

Sorry if I have missed this, but I could not find 'apply_uV' being set
as you described in the v5 of the regulator-dt patchset.

Thanks,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data

[Thomas Abraham]

On 5 December 2011 16:27, Mark Brown
 wrote:
> On Mon, Dec 05, 2011 at 04:14:40PM +0530, Thomas Abraham wrote:
>> On 5 December 2011 16:04, Mark Brown
>
>> > With the regulator device tree bindings if the regulator is configured
>> > to run a single voltage the bindings will set apply_uV unconditionally
>> > so there's no need for a separate constraint.
>
>> Sorry if I have missed this, but I could not find 'apply_uV' being set
>> as you described in the v5 of the regulator-dt patchset.
>
> Yes, looks like Rajendra missed that - just fixed it.
>

Thanks Mark. Could you please push your change.

Regards,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: booting an exynos

[Thomas Abraham]

On 2 January 2013 03:32, Daniel Lezcano  wrote:
>
> Hi All,
>
> happy new year !
>
> I am trying to boot my exynos board for the first time but I have no
> console output (the line shows "offline").
>
> I used a serial-usb with minicom and screen.
>
> The web site origenboard.org is down, so I have no information available.
>
> Is there a trick I missed ? Did anyone face this problem ?

Make sure console port is set as 2 (CONFIG_S3C_LOWLEVEL_UART_PORT). If
this still does not help, please let me know the Exynos processor on
the board (Exynos4210 or Exynos4412) and the mainline kernel version
you are using.

Thanks,
Thomas.

>
> Thanks
>
> -- Daniel
>
> --
>   Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:   Facebook |
>  Twitter |
>  Blog
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] Fix build failure for s5pv310 target when CONFIG_S5PV310_DEV_SYSMMU is not defined

[Thomas Abraham]

On 27 January 2011 18:49, Angus Ainslie  wrote:
>
> Signed-off-by: Angus Ainslie 
> ---
>  arch/arm/mach-s5pv310/mach-smdkv310.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s5pv310/mach-smdkv310.c 
> b/arch/arm/mach-s5pv310/mach-smdkv310.c
> index 28680cf..d946b00 100644
> --- a/arch/arm/mach-s5pv310/mach-smdkv310.c
> +++ b/arch/arm/mach-s5pv310/mach-smdkv310.c
> @@ -164,7 +164,9 @@ static struct platform_device *smdkv310_devices[] 
> __initdata = {
>        &s5pv310_device_pd[PD_TV],
>        &s5pv310_device_pd[PD_GPS],
>        &smdkv310_smsc911x,
> +#ifdef CONFIG_S5PV310_DEV_SYSMMU
>        &s5pv310_device_sysmmu,
> +#endif
>  };

A patch to fix this compilation issue was submitted to Samsung's
mailing list and it has been accepted. This patch can be found at
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg03942.html

>
>  static void __init smdkv310_smsc911x_init(void)
> --
> 1.7.1
>
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[RFC PATCH] SDHCI: S3C: Add support for retrieving memory and irq resource information from device tree.

[thomas . abraham]

From: Thomas Abraham 

Add support for retrieving memory and irq resource information
from device tree for Samsung's SDHCI controller driver.

Signed-off-by: Thomas Abraham 
---

The modification will be made more generic to support both
DT and non-DT versions of the driver without the #ifdef's.
For now, this patch is for review and to understand if the
approach adopted to obtain resource information from the
device tree is appropriate.

 drivers/mmc/host/sdhci-s3c.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 1720358..f536061 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -19,6 +19,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -348,23 +351,52 @@ static int __devinit sdhci_s3c_probe(struct 
platform_device *pdev)
struct sdhci_s3c *sc;
struct resource *res;
int ret, irq, ptr, clks;
+   struct device_node *np = NULL;
+#ifdef CONFIG_OF
+   struct resource iores;
+#endif
 
if (!pdata) {
dev_err(dev, "no device data specified\n");
return -ENOENT;
}
 
+#ifdef CONFIG_OF
+   for_each_compatible_node(np, NULL, "samsung,sdhci-s3c") {
+   const u32 *id = of_get_property(np, "cell-index", NULL);
+   if (be32_to_cpu(*id) == pdev->id)
+   break;
+   }
+
+   if (!np) {
+   dev_err(dev, "no matching device node specified in device 
tree\n");
+   return -ENOENT;
+   }
+#endif
+
+#ifndef CONFIG_OF
irq = platform_get_irq(pdev, 0);
+#else
+   irq = of_irq_to_resource(np, 0, NULL);
+#endif
if (irq < 0) {
dev_err(dev, "no irq specified\n");
return irq;
}
 
+#ifndef CONFIG_OF
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "no memory specified\n");
return -ENOENT;
}
+#else
+   if (of_address_to_resource(np, 0, &iores)) {
+   dev_err(dev, "no memory specified in device tree\n");
+   return -ENOENT;
+   }
+   res = &iores;
+#endif
 
host = sdhci_alloc_host(dev, sizeof(struct sdhci_s3c));
if (IS_ERR(host)) {
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 2/4] ARM: DT: Add a basic dts file for SMDKV310 machine

[Thomas Abraham]

This patch adds a basic dts file for Samsung's SMDKV310 machine.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-s5pv310/mach-smdkv310.dts |   38 +++
 1 files changed, 38 insertions(+), 0 deletions(-)
 create mode 100755 arch/arm/mach-s5pv310/mach-smdkv310.dts

diff --git a/arch/arm/mach-s5pv310/mach-smdkv310.dts 
b/arch/arm/mach-s5pv310/mach-smdkv310.dts
new file mode 100755
index 000..74d80bf
--- /dev/null
+++ b/arch/arm/mach-s5pv310/mach-smdkv310.dts
@@ -0,0 +1,38 @@
+/dts-v1/;
+
+/ {
+   model = "smdkv310";
+   compatible = "samsung,smdkv310";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   memory {
+   device_type = "memory";
+   reg = <0x4000 0x0800>;
+   };
+
+   chosen {
+   bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M 
console=ttySAC1,115200 init=/linuxrc";
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges = <0x 0x 0x>;
+
+   GIC:gic@0x1050 {
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   reg = <0x1050 0x1000>;
+   compatible = "arm,gic";
+   };
+
+   watchdog@0x1006 {
+   reg = <0x1006 0x400>;
+   interrupts = <552>;
+   interrupt-parent = <&GIC>;
+   compatible = "samsung,s3c2410-wdt";
+   };
+   };
+};
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 0/4] Add basic device tree support for Samsung's SMDKV310 machine.

[Thomas Abraham]

This patchset adds Samsung's SMDKV310 machine with device tree support. The
bootargs and memory information is obtained from the device tree. The
watchdog driver is also modified such that it is probed based on the information
from the device tree.

Thomas Abraham (4):
 ARM: DT: Add SMDKV310 machine with device tree support.
 ARM: DT: Add a basic dts file for SMDKV310 machine
 ARM: DT: Add support for probing platform bus on SMDKV310 machine
 watchdog: s3c2410: Add support for device tree based probe

 arch/arm/mach-s5pv310/Kconfig|7 ++
 arch/arm/mach-s5pv310/Makefile   |1 +
 arch/arm/mach-s5pv310/mach-smdkv310-dt.c |  107 ++
 arch/arm/mach-s5pv310/mach-smdkv310.dts  |   38 +++
 drivers/watchdog/s3c2410_wdt.c   |   10 +++
 5 files changed, 163 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-s5pv310/mach-smdkv310-dt.c
 create mode 100755 arch/arm/mach-s5pv310/mach-smdkv310.dts


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 4/4] watchdog: s3c2410: Add support for device tree based probe

[Thomas Abraham]

This patch adds the of_match_table to enable s3c2410-wdt driver
to be probed when watchdog device node is found in the device tree.

Signed-off-by: Thomas Abraham 
---
 drivers/watchdog/s3c2410_wdt.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index ae53662..a9edd50 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -592,6 +592,13 @@ static int s3c2410wdt_resume(struct platform_device *dev)
 #define s3c2410wdt_resume  NULL
 #endif /* CONFIG_PM */
 
+#ifdef CONFIG_OF
+static const struct of_device_id s3c2410_wdt_match[] = {
+   { .compatible = "samsung,s3c2410-wdt" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
+#endif
 
 static struct platform_driver s3c2410wdt_driver = {
.probe  = s3c2410wdt_probe,
@@ -602,6 +609,9 @@ static struct platform_driver s3c2410wdt_driver = {
.driver = {
.owner  = THIS_MODULE,
.name   = "s3c2410-wdt",
+#ifdef CONFIG_OF
+   .of_match_table = s3c2410_wdt_match,
+#endif
},
 };
 
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 3/4] ARM: DT: Add support for probing platform bus on SMDKV310 machine

[Thomas Abraham]

This patch adds support for probing devices from device tree
for Samsung's SMDKV310 machine.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-s5pv310/mach-smdkv310-dt.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv310/mach-smdkv310-dt.c 
b/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
index 367fdb1..f81d88a 100644
--- a/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
+++ b/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
@@ -79,9 +79,15 @@ static void __init smdkv310_map_io(void)
s3c24xx_init_uarts(smdkv310_uartcfgs, ARRAY_SIZE(smdkv310_uartcfgs));
 }
 
+static struct of_device_id smdkv310_dt_match_table[] __initdata = {
+   { .compatible = "simple-bus", },
+   {},
+};
+
 static void __init smdkv310_machine_init(void)
 {
platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
+   of_platform_bus_probe(NULL, smdkv310_dt_match_table, NULL);
 }
 
 static char const *smdkv310_dt_compat[] = {
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 1/4] ARM: DT: Add SMDKV310 machine with device tree support.

[Thomas Abraham]

This patch adds a new SMDKV310 machine that boots with a minimal
device tree support. The bootargs and memory information is obtained
from the device tree during boot.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-s5pv310/Kconfig|7 ++
 arch/arm/mach-s5pv310/Makefile   |1 +
 arch/arm/mach-s5pv310/mach-smdkv310-dt.c |  101 ++
 3 files changed, 109 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-s5pv310/mach-smdkv310-dt.c

diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index 09c4c21..6c5f0bf 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -127,6 +127,13 @@ config MACH_SMDKV310
help
  Machine support for Samsung SMDKV310
 
+config MACH_SMDKV310_DT
+   bool "SMDKV310 with device tree support"
+   select CPU_S5PV310
+   select USE_OF
+   help
+ Machine support for Samsung SMDKV310 with device tree based 
initialization.
+
 endmenu
 
 comment "Configuration for HSMMC bus width"
diff --git a/arch/arm/mach-s5pv310/Makefile b/arch/arm/mach-s5pv310/Makefile
index 036fb38..59545aa 100644
--- a/arch/arm/mach-s5pv310/Makefile
+++ b/arch/arm/mach-s5pv310/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
 
 obj-$(CONFIG_MACH_SMDKC210)+= mach-smdkc210.o
 obj-$(CONFIG_MACH_SMDKV310)+= mach-smdkv310.o
+obj-$(CONFIG_MACH_SMDKV310_DT) += mach-smdkv310-dt.o
 obj-$(CONFIG_MACH_UNIVERSAL_C210)  += mach-universal_c210.o
 
 # device support
diff --git a/arch/arm/mach-s5pv310/mach-smdkv310-dt.c 
b/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
new file mode 100644
index 000..367fdb1
--- /dev/null
+++ b/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
@@ -0,0 +1,101 @@
+/* linux/arch/arm/mach-s5pv310/mach-smdkv310.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Following are default values for UCON, ULCON and UFCON UART registers */
+#define SMDKV310_UCON_DEFAULT  (S3C2410_UCON_TXILEVEL |\
+S3C2410_UCON_RXILEVEL |\
+S3C2410_UCON_TXIRQMODE |   \
+S3C2410_UCON_RXIRQMODE |   \
+S3C2410_UCON_RXFIFO_TOI |  \
+S3C2443_UCON_RXERR_IRQEN)
+
+#define SMDKV310_ULCON_DEFAULT S3C2410_LCON_CS8
+
+#define SMDKV310_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE |   \
+S5PV210_UFCON_TXTRIG4 |\
+S5PV210_UFCON_RXTRIG4)
+
+static struct s3c2410_uartcfg smdkv310_uartcfgs[] __initdata = {
+   [0] = {
+   .hwport = 0,
+   .flags  = 0,
+   .ucon   = SMDKV310_UCON_DEFAULT,
+   .ulcon  = SMDKV310_ULCON_DEFAULT,
+   .ufcon  = SMDKV310_UFCON_DEFAULT,
+   },
+   [1] = {
+   .hwport = 1,
+   .flags  = 0,
+   .ucon   = SMDKV310_UCON_DEFAULT,
+   .ulcon  = SMDKV310_ULCON_DEFAULT,
+   .ufcon  = SMDKV310_UFCON_DEFAULT,
+   },
+   [2] = {
+   .hwport = 2,
+   .flags  = 0,
+   .ucon   = SMDKV310_UCON_DEFAULT,
+   .ulcon  = SMDKV310_ULCON_DEFAULT,
+   .ufcon  = SMDKV310_UFCON_DEFAULT,
+   },
+   [3] = {
+   .hwport = 3,
+   .flags  = 0,
+   .ucon   = SMDKV310_UCON_DEFAULT,
+   .ulcon  = SMDKV310_ULCON_DEFAULT,
+   .ufcon  = SMDKV310_UFCON_DEFAULT,
+   },
+};
+
+static struct platform_device *smdkv310_devices[] __initdata = {
+};
+
+static void __init smdkv310_map_io(void)
+{
+   s5p_init_io(NULL, 0, S5P_VA_CHIPID);
+   s3c24xx_init_clocks(2400);
+   s3c24xx_init_uarts(smdkv310_uartcfgs, ARRAY_SIZE(smdkv310_uartcfgs));
+}
+
+static void __init smdkv310_machine_init(void)
+{
+   platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
+}
+
+static char const *smdkv310_dt_compat[] = {
+   "samsung,smdkv310",
+   NULL
+};
+
+DT_MACHINE_START(SMDKV310, "Samsung's SMDKV310 with flattened device tree")
+   /* Maintainer: Kukjin Kim  */
+   /* Maintainer: Changhwan Youn  */
+   .boot_params= S5P_PA_SDRAM + 0x100,
+   .init_irq   = s5pv310_init_irq,
+   .map_io = smdkv310_map_io,
+   .init_mach

Re: Device Tree on ARM status report

[Thomas Abraham]

On 6 February 2011 10:12, Grant Likely  wrote:
> Hi all,
>
> With several more engineers working on ARM device tree support, I'm
> going to start collecting the status of all the work that is going on
> (and I know about) and posting it in a regular status report,
> hopefully weekly, for the next few months until the all of the major
> features are implemented and working on several arm platforms.  I'll
> try to use roughly the following format:



> Samsung S5PV310 tasks:
> [thomas-ab] enable dtb support in u-boot: DONE?

The dtb support in u-boot has been enabled but that has been done in
my copy of u-boot. The linaro u-boot does not include support for
s5pv310 yet.

> [thomas-ab] enable basic kernel dtb support on S5PV310: DONE?

Done and tested.

> [thomas-ab] make gpio driver dt-aware: TODO

Will do this as next task.

> [thomas-ab] Register devices from dt: INPROGRESS
> ... add more details here, specific devices, etc...

The watchdog timer driver was modified to be probed from device tree
and it is working fine (will work for both dt and non-dt versions).
Other work items that will be taken up next are

- Retrieve the default UART register values from the device tree
during UART initialization.
- Add SDHCI_OF support for SDHCI s3c driver, required to support DT
enabled sdhci driver for s5pv310
- Initialize timer and GIC from dt.
- Support dt for gpio, i2c, spi, uart, srom controller.

Thanks,
Thomas.



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] ARM: S5P: Fix length of memory resource definition for UART devices

[thomas . abraham]

From: Thomas Abraham 

The length of memory resource definition for UART devices in all the
s5p platforms is one byte more than the intended value. This patch
fixes the UART memory resource definition for all s5p platforms.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-s5p6442/include/mach/map.h |2 +-
 arch/arm/mach-s5p64x0/include/mach/map.h |2 +-
 arch/arm/mach-s5pc100/include/mach/map.h |2 +-
 arch/arm/mach-s5pv210/include/mach/map.h |2 +-
 arch/arm/mach-s5pv310/include/mach/map.h |2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-s5p6442/include/mach/map.h 
b/arch/arm/mach-s5p6442/include/mach/map.h
index 203dd5a..59464f9 100644
--- a/arch/arm/mach-s5p6442/include/mach/map.h
+++ b/arch/arm/mach-s5p6442/include/mach/map.h
@@ -46,7 +46,7 @@
 #define S5P_PA_UART0   (S5P6442_PA_UART + 0x0)
 #define S5P_PA_UART1   (S5P6442_PA_UART + 0x400)
 #define S5P_PA_UART2   (S5P6442_PA_UART + 0x800)
-#define S5P_SZ_UARTSZ_256
+#define S5P_SZ_UART(SZ_256 - 1)
 
 #define S5P6442_PA_IIC0(0xEC10)
 
diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h 
b/arch/arm/mach-s5p64x0/include/mach/map.h
index a9365e5..c32c117 100644
--- a/arch/arm/mach-s5p64x0/include/mach/map.h
+++ b/arch/arm/mach-s5p64x0/include/mach/map.h
@@ -51,7 +51,7 @@
 #define S5P_PA_UART4   S5P6450_PA_UART(4)
 #define S5P_PA_UART5   S5P6450_PA_UART(5)
 
-#define S5P_SZ_UARTSZ_256
+#define S5P_SZ_UART(SZ_256 - 1)
 
 #define S5P6440_PA_IIC0(0xEC104000)
 #define S5P6440_PA_IIC1(0xEC20F000)
diff --git a/arch/arm/mach-s5pc100/include/mach/map.h 
b/arch/arm/mach-s5pc100/include/mach/map.h
index ccbe6b7..f999021 100644
--- a/arch/arm/mach-s5pc100/include/mach/map.h
+++ b/arch/arm/mach-s5pc100/include/mach/map.h
@@ -128,6 +128,6 @@
 #define S5P_PA_UART2   S5P_PA_UART(2)
 #define S5P_PA_UART3   S5P_PA_UART(3)
 
-#define S5P_SZ_UARTSZ_256
+#define S5P_SZ_UART(SZ_256 - 1)
 
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-s5pv210/include/mach/map.h 
b/arch/arm/mach-s5pv210/include/mach/map.h
index 1dd5883..89b4f0b 100644
--- a/arch/arm/mach-s5pv210/include/mach/map.h
+++ b/arch/arm/mach-s5pv210/include/mach/map.h
@@ -130,6 +130,6 @@
 #define S5P_PA_UART2   S5P_PA_UART(2)
 #define S5P_PA_UART3   S5P_PA_UART(3)
 
-#define S5P_SZ_UARTSZ_256
+#define S5P_SZ_UART(SZ_256 - 1)
 
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-s5pv310/include/mach/map.h 
b/arch/arm/mach-s5pv310/include/mach/map.h
index 901657f..5235024 100644
--- a/arch/arm/mach-s5pv310/include/mach/map.h
+++ b/arch/arm/mach-s5pv310/include/mach/map.h
@@ -139,6 +139,6 @@
 #define S5P_PA_UART3   S5P_PA_UART(3)
 #define S5P_PA_UART4   S5P_PA_UART(4)
 
-#define S5P_SZ_UARTSZ_256
+#define S5P_SZ_UART(SZ_256 - 1)
 
 #endif /* __ASM_ARCH_MAP_H */
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] ARM: S5P: Fix length of memory resource definition for UART devices

[Thomas Abraham]

On 8 February 2011 09:30, Nicolas Pitre  wrote:
> On Tue, 8 Feb 2011, thomas.abra...@linaro.org wrote:
>
>> From: Thomas Abraham 
>>
>> The length of memory resource definition for UART devices in all the
>> s5p platforms is one byte more than the intended value. This patch
>> fixes the UART memory resource definition for all s5p platforms.
>>
>> Signed-off-by: Thomas Abraham 
>> ---
>>  arch/arm/mach-s5p6442/include/mach/map.h |    2 +-
>>  arch/arm/mach-s5p64x0/include/mach/map.h |    2 +-
>>  arch/arm/mach-s5pc100/include/mach/map.h |    2 +-
>>  arch/arm/mach-s5pv210/include/mach/map.h |    2 +-
>>  arch/arm/mach-s5pv310/include/mach/map.h |    2 +-
>>  5 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mach-s5p6442/include/mach/map.h 
>> b/arch/arm/mach-s5p6442/include/mach/map.h
>> index 203dd5a..59464f9 100644
>> --- a/arch/arm/mach-s5p6442/include/mach/map.h
>> +++ b/arch/arm/mach-s5p6442/include/mach/map.h
>> @@ -46,7 +46,7 @@
>>  #define S5P_PA_UART0         (S5P6442_PA_UART + 0x0)
>>  #define S5P_PA_UART1         (S5P6442_PA_UART + 0x400)
>>  #define S5P_PA_UART2         (S5P6442_PA_UART + 0x800)
>> -#define S5P_SZ_UART          SZ_256
>> +#define S5P_SZ_UART          (SZ_256 - 1)
> [...]
>
> This is wrong.  I'm sure the _size_ is actually 256.  In the resource
> definition it is not a size but a boundary that is required.  So it is
> not the S5P_SZ_UART definition that needs fixing but rather its usage.
>
> For example:
>
>                .start  = S5P6442_PA_PDMA,
>                .end    = S5P6442_PA_PDMA + SZ_4K,
>
> This is wrong. you should have instead:
>
>                .start  = S5P6442_PA_PDMA,
>                .end    = S5P6442_PA_PDMA + SZ_4K - 1,
>
> And so on where S5P_SZ_UART is used.
>
>
> Nicolas
>

Thanks Nicolas. I will correct the patch and resubmit.

Regards,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] ARM: S5P: Fix end address in memory resource information for UART devices

[Thomas Abraham]

For S5P platforms, the end address in memory resource information for UART
devices is one byte more than the intended value. Fix this by reducing the
end address by one byte.

Signed-off-by: Thomas Abraham 
---
 arch/arm/plat-s5p/dev-uart.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/plat-s5p/dev-uart.c b/arch/arm/plat-s5p/dev-uart.c
index 6a73428..afaf87f 100644
--- a/arch/arm/plat-s5p/dev-uart.c
+++ b/arch/arm/plat-s5p/dev-uart.c
@@ -28,7 +28,7 @@
 static struct resource s5p_uart0_resource[] = {
[0] = {
.start  = S5P_PA_UART0,
-   .end= S5P_PA_UART0 + S5P_SZ_UART,
+   .end= S5P_PA_UART0 + S5P_SZ_UART - 1,
.flags  = IORESOURCE_MEM,
},
[1] = {
@@ -51,7 +51,7 @@ static struct resource s5p_uart0_resource[] = {
 static struct resource s5p_uart1_resource[] = {
[0] = {
.start  = S5P_PA_UART1,
-   .end= S5P_PA_UART1 + S5P_SZ_UART,
+   .end= S5P_PA_UART1 + S5P_SZ_UART - 1,
.flags  = IORESOURCE_MEM,
},
[1] = {
@@ -74,7 +74,7 @@ static struct resource s5p_uart1_resource[] = {
 static struct resource s5p_uart2_resource[] = {
[0] = {
.start  = S5P_PA_UART2,
-   .end= S5P_PA_UART2 + S5P_SZ_UART,
+   .end= S5P_PA_UART2 + S5P_SZ_UART - 1,
.flags  = IORESOURCE_MEM,
},
[1] = {
@@ -98,7 +98,7 @@ static struct resource s5p_uart3_resource[] = {
 #if CONFIG_SERIAL_SAMSUNG_UARTS > 3
[0] = {
.start  = S5P_PA_UART3,
-   .end= S5P_PA_UART3 + S5P_SZ_UART,
+   .end= S5P_PA_UART3 + S5P_SZ_UART - 1,
.flags  = IORESOURCE_MEM,
},
[1] = {
@@ -123,7 +123,7 @@ static struct resource s5p_uart4_resource[] = {
 #if CONFIG_SERIAL_SAMSUNG_UARTS > 4
[0] = {
.start  = S5P_PA_UART4,
-   .end= S5P_PA_UART4 + S5P_SZ_UART,
+   .end= S5P_PA_UART4 + S5P_SZ_UART - 1,
.flags  = IORESOURCE_MEM,
},
[1] = {
@@ -148,7 +148,7 @@ static struct resource s5p_uart5_resource[] = {
 #if CONFIG_SERIAL_SAMSUNG_UARTS > 5
[0] = {
.start  = S5P_PA_UART5,
-   .end= S5P_PA_UART5 + S5P_SZ_UART,
+   .end= S5P_PA_UART5 + S5P_SZ_UART - 1,
.flags  = IORESOURCE_MEM,
},
[1] = {
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC] dt: add of_platform_bus_snoop() which attaches nodes to devices

[Thomas Abraham]

Hi Grant,

On 1 February 2011 03:31, Grant Likely  wrote:
> This patch implements an alternate method for using device tree data
> for populating machine device registration.  Traditionally, board
> support has directly generated and registered devices based on nodes
> in the device tree.  The board support code starts at the root of the
> tree and begins allocating devices for each device node it finds.
> Similarly, bus drivers (i2c, spi, etc.) use their child nodes to
> register child devices.  This model can be seen in almost all the powerpc
> board ports (arch/powerpc/platforms/*).
>
> However, for many of the ARM SoCs, there already exists complete board
> support for many SoCs that have their own code for registering the
> basic set of platform devices with non-trivial dependencies on clock
> structure and machine specific platform code.  While starting at the
> base of the tree and working up is certainly possible, it requires
> modifying a lot of machine support code to get it working.
>
> Instead, this patch provides an alternate approach.  Instead of
> starting at the root of the tree and working up, this patch allows the
> SoC support code to register its standard set of platform devices in
> the normal way.  However, it also registers a platform_bus notifier
> function which compares platform_device registrations with data in the
> device tree.  Whenever it finds a matching node, it increments the
> node reference count and assigns it to the device's of_node pointer so
> that it is available for the device driver to use and bind against.
> For example, an spi master driver would have access to the spi node
> which contains information about all the spi slaves on the bus.
>
> An example usage of this facility is to allow a single 'devicetree'
> board support file to support multiple machines all using the same
> SoC.  The common code would register SoC devices unconditionally, and
> the board support code would depend entirely on device tree data.
>
> Note: Board ports using this facility are still required to provide a
> fully populated device tree blob.  It is not a shortcut to providing
> an accurate device tree model of the machine to the point that it
> would be reasonably possible to switch to a direct registration model
> for all devices without change the device tree.  ie. The SoC still
> needs to be correctly identified and there should be nodes for all the
> discrete devices.
>
> I'm not convinced that this is the model to pursue over the long term,
> but it greatly simplifies the task of getting device tree support up
> and running, and it provides a migration path to full dt device
> registration (if it makes sense to do so).
>
> Signed-off-by: Grant Likely 
> ---

I have used this patch for Samsung's smdkv310 board and it works fine.
There are 4 uart port nodes in the dts file and the platform devices
for the 4 uart ports (which are instantiated in the platform code) get
the of_node pointer when the of_platform_bus_snoop function is used.
The driver then is able to pick up information from the device node.
The tough part, though, is moving the existing platform data into the
device tree and having the driver parse that data from the device
node.

Regards,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 5/7] serial: samsung: Get console register defaults from device tree

[Thomas Abraham]

The uart ports are used as console and due to console_init, the uart ports
are initialized prior to the uart driver's probe function is called.
During this intialization stage, the driver obtains the default port
register values from the platform data.

This patch adds support for obtaining the default port register values
from the device tree. The default values should be specified in the
'chosen' node of the device tree.

Signed-off-by: Thomas Abraham 
---
 drivers/tty/serial/samsung.c |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 2335eda..66fece9 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -1384,11 +1385,24 @@ static int s3c24xx_serial_init_ports(struct 
s3c24xx_uart_info **info)
struct s3c24xx_uart_port *ptr = s3c24xx_serial_ports;
struct platform_device **platdev_ptr;
int i;
+   unsigned int *condefs , len;
+   struct s3c2410_uartcfg *cfg;
 
dbg("s3c24xx_serial_init_ports: initialising ports...\n");
 
platdev_ptr = s3c24xx_uart_devs;
+   condefs = (u32 *)of_get_property(of_chosen, "console-defaults", &len);
+   if (condefs && (len / sizeof(unsigned int)) == 3) {
+   for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++) {
+   cfg = s3c24xx_dev_to_cfg(&(*platdev_ptr)->dev);
+   cfg->ucon = be32_to_cpu(condefs[0]);
+   cfg->ulcon = be32_to_cpu(condefs[1]);
+   cfg->ufcon = be32_to_cpu(condefs[2]);
+   platdev_ptr++;
+   }
+   }
 
+   platdev_ptr = s3c24xx_uart_devs;
for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++, ptr++, platdev_ptr++) 
{
s3c24xx_serial_init_port(ptr, info[i], *platdev_ptr);
}
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 6/7] ARM: s5pv310-dt: Enable snooping of platform_device registrations

[Thomas Abraham]

Enable snooping of platform_device registrations for s5pv310-dt machine.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-s5pv310/mach-s5pv310-dt.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv310/mach-s5pv310-dt.c 
b/arch/arm/mach-s5pv310/mach-s5pv310-dt.c
index 2578d73..ed5cae4 100644
--- a/arch/arm/mach-s5pv310/mach-s5pv310-dt.c
+++ b/arch/arm/mach-s5pv310/mach-s5pv310-dt.c
@@ -64,6 +64,7 @@ static struct of_device_id s5pv310_dt_match_table[] 
__initdata = {
 
 static void __init s5pv310_dt_machine_init(void)
 {
+   of_platform_bus_snoop(NULL, s5pv310_dt_match_table);
of_platform_bus_probe(NULL, s5pv310_dt_match_table, NULL);
 }
 
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 1/7] ARM: s5pv310-dt: Add s5pv310 machine with device tree support

[Thomas Abraham]

This patch adds a new Samsung's s5pv310 machine that boots with a minimal
device tree support. The bootargs, memory information, console port
register defaults and external crystal frequency are obtained from the
device tree during boot.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-s5pv310/Kconfig   |7 +++
 arch/arm/mach-s5pv310/Makefile  |1 +
 arch/arm/mach-s5pv310/mach-s5pv310-dt.c |   73 +++
 3 files changed, 81 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-s5pv310/mach-s5pv310-dt.c

diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
index 09c4c21..f0c1afd 100644
--- a/arch/arm/mach-s5pv310/Kconfig
+++ b/arch/arm/mach-s5pv310/Kconfig
@@ -127,6 +127,13 @@ config MACH_SMDKV310
help
  Machine support for Samsung SMDKV310
 
+config MACH_S5PV310_DT
+   bool "S5PV310 with device tree support"
+   select CPU_S5PV310
+   select USE_OF
+   help
+ Machine support for Samsung's S5PV310 SoC with device tree based 
initialization.
+
 endmenu
 
 comment "Configuration for HSMMC bus width"
diff --git a/arch/arm/mach-s5pv310/Makefile b/arch/arm/mach-s5pv310/Makefile
index 036fb38..7fa7842 100644
--- a/arch/arm/mach-s5pv310/Makefile
+++ b/arch/arm/mach-s5pv310/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
 
 obj-$(CONFIG_MACH_SMDKC210)+= mach-smdkc210.o
 obj-$(CONFIG_MACH_SMDKV310)+= mach-smdkv310.o
+obj-$(CONFIG_MACH_S5PV310_DT)  += mach-s5pv310-dt.o
 obj-$(CONFIG_MACH_UNIVERSAL_C210)  += mach-universal_c210.o
 
 # device support
diff --git a/arch/arm/mach-s5pv310/mach-s5pv310-dt.c 
b/arch/arm/mach-s5pv310/mach-s5pv310-dt.c
new file mode 100644
index 000..a5e33ff
--- /dev/null
+++ b/arch/arm/mach-s5pv310/mach-s5pv310-dt.c
@@ -0,0 +1,73 @@
+/*
+ * Samsung's S5PV310 machine with device tree enabled.
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * Platfrom data for uart devices. Some elements of the platform data will
+ * be set by the s5pv310 platform code and the rest will be obtained from the
+ * device tree. TODO: remove this when driver is able to obtain all the
+ * platform data information from the device tree.
+ */
+static struct s3c2410_uartcfg uartcfgs[CONFIG_SERIAL_SAMSUNG_UARTS] __initdata;
+
+static void __init s5pv310_dt_map_io(void)
+{
+   s5p_init_io(NULL, 0, S5P_VA_CHIPID);
+}
+
+static void s5pv310_dt_init_early(void)
+{
+   int i;
+   unsigned int *xtal_freq;
+
+   xtal_freq = (u32 *)of_get_property(of_chosen, "xtal-frequency", NULL);
+   if (!xtal_freq) {
+   printk(KERN_ERR "Ext crystal clock frequency not specified\n");
+   panic("Unknown external crystal clock frequency");
+   }
+
+   s3c24xx_init_clocks(be32_to_cpu(*xtal_freq));
+
+   for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++) {
+   uartcfgs[i].hwport = i;
+   uartcfgs[i].flags = 0;
+   }
+   s3c24xx_init_uarts(uartcfgs, ARRAY_SIZE(uartcfgs));
+}
+
+static char const *s5pv310_dt_compat[] = {
+   "samsung,s5pv310",
+   NULL
+};
+
+MACHINE_START(S5PV310_DT, "Samsung's S5PV310 with flattened device tree")
+   /* Maintainer: Kukjin Kim  */
+   /* Maintainer: Changhwan Youn  */
+   .init_irq   = s5pv310_init_irq,
+   .map_io = s5pv310_dt_map_io,
+   .timer  = &s5pv310_timer,
+   .dt_compat  = s5pv310_dt_compat,
+   .init_early = s5pv310_dt_init_early,
+MACHINE_END
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 3/7] ARM: s5pv310-dt: Add support for probing platform bus on s5pv310 dt-enabled machine

[Thomas Abraham]

This patch adds support for probing devices from device tree
for Samsung's s5pv310 device-tree enabled machine.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-s5pv310/mach-s5pv310-dt.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv310/mach-s5pv310-dt.c 
b/arch/arm/mach-s5pv310/mach-s5pv310-dt.c
index a5e33ff..2578d73 100644
--- a/arch/arm/mach-s5pv310/mach-s5pv310-dt.c
+++ b/arch/arm/mach-s5pv310/mach-s5pv310-dt.c
@@ -57,6 +57,16 @@ static void s5pv310_dt_init_early(void)
s3c24xx_init_uarts(uartcfgs, ARRAY_SIZE(uartcfgs));
 }
 
+static struct of_device_id s5pv310_dt_match_table[] __initdata = {
+   { .compatible = "simple-bus", },
+   {},
+};
+
+static void __init s5pv310_dt_machine_init(void)
+{
+   of_platform_bus_probe(NULL, s5pv310_dt_match_table, NULL);
+}
+
 static char const *s5pv310_dt_compat[] = {
"samsung,s5pv310",
NULL
@@ -67,6 +77,7 @@ MACHINE_START(S5PV310_DT, "Samsung's S5PV310 with flattened 
device tree")
/* Maintainer: Changhwan Youn  */
.init_irq   = s5pv310_init_irq,
.map_io = s5pv310_dt_map_io,
+   .init_machine   = s5pv310_dt_machine_init,
.timer  = &s5pv310_timer,
.dt_compat  = s5pv310_dt_compat,
.init_early = s5pv310_dt_init_early,
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 2/7] ARM: s5pv310-dt: Add a basic dts file for SMDKV310 machine

[Thomas Abraham]

This patch adds a basic dts file for Samsung's SMDKV310 board which
is based on the s5pv310 machine.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-s5pv310/mach-smdkv310.dts |   78 +++
 1 files changed, 78 insertions(+), 0 deletions(-)
 create mode 100755 arch/arm/mach-s5pv310/mach-smdkv310.dts

diff --git a/arch/arm/mach-s5pv310/mach-smdkv310.dts 
b/arch/arm/mach-s5pv310/mach-smdkv310.dts
new file mode 100755
index 000..75aa76d
--- /dev/null
+++ b/arch/arm/mach-s5pv310/mach-smdkv310.dts
@@ -0,0 +1,78 @@
+/dts-v1/;
+
+/ {
+   model = "smdkv310";
+   compatible = "samsung,s5pv310","samsung,smdkv310";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   cpu@0{
+   compatible = "arm,cortex-a9";
+   };
+
+   cpu@1 {
+   compatible = "arm,cortex-a9";
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x4000 0x0800>;
+   };
+
+   chosen {
+   bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M 
console=ttySAC1,115200 init=/linuxrc";
+   console-defaults = <0x3c5 0x3 0x111>;
+   xtal-frequency = <2400>;
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <&GIC>;
+   compatible = "samsung,s5pv310-soc","simple-bus";
+   ranges;
+
+   GIC:gic@0x1050 {
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   reg = <0x1050 0x1000>;
+   compatible = "samsung,s5pv310-gic","arm,gic";
+   };
+
+   watchdog@0x1006 {
+   reg = <0x1006 0x400>;
+   interrupts = <552>;
+   compatible = 
"samsung,s5pv310-wdt","samsung,s3c2410-wdt";
+   };
+
+   serial@0x1380 {
+   reg = <0x1380 0x100>;
+   interrupts = <16 18 17>;
+   reg-defaults = <0x3c5 0x3 0x111>;
+   compatible = 
"samsung,s5pv310-uart","samsung,s3c2410-uart";
+   };
+
+   serial@0x1381 {
+   reg = <0x1381 0x100>;
+   interrupts = <20 22 21>;
+   reg-defaults = <0x3c5 0x3 0x111>;
+   compatible = 
"samsung,s5pv310-uart","samsung,s3c2410-uart";
+   };
+
+   serial@0x1382 {
+   reg = <0x1382 0x100>;
+   interrupts = <24 26 25>;
+   reg-defaults = <0x3c5 0x3 0x111>;
+   compatible = 
"samsung,s5pv310-uart","samsung,s3c2410-uart";
+   };
+
+   serial@0x1383 {
+   reg = <0x1383 0x100>;
+   interrupts = <28 30 29>;
+   reg-defaults = <0x3c5 0x3 0x111>;
+   compatible = 
"samsung,s5pv310-uart","samsung,s3c2410-uart";
+   };
+   };
+};
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 4/7] watchdog: s3c2410: Add support for device tree based probe

[Thomas Abraham]

This patch adds the of_match_table to enable s3c2410-wdt driver
to be probed when watchdog device node is found in the device tree.

Signed-off-by: Thomas Abraham 
---
 drivers/watchdog/s3c2410_wdt.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index ae53662..a9edd50 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -592,6 +592,13 @@ static int s3c2410wdt_resume(struct platform_device *dev)
 #define s3c2410wdt_resume  NULL
 #endif /* CONFIG_PM */
 
+#ifdef CONFIG_OF
+static const struct of_device_id s3c2410_wdt_match[] = {
+   { .compatible = "samsung,s3c2410-wdt" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
+#endif
 
 static struct platform_driver s3c2410wdt_driver = {
.probe  = s3c2410wdt_probe,
@@ -602,6 +609,9 @@ static struct platform_driver s3c2410wdt_driver = {
.driver = {
.owner  = THIS_MODULE,
.name   = "s3c2410-wdt",
+#ifdef CONFIG_OF
+   .of_match_table = s3c2410_wdt_match,
+#endif
},
 };
 
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 0/7] Add Samsung's s5pv310 machine with device tree enabled

[Thomas Abraham]

This patchset adds Samsung's s5pv310 machine with device tree support. This
is based on

git://git.secretlab.ca/git/linux-2.6 devicetree/test

A new machine s5pv310-dt is added along with a dts file for the smdkv310 board.
Some of the features introduced in this patchset are

1. Tested on smdkv310 board and information such as bootargs, memory information
   and console port register defaults are obtained from the device tree.
2. Add basic device tree file for smdkv310 board.
3. Device tree based probe enabled in watchdog timer driver (s3c2410-wdt).
4. UART driver modified to obtain default console register values from
   device tree.

In addition, the first 5 patches have been tested with
git://git.secretlab.ca/git/linux-2.6 devicetree/arm

and (with minor modification [driver/tty/serial -> drivers/serial])
git://git.secretlab.ca/git/linux-2.6 devicetree/arm-linaro-2.6.37

Thomas Abraham (7):
  ARM: s5pv310-dt: Add s5pv310 machine with device tree support
  ARM: s5pv310-dt: Add a basic dts file for SMDKV310 machine
  ARM: s5pv310-dt: Add support for probing platform bus on s5pv310 dt-enabled 
machine
  watchdog: s3c2410: Add support for device tree based probe
  serial: samsung: Get console register defaults from device tree
  ARM: s5pv310-dt: Enable snooping of platform_device registrations
  serial: samsung: Get default port register settings from device tree

 arch/arm/mach-s5pv310/Kconfig   |7 +++
 arch/arm/mach-s5pv310/Makefile  |1 +
 arch/arm/mach-s5pv310/mach-s5pv310-dt.c |   85 +++
 arch/arm/mach-s5pv310/mach-smdkv310.dts |   78 
 drivers/tty/serial/samsung.c|   27 ++
 drivers/watchdog/s3c2410_wdt.c  |   10 
 6 files changed, 208 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-s5pv310/mach-s5pv310-dt.c
 create mode 100755 arch/arm/mach-s5pv310/mach-smdkv310.dts


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 7/7] serial: samsung: Get default port register settings from device tree

[Thomas Abraham]

The default uart port register settings are obtained from the platform data.
In addition to that, this patch adds support for obtaining the default uart port
register values from the uart node in device tree.

Signed-off-by: Thomas Abraham 
---
 drivers/tty/serial/samsung.c |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 66fece9..dda1d52 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1148,9 +1148,22 @@ int s3c24xx_serial_probe(struct platform_device *dev,
 {
struct s3c24xx_uart_port *ourport;
int ret;
+   unsigned int len, *regdef;
+   struct s3c2410_uartcfg *cfg;
 
dbg("s3c24xx_serial_probe(%p, %p) %d\n", dev, info, probe_index);
 
+   if (dev->dev.of_node) {
+   regdef = (u32 *)of_get_property(dev->dev.of_node,
+   "reg-defaults", &len);
+   if (regdef && (len / sizeof(unsigned int)) == 3) {
+   cfg = s3c24xx_dev_to_cfg(&dev->dev);
+   cfg->ucon = be32_to_cpu(regdef[0]);
+   cfg->ulcon = be32_to_cpu(regdef[1]);
+   cfg->ufcon = be32_to_cpu(regdef[2]);
+   }
+   }
+
ourport = &s3c24xx_serial_ports[probe_index];
probe_index++;
 
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/7] ARM: s5pv310-dt: Add a basic dts file for SMDKV310 machine

[Thomas Abraham]

Hi Grant,

On 17 February 2011 06:04, Grant Likely  wrote:
> On Sat, Feb 12, 2011 at 06:17:00PM +0530, Thomas Abraham wrote:
>> This patch adds a basic dts file for Samsung's SMDKV310 board which
>> is based on the s5pv310 machine.
>>
>> Signed-off-by: Thomas Abraham 
>
> Structure looks good.  Some comments below, but it is getting close.
>
>> ---
>>  arch/arm/mach-s5pv310/mach-smdkv310.dts |   78 
>> +++
>>  1 files changed, 78 insertions(+), 0 deletions(-)
>>  create mode 100755 arch/arm/mach-s5pv310/mach-smdkv310.dts
>>
>> diff --git a/arch/arm/mach-s5pv310/mach-smdkv310.dts 
>> b/arch/arm/mach-s5pv310/mach-smdkv310.dts
>> new file mode 100755
>> index 000..75aa76d
>> --- /dev/null
>> +++ b/arch/arm/mach-s5pv310/mach-smdkv310.dts
>> @@ -0,0 +1,78 @@
>> +/dts-v1/;
>> +
>> +/ {
>> +     model = "smdkv310";



>> +
>> +     chosen {
>> +             bootargs = "root=/dev/ram0 rw ramdisk=8192 
>> initrd=0x4100,8M console=ttySAC1,115200 init=/linuxrc";
>
> initrd address should be passed via the linux,initrd-start and
> linux,initrd-end properties.  U-Boot already knows how to do this so
> it shouldn't be encoded in the kernel parameters list.

Ok. "linux,initrd-start" and "linux,initrd-end" properties will be
added in chosen node and initrd parameters from bootargs removed as
below.

chosen {
bootargs = "root=/dev/ram0 console=ttySAC1,115200 init=/linuxrc";
linux,initrd-start=<0x4100>;
linux,initrd-end=<0x4080>;
} ;

>
>> +             console-defaults = <0x3c5 0x3 0x111>;
>
> Drop console-defaults.  The configuration should be encoded in the
> uart's device tree node.

The stage at which console_init is called, the code that initializes
the uart module for console operation does not have access to the uart
device tree node. Hence, the console-default register values are put
into the chosen node which is easier to access. If this not the right
approach, maybe the uart device tree node will have to be looked up by
using "for_each_compatible_node" or similar. Would you suggest using
for_each_compatible_node in this case.

>
>> +             xtal-frequency = <2400>;
>
> It looks like this is misplaced.  If this is the primary frequency for
> the system, then it should go either in the root node,  the soc node,
> or the cpu nodes.

This is the frequency of the crystal clock from which all the SoC
internal clocks are derived. The crystal clock frequency depends on
the board. So it was put into the chosen node. Since this is board
specific, this is added in the chosen node.

>
>> +     };
>> +



>> +
>> +             serial@0x1380 {
>> +                     reg = <0x1380 0x100>;
>> +                     interrupts = <16 18 17>;
>> +                     reg-defaults = <0x3c5 0x3 0x111>;
>
> reg-defaults doesn't sound like a very good binding.  It's better when
> the properties reflect what is trying to be configured instead of a
> set of magic values.  (That said, sometimes magic values are
> appropriate, but even then it needs to be well documented so that
> mere-mortals have a fighting chance of understanding and manipulating it).
>

Ok. This will be changed to be more informative.

>> +                     compatible = 
>> "samsung,s5pv310-uart","samsung,s3c2410-uart";
>> +             };



Thanks,
Thomas.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 4/7] watchdog: s3c2410: Add support for device tree based probe

[Thomas Abraham]

Hi Grant,

On 17 February 2011 05:47, Grant Likely  wrote:
> On Sat, Feb 12, 2011 at 06:17:02PM +0530, Thomas Abraham wrote:
>> This patch adds the of_match_table to enable s3c2410-wdt driver
>> to be probed when watchdog device node is found in the device tree.
>>
>> Signed-off-by: Thomas Abraham 
>> ---
>>  drivers/watchdog/s3c2410_wdt.c |   10 ++
>>  1 files changed, 10 insertions(+), 0 deletions(-)
>
> Need to add documentation for compatible = "samsung,s3c2410-wdt" to
> Documentation/devicetree/bindings/wdt before this patch can be merged.
>
> A couple more comments below, but I'm okay with this one.  I'd go
> ahead and submit it to the linux-watch...@vger.kernel.org list and cc:
> Wim.  It can be mainlined right away after fixing up the comments.
> I'll ack it when you repost and then work out with Wim if it should be
> merged through his tree or through mine.
>
>>
>> diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
>> index ae53662..a9edd50 100644
>> --- a/drivers/watchdog/s3c2410_wdt.c
>> +++ b/drivers/watchdog/s3c2410_wdt.c
>> @@ -592,6 +592,13 @@ static int s3c2410wdt_resume(struct platform_device 
>> *dev)
>>  #define s3c2410wdt_resume  NULL
>>  #endif /* CONFIG_PM */
>>
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id s3c2410_wdt_match[] = {
>> +     { .compatible = "samsung,s3c2410-wdt" },
>> +     {},
>> +};
>> +MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
>> +#endif
>
> #else
> #define s3c2410_wdt_match NULL
> #endif
>
>>
>>  static struct platform_driver s3c2410wdt_driver = {
>>       .probe          = s3c2410wdt_probe,
>> @@ -602,6 +609,9 @@ static struct platform_driver s3c2410wdt_driver = {
>>       .driver         = {
>>               .owner  = THIS_MODULE,
>>               .name   = "s3c2410-wdt",
>> +#ifdef CONFIG_OF
>> +             .of_match_table = s3c2410_wdt_match,
>> +#endif
>
> The #ifdef can be dropped here now.  .of_match_table is no longer conditional.
>

The of_match_table is conditional in devicetree/arm and
devicetree/test branches. Are you referring to any other branch?

Thanks,
Thomas.

>
>>       },
>>  };
>>
>> --
>> 1.6.6.rc2
>>
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 7/7] serial: samsung: Get default port register settings from device tree

[Thomas Abraham]

Hi Grant,

On 17 February 2011 05:56, Grant Likely  wrote:
> On Sat, Feb 12, 2011 at 06:17:05PM +0530, Thomas Abraham wrote:
>> The default uart port register settings are obtained from the platform data.
>> In addition to that, this patch adds support for obtaining the default uart 
>> port
>> register values from the uart node in device tree.
>>
>> Signed-off-by: Thomas Abraham 
>> ---
>>  drivers/tty/serial/samsung.c |   13 +
>>  1 files changed, 13 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>> index 66fece9..dda1d52 100644
>> --- a/drivers/tty/serial/samsung.c
>> +++ b/drivers/tty/serial/samsung.c
>> @@ -1148,9 +1148,22 @@ int s3c24xx_serial_probe(struct platform_device *dev,
>>  {
>>       struct s3c24xx_uart_port *ourport;
>>       int ret;
>> +     unsigned int len, *regdef;
>> +     struct s3c2410_uartcfg *cfg;
>>
>>       dbg("s3c24xx_serial_probe(%p, %p) %d\n", dev, info, probe_index);
>>
>> +     if (dev->dev.of_node) {
>> +             regdef = (u32 *)of_get_property(dev->dev.of_node,
>> +                                     "reg-defaults", &len);
>> +             if (regdef && (len / sizeof(unsigned int)) == 3) {
>> +                     cfg = s3c24xx_dev_to_cfg(&dev->dev);
>> +                     cfg->ucon = be32_to_cpu(regdef[0]);
>> +                     cfg->ulcon = be32_to_cpu(regdef[1]);
>> +                     cfg->ufcon = be32_to_cpu(regdef[2]);
>> +             }
>> +     }
>> +
>
> Same comment as before, per-uart configuration belongs in each ports
> device tree node.

The above configuration is obtained from the uart device tree node
(dev->dev.of_node).

>
> Also, don't forget to add binding documentation do
> Documentation/devicetree/bindings for the properties that you define
> for the samsung uart.

Ok. The documentation will be added.

Thanks,
Thomas.

>
> g.
>
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 0/7] Add Samsung's s5pv310 machine with device tree enabled

[Thomas Abraham]

Hi Grant,

On 17 February 2011 06:09, Grant Likely  wrote:
> On Sat, Feb 12, 2011 at 5:46 AM, Thomas Abraham
>  wrote:
>> This patchset adds Samsung's s5pv310 machine with device tree support. This
>> is based on
>>
>> git://git.secretlab.ca/git/linux-2.6 devicetree/test
>>
>> A new machine s5pv310-dt is added along with a dts file for the smdkv310 
>> board.
>> Some of the features introduced in this patchset are
>>
>> 1. Tested on smdkv310 board and information such as bootargs, memory 
>> information
>>   and console port register defaults are obtained from the device tree.
>> 2. Add basic device tree file for smdkv310 board.
>> 3. Device tree based probe enabled in watchdog timer driver (s3c2410-wdt).
>> 4. UART driver modified to obtain default console register values from
>>   device tree.
>
> Thanks Thomas,
>
> I've picked up patches 1-3 into my devicetree/test branch.  They still
> require some work, but they are close enough that I'm happy to at
> least have them in my series.  You can either send me replacement
> patches as need be, or build on top of devicetree/test.
>
> The remainder I've commented on and I'll leave alone until I get the
> next version.

Thanks for reviewing the patches. I will update the patchset and
submit a newer one.

Thanks,
Thomas.

>
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] ARM: EXYNOS4: Fix addruart macro

[Thomas Abraham]

Fix incorrect conditional execution of ldr instructions in
addruart macro.

Signed-off-by: Thomas Abraham 
Signed-off-by: Abhilash Kesavan 
---
 arch/arm/mach-exynos4/include/mach/debug-macro.S |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos4/include/mach/debug-macro.S 
b/arch/arm/mach-exynos4/include/mach/debug-macro.S
index 58bbd04..a442ef8 100644
--- a/arch/arm/mach-exynos4/include/mach/debug-macro.S
+++ b/arch/arm/mach-exynos4/include/mach/debug-macro.S
@@ -21,8 +21,8 @@
 */
 
.macro addruart, rp, rv
-   ldreq   \rp, = S3C_PA_UART
-   ldrne   \rv, = S3C_VA_UART
+   ldr \rp, = S3C_PA_UART
+   ldr \rv, = S3C_VA_UART
 #if CONFIG_DEBUG_S3C_UART != 0
add \rp, \rp, #(0x1 * CONFIG_DEBUG_S3C_UART)
add \rv, \rv, #(0x1 * CONFIG_DEBUG_S3C_UART)
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] ARM: EXYNOS4: Fix incorrect mapping of gpio pull-up macro to register setting

[Thomas Abraham]

The S3C_GPIO_PULL_UP macro value incorrectly maps to a reserved setting of GPIO
pull up/down registers on Exynos4 platform. Fix this incorrect mapping by adding
wrappers to the s3c_gpio_setpull_updown and s3c_gpio_getpull_updown functions.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-exynos4/gpiolib.c|8 +++---
 arch/arm/plat-samsung/gpio-config.c|   23 ++
 .../plat-samsung/include/plat/gpio-cfg-helpers.h   |   25 
 3 files changed, 52 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos4/gpiolib.c b/arch/arm/mach-exynos4/gpiolib.c
index d54ca6a..3a47c8e 100644
--- a/arch/arm/mach-exynos4/gpiolib.c
+++ b/arch/arm/mach-exynos4/gpiolib.c
@@ -23,14 +23,14 @@
 
 static struct s3c_gpio_cfg gpio_cfg = {
.set_config = s3c_gpio_setcfg_s3c64xx_4bit,
-   .set_pull   = s3c_gpio_setpull_updown,
-   .get_pull   = s3c_gpio_getpull_updown,
+   .set_pull   = s3c_gpio_setpull_exynos4,
+   .get_pull   = s3c_gpio_getpull_exynos4,
 };
 
 static struct s3c_gpio_cfg gpio_cfg_noint = {
.set_config = s3c_gpio_setcfg_s3c64xx_4bit,
-   .set_pull   = s3c_gpio_setpull_updown,
-   .get_pull   = s3c_gpio_getpull_updown,
+   .set_pull   = s3c_gpio_setpull_exynos4,
+   .get_pull   = s3c_gpio_getpull_exynos4,
 };
 
 /*
diff --git a/arch/arm/plat-samsung/gpio-config.c 
b/arch/arm/plat-samsung/gpio-config.c
index 1c0b040..2a710b0 100644
--- a/arch/arm/plat-samsung/gpio-config.c
+++ b/arch/arm/plat-samsung/gpio-config.c
@@ -320,6 +320,29 @@ s3c_gpio_pull_t s3c_gpio_getpull_s3c2443(struct 
s3c_gpio_chip *chip,
return pull;
 }
 #endif
+
+#ifdef CONFIG_CPU_EXYNOS4210
+int s3c_gpio_setpull_exynos4(struct s3c_gpio_chip *chip,
+   unsigned int off, s3c_gpio_pull_t pull)
+{
+   if (pull == S3C_GPIO_PULL_UP)
+   pull = 3;
+
+   return s3c_gpio_setpull_updown(chip, off, pull);
+}
+
+s3c_gpio_pull_t s3c_gpio_getpull_exynos4(struct s3c_gpio_chip *chip,
+   unsigned int off)
+{
+   s3c_gpio_pull_t pull;
+
+   pull = s3c_gpio_getpull_updown(chip, off);
+   if (pull == 3)
+   pull = S3C_GPIO_PULL_UP;
+
+   return pull;
+}
+#endif /* CONFIG_CPU_EXYNOS4210 */
 #endif
 
 #if defined(CONFIG_S3C_GPIO_PULL_UP) || defined(CONFIG_S3C_GPIO_PULL_DOWN)
diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg-helpers.h 
b/arch/arm/plat-samsung/include/plat/gpio-cfg-helpers.h
index 5603db0..75c46b9 100644
--- a/arch/arm/plat-samsung/include/plat/gpio-cfg-helpers.h
+++ b/arch/arm/plat-samsung/include/plat/gpio-cfg-helpers.h
@@ -247,5 +247,30 @@ extern int s3c_gpio_setpull_s3c2443(struct s3c_gpio_chip 
*chip,
 extern s3c_gpio_pull_t s3c_gpio_getpull_s3c2443(struct s3c_gpio_chip *chip,
unsigned int off);
 
+/**
+ * s3c_gpio_setpull_exynos4() - Pull configuration for Exynos 4210.
+ * @chip: The gpio chip that is being configured.
+ * @off: The offset for the GPIO being configured.
+ * @param: pull: The pull mode being requested.
+ *
+ * This is a wrapper function for s3c_gpio_setpull_updown() function.
+ * It provides a different mapping of S3C_GPIO_PULL_XXX to actual
+ * register settings.
+ */
+extern int s3c_gpio_setpull_exynos4(struct s3c_gpio_chip *chip,
+  unsigned int off, s3c_gpio_pull_t pull);
+
+/**
+ * s3c_gpio_getpull_exynos4() - Get configuration for Exynos 4210 pull 
resistors
+ * @chip: The gpio chip that the GPIO pin belongs to
+ * @off: The offset to the pin to get the configuration of.
+ *
+ * This is a wrapper function for s3c_gpio_getpull_updown() function.
+ * It provides a different mapping of S3C_GPIO_PULL_XXX to actual
+ * register settings.
+*/
+extern s3c_gpio_pull_t s3c_gpio_getpull_exynos4(struct s3c_gpio_chip *chip,
+  unsigned int off);
+
 #endif /* __PLAT_GPIO_CFG_HELPERS_H */
 
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH] ARM: EXYNOS4: Fix card insert/removal event detection on smdkv310 board

[Thomas Abraham]

On SMDKV310 board, a card detect gpio pin is available that is directly
connected to the io pad of the sdhci controller. Fix incorrect value
of cd_type field in platform data for sdhci instance 0 and 2.

Signed-off-by: Thomas Abraham 
---
 arch/arm/mach-exynos4/mach-smdkv310.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c 
b/arch/arm/mach-exynos4/mach-smdkv310.c
index 1526764..f6b1c7e 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -78,7 +78,7 @@ static struct s3c2410_uartcfg smdkv310_uartcfgs[] __initdata 
= {
 };
 
 static struct s3c_sdhci_platdata smdkv310_hsmmc0_pdata __initdata = {
-   .cd_type= S3C_SDHCI_CD_GPIO,
+   .cd_type= S3C_SDHCI_CD_INTERNAL,
.ext_cd_gpio= EXYNOS4_GPK0(2),
.ext_cd_gpio_invert = 1,
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
@@ -96,7 +96,7 @@ static struct s3c_sdhci_platdata smdkv310_hsmmc1_pdata 
__initdata = {
 };
 
 static struct s3c_sdhci_platdata smdkv310_hsmmc2_pdata __initdata = {
-   .cd_type= S3C_SDHCI_CD_GPIO,
+   .cd_type= S3C_SDHCI_CD_INTERNAL,
.ext_cd_gpio= EXYNOS4_GPK2(2),
.ext_cd_gpio_invert = 1,
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
-- 
1.6.6.rc2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Boot sanity testing of release candidate kernel

[Thomas Abraham]

On 25 May 2011 23:23, Deepak Saxena  wrote:
> On 25 May 2011 03:29, Tixy  wrote:
>> On Tue, 2011-05-24 at 19:42 -0700, Deepak Saxena wrote:
>>> The Kernel Working Group is getting ready to release the first of our new
>>> monthly development snapshot in a few days and we would like folks
>>> to do some quick sanity boot testing on their boards. Please
>>> grab or update the kernel from
>>> git://git.linaro.org/kernel/linux-linaro-2.6.38.git,
>>> and checkout the linaro-11.05-2.6.38 tag (which happens to be same
>>> as master at this moment) and give it a quick spin. Note that this is just
>>> the stock Linaro kernel and does not include any binary graphics drivers
>>> or other bits provided by Linaro's landing team kernels, so we just
>>> need the basic build and boot tested along with some simple
>>> testing of devices that can be used w/o extra drivers.
>>
>> Is there anywhere to report results of testing? I think it would be
>> useful for us to know what has and what hasn't been tested.
>
> For this "release", email is what we'll use and I'll collate all the
> info into a wiki page
> and maybe the release notes.
>
>
>> - Blocked kworker thread issue manifests [2]
>
> This needs a bug opened and assigned to one of the TI engineers in the KWG.
>
> Thanks,
> ~Deepak

Boots fine on Samsung's smdkv310 board with dt and non-dt.
Tested basic features of sdhci and ethernet drivers.

Thanks,
Thomas.


>
> ___
> linaro-kernel mailing list
> linaro-ker...@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-kernel
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V2] ARM: S5P: Fix compilation error for exynos4_defconfig

[Thomas Abraham]

On 3 June 2011 12:34, Tushar Behera  wrote:
> Added Kconfig entry for setup-usb-phy.c on which EHCI support is
> dependent on.
>
> Following the naming convention of other setup files, we have following
> renaming.
>        usb-phy.c ==> setup-usb-phy.c
>
> Signed-off-by: Tushar Behera 
> ---
>  arch/arm/mach-exynos4/Kconfig                      |    6 ++
>  arch/arm/mach-exynos4/Makefile                     |    2 +-
>  .../mach-exynos4/{usb-phy.c => setup-usb-phy.c}    |    0
>  3 files changed, 7 insertions(+), 1 deletions(-)
>  rename arch/arm/mach-exynos4/{usb-phy.c => setup-usb-phy.c} (100%)
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index b92c1e5..a45a022 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -91,6 +91,11 @@ config EXYNOS4_SETUP_FIMC
>        help
>          Common setup code for the camera interfaces.
>
> +config EXYNOS4_SETUP_USB_PHY
> +       bool
> +       help
> +         Common setup code for USB PHY controller
> +
>  # machine support
>
>  menu "EXYNOS4 Machines"
> @@ -176,6 +181,7 @@ config MACH_NURI
>        select EXYNOS4_SETUP_I2C3
>        select EXYNOS4_SETUP_I2C5
>        select EXYNOS4_SETUP_SDHCI
> +       select EXYNOS4_SETUP_USB_PHY
>        select SAMSUNG_DEV_PWM
>        help
>          Machine support for Samsung Mobile NURI Board.
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index a9bb94f..60fe5ec 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -56,4 +56,4 @@ obj-$(CONFIG_EXYNOS4_SETUP_KEYPAD)    += setup-keypad.o
>  obj-$(CONFIG_EXYNOS4_SETUP_SDHCI)      += setup-sdhci.o
>  obj-$(CONFIG_EXYNOS4_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
>
> -obj-$(CONFIG_USB_SUPPORT)              += usb-phy.o
> +obj-$(CONFIG_EXYNOS4_SETUP_USB_PHY)    += setup-usb-phy.o

Since plat-s5p/dev-ehci.c is the only consumer of setup-usb-phy.c,
could setup-usb-phy.o be made dependent on the S5P_DEV_USB_EHCI config
option? Any particular reason to create a new EXYNOS4_SETUP_USB_PHY
config option in this case? Will there be a case where usb phy
configuration code would be used irrespective of dev-ehci being used?

Thanks,
Thomas.

> diff --git a/arch/arm/mach-exynos4/usb-phy.c 
> b/arch/arm/mach-exynos4/setup-usb-phy.c
> similarity index 100%
> rename from arch/arm/mach-exynos4/usb-phy.c
> rename to arch/arm/mach-exynos4/setup-usb-phy.c
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev