linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] [PATCH v2 0/3] v2: s3c-fb panning and vsync support

[Pawel O. <p.o...@sa...>]

Hello,

>this is the second version of my previous patchset, corrected after your feedback (thank you).
[...]
>The series contains:
>
>[PATCH v2 1/3] [ARM] s3c-fb: Corrected defines for framesel1 register.
>[PATCH v2 2/3] [ARM] s3c-fb: Added support for panning the display in both directions.
>[PATCH v2 3/3] [ARM] s3c-fb: Added wait for VSYNC support.

may I ask for comments on this patchset (and possibly the later one)?
Is it suitable for merging? What could I do for it to be merged?

Thank you and best regards,
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center

Re: [Linux-fbdev-devel] [PATCH] video/omap: adding __init/__exit macros to various drivers

[Imre D. <imr...@no...>]

On Tue, Sep 29, 2009 at 03:18:06AM +0200, ext Peter Huewe wrote:
> From: Peter Huewe <pet...@gm...>
> 
> Trivial patch which adds the __init/__exit macros to the module_init/
> module_exit functions of the following drivers in media/omap:
> drivers/video/omap/lcd_ams_delta.c
> drivers/video/omap/lcd_mipid.c
> 
> Please have a look at the small patch and either pull it through
> your tree, or please ack' it so Jiri can pull it through the trivial tree.
> 
> linux version v2.6.32-rc1 - linus git tree, Di 29. Sep 01:10:18 CEST 2009
> 
> Signed-off-by: Peter Huewe <pet...@gm...>

Acked-by: Imre Deak <imr...@no...>

> ---
> diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
> index 1f74399..319a9a2 100644
> --- a/drivers/video/omap/lcd_ams_delta.c
> +++ b/drivers/video/omap/lcd_ams_delta.c
> @@ -123,12 +123,12 @@ struct platform_driver ams_delta_panel_driver = {
>  	},
>  };
>  
> -static int ams_delta_panel_drv_init(void)
> +static int __init ams_delta_panel_drv_init(void)
>  {
>  	return platform_driver_register(&ams_delta_panel_driver);
>  }
>  
> -static void ams_delta_panel_drv_cleanup(void)
> +static void __exit ams_delta_panel_drv_cleanup(void)
>  {
>  	platform_driver_unregister(&ams_delta_panel_driver);
>  }
> diff --git a/drivers/video/omap/lcd_mipid.c b/drivers/video/omap/lcd_mipid.c
> index 918ee89..d88a792 100644
> --- a/drivers/video/omap/lcd_mipid.c
> +++ b/drivers/video/omap/lcd_mipid.c
> @@ -607,7 +607,7 @@ static struct spi_driver mipid_spi_driver = {
>  	.remove	= __devexit_p(mipid_spi_remove),
>  };
>  
> -static int mipid_drv_init(void)
> +static int __init mipid_drv_init(void)
>  {
>  	spi_register_driver(&mipid_spi_driver);
>  
> @@ -615,7 +615,7 @@ static int mipid_drv_init(void)
>  }
>  module_init(mipid_drv_init);
>  
> -static void mipid_drv_cleanup(void)
> +static void __exit mipid_drv_cleanup(void)
>  {
>  	spi_unregister_driver(&mipid_spi_driver);
>  }

[Linux-fbdev-devel] [PATCH] video/omap: adding __init/__exit macros to various drivers

[Peter H. <Pet...@gm...>]

From: Peter Huewe <pet...@gm...>

Trivial patch which adds the __init/__exit macros to the module_init/
module_exit functions of the following drivers in media/omap:
drivers/video/omap/lcd_ams_delta.c
drivers/video/omap/lcd_mipid.c

Please have a look at the small patch and either pull it through
your tree, or please ack' it so Jiri can pull it through the trivial tree.

linux version v2.6.32-rc1 - linus git tree, Di 29. Sep 01:10:18 CEST 2009

Signed-off-by: Peter Huewe <pet...@gm...>
---
diff --git a/drivers/video/omap/lcd_ams_delta.c b/drivers/video/omap/lcd_ams_delta.c
index 1f74399..319a9a2 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -123,12 +123,12 @@ struct platform_driver ams_delta_panel_driver = {
 	},
 };
 
-static int ams_delta_panel_drv_init(void)
+static int __init ams_delta_panel_drv_init(void)
 {
 	return platform_driver_register(&ams_delta_panel_driver);
 }
 
-static void ams_delta_panel_drv_cleanup(void)
+static void __exit ams_delta_panel_drv_cleanup(void)
 {
 	platform_driver_unregister(&ams_delta_panel_driver);
 }
diff --git a/drivers/video/omap/lcd_mipid.c b/drivers/video/omap/lcd_mipid.c
index 918ee89..d88a792 100644
--- a/drivers/video/omap/lcd_mipid.c
+++ b/drivers/video/omap/lcd_mipid.c
@@ -607,7 +607,7 @@ static struct spi_driver mipid_spi_driver = {
 	.remove	= __devexit_p(mipid_spi_remove),
 };
 
-static int mipid_drv_init(void)
+static int __init mipid_drv_init(void)
 {
 	spi_register_driver(&mipid_spi_driver);
 
@@ -615,7 +615,7 @@ static int mipid_drv_init(void)
 }
 module_init(mipid_drv_init);
 
-static void mipid_drv_cleanup(void)
+static void __exit mipid_drv_cleanup(void)
 {
 	spi_unregister_driver(&mipid_spi_driver);
 }

[Linux-fbdev-devel] [PATCH 3/5] fbdev: remove duplicated #include

[Huang W. <wei...@gm...>]

Remove duplicated #include('s) in
  drivers/video/msm/mddi.c

Signed-off-by: Huang Weiyi <wei...@gm...>
---
 drivers/video/msm/mddi.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/video/msm/mddi.c b/drivers/video/msm/mddi.c
index f2de5a1..b520f10 100644
--- a/drivers/video/msm/mddi.c
+++ b/drivers/video/msm/mddi.c
@@ -27,7 +27,6 @@
 #include <mach/msm_iomap.h>
 #include <mach/irqs.h>
 #include <mach/board.h>
-#include <linux/delay.h>
 
 #include <mach/msm_fb.h>
 #include "mddi_hw.h"
-- 
1.6.1.3

Re: [Linux-fbdev-devel] [PATCH] video: includecheck fix: msm, mddi.c

[Pavel M. <pa...@uc...>]

On Thu 2009-09-24 16:44:32, Jaswinder Singh Rajput wrote:
> 
> fix the following 'make includecheck' warning:
> 
>   drivers/video/msm/mddi.c: linux/delay.h is included more than once.
> 
> Signed-off-by: Jaswinder Singh Rajput <jas...@gm...>

Acked-by: Pavel Machek <pa...@uc...>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Linux-fbdev-devel] [PATCH v2] fbdev: bfin-lq035q1-fb: new Blackfin Landscape LCD EZ-Extender driver

[Mike F. <vap...@gm...>]

On Fri, Sep 25, 2009 at 16:24, Mike Frysinger wrote:
> On Thu, Sep 24, 2009 at 19:32, Andrew Morton wrote:
>> On Thu, 17 Sep 2009 17:37:06 -0400 Mike Frysinger wrote:
>>> +static int lq035q1_control(unsigned char reg, unsigned short value)
>>> +{
>>> +     int ret;
>>> +     u8 regs[3] = {LQ035_INDEX, 0, 0};
>>> +     u8 dat[3] = {LQ035_DATA, 0, 0};
>>> +
>>> +     if (spi_control.spidev) {
>>> +             regs[2] = reg;
>>> +             dat[1] = value >> 8;
>>> +             dat[2] = value & 0xFF;
>>> +
>>> +             ret = spi_write(spi_control.spidev, regs, ARRAY_SIZE(regs));
>>> +             ret |= spi_write(spi_control.spidev, dat, ARRAY_SIZE(dat));
>>> +     } else
>>> +             return -ENODEV;
>>> +
>>> +     return ret;
>>> +}
>>
>> I am suspecting that this function (and the similar ones below) rely
>> upon state within the hardware and will hence misbehave if two
>> instances are run concurrently.
>>
>> Is that correct>  If so, is there locking to prevent this from occurring?
>
> if by "instances" you mean "users" as in "multiple programs
> reading/writing the framebuffer concurrently", then probably.  rather
> than handle the locking ourselves, it can be pushed to the SPI bus by
> having the regs/dat be transfers in a single message.

hmm there shouldnt be any locking problems here actually.  the spi
access is only to initialize/shutdown, and there is a dedicated CS for
each device.  so i dont think anything here really needs changing
(other than to allocate the spi_control global variable dynamically in
the probe).
-mike

Re: [Linux-fbdev-devel] [PATCH v2] fbdev: bfin-lq035q1-fb: new Blackfin Landscape LCD EZ-Extender driver

[Mike F. <vap...@gm...>]

On Thu, Sep 24, 2009 at 19:32, Andrew Morton wrote:
> On Thu, 17 Sep 2009 17:37:06 -0400 Mike Frysinger wrote:
>> +config FB_BFIN_LQ035Q1
>> +     tristate "SHARP LQ035Q1DH02 TFT LCD"
>> +     depends on FB && BLACKFIN
>> +     select FB_CFB_FILLRECT
>> +     select FB_CFB_COPYAREA
>> +     select FB_CFB_IMAGEBLIT
>> +     select BFIN_GPTIMERS
>> +     select SPI
>
> Are we sure about the `select SPI'?  There's only one other place in
> the kernel which does this, and `select' often makes things explode.  I
> fear that you're either selecting the wrong thing or you're selecting
> something which won't work well.

is it there on purpose and is it not just a mistaken typo ?  yes.  do
we really need it and will we cry if it changes to a "depends" ?  no.

it's just confusing to have a device driver disappear if SPI is
disabled, but considering SPI is enabled by default now, it's not a
big deal.

>> +#define DRIVER_NAME "bfin-lq035q1"
>> +static char driver_name[] = DRIVER_NAME;
>
> Will the compielr magically put this string into read-only storage for
> us, or should we do that manually with `const'?

is this question a rhetorical one ?  oh no, infinite loop ...

i'll fix it up in v3

>> +static int lq035q1_control(unsigned char reg, unsigned short value)
>> +{
>> +     int ret;
>> +     u8 regs[3] = {LQ035_INDEX, 0, 0};
>> +     u8 dat[3] = {LQ035_DATA, 0, 0};
>> +
>> +     if (spi_control.spidev) {
>> +             regs[2] = reg;
>> +             dat[1] = value >> 8;
>> +             dat[2] = value & 0xFF;
>> +
>> +             ret = spi_write(spi_control.spidev, regs, ARRAY_SIZE(regs));
>> +             ret |= spi_write(spi_control.spidev, dat, ARRAY_SIZE(dat));
>> +     } else
>> +             return -ENODEV;
>> +
>> +     return ret;
>> +}
>
> I am suspecting that this function (and the similar ones below) rely
> upon state within the hardware and will hence misbehave if two
> instances are run concurrently.
>
> Is that correct>  If so, is there locking to prevent this from occurring?

if by "instances" you mean "users" as in "multiple programs
reading/writing the framebuffer concurrently", then probably.  rather
than handle the locking ourselves, it can be pushed to the SPI bus by
having the regs/dat be transfers in a single message.
-mike

Re: [Linux-fbdev-devel] [APPLIED] [PATCH] omapfb: Reorder Register_framebuffer call

[Florian T. S. <Flo...@gm...>]

Jan Blunck schrieb:
> On Tue, Sep 22, 2009 at 6:57 PM, Aguirre Rodriguez, Sergio Alberto
> <saa...@ti...> wrote:
>> From: Tony Lindgren [to...@at...]
>> Sent: Tuesday, September 22, 2009 11:28 AM
>>> * Jan Blunck <jb...@in...> [090922 07:59]:
>>>> On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren <to...@at...> wrote:
>>>>> This patch has been applied to the linux-omap
>>>>> by youw fwiendly patch wobot.
>>>>>
>>>>> Branch in linux-omap: omap-fixes
>>>>>
>>>>> Initial commit ID (Likely to change): 9aef1066fb5ca8506068eaab1c552ecca4c85475
>>>>>
>>>>> PatchWorks
>>>>> http://patchwork.kernel.org/patch/47089/
>>>>>
>>> Added back the original Cc's that were dropped from the linux-omap
>>> commit message.
>>>
>>>> Is it actually safe to do this? The framebuffer can be used directly
>>>> after it is registered. In this case it would mean it is used before
>>>> it is even fully initialized (set_fb_var(), set_fb_fix(), ... are
>>>> being called).
>>> Good point, dropping the patch.
>> Hmm, ok. I guess i'll rework this patch considering that..
>>
>> I ran some framebuffer tests with this patch applied, and they worked fine for me.
>>
>> The only thing is that i didn't saw Tux on bootup...
>>
>> Actually, nobody ever gave this kind of feedback, which was the initial idea.
>>
> 
> Sorry, I didn't look into it earlier.
> 
> BTW, I actually wonder if it's really necessary to initialize the
> mutex in register_framebuffer() or why it couldn't be done during
> allocation.

This small discussion between Linus and Krzysztof might explain it:
http://marc.info/?l=linux-kernel&m=124703449332064&w=2
or to summarize:
It is done the way it is done to keep drivers working that use 
statically declared fb_info.

Although I agree, that it would be cleaner the other way around.


Regards,

Florian Tobias Schandinat

[Linux-fbdev-devel] [PATCH 1/2] fb: change rules for global rules match.

[Dave A. <ai...@gm...>]

From: Dave Airlie <ai...@li...>

Having a : should be enough 'fb:' isn't really useful
if the fb wants to a kms output ID.

Changed to use strchr as per feedback from Geert.

Signed-off-by: Dave Airlie <ai...@re...>
---
 drivers/video/fbmem.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index a85c818..750c71f 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1789,7 +1789,7 @@ static int __init video_setup(char *options)
  		global = 1;
  	}
 
- 	if (!global && !strstr(options, "fb:")) {
+ 	if (!global && !strchr(options, ':')) {
  		fb_mode_option = options;
  		global = 1;
  	}
-- 
1.6.4.2

Re: [Linux-fbdev-devel] [PATCH v2] fbdev: bfin-lq035q1-fb: new Blackfin Landscape LCD EZ-Extender driver

[Andrew M. <ak...@li...>]

On Thu, 17 Sep 2009 17:37:06 -0400
Mike Frysinger <va...@ge...> wrote:

> From: Michael Hennerich <mic...@an...>
> 
> Framebuffer driver for the Landscape LCD EZ-Extender (ADZS-BFLLCD-EZEXT)
> http://docs.blackfin.uclinux.org/doku.php?id=hw:cards:landscape_lcd_ez-extender
> 
> Signed-off-by: Michael Hennerich <mic...@an...>
> Signed-off-by: Bryan Wu <coo...@ke...>
> Signed-off-by: Mike Frysinger <va...@ge...>
>
> ...
>
> +config FB_BFIN_LQ035Q1
> +	tristate "SHARP LQ035Q1DH02 TFT LCD"
> +	depends on FB && BLACKFIN
> +	select FB_CFB_FILLRECT
> +	select FB_CFB_COPYAREA
> +	select FB_CFB_IMAGEBLIT
> +	select BFIN_GPTIMERS
> +	select SPI

Are we sure about the `select SPI'?  There's only one other place in
the kernel which does this, and `select' often makes things explode.  I
fear that you're either selecting the wrong thing or you're selecting
something which won't work well.

> +	help
> +	  This is the framebuffer device driver for a SHARP LQ035Q1DH02 TFT display found on
> +	  the Blackfin Landscape LCD EZ-Extender Card.
> +	  This display is a QVGA 320x240 18-bit RGB display interfaced by an 16-bit wide PPI
> +	  It uses PPI[0..15] PPI_FS1, PPI_FS2 and PPI_CLK.
>  
>
> ...
>
> +
> +#define DRIVER_NAME "bfin-lq035q1"
> +static char driver_name[] = DRIVER_NAME;

Will the compielr magically put this string into read-only storage for
us, or should we do that manually with `const'?

>
> ...
>
> +static int lq035q1_control(unsigned char reg, unsigned short value)
> +{
> +	int ret;
> +	u8 regs[3] = {LQ035_INDEX, 0, 0};
> +	u8 dat[3] = {LQ035_DATA, 0, 0};
> +
> +	if (spi_control.spidev) {
> +		regs[2] = reg;
> +		dat[1] = value >> 8;
> +		dat[2] = value & 0xFF;
> +
> +		ret = spi_write(spi_control.spidev, regs, ARRAY_SIZE(regs));
> +		ret |= spi_write(spi_control.spidev, dat, ARRAY_SIZE(dat));
> +	} else
> +		return -ENODEV;
> +
> +	return ret;
> +}

I am suspecting that this function (and the similar ones below) rely
upon state within the hardware and will hence misbehave if two
instances are run concurrently.

Is that correct>  If so, is there locking to prevent this from occurring?

>
> ...
>

[Linux-fbdev-devel] [PATCH] video: includecheck fix: msm, mddi.c

[Jaswinder S. R. <jas...@ke...>]

fix the following 'make includecheck' warning:

  drivers/video/msm/mddi.c: linux/delay.h is included more than once.

Signed-off-by: Jaswinder Singh Rajput <jas...@gm...>
Cc: Pavel Machek <pa...@uc...>
Cc: Brian Swetland <swe...@go...>
Cc: Krzysztof Helt <krz...@po...>
Cc: Rebecca Schultz Zavin <re...@an...>
Cc: Dima Zavin <di...@an...>
Cc: Andrew Morton <ak...@li...>
---
 drivers/video/msm/mddi.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/video/msm/mddi.c b/drivers/video/msm/mddi.c
index f2de5a1..5c5a1ad 100644
--- a/drivers/video/msm/mddi.c
+++ b/drivers/video/msm/mddi.c
@@ -27,8 +27,6 @@
 #include <mach/msm_iomap.h>
 #include <mach/irqs.h>
 #include <mach/board.h>
-#include <linux/delay.h>
-
 #include <mach/msm_fb.h>
 #include "mddi_hw.h"
 
-- 
1.6.0.6

[Linux-fbdev-devel] [PATCH] video: includecheck fix: da8xx-fb.c

[Jaswinder S. R. <jas...@ke...>]

fix the following 'make includecheck' warning:

  drivers/video/da8xx-fb.c: linux/device.h is included more than once.

Signed-off-by: Jaswinder Singh Rajput <jas...@gm...>
Cc: Kevin Hilman <kh...@de...>
Cc: Krzysztof Helt <krz...@wp...>
Cc: Pavel Kiryukhin <pki...@ru...>
Cc: Steve Chen <sc...@mv...>
Cc: Sudhakar Rajashekhara <sud...@ti...>
Cc: Andrew Morton <ak...@li...>
---
 drivers/video/da8xx-fb.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 42e1005..d065894 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -26,7 +26,6 @@
 #include <linux/device.h>
 #include <linux/platform_device.h>
 #include <linux/uaccess.h>
-#include <linux/device.h>
 #include <linux/interrupt.h>
 #include <linux/clk.h>
 #include <video/da8xx-fb.h>
-- 
1.6.0.6

Re: [Linux-fbdev-devel] [APPLIED] [PATCH] omapfb: Reorder Register_framebuffer call

[Jan B. <jb...@in...>]

On Tue, Sep 22, 2009 at 6:57 PM, Aguirre Rodriguez, Sergio Alberto
<saa...@ti...> wrote:
> From: Tony Lindgren [to...@at...]
> Sent: Tuesday, September 22, 2009 11:28 AM
>> * Jan Blunck <jb...@in...> [090922 07:59]:
>> > On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren <to...@at...> wrote:
>> > > This patch has been applied to the linux-omap
>> > > by youw fwiendly patch wobot.
>> > >
>> > > Branch in linux-omap: omap-fixes
>> > >
>> > > Initial commit ID (Likely to change): 9aef1066fb5ca8506068eaab1c552ecca4c85475
>> > >
>> > > PatchWorks
>> > > http://patchwork.kernel.org/patch/47089/
>> > >
>> >
>>
>> Added back the original Cc's that were dropped from the linux-omap
>> commit message.
>>
>> > Is it actually safe to do this? The framebuffer can be used directly
>> > after it is registered. In this case it would mean it is used before
>> > it is even fully initialized (set_fb_var(), set_fb_fix(), ... are
>> > being called).
>>
>> Good point, dropping the patch.
>
> Hmm, ok. I guess i'll rework this patch considering that..
>
> I ran some framebuffer tests with this patch applied, and they worked fine for me.
>
> The only thing is that i didn't saw Tux on bootup...
>
> Actually, nobody ever gave this kind of feedback, which was the initial idea.
>

Sorry, I didn't look into it earlier.

BTW, I actually wonder if it's really necessary to initialize the
mutex in register_framebuffer() or why it couldn't be done during
allocation.

Cheers,
Jan

[Linux-fbdev-devel] How to test overlay functionalities

[Sedji G. <sed...@at...>]

Hi,

I am currently writing a driver for a LCD controller that has overlay 
layers.
My concern is that I would like to know how can I test such 
functionalities? For instance is mplayer able to handle overlay layers?
I can see in the kernel 2.6.30 that the pxa handles overlay layers, so 
there should be a way to use/test these layers.

Regards,
Sedji

Re: [Linux-fbdev-devel] OMAP2/3 Display Subsystem merging

[Andrew M. <ak...@li...>]

On Wed, 23 Sep 2009 10:04:09 +0300 Tomi Valkeinen <tom...@no...> wrote:

> Hi,
> 
> How can we proceed with the OMAP DSS2 merging? I can take the old omapfb
> patches you have to my tree, and give that tree to you as one set, or I
> can base the DSS2 on top of your tree. If that's ok, where can I find
> the patches or your tree?

Wait for -rc1 (or tomorrow's mainline, probably), redo and retest the
patches, send them out for review and integration.

[Linux-fbdev-devel] OMAP2/3 Display Subsystem merging

[Tomi V. <tom...@no...>]

Hi,

How can we proceed with the OMAP DSS2 merging? I can take the old omapfb
patches you have to my tree, and give that tree to you as one set, or I
can base the DSS2 on top of your tree. If that's ok, where can I find
the patches or your tree?

 Tomi

Re: [Linux-fbdev-devel] [PATCH 1/2] fb: change rules for global rules match.

[Geert U. <ge...@li...>]

On Wed, Sep 23, 2009 at 06:42, Dave Airlie <ai...@gm...> wrote:
> From: Dave Airlie <ai...@li...>
>
> Having a : should be enough 'fb:' isn't really useful
> if the fb wants to a kms output ID.
>
> Andrew: I can push this via the drm tree if no objections, as
> I have a kms patch that requires it.
>
> Signed-off-by: Dave Airlie <ai...@re...>
> ---
>  drivers/video/fbmem.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index a85c818..41a6162 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1789,7 +1789,7 @@ static int __init video_setup(char *options)
>                global = 1;
>        }
>
> -       if (!global && !strstr(options, "fb:")) {
> +       if (!global && !strstr(options, ":")) {
>                fb_mode_option = options;
>                global = 1;
>        }

Please don't use strstr() with single-character needle parameter strings.
Use strchr() instead.

Gcc may change such a strstr() to strchr() behind our back, causing
linking errors
on platforms that only provide an inline version of strchr().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

Re: [Linux-fbdev-devel] [GIT PULL]: OMAP2/3 Display Subsystem

[Tomi V. <tom...@no...>]

On Tue, 2009-09-22 at 22:03 +0200, ext Andrew Morton wrote:
> On Tue, 22 Sep 2009 15:29:48 +0300
> Tomi Valkeinen <tom...@no...> wrote:
> 
> > Linus,
> > 
> > Here's the new display subsystem and framebuffer driver for OMAP2/3.
> > 
> > The driver has been reviewed on linux-omap and linux-fbdev-devel, and is in
> > use, for example, on N900, Beagle Board and Overo boards. We have an ACK for
> > the OMAP parts from Tony Lindgren, who maintains the OMAP platform.
> > 
> > We have gotten positive feedback about the driver, for example in this thread:
> > http://marc.info/?l=linux-kernel&m=125171081901820&w=2
> > 
> > The driver is actively maintained and developed further, and I have already a
> > bunch of patches on top of these patches, but I would like to get the big core
> > driver merged first. After the driver is merged, other people can send patches
> > to LCD drivers and board files to enable the new display subsystem on their
> > boards.
> > 
> > Andrew said 2-3 weeks ago that he'll merge the driver (after he has looked
> > through it), but he hasn't responded since then. I'm guessing he's quite busy.
> 
> That's because it came very late and conflicts considerably with
> changes which are already pending.
> 
> > Please pull the new OMAP2/3 display subsystem driver from:
> > 
> >   git://gitorious.org/linux-omap-dss2/linux.git for-linus
> > 
> 
> Confused.  These conflicts heavily with the changes which I've already
> queued, does it not?  Ones which were queued way earlier than this
> material.
> 
> If so, why on earth did you send a pull request, knowing that it would
> trash my tree?

Ah, my mistake. I'm new to getting patches merged and the process
involved. Somehow I thought the patches you have went already in, and as
I didn't get any replies for couple of week, I pursued another route.
Sorry about the confusion.

Let's continue this with less audience, no need to bother everyone with
this.

 Tomi

[Linux-fbdev-devel] [PATCH 1/2] fb: change rules for global rules match.

[Dave A. <ai...@gm...>]

From: Dave Airlie <ai...@li...>

Having a : should be enough 'fb:' isn't really useful
if the fb wants to a kms output ID.

Andrew: I can push this via the drm tree if no objections, as
I have a kms patch that requires it.

Signed-off-by: Dave Airlie <ai...@re...>
---
 drivers/video/fbmem.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index a85c818..41a6162 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1789,7 +1789,7 @@ static int __init video_setup(char *options)
  		global = 1;
  	}
 
- 	if (!global && !strstr(options, "fb:")) {
+ 	if (!global && !strstr(options, ":")) {
  		fb_mode_option = options;
  		global = 1;
  	}
-- 
1.6.4.4

Re: [Linux-fbdev-devel] [GIT PULL]: OMAP2/3 Display Subsystem

[Andrew M. <ak...@li...>]

On Tue, 22 Sep 2009 15:29:48 +0300
Tomi Valkeinen <tom...@no...> wrote:

> Linus,
> 
> Here's the new display subsystem and framebuffer driver for OMAP2/3.
> 
> The driver has been reviewed on linux-omap and linux-fbdev-devel, and is in
> use, for example, on N900, Beagle Board and Overo boards. We have an ACK for
> the OMAP parts from Tony Lindgren, who maintains the OMAP platform.
> 
> We have gotten positive feedback about the driver, for example in this thread:
> http://marc.info/?l=linux-kernel&m=125171081901820&w=2
> 
> The driver is actively maintained and developed further, and I have already a
> bunch of patches on top of these patches, but I would like to get the big core
> driver merged first. After the driver is merged, other people can send patches
> to LCD drivers and board files to enable the new display subsystem on their
> boards.
> 
> Andrew said 2-3 weeks ago that he'll merge the driver (after he has looked
> through it), but he hasn't responded since then. I'm guessing he's quite busy.

That's because it came very late and conflicts considerably with
changes which are already pending.

> Please pull the new OMAP2/3 display subsystem driver from:
> 
>   git://gitorious.org/linux-omap-dss2/linux.git for-linus
> 

Confused.  These conflicts heavily with the changes which I've already
queued, does it not?  Ones which were queued way earlier than this
material.

If so, why on earth did you send a pull request, knowing that it would
trash my tree?

Re: [Linux-fbdev-devel] [APPLIED] [PATCH] omapfb: Reorder Register_framebuffer call

[Aguirre R. S. A. <saa...@ti...>]

From: Tony Lindgren [to...@at...]
Sent: Tuesday, September 22, 2009 11:28 AM
> * Jan Blunck <jb...@in...> [090922 07:59]:
> > On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren <to...@at...> wrote:
> > > This patch has been applied to the linux-omap
> > > by youw fwiendly patch wobot.
> > >
> > > Branch in linux-omap: omap-fixes
> > >
> > > Initial commit ID (Likely to change): 9aef1066fb5ca8506068eaab1c552ecca4c85475
> > >
> > > PatchWorks
> > > http://patchwork.kernel.org/patch/47089/
> > >
> >
> 
> Added back the original Cc's that were dropped from the linux-omap
> commit message.
> 
> > Is it actually safe to do this? The framebuffer can be used directly
> > after it is registered. In this case it would mean it is used before
> > it is even fully initialized (set_fb_var(), set_fb_fix(), ... are
> > being called).
> 
> Good point, dropping the patch.

Hmm, ok. I guess i'll rework this patch considering that..

I ran some framebuffer tests with this patch applied, and they worked fine for me.

The only thing is that i didn't saw Tux on bootup...

Actually, nobody ever gave this kind of feedback, which was the initial idea.

Just people worried about booting properly.

Anyways, thanks for your time! I appreciate it.

Regards,
Sergio
> 
> Also, let's let Tomi Valkeinen deal with queueing up the omap fb code.
> I can then merge Tomi's branck into linux-omap master branch as needed.
> 
> Regards,
> 
> Tony
> 
> 

Re: [Linux-fbdev-devel] [APPLIED] [PATCH] omapfb: Reorder Register_framebuffer call

[Tony L. <to...@at...>]

* Jan Blunck <jb...@in...> [090922 07:59]:
> On Tue, Sep 22, 2009 at 3:31 AM, Tony Lindgren <to...@at...> wrote:
> > This patch has been applied to the linux-omap
> > by youw fwiendly patch wobot.
> >
> > Branch in linux-omap: omap-fixes
> >
> > Initial commit ID (Likely to change): 9aef1066fb5ca8506068eaab1c552ecca4c85475
> >
> > PatchWorks
> > http://patchwork.kernel.org/patch/47089/
> >
> 

Added back the original Cc's that were dropped from the linux-omap
commit message.

> Is it actually safe to do this? The framebuffer can be used directly
> after it is registered. In this case it would mean it is used before
> it is even fully initialized (set_fb_var(), set_fb_fix(), ... are
> being called).

Good point, dropping the patch.

Also, let's let Tomi Valkeinen deal with queueing up the omap fb code.
I can then merge Tomi's branck into linux-omap master branch as needed.

Regards,

Tony

Re: [Linux-fbdev-devel] [GIT PULL]: OMAP2/3 Display Subsystem

[Tony L. <to...@at...>]

* Artem Bityutskiy <ded...@gm...> [090922 05:36]:
> On 09/22/2009 03:29 PM, Tomi Valkeinen wrote:
>> Linus,
>>
>> Here's the new display subsystem and framebuffer driver for OMAP2/3.
>>
>> The driver has been reviewed on linux-omap and linux-fbdev-devel, and is in
>> use, for example, on N900, Beagle Board and Overo boards. We have an ACK for
>> the OMAP parts from Tony Lindgren, who maintains the OMAP platform.
>>
>> We have gotten positive feedback about the driver, for example in this thread:
>> http://marc.info/?l=linux-kernel&m=125171081901820&w=2
>>
>> The driver is actively maintained and developed further, and I have already a
>> bunch of patches on top of these patches, but I would like to get the big core
>> driver merged first. After the driver is merged, other people can send patches
>> to LCD drivers and board files to enable the new display subsystem on their
>> boards.
>>
>> Andrew said 2-3 weeks ago that he'll merge the driver (after he has looked
>> through it), but he hasn't responded since then. I'm guessing he's quite busy.

I guess that was because there were some merge conflicts at that point, but
those are sorted out now.

> Just in case it matters, here is my redundant confirmation that we are
> successfully using this piece of software for about a year.

Ack, it would be nice to get this merged.

Regards,

Tony

[Linux-fbdev-devel] [GIT PULL]: OMAP2/3 Display Subsystem

[Tomi V. <tom...@no...>]

Linus,

Here's the new display subsystem and framebuffer driver for OMAP2/3.

The driver has been reviewed on linux-omap and linux-fbdev-devel, and is in
use, for example, on N900, Beagle Board and Overo boards. We have an ACK for
the OMAP parts from Tony Lindgren, who maintains the OMAP platform.

We have gotten positive feedback about the driver, for example in this thread:
http://marc.info/?l=linux-kernel&m=125171081901820&w=2

The driver is actively maintained and developed further, and I have already a
bunch of patches on top of these patches, but I would like to get the big core
driver merged first. After the driver is merged, other people can send patches
to LCD drivers and board files to enable the new display subsystem on their
boards.

Andrew said 2-3 weeks ago that he'll merge the driver (after he has looked
through it), but he hasn't responded since then. I'm guessing he's quite busy.

Please pull the new OMAP2/3 display subsystem driver from:

  git://gitorious.org/linux-omap-dss2/linux.git for-linus

 Tomi

 ---

The following changes since commit 43c1266ce4dc06bfd236cec31e11e9ecd69c0bef:
  Linus Torvalds (1):
        Merge branch 'perfcounters-rename-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip

are available in the git repository at:

  git://gitorious.org/linux-omap-dss2/linux.git for-linus

Tomi Valkeinen (19):
      OMAP2: Add funcs for writing SMS_ROT_* registers
      OMAP: OMAPFB: split omapfb.h
      OMAP: OMAPFB: add omapdss device
      OMAP: Add VRAM manager
      OMAP: Add support for VRFB rotation engine
      OMAP: DSS2: Documentation for DSS2
      OMAP: DSS2: Display Subsystem Driver core
      OMAP: DSS2: Add more core files
      OMAP: DSS2: DISPC
      OMAP: DSS2: DPI driver
      OMAP: DSS2: Video encoder driver
      OMAP: DSS2: RFBI driver
      OMAP: DSS2: SDI driver
      OMAP: DSS2: DSI driver
      OMAP: DSS2: omapfb driver
      OMAP: DSS2: Add DPI panel drivers
      OMAP: DSS2: Taal DSI command mode panel driver
      OMAP: SDP: Enable DSS2 for OMAP3 SDP board
      MAINTAINERS: Add OMAP2/3 DSS and OMAPFB maintainer

 Documentation/arm/OMAP/DSS                         |  317 ++
 MAINTAINERS                                        |   17 +
 arch/arm/configs/omap_3430sdp_defconfig            |   61 +-
 arch/arm/mach-omap1/board-nokia770.c               |    2 +-
 arch/arm/mach-omap2/board-3430sdp.c                |  167 +-
 arch/arm/mach-omap2/clock24xx.c                    |    8 +-
 arch/arm/mach-omap2/clock34xx.c                    |   14 +-
 arch/arm/mach-omap2/io.c                           |    4 +-
 arch/arm/mach-omap2/sdrc.c                         |   16 +
 arch/arm/plat-omap/fb.c                            |   41 +-
 arch/arm/plat-omap/include/mach/display.h          |  540 +++
 arch/arm/plat-omap/include/mach/omapfb.h           |  398 ---
 arch/arm/plat-omap/include/mach/sdrc.h             |    9 +-
 arch/arm/plat-omap/include/mach/vram.h             |   63 +
 arch/arm/plat-omap/include/mach/vrfb.h             |   46 +
 arch/arm/plat-omap/sram.c                          |    8 +
 drivers/video/Kconfig                              |    1 +
 drivers/video/Makefile                             |    1 +
 drivers/video/omap/Kconfig                         |    5 +-
 drivers/video/omap/blizzard.c                      |    2 +-
 drivers/video/omap/dispc.c                         |   21 +-
 drivers/video/omap/hwa742.c                        |    2 +-
 drivers/video/omap/lcd_h3.c                        |    2 +-
 drivers/video/omap/lcd_h4.c                        |    2 +-
 drivers/video/omap/lcd_inn1510.c                   |    2 +-
 drivers/video/omap/lcd_inn1610.c                   |    2 +-
 drivers/video/omap/lcd_osk.c                       |    2 +-
 drivers/video/omap/lcd_palmte.c                    |    2 +-
 drivers/video/omap/lcd_palmtt.c                    |    2 +-
 drivers/video/omap/lcd_palmz71.c                   |    2 +-
 drivers/video/omap/lcdc.c                          |    3 +-
 drivers/video/omap/omapfb.h                        |  227 ++
 drivers/video/omap/omapfb_main.c                   |    2 +-
 drivers/video/omap/rfbi.c                          |    3 +-
 drivers/video/omap/sossi.c                         |    2 +-
 drivers/video/omap2/Kconfig                        |    9 +
 drivers/video/omap2/Makefile                       |    6 +
 drivers/video/omap2/displays/Kconfig               |   28 +
 drivers/video/omap2/displays/Makefile              |    5 +
 drivers/video/omap2/displays/panel-generic.c       |  104 +
 .../omap2/displays/panel-samsung-lte430wq-f0c.c    |  113 +
 .../video/omap2/displays/panel-sharp-ls037v7dw01.c |  153 +
 drivers/video/omap2/displays/panel-taal.c          |  900 +++++
 drivers/video/omap2/dss/Kconfig                    |   89 +
 drivers/video/omap2/dss/Makefile                   |    6 +
 drivers/video/omap2/dss/core.c                     |  917 +++++
 drivers/video/omap2/dss/dispc.c                    | 3182 ++++++++++++++++++
 drivers/video/omap2/dss/display.c                  |  658 ++++
 drivers/video/omap2/dss/dpi.c                      |  388 +++
 drivers/video/omap2/dss/dsi.c                      | 3509 ++++++++++++++++++++
 drivers/video/omap2/dss/dss.c                      |  347 ++
 drivers/video/omap2/dss/dss.h                      |  356 ++
 drivers/video/omap2/dss/manager.c                  | 1487 +++++++++
 drivers/video/omap2/dss/overlay.c                  |  673 ++++
 drivers/video/omap2/dss/rfbi.c                     | 1310 ++++++++
 drivers/video/omap2/dss/sdi.c                      |  261 ++
 drivers/video/omap2/dss/venc.c                     |  797 +++++
 drivers/video/omap2/omapfb/Kconfig                 |   37 +
 drivers/video/omap2/omapfb/Makefile                |    2 +
 drivers/video/omap2/omapfb/omapfb-ioctl.c          |  727 ++++
 drivers/video/omap2/omapfb/omapfb-main.c           | 2137 ++++++++++++
 drivers/video/omap2/omapfb/omapfb-sysfs.c          |  507 +++
 drivers/video/omap2/omapfb/omapfb.h                |  146 +
 drivers/video/omap2/vram.c                         |  655 ++++
 drivers/video/omap2/vrfb.c                         |  277 ++
 include/linux/omapfb.h                             |  242 ++
 66 files changed, 21572 insertions(+), 452 deletions(-)
 create mode 100644 Documentation/arm/OMAP/DSS
 create mode 100644 arch/arm/plat-omap/include/mach/display.h
 delete mode 100644 arch/arm/plat-omap/include/mach/omapfb.h
 create mode 100644 arch/arm/plat-omap/include/mach/vram.h
 create mode 100644 arch/arm/plat-omap/include/mach/vrfb.h
 create mode 100644 drivers/video/omap/omapfb.h
 create mode 100644 drivers/video/omap2/Kconfig
 create mode 100644 drivers/video/omap2/Makefile
 create mode 100644 drivers/video/omap2/displays/Kconfig
 create mode 100644 drivers/video/omap2/displays/Makefile
 create mode 100644 drivers/video/omap2/displays/panel-generic.c
 create mode 100644 drivers/video/omap2/displays/panel-samsung-lte430wq-f0c.c
 create mode 100644 drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
 create mode 100644 drivers/video/omap2/displays/panel-taal.c
 create mode 100644 drivers/video/omap2/dss/Kconfig
 create mode 100644 drivers/video/omap2/dss/Makefile
 create mode 100644 drivers/video/omap2/dss/core.c
 create mode 100644 drivers/video/omap2/dss/dispc.c
 create mode 100644 drivers/video/omap2/dss/display.c
 create mode 100644 drivers/video/omap2/dss/dpi.c
 create mode 100644 drivers/video/omap2/dss/dsi.c
 create mode 100644 drivers/video/omap2/dss/dss.c
 create mode 100644 drivers/video/omap2/dss/dss.h
 create mode 100644 drivers/video/omap2/dss/manager.c
 create mode 100644 drivers/video/omap2/dss/overlay.c
 create mode 100644 drivers/video/omap2/dss/rfbi.c
 create mode 100644 drivers/video/omap2/dss/sdi.c
 create mode 100644 drivers/video/omap2/dss/venc.c
 create mode 100644 drivers/video/omap2/omapfb/Kconfig
 create mode 100644 drivers/video/omap2/omapfb/Makefile
 create mode 100644 drivers/video/omap2/omapfb/omapfb-ioctl.c
 create mode 100644 drivers/video/omap2/omapfb/omapfb-main.c
 create mode 100644 drivers/video/omap2/omapfb/omapfb-sysfs.c
 create mode 100644 drivers/video/omap2/omapfb/omapfb.h
 create mode 100644 drivers/video/omap2/vram.c
 create mode 100644 drivers/video/omap2/vrfb.c
 create mode 100644 include/linux/omapfb.h

Re: [Linux-fbdev-devel] [GIT PULL]: OMAP2/3 Display Subsystem

[Artem B. <ded...@gm...>]

On 09/22/2009 03:29 PM, Tomi Valkeinen wrote:
> Linus,
>
> Here's the new display subsystem and framebuffer driver for OMAP2/3.
>
> The driver has been reviewed on linux-omap and linux-fbdev-devel, and is in
> use, for example, on N900, Beagle Board and Overo boards. We have an ACK for
> the OMAP parts from Tony Lindgren, who maintains the OMAP platform.
>
> We have gotten positive feedback about the driver, for example in this thread:
> http://marc.info/?l=linux-kernel&m=125171081901820&w=2
>
> The driver is actively maintained and developed further, and I have already a
> bunch of patches on top of these patches, but I would like to get the big core
> driver merged first. After the driver is merged, other people can send patches
> to LCD drivers and board files to enable the new display subsystem on their
> boards.
>
> Andrew said 2-3 weeks ago that he'll merge the driver (after he has looked
> through it), but he hasn't responded since then. I'm guessing he's quite busy.

Just in case it matters, here is my redundant confirmation that we are
successfully using this piece of software for about a year.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)