* [PATCH 1/2] fbdev: da8xx:: fix reporting of the display timing info
From: Anatolij Gustschin @ 2012-03-09 15:02 UTC (permalink / raw)
To: linux-fbdev
Timing info is not properly reported by the driver, e.g.:
$ fbset -i
mode "480x272-95"
# D: 21.429 MHz, H: 33.018 kHz, V: 95.429 Hz
geometry 480 272 480 544 16
timings 46666 64 64 32 32 41 10
According to the timing values defined for LK043T1DG01 display
it should be reported as:
mode "480x272-52"
# D: 7.834 MHz, H: 14.921 kHz, V: 51.810 Hz
geometry 480 272 480 544 16
timings 127655 2 2 2 2 41 10
Initialize additional fb_var_screeninfo fields so fix this problem.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Manjunathappa, Prakash <prakash.pm@ti.com>
---
drivers/video/da8xx-fb.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 29577bf..27c2794 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -240,6 +240,14 @@ static struct da8xx_panel known_lcd_panels[] = {
},
};
+static inline unsigned long hz_to_ps(unsigned long hz_val)
+{
+ unsigned long long num = 1000000000000ULL;
+
+ do_div(num, hz_val);
+ return (unsigned long)num;
+}
+
/* Enable the Raster Engine of the LCD Controller */
static inline void lcd_enable_raster(void)
{
@@ -1209,6 +1217,11 @@ static int __devinit fb_probe(struct platform_device *device)
da8xx_fb_var.hsync_len = lcdc_info->hsw;
da8xx_fb_var.vsync_len = lcdc_info->vsw;
+ da8xx_fb_var.right_margin = lcdc_info->hfp;
+ da8xx_fb_var.left_margin = lcdc_info->hbp;
+ da8xx_fb_var.lower_margin = lcdc_info->vfp;
+ da8xx_fb_var.upper_margin = lcdc_info->vbp;
+ da8xx_fb_var.pixclock = hz_to_ps(lcdc_info->pxl_clk);
/* Initialize fbinfo */
da8xx_fb_info->flags = FBINFO_FLAG_DEFAULT;
--
1.7.7.6
^ permalink raw reply related
* [PATCH 0/2] some da8xx-fb driver updates
From: Anatolij Gustschin @ 2012-03-09 15:02 UTC (permalink / raw)
To: linux-fbdev
fbdev: da8xx:: fix reporting of the display timing info
fbdev: da8xx: add support for SP10Q010 display
drivers/video/Kconfig | 1 +
drivers/video/da8xx-fb.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 51 insertions(+), 1 deletions(-)
--
1.7.7.6
^ permalink raw reply
* RE: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
From: Inki Dae @ 2012-03-09 0:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1331206495-3853-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Laurent,
> -----Original Message-----
> From: Joonyoung Shim [mailto:jy0922.shim@samsung.com]
> Sent: Thursday, March 08, 2012 10:06 PM
> To: Laurent Pinchart
> Cc: dri-devel@lists.freedesktop.org; linux-fbdev@vger.kernel.org; Inki
Dae;
> Seung-Woo Kim; Kyungmin Park
> Subject: Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo
> conversion
>
> On 03/08/2012 08:34 PM, Laurent Pinchart wrote:
> > The fb_videomode structure stores the front porch and back porch in the
> > right_margin and left_margin fields respectively. right_margin should
> > thus be computed with hsync_start - hdisplay, and left_margin with
> > htotal - hsync_end. The same holds for the vertical direction.
> >
> > Active Front Sync Back
> > Region Porch Porch
> > <-------------------><----------------><-------------><---------------->
> >
> > //////////////////|
> > ////////////////// |
> > ////////////////// |.................. ..................
> > _______________
> >
> > <------ xres -------><- right_margin -><- hsync_len -><- left_margin -->
> >
> > <---- hdisplay ----->
> > <------------ hsync_start ------------>
> > <--------------------- hsync_end -------------------->
> > <--------------------------------- htotal ----------------------------->
> >
> > Fix the fb_videomode<-> drm_mode_modeinfo conversion functions
> > accordingly.
> >
> > Signed-off-by: Laurent Pinchart<laurent.pinchart@ideasonboard.com>
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_connector.c | 16 ++++++++--------
> > 1 files changed, 8 insertions(+), 8 deletions(-)
> >
> > While trying to understand how the fb_videomode and drm_mode_modeinfo
> fields
> > map to each other, I found what might be a bug in the Exynos DRM driver.
> Could
> > you please check and confirm that my understanding is correct ?
>
> Good catch. You can refer Documentation/fb/framebuffer.txt to know in
> detail.
>
> Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
>
> Thanks.
>
it seems like that you doesn't use latest exynos drm driver so I merged it
manually
for this, you can refer to this link:
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exyn
os-drm-fixes
Thanks,
Inki Dae
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> > index d620b07..7bb1dca 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> > @@ -52,14 +52,14 @@ convert_to_display_mode(struct drm_display_mode
> *mode,
> > mode->vrefresh = timing->refresh;
> >
> > mode->hdisplay = timing->xres;
> > - mode->hsync_start = mode->hdisplay + timing->left_margin;
> > + mode->hsync_start = mode->hdisplay + timing->right_margin;
> > mode->hsync_end = mode->hsync_start + timing->hsync_len;
> > - mode->htotal = mode->hsync_end + timing->right_margin;
> > + mode->htotal = mode->hsync_end + timing->left_margin;
> >
> > mode->vdisplay = timing->yres;
> > - mode->vsync_start = mode->vdisplay + timing->upper_margin;
> > + mode->vsync_start = mode->vdisplay + timing->lower_margin;
> > mode->vsync_end = mode->vsync_start + timing->vsync_len;
> > - mode->vtotal = mode->vsync_end + timing->lower_margin;
> > + mode->vtotal = mode->vsync_end + timing->upper_margin;
> >
> > if (timing->vmode& FB_VMODE_INTERLACED)
> > mode->flags |= DRM_MODE_FLAG_INTERLACE;
> > @@ -81,14 +81,14 @@ convert_to_video_timing(struct fb_videomode *timing,
> > timing->refresh = drm_mode_vrefresh(mode);
> >
> > timing->xres = mode->hdisplay;
> > - timing->left_margin = mode->hsync_start - mode->hdisplay;
> > + timing->right_margin = mode->hsync_start - mode->hdisplay;
> > timing->hsync_len = mode->hsync_end - mode->hsync_start;
> > - timing->right_margin = mode->htotal - mode->hsync_end;
> > + timing->left_margin = mode->htotal - mode->hsync_end;
> >
> > timing->yres = mode->vdisplay;
> > - timing->upper_margin = mode->vsync_start - mode->vdisplay;
> > + timing->lower_margin = mode->vsync_start - mode->vdisplay;
> > timing->vsync_len = mode->vsync_end - mode->vsync_start;
> > - timing->lower_margin = mode->vtotal - mode->vsync_end;
> > + timing->upper_margin = mode->vtotal - mode->vsync_end;
> >
> > if (mode->flags& DRM_MODE_FLAG_INTERLACE)
> > timing->vmode = FB_VMODE_INTERLACED;
^ permalink raw reply
* [PATCH] OMAPDSS: OMAPFB: check for matching memory size early
From: Grazvydas Ignotas @ 2012-03-09 0:42 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-omap, Tomi Valkeinen, Grazvydas Ignotas
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..
drivers/video/omap2/omapfb/omapfb-ioctl.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index df7bcce..a0ac95c 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -225,6 +225,9 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
down_write_nested(&rg->lock, rg->id);
atomic_inc(&rg->lock_count);
+ if (rg->size = size && rg->type = mi->type)
+ goto out;
+
if (atomic_read(&rg->map_count)) {
r = -EBUSY;
goto out;
@@ -245,12 +248,10 @@ static int omapfb_setup_mem(struct fb_info *fbi, struct omapfb_mem_info *mi)
}
}
- if (rg->size != size || rg->type != mi->type) {
- r = omapfb_realloc_fbmem(fbi, size, mi->type);
- if (r) {
- dev_err(fbdev->dev, "realloc fbmem failed\n");
- goto out;
- }
+ r = omapfb_realloc_fbmem(fbi, size, mi->type);
+ if (r) {
+ dev_err(fbdev->dev, "realloc fbmem failed\n");
+ goto out;
}
out:
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] video:uvesafb: Fix oops that uvesafb try to execute NX-protected page
From: Michal Januszewski @ 2012-03-09 0:39 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: Wang YanQing, linux-fbdev, linux-kernel
In-Reply-To: <4F54669E.6080009@gmx.de>
Hi,
On Mon, Mar 5, 2012 at 08:09, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> On 03/05/2012 12:52 AM, Wang YanQing wrote:
>> On Fri, Mar 02, 2012 at 08:48:50AM +0800, Wang YanQing wrote:
>>>
>>> Ok! I think I have learned to make thing simple and send to the right people:)
>
> That's right.
>
>>> This patch try to fix the oops below that catched in my machine
>
> This sounds like you didn't test it. I assume you did? So just write
> "This patch fixes the oops below"
>
>>>
>>> [  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>
>>> ---
>>> Â 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;
>>> --
>>> 1.7.9.2.315.g25a78
>>
>> Ok! Can anybody tell me why this patch had been ignored by community?
>> I try to find out what's wrong with this patch, but I failed to find it out.
>> So any comment is welcome.Thanks
>
> Patch looks okay to me. I will wait a few days to give Michal a chance to
> comment on it.
LGTM here as well.
Thanks,
--
Michal Januszewski
http://people.gentoo.org/spock
^ permalink raw reply
* Re: [RFC PATCH] video:backlight: add dimming sysfs node
From: Donghwa Lee @ 2012-03-09 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F587B1D.5080206@metafoo.de>
Hi,
On Thu, Mar 8, 2012ë…„ 18:25, Lars-Peter Clausen wrote:
> On 03/08/2012 07:52 AM, Donghwa Lee wrote:
>> In backlight class, update_status() callback function is mostly used to change
>> backlight brightness. When platform enter the dimming state, it is usually used.
>> But, I think dimming state can be defined variety of method including brightness.
>> So, it is need to differentiated node from brightness node.
>
> What do you mean by dimming? Completely blank the display or just lower the
> brightness to a certain level > 0? In the former case the bl_power sysfs
> node already exposes such functionality. In the later case can you give an
> example how this will be used and how a typical driver would implement this
> functionality?
>
The dimming usually means minimum backlight brightness status which is not
completely blank. Most backlight driver uses minimum brightness by using
update_status() callback function so far as I know.
But, I think sysfs node have to use only one goals. update_status() is normally
used to change brightness.
I think dimming is different from changing brightness function. Others
functionality can be added to dimming, for example, functionality to reduce
power consumption. In each drivers, some functionalities can be implemented
how to reduce power consumption in driver not only setting minimum brightness
to enter dimming state.
That is to say, dimming status can be defined many ways and be implemented by
developers. Just that time, I think dimming node is used to interface between
driver and platform.
Thank you,
Donghwa Lee
>>
>> In set_dimming() callback function, developers can define variety dimming functions.
>>
>> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
>> Signed-off-by: Inki Dae <inki.dae@samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>> drivers/video/backlight/backlight.c | 37 +++++++++++++++++++++++++++++++++++
>> include/linux/backlight.h | 9 ++++++++
>> 2 files changed, 46 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
>> index bf5b1ec..44a77e4 100644
>> --- a/drivers/video/backlight/backlight.c
>> +++ b/drivers/video/backlight/backlight.c
>> @@ -101,6 +101,43 @@ static void backlight_generate_event(struct backlight_device *bd,
>> sysfs_notify(&bd->dev.kobj, NULL, "actual_brightness");
>> }
>>
>> +static ssize_t backlight_store_dimming(struct device *dev,
>> + struct device_attribute *attr, const char *buf, size_t count)
>> +{
>> + int rc;
>> + struct backlight_device *bd = to_backlight_device(dev);
>> + unsigned long dimming;
>> +
>> + rc = strict_strtoul(buf, 0, &dimming);
>> + if (rc)
>> + return rc;
>> +
>> + if (dimming < 0)
>> + rc = -EINVAL;
>> + else {
>> + pr_debug("set dimming mode\n");
>> +
>> + if (dimming)
>> + bd->props.dimming = true;
>> + else
>> + bd->props.dimming = false;
>> +
>> + backlight_set_dimming(bd);
>> +
>> + rc = count;
>> + }
>> +
>> + return rc;
>> +}
>> +
>> +static ssize_t backlight_show_dimming(struct device *dev,
>> + struct device_attribute *attr,char *buf)
>> +{
>> + struct backlight_device *bd = to_backlight_device(dev);
>> +
>> + return sprintf(buf, "%d\n", bd->props.dimming);
>> +}
>> +
>> static ssize_t backlight_show_power(struct device *dev,
>> struct device_attribute *attr, char *buf)
>> {
>> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
>> index 5ffc6dd..823717e 100644
>> --- a/include/linux/backlight.h
>> +++ b/include/linux/backlight.h
>> @@ -55,10 +55,13 @@ struct backlight_ops {
>> /* Check if given framebuffer device is the one bound to this backlight;
>> return 0 if not, !=0 if it is. If NULL, backlight always matches the fb. */
>> int (*check_fb)(struct backlight_device *, struct fb_info *);
>> + /* Notify the backlight driver to enter the dimming state */
>> + int (*set_dimming)(struct backlight_device *);
>> };
>>
>> /* This structure defines all the properties of a backlight */
>> struct backlight_properties {
>> + bool dimming;
>> /* Current User requested brightness (0 - max_brightness) */
>> int brightness;
>> /* Maximal value for brightness (read-only) */
>> @@ -111,6 +114,12 @@ static inline void backlight_update_status(struct backlight_device *bd)
>> mutex_unlock(&bd->update_lock);
>> }
>>
>> +static inline void backlight_set_dimming(struct backlight_device *bd)
>> +{
>> + if (bd->ops && bd->ops->set_dimming)
>> + bd->ops->set_dimming(bd);
>> +}
>> +
>> extern struct backlight_device *backlight_device_register(const char *name,
>> struct device *dev, void *devdata, const struct backlight_ops *ops,
>> const struct backlight_properties *props);
>
>
^ permalink raw reply
* Re: [PATCH] fb: exynos: Fix MIPI/DSI front/back porch settings
From: Donghwa Lee @ 2012-03-09 0:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1331220954-13177-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi, Laurent,
On Fri, Mar 9, 2012 at 00:35 AM, Laurent Pinchart wrote:
> The exynos_mipi_dsi_set_main_disp_[hv]porch() functions take front and
> back porch arguments in that order. This maps to the fb_videomode
> right/lower_margin and left/upper_margin respectively. Fix the caller
> accordingly.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/video/exynos/exynos_mipi_dsi_common.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
It looks good to me.
Acked-by: Donghwa Lee <dh09.lee@samsung.com>
> diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c b/drivers/video/exynos/exynos_mipi_dsi_common.c
> index 14909c1..99f6451 100644
> --- a/drivers/video/exynos/exynos_mipi_dsi_common.c
> +++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
> @@ -738,11 +738,11 @@ int exynos_mipi_dsi_set_display_mode(struct mipi_dsim_device *dsim,
> if (dsim_config->auto_vertical_cnt = 0) {
> exynos_mipi_dsi_set_main_disp_vporch(dsim,
> dsim_config->cmd_allow,
> - timing->upper_margin,
> - timing->lower_margin);
> + timing->lower_margin,
> + timing->upper_margin);
> exynos_mipi_dsi_set_main_disp_hporch(dsim,
> - timing->left_margin,
> - timing->right_margin);
> + timing->right_margin,
> + timing->left_margin);
> exynos_mipi_dsi_set_main_disp_sync_area(dsim,
> timing->vsync_len,
> timing->hsync_len);
^ permalink raw reply
* Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
From: Laurent Pinchart @ 2012-03-08 18:08 UTC (permalink / raw)
To: James Simmons
Cc: linux-fbdev, Seung-Woo Kim, dri-devel, Inki Dae, Kyungmin Park
In-Reply-To: <alpine.LFD.2.02.1203081656160.1975@casper.infradead.org>
Hi James,
On Thursday 08 March 2012 16:57:21 James Simmons wrote:
> > The fb_videomode structure stores the front porch and back porch in the
> > right_margin and left_margin fields respectively. right_margin should
> > thus be computed with hsync_start - hdisplay, and left_margin with
> > htotal - hsync_end. The same holds for the vertical direction.
> >
> > Active Front Sync Back
> > Region Porch Porch
> >
> > <-------------------><----------------><-------------><---------------->
> >
> > //////////////////|
> >
> > ////////////////// |
> >
> > ////////////////// |.................. ..................
> >
> > _______________
> >
> > <------ xres -------><- right_margin -><- hsync_len -><- left_margin -->
> >
> > <---- hdisplay ----->
> > <------------ hsync_start ------------>
> > <--------------------- hsync_end -------------------->
> > <--------------------------------- htotal ----------------------------->
> >
> > Fix the fb_videomode <-> drm_mode_modeinfo conversion functions
> > accordingly.
>
> Wow I see this has remegered. Some time last year I posted a patch that
> had these routines in a generic format for people to use. I can repost
> them again if people are interested.
As part of the EDID parser rework, I will introduce a common structure to
describe video modes. Conversion functions between the common structures and
struct drm_mode_modeinfo, struct fb_videomode and struct v4l2_bt_timings will
be provided. Direct conversion between drm_mode_modeinfo and fb_videomode
should then disappear.
This being said, we could introduce add you conversion functions in the
meantime. I will then post a patch to remove them when the common video mode
structure will be pushed to mainline :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
From: Corbin Simpson @ 2012-03-08 18:02 UTC (permalink / raw)
To: James Simmons
Cc: linux-fbdev, Seung-Woo Kim, dri-devel, Inki Dae, Kyungmin Park
In-Reply-To: <alpine.LFD.2.02.1203081656160.1975@casper.infradead.org>
On Fri, Mar 9, 2012 at 12:57 AM, James Simmons <jsimmons@infradead.org> wrote:
> Wow I see this has remegered. Some time last year I posted a patch that
> had these routines in a generic format for people to use. I can repost
> them again if people are interested.
Yes please!
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
<MostAwesomeDude@gmail.com>
^ permalink raw reply
* [PATCH 2/2] viafb: avoid refresh and mode lookup in set_par
From: Florian Tobias Schandinat @ 2012-03-08 17:56 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1331229163.git.FlorianSchandinat@gmx.de>
As check_var already ensures that the mode is valid there is no need
to do those expensive lookups here again. The only thing that might
change is that the deprecated interface could report slightly
different refresh rates due to rounding errors.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/viafbdev.c | 32 ++++++++++++++------------------
1 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 7529340..0c88375 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -287,26 +287,22 @@ static int viafb_set_par(struct fb_info *info)
viafb_second_yres, viafb_bpp1, 1);
}
- refresh = viafb_get_refresh(info->var.xres, info->var.yres,
- get_var_refresh(&info->var));
- if (viafb_get_best_mode(viafbinfo->var.xres, viafbinfo->var.yres,
- refresh)) {
- if (viafb_dual_fb && viapar->iga_path = IGA2) {
- viafb_bpp1 = info->var.bits_per_pixel;
- viafb_refresh1 = refresh;
- } else {
- viafb_bpp = info->var.bits_per_pixel;
- viafb_refresh = refresh;
- }
-
- if (info->var.accel_flags & FB_ACCELF_TEXT)
- info->flags &= ~FBINFO_HWACCEL_DISABLED;
- else
- info->flags |= FBINFO_HWACCEL_DISABLED;
- viafb_setmode();
- viafb_pan_display(&info->var, info);
+ refresh = get_var_refresh(&info->var);
+ if (viafb_dual_fb && viapar->iga_path = IGA2) {
+ viafb_bpp1 = info->var.bits_per_pixel;
+ viafb_refresh1 = refresh;
+ } else {
+ viafb_bpp = info->var.bits_per_pixel;
+ viafb_refresh = refresh;
}
+ if (info->var.accel_flags & FB_ACCELF_TEXT)
+ info->flags &= ~FBINFO_HWACCEL_DISABLED;
+ else
+ info->flags |= FBINFO_HWACCEL_DISABLED;
+ viafb_setmode();
+ viafb_pan_display(&info->var, info);
+
return 0;
}
--
1.7.9
^ permalink raw reply related
* [PATCH 1/2] viafb: modetable conversion
From: Florian Tobias Schandinat @ 2012-03-08 17:56 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1331229163.git.FlorianSchandinat@gmx.de>
This patch converts the modetables used in viafb to
- remove the strange thing that sync_end and blanking_end contained
the length and not the absolute value
- remove hundreds of useless defines
- use fb_videomode and not our own definition so modes defined in
the subsystem and received via EDID are compatible with ours
As the modes are now stored in a flat structure and no longer in a
tree like thing the lookup time was increased but as it is a rare
event anyway it shouldn't matter. Otherwise the behaviour should be
the same as before.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/dvi.c | 2 +-
drivers/video/via/hw.c | 41 +--
drivers/video/via/hw.h | 4 +-
drivers/video/via/lcd.c | 53 +---
drivers/video/via/share.h | 331 --------------------
drivers/video/via/viamode.c | 713 ++++++-------------------------------------
drivers/video/via/viamode.h | 11 +-
7 files changed, 120 insertions(+), 1035 deletions(-)
diff --git a/drivers/video/via/dvi.c b/drivers/video/via/dvi.c
index 3312c81..6be72f0 100644
--- a/drivers/video/via/dvi.c
+++ b/drivers/video/via/dvi.c
@@ -176,7 +176,7 @@ void viafb_dvi_set_mode(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
struct fb_var_screeninfo dvi_var = *var;
- struct crt_mode_table *rb_mode;
+ const struct fb_videomode *rb_mode;
int maxPixelClock;
maxPixelClock = viaparinfo->shared->tmds_setting_info.max_pixel_clock;
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 411b7e9..898590d 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,7 +1467,8 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-static struct display_timing var_to_timing(const struct fb_var_screeninfo *var, u16 cxres, u16 cyres)
+struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+ u16 cxres, u16 cyres)
{
struct display_timing timing;
u16 dx = (var->xres - cxres) / 2, dy = (var->yres - cyres) / 2;
@@ -2011,20 +2012,20 @@ int viafb_setmode(void)
int viafb_get_refresh(int hres, int vres, u32 long_refresh)
{
- struct crt_mode_table *best;
+ const struct fb_videomode *best;
best = viafb_get_best_mode(hres, vres, long_refresh);
if (!best)
return 60;
- if (abs(best->refresh_rate - long_refresh) > 3) {
+ if (abs(best->refresh - long_refresh) > 3) {
if (hres = 1200 && vres = 900)
return 49; /* OLPC DCON only supports 50 Hz */
else
return 60;
}
- return best->refresh_rate;
+ return best->refresh;
}
static void device_off(void)
@@ -2118,26 +2119,16 @@ void viafb_set_dpa_gfx(int output_interface, struct GFX_DPA_SETTING\
}
void viafb_fill_var_timing_info(struct fb_var_screeninfo *var,
- struct crt_mode_table *mode)
+ const struct fb_videomode *mode)
{
- struct display_timing crt_reg;
-
- crt_reg = mode->crtc;
- var->pixclock = 1000000000 / (crt_reg.hor_total * crt_reg.ver_total)
- * 1000 / mode->refresh_rate;
- var->xres = crt_reg.hor_addr;
- var->yres = crt_reg.ver_addr;
- var->left_margin - crt_reg.hor_total - (crt_reg.hor_sync_start + crt_reg.hor_sync_end);
- var->right_margin = crt_reg.hor_sync_start - crt_reg.hor_addr;
- var->hsync_len = crt_reg.hor_sync_end;
- var->upper_margin - crt_reg.ver_total - (crt_reg.ver_sync_start + crt_reg.ver_sync_end);
- var->lower_margin = crt_reg.ver_sync_start - crt_reg.ver_addr;
- var->vsync_len = crt_reg.ver_sync_end;
- var->sync = 0;
- if (mode->h_sync_polarity = POSITIVE)
- var->sync |= FB_SYNC_HOR_HIGH_ACT;
- if (mode->v_sync_polarity = POSITIVE)
- var->sync |= FB_SYNC_VERT_HIGH_ACT;
+ var->pixclock = mode->pixclock;
+ var->xres = mode->xres;
+ var->yres = mode->yres;
+ var->left_margin = mode->left_margin;
+ var->right_margin = mode->right_margin;
+ var->hsync_len = mode->hsync_len;
+ var->upper_margin = mode->upper_margin;
+ var->lower_margin = mode->lower_margin;
+ var->vsync_len = mode->vsync_len;
+ var->sync = mode->sync;
}
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index cacedc1..6be243c 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,6 +637,8 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
+struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+ u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
void viafb_set_vclock(u32 CLK, int set_iga);
@@ -660,7 +662,7 @@ void viafb_set_dpa_gfx(int output_interface, struct GFX_DPA_SETTING\
int viafb_setmode(void);
void viafb_fill_var_timing_info(struct fb_var_screeninfo *var,
- struct crt_mode_table *mode);
+ const struct fb_videomode *mode);
void __devinit viafb_init_chip_info(int chip_type);
void __devinit viafb_init_dac(int set_iga);
int viafb_get_refresh(int hres, int vres, u32 float_refresh);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 6e52711..1650379 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -75,9 +75,6 @@ static void check_diport_of_integrated_lvds(
struct lvds_chip_information *plvds_chip_info,
struct lvds_setting_information
*plvds_setting_info);
-static struct display_timing lcd_centering_timging(struct display_timing
- mode_crt_reg,
- struct display_timing panel_crt_reg);
static inline bool check_lvds_chip(int device_id_subaddr, int device_id)
{
@@ -552,39 +549,34 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres,
int panel_hres = plvds_setting_info->lcd_panel_hres;
int panel_vres = plvds_setting_info->lcd_panel_vres;
u32 clock;
- struct display_timing mode_crt_reg, panel_crt_reg, timing;
- struct crt_mode_table *mode_crt_table, *panel_crt_table;
+ struct display_timing timing;
+ struct fb_var_screeninfo panel_var;
+ const struct fb_videomode *mode_crt_table, *panel_crt_table;
DEBUG_MSG(KERN_INFO "viafb_lcd_set_mode!!\n");
/* Get mode table */
mode_crt_table = viafb_get_best_mode(set_hres, set_vres, 60);
- mode_crt_reg = mode_crt_table->crtc;
/* Get panel table Pointer */
panel_crt_table = viafb_get_best_mode(panel_hres, panel_vres, 60);
- panel_crt_reg = panel_crt_table->crtc;
+ viafb_fill_var_timing_info(&panel_var, panel_crt_table);
DEBUG_MSG(KERN_INFO "bellow viafb_lcd_set_mode!!\n");
if (VT1636_LVDS = plvds_chip_info->lvds_chip_name)
viafb_init_lvds_vt1636(plvds_setting_info, plvds_chip_info);
- clock = panel_crt_reg.hor_total * panel_crt_reg.ver_total
- * panel_crt_table->refresh_rate;
+ clock = PICOS2KHZ(panel_crt_table->pixclock) * 1000;
plvds_setting_info->vclk = clock;
if (set_iga = IGA2 && (set_hres < panel_hres || set_vres < panel_vres)
&& plvds_setting_info->display_method = LCD_EXPANDSION) {
- timing = panel_crt_reg;
+ timing = var_to_timing(&panel_var, panel_hres, panel_vres);
load_lcd_scaling(set_hres, set_vres, panel_hres, panel_vres);
} else {
- timing = lcd_centering_timging(mode_crt_reg, panel_crt_reg);
+ timing = var_to_timing(&panel_var, set_hres, set_vres);
if (set_iga = IGA2)
/* disable scaling */
via_write_reg_mask(VIACR, 0x79, 0x00,
BIT0 + BIT1 + BIT2);
}
- timing.hor_blank_end += timing.hor_blank_start;
- timing.hor_sync_end += timing.hor_sync_start;
- timing.ver_blank_end += timing.ver_blank_start;
- timing.ver_sync_end += timing.ver_sync_start;
if (set_iga = IGA1)
via_set_primary_timing(&timing);
else if (set_iga = IGA2)
@@ -968,37 +960,6 @@ void __devinit viafb_init_lvds_output_interface(struct lvds_chip_information
}
}
-static struct display_timing lcd_centering_timging(struct display_timing
- mode_crt_reg,
- struct display_timing panel_crt_reg)
-{
- struct display_timing crt_reg;
-
- crt_reg.hor_total = panel_crt_reg.hor_total;
- crt_reg.hor_addr = mode_crt_reg.hor_addr;
- crt_reg.hor_blank_start - (panel_crt_reg.hor_addr - mode_crt_reg.hor_addr) / 2 +
- crt_reg.hor_addr;
- crt_reg.hor_blank_end = panel_crt_reg.hor_blank_end;
- crt_reg.hor_sync_start - (panel_crt_reg.hor_sync_start -
- panel_crt_reg.hor_blank_start) + crt_reg.hor_blank_start;
- crt_reg.hor_sync_end = panel_crt_reg.hor_sync_end;
-
- crt_reg.ver_total = panel_crt_reg.ver_total;
- crt_reg.ver_addr = mode_crt_reg.ver_addr;
- crt_reg.ver_blank_start - (panel_crt_reg.ver_addr - mode_crt_reg.ver_addr) / 2 +
- crt_reg.ver_addr;
- crt_reg.ver_blank_end = panel_crt_reg.ver_blank_end;
- crt_reg.ver_sync_start - (panel_crt_reg.ver_sync_start -
- panel_crt_reg.ver_blank_start) + crt_reg.ver_blank_start;
- crt_reg.ver_sync_end = panel_crt_reg.ver_sync_end;
-
- return crt_reg;
-}
-
bool viafb_lcd_get_mobile_state(bool *mobile)
{
unsigned char __iomem *romptr, *tableptr, *biosptr;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index c01c1c1..3158dfc 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -283,337 +283,6 @@
#define HW_LAYOUT_LCD1_LCD2 0x04
#define HW_LAYOUT_LCD_EXTERNAL_LCD2 0x10
-/* Definition Refresh Rate */
-#define REFRESH_49 49
-#define REFRESH_50 50
-#define REFRESH_60 60
-#define REFRESH_75 75
-#define REFRESH_85 85
-#define REFRESH_100 100
-#define REFRESH_120 120
-
-/* Definition Sync Polarity*/
-#define NEGATIVE 1
-#define POSITIVE 0
-
-/*480x640@60 Sync Polarity (GTF)
-*/
-#define M480X640_R60_HSP NEGATIVE
-#define M480X640_R60_VSP POSITIVE
-
-/*640x480@60 Sync Polarity (VESA Mode)
-*/
-#define M640X480_R60_HSP NEGATIVE
-#define M640X480_R60_VSP NEGATIVE
-
-/*640x480@75 Sync Polarity (VESA Mode)
-*/
-#define M640X480_R75_HSP NEGATIVE
-#define M640X480_R75_VSP NEGATIVE
-
-/*640x480@85 Sync Polarity (VESA Mode)
-*/
-#define M640X480_R85_HSP NEGATIVE
-#define M640X480_R85_VSP NEGATIVE
-
-/*640x480@100 Sync Polarity (GTF Mode)
-*/
-#define M640X480_R100_HSP NEGATIVE
-#define M640X480_R100_VSP POSITIVE
-
-/*640x480@120 Sync Polarity (GTF Mode)
-*/
-#define M640X480_R120_HSP NEGATIVE
-#define M640X480_R120_VSP POSITIVE
-
-/*720x480@60 Sync Polarity (GTF Mode)
-*/
-#define M720X480_R60_HSP NEGATIVE
-#define M720X480_R60_VSP POSITIVE
-
-/*720x576@60 Sync Polarity (GTF Mode)
-*/
-#define M720X576_R60_HSP NEGATIVE
-#define M720X576_R60_VSP POSITIVE
-
-/*800x600@60 Sync Polarity (VESA Mode)
-*/
-#define M800X600_R60_HSP POSITIVE
-#define M800X600_R60_VSP POSITIVE
-
-/*800x600@75 Sync Polarity (VESA Mode)
-*/
-#define M800X600_R75_HSP POSITIVE
-#define M800X600_R75_VSP POSITIVE
-
-/*800x600@85 Sync Polarity (VESA Mode)
-*/
-#define M800X600_R85_HSP POSITIVE
-#define M800X600_R85_VSP POSITIVE
-
-/*800x600@100 Sync Polarity (GTF Mode)
-*/
-#define M800X600_R100_HSP NEGATIVE
-#define M800X600_R100_VSP POSITIVE
-
-/*800x600@120 Sync Polarity (GTF Mode)
-*/
-#define M800X600_R120_HSP NEGATIVE
-#define M800X600_R120_VSP POSITIVE
-
-/*800x480@60 Sync Polarity (CVT Mode)
-*/
-#define M800X480_R60_HSP NEGATIVE
-#define M800X480_R60_VSP POSITIVE
-
-/*848x480@60 Sync Polarity (CVT Mode)
-*/
-#define M848X480_R60_HSP NEGATIVE
-#define M848X480_R60_VSP POSITIVE
-
-/*852x480@60 Sync Polarity (GTF Mode)
-*/
-#define M852X480_R60_HSP NEGATIVE
-#define M852X480_R60_VSP POSITIVE
-
-/*1024x512@60 Sync Polarity (GTF Mode)
-*/
-#define M1024X512_R60_HSP NEGATIVE
-#define M1024X512_R60_VSP POSITIVE
-
-/*1024x600@60 Sync Polarity (GTF Mode)
-*/
-#define M1024X600_R60_HSP NEGATIVE
-#define M1024X600_R60_VSP POSITIVE
-
-/*1024x768@60 Sync Polarity (VESA Mode)
-*/
-#define M1024X768_R60_HSP NEGATIVE
-#define M1024X768_R60_VSP NEGATIVE
-
-/*1024x768@75 Sync Polarity (VESA Mode)
-*/
-#define M1024X768_R75_HSP POSITIVE
-#define M1024X768_R75_VSP POSITIVE
-
-/*1024x768@85 Sync Polarity (VESA Mode)
-*/
-#define M1024X768_R85_HSP POSITIVE
-#define M1024X768_R85_VSP POSITIVE
-
-/*1024x768@100 Sync Polarity (GTF Mode)
-*/
-#define M1024X768_R100_HSP NEGATIVE
-#define M1024X768_R100_VSP POSITIVE
-
-/*1152x864@75 Sync Polarity (VESA Mode)
-*/
-#define M1152X864_R75_HSP POSITIVE
-#define M1152X864_R75_VSP POSITIVE
-
-/*1280x720@60 Sync Polarity (GTF Mode)
-*/
-#define M1280X720_R60_HSP NEGATIVE
-#define M1280X720_R60_VSP POSITIVE
-
-/* 1280x768@50 Sync Polarity (GTF Mode) */
-#define M1280X768_R50_HSP NEGATIVE
-#define M1280X768_R50_VSP POSITIVE
-
-/*1280x768@60 Sync Polarity (GTF Mode)
-*/
-#define M1280X768_R60_HSP NEGATIVE
-#define M1280X768_R60_VSP POSITIVE
-
-/*1280x800@60 Sync Polarity (CVT Mode)
-*/
-#define M1280X800_R60_HSP NEGATIVE
-#define M1280X800_R60_VSP POSITIVE
-
-/*1280x960@60 Sync Polarity (VESA Mode)
-*/
-#define M1280X960_R60_HSP POSITIVE
-#define M1280X960_R60_VSP POSITIVE
-
-/*1280x1024@60 Sync Polarity (VESA Mode)
-*/
-#define M1280X1024_R60_HSP POSITIVE
-#define M1280X1024_R60_VSP POSITIVE
-
-/* 1360x768@60 Sync Polarity (CVT Mode) */
-#define M1360X768_R60_HSP POSITIVE
-#define M1360X768_R60_VSP POSITIVE
-
-/* 1360x768@60 Sync Polarity (CVT Reduce Blanking Mode) */
-#define M1360X768_RB_R60_HSP POSITIVE
-#define M1360X768_RB_R60_VSP NEGATIVE
-
-/* 1368x768@50 Sync Polarity (GTF Mode) */
-#define M1368X768_R50_HSP NEGATIVE
-#define M1368X768_R50_VSP POSITIVE
-
-/* 1368x768@60 Sync Polarity (VESA Mode) */
-#define M1368X768_R60_HSP NEGATIVE
-#define M1368X768_R60_VSP POSITIVE
-
-/*1280x1024@75 Sync Polarity (VESA Mode)
-*/
-#define M1280X1024_R75_HSP POSITIVE
-#define M1280X1024_R75_VSP POSITIVE
-
-/*1280x1024@85 Sync Polarity (VESA Mode)
-*/
-#define M1280X1024_R85_HSP POSITIVE
-#define M1280X1024_R85_VSP POSITIVE
-
-/*1440x1050@60 Sync Polarity (GTF Mode)
-*/
-#define M1440X1050_R60_HSP NEGATIVE
-#define M1440X1050_R60_VSP POSITIVE
-
-/*1600x1200@60 Sync Polarity (VESA Mode)
-*/
-#define M1600X1200_R60_HSP POSITIVE
-#define M1600X1200_R60_VSP POSITIVE
-
-/*1600x1200@75 Sync Polarity (VESA Mode)
-*/
-#define M1600X1200_R75_HSP POSITIVE
-#define M1600X1200_R75_VSP POSITIVE
-
-/* 1680x1050@60 Sync Polarity (CVT Mode) */
-#define M1680x1050_R60_HSP NEGATIVE
-#define M1680x1050_R60_VSP NEGATIVE
-
-/* 1680x1050@60 Sync Polarity (CVT Reduce Blanking Mode) */
-#define M1680x1050_RB_R60_HSP POSITIVE
-#define M1680x1050_RB_R60_VSP NEGATIVE
-
-/* 1680x1050@75 Sync Polarity (CVT Mode) */
-#define M1680x1050_R75_HSP NEGATIVE
-#define M1680x1050_R75_VSP POSITIVE
-
-/*1920x1080@60 Sync Polarity (CVT Mode)
-*/
-#define M1920X1080_R60_HSP NEGATIVE
-#define M1920X1080_R60_VSP POSITIVE
-
-/* 1920x1080@60 Sync Polarity (CVT Reduce Blanking Mode) */
-#define M1920X1080_RB_R60_HSP POSITIVE
-#define M1920X1080_RB_R60_VSP NEGATIVE
-
-/*1920x1440@60 Sync Polarity (VESA Mode)
-*/
-#define M1920X1440_R60_HSP NEGATIVE
-#define M1920X1440_R60_VSP POSITIVE
-
-/*1920x1440@75 Sync Polarity (VESA Mode)
-*/
-#define M1920X1440_R75_HSP NEGATIVE
-#define M1920X1440_R75_VSP POSITIVE
-
-#if 0
-/* 1400x1050@60 Sync Polarity (VESA Mode) */
-#define M1400X1050_R60_HSP NEGATIVE
-#define M1400X1050_R60_VSP NEGATIVE
-#endif
-
-/* 1400x1050@60 Sync Polarity (CVT Mode) */
-#define M1400X1050_R60_HSP NEGATIVE
-#define M1400X1050_R60_VSP POSITIVE
-
-/* 1400x1050@60 Sync Polarity (CVT Reduce Blanking Mode) */
-#define M1400X1050_RB_R60_HSP POSITIVE
-#define M1400X1050_RB_R60_VSP NEGATIVE
-
-/* 1400x1050@75 Sync Polarity (CVT Mode) */
-#define M1400X1050_R75_HSP NEGATIVE
-#define M1400X1050_R75_VSP POSITIVE
-
-/* 960x600@60 Sync Polarity (CVT Mode) */
-#define M960X600_R60_HSP NEGATIVE
-#define M960X600_R60_VSP POSITIVE
-
-/* 1000x600@60 Sync Polarity (GTF Mode) */
-#define M1000X600_R60_HSP NEGATIVE
-#define M1000X600_R60_VSP POSITIVE
-
-/* 1024x576@60 Sync Polarity (GTF Mode) */
-#define M1024X576_R60_HSP NEGATIVE
-#define M1024X576_R60_VSP POSITIVE
-
-/*1024x600@60 Sync Polarity (GTF Mode)*/
-#define M1024X600_R60_HSP NEGATIVE
-#define M1024X600_R60_VSP POSITIVE
-
-/* 1088x612@60 Sync Polarity (CVT Mode) */
-#define M1088X612_R60_HSP NEGATIVE
-#define M1088X612_R60_VSP POSITIVE
-
-/* 1152x720@60 Sync Polarity (CVT Mode) */
-#define M1152X720_R60_HSP NEGATIVE
-#define M1152X720_R60_VSP POSITIVE
-
-/* 1200x720@60 Sync Polarity (GTF Mode) */
-#define M1200X720_R60_HSP NEGATIVE
-#define M1200X720_R60_VSP POSITIVE
-
-/* 1200x900@60 Sync Polarity (DCON) */
-#define M1200X900_R60_HSP POSITIVE
-#define M1200X900_R60_VSP POSITIVE
-
-/* 1280x600@60 Sync Polarity (GTF Mode) */
-#define M1280x600_R60_HSP NEGATIVE
-#define M1280x600_R60_VSP POSITIVE
-
-/* 1280x720@50 Sync Polarity (GTF Mode) */
-#define M1280X720_R50_HSP NEGATIVE
-#define M1280X720_R50_VSP POSITIVE
-
-/* 1440x900@60 Sync Polarity (CVT Mode) */
-#define M1440X900_R60_HSP NEGATIVE
-#define M1440X900_R60_VSP POSITIVE
-
-/* 1440x900@75 Sync Polarity (CVT Mode) */
-#define M1440X900_R75_HSP NEGATIVE
-#define M1440X900_R75_VSP POSITIVE
-
-/* 1440x900@60 Sync Polarity (CVT Reduce Blanking Mode) */
-#define M1440X900_RB_R60_HSP POSITIVE
-#define M1440X900_RB_R60_VSP NEGATIVE
-
-/* 1600x900@60 Sync Polarity (CVT Mode) */
-#define M1600X900_R60_HSP NEGATIVE
-#define M1600X900_R60_VSP POSITIVE
-
-/* 1600x900@60 Sync Polarity (CVT Reduce Blanking Mode) */
-#define M1600X900_RB_R60_HSP POSITIVE
-#define M1600X900_RB_R60_VSP NEGATIVE
-
-/* 1600x1024@60 Sync Polarity (GTF Mode) */
-#define M1600X1024_R60_HSP NEGATIVE
-#define M1600X1024_R60_VSP POSITIVE
-
-/* 1792x1344@60 Sync Polarity (DMT Mode) */
-#define M1792x1344_R60_HSP NEGATIVE
-#define M1792x1344_R60_VSP POSITIVE
-
-/* 1856x1392@60 Sync Polarity (DMT Mode) */
-#define M1856x1392_R60_HSP NEGATIVE
-#define M1856x1392_R60_VSP POSITIVE
-
-/* 1920x1200@60 Sync Polarity (CVT Mode) */
-#define M1920X1200_R60_HSP NEGATIVE
-#define M1920X1200_R60_VSP POSITIVE
-
-/* 1920x1200@60 Sync Polarity (CVT Reduce Blanking Mode) */
-#define M1920X1200_RB_R60_HSP POSITIVE
-#define M1920X1200_RB_R60_VSP NEGATIVE
-
-/* 2048x1536@60 Sync Polarity (CVT Mode) */
-#define M2048x1536_R60_HSP NEGATIVE
-#define M2048x1536_R60_VSP POSITIVE
-
/* Definition CRTC Timing Index */
#define H_TOTAL_INDEX 0
#define H_ADDR_INDEX 1
diff --git a/drivers/video/via/viamode.c b/drivers/video/via/viamode.c
index 0911cac..0666ab0 100644
--- a/drivers/video/via/viamode.c
+++ b/drivers/video/via/viamode.c
@@ -268,591 +268,78 @@ struct VPITTable VPIT = {
/* Mode Table */
/********************/
-/* 480x640 */
-static struct crt_mode_table CRTM480x640[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M480X640_R60_HSP, M480X640_R60_VSP,
- {624, 480, 480, 144, 504, 48, 663, 640, 640, 23, 641, 3} } /* GTF*/
-};
-
-/* 640x480*/
-static struct crt_mode_table CRTM640x480[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M640X480_R60_HSP, M640X480_R60_VSP,
- {800, 640, 640, 160, 656, 96, 525, 480, 480, 45, 490, 2} },
- {REFRESH_75, M640X480_R75_HSP, M640X480_R75_VSP,
- {840, 640, 640, 200, 656, 64, 500, 480, 480, 20, 481, 3} },
- {REFRESH_85, M640X480_R85_HSP, M640X480_R85_VSP,
- {832, 640, 640, 192, 696, 56, 509, 480, 480, 29, 481, 3} },
- {REFRESH_100, M640X480_R100_HSP, M640X480_R100_VSP,
- {848, 640, 640, 208, 680, 64, 509, 480, 480, 29, 481, 3} }, /*GTF*/
- {REFRESH_120, M640X480_R120_HSP, M640X480_R120_VSP,
- {848, 640, 640, 208, 680, 64, 515, 480, 480, 35, 481, 3} } /*GTF*/
-};
-
-/*720x480 (GTF)*/
-static struct crt_mode_table CRTM720x480[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M720X480_R60_HSP, M720X480_R60_VSP,
- {896, 720, 720, 176, 736, 72, 497, 480, 480, 17, 481, 3} }
-
-};
-
-/*720x576 (GTF)*/
-static struct crt_mode_table CRTM720x576[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M720X576_R60_HSP, M720X576_R60_VSP,
- {912, 720, 720, 192, 744, 72, 597, 576, 576, 21, 577, 3} }
-};
-
-/* 800x480 (CVT) */
-static struct crt_mode_table CRTM800x480[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M800X480_R60_HSP, M800X480_R60_VSP,
- {992, 800, 800, 192, 824, 72, 500, 480, 480, 20, 483, 7} }
-};
-
-/* 800x600*/
-static struct crt_mode_table CRTM800x600[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M800X600_R60_HSP, M800X600_R60_VSP,
- {1056, 800, 800, 256, 840, 128, 628, 600, 600, 28, 601, 4} },
- {REFRESH_75, M800X600_R75_HSP, M800X600_R75_VSP,
- {1056, 800, 800, 256, 816, 80, 625, 600, 600, 25, 601, 3} },
- {REFRESH_85, M800X600_R85_HSP, M800X600_R85_VSP,
- {1048, 800, 800, 248, 832, 64, 631, 600, 600, 31, 601, 3} },
- {REFRESH_100, M800X600_R100_HSP, M800X600_R100_VSP,
- {1072, 800, 800, 272, 848, 88, 636, 600, 600, 36, 601, 3} },
- {REFRESH_120, M800X600_R120_HSP, M800X600_R120_VSP,
- {1088, 800, 800, 288, 856, 88, 643, 600, 600, 43, 601, 3} }
-};
-
-/* 848x480 (CVT) */
-static struct crt_mode_table CRTM848x480[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M848X480_R60_HSP, M848X480_R60_VSP,
- {1056, 848, 848, 208, 872, 80, 500, 480, 480, 20, 483, 5} }
-};
-
-/*856x480 (GTF) convert to 852x480*/
-static struct crt_mode_table CRTM852x480[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M852X480_R60_HSP, M852X480_R60_VSP,
- {1064, 856, 856, 208, 872, 88, 497, 480, 480, 17, 481, 3} }
-};
-
-/*1024x512 (GTF)*/
-static struct crt_mode_table CRTM1024x512[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1024X512_R60_HSP, M1024X512_R60_VSP,
- {1296, 1024, 1024, 272, 1056, 104, 531, 512, 512, 19, 513, 3} }
-
-};
-
-/* 1024x600*/
-static struct crt_mode_table CRTM1024x600[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1024X600_R60_HSP, M1024X600_R60_VSP,
- {1312, 1024, 1024, 288, 1064, 104, 622, 600, 600, 22, 601, 3} },
-};
-
-/* 1024x768*/
-static struct crt_mode_table CRTM1024x768[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1024X768_R60_HSP, M1024X768_R60_VSP,
- {1344, 1024, 1024, 320, 1048, 136, 806, 768, 768, 38, 771, 6} },
- {REFRESH_75, M1024X768_R75_HSP, M1024X768_R75_VSP,
- {1312, 1024, 1024, 288, 1040, 96, 800, 768, 768, 32, 769, 3} },
- {REFRESH_85, M1024X768_R85_HSP, M1024X768_R85_VSP,
- {1376, 1024, 1024, 352, 1072, 96, 808, 768, 768, 40, 769, 3} },
- {REFRESH_100, M1024X768_R100_HSP, M1024X768_R100_VSP,
- {1392, 1024, 1024, 368, 1096, 112, 814, 768, 768, 46, 769, 3} }
-};
-
-/* 1152x864*/
-static struct crt_mode_table CRTM1152x864[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_75, M1152X864_R75_HSP, M1152X864_R75_VSP,
- {1600, 1152, 1152, 448, 1216, 128, 900, 864, 864, 36, 865, 3} }
-
-};
-
-/* 1280x720 (HDMI 720P)*/
-static struct crt_mode_table CRTM1280x720[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1280X720_R60_HSP, M1280X720_R60_VSP,
- {1648, 1280, 1280, 368, 1392, 40, 750, 720, 720, 30, 725, 5} },
- {REFRESH_50, M1280X720_R50_HSP, M1280X720_R50_VSP,
- {1632, 1280, 1280, 352, 1328, 128, 741, 720, 720, 21, 721, 3} }
-};
-
-/*1280x768 (GTF)*/
-static struct crt_mode_table CRTM1280x768[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1280X768_R60_HSP, M1280X768_R60_VSP,
- {1680, 1280, 1280, 400, 1344, 136, 795, 768, 768, 27, 769, 3} },
- {REFRESH_50, M1280X768_R50_HSP, M1280X768_R50_VSP,
- {1648, 1280, 1280, 368, 1336, 128, 791, 768, 768, 23, 769, 3} }
-};
-
-/* 1280x800 (CVT) */
-static struct crt_mode_table CRTM1280x800[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1280X800_R60_HSP, M1280X800_R60_VSP,
- {1680, 1280, 1280, 400, 1352, 128, 831, 800, 800, 31, 803, 6} }
-};
-
-/*1280x960*/
-static struct crt_mode_table CRTM1280x960[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1280X960_R60_HSP, M1280X960_R60_VSP,
- {1800, 1280, 1280, 520, 1376, 112, 1000, 960, 960, 40, 961, 3} }
-};
-
-/* 1280x1024*/
-static struct crt_mode_table CRTM1280x1024[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1280X1024_R60_HSP, M1280X1024_R60_VSP,
- {1688, 1280, 1280, 408, 1328, 112, 1066, 1024, 1024, 42, 1025,
- 3} },
- {REFRESH_75, M1280X1024_R75_HSP, M1280X1024_R75_VSP,
- {1688, 1280, 1280, 408, 1296, 144, 1066, 1024, 1024, 42, 1025,
- 3} },
- {REFRESH_85, M1280X1024_R85_HSP, M1280X1024_R85_VSP,
- {1728, 1280, 1280, 448, 1344, 160, 1072, 1024, 1024, 48, 1025, 3} }
-};
-
-/* 1368x768 (GTF) */
-static struct crt_mode_table CRTM1368x768[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1368X768_R60_HSP, M1368X768_R60_VSP,
- {1800, 1368, 1368, 432, 1440, 144, 795, 768, 768, 27, 769, 3} }
-};
-
-/*1440x1050 (GTF)*/
-static struct crt_mode_table CRTM1440x1050[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1440X1050_R60_HSP, M1440X1050_R60_VSP,
- {1936, 1440, 1440, 496, 1536, 152, 1077, 1040, 1040, 37, 1041, 3} }
-};
-
-/* 1600x1200*/
-static struct crt_mode_table CRTM1600x1200[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1600X1200_R60_HSP, M1600X1200_R60_VSP,
- {2160, 1600, 1600, 560, 1664, 192, 1250, 1200, 1200, 50, 1201,
- 3} },
- {REFRESH_75, M1600X1200_R75_HSP, M1600X1200_R75_VSP,
- {2160, 1600, 1600, 560, 1664, 192, 1250, 1200, 1200, 50, 1201, 3} }
-
-};
-
-/* 1680x1050 (CVT) */
-static struct crt_mode_table CRTM1680x1050[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1680x1050_R60_HSP, M1680x1050_R60_VSP,
- {2240, 1680, 1680, 560, 1784, 176, 1089, 1050, 1050, 39, 1053,
- 6} },
- {REFRESH_75, M1680x1050_R75_HSP, M1680x1050_R75_VSP,
- {2272, 1680, 1680, 592, 1800, 176, 1099, 1050, 1050, 49, 1053, 6} }
-};
-
-/* 1680x1050 (CVT Reduce Blanking) */
-static struct crt_mode_table CRTM1680x1050_RB[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1680x1050_RB_R60_HSP, M1680x1050_RB_R60_VSP,
- {1840, 1680, 1680, 160, 1728, 32, 1080, 1050, 1050, 30, 1053, 6} }
-};
-
-/* 1920x1080 (CVT)*/
-static struct crt_mode_table CRTM1920x1080[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1920X1080_R60_HSP, M1920X1080_R60_VSP,
- {2576, 1920, 1920, 656, 2048, 200, 1120, 1080, 1080, 40, 1083, 5} }
-};
-
-/* 1920x1080 (CVT with Reduce Blanking) */
-static struct crt_mode_table CRTM1920x1080_RB[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1920X1080_RB_R60_HSP, M1920X1080_RB_R60_VSP,
- {2080, 1920, 1920, 160, 1968, 32, 1111, 1080, 1080, 31, 1083, 5} }
-};
-
-/* 1920x1440*/
-static struct crt_mode_table CRTM1920x1440[] = {
- /*r_rate,hsp,vsp */
- /*HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1920X1440_R60_HSP, M1920X1440_R60_VSP,
- {2600, 1920, 1920, 680, 2048, 208, 1500, 1440, 1440, 60, 1441,
- 3} },
- {REFRESH_75, M1920X1440_R75_HSP, M1920X1440_R75_VSP,
- {2640, 1920, 1920, 720, 2064, 224, 1500, 1440, 1440, 60, 1441, 3} }
-};
-
-/* 1400x1050 (CVT) */
-static struct crt_mode_table CRTM1400x1050[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1400X1050_R60_HSP, M1400X1050_R60_VSP,
- {1864, 1400, 1400, 464, 1488, 144, 1089, 1050, 1050, 39, 1053,
- 4} },
- {REFRESH_75, M1400X1050_R75_HSP, M1400X1050_R75_VSP,
- {1896, 1400, 1400, 496, 1504, 144, 1099, 1050, 1050, 49, 1053, 4} }
-};
-
-/* 1400x1050 (CVT Reduce Blanking) */
-static struct crt_mode_table CRTM1400x1050_RB[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1400X1050_RB_R60_HSP, M1400X1050_RB_R60_VSP,
- {1560, 1400, 1400, 160, 1448, 32, 1080, 1050, 1050, 30, 1053, 4} }
-};
-
-/* 960x600 (CVT) */
-static struct crt_mode_table CRTM960x600[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M960X600_R60_HSP, M960X600_R60_VSP,
- {1216, 960, 960, 256, 992, 96, 624, 600, 600, 24, 603, 6} }
-};
-
-/* 1000x600 (GTF) */
-static struct crt_mode_table CRTM1000x600[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1000X600_R60_HSP, M1000X600_R60_VSP,
- {1288, 1000, 1000, 288, 1040, 104, 622, 600, 600, 22, 601, 3} }
-};
-
-/* 1024x576 (GTF) */
-static struct crt_mode_table CRTM1024x576[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1024X576_R60_HSP, M1024X576_R60_VSP,
- {1312, 1024, 1024, 288, 1064, 104, 597, 576, 576, 21, 577, 3} }
-};
-
-/* 1088x612 (CVT) */
-static struct crt_mode_table CRTM1088x612[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1088X612_R60_HSP, M1088X612_R60_VSP,
- {1392, 1088, 1088, 304, 1136, 104, 636, 612, 612, 24, 615, 5} }
-};
-
-/* 1152x720 (CVT) */
-static struct crt_mode_table CRTM1152x720[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1152X720_R60_HSP, M1152X720_R60_VSP,
- {1488, 1152, 1152, 336, 1208, 112, 748, 720, 720, 28, 723, 6} }
-};
-
-/* 1200x720 (GTF) */
-static struct crt_mode_table CRTM1200x720[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1200X720_R60_HSP, M1200X720_R60_VSP,
- {1568, 1200, 1200, 368, 1256, 128, 746, 720, 720, 26, 721, 3} }
-};
-
-/* 1200x900 (DCON) */
-static struct crt_mode_table DCON1200x900[] = {
- /* r_rate, hsp, vsp */
- {REFRESH_49, M1200X900_R60_HSP, M1200X900_R60_VSP,
- /* The correct htotal is 1240, but this doesn't raster on VX855. */
- /* Via suggested changing to a multiple of 16, hence 1264. */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {1264, 1200, 1200, 64, 1211, 32, 912, 900, 900, 12, 901, 10} }
-};
-
-/* 1280x600 (GTF) */
-static struct crt_mode_table CRTM1280x600[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1280x600_R60_HSP, M1280x600_R60_VSP,
- {1648, 1280, 1280, 368, 1336, 128, 622, 600, 600, 22, 601, 3} }
-};
-
-/* 1360x768 (CVT) */
-static struct crt_mode_table CRTM1360x768[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1360X768_R60_HSP, M1360X768_R60_VSP,
- {1776, 1360, 1360, 416, 1432, 136, 798, 768, 768, 30, 771, 5} }
-};
-
-/* 1360x768 (CVT Reduce Blanking) */
-static struct crt_mode_table CRTM1360x768_RB[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1360X768_RB_R60_HSP, M1360X768_RB_R60_VSP,
- {1520, 1360, 1360, 160, 1408, 32, 790, 768, 768, 22, 771, 5} }
-};
-
-/* 1366x768 (GTF) */
-static struct crt_mode_table CRTM1366x768[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1368X768_R60_HSP, M1368X768_R60_VSP,
- {1800, 1368, 1368, 432, 1440, 144, 795, 768, 768, 27, 769, 3} },
- {REFRESH_50, M1368X768_R50_HSP, M1368X768_R50_VSP,
- {1768, 1368, 1368, 400, 1424, 144, 791, 768, 768, 23, 769, 3} }
-};
-
-/* 1440x900 (CVT) */
-static struct crt_mode_table CRTM1440x900[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1440X900_R60_HSP, M1440X900_R60_VSP,
- {1904, 1440, 1440, 464, 1520, 152, 934, 900, 900, 34, 903, 6} },
- {REFRESH_75, M1440X900_R75_HSP, M1440X900_R75_VSP,
- {1936, 1440, 1440, 496, 1536, 152, 942, 900, 900, 42, 903, 6} }
-};
-
-/* 1440x900 (CVT Reduce Blanking) */
-static struct crt_mode_table CRTM1440x900_RB[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1440X900_RB_R60_HSP, M1440X900_RB_R60_VSP,
- {1600, 1440, 1440, 160, 1488, 32, 926, 900, 900, 26, 903, 6} }
-};
-
-/* 1600x900 (CVT) */
-static struct crt_mode_table CRTM1600x900[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1600X900_R60_HSP, M1600X900_R60_VSP,
- {2112, 1600, 1600, 512, 1688, 168, 934, 900, 900, 34, 903, 5} }
-};
-
-/* 1600x900 (CVT Reduce Blanking) */
-static struct crt_mode_table CRTM1600x900_RB[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1600X900_RB_R60_HSP, M1600X900_RB_R60_VSP,
- {1760, 1600, 1600, 160, 1648, 32, 926, 900, 900, 26, 903, 5} }
-};
-
-/* 1600x1024 (GTF) */
-static struct crt_mode_table CRTM1600x1024[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1600X1024_R60_HSP, M1600X1024_R60_VSP,
- {2144, 1600, 1600, 544, 1704, 168, 1060, 1024, 1024, 36, 1025, 3} }
-};
-
-/* 1792x1344 (DMT) */
-static struct crt_mode_table CRTM1792x1344[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1792x1344_R60_HSP, M1792x1344_R60_VSP,
- {2448, 1792, 1792, 656, 1920, 200, 1394, 1344, 1344, 50, 1345, 3} }
-};
-
-/* 1856x1392 (DMT) */
-static struct crt_mode_table CRTM1856x1392[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1856x1392_R60_HSP, M1856x1392_R60_VSP,
- {2528, 1856, 1856, 672, 1952, 224, 1439, 1392, 1392, 47, 1393, 3} }
-};
-
-/* 1920x1200 (CVT) */
-static struct crt_mode_table CRTM1920x1200[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1920X1200_R60_HSP, M1920X1200_R60_VSP,
- {2592, 1920, 1920, 672, 2056, 200, 1245, 1200, 1200, 45, 1203, 6} }
-};
-
-/* 1920x1200 (CVT with Reduce Blanking) */
-static struct crt_mode_table CRTM1920x1200_RB[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M1920X1200_RB_R60_HSP, M1920X1200_RB_R60_VSP,
- {2080, 1920, 1920, 160, 1968, 32, 1235, 1200, 1200, 35, 1203, 6} }
-};
-
-/* 2048x1536 (CVT) */
-static struct crt_mode_table CRTM2048x1536[] = {
- /* r_rate, hsp, vsp */
- /* HT, HA, HBS, HBE, HSS, HSE, VT, VA, VBS, VBE, VSS, VSE */
- {REFRESH_60, M2048x1536_R60_HSP, M2048x1536_R60_VSP,
- {2800, 2048, 2048, 752, 2200, 224, 1592, 1536, 1536, 56, 1539, 4} }
-};
-
-static struct VideoModeTable viafb_modes[] = {
- /* Display : 480x640 (GTF) */
- {CRTM480x640, ARRAY_SIZE(CRTM480x640)},
-
- /* Display : 640x480 */
- {CRTM640x480, ARRAY_SIZE(CRTM640x480)},
-
- /* Display : 720x480 (GTF) */
- {CRTM720x480, ARRAY_SIZE(CRTM720x480)},
-
- /* Display : 720x576 (GTF) */
- {CRTM720x576, ARRAY_SIZE(CRTM720x576)},
-
- /* Display : 800x600 */
- {CRTM800x600, ARRAY_SIZE(CRTM800x600)},
-
- /* Display : 800x480 (CVT) */
- {CRTM800x480, ARRAY_SIZE(CRTM800x480)},
-
- /* Display : 848x480 (CVT) */
- {CRTM848x480, ARRAY_SIZE(CRTM848x480)},
-
- /* Display : 852x480 (GTF) */
- {CRTM852x480, ARRAY_SIZE(CRTM852x480)},
-
- /* Display : 1024x512 (GTF) */
- {CRTM1024x512, ARRAY_SIZE(CRTM1024x512)},
-
- /* Display : 1024x600 */
- {CRTM1024x600, ARRAY_SIZE(CRTM1024x600)},
-
- /* Display : 1024x768 */
- {CRTM1024x768, ARRAY_SIZE(CRTM1024x768)},
-
- /* Display : 1152x864 */
- {CRTM1152x864, ARRAY_SIZE(CRTM1152x864)},
-
- /* Display : 1280x768 (GTF) */
- {CRTM1280x768, ARRAY_SIZE(CRTM1280x768)},
-
- /* Display : 960x600 (CVT) */
- {CRTM960x600, ARRAY_SIZE(CRTM960x600)},
-
- /* Display : 1000x600 (GTF) */
- {CRTM1000x600, ARRAY_SIZE(CRTM1000x600)},
-
- /* Display : 1024x576 (GTF) */
- {CRTM1024x576, ARRAY_SIZE(CRTM1024x576)},
-
- /* Display : 1088x612 (GTF) */
- {CRTM1088x612, ARRAY_SIZE(CRTM1088x612)},
-
- /* Display : 1152x720 (CVT) */
- {CRTM1152x720, ARRAY_SIZE(CRTM1152x720)},
-
- /* Display : 1200x720 (GTF) */
- {CRTM1200x720, ARRAY_SIZE(CRTM1200x720)},
-
- /* Display : 1200x900 (DCON) */
- {DCON1200x900, ARRAY_SIZE(DCON1200x900)},
-
- /* Display : 1280x600 (GTF) */
- {CRTM1280x600, ARRAY_SIZE(CRTM1280x600)},
-
- /* Display : 1280x800 (CVT) */
- {CRTM1280x800, ARRAY_SIZE(CRTM1280x800)},
-
- /* Display : 1280x960 */
- {CRTM1280x960, ARRAY_SIZE(CRTM1280x960)},
-
- /* Display : 1280x1024 */
- {CRTM1280x1024, ARRAY_SIZE(CRTM1280x1024)},
-
- /* Display : 1360x768 (CVT) */
- {CRTM1360x768, ARRAY_SIZE(CRTM1360x768)},
-
- /* Display : 1366x768 */
- {CRTM1366x768, ARRAY_SIZE(CRTM1366x768)},
-
- /* Display : 1368x768 (GTF) */
- {CRTM1368x768, ARRAY_SIZE(CRTM1368x768)},
-
- /* Display : 1440x900 (CVT) */
- {CRTM1440x900, ARRAY_SIZE(CRTM1440x900)},
-
- /* Display : 1440x1050 (GTF) */
- {CRTM1440x1050, ARRAY_SIZE(CRTM1440x1050)},
-
- /* Display : 1600x900 (CVT) */
- {CRTM1600x900, ARRAY_SIZE(CRTM1600x900)},
-
- /* Display : 1600x1024 (GTF) */
- {CRTM1600x1024, ARRAY_SIZE(CRTM1600x1024)},
-
- /* Display : 1600x1200 */
- {CRTM1600x1200, ARRAY_SIZE(CRTM1600x1200)},
-
- /* Display : 1680x1050 (CVT) */
- {CRTM1680x1050, ARRAY_SIZE(CRTM1680x1050)},
-
- /* Display : 1792x1344 (DMT) */
- {CRTM1792x1344, ARRAY_SIZE(CRTM1792x1344)},
-
- /* Display : 1856x1392 (DMT) */
- {CRTM1856x1392, ARRAY_SIZE(CRTM1856x1392)},
-
- /* Display : 1920x1440 */
- {CRTM1920x1440, ARRAY_SIZE(CRTM1920x1440)},
-
- /* Display : 2048x1536 */
- {CRTM2048x1536, ARRAY_SIZE(CRTM2048x1536)},
-
- /* Display : 1280x720 */
- {CRTM1280x720, ARRAY_SIZE(CRTM1280x720)},
-
- /* Display : 1920x1080 (CVT) */
- {CRTM1920x1080, ARRAY_SIZE(CRTM1920x1080)},
-
- /* Display : 1920x1200 (CVT) */
- {CRTM1920x1200, ARRAY_SIZE(CRTM1920x1200)},
-
- /* Display : 1400x1050 (CVT) */
- {CRTM1400x1050, ARRAY_SIZE(CRTM1400x1050)}
-};
-
-static struct VideoModeTable viafb_rb_modes[] = {
- /* Display : 1360x768 (CVT Reduce Blanking) */
- {CRTM1360x768_RB, ARRAY_SIZE(CRTM1360x768_RB)},
-
- /* Display : 1440x900 (CVT Reduce Blanking) */
- {CRTM1440x900_RB, ARRAY_SIZE(CRTM1440x900_RB)},
-
- /* Display : 1400x1050 (CVT Reduce Blanking) */
- {CRTM1400x1050_RB, ARRAY_SIZE(CRTM1400x1050_RB)},
-
- /* Display : 1600x900 (CVT Reduce Blanking) */
- {CRTM1600x900_RB, ARRAY_SIZE(CRTM1600x900_RB)},
-
- /* Display : 1680x1050 (CVT Reduce Blanking) */
- {CRTM1680x1050_RB, ARRAY_SIZE(CRTM1680x1050_RB)},
-
- /* Display : 1920x1080 (CVT Reduce Blanking) */
- {CRTM1920x1080_RB, ARRAY_SIZE(CRTM1920x1080_RB)},
-
- /* Display : 1920x1200 (CVT Reduce Blanking) */
- {CRTM1920x1200_RB, ARRAY_SIZE(CRTM1920x1200_RB)}
-};
+static const struct fb_videomode viafb_modes[] = {
+ {NULL, 60, 480, 640, 40285, 72, 24, 19, 1, 48, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 640, 480, 39682, 48, 16, 33, 10, 96, 2, 0, 0, 0},
+ {NULL, 75, 640, 480, 31746, 120, 16, 16, 1, 64, 3, 0, 0, 0},
+ {NULL, 85, 640, 480, 27780, 80, 56, 25, 1, 56, 3, 0, 0, 0},
+ {NULL, 100, 640, 480, 23167, 104, 40, 25, 1, 64, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 120, 640, 480, 19081, 104, 40, 31, 1, 64, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 720, 480, 37426, 88, 16, 13, 1, 72, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 720, 576, 30611, 96, 24, 17, 1, 72, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 800, 600, 25131, 88, 40, 23, 1, 128, 4, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 75, 800, 600, 20202, 160, 16, 21, 1, 80, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 85, 800, 600, 17790, 152, 32, 27, 1, 64, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 100, 800, 600, 14667, 136, 48, 32, 1, 88, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 120, 800, 600, 11911, 144, 56, 39, 1, 88, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 800, 480, 33602, 96, 24, 10, 3, 72, 7, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 848, 480, 31565, 104, 24, 12, 3, 80, 5, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 856, 480, 31517, 104, 16, 13, 1, 88, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1024, 512, 24218, 136, 32, 15, 1, 104, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1024, 600, 20423, 144, 40, 18, 1, 104, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1024, 768, 15385, 160, 24, 29, 3, 136, 6, 0, 0, 0},
+ {NULL, 75, 1024, 768, 12703, 176, 16, 28, 1, 96, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 85, 1024, 768, 10581, 208, 48, 36, 1, 96, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 100, 1024, 768, 8825, 184, 72, 42, 1, 112, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 75, 1152, 864, 9259, 256, 64, 32, 1, 128, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1280, 768, 12478, 200, 64, 23, 1, 136, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 50, 1280, 768, 15342, 184, 56, 19, 1, 128, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 960, 600, 21964, 128, 32, 15, 3, 96, 6, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1000, 600, 20803, 144, 40, 18, 1, 104, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1024, 576, 21278, 144, 40, 17, 1, 104, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1088, 612, 18825, 152, 48, 16, 3, 104, 5, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1152, 720, 14974, 168, 56, 19, 3, 112, 6, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1200, 720, 14248, 184, 56, 22, 1, 128, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 49, 1200, 900, 17703, 21, 11, 1, 1, 32, 10, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1280, 600, 16259, 184, 56, 18, 1, 128, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1280, 800, 11938, 200, 72, 22, 3, 128, 6, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1280, 960, 9259, 312, 96, 36, 1, 112, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1280, 1024, 9262, 248, 48, 38, 1, 112, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 75, 1280, 1024, 7409, 248, 16, 38, 1, 144, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 85, 1280, 1024, 6351, 224, 64, 44, 1, 160, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1360, 768, 11759, 208, 72, 22, 3, 136, 5, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1368, 768, 11646, 216, 72, 23, 1, 144, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 50, 1368, 768, 14301, 200, 56, 19, 1, 144, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1368, 768, 11646, 216, 72, 23, 1, 144, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1440, 900, 9372, 232, 80, 25, 3, 152, 6, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 75, 1440, 900, 7311, 248, 96, 33, 3, 152, 6, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1440, 1040, 7993, 248, 96, 33, 1, 152, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1600, 900, 8449, 256, 88, 26, 3, 168, 5, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1600, 1024, 7333, 272, 104, 32, 1, 168, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1600, 1200, 6172, 304, 64, 46, 1, 192, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 75, 1600, 1200, 4938, 304, 64, 46, 1, 192, 3, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1680, 1050, 6832, 280, 104, 30, 3, 176, 6, 0, 0, 0},
+ {NULL, 75, 1680, 1050, 5339, 296, 120, 40, 3, 176, 6, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1792, 1344, 4883, 328, 128, 46, 1, 200, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1856, 1392, 4581, 352, 96, 43, 1, 224, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1920, 1440, 4273, 344, 128, 56, 1, 208, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 75, 1920, 1440, 3367, 352, 144, 56, 1, 224, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 2048, 1536, 3738, 376, 152, 49, 3, 224, 4, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1280, 720, 13484, 216, 112, 20, 5, 40, 5, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 50, 1280, 720, 16538, 176, 48, 17, 1, 128, 3, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1920, 1080, 5776, 328, 128, 32, 3, 200, 5, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1920, 1200, 5164, 336, 136, 36, 3, 200, 6, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 60, 1400, 1050, 8210, 232, 88, 32, 3, 144, 4, FB_SYNC_VERT_HIGH_ACT, 0, 0},
+ {NULL, 75, 1400, 1050, 6398, 248, 104, 42, 3, 144, 4, FB_SYNC_VERT_HIGH_ACT, 0, 0} };
+
+static const struct fb_videomode viafb_rb_modes[] = {
+ {NULL, 60, 1360, 768, 13879, 80, 48, 14, 3, 32, 5, FB_SYNC_HOR_HIGH_ACT, 0, 0},
+ {NULL, 60, 1440, 900, 11249, 80, 48, 17, 3, 32, 6, FB_SYNC_HOR_HIGH_ACT, 0, 0},
+ {NULL, 60, 1400, 1050, 9892, 80, 48, 23, 3, 32, 4, FB_SYNC_HOR_HIGH_ACT, 0, 0},
+ {NULL, 60, 1600, 900, 10226, 80, 48, 18, 3, 32, 5, FB_SYNC_HOR_HIGH_ACT, 0, 0},
+ {NULL, 60, 1680, 1050, 8387, 80, 48, 21, 3, 32, 6, FB_SYNC_HOR_HIGH_ACT, 0, 0},
+ {NULL, 60, 1920, 1080, 7212, 80, 48, 23, 3, 32, 5, FB_SYNC_HOR_HIGH_ACT, 0, 0},
+ {NULL, 60, 1920, 1200, 6488, 80, 48, 26, 3, 32, 6, FB_SYNC_HOR_HIGH_ACT, 0, 0} };
int NUM_TOTAL_CN400_ModeXregs = ARRAY_SIZE(CN400_ModeXregs);
int NUM_TOTAL_CN700_ModeXregs = ARRAY_SIZE(CN700_ModeXregs);
@@ -863,56 +350,34 @@ int NUM_TOTAL_CLE266_ModeXregs = ARRAY_SIZE(CLE266_ModeXregs);
int NUM_TOTAL_PATCH_MODE = ARRAY_SIZE(res_patch_table);
-static struct VideoModeTable *get_modes(struct VideoModeTable *vmt, int n,
- int hres, int vres)
-{
- int i;
-
- for (i = 0; i < n; i++)
- if (vmt[i].mode_array &&
- vmt[i].crtc[0].crtc.hor_addr = hres &&
- vmt[i].crtc[0].crtc.ver_addr = vres)
- return &viafb_modes[i];
-
- return NULL;
-}
-
-static struct crt_mode_table *get_best_mode(struct VideoModeTable *vmt,
- int refresh)
+static const struct fb_videomode *get_best_mode(
+ const struct fb_videomode *modes, int n,
+ int hres, int vres, int refresh)
{
- struct crt_mode_table *best;
+ const struct fb_videomode *best = NULL;
int i;
- if (!vmt)
- return NULL;
+ for (i = 0; i < n; i++) {
+ if (modes[i].xres != hres || modes[i].yres != vres)
+ continue;
- best = &vmt->crtc[0];
- for (i = 1; i < vmt->mode_array; i++) {
- if (abs(vmt->crtc[i].refresh_rate - refresh)
- < abs(best->refresh_rate - refresh))
- best = &vmt->crtc[i];
+ if (!best || abs(modes[i].refresh - refresh) <
+ abs(best->refresh - refresh))
+ best = &modes[i];
}
return best;
}
-static struct VideoModeTable *viafb_get_mode(int hres, int vres)
-{
- return get_modes(viafb_modes, ARRAY_SIZE(viafb_modes), hres, vres);
-}
-
-struct crt_mode_table *viafb_get_best_mode(int hres, int vres, int refresh)
+const struct fb_videomode *viafb_get_best_mode(int hres, int vres, int refresh)
{
- return get_best_mode(viafb_get_mode(hres, vres), refresh);
+ return get_best_mode(viafb_modes, ARRAY_SIZE(viafb_modes),
+ hres, vres, refresh);
}
-static struct VideoModeTable *viafb_get_rb_mode(int hres, int vres)
-{
- return get_modes(viafb_rb_modes, ARRAY_SIZE(viafb_rb_modes), hres,
- vres);
-}
-
-struct crt_mode_table *viafb_get_best_rb_mode(int hres, int vres, int refresh)
+const struct fb_videomode *viafb_get_best_rb_mode(int hres, int vres,
+ int refresh)
{
- return get_best_mode(viafb_get_rb_mode(hres, vres), refresh);
+ return get_best_mode(viafb_rb_modes, ARRAY_SIZE(viafb_rb_modes),
+ hres, vres, refresh);
}
diff --git a/drivers/video/via/viamode.h b/drivers/video/via/viamode.h
index 5917a2b..dd19106 100644
--- a/drivers/video/via/viamode.h
+++ b/drivers/video/via/viamode.h
@@ -31,11 +31,6 @@ struct VPITTable {
unsigned char AR[StdAR];
};
-struct VideoModeTable {
- struct crt_mode_table *crtc;
- int mode_array;
-};
-
struct patch_table {
int table_length;
struct io_reg *io_reg_table;
@@ -60,7 +55,9 @@ extern struct io_reg PM1024x768[];
extern struct patch_table res_patch_table[];
extern struct VPITTable VPIT;
-struct crt_mode_table *viafb_get_best_mode(int hres, int vres, int refresh);
-struct crt_mode_table *viafb_get_best_rb_mode(int hres, int vres, int refresh);
+const struct fb_videomode *viafb_get_best_mode(int hres, int vres,
+ int refresh);
+const struct fb_videomode *viafb_get_best_rb_mode(int hres, int vres,
+ int refresh);
#endif /* __VIAMODE_H__ */
--
1.7.9
^ permalink raw reply related
* [PATCH 0/2] viafb modetable conversion
From: Florian Tobias Schandinat @ 2012-03-08 17:55 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
Hi all,
finally the modetable conversion is here. The first patch does the
conversion to get rid of some strange things and lot of defines.
The conversion was done by a program and causes a lot of warnings by
generating lines longer than 80 characters which I do not consider
worth fixing. A side effect of this conversion seems to be that CRTs
are happier with the resulting modes/clocks as the conversion program
used floating point and therefore the resulting pixclocks are closer to
what they should be.
The second patch is just sort of performance optimization by avoiding
two unnecessary modetable walks.
Best regards,
Florian Tobias Schandinat
Florian Tobias Schandinat (2):
viafb: modetable conversion
viafb: avoid refresh and mode lookup in set_par
drivers/video/via/dvi.c | 2 +-
drivers/video/via/hw.c | 41 +--
drivers/video/via/hw.h | 4 +-
drivers/video/via/lcd.c | 53 +---
drivers/video/via/share.h | 331 --------------------
drivers/video/via/viafbdev.c | 32 +-
drivers/video/via/viamode.c | 713 ++++++------------------------------------
drivers/video/via/viamode.h | 11 +-
8 files changed, 134 insertions(+), 1053 deletions(-)
--
1.7.9
^ permalink raw reply
* Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
From: James Simmons @ 2012-03-08 16:57 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev, Seung-Woo Kim, dri-devel, Inki Dae, Kyungmin Park
In-Reply-To: <1331206495-3853-1-git-send-email-laurent.pinchart@ideasonboard.com>
> The fb_videomode structure stores the front porch and back porch in the
> right_margin and left_margin fields respectively. right_margin should
> thus be computed with hsync_start - hdisplay, and left_margin with
> htotal - hsync_end. The same holds for the vertical direction.
>
> Active Front Sync Back
> Region Porch Porch
> <-------------------><----------------><-------------><---------------->
>
> //////////////////|
> ////////////////// |
> ////////////////// |.................. ..................
> _______________
>
> <------ xres -------><- right_margin -><- hsync_len -><- left_margin -->
>
> <---- hdisplay ----->
> <------------ hsync_start ------------>
> <--------------------- hsync_end -------------------->
> <--------------------------------- htotal ----------------------------->
>
> Fix the fb_videomode <-> drm_mode_modeinfo conversion functions
> accordingly.
>
Wow I see this has remegered. Some time last year I posted a patch that
had these routines in a generic format for people to use. I can repost
them again if people are interested.
^ permalink raw reply
* Re: [RFC] FB_MODE_IS_* usage
From: James Simmons @ 2012-03-08 16:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <2317885.WEEKmd8lWO@avalon>
> Hi everybody,
>
> While going through users of the fb_videomode structure, I realized that some
> of the FB_MODE_IS_* flags didn't seem to be used for any practical purpose.
>
> The flags are defined as
>
> #define FB_MODE_IS_UNKNOWN 0
> #define FB_MODE_IS_DETAILED 1
> #define FB_MODE_IS_STANDARD 2
> #define FB_MODE_IS_VESA 4
> #define FB_MODE_IS_CALCULATED 8
> #define FB_MODE_IS_FIRST 16
> #define FB_MODE_IS_FROM_VAR 32
>
> - FB_MODE_IS_UNKNOWN isn't used at all
This was for weird situations.
> - FB_MODE_IS_DETAILED is set by the EDID parser for modes coming from detailed
> timing descriptors, and checked right after to work around monitors that
> report the "Preferred timing mode specified in descriptor block 1" bit in
> their EDID block, but don't report any detailed timing descriptor.
> FB_MODE_IS_DETAILED is thus only used internally in the EDID parser.
>
> - FB_MODE_IS_STANDARD, FB_MODE_IS_VESA and FB_MODE_IS_CALCULATED are set but
> never used.
The reasoning behind this was struct fb_info contains a struct fb_monspecs
which had a private database of modes. So when the driver would unload
that it would skip deleting this entries. That way if drivers needed
special modes besides the standard modes it db could contain them.
> - FB_MODE_IS_FIRST is set by the EDID parser on the first detailed mode, and
> checked by fb_find_best_display() and a couple of drivers (fsl-diu-fb,
> sh_mobile_hdmi, aty and riva) to locate the first detailed mode (I will check
> if I can modify those 4 drivers to use fb_find_best_display() or something
> similar).
Okay.
> - FB_MODE_IS_FROM_VAR is set but never used.
Again in the case of using the private db the driver would mark that mode
with this flag so it would be aware that it is safe to delete.
> If I can remove direct use of the FB_MODE_IS_FIRST flag in the drivers
> mentioned above, the FB_MODE_IS_DETAILED and FB_MODE_IS_FIRST flags will only
> be used internally in the EDID parser. All the other flags are either not used
> at all, or set but never read.
>
> I'm working on sharing the EDID parser between DRM/KMS, FB and V4L2. The
> FB_MODE_IS_FIRST and FB_MODE_IS_DETAILED flags will thus become unused. Is
> there any objection to removing them then ?
Yah !!!
^ permalink raw reply
* [RFC] FB_MODE_IS_* usage
From: Laurent Pinchart @ 2012-03-08 16:26 UTC (permalink / raw)
To: linux-fbdev
Hi everybody,
While going through users of the fb_videomode structure, I realized that some
of the FB_MODE_IS_* flags didn't seem to be used for any practical purpose.
The flags are defined as
#define FB_MODE_IS_UNKNOWN 0
#define FB_MODE_IS_DETAILED 1
#define FB_MODE_IS_STANDARD 2
#define FB_MODE_IS_VESA 4
#define FB_MODE_IS_CALCULATED 8
#define FB_MODE_IS_FIRST 16
#define FB_MODE_IS_FROM_VAR 32
- FB_MODE_IS_UNKNOWN isn't used at all
- FB_MODE_IS_DETAILED is set by the EDID parser for modes coming from detailed
timing descriptors, and checked right after to work around monitors that
report the "Preferred timing mode specified in descriptor block 1" bit in
their EDID block, but don't report any detailed timing descriptor.
FB_MODE_IS_DETAILED is thus only used internally in the EDID parser.
- FB_MODE_IS_STANDARD, FB_MODE_IS_VESA and FB_MODE_IS_CALCULATED are set but
never used.
- FB_MODE_IS_FIRST is set by the EDID parser on the first detailed mode, and
checked by fb_find_best_display() and a couple of drivers (fsl-diu-fb,
sh_mobile_hdmi, aty and riva) to locate the first detailed mode (I will check
if I can modify those 4 drivers to use fb_find_best_display() or something
similar).
- FB_MODE_IS_FROM_VAR is set but never used.
If I can remove direct use of the FB_MODE_IS_FIRST flag in the drivers
mentioned above, the FB_MODE_IS_DETAILED and FB_MODE_IS_FIRST flags will only
be used internally in the EDID parser. All the other flags are either not used
at all, or set but never read.
I'm working on sharing the EDID parser between DRM/KMS, FB and V4L2. The
FB_MODE_IS_FIRST and FB_MODE_IS_DETAILED flags will thus become unused. Is
there any objection to removing them then ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
From: Sascha Hauer @ 2012-03-08 15:36 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev, Seung-Woo Kim, dri-devel, Inki Dae, Kyungmin Park
In-Reply-To: <2708446.uONhtK6raB@avalon>
On Thu, Mar 08, 2012 at 04:31:51PM +0100, Laurent Pinchart wrote:
> Hi Joonyoung,
>
> On Thursday 08 March 2012 22:05:50 Joonyoung Shim wrote:
> > On 03/08/2012 08:34 PM, Laurent Pinchart wrote:
> > > The fb_videomode structure stores the front porch and back porch in the
> > > right_margin and left_margin fields respectively. right_margin should
> > > thus be computed with hsync_start - hdisplay, and left_margin with
> > > htotal - hsync_end. The same holds for the vertical direction.
> > >
> > > Active Front Sync Back
> > > Region Porch Porch
> > >
> > > <-------------------><----------------><-------------><---------------->
> > >
> > > //////////////////|
> > >
> > > ////////////////// |
> > >
> > > ////////////////// |.................. ..................
> > >
> > > _______________
> > >
> > > <------ xres -------><- right_margin -><- hsync_len -><- left_margin -->
> > >
> > > <---- hdisplay ----->
> > > <------------ hsync_start ------------>
> > > <--------------------- hsync_end -------------------->
> > > <--------------------------------- htotal ----------------------------->
> > >
> > > Fix the fb_videomode<-> drm_mode_modeinfo conversion functions
> > > accordingly.
> > >
> > > Signed-off-by: Laurent Pinchart<laurent.pinchart@ideasonboard.com>
> > > ---
> > >
> > > drivers/gpu/drm/exynos/exynos_drm_connector.c | 16 ++++++++--------
> > > 1 files changed, 8 insertions(+), 8 deletions(-)
> > >
> > > While trying to understand how the fb_videomode and drm_mode_modeinfo
> > > fields map to each other, I found what might be a bug in the Exynos DRM
> > > driver. Could you please check and confirm that my understanding is
> > > correct ?
> >
> > Good catch. You can refer Documentation/fb/framebuffer.txt to know in
> > detail.
> >
> > Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
>
> Thank you. There's a similar issue in exynos_mipi_dsi_set_display_mode() where
> front and back porch are inverted. I'll submit a patch for that as well.
Damned. This seems to be a common misunderstanding. I never really
thought about it and always assumed that 'front porch' and 'back porch'
refers to the picture and not to the sync signal. I was so sure that
I didn't even care to google it before I saw this patch.
Sascha
--
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
* [PATCH] fb: exynos: Fix MIPI/DSI front/back porch settings
From: Laurent Pinchart @ 2012-03-08 15:35 UTC (permalink / raw)
To: linux-fbdev
The exynos_mipi_dsi_set_main_disp_[hv]porch() functions take front and
back porch arguments in that order. This maps to the fb_videomode
right/lower_margin and left/upper_margin respectively. Fix the caller
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/exynos/exynos_mipi_dsi_common.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi_common.c b/drivers/video/exynos/exynos_mipi_dsi_common.c
index 14909c1..99f6451 100644
--- a/drivers/video/exynos/exynos_mipi_dsi_common.c
+++ b/drivers/video/exynos/exynos_mipi_dsi_common.c
@@ -738,11 +738,11 @@ int exynos_mipi_dsi_set_display_mode(struct mipi_dsim_device *dsim,
if (dsim_config->auto_vertical_cnt = 0) {
exynos_mipi_dsi_set_main_disp_vporch(dsim,
dsim_config->cmd_allow,
- timing->upper_margin,
- timing->lower_margin);
+ timing->lower_margin,
+ timing->upper_margin);
exynos_mipi_dsi_set_main_disp_hporch(dsim,
- timing->left_margin,
- timing->right_margin);
+ timing->right_margin,
+ timing->left_margin);
exynos_mipi_dsi_set_main_disp_sync_area(dsim,
timing->vsync_len,
timing->hsync_len);
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
From: Laurent Pinchart @ 2012-03-08 15:31 UTC (permalink / raw)
To: Joonyoung Shim
Cc: Inki Dae, linux-fbdev, Seung-Woo Kim, Kyungmin Park, dri-devel
In-Reply-To: <4F58AEAE.4080601@samsung.com>
Hi Joonyoung,
On Thursday 08 March 2012 22:05:50 Joonyoung Shim wrote:
> On 03/08/2012 08:34 PM, Laurent Pinchart wrote:
> > The fb_videomode structure stores the front porch and back porch in the
> > right_margin and left_margin fields respectively. right_margin should
> > thus be computed with hsync_start - hdisplay, and left_margin with
> > htotal - hsync_end. The same holds for the vertical direction.
> >
> > Active Front Sync Back
> > Region Porch Porch
> >
> > <-------------------><----------------><-------------><---------------->
> >
> > //////////////////|
> >
> > ////////////////// |
> >
> > ////////////////// |.................. ..................
> >
> > _______________
> >
> > <------ xres -------><- right_margin -><- hsync_len -><- left_margin -->
> >
> > <---- hdisplay ----->
> > <------------ hsync_start ------------>
> > <--------------------- hsync_end -------------------->
> > <--------------------------------- htotal ----------------------------->
> >
> > Fix the fb_videomode<-> drm_mode_modeinfo conversion functions
> > accordingly.
> >
> > Signed-off-by: Laurent Pinchart<laurent.pinchart@ideasonboard.com>
> > ---
> >
> > drivers/gpu/drm/exynos/exynos_drm_connector.c | 16 ++++++++--------
> > 1 files changed, 8 insertions(+), 8 deletions(-)
> >
> > While trying to understand how the fb_videomode and drm_mode_modeinfo
> > fields map to each other, I found what might be a bug in the Exynos DRM
> > driver. Could you please check and confirm that my understanding is
> > correct ?
>
> Good catch. You can refer Documentation/fb/framebuffer.txt to know in
> detail.
>
> Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Thank you. There's a similar issue in exynos_mipi_dsi_set_display_mode() where
front and back porch are inverted. I'll submit a patch for that as well.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 7/7] OMAPDSS: HDMI: hot plug detect fix
From: Greg KH @ 2012-03-08 15:29 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: stable, linux-fbdev, linux-omap, Rob Clark
In-Reply-To: <1331192113.2354.2.camel@deskari>
On Thu, Mar 08, 2012 at 09:35:13AM +0200, Tomi Valkeinen wrote:
> On Wed, 2012-03-07 at 12:01 -0800, Greg KH wrote:
> > On Thu, Mar 01, 2012 at 02:26:35PM +0200, Tomi Valkeinen wrote:
> > > From: Rob Clark <rob@ti.com>
> > >
> > > The "OMAPDSS: HDMI: PHY burnout fix" commit switched the HDMI driver
> > > over to using a GPIO for plug detect. Unfortunately the ->detect()
> > > method was not also updated, causing HDMI to no longer work for the
> > > omapdrm driver (because it would actually check if a connection was
> > > detected before attempting to enable display).
> > >
> > > Signed-off-by: Rob Clark <rob@ti.com>
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >
> > You forgot to tell me what the git commit id is for this patch (it's
> > ca888a7958b3d808e4efd08ceff88913f4212c69, right?)
>
> Yes, that's the one. It wasn't in Linus's tree yet, only in fbdev tree,
> so I wasn't sure what the commit id is.
Then you should not have sent it to me, as if I were to take it then, I
could not have :(
> > And why isn't this needed for the 3.0 kernel as well?
>
> The detect() function is not present in 3.0, so there was nothing to
> break.
Ok, so everything I've queued up is all that is needed, right?
greg k-h
^ permalink raw reply
* Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
From: Joonyoung Shim @ 2012-03-08 13:05 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Inki Dae, linux-fbdev, Seung-Woo Kim, Kyungmin Park, dri-devel
In-Reply-To: <1331206495-3853-1-git-send-email-laurent.pinchart@ideasonboard.com>
On 03/08/2012 08:34 PM, Laurent Pinchart wrote:
> The fb_videomode structure stores the front porch and back porch in the
> right_margin and left_margin fields respectively. right_margin should
> thus be computed with hsync_start - hdisplay, and left_margin with
> htotal - hsync_end. The same holds for the vertical direction.
>
> Active Front Sync Back
> Region Porch Porch
> <-------------------><----------------><-------------><---------------->
>
> //////////////////|
> ////////////////// |
> ////////////////// |.................. ..................
> _______________
>
> <------ xres -------><- right_margin -><- hsync_len -><- left_margin -->
>
> <---- hdisplay ----->
> <------------ hsync_start ------------>
> <--------------------- hsync_end -------------------->
> <--------------------------------- htotal ----------------------------->
>
> Fix the fb_videomode<-> drm_mode_modeinfo conversion functions
> accordingly.
>
> Signed-off-by: Laurent Pinchart<laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/exynos/exynos_drm_connector.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> While trying to understand how the fb_videomode and drm_mode_modeinfo fields
> map to each other, I found what might be a bug in the Exynos DRM driver. Could
> you please check and confirm that my understanding is correct ?
Good catch. You can refer Documentation/fb/framebuffer.txt to know in
detail.
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Thanks.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index d620b07..7bb1dca 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -52,14 +52,14 @@ convert_to_display_mode(struct drm_display_mode *mode,
> mode->vrefresh = timing->refresh;
>
> mode->hdisplay = timing->xres;
> - mode->hsync_start = mode->hdisplay + timing->left_margin;
> + mode->hsync_start = mode->hdisplay + timing->right_margin;
> mode->hsync_end = mode->hsync_start + timing->hsync_len;
> - mode->htotal = mode->hsync_end + timing->right_margin;
> + mode->htotal = mode->hsync_end + timing->left_margin;
>
> mode->vdisplay = timing->yres;
> - mode->vsync_start = mode->vdisplay + timing->upper_margin;
> + mode->vsync_start = mode->vdisplay + timing->lower_margin;
> mode->vsync_end = mode->vsync_start + timing->vsync_len;
> - mode->vtotal = mode->vsync_end + timing->lower_margin;
> + mode->vtotal = mode->vsync_end + timing->upper_margin;
>
> if (timing->vmode& FB_VMODE_INTERLACED)
> mode->flags |= DRM_MODE_FLAG_INTERLACE;
> @@ -81,14 +81,14 @@ convert_to_video_timing(struct fb_videomode *timing,
> timing->refresh = drm_mode_vrefresh(mode);
>
> timing->xres = mode->hdisplay;
> - timing->left_margin = mode->hsync_start - mode->hdisplay;
> + timing->right_margin = mode->hsync_start - mode->hdisplay;
> timing->hsync_len = mode->hsync_end - mode->hsync_start;
> - timing->right_margin = mode->htotal - mode->hsync_end;
> + timing->left_margin = mode->htotal - mode->hsync_end;
>
> timing->yres = mode->vdisplay;
> - timing->upper_margin = mode->vsync_start - mode->vdisplay;
> + timing->lower_margin = mode->vsync_start - mode->vdisplay;
> timing->vsync_len = mode->vsync_end - mode->vsync_start;
> - timing->lower_margin = mode->vtotal - mode->vsync_end;
> + timing->upper_margin = mode->vtotal - mode->vsync_end;
>
> if (mode->flags& DRM_MODE_FLAG_INTERLACE)
> timing->vmode = FB_VMODE_INTERLACED;
^ permalink raw reply
* [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion
From: Laurent Pinchart @ 2012-03-08 11:34 UTC (permalink / raw)
To: dri-devel; +Cc: Inki Dae, Kyungmin Park, linux-fbdev, Seung-Woo Kim
The fb_videomode structure stores the front porch and back porch in the
right_margin and left_margin fields respectively. right_margin should
thus be computed with hsync_start - hdisplay, and left_margin with
htotal - hsync_end. The same holds for the vertical direction.
Active Front Sync Back
Region Porch Porch
<-------------------><----------------><-------------><---------------->
//////////////////|
////////////////// |
////////////////// |.................. ..................
_______________
<------ xres -------><- right_margin -><- hsync_len -><- left_margin -->
<---- hdisplay ----->
<------------ hsync_start ------------>
<--------------------- hsync_end -------------------->
<--------------------------------- htotal ----------------------------->
Fix the fb_videomode <-> drm_mode_modeinfo conversion functions
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
While trying to understand how the fb_videomode and drm_mode_modeinfo fields
map to each other, I found what might be a bug in the Exynos DRM driver. Could
you please check and confirm that my understanding is correct ?
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index d620b07..7bb1dca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -52,14 +52,14 @@ convert_to_display_mode(struct drm_display_mode *mode,
mode->vrefresh = timing->refresh;
mode->hdisplay = timing->xres;
- mode->hsync_start = mode->hdisplay + timing->left_margin;
+ mode->hsync_start = mode->hdisplay + timing->right_margin;
mode->hsync_end = mode->hsync_start + timing->hsync_len;
- mode->htotal = mode->hsync_end + timing->right_margin;
+ mode->htotal = mode->hsync_end + timing->left_margin;
mode->vdisplay = timing->yres;
- mode->vsync_start = mode->vdisplay + timing->upper_margin;
+ mode->vsync_start = mode->vdisplay + timing->lower_margin;
mode->vsync_end = mode->vsync_start + timing->vsync_len;
- mode->vtotal = mode->vsync_end + timing->lower_margin;
+ mode->vtotal = mode->vsync_end + timing->upper_margin;
if (timing->vmode & FB_VMODE_INTERLACED)
mode->flags |= DRM_MODE_FLAG_INTERLACE;
@@ -81,14 +81,14 @@ convert_to_video_timing(struct fb_videomode *timing,
timing->refresh = drm_mode_vrefresh(mode);
timing->xres = mode->hdisplay;
- timing->left_margin = mode->hsync_start - mode->hdisplay;
+ timing->right_margin = mode->hsync_start - mode->hdisplay;
timing->hsync_len = mode->hsync_end - mode->hsync_start;
- timing->right_margin = mode->htotal - mode->hsync_end;
+ timing->left_margin = mode->htotal - mode->hsync_end;
timing->yres = mode->vdisplay;
- timing->upper_margin = mode->vsync_start - mode->vdisplay;
+ timing->lower_margin = mode->vsync_start - mode->vdisplay;
timing->vsync_len = mode->vsync_end - mode->vsync_start;
- timing->lower_margin = mode->vtotal - mode->vsync_end;
+ timing->upper_margin = mode->vtotal - mode->vsync_end;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
timing->vmode = FB_VMODE_INTERLACED;
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH] add bochs dispi interface framebuffer driver
From: Gerd Hoffmann @ 2012-03-08 10:13 UTC (permalink / raw)
To: qemu-devel, linux-fbdev; +Cc: Gerd Hoffmann
This patchs adds a frame buffer driver for (virtual/emulated) vga cards
implementing the bochs dispi interface. Supported hardware are the
bochs vga card with vbe extension and the qemu standard vga.
The driver uses a fixed depth of 32bpp. Otherwise it supports the full
(but small) feature set of the bochs dispi interface: Resolution
switching and display panning. It is tweaked to maximize fbcon speed,
so you'll get the comfort of the framebuffer console in kvm guests
without performance penalty.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/video/Kconfig | 18 +++
drivers/video/Makefile | 1 +
drivers/video/bochsfb.c | 385 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 404 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/bochsfb.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6ca0c40..4d21f90 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -286,6 +286,24 @@ config FB_CIRRUS
Say N unless you have such a graphics board or plan to get one
before you next recompile the kernel.
+config FB_BOCHS
+ tristate "Bochs dispi interface support"
+ depends on FB && PCI
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ This is the frame buffer driver for (virtual/emulated) vga
+ cards implementing the bochs dispi interface. Supported
+ hardware are the bochs vga card with vbe extension and the
+ qemu standard vga.
+
+ The driver handles the PCI variants only. It uses a fixed
+ depth of 32bpp, anything else doesn't make sense these days.
+
+ Say Y here if you plan to run the kernel in a virtual machine
+ emulated by bochs or qemu.
+
config FB_PM2
tristate "Permedia2 support"
depends on FB && ((AMIGA && BROKEN) || PCI)
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 1426068..a065ad3 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_FB_ARMCLCD) += amba-clcd.o
obj-$(CONFIG_FB_68328) += 68328fb.o
obj-$(CONFIG_FB_GBE) += gbefb.o
obj-$(CONFIG_FB_CIRRUS) += cirrusfb.o
+obj-$(CONFIG_FB_BOCHS) += bochsfb.o
obj-$(CONFIG_FB_ASILIANT) += asiliantfb.o
obj-$(CONFIG_FB_PXA) += pxafb.o
obj-$(CONFIG_FB_PXA168) += pxa168fb.o
diff --git a/drivers/video/bochsfb.c b/drivers/video/bochsfb.c
new file mode 100644
index 0000000..18a94dc
--- /dev/null
+++ b/drivers/video/bochsfb.c
@@ -0,0 +1,385 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/vmalloc.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/fb.h>
+#include <linux/pm.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/console.h>
+#include <asm/io.h>
+
+#define VBE_DISPI_IOPORT_INDEX 0x01CE
+#define VBE_DISPI_IOPORT_DATA 0x01CF
+
+#define VBE_DISPI_INDEX_ID 0x0
+#define VBE_DISPI_INDEX_XRES 0x1
+#define VBE_DISPI_INDEX_YRES 0x2
+#define VBE_DISPI_INDEX_BPP 0x3
+#define VBE_DISPI_INDEX_ENABLE 0x4
+#define VBE_DISPI_INDEX_BANK 0x5
+#define VBE_DISPI_INDEX_VIRT_WIDTH 0x6
+#define VBE_DISPI_INDEX_VIRT_HEIGHT 0x7
+#define VBE_DISPI_INDEX_X_OFFSET 0x8
+#define VBE_DISPI_INDEX_Y_OFFSET 0x9
+#define VBE_DISPI_INDEX_VIDEO_MEMORY_64K 0xa
+
+#define VBE_DISPI_ID0 0xB0C0
+#define VBE_DISPI_ID1 0xB0C1
+#define VBE_DISPI_ID2 0xB0C2
+#define VBE_DISPI_ID3 0xB0C3
+#define VBE_DISPI_ID4 0xB0C4
+#define VBE_DISPI_ID5 0xB0C5
+
+#define VBE_DISPI_DISABLED 0x00
+#define VBE_DISPI_ENABLED 0x01
+#define VBE_DISPI_GETCAPS 0x02
+#define VBE_DISPI_8BIT_DAC 0x20
+#define VBE_DISPI_LFB_ENABLED 0x40
+#define VBE_DISPI_NOCLEARMEM 0x80
+
+enum bochs_types {
+ BOCHS_QEMU_STDVGA,
+ BOCHS_UNKNOWN,
+};
+
+static const char *bochs_names[] = {
+ [ BOCHS_QEMU_STDVGA ] = "QEMU standard vga",
+ [ BOCHS_UNKNOWN ] = "unknown",
+};
+
+static struct fb_fix_screeninfo bochsfb_fix __devinitdata = {
+ .id = "bochsfb",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_TRUECOLOR,
+ .accel = FB_ACCEL_NONE,
+ .xpanstep = 1,
+ .ypanstep = 1,
+};
+
+static struct fb_var_screeninfo bochsfb_var __devinitdata = {
+ .xres = 1024,
+ .yres = 768,
+ .bits_per_pixel = 32,
+#ifdef __BIG_ENDIAN
+ .transp = { .length = 8, .offset = 0 },
+ .red = { .length = 8, .offset = 8 },
+ .green = { .length = 8, .offset = 16 },
+ .blue = { .length = 8, .offset = 24 },
+#else
+ .transp = { .length = 8, .offset = 24 },
+ .red = { .length = 8, .offset = 16 },
+ .green = { .length = 8, .offset = 8 },
+ .blue = { .length = 8, .offset = 0 },
+#endif
+ .height = -1,
+ .width = -1,
+ .vmode = FB_VMODE_NONINTERLACED,
+ .pixclock = 10000,
+ .left_margin = 16,
+ .right_margin = 16,
+ .upper_margin = 16,
+ .lower_margin = 16,
+ .hsync_len = 8,
+ .vsync_len = 8,
+};
+
+static char *mode __devinitdata;
+module_param(mode, charp, 0);
+MODULE_PARM_DESC(mode, "Initial video mode e.g. '648x480'");
+
+static u16 bochs_read(u16 reg)
+{
+ outw(reg, VBE_DISPI_IOPORT_INDEX);
+ return inw(VBE_DISPI_IOPORT_DATA);
+}
+
+static void bochs_write(u16 reg, u16 val)
+{
+ outw(reg, VBE_DISPI_IOPORT_INDEX);
+ outw(val, VBE_DISPI_IOPORT_DATA);
+}
+
+static int bochsfb_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ uint32_t x,y, xv,yv, pixels;
+
+ if (var->bits_per_pixel != 32 ||
+ var->xres > 65535 ||
+ var->xres_virtual > 65535 ||
+ (var->vmode & FB_VMODE_MASK) != FB_VMODE_NONINTERLACED)
+ return -EINVAL;
+
+ x = var->xres & ~0x0f;
+ y = var->yres & ~0x03;
+ xv = var->xres_virtual & ~0x0f;
+ yv = var->yres_virtual & ~0x03;
+ if (xv < x)
+ xv = x;
+ pixels = info->fix.smem_len * 8 / info->var.bits_per_pixel;
+ yv = pixels / xv;
+ if (y > yv)
+ return -EINVAL;
+
+ var->xres = x;
+ var->yres = y;
+ var->xres_virtual = xv;
+ var->yres_virtual = yv;
+ var->xoffset = 0;
+ var->yoffset = 0;
+
+ return 0;
+}
+
+static int bochsfb_set_par(struct fb_info *info)
+{
+ dev_dbg(info->dev, "set mode: real: %dx%d, virtual: %dx%d\n",
+ info->var.xres, info->var.yres,
+ info->var.xres_virtual, info->var.yres_virtual);
+
+ info->fix.line_length = info->var.xres * info->var.bits_per_pixel / 8;
+
+ bochs_write(VBE_DISPI_INDEX_BPP, info->var.bits_per_pixel);
+ bochs_write(VBE_DISPI_INDEX_XRES, info->var.xres);
+ bochs_write(VBE_DISPI_INDEX_YRES, info->var.yres);
+ bochs_write(VBE_DISPI_INDEX_BANK, 0);
+ bochs_write(VBE_DISPI_INDEX_VIRT_WIDTH, info->var.xres_virtual);
+ bochs_write(VBE_DISPI_INDEX_VIRT_HEIGHT, info->var.yres_virtual);
+ bochs_write(VBE_DISPI_INDEX_X_OFFSET, info->var.xoffset);
+ bochs_write(VBE_DISPI_INDEX_Y_OFFSET, info->var.yoffset);
+
+ bochs_write(VBE_DISPI_INDEX_ENABLE,
+ VBE_DISPI_ENABLED | VBE_DISPI_LFB_ENABLED);
+ return 0;
+}
+
+static int bochsfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+ if (regno < 16 && info->var.bits_per_pixel = 32) {
+ red >>= 8;
+ green >>= 8;
+ blue >>= 8;
+ ((u32 *)(info->pseudo_palette))[regno] + (red << info->var.red.offset) |
+ (green << info->var.green.offset) |
+ (blue << info->var.blue.offset);
+ }
+ return 0;
+}
+
+static int bochsfb_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ bochs_write(VBE_DISPI_INDEX_X_OFFSET, var->xoffset);
+ bochs_write(VBE_DISPI_INDEX_Y_OFFSET, var->yoffset);
+ return 0;
+}
+
+static struct fb_ops bochsfb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = bochsfb_check_var,
+ .fb_set_par = bochsfb_set_par,
+ .fb_setcolreg = bochsfb_setcolreg,
+ .fb_pan_display = bochsfb_pan_display,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+static int __devinit
+bochsfb_pci_init(struct pci_dev *dp, const struct pci_device_id *ent)
+{
+ struct fb_info *p;
+ unsigned long addr, size, mem;
+ u16 id;
+ int rc = -ENODEV;
+
+ id = bochs_read(VBE_DISPI_INDEX_ID);;
+ mem = bochs_read(VBE_DISPI_INDEX_VIDEO_MEMORY_64K) * 64 * 1024;
+ dev_info(&dp->dev,"Found bochs VGA, ID 0x%x, mem %ldk, type \"%s\".\n",
+ id, mem / 1024, bochs_names[ent->driver_data]);
+ if ((id & 0xfff0) != VBE_DISPI_ID0) {
+ dev_err(&dp->dev, "ID mismatch\n");
+ goto err_out;
+ }
+
+ if (pci_enable_device(dp) < 0) {
+ dev_err(&dp->dev, "Cannot enable PCI device\n");
+ goto err_out;
+ }
+
+ if ((dp->resource[0].flags & IORESOURCE_MEM) = 0)
+ goto err_disable;
+ addr = pci_resource_start(dp, 0);
+ size = pci_resource_len(dp, 0);
+ if (addr = 0)
+ goto err_disable;
+ if (size != mem) {
+ dev_err(&dp->dev, "Size mismatch: pci=%ld, bochs=%ld\n", size, mem);
+ size = min(size, mem);
+ }
+
+ p = framebuffer_alloc(0, &dp->dev);
+ if (p = NULL) {
+ dev_err(&dp->dev, "Cannot allocate framebuffer structure\n");
+ rc = -ENOMEM;
+ goto err_disable;
+ }
+
+ if (pci_request_region(dp, 0, "bochsfb") != 0) {
+ dev_err(&dp->dev, "Cannot request framebuffer\n");
+ rc = -EBUSY;
+ goto err_release_fb;
+ }
+
+ if (!request_region(VBE_DISPI_IOPORT_INDEX, 2, "bochsfb")) {
+ dev_err(&dp->dev, "Cannot request ioports\n");
+ rc = -EBUSY;
+ goto err_release_pci;
+ }
+
+ p->screen_base = ioremap(addr, size);
+ if (p->screen_base = NULL) {
+ dev_err(&dp->dev, "Cannot map framebuffer\n");
+ rc = -ENOMEM;
+ goto err_release_ports;
+ }
+ memset(p->screen_base, 0, size);
+
+ pci_set_drvdata(dp, p);
+ p->fbops = &bochsfb_ops;
+ p->flags = FBINFO_FLAG_DEFAULT
+ | FBINFO_READS_FAST
+ | FBINFO_HWACCEL_XPAN
+ | FBINFO_HWACCEL_YPAN;
+ p->pseudo_palette = kmalloc(sizeof(u32) * 16, GFP_KERNEL);
+ p->fix = bochsfb_fix;
+ p->fix.smem_start = addr;
+ p->fix.smem_len = size;
+
+ p->var = bochsfb_var;
+ bochsfb_check_var(&p->var, p);
+ if (mode) {
+ fb_find_mode(&p->var, p, mode, NULL, 0, NULL, 32);
+ }
+
+ if (register_framebuffer(p) < 0) {
+ dev_err(&dp->dev,"Framebuffer failed to register\n");
+ goto err_unmap;
+ }
+
+ dev_info(&dp->dev,"fb%d: bochs VGA frame buffer initialized.\n",
+ p->node);
+
+ return 0;
+
+ err_unmap:
+ iounmap(p->screen_base);
+ err_release_ports:
+ release_region(VBE_DISPI_IOPORT_INDEX, 2);
+ err_release_pci:
+ pci_release_region(dp, 0);
+ err_release_fb:
+ framebuffer_release(p);
+ err_disable:
+ err_out:
+ return rc;
+}
+
+static void __devexit bochsfb_remove(struct pci_dev *dp)
+{
+ struct fb_info *p = pci_get_drvdata(dp);
+
+ if (p->screen_base = NULL)
+ return;
+ unregister_framebuffer(p);
+ iounmap(p->screen_base);
+ p->screen_base = NULL;
+ release_region(VBE_DISPI_IOPORT_INDEX, 2);
+ pci_release_region(dp, 0);
+ kfree(p->pseudo_palette);
+ framebuffer_release(p);
+}
+
+static struct pci_device_id bochsfb_pci_tbl[] = {
+ {
+ .vendor = 0x1234,
+ .device = 0x1111,
+ .subvendor = 0x1af4,
+ .subdevice = 0x1100,
+ .driver_data = BOCHS_QEMU_STDVGA,
+ },
+ {
+ .vendor = 0x1234,
+ .device = 0x1111,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .driver_data = BOCHS_UNKNOWN,
+ },
+ { /* end of list */ }
+};
+
+MODULE_DEVICE_TABLE(pci, bochsfb_pci_tbl);
+
+static struct pci_driver bochsfb_driver = {
+ .name = "bochsfb",
+ .id_table = bochsfb_pci_tbl,
+ .probe = bochsfb_pci_init,
+ .remove = __devexit_p(bochsfb_remove),
+};
+
+#ifndef MODULE
+static int __init bochsfb_setup(char *options)
+{
+ char *this_opt;
+
+ if (!options || !*options)
+ return 0;
+
+ while ((this_opt = strsep(&options, ",")) != NULL) {
+ if (!*this_opt)
+ continue;
+ if (!strncmp(this_opt, "mode:", 5))
+ mode = this_opt + 5;
+ else
+ mode = this_opt;
+ }
+ return 0;
+}
+#endif
+
+int __init bochs_init(void)
+{
+#ifndef MODULE
+ char *option = NULL;
+
+ if (fb_get_options("bochsfb", &option))
+ return -ENODEV;
+ bochsfb_setup(option);
+#endif
+ return pci_register_driver(&bochsfb_driver);
+}
+
+module_init(bochs_init);
+
+static void __exit bochsfb_exit(void)
+{
+ pci_unregister_driver(&bochsfb_driver);
+}
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Gerd Hoffmann <kraxel@redhat.com>");
+MODULE_DESCRIPTION("bochs dispi interface framebuffer driver");
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
From: Archit Taneja @ 2012-03-08 9:51 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1331199297.2354.62.camel@deskari>
On Thursday 08 March 2012 03:04 PM, Tomi Valkeinen wrote:
> On Thu, 2012-03-08 at 14:52 +0530, Archit Taneja wrote:
>> On Thursday 08 March 2012 02:16 PM, Tomi Valkeinen wrote:
>>> On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote:
<snip>
>> Oh okay. But the comment after the patch set still says "It's ok if the
>> output-driver register fails.", we could change it to "It's ok if the
>> output-driver probe fails."
>
> Well, I guess this goes into nitpicking area, but if there are no
> devices, probe is not called at all. So I think it's the driver register
> that fails in that case. If there is a device, and it is probed, and
> that fails, then it's probe which fails.
Yes, that's fair enough I guess.
<snip>
>>
>> If we ensure that none of our probes return ENODEV(even though it may
>> make sense to return it if a func within probe fails), we could
>> differentiate between the 2 cases, right?
>
> True, I thought about that. But we can never be sure that the functions
> called by the probe (clk_get, or whatever) won't return ENODEV. Of
> course, we could check what they return, and change the error to
> something else, but I'm not sure if that's good either.
That's true.
<snip>
> Alternatively, if the platform driver code was changed to tell us
> clearly if it was the probe that failed or if there just weren't any
> devices, we could also use that.
Yes, I wonder how that could be done.
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
From: Tomi Valkeinen @ 2012-03-08 9:34 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <4F587A62.3020202@ti.com>
[-- Attachment #1: Type: text/plain, Size: 5275 bytes --]
On Thu, 2012-03-08 at 14:52 +0530, Archit Taneja wrote:
> On Thursday 08 March 2012 02:16 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote:
> >> On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
> >
> >>> - r = hdmi_init_platform_driver();
> >>> - if (r) {
> >>> - DSSERR("Failed to initialize hdmi\n");
> >>> - goto err_hdmi;
> >>> + /*
> >>> + * It's ok if the output-driver register fails. It happens, for example,
> >>> + * when there is no output-device (e.g. SDI for OMAP4).
> >>> + */
> >>
> >> Suppose we do a omap2plus_defconfig, CONFIG_OMAP2_DSS_SDI would be
> >> selected, and sdi.c would be built, if we boot on OMAP4, why would a sdi
> >> driver register cause a failure? Wouldn't the sdi driver just get
> >> registered, and wait till eternity for the corresponding sdi platform
> >> device to get registered?
> >
> > No. Well, yes.
> >
> > Currently we use platform_driver_register() to register the drivers, and
> > it does just what you described. But a few patches later I change
> > platform_driver_register() to platform_driver_probe(), which will return
> > ENODEV if there are no matching devices for the driver.
> >
> > I originally had the platform_driver_probe() patch before this patch,
> > and thus the comment above made sense. Now the patch is after this
> > patch, so the comment is not exactly right until the probe patch is also
> > applied.
>
> Oh okay. But the comment after the patch set still says "It's ok if the
> output-driver register fails.", we could change it to "It's ok if the
> output-driver probe fails."
Well, I guess this goes into nitpicking area, but if there are no
devices, probe is not called at all. So I think it's the driver register
that fails in that case. If there is a device, and it is probed, and
that fails, then it's probe which fails.
> > The point with platform_driver_probe() is that it can be used with
> > non-removable devices which are created at boot time, like the DSS
> > components. With platform_driver_probe() the probe function is called
> > only at that one time, and never afterwards. So probe can be in __init
> > section, and thrown away after init.
>
> So platform_driver_probe() is like a driver_register() + probe().
Yes. Well, when platform_driver_register() is called, and the devices
are already present, it will call the probe also. So in that sense they
are similar. The difference is that for platform_driver_register() the
probe pointer must be in the driver struct, and it stays there even
after init. For platform_driver_probe(), the probe pointer is given as
an argument to the function, and thus it's not stored anywhere and can
be thrown away afterwards.
> Okay, in our case, all the devices are created at boot time, and if
> omapdss were a module, the probes would have been thrown away after
> module_init(), right?
Yes. If omapdss is a module, the functions marked with __init are
discarded after the module_init is done. If omapdss is built-in, the
__init funcs are thrown away after the kernel's init done.
> > One side effect of using platform_driver_probe() is that it returns
> > ENODEV is there are no devices. In a simple module, the error can be
> > then returned from module_init, thus causing the whole module to be
> > unloaded. Our case is a bit more complex as we have multiple drivers in
> > the same module.
> >
> > A downside with that is that we don't really know if the ENODEV error
> > happened because there were no devices (which is ok), or if it came from
> > probe function (which is not so ok). However, I thought that it doesn't
> > matter if an output driver has failed. We can still continue with the
> > other output drivers just fine.
>
> If we ensure that none of our probes return ENODEV(even though it may
> make sense to return it if a func within probe fails), we could
> differentiate between the 2 cases, right?
True, I thought about that. But we can never be sure that the functions
called by the probe (clk_get, or whatever) won't return ENODEV. Of
course, we could check what they return, and change the error to
something else, but I'm not sure if that's good either.
> >
> > Actually, there is a small problem. If, for example, DSI driver fails to
> > load, and DPI driver tries to use DSI PLL...
>
> If we could differentiate between an error occuring because the device
> doesn't exist and an error occuring because the probe failed, we could
> bail out if any of the probes fail, right?
Yes, but it feels a bit hackish to try to use the error as I pointed out
above. So I'd rather go the other way: the drivers should somehow
register the stuff they offer, so for example when the DSI1 is probed,
it should register the DSI1 PLL to dss core. And DPI would have to ask
for the DSI1 PLL from dss core.
That, of course, is not a trivial change, so for the moment this stuff
is slightly broken in error cases. Perhaps we could figure out some kind
of clean hack for that...
Alternatively, if the platform driver code was changed to tell us
clearly if it was the probe that failed or if there just weren't any
devices, we could also use that.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 16/21] OMAPDSS: handle output-driver reg/unreg more dynamically
From: Archit Taneja @ 2012-03-08 9:34 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1331196364.2354.49.camel@deskari>
On Thursday 08 March 2012 02:16 PM, Tomi Valkeinen wrote:
> On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote:
>> On Wednesday 07 March 2012 06:14 PM, Tomi Valkeinen wrote:
>
>>> - r = hdmi_init_platform_driver();
>>> - if (r) {
>>> - DSSERR("Failed to initialize hdmi\n");
>>> - goto err_hdmi;
>>> + /*
>>> + * It's ok if the output-driver register fails. It happens, for example,
>>> + * when there is no output-device (e.g. SDI for OMAP4).
>>> + */
>>
>> Suppose we do a omap2plus_defconfig, CONFIG_OMAP2_DSS_SDI would be
>> selected, and sdi.c would be built, if we boot on OMAP4, why would a sdi
>> driver register cause a failure? Wouldn't the sdi driver just get
>> registered, and wait till eternity for the corresponding sdi platform
>> device to get registered?
>
> No. Well, yes.
>
> Currently we use platform_driver_register() to register the drivers, and
> it does just what you described. But a few patches later I change
> platform_driver_register() to platform_driver_probe(), which will return
> ENODEV if there are no matching devices for the driver.
>
> I originally had the platform_driver_probe() patch before this patch,
> and thus the comment above made sense. Now the patch is after this
> patch, so the comment is not exactly right until the probe patch is also
> applied.
Oh okay. But the comment after the patch set still says "It's ok if the
output-driver register fails.", we could change it to "It's ok if the
output-driver probe fails."
>
> The point with platform_driver_probe() is that it can be used with
> non-removable devices which are created at boot time, like the DSS
> components. With platform_driver_probe() the probe function is called
> only at that one time, and never afterwards. So probe can be in __init
> section, and thrown away after init.
So platform_driver_probe() is like a driver_register() + probe().
Okay, in our case, all the devices are created at boot time, and if
omapdss were a module, the probes would have been thrown away after
module_init(), right?
>
> One side effect of using platform_driver_probe() is that it returns
> ENODEV is there are no devices. In a simple module, the error can be
> then returned from module_init, thus causing the whole module to be
> unloaded. Our case is a bit more complex as we have multiple drivers in
> the same module.
>
> A downside with that is that we don't really know if the ENODEV error
> happened because there were no devices (which is ok), or if it came from
> probe function (which is not so ok). However, I thought that it doesn't
> matter if an output driver has failed. We can still continue with the
> other output drivers just fine.
If we ensure that none of our probes return ENODEV(even though it may
make sense to return it if a func within probe fails), we could
differentiate between the 2 cases, right?
>
> Actually, there is a small problem. If, for example, DSI driver fails to
> load, and DPI driver tries to use DSI PLL...
If we could differentiate between an error occuring because the device
doesn't exist and an error occuring because the probe failed, we could
bail out if any of the probes fail, right?
Archit
>
> Tomi
>
^ 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