[PATCH v2] drm/exynos: fix kernel panic issue at drm releasing

2016-01-05 Thread Inki Dae
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 <inki@samsung.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drm/exynos: fix kernel panic issue at drm releasing

2016-01-05 Thread Inki Dae
Hi Daniel,

2016년 01월 05일 05:24에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 4 January 2016 at 12:57, Inki Dae <inki@samsung.com> wrote:
>> 2015년 12월 24일 22:32에 Daniel Stone 이(가) 쓴 글:
>>> On 24 December 2015 at 09:10, Inki Dae <inki@samsung.com> 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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drm/exynos: fix kernel panic issue at drm releasing

2016-01-05 Thread Inki Dae
+ 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 <inki@samsung.com> wrote:
>>>> 2015년 12월 24일 22:32에 Daniel Stone 이(가) 쓴 글:
>>>>> On 24 December 2015 at 09:10, Inki Dae <inki@samsung.com> 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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/7] drm/exynos: rename zpos to index

2016-01-04 Thread Inki Dae
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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] drm/exynos: crtc: do not wait for the scanout completion

2015-12-24 Thread Inki Dae
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 <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] drm/exynos: fix kernel panic issue at drm releasing

2015-12-24 Thread Inki Dae
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 <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/7] drm/exynos: rename zpos to index

2015-12-24 Thread Inki Dae
ig->index);
 
if (!test_bit(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 <m.szyprow...@samsung.com>
> ---
>  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;
&g

Re: [PATCH v3 1/7] drm/exynos: rename zpos to index

2015-12-24 Thread Inki Dae
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 <m.szyprow...@samsung.com>
> ---
>  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 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-11 Thread Inki Dae
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 <m.szyprow...@samsung.com>
>>>> Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>>>> ---
>>>>   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_

Re: [PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-11 Thread Inki Dae
Hi Marek,

2015-12-11 20:27 GMT+09:00 Marek Szyprowski <m.szyprow...@samsung.com>:
> 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_vid

Re: [PATCH] drm/exynos: atomic check only enabled crtc states

2015-12-11 Thread Inki Dae
Hi Javier,

2015-12-09 19:51 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
> 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 <a.ha...@samsung.com>
>>> Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>>> ---
>>> 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 <jav...@osg.samsung.com>
>>
>
> 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-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size

2015-12-11 Thread Inki Dae


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 <m.szyprow...@samsung.com>
>>> ---
>>>   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
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-11 Thread Inki Dae
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 <m.szyprow...@samsung.com>
>> Reviewed-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>> ---
>>  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

Re: [PATCH v2 10/22] drm/exynos: introduce exynos_drm_plane_config structure

2015-12-10 Thread Inki Dae
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 <m.szyprow...@samsung.com>
> ---
>  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, 

Re: [PATCH v2 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size

2015-12-10 Thread Inki Dae
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 <m.szyprow...@samsung.com>
> ---
>  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)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb

2015-12-10 Thread Inki Dae
] 5fa0: 0004 c000f680 000a7c40 0001 0001 000a9540 
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;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 03/22] drm/exynos: gsc: add device tree support and remove usage of static mappings

2015-12-09 Thread Inki Dae
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 <sw0312@samsung.com>
> 
> 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 <sw0312@samsung.com>
> [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 <m.szyprow...@samsung.com>
> ---
>  .../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@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,
> +  

Re: [PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-07 Thread Inki Dae
Hi Javier,

2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
> Hello Inki,
>
> On 12/07/2015 09:52 AM, Inki Dae wrote:
>> From: Javier Martinez Canillas <jav...@osg.samsung.com>
>>
>
> 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 <jav...@osg.samsung.com>
>> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>
> 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 <inki@samsung.com>
>
> Thanks for the review.
>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 3/4] dt-bindings: exynos-dp: update ports node binding for panel

2015-12-07 Thread Inki Dae
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 <inki@samsung.com>
Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---
 .../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@0 {
+   port {
dp_out: endpoint {
-   remote-endpoint = <_in>;
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
+   panel {
+   ...
+   port {
+   dp_in: endpoint {
+   remote-endpoint = <_out>;
};
};
};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/4] drm/exynos: dp: fix wrong return type

2015-12-07 Thread Inki Dae
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 <inki@samsung.com>
Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-07 Thread Inki Dae
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 <jav...@osg.samsung.com>
Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Reviewed-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 1/4] drm/exynos: dp: add of_graph dt binding support for panel

2015-12-07 Thread 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 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 <inki@samsung.com>
Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/4] drm/exynos: dp: consider port node outbound for panel

2015-12-07 Thread Inki Dae
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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] drm/exynos: decon: remove unused variables

2015-12-07 Thread Inki Dae
This patch just removes unused variables, i and ret.

Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-07 Thread Inki Dae


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 <jav...@osg.samsung.com>:
>>> Hello Inki,
>>>
>>> On 12/07/2015 09:52 AM, Inki Dae wrote:
>>>> From: Javier Martinez Canillas <jav...@osg.samsung.com>
>>>>
>>>
>>> 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 <jav...@osg.samsung.com>
>>>> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>>>
>>> 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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi

2015-12-07 Thread Inki Dae


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 <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 <jav...@osg.samsung.com>
>>>> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>>>> Reviewed-by: Inki Dae <inki@samsung.com>
>>>> ---
>>>>  arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++-
>>>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>>>
>>>
>>> Looks sensible:
>>> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
>>>
>>> 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
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel

2015-12-06 Thread Inki Dae
Hi Javier,

2015-12-03 22:05 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
>
> 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 <jav...@osg.samsung.com>
> 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 <jav...@osg.samsung.com>
> ---
>  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@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-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel

2015-12-04 Thread Inki Dae
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 <inki@samsung.com>
>> ---
>>  .../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@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@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 <jav...@osg.samsung.com>

Thanks,
Inki Dae

> 
> Best regards,
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

2015-12-04 Thread Inki Dae
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 <inki@samsung.com>
>> ---
>>  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)
>>  

Re: [PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel

2015-12-04 Thread Inki Dae
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 <inki@samsung.com>
>> ---
>>  .../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@0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
> 
> You don't need these.

Ditto.

> 
>> +
>> +port {
>>  dp_out: endpoint {
>> -    remote-endpoint = <_in>;
>> +remote-endpoint = <_in>;
>> +};
>> +};
>> +};
>> +
>> +panel@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

2015-12-04 Thread Inki Dae
Hi Javier,

2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
> 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-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/3] drm/exynos: dp: fix wrong return type

2015-12-03 Thread Inki Dae
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 <inki@samsung.com>
Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel

2015-12-03 Thread Inki Dae
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 <inki@samsung.com>
---
 .../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@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port {
dp_out: endpoint {
-   remote-endpoint = <_in>;
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
+   panel@0 {
+   reg = <0>;
+   ...
+   port {
+   dp_in: endpoint {
+   remote-endpoint = <_out>;
};
};
};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/3] drm/exynos: dp: consider port node outbound for panel

2015-12-03 Thread Inki Dae
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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

2015-12-03 Thread 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 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 <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] drm/exynos: dsi: modify a error type when getting a node failed

2015-12-02 Thread Inki Dae
This patch makes it to return -EINVAL instead of -ENXIO
when getting a port or endpoint node failed.

Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel

2015-12-02 Thread Inki Dae

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 <inki@samsung.com>
> ---
>  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) {
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/2] drm/exynos: dp: fix wrong return type

2015-12-02 Thread Inki Dae
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 <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel

2015-12-02 Thread 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 <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] drm/exynos: dp: fix wrong return type

2015-12-02 Thread Inki Dae
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 <inki@samsung.com>
>> ---
>>  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,
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] drm/exynos: dp: add of_graph dt binding support for panel

2015-12-02 Thread Inki Dae
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,
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drm/exynos: simplify sleep PM ops

2015-12-01 Thread Inki Dae
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 <a.ha...@samsung.com>
> ---
> 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 */
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] drm/exynos: add pm_runtime to Mixer

2015-11-26 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

[PATCH v3] drm/exynos: add pm_runtime to HDMI

2015-11-26 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] drm/exynos: add pm_runtime to DP

2015-11-26 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] drm/exynos: add pm_runtime to DECON 7

2015-11-26 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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",

[PATCH v3] drm/exynos: add pm_runtime to FIMD

2015-11-26 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/2] drm/exynos: dp: add of_graph dt binding for panel device

2015-11-26 Thread Inki Dae
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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] drm/exynos: dp: fix wrong return type

2015-11-26 Thread Inki Dae
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 <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] drm/exynos: dp: add of_graph dt binding support for panel

2015-11-26 Thread 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.

Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/5] drm/exynos: mixer: introduce mixer_layer_blending()

2015-11-25 Thread Inki Dae
2015-11-24 2:44 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
> 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 <tjak...@math.uni-bielefeld.de>
>>> ---
>>>  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

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-25 Thread Inki Dae
Hi Javier,

2015-11-24 22:19 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
> 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 
>>>> <jav...@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 <dan...@fooishbar.org>:
>>>>>>> Hi Inki,
>>>>>>>
>>>>>>> On 21 November 2015 at 09:38, Inki Dae <daei...@gmail.com> wrote:
>>>>>>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas 
>>>>>>>> <jav...@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@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@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 
>>>>&g

Re: [PATCH v2 1/5] drm/exynos: mixer: refactor layer setup

2015-11-25 Thread Inki Dae
2015-11-24 2:44 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
> 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 <tjak...@math.uni-bielefeld.de>
>>> ---
>>>  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 eno

Re: [PATCH v2 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()

2015-11-25 Thread Inki Dae
2015-11-24 2:44 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
> 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 <tjak...@math.uni-bielefeld.de>
>>> ---
>>>  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 
>>

Re: [PATCH v2 2/5] drm/exynos: mixer: introduce mixer_layer_blending()

2015-11-23 Thread Inki Dae
   /* 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)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-23 Thread Inki Dae
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 <jav...@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 <dan...@fooishbar.org>:
>>>>> Hi Inki,
>>>>>
>>>>> On 21 November 2015 at 09:38, Inki Dae <daei...@gmail.com> wrote:
>>>>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas 
>>>>>> <jav...@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@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@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
>>>>>> exyn

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-23 Thread Inki Dae
2015-11-23 21:25 GMT+09:00 Javier Martinez Canillas <jav...@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 <dan...@fooishbar.org>:
>>> Hi Inki,
>>>
>>> On 21 November 2015 at 09:38, Inki Dae <daei...@gmail.com> wrote:
>>>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas 
>>>> <jav...@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@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@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

Re: [PATCH v2 1/5] drm/exynos: mixer: refactor layer setup

2015-11-22 Thread Inki Dae
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 <tjak...@math.uni-bielefeld.de>
> ---
>  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);
&g

Re: [PATCH v2 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()

2015-11-22 Thread Inki Dae


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 <tjak...@math.uni-bielefeld.de>
> ---
>  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)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 00/13] drm/exynos: async G2D and g2d_move()

2015-11-22 Thread Inki Dae


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 <human.hw...@samsung.com>
> Reviewed-by: Hyungwon Hwang <human.hw...@samsung.com>

Acked-by: Inki Dae <inki@samsung.com>

Thanks,
Inki Dae

> 
> BRs,
> Hyungwon Hwang
> 
> On Sun, 22 Nov 2015 19:48:30 +0100
> Tobias Jakobi <tjak...@math.uni-bielefeld.de> 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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-21 Thread Inki Dae
Hi Daniel,


2015-11-21 22:40 GMT+09:00 Daniel Stone <dan...@fooishbar.org>:
> Hi Inki,
>
> On 21 November 2015 at 09:38, Inki Dae <daei...@gmail.com> wrote:
>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas <jav...@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@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@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

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-21 Thread Inki Dae
Hi Javier,

2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
> 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@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@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 

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-21 Thread Inki Dae
2015-11-21 1:23 GMT+09:00 Javier Martinez Canillas <jav...@osg.samsung.com>:
> 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-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-20 Thread Inki Dae


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@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@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,
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-20 Thread 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.

Thanks,
Inki Dae

> 
> Best regards,
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] drm/exynos: dsi: add runtime pm support

2015-11-16 Thread Inki Dae
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 <inki@samsung.com>
---
 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_L

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-04 Thread Inki Dae


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 <a.ha...@samsung.com
>>>> <mailto:a.ha...@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 driver is called
&

[PATCH v2 6/7] drm/exynos: add pm_runtime to DECON 5433

2015-11-03 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/7] drm/exynos: add pm_runtime to DP

2015-11-03 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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 

[PATCH v2 7/7] drm/exynos: add pm_runtime to DECON 7

2015-11-03 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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);
-   r

[PATCH v2 3/7] drm/exynos: add pm_runtime to HDMI

2015-11-03 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-03 Thread Inki Dae
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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 4/7] drm/exynos: add pm_runtime to Mixer

2015-11-03 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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->mi

[PATCH v2 1/7] drm/exynos: do not start enabling DP at bind() phase

2015-11-03 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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,
+   

Re: [PATCH v2 0/7] drm/exynos: add pm runtime support

2015-11-03 Thread Inki Dae


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 <a.ha...@samsung.com
>> <mailto:a.ha...@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

[PATCH v2 5/7] drm/exynos: add pm_runtime to FIMD

2015-11-03 Thread Inki Dae
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 <gustavo.pado...@collabora.co.uk>
Signed-off-by: Inki Dae <inki@samsung.com>
---
 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;
-   }
-
/

Re: drm/exynos: when to call dma_map_sg() on a GEM object?

2015-11-02 Thread Inki Dae
Hi Tobias,

2015년 11월 02일 19:29에 Tobias Jakobi 이(가) 쓴 글:
> Hello Joonyoung,
> 
> 
> Joonyoung Shim wrote:
>> On 10/31/2015 05:44 AM, Tobias Jakobi wrote:
>>> Hey there,
>>>
>>> this question arose during some discussion with someone concerning the
>>> Exynos mixer and G2D.
>>>
>>> The question is the following. Consider the Exynos mixer when run under
>>> the IOMMU (that's sysmmu_tv IIRC). What exactly does setup the IOMMU
>>> mapping so that the mixer can scanout the framebuffer?
>>>
>>
>> IOMMU mapping is in dma_alloc_attrs(). Already IOMMU was integrated in
>> the DMA mapping API on ARM arch.
> Thanks, I'm going to take a closer look at dma_alloc_attrs() then.
> 
> 
>>> There is exynos_gem_map_sgt_with_dma() in the Exynos GEM code, but it's
>>> currently exclusively used for the G2D and only when dealing with
>>> userptr (and not GEM) there.
>>>
>>> I was looking at exynos_drm_alloc_buf() since this called when
>>> allocating a BO to be used as scanout.
>>>
>>> I see dma_alloc_attrs() being called, which also sets the DMA address
>>> that is later used in the mixer code. But DMA_ATTR_NO_KERNEL_MAPPING is
>>> passed, so no mapping is done at this point.
>>>
>>
>> Did you read Documentation/DMA-attributes.txt document?
> I did, but I guess I should read it again...
> 
> 
>> DMA_ATTR_NO_KERNEL_MAPPING is just to avoid creating a kernel virtual
>> mapping for the allocated buffer on ARM arch.
> Ah OK, so the IOMMU mapping is always established.
> 
> 
>>> Is the mapping done somewhere else, or is it simply not necessary here?
>>>
>>
>> What is the mapping you mean? As you know, the DMA address of the
>> memory gets from dma_alloc_attrs() and it can be used by device. There
>> is no reason to use dma_map_*().
>>From my understanding the mixer doesn't directly access the physical
> memory when running under IOMMU. It accesses memory through sysmmu_tv,
> so my question was who does the setup so that sysmmu_tv "knows" how to
> translate memory accesses.

That is done by dma-mapping API, dma_alloc_attrs function in case of Exynos DRM.

This dma mapping API calls internally iommu_map function of iommu framework
after allocating physical pages and iova space, and the iova space will be
mapped with physical pages.

Please, look into the dma mapping framework - arch/arm/mm/dma-mapping.c -
if you want to understand. I think you could understand it easily if you
tried to look into exynos_drm_alloc_buf function before asking for it.

Thanks,
Inki Dae

> 
> 
> With best wishes,
> Tobias
> 
> 
>>
>> Thanks.
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/7] ARM: exynos_defconfig: enable Exynos DRM Mixer driver

2015-10-28 Thread Inki Dae


2015년 10월 28일 15:09에 Krzysztof Kozlowski 이(가) 쓴 글:
> On 26.10.2015 21:03, Andrzej Hajda wrote:
>> Mixer driver is selected by CONFIG_DRM_EXYNOS_HDMI option. Since Exynos5433
>> HDMI does not require Mixer. There will be separate options to select Mixer
>> and HDMI. Adding new option to defconfig before Kconfig will allow to keep
>> bisectability.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>>  arch/arm/configs/exynos_defconfig | 1 +
>>  1 file changed, 1 insertion(+)
> 
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> 
> I guess this will go with rest of patchset through Exynos DRM tree:
> Acked-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>

Thanks for ack. I will pick it up.

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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/7] add atomic_check callback to exynos_crtc

2015-10-27 Thread Inki Dae


2015년 10월 28일 10:37에 Krzysztof Kozlowski 이(가) 쓴 글:
> On 26.10.2015 21:03, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> This patchset removes hacky mode validation in Mixer driver by adding
>> atomic_check callback to exynos_crtc and replacing direct function call
>> with DRM framework validation. As a result HDMI driver does not depend 
>> anymore
>> on MIXER driver and both drivers can be selected with different Kconfig 
>> options,
>> it is usefull especially for latests SoCs which do have HDMI IP but do not 
>> have
>> MIXER IP.
>> Additionally patchset performs small Kconfig refactoring.
>>
>> Krzysztof could you look at exynos_defconfig patch. Maybe it would be good
>> to merge it before next patch to allow full bi-sectability :)
> 
> I would be happy to see similar for multi_v7. HDMI is already there.
> 
> I also wonder why actually DRM_EXYNOS_HDMI has to depend on MIXER or DECON?

DECON controller has two kinds of data paths in case of Exynos5433 or later.
One is Display path and other is TV path. So it'd be reasonable for 
DRM_EXYNOS_HDMI to depend on MIXER or DECON -
TV path of DECON controller transfers Display data to HDMI like MIXER IP of 
previous Exynos SoC did.

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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 10/10] drm/exynos/decon5433: add support for DECON-TV

2015-10-23 Thread Inki Dae
nos_drm_crtc *crtc,
   struct exynos_drm_plane *plane)
  {
@@ -271,8 +289,12 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
val = plane->dma_addr[0] + pitch * plane->crtc_h;
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));

-   val = OFFSIZE(pitch - plane->crtc_w * bpp)
-   | PAGEWIDTH(plane->crtc_w * bpp);
+   if (ctx->out_type != IFTYPE_HDMI)
+   val = BIT_VAL(pitch - plane->crtc_w * bpp, 27, 14)
+   | BIT_VAL(plane->crtc_w * bpp, 13, 0);
+   else
+   val = BIT_VAL(pitch - plane->crtc_w * bpp, 29, 15)
+   | BIT_VAL(plane->crtc_w * bpp, 14, 0);
writel(val, ctx->addr + DECON_VIDW0xADD2(win));

decon_win_set_pixfmt(ctx, win, state->fb);
@@ -314,7 +336,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc,

decon_shadow_protect_win(ctx, plane->zpos, false);

-   if (ctx->i80_if)
+   if (ctx->out_type == IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, >flags);
  }

@@ -339,6 +361,17 @@ static void decon_swreset(struct decon_context *ctx)
}

WARN(tries == 0, "failed to software reset DECON\n");
+
+   if (ctx->out_type != IFTYPE_HDMI)
+   return;
+
+   writel(VIDCON0_CLKVALUP | VIDCON0_VLCKFREE, ctx->addr + DECON_VIDCON0);
+   decon_set_bits(ctx, DECON_CMU,
+  CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F, ~0);
+   writel(VIDCON1_VCLK_RUN_VDEN_DISABLE, ctx->addr + DECON_VIDCON1);
+   writel(CRCCTRL_CRCEN | CRCCTRL_CRCSTART_F | CRCCTRL_CRCCLKEN,
+  ctx->addr + DECON_CRCCTRL);
+   decon_setup_trigger(ctx);
  }

  static void decon_enable(struct exynos_drm_crtc *crtc)
@@ -387,7 +420,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
 * suspend that connector. Otherwise we might try to scan from
 * a destroyed buffer later.
 */
-   for (i = 0; i < WINDOWS_NR; i++)
+   for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_disable_plane(crtc, >planes[i]);

decon_swreset(ctx);
@@ -461,25 +494,30 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_private *priv = drm_dev->dev_private;
struct exynos_drm_plane *exynos_plane;
+   enum exynos_drm_output_type out_type;
enum drm_plane_type type;
-   unsigned int zpos;
+   unsigned int win;
int ret;

ctx->drm_dev = drm_dev;
ctx->pipe = priv->pipe++;

-   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
-   type = exynos_plane_get_type(zpos, CURSOR_WIN);
-   ret = exynos_plane_init(drm_dev, >planes[zpos],
+   for (win = ctx->first_win; win < WINDOWS_NR; win++) {
+   int tmp = (win == ctx->first_win) ? 0 : win;


AFAIK, DECON TV for Exynos5433 SoC has four hardware overlays so I guess 
you used ctx->first_win to initialize four planes in case of IFTYPE_HDMI.


However, with IFTYPE_HDMI ctx->first_win has 1, as a result, 
ctx->planes[] will have 0, 2nd, 3rd and 4th planes and this means we 
should use 0, 2nd ~ 4th hardware overlay excepting 1st overlay. Is this 
your intention?
Shouldn't ctx->planes[] have 1st, 2nd ,3rd and 4th planes so that we can 
use 1st ~ 4th hardware overlay for DECON TV?


DECON TV for Exynos5433 SoC can use only 1st ~ 4th hardware overlays.

And other thing, it may be trivial but I think it'd be better to use 
'ovl' instead of 'tmp.


Thanks,
Inki Dae
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 10/10] drm/exynos/decon5433: add support for DECON-TV

2015-10-23 Thread Inki Dae
2015-10-23 22:03 GMT+09:00 Andrzej Hajda <a.ha...@samsung.com>:
>
> On 10/23/2015 01:55 PM, Inki Dae wrote:
> > Hi Andrzej,
> >
> >
> > 2015년 10월 20일 18:22에 Andrzej Hajda 이(가) 쓴 글:
> >> DECON-TV IP is responsible for generating video stream which is transferred
> >> to HDMI IP. It is almost fully compatible with DECON IP.
> >>
> >> The patch is based on initial work of Hyungwon Hwang.
> >>
> >> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> >> ---
> >>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 154 
> >> --
> >>   include/video/exynos5433_decon.h  |  29 +
> >>   2 files changed, 122 insertions(+), 61 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> >> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> >> index 3c9aa4e..fbe1b31 100644
> >> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> >> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> >> @@ -13,6 +13,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>
> >> @@ -37,6 +38,12 @@ static const char * const decon_clks_name[] = {
> >>  "sclk_decon_eclk",
> >>   };
> >>
> >> +enum decon_iftype {
> >> +IFTYPE_RGB,
> >> +IFTYPE_I80,
> >> +IFTYPE_HDMI
> >> +};
> >> +
> >>   enum decon_flag_bits {
> >>  BIT_CLKS_ENABLED,
> >>  BIT_IRQS_ENABLED,
> >> @@ -53,7 +60,8 @@ struct decon_context {
> >>  struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
> >>  int pipe;
> >>  unsigned long   flags;
> >> -booli80_if;
> >> +enum decon_iftype   out_type;
> >> +int first_win;
> >>   };
> >>
> >>   static const uint32_t decon_formats[] = {
> >> @@ -80,7 +88,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc 
> >> *crtc)
> >>
> >>  if (test_and_set_bit(BIT_IRQS_ENABLED, >flags)) {
> >>  val = VIDINTCON0_INTEN;
> >> -if (ctx->i80_if)
> >> +if (ctx->out_type == IFTYPE_I80)
> >>  val |= VIDINTCON0_FRAMEDONE;
> >>  else
> >>  val |= VIDINTCON0_INTFRMEN;
> >> @@ -104,8 +112,11 @@ static void decon_disable_vblank(struct 
> >> exynos_drm_crtc *crtc)
> >>
> >>   static void decon_setup_trigger(struct decon_context *ctx)
> >>   {
> >> -u32 val = TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> >> -TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN;
> >> +u32 val = (ctx->out_type != IFTYPE_HDMI)
> >> +? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> >> +  TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> >> +: TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> >> +  TRIGCON_HWTRIGMASK_I80_RGB | TRIGCON_HWTRIGEN_I80_RGB;
> >>  writel(val, ctx->addr + DECON_TRIGCON);
> >>   }
> >>
> >> @@ -118,13 +129,22 @@ static void decon_commit(struct exynos_drm_crtc 
> >> *crtc)
> >>  if (test_bit(BIT_SUSPENDED, >flags))
> >>  return;
> >>
> >> +if (ctx->out_type == IFTYPE_HDMI) {
> >> +m->crtc_hsync_start = m->crtc_hdisplay + 10;
> >> +m->crtc_hsync_end = m->crtc_htotal - 92;
> >> +m->crtc_vsync_start = m->crtc_vdisplay + 1;
> >> +m->crtc_vsync_end = m->crtc_vsync_start + 1;
> >> +}
> >> +
> >> +decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
> >> +
> >>  /* enable clock gate */
> >>  val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
> >>  writel(val, ctx->addr + DECON_CMU);
> >>
> >>  /* lcd on and use command if */
> >>  val = VIDOUT_LCD_ON;
> >> -if (ctx->i80_if)
> >> +if (ctx->out_type == IFTYPE_I80)
> >>  val |= VIDOUT_COMMAND_IF;
> >>  else
> >>  val |= VIDOUT_RGB_IF;
> >> @@ -134,7 +154,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
> >>  VIDTCON2_HOZVAL(m->hd

Re: [PATCH 07/10] drm/exynos: add pm_runtime to FIMD

2015-10-12 Thread Inki Dae

Also ping~~

2015년 09월 19일 12:53에 Inki Dae 이(가) 쓴 글:

On 2015년 09월 05일 05:15, Gustavo Padovan wrote:

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 <gustavo.pado...@collabora.co.uk>
---
  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  1 -
  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  1 -
  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 91 +++
  3 files changed, 37 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 79b2b22..838a9c1 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -478,7 +478,6 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
.commit = decon_commit,
.enable_vblank  = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
-   .commit = decon_commit,


Above wouldn't be related to this patch.


.atomic_begin   = decon_atomic_begin,
.update_plane   = decon_update_plane,
.disable_plane  = decon_disable_plane,
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f3826dc..e4646e2 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -637,7 +637,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable = decon_disable,
.mode_fixup = decon_mode_fixup,
-   .commit = decon_commit,


Ditto.

Thanks,
Inki Dae


.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.wait_for_vblank = decon_wait_for_vblank,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0bbe537..0f17ae0 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;
}

@@ -394,9 +382,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;
@@ -630,9 +615,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);
  }

@@ -641,9 +623,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);
  }

@@ -659,9 +638,6 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
  

Re: [PATCH] drm/exynos: fix spelling errors

2015-10-12 Thread Inki Dae
Hi, Ingi.

Merged. Thanks for your first patch to drm world. :)
This patch isn't trivial so will go to next.

Thanks,
Inki Dae


2015년 10월 02일 17:59에 Ingi Kim 이(가) 쓴 글:
> This patch fixes spelling errors in drm fimc/gsc
> inavild -> invaild
> 
> Signed-off-by: Ingi Kim <ingi2@samsung.com>
> ---
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c  | 12 ++--
>   2 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 2a65235..5d00f86 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -466,7 +466,7 @@ static int fimc_src_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   EXYNOS_MSCTRL_C_INT_IN_2PLANE);
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid source yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -513,7 +513,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
>   cfg |= EXYNOS_MSCTRL_INFORMAT_YCBCR420;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid source format 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source format 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -578,7 +578,7 @@ static int fimc_src_set_transf(struct device *dev,
>   cfg1 &= ~EXYNOS_MSCTRL_FLIP_Y_MIRROR;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -701,7 +701,7 @@ static int fimc_src_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > FIMC_MAX_SRC) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
>   return -ENOMEM;
>   }
>   
> @@ -812,7 +812,7 @@ static int fimc_dst_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   cfg |= EXYNOS_CIOCTRL_YCBCR_2PLANE;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -865,7 +865,7 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
>   cfg |= EXYNOS_CITRGFMT_OUTFORMAT_YCBCR420;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target format 0x%x.\n",
> + dev_err(ippdrv->dev, "invalid target format 0x%x.\n",
>   fmt);
>   return -EINVAL;
>   }
> @@ -929,7 +929,7 @@ static int fimc_dst_set_transf(struct device *dev,
>   cfg &= ~EXYNOS_CITRGFMT_FLIP_Y_MIRROR;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -1160,7 +1160,7 @@ static int fimc_dst_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > FIMC_MAX_DST) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
>   return -ENOMEM;
>   }
>   
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 808a0a0..11b87d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -543,7 +543,7 @@ static int gsc_src_set_fmt(struct device *dev, u32 fmt)
>   GSC_IN_YUV420_2P);
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -595,7 +595,7 @@ 

Re: [PATCH 1/2] drm/exynos: add global macro for the default primary plane

2015-10-12 Thread Inki Dae
Hi Gustavo,

Merged.

Thanks,
Inki Dae

2015년 09월 05일 07:05에 Gustavo Padovan 이(가) 쓴 글:
> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
> 
> Define DEFAULT_WIN as zero to help set the primary plane on all CRTCs.
> Some CRTCs were defining a variable to store the default window, but that
> is not necessary as the default (primary) window is always the window zero.
> 
> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
> ---
>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 ++
>   drivers/gpu/drm/exynos/exynos7_drm_decon.c| 5 ++---
>   drivers/gpu/drm/exynos/exynos_drm_drv.h   | 2 ++
>   drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 5 ++---
>   drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 6 ++
>   drivers/gpu/drm/exynos/exynos_mixer.c | 7 +++
>   6 files changed, 13 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 988df06..2f393b1 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -33,7 +33,6 @@ struct decon_context {
>   struct exynos_drm_plane planes[WINDOWS_NR];
>   void __iomem*addr;
>   struct clk  *clks[6];
> - unsigned intdefault_win;
>   unsigned long   irq_flags;
>   int pipe;
>   
> @@ -451,7 +450,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->pipe = priv->pipe++;
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
>   DRM_PLANE_TYPE_OVERLAY;
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, decon_formats,
> @@ -460,7 +459,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   return ret;
>   }
>   
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
>   ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>   ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>   _crtc_ops, ctx);
> @@ -557,7 +556,6 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>   if (!ctx)
>   return -ENOMEM;
>   
> - ctx->default_win = 0;
>   ctx->dev = dev;
>   if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
>   ctx->i80_if = true;
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 0776f38..7a6c069 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -52,7 +52,6 @@ struct decon_context {
>   struct clk  *eclk;
>   struct clk  *vclk;
>   void __iomem*regs;
> - unsigned intdefault_win;
>   unsigned long   irq_flags;
>   booli80_if;
>   int pipe;
> @@ -631,7 +630,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   }
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> + type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
>   DRM_PLANE_TYPE_OVERLAY;
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, decon_formats,
> @@ -640,7 +639,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   return ret;
>   }
>   
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
>   ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>  ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>  _crtc_ops, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 5cb9bc3..058abd1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/ex

Re: [PATCH 08/10] drm/exynos: Enable DP clock directly from FIMD

2015-10-12 Thread Inki Dae

Gustavo, please ping~~~

2015년 09월 19일 12:51에 Inki Dae 이(가) 쓴 글:

Hi Gustavo,

On 2015년 09월 05일 05:15, Gustavo Padovan wrote:

From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>

Instead of having a .clock_enable callback enable the dp clock directly
from FIMD.

Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
---
  drivers/gpu/drm/exynos/exynos_dp_core.c  | 13 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |  5 
  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 39 +---
  3 files changed, 21 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 6794982..aa11d18 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -37,11 +37,6 @@
  #define ctx_from_connector(c) container_of(c, struct exynos_dp_device, \
connector)

-static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
-{
-   return to_exynos_crtc(dp->encoder.crtc);
-}
-
  static inline struct exynos_dp_device *encoder_to_dp(
struct drm_encoder *e)
  {
@@ -1068,7 +1063,6 @@ static void exynos_dp_mode_set(struct drm_encoder 
*encoder,
  static void exynos_dp_enable(struct drm_encoder *encoder)
  {
struct exynos_dp_device *dp = encoder_to_dp(encoder);
-   struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

pm_runtime_get_sync(dp->dev);

@@ -1079,9 +1073,6 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
}
}

-   if (crtc->ops->clock_enable)
-   crtc->ops->clock_enable(dp_to_crtc(dp), true);
-
phy_power_on(dp->phy);
exynos_dp_init_dp(dp);
enable_irq(dp->irq);
@@ -1091,7 +1082,6 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
  static void exynos_dp_disable(struct drm_encoder *encoder)
  {
struct exynos_dp_device *dp = encoder_to_dp(encoder);
-   struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

if (dp->panel) {
if (drm_panel_disable(dp->panel)) {
@@ -1104,9 +1094,6 @@ static void exynos_dp_disable(struct drm_encoder *encoder)
flush_work(>hotplug_work);
phy_power_off(dp->phy);

-   if (crtc->ops->clock_enable)
-   crtc->ops->clock_enable(dp_to_crtc(dp), false);
-
if (dp->panel) {
if (drm_panel_unprepare(dp->panel))
DRM_ERROR("failed to turnoff the panel\n");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5f1a4d6..ee60619 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -96,10 +96,6 @@ struct exynos_drm_plane {
   * @disable_plane: disable hardware specific overlay.
   * @te_handler: trigger to transfer video image at the tearing effect
   *synchronization signal if there is a page flip request.
- * @clock_enable: optional function enabling/disabling display domain clock,
- * called from exynos-dp driver before powering up (with
- * 'enable' argument as true) and after powering down (with
- * 'enable' as false).
   */
  struct exynos_drm_crtc;
  struct exynos_drm_crtc_ops {
@@ -120,7 +116,6 @@ struct exynos_drm_crtc_ops {
void (*atomic_flush)(struct exynos_drm_crtc *crtc,
  struct exynos_drm_plane *plane);
void (*te_handler)(struct exynos_drm_crtc *crtc);
-   void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
  };

  /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0f17ae0..3cf2b80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -573,6 +573,23 @@ static void fimd_win_set_colkey(struct fimd_context *ctx, 
unsigned int win)
writel(keycon1, ctx->regs + WKEYCON1_BASE(win));
  }

+static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
+{
+   struct fimd_context *ctx = crtc->ctx;
+   u32 val;
+
+   /*
+* Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
+* clock. On these SoCs the bootloader may enable it but any
+* power domain off/on will reset it to disable state.
+*/
+   if (ctx->driver_data != _fimd_driver_data)
+   return;
+
+   val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
+   writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
+}
+
  /**
   * shadow_protect_win() - disable updating values from shadow registers at 
vsync
   *
@@ -735,6 +752,8 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
if (test_and_clear_bit(0, >irq_flags))
fimd_enable_vblank(ctx->crtc);

+   fimd_dp_clock_enable(crtc, t

Re: [PATCH 2/2] drm/exynos: add cursor plane support

2015-10-12 Thread Inki Dae

Merged.

Thanks,
Inki Dae

2015년 09월 05일 07:05에 Gustavo Padovan 이(가) 쓴 글:
> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
> 
> Set one of the planes for each crtc driver as a cursor plane enabled
> window managers to fully work on exynos.
> 
> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
> 
> ---
> v2: use the top window for cursor on each crtc
> ---
>   drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  4 ++--
>   drivers/gpu/drm/exynos/exynos7_drm_decon.c|  4 ++--
>   drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  4 ++--
>   drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 +++
>   drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 ++
>   drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  4 ++--
>   drivers/gpu/drm/exynos/exynos_mixer.c |  4 ++--
>   7 files changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 2f393b1..4b8dd7c 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -24,6 +24,7 @@
>   #include "exynos_drm_iommu.h"
>   
>   #define WINDOWS_NR  3
> +#define CURSOR_WIN   2
>   #define MIN_FB_WIDTH_FOR_16WORD_BURST   128
>   
>   struct decon_context {
> @@ -450,8 +451,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->pipe = priv->pipe++;
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 7a6c069..aa0ae79 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -41,6 +41,7 @@
>   #define MIN_FB_WIDTH_FOR_16WORD_BURST 128
>   
>   #define WINDOWS_NR  2
> +#define CURSOR_WIN   1
>   
>   struct decon_context {
>   struct device   *dev;
> @@ -630,8 +631,7 @@ static int decon_bind(struct device *dev, struct device 
> *master, void *data)
>   }
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 7776768..caa5255 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -88,6 +88,7 @@
>   
>   /* FIMD has totally five hardware windows. */
>   #define WINDOWS_NR  5
> +#define CURSOR_WIN   4
>   
>   struct fimd_driver_data {
>   unsigned int timing_base;
> @@ -909,8 +910,7 @@ static int fimd_bind(struct device *dev, struct device 
> *master, void *data)
>   ctx->pipe = priv->pipe++;
>   
>   for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == DEFAULT_WIN) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> + type = exynos_plane_get_type(zpos, CURSOR_WIN);
>   ret = exynos_plane_init(drm_dev, >planes[zpos],
>   1 << ctx->pipe, type, fimd_formats,
>   ARRAY_SIZE(fimd_formats), zpos);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 7148224..80b2151 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -208,6 +208,17 @@ static void exynos_plane_attach_zpos_property(struct 
> drm_plane *plane,
>   drm_object_attach_property(>base, prop, zpos);
>   }
>   
> +enum drm_plane_type exynos_plane_get_type(unsigned int zpos,
> +   unsigned int cursor_win)
> +{
> + if (zpos == DEFAULT_WIN)
> + re

Re: [PATCH 00/16] drm/exynos/hdmi: refactoring/cleanup patches

2015-10-12 Thread Inki Dae
Hi Andrzej,

For all patches, merged excepting patch 2 which cleans up dt binding
document.

Thanks,
Inki Dae

2015년 09월 25일 21:48에 Andrzej Hajda 이(가) 쓴 글:
> Hi,
> 
> This is another set of cleanup/improvement patches for HDMI.
> 
> The patchset is based on exynos-drm-next.
> It was tested on Universal and Odroid U3.
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (15):
>drm/exynos/hdmi: remove support for deprecated compatible
>dt-bindings: remove deprecated compatible string from exynos-hdmi
>drm/exynos/hdmi: use mappings for registers with IP dependent address
>drm/exynos/hdmi: move PLL stabilization check code to separate
>  function
>drm/exynos/hdmi: simplify HDMI-PHY power sequence
>drm/exynos/hdmi: replace all writeb with writel
>drm/exynos/hdmi: fix removal order
>drm/exynos/hdmi: use optional regulator_get for hdmi-en
>drm/exynos/hdmi: use constant size array for regulators
>drm/exynos/hdmi: simplify clock re-parenting
>drm/exynos/hdmi: convert to gpiod API
>drm/exynos/hdmi: remove deprecated hdmi_resources structure
>drm/exynos/hdmi: convert container_of macro to inline function
>drm/exynos/hdmi: improve HDMI/ACR related code
>drm/exynos/hdmi: remove unused field
> 
> Tomasz Stanislawski (1):
>drm: exynos: mixer: fix using usleep() in atomic context
> 
>   .../devicetree/bindings/video/exynos_hdmi.txt  |   7 +-
>   drivers/gpu/drm/exynos/exynos_hdmi.c   | 491 
> +++--
>   drivers/gpu/drm/exynos/exynos_mixer.c  |   2 +-
>   drivers/gpu/drm/exynos/regs-hdmi.h |  33 +-
>   4 files changed, 189 insertions(+), 344 deletions(-)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drm/exynos: Avoid NULL pointer dereference in resume if bind failed

2015-09-30 Thread Inki Dae
Hi,

On 2015년 09월 28일 01:11, Charles Keepax wrote:
> If binding failed calling exynos_dp_enable in exynos_dp_resume will
> result in several NULL pointer dereferences. It is much better to
> simply skip suspend/resume handling if bind has failed, do so by
> checking if a drm_dev exists.

Thanks for your patch. However, the pm interfaces of KMS drivers aren't
required because these are controlled by top of Exynos drm driver and
connector dpms. So I posted a patch that it removes pm interfaces of dp
driver.

Thanks,
Inki Dae

> 
> Signed-off-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index d66ade0..48baf07 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1388,6 +1388,9 @@ static int exynos_dp_suspend(struct device *dev)
>  {
>   struct exynos_dp_device *dp = dev_get_drvdata(dev);
>  
> + if (!dp->drm_dev)
> + return 0;
> +
>   exynos_dp_disable(>encoder);
>   return 0;
>  }
> @@ -1396,6 +1399,9 @@ static int exynos_dp_resume(struct device *dev)
>  {
>   struct exynos_dp_device *dp = dev_get_drvdata(dev);
>  
> + if (!dp->drm_dev)
> + return 0;
> +
>   exynos_dp_enable(>encoder);
>   return 0;
>  }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] drm/exynos: dp: remove suspend/resume functions

2015-09-30 Thread Inki Dae
This patch removes unnecessary pm suspend/resume functions.

All kms sub drivers will be controlled by top of Exynos drm driver
and connector dpms so these sub drivers shouldn't have their own
pm interfaces.

Signed-off-by: Inki Dae <inki@samsung.com>
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..124fb9a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1383,28 +1383,6 @@ static int exynos_dp_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int exynos_dp_suspend(struct device *dev)
-{
-   struct exynos_dp_device *dp = dev_get_drvdata(dev);
-
-   exynos_dp_disable(>encoder);
-   return 0;
-}
-
-static int exynos_dp_resume(struct device *dev)
-{
-   struct exynos_dp_device *dp = dev_get_drvdata(dev);
-
-   exynos_dp_enable(>encoder);
-   return 0;
-}
-#endif
-
-static const struct dev_pm_ops exynos_dp_pm_ops = {
-   SET_SYSTEM_SLEEP_PM_OPS(exynos_dp_suspend, exynos_dp_resume)
-};
-
 static const struct of_device_id exynos_dp_match[] = {
{ .compatible = "samsung,exynos5-dp" },
{},
@@ -1417,7 +1395,6 @@ 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

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drm/exynos: dp: remove suspend/resume functions

2015-09-30 Thread Inki Dae
Hi Emil,

On 2015년 09월 30일 21:19, Emil Velikov wrote:
> Hi Inki,
> 
> On 30 September 2015 at 12:21, Inki Dae <inki@samsung.com> wrote:
>> This patch removes unnecessary pm suspend/resume functions.
>>
>> All kms sub drivers will be controlled by top of Exynos drm driver
>> and connector dpms so these sub drivers shouldn't have their own
>> pm interfaces.
>>
> Not sure if you've noticed but this patch seems to do the opposite of
> what Gustavo was aiming with an earlier series [1].

I removed just the interfaces related to sleep pm not runtime pm. From
long ago, Linux DRM drivers - especially ARM DRM drivers - have been
stepping forward to a integrated DRM driver so it'd be reasonable for
sleep pm operations of all KMS drivers are controlled by top of DRM
driver. It means that Exynos drm driver has already sleep pm interfaces.

However, I think a power domain of each kms device couldn't be
controlled by the top in case of ARM SoC because kms devices can use a
different power domain each other according to Vendor SoC so runtime pm
should be controlled by each kms driver, which will be triggered by DRM top.

And Gustavo's patch set you mentioned - now being reviewed - will add
only runtime pm interfaces to each kms driver.

Thanks,
Inki Dae

> 
> Cheers,
> Emil
> 
> [1] http://lists.freedesktop.org/archives/dri-devel/2015-September/089800.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 08/10] drm/exynos: Enable DP clock directly from FIMD

2015-09-18 Thread Inki Dae
 = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
> + writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
> +}
> +
>  /**
>   * shadow_protect_win() - disable updating values from shadow registers at 
> vsync
>   *
> @@ -735,6 +752,8 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
>   if (test_and_clear_bit(0, >irq_flags))
>   fimd_enable_vblank(ctx->crtc);
>  
> + fimd_dp_clock_enable(crtc, true);

You are forcing FIMD driver to enable DP clock every time FIMD is
enabled. Please know that in Exynos Display pipeline, Encoder device
could be used according to how Display path is configured.

For example,
FIMD - Panel
FIMD - MIPI-DSI - Panel
FIMD - DP - Panel
...

In previous codes, DP clock will be enabled by DP driver even through
enable callback of the DP clock is registered by FIMD driver to
fimd_crtc_ops, which means that DP clock can be enabled only in case
that DP driver is available.

Thanks,
Inki Dae

> +
>   fimd_commit(ctx->crtc);
>  }
>  
> @@ -743,6 +762,8 @@ static void fimd_disable(struct exynos_drm_crtc *crtc)
>   struct fimd_context *ctx = crtc->ctx;
>   int i;
>  
> + fimd_dp_clock_enable(crtc, false);
> +
>   /*
>* We need to make sure that all windows are disabled before we
>* suspend that connector. Otherwise we might try to scan from
> @@ -814,23 +835,6 @@ static void fimd_te_handler(struct exynos_drm_crtc *crtc)
>   drm_crtc_handle_vblank(>crtc->base);
>  }
>  
> -static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
> -{
> - struct fimd_context *ctx = crtc->ctx;
> - u32 val;
> -
> - /*
> -  * Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
> -  * clock. On these SoCs the bootloader may enable it but any
> -  * power domain off/on will reset it to disable state.
> -  */
> - if (ctx->driver_data != _fimd_driver_data)
> - return;
> -
> - val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
> - writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
> -}
> -
>  static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
>   .enable = fimd_enable,
>   .disable = fimd_disable,
> @@ -843,7 +847,6 @@ static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
>   .disable_plane = fimd_disable_plane,
>   .atomic_flush = fimd_atomic_flush,
>   .te_handler = fimd_te_handler,
> - .clock_enable = fimd_dp_clock_enable,
>  };
>  
>  static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 07/10] drm/exynos: add pm_runtime to FIMD

2015-09-18 Thread Inki Dae
On 2015년 09월 05일 05:15, Gustavo Padovan wrote:
> 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 <gustavo.pado...@collabora.co.uk>
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  1 -
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  1 -
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 91 
> +++
>  3 files changed, 37 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 79b2b22..838a9c1 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -478,7 +478,6 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
>   .commit = decon_commit,
>   .enable_vblank  = decon_enable_vblank,
>   .disable_vblank = decon_disable_vblank,
> - .commit = decon_commit,

Above wouldn't be related to this patch.

>   .atomic_begin   = decon_atomic_begin,
>   .update_plane   = decon_update_plane,
>   .disable_plane  = decon_disable_plane,
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index f3826dc..e4646e2 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -637,7 +637,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
>   .enable = decon_enable,
>   .disable = decon_disable,
>   .mode_fixup = decon_mode_fixup,
> - .commit = decon_commit,

Ditto.

Thanks,
Inki Dae

>   .enable_vblank = decon_enable_vblank,
>   .disable_vblank = decon_disable_vblank,
>   .wait_for_vblank = decon_wait_for_vblank,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 0bbe537..0f17ae0 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;
>   }
>  
> @@ -394,9 +382,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;
> @@ -630,9 +615,6 @@ static void fimd_atomic_begin(struct exynos_drm_crtc 
> *crtc,
>  {
>   struct fimd_context *ctx = crtc->ctx;
>  
> - if (ctx->suspended)
> - return

Re: [PATCH] drm/exynos: add cursor plane support

2015-09-04 Thread Inki Dae
On 2015년 09월 04일 16:19, Daniel Vetter wrote:
> On Fri, Sep 04, 2015 at 01:05:35PM +0900, Inki Dae wrote:
>> Hi Gustavo,
>>
>> I had already a review but I didn't give any comment to you. Sorry about
>> that. This patch looks good to me but one thing isn't clear. Below is my
>> comment.
>>
>>
>> On 2015년 09월 04일 05:14, Gustavo Padovan wrote:
>>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>>>
>>> Set one of the planes for each crtc driver as a cursor plane enabled
>>> window managers to fully work on exynos.
>>>
>>> Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>>> ---
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  9 ++---
>>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  8 ++--
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 +++
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 ++--
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 +++---
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  5 ++---
>>>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  9 ++---
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 10 +++---
>>>  8 files changed, 31 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index b3c7307..79b2b22 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -33,7 +33,6 @@ struct decon_context {
>>> struct exynos_drm_plane planes[WINDOWS_NR];
>>> void __iomem*addr;
>>> struct clk  *clks[6];
>>> -   unsigned intdefault_win;
>>> unsigned long   irq_flags;
>>> int pipe;
>>> boolsuspended;
>>> @@ -493,7 +492,6 @@ static int decon_bind(struct device *dev, struct device 
>>> *master, void *data)
>>> struct drm_device *drm_dev = data;
>>> struct exynos_drm_private *priv = drm_dev->dev_private;
>>> struct exynos_drm_plane *exynos_plane;
>>> -   enum drm_plane_type type;
>>> unsigned int zpos;
>>> int ret;
>>>  
>>> @@ -501,16 +499,14 @@ static int decon_bind(struct device *dev, struct 
>>> device *master, void *data)
>>> ctx->pipe = priv->pipe++;
>>>  
>>> for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
>>> -   type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
>>> -   DRM_PLANE_TYPE_OVERLAY;
>>> ret = exynos_plane_init(drm_dev, >planes[zpos],
>>> -   1 << ctx->pipe, type, decon_formats,
>>> +   1 << ctx->pipe, decon_formats,
>>> ARRAY_SIZE(decon_formats), zpos);
>>> if (ret)
>>> return ret;
>>> }
>>>  
>>> -   exynos_plane = >planes[ctx->default_win];
>>> +   exynos_plane = >planes[DEFAULT_WIN];
>>> ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>>> ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>>> _crtc_ops, ctx);
>>> @@ -607,7 +603,6 @@ static int exynos5433_decon_probe(struct 
>>> platform_device *pdev)
>>> if (!ctx)
>>> return -ENOMEM;
>>>  
>>> -   ctx->default_win = 0;
>>> ctx->suspended = true;
>>> ctx->dev = dev;
>>> if (of_get_child_by_name(dev->of_node, "i80-if-timings"))
>>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> index cbdb78e..f3826dc 100644
>>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> @@ -52,7 +52,6 @@ struct decon_context {
>>> struct clk  *eclk;
>>> struct clk  *vclk;
>>> void __iomem*regs;
>>> -   unsigned intdefault_win;
>>> unsigned long   irq_flags;
>>> booli80_if;
>>> bools

Re: [PATCH] drm/exynos: add cursor plane support

2015-09-03 Thread Inki Dae
= exynos_plane_init(drm_dev, >planes[zpos],
> - 1 << ctx->pipe, type, decon_formats,
> + 1 << ctx->pipe, decon_formats,
>   ARRAY_SIZE(decon_formats), zpos);
>   if (ret)
>   return ret;
>   }
>  
> - exynos_plane = >planes[ctx->default_win];
> + exynos_plane = >planes[DEFAULT_WIN];
>   ctx->crtc = exynos_drm_crtc_create(drm_dev, _plane->base,
>  ctx->pipe, EXYNOS_DISPLAY_TYPE_LCD,
>  _crtc_ops, ctx);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index b7ba21d..cc56c3d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -22,6 +22,9 @@
>  #define MAX_PLANE5
>  #define MAX_FB_BUFFER4
>  
> +#define DEFAULT_WIN  0
> +#define CURSOR_WIN   1

You fixed overlay number for cursor with 1. However, Display controllers
of Exynos SoC have fixed overlay priority like this,

win 4 > win 3 > win 2 > win 1 > win 0 so if we fix the overlay number
for cursor and we use another overlay - which has a higher layer than
cursor - to display caption or UI then the we couldn't see the cursor on
screen without additional work such as color key or alpha channel.

So before that, you need to check how many overlays can be used
according to Exynos SoC versions, and which way is better - one is for
top layer to be fixed for cursor, other is for one given layer to be
fixed by user-space for cursor.

Thanks,
Inki Dae

> +



--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 10/14] exynos/fimg2d: remove default case from g2d_get_blend_op()

2015-08-31 Thread Inki Dae
On 2015년 09월 01일 03:53, Emil Velikov wrote:
> On 31 August 2015 at 14:25, Inki Dae <inki@samsung.com> wrote:
>> On 2015년 08월 24일 23:14, Tobias Jakobi wrote:
>>> We now validate the blending mode via g2d_validate_mode()
>>> prior to feeding it to g2d_get_blend_op().
>>>
>>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>>> ---
>>>  exynos/exynos_fimg2d.c | 5 -
>>>  1 file changed, 5 deletions(-)
>>>
>>> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
>>> index 4274a94..d708e91 100644
>>> --- a/exynos/exynos_fimg2d.c
>>> +++ b/exynos/exynos_fimg2d.c
>>> @@ -91,11 +91,6 @@ static unsigned int g2d_get_blend_op(enum e_g2d_op op)
>>>   SET_BF(val, G2D_COEFF_MODE_SRC_ALPHA, 0, 0, 0,
>>>   G2D_COEFF_MODE_SRC_ALPHA, 1, 0, 0);
>>>   break;
>>> - default:
>>> - fprintf(stderr, "Not support operation(%d).\n", op);
>>> - SET_BF(val, G2D_COEFF_MODE_ONE, 0, 0, 0, G2D_COEFF_MODE_ZERO,
>>> - 0, 0, 0);
>>> - break;
>>
>> With this, how about changing above switch and case statement to if
>> statement?
>>
> Out of curiosity: why is if/else statement preferred - won't it make
> things longer/harder to read (there are 11 cases here) ?

Just looks strange to me switch and case statement has no default
statement. This is just my opinion and trivial.

Thanks,
Inki Dae

> 
> Cheers,
> Emil
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 04/14] exynos/fimg2d: check buffer space in g2d_solid_fill()

2015-08-31 Thread Inki Dae
On 2015년 09월 01일 04:57, Emil Velikov wrote:
> On 31 August 2015 at 20:27, Tobias Jakobi <tjak...@math.uni-bielefeld.de> 
> wrote:
>> Hello!
>>
>> Inki Dae wrote:
>>> On 2015년 08월 24일 23:13, Tobias Jakobi wrote:
> 
>>>> +if (g2d_check_space(ctx, 7, 1))
>>>> +return -ENOSPC;
>>>
>>> You can make 3 and 4 patches to one. These should be same patch.
>> Hmm, so which 3 (respectively 4) patches should be squashed?
>>
> I believe he meant "squash the introduction of the function and its
> uses into a single patch".
> 
> Not sure how much value that brings, so I'll let you guys decide on
> the bike shed colour :-)

That - including relevant my comments - is just my opinion so no problem
to upstream it as is. This is really trivial.

Thanks,
Inki Dae

> 
> -Emil
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/14] drm/exynos: rewrite fimg2d error handling

2015-08-31 Thread Inki Dae
On 2015년 08월 28일 05:46, Tobias Jakobi wrote:
> Hey Emil,
> 
> 
> Emil Velikov wrote:
>> Hi Tobias,
>>
>> On 24 August 2015 at 15:13, Tobias Jakobi <tjak...@math.uni-bielefeld.de> 
>> wrote:
>>> Hello,
>>>
>>> during the discussion about the last patchset touching the
>>> fimg2d code, it became apparent that the error handling for
>>> the command submission is currently unsatisfactory.
>>>
>>> This series rewrites the handling. All functions that submit
>>> command buffers now first check if enough space is available
>>> and only then proceed to build the command buffers.
>>>
>>> In particular the command buffer is no longer left in a
>>> half-finished state, since parameters passed to the functions
>>> are now validated before command submission. For this some
>>> validation functions are introduced.
>>>
>>> This should also increase performance if the bottleneck is
>>> the submission part, since adding commands to the buffer
>>> is now more lightweight.
>>>
>>> Last but not least some prefix was added to messages printed
>>> by fprintf and printf, and the G2D context struct was moved
>>> out of the public header.
>>>
>>>
>> Thanks for going with my earlier suggestion and untangling all this.
>>
>> I've went through the lot and it looks great afaict. Fwiw for the series
>> Reviewed-by: Emil Velikov <emil.l.veli...@gmail.com>
> thanks for the review and the help on IRC!
> 
> 
>> As pretty much none of this is hardware specific and/or requires
>> additional knowledge of the kernel module I'm inclined to pull this in
>> even if we don't get too many reviewers. We better keep it around for
>> a couple of weeks in case others are swamped with unrelated work atm,
>> yet willing to take a look.
> Sure, I'm going to wait and do some pings from time to time :)
> 

I had a review and looks good to me. There are just cleanup issues but
no problem to upstream them as-is. However, in my opinion, I think the
patch 7 could be more cleaned up.

Signed-off-by: Inki Dae <inki@samsung.com>

Thanks,
Inki Dae


> 
> With best wishes,
> Tobias
> 
>>
>> Cheers,
>> Emil
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 05/14] exynos/fimg2d: check buffer space in g2d_copy()

2015-08-31 Thread Inki Dae
On 2015년 08월 24일 23:14, Tobias Jakobi wrote:
> Move the parameter validation before buffer space checking
> so that we can exit early if it fails.
> Also don't reset the G2D context anymore in this situation
> (since the buffers are not partially submitted).
> 
> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> ---
>  exynos/exynos_fimg2d.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 9b7bcce..185aa80 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -375,17 +375,7 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
>  {
>   union g2d_rop4_val rop4;
>   union g2d_point_val pt;
> - unsigned int src_w = 0, src_h = 0, dst_w = 0, dst_h = 0;
> -
> - g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
> - g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
> - g2d_add_base_addr(ctx, dst, g2d_dst);
> - g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
> -
> - g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
> - g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
> - g2d_add_base_addr(ctx, src, g2d_src);
> - g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
> + unsigned int src_w, src_h, dst_w, dst_h;
>  
>   src_w = w;
>   src_h = h;
> @@ -406,10 +396,22 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
>  
>   if (w <= 0 || h <= 0) {
>   fprintf(stderr, "invalid width or height.\n");
> - g2d_reset(ctx);
>   return -EINVAL;
>   }
>  
> + if (g2d_check_space(ctx, 11, 2))
> + return -ENOSPC;

Above lines could be integrated with 3 and 4 patches as one patch. And
you can make other codes to other one.

Thanks,
Inki Dae

> +
> + g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
> + g2d_add_cmd(ctx, DST_COLOR_MODE_REG, dst->color_mode);
> + g2d_add_base_addr(ctx, dst, g2d_dst);
> + g2d_add_cmd(ctx, DST_STRIDE_REG, dst->stride);
> +
> + g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
> + g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, src->color_mode);
> + g2d_add_base_addr(ctx, src, g2d_src);
> + g2d_add_cmd(ctx, SRC_STRIDE_REG, src->stride);
> +
>   pt.val = 0;
>   pt.data.x = src_x;
>   pt.data.y = src_y;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 10/14] exynos/fimg2d: remove default case from g2d_get_blend_op()

2015-08-31 Thread Inki Dae
On 2015년 08월 24일 23:14, Tobias Jakobi wrote:
> We now validate the blending mode via g2d_validate_mode()
> prior to feeding it to g2d_get_blend_op().
> 
> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> ---
>  exynos/exynos_fimg2d.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 4274a94..d708e91 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -91,11 +91,6 @@ static unsigned int g2d_get_blend_op(enum e_g2d_op op)
>   SET_BF(val, G2D_COEFF_MODE_SRC_ALPHA, 0, 0, 0,
>   G2D_COEFF_MODE_SRC_ALPHA, 1, 0, 0);
>   break;
> - default:
> - fprintf(stderr, "Not support operation(%d).\n", op);
> - SET_BF(val, G2D_COEFF_MODE_ONE, 0, 0, 0, G2D_COEFF_MODE_ZERO,
> - 0, 0, 0);
> - break;

With this, how about changing above switch and case statement to if
statement?

Thanks,
Inki Dae


>   }
>  
>   return val.val;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 07/14] exynos/fimg2d: add g2d_validate_xyz() functions

2015-08-31 Thread Inki Dae
On 2015년 08월 24일 23:14, Tobias Jakobi wrote:
> The G2D headers define a number of modes through enums
> (like e.g. color, select, repeat, etc.).
> 
> This introduces g2d_validate_select_mode() and
> g2d_validate_blending_op() which validate a
> select mode or blending operation respectively.
> 
> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> ---
>  exynos/exynos_fimg2d.c | 44 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 2e04f4a..781aff5 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -119,6 +119,50 @@ static unsigned int g2d_check_space(const struct 
> g2d_context *ctx,
>  }
>  
>  /*
> + * g2d_validate_select_mode - validate select mode.
> + *
> + * @mode: the mode to validate
> + */
> +static unsigned int g2d_validate_select_mode(
> + enum e_g2d_select_mode mode)
> +{
> + switch (mode) {
> + case G2D_SELECT_MODE_NORMAL:
> + case G2D_SELECT_MODE_FGCOLOR:
> + case G2D_SELECT_MODE_BGCOLOR:
> + return 0;
> + }

It's strange use a bit. Just check the range like below,

First, please add G2D_SELECT_MODE_MAX which has 3 << 0, and

if (G2D_SELECT_MODE_MAX < mode) {
fprintf(strerr, "invalid command(0x%x)\n", mode);
return -EINVAL;
}

And I think it'd be better to change return type of this function to int,

> +
> + return 1;

so return 0

> +}
> +
> +/*
> + * g2d_validate_blending_op - validate blending operation.
> + *
> + * @operation: the operation to validate
> + */
> +static unsigned int g2d_validate_blending_op(
> + enum e_g2d_op operation)
> +{
> + switch (operation) {
> + case G2D_OP_CLEAR:
> + case G2D_OP_SRC:
> + case G2D_OP_DST:
> + case G2D_OP_OVER:
> + case G2D_OP_INTERPOLATE:
> + case G2D_OP_DISJOINT_CLEAR:
> + case G2D_OP_DISJOINT_SRC:
> + case G2D_OP_DISJOINT_DST:
> + case G2D_OP_CONJOINT_CLEAR:
> + case G2D_OP_CONJOINT_SRC:
> + case G2D_OP_CONJOINT_DST:
> + return 0;

Ditto, You could modify it like above.

Thanks,
Inki Dae

> + }
> +
> + return 1;
> +}
> +
> +/*
>   * g2d_add_cmd - set given command and value to user side command buffer.
>   *
>   * @ctx: a pointer to g2d_context structure.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


  1   2   3   4   5   6   >