* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-12 9:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Noralf,
>>>> just a quick help the dc pin should be a gpio and be set as output pin
>>>> to control D/C ?
>>> Correct.
>>>
>> Thanks!
>>
>> Is there any sample app/library to draw/test this driver?
> I find it easy to just use the framebuffer console for simple testing:
> con2fbmap (or X windows)
> I have also used Geert's fbtest.
>
Thanks.
I got it compiled against my kernel, but not sure how to add it in my board file (My platform
has no DT support). Should it be registered as spi slave device , I tried adding the following,
{
.modalias = "fb_ssd1306",
.irq = -1,
.max_speed_hz = 16000000,
.bus_num = 2,
.chip_select = 0,
.mode = SPI_MODE_0,
},
But nothing came up how do I register ? any quick pointer would be helpful.
Thanks And Regards,
Sagar
^ permalink raw reply
* Re: SSD1306 OLED driver
From: Noralf Tronnes @ 2015-01-12 14:30 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Den 12.01.2015 10:44, skrev Ssagarr Patil:
> I got it compiled against my kernel, but not sure how to add it in my board file (My platform
> has no DT support). Should it be registered as spi slave device , I tried adding the following,
>
> {
> .modalias = "fb_ssd1306",
> .irq = -1,
> .max_speed_hz = 16000000,
> .bus_num = 2,
> .chip_select = 0,
> .mode = SPI_MODE_0,
> },
>
> 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.
^ permalink raw reply
* [PATCH][RESEND] static code analysis from cppcheck reports:
From: Colin King @ 2015-01-12 15:27 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
Cc: linux-kernel
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(-)
diff --git a/drivers/video/fbdev/broadsheetfb.c b/drivers/video/fbdev/broadsheetfb.c
index 1c29bd1..0e5fde1 100644
--- a/drivers/video/fbdev/broadsheetfb.c
+++ b/drivers/video/fbdev/broadsheetfb.c
@@ -636,7 +636,7 @@ static int broadsheet_spiflash_rewrite_sector(struct broadsheetfb_par *par,
err = broadsheet_spiflash_read_range(par, start_sector_addr,
data_start_addr, sector_buffer);
if (err)
- return err;
+ goto out;
}
/* now we copy our data into the right place in the sector buffer */
@@ -657,7 +657,7 @@ static int broadsheet_spiflash_rewrite_sector(struct broadsheetfb_par *par,
err = broadsheet_spiflash_read_range(par, tail_start_addr,
tail_len, sector_buffer + tail_start_addr);
if (err)
- return err;
+ goto out;
}
/* if we got here we have the full sector that we want to rewrite. */
@@ -665,11 +665,13 @@ static int broadsheet_spiflash_rewrite_sector(struct broadsheetfb_par *par,
/* first erase the sector */
err = broadsheet_spiflash_erase_sector(par, start_sector_addr);
if (err)
- return err;
+ goto out;
/* now write it */
err = broadsheet_spiflash_write_sector(par, start_sector_addr,
sector_buffer, sector_size);
+out:
+ kfree(sector_buffer);
return err;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH][RESEND] static code analysis from cppcheck reports:
From: Geert Uytterhoeven @ 2015-01-12 18:02 UTC (permalink / raw)
To: Colin King
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel@vger.kernel.org
In-Reply-To: <1421076472-7101-1-git-send-email-colin.king@canonical.com>
On Mon, Jan 12, 2015 at 4:27 PM, Colin King <colin.king@canonical.com> 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>
So you can make the box go OOM by repeatedly writing to the
loadstore_waveform device attribute file?
Do we want this applied to -stable?
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: [PATCH][RESEND] static code analysis from cppcheck reports:
From: Colin Ian King @ 2015-01-12 18:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Linux Fbdev development list, linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdXXRpFM2VkEz6gGMA5tmXEKt0mpfUMbgM=SPBZgwVg3Eg@mail.gmail.com>
On 12/01/15 18:02, Geert Uytterhoeven wrote:
> On Mon, Jan 12, 2015 at 4:27 PM, Colin King <colin.king@canonical.com> 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>
>
> So you can make the box go OOM by repeatedly writing to the
> loadstore_waveform device attribute file?
..well, not quickly.
> Do we want this applied to -stable?
>
> 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
* [PATCH] fbdev: ssd1307fb: drop unused function ssd1307fb_write_data()
From: Lad, Prabhakar @ 2015-01-12 19:21 UTC (permalink / raw)
To: LFBDEV, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Maxime Ripard
Cc: LKML, Lad, Prabhakar
this patch drops the unused function ssd1307fb_write_data().
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
drivers/video/fbdev/ssd1307fb.c | 17 -----------------
1 file changed, 17 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index a7ecaa6..c891f11 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -122,23 +122,6 @@ static inline int ssd1307fb_write_cmd(struct i2c_client *client, u8 cmd)
return ret;
}
-static inline int ssd1307fb_write_data(struct i2c_client *client, u8 data)
-{
- struct ssd1307fb_array *array;
- int ret;
-
- array = ssd1307fb_alloc_array(1, SSD1307FB_DATA);
- if (!array)
- return -ENOMEM;
-
- array->data[0] = data;
-
- ret = ssd1307fb_write_array(client, array, 1);
- kfree(array);
-
- return ret;
-}
-
static void ssd1307fb_update_display(struct ssd1307fb_par *par)
{
struct ssd1307fb_array *array;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
From: Geert Uytterhoeven @ 2015-01-12 20:10 UTC (permalink / raw)
To: David Airlie, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: dri-devel, linux-fbdev, linux-kernel, Geert Uytterhoeven
commit 765d5b9c2b72f5b9 ("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.
Remove it, also from new drivers.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
v2:
- Split in two (drm and video) patches,
- Fix recently added rockchip.
---
drivers/gpu/drm/exynos/Kconfig | 1 -
drivers/gpu/drm/rockchip/Kconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9e9b7e7992..c072999b7e0345c6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -6,7 +6,6 @@ config DRM_EXYNOS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
select VIDEOMODE_HELPERS
help
Choose this option if you have a Samsung SoC EXYNOS chipset.
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index ca9f085efa922982..8652dad82009e3ce 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -7,7 +7,6 @@ config DRM_ROCKCHIP
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
select VIDEOMODE_HELPERS
help
Choose this option if you have a Rockchip soc chipset.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] video: Drop superfluous "select VT_HW_CONSOLE_BINDING"
From: Geert Uytterhoeven @ 2015-01-12 20:10 UTC (permalink / raw)
To: David Airlie, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: dri-devel, linux-fbdev, linux-kernel, Geert Uytterhoeven
In-Reply-To: <1421093413-26336-1-git-send-email-geert@linux-m68k.org>
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.
--
1.9.1
^ permalink raw reply related
* [PATCH resend] console/dummy: Move screen size selection from CPP to Kconfig
From: Geert Uytterhoeven @ 2015-01-12 20:17 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, linux-kernel, Geert Uytterhoeven
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.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/video/console/Kconfig | 16 ++++++++++------
drivers/video/console/dummycon.c | 5 +----
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index fe1cd0148e139eaa..ba97efc3bf707db8 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -77,18 +77,22 @@ config DUMMY_CONSOLE
config DUMMY_CONSOLE_COLUMNS
int "Initial number of console screen columns"
- depends on PARISC && DUMMY_CONSOLE
- default "160"
+ depends on DUMMY_CONSOLE && !ARM
+ default 160 if PARISC
+ default 80
help
- The default value is 160, which should fit a 1280x1024 monitor.
+ On PA-RISC, the default value is 160, which should fit a 1280x1024
+ monitor.
Select 80 if you use a 640x480 resolution by default.
config DUMMY_CONSOLE_ROWS
int "Initial number of console screen rows"
- depends on PARISC && DUMMY_CONSOLE
- default "64"
+ depends on DUMMY_CONSOLE && !ARM
+ default 64 if PARISC
+ default 25
help
- The default value is 64, which should fit a 1280x1024 monitor.
+ On PA-RISC, the default value is 64, which should fit a 1280x1024
+ monitor.
Select 25 if you use a 640x480 resolution by default.
config FRAMEBUFFER_CONSOLE
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index 40bec8d64b0a4a56..0efc52f11ad003ae 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -20,13 +20,10 @@
#if defined(__arm__)
#define DUMMY_COLUMNS screen_info.orig_video_cols
#define DUMMY_ROWS screen_info.orig_video_lines
-#elif defined(__hppa__)
+#else
/* set by Kconfig. Use 80x25 for 640x480 and 160x64 for 1280x1024 */
#define DUMMY_COLUMNS CONFIG_DUMMY_CONSOLE_COLUMNS
#define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS
-#else
-#define DUMMY_COLUMNS 80
-#define DUMMY_ROWS 25
#endif
static const char *dummycon_startup(void)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] drm: Drop superfluous "select VT_HW_CONSOLE_BINDING"
From: Daniel Vetter @ 2015-01-12 22:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Fbdev development list, Linux Kernel Mailing List,
dri-devel, Tomi Valkeinen, Jean-Christophe Plagniol-Villard
In-Reply-To: <1421093413-26336-1-git-send-email-geert@linux-m68k.org>
On Mon, Jan 12, 2015 at 09:10:12PM +0100, Geert Uytterhoeven wrote:
> commit 765d5b9c2b72f5b9 ("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.
>
> Remove it, also from new drivers.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Merged into my drm misc branch, thanks.
-Daniel
> ---
> v2:
> - Split in two (drm and video) patches,
> - Fix recently added rockchip.
> ---
> drivers/gpu/drm/exynos/Kconfig | 1 -
> drivers/gpu/drm/rockchip/Kconfig | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 7f9f6f9e9b7e7992..c072999b7e0345c6 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -6,7 +6,6 @@ config DRM_EXYNOS
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> select VIDEOMODE_HELPERS
> help
> Choose this option if you have a Samsung SoC EXYNOS chipset.
> diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> index ca9f085efa922982..8652dad82009e3ce 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -7,7 +7,6 @@ config DRM_ROCKCHIP
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> select VIDEOMODE_HELPERS
> help
> Choose this option if you have a Rockchip soc chipset.
> --
> 1.9.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* RE: [PATCH 1/3] video: fbdev: Add additional vesa modes
From: David Ung @ 2015-01-13 7:32 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-1-git-send-email-davidu@nvidia.com>
Any more comments with this patch?
-----------------------------------------------------------------------------------
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
* Re: [PATCH v4 3/3] arm: dts: omap3-gta04: Add handling for tv output
From: Tomi Valkeinen @ 2015-01-13 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1417642402-20538-4-git-send-email-marek@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
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.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] video: fbdev: Check Standard Timing against DMT
From: Tomi Valkeinen @ 2015-01-13 10:35 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-2-git-send-email-davidu@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]
On 05/12/14 21:47, David Ung wrote:
>
>> On 03/12/14 23:49, David Ung wrote:
>>> 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 | 20 ++++++----
>>> drivers/video/fbdev/core/modedb.c | 84
>> +++++++++++++++++++++++++++++++++++++++
>>> include/linux/fb.h | 10 +++++
>>> 3 files changed, 107 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/core/fbmon.c
>>> b/drivers/video/fbdev/core/fbmon.c
>>> index 5b0e313..aa1110a 100644
>>> --- a/drivers/video/fbdev/core/fbmon.c
>>> +++ b/drivers/video/fbdev/core/fbmon.c
>>> @@ -526,16 +526,22 @@ static int get_std_timing(unsigned char *block,
>> struct fb_videomode *mode,
>>> 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];
>>> + 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) {
>>> + if (!dmt_modes[i].mode)
>>> + break;
>>> + *mode = *dmt_modes[i].mode;
>>> mode->flag |= FB_MODE_IS_STANDARD;
>>> - return 1;
>>> + DPRINTK(" DMT id=%d\n",
>> dmt_modes[i].dmt_id);
>>> + break;
>>> }
>>> }
>>> - calc_mode_timings(xres, yres, refresh, mode);
>>> +
>>> + if (i == DMT_SIZE || !dmt_modes[i].mode)
>>> + calc_mode_timings(xres, yres, refresh, mode);
>>> +
>>> return 1;
>>> }
>>
>> I think this could be made a bit cleaner.
>>
>> The xres/yres/refresh calculation in get_std_timing doesn't matter for the
>> DMT code above. So in get_std_timing() you could first do the search for the
>> DMT mode, and if found, return from the function. After that the code
>> would do the GTF calculation.
>>
>
> Yes, I've deleted the xres/yres/refresh calculation.
Sorry it's taken a while for me to respond...
I mean that the whole 'switch (ratio)' and related code in the beginning
of the get_std_timing() are not needed for the DMT loop. All that could
be moved inside the 'if (i == DMT_SIZE || !dmt_modes[i].mode)' block.
Also, in my opinion the code would be more easily understandable with
something like:
for (dmt loop) {
if (std_2byte_code matches)
break;
}
if (i < DMT_SIZE && dmt_modes[i].mode) {
// DMT mode found
} else {
// calculate GTF
}
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] video: fbdev: Validate mode timing against monspec
From: Tomi Valkeinen @ 2015-01-13 10:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1417643369-20603-3-git-send-email-davidu@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
On 23/12/14 02:27, David Ung wrote:
> 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 aa1110a..cc3ea6c8 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, struct fb_monspecs *specs)
Here and in the rest of the functions I believe monspecs is never
supposed to be changed, so it should be marked as const.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: ocfb: Fix data type warning
From: Tomi Valkeinen @ 2015-01-13 10:49 UTC (permalink / raw)
To: Qiang Chen, Stefan Kristiansson
Cc: Jean-Christophe Plagniol-Villard, Jingoo Han, Daniel Vetter,
Laurent Pinchart, linux-fbdev, linux-kernel, Qiang Chen
In-Reply-To: <1417767510-31462-1-git-send-email-qiang2.chen@sonymobile.com>
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
On 05/12/14 10:18, Qiang Chen wrote:
> When allocate framebuffer memory using dma_alloc_coherent(),
> we'd better use dma_addr_t instead of phys_addr_t. Because the
> address we got in fact is DMA or bus address for the platform.
>
> This patch also fixes below build warning:
> drivers/video/fbdev/ocfb.c:335:2:
> warning: passing argument 3 of ‘dma_alloc_attrs’
> from incompatible pointer type [enabled by default]
>
> Signed-off-by: Qiang Chen <qiang2.chen@sonymobile.com>
> ---
> drivers/video/fbdev/ocfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/ocfb.c b/drivers/video/fbdev/ocfb.c
> index 7f9dc9b..de98196 100644
> --- a/drivers/video/fbdev/ocfb.c
> +++ b/drivers/video/fbdev/ocfb.c
> @@ -61,7 +61,7 @@ struct ocfb_dev {
> /* flag indicating whether the regs are little endian accessed */
> int little_endian;
> /* Physical and virtual addresses of framebuffer */
> - phys_addr_t fb_phys;
> + dma_addr_t fb_phys;
> void __iomem *fb_virt;
> u32 pseudo_palette[PALETTE_SIZE];
> };
>
Thanks, queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: vgastate: remove trailing whitespaces
From: Tomi Valkeinen @ 2015-01-13 10:54 UTC (permalink / raw)
To: Asaf Vertz; +Cc: plagnioj, linux-fbdev, linux-kernel
In-Reply-To: <20141211090441.GA9943@ubuntu>
[-- Attachment #1: Type: text/plain, Size: 340 bytes --]
On 11/12/14 11:04, Asaf Vertz wrote:
> Fixed a coding style error, trailing whitespace.
>
> Signed-off-by: Asaf Vertz <asaf.vertz@tandemg.com>
> ---
> drivers/video/vgastate.c | 82 +++++++++++++++++++++++-----------------------
> 1 files changed, 41 insertions(+), 41 deletions(-)
>
Thanks, queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: omap2: dss: rfbi.c: Remove some unused functions
From: Tomi Valkeinen @ 2015-01-13 11:00 UTC (permalink / raw)
To: Rickard Strandqvist, Jean-Christophe Plagniol-Villard
Cc: Jingoo Han, Laurent Pinchart, Rob Clark, linux-omap, linux-fbdev,
linux-kernel
In-Reply-To: <1419181332-9322-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
On 21/12/14 19:02, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> rfbi_init_display() rfbi_display_disable() rfbi_display_enable()
> rfbi_set_interface_timings() rfbi_set_data_lines() rfbi_set_pixel_size()
> rfbi_set_size() rfbi_update() rfbi_configure() rfbi_enable_te()
> rfbi_setup_te() rfbi_write_pixels() rfbi_write_data() rfbi_read_data()
> rfbi_write_command() rfbi_bus_unlock() rfbi_bus_lock()
>
> 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/rfbi.c | 297 ----------------------------------
> 1 file changed, 297 deletions(-)
It's true those functions are not used anywhere, but RFBI is currently
marked as BROKEN so it cannot be compiled and the functions do not do
any harm. I'd rather keep them, as they give an insight how the rfbi
should work if and when someone will fix the driver.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [patch] fbdev: off by one test (harmless)
From: Tomi Valkeinen @ 2015-01-13 11:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20141226172657.GA14762@mwanda>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
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?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* 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
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