Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
Tomi Valkeinen tomi.valkei...@ti.com writes: On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote: Hi Tomi, Tomi Valkeinen tomi.valkei...@ti.com writes: 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 [...] I was having a quick look at this for the context save/restore piece in order to understand how this driver's context is being saved/restored. Looking at mainline, I don't see where omap_vrfb_restore_context() is being called currently. Am I missing something? No, the driver is missing something. I noticed the same thing. It seems ctx restore for vrfb has never been functional in mainline. I don't really have any recollection if this was left out intentionally from mainline (possibly because we didn't have a good way to handle it at that point), or was it just a mistake. Nobody has complained about it, though, so it can't be a major problem =). heh Vrfb is a platform device/driver after this patch. Do you see any problem with handling the context restore in runtime PM's runtime_resume callback? No, that's the right way to handle it IMO. In fact, that's what I was going to check on when reviewing this patch when I noticed that the restore function wasn't being used. Hmm, I guess then we could have a problem if omapdss and omapfb are resumed before vrfb. Possibly, but this could be handled by adding some sanity checks, or having VRFB functions return -EAGAIN if it hasn't been resumed. Or better yet, VRFB functions should be using runtime PM get/put themselves, if they're used by omapdss/omapfb, a runtime resume (and context restore) is forced. (disclaimer: I don't actually know how VRFB works, so maybe this isn't possible.) Any way to manage the suspend/resume ordering of unrelated (i.e. no parent/child relation) devices? No good way at the moment. And to make things interesting: static suspend/resume ordering is not dependent on parent/child. It's based on driver discover/probe order. runtime PM ordering manages parent/child relationships. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/3] 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| 59 +++
arch/arm/plat-omap/include/plat/vrfb.h |2 +-
drivers/video/omap2/Kconfig|2 +-
drivers/video/omap2/vrfb.c | 124 ++--
4 files changed, 165 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index dd6f92c..a390784 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -35,6 +35,65 @@
#include plat/board.h
+#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
+
+/*
+ * 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/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
index 3792bde..dafbb77 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,7 +35,7 @@ struct vrfb {
bool yuv_mode;
};
-#ifdef CONFIG_OMAP2_VRFB
+#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
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,
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index d877c36..4700ca9 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -2,7 +2,7 @@ config OMAP2_VRAM
bool
config OMAP2_VRFB
- bool
+ tristate
source drivers/video/omap2/dss/Kconfig
source drivers/video/omap2/omapfb/Kconfig
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)
Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
Hi Tomi, Tomi Valkeinen tomi.valkei...@ti.com writes: 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 [...] I was having a quick look at this for the context save/restore piece in order to understand how this driver's context is being saved/restored. Looking at mainline, I don't see where omap_vrfb_restore_context() is being called currently. Am I missing something? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote: Hi Tomi, Tomi Valkeinen tomi.valkei...@ti.com writes: 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 [...] I was having a quick look at this for the context save/restore piece in order to understand how this driver's context is being saved/restored. Looking at mainline, I don't see where omap_vrfb_restore_context() is being called currently. Am I missing something? No, the driver is missing something. I noticed the same thing. It seems ctx restore for vrfb has never been functional in mainline. I don't really have any recollection if this was left out intentionally from mainline (possibly because we didn't have a good way to handle it at that point), or was it just a mistake. Nobody has complained about it, though, so it can't be a major problem =). Vrfb is a platform device/driver after this patch. Do you see any problem with handling the context restore in runtime PM's runtime_resume callback? Hmm, I guess then we could have a problem if omapdss and omapfb are resumed before vrfb. Any way to manage the suspend/resume ordering of unrelated (i.e. no parent/child relation) devices? Tomi signature.asc Description: This is a digitally signed message part
