[PATCH] drm/exynos: add mic_bypass option for exynos542x fimd
Hi Chanho,
2016ë
01ì 30ì¼ 22:58ì Chanho Park ì´(ê°) ì´ ê¸:
> From: Chanho Park
>
> This patch adds a mic_bypass option to bypass the mic
> from display out path. The mic(Mobile image compressor) compresses
> RGB data from fimd and send the compressed data to the mipi dsi.
> The bypass option can be founded from system register and the bit
> of the option is 11.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Signed-off-by: Chanho Park
> ---
> .../devicetree/bindings/display/exynos/samsung-fimd.txt| 2 ++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14
> ++
> 2 files changed, 16 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> index 27c3ce0..7f90c4a 100644
> --- a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> @@ -45,6 +45,8 @@ Optional Properties:
> Can be used in case timings cannot be provided otherwise
> or to override timings provided by the panel.
> - samsung,sysreg: handle to syscon used to control the system registers
> +- samsung,mic-bypass: bypass mic(mobile image compressor) from display path.
> + This option is only available since exynos5420.
> - i80-if-timings: timing configuration for lcd i80 interface support.
>- cs-setup: clock cycles for the active period of address signal is enabled
>until chip select is enabled.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 70194d0..4fb2952 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -94,6 +94,7 @@ struct fimd_driver_data {
> unsigned int lcdblk_offset;
> unsigned int lcdblk_vt_shift;
> unsigned int lcdblk_bypass_shift;
> + unsigned int lcdblk_mic_bypass_shift;
>
> unsigned int has_shadowcon:1;
> unsigned int has_clksel:1;
> @@ -140,6 +141,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data =
> {
> .lcdblk_offset = 0x214,
> .lcdblk_vt_shift = 24,
> .lcdblk_bypass_shift = 15,
> + .lcdblk_mic_bypass_shift = 11,
> .has_shadowcon = 1,
> .has_vidoutcon = 1,
> .has_vtsel = 1,
> @@ -162,6 +164,7 @@ struct fimd_context {
> u32 i80ifcon;
> booli80_if;
> boolsuspended;
> + boolmic_bypass;
> int pipe;
> wait_queue_head_t wait_vsync_queue;
> atomic_twait_vsync_event;
> @@ -461,6 +464,14 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
> return;
> }
>
> + if (ctx->mic_bypass && ctx->sysreg && regmap_update_bits(ctx->sysreg,
> + driver_data->lcdblk_offset,
> + 0x1 << driver_data->lcdblk_mic_bypass_shift,
> + 0x1 << driver_data->lcdblk_mic_bypass_shift)) {
> + DRM_ERROR("Failed to update sysreg for bypass mic.\n");
> + return;
> + }
It'd better to consider mic path also because mic bypass bit of lcdblk could be
true by bootloader. In this case, fimd driver wouldn't do anything if
mic_bypass property isn't declared but the mic_bypass bit of lcdblk register is
still set to 1.
For this, I think you could check lcdblk_mic_pypass_shift to identify whether
mic path is supported or not like below,
if (ctx->lcdblk_mic_bypass_shift) {
if (ctx->sysreg && regmap_update_bits(ctx->sysreg,
driver_data->lcdblk_offset,
ctx->mic_bypass <<
driver_data->lcdblk_mic_bypass_shift,
ctx->mic_bypass <<
driver_data->lcdblk_mic_bypass_shift)) {
...
}
}
Thanks,
Inki Dae
> +
> /* setup horizontal and vertical display size. */
> val = VIDTCON2_LINEVAL(mode->vdisplay - 1) |
> VIDTCON2_HOZVAL(mode->hdisplay - 1) |
> @@ -1014,6 +1025,9 @@ static int fimd_probe(struct platform_device *pdev)
> if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
> ctx->vidcon1 |= VIDCON1_INV_VCLK;
>
> + if (of_property_read_bool(dev->of_node, "samsung,mic-bypass"))
> + ctx->mic_bypass = true;
> +
> i80_if_timings = of_get_child_by_name(dev->of_node, "i80-if-timings");
> if (i80_if_timings) {
> u32 val;
>
[GIT PULL] exynos-drm-fixes
Hi Dave, 2016ë 02ì 05ì¼ 13:46ì Dave Airlie ì´(ê°) ì´ ê¸: > On 1 February 2016 at 16:42, Inki Dae wrote: >> Hi Dave, >> >>Just regression fixes. >>- Fix build warning and error without PM configuration >>- Fix no display issue on Snow board reported by Michal Suchanek, >> http://www.spinics.net/lists/dri-devel/msg99473.html >> >>Plese, kindly let me know if there is any problem. >> >> Thanks, >> Inki Dae >> >> The following changes since commit d8b8eb829d4c30cd1e41a1ddc308a0e7c22169da: >> >> Merge branch 'drm-rockchip-next-fixes-2016-01-22' of >> https://github.com/markyzq/kernel-drm-rockchip into drm-fixes (2016-01-29 >> 10:04:29 +1000) >> >> are available in the git repository at: >> >> >> gitolite.kernel.org:/pub/scm/linux/kernel/git/daeinki/drm-exynos >> exynos-drm-fixes > > Hi Inki, > > this URL isn't valid, please make a git:// URL in your repo to > generate pull requests against. Sorry for this. > > I've fixed this up this time to git://git.kernel.org, but please fix > your scripts. Got it. Thanks, Inki Dae > > Dave. > >
[PATCH 02/10] drm/exynos: ipp: fix incorrect format specifiers in debug messages
2016ë
02ì 04ì¼ 11:17ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸:
> On 03.02.2016 21:42, Marek Szyprowski wrote:
>> Drivers should use %p for printing pointers instead of hardcoding them
>> as hexadecimal integers. This patch fixes compilation warnings on 64bit
>> architectures.
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fimc.c| 2 +-
>> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 2 +-
>> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 32
>> ++---
>> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 2 +-
>> 4 files changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> index c747824..8a4f4a0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> @@ -1723,7 +1723,7 @@ static int fimc_probe(struct platform_device *pdev)
>> goto err_put_clk;
>> }
>>
>> -DRM_DEBUG_KMS("id[%d]ippdrv[0x%x]\n", ctx->id, (int)ippdrv);
>> +DRM_DEBUG_KMS("id[%d]ippdrv[%p]\n", ctx->id, ippdrv);
>
> I don't oppose the patch itself but I have different concern. First -
> probably you meant %pK because this is a writeable structure with
> function pointers.
> Second - why the ippdrv has to be printed? Is it useful for debugging?
Marek fixed just compilation warnings on ARM64 so yes it wouldn't need to print
out ippdrv address but as other cleanup patch.
Thanks,
Inki Dae
>
> Best regards,
> Krzysztof
>
> --
> 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
>
>
[GIT PULL] exynos-drm-fixes
Hi Dave, Just regression fixes. - Fix build warning and error without PM configuration - Fix no display issue on Snow board reported by Michal Suchanek, http://www.spinics.net/lists/dri-devel/msg99473.html Plese, kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit d8b8eb829d4c30cd1e41a1ddc308a0e7c22169da: Merge branch 'drm-rockchip-next-fixes-2016-01-22' of https://github.com/markyzq/kernel-drm-rockchip into drm-fixes (2016-01-29 10:04:29 +1000) are available in the git repository at: gitolite.kernel.org:/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-fixes for you to fetch changes up to 37e110625eeeaba83e8cb763ab7645f0678c6f8e: drm/exynos: dp: Fix panel and bridge lookup logic (2016-02-01 14:54:29 +0900) Arnd Bergmann (2): drm/exynos: fix building without CONFIG_PM_SLEEP drm: exynos: make PM functions as __maybe_unused Javier Martinez Canillas (1): drm/exynos: dp: Fix panel and bridge lookup logic drivers/gpu/drm/exynos/exynos_dp_core.c | 55 +++-- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++-- 3 files changed, 29 insertions(+), 38 deletions(-)
[PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP
Hi Arnd,
Sorry for late.
2015ë
11ì 18ì¼ 00:08ì Arnd Bergmann ì´(ê°) ì´ ê¸:
> The runtime PM operations use the suspend/resume functions
> even when CONFIG_PM_SLEEP is not set, but this now fails
> for the exynos DRM driver:
>
> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in
> a function)
> SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>
> This removes the #ifdef and instead marks the functions as
> __maybe_unused, which does the right thing in all cases and
> also looks nicer.
>
> Signed-off-by: Arnd Bergmann
> Fixes: ("drm/exynos: add pm_runtime to Mixer")
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 7498c6e76a53..fcaf71df77c1 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
How about just changing it to CONFIG_PM for consistency of other kms drivers?
Actually, I had modified it to PM since original auther, Gustavo Padovan,
posted runtime pm support.
However, it seems missing this one.
Thanks,
Inki Dae
> -static int exynos_mixer_suspend(struct device *dev)
> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
> {
> struct mixer_context *ctx = dev_get_drvdata(dev);
> struct mixer_resources *res = >mixer_res;
> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
> return 0;
> }
>
> -static int exynos_mixer_resume(struct device *dev)
> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
> {
> struct mixer_context *ctx = dev_get_drvdata(dev);
> struct mixer_resources *res = >mixer_res;
> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>
> return 0;
> }
> -#endif
>
> static const struct dev_pm_ops exynos_mixer_pm_ops = {
> SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>
>
[PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP
2016ë
01ì 26ì¼ 08:40ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸:
> 2015-11-18 0:08 GMT+09:00 Arnd Bergmann :
>> The runtime PM operations use the suspend/resume functions
>> even when CONFIG_PM_SLEEP is not set, but this now fails
>> for the exynos DRM driver:
>>
>> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in
>> a function)
>> SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>>
>> This removes the #ifdef and instead marks the functions as
>> __maybe_unused, which does the right thing in all cases and
>> also looks nicer.
>>
>> Signed-off-by: Arnd Bergmann
>> Fixes: ("drm/exynos: add pm_runtime to Mixer")
>
> Dear Inki,
>
> Ping? On 4.5-rc1 this is still broken. Can you apply this for fixes
> for current rc-cycle?
Got it.
Thanks,
Inki Dae
>
> Reviewed-by: Krzysztof Kozlowski
>
> Best regards,
> Krzysztof
>
>
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 7498c6e76a53..fcaf71df77c1 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> -#ifdef CONFIG_PM_SLEEP
>> -static int exynos_mixer_suspend(struct device *dev)
>> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
>> {
>> struct mixer_context *ctx = dev_get_drvdata(dev);
>> struct mixer_resources *res = >mixer_res;
>> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
>> return 0;
>> }
>>
>> -static int exynos_mixer_resume(struct device *dev)
>> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
>> {
>> struct mixer_context *ctx = dev_get_drvdata(dev);
>> struct mixer_resources *res = >mixer_res;
>> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>>
>> return 0;
>> }
>> -#endif
>>
>> static const struct dev_pm_ops exynos_mixer_pm_ops = {
>> SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>>
>> --
>> 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
> --
> 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 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV
2016ë 01ì 18ì¼ 19:12ì Andrzej Hajda ì´(ê°) ì´ ê¸: > Hi Inki, > > On 01/18/2016 10:54 AM, Inki Dae wrote: >> >> 2016ë 01ì 18ì¼ 08:45ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸: >>> On 14.01.2016 19:49, Inki Dae wrote: >>>> + Rob Herring >>>> >>>> 2016ë 01ì 14ì¼ 19:36ì Andrzej Hajda ì´(ê°) ì´ ê¸: >>>>> Hi Inki, >>>>> >>>>> It seems this patch and 04/10 did not get picked up yet. >>>>> Could you merge it? >>>> Yes, I can. However, 04/10 is required for acked-by from dt or SoC >>>> maintainer. >>>> Krzysztof and Rob, could you give me acked-by? >>>> >>>> Thanks, >>>> Inki Dae >>> My ack is really not required, because this is a binding for a specific >>> driver from video subsystem. It does not fall into the arm/mach-exynos >>> nor the dts/*exynos*. >>> >>> Anyway I reviewed the patch on 28th of October and Rob acked it on 13th >>> of November. >> I meant 04/10 not 09/10 patch. :) > > There is document in kernel with clear explanation about the subject: > Documentation/devicetree/bindings/submitting-patches.txt. > See especially paragraph II.2 [1]. > > [1]: Documentation/devicetree/bindings/submitting-patches.txt#L50 Got it. The document says, "For driver (not subsystem) bindings: If you are comfortable with the binding, and it hasn't received an Acked-by from the devicetree maintainers after a few weeks, go ahead and take it." Thanks, Inki Dae > > Regards > Andrzej > >> >> Thanks, >> Inki Dae >> >>> Best regards, >>> Krzysztof >>> >>> >>>>> Regards >>>>> Andrzej >>>>> >>>>> On 10/26/2015 12:59 PM, Andrzej Hajda wrote: >>>>>> DECON-TV(Display and Enhancement Controller for TV) is a variation >>>>>> of DECON IP. Its main purpose is to produce video stream for HDMI IP. >>>>>> >>>>>> Signed-off-by: Andrzej Hajda >>>>>> --- >>>>>> Hi Krzysztof, >>>>>> >>>>>> I have decided to skip cleanup part as it would require more work, >>>>>> not related to this patchset. >>>>>> >>>>>> Regards >>>>>> Andrzej >>>>>> >>>>>> Documentation/devicetree/bindings/video/exynos5433-decon.txt | 3 ++- >>>>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git >>>>>> a/Documentation/devicetree/bindings/video/exynos5433-decon.txt >>>>>> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt >>>>>> index 3dff78b..c9fd7b3 100644 >>>>>> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt >>>>>> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt >>>>>> @@ -5,7 +5,8 @@ Exynos 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,exynos5433-decon"; >>>>>> +- compatible: value should be one of: >>>>>> +"samsung,exynos5433-decon", "samsung,exynos5433-decon-tv"; >>>>>> - reg: physical base address and length of the DECON registers set. >>>>>> - interrupts: should contain a list of all DECON IP block interrupts in >>>>>> the >>>>>>order: VSYNC, LCD_SYSTEM. The interrupt specifier format >>>>> -- >>>>> 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 >>>>> >>>>> >>> -- >>> 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 >>> >>> > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" 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 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV
2016ë 01ì 18ì¼ 08:45ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸: > On 14.01.2016 19:49, Inki Dae wrote: >> + Rob Herring >> >> 2016ë 01ì 14ì¼ 19:36ì Andrzej Hajda ì´(ê°) ì´ ê¸: >>> Hi Inki, >>> >>> It seems this patch and 04/10 did not get picked up yet. >>> Could you merge it? >> >> Yes, I can. However, 04/10 is required for acked-by from dt or SoC >> maintainer. >> Krzysztof and Rob, could you give me acked-by? >> >> Thanks, >> Inki Dae > > My ack is really not required, because this is a binding for a specific > driver from video subsystem. It does not fall into the arm/mach-exynos > nor the dts/*exynos*. > > Anyway I reviewed the patch on 28th of October and Rob acked it on 13th > of November. I meant 04/10 not 09/10 patch. :) Thanks, Inki Dae > > Best regards, > Krzysztof > > >>> >>> Regards >>> Andrzej >>> >>> On 10/26/2015 12:59 PM, Andrzej Hajda wrote: >>>> DECON-TV(Display and Enhancement Controller for TV) is a variation >>>> of DECON IP. Its main purpose is to produce video stream for HDMI IP. >>>> >>>> Signed-off-by: Andrzej Hajda >>>> --- >>>> Hi Krzysztof, >>>> >>>> I have decided to skip cleanup part as it would require more work, >>>> not related to this patchset. >>>> >>>> Regards >>>> Andrzej >>>> >>>> Documentation/devicetree/bindings/video/exynos5433-decon.txt | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt >>>> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt >>>> index 3dff78b..c9fd7b3 100644 >>>> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt >>>> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt >>>> @@ -5,7 +5,8 @@ Exynos 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,exynos5433-decon"; >>>> +- compatible: value should be one of: >>>> + "samsung,exynos5433-decon", "samsung,exynos5433-decon-tv"; >>>> - reg: physical base address and length of the DECON registers set. >>>> - interrupts: should contain a list of all DECON IP block interrupts in >>>> the >>>> order: VSYNC, LCD_SYSTEM. The interrupt specifier format >>> >>> -- >>> 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 >>> >>> >> > > -- > 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 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV
+ Rob Herring 2016ë 01ì 14ì¼ 19:36ì Andrzej Hajda ì´(ê°) ì´ ê¸: > Hi Inki, > > It seems this patch and 04/10 did not get picked up yet. > Could you merge it? Yes, I can. However, 04/10 is required for acked-by from dt or SoC maintainer. Krzysztof and Rob, could you give me acked-by? Thanks, Inki Dae > > Regards > Andrzej > > On 10/26/2015 12:59 PM, Andrzej Hajda wrote: >> DECON-TV(Display and Enhancement Controller for TV) is a variation >> of DECON IP. Its main purpose is to produce video stream for HDMI IP. >> >> Signed-off-by: Andrzej Hajda >> --- >> Hi Krzysztof, >> >> I have decided to skip cleanup part as it would require more work, >> not related to this patchset. >> >> Regards >> Andrzej >> >> Documentation/devicetree/bindings/video/exynos5433-decon.txt | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt >> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt >> index 3dff78b..c9fd7b3 100644 >> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt >> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt >> @@ -5,7 +5,8 @@ Exynos 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,exynos5433-decon"; >> +- compatible: value should be one of: >> +"samsung,exynos5433-decon", "samsung,exynos5433-decon-tv"; >> - reg: physical base address and length of the DECON registers set. >> - interrupts: should contain a list of all DECON IP block interrupts in the >>order: VSYNC, LCD_SYSTEM. The interrupt specifier format > > -- > 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 0/7] drm/exynos/hdmi: add Exynos5433 support
2016ë 01ì 14ì¼ 16:01ì Andrzej Hajda ì´(ê°) ì´ ê¸: > On 01/14/2016 07:25 AM, Inki Dae wrote: >> Hi Andrzej, >> >> This patch series incurred merge conflicts at severial patches so I had to >> merge them manually. >> It looks good to me but it seems to need more tests so I merged them to >> exynos-drm-next-todo. >> After that, I will move them to exynos-drm-next. Sorry for late reivew again. > > I guess it is because exynos-drm-next does not contains patch > 'dt-bindings: remove deprecated compatible string from exynos-hdmi'. > It is already in next, it entered via samsung-dt tree. > With this patch this patchset applies cleanly to exynos-drm-next. Including dt-bindings patch, other patches also incurred merge conflicts. I think your patch set are conflicted with the configurable plane support already merged. Thanks, Inki Dae > > Regards > Andrzej > >> >> Thanks, >> Inki Dae >> >> 2016ë 01ì 14ì¼ 13:54ì Inki Dae ì´(ê°) ì´ ê¸: >>> Hi Andrzej, >>> >>> Really sorry for missing this. >>> I will merge them soon. >>> >>> Thanks, >>> Inki Dae >>> >>> 2016ë 01ì 13ì¼ 23:01ì Andrzej Hajda ì´(ê°) ì´ ê¸: >>>> Hi Inki, >>>> >>>> Ping. >>>> >>>> Regards >>>> Andrzej >>>> >>>> On 11/02/2015 02:16 PM, Andrzej Hajda wrote: >>>>> Hi Inki, Krzysztof, >>>>> >>>>> This patchset adds support for Exynos 5433 HDMI. >>>>> There are also few preparation/cleanup patches. >>>>> All patches except one touch only exynos-drm. >>>>> Sixth patch adds binding properties for Exynos5433 HDMI, >>>>> Krzysztof could you look at it. >>>>> >>>>> The patchset is based on exynos-drm-next. >>>>> >>>>> Regards >>>>> Andrzej >>>>> >>>>> >>>>> Andrzej Hajda (7): >>>>> drm/exynos/hdmi: clock code re-factoring >>>>> drm/exynos/hdmi: constify global variables >>>>> drm/exynos/hdmi: use array specifier for HDMI-PHY configurations >>>>> drm/exynos/hdmi: code cleanup >>>>> drm/exynos/hdmi: stop programming registers with default values >>>>> dt-bindings: exynos_hdmi: add bindings for Exynos5433 variant >>>>> drm/exynos/hdmi: add Exynos5433 support >>>>> >>>>> .../devicetree/bindings/video/exynos_hdmi.txt | 27 +- >>>>> drivers/gpu/drm/exynos/exynos_hdmi.c | 454 >>>>> +++-- >>>>> drivers/gpu/drm/exynos/regs-hdmi.h | 9 +- >>>>> 3 files changed, 352 insertions(+), 138 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 >>>> >>>> >>> -- >>> 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 >>> >>> > > -- > 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 0/7] drm/exynos/hdmi: add Exynos5433 support
Hi Andrzej, This patch series incurred merge conflicts at severial patches so I had to merge them manually. It looks good to me but it seems to need more tests so I merged them to exynos-drm-next-todo. After that, I will move them to exynos-drm-next. Sorry for late reivew again. Thanks, Inki Dae 2016ë 01ì 14ì¼ 13:54ì Inki Dae ì´(ê°) ì´ ê¸: > Hi Andrzej, > > Really sorry for missing this. > I will merge them soon. > > Thanks, > Inki Dae > > 2016ë 01ì 13ì¼ 23:01ì Andrzej Hajda ì´(ê°) ì´ ê¸: >> Hi Inki, >> >> Ping. >> >> Regards >> Andrzej >> >> On 11/02/2015 02:16 PM, Andrzej Hajda wrote: >>> Hi Inki, Krzysztof, >>> >>> This patchset adds support for Exynos 5433 HDMI. >>> There are also few preparation/cleanup patches. >>> All patches except one touch only exynos-drm. >>> Sixth patch adds binding properties for Exynos5433 HDMI, >>> Krzysztof could you look at it. >>> >>> The patchset is based on exynos-drm-next. >>> >>> Regards >>> Andrzej >>> >>> >>> Andrzej Hajda (7): >>> drm/exynos/hdmi: clock code re-factoring >>> drm/exynos/hdmi: constify global variables >>> drm/exynos/hdmi: use array specifier for HDMI-PHY configurations >>> drm/exynos/hdmi: code cleanup >>> drm/exynos/hdmi: stop programming registers with default values >>> dt-bindings: exynos_hdmi: add bindings for Exynos5433 variant >>> drm/exynos/hdmi: add Exynos5433 support >>> >>> .../devicetree/bindings/video/exynos_hdmi.txt | 27 +- >>> drivers/gpu/drm/exynos/exynos_hdmi.c | 454 >>> +++-- >>> drivers/gpu/drm/exynos/regs-hdmi.h | 9 +- >>> 3 files changed, 352 insertions(+), 138 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 >> >> > -- > 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/7] drm/exynos/hdmi: clock code re-factoring
TR_ERR(hdata->hdmi);
> - goto fail;
> - }
> - hdata->sclk_hdmi = devm_clk_get(dev, "sclk_hdmi");
> - if (IS_ERR(hdata->sclk_hdmi)) {
> - DRM_ERROR("failed to get clock 'sclk_hdmi'\n");
> - ret = PTR_ERR(hdata->sclk_hdmi);
> - goto fail;
> - }
> - hdata->sclk_pixel = devm_clk_get(dev, "sclk_pixel");
> - if (IS_ERR(hdata->sclk_pixel)) {
> - DRM_ERROR("failed to get clock 'sclk_pixel'\n");
> - ret = PTR_ERR(hdata->sclk_pixel);
> - goto fail;
> - }
> - hdata->sclk_hdmiphy = devm_clk_get(dev, "sclk_hdmiphy");
> - if (IS_ERR(hdata->sclk_hdmiphy)) {
> - DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
> - ret = PTR_ERR(hdata->sclk_hdmiphy);
> - goto fail;
> - }
> - hdata->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
> - if (IS_ERR(hdata->mout_hdmi)) {
> - DRM_ERROR("failed to get clock 'mout_hdmi'\n");
> - ret = PTR_ERR(hdata->mout_hdmi);
> - goto fail;
> + return hdata->irq;
> }
>
> - clk_set_parent(hdata->mout_hdmi, hdata->sclk_pixel);
> + ret = hdmi_clk_init(hdata);
> + if (ret)
> + return ret;
> +
> + hdmi_clk_set_parents(hdata, false);
You should check return type but I can fix it.
Thanks,
Inki Dae
>
> for (i = 0; i < ARRAY_SIZE(supply); ++i) {
> hdata->regul_bulk[i].supply = supply[i];
> @@ -1753,9 +1846,6 @@ static int hdmi_resources_init(struct hdmi_context
> *hdata)
> DRM_ERROR("failed to enable hdmi-en regulator\n");
>
> return ret;
> -fail:
> - DRM_ERROR("HDMI resource init - failed\n");
> - return ret;
> }
>
> static struct of_device_id hdmi_match_types[] = {
>
[PATCH 0/7] drm/exynos/hdmi: add Exynos5433 support
Hi Andrzej, Really sorry for missing this. I will merge them soon. Thanks, Inki Dae 2016ë 01ì 13ì¼ 23:01ì Andrzej Hajda ì´(ê°) ì´ ê¸: > Hi Inki, > > Ping. > > Regards > Andrzej > > On 11/02/2015 02:16 PM, Andrzej Hajda wrote: >> Hi Inki, Krzysztof, >> >> This patchset adds support for Exynos 5433 HDMI. >> There are also few preparation/cleanup patches. >> All patches except one touch only exynos-drm. >> Sixth patch adds binding properties for Exynos5433 HDMI, >> Krzysztof could you look at it. >> >> The patchset is based on exynos-drm-next. >> >> Regards >> Andrzej >> >> >> Andrzej Hajda (7): >> drm/exynos/hdmi: clock code re-factoring >> drm/exynos/hdmi: constify global variables >> drm/exynos/hdmi: use array specifier for HDMI-PHY configurations >> drm/exynos/hdmi: code cleanup >> drm/exynos/hdmi: stop programming registers with default values >> dt-bindings: exynos_hdmi: add bindings for Exynos5433 variant >> drm/exynos/hdmi: add Exynos5433 support >> >> .../devicetree/bindings/video/exynos_hdmi.txt | 27 +- >> drivers/gpu/drm/exynos/exynos_hdmi.c | 454 >> +++-- >> drivers/gpu/drm/exynos/regs-hdmi.h | 9 +- >> 3 files changed, 352 insertions(+), 138 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 > >
[PATCH v3] drm/exynos: fix kernel panic issue at drm releasing
Hi Daniel, 2016ë 01ì 12ì¼ 04:00ì Daniel Stone ì´(ê°) ì´ ê¸: > Hi Inki, > > On 8 January 2016 at 08:46, Inki Dae wrote: >> Changelog v3: >> - initialize only device specific things. Each page flip event object >> is created by DRM core so DRM core should release the object including >> incrementing event space. > > I'm a bit confused here; we no longer call event->base.destroy(), > because you say that the DRM core should release it. But how does the > DRM core know to release the event? From the core point of view, the > event disappears into the driver, and it is no longer tracked. DRM core would need something to track the events. I think basically, someone who created one object should also destroy the object. > > As Daniel says though, later versions handle all this in the core in a > much more clean way, so we can remove these from the drivers then. So I think it's not reasonable for specific driver to destroy the object created by core although there is a memory leak. However, the memory leak would be more critical than temporary codes. Ok, I will merge this patch with more comments which will say the object will be destroyed by core part later. Thanks, Inki Dae > > Cheers, > Daniel > >
[PATCH 13/22] drm/exynos: Remove event cancelling from postclose
Hi Daniel,
It seems your patch is exactly same as below my one I posted before,
http://www.spinics.net/lists/dri-devel/msg97922.html
Anyway, it's ok if this patch can go to mainline.
Acked-by: Inki Dae
2016ë
01ì 12ì¼ 06:41ì Daniel Vetter ì´(ê°) ì´ ê¸:
> The core takes care of this now. And since kfree(NULL) is ok we can
> simplify the function even further now.
>
> Cc: Inki Dae
> Acked-by: Daniel Stone
> Reviewed-by: Alex Deucher
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 9756797a15a5..868ab9f54f17 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -335,20 +335,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
>
> static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
> *file)
> {
> - struct drm_pending_event *e, *et;
> - unsigned long flags;
> -
> - if (!file->driver_priv)
> - return;
> -
> - spin_lock_irqsave(>event_lock, flags);
> - /* Release all events handled by page flip handler but not freed. */
> - list_for_each_entry_safe(e, et, >event_list, link) {
> - list_del(>link);
> - e->destroy(e);
> - }
> - spin_unlock_irqrestore(>event_lock, flags);
> -
> kfree(file->driver_priv);
> file->driver_priv = NULL;
> }
>
[PATCH 0/4] drm/exynos: introduce generic zpos property
Hi Marek,
2016ë
01ì 05ì¼ 21:52ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Hello all,
>
> This patch series is a continuation of rework of blending support in
> Exynos DRM driver. Some background can be found here:
> http://www.spinics.net/lists/dri-devel/msg96969.html
>
> Daniel Vetter suggested that zpos property should be made generic, with
> well-defined semantics. This patchset is my proposal for such generic
> zpos property:
> - added zpos properties to drm core and plane state structures,
> - added helpers for normalizing zpos properties of given set of planes,
> - well defined semantics: planes are sorted by zpos values and then plane
> id value if zpos equals.
>
> Patches 2/4 and 3/4 are fixes for Exynos DRM driver, which are required
Picked them up. Especially, 2/4 is a good patch.
Thanks,
Inki Dae
> to properly implement generic zpos handling. However they can be also
> merged regardless of the rest of the patches (if there is a need for
> further discussion on the generic zpos property feature).
>
> Patches are based on top of latest exynos-drm-next branch.
>
> Best regards
> Marek Szyprowski
> Samsung R Institute Poland
>
>
> Patch summary:
>
> Marek Szyprowski (4):
> drm: add generic zpos property
> drm/exynos: crtc: rework atomic_{begin,flush}
> drm/exynos: mixer: properly update all planes on the same vblank event
> drm/exynos: use generic code for managing zpos plane property
>
> Documentation/DocBook/gpu.tmpl| 14 +-
> drivers/gpu/drm/drm_atomic.c | 4 ++
> drivers/gpu/drm/drm_atomic_helper.c | 52
> drivers/gpu/drm/drm_crtc.c| 13 +
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 14 +++---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 14 +++---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 20 ++--
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 11 ++---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 68
> +++
> drivers/gpu/drm/exynos/exynos_mixer.c | 53 -
> include/drm/drm_atomic_helper.h | 2 +
> include/drm/drm_crtc.h| 13 +
> 13 files changed, 187 insertions(+), 105 deletions(-)
>
[PATCH v3] drm/exynos: fix kernel panic issue at drm releasing
This patch fixes a kernel panic issue which happened
when drm driver is closed while modetest.
This issue could be reproduced easily by launching modetest
with page flip repeatedly.
The reason is that invalid drm_file object could be accessed by
send_vblank_event function when finishing page flip if the drm_file
object was removed by drm_release and there was a pended page
flip event which was already committed to hardware.
So this patch makes the pended page flip event to be cancelled by
preclose callback which is called at front of drm_release function.
Changelog v2:
- free vblank event objects belonging to the request process,
increment event space and decrease pending_update when cancelling
the event
Changelog v3:
- initialize only device specific things. Each page flip event object
is created by DRM core so DRM core should release the object including
incrementing event space.
Signed-off-by: Inki Dae
Reviewed-by: Daniel Stone
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 +++
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 3 +++
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index cd94981..8b503a0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -226,3 +226,18 @@ void exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
if (exynos_crtc->ops->te_handler)
exynos_crtc->ops->te_handler(exynos_crtc);
}
+
+void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct drm_pending_vblank_event *e;
+ unsigned long flags;
+
+ spin_lock_irqsave(>dev->event_lock, flags);
+ e = exynos_crtc->event;
+ if (e) {
+ exynos_crtc->event = NULL;
+ atomic_dec(_crtc->pending_update);
+ }
+ spin_unlock_irqrestore(>dev->event_lock, flags);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 6a581a8..b4def6e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -40,4 +40,7 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device
*drm_dev,
*/
void exynos_drm_crtc_te_handler(struct drm_crtc *crtc);
+/* This function cancels a page flip request. */
+void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc);
+
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 9756797a..57c0e7d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -330,7 +330,12 @@ err_file_priv_free:
static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
{
+ struct drm_crtc *crtc;
+
exynos_drm_subdrv_close(dev, file);
+
+ list_for_each_entry(crtc, >mode_config.crtc_list, head)
+ exynos_drm_crtc_cancel_page_flip(crtc);
}
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
--
1.9.1
[PATCH] drm/exynos: do not free pended event at postclose callback
These events will be freed by drm_events_release of DRM core so
it doesn't need to free these events in SoC specific driver.
This patch removes relevant codes from Exynos DRM driver.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 57c0e7d..59041d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -340,20 +340,9 @@ static void exynos_drm_preclose(struct drm_device *dev,
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
{
- struct drm_pending_event *e, *et;
- unsigned long flags;
-
if (!file->driver_priv)
return;
- spin_lock_irqsave(>event_lock, flags);
- /* Release all events handled by page flip handler but not freed. */
- list_for_each_entry_safe(e, et, >event_list, link) {
- list_del(>link);
- e->destroy(e);
- }
- spin_unlock_irqrestore(>event_lock, flags);
-
kfree(file->driver_priv);
file->driver_priv = NULL;
}
--
1.9.1
[PATCH] drm/exynos: fix kernel panic issue at drm releasing
+ Rob Clark,
Hi Daniel and Rob,
2016ë
01ì 05ì¼ 20:08ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Tue, Jan 05, 2016 at 07:55:52PM +0900, Inki Dae wrote:
>> Hi Daniel,
>>
>> 2016ë
01ì 05ì¼ 05:24ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> Hi Inki,
>>>
>>> On 4 January 2016 at 12:57, Inki Dae wrote:
>>>> 2015ë
12ì 24ì¼ 22:32ì Daniel Stone ì´(ê°) ì´ ê¸:
>>>>> On 24 December 2015 at 09:10, Inki Dae wrote:
>>>>>> +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
>>>>>> +{
>>>>>> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>>>>> + unsigned long flags;
>>>>>> +
>>>>>> + spin_lock_irqsave(>dev->event_lock, flags);
>>>>>> + exynos_crtc->event = NULL;
>>>>>> + spin_unlock_irqrestore(>dev->event_lock, flags);
>>>>>> +}
>>>>>
>>>>> This will leak the event and event space; you should call
>>>>> event->base.destroy() here. With that fixed:
>>>>
>>>> Right. we don't use exynos specific page flip function anymore which
>>>> managed the event as a list so that the event objects can be freed by
>>>> postclose callback.
>>>> Anyway, would it be better for event->base.destory() to be called between
>>>> spin lock/unlock?
>>>
>>> You must increment event->base.file_priv->event_space (see
>>> drm_atomic.c:destroy_vblank_event), as well as calling
>>
>> Reasonable to me. Seems other DRM drivers don't increment event_space.
>>
>>> event->base.destroy (see drm_fops.c:drm_read) underneath event_lock,
>>> yes.
>>
>> In addition, only event objects belonging to the request process should be
>> destroyed.
>
> Just random comment out of the far left field, but robclark had a bunch of
> patches to clean up all that event alloc/cleanup code a bit and extract it
> into core functions. Might be good to ping him on irc to figure out where
> that series is and whether you could take it over.
Good news. I'll try to ping him on irc.
To Rob,
Can you let me know where your bunch of patches are? I'd like to look into the
patches. I'd planned to have pull request so that this patch can go to 4.4.
As you had already relevant patch set maybe, we would need to check whether my
patch can be replaced with your patch set or there is any corner case.
Thanks,
Inki Dae
>
> Cheers, Daniel
>
[PATCH] drm/exynos: fix kernel panic issue at drm releasing
Hi Daniel,
2016ë
01ì 05ì¼ 05:24ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 4 January 2016 at 12:57, Inki Dae wrote:
>> 2015ë
12ì 24ì¼ 22:32ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> On 24 December 2015 at 09:10, Inki Dae wrote:
>>>> +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
>>>> +{
>>>> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>>> + unsigned long flags;
>>>> +
>>>> + spin_lock_irqsave(>dev->event_lock, flags);
>>>> + exynos_crtc->event = NULL;
>>>> + spin_unlock_irqrestore(>dev->event_lock, flags);
>>>> +}
>>>
>>> This will leak the event and event space; you should call
>>> event->base.destroy() here. With that fixed:
>>
>> Right. we don't use exynos specific page flip function anymore which managed
>> the event as a list so that the event objects can be freed by postclose
>> callback.
>> Anyway, would it be better for event->base.destory() to be called between
>> spin lock/unlock?
>
> You must increment event->base.file_priv->event_space (see
> drm_atomic.c:destroy_vblank_event), as well as calling
Reasonable to me. Seems other DRM drivers don't increment event_space.
> event->base.destroy (see drm_fops.c:drm_read) underneath event_lock,
> yes.
In addition, only event objects belonging to the request process should be
destroyed.
Thanks,
Inki Dae
>
> Cheers,
> Daniel
> --
> 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] drm/exynos: fix kernel panic issue at drm releasing
This patch fixes a kernel panic issue which happened
when drm driver is closed while modetest.
This issue could be reproduced easily by launching modetest
with page flip repeatedly.
The reason is that invalid drm_file object could be accessed by
send_vblank_event function when finishing page flip if the drm_file
object was removed by drm_release and there was a pended page
flip event which was already committed to hardware.
So this patch makes the pended page flip event to be cancelled by
preclose callback which is called at front of drm_release function.
Changelog v2:
- free vblank event objects belonging to the request process,
increment event space and decrease pending_update when cancelling
the event
Signed-off-by: Inki Dae
Reviewed-by: Daniel Stone
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 18 ++
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 4
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 +
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index f3589a3..a3c2c71 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -238,3 +238,21 @@ void exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
if (exynos_crtc->ops->te_handler)
exynos_crtc->ops->te_handler(exynos_crtc);
}
+
+void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc,
+ struct drm_file *file)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct drm_pending_vblank_event *e;
+ unsigned long flags;
+
+ spin_lock_irqsave(>dev->event_lock, flags);
+ e = exynos_crtc->event;
+ if (e && e->base.file_priv == file) {
+ exynos_crtc->event = NULL;
+ e->base.destroy(>base);
+ file->event_space += sizeof(e->event);
+ atomic_dec(_crtc->pending_update);
+ }
+ spin_unlock_irqrestore(>dev->event_lock, flags);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 6a581a8..cfdcf3e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -40,4 +40,8 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device
*drm_dev,
*/
void exynos_drm_crtc_te_handler(struct drm_crtc *crtc);
+/* This function cancels a page flip request. */
+void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc,
+ struct drm_file *file);
+
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2c6019d..b9a9fd6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -369,7 +369,12 @@ err_file_priv_free:
static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
{
+ struct drm_crtc *crtc;
+
exynos_drm_subdrv_close(dev, file);
+
+ list_for_each_entry(crtc, >mode_config.crtc_list, head)
+ exynos_drm_crtc_cancel_page_flip(crtc, file);
}
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
--
1.9.1
[PATCH v3 1/7] drm/exynos: rename zpos to index
Hi Marek, 2015ë 12ì 28ì¼ 21:34ì Marek Szyprowski ì´(ê°) ì´ ê¸: > Hello, > > On 2015-12-24 09:15, Inki Dae wrote: >> Seems this patch could be more cleaned up. >> >> Each ctx object of each crtc driver has its own plane config object which >> includes already zpos value. >> So I think we wouldn't need to keep zpos of the plane config and index of >> the plane object. >> How about removing index from exynos plane structure and using zpos of >> exynos plane config structure instead? >> >> Below patch can be applied on top of your patch, > > If you want I can move 'index' entry to config object, but the initial zpos > value > should also be there. Please note that index is not always equal to the > initial zpos > and having initial zpos configurable is also needed. There were already > concerns if > mixer's dedicated video plane should be below or above the primary gfx plane > in the > default configuration. Merged all patches. Thanks, Inki Dae > >> (...) > > Best regards
[PATCH] drm/exynos: fix kernel panic issue at drm releasing
Hi Daniel,
2015ë
12ì 24ì¼ 22:32ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 24 December 2015 at 09:10, Inki Dae wrote:
>> +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
>> +{
>> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(>dev->event_lock, flags);
>> + exynos_crtc->event = NULL;
>> + spin_unlock_irqrestore(>dev->event_lock, flags);
>> +}
>
> This will leak the event and event space; you should call
> event->base.destroy() here. With that fixed:
Right. we don't use exynos specific page flip function anymore which managed
the event as a list so that the event objects can be freed by postclose
callback.
Anyway, would it be better for event->base.destory() to be called between spin
lock/unlock?
Thanks,
Inki Dae
> Reviewed-by: Daniel Stone
>
> Cheers,
> Daniel
> --
> 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: fix kernel panic issue at drm releasing
This patch fixes a kernel panic issue which happened
when drm driver is closed while modetest.
This issue could be reproduced easily by launching modetest
with page flip repeatedly.
The reason is that invalid drm_file object could be accessed by
send_vblank_event function when finishing page flip if the drm_file
object was removed by drm_release and there was a pended page
flip event which was already committed to hardware.
So this patch makes the pended page flip event to be cancelled by
preclose callback which is called at front of drm_release function.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 10 ++
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 3 +++
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 +
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 81cfff5..57619b8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -235,3 +235,13 @@ void exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
if (exynos_crtc->ops->te_handler)
exynos_crtc->ops->te_handler(exynos_crtc);
}
+
+void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ unsigned long flags;
+
+ spin_lock_irqsave(>dev->event_lock, flags);
+ exynos_crtc->event = NULL;
+ spin_unlock_irqrestore(>dev->event_lock, flags);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 6a581a8..b4def6e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -40,4 +40,7 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device
*drm_dev,
*/
void exynos_drm_crtc_te_handler(struct drm_crtc *crtc);
+/* This function cancels a page flip request. */
+void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc);
+
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 9756797a..57c0e7d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -330,7 +330,12 @@ err_file_priv_free:
static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
{
+ struct drm_crtc *crtc;
+
exynos_drm_subdrv_close(dev, file);
+
+ list_for_each_entry(crtc, >mode_config.crtc_list, head)
+ exynos_drm_crtc_cancel_page_flip(crtc);
}
static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
--
1.9.1
[PATCH] drm/exynos: crtc: do not wait for the scanout completion
This patch removes exynos_drm_crtc_complete_scanout function call
which makes sure for overlay data to be updated to real hardware
when drm driver is released.
With atomic modeset support, it doesn't need the function anymore
because atomic modeset interface makes sure that.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 23 ---
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_fb.c | 3 ---
3 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 9d30a0f..81cfff5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -212,29 +212,6 @@ void exynos_drm_crtc_finish_update(struct exynos_drm_crtc
*exynos_crtc,
spin_unlock_irqrestore(>dev->event_lock, flags);
}
-void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb)
-{
- struct exynos_drm_crtc *exynos_crtc;
- struct drm_device *dev = fb->dev;
- struct drm_crtc *crtc;
-
- /*
-* make sure that overlay data are updated to real hardware
-* for all encoders.
-*/
- list_for_each_entry(crtc, >mode_config.crtc_list, head) {
- exynos_crtc = to_exynos_crtc(crtc);
-
- /*
-* wait for vblank interrupt
-* - this makes sure that overlay data are updated to
-* real hardware.
-*/
- if (exynos_crtc->ops->wait_for_vblank)
- exynos_crtc->ops->wait_for_vblank(exynos_crtc);
- }
-}
-
int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
enum exynos_drm_output_type out_type)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index f9f365b..6a581a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -28,7 +28,6 @@ void exynos_drm_crtc_disable_vblank(struct drm_device *dev,
unsigned int pipe);
void exynos_drm_crtc_wait_pending_update(struct exynos_drm_crtc *exynos_crtc);
void exynos_drm_crtc_finish_update(struct exynos_drm_crtc *exynos_crtc,
struct exynos_drm_plane *exynos_plane);
-void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb);
/* This function gets pipe value to crtc device matched with out_type. */
int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index f6bdb0d..db77d83 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -71,9 +71,6 @@ static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
unsigned int i;
- /* make sure that overlay data are updated before relesing fb. */
- exynos_drm_crtc_complete_scanout(fb);
-
drm_framebuffer_cleanup(fb);
for (i = 0; i < ARRAY_SIZE(exynos_fb->exynos_gem); i++) {
--
1.9.1
[PATCH v3 1/7] drm/exynos: rename zpos to index
Below just trivial issue,
2015ë
12ì 16ì¼ 21:21ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch renames zpos entry to index, because in most places it is
> used as index for selecting hardware layer/window instead of
> configurable layer position. This will later enable to make the zpos
> property configurable.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 14 +++---
> 8 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index c7362b99ce28..88d022ad5280 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -256,7 +256,7 @@ static void decon_atomic_begin(struct exynos_drm_crtc
> *crtc,
> if (test_bit(BIT_SUSPENDED, >flags))
> return;
>
> - decon_shadow_protect_win(ctx, plane->zpos, true);
> + decon_shadow_protect_win(ctx, plane->index, true);
> }
>
> #define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
> @@ -270,7 +270,7 @@ static void decon_update_plane(struct exynos_drm_crtc
> *crtc,
> to_exynos_plane_state(plane->base.state);
> struct decon_context *ctx = crtc->ctx;
> struct drm_framebuffer *fb = state->base.fb;
> - unsigned int win = plane->zpos;
> + unsigned int win = plane->index;
> unsigned int bpp = fb->bits_per_pixel >> 3;
> unsigned int pitch = fb->pitches[0];
> dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
> @@ -320,7 +320,7 @@ static void decon_disable_plane(struct exynos_drm_crtc
> *crtc,
> struct exynos_drm_plane *plane)
> {
> struct decon_context *ctx = crtc->ctx;
> - unsigned int win = plane->zpos;
> + unsigned int win = plane->index;
>
> if (test_bit(BIT_SUSPENDED, >flags))
> return;
> @@ -344,7 +344,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc
> *crtc,
> if (test_bit(BIT_SUSPENDED, >flags))
> return;
>
> - decon_shadow_protect_win(ctx, plane->zpos, false);
> + decon_shadow_protect_win(ctx, plane->index, false);
>
> if (ctx->out_type == IFTYPE_I80)
> set_bit(BIT_WIN_UPDATED, >flags);
> @@ -502,7 +502,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> ctx->configs[win].zpos = win;
> ctx->configs[win].type = decon_win_types[tmp];
>
> - ret = exynos_plane_init(drm_dev, >planes[win],
> + ret = exynos_plane_init(drm_dev, >planes[win], i,
'i' isn't declared so you have to use win instead.
Please, post the patch set at least after build test.
Thanks,
Inki Dae
[PATCH v3 1/7] drm/exynos: rename zpos to index
it(MXR_BIT_POWERED, _ctx->flags))
return;
@@ -1011,7 +1011,7 @@ static void mixer_disable_plane(struct exynos_drm_crtc
*crtc,
spin_lock_irqsave(>reg_slock, flags);
mixer_vsync_set_update(mixer_ctx, false);
- mixer_cfg_layer(mixer_ctx, plane->index, 0, false);
+ mixer_cfg_layer(mixer_ctx, plane->config->index, 0, false);
mixer_vsync_set_update(mixer_ctx, true);
spin_unlock_irqrestore(>reg_slock, flags);
@@ -1189,7 +1189,7 @@ static int mixer_bind(struct device *dev, struct device
*manager, void *data)
if (i == VP_DEFAULT_WIN && !ctx->vp_enabled)
continue;
- ret = exynos_plane_init(drm_dev, >planes[i], i,
+ ret = exynos_plane_init(drm_dev, >planes[i],
1 << ctx->pipe, _configs[i]);
if (ret)
return ret;
Thanks,
Inki Dae
2015ë
12ì 16ì¼ 21:21ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch renames zpos entry to index, because in most places it is
> used as index for selecting hardware layer/window instead of
> configurable layer position. This will later enable to make the zpos
> property configurable.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 +-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 14 +++---
> 8 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index c7362b99ce28..88d022ad5280 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -256,7 +256,7 @@ static void decon_atomic_begin(struct exynos_drm_crtc
> *crtc,
> if (test_bit(BIT_SUSPENDED, >flags))
> return;
>
> - decon_shadow_protect_win(ctx, plane->zpos, true);
> + decon_shadow_protect_win(ctx, plane->index, true);
> }
>
> #define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
> @@ -270,7 +270,7 @@ static void decon_update_plane(struct exynos_drm_crtc
> *crtc,
> to_exynos_plane_state(plane->base.state);
> struct decon_context *ctx = crtc->ctx;
> struct drm_framebuffer *fb = state->base.fb;
> - unsigned int win = plane->zpos;
> + unsigned int win = plane->index;
> unsigned int bpp = fb->bits_per_pixel >> 3;
> unsigned int pitch = fb->pitches[0];
> dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
> @@ -320,7 +320,7 @@ static void decon_disable_plane(struct exynos_drm_crtc
> *crtc,
> struct exynos_drm_plane *plane)
> {
> struct decon_context *ctx = crtc->ctx;
> - unsigned int win = plane->zpos;
> + unsigned int win = plane->index;
>
> if (test_bit(BIT_SUSPENDED, >flags))
> return;
> @@ -344,7 +344,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc
> *crtc,
> if (test_bit(BIT_SUSPENDED, >flags))
> return;
>
> - decon_shadow_protect_win(ctx, plane->zpos, false);
> + decon_shadow_protect_win(ctx, plane->index, false);
>
> if (ctx->out_type == IFTYPE_I80)
> set_bit(BIT_WIN_UPDATED, >flags);
> @@ -502,7 +502,7 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> ctx->configs[win].zpos = win;
> ctx->configs[win].type = decon_win_types[tmp];
>
> - ret = exynos_plane_init(drm_dev, >planes[win],
> + ret = exynos_plane_init(drm_dev, >planes[win], i,
> 1 << ctx->pipe, >configs[win]);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index c47f9af8170b..8911f965b06c 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -393,7 +393,7 @@ static void decon_atomic_begin(struct exynos_drm_crtc
> *crtc,
> if (ctx->suspended)
> return;
>
> - decon_shadow_protect_win(ctx, plane-&g
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Marek,
2015ë
12ì 14ì¼ 18:15ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 2015-12-11 15:52, Inki Dae wrote:
>> 2015-12-11 20:27 GMT+09:00 Marek Szyprowski :
>>> On 2015-12-11 10:57, Inki Dae wrote:
>>>> 2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>>>> On 2015-12-11 10:02, Inki Dae wrote:
>>>>>> I found out why NULL point access happened. That was incurred by below
>>>>>> your patch,
>>>>>> [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos
>>>>>> fb
>>>>>>
>>>>>> When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
>>>>>> the drm frambuffer object of fb_helper is set to the plane state of the
>>>>>> new crtc driver
>>>>>> so the driver should get the drm framebuffer object from the plane's
>>>>>> state or
>>>>>> exynos_plane->pending_fb which is set by exynos_plane_atomic_update
>>>>>> function.
>>>>>>
>>>>>> After that, I think the drm framebuffer should be set to drm plane as a
>>>>>> current fb
>>>>>> which would be scanned out.
>>>>>>
>>>>>> Anyway, I can fix it like below if you are ok.
>>>>>>
>>>>>> Thanks,
>>>>>> Inki Dae
>>>>>>
>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>>>> @@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc
>>>>>> *crtc,
>>>>>>if (ctx->suspended)
>>>>>>return;
>>>>>> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>>>>> + addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
>>>>>>DRM_DEBUG_KMS("dma_addr = %pad\n", );
>>>>>>
>>>>>> +plane->base.fb = plane->pending_fb;
>>>>> plane->base.fb should not be modified. I think that the following fix is
>>>>> more
>>>> Could you explain why plane->base.fb shouldn't be modified?
>>>
>>> All 'base' classes are modified by DRM core and there should be no need
>>> to modify them from the drivers.
>> Ok, If so - drm core updates plane->fb - then it's reasonable. But I
>> couldn't find the exact location where plane->fb is set to a fb to be
>> scanned out.
>> So could you let me know the exact location? it's not clear to me yet.
>
> Setting plane->fb is wired somewhere in the atomic update logic, see
> __setplane_internal() function in drivers/gpu/drm/drm_crtc.c. Some more
> comments
This function wouldn't be related to what we are talking about. But...
> are also in the drm_atomic_clean_old_fb() function in
> drivers/gpu/drm/drm_atomic.c
Right. Seems that this function is called after exynos_plane_atomic_update
function
call by atomic_update callback. So drm core updates plane->fb appropriately.
Thanks,
Inki Dae.
> However I don't know the exact call path.
>
>>> I've checked this issue and the proper fix for is the following code:
>>>
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> @@ -131,13 +131,14 @@ static void vidi_disable_vblank(struct exynos_drm_crtc
>>> *crtc)
>>> static void vidi_update_plane(struct exynos_drm_crtc *crtc,
>>>struct exynos_drm_plane *plane)
>>> {
>>> + struct drm_plane_state *state = plane->base.state;
>>> struct vidi_context *ctx = crtc->ctx;
>>> dma_addr_t addr;
>>>
>>> if (ctx->suspended)
>>> return;
>>>
>>> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>> + addr = exynos_drm_fb_dma_addr(state->fb, 0);
>>> DRM_DEBUG_KMS("dma_addr = %pad\n", );
>>>
>>> if (ctx->vblank_on)
>>>
>>>
>>> plane->base.fb is updated from the core once all crtc/plane atomic update
>>> calls finishes. The drivers should use the fb stored in plane->base.state.
>>> I've missed that VIDI driver doesn't get the fb and incorrectly used
>>> plane->base.fb instad of state->fb while updating the code.
>>>
>> Actually, I used state->
[GIT PULL] exynos-drm-next
Hi Dave, This pull request includes runtime pm support, of_graph based dt binding support for DP(Display Port) panel and cleanups for Exynos DRM IPP enhancement. Summary: - Support runtime pm . In case of most ARM SoC, each IP has each power domain which should be controlled by each IP driver using runtime pm interface. So this patch series makes each IP driver to control its own power domain when drm dpms is requested. - Support of_graph based dt binding for DP panel. . This patch series adds of_graph based dt binding for DP panel. And also it keeps backward compatibility. This includes dt binding patch so I got Acked-by from Krzysztof Kozlowski who is a Exynos SoC maintainer and from Rob Herring who is a device tree maintainer. - Cleanup for Exynos DRM IPP enhancement. . This patch series is a first step for enhancing existing IPP framework which will integrate existing IPP functions with DRM KMS part so that these can be transparent to userspace. For other portion of the patch series, we will have more times for the review. Plese, kindly let know if there is any problem. Thanks, Inki Dae The following changes since commit 663a233eef643b38f36c05535cb5c9a4972edcc1: Merge branch 'drm-header-fixes' of https://github.com/GabrielL/linux into drm-next (2015-12-11 13:46:05 +1000) are available in the git repository at: gitolite.kernel.org:/pub/scm/linux/kernel/git/daeinki/drm-exynos.git exynos-drm-next for you to fetch changes up to 9bac40cf28c9318f0b3eb6c81ce35f32581ef7b4: drm/exynos: gem: remove old unused prototypes (2015-12-13 22:22:59 +0900) Andrzej Hajda (1): drm/exynos: simplify sleep PM ops Gustavo Padovan (7): drm/exynos: do not start enabling DP at bind() phase drm/exynos: add pm_runtime to DP drm/exynos: add pm_runtime to HDMI drm/exynos: add pm_runtime to Mixer drm/exynos: add pm_runtime to FIMD drm/exynos: add pm_runtime to DECON 5433 drm/exynos: add pm_runtime to DECON 7 Inki Dae (5): drm/exynos: dsi: add runtime pm support drm/exynos: dsi: modify a error type when getting a node failed drm/exynos: decon: remove unused variables drm/exynos: dp: add of_graph dt binding support for panel dt-bindings: exynos-dp: update ports node binding for panel Javier Martinez Canillas (1): ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi Marek Szyprowski (12): drm/exynos: rotator: convert to common clock framework drm/exynos: exynos7-decon: remove excessive check drm/exynos: move dma_addr attribute from exynos plane to exynos fb drm/exynos: introduce exynos_drm_plane_state structure drm/exynos: mixer: use crtc->state->adjusted_mode instead of crtc->mode drm/exynos: mixer: enable video overlay plane only when VP is available drm/exynos: introduce exynos_drm_plane_config structure drm/exynos: add generic check for plane state drm/exynos: mixer: use ratio precalculated in exynos_state drm/exynos: fix clipping when scaling is enabled drm/exynos: fimd: fix dma burst size setting for small plane size drm/exynos: gem: remove old unused prototypes Seung-Woo Kim (3): drm/exynos: gsc: prepare and unprepare gsc clock drm/exynos: gsc: fix wrong pm_runtime state drm/exynos: gsc: add device tree support and remove usage of static mappings .../bindings/display/exynos/exynos_dp.txt | 41 +++- .../devicetree/bindings/media/exynos5-gsc.txt | 4 + arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 +- drivers/gpu/drm/exynos/Kconfig | 2 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 104 ++--- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 161 +++--- drivers/gpu/drm/exynos/exynos_dp_core.c| 179 --- drivers/gpu/drm/exynos/exynos_dp_core.h| 1 + drivers/gpu/drm/exynos/exynos_drm_drv.c| 76 +++ drivers/gpu/drm/exynos/exynos_drm_drv.h| 81 --- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 151 +++-- drivers/gpu/drm/exynos/exynos_drm_fb.c | 16 +- drivers/gpu/drm/exynos/exynos_drm_fb.h | 3 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 142 +++- drivers/gpu/drm/exynos/exynos_drm_gem.h| 28 --- drivers/gpu/drm/exynos/exynos_drm_gsc.c| 35 ++- drivers/gpu/drm/exynos/exynos_drm_plane.c | 215 +++--- drivers/gpu/drm/exynos/exynos_drm_plane.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 31 ++- drivers/gpu/drm/exynos/exynos_hdmi.c | 49 - drivers/gpu/drm/exynos/exynos_mixer.c | 239 +++-- drivers/gpu/drm/ex
[PATCH] drm/exynos: atomic check only enabled crtc states
Hi Javier, 2015-12-09 19:51 GMT+09:00 Javier Martinez Canillas : > Hello Inki, > > On 11/27/2015 10:00 AM, Javier Martinez Canillas wrote: >> Hello Andrzej, >> >> On 11/27/2015 03:57 AM, Andrzej Hajda wrote: >>> Since atomic check is called also for disabled crtcs it should skip >>> mode checking as it can be uninitialized. The patch fixes it. >>> >>> Signed-off-by: Andrzej Hajda >>> Suggested-by: Daniel Vetter >>> --- >>> Hi Javier, >>> >>> Could you check with this patch. >>> >> >> The patch fixes the issue I reported. The display mode is correctly set >> with and without a HDMI monitor plugged. So on an Exynos5800 Peach Pi: >> >> Tested-by: Javier Martinez Canillas >> > > This patch was never picked but fixes and important > bug introduced in the v4.4 merge window so it should > be sent during the v4.4-rc cycle. Don't worry about that. Thanks, Inki Dae > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Marek,
2015-12-11 20:27 GMT+09:00 Marek Szyprowski :
> Hi Inki,
>
>
> On 2015-12-11 10:57, Inki Dae wrote:
>>
>> Hi Marek,
>>
>> 2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>>
>>> Hi Inki,
>>>
>>> On 2015-12-11 10:02, Inki Dae wrote:
>>>>
>>>> Hi Marek,
>>>>
>>>> I found out why NULL point access happened. That was incurred by below
>>>> your patch,
>>>> [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos
>>>> fb
>>>>
>>>> When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
>>>> the drm frambuffer object of fb_helper is set to the plane state of the
>>>> new crtc driver
>>>> so the driver should get the drm framebuffer object from the plane's
>>>> state or
>>>> exynos_plane->pending_fb which is set by exynos_plane_atomic_update
>>>> function.
>>>>
>>>> After that, I think the drm framebuffer should be set to drm plane as a
>>>> current fb
>>>> which would be scanned out.
>>>>
>>>> Anyway, I can fix it like below if you are ok.
>>>>
>>>> Thanks,
>>>> Inki Dae
>>>>
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>> @@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc
>>>> *crtc,
>>>> if (ctx->suspended)
>>>> return;
>>>>- addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>>>> + addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
>>>> DRM_DEBUG_KMS("dma_addr = %pad\n", );
>>>>
>>>> +plane->base.fb = plane->pending_fb;
>>>
>>> plane->base.fb should not be modified. I think that the following fix is
>>> more
>>
>> Could you explain why plane->base.fb shouldn't be modified?
>
>
> All 'base' classes are modified by DRM core and there should be no need
> to modify them from the drivers.
Ok, If so - drm core updates plane->fb - then it's reasonable. But I
couldn't find the exact location where plane->fb is set to a fb to be
scanned out.
So could you let me know the exact location? it's not clear to me yet.
>
> I've checked this issue and the proper fix for is the following code:
>
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -131,13 +131,14 @@ static void vidi_disable_vblank(struct exynos_drm_crtc
> *crtc)
> static void vidi_update_plane(struct exynos_drm_crtc *crtc,
> struct exynos_drm_plane *plane)
> {
> + struct drm_plane_state *state = plane->base.state;
> struct vidi_context *ctx = crtc->ctx;
> dma_addr_t addr;
>
> if (ctx->suspended)
> return;
>
> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> + addr = exynos_drm_fb_dma_addr(state->fb, 0);
> DRM_DEBUG_KMS("dma_addr = %pad\n", );
>
> if (ctx->vblank_on)
>
>
> plane->base.fb is updated from the core once all crtc/plane atomic update
> calls finishes. The drivers should use the fb stored in plane->base.state.
> I've missed that VIDI driver doesn't get the fb and incorrectly used
> plane->base.fb instad of state->fb while updating the code.
>
Actually, I used state->fb instead of plane->pending_fb but in
exynos_plane_atomic_update function, plane->pending_fb is set to
state->fb.
That is why I commented like below,
" so the driver should get the drm framebuffer object from the plane's
state or exynos_plane->pending_fb which is set by
exynos_plane_atomic_update function."
Anyway, using state->fb looks like more consistent with other drivers,
fimd, decon and mixer.
Thanks,
Inki Dae
>
>
>> In case that userspace requests setplane, plane->base.fb would be updated
>> after update_plane callback.
>> However, in other cases, I don't see how plane->base.fb could be updated.
>> In this case, I think vendor specific drivers would need to update it as a
>> current fb to be scanned out like other some drivers did.
>> Of course, it may be possible for drm core part to take care of it
>> appropriately later.
>>
>> Thanks,
>> Inki Dae
>>
>>> appropriate:
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Marek,
2015ë
12ì 11ì¼ 18:26ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 2015-12-11 10:02, Inki Dae wrote:
>> Hi Marek,
>>
>> I found out why NULL point access happened. That was incurred by below your
>> patch,
>> [PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
>>
>> When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
>> the drm frambuffer object of fb_helper is set to the plane state of the new
>> crtc driver
>> so the driver should get the drm framebuffer object from the plane's state or
>> exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.
>>
>> After that, I think the drm framebuffer should be set to drm plane as a
>> current fb
>> which would be scanned out.
>>
>> Anyway, I can fix it like below if you are ok.
>>
>> Thanks,
>> Inki Dae
>>
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc
>> *crtc,
>> if (ctx->suspended)
>> return;
>> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>> + addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
>> DRM_DEBUG_KMS("dma_addr = %pad\n", );
>>
>> +plane->base.fb = plane->pending_fb;
>
> plane->base.fb should not be modified. I think that the following fix is more
Could you explain why plane->base.fb shouldn't be modified?
In case that userspace requests setplane, plane->base.fb would be updated after
update_plane callback.
However, in other cases, I don't see how plane->base.fb could be updated.
In this case, I think vendor specific drivers would need to update it as a
current fb to be scanned out like other some drivers did.
Of course, it may be possible for drm core part to take care of it
appropriately later.
Thanks,
Inki Dae
> appropriate:
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -132,12 +132,13 @@ static void vidi_update_plane(struct exynos_drm_crtc
> *crtc,
> struct exynos_drm_plane *plane)
> {
> struct vidi_context *ctx = crtc->ctx;
> - dma_addr_t addr;
> + dma_addr_t addr = 0;
>
> if (ctx->suspended)
> return;
>
> - addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> + if (plane->base.fb)
> + addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
> DRM_DEBUG_KMS("dma_addr = %pad\n", );
>
> if (ctx->vblank_on)
>
> I will investigate the case of NULL plane->state.fb, because it might be
> relevant
> to other crtc drivers as well.
>
>
>>if (ctx->vblank_on)
>>
>>
>> 2015ë
12ì 10ì¼ 22:05ì Inki Dae ì´(ê°) ì´ ê¸:
>>>
>>> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>>> DMA address is a framebuffer attribute and the right place for it is
>>>> exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
>>>> helper function for getting dma address of the given framebuffer.
>>>>
>>>> Signed-off-by: Marek Szyprowski
>>>> Reviewed-by: Gustavo Padovan
>>>> ---
>>>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
>>>> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
>>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
>>>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
>>>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 +--
>>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
>>>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
>>>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 5 -
>>>> drivers/gpu/drm/exynos/exynos_mixer.c | 7 ---
>>>> 9 files changed, 38 insertions(+), 53 deletions(-)
>>>>
>>> <--snip-->
>>>
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>> index 669362c53f49..3ce141236fad 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>>>> @@ -24,6 +24,7 @@
>>>> #include "exynos_drm_drv.h"
>>>> #include "exynos_drm_crtc.h&q
[PATCH v2 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size
2015ë
12ì 10ì¼ 21:59ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Hello,
>
> On 2015-12-10 12:35, Inki Dae wrote:
>> Hi Marek,
>>
>> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>> This patch fixes trashed display of buffers cropped to very small width.
>>> Even if DMA is unstable and causes tearing when changing the burst size,
>>> it is still better than displaying a garbage.
>> It seems that this patch is different from above description. I think below
>> patch is just cleanup,
>> which passes each member necessary instead of passing a drm_framebuffer
>> object.
>
> Please note the last chunk of this patch. After applying it width is
> taken from state->src.w instead of fb->width. If you want, I can split
> this patch into 2 parts - one cleanup without functional change, and
> second, replacement of fb->width with state->src.w.
Will just merge it.
Thanks,
Inki Dae
>
>
>>
>>> Signed-off-by: Marek Szyprowski
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +++-
>>> 1 file changed, 11 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 70cd2681e343..2e2247126581 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -487,7 +487,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>>> static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned
>>> int win,
>>> -struct drm_framebuffer *fb)
>>> +uint32_t pixel_format, int width)
>>> {
>>> unsigned long val;
>>> @@ -498,11 +498,11 @@ static void fimd_win_set_pixfmt(struct fimd_context
>>> *ctx, unsigned int win,
>>>* So the request format is ARGB then change it to XRGB.
>>>*/
>>> if (ctx->driver_data->has_limited_fmt && !win) {
>>> -if (fb->pixel_format == DRM_FORMAT_ARGB)
>>> -fb->pixel_format = DRM_FORMAT_XRGB;
>>> +if (pixel_format == DRM_FORMAT_ARGB)
>>> +pixel_format = DRM_FORMAT_XRGB;
>>> }
>>> -switch (fb->pixel_format) {
>>> +switch (pixel_format) {
>>> case DRM_FORMAT_C8:
>>> val |= WINCON0_BPPMODE_8BPP_PALETTE;
>>> val |= WINCONx_BURSTLEN_8WORD;
>>> @@ -538,17 +538,15 @@ static void fimd_win_set_pixfmt(struct fimd_context
>>> *ctx, unsigned int win,
>>> break;
>>> }
>>> -DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
>>> -
>>> /*
>>> - * In case of exynos, setting dma-burst to 16Word causes permanent
>>> - * tearing for very small buffers, e.g. cursor buffer. Burst Mode
>>> - * switching which is based on plane size is not recommended as
>>> - * plane size varies alot towards the end of the screen and rapid
>>> - * movement causes unstable DMA which results into iommu crash/tear.
>>> + * Setting dma-burst to 16Word causes permanent tearing for very small
>>> + * buffers, e.g. cursor buffer. Burst Mode switching which based on
>>> + * plane size is not recommended as plane size varies alot towards the
>>> + * end of the screen and rapid movement causes unstable DMA, but it is
>>> + * still better to change dma-burst than displaying garbage.
>>>*/
>>> -if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
>>> +if (width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
>>> val &= ~WINCONx_BURSTLEN_MASK;
>>> val |= WINCONx_BURSTLEN_4WORD;
>>> }
>>> @@ -723,7 +721,7 @@ static void fimd_update_plane(struct exynos_drm_crtc
>>> *crtc,
>>> DRM_DEBUG_KMS("osd size = 0x%x\n", (unsigned int)val);
>>> }
>>> -fimd_win_set_pixfmt(ctx, win, fb);
>>> +fimd_win_set_pixfmt(ctx, win, fb->pixel_format, state->src.w);
>>> /* hardware window 0 doesn't support color key. */
>>> if (win != 0)
>>>
>
> Best regards
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
Hi Marek,
I found out why NULL point access happened. That was incurred by below your
patch,
[PATCH] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
When another crtc driver is hotplugged in runtime such as HDMI or VIDI,
the drm frambuffer object of fb_helper is set to the plane state of the new
crtc driver
so the driver should get the drm framebuffer object from the plane's state or
exynos_plane->pending_fb which is set by exynos_plane_atomic_update function.
After that, I think the drm framebuffer should be set to drm plane as a current
fb
which would be scanned out.
Anyway, I can fix it like below if you are ok.
Thanks,
Inki Dae
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -137,7 +137,7 @@ static void vidi_update_plane(struct exynos_drm_crtc *crtc,
if (ctx->suspended)
return;
- addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
+ addr = exynos_drm_fb_dma_addr(plane->pending_fb, 0);
DRM_DEBUG_KMS("dma_addr = %pad\n", );
+ plane->base.fb = plane->pending_fb;
if (ctx->vblank_on)
2015ë
12ì 10ì¼ 22:05ì Inki Dae ì´(ê°) ì´ ê¸:
>
>
> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>> DMA address is a framebuffer attribute and the right place for it is
>> exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
>> helper function for getting dma address of the given framebuffer.
>>
>> Signed-off-by: Marek Szyprowski
>> Reviewed-by: Gustavo Padovan
>> ---
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
>> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
>> drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 +--
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 5 -
>> drivers/gpu/drm/exynos/exynos_mixer.c | 7 ---
>> 9 files changed, 38 insertions(+), 53 deletions(-)
>>
>
> <--snip-->
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> index 669362c53f49..3ce141236fad 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
>> @@ -24,6 +24,7 @@
>>
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_crtc.h"
>> +#include "exynos_drm_fb.h"
>> #include "exynos_drm_plane.h"
>> #include "exynos_drm_vidi.h"
>>
>> @@ -126,11 +127,13 @@ static void vidi_update_plane(struct exynos_drm_crtc
>> *crtc,
>>struct exynos_drm_plane *plane)
>> {
>> struct vidi_context *ctx = crtc->ctx;
>> +dma_addr_t addr;
>>
>> if (ctx->suspended)
>> return;
>>
>> -DRM_DEBUG_KMS("dma_addr = %pad\n", plane->dma_addr);
>> +addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
>
> At this point, plane->base.fb is NULL so null pointer access happens like
> below,
>
> [5.969422] Unable to handle kernel NULL pointer dereference at virtual
> address 0090
> [5.977481] pgd = ee59
> [5.980142] [0090] *pgd=6e526831, *pte=, *ppte=
> [5.986347] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [5.991712] Modules linked in:
> [5.994770] CPU: 3 PID: 1598 Comm: sh Not tainted
> 4.4.0-rc3-00052-gc60d7e2-dirty #199
> [6.002565] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [6.008647] task: ef328000 ti: ee4d4000 task.ti: ee4d4000
> [6.014053] PC is at exynos_drm_fb_dma_addr+0x8/0x14
> [6.018990] LR is at vidi_update_plane+0x4c/0xc4
> [6.023581] pc : []lr : []psr: 8013
> [6.023581] sp : ee4d5d90 ip : 0001 fp :
> [6.035029] r10: r9 : c05b965c r8 : ee813e00
> [6.040241] r7 : r6 : ee8e3330 r5 : r4 : ee8e3010
> [6.046749] r3 : r2 : r1 : 0024 r0 :
> [6.053264] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
> none
> [6.060379] Control: 10c5387d Table: 6e59004a DAC: 0051
> [6.066107] Process sh (pid: 1598, stack limit = 0xee4d4210)
> [6.071748] Stack: (0xee4d5d90 to 0xee4d6000)
> [6.076100] 5d80: ee813300
> ee476e40 0005
> [6.08423
-next trees and my time this cycle
Hi Dave, 2015ë 12ì 11ì¼ 15:58ì Dave Airlie ì´(ê°) ì´ ê¸: > Hey all, > > Hopefully all my sub-maintainers are awake and reading this. > > So since Xmas is coming up and I've got an impending new arrival, I'm > betting this merge window might get a bit haphazard. So I'd like > people to start telling me now via git pull's what they'd like to get > in. > > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if > people would like these in now, also anything I've missed on the list. > Other ARM maintainers (especially exynos) please try and get pull > requests in early. I might drop things that come in too late. Sorry for late. I am strugging for review and verification of exynos-drm-next tree. This time, exynos drm tree will include below features, - support runtime pm - support dp panel dt binding using of graph concept. - cleanup part of IPP enhancement patch series. Now while I'm reviewing the cleanup part of IPP enhancement patch series, I found out a critical issue so as soon as I and original author resolve it, I will requst GIT PULL at least within next Monday. Thanks, Inki Dae > > I expect the x86 folks and others who are pretty regular to not be a > problem (i.e. don't be a problem). Especially nouveau early is good > for me if you have anything. > > Dave. > >
[PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
540
0002
[6.222942] 5fc0: 000a7c40 0001 000a9540 0004 0020 000a82c8
000a8294 000a82b4
[6.231102] 5fe0: be8b1624 00012345 b6e94166 4030 0001
[6.239270] [] (exynos_drm_fb_dma_addr) from []
(vidi_update_plane+0x4c/0xc4)
[6.248122] [] (vidi_update_plane) from []
(drm_atomic_helper_commit_planes+0x1f4/0x258)
[6.257928] [] (drm_atomic_helper_commit_planes) from []
(exynos_atomic_commit_complete+0xe4/0x1c4)
[6.268688] [] (exynos_atomic_commit_complete) from []
(exynos_atomic_commit+0x180/0x1cc)
[6.278584] [] (exynos_atomic_commit) from []
(restore_fbdev_mode+0x260/0x290)
[6.287525] [] (restore_fbdev_mode) from []
(drm_fb_helper_restore_fbdev_mode_unlocked+0x30/0x74)
[6.298111] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from
[] (drm_fb_helper_set_par+0x30/0x54)
[6.308961] [] (drm_fb_helper_set_par) from []
(drm_fb_helper_hotplug_event+0x9c/0xdc)
[6.318595] [] (drm_fb_helper_hotplug_event) from []
(drm_helper_hpd_irq_event+0xd4/0x160)
[6.328578] [] (drm_helper_hpd_irq_event) from []
(vidi_store_connection+0x94/0xcc)
[6.337954] [] (vidi_store_connection) from []
(kernfs_fop_write+0xb8/0x1bc)
[6.346723] [] (kernfs_fop_write) from []
(__vfs_write+0x20/0xd8)
[6.354531] [] (__vfs_write) from []
(vfs_write+0x90/0x164)
[6.361821] [] (vfs_write) from [] (SyS_write+0x44/0x9c)
[6.368855] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x3c)
[6.376404] Code: eb0b17f1 eae7 e3510003 d2811024 (d7900101)
When vidi driver is intiated by triggering a connection sysfs file, vidi driver
tries modeset binding by calling drm_fb_helper_hotplug_event.
However, at this time it seems there is a case that plan->state->crtc exists
but plane->fb is NULL, which would be related to vidi driver.
I just looked into this issue roughly so we would need to check this issue in
more details.
Thanks,
Inki Dae
> + DRM_DEBUG_KMS("dma_addr = %pad\n", );
>
> if (ctx->vblank_on)
> schedule_work(>work);
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 4be1a754..f40de82848dc 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -37,6 +37,7 @@
>
> #include "exynos_drm_drv.h"
> #include "exynos_drm_crtc.h"
> +#include "exynos_drm_fb.h"
> #include "exynos_drm_plane.h"
> #include "exynos_drm_iommu.h"
>
> @@ -422,8 +423,8 @@ static void vp_video_buffer(struct mixer_context *ctx,
> return;
> }
>
> - luma_addr[0] = plane->dma_addr[0];
> - chroma_addr[0] = plane->dma_addr[1];
> + luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
> + chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
> ctx->interlace = true;
> @@ -575,7 +576,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> dst_y_offset = plane->crtc_y;
>
> /* converting dma address base and source offset */
> - dma_addr = plane->dma_addr[0]
> + dma_addr = exynos_drm_fb_dma_addr(fb, 0)
> + (plane->src_x * fb->bits_per_pixel >> 3)
> + (plane->src_y * fb->pitches[0]);
> src_x_offset = 0;
>
[PATCH v2 10/22] drm/exynos: introduce exynos_drm_plane_config structure
Hi Marek,
2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch adds common structure for keeping plane configuration and
> capabilities data. This patch is inspired by similar code developed by
> Tobias Jakobi.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 ---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 23 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 19
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 ++-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 34 +
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 7 ++---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 25 ++-
> drivers/gpu/drm/exynos/exynos_mixer.c | 44
> +++
> 8 files changed, 121 insertions(+), 74 deletions(-)
>
<--snip-->
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 3ce141236fad..90701647aef1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -30,7 +30,6 @@
>
> /* vidi has totally three virtual windows. */
> #define WINDOWS_NR 3
> -#define CURSOR_WIN 2
>
> #define ctx_from_connector(c)container_of(c, struct vidi_context, \
> connector)
> @@ -90,6 +89,12 @@ static const uint32_t formats[] = {
> DRM_FORMAT_NV12,
> };
>
> +static const enum drm_plane_type vidi_win_types[WINDOWS_NR] = {
> + DRM_PLANE_TYPE_PRIMARY,
> + DRM_PLANE_TYPE_OVERLAY,
> + DRM_PLANE_TYPE_CURSOR,
> +};
> +
> static int vidi_enable_vblank(struct exynos_drm_crtc *crtc)
> {
> struct vidi_context *ctx = crtc->ctx;
> @@ -442,17 +447,21 @@ static int vidi_bind(struct device *dev, struct device
> *master, void *data)
> struct drm_device *drm_dev = data;
> struct drm_encoder *encoder = >encoder;
> struct exynos_drm_plane *exynos_plane;
> - enum drm_plane_type type;
> - unsigned int zpos;
> + struct exynos_drm_plane_config plane_config = { 0 };
> + unsigned int i;
> int pipe, ret;
>
> vidi_ctx_initialize(ctx, drm_dev);
>
> - for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = exynos_plane_get_type(zpos, CURSOR_WIN);
> - ret = exynos_plane_init(drm_dev, >planes[zpos],
> - 1 << ctx->pipe, type, formats,
> - ARRAY_SIZE(formats), zpos);
> + plane_config.pixel_formats = formats;
> + plane_config.num_pixel_formats = ARRAY_SIZE(formats);
> +
> + for (i = 0; i < WINDOWS_NR; i++) {
> + plane_config.zpos = i;
> + plane_config.type = vidi_win_types(i);
vidi_win_types is not really a function. So this should be 'vidi_win_type[i]'
This is a trivial so I can fix it.
Thanks,
Inki Dae
> +
> + ret = exynos_plane_init(drm_dev, >planes[i],
> + 1 << ctx->pipe, _config);
> if (ret)
> return ret;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 8d2ce13eb725..a229f86d221a 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -43,7 +43,6 @@
>
> #define MIXER_WIN_NR 3
> #define VP_DEFAULT_WIN 2
> -#define CURSOR_WIN 1
>
> /* The pixelformats that are natively supported by the mixer. */
> #define MXR_FORMAT_RGB5654
> @@ -112,6 +111,25 @@ struct mixer_drv_data {
> boolhas_sclk;
> };
>
> +static const struct exynos_drm_plane_config plane_configs[MIXER_WIN_NR] = {
> + {
> + .zpos = 0,
> + .type = DRM_PLANE_TYPE_PRIMARY,
> + .pixel_formats = mixer_formats,
> + .num_pixel_formats = ARRAY_SIZE(mixer_formats),
> + }, {
> + .zpos = 1,
> + .type = DRM_PLANE_TYPE_CURSOR,
> + .pixel_formats = mixer_formats,
> + .num_pixel_formats = ARRAY_SIZE(mixer_formats),
> + }, {
> + .zpos = 2,
> + .type = DRM_PLANE_TYPE_OVERLAY,
> + .pixel_formats = vp_formats,
> + .num_pixel_formats = ARRAY_SIZE(vp_formats),
> + },
> +};
> +
> static const u8 filter_y_horiz_tap8[] = {
> 0, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, 0, 0,
[PATCH v2 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size
Hi Marek,
2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch fixes trashed display of buffers cropped to very small width.
> Even if DMA is unstable and causes tearing when changing the burst size,
> it is still better than displaying a garbage.
It seems that this patch is different from above description. I think below
patch is just cleanup,
which passes each member necessary instead of passing a drm_framebuffer object.
Thanks,
Inki Dae
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 70cd2681e343..2e2247126581 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -487,7 +487,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>
>
> static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
> - struct drm_framebuffer *fb)
> + uint32_t pixel_format, int width)
> {
> unsigned long val;
>
> @@ -498,11 +498,11 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
>* So the request format is ARGB then change it to XRGB.
>*/
> if (ctx->driver_data->has_limited_fmt && !win) {
> - if (fb->pixel_format == DRM_FORMAT_ARGB)
> - fb->pixel_format = DRM_FORMAT_XRGB;
> + if (pixel_format == DRM_FORMAT_ARGB)
> + pixel_format = DRM_FORMAT_XRGB;
> }
>
> - switch (fb->pixel_format) {
> + switch (pixel_format) {
> case DRM_FORMAT_C8:
> val |= WINCON0_BPPMODE_8BPP_PALETTE;
> val |= WINCONx_BURSTLEN_8WORD;
> @@ -538,17 +538,15 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> break;
> }
>
> - DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
> -
> /*
> - * In case of exynos, setting dma-burst to 16Word causes permanent
> - * tearing for very small buffers, e.g. cursor buffer. Burst Mode
> - * switching which is based on plane size is not recommended as
> - * plane size varies alot towards the end of the screen and rapid
> - * movement causes unstable DMA which results into iommu crash/tear.
> + * Setting dma-burst to 16Word causes permanent tearing for very small
> + * buffers, e.g. cursor buffer. Burst Mode switching which based on
> + * plane size is not recommended as plane size varies alot towards the
> + * end of the screen and rapid movement causes unstable DMA, but it is
> + * still better to change dma-burst than displaying garbage.
>*/
>
> - if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
> + if (width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
> val &= ~WINCONx_BURSTLEN_MASK;
> val |= WINCONx_BURSTLEN_4WORD;
> }
> @@ -723,7 +721,7 @@ static void fimd_update_plane(struct exynos_drm_crtc
> *crtc,
> DRM_DEBUG_KMS("osd size = 0x%x\n", (unsigned int)val);
> }
>
> - fimd_win_set_pixfmt(ctx, win, fb);
> + fimd_win_set_pixfmt(ctx, win, fb->pixel_format, state->src.w);
>
> /* hardware window 0 doesn't support color key. */
> if (win != 0)
>
[PATCH v2 03/22] drm/exynos: gsc: add device tree support and remove usage of static mappings
CCing Mr. Kukjin and Krzysztof
Hi Kukjin and Krzysztof,
Below patch includes dt binding about gsc device but it'd be nice this patch to
exynos drm tree with others.
So could you give me Acked-by so that I can merge it to exynos drm tree?
Thanks,
Inki Dae
2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> From: Seung-Woo Kim
>
> This patch adds device tree support for exynos_drm_gsc. This patch
> also fixed build issue on non-Exynos platforms, thus dependency on
> !ARCH_MULTIPLATFORM can be now removed. The driver cannot be used
> simultaneously with V4L2 Mem2Mem GScaller driver thought.
>
> Signed-off-by: Seung-Woo Kim
> [updated commit message, removed the need for wb-lcd property, because
> all gscallers have support for lcd writeback, replaced dependency on
> !ARCH_MULTIPLATFORM with !VIDEO_SAMSUNG_EXYNOS_GSC]
> Signed-off-by: Marek Szyprowski
> ---
> .../devicetree/bindings/media/exynos5-gsc.txt | 4 +++
> drivers/gpu/drm/exynos/Kconfig | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_gsc.c| 30
> +++---
> drivers/gpu/drm/exynos/regs-gsc.h | 4 +--
> 4 files changed, 33 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> index 0604d42f38d1..5fe9372abb37 100644
> --- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> +++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
> @@ -7,6 +7,10 @@ Required properties:
> - reg: should contain G-Scaler physical address location and length.
> - interrupts: should contain G-Scaler interrupt number
>
> +Optional properties:
> +- samsung,sysreg: handle to syscon used to control the system registers to
> + set writeback input and destination
> +
> Example:
>
> gsc_0: gsc at 0x13e0 {
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 96e86cf4455b..83efca941388 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -118,7 +118,7 @@ config DRM_EXYNOS_ROTATOR
>
> config DRM_EXYNOS_GSC
> bool "GScaler"
> - depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !ARCH_MULTIPLATFORM
> + depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !VIDEO_SAMSUNG_EXYNOS_GSC
> help
> Choose this option if you want to use Exynos GSC for DRM.
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index ed55d37b6330..7aecd23cfa11 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -15,7 +15,8 @@
> #include
> #include
> #include
> -#include
> +#include
> +#include
>
> #include
> #include
> @@ -126,6 +127,7 @@ struct gsc_capability {
> * @ippdrv: prepare initialization using ippdrv.
> * @regs_res: register resources.
> * @regs: memory mapped io registers.
> + * @sysreg: handle to SYSREG block regmap.
> * @lock: locking of operations.
> * @gsc_clk: gsc gate clock.
> * @sc: scaler infomations.
> @@ -138,6 +140,7 @@ struct gsc_context {
> struct exynos_drm_ippdrvippdrv;
> struct resource *regs_res;
> void __iomem*regs;
> + struct regmap *sysreg;
> struct mutexlock;
> struct clk *gsc_clk;
> struct gsc_scaler sc;
> @@ -437,9 +440,12 @@ static int gsc_sw_reset(struct gsc_context *ctx)
>
> static void gsc_set_gscblk_fimd_wb(struct gsc_context *ctx, bool enable)
> {
> - u32 gscblk_cfg;
> + unsigned int gscblk_cfg;
>
> - gscblk_cfg = readl(SYSREG_GSCBLK_CFG1);
> + if (!ctx->sysreg)
> + return;
> +
> + regmap_read(ctx->sysreg, SYSREG_GSCBLK_CFG1, _cfg);
>
> if (enable)
> gscblk_cfg |= GSC_BLK_DISP1WB_DEST(ctx->id) |
> @@ -448,7 +454,7 @@ static void gsc_set_gscblk_fimd_wb(struct gsc_context
> *ctx, bool enable)
> else
> gscblk_cfg |= GSC_BLK_PXLASYNC_LO_MASK_WB(ctx->id);
>
> - writel(gscblk_cfg, SYSREG_GSCBLK_CFG1);
> + regmap_write(ctx->sysreg, SYSREG_GSCBLK_CFG1, gscblk_cfg);
> }
>
> static void gsc_handle_irq(struct gsc_context *ctx, bool enable,
> @@ -1663,6 +1669,15 @@ static int gsc_probe(struct platform_device *pdev)
> if (!ctx)
> return -ENOMEM;
>
> + if (dev->of_node) {
> + ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
> + "samsung,sysreg");
> + if (IS_ERR(ctx
[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi
2015ë 12ì 08ì¼ 10:47ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸: > On 08.12.2015 10:33, Javier Martinez Canillas wrote: >> Hello Krzysztof, >> >> On 12/07/2015 09:45 PM, Krzysztof Kozlowski wrote: >>> On 07.12.2015 21:52, Inki Dae wrote: >>>> From: Javier Martinez Canillas >>>> >>>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent >>>> since it uses a phandle to describe the connection between the DP port and >>>> the display panel but uses the OF graph ports and endpoints to describe the >>>> connection betwen the DP port, a bridge chip and the panel. >>>> >>>> The Exynos DP driver and the DT binding have been changed to allow also to >>>> describe the DP port to panel connection using ports / endpoints (OF graph) >>>> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with >>>> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too. >>>> >>>> Signed-off-by: Javier Martinez Canillas >>>> Tested-by: Javier Martinez Canillas >>>> Reviewed-by: Inki Dae >>>> --- >>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++- >>>> 1 file changed, 14 insertions(+), 1 deletion(-) >>>> >>> >>> Looks sensible: >>> Reviewed-by: Krzysztof Kozlowski >>> >>> Dependencies are not mentioned, does it depend on patch 1? >>> >> >> Yes, it depends on patch 1/4 so it should be merged through the Exynos DRM >> tree to maintain bisectability. Inki's patch maintains the DT ABI backward >> compatibility though so another option is to wait until the DRM change hit >> mainline and then pick $SUBJECT. > > Thanks. We could also use a tag with DRM changes for samsung-soc but > since I already flushed my queue for v4.5 I think it would be an > overkill. From my point of view it can safely go through exynos-drm tree. I will pick it up to exynos-drm tree. :) Thanks, Inki Dae > > Best regards, > Krzysztof > >
[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi
2015ë 12ì 08ì¼ 09:48ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸: > On 08.12.2015 00:36, Inki Dae wrote: >> Hi Javier, >> >> 2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas > osg.samsung.com>: >>> Hello Inki, >>> >>> On 12/07/2015 09:52 AM, Inki Dae wrote: >>>> From: Javier Martinez Canillas >>>> >>> >>> Thanks a lot for posting this patch. >>> >>>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent >>>> since it uses a phandle to describe the connection between the DP port and >>>> the display panel but uses the OF graph ports and endpoints to describe the >>>> connection betwen the DP port, a bridge chip and the panel. >>>> >>>> The Exynos DP driver and the DT binding have been changed to allow also to >>>> describe the DP port to panel connection using ports / endpoints (OF graph) >>>> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with >>>> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too. >>>> >>>> Signed-off-by: Javier Martinez Canillas >>>> Tested-by: Javier Martinez Canillas >>> >>> This tag was not in my original patch, it's true that I tested >>> it but will someone believe me? ;) >> >> Oops. I confused you spread Reviewed-by and Tested-by here and there. >> Don't worry about that. Will remove it if you don't give me Tested-by. >> :) > > Actually authorship (the "From") in this case means Tested-by. Author > always tests the patch so it would look weird if we start adding > tested-by to our own patches, right? > > Dear Inki, > However the patch misses your SoB. You touched and sent it so please > extend the SoB chain-of-blame. Right. Missed. Thanks, Inki Dae > > Best regards, > Krzysztof > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi
Hi Javier, 2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas : > Hello Inki, > > On 12/07/2015 09:52 AM, Inki Dae wrote: >> From: Javier Martinez Canillas >> > > Thanks a lot for posting this patch. > >> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent >> since it uses a phandle to describe the connection between the DP port and >> the display panel but uses the OF graph ports and endpoints to describe the >> connection betwen the DP port, a bridge chip and the panel. >> >> The Exynos DP driver and the DT binding have been changed to allow also to >> describe the DP port to panel connection using ports / endpoints (OF graph) >> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with >> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too. >> >> Signed-off-by: Javier Martinez Canillas >> Tested-by: Javier Martinez Canillas > > This tag was not in my original patch, it's true that I tested > it but will someone believe me? ;) Oops. I confused you spread Reviewed-by and Tested-by here and there. Don't worry about that. Will remove it if you don't give me Tested-by. :) Thanks, Inki Dae > >> Reviewed-by: Inki Dae > > Thanks for the review. > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: decon: remove unused variables
This patch just removes unused variables, i and ret.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index edfd6e3..2ac1d4d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -377,8 +377,6 @@ static void decon_swreset(struct decon_context *ctx)
static void decon_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
- int ret;
- int i;
if (!test_and_clear_bit(BIT_SUSPENDED, >flags))
return;
--
1.9.1
[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi
From: Javier Martinez Canillas <jav...@osg.samsung.com>
The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
since it uses a phandle to describe the connection between the DP port and
the display panel but uses the OF graph ports and endpoints to describe the
connection betwen the DP port, a bridge chip and the panel.
The Exynos DP driver and the DT binding have been changed to allow also to
describe the DP port to panel connection using ports / endpoints (OF graph)
so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
Signed-off-by: Javier Martinez Canillas
Tested-by: Javier Martinez Canillas
Reviewed-by: Inki Dae
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..1cc2e95 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -122,6 +122,12 @@
compatible = "auo,b133htn01";
power-supply = <_fet6>;
backlight = <>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
};
mmc1_pwrseq: mmc1_pwrseq {
@@ -148,7 +154,14 @@
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
- panel = <>;
+
+ ports {
+ port {
+ dp_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
};
{
--
1.9.1
[PATCH v2 3/4] dt-bindings: exynos-dp: update ports node binding for panel
This patch updates a ports node binding for panel.
With this, dp node can have a ports node which describes
a remote endpoint node that can be connected to panel or bridge
node.
Changelog v2:
- remove unnecessary properties and numbering.
- update description about eDP device.
Signed-off-by: Inki Dae
Reviewed-by: Javier Martinez Canillas
---
.../bindings/display/exynos/exynos_dp.txt | 41 +++---
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 64693f2..22efeba 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -1,3 +1,20 @@
+Device-Tree bindings for Samsung Exynos Embedded DisplayPort Transmitter(eDP)
+
+DisplayPort is industry standard to accommodate the growing board adoption
+of digital display technology within the PC and CE industries.
+It consolidates the internal and external connection methods to reduce device
+complexity and cost. It also supports necessary features for important cross
+industry applications and provides performance scalability to enable the next
+generation of displays that feature higher color depths, refresh rates, and
+display resolutions.
+
+eDP (embedded display port) device is compliant with Embedded DisplayPort
+standard as follows,
+- DisplayPort standard 1.1a for Exynos5250 and Exynos5260.
+- DisplayPort standard 1.3 for Exynos5422s and Exynos5800.
+
+eDP resides between FIMD and panel or FIMD and bridge such as LVDS.
+
The Exynos display port interface should be configured based on
the type of panel connected to it.
@@ -66,8 +83,15 @@ Optional properties for dp-controller:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug
detection
- -video interfaces: Device node can contain video interface port
- nodes according to [1].
+Video interfaces:
+ Device node can contain video interface port nodes according to [1].
+ The following are properties specific to those nodes:
+
+ endpoint node connected to bridge or panel node:
+ - remote-endpoint: specifies the endpoint in panel or bridge node.
+ This node is required in all kinds of exynos dp
+ to represent the connection between dp and bridge
+ or dp and panel.
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -111,9 +135,18 @@ Board Specific portion:
};
ports {
- port at 0 {
+ port {
dp_out: endpoint {
- remote-endpoint = <_in>;
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+
+ panel {
+ ...
+ port {
+ dp_in: endpoint {
+ remote-endpoint = <_out>;
};
};
};
--
1.9.1
[PATCH v2 2/4] drm/exynos: dp: fix wrong return type
This patch fixes wrong return type when dt binding of bridge device
failed.
If a board has a bridge device then of_graph_get_remote_port_parent
function shouldn't be NULL. So this patch will return a proper error
type so that the deferred probe isn't triggered.
Changelog v2:
- return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 60260a0..aeee60a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1437,8 +1437,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
of_node_put(bridge_node);
if (!dp->ptn_bridge)
return -EPROBE_DEFER;
- } else
- return -EPROBE_DEFER;
+ } else {
+ DRM_ERROR("no port node for bridge device.\n");
+ return -EINVAL;
+ }
}
out:
--
1.9.1
[PATCH v3 1/4] drm/exynos: dp: add of_graph dt binding support for panel
This patch adds of_graph dt binding support for panel device
and also keeps the backward compatibility.
i.e.,
The dts file for Exynos5800 based peach pi board
has a panel property so we need to keep the backward compatibility.
Changelog v3:
- bind only one of two nodes outbound - panel or bridge.
Changelog v2:
- return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 94f02a0..60260a0 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct device_node *panel_node, *bridge_node, *endpoint;
+ struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
struct exynos_dp_device *dp;
int ret;
@@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dp);
+ /* This is for the backward compatibility. */
panel_node = of_parse_phandle(dev->of_node, "panel", 0);
if (panel_node) {
dp->panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
if (!dp->panel)
return -EPROBE_DEFER;
+ } else {
+ endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (endpoint) {
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ if (panel_node) {
+ dp->panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (!dp->panel)
+ return -EPROBE_DEFER;
+ } else {
+ DRM_ERROR("no port node for panel device.\n");
+ return -EINVAL;
+ }
+ }
}
+ if (endpoint)
+ goto out;
+
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
if (endpoint) {
bridge_node = of_graph_get_remote_port_parent(endpoint);
@@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+out:
pm_runtime_enable(dev);
ret = component_add(>dev, _dp_ops);
--
1.9.1
[PATCH v2 0/4] drm/exynos: dp: consider port node outbound for panel
This patch series considers a port node outbound for panel device node, including dt binding for it. And also it fixes a wrong error type. Changelog v2: - add a patch from Javier, which allows dp to connect panel using of graph. - remove unnecessary properties and numbering pointed out by Rob and Javier. - update description about eDP device. Thanks, Inki Dae Inki Dae (3): drm/exynos: dp: add of_graph dt binding support for panel drm/exynos: dp: fix wrong return type dt-bindings: exynos-dp: update ports node binding for panel Javier Martinez Canillas (1): ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi .../bindings/display/exynos/exynos_dp.txt | 41 +++--- arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 +++- drivers/gpu/drm/exynos/exynos_dp_core.c| 27 -- 3 files changed, 75 insertions(+), 8 deletions(-) -- 1.9.1
[PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel
Hi Javier,
2015-12-03 22:05 GMT+09:00 Javier Martinez Canillas :
>
> Hello Inki,
>
> On 12/02/2015 11:11 PM, Inki Dae wrote:
>> Hi Javier,
>>
>> 2015ë
12ì 03ì¼ 00:04ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
>>> Hello Inki,
>>>
>>> On 12/02/2015 08:57 AM, Inki Dae wrote:
>>>> This patch adds of_graph dt binding support for panel device
>>>> and also keeps the backward compatibility.
>>>>
>>>
>>> You have to also update the DT binding doc which seems to be
>>> outdated already:
>>>
>>> Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>>
>> Right. It should be updated.
>>
>
> Great, I see you already posted that.
>
>>>
>>>> i.e.,
>>>> The dts file for Exynos5800 based peach pi board
>>>> has a panel property so we need to keep the backward compatibility.
>>>>
>>>
>>> How did you test this patch?
>>
>> I thought you will test it and give me tested-by because you commented like
>> below,
>> " Assuming you can make a distinction if the endpoint is a panel or a bridge,
>> then yes, I agree with the idea of the patch. Please feel free to cc me if
>> you post such a patch and I'll gladly test it on my Exynos5800 Peach Pi."
>>
>> That is why I cced you. I really have no any Exynos5800 Peach Pi board.
>>
>
> Yes, but if you didn't test a patch, then it should be marked with a RFT
> prefix in the subject line or at least mention that needs testing since
> you lack the HW to test. I've no way to know if you have another board
> with a similar design :)
>
> But what I meant is how the patch is supposed to be tested since there
> ins't a change in the Exynos5800 Peach Pi DTS? We can of course test
> that doesn't break backward compatibility but we don't have a way to
> test the actual change.
>
> So I tested with the patch following patch [0] and things are working
> correctly. Please include that patch in your series.
Will pick it up. And I commented on below your patch.
>
> I've some comments on your patch though but I'll comment on your lastest
> version.
>
>> Thanks,
>> Inki Dae
>>
>>>
>>> Best regards,
>>>
>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
>
> [0]:
> From 644bab7949ac17a8d42ca0cf36cd55d61bc88928 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas
> Date: Thu, 3 Dec 2015 09:32:17 -0300
> Subject: [PATCH 1/1] ARM: dts: Use OF graph for DP to panel connection in
> exynos5800-peach-pi
>
> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent
> since it uses a phandle to describe the connection between the DP port and
> the display panel but uses the OF graph ports and endpoints to describe the
> connection betwen the DP port, a bridge chip and the panel.
>
> The Exynos DP driver and the DT binding have been changed to allow also to
> describe the DP port to panel connection using ports / endpoints (OF graph)
> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with
> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too.
>
> Signed-off-by: Javier Martinez Canillas
> ---
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 7b018e451880..9c6fd7314ee0 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -122,6 +122,12 @@
> compatible = "auo,b133htn01";
> power-supply = <_fet6>;
> backlight = <>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> };
>
> mmc1_pwrseq: mmc1_pwrseq {
> @@ -148,7 +154,14 @@
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <2>;
> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
> - panel = <>;
> +
> + ports {
> + port at 0 {
As Rob commented before, I will pick it up removing @0 if you are ok.
Thanks,
Inki Dae
> + dp_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> };
>
> {
> --
> 2.4.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hi Javier, 2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas : > Hello Inki, > > On 12/04/2015 06:00 AM, Inki Dae wrote: >> Hi Javier, >> >> 2015ë 12ì 03ì¼ 22:55ì Javier Martinez Canillas ì´(ê°) ì´ ê¸: >>> Hello Inki, >>> >>> I found that v2 of this patch is alredy in your exynos-drm for-next branch >>> so >>> so I had to revert it in linux-next to apply this one to test. You shouldn't >>> push patches that were still not reviewed (specially the ones that weren't >>> tested like this one) to your branch that gets pulled by -next. The idea of >>> -next is to have some test coverage but it should be as stable as possible. >> >> exynos-drm/for-next branch is not really for-next branch. This branch is used > > Well, it is a for-next branch because is pulled by -next. It is listed in: > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees > > drm-exynos git > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next > >> only for integration test. As you know, there are many exynos maintainers >> and they have their own repository. So we would need to test the integration. > > Integration testing is of course very needed and linux-next is for that but > what should be tested are the patches that are targeted to mainline. > >> For this, exynos-drm/for-next is merged to linux-next not Dave's tree. >> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed >> and >> tested patches will be merged to exynos-drm-next. >> > > In that case, exynos-drm-next is what should be pulled by linux-next, no the > for-next branch. Linux-next is a simulation of what Torvalds would do next > so problems are found earlier, ideally before the patches land into mainline. Seems I didn't comment enough. exynos-drm/for-next branch includes all patches of exynos-drm-next and actually, they keep same patches for most time but sometimes, I merge additional patches only to exynos-drm/for-next, which should be more tested with other trees before going to Dave's tree. One more thing, there is other difference between exynos-drm-next and exynos-drm/for-next. That is all patches of exynos-drm-next are merged on top of based on Dave's drm-next branch. On the other hand, all of exynos-drm/for-next are merged on top of mainline. So if exynos-drm-next is merged to linux-next then all patches will be conflicted with Dave's tree because his branch is also merged to linux-next. I'm not sure that other maintainers always keep only the for-next branch in their repository but in my case, I use exynos-drm/for-next branch for the test before going to drm-next. Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree will also be pulled by linux-next, which would allow exynos-drm-next to be tested altogether again before going to mainline. Thanks, Inki Dae > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel
Hi Rob,
2015ë
12ì 04ì¼ 08:38ì Rob Herring ì´(ê°) ì´ ê¸:
> On Thu, Dec 03, 2015 at 06:30:10PM +0900, Inki Dae wrote:
>> This patch updates a ports node binding for panel.
>>
>> With this, dp node can have a ports node which describes
>> a remote endpoint node that can be connected to panel or bridge
>> node.
>>
>> Signed-off-by: Inki Dae
>> ---
>> .../bindings/display/exynos/exynos_dp.txt | 28
>> ++
>> 1 file changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> index 64693f2..15b52cb 100644
>> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
>> Hotplug detect GPIO.
>> Indicates which GPIO should be used for hotplug
>> detection
>> --video interfaces: Device node can contain video interface port
>> -nodes according to [1].
>> +Video interfaces:
>> + Device node can contain video interface port nodes according to [1].
>> + The following are properties specific to those nodes:
>> +
>> + endpoint node connected to bridge or panel node:
>> + - remote-endpoint: specifies the endpoint in panel or bridge node.
>> + This node is required in all kinds of exynos dp
>> + to represent the connection between dp and bridge
>> + ,or dp and panel.
>
> Fix your punctuation.
Right.
>
>>
>> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>
>> @@ -111,9 +118,22 @@ Board Specific portion:
>> };
>>
>> ports {
>> -port at 0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>
> You don't need these.
Ditto.
>
>> +
>> +port {
>> dp_out: endpoint {
>> - remote-endpoint = <_in>;
>> +remote-endpoint = <_in>;
>> +};
>> +};
>> +};
>> +
>> +panel at 0 {
>> +reg = <0>;
>
> Drop the @0 and reg as you only have 1.
Ditto.
Thanks,
Inki Dae
>
>> +...
>> +port {
>> +dp_in: endpoint {
>> +remote-endpoint = <_out>;
>> };
>> };
>> };
>> --
>> 1.9.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
[PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel
Hi Javier,
2015ë
12ì 03ì¼ 22:29ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
>
> On 12/03/2015 06:30 AM, Inki Dae wrote:
>> This patch updates a ports node binding for panel.
>>
>> With this, dp node can have a ports node which describes
>> a remote endpoint node that can be connected to panel or bridge
>> node.
>>
>> Signed-off-by: Inki Dae
>> ---
>> .../bindings/display/exynos/exynos_dp.txt | 28
>> ++
>> 1 file changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> index 64693f2..15b52cb 100644
>> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
>> Hotplug detect GPIO.
>> Indicates which GPIO should be used for hotplug
>> detection
>> --video interfaces: Device node can contain video interface port
>> -nodes according to [1].
>> +Video interfaces:
>> + Device node can contain video interface port nodes according to [1].
>> + The following are properties specific to those nodes:
>> +
>> + endpoint node connected to bridge or panel node:
>> + - remote-endpoint: specifies the endpoint in panel or bridge node.
>> + This node is required in all kinds of exynos dp
>> + to represent the connection between dp and bridge
>> + ,or dp and panel.
>>
>
> This is nice but I think the DT binding should also document that it uses
> a phandle to define the connection with the panel (but explain that is
> deprecated). If only so people looking at a DTS and then going to the DT
> binding can understand why there is two ways to define the same.
>
>> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>
>> @@ -111,9 +118,22 @@ Board Specific portion:
>> };
>>
>> ports {
>> -port at 0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>
> These two properties are only needed when there is more than 2 ports and
> a reg property is used to number the port nodes but I don't think that's
> the case for Exynos DP and certainly is not the case in this example so
> I think you should just remove them.
Right. I found out that the dp can have only one port outbound. Will remove
them.
>
>> +port {
>> dp_out: endpoint {
>> -remote-endpoint = <_in>;
>> +remote-endpoint = <_in>;
>> +};
>> +};
>> +};
>> +
>> +panel at 0 {
>> +reg = <0>;
>> +...
>> +port {
>> +dp_in: endpoint {
>> +remote-endpoint = <_out>;
>> };
>> };
>> };
>>
>
> The rest looks good to me so with the two changes feel free to add:
>
> Reviewed-by: Javier Martinez Canillas
Thanks,
Inki Dae
>
> Best regards,
>
[PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hi Javier,
2015ë
12ì 03ì¼ 22:55ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
>
> I found that v2 of this patch is alredy in your exynos-drm for-next branch so
> so I had to revert it in linux-next to apply this one to test. You shouldn't
> push patches that were still not reviewed (specially the ones that weren't
> tested like this one) to your branch that gets pulled by -next. The idea of
> -next is to have some test coverage but it should be as stable as possible.
exynos-drm/for-next branch is not really for-next branch. This branch is used
only for integration test. As you know, there are many exynos maintainers
and they have their own repository. So we would need to test the integration.
For this, exynos-drm/for-next is merged to linux-next not Dave's tree.
Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and
tested patches will be merged to exynos-drm-next.
>
> On 12/03/2015 06:30 AM, Inki Dae wrote:
>> This patch adds of_graph dt binding support for panel device
>> and also keeps the backward compatibility.
>>
>> i.e.,
>> The dts file for Exynos5800 based peach pi board
>> has a panel property so we need to keep the backward compatibility.
>>
>> Changelog v3:
>> - bind only one of two nodes outbound - panel or bridge.
>>
>
> This patch fixes one of the comments I had for v2 but I've another
> comment below.
>
>> Changelog v2:
>> - return -EINVAL if getting a port node failed.
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 21 -
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 94f02a0..60260a0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
>> static int exynos_dp_probe(struct platform_device *pdev)
>> {
>> struct device *dev = >dev;
>> -struct device_node *panel_node, *bridge_node, *endpoint;
>> +struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
>> struct exynos_dp_device *dp;
>> int ret;
>>
>> @@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device
>> *pdev)
>>
>> platform_set_drvdata(pdev, dp);
>>
>> +/* This is for the backward compatibility. */
>> panel_node = of_parse_phandle(dev->of_node, "panel", 0);
>> if (panel_node) {
>> dp->panel = of_drm_find_panel(panel_node);
>> of_node_put(panel_node);
>> if (!dp->panel)
>> return -EPROBE_DEFER;
>> +} else {
>> +endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
>> +if (endpoint) {
>> +panel_node = of_graph_get_remote_port_parent(endpoint);
>
> Here is asssumed that the endpoint will be a panel but it could be that there
> is no "panel" phandle but the port is for a bridge chip (i.e: Peach Pit) so
> this assumption seems fragile to me.
>
> That's what I meant when I said "Assuming you can make a distinction if the
> endpoint is a panel or a bridge" in the other thread.
>
>> +if (panel_node) {
>> +dp->panel = of_drm_find_panel(panel_node);
>> +of_node_put(panel_node);
>> +if (!dp->panel)
>> +return -EPROBE_DEFER;
>> +} else {
>> +DRM_ERROR("no port node for panel device.\n");
>> +return -EINVAL;
>> +}
>> +}
>> }
>>
>> +if (endpoint)
>> +goto out;
>> +
>
> Ok, so IIUC what's done here is to test if the panel lookup failed, then the
> endpoint is looked up again but this time a call to of_drm_find_bridge() is
> made instead of a call to of_drm_find_panel(). I wonder if there is a better
> way to do this...
>
> In any case then I think you should test if (panel_node) instead of endpoint.
>
>> endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
>> if (endpoint) {
>> bridge_node = of_graph_get_remote_port_parent(endpoint);
>> @@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device
>> *pdev)
>> return -EPR
[PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel
This patch updates a ports node binding for panel.
With this, dp node can have a ports node which describes
a remote endpoint node that can be connected to panel or bridge
node.
Signed-off-by: Inki Dae
---
.../bindings/display/exynos/exynos_dp.txt | 28 ++
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 64693f2..15b52cb 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -66,8 +66,15 @@ Optional properties for dp-controller:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug
detection
- -video interfaces: Device node can contain video interface port
- nodes according to [1].
+Video interfaces:
+ Device node can contain video interface port nodes according to [1].
+ The following are properties specific to those nodes:
+
+ endpoint node connected to bridge or panel node:
+ - remote-endpoint: specifies the endpoint in panel or bridge node.
+ This node is required in all kinds of exynos dp
+ to represent the connection between dp and bridge
+ ,or dp and panel.
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -111,9 +118,22 @@ Board Specific portion:
};
ports {
- port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
dp_out: endpoint {
- remote-endpoint = <_in>;
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+
+ panel at 0 {
+ reg = <0>;
+ ...
+ port {
+ dp_in: endpoint {
+ remote-endpoint = <_out>;
};
};
};
--
1.9.1
[PATCH v2 2/3] drm/exynos: dp: fix wrong return type
This patch fixes wrong return type when dt binding of bridge device
failed.
If a board has a bridge device then of_graph_get_remote_port_parent
function shouldn't be NULL. So this patch will return a proper error
type so that the deferred probe isn't triggered.
Changelog v2:
- return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 60260a0..aeee60a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1437,8 +1437,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
of_node_put(bridge_node);
if (!dp->ptn_bridge)
return -EPROBE_DEFER;
- } else
- return -EPROBE_DEFER;
+ } else {
+ DRM_ERROR("no port node for bridge device.\n");
+ return -EINVAL;
+ }
}
out:
--
1.9.1
[PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
This patch adds of_graph dt binding support for panel device
and also keeps the backward compatibility.
i.e.,
The dts file for Exynos5800 based peach pi board
has a panel property so we need to keep the backward compatibility.
Changelog v3:
- bind only one of two nodes outbound - panel or bridge.
Changelog v2:
- return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 94f02a0..60260a0 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct device_node *panel_node, *bridge_node, *endpoint;
+ struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
struct exynos_dp_device *dp;
int ret;
@@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dp);
+ /* This is for the backward compatibility. */
panel_node = of_parse_phandle(dev->of_node, "panel", 0);
if (panel_node) {
dp->panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
if (!dp->panel)
return -EPROBE_DEFER;
+ } else {
+ endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (endpoint) {
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ if (panel_node) {
+ dp->panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (!dp->panel)
+ return -EPROBE_DEFER;
+ } else {
+ DRM_ERROR("no port node for panel device.\n");
+ return -EINVAL;
+ }
+ }
}
+ if (endpoint)
+ goto out;
+
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
if (endpoint) {
bridge_node = of_graph_get_remote_port_parent(endpoint);
@@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+out:
pm_runtime_enable(dev);
ret = component_add(>dev, _dp_ops);
--
1.9.1
[PATCH 0/3] drm/exynos: dp: consider port node outbound for panel
This patch series considers a port node outbound for panel device node, including dt binding for it. And also it fixes a wrong error type. P.s., I already posted relevant patch series[1] before but missed dt binding. So please, ignore the patch series - I couldn't search the patch series on google.com so couldn't link it. Thanks, Inki Dae [1] [PATCH 0/2] drm/exynos: dp: add of_graph dt binding for panel device Inki Dae (3): drm/exynos: dp: add of_graph dt binding support for panel drm/exynos: dp: fix wrong return type dt-bindings: exynos-dp: update ports node binding for panel .../bindings/display/exynos/exynos_dp.txt | 28 ++ drivers/gpu/drm/exynos/exynos_dp_core.c| 27 ++--- 2 files changed, 48 insertions(+), 7 deletions(-) -- 1.9.1
[PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel
It seems that below patch should be modifed for only one of two outbound nodes
- panel
and bridge - to be bound because in case of using bridge device, the bridge
driver will
bind the panel. I will fix and post it again.
Thanks,
Inki Dae
2015ë
12ì 02ì¼ 20:57ì Inki Dae ì´(ê°) ì´ ê¸:
> This patch adds of_graph dt binding support for panel device
> and also keeps the backward compatibility.
>
> i.e.,
> The dts file for Exynos5800 based peach pi board
> has a panel property so we need to keep the backward compatibility.
>
> Changelog v2:
> - return -EINVAL if getting a port node failed.
>
> Signed-off-by: Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 94f02a0..0b53045 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
> static int exynos_dp_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> - struct device_node *panel_node, *bridge_node, *endpoint;
> + struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
> struct exynos_dp_device *dp;
> int ret;
>
> @@ -1403,15 +1403,32 @@ static int exynos_dp_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, dp);
>
> + /* This is for the backward compatibility. */
> panel_node = of_parse_phandle(dev->of_node, "panel", 0);
> if (panel_node) {
> dp->panel = of_drm_find_panel(panel_node);
> of_node_put(panel_node);
> if (!dp->panel)
> return -EPROBE_DEFER;
> + } else {
> + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> + if (endpoint) {
> + panel_node = of_graph_get_remote_port_parent(endpoint);
> + if (panel_node) {
> + dp->panel = of_drm_find_panel(panel_node);
> + of_node_put(panel_node);
> + if (!dp->panel)
> + return -EPROBE_DEFER;
> + } else {
> + DRM_ERROR("no port node for panel device.\n");
> + return -EINVAL;
> + }
> + }
> }
>
> - endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> + panel_node = !endpoint ? NULL : panel_node;
> +
> + endpoint = of_graph_get_next_endpoint(dev->of_node, panel_node);
> if (endpoint) {
> bridge_node = of_graph_get_remote_port_parent(endpoint);
> if (bridge_node) {
>
[PATCH] drm/exynos: dsi: modify a error type when getting a node failed
This patch makes it to return -EINVAL instead of -ENXIO
when getting a port or endpoint node failed.
Signed-off-by: Inki Dae
---
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 7c3606a..a24bf8b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1735,13 +1735,13 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
ep = of_graph_get_next_endpoint(node, NULL);
if (!ep) {
- ret = -ENXIO;
+ ret = -EINVAL;
goto end;
}
dsi->bridge_node = of_graph_get_remote_port_parent(ep);
if (!dsi->bridge_node) {
- ret = -ENXIO;
+ ret = -EINVAL;
goto end;
}
end:
--
1.9.1
[PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel
Hi Javier, 2015ë 12ì 03ì¼ 00:04ì Javier Martinez Canillas ì´(ê°) ì´ ê¸: > Hello Inki, > > On 12/02/2015 08:57 AM, Inki Dae wrote: >> This patch adds of_graph dt binding support for panel device >> and also keeps the backward compatibility. >> > > You have to also update the DT binding doc which seems to be > outdated already: > > Documentation/devicetree/bindings/display/exynos/exynos_dp.txt Right. It should be updated. > >> i.e., >> The dts file for Exynos5800 based peach pi board >> has a panel property so we need to keep the backward compatibility. >> > > How did you test this patch? I thought you will test it and give me tested-by because you commented like below, " Assuming you can make a distinction if the endpoint is a panel or a bridge, then yes, I agree with the idea of the patch. Please feel free to cc me if you post such a patch and I'll gladly test it on my Exynos5800 Peach Pi." That is why I cced you. I really have no any Exynos5800 Peach Pi board. Thanks, Inki Dae > > Best regards, >
[PATCH v2 2/2] drm/exynos: dp: fix wrong return type
This patch fixes wrong return type when dt binding of bridge device
failed.
If a board has a bridge device then of_graph_get_remote_port_parent
function shouldn't be NULL. So this patch will return a proper error
type so that the deferred probe isn't triggered.
Changelog v2:
- return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 0b53045..c77fb83 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1436,8 +1436,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
of_node_put(bridge_node);
if (!dp->ptn_bridge)
return -EPROBE_DEFER;
- } else
- return -EPROBE_DEFER;
+ } else {
+ DRM_ERROR("no port node for bridge device.\n");
+ return -EINVAL;
+ }
}
pm_runtime_enable(dev);
--
1.9.1
[PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel
This patch adds of_graph dt binding support for panel device
and also keeps the backward compatibility.
i.e.,
The dts file for Exynos5800 based peach pi board
has a panel property so we need to keep the backward compatibility.
Changelog v2:
- return -EINVAL if getting a port node failed.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 94f02a0..0b53045 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct device_node *panel_node, *bridge_node, *endpoint;
+ struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
struct exynos_dp_device *dp;
int ret;
@@ -1403,15 +1403,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dp);
+ /* This is for the backward compatibility. */
panel_node = of_parse_phandle(dev->of_node, "panel", 0);
if (panel_node) {
dp->panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
if (!dp->panel)
return -EPROBE_DEFER;
+ } else {
+ endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (endpoint) {
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ if (panel_node) {
+ dp->panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (!dp->panel)
+ return -EPROBE_DEFER;
+ } else {
+ DRM_ERROR("no port node for panel device.\n");
+ return -EINVAL;
+ }
+ }
}
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ panel_node = !endpoint ? NULL : panel_node;
+
+ endpoint = of_graph_get_next_endpoint(dev->of_node, panel_node);
if (endpoint) {
bridge_node = of_graph_get_remote_port_parent(endpoint);
if (bridge_node) {
--
1.9.1
[PATCH 2/2] drm/exynos: dp: fix wrong return type
Hi Javier,
2015ë
11ì 26ì¼ 22:35ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> [adding Ajay Kumar who added the bridge support]
>
> Hello Inki,
>
> On 11/26/2015 09:47 AM, Inki Dae wrote:
>> This patch fixes wrong return type when dt binding of bridge device
>> failed.
>>
>> If a board has a bridge device then of_graph_get_remote_port_parent
>> function shouldn't be NULL. So this patch will return a proper error
>> type so that the deferred probe isn't triggered.
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 0b53045..c77fb83 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1436,8 +1436,10 @@ static int exynos_dp_probe(struct platform_device
>> *pdev)
>> of_node_put(bridge_node);
>> if (!dp->ptn_bridge)
>> return -EPROBE_DEFER;
>> -} else
>> -return -EPROBE_DEFER;
>> +} else {
>> +DRM_ERROR("no port node for bridge device.\n");
>> +return -ENXIO;
>> +}
>> }
>>
>
> As I mentioned in the other thread, I wonder if -ENXIO is the best errno
> code in this case. Shouldn't -EINVAL be more appropriate since is about
> an invalid DTB?
Seems better to use -EINVAL.
Thanks,
Inki Dae
>
>> pm_runtime_enable(dev);
>>
>
> Best regards,
>
[PATCH] drm/exynos: simplify sleep PM ops
Hi Andrzej,
2015ë
11ì 27ì¼ 23:32ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> PM ops in exynos_drm_drv were split into two separate function as they were
> used also by drm device. Since PM ops have been removed from drm device, the
> functions can be merged together.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki,
>
> This is the patch I have promised during our discussion about
> PM callbcks in components.
Thanks for your patch. I will check it.
Thanks,
Inki Dae
>
> Regards
> Andrzej
>
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 76
> +
> 1 file changed, 30 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 2c6019d..9756797a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -304,45 +304,6 @@ int exynos_atomic_commit(struct drm_device *dev, struct
> drm_atomic_state *state,
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
> -{
> - struct drm_connector *connector;
> -
> - drm_modeset_lock_all(dev);
> - list_for_each_entry(connector, >mode_config.connector_list, head) {
> - int old_dpms = connector->dpms;
> -
> - if (connector->funcs->dpms)
> - connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
> -
> - /* Set the old mode back to the connector for resume */
> - connector->dpms = old_dpms;
> - }
> - drm_modeset_unlock_all(dev);
> -
> - return 0;
> -}
> -
> -static int exynos_drm_resume(struct drm_device *dev)
> -{
> - struct drm_connector *connector;
> -
> - drm_modeset_lock_all(dev);
> - list_for_each_entry(connector, >mode_config.connector_list, head) {
> - if (connector->funcs->dpms) {
> - int dpms = connector->dpms;
> -
> - connector->dpms = DRM_MODE_DPMS_OFF;
> - connector->funcs->dpms(connector, dpms);
> - }
> - }
> - drm_modeset_unlock_all(dev);
> -
> - return 0;
> -}
> -#endif
> -
> static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
> {
> struct drm_exynos_file_private *file_priv;
> @@ -476,31 +437,54 @@ static struct drm_driver exynos_drm_driver = {
> };
>
> #ifdef CONFIG_PM_SLEEP
> -static int exynos_drm_sys_suspend(struct device *dev)
> +static int exynos_drm_suspend(struct device *dev)
> {
> struct drm_device *drm_dev = dev_get_drvdata(dev);
> - pm_message_t message;
> + struct drm_connector *connector;
>
> if (pm_runtime_suspended(dev) || !drm_dev)
> return 0;
>
> - message.event = PM_EVENT_SUSPEND;
> - return exynos_drm_suspend(drm_dev, message);
> + drm_modeset_lock_all(drm_dev);
> + drm_for_each_connector(connector, drm_dev) {
> + int old_dpms = connector->dpms;
> +
> + if (connector->funcs->dpms)
> + connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
> +
> + /* Set the old mode back to the connector for resume */
> + connector->dpms = old_dpms;
> + }
> + drm_modeset_unlock_all(drm_dev);
> +
> + return 0;
> }
>
> -static int exynos_drm_sys_resume(struct device *dev)
> +static int exynos_drm_resume(struct device *dev)
> {
> struct drm_device *drm_dev = dev_get_drvdata(dev);
> + struct drm_connector *connector;
>
> if (pm_runtime_suspended(dev) || !drm_dev)
> return 0;
>
> - return exynos_drm_resume(drm_dev);
> + drm_modeset_lock_all(drm_dev);
> + drm_for_each_connector(connector, drm_dev) {
> + if (connector->funcs->dpms) {
> + int dpms = connector->dpms;
> +
> + connector->dpms = DRM_MODE_DPMS_OFF;
> + connector->funcs->dpms(connector, dpms);
> + }
> + }
> + drm_modeset_unlock_all(drm_dev);
> +
> + return 0;
> }
> #endif
>
> static const struct dev_pm_ops exynos_drm_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_sys_suspend, exynos_drm_sys_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_suspend, exynos_drm_resume)
> };
>
> /* forward declaration */
>
[PATCH 2/2] drm/exynos: dp: fix wrong return type
This patch fixes wrong return type when dt binding of bridge device
failed.
If a board has a bridge device then of_graph_get_remote_port_parent
function shouldn't be NULL. So this patch will return a proper error
type so that the deferred probe isn't triggered.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 0b53045..c77fb83 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1436,8 +1436,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
of_node_put(bridge_node);
if (!dp->ptn_bridge)
return -EPROBE_DEFER;
- } else
- return -EPROBE_DEFER;
+ } else {
+ DRM_ERROR("no port node for bridge device.\n");
+ return -ENXIO;
+ }
}
pm_runtime_enable(dev);
--
1.9.1
[PATCH 1/2] drm/exynos: dp: add of_graph dt binding support for panel
This patch adds of_graph dt binding support for panel device
and also keeps the backward compatibility.
i.e.,
The dts file for Exynos5800 based peach pi board
has a panel property so we need to keep the backward compatibility.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 94f02a0..0b53045 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct device_node *panel_node, *bridge_node, *endpoint;
+ struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
struct exynos_dp_device *dp;
int ret;
@@ -1403,15 +1403,32 @@ static int exynos_dp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dp);
+ /* This is for the backward compatibility. */
panel_node = of_parse_phandle(dev->of_node, "panel", 0);
if (panel_node) {
dp->panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
if (!dp->panel)
return -EPROBE_DEFER;
+ } else {
+ endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (endpoint) {
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ if (panel_node) {
+ dp->panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (!dp->panel)
+ return -EPROBE_DEFER;
+ } else {
+ DRM_ERROR("no port node for panel device.\n");
+ return -ENXIO;
+ }
+ }
}
- endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
+ panel_node = !endpoint ? NULL : panel_node;
+
+ endpoint = of_graph_get_next_endpoint(dev->of_node, panel_node);
if (endpoint) {
bridge_node = of_graph_get_remote_port_parent(endpoint);
if (bridge_node) {
--
1.9.1
[PATCH 0/2] drm/exynos: dp: add of_graph dt binding for panel device
This patch series adds of_graph dt binding for panel device and fixes wrong return type when the dt binding of bridge device failed. Inki Dae (2): drm/exynos: dp: add of_graph dt binding support for panel drm/exynos: dp: fix wrong return type drivers/gpu/drm/exynos/exynos_dp_core.c | 27 +++ 1 file changed, 23 insertions(+), 4 deletions(-) -- 1.9.1
[PATCH v3] drm/exynos: add pm_runtime to Mixer
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Changelog v3:
- revive MXR_BIT_POWERED flag to keep current dpms mode.
Changelog v2:
- no change
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_mixer.c | 106 --
1 file changed, 64 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d09f8f9..4be 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1020,43 +1020,12 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc->ctx;
struct mixer_resources *res = >mixer_res;
- int ret;
if (test_bit(MXR_BIT_POWERED, >flags))
return;
pm_runtime_get_sync(ctx->dev);
- ret = clk_prepare_enable(res->mixer);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the mixer clk [%d]\n", ret);
- return;
- }
- ret = clk_prepare_enable(res->hdmi);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
- return;
- }
- if (ctx->vp_enabled) {
- ret = clk_prepare_enable(res->vp);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the vp clk [%d]\n",
- ret);
- return;
- }
- if (ctx->has_sclk) {
- ret = clk_prepare_enable(res->sclk_mixer);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the " \
- "sclk_mixer clk [%d]\n",
- ret);
- return;
- }
- }
- }
-
- set_bit(MXR_BIT_POWERED, >flags);
-
mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);
if (test_bit(MXR_BIT_VSYNC, >flags)) {
@@ -1064,12 +1033,13 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
mixer_reg_writemask(res, MXR_INT_EN, ~0, MXR_INT_EN_VSYNC);
}
mixer_win_reset(ctx);
+
+ set_bit(MXR_BIT_POWERED, >flags);
}
static void mixer_disable(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc->ctx;
- struct mixer_resources *res = >mixer_res;
int i;
if (!test_bit(MXR_BIT_POWERED, >flags))
@@ -1081,17 +1051,9 @@ static void mixer_disable(struct exynos_drm_crtc *crtc)
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_disable_plane(crtc, >planes[i]);
- clear_bit(MXR_BIT_POWERED, >flags);
+ pm_runtime_put(ctx->dev);
- clk_disable_unprepare(res->hdmi);
- clk_disable_unprepare(res->mixer);
- if (ctx->vp_enabled) {
- clk_disable_unprepare(res->vp);
- if (ctx->has_sclk)
- clk_disable_unprepare(res->sclk_mixer);
- }
-
- pm_runtime_put_sync(ctx->dev);
+ clear_bit(MXR_BIT_POWERED, >flags);
}
/* Only valid for Mixer version 16.0.33.0 */
@@ -1293,10 +1255,70 @@ static int mixer_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int exynos_mixer_suspend(struct device *dev)
+{
+ struct mixer_context *ctx = dev_get_drvdata(dev);
+ struct mixer_resources *res = >mixer_res;
+
+ clk_disable_unprepare(res->hdmi);
+ clk_disable_unprepare(res->mixer);
+ if (ctx->vp_enabled) {
+ clk_disable_unprepare(res->vp);
+ if (ctx->has_sclk)
+ clk_disable_unprepare(res->sclk_mixer);
+ }
+
+ return 0;
+}
+
+static int exynos_mixer_resume(struct device *dev)
+{
+ struct mixer_context *ctx = dev_get_drvdata(dev);
+ struct mixer_resources *res = >mixer_res;
+ int ret;
+
+ ret = clk_prepare_enable(res->mixer);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the mixer clk [%d]\n", ret);
+ return ret;
+ }
+ ret = clk_prepare_enable(res->hdmi);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
+ return ret;
+ }
+ if (ctx->vp_enabled) {
+ ret = clk_prepare_enable(res->vp);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the vp clk [%d]\n",
+ ret);
+
[PATCH v3] drm/exynos: add pm_runtime to HDMI
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Changelog v3:
- revive powered flag to keep current dpms mode
Changelog v2:
- Mofidy CONFIG_PM_SLEEP -> CONFIG_PM
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 49 +---
1 file changed, 40 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 57b6755..9a955d2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -113,7 +113,7 @@ struct hdmi_context {
void __iomem*regs_hdmiphy;
struct i2c_client *hdmiphy_port;
struct i2c_adapter *ddc_adpt;
- struct gpio_desc*hpd_gpio;
+ struct gpio_desc*hpd_gpio;
int irq;
struct regmap *pmureg;
struct clk *hdmi;
@@ -1588,8 +1588,6 @@ static void hdmi_enable(struct drm_encoder *encoder)
if (hdata->powered)
return;
- hdata->powered = true;
-
pm_runtime_get_sync(hdata->dev);
if (regulator_bulk_enable(ARRAY_SIZE(supply), hdata->regul_bulk))
@@ -1599,10 +1597,9 @@ static void hdmi_enable(struct drm_encoder *encoder)
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 1);
- clk_prepare_enable(hdata->hdmi);
- clk_prepare_enable(hdata->sclk_hdmi);
-
hdmi_conf_apply(hdata);
+
+ hdata->powered = true;
}
static void hdmi_disable(struct drm_encoder *encoder)
@@ -1633,9 +1630,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
cancel_delayed_work(>hotplug_work);
- clk_disable_unprepare(hdata->sclk_hdmi);
- clk_disable_unprepare(hdata->hdmi);
-
/* reset pmu hdmiphy control bit to disable hdmiphy */
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);
@@ -1978,12 +1972,49 @@ static int hdmi_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int exynos_hdmi_suspend(struct device *dev)
+{
+ struct hdmi_context *hdata = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(hdata->sclk_hdmi);
+ clk_disable_unprepare(hdata->hdmi);
+
+ return 0;
+}
+
+static int exynos_hdmi_resume(struct device *dev)
+{
+ struct hdmi_context *hdata = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(hdata->hdmi);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
+ return ret;
+ }
+ ret = clk_prepare_enable(hdata->sclk_hdmi);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the sclk_mixer clk [%d]\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_hdmi_pm_ops = {
+ SET_RUNTIME_PM_OPS(exynos_hdmi_suspend, exynos_hdmi_resume, NULL)
+};
+
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
.remove = hdmi_remove,
.driver = {
.name = "exynos-hdmi",
.owner = THIS_MODULE,
+ .pm = _hdmi_pm_ops,
.of_match_table = hdmi_match_types,
},
};
--
1.9.1
[PATCH v3] drm/exynos: add pm_runtime to FIMD
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Chnagelog v3:
- Revive suspended varable to check the suspend status.
Changelog v2:
- Remove unnecessary changes which removed commit callback from decon drivers
and modify CONFIG_PM_SLEEP -> CONFIG_PM
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 ++--
1 file changed, 37 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bd75c15..2c38323 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -745,7 +745,6 @@ static void fimd_disable_plane(struct exynos_drm_crtc *crtc,
static void fimd_enable(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc->ctx;
- int ret;
if (!ctx->suspended)
return;
@@ -754,18 +753,6 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx->dev);
- ret = clk_prepare_enable(ctx->bus_clk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the bus clk [%d]\n", ret);
- return;
- }
-
- ret = clk_prepare_enable(ctx->lcd_clk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the lcd clk [%d]\n", ret);
- return;
- }
-
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, >irq_flags))
fimd_enable_vblank(ctx->crtc);
@@ -795,11 +782,7 @@ static void fimd_disable(struct exynos_drm_crtc *crtc)
writel(0, ctx->regs + VIDCON0);
- clk_disable_unprepare(ctx->lcd_clk);
- clk_disable_unprepare(ctx->bus_clk);
-
pm_runtime_put_sync(ctx->dev);
-
ctx->suspended = true;
}
@@ -1121,12 +1104,49 @@ static int fimd_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int exynos_fimd_suspend(struct device *dev)
+{
+ struct fimd_context *ctx = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(ctx->lcd_clk);
+ clk_disable_unprepare(ctx->bus_clk);
+
+ return 0;
+}
+
+static int exynos_fimd_resume(struct device *dev)
+{
+ struct fimd_context *ctx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(ctx->bus_clk);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the bus clk [%d]\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ctx->lcd_clk);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the lcd clk [%d]\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_fimd_pm_ops = {
+ SET_RUNTIME_PM_OPS(exynos_fimd_suspend, exynos_fimd_resume, NULL)
+};
+
struct platform_driver fimd_driver = {
.probe = fimd_probe,
.remove = fimd_remove,
.driver = {
.name = "exynos4-fb",
.owner = THIS_MODULE,
+ .pm = _fimd_pm_ops,
.of_match_table = fimd_driver_dt_match,
},
};
--
1.9.1
[PATCH v3] drm/exynos: add pm_runtime to DP
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.
Chnagelog v3:
- revive dpms_mode to keep current dpms mode.
Changelog v2:
- no change
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 51 +++--
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index e4d32a1..94f02a0 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1061,6 +1061,8 @@ static void exynos_dp_bridge_enable(struct drm_bridge
*bridge)
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;
+ pm_runtime_get_sync(dp->dev);
+
if (dp->panel) {
if (drm_panel_prepare(dp->panel)) {
DRM_ERROR("failed to setup the panel\n");
@@ -1071,7 +1073,6 @@ static void exynos_dp_bridge_enable(struct drm_bridge
*bridge)
if (crtc->ops->clock_enable)
crtc->ops->clock_enable(dp_to_crtc(dp), true);
- clk_prepare_enable(dp->clock);
phy_power_on(dp->phy);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
@@ -1098,7 +1099,6 @@ static void exynos_dp_bridge_disable(struct drm_bridge
*bridge)
disable_irq(dp->irq);
flush_work(>hotplug_work);
phy_power_off(dp->phy);
- clk_disable_unprepare(dp->clock);
if (crtc->ops->clock_enable)
crtc->ops->clock_enable(dp_to_crtc(dp), false);
@@ -1108,6 +1108,8 @@ static void exynos_dp_bridge_disable(struct drm_bridge
*bridge)
DRM_ERROR("failed to turnoff the panel\n");
}
+ pm_runtime_put_sync(dp->dev);
+
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
@@ -1392,6 +1394,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct device_node *panel_node, *bridge_node, *endpoint;
struct exynos_dp_device *dp;
+ int ret;
dp = devm_kzalloc(>dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
@@ -1420,16 +1423,57 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
- return component_add(>dev, _dp_ops);
+ pm_runtime_enable(dev);
+
+ ret = component_add(>dev, _dp_ops);
+ if (ret)
+ goto err_disable_pm_runtime;
+
+ return ret;
+
+err_disable_pm_runtime:
+ pm_runtime_disable(dev);
+
+ return ret;
}
static int exynos_dp_remove(struct platform_device *pdev)
{
+ pm_runtime_disable(>dev);
component_del(>dev, _dp_ops);
return 0;
}
+#ifdef CONFIG_PM
+static int exynos_dp_suspend(struct device *dev)
+{
+ struct exynos_dp_device *dp = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(dp->clock);
+
+ return 0;
+}
+
+static int exynos_dp_resume(struct device *dev)
+{
+ struct exynos_dp_device *dp = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(dp->clock);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_dp_pm_ops = {
+ SET_RUNTIME_PM_OPS(exynos_dp_suspend, exynos_dp_resume, NULL)
+};
+
static const struct of_device_id exynos_dp_match[] = {
{ .compatible = "samsung,exynos5-dp" },
{},
@@ -1442,6 +1486,7 @@ struct platform_driver dp_driver = {
.driver = {
.name = "exynos-dp",
.owner = THIS_MODULE,
+ .pm = _dp_pm_ops,
.of_match_table = exynos_dp_match,
},
};
--
1.9.1
[PATCH v3] drm/exynos: add pm_runtime to DECON 7
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.
Changelog v3:
- revive suspended to keep current dpms mode
Changelog v2:
- Modify CONFIG_PM_SLEEP -> CONFIG_PM
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 93 ++
1 file changed, 55 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ead2b16..38d7762 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -119,13 +119,8 @@ static void decon_clear_channels(struct exynos_drm_crtc
*crtc)
}
/* Wait for vsync, as disable channel takes effect at next vsync */
- if (ch_enabled) {
- unsigned int state = ctx->suspended;
-
- ctx->suspended = 0;
+ if (ch_enabled)
decon_wait_for_vblank(ctx->crtc);
- ctx->suspended = state;
- }
}
static int decon_ctx_initialize(struct decon_context *ctx,
@@ -555,39 +550,12 @@ static void decon_init(struct decon_context *ctx)
static void decon_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
- int ret;
if (!ctx->suspended)
return;
- ctx->suspended = false;
-
pm_runtime_get_sync(ctx->dev);
- ret = clk_prepare_enable(ctx->pclk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the pclk [%d]\n", ret);
- return;
- }
-
- ret = clk_prepare_enable(ctx->aclk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the aclk [%d]\n", ret);
- return;
- }
-
- ret = clk_prepare_enable(ctx->eclk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the eclk [%d]\n", ret);
- return;
- }
-
- ret = clk_prepare_enable(ctx->vclk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the vclk [%d]\n", ret);
- return;
- }
-
decon_init(ctx);
/* if vblank was enabled status, enable it again. */
@@ -595,6 +563,8 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
decon_enable_vblank(ctx->crtc);
decon_commit(ctx->crtc);
+
+ ctx->suspended = false;
}
static void decon_disable(struct exynos_drm_crtc *crtc)
@@ -613,11 +583,6 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
for (i = 0; i < WINDOWS_NR; i++)
decon_disable_plane(crtc, >planes[i]);
- clk_disable_unprepare(ctx->vclk);
- clk_disable_unprepare(ctx->eclk);
- clk_disable_unprepare(ctx->aclk);
- clk_disable_unprepare(ctx->pclk);
-
pm_runtime_put_sync(ctx->dev);
ctx->suspended = true;
@@ -843,11 +808,63 @@ static int decon_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int exynos7_decon_suspend(struct device *dev)
+{
+ struct decon_context *ctx = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(ctx->vclk);
+ clk_disable_unprepare(ctx->eclk);
+ clk_disable_unprepare(ctx->aclk);
+ clk_disable_unprepare(ctx->pclk);
+
+ return 0;
+}
+
+static int exynos7_decon_resume(struct device *dev)
+{
+ struct decon_context *ctx = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(ctx->pclk);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the pclk [%d]\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ctx->aclk);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the aclk [%d]\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ctx->eclk);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the eclk [%d]\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(ctx->vclk);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the vclk [%d]\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos7_decon_pm_ops = {
+ SET_RUNTIME_PM_OPS(exynos7_decon_suspend, exynos7_decon_resume,
+ NULL)
+};
+
struct platform_driver decon_driver = {
.probe = decon_probe,
.remove = decon_remove,
.driver = {
.name = "exynos-decon",
+ .pm = _decon_pm_ops,
.of_match_table = decon_driver_dt_match,
},
};
--
1.9.1
[PATCH v2 1/5] drm/exynos: mixer: refactor layer setup
2015-11-24 2:44 GMT+09:00 Tobias Jakobi :
> Hey Inki,
>
>
> Inki Dae wrote:
>> Hi Tobias,
>>
>> 2015ë
11ì 23ì¼ 01:09ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> First step in allowing a more generic way to setup complex
>>> blending for the different layers.
>>>
>>> Signed-off-by: Tobias Jakobi
>>> ---
>>> drivers/gpu/drm/exynos/exynos_mixer.c | 84
>>> ++-
>>> 1 file changed, 73 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 7498c6e..2c1cea3 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -63,6 +63,11 @@ struct mixer_resources {
>>> struct clk *mout_mixer;
>>> };
>>>
>>> +struct layer_cfg {
>>> +unsigned int index;
>>> +unsigned int priority;
>>> +};
>>> +
>>> enum mixer_version_id {
>>> MXR_VER_0_0_0_16,
>>> MXR_VER_16_0_33_0,
>>> @@ -92,6 +97,8 @@ struct mixer_context {
>>> struct drm_device *drm_dev;
>>> struct exynos_drm_crtc *crtc;
>>> struct exynos_drm_plane planes[MIXER_WIN_NR];
>>> +const struct layer_cfg *layer_cfg;
>>> +unsigned intnum_layer;
>>> int pipe;
>>> unsigned long flags;
>>> boolinterlace;
>>> @@ -110,6 +117,34 @@ struct mixer_drv_data {
>>> boolhas_sclk;
>>> };
>>>
>>> +/*
>>> + * The default layer priorities for non-VP (video processor)
>>> + * and VP mixer configurations.
>>> + *
>>> + * A higher priority means that the layer is at the top of
>>> + * the layer stack.
>>> + * Configurations have to be specified with its entries
>>> + * sorted with increasing priority.
>>> + *
>>> + * The default config assumes the following usage scenario:
>>> + * layer1: OSD [top]
>>> + * layer0: main framebuffer
>>> + * video layer: video overlay [bottom]
>>> + * Note that the video layer is only usable when the
>>> + * VP is available.
>>> + */
>>> +
>>> +static const struct layer_cfg nonvp_default_cfg[] = {
>>> +{ .index = 0, .priority = 1 }, /* layer0 */
>>> +{ .index = 1, .priority = 2 }, /* layer1 */
>>> +};
>>> +
>>> +static const struct layer_cfg vp_default_cfg[] = {
>>> +{ .index = 2, .priority = 1 }, /* video layer */
>>> +{ .index = 0, .priority = 2 }, /* layer0 */
>>> +{ .index = 1, .priority = 3 }, /* layer1 */
>>> +};
>>> +
>>> static const u8 filter_y_horiz_tap8[] = {
>>> 0, -1, -1, -1, -1, -1, -1, -1,
>>> -1, -1, -1, -1, -1, 0, 0, 0,
>>> @@ -268,6 +303,34 @@ static void vp_default_filter(struct mixer_resources
>>> *res)
>>> filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
>>> }
>>>
>>> +static void mixer_layer_priority(struct mixer_context *ctx)
>>> +{
>>> +u32 val = 0;
>>> +unsigned int i, priority;
>>> +
>>> +for (i = 0; i < ctx->num_layer; ++i) {
>>> +priority = ctx->layer_cfg[i].priority;
>>> +BUG_ON(priority > 15);
>>
>> What doesn constant, 15 mean? You need to clarify the meaning
>> and please, use a macro instead.
> If I read the specs correctly the layer priority is encoded with just
> 4-bits in the corresponding register. I'll add a define to make this
> more clear.
Please use a macro instead of 15.
>
>
>> And it'd better to just return in this case so that the layer
>> configuration can be set with a default value.
> The point is that these (currently) are the default values that
> mixer_layer_priority() sets.
> The BUG_ON() is there to make sure that nobody changes
> {vp,nonvp}_default_cfg[] later with illegal values.
Please, know that BUG_ON is very strong macro so kernel will be halt.
By any chance, if someone changed the definitions, then it'd be better
to return error
so that other devices could work correctly.
Thanks,
Inki Dae
>
>
> With best wishes,
> Tobias
>
>
>> I think it'd be enough to print out warning message.
>
[PATCH v2 2/5] drm/exynos: mixer: introduce mixer_layer_blending()
2015-11-24 2:44 GMT+09:00 Tobias Jakobi :
> Hey Inki,
>
>
> Inki Dae wrote:
>>
>>
>> 2015ë
11ì 23ì¼ 01:09ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> This analyses the current layer configuration (which layers
>>> are enabled, which have alpha-pixelformat, etc.) and setups
>>> blending accordingly.
>>>
>>> We currently disable all kinds of blending for the bottom-most
>>> layer, since configuration of the mixer background is not
>>> yet exposed.
>>> Also blending is only enabled when the layer has a pixelformat
>>> with alpha attached.
>>>
>>> Signed-off-by: Tobias Jakobi
>>> ---
>>> drivers/gpu/drm/exynos/exynos_mixer.c | 88
>>> +++
>>> drivers/gpu/drm/exynos/regs-mixer.h | 1 +
>>> 2 files changed, 89 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 2c1cea3..ec77aad 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -174,6 +174,21 @@ static const u8 filter_cr_horiz_tap4[] = {
>>> 70, 59, 48, 37, 27, 19, 11, 5,
>>> };
>>>
>>> +static inline bool is_alpha_format(const struct mixer_context* ctx,
>>> unsigned int win)
>>> +{
>>> +const struct drm_plane_state *state = ctx->planes[win].base.state;
>>> +const struct drm_framebuffer *fb = state->fb;
>>> +
>>> +switch (fb->pixel_format) {
>>> +case DRM_FORMAT_ARGB:
>>> +case DRM_FORMAT_ARGB1555:
>>> +case DRM_FORMAT_ARGB:
>>> +return true;
>>> +default:
>>> +return false;
>>> +}
>>> +}
>>> +
>>> static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
>>> {
>>> return readl(res->vp_regs + reg_id);
>>> @@ -331,6 +346,79 @@ static void mixer_layer_priority(struct mixer_context
>>> *ctx)
>>> mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
>>> }
>>>
>>> +/* Configure blending for bottom-most layer. */
>>> +static void mixer_bottom_layer(struct mixer_context *ctx,
>>> +const struct layer_cfg *cfg)
>>> +{
>>> +u32 val;
>>> +struct mixer_resources *res = >mixer_res;
>>> +
>>> +if (cfg->index == 2) {
>>> +val = 0; /* use defaults for video layer */
>>> +mixer_reg_write(res, MXR_VIDEO_CFG, val);
>>> +} else {
>>> +val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
>>> +
>>> +/* Don't blend bottom-most layer onto the mixer background. */
>>> +mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index),
>>> +val, MXR_GRP_CFG_MISC_MASK);
>>> +}
>>> +}
>>> +
>>> +static void mixer_general_layer(struct mixer_context *ctx,
>>> +const struct layer_cfg *cfg)
>>> +{
>>> +u32 val;
>>> +struct mixer_resources *res = >mixer_res;
>>> +
>>> +if (is_alpha_format(ctx, cfg->index)) {
>>> +val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
>>> +val |= MXR_GRP_CFG_BLEND_PRE_MUL;
>>> +val |= MXR_GRP_CFG_PIXEL_BLEND_EN; /* blending based on pixel
>>> alpha */
>>> +
>>> +/* The video layer never has an alpha pixelformat. */
>>
>> Looks like above comment isn't related to graphics layer.
> Why do you think so? Because it certainly is.
Below line configures graphics layer not video layer. Why did you
comment it about video layer?
>
>
>>> +mixer_reg_writemask(res, MXR_GRAPHIC_CFG(cfg->index),
>>> +val, MXR_GRP_CFG_MISC_MASK);
>>> +} else {
>>> +if (cfg->index == 2) {
>>> +/*
>>> + * No blending at the moment since the NV12/NV21
>>> pixelformats don't
>>> + * have an alpha channel. However the mixer supports a
>>> global alpha
>>> + * value for a layer. Once this functionality is
>>> exposed, we can
>>> + * support blending of the video layer through this.
>>> + */
>>> +
[PATCH v2 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()
2015-11-24 2:44 GMT+09:00 Tobias Jakobi :
> Hey Inki,
>
>
> Inki Dae wrote:
>>
>>
>> 2015ë
11ì 23ì¼ 01:09ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> This updates the blending setup when the layer configuration
>>> changes (triggered by mixer_win_{commit,disable}).
>>>
>>> To avoid unnecesary reconfigurations we cache the layer
>>> state in the mixer context.
>>>
>>> Extra care has to be taken for the layer that is currently
>>> being enabled/disabled.
>>>
>>> Signed-off-by: Tobias Jakobi
>>> ---
>>> drivers/gpu/drm/exynos/exynos_mixer.c | 41
>>> +--
>>> 1 file changed, 39 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index ec9659e..1c24fb5 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -99,6 +99,7 @@ struct mixer_context {
>>> struct exynos_drm_plane planes[MIXER_WIN_NR];
>>> const struct layer_cfg *layer_cfg;
>>> unsigned intnum_layer;
>>> +u32 layer_state;
>>> int pipe;
>>> unsigned long flags;
>>> boolinterlace;
>>> @@ -189,6 +190,27 @@ static inline bool is_alpha_format(const struct
>>> mixer_context* ctx, unsigned int
>>> }
>>> }
>>>
>>> +static inline u32 get_layer_state(const struct mixer_context *ctx,
>>> +unsigned int win, bool enable)
>>> +{
>>> +u32 enable_state, alpha_state;
>>> +
>>> +enable_state = ctx->layer_state & 0x;
>>> +alpha_state = ctx->layer_state >> 16;
>>> +
>>> +if (enable)
>>> +enable_state |= (1 << win);
>>> +else
>>> +enable_state &= ~(1 << win);
>>> +
>>> +if (enable && is_alpha_format(ctx, win))
>>> +alpha_state |= (1 << win);
>>> +else
>>> +alpha_state &= ~(1 << win);
>>> +
>>> +return ((alpha_state << 16) | enable_state);
>>> +}
>>> +
>>> static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
>>> {
>>> return readl(res->vp_regs + reg_id);
>>> @@ -370,8 +392,9 @@ static void mixer_general_layer(struct mixer_context
>>> *ctx,
>>> {
>>> u32 val;
>>> struct mixer_resources *res = >mixer_res;
>>> +const u32 alpha_state = ctx->layer_state >> 16;
>>>
>>> -if (is_alpha_format(ctx, cfg->index)) {
>>> +if (alpha_state & (1 << cfg->index)) {
>>> val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
>>> val |= MXR_GRP_CFG_BLEND_PRE_MUL;
>>> val |= MXR_GRP_CFG_PIXEL_BLEND_EN; /* blending based on pixel
>>> alpha */
>>> @@ -397,10 +420,11 @@ static void mixer_general_layer(struct mixer_context
>>> *ctx,
>>> }
>>> }
>>>
>>> -static void mixer_layer_blending(struct mixer_context *ctx, unsigned int
>>> enable_state)
>>> +static void mixer_layer_blending(struct mixer_context *ctx)
>>> {
>>> unsigned int i, index;
>>> bool bottom_layer = false;
>>> +const u32 enable_state = ctx->layer_state & 0x;
>>>
>>> for (i = 0; i < ctx->num_layer; ++i) {
>>> index = ctx->layer_cfg[i].index;
>>> @@ -503,8 +527,19 @@ static void mixer_cfg_layer(struct mixer_context *ctx,
>>> unsigned int win,
>>> bool enable)
>>> {
>>> struct mixer_resources *res = >mixer_res;
>>> +u32 new_layer_state;
>>> u32 val = enable ? ~0 : 0;
>>>
>>> +new_layer_state = get_layer_state(ctx, win, enable);
>>> +if (new_layer_state == ctx->layer_state)
>>> +return;
>>> +
>>> +/*
>>> + * Update the layer state so that mixer_layer_blending()
>>> + * below can use it.
>>> + */
>>> +ctx->layer_state = new_layer_state;
>>
>> It may be trivial but I think it'd be better to move above line to most
>> bottom of this function.
> Sure, I can do that, but I would rather know what's the rationale here.
Very simple. Above line sets layer_state to new_layer_state logically
but physically not.
So it'd be reasonable to update layer state after physically setting
the mixer layer.
Thanks,
Inki Dae
>
>
> With best wishes,
> Tobias
>
>>> +
>>> switch (win) {
>>> case 0:
>>> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
>>> @@ -520,6 +555,8 @@ static void mixer_cfg_layer(struct mixer_context *ctx,
>>> unsigned int win,
>>> }
>>> break;
>>> }
>>> +
>>> +mixer_layer_blending(ctx);
>>
>> Here.
>>
>> Thanks,
>> Inki Dae
>>
>>> }
>>>
>>> static void mixer_run(struct mixer_context *ctx)
>>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] drm/exynos: add pm runtime support
Hi Javier,
2015-11-24 22:19 GMT+09:00 Javier Martinez Canillas :
> Hello Inki,
>
> On 11/23/2015 11:28 PM, Inki Dae wrote:
>> Hi Javier,
>>
>> 2015ë
11ì 24ì¼ 03:38ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
>>> Hello Inki,
>>>
>>> On 11/23/2015 01:47 PM, Inki Dae wrote:
>>>> 2015-11-23 21:25 GMT+09:00 Javier Martinez Canillas >>> osg.samsung.com>:
>>>>> Hello,
>>>>>
>>>>> On 11/21/2015 11:59 AM, Inki Dae wrote:
>>>>>> Hi Daniel,
>>>>>>
>>>>>>
>>>>>> 2015-11-21 22:40 GMT+09:00 Daniel Stone :
>>>>>>> Hi Inki,
>>>>>>>
>>>>>>> On 21 November 2015 at 09:38, Inki Dae wrote:
>>>>>>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas >>>>>>> osg.samsung.com>:
>>>>>>>>> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>>>>>>>>> The boot log says,
>>>>>>>>>> [5.754493] vdd_ldo9: supplied by vdd_2v
>>>>>>>>>> [5.765510] of_graph_get_next_endpoint(): no port node found in
>>>>>>>>>> /dp-controller at 145B
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This message is a red herring for the reported issue, the message is
>>>>>>>>> also
>>>>>>>>> present when the machine boots and the display is brought correctly.
>>>>>>>>>
>>>>>>>>>> Seems this error is because exynos5800-peach-pit.dts file doesn't
>>>>>>>>>> have 'ports' node in dp node.
>>>>>>>>>>
>>>>>>>>>> Below is dp node description of exynos5420-peach-pit.dts file.
>>>>>>>>>> {
>>>>>>>>>> status = "okay";
>>>>>>>>>> pinctrl-names = "default";
>>>>>>>>>> pinctrl-0 = <_hpd_gpio>;
>>>>>>>>>> samsung,color-space = <0>;
>>>>>>>>>> samsung,dynamic-range = <0>;
>>>>>>>>>> samsung,ycbcr-coeff = <0>;
>>>>>>>>>> samsung,color-depth = <1>;
>>>>>>>>>> samsung,link-rate = <0x06>;
>>>>>>>>>> samsung,lane-count = <2>;
>>>>>>>>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>>>>>
>>>>>>>>>> ports {
>>>>>>>>>> port at 0 {
>>>>>>>>>> dp_out: endpoint {
>>>>>>>>>> remote-endpoint = <_in>;
>>>>>>>>>> };
>>>>>>>>>> };
>>>>>>>>>> };
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> And below is for exynos5800-peash-pit.dts,
>>>>>>>>>> {
>>>>>>>>>> status = "okay";
>>>>>>>>>> pinctrl-names = "default";
>>>>>>>>>> pinctrl-0 = <_hpd_gpio>;
>>>>>>>>>> samsung,color-space = <0>;
>>>>>>>>>> samsung,dynamic-range = <0>;
>>>>>>>>>> samsung,ycbcr-coeff = <0>;
>>>>>>>>>> samsung,color-depth = <1>;
>>>>>>>>>> samsung,link-rate = <0x0a>;
>>>>>>>>>> samsung,lane-count = <2>;
>>>>>>>>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>>>>> panel = <>;
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The difference is because the Exynos5420 Peach Pit Display Port is not
>>>>>>>>> attached directly to the display panel, there is an eDP/LVDS bridge
>>>>>>>>> chip
>>>>>>>>> in the m
[PATCH v2 0/7] drm/exynos: add pm runtime support
Hi Javier,
2015ë
11ì 24ì¼ 03:38ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
>
> On 11/23/2015 01:47 PM, Inki Dae wrote:
>> 2015-11-23 21:25 GMT+09:00 Javier Martinez Canillas > osg.samsung.com>:
>>> Hello,
>>>
>>> On 11/21/2015 11:59 AM, Inki Dae wrote:
>>>> Hi Daniel,
>>>>
>>>>
>>>> 2015-11-21 22:40 GMT+09:00 Daniel Stone :
>>>>> Hi Inki,
>>>>>
>>>>> On 21 November 2015 at 09:38, Inki Dae wrote:
>>>>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas >>>>> osg.samsung.com>:
>>>>>>> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>>>>>>> The boot log says,
>>>>>>>> [5.754493] vdd_ldo9: supplied by vdd_2v
>>>>>>>> [5.765510] of_graph_get_next_endpoint(): no port node found in
>>>>>>>> /dp-controller at 145B
>>>>>>>>
>>>>>>>
>>>>>>> This message is a red herring for the reported issue, the message is
>>>>>>> also
>>>>>>> present when the machine boots and the display is brought correctly.
>>>>>>>
>>>>>>>> Seems this error is because exynos5800-peach-pit.dts file doesn't have
>>>>>>>> 'ports' node in dp node.
>>>>>>>>
>>>>>>>> Below is dp node description of exynos5420-peach-pit.dts file.
>>>>>>>> {
>>>>>>>> status = "okay";
>>>>>>>> pinctrl-names = "default";
>>>>>>>> pinctrl-0 = <_hpd_gpio>;
>>>>>>>> samsung,color-space = <0>;
>>>>>>>> samsung,dynamic-range = <0>;
>>>>>>>> samsung,ycbcr-coeff = <0>;
>>>>>>>> samsung,color-depth = <1>;
>>>>>>>> samsung,link-rate = <0x06>;
>>>>>>>> samsung,lane-count = <2>;
>>>>>>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>>>
>>>>>>>> ports {
>>>>>>>> port at 0 {
>>>>>>>> dp_out: endpoint {
>>>>>>>> remote-endpoint = <_in>;
>>>>>>>> };
>>>>>>>> };
>>>>>>>> };
>>>>>>>> };
>>>>>>>>
>>>>>>>> And below is for exynos5800-peash-pit.dts,
>>>>>>>> {
>>>>>>>> status = "okay";
>>>>>>>> pinctrl-names = "default";
>>>>>>>> pinctrl-0 = <_hpd_gpio>;
>>>>>>>> samsung,color-space = <0>;
>>>>>>>> samsung,dynamic-range = <0>;
>>>>>>>> samsung,ycbcr-coeff = <0>;
>>>>>>>> samsung,color-depth = <1>;
>>>>>>>> samsung,link-rate = <0x0a>;
>>>>>>>> samsung,lane-count = <2>;
>>>>>>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>>> panel = <>;
>>>>>>>> };
>>>>>>>>
>>>>>>>
>>>>>>> The difference is because the Exynos5420 Peach Pit Display Port is not
>>>>>>> attached directly to the display panel, there is an eDP/LVDS bridge chip
>>>>>>> in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.
>>>>>>>
>>>>>>> The Exynos DP driver lookups for either a panel phandle or an OF graph
>>>>>>> endpoint that points to a bridge chip and the bridge enpoint has a port
>>>>>>> that points to the panel.
>>>>>>>
>>>>>>> So the DT is correct but of_graph_get_next_endpoint() always prints an
>>>>>>
>>>>>> Then, the DT is really incorrect. As you mentioned, if the Exynos5800
>>>>>> Peach PI
>>>>>> board doesn't use eDP, then the dp node __should be removed__ from
>>>>>> exynos5800-peach-pit.dts.
>>>>>>
&g
[PATCH v2 0/7] drm/exynos: add pm runtime support
2015-11-23 21:25 GMT+09:00 Javier Martinez Canillas :
> Hello,
>
> On 11/21/2015 11:59 AM, Inki Dae wrote:
>> Hi Daniel,
>>
>>
>> 2015-11-21 22:40 GMT+09:00 Daniel Stone :
>>> Hi Inki,
>>>
>>> On 21 November 2015 at 09:38, Inki Dae wrote:
>>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas >>> osg.samsung.com>:
>>>>> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>>>>> The boot log says,
>>>>>> [5.754493] vdd_ldo9: supplied by vdd_2v
>>>>>> [5.765510] of_graph_get_next_endpoint(): no port node found in
>>>>>> /dp-controller at 145B
>>>>>>
>>>>>
>>>>> This message is a red herring for the reported issue, the message is also
>>>>> present when the machine boots and the display is brought correctly.
>>>>>
>>>>>> Seems this error is because exynos5800-peach-pit.dts file doesn't have
>>>>>> 'ports' node in dp node.
>>>>>>
>>>>>> Below is dp node description of exynos5420-peach-pit.dts file.
>>>>>> {
>>>>>> status = "okay";
>>>>>> pinctrl-names = "default";
>>>>>> pinctrl-0 = <_hpd_gpio>;
>>>>>> samsung,color-space = <0>;
>>>>>> samsung,dynamic-range = <0>;
>>>>>> samsung,ycbcr-coeff = <0>;
>>>>>> samsung,color-depth = <1>;
>>>>>> samsung,link-rate = <0x06>;
>>>>>> samsung,lane-count = <2>;
>>>>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>>
>>>>>> ports {
>>>>>> port at 0 {
>>>>>> dp_out: endpoint {
>>>>>> remote-endpoint = <_in>;
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>> };
>>>>>>
>>>>>> And below is for exynos5800-peash-pit.dts,
>>>>>> {
>>>>>> status = "okay";
>>>>>> pinctrl-names = "default";
>>>>>> pinctrl-0 = <_hpd_gpio>;
>>>>>> samsung,color-space = <0>;
>>>>>> samsung,dynamic-range = <0>;
>>>>>> samsung,ycbcr-coeff = <0>;
>>>>>> samsung,color-depth = <1>;
>>>>>> samsung,link-rate = <0x0a>;
>>>>>> samsung,lane-count = <2>;
>>>>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>>> panel = <>;
>>>>>> };
>>>>>>
>>>>>
>>>>> The difference is because the Exynos5420 Peach Pit Display Port is not
>>>>> attached directly to the display panel, there is an eDP/LVDS bridge chip
>>>>> in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.
>>>>>
>>>>> The Exynos DP driver lookups for either a panel phandle or an OF graph
>>>>> endpoint that points to a bridge chip and the bridge enpoint has a port
>>>>> that points to the panel.
>>>>>
>>>>> So the DT is correct but of_graph_get_next_endpoint() always prints an
>>>>
>>>> Then, the DT is really incorrect. As you mentioned, if the Exynos5800
>>>> Peach PI
>>>> board doesn't use eDP, then the dp node __should be removed__ from
>>>> exynos5800-peach-pit.dts.
>>>>
>>>> From a common-sense standpoint, there is no any reason to build
>>>> and probe dp driver if the board doesn't use dp hardware.
>>>
>>> I agree with what you say, but unfortunately you've slightly misread
>>> what Javier has said. :) exynos5420-peach-pit has an LVDS panel, with
>>> the eDP -> LVDS bridge in between (ps8622). exynos5800-peach-pi (from
>>> which I am writing this) has an eDP panel directly connected. The DT
>
> Thanks a lot Daniel for clarifying my comments to Inki :)
>
>>> describes both the eDP connector from FIMD and the eDP panel, except
>>> that there is no connection between the DT nodes.
>
> There *is* a connection between the FIMD eDP connector and the eDP panel
> nodes but these are connected u
[PATCH v2 2/5] drm/exynos: mixer: introduce mixer_layer_blending()
/* Bottom layer needs special handling. */
> + if (bottom_layer) {
> + mixer_general_layer(ctx, >layer_cfg[i]);
> + } else {
> + mixer_bottom_layer(ctx, >layer_cfg[i]);
> + bottom_layer = true;
> + }
I think above codes could be more cleanned up like below if I understood
correctly,
if (cfg->index == 2) {
val = 0;
mixer_reg_write(res, MXR_VIDEO_CFG, val);
} else {
mixer_general_layer(ctx, >layer_cfg[i]);
}
It'd be better to use a macro - i.e., VIDEO_LAYER - instead of 2.
And how about changing the function name, mixer_general_layer to
mixer_grp_layer_set_blending?
Or how about just adding all codes of the function?
Thanks,
Inki Dae
> + }
> +}
> +
> static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
> {
> struct mixer_resources *res = >mixer_res;
> diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
> b/drivers/gpu/drm/exynos/regs-mixer.h
> index ac60260..118872e 100644
> --- a/drivers/gpu/drm/exynos/regs-mixer.h
> +++ b/drivers/gpu/drm/exynos/regs-mixer.h
> @@ -113,6 +113,7 @@
> #define MXR_GRP_CFG_BLEND_PRE_MUL(1 << 20)
> #define MXR_GRP_CFG_WIN_BLEND_EN (1 << 17)
> #define MXR_GRP_CFG_PIXEL_BLEND_EN (1 << 16)
> +#define MXR_GRP_CFG_MISC_MASK((3 << 16) | (3 << 20))
> #define MXR_GRP_CFG_FORMAT_VAL(x)MXR_MASK_VAL(x, 11, 8)
> #define MXR_GRP_CFG_FORMAT_MASK MXR_GRP_CFG_FORMAT_VAL(~0)
> #define MXR_GRP_CFG_ALPHA_VAL(x) MXR_MASK_VAL(x, 7, 0)
>
[PATCH v2 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()
2015ë
11ì 23ì¼ 01:09ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> This updates the blending setup when the layer configuration
> changes (triggered by mixer_win_{commit,disable}).
>
> To avoid unnecesary reconfigurations we cache the layer
> state in the mixer context.
>
> Extra care has to be taken for the layer that is currently
> being enabled/disabled.
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 41
> +--
> 1 file changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index ec9659e..1c24fb5 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -99,6 +99,7 @@ struct mixer_context {
> struct exynos_drm_plane planes[MIXER_WIN_NR];
> const struct layer_cfg *layer_cfg;
> unsigned intnum_layer;
> + u32 layer_state;
> int pipe;
> unsigned long flags;
> boolinterlace;
> @@ -189,6 +190,27 @@ static inline bool is_alpha_format(const struct
> mixer_context* ctx, unsigned int
> }
> }
>
> +static inline u32 get_layer_state(const struct mixer_context *ctx,
> + unsigned int win, bool enable)
> +{
> + u32 enable_state, alpha_state;
> +
> + enable_state = ctx->layer_state & 0x;
> + alpha_state = ctx->layer_state >> 16;
> +
> + if (enable)
> + enable_state |= (1 << win);
> + else
> + enable_state &= ~(1 << win);
> +
> + if (enable && is_alpha_format(ctx, win))
> + alpha_state |= (1 << win);
> + else
> + alpha_state &= ~(1 << win);
> +
> + return ((alpha_state << 16) | enable_state);
> +}
> +
> static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
> {
> return readl(res->vp_regs + reg_id);
> @@ -370,8 +392,9 @@ static void mixer_general_layer(struct mixer_context *ctx,
> {
> u32 val;
> struct mixer_resources *res = >mixer_res;
> + const u32 alpha_state = ctx->layer_state >> 16;
>
> - if (is_alpha_format(ctx, cfg->index)) {
> + if (alpha_state & (1 << cfg->index)) {
> val = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
> val |= MXR_GRP_CFG_BLEND_PRE_MUL;
> val |= MXR_GRP_CFG_PIXEL_BLEND_EN; /* blending based on pixel
> alpha */
> @@ -397,10 +420,11 @@ static void mixer_general_layer(struct mixer_context
> *ctx,
> }
> }
>
> -static void mixer_layer_blending(struct mixer_context *ctx, unsigned int
> enable_state)
> +static void mixer_layer_blending(struct mixer_context *ctx)
> {
> unsigned int i, index;
> bool bottom_layer = false;
> + const u32 enable_state = ctx->layer_state & 0x;
>
> for (i = 0; i < ctx->num_layer; ++i) {
> index = ctx->layer_cfg[i].index;
> @@ -503,8 +527,19 @@ static void mixer_cfg_layer(struct mixer_context *ctx,
> unsigned int win,
> bool enable)
> {
> struct mixer_resources *res = >mixer_res;
> + u32 new_layer_state;
> u32 val = enable ? ~0 : 0;
>
> + new_layer_state = get_layer_state(ctx, win, enable);
> + if (new_layer_state == ctx->layer_state)
> + return;
> +
> + /*
> + * Update the layer state so that mixer_layer_blending()
> + * below can use it.
> + */
> + ctx->layer_state = new_layer_state;
It may be trivial but I think it'd be better to move above line to most bottom
of this function.
> +
> switch (win) {
> case 0:
> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
> @@ -520,6 +555,8 @@ static void mixer_cfg_layer(struct mixer_context *ctx,
> unsigned int win,
> }
> break;
> }
> +
> + mixer_layer_blending(ctx);
Here.
Thanks,
Inki Dae
> }
>
> static void mixer_run(struct mixer_context *ctx)
>
[PATCH v2 1/5] drm/exynos: mixer: refactor layer setup
Hi Tobias,
2015ë
11ì 23ì¼ 01:09ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> First step in allowing a more generic way to setup complex
> blending for the different layers.
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 84
> ++-
> 1 file changed, 73 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 7498c6e..2c1cea3 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -63,6 +63,11 @@ struct mixer_resources {
> struct clk *mout_mixer;
> };
>
> +struct layer_cfg {
> + unsigned int index;
> + unsigned int priority;
> +};
> +
> enum mixer_version_id {
> MXR_VER_0_0_0_16,
> MXR_VER_16_0_33_0,
> @@ -92,6 +97,8 @@ struct mixer_context {
> struct drm_device *drm_dev;
> struct exynos_drm_crtc *crtc;
> struct exynos_drm_plane planes[MIXER_WIN_NR];
> + const struct layer_cfg *layer_cfg;
> + unsigned intnum_layer;
> int pipe;
> unsigned long flags;
> boolinterlace;
> @@ -110,6 +117,34 @@ struct mixer_drv_data {
> boolhas_sclk;
> };
>
> +/*
> + * The default layer priorities for non-VP (video processor)
> + * and VP mixer configurations.
> + *
> + * A higher priority means that the layer is at the top of
> + * the layer stack.
> + * Configurations have to be specified with its entries
> + * sorted with increasing priority.
> + *
> + * The default config assumes the following usage scenario:
> + * layer1: OSD [top]
> + * layer0: main framebuffer
> + * video layer: video overlay [bottom]
> + * Note that the video layer is only usable when the
> + * VP is available.
> + */
> +
> +static const struct layer_cfg nonvp_default_cfg[] = {
> + { .index = 0, .priority = 1 }, /* layer0 */
> + { .index = 1, .priority = 2 }, /* layer1 */
> +};
> +
> +static const struct layer_cfg vp_default_cfg[] = {
> + { .index = 2, .priority = 1 }, /* video layer */
> + { .index = 0, .priority = 2 }, /* layer0 */
> + { .index = 1, .priority = 3 }, /* layer1 */
> +};
> +
> static const u8 filter_y_horiz_tap8[] = {
> 0, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, 0, 0, 0,
> @@ -268,6 +303,34 @@ static void vp_default_filter(struct mixer_resources
> *res)
> filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
> }
>
> +static void mixer_layer_priority(struct mixer_context *ctx)
> +{
> + u32 val = 0;
> + unsigned int i, priority;
> +
> + for (i = 0; i < ctx->num_layer; ++i) {
> + priority = ctx->layer_cfg[i].priority;
> + BUG_ON(priority > 15);
What doesn constant, 15 mean? You need to clarify the meaning
and please, use a macro instead.
And it'd better to just return in this case so that the layer
configuration can be set with a default value.
I think it'd be enough to print out warning message.
Thanks,
Inki Dae
> +
> + switch (ctx->layer_cfg[i].index) {
> + case 0:
> + val |= MXR_LAYER_CFG_GRP0_VAL(priority);
> + break;
> + case 1:
> + val |= MXR_LAYER_CFG_GRP1_VAL(priority);
> + break;
> + case 2:
> + val |= MXR_LAYER_CFG_VP_VAL(priority);
> + break;
> + default:
> + BUG_ON(true);
> + break;
> + }
> + }
> +
> + mixer_reg_write(>mixer_res, MXR_LAYER_CFG, val);
> +}
> +
> static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
> {
> struct mixer_resources *res = >mixer_res;
> @@ -673,17 +736,7 @@ static void mixer_win_reset(struct mixer_context *ctx)
> mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST,
> MXR_STATUS_BURST_MASK);
>
> - /* setting default layer priority: layer1 > layer0 > video
> - * because typical usage scenario would be
> - * layer1 - OSD
> - * layer0 - framebuffer
> - * video - video overlay
> - */
> - val = MXR_LAYER_CFG_GRP1_VAL(3);
> - val |= MXR_LAYER_CFG_GRP0_VAL(2);
> - if (ctx->vp_enabled)
> - val |= MXR_LAYER_CFG_VP_VAL(1);
> - mixer_reg_write(res, MXR_LAYER_CFG, val);
> + mixer_layer_pr
[PATCH v2 00/13] drm/exynos: async G2D and g2d_move()
2015ë 11ì 23ì¼ 11:35ì Hyungwon Hwang ì´(ê°) ì´ ê¸: > Hello Tobias, > > I reviewed this whole patchset, and it looks good to me. Also I tested > it on my odroid u3, and all works fine. Thanks you for your effort. > > Tested-by: Hyungwon Hwang > Reviewed-by: Hyungwon Hwang Acked-by: Inki Dae Thanks, Inki Dae > > BRs, > Hyungwon Hwang > > On Sun, 22 Nov 2015 19:48:30 +0100 > Tobias Jakobi wrote: > >> Hello, >> >> this series mostly touches G2D code. It introduces the following: >> >> (1) drmHandleEvent2() is added to enable processing of vendor-specific >> events. This will be used to expose asynchronous operation of the >> G2D. The necessary kernel infrastructure is already there since >> a lot of kernel versions. [This touches libdrm core code!] >> >> (2) The necessary infrastructure to handle G2D events. This includes >> adding g2d_config_event() and g2d_exec2() to the public API. >> A test application is provided to ensure that everything works >> as expected. >> >> (3) A small performance test application which can be used to measure >> the speed of solid color clear operations. Interesting for >> benchmarking and plotting colorful graphs (e.g. through >> Mathematica). >> >> (4) g2d_move() which works similar to g2d_copy() but like the C >> memmove() properly handles overlapping buffer copies. >> Again a test application is present to check that this >> indeed does what it should. >> >> (5) Various small changes. A framebuffer colorformat fix for the >> general G2D test application. Moving the currently unused >> g2d_reset() to the public API. Adding a counterpart to >> exynos_bo_map() to unmap buffers again. >> >> (6) Last but not least a small bump of the Exynos version number. >> >> Please review and let me know what I should change/improve. >> >> >> With best wishes, >> Tobias >> >> P.S.: Most patches were submitted already some time ago but never >> made it upstream. So if something looks familiar, don't worry! ;) >> >> Changes since v1: >> - Added wording changes suggested by Hyungwon Hwang. >> - Added binaries for new test applications to .gitignore. >> - Collected r-b and t-b tags. >> >> Tobias Jakobi (13): >> drm: Implement drmHandleEvent2() >> exynos: Introduce exynos_handle_event() >> tests/exynos: add fimg2d performance analysis >> exynos/fimg2d: add g2d_config_event >> exynos: fimg2d: add g2d_exec2 >> tests/exynos: add fimg2d event test >> tests/exynos: use XRGB for framebuffer >> exynos: fimg2d: add g2d_set_direction >> exynos/fimg2d: add g2d_move >> tests/exynos: add test for g2d_move >> exynos/fimg2d: add exynos_bo_unmap() >> exynos/fimg2d: add g2d_reset() to public API >> exynos: bump version number >> >> .gitignore | 2 + >> exynos/exynos-symbol-check | 5 + >> exynos/exynos_drm.c| 48 ++ >> exynos/exynos_drm.h| 12 ++ >> exynos/exynos_drmif.h | 27 +++ >> exynos/exynos_fimg2d.c | 165 +-- >> exynos/exynos_fimg2d.h | 49 ++ >> exynos/libdrm_exynos.pc.in | 2 +- >> tests/exynos/Makefile.am | 26 ++- >> tests/exynos/exynos_fimg2d_event.c | 326 >> >> tests/exynos/exynos_fimg2d_perf.c | 327 >> + >> tests/exynos/exynos_fimg2d_test.c | 134 ++- >> xf86drm.h | 21 +++ >> xf86drmMode.c | 10 +- 14 files changed, 1138 >> insertions(+), 16 deletions(-) create mode 100644 >> tests/exynos/exynos_fimg2d_event.c create mode 100644 >> tests/exynos/exynos_fimg2d_perf.c >> > > -- > 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 0/7] drm/exynos: add pm runtime support
Hi Daniel,
2015-11-21 22:40 GMT+09:00 Daniel Stone :
> Hi Inki,
>
> On 21 November 2015 at 09:38, Inki Dae wrote:
>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas > osg.samsung.com>:
>>> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>>> The boot log says,
>>>> [5.754493] vdd_ldo9: supplied by vdd_2v
>>>> [5.765510] of_graph_get_next_endpoint(): no port node found in
>>>> /dp-controller at 145B
>>>>
>>>
>>> This message is a red herring for the reported issue, the message is also
>>> present when the machine boots and the display is brought correctly.
>>>
>>>> Seems this error is because exynos5800-peach-pit.dts file doesn't have
>>>> 'ports' node in dp node.
>>>>
>>>> Below is dp node description of exynos5420-peach-pit.dts file.
>>>> {
>>>> status = "okay";
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <_hpd_gpio>;
>>>> samsung,color-space = <0>;
>>>> samsung,dynamic-range = <0>;
>>>> samsung,ycbcr-coeff = <0>;
>>>> samsung,color-depth = <1>;
>>>> samsung,link-rate = <0x06>;
>>>> samsung,lane-count = <2>;
>>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>>
>>>> ports {
>>>> port at 0 {
>>>> dp_out: endpoint {
>>>> remote-endpoint = <_in>;
>>>> };
>>>> };
>>>> };
>>>> };
>>>>
>>>> And below is for exynos5800-peash-pit.dts,
>>>> {
>>>> status = "okay";
>>>> pinctrl-names = "default";
>>>> pinctrl-0 = <_hpd_gpio>;
>>>> samsung,color-space = <0>;
>>>> samsung,dynamic-range = <0>;
>>>> samsung,ycbcr-coeff = <0>;
>>>> samsung,color-depth = <1>;
>>>> samsung,link-rate = <0x0a>;
>>>> samsung,lane-count = <2>;
>>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>>> panel = <>;
>>>> };
>>>>
>>>
>>> The difference is because the Exynos5420 Peach Pit Display Port is not
>>> attached directly to the display panel, there is an eDP/LVDS bridge chip
>>> in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.
>>>
>>> The Exynos DP driver lookups for either a panel phandle or an OF graph
>>> endpoint that points to a bridge chip and the bridge enpoint has a port
>>> that points to the panel.
>>>
>>> So the DT is correct but of_graph_get_next_endpoint() always prints an
>>
>> Then, the DT is really incorrect. As you mentioned, if the Exynos5800 Peach
>> PI
>> board doesn't use eDP, then the dp node __should be removed__ from
>> exynos5800-peach-pit.dts.
>>
>> From a common-sense standpoint, there is no any reason to build
>> and probe dp driver if the board doesn't use dp hardware.
>
> I agree with what you say, but unfortunately you've slightly misread
> what Javier has said. :) exynos5420-peach-pit has an LVDS panel, with
> the eDP -> LVDS bridge in between (ps8622). exynos5800-peach-pi (from
> which I am writing this) has an eDP panel directly connected. The DT
> describes both the eDP connector from FIMD and the eDP panel, except
> that there is no connection between the DT nodes.
Right. I misread what Javier said. :)
>
>>> error if the port so OF graph endpoints it seems can't be optional as
>>> used in this driver. Maybe that message should be change to debug then?
>>>
>>> Another option is to extend the DP driver DT binding to be more generic
>>> supporting having a port to a panel besides a bridge, so we could have
>>> something like this for Exynos5800 Peach and be consistent in both cases:
>>
>> It's really not good. This would make it more complex. The best
>> solution is just to
>> remove the dt node from the device tree file.
>
> Given the above, not really. Javier's patch seems correct to me - as
> you can see, there is a panel node, and that is the panel that's
> really connected.
Indeed. Javier's patch will correct it.
Thanks,
Inki Dae
>
>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> @@ -122,6 +122,12 @@
>>> compatible = "auo,b133htn01";
>>> power-supply = <_fet6>;
>>> backlight = <>;
>>> +
>>> + port {
>>> + panel_in: endpoint {
>>> + remote-endpoint = <_out>;
>>> + };
>>> + };
>>> };
>>>
>>> mmc1_pwrseq: mmc1_pwrseq {
>>> @@ -148,7 +154,14 @@
>>> samsung,link-rate = <0x0a>;
>>> samsung,lane-count = <2>;
>>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>> - panel = <>;
>>> +
>>> + ports {
>>> + port at 0 {
>>> + dp_out: endpoint {
>>> + remote-endpoint = <_in>;
>>> + };
>>> + };
>>> + };
>>> };
>
> Cheers,
> Daniel
[PATCH v2 0/7] drm/exynos: add pm runtime support
2015-11-21 1:23 GMT+09:00 Javier Martinez Canillas : > Hello Inki, > > On 11/20/2015 07:59 AM, Inki Dae wrote: >> Hi Javier, >> >> 2015ë 11ì 20ì¼ 00:51ì Javier Martinez Canillas ì´(ê°) ì´ ê¸: >>> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote: >>>>>> >>>>> >>>>> This series causes a boot failure on at least an Exynos5800 Peach Pi >>>>> Chromebook (tested myself) and seems to be the cause of other Exynos >>>>> boards failing to boot: http://kernelci.org/boot/?exynos >>>>> >>>>> [snip] >>>>> >>>>>> drm/exynos: add pm_runtime to Mixer >>>>>> drm/exynos: add pm_runtime to FIMD >>>>> >>>>> I had to revert these patches in order to get the machine in a bootable >>>>> state again, the sha1 hash for these patches in next-20151119 are: >>>>> >>>>> 045febd5f813 drm/exynos: add pm_runtime to FIMD >>> >>> On a closer look, only reverting the FIMD patch is enough >>> to make at least the Exynos5800 Peach Pi to boot again. >> >> Thanks for report. >> > > Thanks to you for the quick answer and providing a fix. > >> I assume that the issue is because above patch removed 'suspended' variable >> for checking the suspend status in runtime so I revived it. >> > > It seems your assumption was correct... > >> I'm not sure that the change could resolve the issue. Could you test it >> with the change again? I have no Exynos5800 Peach Pi board. :( >> >> For this, I pushed it to below exynos-drm/for-next branch, >> >> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c >> >> If the issue is resolved by the change then I will modify other patches for >> DECON series. And if really so, there may be a corner case we missed. >> > > ... since I reverted the offending commit and cherry-picked the one > in your for-next branch and the machine booted again. Great. I'll update and post the patch series again. Thanks, Inki Dae > >> Thanks, >> Inki Dae >> > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] drm/exynos: add pm runtime support
Hi Javier,
2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas :
> Hello Inki,
>
> On 11/20/2015 08:13 AM, Inki Dae wrote:
>>
>>
>> 2015ë
11ì 20ì¼ 19:59ì Inki Dae ì´(ê°) ì´ ê¸:
>>> Hi Javier,
>>>
>>> 2015ë
11ì 20ì¼ 00:51ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
>>>> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>>>>>>>
>>>>>>
>>>>>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>>>>>> Chromebook (tested myself) and seems to be the cause of other Exynos
>>>>>> boards failing to boot: http://kernelci.org/boot/?exynos
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>>> drm/exynos: add pm_runtime to Mixer
>>>>>>> drm/exynos: add pm_runtime to FIMD
>>>>>>
>>>>>> I had to revert these patches in order to get the machine in a bootable
>>>>>> state again, the sha1 hash for these patches in next-20151119 are:
>>>>>>
>>>>>> 045febd5f813 drm/exynos: add pm_runtime to FIMD
>>>>
>>>> On a closer look, only reverting the FIMD patch is enough
>>>> to make at least the Exynos5800 Peach Pi to boot again.
>>>
>>> Thanks for report.
>>>
>>> I assume that the issue is because above patch removed 'suspended' variable
>>> for checking the suspend status in runtime so I revived it.
>>>
>>> I'm not sure that the change could resolve the issue. Could you test it
>>> with the change again? I have no Exynos5800 Peach Pi board. :(
>>>
>>> For this, I pushed it to below exynos-drm/for-next branch,
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c
>>>
>>> If the issue is resolved by the change then I will modify other patches for
>>> DECON series. And if really so, there may be a corner case we missed.
>>
>> Oops, I found out one error at the boot log,
>> http://storage.kernelci.org/next/next-20151120/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-collabora/boot-exynos5800-peach-pi.html
>>
>> The boot log says,
>> [5.754493] vdd_ldo9: supplied by vdd_2v
>> [5.765510] of_graph_get_next_endpoint(): no port node found in
>> /dp-controller at 145B
>>
>
> This message is a red herring for the reported issue, the message is also
> present when the machine boots and the display is brought correctly.
>
>> Seems this error is because exynos5800-peach-pit.dts file doesn't have
>> 'ports' node in dp node.
>>
>> Below is dp node description of exynos5420-peach-pit.dts file.
>> {
>> status = "okay";
>> pinctrl-names = "default";
>> pinctrl-0 = <_hpd_gpio>;
>> samsung,color-space = <0>;
>> samsung,dynamic-range = <0>;
>> samsung,ycbcr-coeff = <0>;
>> samsung,color-depth = <1>;
>> samsung,link-rate = <0x06>;
>> samsung,lane-count = <2>;
>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>>
>> ports {
>> port at 0 {
>> dp_out: endpoint {
>> remote-endpoint = <_in>;
>> };
>> };
>> };
>> };
>>
>> And below is for exynos5800-peash-pit.dts,
>> {
>> status = "okay";
>> pinctrl-names = "default";
>> pinctrl-0 = <_hpd_gpio>;
>> samsung,color-space = <0>;
>> samsung,dynamic-range = <0>;
>> samsung,ycbcr-coeff = <0>;
>> samsung,color-depth = <1>;
>> samsung,link-rate = <0x0a>;
>> samsung,lane-count = <2>;
>> samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
>> panel = <>;
>> };
>>
>
> The difference is because the Exynos5420 Peach Pit Display Port is not
> attached directly to the display panel, there is an eDP/LVDS bridge chip
> in the middle (PS8622) while the Exynos5800 Peach Pi doesn't have that.
>
> The Exynos DP driver lookups for either a panel phandle or an OF graph
> endpoint that points to a bridge chip and the bridge enpoint has a port
> that points to the panel.
>
> So the DT is correct but of_graph_get_next_endpoint() always prints an
Then, the DT is really incorrect. As you mentioned,
[PATCH v2 0/7] drm/exynos: add pm runtime support
2015ë
11ì 20ì¼ 19:59ì Inki Dae ì´(ê°) ì´ ê¸:
> Hi Javier,
>
> 2015ë
11ì 20ì¼ 00:51ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
>> On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote:
>>>>>
>>>>
>>>> This series causes a boot failure on at least an Exynos5800 Peach Pi
>>>> Chromebook (tested myself) and seems to be the cause of other Exynos
>>>> boards failing to boot: http://kernelci.org/boot/?exynos
>>>>
>>>> [snip]
>>>>
>>>>> drm/exynos: add pm_runtime to Mixer
>>>>> drm/exynos: add pm_runtime to FIMD
>>>>
>>>> I had to revert these patches in order to get the machine in a bootable
>>>> state again, the sha1 hash for these patches in next-20151119 are:
>>>>
>>>> 045febd5f813 drm/exynos: add pm_runtime to FIMD
>>
>> On a closer look, only reverting the FIMD patch is enough
>> to make at least the Exynos5800 Peach Pi to boot again.
>
> Thanks for report.
>
> I assume that the issue is because above patch removed 'suspended' variable
> for checking the suspend status in runtime so I revived it.
>
> I'm not sure that the change could resolve the issue. Could you test it
> with the change again? I have no Exynos5800 Peach Pi board. :(
>
> For this, I pushed it to below exynos-drm/for-next branch,
>
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c
>
> If the issue is resolved by the change then I will modify other patches for
> DECON series. And if really so, there may be a corner case we missed.
Oops, I found out one error at the boot log,
http://storage.kernelci.org/next/next-20151120/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-collabora/boot-exynos5800-peach-pi.html
The boot log says,
[5.754493] vdd_ldo9: supplied by vdd_2v
[5.765510] of_graph_get_next_endpoint(): no port node found in
/dp-controller at 145B
Seems this error is because exynos5800-peach-pit.dts file doesn't have 'ports'
node in dp node.
Below is dp node description of exynos5420-peach-pit.dts file.
{
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
samsung,dynamic-range = <0>;
samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
ports {
port at 0 {
dp_out: endpoint {
remote-endpoint = <_in>;
};
};
};
};
And below is for exynos5800-peash-pit.dts,
{
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
samsung,dynamic-range = <0>;
samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
panel = <>;
};
Thanks,
Inki Dae
>
> Thanks,
> Inki Dae
>
>>
>> Best regards,
>>
[PATCH v2 0/7] drm/exynos: add pm runtime support
Hi Javier, 2015ë 11ì 20ì¼ 00:51ì Javier Martinez Canillas ì´(ê°) ì´ ê¸: > On 11/19/2015 11:55 AM, Javier Martinez Canillas wrote: >>>> >>> >>> This series causes a boot failure on at least an Exynos5800 Peach Pi >>> Chromebook (tested myself) and seems to be the cause of other Exynos >>> boards failing to boot: http://kernelci.org/boot/?exynos >>> >>> [snip] >>> >>>> drm/exynos: add pm_runtime to Mixer >>>> drm/exynos: add pm_runtime to FIMD >>> >>> I had to revert these patches in order to get the machine in a bootable >>> state again, the sha1 hash for these patches in next-20151119 are: >>> >>> 045febd5f813 drm/exynos: add pm_runtime to FIMD > > On a closer look, only reverting the FIMD patch is enough > to make at least the Exynos5800 Peach Pi to boot again. Thanks for report. I assume that the issue is because above patch removed 'suspended' variable for checking the suspend status in runtime so I revived it. I'm not sure that the change could resolve the issue. Could you test it with the change again? I have no Exynos5800 Peach Pi board. :( For this, I pushed it to below exynos-drm/for-next branch, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm/for-next=e84f43e2b2c3388694b0b3a58c2c4447f1fbae7c If the issue is resolved by the change then I will modify other patches for DECON series. And if really so, there may be a corner case we missed. Thanks, Inki Dae > > Best regards, >
[PATCH 08/14] drm/exynos: create a fake mmap offset with gem creation
2015ë
11ì 17ì¼ 01:23ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Mon, Nov 16, 2015 at 05:22:42PM +0100, Daniel Vetter wrote:
>> On Tue, Jul 28, 2015 at 05:53:23PM +0900, Joonyoung Shim wrote:
>>> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
>>> not, it will call drm_gem_create_mmap_offset whenever user requests
>>> DRM_IOCTL_MODE_MAP_DUMB ioctl.
>>>
>>> Signed-off-by: Joonyoung Shim
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 +++-
>>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index 550d267..c76aa8a 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -151,6 +151,13 @@ struct exynos_drm_gem_obj *exynos_drm_gem_init(struct
>>> drm_device *dev,
>>> return ERR_PTR(ret);
>>> }
>>>
>>> + ret = drm_gem_create_mmap_offset(obj);
>>> + if (ret < 0) {
>>> + drm_gem_object_release(obj);
>>> + kfree(exynos_gem_obj);
>>> + return ERR_PTR(ret);
>>> + }
>>> +
>>> DRM_DEBUG_KMS("created file object = 0x%x\n", (unsigned int)obj->filp);
>>>
>>> return exynos_gem_obj;
>>> @@ -521,14 +528,9 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file
>>> *file_priv,
>>> goto unlock;
>>> }
>>>
>>> - ret = drm_gem_create_mmap_offset(obj);
>>
>> drm_gem_create_mmap_offset internally checks whether it's been already
>> (protected by locks), so this code is perfectly fine. I don't see any
>> justification for this change (but only noticed it because rockchip
>> cargo-culted this change).
>
> I think it'd be good to revert this to stay consistent with cma helpers
> and other drivers.
At least, seems cma halper doesn't also call drm_gem_create_mmap_offset function
at drm_gem_cma_dumb_map_offset function and calls it at cma creation instead.
So I think now Exynos drm keeps consistent with cma helper.
Thanks,
Inki Dae
> -Daniel
>
>> -Daniel
>>
>>> - if (ret)
>>> - goto out;
>>> -
>>> *offset = drm_vma_node_offset_addr(>vma_node);
>>> DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);
>>>
>>> -out:
>>> drm_gem_object_unreference(obj);
>>> unlock:
>>> mutex_unlock(>struct_mutex);
>>> --
>>> 1.9.1
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>
[PATCH] drm/exynos: dsi: add runtime pm support
This patch adds runtime pm interfaces to dsi driver.
Each sub driver should control not only its own clocks and
regulator but also its power domain.
For this, it removes existing exynos_dsi_poweron/poweroff interfaces
and uses runtime pm interfaces instead.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 147 ++--
1 file changed, 81 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 12b03b3..7c3606a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1458,66 +1458,6 @@ static const struct mipi_dsi_host_ops exynos_dsi_ops = {
.transfer = exynos_dsi_host_transfer,
};
-static int exynos_dsi_poweron(struct exynos_dsi *dsi)
-{
- struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
- int ret, i;
-
- ret = regulator_bulk_enable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
- if (ret < 0) {
- dev_err(dsi->dev, "cannot enable regulators %d\n", ret);
- return ret;
- }
-
- for (i = 0; i < driver_data->num_clks; i++) {
- ret = clk_prepare_enable(dsi->clks[i]);
- if (ret < 0)
- goto err_clk;
- }
-
- ret = phy_power_on(dsi->phy);
- if (ret < 0) {
- dev_err(dsi->dev, "cannot enable phy %d\n", ret);
- goto err_clk;
- }
-
- return 0;
-
-err_clk:
- while (--i > -1)
- clk_disable_unprepare(dsi->clks[i]);
- regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
-
- return ret;
-}
-
-static void exynos_dsi_poweroff(struct exynos_dsi *dsi)
-{
- struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
- int ret, i;
-
- usleep_range(1, 2);
-
- if (dsi->state & DSIM_STATE_INITIALIZED) {
- dsi->state &= ~DSIM_STATE_INITIALIZED;
-
- exynos_dsi_disable_clock(dsi);
-
- exynos_dsi_disable_irq(dsi);
- }
-
- dsi->state &= ~DSIM_STATE_CMD_LPM;
-
- phy_power_off(dsi->phy);
-
- for (i = driver_data->num_clks - 1; i > -1; i--)
- clk_disable_unprepare(dsi->clks[i]);
-
- ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
- if (ret < 0)
- dev_err(dsi->dev, "cannot disable regulators %d\n", ret);
-}
-
static void exynos_dsi_enable(struct drm_encoder *encoder)
{
struct exynos_dsi *dsi = encoder_to_dsi(encoder);
@@ -1526,16 +1466,14 @@ static void exynos_dsi_enable(struct drm_encoder
*encoder)
if (dsi->state & DSIM_STATE_ENABLED)
return;
- ret = exynos_dsi_poweron(dsi);
- if (ret < 0)
- return;
+ pm_runtime_get_sync(dsi->dev);
dsi->state |= DSIM_STATE_ENABLED;
ret = drm_panel_prepare(dsi->panel);
if (ret < 0) {
dsi->state &= ~DSIM_STATE_ENABLED;
- exynos_dsi_poweroff(dsi);
+ pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1547,7 +1485,7 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
dsi->state &= ~DSIM_STATE_ENABLED;
exynos_dsi_set_display_enable(dsi, false);
drm_panel_unprepare(dsi->panel);
- exynos_dsi_poweroff(dsi);
+ pm_runtime_put_sync(dsi->dev);
return;
}
@@ -1569,7 +1507,7 @@ static void exynos_dsi_disable(struct drm_encoder
*encoder)
dsi->state &= ~DSIM_STATE_ENABLED;
- exynos_dsi_poweroff(dsi);
+ pm_runtime_put_sync(dsi->dev);
}
static enum drm_connector_status
@@ -1954,22 +1892,99 @@ static int exynos_dsi_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, >encoder);
+ pm_runtime_enable(dev);
+
return component_add(dev, _dsi_component_ops);
}
static int exynos_dsi_remove(struct platform_device *pdev)
{
+ pm_runtime_disable(>dev);
+
component_del(>dev, _dsi_component_ops);
return 0;
}
+#ifdef CONFIG_PM
+static int exynos_dsi_suspend(struct device *dev)
+{
+ struct drm_encoder *encoder = dev_get_drvdata(dev);
+ struct exynos_dsi *dsi = encoder_to_dsi(encoder);
+ struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
+ int ret, i;
+
+ usleep_range(1, 2);
+
+ if (dsi->state & DSIM_STATE_INITIALIZED) {
+ dsi->state &= ~DSIM_STATE_INITIALIZED;
+
+ exynos_dsi_disable_clock(dsi);
+
+ exynos_dsi_disable_irq(dsi);
+ }
+
+ dsi->state &= ~DSIM_STATE_CMD_LPM;
+
+ phy_power_off(dsi->ph
[PATCH v2 0/7] drm/exynos: add pm runtime support
2015ë 11ì 04ì¼ 19:13ì Andrzej Hajda ì´(ê°) ì´ ê¸: > On 11/04/2015 08:56 AM, Inki Dae wrote: >> >> 2015ë 11ì 04ì¼ 16:24ì Andrzej Hajda ì´(ê°) ì´ ê¸: >>> On 11/03/2015 04:38 PM, Inki Dae wrote: >>>> >>>> 2015-11-03 22:24 GMT+09:00 Andrzej Hajda >>> <mailto:a.hajda at samsung.com>>: >>>>> Hi Inki, >>>>> >>>>> On 11/03/2015 11:47 AM, Inki Dae wrote: >>>>>> This patch series adds pm runtime support for Exynos drm. >>>>>> >>>>>> Originally, this patch was posted by Gustavo but there was no any >>>>>> answer about some comments. So I rebased this patch series on top of >>>>>> exynos-drm-next, removed unnecessary patches and modified wrong macro. >>>>> I have sent comment to original patchset[1], but for some strange reasons >>>>> it went only to mailing lists. >>>>> My concerns were as follows: >>>>> - exynos_drm has already pm_runtime support via exynos_drm_drv pm ops, >>>>> why should we add per component support? >>>> >>>> For this, I think I already mentioned enough, >>>> http://www.spinics.net/lists/linux-samsung-soc/msg47695.html >>>> >>>> In brief, exynos_drm_drv doesn't control each power domain of each kms >>>> device. >>>> It means that we cannot power off fully without pm runtime interface of >>>> each >>>> kms device - just they can only control their clock not power domain. So >>>> question. How we could control power domain of each kms device without >>>> runtime >>>> pm interface? >>> Hmm, but to enable pm_runtime in components it is enough to use >>> pm_runtime_enable/disable and pm_runtime_get/put(_sync), there is no need >>> to add >>> pm callbacks. >> That is this patch series does, and pm callback is implemented in >> exynos_drm_drv not in component drivers. > > But this patchset adds runtime_pm ops to each component. Runtime_pm support > does > not require > implementing runtime_pm ops, they just increases complexity of the code, and I > see no gain in splitting > power off/on sequence between drm enable/disable callbacks and suspend/resume > callbacks. Seems reasonable but if there is no any implemention of runtime pm ops and only runtime pm api is called in enable or disable callbacks of each compoment driver, then we wouldn't know which component driver runtime pm request failed at - we could check if the power domain of each compoment device is enabled or disabled correctly by checking each compoment's runtime pm suspend/resume call. So I think it'd be better to implement component's runtime pm ops to make sure to check if the runtime pm call successed, and I think also to fulfill the use of runtime pm api correctly. Anyway, I'd like to open this patchset for more review for a while before going to -next. Welcome to any opinions. Thanks, Inki Dae > > Regards > Andrzej > >> >>> In fact most of the components already supports runtime pm, but quick grep >>> shows that it is not implemented in: >>> exynos_drm_dsi.c, exynos_dp_core.c, exynos_drm_mic.c. >> exynos_dp_core already has runtime pm interface with this patch series. For >> dsi and mic, we need to add the runtime pm interfaces. >> >>> So I guess adding pm_runtime support by adding calls >>> pm_runtime_enable/disable >>> and pm_runtime_get/put(_sync) in appropriate places should be enough. >>> >>>>> - component suspend sequence is non deterministic, but in case of >>>>> video pipelines, specification often requires fixed order, >>>> Can your show me an example? I think component suspend and resume are >>>> invoked >>>> by only drm dpms interface, and the dpms interface has a fixed order - when >>>> dpms goes to off, encoder first, and when dpms goes to on, crtc first. >>> Now as I understand you do not want to remove exynos_drm_drv pm callbacks so >>> they will disable devices properly, after that clock disabling order should >>> not >>> matter, so the whole point is not valid. >> In this case, the dpms actually is invoked by SLEEP PM of Linux power >> management framework. DRM KMS has a interface to control power of kms >> device, which is really different from SLEEP PM. >> So this request can be done by userspace in runtime - just Display power >> off/on. >> >>>> My only concern is that runtime pm interface of each kms dri
[PATCH v2 0/7] drm/exynos: add pm runtime support
2015ë 11ì 04ì¼ 16:24ì Andrzej Hajda ì´(ê°) ì´ ê¸: > On 11/03/2015 04:38 PM, Inki Dae wrote: >> >> 2015-11-03 22:24 GMT+09:00 Andrzej Hajda > <mailto:a.hajda at samsung.com>>: >>> Hi Inki, >>> >>> On 11/03/2015 11:47 AM, Inki Dae wrote: >>>> This patch series adds pm runtime support for Exynos drm. >>>> >>>> Originally, this patch was posted by Gustavo but there was no any >>>> answer about some comments. So I rebased this patch series on top of >>>> exynos-drm-next, removed unnecessary patches and modified wrong macro. >>> >>> I have sent comment to original patchset[1], but for some strange reasons >>> it went only to mailing lists. >>> My concerns were as follows: >>> - exynos_drm has already pm_runtime support via exynos_drm_drv pm ops, >>> why should we add per component support? >> >> For this, I think I already mentioned enough, >> http://www.spinics.net/lists/linux-samsung-soc/msg47695.html >> >> In brief, exynos_drm_drv doesn't control each power domain of each kms >> device. >> It means that we cannot power off fully without pm runtime interface of each >> kms device - just they can only control their clock not power domain. So >> question. How we could control power domain of each kms device without >> runtime >> pm interface? > > Hmm, but to enable pm_runtime in components it is enough to use > pm_runtime_enable/disable and pm_runtime_get/put(_sync), there is no need to > add > pm callbacks. That is this patch series does, and pm callback is implemented in exynos_drm_drv not in component drivers. > In fact most of the components already supports runtime pm, but quick grep > shows that it is not implemented in: > exynos_drm_dsi.c, exynos_dp_core.c, exynos_drm_mic.c. exynos_dp_core already has runtime pm interface with this patch series. For dsi and mic, we need to add the runtime pm interfaces. > So I guess adding pm_runtime support by adding calls pm_runtime_enable/disable > and pm_runtime_get/put(_sync) in appropriate places should be enough. > >> >>> - component suspend sequence is non deterministic, but in case of >>> video pipelines, specification often requires fixed order, >> >> Can your show me an example? I think component suspend and resume are invoked >> by only drm dpms interface, and the dpms interface has a fixed order - when >> dpms goes to off, encoder first, and when dpms goes to on, crtc first. > > Now as I understand you do not want to remove exynos_drm_drv pm callbacks so > they will disable devices properly, after that clock disabling order should > not > matter, so the whole point is not valid. In this case, the dpms actually is invoked by SLEEP PM of Linux power management framework. DRM KMS has a interface to control power of kms device, which is really different from SLEEP PM. So this request can be done by userspace in runtime - just Display power off/on. > >> >> My only concern is that runtime pm interface of each kms driver is called >> within pm sleep context of Exynos drm driver. So I will look into this no >> problem. >> >>> - the patchset adds implicit dependency on PM_SLEEP. >>> >>> >>> Current solution should work correctly and it was OK last time I have >>> tested it. >>> I am not sure about atomic requirements, are there special ones? >> >> Not related to atomic feature. >> >>> >>> There are other issues with current solution, rather easy to solve: >>> - it assumes that exynos-drm device will be suspended first - it should be >>> true, >>> as it is created at the end and suspend order is reverse to creation >>> order, but >>> I am not sure if we can rely on it - some solution is to add pm callbacks >>> to >>> all components, and from those callbacks call one centralized pm routine, >> >> You mean pm callbacks are pm sleep interface? And you mean let's add sleep pm >> interface to each kms driver? If so, I'm not agree with you because sleep pm >> should be controlled by only drm top like single driver does. > > Lets look at an example: > Assume we have present only fimd and dsi components. > In such case kernel creates two platform devices for fimd and dsi in early > stage > of parsing device tree blob. > During exynos_drm_drv initialization exynos-drm platform device is created, > the > important thing it is created after fimd and dsi. > Now when platform enters sleep mode suspend callbacks are called, the > important > thing here
[PATCH v2 0/7] drm/exynos: add pm runtime support
2015-11-03 22:24 GMT+09:00 Andrzej Hajda : > Hi Inki, > > On 11/03/2015 11:47 AM, Inki Dae wrote: >> This patch series adds pm runtime support for Exynos drm. >> >> Originally, this patch was posted by Gustavo but there was no any >> answer about some comments. So I rebased this patch series on top of >> exynos-drm-next, removed unnecessary patches and modified wrong macro. > > I have sent comment to original patchset[1], but for some strange reasons > it went only to mailing lists. > My concerns were as follows: > - exynos_drm has already pm_runtime support via exynos_drm_drv pm ops, > why should we add per component support? For this, I think I already mentioned enough, http://www.spinics.net/lists/linux-samsung-soc/msg47695.html In brief, exynos_drm_drv doesn't control each power domain of each kms device. It means that we cannot power off fully without pm runtime interface of each kms device - just they can only control their clock not power domain. So question. How we could control power domain of each kms device without runtime pm interface? > - component suspend sequence is non deterministic, but in case of > video pipelines, specification often requires fixed order, Can your show me an example? I think component suspend and resume are invoked by only drm dpms interface, and the dpms interface has a fixed order - when dpms goes to off, encoder first, and when dpms goes to on, crtc first. My only concern is that runtime pm interface of each kms driver is called within pm sleep context of Exynos drm driver. So I will look into this no problem. > - the patchset adds implicit dependency on PM_SLEEP. > > > Current solution should work correctly and it was OK last time I have tested it. > I am not sure about atomic requirements, are there special ones? Not related to atomic feature. > > There are other issues with current solution, rather easy to solve: > - it assumes that exynos-drm device will be suspended first - it should be true, > as it is created at the end and suspend order is reverse to creation order, but > I am not sure if we can rely on it - some solution is to add pm callbacks to > all components, and from those callbacks call one centralized pm routine, You mean pm callbacks are pm sleep interface? And you mean let's add sleep pm interface to each kms driver? If so, I'm not agree with you because sleep pm should be controlled by only drm top like single driver does. > - suspend/resume callbacks theoretically can be called during component > master initialization/deinitailization it could be racy, I'm not sure what you mean but component master initialization/deinitailization mean bind and unbind? If so, bind/unbind interfaces of all components will never call pm relevant interfaces but the the pm relevant interfaces are called by only dpms interface. > - exynos_drm_sys_suspend/resume calls exynos_drm_suspend/resume > for historical reasons, these function can be merged together. Also can you show me more detail? Thanks, Inki Dae > > [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/48395 > > Regards > Andrzej > >> >> Changelog v2: >> - Remove patch 5 and 6. >> . commit callback are already removed so isn't required anymore. >> - Remove patch 8 which makes dp clock enabled directly from FIMD. >> . Really not mendatory for FIMD uses DP, and it could be different >> according to Board. >> - Modified CONFIG_PM_SLEEP to CONFIG_PM. >> . In case of runtime pm, CONFIG_PM macro should be used instead of >> CONFIG_PM_SLEEP. >> >> Gustavo Padovan (7): >> drm/exynos: do not start enabling DP at bind() phase >> drm/exynos: add pm_runtime to DP >> drm/exynos: add pm_runtime to HDMI >> drm/exynos: add pm_runtime to Mixer >> drm/exynos: add pm_runtime to FIMD >> drm/exynos: add pm_runtime to DECON 5433 >> drm/exynos: add pm_runtime to DECON 7 >> >> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 54 ++--- >> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 125 +-- >> drivers/gpu/drm/exynos/exynos_dp_core.c | 165 +++--- >> drivers/gpu/drm/exynos/exynos_dp_core.h | 1 + >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 91 ++ >> drivers/gpu/drm/exynos/exynos_hdmi.c | 56 ++--- >> drivers/gpu/drm/exynos/exynos_mixer.c | 125 ++- >> 7 files changed, 352 insertions(+), 265 deletions(-) >> > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151104/355db834/attachment-0001.html>
[PATCH v2 7/7] drm/exynos: add pm_runtime to DECON 7
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.
Changelog v2:
- Modify CONFIG_PM_SLEEP -> CONFIG_PM
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 125 -
1 file changed, 53 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ead2b16..3119aba 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -54,7 +54,6 @@ struct decon_context {
void __iomem*regs;
unsigned long irq_flags;
booli80_if;
- boolsuspended;
int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
@@ -85,9 +84,6 @@ static void decon_wait_for_vblank(struct exynos_drm_crtc
*crtc)
{
struct decon_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
atomic_set(>wait_vsync_event, 1);
/*
@@ -119,13 +115,8 @@ static void decon_clear_channels(struct exynos_drm_crtc
*crtc)
}
/* Wait for vsync, as disable channel takes effect at next vsync */
- if (ch_enabled) {
- unsigned int state = ctx->suspended;
-
- ctx->suspended = 0;
+ if (ch_enabled)
decon_wait_for_vblank(ctx->crtc);
- ctx->suspended = state;
- }
}
static int decon_ctx_initialize(struct decon_context *ctx,
@@ -170,9 +161,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
struct drm_display_mode *mode = >base.state->adjusted_mode;
u32 val, clkdiv;
- if (ctx->suspended)
- return;
-
/* nothing to do if we haven't set the mode yet */
if (mode->htotal == 0 || mode->vtotal == 0)
return;
@@ -234,9 +222,6 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)
struct decon_context *ctx = crtc->ctx;
u32 val;
- if (ctx->suspended)
- return -EPERM;
-
if (!test_and_set_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
@@ -259,9 +244,6 @@ static void decon_disable_vblank(struct exynos_drm_crtc
*crtc)
struct decon_context *ctx = crtc->ctx;
u32 val;
- if (ctx->suspended)
- return;
-
if (test_and_clear_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
@@ -389,9 +371,6 @@ static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
{
struct decon_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
decon_shadow_protect_win(ctx, plane->zpos, true);
}
@@ -409,9 +388,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int bpp = state->fb->bits_per_pixel >> 3;
unsigned int pitch = state->fb->pitches[0];
- if (ctx->suspended)
- return;
-
/*
* SHADOWCON/PRTCON register is used for enabling timing.
*
@@ -508,9 +484,6 @@ static void decon_disable_plane(struct exynos_drm_crtc
*crtc,
unsigned int win = plane->zpos;
u32 val;
- if (ctx->suspended)
- return;
-
/* protect windows */
decon_shadow_protect_win(ctx, win, true);
@@ -529,9 +502,6 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
{
struct decon_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
decon_shadow_protect_win(ctx, plane->zpos, false);
}
@@ -555,39 +525,9 @@ static void decon_init(struct decon_context *ctx)
static void decon_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
- int ret;
-
- if (!ctx->suspended)
- return;
-
- ctx->suspended = false;
pm_runtime_get_sync(ctx->dev);
- ret = clk_prepare_enable(ctx->pclk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the pclk [%d]\n", ret);
- return;
- }
-
- ret = clk_prepare_enable(ctx->aclk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the aclk [%d]\n", ret);
- return;
- }
-
- ret = clk_prepare_enable(ctx->eclk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the eclk [%d]\n", ret);
- return;
- }
-
- ret = clk_prepare_enable(ctx->vclk);
- if (ret < 0) {
-
[PATCH v2 6/7] drm/exynos: add pm_runtime to DECON 5433
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.
Changelog v2:
- Change CONFIG_PM_SLEEP -> CONFIG_PM
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 54 +++
1 file changed, 39 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index fbe1b31..edfd6e3 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -385,12 +385,6 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx->dev);
- for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
- ret = clk_prepare_enable(ctx->clks[i]);
- if (ret < 0)
- goto err;
- }
-
set_bit(BIT_CLKS_ENABLED, >flags);
/* if vblank was enabled status, enable it again. */
@@ -399,11 +393,6 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
decon_commit(ctx->crtc);
- return;
-err:
- while (--i >= 0)
- clk_disable_unprepare(ctx->clks[i]);
-
set_bit(BIT_SUSPENDED, >flags);
}
@@ -425,9 +414,6 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
decon_swreset(ctx);
- for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++)
- clk_disable_unprepare(ctx->clks[i]);
-
clear_bit(BIT_CLKS_ENABLED, >flags);
pm_runtime_put_sync(ctx->dev);
@@ -478,7 +464,6 @@ err:
static struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable= decon_disable,
- .commit = decon_commit,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.atomic_begin = decon_atomic_begin,
@@ -581,6 +566,44 @@ out:
return IRQ_HANDLED;
}
+#ifdef CONFIG_PM
+static int exynos5433_decon_suspend(struct device *dev)
+{
+ struct decon_context *ctx = dev_get_drvdata(dev);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++)
+ clk_disable_unprepare(ctx->clks[i]);
+
+ return 0;
+}
+
+static int exynos5433_decon_resume(struct device *dev)
+{
+ struct decon_context *ctx = dev_get_drvdata(dev);
+ int i, ret;
+
+ for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
+ ret = clk_prepare_enable(ctx->clks[i]);
+ if (ret < 0)
+ goto err;
+ }
+
+ return 0;
+
+err:
+ while (--i >= 0)
+ clk_disable_unprepare(ctx->clks[i]);
+
+ return ret;
+}
+#endif
+
+static const struct dev_pm_ops exynos5433_decon_pm_ops = {
+ SET_RUNTIME_PM_OPS(exynos5433_decon_suspend, exynos5433_decon_resume,
+ NULL)
+};
+
static const struct of_device_id exynos5433_decon_driver_dt_match[] = {
{
.compatible = "samsung,exynos5433-decon",
@@ -684,6 +707,7 @@ struct platform_driver exynos5433_decon_driver = {
.remove = exynos5433_decon_remove,
.driver = {
.name = "exynos5433-decon",
+ .pm = _decon_pm_ops,
.of_match_table = exynos5433_decon_driver_dt_match,
},
};
--
1.9.1
[PATCH v2 5/7] drm/exynos: add pm_runtime to FIMD
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Changelog v2:
- Remove unnecessary changes which removed commit callback from decon drivers
and modify CONFIG_PM_SLEEP -> CONFIG_PM
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 91 +---
1 file changed, 37 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bd75c15..ae97271 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -160,7 +160,6 @@ struct fimd_context {
u32 vidout_con;
u32 i80ifcon;
booli80_if;
- boolsuspended;
int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
@@ -209,9 +208,6 @@ static int fimd_enable_vblank(struct exynos_drm_crtc *crtc)
struct fimd_context *ctx = crtc->ctx;
u32 val;
- if (ctx->suspended)
- return -EPERM;
-
if (!test_and_set_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
@@ -241,9 +237,6 @@ static void fimd_disable_vblank(struct exynos_drm_crtc
*crtc)
struct fimd_context *ctx = crtc->ctx;
u32 val;
- if (ctx->suspended)
- return;
-
if (test_and_clear_bit(0, >irq_flags)) {
val = readl(ctx->regs + VIDINTCON0);
@@ -264,9 +257,6 @@ static void fimd_wait_for_vblank(struct exynos_drm_crtc
*crtc)
{
struct fimd_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
atomic_set(>wait_vsync_event, 1);
/*
@@ -339,14 +329,12 @@ static void fimd_clear_channels(struct exynos_drm_crtc
*crtc)
int pipe = ctx->pipe;
/* ensure that vblank interrupt won't be reported to core */
- ctx->suspended = false;
ctx->pipe = -1;
fimd_enable_vblank(ctx->crtc);
fimd_wait_for_vblank(ctx->crtc);
fimd_disable_vblank(ctx->crtc);
- ctx->suspended = true;
ctx->pipe = pipe;
}
@@ -384,9 +372,6 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
void *timing_base = ctx->regs + driver_data->timing_base;
u32 val, clkdiv;
- if (ctx->suspended)
- return;
-
/* nothing to do if we haven't set the mode yet */
if (mode->htotal == 0 || mode->vtotal == 0)
return;
@@ -620,9 +605,6 @@ static void fimd_atomic_begin(struct exynos_drm_crtc *crtc,
{
struct fimd_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
fimd_shadow_protect_win(ctx, plane->zpos, true);
}
@@ -631,9 +613,6 @@ static void fimd_atomic_flush(struct exynos_drm_crtc *crtc,
{
struct fimd_context *ctx = crtc->ctx;
- if (ctx->suspended)
- return;
-
fimd_shadow_protect_win(ctx, plane->zpos, false);
}
@@ -649,9 +628,6 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
unsigned int bpp = state->fb->bits_per_pixel >> 3;
unsigned int pitch = state->fb->pitches[0];
- if (ctx->suspended)
- return;
-
offset = plane->src_x * bpp;
offset += plane->src_y * pitch;
@@ -733,9 +709,6 @@ static void fimd_disable_plane(struct exynos_drm_crtc *crtc,
struct fimd_context *ctx = crtc->ctx;
unsigned int win = plane->zpos;
- if (ctx->suspended)
- return;
-
fimd_enable_video_output(ctx, win, false);
if (ctx->driver_data->has_shadowcon)
@@ -745,27 +718,9 @@ static void fimd_disable_plane(struct exynos_drm_crtc
*crtc,
static void fimd_enable(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc->ctx;
- int ret;
-
- if (!ctx->suspended)
- return;
-
- ctx->suspended = false;
pm_runtime_get_sync(ctx->dev);
- ret = clk_prepare_enable(ctx->bus_clk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the bus clk [%d]\n", ret);
- return;
- }
-
- ret = clk_prepare_enable(ctx->lcd_clk);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the lcd clk [%d]\n", ret);
- return;
- }
-
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, >irq_f
[PATCH v2 4/7] drm/exynos: add pm_runtime to Mixer
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_mixer.c | 125 +-
1 file changed, 61 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d09f8f9..7498c6e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -70,7 +70,6 @@ enum mixer_version_id {
};
enum mixer_flag_bits {
- MXR_BIT_POWERED,
MXR_BIT_VSYNC,
};
@@ -926,8 +925,6 @@ static int mixer_enable_vblank(struct exynos_drm_crtc *crtc)
struct mixer_resources *res = _ctx->mixer_res;
__set_bit(MXR_BIT_VSYNC, _ctx->flags);
- if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
- return 0;
/* enable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
@@ -943,9 +940,6 @@ static void mixer_disable_vblank(struct exynos_drm_crtc
*crtc)
__clear_bit(MXR_BIT_VSYNC, _ctx->flags);
- if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
- return;
-
/* disable vsync interrupt */
mixer_reg_writemask(res, MXR_INT_STATUS, ~0, MXR_INT_CLEAR_VSYNC);
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
@@ -958,9 +952,6 @@ static void mixer_update_plane(struct exynos_drm_crtc *crtc,
DRM_DEBUG_KMS("win: %d\n", plane->zpos);
- if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
- return;
-
if (plane->zpos > 1 && mixer_ctx->vp_enabled)
vp_video_buffer(mixer_ctx, plane);
else
@@ -976,9 +967,6 @@ static void mixer_disable_plane(struct exynos_drm_crtc
*crtc,
DRM_DEBUG_KMS("win: %d\n", plane->zpos);
- if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
- return;
-
spin_lock_irqsave(>reg_slock, flags);
mixer_vsync_set_update(mixer_ctx, false);
@@ -993,9 +981,6 @@ static void mixer_wait_for_vblank(struct exynos_drm_crtc
*crtc)
struct mixer_context *mixer_ctx = crtc->ctx;
int err;
- if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
- return;
-
err = drm_vblank_get(mixer_ctx->drm_dev, mixer_ctx->pipe);
if (err < 0) {
DRM_DEBUG_KMS("failed to acquire vblank counter\n");
@@ -1020,43 +1005,9 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc->ctx;
struct mixer_resources *res = >mixer_res;
- int ret;
-
- if (test_bit(MXR_BIT_POWERED, >flags))
- return;
pm_runtime_get_sync(ctx->dev);
- ret = clk_prepare_enable(res->mixer);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the mixer clk [%d]\n", ret);
- return;
- }
- ret = clk_prepare_enable(res->hdmi);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
- return;
- }
- if (ctx->vp_enabled) {
- ret = clk_prepare_enable(res->vp);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the vp clk [%d]\n",
- ret);
- return;
- }
- if (ctx->has_sclk) {
- ret = clk_prepare_enable(res->sclk_mixer);
- if (ret < 0) {
- DRM_ERROR("Failed to prepare_enable the " \
- "sclk_mixer clk [%d]\n",
- ret);
- return;
- }
- }
- }
-
- set_bit(MXR_BIT_POWERED, >flags);
-
mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);
if (test_bit(MXR_BIT_VSYNC, >flags)) {
@@ -1069,29 +1020,15 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
static void mixer_disable(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc->ctx;
- struct mixer_resources *res = >mixer_res;
int i;
- if (!test_bit(MXR_BIT_POWERED, >flags))
- return;
-
mixer_stop(ctx);
mixer_regs_dump(ctx);
for (i = 0; i < MIXER_WIN_NR; i++)
mixer_disable_plane(crtc, >planes[i]);
- clear_bit(MXR_BIT_POWERED, >flags);
-
- clk_disable_unprepare(res->hdmi);
- clk_disable_unprepare(res->mixer);
- if (ctx->vp_enabled) {
- clk_disable_unprepare(res->
[PATCH v2 3/7] drm/exynos: add pm_runtime to HDMI
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with proper
refcnt instead of rely on specific flags to track the enabled state.
Changelog v2:
- Mofidy CONFIG_PM_SLEEP -> CONFIG_PM
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 56
1 file changed, 38 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 57b6755..d0362af 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -102,7 +102,6 @@ struct hdmi_context {
struct device *dev;
struct drm_device *drm_dev;
struct drm_connectorconnector;
- boolpowered;
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
@@ -113,7 +112,7 @@ struct hdmi_context {
void __iomem*regs_hdmiphy;
struct i2c_client *hdmiphy_port;
struct i2c_adapter *ddc_adpt;
- struct gpio_desc*hpd_gpio;
+ struct gpio_desc*hpd_gpio;
int irq;
struct regmap *pmureg;
struct clk *hdmi;
@@ -1585,11 +1584,6 @@ static void hdmi_enable(struct drm_encoder *encoder)
{
struct hdmi_context *hdata = encoder_to_hdmi(encoder);
- if (hdata->powered)
- return;
-
- hdata->powered = true;
-
pm_runtime_get_sync(hdata->dev);
if (regulator_bulk_enable(ARRAY_SIZE(supply), hdata->regul_bulk))
@@ -1599,9 +1593,6 @@ static void hdmi_enable(struct drm_encoder *encoder)
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 1);
- clk_prepare_enable(hdata->hdmi);
- clk_prepare_enable(hdata->sclk_hdmi);
-
hdmi_conf_apply(hdata);
}
@@ -1611,9 +1602,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
struct drm_crtc *crtc = encoder->crtc;
const struct drm_crtc_helper_funcs *funcs = NULL;
- if (!hdata->powered)
- return;
-
/*
* The SFRs of VP and Mixer are updated by Vertical Sync of
* Timing generator which is a part of HDMI so the sequence
@@ -1633,9 +1621,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
cancel_delayed_work(>hotplug_work);
- clk_disable_unprepare(hdata->sclk_hdmi);
- clk_disable_unprepare(hdata->hdmi);
-
/* reset pmu hdmiphy control bit to disable hdmiphy */
regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
PMU_HDMI_PHY_ENABLE_BIT, 0);
@@ -1643,8 +1628,6 @@ static void hdmi_disable(struct drm_encoder *encoder)
regulator_bulk_disable(ARRAY_SIZE(supply), hdata->regul_bulk);
pm_runtime_put_sync(hdata->dev);
-
- hdata->powered = false;
}
static struct drm_encoder_helper_funcs exynos_hdmi_encoder_helper_funcs = {
@@ -1978,12 +1961,49 @@ static int hdmi_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int exynos_hdmi_suspend(struct device *dev)
+{
+ struct hdmi_context *hdata = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(hdata->sclk_hdmi);
+ clk_disable_unprepare(hdata->hdmi);
+
+ return 0;
+}
+
+static int exynos_hdmi_resume(struct device *dev)
+{
+ struct hdmi_context *hdata = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(hdata->hdmi);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the hdmi clk [%d]\n", ret);
+ return ret;
+ }
+ ret = clk_prepare_enable(hdata->sclk_hdmi);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the sclk_mixer clk [%d]\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_hdmi_pm_ops = {
+ SET_RUNTIME_PM_OPS(exynos_hdmi_suspend, exynos_hdmi_resume, NULL)
+};
+
struct platform_driver hdmi_driver = {
.probe = hdmi_probe,
.remove = hdmi_remove,
.driver = {
.name = "exynos-hdmi",
.owner = THIS_MODULE,
+ .pm = _hdmi_pm_ops,
.of_match_table = hdmi_match_types,
},
};
--
1.9.1
[PATCH v2 2/7] drm/exynos: add pm_runtime to DP
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
Let pm_runtime handle the enabling/disabling of the device with
proper refcnt instead of rely on specific flags to track the enabled
state.
Changelog v2:
- no change
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 58 ++---
1 file changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index e4d32a1..b6e8b89 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1058,8 +1058,7 @@ static void exynos_dp_bridge_enable(struct drm_bridge
*bridge)
struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
- if (dp->dpms_mode == DRM_MODE_DPMS_ON)
- return;
+ pm_runtime_get_sync(dp->dev);
if (dp->panel) {
if (drm_panel_prepare(dp->panel)) {
@@ -1071,13 +1070,10 @@ static void exynos_dp_bridge_enable(struct drm_bridge
*bridge)
if (crtc->ops->clock_enable)
crtc->ops->clock_enable(dp_to_crtc(dp), true);
- clk_prepare_enable(dp->clock);
phy_power_on(dp->phy);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
exynos_dp_commit(>encoder);
-
- dp->dpms_mode = DRM_MODE_DPMS_ON;
}
static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
@@ -1085,9 +1081,6 @@ static void exynos_dp_bridge_disable(struct drm_bridge
*bridge)
struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
- if (dp->dpms_mode != DRM_MODE_DPMS_ON)
- return;
-
if (dp->panel) {
if (drm_panel_disable(dp->panel)) {
DRM_ERROR("failed to disable the panel\n");
@@ -1098,7 +1091,6 @@ static void exynos_dp_bridge_disable(struct drm_bridge
*bridge)
disable_irq(dp->irq);
flush_work(>hotplug_work);
phy_power_off(dp->phy);
- clk_disable_unprepare(dp->clock);
if (crtc->ops->clock_enable)
crtc->ops->clock_enable(dp_to_crtc(dp), false);
@@ -1108,7 +1100,7 @@ static void exynos_dp_bridge_disable(struct drm_bridge
*bridge)
DRM_ERROR("failed to turnoff the panel\n");
}
- dp->dpms_mode = DRM_MODE_DPMS_OFF;
+ pm_runtime_put_sync(dp->dev);
}
static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
@@ -1267,7 +1259,6 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
int pipe, ret = 0;
dp->dev = >dev;
- dp->dpms_mode = DRM_MODE_DPMS_OFF;
dp->video_info = exynos_dp_dt_parse_pdata(>dev);
if (IS_ERR(dp->video_info))
@@ -1392,6 +1383,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct device_node *panel_node, *bridge_node, *endpoint;
struct exynos_dp_device *dp;
+ int ret;
dp = devm_kzalloc(>dev, sizeof(struct exynos_dp_device),
GFP_KERNEL);
@@ -1420,16 +1412,57 @@ static int exynos_dp_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
- return component_add(>dev, _dp_ops);
+ pm_runtime_enable(dev);
+
+ ret = component_add(>dev, _dp_ops);
+ if (ret)
+ goto err_disable_pm_runtime;
+
+ return ret;
+
+err_disable_pm_runtime:
+ pm_runtime_disable(dev);
+
+ return ret;
}
static int exynos_dp_remove(struct platform_device *pdev)
{
+ pm_runtime_disable(>dev);
component_del(>dev, _dp_ops);
return 0;
}
+#ifdef CONFIG_PM
+static int exynos_dp_suspend(struct device *dev)
+{
+ struct exynos_dp_device *dp = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(dp->clock);
+
+ return 0;
+}
+
+static int exynos_dp_resume(struct device *dev)
+{
+ struct exynos_dp_device *dp = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(dp->clock);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops exynos_dp_pm_ops = {
+ SET_RUNTIME_PM_OPS(exynos_dp_suspend, exynos_dp_resume, NULL)
+};
+
static const struct of_device_id exynos_dp_match[] = {
{ .compatible = "samsung,exynos5-dp" },
{},
@@ -1442,6 +1475,7 @@ struct platform_driver dp_driver = {
.driver = {
.name = "exynos-dp",
.owner = THIS_MODULE,
+ .pm = _dp_pm_ops,
.of_match_table = exynos_dp_match,
},
};
--
1.9.1
[PATCH v2 1/7] drm/exynos: do not start enabling DP at bind() phase
From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
The DP device will be properly enabled at the enable() call just
after the bind call finishes.
Changelog v2:
- no change
Signed-off-by: Gustavo Padovan
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 107 +++-
drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
2 files changed, 78 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 124fb9a..e4d32a1 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1009,9 +1009,9 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
{
int ret;
- encoder->bridge = dp->bridge;
- dp->bridge->encoder = encoder;
- ret = drm_bridge_attach(encoder->dev, dp->bridge);
+ encoder->bridge->next = dp->ptn_bridge;
+ dp->ptn_bridge->encoder = encoder;
+ ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
return ret;
@@ -1020,14 +1020,15 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
return 0;
}
-static int exynos_dp_create_connector(struct drm_encoder *encoder)
+static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
{
- struct exynos_dp_device *dp = encoder_to_dp(encoder);
+ struct exynos_dp_device *dp = bridge->driver_private;
+ struct drm_encoder *encoder = >encoder;
struct drm_connector *connector = >connector;
int ret;
/* Pre-empt DP connector creation if there's a bridge */
- if (dp->bridge) {
+ if (dp->ptn_bridge) {
ret = exynos_drm_attach_lcd_bridge(dp, encoder);
if (!ret)
return 0;
@@ -1052,22 +1053,9 @@ static int exynos_dp_create_connector(struct drm_encoder
*encoder)
return ret;
}
-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
-static void exynos_dp_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void exynos_dp_enable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
{
- struct exynos_dp_device *dp = encoder_to_dp(encoder);
+ struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
@@ -1092,9 +1080,9 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
dp->dpms_mode = DRM_MODE_DPMS_ON;
}
-static void exynos_dp_disable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
{
- struct exynos_dp_device *dp = encoder_to_dp(encoder);
+ struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
@@ -1123,6 +,69 @@ static void exynos_dp_disable(struct drm_encoder
*encoder)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
+static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
+{
+ /* do nothing */
+}
+
+static const struct drm_bridge_funcs exynos_dp_bridge_funcs = {
+ .enable = exynos_dp_bridge_enable,
+ .disable = exynos_dp_bridge_disable,
+ .pre_enable = exynos_dp_bridge_nop,
+ .post_disable = exynos_dp_bridge_nop,
+ .attach = exynos_dp_bridge_attach,
+};
+
+static int exynos_dp_create_connector(struct drm_encoder *encoder)
+{
+ struct exynos_dp_device *dp = encoder_to_dp(encoder);
+ struct drm_device *drm_dev = dp->drm_dev;
+ struct drm_bridge *bridge;
+ int ret;
+
+ bridge = devm_kzalloc(drm_dev->dev, sizeof(*bridge), GFP_KERNEL);
+ if (!bridge) {
+ DRM_ERROR("failed to allocate for drm bridge\n");
+ return -ENOMEM;
+ }
+
+ dp->bridge = bridge;
+
+ encoder->bridge = bridge;
+ bridge->driver_private = dp;
+ bridge->encoder = encoder;
+ bridge->funcs = _dp_bridge_funcs;
+
+ ret = drm_bridge_attach(drm_dev, bridge);
+ if (ret) {
+ DRM_ERROR("failed to attach drm bridge\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
+const struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+ return tru
[PATCH v2 0/7] drm/exynos: add pm runtime support
This patch series adds pm runtime support for Exynos drm. Originally, this patch was posted by Gustavo but there was no any answer about some comments. So I rebased this patch series on top of exynos-drm-next, removed unnecessary patches and modified wrong macro. Changelog v2: - Remove patch 5 and 6. . commit callback are already removed so isn't required anymore. - Remove patch 8 which makes dp clock enabled directly from FIMD. . Really not mendatory for FIMD uses DP, and it could be different according to Board. - Modified CONFIG_PM_SLEEP to CONFIG_PM. . In case of runtime pm, CONFIG_PM macro should be used instead of CONFIG_PM_SLEEP. Gustavo Padovan (7): drm/exynos: do not start enabling DP at bind() phase drm/exynos: add pm_runtime to DP drm/exynos: add pm_runtime to HDMI drm/exynos: add pm_runtime to Mixer drm/exynos: add pm_runtime to FIMD drm/exynos: add pm_runtime to DECON 5433 drm/exynos: add pm_runtime to DECON 7 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 54 ++--- drivers/gpu/drm/exynos/exynos7_drm_decon.c| 125 +-- drivers/gpu/drm/exynos/exynos_dp_core.c | 165 +++--- drivers/gpu/drm/exynos/exynos_dp_core.h | 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 91 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 56 ++--- drivers/gpu/drm/exynos/exynos_mixer.c | 125 ++- 7 files changed, 352 insertions(+), 265 deletions(-) -- 1.9.1
