* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-10 12:46 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Noralf,
>>>
>>> I am now concerned if the driver was tested in first place ?
>> No. I just submitted some good looking code that never ever got
>> tested.
>>
>> More seriously, There's a few thing that comes to my mind:
>> - Your controller doesn't behave the same way than the ones already
>> supported.
>> - You haven't posted your changes yet, so maybe you're not doing the
>> transfers right
>> - Your SPI controller is doing something weird
>>
>> What happens if you plug a logical analyzer on the bus?
>>
>> Maxime
>>
> Hi,
>
> The major difference between the SSD1306 SPI and I2C interfaces, is that
> SPI uses a D/C pin to signal whether it's data or command coming in.
> Looking at ssd1307fb, this Data/Command info is embedded as the first
> byte in the i2c package/message.
> Without looking up the datasheet, I would guess that this is the only
> difference, the way the D/C bit is handled.
> The rest of the package payload should be the same.
> So:
> dc=0, spi write command
> dc=1, spi write data (optional)
>
I was working on ssd1306 itself.
>
> Apart from that, I have SSD1306 SPI support in a project of mine:
>
> This is the part writing the framebuffer:
> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
> This writes commands (for many controllers):
> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
> This is the SPI specific part:
> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
> Project wiki: https://github.com/notro/fbtft/wiki
>
Thanks for the pointers that was really helpful.
just a quick help the dc pin should be a gpio and be set as output pin
to control D/C ?
in my case for ssd1306 needs to be added as slave device in
board file since I dont have DT.
> The code isn't particularly pretty, it was my first venture into the kernel.
> It has recently been submitted for the staging tree:
> https://github.com/notro/fbtft/issues/161#issuecomment-68431405
>
hope it gets accepted soon.
Thanks,
--Sagar
^ permalink raw reply
* Re: SSD1306 OLED driver
From: Noralf Tronnes @ 2015-01-10 13:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Den 10.01.2015 13:34, skrev Ssagarr Patil:
> Hi Noralf,
>
>>>> I am now concerned if the driver was tested in first place ?
>>> No. I just submitted some good looking code that never ever got
>>> tested.
>>>
>>> More seriously, There's a few thing that comes to my mind:
>>> - Your controller doesn't behave the same way than the ones already
>>> supported.
>>> - You haven't posted your changes yet, so maybe you're not doing the
>>> transfers right
>>> - Your SPI controller is doing something weird
>>>
>>> What happens if you plug a logical analyzer on the bus?
>>>
>>> Maxime
>>>
>> Hi,
>>
>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>> SPI uses a D/C pin to signal whether it's data or command coming in.
>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>> byte in the i2c package/message.
>> Without looking up the datasheet, I would guess that this is the only
>> difference, the way the D/C bit is handled.
>> The rest of the package payload should be the same.
>> So:
>> dc=0, spi write command
>> dc=1, spi write data (optional)
>>
> I was working on ssd1306 itself.
>
>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>
>> This is the part writing the framebuffer:
>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>> This writes commands (for many controllers):
>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>> This is the SPI specific part:
>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>> Project wiki: https://github.com/notro/fbtft/wiki
>>
> Thanks for the pointers that was really helpful.
>
> just a quick help the dc pin should be a gpio and be set as output pin
> to control D/C ?
Correct.
^ permalink raw reply
* Re: [PATCH v4 0/3] omapdss: Add video output support for gta04
From: Belisko Marek @ 2015-01-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1417642402-20538-1-git-send-email-marek@goldelico.com>
Tomi can you please pick up this series for 3.20 release? Thanks
On Wed, Dec 3, 2014 at 10:33 PM, Marek Belisko <marek@goldelico.com> wrote:
> changes from v3:
> - use GPL v2 instead GPL
> - fix wrong gpios property name in doc and DT
> - set gpio to NULL if invalid
> - drop unnecessary header
>
> changes from v2:
> - rename amplifier-opa362.c to encoder-opa362
> - drop inversion handlign from driver
> - add ti,invert-polarity to venc node
>
> I also drop devconf1 handling patches because discussion how to
> properly implement is not yet finished and this part is independent
> from video driver.
>
> changes from v1:
> - fix opa362 compilation error
> - fix opa362 DT documentation
> - move devconf1 definition to omap3.dtsi
> Marek Belisko (3):
> video: omapdss: Add opa362 driver
> Documentation: DT: Add documentation for ti,opa362 bindings
> arm: dts: omap3-gta04: Add handling for tv output
>
> .../devicetree/bindings/video/ti,opa362.txt | 38 +++
> arch/arm/boot/dts/omap3-gta04.dtsi | 49 ++++
> drivers/video/fbdev/omap2/displays-new/Kconfig | 6 +
> drivers/video/fbdev/omap2/displays-new/Makefile | 1 +
> .../fbdev/omap2/displays-new/encoder-opa362.c | 285 +++++++++++++++++++++
> 5 files changed, 379 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/ti,opa362.txt
> create mode 100644 drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
>
> --
> 1.9.1
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* RE: SSD1306 OLED driver
From: Ssagarr Patil @ 2015-01-10 21:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Hi Noralf,
> Date: Sat, 10 Jan 2015 14:50:09 +0100
> From: notro@tronnes.org
> To: hugarsagar@outlook.com
> CC: linux-fbdev@vger.kernel.org
> Subject: Re: SSD1306 OLED driver
>
> Den 10.01.2015 13:34, skrev Ssagarr Patil:
>> Hi Noralf,
>>
>>>>> I am now concerned if the driver was tested in first place ?
>>>> No. I just submitted some good looking code that never ever got
>>>> tested.
>>>>
>>>> More seriously, There's a few thing that comes to my mind:
>>>> - Your controller doesn't behave the same way than the ones already
>>>> supported.
>>>> - You haven't posted your changes yet, so maybe you're not doing the
>>>> transfers right
>>>> - Your SPI controller is doing something weird
>>>>
>>>> What happens if you plug a logical analyzer on the bus?
>>>>
>>>> Maxime
>>>>
>>> Hi,
>>>
>>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>>> SPI uses a D/C pin to signal whether it's data or command coming in.
>>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>>> byte in the i2c package/message.
>>> Without looking up the datasheet, I would guess that this is the only
>>> difference, the way the D/C bit is handled.
>>> The rest of the package payload should be the same.
>>> So:
>>> dc=0, spi write command
>>> dc=1, spi write data (optional)
>>>
>> I was working on ssd1306 itself.
>>
>>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>>
>>> This is the part writing the framebuffer:
>>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>>> This writes commands (for many controllers):
>>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>>> This is the SPI specific part:
>>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>>> Project wiki: https://github.com/notro/fbtft/wiki
>>>
>> Thanks for the pointers that was really helpful.
>>
>> 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?
Thanks,
--Sagar
^ permalink raw reply
* Re: SSD1306 OLED driver
From: Noralf Tronnes @ 2015-01-11 14:20 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
Den 10.01.2015 22:07, skrev Ssagarr Patil:
> Hi Noralf,
>
>> Date: Sat, 10 Jan 2015 14:50:09 +0100
>> From: notro@tronnes.org
>> To: hugarsagar@outlook.com
>> CC: linux-fbdev@vger.kernel.org
>> Subject: Re: SSD1306 OLED driver
>>
>> Den 10.01.2015 13:34, skrev Ssagarr Patil:
>>> Hi Noralf,
>>>
>>>>>> I am now concerned if the driver was tested in first place ?
>>>>> No. I just submitted some good looking code that never ever got
>>>>> tested.
>>>>>
>>>>> More seriously, There's a few thing that comes to my mind:
>>>>> - Your controller doesn't behave the same way than the ones already
>>>>> supported.
>>>>> - You haven't posted your changes yet, so maybe you're not doing the
>>>>> transfers right
>>>>> - Your SPI controller is doing something weird
>>>>>
>>>>> What happens if you plug a logical analyzer on the bus?
>>>>>
>>>>> Maxime
>>>>>
>>>> Hi,
>>>>
>>>> The major difference between the SSD1306 SPI and I2C interfaces, is that
>>>> SPI uses a D/C pin to signal whether it's data or command coming in.
>>>> Looking at ssd1307fb, this Data/Command info is embedded as the first
>>>> byte in the i2c package/message.
>>>> Without looking up the datasheet, I would guess that this is the only
>>>> difference, the way the D/C bit is handled.
>>>> The rest of the package payload should be the same.
>>>> So:
>>>> dc=0, spi write command
>>>> dc=1, spi write data (optional)
>>>>
>>> I was working on ssd1306 itself.
>>>
>>>> Apart from that, I have SSD1306 SPI support in a project of mine:
>>>>
>>>> This is the part writing the framebuffer:
>>>> https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173
>>>> This writes commands (for many controllers):
>>>> https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10
>>>> This is the SPI specific part:
>>>> https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10
>>>> Project wiki: https://github.com/notro/fbtft/wiki
>>>>
>>> Thanks for the pointers that was really helpful.
>>>
>>> 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.
Noralf.
^ permalink raw reply
* [PATCH 3/5] video: atafb: Remove obsolete IRQ_TYPE_PRIO
From: Geert Uytterhoeven @ 2015-01-12 8:40 UTC (permalink / raw)
To: David S. Miller, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Jaroslav Kysela, Takashi Iwai
Cc: linux-m68k, linux-kernel, Geert Uytterhoeven, linux-fbdev
In-Reply-To: <1421052021-12560-1-git-send-email-geert@linux-m68k.org>
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)
--
1.9.1
^ permalink raw reply related
* 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
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