* Re: [PATCH 1/2] da8xx-fb: move panel information from driver to platform file
From: Sekhar Nori @ 2012-10-09 6:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1349445084-9857-2-git-send-email-prakash.pm@ti.com>
On 10/8/2012 10:03 PM, Manjunathappa, Prakash wrote:
> Hi Sekhar,
>
> On Mon, Oct 08, 2012 at 18:10:12, Nori, Sekhar wrote:
>> Hi Prakash,
>>
>> On 10/5/2012 7:21 PM, Manjunathappa, Prakash wrote:
>>> Moving panel information from driver to platform file, patch also made
>>> compliant to fb_videomode data.
>>>
>>> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
>>
>> Why do you have to do this? Just moving panel data from driver to
>> platform code doesn't seem to buy anything.
>>
>> If you are passed DT data, then use it else continue the existing
>> platform data method? Once all the boards using this driver are
>> converted to DT, then all the panel information can be removed from
>> driver. That will save code.
>>
>
> Because of following reasons I moved it out of driver
> 1)This patch also converts panel information compliant to fb_videomode.
> Patch "of: add display helper"[1] under review expects panel data in fb_videomode format.
Sounds like this should be a separate patch as this has got nothing to
do with moving panel information to platform code.
> 2)I felt difficult and unclean to have driver supporting both panel data from driver and panel data from DT.
Do you have any code where you tried this? If it is clean enough, can
you post it so we can all see what the alternate looks like?
> 3)This effort will also ease adding DT support of this driver.
It is still not clear to me why exactly it will ease adding DT support.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH 2/2 v6] of: add generic videomode description
From: Steffen Trumtrar @ 2012-10-09 7:26 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree-discuss, Rob Herring, linux-fbdev, dri-devel,
linux-media, Tomi Valkeinen
In-Reply-To: <1737299.6PuzOm7XuT@avalon>
Hi Laurent,
On Mon, Oct 08, 2012 at 10:52:04PM +0200, Laurent Pinchart wrote:
> Hi Steffen,
>
> On Monday 08 October 2012 14:48:01 Steffen Trumtrar wrote:
> > On Mon, Oct 08, 2012 at 02:13:50PM +0200, Laurent Pinchart wrote:
> > > On Thursday 04 October 2012 19:59:20 Steffen Trumtrar wrote:
> > > > Get videomode from devicetree in a format appropriate for the
> > > > backend. drm_display_mode and fb_videomode are supported atm.
> > > > Uses the display signal timings from of_display_timings
> > > >
> > > > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > > > ---
> > > >
> > > > drivers/of/Kconfig | 5 +
> > > > drivers/of/Makefile | 1 +
> > > > drivers/of/of_videomode.c | 212 +++++++++++++++++++++++++++++++++++
> > > > include/linux/of_videomode.h | 41 ++++++++
> > > > 4 files changed, 259 insertions(+)
> > > > create mode 100644 drivers/of/of_videomode.c
> > > > create mode 100644 include/linux/of_videomode.h
>
> [snip]
>
> > > > diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
> > > > new file mode 100644
> > > > index 0000000..76ac16e
> > > > --- /dev/null
> > > > +++ b/drivers/of/of_videomode.c
>
> [snip]
>
> > > > +int videomode_from_timing(struct display_timings *disp, struct
> > > > videomode *vm,
> > > > + int index)
> > > > +{
> > > > + struct signal_timing *st = NULL;
> > > > +
> > > > + if (!vm)
> > > > + return -EINVAL;
> > > > +
> > >
> > > What about making vm a mandatory argument ? It looks to me like a caller
> > > bug if vm is NULL.
> >
> > The caller must provide the struct videomode, yes. Wouldn't the kernel hang
> > itself with a NULL pointer exception, if I just work with it ?
>
> The kernel would oops, clearly showing the caller that a non-null vm is needed
> :-)
>
Okay. No error checking it is then.
> > > > + st = display_timings_get(disp, index);
> > > > +
> > >
> > > You can remove the blank line.
> > >
> > > > + if (!st) {
> > > > + pr_err("%s: no signal timings found\n", __func__);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + vm->pixelclock = signal_timing_get_value(&st->pixelclock, 0);
> > > > + vm->hactive = signal_timing_get_value(&st->hactive, 0);
> > > > + vm->hfront_porch = signal_timing_get_value(&st->hfront_porch, 0);
> > > > + vm->hback_porch = signal_timing_get_value(&st->hback_porch, 0);
> > > > + vm->hsync_len = signal_timing_get_value(&st->hsync_len, 0);
> > > > +
> > > > + vm->vactive = signal_timing_get_value(&st->vactive, 0);
> > > > + vm->vfront_porch = signal_timing_get_value(&st->vfront_porch, 0);
> > > > + vm->vback_porch = signal_timing_get_value(&st->vback_porch, 0);
> > > > + vm->vsync_len = signal_timing_get_value(&st->vsync_len, 0);
> > > > +
> > > > + vm->vah = st->vsync_pol_active_high;
> > > > + vm->hah = st->hsync_pol_active_high;
> > > > + vm->interlaced = st->interlaced;
> > > > + vm->doublescan = st->doublescan;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int of_get_videomode(struct device_node *np, struct videomode *vm, int
> > > > index)
> > >
> > > I wonder how to avoid abuse of this functions. It's a useful helper for
> > > drivers that need to get a video mode once only, but would result in lower
> > > performances if a driver calls it for every mode. Drivers must call
> > > of_get_display_timing_list instead in that case and case the display
> > > timings. I'm wondering whether we should really expose of_get_videomode.
> >
> > The intent was to let the driver decide. That way all the other overhead may
> > be skipped.
>
> My point is that driver writers might just call of_get_videomode() in a loop,
> not knowing that it's expensive. I want to avoid that. We need to at least add
> kerneldoc to the function stating that this shouldn't be done.
>
You're right. That should be made clear in the code.
> > > > +{
> > > > + struct display_timings *disp;
> > > > + int ret = 0;
> > >
> > > No need to assign ret to 0 here.
> >
> > Ah, yes. Unneeded in this case.
> >
> > > > +
> > > > + disp = of_get_display_timing_list(np);
> > > > +
> > >
> > > You can remove the blank line.
> > >
> > > > + if (!disp) {
> > > > + pr_err("%s: no timings specified\n", __func__);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + if (index = OF_DEFAULT_TIMING)
> > > > + index = disp->default_timing;
> > > > +
> > > > + ret = videomode_from_timing(disp, vm, index);
> > > > +
> > >
> > > No need for a blank line.
> > >
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + display_timings_release(disp);
> > > > +
> > > > + if (!vm) {
> > > > + pr_err("%s: could not get videomode %d\n", __func__, index);
> > > > + return -EINVAL;
> > > > + }
> > >
> > > This can't happen. If vm is NULL the videomode_from_timing call above will
> > > return -EINVAL, and this function will then return immediately without
> > > reaching this code block.
> >
> > Okay.
> >
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(of_get_videomode);
>
> --
> Regards,
>
> Laurent Pinchart
>
>
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/2] OMAP: VRFB: convert vrfb to platform device
From: Tomi Valkeinen @ 2012-10-09 8:55 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev, Archit Taneja
In-Reply-To: <20121008172440.GI3874@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 4443 bytes --]
On Mon, 2012-10-08 at 10:24 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121008 05:31]:
> > 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.valkeinen@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > ---
> > arch/arm/plat-omap/fb.c | 53 +++++++++++++++++++
> > drivers/video/omap2/vrfb.c | 124 +++++++++++++++++++++++++++++++++++++-------
> > 2 files changed, 157 insertions(+), 20 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
> > index dd6f92c..d231912 100644
> > --- a/arch/arm/plat-omap/fb.c
> > +++ b/arch/arm/plat-omap/fb.c
> > @@ -35,6 +35,59 @@
> >
> > #include <plat/board.h>
> >
> > +#if defined(CONFIG_OMAP2_VRFB)
> > +static const struct resource omap2_vrfb_resources[] = {
> > + DEFINE_RES_MEM(0x68008000u, 0x40),
> > + DEFINE_RES_MEM(0x70000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x74000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x78000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x7c000000u, 0x4000000),
> > +};
> > +
> > +static const struct resource omap3_vrfb_resources[] = {
> > + DEFINE_RES_MEM(0x6C000180u, 0xc0),
> > + DEFINE_RES_MEM(0x70000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x74000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x78000000u, 0x4000000),
> > + DEFINE_RES_MEM(0x7c000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xe0000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xe4000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xe8000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xec000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xf0000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xf4000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xf8000000u, 0x4000000),
> > + DEFINE_RES_MEM(0xfc000000u, 0x4000000),
> > +};
>
> Maybe add comments describing what these register are in case
> we have a framework handling them at some point later on?
Sure.
> > --- a/drivers/video/omap2/vrfb.c
> > +++ b/drivers/video/omap2/vrfb.c
> > +#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) (0x1000000 * (rot))
>
> Can you please also remove the old SMS defines and functions
> so other code won't start tinkering with them?
Ok.
> > +static int __init vrfb_probe(struct platform_device *pdev)
> > +{
> > + struct resource *mem;
> > + int i;
> > +
> > + /* first resource is the register res, the rest are vrfb contexts */
> > +
> > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!mem) {
> > + dev_err(&pdev->dev, "can't get vrfb base address\n");
> > + return -EINVAL;
> > + }
>
> Now that we assume vrfb is the only user of this, so you must do
> request_mem_region here as that's the only protection we have.
> If that fails here, then we know something is wrong.
Right, I'll add that.
> > + vrfb_base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
> > + if (!vrfb_base) {
> > + dev_err(&pdev->dev, "can't ioremap vrfb memory\n");
> > + return -ENOMEM;
> > + }
> > +
> > + num_ctxs = pdev->num_resources - 1;
> > +
> > + ctxs = devm_kzalloc(&pdev->dev,
> > + sizeof(struct vrfb_ctx) * num_ctxs,
> > + GFP_KERNEL);
> > +
> > + if (!ctxs)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < num_ctxs; ++i) {
> > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
> > + if (!mem) {
> > + dev_err(&pdev->dev, "can't get vrfb ctx %d address\n",
> > + i);
> > + return -EINVAL;
> > + }
> > +
> > + ctxs[i].base = mem->start;
> > + }
>
> And request_mem_region must also be done for these registers to make
> sure no other code is using them. Again, if it fails, something is
> wrong.
There's already request_mem_region for the VRFB virtual areas, which is
done later when omapfb or somebody else requests a vrfb context with
omap_vrfb_request_ctx(). The memory areas (they are rotated
framebuffers, not registers as such) are not used until then.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] fb: only enable console lock in fb for VGA console
From: Jun Nie @ 2012-10-09 10:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CAGA24M+PmObK3ZJWvtNhBzxO4WkGk_xyveQiZNtZe7xGdHrbFw@mail.gmail.com>
2012/9/30 Paul Mundt <lethal@linux-sh.org>:
> On Sat, Sep 29, 2012 at 01:29:17PM +0800, Jun Nie wrote:
>> diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
>> index 1d00736..7759c82 100644
>> --- a/drivers/video/s3fb.c
>> +++ b/drivers/video/s3fb.c
>> @@ -1445,12 +1444,12 @@ static int s3_pci_suspend(struct pci_dev* dev,
>> pm_message_t state)
>>
>> dev_info(info->device, "suspend\n");
>>
>> - console_lock();
>> + fb_fb_console_lock();
>> mutex_lock(&(par->open_lock));
>>
> Compiling is overrated anyways.
>
>> diff --git a/drivers/video/tmiofb.c b/drivers/video/tmiofb.c
>> index 8e4a446..e266b6b 100644
>> --- a/drivers/video/tmiofb.c
>> +++ b/drivers/video/tmiofb.c
>> @@ -959,7 +958,7 @@ static int tmiofb_suspend(struct platform_device
>> *dev, pm_message_t state)
>> if (cell->suspend)
>> retval = cell->suspend(dev);
>>
>> - console_unlock();
>> + fb_fb_console_unlock();
>>
>> return retval;
>> }
>> @@ -986,7 +985,7 @@ static int tmiofb_resume(struct platform_device *dev)
>>
>> fb_set_suspend(info, 0);
>> out:
>> - console_unlock();
>> + fb_fb_console_unlock();
>> return retval;
>> }
>> #else
>
> Here too.
>
> Turning locks in to no-ops without auditing every single driver's use of
> said lock and converting to something to protect the work being done
> under lock suggests that this conversion is more mechanical than thought
> out beyond your specific use case.
>
> While you've obviously identified a problem that's worth pursuing, it's
> going to take a bit more work than mechanical conversion, and it's going
> to have to be something that's moved towards incrementally. If you
> haven't even compile tested the impacted drivers, it suggests you haven't
> spent a great deal of time thinking about what they are doing under said
> lock, either..
Paul,
Thanks for pointing out the defect in my pacth. I did not compile for
every arch I changed.
I check console_lock usage and find it is used for three category
operations sync, a) console output. b) console configuration(font,
resize, connection, etc). c) FB system internal sync as Benjamin
mentioned. Usage A does not happen frequenty. Usage B is our target.
Usage C happens frequently and it may hold the lock for a long time,
while it is unrelated to console if framebuffer console is disabled.
For any system whose log relay on non-FB console, it may encounter no
log or partial log when panic. So it is common use case.
How do you think below code for this purpose?
#ifndef CONFIG_FRAMEBUFFER_CONSOLE
static DEFINE_MUTEX(fb_lock);
#endif
void fb_console_lock(void)
{
#ifdef CONFIG_FRAMEBUFFER_CONSOLE
console_lock();
#else
mutex_lock(&fb_lock);
#endif
}
EXPORT_SYMBOL(fb_console_lock);
void fb_console_unlock(void)
{
#ifdef CONFIG_FRAMEBUFFER_CONSOLE
console_unlock();
#else
mutex_unlock(&fb_lock);
#endif
}
EXPORT_SYMBOL(fb_console_unlock);
^ permalink raw reply
* [PATCH] matroxfb: Convert struct i2c_msg initialization to C99 format
From: Shubhrajyoti D @ 2012-10-09 11:49 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: FlorianSchandinat-Mmb7MZpHnFY, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w, Shubhrajyoti D
In-Reply-To: <1347897325-20684-1-git-send-email-shubhrajyoti@ti.com>
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Thanks to Julia Lawall <julia.lawall@lip6.fr> for automating the conversion
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/video/matrox/matroxfb_maven.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
index 217678e..fb5c123 100644
--- a/drivers/video/matrox/matroxfb_maven.c
+++ b/drivers/video/matrox/matroxfb_maven.c
@@ -137,8 +137,19 @@ static int* get_ctrl_ptr(struct maven_data* md, int idx) {
static int maven_get_reg(struct i2c_client* c, char reg) {
char dst;
- struct i2c_msg msgs[] = {{ c->addr, I2C_M_REV_DIR_ADDR, sizeof(reg), ® },
- { c->addr, I2C_M_RD | I2C_M_NOSTART, sizeof(dst), &dst }};
+ struct i2c_msg msgs[] = {{
+ .addr = c->addr,
+ .flags = I2C_M_REV_DIR_ADDR,
+ .len = sizeof(reg),
+ .buf = ®
+ },
+ {
+ .addr = c->addr,
+ .flags = I2C_M_RD | I2C_M_NOSTART,
+ .len = sizeof(dst),
+ .buf = &dst
+ }
+ };
s32 err;
err = i2c_transfer(c->adapter, msgs, 2);
--
1.7.5.4
^ permalink raw reply related
* [PATCHv2 0/3] OMAP: VRFB: convert to platform device
From: Tomi Valkeinen @ 2012-10-09 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Tony Lindgren; +Cc: Archit Taneja, Tomi Valkeinen
Hi,
This is second version of the patch series. The changes to v1 are:
* request mem region for VRFB registers
* declare VRFB resources with names
* remove unused VRFB code from sdrc
* vrfb is now tristate, so that it can be built as a module
Tomi
Tomi Valkeinen (3):
OMAP: VRFB: convert vrfb to platform device
OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
OMAP: SDRC: remove VRFB code
arch/arm/mach-omap2/sdrc.c | 16 ----
arch/arm/plat-omap/fb.c | 59 ++++++++++++++
arch/arm/plat-omap/include/plat/sdrc.h | 7 --
arch/arm/plat-omap/include/plat/vrfb.h | 66 ---------------
drivers/media/video/omap/omap_vout.c | 2 +-
drivers/media/video/omap/omap_vout_vrfb.c | 2 +-
drivers/media/video/omap/omap_voutdef.h | 2 +-
drivers/video/omap2/Kconfig | 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 | 126 ++++++++++++++++++++++++-----
include/video/omapvrfb.h | 66 +++++++++++++++
13 files changed, 237 insertions(+), 117 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
create mode 100644 include/video/omapvrfb.h
--
1.7.9.5
^ permalink raw reply
* [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
From: Tomi Valkeinen @ 2012-10-09 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Tony Lindgren; +Cc: Archit Taneja, Tomi Valkeinen
In-Reply-To: <1349785827-27055-1-git-send-email-tomi.valkeinen@ti.com>
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.valkeinen@ti.com>
Cc: Tony Lindgren <tony@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(0x70000000u, 0x4000000, "vrfb-area-0"),
+ DEFINE_RES_MEM_NAMED(0x74000000u, 0x4000000, "vrfb-area-1"),
+ DEFINE_RES_MEM_NAMED(0x78000000u, 0x4000000, "vrfb-area-2"),
+ DEFINE_RES_MEM_NAMED(0x7c000000u, 0x4000000, "vrfb-area-3"),
+};
+
+static const struct resource omap3_vrfb_resources[] = {
+ DEFINE_RES_MEM_NAMED(0x6C000180u, 0xc0, "vrfb-regs"),
+ DEFINE_RES_MEM_NAMED(0x70000000u, 0x4000000, "vrfb-area-0"),
+ DEFINE_RES_MEM_NAMED(0x74000000u, 0x4000000, "vrfb-area-1"),
+ DEFINE_RES_MEM_NAMED(0x78000000u, 0x4000000, "vrfb-area-2"),
+ DEFINE_RES_MEM_NAMED(0x7c000000u, 0x4000000, "vrfb-area-3"),
+ DEFINE_RES_MEM_NAMED(0xe0000000u, 0x4000000, "vrfb-area-4"),
+ DEFINE_RES_MEM_NAMED(0xe4000000u, 0x4000000, "vrfb-area-5"),
+ DEFINE_RES_MEM_NAMED(0xe8000000u, 0x4000000, "vrfb-area-6"),
+ DEFINE_RES_MEM_NAMED(0xec000000u, 0x4000000, "vrfb-area-7"),
+ DEFINE_RES_MEM_NAMED(0xf0000000u, 0x4000000, "vrfb-area-8"),
+ DEFINE_RES_MEM_NAMED(0xf4000000u, 0x4000000, "vrfb-area-9"),
+ DEFINE_RES_MEM_NAMED(0xf8000000u, 0x4000000, "vrfb-area-10"),
+ DEFINE_RES_MEM_NAMED(0xfc000000u, 0x4000000, "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) ? 0xD0000000 : 0x70000000) \
- + (0x4000000 * (context)) \
- + (0x1000000 * (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) (0x1000000 * (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 + SMS_ROT_CONTROL(ctx));
+}
+
+static void omap2_sms_write_rot_size(u32 val, unsigned ctx)
+{
+ __raw_writel(val, vrfb_base + SMS_ROT_SIZE(ctx));
+}
+
+static void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
+{
+ __raw_writel(val, vrfb_base + SMS_ROT_PHYSICAL_BA(ctx));
+}
static inline void restore_hw_context(int ctx)
{
- omap2_sms_write_rot_control(vrfb_hw_context[ctx].control, ctx);
- omap2_sms_write_rot_size(vrfb_hw_context[ctx].size, ctx);
- omap2_sms_write_rot_physical_ba(vrfb_hw_context[ctx].physical_ba, ctx);
+ omap2_sms_write_rot_control(ctxs[ctx].control, ctx);
+ omap2_sms_write_rot_size(ctxs[ctx].size, ctx);
+ omap2_sms_write_rot_physical_ba(ctxs[ctx].physical_ba, ctx);
}
static u32 get_image_width_roundup(u16 width, u8 bytespp)
@@ -196,9 +217,9 @@ void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
control |= VRFB_PAGE_WIDTH_EXP << SMS_PW_OFFSET;
control |= VRFB_PAGE_HEIGHT_EXP << SMS_PH_OFFSET;
- vrfb_hw_context[ctx].physical_ba = paddr;
- vrfb_hw_context[ctx].size = size;
- vrfb_hw_context[ctx].control = control;
+ ctxs[ctx].physical_ba = paddr;
+ ctxs[ctx].size = size;
+ ctxs[ctx].control = control;
omap2_sms_write_rot_physical_ba(paddr, ctx);
omap2_sms_write_rot_size(size, ctx);
@@ -274,11 +295,11 @@ int omap_vrfb_request_ctx(struct vrfb *vrfb)
mutex_lock(&ctx_lock);
- for (ctx = 0; ctx < VRFB_NUM_CTXS; ++ctx)
+ for (ctx = 0; ctx < num_ctxs; ++ctx)
if ((ctx_map & (1 << ctx)) = 0)
break;
- if (ctx = VRFB_NUM_CTXS) {
+ if (ctx = num_ctxs) {
pr_err("vrfb: no free contexts\n");
r = -EBUSY;
goto out;
@@ -293,7 +314,7 @@ int omap_vrfb_request_ctx(struct vrfb *vrfb)
vrfb->context = ctx;
for (rot = 0; rot < 4; ++rot) {
- paddr = SMS_ROT_VIRT_BASE(ctx, rot);
+ paddr = ctxs[ctx].base + SMS_ROT_VIRT_BASE(rot);
if (!request_mem_region(paddr, OMAP_VRFB_SIZE, "vrfb")) {
pr_err("vrfb: failed to reserve VRFB "
"area for ctx %d, rotation %d\n",
@@ -314,3 +335,66 @@ out:
return r;
}
EXPORT_SYMBOL(omap_vrfb_request_ctx);
+
+static int __init vrfb_probe(struct platform_device *pdev)
+{
+ struct resource *mem;
+ int i;
+
+ /* first resource is the register res, the rest are vrfb contexts */
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "can't get vrfb base address\n");
+ return -EINVAL;
+ }
+
+ vrfb_base = devm_request_and_ioremap(&pdev->dev, mem);
+ if (!vrfb_base) {
+ dev_err(&pdev->dev, "can't ioremap vrfb memory\n");
+ return -ENOMEM;
+ }
+
+ num_ctxs = pdev->num_resources - 1;
+
+ ctxs = devm_kzalloc(&pdev->dev,
+ sizeof(struct vrfb_ctx) * num_ctxs,
+ GFP_KERNEL);
+
+ if (!ctxs)
+ return -ENOMEM;
+
+ for (i = 0; i < num_ctxs; ++i) {
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
+ if (!mem) {
+ dev_err(&pdev->dev, "can't get vrfb ctx %d address\n",
+ i);
+ return -EINVAL;
+ }
+
+ ctxs[i].base = mem->start;
+ }
+
+ return 0;
+}
+
+static struct platform_driver vrfb_driver = {
+ .driver.name = "omapvrfb",
+};
+
+static int __init vrfb_init(void)
+{
+ return platform_driver_probe(&vrfb_driver, &vrfb_probe);
+}
+
+static void __exit vrfb_exit(void)
+{
+ platform_driver_unregister(&vrfb_driver);
+}
+
+module_init(vrfb_init);
+module_exit(vrfb_exit);
+
+MODULE_AUTHOR("Tomi Valkeinen <tomi.valkeinen@ti.com>");
+MODULE_DESCRIPTION("OMAP VRFB");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
From: Tomi Valkeinen @ 2012-10-09 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Tony Lindgren
Cc: Archit Taneja, Tomi Valkeinen, Vaibhav Hiremath
In-Reply-To: <1349785827-27055-1-git-send-email-tomi.valkeinen@ti.com>
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.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
arch/arm/plat-omap/include/plat/vrfb.h | 66 -----------------------------
drivers/media/video/omap/omap_vout.c | 2 +-
drivers/media/video/omap/omap_vout_vrfb.c | 2 +-
drivers/media/video/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 dafbb77..0000000
--- 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.valkeinen@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;
-};
-
-#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,
- 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/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c
index f721fd2..940f39f 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -45,7 +45,7 @@
#include <media/v4l2-ioctl.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/video/omap/omap_vout_vrfb.c b/drivers/media/video/omap/omap_vout_vrfb.c
index 4be26abf6c..6c37f92 100644
--- a/drivers/media/video/omap/omap_vout_vrfb.c
+++ b/drivers/media/video/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/video/omap/omap_voutdef.h b/drivers/media/video/omap/omap_voutdef.h
index 27a95d2..9ccfe1f 100644
--- a/drivers/media/video/omap/omap_voutdef.h
+++ b/drivers/media/video/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_BPP 2
#define RGB565_BPP 2
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 606b89f..55a39be 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -30,7 +30,7 @@
#include <linux/export.h>
#include <video/omapdss.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include <plat/vram.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index b103793..742a66b 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -32,7 +32,7 @@
#include <video/omapdss.h>
#include <plat/vram.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/omapfb/omapfb-sysfs.c b/drivers/video/omap2/omapfb/omapfb-sysfs.c
index e8d8cc7..17aa174 100644
--- a/drivers/video/omap2/omapfb/omapfb-sysfs.c
+++ b/drivers/video/omap2/omapfb/omapfb-sysfs.c
@@ -30,7 +30,7 @@
#include <linux/omapfb.h>
#include <video/omapdss.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#include "omapfb.h"
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index fda45cc..e4a0450 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -28,7 +28,7 @@
#include <linux/mutex.h>
#include <linux/platform_device.h>
-#include <plat/vrfb.h>
+#include <video/omapvrfb.h>
#ifdef DEBUG
#define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
diff --git a/include/video/omapvrfb.h b/include/video/omapvrfb.h
new file mode 100644
index 0000000..dafbb77
--- /dev/null
+++ b/include/video/omapvrfb.h
@@ -0,0 +1,66 @@
+/*
+ * VRFB Rotation Engine
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen <tomi.valkeinen@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;
+};
+
+#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,
+ 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 */
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 3/3] OMAP: SDRC: remove VRFB code
From: Tomi Valkeinen @ 2012-10-09 12:30 UTC (permalink / raw)
To: linux-omap, linux-fbdev, Tony Lindgren; +Cc: Archit Taneja, Tomi Valkeinen
In-Reply-To: <1349785827-27055-1-git-send-email-tomi.valkeinen@ti.com>
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.valkeinen@ti.com>
Cc: Tony Lindgren <tony@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
^ permalink raw reply related
* RE: [PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
From: Hiremath, Vaibhav @ 2012-10-09 12:54 UTC (permalink / raw)
To: Valkeinen, Tomi, linux-omap@vger.kernel.org,
linux-fbdev@vger.kernel.org, Tony Lindgren
Cc: Taneja, Archit
In-Reply-To: <1349785827-27055-3-git-send-email-tomi.valkeinen@ti.com>
On Tue, Oct 09, 2012 at 18:00:25, Valkeinen, Tomi wrote:
> 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.
>
Which baseline you are using? I tried it with linux-omap/master, patch[1/3] is failing -
patching file arch/arm/plat-omap/include/plat/vrfb.h
patching file drivers/media/video/omap/omap_vout.c
Hunk #1 FAILED at 45.
1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_vout.c.rej
patching file drivers/media/video/omap/omap_vout_vrfb.c
Hunk #1 FAILED at 17.
1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_vout_vrfb.c.rej
patching file drivers/media/video/omap/omap_voutdef.h
Hunk #1 FAILED at 12.
1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_voutdef.h.rej
patching file drivers/video/omap2/omapfb/omapfb-ioctl.c
patching file drivers/video/omap2/omapfb/omapfb-main.c
Hunk #1 succeeded at 33 with fuzz 2 (offset 1 line).
patching file drivers/video/omap2/omapfb/omapfb-sysfs.c
patching file drivers/video/omap2/vrfb.c
patching file include/video/omapvrfb.h
Note that, the directory structure has been changed in the mainline,
Now V4L2 OMAP Display driver is in "drivers/media/platform/omap/"
You have to rebase the patches and resend it.
Thanks,
Vaibhav
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> ---
> arch/arm/plat-omap/include/plat/vrfb.h | 66 -----------------------------
> drivers/media/video/omap/omap_vout.c | 2 +-
> drivers/media/video/omap/omap_vout_vrfb.c | 2 +-
> drivers/media/video/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 dafbb77..0000000
> --- 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.valkeinen@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;
> -};
> -
> -#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,
> - 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/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c
> index f721fd2..940f39f 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -45,7 +45,7 @@
> #include <media/v4l2-ioctl.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/video/omap/omap_vout_vrfb.c b/drivers/media/video/omap/omap_vout_vrfb.c
> index 4be26abf6c..6c37f92 100644
> --- a/drivers/media/video/omap/omap_vout_vrfb.c
> +++ b/drivers/media/video/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/video/omap/omap_voutdef.h b/drivers/media/video/omap/omap_voutdef.h
> index 27a95d2..9ccfe1f 100644
> --- a/drivers/media/video/omap/omap_voutdef.h
> +++ b/drivers/media/video/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_BPP 2
> #define RGB565_BPP 2
> diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> index 606b89f..55a39be 100644
> --- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
> +++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
> @@ -30,7 +30,7 @@
> #include <linux/export.h>
>
> #include <video/omapdss.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
> #include <plat/vram.h>
>
> #include "omapfb.h"
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
> index b103793..742a66b 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -32,7 +32,7 @@
>
> #include <video/omapdss.h>
> #include <plat/vram.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
>
> #include "omapfb.h"
>
> diff --git a/drivers/video/omap2/omapfb/omapfb-sysfs.c b/drivers/video/omap2/omapfb/omapfb-sysfs.c
> index e8d8cc7..17aa174 100644
> --- a/drivers/video/omap2/omapfb/omapfb-sysfs.c
> +++ b/drivers/video/omap2/omapfb/omapfb-sysfs.c
> @@ -30,7 +30,7 @@
> #include <linux/omapfb.h>
>
> #include <video/omapdss.h>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
>
> #include "omapfb.h"
>
> diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
> index fda45cc..e4a0450 100644
> --- a/drivers/video/omap2/vrfb.c
> +++ b/drivers/video/omap2/vrfb.c
> @@ -28,7 +28,7 @@
> #include <linux/mutex.h>
> #include <linux/platform_device.h>
>
> -#include <plat/vrfb.h>
> +#include <video/omapvrfb.h>
>
> #ifdef DEBUG
> #define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
> diff --git a/include/video/omapvrfb.h b/include/video/omapvrfb.h
> new file mode 100644
> index 0000000..dafbb77
> --- /dev/null
> +++ b/include/video/omapvrfb.h
> @@ -0,0 +1,66 @@
> +/*
> + * VRFB Rotation Engine
> + *
> + * Copyright (C) 2009 Nokia Corporation
> + * Author: Tomi Valkeinen <tomi.valkeinen@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;
> +};
> +
> +#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,
> + 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 */
> --
> 1.7.9.5
>
>
^ permalink raw reply
* RE: [PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
From: Tomi Valkeinen @ 2012-10-09 12:57 UTC (permalink / raw)
To: Hiremath, Vaibhav
Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
Tony Lindgren, Taneja, Archit
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB3A082@DBDE01.ent.ti.com>
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
On Tue, 2012-10-09 at 12:54 +0000, Hiremath, Vaibhav wrote:
> On Tue, Oct 09, 2012 at 18:00:25, Valkeinen, Tomi wrote:
> > 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.
> >
>
> Which baseline you are using? I tried it with linux-omap/master, patch[1/3] is failing -
It's based on omapdss master, which is what I've sent in the pull
request for 3.7.
> patching file arch/arm/plat-omap/include/plat/vrfb.h
> patching file drivers/media/video/omap/omap_vout.c
> Hunk #1 FAILED at 45.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_vout.c.rej
> patching file drivers/media/video/omap/omap_vout_vrfb.c
> Hunk #1 FAILED at 17.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_vout_vrfb.c.rej
> patching file drivers/media/video/omap/omap_voutdef.h
> Hunk #1 FAILED at 12.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/media/video/omap/omap_voutdef.h.rej
> patching file drivers/video/omap2/omapfb/omapfb-ioctl.c
> patching file drivers/video/omap2/omapfb/omapfb-main.c
> Hunk #1 succeeded at 33 with fuzz 2 (offset 1 line).
> patching file drivers/video/omap2/omapfb/omapfb-sysfs.c
> patching file drivers/video/omap2/vrfb.c
> patching file include/video/omapvrfb.h
>
>
>
> Note that, the directory structure has been changed in the mainline,
> Now V4L2 OMAP Display driver is in "drivers/media/platform/omap/"
>
> You have to rebase the patches and resend it.
Yep, I'll rebase it on top of 3.7-rc1 when that's out, so that Tony can
pull that branch into his tree also. I guess the omap_vout changes
should apply easily, as it's just include filename changes.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: omap DSS cmdline resolution not working for HDMI?
From: Tomi Valkeinen @ 2012-10-09 13:06 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-fbdev
In-Reply-To: <20121005164308.GM3874@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3489 bytes --]
On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote:
> Looks like somehow also output_size won't change when changing
> display output from DVI to HDMI.
>
> If I boot with DVI panel at 1600x1200, then try to switch to the
> HDMI monitor with the following script:
>
> #!/bin/sh
>
> export dvi=display0
> export hdmi=display1
> export overlay=overlay0
>
> echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
> echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
> echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
> echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
> echo tv > /sys/devices/platform/omapdss/$overlay/manager
> #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
> echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
> cat /sys/devices/platform/omapdss/$hdmi/timings
> cat /sys/devices/platform/omapdss/$overlay/output_size
>
> I get the following which may provide more clues:
>
> [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
> [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
> [64370.849670] omapdss HDMI error: failed to power on device
> [64370.855407] omapdss error: failed to power on
> [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
> [64370.880798] omapdss HDMI error: failed to power on device
> [64370.886505] omapdss error: failed to power on
> 85500,1366/70/213/143,768/3/24/3
> 1600,1200
Well, it's not that simple =). There are three things to consider:
- Framebuffer in the sdram. It has xres and yres parameters.
- Overlay, and it's input size (from fb) and output sizes (must fit into
the display).
- Display, which has certain size depending on video mode.
Only VID overlays can have different input and output sizes, GFX overlay
does not support scaling.
In the script above you don't change the fb at all. You can do that with
when the overlay is disabled, for example:
fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768
But that only works if there's enough memory allocated for the
framebuffer, but that is the case for you if the fb was bigger
initially. Otherwise you need to set the new size
with /sys/class/graphics/fb0/size before resizing the fb.
And, of course, the framebuffer cannot be in use at that time by, for
example, X.
Yes, it's complex! I hope omapdrm will make all things simple, and we
can forget omapfb. In hindsight, I should've designed omapfb to be much
simpler, and only use gfx overlay. Making it support all overlays is a
never ending source for problems and complexity.
> FYI, I'm also seeing the DVI monitor blank out on it's own for
> about a second or so on regular basis every 10 minutes or so.
> No idea what's causing that, maybe it's a reminder to take
> a short break :)
Well that's something different. I've recently done some testing with
using DSI PLL for generating pixel clock, and I've seen unstabilities
with that. But perhaps there's something else wrong also, even when
using the PRCM for pix clock as in your case.
Does your monitor ever report something like bad signal or such?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for fbdev
From: David Howells @ 2012-10-09 13:30 UTC (permalink / raw)
To: FlorianSchandinat; +Cc: dhowells, linux-fbdev, linux-kernel
Can you merge the following branch into the fbdev tree please.
This is to complete part of the Userspace API (UAPI) disintegration for which
the preparatory patches were pulled recently. After these patches, userspace
headers will be segregated into:
include/uapi/linux/.../foo.h
for the userspace interface stuff, and:
include/linux/.../foo.h
for the strictly kernel internal stuff.
---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-fbdev-20121009
for you to fetch changes up to c86cba891a10fdc9c2218973435d0b7d0f9f5cf0:
UAPI: (Scripted) Disintegrate include/video (2012-10-09 11:15:01 +0100)
----------------------------------------------------------------
(from the branch description for disintegrate-fbdev local branch)
clone of "disintegrate-media"
UAPI Disintegration 2012-10-09
----------------------------------------------------------------
David Howells (1):
UAPI: (Scripted) Disintegrate include/video
include/uapi/video/Kbuild | 3 +
include/uapi/video/edid.h | 9 ++
include/uapi/video/sisfb.h | 209 +++++++++++++++++++++++++++++++++++++++++++
include/uapi/video/uvesafb.h | 60 +++++++++++++
include/video/Kbuild | 3 -
include/video/edid.h | 7 +-
include/video/sisfb.h | 189 +-------------------------------------
include/video/uvesafb.h | 58 +-----------
8 files changed, 284 insertions(+), 254 deletions(-)
create mode 100644 include/uapi/video/edid.h
create mode 100644 include/uapi/video/sisfb.h
create mode 100644 include/uapi/video/uvesafb.h
.
^ permalink raw reply
* [PATCH V4 0/2] video: exynos_dp: Add device tree support to DP driver
From: Ajay Kumar @ 2012-10-09 14:04 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev, jg1.han, devicetree-discuss
Cc: FlorianSchandinat, sylvester.nawrocki, tomasz.figa, thomas.ab
Changes from V3:
--Fix typos in the documentation file "exynos_dp.txt".
--Use variable name enable_mask instead of enable_bit.
--Use property name samsung,dp_phy instead of dp-phy.
To linux-fbdev:
[PATCH V4 1/2] video: exynos_dp: Add device tree support to DP driver
To devicetree discussion list:
[PATCH V4 2/2] video: exynos_dp: device tree documentation
.../devicetree/bindings/video/exynos_dp.txt | 81 ++++++++++
drivers/video/exynos/exynos_dp_core.c | 168 ++++++++++++++++++--
drivers/video/exynos/exynos_dp_core.h | 2 +
3 files changed, 239 insertions(+), 14 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
^ permalink raw reply
* [PATCH V4 1/2] video: exynos_dp: Add device tree support to DP driver
From: Ajay Kumar @ 2012-10-09 14:04 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev, jg1.han, devicetree-discuss
Cc: FlorianSchandinat, sylvester.nawrocki, tomasz.figa, thomas.ab
In-Reply-To: <1349824101-32574-1-git-send-email-ajaykumar.rs@samsung.com>
This patch enables device tree based discovery support for DP driver.
The driver is modified to handle platform data in both the cases:
with DT and non-DT.
DP-PHY should be regarded as a seperate device node while
being passed from device tree list, and device node for
DP should contain DP-PHY as child node with property name
"samsung,dp_phy" associated with it.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
drivers/video/exynos/exynos_dp_core.c | 168 ++++++++++++++++++++++++++++++---
drivers/video/exynos/exynos_dp_core.h | 2 +
2 files changed, 156 insertions(+), 14 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
index cdc1398..74f18f2 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
#include <linux/io.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <linux/of.h>
#include <video/exynos_dp.h>
@@ -856,6 +857,106 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void *arg)
return IRQ_HANDLED;
}
+#ifdef CONFIG_OF
+struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
+{
+ struct device_node *dp_node = dev->of_node;
+ struct exynos_dp_platdata *pd;
+ struct video_info *dp_video_config;
+
+ pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_err(dev, "memory allocation for pdata failed\n");
+ return ERR_PTR(-ENOMEM);
+ }
+ dp_video_config = devm_kzalloc(dev,
+ sizeof(*dp_video_config), GFP_KERNEL);
+
+ if (!dp_video_config) {
+ dev_err(dev, "memory allocation for video config failed\n");
+ return ERR_PTR(-ENOMEM);
+ }
+ pd->video_info = dp_video_config;
+
+ if (of_get_property(dp_node, "samsung,h-sync-polarity", NULL))
+ dp_video_config->h_sync_polarity = 1;
+
+ if (of_get_property(dp_node, "samsung,v-sync-polarity", NULL))
+ dp_video_config->v_sync_polarity = 1;
+
+ if (of_get_property(dp_node, "samsung,interlaced", NULL))
+ dp_video_config->interlaced = 1;
+
+ of_property_read_u32(dp_node, "samsung,color_space",
+ &dp_video_config->color_space);
+
+ of_property_read_u32(dp_node, "samsung,dynamic_range",
+ &dp_video_config->dynamic_range);
+
+ of_property_read_u32(dp_node, "samsung,ycbcr_coeff",
+ &dp_video_config->ycbcr_coeff);
+
+ of_property_read_u32(dp_node, "samsung,color_depth",
+ &dp_video_config->color_depth);
+
+ of_property_read_u32(dp_node, "samsung,link_rate",
+ &dp_video_config->link_rate);
+
+ of_property_read_u32(dp_node, "samsung,lane_count",
+ &dp_video_config->lane_count);
+ return pd;
+}
+
+void exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
+{
+ struct device_node *dp_phy_node;
+ const __be32 *parp;
+ u32 phy_base;
+ void *virt_phy_base;
+
+ parp = of_get_property(dp->dev->of_node, "samsung,dp_phy", NULL);
+ if (!parp) {
+ dp->dp_phy_addr = NULL;
+ return;
+ }
+
+ dp_phy_node = of_find_node_by_phandle(be32_to_cpup(parp));
+ if (!dp_phy_node) {
+ dp->dp_phy_addr = NULL;
+ return;
+ }
+
+ of_property_read_u32(dp_phy_node, "samsung,dptx_phy_reg", &phy_base);
+ of_property_read_u32(dp_phy_node, "samsung,enable_mask",
+ &dp->enable_mask);
+ virt_phy_base = ioremap(phy_base, SZ_4);
+ if (!virt_phy_base) {
+ dev_err(dp->dev, "failed to ioremap dp-phy\n");
+ dp->dp_phy_addr = NULL;
+ return;
+ }
+ dp->dp_phy_addr = virt_phy_base;
+}
+
+void exynos_dp_phy_init(struct exynos_dp_device *dp)
+{
+ u32 reg;
+
+ reg = __raw_readl(dp->dp_phy_addr);
+ reg |= dp->enable_mask;
+ __raw_writel(reg, dp->dp_phy_addr);
+}
+
+void exynos_dp_phy_exit(struct exynos_dp_device *dp)
+{
+ u32 reg;
+
+ reg = __raw_readl(dp->dp_phy_addr);
+ reg &= ~(dp->enable_mask);
+ __raw_writel(reg, dp->dp_phy_addr);
+}
+#endif /* CONFIG_OF */
+
static int __devinit exynos_dp_probe(struct platform_device *pdev)
{
struct resource *res;
@@ -864,12 +965,6 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
int ret = 0;
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev, "no platform data\n");
- return -EINVAL;
- }
-
dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
if (!dp) {
@@ -879,6 +974,21 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
dp->dev = &pdev->dev;
+ if (pdev->dev.of_node) {
+ pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
+
+ exynos_dp_dt_parse_phydata(dp);
+ } else {
+ pdata = pdev->dev.platform_data;
+ }
+
+ if (!pdata) {
+ dev_err(&pdev->dev, "no platform data\n");
+ return -EINVAL;
+ }
+
dp->clock = devm_clk_get(&pdev->dev, "dp");
if (IS_ERR(dp->clock)) {
dev_err(&pdev->dev, "failed to get clock\n");
@@ -909,8 +1019,14 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
}
dp->video_info = pdata->video_info;
- if (pdata->phy_init)
- pdata->phy_init();
+
+ if (pdev->dev.of_node) {
+ if (dp->dp_phy_addr)
+ exynos_dp_phy_init(dp);
+ } else {
+ if (pdata->phy_init)
+ pdata->phy_init();
+ }
exynos_dp_init_dp(dp);
@@ -953,8 +1069,13 @@ static int __devexit exynos_dp_remove(struct platform_device *pdev)
struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
struct exynos_dp_device *dp = platform_get_drvdata(pdev);
- if (pdata && pdata->phy_exit)
- pdata->phy_exit();
+ if (pdev->dev.of_node) {
+ if (dp->dp_phy_addr)
+ exynos_dp_phy_exit(dp);
+ } else {
+ if (pdata && pdata->phy_exit)
+ pdata->phy_exit();
+ }
clk_disable(dp->clock);
@@ -968,8 +1089,13 @@ static int exynos_dp_suspend(struct device *dev)
struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
struct exynos_dp_device *dp = platform_get_drvdata(pdev);
- if (pdata && pdata->phy_exit)
- pdata->phy_exit();
+ if (dev->of_node) {
+ if (dp->dp_phy_addr)
+ exynos_dp_phy_exit(dp);
+ } else {
+ if (pdata && pdata->phy_exit)
+ pdata->phy_exit();
+ }
clk_disable(dp->clock);
@@ -982,8 +1108,13 @@ static int exynos_dp_resume(struct device *dev)
struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
struct exynos_dp_device *dp = platform_get_drvdata(pdev);
- if (pdata && pdata->phy_init)
- pdata->phy_init();
+ if (dev->of_node) {
+ if (dp->dp_phy_addr)
+ exynos_dp_phy_init(dp);
+ } else {
+ if (pdata && pdata->phy_init)
+ pdata->phy_init();
+ }
clk_enable(dp->clock);
@@ -1013,6 +1144,14 @@ static const struct dev_pm_ops exynos_dp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(exynos_dp_suspend, exynos_dp_resume)
};
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_dp_match[] = {
+ { .compatible = "samsung,exynos5-dp" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_dp_match);
+#endif
+
static struct platform_driver exynos_dp_driver = {
.probe = exynos_dp_probe,
.remove = __devexit_p(exynos_dp_remove),
@@ -1020,6 +1159,7 @@ static struct platform_driver exynos_dp_driver = {
.name = "exynos-dp",
.owner = THIS_MODULE,
.pm = &exynos_dp_pm_ops,
+ .of_match_table = of_match_ptr(exynos_dp_match),
},
};
diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
index 57b8a65..569858b 100644
--- a/drivers/video/exynos/exynos_dp_core.h
+++ b/drivers/video/exynos/exynos_dp_core.h
@@ -29,6 +29,8 @@ struct exynos_dp_device {
struct clk *clock;
unsigned int irq;
void __iomem *reg_base;
+ void __iomem *dp_phy_addr;
+ unsigned int enable_mask;
struct video_info *video_info;
struct link_train link_train;
--
1.7.0.4
^ permalink raw reply related
* [PATCH V4 2/2] video: exynos_dp: device tree documentation
From: Ajay Kumar @ 2012-10-09 14:05 UTC (permalink / raw)
To: linux-samsung-soc, linux-fbdev, jg1.han, devicetree-discuss
Cc: FlorianSchandinat, sylvester.nawrocki, tomasz.figa, thomas.ab
In-Reply-To: <1349824101-32574-1-git-send-email-ajaykumar.rs@samsung.com>
Add documentation for the DT bindings in exynos display port driver.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
---
.../devicetree/bindings/video/exynos_dp.txt | 83 ++++++++++++++++++++
1 files changed, 83 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
new file mode 100644
index 0000000..a021963
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -0,0 +1,83 @@
+Exynos display port driver should configure the display port interface
+based on the type of panel connected to it.
+
+We use two nodes:
+ -dptx_phy node
+ -display-port-controller node
+
+For the dp-phy initialization, we use a dptx_phy node.
+Required properties for dptx_phy:
+ -compatible:
+ Should be "samsung,dp-phy".
+ -samsung,dptx_phy_reg:
+ Base address of DP PHY register.
+ -samsung,enable_mask:
+ The bit-mask used to enable/disable DP PHY.
+
+For the Panel initialization, we read data from display-port-controller node.
+Required properties for display-port-controller:
+ -compatible:
+ Should be "samsung,exynos5-dp".
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ Interrupt combiner values.
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -samsung,dp_phy:
+ phandle to dptx_phy node.
+ -samsung,color_space:
+ input video data format.
+ COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
+ -samsung,dynamic_range:
+ dynamic range for input video data.
+ VESA = 0, CEA = 1
+ -samsung,ycbcr_coeff:
+ YCbCr co-efficients for input video.
+ COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
+ -samsung,color_depth:
+ Number of bits per colour component.
+ COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
+ -samsung,link_rate:
+ link rate supported by the panel.
+ LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
+ -samsung,lane_count:
+ number of lanes supported by the panel.
+ LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
+ -samsung,interlaced:
+ Interlace scan mode.
+ Progressive if defined, Interlaced if not defined
+ -samsung,v_sync_polarity:
+ VSYNC polarity configuration.
+ High if defined, Low if not defined
+ -samsung,h_sync_polarity:
+ HSYNC polarity configuration.
+ High if defined, Low if not defined
+
+Example:
+
+SOC specific portion:
+ dptx_phy: dptx_phy@0x10040720 {
+ compatible = "samsung,dp-phy";
+ samsung,dptx_phy_reg = <0x10040720>;
+ samsung,enable_mask = <1>;
+ };
+
+ display-port-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145B0000 0x10000>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ samsung,dp_phy = <&dptx_phy>;
+ };
+
+Board Specific portion:
+ display-port-controller {
+ samsung,color_space = <0>;
+ samsung,dynamic_range = <0>;
+ samsung,ycbcr_coeff = <0>;
+ samsung,color_depth = <1>;
+ samsung,link_rate = <0x0a>;
+ samsung,lane_count = <2>;
+ };
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 0/8] ARM: mostly harmless gcc warnings
From: Arnd Bergmann @ 2012-10-09 20:13 UTC (permalink / raw)
To: linux-arm-kernel
Most patches from the first time this was posted have been
adopted by a subsystem maintainer or were show to be obsolete.
Here are the remaining ones again.
I'm planning to submit those patches that are still necessary
by the time we have an -rc1 through the arm-soc tree, but
my preference is still to have them go through the subsystem
maintainers.
Olof: should we add it to for-next?
Arnd
Arnd Bergmann (8):
SCSI: ARM: ncr5380/oak uses no interrupts
SCSI: ARM: make fas216_dumpinfo function conditional
mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN
USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit
clk: don't mark clkdev_add_table as init
pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops
video: mark nuc900fb_map_video_memory as __devinit
spi/s3c64xx: use correct dma_transfer_direction type
drivers/clk/clkdev.c | 2 +-
drivers/pcmcia/pxa2xx_sharpsl.c | 2 +-
drivers/scsi/arm/fas216.c | 2 +-
drivers/scsi/arm/oak.c | 1 +
drivers/spi/spi-s3c64xx.c | 2 +-
drivers/usb/host/ehci-orion.c | 2 +-
drivers/video/nuc900fb.c | 2 +-
mm/slob.c | 6 +++---
8 files changed, 10 insertions(+), 9 deletions(-)
--
1.7.10
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jochen Friedrich <jochen@scram.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Pavel Machek <pavel@suse.cz>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-pcmcia@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: spi-devel-general@lists.sourceforge.net
Cc: stable@vger.kernel.org
^ permalink raw reply
* [PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit
From: Arnd Bergmann @ 2012-10-09 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349813638-4617-1-git-send-email-arnd@arndb.de>
nuc900fb_map_video_memory is called by an devinit function
that may be called at run-time, but the function itself is
marked __init and will be discarded after boot.
To avoid calling into a function that may have been overwritten,
mark nuc900fb_map_video_memory itself as __devinit.
Without this patch, building nuc950_defconfig results in:
WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
The function __devinit nuc900fb_probe() references
a function __init nuc900fb_map_video_memory().
If nuc900fb_map_video_memory is only used by nuc900fb_probe then
annotate nuc900fb_map_video_memory with a matching annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/nuc900fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
index e10f551..b31b12b 100644
--- a/drivers/video/nuc900fb.c
+++ b/drivers/video/nuc900fb.c
@@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
* The buffer should be a non-cached, non-buffered, memory region
* to allow palette and pixel writes without flushing the cache.
*/
-static int __init nuc900fb_map_video_memory(struct fb_info *info)
+static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
{
struct nuc900fb_info *fbi = info->par;
dma_addr_t map_dma;
--
1.7.10
^ permalink raw reply related
* Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
From: Kevin Hilman @ 2012-10-09 20:37 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Tony Lindgren, Archit Taneja
In-Reply-To: <1349785827-27055-2-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
Tomi Valkeinen <tomi.valkeinen@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.valkeinen@ti.com>
> Cc: Tony Lindgren <tony@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
^ permalink raw reply
* Re: [PATCH V4 2/2] video: exynos_dp: device tree documentation
From: Sylwester Nawrocki @ 2012-10-09 21:29 UTC (permalink / raw)
To: Ajay Kumar
Cc: linux-samsung-soc, linux-fbdev, jg1.han, devicetree-discuss,
FlorianSchandinat, sylvester.nawrocki, tomasz.figa, thomas.ab
In-Reply-To: <1349824101-32574-3-git-send-email-ajaykumar.rs@samsung.com>
Hi Ajay,
On 10/10/2012 01:08 AM, Ajay Kumar wrote:
> Add documentation for the DT bindings in exynos display port driver.
>
> Signed-off-by: Ajay Kumar<ajaykumar.rs@samsung.com>
> ---
> .../devicetree/bindings/video/exynos_dp.txt | 83 ++++++++++++++++++++
> 1 files changed, 83 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
> new file mode 100644
> index 0000000..a021963
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -0,0 +1,83 @@
> +Exynos display port driver should configure the display port interface
> +based on the type of panel connected to it.
The bindings are supposed to describe devices, not drivers. So it
might be better to say:
"The Exynos display port interface should be configured based on the
type of panel connected to it."
From this documentation it is not clear which properties are required
and which are optional for each node.
I think, in the property names dashes should be used, rather than
underscores. Dashes are much more common among existing bindings.
> +We use two nodes:
> + -dptx_phy node
> + -display-port-controller node
> +
> +For the dp-phy initialization, we use a dptx_phy node.
> +Required properties for dptx_phy:
> + -compatible:
> + Should be "samsung,dp-phy".
Is there a separate dptx-phy driver that is being matched with this
compatible property ? Is the dptx-node going to be referenced by other
nodes than display-port-controller ? If not, then you could likely drop
the compatible property entirely and make the dptx-phy node a child
node of display-port-controller, i.e.
display-port-controller {
compatible = "samsung,exynos5-dp";
reg = <0x145b0000 0x10000>;
interrupts =<10 3>;
interrupt-parent =<&combiner>;
dptx-phy {
reg = <0x10040720>;
samsung,enable_mask = <1>;
};
};
Then the driver could just look for a child node named "dptx-phy" with
e.g. of_find_node_by_name().
> + -samsung,dptx_phy_reg:
I think it's fine to use just 'reg' instead of this vendor specific name.
> + Base address of DP PHY register.
> + -samsung,enable_mask:
> + The bit-mask used to enable/disable DP PHY.
> +
> +For the Panel initialization, we read data from display-port-controller node.
> +Required properties for display-port-controller:
> + -compatible:
> + Should be "samsung,exynos5-dp".
> + -reg:
> + physical base address of the controller and length
> + of memory mapped region.
> + -interrupts:
> + Interrupt combiner values.
> + -interrupt-parent:
> + phandle to Interrupt combiner node.
> + -samsung,dp_phy:
> + phandle to dptx_phy node.
> + -samsung,color_space:
> + input video data format.
> + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
> + -samsung,dynamic_range:
> + dynamic range for input video data.
> + VESA = 0, CEA = 1
> + -samsung,ycbcr_coeff:
> + YCbCr co-efficients for input video.
> + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> + -samsung,color_depth:
> + Number of bits per colour component.
> + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> + -samsung,link_rate:
> + link rate supported by the panel.
> + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
> + -samsung,lane_count:
> + number of lanes supported by the panel.
> + LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> + -samsung,interlaced:
> + Interlace scan mode.
> + Progressive if defined, Interlaced if not defined
> + -samsung,v_sync_polarity:
> + VSYNC polarity configuration.
> + High if defined, Low if not defined
> + -samsung,h_sync_polarity:
> + HSYNC polarity configuration.
> + High if defined, Low if not defined
So there is no common video bindings for things like these two ?
In V4L2 we decided to use vsync-active, hsync-active [1], the video
timings bindings [2] use hsync-active-high, hsync-active-high boolean
properties. Perhaps it is worth to pick some of those standard
definitions and use instead of the vendor specific ones ?
> +
> +Example:
> +
> +SOC specific portion:
> + dptx_phy: dptx_phy@0x10040720 {
> + compatible = "samsung,dp-phy";
> + samsung,dptx_phy_reg =<0x10040720>;
reg = <0x10040720>;
> + samsung,enable_mask =<1>;
> + };
> +
> + display-port-controller {
> + compatible = "samsung,exynos5-dp";
> + reg =<0x145B0000 0x10000>;
I think lower case is preferred.
> + interrupts =<10 3>;
> + interrupt-parent =<&combiner>;
> + samsung,dp_phy =<&dptx_phy>;
> + };
> +
> +Board Specific portion:
> + display-port-controller {
> + samsung,color_space =<0>;
> + samsung,dynamic_range =<0>;
> + samsung,ycbcr_coeff =<0>;
> + samsung,color_depth =<1>;
> + samsung,link_rate =<0x0a>;
> + samsung,lane_count =<2>;
> + };
Thanks,
Sylwester
[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg52743.html
[2] http://www.mail-archive.com/linux-media@vger.kernel.org/msg53323.html
^ permalink raw reply
* Re: omap DSS cmdline resolution not working for HDMI?
From: Tony Lindgren @ 2012-10-09 21:54 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1349788010.2409.38.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121009 06:08]:
> On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote:
>
> > Looks like somehow also output_size won't change when changing
> > display output from DVI to HDMI.
> >
> > If I boot with DVI panel at 1600x1200, then try to switch to the
> > HDMI monitor with the following script:
> >
> > #!/bin/sh
> >
> > export dvi=display0
> > export hdmi=display1
> > export overlay=overlay0
> >
> > echo 0 > /sys/devices/platform/omapdss/$dvi/enabled
> > echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled
> > echo "85500,1366/70/213/143,768/3/24/3" > /sys/devices/platform/omapdss/$hdmi/timings
> > echo 0 > /sys/devices/platform/omapdss/$overlay/enabled
> > echo tv > /sys/devices/platform/omapdss/$overlay/manager
> > #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size
> > echo 1 > /sys/devices/platform/omapdss/$overlay/enabled
> > cat /sys/devices/platform/omapdss/$hdmi/timings
> > cat /sys/devices/platform/omapdss/$overlay/output_size
> >
> > I get the following which may provide more clues:
> >
> > [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays dd
> > [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> > [64370.840972] omapdss APPLY error: failed to enable manager 1: check_settings failed
> > [64370.849670] omapdss HDMI error: failed to power on device
> > [64370.855407] omapdss error: failed to power on
> > [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the display area (0 + 1600 >= 13)
> > [64370.872436] omapdss APPLY error: failed to enable manager 1: check_settings failed
> > [64370.880798] omapdss HDMI error: failed to power on device
> > [64370.886505] omapdss error: failed to power on
> > 85500,1366/70/213/143,768/3/24/3
> > 1600,1200
>
> Well, it's not that simple =). There are three things to consider:
>
> - Framebuffer in the sdram. It has xres and yres parameters.
> - Overlay, and it's input size (from fb) and output sizes (must fit into
> the display).
> - Display, which has certain size depending on video mode.
>
> Only VID overlays can have different input and output sizes, GFX overlay
> does not support scaling.
>
> In the script above you don't change the fb at all. You can do that with
> when the overlay is disabled, for example:
>
> fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768
>
> But that only works if there's enough memory allocated for the
> framebuffer, but that is the case for you if the fb was bigger
> initially. Otherwise you need to set the new size
> with /sys/class/graphics/fb0/size before resizing the fb.
>
> And, of course, the framebuffer cannot be in use at that time by, for
> example, X.
Thanks for the explanation, I'll give that a try at some point.
> Yes, it's complex! I hope omapdrm will make all things simple, and we
> can forget omapfb. In hindsight, I should've designed omapfb to be much
> simpler, and only use gfx overlay. Making it support all overlays is a
> never ending source for problems and complexity.
Heh oh well it works reasonably for most cases I guess.
> > FYI, I'm also seeing the DVI monitor blank out on it's own for
> > about a second or so on regular basis every 10 minutes or so.
> > No idea what's causing that, maybe it's a reminder to take
> > a short break :)
>
> Well that's something different. I've recently done some testing with
> using DSI PLL for generating pixel clock, and I've seen unstabilities
> with that. But perhaps there's something else wrong also, even when
> using the PRCM for pix clock as in your case.
>
> Does your monitor ever report something like bad signal or such?
Yes I've seen that too, but that seems to be different issue and
I may have passed wrong timings in that case.
I guess the random blanking for a second or so could also be
an occastional bad timing. No warnings in that case on the monitor
though.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2 7/8] video: mark nuc900fb_map_video_memory as __devinit
From: Wan ZongShun @ 2012-10-10 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349813638-4617-8-git-send-email-arnd@arndb.de>
2012/10/10 Arnd Bergmann <arnd@arndb.de>:
> nuc900fb_map_video_memory is called by an devinit function
> that may be called at run-time, but the function itself is
> marked __init and will be discarded after boot.
>
> To avoid calling into a function that may have been overwritten,
> mark nuc900fb_map_video_memory itself as __devinit.
>
> Without this patch, building nuc950_defconfig results in:
>
> WARNING: drivers/video/built-in.o(.devinit.text+0x26c): Section mismatch in reference from the function nuc900fb_probe() to the function .init.text:nuc900fb_map_video_memory()
> The function __devinit nuc900fb_probe() references
> a function __init nuc900fb_map_video_memory().
> If nuc900fb_map_video_memory is only used by nuc900fb_probe then
> annotate nuc900fb_map_video_memory with a matching annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Wan ZongShun <mcuos.com@gmail.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
Thanks for your patch.
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
> ---
> drivers/video/nuc900fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/nuc900fb.c b/drivers/video/nuc900fb.c
> index e10f551..b31b12b 100644
> --- a/drivers/video/nuc900fb.c
> +++ b/drivers/video/nuc900fb.c
> @@ -387,7 +387,7 @@ static int nuc900fb_init_registers(struct fb_info *info)
> * The buffer should be a non-cached, non-buffered, memory region
> * to allow palette and pixel writes without flushing the cache.
> */
> -static int __init nuc900fb_map_video_memory(struct fb_info *info)
> +static int __devinit nuc900fb_map_video_memory(struct fb_info *info)
> {
> struct nuc900fb_info *fbi = info->par;
> dma_addr_t map_dma;
> --
> 1.7.10
>
--
Wan ZongShun.
www.mcuos.com
^ permalink raw reply
* Re: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
From: Tomi Valkeinen @ 2012-10-10 4:07 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-fbdev, Tony Lindgren, Archit Taneja
In-Reply-To: <87fw5n1iwh.fsf@deeprootsystems.com>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote:
> Hi Tomi,
>
> Tomi Valkeinen <tomi.valkeinen@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.valkeinen@ti.com>
> > Cc: Tony Lindgren <tony@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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] matroxfb: Convert struct i2c_msg initialization to C99 format
From: Jean Delvare @ 2012-10-10 9:05 UTC (permalink / raw)
To: Shubhrajyoti D
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, FlorianSchandinat-Mmb7MZpHnFY,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1349782668-9098-1-git-send-email-shubhrajyoti-l0cyMroinI0@public.gmane.org>
On Tue, 9 Oct 2012 17:07:48 +0530, Shubhrajyoti D wrote:
> Convert the struct i2c_msg initialization to C99 format. This makes
> maintaining and editing the code simpler. Also helps once other fields
> like transferred are added in future.
>
> Thanks to Julia Lawall <julia.lawall@lip6.fr> for automating the conversion
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> drivers/video/matrox/matroxfb_maven.c | 15 +++++++++++++--
> 1 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/matrox/matroxfb_maven.c b/drivers/video/matrox/matroxfb_maven.c
> index 217678e..fb5c123 100644
> --- a/drivers/video/matrox/matroxfb_maven.c
> +++ b/drivers/video/matrox/matroxfb_maven.c
> @@ -137,8 +137,19 @@ static int* get_ctrl_ptr(struct maven_data* md, int idx) {
>
> static int maven_get_reg(struct i2c_client* c, char reg) {
> char dst;
> - struct i2c_msg msgs[] = {{ c->addr, I2C_M_REV_DIR_ADDR, sizeof(reg), ® },
> - { c->addr, I2C_M_RD | I2C_M_NOSTART, sizeof(dst), &dst }};
> + struct i2c_msg msgs[] = {{
> + .addr = c->addr,
> + .flags = I2C_M_REV_DIR_ADDR,
> + .len = sizeof(reg),
> + .buf = ®
> + },
> + {
> + .addr = c->addr,
> + .flags = I2C_M_RD | I2C_M_NOSTART,
> + .len = sizeof(dst),
> + .buf = &dst
> + }
I'd prefer clean indentation as you have in the previous patches.
> + };
> s32 err;
>
> err = i2c_transfer(c->adapter, msgs, 2);
Acked-by: Jean Delvare <khali@linux-fr.org>
--
Jean Delvare
^ permalink raw reply
* [PATCH V5 4/5] OMAPDSS: Replace multi part debug prints with pr_debug
From: Chandrabhanu Mahapatra @ 2012-10-10 9:34 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <8fb0b3848f5d6148889f2b5160b8aa40e764f409.1348914940.git.cmahapatra@ti.com>
The various functions in dispc and dsi such as print_irq_status(),
print_irq_status_vc(), print_irq_status_cio() and _dsi_print_reset_status()
consist of a number of debug prints which need to be enabled all at once or none
at all. So, these debug prints in corresponding functions are replaced with one
dynamic debug enabled pr_debug() each.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
Changes from V4 to V5:
* replaced prints in dsi functions print_irq_status, print_irq_status_vc() and
print_irq_status_cio() with single pr_debug()
* replaced macro VERBOSE_IRQ with static variable verbose_irq
drivers/video/omap2/dss/dispc.c | 32 +++-----
drivers/video/omap2/dss/dsi.c | 168 ++++++++++++++++++---------------------
2 files changed, 90 insertions(+), 110 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index a173a94..67d9f3b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3675,26 +3675,20 @@ static void print_irq_status(u32 status)
if ((status & dispc.irq_error_mask) = 0)
return;
- printk(KERN_DEBUG "DISPC IRQ: 0x%x: ", status);
-
-#define PIS(x) \
- if (status & DISPC_IRQ_##x) \
- printk(#x " ");
- PIS(GFX_FIFO_UNDERFLOW);
- PIS(OCP_ERR);
- PIS(VID1_FIFO_UNDERFLOW);
- PIS(VID2_FIFO_UNDERFLOW);
- if (dss_feat_get_num_ovls() > 3)
- PIS(VID3_FIFO_UNDERFLOW);
- PIS(SYNC_LOST);
- PIS(SYNC_LOST_DIGIT);
- if (dss_has_feature(FEAT_MGR_LCD2))
- PIS(SYNC_LOST2);
- if (dss_has_feature(FEAT_MGR_LCD3))
- PIS(SYNC_LOST3);
+#define PIS(x) (status & DISPC_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DISPC IRQ: 0x%x: %s%s%s%s%s%s%s%s%s\n",
+ status,
+ PIS(OCP_ERR),
+ PIS(GFX_FIFO_UNDERFLOW),
+ PIS(VID1_FIFO_UNDERFLOW),
+ PIS(VID2_FIFO_UNDERFLOW),
+ dss_feat_get_num_ovls() > 3 ? PIS(VID3_FIFO_UNDERFLOW) : "",
+ PIS(SYNC_LOST),
+ PIS(SYNC_LOST_DIGIT),
+ dss_has_feature(FEAT_MGR_LCD2) ? PIS(SYNC_LOST2) : "",
+ dss_has_feature(FEAT_MGR_LCD3) ? PIS(SYNC_LOST3) : "");
#undef PIS
-
- printk("\n");
}
#endif
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b0345f3..19daee9 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -45,7 +45,6 @@
#include "dss.h"
#include "dss_features.h"
-/*#define VERBOSE_IRQ*/
#define DSI_CATCH_MISSING_TE
struct dsi_reg { u16 idx; };
@@ -526,42 +525,38 @@ static inline void dsi_perf_show(struct platform_device *dsidev,
}
#endif
+static int verbose_irq;
+
static void print_irq_status(u32 status)
{
if (status = 0)
return;
-#ifndef VERBOSE_IRQ
- if ((status & ~DSI_IRQ_CHANNEL_MASK) = 0)
+ if (!verbose_irq && (status & ~DSI_IRQ_CHANNEL_MASK) = 0)
return;
-#endif
- printk(KERN_DEBUG "DSI IRQ: 0x%x: ", status);
-#define PIS(x) \
- if (status & DSI_IRQ_##x) \
- printk(#x " ");
-#ifdef VERBOSE_IRQ
- PIS(VC0);
- PIS(VC1);
- PIS(VC2);
- PIS(VC3);
-#endif
- PIS(WAKEUP);
- PIS(RESYNC);
- PIS(PLL_LOCK);
- PIS(PLL_UNLOCK);
- PIS(PLL_RECALL);
- PIS(COMPLEXIO_ERR);
- PIS(HS_TX_TIMEOUT);
- PIS(LP_RX_TIMEOUT);
- PIS(TE_TRIGGER);
- PIS(ACK_TRIGGER);
- PIS(SYNC_LOST);
- PIS(LDO_POWER_GOOD);
- PIS(TA_TIMEOUT);
+#define PIS(x) (status & DSI_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DSI IRQ: 0x%x: %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ status,
+ verbose_irq ? PIS(VC0) : "",
+ verbose_irq ? PIS(VC1) : "",
+ verbose_irq ? PIS(VC2) : "",
+ verbose_irq ? PIS(VC3) : "",
+ PIS(WAKEUP),
+ PIS(RESYNC),
+ PIS(PLL_LOCK),
+ PIS(PLL_UNLOCK),
+ PIS(PLL_RECALL),
+ PIS(COMPLEXIO_ERR),
+ PIS(HS_TX_TIMEOUT),
+ PIS(LP_RX_TIMEOUT),
+ PIS(TE_TRIGGER),
+ PIS(ACK_TRIGGER),
+ PIS(SYNC_LOST),
+ PIS(LDO_POWER_GOOD),
+ PIS(TA_TIMEOUT));
#undef PIS
-
- printk("\n");
}
static void print_irq_status_vc(int channel, u32 status)
@@ -569,28 +564,24 @@ static void print_irq_status_vc(int channel, u32 status)
if (status = 0)
return;
-#ifndef VERBOSE_IRQ
- if ((status & ~DSI_VC_IRQ_PACKET_SENT) = 0)
+ if (!verbose_irq && (status & ~DSI_VC_IRQ_PACKET_SENT) = 0)
return;
-#endif
- printk(KERN_DEBUG "DSI VC(%d) IRQ 0x%x: ", channel, status);
-#define PIS(x) \
- if (status & DSI_VC_IRQ_##x) \
- printk(#x " ");
- PIS(CS);
- PIS(ECC_CORR);
-#ifdef VERBOSE_IRQ
- PIS(PACKET_SENT);
-#endif
- PIS(FIFO_TX_OVF);
- PIS(FIFO_RX_OVF);
- PIS(BTA);
- PIS(ECC_NO_CORR);
- PIS(FIFO_TX_UDF);
- PIS(PP_BUSY_CHANGE);
+#define PIS(x) (status & DSI_VC_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DSI VC(%d) IRQ 0x%x: %s%s%s%s%s%s%s%s%s\n",
+ channel,
+ status,
+ PIS(CS),
+ PIS(ECC_CORR),
+ PIS(ECC_NO_CORR),
+ verbose_irq ? PIS(PACKET_SENT) : "",
+ PIS(BTA),
+ PIS(FIFO_TX_OVF),
+ PIS(FIFO_RX_OVF),
+ PIS(FIFO_TX_UDF),
+ PIS(PP_BUSY_CHANGE));
#undef PIS
- printk("\n");
}
static void print_irq_status_cio(u32 status)
@@ -598,34 +589,31 @@ static void print_irq_status_cio(u32 status)
if (status = 0)
return;
- printk(KERN_DEBUG "DSI CIO IRQ 0x%x: ", status);
-
-#define PIS(x) \
- if (status & DSI_CIO_IRQ_##x) \
- printk(#x " ");
- PIS(ERRSYNCESC1);
- PIS(ERRSYNCESC2);
- PIS(ERRSYNCESC3);
- PIS(ERRESC1);
- PIS(ERRESC2);
- PIS(ERRESC3);
- PIS(ERRCONTROL1);
- PIS(ERRCONTROL2);
- PIS(ERRCONTROL3);
- PIS(STATEULPS1);
- PIS(STATEULPS2);
- PIS(STATEULPS3);
- PIS(ERRCONTENTIONLP0_1);
- PIS(ERRCONTENTIONLP1_1);
- PIS(ERRCONTENTIONLP0_2);
- PIS(ERRCONTENTIONLP1_2);
- PIS(ERRCONTENTIONLP0_3);
- PIS(ERRCONTENTIONLP1_3);
- PIS(ULPSACTIVENOT_ALL0);
- PIS(ULPSACTIVENOT_ALL1);
+#define PIS(x) (status & DSI_CIO_IRQ_##x) ? (#x " ") : ""
+
+ pr_debug("DSI CIO IRQ 0x%x: %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ status,
+ PIS(ERRSYNCESC1),
+ PIS(ERRSYNCESC2),
+ PIS(ERRSYNCESC3),
+ PIS(ERRESC1),
+ PIS(ERRESC2),
+ PIS(ERRESC3),
+ PIS(ERRCONTROL1),
+ PIS(ERRCONTROL2),
+ PIS(ERRCONTROL3),
+ PIS(STATEULPS1),
+ PIS(STATEULPS2),
+ PIS(STATEULPS3),
+ PIS(ERRCONTENTIONLP0_1),
+ PIS(ERRCONTENTIONLP1_1),
+ PIS(ERRCONTENTIONLP0_2),
+ PIS(ERRCONTENTIONLP1_2),
+ PIS(ERRCONTENTIONLP0_3),
+ PIS(ERRCONTENTIONLP1_3),
+ PIS(ULPSACTIVENOT_ALL0),
+ PIS(ULPSACTIVENOT_ALL1));
#undef PIS
-
- printk("\n");
}
#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
@@ -1121,14 +1109,6 @@ static void _dsi_print_reset_status(struct platform_device *dsidev)
* I/O. */
l = dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
- printk(KERN_DEBUG "DSI resets: ");
-
- l = dsi_read_reg(dsidev, DSI_PLL_STATUS);
- printk("PLL (%d) ", FLD_GET(l, 0, 0));
-
- l = dsi_read_reg(dsidev, DSI_COMPLEXIO_CFG1);
- printk("CIO (%d) ", FLD_GET(l, 29, 29));
-
if (dss_has_feature(FEAT_DSI_REVERSE_TXCLKESC)) {
b0 = 28;
b1 = 27;
@@ -1139,14 +1119,20 @@ static void _dsi_print_reset_status(struct platform_device *dsidev)
b2 = 26;
}
- l = dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
- printk("PHY (%x%x%x, %d, %d, %d)\n",
- FLD_GET(l, b0, b0),
- FLD_GET(l, b1, b1),
- FLD_GET(l, b2, b2),
- FLD_GET(l, 29, 29),
- FLD_GET(l, 30, 30),
- FLD_GET(l, 31, 31));
+#define DSI_FLD_GET(fld, start, end)\
+ FLD_GET(dsi_read_reg(dsidev, DSI_##fld), start, end)
+
+ pr_debug("DSI resets: PLL (%d) CIO (%d) PHY (%x%x%x, %d, %d, %d)\n",
+ DSI_FLD_GET(PLL_STATUS, 0, 0),
+ DSI_FLD_GET(COMPLEXIO_CFG1, 29, 29),
+ DSI_FLD_GET(DSIPHY_CFG5, b0, b0),
+ DSI_FLD_GET(DSIPHY_CFG5, b1, b1),
+ DSI_FLD_GET(DSIPHY_CFG5, b2, b2),
+ DSI_FLD_GET(DSIPHY_CFG5, 29, 29),
+ DSI_FLD_GET(DSIPHY_CFG5, 30, 30),
+ DSI_FLD_GET(DSIPHY_CFG5, 31, 31));
+
+#undef DSI_FLD_GET
}
#else
#define _dsi_print_reset_status(x)
--
1.7.10
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox