Re: [PATCH/RESEND #3 5/7] arm: omap: smartreflex: clean ups all over

[Felipe Balbi]

On Tue, Nov 15, 2011 at 07:39:51PM -0500, valdis.kletni...@vt.edu wrote:
 On Tue, 15 Nov 2011 10:46:03 +0200, Felipe Balbi said:
 
  -   int srid;
  -   int ip_type;
  +   struct list_headnode;
  +   struct platform_device  *pdev;
  +   struct omap_sr_nvalue_table *nvalue_table;
  +   struct voltagedomain*voltdm;
 
 As long as you're de-tabifying the function names that caused the problem...
 
  int nvalue_count;
  -   boolautocomp_active;
  -   boolis_suspended;
 
 Why are you leaveing the rest of the struct tabified out to East Podunk?

de-tabifying ? I tabified the entire thing... Everything is aligned.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v8 11/20] OMAP2+: UART: Move errata handling from serial.c to omap-serial

[Govindraj]

On Tue, Nov 15, 2011 at 1:20 AM, Jon Hunter jon-hun...@ti.com wrote:
 Hi Govindraj,

[...]


        oh = uart-oh;
 -       uart-dma_enabled = 0;
        name = DRIVER_NAME;

        omap_up.dma_enabled = uart-dma_enabled;
        omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
        omap_up.flags = UPF_BOOT_AUTOCONF;
        omap_up.get_context_loss_count =
 omap_pm_get_dev_context_loss_count;
 +       omap_up.set_forceidle = omap_uart_set_forceidle;
 +       omap_up.set_noidle = omap_uart_set_noidle;
 +
 +       /* Enable the MDR1 errata for OMAP2/3/4 */
 +       if ((cpu_is_omap2430() || cpu_is_omap34xx() ||
 cpu_is_omap44xx())
 +                                               !cpu_is_ti816x())
 +               omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;

 I am not sure that this will apply the errata for OMAP3630 devices. I think
 we need cpu_is_omap36xx() above too. Or you may wish to do
 !cpu_class_is_omap1 and !cpu_is_omap2420.


Yes correct, I have updated this patch as here [1].

btw, omap-serial is applicable only for omap2+ so
I think cpu_class_is omap1 not applicable here
need to be handled in /mach-omap1/serial.c.

        pdata =omap_up;
        pdata_size = sizeof(struct omap_uart_port_info);
 @@ -519,10 +481,6 @@ void __init omap_serial_init_port(struct
 omap_board_data *bdata)
        if (((cpu_is_omap34xx() || cpu_is_omap44xx())  bdata-pads) ||
                (pdata-wk_en  pdata-wk_mask))
                device_init_wakeup(pdev-dev, true);
 -
 -       /* Enable the MDR1 errata for OMAP3 */
 -       if (cpu_is_omap34xx()  !cpu_is_ti816x())
 -               uart-errata |= UART_ERRATA_i202_MDR1_ACCESS;
  }

  /**

[...]


 +       /* Errata i291 */
 +       if (up-use_dma  pdata-set_forceidle)
 +               pdata-set_forceidle(up-pdev);
 +

 So it does appear that you are applying this to all devices. I think that
 this should only impact omap3.


Yes correct,  new one is has here [1].

--
Thanks,
Govindraj.R


[1]:

same is updated in here
(v8 uart runtime patches hosted in gitorious)
git://gitorious.org/runtime_3-0/runtime_3-0.git 3.2-rc1_uart_runtime.

From e7ac07903a813f624c4a19d93131d40a09eb8f81 Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Mon, 7 Nov 2011 19:00:33 +0530
Subject: [PATCH v8 11/20] OMAP2+: UART: Move errata handling from
serial.c to omap-serial

Move the errata handling mechanism from serial.c to omap-serial file
and utilise the same func in driver file.

Errata i202, i291 are moved to be handled with omap-serial
Moving the errata macro from serial.c file to driver header file
as from on errata will be handled in driver file itself.
Corrected errata id from chapter reference 2.15 to errata id i291.

Removed errata and dma_enabled fields from omap_uart_state struct
as they are no more needed with errata handling done within omap-serial.

Acked-by: Alan Cox a...@linux.intel.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
 arch/arm/mach-omap2/serial.c  |  101 -
 arch/arm/plat-omap/include/plat/omap-serial.h |7 ++
 drivers/tty/serial/omap-serial.c  |   68 -
 3 files changed, 102 insertions(+), 74 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 98e2666..9cbf230 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -42,8 +42,6 @@
 #include control.h
 #include mux.h

-#define UART_ERRATA_i202_MDR1_ACCESS   (0x1  1)
-
 /*
  * NOTE: By default the serial timeout is disabled as it causes lost characters
  * over the serial ports. This means that the UART clocks will stay on until
@@ -61,59 +59,17 @@ struct omap_uart_state {
void __iomem *wk_st;
void __iomem *wk_en;
u32 wk_mask;
-   u32 dma_enabled;

int clocked;

struct list_head node;
struct omap_hwmod *oh;
struct platform_device *pdev;
-
-   u32 errata;
 };

 static LIST_HEAD(uart_list);
 static u8 num_uarts;

-#if defined(CONFIG_PM)  defined(CONFIG_ARCH_OMAP3)
-
-/*
- * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
- * The access to uart register after MDR1 Access
- * causes UART to corrupt data.
- *
- * Need a delay =
- * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS)
- * give 10 times as much
- */
-static void omap_uart_mdr1_errataset(struct omap_uart_state *uart, u8 mdr1_val,
-   u8 fcr_val)
-{
-   u8 timeout = 255;
-
-   serial_write_reg(uart, UART_OMAP_MDR1, mdr1_val);
-   udelay(2);
-   serial_write_reg(uart, UART_FCR, fcr_val | UART_FCR_CLEAR_XMIT |
-   UART_FCR_CLEAR_RCVR);
-   /*
-* Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
-* TX_FIFO_E bit is 1.
-*/
-   while (UART_LSR_THRE != (serial_read_reg(uart, UART_LSR) 
-   (UART_LSR_THRE | UART_LSR_DR))) {
-   timeout--;
-   if (!timeout) {
- 

Re: Help with clk API

[Felipe Balbi]

Hi,

On Tue, Nov 15, 2011 at 06:45:17AM -0700, Paul Walmsley wrote:
 Hi Felipe
 
 On Fri, 11 Nov 2011, Felipe Balbi wrote:
 
  I have a doubt about using clk API to change CLKSEL_UTMI_P1 bit for a
  silicon errata (OMAP4460 i693) implementation.
  
  According to errata, I need to switch from external to internal clock
  during USB port suspend, wait 1ms and switch back from internal to
  external.
  
  How can I do that with clk API ? Is it by changing clk parent ? Any tips
  would be helpful ;-) thanks
 
 clk_set_parent() is the way to go.  There are 44xx struct clks that 
 references CLKSEL_UTMI_P1 and CLKSEL_UTMI_P2: see utmi_p1_gfclk and 
 utmi_p2_gfclk in mach-omap2/clock44xx_data.c.  The possible parent clocks 
 are listed in utmi_p1_gfclk_sel and utmi_p2_gfclk_sel in the same file.
 
 So you should be able to clk_get() the possible parent clocks and 
 utmi_p1_gfclk during module init, then use clk_set_parent() to switch 
 between them.  For example, for port 1:
 
 new_parent = clk_set_parent(utmi_p1_clk, init_60m_clk);
 /* test new_parent for error */
 /* delay 1ms */
 new_parent = clk_set_parent(utmi_p1_clk, xclk60mhsp1_ck);

ok, so if I understood correctly, xclk60mhsp1_ck is the external clock
for port 1 and init_60m_clk is the internal optional 60MHz clock, right?
So the final workaround would be something like:

clk = uhh-utmi_p1_fck;

/* ensure optional clock is disabled */
clk_disable(clk);

ret = clk_set_parent(clk, parent);
if (ret) {
dev_err(uhh-dev, can't change %s's parent to %s\n,
clk-name, parent-name);
return;
}

ret = clk_enable(clk);
if (ret) {
dev_err(uhh-dev, failed to enable %s\n, clk-name);
return;
}

/* wait 1ms */
msleep(1);

parent = uhh-xclk60mhsp1_ck;
clk_disable(clk);

ret = clk_set_parent(clk, parent);
if (ret) {
dev_err(uhh-dev, can't change %s's parent to %s\n,
clk-name, parent-name);
return;
}

ret = clk_enable(clk);
if (ret) {
dev_err(uhh-dev, failed to enable %s\n, clk-name);
}

and similarly for port 2, but :%s/p1/p2/g

right ?

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 0/3] OMAP serial device tree support

[Rajendra Nayak]

This series adds minimal device tree support for
OMAP-serial driver, and is based on top of the latest
runtime-PM changes from Govind[1] posted here[2].

The series passes minimal data that allows serial console
boot, with UART's initialised from device tree.
However some of low power support for UART and remote
wakeup needs more work.
Boot tested on OMAP4 panda and OMAP4 sdp boards.

[1] git://gitorious.org/runtime_3-0/runtime_3-0.git 3.2-rc1_uart_runtime
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58486.html

Rajendra Nayak (3):
  ARM: omap_device: handle first time activation of console device
  omap-serial: Add minimal device tree support
  ARM: omap: pass minimal SoC/board data for UART from dt

 .../devicetree/bindings/arm/omap/omap.txt  |1 +
 .../devicetree/bindings/serial/omap_serial.txt |8 
 arch/arm/boot/dts/omap3-beagle.dts |   17 +
 arch/arm/boot/dts/omap3.dtsi   |   27 ++
 arch/arm/boot/dts/omap4-panda.dts  |   17 +
 arch/arm/boot/dts/omap4-sdp.dts|   17 +
 arch/arm/boot/dts/omap4.dtsi   |   24 +
 arch/arm/mach-omap2/board-generic.c|1 -
 arch/arm/plat-omap/omap_device.c   |   33 +-
 drivers/tty/serial/omap-serial.c   |   37 +++-
 10 files changed, 179 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] omap-serial: Add minimal device tree support

[Rajendra Nayak]

Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smaridle bits and handling
remote wakeup and dynamic muxing.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 .../devicetree/bindings/serial/omap_serial.txt |9 +
 drivers/tty/serial/omap-serial.c   |   37 +++-
 2 files changed, 45 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..bf6d631
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,9 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be ti,omap-uart
+- ti,hwmods : Must be uartn, n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
+- ti,console_hwmod : boolean, UART used as debug console
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e1c8527..e3419c6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
 #include linux/serial_core.h
 #include linux/irq.h
 #include linux/pm_runtime.h
+#include linux/of.h
 
 #include plat/dma.h
 #include plat/dmtimer.h
@@ -1322,6 +1323,22 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, 
void *data)
return;
 }
 
+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+   struct omap_uart_port_info *omap_up_info;
+
+   omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+   if (!omap_up_info)
+   return NULL; /* out of memory */
+
+   of_property_read_u32(dev-of_node, clock-frequency,
+(*omap_up_info).uartclk);
+
+   return omap_up_info;
+}
+
+static atomic_t omap_uart_next_id = ATOMIC_INIT(0);
+
 static int serial_omap_probe(struct platform_device *pdev)
 {
struct uart_omap_port   *up;
@@ -1329,6 +1346,11 @@ static int serial_omap_probe(struct platform_device 
*pdev)
struct omap_uart_port_info *omap_up_info = pdev-dev.platform_data;
int ret = -ENOSPC;
 
+   if (pdev-dev.of_node) {
+   omap_up_info = of_get_uart_port_info(pdev-dev);
+   pdev-id = atomic_inc_return(omap_uart_next_id) - 1;
+   }
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(pdev-dev, no mem resource?\n);
@@ -1523,7 +1545,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;
 
-   if (!pdata-enable_wakeup)
+   if (!pdata || !pdata-enable_wakeup)
return 0;
 
if (pdata-get_context_loss_count)
@@ -1582,12 +1604,25 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = 
{
serial_omap_runtime_resume, NULL)
 };
 
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+   {
+   .compatible = ti,omap-uart,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#else
+#define omap_serial_of_match NULL
+#endif
+
 static struct platform_driver serial_omap_driver = {
.probe  = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name   = DRIVER_NAME,
.pm = serial_omap_dev_pm_ops,
+   .of_match_table = omap_serial_of_match,
},
 };
 
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ARM: omap_device: handle first time activation of console device

[Rajendra Nayak]

console device on OMAP is never reset or idled by hwmod post
initial setup, early during boot, for obvious reasons not to
break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation
of it using hwmod needs to be handled in such a way that a disable is
called followed by an enable of the hwmod, the subsequent activations
can then use the default activation technique.

To handle this add a new binding to identify a hwmod which is used as
the console device.

This patch is based on the what is done in serial.c for non-DT builds.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 .../devicetree/bindings/arm/omap/omap.txt  |1 +
 arch/arm/plat-omap/omap_device.c   |   33 +++-
 2 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dbdab40..46ffd41 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,6 +21,7 @@ Required properties:
 Optional properties:
 - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
   during suspend.
+- ti,console_hwmod: boolean, identifies the hwmod used as console device
 
 
 Example:
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index e8d9869..2b2d068 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -88,6 +88,7 @@
 #include linux/pm_runtime.h
 #include linux/of.h
 #include linux/notifier.h
+#include linux/console.h
 
 #include plat/omap_device.h
 #include plat/omap_hwmod.h
@@ -114,6 +115,32 @@ static struct omap_device_pm_latency 
omap_default_latency[] = {
}
 };
 
+static int omap_console_hwmod_enable(struct omap_device *od)
+{
+   console_lock();
+   /*
+* For early console we prevented hwmod reset and idle
+* So before we enable the uart clocks idle the console
+* uart clocks, then enable back the console uart hwmod.
+*/
+   omap_hwmod_idle(od-hwmods[0]);
+   omap_hwmod_enable(od-hwmods[0]);
+   console_unlock();
+   /*
+* Restore the default activate/deactivate funcs,
+* since now we have set the hwmod state machine right
+* with the idle/enable for console uart
+*/
+   od-pm_lats = omap_default_latency;
+   return 0;
+}
+
+static struct omap_device_pm_latency omap_console_latency[] = {
+   {
+   .activate_func   = omap_console_hwmod_enable,
+   },
+};
+
 /* Private functions */
 
 /**
@@ -342,6 +369,7 @@ static int omap_device_build_from_dt(struct platform_device 
*pdev)
struct omap_hwmod **hwmods;
struct omap_device *od;
struct omap_hwmod *oh;
+   struct omap_device_pm_latency *pm_lat = NULL;
struct device_node *node = pdev-dev.of_node;
const char *oh_name;
int oh_cnt, i, ret = 0;
@@ -370,7 +398,10 @@ static int omap_device_build_from_dt(struct 
platform_device *pdev)
hwmods[i] = oh;
}
 
-   od = omap_device_alloc(pdev, hwmods, oh_cnt, NULL, 0);
+   if (of_find_property(node, ti,console_hwmod, NULL))
+   pm_lat = omap_console_latency;
+
+   od = omap_device_alloc(pdev, hwmods, oh_cnt, pm_lat, 0);
if (!od) {
dev_err(pdev-dev, Cannot allocate omap_device for :%s\n,
oh_name);
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ARM: omap: pass minimal SoC/board data for UART from dt

[Rajendra Nayak]

Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/boot/dts/omap3-beagle.dts  |   17 +
 arch/arm/boot/dts/omap3.dtsi|   27 +++
 arch/arm/boot/dts/omap4-panda.dts   |   17 +
 arch/arm/boot/dts/omap4-sdp.dts |   17 +
 arch/arm/boot/dts/omap4.dtsi|   24 
 arch/arm/mach-omap2/board-generic.c |1 -
 6 files changed, 102 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..4c8f11e 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,20 @@
reg = 0x8000 0x2000; /* 512 MB */
};
 };
+
+uart1 {
+   clock-frequency = 4800;
+};
+
+uart2 {
+   clock-frequency = 4800;
+};
+
+uart3 {
+   ti,console_hwmod;
+   clock-frequency = 4800;
+};
+
+uart4 {
+   clock-frequency = 4800;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..ea591c5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
 / {
compatible = ti,omap3430, ti,omap3;
 
+   aliases {
+   uart1 = uart1;
+   uart2 = uart2;
+   uart3 = uart3;
+   uart4 = uart4;
+   };
+
cpus {
cpu@0 {
compatible = arm,cortex-a8;
@@ -59,5 +66,25 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+   uart1: uart@1 {
+   compatible = ti,omap-uart;
+   ti,hwmods = uart1;
+   };
+
+   uart2: uart@2 {
+   compatible = ti,omap-uart;
+   ti,hwmods = uart2;
+   };
+
+   uart3: uart@3 {
+   compatible = ti,omap-uart;
+   ti,hwmods = uart3;
+   };
+
+   uart4: uart@4 {
+   compatible = ti,omap-uart;
+   ti,hwmods = uart4;
+   };
};
 };
diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index c702657..aa65449 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -27,3 +27,20 @@
reg = 0x8000 0x4000; /* 1 GB */
};
 };
+
+uart1 {
+   clock-frequency = 4800;
+};
+
+uart2 {
+   clock-frequency = 4800;
+};
+
+uart3 {
+   ti,console_hwmod;
+   clock-frequency = 4800;
+};
+
+uart4 {
+   clock-frequency = 4800;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..524f5bf 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -27,3 +27,20 @@
reg = 0x8000 0x4000; /* 1 GB */
};
 };
+
+uart1 {
+   clock-frequency = 4800;
+};
+
+uart2 {
+   clock-frequency = 4800;
+};
+
+uart3 {
+   ti,console_hwmod;
+   clock-frequency = 4800;
+};
+
+uart4 {
+   clock-frequency = 4800;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..2378d1e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = gic;
 
aliases {
+   uart1 = uart1;
+   uart2 = uart2;
+   uart3 = uart3;
+   uart4 = uart4;
};
 
cpus {
@@ -99,5 +103,25 @@
reg = 0x48241000 0x1000,
  0x48240100 0x0100;
};
+
+   uart1: uart@1 {
+   compatible = ti,omap-uart;
+   ti,hwmods = uart1;
+   };
+
+   uart2: uart@2 {
+   compatible = ti,omap-uart;
+   ti,hwmods = uart2;
+   };
+
+   uart3: uart@3 {
+   compatible = ti,omap-uart;
+   ti,hwmods = uart3;
+   };
+
+   uart4: uart@4 {
+   compatible = ti,omap-uart;
+   ti,hwmods = uart4;
+   };
};
 };
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index fb55fa3..bb72809 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -70,7 +70,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
 
-   omap_serial_init();
omap_sdrc_init(NULL, NULL);
 
of_platform_populate(NULL, omap_dt_match_table, NULL, 

RE: [PATCH 2/2 v4] net/smsc911x: Add regulator support

[Robert MARKLUND]

 -Original Message-
 From: Mike Frysinger [mailto:vap...@gentoo.org]
 Sent: den 31 oktober 2011 19:21
 To: Robert MARKLUND
 Cc: net...@vger.kernel.org; Steve Glendinning; Mathieu Poirier; Paul Mundt; 
 linux...@vger.kernel.org;
 Sascha Hauer; Tony Lindgren; linux-omap@vger.kernel.org; 
 uclinux-dist-de...@blackfin.uclinux.org;
 Linus Walleij
 Subject: Re: [PATCH 2/2 v4] net/smsc911x: Add regulator support
 
 On Monday 31 October 2011 08:38:39 Robert Marklund wrote:
  ChangeLog v3-v4:
  - Remove dual prints and old comment on Mike's request.
  - Split the request_free fucntion on Mike and Sascha request.
 
 would be nice if the enable/disable were split as well ...

I interpret this as nice if, if it's a must be then ill change it.

 
  iounmap(pdata-ioaddr);
 
  +   (void)smsc911x_enable_disable_resources(pdev, false);
 
 i don't think the (void) cast is necessary

I like telling the reader of the code that I ignore the return value, 
I did not just forget it.

/R

 
 otherwise looks fine
 -mike
N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

RE: [RFC PATCH] arm:omap: cleanup split omap2/3/4_check_revision function

[Hiremath, Vaibhav]

 -Original Message-
 From: Hiremath, Vaibhav
 Sent: Monday, November 07, 2011 8:13 PM
 To: linux-omap@vger.kernel.org
 Cc: t...@atomide.com; Hiremath, Vaibhav
 Subject: [RFC PATCH] arm:omap: cleanup  split omap2/3/4_check_revision
 function
 
 This patch doesn't change functionality or behavior of the code
 execution; it barely cleans up the code and splits into SoC
 specific implementation for ID and feature detection; makes
 easier to add new SoC (especially for AM devices where we do not have
 feature register).
 
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 ---
  arch/arm/mach-omap2/id.c  |   48 +---
 
  arch/arm/mach-omap2/io.c  |6 +++-
  arch/arm/plat-omap/include/plat/cpu.h |4 ++-
  3 files changed, 28 insertions(+), 30 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
 index 7f47092..f1784ee 100644
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -226,9 +226,9 @@ static void __init omap4_check_features(void)
   }
  }
 
 -static void __init ti816x_check_features(void)
 +static void __init omap3_add_def_features(void)
  {
 - omap_features = OMAP3_HAS_NEON;
 + omap_features = OMAP3_HAS_NEON | OMAP3_HAS_L2CACHE;
  }
 
  static void __init omap3_check_revision(const char **cpu_rev)
 @@ -456,37 +456,29 @@ static void __init omap3_cpuinfo(const char
 *cpu_rev)
   printk()\n);
  }
 
 -/*
 - * Try to detect the exact revision of the omap we're running on
 - */
 -void __init omap2_check_revision(void)
 +void __init omap2xxx_check_revision(void)
 +{
 + omap24xx_check_revision();
 +}
 +
 +void __init omap3xxx_check_revision(bool has_feature_reg)
  {
   const char *cpu_rev;
 
 - /*
 -  * At this point we have an idea about the processor revision set
 -  * earlier with omap2_set_globals_tap().
 -  */
 - if (cpu_is_omap24xx()) {
 - omap24xx_check_revision();
 - } else if (cpu_is_omap34xx()) {
 - omap3_check_revision(cpu_rev);
 + omap3_check_revision(cpu_rev);
 
 - /* TI816X doesn't have feature register */
 - if (!cpu_is_ti816x())
 - omap3_check_features();
 - else
 - ti816x_check_features();
 + if (has_feature_reg)
 + omap3_check_features();
 + else
 + omap3_add_def_features();
 
 - omap3_cpuinfo(cpu_rev);
 - return;
 - } else if (cpu_is_omap44xx()) {
 - omap4_check_revision();
 - omap4_check_features();
 - return;
 - } else {
 - pr_err(OMAP revision unknown, please fix!\n);
 - }
 + omap3_cpuinfo(cpu_rev);
 +}
 +
 +void __init omap4xxx_check_revision(void)
 +{
 + omap4_check_revision();
 + omap4_check_features();
  }
 
  /*
 diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
 index 25d20ce..da9bc4a 100644
 --- a/arch/arm/mach-omap2/io.c
 +++ b/arch/arm/mach-omap2/io.c
 @@ -321,7 +321,6 @@ void __iomem *omap_irq_base;
 
  static void __init omap_common_init_early(void)
  {
 - omap2_check_revision();
   omap_ioremap_init();
   omap_init_consistent_dma_size();
  }
 @@ -363,6 +362,7 @@ static void __init omap_hwmod_init_postsetup(void)
  void __init omap2420_init_early(void)
  {
   omap2_set_globals_242x();
 + omap2xxx_check_revision();
   omap_common_init_early();
   omap2xxx_voltagedomains_init();
   omap242x_powerdomains_init();
 @@ -375,6 +375,7 @@ void __init omap2420_init_early(void)
  void __init omap2430_init_early(void)
  {
   omap2_set_globals_243x();
 + omap2xxx_check_revision();
   omap_common_init_early();
   omap2xxx_voltagedomains_init();
   omap243x_powerdomains_init();
 @@ -393,6 +394,7 @@ void __init omap2430_init_early(void)
  void __init omap3_init_early(void)
  {
   omap2_set_globals_3xxx();
 + omap3xxx_check_revision(true);
   omap_common_init_early();
   omap3xxx_voltagedomains_init();
   omap3xxx_powerdomains_init();
 @@ -425,6 +427,7 @@ void __init am35xx_init_early(void)
  void __init ti816x_init_early(void)
  {
   omap2_set_globals_ti816x();
 + omap3xxx_check_revision(false);
   omap_common_init_early();
   omap3xxx_voltagedomains_init();
   omap3xxx_powerdomains_init();
 @@ -439,6 +442,7 @@ void __init ti816x_init_early(void)
  void __init omap4430_init_early(void)
  {
   omap2_set_globals_443x();
 + omap4xxx_check_revision();
   omap_common_init_early();
   omap44xx_voltagedomains_init();
   omap44xx_powerdomains_init();
 diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-
 omap/include/plat/cpu.h
 index aa52d1e..51a0262 100644
 --- a/arch/arm/plat-omap/include/plat/cpu.h
 +++ b/arch/arm/plat-omap/include/plat/cpu.h
 @@ -420,7 +420,9 @@ IS_OMAP_TYPE(3517, 0x3517)
  #define OMAP446X_CLASS   0x44600044
  #define OMAP4460_REV_ES1_0   

Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

[Rob Herring]

On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
 console device on OMAP is never reset or idled by hwmod post
 initial setup, early during boot, for obvious reasons not to
 break early debug prints thrown on console.
 This leaves the console device enabled at boot and the first activation
 of it using hwmod needs to be handled in such a way that a disable is
 called followed by an enable of the hwmod, the subsequent activations
 can then use the default activation technique.
 
 To handle this add a new binding to identify a hwmod which is used as
 the console device.
 
 This patch is based on the what is done in serial.c for non-DT builds.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 ---
  .../devicetree/bindings/arm/omap/omap.txt  |1 +
  arch/arm/plat-omap/omap_device.c   |   33 
 +++-
  2 files changed, 33 insertions(+), 1 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
 b/Documentation/devicetree/bindings/arm/omap/omap.txt
 index dbdab40..46ffd41 100644
 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
 @@ -21,6 +21,7 @@ Required properties:
  Optional properties:
  - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
during suspend.
 +- ti,console_hwmod: boolean, identifies the hwmod used as console device
  

This doesn't seem right. Which console is not a h/w property. Why can't
you use aliases like other platforms are doing?

Also, it's not clear in the documentation where this (and
ti,no_idle_on_suspend) should go in the DT. Both seem like they should
be kernel cmdline params.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] arm:omap:serial:cleanup: use module rev instead of cpu_is_xxxx

[Hiremath, Vaibhav]

 -Original Message-
 From: Hilman, Kevin
 Sent: Tuesday, November 08, 2011 1:15 AM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; t...@atomide.com
 Subject: Re: [PATCH] arm:omap:serial:cleanup: use module rev instead of
 cpu_is_
 
 Vaibhav Hiremath hvaib...@ti.com writes:
 
  For OMAP3 uarts (module rev = 0x52) and all successor devices
  (omap4, TI81xx, AM33xx, etc...) empty fifo read errata is applicable,
  so we can get rid of cpu_is_ check and simply check for module rev
 here.
 
  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  ---
  NOTE: This patch has been tested on OMAP3EVM, and I expect to work on
 all OMAP3
  family of devices (including TI816x, TI814x, AM335x, etc...).
  but I am quite not sure about OMAP2 device, can anybody comment/test?
 
 Leaving OMAP2 as it is should be fine.
 
 There is a major UART cleanup in progress from Govindraj.  I suggest you
 rework this patch on top of his series from 10/18:
 
[PATCH v7 00/21] OMAP2+: UART: Runtime adaptation + cleanup
 
 although it still has a few changes to go through before being ready to
 merge.
 
Kevin,

Sorry, I missed to update on this.

We do not need this patch anymore. With latest cleanup series from Govindraj, 
it is already taken care. Please read below commit description -

-From Govindraj's commit (405b5009)
Serial_in and serial_out override for 8250 serial driver is also
removed. Empty fifo read fix is already taken care with omap-serial
driver with data ready bit check from LSR reg before reading RX fifo.
Also waiting for THRE(transmit hold reg empty) is done with wait_for_xmitr
in omap-serial driver.

Thanks,
Vaibhav

 Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] omap-serial: Add minimal device tree support

[Rob Herring]

On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
 Adapt the driver to device tree and pass minimal platform
 data from device tree needed for console boot.
 No power management features will be suppported for now
 since it requires more tweaks around OCP settings
 to toggle forceidle/noidle/smaridle bits and handling
 remote wakeup and dynamic muxing.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 ---
  .../devicetree/bindings/serial/omap_serial.txt |9 +
  drivers/tty/serial/omap-serial.c   |   37 
 +++-
  2 files changed, 45 insertions(+), 1 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
 
 diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
 b/Documentation/devicetree/bindings/serial/omap_serial.txt
 new file mode 100644
 index 000..bf6d631
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
 @@ -0,0 +1,9 @@
 +OMAP UART controller
 +
 +Required properties:
 +- compatible : should be ti,omap-uart

This seems too generic. There are no h/w differences in the uart since
the 1st OMAP1 device?

 +- ti,hwmods : Must be uartn, n being the instance number (1-based)
 +
 +Optional properties:
 +- clock-frequency : frequency of the clock input to the UART
 +- ti,console_hwmod : boolean, UART used as debug console
 diff --git a/drivers/tty/serial/omap-serial.c 
 b/drivers/tty/serial/omap-serial.c
 index e1c8527..e3419c6 100644
 --- a/drivers/tty/serial/omap-serial.c
 +++ b/drivers/tty/serial/omap-serial.c
 @@ -38,6 +38,7 @@
  #include linux/serial_core.h
  #include linux/irq.h
  #include linux/pm_runtime.h
 +#include linux/of.h
  
  #include plat/dma.h
  #include plat/dmtimer.h
 @@ -1322,6 +1323,22 @@ static void uart_tx_dma_callback(int lch, u16 
 ch_status, void *data)
   return;
  }
  
 +static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
 +{
 + struct omap_uart_port_info *omap_up_info;
 +
 + omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
 + if (!omap_up_info)
 + return NULL; /* out of memory */
 +
 + of_property_read_u32(dev-of_node, clock-frequency,
 +  (*omap_up_info).uartclk);

omap_up_info-uartclk

You want 0 to be the default freq?

 +
 + return omap_up_info;
 +}
 +
 +static atomic_t omap_uart_next_id = ATOMIC_INIT(0);
 +
  static int serial_omap_probe(struct platform_device *pdev)
  {
   struct uart_omap_port   *up;
 @@ -1329,6 +1346,11 @@ static int serial_omap_probe(struct platform_device 
 *pdev)
   struct omap_uart_port_info *omap_up_info = pdev-dev.platform_data;
   int ret = -ENOSPC;
  
 + if (pdev-dev.of_node) {
 + omap_up_info = of_get_uart_port_info(pdev-dev);
 + pdev-id = atomic_inc_return(omap_uart_next_id) - 1;

I don't think a driver changing this value is a good idea. Look at other
serial drivers like iMX for how they use aliases.

 + }
 +
   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   if (!mem) {
   dev_err(pdev-dev, no mem resource?\n);
 @@ -1523,7 +1545,7 @@ static int serial_omap_runtime_suspend(struct device 
 *dev)
   if (!up)
   return -EINVAL;
  
 - if (!pdata-enable_wakeup)
 + if (!pdata || !pdata-enable_wakeup)
   return 0;
  
   if (pdata-get_context_loss_count)
 @@ -1582,12 +1604,25 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops 
 = {
   serial_omap_runtime_resume, NULL)
  };
  
 +#if defined(CONFIG_OF)
 +static const struct of_device_id omap_serial_of_match[] = {
 + {
 + .compatible = ti,omap-uart,
 + },
 + {},
 +};
 +MODULE_DEVICE_TABLE(of, omap_serial_of_match);
 +#else
 +#define omap_serial_of_match NULL
 +#endif
 +
  static struct platform_driver serial_omap_driver = {
   .probe  = serial_omap_probe,
   .remove = serial_omap_remove,
   .driver = {
   .name   = DRIVER_NAME,
   .pm = serial_omap_dev_pm_ops,
 + .of_match_table = omap_serial_of_match,

Use of_match_ptr and get rid of the #else

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

[Cousson, Benoit]

Hi Rajendra,

On 11/16/2011 12:02 PM, Rajendra Nayak wrote:
 console device on OMAP is never reset or idled by hwmod post
 initial setup, early during boot, for obvious reasons not to
 break early debug prints thrown on console.
 This leaves the console device enabled at boot and the first activation
 of it using hwmod needs to be handled in such a way that a disable is
 called followed by an enable of the hwmod, the subsequent activations
 can then use the default activation technique.
 
 To handle this add a new binding to identify a hwmod which is used as
 the console device.
 
 This patch is based on the what is done in serial.c for non-DT builds.
 
 Signed-off-by: Rajendra Nayakrna...@ti.com
 ---
   .../devicetree/bindings/arm/omap/omap.txt  |1 +
   arch/arm/plat-omap/omap_device.c   |   33 
 +++-
   2 files changed, 33 insertions(+), 1 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
 b/Documentation/devicetree/bindings/arm/omap/omap.txt
 index dbdab40..46ffd41 100644
 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
 @@ -21,6 +21,7 @@ Required properties:
   Optional properties:
   - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
 during suspend.
 +- ti,console_hwmod: boolean, identifies the hwmod used as console device

This is not directly hwmod related,  

   Example:
 diff --git a/arch/arm/plat-omap/omap_device.c 
 b/arch/arm/plat-omap/omap_device.c
 index e8d9869..2b2d068 100644
 --- a/arch/arm/plat-omap/omap_device.c
 +++ b/arch/arm/plat-omap/omap_device.c
 @@ -88,6 +88,7 @@
   #includelinux/pm_runtime.h
   #includelinux/of.h
   #includelinux/notifier.h
 +#includelinux/console.h
 
   #includeplat/omap_device.h
   #includeplat/omap_hwmod.h
 @@ -114,6 +115,32 @@ static struct omap_device_pm_latency 
 omap_default_latency[] = {
   }
   };
 
 +static int omap_console_hwmod_enable(struct omap_device *od)
 +{
 + console_lock();
 + /*
 +  * For early console we prevented hwmod reset and idle

A period is missing. Or maybe it should a comma with not capital letter.

 +  * So before we enable the uart clocks idle the console
 +  * uart clocks, then enable back the console uart hwmod.
 +  */
 + omap_hwmod_idle(od-hwmods[0]);
 + omap_hwmod_enable(od-hwmods[0]);

Why do we have to idle - enable? The module is already enabled, isn't it?
The comment is not super clear for me :-)
Is the goal is to reset the IP?

 + console_unlock();
 + /*
 +  * Restore the default activate/deactivate funcs,
 +  * since now we have set the hwmod state machine right
 +  * with the idle/enable for console uart
 +  */
 + od-pm_lats = omap_default_latency;

I do not understand that part to?
This is not the default, but instead a specific one only for the serial driver.

It looks to me that you are overwriting the default one with a specific one.

 + return 0;
 +}
 +
 +static struct omap_device_pm_latency omap_console_latency[] = {
 + {
 + .activate_func   = omap_console_hwmod_enable,
 + },
 +};
 +
   /* Private functions */
 
   /**
 @@ -342,6 +369,7 @@ static int omap_device_build_from_dt(struct 
 platform_device *pdev)
   struct omap_hwmod **hwmods;
   struct omap_device *od;
   struct omap_hwmod *oh;
 + struct omap_device_pm_latency *pm_lat = NULL;
   struct device_node *node = pdev-dev.of_node;
   const char *oh_name;
   int oh_cnt, i, ret = 0;
 @@ -370,7 +398,10 @@ static int omap_device_build_from_dt(struct 
 platform_device *pdev)
   hwmods[i] = oh;
   }
 
 - od = omap_device_alloc(pdev, hwmods, oh_cnt, NULL, 0);
 + if (of_find_property(node, ti,console_hwmod, NULL))
 + pm_lat = omap_console_latency;

That's looks like a hack to me to add that specific serial hooks into the core 
code.
But I'm not sure to have any better idea, since the issue is the lack of 
function pointer in DT :-)

 + od = omap_device_alloc(pdev, hwmods, oh_cnt, pm_lat, 0);

It should not be 0 but the size of the array here: 
ARRAY_SIZE(omap_console_latency).

I'm wondering how it can work with zero since the code is doing that in 
omap_device_alloc:

od-pm_lats = kmemdup(pm_lats,
  sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
  GFP_KERNEL);

Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

[Cousson, Benoit]

Hi Rob,

On 11/16/2011 3:50 PM, Rob Herring wrote:

On 11/16/2011 05:02 AM, Rajendra Nayak wrote:

console device on OMAP is never reset or idled by hwmod post
initial setup, early during boot, for obvious reasons not to
break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation
of it using hwmod needs to be handled in such a way that a disable is
called followed by an enable of the hwmod, the subsequent activations
can then use the default activation technique.

To handle this add a new binding to identify a hwmod which is used as
the console device.

This patch is based on the what is done in serial.c for non-DT builds.

Signed-off-by: Rajendra Nayakrna...@ti.com
---
  .../devicetree/bindings/arm/omap/omap.txt  |1 +
  arch/arm/plat-omap/omap_device.c   |   33 +++-
  2 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dbdab40..46ffd41 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,6 +21,7 @@ Required properties:
  Optional properties:
  - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
during suspend.
+- ti,console_hwmod: boolean, identifies the hwmod used as console device



This doesn't seem right. Which console is not a h/w property. Why can't
you use aliases like other platforms are doing?

Also, it's not clear in the documentation where this (and
ti,no_idle_on_suspend) should go in the DT. Both seem like they should
be kernel cmdline params.


That raise the question about using DT to pass linux specific parameter.
We already discuss that on the mailing list, but never get a clear answer.
It seems that DT is already used to provide some OS specific information 
using the linux, prefix for example.


There are clearly a couple of parameters that can be provided by the 
bootloader, but that does not reflect a HW property.


So what is the guideline for that, should we stick to cmdline params for 
that?


Quoting Grant's documentation, runtime configuration is supported:

Runtime configuration

In most cases, a DT will be the sole method of communicating data from 
firmware to the kernel, so also gets used to pass in runtime and 
configuration data like the kernel parameters string and the location of 
an initrd image.


Most of this data is contained in the /chosen node, and when booting 
Linux it will look something like this:


chosen {
bootargs = console=ttyS0,115200 loglevel=8;
initrd-start = 0xc800;
initrd-end = 0xc820;
};

The bootargs property contains the kernel arguments, and the initrd-* 
properties define the address and size of an initrd blob. The chosen 
node may also optionally contain an arbitrary number of additional 
properties for platform-specific configuration data.



Does that mean that this is supported only if the bootloader does not 
support cmdline?


Thanks,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

[Rob Herring]

Benoit,

On 11/16/2011 09:14 AM, Cousson, Benoit wrote:
 Hi Rob,
 
 On 11/16/2011 3:50 PM, Rob Herring wrote:
 On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
 console device on OMAP is never reset or idled by hwmod post
 initial setup, early during boot, for obvious reasons not to
 break early debug prints thrown on console.
 This leaves the console device enabled at boot and the first activation
 of it using hwmod needs to be handled in such a way that a disable is
 called followed by an enable of the hwmod, the subsequent activations
 can then use the default activation technique.

 To handle this add a new binding to identify a hwmod which is used as
 the console device.

 This patch is based on the what is done in serial.c for non-DT builds.

 Signed-off-by: Rajendra Nayakrna...@ti.com
 ---
   .../devicetree/bindings/arm/omap/omap.txt  |1 +
   arch/arm/plat-omap/omap_device.c   |   33
 +++-
   2 files changed, 33 insertions(+), 1 deletions(-)

 diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
 b/Documentation/devicetree/bindings/arm/omap/omap.txt
 index dbdab40..46ffd41 100644
 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
 @@ -21,6 +21,7 @@ Required properties:
   Optional properties:
   - ti,no_idle_on_suspend: When present, it prevents the PM to idle
 the module
 during suspend.
 +- ti,console_hwmod: boolean, identifies the hwmod used as console
 device


 This doesn't seem right. Which console is not a h/w property. Why can't
 you use aliases like other platforms are doing?

 Also, it's not clear in the documentation where this (and
 ti,no_idle_on_suspend) should go in the DT. Both seem like they should
 be kernel cmdline params.
 
 That raise the question about using DT to pass linux specific parameter.
 We already discuss that on the mailing list, but never get a clear answer.
 It seems that DT is already used to provide some OS specific information
 using the linux, prefix for example.

True, but linux, properties will always face resistance and scrutiny.

 There are clearly a couple of parameters that can be provided by the
 bootloader, but that does not reflect a HW property.
 
 So what is the guideline for that, should we stick to cmdline params for
 that?
 

I would say that if the setting does not depend on something in the DT,
then the cmdline is the right place. If you have a property that
references a phandle, then it can't be on the cmdline. For console
selection, there is already a defined way to select it with
console=blah. And there is an agreed way to define indexes in the DT
with aliases.

How were these properties set without DT?

 Quoting Grant's documentation, runtime configuration is supported:
 
 Runtime configuration
 
 In most cases, a DT will be the sole method of communicating data from
 firmware to the kernel, so also gets used to pass in runtime and
 configuration data like the kernel parameters string and the location of
 an initrd image.
 
 Most of this data is contained in the /chosen node, and when booting
 Linux it will look something like this:
 
 chosen {
 bootargs = console=ttyS0,115200 loglevel=8;
 initrd-start = 0xc800;
 initrd-end = 0xc820;
 };
 
 The bootargs property contains the kernel arguments, and the initrd-*
 properties define the address and size of an initrd blob. The chosen
 node may also optionally contain an arbitrary number of additional
 properties for platform-specific configuration data.
 
 
 Does that mean that this is supported only if the bootloader does not
 support cmdline?

No. I think it means chosen can be extended. However, how many other
chosen properties are defined? Not very many. Clearly, it's not a place
for adding whatever random property you want. chosen is really the boot
interface between the bootloader and kernel as it is ATAG type data.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH Resend] ARM: OMAP2+: Remove empty io.h

[Thomas Weber]

The file arch/arm/mach-omap2/io.h is empty, so we can remove it.

Signed-off-by: Thomas Weber we...@corscience.de
---
 0 files changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/io.h

diff --git a/arch/arm/mach-omap2/io.h b/arch/arm/mach-omap2/io.h
deleted file mode 100644
index e69de29..000
-- 
1.7.8.rc1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] ARM: OMAP: hwmod fix for 3.2-rc3

[Cousson, Benoit]

Hi Tony,

That bug is becoming annoying, and a bunch of folks are hitting that issue 
during DT dev for 3.3, so it will be cool to fix that ASAP.

It might already be in Paul's queue for 3.2-rc3.

Thanks,
Benoit


The following changes since commit 6aaf05f472c97ebceff47d9eef464574f1a55727:
  Linus Torvalds (1):
Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6

are available in the git repository at:

  git://gitorious.org/omap-pm/linux.git for_3.2-rc/hwmod-fixes

sricharan (1):
  ARM: OMAP: hwmod: Fix the addr space, irq, dma count APIs

 arch/arm/mach-omap2/omap_hwmod.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

[Cousson, Benoit]

On 11/16/2011 4:41 PM, Rob Herring wrote:

Benoit,

On 11/16/2011 09:14 AM, Cousson, Benoit wrote:

Hi Rob,

On 11/16/2011 3:50 PM, Rob Herring wrote:

On 11/16/2011 05:02 AM, Rajendra Nayak wrote:

console device on OMAP is never reset or idled by hwmod post
initial setup, early during boot, for obvious reasons not to
break early debug prints thrown on console.
This leaves the console device enabled at boot and the first activation
of it using hwmod needs to be handled in such a way that a disable is
called followed by an enable of the hwmod, the subsequent activations
can then use the default activation technique.

To handle this add a new binding to identify a hwmod which is used as
the console device.

This patch is based on the what is done in serial.c for non-DT builds.

Signed-off-by: Rajendra Nayakrna...@ti.com
---
   .../devicetree/bindings/arm/omap/omap.txt  |1 +
   arch/arm/plat-omap/omap_device.c   |   33
+++-
   2 files changed, 33 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dbdab40..46ffd41 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,6 +21,7 @@ Required properties:
   Optional properties:
   - ti,no_idle_on_suspend: When present, it prevents the PM to idle
the module
 during suspend.
+- ti,console_hwmod: boolean, identifies the hwmod used as console
device



This doesn't seem right. Which console is not a h/w property. Why can't
you use aliases like other platforms are doing?

Also, it's not clear in the documentation where this (and
ti,no_idle_on_suspend) should go in the DT. Both seem like they should
be kernel cmdline params.


That raise the question about using DT to pass linux specific parameter.
We already discuss that on the mailing list, but never get a clear answer.
It seems that DT is already used to provide some OS specific information
using the linux, prefix for example.


True, but linux, properties will always face resistance and scrutiny.


OK, that's good to know. So we should avoid abusing that kind of prefix.


There are clearly a couple of parameters that can be provided by the
bootloader, but that does not reflect a HW property.

So what is the guideline for that, should we stick to cmdline params for
that?



I would say that if the setting does not depend on something in the DT,
then the cmdline is the right place. If you have a property that
references a phandle, then it can't be on the cmdline. For console
selection, there is already a defined way to select it with
console=blah. And there is an agreed way to define indexes in the DT
with aliases.


OK, I saw that in some DT adapted serial driver, we can retrieve the 
index from the string serialx and thus can get the console from the 
ttyS number.



How were these properties set without DT?


From the board file most of the time. Or using some dirty hacks here 
and there :-)



Quoting Grant's documentation, runtime configuration is supported:

Runtime configuration

In most cases, a DT will be the sole method of communicating data from
firmware to the kernel, so also gets used to pass in runtime and
configuration data like the kernel parameters string and the location of
an initrd image.

Most of this data is contained in the /chosen node, and when booting
Linux it will look something like this:

 chosen {
 bootargs = console=ttyS0,115200 loglevel=8;
 initrd-start =0xc800;
 initrd-end =0xc820;
 };

The bootargs property contains the kernel arguments, and the initrd-*
properties define the address and size of an initrd blob. The chosen
node may also optionally contain an arbitrary number of additional
properties for platform-specific configuration data.


Does that mean that this is supported only if the bootloader does not
support cmdline?


No. I think it means chosen can be extended. However, how many other
chosen properties are defined? Not very many. Clearly, it's not a place
for adding whatever random property you want. chosen is really the boot
interface between the bootloader and kernel as it is ATAG type data.


OK, thanks for the clarification.

Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] mmc: Logging neatening

[Mike Frysinger]

On Tuesday 15 November 2011 20:48:05 NamJae Jeon wrote:
 2011/11/16 Joe Perches j...@perches.com:
 mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci
  interrupt */
  
  -   dev_info(pdev-dev, DW MMC controller at irq %d, 
  -%d bit host data width, 
  -%u deep fifo\n,
  +   dev_info(pdev-dev,
  +   DW MMC controller at irq %d, %d bit host data width, %u deep
  fifo\n, irq, width, fifo_size);
 
 I think that tab is needed this DW MMC controller at irq  ?

looks to me like this was the only part you replied to.  could you please snip 
the unrelated context in the future ?  no reason to include ~1700 lines of 
context when you only replying to like ~10 lines.
-mike


signature.asc
Description: This is a digitally signed message part.

[PATCHv2] ARM: OMAP: hsmmc: Fix mux for non-OMAP pins

[Thomas Weber]

The Devkit8000 uses a TWL4030 pin for card detection.
Thats why the error:
_omap_mux_init_gpio: Could not set gpio192
occurs.

This patch checks that the pin is on OMAP before
calling omap_mux_init_gpio.

Signed-off-by: Thomas Weber we...@corscience.de
---
Changelog:
v2: Remove backslash at end of line

 arch/arm/mach-omap2/hsmmc.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index f4a1020..c3aea79 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -200,10 +200,12 @@ static int nop_mmc_set_power(struct device *dev, int 
slot, int power_on,
 static inline void omap_hsmmc_mux(struct omap_mmc_platform_data 
*mmc_controller,
int controller_nr)
 {
-   if (gpio_is_valid(mmc_controller-slots[0].switch_pin))
+   if (gpio_is_valid(mmc_controller-slots[0].switch_pin) 
+   (mmc_controller-slots[0].switch_pin  OMAP_MAX_GPIO_LINES))
omap_mux_init_gpio(mmc_controller-slots[0].switch_pin,
OMAP_PIN_INPUT_PULLUP);
-   if (gpio_is_valid(mmc_controller-slots[0].gpio_wp))
+   if (gpio_is_valid(mmc_controller-slots[0].gpio_wp) 
+   (mmc_controller-slots[0].gpio_wp  OMAP_MAX_GPIO_LINES))
omap_mux_init_gpio(mmc_controller-slots[0].gpio_wp,
OMAP_PIN_INPUT_PULLUP);
if (cpu_is_omap34xx()) {
-- 
1.7.7.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 11/20] OMAP2+: UART: Move errata handling from serial.c to omap-serial

[Jon Hunter]

Hi Govindraj,

On 11/16/2011 4:13, Govindraj wrote:

On Tue, Nov 15, 2011 at 1:20 AM, Jon Hunterjon-hun...@ti.com  wrote:

Hi Govindraj,


[...]



oh = uart-oh;
-   uart-dma_enabled = 0;
name = DRIVER_NAME;

omap_up.dma_enabled = uart-dma_enabled;
omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
omap_up.flags = UPF_BOOT_AUTOCONF;
omap_up.get_context_loss_count =
omap_pm_get_dev_context_loss_count;
+   omap_up.set_forceidle = omap_uart_set_forceidle;
+   omap_up.set_noidle = omap_uart_set_noidle;
+
+   /* Enable the MDR1 errata for OMAP2/3/4 */
+   if ((cpu_is_omap2430() || cpu_is_omap34xx() ||
cpu_is_omap44xx())
+   !cpu_is_ti816x())
+   omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;


I am not sure that this will apply the errata for OMAP3630 devices. I think
we need cpu_is_omap36xx() above too. Or you may wish to do
!cpu_class_is_omap1 and !cpu_is_omap2420.



Yes correct, I have updated this patch as here [1].


Thanks! Looks good.


btw, omap-serial is applicable only for omap2+ so
I think cpu_class_is omap1 not applicable here
need to be handled in /mach-omap1/serial.c.


Duh! I missed that. We are good then.

Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] AM35xx: DSS: there is no VDDS_DSI on AM35xx

[Ilya Yanok]

Hi Archit,

On 09.11.2011 14:10, Archit Taneja wrote:
 AM35xx don't have VDDS_DSI regulator.
 
 AM35xx do have vdds_dsi regulator. Are you saying that your particular
 board doesn't have vdds_dsi connected to a regulator?
 
 I assumed that vdds_dsi regulator was required for DPI to function
 properly on omap3 devices.

Could you please give me some pointer how to find VDDS_DSI on AM3517?
Looking at the AM3517 datasheet neither I nor board manufactured can't
find any reference of VDDS_DSI so we can't determine how it is powered.

Of course I can register fake fixed regulator from the board code but
I'd like to find the proper solution for this.

Regards, Ilya.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP: PM: only register TWL with voltage layer when device is present

[Kevin Hilman]

Premi, Sanjeev pr...@ti.com writes:

  

 -Original Message-
 From: Hilman, Kevin 
 Sent: Friday, November 11, 2011 12:04 AM
 To: Premi, Sanjeev
 Cc: linux-omap@vger.kernel.org; 
 linux-arm-ker...@lists.infradead.org; Koyamangalath, Abhilash
 Subject: Re: [PATCH] ARM: OMAP: PM: only register TWL with 
 voltage layer when device is present
 
 Premi, Sanjeev pr...@ti.com writes:
 
  Current code registers voltage layer details for TWL PMIC 
 even when a
  TWL has not been registered.  Fix this to only register 
 the TWL with
  voltage layer when the TWL PMIC is initialized by board-level code.
  
  Signed-off-by: Kevin Hilman khil...@ti.com
 
 [...]
 
  I have been out-of-loop from PM for some time. So my query may be
  redundant:
 
  1) What happens when different PMIC (not TWL series) is registered
 for AM35x? e.g. TPS65023
 http://www.spinics.net/lists/linux-omap/msg48630.html
 
  2) Wouldn't we still fall back into omap3_twl_init()?
 
 I'm not sure I follow the question.
 
 If you're not using a TWL PMIC (or similar derivative) then
 omap*_twl_init() should not be called.
 
 If you are using a TWL PMIC, then no, the omap*_twl_init functions
 should not be called.

 When I read this function (in the patch), if pmic_i2c_board_info.irq
 is non-zero, omap3_twl_init() and omap4_twl_init() are called.

 So my question was, for the case when PMIC is not TWL family. Then,
 is checking .irq sufficient to prevent the execution of twl specific
 functions.

If PMIC is not TWL family, then I don't expect any functions in
twl_common.c to be called.

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RESEND #3 6/7] arm: omap: smartreflex: fix IRQ handling bug

[Kevin Hilman]

Felipe Balbi ba...@ti.com writes:

F fix a bug which has been on this driver since
 it was added by the original commit 984aa6db
 which would never clear IRQSTATUS bits.

 Signed-off-by: Felipe Balbi ba...@ti.com

Queuing this fix for v3.2-rc (branch: for_3.2/fixes/pm)

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RESEND #3 0/7] SmartReflex Patches

[Kevin Hilman]

+Jean

Felipe Balbi ba...@ti.com writes:

 here's a bunch of patches to smartreflex which have been pending
 for months.

The SmartReflex code is going through a major rework by Jean so it can be
converted into a real driver and moved under drivers/*.

I'll leave it to Jean to incorporate these changes into his rework as he
sees fit, although I've queued the IRQ fix for v3.2-rc.

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 10/11] omap3+: use lp params for calculating clock setup times

[Kevin Hilman]

Hi Tero,

Tero Kristo t-kri...@ti.com writes:

[...]

 One question though, do you want to have the auto_ret / auto_off
 support along with these changes? Some of the code in this set is only
 used when the auto_ret / auto_off is in, and it also makes it a bit
 more easier to test the resulting stuff.

Yes, it would be helpful to include that for better testing.  You can
add that as separate patches at the end of the series.

Thanks,

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH Resend] ARM: OMAP2+: Remove empty io.h

[Kevin Hilman]

Thomas Weber we...@corscience.de writes:

 The file arch/arm/mach-omap2/io.h is empty, so we can remove it.

 Signed-off-by: Thomas Weber we...@corscience.de

It's empty and unused elsewhere.

Acked-by: Kevin Hilman khil...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] omap_dss: add FocalTech ETM070003DH6 display support

[Ilya Yanok]

Hi guys,

what about this patch? Can it be applied? It's pretty independent from
other ones.

Regards, Ilya.

On 09.11.2011 04:12, Ilya Yanok wrote:
 Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
 display driver.
 
 Signed-off-by: Ilya Yanok ya...@emcraft.com
 ---
  drivers/video/omap2/displays/panel-generic-dpi.c |   24 
 ++
  1 files changed, 24 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
 b/drivers/video/omap2/displays/panel-generic-dpi.c
 index 519c47d..42bfe47 100644
 --- a/drivers/video/omap2/displays/panel-generic-dpi.c
 +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
 @@ -297,6 +297,30 @@ static struct panel_config generic_dpi_panels[] = {
  
   .name   = apollon,
   },
 + /* FocalTech ETM070003DH6 */
 + {
 + {
 + .x_res  = 800,
 + .y_res  = 480,
 +
 + .pixel_clock= 28000,
 +
 + .hsw= 48,
 + .hfp= 40,
 + .hbp= 40,
 +
 + .vsw= 3,
 + .vfp= 13,
 + .vbp= 29,
 + },
 + .acbi   = 0x0,
 + .acb= 0x28,
 + .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
 +   OMAP_DSS_LCD_IHS,
 + .power_on_delay = 50,
 + .power_off_delay= 100,
 + .name   = focaltech_etm070003dh6,
 + },
  };
  
  struct panel_drv_data {

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] am35xx-emac: move generic EMAC init to separate file

[Ilya Yanok]

AM35xx SoCs include DaVinci EMAC IP. Initialization code in
board-am3517evm.c is pretty board independent and will work for any
AM35xx based board so move this code to it's own file to be reused by
other boards.

Signed-off-by: Ilya Yanok ya...@emcraft.com
---
 arch/arm/mach-omap2/Makefile  |3 +
 arch/arm/mach-omap2/am35xx-emac.c |  136 +
 arch/arm/mach-omap2/am35xx-emac.h |   17 
 arch/arm/mach-omap2/board-am3517evm.c |  114 +---
 4 files changed, 158 insertions(+), 112 deletions(-)
 create mode 100644 arch/arm/mach-omap2/am35xx-emac.c
 create mode 100644 arch/arm/mach-omap2/am35xx-emac.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69ab1c0..3256301 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -267,4 +267,7 @@ obj-$(CONFIG_ARCH_OMAP4)+= hwspinlock.o
 disp-$(CONFIG_OMAP2_DSS)   := display.o
 obj-y  += $(disp-m) $(disp-y)
 
+emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
+obj-y  += $(emac-m) $(emac-y)
+
 obj-y  += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/am35xx-emac.c 
b/arch/arm/mach-omap2/am35xx-emac.c
new file mode 100644
index 000..e5ad303
--- /dev/null
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -0,0 +1,136 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ * Author: Ranjith Lohithakshan ranji...@ti.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 
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/davinci_emac.h
+#include linux/platform_device.h
+#include plat/irqs.h
+#include mach/am35xx.h
+
+#include control.h
+
+static struct mdio_platform_data am35xx_mdio_pdata;
+
+static struct resource am35xx_mdio_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+   .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device am35xx_mdio_device = {
+   .name   = davinci_mdio,
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(am35xx_mdio_resources),
+   .resource   = am35xx_mdio_resources,
+   .dev.platform_data = am35xx_mdio_pdata,
+};
+
+static void am35xx_enable_ethernet_int(void)
+{
+   u32 regval;
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+   AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am35xx_disable_ethernet_int(void)
+{
+   u32 regval;
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct emac_platform_data am35xx_emac_pdata = {
+   .ctrl_reg_offset= AM35XX_EMAC_CNTRL_OFFSET,
+   .ctrl_mod_reg_offset= AM35XX_EMAC_CNTRL_MOD_OFFSET,
+   .ctrl_ram_offset= AM35XX_EMAC_CNTRL_RAM_OFFSET,
+   .ctrl_ram_size  = AM35XX_EMAC_CNTRL_RAM_SIZE,
+   .version= EMAC_VERSION_2,
+   .hw_ram_addr= AM35XX_EMAC_HW_RAM_ADDR,
+   .interrupt_enable   = am35xx_enable_ethernet_int,
+   .interrupt_disable  = am35xx_disable_ethernet_int,
+};
+
+static struct resource am35xx_emac_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE,
+   .end= AM35XX_IPSS_EMAC_BASE + 0x2,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .end= INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+   .end= INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+   .end= 

Re: [PATCH v16 09/12] OMAP: dmtimer: low-power mode support

[Omar Ramirez Luna]

On Wed, Nov 16, 2011 at 12:18 AM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
...
 My use case is as follows:

 DSP sends a mailbox message to ARM, this triggers a tasklet in mailbox
 for processing the message, when it reaches tidspbridge it turns out
 that the DSP wants to enable a gpt timer; however, locks involved
 clocks_mutex and dm_timer_lock now could cause a deadlock as they
 have been called from unsafe contexts in the past
 (http://pastebin.com/7Dtz8t0f).

 Is the intention to restrict enabling the dmtimer clocks from hard|soft irqs?
 The aim is to prevent client drivers perform clock enable/disable 
 independently.
 Instead just use the request/start/stop APIs. In that way we can make clock
 enable/disable functions static in the future.

Those are the APIs I'm using, omap_dm_timer_request_specific from a
softirq triggers this warning, this was not hinted by the patch or
cover letter of the series, hence the question:

Was this change intentional? Does omap_dm_timer_request_specific
should be allowed on other contexts (soft|hard irq)?

...
 You are right. This change some how got missed in mainline.
 I have posted a patch for this already.

Ok.

Regards,

Omar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: omap: pass minimal SoC/board data for UART from dt

[Rob Herring]

On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
 Pass minimal data needed for console boot, from dt, for
 OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
 static initialization from generic board file.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com
 ---
  arch/arm/boot/dts/omap3-beagle.dts  |   17 +
  arch/arm/boot/dts/omap3.dtsi|   27 +++
  arch/arm/boot/dts/omap4-panda.dts   |   17 +
  arch/arm/boot/dts/omap4-sdp.dts |   17 +
  arch/arm/boot/dts/omap4.dtsi|   24 
  arch/arm/mach-omap2/board-generic.c |1 -
  6 files changed, 102 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
 b/arch/arm/boot/dts/omap3-beagle.dts
 index 9486be6..4c8f11e 100644
 --- a/arch/arm/boot/dts/omap3-beagle.dts
 +++ b/arch/arm/boot/dts/omap3-beagle.dts
 @@ -27,3 +27,20 @@
   reg = 0x8000 0x2000; /* 512 MB */
   };
  };
 +
 +uart1 {
 + clock-frequency = 4800;
 +};
 +
 +uart2 {
 + clock-frequency = 4800;
 +};
 +
 +uart3 {
 + ti,console_hwmod;
 + clock-frequency = 4800;
 +};
 +
 +uart4 {
 + clock-frequency = 4800;
 +};
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index d202bb5..ea591c5 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -13,6 +13,13 @@
  / {
   compatible = ti,omap3430, ti,omap3;
  
 + aliases {
 + uart1 = uart1;
 + uart2 = uart2;
 + uart3 = uart3;
 + uart4 = uart4;
 + };
 +
   cpus {
   cpu@0 {
   compatible = arm,cortex-a8;
 @@ -59,5 +66,25 @@
   interrupt-controller;
   #interrupt-cells = 1;
   };
 +
 + uart1: uart@1 {

Use the generic name serial and the address: uart1: serial@1234abcd

 + compatible = ti,omap-uart;
 + ti,hwmods = uart1;
 + };
 +
 + uart2: uart@2 {
 + compatible = ti,omap-uart;
 + ti,hwmods = uart2;
 + };
 +
 + uart3: uart@3 {
 + compatible = ti,omap-uart;
 + ti,hwmods = uart3;
 + };
 +
 + uart4: uart@4 {
 + compatible = ti,omap-uart;
 + ti,hwmods = uart4;
 + };
   };
  };
 diff --git a/arch/arm/boot/dts/omap4-panda.dts 
 b/arch/arm/boot/dts/omap4-panda.dts
 index c702657..aa65449 100644
 --- a/arch/arm/boot/dts/omap4-panda.dts
 +++ b/arch/arm/boot/dts/omap4-panda.dts
 @@ -27,3 +27,20 @@
   reg = 0x8000 0x4000; /* 1 GB */
   };
  };
 +
 +uart1 {
 + clock-frequency = 4800;
 +};
 +
 +uart2 {
 + clock-frequency = 4800;
 +};
 +
 +uart3 {
 + ti,console_hwmod;
 + clock-frequency = 4800;
 +};
 +
 +uart4 {
 + clock-frequency = 4800;
 +};
 diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
 index 066e28c..524f5bf 100644
 --- a/arch/arm/boot/dts/omap4-sdp.dts
 +++ b/arch/arm/boot/dts/omap4-sdp.dts
 @@ -27,3 +27,20 @@
   reg = 0x8000 0x4000; /* 1 GB */
   };
  };
 +
 +uart1 {
 + clock-frequency = 4800;
 +};
 +
 +uart2 {
 + clock-frequency = 4800;
 +};
 +
 +uart3 {
 + ti,console_hwmod;
 + clock-frequency = 4800;
 +};
 +
 +uart4 {
 + clock-frequency = 4800;

It doesn't seem that this frequency ever varies and is likely to be
replaced with clock bindings, so maybe just put it in the dtsi files.

Rob

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap2: fix build failure

[Ming Lei]

Hi,

On Wed, Nov 9, 2011 at 3:24 AM, Kevin Hilman khil...@ti.com wrote:
 tom.leim...@gmail.com writes:

 From: Ming Lei tom.leim...@gmail.com

 The patch fixes the compile failure:

   CC      arch/arm/mach-omap2/cpuidle34xx.o
 arch/arm/mach-omap2/cpuidle34xx.c:317:12: error: 'THIS_MODULE'
 undeclared here (not in a function)
 make[1]: *** [arch/arm/mach-omap2/cpuidle34xx.o] Error 1
 make: *** [arch/arm/mach-omap2] Error 2
 make: *** Waiting for unfinished jobs

 Signed-off-by: Ming Lei tom.leim...@gmail.com

 FYI...

 Tony has already queued fix for this in his fixes branch.

     http://marc.info/?l=linux-arm-kernelm=132071036621713w=2

The fix is not merged into 3.2.0-rc2-next-2016+ yet...

thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH -next] arm: omap2: fix compile failure on arch/arm/mach-omap2/cpuidle34xx.c

[tom . leiming]

From: Ming Lei tom.leim...@gmail.com

  CC  arch/arm/mach-omap2/cpuidle34xx.o
arch/arm/mach-omap2/cpuidle34xx.c: In function 'omap3_enter_idle':
arch/arm/mach-omap2/cpuidle34xx.c:117:2: error: implicit declaration of
function 'omap_irq_pending'
make[1]: *** [arch/arm/mach-omap2/cpuidle34xx.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
make: *** Waiting for unfinished jobs

Signed-off-by: Ming Lei tom.leim...@gmail.com
---
 arch/arm/mach-omap2/cpuidle34xx.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 158c17e..0f49834 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -34,6 +34,7 @@
 
 #include pm.h
 #include control.h
+#include common.h
 
 #ifdef CONFIG_CPU_IDLE
 
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2 v4] net/smsc911x: Add regulator support

[Mike Frysinger]

On Wednesday 16 November 2011 07:59:41 Robert MARKLUND wrote:
 From: Mike Frysinger [mailto:vap...@gentoo.org]
  On Monday 31 October 2011 08:38:39 Robert Marklund wrote:
   ChangeLog v3-v4:
   - Remove dual prints and old comment on Mike's request.
   - Split the request_free fucntion on Mike and Sascha request.
  
  would be nice if the enable/disable were split as well ...
 
 I interpret this as nice if, if it's a must be then ill change it.

i would prefer it were split
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH/RESEND #3 6/7] arm: omap: smartreflex: fix IRQ handling bug

[Felipe Balbi]

On Wed, Nov 16, 2011 at 04:06:08PM -0800, Kevin Hilman wrote:
 Felipe Balbi ba...@ti.com writes:
 
 F fix a bug which has been on this driver since
  it was added by the original commit 984aa6db
  which would never clear IRQSTATUS bits.
 
  Signed-off-by: Felipe Balbi ba...@ti.com
 
 Queuing this fix for v3.2-rc (branch: for_3.2/fixes/pm)

should it go to stable too ??

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

[Rajendra Nayak]

[...]

+static int omap_console_hwmod_enable(struct omap_device *od)
+{
+   console_lock();
+   /*
+* For early console we prevented hwmod reset and idle


A period is missing. Or maybe it should a comma with not capital letter.


+* So before we enable the uart clocks idle the console
+* uart clocks, then enable back the console uart hwmod.
+*/
+   omap_hwmod_idle(od-hwmods[0]);
+   omap_hwmod_enable(od-hwmods[0]);


Why do we have to idle -  enable? The module is already enabled, isn't it?
The comment is not super clear for me :-)
Is the goal is to reset the IP?


Yes, now that I read it, it does sound confusing. I should have at-least
read it once before I picked it from serial.c

But anyway, here's what the problem is.

I feel its partly to do with the inability of hwmod to handle some
modules which are left enabled post a setup, due to the
'HWMOD_INIT_NO_IDLE' flag set.
Such modules end up with a hwmod state as '_HWMOD_STATE_ENABLED' post
a setup. Now when a driver for such devices/modules tries to enable the
module the first time, hwmod throws up a big WARN stating the hwmod is
already in an enabled state.
[uart used as console is one such module, which cannot be idled post a
setup by hwmod]

If hwmod could be made in some way intelligent enough to know that the
module is in enabled state because of the 'HWMOD_INIT_NO_IDLE' itself,
a lot of this hackery might not be needed at all.
Simplest way to do it could be to just add another intermediate state,
something like  '_HWMOD_STATE_ENABLED_AT_INIT'.
I will post a patch for this, see if you like it being handled that way.

The other part of the problem is also with the inability to hook up
'custom' omap_device_pm_latency for omap devices created from DT.
Maybe a lot of such cases which need custom activate/deactivate
functions might have to be handled in some way in the framework
itself like the one above.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: omap_device: handle first time activation of console device

[Rajendra Nayak]

Hi Rob,

On Wednesday 16 November 2011 08:20 PM, Rob Herring wrote:
[]...


diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dbdab40..46ffd41 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,6 +21,7 @@ Required properties:
  Optional properties:
  - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
during suspend.
+- ti,console_hwmod: boolean, identifies the hwmod used as console device



This doesn't seem right. Which console is not a h/w property. Why can't
you use aliases like other platforms are doing?


After thinking of this some more, I figured its more of a hwmod problem
to be solved, than with being able to identify which console.
Will post a separate patch to fix it up in hmwod and drop this from the
DT series.

Thanks for the review.

regards,
Rajendra



Also, it's not clear in the documentation where this (and
ti,no_idle_on_suspend) should go in the DT. Both seem like they should
be kernel cmdline params.

Rob


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: arm pmu interrupt on pandaboard

[Ming Lei]

Hi,

On Thu, Nov 17, 2011 at 3:04 PM, Fan Ye mouseye...@yahoo.com wrote:
 Hi Tom,
 I am currently working on PMU interrupt on Pandaboard.I use the patch sent
 by you:
 http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html

 But it will fail to boot the kernel. So I also apply the following patch:
 http://lists.linaro.org/pipermail/linaro-dev/2011-April/004019.html

 Now the kernel can boot up successfully. But I find that PMU interrupt is
 not triggered even if the PMU overflow happens and the interrupt is enabled
 in the PMINTENSET register.

I have posted some new code about the issue, see

   http://marc.info/?t=13194677661r=1w=2

I think this one can make your pmu work, :-)

 The code base I am using is
 http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary
 Thank you very much.
 Ye Fan


thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html