* Re: [PATCH] video: fbdev: omap2: dss: dispc.c: Remove some unused functions
From: Tomi Valkeinen @ 2015-01-13 11:22 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Jean-Christophe Plagniol-Villard, Grant Likely, Rob Herring,
linux-omap, linux-fbdev, linux-kernel, devicetree
In-Reply-To: <1420126149-27019-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On 01/01/15 17:29, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> dispc_wb_go() dispc_wb_go_busy() dispc_wb_get_framedone_irq()
> dispc_mgr_get_clock_div() dispc_wb_is_enabled() dispc_wb_enable()
> dispc_wb_setup() dispc_enable_fifomerge() dispc_wb_set_channel_in()
>
> This was partially found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
> ---
> drivers/video/fbdev/omap2/dss/dispc.c | 124 ---------------------------------
> drivers/video/fbdev/omap2/dss/dss.h | 12 ----
> 2 files changed, 136 deletions(-)
The functions are for DSS's write-back functionality. We're going to
implement that hopefully sometime soon, so I don't want to remove those
functions.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: omap2: Fix typo in tvc_probe_pdata
From: Tomi Valkeinen @ 2015-01-13 11:26 UTC (permalink / raw)
To: Rasmus Villemoes, Jean-Christophe Plagniol-Villard
Cc: linux-omap, linux-fbdev, linux-kernel
In-Reply-To: <1420463387-26391-1-git-send-email-linux@rasmusvillemoes.dk>
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
On 05/01/15 15:09, Rasmus Villemoes wrote:
> Assigning ddata->invert_polarity to itself is not very useful; the
> context suggests that the right-hand side should have been
> pdata->invert_polarity.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c b/drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c
> index 9a2b5ce58545..8511c648a15c 100644
> --- a/drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c
> +++ b/drivers/video/fbdev/omap2/displays-new/connector-analog-tv.c
> @@ -208,7 +208,7 @@ static int tvc_probe_pdata(struct platform_device *pdev)
> ddata->in = in;
>
> ddata->connector_type = pdata->connector_type;
> - ddata->invert_polarity = ddata->invert_polarity;
> + ddata->invert_polarity = pdata->invert_polarity;
>
> dssdev = &ddata->dssdev;
> dssdev->name = pdata->name;
Good catch, thanks! Queueing for 3.20 (as no one is using that flag in
3.19).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: geocode: remove unneeded NULL check
From: Tomi Valkeinen @ 2015-01-13 11:31 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Jean-Christophe Plagniol-Villard, linux-geode, linux-fbdev,
linux-kernel
In-Reply-To: <1420548302-11489-2-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On 06/01/15 14:45, Sudip Mukherjee wrote:
> the check for info is not required as we are checking it immediately
> after gxfb_init_fbinfo() and lxfb_init_fbinfo() and returnig -ENOMEM
> if it is NULL.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
> Hi Tomi,
> This patch is similar to my last patch which you have already queued
> for 3.20. if you can revert that then i can send you a single patch
> with all these three changes together.
No need for that, two separate patches is fine. So queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: savage: remove unused variable
From: Tomi Valkeinen @ 2015-01-13 11:34 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Antonino Daplas, Jean-Christophe Plagniol-Villard, linux-fbdev,
linux-kernel
In-Reply-To: <1420549930-16607-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
On 06/01/15 15:12, Sudip Mukherjee wrote:
> vga_in8() was storing the return value in tmp, but that return value
> was never used again. so it should be safe to remove those variables.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
>
> just one doubt:
> vga_in8() is calling savage_in8() which is a readb().
> so in effect we are reading one byte from
> (par->mmio.vbase + 0x8000 + 0x3da) and then discarding that value.
> so if we are discarding that value then why we are reading it?
Sometimes reading a HW register without actually using the returned
value has some effect. I don't know if there's a reason for that in this
case, though, as I'm not familiar with the HW.
In any case, it's safer to keep the read there as you did.
Queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] video: vt8500lcdfb: remove unneeded continue
From: Tomi Valkeinen @ 2015-01-13 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1420608948-4550-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
On 07/01/15 07:35, Sudip Mukherjee wrote:
> continue is not needed at the end of a for loop, also removed the
> braces which were no longer required.
>
Thanks, queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] fbdev: ssd1307fb: check return value while setting offset
From: Tomi Valkeinen @ 2015-01-13 11:43 UTC (permalink / raw)
To: Lad, Prabhakar, LFBDEV, Jean-Christophe Plagniol-Villard,
Maxime Ripard
Cc: LKML
In-Reply-To: <1420705079-3741-3-git-send-email-prabhakar.csengg@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
On 08/01/15 10:17, Lad, Prabhakar wrote:
> this patch checks the return value of write command while
> setting the display offset.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> drivers/video/fbdev/ssd1307fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 70e3ce8..a7ecaa6 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -342,7 +342,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
>
> /* set display offset value */
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
> - ret = ssd1307fb_write_cmd(par->client, 0x20);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x20);
> if (ret < 0)
> return ret;
Hrm, what's that supposed to do? If both calls to ssd1307fb_write_cmd()
return an error, they are anded, resulting in a garbage error code...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] fbdev: ssd1307fb: check return value while setting offset
From: Prabhakar Lad @ 2015-01-13 11:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: LFBDEV, Jean-Christophe Plagniol-Villard, Maxime Ripard, LKML
In-Reply-To: <54B504EF.4000809@ti.com>
On Tue, Jan 13, 2015 at 11:43 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 08/01/15 10:17, Lad, Prabhakar wrote:
>> this patch checks the return value of write command while
>> setting the display offset.
>>
>> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>> ---
>> drivers/video/fbdev/ssd1307fb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
>> index 70e3ce8..a7ecaa6 100644
>> --- a/drivers/video/fbdev/ssd1307fb.c
>> +++ b/drivers/video/fbdev/ssd1307fb.c
>> @@ -342,7 +342,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
>>
>> /* set display offset value */
>> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
>> - ret = ssd1307fb_write_cmd(par->client, 0x20);
>> + ret = ret & ssd1307fb_write_cmd(par->client, 0x20);
>> if (ret < 0)
>> return ret;
>
> Hrm, what's that supposed to do? If both calls to ssd1307fb_write_cmd()
> return an error, they are anded, resulting in a garbage error code...
>
Agreed I have just aligned this to rest of the code in this function.
Maxime if you are OK I'll post a patch returning error then and there ?
Thanks,
--Prabhakar Lad
^ permalink raw reply
* Re: FOSDEM15: Graphics DevRoom: call for speakers.
From: Thierry Reding @ 2015-01-13 12:14 UTC (permalink / raw)
To: Luc Verhaegen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
xorg-devel-go0+a7rfsptAfugRpC6u6w,
xorg-announce-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
wayland-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
xorg-go0+a7rfsptAfugRpC6u6w, directfb-dev-iGvX3keArt1g9hUCZPvPmw,
mir-devel-nLRlyDuq1AZFpShjVBNYrg,
mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141209143926.GB17341-AgBVmzD5pcezQB+pC5nmwQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
On Tue, Dec 09, 2014 at 03:39:26PM +0100, Luc Verhaegen wrote:
> On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
> > Hi,
> >
> > At FOSDEM on the 31st of january and the 1st of February 2015, there
> > will be another graphics DevRoom. URL: https://fosdem.org/2015/
>
> > Slots will be handed out on a first come, first serve basis. The best
> > slots will go to those who apply the earliest. The amount of slots is
> > currently not known yet, but i expect there to be around 16 available (8
> > on each day), so act quickly.
>
> > As for deadlines, i hope to have a pretty much complete schedule between
> > christmas and the new year. The rockhard printed schedule deadline is
> > probably January 9th, after that you will not be featured in the booklet
> > and you will have a lot less visitors. I will hopefully be able to lock
> > down entries and descriptions after that date.
>
> It's been more than 2 months since the original email, it's less than
> two months away from the event, and one month away from what usually is
> the deadline for the booklet. File your talk now, while there are still
> some useful slots available.
>
> Also, for those who have filed already but who have left their abstracts
> open, please get those filed in ASAP. Your talk will be only be ordered
> in when at least the basics are provided.
Hi Luc,
I realize I'm terribly late, but it took quite some time to get travel
arranged. Looking at the schedule there still seem to be some free
slots. Does it make sense to still submit a talk? I was asked to give
one on atomic modesetting from a driver developer's perspective.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: FOSDEM15: Graphics DevRoom: call for speakers.
From: Luc Verhaegen @ 2015-01-13 12:27 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-fbdev, dri-devel, xorg-devel, xorg-announce, wayland-devel,
xorg, directfb-dev, mir-devel, mesa-dev, linux-media
In-Reply-To: <20150113121415.GA22145@ulmo.nvidia.com>
On Tue, Jan 13, 2015 at 01:14:17PM +0100, Thierry Reding wrote:
> On Tue, Dec 09, 2014 at 03:39:26PM +0100, Luc Verhaegen wrote:
> > On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
> > > Hi,
> > >
> > > At FOSDEM on the 31st of january and the 1st of February 2015, there
> > > will be another graphics DevRoom. URL: https://fosdem.org/2015/
> >
> > > Slots will be handed out on a first come, first serve basis. The best
> > > slots will go to those who apply the earliest. The amount of slots is
> > > currently not known yet, but i expect there to be around 16 available (8
> > > on each day), so act quickly.
> >
> > > As for deadlines, i hope to have a pretty much complete schedule between
> > > christmas and the new year. The rockhard printed schedule deadline is
> > > probably January 9th, after that you will not be featured in the booklet
> > > and you will have a lot less visitors. I will hopefully be able to lock
> > > down entries and descriptions after that date.
> >
> > It's been more than 2 months since the original email, it's less than
> > two months away from the event, and one month away from what usually is
> > the deadline for the booklet. File your talk now, while there are still
> > some useful slots available.
> >
> > Also, for those who have filed already but who have left their abstracts
> > open, please get those filed in ASAP. Your talk will be only be ordered
> > in when at least the basics are provided.
>
> Hi Luc,
>
> I realize I'm terribly late, but it took quite some time to get travel
> arranged. Looking at the schedule there still seem to be some free
> slots. Does it make sense to still submit a talk? I was asked to give
> one on atomic modesetting from a driver developer's perspective.
>
> Thierry
Yes, but be quick, the hard booklet deadline is thursday evening. I will
not be accepting talks past tomorrow evening.
Luc Verhaegen.
^ permalink raw reply
* Re: [PATCH 3/5] video: atafb: Remove obsolete IRQ_TYPE_PRIO
From: Tomi Valkeinen @ 2015-01-13 12:51 UTC (permalink / raw)
To: Geert Uytterhoeven, David S. Miller,
Jean-Christophe Plagniol-Villard, Jaroslav Kysela, Takashi Iwai
Cc: linux-m68k, linux-kernel, linux-fbdev
In-Reply-To: <1421052021-12560-4-git-send-email-geert@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]
On 12/01/15 10:40, Geert Uytterhoeven wrote:
> IRQ_TYPE_PRIO is no longer used by the Atari platform interrupt code
> since commit 734085651c9b80aa ("[PATCH] m68k: convert atari irq code")
> in v2.6.18-rc1, so drop it.
>
> Note that its value has been reused for a different purpose
> (IRQ_TYPE_EDGE_FALLING) since commit 6a6de9ef5850d063 ("[PATCH] genirq:
> core") in v2.6.18-rc1.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: linux-fbdev@vger.kernel.org
> ---
> drivers/video/fbdev/atafb.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
> index b2d38097a95718ce..7b231771a4b668b0 100644
> --- a/drivers/video/fbdev/atafb.c
> +++ b/drivers/video/fbdev/atafb.c
> @@ -3121,8 +3121,7 @@ int __init atafb_init(void)
> printk("atafb_init: initializing Falcon hw\n");
> fbhw = &falcon_switch;
> atafb_ops.fb_setcolreg = &falcon_setcolreg;
> - error = request_irq(IRQ_AUTO_4, falcon_vbl_switcher,
> - IRQ_TYPE_PRIO,
> + error = request_irq(IRQ_AUTO_4, falcon_vbl_switcher, 0,
> "framebuffer:modeswitch",
> falcon_vbl_switcher);
> if (error)
>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH resend] console/dummy: Move screen size selection from CPP to Kconfig
From: Tomi Valkeinen @ 2015-01-13 12:55 UTC (permalink / raw)
To: Geert Uytterhoeven, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1421093822-26761-1-git-send-email-geert@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 311 bytes --]
On 12/01/15 22:17, Geert Uytterhoeven wrote:
> PA-RISC already handled the dummy console screen size selection in
> Kconfig, so generalize this to other platforms.
>
> ARM keeps on using screen_info, which is filled in by
> platform-specific code, or from ATAGS.
Thanks, queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH][RESEND] static code analysis from cppcheck reports:
From: Tomi Valkeinen @ 2015-01-13 13:15 UTC (permalink / raw)
To: Colin King, Jean-Christophe Plagniol-Villard, linux-fbdev; +Cc: linux-kernel
In-Reply-To: <1421076472-7101-1-git-send-email-colin.king@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
On 12/01/15 17:27, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> [drivers/video/fbdev/broadsheetfb.c:673]:
> (error) Memory leak: sector_buffer
>
> sector_buffer is not being kfree'd on each call to
> broadsheet_spiflash_rewrite_sector(), so free it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/video/fbdev/broadsheetfb.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Thanks, I've queued this for 3.19 fbdev fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] video: Drop superfluous "select VT_HW_CONSOLE_BINDING"
From: Tomi Valkeinen @ 2015-01-13 13:19 UTC (permalink / raw)
To: Geert Uytterhoeven, Jean-Christophe Plagniol-Villard
Cc: David Airlie, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <1421093413-26336-2-git-send-email-geert@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
On 12/01/15 22:10, Geert Uytterhoeven wrote:
> commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 ("fbdev: fbcon: select
> VT_HW_CONSOLE_BINDING") made FRAMEBUFFER_CONSOLE always select
> VT_HW_CONSOLE_BINDING, but forgot to remove
>
> select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>
> from the individual drivers' sections that already did this before.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> v2:
> - Split in two (drm and video) patches.
> ---
> drivers/video/fbdev/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 4916c97216f880fc..f2c3fb7d03992ad1 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2151,7 +2151,6 @@ config FB_PS3
> select FB_SYS_COPYAREA
> select FB_SYS_IMAGEBLIT
> select FB_SYS_FOPS
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> ---help---
> Include support for the virtual frame buffer in the PS3 platform.
>
>
Thanks, queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] fbdev: ssd1307fb: check return value while setting offset
From: Maxime Ripard @ 2015-01-13 13:39 UTC (permalink / raw)
To: Prabhakar Lad
Cc: Tomi Valkeinen, LFBDEV, Jean-Christophe Plagniol-Villard, LKML
In-Reply-To: <CA+V-a8u0RARw84FYa661VZCYpXkZYkXmtc03jCXU=t0aoGvg9Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]
On Tue, Jan 13, 2015 at 11:53:01AM +0000, Prabhakar Lad wrote:
> On Tue, Jan 13, 2015 at 11:43 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 08/01/15 10:17, Lad, Prabhakar wrote:
> >> this patch checks the return value of write command while
> >> setting the display offset.
> >>
> >> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> >> ---
> >> drivers/video/fbdev/ssd1307fb.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> >> index 70e3ce8..a7ecaa6 100644
> >> --- a/drivers/video/fbdev/ssd1307fb.c
> >> +++ b/drivers/video/fbdev/ssd1307fb.c
> >> @@ -342,7 +342,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
> >>
> >> /* set display offset value */
> >> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
> >> - ret = ssd1307fb_write_cmd(par->client, 0x20);
> >> + ret = ret & ssd1307fb_write_cmd(par->client, 0x20);
> >> if (ret < 0)
> >> return ret;
> >
> > Hrm, what's that supposed to do? If both calls to ssd1307fb_write_cmd()
> > return an error, they are anded, resulting in a garbage error code...
> >
> Agreed I have just aligned this to rest of the code in this function.
>
> Maxime if you are OK I'll post a patch returning error then and there ?
I'm not sure what the question is, but Tomi is right, having two
returns seems the right thing to do.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: ssd1307fb: drop unused function ssd1307fb_write_data()
From: Maxime Ripard @ 2015-01-13 13:43 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen, LKML
In-Reply-To: <1421090474-4243-1-git-send-email-prabhakar.csengg@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
On Mon, Jan 12, 2015 at 07:21:14PM +0000, Lad, Prabhakar wrote:
> this patch drops the unused function ssd1307fb_write_data().
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-13 13:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Noralf,
>> },
>>
>> But nothing came up how do I register ? any quick pointer would be helpful.
>
> Copy/symlink fbtft.h to include/fbtft.h and do it like this:
> https://github.com/notro/fbtft/wiki/Build-kernel-and-fbtft-drivers#configure-devices
>
> Or use the fbtft_device module:
> https://github.com/notro/fbtft/wiki/fbtft_device
> ssd1306 entry:
> https://github.com/notro/fbtft/blob/master/fbtft_device.c#L272
> The values can be set/changed using module arguments.
>
Thanks for the pointers that helped!
will the regwidth and buswidth be populated ?
I am not sure what these two should be set to.
Thanks And Regards,
--Sagar
^ permalink raw reply
* Re: [PATCH 2/2] fbdev: ssd1307fb: check return value while setting offset
From: Prabhakar Lad @ 2015-01-13 13:46 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tomi Valkeinen, LFBDEV, Jean-Christophe Plagniol-Villard, LKML
In-Reply-To: <20150113133903.GV4891@lukather>
On Tue, Jan 13, 2015 at 1:39 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Jan 13, 2015 at 11:53:01AM +0000, Prabhakar Lad wrote:
>> On Tue, Jan 13, 2015 at 11:43 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On 08/01/15 10:17, Lad, Prabhakar wrote:
>> >> this patch checks the return value of write command while
>> >> setting the display offset.
>> >>
>> >> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>> >> ---
>> >> drivers/video/fbdev/ssd1307fb.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
>> >> index 70e3ce8..a7ecaa6 100644
>> >> --- a/drivers/video/fbdev/ssd1307fb.c
>> >> +++ b/drivers/video/fbdev/ssd1307fb.c
>> >> @@ -342,7 +342,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
>> >>
>> >> /* set display offset value */
>> >> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
>> >> - ret = ssd1307fb_write_cmd(par->client, 0x20);
>> >> + ret = ret & ssd1307fb_write_cmd(par->client, 0x20);
>> >> if (ret < 0)
>> >> return ret;
>> >
>> > Hrm, what's that supposed to do? If both calls to ssd1307fb_write_cmd()
>> > return an error, they are anded, resulting in a garbage error code...
>> >
>> Agreed I have just aligned this to rest of the code in this function.
>>
>> Maxime if you are OK I'll post a patch returning error then and there ?
>
> I'm not sure what the question is, but Tomi is right, having two
> returns seems the right thing to do.
>
OK I'll post a new patch having two separate returns.
Thanks,
--Prabhakar Lad
^ permalink raw reply
* Re: [PATCH v4 3/3] arm: dts: omap3-gta04: Add handling for tv output
From: Tony Lindgren @ 2015-01-13 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54B4EF43.50300@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [150113 02:14]:
> On 03/12/14 23:33, Marek Belisko wrote:
> > Add handling for gta04 tv out chain:
> > venc -> opa362 -> svideo
> >
> > Use invert-polarity in venc node because opa362
> > is doing polarity inversion also.
> >
> > Signed-off-by: Marek Belisko <marek@goldelico.com>
> > ---
> > arch/arm/boot/dts/omap3-gta04.dtsi | 49 ++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 49 insertions(+)
>
> Looks fine to me.
>
> Tony, do you want to pick this up? I can take the first two patches via
> fbdev.
OK will pick the dtsi change.
Thanks,
Tony
^ permalink raw reply
* [PATCH] video: hgafb: remove unneeded comparison
From: Sudip Mukherjee @ 2015-01-13 16:26 UTC (permalink / raw)
To: Ferenc Bakonyi, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Sudip Mukherjee, linux-nvidia, linux-fbdev, linux-kernel
var->yoffset is of the type __u32, hence the comparison will always
be false.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/video/fbdev/hgafb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
index 5ff9fe2..15d3ccf 100644
--- a/drivers/video/fbdev/hgafb.c
+++ b/drivers/video/fbdev/hgafb.c
@@ -417,8 +417,7 @@ static int hgafb_pan_display(struct fb_var_screeninfo *var,
struct fb_info *info)
{
if (var->vmode & FB_VMODE_YWRAP) {
- if (var->yoffset < 0 ||
- var->yoffset >= info->var.yres_virtual ||
+ if (var->yoffset >= info->var.yres_virtual ||
var->xoffset)
return -EINVAL;
} else {
--
1.8.1.2
^ permalink raw reply related
* [PATCH] OMAPDSS: hdmi5: remove unneeded check
From: Sudip Mukherjee @ 2015-01-13 16:58 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard
Cc: Sudip Mukherjee, linux-omap, linux-fbdev, linux-kernel
prior to this check we are checking for word_length_16b and if word_length_16b
is false then we are returning with -EINVAL.
So at this point word_length_16b can only be true.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/video/fbdev/omap2/dss/hdmi5_core.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c
index a3cfe3d..6bf4b75 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c
@@ -858,10 +858,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp,
core_cfg.layout = HDMI_AUDIO_LAYOUT_8CH;
/* DMA settings */
- if (word_length_16b)
- audio_dma.transfer_size = 0x10;
- else
- audio_dma.transfer_size = 0x20;
+ audio_dma.transfer_size = 0x10;
audio_dma.block_size = 0xC0;
audio_dma.mode = HDMI_AUDIO_TRANSF_DMA;
audio_dma.fifo_threshold = 0x20; /* in number of samples */
--
1.8.1.2
^ permalink raw reply related
* [PATCH] video: fbdev: tridentfb: Remove unused function
From: Rickard Strandqvist @ 2015-01-13 18:19 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Rickard Strandqvist, Jingoo Han, Laurent Pinchart, Rob Clark,
linux-fbdev, linux-kernel
Remove the function shadowmode_off() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/video/fbdev/tridentfb.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
index 7ed9a22..b5cbd2c 100644
--- a/drivers/video/fbdev/tridentfb.c
+++ b/drivers/video/fbdev/tridentfb.c
@@ -999,11 +999,6 @@ static inline void shadowmode_on(struct tridentfb_par *par)
write3CE(par, CyberControl, read3CE(par, CyberControl) | 0x81);
}
-static inline void shadowmode_off(struct tridentfb_par *par)
-{
- write3CE(par, CyberControl, read3CE(par, CyberControl) & 0x7E);
-}
-
/* Set the hardware to the requested video mode */
static int tridentfb_set_par(struct fb_info *info)
{
--
1.7.10.4
^ permalink raw reply related
* [PATCH V2 1/3] video: fbdev: Add additional vesa modes
From: David Ung @ 2015-01-14 3:04 UTC (permalink / raw)
To: linux-fbdev
Add high resolution modes to vesa_modes struct.
Signed-off-by: David Ung <davidu@nvidia.com>
---
drivers/video/fbdev/core/modedb.c | 27 +++++++++++++++++++++++++++
include/linux/fb.h | 2 +-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
index 388f797..0b57c1df 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -468,6 +468,33 @@ const struct fb_videomode vesa_modes[] = {
/* 33 1920x1440-75 VESA */
{ NULL, 75, 1920, 1440, 3367, 352, 144, 56, 1, 224, 3,
FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 34 1920x1200-60 RB VESA */
+ { NULL, 60, 1920, 1200, 6493, 80, 48, 26, 3, 32, 6,
+ FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 35 1920x1200-60 VESA */
+ { NULL, 60, 1920, 1200, 5174, 336, 136, 36, 3, 200, 6,
+ FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 36 1920x1200-75 VESA */
+ { NULL, 75, 1920, 1200, 4077, 344, 136, 46, 3, 208, 6,
+ FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 37 1920x1200-85 VESA */
+ { NULL, 85, 1920, 1200, 3555, 352, 144, 53, 3, 208, 6,
+ FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 38 2560x1600-60 RB VESA */
+ { NULL, 60, 2560, 1600, 3724, 80, 48, 37, 3, 32, 6,
+ FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 39 2560x1600-60 VESA */
+ { NULL, 60, 2560, 1600, 2869, 472, 192, 49, 3, 280, 6,
+ FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 40 2560x1600-75 VESA */
+ { NULL, 75, 2560, 1600, 2256, 488, 208, 63, 3, 280, 6,
+ FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 41 2560x1600-85 VESA */
+ { NULL, 85, 2560, 1600, 1979, 488, 208, 73, 3, 280, 6,
+ FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+ /* 42 2560x1600-120 RB VESA */
+ { NULL, 120, 2560, 1600, 1809, 80, 48, 85, 3, 32, 6,
+ FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
};
EXPORT_SYMBOL(vesa_modes);
#endif /* CONFIG_FB_MODE_HELPERS */
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 09bb7a1..882dbd1 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -726,7 +726,7 @@ extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
/* drivers/video/modedb.c */
-#define VESA_MODEDB_SIZE 34
+#define VESA_MODEDB_SIZE 43
extern void fb_var_to_videomode(struct fb_videomode *mode,
const struct fb_var_screeninfo *var);
extern void fb_videomode_to_var(struct fb_var_screeninfo *var,
--
1.8.1.5
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply related
* [PATCH V2 2/3] video: fbdev: Check Standard Timing against DMT
From: David Ung @ 2015-01-14 3:04 UTC (permalink / raw)
To: linux-fbdev
Add the VESA Display Monitor Timing (DMT) table.
During parsing of Standard Timings, it compare the 2 byte STD code
with DMT to see what the VESA mode should be. If there is no entry
in the vesa_modes table or no match found, it fallsback to the
GTF timings.
Signed-off-by: David Ung <davidu@nvidia.com>
---
drivers/video/fbdev/core/fbmon.c | 76 +++++++++++++++++++----------------
drivers/video/fbdev/core/modedb.c | 84 +++++++++++++++++++++++++++++++++++++++
include/linux/fb.h | 10 +++++
3 files changed, 136 insertions(+), 34 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 5b0e313..0f234c1 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -498,44 +498,52 @@ static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
static int get_std_timing(unsigned char *block, struct fb_videomode *mode,
int ver, int rev)
{
- int xres, yres = 0, refresh, ratio, i;
-
- xres = (block[0] + 31) * 8;
- if (xres <= 256)
- return 0;
+ int i;
- ratio = (block[1] & 0xc0) >> 6;
- switch (ratio) {
- case 0:
- /* in EDID 1.3 the meaning of 0 changed to 16:10 (prior 1:1) */
- if (ver < 1 || (ver = 1 && rev < 3))
- yres = xres;
- else
- yres = (xres * 10)/16;
- break;
- case 1:
- yres = (xres * 3)/4;
- break;
- case 2:
- yres = (xres * 4)/5;
- break;
- case 3:
- yres = (xres * 9)/16;
- break;
+ for (i = 0; i < DMT_SIZE; i++) {
+ u32 std_2byte_code = block[0] << 8 | block[1];
+ if (std_2byte_code = dmt_modes[i].std_2byte_code)
+ break;
}
- refresh = (block[1] & 0x3f) + 60;
-
- DPRINTK(" %dx%d@%dHz\n", xres, yres, refresh);
- for (i = 0; i < VESA_MODEDB_SIZE; i++) {
- if (vesa_modes[i].xres = xres &&
- vesa_modes[i].yres = yres &&
- vesa_modes[i].refresh = refresh) {
- *mode = vesa_modes[i];
- mode->flag |= FB_MODE_IS_STANDARD;
- return 1;
+
+ if (i < DMT_SIZE && dmt_modes[i].mode) {
+ /* DMT mode found */
+ *mode = *dmt_modes[i].mode;
+ mode->flag |= FB_MODE_IS_STANDARD;
+ DPRINTK(" DMT id=%d\n", dmt_modes[i].dmt_id);
+
+ } else {
+ int xres, yres = 0, refresh, ratio;
+
+ xres = (block[0] + 31) * 8;
+ if (xres <= 256)
+ return 0;
+
+ ratio = (block[1] & 0xc0) >> 6;
+ switch (ratio) {
+ case 0:
+ /* in EDID 1.3 the meaning of 0 changed to 16:10 (prior 1:1) */
+ if (ver < 1 || (ver = 1 && rev < 3))
+ yres = xres;
+ else
+ yres = (xres * 10)/16;
+ break;
+ case 1:
+ yres = (xres * 3)/4;
+ break;
+ case 2:
+ yres = (xres * 4)/5;
+ break;
+ case 3:
+ yres = (xres * 9)/16;
+ break;
}
+ refresh = (block[1] & 0x3f) + 60;
+ DPRINTK(" %dx%d@%dHz\n", xres, yres, refresh);
+
+ calc_mode_timings(xres, yres, refresh, mode);
}
- calc_mode_timings(xres, yres, refresh, mode);
+
return 1;
}
diff --git a/drivers/video/fbdev/core/modedb.c b/drivers/video/fbdev/core/modedb.c
index 0b57c1df..858a97e 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -497,6 +497,90 @@ const struct fb_videomode vesa_modes[] = {
FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
};
EXPORT_SYMBOL(vesa_modes);
+
+const struct dmt_videomode dmt_modes[DMT_SIZE] = {
+ { 0x01, 0x0000, 0x000000, &vesa_modes[0] },
+ { 0x02, 0x3119, 0x000000, &vesa_modes[1] },
+ { 0x03, 0x0000, 0x000000, &vesa_modes[2] },
+ { 0x04, 0x3140, 0x000000, &vesa_modes[3] },
+ { 0x05, 0x314c, 0x000000, &vesa_modes[4] },
+ { 0x06, 0x314f, 0x000000, &vesa_modes[5] },
+ { 0x07, 0x3159, 0x000000, &vesa_modes[6] },
+ { 0x08, 0x0000, 0x000000, &vesa_modes[7] },
+ { 0x09, 0x4540, 0x000000, &vesa_modes[8] },
+ { 0x0a, 0x454c, 0x000000, &vesa_modes[9] },
+ { 0x0b, 0x454f, 0x000000, &vesa_modes[10] },
+ { 0x0c, 0x4559, 0x000000, &vesa_modes[11] },
+ { 0x0d, 0x0000, 0x000000, 0 },
+ { 0x0e, 0x0000, 0x000000, 0 },
+ { 0x0f, 0x0000, 0x000000, &vesa_modes[12] },
+ { 0x10, 0x6140, 0x000000, &vesa_modes[13] },
+ { 0x11, 0x614a, 0x000000, &vesa_modes[14] },
+ { 0x12, 0x614f, 0x000000, &vesa_modes[15] },
+ { 0x13, 0x6159, 0x000000, &vesa_modes[16] },
+ { 0x14, 0x0000, 0x000000, 0 },
+ { 0x15, 0x714f, 0x000000, &vesa_modes[17] },
+ { 0x16, 0x0000, 0x7f1c21, 0 },
+ { 0x17, 0x0000, 0x7f1c28, 0 },
+ { 0x18, 0x0000, 0x7f1c44, 0 },
+ { 0x19, 0x0000, 0x7f1c62, 0 },
+ { 0x1a, 0x0000, 0x000000, 0 },
+ { 0x1b, 0x0000, 0x8f1821, 0 },
+ { 0x1c, 0x8100, 0x8f1828, 0 },
+ { 0x1d, 0x810f, 0x8f1844, 0 },
+ { 0x1e, 0x8119, 0x8f1862, 0 },
+ { 0x1f, 0x0000, 0x000000, 0 },
+ { 0x20, 0x8140, 0x000000, &vesa_modes[18] },
+ { 0x21, 0x8159, 0x000000, &vesa_modes[19] },
+ { 0x22, 0x0000, 0x000000, 0 },
+ { 0x23, 0x8180, 0x000000, &vesa_modes[20] },
+ { 0x24, 0x818f, 0x000000, &vesa_modes[21] },
+ { 0x25, 0x8199, 0x000000, &vesa_modes[22] },
+ { 0x26, 0x0000, 0x000000, 0 },
+ { 0x27, 0x0000, 0x000000, 0 },
+ { 0x28, 0x0000, 0x000000, 0 },
+ { 0x29, 0x0000, 0x0c2021, 0 },
+ { 0x2a, 0x9040, 0x0c2028, 0 },
+ { 0x2b, 0x904f, 0x0c2044, 0 },
+ { 0x2c, 0x9059, 0x0c2062, 0 },
+ { 0x2d, 0x0000, 0x000000, 0 },
+ { 0x2e, 0x9500, 0xc11821, 0 },
+ { 0x2f, 0x9500, 0xc11828, 0 },
+ { 0x30, 0x950f, 0xc11844, 0 },
+ { 0x31, 0x9519, 0xc11868, 0 },
+ { 0x32, 0x0000, 0x000000, 0 },
+ { 0x33, 0xa940, 0x000000, &vesa_modes[23] },
+ { 0x34, 0xa945, 0x000000, &vesa_modes[24] },
+ { 0x35, 0xa94a, 0x000000, &vesa_modes[25] },
+ { 0x36, 0xa94f, 0x000000, &vesa_modes[26] },
+ { 0x37, 0xa959, 0x000000, &vesa_modes[27] },
+ { 0x38, 0x0000, 0x000000, 0 },
+ { 0x39, 0x0000, 0x0c2821, 0 },
+ { 0x3a, 0xb300, 0x0c2828, 0 },
+ { 0x3b, 0xb30f, 0x0c2844, 0 },
+ { 0x3c, 0xb319, 0x0c2868, 0 },
+ { 0x3d, 0x0000, 0x000000, 0 },
+ { 0x3e, 0xc140, 0x000000, &vesa_modes[28] },
+ { 0x3f, 0xc14f, 0x000000, &vesa_modes[29] },
+ { 0x40, 0x0000, 0x000000, 0 },
+ { 0x41, 0xc940, 0x000000, &vesa_modes[30] },
+ { 0x42, 0xc94f, 0x000000, &vesa_modes[31] },
+ { 0x43, 0x0000, 0x000000, 0 },
+ { 0x44, 0x0000, 0x572821, &vesa_modes[34] },
+ { 0x45, 0xd100, 0x572828, &vesa_modes[35] },
+ { 0x46, 0xd10f, 0x572844, &vesa_modes[36] },
+ { 0x47, 0xd119, 0x572862, &vesa_modes[37] },
+ { 0x48, 0x0000, 0x000000, 0 },
+ { 0x49, 0xd140, 0x000000, &vesa_modes[32] },
+ { 0x4a, 0xd14f, 0x000000, &vesa_modes[33] },
+ { 0x4b, 0x0000, 0x000000, 0 },
+ { 0x4c, 0x0000, 0x1f3821, &vesa_modes[38] },
+ { 0x4d, 0x0000, 0x1f3828, &vesa_modes[39] },
+ { 0x4e, 0x0000, 0x1f3844, &vesa_modes[40] },
+ { 0x4f, 0x0000, 0x1f3862, &vesa_modes[41] },
+ { 0x50, 0x0000, 0x000000, &vesa_modes[42] },
+};
+EXPORT_SYMBOL(dmt_modes);
#endif /* CONFIG_FB_MODE_HELPERS */
/**
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 882dbd1..043f328 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -727,6 +727,8 @@ extern int fb_videomode_from_videomode(const struct videomode *vm,
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 43
+#define DMT_SIZE 0x50
+
extern void fb_var_to_videomode(struct fb_videomode *mode,
const struct fb_var_screeninfo *var);
extern void fb_videomode_to_var(struct fb_var_screeninfo *var,
@@ -777,9 +779,17 @@ struct fb_videomode {
u32 flag;
};
+struct dmt_videomode {
+ u32 dmt_id;
+ u32 std_2byte_code;
+ u32 cvt_3byte_code;
+ const struct fb_videomode *mode;
+};
+
extern const char *fb_mode_option;
extern const struct fb_videomode vesa_modes[];
extern const struct fb_videomode cea_modes[64];
+extern const struct dmt_videomode dmt_modes[];
struct fb_modelist {
struct list_head list;
--
1.8.1.5
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply related
* [PATCH V2 3/3] video: fbdev: Validate mode timing against monspec
From: David Ung @ 2015-01-14 3:04 UTC (permalink / raw)
To: linux-fbdev
fbmon may generate mode timings that are out of spec of the monitor.
eg DELL U2410 has a max clock 170mhz but advertises a resolutions of
1920x1200@60 in its Standard Timings using 2byte code of D1 00.
When this is looked up in the DMT table it gives it a 193mhz clock.
Although the DELL monitor supports 1920x1200@60, it can only run with
reduced timings at 154mhz or DMT id 0x44 which has no STD 2byte code.
This patch checks to see if the mode can be supported by the monitor
by comparing against monspecs.dclkmax.
Signed-off-by: David Ung <davidu@nvidia.com>
---
drivers/video/fbdev/core/fbmon.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 0f234c1..9533859 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -496,7 +496,7 @@ static int get_est_timing(unsigned char *block, struct fb_videomode *mode)
}
static int get_std_timing(unsigned char *block, struct fb_videomode *mode,
- int ver, int rev)
+ int ver, int rev, const struct fb_monspecs *specs)
{
int i;
@@ -544,16 +544,23 @@ static int get_std_timing(unsigned char *block, struct fb_videomode *mode,
calc_mode_timings(xres, yres, refresh, mode);
}
+ /* Check the mode we got is within valid spec of the monitor */
+ if (specs && specs->dclkmax
+ && PICOS2KHZ(mode->pixclock) * 1000 > specs->dclkmax) {
+ DPRINTK(" mode exceed max DCLK\n");
+ return 0;
+ }
+
return 1;
}
-static int get_dst_timing(unsigned char *block,
- struct fb_videomode *mode, int ver, int rev)
+static int get_dst_timing(unsigned char *block, struct fb_videomode *mode,
+ int ver, int rev, const struct fb_monspecs *specs)
{
int j, num = 0;
for (j = 0; j < 6; j++, block += STD_TIMING_DESCRIPTION_SIZE)
- num += get_std_timing(block, &mode[num], ver, rev);
+ num += get_std_timing(block, &mode[num], ver, rev, specs);
return num;
}
@@ -609,7 +616,8 @@ static void get_detailed_timing(unsigned char *block,
* This function builds a mode database using the contents of the EDID
* data
*/
-static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize)
+static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize,
+ const struct fb_monspecs *specs)
{
struct fb_videomode *mode, *m;
unsigned char *block;
@@ -651,12 +659,13 @@ static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize)
DPRINTK(" Standard Timings\n");
block = edid + STD_TIMING_DESCRIPTIONS_START;
for (i = 0; i < STD_TIMING; i++, block += STD_TIMING_DESCRIPTION_SIZE)
- num += get_std_timing(block, &mode[num], ver, rev);
+ num += get_std_timing(block, &mode[num], ver, rev, specs);
block = edid + DETAILED_TIMING_DESCRIPTIONS_START;
for (i = 0; i < 4; i++, block+= DETAILED_TIMING_DESCRIPTION_SIZE) {
if (block[0] = 0x00 && block[1] = 0x00 && block[3] = 0xfa)
- num += get_dst_timing(block + 5, &mode[num], ver, rev);
+ num += get_dst_timing(block + 5, &mode[num],
+ ver, rev, specs);
}
/* Yikes, EDID data is totally useless */
@@ -715,7 +724,7 @@ static int fb_get_monitor_limits(unsigned char *edid, struct fb_monspecs *specs)
int num_modes, hz, hscan, pixclock;
int vtotal, htotal;
- modes = fb_create_modedb(edid, &num_modes);
+ modes = fb_create_modedb(edid, &num_modes, specs);
if (!modes) {
DPRINTK("None Available\n");
return 1;
@@ -972,7 +981,7 @@ void fb_edid_to_monspecs(unsigned char *edid, struct fb_monspecs *specs)
DPRINTK(" Display Characteristics:\n");
get_monspecs(edid, specs);
- specs->modedb = fb_create_modedb(edid, &specs->modedb_len);
+ specs->modedb = fb_create_modedb(edid, &specs->modedb_len, specs);
/*
* Workaround for buggy EDIDs that sets that the first
--
1.8.1.5
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply related
* RE: [patch] fbdev: off by one test (harmless)
From: David Ung @ 2015-01-14 5:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20141226172657.GA14762@mwanda>
> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@ti.com]
> Sent: Tuesday, January 13, 2015 3:19 AM
> To: David Ung; 'Jingoo Han'; 'Dan Carpenter'
> Cc: 'Jean-Christophe Plagniol-Villard'; 'Daniel Vetter'; 'Laurent Pinchart';
> 'Rob Clark'; linux-fbdev@vger.kernel.org; kernel-janitors@vger.kernel.org
> Subject: Re: [patch] fbdev: off by one test (harmless)
>
> * PGP Signed by an unknown key
>
> On 29/12/14 23:51, David Ung wrote:
> >
> >>> test is really a no-op. But it's still off by one and upsets the
> >>> static checkers so we may as well correct it.
> >>
> >> 'idx' should be 0~63, because cea_modes array is defined as
> >> 'cea_modes[64]'.
> >
> > According to CEA/EIA-861E, there are 64 defined modes, but idx is
> > valid for 1-64, 0 is reserved hence the check for
> >
> > If (!idx || idx > 63) {
> >
> > Think idx check really should be !idx || idx > 64 if following
> > CEA/EIA-861E
>
> In that case there's something funny with the code. The code indexes
> 'cea_modes' using 'idx', and I _think_ cea_modes is already offset properly,
> i.e. there's no entry at 0. But its length is 64, which is not right, as there's the
> empty item in the beginning.
>
> So maybe the correct fix is to increase the length of cea_modes to 65, and
> change the idx check as you mention above?
>
In that case might aswell go with CEA/EAI-861F for completeness and have the check against 107.
but with a slight waste of memory.
David
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ 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