* [PATCH 10/10] OMAP: DSS2: reorganize functions in dss.h
From: Tomi Valkeinen @ 2011-08-22 8:27 UTC (permalink / raw)
To: linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1314001671-18123-1-git-send-email-tomi.valkeinen@ti.com>
Group dispc's overlay and manager related functions.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dss.h | 47 +++++++++++++++++++---------------------
1 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 0e95418..3de71c0 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -383,22 +383,24 @@ void dispc_disable_sidle(void);
void dispc_lcd_enable_signal_polarity(bool act_high);
void dispc_lcd_enable_signal(bool enable);
void dispc_pck_free_enable(bool enable);
-void dispc_mgr_enable_fifohandcheck(enum omap_channel channel, bool enable);
-
-void dispc_mgr_set_lcd_size(enum omap_channel channel, u16 width, u16 height);
void dispc_set_digit_size(u16 width, u16 height);
+void dispc_enable_fifomerge(bool enable);
+void dispc_enable_gamma_table(bool enable);
+void dispc_set_loadmode(enum omap_dss_load_mode mode);
+
+bool dispc_lcd_timings_ok(struct omap_video_timings *timings);
+unsigned long dispc_fclk_rate(void);
+void dispc_find_clk_divs(bool is_tft, unsigned long req_pck, unsigned long fck,
+ struct dispc_clock_info *cinfo);
+int dispc_calc_clock_rates(unsigned long dispc_fclk_rate,
+ struct dispc_clock_info *cinfo);
+
+
u32 dispc_ovl_get_fifo_size(enum omap_plane plane);
void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high);
-void dispc_enable_fifomerge(bool enable);
u32 dispc_ovl_get_burst_size(enum omap_plane plane);
-void dispc_mgr_enable_cpr(enum omap_channel channel, bool enable);
-void dispc_mgr_set_cpr_coef(enum omap_channel channel,
- struct omap_dss_cpr_coefs *coefs);
-
void dispc_ovl_set_channel_out(enum omap_plane plane,
enum omap_channel channel_out);
-
-void dispc_enable_gamma_table(bool enable);
int dispc_ovl_setup(enum omap_plane plane,
u32 paddr, u16 screen_width,
u16 pos_x, u16 pos_y,
@@ -411,21 +413,24 @@ int dispc_ovl_setup(enum omap_plane plane,
u8 global_alpha, u8 pre_mult_alpha,
enum omap_channel channel,
u32 puv_addr);
+int dispc_ovl_enable(enum omap_plane plane, bool enable);
+void dispc_ovl_enable_replication(enum omap_plane plane, bool enable);
+
+void dispc_mgr_enable_fifohandcheck(enum omap_channel channel, bool enable);
+void dispc_mgr_set_lcd_size(enum omap_channel channel, u16 width, u16 height);
+void dispc_mgr_enable_cpr(enum omap_channel channel, bool enable);
+void dispc_mgr_set_cpr_coef(enum omap_channel channel,
+ struct omap_dss_cpr_coefs *coefs);
bool dispc_mgr_go_busy(enum omap_channel channel);
void dispc_mgr_go(enum omap_channel channel);
void dispc_mgr_enable(enum omap_channel channel, bool enable);
bool dispc_mgr_is_channel_enabled(enum omap_channel channel);
-int dispc_ovl_enable(enum omap_plane plane, bool enable);
-void dispc_ovl_enable_replication(enum omap_plane plane, bool enable);
-
void dispc_mgr_set_parallel_interface_mode(enum omap_channel channel,
enum omap_parallel_interface_mode mode);
void dispc_mgr_set_tft_data_lines(enum omap_channel channel, u8 data_lines);
void dispc_mgr_set_lcd_display_type(enum omap_channel channel,
enum omap_lcd_display_type type);
-void dispc_set_loadmode(enum omap_dss_load_mode mode);
-
void dispc_mgr_set_default_color(enum omap_channel channel, u32 color);
u32 dispc_mgr_get_default_color(enum omap_channel channel);
void dispc_mgr_set_trans_key(enum omap_channel ch,
@@ -438,25 +443,17 @@ void dispc_mgr_enable_trans_key(enum omap_channel ch, bool enable);
void dispc_mgr_enable_alpha_blending(enum omap_channel ch, bool enable);
bool dispc_mgr_trans_key_enabled(enum omap_channel ch);
bool dispc_mgr_alpha_blending_enabled(enum omap_channel ch);
-
-bool dispc_lcd_timings_ok(struct omap_video_timings *timings);
void dispc_mgr_set_lcd_timings(enum omap_channel channel,
struct omap_video_timings *timings);
-unsigned long dispc_fclk_rate(void);
-unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
-unsigned long dispc_mgr_pclk_rate(enum omap_channel channel);
void dispc_mgr_set_pol_freq(enum omap_channel channel,
enum omap_panel_config config, u8 acbi, u8 acb);
-void dispc_find_clk_divs(bool is_tft, unsigned long req_pck, unsigned long fck,
- struct dispc_clock_info *cinfo);
-int dispc_calc_clock_rates(unsigned long dispc_fclk_rate,
- struct dispc_clock_info *cinfo);
+unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
+unsigned long dispc_mgr_pclk_rate(enum omap_channel channel);
int dispc_mgr_set_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo);
int dispc_mgr_get_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo);
-
/* VENC */
#ifdef CONFIG_OMAP2_DSS_VENC
int venc_init_platform_driver(void);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 00/10] OMAPDSS: code cleanups
From: Tomi Valkeinen @ 2011-08-22 8:42 UTC (permalink / raw)
To: linux-omap; +Cc: linux-fbdev
In-Reply-To: <1314001671-18123-1-git-send-email-tomi.valkeinen@ti.com>
On Mon, 2011-08-22 at 11:27 +0300, Tomi Valkeinen wrote:
> Cleanups for DSS driver, no functionality changed.
>
> Tomi
>
> Tomi Valkeinen (10):
> OMAP: DSS2: Remove support for non-DISPC overlays
> OMAP: DSS2: DISPC: use lookup tables for bit shifts
> OMAP: DSS2: Add overlay caps to DSS features
> OMAP: DSS2: Add GLOBAL_ALPHA & PRE_MULT_ALPHA to ovl caps
> OMAP: DSS2: string parsing cleanups
> OMAP: OMAPFB: string parsing cleanups
> OMAP: DSS2: DISPC: remove non-existing func prototypes
> OMAP: DSS2: DISPC: rename overlay related funcs
> OMAP: DSS2: DISPC: rename manager related funcs
> OMAP: DSS2: reorganize functions in dss.h
This patch set had some minor conflicts with the patch "OMAP: DSS2:
Handle manager change in apply". The dss master branch has all the
patches with conflicts resolved.
Tomi
^ permalink raw reply
* Re: [PATCH 05/10] OMAP: DSS2: string parsing cleanups
From: Tomi Valkeinen @ 2011-08-22 12:22 UTC (permalink / raw)
To: linux-omap; +Cc: linux-fbdev
In-Reply-To: <1314001671-18123-6-git-send-email-tomi.valkeinen@ti.com>
On Mon, 2011-08-22 at 11:27 +0300, Tomi Valkeinen wrote:
> Use strtobool and kstrto* functions when parsing sysfs inputs.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/display.c | 21 +++++++++------------
> drivers/video/omap2/dss/manager.c | 37 +++++++++++++++++++------------------
> drivers/video/omap2/dss/overlay.c | 7 +++----
> 3 files changed, 31 insertions(+), 34 deletions(-)
<snip>
> diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c
> index a95f25e..b2a5685 100644
> --- a/drivers/video/omap2/dss/overlay.c
> +++ b/drivers/video/omap2/dss/overlay.c
> @@ -211,17 +211,16 @@ static ssize_t overlay_enabled_show(struct omap_overlay *ovl, char *buf)
> static ssize_t overlay_enabled_store(struct omap_overlay *ovl, const char *buf,
> size_t size)
> {
> - int r, enable;
> + int r;
> + bool enable;
> struct omap_overlay_info info;
>
> ovl->get_overlay_info(ovl, &info);
>
> - r = kstrtoint(buf, 0, &enable);
> + r = strtobool(buf, &enable);
> if (r)
> return r;
>
> - info.enabled = !!enable;
> -
> r = ovl->set_overlay_info(ovl, &info);
> if (r)
> return r;
Oops. This removes the lines that write the new value to overlay_info,
thus making it impossible to change the enable-status. I'll fix this.
Tomi
^ permalink raw reply
* RE: [PATCH] video: ep93xx-fb: add missing include of linux/module.h
From: H Hartley Sweeten @ 2011-08-22 16:36 UTC (permalink / raw)
To: Axel Lin, linux-kernel@vger.kernel.org
Cc: Paul Mundt, linux-fbdev@vger.kernel.org
In-Reply-To: <1313937545.13671.5.camel@phoenix>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 2769 bytes --]
On Sunday, August 21, 2011 7:39 AM, Axel Lin wrote:
>
> ep93xx-fb.c uses interfaces from linux/module.h,
> so it should include that file. This patch fixes below build errors.
>
> CC drivers/video/ep93xx-fb.o
> drivers/video/ep93xx-fb.c:120: error: expected ')' before 'int'
> drivers/video/ep93xx-fb.c:122: error: expected ')' before string constant
> drivers/video/ep93xx-fb.c:409: error: 'THIS_MODULE' undeclared here (not in a function)
> drivers/video/ep93xx-fb.c:645: error: expected declaration specifiers or '...' before string constant
> drivers/video/ep93xx-fb.c:645: warning: data definition has no type or storage class
> drivers/video/ep93xx-fb.c:645: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
> drivers/video/ep93xx-fb.c:645: warning: function declaration isn't a prototype
> drivers/video/ep93xx-fb.c:646: error: expected declaration specifiers or '...' before string constant
> drivers/video/ep93xx-fb.c:646: warning: data definition has no type or storage class
> drivers/video/ep93xx-fb.c:646: warning: type defaults to 'int' in declaration of 'MODULE_ALIAS'
> drivers/video/ep93xx-fb.c:646: warning: function declaration isn't a prototype
> drivers/video/ep93xx-fb.c:647: error: expected declaration specifiers or '...' before string constant
> drivers/video/ep93xx-fb.c:647: warning: data definition has no type or storage class
> drivers/video/ep93xx-fb.c:647: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
> drivers/video/ep93xx-fb.c:647: warning: function declaration isn't a prototype
> drivers/video/ep93xx-fb.c:649: error: expected declaration specifiers or '...' before string constant
> drivers/video/ep93xx-fb.c:649: warning: data definition has no type or storage class
> drivers/video/ep93xx-fb.c:649: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
> drivers/video/ep93xx-fb.c:649: warning: function declaration isn't a prototype
> make[2]: *** [drivers/video/ep93xx-fb.o] Error 1
> make[1]: *** [drivers/video] Error 2
> make: *** [drivers] Error 2
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
> ---
> drivers/video/ep93xx-fb.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
> index 40e5f17..8133a9d 100644
> --- a/drivers/video/ep93xx-fb.c
> +++ b/drivers/video/ep93xx-fb.c
> @@ -17,6 +17,7 @@
> *
> */
>
> +#include <linux/module.h>
> #include <linux/platform_device.h>
> #include <linux/dma-mapping.h>
> #include <linux/slab.h>
Same issue as the backlight driver...
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply
* RE: [PATCH] video: ep93xx-fb: add missing include of linux/module.h
From: H Hartley Sweeten @ 2011-08-22 16:40 UTC (permalink / raw)
To: Ryan Mallon, axel.lin@gmail.com
Cc: linux-kernel@vger.kernel.org, Paul Mundt,
linux-fbdev@vger.kernel.org, Paul Gortmaker
In-Reply-To: <4E51A34C.6060207@gmail.com>
On Sunday, August 21, 2011 5:31 PM, Ryan Mallon wrote:
> On 22/08/11 10:06, Axel Lin wrote:
>> 2011/8/22 Ryan Mallon<rmallon@gmail.com>:
>>> On 22/08/11 09:41, Ryan Mallon wrote:
>>>> On 22/08/11 00:39, Axel Lin wrote:
>>>>> ep93xx-fb.c uses interfaces from linux/module.h,
>>>>> so it should include that file. This patch fixes below build errors.
>>>> What actually changed to make these files broken? Did some other header
>>>> previously include module.h for us? How many other drivers are broken?
>>>>
>>>> Anyway, the change is okay.
>>>>
>>>> Acked-by: Ryan Mallon<rmallon@gmail.com>
>>> Actually, having a second look at this it does not look right.
>>>
>>> drivers/video/ep93xx-fb.c includes linux/platform.h (as its first include),
>>> which includes linux/driver.h, which includes linux/module.h.
>>>
>>> Just tested on Linus' latest tree and both this driver and the ep93xx
>>> backlight driver build fine. What kernel version are you using?
>>>
>>> ~Ryan
>> hi Ryan,
>>
>> The patch is against linux-next tree.
>> I got build error for ep93xx-fb.c and ep93xx_bl.c on linux-next tree.
>> ( next-20110819 )
>
> Ok, I see now. The change which caused the breakage is fdb697c:
> "include: replace linux/module.h with "struct module" wherever
> possible". How many other drivers got broken now that device.h does not
> include module.h?
Probably a lot... Which is one of the reasons linux-next exists.. . ;-)
Actually, Paul Gortmaker caused this breakage with the commit. He should
take a deeper look and see what it broke. From his commit:
Most of the implicit dependencies on module.h being present by
these headers pulling it in have been now weeded out, so we can
finally make this change with hopefully minimal breakage.
Regards,
Hartley
^ permalink raw reply
* Re: [PATCH] video: ep93xx-fb: add missing include of linux/module.h
From: Ryan Mallon @ 2011-08-22 23:48 UTC (permalink / raw)
To: H Hartley Sweeten
Cc: axel.lin@gmail.com, linux-kernel@vger.kernel.org, Paul Mundt,
linux-fbdev@vger.kernel.org, Paul Gortmaker
In-Reply-To: <ADE657CA350FB648AAC2C43247A983F001F388575258@AUSP01VMBX24.collaborationhost.net>
On 23/08/11 02:40, H Hartley Sweeten wrote:
> On Sunday, August 21, 2011 5:31 PM, Ryan Mallon wrote:
>> On 22/08/11 10:06, Axel Lin wrote:
>>> 2011/8/22 Ryan Mallon<rmallon@gmail.com>:
>>>> On 22/08/11 09:41, Ryan Mallon wrote:
>>>>> On 22/08/11 00:39, Axel Lin wrote:
>>>>>> ep93xx-fb.c uses interfaces from linux/module.h,
>>>>>> so it should include that file. This patch fixes below build errors.
>>>>> What actually changed to make these files broken? Did some other header
>>>>> previously include module.h for us? How many other drivers are broken?
>>>>>
>>>>> Anyway, the change is okay.
>>>>>
>>>>> Acked-by: Ryan Mallon<rmallon@gmail.com>
>>>> Actually, having a second look at this it does not look right.
>>>>
>>>> drivers/video/ep93xx-fb.c includes linux/platform.h (as its first include),
>>>> which includes linux/driver.h, which includes linux/module.h.
>>>>
>>>> Just tested on Linus' latest tree and both this driver and the ep93xx
>>>> backlight driver build fine. What kernel version are you using?
>>>>
>>>> ~Ryan
>>> hi Ryan,
>>>
>>> The patch is against linux-next tree.
>>> I got build error for ep93xx-fb.c and ep93xx_bl.c on linux-next tree.
>>> ( next-20110819 )
>> Ok, I see now. The change which caused the breakage is fdb697c:
>> "include: replace linux/module.h with "struct module" wherever
>> possible". How many other drivers got broken now that device.h does not
>> include module.h?
> Probably a lot... Which is one of the reasons linux-next exists.. . ;-)
Does anybody know how we can quickly determine which drivers are broken
short of doing an allyesconfig? I tried to do some quick tricks by
passing files which contain THIS_MODULE/MODULE_* through cpp, but I get
loads of errors in headers files because I'm missing some config
includes. Is there an easy way to get the kbuild arguments for the
current .config so I can pass them to cpp?
> Actually, Paul Gortmaker caused this breakage with the commit. He should
> take a deeper look and see what it broke. From his commit:
>
> Most of the implicit dependencies on module.h being present by
> these headers pulling it in have been now weeded out, so we can
> finally make this change with hopefully minimal breakage.
Quick glance:
ryanm@kiwi:linux-2.6$ grep -lR "^MODULE_" drivers/ | xargs grep -L
"linux/module.h\|linux/moduleloader.h\|linux/miscdevice.h\|linux/regmap.h\|linux/irq.h"
| wc -l
579
ryanm@kiwi:linux-2.6$ grep -lR "THIS_MODULE" drivers/ | xargs grep -L
"linux/module.h\|linux/moduleloader.h\|linux/miscdevice.h\|linux/regmap.h\|linux/irq.h\|linux/export.h\|acpi/platform/aclinux.h\|xen/xenbus.h"
| wc -l
399
Not sure how many of those are really broken though since there may be a
few other ways to include module.h/export.h. I would also think there
would be a lot more build failure reports if all of those were broken :-).
~Ryan
^ permalink raw reply
* Re: [RFC PATCH v2] Resurrect Intel740 driver: i740fb
From: Ondrej Zary @ 2011-08-23 9:03 UTC (permalink / raw)
To: Alan Cox
Cc: linux-fbdev, Kernel development list, Paul Mundt,
Florian Tobias Schandinat
In-Reply-To: <20110821233648.6d120143@lxorguk.ukuu.org.uk>
On Monday 22 August 2011, Alan Cox wrote:
> > - 24bpp modes still don't work in fbtest but it looks like fbtest bug!
> >
> > Is there any better way to test fb drivers than fbtest?
>
> X11 fbdev driver ?
Thanks, completely forgot about that. It works fine even in 24bpp.
> Alan
--
Ondrej Zary
^ permalink raw reply
* Re: [RFC PATCH v2] Resurrect Intel740 driver: i740fb
From: Dave Airlie @ 2011-08-23 9:10 UTC (permalink / raw)
To: Ondrej Zary
Cc: linux-fbdev, Kernel development list, Paul Mundt,
Florian Tobias Schandinat
In-Reply-To: <201108212242.12717.linux@rainbow-software.org>
On Sun, Aug 21, 2011 at 9:42 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> Hello,
> this is an v2 attempt to resurrect an old (like 2.4.19) out-of-tree driver for
> Intel740 graphics cards and modify it for recent kernels. The old driver is
> located at: http://sourceforge.net/projects/i740fbdev/files/
>
> It was easier to create a new driver based on skeletonfb, using most of the
> low level HW code from the old driver. The DDC code is completely new.
>
> The driver was tested on two 8MB cards: ManLi and Diamond Stealth II G460
>
> The i740_calc_fifo() function formatting is nice but does not pass
> checkpatch. Making it checkpatch-compliant makes the code look ugly. How to
> make it both nice and compatible with Linux coding style?
> (the remaining // comments mark things that need attention - missing xpan
> and suspend/resume)
>
> Changes in v2:
> - fixed 15bpp (16bpp 555) mode
> - not working 1280x1024-32 is not a bug but card's feature, it's now handled
> correctly by the driver
> - 24bpp modes still don't work in fbtest but it looks like fbtest bug!
>
> Is there any better way to test fb drivers than fbtest?
>
> no signed-off-by yet
>
> --- linux-2.6.39-rc2-orig/drivers/video/Kconfig 2011-04-06 03:30:43.000000000 +0200
> +++ linux-2.6.39-rc2/drivers/video/Kconfig 2011-07-30 11:34:10.000000000 +0200
> @@ -1117,6 +1117,17 @@ config FB_RIVA_BACKLIGHT
> help
> Say Y here if you want to control the backlight of your display.
>
> +config FB_I740
> + tristate "Intel740 support (EXPERIMENTAL)"
> + depends on EXPERIMENTAL && FB && PCI && X86_32 && AGP_INTEL
> + select FB_MODE_HELPERS
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + select VGASTATE
> + help
> + This driver supports graphics cards based on Intel740 chip.
> +
It shouldn't need AGP_INTEL, as its an AGP card not an integrated
chipset, it might need just AGP.
Dave.
^ permalink raw reply
* Re: [RFC PATCH v2] Resurrect Intel740 driver: i740fb
From: Michel Dänzer @ 2011-08-23 9:25 UTC (permalink / raw)
To: Ondrej Zary
Cc: Alan Cox, linux-fbdev, Kernel development list, Paul Mundt,
Florian Tobias Schandinat
In-Reply-To: <201108231103.30591.linux@rainbow-software.org>
On Die, 2011-08-23 at 11:03 +0200, Ondrej Zary wrote:
> On Monday 22 August 2011, Alan Cox wrote:
> > > - 24bpp modes still don't work in fbtest but it looks like fbtest bug!
> > >
> > > Is there any better way to test fb drivers than fbtest?
> >
> > X11 fbdev driver ?
>
> Thanks, completely forgot about that. It works fine even in 24bpp.
Beware that Xorg defaults to 32 bpp for depth 24; did you verify in
Xorg.0.log that it was really using 24 bpp?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [RFC PATCH v2] Resurrect Intel740 driver: i740fb
From: Ondrej Zary @ 2011-08-23 9:58 UTC (permalink / raw)
To: Michel Dänzer
Cc: Alan Cox, linux-fbdev, Kernel development list, Paul Mundt,
Florian Tobias Schandinat
In-Reply-To: <1314091533.21860.289.camel@thor.local>
On Tuesday 23 August 2011, Michel Dänzer wrote:
> On Die, 2011-08-23 at 11:03 +0200, Ondrej Zary wrote:
> > On Monday 22 August 2011, Alan Cox wrote:
> > > > - 24bpp modes still don't work in fbtest but it looks like fbtest
> > > > bug!
> > > >
> > > > Is there any better way to test fb drivers than fbtest?
> > >
> > > X11 fbdev driver ?
> >
> > Thanks, completely forgot about that. It works fine even in 24bpp.
>
> Beware that Xorg defaults to 32 bpp for depth 24; did you verify in
> Xorg.0.log that it was really using 24 bpp?
Yes, found that very quickly as I was testing at 1280x1024 and the card cannot
do 32bpp there. I had to set both DefaultDepth and DefaultFbBpp to 24 for X11
to run.
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH] video: ep93xx-fb: add missing include of linux/module.h
From: Paul Gortmaker @ 2011-08-24 13:39 UTC (permalink / raw)
To: Ryan Mallon
Cc: H Hartley Sweeten, axel.lin@gmail.com,
linux-kernel@vger.kernel.org, Paul Mundt,
linux-fbdev@vger.kernel.org
In-Reply-To: <4E52EAB3.4090201@gmail.com>
On 11-08-22 07:48 PM, Ryan Mallon wrote:
> On 23/08/11 02:40, H Hartley Sweeten wrote:
>> On Sunday, August 21, 2011 5:31 PM, Ryan Mallon wrote:
>>> On 22/08/11 10:06, Axel Lin wrote:
>>>> 2011/8/22 Ryan Mallon<rmallon@gmail.com>:
>>>>> On 22/08/11 09:41, Ryan Mallon wrote:
>>>>>> On 22/08/11 00:39, Axel Lin wrote:
>>>>>>> ep93xx-fb.c uses interfaces from linux/module.h,
>>>>>>> so it should include that file. This patch fixes below build errors.
>>>>>> What actually changed to make these files broken? Did some other header
>>>>>> previously include module.h for us? How many other drivers are broken?
>>>>>>
>>>>>> Anyway, the change is okay.
>>>>>>
>>>>>> Acked-by: Ryan Mallon<rmallon@gmail.com>
>>>>> Actually, having a second look at this it does not look right.
>>>>>
>>>>> drivers/video/ep93xx-fb.c includes linux/platform.h (as its first include),
>>>>> which includes linux/driver.h, which includes linux/module.h.
For the record, this is exactly what we are trying to fix -- relying on
implicit and non-obvious include chaining. If you are writing a modular
driver, you should include module.h explicitly.
>>>>>
>>>>> Just tested on Linus' latest tree and both this driver and the ep93xx
>>>>> backlight driver build fine. What kernel version are you using?
>>>>>
>>>>> ~Ryan
>>>> hi Ryan,
>>>>
>>>> The patch is against linux-next tree.
>>>> I got build error for ep93xx-fb.c and ep93xx_bl.c on linux-next tree.
>>>> ( next-20110819 )
>>> Ok, I see now. The change which caused the breakage is fdb697c:
>>> "include: replace linux/module.h with "struct module" wherever
>>> possible". How many other drivers got broken now that device.h does not
>>> include module.h?
>> Probably a lot... Which is one of the reasons linux-next exists.. . ;-)
>
> Does anybody know how we can quickly determine which drivers are broken
> short of doing an allyesconfig? I tried to do some quick tricks by
> passing files which contain THIS_MODULE/MODULE_* through cpp, but I get
> loads of errors in headers files because I'm missing some config
> includes. Is there an easy way to get the kbuild arguments for the
> current .config so I can pass them to cpp?
>
>> Actually, Paul Gortmaker caused this breakage with the commit. He should
>> take a deeper look and see what it broke. From his commit:
>>
>> Most of the implicit dependencies on module.h being present by
>> these headers pulling it in have been now weeded out, so we can
>> finally make this change with hopefully minimal breakage.
>
> Quick glance:
>
> ryanm@kiwi:linux-2.6$ grep -lR "^MODULE_" drivers/ | xargs grep -L
> "linux/module.h\|linux/moduleloader.h\|linux/miscdevice.h\|linux/regmap.h\|linux/irq.h"
> | wc -l
> 579
This can be misleading because subsystems may have a common header that
includes module.h, and then all the C files include that common header.
I think the e1000 network driver is one example.
>
> ryanm@kiwi:linux-2.6$ grep -lR "THIS_MODULE" drivers/ | xargs grep -L
> "linux/module.h\|linux/moduleloader.h\|linux/miscdevice.h\|linux/regmap.h\|linux/irq.h\|linux/export.h\|acpi/platform/aclinux.h\|xen/xenbus.h"
> | wc -l
> 399
>
> Not sure how many of those are really broken though since there may be a
> few other ways to include module.h/export.h. I would also think there
> would be a lot more build failure reports if all of those were broken :-).
Exactly. I've done allyesconfig, allnoconfig, allmodconfig builds for all
the common arch and even half a dozen or so uncommon arch. Plus in the case
of things like arm and powerpc with board specific config files that are in
arch/*/configs, I've built all those. So a couple of odd cases like this
which don't get build coverage through any of the above was expected, and
hence the value of being in linux-next for a while.
Thanks all for the report, I'll make sure these files get the proper
include header they need.
Paul.
>
> ~Ryan
>
>
>
^ permalink raw reply
* linux-next tree addition request (fbdev)
From: Florian Tobias Schandinat @ 2011-08-24 13:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-fbdev@vger.kernel.org, Paul Mundt
Hi Stephen,
can you please add
git://github.com/schandinat/linux-2.6.git fbdev-next
to linux-next. It collects patches for the frame buffer subsystem.
Can you please add the linux-fbdev@vger.kernel.org mailing list as additional
contact for warnings/errors/problems?
You probably want to drop Paul's fbdev branches as they contain some outdated
patches that will conflict with the newer versions.
Thanks,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 4/6] udlfb: Add module option to do without shadow framebuffer
From: Florian Tobias Schandinat @ 2011-08-24 13:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1313958862-5640-7-git-send-email-bernie@plugable.com>
On 08/21/2011 08:34 PM, bernie@plugable.com wrote:
> From: Stuart Hopkins <stuart@linux-depot.com>
>
> By default, udlfb allocates a 2nd buffer to shadow what's across
> the bus on the USB device. It can operate without this shadow,
> but then it cannot tell which pixels have changed, and must send all.
>
> Saves host memory, but worsens the USB 2.0 bus bottleneck.
>
> This option allows users in very low memory situations (e.g.
> bifferboard) to optionally turn off this shadow framebuffer.
>
> Signed-off-by: Bernie Thompson <bernie@plugable.com>
> Signed-off-by: Stuart Hopkins <stuart@linux-depot.com>
The order of the Signed-offs looks a bit strange here so I reordered them.
I applied the ?/6 series.
Thanks,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PULL] Use display information in info not in var for panning
From: Florian Tobias Schandinat @ 2011-08-24 14:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201108191038.43286.laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 08/19/2011 08:38 AM, Laurent Pinchart wrote:
> Hi Florian (or should I call you Florian Tobias ?),
Florian is good. I just use my full name as an indication of authenticity.
> Here is the latest version of the pan patches based on top of v3.1-rc2. Apart
> from being rebased, they're identical to the v3 version posted to the linux-
> fbdev mailing list.
Pulled this one.
JFYI: I want to have a deeper look at the other pull request you sent and
therefore I will need some time for it.
Thanks,
Florian Tobias Schandinat
> The following changes since commit 93ee7a9340d64f20295aacc3fb6a22b759323280:
>
> Linux 3.1-rc2 (2011-08-14 15:09:08 -0700)
>
> are available in the git repository at:
> git://linuxtv.org/pinchartl/fbdev.git pan-fixes
>
> Laurent Pinchart (29):
> 68328fb: use display information in info not in var for panning
> acornfb: Dont BUG() on invalid pan parameters
> acornfb: use display information in info not in var for panning
> arkfb: use display information in info not in var for panning
> atmel_lcdfb: use display information in info not in var for panning
> radeonfb: use display information in info not in var for panning
> fbdev: da8xx: use display information in info not in var for panning
> fbdev: unicore32: use display information in info not in var for panning
> g364fb: use display information in info not in var for panning
> gxt4500: use display information in info not in var for panning
> hgafb: use display information in info not in var for panning
> imsttfb: use display information in info not in var for panning
> intelfb: use display information in info not in var for panning
> mb862xxfb: use display information in info not in var for panning
> mx3fb: use display information in info not in var for panning
> neofb: use display information in info not in var for panning
> pm2fb: use display information in info not in var for panning
> pm3fb: use display information in info not in var for panning
> s3c-fb: use display information in info not in var for panning
> s3fb: use display information in info not in var for panning
> savagefb: use display information in info not in var for panning
> sisfb: use display information in info not in var for panning
> sm501fb: use display information in info not in var for panning
> tridentfb: use display information in info not in var for panning
> vfb: use display information in info not in var for panning
> vga16fb: use display information in info not in var for panning
> vt8500lcdfb: use display information in info not in var for panning
> vt8623fb: use display information in info not in var for panning
> staging: xgifb: use display information in info not in var for panning
>
> drivers/staging/xgifb/XGI_main_26.c | 22 ++++++----------------
> drivers/video/68328fb.c | 4 ++--
> drivers/video/acornfb.c | 5 +++--
> drivers/video/arkfb.c | 9 +++++----
> drivers/video/atmel_lcdfb.c | 15 +++++++++------
> drivers/video/aty/radeon_base.c | 10 +++++-----
> drivers/video/da8xx-fb.c | 4 ++--
> drivers/video/fb-puv3.c | 4 ++--
> drivers/video/g364fb.c | 5 +++--
> drivers/video/gxt4500.c | 4 ++--
> drivers/video/hgafb.c | 4 ++--
> drivers/video/imsttfb.c | 2 +-
> drivers/video/intelfb/intelfbhw.c | 6 +++---
> drivers/video/mb862xx/mb862xxfbdrv.c | 2 +-
> drivers/video/mx3fb.c | 6 +++---
> drivers/video/neofb.c | 4 ++--
> drivers/video/pm2fb.c | 4 ++--
> drivers/video/pm3fb.c | 4 ++--
> drivers/video/s3c-fb.c | 2 +-
> drivers/video/s3fb.c | 7 ++++---
> drivers/video/savage/savagefb_driver.c | 16 +++++++---------
> drivers/video/sis/sis_main.c | 30 ++++++++++--------------------
> drivers/video/sm501fb.c | 6 +++---
> drivers/video/tridentfb.c | 4 ++--
> drivers/video/vfb.c | 4 ++--
> drivers/video/vga16fb.c | 2 +-
> drivers/video/vt8500lcdfb.c | 4 ++--
> drivers/video/vt8623fb.c | 9 +++++----
> 28 files changed, 92 insertions(+), 106 deletions(-)
>
^ permalink raw reply
* Re: [PATCH RESEND] video: s3c-fb: Add support EXYNOS4 FIMD
From: Florian Tobias Schandinat @ 2011-08-24 14:23 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1311673687-1522-1-git-send-email-jg1.han@samsung.com>
On 08/22/2011 03:16 AM, Jingoo Han wrote:
> This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4
> and adds lcd clock gating support.
>
> FIMD driver needs two clocks for FIMD IP and LCD pixel clock. Previously,
> both clocks are provided by using bus clock such as HCLK. However, EXYNOS4
> can not select HCLK for LCD pixel clock because the EXYNOS4 FIMD IP does not
> have the CLKSEL bit of VIDCON0. So, FIMD driver should provide the lcd clock
> using SCLK_FIMD as LCD pixel clock for EXYNOS4.
>
> The driver selects enabling lcd clock according to has_clksel which means
> the CLKSEL bit of VIDCON0. If there is has_clksel, the driver will not
> enable the lcd clock using SCLK_FIMD because bus clock using HCLK is used
> a LCD pixel clock.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Looks good to me, I've applied it.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/Kconfig | 2 +-
> drivers/video/s3c-fb.c | 88 +++++++++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 85 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 549b960..963b8b7 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2027,7 +2027,7 @@ config FB_TMIO_ACCELL
>
> config FB_S3C
> tristate "Samsung S3C framebuffer support"
> - depends on FB && S3C_DEV_FB
> + depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 4aecf21..cb0d3ea 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -81,6 +81,7 @@ struct s3c_fb;
> * @palette: Address of palette memory, or 0 if none.
> * @has_prtcon: Set if has PRTCON register.
> * @has_shadowcon: Set if has SHADOWCON register.
> + * @has_clksel: Set if VIDCON0 register has CLKSEL bit.
> */
> struct s3c_fb_variant {
> unsigned int is_2443:1;
> @@ -98,6 +99,7 @@ struct s3c_fb_variant {
>
> unsigned int has_prtcon:1;
> unsigned int has_shadowcon:1;
> + unsigned int has_clksel:1;
> };
>
> /**
> @@ -186,6 +188,7 @@ struct s3c_fb_vsync {
> * @dev: The device that we bound to, for printing, etc.
> * @regs_res: The resource we claimed for the IO registers.
> * @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
> + * @lcd_clk: The clk (sclk) feeding pixclk.
> * @regs: The mapped hardware registers.
> * @variant: Variant information for this hardware.
> * @enabled: A bitmask of enabled hardware windows.
> @@ -200,6 +203,7 @@ struct s3c_fb {
> struct device *dev;
> struct resource *regs_res;
> struct clk *bus_clk;
> + struct clk *lcd_clk;
> void __iomem *regs;
> struct s3c_fb_variant variant;
>
> @@ -336,10 +340,15 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
> */
> static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
> {
> - unsigned long clk = clk_get_rate(sfb->bus_clk);
> + unsigned long clk;
> unsigned long long tmp;
> unsigned int result;
>
> + if (sfb->variant.has_clksel)
> + clk = clk_get_rate(sfb->bus_clk);
> + else
> + clk = clk_get_rate(sfb->lcd_clk);
> +
> tmp = (unsigned long long)clk;
> tmp *= pixclk;
>
> @@ -1354,13 +1363,24 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
>
> clk_enable(sfb->bus_clk);
>
> + if (!sfb->variant.has_clksel) {
> + sfb->lcd_clk = clk_get(dev, "sclk_fimd");
> + if (IS_ERR(sfb->lcd_clk)) {
> + dev_err(dev, "failed to get lcd clock\n");
> + ret = PTR_ERR(sfb->lcd_clk);
> + goto err_bus_clk;
> + }
> +
> + clk_enable(sfb->lcd_clk);
> + }
> +
> pm_runtime_enable(sfb->dev);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(dev, "failed to find registers\n");
> ret = -ENOENT;
> - goto err_clk;
> + goto err_lcd_clk;
> }
>
> sfb->regs_res = request_mem_region(res->start, resource_size(res),
> @@ -1368,7 +1388,7 @@ static int __devinit s3c_fb_probe(struct platform_device *pdev)
> if (!sfb->regs_res) {
> dev_err(dev, "failed to claim register region\n");
> ret = -ENOENT;
> - goto err_clk;
> + goto err_lcd_clk;
> }
>
> sfb->regs = ioremap(res->start, resource_size(res));
> @@ -1450,7 +1470,13 @@ err_ioremap:
> err_req_region:
> release_mem_region(sfb->regs_res->start, resource_size(sfb->regs_res));
>
> -err_clk:
> +err_lcd_clk:
> + if (!sfb->variant.has_clksel) {
> + clk_disable(sfb->lcd_clk);
> + clk_put(sfb->lcd_clk);
> + }
> +
> +err_bus_clk:
> clk_disable(sfb->bus_clk);
> clk_put(sfb->bus_clk);
>
> @@ -1481,6 +1507,11 @@ static int __devexit s3c_fb_remove(struct platform_device *pdev)
>
> iounmap(sfb->regs);
>
> + if (!sfb->variant.has_clksel) {
> + clk_disable(sfb->lcd_clk);
> + clk_put(sfb->lcd_clk);
> + }
> +
> clk_disable(sfb->bus_clk);
> clk_put(sfb->bus_clk);
>
> @@ -1510,6 +1541,9 @@ static int s3c_fb_suspend(struct device *dev)
> s3c_fb_blank(FB_BLANK_POWERDOWN, win->fbinfo);
> }
>
> + if (!sfb->variant.has_clksel)
> + clk_disable(sfb->lcd_clk);
> +
> clk_disable(sfb->bus_clk);
> return 0;
> }
> @@ -1524,6 +1558,9 @@ static int s3c_fb_resume(struct device *dev)
>
> clk_enable(sfb->bus_clk);
>
> + if (!sfb->variant.has_clksel)
> + clk_enable(sfb->lcd_clk);
> +
> /* setup gpio and output polarity controls */
> pd->setup_gpio();
> writel(pd->vidcon1, sfb->regs + VIDCON1);
> @@ -1569,6 +1606,9 @@ static int s3c_fb_runtime_suspend(struct device *dev)
> s3c_fb_blank(FB_BLANK_POWERDOWN, win->fbinfo);
> }
>
> + if (!sfb->variant.has_clksel)
> + clk_disable(sfb->lcd_clk);
> +
> clk_disable(sfb->bus_clk);
> return 0;
> }
> @@ -1583,6 +1623,9 @@ static int s3c_fb_runtime_resume(struct device *dev)
>
> clk_enable(sfb->bus_clk);
>
> + if (!sfb->variant.has_clksel)
> + clk_enable(sfb->lcd_clk);
> +
> /* setup gpio and output polarity controls */
> pd->setup_gpio();
> writel(pd->vidcon1, sfb->regs + VIDCON1);
> @@ -1755,6 +1798,7 @@ static struct s3c_fb_driverdata s3c_fb_data_64xx = {
> },
>
> .has_prtcon = 1,
> + .has_clksel = 1,
> },
> .win[0] = &s3c_fb_data_64xx_wins[0],
> .win[1] = &s3c_fb_data_64xx_wins[1],
> @@ -1785,6 +1829,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pc100 = {
> },
>
> .has_prtcon = 1,
> + .has_clksel = 1,
> },
> .win[0] = &s3c_fb_data_s5p_wins[0],
> .win[1] = &s3c_fb_data_s5p_wins[1],
> @@ -1815,6 +1860,37 @@ static struct s3c_fb_driverdata s3c_fb_data_s5pv210 = {
> },
>
> .has_shadowcon = 1,
> + .has_clksel = 1,
> + },
> + .win[0] = &s3c_fb_data_s5p_wins[0],
> + .win[1] = &s3c_fb_data_s5p_wins[1],
> + .win[2] = &s3c_fb_data_s5p_wins[2],
> + .win[3] = &s3c_fb_data_s5p_wins[3],
> + .win[4] = &s3c_fb_data_s5p_wins[4],
> +};
> +
> +static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
> + .variant = {
> + .nr_windows = 5,
> + .vidtcon = VIDTCON0,
> + .wincon = WINCON(0),
> + .winmap = WINxMAP(0),
> + .keycon = WKEYCON,
> + .osd = VIDOSD_BASE,
> + .osd_stride = 16,
> + .buf_start = VIDW_BUF_START(0),
> + .buf_size = VIDW_BUF_SIZE(0),
> + .buf_end = VIDW_BUF_END(0),
> +
> + .palette = {
> + [0] = 0x2400,
> + [1] = 0x2800,
> + [2] = 0x2c00,
> + [3] = 0x3000,
> + [4] = 0x3400,
> + },
> +
> + .has_shadowcon = 1,
> },
> .win[0] = &s3c_fb_data_s5p_wins[0],
> .win[1] = &s3c_fb_data_s5p_wins[1],
> @@ -1843,6 +1919,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
> [0] = 0x400,
> [1] = 0x800,
> },
> + .has_clksel = 1,
> },
> .win[0] = &(struct s3c_fb_win_variant) {
> .palette_sz = 256,
> @@ -1870,6 +1947,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
> .name = "s5pv210-fb",
> .driver_data = (unsigned long)&s3c_fb_data_s5pv210,
> }, {
> + .name = "exynos4-fb",
> + .driver_data = (unsigned long)&s3c_fb_data_exynos4,
> + }, {
> .name = "s3c2443-fb",
> .driver_data = (unsigned long)&s3c_fb_data_s3c2443,
> },
^ permalink raw reply
* Re: [PULL] Use display information in info not in var for panning
From: Laurent Pinchart @ 2011-08-24 14:24 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201108191038.43286.laurent.pinchart@ideasonboard.com>
Hi Florian,
On Wednesday 24 August 2011 16:15:46 Florian Tobias Schandinat wrote:
> On 08/19/2011 08:38 AM, Laurent Pinchart wrote:
> > Hi Florian (or should I call you Florian Tobias ?),
>
> Florian is good. I just use my full name as an indication of authenticity.
>
> > Here is the latest version of the pan patches based on top of v3.1-rc2.
> > Apart from being rebased, they're identical to the v3 version posted to
> > the linux- fbdev mailing list.
>
> Pulled this one.
Thank you.
> JFYI: I want to have a deeper look at the other pull request you sent and
> therefore I will need some time for it.
No worries. Review is always appreciated :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: linux-next tree addition request (fbdev)
From: Stephen Rothwell @ 2011-08-24 14:33 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-next, linux-fbdev@vger.kernel.org, Paul Mundt
In-Reply-To: <4E54FF5E.5050308@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]
Hi Florian,
On Wed, 24 Aug 2011 13:40:46 +0000 Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
>
> can you please add
>
> git://github.com/schandinat/linux-2.6.git fbdev-next
>
> to linux-next. It collects patches for the frame buffer subsystem.
> Can you please add the linux-fbdev@vger.kernel.org mailing list as additional
> contact for warnings/errors/problems?
>
> You probably want to drop Paul's fbdev branches as they contain some outdated
> patches that will conflict with the newer versions.
OK, Paul is still listed as the frame buffer subsystem maintainer, so I
will need an Ack from him. When I get that, I will replace his tree with
yours. I assume someone will update the MAINTAINERS file.
I also have another tree from Paul (called fbdev-current) that contained
fixes for Linus' current release. I also assume that that tree will be
dropped (unless you have a new version of that as well).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] video: mxsfb: add missing include of linux/module.h
From: Axel Lin @ 2011-08-25 7:54 UTC (permalink / raw)
To: linux-kernel; +Cc: Sascha Hauer, Paul Mundt, linux-fbdev
Include linux/module.h to fix below build error:
from drivers/video/mxsfb.c:42:
arch/arm/mach-mxs/include/mach/memory.h:22:1: warning: this is the location of the previous definition
drivers/video/mxsfb.c:574: error: 'THIS_MODULE' undeclared here (not in a function)
drivers/video/mxsfb.c:893: warning: data definition has no type or storage class
drivers/video/mxsfb.c:893: warning: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE'
drivers/video/mxsfb.c:893: warning: parameter names (without types) in function declaration
drivers/video/mxsfb.c:917: error: expected declaration specifiers or '...' before string constant
drivers/video/mxsfb.c:917: warning: data definition has no type or storage class
drivers/video/mxsfb.c:917: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
drivers/video/mxsfb.c:917: warning: function declaration isn't a prototype
drivers/video/mxsfb.c:918: error: expected declaration specifiers or '...' before string constant
drivers/video/mxsfb.c:918: warning: data definition has no type or storage class
drivers/video/mxsfb.c:918: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
drivers/video/mxsfb.c:918: warning: function declaration isn't a prototype
drivers/video/mxsfb.c:919: error: expected declaration specifiers or '...' before string constant
drivers/video/mxsfb.c:919: warning: data definition has no type or storage class
drivers/video/mxsfb.c:919: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
drivers/video/mxsfb.c:919: warning: function declaration isn't a prototype
make[2]: *** [drivers/video/mxsfb.o] Error 1
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/video/mxsfb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 0b2f2dd..d837d63 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -39,6 +39,7 @@
* the required value in the imx_fb_videomode structure.
*/
+#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/clk.h>
--
1.7.4.1
^ permalink raw reply related
* [PATCH] video/backlight: Remove obsolete cleanup for clientdata
From: Wolfram Sang @ 2011-08-25 10:54 UTC (permalink / raw)
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Richard Purdie, Paul Mundt, Andrew Morton,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
A few new i2c-drivers came into the kernel which clear the clientdata-pointer
on exit or error. This is obsolete meanwhile, the core will do it.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/backlight/adp8870_bl.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/adp8870_bl.c b/drivers/video/backlight/adp8870_bl.c
index 05a8832..71d90f4 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -932,7 +932,6 @@ out:
out1:
backlight_device_unregister(bl);
out2:
- i2c_set_clientdata(client, NULL);
kfree(data);
return ret;
@@ -952,7 +951,6 @@ static int __devexit adp8870_remove(struct i2c_client *client)
&adp8870_bl_attr_group);
backlight_device_unregister(data->bl);
- i2c_set_clientdata(client, NULL);
kfree(data);
return 0;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/2] video: s3c-fb: Add window positioning support
From: Ajay Kumar @ 2011-08-25 13:54 UTC (permalink / raw)
To: linux-arm-kernel
These patches are created against "for-next" branch of Kukjin Kim's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
This patch adds support for positioning of the FB windows on the LCD screen.
This patchset creates an ioctl and defines a data structure which are
specific to samsung SOCs, to hold the window position.
Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
seem to be doing window/plane positioning in their driver code.
Is it possible to have this window positioning support at a common place?
For instance, we can have a common struture and ioctl number in
include/linux/fb.h as below:
#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
struct fb_overlay_win_pos {
__u32 win_pos_x; /* x-offset of window from LCD(0,0) */
__u32 win_pos_y; /* y-offset of window from LCD(0,0) */
};
where LCD(0,0) means the first pixel of the LCD screen.
Individual drivers can have implementation for this ioctl.
To Kukjin Kim,
[PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb driver
To Paul Mundt, Florian Tobias Schandinat
[PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
arch/arm/plat-samsung/include/plat/fb.h | 14 +++++++++++
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++----
2 files changed, 46 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-fb
From: Ajay Kumar @ 2011-08-25 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314301917-9938-1-git-send-email-ajaykumar.rs@samsung.com>
This patch:
--adds a data-structure to hold the current position of windows.
--adds an ioctl number to support dynamic positioning the windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
arch/arm/plat-samsung/include/plat/fb.h | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-samsung/include/plat/fb.h
index bd79c0a..77ed75c 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -22,6 +22,18 @@
*/
#define S3C_FB_MAX_WIN (5)
+/* struct s3cfb_window_pos
+ * @win_pos_x: X-coordinate of window from the left.
+ * @win_pos_y: Y-coordinate of window from the top.
+ */
+struct s3cfb_window_pos {
+ int win_pos_x;
+ int win_pos_y;
+};
+
+/* Custom ioctl */
+#define S3CFB_WIN_POSITION _IOW('F', 1, struct s3cfb_window_pos)
+
/**
* struct s3c_fb_pd_win - per window setup data
* @win_mode: The display parameters to initialise (not for window 0)
@@ -35,6 +47,8 @@ struct s3c_fb_pd_win {
unsigned short max_bpp;
unsigned short virtual_x;
unsigned short virtual_y;
+
+ struct s3cfb_window_pos winpos;
};
/**
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
From: Ajay Kumar @ 2011-08-25 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1314301917-9938-1-git-send-email-ajaykumar.rs@samsung.com>
This patch modifies the existing s3c-fb driver to provide
flexibility to the user to reposition the framebuffer windows.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
---
drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0fda252..41179d7 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
struct fb_var_screeninfo *var = &info->var;
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
+ struct s3cfb_window_pos *winpos = &win->windata->winpos;
void __iomem *regs = sfb->regs;
void __iomem *buf = regs;
int win_no = win->index;
@@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
- data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
- var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
+ (winpos->win_pos_x + var->xres - 1)))) |
+ VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
{
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
- int ret;
+ struct s3cfb_window_pos *winpos = &win->windata->winpos;
+ int ret = 0;
u32 crtc;
+ u32 data;
switch (cmd) {
case FBIO_WAITFORVSYNC:
@@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned int cmd,
ret = s3c_fb_wait_for_vsync(sfb, crtc);
break;
+ case S3CFB_WIN_POSITION:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct s3cfb_window_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ shadow_protect_win(win, 1);
+
+ /* write 'OSD' registers to set position of the window */
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
+ writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
+
+ data = VIDOSDxB_BOTRIGHT_X(
+ s3c_fb_align_word(info->var.bits_per_pixel,
+ (winpos->win_pos_x + info->var.xres - 1)));
+ data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
+ info->var.yres - 1);
+ writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
+
+ shadow_protect_win(win, 0);
+ break;
default:
ret = -ENOTTY;
}
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
From: JinGoo Han @ 2011-08-26 0:44 UTC (permalink / raw)
To: AJAY KUMAR RAMAKRISHNA SHYMALAMMA,
linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org
Cc: FlorianSchandinat@gmx.de, lethal@linux-sh.org, Marek Szyprowski,
ben-linux@fluff.org, BANAJIT GOSWAMI
In-Reply-To: <1314301917-9938-3-git-send-email-ajaykumar.rs@samsung.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 4182 bytes --]
Hi, Ajay.
> -----Original Message-----
> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
> Sent: Friday, August 26, 2011 4:52 AM
> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org
> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
> Subject: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
> positioning
>
> This patch modifies the existing s3c-fb driver to provide
> flexibility to the user to reposition the framebuffer windows.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
> ---
> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
> 1 files changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 0fda252..41179d7 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
> struct fb_var_screeninfo *var = &info->var;
> struct s3c_fb_win *win = info->par;
> struct s3c_fb *sfb = win->parent;
> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
> void __iomem *regs = sfb->regs;
> void __iomem *buf = regs;
> int win_no = win->index;
> @@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
>
> /* write 'OSD' registers to control position of framebuffer */
>
> - data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
> writel(data, regs + VIDOSD_A(win_no, sfb->variant));
>
> - data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
> - var->xres - 1)) |
> - VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
> + data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
> + (winpos->win_pos_x + var->xres - 1)))) |
> + VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
>
> writel(data, regs + VIDOSD_B(win_no, sfb->variant));
>
> @@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info,
> unsigned int cmd,
> {
> struct s3c_fb_win *win = info->par;
> struct s3c_fb *sfb = win->parent;
> - int ret;
> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
> + int ret = 0;
> u32 crtc;
> + u32 data;
>
> switch (cmd) {
> case FBIO_WAITFORVSYNC:
> @@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info,
> unsigned int cmd,
>
> ret = s3c_fb_wait_for_vsync(sfb, crtc);
> break;
> + case S3CFB_WIN_POSITION:
> + if (copy_from_user(winpos, (u32 __user *)arg,
> + sizeof(struct s3cfb_window_pos))) {
> + ret = -EFAULT;
> + break;
> + }
> +
> + shadow_protect_win(win, 1);
> +
> + /* write 'OSD' registers to set position of the window */
> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
> + writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
> +
> + data = VIDOSDxB_BOTRIGHT_X(
> + s3c_fb_align_word(info->var.bits_per_pixel,
> + (winpos->win_pos_x + info->var.xres - 1)));
> + data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
> + info->var.yres - 1);
> + writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
> +
> + shadow_protect_win(win, 0);
> + break;
Can you move this to separate function?
In my opinion, it would be better for readability and consistency.
Also, FBIO_WAITFORVSYNC has been implemented in this way.
ret = s3c_fb_wait_for_vsync(sfb, crtc);
How about adding a function 's3c_fb_set_window_position' for this as belows?
+int s3c_fb_set_window_position(struct fb_info *info,
+ struct s3cfb_window_pos winpos)
........
+ case S3CFB_WIN_POSITION:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct s3cfb_window_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+ ret = s3c_fb_set_window_position(info, winpos);
+ break;
> default:
> ret = -ENOTTY;
> }
> --
> 1.7.0.4
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ permalink raw reply
* Re: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window positioning
From: Ajay kumar @ 2011-08-26 5:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14401983.184721314319448396.JavaMail.weblogic@epv6ml01>
Hi Jingoo,
2011/8/26 JinGoo Han <jg1.han@samsung.com>:
> Hi, Ajay.
>> -----Original Message-----
>> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
>> Sent: Friday, August 26, 2011 4:52 AM
>> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
>> arm-kernel@lists.infradead.org
>> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
>> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
>> Subject: [PATCH 2/2] video: s3c-fb: Modify s3c-fb driver to support window
>> positioning
>>
>> This patch modifies the existing s3c-fb driver to provide
>> flexibility to the user to reposition the framebuffer windows.
>>
>> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
>> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
>> ---
>> drivers/video/s3c-fb.c | 37 ++++++++++++++++++++++++++++++++-----
>> 1 files changed, 32 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
>> index 0fda252..41179d7 100644
>> --- a/drivers/video/s3c-fb.c
>> +++ b/drivers/video/s3c-fb.c
>> @@ -442,6 +442,7 @@ static int s3c_fb_set_par(struct fb_info *info)
>> struct fb_var_screeninfo *var = &info->var;
>> struct s3c_fb_win *win = info->par;
>> struct s3c_fb *sfb = win->parent;
>> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
>> void __iomem *regs = sfb->regs;
>> void __iomem *buf = regs;
>> int win_no = win->index;
>> @@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
>>
>> /* write 'OSD' registers to control position of framebuffer */
>>
>> - data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
>> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
>> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
>> writel(data, regs + VIDOSD_A(win_no, sfb->variant));
>>
>> - data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
>> - var->xres - 1)) |
>> - VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
>> + data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
>> + (winpos->win_pos_x + var->xres - 1)))) |
>> + VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
>>
>> writel(data, regs + VIDOSD_B(win_no, sfb->variant));
>>
>> @@ -999,8 +1001,10 @@ static int s3c_fb_ioctl(struct fb_info *info,
>> unsigned int cmd,
>> {
>> struct s3c_fb_win *win = info->par;
>> struct s3c_fb *sfb = win->parent;
>> - int ret;
>> + struct s3cfb_window_pos *winpos = &win->windata->winpos;
>> + int ret = 0;
>> u32 crtc;
>> + u32 data;
>>
>> switch (cmd) {
>> case FBIO_WAITFORVSYNC:
>> @@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info,
>> unsigned int cmd,
>>
>> ret = s3c_fb_wait_for_vsync(sfb, crtc);
>> break;
>> + case S3CFB_WIN_POSITION:
>> + if (copy_from_user(winpos, (u32 __user *)arg,
>> + sizeof(struct s3cfb_window_pos))) {
>> + ret = -EFAULT;
>> + break;
>> + }
>> +
>> + shadow_protect_win(win, 1);
>> +
>> + /* write 'OSD' registers to set position of the window */
>> + data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
>> + VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
>> + writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
>> +
>> + data = VIDOSDxB_BOTRIGHT_X(
>> + s3c_fb_align_word(info->var.bits_per_pixel,
>> + (winpos->win_pos_x + info->var.xres - 1)));
>> + data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
>> + info->var.yres - 1);
>> + writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
>> +
>> + shadow_protect_win(win, 0);
>> + break;
> Can you move this to separate function?
> In my opinion, it would be better for readability and consistency.
> Also, FBIO_WAITFORVSYNC has been implemented in this way.
> ret = s3c_fb_wait_for_vsync(sfb, crtc);
> How about adding a function 's3c_fb_set_window_position' for this as belows?
> +int s3c_fb_set_window_position(struct fb_info *info,
> + struct s3cfb_window_pos winpos)
Thanks for your suggestion.
I have considered it, and now I have written a separate function for this.
I will be sending it in V2 version.
> ........
> + case S3CFB_WIN_POSITION:
> + if (copy_from_user(winpos, (u32 __user *)arg,
> + sizeof(struct s3cfb_window_pos))) {
> + ret = -EFAULT;
> + break;
> + }
> + ret = s3c_fb_set_window_position(info, winpos);
> + break;
>> default:
>> ret = -ENOTTY;
>> }
>> --
>> 1.7.0.4
>
>
>
^ permalink raw reply
* RE: [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for
From: Jingoo Han @ 2011-08-26 5:56 UTC (permalink / raw)
To: AJAY KUMAR RAMAKRISHNA SHYMALAMMA
Cc: linux-samsung-soc@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, FlorianSchandinat@gmx.de,
lethal@linux-sh.org, Jingoo Han, Marek Szyprowski,
ben-linux@fluff.org, BANAJIT GOSWAMI
In-Reply-To: <1314301917-9938-2-git-send-email-ajaykumar.rs@samsung.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 2118 bytes --]
Hi, Ajay.
> -----Original Message-----
> From: Ajay Kumar [mailto:ajaykumar.rs@samsung.com]
> Sent: Friday, August 26, 2011 4:52 AM
> To: linux-samsung-soc@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org
> Cc: FlorianSchandinat@gmx.de; lethal@linux-sh.org; jg1.han@samsung.com;
> m.szyprowski@samsung.com; ben-linux@fluff.org; banajit.g@samsung.com
> Subject: [PATCH 1/2] ARM: SAMSUNG: Add Window Positioning Support for s3c-
> fb driver
>
> This patch:
> --adds a data-structure to hold the current position of windows.
> --adds an ioctl number to support dynamic positioning the windows.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Banajit Goswami <banajit.g@samsung.com>
> ---
> arch/arm/plat-samsung/include/plat/fb.h | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-
> samsung/include/plat/fb.h
> index bd79c0a..77ed75c 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -22,6 +22,18 @@
> */
> #define S3C_FB_MAX_WIN (5)
>
> +/* struct s3cfb_window_pos
> + * @win_pos_x: X-coordinate of window from the left.
> + * @win_pos_y: Y-coordinate of window from the top.
> + */
> +struct s3cfb_window_pos {
> + int win_pos_x;
> + int win_pos_y;
> +};
> +
> +/* Custom ioctl */
> +#define S3CFB_WIN_POSITION _IOW('F', 1, struct s3cfb_window_pos)
Can you change the number from 1 to 203 as follows?
+#define S3CFB_WIN_POSITION _IOW('F', 203, struct s3cfb_window_pos)
We already use this number as S3CFB_WIN_POSITION.
> +
> /**
> * struct s3c_fb_pd_win - per window setup data
> * @win_mode: The display parameters to initialise (not for window 0)
> @@ -35,6 +47,8 @@ struct s3c_fb_pd_win {
> unsigned short max_bpp;
> unsigned short virtual_x;
> unsigned short virtual_y;
> +
> + struct s3cfb_window_pos winpos;
> };
>
> /**
> --
> 1.7.0.4
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
^ 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