from:"Inki Dae"

[PATCH] drm/exynos/hdmi: refactor infoframe code

2016-11-07 Thread Inki Dae



2016ë 10ì 26ì¼ 21:36ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Use core helpers to generate infoframes and generate vendor frame if 
> necessary.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 141 
> ++-
>  drivers/gpu/drm/exynos/regs-hdmi.h   |   2 +
>  2 files changed, 42 insertions(+), 101 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index e8fb6ef..1bb2df7 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -47,19 +47,6 @@
>  
>  #define HOTPLUG_DEBOUNCE_MS  1100
>  
> -/* AVI header and aspect ratio */
> -#define HDMI_AVI_VERSION 0x02
> -#define HDMI_AVI_LENGTH  0x0d
> -
> -/* AUI header info */
> -#define HDMI_AUI_VERSION 0x01
> -#define HDMI_AUI_LENGTH  0x0a
> -
> -/* AVI active format aspect ratio */
> -#define AVI_SAME_AS_PIC_ASPECT_RATIO 0x08
> -#define AVI_4_3_CENTER_RATIO 0x09
> -#define AVI_16_9_CENTER_RATIO0x0a
> -
>  enum hdmi_type {
>   HDMI_TYPE13,
>   HDMI_TYPE14,
> @@ -131,7 +118,6 @@ struct hdmi_context {
>   booldvi_mode;
>   struct delayed_work hotplug_work;
>   struct drm_display_mode current_mode;
> - u8  cea_video_id;
>   const struct hdmi_driver_data   *drv_data;
>  
>   void __iomem*regs;
> @@ -681,6 +667,13 @@ static inline void hdmi_reg_writev(struct hdmi_context 
> *hdata, u32 reg_id,
>   }
>  }
>  
> +static inline void hdmi_reg_write_buf(struct hdmi_context *hdata, u32 reg_id,
> +   u8 *buf, int size)
> +{
> + for (reg_id = hdmi_map_reg(hdata, reg_id); size; --size, reg_id += 4)
> + writel(*buf++, hdata->regs + reg_id);
> +}
> +
>  static inline void hdmi_reg_writemask(struct hdmi_context *hdata,
>u32 reg_id, u32 value, u32 mask)
>  {
> @@ -762,93 +755,50 @@ static int hdmi_clk_set_parents(struct hdmi_context 
> *hdata, bool to_phy)
>   return ret;
>  }
>  
> -static u8 hdmi_chksum(struct hdmi_context *hdata,
> - u32 start, u8 len, u32 hdr_sum)
> -{
> - int i;
> -
> - /* hdr_sum : header0 + header1 + header2
> - * start : start address of packet byte1
> - * len : packet bytes - 1 */
> - for (i = 0; i < len; ++i)
> - hdr_sum += 0xff & hdmi_reg_read(hdata, start + i * 4);
> -
> - /* return 2's complement of 8 bit hdr_sum */
> - return (u8)(~(hdr_sum & 0xff) + 1);
> -}
> -
> -static void hdmi_reg_infoframe(struct hdmi_context *hdata,
> - union hdmi_infoframe *infoframe)
> +static void hdmi_reg_infoframes(struct hdmi_context *hdata)
>  {
> - u32 hdr_sum;
> - u8 chksum;
> - u8 ar;
> + union hdmi_infoframe frm;
> + u8 buf[25];
> + int ret;
>  
>   if (hdata->dvi_mode) {
> - hdmi_reg_writeb(hdata, HDMI_VSI_CON,
> - HDMI_VSI_CON_DO_NOT_TRANSMIT);
>   hdmi_reg_writeb(hdata, HDMI_AVI_CON,
>   HDMI_AVI_CON_DO_NOT_TRANSMIT);
> + hdmi_reg_writeb(hdata, HDMI_VSI_CON,
> + HDMI_VSI_CON_DO_NOT_TRANSMIT);
>   hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_NO_TRAN);
>   return;
>   }
>  
> - switch (infoframe->any.type) {
> - case HDMI_INFOFRAME_TYPE_AVI:
> + ret = drm_hdmi_avi_infoframe_from_display_mode(&frm.avi,
> + &hdata->current_mode);
> + if (ret >= 0)

Seems above condition is not clear becuase 
drm_hdmi_avi_infoframe_from_display_mode function returns 0 or negative value.

> + ret = hdmi_avi_infoframe_pack(&frm.avi, buf, sizeof(buf));
> + if (ret > 0) {
>   hdmi_reg_writeb(hdata, HDMI_AVI_CON, HDMI_AVI_CON_EVERY_VSYNC);

I think above code should be called when 
drm_hdmi_avi_infoframe_from_display_mode function returned 0 and the value from 
hdmi_avi_infoframe_pack function is more than 1.

> - hdmi_reg_writeb(hdata, HDMI_AVI_HEADER0, infoframe->any.type);
> - hdmi_reg_writeb(hdata, HDMI_AVI_HEADER1,
> - infoframe->any.version);
> - hdmi_reg_writeb(hdata, HDMI_AVI_HEADER2, infoframe->any.length);
> - hdr_sum = infoframe->any.type + infoframe->any.version +
> -   infoframe->any.length;
> -
> - /* Output format zero hardcoded ,RGB YBCR selection */
> - hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(1), 0 << 5 |
> - AVI_ACTIVE_FORMAT_VALID |
> - AVI_UNDERSCANNED_DISPLAY_VALID);
> -
> - /*
> -  * Set the aspect ratio as per the mode, mentioned in
> -  * Table 9 AVI InfoFrame Data Byte 2 of CEA-861-D S

[PATCH V2] gpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap

2016-10-19 Thread Inki Dae

Will pick it up soon.

Thanks,
Inki Dae

2016-10-19 19:04 GMT+09:00 Arvind Yadav :
> Free memory mapping, if hdmi_probe is not successful.
>
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..ba28dec 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
>  err_hdmiphy:
> if (hdata->hdmiphy_port)
> put_device(&hdata->hdmiphy_port->dev);
> +   if (hdata->regs_hdmiphy)
> +   iounmap(hdata->regs_hdmiphy);
>  err_ddc:
> put_device(&hdata->ddc_adpt->dev);
>
> @@ -1923,6 +1925,9 @@ static int hdmi_remove(struct platform_device *pdev)
> if (hdata->hdmiphy_port)
> put_device(&hdata->hdmiphy_port->dev);
>
> +   if (hdata->regs_hdmiphy)
> +   iounmap(hdata->regs_hdmiphy);
> +
> put_device(&hdata->ddc_adpt->dev);
>
> return 0;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

2016-10-19 Thread Inki Dae

Hi Shuah,

2016-10-13 8:11 GMT+09:00 Shuah Khan :
> Hi Inki,
>
> On 08/15/2016 10:40 PM, Inki Dae wrote:
>
>>>
>>> okay the very first commit that added IOMMU support
>>> introduced the code that rejects non-contig gem memory
>>> type without IOMMU.
>>>
>>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>>> Author: Inki Dae 
>>> Date:   Sat Oct 20 07:53:42 2012 -0700
>>>
>>> drm/exynos: add iommu support for exynos drm framework
>>>
>
> I haven't given up on this yet. I am still seeing the following failure:
>
> Additional debug messages I added:
> [   15.287403] exynos_drm_gem_create_ioctl() 1
> [   15.287419] exynos_drm_gem_create() flags 1
>
> [   15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM 
> memory is not supported.
>
> Additional debug message I added:
> [   15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize 
> framebuffer
>
> This is what happens:
>
> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>check_fb_gem_memory_type()
>
> At this point, there is no recovery and lightdm fails
>
> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
> allocations are not supported in some exynos drm versions: The following
> commit introduced this change:
>
> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>
> excerpts from the diff:-   if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
> -   create_exynos.flags = EXYNOS_BO_CONTIG;
> -   else
> -   create_exynos.flags = EXYNOS_BO_NONCONTIG;
> +
> +   /* Contiguous allocations are not supported in some exynos drm 
> versions.
> +* When they are supported all allocations are effectively contiguous
> +* anyway, so for simplicity we always request non contiguous buffers.
> +*/
> +   create_exynos.flags = EXYNOS_BO_NONCONTIG;
>

Above comment, "Contiguous allocations are not supported in some
exynos drm versions.", seems wrong assumption.
The root cause, contiguous allocation is not supported, would be that
they used Linux kernel which didn't have CMA region enough - as
default 16MB, or didn't declare CMA region enough for the DMA device.
So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
should manage the error case if the allocation failed.

> There might have been logic on exynos_drm that forced Contig when it coudn't
> support NONCONTIG. At least, that is what this comment suggests. This 
> assumption
> doesn't appear to be a good one and not sure if this change was made to fix a 
> bug.
>
> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>
> This is what I am running into. This leads to the following question:
>
> 1. How do we ensure exynos_drm kernel changes don't break user-space
>specifically xf86-video-armsoc
> 2. This seems to have gone undetected for a while. I see a change in
>exynos_drm_gem_dumb_create() that is probably addressing this type
>of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>handling for IOMMU NONCONTIG case.

Seems this patch has a problem. This patch forces to flag NONCONTIG if
iommu is enabled. The flag should be depend on the argument from
user-space.
I.e., if user-space requested a gem allocation with CONTIG flag, then
Exynos drm driver should allocate contiguous memory even though iommu
is enabled.

>
> Anyway, I am interested in getting the exynos_drm kernel side code
> and xf86-video-armsoc in sync to resolve the issue.
>
> Could you recommend a going forward plan?

My opinion are,

1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
2. Do not force to flag NONCONTIG at Exynos drm driver even though
iommu is enabled and flag allocation type with the argument from
user-space.

I think you could try to post above patches.

Thanks,
Inki Dae

>
> I can submit a patch to xf86-video-armsoc. I am also looking ahead to
> see if we can avoid such breaks in the future by keeping kernel and
> xf86-video-armsoc in sync.
>
> thanks,
> -- Shuah
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] exynos-drm: Fix error messages to print flags and size

2016-10-19 Thread Inki Dae

2016-10-06 22:09 GMT+09:00 Tobias Jakobi :
> Hello,
>
> I think this patch was never picked up. So just a short 'ping' from my side.
>

Oops. one I missed. Will pick it up soon.

Thanks,
Inki Dae

> With best wishes,
> Tobias
>
>
> Shuah Khan wrote:
>> Fix exynos_drm_gem_create() error messages to include flags and size when
>> flags and size are invalid.
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index cdf9f1a..4c4cb0e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -231,12 +231,12 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
>> drm_device *dev,
>>   int ret;
>>
>>   if (flags & ~(EXYNOS_BO_MASK)) {
>> - DRM_ERROR("invalid flags.\n");
>> + DRM_ERROR("invalid GEM buffer flags: %u\n", flags);
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>>   if (!size) {
>> - DRM_ERROR("invalid size.\n");
>> + DRM_ERROR("invalid GEM buffer size: %lu\n", size);
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-next

2016-10-01 Thread Inki Dae

Hi Dave,

   This pull request includes,
- Code refactoring on HDMI DDC and PHY.
- Regression fixup on deadlock issue with G2D pm integration.
- Fixup on page fault issue with wait_for_vblank mechianism specific to 
Exynos drm.
- And some cleanups.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae


The following changes since commit 28a396545a2a5fbdffb2b661ed6c9b6820e28772:

  Merge branch 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2016-09-30 13:21:02 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to c0462796464219fed0fbc1e8b2b93eb6751769f5:

  drm/exynos: g2d: simplify g2d_free_runqueue_node() (2016-10-01 00:39:42 +0900)


Andrzej Hajda (4):
  drm/exynos/vidi: use timer for vblanks instead of sleeping worker
  drm/exynos: fix pending update handling
  drm/exynos/fimd: add clock rate checking
  drm/exynos: use drm core to handle page-flip event

Baoyou Xie (1):
  drm/exynos: mark exynos_dp_crtc_clock_enable() static

Milo Kim (3):
  gpu: drm: exynos_hdmi: Move DDC logic into single function
  gpu: drm: exynos_hdmi: Move PHY logic into single function
  gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk 
consumer

Tobias Jakobi (9):
  drm/exynos: mixer: convert booleans to flags in mixer context
  drm/exynos: mixer: simplify loop in vp_win_reset()
  drm/exynos: g2d: beautify probing message
  Revert "drm/exynos: g2d: fix system and runtime pm integration"
  drm/exynos: g2d: move PM management to runqueue worker
  drm/exynos: g2d: remove runqueue nodes in g2d_{close,remove}()
  drm/exynos: g2d: wait for engine to finish
  drm/exynos: g2d: use autosuspend mode for PM runtime
  drm/exynos: g2d: simplify g2d_free_runqueue_node()

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |   11 --
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|9 -
 drivers/gpu/drm/exynos/exynos_dp.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   58 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |   44 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |4 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   54 +++---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  239 +++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c |1 -
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   76 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  112 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c |   68 ---
 12 files changed, 352 insertions(+), 326 deletions(-)

[PATCH 08/20] drm/exynos: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

2016-10-01 Thread Inki Dae

 Acked-by: Inki Dae 

Thanks,
Inki Dae

2016-09-30 5:48 GMT+09:00 Stefan Christ :
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Signed-off-by: Stefan Christ 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 4cfb39d..9f35deb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -63,15 +63,11 @@ static int exynos_drm_fb_mmap(struct fb_info *info,
>
>  static struct fb_ops exynos_drm_fb_ops = {
> .owner  = THIS_MODULE,
> +   DRM_FB_HELPER_DEFAULT_OPS,
> .fb_mmap= exynos_drm_fb_mmap,
> .fb_fillrect= drm_fb_helper_cfb_fillrect,
> .fb_copyarea= drm_fb_helper_cfb_copyarea,
> .fb_imageblit   = drm_fb_helper_cfb_imageblit,
> -   .fb_check_var   = drm_fb_helper_check_var,
> -   .fb_set_par = drm_fb_helper_set_par,
> -   .fb_blank   = drm_fb_helper_blank,
> -   .fb_pan_display = drm_fb_helper_pan_display,
> -   .fb_setcmap = drm_fb_helper_setcmap,
>  };
>
>  static int exynos_drm_fbdev_update(struct drm_fb_helper *helper,
> --
> 2.7.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-29 Thread Inki Dae



2016ë 09ì 29ì¼ 01:28ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Inki Dae wrote:
>> 2016-09-28 18:06 GMT+09:00 Tobias Jakobi :
>>> Hello Inki,
>>>
>>>
>>> Inki Dae wrote:
>>>>
>>>>
>>>> 2016ë 09ì 28ì¼ 09:03ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>> Hey Inki,
>>>>>
>>>>>
>>>>> Inki Dae wrote:
>>>>>>
>>>>>>
>>>>>> 2016ë 09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>>>> Hello Andrzej,
>>>>>>>
>>>>>>>
>>>>>>> Andrzej Hajda wrote:
>>>>>>>> On 27.09.2016 13:22, Tobias Jakobi wrote:
>>>>>>>>> Hello Inki,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Inki Dae wrote:
>>>>>>>>>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>>>>>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>>>>>>>>>> in mixer_cfg_layer().
>>>>>>>>>>> Trigger this via atomic flush.
>>>>>>>>>>>
>>>>>>>>>>> Changes in v2:
>>>>>>>>>>> - issue mixer_cfg_layer() in mixer_disable()
>>>>>>>>>>> - rename fields as suggested by Andrzej
>>>>>>>>>>> - added docu to mixer context struct
>>>>>>>>>>> - simplify mixer_win_reset() as well
>>>>>>>>>>>
>>>>>>>>>>> Changes in v3:
>>>>>>>>>>> - simplify some conditions as suggested by Inki
>>>>>>>>>>> - add docu to mixer_cfg_layer()
>>>>>>>>>>> - fold switch statements into a single one
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Tobias Jakobi 
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>>>>>>>>>> ++
>>>>>>>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>>>>>>>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>>>>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>>>>> index 1e78d57..4f06f4d 100644
>>>>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>>>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>>>>>>>>>DRM_FORMAT_NV21,
>>>>>>>>>>>  };
>>>>>>>>>>>
>>>>>>>>>>> +/*
>>>>>>>>>>> + * Mixer context structure.
>>>>>>>>>>> + *
>>>>>>>>>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>>>>>>>>>> + * @planes: Array of plane objects for each of the mixer windows.
>>>>>>>>>>> + * @active_windows: Cache of the mixer's hardware state.
>>>>>>>>>>> + *   Tracks which mixer windows are active/inactive.
>>>>>>>>>>> + * @pipe: The CRTC index.
>>>>>>>>>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>>>>>>>>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>>>>>>>>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>>>>>>>>>> + */
>>>>>>>>>>>  struct mixer_context {
>>>>>>>>>>>struct platform_device *pdev;
>>>>>>>>>>>struct device   *dev;
>>>>>>>>>>>struct drm_device   *drm_dev;
>>>>>>>>>>>struct exynos_drm_crtc  *crtc;
>>>>>>>>>>>struct exynos_drm_plane planes[MIXER_WIN_NR];
>>>>

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-29 Thread Inki Dae

2016-09-28 18:06 GMT+09:00 Tobias Jakobi :
> Hello Inki,
>
>
> Inki Dae wrote:
>>
>>
>> 2016ë 09ì 28ì¼ 09:03ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> Hey Inki,
>>>
>>>
>>> Inki Dae wrote:
>>>>
>>>>
>>>> 2016ë 09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>> Hello Andrzej,
>>>>>
>>>>>
>>>>> Andrzej Hajda wrote:
>>>>>> On 27.09.2016 13:22, Tobias Jakobi wrote:
>>>>>>> Hello Inki,
>>>>>>>
>>>>>>>
>>>>>>> Inki Dae wrote:
>>>>>>>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>>>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>>>>>>>> in mixer_cfg_layer().
>>>>>>>>> Trigger this via atomic flush.
>>>>>>>>>
>>>>>>>>> Changes in v2:
>>>>>>>>> - issue mixer_cfg_layer() in mixer_disable()
>>>>>>>>> - rename fields as suggested by Andrzej
>>>>>>>>> - added docu to mixer context struct
>>>>>>>>> - simplify mixer_win_reset() as well
>>>>>>>>>
>>>>>>>>> Changes in v3:
>>>>>>>>> - simplify some conditions as suggested by Inki
>>>>>>>>> - add docu to mixer_cfg_layer()
>>>>>>>>> - fold switch statements into a single one
>>>>>>>>>
>>>>>>>>> Signed-off-by: Tobias Jakobi 
>>>>>>>>> ---
>>>>>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>>>>>>>> ++
>>>>>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>>>>>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>>> index 1e78d57..4f06f4d 100644
>>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>>>>>>>DRM_FORMAT_NV21,
>>>>>>>>>  };
>>>>>>>>>
>>>>>>>>> +/*
>>>>>>>>> + * Mixer context structure.
>>>>>>>>> + *
>>>>>>>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>>>>>>>> + * @planes: Array of plane objects for each of the mixer windows.
>>>>>>>>> + * @active_windows: Cache of the mixer's hardware state.
>>>>>>>>> + *   Tracks which mixer windows are active/inactive.
>>>>>>>>> + * @pipe: The CRTC index.
>>>>>>>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>>>>>>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>>>>>>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>>>>>>>> + */
>>>>>>>>>  struct mixer_context {
>>>>>>>>>struct platform_device *pdev;
>>>>>>>>>struct device   *dev;
>>>>>>>>>struct drm_device   *drm_dev;
>>>>>>>>>struct exynos_drm_crtc  *crtc;
>>>>>>>>>struct exynos_drm_plane planes[MIXER_WIN_NR];
>>>>>>>>> +  unsigned long   active_windows;
>>>>>>>>>int pipe;
>>>>>>>>>unsigned long   flags;
>>>>>>>>>
>>>>>>>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct 
>>>>>>>>> mixer_context *ctx, unsigned int height)
>>>>>>>>>mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>>>>>>>  }
>>>>>>>>>
>>>>>>>>> -static void mixer_cfg_layer(struc

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-28 Thread Inki Dae



2016ë 09ì 28ì¼ 09:03ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Hey Inki,
> 
> 
> Inki Dae wrote:
>>
>>
>> 2016ë 09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> Hello Andrzej,
>>>
>>>
>>> Andrzej Hajda wrote:
>>>> On 27.09.2016 13:22, Tobias Jakobi wrote:
>>>>> Hello Inki,
>>>>>
>>>>>
>>>>> Inki Dae wrote:
>>>>>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>>>>>> in mixer_cfg_layer().
>>>>>>> Trigger this via atomic flush.
>>>>>>>
>>>>>>> Changes in v2:
>>>>>>> - issue mixer_cfg_layer() in mixer_disable()
>>>>>>> - rename fields as suggested by Andrzej
>>>>>>> - added docu to mixer context struct
>>>>>>> - simplify mixer_win_reset() as well
>>>>>>>
>>>>>>> Changes in v3:
>>>>>>> - simplify some conditions as suggested by Inki
>>>>>>> - add docu to mixer_cfg_layer()
>>>>>>> - fold switch statements into a single one
>>>>>>>
>>>>>>> Signed-off-by: Tobias Jakobi 
>>>>>>> ---
>>>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>>>>>> ++
>>>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>>>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> index 1e78d57..4f06f4d 100644
>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>>>>> DRM_FORMAT_NV21,
>>>>>>>  };
>>>>>>>  
>>>>>>> +/*
>>>>>>> + * Mixer context structure.
>>>>>>> + *
>>>>>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>>>>>> + * @planes: Array of plane objects for each of the mixer windows.
>>>>>>> + * @active_windows: Cache of the mixer's hardware state.
>>>>>>> + *   Tracks which mixer windows are active/inactive.
>>>>>>> + * @pipe: The CRTC index.
>>>>>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>>>>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>>>>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>>>>>> + */
>>>>>>>  struct mixer_context {
>>>>>>> struct platform_device *pdev;
>>>>>>> struct device   *dev;
>>>>>>> struct drm_device   *drm_dev;
>>>>>>> struct exynos_drm_crtc  *crtc;
>>>>>>> struct exynos_drm_plane planes[MIXER_WIN_NR];
>>>>>>> +   unsigned long   active_windows;
>>>>>>> int pipe;
>>>>>>> unsigned long   flags;
>>>>>>>  
>>>>>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct 
>>>>>>> mixer_context *ctx, unsigned int height)
>>>>>>> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>>>>>  }
>>>>>>>  
>>>>>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int 
>>>>>>> win,
>>>>>>> -   unsigned int priority, bool enable)
>>>>>>> +/**
>>>>>>> + * mixer_cfg_layer - apply layer configuration to hardware
>>>>>>> + * @ctx: mixer context
>>>>>>> + *
>>>>>>> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
>>>>>>> + * using the 'active_windows' field of the the mixer content, and
>>>>>>> + * the pixel format of the framebuffers associated with the enabled
>>>>>>> + * windows.
>>>&

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-28 Thread Inki Dae



2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
> in mixer_cfg_layer().
> Trigger this via atomic flush.
> 
> Changes in v2:
> - issue mixer_cfg_layer() in mixer_disable()
> - rename fields as suggested by Andrzej
> - added docu to mixer context struct
> - simplify mixer_win_reset() as well
> 
> Changes in v3:
> - simplify some conditions as suggested by Inki
> - add docu to mixer_cfg_layer()
> - fold switch statements into a single one
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
> ++
>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>  2 files changed, 92 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 1e78d57..4f06f4d 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>   DRM_FORMAT_NV21,
>  };
>  
> +/*
> + * Mixer context structure.
> + *
> + * @crtc: The HDMI CRTC attached to the mixer.
> + * @planes: Array of plane objects for each of the mixer windows.
> + * @active_windows: Cache of the mixer's hardware state.
> + *   Tracks which mixer windows are active/inactive.
> + * @pipe: The CRTC index.
> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
> + * @mixer_resources: A struct containing registers, clocks, etc.
> + * @mxr_ver: The hardware revision/version of the mixer.
> + */
>  struct mixer_context {
>   struct platform_device *pdev;
>   struct device   *dev;
>   struct drm_device   *drm_dev;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
> + unsigned long   active_windows;
>   int pipe;
>   unsigned long   flags;
>  
> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
> *ctx, unsigned int height)
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>  }
>  
> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
> - unsigned int priority, bool enable)
> +/**
> + * mixer_cfg_layer - apply layer configuration to hardware
> + * @ctx: mixer context
> + *
> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
> + * using the 'active_windows' field of the the mixer content, and
> + * the pixel format of the framebuffers associated with the enabled
> + * windows.
> + *
> + * Has to be called under mixer lock.
> + */
> +static void mixer_cfg_layer(struct mixer_context *ctx)
>  {
>   struct mixer_resources *res = &ctx->mixer_res;
> - u32 val = enable ? ~0 : 0;
> -
> - switch (win) {
> - case 0:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP0_VAL(priority),
> - MXR_LAYER_CFG_GRP0_MASK);
> - break;
> - case 1:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP1_VAL(priority),
> - MXR_LAYER_CFG_GRP1_MASK);
> + unsigned int win;
>  
> - break;
> - case VP_DEFAULT_WIN:
> - if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
> - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
> - mixer_reg_writemask(res, MXR_CFG, val,
> - MXR_CFG_VP_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_VP_VAL(priority),
> - MXR_LAYER_CFG_VP_MASK);
> + struct exynos_drm_plane_state *state;
> + struct drm_framebuffer *fb;
> + unsigned int priority;
> + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
> + bool enable;
> +
> + for (win = 0; win < MIXER_WIN_NR; ++win) {
> + state = to_exynos_plane_state(ctx->planes[win].base.state);
> + fb = state->fb;
> +
> + priority = state->base.normalized_zpos + 1;
> + enable = test_bit(win, &ctx->active_windows);
> +
> + if (!enable)
> + continue;
> +
> + BUG_ON(!fb);
> +
> + /*
> +  * TODO: Don't enable alpha blending for the bottom window.
> +  */
> + switch (win) {
> + case 0:
> + mxr_cfg |=  MXR_CFG_GRP0_ENABLE;
> + mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority);
> + mixer_cfg_gfx_blend(ctx, win, 
> is_alpha_format(fb->pixel_format));
> + break;
> +
> + case

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-28 Thread Inki Dae



2016ë 09ì 28ì¼ 09:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Hello Inki,
> 
> 
> Inki Dae wrote:
>>
>>
>> 2016ë 09ì 28ì¼ 08:31ì Inki Dae ì´(ê°) ì´ ê¸:
>>>
>>>
>>> 2016ë 09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>> Hello Andrzej,
>>>>
>>>>
>>>> Andrzej Hajda wrote:
>>>>> On 27.09.2016 13:22, Tobias Jakobi wrote:
>>>>>> Hello Inki,
>>>>>>
>>>>>>
>>>>>> Inki Dae wrote:
>>>>>>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>>>>>>> in mixer_cfg_layer().
>>>>>>>> Trigger this via atomic flush.
>>>>>>>>
>>>>>>>> Changes in v2:
>>>>>>>> - issue mixer_cfg_layer() in mixer_disable()
>>>>>>>> - rename fields as suggested by Andrzej
>>>>>>>> - added docu to mixer context struct
>>>>>>>> - simplify mixer_win_reset() as well
>>>>>>>>
>>>>>>>> Changes in v3:
>>>>>>>> - simplify some conditions as suggested by Inki
>>>>>>>> - add docu to mixer_cfg_layer()
>>>>>>>> - fold switch statements into a single one
>>>>>>>>
>>>>>>>> Signed-off-by: Tobias Jakobi 
>>>>>>>> ---
>>>>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>>>>>>> ++
>>>>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>>>>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>> index 1e78d57..4f06f4d 100644
>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>>>>>>DRM_FORMAT_NV21,
>>>>>>>>  };
>>>>>>>>  
>>>>>>>> +/*
>>>>>>>> + * Mixer context structure.
>>>>>>>> + *
>>>>>>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>>>>>>> + * @planes: Array of plane objects for each of the mixer windows.
>>>>>>>> + * @active_windows: Cache of the mixer's hardware state.
>>>>>>>> + *   Tracks which mixer windows are active/inactive.
>>>>>>>> + * @pipe: The CRTC index.
>>>>>>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>>>>>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>>>>>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>>>>>>> + */
>>>>>>>>  struct mixer_context {
>>>>>>>>struct platform_device *pdev;
>>>>>>>>struct device   *dev;
>>>>>>>>struct drm_device   *drm_dev;
>>>>>>>>struct exynos_drm_crtc  *crtc;
>>>>>>>>struct exynos_drm_plane planes[MIXER_WIN_NR];
>>>>>>>> +  unsigned long   active_windows;
>>>>>>>>int pipe;
>>>>>>>>unsigned long   flags;
>>>>>>>>  
>>>>>>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct 
>>>>>>>> mixer_context *ctx, unsigned int height)
>>>>>>>>mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>>>>>>  }
>>>>>>>>  
>>>>>>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int 
>>>>>>>> win,
>>>>>>>> -  unsigned int priority, bool enable)
>>>>>>>> +/**
>>>>>>>> + * mixer_cfg_layer - apply layer configuration to hardware
>>>>>>>> + * @ctx: mi

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-28 Thread Inki Dae



2016ë 09ì 28ì¼ 09:03ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Hey Inki,
> 
> 
> Inki Dae wrote:
>>
>>
>> 2016ë 09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> Hello Andrzej,
>>>
>>>
>>> Andrzej Hajda wrote:
>>>> On 27.09.2016 13:22, Tobias Jakobi wrote:
>>>>> Hello Inki,
>>>>>
>>>>>
>>>>> Inki Dae wrote:
>>>>>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>>>>>> in mixer_cfg_layer().
>>>>>>> Trigger this via atomic flush.
>>>>>>>
>>>>>>> Changes in v2:
>>>>>>> - issue mixer_cfg_layer() in mixer_disable()
>>>>>>> - rename fields as suggested by Andrzej
>>>>>>> - added docu to mixer context struct
>>>>>>> - simplify mixer_win_reset() as well
>>>>>>>
>>>>>>> Changes in v3:
>>>>>>> - simplify some conditions as suggested by Inki
>>>>>>> - add docu to mixer_cfg_layer()
>>>>>>> - fold switch statements into a single one
>>>>>>>
>>>>>>> Signed-off-by: Tobias Jakobi 
>>>>>>> ---
>>>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>>>>>> ++
>>>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>>>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> index 1e78d57..4f06f4d 100644
>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>>>>> DRM_FORMAT_NV21,
>>>>>>>  };
>>>>>>>  
>>>>>>> +/*
>>>>>>> + * Mixer context structure.
>>>>>>> + *
>>>>>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>>>>>> + * @planes: Array of plane objects for each of the mixer windows.
>>>>>>> + * @active_windows: Cache of the mixer's hardware state.
>>>>>>> + *   Tracks which mixer windows are active/inactive.
>>>>>>> + * @pipe: The CRTC index.
>>>>>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>>>>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>>>>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>>>>>> + */
>>>>>>>  struct mixer_context {
>>>>>>> struct platform_device *pdev;
>>>>>>> struct device   *dev;
>>>>>>> struct drm_device   *drm_dev;
>>>>>>> struct exynos_drm_crtc  *crtc;
>>>>>>> struct exynos_drm_plane planes[MIXER_WIN_NR];
>>>>>>> +   unsigned long   active_windows;
>>>>>>> int pipe;
>>>>>>> unsigned long   flags;
>>>>>>>  
>>>>>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct 
>>>>>>> mixer_context *ctx, unsigned int height)
>>>>>>> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>>>>>  }
>>>>>>>  
>>>>>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int 
>>>>>>> win,
>>>>>>> -   unsigned int priority, bool enable)
>>>>>>> +/**
>>>>>>> + * mixer_cfg_layer - apply layer configuration to hardware
>>>>>>> + * @ctx: mixer context
>>>>>>> + *
>>>>>>> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
>>>>>>> + * using the 'active_windows' field of the the mixer content, and
>>>>>>> + * the pixel format of the framebuffers associated with the enabled
>>>>>>> + * windows.
>>>&

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-28 Thread Inki Dae



2016ë 09ì 28ì¼ 08:31ì Inki Dae ì´(ê°) ì´ ê¸:
> 
> 
> 2016ë 09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Hello Andrzej,
>>
>>
>> Andrzej Hajda wrote:
>>> On 27.09.2016 13:22, Tobias Jakobi wrote:
>>>> Hello Inki,
>>>>
>>>>
>>>> Inki Dae wrote:
>>>>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>>>>> in mixer_cfg_layer().
>>>>>> Trigger this via atomic flush.
>>>>>>
>>>>>> Changes in v2:
>>>>>> - issue mixer_cfg_layer() in mixer_disable()
>>>>>> - rename fields as suggested by Andrzej
>>>>>> - added docu to mixer context struct
>>>>>> - simplify mixer_win_reset() as well
>>>>>>
>>>>>> Changes in v3:
>>>>>> - simplify some conditions as suggested by Inki
>>>>>> - add docu to mixer_cfg_layer()
>>>>>> - fold switch statements into a single one
>>>>>>
>>>>>> Signed-off-by: Tobias Jakobi 
>>>>>> ---
>>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>>>>> ++
>>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>> index 1e78d57..4f06f4d 100644
>>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>>>>  DRM_FORMAT_NV21,
>>>>>>  };
>>>>>>  
>>>>>> +/*
>>>>>> + * Mixer context structure.
>>>>>> + *
>>>>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>>>>> + * @planes: Array of plane objects for each of the mixer windows.
>>>>>> + * @active_windows: Cache of the mixer's hardware state.
>>>>>> + *   Tracks which mixer windows are active/inactive.
>>>>>> + * @pipe: The CRTC index.
>>>>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>>>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>>>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>>>>> + */
>>>>>>  struct mixer_context {
>>>>>>  struct platform_device *pdev;
>>>>>>  struct device   *dev;
>>>>>>  struct drm_device   *drm_dev;
>>>>>>  struct exynos_drm_crtc  *crtc;
>>>>>>  struct exynos_drm_plane planes[MIXER_WIN_NR];
>>>>>> +unsigned long   active_windows;
>>>>>>  int pipe;
>>>>>>  unsigned long   flags;
>>>>>>  
>>>>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>>>>>> *ctx, unsigned int height)
>>>>>>  mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>>>>  }
>>>>>>  
>>>>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
>>>>>> -unsigned int priority, bool enable)
>>>>>> +/**
>>>>>> + * mixer_cfg_layer - apply layer configuration to hardware
>>>>>> + * @ctx: mixer context
>>>>>> + *
>>>>>> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
>>>>>> + * using the 'active_windows' field of the the mixer content, and
>>>>>> + * the pixel format of the framebuffers associated with the enabled
>>>>>> + * windows.
>>>>>> + *
>>>>>> + * Has to be called under mixer lock.
>>>>>> + */
>>>>>> +static void mixer_cfg_layer(struct mixer_context *ctx)
>>>>>>  {
>>>>>>  struct mixer_resources *res = &ctx->mixer_res;
>>>>>> -u32 val = enable ? ~0 : 0;
>>>>>> -
>>

[PATCH 0/6] drm/exynos: g2d: rework sleep and runtime PM

2016-09-28 Thread Inki Dae

We would need to review this patch series for -next in a hurry.
I have to request git-pull soon.

2016ë 09ì 28ì¼ 00:50ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Hello everyone,
> 
> as discussed with Marek I have broken down my initial patch into smaller 
> piecer.
> 
> Anyway, this series fixes a regression introduced by commit
> b05984e21a7e000bf5074ace00d7a574944b2c16.
> 
> With best wishes,
> Tobias
> 
> Tobias Jakobi (6):
>   Revert "drm/exynos: g2d: fix system and runtime pm integration"
>   drm/exynos: g2d: move PM management to runqueue worker
>   drm/exynos: g2d: remove runqueue nodes in g2d_{close,remove}()
>   drm/exynos: g2d: wait for engine to finish
>   drm/exynos: g2d: use autosuspend mode for PM runtime
>   drm/exynos: g2d: simplify g2d_free_runqueue_node()
> 
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 237 
> +---
>  1 file changed, 188 insertions(+), 49 deletions(-)
>

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-28 Thread Inki Dae



2016ë 09ì 27ì¼ 20:22ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Hey Inki,
> 
> 
> Inki Dae wrote:
>> 2016ë 09ì 27ì¼ 14:40ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> Inki Dae wrote:
>>>>
>>>>
>>>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>>>> in mixer_cfg_layer().
>>>>> Trigger this via atomic flush.
>>>>>
>>>>> Changes in v2:
>>>>> - issue mixer_cfg_layer() in mixer_disable()
>>>>> - rename fields as suggested by Andrzej
>>>>> - added docu to mixer context struct
>>>>> - simplify mixer_win_reset() as well
>>>>>
>>>>> Changes in v3:
>>>>> - simplify some conditions as suggested by Inki
>>>>> - add docu to mixer_cfg_layer()
>>>>> - fold switch statements into a single one
>>>>>
>>>>> Signed-off-by: Tobias Jakobi 
>>>>> ---
>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>>>> ++
>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> index 1e78d57..4f06f4d 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>>>   DRM_FORMAT_NV21,
>>>>>  };
>>>>>  
>>>>> +/*
>>>>> + * Mixer context structure.
>>>>> + *
>>>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>>>> + * @planes: Array of plane objects for each of the mixer windows.
>>>>> + * @active_windows: Cache of the mixer's hardware state.
>>>>> + *   Tracks which mixer windows are active/inactive.
>>>>> + * @pipe: The CRTC index.
>>>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>>>> + */
>>>>>  struct mixer_context {
>>>>>   struct platform_device *pdev;
>>>>>   struct device   *dev;
>>>>>   struct drm_device   *drm_dev;
>>>>>   struct exynos_drm_crtc  *crtc;
>>>>>   struct exynos_drm_plane planes[MIXER_WIN_NR];
>>>>> + unsigned long   active_windows;
>>>>>   int pipe;
>>>>>   unsigned long   flags;
>>>>>  
>>>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>>>>> *ctx, unsigned int height)
>>>>>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>>>  }
>>>>>  
>>>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
>>>>> - unsigned int priority, bool enable)
>>>>> +/**
>>>>> + * mixer_cfg_layer - apply layer configuration to hardware
>>>>> + * @ctx: mixer context
>>>>> + *
>>>>> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
>>>>> + * using the 'active_windows' field of the the mixer content, and
>>>>> + * the pixel format of the framebuffers associated with the enabled
>>>>> + * windows.
>>>>> + *
>>>>> + * Has to be called under mixer lock.
>>>>> + */
>>>>> +static void mixer_cfg_layer(struct mixer_context *ctx)
>>>>>  {
>>>>>   struct mixer_resources *res = &ctx->mixer_res;
>>>>> - u32 val = enable ? ~0 : 0;
>>>>> -
>>>>> - switch (win) {
>>>>> - case 0:
>>>>> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
>>>>> - mixer_reg_writemask(res, MXR_LAYER_CFG,
>>>>> - MXR_LAYER_CFG_GRP0_VAL(priority),
>>>>> - MXR_LAYER_CFG_GRP0_MASK);
>>>>> - break;
>>>>> - case 1:
>>>>> -

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-28 Thread Inki Dae



2016ë 09ì 28ì¼ 01:52ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Hello Andrzej,
> 
> 
> Andrzej Hajda wrote:
>> On 27.09.2016 13:22, Tobias Jakobi wrote:
>>> Hello Inki,
>>>
>>>
>>> Inki Dae wrote:
>>>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>>>> in mixer_cfg_layer().
>>>>> Trigger this via atomic flush.
>>>>>
>>>>> Changes in v2:
>>>>> - issue mixer_cfg_layer() in mixer_disable()
>>>>> - rename fields as suggested by Andrzej
>>>>> - added docu to mixer context struct
>>>>> - simplify mixer_win_reset() as well
>>>>>
>>>>> Changes in v3:
>>>>> - simplify some conditions as suggested by Inki
>>>>> - add docu to mixer_cfg_layer()
>>>>> - fold switch statements into a single one
>>>>>
>>>>> Signed-off-by: Tobias Jakobi 
>>>>> ---
>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>>>> ++
>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> index 1e78d57..4f06f4d 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>>>>   DRM_FORMAT_NV21,
>>>>>  };
>>>>>  
>>>>> +/*
>>>>> + * Mixer context structure.
>>>>> + *
>>>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>>>> + * @planes: Array of plane objects for each of the mixer windows.
>>>>> + * @active_windows: Cache of the mixer's hardware state.
>>>>> + *   Tracks which mixer windows are active/inactive.
>>>>> + * @pipe: The CRTC index.
>>>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>>>> + */
>>>>>  struct mixer_context {
>>>>>   struct platform_device *pdev;
>>>>>   struct device   *dev;
>>>>>   struct drm_device   *drm_dev;
>>>>>   struct exynos_drm_crtc  *crtc;
>>>>>   struct exynos_drm_plane planes[MIXER_WIN_NR];
>>>>> + unsigned long   active_windows;
>>>>>   int pipe;
>>>>>   unsigned long   flags;
>>>>>  
>>>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>>>>> *ctx, unsigned int height)
>>>>>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>>>  }
>>>>>  
>>>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
>>>>> - unsigned int priority, bool enable)
>>>>> +/**
>>>>> + * mixer_cfg_layer - apply layer configuration to hardware
>>>>> + * @ctx: mixer context
>>>>> + *
>>>>> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
>>>>> + * using the 'active_windows' field of the the mixer content, and
>>>>> + * the pixel format of the framebuffers associated with the enabled
>>>>> + * windows.
>>>>> + *
>>>>> + * Has to be called under mixer lock.
>>>>> + */
>>>>> +static void mixer_cfg_layer(struct mixer_context *ctx)
>>>>>  {
>>>>>   struct mixer_resources *res = &ctx->mixer_res;
>>>>> - u32 val = enable ? ~0 : 0;
>>>>> -
>>>>> - switch (win) {
>>>>> - case 0:
>>>>> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
>>>>> - mixer_reg_writemask(res, MXR_LAYER_CFG,
>>>>> - MXR_LAYER_CFG_GRP0_VAL(priority),
>>>>> - MXR_LAYER_CFG_GRP0_MASK);
>>>>> - break;
>>>>> - case 1:
>>>>> -

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-27 Thread Inki Dae



2016ë 09ì 27ì¼ 14:40ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Inki Dae wrote:
>>
>>
>> 2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>> in mixer_cfg_layer().
>>> Trigger this via atomic flush.
>>>
>>> Changes in v2:
>>> - issue mixer_cfg_layer() in mixer_disable()
>>> - rename fields as suggested by Andrzej
>>> - added docu to mixer context struct
>>> - simplify mixer_win_reset() as well
>>>
>>> Changes in v3:
>>> - simplify some conditions as suggested by Inki
>>> - add docu to mixer_cfg_layer()
>>> - fold switch statements into a single one
>>>
>>> Signed-off-by: Tobias Jakobi 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
>>> ++
>>>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>>>  2 files changed, 92 insertions(+), 45 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 1e78d57..4f06f4d 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>>> DRM_FORMAT_NV21,
>>>  };
>>>  
>>> +/*
>>> + * Mixer context structure.
>>> + *
>>> + * @crtc: The HDMI CRTC attached to the mixer.
>>> + * @planes: Array of plane objects for each of the mixer windows.
>>> + * @active_windows: Cache of the mixer's hardware state.
>>> + *   Tracks which mixer windows are active/inactive.
>>> + * @pipe: The CRTC index.
>>> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
>>> + * @mixer_resources: A struct containing registers, clocks, etc.
>>> + * @mxr_ver: The hardware revision/version of the mixer.
>>> + */
>>>  struct mixer_context {
>>> struct platform_device *pdev;
>>> struct device   *dev;
>>> struct drm_device   *drm_dev;
>>> struct exynos_drm_crtc  *crtc;
>>> struct exynos_drm_plane planes[MIXER_WIN_NR];
>>> +   unsigned long   active_windows;
>>> int pipe;
>>> unsigned long   flags;
>>>  
>>> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>>> *ctx, unsigned int height)
>>> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>>>  }
>>>  
>>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
>>> -   unsigned int priority, bool enable)
>>> +/**
>>> + * mixer_cfg_layer - apply layer configuration to hardware
>>> + * @ctx: mixer context
>>> + *
>>> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
>>> + * using the 'active_windows' field of the the mixer content, and
>>> + * the pixel format of the framebuffers associated with the enabled
>>> + * windows.
>>> + *
>>> + * Has to be called under mixer lock.
>>> + */
>>> +static void mixer_cfg_layer(struct mixer_context *ctx)
>>>  {
>>> struct mixer_resources *res = &ctx->mixer_res;
>>> -   u32 val = enable ? ~0 : 0;
>>> -
>>> -   switch (win) {
>>> -   case 0:
>>> -   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
>>> -   mixer_reg_writemask(res, MXR_LAYER_CFG,
>>> -   MXR_LAYER_CFG_GRP0_VAL(priority),
>>> -   MXR_LAYER_CFG_GRP0_MASK);
>>> -   break;
>>> -   case 1:
>>> -   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
>>> -   mixer_reg_writemask(res, MXR_LAYER_CFG,
>>> -   MXR_LAYER_CFG_GRP1_VAL(priority),
>>> -   MXR_LAYER_CFG_GRP1_MASK);
>>> +   unsigned int win;
>>>  
>>> -   break;
>>> -   case VP_DEFAULT_WIN:
>>> -   if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
>>> -   vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
>>> -   mixer_reg_writemask(res, MXR_CFG, val,
>>> -   MXR_CFG_VP_ENABLE);
>>> -   mixer_reg_writemask(res, MXR_LAYER_CFG,
>>> -

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-27 Thread Inki Dae



2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
> in mixer_cfg_layer().
> Trigger this via atomic flush.
> 
> Changes in v2:
> - issue mixer_cfg_layer() in mixer_disable()
> - rename fields as suggested by Andrzej
> - added docu to mixer context struct
> - simplify mixer_win_reset() as well
> 
> Changes in v3:
> - simplify some conditions as suggested by Inki
> - add docu to mixer_cfg_layer()
> - fold switch statements into a single one
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
> ++
>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>  2 files changed, 92 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 1e78d57..4f06f4d 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>   DRM_FORMAT_NV21,
>  };
>  
> +/*
> + * Mixer context structure.
> + *
> + * @crtc: The HDMI CRTC attached to the mixer.
> + * @planes: Array of plane objects for each of the mixer windows.
> + * @active_windows: Cache of the mixer's hardware state.
> + *   Tracks which mixer windows are active/inactive.
> + * @pipe: The CRTC index.
> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
> + * @mixer_resources: A struct containing registers, clocks, etc.
> + * @mxr_ver: The hardware revision/version of the mixer.
> + */
>  struct mixer_context {
>   struct platform_device *pdev;
>   struct device   *dev;
>   struct drm_device   *drm_dev;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
> + unsigned long   active_windows;
>   int pipe;
>   unsigned long   flags;
>  
> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
> *ctx, unsigned int height)
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>  }
>  
> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
> - unsigned int priority, bool enable)
> +/**
> + * mixer_cfg_layer - apply layer configuration to hardware
> + * @ctx: mixer context
> + *
> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
> + * using the 'active_windows' field of the the mixer content, and
> + * the pixel format of the framebuffers associated with the enabled
> + * windows.
> + *
> + * Has to be called under mixer lock.
> + */
> +static void mixer_cfg_layer(struct mixer_context *ctx)
>  {
>   struct mixer_resources *res = &ctx->mixer_res;
> - u32 val = enable ? ~0 : 0;
> -
> - switch (win) {
> - case 0:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP0_VAL(priority),
> - MXR_LAYER_CFG_GRP0_MASK);
> - break;
> - case 1:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP1_VAL(priority),
> - MXR_LAYER_CFG_GRP1_MASK);
> + unsigned int win;
>  
> - break;
> - case VP_DEFAULT_WIN:
> - if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
> - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
> - mixer_reg_writemask(res, MXR_CFG, val,
> - MXR_CFG_VP_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_VP_VAL(priority),
> - MXR_LAYER_CFG_VP_MASK);
> + struct exynos_drm_plane_state *state;
> + struct drm_framebuffer *fb;
> + unsigned int priority;
> + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
> + bool enable;
> +
> + for (win = 0; win < MIXER_WIN_NR; ++win) {
> + state = to_exynos_plane_state(ctx->planes[win].base.state);
> + fb = state->fb;
> +
> + priority = state->base.normalized_zpos + 1;
> + enable = test_bit(win, &ctx->active_windows);
> +
> + if (!enable)
> + continue;
> +
> + BUG_ON(!fb);
> +
> + /*
> +  * TODO: Don't enable alpha blending for the bottom window.
> +  */
> + switch (win) {
> + case 0:
> + mxr_cfg |=  MXR_CFG_GRP0_ENABLE;
> + mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority);
> + mixer_cfg_gfx_blend(ctx, win, 
> is_alpha_format(fb->pixel_format));
> + break;
> +
> + case

[PATCH v3] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-27 Thread Inki Dae



2016ë 09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
> in mixer_cfg_layer().
> Trigger this via atomic flush.
> 
> Changes in v2:
> - issue mixer_cfg_layer() in mixer_disable()
> - rename fields as suggested by Andrzej
> - added docu to mixer context struct
> - simplify mixer_win_reset() as well
> 
> Changes in v3:
> - simplify some conditions as suggested by Inki
> - add docu to mixer_cfg_layer()
> - fold switch statements into a single one
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 135 
> ++
>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>  2 files changed, 92 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 1e78d57..4f06f4d 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>   DRM_FORMAT_NV21,
>  };
>  
> +/*
> + * Mixer context structure.
> + *
> + * @crtc: The HDMI CRTC attached to the mixer.
> + * @planes: Array of plane objects for each of the mixer windows.
> + * @active_windows: Cache of the mixer's hardware state.
> + *   Tracks which mixer windows are active/inactive.
> + * @pipe: The CRTC index.
> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
> + * @mixer_resources: A struct containing registers, clocks, etc.
> + * @mxr_ver: The hardware revision/version of the mixer.
> + */
>  struct mixer_context {
>   struct platform_device *pdev;
>   struct device   *dev;
>   struct drm_device   *drm_dev;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
> + unsigned long   active_windows;
>   int pipe;
>   unsigned long   flags;
>  
> @@ -418,37 +431,70 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
> *ctx, unsigned int height)
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>  }
>  
> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
> - unsigned int priority, bool enable)
> +/**
> + * mixer_cfg_layer - apply layer configuration to hardware
> + * @ctx: mixer context
> + *
> + * This configures the MXR_CFG and MXR_LAYER_CFG hardware registers
> + * using the 'active_windows' field of the the mixer content, and
> + * the pixel format of the framebuffers associated with the enabled
> + * windows.
> + *
> + * Has to be called under mixer lock.
> + */
> +static void mixer_cfg_layer(struct mixer_context *ctx)
>  {
>   struct mixer_resources *res = &ctx->mixer_res;
> - u32 val = enable ? ~0 : 0;
> -
> - switch (win) {
> - case 0:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP0_VAL(priority),
> - MXR_LAYER_CFG_GRP0_MASK);
> - break;
> - case 1:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP1_VAL(priority),
> - MXR_LAYER_CFG_GRP1_MASK);
> + unsigned int win;
>  
> - break;
> - case VP_DEFAULT_WIN:
> - if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
> - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
> - mixer_reg_writemask(res, MXR_CFG, val,
> - MXR_CFG_VP_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_VP_VAL(priority),
> - MXR_LAYER_CFG_VP_MASK);
> + struct exynos_drm_plane_state *state;
> + struct drm_framebuffer *fb;
> + unsigned int priority;
> + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
> + bool enable;
> +
> + for (win = 0; win < MIXER_WIN_NR; ++win) {
> + state = to_exynos_plane_state(ctx->planes[win].base.state);
> + fb = state->fb;
> +
> + priority = state->base.normalized_zpos + 1;
> + enable = test_bit(win, &ctx->active_windows);
> +
> + if (!enable)
> + continue;
> +
> + BUG_ON(!fb);

Not good. Even through some problem happens at mixer driver, other KMS drivers 
should work.

[PATCH v2 4/4] drm/exynos: g2d: beautify probing message

2016-09-26 Thread Inki Dae



2016ë 09ì 22ì¼ 23:57ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Apply some 'make-up' in g2d_probe().

Just clean up. Picked it up.

> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 73cd83f..410d170 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -2423,7 +2423,7 @@ static int g2d_probe(struct platform_device *pdev)
>   goto err_put_clk;
>   }
>  
> - dev_info(dev, "The exynos g2d(ver %d.%d) successfully probed\n",
> + dev_info(dev, "The Exynos G2D (ver %d.%d) successfully probed.\n",
>   G2D_HW_MAJOR_VER, G2D_HW_MINOR_VER);
>  
>   return 0;
>

[PATCH v2 2/4] drm/exynos: mixer: configure layers once in mixer_atomic_flush()

2016-09-26 Thread Inki Dae



2016ë 09ì 22ì¼ 23:57ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
> in mixer_cfg_layer().
> Trigger this via atomic flush.
> 
> Changes in v2:
> - issue mixer_cfg_layer() in mixer_disable()
> - rename fields as suggested by Andrzej
> - added docu to mixer context struct
> - simplify mixer_win_reset() as well
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 133 
> ++
>  drivers/gpu/drm/exynos/regs-mixer.h   |   2 +
>  2 files changed, 90 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 1e78d57..c3dad66 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -93,12 +93,25 @@ static const uint32_t vp_formats[] = {
>   DRM_FORMAT_NV21,
>  };
>  
> +/*
> + * Mixer context structure.
> + *
> + * @crtc: The HDMI CRTC attached to the mixer.
> + * @planes: Array of plane objects for each of the mixer windows.
> + * @active_windows: Cache of the mixer's hardware state.
> + *   Tracks which mixer windows are active/inactive.
> + * @pipe: The CRTC index.
> + * @flags: Bitfield build from the mixer_flag_bits enumerator.
> + * @mixer_resources: A struct containing registers, clocks, etc.
> + * @mxr_ver: The hardware revision/version of the mixer.
> + */

Above changes are not related to this patch but trivial thing so no problem.

>  struct mixer_context {
>   struct platform_device *pdev;
>   struct device   *dev;
>   struct drm_device   *drm_dev;
>   struct exynos_drm_crtc  *crtc;
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
> + unsigned long   active_windows;
>   int pipe;
>   unsigned long   flags;
>  
> @@ -418,37 +431,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
> *ctx, unsigned int height)
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
>  }
>  
> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
> - unsigned int priority, bool enable)
> +static void mixer_cfg_layer(struct mixer_context *ctx)
>  {
>   struct mixer_resources *res = &ctx->mixer_res;
> - u32 val = enable ? ~0 : 0;
> -
> - switch (win) {
> - case 0:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP0_VAL(priority),
> - MXR_LAYER_CFG_GRP0_MASK);
> - break;
> - case 1:
> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_GRP1_VAL(priority),
> - MXR_LAYER_CFG_GRP1_MASK);
> + unsigned int win;
>  
> - break;
> - case VP_DEFAULT_WIN:
> - if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
> - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
> - mixer_reg_writemask(res, MXR_CFG, val,
> - MXR_CFG_VP_ENABLE);
> - mixer_reg_writemask(res, MXR_LAYER_CFG,
> - MXR_LAYER_CFG_VP_VAL(priority),
> - MXR_LAYER_CFG_VP_MASK);
> + struct exynos_drm_plane_state *state;
> + struct drm_framebuffer *fb;
> + unsigned int priority;
> + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0;
> + bool enable;
> +
> + for (win = 0; win < MIXER_WIN_NR; ++win) {
> + state = to_exynos_plane_state(ctx->planes[win].base.state);
> + fb = state->fb;
> +
> + priority = state->base.normalized_zpos + 1;
> + enable = test_bit(win, &ctx->active_windows);
> +
> + if (!enable)
> + continue;

if (!enable || !fb)
continue;

> +
> + switch (win) {
> + case 0:
> + mxr_cfg |=  MXR_CFG_GRP0_ENABLE;
> + mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority);
> + break;
> +
> + case 1:
> + mxr_cfg |=  MXR_CFG_GRP1_ENABLE;
> + mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority);
> + break;
> +
> + case VP_DEFAULT_WIN:
> + vp_enable = VP_ENABLE_ON;
> + mxr_cfg |=  MXR_CFG_VP_ENABLE;
> + mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority);
> + break;
> + }
> +
> + if (!fb)
> + continue;

And remove above two lines.

> +
> + /*
> +  * TODO: Don't enable alpha blending for the bottom window.
> +  */
> +

[PATCH v2 1/4] drm/exynos: mixer: convert booleans to flags in mixer context

2016-09-26 Thread Inki Dae

Picked this one up.

Thanks,
Inki Dae

2016ë 09ì 22ì¼ 23:57ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> The mixer context struct already has a 'flags' field, so
> we can use it to store the 'interlace', 'vp_enabled' and
> 'has_sclk' booleans.
> We use the non-atomic helper functions to access these bits.
> 
> Reviewed-by: Andrzej Hajda 
> Signed-off-by: Tobias Jakobi 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 54 
> +++
>  1 file changed, 29 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 9a48aa1..1e78d57 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -73,6 +73,9 @@ enum mixer_version_id {
>  enum mixer_flag_bits {
>   MXR_BIT_POWERED,
>   MXR_BIT_VSYNC,
> + MXR_BIT_INTERLACE,
> + MXR_BIT_VP_ENABLED,
> + MXR_BIT_HAS_SCLK,
>  };
>  
>  static const uint32_t mixer_formats[] = {
> @@ -98,9 +101,6 @@ struct mixer_context {
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
>   int pipe;
>   unsigned long   flags;
> - boolinterlace;
> - boolvp_enabled;
> - boolhas_sclk;
>  
>   struct mixer_resources  mixer_res;
>   enum mixer_version_id   mxr_ver;
> @@ -346,7 +346,7 @@ static void mixer_vsync_set_update(struct mixer_context 
> *ctx, bool enable)
>   mixer_reg_writemask(res, MXR_STATUS, enable ?
>   MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
>  
> - if (ctx->vp_enabled)
> + if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags))
>   vp_reg_write(res, VP_SHADOW_UPDATE, enable ?
>   VP_SHADOW_UPDATE_ENABLE : 0);
>  }
> @@ -357,8 +357,8 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
> unsigned int height)
>   u32 val;
>  
>   /* choosing between interlace and progressive mode */
> - val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
> - MXR_CFG_SCAN_PROGRESSIVE);
> + val = test_bit(MXR_BIT_INTERLACE, &ctx->flags) ?
> + MXR_CFG_SCAN_INTERLACE : MXR_CFG_SCAN_PROGRESSIVE;
>  
>   if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
>   /* choosing between proper HD and SD mode */
> @@ -436,9 +436,10 @@ static void mixer_cfg_layer(struct mixer_context *ctx, 
> unsigned int win,
>   mixer_reg_writemask(res, MXR_LAYER_CFG,
>   MXR_LAYER_CFG_GRP1_VAL(priority),
>   MXR_LAYER_CFG_GRP1_MASK);
> +
>   break;
>   case VP_DEFAULT_WIN:
> - if (ctx->vp_enabled) {
> + if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) {
>   vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
>   mixer_reg_writemask(res, MXR_CFG, val,
>   MXR_CFG_VP_ENABLE);
> @@ -501,7 +502,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
>  
>   if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
> - ctx->interlace = true;
> + __set_bit(MXR_BIT_INTERLACE, &ctx->flags);
>   if (tiled_mode) {
>   luma_addr[1] = luma_addr[0] + 0x40;
>   chroma_addr[1] = chroma_addr[0] + 0x40;
> @@ -510,7 +511,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
>   }
>   } else {
> - ctx->interlace = false;
> + __clear_bit(MXR_BIT_INTERLACE, &ctx->flags);
>   luma_addr[1] = 0;
>   chroma_addr[1] = 0;
>   }
> @@ -518,7 +519,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   spin_lock_irqsave(&res->reg_slock, flags);
>  
>   /* interlace or progressive scan mode */
> - val = (ctx->interlace ? ~0 : 0);
> + val = (test_bit(MXR_BIT_INTERLACE, &ctx->flags) ? ~0 : 0);
>   vp_reg_writemask(res, VP_MODE, val, VP_MODE_LINE_SKIP);
>  
>   /* setup format */
> @@ -541,7 +542,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>  
>   vp_reg_write(res, VP_DST_WIDTH, state->crtc.w);
>   vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x);
> - if (ctx->interlace) {
> + if (test_bit(MXR_BIT_INTERLACE, &ctx->flags)) {
>   vp_reg_write(res, VP_DST_HEIGHT, state->crt

[GIT PULL] exynos-drm-fixes

2016-09-19 Thread Inki Dae

Hi Dave,

There was my mistake reported below when I merged one fixup manually.
http://www.spinics.net/lists/dri-devel/msg118283.html

Fixed.

Thanks,
Inki Dae


2016ë 09ì 18ì¼ 23:12ì Inki Dae ì´(ê°) ì´ ê¸:
> Hi Dave,
> 
>Just fixup to runtime pm usage and some cleanups.
> 
>Please kindly let me know if there is any problem.
> 
>Ps. We will request git-pull for -next soon if no critical issue,
>which includes only code refactoring on hdmi ddc and phy.
> 
> Thanks,
> Inki Dae
> 
> The following changes since commit 09cb5b78af52208afb9f1b194c8a9154df4a4782:
> 
>   Merge tag 'drm-vc4-fixes-2016-09-14' of https://github.com/anholt/linux 
> into drm-fixes (2016-09-17 07:57:55 +1000)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
> exynos-drm-fixes
> 
> for you to fetch changes up to f14b71e73240a6264f5ea71879219f97fd227e34:
> 
>   Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning 
> (2016-09-18 22:52:29 +0900)
> 
> 
> Arnd Bergmann (1):
>   Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning
> 
> Marek Szyprowski (4):
>   drm/exynos: fimc: fix system and runtime pm integration
>   drm/exynos: gsc: fix system and runtime pm integration
>   drm/exynos: rotator: fix system and runtime pm integration
>   drm/exynos: g2d: fix system and runtime pm integration
> 
> Shuah Khan (1):
>   exynos-drm: Fix unsupported GEM memory type error message to be clear
> 
>  drivers/gpu/drm/exynos/exynos_drm_fb.c  |6 ++---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|   29 ++-
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c |   29 ++-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |   34 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |   26 ++--
>  5 files changed, 18 insertions(+), 106 deletions(-)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[GIT PULL] exynos-drm-fixes

2016-09-18 Thread Inki Dae

Hi Dave,

   Just fixup to runtime pm usage and some cleanups.

   Please kindly let me know if there is any problem.

   Ps. We will request git-pull for -next soon if no critical issue,
   which includes only code refactoring on hdmi ddc and phy.

Thanks,
Inki Dae

The following changes since commit 09cb5b78af52208afb9f1b194c8a9154df4a4782:

  Merge tag 'drm-vc4-fixes-2016-09-14' of https://github.com/anholt/linux into 
drm-fixes (2016-09-17 07:57:55 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to f14b71e73240a6264f5ea71879219f97fd227e34:

  Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning 
(2016-09-18 22:52:29 +0900)


Arnd Bergmann (1):
  Subject: [PATCH, RESEND] drm: exynos: avoid unused function warning

Marek Szyprowski (4):
  drm/exynos: fimc: fix system and runtime pm integration
  drm/exynos: gsc: fix system and runtime pm integration
  drm/exynos: rotator: fix system and runtime pm integration
  drm/exynos: g2d: fix system and runtime pm integration

Shuah Khan (1):
  exynos-drm: Fix unsupported GEM memory type error message to be clear

 drivers/gpu/drm/exynos/exynos_drm_fb.c  |6 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|   29 ++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   29 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |   34 ---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |   26 ++--
 5 files changed, 18 insertions(+), 106 deletions(-)

[PATCH v4 0/3] gpu: drm: exynos_hdmi: Code refactoring on hdmi ddc and phy

2016-09-18 Thread Inki Dae

Hi,

Thanks for your contribution.

Seems good to me. Will picked them up soon if no critical issues.

Thanks,
Inki Dae


2016-08-31 15:14 GMT+09:00 Milo Kim :

> v4:
>   Only DRM patchset is sent, DTS patch was sent separately.
>
> Milo Kim (3):
>   gpu: drm: exynos_hdmi: Move DDC logic into single function
>   gpu: drm: exynos_hdmi: Move PHY logic into single function
>   gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator
> bulk consumer
>
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 112 ++
> -
>  1 file changed, 59 insertions(+), 53 deletions(-)
>
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160918/c3287d43/attachment.html>

[RFC 0/2] New feature: Framebuffer processors

2016-08-30 Thread Inki Dae



2016ë 08ì 25ì¼ 21:14ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Thu, Aug 25, 2016 at 08:45:25PM +0900, Inki Dae wrote:
>>
>>
>> 2016ë 08ì 25ì¼ 17:42ì Daniel Vetter ì´(ê°) ì´ ê¸:
>>> On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
>>>>
>>>>
>>>> 2016ë 08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
>>>>> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
>>>>>> Hi,
>>>>>>
>>>>>> 2016ë 08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 22 August 2016 at 16:23, Rob Clark  wrote:
>>>>>>>> I guess a lot comes down to 'how long before hw designers bolt a CP to
>>>>>>>> the thing'..  at that point, I think you especially don't want a
>>>>>>>> per-blit kernel interface.
>>>>>>>
>>>>>>> Regardless of whether or not we want it, we already _have_ it, in the
>>>>>>> form of V4L2 M2M. There are already a few IP blocks working on that, I
>>>>>>> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
>>>>>>> anyway ...
>>>>>>
>>>>>> So we are trying this. We had expereneced using V4L2 and DRM together on
>>>>>> Linux Platform makes it too complicated, and also integrated DRM with
>>>>>> M2M such as 2D and Post processor makes it simplified.  So We have been
>>>>>> trying to move existing V4L2 based drivers into DRM excepting HW Video
>>>>>> Codec - called it MFC - and Camera sensor and relevant things.
>>>>>> I think now V4L2 and DRM frameworks may make many engineers confusing
>>>>>> because there are the same devices which can be controlled by V4L2 and
>>>>>> DRM frameworks - maybe we would need more efforts like Laurent did with
>>>>>> Live source[1] in the future.
>>>>>
>>>>> Can you pls explain in more detail where working with both v4l and drm
>>>>> drivers and making them cooperate using dma-bufs poses problems? We should
>>>>> definitely fix that.
>>>>
>>>> I think it would be most Linux Platforms - Android, Chrome and Tizen -
>>>> which would use OpenMAX/GStreammer for Multimedia and X or
>>>> Wayland/SurfaceFlinger for Display.
>>>
>>> Yes, that's the use case. Where is the problem in making this happen? v4l
>>> can import dma-bufs, drm can export them, and there's plenty devices
>>> shipping (afaik) that make use of exact this pipeline. Can you pls explain
>>> what problem you've hit trying to make this work on exynos?
>>
>> No problem but just make it complicated as I mentioned above - the
>> stream operations - S_FMT, REQBUF, QUARYBUF, QBUF, STREAM ON and DQBUF
>> of V4L2 would never be simple as DRM.  Do you think M2M device should be
>> controlled by V4L2 interfaces? and even 2D accelerator? As long as I
>> know, The Graphics card on Desktop has all devices such as 2D/3D GPU, HW
>> Video codec and Display controller, and these devices are controlled by
>> DRM interfaces. So we - ARM Exynos - are trying to move these things to
>> DRM world and also trying to implement more convenient interfaces like
>> Marek did.
> 
> This is a misconception, there's nothing in the drm world requiring that
> everything is under the same drm device. All the work we've done over the
> past years (dma-buf, reservations, fence, prime, changes in X.org and
> wayland) are _all_ to make it possible to have a gfx device consisting of
> multiple drm/v4l/whatever else nodes. Especially for a SoC moving back to
> fake-integrating stuff really isn't a good idea I think.

Yes, not all devices. As I mentioned already - excepting HW Video codec and 
Camera device, we have changed a post processor driver to DRM instead of V4L2 
and now we are trying to standard the post processsor interfaces.
I know that the Display controllers of several SoC include Post processing 
function which makes image to be scaled up, down or rotated and pixel format of 
the image to be converted to other pixel format, and these device are 
controlled by DRM.

Do you think these post processor devices should be controlled by V4L2?

Thanks,
Inki Dae

> 
> And wrt drm being simpler than v4l - I don't think drm is any simpler, at
> elast if you look at some of the more feature-full render drivers.
> -Daniel
>

[RFC 0/2] New feature: Framebuffer processors

2016-08-25 Thread Inki Dae



2016ë 08ì 25ì¼ 17:42ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
>>
>>
>> 2016ë 08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
>>> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
>>>> Hi,
>>>>
>>>> 2016ë 08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
>>>>> Hi,
>>>>>
>>>>> On 22 August 2016 at 16:23, Rob Clark  wrote:
>>>>>> I guess a lot comes down to 'how long before hw designers bolt a CP to
>>>>>> the thing'..  at that point, I think you especially don't want a
>>>>>> per-blit kernel interface.
>>>>>
>>>>> Regardless of whether or not we want it, we already _have_ it, in the
>>>>> form of V4L2 M2M. There are already a few IP blocks working on that, I
>>>>> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
>>>>> anyway ...
>>>>
>>>> So we are trying this. We had expereneced using V4L2 and DRM together on
>>>> Linux Platform makes it too complicated, and also integrated DRM with
>>>> M2M such as 2D and Post processor makes it simplified.  So We have been
>>>> trying to move existing V4L2 based drivers into DRM excepting HW Video
>>>> Codec - called it MFC - and Camera sensor and relevant things.
>>>> I think now V4L2 and DRM frameworks may make many engineers confusing
>>>> because there are the same devices which can be controlled by V4L2 and
>>>> DRM frameworks - maybe we would need more efforts like Laurent did with
>>>> Live source[1] in the future.
>>>
>>> Can you pls explain in more detail where working with both v4l and drm
>>> drivers and making them cooperate using dma-bufs poses problems? We should
>>> definitely fix that.
>>
>> I think it would be most Linux Platforms - Android, Chrome and Tizen -
>> which would use OpenMAX/GStreammer for Multimedia and X or
>> Wayland/SurfaceFlinger for Display.
> 
> Yes, that's the use case. Where is the problem in making this happen? v4l
> can import dma-bufs, drm can export them, and there's plenty devices
> shipping (afaik) that make use of exact this pipeline. Can you pls explain
> what problem you've hit trying to make this work on exynos?

No problem but just make it complicated as I mentioned above - the stream 
operations - S_FMT, REQBUF, QUARYBUF, QBUF, STREAM ON and DQBUF of V4L2 would 
never be simple as DRM.
Do you think M2M device should be controlled by V4L2 interfaces? and even 2D 
accelerator? As long as I know, The Graphics card on Desktop has all devices 
such as 2D/3D GPU, HW Video codec and Display controller, and these devices are 
controlled by DRM interfaces. So we - ARM Exynos - are trying to move these 
things to DRM world and also trying to implement more convenient interfaces 
like Marek did.

Thanks,
Inki Dae

> -Daniel
>

[RFC 0/2] New feature: Framebuffer processors

2016-08-25 Thread Inki Dae



2016ë 08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
>> Hi,
>>
>> 2016ë 08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> Hi,
>>>
>>> On 22 August 2016 at 16:23, Rob Clark  wrote:
>>>> I guess a lot comes down to 'how long before hw designers bolt a CP to
>>>> the thing'..  at that point, I think you especially don't want a
>>>> per-blit kernel interface.
>>>
>>> Regardless of whether or not we want it, we already _have_ it, in the
>>> form of V4L2 M2M. There are already a few IP blocks working on that, I
>>> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
>>> anyway ...
>>
>> So we are trying this. We had expereneced using V4L2 and DRM together on
>> Linux Platform makes it too complicated, and also integrated DRM with
>> M2M such as 2D and Post processor makes it simplified.  So We have been
>> trying to move existing V4L2 based drivers into DRM excepting HW Video
>> Codec - called it MFC - and Camera sensor and relevant things.
>> I think now V4L2 and DRM frameworks may make many engineers confusing
>> because there are the same devices which can be controlled by V4L2 and
>> DRM frameworks - maybe we would need more efforts like Laurent did with
>> Live source[1] in the future.
> 
> Can you pls explain in more detail where working with both v4l and drm
> drivers and making them cooperate using dma-bufs poses problems? We should
> definitely fix that.

I think it would be most Linux Platforms - Android, Chrome and Tizen - which 
would use OpenMAX/GStreammer for Multimedia and X or Wayland/SurfaceFlinger for 
Display.

Thanks,
Inki Dae

> -Daniel
>

[RFC 0/2] New feature: Framebuffer processors

2016-08-24 Thread Inki Dae

Hi,

2016ë 08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi,
> 
> On 22 August 2016 at 16:23, Rob Clark  wrote:
>> I guess a lot comes down to 'how long before hw designers bolt a CP to
>> the thing'..  at that point, I think you especially don't want a
>> per-blit kernel interface.
> 
> Regardless of whether or not we want it, we already _have_ it, in the
> form of V4L2 M2M. There are already a few IP blocks working on that, I
> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
> anyway ...

So we are trying this. We had expereneced using V4L2 and DRM together on Linux 
Platform makes it too complicated, and also integrated DRM with M2M such as 2D 
and Post processor makes it simplified.
So We have been trying to move existing V4L2 based drivers into DRM excepting 
HW Video Codec - called it MFC - and Camera sensor and relevant things.
I think now V4L2 and DRM frameworks may make many engineers confusing because 
there are the same devices which can be controlled by V4L2 and DRM frameworks - 
maybe we would need more efforts like Laurent did with Live source[1] in the 
future.

Anyway, sad to say, it seems other maintainers leave NAK for this patch series 
because this trying had failed already long time ago - they had learned such 
thing didn't work well. So seems we have to keep this in only Exynos DRM.

[1] https://lwn.net/Articles/640290/

Thanks,
Inki Dae

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

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

2016-08-16 Thread Inki Dae

Hi Shuah,

2016ë 08ì 13ì¼ 02:52ì Shuah Khan ì´(ê°) ì´ ê¸:
> On 08/12/2016 11:28 AM, Shuah Khan wrote:
>> On 08/10/2016 05:05 PM, Shuah Khan wrote:
>>> On 08/10/2016 04:59 PM, Inki Dae wrote:
>>>> Hi Shuah,
>>>>
>>>> 2016ë 08ì 11ì¼ 02:30ì Shuah Khan ì´(ê°) ì´ ê¸:
>>>>> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
>>>>> memory without IOMMU. In this case, there is no point in attempting to
>>>>
>>>> DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
>>>> device and other DMA devices.
>>>> Even though IOMMU support is disabled, other framework based DMA drivers 
>>>> can use IOMMU - i.e., GPU driver -
>>>> and they can use non-contiguous GEM buffer through UMM. (DMABUF) 
>>>>
>>>> So GEM allocation type is not dependent on IOMMU.
>>>
>>> Hi Inki,
>>>
>>> I am seeing the following failure without IOMMU and light dm fails
>>> to start:
>>>
>>> [drm:exynos_drm_framebuffer_init] *ERROR* Non-continguous GEM memory is not 
>>> supported.
>>>
>>> The change I made fixed that problem and light dm starts without IOMMU.
>>> Is there a better way to fix this problem? Currently without IOMMU,
>>> light dm doesn't start.
>>>
>>> This is on linux_next
>>
>> Hi Inki,
>>
>> I am looking into this further and I am finding inconsistent
>> commits with regards to GEM contiguous and non-contiguous
>> buffers.
>>
>> Okay what you said is that:
>>
>> exymod-drm should support non-continguous and contiguous GEM memory
>> type with or without IOMMU

Right.

>>
>> However, the code currently isn't doing that. The following
>> commit allocates non-contiguous buffers when IOMMU is enabled
>> to handle contiguous allocation failures.
>>
>> There are other commits that removed checks for non-contig type.
>> Let's look at the following cases to see what should be the driver
>> behavior in these cases:
>>
>> IOMMU is disabled:
>>
>> exynos_drm_gem_create_ioctl() gets called with NONCONTIG
>> - driver should try to allocate non-contig
>> - if it can't allocate non-contig, allocate contig
>>   ( this will allow avoid failure like the one I am seeing)
>>
>> exynos_drm_gem_create_ioctl() gets called with CONTIG
>> - driver should try to allocate contig
>> - if it can't allocate contig, allocate non-contig
>>
>> What is confusing is there are several code paths in the
>> GEN allocation and checking memory types are enforcing
>> non-contig with IOMMU. Check this routine:
>>
>> exynos_drm_framebuffer_init() will reject non-contig
>> memory type when check_fb_gem_memory_type() rejects
>> non-contig GEM memory type without IOMMU.

Only in case that the gem buffer is used for framebuffer, gem memory type 
should be checked because this means the DMA of Display controller accesses the 
gem buffer so without IOMMU the DMA device cannot access non-contiguous memory 
region.
That is why exynos_drm_framebuffer_init checks gem memory type for fb not when 
gem is created.

> 
> 
> okay the very first commit that added IOMMU support
> introduced the code that rejects non-contig gem memory
> type without IOMMU.
> 
> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
> Author: Inki Dae 
> Date:   Sat Oct 20 07:53:42 2012 -0700
> 
> drm/exynos: add iommu support for exynos drm framework
> 
> Anyway, if it is th right change to fix check_fb_gem_memory_type()
> to not reject NONCONTIG_BUFFER, then I can make that change

No, as I mentioned above, the gem buffer for fb is dependent on IOMMU because 
the gem buffer for fb is used by DMA device - FIMD, DECON or Mixer.
You would need to understand that gem buffer can be used for other purposes - 
2D/3D or post process devices which don't use framebuffer - not display 
controller which uses framebuffer to scanout

Thanks,
Inki Dae

> instead of this patch I sent.
> 
>>
>> So there is inconsistency in the non-contig vs. contig
>> GEM support in exynos-drm. I think this needs to be cleaned
>> up to get the desired behavior.
>>
>> The following commit allocates non-contiguous buffers when IOMMU is
>> enabled to handle contiguous allocation failures.
>>
>> There are other commits that removed checks for non-contig type.
>> Let's look at the following cases to see what should be the driver
>> behavior in these cases:
>>
>> commit 122beea84bb90236b1ae545f08267af58

[PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

2016-08-11 Thread Inki Dae

Hi Shuah,

2016ë 08ì 11ì¼ 02:30ì Shuah Khan ì´(ê°) ì´ ê¸:
> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
> memory without IOMMU. In this case, there is no point in attempting to

DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
device and other DMA devices.
Even though IOMMU support is disabled, other framework based DMA drivers can 
use IOMMU - i.e., GPU driver -
and they can use non-contiguous GEM buffer through UMM. (DMABUF) 

So GEM allocation type is not dependent on IOMMU.

Thanks,
Inki Dae

> allocate non-contiguous memory, only to return error during the next step
> from exynos_drm_framebuffer_init() which leads to display manager failing
> to start.
> 
> Check if non-contiguous GEM memory is requested without IOMMU. If so,
> allocate contiguous GEM memory to help display manager start.
> 
> Signed-off-by: Shuah Khan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c4cb0e..4719116 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -266,6 +266,20 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev, 
> void *data,
>   struct exynos_drm_gem *exynos_gem;
>   int ret;
>  
> + /*
> +  * Check if non-contiguous GEM memory is requested without IOMMU.
> +  * If so, allocate contiguous GEM memory.
> +  *
> +  * There is no point in attempting to allocate non-contiguous memory,
> +  * only to return error from exynos_drm_framebuffer_init() which leads
> +  * to display manager failing to start.
> + */
> + if (!is_drm_iommu_supported(dev) &&
> + (args->flags & EXYNOS_BO_NONCONTIG)) {
> + args->flags &= ~EXYNOS_BO_NONCONTIG;
> + args->flags |= EXYNOS_BO_CONTIG;
> + }
> +
>   exynos_gem = exynos_drm_gem_create(dev, args->flags, args->size);
>   if (IS_ERR(exynos_gem))
>   return PTR_ERR(exynos_gem);
>

[PATCH v2] exynos-drm: Fix unsupported GEM memory type error message to be clear

2016-08-09 Thread Inki Dae

Picked it up. :)

Thanks,
Inki Dae


2016-08-09 8:48 GMT+09:00 Shuah Khan :

> Fix unsupported GEM memory type error message to include the memory type
> information.
>
> Signed-off-by: Shuah Khan 
> ---
> Changes since v1:
> -- Comment changed to read clearly
>
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index e016640..40ce841 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -55,11 +55,11 @@ static int check_fb_gem_memory_type(struct drm_device
> *drm_dev,
> flags = exynos_gem->flags;
>
> /*
> -* without iommu support, not support physically non-continuous
> memory
> -* for framebuffer.
> +* Physically non-contiguous memory type for framebuffer is not
> +* supported without IOMMU.
>  */
> if (IS_NONCONTIG_BUFFER(flags)) {
> -   DRM_ERROR("cannot use this gem memory type for fb.\n");
> +   DRM_ERROR("Non-contiguous GEM memory is not supported.\n");
> return -EINVAL;
> }
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160809/740246d5/attachment.html>

[RFC] dma-buf: Import/export the implicit fences on the dma-buf

2016-07-15 Thread Inki Dae

2016-07-12 6:59 GMT+09:00 Chris Wilson :
> When dealing with user interfaces that utilize explicit fences, it is
> convenient to sometimes create those fences after the fact, i.e. to
> query the dma-buf for the current set of implicit fences, encapsulate
> those into a sync_file and hand that fd back to userspace.
> Correspondingly, being able to add an explicit fence back into the mix
> of fences being tracked by the dma-buf allows that userspace fence to be
> included in any implicit tracking.

Regarding import fence, explicit fence can be corresponded to one of
sub-allocated blocks of a DMA buffer. What if user-space requested
import fence with a fence corresponding to a sub-allocated block?
As you know, implicit fence is always corresponded to one DMA buffer
not sub block of it. I guess there may be other things you should
consider for import fence interface.

>
> Signed-off-by: Chris Wilson 
> Cc: Gustavo Padovan 
> Cc: Rob Clark 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> Cc: dri-devel at lists.freedesktop.org
> ---
>
> Gustavo, could you look at the sync-file/fence-array handling? There's
> definitely room for a cleaner sync_file_create() API.
>
> I was thinking about this for the "why not sync-file" question Gustavo
> posed for the vgem_fences. I wanted to add an ioctl to the vgem to allow
> exporting and creating fences from sync-file for testing passing
> explicit userspaces around between drivers, and realised that I was just
> writing a generic mechanism that only required dma-buf.
>
> Whilst this interface could be used for lazily creating explicit fences,
> drivers will also likely want to support specific ioctl to skip the
> dmabuf creation, I think this interfaces will be useful with the vgem
> fences for testing sync_file handling in drivers (on i915 at the moment,
> my tests for sync_file involve sleeping and a few white lies). So
> fulfilling a similar role in driver testing to debugfs/sw_sync?
> (sw_sync is still more apt for testing timelines etc, vgem feels more
> apt for ease of testing rendering.)
> -Chris
>
> ---
>  drivers/dma-buf/dma-buf.c| 100 
> +++
>  include/uapi/linux/dma-buf.h |   9 
>  2 files changed, 109 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 41fbce0c273a..6f066a8affd7 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -26,11 +26,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -254,6 +256,97 @@ out:
> return events;
>  }
>
> +static long dma_buf_import_fence_ioctl(struct dma_buf *dmabuf,
> +  struct dma_buf_fence  __user *arg)
> +{
> +   struct reservation_object *resv = dmabuf->resv;
> +   struct dma_buf_fence cmd;
> +   struct fence *fence;
> +   int ret;
> +
> +   if (copy_from_user(&cmd, arg, sizeof(cmd)))
> +   return -EFAULT;
> +
> +   fence = NULL;
> +   //fence = sync_file_get_fence(cmd.fd);

Your mistake?

Thanks,
Inki Dae

> +   if (!fence)
> +   return -EINVAL;
> +

[RFC] dma-buf: Rename struct fence to dma_fence

2016-07-13 Thread Inki Dae

Hi,

2016-07-13 23:10 GMT+09:00 Chris Wilson :
> I plan to usurp the short name of struct fence for a core kernel struct,
> and so I need to rename the specialised fence/timeline for DMA
> operations to make room.
>
> As an indication of the scale of the flag day:
>
>  91 files changed, 904 insertions(+), 880 deletions(-)

Seems files changed and below patch codes are not inconsistent. i.e.,
I cannot see modified codes for Android sync driver.
And Android sync driver - explicit fence - can use a fence object
regardless of DMA buffer. So it looks reasonable to use 'fence' as-is.
Was there any changes for Android sync driver to be dependent on DMA buffer?

Thanks,
Inki Dae

>
> with the greatest victim being amdgpu.
>
> Just the highlights shown below.
> -Chris
>
> ---
>  drivers/base/Kconfig|   6 +-
>  drivers/dma-buf/Makefile|   2 +-
>  drivers/dma-buf/dma-buf.c   |  28 +-
>  drivers/dma-buf/dma-fence.c | 535 
> 
>  drivers/dma-buf/fence.c | 532 ---
>  drivers/dma-buf/reservation.c   |  90 ++--
>  drivers/dma-buf/seqno-fence.c   |  18 +-
>  drivers/dma-buf/sw_sync.c   |  44 +-
>  drivers/dma-buf/sync_debug.c|   9 +-
>  drivers/dma-buf/sync_debug.h|  13 +-
>  drivers/dma-buf/sync_file.c |  30 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  56 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c |  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  16 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c   |  50 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  |  10 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c  |  24 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c|  56 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c|  12 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h   |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |  18 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c |  22 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h |   4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  56 +--
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |   8 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  16 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |   8 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c   |   6 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c   |   6 +-
>  drivers/gpu/drm/amd/scheduler/gpu_sched_trace.h |   4 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c   |  42 +-
>  drivers/gpu/drm/amd/scheduler/gpu_scheduler.h   |  24 +-
>  drivers/gpu/drm/amd/scheduler/sched_fence.c |  22 +-
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c   |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c   |  46 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h   |   4 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c|  12 +-
>  drivers/gpu/drm/msm/msm_drv.h   |   2 +-
>  drivers/gpu/drm/msm/msm_fence.c |  30 +-
>  drivers/gpu/drm/msm/msm_fence.h |   2 +-
>  drivers/gpu/drm/msm/msm_gem.c   |  14 +-
>  drivers/gpu/drm/msm/msm_gem.h   |   2 +-
>  drivers/gpu/drm/msm/msm_gem_submit.c|   2 +-
>  drivers/gpu/drm/msm/msm_gpu.c   |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c|   6 +-
>  drivers/gpu/drm/nouveau/nouveau_fence.c |  68 +--
>  drivers/gpu/drm/nouveau/nouveau_fence.h |   6 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c   |   2 +-
>  drivers/gpu/drm/nouveau/nv04_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv10_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv17_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv50_fence.c|   2 +-
>  drivers/gpu/drm/nouveau/nv84_fence.c|   2 +-
>  drivers/g

[GIT PULL] exynos-drm-next

2016-07-13 Thread Inki Dae

Hi Dave,
   This pull request adds to the rework patch series for IOMMU
   integration to support ARM64bit architecture with DMA-IOMMU
   glue code.

   With this patch series, Exynos DRM works well on Exynos5433 SoC
   with IOMMU enabled.

   Ps. current implementation has conditional codes in exynos_drm_iommu.h
   for ARM32/64 supports because these two architectures are not compatible
   yet so the conditional codes will be removed later with architectures
   unified.

   Please kindly let me know if there is any problem.


Thanks,
Inki Dae


The following changes since commit 5dd0775e502b26b44e5bcb5f504a977a565f2f3e:

  Merge tag 'asoc-hdmi-codec-pdata' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into drm-next 
(2016-07-05 09:57:23 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to 197adf0b7e419247a6e54d05d0d334e07e9e4c33:

  drm/exynos: iommu: add support for ARM64 specific code for IOMMU glue 
(2016-07-13 23:06:07 +0900)


Marek Szyprowski (5):
  drm/exynos: iommu: move dma_params configuration code to separate 
functions
  drm/exynos: iommu: add a check if all sub-devices have iommu controller
  drm/exynos: iommu: remove unused entries from exynos_drm_private strcuture
  drm/exynos: iommu: move ARM specific code to exynos_drm_iommu.h
  drm/exynos: iommu: add support for ARM64 specific code for IOMMU glue

 drivers/gpu/drm/exynos/Kconfig|2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |7 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |2 -
 drivers/gpu/drm/exynos/exynos_drm_iommu.c |   77 +++-
 drivers/gpu/drm/exynos/exynos_drm_iommu.h |   91 +
 5 files changed, 126 insertions(+), 53 deletions(-)

[PATCH v2 1/5] drm/exynos: iommu: move dma_params configuration code to separate functions

2016-07-08 Thread Inki Dae

Hi Marek,

2016ë 06ì 17ì¼ 16:54ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Move code for managing DMA max segment size parameter to separate
> functions. This patch also replaces devm_kzalloc() with kzalloc() and
> adds proper kfree call. devm_kzalloc() cannot be used for dma_params
> structure, because it will be freed on driver remove not on device
> release. This means in case of Exynos DRM being compiled as module and
> loaded 2 times, a user-after-free issue will happen.

Picked this patch series up.

Thanks,
Inki Dae

> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_iommu.c | 28 ++--
>  1 file changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c 
> b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> index 7ca09ee19656..1e82529e0c41 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
> @@ -21,6 +21,23 @@
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_iommu.h"
>  
> +static inline int configure_dma_max_seg_size(struct device *dev)
> +{
> + if (!dev->dma_parms)
> + dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
> + if (!dev->dma_parms)
> + return -ENOMEM;
> +
> + dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
> + return 0;
> +}
> +
> +static inline void clear_dma_max_seg_size(struct device *dev)
> +{
> + kfree(dev->dma_parms);
> + dev->dma_parms = NULL;
> +}
> +
>  /*
>   * drm_create_iommu_mapping - create a mapping structure
>   *
> @@ -80,13 +97,10 @@ int drm_iommu_attach_device(struct drm_device *drm_dev,
>   if (!priv->mapping)
>   return 0;
>  
> - subdrv_dev->dma_parms = devm_kzalloc(subdrv_dev,
> - sizeof(*subdrv_dev->dma_parms),
> - GFP_KERNEL);
> - if (!subdrv_dev->dma_parms)
> - return -ENOMEM;
>  
> - dma_set_max_seg_size(subdrv_dev, 0xu);
> + ret = configure_dma_max_seg_size(subdrv_dev);
> + if (ret)
> + return ret;
>  
>   if (subdrv_dev->archdata.mapping)
>   arm_iommu_detach_device(subdrv_dev);
> @@ -94,6 +108,7 @@ int drm_iommu_attach_device(struct drm_device *drm_dev,
>   ret = arm_iommu_attach_device(subdrv_dev, priv->mapping);
>   if (ret < 0) {
>   DRM_DEBUG_KMS("failed iommu attach.\n");
> + clear_dma_max_seg_size(subdrv_dev);
>   return ret;
>   }
>  
> @@ -119,4 +134,5 @@ void drm_iommu_detach_device(struct drm_device *drm_dev,
>   return;
>  
>   arm_iommu_detach_device(subdrv_dev);
> + clear_dma_max_seg_size(subdrv_dev);
>  }
>

[GIT PULL] exynos-drm-fixes

2016-06-19 Thread Inki Dae

Hi Dave,

   Just regression fixups and cleanups.

   Since HW trigger mode was suppoted we have faced with a issue
   that Display panel didn't work correctly when trigger mode was changed
   in booting time.
   For this, we keep trigger mode with SW trigger mode in default mode
   like we did before.

   However, we will need to consider PSR(Panel Self Reflash) mode to resolve
   this issue fundamentally later.

   Please kindly let me know if there is any problem.


Thanks,
Inki Dae

The following changes since commit 0ab15bdeb2943bd6491a35ec4eeb53a9a4436525:

  Merge branch 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-06-16 10:24:13 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to 41abbf5afa51136bcb2aeefc80bf5c3a005d0aa3:

  drm/exynos: use logical AND in exynos_drm_plane_check_size() (2016-06-19 
14:37:28 +0900)


Javier Martinez Canillas (2):
  drm/exynos: fimd: don't set .has_hw_trigger in s3c6400 driver data
  drm/exynos: don't use HW trigger for Exynos5420/5422/5800

Tobias Jakobi (3):
  drm/exynos: g2d: drop the _REG postfix from the stride defines
  drm/exynos: remove superfluous inclusions of fbdev header
  drm/exynos: use logical AND in exynos_drm_plane_check_size()

Yakir Yang (1):
  drm/exynos: dp: Fix NULL pointer dereference due uninitialized connector

 drivers/gpu/drm/exynos/exynos7_drm_decon.c |1 -
 drivers/gpu/drm/exynos/exynos_dp.c |5 +++--
 drivers/gpu/drm/exynos/exynos_drm_core.c   |1 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |5 -
 drivers/gpu/drm/exynos/exynos_drm_g2d.c|   12 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |2 +-
 6 files changed, 10 insertions(+), 16 deletions(-)

[PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

2016-06-13 Thread Inki Dae



2016ë 06ì 10ì¼ 09:24ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
> 
> On Thu, Jun 9, 2016 at 6:35 PM, Inki Dae  wrote:
> 
> [snip]
> 
>>> I know that removing .trg_type is enough but I also removed those lines
>>> because the fields are not used if .trg_type != I80_HW_TRG. So there is
>>> no point to leave a set for unused fields.
>>>
>>> We can latter add those one HW trigger support is fixed for Exynos5420.
>>>
>>
>> As of now, I can merge it but I think it would be not reasonable solution 
>> because potential problem still exists even we use SW trigger mode in 
>> default - ie., in case of using HW trigger mode at bootloader, same problem 
>> would happen as long as we don't support PSR mode support.
>>
> 
> Yes, I understand that the problem will show again if the bootloader
> uses HW trigger mode and that we need proper Panel Self Refresh
> support but I think that's a separate issue. That's why I said that
> those can be addressed for v4.8 but revert to SW trigger for v4.7 as a
> short term fix for the regression.
> 
> In other words, enabling HW trigger mode breaks the display for the
> Exynos5420 and Exynos5800 Peach Pi Chromebooks with the shipped
> bootloaders (which are probably the most popular Exynos5 devices with
> display and mainline support so is likely to affect users).

I thought to add PSR support somehow but put me other things to trouble.
Anyway, we could support it later so picked it up.

Thanks,
Inki Dae

> 
> Best regards,
> Javier
> 
> 
>

[PATCH] drm/exynos: g2d: drop the _REG postfix from the stride defines

2016-06-13 Thread Inki Dae

Picked it up.

Thanks,
Inki Dae

2016ë 06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Ping!
> 
> - Tobias
> 
> Tobias Jakobi wrote:
>> This makes the defines consistent with the rest.
>>
>> Signed-off-by: Tobias Jakobi 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> index 01b72b9..0934d38 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>> @@ -48,13 +48,13 @@
>>  
>>  /* registers for base address */
>>  #define G2D_SRC_BASE_ADDR   0x0304
>> -#define G2D_SRC_STRIDE_REG  0x0308
>> +#define G2D_SRC_STRIDE  0x0308
>>  #define G2D_SRC_COLOR_MODE  0x030C
>>  #define G2D_SRC_LEFT_TOP0x0310
>>  #define G2D_SRC_RIGHT_BOTTOM0x0314
>>  #define G2D_SRC_PLANE2_BASE_ADDR0x0318
>>  #define G2D_DST_BASE_ADDR   0x0404
>> -#define G2D_DST_STRIDE_REG  0x0408
>> +#define G2D_DST_STRIDE  0x0408
>>  #define G2D_DST_COLOR_MODE  0x040C
>>  #define G2D_DST_LEFT_TOP0x0410
>>  #define G2D_DST_RIGHT_BOTTOM0x0414
>> @@ -560,7 +560,7 @@ static enum g2d_reg_type g2d_get_reg_type(int reg_offset)
>>  
>>  switch (reg_offset) {
>>  case G2D_SRC_BASE_ADDR:
>> -case G2D_SRC_STRIDE_REG:
>> +case G2D_SRC_STRIDE:
>>  case G2D_SRC_COLOR_MODE:
>>  case G2D_SRC_LEFT_TOP:
>>  case G2D_SRC_RIGHT_BOTTOM:
>> @@ -570,7 +570,7 @@ static enum g2d_reg_type g2d_get_reg_type(int reg_offset)
>>  reg_type = REG_TYPE_SRC_PLANE2;
>>  break;
>>  case G2D_DST_BASE_ADDR:
>> -case G2D_DST_STRIDE_REG:
>> +case G2D_DST_STRIDE:
>>  case G2D_DST_COLOR_MODE:
>>  case G2D_DST_LEFT_TOP:
>>  case G2D_DST_RIGHT_BOTTOM:
>> @@ -961,8 +961,8 @@ static int g2d_check_reg_offset(struct device *dev,
>>  } else
>>  buf_info->types[reg_type] = BUF_TYPE_GEM;
>>  break;
>> -case G2D_SRC_STRIDE_REG:
>> -case G2D_DST_STRIDE_REG:
>> +case G2D_SRC_STRIDE:
>> +case G2D_DST_STRIDE:
>>  if (for_addr)
>>  goto err;
>>  
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
>

[PATCH] drm/exynos: remove superfluous inclusions of fbdev header

2016-06-13 Thread Inki Dae

Picked it up.

Thanks,
Inki Dae

2016ë 06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>  3 files changed, 3 deletions(-)

[PATCH] drm/exynos: use logical AND in exynos_drm_plane_check_size()

2016-06-13 Thread Inki Dae

Picked it up.

Thanks,
Inki Dae

2016ë 06ì 10ì¼ 19:12ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Ping!
> 
> - Tobias
> 
> Tobias Jakobi wrote:
>> The current bitwise AND should result in the same assembler
>> but this is what the code is actually supposed to do.
>>
>> Signed-off-by: Tobias Jakobi 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> index b3f3c2c..e4a1a63 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> @@ -226,7 +226,7 @@ exynos_drm_plane_check_size(const struct 
>> exynos_drm_plane_config *config,
>>  state->v_ratio == (1 << 15))
>>  height_ok = true;
>>  
>> -if (width_ok & height_ok)
>> +if (width_ok && height_ok)
>>  return 0;
>>  
>>  DRM_DEBUG_KMS("scaling mode is not supported");
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
>

[PATCH 07/26] drm/exynos: Use for_each_crtc_in_state

2016-06-13 Thread Inki Dae



2016ë 05ì 30ì¼ 03:35ì Daniel Vetter ì´(ê°) ì´ ê¸:
> We want to hide drm_atomic_state internals better.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> 
> Cc: Inki Dae 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 2dd820e23b0c..cabc5fd0246d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -267,6 +267,8 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
> drm_atomic_state *state,
>  {
>   struct exynos_drm_private *priv = dev->dev_private;
>   struct exynos_atomic_commit *commit;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
>   int i, ret;
>  
>   commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> @@ -288,10 +290,8 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
> drm_atomic_state *state,
>   /* Wait until all affected CRTCs have completed previous commits and
>* mark them as pending.
>*/
> - for (i = 0; i < dev->mode_config.num_crtc; ++i) {
> - if (state->crtcs[i])
> - commit->crtcs |= 1 << drm_crtc_index(state->crtcs[i]);
> - }
> + for_each_crtc_in_state(state, crtc, crtc_state, i)
> + commit->crtcs |= 1 << drm_crtc_index(crtc);
>  
>   wait_event(priv->wait, !commit_is_pending(priv, commit->crtcs));
>  
>

[PATCH v2 4/9] drm/fb-helper: Push down modeset lock into FB helpers

2016-06-10 Thread Inki Dae

Hi Thierry,

2016ë 06ì 08ì¼ 00:26ì Thierry Reding ì´(ê°) ì´ ê¸:
> From: Thierry Reding 
> 
> Move the modeset locking from drivers into FB helpers.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_fb_helper.c| 59 
> +-
>  drivers/gpu/drm/i915/intel_dp_mst.c|  4 ---
>  drivers/gpu/drm/radeon/radeon_dp_mst.c |  7 
>  3 files changed, 44 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 9afd4208596f..252c7557bdb5 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -95,8 +95,8 @@ static LIST_HEAD(kernel_fb_helper_list);
>   * mmap page writes.
>   */
>  
> -int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> - struct drm_connector *connector)
> +static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> +  struct drm_connector *connector)
>  {
>   struct drm_fb_helper_connector **temp;
>   struct drm_fb_helper_connector *conn;
> @@ -129,6 +129,20 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
> *fb_helper,
>   fb_helper->connector_info[fb_helper->connector_count++] = conn;
>   return 0;
>  }
> +
> +int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> + struct drm_connector *connector)
> +{
> + int err;
> +
> + mutex_lock(&fb_helper->dev->mode_config.mutex);
> +
> + err = __drm_fb_helper_add_one_connector(fb_helper, connector);

I think you don't need to make __drm_fb_helper_add_on_connector function but 
just you can implement the codes here instead. And the use of prefix '__' thing 
would not good.
And my concern about this is that other drivers may need to call this function 
after taking a same mutex lock. Can you assure anyone not to call this function 
with mutex lock?

If there is such case then,

some_function()
{
mutex_lock();
...
mutex_unlock();
drm_fb_helper_add_one_connector();
...
}

So in this case, other users should consider to make sure to unlock before 
calling this function. That would be now really what you want.

Thanks,
Inki Dae

> +
> + mutex_unlock(&fb_helper->dev->mode_config.mutex);
> +
> + return err;
> +}
>  EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
>  
>  /**
> @@ -155,28 +169,28 @@ int drm_fb_helper_single_add_all_connectors(struct 
> drm_fb_helper *fb_helper)
>   return 0;
>  
>   mutex_lock(&dev->mode_config.mutex);
> +
>   drm_for_each_connector(connector, dev) {
> - ret = drm_fb_helper_add_one_connector(fb_helper, connector);
> + ret = __drm_fb_helper_add_one_connector(fb_helper, connector);
> + if (ret) {
> + for (i = 0; i < fb_helper->connector_count; i++) {
> + kfree(fb_helper->connector_info[i]);
> + fb_helper->connector_info[i] = NULL;
> + }

I think all resources should be released by someone who allocated the resources 
in case of failure. I mean that if some routine of 
__drm_fb_helper_add_on_connector function failed than the function make sure to 
release the resources allocated. I know this is really not what you did but 
original code did. So how about cleanning up this thing? 

Thanks,
Inki Dae

>  
> - if (ret)
> - goto fail;
> - }
> - mutex_unlock(&dev->mode_config.mutex);
> - return 0;
> -fail:
> - for (i = 0; i < fb_helper->connector_count; i++) {
> - kfree(fb_helper->connector_info[i]);
> - fb_helper->connector_info[i] = NULL;
> + fb_helper->connector_count = 0;
> + break;
> + }
>   }
> - fb_helper->connector_count = 0;
> +
>   mutex_unlock(&dev->mode_config.mutex);
>  
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
>  
> -int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> -struct drm_connector *connector)
> +static int __drm_fb_helper_remove_one_connector(struct drm_fb_helper 
> *fb_helper,
> + struct drm_connector *connector)
>  {
>   struct drm_fb_helper_connector *fb_helper_connector;
>   int i, j;
> @@ -193,6 +207,7 @@ int drm_fb_helper_remove_one_connector(struct 
> drm_fb_helper *fb_helper,
>  
>

[PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

2016-06-10 Thread Inki Dae

Hi Javier,

2016ë 06ì 09ì¼ 09:17ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
> 
> Thanks for your feedback.
> 
> On 06/08/2016 07:09 PM, Inki Dae wrote:
>> Hi Javier,
>>
>> 2016ë 06ì 02ì¼ 23:20ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
>>> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
>>> hardware trigger support to the FIMD controller driver. But this broke
>>> the display in at least the Exynos5800 Peach Pi Chromebook.
>>>
>>> So until the issue is fixed, avoid using HW trigger for the Exynos5420
>>> based boards and use SW trigger as it was before the mentioned commit.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>>
>>> ---
>>>
>>> Hello Inki,
>>>
>>> Since commit a6f75aa161c5 landed in v4.7-rc1, I think $SUBJECT should be
>>> picked to make sure that v4.7 is released with the display working for
>>> the Exynos5420 based Chromebooks.
>>>
>>> We can then figure out what's wrong with the HW trigger support and fix
>>> it for v4.8.
>>
>> Agree. And below is a trivial comment.
>>
> 
> I'm glad that you agree.
> 
>>>
>>> Best regards,
>>> Javier
>>>
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
>>>  1 file changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 1c23a8ff5e83..f10030ff00e6 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -170,14 +170,11 @@ static struct fimd_driver_data 
>>> exynos5420_fimd_driver_data = {
>>> .lcdblk_vt_shift = 24,
>>> .lcdblk_bypass_shift = 15,
>>> .lcdblk_mic_bypass_shift = 11,
>>> -   .trg_type = I80_HW_TRG,
>>> .has_shadowcon = 1,
>>> .has_vidoutcon = 1,
>>> .has_vtsel = 1,
>>> .has_mic_bypass = 1,
>>> .has_dp_clk = 1,
>>> -   .has_hw_trigger = 1,
>>> -   .has_trigger_per_te = 1,
>>
>> We don't need to remove above two lines. It would be enough to remove 
>> 'trg_type = I80_HW_TRG', which makes FIMD to be worked with SW trigger in 
>> default.
>>
> 
> I know that removing .trg_type is enough but I also removed those lines
> because the fields are not used if .trg_type != I80_HW_TRG. So there is
> no point to leave a set for unused fields.
> 
> We can latter add those one HW trigger support is fixed for Exynos5420.
> 

As of now, I can merge it but I think it would be not reasonable solution 
because potential problem still exists even we use SW trigger mode in default - 
ie., in case of using HW trigger mode at bootloader, same problem would happen 
as long as we don't support PSR mode support.

Thanks,
Inki Dae

>> Thanks,
>> Inki Dae
>>
>>>  };
>>>  
>>>  struct fimd_context {
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> Best regards,
>

[PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

2016-06-09 Thread Inki Dae

Hi Javier,

2016ë 06ì 02ì¼ 23:20ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
> hardware trigger support to the FIMD controller driver. But this broke
> the display in at least the Exynos5800 Peach Pi Chromebook.
> 
> So until the issue is fixed, avoid using HW trigger for the Exynos5420
> based boards and use SW trigger as it was before the mentioned commit.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Hello Inki,
> 
> Since commit a6f75aa161c5 landed in v4.7-rc1, I think $SUBJECT should be
> picked to make sure that v4.7 is released with the display working for
> the Exynos5420 based Chromebooks.
> 
> We can then figure out what's wrong with the HW trigger support and fix
> it for v4.8.

Agree. And below is a trivial comment.

> 
> Best regards,
> Javier
> 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 1c23a8ff5e83..f10030ff00e6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -170,14 +170,11 @@ static struct fimd_driver_data 
> exynos5420_fimd_driver_data = {
>   .lcdblk_vt_shift = 24,
>   .lcdblk_bypass_shift = 15,
>   .lcdblk_mic_bypass_shift = 11,
> - .trg_type = I80_HW_TRG,
>   .has_shadowcon = 1,
>   .has_vidoutcon = 1,
>   .has_vtsel = 1,
>   .has_mic_bypass = 1,
>   .has_dp_clk = 1,
> - .has_hw_trigger = 1,
> - .has_trigger_per_te = 1,

We don't need to remove above two lines. It would be enough to remove 'trg_type 
= I80_HW_TRG', which makes FIMD to be worked with SW trigger in default.

Thanks,
Inki Dae

>  };
>  
>  struct fimd_context {
>

[PATCH 2/3] drm/exynos: fimd: add HW trigger support

2016-06-01 Thread Inki Dae

Hi Javier,

2016ë 05ì 31ì¼ 07:58ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
> 
> On 04/05/2016 04:27 AM, Inki Dae wrote:
>> This patch adds HW trigger support on i80 mode.
>>
>> Until now, Exynos DRM only supported SW trigger which was set
>> SWTRGCMD bit of TRIGCON register by CPU to transfer scanout
>> buffer to Display bus device or panel.
>>
>> With this patch, the transmission to Display bus device or
>> panel will be initiated by FIMD controller.
>>
>> Signed-off-by: Inki Dae 
>> ---
> 
> There is a regression for the Exynos5800 Peach Pi Chromebook display due
> this patch. The display is blank and I noticed that it only happens when
> HW start trigger is enabled, but works with SW trigger (as it was before).

Posted below pathch,
[PATCH] drm/exynos: fimd: fix trigger mode change regression

Can you test it again with the patch? I have no HW to test it. :(

Thanks,
Inki Dae

> 
> So for example with the following diff on top of v4.7-rc1, display works
> again. Do you have any hints about what could be the issue?
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 0444d7fc400d..8c62830e9514 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -171,7 +171,7 @@ static struct fimd_driver_data 
> exynos5420_fimd_driver_data = {
>   .lcdblk_vt_shift = 24,
>   .lcdblk_bypass_shift = 15,
>   .lcdblk_mic_bypass_shift = 11,
> - .trg_type = I80_HW_TRG,
>   .has_shadowcon = 1,
>   .has_vidoutcon = 1,
>   .has_vtsel = 1,
> 
> Best regards,
>

[PATCH] drm/exynos: fimd: fix trigger mode change regression

2016-06-01 Thread Inki Dae

This patch fixes a regression that Display panel doesn't work
since HW trigger mode was supported.

The trigger mode should be changed on PSR(Panel Self Refresh)
mode of Panel device according to HW guy's saying. However,
with previous HW trigger support, trigger mode could been changed
in normal mode of Panel device.

So this patch makes sure to change the trigger mode after power off
and on again. Later we need to add PSR relevant codes instead.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 35 
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 3efe1aa..355149f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -203,6 +203,11 @@ struct fimd_context {
atomic_twait_vsync_event;
atomic_twin_updated;
atomic_ttriggering;
+   /*
+* fimd_setup_trigger function will try to change trigger mode
+* only in case that this flag is set.
+*/
+   atomic_tdeferred_tr_mode;

const struct fimd_driver_data *driver_data;
struct drm_encoder *encoder;
@@ -430,11 +435,37 @@ static void fimd_setup_trigger(struct fimd_context *ctx)
val &= ~(TRGMODE_ENABLE);

if (trg_type == I80_HW_TRG) {
+   /*
+* change trigger mode after power off and on again.
+* deferred_tr_mode will be set when fimd_disable is called.
+*
+* TODO. Trigger mode should be changed on PSR mode of Panel
+* device. So we have to add relevant codes to make sure
+* entering into PSR mode later.
+*/
+   if (val & TRGMODE_ENABLE &&
+   !atomic_read(&ctx->deferred_tr_mode))
+   return;
+
if (ctx->driver_data->has_hw_trigger)
val |= HWTRGEN_ENABLE | HWTRGMASK_ENABLE;
if (ctx->driver_data->has_trigger_per_te)
val |= HWTRIGEN_PER_ENABLE;
} else {
+   /*
+* change trigger mode after power off and on again.
+* deferred_tr_mode will be set when fimd_disable is called.
+*
+* TODO. Trigger mode should be changed on PSR mode of Panel
+* device. So we have to add relevant codes to make sure
+* entering into PSR mode later.
+*/
+   if (ctx->driver_data->has_hw_trigger) {
+   if (val & HWTRGEN_ENABLE &&
+   !atomic_read(&ctx->deferred_tr_mode))
+   return;
+   }
+
val |= TRGMODE_ENABLE;
}

@@ -864,6 +895,10 @@ static void fimd_disable(struct exynos_drm_crtc *crtc)
writel(0, ctx->regs + VIDCON0);

pm_runtime_put_sync(ctx->dev);
+
+   if (ctx->i80_if)
+   atomic_set(&ctx->deferred_tr_mode, 1);
+
ctx->suspended = true;
 }

-- 
1.9.1

[PATCH 2/3] drm/exynos: fimd: add HW trigger support

2016-06-01 Thread Inki Dae

Hi Javier,

2016ë 05ì 31ì¼ 07:58ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
> 
> On 04/05/2016 04:27 AM, Inki Dae wrote:
>> This patch adds HW trigger support on i80 mode.
>>
>> Until now, Exynos DRM only supported SW trigger which was set
>> SWTRGCMD bit of TRIGCON register by CPU to transfer scanout
>> buffer to Display bus device or panel.
>>
>> With this patch, the transmission to Display bus device or
>> panel will be initiated by FIMD controller.
>>
>> Signed-off-by: Inki Dae 
>> ---
> 
> There is a regression for the Exynos5800 Peach Pi Chromebook display due
> this patch. The display is blank and I noticed that it only happens when
> HW start trigger is enabled, but works with SW trigger (as it was before).
> 
> So for example with the following diff on top of v4.7-rc1, display works
> again. Do you have any hints about what could be the issue?

Right, there is a regression on boards with i80 Panel and in case that 
bootloader set trigger mode to SW trigger. The current trigger mode should be 
changed to other one after entering into PSR mode of Panel device according to 
HW guy's saying. If the panel doesn't support the PSR mode, then the mode 
should be changed after Panel power off and on again. I don't understand 
exactly what is the PSR mode so I need more details about PSR mode.

I will fix it soon.

Thanks,
Inki Dae  


> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 0444d7fc400d..8c62830e9514 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -171,7 +171,7 @@ static struct fimd_driver_data 
> exynos5420_fimd_driver_data = {
>   .lcdblk_vt_shift = 24,
>   .lcdblk_bypass_shift = 15,
>   .lcdblk_mic_bypass_shift = 11,
> - .trg_type = I80_HW_TRG,
>   .has_shadowcon = 1,
>   .has_vidoutcon = 1,
>   .has_vtsel = 1,
> 
> Best regards,
>

[PATCH 07/26] drm/exynos: Use for_each_crtc_in_state

2016-05-31 Thread Inki Dae

2016-05-30 3:35 GMT+09:00 Daniel Vetter :
> We want to hide drm_atomic_state internals better.
>

Acked-by: Inki Dae 

> Cc: Inki Dae 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 2dd820e23b0c..cabc5fd0246d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -267,6 +267,8 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
> drm_atomic_state *state,
>  {
> struct exynos_drm_private *priv = dev->dev_private;
> struct exynos_atomic_commit *commit;
> +   struct drm_crtc *crtc;
> +   struct drm_crtc_state *crtc_state;
> int i, ret;
>
> commit = kzalloc(sizeof(*commit), GFP_KERNEL);
> @@ -288,10 +290,8 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
> drm_atomic_state *state,
> /* Wait until all affected CRTCs have completed previous commits and
>  * mark them as pending.
>  */
> -   for (i = 0; i < dev->mode_config.num_crtc; ++i) {
> -   if (state->crtcs[i])
> -   commit->crtcs |= 1 << drm_crtc_index(state->crtcs[i]);
> -   }
> +   for_each_crtc_in_state(state, crtc, crtc_state, i)
> +   commit->crtcs |= 1 << drm_crtc_index(crtc);
>
> wait_event(priv->wait, !commit_is_pending(priv, commit->crtcs));
>
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL 2nd] exynos-drm-next

2016-05-10 Thread Inki Dae

Hi Dave,

   This 2nd pull request includes one patch I missed, some cleanups
   and fixups.

   Summary:
   - expose HDMI-PHY clock to other drivers.
 . this patch was included in below patch series but I missed.
 http://www.spinics.net/lists/dri-devel/msg103097.html
   - some fixups about DECON5433 driver
 . this patch corrects vblank handling and fixes up trigger
   configuration.
   - use generic functions - gem_prime_mmap and dma_buf_mmap.
   - use DMA-Mapping API instead of specific one.
   - some code cleanups and fixeups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit 2e726dc4b4e2dd3ae3fe675f9d3af88a2d593ee1:

  Merge tag 'mediatek-drm-2016-05-09' of git://git.pengutronix.de/git/pza/linux 
into drm-next (2016-05-10 15:01:47 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to dd65a6867454117ecaeb8944dc231a4737681782:

  drm/exynos/decon5433: fix trigger configuration (2016-05-10 23:11:46 +0900)


Andrzej Hajda (5):
  drm/exynos/hdmi: expose HDMI-PHY clock as pipeline clock
  drm/exynos/decon5433: handle vblank in vblank interrupt
  drm/exynos/decon5433: do not use unnecessary software trigger
  drm/exynos: fix cancel page flip code
  drm/exynos/decon5433: fix trigger configuration

Daniel Vetter (1):
  drm/exynos: Nuke dummy fb->dirty callback

Javier Martinez Canillas (1):
  drm/exynos/hdmi: Don't print error on deferral due to regulators

Joonyoung Shim (3):
  drm/exynos: support gem_prime_mmap
  drm/exynos: fix imported dma-buf to be mapped
  drm/exynos: use directly DMA mapping APIs on g2d

Philipp Zabel (2):
  drm/exynos/dpi: use of_graph_get_endpoint_by_regs helper
  drm/exynos/dsi: use of_graph_get_endpoint_by_regs helper

Tobias Jakobi (1):
  drm/exynos: fimd: harden fimd_calc_clkdiv()

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |   16 +++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   15 ++---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c   |   69 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c   |   57 +--
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   11 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |9 ++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |   10 ++--
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   70 
 drivers/gpu/drm/exynos/exynos_drm_gem.h   |   12 +---
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   73 ++---
 11 files changed, 120 insertions(+), 223 deletions(-)

[PATCH 3/3] drm/exynos/decon5433: fix trigger configuration

2016-05-10 Thread Inki Dae


2016ë 05ì 10ì¼ 16:08ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 05/10/2016 08:24 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 2016ë 05ì 10ì¼ 15:08ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> Hi Inki,
>>>
>>>
>>> On 05/10/2016 07:31 AM, Inki Dae wrote:
>>>> Hi Andrzej,
>>>>
>>>> 2016ë 04ì 29ì¼ 22:42ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>>>> It seems trigger cannot be configured too early, otherwise it does not 
>>>>> work in
>>>>> case of panel. The patch fixes also trigger flag logic, previously 
>>>>> HW-TRIGGER
>>>>> flag was cleared in case of panel - as a result panel used always software
>>>> Andrzej, sorry but I can't understand what above two lines mean. Can you 
>>>> give me more details?
>>> Details below.
>>>
>>>>> trigger.
>>>>>
>>>>> Signed-off-by: Andrzej Hajda 
>>>>> ---
>>>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 --
>>>>>  1 file changed, 4 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>>>> index 7b4f699..9ae913b 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>>>> @@ -151,11 +151,13 @@ static void decon_commit(struct exynos_drm_crtc 
>>>>> *crtc)
>>>>>   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>>>>>   writel(val, ctx->addr + DECON_CMU);
>>>>>  
>>>>> + if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
>>>>> + decon_setup_trigger(ctx);
>>>> Shouldn't it be configured in case of using SW trigger mode also?
>>>>
>>>> Thanks,
>>>> Inki Dae
>>>>
>>>>> +
>>>>>   /* lcd on and use command if */
>>>>>   val = VIDOUT_LCD_ON;
>>>>>   if (ctx->out_type & IFTYPE_I80) {
>>>>>   val |= VIDOUT_COMMAND_IF;
>>>>> - decon_setup_trigger(ctx);
>>>>>   } else {
>>>>>   val |= VIDOUT_RGB_IF;
>>>>>   }
>>>>> @@ -380,9 +382,6 @@ static void decon_swreset(struct decon_context *ctx)
>>>>>   writel(VIDCON1_VCLK_RUN_VDEN_DISABLE, ctx->addr + DECON_VIDCON1);
>>>>>   writel(CRCCTRL_CRCEN | CRCCTRL_CRCSTART_F | CRCCTRL_CRCCLKEN,
>>>>>  ctx->addr + DECON_CRCCTRL);
>>>>> -
>>>>> - if (ctx->out_type & IFTYPE_I80)
>>>>> - decon_setup_trigger(ctx);
>>>>>  }
>>>>>  
>>>>>  static void decon_enable(struct exynos_drm_crtc *crtc)
>>>>> @@ -652,9 +651,8 @@ static int exynos5433_decon_probe(struct 
>>>>> platform_device *pdev)
>>>>>  
>>>>>   if (ctx->out_type & IFTYPE_HDMI) {
>>>>>       ctx->first_win = 1;
>>>>> -     ctx->out_type = IFTYPE_I80;
>>>>>   } else if (of_get_child_by_name(dev->of_node, "i80-if-timings")) {
>>>>> - ctx->out_type = IFTYPE_I80;
>>>>> + ctx->out_type |= IFTYPE_I80;
>>> ctx->out_type was overwritten here with IFTYPE_I80. So when
>>> decon_setup_trigger
>>> were called I80_HW_TRG bit was always clear and DECON_TRIGCON was configured
>>> to use soft trigger.
>> Indeed. Then shouldn't decon_setup_trigger function be called in both cases 
>> - SW and HW trigger modes?
>> Is there any reason to call the function only in case of HW trigger mode?
> 
> With this patch function is called under following condition:
>> +if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
>> +decon_setup_trigger(ctx);
> 
> So it is called always in case of I80 mode, in such case value of I80_HW_TRG
> determines if it should use sw or hw trigger.

Ah, sorry. I misleaded above condition.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
> 
>>
>> Thanks,
>> Inki Dae
>>
>>> Regards
>>> Andrzej
>>>
>>>>>   }
>>>>>  
>>>>>   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
>>>>>
>>>
> 
>

[PATCH] exynos: change the license to X11/MIT

2016-05-10 Thread Inki Dae

This patch changes GPL license to X11/MIT.

Signed-off-by: Inki Dae 
---
 exynos/exynos_fimg2d.c | 21 +
 exynos/exynos_fimg2d.h | 21 +
 exynos/fimg2d_reg.h| 21 +
 tests/exynos/exynos_fimg2d_event.c | 27 +--
 tests/exynos/exynos_fimg2d_perf.c  | 27 +--
 tests/exynos/exynos_fimg2d_test.c  | 21 +
 6 files changed, 102 insertions(+), 36 deletions(-)

diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 7f1d105..7127ef0 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -3,11 +3,24 @@
  * Authors:
  * Inki Dae 
  *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
  *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */

 #ifdef HAVE_CONFIG_H
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index a825c68..a4dfbe7 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -3,11 +3,24 @@
  * Authors:
  * Inki Dae 
  *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
  *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */

 #ifndef _FIMG2D_H_
diff --git a/exynos/fimg2d_reg.h b/exynos/fimg2d_reg.h
index 07dd634..d42296d 100644
--- a/exynos/fimg2d_reg.h
+++ b/exynos/fimg2d_reg.h
@@ -3,11 +3,24 @@
  * Authors:
  * Inki Dae 
  *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
  *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

[PATCH 17/35] drm/exynos: Use lockless gem BO free callback

2016-05-10 Thread Inki Dae



2016ë 04ì 27ì¼ 02:29ì Daniel Vetter ì´(ê°) ì´ ê¸:
> No dev->struct_mutex anywhere to be seen.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> 
> Cc: Inki Dae 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 5344940c8a07..f534ed62065e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -418,7 +418,7 @@ static struct drm_driver exynos_drm_driver = {
>   .get_vblank_counter = drm_vblank_no_hw_counter,
>   .enable_vblank  = exynos_drm_crtc_enable_vblank,
>   .disable_vblank = exynos_drm_crtc_disable_vblank,
> - .gem_free_object= exynos_drm_gem_free_object,
> + .gem_free_object_unlocked = exynos_drm_gem_free_object,
>   .gem_vm_ops = &exynos_drm_gem_vm_ops,
>   .dumb_create= exynos_drm_gem_dumb_create,
>   .dumb_map_offset= exynos_drm_gem_dumb_map_offset,
>

[PATCH 2/3] drm/exynos: Nuke dummy fb->dirty callback

2016-05-10 Thread Inki Dae

Hi Daniel,

2016ë 04ì 27ì¼ 20:38ì Daniel Vetter ì´(ê°) ì´ ê¸:
> It's an optional hook. Might be needed for frontbuffer rendering on
> manual upload displays, but a simple TODO doesn't explain at all what
> needs to be done or why.

We have a plan for partial update support but not now yet. Picked it up.

Thanks,
Inki Dae

> 
> Cc: Inki Dae 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 81cc5537cf25..f851a40ac6cb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -97,20 +97,9 @@ static int exynos_drm_fb_create_handle(struct 
> drm_framebuffer *fb,
>&exynos_fb->exynos_gem[0]->base, handle);
>  }
>  
> -static int exynos_drm_fb_dirty(struct drm_framebuffer *fb,
> - struct drm_file *file_priv, unsigned flags,
> - unsigned color, struct drm_clip_rect *clips,
> - unsigned num_clips)
> -{
> - /* TODO */
> -
> - return 0;
> -}
> -
>  static const struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
>   .destroy= exynos_drm_fb_destroy,
>   .create_handle  = exynos_drm_fb_create_handle,
> - .dirty  = exynos_drm_fb_dirty,
>  };
>  
>  struct drm_framebuffer *
>

[PATCH 3/3] drm/exynos/decon5433: fix trigger configuration

2016-05-10 Thread Inki Dae

Hi Andrzej,

2016ë 05ì 10ì¼ 15:08ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi Inki,
> 
> 
> On 05/10/2016 07:31 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 2016ë 04ì 29ì¼ 22:42ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> It seems trigger cannot be configured too early, otherwise it does not work 
>>> in
>>> case of panel. The patch fixes also trigger flag logic, previously 
>>> HW-TRIGGER
>>> flag was cleared in case of panel - as a result panel used always software
>> Andrzej, sorry but I can't understand what above two lines mean. Can you 
>> give me more details?
> 
> Details below.
> 
>>
>>> trigger.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 --
>>>  1 file changed, 4 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index 7b4f699..9ae913b 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -151,11 +151,13 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>> val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>>> writel(val, ctx->addr + DECON_CMU);
>>>  
>>> +   if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
>>> +   decon_setup_trigger(ctx);
>> Shouldn't it be configured in case of using SW trigger mode also?
>>
>> Thanks,
>> Inki Dae
>>
>>> +
>>> /* lcd on and use command if */
>>> val = VIDOUT_LCD_ON;
>>> if (ctx->out_type & IFTYPE_I80) {
>>> val |= VIDOUT_COMMAND_IF;
>>> -   decon_setup_trigger(ctx);
>>> } else {
>>> val |= VIDOUT_RGB_IF;
>>> }
>>> @@ -380,9 +382,6 @@ static void decon_swreset(struct decon_context *ctx)
>>> writel(VIDCON1_VCLK_RUN_VDEN_DISABLE, ctx->addr + DECON_VIDCON1);
>>> writel(CRCCTRL_CRCEN | CRCCTRL_CRCSTART_F | CRCCTRL_CRCCLKEN,
>>>ctx->addr + DECON_CRCCTRL);
>>> -
>>> -   if (ctx->out_type & IFTYPE_I80)
>>> -   decon_setup_trigger(ctx);
>>>  }
>>>  
>>>  static void decon_enable(struct exynos_drm_crtc *crtc)
>>> @@ -652,9 +651,8 @@ static int exynos5433_decon_probe(struct 
>>> platform_device *pdev)
>>>  
>>> if (ctx->out_type & IFTYPE_HDMI) {
>>> ctx->first_win = 1;
>>> -   ctx->out_type = IFTYPE_I80;
>>> } else if (of_get_child_by_name(dev->of_node, "i80-if-timings")) {
>>> -   ctx->out_type = IFTYPE_I80;
>>> +   ctx->out_type |= IFTYPE_I80;
> 
> ctx->out_type was overwritten here with IFTYPE_I80. So when
> decon_setup_trigger
> were called I80_HW_TRG bit was always clear and DECON_TRIGCON was configured
> to use soft trigger.

Indeed. Then shouldn't decon_setup_trigger function be called in both cases - 
SW and HW trigger modes?
Is there any reason to call the function only in case of HW trigger mode?

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
>>> }
>>>  
>>> for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
>>>
> 
>

[PATCH 3/3] drm/exynos/decon5433: fix trigger configuration

2016-05-10 Thread Inki Dae

Hi Andrzej,

2016ë 04ì 29ì¼ 22:42ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> It seems trigger cannot be configured too early, otherwise it does not work in
> case of panel. The patch fixes also trigger flag logic, previously HW-TRIGGER
> flag was cleared in case of panel - as a result panel used always software

Andrzej, sorry but I can't understand what above two lines mean. Can you give 
me more details?

> trigger.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 7b4f699..9ae913b 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -151,11 +151,13 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
>   writel(val, ctx->addr + DECON_CMU);
>  
> + if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
> + decon_setup_trigger(ctx);

Shouldn't it be configured in case of using SW trigger mode also?

Thanks,
Inki Dae

> +
>   /* lcd on and use command if */
>   val = VIDOUT_LCD_ON;
>   if (ctx->out_type & IFTYPE_I80) {
>   val |= VIDOUT_COMMAND_IF;
> - decon_setup_trigger(ctx);
>   } else {
>   val |= VIDOUT_RGB_IF;
>   }
> @@ -380,9 +382,6 @@ static void decon_swreset(struct decon_context *ctx)
>   writel(VIDCON1_VCLK_RUN_VDEN_DISABLE, ctx->addr + DECON_VIDCON1);
>   writel(CRCCTRL_CRCEN | CRCCTRL_CRCSTART_F | CRCCTRL_CRCCLKEN,
>  ctx->addr + DECON_CRCCTRL);
> -
> - if (ctx->out_type & IFTYPE_I80)
> - decon_setup_trigger(ctx);
>  }
>  
>  static void decon_enable(struct exynos_drm_crtc *crtc)
> @@ -652,9 +651,8 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
>  
>   if (ctx->out_type & IFTYPE_HDMI) {
>   ctx->first_win = 1;
> - ctx->out_type = IFTYPE_I80;
>   } else if (of_get_child_by_name(dev->of_node, "i80-if-timings")) {
> - ctx->out_type = IFTYPE_I80;
> + ctx->out_type |= IFTYPE_I80;
>   }
>  
>   for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
>

drm/exynos: fimd: pagefault when restarting X

2016-05-09 Thread Inki Dae

Hi Tobias and Andrzej,

Thanks for reporting.

2016-05-06 17:47 GMT+09:00 Andrzej Hajda :
> +CC: Inki
>
> On 05/06/2016 09:48 AM, Tobias Jakobi wrote:
>> Hello Andrzej,
>>
>>
>> Andrzej Hajda wrote:
>>> Hi Tobias,
>>>
>>> On 05/05/2016 07:27 PM, Tobias Jakobi wrote:
>>>> Hello,
>>>>
>>>> here's another issue I experience when enabling FIMD on the ODROID-X2.
>>>>
>>>> I can trigger a IOMMU pagefault by starting X once, quitting, and
>>>> restarting X again.
>>>>
>>>
>>> I have observed similar behavior on arm64 dev board which
>>> uses decon5433 device.
>>>
>>>> The pagefault occurs exactly when exynos_drm_free_buf() is called on
>>>> this buffer, which then destroys the IOMMU mapping.
>>>>
>>>> Obviously the FIMD block is still happily scanning out from the buffer,
>>>> even though the previous fimd_update_plane() has configured a new
>>>> dma_addr.
>>>>
>>>> Now here's what I guess happens:
>>>> Hardware registers are never updated in fimd_update_plane(), but update
>>>> is only performed on the shadow registers. Shadow registers are written
>>>> to the real ones on next vblank, but such a vblank nevers occurs before
>>>> DRM core decides that the previously bound fb is no longer used.
>>>>
>>>> Now I'm not sure if I'm just seeing this since nothing is connected to
>>>> the external connector on the board. Still something looks wrong here.
>>>> If the real update of the hw registers really happens on the next
>>>> vblank, then the driver should probably still hold a reference to the
>>>> old fb, which is then dropped in the vblank irq handler?
>>>
>>> For sure there is a problem in synchronization with irq handler and
>>> in some circumstances driver assumes crtc (fimd/decon) stopped using
>>> old framebuffer which is not true. In system without IOMMU it was usually
>>> painless, but since IOMMU started working it signals this bug quite
>>> loudly :)
>> One additional thought, I'm not sure that the driver should update on
>> vblank in this situation anyway. As one can see the fimd_update_plane()
>> call is triggered by a setcrtc ioctl, so AFAIK the update should happen
>> immediately.
>> My knowledge about FIMD is very limited, but I guess there is a way to
>> write directly without using the shadow registers.
>
> My knowledge about fimd is also limited, but it seems it is not possible

Right, not possible to update registers directly in Exynos SoC.

> to update registers directly - it looks for me reasonable -  update on
> vsync is a cheap way to make updates of multiple registers in atomic way
> (with help of shadow protect bits).

Also right. I think there should be no problem with atomic modeset
support - that is why I removed exynos_drm_crtc_complete_scanout
function- but it seems there is other issue we missed.
https://lists.freedesktop.org/archives/dri-devel/2015-December/097648.html

Thanks,
Inki Dae

>
> Regards
> Andrzej
>
>>
>>
>>> I will prepare patch for this, hopefully today/tomorrow.
>>> As the patch will touch exynos-drm core it should be tested on different
>>> platforms / configurations, I will be glad if you can test on your board.
>> Sure, I can do that!
>>
>>
>> With best wishes,
>> Tobias
>>
>>
>>>
>>> Regards
>>> Andrzej
>>>
>>>
>>>>
>>>>
>>>> With best wishes,
>>>> Tobias
>>>>
>>>>
>>>>
>>>> dmesg / startx run 1:
>>>>> [  229.728455] [drm:drm_stub_open]
>>>>> [  229.728554] [drm:drm_open_helper] pid = 2620, minor = 0
>>>>> [  229.731411] [drm:ipp_subdrv_open] done priv[ee2be810]
>>>>> [  229.737144] [drm:drm_setup]
>>>>> [  229.739394] [drm:drm_ioctl] pid=2620, dev=0xe200, auth=1, 
>>>>> DRM_IOCTL_SET_VERSION
>>>>> [  229.746721] [drm:drm_ioctl] pid=2620, dev=0xe200, auth=1, 
>>>>> DRM_IOCTL_GET_UNIQUE
>>>>> [  229.753799] [drm:drm_ioctl] pid=2620, dev=0xe200, auth=1, 
>>>>> DRM_IOCTL_GET_UNIQUE
>>>>> [  229.761193] [drm:drm_ioctl] pid=2620, dev=0xe200, auth=1, 
>>>>> DRM_IOCTL_VERSION
>>>>> [  229.767889] [drm:drm_ioctl] pid=2620, dev=0xe200, auth=1, 
>>>>> DRM_IOCTL_VERSION
>>>>> [  229.774886] [drm

[PATCH 3/6] drm/exynos/hdmi: expose HDMI-PHY clock as pipeline clock

2016-05-09 Thread Inki Dae

Hi Andrzej,



2016-05-04 18:52 GMT+09:00 Andrzej Hajda :
> Hi Inki,
>
> It looks like this patch felt through the cracks.
> It is a part of "drm/exynos: add pipeline clock support" patchset.

Ah, sorry.

> Other patches from the patchset were taken already.
> Could you queue it to next pull request?
>

Got it.

Thanks,
Inki Dae

> Regards
> Andrzej
>
> On 03/23/2016 02:25 PM, Andrzej Hajda wrote:
>> HDMI-PHY clock should be accessible from other components in the pipeline.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 67 
>> ++--
>>  1 file changed, 48 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 49a5902..0d1c2f0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -146,6 +146,7 @@ struct hdmi_context {
>>   struct clk  **clk_muxes;
>>   struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>>   struct regulator*reg_hdmi_en;
>> + struct exynos_drm_clk   phy_clk;
>>  };
>>
>>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>> @@ -1448,7 +1449,6 @@ static void hdmiphy_conf_apply(struct hdmi_context 
>> *hdata)
>>
>>  static void hdmi_conf_apply(struct hdmi_context *hdata)
>>  {
>> - hdmiphy_conf_apply(hdata);
>>   hdmi_start(hdata, false);
>>   hdmi_conf_init(hdata);
>>   hdmi_audio_init(hdata);
>> @@ -1481,10 +1481,8 @@ static void hdmi_set_refclk(struct hdmi_context 
>> *hdata, bool on)
>>  SYSREG_HDMI_REFCLK_INT_CLK, on ? ~0 : 0);
>>  }
>>
>> -static void hdmi_enable(struct drm_encoder *encoder)
>> +static void hdmiphy_enable(struct hdmi_context *hdata)
>>  {
>> - struct hdmi_context *hdata = encoder_to_hdmi(encoder);
>> -
>>   if (hdata->powered)
>>   return;
>>
>> @@ -1500,11 +1498,40 @@ static void hdmi_enable(struct drm_encoder *encoder)
>>
>>   hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, 0, HDMI_PHY_POWER_OFF_EN);
>>
>> - hdmi_conf_apply(hdata);
>> + hdmiphy_conf_apply(hdata);
>>
>>   hdata->powered = true;
>>  }
>>
>> +static void hdmiphy_disable(struct hdmi_context *hdata)
>> +{
>> + if (!hdata->powered)
>> + return;
>> +
>> + hdmi_reg_writemask(hdata, HDMI_CON_0, 0, HDMI_EN);
>> +
>> + hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0, HDMI_PHY_POWER_OFF_EN);
>> +
>> + hdmi_set_refclk(hdata, false);
>> +
>> + regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>> + PMU_HDMI_PHY_ENABLE_BIT, 0);
>> +
>> + regulator_bulk_disable(ARRAY_SIZE(supply), hdata->regul_bulk);
>> +
>> + pm_runtime_put_sync(hdata->dev);
>> +
>> + hdata->powered = false;
>> +}
>> +
>> +static void hdmi_enable(struct drm_encoder *encoder)
>> +{
>> + struct hdmi_context *hdata = encoder_to_hdmi(encoder);
>> +
>> + hdmiphy_enable(hdata);
>> + hdmi_conf_apply(hdata);
>> +}
>> +
>>  static void hdmi_disable(struct drm_encoder *encoder)
>>  {
>>   struct hdmi_context *hdata = encoder_to_hdmi(encoder);
>> @@ -1528,22 +1555,9 @@ static void hdmi_disable(struct drm_encoder *encoder)
>>   if (funcs && funcs->disable)
>>   (*funcs->disable)(crtc);
>>
>> - hdmi_reg_writemask(hdata, HDMI_CON_0, 0, HDMI_EN);
>> -
>>   cancel_delayed_work(&hdata->hotplug_work);
>>
>> - hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0, HDMI_PHY_POWER_OFF_EN);
>> -
>> - hdmi_set_refclk(hdata, false);
>> -
>> - regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>> - PMU_HDMI_PHY_ENABLE_BIT, 0);
>> -
>> - regulator_bulk_disable(ARRAY_SIZE(supply), hdata->regul_bulk);
>> -
>> - pm_runtime_put_sync(hdata->dev);
>> -
>> - hdata->powered = false;
>> + hdmiphy_disable(hdata);
>>  }
>>
>>  static const struct drm_encoder_helper_funcs 
>> exynos_hdmi_encoder_helper_funcs = {
>> @@ -1627,6 +1641,17 @@ static int hdmi_clk_init(struct hdmi_context *hdata)
>>   return hdmi_clks_get(hdata, &drv_data->clk_muxes, hdata->clk_muxes);
>>  }
>>
>> +static voi

[GIT PULL] exynos-drm-next

2016-04-30 Thread Inki Dae

Hi Dave,

This pull request includes some code refactoring, Exynos5433 and
HW trigger mode supports.

Summary:
- Support for pipeline clock between KMS drivers.
  . Exynos SoC is required to control clocks across KMS drivers
according to Exynos SoC version. So this patch refactos
some relevant codes and provides generic solution for it.
- Add Exynos5433 SoC support to HDMI parts - HDMI and DECON-TV.
- Add HW trigger mode support to CRTC drivers.
  . In case of using i80 Panel, some Exynos SoC supports HW trigger
mode so this patch makes trigger mode - HW or SW trigger - to be
set according to SoC version properly.
- And some cleanups and regression fixups.

Please, kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:

  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into 
drm-next (2016-04-29 14:57:51 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to b5bf0f1ea3658254bd72ef64abc97786e8a32255:

  drm/exynos: clean up register definions for fimd and decon (2016-04-30 
11:34:14 +0900)


Andrzej Hajda (23):
  drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
  drm/exynos: build fbdev code conditionally
  drm/exynos/hdmi: clock code re-factoring
  drm/exynos/hdmi: constify global variables
  drm/exynos/hdmi: use array specifier for HDMI-PHY configurations
  drm/exynos/hdmi: code cleanup
  drm/exynos/hdmi: stop programming registers with default values
  dt-bindings: exynos_hdmi: add bindings for Exynos5433 variant
  drm/exynos/hdmi: add Exynos5433 support
  dt-bindings: video: add PCLK clock entry to exynos5433-decon
  dt-bindings: video: exynos5433-decon: add bindings for DECON-TV
  drm/exynos/hdmi: fix PHY configuration sequence
  drm/exynos/hdmi: add PHY power off signal handling
  drm/exynos/hdmi: add core reset code
  drm/exynos/hdmi: remove registry dump
  drm/exynos/decon5433: fix DECON standalone update
  drm/exynos/decon5433: reset decon on start
  drm/exynos/decon5433: do not protect window in plane disable
  drm/exynos: add helper to get crtc from pipe
  drm/exynos: add support for pipeline clock to the framework
  drm/exynos/decon5433: enable HDMI-PHY before configuring DECON
  drm/exynos/mixer: enable HDMI-PHY before configuring MIXER
  drm/exynos: convert clock_enable crtc callback to pipeline clock

Arnd Bergmann (1):
  drm/exynos: fix error handling in exynos_drm_subdrv_open

Dan Carpenter (2):
  drm/exynos: mic: fix an error code
  drm/exynos: fix a warning message

Inki Dae (4):
  drm/exynos: clean up wait_for_vblank
  drm/exynos: fimd: add HW trigger support
  drm/exynos: decon: clean up interface type
  drm/exynos: clean up register definions for fimd and decon

Javier Martinez Canillas (1):
  drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency

Marek Szyprowski (8):
  drm/exynos: fimd: fix broken dp_clock control
  drm/exynos: exynos5433_decon: use generic of_device_get_match_data helper
  drm/exynos: dsi: use generic of_device_get_match_data helper
  drm/exynos: fimd: use generic of_device_get_match_data helper
  drm/exynos: rotator: use generic of_device_get_match_data helper
  drm/exynos: hdmi: use generic of_device_get_match_data helper
  drm/exynos: mixer: remove support for non-dt platforms
  drm/exynos: mixer: use generic of_device_get_match_data helper

 .../bindings/display/exynos/exynos5433-decon.txt   |5 +-
 .../bindings/display/exynos/exynos_hdmi.txt|   27 +-
 drivers/gpu/drm/exynos/Kconfig |2 +-
 drivers/gpu/drm/exynos/Makefile|6 +-
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  |   86 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |1 -
 drivers/gpu/drm/exynos/exynos_dp.c |9 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   10 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   28 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|   27 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c |   11 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   11 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h  |   23 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   99 ++-
 drivers/gpu/drm/exynos/exynos_drm_mic.c|3 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c  |   12 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c|   11 +-
 drivers/gpu/drm/exynos/exy

[PATCH 2/2] ARM: dts: add exynos5420-fimd compatible

2016-04-21 Thread Inki Dae

2016-04-21 19:06 GMT+09:00 Krzysztof Kozlowski :
> On 02/15/2016 04:59 AM, Krzysztof Kozlowski wrote:
>> On 15.02.2016 09:57, Krzysztof Kozlowski wrote:
>>> On 12.02.2016 22:31, Chanho Park wrote:
>>>> This patch changes the compatible of exynos5420 fimd
>>>> to "exynos5420-fimd". To support mic bypass from display
>>>> path, the new compatible is introduced for exynos5420.
>>>>
>>>> Cc: Inki Dae 
>>>> Cc: Kukjin Kim 
>>>> Cc: Krzysztof Kozlowski 
>>>> Signed-off-by: Chanho Park 
>>>> ---
>>>>  arch/arm/boot/dts/exynos5420.dtsi | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>
>>> Looks okay to me and also looks independent from patch #1. I will apply
>>> it for late v4.6 if patch #1 got accepted by Inki.
>>>
>>> Anyway, for reference:
>>> Reviewed-by: Krzysztof Kozlowski 
>>
>> Stupid me, of course it cannot go independently through my tree. Please
>> feel free to take it through drm-exynos with my reviewed-by tag.
>
> Inki did not pick it up, so applied now for late v4.7.
>

Forgot it. Sorry for this Chanho and Krzysztof.

Thanks,
Inki Dae

> Best regards,
> Krzysztof
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/7] drm/exynos: dsi: use generic of_device_get_match_data helper

2016-04-18 Thread Inki Dae

Hi Marek,

2016ë 04ì 01ì¼ 22:17ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> Simplify code by replacing custom code by generic helper.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 63c84a106c0b..b6518df2411d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -532,15 +532,6 @@ static const struct of_device_id exynos_dsi_of_match[] = 
> {
>   { }
>  };
>  
> -static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
> - struct platform_device *pdev)
> -{
> - const struct of_device_id *of_id =
> - of_match_device(exynos_dsi_of_match, &pdev->dev);
> -
> - return (struct exynos_dsi_driver_data *)of_id->data;
> -}
> -
>  static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
>  {
>   if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
> @@ -1833,7 +1824,7 @@ static int exynos_dsi_probe(struct platform_device 
> *pdev)
>   dsi->dsi_host.dev = dev;
>  
>   dsi->dev = dev;
> - dsi->driver_data = exynos_dsi_get_driver_data(pdev);
> + dsi->driver_data = of_device_get_match_data(dev);

drivers/gpu/drm/exynos/exynos_drm_dsi.c: In function 'exynos_dsi_probe':
drivers/gpu/drm/exynos/exynos_drm_dsi.c:1827:19: warning: assignment discards 
'const' qualifier from pointer target type

Looks you missed const prefix and for patch 3 also but I can fix them.

Thanks,
Inki Dae

>  
>   ret = exynos_dsi_parse_dt(dsi);
>   if (ret)
>

[GIT PULL] exynos-drm-fixes

2016-04-13 Thread Inki Dae

HI Dave,

   This pull request includes several regression fixups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae


The following changes since commit 928815245cbdaa611873424759d5e7a7293dd18b:

  Merge tag 'drm-intel-fixes-2016-04-07' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-04-11 13:30:05 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to 2072fe51466f86e1f0eedf12bff7106913807efc:

  drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency (2016-04-13 
00:23:49 +0900)


Andrzej Hajda (2):
  drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
  drm/exynos: build fbdev code conditionally

Arnd Bergmann (1):
  drm/exynos: fix error handling in exynos_drm_subdrv_open

Dan Carpenter (2):
  drm/exynos: mic: fix an error code
  drm/exynos: fix a warning message

Javier Martinez Canillas (1):
  drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency

Marek Szyprowski (1):
  drm/exynos: fimd: fix broken dp_clock control

 drivers/gpu/drm/exynos/Kconfig|2 +-
 drivers/gpu/drm/exynos/Makefile   |6 +++---
 drivers/gpu/drm/exynos/exynos_drm_core.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c|   11 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   11 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h |   23 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_mic.c   |3 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   12 +++-
 9 files changed, 48 insertions(+), 24 deletions(-)

[PATCH 5/7] drm/exynos/decon5433: fix DECON standalone update

2016-04-12 Thread Inki Dae



2016ë 04ì 12ì¼ 16:33ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 04/12/2016 04:25 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> DECON should be updated after un-protecting windows and after changing
>>> output parameters, otherwise image is not displayed in case of HDMI path.
>> I'm not sure why STANDALONE_UPDATE_F bit should be updated after 
>> un-protecting windows and changing output parameters.
>> The fields with _F prefix mean that these will be applied after vsync so we 
>> use protection window in case of all registers which affect display output 
>> so that they can be updated together.
>>
>> Wouldn't there be other thing which affects HDMI output?
>>
>> In addition, we would need another patch which updates TV relevant registers 
>> only in case of DECON-TV. DECON_UPDATE is a register for DECON-TV.
> 
> DECON_UPDATE is present in both DECON and DECON-TV and in both cases
> have the same field STANDALONE_UPDATE_F.
> 
> Documentation for 5433 says:
>> When you modify the shadow attributed registers, set
>> STANDALONE_UPDATE_F.
>>
> So it should be set after setting registers with _F suffix,
> but it has also _F suffix - contradiction. So I guess this _F suffix
> should not be treated too strictly in this case. Moreover the suffix
> has been removed in Exynos7420 - it is called just STANDALONE_UPDATE.

Indeed. I thought the register name has TV suffix so this register is for 
DECON-TV. However, without the register setting, DECON didn't work correctly - 
display not updated.


> 
> Anyway I am not sure what is exact purpose of this register and
> the changes proposed in the patch are rather results of multiple tests
> with hardware - documentation is rather poor on this subject.
> 
> I am also not sure why DECON works without it but DECON-TV does not,
> anyway I set it in both variants because documentation says so.

Ok, picked them up.

Thanks,
Inki Dae

> 
> Regards
> Andrzej
> 
>>
>> Thanks,
>> Inki Dae
>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 15 ---
>>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index ab9154e..7fec656 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -191,6 +191,8 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>>  
>>> /* enable output and display signal */
>>> decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
>>> +
>>> +   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>>  }
>>>  
>>>  static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int 
>>> win,
>>> @@ -316,9 +318,6 @@ static void decon_update_plane(struct exynos_drm_crtc 
>>> *crtc,
>>>  
>>> /* window enable */
>>> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
>>> -
>>> -   /* standalone update */
>>> -   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>>  }
>>>  
>>>  static void decon_disable_plane(struct exynos_drm_crtc *crtc,
>>> @@ -336,9 +335,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
>>> *crtc,
>>> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>>>  
>>> decon_shadow_protect_win(ctx, win, false);
>>> -
>>> -   /* standalone update */
>>> -   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>>  }
>>>  
>>>  static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
>>> @@ -352,6 +348,9 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
>>> *crtc)
>>> for (i = ctx->first_win; i < WINDOWS_NR; i++)
>>> decon_shadow_protect_win(ctx, i, false);
>>>  
>>> +   /* standalone update */
>>> +   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>> +
>>> if (ctx->out_type == IFTYPE_I80)
>>> set_bit(BIT_WIN_UPDATED, &ctx->flags);
>>>  }
>>> @@ -463,8 +462,10 @@ static void decon_clear_channels(struct 
>>> exynos_drm_crtc *crtc)
>>> decon_shadow_protect_win(ctx, win, true);
>>> decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>>> decon_shadow_protect_win(ctx, win, false);
>>> -   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>> }
>>> +
>>> +   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>>> +
>>> /* TODO: wait for possible vsync */
>>> msleep(50);
>>>  
>>>
> 
>

[PATCH v2] drm/exynos: decon: clean up interface type

2016-04-12 Thread Inki Dae

This patch cleans up interface type relevant codes.

Trigger mode is determinded only by i80 mode, which isn't
related to Display types - HDMI or Display controller.
So this patch makes the trigger mode to be set only in case of
i80 mode - For DECON-TV, HW Trigger mode is flaged mandatorily
because HDMI Timing Generator generates VSYNC signal
which works as a hardware trigger.

Changelog v2.
- If interface type is HDMI then set out_type to I80.
- fix compile warning.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 57 ++-
 1 file changed, 30 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5245bc5..eacbb73 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -28,6 +28,10 @@
 #define WINDOWS_NR 3
 #define MIN_FB_WIDTH_FOR_16WORD_BURST  128

+#define IFTYPE_I80 (1 << 0)
+#define I80_HW_TRG (1 << 1)
+#define IFTYPE_HDMI(1 << 2)
+
 static const char * const decon_clks_name[] = {
"pclk",
"aclk_decon",
@@ -38,12 +42,6 @@ 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,
@@ -61,7 +59,7 @@ struct decon_context {
struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
int pipe;
unsigned long   flags;
-   enum decon_iftype   out_type;
+   unsigned long   out_type;
int first_win;
 };

@@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)

if (!test_and_set_bit(BIT_IRQS_ENABLED, &ctx->flags)) {
val = VIDINTCON0_INTEN;
-   if (ctx->out_type == IFTYPE_I80)
+   if (ctx->out_type & IFTYPE_I80)
val |= VIDINTCON0_FRAMEDONE;
else
val |= VIDINTCON0_INTFRMEN;
@@ -119,7 +117,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)

 static void decon_setup_trigger(struct decon_context *ctx)
 {
-   u32 val = (ctx->out_type != IFTYPE_HDMI)
+   u32 val = !(ctx->out_type & I80_HW_TRG)
? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
  TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
: TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
@@ -136,7 +134,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
if (test_bit(BIT_SUSPENDED, &ctx->flags))
return;

-   if (ctx->out_type == IFTYPE_HDMI) {
+   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;
@@ -151,17 +149,20 @@ static void decon_commit(struct exynos_drm_crtc *crtc)

/* lcd on and use command if */
val = VIDOUT_LCD_ON;
-   if (ctx->out_type == IFTYPE_I80)
+   if (ctx->out_type & IFTYPE_I80) {
val |= VIDOUT_COMMAND_IF;
-   else
+   decon_setup_trigger(ctx);
+   } else {
val |= VIDOUT_RGB_IF;
+   }
+
writel(val, ctx->addr + DECON_VIDOUTCON0);

val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);

-   if (ctx->out_type != IFTYPE_I80) {
+   if (!(ctx->out_type & IFTYPE_I80)) {
val = VIDTCON00_VBPD_F(
m->crtc_vtotal - m->crtc_vsync_end - 1) |
VIDTCON00_VFPD_F(
@@ -183,8 +184,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
writel(val, ctx->addr + DECON_VIDTCON11);
}

-   decon_setup_trigger(ctx);
-
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
 }
@@ -300,7 +299,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
val = dma_addr + pitch * state->src.h;
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));

-   if (ctx->out_type != IFTYPE_HDMI)
+   if (!(ctx->out_type & IFTYPE_HDMI))
val = BIT_VAL(pitch - state->crtc.w * bpp, 27, 14)
| BIT_VAL(state->crtc.w * bpp, 13, 0);
else
@@ -348,7 +347,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);

-   if (ctx->out_typ

[PATCH 3/3] drm/exynos: decon: clean up interface type

2016-04-12 Thread Inki Dae



2016ë 04ì 12ì¼ 14:55ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi Inki,
> 
> On 04/12/2016 02:40 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 2016ë 04ì 05ì¼ 21:52ì Inki Dae ì´(ê°) ì´ ê¸:
>>>  Hi Andrzej,
>>>
>>> 2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
>>>> Hi Inki,
>>>>
>>>> On 04/05/2016 10:27 AM, Inki Dae wrote:
>>>>> This patch cleans up interface type relevant codes.
>>>>>
>>>>> Trigger mode is determinded only by i80 mode, which isn't
>>>>> related to Display types - HDMI or Display controller.
>>>>> So this patch makes the trigger mode to be set only in case of
>>>>> i80 mode.
>>>> With this patch HDMI path image has serious synchronization problems.
>>>> Exynos5433 documentation says that HDMI Timing Generator generates VSYNC
>>>> signal which works as a hardware trigger for DECON-TV, so I guess
>>>> trigger is required.
>>> Right. One I missed. For DECON-TV, seems that HW trigger mode is mandatory.
>> Looks considered already. for DECON-TV, I80_HW_TRG flag is used mandatorily,
>>  .compatible = "samsung,exynos5433-decon-tv",
>>  .data = (void *)(I80_HW_TRG | IFTYPE_HDMI)
> Here it is OK, but there are other changes, see below for more details.
>>
>>>> Btw, I think it could be good to remove suffixes I80_RGV from
>>>> TRIGCON_HWTRIGEN_I80_RGB and TRIGCON_HWTRIGMASK_I80_RGB - they are
>>>> misleading and differ from documentation.
>>> Indeed. Looked strange when I wrote the suffixes.
>> will send another cleanup patch.
>>
>> Thanks,
>> Inki Dae
>>
>>>> As far as I have tested I80 mode works OK on Decon5433.
>>> Thanks for testing.
>>> Inki Dae
>>>
>>>> Regards
>>>> Andrzej
>>>>
>>>>> Signed-off-by: Inki Dae 
>>>>> ---
>>>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 53 
>>>>> ++-
>>>>>  1 file changed, 27 insertions(+), 26 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>>>> index 5245bc5..5922e99 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>>>> @@ -28,6 +28,10 @@
>>>>>  #define WINDOWS_NR   3
>>>>>  #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>>>>>
>>>>> +#define IFTYPE_I80   (1 << 0)
>>>>> +#define I80_HW_TRG   (1 << 1)
>>>>> +#define IFTYPE_HDMI  (1 << 2)
>>>>> +
>>>>>  static const char * const decon_clks_name[] = {
>>>>>   "pclk",
>>>>>   "aclk_decon",
>>>>> @@ -38,12 +42,6 @@ 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,
>>>>> @@ -61,7 +59,7 @@ struct decon_context {
>>>>>   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
>>>>>   int pipe;
>>>>>   unsigned long   flags;
>>>>> - enum decon_iftype   out_type;
>>>>> + unsigned intout_type;
>>>>>   int first_win;
>>>>>  };
>>>>>
>>>>> @@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc 
>>>>> *crtc)
>>>>>
>>>>>   if (!test_and_set_bit(BIT_IRQS_ENABLED, &ctx->flags)) {
>>>>>   val = VIDINTCON0_INTEN;
>>>>> - if (ctx->out_type == IFTYPE_I80)
>>>>> + if (ctx->out_type & IFTYPE_I80)
>>>>>   val |= VIDINTCON0_FRAMEDONE;
>>>>>   else
>>>>>   val |= VIDINTCON0_INTFRMEN;
>>>>> @@ -119,7 +117,7 @@ static void dec

[PATCH 5/7] drm/exynos/decon5433: fix DECON standalone update

2016-04-12 Thread Inki Dae

Hi Andrzej,

2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> DECON should be updated after un-protecting windows and after changing
> output parameters, otherwise image is not displayed in case of HDMI path.

I'm not sure why STANDALONE_UPDATE_F bit should be updated after un-protecting 
windows and changing output parameters.
The fields with _F prefix mean that these will be applied after vsync so we use 
protection window in case of all registers which affect display output so that 
they can be updated together.

Wouldn't there be other thing which affects HDMI output?

In addition, we would need another patch which updates TV relevant registers 
only in case of DECON-TV. DECON_UPDATE is a register for DECON-TV.

Thanks,
Inki Dae

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index ab9154e..7fec656 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -191,6 +191,8 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>  
>   /* enable output and display signal */
>   decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
> +
> + decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>  }
>  
>  static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
> @@ -316,9 +318,6 @@ static void decon_update_plane(struct exynos_drm_crtc 
> *crtc,
>  
>   /* window enable */
>   decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, ~0);
> -
> - /* standalone update */
> - decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>  }
>  
>  static void decon_disable_plane(struct exynos_drm_crtc *crtc,
> @@ -336,9 +335,6 @@ static void decon_disable_plane(struct exynos_drm_crtc 
> *crtc,
>   decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>  
>   decon_shadow_protect_win(ctx, win, false);
> -
> - /* standalone update */
> - decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>  }
>  
>  static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
> @@ -352,6 +348,9 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
> *crtc)
>   for (i = ctx->first_win; i < WINDOWS_NR; i++)
>   decon_shadow_protect_win(ctx, i, false);
>  
> + /* standalone update */
> + decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
> +
>   if (ctx->out_type == IFTYPE_I80)
>   set_bit(BIT_WIN_UPDATED, &ctx->flags);
>  }
> @@ -463,8 +462,10 @@ static void decon_clear_channels(struct exynos_drm_crtc 
> *crtc)
>   decon_shadow_protect_win(ctx, win, true);
>   decon_set_bits(ctx, DECON_WINCONx(win), WINCONx_ENWIN_F, 0);
>   decon_shadow_protect_win(ctx, win, false);
> - decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>   }
> +
> + decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
> +
>   /* TODO: wait for possible vsync */
>   msleep(50);
>  
>

[PATCH] drm/exynos: clean up register definions for fimd and decon

2016-04-12 Thread Inki Dae

This patch removes suffixes from I80 relevant register definitions,
which are misleading.

This is based on top of below patch set,
 http://www.spinics.net/lists/dri-devel/msg104057.html

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 23 +++
 include/video/exynos5433_decon.h  |  6 +++---
 3 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5922e99..8cfef0d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -121,7 +121,7 @@ static void decon_setup_trigger(struct decon_context *ctx)
? 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;
+ TRIGCON_HWTRIGMASK | TRIGCON_HWTRIGEN;
writel(val, ctx->addr + DECON_TRIGCON);
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index c4cd16a..9fa07a6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -68,15 +68,15 @@
 /* color key value register for hardware window 1 ~ 4. */
 #define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))

-/* I80 / RGB trigger control register */
+/* I80 trigger control register */
 #define TRIGCON0x1A4
-#define TRGMODE_I80_RGB_ENABLE_I80 (1 << 0)
-#define SWTRGCMD_I80_RGB_ENABLE(1 << 1)
+#define TRGMODE_ENABLE (1 << 0)
+#define SWTRGCMD_ENABLE(1 << 1)
 /* Exynos3250, 3472, 4415, 5260 5410, 5420 and 5422 only supported. */
-#define HWTRGEN_I80_RGB_ENABLE (1 << 3)
-#define HWTRGMASK_I80_RGB_ENABLE   (1 << 4)
+#define HWTRGEN_ENABLE (1 << 3)
+#define HWTRGMASK_ENABLE   (1 << 4)
 /* Exynos3250, 3472, 4415, 5260, 5420 and 5422 only supported. */
-#define HWTRIGEN_PER_RGB_ENABLE(1 << 31)
+#define HWTRIGEN_PER_ENABLE(1 << 31)

 /* display mode change control register except exynos4 */
 #define VIDOUT_CON 0x000
@@ -425,16 +425,15 @@ static void fimd_setup_trigger(struct fimd_context *ctx)
u32 trg_type = ctx->driver_data->trg_type;
u32 val = readl(timing_base + TRIGCON);

-   val &= ~(TRGMODE_I80_RGB_ENABLE_I80);
+   val &= ~(TRGMODE_ENABLE);

if (trg_type == I80_HW_TRG) {
if (ctx->driver_data->has_hw_trigger)
-   val |= HWTRGEN_I80_RGB_ENABLE |
-   HWTRGMASK_I80_RGB_ENABLE;
+   val |= HWTRGEN_ENABLE | HWTRGMASK_ENABLE;
if (ctx->driver_data->has_trigger_per_te)
-   val |= HWTRIGEN_PER_RGB_ENABLE;
+   val |= HWTRIGEN_PER_ENABLE;
} else {
-   val |= TRGMODE_I80_RGB_ENABLE_I80;
+   val |= TRGMODE_ENABLE;
}

writel(val, timing_base + TRIGCON);
@@ -884,7 +883,7 @@ static void fimd_trigger(struct device *dev)
atomic_set(&ctx->triggering, 1);

reg = readl(timing_base + TRIGCON);
-   reg |= (TRGMODE_I80_RGB_ENABLE_I80 | SWTRGCMD_I80_RGB_ENABLE);
+   reg |= (TRGMODE_ENABLE | SWTRGCMD_ENABLE);
writel(reg, timing_base + TRIGCON);

/*
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index c1c1ca1..0098a52 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -179,9 +179,9 @@
 #define TRIGCON_TRIGMODE_W1BUF (1 << 10)
 #define TRIGCON_SWTRIGCMD_W0BUF(1 << 6)
 #define TRIGCON_TRIGMODE_W0BUF (1 << 5)
-#define TRIGCON_HWTRIGMASK_I80_RGB (1 << 4)
-#define TRIGCON_HWTRIGEN_I80_RGB   (1 << 3)
-#define TRIGCON_HWTRIG_INV_I80_RGB (1 << 2)
+#define TRIGCON_HWTRIGMASK (1 << 4)
+#define TRIGCON_HWTRIGEN   (1 << 3)
+#define TRIGCON_HWTRIG_INV (1 << 2)
 #define TRIGCON_SWTRIGCMD  (1 << 1)
 #define TRIGCON_SWTRIGEN   (1 << 0)

-- 
1.9.1

[PATCH 3/3] drm/exynos: decon: clean up interface type

2016-04-12 Thread Inki Dae

Hi Andrzej,

2016ë 04ì 05ì¼ 21:52ì Inki Dae ì´(ê°) ì´ ê¸:
>  Hi Andrzej,
> 
> 2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
>> Hi Inki,
>>
>> On 04/05/2016 10:27 AM, Inki Dae wrote:
>>> This patch cleans up interface type relevant codes.
>>>
>>> Trigger mode is determinded only by i80 mode, which isn't
>>> related to Display types - HDMI or Display controller.
>>> So this patch makes the trigger mode to be set only in case of
>>> i80 mode.
>>
>> With this patch HDMI path image has serious synchronization problems.
>> Exynos5433 documentation says that HDMI Timing Generator generates VSYNC
>> signal which works as a hardware trigger for DECON-TV, so I guess
>> trigger is required.
> 
> Right. One I missed. For DECON-TV, seems that HW trigger mode is mandatory.

Looks considered already. for DECON-TV, I80_HW_TRG flag is used mandatorily,
.compatible = "samsung,exynos5433-decon-tv",
.data = (void *)(I80_HW_TRG | IFTYPE_HDMI)

>>
>> Btw, I think it could be good to remove suffixes I80_RGV from
>> TRIGCON_HWTRIGEN_I80_RGB and TRIGCON_HWTRIGMASK_I80_RGB - they are
>> misleading and differ from documentation.
> 
> Indeed. Looked strange when I wrote the suffixes.

will send another cleanup patch.

Thanks,
Inki Dae

> 
>>
>> As far as I have tested I80 mode works OK on Decon5433.
> 
> Thanks for testing.
> Inki Dae
> 
>>
>> Regards
>> Andrzej
>>
>>>
>>> Signed-off-by: Inki Dae 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 53 
>>> ++-
>>>  1 file changed, 27 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> index 5245bc5..5922e99 100644
>>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>>> @@ -28,6 +28,10 @@
>>>  #define WINDOWS_NR   3
>>>  #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>>>
>>> +#define IFTYPE_I80   (1 << 0)
>>> +#define I80_HW_TRG   (1 << 1)
>>> +#define IFTYPE_HDMI  (1 << 2)
>>> +
>>>  static const char * const decon_clks_name[] = {
>>>   "pclk",
>>>   "aclk_decon",
>>> @@ -38,12 +42,6 @@ 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,
>>> @@ -61,7 +59,7 @@ struct decon_context {
>>>   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
>>>   int pipe;
>>>   unsigned long   flags;
>>> - enum decon_iftype   out_type;
>>> + unsigned intout_type;
>>>   int first_win;
>>>  };
>>>
>>> @@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc 
>>> *crtc)
>>>
>>>   if (!test_and_set_bit(BIT_IRQS_ENABLED, &ctx->flags)) {
>>>   val = VIDINTCON0_INTEN;
>>> - if (ctx->out_type == IFTYPE_I80)
>>> + if (ctx->out_type & IFTYPE_I80)
>>>   val |= VIDINTCON0_FRAMEDONE;
>>>   else
>>>   val |= VIDINTCON0_INTFRMEN;
>>> @@ -119,7 +117,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
>>> *crtc)
>>>
>>>  static void decon_setup_trigger(struct decon_context *ctx)
>>>  {
>>> - u32 val = (ctx->out_type != IFTYPE_HDMI)
>>> + u32 val = !(ctx->out_type & I80_HW_TRG)
>>>   ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>>> TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>>>   : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>>> @@ -136,7 +134,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>>   if (test_bit(BIT_SUSPENDED, &ctx->flags))
>>>   return;
>>>
>>> - if (ctx->out_type == IFTYPE_HDMI) {
>>> + if (ctx->out_type & IFTYPE_HDMI) {
>>>   m->crtc_hsync_start = m->crtc_hdis

[PATCH 3/3] drm/exynos: decon: clean up interface type

2016-04-05 Thread Inki Dae

 Hi Andrzej,

2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
> Hi Inki,
>
> On 04/05/2016 10:27 AM, Inki Dae wrote:
>> This patch cleans up interface type relevant codes.
>>
>> Trigger mode is determinded only by i80 mode, which isn't
>> related to Display types - HDMI or Display controller.
>> So this patch makes the trigger mode to be set only in case of
>> i80 mode.
>
> With this patch HDMI path image has serious synchronization problems.
> Exynos5433 documentation says that HDMI Timing Generator generates VSYNC
> signal which works as a hardware trigger for DECON-TV, so I guess
> trigger is required.

Right. One I missed. For DECON-TV, seems that HW trigger mode is mandatory.

>
> Btw, I think it could be good to remove suffixes I80_RGV from
> TRIGCON_HWTRIGEN_I80_RGB and TRIGCON_HWTRIGMASK_I80_RGB - they are
> misleading and differ from documentation.

Indeed. Looked strange when I wrote the suffixes.

>
> As far as I have tested I80 mode works OK on Decon5433.

Thanks for testing.
Inki Dae

>
> Regards
> Andrzej
>
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 53 
>> ++-
>>  1 file changed, 27 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> index 5245bc5..5922e99 100644
>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> @@ -28,6 +28,10 @@
>>  #define WINDOWS_NR   3
>>  #define MIN_FB_WIDTH_FOR_16WORD_BURST128
>>
>> +#define IFTYPE_I80   (1 << 0)
>> +#define I80_HW_TRG   (1 << 1)
>> +#define IFTYPE_HDMI  (1 << 2)
>> +
>>  static const char * const decon_clks_name[] = {
>>   "pclk",
>>   "aclk_decon",
>> @@ -38,12 +42,6 @@ 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,
>> @@ -61,7 +59,7 @@ struct decon_context {
>>   struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
>>   int pipe;
>>   unsigned long   flags;
>> - enum decon_iftype   out_type;
>> + unsigned intout_type;
>>   int first_win;
>>  };
>>
>> @@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc 
>> *crtc)
>>
>>   if (!test_and_set_bit(BIT_IRQS_ENABLED, &ctx->flags)) {
>>   val = VIDINTCON0_INTEN;
>> - if (ctx->out_type == IFTYPE_I80)
>> + if (ctx->out_type & IFTYPE_I80)
>>   val |= VIDINTCON0_FRAMEDONE;
>>   else
>>   val |= VIDINTCON0_INTFRMEN;
>> @@ -119,7 +117,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
>> *crtc)
>>
>>  static void decon_setup_trigger(struct decon_context *ctx)
>>  {
>> - u32 val = (ctx->out_type != IFTYPE_HDMI)
>> + u32 val = !(ctx->out_type & I80_HW_TRG)
>>   ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>> TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>>   : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
>> @@ -136,7 +134,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>   if (test_bit(BIT_SUSPENDED, &ctx->flags))
>>   return;
>>
>> - if (ctx->out_type == IFTYPE_HDMI) {
>> + 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;
>> @@ -151,17 +149,20 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>
>>   /* lcd on and use command if */
>>   val = VIDOUT_LCD_ON;
>> - if (ctx->out_type == IFTYPE_I80)
>> + if (ctx->out_type & IFTYPE_I80) {
>>   val |= VIDOUT_COMMAND_IF;
>> - else
>> + decon_setup_trigger(ctx);
>> + } else {
>>   val |= VIDOUT_RGB_IF;
>> + }
>> +
>>   writel(val, ctx->addr + DECON_VIDOUTCON0);
>>
>>   val = VIDTCON2_LINEVAL(m->

[PATCH 3/3] drm/exynos: decon: clean up interface type

2016-04-05 Thread Inki Dae

This patch cleans up interface type relevant codes.

Trigger mode is determinded only by i80 mode, which isn't
related to Display types - HDMI or Display controller.
So this patch makes the trigger mode to be set only in case of
i80 mode.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 53 ++-
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5245bc5..5922e99 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -28,6 +28,10 @@
 #define WINDOWS_NR 3
 #define MIN_FB_WIDTH_FOR_16WORD_BURST  128

+#define IFTYPE_I80 (1 << 0)
+#define I80_HW_TRG (1 << 1)
+#define IFTYPE_HDMI(1 << 2)
+
 static const char * const decon_clks_name[] = {
"pclk",
"aclk_decon",
@@ -38,12 +42,6 @@ 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,
@@ -61,7 +59,7 @@ struct decon_context {
struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
int pipe;
unsigned long   flags;
-   enum decon_iftype   out_type;
+   unsigned intout_type;
int first_win;
 };

@@ -95,7 +93,7 @@ static int decon_enable_vblank(struct exynos_drm_crtc *crtc)

if (!test_and_set_bit(BIT_IRQS_ENABLED, &ctx->flags)) {
val = VIDINTCON0_INTEN;
-   if (ctx->out_type == IFTYPE_I80)
+   if (ctx->out_type & IFTYPE_I80)
val |= VIDINTCON0_FRAMEDONE;
else
val |= VIDINTCON0_INTFRMEN;
@@ -119,7 +117,7 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
*crtc)

 static void decon_setup_trigger(struct decon_context *ctx)
 {
-   u32 val = (ctx->out_type != IFTYPE_HDMI)
+   u32 val = !(ctx->out_type & I80_HW_TRG)
? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
  TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
: TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
@@ -136,7 +134,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
if (test_bit(BIT_SUSPENDED, &ctx->flags))
return;

-   if (ctx->out_type == IFTYPE_HDMI) {
+   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;
@@ -151,17 +149,20 @@ static void decon_commit(struct exynos_drm_crtc *crtc)

/* lcd on and use command if */
val = VIDOUT_LCD_ON;
-   if (ctx->out_type == IFTYPE_I80)
+   if (ctx->out_type & IFTYPE_I80) {
val |= VIDOUT_COMMAND_IF;
-   else
+   decon_setup_trigger(ctx);
+   } else {
val |= VIDOUT_RGB_IF;
+   }
+
writel(val, ctx->addr + DECON_VIDOUTCON0);

val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);

-   if (ctx->out_type != IFTYPE_I80) {
+   if (!(ctx->out_type & IFTYPE_I80)) {
val = VIDTCON00_VBPD_F(
m->crtc_vtotal - m->crtc_vsync_end - 1) |
VIDTCON00_VFPD_F(
@@ -183,8 +184,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
writel(val, ctx->addr + DECON_VIDTCON11);
}

-   decon_setup_trigger(ctx);
-
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
 }
@@ -300,7 +299,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
val = dma_addr + pitch * state->src.h;
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));

-   if (ctx->out_type != IFTYPE_HDMI)
+   if (!(ctx->out_type & IFTYPE_HDMI))
val = BIT_VAL(pitch - state->crtc.w * bpp, 27, 14)
| BIT_VAL(state->crtc.w * bpp, 13, 0);
else
@@ -348,7 +347,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
for (i = ctx->first_win; i < WINDOWS_NR; i++)
decon_shadow_protect_win(ctx, i, false);

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

@@ -374,7 +373,7 @@ static void decon_swreset(struct decon_context *ctx)

WARN(tries == 0, &qu

[PATCH 2/3] drm/exynos: fimd: add HW trigger support

2016-04-05 Thread Inki Dae

This patch adds HW trigger support on i80 mode.

Until now, Exynos DRM only supported SW trigger which was set
SWTRGCMD bit of TRIGCON register by CPU to transfer scanout
buffer to Display bus device or panel.

With this patch, the transmission to Display bus device or
panel will be initiated by FIMD controller.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 47 
 1 file changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 752c6b0..c4cd16a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,11 @@
 #define TRIGCON0x1A4
 #define TRGMODE_I80_RGB_ENABLE_I80 (1 << 0)
 #define SWTRGCMD_I80_RGB_ENABLE(1 << 1)
+/* Exynos3250, 3472, 4415, 5260 5410, 5420 and 5422 only supported. */
+#define HWTRGEN_I80_RGB_ENABLE (1 << 3)
+#define HWTRGMASK_I80_RGB_ENABLE   (1 << 4)
+/* Exynos3250, 3472, 4415, 5260, 5420 and 5422 only supported. */
+#define HWTRIGEN_PER_RGB_ENABLE(1 << 31)

 /* display mode change control register except exynos4 */
 #define VIDOUT_CON 0x000
@@ -89,12 +94,16 @@
 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5

+/* HW trigger flag on i80 panel. */
+#define I80_HW_TRG (1 << 1)
+
 struct fimd_driver_data {
unsigned int timing_base;
unsigned int lcdblk_offset;
unsigned int lcdblk_vt_shift;
unsigned int lcdblk_bypass_shift;
unsigned int lcdblk_mic_bypass_shift;
+   unsigned int trg_type;

unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
@@ -102,6 +111,8 @@ struct fimd_driver_data {
unsigned int has_vidoutcon:1;
unsigned int has_vtsel:1;
unsigned int has_mic_bypass:1;
+   unsigned int has_hw_trigger:1;
+   unsigned int has_trigger_per_te:1;
 };

 static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -114,8 +125,10 @@ static struct fimd_driver_data exynos3_fimd_driver_data = {
.timing_base = 0x2,
.lcdblk_offset = 0x210,
.lcdblk_bypass_shift = 1,
+   .trg_type = I80_HW_TRG,
.has_shadowcon = 1,
.has_vidoutcon = 1,
+   .has_trigger_per_te = 1,
 };

 static struct fimd_driver_data exynos4_fimd_driver_data = {
@@ -132,9 +145,11 @@ static struct fimd_driver_data exynos4415_fimd_driver_data 
= {
.lcdblk_offset = 0x210,
.lcdblk_vt_shift = 10,
.lcdblk_bypass_shift = 1,
+   .trg_type = I80_HW_TRG,
.has_shadowcon = 1,
.has_vidoutcon = 1,
.has_vtsel = 1,
+   .has_trigger_per_te = 1,
 };

 static struct fimd_driver_data exynos5_fimd_driver_data = {
@@ -145,6 +160,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
.has_shadowcon = 1,
.has_vidoutcon = 1,
.has_vtsel = 1,
+   .has_hw_trigger = 1,
 };

 static struct fimd_driver_data exynos5420_fimd_driver_data = {
@@ -153,10 +169,13 @@ static struct fimd_driver_data 
exynos5420_fimd_driver_data = {
.lcdblk_vt_shift = 24,
.lcdblk_bypass_shift = 15,
.lcdblk_mic_bypass_shift = 11,
+   .trg_type = I80_HW_TRG,
.has_shadowcon = 1,
.has_vidoutcon = 1,
.has_vtsel = 1,
.has_mic_bypass = 1,
+   .has_hw_trigger = 1,
+   .has_trigger_per_te = 1,
 };

 struct fimd_context {
@@ -400,6 +419,27 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
return (clkdiv < 0x100) ? clkdiv : 0xff;
 }

+static void fimd_setup_trigger(struct fimd_context *ctx)
+{
+   void __iomem *timing_base = ctx->regs + ctx->driver_data->timing_base;
+   u32 trg_type = ctx->driver_data->trg_type;
+   u32 val = readl(timing_base + TRIGCON);
+
+   val &= ~(TRGMODE_I80_RGB_ENABLE_I80);
+
+   if (trg_type == I80_HW_TRG) {
+   if (ctx->driver_data->has_hw_trigger)
+   val |= HWTRGEN_I80_RGB_ENABLE |
+   HWTRGMASK_I80_RGB_ENABLE;
+   if (ctx->driver_data->has_trigger_per_te)
+   val |= HWTRIGEN_PER_RGB_ENABLE;
+   } else {
+   val |= TRGMODE_I80_RGB_ENABLE_I80;
+   }
+
+   writel(val, timing_base + TRIGCON);
+}
+
 static void fimd_commit(struct exynos_drm_crtc *crtc)
 {
struct fimd_context *ctx = crtc->ctx;
@@ -495,6 +535,8 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
   VIDTCON2_HOZVAL_E(mode->hdisplay - 1);
writel(val, ctx->regs + driver_data->timing_base + VIDTCON2);

+   fimd_setup_trigger(ctx);
+
/*
 * fields of register with prefix '_F' would be updated
 * at vsync(same as dma start)
@@ -856,11 +898,15 @@ static void fimd_trigger(struct device *dev)
 static void f

[PATCH 1/3] drm/exynos: clean up wait_for_vblank

2016-04-05 Thread Inki Dae

This patch cleans up wait_for_vblank relevant codes.
wait_for_vblank callback isn't used anymore in Exynos drm driver
so it removes relevant codes. However, display controllers -
FIMD and DECON - still use this function driver internally
to ensure shadow registers to be updated, which resolves
page fault issue so keep it.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  3 ---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  1 -
 drivers/gpu/drm/exynos/exynos_mixer.c  | 39 --
 4 files changed, 44 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 9336107..f6223f9 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -593,7 +593,6 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.commit = decon_commit,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
-   .wait_for_vblank = decon_wait_for_vblank,
.atomic_begin = decon_atomic_begin,
.update_plane = decon_update_plane,
.disable_plane = decon_disable_plane,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 502f750..bfe835a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -120,8 +120,6 @@ struct exynos_drm_plane_config {
  * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
- * @wait_for_vblank: wait for vblank interrupt to make sure that
- * hardware overlay is updated.
  * @atomic_check: validate state
  * @atomic_begin: prepare device to receive an update
  * @atomic_flush: mark the end of device update
@@ -141,7 +139,6 @@ struct exynos_drm_crtc_ops {
void (*commit)(struct exynos_drm_crtc *crtc);
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
-   void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
int (*atomic_check)(struct exynos_drm_crtc *crtc,
struct drm_crtc_state *state);
void (*atomic_begin)(struct exynos_drm_crtc *crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 51d484a..752c6b0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -902,7 +902,6 @@ static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
.commit = fimd_commit,
.enable_vblank = fimd_enable_vblank,
.disable_vblank = fimd_disable_vblank,
-   .wait_for_vblank = fimd_wait_for_vblank,
.atomic_begin = fimd_atomic_begin,
.update_plane = fimd_update_plane,
.disable_plane = fimd_disable_plane,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0a5a600..f272417 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -103,8 +103,6 @@ struct mixer_context {

struct mixer_resources  mixer_res;
enum mixer_version_id   mxr_ver;
-   wait_queue_head_t   wait_vsync_queue;
-   atomic_twait_vsync_event;
 };

 struct mixer_drv_data {
@@ -787,12 +785,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)

exynos_drm_crtc_finish_update(ctx->crtc, plane);
}
-
-   /* set wait vsync event to zero and wake up queue. */
-   if (atomic_read(&ctx->wait_vsync_event)) {
-   atomic_set(&ctx->wait_vsync_event, 0);
-   wake_up(&ctx->wait_vsync_queue);
-   }
}

 out:
@@ -1027,34 +1019,6 @@ static void mixer_atomic_flush(struct exynos_drm_crtc 
*crtc)
mixer_vsync_set_update(mixer_ctx, true);
 }

-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, &mixer_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");
-   return;
-   }
-
-   atomic_set(&mixer_ctx->wait_vsync_event, 1);
-
-   /*
-* wait for MIXER to signal VSYNC interrupt or return after
-* timeout which is set to 50ms (refresh rate of 20).
-*/
-   if (!wait_event_timeout(mixer_ctx->wait_vsync_queue,
-   !atomic_read(&mixer_ctx->wait_vsync_event),
-   HZ/20))
-   DR

[PATCH 0/3] drm/exynos: support HW trigger on i80 mode

2016-04-05 Thread Inki Dae

This patch series adds HW trigger on i80 mode, including one cleanup patch.

Until now, Exynos drm driver used SW trigger in case of i80 panel
and trigger mode setting of DECON HDMI was not reasonable because
the trigger mode is related to only i80 mode so also corrects it.

With this patch series, HW trigger mode will be used in default if
SoC suppots HW trigger - Exynos3250, 3472, 4415, 5260 5410, 5420 and 5422.

P.s. HW trigger support for Exynos 7 series will be added later.

Thanks,
Inki Dae

Inki Dae (3):
  drm/exynos: clean up wait_for_vblank
  drm/exynos: fimd: add HW trigger support
  drm/exynos: decon: clean up interface type

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 53 ++-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  3 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 48 +++-
 drivers/gpu/drm/exynos/exynos_mixer.c | 39 
 5 files changed, 74 insertions(+), 70 deletions(-)

-- 
1.9.1

[RFC 0/6] drm/fences: add in-fences to DRM

2016-04-04 Thread Inki Dae


2016ë 03ì 31ì¼ 23:10ì Rob Clark ì´(ê°) ì´ ê¸:
> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae  wrote:
>> Hi Daniel,
>>
>> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>>> Hi Inki,
>>>
>>> On 31 March 2016 at 11:05, Inki Dae  wrote:
>>>> 2016ë 03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
>>>>> On 31 March 2016 at 08:45, Inki Dae  wrote:
>>>>>> As of now, it seems that this wouldn't be optional but mandatory if 
>>>>>> explicit fence support is added to the atomic helper framework. This 
>>>>>> would definitely be duplication and it seems not clear enough even if 
>>>>>> one of them is just skipped in runtime.
>>>>>
>>>>> Drivers would have to opt in to explicit fencing support, and part of
>>>>> that would be ensuring that the driver does not wait on implicit
>>>>> fences when the user has requested explicit fencing be used.
>>>>>
>>>>
>>>> Then, existing drivers would need additional works for explicit fencing 
>>>> support. This wouldn't be really what the drivers have to but should be 
>>>> handled with this patch series because this would affect exising device 
>>>> drivers which use implicit fencing.
>>>
>>> Well, yes. Anyone implementing their own atomic commit would need to
>>> ensure that the commit works properly for fences. The helpers could
>>> also add it, but the helpers are not mandatory, and you are not
>>> required to use every part of the helper to use one part of the
>>> helper. There is no magic wand you can wave that instantly makes it
>>> work for every driver
>>
>> I meant there are already several DRM drivers which work properly for
>> implicit fence. So if atomic helper framework of DRM core is
>> considered only for the explicit fence, then fencing operation would
>> affect the existing DRM drivers. So I hope this trying could consider
>> existing implicit fence users.
>>
> 
> Note that there would be a new flag on the atomic ioctl to request

What is the new flag? And Where I could find the new flag?

> explicit fencing, and with an old kernel or a driver that does not
> support it, the ioctl would be rejected and an error returned.  The
> atomic/kms framework would of course continue to support implicit

I couldn't find where such exceptions are considered.
And as of now, I think implicit fence is implemented by drivers so hided from 
drm core framework. So how atomic/kms framework knows whether explicit or 
implicit fence is supported by driver?
Otherwise, you mean such things are TODO in the future?

There may be some logic I don't understand yet.

Thanks,
Inki Dae

> fencing.   And an explicit-fencing userspace would require a
> sufficiently new kernel and possibly some minor driver support (above
> and beyond 'struct fence' conversion).
> 
> BR,
> -R
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-31 Thread Inki Dae

2016-03-31 19:04 GMT+09:00 Daniel Vetter :
> On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
>> Well, it has to be one or the other: mixing explicit and implicit,
>> defeats the purpose of using explicit fencing. So, when explicit
>> fencing is in use, implicit fences must be ignored.
>
> You can mix it, if you're careful. CrOS wants that to better mesh android
> with Ozone, and we'll be discussing what needs to be added to be able to
> make it work implicit and explicit fencing work together, in both
> directions. Of course this should only be used for shared buffers, e.g.
> explicit syncing in an android client running on top of implicitly synced
> ozone/kms.

Good idea. I hope fence things of mainline would be more discussed so
could be considered for many cases.

Thanks,
Inki Dae

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-31 Thread Inki Dae

Hi Daniel,

2016-03-31 19:56 GMT+09:00 Daniel Stone :
> Hi Inki,
>
> On 31 March 2016 at 11:05, Inki Dae  wrote:
>> 2016ë 03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> On 31 March 2016 at 08:45, Inki Dae  wrote:
>>>> As of now, it seems that this wouldn't be optional but mandatory if 
>>>> explicit fence support is added to the atomic helper framework. This would 
>>>> definitely be duplication and it seems not clear enough even if one of 
>>>> them is just skipped in runtime.
>>>
>>> Drivers would have to opt in to explicit fencing support, and part of
>>> that would be ensuring that the driver does not wait on implicit
>>> fences when the user has requested explicit fencing be used.
>>>
>>
>> Then, existing drivers would need additional works for explicit fencing 
>> support. This wouldn't be really what the drivers have to but should be 
>> handled with this patch series because this would affect exising device 
>> drivers which use implicit fencing.
>
> Well, yes. Anyone implementing their own atomic commit would need to
> ensure that the commit works properly for fences. The helpers could
> also add it, but the helpers are not mandatory, and you are not
> required to use every part of the helper to use one part of the
> helper. There is no magic wand you can wave that instantly makes it
> work for every driver

I meant there are already several DRM drivers which work properly for
implicit fence. So if atomic helper framework of DRM core is
considered only for the explicit fence, then fencing operation would
affect the existing DRM drivers. So I hope this trying could consider
existing implicit fence users.

Thanks,
Inki Dae
. 
>
> Cheers,
> Daniel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-31 Thread Inki Dae

Hi Daniel,

2016ë 03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
> 
> On 31 March 2016 at 08:45, Inki Dae  wrote:
>> 2016ë 03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
>>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
>>>> In addition, I wonder how explicit and implicit fences could coexist 
>>>> together.
>>>> Rob said,
>>>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>>>> explicit sync instead"
>>>>
>>>> This would mean that if we use explicit sync for user-space then it 
>>>> coexists with implicit sync. However, these two sync fences can't see same 
>>>> DMA buffer because explicit fence has a different file object from 
>>>> implicit one.
>>>> So in this case, I think explicit fence would need to be hung up on the 
>>>> reservation object of dmabuf object somehow. Otherwise, although they 
>>>> coexist together, are these fences - explicit and implicit - used for 
>>>> differenct purpose separately?
>>>>
>>>
>>> I'm not entirely sure about coexistance at the same time.  It ofc
>>> shouldn't be a problem for one kernel to support both kinds of
>>> userspace (pure explicit and pure implicit).  And how this would work
>>> on kms atomic ioctl (compositor/consumer) side seems clear enough..
>>> ie. some sort of flag, which if set user provides an explicit fence
>>> fd, and if not set we fall back to current behaviour (ie. get fences
>>> from resv object).
>>
>> With this patch series, users can register explicit fence(s) to atomic 
>> kms(consumer side) through kms property interface for the explicit sync.
>>
>> However, now several DRM drivers(also consumer) already have beeen using 
>> implicit fence. So while GPU(producer side) is accessing DMA buffer after 
>> registering its explicit fence to atomic kms, and if atomic commit is 
>> requested by user-space, then atomic helper framework will try to 
>> synchronize with the producer - waiting for the signal of GPU 
>> side(producer), and device specific page flip function will also try to do 
>> same thing.
> 
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.
> 
>> As of now, it seems that this wouldn't be optional but mandatory if explicit 
>> fence support is added to the atomic helper framework. This would definitely 
>> be duplication and it seems not clear enough even if one of them is just 
>> skipped in runtime.
> 
> Drivers would have to opt in to explicit fencing support, and part of
> that would be ensuring that the driver does not wait on implicit
> fences when the user has requested explicit fencing be used.
> 

Then, existing drivers would need additional works for explicit fencing 
support. This wouldn't be really what the drivers have to but should be handled 
with this patch series because this would affect exising device drivers which 
use implicit fencing.


Thanks,
Inki Dae

> Cheers,
> Daniel
> 
>

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-31 Thread Inki Dae

2016ë 03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
>>
>> In addition, I wonder how explicit and implicit fences could coexist 
>> together.
>> Rob said,
>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>> explicit sync instead"
>>
>> This would mean that if we use explicit sync for user-space then it coexists 
>> with implicit sync. However, these two sync fences can't see same DMA buffer 
>> because explicit fence has a different file object from implicit one.
>> So in this case, I think explicit fence would need to be hung up on the 
>> reservation object of dmabuf object somehow. Otherwise, although they 
>> coexist together, are these fences - explicit and implicit - used for 
>> differenct purpose separately?
>>
> 
> I'm not entirely sure about coexistance at the same time.  It ofc
> shouldn't be a problem for one kernel to support both kinds of
> userspace (pure explicit and pure implicit).  And how this would work
> on kms atomic ioctl (compositor/consumer) side seems clear enough..
> ie. some sort of flag, which if set user provides an explicit fence
> fd, and if not set we fall back to current behaviour (ie. get fences
> from resv object).

With this patch series, users can register explicit fence(s) to atomic 
kms(consumer side) through kms property interface for the explicit sync.

However, now several DRM drivers(also consumer) already have beeen using 
implicit fence. So while GPU(producer side) is accessing DMA buffer after 
registering its explicit fence to atomic kms, and if atomic commit is requested 
by user-space, then atomic helper framework will try to synchronize with the 
producer - waiting for the signal of GPU side(producer), and device specific 
page flip function will also try to do same thing.

As of now, it seems that this wouldn't be optional but mandatory if explicit 
fence support is added to the atomic helper framework. This would definitely be 
duplication and it seems not clear enough even if one of them is just skipped 
in runtime.

> 
> On the gpu/producer side, I think what makes sense is to both attach
> the fence to the resv objects and (optionally, specified by an submit
> ioctl flag) return a fence fd.  The other option is to add a new ioctl
> to convert an internal per-ring fence/seqno (that is already returned
> by submit ioctl) to a fence fd.. but I think that would end up with
> duplicate 'struct fence' objects on the kernel side (not sure if that

I think the problem is not that kernel just keeps duplicate fence objects 
separately but is that these fences can be performed separately for same 
purpose.

> would cause issues somehow), and might be unneeded since with
> EGL_ANDROID_native_fence_sync since we should know before glFlush() is
> called whether we want an fd or not.  But main thing I'm pondering

So I think this is not user-space issue. All users don't have to know whether 
DMA drivers support implicit fence or not so as soon as user uses explicit 
fence, the duplication would happen.

There may be something I missed so your comment would be helpful in 
understanding it.

Thanks,
Inki Dae

> here is how to sanely support the old way of userspace gl driver
> internal synchronization with new userspace on old kernel, but also
> conditionally support EGL_ANDROID_native_fence_sync if you have a new
> enough kernel.
> 
> BR,
> -R
> 
>

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-29 Thread Inki Dae

Hi Daniel,

2016ë 03ì 28ì¼ 22:26ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
> 
> On 28 March 2016 at 02:26, Inki Dae  wrote:
>> 2016ë 03ì 25ì¼ 21:10ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> Second, really. Vulkan avoids implicit sync entirely, and exposes
>>> fence-like primitives throughout its whole API. These include being
>>> able to pass prerequisite fences for display (what Gustavo is adding
>>> here: something to block on before display), and also when the user
>>> acquires a buffer as a render target, it is given another prerequisite
>>> fence (the other side of what Gustavo is suggesting, i.e. the fence
>>> triggers when the buffer is no longer displayed and becomes available
>>> for rendering).
>>>
>>> In order to implement this correctly, and avoid performance bubbles,
>>> we need a primitive like this exposed through the KMS API, from both
>>> sides. This is especially important when you take the case of
>>> userspace suballocation, where userspace allocates larger blocks and
>>> divides the allocation internally for different uses. Implicit sync
>>> does not work at all for that case.
>>
>> Can you give me more details why implicit sync cannot take care of the case 
>> of userspace suballocation?
> 
> Implicit sync does not know about suballocation, so implicit will
> operate for every range in the buffer, not just the one you want.
> 
> Say you have one kernel buffer, which userspace subdivides into four
> independent buffers. It can perform operations on these buffers which
> are completely independent of each other, and an explicit sync model
> allows this independence to be kept. Implicit sync ties them together,
> so that you cannot do any operations on buffer 1 until all operations
> on buffer 2 have completed.
> 
>> And is there any reason that fence fd shouldn't dependent of DMABUF - now 
>> fence fd is a new file, not DMABUF fd?
> 
> Because dmabuf is for buffer sharing, and fences aren't buffers (they
> will never export page ranges). Is there any particular benefit you
> think you would get from doing this?

Just for consistency. As you know, implicit sync hangs DMA fence up on dmabuf 
object through reservation object so dmabuf independent explicit sync looked 
strange to me.
As you mentioned above, the suballocation would be why explicit sync should be 
indepenent of DMABUF.

In addition, I wonder how explicit and implicit fences could coexist together.
Rob said,
"Implicit sync ofc remains the default, but userspace could opt-in to explicit 
sync instead"

This would mean that if we use explicit sync for user-space then it coexists 
with implicit sync. However, these two sync fences can't see same DMA buffer 
because explicit fence has a different file object from implicit one.
So in this case, I think explicit fence would need to be hung up on the 
reservation object of dmabuf object somehow. Otherwise, although they coexist 
together, are these fences - explicit and implicit - used for differenct 
purpose separately? 

Thanks,
Inki Dae

> 
>>> good thing. This is also the model that ChromeOS is moving towards, so
>>> it becomes more important from that point of view as well.
>>
>> I think Gustavo should had explaned this path series enough to other people 
>> when posting them - ie, what relationship explict and implicit fences have, 
>> and why implicit fence - which is independent of DMABUF - is required, and 
>> what use cases there are in real users, and etc.
> 
> Fair enough, the summary could perhaps contain something like this.
> 
> Cheers,
> Daniel
> 
>

[PATCH 0/3] drm/exynos: Kconfig dependency fixes

2016-03-29 Thread Inki Dae

Hi Javier,

Thanks for your patch set.

Will merge them if there is no issue.

Thanks,
Inki Dae

2016ë 03ì 29ì¼ 10:28ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
> Hello Inki,
> 
> This patch series contains some fixes for the Kconfig symbol dependencies
> of the Exynos DRM driver. They make sure that the Exynos DRM components
> and the media platform drivers that makes use of the same HW IP block are
> not enabled at the same time.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (3):
>   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
>   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
>   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n
> 
>  drivers/gpu/drm/exynos/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-28 Thread Inki Dae

Hi Rob and Daniel,

2016ë 03ì 25ì¼ 21:10ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi all,
> 
> On 25 March 2016 at 11:58, Rob Clark  wrote:
>> On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae  wrote:
>>> It's definitely different case. This tries to add new user-space interfaces 
>>> to expose fences to user-space. At least, implicit interfaces are embedded 
>>> into drivers.
>>> So I'd like to give you a question. Why exposing fences to user-space is 
>>> required? To provide easy-to-debug solution to rendering pipleline? To 
>>> provide merge fence feature?
>>
>> Well, implicit sync and explicit sync are two different cases.
>> Implicit sync ofc remains the default, but userspace could opt-in to
>> explicit sync instead.  For example, on the gpu side of things,
>> depending on flags userspace passes in to the submit ioctl we would
>> either attach the fence to all the written buffers (implicit) or
>> return it as a fence fd to userspace (explicit), which userspace could
>> then pass in to atomic ioctl to synchronize pageflip.
>>
>> And visa-versa, we can pass the pageflip (atomic) completion fence
>> back in to gpu so it doesn't start rendering the next frame until the
>> buffer is off screen.
>>
>> fwiw, currently android is the first user of explicit sync (although I
>> expect wayland/weston to follow suit).
> 
> Second, really. Vulkan avoids implicit sync entirely, and exposes
> fence-like primitives throughout its whole API. These include being
> able to pass prerequisite fences for display (what Gustavo is adding
> here: something to block on before display), and also when the user
> acquires a buffer as a render target, it is given another prerequisite
> fence (the other side of what Gustavo is suggesting, i.e. the fence
> triggers when the buffer is no longer displayed and becomes available
> for rendering).
> 
> In order to implement this correctly, and avoid performance bubbles,
> we need a primitive like this exposed through the KMS API, from both
> sides. This is especially important when you take the case of
> userspace suballocation, where userspace allocates larger blocks and
> divides the allocation internally for different uses. Implicit sync
> does not work at all for that case.

Can you give me more details why implicit sync cannot take care of the case of 
userspace suballocation?
And is there any reason that fence fd shouldn't dependent of DMABUF - now fence 
fd is a new file, not DMABUF fd?

> 
> As stated before, there are other benefits, including much better
> traceability. I would expect Wayland/Weston to also start pushing
> support for this API relatively soon.
> 
>> A couple linaro folks have
>> android running with an upstream kernel + mesa + atomic/kms hwc on a
>> couple devices (nexus7 and db410c with freedreno, and qemu with
>> virgl).  But there are some limitations due to missing the
>> EGL_ANDROID_native_fence_sync extension in mesa.  I plan to implement
>> that, but I ofc need the fence fd stuff in order to do so ;-)
> 
> Yes, having that would be a godsend for a lot of people.
> 
>>> And if we need really to expose fences to user-space and there is really 
>>> real user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or 
>>> maybe fcntl system call because we share already DMA buffer between CPU <-> 
>>> DMA and DMA <-> DMA using DMABUF.
>>> For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long 
>>> time ago because you was there. Several years ago, I tried to couple 
>>> exposing the fences to user-space with cache operation although at that 
>>> time, I really misleaded the fence machnism. My trying was also for the 
>>> potential users.
>>
>> Note that this is not (just) about sw sync, but also sync between
>> multiple hw devices.
> 
> Sync isn't quite good enough, because it's a mandatory blocking point
> for userspace. We want to push the explicit fences further down the
> line, so userspace can parallelise its work.
> 
> Even if none of the above requirements held true, I don't think being
> able to support Android is a bad thing. It's completely right to be
> worried about pushing in Android work and APIs for the sake of it -
> hence why we didn't take ADF! - but in this case it's definitely a

As least Google's ADF boosted up atomic KMS. :) 

> good thing. This is also the model that ChromeOS is moving towards, so
> it becomes more important from that point of view as well.

I think Gustavo should had explaned this path series enough to other people 
when posting them - ie, what relationship explict and implicit fences have, and 
why implicit fence - which is independent of DMABUF - is required, and what use 
cases there are in real users, and etc.


Thanks,
Inki Dae

> 
> Cheers,
> Daniel
> 
>

[patch 2/2] drm/exynos: mic: remove some dead code

2016-03-25 Thread Inki Dae

Hi Dan,

2016ë 03ì 17ì¼ 19:39ì Dan Carpenter ì´(ê°) ì´ ê¸:
> We know "ret" is zero and the test makes static checkers complain so
> let's delete this printk.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 890c9b1..12db353 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -130,8 +130,6 @@ static void mic_set_path(struct exynos_mic *mic, bool 
> enable)
>   val &= ~(MIC0_RGB_MUX | MIC0_I80_MUX | MIC0_ON_MUX);
>  
>   regmap_write(mic->sysreg, DSD_CFG_MUX, val);
> - if (ret)
> - DRM_ERROR("mic: Failed to read system register\n");

I think we missed to keep return value from regmap_write function,
ret = regmap_write(mic->sysreg, );
if (ret)
...

Thanks,
Inki Dae

>  }
>  
>  static int mic_sw_reset(struct exynos_mic *mic)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-25 Thread Inki Dae

2016ë 03ì 25ì¼ 00:40ì Rob Clark ì´(ê°) ì´ ê¸:
> On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae  wrote:
>> Hi,
>>
>> 2016ë 03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
>>> From: Gustavo Padovan 
>>>
>>> Hi,
>>>
>>> This is a first proposal to discuss the addition of in-fences support
>>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>>> in DRM drivers. The new struct fence_collection contains a array with all
>>> fences that a atomic commit needs to wait on
>>
>> As I mentioned already like below,
>> http://www.spinics.net/lists/dri-devel/msg103225.html
>>
>> I don't see why Android specific thing is tried to propagate to Linux DRM. 
>> In Linux mainline, it has already implicit sync interfaces for DMA devices 
>> called dma fence which forces registering a fence obejct to DMABUF through a 
>> reservation obejct when a dmabuf object is created. However, Android sync 
>> driver creates a new file for a sync object and this would have different 
>> point of view.
>>
>> Is there anyone who can explan why Android specific thing is tried to spread 
>> into Linux DRM? Was there any consensus to use Android sync driver - which 
>> uses explicit sync interfaces - as Linux standard?
>>
> 
> btw, there is already plane_state->fence .. which I don't think has
> any users yet, but I start to use it in my patchset that converts
> drm/msm to 'struct fence'

Yes, Exynos also started it.

> 
> That said, we do need syncpt as the way to expose fences to userspace
> for explicit synchronization, but I'm not entirely sure that the

It's definitely different case. This tries to add new user-space interfaces to 
expose fences to user-space. At least, implicit interfaces are embedded into 
drivers.
So I'd like to give you a question. Why exposing fences to user-space is 
required? To provide easy-to-debug solution to rendering pipleline? To provide 
merge fence feature? 

And if we need really to expose fences to user-space and there is really real 
user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or maybe fcntl 
system call because we share already DMA buffer between CPU <-> DMA and DMA <-> 
DMA using DMABUF.
For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long time 
ago because you was there. Several years ago, I tried to couple exposing the 
fences to user-space with cache operation although at that time, I really 
misleaded the fence machnism. My trying was also for the potential users.

Anyway, my opinion is that we could expose the fences hided by DMABUF to 
user-space using interfaces it exists already around us. And for this, below 
Chromium solution would also give us some helps,
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.18/drivers/gpu/drm/drm_sync_helper.c

And in /driver/dma-buf/, there are DMABUF-centric modules so looks strange 
sync_file module of Android is placed in that directory - Android sync driver 
doesn't use really DMABUF but creates new file for their sync fence instead. 
For implicit sync interfaces for DMA devices, we use DMABUF and for explict 
sync interfaces for user-space, we use sync_file not DMABUF? That doesn't make 
sense. 

I love really Android but I feel as if we try to give a seat available to 
Android somehow.

Thanks,
Inki Dae

> various drivers ever need to see that (vs just struct fence), at least
> on the kms side of things.
> 
> BR,
> -R
> 
> 
>> Thanks,
>> Inki Dae
>>
>>>
>>> /**
>>>  * struct fence_collection - aggregate fences together
>>>  * @num_fences: number of fence in the collection.
>>>  * @user_data: user data.
>>>  * @func: user callback to put user data.
>>>  * @fences: array of @num_fences fences.
>>>  */
>>> struct fence_collection {
>>>int num_fences;
>>>void *user_data;
>>>collection_put_func_t func;
>>>struct fence *fences[];
>>> };
>>>
>>>
>>> The fence_collection is allocated and filled by sync_file_fences_get() and
>>> atomic_commit helpers can use fence_collection_wait() to wait the fences to
>>> signal.
>>>
>>> These patches depends on the sync ABI rework:
>>>
>>> https://www.spinics.net/lists/dri-devel/msg102795.html
>>>
>>> and the patch to de-stage the sync framework:
>>>
>>> https://www.spinics.net/lists/dri-devel/msg102799.html
>>>
>>>
>>> I also hacked together some sync support into modetest for testing

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-25 Thread Inki Dae

Hi Guestavo,

2016ë 03ì 24ì¼ 23:39ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> Hi Inki,
> 
> 2016-03-24 Inki Dae :
> 
>> Hi,
>>
>> 2016ë 03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
>>> From: Gustavo Padovan 
>>>
>>> Hi,
>>>
>>> This is a first proposal to discuss the addition of in-fences support
>>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>>> in DRM drivers. The new struct fence_collection contains a array with all
>>> fences that a atomic commit needs to wait on
>>
>> As I mentioned already like below,
>> http://www.spinics.net/lists/dri-devel/msg103225.html
>>
>> I don't see why Android specific thing is tried to propagate to Linux DRM. 
>> In Linux mainline, it has already implicit sync interfaces for DMA devices 
>> called dma fence which forces registering a fence obejct to DMABUF through a 
>> reservation obejct when a dmabuf object is created. However, Android sync 
>> driver creates a new file for a sync object and this would have different 
>> point of view.
>>
>> Is there anyone who can explan why Android specific thing is tried to spread 
>> into Linux DRM? Was there any consensus to use Android sync driver - which 
>> uses explicit sync interfaces - as Linux standard?
> 
> Because we want explicit fencing as the Linux standard in the future to
> be able to do smart scheduling, e.g., send async jobs to the gpu and at
> the same time send async atomic commits with sync_file fd attached so
> they can wait the GPU to finish and we don't block in userspace anymore,
> quite similar to what Android does.

GPU is also DMA device so I think the synchonization should be handled 
transparent to user-space.
And I know that Chromium guy already did similar thing with non-atomic commit 
only using implicit sync,
https://chromium.googlesource.com/chromiumos/third_party/kernel
branch name : chromeos-3.14

Of course, this approach uses a new helper framework placed in drm directory so 
I think if this framework can be moved into dma-buf directory after some 
cleanup and refactoring them if necessary.
Anyway, I'm not sure I understood the smart scheduling you mentioned but I 
think we could do what you try to do without the explicit fence.

> 
> This would still use dma-buf fences in the driver level, but it has a
> lot more advantages than implicit fencing.

You means things for rendering pipeline debugging and merging sync fences?

Thanks,
Inki Dae

> 
>   Gustavo
> 
>

[RFC 0/6] drm/fences: add in-fences to DRM

2016-03-24 Thread Inki Dae

Hi,

2016ë 03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan 
> 
> Hi,
> 
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collection contains a array with all
> fences that a atomic commit needs to wait on

As I mentioned already like below,
http://www.spinics.net/lists/dri-devel/msg103225.html

I don't see why Android specific thing is tried to propagate to Linux DRM. In 
Linux mainline, it has already implicit sync interfaces for DMA devices called 
dma fence which forces registering a fence obejct to DMABUF through a 
reservation obejct when a dmabuf object is created. However, Android sync 
driver creates a new file for a sync object and this would have different point 
of view.

Is there anyone who can explan why Android specific thing is tried to spread 
into Linux DRM? Was there any consensus to use Android sync driver - which uses 
explicit sync interfaces - as Linux standard?

Thanks,
Inki Dae

> 
> /**
>  * struct fence_collection - aggregate fences together
>  * @num_fences: number of fence in the collection.
>  * @user_data: user data.
>  * @func: user callback to put user data.
>  * @fences: array of @num_fences fences.
>  */
> struct fence_collection {
>int num_fences;
>void *user_data;
>collection_put_func_t func;
>struct fence *fences[];
> };
> 
> 
> The fence_collection is allocated and filled by sync_file_fences_get() and
> atomic_commit helpers can use fence_collection_wait() to wait the fences to
> signal.
> 
> These patches depends on the sync ABI rework:
> 
> https://www.spinics.net/lists/dri-devel/msg102795.html
> 
> and the patch to de-stage the sync framework:
> 
> https://www.spinics.net/lists/dri-devel/msg102799.html
> 
> 
> I also hacked together some sync support into modetest for testing:
> 
> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
> 
> 
>   Gustavo
> 
> 
> Gustavo Padovan (6):
>   drm/fence: add FENCE_FD property to planes
>   dma-buf/fence: add struct fence_collection
>   dma-buf/sync_file: add sync_file_fences_get()
>   dma-buf/fence: add fence_collection_put()
>   dma-buf/fence: add fence_collection_wait()
>   drm/fence: support fence_collection on atomic commit
> 
>  drivers/dma-buf/fence.c | 33 +
>  drivers/dma-buf/sync_file.c | 36 
>  drivers/gpu/drm/drm_atomic.c| 13 +
>  drivers/gpu/drm/drm_atomic_helper.c | 10 ++
>  drivers/gpu/drm/drm_crtc.c  |  7 +++
>  include/drm/drm_crtc.h  |  5 -
>  include/linux/fence.h   | 19 +++
>  include/linux/sync_file.h   |  8 
>  8 files changed, 126 insertions(+), 5 deletions(-)
>

[RFC 1/6] drm/fence: add FENCE_FD property to planes

2016-03-24 Thread Inki Dae

Hi,

2016ë 03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan 
> 
> FENCE_FD can now be set by the user during an atomic IOCTL, it
> will be used by atomic_commit to wait until the sync_file is signalled,
> i.e., the framebuffer is ready for scanout.

It seems that this patch makes Linux DRM to be dependent of Android which uses 
explicit sync interfaces.
So was there any a consensus that Android sync driver is used for DMA buffer 
synchronization as a Linux standard?

I see the Android sync driver exists in staging yet. Isn't the implicit sync 
interface used for DMA device as a Linux standard?
I don't see why Android specific things are spreaded into Linux DRM.

Thanks,
Inki Dae

> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/drm_atomic.c| 4 
>  drivers/gpu/drm/drm_atomic_helper.c | 1 +
>  drivers/gpu/drm/drm_crtc.c  | 7 +++
>  include/drm/drm_crtc.h  | 3 +++
>  4 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8fb469c..8bc364c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -609,6 +609,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   drm_atomic_set_fb_for_plane(state, fb);
>   if (fb)
>   drm_framebuffer_unreference(fb);
> + } else if (property == config->prop_fence_fd) {
> + state->fence_fd = val;
>   } else if (property == config->prop_crtc_id) {
>   struct drm_crtc *crtc = drm_crtc_find(dev, val);
>   return drm_atomic_set_crtc_for_plane(state, crtc);
> @@ -666,6 +668,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>  
>   if (property == config->prop_fb_id) {
>   *val = (state->fb) ? state->fb->base.id : 0;
> + } else if (property == config->prop_fence_fd) {
> + *val = state->fence_fd;
>   } else if (property == config->prop_crtc_id) {
>   *val = (state->crtc) ? state->crtc->base.id : 0;
>   } else if (property == config->prop_crtc_x) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2b430b0..4f91f84 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2594,6 +2594,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
> *plane)
>   if (plane->state) {
>   plane->state->plane = plane;
>   plane->state->rotation = BIT(DRM_ROTATE_0);
> + plane->state->fence_fd = -1;
>   }
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 65258ac..165f199 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1291,6 +1291,7 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>  
>   if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>   drm_object_attach_property(&plane->base, config->prop_fb_id, 0);
> + drm_object_attach_property(&plane->base, config->prop_fence_fd, 
> -1);
>   drm_object_attach_property(&plane->base, config->prop_crtc_id, 
> 0);
>   drm_object_attach_property(&plane->base, config->prop_crtc_x, 
> 0);
>   drm_object_attach_property(&plane->base, config->prop_crtc_y, 
> 0);
> @@ -1546,6 +1547,12 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.prop_fb_id = prop;
>  
> + prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
> + "FENCE_FD", -1, INT_MAX);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_fence_fd = prop;
> +
>   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
>   "CRTC_ID", DRM_MODE_OBJECT_CRTC);
>   if (!prop)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8c7fb3d..a8f6ec0 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1239,6 +1239,7 @@ struct drm_connector {
>   * @crtc: currently bound CRTC, NULL if disabled
>   * @fb: currently bound framebuffer
>   * @fence: optional fence to wait for before scanning out @fb
> + * @fence_fd: fd representing the sync_fence
>   * @crtc_x: left position of visible portion of plane on crtc
>   * @crtc_y: upper position of visible portion of plane on crtc
>   * @crtc_w: width of visible portion

[PATCH 0/7] drm/exynos: HDMI and DECON fixes and enhancements

2016-03-24 Thread Inki Dae



2016ë 03ì 24ì¼ 10:07ì Inki Dae ì´(ê°) ì´ ê¸:
> Hi Andrzej,
> 
> 2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> Hi Inki,
>>
>> This set of patches provides set of different fixes and enhancements
>> for DECON -> HDMI path. It is based on:
>> - my HDMI patches which are not yet merged[1], could you look at them
>>   by the way, they were posted about 5 months ago :)
> 
> Oops, really sorry. Will have a review ASAP.

I had already a review for this patch series and merged them to 
exynos-drm-next-todo branch,
http://www.spinics.net/lists/dri-devel/msg98354.html

But I forgot to have a test. :)

Thanks,
Inki Dae

> 
> Thanks,
> Inki Dae
> 
>> - IOMMU patches by Marek (for some mysterious reason HDMI path on 5433
>>   works only with IOMMU enabled),
>> - latest exynos-drm-next patches.
>>
>> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/140109
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (7):
>>   drm/exynos/hdmi: fix PHY configuration sequence
>>   drm/exynos/hdmi: add PHY power off signal handling
>>   drm/exynos/hdmi: add core reset code
>>   drm/exynos/hdmi: remove registry dump
>>   drm/exynos/decon5433: fix DECON standalone update
>>   drm/exynos/decon5433: reset decon on start
>>   drm/exynos/decon5433: do not protect window in plane disable
>>
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  22 +-
>>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 293 
>> ++
>>  2 files changed, 29 insertions(+), 286 deletions(-)
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 0/7] drm/exynos: HDMI and DECON fixes and enhancements

2016-03-24 Thread Inki Dae

Hi Andrzej,

2016ë 03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi Inki,
> 
> This set of patches provides set of different fixes and enhancements
> for DECON -> HDMI path. It is based on:
> - my HDMI patches which are not yet merged[1], could you look at them
>   by the way, they were posted about 5 months ago :)

Oops, really sorry. Will have a review ASAP.

Thanks,
Inki Dae

> - IOMMU patches by Marek (for some mysterious reason HDMI path on 5433
>   works only with IOMMU enabled),
> - latest exynos-drm-next patches.
> 
> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/140109
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (7):
>   drm/exynos/hdmi: fix PHY configuration sequence
>   drm/exynos/hdmi: add PHY power off signal handling
>   drm/exynos/hdmi: add core reset code
>   drm/exynos/hdmi: remove registry dump
>   drm/exynos/decon5433: fix DECON standalone update
>   drm/exynos/decon5433: reset decon on start
>   drm/exynos/decon5433: do not protect window in plane disable
> 
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  22 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 293 
> ++
>  2 files changed, 29 insertions(+), 286 deletions(-)
>

Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-23 Thread Inki Dae

2016ë 03ì 23ì¼ 08:39ì Russell King - ARM Linux ì´(ê°) ì´ ê¸:
> On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
>> In this case, someone else may send an email again like you "who is going to 
>> merge?"
>> That would be why we need a maintainer.
>>
>> drm panel is already managed well by Thierry Reding without such confusion. 
> 
> You don't need a maintainer for every subdirectory just because it's
> a subdirectory...
> 
> Sometimes, having too many maintainers adds beaurocracy which becomes

Yes, but... if there is no someone who is responsible for maintainership, then 
we would receive such emails like Heiko sent "who is going to merge" 
I don't also want adding many maintainers unnecessary but drm bridge - although 
the framework is a thin and small - is used *over the ARM SoC* so that many 
confusions may happen for upstream.

So although it's small framework or just subdirectory, we would need someone 
who can manage the framework to avoid further confusion if necessary.

Thanks,
Inki Dae

> counter-productive.  dw_hdmi seems to be adequately managed so far
> without there needing to be a "DRM bridge maintainer".
>

Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-23 Thread Inki Dae



2016ë 03ì 23ì¼ 07:52ì Heiko StÃ¼bner ì´(ê°) ì´ ê¸:
> Am Mittwoch, 23. MÃ¤rz 2016, 07:44:59 schrieb Inki Dae:
>> + Ajay kumar with Samsung email
>>
>> Hi,
>>
>> 2016ë 03ì 23ì¼ 07:12ì Heiko StÃ¼bner ì´(ê°) ì´ ê¸:
>>> Hi,
>>>
>>> Am Dienstag, 22. MÃ¤rz 2016, 16:19:37 schrieb Javier Martinez Canillas:
>>>> On 03/18/2016 07:53 PM, Doug Anderson wrote:
>>>>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang
>>>>> 
>>>
>>> wrote:
>>>> Same here, this is the second time I tested this series (first time was
>>>> v6 on October 25 [2]) and I think that has been out there for too long.
>>>>
>>>>> Tested-by: Douglas Anderson 
>>>>
>>>> Tested-by: Javier Martinez Canillas 
>>>
>>> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as
>>> Javier for the Exynos side based on the most recent drm state.
>>>
>>> As said by a lot of people it would be cool to get this merged soon -
>>> hopefully directly after -rc1. The only remaining question is through
>>> which
>>> tree it should go.
>>>
>>> I guess there are two basic options:
>>> - Inki takes the series - we could see the Rockchip-Ack being implied but
>>> maybe Mark can provide an explicit one
>>> - Mark takes the series with an Ack from Inki for the shared parts
>>>
>>> Inki, Mark do you have a preference?
>>
>> The problem would be that there is no drm bridge maintainer. I think the
>> most suitable person as the maintainer would be Ajay Kumar who is an author
>> of drm bridge framework. Of course, I could take them and have pull-request
>> again. But it seems a little late. Dave had already pull-request.
> 
> I really meant that for 4.7, not for the current merge window. I just want to 
> make sure it goes into a maintainer tree shortly after v4.6-rc1, before 
> something else changes the exynos-dp again :-).
> 
> 
>> To Ajay,
>> How about adding you as a drm bridge maintainer? DRM SoC driver maintainers
>> would need a person who can manage the drm bridge relevant pathes.
> 
> The previous example (dw_hdmi generalization between imx and rockchip) did 
> just go through the imx tree. So either the Samsung or Rockchip drm-trees 
> might be enough?

In this case, someone else may send an email again like you "who is going to 
merge?"
That would be why we need a maintainer.

drm panel is already managed well by Thierry Reding without such confusion. 

Thanks,
Inki Dae

> 
> 
> Heiko
> 
>

Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

2016-03-23 Thread Inki Dae

+ Ajay kumar with Samsung email

Hi,

2016ë 03ì 23ì¼ 07:12ì Heiko StÃ¼bner ì´(ê°) ì´ ê¸:
> Hi,
> 
> Am Dienstag, 22. MÃ¤rz 2016, 16:19:37 schrieb Javier Martinez Canillas:
>> On 03/18/2016 07:53 PM, Doug Anderson wrote:
>>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang >> gmail.com> 
> wrote:
>> Same here, this is the second time I tested this series (first time was
>> v6 on October 25 [2]) and I think that has been out there for too long.
>>
>>> Tested-by: Douglas Anderson 
>> Tested-by: Javier Martinez Canillas 
> 
> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as 
> Javier for the Exynos side based on the most recent drm state.
> 
> As said by a lot of people it would be cool to get this merged soon - 
> hopefully directly after -rc1. The only remaining question is through which 
> tree it should go.
> 
> I guess there are two basic options:
> - Inki takes the series - we could see the Rockchip-Ack being implied but 
> maybe Mark can provide an explicit one
> - Mark takes the series with an Ack from Inki for the shared parts
> 
> Inki, Mark do you have a preference?

The problem would be that there is no drm bridge maintainer. I think the most 
suitable person as the maintainer would be Ajay Kumar who is an author of drm 
bridge framework.
Of course, I could take them and have pull-request again. But it seems a little 
late. Dave had already pull-request.

To Ajay,
How about adding you as a drm bridge maintainer? DRM SoC driver maintainers 
would need a person who can manage the drm bridge relevant pathes.

Thanks,
Inki Dae

> 
> Thanks
> Heiko
> 
>

[PATCH v8 01/17] drm: exynos: dp: convert to drm bridge mode

2016-03-23 Thread Inki Dae



2015ë 10ì 28ì¼ 17:19ì Yakir Yang ì´(ê°) ì´ ê¸:
> In order to move exynos dp code to bridge directory,
> we need to convert driver drm bridge mode first. As
> dp driver already have a ptn3460 bridge, so we need
> to move ptn bridge to the next bridge of dp bridge.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> ---
> Changes in v8: None
> Changes in v7: None
> Changes in v6:
> - Fix the wrong code in previous series, and test on Samsung snow Chromebook
>   successfully, here are the detail changes:
> =>
> -   if (!dp->panel && !dp->bridge) {
> +   if (!dp->panel && !dp->ptn_bridge) {
> ret = exynos_dp_dt_parse_panel(dp);
> if (ret)
> =>
> +   encoder->bridge = bridge;
>   bridge->driver_private = dp;
> bridge->encoder = encoder;
> bridge->funcs = &exynos_dp_bridge_funcs;
> ret = drm_bridge_attach(drm_dev, bridge);
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Keep author name list no changed (Jingoo)
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c | 103 
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.h |   1 +
>  2 files changed, 78 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 124fb9a..aedd074 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 = &dp->encoder;
>   struct drm_connector *connector = &dp->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)
> +{

[GIT PULL] exynos-drm-next for 4.6

2016-03-13 Thread Inki Dae

Hi Dave,

   This pull request adds DRM_EXYNOS_GEM_MAP ioctl interface
   for the use of render node.
   This interface had been tried to mainline but tackled
   by Daniel Stone because there was no non-libdrm user,
   http://www.spinics.net/lists/dri-devel/msg93243.html

   We have already added the non-libdrm user support like below,

https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-exynos.git;a=commit;h=773b66e9f51db46745508c739c71b3f8a4e35a30

   And that has been tested enough. For more information
   about libtbm, this module is a buffer manager for Tizen platform.
   All applications - who want to use dma buffer - use this module
   to allocate dma buffer through DRM GEM.

   Kindly let me know if there is any problem.


Thanks,
Inki Dae


The following changes since commit 550e3b23a53c88adfa46e64f9d442743e65d47da:

  Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2016-03-08 10:51:51 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to 6564c65f3a2b75832957e53bcc3c6066d1d73487:

  drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl (2016-03-13 14:54:03 +0900)


Joonyoung Shim (1):
  drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl

 drivers/gpu/drm/exynos/exynos_drm_drv.c |2 ++
 drivers/gpu/drm/exynos/exynos_drm_gem.c |9 +
 drivers/gpu/drm/exynos/exynos_drm_gem.h |4 
 include/uapi/drm/exynos_drm.h   |   17 -
 4 files changed, 31 insertions(+), 1 deletion(-)

[GIT PULL] exynos-drm-next for 4.6

2016-03-02 Thread Inki Dae

Hi Dave,

   This pull request includes Exynos5420/5422 SoC support, fixups and cleanups.

   Summary:
   - Add Exynos5420 SoC support to FIMD driver.
 . This patch makes MIC(Mobile Image Compressor) IP to be bypassed in 
default
   in case of Exynos5420 and later. The Display pipe line configuraion for
   Exynos DRM driver will be considered through of graph concept later.
   - Add Exynos5422 SoC support to MIPI-DSI driver.
 . Exynos5422 SoC is similar to Exynos5433 SoC but software reset is 
different
   each other so this patch consideres the difference.
   - Get more precise clock divider value of FIMD controller.
 . This patch changes DIV_ROUND_CLOSEST macro to be used instead of 
DIV_ROUND_UP.
   - Refactor Exynos DRM device and driver registeration.
 . This patch makes Exynos DRM driver to be easy-to-read and at the same 
time,
   cleans it up by removing #ifdef ~ #endif things.
   - Configure DMA-mapping address space common to Exynos DRM devices in more 
generic
 without any hacks.
   - some fixups and cleanups.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit efcebcf983abf70a15958b9fb5237b1c38060d95:

  Merge tag 'drm-intel-next-2016-02-14' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-03-01 13:06:44 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to 6c81e96d4bd10617b856ce3cb5fa09337871bfdf:

  drm/exynos/dsi: use core helper to create DSI packet (2016-03-02 00:21:37 
+0900)


Andrzej Hajda (11):
  drm/exynos/decon: fix disable clocks order
  drm/exynos/dsi: replace registry access macros with functions
  drm/exynos/dsi: constify read only structures
  drm/exynos/hdmi: remove unused variable
  drm/exynos/decon: make irq handler static
  drm/exynos: remove incorrect ccflags from Makefile
  drm/exynos: remove struct exynos_drm_panel_info
  drm/exynos/fimc: remove unused camera interface polarization code
  drm/exynos: remove platform data structures and include/drm/exynos_drm.h
  drm/exynos: use arch independent types in uapi header
  drm/exynos/dsi: use core helper to create DSI packet

Chanho Park (3):
  drm/exynos: support exynos5422 mipi-dsi
  drm/exynos: use DIV_ROUND_CLOSEST to find the closest div
  drm/exynos: add exynos5420 support for fimd

Joonyoung Shim (1):
  drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS

Marek Szyprowski (11):
  drm/exynos: ipp: fix incorrect format specifiers in debug messages
  drm/exynos: fix types for compilation on 64bit architectures
  drm/exynos: mic: use devm_clk interface
  drm/exynos: mic: convert to component framework
  drm/exynos: mic: make all functions static
  drm/exynos: dsi: restore support for drm bridge
  drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable
  drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable
  drm/exynos: fix incorrect cpu address for dma_mmap_attrs()
  drm/exynos: refactor driver and device registration code
  drm/exynos: use real device for DMA-mapping operations

 .../bindings/display/exynos/exynos_dsim.txt|1 +
 .../bindings/display/exynos/samsung-fimd.txt   |3 +-
 drivers/gpu/drm/exynos/Kconfig |2 +-
 drivers/gpu/drm/exynos/Makefile|1 -
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c  |   10 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |1 -
 drivers/gpu/drm/exynos/exynos_dp_core.c|7 +-
 drivers/gpu/drm/exynos/exynos_dp_core.h|4 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  265 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   10 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  235 +
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimc.c   |   30 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   34 ++-
 drivers/gpu/drm/exynos/exynos_drm_g2d.c|   12 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c|   16 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c|2 +-
 drivers/gpu/drm/exynos/exynos_drm_iommu.c  |   39 +--
 drivers/gpu/drm/exynos/exynos_drm_iommu.h  |4 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c|   32 +--
 drivers/gpu/drm/exynos/exynos_drm_mic.c|   72 +++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c|3 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |8 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |2 -
 include/drm/exynos_drm.h   |  101 
 include/uapi/drm/exynos_drm.h  |

[PATCH] drm/exynos/dsi: use core helper to create DSI packet

2016-03-02 Thread Inki Dae

Fixed trivial one related to following warning,
drivers/gpu/drm/exynos/exynos_drm_dsi.c:1188:2: warning: format '%ld'
expects argument of type 'long int', but argument 5 has type 'size_t'
[-Wformat]

2016-02-17 22:33 GMT+09:00 Andrzej Hajda :
> Core provides generic helper to create DSI packet, use it instead of
> custom code.
>
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 69 
> +++--
>  1 file changed, 23 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 77e17ae..f17be93 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -10,6 +10,8 @@
>   * published by the Free Software Foundation.
>  */
>
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -222,12 +224,8 @@ struct exynos_dsi_transfer {
> struct list_head list;
> struct completion completed;
> int result;
> -   u8 data_id;
> -   u8 data[2];
> +   struct mipi_dsi_packet packet;
> u16 flags;
> -
> -   const u8 *tx_payload;
> -   u16 tx_len;
> u16 tx_done;
>
> u8 *rx_payload;
> @@ -322,6 +320,7 @@ enum reg_idx {
>  static inline void exynos_dsi_write(struct exynos_dsi *dsi, enum reg_idx idx,
> u32 val)
>  {
> +
> writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
>  }
>
> @@ -983,13 +982,14 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
> struct exynos_dsi_transfer *xfer)
>  {
> struct device *dev = dsi->dev;
> -   const u8 *payload = xfer->tx_payload + xfer->tx_done;
> -   u16 length = xfer->tx_len - xfer->tx_done;
> +   struct mipi_dsi_packet *pkt = &xfer->packet;
> +   const u8 *payload = pkt->payload + xfer->tx_done;
> +   u16 length = pkt->payload_length - xfer->tx_done;
> bool first = !xfer->tx_done;
> u32 reg;
>
> dev_dbg(dev, "< xfer %p: tx len %u, done %u, rx len %u, done %u\n",
> -   xfer, xfer->tx_len, xfer->tx_done, xfer->rx_len, 
> xfer->rx_done);
> +   xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
>
> if (length > DSI_TX_FIFO_SIZE)
> length = DSI_TX_FIFO_SIZE;
> @@ -998,8 +998,7 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>
> /* Send payload */
> while (length >= 4) {
> -   reg = (payload[3] << 24) | (payload[2] << 16)
> -   | (payload[1] << 8) | payload[0];
> +   reg = get_unaligned_le32(payload);
> exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
> payload += 4;
> length -= 4;
> @@ -1017,16 +1016,13 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
> reg |= payload[0];
> exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
> break;
> -   case 0:
> -   /* Do nothing */
> -   break;
> }
>
> /* Send packet header */
> if (!first)
> return;
>
> -   reg = (xfer->data[1] << 16) | (xfer->data[0] << 8) | xfer->data_id;
> +   reg = get_unaligned_le32(pkt->header);
> if (exynos_dsi_wait_for_hdr_fifo(dsi)) {
> dev_err(dev, "waiting for header FIFO timed out\n");
> return;
> @@ -1147,13 +1143,14 @@ again:
>
> spin_unlock_irqrestore(&dsi->transfer_lock, flags);
>
> -   if (xfer->tx_len && xfer->tx_done == xfer->tx_len)
> +   if (xfer->packet.payload_length &&
> +   xfer->tx_done == xfer->packet.payload_length)
> /* waiting for RX */
> return;
>
> exynos_dsi_send_to_fifo(dsi, xfer);
>
> -   if (xfer->tx_len || xfer->rx_len)
> +   if (xfer->packet.payload_length || xfer->rx_len)
> return;
>
> xfer->result = 0;
> @@ -1189,10 +1186,11 @@ static bool exynos_dsi_transfer_finish(struct 
> exynos_dsi *dsi)
> spin_unlock_irqrestore(&dsi->transfer_lock, flags);
>
> dev_dbg(dsi->dev,
> -   "> xfer %p, tx_len %u, tx_done %u, rx_len %u, rx_done %u\n",
> -   xfer, xfer->tx_len, xfer->tx_done, xfer->rx_len, 
> xfer->rx_done);
> +   "> xfer %p, tx_len %lu, tx_done %u, rx_len %u, rx_done %u\n",
> +   xfer, xfer->packet.payload_length, xfer->tx_done, 
> xfer->rx_len,

%zu would be required for xfer->packet.payload_length which has size_t type.

Thanks,
Inki Dae

[PATCH] drm/exynos/dsi: use core helper to create DSI packet

2016-02-29 Thread Inki Dae

Picked it up.

Thanks,
Inki Dae

2016ë 02ì 17ì¼ 22:33ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Core provides generic helper to create DSI packet, use it instead of
> custom code.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 69 
> +++--
>  1 file changed, 23 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 77e17ae..f17be93 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -10,6 +10,8 @@
>   * published by the Free Software Foundation.
>  */
>  
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -222,12 +224,8 @@ struct exynos_dsi_transfer {
>   struct list_head list;
>   struct completion completed;
>   int result;
> - u8 data_id;
> - u8 data[2];
> + struct mipi_dsi_packet packet;
>   u16 flags;
> -
> - const u8 *tx_payload;
> - u16 tx_len;
>   u16 tx_done;
>  
>   u8 *rx_payload;
> @@ -322,6 +320,7 @@ enum reg_idx {
>  static inline void exynos_dsi_write(struct exynos_dsi *dsi, enum reg_idx idx,
>   u32 val)
>  {
> +
>   writel(val, dsi->reg_base + dsi->driver_data->reg_ofs[idx]);
>  }
>  
> @@ -983,13 +982,14 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>   struct exynos_dsi_transfer *xfer)
>  {
>   struct device *dev = dsi->dev;
> - const u8 *payload = xfer->tx_payload + xfer->tx_done;
> - u16 length = xfer->tx_len - xfer->tx_done;
> + struct mipi_dsi_packet *pkt = &xfer->packet;
> + const u8 *payload = pkt->payload + xfer->tx_done;
> + u16 length = pkt->payload_length - xfer->tx_done;
>   bool first = !xfer->tx_done;
>   u32 reg;
>  
>   dev_dbg(dev, "< xfer %p: tx len %u, done %u, rx len %u, done %u\n",
> - xfer, xfer->tx_len, xfer->tx_done, xfer->rx_len, xfer->rx_done);
> + xfer, length, xfer->tx_done, xfer->rx_len, xfer->rx_done);
>  
>   if (length > DSI_TX_FIFO_SIZE)
>   length = DSI_TX_FIFO_SIZE;
> @@ -998,8 +998,7 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>  
>   /* Send payload */
>   while (length >= 4) {
> - reg = (payload[3] << 24) | (payload[2] << 16)
> - | (payload[1] << 8) | payload[0];
> + reg = get_unaligned_le32(payload);
>   exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
>   payload += 4;
>   length -= 4;
> @@ -1017,16 +1016,13 @@ static void exynos_dsi_send_to_fifo(struct exynos_dsi 
> *dsi,
>   reg |= payload[0];
>   exynos_dsi_write(dsi, DSIM_PAYLOAD_REG, reg);
>   break;
> - case 0:
> - /* Do nothing */
> - break;
>   }
>  
>   /* Send packet header */
>   if (!first)
>   return;
>  
> - reg = (xfer->data[1] << 16) | (xfer->data[0] << 8) | xfer->data_id;
> + reg = get_unaligned_le32(pkt->header);
>   if (exynos_dsi_wait_for_hdr_fifo(dsi)) {
>   dev_err(dev, "waiting for header FIFO timed out\n");
>   return;
> @@ -1147,13 +1143,14 @@ again:
>  
>   spin_unlock_irqrestore(&dsi->transfer_lock, flags);
>  
> - if (xfer->tx_len && xfer->tx_done == xfer->tx_len)
> + if (xfer->packet.payload_length &&
> + xfer->tx_done == xfer->packet.payload_length)
>   /* waiting for RX */
>   return;
>  
>   exynos_dsi_send_to_fifo(dsi, xfer);
>  
> - if (xfer->tx_len || xfer->rx_len)
> + if (xfer->packet.payload_length || xfer->rx_len)
>   return;
>  
>   xfer->result = 0;
> @@ -1189,10 +1186,11 @@ static bool exynos_dsi_transfer_finish(struct 
> exynos_dsi *dsi)
>   spin_unlock_irqrestore(&dsi->transfer_lock, flags);
>  
>   dev_dbg(dsi->dev,
> - "> xfer %p, tx_len %u, tx_done %u, rx_len %u, rx_done %u\n",
> - xfer, xfer->tx_len, xfer->tx_done, xfer->rx_len, xfer->rx_done);
> + "> xfer %p, tx_len %lu, tx_done %u, rx_len %u, rx_done %u\n",
> + xfer, xfer->packet.payload_length, xfer->tx_done, xfer->rx_len,
> + xfer->rx_done);
>  
> - if (xfer->tx_done != xfer-&

[PATCH 1/2] drm/exynos: refactor driver and device registration code

2016-02-29 Thread Inki Dae

For 1 and 2, picked it up.

Thanks,
Inki Dae


2016ë 02ì 18ì¼ 22:34ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch refactors driver and device registration by moving all drivers
> to the common array. This way additional flags can be added later for
> new features. #ifdef-based code has been replaced by IS_ENABLED() macro
> usage.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 233 
> +++-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |   1 -
>  2 files changed, 107 insertions(+), 127 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 68f0f36f6e7e..5ab8f1240d7b 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -495,69 +495,64 @@ static const struct dev_pm_ops exynos_drm_pm_ops = {
>  /* forward declaration */
>  static struct platform_driver exynos_drm_platform_driver;
>  
> +struct exynos_drm_driver_info {
> + struct platform_driver *driver;
> + unsigned int flags;
> +};
> +
> +#define DRM_COMPONENT_DRIVER BIT(0)  /* supports component framework */
> +#define DRM_VIRTUAL_DEVICE   BIT(1)  /* create virtual platform device */
> +
> +#define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? &drv : NULL)
> +
>  /*
>   * Connector drivers should not be placed before associated crtc drivers,
>   * because connector requires pipe number of its crtc during initialization.
>   */
> -static struct platform_driver *const exynos_drm_kms_drivers[] = {
> -#ifdef CONFIG_DRM_EXYNOS_FIMD
> - &fimd_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS5433_DECON
> - &exynos5433_decon_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS7_DECON
> - &decon_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_MIC
> - &mic_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_DP
> - &dp_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_DSI
> - &dsi_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_MIXER
> - &mixer_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_HDMI
> - &hdmi_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_VIDI
> - &vidi_driver,
> -#endif
> -};
> -
> -static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
> -#ifdef CONFIG_DRM_EXYNOS_G2D
> - &g2d_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_FIMC
> - &fimc_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_ROTATOR
> - &rotator_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_GSC
> - &gsc_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_IPP
> - &ipp_driver,
> -#endif
> - &exynos_drm_platform_driver,
> -};
> -
> -static struct platform_driver *const exynos_drm_drv_with_simple_dev[] = {
> -#ifdef CONFIG_DRM_EXYNOS_VIDI
> - &vidi_driver,
> -#endif
> -#ifdef CONFIG_DRM_EXYNOS_IPP
> - &ipp_driver,
> -#endif
> - &exynos_drm_platform_driver,
> +static struct exynos_drm_driver_info exynos_drm_drivers[] = {
> + {
> + DRV_PTR(fimd_driver, CONFIG_DRM_EXYNOS_FIMD),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(exynos5433_decon_driver, CONFIG_DRM_EXYNOS5433_DECON),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(decon_driver, CONFIG_DRM_EXYNOS7_DECON),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(dp_driver, CONFIG_DRM_EXYNOS_DP),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(dsi_driver, CONFIG_DRM_EXYNOS_DSI),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(hdmi_driver, CONFIG_DRM_EXYNOS_HDMI),
> + DRM_COMPONENT_DRIVER
> + }, {
> + DRV_PTR(vidi_driver, CONFIG_DRM_EXYNOS_VIDI),
> + DRM_COMPONENT_DRIVER | DRM_VIRTUAL_DEVICE
> + }, {
> + DRV_PTR(g2d_driver, CONFIG_DRM_EXYNOS_G2D),
> + }, {
> + DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
> + }, {
> + DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
> + }, {
> + DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
> + }, {
> + DRV_PTR(ipp_driver, CONFIG_DRM_EXYNOS_IPP),
> + DRM_VIRTUAL_DEVICE
> + }, {
> + &exynos_drm_platform_driver,
> + DRM_VIRTUAL_DEVICE
> + }
>  };
> -#define

[PATCH v5 5/5] drm/exynos: add support for blending properties

2016-02-29 Thread Inki Dae



2016ë 01ì 27ì¼ 23:44ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch adds support for blending related properties to Exynos DRM
> core and Exynos Mixer CRTC device.

To drm-misc.

Acked-by : Inki Dae 

Thanks,
Inki Dae

> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  5 +++
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 60 
> +++
>  2 files changed, 65 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 816537886e4e..b33d69b8bb38 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -92,6 +92,9 @@ struct exynos_drm_plane {
>  #define EXYNOS_DRM_PLANE_CAP_DOUBLE  (1 << 0)
>  #define EXYNOS_DRM_PLANE_CAP_SCALE   (1 << 1)
>  #define EXYNOS_DRM_PLANE_CAP_ZPOS(1 << 2)
> +#define EXYNOS_DRM_PLANE_CAP_PLANE_ALPHA (1 << 3)
> +#define EXYNOS_DRM_PLANE_CAP_PREMULT_ALPHA   (1 << 4)
> +#define EXYNOS_DRM_PLANE_CAP_BLENDING(1 << 5)
>  
>  /*
>   * Exynos DRM plane configuration structure.
> @@ -100,6 +103,7 @@ struct exynos_drm_plane {
>   * @type: type of the plane (primary, cursor or overlay).
>   * @pixel_formats: supported pixel formats.
>   * @num_pixel_formats: number of elements in 'pixel_formats'.
> + * @blending_mode: default blending mode.
>   * @capabilities: supported features (see EXYNOS_DRM_PLANE_CAP_*)
>   */
>  
> @@ -108,6 +112,7 @@ struct exynos_drm_plane_config {
>   enum drm_plane_type type;
>   const uint32_t *pixel_formats;
>   unsigned int num_pixel_formats;
> + unsigned int blending_mode;
>   unsigned int capabilities;
>  };
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 3a486939168e..28502aac135f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -140,6 +140,9 @@ static void exynos_drm_plane_reset(struct drm_plane 
> *plane)
>   plane->state = &exynos_state->base;
>   plane->state->plane = plane;
>   plane->state->zpos = exynos_plane->config->zpos;
> + plane->state->alpha = 255;
> + plane->state->alpha_premult = 1;
> + plane->state->blending = exynos_plane->config->blending_mode;
>   }
>  }
>  
> @@ -284,6 +287,53 @@ static void exynos_plane_attach_zpos_property(struct 
> drm_plane *plane,
>   drm_object_attach_property(&plane->base, prop, zpos);
>  }
>  
> +static void exynos_plane_attach_alpha_property(struct drm_plane *plane)
> +{
> + struct drm_device *dev = plane->dev;
> +
> + if (!dev->mode_config.alpha_property)
> + if (drm_mode_create_alpha_property(dev, 255))
> + return;
> +
> + drm_object_attach_property(&plane->base,
> +dev->mode_config.alpha_property, 255);
> +}
> +
> +static void exynos_plane_attach_alpha_premult_property(struct drm_plane 
> *plane)
> +{
> + struct drm_device *dev = plane->dev;
> +
> + if (!dev->mode_config.alpha_premult_property)
> + if (drm_mode_create_alpha_premult_property(dev)) {
> + printk("failed to create alpha premult property\n");
> + return;
> + }
> +
> + drm_object_attach_property(&plane->base,
> +dev->mode_config.alpha_premult_property, 1);
> +}
> +
> +static void exynos_plane_attach_blending_property(struct drm_plane *plane,
> +   unsigned int blending_mode)
> +{
> + struct drm_device *dev = plane->dev;
> + static unsigned int blending_modes[] = {
> + DRM_BLEND_DISABLED,
> + DRM_BLEND_PIXEL_ALPHA,
> + DRM_BLEND_CONST_ALPHA,
> + DRM_BLEND_PIXEL_CONST_ALPHA,
> + };
> +
> + if (!dev->mode_config.blending_property)
> + if (drm_mode_create_blending_property(dev, blending_modes,
> + ARRAY_SIZE(blending_modes)))
> + return;
> +
> + drm_object_attach_property(&plane->base,
> +dev->mode_config.blending_property,
> +blending_mode);
> +}
> +
>  int exynos_plane_init(struct drm_device *dev,
> struct exynos_drm_plane *exynos_plane,
>

[PATCH v5 2/5] drm/exynos: use generic code for managing zpos plane property

2016-02-29 Thread Inki Dae



2016ë 01ì 27ì¼ 23:44ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch replaces zpos property handling custom code in Exynos DRM
> driver with calls to generic DRM code.

It'd be better to go to drm-misc.

Acked-by: Inki Dae 

Thanks,
Inki Dae

> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 68 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
>  3 files changed, 20 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 17b5ded72ff1..816537886e4e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
>   struct exynos_drm_rect src;
>   unsigned int h_ratio;
>   unsigned int v_ratio;
> - unsigned int zpos;
>  };
>  
>  static inline struct exynos_drm_plane_state *
> @@ -217,7 +216,6 @@ struct exynos_drm_private {
>* this array is used to be aware of which crtc did it request vblank.
>*/
>   struct drm_crtc *crtc[MAX_CRTC];
> - struct drm_property *plane_zpos_property;
>  
>   unsigned long da_start;
>   unsigned long da_space_size;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index d86227236f55..3a486939168e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -137,9 +137,9 @@ static void exynos_drm_plane_reset(struct drm_plane 
> *plane)
>  
>   exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
>   if (exynos_state) {
> - exynos_state->zpos = exynos_plane->config->zpos;
>   plane->state = &exynos_state->base;
>   plane->state->plane = plane;
> + plane->state->zpos = exynos_plane->config->zpos;
>   }
>  }
>  
> @@ -155,7 +155,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
>   return NULL;
>  
>   __drm_atomic_helper_plane_duplicate_state(plane, ©->base);
> - copy->zpos = exynos_state->zpos;
>   return ©->base;
>  }
>  
> @@ -168,43 +167,6 @@ static void exynos_drm_plane_destroy_state(struct 
> drm_plane *plane,
>   kfree(old_exynos_state);
>  }
>  
> -static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
> - struct drm_plane_state *state,
> - struct drm_property *property,
> - uint64_t val)
> -{
> - struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> - struct exynos_drm_plane_state *exynos_state =
> - to_exynos_plane_state(state);
> - struct exynos_drm_private *dev_priv = plane->dev->dev_private;
> - const struct exynos_drm_plane_config *config = exynos_plane->config;
> -
> - if (property == dev_priv->plane_zpos_property &&
> - (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
> - exynos_state->zpos = val;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
> -   const struct drm_plane_state *state,
> -   struct drm_property *property,
> -   uint64_t *val)
> -{
> - const struct exynos_drm_plane_state *exynos_state =
> - container_of(state, const struct exynos_drm_plane_state, base);
> - struct exynos_drm_private *dev_priv = plane->dev->dev_private;
> -
> - if (property == dev_priv->plane_zpos_property)
> - *val = exynos_state->zpos;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
>  static struct drm_plane_funcs exynos_plane_funcs = {
>   .update_plane   = drm_atomic_helper_update_plane,
>   .disable_plane  = drm_atomic_helper_disable_plane,
> @@ -213,8 +175,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
>   .reset  = exynos_drm_plane_reset,
>   .atomic_duplicate_state = exynos_drm_plane_duplicate_state,
>   .atomic_destroy_state = exynos_drm_plane_destroy_state,
> - .atomic_set_property = exynos_drm_plane_atomic_set_property,
> - .atomic_get_property = exynos_drm_plane_atomic_get_property,
>  };
>  
>  static int
> @@ -302,20 +262,2

[PATCH 1/2] drm/exynos: add exynos5420 support for fimd

2016-02-23 Thread Inki Dae

Picked it up.

Thanks,
Inki Dae

2016ë 02ì 12ì¼ 22:31ì Chanho Park ì´(ê°) ì´ ê¸:
> This patch adds a exynos5420 driver data to support mic_bypass
> option to bypass the mic from display out path.
> The mic(Mobile image compressor) compresses RGB data from fimd
> and send the compressed data to the mipi dsi.
> The bypass option can be founded from system register and the bit
> is 11. The option bit has been introduced since exynos5420. The
> only difference between exynos5250 and exynos5420/exynos5422 is
> existence of the bit. Until the MIC is defined and enabled from
> device tree, the bypass mic will be default option.
> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Signed-off-by: Chanho Park 
> ---
>  .../bindings/display/exynos/samsung-fimd.txt   |  3 ++-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 31 
> +-
>  2 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt 
> b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> index 27c3ce0..c7c6b9a 100644
> --- a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> @@ -12,7 +12,8 @@ Required properties:
>   "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */
>   "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
>   "samsung,exynos4415-fimd"; /* for Exynos4415 SoC */
> - "samsung,exynos5250-fimd"; /* for Exynos5 SoCs */
> + "samsung,exynos5250-fimd"; /* for Exynos5250 SoCs */
> + "samsung,exynos5420-fimd"; /* for Exynos5420/5422/5800 SoCs */
>  
>  - reg: physical base address and length of the FIMD registers set.
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 70194d0..41c3bb2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -94,12 +94,14 @@ struct fimd_driver_data {
>   unsigned int lcdblk_offset;
>   unsigned int lcdblk_vt_shift;
>   unsigned int lcdblk_bypass_shift;
> + unsigned int lcdblk_mic_bypass_shift;
>  
>   unsigned int has_shadowcon:1;
>   unsigned int has_clksel:1;
>   unsigned int has_limited_fmt:1;
>   unsigned int has_vidoutcon:1;
>   unsigned int has_vtsel:1;
> + unsigned int has_mic_bypass:1;
>  };
>  
>  static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -145,6 +147,18 @@ static struct fimd_driver_data exynos5_fimd_driver_data 
> = {
>   .has_vtsel = 1,
>  };
>  
> +static struct fimd_driver_data exynos5420_fimd_driver_data = {
> + .timing_base = 0x2,
> + .lcdblk_offset = 0x214,
> + .lcdblk_vt_shift = 24,
> + .lcdblk_bypass_shift = 15,
> + .lcdblk_mic_bypass_shift = 11,
> + .has_shadowcon = 1,
> + .has_vidoutcon = 1,
> + .has_vtsel = 1,
> + .has_mic_bypass = 1,
> +};
> +
>  struct fimd_context {
>   struct device   *dev;
>   struct drm_device   *drm_dev;
> @@ -184,6 +198,8 @@ static const struct of_device_id fimd_driver_dt_match[] = 
> {
> .data = &exynos4415_fimd_driver_data },
>   { .compatible = "samsung,exynos5250-fimd",
> .data = &exynos5_fimd_driver_data },
> + { .compatible = "samsung,exynos5420-fimd",
> +   .data = &exynos5420_fimd_driver_data },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
> @@ -461,6 +477,18 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>   return;
>   }
>  
> + /* TODO: When MIC is enabled for display path, the lcdblk_mic_bypass
> +  * bit should be cleared.
> +  */
> + if (driver_data->has_mic_bypass && ctx->sysreg &&
> + regmap_update_bits(ctx->sysreg,
> + driver_data->lcdblk_offset,
> + 0x1 << driver_data->lcdblk_mic_bypass_shift,
> + 0x1 << driver_data->lcdblk_mic_bypass_shift)) {
> + DRM_ERROR("Failed to update sysreg for bypass mic.\n");
> + return;
> + }
> +
>   /* setup horizontal and vertical display size. */
>   val = VIDTCON2_LINEVAL(mode->vdisplay - 1) |
>  VIDTCON2_HOZVAL(mode->hdisplay - 1) |
> @@ -861,7 +889,8 @@ static void fimd_dp_clock_enable(struct exynos_drm_crtc 
> *crtc, bool enable)
>* 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 != &exynos5_fimd_driver_data)
> + if (ctx->driver_data != &exynos5_fimd_driver_data ||
> + ctx->driver_data != &exynos5420_fimd_driver_data)
>   return;
>  
>   val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
>

< 1 2 3 4 5 6 7 8 9 10 >

501 - 600 of 3059 matches

Mail list logo