* Re: [PATCH 1/7] drivers/video/pvr2fb.c: ensure arguments to request_irq and free_irq are compatible
From: Florian Tobias Schandinat @ 2012-03-21 18:37 UTC (permalink / raw)
To: Julia Lawall; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1331494587-12196-2-git-send-email-Julia.Lawall@lip6.fr>
On 03/11/2012 07:36 PM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Convert calls to free_irq so that the second argument is the same as the
> last argument of the corresponding call to request_irq. Without this
> property, free_irq does nothing.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied.
Thanks,
Florian Tobias Schandinat
>
> ---
> Not tested.
>
> drivers/video/pvr2fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
> index 3a3fdc6..bcd44c3 100644
> --- a/drivers/video/pvr2fb.c
> +++ b/drivers/video/pvr2fb.c
> @@ -895,7 +895,7 @@ static int __init pvr2fb_dc_init(void)
>
> #ifdef CONFIG_PVR2_DMA
> if (request_dma(pvr2dma, "pvr2") != 0) {
> - free_irq(HW_EVENT_VSYNC, 0);
> + free_irq(HW_EVENT_VSYNC, fb_info);
> return -EBUSY;
> }
> #endif
> @@ -914,7 +914,7 @@ static void __exit pvr2fb_dc_exit(void)
> currentpar->mmio_base = 0;
> }
>
> - free_irq(HW_EVENT_VSYNC, 0);
> + free_irq(HW_EVENT_VSYNC, fb_info);
> #ifdef CONFIG_PVR2_DMA
> free_dma(pvr2dma);
> #endif
>
>
^ permalink raw reply
* Re: [PATCH] video:uvesafb: notice user when we failed to save hardware state
From: Florian Tobias Schandinat @ 2012-03-21 18:35 UTC (permalink / raw)
To: Wang YanQing, spock, linux-fbdev, linux-kernel
In-Reply-To: <20120302014531.GA3597@udknight>
On 03/02/2012 01:45 AM, Wang YanQing wrote:
>
> uvesafb_open may failed to save hardware state when kmalloc failed
> in uvesafb_vbe_state_save, we should check this and notice user.
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/uvesafb.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index e7f69ef..9db3de3 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -362,7 +362,7 @@ static u8 *uvesafb_vbe_state_save(struct uvesafb_par *par)
>
> state = kmalloc(par->vbe_state_size, GFP_KERNEL);
> if (!state)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>
> task = uvesafb_prep();
> if (!task) {
> @@ -1172,9 +1172,17 @@ static int uvesafb_open(struct fb_info *info, int user)
> {
> struct uvesafb_par *par = info->par;
> int cnt = atomic_read(&par->ref_count);
> + u8 *buf = NULL;
>
> - if (!cnt && par->vbe_state_size)
> - par->vbe_state_orig = uvesafb_vbe_state_save(par);
> + if (!cnt && par->vbe_state_size) {
> + buf = uvesafb_vbe_state_save(par);
> + if (IS_ERR(buf)) {
> + printk(KERN_WARNING "uvesafb: save hardware state"
> + "failed, error code is %ld!\n", PTR_ERR(buf));
> + } else {
> + par->vbe_state_orig = buf;
> + }
> + }
>
> atomic_inc(&par->ref_count);
> return 0;
^ permalink raw reply
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Florian Tobias Schandinat @ 2012-03-21 18:34 UTC (permalink / raw)
To: Wang YanQing, linux-fbdev, linux-kernel, spock
In-Reply-To: <20120302004850.GA4139@udknight>
On 03/02/2012 12:48 AM, Wang YanQing wrote:
>
> Ok! I think I have learned to make thing simple and send to the right people:)
> This patch try to fix the oops below that catched in my machine
>
> [ 81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev , OEM: NVIDIA, VBE v3.0
> [ 81.609384] uvesafb: protected mode interface info at c000:d350
> [ 81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e
> [ 81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
> [ 81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers
> [ 81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used
> [ 81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtualI15
> [ 81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
> [ 81.744153] BUG: unable to handle kernel paging request at c00cd3b3
> [ 81.744159] IP: [<c00cd3b3>] 0xc00cd3b2
> [ 81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163
> [ 81.744171] Oops: 0011 [#1] SMP
> [ 81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect
> [ 81.744178]
> [ 81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer Aspire 4741 /Aspire 4741
> [ 81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0
> [ 81.744187] EIP is at 0xc00cd3b3
> [ 81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000
> [ 81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00
> [ 81.744192] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [ 81.744195] Process modprobe (pid: 3497, tiõ7f2000 task÷48c600 task.tiõ7f2000)
> [ 81.744196] Stack:
> [ 81.744197] f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0
> [ 81.744202] f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000
> [ 81.744206] f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400
> [ 81.744210] Call Trace:
> [ 81.744215] [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb]
> [ 81.744222] [<c124a9bc>] fb_pan_display+0x10c/0x160
> [ 81.744226] [<f8251280>] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb]
> [ 81.744230] [<c12598dd>] bit_update_start+0x1d/0x50
> [ 81.744232] [<c1255efe>] fbcon_switch+0x39e/0x550
> [ 81.744235] [<c125a21a>] ? bit_cursor+0x4ea/0x560
> [ 81.744240] [<c129b6cb>] redraw_screen+0x12b/0x220
> [ 81.744245] [<c128843b>] ? tty_do_resize+0x3b/0xc0
> [ 81.744247] [<c129ef42>] vc_do_resize+0x3d2/0x3e0
> [ 81.744250] [<c129efb4>] vc_resize+0x14/0x20
> [ 81.744253] [<c12586bd>] fbcon_init+0x29d/0x500
> [ 81.744255] [<c12984c4>] ? set_inverse_trans_unicode+0xe4/0x110
> [ 81.744258] [<c129b378>] visual_init+0xb8/0x150
> [ 81.744261] [<c129c16c>] bind_con_driver+0x16c/0x360
> [ 81.744264] [<c129b47e>] ? register_con_driver+0x6e/0x190
> [ 81.744267] [<c129c3a1>] take_over_console+0x41/0x50
> [ 81.744269] [<c1257b7a>] fbcon_takeover+0x6a/0xd0
> [ 81.744272] [<c12594b8>] fbcon_event_notify+0x758/0x790
> [ 81.744277] [<c10929e2>] notifier_call_chain+0x42/0xb0
> [ 81.744280] [<c1092d30>] __blocking_notifier_call_chain+0x60/0x90
> [ 81.744283] [<c1092d7a>] blocking_notifier_call_chain+0x1a/0x20
> [ 81.744285] [<c124a5a1>] fb_notifier_call_chain+0x11/0x20
> [ 81.744288] [<c124b759>] register_framebuffer+0x1d9/0x2b0
> [ 81.744293] [<c1061c73>] ? ioremap_wc+0x33/0x40
> [ 81.744298] [<f82537c6>] uvesafb_probe+0xaba/0xc40 [uvesafb]
> [ 81.744302] [<c12bb81f>] platform_drv_probe+0xf/0x20
> [ 81.744306] [<c12ba558>] driver_probe_device+0x68/0x170
> [ 81.744309] [<c12ba731>] __device_attach+0x41/0x50
> [ 81.744313] [<c12b9088>] bus_for_each_drv+0x48/0x70
> [ 81.744316] [<c12ba7f3>] device_attach+0x83/0xa0
> [ 81.744319] [<c12ba6f0>] ? __driver_attach+0x90/0x90
> [ 81.744321] [<c12b991f>] bus_probe_device+0x6f/0x90
> [ 81.744324] [<c12b8a45>] device_add+0x5e5/0x680
> [ 81.744329] [<c122a1a3>] ? kvasprintf+0x43/0x60
> [ 81.744332] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
> [ 81.744335] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70
> [ 81.744339] [<c12bbe9f>] platform_device_add+0xff/0x1b0
> [ 81.744343] [<f8252906>] uvesafb_init+0x50/0x9b [uvesafb]
> [ 81.744346] [<c100111f>] do_one_initcall+0x2f/0x170
> [ 81.744350] [<f82528b6>] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb]
> [ 81.744355] [<c10c6994>] sys_init_module+0xf4/0x1410
> [ 81.744359] [<c1157fc0>] ? vfsmount_lock_local_unlock_cpu+0x30/0x30
> [ 81.744363] [<c144cb10>] sysenter_do_call+0x12/0x36
> [ 81.744365] Code: f5 00 00 00 32 f6 66 8b da 66 d1 e3 66 ba d4 03 8a e3 b0 1c 66 ef b0 1e 66 ef 8a e7 b0 1d 66 ef b0 1f 66 ef e8 fa 00 00 00 61 c3 <60> e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66
> [ 81.744388] EIP: [<c00cd3b3>] 0xc00cd3b3 SS:ESP 0068:f57f3a00
> [ 81.744391] CR2: 00000000c00cd3b3
> [ 81.744393] ---[ end trace 18b2c87c925b54d6 ]---
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
I applied this patch but as there is opposition against exporting
'pcibios_enabled' and otherwise the building uvesafb as a module would
be broken I reverted it for this merge window, sorry. If you get this
solved I'd like to push it in some -rc (as well as in stable).
Best regards,
Florian Tobias Schandinat
> ---
> drivers/video/uvesafb.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index e7f69ef..f9a670d 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -23,6 +23,7 @@
> #include <video/uvesafb.h>
> #ifdef CONFIG_X86
> #include <video/vga.h>
> +#include <linux/pci.h>
> #endif
> #ifdef CONFIG_MTRR
> #include <asm/mtrr.h>
> @@ -815,8 +816,15 @@ static int __devinit uvesafb_vbe_init(struct fb_info *info)
> par->pmi_setpal = pmi_setpal;
> par->ypan = ypan;
>
> - if (par->pmi_setpal || par->ypan)
> - uvesafb_vbe_getpmi(task, par);
> + if (par->pmi_setpal || par->ypan) {
> + if (pcibios_enabled) {
> + uvesafb_vbe_getpmi(task, par);
> + } else {
> + par->pmi_setpal = par->ypan = 0;
> + printk(KERN_WARNING "uvesafb: PCI BIOS area is NX."
> + "Can't use protected mode interface\n");
> + }
> + }
> #else
> /* The protected mode interface is not available on non-x86. */
> par->pmi_setpal = par->ypan = 0;
^ permalink raw reply
* Re: [PATCH v2] udlfb: Fix invalid return codes in edid sysfs entry store function
From: Florian Tobias Schandinat @ 2012-03-21 18:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1330499200-20819-1-git-send-email-olivier@sobrie.be>
On 02/29/2012 07:06 AM, Olivier Sobrie wrote:
> Return a negative errno instead of zero in the write function of
> the sysfs entry in case of error.
> Also add a check on the return value of dlfb_setup_modes().
>
> Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
As Bernie did agree in the pull request, I applied this patch.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/udlfb.c | 19 +++++++++++--------
> 1 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index a197731..bfd2a56 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -1427,19 +1427,22 @@ static ssize_t edid_store(
> struct device *fbdev = container_of(kobj, struct device, kobj);
> struct fb_info *fb_info = dev_get_drvdata(fbdev);
> struct dlfb_data *dev = fb_info->par;
> + int ret;
>
> /* We only support write of entire EDID at once, no offset*/
> if ((src_size != EDID_LENGTH) || (src_off != 0))
> - return 0;
> + return -EINVAL;
>
> - dlfb_setup_modes(dev, fb_info, src, src_size);
> + ret = dlfb_setup_modes(dev, fb_info, src, src_size);
> + if (ret)
> + return ret;
>
> - if (dev->edid && (memcmp(src, dev->edid, src_size) = 0)) {
> - pr_info("sysfs written EDID is new default\n");
> - dlfb_ops_set_par(fb_info);
> - return src_size;
> - } else
> - return 0;
> + if (!dev->edid || memcmp(src, dev->edid, src_size))
> + return -EINVAL;
> +
> + pr_info("sysfs written EDID is new default\n");
> + dlfb_ops_set_par(fb_info);
> + return src_size;
> }
>
> static ssize_t metrics_reset_store(struct device *fbdev,
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Laurent Pinchart @ 2012-03-21 14:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Florian,
On Wednesday 21 March 2012 14:26:01 Florian Tobias Schandinat wrote:
> On 03/21/2012 02:09 PM, Laurent Pinchart wrote:
> > On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
> >> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> >>> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> >>>> MERAM can be used for other IP blocks as well in the future.
> >>>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> >>>> This patch corrects dependency.
> >>>>
> >>>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >>>> ---
> >>>> v3 -> v4
> >>>>
> >>>> - move config to before endpoint
> >>>
> >>> As the driver doesn't depend on FB and can also be used by other
> >>> subsystems, would it make sense to move it out of drivers/video/ ?
> >>> drivers/sh/ might be a candidate, although I think selecting a location
> >>> based on the platform is frowned upon (drivers/platform/x86 comes to
> >>> mind). There's probably a better location.
> >>
> >> Well, as long as it is related to video/graphic I think drivers/video is
> >> a good location. There are also backlight and console in that directory
> >> without being directly related to the framebuffer subsystem.
> >
> > The MERAM can also be used by the video engine unit (a memory-to-memory
> > format conversion block), the video processing unit (a multi-codec
> > module), the capture engine unit (camera interface), the JPEG engine unit
> > (a JPEG codec), ... Not all of those are related to display, although
> > they're all related to display, imaging, and or/video.
>
> I see, thanks for the explanation.
> I applied this patch so it can be used for such purposes without the
> dependency. If there will be a better place for it in the future we can
> move it than.
Sounds good to me. Thank you.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Florian Tobias Schandinat @ 2012-03-21 14:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Laurent,
On 03/21/2012 02:09 PM, Laurent Pinchart wrote:
> On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
>> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
>>> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
>>>> MERAM can be used for other IP blocks as well in the future.
>>>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
>>>> This patch corrects dependency.
>>>>
>>>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>>>> ---
>>>> v3 -> v4
>>>>
>>>> - move config to before endpoint
>>>
>>> As the driver doesn't depend on FB and can also be used by other
>>> subsystems, would it make sense to move it out of drivers/video/ ?
>>> drivers/sh/ might be a candidate, although I think selecting a location
>>> based on the platform is frowned upon (drivers/platform/x86 comes to
>>> mind). There's probably a better location.
>>
>> Well, as long as it is related to video/graphic I think drivers/video is
>> a good location. There are also backlight and console in that directory
>> without being directly related to the framebuffer subsystem.
>
> The MERAM can also be used by the video engine unit (a memory-to-memory format
> conversion block), the video processing unit (a multi-codec module), the
> capture engine unit (camera interface), the JPEG engine unit (a JPEG codec),
> ... Not all of those are related to display, although they're all related to
> display, imaging, and or/video.
I see, thanks for the explanation.
I applied this patch so it can be used for such purposes without the
dependency. If there will be a better place for it in the future we can
move it than.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Laurent Pinchart @ 2012-03-21 14:09 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Florian,
On Wednesday 21 March 2012 14:01:00 Florian Tobias Schandinat wrote:
> On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> > On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> >> MERAM can be used for other IP blocks as well in the future.
> >> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> >> This patch corrects dependency.
> >>
> >> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >> ---
> >> v3 -> v4
> >>
> >> - move config to before endpoint
> >
> > As the driver doesn't depend on FB and can also be used by other
> > subsystems, would it make sense to move it out of drivers/video/ ?
> > drivers/sh/ might be a candidate, although I think selecting a location
> > based on the platform is frowned upon (drivers/platform/x86 comes to
> > mind). There's probably a better location.
>
> Well, as long as it is related to video/graphic I think drivers/video is
> a good location. There are also backlight and console in that directory
> without being directly related to the framebuffer subsystem.
The MERAM can also be used by the video engine unit (a memory-to-memory format
conversion block), the video processing unit (a multi-codec module), the
capture engine unit (camera interface), the JPEG engine unit (a JPEG codec),
... Not all of those are related to display, although they're all related to
display, imaging, and or/video.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Florian Tobias Schandinat @ 2012-03-21 14:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Laurent,
On 03/21/2012 01:49 PM, Laurent Pinchart wrote:
> Hi Morimoto-san,
>
> On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
>> MERAM can be used for other IP blocks as well in the future.
>> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
>> This patch corrects dependency.
>>
>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> ---
>> v3 -> v4
>>
>> - move config to before endpoint
>
> As the driver doesn't depend on FB and can also be used by other subsystems,
> would it make sense to move it out of drivers/video/ ? drivers/sh/ might be a
> candidate, although I think selecting a location based on the platform is
> frowned upon (drivers/platform/x86 comes to mind). There's probably a better
> location.
Well, as long as it is related to video/graphic I think drivers/video is
a good location. There are also backlight and console in that directory
without being directly related to the framebuffer subsystem.
Best regards,
Florian Tobias Schandinat
>
>> drivers/video/Kconfig | 23 +++++++++++------------
>> 1 files changed, 11 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 8951cbd..0fb9540 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
>> ---help---
>> Driver for the on-chip SH-Mobile HDMI controller.
>>
>> -config FB_SH_MOBILE_MERAM
>> - tristate "SuperH Mobile MERAM read ahead support for LCDC"
>> - depends on FB_SH_MOBILE_LCDC
>> - default y
>> - ---help---
>> - Enable MERAM support for the SH-Mobile LCD controller.
>> -
>> - This will allow for caching of the framebuffer to provide more
>> - reliable access under heavy main memory bus traffic situations.
>> - Up to 4 memory channels can be configured, allowing 4 RGB or
>> - 2 YCbCr framebuffers to be configured.
>> -
>> config FB_TMIO
>> tristate "Toshiba Mobile IO FrameBuffer support"
>> depends on FB && MFD_CORE
>> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
>> source "drivers/video/logo/Kconfig"
>> endif
>>
>> +config FB_SH_MOBILE_MERAM
>> + tristate "SuperH Mobile MERAM read ahead support"
>> + depends on (SUPERH || ARCH_SHMOBILE)
>> + ---help---
>> + Enable MERAM support for the SuperH controller.
>> +
>> + This will allow for caching of the framebuffer to provide more
>> + reliable access under heavy main memory bus traffic situations.
>> + Up to 4 memory channels can be configured, allowing 4 RGB or
>> + 2 YCbCr framebuffers to be configured.
>> +
>> endmenu
^ permalink raw reply
* Re: [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Laurent Pinchart @ 2012-03-21 13:49 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87obrqwxp2.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
On Tuesday 20 March 2012 18:27:08 Kuninori Morimoto wrote:
> MERAM can be used for other IP blocks as well in the future.
> It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> This patch corrects dependency.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> v3 -> v4
>
> - move config to before endpoint
As the driver doesn't depend on FB and can also be used by other subsystems,
would it make sense to move it out of drivers/video/ ? drivers/sh/ might be a
candidate, although I think selecting a location based on the platform is
frowned upon (drivers/platform/x86 comes to mind). There's probably a better
location.
> drivers/video/Kconfig | 23 +++++++++++------------
> 1 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 8951cbd..0fb9540 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
> ---help---
> Driver for the on-chip SH-Mobile HDMI controller.
>
> -config FB_SH_MOBILE_MERAM
> - tristate "SuperH Mobile MERAM read ahead support for LCDC"
> - depends on FB_SH_MOBILE_LCDC
> - default y
> - ---help---
> - Enable MERAM support for the SH-Mobile LCD controller.
> -
> - This will allow for caching of the framebuffer to provide more
> - reliable access under heavy main memory bus traffic situations.
> - Up to 4 memory channels can be configured, allowing 4 RGB or
> - 2 YCbCr framebuffers to be configured.
> -
> config FB_TMIO
> tristate "Toshiba Mobile IO FrameBuffer support"
> depends on FB && MFD_CORE
> @@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
> source "drivers/video/logo/Kconfig"
> endif
>
> +config FB_SH_MOBILE_MERAM
> + tristate "SuperH Mobile MERAM read ahead support"
> + depends on (SUPERH || ARCH_SHMOBILE)
> + ---help---
> + Enable MERAM support for the SuperH controller.
> +
> + This will allow for caching of the framebuffer to provide more
> + reliable access under heavy main memory bus traffic situations.
> + Up to 4 memory channels can be configured, allowing 4 RGB or
> + 2 YCbCr framebuffers to be configured.
> +
> endmenu
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: provide default get_timings function for panels
From: Tomi Valkeinen @ 2012-03-21 13:11 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1331834424-485-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Thu, 2012-03-15 at 20:00 +0200, Grazvydas Ignotas wrote:
> With this we can eliminate some duplicate code in panel drivers.
> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
> tpo-td043mtea1 gain support of reading timings over sysfs.
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> drivers/video/omap2/displays/panel-acx565akm.c | 7 -------
> drivers/video/omap2/displays/panel-generic-dpi.c | 7 -------
> drivers/video/omap2/displays/panel-n8x0.c | 8 --------
> drivers/video/omap2/displays/panel-taal.c | 8 --------
> drivers/video/omap2/dss/core.c | 2 ++
> drivers/video/omap2/dss/display.c | 7 +++++++
> drivers/video/omap2/dss/venc.c | 7 -------
> include/video/omapdss.h | 2 ++
> 8 files changed, 11 insertions(+), 37 deletions(-)
These two patches look fine to me, I'll apply to omapdss tree. Thanks!
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: OMAPFB: check for matching memory size early
From: Tomi Valkeinen @ 2012-03-21 12:58 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1331253769-9770-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
Hi,
On Fri, 2012-03-09 at 02:42 +0200, Grazvydas Ignotas wrote:
> If the size of memory region that is being set up is the same as before,
> we don't have to do memory and layer busy checks.
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> I'm not sure if this is semantically correct, but this helps to get
> some old programs working, that rely on old DSS version which didn't
> check for mmap lock, but incidentally they are using same size too..
Well, I wouldn't allow code like that if it was a new ioctl, but if, as
you say, the old omapfb worked that way, then I think it's better to do
things the same way.
I can see no harm in it, so I'll apply.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
From: Tomi Valkeinen @ 2012-03-21 12:50 UTC (permalink / raw)
To: Mark Brown
Cc: Florian Tobias Schandinat, Grazvydas Ignotas, linux-omap,
linux-fbdev
In-Reply-To: <1332169352-5076-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
On Mon, 2012-03-19 at 15:02 +0000, Mark Brown wrote:
> It is possible for regulator_enable() to fail and if it does fail that's
> generally a bad sign for anything we try to do with the hardware afterwards
> so check for and immediately return an error if regulator_enable() fails.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> .../video/omap2/displays/panel-tpo-td043mtea1.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> index 32f3fcd..74c6b87 100644
> --- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> +++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
> @@ -272,11 +272,14 @@ static const struct omap_video_timings tpo_td043_timings = {
> static int tpo_td043_power_on(struct tpo_td043_device *tpo_td043)
> {
> int nreset_gpio = tpo_td043->nreset_gpio;
> + int r;
>
> if (tpo_td043->powered_on)
> return 0;
>
> - regulator_enable(tpo_td043->vcc_reg);
> + r = regulator_enable(tpo_td043->vcc_reg);
> + if (r != 0)
> + return r;
>
> /* wait for regulator to stabilize */
> msleep(160);
Thanks, I'll apply this series to omapdss tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: VENC: Check for errors from regulator_enable()
From: Tomi Valkeinen @ 2012-03-21 12:49 UTC (permalink / raw)
To: Mark Brown; +Cc: Florian Tobias Schandinat, linux-omap, linux-fbdev
In-Reply-To: <1332168999-4600-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
On Mon, 2012-03-19 at 14:56 +0000, Mark Brown wrote:
> It is possible for regulator_enable() to fail and if it does fail that's
> generally a bad sign for anything we try to do with the hardware afterwards
> so check for and immediately return an error if regulator_enable() fails.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
> drivers/video/omap2/dss/venc.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
> index 9c3daf7..abfbd4a 100644
> --- a/drivers/video/omap2/dss/venc.c
> +++ b/drivers/video/omap2/dss/venc.c
> @@ -443,7 +443,9 @@ static int venc_power_on(struct omap_dss_device *dssdev)
> dispc_set_digit_size(dssdev->panel.timings.x_res,
> dssdev->panel.timings.y_res/2);
>
> - regulator_enable(venc.vdda_dac_reg);
> + r = regulator_enable(venc.vdda_dac_reg);
> + if (r)
> + goto err;
>
> if (dssdev->platform_enable)
> dssdev->platform_enable(dssdev);
Thanks, I'll apply to omapdss tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage
From: Tomi Valkeinen @ 2012-03-21 12:49 UTC (permalink / raw)
To: Mark Brown; +Cc: Florian Tobias Schandinat, linux-omap, linux-fbdev
In-Reply-To: <1332168646-4391-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]
On Mon, 2012-03-19 at 14:50 +0000, Mark Brown wrote:
> The TAAL driver contains some regulator support which is currently unused
> (the code is there but the one panel supported by the driver doesn't have
> any regulators provided). This code mostly looks like an open coded
> version of the regulator core bulk API.
>
> The only additional feature is that a voltage range can be set once when
> the device is opened, though this is never varied at runtime. The general
> expectation is that if the device is not actively managing the voltage of
> the device (eg, doing DVFS) then any configuration will be done using the
> constraints rather than by drivers, saving them code and ensuring that
> they work well with systems where the voltage is not configurable.
>
> If systems are added needing regulator support this can be added back in,
> though it should be based on core features rather than open coding things.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Looks fine to me, I'll apply to omapdss tree.
We had multiple panels in Nokia, almost the same but with slightly
different regulator needs, so we wrote the code removed in this patch.
But as it seems there are no more linux devices coming from Nokia, let's
just remove the regulator code.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [GIT PULL] OMAP DSS for v3.4
From: Tomi Valkeinen @ 2012-03-21 12:39 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: Arnd Bergmann, linux-omap, linux-fbdev
In-Reply-To: <1332154865.2144.57.camel@deskari>
[-- Attachment #1: Type: text/plain, Size: 6583 bytes --]
Hi Florian,
On Mon, 2012-03-19 at 13:01 +0200, Tomi Valkeinen wrote:
> Hi Florian, Arnd,
>
> Here are the changes for OMAP DSS driver for v3.4.
>
> There's an issue with the dss driver that appears on arm-soc/for-next
> branch, which I'm still solving
> (http://marc.info/?l=linux-omap&m=133214966902577&w=2). I hope to get
> fix for that ready and merged for -rc1, but I'm not sure if I can make
> it in time, so I wanted to sent this pull request already.
Below is a patch that fixes the issue I mentioned above. So briefly, the
problem is that omapdss's driver registration is broken, and it has been
working so far by luck. arm-soc tree contains a patch which changes how
arch/arm/plat-omap/omap_device.c creates the devices, and this causes
the (broken) omapdss driver registration to break, causing a deadlock.
The patch below makes the omapdss driver registration saner. The patch
works with and without the omap_device.c patch from arm-soc.
Florian, if you didn't send the pull request yet, this would be a good
patch to add to it. We can, of course, get it in for -rc2, but avoiding
a kernel deadlock on -rc1 would be nice.
Tomi
From 849c07b1fd3d9f23e8ed94436b6221f8652462c0 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon, 19 Mar 2012 15:05:02 +0200
Subject: [PATCH] OMAPDSS: register dss drivers in module init
We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.
There doesn't seem to be any reason for that, and additionally the
soon-to-be-merged patch "ARM: OMAP: omap_device: remove
omap_device_parent" will break omapdss initialization with the current
registration model.
This patch changes the registration for all drivers to happen at the
same place, in the init of the module.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/core.c | 135 +++++++++++++++++++++++-----------------
1 files changed, 77 insertions(+), 58 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8613f86..e8a1207 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -183,42 +183,6 @@ static int omap_dss_probe(struct platform_device *pdev)
dss_init_overlay_managers(pdev);
dss_init_overlays(pdev);
- r = dss_init_platform_driver();
- if (r) {
- DSSERR("Failed to initialize DSS platform driver\n");
- goto err_dss;
- }
-
- r = dispc_init_platform_driver();
- if (r) {
- DSSERR("Failed to initialize dispc platform driver\n");
- goto err_dispc;
- }
-
- r = rfbi_init_platform_driver();
- if (r) {
- DSSERR("Failed to initialize rfbi platform driver\n");
- goto err_rfbi;
- }
-
- r = venc_init_platform_driver();
- if (r) {
- DSSERR("Failed to initialize venc platform driver\n");
- goto err_venc;
- }
-
- r = dsi_init_platform_driver();
- if (r) {
- DSSERR("Failed to initialize DSI platform driver\n");
- goto err_dsi;
- }
-
- r = hdmi_init_platform_driver();
- if (r) {
- DSSERR("Failed to initialize hdmi\n");
- goto err_hdmi;
- }
-
r = dss_initialize_debugfs();
if (r)
goto err_debugfs;
@@ -246,18 +210,6 @@ static int omap_dss_probe(struct platform_device *pdev)
err_register:
dss_uninitialize_debugfs();
err_debugfs:
- hdmi_uninit_platform_driver();
-err_hdmi:
- dsi_uninit_platform_driver();
-err_dsi:
- venc_uninit_platform_driver();
-err_venc:
- dispc_uninit_platform_driver();
-err_dispc:
- rfbi_uninit_platform_driver();
-err_rfbi:
- dss_uninit_platform_driver();
-err_dss:
return r;
}
@@ -269,13 +221,6 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
- hdmi_uninit_platform_driver();
- dsi_uninit_platform_driver();
- venc_uninit_platform_driver();
- rfbi_uninit_platform_driver();
- dispc_uninit_platform_driver();
- dss_uninit_platform_driver();
-
dss_uninit_overlays(pdev);
dss_uninit_overlay_managers(pdev);
@@ -525,6 +470,80 @@ static int omap_dss_bus_register(void)
/* INIT */
+static int __init omap_dss_register_drivers(void)
+{
+ int r;
+
+ r = platform_driver_register(&omap_dss_driver);
+ if (r)
+ return r;
+
+ r = dss_init_platform_driver();
+ if (r) {
+ DSSERR("Failed to initialize DSS platform driver\n");
+ goto err_dss;
+ }
+
+ r = dispc_init_platform_driver();
+ if (r) {
+ DSSERR("Failed to initialize dispc platform driver\n");
+ goto err_dispc;
+ }
+
+ r = rfbi_init_platform_driver();
+ if (r) {
+ DSSERR("Failed to initialize rfbi platform driver\n");
+ goto err_rfbi;
+ }
+
+ r = venc_init_platform_driver();
+ if (r) {
+ DSSERR("Failed to initialize venc platform driver\n");
+ goto err_venc;
+ }
+
+ r = dsi_init_platform_driver();
+ if (r) {
+ DSSERR("Failed to initialize DSI platform driver\n");
+ goto err_dsi;
+ }
+
+ r = hdmi_init_platform_driver();
+ if (r) {
+ DSSERR("Failed to initialize hdmi\n");
+ goto err_hdmi;
+ }
+
+ return 0;
+
+err_hdmi:
+ dsi_uninit_platform_driver();
+err_dsi:
+ venc_uninit_platform_driver();
+err_venc:
+ rfbi_uninit_platform_driver();
+err_rfbi:
+ dispc_uninit_platform_driver();
+err_dispc:
+ dss_uninit_platform_driver();
+err_dss:
+ platform_driver_unregister(&omap_dss_driver);
+
+ return r;
+}
+
+static void __exit omap_dss_unregister_drivers(void)
+{
+ hdmi_uninit_platform_driver();
+ dsi_uninit_platform_driver();
+ venc_uninit_platform_driver();
+ rfbi_uninit_platform_driver();
+ dispc_uninit_platform_driver();
+ dss_uninit_platform_driver();
+
+ platform_driver_unregister(&omap_dss_driver);
+}
+
#ifdef CONFIG_OMAP2_DSS_MODULE
static void omap_dss_bus_unregister(void)
{
@@ -541,7 +560,7 @@ static int __init omap_dss_init(void)
if (r)
return r;
- r = platform_driver_register(&omap_dss_driver);
+ r = omap_dss_register_drivers();
if (r) {
omap_dss_bus_unregister();
return r;
@@ -562,7 +581,7 @@ static void __exit omap_dss_exit(void)
core.vdds_sdi_reg = NULL;
}
- platform_driver_unregister(&omap_dss_driver);
+ omap_dss_unregister_drivers();
omap_dss_bus_unregister();
}
@@ -577,7 +596,7 @@ static int __init omap_dss_init(void)
static int __init omap_dss_init2(void)
{
- return platform_driver_register(&omap_dss_driver);
+ return omap_dss_register_drivers();
}
core_initcall(omap_dss_init);
--
1.7.4.1
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH V2 2/3] OMAPDSS: DISPC: Handle synclost errors in OMAP3
From: Chandrabhanu Mahapatra @ 2012-03-21 9:56 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver rejects
configuration exceeding above limitations.
This code was successfully tested on OMAP3. This code is written based on code
written by Ville Syrj채l채 <ville.syrjala@nokia.com> in Linux OMAP kernel. Ville
Syrj채l채 <ville.syrjala@nokia.com> had added checks for video overlay horizontal
timing and DISPC horizontal blanking length limitations.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 97 +++++++++++++++++++++++++++++----------
1 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5a1963e..d8a1672 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1622,6 +1622,57 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
}
}
+static int check_horiz_timing(enum omap_channel channel, u16 pos_x,
+ u16 width, u16 height, u16 out_width, u16 out_height)
+{
+ int DS = DIV_ROUND_UP(height, out_height);
+ struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
+ struct omap_video_timings t = dssdev->panel.timings;
+ unsigned long nonactive, lclk, pclk;
+ static const u8 limits[3] = { 8, 10, 20 };
+ u64 val, blank;
+ int i;
+
+ nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+ pclk = dispc_mgr_pclk_rate(channel);
+ lclk = dispc_mgr_lclk_rate(channel);
+
+ i = 0;
+ if (out_height < height)
+ i++;
+ if (out_width < width)
+ i++;
+ blank = div_u64((u64)(t.hbp + t.hsw + t.hfp) * lclk, pclk);
+ DSSDBG("blanking period + ppl = %llu (limit = %u)\n", blank, limits[i]);
+ if (blank <= limits[i])
+ return -EINVAL;
+
+ /*
+ * Pixel data should be prepared before visible display point starts.
+ * So, atleast DS-2 lines must have already been fetched by DISPC
+ * during nonactive - pos_x period.
+ */
+ val = div_u64((u64)(nonactive - pos_x) * lclk, pclk);
+ DSSDBG("(nonactive - pos_x) * pcd = %llu,"
+ " max(0, DS - 2) * width = %d\n",
+ val, max(0, DS - 2) * width);
+ if (val < max(0, DS - 2) * width)
+ return -EINVAL;
+
+ /*
+ * All lines need to be refilled during the nonactive period of which
+ * only one line can be loaded during the active period. So, atleast
+ * DS - 1 lines should be loaded during nonactive period.
+ */
+ val = div_u64((u64)nonactive * lclk, pclk);
+ DSSDBG("nonactive * pcd = %llu, max(0, DS - 1) * width = %d\n",
+ val, max(0, DS - 1) * width);
+ if (val < max(0, DS - 1) * width)
+ return -EINVAL;
+
+ return 0;
+}
+
static unsigned long calc_fclk_five_taps(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
@@ -1702,7 +1753,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
enum omap_channel channel, u16 width, u16 height,
u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
- int *x_predecim, int *y_predecim)
+ int *x_predecim, int *y_predecim, u16 pos_x)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
@@ -1778,6 +1829,9 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
fclk = calc_fclk_five_taps(channel, in_width, in_height,
out_width, out_height, color_mode);
+ error = check_horiz_timing(channel, pos_x, in_width,
+ in_height, out_width, out_height);
+
if (in_width > maxsinglelinewidth)
if (in_height > out_height &&
in_height < out_height * 2)
@@ -1785,7 +1839,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if (!*five_taps)
fclk = calc_fclk(channel, in_width, in_height,
out_width, out_height);
- error = (in_width > maxsinglelinewidth * 2 ||
+ error = (error || in_width > maxsinglelinewidth * 2 ||
(in_width > maxsinglelinewidth && *five_taps) ||
!fclk || fclk > dispc_fclk_rate());
if (error) {
@@ -1801,6 +1855,12 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
} while (decim_x <= *x_predecim && decim_y <= *y_predecim
&& error);
+ if (check_horiz_timing(channel, pos_x, width, height,
+ out_width, out_height)){
+ DSSERR("horizontal timing too tight\n");
+ return -EINVAL;
+ }
+
if (in_width > (maxsinglelinewidth * 2)) {
DSSERR("Cannot setup scaling");
DSSERR("width exceeds maximum width possible");
@@ -1901,7 +1961,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
r = dispc_ovl_calc_scaling(plane, channel, in_width, in_height,
out_width, out_height, oi->color_mode, &five_taps,
- &x_predecim, &y_predecim);
+ &x_predecim, &y_predecim, oi->pos_x);
if (r)
return r;
@@ -2472,32 +2532,19 @@ unsigned long dispc_fclk_rate(void)
unsigned long dispc_mgr_lclk_rate(enum omap_channel channel)
{
- struct platform_device *dsidev;
- int lcd;
- unsigned long r;
- u32 l;
+ unsigned long r = dispc_fclk_rate();
- l = dispc_read_reg(DISPC_DIVISORo(channel));
+ if (dispc_mgr_is_lcd(channel)) {
+ u32 l;
+ int lcd;
- lcd = FLD_GET(l, 23, 16);
+ l = dispc_read_reg(DISPC_DIVISORo(channel));
+ lcd = FLD_GET(l, 23, 16);
- switch (dss_get_lcd_clk_source(channel)) {
- case OMAP_DSS_CLK_SRC_FCK:
- r = clk_get_rate(dispc.dss_clk);
- break;
- case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
- dsidev = dsi_get_dsidev_from_id(0);
- r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
- break;
- case OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC:
- dsidev = dsi_get_dsidev_from_id(1);
- r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
- break;
- default:
- BUG();
+ return r / lcd;
+ } else {
+ return r;
}
-
- return r / lcd;
}
unsigned long dispc_mgr_pclk_rate(enum omap_channel channel)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 3/3] OMAPDSS: DISPC: Correct DISPC functional clock usage
From: Chandrabhanu Mahapatra @ 2012-03-21 9:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
DISPC_FCLK is incorrectly used as functional clock of DISPC in scaling
calculations. So, DISPC_CORE_CLK replaces as functional clock of DISPC.
DISPC_CORE_CLK is derived from DISPC_FCLK divided by an independent DISPC
divisor LCD.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d8a1672..1fdac73 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1761,6 +1761,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
const int max_decim_limit = 16;
unsigned long fclk = 0;
+ unsigned long dispc_core_clk = dispc_mgr_lclk_rate(channel);
int decim_x, decim_y, error, min_factor;
u16 in_width, in_height, in_width_max = 0;
@@ -1803,7 +1804,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
fclk = calc_fclk(channel, in_width, in_height,
out_width, out_height);
error = (in_width > maxsinglelinewidth || !fclk ||
- fclk > dispc_fclk_rate());
+ fclk > dispc_core_clk);
if (error) {
if (decim_x = decim_y) {
decim_x = min_factor;
@@ -1841,7 +1842,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
out_width, out_height);
error = (error || in_width > maxsinglelinewidth * 2 ||
(in_width > maxsinglelinewidth && *five_taps) ||
- !fclk || fclk > dispc_fclk_rate());
+ !fclk || fclk > dispc_core_clk);
if (error) {
if (decim_x = decim_y) {
decim_x = min_factor;
@@ -1873,7 +1874,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
}
} else {
in_height = DIV_ROUND_UP(height, decim_y);
- in_width_max = dispc_fclk_rate() /
+ in_width_max = dispc_core_clk /
DIV_ROUND_UP(dispc_mgr_pclk_rate(channel),
out_width);
decim_x = DIV_ROUND_UP(width, in_width_max);
@@ -1894,13 +1895,13 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
}
DSSDBG("required fclk rate = %lu Hz\n", fclk);
- DSSDBG("current fclk rate = %lu Hz\n", dispc_fclk_rate());
+ DSSDBG("current fclk rate = %lu Hz\n", dispc_core_clk);
- if (!fclk || fclk > dispc_fclk_rate()) {
+ if (!fclk || fclk > dispc_core_clk) {
DSSERR("failed to set up scaling, "
"required fclk rate = %lu Hz, "
"current fclk rate = %lu Hz\n",
- fclk, dispc_fclk_rate());
+ fclk, dispc_core_clk);
return -EINVAL;
}
--
1.7.1
^ permalink raw reply related
* [PATCH V2 1/3] OMAPDSS: DISPC: Enable predecimation
From: Chandrabhanu Mahapatra @ 2012-03-21 9:52 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
up to 2 times in OMAP2. However, with predecimation, the image can be reduced
to 16 times by fetching only the necessary pixels in memory. Then this
predecimated image can be downscaled further by the DISPC scaler.
The pipeline is configured to use a burst of size 8 * 128 bits which consists
of 8 mini bursts of 16 bytes each. So, horizontal predecimation more than 16
can lead to complete discarding of such mini bursts. L3 interconnect may
handover the bus to some other initiator and inturn delay the fetching of
pixels leading to underflows. So, maximum predecimation limit is fixed at 16.
Based on the downscaling required, a prior calculation of predecimation values
for width and height of an image is done. Since, Predecimation reduces quality
of an image higher priorty is given to DISPC Scaler for downscaling.
This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and
vertical predecimation worked fine except for some synclost errors due to
undocumented errata in OMAP3 which are fixed later and skewed images were seen
on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in
the future patches.
This code is based on code written by Lajos Molnar <lajos@ti.com> who had added
predecimation support for NV12/YUV/rotated/SDMA buffers.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 262 +++++++++++++++++++++++++++------------
1 files changed, 181 insertions(+), 81 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e1626a1..5a1963e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1389,7 +1389,7 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool mirror,
enum omap_color_mode color_mode, bool fieldmode,
unsigned int field_offset,
unsigned *offset0, unsigned *offset1,
- s32 *row_inc, s32 *pix_inc)
+ s32 *row_inc, s32 *pix_inc, int x_predecim, int y_predecim)
{
u8 ps;
@@ -1435,10 +1435,10 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool mirror,
else
*offset0 = 0;
- *row_inc = pixinc(1 + (screen_width - width) +
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 +
+ (y_predecim * screen_width - x_predecim * width) +
+ (fieldmode ? screen_width : 0), ps);
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_0 + 4:
@@ -1456,10 +1456,10 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool mirror,
*offset0 = field_offset * screen_width * ps;
else
*offset0 = 0;
- *row_inc = pixinc(1 - (screen_width + width) -
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 -
+ (y_predecim * screen_width + x_predecim * width) -
+ (fieldmode ? screen_width : 0), ps);
+ *pix_inc = pixinc(x_predecim, ps);
break;
default:
@@ -1473,7 +1473,7 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
enum omap_color_mode color_mode, bool fieldmode,
unsigned int field_offset,
unsigned *offset0, unsigned *offset1,
- s32 *row_inc, s32 *pix_inc)
+ s32 *row_inc, s32 *pix_inc, int x_predecim, int y_predecim)
{
u8 ps;
u16 fbw, fbh;
@@ -1515,10 +1515,14 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 + field_offset * screen_width * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(1 + (screen_width - fbw) +
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 +
+ (y_predecim * screen_width - fbw * x_predecim) +
+ (fieldmode ? screen_width : 0), ps);
+ if (color_mode = OMAP_DSS_COLOR_YUV2 ||
+ color_mode = OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_90:
*offset1 = screen_width * (fbh - 1) * ps;
@@ -1526,9 +1530,9 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 + field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(screen_width * (fbh - 1) + 1 +
- (fieldmode ? 1 : 0), ps);
- *pix_inc = pixinc(-screen_width, ps);
+ *row_inc = pixinc(screen_width * (fbh * x_predecim - 1) +
+ y_predecim + (fieldmode ? 1 : 0), ps);
+ *pix_inc = pixinc(-x_predecim * screen_width, ps);
break;
case OMAP_DSS_ROT_180:
*offset1 = (screen_width * (fbh - 1) + fbw - 1) * ps;
@@ -1537,10 +1541,13 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
else
*offset0 = *offset1;
*row_inc = pixinc(-1 -
- (screen_width - fbw) -
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(-1, ps);
+ (y_predecim * screen_width - fbw * x_predecim) -
+ (fieldmode ? screen_width : 0), ps);
+ if (color_mode = OMAP_DSS_COLOR_YUV2 ||
+ color_mode = OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(-x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(-x_predecim, ps);
break;
case OMAP_DSS_ROT_270:
*offset1 = (fbw - 1) * ps;
@@ -1548,9 +1555,9 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 - field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(-screen_width * (fbh - 1) - 1 -
- (fieldmode ? 1 : 0), ps);
- *pix_inc = pixinc(screen_width, ps);
+ *row_inc = pixinc(-screen_width * (fbh * x_predecim - 1) -
+ y_predecim - (fieldmode ? 1 : 0), ps);
+ *pix_inc = pixinc(x_predecim * screen_width, ps);
break;
/* mirroring */
@@ -1560,10 +1567,14 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 + field_offset * screen_width * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(screen_width * 2 - 1 +
+ *row_inc = pixinc(y_predecim * screen_width * 2 - 1 +
(fieldmode ? screen_width : 0),
ps);
- *pix_inc = pixinc(-1, ps);
+ if (color_mode = OMAP_DSS_COLOR_YUV2 ||
+ color_mode = OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(-x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(-x_predecim, ps);
break;
case OMAP_DSS_ROT_90 + 4:
@@ -1572,10 +1583,10 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 + field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(-screen_width * (fbh - 1) + 1 +
- (fieldmode ? 1 : 0),
+ *row_inc = pixinc(-screen_width * (fbh * x_predecim - 1) +
+ y_predecim + (fieldmode ? 1 : 0),
ps);
- *pix_inc = pixinc(screen_width, ps);
+ *pix_inc = pixinc(x_predecim * screen_width, ps);
break;
case OMAP_DSS_ROT_180 + 4:
@@ -1584,10 +1595,14 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 - field_offset * screen_width * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(1 - screen_width * 2 -
+ *row_inc = pixinc(1 - y_predecim * screen_width * 2 -
(fieldmode ? screen_width : 0),
ps);
- *pix_inc = pixinc(1, ps);
+ if (color_mode = OMAP_DSS_COLOR_YUV2 ||
+ color_mode = OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_270 + 4:
@@ -1596,10 +1611,10 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 - field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(screen_width * (fbh - 1) - 1 -
- (fieldmode ? 1 : 0),
+ *row_inc = pixinc(screen_width * (fbh * x_predecim - 1) -
+ y_predecim - (fieldmode ? 1 : 0),
ps);
- *pix_inc = pixinc(-screen_width, ps);
+ *pix_inc = pixinc(-x_predecim * screen_width, ps);
break;
default:
@@ -1686,13 +1701,17 @@ static unsigned long calc_fclk(enum omap_channel channel, u16 width,
static int dispc_ovl_calc_scaling(enum omap_plane plane,
enum omap_channel channel, u16 width, u16 height,
u16 out_width, u16 out_height,
- enum omap_color_mode color_mode, bool *five_taps)
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
const int maxsinglelinewidth dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ const int max_decim_limit = 16;
unsigned long fclk = 0;
+ int decim_x, decim_y, error, min_factor;
+ u16 in_width, in_height, in_width_max = 0;
if (width = out_width && height = out_height)
return 0;
@@ -1700,45 +1719,117 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) = 0)
return -EINVAL;
- if (out_width < width / maxdownscale ||
- out_width > width * 8)
+ *x_predecim = max_decim_limit;
+ *y_predecim = max_decim_limit;
+
+ if (color_mode = OMAP_DSS_COLOR_CLUT1 ||
+ color_mode = OMAP_DSS_COLOR_CLUT2 ||
+ color_mode = OMAP_DSS_COLOR_CLUT4 ||
+ color_mode = OMAP_DSS_COLOR_CLUT8) {
+ *x_predecim = 1;
+ *y_predecim = 1;
+ *five_taps = false;
+ return 0;
+ }
+
+ decim_x = DIV_ROUND_UP(DIV_ROUND_UP(width, out_width), maxdownscale);
+ decim_y = DIV_ROUND_UP(DIV_ROUND_UP(height, out_height), maxdownscale);
+
+ min_factor = min(decim_x, decim_y);
+
+ if (decim_x > *x_predecim || out_width > width * 8)
return -EINVAL;
- if (out_height < height / maxdownscale ||
- out_height > height * 8)
+ if (decim_y > *y_predecim || out_height > height * 8)
return -EINVAL;
if (cpu_is_omap24xx()) {
- if (width > maxsinglelinewidth)
- DSSERR("Cannot scale max input width exceeded");
*five_taps = false;
- fclk = calc_fclk(channel, width, height, out_width,
- out_height);
+
+ do {
+ in_height = DIV_ROUND_UP(height, decim_y);
+ in_width = DIV_ROUND_UP(width, decim_x);
+ fclk = calc_fclk(channel, in_width, in_height,
+ out_width, out_height);
+ error = (in_width > maxsinglelinewidth || !fclk ||
+ fclk > dispc_fclk_rate());
+ if (error) {
+ if (decim_x = decim_y) {
+ decim_x = min_factor;
+ decim_y++;
+ } else {
+ swap(decim_x, decim_y);
+ if (decim_x < decim_y)
+ decim_x++;
+ }
+ }
+ } while (decim_x <= *x_predecim && decim_y <= *y_predecim &&
+ error);
+
+ if (in_width > maxsinglelinewidth) {
+ DSSERR("Cannot scale max input width exceeded");
+ return -EINVAL;
+ }
} else if (cpu_is_omap34xx()) {
- if (width > (maxsinglelinewidth * 2)) {
+
+ do {
+ in_height = DIV_ROUND_UP(height, decim_y);
+ in_width = DIV_ROUND_UP(width, decim_x);
+ fclk = calc_fclk_five_taps(channel, in_width, in_height,
+ out_width, out_height, color_mode);
+
+ if (in_width > maxsinglelinewidth)
+ if (in_height > out_height &&
+ in_height < out_height * 2)
+ *five_taps = false;
+ if (!*five_taps)
+ fclk = calc_fclk(channel, in_width, in_height,
+ out_width, out_height);
+ error = (in_width > maxsinglelinewidth * 2 ||
+ (in_width > maxsinglelinewidth && *five_taps) ||
+ !fclk || fclk > dispc_fclk_rate());
+ if (error) {
+ if (decim_x = decim_y) {
+ decim_x = min_factor;
+ decim_y++;
+ } else {
+ swap(decim_x, decim_y);
+ if (decim_x < decim_y)
+ decim_x++;
+ }
+ }
+ } while (decim_x <= *x_predecim && decim_y <= *y_predecim
+ && error);
+
+ if (in_width > (maxsinglelinewidth * 2)) {
DSSERR("Cannot setup scaling");
DSSERR("width exceeds maximum width possible");
return -EINVAL;
}
- fclk = calc_fclk_five_taps(channel, width, height, out_width,
- out_height, color_mode);
- if (width > maxsinglelinewidth) {
- if (height > out_height && height < out_height * 2)
- *five_taps = false;
- else {
- DSSERR("cannot setup scaling with five taps");
- return -EINVAL;
- }
+
+ if (in_width > maxsinglelinewidth && *five_taps) {
+ DSSERR("cannot setup scaling with five taps");
+ return -EINVAL;
}
- if (!*five_taps)
- fclk = calc_fclk(channel, width, height, out_width,
- out_height);
} else {
- if (width > maxsinglelinewidth) {
+ in_height = DIV_ROUND_UP(height, decim_y);
+ in_width_max = dispc_fclk_rate() /
+ DIV_ROUND_UP(dispc_mgr_pclk_rate(channel),
+ out_width);
+ decim_x = DIV_ROUND_UP(width, in_width_max);
+ if (decim_x > *x_predecim)
+ return -EINVAL;
+ do {
+ in_width = DIV_ROUND_UP(width, decim_x);
+ } while (decim_x <= *x_predecim &&
+ in_width > maxsinglelinewidth && decim_x++);
+
+ if (in_width > maxsinglelinewidth) {
DSSERR("Cannot scale width exceeds max line width");
return -EINVAL;
}
- fclk = calc_fclk(channel, width, height, out_width,
+
+ fclk = calc_fclk(channel, in_width, in_height, out_width,
out_height);
}
@@ -1753,6 +1844,8 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
return -EINVAL;
}
+ *x_predecim = decim_x;
+ *y_predecim = decim_y;
return 0;
}
@@ -1768,8 +1861,11 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
s32 pix_inc;
u16 frame_height = oi->height;
unsigned int field_offset = 0;
- u16 outw, outh;
+ u16 in_height = oi->height;
+ u16 in_width = oi->width;
+ u16 out_width, out_height;
enum omap_channel channel;
+ int x_predecim = 1, y_predecim = 1;
channel = dispc_ovl_get_channel_out(plane);
@@ -1783,32 +1879,35 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
if (oi->paddr = 0)
return -EINVAL;
- outw = oi->out_width = 0 ? oi->width : oi->out_width;
- outh = oi->out_height = 0 ? oi->height : oi->out_height;
+ out_width = oi->out_width = 0 ? oi->width : oi->out_width;
+ out_height = oi->out_height = 0 ? oi->height : oi->out_height;
- if (ilace && oi->height = outh)
+ if (ilace && oi->height = out_height)
fieldmode = 1;
if (ilace) {
if (fieldmode)
- oi->height /= 2;
+ in_height /= 2;
oi->pos_y /= 2;
- outh /= 2;
+ out_height /= 2;
DSSDBG("adjusting for ilace: height %d, pos_y %d, "
"out_height %d\n",
- oi->height, oi->pos_y, outh);
+ in_height, oi->pos_y, out_height);
}
if (!dss_feat_color_mode_supported(plane, oi->color_mode))
return -EINVAL;
- r = dispc_ovl_calc_scaling(plane, channel, oi->width, oi->height,
- outw, outh, oi->color_mode,
- &five_taps);
+ r = dispc_ovl_calc_scaling(plane, channel, in_width, in_height,
+ out_width, out_height, oi->color_mode, &five_taps,
+ &x_predecim, &y_predecim);
if (r)
return r;
+ in_width = DIV_ROUND_UP(in_width, x_predecim);
+ in_height = DIV_ROUND_UP(in_height, y_predecim);
+
if (oi->color_mode = OMAP_DSS_COLOR_YUV2 ||
oi->color_mode = OMAP_DSS_COLOR_UYVY ||
oi->color_mode = OMAP_DSS_COLOR_NV12)
@@ -1822,10 +1921,10 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
* so the integer part must be added to the base address of the
* bottom field.
*/
- if (!oi->height || oi->height = outh)
+ if (!in_height || in_height = out_height)
field_offset = 0;
else
- field_offset = oi->height / outh / 2;
+ field_offset = in_height / out_height / 2;
}
/* Fields are independent but interleaved in memory. */
@@ -1834,14 +1933,16 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
if (oi->rotation_type = OMAP_DSS_ROT_DMA)
calc_dma_rotation_offset(oi->rotation, oi->mirror,
- oi->screen_width, oi->width, frame_height,
+ oi->screen_width, in_width, frame_height,
oi->color_mode, fieldmode, field_offset,
- &offset0, &offset1, &row_inc, &pix_inc);
+ &offset0, &offset1, &row_inc, &pix_inc,
+ x_predecim, y_predecim);
else
calc_vrfb_rotation_offset(oi->rotation, oi->mirror,
- oi->screen_width, oi->width, frame_height,
+ oi->screen_width, in_width, frame_height,
oi->color_mode, fieldmode, field_offset,
- &offset0, &offset1, &row_inc, &pix_inc);
+ &offset0, &offset1, &row_inc, &pix_inc,
+ x_predecim, y_predecim);
DSSDBG("offset0 %u, offset1 %u, row_inc %d, pix_inc %d\n",
offset0, offset1, row_inc, pix_inc);
@@ -1860,19 +1961,18 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
dispc_ovl_set_row_inc(plane, row_inc);
dispc_ovl_set_pix_inc(plane, pix_inc);
- DSSDBG("%d,%d %dx%d -> %dx%d\n", oi->pos_x, oi->pos_y, oi->width,
- oi->height, outw, outh);
+ DSSDBG("%d,%d %dx%d -> %dx%d\n", oi->pos_x, oi->pos_y, in_width,
+ in_height, out_width, out_height);
dispc_ovl_set_pos(plane, oi->pos_x, oi->pos_y);
- dispc_ovl_set_pic_size(plane, oi->width, oi->height);
+ dispc_ovl_set_pic_size(plane, in_width, in_height);
if (ovl->caps & OMAP_DSS_OVL_CAP_SCALE) {
- dispc_ovl_set_scaling(plane, oi->width, oi->height,
- outw, outh,
- ilace, five_taps, fieldmode,
+ dispc_ovl_set_scaling(plane, in_width, in_height, out_width,
+ out_height, ilace, five_taps, fieldmode,
oi->color_mode, oi->rotation);
- dispc_ovl_set_vid_size(plane, outw, outh);
+ dispc_ovl_set_vid_size(plane, out_width, out_height);
dispc_ovl_set_vid_color_conv(plane, cconv);
}
--
1.7.1
^ permalink raw reply related
* [PATCH V2 0/3] OMAPDSS: DISPC: Enable predecimation for DMA and VRFB
From: Chandrabhanu Mahapatra @ 2012-03-21 9:52 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
Hi everyone,
the following patch set directs to enable predecimation for DMA and VRFB
which consists of two pacthes.
The first patch is based on code written by Lajos Molnar <lajos@ti.com> in
Android Kernel, which updates the code with predecimation logic thereby
increasing the downscaling ability of the DISPC module.
In version 2 patch description has been modified include reason for maximum
predecimation limit of 16.
The second patch is based on code written by Ville Syrjälä
<ville.syrjala@nokia.com> which aims to avoid synclost errors occurring
in OMAP3 due to some undocumented horizontal position and timing related
limitations which I faced during testing of the previous patch.
In version 2 the pcd factor has been replaced lclk / pclk to support HDMI and
tv output as pointed out by Ville Syrjälä.
The third patch corrects the usage of dispc fclk in scaling checks by
replacing it with dispc_core_clk as per suggestions of Ville Syrjälä.
I have tested these patches successfully on OMAP2, OMAP3 AND OMAP4 on the
mainline kernel v3.3. Horizontal and vertical predecimation worked fine
but skewed images were seen on OMAP2 and OMAP3 on HDMI tv during horizontal
predecimation which will be addressed in the future patches.
All your comments and suggestions are welcome.
Regards,
Chandrabhanu
Chandrabhanu Mahapatra (3):
OMAPDSS: DISPC: Enable predecimation
OMAPDSS: DISPC: Handle synclost errors in OMAP3
OMAPDSS: DISPC: Correct DISPC functional clock usage
drivers/video/omap2/dss/dispc.c | 360 +++++++++++++++++++++++++++------------
1 files changed, 254 insertions(+), 106 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] x86: export 'pcibios_enabled' as GPL
From: Alan Cox @ 2012-03-21 9:29 UTC (permalink / raw)
To: Wang YanQing
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, Florian Tobias Schandinat, linux-fbdev, x86,
Andrew Morton, tglx, mingo, hpa
In-Reply-To: <20120321043721.GA927@udknight>
On Wed, 21 Mar 2012 12:37:21 +0800
Wang YanQing <udknight@gmail.com> wrote:
> On Sun, Mar 18, 2012 at 06:03:41PM -0700, Randy Dunlap wrote:
> > From: Randy Dunlap <rdunlap@xenotime.net>
> >
> > Export 'pcibios_enabled' so that when uvesafb is built as a
> > loadable module (on X86_32), the build will succeed.
> >
> > ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
> >
> > Patch v2 uses EXPORT_SYMBOL_GPL() as requested.
> >
> > Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> > Cc: Michal Januszewski <spock@gentoo.org>
> > Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: x86@kernel.org
> > ---
> > arch/x86/pci/pcbios.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > --- linux-next-20120313.orig/arch/x86/pci/pcbios.c
> > +++ linux-next-20120313/arch/x86/pci/pcbios.c
> > @@ -27,6 +27,7 @@
> > #define PCIBIOS_HW_TYPE2_SPEC 0x20
> >
> > int pcibios_enabled;
> > +EXPORT_SYMBOL_GPL(pcibios_enabled);
> >
> > /* According to the BIOS specification at:
> > * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
> Acked-by: Wang YanQing <udknight@gmail.com>
NAKked again by Alan Cox <alan@linux.intel.com>
The fb code shouldn't be playing guessing games with thsi variable.
I've pointed out both how to check if NX is enabled and how to set pages
NX/non-NX.
Even if you wanted to check the pci bios state we should export a helper
method.
So NAK.
Alan
^ permalink raw reply
* Re: [PATCH v2] x86: export 'pcibios_enabled' as GPL
From: Wang YanQing @ 2012-03-21 4:37 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Michal Januszewski,
Florian Tobias Schandinat, linux-fbdev, x86, Andrew Morton, tglx,
mingo, hpa
In-Reply-To: <4F6685ED.7040000@xenotime.net>
On Sun, Mar 18, 2012 at 06:03:41PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Export 'pcibios_enabled' so that when uvesafb is built as a
> loadable module (on X86_32), the build will succeed.
>
> ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
>
> Patch v2 uses EXPORT_SYMBOL_GPL() as requested.
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: Michal Januszewski <spock@gentoo.org>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: x86@kernel.org
> ---
> arch/x86/pci/pcbios.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20120313.orig/arch/x86/pci/pcbios.c
> +++ linux-next-20120313/arch/x86/pci/pcbios.c
> @@ -27,6 +27,7 @@
> #define PCIBIOS_HW_TYPE2_SPEC 0x20
>
> int pcibios_enabled;
> +EXPORT_SYMBOL_GPL(pcibios_enabled);
>
> /* According to the BIOS specification at:
> * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
Acked-by: Wang YanQing <udknight@gmail.com>
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-21 3:00 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1332269710.3921.31.camel@debian.Gayathri>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 5181 bytes --]
æ–¼ 三，2012-03-21 æ–¼ 00:25 +0530，Pradeep Subrahmanion æ到：
> > >From 5da43d2ee6c87dcf17fda34f0b50fe11b04a16bf Mon Sep 17 00:00:00 2001
> > From: "Lee, Chun-Yi" <jlee@suse.com>
> > Date: Tue, 20 Mar 2012 19:00:58 +0800
> > Subject: [PATCH] acer-wmi: add quirk table for video backlight vendor mode
> >
> > There have some acer laptop have broken _BCM implemenation, the AML
> > code wrote value to EC register but firmware didn't change brighenss.
> >
> > Fortunately, the brightness control works on those machines with
> > vendor mode. So, add quirk table for video backlight vendor mode
> > and unregister acpi video interface on those machines.
> >
> > Tested on Acer TravelMate 4750
> >
> > Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> > ---
> > drivers/platform/x86/Kconfig | 4 ++++
> > drivers/platform/x86/acer-wmi.c | 38 +++++++++++++++++++++++++++++++++++---
> > 2 files changed, 39 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 15dbd8c..fe3a494 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -26,6 +26,10 @@ config ACER_WMI
> > depends on RFKILL || RFKILL = n
> > depends on ACPI_WMI
> > select INPUT_SPARSEKMAP
> > + # Acer WMI depends on ACPI_VIDEO when ACPI is enabled
> > + # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> > + select VIDEO_OUTPUT_CONTROL if ACPI
> > + select ACPI_VIDEO if ACPI
> > ---help---
> > This is a driver for newer Acer (and Wistron) laptops. It adds
> > wireless radio and bluetooth control, and on some laptops,
> > diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> > index 1e5290b..984a7b5 100644
> > --- a/drivers/platform/x86/acer-wmi.c
> > +++ b/drivers/platform/x86/acer-wmi.c
> > @@ -43,6 +43,7 @@
> > #include <linux/input/sparse-keymap.h>
> >
> > #include <acpi/acpi_drivers.h>
> > +#include <acpi/video.h>
> >
> > MODULE_AUTHOR("Carlos Corbacho");
> > MODULE_DESCRIPTION("Acer Laptop WMI Extras Driver");
> > @@ -478,6 +479,33 @@ static struct dmi_system_id acer_quirks[] = {
> > {}
> > };
> >
> > +static int video_set_backlight_video_vendor(const struct dmi_system_id *d)
> > +{
> > + interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > + pr_info("Brightness must be controlled by generic video driver\n");
> > + return 0;
> > +}
> > +
> > +static const struct dmi_system_id video_vendor_dmi_table[] = {
> > + {
> > + .callback = video_set_backlight_video_vendor,
> > + .ident = "Acer Aspire 4736",
> > + .matches = {
> > + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 4736"),
> > + },
> > + },
> > + {
> > + .callback = video_set_backlight_video_vendor,
> > + .ident = "Acer TravelMate 4750",
> > + .matches = {
> > + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
> > + },
> > + },
> > + {}
> > +};
> > +
> > /* Find which quirks are needed for a particular vendor/ model pair */
> > static void find_quirks(void)
> > {
> > @@ -1981,9 +2009,13 @@ static int __init acer_wmi_init(void)
> > set_quirks();
> >
> > if (acpi_video_backlight_support()) {
> > - interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > - pr_info("Brightness must be controlled by "
> > - "generic video driver\n");
> > + if (dmi_check_system(video_vendor_dmi_table)) {
> > + acpi_video_unregister();
> > + } else {
> > + interface->capability &= ~ACER_CAP_BRIGHTNESS;
> > + pr_info("Brightness must be controlled by "
> > + "acpi video driver\n");
> > + }
> > }
> >
> > if (wmi_has_guid(WMID_GUID3)) {
>
> I tried out applied your patch . Boot message shows ,
>
> [11.220410] acer_wmi: Brightness must be controlled by generic video
> driver
>
> Now 'acpi_video0' and 'intel_backlight' are present
> inside /sys/class/backlight .Hot key works like earlier ( ie problem
> after maximum level still exists).
> I tried following commands ,
>
It's not the expected behavior.
This new patch should remove acpi_video0 interface on your machine.
Please kindly provide your dmidecode:
dmidecode > dmidecode.log
And,
please make should the patch really applied, you can do a bit change on
pr_info message by yourself.
> echo 5 > /sys/class/backlight/acpi_video0/brightness
> echo 5 > /sys/class/backlight/intel_backlight/brightness
>
> But it doesn't make any change .
>
> In my case , 'acpi_backlight = vendor' does not make any difference since the hot key control
>
> already starts working with 'acpi_osi=Linux' option.
>
> cat /proc/cmdline gives ,
>
> BOOT_IMAGE=/boot/vmlinuz-3.3.0+
> root=UUIDð197a59-c067-4fd8-ad90-c4d721816077 ro acpi_osi=Linux
>
>
> Thanks ,
>
> Pradeep Subrahmanion
>
OK, that's more clearly, please remove acpi_osi=Linux then re-test, I
think the hotkey of backlight control only works with acpi_osi=Linux ?
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] fbdev: sh_mipi_dsi: add extra phyctrl for sh_mipi_dsi_info
From: Kuninori Morimoto @ 2012-03-21 1:34 UTC (permalink / raw)
To: linux-fbdev
sh_mipi uses some clocks, but the method of setup depends on CPU.
Current SuperH (like sh73a0) can control all of these clocks
by CPG (Clock Pulse Generator).
It means we can control it by clock framework only.
But on sh7372, it needs CPG settings AND sh_mipi PHYCTRL::PLLDS,
and only sh7372 has PHYCTRL::PLLDS.
But on current sh_mipi driver, PHYCTRL::PLLDS of sh7372 was
overwrote since the callback timing of clock setting was changed
by c2658b70f06108361aa5024798f9c1bf47c73374
(fbdev: sh_mipi_dsi: fixup setup timing of sh_mipi_setup()).
To solve this issue, this patch adds extra .phyctrl.
This patch adds detail explanation for unclear mipi settings
and fixup wrong PHYCTRL::PLLDS value for ap4evb (0xb -> 0x6).
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2
- fixup wrong MHz (321 -> 312)
- Adds explain that this patch fixup wrong PLLDS value for ap4evb
arch/arm/mach-shmobile/board-ap4evb.c | 12 +++++++++---
drivers/video/sh_mipi_dsi.c | 2 +-
include/video/sh_mipi_dsi.h | 1 +
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index eeb4d96..50fcf1b 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -556,20 +556,25 @@ static struct platform_device keysc_device = {
};
/* MIPI-DSI */
-#define PHYCTRL 0x0070
static int sh_mipi_set_dot_clock(struct platform_device *pdev,
void __iomem *base,
int enable)
{
struct clk *pck = clk_get(&pdev->dev, "dsip_clk");
- void __iomem *phy = base + PHYCTRL;
if (IS_ERR(pck))
return PTR_ERR(pck);
if (enable) {
+ /*
+ * DSIPCLK = 24MHz
+ * D-PHY = DSIPCLK * ((0x6*2)+1) = 312MHz (see .phyctrl)
+ * HsByteCLK = D-PHY/8 = 39MHz
+ *
+ * X * Y * FPS + * (544+72+600+16) * (961+8+8+2) * 30 = 36.1MHz
+ */
clk_set_rate(pck, clk_round_rate(pck, 24000000));
- iowrite32(ioread32(phy) | (0xb << 8), phy);
clk_enable(pck);
} else {
clk_disable(pck);
@@ -598,6 +603,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
.lcd_chan = &lcdc_info.ch[0],
.lane = 2,
.vsynw_offset = 17,
+ .phyctrl = 0x6 << 8,
.flags = SH_MIPI_DSI_SYNC_PULSES_MODE |
SH_MIPI_DSI_HSbyteCLK,
.set_dot_clock = sh_mipi_set_dot_clock,
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 05151b8..214482c 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -271,7 +271,7 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
iowrite32(0x00000001, base + PHYCTRL);
udelay(200);
/* Deassert resets, power on */
- iowrite32(0x03070001, base + PHYCTRL);
+ iowrite32(0x03070001 | pdata->phyctrl, base + PHYCTRL);
/*
* Default = ULPS enable |
diff --git a/include/video/sh_mipi_dsi.h b/include/video/sh_mipi_dsi.h
index 434d56b..06c67fb 100644
--- a/include/video/sh_mipi_dsi.h
+++ b/include/video/sh_mipi_dsi.h
@@ -51,6 +51,7 @@ struct sh_mipi_dsi_info {
int lane;
unsigned long flags;
u32 clksrc;
+ u32 phyctrl; /* for extra setting */
unsigned int vsynw_offset;
int (*set_dot_clock)(struct platform_device *pdev,
void __iomem *base,
--
1.7.5.4
^ permalink raw reply related
* [PATCH v4] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Kuninori Morimoto @ 2012-03-21 1:27 UTC (permalink / raw)
To: linux-fbdev
MERAM can be used for other IP blocks as well in the future.
It doesn't necessarily mean that the MERAM driver depends on the LCDC.
This patch corrects dependency.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v3 -> v4
- move config to before endpoint
drivers/video/Kconfig | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 8951cbd..0fb9540 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2013,18 +2013,6 @@ config FB_SH_MOBILE_HDMI
---help---
Driver for the on-chip SH-Mobile HDMI controller.
-config FB_SH_MOBILE_MERAM
- tristate "SuperH Mobile MERAM read ahead support for LCDC"
- depends on FB_SH_MOBILE_LCDC
- default y
- ---help---
- Enable MERAM support for the SH-Mobile LCD controller.
-
- This will allow for caching of the framebuffer to provide more
- reliable access under heavy main memory bus traffic situations.
- Up to 4 memory channels can be configured, allowing 4 RGB or
- 2 YCbCr framebuffers to be configured.
-
config FB_TMIO
tristate "Toshiba Mobile IO FrameBuffer support"
depends on FB && MFD_CORE
@@ -2434,4 +2422,15 @@ if FB || SGI_NEWPORT_CONSOLE
source "drivers/video/logo/Kconfig"
endif
+config FB_SH_MOBILE_MERAM
+ tristate "SuperH Mobile MERAM read ahead support"
+ depends on (SUPERH || ARCH_SHMOBILE)
+ ---help---
+ Enable MERAM support for the SuperH controller.
+
+ This will allow for caching of the framebuffer to provide more
+ reliable access under heavy main memory bus traffic situations.
+ Up to 4 memory channels can be configured, allowing 4 RGB or
+ 2 YCbCr framebuffers to be configured.
+
endmenu
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v3] fbdev: remove dependency of FB_SH_MOBILE_MERAM from FB_SH_MOBILE_LCDC
From: Kuninori Morimoto @ 2012-03-21 1:10 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <87d38qwmi9.wl%kuninori.morimoto.gx@renesas.com>
Hi Florian
> > MERAM can be used for other IP blocks as well in the future.
> > It doesn't necessarily mean that the MERAM driver depends on the LCDC.
> > This patch corrects dependency.
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
> > v2 -> v3
> >
> > - move config FB_SH_MOBILE_MERAM out of "choice"
>
> I am afraid but this is still not correct. The problem is that after
> your patch this config option has no longer any dependency on the
> framebuffer subsystem. As "FB" is a menuconfig option I guess the first
> config option without any direct or indirect dependency on FB terminates
> the menu. As I don't understand how this driver is used I don't know how
> I should resolve this: either leave it where it is and just add an
> dependency on "FB" or move it even further down, probably just before
> endmenu (AFAIK the first thing that breaks it is OMAP2).
Thank you for checking my patch.
And sorry for breaking menuconfig
As Laurent/Hayama-san said that the MERAM will be used
from VIDEO_SH_MOBILE_CEU (${LINUX}/drivers/media/video/Kconfig)
in the future.
I move it to before endmenu (without "FB" dependency)
Best regards
---
Kuninori Morimoto
^ permalink raw reply
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