Re: [PATCH] video: s3c-fb: use clk_prepare_enable and clk_disable_unprepare
On 10/02/2012 11:57 PM, Thomas Abraham wrote:
Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
calls as required by common clock framework.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Applied.
Thanks,
Florian Tobias Schandinat
---
drivers/video/s3c-fb.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 52b744f..2ed7b63 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1404,7 +1404,7 @@ static int __devinit s3c_fb_probe(struct
platform_device *pdev)
return PTR_ERR(sfb-bus_clk);
}
- clk_enable(sfb-bus_clk);
+ clk_prepare_enable(sfb-bus_clk);
if (!sfb-variant.has_clksel) {
sfb-lcd_clk = devm_clk_get(dev, sclk_fimd);
@@ -1414,7 +1414,7 @@ static int __devinit s3c_fb_probe(struct
platform_device *pdev)
goto err_bus_clk;
}
- clk_enable(sfb-lcd_clk);
+ clk_prepare_enable(sfb-lcd_clk);
}
pm_runtime_enable(sfb-dev);
@@ -1504,10 +1504,10 @@ err_lcd_clk:
pm_runtime_disable(sfb-dev);
if (!sfb-variant.has_clksel)
- clk_disable(sfb-lcd_clk);
+ clk_disable_unprepare(sfb-lcd_clk);
err_bus_clk:
- clk_disable(sfb-bus_clk);
+ clk_disable_unprepare(sfb-bus_clk);
return ret;
}
@@ -1531,9 +1531,9 @@ static int __devexit s3c_fb_remove(struct
platform_device *pdev)
s3c_fb_release_win(sfb, sfb-windows[win]);
if (!sfb-variant.has_clksel)
- clk_disable(sfb-lcd_clk);
+ clk_disable_unprepare(sfb-lcd_clk);
- clk_disable(sfb-bus_clk);
+ clk_disable_unprepare(sfb-bus_clk);
pm_runtime_put_sync(sfb-dev);
pm_runtime_disable(sfb-dev);
@@ -1561,9 +1561,9 @@ static int s3c_fb_suspend(struct device *dev)
}
if (!sfb-variant.has_clksel)
- clk_disable(sfb-lcd_clk);
+ clk_disable_unprepare(sfb-lcd_clk);
- clk_disable(sfb-bus_clk);
+ clk_disable_unprepare(sfb-bus_clk);
pm_runtime_put_sync(sfb-dev);
@@ -1581,10 +1581,10 @@ static int s3c_fb_resume(struct device *dev)
pm_runtime_get_sync(sfb-dev);
- clk_enable(sfb-bus_clk);
+ clk_prepare_enable(sfb-bus_clk);
if (!sfb-variant.has_clksel)
- clk_enable(sfb-lcd_clk);
+ clk_prepare_enable(sfb-lcd_clk);
/* setup gpio and output polarity controls */
pd-setup_gpio();
@@ -1640,9 +1640,9 @@ static int s3c_fb_runtime_suspend(struct device *dev)
struct s3c_fb *sfb = platform_get_drvdata(pdev);
if (!sfb-variant.has_clksel)
- clk_disable(sfb-lcd_clk);
+ clk_disable_unprepare(sfb-lcd_clk);
- clk_disable(sfb-bus_clk);
+ clk_disable_unprepare(sfb-bus_clk);
return 0;
}
@@ -1653,10 +1653,10 @@ static int s3c_fb_runtime_resume(struct device *dev)
struct s3c_fb *sfb = platform_get_drvdata(pdev);
struct s3c_fb_platdata *pd = sfb-pdata;
- clk_enable(sfb-bus_clk);
+ clk_prepare_enable(sfb-bus_clk);
if (!sfb-variant.has_clksel)
- clk_enable(sfb-lcd_clk);
+ clk_prepare_enable(sfb-lcd_clk);
/* setup gpio and output polarity controls */
pd-setup_gpio();
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
On 08/23/2012 09:55 AM, Kukjin Kim wrote: Florian Tobias Schandinat wrote: On 08/01/2012 02:28 AM, Kukjin Kim wrote: Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. (Cc'ed Florian Tobias Schandinat) Yeah, since it's merge window, this series could be created against on mainline. And IMO, would be helpful to us if this series could be sent to upstream via samsung tree after reviewing, because this touches too many files in samsung tree and just adds include/video/samsung_fimd.h. But I'm not sure the added inclusion will be used in other file of drivers/video. If so, I can provide some topic branch can be merged into Florian's tree. Florian, how about? Using a topic branch to merge it in both trees sounds like a good plan to me. Florian, Please pull following topic branch we talked. I already merged it into my -next. git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Note, I applied Leela's V4 patches not this V2 series. Merged, just as I wrote in another thread. Took a bit longer as I was writing my thesis... Best regards, Florian Tobias Schandinat If any problems, please kindly let me know. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v3.7-for-florian Leela Krishna Amudala (2): include/video: move fimd register headers from platform to include/video include/video: Add register offsets for FIMD version 8 arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h = include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (73%) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 6/7] Samsung cleanup fimd header for v3.7
Hi, On 09/20/2012 11:59 PM, Olof Johansson wrote: On Thu, Sep 20, 2012 at 08:19:15AM +0900, Kukjin Kim wrote: Hi Arnd, Olof. This is for moving header file is related to fimd from platform to include/video. Since this touches many Samsung stuff, it is included in samsung tree and I requested to pull into Florian's tree and he already agreed. So its name is 'v3.7-for-florian'. Hi, So, it seems like there's no need to pull this through arm-soc; there are no conflicts with other patches as far as I can see, and it can just go in through Florian's tree. Florian, if you want, you can add: Acked-by: Olof Johansson o...@lixom.net on the merge you do. Works for me. I already merged it. Best regards, Florian Tobias Schandinat -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
On 08/01/2012 02:28 AM, Kukjin Kim wrote: Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. (Cc'ed Florian Tobias Schandinat) Yeah, since it's merge window, this series could be created against on mainline. And IMO, would be helpful to us if this series could be sent to upstream via samsung tree after reviewing, because this touches too many files in samsung tree and just adds include/video/samsung_fimd.h. But I'm not sure the added inclusion will be used in other file of drivers/video. If so, I can provide some topic branch can be merged into Florian's tree. Florian, how about? Using a topic branch to merge it in both trees sounds like a good plan to me. Best regards, Florian Tobias Schandinat Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Changes from version 1: - Split the patches as per Sylwester comments - Changed FIMD_V8_xxx macro to EXYNOS5_xxx Leela Krishna Amudala (5): include/video: Add samsung FIMD register header include/video: Add Exynos5 specific FIMD register offsets arm: samsung: Include the modified FIMD header file driver: Include the modified FIMD header file arm: samsung: delete frame buffer header files from platform arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h = include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (74%) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] video: s3c-fb: Rearrange the elements in platform data
On 03/24/2012 04:28 PM, Thomas Abraham wrote: Changes since v2: - Patch 3/4 is a new patch in this series. The real6410 and mini6410 boards use the display controllers window configuration data to represent video timing of two different lcd panels. Since the window configuration data should be not be used to specify timing of two different panels, this has been reworked in such a way that two instance of display controller's platform data is setup for the two supported lcd panels. Depending on the lcd panel specified using boot parameters, the corresponding platform data is registered. This maintains backward compatibility with existing functionality of supporting multiple lcd panels at runtime. Changes since v1: - Includes all changes suggested by Jingoo Han. - Reworked s3c-fb platform data in all Samsung SoC based board files. This patchset rearranges the elements in the platform data of the s3c-fb driver with the intent of adding device tree support to the driver in subsequent patches. The first patch moves the video timing information from the individual window setup data into the platform specific configuration section in the platform data. The video timing is independent of the window setup. The resolution of the window could be smaller than that of the lcd panel attached. So the video timing data is removed from window configuration data. The second patch removes the need for the 'default_win' element in the platform data. This element was used to decide whether the video data output from the controller should be enabled or disabled when the window specified by 'default_win' is enabled or disabled. With the first patch removing the need for atleast one window to be of the same resolution as that of the lcd panel, it is now possible to decide when to enable/disable the video data output based on the state of each window. If any of the window is active, the lcd data output is enabled. Otherwise, the lcd data output is disabled. Hence, the 'default_win' parameter from the platform data can be removed, which anyways cannot be specified when using device tree. The third patch reworks the display controller's platform data that was used to supply video timing information for two different panels on the mini6410 and real6410 boards. That was not the correct usage of the window data and hence reworks the runtime handling of two different lcd panels. For all the Samsung SoC based boards, the forth patch reworks the platform data of the display controller based on the changes introduced in the first two patches. This patch series is based on http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git [for-next] with all patches merged from https://github.com/schandinat/linux-2.6.git [fbdev-next] and tested one Exynos4210 based Origen board (only compile tested for other boards) Thomas Abraham (4): video: s3c-fb: move video interface timing out of window setup data video: s3c-fb: remove 'default_win' element from platform data ARM: s3c64xx: Decouple lcd type from display controller window data ARM: Samsung: Rework platform data of s3c-fb driver Applied this series. Thanks, Florian Tobias Schandinat arch/arm/mach-exynos/mach-nuri.c | 26 +++--- arch/arm/mach-exynos/mach-origen.c | 24 +++-- arch/arm/mach-exynos/mach-smdkv310.c | 28 --- arch/arm/mach-exynos/mach-universal_c210.c | 26 +++--- arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 +++--- arch/arm/mach-s3c64xx/mach-anw6410.c | 25 +++--- arch/arm/mach-s3c64xx/mach-crag6410.c | 25 +++--- arch/arm/mach-s3c64xx/mach-hmt.c | 24 +++-- arch/arm/mach-s3c64xx/mach-mini6410.c | 92 +++ arch/arm/mach-s3c64xx/mach-real6410.c | 90 +++ arch/arm/mach-s3c64xx/mach-smartq5.c | 26 +++--- arch/arm/mach-s3c64xx/mach-smartq7.c | 26 +++--- arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 +++--- arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 +++-- arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 +++-- arch/arm/mach-s5pc100/mach-smdkc100.c | 27 +++--- arch/arm/mach-s5pv210/mach-aquila.c| 36 arch/arm/mach-s5pv210/mach-goni.c | 26 +++--- arch/arm/mach-s5pv210/mach-smdkv210.c | 24 +++-- arch/arm/plat-samsung/include/plat/fb.h| 11 ++- drivers/video/s3c-fb.c | 135 +-- 21 files changed, 426 insertions(+), 345 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] include: fb: Add definiton for window positioning structure
) is always the visible part of the framebuffer. Typically that's also part of the timings as they define what is visible. With the introduction of overlays (and maybe even for some hardware anyway) it is no longer always true to have any timings at all. So on all framebuffer that do not have physical timings the timing interpretation is useless anyway (I'm thinking about adding a FB_CAP_NOTIMING) and what remains is the interpretation of xres/yres as visible screen region. And generally I can't really make my mind about adding these more complex features. On one hand it would be very nice to have fbdev supporting overlays and whatnot, but on the other hand, I can't figure out how to add them properly. I don't see it as adding new features, rather unifying what is already there for easier use. Sure it should be done in a consistent way. Best regards, Florian Tobias Schandinat [1] http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
Hi Laurent, On 09/07/2011 03:31 PM, Laurent Pinchart wrote: Hi Florian, On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote: Hi all, On 08/25/2011 07:51 PM, Ajay Kumar wrote: 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? Good point. Congratulations for figuring out that I like to standardize things. But I think your suggestion is far from being enough to be useful for userspace (which is our goal so that applications can be reused along drivers and don't need to know about individual drivers). Beside standardizing things, do you also like to take them one level higher to solve challenging issues ? I know the answer must be yes :-) The problem at hand here is something we have solved in V4L2 (theoretically only for part of it) with the media controller API, the V4L2 subdevs and their pad-level format API. In a nutshell, the media controller lets drivers model hardware as a graph of buliding blocks connected through their pads and expose that description to userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which are abstract building blocks that implement sets of standard operations. Those operations are exposed to userspace through the V4L2 subdevs pad-level format API, allowing application to configure sizes and selection rectangles at all pads in the graph. Selection rectangles can be used to configure cropping and composing, which is exactly what the window positioning API needs to do. Instead of creating a new fbdev-specific API to do the same, shouldn't we try to join forces ? Okay, thanks for the pointer. After having a look at your API I understand that it would solve the problem to discover how many windows (in this case) are there and how they can be accessed. It looks fine for this purpose, powerful enough and not too complex. So if I get it correct we still need at least a way to configure the position of the windows/overlays/sink pads similar to what Ajay proposed. Additionally a way to get and/or set the z-position of the overlays if multiple overlays overlap and set/get how the overlays work (overdraw, constant alpha, source/destination color keying). Normally I'd consider these link properties but I think implementing them as properties of the source framebuffer or sink pad would work as well. Is this correct or did I miss something? Best regards, Florian Tobias Schandinat -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 RESEND 1/6] video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata
On 09/09/2011 06:00 PM, Ajay Kumar wrote:
This patch:
-- Adds s3c_fb_driverdata for S5P64X0, which supports 3 windows.
-- Also, register s5p64x0-fb type driver_data.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Kukjin Kim kgene@samsung.com
Applied.
Thanks,
Florian Tobias Schandinat
---
drivers/video/s3c-fb.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 4aecf21..0fda252 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1859,6 +1859,30 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
},
};
+static struct s3c_fb_driverdata s3c_fb_data_s5p64x0 = {
+ .variant = {
+ .nr_windows = 3,
+ .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,
+ },
+ },
+ .win[0] = s3c_fb_data_s5p_wins[0],
+ .win[1] = s3c_fb_data_s5p_wins[1],
+ .win[2] = s3c_fb_data_s5p_wins[2],
+};
+
static struct platform_device_id s3c_fb_driver_ids[] = {
{
.name = s3c-fb,
@@ -1872,6 +1896,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
}, {
.name = s3c2443-fb,
.driver_data= (unsigned long)s3c_fb_data_s3c2443,
+ }, {
+ .name = s5p64x0-fb,
+ .driver_data= (unsigned long)s3c_fb_data_s5p64x0,
},
{},
};
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] video: s3c-fb: Add window positioning support
Hi all,
On 08/25/2011 07:51 PM, Ajay Kumar wrote:
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?
Good point. Congratulations for figuring out that I like to standardize things.
But I think your suggestion is far from being enough to be useful for userspace
(which is our goal so that applications can be reused along drivers and don't
need to know about individual drivers).
So let me at first summarize how I understand you implemented those things after
having a brief look at some of the drivers:
Windows are rectangular screen areas whose pixel data come from other locations.
The other locations are accessible via other framebuffer devices (e.g. fb1). So
in this area the data of fb1 is shown and not the data of fb0 that would be
normally shown.
So in addition to your proposed positioning I think we should also have the
following to give userspace a useful set of functionality:
- a way to discover how the screen is composited (how many windows are there,
how they are stacked and how to access those)
- a way to enable/disable windows (make them (in)visible)
- reporting and selecting how the window content can be mixed with the root
screen (overwrite, source or destination color keying)
- things like window size and color format could be handled by the usual fb API
used on the window. However there might be restrictions which cause them to be
not 100% API compatible (for example when changing the color format if the
windows are required to have the same format as the root screen)
- do we need to worry about hardware (up/down) scaling of the window content?
So is that what you need for a standardized window implementation?
Any additional things that were useful/needed in this context?
Would you consider adding support for this API in your drivers? (as
standardizing wouldn't be useful if nobody would implement it)
Best regards,
Florian Tobias Schandinat
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(-)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
