Re: [PATCH] video: exynos_dp: use clk_prepare_enable and clk_disable_unprepare
On 10/04/2012 06:45 AM, Jingoo Han wrote: > Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare > calls as required by common clock framework. > > Signed-off-by: Jingoo Han Applied. Thanks, Florian Tobias Schandinat > --- > drivers/video/exynos/exynos_dp_core.c |8 > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/video/exynos/exynos_dp_core.c > b/drivers/video/exynos/exynos_dp_core.c > index cdc1398..d55470e 100644 > --- a/drivers/video/exynos/exynos_dp_core.c > +++ b/drivers/video/exynos/exynos_dp_core.c > @@ -885,7 +885,7 @@ static int __devinit exynos_dp_probe(struct > platform_device *pdev) > return PTR_ERR(dp->clock); > } > > - clk_enable(dp->clock); > + clk_prepare_enable(dp->clock); > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > @@ -956,7 +956,7 @@ static int __devexit exynos_dp_remove(struct > platform_device *pdev) > if (pdata && pdata->phy_exit) > pdata->phy_exit(); > > - clk_disable(dp->clock); > + clk_disable_unprepare(dp->clock); > > return 0; > } > @@ -971,7 +971,7 @@ static int exynos_dp_suspend(struct device *dev) > if (pdata && pdata->phy_exit) > pdata->phy_exit(); > > - clk_disable(dp->clock); > + clk_disable_unprepare(dp->clock); > > return 0; > } > @@ -985,7 +985,7 @@ static int exynos_dp_resume(struct device *dev) > if (pdata && pdata->phy_init) > pdata->phy_init(); > > - clk_enable(dp->clock); > + clk_prepare_enable(dp->clock); > > exynos_dp_init_dp(dp); > -- 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] 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
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 , 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 > > 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 , 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 V2 RESEND] video: s3c-fb: Add support EXYNOS5 FIMD
On 03/06/2012 06:53 AM, Jingoo Han wrote: > This patch adds s3c_fb_driverdata s3c_fb_data_exynos5 for EXYNOS5 > and adds extended timing control setting. > > EXYNOS5 FIMD needs extended setting for video timing control. > Additional bits are added to VIDTCON2, VIDWxxADD2, VIDOSDxA and > VIDOSDxB registers in order to set timing value for lager resolution. > > Also, address offset of VIDTCONx registers is changed from 0x0 > to 0x2, thus variable type should be changed to int type > to handle the address offset of VIDTCONx registers for EXYNOS5 FIMD. > > Signed-off-by: Jingoo Han Applied. No need to resend when just over a week has passed. I usually try to wait a week for non-trivial patches to give others a chance to comment on it before applying. Thanks, Florian Tobias Schandinat > --- > v2: fix commit message from VIDCONx to VIDTCONx. > > arch/arm/plat-samsung/include/plat/regs-fb.h | 24 > drivers/video/s3c-fb.c | 52 +++-- > 2 files changed, 63 insertions(+), 13 deletions(-) > > diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h > b/arch/arm/plat-samsung/include/plat/regs-fb.h > index bbb16e0..9a78012 100644 > --- a/arch/arm/plat-samsung/include/plat/regs-fb.h > +++ b/arch/arm/plat-samsung/include/plat/regs-fb.h > @@ -167,15 +167,17 @@ > #define VIDTCON1_HSPW(_x)((_x) << 0) > > #define VIDTCON2 (0x18) > +#define VIDTCON2_LINEVAL_E(_x) _x) & 0x800) >> 11) > << 23) > #define VIDTCON2_LINEVAL_MASK(0x7ff << 11) > #define VIDTCON2_LINEVAL_SHIFT (11) > #define VIDTCON2_LINEVAL_LIMIT (0x7ff) > -#define VIDTCON2_LINEVAL(_x) ((_x) << 11) > +#define VIDTCON2_LINEVAL(_x) (((_x) & 0x7ff) << 11) > > +#define VIDTCON2_HOZVAL_E(_x)_x) & 0x800) >> 11) > << 22) > #define VIDTCON2_HOZVAL_MASK (0x7ff << 0) > #define VIDTCON2_HOZVAL_SHIFT(0) > #define VIDTCON2_HOZVAL_LIMIT(0x7ff) > -#define VIDTCON2_HOZVAL(_x) ((_x) << 0) > +#define VIDTCON2_HOZVAL(_x) (((_x) & 0x7ff) << 0) > > /* WINCONx */ > > @@ -231,25 +233,29 @@ > /* Local input channels (windows 0-2) */ > #define SHADOWCON_CHx_LOCAL_ENABLE(_win) (1 << (5 + (_win))) > > +#define VIDOSDxA_TOPLEFT_X_E(_x) _x) & 0x800) >> 11) << 23) > #define VIDOSDxA_TOPLEFT_X_MASK (0x7ff << 11) > #define VIDOSDxA_TOPLEFT_X_SHIFT (11) > #define VIDOSDxA_TOPLEFT_X_LIMIT (0x7ff) > -#define VIDOSDxA_TOPLEFT_X(_x) ((_x) << 11) > +#define VIDOSDxA_TOPLEFT_X(_x) (((_x) & 0x7ff) << 11) > > +#define VIDOSDxA_TOPLEFT_Y_E(_x) _x) & 0x800) >> 11) << 22) > #define VIDOSDxA_TOPLEFT_Y_MASK (0x7ff << 0) > #define VIDOSDxA_TOPLEFT_Y_SHIFT (0) > #define VIDOSDxA_TOPLEFT_Y_LIMIT (0x7ff) > -#define VIDOSDxA_TOPLEFT_Y(_x) ((_x) << 0) > +#define VIDOSDxA_TOPLEFT_Y(_x) (((_x) & 0x7ff) << 0) > > +#define VIDOSDxB_BOTRIGHT_X_E(_x)_x) & 0x800) >> 11) << 23) > #define VIDOSDxB_BOTRIGHT_X_MASK (0x7ff << 11) > #define VIDOSDxB_BOTRIGHT_X_SHIFT(11) > #define VIDOSDxB_BOTRIGHT_X_LIMIT(0x7ff) > -#define VIDOSDxB_BOTRIGHT_X(_x) ((_x) << 11) > +#define VIDOSDxB_BOTRIGHT_X(_x) (((_x) & 0x7ff) << 11) > > +#define VIDOSDxB_BOTRIGHT_Y_E(_x)_x) & 0x800) >> 11) << 22) > #define VIDOSDxB_BOTRIGHT_Y_MASK (0x7ff << 0) > #define VIDOSDxB_BOTRIGHT_Y_SHIFT(0) > #define VIDOSDxB_BOTRIGHT_Y_LIMIT(0x7ff) > -#define VIDOSDxB_BOTRIGHT_Y(_x) ((_x) << 0) > +#define VIDOSDxB_BOTRIGHT_Y(_x) (((_x) & 0x7ff) << 0) > > /* For VIDOSD[1..4]C */ > #define VIDISD14C_ALPHA0_R(_x) ((_x) << 20) > @@ -281,15 +287,17 @@ > #define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8)) > #define VIDW_BUF_SIZE(_buff) (0x100 + ((_buff) * 4)) > > +#define VIDW_BUF_SIZE_OFFSET_E(_x) _x) & 0x2000) >> 13) << 27) > #define VIDW_BUF_SIZE_OFFSET_MASK
Re: [PATCH 06/12] ARM: S3C24XX: change the ARCH_S3C2410 to ARCH_S3C24XX
Hi, On 02/15/2012 10:55 PM, Kukjin Kim wrote: > This patch changes the ARCH name to "ARCH_S3C24XX" for Samsung > S3C2410, S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443, > and S3C2450 SoCs so that we can merge the mach-xxx directories > and plat-s3c24xx dir. to just one mach-s3c24xx for them. Great. > I think this should be sent to upstream via samsung tree because > this touches many samsung stuff. Okay, feel free to do so. > Cc: Dmitry Torokhov > Cc: Richard Purdie > Cc: Chris Ball > Cc: David Woodhouse > Cc: Alessandro Zummo > Cc: Grant Likely > Cc: Greg Kroah-Hartman > Cc: Felipe Balbi > Cc: Florian Tobias Schandinat for the framebuffer (video) part: Acked-by: Florian Tobias Schandinat > Cc: Wim Van Sebroeck > Cc: Sangbeom Kim > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Russell King > Signed-off-by: Kukjin Kim > --- 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 1/3] include: fb: Add definiton for window positioning structure
the position is relative too. But if the parent is no framebuffer, should we also include the entity into the interface to allow configuring things that are nor even framebuffers? Also I think we need a z-index in case overlays overlap (might happen or?) and enforcing that all z-indexes are different for the same entity. > Of course, if we specify that a single framebuffer will ever go only to > one output, the problem disappears. > > However, even if we specify so, this will make the fbdev a bit weird: > what is x/yres after this patch? In the current fbdev x/yres is the size > of the output, and x/yres are part of video timings. After this patch > this is no longer the case: x/yres will be the size of the overlay. But > the old code will still use x/yres as part of video timings, making > things confusing. As I see it xres/yres (together with xoffset/yoffset) 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
> Acked-by: Jingoo Han
> Acked-by: Kukjin Kim
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
