date:20121017

This is the third version of the series. Changes to v2 are:
* rebased on 3.7-rc1 to resolve conflicts
* add omap_vrfb_supported() so that cpu_is_* check can be removed from omapfb

As Kevin Hilman pointed out, the context restore is not functional. I didn't
touch that, as it's not functional with the current kernel either (and nobody
has complained, so it can't be that critical).

 Tomi

Tomi Valkeinen (5):
  OMAP: VRFB: convert vrfb to platform device
  OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
  OMAP: SDRC: remove VRFB code
  OMAPDSS: VRFB: add omap_vrfb_supported()
  OMAPFB: use omap_vrfb_supported()

 arch/arm/mach-omap2/sdrc.c   |   16 ---
 arch/arm/plat-omap/fb.c  |   61 +++
 arch/arm/plat-omap/include/plat/sdrc.h   |7 --
 arch/arm/plat-omap/include/plat/vrfb.h   |   66 
 drivers/media/platform/omap/omap_vout.c  |2 +-
 drivers/media/platform/omap/omap_vout_vrfb.c |2 +-
 drivers/media/platform/omap/omap_voutdef.h   |2 +-
 drivers/video/omap2/omapfb/omapfb-ioctl.c|2 +-
 drivers/video/omap2/omapfb/omapfb-main.c |8 +-
 drivers/video/omap2/omapfb/omapfb-sysfs.c|2 +-
 drivers/video/omap2/vrfb.c   |  142 ++
 include/video/omapvrfb.h |   68 
 12 files changed, 257 insertions(+), 121 deletions(-)
 delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
 create mode 100644 include/video/omapvrfb.h

-- 
1.7.9.5

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

[PATCHv3 1/5] OMAP: VRFB: convert vrfb to platform device

This patch converts vrfb library into a platform device, in an effort to
remove omap dependencies.

The platform device is registered in arch/arm/plat-omap/fb.c and
assigned resources depending on whether running on omap2 or omap3.

The vrfb driver will parse those resources and use them to access vrfb
configuration registers and the vrfb virtual rotation areas.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
 arch/arm/plat-omap/fb.c|   61 ++
 drivers/video/omap2/vrfb.c |  124 +---
 2 files changed, 165 insertions(+), 20 deletions(-)

diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index bcbb9d5..f868cae 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -33,6 +33,67 @@
 #include mach/hardware.h
 #include asm/mach/map.h
 
+#include plat/cpu.h
+
+#ifdef CONFIG_OMAP2_VRFB
+
+/*
+ * The first memory resource is the register region for VRFB,
+ * the rest are VRFB virtual memory areas for each VRFB context.
+ */
+
+static const struct resource omap2_vrfb_resources[] = {
+   DEFINE_RES_MEM_NAMED(0x68008000u, 0x40, vrfb-regs),
+   DEFINE_RES_MEM_NAMED(0x7000u, 0x400, vrfb-area-0),
+   DEFINE_RES_MEM_NAMED(0x7400u, 0x400, vrfb-area-1),
+   DEFINE_RES_MEM_NAMED(0x7800u, 0x400, vrfb-area-2),
+   DEFINE_RES_MEM_NAMED(0x7c00u, 0x400, vrfb-area-3),
+};
+
+static const struct resource omap3_vrfb_resources[] = {
+   DEFINE_RES_MEM_NAMED(0x6C000180u, 0xc0, vrfb-regs),
+   DEFINE_RES_MEM_NAMED(0x7000u, 0x400, vrfb-area-0),
+   DEFINE_RES_MEM_NAMED(0x7400u, 0x400, vrfb-area-1),
+   DEFINE_RES_MEM_NAMED(0x7800u, 0x400, vrfb-area-2),
+   DEFINE_RES_MEM_NAMED(0x7c00u, 0x400, vrfb-area-3),
+   DEFINE_RES_MEM_NAMED(0xe000u, 0x400, vrfb-area-4),
+   DEFINE_RES_MEM_NAMED(0xe400u, 0x400, vrfb-area-5),
+   DEFINE_RES_MEM_NAMED(0xe800u, 0x400, vrfb-area-6),
+   DEFINE_RES_MEM_NAMED(0xec00u, 0x400, vrfb-area-7),
+   DEFINE_RES_MEM_NAMED(0xf000u, 0x400, vrfb-area-8),
+   DEFINE_RES_MEM_NAMED(0xf400u, 0x400, vrfb-area-9),
+   DEFINE_RES_MEM_NAMED(0xf800u, 0x400, vrfb-area-10),
+   DEFINE_RES_MEM_NAMED(0xfc00u, 0x400, vrfb-area-11),
+};
+
+static int __init omap_init_vrfb(void)
+{
+   struct platform_device *pdev;
+   const struct resource *res;
+   unsigned int num_res;
+
+   if (cpu_is_omap24xx()) {
+   res = omap2_vrfb_resources;
+   num_res = ARRAY_SIZE(omap2_vrfb_resources);
+   } else if (cpu_is_omap34xx()) {
+   res = omap3_vrfb_resources;
+   num_res = ARRAY_SIZE(omap3_vrfb_resources);
+   } else {
+   return 0;
+   }
+
+   pdev = platform_device_register_resndata(NULL, omapvrfb, -1,
+   res, num_res, NULL, 0);
+
+   if (IS_ERR(pdev))
+   return PTR_ERR(pdev);
+   else
+   return 0;
+}
+
+arch_initcall(omap_init_vrfb);
+#endif
+
 #if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
 
 static bool omapfb_lcd_configured;
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 7e99022..fda45cc 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -26,9 +26,9 @@
 #include linux/io.h
 #include linux/bitops.h
 #include linux/mutex.h
+#include linux/platform_device.h
 
 #include plat/vrfb.h
-#include plat/sdrc.h
 
 #ifdef DEBUG
 #define DBG(format, ...) pr_debug(VRFB:  format, ## __VA_ARGS__)
@@ -36,10 +36,10 @@
 #define DBG(format, ...)
 #endif
 
-#define SMS_ROT_VIRT_BASE(context, rot) \
-   (((context = 4) ? 0xD000 : 0x7000) \
-+ (0x400 * (context)) \
-+ (0x100 * (rot)))
+#define SMS_ROT_CONTROL(context)   (0x0 + 0x10 * context)
+#define SMS_ROT_SIZE(context)  (0x4 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context)   (0x8 + 0x10 * context)
+#define SMS_ROT_VIRT_BASE(rot) (0x100 * (rot))
 
 #define OMAP_VRFB_SIZE (2048 * 2048 * 4)
 
@@ -53,10 +53,16 @@
 #define SMS_PW_OFFSET  4
 #define SMS_PS_OFFSET  0
 
-#define VRFB_NUM_CTXS 12
 /* bitmap of reserved contexts */
 static unsigned long ctx_map;
 
+struct vrfb_ctx {
+   u32 base;
+   u32 physical_ba;
+   u32 control;
+   u32 size;
+};
+
 static DEFINE_MUTEX(ctx_lock);
 
 /*
@@ -65,17 +71,32 @@ static DEFINE_MUTEX(ctx_lock);
  * we don't need locking, since no drivers will run until after the wake-up
  * has finished.
  */
-static struct {
-   u32 physical_ba;
-   u32 control;
-   u32 size;
-} vrfb_hw_context[VRFB_NUM_CTXS];
+
+static void __iomem *vrfb_base;
+
+static int num_ctxs;
+static struct vrfb_ctx *ctxs;
+
+static void omap2_sms_write_rot_control(u32 val, unsigned ctx)
+{
+   __raw_writel(val, vrfb_base +

[PATCHv3 2/5] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h

Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/plat-omap/include/plat/vrfb.h   |   66 --
 drivers/media/platform/omap/omap_vout.c  |2 +-
 drivers/media/platform/omap/omap_vout_vrfb.c |2 +-
 drivers/media/platform/omap/omap_voutdef.h   |2 +-
 drivers/video/omap2/omapfb/omapfb-ioctl.c|2 +-
 drivers/video/omap2/omapfb/omapfb-main.c |2 +-
 drivers/video/omap2/omapfb/omapfb-sysfs.c|2 +-
 drivers/video/omap2/vrfb.c   |2 +-
 include/video/omapvrfb.h |   66 ++
 9 files changed, 73 insertions(+), 73 deletions(-)
 delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
 create mode 100644 include/video/omapvrfb.h

diff --git a/arch/arm/plat-omap/include/plat/vrfb.h 
b/arch/arm/plat-omap/include/plat/vrfb.h
deleted file mode 100644
index 3792bde..000
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * VRFB Rotation Engine
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen tomi.valkei...@nokia.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.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
- */
-
-#ifndef __OMAP_VRFB_H__
-#define __OMAP_VRFB_H__
-
-#define OMAP_VRFB_LINE_LEN 2048
-
-struct vrfb {
-   u8 context;
-   void __iomem *vaddr[4];
-   unsigned long paddr[4];
-   u16 xres;
-   u16 yres;
-   u16 xoffset;
-   u16 yoffset;
-   u8 bytespp;
-   bool yuv_mode;
-};
-
-#ifdef CONFIG_OMAP2_VRFB
-extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
-   u8 bytespp);
-extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
-extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
-extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
-   u16 width, u16 height,
-   unsigned bytespp, bool yuv_mode);
-extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
-extern void omap_vrfb_restore_context(void);
-
-#else
-static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
-static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
-static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
-   u8 bytespp) {}
-static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
-   { return 0; }
-static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
-   { return 0; }
-static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
-   u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
-static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
-   { return 0; }
-static inline void omap_vrfb_restore_context(void) {}
-#endif
-#endif /* __VRFB_H */
diff --git a/drivers/media/platform/omap/omap_vout.c 
b/drivers/media/platform/omap/omap_vout.c
index a3b1a34..3ff94a3 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -46,7 +46,7 @@
 
 #include plat/cpu.h
 #include plat/dma.h
-#include plat/vrfb.h
+#include video/omapvrfb.h
 #include video/omapdss.h
 
 #include omap_voutlib.h
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c 
b/drivers/media/platform/omap/omap_vout_vrfb.c
index 4be26abf6c..6c37f92 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -17,7 +17,7 @@
 #include media/v4l2-device.h
 
 #include plat/dma.h
-#include plat/vrfb.h
+#include video/omapvrfb.h
 
 #include omap_voutdef.h
 #include omap_voutlib.h
diff --git a/drivers/media/platform/omap/omap_voutdef.h 
b/drivers/media/platform/omap/omap_voutdef.h
index 27a95d2..9ccfe1f 100644
--- a/drivers/media/platform/omap/omap_voutdef.h
+++ b/drivers/media/platform/omap/omap_voutdef.h
@@ -12,7 +12,7 @@
 #define OMAP_VOUTDEF_H
 
 #include video/omapdss.h
-#include plat/vrfb.h
+#include video/omapvrfb.h
 
 #define YUYV_BPP2
 #define RGB565_BPP  2
diff --git

[PATCHv3 3/5] OMAP: SDRC: remove VRFB code

Now that VRFB driver handles its registers independently, we can remove
the VRFB related code from OMAP's sdrc.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/sdrc.c |   16 
 arch/arm/plat-omap/include/plat/sdrc.h |7 ---
 2 files changed, 23 deletions(-)

diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index e3d345f..4282e6e 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -160,19 +160,3 @@ void __init omap2_sdrc_init(struct omap_sdrc_params 
*sdrc_cs0,
sdrc_write_reg(l, SDRC_POWER);
omap2_sms_save_context();
 }
-
-void omap2_sms_write_rot_control(u32 val, unsigned ctx)
-{
-   sms_write_reg(val, SMS_ROT_CONTROL(ctx));
-}
-
-void omap2_sms_write_rot_size(u32 val, unsigned ctx)
-{
-   sms_write_reg(val, SMS_ROT_SIZE(ctx));
-}
-
-void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
-{
-   sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
-}
-
diff --git a/arch/arm/plat-omap/include/plat/sdrc.h 
b/arch/arm/plat-omap/include/plat/sdrc.h
index 36d6a76..c68bab2 100644
--- a/arch/arm/plat-omap/include/plat/sdrc.h
+++ b/arch/arm/plat-omap/include/plat/sdrc.h
@@ -94,9 +94,6 @@
 /* SMS register offsets - read/write with sms_{read,write}_reg() */
 
 #define SMS_SYSCONFIG  0x010
-#define SMS_ROT_CONTROL(context)   (0x180 + 0x10 * context)
-#define SMS_ROT_SIZE(context)  (0x184 + 0x10 * context)
-#define SMS_ROT_PHYSICAL_BA(context)   (0x188 + 0x10 * context)
 /* REVISIT: fill in other SMS registers here */
 
 
@@ -137,10 +134,6 @@ int omap2_sdrc_get_params(unsigned long r,
 void omap2_sms_save_context(void);
 void omap2_sms_restore_context(void);
 
-void omap2_sms_write_rot_control(u32 val, unsigned ctx);
-void omap2_sms_write_rot_size(u32 val, unsigned ctx);
-void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
-
 #ifdef CONFIG_ARCH_OMAP2
 
 struct memory_timings {
-- 
1.7.9.5

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

[PATCHv3 4/5] OMAPDSS: VRFB: add omap_vrfb_supported()

Add an exported function omap_vrfb_supported() which returns true if the
vrfb driver has been loaded succesfully. This can be used to decide if
VRFB can be used or not.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/vrfb.c |   16 
 include/video/omapvrfb.h   |2 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index e4a0450..5d8fdac 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -77,6 +77,8 @@ static void __iomem *vrfb_base;
 static int num_ctxs;
 static struct vrfb_ctx *ctxs;
 
+static bool vrfb_loaded;
+
 static void omap2_sms_write_rot_control(u32 val, unsigned ctx)
 {
__raw_writel(val, vrfb_base + SMS_ROT_CONTROL(ctx));
@@ -336,6 +338,12 @@ out:
 }
 EXPORT_SYMBOL(omap_vrfb_request_ctx);
 
+bool omap_vrfb_supported(void)
+{
+   return vrfb_loaded;
+}
+EXPORT_SYMBOL(omap_vrfb_supported);
+
 static int __init vrfb_probe(struct platform_device *pdev)
 {
struct resource *mem;
@@ -375,11 +383,19 @@ static int __init vrfb_probe(struct platform_device *pdev)
ctxs[i].base = mem-start;
}
 
+   vrfb_loaded = true;
+
return 0;
 }
 
+static void __exit vrfb_remove(struct platform_device *pdev)
+{
+   vrfb_loaded = false;
+}
+
 static struct platform_driver vrfb_driver = {
.driver.name= omapvrfb,
+   .remove = __exit_p(vrfb_remove),
 };
 
 static int __init vrfb_init(void)
diff --git a/include/video/omapvrfb.h b/include/video/omapvrfb.h
index 3792bde..bb0bd89 100644
--- a/include/video/omapvrfb.h
+++ b/include/video/omapvrfb.h
@@ -36,6 +36,7 @@ struct vrfb {
 };
 
 #ifdef CONFIG_OMAP2_VRFB
+extern bool omap_vrfb_supported(void);
 extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
 extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
 extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
@@ -49,6 +50,7 @@ extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, 
u8 rot);
 extern void omap_vrfb_restore_context(void);
 
 #else
+static inline bool omap_vrfb_supported(void) { return false; }
 static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
 static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
 static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
-- 
1.7.9.5

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

[PATCHv3 5/5] OMAPFB: use omap_vrfb_supported()

Replace cpu_is_*() check with omap_vrfb_supported().

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/omapfb/omapfb-main.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c 
b/drivers/video/omap2/omapfb/omapfb-main.c
index 5943b3a..bc225e4 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -31,7 +31,6 @@
 #include linux/omapfb.h
 
 #include video/omapdss.h
-#include plat/cpu.h
 #include plat/vram.h
 #include video/omapvrfb.h
 
@@ -2396,10 +2395,7 @@ static int __init omapfb_probe(struct platform_device 
*pdev)
goto err0;
}
 
-   /* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
-   *available for OMAP2 and OMAP3
-   */
-   if (def_vrfb  !cpu_is_omap24xx()  !cpu_is_omap34xx()) {
+   if (def_vrfb  !omap_vrfb_supported()) {
def_vrfb = 0;
dev_warn(pdev-dev, VRFB is not supported on this hardware, 
ignoring the module parameter vrfb=y\n);
-- 
1.7.9.5

--
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 0/5] OMAP: VRFB: convert to platform device

Hi Tony,

I have pushed this vrfb series and the omapdss version series to:

git://gitorious.org/linux-omap-dss2/linux.git 3.8/dss-version
git://gitorious.org/linux-omap-dss2/linux.git 3.8/vrfb-conversion

If they look ok to you and we don't get any other comments, I think
these branches can be considered stable and you can pull them.

After these are merged:

$ git grep -E (plat/)|(mach/) drivers/video/omap2/
drivers/video/omap2/omapfb/omapfb-ioctl.c:#include plat/vram.h
drivers/video/omap2/omapfb/omapfb-main.c:#include plat/vram.h
drivers/video/omap2/vram.c:#include plat/vram.h

So the vram stuff should be the only omap dependency left in omapdss and
omapfb. I'll start working on that soon.

 Tomi

On 2012-10-17 13:18, Tomi Valkeinen wrote:
 This is the third version of the series. Changes to v2 are:
 * rebased on 3.7-rc1 to resolve conflicts
 * add omap_vrfb_supported() so that cpu_is_* check can be removed from omapfb
 
 As Kevin Hilman pointed out, the context restore is not functional. I didn't
 touch that, as it's not functional with the current kernel either (and nobody
 has complained, so it can't be that critical).
 
  Tomi
 
 Tomi Valkeinen (5):
   OMAP: VRFB: convert vrfb to platform device
   OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
   OMAP: SDRC: remove VRFB code
   OMAPDSS: VRFB: add omap_vrfb_supported()
   OMAPFB: use omap_vrfb_supported()
 
  arch/arm/mach-omap2/sdrc.c   |   16 ---
  arch/arm/plat-omap/fb.c  |   61 +++
  arch/arm/plat-omap/include/plat/sdrc.h   |7 --
  arch/arm/plat-omap/include/plat/vrfb.h   |   66 
  drivers/media/platform/omap/omap_vout.c  |2 +-
  drivers/media/platform/omap/omap_vout_vrfb.c |2 +-
  drivers/media/platform/omap/omap_voutdef.h   |2 +-
  drivers/video/omap2/omapfb/omapfb-ioctl.c|2 +-
  drivers/video/omap2/omapfb/omapfb-main.c |8 +-
  drivers/video/omap2/omapfb/omapfb-sysfs.c|2 +-
  drivers/video/omap2/vrfb.c   |  142 
 ++
  include/video/omapvrfb.h |   68 
  12 files changed, 257 insertions(+), 121 deletions(-)
  delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
  create mode 100644 include/video/omapvrfb.h
 




signature.asc
Description: OpenPGP digital signature

[PATCH 0/9] OMAPDSS: minor fixes cleanups

Hi,

This series contains minor cleanups and fixes for omapdss.

 Tomi

Tomi Valkeinen (9):
  OMAPDSS: DSI: fix dsi_get_dsidev_from_id()
  OMAPDSS: fix registering the vsync isr in apply
  OMAPDSS: DISPC: constify function parameters
  OMAPDSS: combine LCD related config into one func
  OMAPDSS: remove declarations for non-existing funcs
  OMAPDSS: DISPC: remove struct omap_overlay use
  OMAPDSS: DISPC: cleanup lcd and digit enable
  OMAPDSS: DISPC: add dispc_mgr_get_sync_lost_irq()
  OMAPDSS: DISPC: cleanup lcd/digit enable/disable

 drivers/video/omap2/dss/apply.c |   27 ++---
 drivers/video/omap2/dss/dispc.c |  235 ---
 drivers/video/omap2/dss/dsi.c   |   13 ++-
 drivers/video/omap2/dss/dss.h   |   21 ++--
 4 files changed, 174 insertions(+), 122 deletions(-)

-- 
1.7.9.5

--
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/9] OMAPDSS: DSI: fix dsi_get_dsidev_from_id()

If dsi_get_dsidev_from_id() is called with a DSI module id that does not
exist on the board, the function will crash as omap_dss_get_output()
will return NULL.

This happens on omap3 boards when dumping DSI clocks, as the dumping
code will try to get the dsidev for DSI modules 0 and 1, but omap3 only
has DSI module 0.

Also clean up the id - output mapping, so that if the function is
called with invalid module ID it will return NULL.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dsi.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d64ac38..bee9284 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -365,11 +365,20 @@ struct platform_device *dsi_get_dsidev_from_id(int module)
struct omap_dss_output *out;
enum omap_dss_output_id id;
 
-   id = module == 0 ? OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2;
+   switch (module) {
+   case 0:
+   id = OMAP_DSS_OUTPUT_DSI1;
+   break;
+   case 1:
+   id = OMAP_DSS_OUTPUT_DSI2;
+   break;
+   default:
+   return NULL;
+   }
 
out = omap_dss_get_output(id);
 
-   return out-pdev;
+   return out ? out-pdev : NULL;
 }
 
 static inline void dsi_write_reg(struct platform_device *dsidev,
-- 
1.7.9.5

--
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/9] OMAPDSS: fix registering the vsync isr in apply

When we enable an output we don't check if we need to register the vsync
isr. This causes us to miss vsync interrupts until somebody changes the
configuration of an overlay or an overlay manager.

Add the registration to dss_mgr_enable to fix the problem.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/apply.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 19d66f4..29ce5a8 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1035,6 +1035,9 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr)
if (!mgr_manual_update(mgr))
mp-updating = true;
 
+   if (!dss_data.irq_enabled  need_isr())
+   dss_register_vsync_isr();
+
spin_unlock_irqrestore(data_lock, flags);
 
if (!mgr_manual_update(mgr))
-- 
1.7.9.5

--
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 4/9] OMAPDSS: combine LCD related config into one func

Dispc has a bunch of functions used to configure output related
parameters:

- dispc_mgr_set_io_pad_mode
- dispc_mgr_enable_stallmode
- dispc_mgr_enable_fifohandcheck
- dispc_mgr_set_clock_div
- dispc_mgr_set_tft_data_lines
- dispc_lcd_enable_signal_polarity
- dispc_mgr_set_lcd_type_tft

These are all called together, and the configuration values are taken
from struct dss_lcd_mgr_config.

Instead of exposing those individual dispc functions, create a new one,
dispc_mgr_set_lcd_config(), which is used to configure the above
parameters from values in struct dss_lcd_mgr_config.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/apply.c |   18 ++
 drivers/video/omap2/dss/dispc.c |   29 +++--
 drivers/video/omap2/dss/dss.h   |8 ++--
 3 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 29ce5a8..ae9f70d 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -666,22 +666,8 @@ static void dss_mgr_write_regs_extra(struct 
omap_overlay_manager *mgr)
dispc_mgr_set_timings(mgr-id, mp-timings);
 
/* lcd_config parameters */
-   if (dss_mgr_is_lcd(mgr-id)) {
-   dispc_mgr_set_io_pad_mode(mp-lcd_config.io_pad_mode);
-
-   dispc_mgr_enable_stallmode(mgr-id, mp-lcd_config.stallmode);
-   dispc_mgr_enable_fifohandcheck(mgr-id,
-   mp-lcd_config.fifohandcheck);
-
-   dispc_mgr_set_clock_div(mgr-id, mp-lcd_config.clock_info);
-
-   dispc_mgr_set_tft_data_lines(mgr-id,
-   mp-lcd_config.video_port_width);
-
-   
dispc_lcd_enable_signal_polarity(mp-lcd_config.lcden_sig_polarity);
-
-   dispc_mgr_set_lcd_type_tft(mgr-id);
-   }
+   if (dss_mgr_is_lcd(mgr-id))
+   dispc_mgr_set_lcd_config(mgr-id, mp-lcd_config);
 
mp-extra_info_dirty = false;
if (mp-updating)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4dfc90a..d3c58eb 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2769,7 +2769,7 @@ bool dispc_wb_is_enabled(void)
return REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
 }
 
-void dispc_lcd_enable_signal_polarity(bool act_high)
+static void dispc_lcd_enable_signal_polarity(bool act_high)
 {
if (!dss_has_feature(FEAT_LCDENABLEPOL))
return;
@@ -2793,13 +2793,13 @@ void dispc_pck_free_enable(bool enable)
REG_FLD_MOD(DISPC_CONTROL, enable ? 1 : 0, 27, 27);
 }
 
-void dispc_mgr_enable_fifohandcheck(enum omap_channel channel, bool enable)
+static void dispc_mgr_enable_fifohandcheck(enum omap_channel channel, bool 
enable)
 {
mgr_fld_write(channel, DISPC_MGR_FLD_FIFOHANDCHECK, enable);
 }
 
 
-void dispc_mgr_set_lcd_type_tft(enum omap_channel channel)
+static void dispc_mgr_set_lcd_type_tft(enum omap_channel channel)
 {
mgr_fld_write(channel, DISPC_MGR_FLD_STNTFT, 1);
 }
@@ -2855,7 +2855,7 @@ void dispc_mgr_setup(enum omap_channel channel,
}
 }
 
-void dispc_mgr_set_tft_data_lines(enum omap_channel channel, u8 data_lines)
+static void dispc_mgr_set_tft_data_lines(enum omap_channel channel, u8 
data_lines)
 {
int code;
 
@@ -2880,7 +2880,7 @@ void dispc_mgr_set_tft_data_lines(enum omap_channel 
channel, u8 data_lines)
mgr_fld_write(channel, DISPC_MGR_FLD_TFTDATALINES, code);
 }
 
-void dispc_mgr_set_io_pad_mode(enum dss_io_pad_mode mode)
+static void dispc_mgr_set_io_pad_mode(enum dss_io_pad_mode mode)
 {
u32 l;
int gpout0, gpout1;
@@ -2909,11 +2909,28 @@ void dispc_mgr_set_io_pad_mode(enum dss_io_pad_mode 
mode)
dispc_write_reg(DISPC_CONTROL, l);
 }
 
-void dispc_mgr_enable_stallmode(enum omap_channel channel, bool enable)
+static void dispc_mgr_enable_stallmode(enum omap_channel channel, bool enable)
 {
mgr_fld_write(channel, DISPC_MGR_FLD_STALLMODE, enable);
 }
 
+void dispc_mgr_set_lcd_config(enum omap_channel channel,
+   const struct dss_lcd_mgr_config *config)
+{
+   dispc_mgr_set_io_pad_mode(config-io_pad_mode);
+
+   dispc_mgr_enable_stallmode(channel, config-stallmode);
+   dispc_mgr_enable_fifohandcheck(channel, config-fifohandcheck);
+
+   dispc_mgr_set_clock_div(channel, config-clock_info);
+
+   dispc_mgr_set_tft_data_lines(channel, config-video_port_width);
+
+   dispc_lcd_enable_signal_polarity(config-lcden_sig_polarity);
+
+   dispc_mgr_set_lcd_type_tft(channel);
+}
+
 static bool _dispc_mgr_size_ok(u16 width, u16 height)
 {
return width = dss_feat_get_param_max(FEAT_PARAM_MGR_WIDTH) 
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index eaf0856..8447871 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -435,7 +435,6 @@ void dispc_runtime_put(void);
 void

[PATCH 5/9] OMAPDSS: remove declarations for non-existing funcs

dss_mgr_set_device and dss_mgr_unset_device are declared in dss.h, but
the functions do not exist. Remove the declarations.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/dss.h |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 8447871..373847c 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -217,9 +217,6 @@ int dss_mgr_set_info(struct omap_overlay_manager *mgr,
struct omap_overlay_manager_info *info);
 void dss_mgr_get_info(struct omap_overlay_manager *mgr,
struct omap_overlay_manager_info *info);
-int dss_mgr_set_device(struct omap_overlay_manager *mgr,
-   struct omap_dss_device *dssdev);
-int dss_mgr_unset_device(struct omap_overlay_manager *mgr);
 int dss_mgr_set_output(struct omap_overlay_manager *mgr,
struct omap_dss_output *output);
 int dss_mgr_unset_output(struct omap_overlay_manager *mgr);
-- 
1.7.9.5

--
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 6/9] OMAPDSS: DISPC: remove struct omap_overlay use

dispc_ovl_setup() uses struct omap_overlay to get the caps for the
overlay. We can change the code to get the caps directly from dss
features, thus removing the dependency to struct omap_overlay.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/dispc.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d3c58eb..9f0ce18 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2505,7 +2505,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
bool mem_to_mem)
 {
int r;
-   const struct omap_overlay *ovl = omap_dss_get_overlay(plane);
+   enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
enum omap_channel channel;
 
channel = dispc_ovl_get_channel_out(plane);
@@ -2516,7 +2516,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
oi-pos_y, oi-width, oi-height, oi-out_width, oi-out_height,
oi-color_mode, oi-rotation, oi-mirror, channel, replication);
 
-   r = dispc_ovl_setup_common(plane, ovl-caps, oi-paddr, oi-p_uv_addr,
+   r = dispc_ovl_setup_common(plane, caps, oi-paddr, oi-p_uv_addr,
oi-screen_width, oi-pos_x, oi-pos_y, oi-width, oi-height,
oi-out_width, oi-out_height, oi-color_mode, oi-rotation,
oi-mirror, oi-zorder, oi-pre_mult_alpha, oi-global_alpha,
-- 
1.7.9.5

--
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 7/9] OMAPDSS: DISPC: cleanup lcd and digit enable

dispc.c's functions to enable LCD and DIGIT outputs can be cleaned up a
bit by using common functions to set the enable bit and to check if the
output is enabled.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   27 ++-
 1 file changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9f0ce18..492740e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2591,13 +2591,18 @@ static void dispc_disable_isr(void *data, u32 mask)
complete(compl);
 }
 
-static void _enable_lcd_out(enum omap_channel channel, bool enable)
+static void _enable_mgr_out(enum omap_channel channel, bool enable)
 {
mgr_fld_write(channel, DISPC_MGR_FLD_ENABLE, enable);
/* flush posted write */
mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
 }
 
+bool dispc_mgr_is_enabled(enum omap_channel channel)
+{
+   return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
+}
+
 static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable)
 {
struct completion frame_done_completion;
@@ -2608,7 +2613,7 @@ static void dispc_mgr_enable_lcd_out(enum omap_channel 
channel, bool enable)
/* When we disable LCD output, we need to wait until frame is done.
 * Otherwise the DSS is still working, and turning off the clocks
 * prevents DSS from going to OFF mode */
-   is_on = mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
+   is_on = dispc_mgr_is_enabled(channel);
 
irq = mgr_desc[channel].framedone_irq;
 
@@ -2622,7 +2627,7 @@ static void dispc_mgr_enable_lcd_out(enum omap_channel 
channel, bool enable)
DSSERR(failed to register FRAMEDONE isr\n);
}
 
-   _enable_lcd_out(channel, enable);
+   _enable_mgr_out(channel, enable);
 
if (!enable  is_on) {
if (!wait_for_completion_timeout(frame_done_completion,
@@ -2637,13 +2642,6 @@ static void dispc_mgr_enable_lcd_out(enum omap_channel 
channel, bool enable)
}
 }
 
-static void _enable_digit_out(bool enable)
-{
-   REG_FLD_MOD(DISPC_CONTROL, enable ? 1 : 0, 1, 1);
-   /* flush posted write */
-   dispc_read_reg(DISPC_CONTROL);
-}
-
 static void dispc_mgr_enable_digit_out(bool enable)
 {
struct completion frame_done_completion;
@@ -2652,7 +2650,7 @@ static void dispc_mgr_enable_digit_out(bool enable)
u32 irq_mask;
int num_irqs;
 
-   if (REG_GET(DISPC_CONTROL, 1, 1) == enable)
+   if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT) == enable)
return;
 
src = dss_get_hdmi_venc_clk_source();
@@ -2689,7 +2687,7 @@ static void dispc_mgr_enable_digit_out(bool enable)
if (r)
DSSERR(failed to register %x isr\n, irq_mask);
 
-   _enable_digit_out(enable);
+   _enable_mgr_out(OMAP_DSS_CHANNEL_DIGIT, enable);
 
for (i = 0; i  num_irqs; ++i) {
if (!wait_for_completion_timeout(frame_done_completion,
@@ -2713,11 +2711,6 @@ static void dispc_mgr_enable_digit_out(bool enable)
}
 }
 
-bool dispc_mgr_is_enabled(enum omap_channel channel)
-{
-   return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
-}
-
 void dispc_mgr_enable(enum omap_channel channel, bool enable)
 {
if (dss_mgr_is_lcd(channel))
-- 
1.7.9.5

--
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 8/9] OMAPDSS: DISPC: add dispc_mgr_get_sync_lost_irq()

Add function that returns the sync lost irq mask for the given channel.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/dispc.c |5 +
 drivers/video/omap2/dss/dss.h   |1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 492740e..82339ad 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -543,6 +543,11 @@ u32 dispc_mgr_get_framedone_irq(enum omap_channel channel)
return mgr_desc[channel].framedone_irq;
 }
 
+u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel)
+{
+   return mgr_desc[channel].sync_lost_irq;
+}
+
 u32 dispc_wb_get_framedone_irq(void)
 {
return DISPC_IRQ_FRAMEDONEWB;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 373847c..b6e3a06 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -460,6 +460,7 @@ void dispc_ovl_set_channel_out(enum omap_plane plane,
 
 u32 dispc_mgr_get_vsync_irq(enum omap_channel channel);
 u32 dispc_mgr_get_framedone_irq(enum omap_channel channel);
+u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel);
 bool dispc_mgr_go_busy(enum omap_channel channel);
 void dispc_mgr_go(enum omap_channel channel);
 bool dispc_mgr_is_enabled(enum omap_channel channel);
-- 
1.7.9.5

--
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 9/9] OMAPDSS: DISPC: cleanup lcd/digit enable/disable

We currently have a single function to enable and disable the manager
output for LCD and DIGIT. The functions are a bit complex, as handling
both enable and disable require some extra steps to ensure that the
output is enabled or disabled properly without errors before exiting the
function.

The code can be made simpler to understand by splitting the functions
into separate enable and disable functions. We'll also clean up the
comments and some parameter names at the same time.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/apply.c |6 +-
 drivers/video/omap2/dss/dispc.c |  178 ---
 drivers/video/omap2/dss/dss.h   |3 +-
 3 files changed, 116 insertions(+), 71 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index ae9f70d..4fff8ac 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -772,7 +772,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
if (!dss_data.irq_enabled  need_isr())
dss_register_vsync_isr();
 
-   dispc_mgr_enable(mgr-id, true);
+   dispc_mgr_enable(mgr-id);
 
mgr_clear_shadow_dirty(mgr);
 
@@ -1027,7 +1027,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr)
spin_unlock_irqrestore(data_lock, flags);
 
if (!mgr_manual_update(mgr))
-   dispc_mgr_enable(mgr-id, true);
+   dispc_mgr_enable(mgr-id);
 
 out:
mutex_unlock(apply_lock);
@@ -1052,7 +1052,7 @@ void dss_mgr_disable(struct omap_overlay_manager *mgr)
goto out;
 
if (!mgr_manual_update(mgr))
-   dispc_mgr_enable(mgr-id, false);
+   dispc_mgr_disable(mgr-id);
 
spin_lock_irqsave(data_lock, flags);
 
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 82339ad..94f393ec 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2590,7 +2590,7 @@ int dispc_ovl_enable(enum omap_plane plane, bool enable)
return 0;
 }
 
-static void dispc_disable_isr(void *data, u32 mask)
+static void dispc_mgr_disable_isr(void *data, u32 mask)
 {
struct completion *compl = data;
complete(compl);
@@ -2608,122 +2608,166 @@ bool dispc_mgr_is_enabled(enum omap_channel channel)
return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
 }
 
-static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable)
+static void dispc_mgr_enable_lcd_out(enum omap_channel channel)
 {
-   struct completion frame_done_completion;
-   bool is_on;
+   _enable_mgr_out(channel, true);
+}
+
+static void dispc_mgr_disable_lcd_out(enum omap_channel channel)
+{
+   DECLARE_COMPLETION_ONSTACK(framedone_compl);
int r;
u32 irq;
 
-   /* When we disable LCD output, we need to wait until frame is done.
-* Otherwise the DSS is still working, and turning off the clocks
-* prevents DSS from going to OFF mode */
-   is_on = dispc_mgr_is_enabled(channel);
+   if (dispc_mgr_is_enabled(channel) == false)
+   return;
+
+   /*
+* When we disable LCD output, we need to wait for FRAMEDONE to know
+* that DISPC has finished with the LCD output.
+*/
 
-   irq = mgr_desc[channel].framedone_irq;
+   irq = dispc_mgr_get_framedone_irq(channel);
 
-   if (!enable  is_on) {
-   init_completion(frame_done_completion);
+   r = omap_dispc_register_isr(dispc_mgr_disable_isr, framedone_compl,
+   irq);
+   if (r)
+   DSSERR(failed to register FRAMEDONE isr\n);
 
-   r = omap_dispc_register_isr(dispc_disable_isr,
-   frame_done_completion, irq);
+   _enable_mgr_out(channel, false);
 
-   if (r)
-   DSSERR(failed to register FRAMEDONE isr\n);
+   /* if we couldn't register for framedone, just sleep and exit */
+   if (r) {
+   msleep(200);
+   return;
}
 
-   _enable_mgr_out(channel, enable);
+   if (!wait_for_completion_timeout(framedone_compl,
+   msecs_to_jiffies(100)))
+   DSSERR(timeout waiting for FRAME DONE\n);
 
-   if (!enable  is_on) {
-   if (!wait_for_completion_timeout(frame_done_completion,
-   msecs_to_jiffies(100)))
-   DSSERR(timeout waiting for FRAME DONE\n);
+   r = omap_dispc_unregister_isr(dispc_mgr_disable_isr, framedone_compl,
+   irq);
+   if (r)
+   DSSERR(failed to unregister FRAMEDONE isr\n);
+}
 
-   r = omap_dispc_unregister_isr(dispc_disable_isr,
-   frame_done_completion, irq);
+static void dispc_digit_out_enable_isr(void *data, u32 mask)
+{
+   struct completion *compl = data;
 
-   if

Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

2012-10-17 Thread Igor Grinberg

Hi Ohad,

On 10/17/12 11:10, Ohad Ben-Cohen wrote:
 On Tue, Oct 16, 2012 at 8:26 PM, Tony Lindgren t...@atomide.com wrote:
 Hmm looking at it repeats the same code over again. Can you
 rather add some wl12xx_board_init() helper function to mach-omap2/devices.c
 to do it?
 
 Nice, see below. Note that I can only compile test this now, which may
 be ok because it's pretty trivial. But do let me know if you want me
 to get it tested.

The patch looks good, though minor comment below.

 
From b940fb88a97494ad3a0a093279a5f176c0b29e44 Mon Sep 17 00:00:00 2001
 From: Ohad Ben-Cohen o...@wizery.com
 Date: Sun, 14 Oct 2012 20:16:01 +0200
 Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't
  configured
 
 Stop intimidating users with scary wlan error messages in case wl12xx
 support wasn't even built.
 
 In addition, when wl12xx_set_platform_data() fails, don't bother
 registering wl12xx's fixed regulator device (on the relevant
 boards).
 
 While we're at it, extract the wlan init code to a dedicated function to
 make (the relevant boards') init code look a bit nicer.
 
 Compile tested only.
 
 Reported-by: Russell King li...@arm.linux.org.uk
 Signed-off-by: Ohad Ben-Cohen o...@wizery.com
 ---
  arch/arm/mach-davinci/board-da850-evm.c  |  8 ++--
  arch/arm/mach-omap2/board-4430sdp.c  |  7 ---
  arch/arm/mach-omap2/board-omap3evm.c |  6 +++---
  arch/arm/mach-omap2/board-omap3pandora.c |  9 +++--
  arch/arm/mach-omap2/board-omap4panda.c   | 20 ++--
  arch/arm/mach-omap2/board-zoom-peripherals.c | 15 ++-
  arch/arm/mach-omap2/common-board-devices.h   |  2 ++
  arch/arm/mach-omap2/devices.c| 26 ++
  8 files changed, 64 insertions(+), 29 deletions(-)

[...]

 diff --git a/arch/arm/mach-omap2/common-board-devices.h
 b/arch/arm/mach-omap2/common-board-devices.h
 index a0b4a428..52e91424 100644
 --- a/arch/arm/mach-omap2/common-board-devices.h
 +++ b/arch/arm/mach-omap2/common-board-devices.h
 @@ -7,9 +7,11 @@
 
  struct mtd_partition;
  struct ads7846_platform_data;
 +struct wl12xx_platform_data;
 
  void omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
  struct ads7846_platform_data *board_pdata);
  void omap_nand_flash_init(int opts, struct mtd_partition *parts, int 
 n_parts);
 +int __init wl12xx_board_init(struct wl12xx_platform_data *wlan_data, int 
 gpio);

You are adding declarations inside the common-board-devices.h,
but the implementation inside the devices.c.
I can see that devices.c has only on-soc devices in it.
So, I would expect to have the wl12xx_board_init() function implementation
inside the common-board-devices.c file.

Another minor nit: I don't think you need to mark the declaration as __init,
only the implementation, or is it for documenting it so?

 
  #endif /* __OMAP_COMMON_BOARD_DEVICES__ */
 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
 index c8c2117..9e86bb9 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -19,6 +19,7 @@
  #include linux/of.h
  #include linux/pinctrl/machine.h
  #include linux/platform_data/omap4-keypad.h
 +#include linux/wl12xx.h
 
  #include asm/mach-types.h
  #include asm/mach/map.h
 @@ -38,6 +39,31 @@
  #define L3_MODULES_MAX_LEN 12
  #define L3_MODULES 3
 
 +int __init wl12xx_board_init(struct wl12xx_platform_data *wlan_data, int 
 gpio)
 +{
 + int ret;
 +
 + wlan_data-irq = gpio_to_irq(gpio);
 + if (wlan_data-irq  0) {
 + ret = wlan_data-irq;
 + pr_err(wl12xx: gpio_to_irq(%d) failed: %d\n, gpio, ret);
 + return ret;
 + }
 +
 + ret = wl12xx_set_platform_data(wlan_data);
 + /* bail out silently in case wl12xx isn't configured */
 + if (ret == -ENOSYS)
 + return ret;

Instead of the above, wouldn't it be better to have:
#if defined(CONFIG_WL12XX_PLATFORM_DATA)
int __init wl12xx_board_init(struct wl12xx_platform_data *wlan_data, int 
irq_gpio)
{
...
}
#else
inline int wl12xx_board_init(struct wl12xx_platform_data *wlan_data, int 
irq_gpio)
{
return 0;
}
#endif

 +
 + /* bail out verbosely on any other error */
 + if (ret) {
 + pr_err(error setting wl12xx data: %d\n, ret);
 + return ret;
 + }
 +
 + return 0;
 +}
 +
  static int __init omap3_l3_init(void)
  {
   struct omap_hwmod *oh;

-- 
Regards,
Igor.
--
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] drivers: bus: omap_interconnect: Fix rand-config build warning

2012-10-17 Thread Lokesh Vutla

When building omap_l3_noc/smx drivers as modules, the following
warning appears:

CC [M]  drivers/bus/omap_l3_smx.o
drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage 
class
drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration 
of 'postcore_initcall_sync'
drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in 
function declaration
drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used
CC [M]  drivers/bus/omap_l3_noc.o
drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage 
class
drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration 
of 'arch_initcall_sync'
drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in 
function declaration
drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used

Adding module_init() and macros in omap_l3_noc/smx drivers when building
as modules to remove the above warning.

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
 drivers/bus/omap_l3_noc.c |9 +
 drivers/bus/omap_l3_smx.c |   10 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index d15225f..8222a33 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -257,10 +257,19 @@ static int __init omap4_l3_init(void)
 {
return platform_driver_register(omap4_l3_driver);
 }
+#ifndef CONFIG_OMAP_INTERCONNECT_MODULE
 postcore_initcall_sync(omap4_l3_init);
+#else
+module_init(omap4_l3_init);
+#endif
 
 static void __exit omap4_l3_exit(void)
 {
platform_driver_unregister(omap4_l3_driver);
 }
 module_exit(omap4_l3_exit);
+
+MODULE_ALIAS(platform: omap_l3_noc);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_DESCRIPTION(OMAP4XXX L3 Interconnect Driver);
+MODULE_LICENSE(GPL v2);
diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index acc2164..00f712d 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -22,6 +22,7 @@
  * USA
  */
 
+#include linux/module.h
 #include linux/kernel.h
 #include linux/slab.h
 #include linux/platform_device.h
@@ -288,10 +289,19 @@ static int __init omap3_l3_init(void)
 {
return platform_driver_probe(omap3_l3_driver, omap3_l3_probe);
 }
+#ifndef CONFIG_OMAP_INTERCONNECT_MODULE
 postcore_initcall_sync(omap3_l3_init);
+#else
+module_init(omap3_l3_init);
+#endif
 
 static void __exit omap3_l3_exit(void)
 {
platform_driver_unregister(omap3_l3_driver);
 }
 module_exit(omap3_l3_exit);
+
+MODULE_ALIAS(platform: omap_l3_smx);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_DESCRIPTION(OMAP3XXX L3 Interconnect Driver);
+MODULE_LICENSE(GPL v2);
-- 
1.7.10.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] drivers: bus: omap_interconnect: Fix rand-config build warning

2012-10-17 Thread Santosh Shilimkar


(Looping Arnd and Olof)

On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote:

When building omap_l3_noc/smx drivers as modules, the following
warning appears:

CC [M]  drivers/bus/omap_l3_smx.o
drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage 
class
drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration 
of 'postcore_initcall_sync'
drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in 
function declaration
drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used
CC [M]  drivers/bus/omap_l3_noc.o
drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage 
class
drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration 
of 'arch_initcall_sync'
drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in 
function declaration
drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used

Adding module_init() and macros in omap_l3_noc/smx drivers when building
as modules to remove the above warning.

Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---

Thanks for the fix Lokesh. Looks fine to me.

Acked-by: Santosh Shilimkar santosh.shilim...@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: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support)

Hi,

On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
 + peterz, tglx
 
 Felipe Balbi ba...@ti.com writes:
 
 [...]
 
  The problem I see is that even though we properly return IRQ_WAKE_THREAD
  and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
  the thread is never scheduled. To make things even worse, ouw irq thread
  runs once, but doesn't run on a consecutive call. Here's some (rather
  nasty) debug prints showing the problem:
 
 [...]
 
  [   88.721923] try_to_wake_up 1411
  [   88.725189] === irq_wake_thread 139: IRQ 72 wake_up_process 0
  [   88.731292] [sched_delayed] sched: RT throttling activated
 
 This throttling message is the key one.
 
 With RT throttling activated, the IRQ thread will not be run (it
 eventually will be allowed much later on, but by then, the I2C xfers
 have timed out.)
 
 As a quick hack, the throttling can be disabled by seeting the
 sched_rt_runtime to RUNTIME_INF:
 
 # sysctl -w kernel.sched_rt_runtime_us=-1
 
 and a quick test shows that things go back to working as expected.  But
 we still need to figure out why the throttling is hapenning...
 
 So I started digging into why the RT runtime was so high, and noticed
 that time spent in suspend was being counted as RT runtime!
 
 So spending time in suspend anywhere near sched_rt_runtime (0.95s) will
 cause the RT throttling to always be triggered, and thus prevent IRQ
 threads from running in the resume path.  Ouch.
 
 I think I'm already in over my head in the RT runtime stuff, but
 counting the time spent in suspend as RT runtime smells like a bug to
 me. no?
 
 Peter? Thomas?

it looks like removing console output completely (echo 0 
/proc/sysrq-trigger) I don't see the issue anymore. Let me just run for
a few more iterations to make sure what I'm saying is correct.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 9/9] OMAPDSS: DISPC: cleanup lcd/digit enable/disable

2012-10-17 Thread Archit Taneja


Hi,

On Wednesday 17 October 2012 04:50 PM, Tomi Valkeinen wrote:

We currently have a single function to enable and disable the manager
output for LCD and DIGIT. The functions are a bit complex, as handling
both enable and disable require some extra steps to ensure that the
output is enabled or disabled properly without errors before exiting the
function.

The code can be made simpler to understand by splitting the functions
into separate enable and disable functions. We'll also clean up the
comments and some parameter names at the same time.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
  drivers/video/omap2/dss/apply.c |6 +-
  drivers/video/omap2/dss/dispc.c |  178 ---
  drivers/video/omap2/dss/dss.h   |3 +-
  3 files changed, 116 insertions(+), 71 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index ae9f70d..4fff8ac 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -772,7 +772,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
if (!dss_data.irq_enabled  need_isr())
dss_register_vsync_isr();

-   dispc_mgr_enable(mgr-id, true);
+   dispc_mgr_enable(mgr-id);

mgr_clear_shadow_dirty(mgr);

@@ -1027,7 +1027,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr)
spin_unlock_irqrestore(data_lock, flags);

if (!mgr_manual_update(mgr))
-   dispc_mgr_enable(mgr-id, true);
+   dispc_mgr_enable(mgr-id);

  out:
mutex_unlock(apply_lock);
@@ -1052,7 +1052,7 @@ void dss_mgr_disable(struct omap_overlay_manager *mgr)
goto out;

if (!mgr_manual_update(mgr))
-   dispc_mgr_enable(mgr-id, false);
+   dispc_mgr_disable(mgr-id);

spin_lock_irqsave(data_lock, flags);

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 82339ad..94f393ec 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2590,7 +2590,7 @@ int dispc_ovl_enable(enum omap_plane plane, bool enable)
return 0;
  }

-static void dispc_disable_isr(void *data, u32 mask)
+static void dispc_mgr_disable_isr(void *data, u32 mask)
  {
struct completion *compl = data;
complete(compl);
@@ -2608,122 +2608,166 @@ bool dispc_mgr_is_enabled(enum omap_channel channel)
return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE);
  }

-static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable)
+static void dispc_mgr_enable_lcd_out(enum omap_channel channel)
  {
-   struct completion frame_done_completion;
-   bool is_on;
+   _enable_mgr_out(channel, true);
+}
+
+static void dispc_mgr_disable_lcd_out(enum omap_channel channel)
+{
+   DECLARE_COMPLETION_ONSTACK(framedone_compl);
int r;
u32 irq;

-   /* When we disable LCD output, we need to wait until frame is done.
-* Otherwise the DSS is still working, and turning off the clocks
-* prevents DSS from going to OFF mode */
-   is_on = dispc_mgr_is_enabled(channel);
+   if (dispc_mgr_is_enabled(channel) == false)
+   return;
+
+   /*
+* When we disable LCD output, we need to wait for FRAMEDONE to know
+* that DISPC has finished with the LCD output.
+*/

-   irq = mgr_desc[channel].framedone_irq;
+   irq = dispc_mgr_get_framedone_irq(channel);

-   if (!enable  is_on) {
-   init_completion(frame_done_completion);
+   r = omap_dispc_register_isr(dispc_mgr_disable_isr, framedone_compl,
+   irq);
+   if (r)
+   DSSERR(failed to register FRAMEDONE isr\n);

-   r = omap_dispc_register_isr(dispc_disable_isr,
-   frame_done_completion, irq);
+   _enable_mgr_out(channel, false);

-   if (r)
-   DSSERR(failed to register FRAMEDONE isr\n);
+   /* if we couldn't register for framedone, just sleep and exit */
+   if (r) {
+   msleep(200);


We sleep for 200 ms if we fail to register for framedone. But we just 
wait for 100ms for FRAMEDONE to occur. It seems a bit incorrect, both 
should be kept the same, shouldn't they?



+   return;
}

-   _enable_mgr_out(channel, enable);
+   if (!wait_for_completion_timeout(framedone_compl,
+   msecs_to_jiffies(100)))
+   DSSERR(timeout waiting for FRAME DONE\n);

-   if (!enable  is_on) {
-   if (!wait_for_completion_timeout(frame_done_completion,
-   msecs_to_jiffies(100)))
-   DSSERR(timeout waiting for FRAME DONE\n);
+   r = omap_dispc_unregister_isr(dispc_mgr_disable_isr, framedone_compl,
+   irq);
+   if (r)
+   DSSERR(failed to unregister FRAMEDONE isr\n);
+}

-

Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode


On 10/16/2012 04:26 PM, Tony Lindgren wrote:
 * Jon Hunter jon-hun...@ti.com [121016 14:00]:
 Hi Tony,

 On 10/16/2012 12:48 PM, Tony Lindgren wrote:
 * Richard Cochran richardcoch...@gmail.com [121015 12:18]:
 From: hvaib...@ti.com hvaib...@ti.com

 With recent changes in omap gpmc driver code, in case of DT
 boot mode, where bootloader does not configure gpmc cs space
 will result into kernel BUG() inside gpmc_mem_init() function,
 as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
 gpmc_config7[0].baseaddress is set to '0' on reset.

 This use-case is applicable for any board/EVM which doesn't have
 any peripheral connected to gpmc cs0, for example BeagleXM and
 BeagleBone, so DT boot mode fails.

 This patch adds of_have_populated_dt() check before creating
 device, so that for DT boot mode, gpmc probe will not be called
 which is expected behavior, as gpmc is not supported yet from DT.

 I'm applying this one into omap-for-v3.7-rc1/fixes-part2.

 Next time, please also cc linux-omap@vger.kernel.org for series
 like this. I'm sure the people reading the omap list are interested
 in these.

 This patch appears to be masking an underlying issue. How about 
 something like the following ...
 
 OK that looks good to me. I'll drop the earlier fix and use
 yours instead.

Hi Tony, sorry but I realised now that in my patch that I need to
take care of releasing and memory and clocks that were acquired 
during the probe. Here is a V2. If you prefer I can create a delta
patch also with the previous. 

Cheers
Jon

From 91f5234d567c07ce1579b50e52de1a1e06ce5c68 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Tue, 16 Oct 2012 15:22:58 -0500
Subject: [PATCH V2] ARM: OMAP2+: Allow kernel to boot even if GPMC fails to
 reserve memory

Currently, if the GPMC driver fails to reserve memory when probed we will
call BUG() and the kernel will not boot. Instead of calling BUG(), return
an error from probe and allow kernel to boot.

Boot tested on AM335x beagle bone board and OMAP4430 Panda board.

V2 changes:
- Ensure that clock and memory resources are released on error.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |   24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5ac5cf3..92b5718 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -868,9 +868,9 @@ static void __devexit gpmc_mem_exit(void)
 
 }
 
-static void __devinit gpmc_mem_init(void)
+static int __devinit gpmc_mem_init(void)
 {
-   int cs;
+   int cs, rc;
unsigned long boot_rom_space = 0;
 
/* never allocate the first page, to facilitate bug detection;
@@ -890,13 +890,21 @@ static void __devinit gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, base, size);
-   if (gpmc_cs_insert_mem(cs, base, size)  0)
-   BUG();
+   rc = gpmc_cs_insert_mem(cs, base, size);
+   if (IS_ERR_VALUE(rc)) {
+   while (--cs = 0)
+   if (gpmc_cs_mem_enabled(cs))
+   gpmc_cs_delete_mem(cs);
+   return rc;
+   }
}
+
+   return 0;
 }
 
 static __devinit int gpmc_probe(struct platform_device *pdev)
 {
+   int rc;
u32 l;
struct resource *res;
 
@@ -936,7 +944,13 @@ static __devinit int gpmc_probe(struct platform_device 
*pdev)
dev_info(gpmc_dev, GPMC revision %d.%d\n, GPMC_REVISION_MAJOR(l),
 GPMC_REVISION_MINOR(l));
 
-   gpmc_mem_init();
+   rc = gpmc_mem_init();
+   if (IS_ERR_VALUE(rc)) {
+   clk_disable_unprepare(gpmc_l3_clk);
+   clk_put(gpmc_l3_clk);
+   dev_err(gpmc_dev, failed to reserve memory\n);
+   return rc;
+   }
 
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, gpmc_setup_irq failed\n);
-- 
1.7.9.5
 
--
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 0/4] OMAP-GPMC generic timing migration

2012-10-17 Thread Daniel Mack

Hi Afzal,

On 17.10.2012 07:42, Afzal Mohammed wrote:
 On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
 I certainly don't think it is easier, rather tougher, cleaner
 as well. One thing that worried me was, if we pursue the
 auxdata path (a last resort option) and later if it is
 objected, we would be back to square one.
 
 I commented on auxdata usage without visualising in more
 detail how it can be implemented, it was bad of me.
 
 I doubt whether auxdata would help here, it seems using
 compatible field alone would help in deciding relevant
 custom timing routine. Whether we want this kind of
 peripheral knowledge in gpmc driver instead of using
 generic timing routine has to be decided though.

Maybe slightly off-topic, but still:

When GPMC is used for driving NAND chips that comply to CFI, the timings
could actually be derived from the connected peripheral as well. I
believe a slowest-possible-mode will have to be selected first for the
identication phase.

Another thing that might be worth thinking about is that apart from the
GPMC host controller and the peripherals, there could be other
components like level shifters or series resistors on the board that
limit the maximum speed of transactions. So in fact we might be better
off storing all that timing details in the DT, as they are in fact
highly application specific.


Daniel

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

[RFC/NOT FOR MERGING 0/5] OMAP PM patches

Hi guys,

this series is actually *REALLY* far from ready, but I wanted
to ask if I should continue down this track because it really
looks (to me at least) that OMAP's PM layer took a few uneecessary
shortcuts.

I'm trying to understand the reasoning behind that, so bear with
me for a while.

At least patches 1 and 4 look like they could go upstream, but
please give it a very good review. I will continue to work on
these if the rest of the community thinks it's valid, otherwise
I would like to get some explanation for the way OMAP PM layer
is implemented today.

cheers

Felipe Balbi (5):
  arm: omap: fix up _od_suspend_noirq and _od_resume_noirq
  arm: omap: don't forcefully runtime suspend a device
  arm: omap: introduce other PM methods
  i2c: omap: don't re-enable IRQs after masking them
  i2c: omap: introduce suspend/resume methods

 arch/arm/plat-omap/omap_device.c | 162 +--
 drivers/i2c/busses/i2c-omap.c|  70 -
 2 files changed, 207 insertions(+), 25 deletions(-)

-- 
1.8.0.rc0

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

[RFC/NOT FOR MERGING 2/5] arm: omap: don't forcefully runtime suspend a device

device drivers should be smart enough to provide
-suspend/-resume callbacks when needed and they
should take care of doing whatever needs to be
done in order to allow a device to be suspended.

Calling pm_runtime_* from system suspend isn't
the right way to achieve that, as it creates a
situation where OMAP's PM has different requirements
and semantics than all other architectures.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/plat-omap/omap_device.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 935f416..cd84eac 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -817,11 +817,9 @@ static int _od_suspend_noirq(struct device *dev)
ret = pm_generic_suspend_noirq(dev);
 
if (!ret  !pm_runtime_status_suspended(dev)) {
-   if (pm_generic_runtime_suspend(dev) == 0) {
-   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
-   omap_device_idle(pdev);
-   od-flags |= OMAP_DEVICE_SUSPENDED;
-   }
+   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
+   omap_device_idle(pdev);
+   od-flags |= OMAP_DEVICE_SUSPENDED;
}
 
return ret;
@@ -841,7 +839,6 @@ static int _od_resume_noirq(struct device *dev)
od-flags = ~OMAP_DEVICE_SUSPENDED;
if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
omap_device_enable(pdev);
-   pm_generic_runtime_resume(dev);
}
 
return pm_generic_resume_noirq(dev);
-- 
1.8.0.rc0

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

[RFC/NOT FOR MERGING 3/5] arm: omap: introduce other PM methods

current omap_device PM implementation defines
omap-specific *_noirq methods but uses the
generic versions for all other PM methods.

As it turns out, if a device decides to implement
non-runtime PM callbacks, we might fall into a
situation where the hwmod is still idled which
will generate an abort exception when we try
to access device's address space while clocks
are still gated.

In order to solve that, we implement all other
methods taking into account that devices might
not implement those, in which case we return
early.

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

notice here that it would be far better to avoid the code duplication
and have another function (e.g. _od_generic_suspend/resume) which would
receive pm_message_t and omap_device as arguments so it can decide
what to do.

That can be done on a later version, though.

 arch/arm/plat-omap/omap_device.c | 145 ++-
 1 file changed, 144 insertions(+), 1 deletion(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index cd84eac..60ce750 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -843,16 +843,159 @@ static int _od_resume_noirq(struct device *dev)
 
return pm_generic_resume_noirq(dev);
 }
+
+static int _od_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct omap_device *od = to_omap_device(pdev);
+   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+   int ret;
+
+   if (!pm || !pm-suspend)
+   return 0;
+
+   /* Don't attempt suspend on a driver that is not bound */
+   if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER)
+   return 0;
+
+   ret = pm_generic_suspend(dev);
+   if (ret)
+   return ret;
+
+   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
+   omap_device_idle(pdev);
+   od-flags |= OMAP_DEVICE_SUSPENDED;
+
+   return 0;
+}
+
+static int _od_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct omap_device *od = to_omap_device(pdev);
+   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+
+   if (!pm || !pm-resume)
+   return 0;
+
+   if (od-flags  OMAP_DEVICE_SUSPENDED) {
+   od-flags = ~OMAP_DEVICE_SUSPENDED;
+
+   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
+   omap_device_enable(pdev);
+   }
+
+   return pm_generic_resume(dev);
+}
+
+static int _od_freeze(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct omap_device *od = to_omap_device(pdev);
+   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+   int ret;
+
+   if (!pm || !pm-freeze)
+   return 0;
+
+   /* Don't attempt late suspend on a driver that is not bound */
+   if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER)
+   return 0;
+
+   ret = pm_generic_freeze(dev);
+   if (ret)
+   return ret;
+
+   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
+   omap_device_idle(pdev);
+   od-flags |= OMAP_DEVICE_SUSPENDED;
+
+   return 0;
+}
+
+static int _od_thaw(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct omap_device *od = to_omap_device(pdev);
+   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+
+   if (!pm || !pm-thaw)
+   return 0;
+
+   if (od-flags  OMAP_DEVICE_SUSPENDED) {
+   od-flags = ~OMAP_DEVICE_SUSPENDED;
+
+   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
+   omap_device_enable(pdev);
+   }
+
+   return pm_generic_thaw(dev);
+}
+
+static int _od_poweroff(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct omap_device *od = to_omap_device(pdev);
+   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+   int ret;
+
+   if (!pm || !pm-poweroff)
+   return 0;
+
+   /* Don't attempt late suspend on a driver that is not bound */
+   if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER)
+   return 0;
+
+   ret = pm_generic_poweroff(dev);
+   if (ret)
+   return ret;
+
+   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
+   omap_device_idle(pdev);
+   od-flags |= OMAP_DEVICE_SUSPENDED;
+
+   return 0;
+}
+
+static int _od_restore(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct omap_device *od = to_omap_device(pdev);
+   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+
+   if (!pm || !pm-restore)
+   return 0;
+
+   if (od-flags  OMAP_DEVICE_SUSPENDED) {
+   od-flags = ~OMAP_DEVICE_SUSPENDED;
+

[RFC/NOT FOR MERGING 5/5] i2c: omap: introduce suspend/resume methods

during system-wide (static) suspend, we also
want to save our context and restore it when
waking up.

Let's introduce new suspend/resume methods so
that we can survive a suspend-to-ram transition.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/i2c/busses/i2c-omap.c | 60 +++
 1 file changed, 50 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 7eeae11..ceab138 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1236,13 +1236,8 @@ static int __devexit omap_i2c_remove(struct 
platform_device *pdev)
 }
 
 #ifdef CONFIG_PM
-#ifdef CONFIG_PM_RUNTIME
-static int omap_i2c_runtime_suspend(struct device *dev)
+static int omap_i2c_low_level_suspend(struct omap_i2c_dev *_dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
-   u16 iv;
-
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
 
omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
@@ -1253,11 +1248,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
return 0;
 }
 
-static int omap_i2c_runtime_resume(struct device *dev)
+static int omap_i2c_low_level_resume(struct omap_i2c_dev *_dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
-
if (_dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
@@ -1278,9 +1270,57 @@ static int omap_i2c_runtime_resume(struct device *dev)
 
return 0;
 }
+
+static int omap_i2c_suspend(struct device *dev)
+{
+   struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
+
+   if (pm_runtime_suspended(dev))
+   return 0;
+
+   return omap_i2c_low_level_suspend(_dev);
+}
+
+static int omap_i2c_resume(struct device *dev)
+{
+   struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
+   int r;
+
+   r = omap_i2c_low_level_resume(_dev);
+   if (r)
+   return r;
+
+   pm_runtime_disable(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+   pm_runtime_mark_last_busy(dev);
+   pm_runtime_put_autosuspend(dev);
+
+   return 0;
+}
+
+#ifdef CONFIG_PM_RUNTIME
+static int omap_i2c_runtime_suspend(struct device *dev)
+{
+   struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
+
+   return omap_i2c_low_level_suspend(_dev);
+}
+
+static int omap_i2c_runtime_resume(struct device *dev)
+{
+   struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
+
+   return omap_i2c_low_level_resume(_dev);
+}
+#else
+#define omap_i2c_runtime_suspend NULL
+#define omap_i2c_runtime_resume NULL
 #endif /* CONFIG_PM_RUNTIME */
 
 static struct dev_pm_ops omap_i2c_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(omap_i2c_suspend,
+   omap_i2c_resume)
SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
   omap_i2c_runtime_resume, NULL)
 };
-- 
1.8.0.rc0

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

[RFC/NOT FOR MERGING 4/5] i2c: omap: don't re-enable IRQs after masking them

OMAP I2C driver will re-enable IRQs right after
masking them during suspend.

That's not what we want. We want to keep IRQs
masked until our resume method is called.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/i2c/busses/i2c-omap.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..7eeae11 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1247,14 +1247,8 @@ static int omap_i2c_runtime_suspend(struct device *dev)
 
omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
 
-   if (_dev-rev  OMAP_I2C_OMAP1_REV_2) {
-   iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
-   } else {
-   omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate);
-
-   /* Flush posted write */
-   omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
-   }
+   /* Flush posted write */
+   omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG);
 
return 0;
 }
-- 
1.8.0.rc0

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

[RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq

current implementation doesn't take care about
drivers which don't provide *_noirq methods and we
could fall into a situation where we would suspend/resume
devices even though they haven't asked for it.

One such case happened with the I2C driver which
was getting suspended during suspend_noirq() just
to be resume right after by any other device doing
an I2C transfer on its suspend method.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/plat-omap/omap_device.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7a7d1f2..935f416 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -804,8 +804,12 @@ static int _od_suspend_noirq(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
+   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
int ret;
 
+   if (!pm || !pm-suspend_noirq)
+   return 0;
+
/* Don't attempt late suspend on a driver that is not bound */
if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER)
return 0;
@@ -827,6 +831,10 @@ static int _od_resume_noirq(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct omap_device *od = to_omap_device(pdev);
+   const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+
+   if (!pm || !pm-resume_noirq)
+   return 0;
 
if ((od-flags  OMAP_DEVICE_SUSPENDED) 
!pm_runtime_status_suspended(dev)) {
-- 
1.8.0.rc0

--
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] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h

In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.

Move USB platform_data to linux/platform_data/omap-usb.h
and keep only internal functions in plat/usb.h.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/mach-omap2/usb-host.c |   1 +
 arch/arm/mach-omap2/usb-musb.c |   1 +
 arch/arm/mach-omap2/usb-tusb6010.c |   1 +
 arch/arm/plat-omap/include/plat/usb.h  | 126 +
 drivers/mfd/omap-usb-host.c|   2 +-
 drivers/usb/musb/am35x.c   |   3 +-
 drivers/usb/musb/musb_dsps.c   |   3 +-
 drivers/usb/musb/omap2430.h|   2 +-
 .../linux/platform_data/usb-omap.h |  80 +
 9 files changed, 36 insertions(+), 183 deletions(-)
 copy arch/arm/plat-omap/include/plat/usb.h = 
include/linux/platform_data/usb-omap.h (69%)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 3c43449..e0c2cad 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,6 +22,7 @@
 #include linux/platform_device.h
 #include linux/slab.h
 #include linux/dma-mapping.h
+#include linux/platform_data/usb-omap.h
 
 #include asm/io.h
 
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 51da21c..4fcd3a6 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -23,6 +23,7 @@
 #include linux/clk.h
 #include linux/dma-mapping.h
 #include linux/io.h
+#include linux/platform_data/usb-omap.h
 #include linux/usb/musb.h
 
 #include plat/usb.h
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c 
b/arch/arm/mach-omap2/usb-tusb6010.c
index 805bea6..5e24289 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -15,6 +15,7 @@
 #include linux/platform_device.h
 #include linux/gpio.h
 #include linux/export.h
+#include linux/platform_data/usb-omap.h
 
 #include linux/usb/musb.h
 
diff --git a/arch/arm/plat-omap/include/plat/usb.h 
b/arch/arm/plat-omap/include/plat/usb.h
index 87ee140..550e40e 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -3,86 +3,15 @@
 #ifndef__ASM_ARCH_OMAP_USB_H
 #define__ASM_ARCH_OMAP_USB_H
 
-#include linux/io.h
 #include linux/platform_device.h
-#include linux/usb/musb.h
-
-#define OMAP3_HS_USB_PORTS 3
-
-enum usbhs_omap_port_mode {
-   OMAP_USBHS_PORT_MODE_UNUSED,
-   OMAP_EHCI_PORT_MODE_PHY,
-   OMAP_EHCI_PORT_MODE_TLL,
-   OMAP_EHCI_PORT_MODE_HSIC,
-   OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM,
-   OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM,
-   OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM,
-   OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM,
-   OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM
-};
-
-struct usbhs_omap_board_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-
-   /* have to be valid if phy_reset is true and portx is in phy mode */
-   int reset_gpio_port[OMAP3_HS_USB_PORTS];
-
-   /* Set this to true for ES2.x silicon */
-   unsignedes2_compatibility:1;
-
-   unsignedphy_reset:1;
-
-   /*
-* Regulators for USB PHYs.
-* Each PHY can have a separate regulator.
-*/
-   struct regulator*regulator[OMAP3_HS_USB_PORTS];
-};
+#include linux/platform_data/usb-omap.h
 
 #ifdef CONFIG_ARCH_OMAP2PLUS
 
-struct ehci_hcd_omap_platform_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-   int reset_gpio_port[OMAP3_HS_USB_PORTS];
-   struct regulator*regulator[OMAP3_HS_USB_PORTS];
-   unsignedphy_reset:1;
-};
-
-struct ohci_hcd_omap_platform_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-   unsignedes2_compatibility:1;
-};
-
-struct usbhs_omap_platform_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-
-   struct ehci_hcd_omap_platform_data  *ehci_data;
-   struct ohci_hcd_omap_platform_data  *ohci_data;
-};
 
 struct usbtll_omap_platform_data {
enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
 };
-/*-*/
-
-struct omap_musb_board_data {
-   u8  interface_type;
-   u8  mode;
-   u16 power;
-   unsigned extvbus:1;
-   void(*set_phy_power)(u8 on);
-   void(*clear_irq)(void);
-   void(*set_mode)(u8 mode);
-   void(*reset)(void);
-};
-

Re: [PATCH] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h

Hi,

On Wed, Oct 17, 2012 at 06:43:41PM +0300, Felipe Balbi wrote:
 In order to make single zImage work for ARM architecture,
 we need to make sure we don't depend on private headers.
 
 Move USB platform_data to linux/platform_data/omap-usb.h
 and keep only internal functions in plat/usb.h.
 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
  arch/arm/mach-omap2/usb-host.c |   1 +
  arch/arm/mach-omap2/usb-musb.c |   1 +
  arch/arm/mach-omap2/usb-tusb6010.c |   1 +
  arch/arm/plat-omap/include/plat/usb.h  | 126 
 +
  drivers/mfd/omap-usb-host.c|   2 +-
  drivers/usb/musb/am35x.c   |   3 +-
  drivers/usb/musb/musb_dsps.c   |   3 +-
  drivers/usb/musb/omap2430.h|   2 +-
  .../linux/platform_data/usb-omap.h |  80 +
  9 files changed, 36 insertions(+), 183 deletions(-)
  copy arch/arm/plat-omap/include/plat/usb.h = 
 include/linux/platform_data/usb-omap.h (69%)
 
 diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
 index 3c43449..e0c2cad 100644
 --- a/arch/arm/mach-omap2/usb-host.c
 +++ b/arch/arm/mach-omap2/usb-host.c
 @@ -22,6 +22,7 @@
  #include linux/platform_device.h
  #include linux/slab.h
  #include linux/dma-mapping.h
 +#include linux/platform_data/usb-omap.h
  
  #include asm/io.h
  
 diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
 index 51da21c..4fcd3a6 100644
 --- a/arch/arm/mach-omap2/usb-musb.c
 +++ b/arch/arm/mach-omap2/usb-musb.c
 @@ -23,6 +23,7 @@
  #include linux/clk.h
  #include linux/dma-mapping.h
  #include linux/io.h
 +#include linux/platform_data/usb-omap.h
  #include linux/usb/musb.h
  
  #include plat/usb.h
 diff --git a/arch/arm/mach-omap2/usb-tusb6010.c 
 b/arch/arm/mach-omap2/usb-tusb6010.c
 index 805bea6..5e24289 100644
 --- a/arch/arm/mach-omap2/usb-tusb6010.c
 +++ b/arch/arm/mach-omap2/usb-tusb6010.c
 @@ -15,6 +15,7 @@
  #include linux/platform_device.h
  #include linux/gpio.h
  #include linux/export.h
 +#include linux/platform_data/usb-omap.h
  
  #include linux/usb/musb.h
  
 diff --git a/arch/arm/plat-omap/include/plat/usb.h 
 b/arch/arm/plat-omap/include/plat/usb.h
 index 87ee140..550e40e 100644
 --- a/arch/arm/plat-omap/include/plat/usb.h
 +++ b/arch/arm/plat-omap/include/plat/usb.h
 @@ -3,86 +3,15 @@
  #ifndef  __ASM_ARCH_OMAP_USB_H
  #define  __ASM_ARCH_OMAP_USB_H
  
 -#include linux/io.h
  #include linux/platform_device.h
 -#include linux/usb/musb.h
 -
 -#define OMAP3_HS_USB_PORTS   3
 -
 -enum usbhs_omap_port_mode {
 - OMAP_USBHS_PORT_MODE_UNUSED,
 - OMAP_EHCI_PORT_MODE_PHY,
 - OMAP_EHCI_PORT_MODE_TLL,
 - OMAP_EHCI_PORT_MODE_HSIC,
 - OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0,
 - OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM,
 - OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0,
 - OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM,
 - OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0,
 - OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM,
 - OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0,
 - OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM,
 - OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0,
 - OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM
 -};
 -
 -struct usbhs_omap_board_data {
 - enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
 -
 - /* have to be valid if phy_reset is true and portx is in phy mode */
 - int reset_gpio_port[OMAP3_HS_USB_PORTS];
 -
 - /* Set this to true for ES2.x silicon */
 - unsignedes2_compatibility:1;
 -
 - unsignedphy_reset:1;
 -
 - /*
 -  * Regulators for USB PHYs.
 -  * Each PHY can have a separate regulator.
 -  */
 - struct regulator*regulator[OMAP3_HS_USB_PORTS];
 -};
 +#include linux/platform_data/usb-omap.h
  
  #ifdef CONFIG_ARCH_OMAP2PLUS
  
 -struct ehci_hcd_omap_platform_data {
 - enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
 - int reset_gpio_port[OMAP3_HS_USB_PORTS];
 - struct regulator*regulator[OMAP3_HS_USB_PORTS];
 - unsignedphy_reset:1;
 -};
 -
 -struct ohci_hcd_omap_platform_data {
 - enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
 - unsignedes2_compatibility:1;
 -};
 -
 -struct usbhs_omap_platform_data {
 - enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
 -
 - struct ehci_hcd_omap_platform_data  *ehci_data;
 - struct ohci_hcd_omap_platform_data  *ohci_data;
 -};
  
  struct usbtll_omap_platform_data {
   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
  };

looks like should be moved too... I'll respin the patch.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH v2] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h

In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.

Move USB platform_data to linux/platform_data/omap-usb.h
and keep only internal functions in plat/usb.h.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/mach-omap2/usb-host.c |   1 +
 arch/arm/mach-omap2/usb-musb.c |   1 +
 arch/arm/mach-omap2/usb-tusb6010.c |   1 +
 arch/arm/plat-omap/include/plat/usb.h  | 130 +
 drivers/mfd/omap-usb-host.c|   2 +-
 drivers/usb/musb/am35x.c   |   3 +-
 drivers/usb/musb/musb_dsps.c   |   3 +-
 drivers/usb/musb/omap2430.h|   2 +-
 .../linux/platform_data/usb-omap.h |  84 +
 9 files changed, 40 insertions(+), 187 deletions(-)
 copy arch/arm/plat-omap/include/plat/usb.h = 
include/linux/platform_data/usb-omap.h (71%)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 3c43449..e0c2cad 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,6 +22,7 @@
 #include linux/platform_device.h
 #include linux/slab.h
 #include linux/dma-mapping.h
+#include linux/platform_data/usb-omap.h
 
 #include asm/io.h
 
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 51da21c..4fcd3a6 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -23,6 +23,7 @@
 #include linux/clk.h
 #include linux/dma-mapping.h
 #include linux/io.h
+#include linux/platform_data/usb-omap.h
 #include linux/usb/musb.h
 
 #include plat/usb.h
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c 
b/arch/arm/mach-omap2/usb-tusb6010.c
index 805bea6..5e24289 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -15,6 +15,7 @@
 #include linux/platform_device.h
 #include linux/gpio.h
 #include linux/export.h
+#include linux/platform_data/usb-omap.h
 
 #include linux/usb/musb.h
 
diff --git a/arch/arm/plat-omap/include/plat/usb.h 
b/arch/arm/plat-omap/include/plat/usb.h
index 87ee140..2d5c027 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -3,86 +3,11 @@
 #ifndef__ASM_ARCH_OMAP_USB_H
 #define__ASM_ARCH_OMAP_USB_H
 
-#include linux/io.h
 #include linux/platform_device.h
-#include linux/usb/musb.h
-
-#define OMAP3_HS_USB_PORTS 3
-
-enum usbhs_omap_port_mode {
-   OMAP_USBHS_PORT_MODE_UNUSED,
-   OMAP_EHCI_PORT_MODE_PHY,
-   OMAP_EHCI_PORT_MODE_TLL,
-   OMAP_EHCI_PORT_MODE_HSIC,
-   OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM,
-   OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM,
-   OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM,
-   OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM,
-   OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0,
-   OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM
-};
-
-struct usbhs_omap_board_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-
-   /* have to be valid if phy_reset is true and portx is in phy mode */
-   int reset_gpio_port[OMAP3_HS_USB_PORTS];
-
-   /* Set this to true for ES2.x silicon */
-   unsignedes2_compatibility:1;
-
-   unsignedphy_reset:1;
-
-   /*
-* Regulators for USB PHYs.
-* Each PHY can have a separate regulator.
-*/
-   struct regulator*regulator[OMAP3_HS_USB_PORTS];
-};
+#include linux/platform_data/usb-omap.h
 
 #ifdef CONFIG_ARCH_OMAP2PLUS
 
-struct ehci_hcd_omap_platform_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-   int reset_gpio_port[OMAP3_HS_USB_PORTS];
-   struct regulator*regulator[OMAP3_HS_USB_PORTS];
-   unsignedphy_reset:1;
-};
-
-struct ohci_hcd_omap_platform_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-   unsignedes2_compatibility:1;
-};
-
-struct usbhs_omap_platform_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-
-   struct ehci_hcd_omap_platform_data  *ehci_data;
-   struct ohci_hcd_omap_platform_data  *ohci_data;
-};
-
-struct usbtll_omap_platform_data {
-   enum usbhs_omap_port_mode   port_mode[OMAP3_HS_USB_PORTS];
-};
-/*-*/
-
-struct omap_musb_board_data {
-   u8  interface_type;
-   u8  mode;
-   u16 power;
-   unsigned extvbus:1;
-   void(*set_phy_power)(u8 on);
-   void(*clear_irq)(void);
-   void(*set_mode)(u8 mode);
-   void(*reset)(void);
-};
-

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

* Daniel Mack zon...@gmail.com [121017 08:15]:
 Hi Afzal,
 
 On 17.10.2012 07:42, Afzal Mohammed wrote:
  On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
  I certainly don't think it is easier, rather tougher, cleaner
  as well. One thing that worried me was, if we pursue the
  auxdata path (a last resort option) and later if it is
  objected, we would be back to square one.
  
  I commented on auxdata usage without visualising in more
  detail how it can be implemented, it was bad of me.
  
  I doubt whether auxdata would help here, it seems using
  compatible field alone would help in deciding relevant
  custom timing routine. Whether we want this kind of
  peripheral knowledge in gpmc driver instead of using
  generic timing routine has to be decided though.
 
 Maybe slightly off-topic, but still:
 
 When GPMC is used for driving NAND chips that comply to CFI, the timings
 could actually be derived from the connected peripheral as well. I
 believe a slowest-possible-mode will have to be selected first for the
 identication phase.

I wish.. Just getting things working to the identification phase
requires quite a bit of configuration for the timings.
 
 Another thing that might be worth thinking about is that apart from the
 GPMC host controller and the peripherals, there could be other
 components like level shifters or series resistors on the board that
 limit the maximum speed of transactions. So in fact we might be better
 off storing all that timing details in the DT, as they are in fact
 highly application specific.

Yes and the level shifters affect timings too.

Regards,

Tony
--
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 v3] ARM: OMAP: i2c: fix interrupt flood during resume

Hi,

On Thu, Oct 11, 2012 at 02:08:25PM -0700, Kevin Hilman wrote:
 Hi Kalle,
 
 Kalle Jokiniemi kalle.jokini...@jollamobile.com writes:
 
  The resume_noirq enables interrupts one-by-one starting from
  first one. Now if the wake up event for suspend came from i2c
  device, the i2c bus irq gets enabled before the threaded
  i2c device irq, causing a flood of i2c bus interrupts as the
  threaded irq that should clear the event is not enabled yet.
 
  Fixed the issue by adding suspend_noirq and resume_early
  functions that keep i2c bus interrupts disabled until
  resume_noirq has run completely.
 
  Issue was detected doing a wake up from autosleep with
  twl4030 power key on N9. Patch tested on N9.
 
  Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com
 
 This version looks good, thanks for the extra comments.
 
 Reviewed-by: Kevin Hilman khil...@ti.com
 Tested-by: Kevin Hilman khil...@ti.com
 
 Wolfram, This should also probably be Cc'd to stable since it affects
 earlier kernels as well.  Thanks,

just to make sure we're not fixing the wrong problem... does [1] help in
any way ?

[1] http://marc.info/?l=linux-omapm=135048839915719w=2

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode

* Jon Hunter jon-hun...@ti.com [121017 07:43]:
 
 On 10/16/2012 04:26 PM, Tony Lindgren wrote:
  * Jon Hunter jon-hun...@ti.com [121016 14:00]:
  Hi Tony,
 
  On 10/16/2012 12:48 PM, Tony Lindgren wrote:
  * Richard Cochran richardcoch...@gmail.com [121015 12:18]:
  From: hvaib...@ti.com hvaib...@ti.com
 
  With recent changes in omap gpmc driver code, in case of DT
  boot mode, where bootloader does not configure gpmc cs space
  will result into kernel BUG() inside gpmc_mem_init() function,
  as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
  gpmc_config7[0].baseaddress is set to '0' on reset.
 
  This use-case is applicable for any board/EVM which doesn't have
  any peripheral connected to gpmc cs0, for example BeagleXM and
  BeagleBone, so DT boot mode fails.
 
  This patch adds of_have_populated_dt() check before creating
  device, so that for DT boot mode, gpmc probe will not be called
  which is expected behavior, as gpmc is not supported yet from DT.
 
  I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
 
  Next time, please also cc linux-omap@vger.kernel.org for series
  like this. I'm sure the people reading the omap list are interested
  in these.
 
  This patch appears to be masking an underlying issue. How about 
  something like the following ...
  
  OK that looks good to me. I'll drop the earlier fix and use
  yours instead.
 
 Hi Tony, sorry but I realised now that in my patch that I need to
 take care of releasing and memory and clocks that were acquired 
 during the probe. Here is a V2. If you prefer I can create a delta
 patch also with the previous. 

OK thanks I'll update it.

Regards,

Tony
--
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] i2c: omap: adopt pinctrl support

2012-10-17 Thread Shubhrajyoti Datta

On Tue, Oct 16, 2012 at 8:53 PM, Sebastien Guiriec s-guir...@ti.com wrote:
 Some GPIO expanders need some early pin control muxing. Due to
 legacy boards sometimes the driver uses subsys_initcall instead of
 module_init. This patch takes advantage of defer probe feature
 and pin control in order to wait until pin control probing before
 GPIO driver probing. It has been tested on OMAP5 board with TCA6424
 driver.

 log:

 [0.482299] omap_i2c i2c.15: could not find pctldev for node /ocp/pinmux@4a00
 2840/pinmux_i2c5_pins, deferring probe
 [0.482330] platform i2c.15: Driver omap_i2c requests probe deferral
 [0.484466] Advanced Linux Sound Architecture Driver Initialized.

 [4.746917] omap_i2c i2c.15: bus 4 rev2.4.0 at 100 kHz
 [4.755279] gpiochip_find_base: found new base at 477
 [4.761169] gpiochip_add: registered GPIOs 477 to 500 on device: tca6424a

Thanks,

Acked-by: Shubhrajyoti D shubhrajy...@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] ARM: OMAP: move plat-omap/include/plat/sdrc.h into mach-omap2/sdrc.h

* Paul Walmsley p...@pwsan.com [121016 17:48]:
 
 Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents
 into arch/arm/mach-omap2/sdrc.h.  The objective is to assist Tony in
 cleaning out arch/arm/plat-omap/, as his upstreams request.
 
 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Tony Lindgren t...@atomide.com
 ---
 
 This has a dependency on Tomi's OMAP: VRFB: convert to platform device 
 series.

Thanks applying this into omap-for-v3.8/cleanup-headers-dss.

Regards,

Tony
--
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 V3 0/5] ARM: OMAP2+: Add device-tree support for timers

This series adds device-tree support for the timers on OMAP2+ devices
including AM33xx.

Testing:
1. I have booted tested this series on OMAP2420 H4, OMAP3430 Beagle, OMAP4430
   Panda and AM335x Beagle Bone with/without ...
   a). device-tree present
   b). CONFIG_OMAP_32K_TIMER set
   c). kernel boot parameter clocksource=gp_timer present
2. I have tested the all the timers (not used by the kernel as sys-timers) on
   OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda with/without device-tree with
   this series. The testing includes ...
   a. Configuring, starting a timer and checking the counter value is
  incrementing.
   b. Testing timer overflow interrupt when timer expires.
   c. Using different clock sources to operate the timer with.

V3 changes:
- Removed definition TIMER_PROP_ALWON per Rob Herring's feedback
- Updated OMAP system timer (clock-events and clock-source) code so that
  HWMOD is NOT used for getting resource (memory and interrupt) information
  when device-tree is present.

V2 changes:
- Remove use of device-tree alias property
- Migrate OMAP timers to request timers by property instead of device ID
- Include OMAP2 support

Jon Hunter (5):
  ARM: dts: OMAP: Add timer nodes
  ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
  ARM: OMAP: Add function to request a timer by capability
  ARM: OMAP3: Add generic machine descriptor for boards with OMAP3 GP
devices
  ARM: OMAP: Add DT support for timer driver

 .../devicetree/bindings/arm/omap/timer.txt |   29 
 arch/arm/boot/dts/am33xx.dtsi  |   61 +++
 arch/arm/boot/dts/omap2.dtsi   |   86 ++
 arch/arm/boot/dts/omap2420.dtsi|8 +
 arch/arm/boot/dts/omap2430.dtsi|8 +
 arch/arm/boot/dts/omap3.dtsi   |   96 +++
 arch/arm/boot/dts/omap4.dtsi   |   86 ++
 arch/arm/mach-omap2/board-generic.c|   17 ++
 arch/arm/mach-omap2/timer.c|  174 
 arch/arm/plat-omap/dmtimer.c   |   93 ++-
 arch/arm/plat-omap/include/plat/dmtimer.h  |1 +
 11 files changed, 622 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt

-- 
1.7.9.5

--
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 V3 1/5] ARM: dts: OMAP: Add timer nodes

Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.

Add documentation for timer properties specific to OMAP.

Please note that for OMAP2/3 devices, there is only one interrupt controller
for the ARM CPU (which has the label intc) and so globally define this as the
interrupt parent to save duplicating the interrupt parent for all device nodes.

Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
Vaibhav's original nodes adding information on which timers support a PWM
output.

Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 .../devicetree/bindings/arm/omap/timer.txt |   29 ++
 arch/arm/boot/dts/am33xx.dtsi  |   61 +
 arch/arm/boot/dts/omap2.dtsi   |   86 ++
 arch/arm/boot/dts/omap2420.dtsi|8 ++
 arch/arm/boot/dts/omap2430.dtsi|8 ++
 arch/arm/boot/dts/omap3.dtsi   |   96 
 arch/arm/boot/dts/omap4.dtsi   |   86 ++
 7 files changed, 374 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt 
b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 000..d9449d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,29 @@
+OMAP Timer bindings
+
+Required properties:
+- compatible:  Must be ti,omap2-timer for OMAP2+ controllers
+- reg: Contains timer register address range (base address and length)
+- interrupts:  Contains the interrupt information for the timer. The format is
+   being dependent on which interrupt controller the OMAP device
+   uses.
+- ti,hwmods:   Name of the hwmod associated to the timer, timerX, where
+   X is the instance number of the timer from the HW spec.
+
+Optional properties:
+- ti,timer-alwon:  Indicates the timer is in an alway-on power domain.
+- ti,timer-dsp:Indicates the timer can interrupt the on-chip 
DSP in
+   addition to the ARM CPU.
+- ti,timer-pwm:Indicates the timer can generate a PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
+   and therefore cannot be used by the kernel.
+
+Example:
+
+timer12: timer@48304000 {
+   compatible = ti,omap2-timer;
+   reg = 0x48304000 0xfff;
+   interrupts = 95;
+   ti,hwmods = timer12
+   ti,timer-alwon;
+   ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..fd5074c 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,66 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+   timer1: timer@44e31000 {
+   compatible = ti,omap2-timer;
+   reg = 0x44e31000 0x1000;
+   interrupt-parent = intc;
+   interrupts = 67;
+   ti,hwmods = timer1;
+   ti,timer-alwon;
+   };
+
+   timer2: timer@4804 {
+   compatible = ti,omap2-timer;
+   reg = 0x4804 0x1000;
+   interrupt-parent = intc;
+   interrupts = 68;
+   ti,hwmods = timer2;
+   };
+
+   timer3: timer@48042000 {
+   compatible = ti,omap2-timer;
+   reg = 0x48042000 0x1000;
+   interrupt-parent = intc;
+   interrupts = 69;
+   ti,hwmods = timer3;
+   };
+
+   timer4: timer@48044000 {
+   compatible = ti,omap2-timer;
+   reg = 0x48044000 0x1000;
+   interrupt-parent = intc;
+   interrupts = 92;
+   ti,hwmods = timer4;
+   ti,timer-pwm;
+   };
+
+   timer5: timer@48046000 {
+   compatible = ti,omap2-timer;
+   reg = 0x48046000 0x1000;
+   interrupt-parent = intc;
+   interrupts = 93;
+   ti,hwmods = timer5;
+   ti,timer-pwm;
+   };
+
+   timer6: timer@48048000 {
+   compatible = ti,omap2-timer;
+   reg = 0x48048000 0x1000;
+   interrupt-parent = intc;
+   interrupts = 94;
+   ti,hwmods = timer6;
+   ti,timer-pwm;

[PATCH V3 2/5] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices

OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).

For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for secure usage and so cannot be used by
the kernel, where as for a GP device it is available. We can detect the OMAP
device type, secure or GP, at runtime via an on-chip register. Today, when not
using DT, we do not register the 12th timer as a linux device if the device is
secure.

When using device tree, device tree is going to register all the timer devices
it finds in the device tree blob. To prevent device tree from registering 12th
timer on a secure OMAP3 device we can add a status property to the timer
binding with the value disabled at boot time. Note that timer 12 on a OMAP3
device has a property ti,timer-secure to indicate that it will not be
available on a secure device and so for secure OMAP3 devices, we search for
timers with this property and then disable them. Using the prom_add_property()
function to dynamically add a property was a recommended approach suggested by
Rob Herring [1].

I have tested this on an OMAP3 GP device and faking it to pretend to be a
secure device to ensure that any timers marked with ti,timer-secure are not
registered on boot. I have also made sure that all timers are registered as
expected on a GP device by default.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |   36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 44f9aa7..96d26f2 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -144,6 +144,41 @@ static struct clock_event_device clockevent_gpt = {
.set_mode   = omap2_gp_timer_set_mode,
 };
 
+static struct property device_disabled = {
+   .name = status,
+   .length = sizeof(disabled),
+   .value = disabled,
+};
+
+static struct of_device_id omap_timer_match[] __initdata = {
+   { .compatible = ti,omap2-timer, },
+   { }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type timer-secure cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{
+   struct device_node *np;
+
+   if (!cpu_is_omap34xx())
+   return;
+
+   /* If we are a secure device, remove any secure timer nodes */
+   if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
+   for_each_matching_node(np, omap_timer_match) {
+   if (of_get_property(np, ti,timer-secure, NULL))
+   prom_add_property(np, device_disabled);
+   }
+   }
+}
+
 static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
int gptimer_id,
const char *fck_source)
@@ -437,6 +472,7 @@ static inline void __init realtime_counter_init(void)
clksrc_nr, clksrc_src)  \
 static void __init omap##name##_timer_init(void)   \
 {  \
+   omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src);\
omap2_clocksource_init((clksrc_nr), clksrc_src);\
 }
-- 
1.7.9.5

--
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 V3 3/5] ARM: OMAP: Add function to request a timer by capability

Currently OMAP timers can be requested by requesting any available or by a
numerical device ID. If a specific timer is required because it has a particular
capability, such as can interrupt the on-chip DSP in addition to the ARM CPU,
then the user needs to know the device ID of the timer with this feature.
Therefore, add a new API called omap_dm_timer_request_by_cap() that allows
drivers to request a timer by capability.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/plat-omap/dmtimer.c  |   52 +
 arch/arm/plat-omap/include/plat/dmtimer.h |1 +
 2 files changed, 53 insertions(+)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 938b50a..2574b86 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -237,6 +237,58 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int 
id)
 }
 EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific);
 
+/**
+ * omap_dm_timer_request_by_cap - Request a timer by capability
+ * @cap:   Bit mask of capabilities to match
+ *
+ * Find a timer based upon capabilities bit mask. Callers of this function
+ * should use the definitions found in the plat/dmtimer.h file under the
+ * comment timer capabilities used in hwmod database. Returns pointer to
+ * timer handle on success and a NULL pointer on failure.
+ */
+struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
+{
+   struct omap_dm_timer *timer = NULL, *t;
+   unsigned long flags;
+
+   if (!cap)
+   return NULL;
+
+   spin_lock_irqsave(dm_timer_lock, flags);
+   list_for_each_entry(t, omap_timer_list, node) {
+   if ((!t-reserved)  ((t-capability  cap) == cap)) {
+   /*
+* If timer is not NULL, we have already found one timer
+* but it was not an exact match because it had more
+* capabilites that what was required. Therefore,
+* unreserve the last timer found and see if this one
+* is a better match.
+*/
+   if (timer)
+   timer-reserved = 0;
+
+   timer = t;
+   timer-reserved = 1;
+
+   /* Exit loop early if we find an exact match */
+   if (t-capability == cap)
+   break;
+   }
+   }
+   spin_unlock_irqrestore(dm_timer_lock, flags);
+
+   if (timer  omap_dm_timer_prepare(timer)) {
+   timer-reserved = 0;
+   timer = NULL;
+   }
+
+   if (!timer)
+   pr_debug(%s: timer request failed!\n, __func__);
+
+   return timer;
+}
+EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap);
+
 int omap_dm_timer_free(struct omap_dm_timer *timer)
 {
if (unlikely(!timer))
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 85868e9..348f855 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -99,6 +99,7 @@ struct dmtimer_platform_data {
 int omap_dm_timer_reserve_systimer(int id);
 struct omap_dm_timer *omap_dm_timer_request(void);
 struct omap_dm_timer *omap_dm_timer_request_specific(int timer_id);
+struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap);
 int omap_dm_timer_free(struct omap_dm_timer *timer);
 void omap_dm_timer_enable(struct omap_dm_timer *timer);
 void omap_dm_timer_disable(struct omap_dm_timer *timer);
-- 
1.7.9.5

--
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 V3 4/5] ARM: OMAP3: Add generic machine descriptor for boards with OMAP3 GP devices

OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).

Some OMAP3 boards, such as the OMAP3 beagle board, only use GP devices and for
GP devices there is a 12th timer available on-chip that can operate at 32kHz.
The clock for 12th timer is generated by an internal oscillator and is unique
this timer. Boards such as the beagle board use this timer as a 32kHz based
clock-events timer because early versions of the board had a hardware problem
preventing them from using other on-chip timers clocked by a external 32kHz
clock.

When booting with device-tree all OMAP3 devices use timer 1 by default for
the clock-events timer. Therefore, add a generic machine descriptor for boards
with OMAP3 GP devices so that they can use the 12th timer as the clock-events
timer instead of the default.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/board-generic.c |   17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..d690180 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -97,6 +97,23 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device 
Tree))
.dt_compat  = omap3_boards_compat,
.restart= omap_prcm_restart,
 MACHINE_END
+
+static const char *omap3_gp_boards_compat[] __initdata = {
+   ti,omap3-beagle,
+   NULL,
+};
+
+DT_MACHINE_START(OMAP3_GP_DT, Generic OMAP3-GP (Flattened Device Tree))
+   .reserve= omap_reserve,
+   .map_io = omap3_map_io,
+   .init_early = omap3430_init_early,
+   .init_irq   = omap_intc_of_init,
+   .handle_irq = omap3_intc_handle_irq,
+   .init_machine   = omap_generic_init,
+   .timer  = omap3_secure_timer,
+   .dt_compat  = omap3_gp_boards_compat,
+   .restart= omap_prcm_restart,
+MACHINE_END
 #endif
 
 #ifdef CONFIG_SOC_AM33XX
-- 
1.7.9.5

--
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 V3 5/5] ARM: OMAP: Add DT support for timer driver

In order to add device-tree support to the timer driver the following changes
were made ...

1. Allocate system timers (used for clock-events and clock-source) based upon
   timer properties rather than using an hard-coded timer instance ID. To allow
   this a new helper function called omap_dmtimer_find_by_property() has been
   added for finding a timer with the particular properties in the device-tree
   blob. Please note that this is an internal helper function for system timers
   only to find a timer in the device-tree blob. This cannot be used by device
   drivers, another API has been added for that (see below). Timers that are
   allocated for system timers are dynamically disabled at boot time by adding
   a status property with the value disabled to the timer's device-tree node.

   Please note that when allocating system timers we now pass a timer ID and
   timer property. The timer ID is only be used for allocating a timer when
   booting without device-tree. Once device-tree migration is complete, all
   the timer ID references will be removed.

2. System timer resources (memory and interrupts) are directly obtained from
   the device-tree timer node when booting with device-tree, so that system
   timers are no longer reliant upon the OMAP HWMOD framework to provide these
   resources.

3. If DT blob is present, then let device-tree create the timer devices
   dynamically.

4. When device-tree is present the id field in the platform_device structure
   (pdev-id) is initialised to -1 and hence cannot be used to identify a timer
   instance. Due to this the following changes were made ...
   a). The API omap_dm_timer_request_specific() is not supported when using
   device-tree, because it uses the device ID to request a specific timer.
   This function will return an error if called when device-tree is present.
   Users of this API should use omap_dm_timer_request_by_cap() instead.
   b). When removing the DMTIMER driver, the timer id was used to identify the
   timer instance. The remove function has been modified to use the device
   name instead of the id.

5. When device-tree is present the platform_data structure will be NULL and so
   check for this.

6. The OMAP timer device tree binding has the following optional parameters ...
   a). ti,timer-alwon  -- Timer is in an always-on power domain
   b). ti,timer-dsp-- Timer can generate an interrupt to the on-chip DSP
   c). ti,timer-pwm-- Timer can generate a PWM output
   d). ti,timer-secure -- Timer is reserved on a secure OMAP device
   Search for the above parameters and set the appropriate timer attribute
   flags.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c  |  146 --
 arch/arm/plat-omap/dmtimer.c |   41 ++--
 2 files changed, 146 insertions(+), 41 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 96d26f2..d064afd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -37,6 +37,8 @@
 #include linux/clockchips.h
 #include linux/slab.h
 #include linux/of.h
+#include linux/of_address.h
+#include linux/of_irq.h
 
 #include asm/mach/time.h
 #include asm/smp_twd.h
@@ -66,11 +68,13 @@
 #define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
 #define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
 #define OMAP3_SECURE_TIMER 12
+#define TIMER_PROP_SECURE  ti,timer-secure
 #else
 #define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
 #define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
 #define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
 #define OMAP3_SECURE_TIMER 1
+#define TIMER_PROP_SECURE  ti,timer-alwon
 #endif
 
 #define REALTIME_COUNTER_BASE  0x48243200
@@ -156,6 +160,40 @@ static struct of_device_id omap_timer_match[] __initdata = 
{
 };
 
 /**
+ * omap_get_timer_dt - get a timer using device-tree
+ * @match  - device-tree match structure for matching a device type
+ * @property   - optional timer property to match
+ *
+ * Helper function to get a timer during early boot using device-tree for use
+ * as kernel system timer. Optionally, the property argument can be used to
+ * select a timer with a specific property. Once a timer is found then mark
+ * the timer node in device-tree as disabled, to prevent the kernel from
+ * registering this timer as a platform device and so no one else can use it.
+ */
+static struct device_node * __init omap_get_timer_dt(struct of_device_id 
*match,
+const char *property)
+{
+   struct device_node *np;
+
+   for_each_matching_node(np, match) {
+   if (!of_device_is_available(np)) {
+   of_node_put(np);
+   continue;
+   }
+
+   if (property  !of_get_property(np, property, NULL)) {
+   of_node_put(np);
+   continue;
+   }
+
+

Re: [PATCH V3 0/5] ARM: OMAP2+: Add device-tree support for timers


On 10/17/2012 01:01 PM, Jon Hunter wrote:
 This series adds device-tree support for the timers on OMAP2+ devices
 including AM33xx.
 
 Testing:
 1. I have booted tested this series on OMAP2420 H4, OMAP3430 Beagle, OMAP4430
Panda and AM335x Beagle Bone with/without ...
a). device-tree present
b). CONFIG_OMAP_32K_TIMER set
c). kernel boot parameter clocksource=gp_timer present
 2. I have tested the all the timers (not used by the kernel as sys-timers) on
OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda with/without device-tree 
 with
this series. The testing includes ...
a. Configuring, starting a timer and checking the counter value is
   incrementing.
b. Testing timer overflow interrupt when timer expires.
c. Using different clock sources to operate the timer with.
 
 V3 changes:
 - Removed definition TIMER_PROP_ALWON per Rob Herring's feedback
 - Updated OMAP system timer (clock-events and clock-source) code so that
   HWMOD is NOT used for getting resource (memory and interrupt) information
   when device-tree is present.
 
 V2 changes:
 - Remove use of device-tree alias property
 - Migrate OMAP timers to request timers by property instead of device ID
 - Include OMAP2 support

Forgot to mention that this is based on top of v3.7-rc1.

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/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h

* Tony Lindgren t...@atomide.com [121015 17:09]:
 * Tony Lindgren t...@atomide.com [121009 17:21]:
  * Péter Ujfalusi peter.ujfal...@ti.com [121009 02:03]:
   On 10/08/2012 07:35 PM, Tony Lindgren wrote:
   
- omap-dma.c and omap-pcm.c can test the arch locally as
  omap1 and omap2 cannot be compiled together because of
  conflicting compiler flags
   
 sound/soc/omap/omap-pcm.c |9 +++--
   
   Tony: is this going to be included in 3.7?
  
  Hmm I guess we could try to get this out of the way
  to cut down the dependencies. Let's if maintainers
  of the other affected drivers this is OK for the
  -rc series.
 
 It seems that nobody needs these until for v3.8, so I'll
 be applying this into omap-for-v3.8/cleanup-headers-prepare
 branch soon.
 
 Anybody else care to ack?

OK pushed out now with just that patch in the branch in case
driver branches need to merge it in too to avoid conflicts.

Regards,

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

Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-17 Thread Richard Cochran

Paul,

Would you please take this bugfix for 3.7-rc2? The suggestion to mail
you came from Toni Lindgren. The context where it came from is here:

http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html

Thanks,
Richard

- Forwarded message from Richard Cochran richardcoch...@gmail.com -

Date: Mon, 15 Oct 2012 21:16:32 +0200
From: Richard Cochran richardcoch...@gmail.com
To: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org, Arnd Bergmann a...@arndb.de,
David Miller da...@davemloft.net,
Russell King li...@arm.linux.org.uk,
Mugunthan V N mugunthan...@ti.com
Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
X-Mailer: git-send-email 1.7.2.5

From: Mugunthan V N mugunthan...@ti.com

This patch adds minimal hwmod support for davinci mdio driver. This patch
requires rework on parent child relation between cpsw and davinci mdio
hwmod data to support runtime PM.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   34 ++-
 1 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..f96bbc0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc 
= {
.rev_offs   = 0x0,
.sysc_offs  = 0x8,
.syss_offs  = 0x4,
-   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
-  SYSS_HAS_RESET_STATUS),
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
   MSTANDBY_NO),
.sysc_fields= omap_hwmod_sysc_type3,
@@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
+   .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+  HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
 };
 
 /*
@@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space 
am33xx_elm_addr_space[] = {
{ }
 };
 
+/* mdio class */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+   .name   = davinci_mdio,
+};
+
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+   {
+   .pa_start   = 0x4A101000,
+   .pa_end = 0x4A101000 + SZ_256 - 1,
+   .flags  = ADDR_MAP_ON_INIT,
+   },
+   { }
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+   .name   = davinci_mdio,
+   .class  = am33xx_mdio_hwmod_class,
+   .clkdm_name = cpsw_125mhz_clkdm,
+   .main_clk   = cpsw_125mhz_gclk,
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+   .master = am33xx_cpgmac0_hwmod,
+   .slave  = am33xx_mdio_hwmod,
+   .addr   = am33xx_mdio_addr_space,
+   .user   = OCP_USER_MPU,
+};
+
 static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
.master = am33xx_l4_ls_hwmod,
.slave  = am33xx_elm_hwmod,
@@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] 
__initdata = {
am33xx_l3_main__tptc2,
am33xx_l3_s__usbss,
am33xx_l4_hs__cpgmac0,
+   am33xx_cpgmac0__mdio,
NULL,
 };
 
-- 
1.7.2.5


- End forwarded message -
--
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

Fwd: [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX

2012-10-17 Thread Richard Cochran

Benoit,

Would you please take this bugfix for 3.7-rc2? The suggestion to
mail you came from Toni Lindgren. The context where it came from
is here:

http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html

Thanks,
Richard

- Forwarded message from Richard Cochran richardcoch...@gmail.com -

Date: Mon, 15 Oct 2012 21:16:35 +0200
From: Richard Cochran richardcoch...@gmail.com
To: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org, Arnd Bergmann a...@arndb.de,
David Miller da...@davemloft.net,
Russell King li...@arm.linux.org.uk,
Mugunthan V N mugunthan...@ti.com,
Vaibhav Hiremath hvaib...@ti.com
Subject: [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX
X-Mailer: git-send-email 1.7.2.5

From: Mugunthan V N mugunthan...@ti.com

Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/boot/dts/am335x-bone.dts |8 ++
 arch/arm/boot/dts/am335x-evm.dts  |8 ++
 arch/arm/boot/dts/am33xx.dtsi |   50 +
 3 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
 };
+
+cpsw_emac0 {
+   phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+   phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
 };
+
+cpsw_emac0 {
+   phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+   phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..f6bea04 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,55 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+   mac: ethernet@4A10 {
+   compatible = ti,cpsw;
+   ti,hwmods = cpgmac0;
+   cpdma_channels = 8;
+   host_port_no = 0;
+   cpdma_reg_ofs = 0x800;
+   cpdma_sram_ofs = 0xa00;
+   ale_reg_ofs = 0xd00;
+   ale_entries = 1024;
+   host_port_reg_ofs = 0x108;
+   hw_stats_reg_ofs = 0x900;
+   bd_ram_ofs = 0x2000;
+   bd_ram_size = 0x2000;
+   no_bd_ram = 0;
+   rx_descs = 64;
+   mac_control = 0x20;
+   slaves = 2;
+   reg = 0x4a10 0x800
+   0x4a101200 0x100
+   0x4a101000 0x100;
+   #address-cells = 1;
+   #size-cells = 1;
+   interrupt-parent = intc;
+   /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend 
c0_misc_pend*/
+   interrupts = 40 41 42 43;
+   ranges;
+   cpsw_emac0: slave@0 {
+   slave_reg_ofs = 0x208;
+   sliver_reg_ofs = 0xd80;
+   /* Filled in by U-Boot */
+   mac-address = [ 00 00 00 00 00 00 ];
+   };
+   cpsw_emac1: slave@1 {
+   slave_reg_ofs = 0x308;
+   sliver_reg_ofs = 0xdc0;
+   /* Filled in by U-Boot */
+   mac-address = [ 00 00 00 00 00 00 ];
+   };
+
+   davinci_mdio: mdio@4a101000 {
+   compatible = ti,davinci_mdio;
+   #address-cells = 1;
+   #size-cells = 0;
+   ti,hwmods = davinci_mdio;
+   bus_freq = 100;
+   reg = 0x4a101000 0x100;
+   };
+
+   };
};
 };
-- 
1.7.2.5


- End forwarded message -
--
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 0/5] OMAP: VRFB: convert to platform device

* Tomi Valkeinen tomi.valkei...@ti.com [121017 03:27]:
 Hi Tony,
 
 I have pushed this vrfb series and the omapdss version series to:
 
 git://gitorious.org/linux-omap-dss2/linux.git 3.8/dss-version

I used this branch up to commit 35f70935c64ae229ebd1fc65398ec68d4d803712,
but left out the x86 compile changes as those seem unrelated to the plat
issue.

 git://gitorious.org/linux-omap-dss2/linux.git 3.8/vrfb-conversion

And then I merged in this branch. I have the merged branch at
omap-for-v3.8/cleanup-headers-dss.
 
 If they look ok to you and we don't get any other comments, I think
 these branches can be considered stable and you can pull them.

Thanks yes let's consider those frozen and if something needs to
be fixed it should be done on top of those commits.
 
 After these are merged:
 
 $ git grep -E (plat/)|(mach/) drivers/video/omap2/
 drivers/video/omap2/omapfb/omapfb-ioctl.c:#include plat/vram.h
 drivers/video/omap2/omapfb/omapfb-main.c:#include plat/vram.h
 drivers/video/omap2/vram.c:#include plat/vram.h
 
 So the vram stuff should be the only omap dependency left in omapdss and
 omapfb. I'll start working on that soon.

OK thanks a lot. Then there's also the two vout files that
you may already have patches for:

drivers/media/platform/omap/omap_vout.c
drivers/media/platform/omap/omap_voutlib.c

Regards,

Tony
--
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] Nokia N9/N900/N950 -- mention product names

2012-10-17 Thread Pavel Machek

Hi!

This adds product names (that most users know) to Kconfig and board
comments.

Signed-off-by: Pavel Machek pa...@ucw.cz

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 346fd26..da08226 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0
select MACH_NOKIA_N810_WIMAX
 
 config MACH_NOKIA_RM680
-   bool Nokia RM-680/696 board
+   bool Nokia N9/N950 (RM-680/696) phones
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
select MACH_NOKIA_RM696
 
 config MACH_NOKIA_RX51
-   bool Nokia RX-51 board
+   bool Nokia N900 phone (RX-51)
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
diff --git a/arch/arm/mach-omap2/board-rm680.c 
b/arch/arm/mach-omap2/board-rm680.c
index 0ad1bb3b..26965f3 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -1,5 +1,5 @@
 /*
- * Board support file for Nokia RM-680/696.
+ * Board support file for Nokia N9/N950 (aka RM-680/696).
  *
  * Copyright (C) 2010 Nokia
  *
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 345dd93..b60ca9d 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -1,5 +1,5 @@
 /*
- * linux/arch/arm/mach-omap2/board-rx51.c
+ * Board support file for Nokia N900 (aka RX-51).
  *
  * Copyright (C) 2007, 2008 Nokia
  *

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 0/2] ARM: OMAP2+: Add device-tree support for 32kHz counter

This series adds device-tree support for the 32kHz counter on OMAP2+ devices,
which is used as the default kernel clock-source for OMAP devices.

Boot tested on OMAP2420 H4, OMAP3430 Beagle Board and OMAP4430 Panda Board
with and without device-tree present.

Based and dependent upon OMAP2+ series that adds device-tree support for
DMTIMERs [1].

[1] http://marc.info/?l=linux-omapm=135049690119218w=2

Jon Hunter (2):
  ARM: dts: OMAP: Add counter-32k nodes
  ARM: OMAP2+: Add device-tree support for 32kHz counter

 .../devicetree/bindings/arm/omap/counter32k.txt|   15 +++
 arch/arm/boot/dts/omap2420.dtsi|6 +
 arch/arm/boot/dts/omap2430.dtsi|6 +
 arch/arm/boot/dts/omap3.dtsi   |6 +
 arch/arm/boot/dts/omap4.dtsi   |6 +
 arch/arm/mach-omap2/timer.c|   28 +++-
 6 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/counter32k.txt

-- 
1.7.9.5

--
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/2] ARM: dts: OMAP: Add counter-32k nodes

Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
device-tree binding documentation for OMAP counter-32k.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 .../devicetree/bindings/arm/omap/counter32k.txt|   15 +++
 arch/arm/boot/dts/omap2420.dtsi|6 ++
 arch/arm/boot/dts/omap2430.dtsi|6 ++
 arch/arm/boot/dts/omap3.dtsi   |6 ++
 arch/arm/boot/dts/omap4.dtsi   |6 ++
 5 files changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/counter32k.txt

diff --git a/Documentation/devicetree/bindings/arm/omap/counter32k.txt 
b/Documentation/devicetree/bindings/arm/omap/counter32k.txt
new file mode 100644
index 000..1983fae
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/counter32k.txt
@@ -0,0 +1,15 @@
+OMAP Counter-32K bindings
+
+Required properties:
+- compatible:  Must be ti,omap-counter32k for OMAP controllers
+- reg: Contains timer register address range (base address and length)
+- ti,hwmods:   Name of the hwmod associated to the counter, which is typically
+   counter_32k
+
+Example:
+
+counter32k: counter32k@4a304000 {
+   compatible = ti,omap-counter32k;
+   reg = 0x4a304000 0x001f;
+   ti,hwmods = counter_32k;
+};
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 5f68a70..082193f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -14,6 +14,12 @@
compatible = ti,omap2420, ti,omap2;
 
ocp {
+   counter32k: counter32k@48004000 {
+   compatible = ti,omap-counter32k;
+   reg = 0x48004000 0x001f;
+   ti,hwmods = counter_32k;
+   };
+
omap2420_pmx: pinmux@4830 {
compatible = ti,omap2420-padconf, pinctrl-single;
reg = 0x4830 0x0113;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 7439987..2e568cf 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -14,6 +14,12 @@
compatible = ti,omap2430, ti,omap2;
 
ocp {
+   counter32k: counter32k@4902 {
+   compatible = ti,omap-counter32k;
+   reg = 0x4902 0x001f;
+   ti,hwmods = counter_32k;
+   };
+
omap2430_pmx: pinmux@49002030 {
compatible = ti,omap2430-padconf, pinctrl-single;
reg = 0x49002030 0x0154;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3fb910f..aa775b2 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,6 +61,12 @@
ranges;
ti,hwmods = l3_main;
 
+   counter32k: counter32k@4832 {
+   compatible = ti,omap-counter32k;
+   reg = 0x4832 0x001f;
+   ti,hwmods = counter_32k;
+   };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index f6ac2b7..3eb66ee 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -95,6 +95,12 @@
ranges;
ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
 
+   counter32k: counter32k@4a304000 {
+   compatible = ti,omap-counter32k;
+   reg = 0x4a304000 0x001f;
+   ti,hwmods = counter_32k;
+   };
+
omap4_pmx_core: pinmux@4a100040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a100040 0x0196;
-- 
1.7.9.5

--
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/2] ARM: OMAP2+: Add device-tree support for 32kHz counter

For OMAP devices, the 32kHz counter is the default clock-source for the kernel.
However, this is not the only possible clock-source the kernel can use for OMAP
devices.

When booting with device-tree, if the 32kHz counter is the desired clock-source
for the kernel, then parse the device-tree blob to ensure that the counter is
present and if so map memory for the counter using the device-tree of_iomap()
function so we are no longer reliant on the OMAP HWMOD framework to do this for
us.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |   28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index d064afd..a67688f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -159,6 +159,11 @@ static struct of_device_id omap_timer_match[] __initdata = 
{
{ }
 };
 
+static struct of_device_id omap_counter_match[] __initdata = {
+   { .compatible = ti,omap-counter32k, },
+   { }
+};
+
 /**
  * omap_get_timer_dt - get a timer using device-tree
  * @match  - device-tree match structure for matching a device type
@@ -378,11 +383,26 @@ static u32 notrace dmtimer_read_sched_clock(void)
 static int __init omap2_sync32k_clocksource_init(void)
 {
int ret;
+   struct device_node *np = NULL;
struct omap_hwmod *oh;
void __iomem *vbase;
const char *oh_name = counter_32k;
 
/*
+* If device-tree is present, then search the DT blob
+* to see if the 32kHz counter is supported.
+*/
+   if (of_have_populated_dt()) {
+   np = omap_get_timer_dt(omap_counter_match, NULL);
+   if (!np)
+   return -ENODEV;
+
+   of_property_read_string_index(np, ti,hwmods, 0, oh_name);
+   if (!oh_name)
+   return -ENODEV;
+   }
+
+   /*
 * First check hwmod data is available for sync32k counter
 */
oh = omap_hwmod_lookup(oh_name);
@@ -391,7 +411,13 @@ static int __init omap2_sync32k_clocksource_init(void)
 
omap_hwmod_setup_one(oh_name);
 
-   vbase = omap_hwmod_get_mpu_rt_va(oh);
+   if (of_have_populated_dt()) {
+   vbase = of_iomap(np, 0);
+   of_node_put(np);
+   } else {
+   vbase = omap_hwmod_get_mpu_rt_va(oh);
+   }
+
if (!vbase) {
pr_warn(%s: failed to get counter_32k resource\n, __func__);
return -ENXIO;
-- 
1.7.9.5

--
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] ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driver

From: Vaibhav Hiremath hvaib...@ti.com

Add dmtimer clock aliases for AM33XX devices so that the parent clock for
the dmtimer can be set correctly by the dmtimer driver. Without these clock
aliases the dmtimer driver will fail to find the parent clocks for the dmtimer.

Verified that DMTIMERs can be successfully requested on AM335x beagle bone.

Original patch was provided by Vaibhav Hiremath [1]. Changelog and
additional verification performed by Jon Hunter.

[1] http://marc.info/?l=linux-omapm=134693631608018w=2

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Tested-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/clock33xx_data.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/clock33xx_data.c 
b/arch/arm/mach-omap2/clock33xx_data.c
index 114ab4b..1a45d6b 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -1073,6 +1073,8 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL,   gfx_fck_div_ck,   gfx_fck_div_ck,
CK_AM33XX),
CLK(NULL,   sysclkout_pre_ck, sysclkout_pre_ck,  
CK_AM33XX),
CLK(NULL,   clkout2_ck,   clkout2_ck,CK_AM33XX),
+   CLK(NULL,   timer_32k_ck, clkdiv32k_ick, CK_AM33XX),
+   CLK(NULL,   timer_sys_ck, sys_clkin_ck,  CK_AM33XX),
 };
 
 int __init am33xx_clk_init(void)
-- 
1.7.9.5

--
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] Nokia N9/N900/N950 -- mention product names

2012-10-17 Thread Aaro Koskinen

Hi,

Some minor comments:

On Wed, Oct 17, 2012 at 08:33:08PM +0200, Pavel Machek wrote:
 This adds product names (that most users know) to Kconfig and board
 comments.

Good idea. :-)

 Signed-off-by: Pavel Machek pa...@ucw.cz
 
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index 346fd26..da08226 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0
   select MACH_NOKIA_N810_WIMAX
  
  config MACH_NOKIA_RM680
 - bool Nokia RM-680/696 board
 + bool Nokia N9/N950 (RM-680/696) phones

This should be N950/N9 (RM-680/RM-696) or perhaps for clarity
N950 (RM-680) / N9 (RM-696).

   depends on ARCH_OMAP3
   default y
   select OMAP_PACKAGE_CBB
   select MACH_NOKIA_RM696
  
  config MACH_NOKIA_RX51
 - bool Nokia RX-51 board
 + bool Nokia N900 phone (RX-51)
   depends on ARCH_OMAP3
   default y
   select OMAP_PACKAGE_CBB
 diff --git a/arch/arm/mach-omap2/board-rm680.c 
 b/arch/arm/mach-omap2/board-rm680.c
 index 0ad1bb3b..26965f3 100644
 --- a/arch/arm/mach-omap2/board-rm680.c
 +++ b/arch/arm/mach-omap2/board-rm680.c
 @@ -1,5 +1,5 @@
  /*
 - * Board support file for Nokia RM-680/696.
 + * Board support file for Nokia N9/N950 (aka RM-680/696).

Same here.

Thanks,

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

IS_ERR_OR_NULL - please STOP telling people to use this on a whim

2012-10-17 Thread Russell King - ARM Linux

People,

This is not aimed at anyone specifically - but it is aimed at everyone
who reviews patches to make them aware of this issue, and to modify their
behaviour.

I'm geting sick and tired of telling people about this.  I've just
floated the idea of removing IS_ERR_OR_NULL from the kernel tree because
it's one of the most incorrectly used and abused macros we have in the
source tree.

It would be one thing if this was only being done by people who are
submitting new code, but it's far worse than that.  Reviewers who should
know better are telling people to use it _incorrectly_.

Reviewers really need to think about your review comments.  Looking
through the kernel tree today, I see lots of uses of IS_ERR_OR_NULL(),
many of them are *buggy*.

Take a moment to think about this:

int error_value(struct device *dev, void *foo)
{
if (IS_ERR_OR_NULL(foo))
return PTR_ERR(foo);
return 0;
}

Consider the value this function returns for three arguments:

1. an errno encoded pointer
2. a NULL pointer.
3. a valid pointer.

If you can't see the problem, then *do* *not* tell anyone to use
IS_ERR_OR_NULL(), because you do *not* have the understanding necessary
to make that judgement yourself - you're probably telling people to
create buggy code.

Here's the list so far of what looks like buggy uses specific to ARM.
There _are_ others elsewhere in the kernel.

drivers/media/video/s5p-mfc/s5p_mfc.c:  if (IS_ERR_OR_NULL(dev-alloc_ctx[0])) {
drivers/media/video/s5p-mfc/s5p_mfc.c-  ret = 
PTR_ERR(dev-alloc_ctx[0]);
drivers/media/video/s5p-mfc/s5p_mfc.c-  goto err_res;
drivers/media/video/s5p-mfc/s5p_mfc.c-  }
--
drivers/media/video/s5p-mfc/s5p_mfc.c:  if (IS_ERR_OR_NULL(dev-alloc_ctx[1])) {
drivers/media/video/s5p-mfc/s5p_mfc.c-  ret = 
PTR_ERR(dev-alloc_ctx[1]);
drivers/media/video/s5p-mfc/s5p_mfc.c-  goto err_mem_init_ctx_1;
drivers/media/video/s5p-mfc/s5p_mfc.c-  }
--
drivers/staging/omapdrm/omap_dmm_tiler.c:   if (IS_ERR_OR_NULL(txn))
drivers/staging/omapdrm/omap_dmm_tiler.c-   return PTR_ERR(txn);
drivers/staging/omapdrm/omap_dmm_tiler.c-
drivers/staging/omapdrm/omap_dmm_tiler.c-   tcm_for_each_slice(slice, 
*area, area_s) {
--
drivers/staging/omap-thermal/omap-bandgap.c:if (IS_ERR_OR_NULL(bg_ptr)) {
drivers/staging/omap-thermal/omap-bandgap.c-dev_err(pdev-dev, 
failed to fetch platform data\n);
drivers/staging/omap-thermal/omap-bandgap.c-return PTR_ERR(bg_ptr);
drivers/staging/omap-thermal/omap-bandgap.c-}
--
drivers/staging/omap-thermal/omap-thermal-common.c: if 
(IS_ERR_OR_NULL(data-omap_thermal)) {
drivers/staging/omap-thermal/omap-thermal-common.c- 
dev_err(bg_ptr-dev, thermal zone device is NULL\n);
drivers/staging/omap-thermal/omap-thermal-common.c- return 
PTR_ERR(data-omap_thermal);
drivers/staging/omap-thermal/omap-thermal-common.c- }
--
drivers/staging/omap-thermal/omap-thermal-common.c: if 
(IS_ERR_OR_NULL(freq_table)) {
drivers/staging/omap-thermal/omap-thermal-common.c- 
dev_err(bg_ptr-dev,
drivers/staging/omap-thermal/omap-thermal-common.c- %s: 
failed to get cpufreq table (%p)\n,
drivers/staging/omap-thermal/omap-thermal-common.c- 
__func__, freq_table);
--
drivers/staging/omap-thermal/omap-thermal-common.c: if 
(IS_ERR_OR_NULL(data-cool_dev)) {
drivers/staging/omap-thermal/omap-thermal-common.c- 
dev_err(bg_ptr-dev,
drivers/staging/omap-thermal/omap-thermal-common.c- Failed 
to register cpufreq cooling device\n);
drivers/staging/omap-thermal/omap-thermal-common.c- return 
PTR_ERR(data-cool_dev);
--
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c: if (IS_ERR_OR_NULL(sgt)) {
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- ret = PTR_ERR(sgt);
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- goto err_buf_detach;
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- }
--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c:  if (IS_ERR_OR_NULL(helper-fb)) 
{
drivers/gpu/drm/exynos/exynos_drm_fbdev.c-  DRM_ERROR(failed to 
create drm framebuffer.\n);
drivers/gpu/drm/exynos/exynos_drm_fbdev.c-  ret = 
PTR_ERR(helper-fb);
drivers/gpu/drm/exynos/exynos_drm_fbdev.c-  goto out;
--
--
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 v2 0/2] ASoC: omap-mcpdm updates for 3.7

Hi Mark,

* Peter Ujfalusi peter.ujfal...@ti.com [121004 01:27]:
 Hello Mark, Tony,
 
 Change since v1:
 - Fixed the second patch to keep the omap_mcpdm_open_stream() - after a coffee
 
 The mcpdm driver no longer needs to include any plat/*.h file, clearing the 
 way
 for the single kernel image.
 
 Regards,
 Peter
 ---
 Peter Ujfalusi (1):
   ASoC: omap-mcpdm: Remove OMAP revision check
 
 Tony Lindgren (1):
   ASoC: Fix wrong include for McPDM
 
  sound/soc/omap/omap-mcpdm.c | 9 ++---
  1 file changed, 2 insertions(+), 7 deletions(-)

Is it OK for me to merge in your ASoC for-3.7 branch at commit
68214d99 (ASoC: omap-mcpdm: Remove OMAP revision check) also
into my omap cleanup branch for v3.8?

I need that to avoid compile errors with some of my test configs.

Regards,

Tony
--
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] ARM: OMAP2+: Only write the sysconfig on idle when necessary

Currently, whenever we idle a device _idle_sysc() is called and writes to the
devices SYSCONFIG register to set the idle mode. A lot devices are using the
smart-idle mode and so the write to the SYSCONFIG register is programming the
same value that is already stored in the register.

Writes to the devices SYSCONFIG register can be slow, for example, writing to
the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional
clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can
take ~100us.

Furthermore, during boot on an OMAP4430 panda board, I see that there are 100
calls to _idle_sysc(), however, only 3 out of the 100 calls actually write
the SYSCONFIG register with a new value.

Therefore, to avoid unnecessary writes to device SYSCONFIG registers when
idling the device, only write the value if the value has changed. It should be
safe to do this on idle as the context of the register will never be lost while
the device is active.

Verified that suspend, CORE off and retention states are working with this
change on OMAP3430 Beagle board.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod.c |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..962773b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1389,6 +1389,10 @@ static void _idle_sysc(struct omap_hwmod *oh)
if ((sf  SYSC_HAS_SIDLEMODE)  !(oh-flags  HWMOD_SWSUP_SIDLE))
_enable_wakeup(oh, v);
 
+   /* If the cached value is the same as the new value, skip the write */
+   if (oh-_sysc_cache == v)
+   return;
+
_write_sysconfig(v, oh);
 }
 
-- 
1.7.9.5

--
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+: Only write the sysconfig on idle when necessary

cc Rajendra

Hi Jon

On Wed, 17 Oct 2012, Jon Hunter wrote:

 Currently, whenever we idle a device _idle_sysc() is called and writes to the
 devices SYSCONFIG register to set the idle mode. A lot devices are using the
 smart-idle mode and so the write to the SYSCONFIG register is programming the
 same value that is already stored in the register.
 
 Writes to the devices SYSCONFIG register can be slow, for example, writing to
 the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional
 clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can
 take ~100us.
 
 Furthermore, during boot on an OMAP4430 panda board, I see that there are 100
 calls to _idle_sysc(), however, only 3 out of the 100 calls actually write
 the SYSCONFIG register with a new value.
 
 Therefore, to avoid unnecessary writes to device SYSCONFIG registers when
 idling the device, only write the value if the value has changed. It should be
 safe to do this on idle as the context of the register will never be lost 
 while
 the device is active.
 
 Verified that suspend, CORE off and retention states are working with this
 change on OMAP3430 Beagle board.

The code used to do what you propose in _write_sysconfig(), which applied 
to all sysconfig writes, not just idle.  But it was changed by commit 
233cbe5b94096f95ba7bca2162d63275b0b90b5b (OMAP2+: hwmod: Update the 
sysc_cache in case module context is lost).  Could you take a look at 
this and maybe discuss it with Rajendra?  It seems to make more sense to 
me to cache it by default, and only invalidate it when we know that 
context is lost.


- Paul
--
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 v2] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h

* Felipe Balbi ba...@ti.com [121017 08:54]:
 In order to make single zImage work for ARM architecture,
 we need to make sure we don't depend on private headers.
 
 Move USB platform_data to linux/platform_data/omap-usb.h
 and keep only internal functions in plat/usb.h.

Thanks, looks like I can't make this apply against v3.7-rc1:

patching file arch/arm/plat-omap/include/plat/usb.h
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 26.
Hunk #3 FAILED at 44.
Hunk #4 FAILED at 65.
Hunk #5 FAILED at 81.
Hunk #6 succeeded at 28 with fuzz 2 (offset -128 lines).
5 out of 6 hunks FAILED -- rejects in file arch/arm/plat-omap/include/plat/usb.h

Can you please check it?

Regards,

Tony
--
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+: Only write the sysconfig on idle when necessary


On 10/17/2012 03:25 PM, Paul Walmsley wrote:
 cc Rajendra
 
 Hi Jon
 
 On Wed, 17 Oct 2012, Jon Hunter wrote:
 
 Currently, whenever we idle a device _idle_sysc() is called and writes to the
 devices SYSCONFIG register to set the idle mode. A lot devices are using the
 smart-idle mode and so the write to the SYSCONFIG register is programming the
 same value that is already stored in the register.

 Writes to the devices SYSCONFIG register can be slow, for example, writing to
 the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 
 functional
 clock cycles. If the DMTIMER is using the slow 32kHz functional clock this 
 can
 take ~100us.

 Furthermore, during boot on an OMAP4430 panda board, I see that there are 100
 calls to _idle_sysc(), however, only 3 out of the 100 calls actually write
 the SYSCONFIG register with a new value.

 Therefore, to avoid unnecessary writes to device SYSCONFIG registers when
 idling the device, only write the value if the value has changed. It should 
 be
 safe to do this on idle as the context of the register will never be lost 
 while
 the device is active.

 Verified that suspend, CORE off and retention states are working with this
 change on OMAP3430 Beagle board.
 
 The code used to do what you propose in _write_sysconfig(), which applied 
 to all sysconfig writes, not just idle.  But it was changed by commit 
 233cbe5b94096f95ba7bca2162d63275b0b90b5b (OMAP2+: hwmod: Update the 
 sysc_cache in case module context is lost). Could you take a look at
 this and maybe discuss it with Rajendra?  It seems to make more sense to 
 me to cache it by default, and only invalidate it when we know that 
 context is lost.

Ok, thanks. Yes, only updating the register when the cache value changed
would not work due to the possibility of context being lost. So
Rajendra's change makes sense. However, I think there is room to
optimise this.

With this change, on idle, the cache value and register value are only
updated when needed. This should be safe.

Are you looking to go one step further and only update the sysconfig on
enabling when the context has been lost? That would require more
changes. This was a quick optimisation I saw when reviewing the code.

Rajendra, let me know if you have any comments.

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: IS_ERR_OR_NULL - please STOP telling people to use this on a whim

2012-10-17 Thread Phil Carmody

On 17/10/12 20:41 +0100, Russell King - ARM Linux wrote:
 People,
 
 This is not aimed at anyone specifically - but it is aimed at everyone
 who reviews patches to make them aware of this issue, and to modify their
 behaviour.
 
 I'm geting sick and tired of telling people about this.  I've just
 floated the idea of removing IS_ERR_OR_NULL from the kernel tree because
 it's one of the most incorrectly used and abused macros we have in the
 source tree.

This makes me sad. I was responsible for its introduction, and my motive
was exactly yours in sending the above. 

 It would be one thing if this was only being done by people who are
 submitting new code, but it's far worse than that.  Reviewers who should
 know better are telling people to use it _incorrectly_.
 
 Reviewers really need to think about your review comments.  Looking
 through the kernel tree today, I see lots of uses of IS_ERR_OR_NULL(),
 many of them are *buggy*.
 
 Take a moment to think about this:
 
 int error_value(struct device *dev, void *foo)
 {
   if (IS_ERR_OR_NULL(foo))
   return PTR_ERR(foo);
   return 0;
 }
 
 Consider the value this function returns for three arguments:
 
 1. an errno encoded pointer
 2. a NULL pointer.
 3. a valid pointer.
 
 If you can't see the problem, then *do* *not* tell anyone to use
 IS_ERR_OR_NULL(), because you do *not* have the understanding necessary
 to make that judgement yourself - you're probably telling people to
 create buggy code.

The problem I saw was functions returning -ERRORs or NULL. There were
too many, and there was too much sloppy code inconsistently handling one
or either of the two, and not always both. I did consider trying to fix
some of the core functions that were returning -ERRORs or NULL to the
drivers I was involved in, but it seemed like there were too many, and
that would be too brave. I imagined that my macro would help catch
that undesirable situation, and permit people to map the error onto
whatever was most appropriate to propagate on.

The idea of them propagating the undesirable problem up further in the call
chain is the exact antithesis of what I intended.

Thank you for highlighting the issue I didn't foresee (neither did my 
colleagues at Nokia, they made good use of it fairly quickly) and in 
such unambiguous terms. Better to nip it in the bud, certainly.

 Here's the list so far of what looks like buggy uses specific to ARM.
 There _are_ others elsewhere in the kernel.
 
 drivers/media/video/s5p-mfc/s5p_mfc.c:  if 
 (IS_ERR_OR_NULL(dev-alloc_ctx[0])) {
 drivers/media/video/s5p-mfc/s5p_mfc.c-  ret = 
 PTR_ERR(dev-alloc_ctx[0]);
 drivers/media/video/s5p-mfc/s5p_mfc.c-  goto err_res;
 drivers/media/video/s5p-mfc/s5p_mfc.c-  }
...

:-(

So, what to do? It can and has been used sensibly, so I don't think removing
it is the best option.

Phil

pcarm...@nokia.com is no more, I'm now pc+l...@asdf.org
--
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+: Only write the sysconfig on idle when necessary

On Wed, 17 Oct 2012, Jon Hunter wrote:

 Are you looking to go one step further and only update the sysconfig on
 enabling when the context has been lost? That would require more
 changes.

Yes that's exactly it.  That would avoid adding a special case for what 
should be the common case.  From a quick glance it looks like the cache 
needs to be loaded in _reset(), omap_hwmod_softreset(), and _enable().  
Other than that, seems like the cached value should work.

It should also be possible to avoid the reload in _enable() in most cases 
since the PM code should know whether the IP block's powerdomain was 
programmed to go off and indeed whether it did so.  It shouldn't involve 
any extra register reads.  But I wouldn't expect you to add that 
optimization; would just be nice to have a comment to that effect.

If the meta-theme of your message is that commit 
233cbe5b94096f95ba7bca2162d63275b0b90b5b should have had closer scrutiny, 
I agree with you, but we're beyond that point now...


- Paul
--
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] Nokia N9/N900/N950 -- mention product names

2012-10-17 Thread Pavel Machek


This adds product names (that most users know) to Kconfig and board
comments.
 
Signed-off-by: Pavel Machek pa...@ucw.cz

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 346fd26..f03f19a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0
select MACH_NOKIA_N810_WIMAX
 
 config MACH_NOKIA_RM680
-   bool Nokia RM-680/696 board
+   bool Nokia N950 (RM-680) / N9 (RM-696) phones
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
select MACH_NOKIA_RM696
 
 config MACH_NOKIA_RX51
-   bool Nokia RX-51 board
+   bool Nokia N900 (RX-51) phone
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
diff --git a/arch/arm/mach-omap2/board-rm680.c 
b/arch/arm/mach-omap2/board-rm680.c
index 0ad1bb3b..96f8757 100644
--- a/arch/arm/mach-omap2/board-rm680.c
+++ b/arch/arm/mach-omap2/board-rm680.c
@@ -1,5 +1,5 @@
 /*
- * Board support file for Nokia RM-680/696.
+ * Board support file for Nokia N950 (RM-680) / N9 (RM-696).
  *
  * Copyright (C) 2010 Nokia
  *
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 345dd93..b60ca9d 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -1,5 +1,5 @@
 /*
- * linux/arch/arm/mach-omap2/board-rx51.c
+ * Board support file for Nokia N900 (aka RX-51).
  *
  * Copyright (C) 2007, 2008 Nokia
  *

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: discrepancy while save and restore of debounce registers

Hi Gururaja,

On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
 Hi,
 
 I came across a peculiar issue while updating GPIO debounce registers on
 OMAP platform.
 
 According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
 
 gpio/omap: save and restore debounce registers
 
 GPIO debounce registers need to be saved and restored for proper functioning
 of driver.
 
 ...
 @@ -1363,6 +1369,12 @@ static void omap_gpio_restore_context(struct gpio_bank 
 *bank)
 __raw_writel(bank-context.fallingdetect,
 bank-base + bank-regs-fallingdetect);
 __raw_writel(bank-context.dataout, bank-base + bank-regs-dataout);
 +   if (bank-dbck_enable_mask) {
 +   __raw_writel(bank-context.debounce, bank-base +
 +   bank-regs-debounce);
 +   __raw_writel(bank-context.debounce_en,
 +   bank-base + bank-regs-debounce_en);
 +   }
  }
 
 
 Due to copy/paste of this commit into my local tree, I missed the check for 
 bank-dbck_enable_mask, and directly restored the saved value from context.
 
 After this, I saw random crashes when accessing different registers (sometimes
 its OE register and sometime its DATAOUT register). 
 
 These crashes were seen across 2nd and subsequent suspend/resume.
 
 My doubt/questions are
 1. Why should debounce registers be updated only when it's accessed 
 previously?

If debounce is not being used by any of the gpios, then there is no need
to restore them as there are no bits set. So this makes sense and saves
a couple register writes.

 2. What is the relation between updating debounce registers and crash seen on
 others registers? 

This I am not sure about. I gave this a quick try on my omap3430 beagle
board, but I did not see any side-effects from doing this. However, if
you are always restoring the debounce context regardless of whether
debounce is being used, then you could be writing bad values to the
debounce registers as the context variables bank-context.debouce and
bank-context.debouce_en may not initialised. So that is bad. However,
that said I am still not sure how this could cause a crash.

Can you share more details on ...
1. The OMAP platform you are using?
2. What linux distro/environment you are using?
3. If there are any specific steps to reproduce this 100% of the time?

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] Nokia N9/N900/N950 -- mention product names

2012-10-17 Thread Aaro Koskinen

On Wed, Oct 17, 2012 at 11:03:00PM +0200, Pavel Machek wrote:
 
 This adds product names (that most users know) to Kconfig and board
 comments.
  
 Signed-off-by: Pavel Machek pa...@ucw.cz

Reviewed-by: Aaro Koskinen aaro.koski...@iki.fi

A.

 
 diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
 index 346fd26..f03f19a 100644
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0
   select MACH_NOKIA_N810_WIMAX
  
  config MACH_NOKIA_RM680
 - bool Nokia RM-680/696 board
 + bool Nokia N950 (RM-680) / N9 (RM-696) phones
   depends on ARCH_OMAP3
   default y
   select OMAP_PACKAGE_CBB
   select MACH_NOKIA_RM696
  
  config MACH_NOKIA_RX51
 - bool Nokia RX-51 board
 + bool Nokia N900 (RX-51) phone
   depends on ARCH_OMAP3
   default y
   select OMAP_PACKAGE_CBB
 diff --git a/arch/arm/mach-omap2/board-rm680.c 
 b/arch/arm/mach-omap2/board-rm680.c
 index 0ad1bb3b..96f8757 100644
 --- a/arch/arm/mach-omap2/board-rm680.c
 +++ b/arch/arm/mach-omap2/board-rm680.c
 @@ -1,5 +1,5 @@
  /*
 - * Board support file for Nokia RM-680/696.
 + * Board support file for Nokia N950 (RM-680) / N9 (RM-696).
   *
   * Copyright (C) 2010 Nokia
   *
 diff --git a/arch/arm/mach-omap2/board-rx51.c 
 b/arch/arm/mach-omap2/board-rx51.c
 index 345dd93..b60ca9d 100644
 --- a/arch/arm/mach-omap2/board-rx51.c
 +++ b/arch/arm/mach-omap2/board-rx51.c
 @@ -1,5 +1,5 @@
  /*
 - * linux/arch/arm/mach-omap2/board-rx51.c
 + * Board support file for Nokia N900 (aka RX-51).
   *
   * Copyright (C) 2007, 2008 Nokia
   *
 
 -- 
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-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+: Only write the sysconfig on idle when necessary


On 10/17/2012 03:58 PM, Paul Walmsley wrote:
 On Wed, 17 Oct 2012, Jon Hunter wrote:
 
 Are you looking to go one step further and only update the sysconfig on
 enabling when the context has been lost? That would require more
 changes.
 
 Yes that's exactly it.  That would avoid adding a special case for what 
 should be the common case.  From a quick glance it looks like the cache 
 needs to be loaded in _reset(), omap_hwmod_softreset(), and _enable().  
 Other than that, seems like the cached value should work.
 
 It should also be possible to avoid the reload in _enable() in most cases 
 since the PM code should know whether the IP block's powerdomain was 
 programmed to go off and indeed whether it did so.  It shouldn't involve 
 any extra register reads.  But I wouldn't expect you to add that 
 optimization; would just be nice to have a comment to that effect.

Ah, so you really want the cache to behave like a cache. That would be nice!

 If the meta-theme of your message is that commit 
 233cbe5b94096f95ba7bca2162d63275b0b90b5b should have had closer scrutiny, 
 I agree with you, but we're beyond that point now...

No under-lying theme here, just more of a I stumbled across this while
debugging something else and I am a nut-case about saving cpu cycles
where I can. Although not always possible and I am probably responsible
for burning more cycles than I am saving these days!

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: IS_ERR_OR_NULL - please STOP telling people to use this on a whim

2012-10-17 Thread Russell King - ARM Linux

On Wed, Oct 17, 2012 at 11:28:48PM +0300, Phil Carmody wrote:
 So, what to do? It can and has been used sensibly, so I don't think removing
 it is the best option.

Well, the first thing that needs to be done is a full review of every user
and fixes applied.

The second thing is that we need eyes on code _and_ review comments, and
educate those who are telling people to use IS_ERR_OR_NULL() whenever they
see an IS_ERR() to think about the code a little more - that's kind of the
purpose of my email.

Unfortunately, it's going to take time to achieve a change, and if I end
up being the only one who's spotting these errors, I'm going to get
incredibly pissed off at doing so (because it will feel like I'm being
ignored when there's a constant stream of it.)

Another thing would be to work out whether we can get checkpatch to
detect usage of IS_ERR_OR_NULL(p) followed by PTR_ERR(p) without any
explicit NULL checks against p in the same block.  That's probably
going to be interesting to code up in perl.
--
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: Updated status of the removal of plat headers

Hi Tony,

On 10/16/2012 06:00 PM, Tony Lindgren wrote:
 Hi all,
 
 Here's a quick status update on the removal of remaining
 #include plat/*.h files. Most files are now fixed up, and
 we only have the following remaining:
 
 cpu.h wrapper only left, will be removed as soon as drivers are fixed
 
 dmtimer.h Jon is fixing this

I have patches ready for this. However, as you know I have a few timer
series cooking at the moment and just sent out the latest timer DT
series today [1][2].

I have also updated my timer fixes series [3] too, however, I was not
going to send out until the DT stuff is sorted. At the moment I have
included the dmtimer header patches with the fixes series as there are
some dependencies but this series has now grown into a 20+ patch series.
So if it is easier to manage, I could split this into a fixes series and
a clean-up series. Or if you only want the header stuff now, I could
send this and send the fixes and clean-up later.

Cheers
Jon

[1] http://marc.info/?l=linux-omapm=135049690119218w=2
[2] http://marc.info/?l=linux-omapm=135049882020029w=2
[3] http://marc.info/?l=linux-arm-kernelm=134687192121865w=2
--
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: Updated status of the removal of plat headers

* Jon Hunter jon-hun...@ti.com [121017 14:53]:
 Hi Tony,
 
 On 10/16/2012 06:00 PM, Tony Lindgren wrote:
  Hi all,
  
  Here's a quick status update on the removal of remaining
  #include plat/*.h files. Most files are now fixed up, and
  we only have the following remaining:
  
  cpu.h   wrapper only left, will be removed as soon as drivers 
  are fixed
  
  dmtimer.h   Jon is fixing this
 
 I have patches ready for this. However, as you know I have a few timer
 series cooking at the moment and just sent out the latest timer DT
 series today [1][2].
 
 I have also updated my timer fixes series [3] too, however, I was not
 going to send out until the DT stuff is sorted. At the moment I have
 included the dmtimer header patches with the fixes series as there are
 some dependencies but this series has now grown into a 20+ patch series.
 So if it is easier to manage, I could split this into a fixes series and
 a clean-up series. Or if you only want the header stuff now, I could
 send this and send the fixes and clean-up later.

When they are ready, two separate pull requests against v3.7-rc1 for fixes
and cleanup would be perfect.

Thanks,

Tony
 
 [1] http://marc.info/?l=linux-omapm=135049690119218w=2
 [2] http://marc.info/?l=linux-omapm=135049882020029w=2
 [3] http://marc.info/?l=linux-arm-kernelm=134687192121865w=2
--
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] omap fixes ready to go for v3.7-rc1

Hi Arnd  Olof,

Here are the fixes ready to pull, there's at least one more fix in works
but it still requires minor changes. The two top commits are recent as
Jon Hunter noticed an issue freeing resources in his fix and I did a
new branch to swap in the fixed patch.

Regards,

Tony


The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.7-rc1/fixes-take5-signed

for you to fetch changes up to 8119024ef7363591fd958ec89ebfaee7c18209e3:

  ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory 
(2012-10-17 09:01:14 -0700)


A boot problem fix for am33xx beaglebone caused by GPMC,
a regression fix for local timer, and a clockdomain locking fix.
Also few minor fixes for boot time and sparse warnings.


Benoit Cousson (1):
  ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck

Jon Hunter (1):
  ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory

Paul Walmsley (1):
  ARM: OMAP: resolve sparse warning concerning debug_card_init()

Sebastien Guiriec (1):
  ARM: OMAP4: devices: fixup OMAP4 DMIC platform device error message

Tero Kristo (1):
  ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable

Tony Lindgren (1):
  ARM: OMAP4: Fix twd_local_timer_register regression

 arch/arm/mach-omap2/clock44xx_data.c |2 +-
 arch/arm/mach-omap2/clockdomain.c|   15 +++
 arch/arm/mach-omap2/devices.c|2 +-
 arch/arm/mach-omap2/gpmc.c   |   24 +++-
 arch/arm/mach-omap2/timer.c  |2 +-
 arch/arm/plat-omap/debug-devices.c   |1 +
 6 files changed, 34 insertions(+), 12 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: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support)

2012-10-17 Thread Kevin Hilman

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

 On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote:
 
 On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote:
  + peterz, tglx
  
  Felipe Balbi ba...@ti.com writes:
  
  [...]
  
   The problem I see is that even though we properly return IRQ_WAKE_THREAD
   and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
   the thread is never scheduled. To make things even worse, ouw irq thread
   runs once, but doesn't run on a consecutive call. Here's some (rather
   nasty) debug prints showing the problem:
  
  [...]
  
   [   88.721923] try_to_wake_up 1411
   [   88.725189] === irq_wake_thread 139: IRQ 72 wake_up_process 0
   [   88.731292] [sched_delayed] sched: RT throttling activated
  
  This throttling message is the key one.
  
  With RT throttling activated, the IRQ thread will not be run (it
  eventually will be allowed much later on, but by then, the I2C xfers
  have timed out.)
  
  As a quick hack, the throttling can be disabled by seeting the
  sched_rt_runtime to RUNTIME_INF:
  
  # sysctl -w kernel.sched_rt_runtime_us=-1
  
  and a quick test shows that things go back to working as expected.  But
  we still need to figure out why the throttling is hapenning...
  
  So I started digging into why the RT runtime was so high, and noticed
  that time spent in suspend was being counted as RT runtime!
  
  So spending time in suspend anywhere near sched_rt_runtime (0.95s) will
  cause the RT throttling to always be triggered, and thus prevent IRQ
  threads from running in the resume path.  Ouch.
  
  I think I'm already in over my head in the RT runtime stuff, but
  counting the time spent in suspend as RT runtime smells like a bug to
  me. no?
  
  Peter? Thomas?
 
 it looks like removing console output completely (echo 0 
 /proc/sysrq-trigger) I don't see the issue anymore. Let me just run for
 a few more iterations to make sure what I'm saying is correct.

 Yeah, really looks like removing console output makes the problem go
 away. Ran a few iterations and it always worked fine. Full logs attached

Removing console output during resume is going to significantly change
the timing of what is happening during suspend/resume, so I suspect that
combined with all your other debug prints is somehow masking the
problem.  How log are you letting the system stay in suspend?

That being said, I can still easily reproduce the problem, even with
console output disabled.

With vanilla v3.7-rc1 + the debug patch below[1], with and without
console output, I see RT throttling kicking in on resume, and the RT
runtime on resume corresponds to the time spent in suspend.  Here's an
example of debug output of my patch below after ~3 sec in suspend:

[   43.198028] sched_rt_runtime_exceeded: rt_time 2671752930  runtime 95000
[   43.198028] update_curr_rt: RT runtime exceeded: irq/72-omap_i2c
[   43.198059] update_curr_rt: RT runtime exceeded: irq/72-omap_i2c
[   43.203704] [sched_delayed] sched: RT throttling activated

I see this rather consistently, and the rt_time value is always roughly the
time I spent in suspend.

So the primary question remains: is RT runtime supposed to include the
time spent suspended?  I suspect not. 

Kevin

[1]
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 418feb0..39de750 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -891,6 +891,8 @@ static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq)
if (!once) {
once = true;
printk_sched(sched: RT throttling 
activated\n);
+   pr_warn(%s: rt_time %llu  runtime %llu\n,
+   __func__, rt_rq-rt_time, runtime);
}
} else {
/*
@@ -948,8 +950,11 @@ static void update_curr_rt(struct rq *rq)
if (sched_rt_runtime(rt_rq) != RUNTIME_INF) {
raw_spin_lock(rt_rq-rt_runtime_lock);
rt_rq-rt_time += delta_exec;
-   if (sched_rt_runtime_exceeded(rt_rq))
+   if (sched_rt_runtime_exceeded(rt_rq)) {
+   pr_warn(%s: RT runtime exceeded: %s\n,
+   __func__, curr-comm);
resched_task(curr);
+   }
raw_spin_unlock(rt_rq-rt_runtime_lock);
}
}
--
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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

Hi Richard

On Wed, 17 Oct 2012, Richard Cochran wrote:

 Would you please take this bugfix for 3.7-rc2? The suggestion to mail
 you came from Toni Lindgren. The context where it came from is here:
 
 http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html

This patch appears to add a new feature, correct?  I don't think the CPSW 
could have worked in the past without this data present.  So it looks to 
me like this is 3.8 material, unless Tony would like it to go in sooner?


- Paul

 
 Thanks,
 Richard
 
 - Forwarded message from Richard Cochran richardcoch...@gmail.com -
 
 Date: Mon, 15 Oct 2012 21:16:32 +0200
 From: Richard Cochran richardcoch...@gmail.com
 To: net...@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org, Arnd Bergmann a...@arndb.de,
   David Miller da...@davemloft.net,
   Russell King li...@arm.linux.org.uk,
   Mugunthan V N mugunthan...@ti.com
 Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for 
 davinci_mdio
 X-Mailer: git-send-email 1.7.2.5
 
 From: Mugunthan V N mugunthan...@ti.com
 
 This patch adds minimal hwmod support for davinci mdio driver. This patch
 requires rework on parent child relation between cpsw and davinci mdio
 hwmod data to support runtime PM.
 
 Signed-off-by: Mugunthan V N mugunthan...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |   34 ++-
  1 files changed, 32 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
 index 59d5c1c..f96bbc0 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
 @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig 
 am33xx_cpgmac_sysc = {
   .rev_offs   = 0x0,
   .sysc_offs  = 0x8,
   .syss_offs  = 0x4,
 - .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
 -SYSS_HAS_RESET_STATUS),
 + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
  MSTANDBY_NO),
   .sysc_fields= omap_hwmod_sysc_type3,
 @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
   .modulemode = MODULEMODE_SWCTRL,
   },
   },
 + .flags  = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
 +HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
  };
  
  /*
 @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space 
 am33xx_elm_addr_space[] = {
   { }
  };
  
 +/* mdio class */
 +static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
 + .name   = davinci_mdio,
 +};
 +
 +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
 + {
 + .pa_start   = 0x4A101000,
 + .pa_end = 0x4A101000 + SZ_256 - 1,
 + .flags  = ADDR_MAP_ON_INIT,
 + },
 + { }
 +};
 +
 +static struct omap_hwmod am33xx_mdio_hwmod = {
 + .name   = davinci_mdio,
 + .class  = am33xx_mdio_hwmod_class,
 + .clkdm_name = cpsw_125mhz_clkdm,
 + .main_clk   = cpsw_125mhz_gclk,
 +};
 +
 +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
 + .master = am33xx_cpgmac0_hwmod,
 + .slave  = am33xx_mdio_hwmod,
 + .addr   = am33xx_mdio_addr_space,
 + .user   = OCP_USER_MPU,
 +};
 +
  static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
   .master = am33xx_l4_ls_hwmod,
   .slave  = am33xx_elm_hwmod,
 @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] 
 __initdata = {
   am33xx_l3_main__tptc2,
   am33xx_l3_s__usbss,
   am33xx_l4_hs__cpgmac0,
 + am33xx_cpgmac0__mdio,
   NULL,
  };
  
 -- 
 1.7.2.5
 
 
 - End forwarded message -
 


- Paul
--
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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

* Paul Walmsley p...@pwsan.com [121017 16:39]:
 Hi Richard
 
 On Wed, 17 Oct 2012, Richard Cochran wrote:
 
  Would you please take this bugfix for 3.7-rc2? The suggestion to mail
  you came from Toni Lindgren. The context where it came from is here:
  
  http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
 
 This patch appears to add a new feature, correct?  I don't think the CPSW 
 could have worked in the past without this data present.  So it looks to 
 me like this is 3.8 material, unless Tony would like it to go in sooner?

Yeah unless it fixes something, we should just queue it for v3.8 merge
window.

Regards,

Tony
--
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/6] ARM: OMAP3/4: iommu: adapt to runtime pm

2012-10-17 Thread Omar Ramirez Luna

On 15 October 2012 22:23, Felipe Contreras felipe.contre...@gmail.com wrote:
 On probe this patch does pm_runtime_enable, however this doesn't mean
 the device is turned ON or resumed or kept ON all the time.

 In fact it's the other way around; pm_runtime_enable turns off the
 power (if it's ON).

pm_runtime_enable just decrements the disable_depth counter. Doesn't
turn off anything by itself.

 @@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct 
 platform_device *pdev)
 release_mem_region(res-start, resource_size(res));
 iounmap(obj-regbase);

 -   clk_put(obj-clk);
 +   pm_runtime_disable(obj-dev);

 This will turn on the device unnecessarily, wasting power, and there's
 no need for that, kfree will take care of that without resuming.

 Left aside the aesthetics of having balanced calls, the device will be
 enabled if there was a pending resume to be executed, otherwise it
 won't, kfree won't increment the disable_depth counter and I don't
 think that freeing the pointer is enough reason to ignore
 pm_runtime_disable.

 You are doing __pm_runtime_disable(dev, true), kfree will do
 __pm_runtime_disable(dev, false), which is what we want. Both will
 decrement the disable_depth.

 I'm quite confused here, could you please point me to the kfree snip
 that does __pm_runtime_disable(dev, false)?

 Sorry, not kfree, but the device removal process:

 device_del
  device_pm_remove
   pm_runtime_remove
__pm_runtime_disable - HERE

I'm not entirely convinced _iommu_ follows this path, it doesn't
create any devices nor register them... whereas mailbox does create
devices and mailbox does follow this path for the devices created
which are child devices.

So this path won't take care of the omap-iommu device pm_runtime_disable.

 But at least you agree that there's a chance that the device will be waken 
 up.

 Of course, if there is a pending resume to be executed, it must honor
 that resume request and then turn off the device before removing the
 iommu, IMHO.

 Who will turn off the device afterwards?

What I meant is that omap_iommu_detach should turn off the device
before removing the iommu.

Cheers,

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 v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM

2012-10-17 Thread Omar Ramirez Luna

On 16 October 2012 12:22, Tony Lindgren t...@atomide.com wrote:
 * Omar Ramirez Luna omar.l...@linaro.org [121011 18:07]:
 These patches are needed for remoteproc to work on OMAP4.

 Introduced iommu hwmod support for OMAP3 (iva, isp) and
 OMAP4 (ipu, dsp), along with the corresponding runtime PM
 and routines to deassert reset lines, enable/disable clocks
 and configure sysc registers.

 Although IOMMU hwmod patches were already submitted in the past,
 this series adds few more changes, like:
 - New reset handling.
 - Save and restore context code rework.
 - Device tree bindings for OMAP3 and OMAP4.

 For this series I just dropped the patches already included in
 mainline.

 These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu
 when I have that pushed out as that removes plat/*iommu*.h files.

Ok, will wait and rebase on top of it.

Thanks,

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: [GIT PULL] omap fixes ready to go for v3.7-rc1

2012-10-17 Thread Olof Johansson

On Wed, Oct 17, 2012 at 3:02 PM, Tony Lindgren t...@atomide.com wrote:
 Hi Arnd  Olof,

 Here are the fixes ready to pull, there's at least one more fix in works
 but it still requires minor changes. The two top commits are recent as
 Jon Hunter noticed an issue freeing resources in his fix and I did a
 new branch to swap in the fixed patch.

 Regards,

 Tony


 The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

   Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.7-rc1/fixes-take5-signed

Pulled into fixes, thanks.


-Olof
--
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 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer (fwd)


Hi Wim,

When you have the opportunity, could you take a look at this patch, and 
the subsequent patch 6/7, and ack them if you're okay with them?

We'd like to merge thse as part of a larger cleanup series through the 
arm-soc tree.  They like cleanup patches to arrive at the beginning of the 
-rc series, which means that we need to have the pull request sent pretty 
soon.


thanks,

- Paul

-- Forwarded message --
Date: Mon, 15 Oct 2012 19:32:33 -0600
From: Paul Walmsley p...@pwsan.com
To: linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org
Cc: Wim Van Sebroeck w...@iguana.be, linux-watch...@vger.kernel.org
Subject: [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata
function pointer

The OMAP watchdog timer driver directly calls a function exported by
code in arch/arm/mach-omap2.  This is not good; it tightly couples
this driver to the mach-omap2 integration code.  Instead, add a
temporary platform_data function pointer to abstract this function
call.  A subsequent patch will convert the watchdog driver to use this
function pointer.

This patch also moves the device creation code out of
arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c.
This is another step towards the removal of
arch/arm/mach-omap2/devices.c.

Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Wim Van Sebroeck w...@iguana.be
---
 arch/arm/mach-omap1/devices.c   |   21 +--
 arch/arm/mach-omap2/devices.c   |   26 --
 arch/arm/mach-omap2/wd_timer.c  |   33 +++
 include/linux/platform_data/omap-wd-timer.h |   38 +++
 4 files changed, 89 insertions(+), 29 deletions(-)
 create mode 100644 include/linux/platform_data/omap-wd-timer.h

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index d3fec92..c3408e7 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -17,6 +17,8 @@
 #include linux/platform_device.h
 #include linux/spi/spi.h
 
+#include linux/platform_data/omap-wd-timer.h
+
 #include asm/mach/map.h
 
 #include plat/tc.h
@@ -439,18 +441,31 @@ static struct resource wdt_resources[] = {
 };
 
 static struct platform_device omap_wdt_device = {
-   .name  = omap_wdt,
-   .id  = -1,
+   .name   = omap_wdt,
+   .id = -1,
.num_resources  = ARRAY_SIZE(wdt_resources),
.resource   = wdt_resources,
 };
 
 static int __init omap_init_wdt(void)
 {
+   struct omap_wd_timer_platform_data pdata;
+   int ret;
+
if (!cpu_is_omap16xx())
return -ENODEV;
 
-   return platform_device_register(omap_wdt_device);
+   pdata.read_reset_sources = omap1_read_reset_sources;
+
+   ret = platform_device_register(omap_wdt_device);
+   if (!ret) {
+   ret = platform_device_add_data(omap_wdt_device, pdata,
+  sizeof(pdata));
+   if (ret)
+   platform_device_del(omap_wdt_device);
+   }
+
+   return ret;
 }
 subsys_initcall(omap_init_wdt);
 #endif
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..2ab2c99 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -644,29 +644,3 @@ static int __init omap2_init_devices(void)
return 0;
 }
 arch_initcall(omap2_init_devices);
-
-#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-static int __init omap_init_wdt(void)
-{
-   int id = -1;
-   struct platform_device *pdev;
-   struct omap_hwmod *oh;
-   char *oh_name = wd_timer2;
-   char *dev_name = omap_wdt;
-
-   if (!cpu_class_is_omap2() || of_have_populated_dt())
-   return 0;
-
-   oh = omap_hwmod_lookup(oh_name);
-   if (!oh) {
-   pr_err(Could not look up wd_timer%d hwmod\n, id);
-   return -EINVAL;
-   }
-
-   pdev = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0);
-   WARN(IS_ERR(pdev), Can't build omap_device for %s:%s.\n,
-   dev_name, oh-name);
-   return 0;
-}
-subsys_initcall(omap_init_wdt);
-#endif
diff --git a/arch/arm/mach-omap2/wd_timer.c b/arch/arm/mach-omap2/wd_timer.c
index b2f1c67..00ef54c 100644
--- a/arch/arm/mach-omap2/wd_timer.c
+++ b/arch/arm/mach-omap2/wd_timer.c
@@ -11,10 +11,14 @@
 #include linux/io.h
 #include linux/err.h
 
+#include linux/platform_data/omap-wd-timer.h
+
 #include plat/omap_hwmod.h
+#include plat/omap_device.h
 
 #include wd_timer.h
 #include common.h
+#include prm.h
 
 /*
  * In order to avoid any assumptions from bootloader regarding WDT
@@ -99,3 +103,32 @@ int omap2_wd_timer_reset(struct omap_hwmod *oh)
return (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT :
omap2_wd_timer_disable(oh);
 }
+
+static int __init omap_init_wdt(void)
+{
+   int id = -1;
+

Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-17 Thread Richard Cochran

On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote:
 * Paul Walmsley p...@pwsan.com [121017 16:39]:
  Hi Richard
  
  On Wed, 17 Oct 2012, Richard Cochran wrote:
  
   Would you please take this bugfix for 3.7-rc2? The suggestion to mail
   you came from Toni Lindgren. The context where it came from is here:
   
   http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
  
  This patch appears to add a new feature, correct?  I don't think the CPSW 
  could have worked in the past without this data present.  So it looks to 
  me like this is 3.8 material, unless Tony would like it to go in sooner?
 
 Yeah unless it fixes something, we should just queue it for v3.8 merge
 window.

So there has been this cpsw driver since v3.4-rc1~177^2~5

   df82859 netdev: driver: ethernet: Add TI CPSW driver

and four people signed off on it, so it must have been working at one
point. Since the device tree make-over, the driver is a derelict, and
thus the present patch is fixing a regression.

I just want the already merged driver to work with the vanilla
kernel. Is that too much to ask?

Thanks,
Richard
--
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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

On Thu, 18 Oct 2012, Richard Cochran wrote:

So there has been this cpsw driver since v3.4-rc1~177^2~5

df82859 netdev: driver: ethernet: Add TI CPSW driver

and four people signed off on it, so it must have been working at one
point.

The signoffs just mean that those people are asserting that the code is
covered under an appropriate license, or are passing it on through the
maintainer hierarchy. See

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/SubmittingPatches;h=c379a2a6949f1c1cac04fb6f185c633512f37061;hb=HEAD#l298

It doesn't necessarily mean that the driver is usable in that kernel
release.

Since the device tree make-over, the driver is a derelict, and thus the
present patch is fixing a regression.

Probably the driver was submitted before any SoC integration support was
available. Grepping for 'cpsw' under arch/ turns up only AM33xx. AM335x
didn't have device enumeration support in the mainline kernel until 3.7,
via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 (ARM: OMAP3+: hwmod:
Add AM33XX HWMOD data). So I don't see how it could have worked with
mainline.

I just want the already merged driver to work with the vanilla
kernel. Is that too much to ask?

It's a very reasonable wish and your patches are certainly appreciated.

But it seems that the CPSW has never worked in the mainline kernel. So
this particular patch is not fixing a regression. Therefore we shouldn't
send it upstream during the -rc time period. Instead we'll schedule it to
be sent a few weeks later, during the 3.8 merge window.

Either way, the patch is likely to make it into the mainline kernel.
It's just that it will probably take a few weeks longer than you might
like.

- Paul
--
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/6] ARM: OMAP3/4: iommu: adapt to runtime pm

2012-10-17 Thread Felipe Contreras

On Thu, Oct 18, 2012 at 1:51 AM, Omar Ramirez Luna omar.l...@linaro.org wrote:
 On 15 October 2012 22:23, Felipe Contreras felipe.contre...@gmail.com wrote:
 On probe this patch does pm_runtime_enable, however this doesn't mean
 the device is turned ON or resumed or kept ON all the time.

 In fact it's the other way around; pm_runtime_enable turns off the
 power (if it's ON).

 pm_runtime_enable just decrements the disable_depth counter. Doesn't
 turn off anything by itself.

pm_runtime_enable turns on power management, without it the device
remains in whatever state it booted.

 device_del
  device_pm_remove
   pm_runtime_remove
__pm_runtime_disable - HERE

 I'm not entirely convinced _iommu_ follows this path, it doesn't
 create any devices nor register them... whereas mailbox does create
 devices and mailbox does follow this path for the devices created
 which are child devices.

 So this path won't take care of the omap-iommu device pm_runtime_disable.

Are you sure? What code-path calls omap_iommu_remove then?

Anyway, it was just an observation. I've seen other code do this.

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

OMAP baseline test results for v3.7-rc1


Here are some basic OMAP test results for Linux v3.7-rc1.
Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/


Changes from previous tests
---

Kernel configs have been reorganized and updated.  AM335x Beaglebone and
OMAP4460 Pandaboard-ES boards have been added to the testbed.


Passing tests
-

Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
   4430es2panda, 5912osk, am335xbone

PM ret/off, suspend + dynamic idle: (none)


Failing tests: fixed by posted patches
--

Boot tests:

* 2430sdp: vfp_reload_hw oops during MMC initialization
  - Kernel attempts to save FP registers that don't exist; fix posted:
- http://www.spinics.net/lists/arm-kernel/msg200646.html

Other:

* 2420N800: powers down 30 seconds after boot
  - Presumably due to missing CBUS patches for watchdog control
  - http://lkml.org/lkml/2012/9/3/265



Failing tests: needing investigation


Boot tests:

* 2420n800: boot hangs during UART initialization
  - http://lkml.org/lkml/2012/9/11/454
  - Various attempts at fixes posted; etiology known; issue still unresolved

* CM-T3517: L3 in-band error with IPSS during boot
  - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
  - Longstanding issue; does not occur on the 3517EVM

* 3517EVM  CM-T3517: boot hangs with NFS root
  - Likely some Kconfig, board file, and PM issues with EMAC

* CM-T3517: boot hangs with MMC boot
  - Due to missing MMC setup in board file

PM tests:

* 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend
  - Causes MMC to become unusable since regulators are not reenabled
  - Can be worked around by reverting the I2C driver conversion to
threaded IRQs:
- http://marc.info/?l=linux-i2cm=135026587102887w=2
  - Appears to be due to an accounting problem; under discussion:
- http://marc.info/?l=linux-arm-kernelm=135042360725821w=2

* 3530es3beagle: hangs during off-mode dynamic idle test
  - Unknown cause; not investigated

* 37xx EVM: CORE not entering dynamic off-idle
  - Cause unknown; dynamic retention-idle seems to work; system suspend to 
off works

* 3730 Beagle XM: does not serial wake from off-idle suspend when console
  UART doesn't clock gate (debug ignore_loglevel)
  - Not shown in the current test logs; cause unknown


Kernel size/memory differences
--

vmlinux object size
(delta in bytes from test_v3.6 (a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)):
   text data  bsstotal  kernel
+118682   -66688+2280   +54274  am33xx_only
 +57789   -88928+2148   -28991  n800_multi_omap2xxx
 +58669   -86432+2180   -25583  n800_only_a
 +54196+4616 -136   +58676  omap1_defconfig
 +53420+3096 -104   +56412  omap1_defconfig_1510innovator_only
 +54384+3112 -168   +57328  omap1_defconfig_5912osk_only
+128332   -67728+2144   +62748  omap2plus_defconfig
+106894   -83664+1992   +25222  omap2plus_defconfig_2430sdp_only
+128296   -67744+2080   +62632  omap2plus_defconfig_cpupm
+130151   -67552+1824   +64423  omap2plus_defconfig_no_pm
+107810   -88848+1952   +20914  omap2plus_defconfig_omap2_4_only
+107293   -88232+2016   +21077  omap2plus_defconfig_omap3_4_only
+113921   -66976+2348   +49293  rmk_omap3430_ldp_oldconfig
+106849   -47216+2760   +62393  rmk_omap4430_sdp_oldconfig

Boot-time memory difference
(delta in bytes from test_v3.6 (a0d271cbfed1dd50278c6b06bead3d00ba0a88f9))
  avail  rsrvd   high  freed  board  kconfig
20k   -20k  .  -152k  2420n800   omap2plus_defconfig
   -60k60k  . 4k  2430sdpomap2plus_defconfig
   -60k60k  . 4k  3517evmomap2plus_defconfig
   -60k60k  . 4k  3530es3beagle  omap2plus_defconfig
   -60k60k  . 4k  3730beaglexm   omap2plus_defconfig
   -60k60k  . 4k  37xxevmomap2plus_defconfig
   -60k60k  . 4k  4430es2panda   omap2plus_defconfig
   -52k52k  .  .  5912oskomap2plus_defconfig
   -60k60k  .  .  cmt3517omap2plus_defconfig


- Paul


--
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 0/4] OMAP-GPMC generic timing migration

2012-10-17 Thread Afzal Mohammed


Hi Daniel,

On Wednesday 17 October 2012 08:43 PM, Daniel Mack wrote:

On 17.10.2012 07:42, Afzal Mohammed wrote:



I doubt whether auxdata would help here, it seems using
compatible field alone would help in deciding relevant
custom timing routine. Whether we want this kind of
peripheral knowledge in gpmc driver instead of using
generic timing routine has to be decided though.



Another thing that might be worth thinking about is that apart from the
GPMC host controller and the peripherals, there could be other
components like level shifters or series resistors on the board that
limit the maximum speed of transactions. So in fact we might be better
off storing all that timing details in the DT, as they are in fact
highly application specific.


Yes, making it future proof for these kind of scenarios was one
of the reason's that initially triggered generic timing path.

Regards
Afzal
--
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: discrepancy while save and restore of debounce registers

2012-10-17 Thread Hebbar, Gururaja

Jon,

On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
 Hi Gururaja,
 
 On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
  Hi,
  
  I came across a peculiar issue while updating GPIO debounce registers on
  OMAP platform.
  
  According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
  
  gpio/omap: save and restore debounce registers
  
  GPIO debounce registers need to be saved and restored for proper functioning
  of driver.
  
  ...
  @@ -1363,6 +1369,12 @@ static void omap_gpio_restore_context(struct 
  gpio_bank *bank)
  __raw_writel(bank-context.fallingdetect,
  bank-base + bank-regs-fallingdetect);
  __raw_writel(bank-context.dataout, bank-base + 
  bank-regs-dataout);
  +   if (bank-dbck_enable_mask) {
  +   __raw_writel(bank-context.debounce, bank-base +
  +   bank-regs-debounce);
  +   __raw_writel(bank-context.debounce_en,
  +   bank-base + 
  bank-regs-debounce_en);
  +   }
   }
  
  
  Due to copy/paste of this commit into my local tree, I missed the check for 
  bank-dbck_enable_mask, and directly restored the saved value from context.
  
  After this, I saw random crashes when accessing different registers 
  (sometimes
  its OE register and sometime its DATAOUT register). 
  
  These crashes were seen across 2nd and subsequent suspend/resume.
  
  My doubt/questions are
  1. Why should debounce registers be updated only when it's accessed 
  previously?
 
 If debounce is not being used by any of the gpios, then there is no need
 to restore them as there are no bits set. So this makes sense and saves
 a couple register writes.

What I want to know is that other than saving register writes, is there any
other important stuff that specifies this requirement.

 
  2. What is the relation between updating debounce registers and crash seen 
  on
  others registers? 
 
 This I am not sure about. I gave this a quick try on my omap3430 beagle
 board, but I did not see any side-effects from doing this. However, if
 you are always restoring the debounce context regardless of whether
 debounce is being used, then you could be writing bad values to the
 debounce registers as the context variables bank-context.debouce and
 bank-context.debouce_en may not initialised. So that is bad. However,
 that said I am still not sure how this could cause a crash.
 
 Can you share more details on ...

Sorry for missing below details in first post.

 1. The OMAP platform you are using?

I was trying this on TI AM335x platform (repo below). On AM335x EVM board

http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog;
h=refs/heads/v3.2-staging

 2. What linux distro/environment you are using?

Arago AM335x PSP release (linux 3.2 + am335x patch-set)

 3. If there are any specific steps to reproduce this 100% of the time?

On top of this tree, try suspend/resume using echo mem  /syspower/state

 
 Cheers
 Jon
 


Regards, 
Gururaja
--
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: dts: AM33XX: Add tsl2550 ambient light sensor DT data

2012-10-17 Thread AnilKumar, Chimata

On Fri, Sep 21, 2012 at 21:19:11, AnilKumar, Chimata wrote:
 Add tsl2550 ambient light sensor DT data to am335x-evm.dts. In AM335x
 EVM tsl2550 ambient light sensor is connected to I2C2 bus. So this patch
 adds child node inside i2c2 node with i2c slave address.
 
 TAOS tsl2550 sensor with two-wire SMBus serial interface. This patch
 also reduces I2C2 clock frequency to 100KHz from 400KHz because the
 maximum clock frequency of SMBus is 100KHz.
 
 Signed-off-by: AnilKumar Ch anilku...@ti.com
 ---
  arch/arm/boot/dts/am335x-evm.dts |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/am335x-evm.dts 
 b/arch/arm/boot/dts/am335x-evm.dts
 index 3b1f313..d99aa0f 100644
 --- a/arch/arm/boot/dts/am335x-evm.dts
 +++ b/arch/arm/boot/dts/am335x-evm.dts
 @@ -49,7 +49,7 @@
  
   i2c2: i2c@4802a000 {
   status = okay;
 - clock-frequency = 40;
 + clock-frequency = 10;
  
   lis331dlh: lis331dlh@18 {
   compatible = st,lis331dlh, st,lis3lv02d;
 @@ -79,6 +79,11 @@
   st,max-limit-z = 750;
   };
  
 + tsl2550: tsl2550@39 {
 + compatible = taos,tsl2550;
 + reg = 0x39;
 + };
 +
   tmp275: tmp275@48 {
   compatible = ti,tmp275;
   reg = 0x48;

Hi Tony/Benoit,

If there are no comments in this patch could you please take this in?

Thanks
AnilKumar
--
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+: Only write the sysconfig on idle when necessary

2012-10-17 Thread Rajendra Nayak


On Thursday 18 October 2012 02:07 AM, Jon Hunter wrote:

Ok, thanks. Yes, only updating the register when the cache value changed
would not work due to the possibility of context being lost. So
Rajendra's change makes sense. However, I think there is room to
optimise this.

With this change, on idle, the cache value and register value are only
updated when needed. This should be safe.

Are you looking to go one step further and only update the sysconfig on
enabling when the context has been lost? That would require more
changes. This was a quick optimisation I saw when reviewing the code.

Rajendra, let me know if you have any comments.


Makes sense to me. To handle the more generic case of avoiding all
reads and writes whenever possible, and making the cache really behave
like a cache, as Paul suggested, is certainly more work and more
importantly more testing, as it would rely heavily on the context lost 
counters to work correctly. I feel there is still some work needed

around those counters to make them more robust before we start heading
in that direction.
--
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 v2] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h

Hi,

On Wed, Oct 17, 2012 at 01:34:04PM -0700, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [121017 08:54]:
  In order to make single zImage work for ARM architecture,
  we need to make sure we don't depend on private headers.
  
  Move USB platform_data to linux/platform_data/omap-usb.h
  and keep only internal functions in plat/usb.h.
 
 Thanks, looks like I can't make this apply against v3.7-rc1:
 
 patching file arch/arm/plat-omap/include/plat/usb.h
 Hunk #1 FAILED at 1.
 Hunk #2 FAILED at 26.
 Hunk #3 FAILED at 44.
 Hunk #4 FAILED at 65.
 Hunk #5 FAILED at 81.
 Hunk #6 succeeded at 28 with fuzz 2 (offset -128 lines).
 5 out of 6 hunks FAILED -- rejects in file 
 arch/arm/plat-omap/include/plat/usb.h
 
 Can you please check it?

Are you sure you have a clean v3.7-rc1 ?

commit 9b1ebba0f43e7bf6a8fdd8aa84da65e5e0344fb7
Author: Felipe Balbi ba...@ti.com
Date:   Fri Sep 28 09:51:01 2012 +0300

arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h

In order to make single zImage work for ARM architecture,
we need to make sure we don't depend on private headers.

Move USB platform_data to linux/platform_data/omap-usb.h
and keep only internal functions in plat/usb.h.

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

commit ddffeb8c4d0331609ef2581d84de4d763607bd37
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Sun Oct 14 14:41:04 2012 -0700

Linux 3.7-rc1


That's my branch. Patch is right on top of v3.7-rc1 commit.

-- 
balbi


signature.asc
Description: Digital signature

Re: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support)