* 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
* [PATCH] fbdev: ssd1307fb: return proper error code if write command fails
From: Lad, Prabhakar @ 2015-01-14 8:24 UTC (permalink / raw)
To: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Maxime Ripard
Cc: LKML, Lad, Prabhakar
this patch fixes ssd1307fb_ssd1306_init() function to return
proper error codes in case of failures.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/fbdev/ssd1307fb.c | 54 ++++++++++++++++++++++++++++++-----------
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index f4daa59..528ea16 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -320,7 +320,9 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
/* Set initial contrast */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
- ret = ret & ssd1307fb_write_cmd(par->client, 0x7f);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0x7f);
if (ret < 0)
return ret;
@@ -336,63 +338,87 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
/* Set multiplex ratio value */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_MULTIPLEX_RATIO);
- ret = ret & ssd1307fb_write_cmd(par->client, par->height - 1);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, par->height - 1);
if (ret < 0)
return ret;
/* set display offset value */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
+ if (ret < 0)
+ return ret;
ret = ssd1307fb_write_cmd(par->client, 0x20);
if (ret < 0)
return ret;
/* Set clock frequency */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_CLOCK_FREQ);
- ret = ret & ssd1307fb_write_cmd(par->client, 0xf0);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0xf0);
if (ret < 0)
return ret;
/* Set precharge period in number of ticks from the internal clock */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PRECHARGE_PERIOD);
- ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0x22);
if (ret < 0)
return ret;
/* Set COM pins configuration */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COM_PINS_CONFIG);
- ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0x22);
if (ret < 0)
return ret;
/* Set VCOMH */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_VCOMH);
- ret = ret & ssd1307fb_write_cmd(par->client, 0x49);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0x49);
if (ret < 0)
return ret;
/* Turn on the DC-DC Charge Pump */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
- ret = ret & ssd1307fb_write_cmd(par->client, 0x14);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0x14);
if (ret < 0)
return ret;
/* Switch to horizontal addressing mode */
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_ADDRESS_MODE);
- ret = ret & ssd1307fb_write_cmd(par->client,
- SSD1307FB_SET_ADDRESS_MODE_HORIZONTAL);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client,
+ SSD1307FB_SET_ADDRESS_MODE_HORIZONTAL);
if (ret < 0)
return ret;
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COL_RANGE);
- ret = ret & ssd1307fb_write_cmd(par->client, 0x0);
- ret = ret & ssd1307fb_write_cmd(par->client, par->width - 1);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0x0);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, par->width - 1);
if (ret < 0)
return ret;
ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PAGE_RANGE);
- ret = ret & ssd1307fb_write_cmd(par->client, 0x0);
- ret = ret & ssd1307fb_write_cmd(par->client,
- par->page_offset + (par->height / 8) - 1);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client, 0x0);
+ if (ret < 0)
+ return ret;
+ ret = ssd1307fb_write_cmd(par->client,
+ par->page_offset + (par->height / 8) - 1);
if (ret < 0)
return ret;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] fbdev: ssd1307fb: return proper error code if write command fails
From: Maxime Ripard @ 2015-01-14 11:07 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen, LKML
In-Reply-To: <1421223889-9448-1-git-send-email-prabhakar.csengg@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
Hi,
Thanks for doing this,
On Wed, Jan 14, 2015 at 08:24:49AM +0000, Lad, Prabhakar wrote:
> this patch fixes ssd1307fb_ssd1306_init() function to return
> proper error codes in case of failures.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> drivers/video/fbdev/ssd1307fb.c | 54 ++++++++++++++++++++++++++++++-----------
> 1 file changed, 40 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index f4daa59..528ea16 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -320,7 +320,9 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
>
> /* Set initial contrast */
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
> - ret = ret & ssd1307fb_write_cmd(par->client, 0x7f);
> + if (ret < 0)
> + return ret;
A newline here (and to all the subsequent changes) would be great.
Thanks!
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-14 13:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Noralf/Geert,
>>>> 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.
> I'm skipping CC'ing the mailinglist as this still is an out-of-tree driver.
>
I have got the driver working!
I am also able to run the fbtest application, but with test10 I do not see 'hello world'
pattern. Am I missing something.
Thanks & Regards,
Sagar
^ permalink raw reply
* [PATCH 3/3] backlight: 88pm860x_bl: Use of_get_child_by_name() instead of refcount hack
From: Geert Uytterhoeven @ 2015-01-14 13:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Bryan Wu, Richard Purdie, Jingoo Han,
Lee Jones
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1421243519-6257-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
of_find_node_by_name() calls of_node_put() on its "from" parameter.
To counter this, pm860x_backlight_dt_init() calls of_node_get() first.
Use of_get_child_by_name() instead to get rid of the refcount hack.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: linux-fbdev@vger.kernel.org
---
Compile-tested only
---
drivers/video/backlight/88pm860x_bl.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/backlight/88pm860x_bl.c b/drivers/video/backlight/88pm860x_bl.c
index 9a23698b6fe8398c..2da5862876d1fe78 100644
--- a/drivers/video/backlight/88pm860x_bl.c
+++ b/drivers/video/backlight/88pm860x_bl.c
@@ -168,10 +168,7 @@ static int pm860x_backlight_dt_init(struct platform_device *pdev,
struct device_node *nproot, *np;
int iset = 0;
- nproot = of_node_get(pdev->dev.parent->of_node);
- if (!nproot)
- return -ENODEV;
- nproot = of_find_node_by_name(nproot, "backlights");
+ nproot = of_get_child_by_name(pdev->dev.parent->of_node, "backlights");
if (!nproot) {
dev_err(&pdev->dev, "failed to find backlights node\n");
return -ENODEV;
--
1.9.1
^ permalink raw reply related
* Re: SSD1306 OLED driver
From: Geert Uytterhoeven @ 2015-01-14 15:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Sagar,
On Wed, Jan 14, 2015 at 2:51 PM, Ssagarr Patil <hugarsagar@outlook.com> wrote:
> I am also able to run the fbtest application, but with test10 I do not see 'hello world'
Good!
> pattern. Am I missing something.
That's because that test requires 16 colors, although these aren't used.
If you change ".numcolors \x16" to ".numcolors = 2" in tests/test010.c,
it should at least draw some text, but the colors may be of as it
failed to install
the 16-color console pallette.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-14 16:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Greet,
>
> On Wed, Jan 14, 2015 at 2:51 PM, Ssagarr Patil <hugarsagar@outlook.com> wrote:
>> I am also able to run the fbtest application, but with test10 I do not see 'hello world'
>
> Good!
>
>> pattern. Am I missing something.
>
> That's because that test requires 16 colors, although these aren't used.
>
> If you change ".numcolors \x16" to ".numcolors = 2" in tests/test010.c,
> it should at least draw some text, but the colors may be of as it
> failed to install
> the 16-color console pallette.
>
Thanks for your response, I did try with setting .numcolors = 2 but it doesnt help
neither I still don’t see 'Hello World' on the oled.
Thanks & Regards,
Sagar
^ 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