[RFC PATCH] drm/exynos: Add DECON driver
Hi, Fortunately, I could get the user manual for Exynos7420. Below are my comments. Thanks, Inki Dae On 2014ë 10ì 23ì¼ 01:34, Ajay kumar wrote: > On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae wrote: >> >> Thanks for contribution. >> >> It seems reasonable that you separate device drivers into FIMD and DECON >> because many registers of them have many different offsets and fields. >> However, there may be a good solution that we can combine common sets of >> these drivers later. > Yes, this is the main reason behind sending this as RFC patch. > I want to know what's the best way to do this. > FIMD, 5433 DECON and Exynos7 DECON - all are different. > Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). > So, even I am not sure how the driver layouts should be! Please, make sure Exynos SoC name, Exynos7410 or Exynos7420. In my understanding, Exynos7 doesn't mean one real SoC. > >> Below are my comments. >> >> Thanks, >> Inki Dae >> >> On 2014ë 10ì 10ì¼ 21:48, Ajay Kumar wrote: >>> This series is based on exynos-drm-next branch of Inki Dae's tree at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>> >>> DECON(Display and Enhancement Controller) is the new IP >>> in exynos7 SOC for generating video signals using pixel data. >> >> DECON was used since Exynos5430. And is Exynos5433 different from >> Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? > Yes, Exynos5433 DECON is very much different than Exynos7 DECON. Do not use Exynos7 word and use Exynos7410 or Exynos7420 instead. > I will see how manual can be arranged. > >>> >>> DECON driver can be used to drive 2 different interfaces on Exynos7: >>> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) >>> >>> The existing FIMD driver code was used as a template to create >>> DECON driver. Only DECON-INT is supported as of now, and >>> DECON-EXT support will be added later. >>> >>> Signed-off-by: Akshu Agrawal >>> Signed-off-by: Ajay Kumar >>> --- >>> .../devicetree/bindings/video/exynos-decon.txt | 68 ++ >>> drivers/gpu/drm/exynos/Kconfig | 11 +- >>> drivers/gpu/drm/exynos/Makefile|1 + >>> drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 >> >>> drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- >>> drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + >>> include/video/samsung_decon.h | 346 +++ >>> 7 files changed, 1537 insertions(+), 3 deletions(-) >>> create mode 100644 >> Documentation/devicetree/bindings/video/exynos-decon.txt >>> create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c >>> create mode 100644 include/video/samsung_decon.h >>> >>> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt >> b/Documentation/devicetree/bindings/video/exynos-decon.txt >>> new file mode 100644 >>> index 000..e865650 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt >>> @@ -0,0 +1,68 @@ >>> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) >>> + >>> +DECON (Display and Enhancement Controller) is the Display Controller >> for the >>> +Exynos7 series of SoCs which transfers the image data from a video memory >>> +buffer to an external LCD interface. >>> + >>> +Required properties: >>> +- compatible: value should be "samsung,exynos7-decon"; >> >> If exynos5433 was just renamed to exynos7 then, it should be one of the >> following: >> (a) "samsung,exynos5430-decon" for Display and enhancement controller >> IP for Exynos5430 >> (b) "samsung,exynos7" for Display and enhancement controller IP for >> Exynos7 >> >> Or, >> (a) "samsung,exynos5430-decon" for Display and enhancement controller >> IP for Exynos5430 >> >> (b) "samsung,exynos5433-decon" for Display and enhancement controller >> IP for Exynos5433 >> (c) "samsung,exynos7" for Display and enhancement controller IP for >> Exynos7 > Eventually, we will end up here. > >> >>> + >>> +- reg: physical base address and length of the DECON registers set. >>> + >>> +- interrupt-parent: should be the phandle of the decon controller's >>> + parent interrup
[PATCH] drm/exynos: remove ifdeferry from initialization code
On 2014ë
10ì 30ì¼ 22:13, Andrzej Hajda wrote:
> The patch replaces separate calls to driver (de)registration by
> loops over the array of drivers. As a result it significantly
> decreases number of ifdefs. Additionally it moves device registration
> related ifdefs to header file.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki,
>
> Rebased on the latest exynos-drm-next.
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 170
> +++-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 25 +++--
> 2 files changed, 48 insertions(+), 147 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index c57466e..fe250e4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -550,74 +550,54 @@ static const struct component_master_ops exynos_drm_ops
> = {
> .unbind = exynos_drm_unbind,
> };
>
> -static int exynos_drm_platform_probe(struct platform_device *pdev)
> -{
> - struct component_match *match;
> - int ret;
> -
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> - exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
> -
> +static struct platform_driver * const exynos_drm_drivers[] = {
> #ifdef CONFIG_DRM_EXYNOS_FIMD
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - return ret;
> + _driver,
> #endif
> -
> #ifdef CONFIG_DRM_EXYNOS_DP
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_fimd_drv;
> + _driver,
> #endif
> -
> #ifdef CONFIG_DRM_EXYNOS_DSI
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_dp_drv;
> + _driver,
> #endif
> -
> #ifdef CONFIG_DRM_EXYNOS_HDMI
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_dsi_drv;
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_mixer_drv;
> + _driver,
> + _driver,
> #endif
> -
> #ifdef CONFIG_DRM_EXYNOS_G2D
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_hdmi_drv;
> + _driver,
> #endif
> -
> #ifdef CONFIG_DRM_EXYNOS_FIMC
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_g2d_drv;
> + _driver,
> #endif
> -
> #ifdef CONFIG_DRM_EXYNOS_ROTATOR
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_fimc_drv;
> + _driver,
> #endif
> -
> #ifdef CONFIG_DRM_EXYNOS_GSC
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_rotator_drv;
> + _driver,
> #endif
> -
> #ifdef CONFIG_DRM_EXYNOS_IPP
> - ret = platform_driver_register(_driver);
> - if (ret < 0)
> - goto err_unregister_gsc_drv;
> + _driver,
> +#endif
> +};
> +
> +static int exynos_drm_platform_probe(struct platform_device *pdev)
> +{
> + struct component_match *match;
> + int ret, i;
> +
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
> +
> + for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
> + ret = platform_driver_register(exynos_drm_drivers[i]);
> + if (ret < 0)
> + goto err_unregister_drivers;
> + }
>
> ret = exynos_platform_device_ipp_register();
> if (ret < 0)
> - goto err_unregister_ipp_drv;
> -#endif
> + goto err_unregister_drivers;
>
> match = exynos_drm_match_add(>dev);
> if (IS_ERR(match)) {
> @@ -633,96 +613,24 @@ static int exynos_drm_platform_probe(struct
> platform_device *pdev)
> return ret;
>
> err_unregister_resources:
> -
> -#ifdef CONFIG_DRM_EXYNOS_IPP
> exynos_platform_device_ipp_unregister();
> -err_unregister_ipp_drv:
> - platform_driver_unregister(_driver);
> -err_unregister_gsc_drv:
> -#endif
>
> -#ifdef CONFIG_DRM_EXYNOS_GSC
> - platform_driver_unregister(_driver);
> -err_unregister_rotator_drv:
> -#endif
> +err_unregister_drivers:
> + while (--i >= 0)
> + platform_driver_unregister(exynos_drm_drivers[i]);
>
> -#ifdef CONFIG_DRM_EXYNOS_ROTATOR
> - platform_driver_unregister(_driver);
[PATCH] drm/exynos: remove ifdeferry from initialization code
On 2014ë
10ì 30ì¼ 21:36, Andrzej Hajda wrote:
> On 09/10/2014 01:53 PM, Andrzej Hajda wrote:
>> The patch replaces separate calls to driver (de)registration by
>> loops over the array of drivers. As a result it significantly
>> decreases number of ifdefs. Additionally it moves device registration
>> related ifdefs to header file.
>>
>> Signed-off-by: Andrzej Hajda
>
> ping
>
Oops, this is one of them I missed. Sorry for this. Can you rebase this
patch on top of exynos-drm-next?. I just had a setup to exynos-drm-next.
Thanks,
Inki Dae
> Regards
> Andrzej
>
>> ---
>> Hi Inki,
>>
>> During testing your component match support patch [1] I have prepared patch
>> removing most ifdefs from exynos_drm_drv.c. It is based on your patch, but
>> I can rebase it if necessary.
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37031
>>
>> Regards
>> Andrzej
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 170
>> +++-
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 25 +++--
>> 2 files changed, 48 insertions(+), 147 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index b2c710a..a660e46 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -553,74 +553,54 @@ static const struct component_master_ops
>> exynos_drm_ops = {
>> .unbind = exynos_drm_unbind,
>> };
>>
>> -static int exynos_drm_platform_probe(struct platform_device *pdev)
>> -{
>> -struct component_match *match;
>> -int ret;
>> -
>> -pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> -exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>> -
>> +static struct platform_driver * const exynos_drm_drivers[] = {
>> #ifdef CONFIG_DRM_EXYNOS_FIMD
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -return ret;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_DP
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_fimd_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_DSI
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_dp_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_HDMI
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_dsi_drv;
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_mixer_drv;
>> +_driver,
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_G2D
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_hdmi_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_FIMC
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_g2d_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_ROTATOR
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_fimc_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_GSC
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_rotator_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_IPP
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_gsc_drv;
>> +_driver,
>> +#endif
>> +};
>> +
>> +static int exynos_drm_platform_probe(struct platform_device *pdev)
>> +{
>> +struct component_match *match;
>> +int ret, i;
>> +
>> +pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>> +
>> +for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
>> +ret = platform_driver_register(exynos_drm_drivers[i]);
>> +if (ret < 0)
>> +goto err_unregister_drivers;
>> +}
>>
>> ret = exynos_platform_device_ipp_register();
>> if (ret < 0)
>> -goto e
[PATCH 0/4] drm/exynos/dsi: remove global display variable
On 2014ë 10ì 30ì¼ 21:39, Andrzej Hajda wrote: > On 10/07/2014 02:01 PM, Andrzej Hajda wrote: >> Hi Inki, >> >> Many Exynos DRM drivers uses global variables to represent associated devices >> in Exynos DRM internal framework. It is quite confusing, it adds data >> duplication >> and finally it does not allow to handle more than one device in system. >> It seems better to embed such structures in private context of the device. > > Gently ping. This patch series already is in exynos-drm-next-todo branch. I will move it to exynos-drm-next after checking. Thanks, Inki Dae > > Regards > Andrzej > >> >> The patchset is based on exynos_drm_next plus my patch [1]: >> 'drm/exynos: remove explicit encoder/connector de-initialization'. >> >> If the patchset is OK for you I can prepare similar patches for other Exynos >> DRM components. >> >> [1]: https://lkml.org/lkml/2014/9/22/148 >> >> Regards >> Andrzej >> >> >> Andrzej Hajda (4): >> drm/exynos/dsi: remove global variable exynos_dsi_display >> drm/exynos/dsi: simplify device pointer evaluation >> drm/exynos/dsi: remove redundant encoder field >> drm/exynos/dsi: stop using display->ctx pointer >> >> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 96 >> - >> 1 file changed, 47 insertions(+), 49 deletions(-) >> > >
[PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy
Sorry for late. I missed this patch a little bit for long time.
On 2014ë
09ì 15ì¼ 22:13, Vivek Gautam wrote:
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.
>
> Signed-off-by: Vivek Gautam
> Cc: Jingoo Han
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 58
> +++
> drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
> 2 files changed, 13 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 4f3c7eb..5ffc1b2 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct
> exynos_drm_display *display,
>
> static void exynos_dp_phy_init(struct exynos_dp_device *dp)
> {
> - if (dp->phy) {
> + if (dp->phy)
> phy_power_on(dp->phy);
> - } else if (dp->phy_addr) {
> - u32 reg;
> -
> - reg = __raw_readl(dp->phy_addr);
> - reg |= dp->enable_mask;
> - __raw_writel(reg, dp->phy_addr);
> - }
> }
>
> static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> {
> - if (dp->phy) {
> + if (dp->phy)
> phy_power_off(dp->phy);
> - } else if (dp->phy_addr) {
> - u32 reg;
> -
> - reg = __raw_readl(dp->phy_addr);
> - reg &= ~(dp->enable_mask);
> - __raw_writel(reg, dp->phy_addr);
> - }
> }
>
> static void exynos_dp_poweron(struct exynos_drm_display *display)
> @@ -1210,39 +1196,21 @@ static struct video_info
> *exynos_dp_dt_parse_pdata(struct device *dev)
>
> static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> {
> - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> - u32 phy_base;
> int ret = 0;
>
> - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> - if (!dp_phy_node) {
> - dp->phy = devm_phy_get(dp->dev, "dp");
> - return PTR_ERR_OR_ZERO(dp->phy);
> - }
> -
> - if (of_property_read_u32(dp_phy_node, "reg", _base)) {
> - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> - ret = -EINVAL;
> - goto err;
> - }
> -
> - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> - >enable_mask)) {
> - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> - ret = -EINVAL;
> - goto err;
> - }
> -
> - dp->phy_addr = ioremap(phy_base, SZ_4);
> - if (!dp->phy_addr) {
> - dev_err(dp->dev, "failed to ioremap dp-phy\n");
> - ret = -ENOMEM;
> - goto err;
> + dp->phy = devm_phy_get(dp->dev, "dp");
> + if (IS_ERR(dp->phy)) {
> + ret = PTR_ERR(dp->phy);
> + if (ret == -ENOSYS || ret == -ENODEV) {
> + dp->phy = NULL;
> + } else if (ret == -EPROBE_DEFER) {
> + return ret;
> + } else {
WARNING: else is not generally useful after a break or return
#146: FILE: drivers/gpu/drm/exynos/exynos_dp_core.c:1208:
+ return ret;
+ } else {
How about just returning ret like below?
if (IS_ERR(dp->phy)) {
dev_err(dp->dev, "no DP phy configured\n");
return PTR_ERR(ret);
}
And then you can handle the error at probe function properly.
Thanks,
Inki Dae
> + dev_err(dp->dev, "no DP phy configured\n");
> + return ret;
> + }
> }
>
> -err:
> - of_node_put(dp_phy_node);
> -
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h
> b/drivers/gpu/drm/exynos/exynos_dp_core.h
> index a1aee69..6426201 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
> @@ -153,8 +153,6 @@ struct exynos_dp_device {
> struct clk *clock;
> unsigned intirq;
> void __iomem*reg_base;
> - void __iomem*phy_addr;
> - unsigned intenable_mask;
>
> struct video_info *video_info;
> struct link_train link_train;
>
[RFC PATCH] drm/exynos: Add DECON driver
On 2014? 10? 23? 01:34, Ajay kumar wrote: > On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae wrote: >> >> Thanks for contribution. >> >> It seems reasonable that you separate device drivers into FIMD and DECON >> because many registers of them have many different offsets and fields. >> However, there may be a good solution that we can combine common sets of >> these drivers later. > Yes, this is the main reason behind sending this as RFC patch. > I want to know what's the best way to do this. > FIMD, 5433 DECON and Exynos7 DECON - all are different. > Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). > So, even I am not sure how the driver layouts should be! > >> Below are my comments. >> >> Thanks, >> Inki Dae >> >> On 2014? 10? 10? 21:48, Ajay Kumar wrote: >>> This series is based on exynos-drm-next branch of Inki Dae's tree at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>> >>> DECON(Display and Enhancement Controller) is the new IP >>> in exynos7 SOC for generating video signals using pixel data. >> >> DECON was used since Exynos5430. And is Exynos5433 different from >> Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? > Yes, Exynos5433 DECON is very much different than Exynos7 DECON. > I will see how manual can be arranged. > Sorry but I couldn't continue to review without Exynos7 user manual. I hope that I could get it ASAP. >>> >>> DECON driver can be used to drive 2 different interfaces on Exynos7: >>> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) >>> >>> The existing FIMD driver code was used as a template to create >>> DECON driver. Only DECON-INT is supported as of now, and >>> DECON-EXT support will be added later. >>> >>> Signed-off-by: Akshu Agrawal >>> Signed-off-by: Ajay Kumar >>> --- >>> .../devicetree/bindings/video/exynos-decon.txt | 68 ++ >>> drivers/gpu/drm/exynos/Kconfig | 11 +- >>> drivers/gpu/drm/exynos/Makefile|1 + >>> drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 >> >>> drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- >>> drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + >>> include/video/samsung_decon.h | 346 +++ >>> 7 files changed, 1537 insertions(+), 3 deletions(-) >>> create mode 100644 >> Documentation/devicetree/bindings/video/exynos-decon.txt >>> create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c >>> create mode 100644 include/video/samsung_decon.h >>> >>> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt >> b/Documentation/devicetree/bindings/video/exynos-decon.txt >>> new file mode 100644 >>> index 000..e865650 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt >>> @@ -0,0 +1,68 @@ >>> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) >>> + >>> +DECON (Display and Enhancement Controller) is the Display Controller >> for the >>> +Exynos7 series of SoCs which transfers the image data from a video memory >>> +buffer to an external LCD interface. >>> + >>> +Required properties: >>> +- compatible: value should be "samsung,exynos7-decon"; >> >> If exynos5433 was just renamed to exynos7 then, it should be one of the >> following: >> (a) "samsung,exynos5430-decon" for Display and enhancement controller >> IP for Exynos5430 >> (b) "samsung,exynos7" for Display and enhancement controller IP for >> Exynos7 >> >> Or, >> (a) "samsung,exynos5430-decon" for Display and enhancement controller >> IP for Exynos5430 >> >> (b) "samsung,exynos5433-decon" for Display and enhancement controller >> IP for Exynos5433 >> (c) "samsung,exynos7" for Display and enhancement controller IP for >> Exynos7 > Eventually, we will end up here. > >> >>> + >>> +- reg: physical base address and length of the DECON registers set. >>> + >>> +- interrupt-parent: should be the phandle of the decon controller's >>> + parent interrupt controller. >>> + >>> +- interrupts: should contain a list of all DECON IP block interrupts >> in the >>> + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt
[RFC PATCH] drm/exynos: Add DECON driver
Thanks for contribution. It seems reasonable that you separate device drivers into FIMD and DECON because many registers of them have many different offsets and fields. However, there may be a good solution that we can combine common sets of these drivers later. Below are my comments. Thanks, Inki Dae On 2014? 10? 10? 21:48, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > DECON(Display and Enhancement Controller) is the new IP > in exynos7 SOC for generating video signals using pixel data. DECON was used since Exynos5430. And is Exynos5433 different from Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? > > DECON driver can be used to drive 2 different interfaces on Exynos7: > DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) > > The existing FIMD driver code was used as a template to create > DECON driver. Only DECON-INT is supported as of now, and > DECON-EXT support will be added later. > > Signed-off-by: Akshu Agrawal > Signed-off-by: Ajay Kumar > --- > .../devicetree/bindings/video/exynos-decon.txt | 68 ++ > drivers/gpu/drm/exynos/Kconfig | 11 +- > drivers/gpu/drm/exynos/Makefile|1 + > drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 > drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- > drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + > include/video/samsung_decon.h | 346 +++ > 7 files changed, 1537 insertions(+), 3 deletions(-) > create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt > create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c > create mode 100644 include/video/samsung_decon.h > > diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt b/Documentation/devicetree/bindings/video/exynos-decon.txt > new file mode 100644 > index 000..e865650 > --- /dev/null > +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt > @@ -0,0 +1,68 @@ > +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) > + > +DECON (Display and Enhancement Controller) is the Display Controller for the > +Exynos7 series of SoCs which transfers the image data from a video memory > +buffer to an external LCD interface. > + > +Required properties: > +- compatible: value should be "samsung,exynos7-decon"; If exynos5433 was just renamed to exynos7 then, it should be one of the following: (a) "samsung,exynos5430-decon" for Display and enhancement controller IP for Exynos5430 (b) "samsung,exynos7" for Display and enhancement controller IP for Exynos7 Or, (a) "samsung,exynos5430-decon" for Display and enhancement controller IP for Exynos5430 (b) "samsung,exynos5433-decon" for Display and enhancement controller IP for Exynos5433 (c) "samsung,exynos7" for Display and enhancement controller IP for Exynos7 > + > +- reg: physical base address and length of the DECON registers set. > + > +- interrupt-parent: should be the phandle of the decon controller's > + parent interrupt controller. > + > +- interrupts: should contain a list of all DECON IP block interrupts in the > + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier > + format depends on the interrupt controller used. > + > +- interrupt-names: should contain the interrupt names: "fifo", "vsync", > + "lcd_sys", in the same order as they were listed in the interrupts > +property. > + > +- pinctrl-0: pin control group to be used for this controller. > + > +- pinctrl-names: must contain a "default" entry. > + > +- clocks: must include clock specifiers corresponding to entries in the > + clock-names property. > + > +- clock-names: list of clock names sorted in the same order as the clocks > + property. Must contain "pclk_decon0", "aclk_decon0", > +"decon0_eclk", "decon0_vclk", "sclk_dsd", aclk_lh_disp0", > +"aclk_disp", "aclk_lh_disp1". Should DECON driver really control above all clocks? I think it's enough that DECON driver controls only lcd and bus clocks, and others could be configured by boot-loader or by calling clk_set_rate. > + > +Optional Properties: > +- samsung,power-domain: a phandle to DECON power domain node. You are missing many properties, samsung,invert-vden samsung,invert-vclk display-timings ... refer to below document, Document
[PATCH] drm/exynos: fix vblank handling during dpms off
On 2014? 10? 10? 21:39, Andrzej Hajda wrote:
> On 10/02/2014 12:52 PM, Inki Dae wrote:
>> On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
>>>> The patch disables vblanks during dpms off only if pagefilp has
>>>> not been finished. It also replaces drm_vblank_off with
>>>> drm_crtc_vblank_put.
>>>> It fixes issue with page_flip ioctl not being able to acquire vblank
>>>> counter.
>>> This problem isn't related with pageflip, it just causes from
>>> 7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
>>> drm_vblank_get() after drm_vblank_off()).
>>>
>>> We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
>>> after the commit .
>>>
>>> How about below patch?
>> Thanks you Joonyoung and Andrzej,
>>
>> drm_vblank_on/off() are legacy api so it would be better to use
>> drm_vblank_crtc_on/off functions instead.
>>
>> And drm_vblank_crtc_off() makes sure that the latest vblank frame count
>> is stored and restored by drm_vblank_crtc_on() again. So my opinion is,
>>
>> static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
>> {
>> [snip]
>>
>> if (mode > DRM_MODE_DPMS_ON) {
>> /* wait for the completion of page flip. */
>> if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
>> !atomic_read(_crtc->pending_flip),
>> HZ/20))
>> atomic_set(_crtc->pending_flip, 0);
>> drm_crtc_vblank_off(crtc); //<- store the latest
>> vblank frame count.
>> } else {
>> drm_crtc_vblank_on(crtc); //<- restore the vblank
>> frame count.
>> }
>>
>> [snip]
>> }
>>
>>
>> Tested and worked well with above patch. How about it?
>>
>>
>
> drm_crtc_vblank_on should be called after dpms on, otherwise it can fail
> enabling vblank. I have provided
> full explanation in my other email [1].
> You can modify your patch or just use the one provided in [1].
I will just merge your patch set after review and test. :)
Thanks,
Inki Dae
>
> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/116152
>
> Regards
> Andrzej
>
>
[PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy
On 2014? 10? 08? 11:57, Vivek Gautam wrote:
> Hi,
>
>
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam
> wrote:
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>>
>> Signed-off-by: Vivek Gautam
>> Cc: Jingoo Han
>> ---
>
> Is someone taking care of this patch ? We already have got the corresponsding
> dp-phy patch merged, so we should also get this patch in.
>
Can anyone give me tested-by after test? I cannot test this module
because I have no any board equipped with dp panel.
Jingoo or other?
Thanks,
Inki Dae
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 58
>> +++
>> drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>> 2 files changed, 13 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4f3c7eb..5ffc1b2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct
>> exynos_drm_display *display,
>>
>> static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>> {
>> - if (dp->phy) {
>> + if (dp->phy)
>> phy_power_on(dp->phy);
>> - } else if (dp->phy_addr) {
>> - u32 reg;
>> -
>> - reg = __raw_readl(dp->phy_addr);
>> - reg |= dp->enable_mask;
>> - __raw_writel(reg, dp->phy_addr);
>> - }
>> }
>>
>> static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>> {
>> - if (dp->phy) {
>> + if (dp->phy)
>> phy_power_off(dp->phy);
>> - } else if (dp->phy_addr) {
>> - u32 reg;
>> -
>> - reg = __raw_readl(dp->phy_addr);
>> - reg &= ~(dp->enable_mask);
>> - __raw_writel(reg, dp->phy_addr);
>> - }
>> }
>>
>> static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1210,39 +1196,21 @@ static struct video_info
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>> static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>> {
>> - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> - u32 phy_base;
>> int ret = 0;
>>
>> - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> - if (!dp_phy_node) {
>> - dp->phy = devm_phy_get(dp->dev, "dp");
>> - return PTR_ERR_OR_ZERO(dp->phy);
>> - }
>> -
>> - if (of_property_read_u32(dp_phy_node, "reg", _base)) {
>> - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> - ret = -EINVAL;
>> - goto err;
>> - }
>> -
>> - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> - >enable_mask)) {
>> - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> - ret = -EINVAL;
>> - goto err;
>> - }
>> -
>> - dp->phy_addr = ioremap(phy_base, SZ_4);
>> - if (!dp->phy_addr) {
>> - dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> - ret = -ENOMEM;
>> - goto err;
>> + dp->phy = devm_phy_get(dp->dev, "dp");
>> + if (IS_ERR(dp->phy)) {
>> + ret = PTR_ERR(dp->phy);
>> + if (ret == -ENOSYS || ret == -ENODEV) {
>> + dp->phy = NULL;
>> + } else if (ret == -EPROBE_DEFER) {
>> + return ret;
>> + } else {
>> + dev_err(dp->dev, "no DP phy configured\n");
>> + return ret;
>> + }
>> }
>>
>> -err:
>> - of_node_put(dp_phy_node);
>> -
>> return ret;
>> }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h
>> b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> index a1aee69..6426201 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>> struct clk *clock;
>> unsigned intirq;
>> void __iomem*reg_base;
>> - void __iomem*phy_addr;
>> - unsigned intenable_mask;
>>
>> struct video_info *video_info;
>> struct link_train link_train;
>> --
>> 1.7.10.4
>>
>
>
>
[PATCH] drm/exynos: init vblank with real number of crtcs
On 2014? 10? 08? 00:28, Inki Dae wrote: > > Sorry for late. > > On 2014? 10? 07? 21:27, Andrzej Hajda wrote: >> Hi Inki, >> >> Gently ping. >> >> Andrzej >> >> >> On 09/19/2014 02:57 PM, Andrzej Hajda wrote: >>> Initialization of vblank with MAX_CRTC caused attempts >>> to disabling vblanks for non-existing crtcs in case >>> drm used fewer crtcs. The patch fixes it. > > Nice catch~ This patch also resolves unbind issue. When exynos driver is > unbound, disable_vblank callback is called as dev->num_crtcs so if the > number of probed crtc drivers is different from the one of enabled crtc Oops, s/the one of enabled crtc drivers/MAX_CRTC > drivers then it could attempt to disabling vblank for non-existing crtc, > which in turn, null pointer access occurs. > > Thanks, > Inki Dae > >>> >>> Signed-off-by: Andrzej Hajda >>> --- >>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +- >>> 1 file changed, 9 insertions(+), 9 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> index 9b00e4e..dc4affd 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c >>> @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, >>> unsigned long flags) >>> /* init kms poll for handling hpd */ >>> drm_kms_helper_poll_init(dev); >>> >>> - ret = drm_vblank_init(dev, MAX_CRTC); >>> - if (ret) >>> - goto err_mode_config_cleanup; >>> - >>> /* setup possible_clones. */ >>> exynos_drm_encoder_setup(dev); >>> >>> @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, >>> unsigned long flags) >>> /* Try to bind all sub drivers. */ >>> ret = component_bind_all(dev->dev, dev); >>> if (ret) >>> - goto err_cleanup_vblank; >>> + goto err_mode_config_cleanup; >>> + >>> + ret = drm_vblank_init(dev, dev->mode_config.num_crtc); >>> + if (ret) >>> + goto err_unbind_all; >>> >>> /* Probe non kms sub drivers and virtual display driver. */ >>> ret = exynos_drm_device_subdrv_probe(dev); >>> if (ret) >>> - goto err_unbind_all; >>> + goto err_cleanup_vblank; >>> >>> /* force connectors detection */ >>> drm_helper_hpd_irq_event(dev); >>> >>> return 0; >>> >>> -err_unbind_all: >>> - component_unbind_all(dev->dev, dev); >>> err_cleanup_vblank: >>> drm_vblank_cleanup(dev); >>> +err_unbind_all: >>> + component_unbind_all(dev->dev, dev); >>> err_mode_config_cleanup: >>> drm_mode_config_cleanup(dev); >>> drm_release_iommu_mapping(dev); >>> @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev) >>> exynos_drm_fbdev_fini(dev); >>> drm_kms_helper_poll_fini(dev); >>> >>> - component_unbind_all(dev->dev, dev); >>> drm_vblank_cleanup(dev); >>> + component_unbind_all(dev->dev, dev); >>> drm_mode_config_cleanup(dev); >>> drm_release_iommu_mapping(dev); >>> >>> >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH] drm/exynos: init vblank with real number of crtcs
Sorry for late. On 2014? 10? 07? 21:27, Andrzej Hajda wrote: > Hi Inki, > > Gently ping. > > Andrzej > > > On 09/19/2014 02:57 PM, Andrzej Hajda wrote: >> Initialization of vblank with MAX_CRTC caused attempts >> to disabling vblanks for non-existing crtcs in case >> drm used fewer crtcs. The patch fixes it. Nice catch~ This patch also resolves unbind issue. When exynos driver is unbound, disable_vblank callback is called as dev->num_crtcs so if the number of probed crtc drivers is different from the one of enabled crtc drivers then it could attempt to disabling vblank for non-existing crtc, which in turn, null pointer access occurs. Thanks, Inki Dae >> >> Signed-off-by: Andrzej Hajda >> --- >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +- >> 1 file changed, 9 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c >> index 9b00e4e..dc4affd 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c >> @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, >> unsigned long flags) >> /* init kms poll for handling hpd */ >> drm_kms_helper_poll_init(dev); >> >> -ret = drm_vblank_init(dev, MAX_CRTC); >> -if (ret) >> -goto err_mode_config_cleanup; >> - >> /* setup possible_clones. */ >> exynos_drm_encoder_setup(dev); >> >> @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, >> unsigned long flags) >> /* Try to bind all sub drivers. */ >> ret = component_bind_all(dev->dev, dev); >> if (ret) >> -goto err_cleanup_vblank; >> +goto err_mode_config_cleanup; >> + >> +ret = drm_vblank_init(dev, dev->mode_config.num_crtc); >> +if (ret) >> +goto err_unbind_all; >> >> /* Probe non kms sub drivers and virtual display driver. */ >> ret = exynos_drm_device_subdrv_probe(dev); >> if (ret) >> -goto err_unbind_all; >> +goto err_cleanup_vblank; >> >> /* force connectors detection */ >> drm_helper_hpd_irq_event(dev); >> >> return 0; >> >> -err_unbind_all: >> -component_unbind_all(dev->dev, dev); >> err_cleanup_vblank: >> drm_vblank_cleanup(dev); >> +err_unbind_all: >> +component_unbind_all(dev->dev, dev); >> err_mode_config_cleanup: >> drm_mode_config_cleanup(dev); >> drm_release_iommu_mapping(dev); >> @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev) >> exynos_drm_fbdev_fini(dev); >> drm_kms_helper_poll_fini(dev); >> >> -component_unbind_all(dev->dev, dev); >> drm_vblank_cleanup(dev); >> +component_unbind_all(dev->dev, dev); >> drm_mode_config_cleanup(dev); >> drm_release_iommu_mapping(dev); >> >> > >
[PATCH] drm/exynos: vidi: fix build warning
encoder object isn't used anymore so remove it.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 9395e85..50faf91 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -630,7 +630,6 @@ static int vidi_remove(struct platform_device *pdev)
{
struct exynos_drm_manager *mgr = platform_get_drvdata(pdev);
struct vidi_context *ctx = mgr->ctx;
- struct drm_encoder *encoder = ctx->encoder;
if (ctx->raw_edid != (struct edid *)fake_edid_info) {
kfree(ctx->raw_edid);
--
1.7.9.5
[PATCH] drm/exynos: fix vblank handling during dpms off
On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
> Hi Andrzej,
>
> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
>> The patch disables vblanks during dpms off only if pagefilp has
>> not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
>> It fixes issue with page_flip ioctl not being able to acquire vblank counter.
>
> This problem isn't related with pageflip, it just causes from
> 7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
> drm_vblank_get() after drm_vblank_off()).
>
> We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
> after the commit .
>
> How about below patch?
Thanks you Joonyoung and Andrzej,
drm_vblank_on/off() are legacy api so it would be better to use
drm_vblank_crtc_on/off functions instead.
And drm_vblank_crtc_off() makes sure that the latest vblank frame count
is stored and restored by drm_vblank_crtc_on() again. So my opinion is,
static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
{
[snip]
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
!atomic_read(_crtc->pending_flip),
HZ/20))
atomic_set(_crtc->pending_flip, 0);
drm_crtc_vblank_off(crtc); //<- store the latest
vblank frame count.
} else {
drm_crtc_vblank_on(crtc); //<- restore the vblank
frame count.
}
[snip]
}
Tested and worked well with above patch. How about it?
Thanks,
Inki Dae
>
>>From 6de01473746af225c688ee430123001d57d9af2a Mon Sep 17 00:00:00 2001
> From: Joonyoung Shim
> Date: Thu, 2 Oct 2014 17:48:27 +0900
> Subject: [PATCH] drm/exynos: use drm_vblank_on()
>
> We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
> after the commit 7ffd7a68511c ("drm: Always reject drm_vblank_get()
> after drm_vblank_off()"). If not, drm_vblank_get() will be failed
> always after drm_vblank_off().
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 8e38e9f..dfa209a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -71,7 +71,6 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
> mode)
> !atomic_read(_crtc->pending_flip),
> HZ/20))
> atomic_set(_crtc->pending_flip, 0);
> - drm_vblank_off(crtc->dev, exynos_crtc->pipe);
> }
>
> if (manager->ops->dpms)
> @@ -90,6 +89,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> struct exynos_drm_manager *manager = exynos_crtc->manager;
>
> + drm_vblank_on(crtc->dev, exynos_crtc->pipe);
> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>
> exynos_plane_commit(crtc->primary);
> @@ -177,10 +177,12 @@ static int exynos_drm_crtc_mode_set_base(struct
> drm_crtc *crtc, int x, int y,
>
> static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
> {
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> struct drm_plane *plane;
> int ret;
>
> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
> + drm_vblank_off(crtc->dev, exynos_crtc->pipe);
>
> drm_for_each_legacy_plane(plane, >dev->mode_config.plane_list) {
> if (plane->crtc != crtc)
>
[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl
On 2014? 10? 02? 08:47, Joonyoung Shim wrote: > Hi Tomasz, > > On 10/02/2014 12:13 AM, Tomasz Figa wrote: >> Hi Inki, >> >> On 17.09.2014 15:48, Inki Dae wrote: >>> This interface and relevant codes aren't used anymore. >>> >> >> Hmm, I might be missing something, but after removing this IOCTL, how do >> we obtain an offset to pass to mmap()? > > There is DRM_IOCTL_MODE_MAP_DUMB, it can get mmap offset before mmap and > the offset is passed via mmap. Exactly. That will lead us to more generic world. Thanks, Inki Dae > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH 2/2] drm/exynos: use drm generic mmap interface
On 2014? 10? 01? 22:17, Tomasz Figa wrote: > Hi Inki, > > On 17.09.2014 15:48, Inki Dae wrote: >> This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific >> to Exynos drm and instead uses drm generic mmap. > > It looks like libdrm_exynos is still using DRM_EXYNOS_GEM_MMAP, but this > patch just removes it. This basically means that any application using > it is now broken. Do you have any plans to fix this? > Hi Tomasz, Yes, of course. We will fix it soon. For this, I mentioned earlier, http://web.archiveorange.com/archive/v/hhSc574WhqJAKgdBq7KL Thanks, Inki Dae > Best regards, > Tomasz > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH] drm/exynos: remove ifdeferry from initialization code
On 2014? 10? 01? 14:48, Inki Dae wrote:
> On 2014? 09? 30? 20:29, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> Gently ping.
>
> Hi Andrzej,
>
> I merged it to local repository to test. But now exynos drm doesn't work
> correctly since pulling drm-next of Dave regardless of your patch.
>
> Problems are,
> 1. error occurs when we try to test modetest with -v option from second
> times.
> 2. error occurs when we try to test unbind.
>
> Now we are checking these problems. Can you try to also check it?
In addition, we are testing it on trats2 board.
>
> Thanks,
> Inki Dae
>
>>
>> Andrzej
>>
>> On 09/10/2014 01:53 PM, Andrzej Hajda wrote:
>>> The patch replaces separate calls to driver (de)registration by
>>> loops over the array of drivers. As a result it significantly
>>> decreases number of ifdefs. Additionally it moves device registration
>>> related ifdefs to header file.
>>>
>>> Signed-off-by: Andrzej Hajda
>>> ---
>>> Hi Inki,
>>>
>>> During testing your component match support patch [1] I have prepared patch
>>> removing most ifdefs from exynos_drm_drv.c. It is based on your patch, but
>>> I can rebase it if necessary.
>>>
>>> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37031
>>>
>>> Regards
>>> Andrzej
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 170
>>> +++-
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 25 +++--
>>> 2 files changed, 48 insertions(+), 147 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> index b2c710a..a660e46 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> @@ -553,74 +553,54 @@ static const struct component_master_ops
>>> exynos_drm_ops = {
>>> .unbind = exynos_drm_unbind,
>>> };
>>>
>>> -static int exynos_drm_platform_probe(struct platform_device *pdev)
>>> -{
>>> - struct component_match *match;
>>> - int ret;
>>> -
>>> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>> - exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>>> -
>>> +static struct platform_driver * const exynos_drm_drivers[] = {
>>> #ifdef CONFIG_DRM_EXYNOS_FIMD
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - return ret;
>>> + _driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_DP
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - goto err_unregister_fimd_drv;
>>> + _driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_DSI
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - goto err_unregister_dp_drv;
>>> + _driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_HDMI
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - goto err_unregister_dsi_drv;
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - goto err_unregister_mixer_drv;
>>> + _driver,
>>> + _driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_G2D
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - goto err_unregister_hdmi_drv;
>>> + _driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_FIMC
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - goto err_unregister_g2d_drv;
>>> + _driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_ROTATOR
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - goto err_unregister_fimc_drv;
>>> + _driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_GSC
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>>> - goto err_unregister_rotator_drv;
>>> + _driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_IPP
>>> - ret = platform_driver_register(_driver);
>>> - if (ret < 0)
>
[PATCH] drm/exynos: remove ifdeferry from initialization code
On 2014? 09? 30? 20:29, Andrzej Hajda wrote:
> Hi Inki,
>
> Gently ping.
Hi Andrzej,
I merged it to local repository to test. But now exynos drm doesn't work
correctly since pulling drm-next of Dave regardless of your patch.
Problems are,
1. error occurs when we try to test modetest with -v option from second
times.
2. error occurs when we try to test unbind.
Now we are checking these problems. Can you try to also check it?
Thanks,
Inki Dae
>
> Andrzej
>
> On 09/10/2014 01:53 PM, Andrzej Hajda wrote:
>> The patch replaces separate calls to driver (de)registration by
>> loops over the array of drivers. As a result it significantly
>> decreases number of ifdefs. Additionally it moves device registration
>> related ifdefs to header file.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> Hi Inki,
>>
>> During testing your component match support patch [1] I have prepared patch
>> removing most ifdefs from exynos_drm_drv.c. It is based on your patch, but
>> I can rebase it if necessary.
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37031
>>
>> Regards
>> Andrzej
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 170
>> +++-
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 25 +++--
>> 2 files changed, 48 insertions(+), 147 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index b2c710a..a660e46 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -553,74 +553,54 @@ static const struct component_master_ops
>> exynos_drm_ops = {
>> .unbind = exynos_drm_unbind,
>> };
>>
>> -static int exynos_drm_platform_probe(struct platform_device *pdev)
>> -{
>> -struct component_match *match;
>> -int ret;
>> -
>> -pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> -exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>> -
>> +static struct platform_driver * const exynos_drm_drivers[] = {
>> #ifdef CONFIG_DRM_EXYNOS_FIMD
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -return ret;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_DP
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_fimd_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_DSI
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_dp_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_HDMI
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_dsi_drv;
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_mixer_drv;
>> +_driver,
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_G2D
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_hdmi_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_FIMC
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_g2d_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_ROTATOR
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_fimc_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_GSC
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_rotator_drv;
>> +_driver,
>> #endif
>> -
>> #ifdef CONFIG_DRM_EXYNOS_IPP
>> -ret = platform_driver_register(_driver);
>> -if (ret < 0)
>> -goto err_unregister_gsc_drv;
>> +_driver,
>> +#endif
>> +};
>> +
>> +static int exynos_drm_platform_probe(struct platform_device *pdev)
>> +{
>> +struct component_match *match;
>> +int ret, i;
>> +
>> +pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> +exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>> +
>> +for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
>> +ret = platform_driver_register(exynos_drm_drivers[i]);
>> +if (
[PATCH] drm/exynos: fimd: fix screen shaking issue on i80 mode
This patch resolves a issue that screen is shaked after resumed. The issue could be incurred when overlay registers are updated to new buffer while fimd is still transmitting video data. So this patch make sure to wait for the completion of the transmission if fimd is transmitting video data before updating overlay registers. Signed-off-by: Inki Dae --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 2f896df..8a45a70 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -665,6 +665,25 @@ static void fimd_win_commit(struct exynos_drm_manager *mgr, int zpos) } /* +* Wait for the completion of current transmission if fimd is still +* transmitting video data. +* +* Below codes resolve following issue: +* when resumed, fimd_win_commit() could be called to update overlay +* relevent registers and then pae flip could be performed by userspace +* request. The problem is that te interrupt could occur and +* fimd_trigger() could be called before fimd_win_commit is called by +* page flip function, exynos_drm_crtc_page_flip. +* +* In this case, there is a problem that fimd_win_commit() is called by +* the page flip request while fimd is still transmitting video data +* so overlay registers are updated to new buffer. That makes screen +* to be shaked. +*/ + if (ctx->i80_if && atomic_read(>triggering)) + fimd_wait_for_vblank(mgr); + + /* * SHADOWCON/PRTCON register is used for enabling timing. * * for example, once only width value of a register is set, -- 1.7.9.5
[PATCH v2] drm/exynos: switch to universal plane API
2014-09-20 1:04 GMT+09:00 Inki Dae :
> 2014-09-19 21:58 GMT+09:00 Andrzej Hajda :
>> The patch replaces legacy functions
>> drm_plane_init() / drm_crtc_init() with
>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>> It allows to replace fake primary plane with the real one.
>> Additionally the patch leaves cleanup of crtcs to core,
>> this way planes and crtcs are cleaned in correct order.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> Hi Inki, Joonyoung,
>>
>> This is 2nd version of the patch with addressed comments of Joonyoung.
>
> Picked it up.
Oops, one more thing, there are trivial issues below. See the below
comments. Anyway, I fixed them up and merged.
Thanks,
Inki Dae
>
> Thanks,
> Inki Dae
>
>>
>> Regards
>> Andrzej
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 62
>> +++
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 -
>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +-
>> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 -
>> drivers/gpu/drm/exynos/exynos_mixer.c | 2 -
>> 7 files changed, 46 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index b68e58f..8e38e9f 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>> * Exynos specific crtc structure.
>> *
>> * @drm_crtc: crtc object.
>> - * @drm_plane: pointer of private plane object for this crtc
>> * @manager: the manager associated with this crtc
>> * @pipe: a crtc index created at load() with a new crtc object creation
>> * and the crtc object would be set to private->crtc array
>> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>> */
>> struct exynos_drm_crtc {
>> struct drm_crtc drm_crtc;
>> - struct drm_plane*plane;
>> struct exynos_drm_manager *manager;
>> unsigned intpipe;
>> unsigned intdpms;
>> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>>
>> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>>
>> - exynos_plane_commit(exynos_crtc->plane);
>> + exynos_plane_commit(crtc->primary);
>>
>> if (manager->ops->commit)
>> manager->ops->commit(manager);
>>
>> - exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
>> + exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>> }
>>
>> static bool
>> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
>> drm_display_mode *mode,
>> {
>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> struct exynos_drm_manager *manager = exynos_crtc->manager;
>> - struct drm_plane *plane = exynos_crtc->plane;
>> + struct drm_framebuffer *fb = crtc->primary->fb;
>> unsigned int crtc_w;
>> unsigned int crtc_h;
>> - int ret;
>>
>> /*
>> * copy the mode data adjusted by mode_fixup() into crtc->mode
>> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
>> drm_display_mode *mode,
>> */
>> memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>>
>> - crtc_w = crtc->primary->fb->width - x;
>> - crtc_h = crtc->primary->fb->height - y;
>> + crtc_w = fb->width - x;
>> + crtc_h = fb->height - y;
>>
>> if (manager->ops->mode_set)
>> manager->ops->mode_set(manager, >mode);
>>
>> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
>> crtc_w, crtc_h,
>> - x, y, crtc_w, crtc_h);
>> - if (ret)
>> - return ret;
>> -
>> - plane->crtc = crtc;
>> - plane->fb = crtc->primary->fb;
>> - drm_framebuffer_reference(plane->fb);
>> -
>> - return 0;
>> + return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>> }
>>
>> static int exy
[PATCH] drm/exynos: factor out initial setting of each driver
2014-09-18 17:50 GMT+09:00 Joonyoung Shim :
> From fimd driver and vidi driver, dev->irq_enabled and
> dev->vblank_disable_allowed are set and also mixer needs them even if
> missed. It's duplicated so set them when loads drm driver.
Picked it up.
Thanks,
Inki Dae
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 17 +
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 -
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 -
> 3 files changed, 17 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 0d74e9b..bc87be3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -116,6 +116,23 @@ static int exynos_drm_load(struct drm_device *dev,
> unsigned long flags)
> /* force connectors detection */
> drm_helper_hpd_irq_event(dev);
>
> + /*
> +* enable drm irq mode.
> +* - with irq_enabled = true, we can use the vblank feature.
> +*
> +* P.S. note that we wouldn't use drm irq handler but
> +* just specific driver own one instead because
> +* drm framework supports only one irq handler.
> +*/
> + dev->irq_enabled = true;
> +
> + /*
> +* with vblank_disable_allowed = true, vblank interrupt will be
> disabled
> +* by drm timer once a current process gives up ownership of
> +* vblank event.(after drm_vblank_put function is called)
> +*/
> + dev->vblank_disable_allowed = true;
> +
> return 0;
>
> err_unbind_all:
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 5d09e33..370abdc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -237,23 +237,6 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
> *mgr,
> mgr->drm_dev = ctx->drm_dev = drm_dev;
> mgr->pipe = ctx->pipe = priv->pipe++;
>
> - /*
> -* enable drm irq mode.
> -* - with irq_enabled = true, we can use the vblank feature.
> -*
> -* P.S. note that we wouldn't use drm irq handler but
> -* just specific driver own one instead because
> -* drm framework supports only one irq handler.
> -*/
> - drm_dev->irq_enabled = true;
> -
> - /*
> -* with vblank_disable_allowed = true, vblank interrupt will be
> disabled
> -* by drm timer once a current process gives up ownership of
> -* vblank event.(after drm_vblank_put function is called)
> -*/
> - drm_dev->vblank_disable_allowed = true;
> -
> /* attach this sub driver to iommu mapping if supported. */
> if (is_drm_iommu_supported(ctx->drm_dev)) {
> /*
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 9528d81..2e6120b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -303,23 +303,6 @@ static int vidi_mgr_initialize(struct exynos_drm_manager
> *mgr,
> mgr->drm_dev = ctx->drm_dev = drm_dev;
> mgr->pipe = ctx->pipe = priv->pipe++;
>
> - /*
> -* enable drm irq mode.
> -* - with irq_enabled = 1, we can use the vblank feature.
> -*
> -* P.S. note that we wouldn't use drm irq handler but
> -* just specific driver own one instead because
> -* drm framework supports only one irq handler.
> -*/
> - drm_dev->irq_enabled = 1;
> -
> - /*
> -* with vblank_disable_allowed = 1, vblank interrupt will be disabled
> -* by drm timer once a current process gives up ownership of
> -* vblank event.(after drm_vblank_put function is called)
> -*/
> - drm_dev->vblank_disable_allowed = 1;
> -
> return 0;
> }
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/exynos: switch to universal plane API
2014-09-19 21:58 GMT+09:00 Andrzej Hajda :
> The patch replaces legacy functions
> drm_plane_init() / drm_crtc_init() with
> drm_universal_plane_init() and drm_crtc_init_with_planes().
> It allows to replace fake primary plane with the real one.
> Additionally the patch leaves cleanup of crtcs to core,
> this way planes and crtcs are cleaned in correct order.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki, Joonyoung,
>
> This is 2nd version of the patch with addressed comments of Joonyoung.
Picked it up.
Thanks,
Inki Dae
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 62
> +++
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++-
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 -
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 19 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 -
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 -
> 7 files changed, 46 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index b68e58f..8e38e9f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
> * Exynos specific crtc structure.
> *
> * @drm_crtc: crtc object.
> - * @drm_plane: pointer of private plane object for this crtc
> * @manager: the manager associated with this crtc
> * @pipe: a crtc index created at load() with a new crtc object creation
> * and the crtc object would be set to private->crtc array
> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
> */
> struct exynos_drm_crtc {
> struct drm_crtc drm_crtc;
> - struct drm_plane*plane;
> struct exynos_drm_manager *manager;
> unsigned intpipe;
> unsigned intdpms;
> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>
> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>
> - exynos_plane_commit(exynos_crtc->plane);
> + exynos_plane_commit(crtc->primary);
>
> if (manager->ops->commit)
> manager->ops->commit(manager);
>
> - exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
> + exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
> }
>
> static bool
> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> struct exynos_drm_manager *manager = exynos_crtc->manager;
> - struct drm_plane *plane = exynos_crtc->plane;
> + struct drm_framebuffer *fb = crtc->primary->fb;
> unsigned int crtc_w;
> unsigned int crtc_h;
> - int ret;
>
> /*
> * copy the mode data adjusted by mode_fixup() into crtc->mode
> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> */
> memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>
> - crtc_w = crtc->primary->fb->width - x;
> - crtc_h = crtc->primary->fb->height - y;
> + crtc_w = fb->width - x;
> + crtc_h = fb->height - y;
>
> if (manager->ops->mode_set)
> manager->ops->mode_set(manager, >mode);
>
> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0,
> crtc_w, crtc_h,
> - x, y, crtc_w, crtc_h);
> - if (ret)
> - return ret;
> -
> - plane->crtc = crtc;
> - plane->fb = crtc->primary->fb;
> - drm_framebuffer_reference(plane->fb);
> -
> - return 0;
> + return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
> }
>
> static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int
> y,
> struct drm_framebuffer *old_fb)
> {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> - struct drm_plane *plane = exynos_crtc->plane;
> + struct drm_framebuffer *fb = crtc->primary->fb;
> unsigned int crtc_w;
> unsigned int crtc_h;
> int ret;
> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct
> drm_crtc *crtc, int x, int y,
> return -EPERM;
> }
>
[PATCH v2] drm/exynos: use drm generic mmap interface
This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
to Exynos drm and instead uses drm generic mmap.
We had used the interface specific to Exynos drm to do mmap directly,
not to use demand paging which maps each page with physical memory
at page fault handler. We don't need the specific mmap interface
because the drm generic mmap which uses vm offset manager stuff can
also do mmap directly.
This patch makes a userspace region to be mapped with whole physical
memory region allocated by userspace request when mmap system call is
requested.
Changelog v2:
- do not set VM_IO, VM_DONTEXPEND and VM_DONTDUMP. These flags were already
set by drm_gem_mmap
- do not include , which isn't needed anymore.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 -
drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
drivers/gpu/drm/exynos/exynos_drm_gem.c | 89 ++-
drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
include/uapi/drm/exynos_drm.h | 22
5 files changed, 16 insertions(+), 132 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 10ad3d4..928c514 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -15,7 +15,6 @@
#include
#include
-#include
#include
#include
@@ -149,10 +148,6 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
}
-static const struct file_operations exynos_drm_gem_fops = {
- .mmap = exynos_drm_gem_mmap_buffer,
-};
-
static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
{
struct drm_connector *connector;
@@ -191,7 +186,6 @@ static int exynos_drm_resume(struct drm_device *dev)
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
- struct file *anon_filp;
int ret;
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
@@ -204,21 +198,8 @@ static int exynos_drm_open(struct drm_device *dev, struct
drm_file *file)
if (ret)
goto err_file_priv_free;
- anon_filp = anon_inode_getfile("exynos_gem", _drm_gem_fops,
- NULL, 0);
- if (IS_ERR(anon_filp)) {
- ret = PTR_ERR(anon_filp);
- goto err_subdrv_close;
- }
-
- anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
- file_priv->anon_filp = anon_filp;
-
return ret;
-err_subdrv_close:
- exynos_drm_subdrv_close(dev, file);
-
err_file_priv_free:
kfree(file_priv);
file->driver_priv = NULL;
@@ -234,7 +215,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
{
struct exynos_drm_private *private = dev->dev_private;
- struct drm_exynos_file_private *file_priv;
struct drm_pending_vblank_event *v, *vt;
struct drm_pending_event *e, *et;
unsigned long flags;
@@ -260,10 +240,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
struct drm_file *file)
}
spin_unlock_irqrestore(>event_lock, flags);
- file_priv = file->driver_priv;
- if (file_priv->anon_filp)
- fput(file_priv->anon_filp);
-
kfree(file->driver_priv);
file->driver_priv = NULL;
}
@@ -282,8 +258,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
- exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 69a6fa3..d22e640 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
struct drm_exynos_file_private {
struct exynos_drm_g2d_private *g2d_priv;
struct device *ipp_dev;
- struct file *anon_filp;
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2f3665d..0d5b969 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,23 +318,16 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-int exynos_drm_gem_mmap_buffer(struct file *filp,
+int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
[PATCH 2/2] drm/exynos: use drm generic mmap interface
Thanks for review.
Below trivial things you pointed out will be fixed soon.
On 2014? 09? 18? 13:56, Joonyoung Shim wrote:
> Hi,
>
> On 09/17/2014 10:48 PM, Inki Dae wrote:
>> This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
>> to Exynos drm and instead uses drm generic mmap.
>>
>> We had used the interface specific to Exynos drm to do mmap directly,
>> not to use demand paging which maps each page with physical memory
>> at page fault handler. We don't need the specific mmap interface
>> because the drm generic mmap which uses vm offset manager stuff can
>> also do mmap directly.
>>
>> This patch makes a userspace region to be mapped with whole physical
>> memory region allocated by userspace request when mmap system call is
>> requested.
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 -
>> drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 84
>> ++-
>> drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
>> include/uapi/drm/exynos_drm.h | 22
>> 5 files changed, 14 insertions(+), 128 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 10ad3d4..a7819eb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>
> Because anymore anon file doesn't use, you can remove to include
> .
Right, I missed it while taking away the direct mmap stuff specific to
Exynos drm.
>
>> @@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
>> return 0;
>> }
>>
>> -static const struct file_operations exynos_drm_gem_fops = {
>> -.mmap = exynos_drm_gem_mmap_buffer,
>> -};
>> -
>> static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
>> {
>> struct drm_connector *connector;
>> @@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
>> static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>> {
>> struct drm_exynos_file_private *file_priv;
>> -struct file *anon_filp;
>> int ret;
>>
>> file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
>> @@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev,
>> struct drm_file *file)
>> if (ret)
>> goto err_file_priv_free;
>>
>> -anon_filp = anon_inode_getfile("exynos_gem", _drm_gem_fops,
>> -NULL, 0);
>> -if (IS_ERR(anon_filp)) {
>> -ret = PTR_ERR(anon_filp);
>> -goto err_subdrv_close;
>> -}
>> -
>> -anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
>> -file_priv->anon_filp = anon_filp;
>> -
>> return ret;
>>
>> -err_subdrv_close:
>> -exynos_drm_subdrv_close(dev, file);
>> -
>> err_file_priv_free:
>> kfree(file_priv);
>> file->driver_priv = NULL;
>> @@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
>> static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
>> *file)
>> {
>> struct exynos_drm_private *private = dev->dev_private;
>> -struct drm_exynos_file_private *file_priv;
>> struct drm_pending_vblank_event *v, *vt;
>> struct drm_pending_event *e, *et;
>> unsigned long flags;
>> @@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device
>> *dev, struct drm_file *file)
>> }
>> spin_unlock_irqrestore(>event_lock, flags);
>>
>> -file_priv = file->driver_priv;
>> -if (file_priv->anon_filp)
>> -fput(file_priv->anon_filp);
>> -
>> kfree(file->driver_priv);
>> file->driver_priv = NULL;
>> }
>> @@ -282,8 +259,6 @@ static const struct vm_operations_struct
>> exynos_drm_gem_vm_ops = {
>> static const struct drm_ioctl_desc exynos_ioctls[] = {
>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
>> DRM_UNLOCKED | DRM_AUTH),
>> -DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
>> -exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
>> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
>> exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
>> DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
>> diff --git a/drivers/gpu/drm/exynos/
[PATCH 2/2] drm/exynos: use drm generic mmap interface
This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
to Exynos drm and instead uses drm generic mmap.
We had used the interface specific to Exynos drm to do mmap directly,
not to use demand paging which maps each page with physical memory
at page fault handler. We don't need the specific mmap interface
because the drm generic mmap which uses vm offset manager stuff can
also do mmap directly.
This patch makes a userspace region to be mapped with whole physical
memory region allocated by userspace request when mmap system call is
requested.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 25 -
drivers/gpu/drm/exynos/exynos_drm_drv.h |1 -
drivers/gpu/drm/exynos/exynos_drm_gem.c | 84 ++-
drivers/gpu/drm/exynos/exynos_drm_gem.h | 10
include/uapi/drm/exynos_drm.h | 22
5 files changed, 14 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 10ad3d4..a7819eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -149,10 +149,6 @@ static int exynos_drm_unload(struct drm_device *dev)
return 0;
}
-static const struct file_operations exynos_drm_gem_fops = {
- .mmap = exynos_drm_gem_mmap_buffer,
-};
-
static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
{
struct drm_connector *connector;
@@ -191,7 +187,6 @@ static int exynos_drm_resume(struct drm_device *dev)
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
- struct file *anon_filp;
int ret;
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
@@ -204,21 +199,8 @@ static int exynos_drm_open(struct drm_device *dev, struct
drm_file *file)
if (ret)
goto err_file_priv_free;
- anon_filp = anon_inode_getfile("exynos_gem", _drm_gem_fops,
- NULL, 0);
- if (IS_ERR(anon_filp)) {
- ret = PTR_ERR(anon_filp);
- goto err_subdrv_close;
- }
-
- anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
- file_priv->anon_filp = anon_filp;
-
return ret;
-err_subdrv_close:
- exynos_drm_subdrv_close(dev, file);
-
err_file_priv_free:
kfree(file_priv);
file->driver_priv = NULL;
@@ -234,7 +216,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
{
struct exynos_drm_private *private = dev->dev_private;
- struct drm_exynos_file_private *file_priv;
struct drm_pending_vblank_event *v, *vt;
struct drm_pending_event *e, *et;
unsigned long flags;
@@ -260,10 +241,6 @@ static void exynos_drm_postclose(struct drm_device *dev,
struct drm_file *file)
}
spin_unlock_irqrestore(>event_lock, flags);
- file_priv = file->driver_priv;
- if (file_priv->anon_filp)
- fput(file_priv->anon_filp);
-
kfree(file->driver_priv);
file->driver_priv = NULL;
}
@@ -282,8 +259,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
- exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 69a6fa3..d22e640 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -240,7 +240,6 @@ struct exynos_drm_g2d_private {
struct drm_exynos_file_private {
struct exynos_drm_g2d_private *g2d_priv;
struct device *ipp_dev;
- struct file *anon_filp;
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 2f3665d..3cf6494 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,21 +318,17 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-int exynos_drm_gem_mmap_buffer(struct file *filp,
+int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
struct vm_area_struct *vma)
{
- struct drm_gem_object *obj = filp->private_data;
- struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
- struct drm_device *drm_dev = obj->dev;
+
[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl
This interface and relevant codes aren't used anymore.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |3 ---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 17 -
drivers/gpu/drm/exynos/exynos_drm_gem.h |4
include/uapi/drm/exynos_drm.h | 18 --
4 files changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 9b00e4e..10ad3d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -282,9 +282,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
- DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP_OFFSET,
- exynos_drm_gem_map_offset_ioctl, DRM_UNLOCKED |
- DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 15db801..2f3665d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,23 +318,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
}
-int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
-{
- struct drm_exynos_gem_map_off *args = data;
-
- DRM_DEBUG_KMS("handle = 0x%x, offset = 0x%lx\n",
- args->handle, (unsigned long)args->offset);
-
- if (!(dev->driver->driver_features & DRIVER_GEM)) {
- DRM_ERROR("does not support GEM.\n");
- return -ENODEV;
- }
-
- return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
- >offset);
-}
-
int exynos_drm_gem_mmap_buffer(struct file *filp,
struct vm_area_struct *vma)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 1592c0b..8e46094 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -111,10 +111,6 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
unsigned int gem_handle,
struct drm_file *filp);
-/* get buffer offset to map to user space. */
-int exynos_drm_gem_map_offset_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-
/*
* mmap the physically continuous memory that a gem object contains
* to user space.
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index d584412..67a751c 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -33,20 +33,6 @@ struct drm_exynos_gem_create {
};
/**
- * A structure for getting buffer offset.
- *
- * @handle: a pointer to gem object created.
- * @pad: just padding to be 64-bit aligned.
- * @offset: relatived offset value of the memory region allocated.
- * - this value should be set by user.
- */
-struct drm_exynos_gem_map_off {
- unsigned int handle;
- unsigned int pad;
- uint64_t offset;
-};
-
-/**
* A structure for mapping buffer.
*
* @handle: a handle to gem object created.
@@ -316,7 +302,6 @@ struct drm_exynos_ipp_cmd_ctrl {
};
#define DRM_EXYNOS_GEM_CREATE 0x00
-#define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
#define DRM_EXYNOS_GEM_MMAP0x02
/* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
#define DRM_EXYNOS_GEM_GET 0x04
@@ -336,9 +321,6 @@ struct drm_exynos_ipp_cmd_ctrl {
#define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
-#define DRM_IOCTL_EXYNOS_GEM_MAP_OFFSETDRM_IOWR(DRM_COMMAND_BASE + \
- DRM_EXYNOS_GEM_MAP_OFFSET, struct drm_exynos_gem_map_off)
-
#define DRM_IOCTL_EXYNOS_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_MMAP, struct drm_exynos_gem_mmap)
--
1.7.9.5
[PATCH 0/2] drm/exynos: use drm generic mmap interface
This patch set removes unnecessary DRM_EXYNOS_GEM_MAP_OFFSET interface which isn't used anymore and also uses drm generic mmap interface instead of a mmap interface specific to Exynos drm. So this patch set removes a existing mmap interface and relevant codes specific to Exynos drm. Inki Dae (2): drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl drm/exynos: use drm generic mmap interface drivers/gpu/drm/exynos/exynos_drm_drv.c | 28 - drivers/gpu/drm/exynos/exynos_drm_drv.h |1 - drivers/gpu/drm/exynos/exynos_drm_gem.c | 101 +-- drivers/gpu/drm/exynos/exynos_drm_gem.h | 14 - include/uapi/drm/exynos_drm.h | 40 5 files changed, 14 insertions(+), 170 deletions(-) -- 1.7.9.5
[PATCH 0/9] drm/exynos: initialization/deinitialization fixes
On 2014? 09? 09? 22:16, Andrzej Hajda wrote: > This set of patches contains fixes of initialization and deinitialization > code of exynos_drm core and components. > It is based on exynos-drm-next branch. > > Patchset has been tested on trats and universal_c210 platforms. Applied all patches except patch #5. As of now, it seems good to merge also patch #5 if you couldn't post next version of that patch until the end of this week. In this case, I will have a pull request including that patch so that we can fix it up correctly later. Give me your opinion if there is other plan. Thanks, Inki Dae > > Regards > Andrzej > > > Andrzej Hajda (9): > drm/exynos/ipp: traverse ipp drivers list safely > drm/exynos: fix drm driver de-initialization order > drm/exynos/fbdev: fix fbdev gem object cleanup > drm/exynos/fb: free exynos framebuffer on error > drm/exynos/crtc: fix framebuffer reference sequence > drm/exynos/dsi: unregister connector on removal > drm/exynos/dpi: unregister connector and panel on removal > drm/exynos/dp: unregister connector on removal > drm/exynos/hdmi: unregister connector on removal > > drivers/gpu/drm/exynos/exynos_dp_core.c | 4 +++- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ++--- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 1 + > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 --- > drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +++- > 9 files changed, 30 insertions(+), 15 deletions(-) >
-next mostly closed, what have I missed?
Hi Dave, On 2014? 09? 17? 09:59, Dave Airlie wrote: > Okay so I'm pretty sure I'm close to not taking anything major for next, > > I'm not sure I've gotten an exynos tree yet, so hopefully that appears > before -rc6, I have patch sets for enhancing Exynos drm and will have a pull with them by the end of the week. Thanks for notice, Inki Dae > > Please continue to send fixes for -next pulls, and I'm kinda open to > new hw support depending on how intrusive it is to other code. > > Now we have a strange new time of a few weeks where maybe we should go > fix some regressions or something! > > any other trees I've missed? > Dave. >
[PATCH] drm/exynos: fix plane-framebuffer linkage
On 2014? 09? 17? 15:35, Andrzej Hajda wrote: > Hi, > > On 09/16/2014 08:35 AM, Daniel Vetter wrote: >> On Mon, Sep 15, 2014 at 12:52:17PM -0600, Daniel Drake wrote: >>> Pageflipping currently causes some inconsistencies that lead to >>> crashes. Just run an app that causes a CRTC pageflip in a raw X session >>> and check that it exits cleanly and can be restarted - you'll see >>> crashes like: >>> Unable to handle kernel NULL pointer dereference at virtual address >>> 0334 >>> PC is at exynos_drm_crtc_plane_commit+0x20/0x40 >>> LR is at exynos_drm_crtc_plane_commit+0x20/0x40 >>> [] (exynos_drm_crtc_plane_commit) from [] >>> (exynos_drm_crtc_commit+0x44/0x70) >>> [] (exynos_drm_crtc_commit) from [] >>> (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4) >>> [] (exynos_drm_crtc_mode_set_commit.isra.2) from [] >>> (exynos_drm_crtc_page_flip+0x140/0x1a8) >>> [] (exynos_drm_crtc_page_flip) from [] >>> (drm_mode_page_flip_ioctl+0x224/0x2dc) >>> [] (drm_mode_page_flip_ioctl) from [] >>> (drm_ioctl+0x338/0x4fc) >>> >>> These crashes happen because drm_plane_force_disable has previously set >>> plane->crtc to NULL. >>> >>> When drm_mode_page_flip_ioctl() is used to flip another framebuffer >>> onto the primary plane, crtc->primary->fb is correctly updated (this is >>> a virtual plane created by plane_helper), but plane->fb is not (this >>> plane is the real one, created by exynos_drm_crtc_create). >>> >>> We then come to handle rmfb of the backbuffer, which the "real" primary >>> plane is incorrectly pointing at. So drm_framebuffer_remove() decides that >>> the buffer is actually active on a plane and force-disables the plane. >>> >>> Ensuring that plane->fb is kept up-to-date solves that issue, but >>> exposes a reference counting problem. Now we see crashes when rmfb is >>> called on the front-buffer, because the rmfb code expects to drop 3 >>> references here, and there are only 2. >>> >>> That can be fixed by adopting the reference management found in omapdrm: >>> Framebuffer references are not taken directly in crtc mode_set context, >>> but rather in the context of updating the plane, which also covers >>> flips. Like omapdrm we also unreference the old framebuffer here. >>> >>> Signed-off-by: Daniel Drake >> This sounds very much like exynos should switch to universal planes so >> that the fake primary plane created by the helpers doesn't get in the way. >> And for chips which already use planes for everything internally this >> shouldn't be a lot more than a few lines. >> -Daniel > > The patch proposed here of course supersedes my patch fixing fb refcounting. > But the best solution is to get rid of virtual plane as Daniel Vetter > stated. > Daniel (Drake of course :) ) do you want to prepare patch switching to > universal planes? > Maybe other volunteers? If not I can try to do it, as it seems quite > straightforward. I think you can do it and you would be a right person to do it. Thanks, Inki Dae > > Regards > Andrzej > >>> --- >>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 ++-- >>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 8 >>> 2 files changed, 10 insertions(+), 10 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> index b68e58f..7aa9dee 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> @@ -140,16 +140,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct >>> drm_display_mode *mode, >>> if (manager->ops->mode_set) >>> manager->ops->mode_set(manager, >mode); >>> >>> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, >>> crtc_w, crtc_h, >>> - x, y, crtc_w, crtc_h); >>> - if (ret) >>> - return ret; >>> - >>> - plane->crtc = crtc; >>> - plane->fb = crtc->primary->fb; >>> - drm_framebuffer_reference(plane->fb); >>> - >>> - return 0; >>> + return exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, >>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h); >>> } >>> >>> static int exynos_drm_crtc_
[PATCH 5/9] drm/exynos/crtc: fix framebuffer reference sequence
On 2014? 09? 12? 20:04, Andrzej Hajda wrote: > On 09/12/2014 12:45 PM, Inki Dae wrote: >> On 2014? 09? 12? 18:27, Andrzej Hajda wrote: >>> On 09/12/2014 10:57 AM, Daniel Vetter wrote: >>>> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote: >>>>> Hi Andrzej, >>>>> >>>>> On 2014? 09? 09? 22:16, Andrzej Hajda wrote: >>>>>> Adding reference to framebuffer should be accompanied with removing >>>>>> reference to old framebuffer assigned to the plane. >>>>>> This patch removes following warning: >>>>>> >>>>>> [ 95.038017] WARNING: CPU: 1 PID: 3067 at >>>>>> drivers/gpu/drm/drm_crtc.c:5115 drm_mode_config_cleanup+0x258/0x268() >>>>>> [ 95.048086] Modules linked in: >>>>>> [ 95.051430] CPU: 1 PID: 3067 Comm: bash Tainted: GW >>>>>> 3.16.0-11355-g7a6eca5-dirty #3015 >>>>>> [ 95.060058] [] (unwind_backtrace) from [] >>>>>> (show_stack+0x10/0x14) >>>>>> [ 95.067766] [] (show_stack) from [] >>>>>> (dump_stack+0x70/0xbc) >>>>>> [ 95.074953] [] (dump_stack) from [] >>>>>> (warn_slowpath_common+0x64/0x88) >>>>>> [ 95.083005] [] (warn_slowpath_common) from [] >>>>>> (warn_slowpath_null+0x1c/0x24) >>>>>> [ 95.091780] [] (warn_slowpath_null) from [] >>>>>> (drm_mode_config_cleanup+0x258/0x268) >>>>>> [ 95.100983] [] (drm_mode_config_cleanup) from [] >>>>>> (exynos_drm_unload+0x38/0x50) >>>>>> [ 95.109915] [] (exynos_drm_unload) from [] >>>>>> (drm_dev_unregister+0x24/0x98) >>>>>> [ 95.118414] [] (drm_dev_unregister) from [] >>>>>> (drm_put_dev+0x28/0x64) >>>>>> [ 95.126412] [] (drm_put_dev) from [] >>>>>> (take_down_master+0x24/0x44) >>>>>> [ 95.134218] [] (take_down_master) from [] >>>>>> (component_del+0x8c/0xc8) >>>>>> [ 95.142201] [] (component_del) from [] >>>>>> (exynos_dsi_remove+0x18/0x2c) >>>>>> [ 95.150294] [] (exynos_dsi_remove) from [] >>>>>> (platform_drv_remove+0x18/0x1c) >>>>>> [ 95.158872] [] (platform_drv_remove) from [] >>>>>> (__device_release_driver+0x70/0xc4) >>>>>> [ 95.167981] [] (__device_release_driver) from [] >>>>>> (device_release_driver+0x20/0x2c) >>>>>> [ 95.177268] [] (device_release_driver) from [] >>>>>> (unbind_store+0x5c/0x94) >>>>>> [ 95.185597] [] (unbind_store) from [] >>>>>> (drv_attr_store+0x20/0x2c) >>>>>> [ 95.193323] [] (drv_attr_store) from [] >>>>>> (sysfs_kf_write+0x4c/0x50) >>>>>> [ 95.201224] [] (sysfs_kf_write) from [] >>>>>> (kernfs_fop_write+0xc4/0x184) >>>>>> [ 95.209393] [] (kernfs_fop_write) from [] >>>>>> (vfs_write+0xa0/0x1a8) >>>>>> [ 95.217111] [] (vfs_write) from [] >>>>>> (SyS_write+0x40/0x8c) >>>>>> [ 95.224146] [] (SyS_write) from [] >>>>>> (ret_fast_syscall+0x0/0x48) >>>>>> >>>>>> Signed-off-by: Andrzej Hajda >>>>>> --- >>>>>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ >>>>>> 1 file changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>>>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>>>>> index b68e58f..bde19f4 100644 >>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>>>>> @@ -145,10 +145,16 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, >>>>>> struct drm_display_mode *mode, >>>>>> if (ret) >>>>>> return ret; >>>>>> >>>>>> +/* we need to unreference current fb after replacing it with >>>>>> new one */ >>>>>> +old_fb = plane->fb; >>>>>> + >>>>>> plane->crtc = crtc; >>>>>> plane->fb = crtc->primary->fb; >>>>>> drm_framebuffer_reference(plane->fb); >>>>>> >>>
[PATCH 5/9] drm/exynos/crtc: fix framebuffer reference sequence
On 2014? 09? 12? 18:27, Andrzej Hajda wrote: > On 09/12/2014 10:57 AM, Daniel Vetter wrote: >> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote: >>> Hi Andrzej, >>> >>> On 2014? 09? 09? 22:16, Andrzej Hajda wrote: >>>> Adding reference to framebuffer should be accompanied with removing >>>> reference to old framebuffer assigned to the plane. >>>> This patch removes following warning: >>>> >>>> [ 95.038017] WARNING: CPU: 1 PID: 3067 at >>>> drivers/gpu/drm/drm_crtc.c:5115 drm_mode_config_cleanup+0x258/0x268() >>>> [ 95.048086] Modules linked in: >>>> [ 95.051430] CPU: 1 PID: 3067 Comm: bash Tainted: GW >>>> 3.16.0-11355-g7a6eca5-dirty #3015 >>>> [ 95.060058] [] (unwind_backtrace) from [] >>>> (show_stack+0x10/0x14) >>>> [ 95.067766] [] (show_stack) from [] >>>> (dump_stack+0x70/0xbc) >>>> [ 95.074953] [] (dump_stack) from [] >>>> (warn_slowpath_common+0x64/0x88) >>>> [ 95.083005] [] (warn_slowpath_common) from [] >>>> (warn_slowpath_null+0x1c/0x24) >>>> [ 95.091780] [] (warn_slowpath_null) from [] >>>> (drm_mode_config_cleanup+0x258/0x268) >>>> [ 95.100983] [] (drm_mode_config_cleanup) from [] >>>> (exynos_drm_unload+0x38/0x50) >>>> [ 95.109915] [] (exynos_drm_unload) from [] >>>> (drm_dev_unregister+0x24/0x98) >>>> [ 95.118414] [] (drm_dev_unregister) from [] >>>> (drm_put_dev+0x28/0x64) >>>> [ 95.126412] [] (drm_put_dev) from [] >>>> (take_down_master+0x24/0x44) >>>> [ 95.134218] [] (take_down_master) from [] >>>> (component_del+0x8c/0xc8) >>>> [ 95.142201] [] (component_del) from [] >>>> (exynos_dsi_remove+0x18/0x2c) >>>> [ 95.150294] [] (exynos_dsi_remove) from [] >>>> (platform_drv_remove+0x18/0x1c) >>>> [ 95.158872] [] (platform_drv_remove) from [] >>>> (__device_release_driver+0x70/0xc4) >>>> [ 95.167981] [] (__device_release_driver) from [] >>>> (device_release_driver+0x20/0x2c) >>>> [ 95.177268] [] (device_release_driver) from [] >>>> (unbind_store+0x5c/0x94) >>>> [ 95.185597] [] (unbind_store) from [] >>>> (drv_attr_store+0x20/0x2c) >>>> [ 95.193323] [] (drv_attr_store) from [] >>>> (sysfs_kf_write+0x4c/0x50) >>>> [ 95.201224] [] (sysfs_kf_write) from [] >>>> (kernfs_fop_write+0xc4/0x184) >>>> [ 95.209393] [] (kernfs_fop_write) from [] >>>> (vfs_write+0xa0/0x1a8) >>>> [ 95.217111] [] (vfs_write) from [] >>>> (SyS_write+0x40/0x8c) >>>> [ 95.224146] [] (SyS_write) from [] >>>> (ret_fast_syscall+0x0/0x48) >>>> >>>> Signed-off-by: Andrzej Hajda >>>> --- >>>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>>> index b68e58f..bde19f4 100644 >>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>>> @@ -145,10 +145,16 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, >>>> struct drm_display_mode *mode, >>>>if (ret) >>>>return ret; >>>> >>>> + /* we need to unreference current fb after replacing it with new one */ >>>> + old_fb = plane->fb; >>>> + >>>>plane->crtc = crtc; >>>>plane->fb = crtc->primary->fb; >>>>drm_framebuffer_reference(plane->fb); >>>> >>>> + if (old_fb) >>>> + drm_framebuffer_unreference(old_fb); >>> This time would be a good chance that we can consider drm flip queue to >>> make sure that whole memory region to old_fb is scanned out completely >>> before dropping a reference of old_fb. the reference of old_fb should be >>> dropped at irq handler of each crtc devices, fimd and mixer. >> Generally it's not a good idea to drop fb references from irq context, >> since if you actually drop the last reference it'll blow up: fb cleanup >> needs a bunch of mutexes. > > I agree with that. > >> >> Also the drm core really should be taking care of this for you, you only >> need to grab references yourself for async flips i
[PATCH 5/9] drm/exynos/crtc: fix framebuffer reference sequence
On 2014? 09? 12? 17:57, Daniel Vetter wrote: > On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote: >> Hi Andrzej, >> >> On 2014? 09? 09? 22:16, Andrzej Hajda wrote: >>> Adding reference to framebuffer should be accompanied with removing >>> reference to old framebuffer assigned to the plane. >>> This patch removes following warning: >>> >>> [ 95.038017] WARNING: CPU: 1 PID: 3067 at drivers/gpu/drm/drm_crtc.c:5115 >>> drm_mode_config_cleanup+0x258/0x268() >>> [ 95.048086] Modules linked in: >>> [ 95.051430] CPU: 1 PID: 3067 Comm: bash Tainted: GW >>> 3.16.0-11355-g7a6eca5-dirty #3015 >>> [ 95.060058] [] (unwind_backtrace) from [] >>> (show_stack+0x10/0x14) >>> [ 95.067766] [] (show_stack) from [] >>> (dump_stack+0x70/0xbc) >>> [ 95.074953] [] (dump_stack) from [] >>> (warn_slowpath_common+0x64/0x88) >>> [ 95.083005] [] (warn_slowpath_common) from [] >>> (warn_slowpath_null+0x1c/0x24) >>> [ 95.091780] [] (warn_slowpath_null) from [] >>> (drm_mode_config_cleanup+0x258/0x268) >>> [ 95.100983] [] (drm_mode_config_cleanup) from [] >>> (exynos_drm_unload+0x38/0x50) >>> [ 95.109915] [] (exynos_drm_unload) from [] >>> (drm_dev_unregister+0x24/0x98) >>> [ 95.118414] [] (drm_dev_unregister) from [] >>> (drm_put_dev+0x28/0x64) >>> [ 95.126412] [] (drm_put_dev) from [] >>> (take_down_master+0x24/0x44) >>> [ 95.134218] [] (take_down_master) from [] >>> (component_del+0x8c/0xc8) >>> [ 95.142201] [] (component_del) from [] >>> (exynos_dsi_remove+0x18/0x2c) >>> [ 95.150294] [] (exynos_dsi_remove) from [] >>> (platform_drv_remove+0x18/0x1c) >>> [ 95.158872] [] (platform_drv_remove) from [] >>> (__device_release_driver+0x70/0xc4) >>> [ 95.167981] [] (__device_release_driver) from [] >>> (device_release_driver+0x20/0x2c) >>> [ 95.177268] [] (device_release_driver) from [] >>> (unbind_store+0x5c/0x94) >>> [ 95.185597] [] (unbind_store) from [] >>> (drv_attr_store+0x20/0x2c) >>> [ 95.193323] [] (drv_attr_store) from [] >>> (sysfs_kf_write+0x4c/0x50) >>> [ 95.201224] [] (sysfs_kf_write) from [] >>> (kernfs_fop_write+0xc4/0x184) >>> [ 95.209393] [] (kernfs_fop_write) from [] >>> (vfs_write+0xa0/0x1a8) >>> [ 95.217111] [] (vfs_write) from [] >>> (SyS_write+0x40/0x8c) >>> [ 95.224146] [] (SyS_write) from [] >>> (ret_fast_syscall+0x0/0x48) >>> >>> Signed-off-by: Andrzej Hajda >>> --- >>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> index b68e58f..bde19f4 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c >>> @@ -145,10 +145,16 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, >>> struct drm_display_mode *mode, >>> if (ret) >>> return ret; >>> >>> + /* we need to unreference current fb after replacing it with new one */ >>> + old_fb = plane->fb; >>> + >>> plane->crtc = crtc; >>> plane->fb = crtc->primary->fb; >>> drm_framebuffer_reference(plane->fb); >>> >>> + if (old_fb) >>> + drm_framebuffer_unreference(old_fb); >> >> This time would be a good chance that we can consider drm flip queue to >> make sure that whole memory region to old_fb is scanned out completely >> before dropping a reference of old_fb. the reference of old_fb should be >> dropped at irq handler of each crtc devices, fimd and mixer. > > Generally it's not a good idea to drop fb references from irq context, > since if you actually drop the last reference it'll blow up: fb cleanup > needs a bunch of mutexes. Actually, drm_flip_work_commit function will be called at irq context so the reference will be dropped by work queue handler so mutex lock would be required before dropping the reference. My concern was that gem memory may be freed before the memory region is scanned out completely so I thought we need to make sure to scan out completely somehow. > > Also the drm core really should be taking care of this for you, you only > need to grab references yourself for async flips if you want the buffer to > survive a bit. crtc_mode_set has not need for this. I expect that the > refcounting bug is somewhere else, at least from my experience chasing > such issues in i915 ;-) Thanks for comments. Yes, there may be refcounting bug somewhere else if drm core makes sure to take care of this. It seems to need more checking. Thanks, Inki Dae > -Daniel >
[PATCH 5/9] drm/exynos/crtc: fix framebuffer reference sequence
Hi Andrzej, On 2014? 09? 09? 22:16, Andrzej Hajda wrote: > Adding reference to framebuffer should be accompanied with removing > reference to old framebuffer assigned to the plane. > This patch removes following warning: > > [ 95.038017] WARNING: CPU: 1 PID: 3067 at drivers/gpu/drm/drm_crtc.c:5115 > drm_mode_config_cleanup+0x258/0x268() > [ 95.048086] Modules linked in: > [ 95.051430] CPU: 1 PID: 3067 Comm: bash Tainted: GW > 3.16.0-11355-g7a6eca5-dirty #3015 > [ 95.060058] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 95.067766] [] (show_stack) from [] > (dump_stack+0x70/0xbc) > [ 95.074953] [] (dump_stack) from [] > (warn_slowpath_common+0x64/0x88) > [ 95.083005] [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x1c/0x24) > [ 95.091780] [] (warn_slowpath_null) from [] > (drm_mode_config_cleanup+0x258/0x268) > [ 95.100983] [] (drm_mode_config_cleanup) from [] > (exynos_drm_unload+0x38/0x50) > [ 95.109915] [] (exynos_drm_unload) from [] > (drm_dev_unregister+0x24/0x98) > [ 95.118414] [] (drm_dev_unregister) from [] > (drm_put_dev+0x28/0x64) > [ 95.126412] [] (drm_put_dev) from [] > (take_down_master+0x24/0x44) > [ 95.134218] [] (take_down_master) from [] > (component_del+0x8c/0xc8) > [ 95.142201] [] (component_del) from [] > (exynos_dsi_remove+0x18/0x2c) > [ 95.150294] [] (exynos_dsi_remove) from [] > (platform_drv_remove+0x18/0x1c) > [ 95.158872] [] (platform_drv_remove) from [] > (__device_release_driver+0x70/0xc4) > [ 95.167981] [] (__device_release_driver) from [] > (device_release_driver+0x20/0x2c) > [ 95.177268] [] (device_release_driver) from [] > (unbind_store+0x5c/0x94) > [ 95.185597] [] (unbind_store) from [] > (drv_attr_store+0x20/0x2c) > [ 95.193323] [] (drv_attr_store) from [] > (sysfs_kf_write+0x4c/0x50) > [ 95.201224] [] (sysfs_kf_write) from [] > (kernfs_fop_write+0xc4/0x184) > [ 95.209393] [] (kernfs_fop_write) from [] > (vfs_write+0xa0/0x1a8) > [ 95.217111] [] (vfs_write) from [] > (SyS_write+0x40/0x8c) > [ 95.224146] [] (SyS_write) from [] > (ret_fast_syscall+0x0/0x48) > > Signed-off-by: Andrzej Hajda > --- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c > b/drivers/gpu/drm/exynos/exynos_drm_crtc.c > index b68e58f..bde19f4 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c > @@ -145,10 +145,16 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct > drm_display_mode *mode, > if (ret) > return ret; > > + /* we need to unreference current fb after replacing it with new one */ > + old_fb = plane->fb; > + > plane->crtc = crtc; > plane->fb = crtc->primary->fb; > drm_framebuffer_reference(plane->fb); > > + if (old_fb) > + drm_framebuffer_unreference(old_fb); This time would be a good chance that we can consider drm flip queue to make sure that whole memory region to old_fb is scanned out completely before dropping a reference of old_fb. the reference of old_fb should be dropped at irq handler of each crtc devices, fimd and mixer. Thanks, Inki Dae > + > return 0; > } > >
[PATCH v2] drm/exynos: update to use component match support
Update Exynos's DRM driver to use component match support rater than
add_components.
Changelog v2:
- release devices and drivers if failed.
- change compare_of to compare_dev.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 44 +++
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 5aae95c..3f6ec96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -486,21 +486,20 @@ void exynos_drm_component_del(struct device *dev,
mutex_unlock(_component_lock);
}
-static int compare_of(struct device *dev, void *data)
+static int compare_dev(struct device *dev, void *data)
{
return dev == (struct device *)data;
}
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+ struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(_component_lock);
list_for_each_entry(cdev, _component_list, list) {
- int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -515,16 +514,10 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
-*
-* TODO. if dpi module follows driver-model driver then
-* below codes can be removed.
*/
if (cdev->crtc_dev == cdev->conn_dev) {
- ret = component_master_add_child(m, compare_of,
- cdev->crtc_dev);
- if (ret < 0)
- return ret;
-
+ component_match_add(dev, , compare_dev,
+ cdev->crtc_dev);
goto out_lock;
}
@@ -534,11 +527,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
- ret = component_master_add_child(m, compare_of, cdev->crtc_dev);
- ret |= component_master_add_child(m, compare_of,
- cdev->conn_dev);
- if (ret < 0)
- return ret;
+ component_match_add(dev, , compare_dev, cdev->crtc_dev);
+ component_match_add(dev, , compare_dev, cdev->conn_dev);
out_lock:
mutex_lock(_component_lock);
@@ -546,7 +536,7 @@ out_lock:
mutex_unlock(_component_lock);
- return attach_cnt ? 0 : -ENODEV;
+ return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -560,13 +550,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
- .add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+ struct component_match *match;
int ret;
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -633,13 +623,23 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- ret = component_master_add(>dev, _drm_ops);
+ match = exynos_drm_match_add(>dev);
+ if (IS_ERR(match)) {
+ ret = PTR_ERR(match);
+ goto err_unregister_resources;
+ }
+
+ ret = component_master_add_with_match(>dev, _drm_ops,
+ match);
if (ret < 0)
- DRM_DEBUG_KMS("re-tried by last sub driver probed later.\n");
+ goto err_unregister_resources;
- return 0;
+ return ret;
+
+err_unregister_resources:
#ifdef CONFIG_DRM_EXYNOS_IPP
+ exynos_platform_device_ipp_unregister();
err_unregister_ipp_drv:
platform_driver_unregister(_driver);
err_unregister_gsc_drv:
--
1.7.9.5
[PATCH v2 00/17] drm/exynos/ipp: image post processing fixes and improvements, part four
On 2014? 08? 28? 18:07, Andrzej Hajda wrote: > This set of patches contains various improvement and fixes > for exynos_drm ipp framework. > The patchset is based on exynos-drm-next branch. > > IPP framework was tested for regressions on exynos4210-trats target. > > In the 2nd version of the series I have included changes proposed by > Joonyoung Shim. > I have decided to resend whole series because the changes caused merge > conflicts and > two separate patches have been added to the series. > Changes are described in comit messages. Applied. Thanks, Inki Dae > > Regards > Andrzej > > > Andrzej Hajda (17): > drm/exynos/ipp: remove fake pm callbacks > drm/exynos/ipp: cancel works before command node clean > drm/exynos/ipp: move file reference from memory to command node > drm/exynos/ipp: remove only related commands on file close > drm/exynos/ipp: remove unused field in command node > drm/exynos/ipp: free partially allocated resources on error > drm/exynos/ipp: move nodes cleaning to separate function > drm/exynos/ipp: clean memory nodes on command node cleaning > drm/exynos/ipp: replace work_struct casting with better constructs > drm/exynos/ipp: stop hardware before freeing memory > drm/exynos/ipp: remove events during command cleaning > drm/exynos/fimc: avoid clearing overflow bits > drm/exynos/fimc: do not enable fimc twice > drm/exynos/fimc: simplify buffer queuing > drm/exynos/fimc: fix source buffer registers > drm/exynos/ipp: remove file argument from node related functions > drm/exynos/ipp: add file checks for ioctls > > drivers/gpu/drm/exynos/exynos_drm_fimc.c| 90 ++- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 3 +- > drivers/gpu/drm/exynos/exynos_drm_ipp.c | 397 > > drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +- > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 3 +- > 5 files changed, 195 insertions(+), 302 deletions(-) >
[PATCH] drm/exynos: use a new anon file for exynos gem mmaper
On 2014? 09? 11? 16:01, Joonyoung Shim wrote: > Hi, > > On 09/11/2014 03:22 PM, Daniel Vetter wrote: >> On Thu, Sep 11, 2014 at 11:16:53AM +0900, Inki Dae wrote: >>> On 2014? 09? 10? 18:01, Daniel Vetter wrote: >>>> Ok I've stumbled over the exynos mmap stuff again while cleaning up >>>> drm legacy cruft and I just don't get what you're doing and why >>>> exactly exynos needs to be special. >>>> >>>> _All_ other drm drivers happily get along with the vma offset manger >>>> stuff to handle mmaps, but somehow exynos does something really crazy. >>> >>> We are also using the vma offset manager stuff. We just added direct >>> mapping interface specific to Exynos additionally. >>> >>>> >>>> Can you please explain the design justification for this and why >>>> switching to the standard gem mmap support isn't possible? >>> >>> As I mentioned above, we are using the standard gem mmap support. >>> However, the standard gem mmap is required for on-demand paging mostly >>> suitable for Desktop. In case of ARM SoC, whole memory region requested >>> by userspace would be allocated once the gem creation interface is >>> called. In this case, it wouldn't need to map userspace with physical >>> page in page fault handler, and the use of the vma offset manager stuff >>> would be unnecessary step. >> >> You don't need to do demand paging at all, you can simply put in all the >> ptes in one go and then never unbind it. So strictly speaking you don't >> need to roll your own mmap, but otoh other drivers (including i915) do >> their own special mmap too. And since you now have it you must support it >> forever anyway. > > I agree with Daniel. The exynos drm specific mmap ioctl can be > substituted to standard gem mmap if exynos mmap is implemented for > direct mapping, actually gem cma does it from drm_gem_cma_mmap_obj. Right, we don't need mmap ioctl specific to Exynos. What we have to is to call a Exynos function to do direct mapping at the end of exynos_drm_gem_mmap function. As Daniel mentioned above, this way we don't also need even page fault handler. We really visited here and there to stick to the use of mmap ioctl specfic to Exynos. :) Thanks, Inki Dae > > Thanks. > >> >> Aside: We have patches floating around for i915 to prefault aggressively, >> so you're not the only ones who noticed the faulting overhead. ARM SoC >> really aren't all that special compared to traditional desktop gpus, so if >> you stumble over such issues please raise them on dri-devel so that we >> could look into useful generic solutions next time around. >> >>> For the same question, Al Viro did, >>> http://lists.freedesktop.org/archives/dri-devel/2013-September/046207.html >>> >>> Is there any issue I am missing , that could be incurred by Exynos codes? >> >> I've stumbled over it again because you're reusing the drm_vm_open_locked >> function, which really should just be an implementation detail of the core >> drm/gem mmap support. >> >> If you want to roll your own mmap (and that's ok, i915 has it and ttm also >> does it) then imo you should not reuse any of the core mmap code, but >> implement your own set of vm_ops. You don't need a faul handler for this >> (since it will never fault), and open/close would just grabbing/dropping a >> reference of the underlying gem object. Instead of trying to reuse the >> same vm_ops you use for normal gem mmaps, which just doesn't make a lot of >> sense to me. >> >> If exynos stops using drm_vm_open_locked then I can move it into the new >> drm_internal.h header since this function really should be private to >> drm.ko. >> >> Thanks, Daniel >> > >
[PATCH] drm/exynos: use a new anon file for exynos gem mmaper
On 2014? 09? 11? 15:22, Daniel Vetter wrote: > On Thu, Sep 11, 2014 at 11:16:53AM +0900, Inki Dae wrote: >> On 2014? 09? 10? 18:01, Daniel Vetter wrote: >>> Ok I've stumbled over the exynos mmap stuff again while cleaning up >>> drm legacy cruft and I just don't get what you're doing and why >>> exactly exynos needs to be special. >>> >>> _All_ other drm drivers happily get along with the vma offset manger >>> stuff to handle mmaps, but somehow exynos does something really crazy. >> >> We are also using the vma offset manager stuff. We just added direct >> mapping interface specific to Exynos additionally. >> >>> >>> Can you please explain the design justification for this and why >>> switching to the standard gem mmap support isn't possible? >> >> As I mentioned above, we are using the standard gem mmap support. >> However, the standard gem mmap is required for on-demand paging mostly >> suitable for Desktop. In case of ARM SoC, whole memory region requested >> by userspace would be allocated once the gem creation interface is >> called. In this case, it wouldn't need to map userspace with physical >> page in page fault handler, and the use of the vma offset manager stuff >> would be unnecessary step. > > You don't need to do demand paging at all, you can simply put in all the > ptes in one go and then never unbind it. So strictly speaking you don't > need to roll your own mmap, but otoh other drivers (including i915) do > their own special mmap too. And since you now have it you must support it > forever anyway. > > Aside: We have patches floating around for i915 to prefault aggressively, > so you're not the only ones who noticed the faulting overhead. ARM SoC > really aren't all that special compared to traditional desktop gpus, so if > you stumble over such issues please raise them on dri-devel so that we > could look into useful generic solutions next time around. > >> For the same question, Al Viro did, >> http://lists.freedesktop.org/archives/dri-devel/2013-September/046207.html >> >> Is there any issue I am missing , that could be incurred by Exynos codes? > > I've stumbled over it again because you're reusing the drm_vm_open_locked > function, which really should just be an implementation detail of the core > drm/gem mmap support. Ah, right. that is critical issue. I shouldn't had used drm_vm_open_locked. Sorry for this. > > If you want to roll your own mmap (and that's ok, i915 has it and ttm also > does it) then imo you should not reuse any of the core mmap code, but > implement your own set of vm_ops. You don't need a faul handler for this > (since it will never fault), and open/close would just grabbing/dropping a > reference of the underlying gem object. Instead of trying to reuse the > same vm_ops you use for normal gem mmaps, which just doesn't make a lot of > sense to me. > > If exynos stops using drm_vm_open_locked then I can move it into the new > drm_internal.h header since this function really should be private to > drm.ko. Sorry for blocking you. I will fix it soon. Thanks, Inki Dae > > Thanks, Daniel >
[PATCH] drm/exynos: update to use component match support
On 2014? 09? 10? 19:24, Andrzej Hajda wrote:
> Hi Inki,
>
> To test it properly I have to fix init/remove bugs [1].
> Of course these bugs were not introduced by this patch,
> but they prevented some basic tests.
I had tested my patch with trats2 board, and works well without below
patch set. hm.. it seems that there is other corner cases I missed. Can
you give me more details about basic tests?
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37266
>
> I have tested successfully your patch with trats and universal_c210 boards.
Thanks for testing and above fixup patch set. Will look into them soon. :)
Thanks,
Inki Dae
>
> Few additional comments below.
>
> On 09/01/2014 02:19 PM, Inki Dae wrote:
>> Update Exynos's DRM driver to use component match support rater than
>> add_components.
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 40
>> ++-
>> 1 file changed, 18 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index feee991..dae62c2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -503,16 +503,15 @@ static int compare_of(struct device *dev, void *data)
>> return dev == (struct device *)data;
>> }
>
> Nitpick.
>
> This is not a part of this patch but compare_of suggests it compares OF
> nodes but this function compares devices, maybe compare_dev would be better.
>
>>
>> -static int exynos_drm_add_components(struct device *dev, struct master *m)
>> +static struct component_match *exynos_drm_match_add(struct device *dev)
>> {
>> +struct component_match *match = NULL;
>> struct component_dev *cdev;
>> unsigned int attach_cnt = 0;
>>
>> mutex_lock(_component_lock);
>>
>> list_for_each_entry(cdev, _component_list, list) {
>> -int ret;
>> -
>> /*
>> * Add components to master only in case that crtc and
>> * encoder/connector device objects exist.
>> @@ -527,16 +526,10 @@ static int exynos_drm_add_components(struct device
>> *dev, struct master *m)
>> /*
>> * fimd and dpi modules have same device object so add
>> * only crtc device object in this case.
>> - *
>> - * TODO. if dpi module follows driver-model driver then
>> - * below codes can be removed.
>> */
>> if (cdev->crtc_dev == cdev->conn_dev) {
>> -ret = component_master_add_child(m, compare_of,
>> -cdev->crtc_dev);
>> -if (ret < 0)
>> -return ret;
>> -
>> +component_match_add(dev, , compare_of,
>> +cdev->crtc_dev);
>> goto out_lock;
>> }
>>
>> @@ -546,11 +539,8 @@ static int exynos_drm_add_components(struct device
>> *dev, struct master *m)
>> * connector/encoder need pipe number of crtc when they
>> * are created.
>> */
>> -ret = component_master_add_child(m, compare_of, cdev->crtc_dev);
>> -ret |= component_master_add_child(m, compare_of,
>> -cdev->conn_dev);
>> -if (ret < 0)
>> -return ret;
>> +component_match_add(dev, , compare_of, cdev->crtc_dev);
>> +component_match_add(dev, , compare_of, cdev->conn_dev);
>>
>> out_lock:
>> mutex_lock(_component_lock);
>> @@ -558,7 +548,7 @@ out_lock:
>>
>> mutex_unlock(_component_lock);
>>
>> -return attach_cnt ? 0 : -ENODEV;
>> +return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
>> }
>>
>> static int exynos_drm_bind(struct device *dev)
>> @@ -572,13 +562,13 @@ static void exynos_drm_unbind(struct device *dev)
>> }
>>
>> static const struct component_master_ops exynos_drm_ops = {
>> -.add_components = exynos_drm_add_components,
>> .bind = exynos_drm_bind,
>> .unbind = exynos_drm_unbind,
>> };
>>
>> static int exynos_drm_platform_probe(struct platform_device *pdev)
>> {
>> +struct component_match *match;
>&
[PATCH] drm/exynos: use a new anon file for exynos gem mmaper
On 2014? 09? 10? 18:01, Daniel Vetter wrote:
> Ok I've stumbled over the exynos mmap stuff again while cleaning up
> drm legacy cruft and I just don't get what you're doing and why
> exactly exynos needs to be special.
>
> _All_ other drm drivers happily get along with the vma offset manger
> stuff to handle mmaps, but somehow exynos does something really crazy.
We are also using the vma offset manager stuff. We just added direct
mapping interface specific to Exynos additionally.
>
> Can you please explain the design justification for this and why
> switching to the standard gem mmap support isn't possible?
As I mentioned above, we are using the standard gem mmap support.
However, the standard gem mmap is required for on-demand paging mostly
suitable for Desktop. In case of ARM SoC, whole memory region requested
by userspace would be allocated once the gem creation interface is
called. In this case, it wouldn't need to map userspace with physical
page in page fault handler, and the use of the vma offset manager stuff
would be unnecessary step.
For the same question, Al Viro did,
http://lists.freedesktop.org/archives/dri-devel/2013-September/046207.html
Is there any issue I am missing , that could be incurred by Exynos codes?
Thanks,
Inki Dae
>
> Thanks, Daniel
>
>
> On Fri, Dec 20, 2013 at 11:36 AM, Inki Dae wrote:
>> This patch resolves potential deadlock issue that can be incurred
>> by changing file->f_op and filp->private_data to exynos specific
>> mapper ops and gem object temporarily.
>>
>> To resolve this issue, this patch creates a new anon file dedicated
>> to exynos specific mmaper, and making it used instead of existing one.
>>
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 21 +
>> drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 74
>> ++-
>> drivers/gpu/drm/exynos/exynos_drm_gem.h |3 ++
>> 4 files changed, 38 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 22b8f5e..b5e5957 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -14,6 +14,8 @@
>> #include
>> #include
>>
>> +#include
>> +
>> #include
>>
>> #include "exynos_drm_drv.h"
>> @@ -150,9 +152,14 @@ static int exynos_drm_unload(struct drm_device *dev)
>> return 0;
>> }
>>
>> +static const struct file_operations exynos_drm_gem_fops = {
>> + .mmap = exynos_drm_gem_mmap_buffer,
>> +};
>> +
>> static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>> {
>> struct drm_exynos_file_private *file_priv;
>> + struct file *anon_filp;
>> int ret;
>>
>> file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
>> @@ -167,6 +174,16 @@ static int exynos_drm_open(struct drm_device *dev,
>> struct drm_file *file)
>> file->driver_priv = NULL;
>> }
>>
>> + anon_filp = anon_inode_getfile("exynos_gem", _drm_gem_fops,
>> + NULL, 0);
>> + if (IS_ERR(anon_filp)) {
>> + kfree(file_priv);
>> + return PTR_ERR(anon_filp);
>> + }
>> +
>> + anon_filp->f_mode = FMODE_READ | FMODE_WRITE;
>> + file_priv->anon_filp = anon_filp;
>> +
>> return ret;
>> }
>>
>> @@ -179,6 +196,7 @@ static void exynos_drm_preclose(struct drm_device *dev,
>> static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
>> *file)
>> {
>> struct exynos_drm_private *private = dev->dev_private;
>> + struct drm_exynos_file_private *file_priv;
>> struct drm_pending_vblank_event *v, *vt;
>> struct drm_pending_event *e, *et;
>> unsigned long flags;
>> @@ -204,6 +222,9 @@ static void exynos_drm_postclose(struct drm_device *dev,
>> struct drm_file *file)
>> }
>> spin_unlock_irqrestore(>event_lock, flags);
>>
>> + file_priv = file->driver_priv;
>> + if (file_priv->anon_filp)
>> + fput(file_priv->anon_filp);
>>
>> kfree(file->driver_priv);
>> file->driver_priv = NULL;
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>
[PATCH] drm/exynos: update to use component match support
On 2014? 09? 10? 19:24, Andrzej Hajda wrote:
> Hi Inki,
>
> To test it properly I have to fix init/remove bugs [1].
> Of course these bugs were not introduced by this patch,
> but they prevented some basic tests.
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37266
>
> I have tested successfully your patch with trats and universal_c210 boards.
>
> Few additional comments below.
>
> On 09/01/2014 02:19 PM, Inki Dae wrote:
>> Update Exynos's DRM driver to use component match support rater than
>> add_components.
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 40
>> ++-
>> 1 file changed, 18 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index feee991..dae62c2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -503,16 +503,15 @@ static int compare_of(struct device *dev, void *data)
>> return dev == (struct device *)data;
>> }
>
> Nitpick.
>
> This is not a part of this patch but compare_of suggests it compares OF
> nodes but this function compares devices, maybe compare_dev would be better.
Agree.
>
>>
>> -static int exynos_drm_add_components(struct device *dev, struct master *m)
>> +static struct component_match *exynos_drm_match_add(struct device *dev)
>> {
>> +struct component_match *match = NULL;
>> struct component_dev *cdev;
>> unsigned int attach_cnt = 0;
>>
>> mutex_lock(_component_lock);
>>
>> list_for_each_entry(cdev, _component_list, list) {
>> -int ret;
>> -
>> /*
>> * Add components to master only in case that crtc and
>> * encoder/connector device objects exist.
>> @@ -527,16 +526,10 @@ static int exynos_drm_add_components(struct device
>> *dev, struct master *m)
>> /*
>> * fimd and dpi modules have same device object so add
>> * only crtc device object in this case.
>> - *
>> - * TODO. if dpi module follows driver-model driver then
>> - * below codes can be removed.
>> */
>> if (cdev->crtc_dev == cdev->conn_dev) {
>> -ret = component_master_add_child(m, compare_of,
>> -cdev->crtc_dev);
>> -if (ret < 0)
>> -return ret;
>> -
>> +component_match_add(dev, , compare_of,
>> +cdev->crtc_dev);
>> goto out_lock;
>> }
>>
>> @@ -546,11 +539,8 @@ static int exynos_drm_add_components(struct device
>> *dev, struct master *m)
>> * connector/encoder need pipe number of crtc when they
>> * are created.
>> */
>> -ret = component_master_add_child(m, compare_of, cdev->crtc_dev);
>> -ret |= component_master_add_child(m, compare_of,
>> -cdev->conn_dev);
>> -if (ret < 0)
>> -return ret;
>> +component_match_add(dev, , compare_of, cdev->crtc_dev);
>> +component_match_add(dev, , compare_of, cdev->conn_dev);
>>
>> out_lock:
>> mutex_lock(_component_lock);
>> @@ -558,7 +548,7 @@ out_lock:
>>
>> mutex_unlock(_component_lock);
>>
>> -return attach_cnt ? 0 : -ENODEV;
>> +return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
>> }
>>
>> static int exynos_drm_bind(struct device *dev)
>> @@ -572,13 +562,13 @@ static void exynos_drm_unbind(struct device *dev)
>> }
>>
>> static const struct component_master_ops exynos_drm_ops = {
>> -.add_components = exynos_drm_add_components,
>> .bind = exynos_drm_bind,
>> .unbind = exynos_drm_unbind,
>> };
>>
>> static int exynos_drm_platform_probe(struct platform_device *pdev)
>> {
>> +struct component_match *match;
>> int ret;
>>
>> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> @@ -645,13 +635,19 @@ static int exynos_drm_platform_probe(struct
>> platform_device *pdev)
>> goto err_unregister_ipp_drv;
>> #endif
>>
[PATCH] drm/exynos: update to use component match support
Update Exynos's DRM driver to use component match support rater than
add_components.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 40 ++-
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index feee991..dae62c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -503,16 +503,15 @@ static int compare_of(struct device *dev, void *data)
return dev == (struct device *)data;
}
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+ struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(_component_lock);
list_for_each_entry(cdev, _component_list, list) {
- int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -527,16 +526,10 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
-*
-* TODO. if dpi module follows driver-model driver then
-* below codes can be removed.
*/
if (cdev->crtc_dev == cdev->conn_dev) {
- ret = component_master_add_child(m, compare_of,
- cdev->crtc_dev);
- if (ret < 0)
- return ret;
-
+ component_match_add(dev, , compare_of,
+ cdev->crtc_dev);
goto out_lock;
}
@@ -546,11 +539,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
- ret = component_master_add_child(m, compare_of, cdev->crtc_dev);
- ret |= component_master_add_child(m, compare_of,
- cdev->conn_dev);
- if (ret < 0)
- return ret;
+ component_match_add(dev, , compare_of, cdev->crtc_dev);
+ component_match_add(dev, , compare_of, cdev->conn_dev);
out_lock:
mutex_lock(_component_lock);
@@ -558,7 +548,7 @@ out_lock:
mutex_unlock(_component_lock);
- return attach_cnt ? 0 : -ENODEV;
+ return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -572,13 +562,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
- .add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+ struct component_match *match;
int ret;
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -645,13 +635,19 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- ret = component_master_add(>dev, _drm_ops);
- if (ret < 0)
- DRM_DEBUG_KMS("re-tried by last sub driver probed later.\n");
+ match = exynos_drm_match_add(>dev);
+ if (IS_ERR(match)) {
+ ret = PTR_ERR(match);
+ goto err_unregister_ipp_dev;
+ }
- return 0;
+ return component_master_add_with_match(>dev, _drm_ops,
+ match);
+
+err_unregister_ipp_dev:
#ifdef CONFIG_DRM_EXYNOS_IPP
+ exynos_platform_device_ipp_unregister();
err_unregister_ipp_drv:
platform_driver_unregister(_driver);
err_unregister_gsc_drv:
--
1.7.9.5
[PATCH RFC v2 3/8] component: add support for component match array
On 2014? 08? 31? 06:33, Russell King - ARM Linux wrote:
> On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote:
>> 2014-07-01 23:22 GMT+09:00 Russell King - ARM Linux > arm.linux.org.uk>:
>>> On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote:
>>>> On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
>>>>> Hi Russell,
>>>>>
>>>>> On Tue, Jun 24, 2014 at 9:29 PM, Russell King
>>>>> <rmk+kernel at arm.linux.org.uk> wrote:
>>>>> [...]
>>>>>> +/*
>>>>>> + * Add a component to be matched.
>>>>>> + *
>>>>>> + * The match array is first created or extended if necessary.
>>>>>> + */
>>>>>> +void component_match_add(struct device *dev, struct component_match
>>>>>> **matchptr,
>>>>>> + int (*compare)(struct device *, void *), void *compare_data)
>>>>>> +{
>>>>>> + struct component_match *match = *matchptr;
>>>>>> +
>>>>>> + if (IS_ERR(match))
>>>>>> + return;
>>>>>> +
>>>>>> + if (!match || match->num == match->alloc) {
>>>>>> + size_t new_size = match ? match->alloc + 16 : 15;
>>>>>> +
>>>>>> + match = component_match_realloc(dev, match, new_size);
>>>>>> +
>>>>>> + *matchptr = match;
>>>>>> +
>>>>>> + if (IS_ERR(match))
>>>>>> + return;
>>>>>> + }
>>>>>> +
>>>>>> + match->compare[match->num].fn = compare;
>>>>>> + match->compare[match->num].data = compare_data;
>>>>>> + match->num++;
>>>>>> +}
>>>>>
>>>>> component_match_add should be exported.
>>>>
>>>> Fixed, thanks.
>>>
>>> As there's no further comments, and Inki Dae has not responded, I'm
>>
>> It's has been just a week. I will check and look into your patch
>> series. I think Exynos drm should also be considered for the use of
>> component match array.
>
> It has now been almost two months. What's happening on this?
>
> Please note that I'm planning to push the rest of the component updates
> during the next merge window, which will result in unconverted drivers
> breaking.
>
Sorry for this. I was busy with other works. I will update and post it
until this week.
Thanks,
Inki Dae
> Thanks.
>
[PATCH 1/2] drm/mipi-dsi: consider low power transmission
On 2014? 08? 18? 20:38, Andrzej Hajda wrote:
> On 08/18/2014 10:11 AM, Inki Dae wrote:
>> This patch adds a new flag, MIPI_DSI-MODE_LPM, to transmit data
>> in low power. With this flag, msg.flags has MIPI_DSI_MSG_USE_LPM
>> so that host driver of each SoC can clear or set relevant register
>> bit for low power transmission.
>>
>> All host drivers shall support continuous clock behavior on the
>> Clock Lane, and optionally may support non-continuous clock behavior.
>> Both of them can transmit data in high speed of low power.
>>
>> With each clock behavior, non-continuous or continuous clock mode,
>> host controller will transmit data in high speed by default so if
>> peripheral wants to receive data in low power, the peripheral driver
>> should set MIPI_DSI_MODE_LPM flag.
>
> I think it would be better to remove last two paragraphs as irrelevant,
> LPM and clock behavior are orthogonal.
>
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/drm_mipi_dsi.c |6 ++
>> include/drm/drm_mipi_dsi.h |2 ++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
>> index 6aa6a9e..eb6dfe5 100644
>> --- a/drivers/gpu/drm/drm_mipi_dsi.c
>> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
>> @@ -231,6 +231,9 @@ ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
>> const void *data,
>> break;
>> }
>>
>> +if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
>> +msg.flags = MIPI_DSI_MSG_USE_LPM;
>> +
>> return ops->transfer(dsi->host, );
>> }
>> EXPORT_SYMBOL(mipi_dsi_dcs_write);
>> @@ -260,6 +263,9 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi,
>> u8 cmd, void *data,
>> if (!ops || !ops->transfer)
>> return -ENOSYS;
>>
>> +if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
>> +msg.flags = MIPI_DSI_MSG_USE_LPM;
>> +
>
> I see three other ways of adding LPM to DCS:
>
> 1. Add flags argument to DCS command, eg:
>mipi_dsi_dcs_write(dsi, data, len, flags)
>
> 2. Pass struct mipi_dsi_device to transfer callback:
> ssize_t (*transfer)(struct mipi_dsi_device *dsi,
> struct mipi_dsi_msg *msg);
>or
> ssize_t (*transfer)(struct mipi_dsi_host *host,
> struct mipi_dsi_device *dsi,
> struct mipi_dsi_msg *msg);
>
> This way DSI host will have access to mipi_dsi_device
> and to its flags.
>
> 3. Create new API function, lets call it dsi_transfer, which
> should by called by DCS helpers instead of transfer op.
> This function shall translate device flags to message flags
> and call the original op.
>
> I think the 3rd solution is the best one, but I have no strong feelings
> against the other ones, including your.
> As I remember Thierry have also some ideas about changes in DSI API
> so I have added him to CC.
Thanks for comments and CCing Thierry.
I think it'd better to handle this solution flexibly. There was a
concern that my solution makes all commands to be transmitted in low
power or high speed by default. So if we have other solution which
passes a flag per a message, then we could transmit each command in low
power or high speed, which could also be used selectively with my
solution - if msg->flags has MIPI_DSI_MODE_LPM, then each flag of the
new API is ignored.
Thierry, which one do you prefer? Otherwise, do you have other opinions?
Thanks,
Inki Dae
>
> Regards
> Andrzej
>
>
>> return ops->transfer(dsi->host, );
>> }
>> EXPORT_SYMBOL(mipi_dsi_dcs_read);
>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>> index 2bb55b8..8569dc5 100644
>> --- a/include/drm/drm_mipi_dsi.h
>> +++ b/include/drm/drm_mipi_dsi.h
>> @@ -96,6 +96,8 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
>> #define MIPI_DSI_MODE_EOT_PACKETBIT(9)
>> /* device supports non-continuous clock behavior (DSI spec 5.6.1) */
>> #define MIPI_DSI_CLOCK_NON_CONTINUOUS BIT(10)
>> +/* transmit data in low power */
>> +#define MIPI_DSI_MODE_LPM BIT(11)
>>
>> enum mipi_dsi_pixel_format {
>> MIPI_DSI_FMT_RGB888,
>
>
[PATCH] drm/exynos: dsi: fix exynos_dsi_set_pll() wrong return value
On 2014? 08? 14? 11:22, YoungJun Cho wrote:
> The type of this function is unsigned long, and it is expected
> to return proper fout value or zero if something is wrong.
> So this patch fixes wrong return value for error cases.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: YoungJun Cho
> Acked-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 86aebd8..061017b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -421,7 +421,7 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi
> *dsi,
> if (!fout) {
> dev_err(dsi->dev,
> "failed to find PLL PMS for requested frequency\n");
> - return -EFAULT;
> + return 0;
> }
> dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
>
> @@ -453,7 +453,7 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi
> *dsi,
> do {
> if (timeout-- == 0) {
> dev_err(dsi->dev, "PLL failed to stabilize\n");
> - return -EFAULT;
> + return 0;
> }
> reg = readl(dsi->reg_base + DSIM_STATUS_REG);
> } while ((reg & DSIM_PLL_STABLE) == 0);
>
[PATCH 5/5] ARM: dts: add mipi dsi device node to exynos3250.dtsi
Signed-off-by: Inki Dae
---
arch/arm/boot/dts/exynos3250.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 2bab12f..480dedf 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -234,6 +234,21 @@
status = "disabled";
};
+ dsi_0: dsi at 11C8 {
+ compatible = "samsung,exynos3250-mipi-dsi";
+ reg = <0x11C8 0x1>;
+ interrupts = <0 83 0>;
+ samsung,phy-type = <0>;
+ samsung,power-domain = <_lcd0>;
+ phys = <_phy 1>;
+ phy-names = "dsim";
+ clocks = < CLK_DSIM0>, < CLK_SCLK_MIPI0>;
+ clock-names = "bus_clk", "pll_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mshc_0: mshc at 1251 {
compatible = "samsung,exynos5250-dw-mshc";
reg = <0x1251 0x1000>;
--
1.7.9.5
[PATCH 4/5] ARM: dts: add mipi_phy device node to exynos3250.dtsi
This patch adds mipi_phy device node to reset, disable and enable
DSIM and CSIS PHY.
Signed-off-by: Inki Dae
---
arch/arm/boot/dts/exynos3250.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 0ec2584..2bab12f 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -132,6 +132,12 @@
reg = <0x1002 0x4000>;
};
+ mipi_phy: video-phy at 10020710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10020710 8>;
+ #phy-cells = <1>;
+ };
+
pd_cam: cam-power-domain at 10023C00 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x20>;
--
1.7.9.5
[PATCH 3/5] ARM: dts: add fimd device node to exynos3250.dsti
Signed-off-by: Inki Dae
---
arch/arm/boot/dts/exynos3250.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 1d52de6..0ec2584 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -216,6 +216,18 @@
interrupts = <0 240 0>;
};
+ fimd: fimd at 11c0 {
+ compatible = "samsung,exynos3250-fimd";
+ reg = <0x11c0 0x3>;
+ interrupt-names = "fifo", "vsync", "lcd_sys";
+ interrupts = <0 84 0>, <0 85 0>, <0 86 0>;
+ clocks = < CLK_SCLK_FIMD0>, < CLK_FIMD0>;
+ clock-names = "sclk_fimd", "fimd";
+ samsung,power-domain = <_lcd0>;
+ samsung,sysreg = <_reg>;
+ status = "disabled";
+ };
+
mshc_0: mshc at 1251 {
compatible = "samsung,exynos5250-dw-mshc";
reg = <0x1251 0x1000>;
--
1.7.9.5
[PATCH 2/5] drm/exynos: fimd: add Exynos3 SoC support
Signed-off-by: Inki Dae
---
.../devicetree/bindings/video/samsung-fimd.txt |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index ecc899b..4e6c77c 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -9,6 +9,7 @@ Required properties:
"samsung,s3c2443-fimd"; /* for S3C24XX SoCs */
"samsung,s3c6400-fimd"; /* for S3C64XX SoCs */
"samsung,s5pv210-fimd"; /* for S5PV210 SoC */
+ "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */
"samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
"samsung,exynos5250-fimd"; /* for Exynos5 SoCs */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 5d09e33..909e647 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -104,6 +104,14 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
.has_limited_fmt = 1,
};
+static struct fimd_driver_data exynos3_fimd_driver_data = {
+ .timing_base = 0x2,
+ .lcdblk_offset = 0x210,
+ .lcdblk_bypass_shift = 1,
+ .has_shadowcon = 1,
+ .has_vidoutcon = 1,
+};
+
static struct fimd_driver_data exynos4_fimd_driver_data = {
.timing_base = 0x0,
.lcdblk_offset = 0x210,
@@ -168,6 +176,8 @@ struct fimd_context {
static const struct of_device_id fimd_driver_dt_match[] = {
{ .compatible = "samsung,s3c6400-fimd",
.data = _fimd_driver_data },
+ { .compatible = "samsung,exynos3250-fimd",
+ .data = _fimd_driver_data },
{ .compatible = "samsung,exynos4210-fimd",
.data = _fimd_driver_data },
{ .compatible = "samsung,exynos5250-fimd",
--
1.7.9.5
[PATCH 1/5] drm/exynos: mipi-dsi: add Exynos3 SoC support
This patch adds Exynos3250/3472 SoCs support.
Signed-off-by: Inki Dae
---
.../devicetree/bindings/video/exynos_dsim.txt |1 +
drivers/gpu/drm/exynos/exynos_drm_dsi.c|8
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 31036c6..e74243b 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -2,6 +2,7 @@ Exynos MIPI DSI Master
Required properties:
- compatible: value should be one of the following
+ "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */
"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs
*/
- reg: physical base address and length of the registers set for the device
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 9a186c0..a8c0c4f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -304,6 +304,12 @@ struct exynos_dsi {
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
#define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
+static struct exynos_dsi_driver_data exynos3_dsi_driver_data = {
+ .plltmr_reg = 0x50,
+ .has_freqband = 1,
+ .has_clklane_stop = 1,
+};
+
static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
.plltmr_reg = 0x50,
.has_freqband = 1,
@@ -315,6 +321,8 @@ static struct exynos_dsi_driver_data
exynos5_dsi_driver_data = {
};
static struct of_device_id exynos_dsi_of_match[] = {
+ { .compatible = "samsung,exynos3250-mipi-dsi",
+ .data = _dsi_driver_data },
{ .compatible = "samsung,exynos4210-mipi-dsi",
.data = _dsi_driver_data },
{ .compatible = "samsung,exynos5410-mipi-dsi",
--
1.7.9.5
[PATCH 0/5] drm/exynos: support Exynos3250 SoC
This patch series adds of_device_id and relevant device nodes for Exynos3250 SoC support. Inki Dae (5): drm/exynos: mipi-dsi: add Exynos3 SoC support drm/exynos: fimd: add Exynos3 SoC support ARM: dts: add fimd device node to exynos3250.dsti ARM: dts: add mipi_phy device node to exynos3240.dtsi ARM: dts: add mipi dsi device node to exynos3250.dtsi .../devicetree/bindings/video/exynos_dsim.txt |1 + .../devicetree/bindings/video/samsung-fimd.txt |1 + arch/arm/boot/dts/exynos3250.dtsi | 33 drivers/gpu/drm/exynos/exynos_drm_dsi.c|8 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++ 5 files changed, 53 insertions(+) -- 1.7.9.5
[PATCH 2/2] drm/exynos: mipi-dsi: consider non-continuous clock mode
This patch adds non-continuous clock mode support
Clock mode on Clock Lane is continuous clock by default.
So if we want to transmit data in non-continuous clock mode
to reduce power consumption, then host driver should set
DSIM_CLKLANE_STOP bit. In this case, host controller turns off
HS clock between high speed transmissions.
For this, this patch adds a new bit, DSIM_CLKLANE_STOP, and makes
the host driver set this bit only in case that dsi->mode_flags has
MIPI_DSI_CLOCK_NON_CONTINUOUS flag.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 442aa2d..2d47290 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -114,6 +114,8 @@
#define DSIM_SYNC_INFORM (1 << 27)
#define DSIM_EOT_DISABLE (1 << 28)
#define DSIM_MFLUSH_VS (1 << 29)
+/* This flag is valid only for exynos3250/3472/4415/5260/5430 */
+#define DSIM_CLKLANE_STOP (1 << 30)
/* DSIM_ESCMODE */
#define DSIM_TX_TRIGGER_RST(1 << 4)
@@ -262,6 +264,7 @@ struct exynos_dsi_driver_data {
unsigned int plltmr_reg;
unsigned int has_freqband:1;
+ unsigned int has_clklane_stop:1;
};
struct exynos_dsi {
@@ -304,6 +307,7 @@ struct exynos_dsi {
static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
.plltmr_reg = 0x50,
.has_freqband = 1,
+ .has_clklane_stop = 1,
};
static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
@@ -569,6 +573,7 @@ static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
static int exynos_dsi_init_link(struct exynos_dsi *dsi)
{
+ struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
int timeout;
u32 reg;
u32 lanes_mask;
@@ -650,6 +655,20 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
reg |= DSIM_LANE_EN(lanes_mask);
writel(reg, dsi->reg_base + DSIM_CONFIG_REG);
+ /*
+* Use non-continuous clock mode if the periparal wants and
+* host controller supports
+*
+* In non-continous clock mode, host controller will turn off
+* the HS clock between high-speed transmissions to reduce
+* power consumption.
+*/
+ if (driver_data->has_clklane_stop &&
+ dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
+ reg |= DSIM_CLKLANE_STOP;
+ writel(reg, dsi->reg_base + DSIM_CONFIG_REG);
+ }
+
/* Check clock and data lane state are stop state */
timeout = 100;
do {
--
1.7.9.5
[PATCH 1/2] drm/mipi-dsi: consider low power transmission
This patch adds a new flag, MIPI_DSI-MODE_LPM, to transmit data
in low power. With this flag, msg.flags has MIPI_DSI_MSG_USE_LPM
so that host driver of each SoC can clear or set relevant register
bit for low power transmission.
All host drivers shall support continuous clock behavior on the
Clock Lane, and optionally may support non-continuous clock behavior.
Both of them can transmit data in high speed of low power.
With each clock behavior, non-continuous or continuous clock mode,
host controller will transmit data in high speed by default so if
peripheral wants to receive data in low power, the peripheral driver
should set MIPI_DSI_MODE_LPM flag.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_mipi_dsi.c |6 ++
include/drm/drm_mipi_dsi.h |2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 6aa6a9e..eb6dfe5 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -231,6 +231,9 @@ ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
const void *data,
break;
}
+ if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, );
}
EXPORT_SYMBOL(mipi_dsi_dcs_write);
@@ -260,6 +263,9 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8
cmd, void *data,
if (!ops || !ops->transfer)
return -ENOSYS;
+ if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, );
}
EXPORT_SYMBOL(mipi_dsi_dcs_read);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 2bb55b8..8569dc5 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -96,6 +96,8 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
/* device supports non-continuous clock behavior (DSI spec 5.6.1) */
#define MIPI_DSI_CLOCK_NON_CONTINUOUS BIT(10)
+/* transmit data in low power */
+#define MIPI_DSI_MODE_LPM BIT(11)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
--
1.7.9.5
[PATCH 0/2] drm/mipi-dsi: support low power transmission
This patch considers low power transmisson to two clock behaviors, non-continuous and continuous clock mode. These two clock behaviors can transmit data in high speed or low power. So this patch series adds a new flag, MIPI_DSI_MODE_LPM so that each host driver can setup its host controller properly. Patch 1: Add MIPI_DSI_MODE_LPM flag. If panel driver sets this flag, then msg->flags will have MIPI_DSI_MSG_USE_LPM so that host driver can transmit data in low power. Patch 2: Just exynos part for supporting non-continuous and continuous clock mode. Inki Dae (2): drm/mipi-dsi: consider low power transmission drm/exynos: mipi-dsi: consider non-continuous clock mode drivers/gpu/drm/drm_mipi_dsi.c |6 ++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 +++ include/drm/drm_mipi_dsi.h |2 ++ 3 files changed, 27 insertions(+) -- 1.7.9.5
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 12? 20:54, YoungJun Cho wrote: > Hi Inki, Andrzej > > On 08/11/2014 04:09 PM, Inki Dae wrote: >> On 2014? 08? 08? 18:40, Andrzej Hajda wrote: >>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: >>>> On 08/08/2014 09:37 AM, Inki Dae wrote: >>>>> On 2014? 08? 08? 16:03, Thierry Reding wrote: >>>>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >>>>>>> On 2014? 08? 07? 22:55, Thierry Reding wrote: >>>>>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: >>>>>>>>> On 2014? 08? 07? 22:17, Thierry Reding wrote: >>>>>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: >>>>>>>>>>> On 2014? 08? 07? 20:09, Thierry Reding wrote: >>>>>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >>>>>>>>>>>>> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>>>>>>>>>>>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means >>>>>>>>>>>>>>>>>> that the host can >>>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. >>>>>>>>>>>>>>>>>> I think Andrzej >>>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this >>>>>>>>>>>>>>>>>> is an optional >>>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra >>>>>>>>>>>>>>>>>> circuitry that >>>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't >>>>>>>>>>>>>>>>>> have such circuitry >>>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between >>>>>>>>>>>>>>>>>> transmissions and >>>>>>>>>>>>>>>>>> therefore require the HS clock to be always on >>>>>>>>>>>>>>>>>> (continuous mode). That's >>>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it >>>>>>>>>>>>>>>>>> advertises that the >>>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore >>>>>>>>>>>>>>>>>> the host can turn >>>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions. >>>>>>>>>>>>>>>>> What I don't make sure is this sentence. With >>>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible >>>>>>>>>>>>>>>>> operations. >>>>>>>>>>>>>>>>> One is, >>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a >>>>>>>>>>>>>>>>> register >>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and >>>>>>>>>>>>>>>>> negative lane all >>>>>>>>>>>>>>>>> are high). >>>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of
[PATCH 2/2] drm/exynos: mipi-dsi: consider non-continuous clock mode
This patch adds non-continuous clock mode support.
Clock mode on Clock Lane is continuous clock by default.
So if we want to transmit data in non-continuous clock mode
to reduce power consumption, then host driver should clear
DSIM_TX_REQUEST_HSCLK.
For this, this patch makes the host driver set DSIM_TX_REQUEST_HSCLK
only in case that dsi->mode_flags has no MIPI_DSI_CLOCK_NON_CONTINUOUS
flag.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32 +--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 86aebd8..8c43c96 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,17 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
- | DSIM_BYTE_CLK_SRC(0)
- | DSIM_TX_REQUEST_HSCLK;
+ | DSIM_BYTE_CLK_SRC(0);
+
+ /*
+* Set DSIM_TX_REQUEST_HSCLK only in case of not requesting
+* non-continous clock mode. So if MIPI_DSI_CLOCK_NON_CONTINUOUS,
+* then host controller will turn off the HS clock between high-speed
+* transmissions.
+*/
+ if (!(dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
return 0;
@@ -701,10 +710,29 @@ static void exynos_dsi_set_display_mode(struct exynos_dsi
*dsi)
dev_dbg(dsi->dev, "LCD size = %dx%d\n", vm->hactive, vm->vactive);
}
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+ bool enable)
+{
+ u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
+
+ reg &= ~DSIM_TX_REQUEST_HSCLK;
+ if (enable)
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
+ writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
+}
+
static void exynos_dsi_set_display_enable(struct exynos_dsi *dsi, bool enable)
{
u32 reg;
+ /*
+* Set DSIM_TX_REQUEST_HSCLK. In case of video data, host controller
+* will transmit the data in HS mode always.
+*/
+ if (enable)
+ exynos_dsi_enable_hs_clock(dsi, true);
+
reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
if (enable)
reg |= DSIM_MAIN_STAND_BY;
--
1.7.9.5
[PATCH 1/2] drm/mipi-dsi: consider low power transmission.
This patch adds a new flag, MIPI_DSI_MODE_LPM, to transmit data
in low power. With this flag, msg.flags has MIPI_DSI_MSG_USE_LPM
so that host driver of each SoC can clear or set relevant register
bit for low power transmission.
All host controllers shall support continuous clock behavior on the
Clock Lane, and optionally may support non-continuous clock behavior.
Both of them can transmit data in high speed or low power.
With each clock behavior, non-continuous or continuous clock mode,
host controller will transmit data in high speed by default so if
peripheral want to receive data in low power, the peripheral driver
should set MIPI_DSI_MODE_LPM flag.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/drm_mipi_dsi.c |6 ++
include/drm/drm_mipi_dsi.h |2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index e633df2..6cc0720 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
unsigned int channel,
break;
}
+ if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, );
}
EXPORT_SYMBOL(mipi_dsi_dcs_write);
@@ -262,6 +265,9 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi,
unsigned int channel,
if (!ops || !ops->transfer)
return -ENOSYS;
+ if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, );
}
EXPORT_SYMBOL(mipi_dsi_dcs_read);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index efa1b55..90d9f71 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -96,6 +96,8 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
/* device supports non-continuous clock behavior (DSI spec 5.6.1) */
#define MIPI_DSI_CLOCK_NON_CONTINUOUS BIT(10)
+/* transmit data in low power */
+#define MIPI_DSI_MODE_LPM BIT(11)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
--
1.7.9.5
[PATCH 0/2] drm/mipi-dsi: consider low power transmission
This patch considers low power transmisson to two clock behaviors, non-continuous and continuous clock mode. These two clock behaviors can transmit data in high speed or low power. So this patch series adds a new flag, MIPI_DSI_MODE_LPM so that each host driver can setup its host controller properly. Patch 1: Add MIPI_DSI_MODE_LPM flag, and with this flag, mipi-dsi framework will set MIPI_DSI_MSG_USE_LPM. Patch 2: Just exynos part for supporting non-continuous and continuous clock mode. Inki Dae (2): drm/mipi-dsi: consider low power transmission. drm/exynos: mipi-dsi: consider non-continuous clock mode drivers/gpu/drm/drm_mipi_dsi.c |6 ++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32 +-- include/drm/drm_mipi_dsi.h |2 ++ 3 files changed, 38 insertions(+), 2 deletions(-) -- 1.7.9.5
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 11? 18:11, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote: >> On 2014? 08? 11? 16:50, Thierry Reding wrote: >>> On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: >>>> On 2014? 08? 11? 16:24, Thierry Reding wrote: >>>>> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: >>>>>> On 2014? 08? 08? 18:55, Thierry Reding wrote: >>> [...] >>>>>>> The above is actually more like this: >>>>>>> >>>>>>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) >>>>>>> clear DSI_HS_CLK_CTRL; >>>>>>> else >>>>>>> set DSI_HS_CLK_CTRL; >>>>>>> >>>>>>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) >>>>>>> clear DSI_HIGH_SPEED_TRANS; >>>>>>> else >>>>>>> set DSI_HIGH_SPEED_TRANS; >>>>>>> >>>>>>> So for peripherals that don't support non-continuous clock mode, this >>>>>>> will result in the following for low-power transmissions: >>>>>>> >>>>>>> clear DSI_HS_CLK_CTRL; /* HS clock always on */ >>>>>>> clear DSI_HIGH_SPEED_TRANS; >>>>>> >>>>>> Right, then how host driver should check it if peripheral doesn't >>>>>> support non-continuous clock mode? Or how the peripheral should notify >>>>>> it to host driver? It would need a new flag instead of >>>>>> MIPI_DSI_MODE_NON_CONTINUOUS. >>>>> >>>>> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to >>>>> set to signal that they support non-continuous mode. If devices don't >>>>> have that set, then the controller should always provide the HS clock. >>>>> >>>>> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral >>>>> does *not* support non-continuous mode. >>>>> >>>> >>>> Again, assume that there is a peripheral that doesn't support >>>> non-continuous clock mode but host driver want to transmit data in low >>>> power. For this, you already mentioned like below, >>>> >>>> "So for peripherals that don't support non-continuous clock mode, this >>>> will result in the following for low-power transmissions: >>>> >>>>clear DSI_HS_CLK_CTRL; /* HS clock always on */ >>>>clear DSI_HIGH_SPEED_TRANS; >>>> " >>>> >>>> In this case, how should host driver check it to clear above two flags? >>>> As you know, this is required to clear two flags same as non-continuous >>>> clock mode. Don't you think that we need a new flag to identify them - >>>> non-continuous clock mode or just for low-power transmission? >>> >>> See what I wrote a little further up: >>> >>>>>>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) >>>>>>> clear DSI_HS_CLK_CTRL; >>>>>>> else >>>>>>> set DSI_HS_CLK_CTRL; >>>>>>> >>>>>>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) >>>>>>> clear DSI_HIGH_SPEED_TRANS; >>>>>>> else >>>>>>> set DSI_HIGH_SPEED_TRANS; >>>>>>> >>> >>> MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- >>> continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because >>> that tells the controller to turn off the HS clock between high-speed >>> transmissions. >>> >>> MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power >>> mode. >>> >>> With the above two flags we can cover four cases: >>> >>> 1) non-continuous mode with messages transmitted in low-power mode >>> 2) non-continuous mode with messages transmitted in high-speed mode >>> 3) continuous mode with messages transmitted in low-power mode >> >> In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear >> DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but >> dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right. >&g
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 11? 16:50, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote: >> On 2014? 08? 11? 16:24, Thierry Reding wrote: >>> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: >>>> On 2014? 08? 08? 18:55, Thierry Reding wrote: > [...] >>>>> The above is actually more like this: >>>>> >>>>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) >>>>> clear DSI_HS_CLK_CTRL; >>>>> else >>>>> set DSI_HS_CLK_CTRL; >>>>> >>>>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) >>>>> clear DSI_HIGH_SPEED_TRANS; >>>>> else >>>>> set DSI_HIGH_SPEED_TRANS; >>>>> >>>>> So for peripherals that don't support non-continuous clock mode, this >>>>> will result in the following for low-power transmissions: >>>>> >>>>> clear DSI_HS_CLK_CTRL; /* HS clock always on */ >>>>> clear DSI_HIGH_SPEED_TRANS; >>>> >>>> Right, then how host driver should check it if peripheral doesn't >>>> support non-continuous clock mode? Or how the peripheral should notify >>>> it to host driver? It would need a new flag instead of >>>> MIPI_DSI_MODE_NON_CONTINUOUS. >>> >>> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to >>> set to signal that they support non-continuous mode. If devices don't >>> have that set, then the controller should always provide the HS clock. >>> >>> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral >>> does *not* support non-continuous mode. >>> >> >> Again, assume that there is a peripheral that doesn't support >> non-continuous clock mode but host driver want to transmit data in low >> power. For this, you already mentioned like below, >> >> "So for peripherals that don't support non-continuous clock mode, this >> will result in the following for low-power transmissions: >> >> clear DSI_HS_CLK_CTRL; /* HS clock always on */ >> clear DSI_HIGH_SPEED_TRANS; >> " >> >> In this case, how should host driver check it to clear above two flags? >> As you know, this is required to clear two flags same as non-continuous >> clock mode. Don't you think that we need a new flag to identify them - >> non-continuous clock mode or just for low-power transmission? > > See what I wrote a little further up: > >>>>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) >>>>> clear DSI_HS_CLK_CTRL; >>>>> else >>>>> set DSI_HS_CLK_CTRL; >>>>> >>>>> if (msg->flags & MIPI_DSI_MSG_USE_LPM) >>>>> clear DSI_HIGH_SPEED_TRANS; >>>>> else >>>>> set DSI_HIGH_SPEED_TRANS; >>>>> > > MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non- > continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because > that tells the controller to turn off the HS clock between high-speed > transmissions. > > MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power > mode. > > With the above two flags we can cover four cases: > > 1) non-continuous mode with messages transmitted in low-power mode > 2) non-continuous mode with messages transmitted in high-speed mode > 3) continuous mode with messages transmitted in low-power mode In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right. You mean that continuous mode is set by default implicitly? Thanks, Inki Dae > 4) continuous mode with messages transmitted in high-speed mode > > What other cases do you think we need to support? > > Thierry >
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 11? 16:44, Andrzej Hajda wrote: > On 08/11/2014 09:09 AM, Inki Dae wrote: >> On 2014? 08? 08? 18:40, Andrzej Hajda wrote: >>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote: >>>> On 08/08/2014 09:37 AM, Inki Dae wrote: >>>>> On 2014? 08? 08? 16:03, Thierry Reding wrote: >>>>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >>>>>>> On 2014? 08? 07? 22:55, Thierry Reding wrote: >>>>>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: >>>>>>>>> On 2014? 08? 07? 22:17, Thierry Reding wrote: >>>>>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: >>>>>>>>>>> On 2014? 08? 07? 20:09, Thierry Reding wrote: >>>>>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >>>>>>>>>>>>> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>>>>>>>>>>>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >>>>>>>>>>>>>>>> gmail.com>: >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that >>>>>>>>>>>>>>>>>> the host can >>>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I >>>>>>>>>>>>>>>>>> think Andrzej >>>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an >>>>>>>>>>>>>>>>>> optional >>>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra >>>>>>>>>>>>>>>>>> circuitry that >>>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such >>>>>>>>>>>>>>>>>> circuitry >>>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions >>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous >>>>>>>>>>>>>>>>>> mode). That's >>>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it >>>>>>>>>>>>>>>>>> advertises that the >>>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the >>>>>>>>>>>>>>>>>> host can turn >>>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions. >>>>>>>>>>>>>>>>> What I don't make sure is this sentence. With >>>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible >>>>>>>>>>>>>>>>> operations. >>>>>>>>>>>>>>>>> One is, >>>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a >>>>>>>>>>>>>>>>> register >>>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative >>>>>>>>>>>>>>>>> lane all >>>>>>>>>>>>>>>>> are high). >>>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller.
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 11? 16:24, Thierry Reding wrote: > On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote: >> On 2014? 08? 08? 18:55, Thierry Reding wrote: >>> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote: >>>> On 2014? 08? 08? 16:03, Thierry Reding wrote: >>>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >>>>>> On 2014? 08? 07? 22:55, Thierry Reding wrote: >>>>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: >>>>>>>> On 2014? 08? 07? 22:17, Thierry Reding wrote: >>>>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: >>>>>>>>>> On 2014? 08? 07? 20:09, Thierry Reding wrote: >>>>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >>>>>>>>>>>> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>>>>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>>>>>>>>>>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >>>>>>>>>>>>>>> gmail.com>: >>>>>>>>>>>>> [...] >>>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that >>>>>>>>>>>>>>>>> the host can >>>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I >>>>>>>>>>>>>>>>> think Andrzej >>>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an >>>>>>>>>>>>>>>>> optional >>>>>>>>>>>>>>>>> mode that peripherals can support if they have extra >>>>>>>>>>>>>>>>> circuitry that >>>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such >>>>>>>>>>>>>>>>> circuitry >>>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous >>>>>>>>>>>>>>>>> mode). That's >>>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises >>>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the >>>>>>>>>>>>>>>>> host can turn >>>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What I don't make sure is this sentence. With >>>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible >>>>>>>>>>>>>>>> operations. >>>>>>>>>>>>>>>> One is, >>>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a >>>>>>>>>>>>>>>> register >>>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative >>>>>>>>>>>>>>>> lane all >>>>>>>>>>>>>>>> are high). >>>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller. >>>>>>>>>>>>>>>> 5. At this time, operation mode of host controller be
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 08? 18:40, Andrzej Hajda wrote: > On 08/08/2014 11:02 AM, Andrzej Hajda wrote: >> On 08/08/2014 09:37 AM, Inki Dae wrote: >>> On 2014? 08? 08? 16:03, Thierry Reding wrote: >>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >>>>> On 2014? 08? 07? 22:55, Thierry Reding wrote: >>>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: >>>>>>> On 2014? 08? 07? 22:17, Thierry Reding wrote: >>>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: >>>>>>>>> On 2014? 08? 07? 20:09, Thierry Reding wrote: >>>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >>>>>>>>>>> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>>>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>>>>>>>>>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >>>>>>>>>>>>>> gmail.com>: >>>>>>>>>>>> [...] >>>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the >>>>>>>>>>>>>>>> host can >>>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think >>>>>>>>>>>>>>>> Andrzej >>>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an >>>>>>>>>>>>>>>> optional >>>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such >>>>>>>>>>>>>>>> circuitry >>>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous >>>>>>>>>>>>>>>> mode). That's >>>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises >>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host >>>>>>>>>>>>>>>> can turn >>>>>>>>>>>>>>>> the HS clock off after high-speed transmissions. >>>>>>>>>>>>>>> What I don't make sure is this sentence. With >>>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible >>>>>>>>>>>>>>> operations. >>>>>>>>>>>>>>> One is, >>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative >>>>>>>>>>>>>>> lane all >>>>>>>>>>>>>>> are high). >>>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller. >>>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Other is, >>>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>&g
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 08? 18:55, Thierry Reding wrote: > On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote: >> On 2014? 08? 08? 16:03, Thierry Reding wrote: >>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >>>> On 2014? 08? 07? 22:55, Thierry Reding wrote: >>>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: >>>>>> On 2014? 08? 07? 22:17, Thierry Reding wrote: >>>>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: >>>>>>>> On 2014? 08? 07? 20:09, Thierry Reding wrote: >>>>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >>>>>>>>>> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>>>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>>>>>>>>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >>>>>>>>>>>>> gmail.com>: >>>>>>>>>>> [...] >>>>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the >>>>>>>>>>>>>>> host can >>>>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think >>>>>>>>>>>>>>> Andrzej >>>>>>>>>>>>>>> mentioned this already in another subthread, but this is an >>>>>>>>>>>>>>> optional >>>>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such >>>>>>>>>>>>>>> circuitry >>>>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and >>>>>>>>>>>>>>> therefore require the HS clock to be always on (continuous >>>>>>>>>>>>>>> mode). That's >>>>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises >>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host >>>>>>>>>>>>>>> can turn >>>>>>>>>>>>>>> the HS clock off after high-speed transmissions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What I don't make sure is this sentence. With >>>>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible >>>>>>>>>>>>>> operations. >>>>>>>>>>>>>> One is, >>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative >>>>>>>>>>>>>> lane all >>>>>>>>>>>>>> are high). >>>>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller. >>>>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Other is, >>>>>>>>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative >>>>>>>>>>>>>> lane all >>>>>>>>>>>>>> are high). >>>>>
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 08? 16:03, Thierry Reding wrote: > On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >> On 2014? 08? 07? 22:55, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: >>>> On 2014? 08? 07? 22:17, Thierry Reding wrote: >>>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: >>>>>> On 2014? 08? 07? 20:09, Thierry Reding wrote: >>>>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >>>>>>>> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>>>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>>>>>>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >>>>>>>>>>> gmail.com>: >>>>>>>>> [...] >>>>>>>>>>>>> As far as I can tell non-continuous mode simply means that the >>>>>>>>>>>>> host can >>>>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think >>>>>>>>>>>>> Andrzej >>>>>>>>>>>>> mentioned this already in another subthread, but this is an >>>>>>>>>>>>> optional >>>>>>>>>>>>> mode that peripherals can support if they have extra circuitry >>>>>>>>>>>>> that >>>>>>>>>>>>> provides an internal clock. Peripherals that don't have such >>>>>>>>>>>>> circuitry >>>>>>>>>>>>> may rely on the HS clock to perform in between transmissions and >>>>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). >>>>>>>>>>>>> That's >>>>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises >>>>>>>>>>>>> that the >>>>>>>>>>>>> peripheral supports non-continuous mode and therefore the host >>>>>>>>>>>>> can turn >>>>>>>>>>>>> the HS clock off after high-speed transmissions. >>>>>>>>>>>> >>>>>>>>>>>> What I don't make sure is this sentence. With >>>>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. >>>>>>>>>>>> One is, >>>>>>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane >>>>>>>>>>>> all >>>>>>>>>>>> are high). >>>>>>>>>>>> 4. And then D-PHY disables HS clock of host controller. >>>>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM. >>>>>>>>>>>> >>>>>>>>>>>> Other is, >>>>>>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane >>>>>>>>>>>> all >>>>>>>>>>>> are high). >>>>>>>>>>>> 3. And then video data is transmitted to panel in LPM. >>>>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM. >>>>>>>>>>>> >>>>>>>>>>>> It seems that you says latter case. >>>>>>>>>>> >>>>>>>>>>> No. High speed clock and low power mode are orthogonal. >>>>>>>>>>> Non-continuous >>>>>>>>>>> mode simply m
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 07? 22:55, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: >> On 2014? 08? 07? 22:17, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: >>>> On 2014? 08? 07? 20:09, Thierry Reding wrote: >>>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >>>>>> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>>>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>>>>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >>>>>>>>> gmail.com>: >>>>>>> [...] >>>>>>>>>>> As far as I can tell non-continuous mode simply means that the host >>>>>>>>>>> can >>>>>>>>>>> turn off the HS clock after a high-speed transmission. I think >>>>>>>>>>> Andrzej >>>>>>>>>>> mentioned this already in another subthread, but this is an optional >>>>>>>>>>> mode that peripherals can support if they have extra circuitry that >>>>>>>>>>> provides an internal clock. Peripherals that don't have such >>>>>>>>>>> circuitry >>>>>>>>>>> may rely on the HS clock to perform in between transmissions and >>>>>>>>>>> therefore require the HS clock to be always on (continuous mode). >>>>>>>>>>> That's >>>>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that >>>>>>>>>>> the >>>>>>>>>>> peripheral supports non-continuous mode and therefore the host can >>>>>>>>>>> turn >>>>>>>>>>> the HS clock off after high-speed transmissions. >>>>>>>>>> >>>>>>>>>> What I don't make sure is this sentence. With >>>>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. >>>>>>>>>> One is, >>>>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane >>>>>>>>>> all >>>>>>>>>> are high). >>>>>>>>>> 4. And then D-PHY disables HS clock of host controller. >>>>>>>>>> 5. At this time, operation mode of host controller becomes LPM. >>>>>>>>>> >>>>>>>>>> Other is, >>>>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane >>>>>>>>>> all >>>>>>>>>> are high). >>>>>>>>>> 3. And then video data is transmitted to panel in LPM. >>>>>>>>>> 4. At this time, operation mode of host controller becomes LPM. >>>>>>>>>> >>>>>>>>>> It seems that you says latter case. >>>>>>>>> >>>>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous >>>>>>>>> mode simply means that the clock lane enters LP-11 between HS >>>>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification). >>>>>>>>> >>>>>>>> >>>>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if >>>>>>>> non-continous mode is used. Right? >>>>>>> >>>>>>> No, I think as long as HS clock is enabled the clock lane won't enter >>>>>>> LP-11. Non-continuous mode means that the controller can disable the HS >>>>>>> clock between HS transmissions. So i
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 07? 22:17, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: >> On 2014? 08? 07? 20:09, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >>>> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >>>>>>> gmail.com>: >>>>> [...] >>>>>>>>> As far as I can tell non-continuous mode simply means that the host >>>>>>>>> can >>>>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej >>>>>>>>> mentioned this already in another subthread, but this is an optional >>>>>>>>> mode that peripherals can support if they have extra circuitry that >>>>>>>>> provides an internal clock. Peripherals that don't have such circuitry >>>>>>>>> may rely on the HS clock to perform in between transmissions and >>>>>>>>> therefore require the HS clock to be always on (continuous mode). >>>>>>>>> That's >>>>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the >>>>>>>>> peripheral supports non-continuous mode and therefore the host can >>>>>>>>> turn >>>>>>>>> the HS clock off after high-speed transmissions. >>>>>>>> >>>>>>>> What I don't make sure is this sentence. With >>>>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. >>>>>>>> One is, >>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all >>>>>>>> are high). >>>>>>>> 4. And then D-PHY disables HS clock of host controller. >>>>>>>> 5. At this time, operation mode of host controller becomes LPM. >>>>>>>> >>>>>>>> Other is, >>>>>>>> 1. host controller will generates signals if a bit of a register >>>>>>>> related to non-contiguous clock mode is set or unset. >>>>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all >>>>>>>> are high). >>>>>>>> 3. And then video data is transmitted to panel in LPM. >>>>>>>> 4. At this time, operation mode of host controller becomes LPM. >>>>>>>> >>>>>>>> It seems that you says latter case. >>>>>>> >>>>>>> No. High speed clock and low power mode are orthogonal. Non-continuous >>>>>>> mode simply means that the clock lane enters LP-11 between HS >>>>>>> transmissions (see 5.6 "Clock Management" of the DSI specification). >>>>>>> >>>>>> >>>>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if >>>>>> non-continous mode is used. Right? >>>>> >>>>> No, I think as long as HS clock is enabled the clock lane won't enter >>>>> LP-11. Non-continuous mode means that the controller can disable the HS >>>>> clock between HS transmissions. So in non-continuous mode the clock lane >>>>> can enter LP-11 because the controller disables the HS clock. >>>> >>>> It makes me a little bit confusing. You said "if HS clock is enabled, >>>> the the clock lane won't enter LP-11" But you said again "the clock lane >>>> can enter LP-11 because the controller disables the HS clock" What is >>>> the meaning? >>> >>> It means that if the HS clock is enabled, then the clock lane is not in >>> LP-11. When the HS clock stops, then the clock lane enters LP-11. >>> >>>>> In continuous mode, then the clock will never be disabled, hence the >>>>> clock lane will never enter LP-11. &
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 07? 20:09, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >>>> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding : >>> [...] >>>>>>> As far as I can tell non-continuous mode simply means that the host can >>>>>>> turn off the HS clock after a high-speed transmission. I think Andrzej >>>>>>> mentioned this already in another subthread, but this is an optional >>>>>>> mode that peripherals can support if they have extra circuitry that >>>>>>> provides an internal clock. Peripherals that don't have such circuitry >>>>>>> may rely on the HS clock to perform in between transmissions and >>>>>>> therefore require the HS clock to be always on (continuous mode). That's >>>>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the >>>>>>> peripheral supports non-continuous mode and therefore the host can turn >>>>>>> the HS clock off after high-speed transmissions. >>>>>> >>>>>> What I don't make sure is this sentence. With >>>>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. >>>>>> One is, >>>>>> 1. host controller will generates signals if a bit of a register >>>>>> related to non-contiguous clock mode is set or unset. >>>>>> 2. And then video data is transmitted to panel in HS mode. >>>>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all >>>>>> are high). >>>>>> 4. And then D-PHY disables HS clock of host controller. >>>>>> 5. At this time, operation mode of host controller becomes LPM. >>>>>> >>>>>> Other is, >>>>>> 1. host controller will generates signals if a bit of a register >>>>>> related to non-contiguous clock mode is set or unset. >>>>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all >>>>>> are high). >>>>>> 3. And then video data is transmitted to panel in LPM. >>>>>> 4. At this time, operation mode of host controller becomes LPM. >>>>>> >>>>>> It seems that you says latter case. >>>>> >>>>> No. High speed clock and low power mode are orthogonal. Non-continuous >>>>> mode simply means that the clock lane enters LP-11 between HS >>>>> transmissions (see 5.6 "Clock Management" of the DSI specification). >>>>> >>>> >>>> It seems that clock lane enters LP-11 regardless of HS clock enabled if >>>> non-continous mode is used. Right? >>> >>> No, I think as long as HS clock is enabled the clock lane won't enter >>> LP-11. Non-continuous mode means that the controller can disable the HS >>> clock between HS transmissions. So in non-continuous mode the clock lane >>> can enter LP-11 because the controller disables the HS clock. >> >> It makes me a little bit confusing. You said "if HS clock is enabled, >> the the clock lane won't enter LP-11" But you said again "the clock lane >> can enter LP-11 because the controller disables the HS clock" What is >> the meaning? > > It means that if the HS clock is enabled, then the clock lane is not in > LP-11. When the HS clock stops, then the clock lane enters LP-11. > >>> In continuous mode, then the clock will never be disabled, hence the >>> clock lane will never enter LP-11. >>> >>>> And also it seems that non-continous mode is different from LPM at all >>>> because with non-continuous mode, command data is transmitted to panel >>>> in HS mode, but with LPM, command data is transmitted to panel in LP >>>> mode. Also right? >>> >>> No. I think you can send command data to the peripheral in low power >>> mode in both continuous and non-continuous clock modes. >>> >>>> If so, shouldn't the host driver disable HS clock, in case of LP mode, >>>> before the host driver transmits command data? >>> >>> No. If the peripheral doesn't support non-continuous mode, then the HS >>> clock must never be
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 07? 18:09, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding : > [...] >>>>> As far as I can tell non-continuous mode simply means that the host can >>>>> turn off the HS clock after a high-speed transmission. I think Andrzej >>>>> mentioned this already in another subthread, but this is an optional >>>>> mode that peripherals can support if they have extra circuitry that >>>>> provides an internal clock. Peripherals that don't have such circuitry >>>>> may rely on the HS clock to perform in between transmissions and >>>>> therefore require the HS clock to be always on (continuous mode). That's >>>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the >>>>> peripheral supports non-continuous mode and therefore the host can turn >>>>> the HS clock off after high-speed transmissions. >>>> >>>> What I don't make sure is this sentence. With >>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. >>>> One is, >>>> 1. host controller will generates signals if a bit of a register >>>> related to non-contiguous clock mode is set or unset. >>>> 2. And then video data is transmitted to panel in HS mode. >>>> 3. And then D-PHY detects LP-11 signal (positive and negative lane all >>>> are high). >>>> 4. And then D-PHY disables HS clock of host controller. >>>> 5. At this time, operation mode of host controller becomes LPM. >>>> >>>> Other is, >>>> 1. host controller will generates signals if a bit of a register >>>> related to non-contiguous clock mode is set or unset. >>>> 2. And then D-PHY detects LP-11 signal (positive and negative lane all >>>> are high). >>>> 3. And then video data is transmitted to panel in LPM. >>>> 4. At this time, operation mode of host controller becomes LPM. >>>> >>>> It seems that you says latter case. >>> >>> No. High speed clock and low power mode are orthogonal. Non-continuous >>> mode simply means that the clock lane enters LP-11 between HS >>> transmissions (see 5.6 "Clock Management" of the DSI specification). >>> >> >> It seems that clock lane enters LP-11 regardless of HS clock enabled if >> non-continous mode is used. Right? > > No, I think as long as HS clock is enabled the clock lane won't enter > LP-11. Non-continuous mode means that the controller can disable the HS > clock between HS transmissions. So in non-continuous mode the clock lane > can enter LP-11 because the controller disables the HS clock. It makes me a little bit confusing. You said "if HS clock is enabled, the the clock lane won't enter LP-11" But you said again "the clock lane can enter LP-11 because the controller disables the HS clock" What is the meaning? > > In continuous mode, then the clock will never be disabled, hence the > clock lane will never enter LP-11. > >> And also it seems that non-continous mode is different from LPM at all >> because with non-continuous mode, command data is transmitted to panel >> in HS mode, but with LPM, command data is transmitted to panel in LP >> mode. Also right? > > No. I think you can send command data to the peripheral in low power > mode in both continuous and non-continuous clock modes. > >> If so, shouldn't the host driver disable HS clock, in case of LP mode, >> before the host driver transmits command data? > > No. If the peripheral doesn't support non-continuous mode, then the HS > clock must never be turned off. On the other hand, if the peripheral > supports non-continuous mode, then the DSI host should automatically > disable the HS clock between high-speed transmissions. That means if a > packet is transmitted in low power mode the DSI host will not be > transmitting in high-speed mode and therefore disable the HS clock. What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So for LPM transfer, lanes should be LP-11 state and also HS clock of the host controller should be disabled. Your comment, "if a packet is transmitted in low power mode the DSI host will not be transmitting in high-speed mode and therefor disable the HS clock" would mean same as my question. > > Obviously if the controller can't do that automatically then it might be > necessary to explicitl
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 08? 07? 15:58, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >> 2014-08-06 16:43 GMT+09:00 Thierry Reding : >>> On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: >>>> On 2014? 08? 05? 20:12, Thierry Reding wrote: >>> [...] >>>>> I think that low power mode is more often used for command transmission >>>>> (in host-driven mode). I'm not sure how much sense it really makes to >>>>> transmit video data in low power mode. It also seems like low power mode >>>>> is what all peripherals need to support (if they can do command mode). >>>>> Hence I'd like to propose the attached patch that makes all command >>>>> messages use low power mode. >>>> >>>> To use low power mode, I think SoC drivers should add more codes: >>>> checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does >>>> exactly that, >>>> http://www.spinics.net/lists/linux-samsung-soc/msg34866.html >>> >>> I agree in general that DSI host drivers need to check the flags to make >>> a decision about which mode to enable. But your patch also introduces >>> additional flags that I don't think are necessary (at least for any of >>> the use-cases discussed so far). >>> >>> As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM >>> flags that you introduce would advertise that the device only supports >>> low power mode for command or video modes respectively. However, I doubt >> >> Not so. My intention is to add LPM support for video and command data >> transfers because mipi-dsi framework enforces implicitly using HS mode >> for by default. > > No, it doesn't enforce anything at this point. Everyone is free to use > whatever they see fit. Drivers that require low power mode for command > transmission can set the MIPI_DSI_MSG_USE_LPM flag in messages. For > video there's no way to specify what a given peripheral uses, so DSI > host controller drivers are free to do whatever they want. > > So for command data we already have a means, and for video data I don't > think it makes sense to use low power mode. Therefore I don't think > these new flags are necessary. > >>> that there really are devices that only support low power video mode. It >>> wouldn't make much sense because you'd get a maximum of 10 MHz for the >>> clock, which is about 1.6 frames per second at 1920x1080 resolution (not >>> counting blanking). And even with lower resolutions such as 1024x768 it >>> would be somewhere around 4 frames per second. And I think it's >>> reasonable to assume that we'll see that kind of resolution become very >>> rare in the future. >>> >>> So my point is that devices which support video mode will always support >>> high speed mode for video transmission too. Similarly, if a device >>> supports command mode, then it will likely support it in low-power mode, >>> and optionally in high speed mode too. >>> >>>> And what I and Andrzej don't make sure is non-continuous clock mode. Do >>>> you know how non-continuous clock mode is related to HS clock? >>> >>> As far as I can tell non-continuous mode simply means that the host can >>> turn off the HS clock after a high-speed transmission. I think Andrzej >>> mentioned this already in another subthread, but this is an optional >>> mode that peripherals can support if they have extra circuitry that >>> provides an internal clock. Peripherals that don't have such circuitry >>> may rely on the HS clock to perform in between transmissions and >>> therefore require the HS clock to be always on (continuous mode). That's >>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the >>> peripheral supports non-continuous mode and therefore the host can turn >>> the HS clock off after high-speed transmissions. >> >> What I don't make sure is this sentence. With >> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. >> One is, >> 1. host controller will generates signals if a bit of a register >> related to non-contiguous clock mode is set or unset. >> 2. And then video data is transmitted to panel in HS mode. >> 3. And then D-PHY detects LP-11 signal (positive and negative lane all >> are high). >> 4. And then D-PHY disables HS clock of host controller. >> 5. At this time, operation mode of host controller becomes LPM. >> >> Other is, >> 1. host controller will generates sign
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 2014? 07? 29? 22:16, Andrzej Hajda wrote:
> On 07/29/2014 02:08 PM, Inki Dae wrote:
>> On 2014? 07? 29? 20:39, Andrzej Hajda wrote:
>>> On 07/29/2014 05:42 AM, Inki Dae wrote:
>>>> On 2014? 07? 29? 00:50, Andrzej Hajda wrote:
>>>>> On 07/28/2014 04:00 AM, Inki Dae wrote:
>>>>>> This patch adds LPM transfer support for video or command data.
>>>>>>
>>>>>> With this patch, Exynos MIPI DSI controller can transfer command or
>>>>>> video data with HS or LP mode in accordance with mode_flags set
>>>>>> by LCD Panel driver.
>>>>>>
>>>>>> Changelog v2: Enable High Speed clock only in case of stand by request.
>>>>>>
>>>>>> Signed-off-by: Inki Dae
>>>>>> Acked-by: Kyungmin Park
>>>>>> ---
>>>>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
>>>>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>> index 5e78d45..1bed105 100644
>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>>>> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct
>>>>>> exynos_dsi *dsi)
>>>>>> | DSIM_ESC_PRESCALER(esc_div)
>>>>>> | DSIM_LANE_ESC_CLK_EN_CLK
>>>>>> | DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>>>>>> -| DSIM_BYTE_CLK_SRC(0)
>>>>>> -| DSIM_TX_REQUEST_HSCLK;
>>>>>> +| DSIM_BYTE_CLK_SRC(0);
>>>>>> +
>>>>>> +if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>>>>>> +reg |= DSIM_TX_REQUEST_HSCLK;
>>>>>> +
>>>>>> writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>>>
>>>>>> return 0;
>>>>>> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct
>>>>>> exynos_dsi *dsi)
>>>>>> writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>>>>>> }
>>>>>>
>>>>>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>>>>>> +bool enable)
>>>>>> +{
>>>>>> +u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>>> +
>>>>>> +reg &= ~DSIM_TX_REQUEST_HSCLK;
>>>>>> +if (enable)
>>>>>> +reg |= DSIM_TX_REQUEST_HSCLK;
>>>>>> +
>>>>>> +writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>>> +}
>>>>>> +
>>>>> I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
>>>>> it works with and without the bit set.
>>>> If you can test thmorstat board, you will face with that its panel is
>>>> not worked.
>>> So it means this panel requires proper driving of this bit, but it does
>>> not prove it is
>>> LPM related.
>>>
>>>>> So I start to suspect this bit is not just for simply enable/disable HS
>>>>> clock as function name suggests, do you know what is its
>>>>> exact meaning? The specs are quite succinct on it.
>>>> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
>>> This sounds very strange. DSI specs and D-PHY specs says clearly
>>> that LPM transmissions are unrelated to HS clock [1][2]. Even timing
>>> diagrams
>>> in Exynos specs shows no dependency of LPM transmissions on HS clock.
>>> And the
>>> description of TxRequestHsClk bit says "HS clock request for HS transfer
>>> at clock lane (Turn
>>> on HS clock)".
>> There are three System power states of D-PHY, Low-Power mode, High-Speed
>> mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
>> Lane. Therefore, to use HS mode, HS clock should be enabled. On the
>> other hand, LP mode needs only 10MHz (max).
>>
>> So do you really think LP mode will be worked well with HS clock
>> enabled? The purpose
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
2014-08-06 16:43 GMT+09:00 Thierry Reding : > On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: >> On 2014? 08? 05? 20:12, Thierry Reding wrote: > [...] >> > I think that low power mode is more often used for command transmission >> > (in host-driven mode). I'm not sure how much sense it really makes to >> > transmit video data in low power mode. It also seems like low power mode >> > is what all peripherals need to support (if they can do command mode). >> > Hence I'd like to propose the attached patch that makes all command >> > messages use low power mode. >> >> To use low power mode, I think SoC drivers should add more codes: >> checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does >> exactly that, >> http://www.spinics.net/lists/linux-samsung-soc/msg34866.html > > I agree in general that DSI host drivers need to check the flags to make > a decision about which mode to enable. But your patch also introduces > additional flags that I don't think are necessary (at least for any of > the use-cases discussed so far). > > As I understand it the MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM > flags that you introduce would advertise that the device only supports > low power mode for command or video modes respectively. However, I doubt Not so. My intention is to add LPM support for video and command data transfers because mipi-dsi framework enforces implicitly using HS mode for by default. > that there really are devices that only support low power video mode. It > wouldn't make much sense because you'd get a maximum of 10 MHz for the > clock, which is about 1.6 frames per second at 1920x1080 resolution (not > counting blanking). And even with lower resolutions such as 1024x768 it > would be somewhere around 4 frames per second. And I think it's > reasonable to assume that we'll see that kind of resolution become very > rare in the future. > > So my point is that devices which support video mode will always support > high speed mode for video transmission too. Similarly, if a device > supports command mode, then it will likely support it in low-power mode, > and optionally in high speed mode too. > >> And what I and Andrzej don't make sure is non-continuous clock mode. Do >> you know how non-continuous clock mode is related to HS clock? > > As far as I can tell non-continuous mode simply means that the host can > turn off the HS clock after a high-speed transmission. I think Andrzej > mentioned this already in another subthread, but this is an optional > mode that peripherals can support if they have extra circuitry that > provides an internal clock. Peripherals that don't have such circuitry > may rely on the HS clock to perform in between transmissions and > therefore require the HS clock to be always on (continuous mode). That's > what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises that the > peripheral supports non-continuous mode and therefore the host can turn > the HS clock off after high-speed transmissions. What I don't make sure is this sentence. With MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible operations. One is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then video data is transmitted to panel in HS mode. 3. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 4. And then D-PHY disables HS clock of host controller. 5. At this time, operation mode of host controller becomes LPM. Other is, 1. host controller will generates signals if a bit of a register related to non-contiguous clock mode is set or unset. 2. And then D-PHY detects LP-11 signal (positive and negative lane all are high). 3. And then video data is transmitted to panel in LPM. 4. At this time, operation mode of host controller becomes LPM. It seems that you says latter case. I really know that with non-contiguous clock mode, HS clock of host controller can be disabled. My question is who controls HS clock in this case. D-PHY or host controller? In other words, with LPM and MIPI_DSI_CLOCK_NON_CONTIUOUS flags, should the host driver check these two flags to disable HS clock? or In this case, does the D-PHY disable HS clock regardless of host driver? I think we should make sure that to handle LP and HS modes correctly. > > If a device doesn't specify that flag then the host needs to keep the HS > clock running all the time. > >> > The .transfer() function was really designed with initialization >> > commands in mind, so it doesn't deal with mixing video data and commands >> > anyway and for initialization low-power mode should be fast enough. The >> > downside is that it may not be optimal for some peripherals, but it >&
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
Thanks for comments. On 2014? 08? 05? 20:12, Thierry Reding wrote: > On Mon, Jul 28, 2014 at 06:09:58PM +0200, Andrzej Hajda wrote: >> On 07/28/2014 04:00 AM, Inki Dae wrote: >>> This patch adds below two flags for LPM transfer, and it attaches LPM flags >>> to a msg in accordance with master's mode_flags set by LCD Panel driver. >>> >>> MIPI_DSI_MODE_CMD_LPM >>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>> command data to Panel device in Low Power Mode. >> >> What do you mean by command data? It could be: >> - all transfer in command mode of operations, >> - transfer initialized by the driver by writing to DSIM registers. >> >>> >>> MIPI_DSI_MODE_VIDEO_LPM >>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>> image data to Panel device in Low Power Mode. >> >> What is the meaning of this flag in case of command mode of operation? >> >> Maybe it would be better to create flags based on source of data/FIFOs: >> - commands send by SFR registers, >> - commands generated from data sent from Display Controller. > > I have no idea what SFR is. But it sounds like you're talking about two > ways to generate command packets here. We have something similar on > Tegra, where it's called "host-driven command mode" and "DC-driven > command mode". > > In host-driven command mode the driver needs to explicitly program some > of the DSI controller registers to send command packets. This is > essentially a FIFO register and a control register to trigger > transmission and poll for completion. > > DC-driven command mode is typically used to update contents of a remote > framebuffer (what MIPI calls "Type 1 Display Architecture"). This is > done by programming a different set of registers that cause the DSI > controller to take data output by the display controller and wrap it > into DCS commands (e.g. write_memory_start and write_memory_continue). > Exynos also supports above two command mode but we have never used DC-driven command mode. > I think that low power mode is more often used for command transmission > (in host-driven mode). I'm not sure how much sense it really makes to > transmit video data in low power mode. It also seems like low power mode > is what all peripherals need to support (if they can do command mode). > Hence I'd like to propose the attached patch that makes all command > messages use low power mode. To use low power mode, I think SoC drivers should add more codes: checking xxx_MSG_LPM, and maybe disabling HS clock. My patch does exactly that, http://www.spinics.net/lists/linux-samsung-soc/msg34866.html And what I and Andrzej don't make sure is non-continuous clock mode. Do you know how non-continuous clock mode is related to HS clock? > > The .transfer() function was really designed with initialization > commands in mind, so it doesn't deal with mixing video data and commands > anyway and for initialization low-power mode should be fast enough. The > downside is that it may not be optimal for some peripherals, but it > gives us a good solution for the general case since it should support > all devices. > > If we absolutely must have faster initialization, or if we come across a > device that can only initialize in high speed mode, then I think we > should introduce a new flag to allow DSI host controllers to optimize in > those cases. Originally, mipi-dsi framework enforces implicitly using HS mode for video and command data as default so I added LPM relevant flags - for video and also command data - for host driver can consider Low Power Mode. However, your patch makes it use Low Power Mode for command data as default. So your patch would mean that default transfer mode for command data is Low Power Mode, but HS mode for video data. Do you intend to control transfer mode - HS or LPM - only for command data? If so, we would need only one flag, i.e., MIPI_DSI_MODE_HS. Thanks, Inki Dae > > Note that this is based on some of my local patches, so it won't apply > as-is. But if anybody wants to give this a go it should be easy to apply > manually as well. > > Thierry >
[GIT PULL] exynos-drm-next
Hi Dave, This pull request includes i80 interface support, module auto-loading ipp consolidation, and trivail fixups and cleanups. Summary: - Add i80 interface support. For this, we added some features to Exynos drm framework, which don't affect any other SoC and common framework because they are specific to Exynos drm. - Add module auto-loading support. For this, sub drivers of Exynos drm exports their of match tables to userspace. This allows modules to be loaded automatically based on devicetree information - Consolidate ipp driver. This patch just just includes cleanups and a littl bit refactoring codes. If there is any problem, please kindly let me know. Thanks, Inki Dae The following changes since commit 08d645c181e9b9482c249e82a061c279a986db15: agp: remove read/write stubs (2014-08-02 06:43:51 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-next for you to fetch changes up to ef7ce055a9e00f6376416466b996515a27b7cb31: drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail (2014-08-04 13:39:28 +0900) Alban Browaeys (1): drm/exynos: g2d: add exynos4212 as a compatible device. Andrzej Hajda (12): drm/exynos/ipp: remove type casting drm/exynos/ipp: remove unused field from exynos_drm_ipp_private drm/exynos/ipp: remove struct exynos_drm_ipp_private drm/exynos/ipp: correct address type drm/exynos/ipp: remove temporary variable drm/exynos/ipp: remove incorrect checks of list_first_entry result drm/exynos/ipp: simplify memory check function drm/exynos/ipp: remove useless registration checks drm/exynos/ipp: simplify ipp_find_obj drm/exynos/ipp: remove redundant messages drm/exynos/ipp: simplify ipp_create_id drm/exynos/ipp: simplify ipp_find_driver Jingoo Han (1): drm/exynos: dp: Use correct module license Joonyoung Shim (1): drm/exynos: control blending of mixer graphic layer 0 Krzysztof Kozlowski (1): drm/exynos: Fix NULL pointer exception when suspending without components Marek Szyprowski (2): drm/exynos: hdmi: make 'hdmi-en' regulator optional and keep it enabled drm/exynos: hdmi: enable exynos 4210 and 4x12 soc support Sachin Kamat (2): drm/exynos: Remove unused variable from exynos_hdmi.c drm/exynos: Remove unused variable in exynos_drm_gem.c Seung-Woo Kim (1): drm/exynos: hdmi: add null check for hdmiphy_port Sjoerd Simons (3): Subject: Revert "drm/exynos: fix module build error" Subject: Revert "drm/exynos: remove MODULE_DEVICE_TABLE definitions" drm/exynos: Add MODULE_DEVICE_TABLE entries for various components Tobias Jakobi (2): drm/exynos: g2d: make ioctls more robust drm/exynos: g2d: let exynos_g2d_get_ver_ioctl fail YoungJun Cho (12): drm/exynos: dsi: move the EoT packets configuration point drm/exynos: use wait_event_timeout() for safety usage ARM: dts: samsung-fimd: add LCD I80 interface specific properties drm/exynos: add TE handler to support LCD I80 interface drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface drm/exynos: fimd: support LCD I80 interface ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs ARM: dts: exynos4: add system register property ARM: dts: exynos5: add system register property ARM: dts: exynos5420: add mipi-phy node ARM: dts: exynos5420: add dsi node .../devicetree/bindings/video/exynos_dsim.txt |4 +- .../devicetree/bindings/video/exynos_mixer.txt |5 +- .../devicetree/bindings/video/samsung-fimd.txt | 28 ++ arch/arm/boot/dts/exynos4.dtsi |1 + arch/arm/boot/dts/exynos5.dtsi |1 + arch/arm/boot/dts/exynos5420.dtsi | 20 ++ drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_dp_core.c|3 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 +- drivers/gpu/drm/exynos/exynos_drm_crtc.h |7 + drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 10 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 270 +-- drivers/gpu/drm/exynos/exynos_drm_fimc.c |1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 277 drivers/gpu/drm/exynos/exynos_drm_g2d.c| 29 +- drivers/gpu/drm/exynos/exynos_drm_gem.c|3 - drivers/gpu/drm/exynos/exynos_drm_ipp.c| 259 +- drivers/gpu/drm/exynos/exynos_drm_ipp.h|4 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c|1 + drivers/gpu/drm/exynos/exynos_hdmi.c
[PATCH 1/2] drm/exynos: g2d: make ioctls more robust
On 2014? 08? 03? 18:52, Tobias Jakobi wrote: > Inki Dae wrote: >> It seems that you have no build test because above line incurs build >> error. Anyway I fixed it up. > That's why I have sent v2 of the patch. > Oops, sorry. I didn't check v2. Thanks, Inki Dae > With best wishes, > Tobias > >
[PATCH 07/15] drm/exynos: dsi: Add support for panel prepare and unprepare routines
2014-08-01 18:05 GMT+09:00 Thierry Reding : > On Thu, Jul 31, 2014 at 11:12:06PM +0530, Ajay Kumar wrote: >> Modify exynos_dsi driver to support the new panel calls: >> prepare and unprepare. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 12 ++-- >> 1 file changed, 10 insertions(+), 2 deletions(-) > > And this one as well. Acked-by: Inki Dae Thanks, Inki Dae > > Thierry > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 1/2] drm/exynos: g2d: make ioctls more robust
2014-07-23 23:57 GMT+09:00 Tobias Jakobi :
> Both exynos_g2d_set_cmdlist_ioctl and exynos_g2d_exec_ioctl don't check
> if the G2D was succesfully probe. If that is not the case, then g2d_priv
> is just NULL and extracting 'dev' from it in the next step is going to
> produce a kernel oops.
>
> Add proper checks and return ENODEV if the G2D is not available.
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 5fa1bb6..8c62423 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1056,7 +1056,7 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
> *drm_dev, void *data,
> {
> struct drm_exynos_file_private *file_priv = file->driver_priv;
> struct exynos_drm_g2d_private *g2d_priv = file_priv->g2d_priv;
> - struct device *dev = g2d_priv->dev;
> + struct device *dev;
> struct g2d_data *g2d;
> struct drm_exynos_g2d_set_cmdlist *req = data;
> struct drm_exynos_g2d_cmd *cmd;
> @@ -1067,6 +1067,10 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device
> *drm_dev, void *data,
> int size;
> int ret;
>
> + if (!g2d_priv)
> + return -ENODEV;
> +
> + dev = g2d_priv->dev;
> if (!dev)
> return -ENODEV;
>
> @@ -1223,13 +1227,17 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev,
> void *data,
> {
> struct drm_exynos_file_private *file_priv = file->driver_priv;
> struct exynos_drm_g2d_private *g2d_priv = file_priv->g2d_priv;
> - struct device *dev = g2d_priv->dev;
> + struct device *dev;
> struct g2d_data *g2d;
> struct drm_exynos_g2d_exec *req = data;
> struct g2d_runqueue_node *runqueue_node;
> struct list_head *run_cmdlist;
> struct list_head *event_list;
>
> + if (!g2d_priv)
> + return -ENODEV;
> +
> + dev = g2d_priv->dev
It seems that you have no build test because above line incurs build
error. Anyway I fixed it up.
Thanks,
Inki Dae
> if (!dev)
> return -ENODEV;
>
> --
> 1.8.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
2014-08-03 16:03 GMT+09:00 Inki Dae : > 2014-07-29 19:23 GMT+09:00 Andrzej Hajda : >> On 07/29/2014 02:57 AM, YoungJun Cho wrote: >>> Hi Andrzej, >>> >>> On 07/29/2014 01:09 AM, Andrzej Hajda wrote: >>>> On 07/28/2014 04:00 AM, Inki Dae wrote: >>>>> This patch adds below two flags for LPM transfer, and it attaches LPM >>>>> flags >>>>> to a msg in accordance with master's mode_flags set by LCD Panel driver. >>>>> >>>>> MIPI_DSI_MODE_CMD_LPM >>>>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>>>> command data to Panel device in Low Power Mode. >>>> What do you mean by command data? It could be: >>>> - all transfer in command mode of operations, >>>> - transfer initialized by the driver by writing to DSIM registers. >>> The 2nd one. >>> >>>>> MIPI_DSI_MODE_VIDEO_LPM >>>>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>>>> image data to Panel device in Low Power Mode. >>>> What is the meaning of this flag in case of command mode of operation? >>> I'm also not sure that there is a case to transfer image data in Low >>> Power Mode, but this flag is not related with 'command mode' only. >>> Inki may consider generic condition. >>> >>>> Maybe it would be better to create flags based on source of data/FIFOs: >>>> - commands send by SFR registers, >>>> - commands generated from data sent from Display Controller. >>>> >>>> >>>>> And above two flags can be combined together to transfer command and video >>>>> data to Panel device. >>>>> >>>>> MIPI DSI spec says, >>>>> "the host processor controls the desired mode of clock operation. >>>>>Host protocol and applications control Clock Lane operating mode >>>>>(High Speed or Low Power mode). System designers are responsible >>>>>for understanding the clock requirements for peripherals attached >>>>>to DSI and controlling clock behavior in accordance with those >>>>>requirements." >>>>> >>>>> Some LCD Panel devices, nt35502a, would need LPM transfer support >>>>> because they should receive some initial commands with LPM by default >>>>> hardware setting. >>>> >>>> Is this requirement for initial commands, or for all commands. >>>> Btw what is the mode of operation of nt35502a? What flags do you need >>>> for it? >>>> >>> The nt35502a panel is video(RGB) mode panel and it requires low power >>> mode for initial commands, which means to initialize nt35502a panel, the >>> initial commands are transferred by LP mode(Not HS mode). >>> And after initialization, its other features like gamma control or etc >>> could be controlled in HS mode. >> >> It sounds similar to my tc358764 bridge driver [1]. The difference is that >> it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM. >> >> As I understand nt35502a requires also different driving of >> TxRequestHSClk signal >> and this seems to me unrelated to LPM. As LPM is not related at all with >> HS clock, AFAIK. >> > > + Tomi Valkeinen > > At private talks before, I think we reached the following consensus, > > 1. D-PHY could disable HS clock of MIPI-DSI controller in case that > D-PHY detectsTransition to Stop state (LP=11) and TxRequestHSClk bit > of MIPI-DSI controller is set, which means that Panel driver set > MIPI_DSI_CLOCK_NON_CONTINUOUS flag. > > 2. Lower Power Mode means that the state of HS clock is low, Positive > and Negative lane are all low, LP-11 state. > > However, it seems some misunderstanding each other. > > I guess that non-contiguous clock mode - TxRequestHSCllk bit is set or > maybe unset - would mean that HS clock is high while MIPI-DSI > controller transmits data to Panel until D-PHY detects LP-11 state. Or with non-contiguous clock mode, data may be transmistted to Panel in LPM (HS clock is low and LP-11) after D-PHY detects LP-11 state. To make sure this, I will try to test that Panel - requiring LPM transfer for initial commands as default hw setting - works well with non-contiguous clock mode. In this cae, it seems that we need to consider HW that supports non-continuous clock mode. Thanks, Inki Dae > Therefore, I think LPM is different from non-contiguous clock mode, > and I think with LPM flag, host driver -
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
2014-07-29 19:23 GMT+09:00 Andrzej Hajda : > On 07/29/2014 02:57 AM, YoungJun Cho wrote: >> Hi Andrzej, >> >> On 07/29/2014 01:09 AM, Andrzej Hajda wrote: >>> On 07/28/2014 04:00 AM, Inki Dae wrote: >>>> This patch adds below two flags for LPM transfer, and it attaches LPM flags >>>> to a msg in accordance with master's mode_flags set by LCD Panel driver. >>>> >>>> MIPI_DSI_MODE_CMD_LPM >>>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>>> command data to Panel device in Low Power Mode. >>> What do you mean by command data? It could be: >>> - all transfer in command mode of operations, >>> - transfer initialized by the driver by writing to DSIM registers. >> The 2nd one. >> >>>> MIPI_DSI_MODE_VIDEO_LPM >>>> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >>>> image data to Panel device in Low Power Mode. >>> What is the meaning of this flag in case of command mode of operation? >> I'm also not sure that there is a case to transfer image data in Low >> Power Mode, but this flag is not related with 'command mode' only. >> Inki may consider generic condition. >> >>> Maybe it would be better to create flags based on source of data/FIFOs: >>> - commands send by SFR registers, >>> - commands generated from data sent from Display Controller. >>> >>> >>>> And above two flags can be combined together to transfer command and video >>>> data to Panel device. >>>> >>>> MIPI DSI spec says, >>>> "the host processor controls the desired mode of clock operation. >>>>Host protocol and applications control Clock Lane operating mode >>>>(High Speed or Low Power mode). System designers are responsible >>>>for understanding the clock requirements for peripherals attached >>>>to DSI and controlling clock behavior in accordance with those >>>>requirements." >>>> >>>> Some LCD Panel devices, nt35502a, would need LPM transfer support >>>> because they should receive some initial commands with LPM by default >>>> hardware setting. >>> >>> Is this requirement for initial commands, or for all commands. >>> Btw what is the mode of operation of nt35502a? What flags do you need >>> for it? >>> >> The nt35502a panel is video(RGB) mode panel and it requires low power >> mode for initial commands, which means to initialize nt35502a panel, the >> initial commands are transferred by LP mode(Not HS mode). >> And after initialization, its other features like gamma control or etc >> could be controlled in HS mode. > > It sounds similar to my tc358764 bridge driver [1]. The difference is that > it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM. > > As I understand nt35502a requires also different driving of > TxRequestHSClk signal > and this seems to me unrelated to LPM. As LPM is not related at all with > HS clock, AFAIK. > + Tomi Valkeinen At private talks before, I think we reached the following consensus, 1. D-PHY could disable HS clock of MIPI-DSI controller in case that D-PHY detectsTransition to Stop state (LP=11) and TxRequestHSClk bit of MIPI-DSI controller is set, which means that Panel driver set MIPI_DSI_CLOCK_NON_CONTINUOUS flag. 2. Lower Power Mode means that the state of HS clock is low, Positive and Negative lane are all low, LP-11 state. However, it seems some misunderstanding each other. I guess that non-contiguous clock mode - TxRequestHSCllk bit is set or maybe unset - would mean that HS clock is high while MIPI-DSI controller transmits data to Panel until D-PHY detects LP-11 state. Therefore, I think LPM is different from non-contiguous clock mode, and I think with LPM flag, host driver - for MIPI-DSI device - should disable HS clock to transmit data to Panel. So I think HS clock is related to LPM. Anyway, we all are not sure how D-PHY handles HS clock of MIPI-DSI controller. So we would need more comments from HW guy or specitialists of MIPI-DSI to make sure. I think Tomi Valkeinen would be one of the specitialists. Hi Tomi, Could you give us some comments about this? Is HS clock unrelated to Low Power Mode at all? And do you know D-PHY handle HS clock of MIPI-DSI controller with non-contigous clock mode? Thanks, Inki Dae > Regards > Andrzej > > [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 > > >> >> Thank you. >> Best regards YJ >> >>> >>>> Changelog v2: just add more descriptions.
[PATCH 15/15] drm/exynos: dp: Modify driver to support drm_panel
On 2014? 08? 01? 18:09, Thierry Reding wrote: > On Thu, Jul 31, 2014 at 11:12:14PM +0530, Ajay Kumar wrote: >> Add drm_panel controls to support powerup/down of the >> eDP panel, if one is present at the sink side. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/gpu/drm/exynos/Kconfig |1 + >> drivers/gpu/drm/exynos/exynos_dp_core.c | 88 >> --- >> drivers/gpu/drm/exynos/exynos_dp_core.h |3 +- >> 3 files changed, 71 insertions(+), 21 deletions(-) > > Inki, I'll need an Acked-by from you on this one as well. It has a build > time dependency on earlier patches in this series, so taking it through > the panel tree along with the rest is probably easiest. Acked-by: Inki Dae Thanks, Inki Dae > > Thierry >
[PATCH 06/15] drm/exynos: dpi: Add support for panel prepare and unprepare routines
On 2014? 08? 01? 18:04, Thierry Reding wrote: > On Thu, Jul 31, 2014 at 11:12:05PM +0530, Ajay Kumar wrote: >> Modify exynos_dpi driver to support the new panel calls: >> prepare and unprepare. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++-- >> 1 file changed, 6 insertions(+), 2 deletions(-) > > Looks good to me. Inki, can I have your Acked-by to take this through > the panel tree? Of course. Acked-by: Inki Dae Thanks, Inki Dae > > Thierry >
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
On 2014? 07? 29? 20:59, Andreas F?rber wrote: > Am 29.07.2014 10:05, schrieb Sjoerd Simons: >> On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote: >>> On 2014? 07? 28? 23:45, Sjoerd Simons wrote: >>>> On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: >>>>> On 2014? 07? 28? 17:30, Sjoerd Simons wrote: >>>>> I don't see why Exynos drm driver should be auto-loaded module. I think >>>>> all devices covered by Exynos drm framework are not hot-plugged. Maybe >>>>> there is my missing point. So can you explain why Exynos drm driver >>>>> should be auto-loaded module? >>>> >>>> The background for this is that I'm building a distribution-style >>>> multiplatform kernel, that is to say a kernel which can boot on a big >>>> set of different ARM boards. As such, the intention is to keep the core >>>> zImage as small as possible and essentially build things as far as >>>> possible as loadable modules. So in a sense, all of the hardware is >>>> "hotplugged", depending on which board the kernel is actually booted on! >>>> >>>> For that use-case, exynosdrm needs to be able to build as a module >>>> (which it already can!) and it needs the required meta-data for >>>> userspace to know when it should be loaded. The latter is what my patch >>>> adds. >>> >>> It seems that you want that module data of sub drivers are added by >>> depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some >>> hot-plug system should use modules.xxxmap file to find the proper driver >>> to load. >> >> Yes. I would like the module to export its module alias information for >> the subdrivers such that depmod can add it to its databases and the >> normal module autoloading mechanisms work as intended. Note that in my >> case, "some hot-plug" system is really just udev, not something >> special.. > > +1 here. > > While I haven't tested this on my Exynos devices yet since I'm still > working on -next kernels there, here's an example of such a 3.16 config: > > http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/default > > Of the platforms enabled, all drivers are configured as modules where > possible, to keep kernel size small, and dracut (or kiwi) is used to > generate an initrd that makes available the modules. > > So it would certainly be good to have the DRM auto-load somehow, without > the user having to manually touch config files. In particular when I > think of the Chromebooks, where Wifi needs configuration on first boot > and no serial console is accessible. Got it. will merge them. However, I'm not sure that Exynos drm should have hot-plug feature such as PCI base devices: all devices covered by Exynos drm framework cannot attached and detached to and from machine. Thanks, Inki Dae > > Regards, > Andreas >
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 2014? 07? 29? 20:39, Andrzej Hajda wrote:
> On 07/29/2014 05:42 AM, Inki Dae wrote:
>> On 2014? 07? 29? 00:50, Andrzej Hajda wrote:
>>> On 07/28/2014 04:00 AM, Inki Dae wrote:
>>>> This patch adds LPM transfer support for video or command data.
>>>>
>>>> With this patch, Exynos MIPI DSI controller can transfer command or
>>>> video data with HS or LP mode in accordance with mode_flags set
>>>> by LCD Panel driver.
>>>>
>>>> Changelog v2: Enable High Speed clock only in case of stand by request.
>>>>
>>>> Signed-off-by: Inki Dae
>>>> Acked-by: Kyungmin Park
>>>> ---
>>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
>>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> index 5e78d45..1bed105 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>>> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi
>>>> *dsi)
>>>>| DSIM_ESC_PRESCALER(esc_div)
>>>>| DSIM_LANE_ESC_CLK_EN_CLK
>>>>| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>>>> - | DSIM_BYTE_CLK_SRC(0)
>>>> - | DSIM_TX_REQUEST_HSCLK;
>>>> + | DSIM_BYTE_CLK_SRC(0);
>>>> +
>>>> + if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>>>> + reg |= DSIM_TX_REQUEST_HSCLK;
>>>> +
>>>>writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>>
>>>>return 0;
>>>> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi
>>>> *dsi)
>>>>writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>>>> }
>>>>
>>>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>>>> + bool enable)
>>>> +{
>>>> + u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>>>> +
>>>> + reg &= ~DSIM_TX_REQUEST_HSCLK;
>>>> + if (enable)
>>>> + reg |= DSIM_TX_REQUEST_HSCLK;
>>>> +
>>>> + writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>>> +}
>>>> +
>>> I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
>>> it works with and without the bit set.
>> If you can test thmorstat board, you will face with that its panel is
>> not worked.
>
> So it means this panel requires proper driving of this bit, but it does
> not prove it is
> LPM related.
>
>>> So I start to suspect this bit is not just for simply enable/disable HS
>>> clock as function name suggests, do you know what is its
>>> exact meaning? The specs are quite succinct on it.
>> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
>
> This sounds very strange. DSI specs and D-PHY specs says clearly
> that LPM transmissions are unrelated to HS clock [1][2]. Even timing
> diagrams
> in Exynos specs shows no dependency of LPM transmissions on HS clock.
> And the
> description of TxRequestHsClk bit says "HS clock request for HS transfer
> at clock lane (Turn
> on HS clock)".
There are three System power states of D-PHY, Low-Power mode, High-Speed
mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
Lane. Therefore, to use HS mode, HS clock should be enabled. On the
other hand, LP mode needs only 10MHz (max).
So do you really think LP mode will be worked well with HS clock
enabled? The purpose of LP mode is to reduce power consumption while
transmitting data. Can you reduce the power consumption in LP mode with
HS clock enabled?
Thanks,
Inki Dae
>
> Maybe different flag should be used to describe your panel requirements
> regarding this bit.
>
> It would be good to see the real initialization sequence in form of
> pseudo-code or better in the driver.
>
>
> [1]: MIPI DSI: "Note that in Low Power signaling mode, LP clock is
> functionally embedded in the data signals. When LP
> data transmission ends, the clock effectively stops and subsequent LP
> clocks are not available to the
> peripheral. The peripheral shall not require additional bits, bytes, or
> packets from the host processor in
> order to complete processing or pipeline movement of received data in LP
&g
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
On 2014? 07? 28? 23:45, Sjoerd Simons wrote: > Hey Inki, > > On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: >> On 2014? 07? 28? 17:30, Sjoerd Simons wrote: >> Sorry for late, >> >> I don't see why Exynos drm driver should be auto-loaded module. I think >> all devices covered by Exynos drm framework are not hot-plugged. Maybe >> there is my missing point. So can you explain why Exynos drm driver >> should be auto-loaded module? > > The background for this is that I'm building a distribution-style > multiplatform kernel, that is to say a kernel which can boot on a big > set of different ARM boards. As such, the intention is to keep the core > zImage as small as possible and essentially build things as far as > possible as loadable modules. So in a sense, all of the hardware is > "hotplugged", depending on which board the kernel is actually booted on! > > For that use-case, exynosdrm needs to be able to build as a module > (which it already can!) and it needs the required meta-data for > userspace to know when it should be loaded. The latter is what my patch > adds. > It seems that you want that module data of sub drivers are added by depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some hot-plug system should use modules.xxxmap file to find the proper driver to load. Ok, then does exynos drm driver is loaded well with your patches? My concern is that device_id of exynos drm core driver , exynos_drm_drv.c, wouldn't be exported to userspace, which means that exynos drm subsystem aren't bound by component framework because most sub drivers except vidi are bound by component interfaces of exynos drm core: exynos drm drv is not device tree base driver. Thanks, Inki Dae
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 2014? 07? 29? 00:50, Andrzej Hajda wrote:
> On 07/28/2014 04:00 AM, Inki Dae wrote:
>> This patch adds LPM transfer support for video or command data.
>>
>> With this patch, Exynos MIPI DSI controller can transfer command or
>> video data with HS or LP mode in accordance with mode_flags set
>> by LCD Panel driver.
>>
>> Changelog v2: Enable High Speed clock only in case of stand by request.
>>
>> Signed-off-by: Inki Dae
>> Acked-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 5e78d45..1bed105 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi
>> *dsi)
>> | DSIM_ESC_PRESCALER(esc_div)
>> | DSIM_LANE_ESC_CLK_EN_CLK
>> | DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>> -| DSIM_BYTE_CLK_SRC(0)
>> -| DSIM_TX_REQUEST_HSCLK;
>> +| DSIM_BYTE_CLK_SRC(0);
>> +
>> +if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>> +reg |= DSIM_TX_REQUEST_HSCLK;
>> +
>> writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>
>> return 0;
>> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi
>> *dsi)
>> writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>> }
>>
>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>> +bool enable)
>> +{
>> +u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>> +
>> +reg &= ~DSIM_TX_REQUEST_HSCLK;
>> +if (enable)
>> +reg |= DSIM_TX_REQUEST_HSCLK;
>> +
>> +writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>> +}
>> +
>
> I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
> it works with and without the bit set.
If you can test thmorstat board, you will face with that its panel is
not worked.
> So I start to suspect this bit is not just for simply enable/disable HS
> clock as function name suggests, do you know what is its
> exact meaning? The specs are quite succinct on it.
HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
> On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
> in DSIM_ESCMODE register
> which seems to be related to flags you have introduced:
> - DSIM_CMD_LPDT_LP - transmit commands in LP mode,
> - DSIM_TX_LPDT_LP - transmit data in LP mode.
As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
that host can transmit command and also image data to Panel in Low Power
Mode. So these flags are specific to MIPI-DSI controller of Exynos.
> The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
This flag is set only when command msg transmission is requested by
Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
transmit command and also image.
Thanks,
Inki Dae
> you use the latter?
>
> Regards
> Andrzej
>
>> static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>> {
>> u32 reg;
>> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct
>> exynos_dsi *dsi, bool enable)
>> {
>> u32 reg;
>>
>> +if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
>> +exynos_dsi_enable_hs_clock(dsi, true);
>> +
>> reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>> if (enable)
>> reg |= DSIM_MAIN_STAND_BY;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 07? 29? 01:09, Andrzej Hajda wrote: > On 07/28/2014 04:00 AM, Inki Dae wrote: >> This patch adds below two flags for LPM transfer, and it attaches LPM flags >> to a msg in accordance with master's mode_flags set by LCD Panel driver. >> >> MIPI_DSI_MODE_CMD_LPM >> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >> command data to Panel device in Low Power Mode. > > What do you mean by command data? It could be: > - all transfer in command mode of operations, > - transfer initialized by the driver by writing to DSIM registers. > >> >> MIPI_DSI_MODE_VIDEO_LPM >> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer >> image data to Panel device in Low Power Mode. > > What is the meaning of this flag in case of command mode of operation? > > Maybe it would be better to create flags based on source of data/FIFOs: > - commands send by SFR registers, > - commands generated from data sent from Display Controller. > I wrote the descriptions in host controller point of view: with MIPI_DSI_MODE_CMD_LPM, host controller will set the operation mode to command mode operation and transfer command data to Panel (MIPI DSI client), and with MIPI_DSI_MODE_VIDEO_LPM, host controller will set the operation mode to video mode and transfer video data (pixel stream) to Panel. However, it seems that these descriptions aren't enough. So make sure the meanings. MIPI-DSI has two operation modes, Command and Video mode. And MIPI-DSI spec says, "Command Mode refers to operation in which transactions primarily take the form of sending commands and data to a peripheral, such as a display module, that incorporates a display controller. The display controller may include local registers and a frame buffer. Systems using Command Mode write to, and read from, the registers and frame buffer memory. The host processor indirectly controls activity at the peripheral by sending commands, parameters and data to the display controller. The host processor can also read display module status information or the contents of the frame memory. Command Mode operation requires a bidirectional interface.". And also the spec says for Video mode, "Video mode Mode refers to operation in which transfers from the host processor to the peripheral take the form of a real-time pixel stream. In normal operation, the display module relies on the host processor to provide image data at sufficient bandwidth to avoid flicker or other visible artifacts in the displayed image. Video information should only be transmitted using High Speed Mode. Some Video Mode architectures may include a simple timing controller and partial frame buffer, used to maintain a partial-screen or lower-resolution image in standby or low-power mode. This permits the interface to be shut down to reduce power consumption. To reduce complexity and cost, systems that only operate in Video Mode may use a unidirectional data path." Thus, with Command mode, host can send command and image data to Panel device, and with Video mode, host can send image data to Panel device in High Speed Mode (HS clock enabled) Therefore, I think MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM flags have generic meaning, In default, host transmits Command and image data to Panel in High Speed Mode. MIP_DSI_MODE_CMD_LPM: Host transmits command and image data to Panel in Low Power mode, and also the host can read data from SRF and internal frame buffer of Panel device. With this flag, host needs to set transmission mode to Low Power Mode (and HS clock disabled) MIPI_DSI_MODE_VIDEO_LPM: Host transmits image data to Panel in Low Power mode. With this flags, host needs to set transmission mode to Low Power Mode. I think above two flags are common to all SoC. In case of Exynos MIPI-DSI, 'CmdLpdt bit = 1' specifies that host transmits commands to Panel in Low Power Mode so this would be corresponded to MIPI_DSI_MODE_CMD_LPM. However, 'TxLpdt = 1' specifies that host transmits all data that include commands and imageto Panel in Low Power Mode (and HS clock disabled). So this bit would be corresponded to MIPI_DSI_MODE_VIDEO_LPM. Feel free to give me your opinions if you have other opinions or there is my missing point. Thanks, Inki Dae > >> >> And above two flags can be combined together to transfer command and video >> data to Panel device. >> >> MIPI DSI spec says, >> "the host processor controls the desired mode of clock operation. >> Host protocol and applications control Clock Lane operating mode >> (High Speed or Low Power mode). System designers are responsible >> for understanding the clock requirements for peripherals attached >> to DSI and controlling clock behavior in accordance with those >> requirements." >>
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
On 2014? 07? 28? 17:30, Sjoerd Simons wrote: > Hey Inki, > > On Mon, 2014-07-21 at 08:50 +0200, Sjoerd Simons wrote: >> Hey Inki, >> >> On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote: >>> On 2014? 07? 19? 05:36, Sjoerd Simons wrote: >>>> The exynos DRM module currently is not automatically loaded when build as a >>>> module. This is due to the simple fact that it doesn't have any >>>> MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed >>>> previously >>>> as it wasn't possible at the time to have multiple calls to >>>> MODULE_DEVICE_TABLE >>>> in one module, however commit 21bdd17b21b45ea solved that. >>>> >>>> The first two patches revert the previous removals of MODULE_DEVICE_TABLE >>>> calls, while the last one adds calls for the remaining OF match tables >>>> without a >>>> MODULE_DEVICE_TABLE call. >> >>> Exynos drm follows single-driver model. So each usb driver of Exynos drm >>> wouldn't need its own MODULE_DEVICE_TABLE. >> >> Strictly speaking you're right, for module autoloading to work the >> module just needs to have one that matches. So in principle all other >> entries are redundant. >> >> However for exynos drm there does not seem to be one main device which >> is guaranteed to always be present which can be used to key the module >> autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries >> for all the various subdrivers to ensure autoloading actually happens, >> especially since the various subdrivers can be seperately enabled >> at build time. > > Been about a week since this last mail. If you have any suggestions on a > better approach or on how to move this forward, i'd be very grateful to > hear as i think i've addressed your original comment on the set in the > previous reply? Sorry for late, I don't see why Exynos drm driver should be auto-loaded module. I think all devices covered by Exynos drm framework are not hot-plugged. Maybe there is my missing point. So can you explain why Exynos drm driver should be auto-loaded module? Thanks, Inki Dae >
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
This patch adds LPM transfer support for video or command data.
With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.
Changelog v2: Enable High Speed clock only in case of stand by request.
Signed-off-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..1bed105 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
- | DSIM_BYTE_CLK_SRC(0)
- | DSIM_TX_REQUEST_HSCLK;
+ | DSIM_BYTE_CLK_SRC(0);
+
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
return 0;
@@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
}
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+ bool enable)
+{
+ u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
+
+ reg &= ~DSIM_TX_REQUEST_HSCLK;
+ if (enable)
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
+ writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
+}
+
static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
{
u32 reg;
@@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi
*dsi, bool enable)
{
u32 reg;
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
+ exynos_dsi_enable_hs_clock(dsi, true);
+
reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
if (enable)
reg |= DSIM_MAIN_STAND_BY;
--
1.7.9.5
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's mode_flags set by LCD Panel driver.
MIPI_DSI_MODE_CMD_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
command data to Panel device in Low Power Mode.
MIPI_DSI_MODE_VIDEO_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
image data to Panel device in Low Power Mode.
And above two flags can be combined together to transfer command and video
data to Panel device.
MIPI DSI spec says,
"the host processor controls the desired mode of clock operation.
Host protocol and applications control Clock Lane operating mode
(High Speed or Low Power mode). System designers are responsible
for understanding the clock requirements for peripherals attached
to DSI and controlling clock behavior in accordance with those
requirements."
Some LCD Panel devices, nt35502a, would need LPM transfer support
because they should receive some initial commands with LPM by default
hardware setting.
Changelog v2: just add more descriptions.
Signed-off-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/drm_mipi_dsi.c |3 +++
include/drm/drm_mipi_dsi.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index e633df2..6b2bbda 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
unsigned int channel,
break;
}
+ if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, );
}
EXPORT_SYMBOL(mipi_dsi_dcs_write);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..1c41e49 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
#define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
/* disable EoT packets in HS mode */
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
+/* command low power mode */
+#define MIPI_DSI_MODE_CMD_LPM BIT(10)
+/* video low power mode */
+#define MIPI_DSI_MODE_VIDEO_LPMBIT(11)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
--
1.7.9.5
[PATCH v2 0/2] drm/mipi-dsi: support lpm (low power mode) transfer
This patch series adds lpm tranfer support for video and command data. for this, this patch adds two flags, and makes mipi dsi host to send commands to lcd panel device with lpm if mode_flags of lcd panel driver includes lpm flag. and also it applies this feature to exynos mipi dsi driver. Changelog v2: - Add more describtions. - Enable High Speed clock only in case of stand by request. Inki Dae (2): drm/mipi-dsi: add (LPM) Low Power Mode transfer support drm/exynos: dsi: add LPM (Low Power Mode) transfer support drivers/gpu/drm/drm_mipi_dsi.c |3 +++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 -- include/drm/drm_mipi_dsi.h |4 3 files changed, 27 insertions(+), 2 deletions(-) -- 1.7.9.5
[PATCH 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 2014? 07? 24? 19:48, Andrzej Hajda wrote:
> +CC: Thierry and Alexandre
>
> On 07/18/2014 12:56 PM, Inki Dae wrote:
>> This patch adds LPM transfer support for video or command data.
>>
>> With this patch, Exynos MIPI DSI controller can transfer command or
>> video data with HS or LP mode in accordance with mode_flags set
>> by LCD Panel driver.
>>
>> Signed-off-by: Inki Dae
>> Acked-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 2df3592..b120554 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -426,13 +426,28 @@ static int exynos_dsi_enable_clock(struct exynos_dsi
>> *dsi)
>> | DSIM_ESC_PRESCALER(esc_div)
>> | DSIM_LANE_ESC_CLK_EN_CLK
>> | DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
>> -| DSIM_BYTE_CLK_SRC(0)
>> -| DSIM_TX_REQUEST_HSCLK;
>> +| DSIM_BYTE_CLK_SRC(0);
>> +
>> +if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
>> +reg |= DSIM_TX_REQUEST_HSCLK;
>> +
>
> Maybe I missed sth but it seems to me slightly unrelated to LPM flag.
> According to specs some panels can require this clock even in LPM mode.
> I wonder if recently introduced MIPI_DSI_CLOCK_NON_CONTINUOUS wouldn't
> handle it.
It's different. MIPI DSI spec says,
"For continuous clock behaviour, the Clock Lane remains in high-speed
mode generating active clock signals between HS data packet
transmissions. For non-continuous clock behaviour, *the Clock Lane
enters the LP-11 state between HS data packet transmissions*."
>
>> writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>>
>> return 0;
>> }
>>
>> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
>> +bool enable)
>> +{
>> +u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
>> +
>> +reg &= ~DSIM_TX_REQUEST_HSCLK;
>> +if (enable)
>> +reg |= DSIM_TX_REQUEST_HSCLK;
>> +
>> +writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>> +}
>> +
>> static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>> {
>> u32 reg;
>> @@ -575,6 +590,9 @@ static void exynos_dsi_set_display_enable(struct
>> exynos_dsi *dsi, bool enable)
>> {
>> u32 reg;
>>
>> +if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM))
>> +exynos_dsi_enable_hs_clock(dsi, true);
>> +
>
> It does not care about enable argument of the function, I guess it should.
>
Yes, it's better to enable HS clock only in case of enabling. So will
add one more flag like below,
if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
Thank,
Inki Dae
> Regards
> Andrzej
>
>> reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>> if (enable)
>> reg |= DSIM_MAIN_STAND_BY;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[PATCH 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 07? 24? 19:23, Andrzej Hajda wrote:
> Hi Inki,
>
> +CC: Thierry and Alexandre
>
> On 07/18/2014 12:56 PM, Inki Dae wrote:
>> This patch adds below two flags for LPM transfer, and it attaches LPM flags
>> to a msg in accordance with master's mode_flags set by LCD Panel driver.
>>
>> MIPI_DSI_MODE_CMD_LPM: low power command transfer
>> MIPI_DSI_MODE_VIDEO_LPM: low power video transfer
> What is the difference between these two?
They mean that MIPI DSI controller have to transfer command or video to
Panel in Low Power Mode according to these flags.
> Why not just MIPI_DSI_MODE_LPM combined optionally with
> MIPI_DSI_MODE_VIDEO ?
> Anyway as I understand the only role of this flag is to always trigger
> MIPI_DSI_MSG_USE_LPM flag in DSI message. Maybe better is to check both
> flags in DSI host, using some helper function.
No any flag would mean that video and command data have to be
transferred in HS mode. On the other hands, if there is one of above
flags, the data would be transferred in Low Power Mode. So I think
separated flags, MIPI_DSI_MODE_VIDEO/COMMAND and MIPI_DSI_MODE_LPM
causes unnecessary flag combination.
>
>>
>> MIPI DSI spec says,
>> "the host processor controls the desired mode of clock operation.
>> Host protocol and applications control Clock Lane operating mode
>> (High Speed or Low Power mode). System designers are responsible
>> for understanding the clock requirements for peripherals attached
>> to DSI and controlling clock behavior in accordance with those
>> requirements."
>>
>> Some LCD Panel devices, nt35502a, would need LPM transfer support
>> because they should receive some initial commands with LPM by default
>> hardware setting.
>
> It would be good to see usage of this flag in the driver. Is it possible
> to post it?
Yes, but that driver is needed for more cleanup works. Anyway I will
post it in the near future.
>
> I have posted few months ago TC358764 driver[1] which also uses LPM for
> initialization, have you look at it.
>
> [1]:
> http://lists.freedesktop.org/archives/dri-devel/2014-February/053713.html
>
> Regards
> Andrzej
>
>>
>> Signed-off-by: Inki Dae
>> Acked-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/drm_mipi_dsi.c |3 +++
>> include/drm/drm_mipi_dsi.h |4
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
>> index e633df2..6b2bbda 100644
>> --- a/drivers/gpu/drm/drm_mipi_dsi.c
>> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
>> @@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
>> unsigned int channel,
>> break;
>> }
>>
>> +if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
>> +msg.flags = MIPI_DSI_MSG_USE_LPM;
>> +
>> return ops->transfer(dsi->host, );
>> }
>> EXPORT_SYMBOL(mipi_dsi_dcs_write);
>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>> index 944f33f..1c41e49 100644
>> --- a/include/drm/drm_mipi_dsi.h
>> +++ b/include/drm/drm_mipi_dsi.h
>> @@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
>> #define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
>> /* disable EoT packets in HS mode */
>> #define MIPI_DSI_MODE_EOT_PACKETBIT(9)
>> +/* command low power mode */
>> +#define MIPI_DSI_MODE_CMD_LPM BIT(10)
>> +/* video low power mode */
>> +#define MIPI_DSI_MODE_VIDEO_LPM BIT(11)
>>
>> enum mipi_dsi_pixel_format {
>> MIPI_DSI_FMT_RGB888,
>
>
[PATCH v6 00/14] drm/exynos: support LCD I80 interface display
On 2014? 07? 17? 18:01, YoungJun Cho wrote: > Hi, > > This series adds LCD I80 interface display support for Exynos DRM driver. > The FIMD(display controller) specification describes it as "LCD I80 interface" > and the DSI specification describes it as "Command mode interface". > > This is based on exynos-drm-next branch. > > The previous patches, > RFC: http://www.spinics.net/lists/dri-devel/msg58898.html > V1: http://www.spinics.net/lists/dri-devel/msg59291.html > V2: http://www.spinics.net/lists/dri-devel/msg59867.html > V3: http://www.spinics.net/lists/dri-devel/msg60708.html > V4: http://www.spinics.net/lists/dri-devel/msg60943.html > V5: http://www.spinics.net/lists/dri-devel/msg62956.html > > Changelog v2: > - Fixes typo and removes unnecessary error log. (commented by Andrzej Hazda) > - Adds missed pendlig_flip flag clear points. (commented by Daniel Kurtz) > > Changelog v3: > - Removes generic command mode and command mode display timing interface. > - Moves I80 interface timings from panel DT to the FIMD(display controller) > DT. > > Changelog v4: > - Removes exynos5 sysreg(syscon) DT bindings and node from dtsi because > it was already updated by linux-samsung-soc. (commented by Vivek Gautam) > > Changelog v5: > - Fixes FIMD vidcon0 register relevant code. > - Fixes panel gamma table, disable sequence. > - Slitely updates for code cleanup. > > Changelog v6: > - Removes pass TE host ops in dsi and exynos dsi uses TE irq handler instead, > and it is related with the TE GPIO of panel. (commented by Thierry Reding) > > Patches 1 and 2 fix trivial bugs. > > Patches 3, 4, 5 and 6 implement FIMD(display controller) I80 interface. > The MIPI DSI command mode based panel generates Tearing Effect synchronization > signal between MCU and FB to display video image, and FIMD should trigger to > transfer video image at this signal. > So the panel generates it and the dsi should receive the TE IRQ and call TE > handler chains to notify it to the FIMD. > > Patches 7 and 8 implement to use Exynos5410 / 5420 / 5440 SoC DSI driver > which is different from previous Exynos4 SoCs for some registers control. > > Patches 9 and 10 introduce MIPI DSI command mode based Samsung S6E3FA0 AMOLED > 5.7" LCD drm panel driver. > > The ohters add DT property nodes to support MIPI DSI command mode. > > I welcome any comments. > > Thank you. > Best regards YJ > > YoungJun Cho (14): > drm/exynos: dsi: move the EoT packets configuration point > drm/exynos: use wait_event_timeout() for safety usage > ARM: dts: samsung-fimd: add LCD I80 interface specific properties > drm/exynos: add TE handler to support LCD I80 interface > drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface > drm/exynos: fimd: support LCD I80 interface > ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings > drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs > ARM: dts: s6e3fa0: add DT bindings > drm/panel: add S6E3FA0 driver > ARM: dts: exynos4: add system register property > ARM: dts: exynos5: add system register property > ARM: dts: exynos5420: add mipi-phy node > ARM: dts: exynos5420: add dsi node Piked them up except patch 9 and 10. The two patches are needed for more review and consensus Thanks, Inki Dae > > .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 46 ++ > .../devicetree/bindings/video/exynos_dsim.txt | 4 +- > .../devicetree/bindings/video/samsung-fimd.txt | 28 ++ > arch/arm/boot/dts/exynos4.dtsi | 1 + > arch/arm/boot/dts/exynos5.dtsi | 1 + > arch/arm/boot/dts/exynos5420.dtsi | 20 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 + > drivers/gpu/drm/exynos/exynos_drm_drv.h| 3 + > drivers/gpu/drm/exynos/exynos_drm_dsi.c| 266 +- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 276 +-- > drivers/gpu/drm/panel/Kconfig | 7 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-s6e3fa0.c | 541 > + > include/video/samsung_fimd.h | 3 +- > 16 files changed, 1146 insertions(+), 74 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt > create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c >
[PATCH 00/12] drm/exynos/ipp: image post processing improvements, part three
On 2014? 07? 03? 22:10, Andrzej Hajda wrote: > This set of independent patches contains various improvement and fixes > for exynos_drm ipp framework. > The patchset is based on exynos-drm-next branch. Applied. Thanks, Inki Dae > > Regards > Andrzej > > > Andrzej Hajda (12): > drm/exynos/ipp: remove type casting > drm/exynos/ipp: remove unused field from exynos_drm_ipp_private > drm/exynos/ipp: remove struct exynos_drm_ipp_private > drm/exynos/ipp: correct address type > drm/exynos/ipp: remove temporary variable > drm/exynos/ipp: remove incorrect checks of list_first_entry result > drm/exynos/ipp: simplify memory check function > drm/exynos/ipp: remove useless registration checks > drm/exynos/ipp: simplify ipp_find_obj > drm/exynos/ipp: remove redundant messages > drm/exynos/ipp: simplify ipp_create_id > drm/exynos/ipp: simplify ipp_find_driver > > drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 +- > drivers/gpu/drm/exynos/exynos_drm_ipp.c | 259 > +--- > drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +- > 3 files changed, 73 insertions(+), 197 deletions(-) >
[PATCH v6 05/14] drm/exynos: dsi: add TE interrupt handler to support LCD I80 interface
On 2014? 07? 21? 23:01, Andrzej Hajda wrote:
> On 07/17/2014 11:01 AM, YoungJun Cho wrote:
>> To support LCD I80 interface, the DSI host should register
>> TE interrupt handler from the TE GPIO of attached panel.
>> So the panel generates a tearing effect synchronization signal
>> then the DSI host calls the CRTC device manager to trigger
>> to transfer video image.
>>
>
> This whole patch seems to be a hack.
>
> I think it is not a good idea to parse property of one device by another
> device's driver.
>
> Especially here TE GPIO belongs to the panel. The panel driver should
> know how to configure it and how to use it or not. The panel driver will
> generate TE signal based on this GPIO, DSI/BTA mechanism or any other
> mechanism provided by the panel.
> TE signal should be delivered to the display controller. The only role
> of DSIM here is that it is between the panel and the display controller
> so it should be used to route this signal to DC.
>
> According to specs TE signal should/can be generated by DBI and DSI
> command mode panels, so its handling should be more generic, not Exynos
> specific.
>
Right. However, it seems that there are no much users using command mode
panel so we would need more times to discuss the generic way. I think we
can have this feature in specific to Exynos drm - it doesn't affect
other SoC -. Actually, I know OMAP people handle this feature in a way
specific to OMAP SoC. If other users need more generic way to this
feature then we could have a discussion about the generic way at that time.
That is why Mr. Cho implemented TE feature like this. Do you have more
good idea? I wish the idea would be specific so that Mr. Cho can
implement it.
P.s. Thierry already opposed the use of mipi_dsi_host_ops, I agree with
him. And also it seems not good to use crtc and encoder/connector
because these frameworks are common to all architecture including x86 so
other architectures wouldn't need TE feature.
Thanks,
Inki Dae
> Regards
> Andrzej
>
>> Signed-off-by: YoungJun Cho
>> Acked-by: Inki Dae
>> Acked-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 95
>> -
>> 1 file changed, 93 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index 58bfb2a..4997bfe 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -16,7 +16,9 @@
>> #include
>>
>> #include
>> +#include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -24,6 +26,7 @@
>> #include
>> #include
>>
>> +#include "exynos_drm_crtc.h"
>> #include "exynos_drm_drv.h"
>>
>> /* returns true iff both arguments logically differs */
>> @@ -247,6 +250,7 @@ struct exynos_dsi {
>> struct clk *bus_clk;
>> struct regulator_bulk_data supplies[2];
>> int irq;
>> +int te_gpio;
>>
>> u32 pll_clk_rate;
>> u32 burst_clk_rate;
>> @@ -954,17 +958,89 @@ static irqreturn_t exynos_dsi_irq(int irq, void
>> *dev_id)
>> return IRQ_HANDLED;
>> }
>>
>> +static irqreturn_t exynos_dsi_te_irq_handler(int irq, void *dev_id)
>> +{
>> +struct exynos_dsi *dsi = (struct exynos_dsi *)dev_id;
>> +struct drm_encoder *encoder = dsi->encoder;
>> +
>> +if (dsi->state & DSIM_STATE_ENABLED)
>> +exynos_drm_crtc_te_handler(encoder->crtc);
>> +
>> +return IRQ_HANDLED;
>> +}
>> +
>> +static void exynos_dsi_enable_irq(struct exynos_dsi *dsi)
>> +{
>> +enable_irq(dsi->irq);
>> +
>> +if (gpio_is_valid(dsi->te_gpio))
>> +enable_irq(gpio_to_irq(dsi->te_gpio));
>> +}
>> +
>> +static void exynos_dsi_disable_irq(struct exynos_dsi *dsi)
>> +{
>> +if (gpio_is_valid(dsi->te_gpio))
>> +disable_irq(gpio_to_irq(dsi->te_gpio));
>> +
>> +disable_irq(dsi->irq);
>> +}
>> +
>> static int exynos_dsi_init(struct exynos_dsi *dsi)
>> {
>> exynos_dsi_enable_clock(dsi);
>> exynos_dsi_reset(dsi);
>> -enable_irq(dsi->irq);
>> +exynos_dsi_enable_irq(dsi);
>> exynos_dsi_wait_for_reset(dsi);
>> exynos_dsi_init_link(dsi);
>>
>> return 0;
>> }
>>
>> +static int exynos_dsi_register_te_irq(struct exynos_dsi *dsi)
>> +{
>> +int ret;
>>
[PATCH 00/12] drm/exynos/ipp: image post processing improvements, part three
On 2014? 07? 21? 18:23, Andrzej Hajda wrote: > Hi Inki, > > On 07/09/2014 04:47 PM, Inki Dae wrote: >> On 2014? 07? 03? 22:10, Andrzej Hajda wrote: >>> This set of independent patches contains various improvement and fixes >>> for exynos_drm ipp framework. >>> The patchset is based on exynos-drm-next branch. >>> >> Did you test ipp module using libdrm? If so, can you share the app? I >> would try to test this patch series before merging them. Mainline libdrm >> has no any ipp interfaces. > > I have used ipptest program developed by you :), with minor changes. > More advanced tests are on my TODO list, but for this patchset ipptest > seems to be OK - the patches are mainly cleanup patches. > Did the ipptest work fine? I just tried to build the app so didn't test the app. :) Got it, will merge this patch series. Thanks, Inki Dae > Regards > Andrzej > >> >> Thanks, >> Inki Dae >> >>> Regards >>> Andrzej >>> >>> >>> Andrzej Hajda (12): >>> drm/exynos/ipp: remove type casting >>> drm/exynos/ipp: remove unused field from exynos_drm_ipp_private >>> drm/exynos/ipp: remove struct exynos_drm_ipp_private >>> drm/exynos/ipp: correct address type >>> drm/exynos/ipp: remove temporary variable >>> drm/exynos/ipp: remove incorrect checks of list_first_entry result >>> drm/exynos/ipp: simplify memory check function >>> drm/exynos/ipp: remove useless registration checks >>> drm/exynos/ipp: simplify ipp_find_obj >>> drm/exynos/ipp: remove redundant messages >>> drm/exynos/ipp: simplify ipp_create_id >>> drm/exynos/ipp: simplify ipp_find_driver >>> >>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 7 +- >>> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 259 >>> +--- >>> drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +- >>> 3 files changed, 73 insertions(+), 197 deletions(-) >>> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining
> -
> -out:
> - if (power_off)
> - ptn3460_disable(ptn_bridge->bridge);
> -
> - return num_modes;
> -}
> -
> -struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
> -{
> - struct ptn3460_bridge *ptn_bridge;
> -
> - ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
> -
> - return ptn_bridge->encoder;
> -}
> -
> -struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
> - .get_modes = ptn3460_get_modes,
> - .best_encoder = ptn3460_best_encoder,
> -};
> -
> -enum drm_connector_status ptn3460_detect(struct drm_connector *connector,
> - bool force)
> -{
> - return connector_status_connected;
> -}
> -
> -void ptn3460_connector_destroy(struct drm_connector *connector)
> -{
> - drm_connector_cleanup(connector);
> -}
> -
> -struct drm_connector_funcs ptn3460_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> - .detect = ptn3460_detect,
> - .destroy = ptn3460_connector_destroy,
> -};
> -
> -int ptn3460_init(struct drm_device *dev, struct drm_encoder *encoder,
> - struct i2c_client *client, struct device_node *node)
> +struct drm_bridge *ptn3460_init(struct drm_device *dev,
> + struct drm_encoder *encoder,
> + struct i2c_client *client,
> + struct device_node *node)
> {
> int ret;
> struct drm_bridge *bridge;
> @@ -267,13 +183,13 @@ int ptn3460_init(struct drm_device *dev, struct
> drm_encoder *encoder,
> bridge = devm_kzalloc(dev->dev, sizeof(*bridge), GFP_KERNEL);
> if (!bridge) {
> DRM_ERROR("Failed to allocate drm bridge\n");
> - return -ENOMEM;
> + return NULL;
I think you could handle error case correctly. Please return
ERR_PTR(-ENOMEM) instead of NULL, and below codes also.
Thanks,
Inki Dae
> }
>
> ptn_bridge = devm_kzalloc(dev->dev, sizeof(*ptn_bridge), GFP_KERNEL);
> if (!ptn_bridge) {
> DRM_ERROR("Failed to allocate ptn bridge\n");
> - return -ENOMEM;
> + return NULL;
> }
>
> ptn_bridge->client = client;
> @@ -285,7 +201,7 @@ int ptn3460_init(struct drm_device *dev, struct
> drm_encoder *encoder,
> GPIOF_OUT_INIT_HIGH, "PTN3460_PD_N");
> if (ret) {
> DRM_ERROR("Request powerdown-gpio failed (%d)\n", ret);
> - return ret;
> + return NULL;
> }
> }
>
> @@ -300,7 +216,7 @@ int ptn3460_init(struct drm_device *dev, struct
> drm_encoder *encoder,
> if (ret) {
> DRM_ERROR("Request reset-gpio failed (%d)\n", ret);
> gpio_free(ptn_bridge->gpio_pd_n);
> - return ret;
> + return NULL;
> }
> }
>
[PATCH V5 00/12] drm/exynos: few patches to enhance bridge chip support
On 2014? 07? 18? 05:43, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > This patchset also consolidates various inputs from the drm community > regarding the bridge chaining concept: > (1) [RFC V2 0/3] drm/bridge: panel and chaining > http://www.spinics.net/lists/linux-samsung-soc/msg30160.html > (2) [RFC V3 0/3] drm/bridge: panel and chaining > http://www.spinics.net/lists/linux-samsung-soc/msg30507.html > > I have tested this after adding few DT changes for exynos5250-snow, > exynos5420-peach-pit and exynos5800-peach-pi boards. > > The V4 series of this particular patchset was also tested by: > Rahul Sharma > Javier Martinez Canillas > > Changes since V2: > -- Address comments from Jingoo Han for ps8622 driver > -- Address comments from Daniel, Rob and Thierry regarding > bridge chaining > -- Address comments from Thierry regarding the names for > new drm_panel functions > > Changes since V3: > -- Remove hotplug based initialization of exynos_dp > -- Make exynos_dp work directly with drm_panel, remove > dependency on panel_binder > -- Minor cleanups in panel_binder and panel_lvds driver > > Changes since V4: > -- Use gpiod interface for panel-lvds and ps8622 drivers. > -- Address comments from Javier. > -- Fix compilation issues when PANEL_BINDER is selected as module. > -- Split Documentation patches from driver patches. > -- Rebase on top of the tree. Hi Ajay, Thanks for your contribution. I am reviewing your patch series. Sorry for late. Below is my comment. How about using graph concept to bind eDP, LVDS bridge, and Panel? Your patch tries to bind bridge driver using find_bridge function, and this function tries to find bridge device node directly using of_find_compatible_node() again, which in turn make eDP driver to add all codes related to all bridge devices including all relevant bridge headers: i.e., if there are five bridge devices then eDP driver should try to find all of them. That is really not good. So my opinion is to define the relationship between eDP, LVDS, and Panel using graph concept: eDP context would have panel and bridge object according to graph definition of device tree. As a result, eDP context has already bridge_chain object for lvds bridge device and panel_binder->bridge object in exynos_drm_attach_lcd_bridge function context so it can add bridge_chain object to panel_binder->bridge as is there. I think lvds bridge device drivers could follow Linux driver model with this approach. Rob, it seems to need at least your ACK so that I can merge this patch series to exynos-drm-next. Thanks, Inki Dae > > Ajay Kumar (9): > [RESEND PATCH V5 01/12] drm/exynos: Move DP setup out of hotplug workqueue > [RESEND PATCH V5 02/12] drm/panel: add prepare and unprepare routines > [RESEND PATCH V5 03/12] drm/exynos: dp: modify driver to support drm_panel > [PATCH V5 04/12] drm/panel: Add driver for lvds/edp based panels > [PATCH V5 05/12] Documentation: Add DT bindings for panel-lvds driver > [RESEND PATCH V5 06/12] drm/bridge: add helper functions to support bridge > chain > [PATCH V5 07/12] drm/bridge: Add a driver which binds drm_bridge with > drm_panel > [RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining > [RESEND PATCH V5 09/12] drm/exynos: dp: create bridge chain using ptn3460 > and panel_binder > > Vincent Palatin (2): > [PATCH V5 10/12] Documentation: Add DT bindings for ps8622/ps8625 bridge > driver > [PATCH V5 11/12] drm/bridge: Add ps8622/ps8625 bridge driver > > Rahul Sharma (1): > [RESEND PATCH V5 12/12] drm/exynos: Add ps8622 lvds bridge discovery to DP > driver > > .../devicetree/bindings/drm/bridge/ps8622.txt | 21 + > .../devicetree/bindings/panel/panel-lvds.txt | 50 ++ > .../devicetree/bindings/video/exynos_dp.txt|2 + > drivers/gpu/drm/bridge/Kconfig | 15 + > drivers/gpu/drm/bridge/Makefile|2 + > drivers/gpu/drm/bridge/panel_binder.c | 193 > drivers/gpu/drm/bridge/ps8622.c| 476 > > drivers/gpu/drm/bridge/ptn3460.c | 137 +- > drivers/gpu/drm/exynos/Kconfig |1 + > drivers/gpu/drm/exynos/exynos_dp_core.c| 87 +++- > drivers/gpu/drm/exynos/exynos_dp_core.h|2 + > drivers/gpu/drm/panel/Kconfig | 10 + > drivers/gpu/drm/panel/Makefile |1 + > drivers/gpu/drm/panel/panel-lvds.c | 26
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
On 2014? 07? 19? 05:36, Sjoerd Simons wrote: > The exynos DRM module currently is not automatically loaded when build as a > module. This is due to the simple fact that it doesn't have any > MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed > previously > as it wasn't possible at the time to have multiple calls to > MODULE_DEVICE_TABLE > in one module, however commit 21bdd17b21b45ea solved that. > > The first two patches revert the previous removals of MODULE_DEVICE_TABLE > calls, while the last one adds calls for the remaining OF match tables > without a > MODULE_DEVICE_TABLE call. Hi, Exynos drm follows single-driver model. So each usb driver of Exynos drm wouldn't need its own MODULE_DEVICE_TABLE. Thanks, Inki Dae > > Sjoerd Simons (3): > Revert "drm/exynos: fix module build error" > Revert "drm/exynos: remove MODULE_DEVICE_TABLE definitions" > drm/exynos: Add MODULE_DEVICE_TABLE entries for various components > > drivers/gpu/drm/exynos/exynos_dp_core.c | 1 + > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 + > drivers/gpu/drm/exynos/exynos_drm_fimc.c| 1 + > drivers/gpu/drm/exynos/exynos_drm_fimd.c| 1 + > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 + > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 + > drivers/gpu/drm/exynos/exynos_hdmi.c| 1 + > drivers/gpu/drm/exynos/exynos_mixer.c | 1 + > 8 files changed, 8 insertions(+) >
[PATCH 0/7] Exynos4: enable HDMI support for Odroid and UniversalC210
2014-07-01 17:10 GMT+09:00 Marek Szyprowski :
> Hello,
>
> This is a long awaited patch series enabling support for HDMI output
> available on Exynos4412-based Odroid boards (X/X2/U2/U3/U3+) and
> Exynos4210 Universal C210 board.
>
> This patch consists of 3 groups of patches, which are aimed to be merged
> to respective maintainer kernel trees.
>
> First patch ("clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER
> clocks") adds missing device tree support for hdmi related clocks. It is
> prepared for clk kernel tree.
>
> Next two patches ("drm: exynos: hdmi: make 'hdmi-en' regulator optional
> and keep it enabled" and "drm: hdmi/mixer: enable exynos 4210 and 4x12
> soc support") add proper support for Exynos4 SoCs to Exynos DRM drivers.
> Those patches should go to exynos-drm kernel tree.
Picked them up.
Thanks,
Inki Dae
>
> Last patches ("Exynos: add support for 'domain-always-on' property",
> "ARM: dts: exynos4: add hdmi related nodes", "ARM: dts:
> exynos4412-odroid: enable hdmi support" and "ARM: dts:
> exynos4210-universal_c210: enable hdmi support") adds changes to all DTS
> files and adds 'domain-always-on' property to Exynos power-domain
> driver. This property is needed to resolve the non-trivial dependences
> between TV and LCD0 power domains and the power on/off sequence of the
> TV and mixer modules.
>
> Patches are prepared on top of v3.16-rc3 with '[PATCH v2 0/4] Add
> Exynos4412 based Odroid X2 and U2/U3/U3+ support' series and '[PATCH]
> ARM: dts: exynos4412-odroid: add support for GPIO buttons' patch
> applied:
> http://www.spinics.net/lists/linux-samsung-soc/msg33115.html
> http://www.spinics.net/lists/linux-samsung-soc/msg33497.html
>
> Kernel tree with all Odroid related patches is available at
> http://git.linaro.org/git-ro/people/marek.szyprowski/linux-srpol.git
> on v3.16-odroid branch.
>
> Best regards
> Marek Szyprowski
> Samsung R Institute Poland
>
> Marek Szyprowski (6):
> clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks
> drm: exynos: hdmi: make 'hdmi-en' regulator optional and keep it
> enabled
> drm: hdmi/mixer: enable exynos 4210 and 4x12 soc support
> Exynos: add support for 'domain-always-on' property
> ARM: dts: exynos4: add hdmi related nodes
> ARM: dts: exynos4412-odroid: enable hdmi support
>
> Tomasz Stanislawski (1):
> ARM: dts: exynos4210-universal_c210: enable hdmi support
>
> .../bindings/arm/exynos/power_domain.txt | 2 +
> .../devicetree/bindings/video/exynos_mixer.txt | 5 +-
> arch/arm/boot/dts/exynos4.dtsi | 37
> arch/arm/boot/dts/exynos4210-universal_c210.dts| 65
> ++
> arch/arm/boot/dts/exynos4210.dtsi | 5 ++
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 52 +
> arch/arm/boot/dts/exynos4x12.dtsi | 10
> arch/arm/mach-exynos/pm_domains.c | 6 +-
> drivers/clk/samsung/clk-exynos4.c | 4 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 29 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 51 -
> include/dt-bindings/clock/exynos4.h| 2 +
> 12 files changed, 247 insertions(+), 21 deletions(-)
>
> --
> 1.9.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
This patch adds LPM transfer support for video or command data.
With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.
Signed-off-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2df3592..b120554 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -426,13 +426,28 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
- | DSIM_BYTE_CLK_SRC(0)
- | DSIM_TX_REQUEST_HSCLK;
+ | DSIM_BYTE_CLK_SRC(0);
+
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
return 0;
}
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+ bool enable)
+{
+ u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
+
+ reg &= ~DSIM_TX_REQUEST_HSCLK;
+ if (enable)
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
+ writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
+}
+
static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
{
u32 reg;
@@ -575,6 +590,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi
*dsi, bool enable)
{
u32 reg;
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM))
+ exynos_dsi_enable_hs_clock(dsi, true);
+
reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
if (enable)
reg |= DSIM_MAIN_STAND_BY;
--
1.7.9.5
