Re: [PATCH RESEND] drm: panel-orientation-quirks: Add quirk for Aya Neo KUN

[Tobias Jakobi]

On 3/10/24 23:04, tjak...@math.uni-bielefeld.de wrote:


From: Tobias Jakobi 

Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.

Signed-off-by: Tobias Jakobi 
---
  drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 3d92f66e550c..5d3fb11fd45f 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -196,6 +196,12 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_MATCH(DMI_BOARD_NAME, "NEXT"),
},
.driver_data = (void *)_rightside_up,
+   }, {/* AYA NEO KUN */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AYANEO"),
+ DMI_MATCH(DMI_BOARD_NAME, "KUN"),
+   },
+   .driver_data = (void *)_rightside_up,
}, {/* Chuwi HiBook (CWI514) */
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),

Another gentle ping!

Re: [PATCH] drm/amd/display: Add MSF panel to DPCD 0x317 patch list

[Tobias Jakobi]

On 3/9/24 02:47, tjak...@math.uni-bielefeld.de wrote:


From: Tobias Jakobi 

This 8.4 inch panel is integrated in the Ayaneo Kun handheld
device. The panel resolution is 2560×1600, i.e. it has
portrait dimensions.

Decoding the EDID shows:
Manufacturer: MSF
Model: 4099
Display Product Name: 'TV080WUM-NL0 '

Judging from the product name this might be a clone of a
BOE panel, but with larger dimensions.

Panel frequently shows non-functional backlight control. Adding
some debug prints to update_connector_ext_caps() shows that
something the OLED bit of ext_caps is set, and then the driver
assumes that backlight is controlled via AUX.

Forcing backlight control to PWM via amdgpu.backlight=0 restores
backlight operation.

Signed-off-by: Tobias Jakobi 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 7a09a72e182f..5a017ba94e3c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -68,6 +68,7 @@ static void apply_edid_quirks(struct edid *edid, struct 
dc_edid_caps *edid_caps)
case drm_edid_encode_panel_id('A', 'U', 'O', 0xE69B):
case drm_edid_encode_panel_id('B', 'O', 'E', 0x092A):
case drm_edid_encode_panel_id('L', 'G', 'D', 0x06D1):
+   case drm_edid_encode_panel_id('M', 'S', 'F', 0x1003):
DRM_DEBUG_DRIVER("Clearing DPCD 0x317 on monitor with panel id 
%X\n", panel_id);
edid_caps->panel_patch.remove_sink_ext_caps = true;
break;

Another gentle ping!

Re: [PATCH RESEND] drm: panel-orientation-quirks: Add quirk for Aya Neo KUN

[Tobias Jakobi]

On 3/10/24 23:04, tjak...@math.uni-bielefeld.de wrote:


From: Tobias Jakobi 

Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.

Signed-off-by: Tobias Jakobi 
---
  drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 3d92f66e550c..5d3fb11fd45f 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -196,6 +196,12 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_MATCH(DMI_BOARD_NAME, "NEXT"),
},
.driver_data = (void *)_rightside_up,
+   }, {/* AYA NEO KUN */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "AYANEO"),
+ DMI_MATCH(DMI_BOARD_NAME, "KUN"),
+   },
+   .driver_data = (void *)_rightside_up,
}, {/* Chuwi HiBook (CWI514) */
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),

Gentle ping...

Re: [PATCH] drm/amd/display: Add MSF panel to DPCD 0x317 patch list

[Tobias Jakobi]

On 3/9/24 02:47, tjak...@math.uni-bielefeld.de wrote:


From: Tobias Jakobi 

This 8.4 inch panel is integrated in the Ayaneo Kun handheld
device. The panel resolution is 2560×1600, i.e. it has
portrait dimensions.

Decoding the EDID shows:
Manufacturer: MSF
Model: 4099
Display Product Name: 'TV080WUM-NL0 '

Judging from the product name this might be a clone of a
BOE panel, but with larger dimensions.

Panel frequently shows non-functional backlight control. Adding
some debug prints to update_connector_ext_caps() shows that
something the OLED bit of ext_caps is set, and then the driver
assumes that backlight is controlled via AUX.

Forcing backlight control to PWM via amdgpu.backlight=0 restores
backlight operation.

Signed-off-by: Tobias Jakobi 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 7a09a72e182f..5a017ba94e3c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -68,6 +68,7 @@ static void apply_edid_quirks(struct edid *edid, struct 
dc_edid_caps *edid_caps)
case drm_edid_encode_panel_id('A', 'U', 'O', 0xE69B):
case drm_edid_encode_panel_id('B', 'O', 'E', 0x092A):
case drm_edid_encode_panel_id('L', 'G', 'D', 0x06D1):
+   case drm_edid_encode_panel_id('M', 'S', 'F', 0x1003):
DRM_DEBUG_DRIVER("Clearing DPCD 0x317 on monitor with panel id 
%X\n", panel_id);
edid_caps->panel_patch.remove_sink_ext_caps = true;
break;

Gentle ping...

Re: [PATCH] drm: panel-orientation-quirks: Add quirk for Aya Neo KUN

[Tobias Jakobi]

Hi Dmitry,

On 2/7/24 12:00, Dmitry Baryshkov wrote:

On Tue, 6 Feb 2024 at 01:57,  wrote:

From: Tobias Jakobi 

Similar to the other Aya Neo devices this one features
again a portrait screen, here with a native resolution
of 1600x2560.

Signed-off-by: Tobias Jakobi 

As you don't seem to be the author of the patch, this needs your sign-off too.


I'm not sure what you mean. Patch is by me, and signed off by me.

- Tobias

Re: [PATCH] drm/exynos/mixer: Remove unused local variable priv

[Tobias Jakobi]

Hello Krzysztof,

looks good to me!

Reviewed-by: Tobias Jakobi 

- Tobias


Krzysztof Kozlowski wrote:
> Remove local variable 'priv' to fix GCC warning:
> 
> drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_initialize':
> drivers/gpu/drm/exynos/exynos_mixer.c:840:29: warning: variable 'priv' 
> set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 272c79f5f5bf..b86ae2ab9590 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -837,8 +837,6 @@ static int mixer_initialize(struct mixer_context 
> *mixer_ctx,
>   struct drm_device *drm_dev)
>  {
>   int ret;
> - struct exynos_drm_private *priv;
> - priv = drm_dev->dev_private;
>  
>   mixer_ctx->drm_dev = drm_dev;
>  
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

[Tobias Jakobi]

Hey Arnd,

looks good to me!

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

- Tobias


Arnd Bergmann wrote:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
> 
> 1. signed seconds overflow in y2038
> 2. the 'struct timeval' definition is deprecated in the kernel
> 3. time may jump or go backwards after a 'settimeofday()' syscall
> 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
>can't be compared
> 5. exporting microseconds requires a division by 1000, which may
>be slow on some architectures.
> 
> The code existed in two places before, but the IPP portion was
> removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM
> IPP subsystem"), so we no longer need to worry about it.
> 
> Ideally timestamps should just use 64-bit nanoseconds instead, but
> of course we can't change that now. Instead, this tries to address
> the first four points above by using monotonic 'timespec' values.
> 
> According to Tobias Jakobi, user space doesn't care about the
> timestamp at the moment, so we can change the format. Even if
> there is something looking at them, it will work just fine with
> monotonic times as long as the application only looks at the
> relative values between two events.
> 
> Link: https://patchwork.kernel.org/patch/10038593/
> Cc: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> v2: rebased to what will be in 4.15, now that ipp is gone,
> updated changelog text based on input from Tobias.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 2b8bf2dd6387..9effe40f5fa5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -926,7 +926,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   struct drm_device *drm_dev = g2d->subdrv.drm_dev;
>   struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
>   struct drm_exynos_pending_g2d_event *e;
> - struct timeval now;
> + struct timespec64 now;
>  
>   if (list_empty(_node->event_list))
>   return;
> @@ -934,9 +934,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   e = list_first_entry(_node->event_list,
>struct drm_exynos_pending_g2d_event, base.link);
>  
> - do_gettimeofday();
> + ktime_get_ts64();
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.cmdlist_no = cmdlist_no;
>  
>   drm_send_event(drm_dev, >base);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[Tobias Jakobi]

Inki Dae wrote:
> Hi Tobias,
> 
> Thanks for touching this code.
> 
> But I think below changes chould be explained exactly. Anyway, below are my 
> comments,
> 
> 2017년 11월 23일 23:19에 Tobias Jakobi 이(가) 쓴 글:
>> If an interlaced video mode is selected, a IOMMU pagefault is
>> triggered by vp_video_buffer().
>>
>> Fix the most apparent bugs:
>> - pitch value for chroma plane
>> - divide by two of height and vpos
>>
>> This is more like a band-aid at this point. The VP plane is
>> still corrupted, but at least there are no more pagefaults.
>>
>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
>>  1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index dc5d79465f9b..a18426379e57 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>>  chroma_addr[1] = chroma_addr[0] + 0x40;
>>  } else {
>>  luma_addr[1] = luma_addr[0] + fb->pitches[0];
>> -chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
>> +chroma_addr[1] = chroma_addr[0] + fb->pitches[1];
> 
> chroma_addr[1] is set to VP_BOT_C_PTR register and datasheet says about this 
> register,
> "specifies base address for Chrominance of bottom field"
> 
> Before that, we would need to look into NV12 pixel format and its video 
> signal mode - interlaced or progressive.
You're mixing something up here. The buffer is (progressive) NV12, but the video
mode is interlaced.


> NV12 interfaced
> YY
> YY
> UVUVUVUVUV
> YY
> YY
> UVUVUVUVUV
> 
> NV12 progressive
> YY
> YY
> YY
> YY
> UVUVUVUVUV
> UVUVUVUVUV
> 
> As you can see above, the offset of the gem buffer should be decided 
> according to video signal mode, and 'base address + the offset' should be set 
> to chroma_addr[1] register properly. 
> 
> And also there would be one thing more we have to consider,
> User space can make two separated gem buffers - one is for luminance pixel 
> data and other is for chrominance pixel data - and send them to KMS driver, 
> or he can make one contiguous gem buffer which contains two kinds of pixel 
> data and send it to KMS driver.
> 
> I guess now vp side of mixer driver didn't manage these buffers properly so 
> page fault happened. So I think a good way for it would be to handle two 
> kinds of buffers properly - one continuous buffer or two separated buffers - 
> through exynos_drm_gem_fb_dma_addr function, and calculate the offset 
> properly according to video signal mode - interfaced or progressive.
> 
> Regarding this, we had posted one patch and it had been merged to mainline. 
> This patch added two new pixel formats, DRM_FORMAT_NV12M and 
> DRM_FORMAT_YUV420M to judge how KMS driver should handle these gem buffers. 
> However, this patch had been reverted[1] by Ville due to breaking the ABI. So 
> the only way to identify buffer type would be to check how many buffers are 
> set to exynos_drm_fb object.
That's not related. In fact the second part (div by 2) is what actually removes
the pagefaults.

- Tobias



> [1] https://lists.freedesktop.org/archives/dri-devel/2012-April/021812.html
> 
> Thanks,
> Inki Dae
> 
>>  }
>>  } else {
>>  luma_addr[1] = 0;
>> @@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx,
>>  vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
>>  VP_IMG_VSIZE(fb->height));
>>  /* chroma plane for NV12/NV21 is half the height of the luma plane */
>> -vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
>> +vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
>>  VP_IMG_VSIZE(fb->height / 2));
>>  
>>  vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
>> -vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
>>  vp_reg_write(ctx, VP_SRC_H_POSITION,
>>  VP_SRC_H_POSITION_VAL(state->src.x));
>> -vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
>>  
>> -vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
>> -vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
>>  if (test_bit(MXR_BIT_INTERLACE, >flags)) {
>> -

[PATCH v2] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[Tobias Jakobi]

If an interlaced video mode is selected, a IOMMU pagefault is
triggered by vp_video_buffer().

Fix the most apparent bugs:
- pitch value for chroma plane
- divide by two of height and vpos

This is more like a band-aid at this point. The VP plane is
still corrupted, but at least there are no more pagefaults.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index dc5d79465f9b..a18426379e57 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
luma_addr[1] = luma_addr[0] + fb->pitches[0];
-   chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
+   chroma_addr[1] = chroma_addr[0] + fb->pitches[1];
}
} else {
luma_addr[1] = 0;
@@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
/* chroma plane for NV12/NV21 is half the height of the luma plane */
-   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
+   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
VP_IMG_VSIZE(fb->height / 2));
 
vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
-   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
vp_reg_write(ctx, VP_SRC_H_POSITION,
VP_SRC_H_POSITION_VAL(state->src.x));
-   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
 
-   vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
-   vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
if (test_bit(MXR_BIT_INTERLACE, >flags)) {
-   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2);
-   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2);
+   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h / 2);
+   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y / 2);
} else {
-   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
-   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
+   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
+   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
}
 
+   vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
+   vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
+   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
+   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
+
vp_reg_write(ctx, VP_H_RATIO, state->h_ratio);
vp_reg_write(ctx, VP_V_RATIO, state->v_ratio);
 
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[Tobias Jakobi]

Please disregard this one, need to rebase. v2 in a minute...

- Tobias


Tobias Jakobi wrote:
> If an interlaced video mode is selected, a IOMMU pagefault is
> triggered by vp_video_buffer().
> 
> Fix the most apparent bugs:
> - pitch value for chroma plane
> - divide by two of height and vpos
> 
> This is more like a band-aid at this point. The VP plane is
> still corrupted, but at least there are no more pagefaults.
> 
> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index dc5d79465f9b..c382f99e0f5b 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   chroma_addr[1] = chroma_addr[0] + 0x40;
>   } else {
>   luma_addr[1] = luma_addr[0] + fb->pitches[0];
> - chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
> + chroma_addr[1] = chroma_addr[0] + fb->pitches[1];
>   }
>   } else {
>   luma_addr[1] = 0;
> @@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
>   VP_IMG_VSIZE(fb->height));
>   /* chroma plane for NV12/NV21 is half the height of the luma plane */
> - vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
> + vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
>   VP_IMG_VSIZE(fb->height / 2));
>  
>   vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
> - vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
>   vp_reg_write(ctx, VP_SRC_H_POSITION,
>   VP_SRC_H_POSITION_VAL(state->src.x));
> - vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
>  
> - vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
> - vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
>   if (test_bit(MXR_BIT_INTERLACE, >flags)) {
> - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2);
> - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2);
> + vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2);
> + vp_reg_write(res, VP_SRC_V_POSITION, state->src.y / 2);
>   } else {
> - vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
> - vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
> + vp_reg_write(res, VP_SRC_HEIGHT, state->src.h);
> + vp_reg_write(res, VP_SRC_V_POSITION, state->src.y);
>   }
>  
> + vp_reg_write(res, VP_DST_WIDTH, state->crtc.w);
> + vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x);
> + vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h);
> + vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y);
> +
>   vp_reg_write(ctx, VP_H_RATIO, state->h_ratio);
>   vp_reg_write(ctx, VP_V_RATIO, state->v_ratio);
>  
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[Tobias Jakobi]

If an interlaced video mode is selected, a IOMMU pagefault is
triggered by vp_video_buffer().

Fix the most apparent bugs:
- pitch value for chroma plane
- divide by two of height and vpos

This is more like a band-aid at this point. The VP plane is
still corrupted, but at least there are no more pagefaults.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index dc5d79465f9b..c382f99e0f5b 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
luma_addr[1] = luma_addr[0] + fb->pitches[0];
-   chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
+   chroma_addr[1] = chroma_addr[0] + fb->pitches[1];
}
} else {
luma_addr[1] = 0;
@@ -507,25 +507,26 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
/* chroma plane for NV12/NV21 is half the height of the luma plane */
-   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
+   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
VP_IMG_VSIZE(fb->height / 2));
 
vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
-   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
vp_reg_write(ctx, VP_SRC_H_POSITION,
VP_SRC_H_POSITION_VAL(state->src.x));
-   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
 
-   vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
-   vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
if (test_bit(MXR_BIT_INTERLACE, >flags)) {
-   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2);
-   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2);
+   vp_reg_write(res, VP_SRC_HEIGHT, state->src.h / 2);
+   vp_reg_write(res, VP_SRC_V_POSITION, state->src.y / 2);
} else {
-   vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
-   vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
+   vp_reg_write(res, VP_SRC_HEIGHT, state->src.h);
+   vp_reg_write(res, VP_SRC_V_POSITION, state->src.y);
}
 
+   vp_reg_write(res, VP_DST_WIDTH, state->crtc.w);
+   vp_reg_write(res, VP_DST_H_POSITION, state->crtc.x);
+   vp_reg_write(res, VP_DST_HEIGHT, state->crtc.h);
+   vp_reg_write(res, VP_DST_V_POSITION, state->crtc.y);
+
vp_reg_write(ctx, VP_H_RATIO, state->h_ratio);
vp_reg_write(ctx, VP_V_RATIO, state->v_ratio);
 
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Tobias Jakobi]

Inki Dae wrote:
> 
> 
> 2017년 11월 22일 22:14에 Marek Szyprowski 이(가) 쓴 글:
>> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
>> are contiguous, because of the underlying dma_alloc_attrs() function
>> provides only such buffers. In such case it makes no sense to keep
>> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
>> failures for buffer contiguity checks in the subsequent operations on GEM
>> objects.
>>
>> Signed-off-by: Marek Szyprowski 
>> CC: sta...@vger.kernel.org # v4.4+
>> ---
>> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
>> support for exynos drm framework"), but this patch applies cleanly
>> only to v4.4+ kernel releases due changes in the surrounding code.
>>
>> Changelog:
>> v2:
>> - added warning message when buffer flags are updadated (requested by Inki)
>>
>> v1: https://patchwork.kernel.org/patch/10034919/
>> - initial version
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 077de014d610..4400efe3974a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
>> drm_device *dev,
>>  if (IS_ERR(exynos_gem))
>>  return exynos_gem;
>>  
>> +if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) {
>> +/*
>> + * when no IOMMU is available, all allocated buffers are
>> + * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag
>> + */
>> +flags &= ~EXYNOS_BO_NONCONTIG;
>> +DRM_WARN("Non-contiguous allocation is not supported without 
>> IOMMU, falling back to contiguous buffer\n");
> 
> WARNING: line over 80 characters
That warning is bogus. Message strings are not supposed to be split.


> I wil change above a warning like below if you are ok,
>   DRM_WARN("Changed to CONTIG buffer due to no IOMMU support.\n");
I think Marek's message is more descriptive.

- Tobias

> 
> 
> Thanks,
> Inki Dae
> 
>> +}
>> +
>>  /* set memory type and cache attribute from user side. */
>>  exynos_gem->flags = flags;
>>  
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU

[Tobias Jakobi]

Marek Szyprowski wrote:
> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
> are contiguous, because of the underlying dma_alloc_attrs() function
> provides only such buffers. In such case it makes no sense to keep
> BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
> failures for buffer contiguity checks in the subsequent operations on GEM
> objects.

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

- Tobias

> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> CC: sta...@vger.kernel.org # v4.4+
> ---
> This issue is there since commit 0519f9a12d011 ("drm/exynos: add iommu
> support for exynos drm framework"), but this patch applies cleanly
> only to v4.4+ kernel releases due changes in the surrounding code.
> 
> Changelog:
> v2:
> - added warning message when buffer flags are updadated (requested by Inki)
> 
> v1: https://patchwork.kernel.org/patch/10034919/
> - initial version
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 077de014d610..4400efe3974a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -247,6 +247,15 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
> drm_device *dev,
>   if (IS_ERR(exynos_gem))
>   return exynos_gem;
>  
> + if (!is_drm_iommu_supported(dev) && (flags & EXYNOS_BO_NONCONTIG)) {
> + /*
> +  * when no IOMMU is available, all allocated buffers are
> +  * contiguous anyway, so drop EXYNOS_BO_NONCONTIG flag
> +  */
> + flags &= ~EXYNOS_BO_NONCONTIG;
> + DRM_WARN("Non-contiguous allocation is not supported without 
> IOMMU, falling back to contiguous buffer\n");
> + }
> +
>   /* set memory type and cache attribute from user side. */
>   exynos_gem->flags = flags;
>  
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] exynos: drm: use monotonic timestamps

[Tobias Jakobi]

Hello Arnd,

I guess you could coordinate the IPP changes with Marek, who is rewriting the
IPP subsystem anyway (added Marek to Cc).

Here is the most recent IPPv2 series:
https://www.spinics.net/lists/linux-samsung-soc/msg61066.html

Concerning the G2D changes, I don't think anything in userspace uses the
timestamps (e.g. for synchronisation).

With best wishes,
Tobias


Arnd Bergmann wrote:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
> 
> 1. signed seconds overflow in y2038
> 2. the 'struct timeval' definition is deprecated in the kernel
> 3. time may jump or go backwards after a 'settimeofday()' syscall
> 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
>can't be compared
> 5. exporting microseconds requires a division by 1000, which may
>be slow on some architectures.
> 
> Ideally timestamps should just use 64-bit nanoseconds instead, but
> of course we can't change that now. Instead, this tries to address
> the first four points above by using monotonic 'timespec' values.
> 
> The downside is that there is a small risk of breaking user space
> if that expects the absolute timestamp numbers to relate to the
> result of 'gettimeofday()'. Please review the user space driver
> before applying this patch to ensure this works.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +++---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 2b8bf2dd6387..9effe40f5fa5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -926,7 +926,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   struct drm_device *drm_dev = g2d->subdrv.drm_dev;
>   struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
>   struct drm_exynos_pending_g2d_event *e;
> - struct timeval now;
> + struct timespec64 now;
>  
>   if (list_empty(_node->event_list))
>   return;
> @@ -934,9 +934,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   e = list_first_entry(_node->event_list,
>struct drm_exynos_pending_g2d_event, base.link);
>  
> - do_gettimeofday();
> + ktime_get_ts64();
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.cmdlist_no = cmdlist_no;
>  
>   drm_send_event(drm_dev, >base);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 3edda18cc2d2..3f9d8d79bbde 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -1406,7 +1406,7 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
> *ippdrv,
>   struct drm_exynos_ipp_queue_buf qbuf;
>   struct drm_exynos_ipp_send_event *e;
>   struct list_head *head;
> - struct timeval now;
> + struct timespec64 now;
>   u32 tbuf_id[EXYNOS_DRM_OPS_MAX] = {0, };
>   int ret, i;
>  
> @@ -1509,10 +1509,10 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
> *ippdrv,
>   e = list_first_entry(_node->event_list,
>   struct drm_exynos_ipp_send_event, base.link);
>  
> - do_gettimeofday();
> - DRM_DEBUG_KMS("tv_sec[%ld]tv_usec[%ld]\n", now.tv_sec, now.tv_usec);
> + ktime_get_ts64();
> + DRM_DEBUG_KMS("tv_sec[%lld]tv_nsec[%ld]\n", (s64)now.tv_sec, 
> now.tv_nsec);
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.prop_id = property->prop_id;
>  
>   /* set buffer id about source destination */
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Tobias Jakobi]

 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 <inki@samsung.com>
>>   *
>> - * 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_REG_H_
>> diff --git a/libkms/exynos.c b/libkms/exynos.c
>> index 0e97fb5..c20b6b0 100644
>> --- a/libkms/exynos.c
>> +++ b/libkms/exynos.c
>> @@ -5,10 +5,24 @@
>>   *  SooChan Lim <sc1@samsung.com>
>>   *  Sangjin LEE <lsj...@samsung.com>
>>   *
>> - * 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
>> + * THE AUTHORS OR COPYRIGHT HOLDERS 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/tests/exynos/exynos_fimg2d_event.c 
>> b/tests/exynos/exynos_fimg2d_event.c
>> index 9ed5a30..353e087 100644
>> --- a/tests/exynos/exynos_fimg2d_event.

Re: [PATCH v4 2/9] drm/exynos: ipp: Add IPP v2 framework

[Tobias Jakobi]

Dave Airlie wrote:
> On 23 October 2017 at 17:54, Marek Szyprowski  
> wrote:
>> This patch adds Exynos IPP v2 subsystem and userspace API.
>>
>> New userspace API is focused ONLY on memory-to-memory image processing.
>> The two remainging IPP operation modes (framebuffer writeback and
>> local-path output with image processing) can be implemented using
>> standard DRM features: writeback connectors and additional DRM planes with
>> scaling features.
>>
>> V2 IPP userspace API is not compatible with old IPP ioctls. This is a
>> significant change, but the old IPP subsystem in mainline Linux kernel was
>> partially disfunctional anyway and not used in any open-source project.
>>
>> V2 IPP userspace API is based on stateless approach, which much better fits
>> to memory-to-memory image processing model. It also provides support for
>> all image formats, which are both already defined in DRM API and supported
>> by the existing IPP hardware modules.
>>
>> The API consists of the following ioctls:
>> - DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
>>   processing modules,
>> - DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
>>   formats of given IPP module,
>> - DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
>>   selected image format of given IPP module,
>> - DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
>>   provided structures (source and destination buffers, operation rectangle,
>>   transformation, etc).
>>
>> The proposed userspace API is extensible. In the future more advanced image
>> processing operations can be defined to support for example blending.
>>
>> Userspace API is fully functional also on DRM render nodes, so it is not
>> limited to the root/privileged client.
>>
>> Internal driver API also has been completely rewritten. New IPP core
>> performs all possible input validation, checks and object life-time
>> control. The drivers can focus only on writing configuration to hardware
>> registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
>> the driver API. Minimal driver needs to provide a single callback for
>> starting processing and an array with supported image formats.
> 
> Is there userspace user for this? This is pretty significant
> driver-specific API addition.
> 
> The commit should contain pointers to a userspace project using this,
> or patches to one.
The pointers are in the cover letter of the series.

- Tobias

> Dave.
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Fix dma-buf import

[Tobias Jakobi]

Marek Szyprowski wrote:
> When IOMMU support was enabled, dma-buf import in Exynos DRM was broken
> since commit f43c35966a5a ("drm/exynos: use real device for DMA-mapping
> operations") due to using wrong struct device in drm_gem_prime_import()
> function. This patch fixes following kernel BUG caused by incorrect buffer
> mapping to DMA address space:
> 
> exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT occurred at 
> 0xb2e0
> [ cut here ]
> kernel BUG at drivers/iommu/exynos-iommu.c:449!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 4.14.0-rc4-next-20171016-00033-g990d723669fd #3165
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> task: c0e0b7c0 task.stack: c0e0
> PC is at exynos_sysmmu_irq+0x1d0/0x24c
> LR is at exynos_sysmmu_irq+0x154/0x24c
> [ cut here ]
Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>


- Tobias

> Reported-by: Marian Mihailescu <mihailesc...@gmail.com>
> Fixes: f43c35966a5a ("drm/exynos: use real device for DMA-mapping operations")
> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 6 ++
>  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 ++
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index e651a58c18cf..0822c5341ba4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -148,7 +148,7 @@ static struct drm_driver exynos_drm_driver = {
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_prime_export   = drm_gem_prime_export,
> - .gem_prime_import   = drm_gem_prime_import,
> + .gem_prime_import   = exynos_drm_gem_prime_import,
>   .gem_prime_get_sg_table = exynos_drm_gem_prime_get_sg_table,
>   .gem_prime_import_sg_table  = exynos_drm_gem_prime_import_sg_table,
>   .gem_prime_vmap = exynos_drm_gem_prime_vmap,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 077de014d610..ef35bc23bb36 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -506,6 +506,12 @@ int exynos_drm_gem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
>  }
>  
>  /* low-level interface prime helpers */
> +struct drm_gem_object *exynos_drm_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf)
> +{
> + return drm_gem_prime_import_dev(dev, dma_buf, to_dma_dev(dev));
> +}
> +
>  struct sg_table *exynos_drm_gem_prime_get_sg_table(struct drm_gem_object 
> *obj)
>  {
>   struct exynos_drm_gem *exynos_gem = to_exynos_gem(obj);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> index e86d1a9518c3..5a4c7de80f65 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> @@ -117,6 +117,8 @@ int exynos_drm_gem_fault(struct vm_fault *vmf);
>  int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
>  
>  /* low-level interface prime helpers */
> +struct drm_gem_object *exynos_drm_gem_prime_import(struct drm_device *dev,
> + struct dma_buf *dma_buf);
>  struct sg_table *exynos_drm_gem_prime_get_sg_table(struct drm_gem_object 
> *obj);
>  struct drm_gem_object *
>  exynos_drm_gem_prime_import_sg_table(struct drm_device *dev,
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/9] drm/exynos: fimc: Convert driver to IPP v2 core API

[Tobias Jakobi]

Marek Szyprowski wrote:
> This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
"DRM FIMC driver"

- Tobias


> The side effect of this conversion is a switch to driver component API
> to register properly in the Exynos DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/Kconfig   |   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c | 930 
> ++-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.h |  23 -
>  4 files changed, 282 insertions(+), 674 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 4bb9edb00601..33ef84be2d7f 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -99,7 +99,7 @@ config DRM_EXYNOS_IPP
>  
>  config DRM_EXYNOS_FIMC
>   bool "FIMC"
> - depends on BROKEN && MFD_SYSCON
> + select DRM_EXYNOS_IPP
>   help
> Choose this option if you want to use Exynos FIMC for DRM.
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 60ae6ae06eb2..4afeffa024f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -256,6 +256,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] 
> = {
>   DRV_PTR(g2d_driver, CONFIG_DRM_EXYNOS_G2D),
>   }, {
>   DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
> + DRM_COMPONENT_DRIVER | DRM_SHARED_DEVICE,
>   }, {
>   DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
>   DRM_COMPONENT_DRIVER
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 5b18b5c5fdf2..870f14b775b5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -12,6 +12,7 @@
>   *
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -24,8 +25,9 @@
>  #include 
>  #include "regs-fimc.h"
>  #include "exynos_drm_drv.h"
> +#include "exynos_drm_iommu.h"
>  #include "exynos_drm_ipp.h"
> -#include "exynos_drm_fimc.h"
> +
>  
>  /*
>   * FIMC stands for Fully Interactive Mobile Camera and
> @@ -33,23 +35,6 @@
>   * input DMA reads image data from the memory.
>   * output DMA writes image data to memory.
>   * FIMC supports image rotation and image effect functions.
> - *
> - * M2M operation : supports crop/scale/rotation/csc so on.
> - * Memory > FIMC H/W > Memory.
> - * Writeback operation : supports cloned screen with FIMD.
> - * FIMD > FIMC H/W > Memory.
> - * Output operation : supports direct display using local path.
> - * Memory > FIMC H/W > FIMD.
> - */
> -
> -/*
> - * TODO
> - * 1. check suspend/resume api if needed.
> - * 2. need to check use case platform_device_id.
> - * 3. check src/dst size with, height.
> - * 4. added check_prepare api for right register.
> - * 5. need to add supported list in prop_list.
> - * 6. check prescaler/scaler optimization.
>   */
>  
>  #define FIMC_MAX_DEVS4
> @@ -59,29 +44,15 @@
>  #define FIMC_BUF_STOP1
>  #define FIMC_BUF_START   2
>  #define FIMC_WIDTH_ITU_709   1280
> -#define FIMC_REFRESH_MAX 60
> -#define FIMC_REFRESH_MIN 12
> -#define FIMC_CROP_MAX8192
> -#define FIMC_CROP_MIN32
> -#define FIMC_SCALE_MAX   4224
> -#define FIMC_SCALE_MIN   32
> +#define FIMC_AUTOSUSPEND_DELAY   2000
>  
>  #define get_fimc_context(dev)
> platform_get_drvdata(to_platform_device(dev))
> -#define get_ctx_from_ippdrv(ippdrv)  container_of(ippdrv,\
> - struct fimc_context, ippdrv);
> -enum fimc_wb {
> - FIMC_WB_NONE,
> - FIMC_WB_A,
> - FIMC_WB_B,
> -};
>  
>  enum {
>   FIMC_CLK_LCLK,
>   FIMC_CLK_GATE,
>   FIMC_CLK_WB_A,
>   FIMC_CLK_WB_B,
> - FIMC_CLK_MUX,
> - FIMC_CLK_PARENT,
>   FIMC_CLKS_MAX
>  };
>  
> @@ -90,8 +61,6 @@ static const char * const fimc_clock_names[] = {
>   [FIMC_CLK_GATE]   = "fimc",
>   [FIMC_CLK_WB_A]   = "pxl_async0",
>   [FIMC_CLK_WB_B]   = "pxl_async1",
> - [FIMC_CLK_MUX]= "mux",
> - [FIMC_CLK_PARENT] = "parent",
>  };
>  
>  #define FIMC_DEFAULT_LCLK_FREQUENCY 13300UL
> @@ -141,31 +110,29 @@ struct fimc_capability {
>  /*
>   * A structure of fimc context.
>   *
> - * @ippdrv: prepare initialization using ippdrv.
>   * @regs_res: register resources.
>   * @regs: memory mapped io registers.
>   * @lock: locking of operations.
>   * @clocks: fimc clocks.
> - * @clk_frequency: LCLK clock frequency.
> - * @sysreg: handle to SYSREG block regmap.
>   * @sc: scaler infomations.
>   * @pol: porarity of writeback.
>   * @id: fimc id.
>   * @irq: irq number.
> - * @suspended: qos operations.
>   */
>  struct fimc_context {
> - struct 

Re: [PATCH v3 4/9] drm/exynos: gsc: Convert driver to IPP v2 core API

[Tobias Jakobi]

Hey Marek,


Marek Szyprowski wrote:
> This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
you probably mean "DRM gsc driver" here (or GSC, not sure about capitalisation).

- Tobias


> The side effect of this conversion is a switch to driver component API
> to register properly in the Exynos DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> Tested-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/Kconfig  |   3 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 995 
> ++--
>  drivers/gpu/drm/exynos/exynos_drm_gsc.h |  24 -
>  4 files changed, 315 insertions(+), 708 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index c10c9ca0d8b4..4bb9edb00601 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -111,7 +111,8 @@ config DRM_EXYNOS_ROTATOR
>  
>  config DRM_EXYNOS_GSC
>   bool "GScaler"
> - depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
> + depends on ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
> + select DRM_EXYNOS_IPP
>   help
> Choose this option if you want to use Exynos GSC for DRM.
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 3ade2b0ad15d..cac0d84385d3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -260,6 +260,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] 
> = {
>   DRM_COMPONENT_DRIVER
>   }, {
>   DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
> + DRM_COMPONENT_DRIVER
>   }, {
>   _drm_platform_driver,
>   DRM_VIRTUAL_DEVICE
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 0506b2b17ac1..f99d4fea9df1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -12,18 +12,20 @@
>   *
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
>  #include 
>  #include "regs-gsc.h"
>  #include "exynos_drm_drv.h"
> +#include "exynos_drm_iommu.h"
>  #include "exynos_drm_ipp.h"
> -#include "exynos_drm_gsc.h"
>  
>  /*
>   * GSC stands for General SCaler and
> @@ -31,26 +33,10 @@
>   * input DMA reads image data from the memory.
>   * output DMA writes image data to memory.
>   * GSC supports image rotation and image effect functions.
> - *
> - * M2M operation : supports crop/scale/rotation/csc so on.
> - * Memory > GSC H/W > Memory.
> - * Writeback operation : supports cloned screen with FIMD.
> - * FIMD > GSC H/W > Memory.
> - * Output operation : supports direct display using local path.
> - * Memory > GSC H/W > FIMD, Mixer.
>   */
>  
> -/*
> - * TODO
> - * 1. check suspend/resume api if needed.
> - * 2. need to check use case platform_device_id.
> - * 3. check src/dst size with, height.
> - * 4. added check_prepare api for right register.
> - * 5. need to add supported list in prop_list.
> - * 6. check prescaler/scaler optimization.
> - */
>  
> -#define GSC_MAX_DEVS 4
> +#define GSC_MAX_CLOCKS   8
>  #define GSC_MAX_SRC  4
>  #define GSC_MAX_DST  16
>  #define GSC_RESET_TIMEOUT50
> @@ -65,8 +51,6 @@
>  #define GSC_SC_DOWN_RATIO_4_8131072
>  #define GSC_SC_DOWN_RATIO_3_8174762
>  #define GSC_SC_DOWN_RATIO_2_8262144
> -#define GSC_REFRESH_MIN  12
> -#define GSC_REFRESH_MAX  60
>  #define GSC_CROP_MAX 8192
>  #define GSC_CROP_MIN 32
>  #define GSC_SCALE_MAX4224
> @@ -77,10 +61,9 @@
>  #define GSC_COEF_H_8T8
>  #define GSC_COEF_V_4T4
>  #define GSC_COEF_DEPTH   3
> +#define GSC_AUTOSUSPEND_DELAY2000
>  
>  #define get_gsc_context(dev) platform_get_drvdata(to_platform_device(dev))
> -#define get_ctx_from_ippdrv(ippdrv)  container_of(ippdrv,\
> - struct gsc_context, ippdrv);
>  #define gsc_read(offset) readl(ctx->regs + (offset))
>  #define gsc_write(cfg, offset)   writel(cfg, ctx->regs + (offset))
>  
> @@ -124,7 +107,6 @@ struct gsc_capability {
>  /*
>   * A structure of gsc context.
>   *
> - * @ippdrv: prepare initialization using ippdrv.
>   * @regs_res: register resources.
>   * @regs: memory mapped io registers.
>   * @sysreg: handle to SYSREG block regmap.
> @@ -137,12 +119,18 @@ struct gsc_capability {
>   * @suspended: qos operations.
>   */
>  struct gsc_context {
> - struct exynos_drm_ippdrvippdrv;
> + struct exynos_drm_ipp ipp;
> + struct drm_device *drm_dev;
> + struct device   *dev;
> + struct exynos_drm_ipp_task  *task;
> + struct 

Re: [PATCH v2 0/9] Exynos DRM: rewrite IPP subsystem and userspace API

[Tobias Jakobi]

Hello everyone,

I have finished some first (working) version of my mpv video backend for IPPv2.

You can find the tree here:
https://github.com/tobiasjakobi/mpv

I've also created some RFC pull request upstream, to get some input on the
current patches:
https://github.com/mpv-player/mpv/pull/4986

As you can see, a lot is currently missing, but at least the video presentation
(for YUV420) already works and shows good performance.

I have also cleaned up my ippv2 libdrm branch. Now it should just contain the
IPPv2 bits:
https://github.com/tobiasjakobi/libdrm/tree/ippv2

With best wishes,
Tobias



Marek Szyprowski wrote:
> Dear all,
> 
> This patchset performs complete rewrite of Exynos DRM IPP subsystem and
> its userspace API.
> 
> Why such rewrite is needed? Exynos DRM IPP API is over-engineered in
> general, but not really extensible on the other side. It is also buggy,
> with significant design flaws:
> - Userspace API covers memory-2-memory picture operations together with
>   CRTC writeback and duplicating features, which belongs to video plane.
> - Lack of support of the all required image formats (for example NV12
>   Samsung-tiled cannot be used due to lack of pixel format modifier
>   support).
> - Userspace API designed only to mimic hardware behaviour, not easy to
>   understand.
> - Lack of proper input validation in the core, drivers also didn't do that
>   correctly, so it was possible to set incorrect parameters and easil
>   trigger IOMMU fault or memory trash.
> - Drivers were partially disfunctional or supported only a subset of modes.
> 
> Due to the above limitations and issues the Exynos DRM IPP API was not
> used by any of the open-source projects. I assume that it is safe to remove
> this broken API without any damage to open-source community. All remaining
> users (mainly Tizen project related) will be updated to the new version.
> 
> This patchset changes Exynos DRM IPP subsystem to something useful. The
> userspace API is much simpler, state-less and easy to understand. Also
> the code of the core and driver is significantly smaller and easier to
> understand.
> 
> Patches were tested on Exynos4412 based Odroid U3 and Exynos5422
> Odroid XU3 boards, on top of Linux next-20170928 kernel.
> 
> Best regards
> Marek Szyprowski
> Samsung R Institute Poland
> 
> 
> Changelog:
> 
> v2:
> - fixed minor issues pointed by other developers:
>   * fixed possible null pointer dereferrence (Tobias)
>   * changed limits_size to limits_count (Tobias)
>   * renamed struct exynos_drm_ipp_format to drm_exynos_ipp_format (Andrzej)
>   * added proper return value from exynos_drm_ipp_get_res_ioctl when no IPP
> driver is present (Andrzej)
>   * properly aligned all uapi structures to be 32/64 bit safe (Emil)
>   * properly initialize all strucutres
> - added new Exynos Scaler driver from Andrzej Pietrasiewicz
> 
> v1: https://www.spinics.net/lists/linux-samsung-soc/msg60492.html
> - initial version of IPP v2
> 
> My previous works in this area:
> 
> "[RFC v2 0/2] Exynos DRM: add Picture Processor extension"
> https://www.spinics.net/lists/dri-devel/msg140669.html
> - removed usage of DRM objects and properties - replaced them with simple
>   list of parameters with predefined IDs
> 
> "[RFC 0/4] Exynos DRM: add Picture Processor extension"
> https://www.spinics.net/lists/linux-samsung-soc/msg59323.html
> - moved this feature from DRM core to Exynos DRM driver
> - changed name from framebuffer processor to picture processor
> - simplified code to cover only things needed by Exynos drivers
> - implemented simple fifo task scheduler
> - cleaned up rotator driver conversion (removed IPP remainings)
> 
> "[RFC 0/2] New feature: Framebuffer processors"
> https://www.spinics.net/lists/linux-samsung-soc/msg54810.html
> - generic approach implemented in DRM core, rejected
> 
> 
> Patch summary:
> 
> Andrzej Pietrasiewicz (3):
>   drm/exynos: Add driver for Exynos Scaler module
>   drivers: clk: samsung: Fix m2m scaler clock on Exynos542x
>   ARM: dts: exynos: Add mem-2-mem Scaler devices
> 
> Marek Szyprowski (6):
>   drm/exynos: ipp: Remove Exynos DRM IPP subsystem
>   drm/exynos: ipp: Add IPP v2 framework
>   drm/exynos: rotator: Convert driver to IPP v2 core API
>   drm/exynos: gsc: Convert driver to IPP v2 core API
>   drm/exynos: Add generic support for devices shared with V4L2 subsystem
>   drm/exynos: fimc: Convert driver to IPP v2 core API
> 
>  .../devicetree/bindings/gpu/samsung-scaler.txt |   25 +
>  arch/arm/boot/dts/exynos5420.dtsi  |   35 +
>  drivers/clk/samsung/clk-exynos5420.c   |2 +-
>  drivers/gpu/drm/exynos/Kconfig |   18 +-
>  drivers/gpu/drm/exynos/Makefile|1 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   36 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|5 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c   |  893 +++-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.h   

[PATCH libdrm] Add const qualifier to arguments of drmModeAddFB2()

[Tobias Jakobi]

Both drmModeAddFB2() and drmModeAddFB2WithModifiers() have some
arguments that are just pointers to uint32_t in disguise. These
are not modified (just copied) in the function, so we can add a
const qualifier here.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 xf86drmMode.c | 10 +-
 xf86drmMode.h | 11 ++-
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index d3bc20ea..2b3887b3 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -271,9 +271,9 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t height, 
uint8_t depth,
 }
 
 int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
-   uint32_t pixel_format, uint32_t bo_handles[4],
-   uint32_t pitches[4], uint32_t offsets[4],
-   uint64_t modifier[4], uint32_t *buf_id, 
uint32_t flags)
+   uint32_t pixel_format, const uint32_t 
bo_handles[4],
+   const uint32_t pitches[4], const uint32_t 
offsets[4],
+   const uint64_t modifier[4], uint32_t *buf_id, 
uint32_t flags)
 {
struct drm_mode_fb_cmd2 f;
int ret;
@@ -297,8 +297,8 @@ int drmModeAddFB2WithModifiers(int fd, uint32_t width, 
uint32_t height,
 }
 
 int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
-  uint32_t pixel_format, uint32_t bo_handles[4],
-  uint32_t pitches[4], uint32_t offsets[4],
+  uint32_t pixel_format, const uint32_t bo_handles[4],
+  const uint32_t pitches[4], const uint32_t offsets[4],
   uint32_t *buf_id, uint32_t flags)
 {
return drmModeAddFB2WithModifiers(fd, width, height,
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 5b390d9f..6dbe3353 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -369,15 +369,16 @@ extern int drmModeAddFB(int fd, uint32_t width, uint32_t 
height, uint8_t depth,
uint32_t *buf_id);
 /* ...with a specific pixel format */
 extern int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
-uint32_t pixel_format, uint32_t bo_handles[4],
-uint32_t pitches[4], uint32_t offsets[4],
+uint32_t pixel_format, const uint32_t bo_handles[4],
+const uint32_t pitches[4], const uint32_t offsets[4],
 uint32_t *buf_id, uint32_t flags);
 
 /* ...with format modifiers */
 int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height,
-  uint32_t pixel_format, uint32_t bo_handles[4],
-  uint32_t pitches[4], uint32_t offsets[4],
-  uint64_t modifier[4], uint32_t *buf_id, uint32_t 
flags);
+  uint32_t pixel_format, const uint32_t 
bo_handles[4],
+  const uint32_t pitches[4], const uint32_t 
offsets[4],
+  const uint64_t modifier[4], uint32_t *buf_id,
+  uint32_t flags);
 
 /**
  * Destroies the given framebuffer.
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/9] Exynos DRM: rewrite IPP subsystem and userspace API

[Tobias Jakobi]

Hello Marek,

I just tested this series, and I noticed a lot of these lines:
> exynos-sysmmu 11a4.sysmmu: restoring state
> exynos-sysmmu 11a4.sysmmu: saving state

I guess it would make sense to enable autosuspend for runtime PM in each of the
hw drivers.

I've just send a patch that does it for the FIMC (the only hw I can test this
on). This improves frame time stability for me.

With best wishes,
Tobias


Marek Szyprowski wrote:
> Dear all,
> 
> This patchset performs complete rewrite of Exynos DRM IPP subsystem and
> its userspace API.
> 
> Why such rewrite is needed? Exynos DRM IPP API is over-engineered in
> general, but not really extensible on the other side. It is also buggy,
> with significant design flaws:
> - Userspace API covers memory-2-memory picture operations together with
>   CRTC writeback and duplicating features, which belongs to video plane.
> - Lack of support of the all required image formats (for example NV12
>   Samsung-tiled cannot be used due to lack of pixel format modifier
>   support).
> - Userspace API designed only to mimic hardware behaviour, not easy to
>   understand.
> - Lack of proper input validation in the core, drivers also didn't do that
>   correctly, so it was possible to set incorrect parameters and easil
>   trigger IOMMU fault or memory trash.
> - Drivers were partially disfunctional or supported only a subset of modes.
> 
> Due to the above limitations and issues the Exynos DRM IPP API was not
> used by any of the open-source projects. I assume that it is safe to remove
> this broken API without any damage to open-source community. All remaining
> users (mainly Tizen project related) will be updated to the new version.
> 
> This patchset changes Exynos DRM IPP subsystem to something useful. The
> userspace API is much simpler, state-less and easy to understand. Also
> the code of the core and driver is significantly smaller and easier to
> understand.
> 
> Patches were tested on Exynos4412 based Odroid U3 and Exynos5422
> Odroid XU3 boards, on top of Linux next-20170928 kernel.
> 
> Best regards
> Marek Szyprowski
> Samsung R Institute Poland
> 
> 
> Changelog:
> 
> v2:
> - fixed minor issues pointed by other developers:
>   * fixed possible null pointer dereferrence (Tobias)
>   * changed limits_size to limits_count (Tobias)
>   * renamed struct exynos_drm_ipp_format to drm_exynos_ipp_format (Andrzej)
>   * added proper return value from exynos_drm_ipp_get_res_ioctl when no IPP
> driver is present (Andrzej)
>   * properly aligned all uapi structures to be 32/64 bit safe (Emil)
>   * properly initialize all strucutres
> - added new Exynos Scaler driver from Andrzej Pietrasiewicz
> 
> v1: https://www.spinics.net/lists/linux-samsung-soc/msg60492.html
> - initial version of IPP v2
> 
> My previous works in this area:
> 
> "[RFC v2 0/2] Exynos DRM: add Picture Processor extension"
> https://www.spinics.net/lists/dri-devel/msg140669.html
> - removed usage of DRM objects and properties - replaced them with simple
>   list of parameters with predefined IDs
> 
> "[RFC 0/4] Exynos DRM: add Picture Processor extension"
> https://www.spinics.net/lists/linux-samsung-soc/msg59323.html
> - moved this feature from DRM core to Exynos DRM driver
> - changed name from framebuffer processor to picture processor
> - simplified code to cover only things needed by Exynos drivers
> - implemented simple fifo task scheduler
> - cleaned up rotator driver conversion (removed IPP remainings)
> 
> "[RFC 0/2] New feature: Framebuffer processors"
> https://www.spinics.net/lists/linux-samsung-soc/msg54810.html
> - generic approach implemented in DRM core, rejected
> 
> 
> Patch summary:
> 
> Andrzej Pietrasiewicz (3):
>   drm/exynos: Add driver for Exynos Scaler module
>   drivers: clk: samsung: Fix m2m scaler clock on Exynos542x
>   ARM: dts: exynos: Add mem-2-mem Scaler devices
> 
> Marek Szyprowski (6):
>   drm/exynos: ipp: Remove Exynos DRM IPP subsystem
>   drm/exynos: ipp: Add IPP v2 framework
>   drm/exynos: rotator: Convert driver to IPP v2 core API
>   drm/exynos: gsc: Convert driver to IPP v2 core API
>   drm/exynos: Add generic support for devices shared with V4L2 subsystem
>   drm/exynos: fimc: Convert driver to IPP v2 core API
> 
>  .../devicetree/bindings/gpu/samsung-scaler.txt |   25 +
>  arch/arm/boot/dts/exynos5420.dtsi  |   35 +
>  drivers/clk/samsung/clk-exynos5420.c   |2 +-
>  drivers/gpu/drm/exynos/Kconfig |   18 +-
>  drivers/gpu/drm/exynos/Makefile|1 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|   36 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|5 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c   |  893 +++-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.h   |   23 -
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c|  853 ++--
>  drivers/gpu/drm/exynos/exynos_drm_gsc.h|   24 -
>  

[PATCH] drm/exynos: fimc: enable autosuspend for runtime PM

[Tobias Jakobi]

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 1c48c57381f1..bffb4b513453 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1009,7 +1009,8 @@ static irqreturn_t fimc_irq_handler(int irq, void *dev_id)
struct exynos_drm_ipp_task *task = ctx->task;
 
ctx->task = NULL;
-   pm_runtime_put(ctx->dev);
+   pm_runtime_mark_last_busy(ctx->dev);
+   pm_runtime_put_autosuspend(ctx->dev);
exynos_drm_ipp_task_done(task, 0);
}
 
@@ -1158,7 +1159,8 @@ static void fimc_abort(struct exynos_drm_ipp *ipp,
struct exynos_drm_ipp_task *task = ctx->task;
 
ctx->task = NULL;
-   pm_runtime_put(ctx->dev);
+   pm_runtime_mark_last_busy(ctx->dev);
+   pm_runtime_put_autosuspend(ctx->dev);
exynos_drm_ipp_task_done(task, -EIO);
}
 }
@@ -1329,6 +1331,8 @@ static int fimc_probe(struct platform_device *pdev)
spin_lock_init(>lock);
platform_set_drvdata(pdev, ctx);
 
+   pm_runtime_use_autosuspend(dev);
+   pm_runtime_set_autosuspend_delay(dev, 2000);
pm_runtime_enable(dev);
 
ret = component_add(dev, _component_ops);
@@ -1340,6 +1344,7 @@ static int fimc_probe(struct platform_device *pdev)
return 0;
 
 err_pm_dis:
+   pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
fimc_put_clocks(ctx);
 
@@ -1352,6 +1357,7 @@ static int fimc_remove(struct platform_device *pdev)
struct fimc_context *ctx = get_fimc_context(dev);
 
component_del(dev, _component_ops);
+   pm_runtime_dont_use_autosuspend(dev);
pm_runtime_disable(dev);
 
fimc_put_clocks(ctx);
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Exynos DRM: rewrite IPP subsystem and userspace API

[Tobias Jakobi]

Hello everyone,

just finished a first draft of the libdrm API and some test application:
https://github.com/tobiasjakobi/libdrm/blob/ippv2/exynos/exynos_ipp.h
https://github.com/tobiasjakobi/libdrm/blob/ippv2/tests/exynos/exynos_ipp_test.c

Needs a small patch to the kernel to prevent an Oops when a format has no 
limits.

Does not a lot atm. Just pretty-printing the information from the kernel driver
and testing a simple CSC queue.

Now looking to using this for the mpv vo backend.

With best wishes,
Tobias


P.S.: Output from my system below.

> exynos/ipp: 3 IPP modules found.
> IPP module number 0:
>   id = 0
>   supports crop
>   supports rotate
>   supports scale
>   supports convert
> a total of 15 formats are supported:
>   fourcc: XR24, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: RG24, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: RG16, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: NV12, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: NV16, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: NV21, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: NV61, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: UYVY, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: VYUY, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YUYV, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YVYU, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YU12, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YV12, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YU16, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YU24, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
> IPP module number 1:
>   id = 1
>   supports crop
>   supports rotate
>   supports scale
>   supports convert
> a total of 15 formats are supported:
>   fourcc: XR24, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: RG24, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: RG16, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: NV12, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: NV16, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: NV21, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: NV61, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: UYVY, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: VYUY, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YUYV, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YVYU, type: source+destination, modifier: 0x0
>   format has no source limits
>   format has no destination limits
>   fourcc: YU12, type: 

Re: [PATCH 2/6] drm/exynos: ipp: Add IPP v2 framework

[Tobias Jakobi]

Hello Marek,


Marek Szyprowski wrote:
> This patch adds Exynos IPP v2 subsystem and userspace API.
> 
> New userspace API is focused ONLY on memory-to-memory image processing.
> The two remainging IPP operation modes (framebuffer writeback and
> local-path output with image processing) can be implemented using
> standard DRM features: writeback connectors and additional DRM planes with
> scaling features.
> 
> V2 IPP userspace API is not compatible with old IPP ioctls. This is a
> significant change, but the old IPP subsystem in mainline Linux kernel was
> partially disfunctional anyway and not used in any open-source project.
> 
> V2 IPP userspace API is based on stateless approach, which much better fits
> to memory-to-memory image processing model. It also provides support for
> all image formats, which are both already defined in DRM API and supported
> by the existing IPP hardware modules.
> 
> The API consists of the following ioctls:
> - DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
>   processing modules,
> - DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
>   formats of given IPP module,
> - DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
>   selected image format of given IPP module,
> - DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
>   provided structures (source and destination buffers, operation rectangle,
>   transformation, etc).
> 
> The proposed userspace API is extensible. In the future more advanced image
> processing operations can be defined to support for example blending.
> 
> Userspace API is fully functional also on DRM render nodes, so it is not
> limited to the root/privileged client.
> 
> Internal driver API also has been completely rewritten. New IPP core
> performs all possible input validation, checks and object life-time
> control. The drivers can focus only on writing configuration to hardware
> registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
> the driver API. Minimal driver needs to provide a single callback for
> starting processing and an array with supported image formats.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/Kconfig  |   3 +
>  drivers/gpu/drm/exynos/Makefile |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   9 +
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 893 
> 
>  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 188 +++
>  include/uapi/drm/exynos_drm.h   | 227 
>  6 files changed, 1321 insertions(+)
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h
> 
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 88cff0e039b6..2e097a81df12 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -94,6 +94,9 @@ config DRM_EXYNOS_G2D
>   help
> Choose this option if you want to use Exynos G2D for DRM.
>  
> +config DRM_EXYNOS_IPP
> + bool
> +
>  config DRM_EXYNOS_FIMC
>   bool "FIMC"
>   depends on BROKEN && MFD_SYSCON
> diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
> index 09bb002c9555..f663490e949d 100644
> --- a/drivers/gpu/drm/exynos/Makefile
> +++ b/drivers/gpu/drm/exynos/Makefile
> @@ -17,6 +17,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)+= 
> exynos_mixer.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)  += exynos_hdmi.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)  += exynos_drm_vidi.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)   += exynos_drm_g2d.o
> +exynosdrm-$(CONFIG_DRM_EXYNOS_IPP)   += exynos_drm_ipp.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)  += exynos_drm_fimc.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)   += exynos_drm_rotator.o
>  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)   += exynos_drm_gsc.o
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 7f19054ebce3..645046c5943a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -26,6 +26,7 @@
>  #include "exynos_drm_fb.h"
>  #include "exynos_drm_gem.h"
>  #include "exynos_drm_plane.h"
> +#include "exynos_drm_ipp.h"
>  #include "exynos_drm_vidi.h"
>  #include "exynos_drm_g2d.h"
>  #include "exynos_drm_iommu.h"
> @@ -114,6 +115,14 @@ static void exynos_drm_lastclose(struct drm_device *dev)
>   DRM_AUTH | DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
>   DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES, 
> exynos_drm_ipp_get_res_ioctl,
> + DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_CAPS, exynos_drm_ipp_get_caps_ioctl,
> + DRM_AUTH | DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_LIMITS, 
> 

Re: [PATCH 0/6] Exynos DRM: rewrite IPP subsystem and userspace API

[Tobias Jakobi]

Hey Marek,

first of all thanks for keeping this series alive. Looks pretty good so far.

I have started to rewrite my IPP userspace API in libdrm and when this is done,
I'm going to adapt my mpv video backend to it.

With best wishes,
Tobias



Marek Szyprowski wrote:
> Dear all,
> 
> This patchset performs complete rewrite of Exynos DRM IPP subsystem and
> its userspace API.
> 
> Why such rewrite is needed? Exynos DRM IPP API is over-engineered in
> general, but not really extensible on the other side. It is also buggy,
> with significant design flaws:
> - Userspace API covers memory-2-memory picture operations together with
>   CRTC writeback and duplicating features, which belongs to video plane.
> - Lack of support of the all required image formats (for example NV12
>   Samsung-tiled cannot be used due to lack of pixel format modifier
>   support).
> - Userspace API designed only to mimic hardware behaviour, not easy to
>   understand.
> - Lack of proper input validation in the core, drivers also didn't do that
>   correctly, so it was possible to set incorrect parameters and easil
>   trigger IOMMU fault or memory trash.
> - Drivers were partially disfunctional or supported only a subset of modes.
> 
> Due to the above limitations and issues the Exynos DRM IPP API was not
> used by any of the open-source projects. I assume that it is safe to remove
> this broken API without any damage to open-source community. All remaining
> users (mainly Tizen project related) will be updated to the new version.
> 
> This patchset changes Exynos DRM IPP subsystem to something useful. The
> userspace API is much simpler, state-less and easy to understand. Also
> the code of the core and driver is significantly smaller and easier to
> understand.
> 
> Patches were tested on Exynos4412 based Odroid U3 and Exynos5422
> Odroid XU3 boards, on top of Linux next-20170911 kernel.
> 
> Best regards
> Marek Szyprowski
> Samsung R Institute Poland
> 
> 
> My previous works in this area:
> 
> "[RFC v2 0/2] Exynos DRM: add Picture Processor extension"
> https://www.spinics.net/lists/dri-devel/msg140669.html
> - removed usage of DRM objects and properties - replaced them with simple
>   list of parameters with predefined IDs
> 
> "[RFC 0/4] Exynos DRM: add Picture Processor extension"
> https://www.spinics.net/lists/linux-samsung-soc/msg59323.html
> - moved this feature from DRM core to Exynos DRM driver
> - changed name from framebuffer processor to picture processor
> - simplified code to cover only things needed by Exynos drivers
> - implemented simple fifo task scheduler
> - cleaned up rotator driver conversion (removed IPP remainings)
> 
> "[RFC 0/2] New feature: Framebuffer processors"
> https://www.spinics.net/lists/linux-samsung-soc/msg54810.html
> - generic approach implemented in DRM core, rejected
> 
> 
> Patch summary:
> 
> Marek Szyprowski (6):
>   drm/exynos: ipp: Remove Exynos DRM IPP subsystem
>   drm/exynos: ipp: Add IPP v2 framework
>   drm/exynos: rotator: Convert driver to IPP v2 core API
>   drm/exynos: gsc: Convert driver to IPP v2 core API
>   drm/exynos: Add generic support for devices shared with V4L2 subsystem
>   drm/exynos: fimc: Convert driver to IPP v2 core API
> 
>  drivers/gpu/drm/exynos/Kconfig  |   12 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   33 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |4 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  893 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimc.h|   23 -
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |  853 +++---
>  drivers/gpu/drm/exynos/exynos_drm_gsc.h |   24 -
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 2239 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.h |  352 ++---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  735 ++---
>  drivers/gpu/drm/exynos/exynos_drm_rotator.h |   19 -
>  include/uapi/drm/exynos_drm.h   |  315 ++--
>  12 files changed, 1627 insertions(+), 3875 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/10] drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> Since HDMI can handle these modes despite of MIXER limitations lets
> enable them.
lets --> let's

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 5aae82b..108dccb 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1014,6 +1014,9 @@ static int mixer_mode_valid(struct exynos_drm_crtc 
> *crtc,
>   (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
>   return MODE_OK;
>  
> + if ((w == 1024 && h == 768) || (w == 1280 && h == 1024))
> + return MODE_OK;
> +
>   return MODE_BAD;
>  }
>  
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/10] drm/exynos/mixer: move resolution configuration to single function

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> Screen resolution configuration depends on HW version, let put it into
> single function to make it consistent and simplify the code.
"...let's put it into..."

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index ae89e53..a87f60b 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -367,7 +367,7 @@ static void mixer_vsync_set_update(struct mixer_context 
> *ctx, bool enable)
>   VP_SHADOW_UPDATE_ENABLE : 0);
>  }
>  
> -static void mixer_cfg_scan(struct mixer_context *ctx, unsigned int height)
> +static void mixer_cfg_scan(struct mixer_context *ctx, int width, int height)
>  {
>   struct mixer_resources *res = >mixer_res;
>   u32 val;
> @@ -376,7 +376,11 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
> unsigned int height)
>   val = test_bit(MXR_BIT_INTERLACE, >flags) ?
>   MXR_CFG_SCAN_INTERLACE : MXR_CFG_SCAN_PROGRESSIVE;
>  
> - if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184) {
> + mixer_reg_write(>mixer_res, MXR_RESOLUTION,
> + MXR_MXR_RES_HEIGHT(height) | MXR_MXR_RES_WIDTH(width));
> + } else {
>   /* choosing between proper HD and SD mode */
>   if (height <= 480)
>   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> @@ -482,14 +486,7 @@ static void mixer_commit(struct mixer_context *ctx)
>   else
>   __clear_bit(MXR_BIT_INTERLACE, >flags);
>  
> - /* setup display size */
> - if (ctx->mxr_ver == MXR_VER_128_0_0_184) {
> - u32 val  = MXR_MXR_RES_HEIGHT(mode->vdisplay)
> -  | MXR_MXR_RES_WIDTH(mode->hdisplay);
> - mixer_reg_write(>mixer_res, MXR_RESOLUTION, val);
> - }
> -
> - mixer_cfg_scan(ctx, mode->vdisplay);
> + mixer_cfg_scan(ctx, mode->hdisplay, mode->vdisplay);
>   mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
>   mixer_run(ctx);
>  }
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/10] drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> crtc::mode_fixup callback is required by crtcs which use internally
> different mode than requested by user - case of Exynos Mixer.
"...which internally use a different..."


Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

With one suggestion below.


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 +++
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |  3 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 6ce0821..dc01342 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -95,8 +95,23 @@ static enum drm_mode_status exynos_crtc_mode_valid(struct 
> drm_crtc *crtc,
>   return MODE_OK;
>  }
>  
> +static bool exynos_crtc_mode_fixup(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> +
> + if (exynos_crtc->ops->mode_fixup)
> + return exynos_crtc->ops->mode_fixup(exynos_crtc, mode,
> + adjusted_mode);
> +
> + return true;
> +}
> +
> +
>  static const struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
>   .mode_valid = exynos_crtc_mode_valid,
> + .mode_fixup = exynos_crtc_mode_fixup,
>   .atomic_check   = exynos_crtc_atomic_check,
>   .atomic_begin   = exynos_crtc_atomic_begin,
>   .atomic_flush   = exynos_crtc_atomic_flush,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index cf131c2..e8bcc72 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -136,6 +136,9 @@ struct exynos_drm_crtc_ops {
>   u32 (*get_vblank_counter)(struct exynos_drm_crtc *crtc);
>   enum drm_mode_status (*mode_valid)(struct exynos_drm_crtc *crtc,
>   const struct drm_display_mode *mode);
> + bool (*mode_fixup)(struct exynos_drm_crtc *crtc,
> +const struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode);
I'm always wary when I encounter a bool as return value, since to check what
true/false actually encodes, I need to have some reference which I can check.
Just go for an integer here and use standard convention that negative values are
errors?



>   int (*atomic_check)(struct exynos_drm_crtc *crtc,
>   struct drm_crtc_state *state);
>   void (*atomic_begin)(struct exynos_drm_crtc *crtc);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/10] drm/exynos/mixer: pass actual mode on MIXER to encoder

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> MIXER in SoCs prior to Exynos5420 supports only 4 video modes:
> 720x480, 720x576, 1280x720, 1920x1080. Support for other modes can be
> enabled by manipulating timings of HDMI. To allow it MIXER must pass
> actual video mode to HDMI, the proper way to do it is to modify
> adjusted_mode property in crtc::mode_fixup callback. Adding such callback
> allows also to simplify mixer_cfg_scan code - choosing mode is performed
> already in crtc::mode_fixup. mode_fixup is also better place to check
> interlace flag.

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 70 
> +--
>  1 file changed, 50 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index f6ea9d9..5aae82b 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -115,6 +115,7 @@ struct mixer_context {
>   struct clk  *sclk_hdmi;
>   struct clk  *mout_mixer;
>   enum mixer_version_id   mxr_ver;
> + int scan_value;
>  };
>  
>  struct mixer_drv_data {
> @@ -367,23 +368,11 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
> int width, int height)
>   val = test_bit(MXR_BIT_INTERLACE, >flags) ?
>   MXR_CFG_SCAN_INTERLACE : MXR_CFG_SCAN_PROGRESSIVE;
>  
> - /* setup display size */
> - if (ctx->mxr_ver == MXR_VER_128_0_0_184) {
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184)
>   mixer_reg_write(ctx, MXR_RESOLUTION,
>   MXR_MXR_RES_HEIGHT(height) | MXR_MXR_RES_WIDTH(width));
> - } else {
> - /* choosing between proper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - }
> + else
> + val |= ctx->scan_value;
>  
>   mixer_reg_writemask(ctx, MXR_CFG, val, MXR_CFG_SCAN_MASK);
>  }
> @@ -467,11 +456,6 @@ static void mixer_commit(struct mixer_context *ctx)
>  {
>   struct drm_display_mode *mode = >crtc->base.state->adjusted_mode;
>  
> - if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> - __set_bit(MXR_BIT_INTERLACE, >flags);
> - else
> - __clear_bit(MXR_BIT_INTERLACE, >flags);
> -
>   mixer_cfg_scan(ctx, mode->hdisplay, mode->vdisplay);
>   mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
>   mixer_run(ctx);
> @@ -1033,6 +1017,51 @@ static int mixer_mode_valid(struct exynos_drm_crtc 
> *crtc,
>   return MODE_BAD;
>  }
>  
> +static bool mixer_mode_fixup(struct exynos_drm_crtc *crtc,
> +const struct drm_display_mode *mode,
> +struct drm_display_mode *adjusted_mode)
> +{
> + struct mixer_context *ctx = crtc->ctx;
> + int width = mode->hdisplay, height = mode->vdisplay, i;
> +
> + struct {
> + int hdisplay, vdisplay, htotal, vtotal, scan_val;
> + } static const modes[] = {
> + { 720, 480, 858, 525, MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD },
> + { 720, 576, 864, 625, MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD },
> + { 1280, 720, 1650, 750, MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD },
> + { 1920, 1080, 2200, 1125, MXR_CFG_SCAN_HD_1080 | 
> MXR_CFG_SCAN_HD }
> + };
> +
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + __set_bit(MXR_BIT_INTERLACE, >flags);
> + else
> + __clear_bit(MXR_BIT_INTERLACE, >flags);
> +
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return true;
> +
> + for (i = 0; i < ARRAY_SIZE(modes); ++i)
> + if (width <= modes[i].hdisplay && height <= modes[i].vdisplay) {
> + ctx->scan_value = modes[i].scan_val;
> + if (width < modes[i].hdisplay ||
> + height < modes[i].vdisplay) {
> + adjusted_mode->hdisplay = modes[i].hdisplay;
> +

Re: [PATCH 09/10] drm/exynos/hdmi: quirk for support mode timings conversion

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> MIXER in SoCs prior to Exynos5420 supports only 4 video modes:
> 720x480, 720x576, 1280x720, 1920x1080. Support for other modes
> can be enabled by manipulating timings of HDMI. To do it
> adjusted_mode should contain actual mode set on crtc.
> With this patch it is possible to enable 1024x768 and 1280x1024
> modes in MIXER.

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

And some question below.


> Suggested-by: Daniel Drake <dr...@endlessm.com>
> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 7225b65..4b081f6 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1239,6 +1239,17 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
> *hdata)
>  static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
>  {
>   struct drm_display_mode *m = >encoder.crtc->state->mode;
> + struct drm_display_mode *am = 
> >encoder.crtc->state->adjusted_mode;
> + int hquirk = 0;
> +
> + /*
> +  * In case video mode coming from CRTC differs from requested one HDMI
> +  * sometimes is able to almost properly perform conversion - only
> +  * first line is distorted.
> +  */
> + if ((m->vdisplay != am->vdisplay) &&
> + (m->hdisplay == 1280 || m->hdisplay == 1024))
> + hquirk = 258;
Can it even happen, that m->hdisplay is neither 1280 nor 1024 but "m->vdisplay
!= am->vdisplay" still holds?



>   hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
>   hdmi_reg_writev(hdata, HDMI_V_LINE_0, 2, m->vtotal);
> @@ -1332,8 +1343,8 @@ static void hdmi_v14_mode_apply(struct hdmi_context 
> *hdata)
>   hdmi_reg_writev(hdata, HDMI_V_SYNC_LINE_AFT_PXL_6_0, 2, 0x);
>  
>   hdmi_reg_writev(hdata, HDMI_TG_H_FSZ_L, 2, m->htotal);
> - hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay);
> - hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay);
> + hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay - 
> hquirk);
> + hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay + hquirk);
>   hdmi_reg_writev(hdata, HDMI_TG_V_FSZ_L, 2, m->vtotal);
>   if (hdata->drv_data == _hdmi_driver_data)
>   hdmi_reg_writeb(hdata, HDMI_TG_DECON_EN, 1);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/10] drm/exynos/mixer: abstract out output mode setup code

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> Mode setup code is called from video plane update and mixer plane update.
> Lets group it together in mixer_commit function like in case of other
> Exynos CRTCs.
Minor typo: Lets --> Let's

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

With some small question below.


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 ++---
>  1 file changed, 18 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 0027554..499ebdc 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -473,6 +473,22 @@ static void mixer_stop(struct mixer_context *ctx)
>   usleep_range(1, 12000);
>  }
>  
> +static void mixer_commit(struct mixer_context *ctx)
> +{
> + struct drm_display_mode *mode = >crtc->base.state->adjusted_mode;
> +
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184) {
> + u32 val  = MXR_MXR_RES_HEIGHT(mode->vdisplay)
> +  | MXR_MXR_RES_WIDTH(mode->hdisplay);
> + mixer_reg_write(>mixer_res, MXR_RESOLUTION, val);
> + }
> +
> + mixer_cfg_scan(ctx, mode->vdisplay);
> + mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
> + mixer_run(ctx);
> +}
> +
>  static void vp_video_buffer(struct mixer_context *ctx,
>   struct exynos_drm_plane *plane)
>  {
> @@ -553,11 +569,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   vp_reg_write(res, VP_TOP_C_PTR, chroma_addr[0]);
>   vp_reg_write(res, VP_BOT_C_PTR, chroma_addr[1]);
>  
> - mixer_cfg_scan(ctx, mode->vdisplay);
> - mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
>   mixer_cfg_layer(ctx, plane->index, priority, true);
>   mixer_cfg_vp_blend(ctx);
> - mixer_run(ctx);
> + mixer_commit(ctx);
>  
>   spin_unlock_irqrestore(>reg_slock, flags);
>  
> @@ -638,14 +652,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
>   mixer_reg_write(res, MXR_GRAPHIC_SPAN(win),
>   fb->pitches[0] / fb->format->cpp[0]);
>  
> - /* setup display size */
> - if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> - win == DEFAULT_WIN) {
> - val  = MXR_MXR_RES_HEIGHT(mode->vdisplay);
> - val |= MXR_MXR_RES_WIDTH(mode->hdisplay);
> - mixer_reg_write(res, MXR_RESOLUTION, val);
> - }
> -
>   val  = MXR_GRP_WH_WIDTH(state->src.w);
>   val |= MXR_GRP_WH_HEIGHT(state->src.h);
>   val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -660,18 +666,15 @@ static void mixer_graph_buffer(struct mixer_context 
> *ctx,
>   /* set buffer address to mixer */
>   mixer_reg_write(res, MXR_GRAPHIC_BASE(win), dma_addr);
>  
> - mixer_cfg_scan(ctx, mode->vdisplay);
> - mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
>   mixer_cfg_layer(ctx, win, priority, true);
>   mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->format->format));
> + mixer_commit(ctx);
With this change, mixer_run() is now done before mixer_layer_update(). I just
wanted to make sure that the order of operations isn't critical here.



>   /* layer update mandatory for mixer 16.0.33.0 */
>   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
>   ctx->mxr_ver == MXR_VER_128_0_0_184)
>   mixer_layer_update(ctx);
>  
> - mixer_run(ctx);
> -
>   spin_unlock_irqrestore(>reg_slock, flags);
>  
>   mixer_regs_dump(ctx);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/10] drm/exynos/mixer: move mode commit to enable callback

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> Mode commit should not be called for every plane separately. It is enough
> to call it once in enable callback. The change requires also that
> interlace check should be moved to mixer_commit. It should be done in
> the same patch to avoid regression.
"...also requires that the interlace check is moved to..."


Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 499ebdc..ae89e53 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -477,6 +477,11 @@ static void mixer_commit(struct mixer_context *ctx)
>  {
>   struct drm_display_mode *mode = >crtc->base.state->adjusted_mode;
>  
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + __set_bit(MXR_BIT_INTERLACE, >flags);
> + else
> + __clear_bit(MXR_BIT_INTERLACE, >flags);
> +
>   /* setup display size */
>   if (ctx->mxr_ver == MXR_VER_128_0_0_184) {
>   u32 val  = MXR_MXR_RES_HEIGHT(mode->vdisplay)
> @@ -494,7 +499,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
>  {
>   struct exynos_drm_plane_state *state =
>   to_exynos_plane_state(plane->base.state);
> - struct drm_display_mode *mode = >base.crtc->state->adjusted_mode;
>   struct mixer_resources *res = >mixer_res;
>   struct drm_framebuffer *fb = state->base.fb;
>   unsigned int priority = state->base.normalized_zpos + 1;
> @@ -509,8 +513,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
>   chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
>  
> - if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
> - __set_bit(MXR_BIT_INTERLACE, >flags);
> + if (test_bit(MXR_BIT_INTERLACE, >flags)) {
>   if (is_tiled) {
>   luma_addr[1] = luma_addr[0] + 0x40;
>   chroma_addr[1] = chroma_addr[0] + 0x40;
> @@ -519,7 +522,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
>   chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
>   }
>   } else {
> - __clear_bit(MXR_BIT_INTERLACE, >flags);
>   luma_addr[1] = 0;
>   chroma_addr[1] = 0;
>   }
> @@ -571,7 +573,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
>  
>   mixer_cfg_layer(ctx, plane->index, priority, true);
>   mixer_cfg_vp_blend(ctx);
> - mixer_commit(ctx);
>  
>   spin_unlock_irqrestore(>reg_slock, flags);
>  
> @@ -591,7 +592,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
>  {
>   struct exynos_drm_plane_state *state =
>   to_exynos_plane_state(plane->base.state);
> - struct drm_display_mode *mode = >base.crtc->state->adjusted_mode;
>   struct mixer_resources *res = >mixer_res;
>   struct drm_framebuffer *fb = state->base.fb;
>   unsigned int priority = state->base.normalized_zpos + 1;
> @@ -637,11 +637,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
>   + (state->src.x * fb->format->cpp[0])
>   + (state->src.y * fb->pitches[0]);
>  
> - if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> - __set_bit(MXR_BIT_INTERLACE, >flags);
> - else
> - __clear_bit(MXR_BIT_INTERLACE, >flags);
> -
>   spin_lock_irqsave(>reg_slock, flags);
>  
>   /* setup format */
> @@ -668,7 +663,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
>  
>   mixer_cfg_layer(ctx, win, priority, true);
>   mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->format->format));
> - mixer_commit(ctx);
>  
>   /* layer update mandatory for mixer 16.0.33.0 */
>   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> @@ -1021,6 +1015,8 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
>   }
>   mixer_win_reset(ctx);
>  
> + mixer_commit(ctx);
> +
>   mixer_vsync_set_update(ctx, true);
>  
>   set_bit(MXR_BIT_POWERED, >flags);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/10] drm/exynos/mixer: fix mode validation code

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> Mode limitation checked in mixer driver affects only older HW.
> Mixer in Exynos542x has no such limitations. While at it patch changes
> validation callback to recently introduced mode_valid which is more
> suitable for the check. Additionally little cleanup is performed.

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

And some small suggestion below.


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index a87f60b..d530c18 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1040,26 +1040,24 @@ static void mixer_disable(struct exynos_drm_crtc 
> *crtc)
>   clear_bit(MXR_BIT_POWERED, >flags);
>  }
>  
> -/* Only valid for Mixer version 16.0.33.0 */
> -static int mixer_atomic_check(struct exynos_drm_crtc *crtc,
> -struct drm_crtc_state *state)
> +static int mixer_mode_valid(struct exynos_drm_crtc *crtc,
> + const struct drm_display_mode *mode)
>  {
> - struct drm_display_mode *mode = >adjusted_mode;
> - u32 w, h;
> + struct mixer_context *ctx = crtc->ctx;
> + u32 w = mode->hdisplay, h = mode->vdisplay;
>  
> - w = mode->hdisplay;
> - h = mode->vdisplay;
> + DRM_DEBUG_KMS("xres=%d, yres=%d, refresh=%d, intl=%d\n", w, h,
> + mode->vrefresh, !!(mode->flags & DRM_MODE_FLAG_INTERLACE));
>  
> - DRM_DEBUG_KMS("xres=%d, yres=%d, refresh=%d, intl=%d\n",
> - mode->hdisplay, mode->vdisplay, mode->vrefresh,
> - (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return MODE_OK;
>  
>   if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>   (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
>   (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
I think it would be nice to have these aligned.


> - return 0;
> + return MODE_OK;
>  
> - return -EINVAL;
> + return MODE_BAD;
>  }
>  
>  static const struct exynos_drm_crtc_ops mixer_crtc_ops = {
> @@ -1071,7 +1069,7 @@ static const struct exynos_drm_crtc_ops mixer_crtc_ops 
> = {
>   .update_plane   = mixer_update_plane,
>   .disable_plane  = mixer_disable_plane,
>   .atomic_flush   = mixer_atomic_flush,
> - .atomic_check   = mixer_atomic_check,
> + .mode_valid = mixer_mode_valid,
>  };
>  
>  static const struct mixer_drv_data exynos5420_mxr_drv_data = {
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/10] drm/exynos/hdmi: remove redundant mode field

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> Display mode is preserved in CRTC state, there is no need to keep local
> copy of it. Moreover since HDMI should configure registers according to
> requested mode, use it instead of adjusted_mode, which should contain
> mode produced by CRTC - functionally it does not change anything, but
> subsequent patches will make the difference.

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 34 +-
>  1 file changed, 9 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 214fa5e..7225b65 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -119,7 +119,6 @@ struct hdmi_context {
>   boolpowered;
>   booldvi_mode;
>   struct delayed_work hotplug_work;
> - struct drm_display_mode current_mode;
>   struct cec_notifier *notifier;
>   const struct hdmi_driver_data   *drv_data;
>  
> @@ -770,6 +769,7 @@ static int hdmi_clk_set_parents(struct hdmi_context 
> *hdata, bool to_phy)
>  
>  static void hdmi_reg_infoframes(struct hdmi_context *hdata)
>  {
> + struct drm_display_mode *m = >encoder.crtc->state->mode;
>   union hdmi_infoframe frm;
>   u8 buf[25];
>   int ret;
> @@ -783,8 +783,7 @@ static void hdmi_reg_infoframes(struct hdmi_context 
> *hdata)
>   return;
>   }
>  
> - ret = drm_hdmi_avi_infoframe_from_display_mode(,
> - >current_mode, false);
> + ret = drm_hdmi_avi_infoframe_from_display_mode(, m, false);
>   if (!ret)
>   ret = hdmi_avi_infoframe_pack(, buf, sizeof(buf));
>   if (ret > 0) {
> @@ -794,8 +793,7 @@ static void hdmi_reg_infoframes(struct hdmi_context 
> *hdata)
>   DRM_INFO("%s: invalid AVI infoframe (%d)\n", __func__, ret);
>   }
>  
> - ret = drm_hdmi_vendor_infoframe_from_display_mode(,
> - >current_mode);
> + ret = drm_hdmi_vendor_infoframe_from_display_mode(, m);
>   if (!ret)
>   ret = hdmi_vendor_infoframe_pack(, buf,
>   sizeof(buf));
> @@ -1088,9 +1086,10 @@ static void hdmi_audio_control(struct hdmi_context 
> *hdata, bool onoff)
>  
>  static void hdmi_start(struct hdmi_context *hdata, bool start)
>  {
> + struct drm_display_mode *m = >encoder.crtc->state->mode;
>   u32 val = start ? HDMI_TG_EN : 0;
>  
> - if (hdata->current_mode.flags & DRM_MODE_FLAG_INTERLACE)
> + if (m->flags & DRM_MODE_FLAG_INTERLACE)
>   val |= HDMI_FIELD_EN;
>  
>   hdmi_reg_writemask(hdata, HDMI_CON_0, val, HDMI_EN);
> @@ -1160,7 +1159,7 @@ static void hdmiphy_wait_for_pll(struct hdmi_context 
> *hdata)
>  
>  static void hdmi_v13_mode_apply(struct hdmi_context *hdata)
>  {
> - struct drm_display_mode *m = >current_mode;
> + struct drm_display_mode *m = >encoder.crtc->state->mode;
>   unsigned int val;
>  
>   hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
> @@ -1239,7 +1238,7 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
> *hdata)
>  
>  static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
>  {
> - struct drm_display_mode *m = >current_mode;
> + struct drm_display_mode *m = >encoder.crtc->state->mode;
>  
>   hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
>   hdmi_reg_writev(hdata, HDMI_V_LINE_0, 2, m->vtotal);
> @@ -1372,10 +1371,11 @@ static void hdmiphy_enable_mode_set(struct 
> hdmi_context *hdata, bool enable)
>  
>  static void hdmiphy_conf_apply(struct hdmi_context *hdata)
>  {
> + struct drm_display_mode *m = >encoder.crtc->state->mode;
>   int ret;
>   const u8 *phy_conf;
>  
> - ret = hdmi_find_phy_conf(hdata, hdata->current_mode.clock * 1000);
> + ret = hdmi_find_phy_conf(hdata, m->clock * 1000);
>   if (ret < 0) {
>   DRM_ERROR("failed to find hdmiphy conf\n");
>   return;
> @@ -1407,21 +1407,6 @@ static void hdmi_conf_apply(struct hdmi_context *hdata)
>   hdmi_audio_control(hdata, true);
>  }
>  
> -static void hdmi_mode_set(struct drm_encoder *encoder,
> -   struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode)
> -{
&

Re: [PATCH 05/10] drm/exynos/mixer: remove mixer_resources sub-structure

[Tobias Jakobi]

Hello Andrzej,

Andrzej Hajda wrote:
> mixer_resources adds only unnecessary redirection, removing it makes the
> code shorter and cleaner.

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>


> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 323 
> --
>  1 file changed, 147 insertions(+), 176 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index d530c18..f6ea9d9 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -67,19 +67,6 @@
>  #define MXR_FORMAT_ARGB  6
>  #define MXR_FORMAT_ARGB  7
>  
> -struct mixer_resources {
> - int irq;
> - void __iomem*mixer_regs;
> - void __iomem*vp_regs;
> - spinlock_t  reg_slock;
> - struct clk  *mixer;
> - struct clk  *vp;
> - struct clk  *hdmi;
> - struct clk  *sclk_mixer;
> - struct clk  *sclk_hdmi;
> - struct clk  *mout_mixer;
> -};
> -
>  enum mixer_version_id {
>   MXR_VER_0_0_0_16,
>   MXR_VER_16_0_33_0,
> @@ -117,7 +104,16 @@ struct mixer_context {
>   struct exynos_drm_plane planes[MIXER_WIN_NR];
>   unsigned long   flags;
>  
> - struct mixer_resources  mixer_res;
> + int irq;
> + void __iomem*mixer_regs;
> + void __iomem*vp_regs;
> + spinlock_t  reg_slock;
> + struct clk  *mixer;
> + struct clk  *vp;
> + struct clk  *hdmi;
> + struct clk  *sclk_mixer;
> + struct clk  *sclk_hdmi;
> + struct clk  *mout_mixer;
>   enum mixer_version_id   mxr_ver;
>  };
>  
> @@ -194,44 +190,44 @@ static inline bool is_alpha_format(unsigned int 
> pixel_format)
>   }
>  }
>  
> -static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
> +static inline u32 vp_reg_read(struct mixer_context *ctx, u32 reg_id)
>  {
> - return readl(res->vp_regs + reg_id);
> + return readl(ctx->vp_regs + reg_id);
>  }
>  
> -static inline void vp_reg_write(struct mixer_resources *res, u32 reg_id,
> +static inline void vp_reg_write(struct mixer_context *ctx, u32 reg_id,
>u32 val)
>  {
> - writel(val, res->vp_regs + reg_id);
> + writel(val, ctx->vp_regs + reg_id);
>  }
>  
> -static inline void vp_reg_writemask(struct mixer_resources *res, u32 reg_id,
> +static inline void vp_reg_writemask(struct mixer_context *ctx, u32 reg_id,
>u32 val, u32 mask)
>  {
> - u32 old = vp_reg_read(res, reg_id);
> + u32 old = vp_reg_read(ctx, reg_id);
>  
>   val = (val & mask) | (old & ~mask);
> - writel(val, res->vp_regs + reg_id);
> + writel(val, ctx->vp_regs + reg_id);
>  }
>  
> -static inline u32 mixer_reg_read(struct mixer_resources *res, u32 reg_id)
> +static inline u32 mixer_reg_read(struct mixer_context *ctx, u32 reg_id)
>  {
> - return readl(res->mixer_regs + reg_id);
> + return readl(ctx->mixer_regs + reg_id);
>  }
>  
> -static inline void mixer_reg_write(struct mixer_resources *res, u32 reg_id,
> +static inline void mixer_reg_write(struct mixer_context *ctx, u32 reg_id,
>u32 val)
>  {
> - writel(val, res->mixer_regs + reg_id);
> + writel(val, ctx->mixer_regs + reg_id);
>  }
>  
> -static inline void mixer_reg_writemask(struct mixer_resources *res,
> +static inline void mixer_reg_writemask(struct mixer_context *ctx,
>u32 reg_id, u32 val, u32 mask)
>  {
> - u32 old = mixer_reg_read(res, reg_id);
> + u32 old = mixer_reg_read(ctx, reg_id);
>  
>   val = (val & mask) | (old & ~mask);
> - writel(val, res->mixer_regs + reg_id);
> + writel(val, ctx->mixer_regs + reg_id);
>  }
>  
>  static void mixer_regs_dump(struct mixer_context *ctx)
> @@ -239,7 +235,7 @@ static void mixer_regs_dump(struct mixer_context *ctx)
>  #define DUMPREG(reg_id) \
>  do { \
>   DRM_DEBUG_KMS(#reg_id " = %08x\n", \
> - (u32)readl(ctx->mixer_res.mixer_regs + reg_id)); \
> + (u32)readl(ctx->mixer_regs + reg_id)); \
>  } while (0)
>  
>   DUMPREG(MXR_STATUS);
> @@ -271,7 +267,7 @@ static void vp_regs_dump(struct mixer_context *ctx)
>  #define DUMPREG(reg_id) \
>  do { \
>

[PATCH] drm/exynos/hdmi: add 85.5MHz pixel clock for v14 HDMI PHY

[Tobias Jakobi]

From: Daniel Drake <dr...@endlessm.com>

Configuration details from Samsung. This enables 1366x768@60Hz,
which also needs the 257px timing hack to work around a mixer
limitation.

Signed-off-by: Daniel Drake <dr...@endlessm.com>
Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 9 +
 drivers/gpu/drm/exynos/exynos_mixer.c | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2b14cc7def6f..adc69331dafe 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -298,6 +298,15 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = 
{
},
},
{
+   .pixel_clock = 8550,
+   .conf = {
+   0x01, 0xd1, 0x24, 0x11, 0x40, 0x40, 0xd0, 0x08,
+   0x84, 0xa0, 0xd6, 0xd8, 0x45, 0xa0, 0xac, 0x80,
+   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
+   0x54, 0x90, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
.pixel_clock = 10650,
.conf = {
0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 96c3f61f080e..1dd65e261385 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1127,6 +1127,7 @@ static int mixer_atomic_check(struct exynos_drm_crtc 
*crtc,
 
/* Check against some specific resolutions. */
if ((w == 1024 && h == 768) ||
+   (w == 1366 && h == 768) ||
(w == 1280 && h == 1024))
return 0;
 
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/10] drm/exynos: TV path improvements

[Tobias Jakobi]

Hello Andrzej,

just did a quick test and looks good so far. One thing I noticed is that
compared to Daniel's approach you just manipulate HDMI_TG_HACT_{ST,SZ}_L,
instead of HDMI_TG_VACT_SZ_L + HDMI_TG_HACT_{ST,SZ}_L. I just wanted to make
sure that on the HDMI level, this does the same thing?

I'll try to do a proper review tomorrow.

I also noticed that I have another patch by Daniel in my tree, which, together
with the quirk, enables 1366x768@60Hz. Going to send it shortly, since it could
probably go along with this series.

With best wishes,
Tobias



Andrzej Hajda wrote:
> Hi all,
> 
> This patchset does two main things:
> - removes mode limitation for Exynos542x chips, multiple modes were filtered
>   out due to lack of HW version checking code,
> - enables two modes on older chips, thanks to quirk found by Daniel Drake,
>   and published by Tobias Jakobi [1][2].
> Beside this it consolidates the code and performs multiple cleanups.
> 
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg24617.html
> [2]: https://www.spinics.net/lists/dri-devel/msg150906.html
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (10):
>   drm/exynos/mixer: abstract out output mode setup code
>   drm/exynos/mixer: move mode commit to enable callback
>   drm/exynos/mixer: move resolution configuration to single function
>   drm/exynos/mixer: fix mode validation code
>   drm/exynos/mixer: remove mixer_resources sub-structure
>   drm/exynos/hdmi: remove redundant mode field
>   drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops
>   drm/exynos/mixer: pass actual mode on MIXER to encoder
>   drm/exynos/hdmi: quirk for support mode timings conversion
>   drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes
> 
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |  15 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   3 +
>  drivers/gpu/drm/exynos/exynos_hdmi.c |  49 ++--
>  drivers/gpu/drm/exynos/exynos_mixer.c| 452 
> +++
>  4 files changed, 265 insertions(+), 254 deletions(-)
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 6/9] drm/exynos: introduce BYTE_PITCH capability

[Tobias Jakobi]

Hello Marek,

first of all thanks for checking this!


Marek Szyprowski wrote:
> Hi Tobias,
> 
> On 2017-08-22 16:19, Tobias Jakobi wrote:
>> In some of subdrivers we compute something like 'pitch / cpp' at some
>> point, silently assuming that the pitch (which is in bytes) is
>> divisible by the buffer's cpp. This must not be true, in particular
>> it depends on the underlying hardware.
>>
>> If userspace should request such a setup, we should communicate this.
>>
>> Introduce a new cap which indicates that the hardware supports a
>> pitch with 'byte-granularity'. If the cap is not set, assume that
>> we need a pitch aligned to cpp.
>>
>> We set this cap in a later patch for the drivers/planes which
>> support it.
>>
>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> 
> I briefly checked the patch and it looks fine, but I really wonder whether
> drivers should support such strange formats, when pitches are not multiple
> of pixel size in bytes. I cannot find any sane use case for such formats.
Apparantly the hw can do it, so why not support it? A potential use case I see
would be an application that uses a single buffer with multiple pixelformats.

Let buffer-size = width * height * sizeof(uint16_t), with width odd. Then the
buffer pitch is not divisible by 4. In case the hw supports it, we can still use
e.g. XRGB with this setup.


> Maybe it would make sense to add a check for it in DRM core? I also didn't
> notice a check for that in any other drivers, but some of them also
> compute 'pitch / cpp' values.
I thought about some check in DRM core, but I didn't see a clean way to add it,
since the behaviour very much depends on the hw.  Well, except if you just want
to enforce 'pitch % cpp == 0' everywhere. Not sure how the rest of the DRM folks
thinks about it.

With best wishes,
Tobias



>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
>>   drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
>>   2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 43afab4bebc3..ec32632485d2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -92,6 +92,7 @@ struct exynos_drm_plane {
>>   #define EXYNOS_DRM_PLANE_CAP_SCALE(1 << 1)
>>   #define EXYNOS_DRM_PLANE_CAP_ZPOS(1 << 2)
>>   #define EXYNOS_DRM_PLANE_CAP_TILE(1 << 3)
>> +#define EXYNOS_DRM_PLANE_CAP_BYTE_PITCH(1 << 4)
>> /*
>>* Exynos DRM plane configuration structure.
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> index 133af72f5c90..17e47b8f0d6a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> @@ -185,6 +185,16 @@ exynos_drm_plane_check_format(const struct
>> exynos_drm_plane_config *config,
>>   {
>>   struct drm_framebuffer *fb = state->base.fb;
>>   +/*
>> + * Some blocks only allow to specify a buffer pitch in terms
>> + * of pixels. In these cases, we need to ensure that the pitch
>> + * provided by userspace is divisible by the cpp.
>> + */
>> +if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_BYTE_PITCH)) {
>> +if (fb->pitches[0] % fb->format->cpp[0])
>> +return -ENOTSUPP;
>> +}
>> +
>>   switch (fb->modifier) {
>>   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
>>   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
> 
> Best regards

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 1/1] drm/exynos/hdmi: add 257px offset timing hack

[Tobias Jakobi]

From: Daniel Drake <dr...@endlessm.com>

As discussed in
http://www.spinics.net/lists/linux-samsung-soc/msg24617.html
the 1024x768 timings don't quite work out of the box, for unknown reasons.

However, massaging of the values in the way implemented in this patch
makes the system usable, although it is missing the top row of pixels,
and the rightmost column too.

Apply the timing hack to both 1280x1024 and 1024x768.

Signed-off-by: Daniel Drake <dr...@endlessm.com>
Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 16 
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d5e923452121..2b14cc7def6f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1241,6 +1241,14 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
*hdata)
 static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
 {
struct drm_display_mode *m = >current_mode;
+   int hcorrect = 0;
+   int vcorrect = 0;
+
+   if ((m->hdisplay == 1024 && m->vdisplay == 768) ||
+   (m->hdisplay == 1280 && m->vdisplay == 1024)) {
+   hcorrect = 257;
+   vcorrect = 1;
+   }
 
hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
hdmi_reg_writev(hdata, HDMI_V_LINE_0, 2, m->vtotal);
@@ -1306,8 +1314,8 @@ static void hdmi_v14_mode_apply(struct hdmi_context 
*hdata)
hdmi_reg_writev(hdata, HDMI_V_SYNC_LINE_AFT_PXL_2_0, 2, 0x);
hdmi_reg_writev(hdata, HDMI_V_SYNC_LINE_AFT_PXL_1_0, 2, 0x);
hdmi_reg_writev(hdata, HDMI_TG_VACT_ST_L, 2,
-   m->vtotal - m->vdisplay);
-   hdmi_reg_writev(hdata, HDMI_TG_VACT_SZ_L, 2, m->vdisplay);
+   (m->vtotal - m->vdisplay) - vcorrect);
+   hdmi_reg_writev(hdata, HDMI_TG_VACT_SZ_L, 2, m->vdisplay + 
vcorrect);
}
 
hdmi_reg_writev(hdata, HDMI_H_SYNC_START_0, 2,
@@ -1334,8 +1342,8 @@ static void hdmi_v14_mode_apply(struct hdmi_context 
*hdata)
hdmi_reg_writev(hdata, HDMI_V_SYNC_LINE_AFT_PXL_6_0, 2, 0x);
 
hdmi_reg_writev(hdata, HDMI_TG_H_FSZ_L, 2, m->htotal);
-   hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay);
-   hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay);
+   hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, (m->htotal - m->hdisplay) 
- hcorrect);
+   hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay + hcorrect);
hdmi_reg_writev(hdata, HDMI_TG_V_FSZ_L, 2, m->vtotal);
if (hdata->drv_data == _hdmi_driver_data)
hdmi_reg_writeb(hdata, HDMI_TG_DECON_EN, 1);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 600b4de45c51..96c3f61f080e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1119,11 +1119,17 @@ static int mixer_atomic_check(struct exynos_drm_crtc 
*crtc,
mode->hdisplay, mode->vdisplay, mode->vrefresh,
(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
 
+   /* Check against resolution ranges. */
if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
(w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
(w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
return 0;
 
+   /* Check against some specific resolutions. */
+   if ((w == 1024 && h == 768) ||
+   (w == 1280 && h == 1024))
+   return 0;
+
return -EINVAL;
 }
 
-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/1] drm/exynos: hack to support more HDMI resolutions

[Tobias Jakobi]

Hello,

I was asked by a user of my kernel tree to try to upstream this. The patch is 
originally by Daniel who figured out this peculiar behaviour of the HDMI block.

Since this is clearly a hack, should it even be upstreamed?

Some more questions/thoughts:
- I know that it works for the HDMI block on the Exynos4412, but I guess it 
could also work for other Exynos SoCs. So this would require some testing by 
someone who has access to other boards.
- Currently the manipulation in hdmi_v14_mode_apply() is always active. Once we 
figure out for which hw the hack works, we could probably set a flag somewhere.
- Same goes for mixer_atomic_check() which now always accepts 1024x768 and 
1280x1024. This should also depend on a flag (maybe some CRTC flag).

Feedback would be appreciated!

With best wishes,
Tobias

Daniel Drake (1):
  drm/exynos/hdmi: add 257px offset timing hack

 drivers/gpu/drm/exynos/exynos_hdmi.c  | 16 
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++
 2 files changed, 18 insertions(+), 4 deletions(-)

-- 
2.13.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/9] drm/exynos: misc fixes and more

[Tobias Jakobi]

Inki Dae wrote:
> Hi Tobias,
> 
> Regarding below two patches, I'd like to have more review so I will consider 
> to merge them in next turn. Sorry for this.
Thanks, calling out to potential reviewers then :-)

- Tobias


>   drm/exynos: introduce BYTE_PITCH capability
>   drm/exynos: add BYTE_PITCH cap for all supported planes
> 
> Thanks,
> Inki Dae
> 
> 2017년 08월 22일 23:19에 Tobias Jakobi 이(가) 쓴 글:
>> Hello,
>>
>> this is the second iteration of [1], with the following changes:
>> - split patch 3/8 (suggested by Inki)
>> - zero init registers in patch 4/8 (suggested by Inki)
>> - rephrased commit description of patch 5/8 to make it more
>>   clear that this behaviour depends on the hw
>> - replace zero with linear modifier in patch 2/8
>>
>>
>> Summary:
>> (a) Enables support for NV12MT in the mixer.
>> (b) Sanitizes buffer pitch for HW with restrictions.
>> (c) Misc fixes
>>
>> With best wishes,
>> Tobias
>>
>> [1] https://www.spinics.net/lists/linux-samsung-soc/msg60235.html
>>
>>
>> Tobias Jakobi (9):
>>   drm/exynos: mixer: fix chroma comment in vp_video_buffer()
>>   drm/exynos: mixer: enable NV12MT support for the video plane
>>   drm/exynos: mixer: simplify vp_video_buffer()
>>   drm/exynos: mixer: simplify mixer_graph_buffer()
>>   drm/exynos: mixer: remove src offset from mixer_graph_buffer()
>>   drm/exynos: introduce BYTE_PITCH capability
>>   drm/exynos: add BYTE_PITCH cap for all supported planes
>>   drm/exynos: consistent use of cpp
>>   drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers
>>
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 17 +-
>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 13 +++-
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 ++
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 17 --
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 +
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 48 
>> +--
>>  7 files changed, 75 insertions(+), 61 deletions(-)
>>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/10] drm/exynos/decon5433: use readl_poll_timeout helpers

[Tobias Jakobi]

Tobias Jakobi wrote:
> Hello Andrzej,
> 
> 
> Andrzej Hajda wrote:
>> Linux core provide helpers for polling with timeout, lets use them.
>>
>> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
>> ---
>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20 
>>  1 file changed, 8 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> index 5792ca88..237b4c9 100644
>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -407,24 +408,19 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
>> *crtc)
>>  
>>  static void decon_swreset(struct decon_context *ctx)
>>  {
>> -unsigned int tries;
>>  unsigned long flags;
>> +u32 val;
>> +int ret;
>>  
>>  writel(0, ctx->addr + DECON_VIDCON0);
>> -for (tries = 2000; tries; --tries) {
>> -if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_STOP_STATUS)
>> -break;
>> -udelay(10);
>> -}
>> +readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
>> +   ~val & VIDCON0_STOP_STATUS, 12, 2);
> Wouldn't it be more consistent to also check for a timeout here?
I see! Thanks for the clarification.

- Tobias


> With best wishes,
> Tobias
> 
> 
> 
>>  writel(VIDCON0_SWRESET, ctx->addr + DECON_VIDCON0);
>> -for (tries = 2000; tries; --tries) {
>> -if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_SWRESET)
>> -break;
>> -udelay(10);
>> -}
>> +ret = readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
>> + ~val & VIDCON0_SWRESET, 12, 2);
>>  
>> -WARN(tries == 0, "failed to software reset DECON\n");
>> +WARN(ret < 0, "failed to software reset DECON\n");
>>  
>>  spin_lock_irqsave(>vblank_lock, flags);
>>  ctx->frame_id = 0;
>>
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 01/10] drm/exynos/decon5433: use readl_poll_timeout helpers

[Tobias Jakobi]

Hello Andrzej,


Andrzej Hajda wrote:
> Linux core provide helpers for polling with timeout, lets use them.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 5792ca88..237b4c9 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -407,24 +408,19 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
> *crtc)
>  
>  static void decon_swreset(struct decon_context *ctx)
>  {
> - unsigned int tries;
>   unsigned long flags;
> + u32 val;
> + int ret;
>  
>   writel(0, ctx->addr + DECON_VIDCON0);
> - for (tries = 2000; tries; --tries) {
> - if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_STOP_STATUS)
> - break;
> - udelay(10);
> - }
> + readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
> +~val & VIDCON0_STOP_STATUS, 12, 2);
Wouldn't it be more consistent to also check for a timeout here?

With best wishes,
Tobias



>   writel(VIDCON0_SWRESET, ctx->addr + DECON_VIDCON0);
> - for (tries = 2000; tries; --tries) {
> - if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_SWRESET)
> - break;
> - udelay(10);
> - }
> + ret = readl_poll_timeout(ctx->addr + DECON_VIDCON0, val,
> +  ~val & VIDCON0_SWRESET, 12, 2);
>  
> - WARN(tries == 0, "failed to software reset DECON\n");
> + WARN(ret < 0, "failed to software reset DECON\n");
>  
>   spin_lock_irqsave(>vblank_lock, flags);
>   ctx->frame_id = 0;
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 9/9] drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

[Tobias Jakobi]

DRM core already checks the validity of the pixelformat.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 8 +---
 3 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 66ceca0af2a0..3dfba34be24d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -277,13 +277,11 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_ARGB:
+   default:
val |= WINCONx_BPPMODE_32BPP_A;
val |= WINCONx_WSWP_F | WINCONx_BLD_PIX_F | WINCONx_ALPHA_SEL_F;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_ERROR("Proper pixel format is not set\n");
-   return;
}
 
DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 4662d55ed988..615efcf7782a 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -309,16 +309,11 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_BGRA:
+   default:
val |= WINCONx_BPPMODE_32BPP_BGRA | WINCONx_BLD_PIX |
WINCONx_ALPHA_SEL;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_DEBUG_KMS("invalid pixel size so using unpacked 24bpp.\n");
-
-   val |= WINCONx_BPPMODE_24BPP_xRGB;
-   val |= WINCONx_BURSTLEN_16WORD;
-   break;
}
 
DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9b83d1846589..91c62e7afdd5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -583,18 +583,12 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx, 
unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_ARGB:
+   default:
val |= WINCON1_BPPMODE_25BPP_A1888
| WINCON1_BLD_PIX | WINCON1_ALPHA_SEL;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_DEBUG_KMS("invalid pixel size so using unpacked 24bpp.\n");
-
-   val |= WINCON0_BPPMODE_24BPP_888;
-   val |= WINCONx_WSWP;
-   val |= WINCONx_BURSTLEN_16WORD;
-   break;
}
 
/*
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 8/9] drm/exynos: consistent use of cpp

[Tobias Jakobi]

A recent commit (272725c7db4da1fd3229d944fc76d2e98e3a144e) has removed
the use of 'bits_per_pixel' in DRM. However the corresponding Exynos
driver code still uses the ambiguous 'bpp', even though it is now
initialized from fb->cpp[0].

Consistenly use 'cpp' in FIMD, DECON7 and DECON5433 drivers.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12 ++--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  6 +++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 62b50e0685b0..66ceca0af2a0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -286,7 +286,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
return;
}
 
-   DRM_DEBUG_KMS("bpp = %u\n", fb->format->cpp[0] * 8);
+   DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -329,7 +329,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
struct decon_context *ctx = crtc->ctx;
struct drm_framebuffer *fb = state->base.fb;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
u32 val;
@@ -365,11 +365,11 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));
 
if (!(ctx->out_type & IFTYPE_HDMI))
-   val = BIT_VAL(pitch - state->crtc.w * bpp, 27, 14)
-   | BIT_VAL(state->crtc.w * bpp, 13, 0);
+   val = BIT_VAL(pitch - state->crtc.w * cpp, 27, 14)
+   | BIT_VAL(state->crtc.w * cpp, 13, 0);
else
-   val = BIT_VAL(pitch - state->crtc.w * bpp, 29, 15)
-   | BIT_VAL(state->crtc.w * bpp, 14, 0);
+   val = BIT_VAL(pitch - state->crtc.w * cpp, 29, 15)
+   | BIT_VAL(state->crtc.w * cpp, 14, 0);
writel(val, ctx->addr + DECON_VIDW0xADD2(win));
 
decon_win_set_pixfmt(ctx, win, fb);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3e88269fdc2e..4662d55ed988 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -321,7 +321,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
break;
}
 
-   DRM_DEBUG_KMS("bpp = %d\n", fb->format->cpp[0] * 8);
+   DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -398,7 +398,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int last_x;
unsigned int last_y;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
 
if (ctx->suspended)
@@ -418,7 +418,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
val = (unsigned long)exynos_drm_fb_dma_addr(fb, 0);
writel(val, ctx->regs + VIDW_BUF_START(win));
 
-   padding = (pitch / bpp) - fb->width;
+   padding = (pitch / cpp) - fb->width;
 
/* buffer size */
writel(fb->width + padding, ctx->regs + VIDW_WHOLE_X(win));
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e88597f6d356..9b83d1846589 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -718,13 +718,13 @@ static void fimd_update_plane(struct exynos_drm_crtc 
*crtc,
unsigned long val, size, offset;
unsigned int last_x, last_y, buf_offsize, line_size;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
 
if (ctx->suspended)
return;
 
-   offset = state->src.x * bpp;
+   offset = state->src.x * cpp;
offset += state->src.y * pitch;
 
/* buffer start address */
@@ -743,8 +743,8 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
state->crtc.w, state->crtc.h);
 
/* buffer size */
-   buf_offsize = pitch 

[PATCH v2 7/9] drm/exynos: add BYTE_PITCH cap for all supported planes

[Tobias Jakobi]

Both FIMD and DECON5433 support a pitch in bytes.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5792ca88ab7a..62b50e0685b0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -546,6 +546,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[win].num_pixel_formats = ARRAY_SIZE(decon_formats);
ctx->configs[win].zpos = win;
ctx->configs[win].type = decon_win_types[tmp];
+   ctx->configs[win].capabilities = 
EXYNOS_DRM_PLANE_CAP_BYTE_PITCH;
 
ret = exynos_plane_init(drm_dev, >planes[win], win,
>configs[win]);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 60f93cad6643..e88597f6d356 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -986,6 +986,7 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[i].num_pixel_formats = ARRAY_SIZE(fimd_formats);
ctx->configs[i].zpos = i;
ctx->configs[i].type = fimd_win_types[i];
+   ctx->configs[i].capabilities = EXYNOS_DRM_PLANE_CAP_BYTE_PITCH;
ret = exynos_plane_init(drm_dev, >planes[i], i,
>configs[i]);
if (ret)
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/9] drm/exynos: introduce BYTE_PITCH capability

[Tobias Jakobi]

In some of subdrivers we compute something like 'pitch / cpp' at some
point, silently assuming that the pitch (which is in bytes) is
divisible by the buffer's cpp. This must not be true, in particular
it depends on the underlying hardware.

If userspace should request such a setup, we should communicate this.

Introduce a new cap which indicates that the hardware supports a
pitch with 'byte-granularity'. If the cap is not set, assume that
we need a pitch aligned to cpp.

We set this cap in a later patch for the drivers/planes which
support it.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 43afab4bebc3..ec32632485d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -92,6 +92,7 @@ struct exynos_drm_plane {
 #define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
 #define EXYNOS_DRM_PLANE_CAP_ZPOS  (1 << 2)
 #define EXYNOS_DRM_PLANE_CAP_TILE  (1 << 3)
+#define EXYNOS_DRM_PLANE_CAP_BYTE_PITCH(1 << 4)
 
 /*
  * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 133af72f5c90..17e47b8f0d6a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -185,6 +185,16 @@ exynos_drm_plane_check_format(const struct 
exynos_drm_plane_config *config,
 {
struct drm_framebuffer *fb = state->base.fb;
 
+   /*
+* Some blocks only allow to specify a buffer pitch in terms
+* of pixels. In these cases, we need to ensure that the pitch
+* provided by userspace is divisible by the cpp.
+*/
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_BYTE_PITCH)) {
+   if (fb->pitches[0] % fb->format->cpp[0])
+   return -ENOTSUPP;
+   }
+
switch (fb->modifier) {
case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 5/9] drm/exynos: mixer: remove src offset from mixer_graph_buffer()

[Tobias Jakobi]

We always translate the dma address such that the offsets of
the source image are zero. Hence we can remove manipulation of
the MXR_GRAPHIC_SXY(win) register and just zero them once
in mixer_win_reset().

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8d68de85bada..a540e50ceadc 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -584,7 +584,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
unsigned long flags;
unsigned int win = plane->index;
unsigned int x_ratio = 0, y_ratio = 0;
-   unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
+   unsigned int dst_x_offset, dst_y_offset;
dma_addr_t dma_addr;
unsigned int fmt;
u32 val;
@@ -618,12 +618,10 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
dst_x_offset = state->crtc.x;
dst_y_offset = state->crtc.y;
 
-   /* converting dma address base and source offset */
+   /* translate dma address base s.t. the source image offset is zero */
dma_addr = exynos_drm_fb_dma_addr(fb, 0)
+ (state->src.x * fb->format->cpp[0])
+ (state->src.y * fb->pitches[0]);
-   src_x_offset = 0;
-   src_y_offset = 0;
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
__set_bit(MXR_BIT_INTERLACE, >flags);
@@ -654,11 +652,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
val |= MXR_GRP_WH_V_SCALE(y_ratio);
mixer_reg_write(res, MXR_GRAPHIC_WH(win), val);
 
-   /* setup offsets in source image */
-   val  = MXR_GRP_SXY_SX(src_x_offset);
-   val |= MXR_GRP_SXY_SY(src_y_offset);
-   mixer_reg_write(res, MXR_GRAPHIC_SXY(win), val);
-
/* setup offsets in display image */
val  = MXR_GRP_DXY_DX(dst_x_offset);
val |= MXR_GRP_DXY_DY(dst_y_offset);
@@ -735,6 +728,10 @@ static void mixer_win_reset(struct mixer_context *ctx)
if (test_bit(MXR_BIT_VP_ENABLED, >flags))
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);
 
+   /* set all source image offsets to zero */
+   mixer_reg_write(res, MXR_GRAPHIC_SXY(0), 0);
+   mixer_reg_write(res, MXR_GRAPHIC_SXY(1), 0);
+
spin_unlock_irqrestore(>reg_slock, flags);
 }
 
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/9] drm/exynos: mixer: simplify mixer_graph_buffer()

[Tobias Jakobi]

DRM core already checks in drm_atomic_plane_check() if the
pixelformat is valid. Hence we can collapse the default case
of the switch statement with the XRGB case.

No functional change.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index beef4d6c41ca..8d68de85bada 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -606,12 +606,9 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
 
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+   default:
fmt = MXR_FORMAT_ARGB;
break;
-
-   default:
-   DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
-   return;
}
 
/* ratio is already checked by common plane code */
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/9] drm/exynos: mixer: simplify vp_video_buffer()

[Tobias Jakobi]

DRM core already checks in drm_atomic_plane_check() if the
pixelformat is valid. Hence we can drop the default case of
the switch statement and collapse most of the code.

Also rename the two booleans to reflect what true/false
actually means, and to avoid mixing CrCb/NV21 descriptions.

No functional change.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4c894d97aba3..beef4d6c41ca 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -484,32 +484,18 @@ static void vp_video_buffer(struct mixer_context *ctx,
unsigned int priority = state->base.normalized_zpos + 1;
unsigned long flags;
dma_addr_t luma_addr[2], chroma_addr[2];
-   bool tiled_mode = false;
-   bool crcb_mode = false;
+   bool is_tiled, is_nv21;
u32 val;
 
-   switch (fb->format->format) {
-   case DRM_FORMAT_NV12:
-   crcb_mode = false;
-   break;
-   case DRM_FORMAT_NV21:
-   crcb_mode = true;
-   break;
-   default:
-   DRM_ERROR("pixel format for vp is wrong [%d].\n",
-   fb->format->format);
-   return;
-   }
-
-   if (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
-   tiled_mode = true;
+   is_nv21 = (fb->format->format == DRM_FORMAT_NV21);
+   is_tiled = (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE);
 
luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
__set_bit(MXR_BIT_INTERLACE, >flags);
-   if (tiled_mode) {
+   if (is_tiled) {
luma_addr[1] = luma_addr[0] + 0x40;
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
@@ -529,8 +515,8 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_writemask(res, VP_MODE, val, VP_MODE_LINE_SKIP);
 
/* setup format */
-   val = (crcb_mode ? VP_MODE_NV21 : VP_MODE_NV12);
-   val |= (tiled_mode ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
+   val = (is_nv21 ? VP_MODE_NV21 : VP_MODE_NV12);
+   val |= (is_tiled ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
vp_reg_writemask(res, VP_MODE, val, VP_MODE_FMT_MASK);
 
/* setting size of input image */
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/9] drm/exynos: mixer: enable NV12MT support for the video plane

[Tobias Jakobi]

The video processor supports a tiled version of the NV12 format,
known as NV12MT in V4L2 terms. The support was removed in commit
083500baefd5f4c215a5a93aef2492c1aa775828 due to not being a real
pixel format, but rather NV12 with a special memory layout.

With the introduction of FB modifiers, we can now properly support
this format again.

Tested with a hacked up modetest from libdrm's test suite on
an ODROID-X2 (Exynos4412).

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 27 +++
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 +-
 4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a93de321706b..43afab4bebc3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -91,6 +91,7 @@ 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_TILE  (1 << 3)
 
 /*
  * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 73217c281c9a..a958818d552b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -250,4 +250,6 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
 
dev->mode_config.funcs = _drm_mode_config_funcs;
dev->mode_config.helper_private = _drm_mode_config_helpers;
+
+   dev->mode_config.allow_fb_modifiers = true;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 611b6fd65433..133af72f5c90 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -180,6 +180,29 @@ static struct drm_plane_funcs exynos_plane_funcs = {
 };
 
 static int
+exynos_drm_plane_check_format(const struct exynos_drm_plane_config *config,
+ struct exynos_drm_plane_state *state)
+{
+   struct drm_framebuffer *fb = state->base.fb;
+
+   switch (fb->modifier) {
+   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
+   return -ENOTSUPP;
+   break;
+
+   case DRM_FORMAT_MOD_LINEAR:
+   break;
+
+   default:
+   DRM_ERROR("unsupported pixel format modifier");
+   return -ENOTSUPP;
+   }
+
+   return 0;
+}
+
+static int
 exynos_drm_plane_check_size(const struct exynos_drm_plane_config *config,
struct exynos_drm_plane_state *state)
 {
@@ -223,6 +246,10 @@ static int exynos_plane_atomic_check(struct drm_plane 
*plane,
/* translate state into exynos_state */
exynos_plane_mode_set(exynos_state);
 
+   ret = exynos_drm_plane_check_format(exynos_plane->config, exynos_state);
+   if (ret)
+   return ret;
+
ret = exynos_drm_plane_check_size(exynos_plane->config, exynos_state);
return ret;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c6d6f6d42900..4c894d97aba3 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -148,7 +148,8 @@ static const struct exynos_drm_plane_config 
plane_configs[MIXER_WIN_NR] = {
.pixel_formats = vp_formats,
.num_pixel_formats = ARRAY_SIZE(vp_formats),
.capabilities = EXYNOS_DRM_PLANE_CAP_SCALE |
-   EXYNOS_DRM_PLANE_CAP_ZPOS,
+   EXYNOS_DRM_PLANE_CAP_ZPOS |
+   EXYNOS_DRM_PLANE_CAP_TILE,
},
 };
 
@@ -500,6 +501,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
return;
}
 
+   if (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
+   tiled_mode = true;
+
luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
 
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/9] drm/exynos: misc fixes and more

[Tobias Jakobi]

Hello,

this is the second iteration of [1], with the following changes:
- split patch 3/8 (suggested by Inki)
- zero init registers in patch 4/8 (suggested by Inki)
- rephrased commit description of patch 5/8 to make it more
  clear that this behaviour depends on the hw
- replace zero with linear modifier in patch 2/8


Summary:
(a) Enables support for NV12MT in the mixer.
(b) Sanitizes buffer pitch for HW with restrictions.
(c) Misc fixes

With best wishes,
Tobias

[1] https://www.spinics.net/lists/linux-samsung-soc/msg60235.html


Tobias Jakobi (9):
  drm/exynos: mixer: fix chroma comment in vp_video_buffer()
  drm/exynos: mixer: enable NV12MT support for the video plane
  drm/exynos: mixer: simplify vp_video_buffer()
  drm/exynos: mixer: simplify mixer_graph_buffer()
  drm/exynos: mixer: remove src offset from mixer_graph_buffer()
  drm/exynos: introduce BYTE_PITCH capability
  drm/exynos: add BYTE_PITCH cap for all supported planes
  drm/exynos: consistent use of cpp
  drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 17 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 13 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 17 --
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 +
 drivers/gpu/drm/exynos/exynos_mixer.c | 48 +--
 7 files changed, 75 insertions(+), 61 deletions(-)

-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/9] drm/exynos: mixer: fix chroma comment in vp_video_buffer()

[Tobias Jakobi]

The current comment sounds like the division op is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index a998a8dd783c..c6d6f6d42900 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -532,7 +532,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
/* setting size of input image */
vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
-   /* chroma height has to reduced by 2 to avoid chroma distorions */
+   /* the chroma plane for NV12/NV21 is half the height of the luma plane 
*/
vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height / 2));
 
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/8] drm/exynos: mixer: remove src offset from mixer_graph_buffer()

[Tobias Jakobi]

Inki Dae wrote:
> 
> 
> 2017년 08월 09일 20:48에 Tobias Jakobi 이(가) 쓴 글:
>> We always translate the dma address such that the offsets of
>> the source image are zero. Hence we can remove manipulation of
>> the MXR_GRAPHIC_SXY(win) register.
>>
>> We leave the register defines (in regs_mixer.h) in place, since
>> they document the hardware.
>>
>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 11 ++-
>>  1 file changed, 2 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 8d68de85bada..28fbe79befff 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -584,7 +584,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
>>  unsigned long flags;
>>  unsigned int win =lane->index;
>>  unsigned int x_ratio =, y_ratio = 0;
>> -unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
>> +unsigned int dst_x_offset, dst_y_offset;
>>  dma_addr_t dma_addr;
>>  unsigned int fmt;
>>  u32 val;
>> @@ -618,12 +618,10 @@ static void mixer_graph_buffer(struct mixer_context 
>> *ctx,
>>  dst_x_offset =tate->crtc.x;
>>  dst_y_offset =tate->crtc.y;
>>  
>> -/* converting dma address base and source offset */
>> +/* translate dma address base s.t. the source image offset is zero */
>>  dma_addr =xynos_drm_fb_dma_addr(fb, 0)
>>  + (state->src.x * fb->format->cpp[0])
>>  + (state->src.y * fb->pitches[0]);
>> -src_x_offset =;
>> -src_y_offset =;
>>  
>>  if (mode->flags & DRM_MODE_FLAG_INTERLACE)
>>  __set_bit(MXR_BIT_INTERLACE, >flags);
>> @@ -654,11 +652,6 @@ static void mixer_graph_buffer(struct mixer_context 
>> *ctx,
>>  val |=XR_GRP_WH_V_SCALE(y_ratio);
>>  mixer_reg_write(res, MXR_GRAPHIC_WH(win), val);
>>  
>> -/* setup offsets in source image */
>> -val  =XR_GRP_SXY_SX(src_x_offset);
>> -val |=XR_GRP_SXY_SY(src_y_offset);
>> -mixer_reg_write(res, MXR_GRAPHIC_SXY(win), val);
> 
> The offset of source buffer can be set at bootloader so previous value can be 
> keeped. I think MXR_GRAPHIC_SXY register should be cleared at mixer_win_reset 
> function if you want to remove above lines.
> 
Good idea, will do so.

- Tobias


>> -
>>  /* setup offsets in display image */
>>  val  =XR_GRP_DXY_DX(dst_x_offset);
>>  val |=XR_GRP_DXY_DY(dst_y_offset);
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/8] drm/exynos: introduce BYTE_PITCH capability

[Tobias Jakobi]

Inki Dae wrote:
> 
> 
> 2017년 08월 09일 20:48에 Tobias Jakobi 이(가) 쓴 글:
>> In some of drivers we compute something like 'pitch / cpp' at some
>> point, silently assuming that the pitch (which is in bytes) is
>> divisible by the buffer's cpp. This is not always true, in particular
>> DRM core does not check for pitch alignment in the common case.
>>
>> Introduce a new cap which indicates that the hardware supports a
>> pitch with 'byte-granularity'. If the cap is not set, assume that
>> we need pitch aligned to cpp.
>>
>> We set this cap later for the drivers/planes that support it.
>>
>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
>>  2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 43afab4bebc3..ec32632485d2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -92,6 +92,7 @@ struct exynos_drm_plane {
>>  #define EXYNOS_DRM_PLANE_CAP_SCALE  (1 << 1)
>>  #define EXYNOS_DRM_PLANE_CAP_ZPOS   (1 << 2)
>>  #define EXYNOS_DRM_PLANE_CAP_TILE   (1 << 3)
>> +#define EXYNOS_DRM_PLANE_CAP_BYTE_PITCH (1 << 4)
> 
> I don't see why this flag is required because cpp value is given always. So I 
> think we can check the pitch alignment regardless of a given flag.
> BTW, it'd better for pitch alignment to be checked by drm core?
How do you want to check the pitch value, if you don't know what the HW can 
handle?

- Tobias

> 
>>  
>>  /*
>>   * Exynos DRM plane configuration structure.
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> index bd3825617b06..734d5ba4eb99 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>> @@ -185,6 +185,16 @@ exynos_drm_plane_check_format(const struct 
>> exynos_drm_plane_config *config,
>>  {
>>  struct drm_framebuffer *fb = state->base.fb;
>>  
>> +/*
>> + * Some blocks only allow to specify a buffer pitch in terms
>> + * of pixels. In these cases, we need to ensure that the pitch
>> + * provided by userspace is divisible by the cpp.
>> + */
>> +if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_BYTE_PITCH)) {
>> +if (fb->pitches[0] % fb->format->cpp[0])
>> +return -ENOTSUPP;
>> +}
>> +
>>  switch (fb->modifier) {
>>  case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
>>  if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/8] drm/exynos: mixer: simplify {vp_video,mixer_graph}_buffer()

[Tobias Jakobi]

Inki Dae wrote:
> 
> 
> 2017년 08월 09일 20:48에 Tobias Jakobi 이(가) 쓴 글:
>> DRM core already checks the validity of the pixelformats, so we
>> can simplify the checks here. The same applies to the FB modifier,
>> which is now checked in common Exynos plane code.
>>
>> Also rename the booleans to reflect what true/false actually
>> means.
>>
>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++
>>  1 file changed, 7 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 4c894d97aba3..8d68de85bada 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -484,32 +484,18 @@ static void vp_video_buffer(struct mixer_context *ctx,
>>  unsigned int priority =tate->base.normalized_zpos + 1;
>>  unsigned long flags;
>>  dma_addr_t luma_addr[2], chroma_addr[2];
>> -bool tiled_mode =alse;
>> -bool crcb_mode =alse;
>> +bool is_tiled, is_nv21;
>>  u32 val;
>>  
>> -switch (fb->format->format) {
>> -case DRM_FORMAT_NV12:
>> -crcb_mode =alse;
>> -break;
>> -case DRM_FORMAT_NV21:
>> -crcb_mode =rue;
>> -break;
>> -default:
>> -DRM_ERROR("pixel format for vp is wrong [%d].\n",
>> -fb->format->format);
>> -return;
>> -}
>> -
>> -if (fb->modifier =DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
>> -tiled_mode =rue;
>> +is_nv21 =fb->format->format == DRM_FORMAT_NV21);
>> +is_tiled =fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE);
>>  
>>  luma_addr[0] =xynos_drm_fb_dma_addr(fb, 0);
>>  chroma_addr[0] =xynos_drm_fb_dma_addr(fb, 1);
>>  
>>  if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
>>  __set_bit(MXR_BIT_INTERLACE, >flags);
>> -if (tiled_mode) {
>> +if (is_tiled) {
>>  luma_addr[1] =uma_addr[0] + 0x40;
>>  chroma_addr[1] =hroma_addr[0] + 0x40;
>>  } else {
>> @@ -529,8 +515,8 @@ static void vp_video_buffer(struct mixer_context *ctx,
>>  vp_reg_writemask(res, VP_MODE, val, VP_MODE_LINE_SKIP);
>>  
>>  /* setup format */
>> -val =crcb_mode ? VP_MODE_NV21 : VP_MODE_NV12);
>> -val |=tiled_mode ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
>> +val =is_nv21 ? VP_MODE_NV21 : VP_MODE_NV12);
>> +val |=is_tiled ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
>>  vp_reg_writemask(res, VP_MODE, val, VP_MODE_FMT_MASK);
>>  
>>  /* setting size of input image */
>> @@ -620,12 +606,9 @@ static void mixer_graph_buffer(struct mixer_context 
>> *ctx,
>>  
>>  case DRM_FORMAT_XRGB:
>>  case DRM_FORMAT_ARGB:
>> +default:
>>  fmt =XR_FORMAT_ARGB;
>>  break;
>> -
>> -default:
>> -DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
>> -return;
> 
> This change should be made as another patch because this patch changes the 
> behavior whether it allows wrong pixel format or not.
> 
OK, I will split the change to mixer_graph_buffer() into another patch here.

- Tobias


> Thanks,
> Inki Dae
> 
>>  }
>>  
>>  /* ratio is already checked by common plane code */
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Tobias Jakobi]

Hello,

some comments first.

- What is this license checker and why should we care about it?
- If multiple licenses are really the problem, we could also change it to GPLv3.
But you want to change it to X11/MIT, so you should clarify this particular
choice. You kinda did this in [1], but it's totally missing here.

More comments inline.

With these changes you have my
Acked-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

- Tobias


[1] http://www.spinics.net/lists/linux-samsung-soc/msg59230.html

Inki Dae wrote:
> Chnage GPL license of Exynos relevant code to X11/MIT.
"Chnage" -> "Change"
"relevant" -> "related"


> I'd like to keep license consistency to all Exynos code
...to keep a consistent license across all...


> because License checker notices two more licenses exist
> in libdrm.
> 
> For the license change I need to get your agree - all committers.
> So please give me Acked-by if you agree with me.
> 
> Signed-off-by: Inki Dae <inki@samsung.com>
> Acked-by: Hyungwon Hwang <human.hw...@samsung.com>
> Acked-by: SooChan Lim <sc1@samsung.com>
> Acked-by: Sangjin LEE <lsj...@samsung.com>
> Acked-by: Boram Park <boram1288.p...@samsung.com>
> Acked-by: Seung-Woo Kim <sw0312@samsung.com>
> Acked-by: Joonyoung Shim <jy0922.s...@samsung.com>
> Acked-by: Emil Velikov <emil.l.veli...@gmail.com>
> ---
>  exynos/exynos_fimg2d.c | 21 +
>  exynos/exynos_fimg2d.h | 21 +
>  exynos/fimg2d_reg.h| 21 +
>  libkms/exynos.c| 22 ++
>  tests/exynos/exynos_fimg2d_event.c | 27 +--
>  tests/exynos/exynos_fimg2d_perf.c  | 27 +--
>  tests/exynos/exynos_fimg2d_test.c  | 21 +
>  7 files changed, 120 insertions(+), 40 deletions(-)
> 
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 61340c3..5658a48 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -3,11 +3,24 @@
>   * Authors:
>   *   Inki Dae <inki@samsung.com>
>   *
> - * 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 <inki@samsung.com>
>   *
> - * 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 (inc

[PATCH 8/8] drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

[Tobias Jakobi]

DRM core already checks the validity of the pixelformat.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 8 +---
 3 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 66ceca0af2a0..3dfba34be24d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -277,13 +277,11 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_ARGB:
+   default:
val |= WINCONx_BPPMODE_32BPP_A;
val |= WINCONx_WSWP_F | WINCONx_BLD_PIX_F | WINCONx_ALPHA_SEL_F;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_ERROR("Proper pixel format is not set\n");
-   return;
}
 
DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 4662d55ed988..615efcf7782a 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -309,16 +309,11 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_BGRA:
+   default:
val |= WINCONx_BPPMODE_32BPP_BGRA | WINCONx_BLD_PIX |
WINCONx_ALPHA_SEL;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_DEBUG_KMS("invalid pixel size so using unpacked 24bpp.\n");
-
-   val |= WINCONx_BPPMODE_24BPP_xRGB;
-   val |= WINCONx_BURSTLEN_16WORD;
-   break;
}
 
DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9b83d1846589..91c62e7afdd5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -583,18 +583,12 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx, 
unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_ARGB:
+   default:
val |= WINCON1_BPPMODE_25BPP_A1888
| WINCON1_BLD_PIX | WINCON1_ALPHA_SEL;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_DEBUG_KMS("invalid pixel size so using unpacked 24bpp.\n");
-
-   val |= WINCON0_BPPMODE_24BPP_888;
-   val |= WINCONx_WSWP;
-   val |= WINCONx_BURSTLEN_16WORD;
-   break;
}
 
/*
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/8] drm/exynos: consistent use of cpp

[Tobias Jakobi]

A recent commit (272725c7db4da1fd3229d944fc76d2e98e3a144e) has removed
the use of 'bits_per_pixel' in DRM. However the corresponding Exynos
driver code still uses the ambiguous 'bpp', even though it is now
initialized from fb->cpp[0].

Consistenly use 'cpp' in FIMD, DECON7 and DECON5433 drivers.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12 ++--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  6 +++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 62b50e0685b0..66ceca0af2a0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -286,7 +286,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
return;
}
 
-   DRM_DEBUG_KMS("bpp = %u\n", fb->format->cpp[0] * 8);
+   DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -329,7 +329,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
struct decon_context *ctx = crtc->ctx;
struct drm_framebuffer *fb = state->base.fb;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
u32 val;
@@ -365,11 +365,11 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));
 
if (!(ctx->out_type & IFTYPE_HDMI))
-   val = BIT_VAL(pitch - state->crtc.w * bpp, 27, 14)
-   | BIT_VAL(state->crtc.w * bpp, 13, 0);
+   val = BIT_VAL(pitch - state->crtc.w * cpp, 27, 14)
+   | BIT_VAL(state->crtc.w * cpp, 13, 0);
else
-   val = BIT_VAL(pitch - state->crtc.w * bpp, 29, 15)
-   | BIT_VAL(state->crtc.w * bpp, 14, 0);
+   val = BIT_VAL(pitch - state->crtc.w * cpp, 29, 15)
+   | BIT_VAL(state->crtc.w * cpp, 14, 0);
writel(val, ctx->addr + DECON_VIDW0xADD2(win));
 
decon_win_set_pixfmt(ctx, win, fb);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 3e88269fdc2e..4662d55ed988 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -321,7 +321,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
break;
}
 
-   DRM_DEBUG_KMS("bpp = %d\n", fb->format->cpp[0] * 8);
+   DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -398,7 +398,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int last_x;
unsigned int last_y;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
 
if (ctx->suspended)
@@ -418,7 +418,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
val = (unsigned long)exynos_drm_fb_dma_addr(fb, 0);
writel(val, ctx->regs + VIDW_BUF_START(win));
 
-   padding = (pitch / bpp) - fb->width;
+   padding = (pitch / cpp) - fb->width;
 
/* buffer size */
writel(fb->width + padding, ctx->regs + VIDW_WHOLE_X(win));
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index e88597f6d356..9b83d1846589 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -718,13 +718,13 @@ static void fimd_update_plane(struct exynos_drm_crtc 
*crtc,
unsigned long val, size, offset;
unsigned int last_x, last_y, buf_offsize, line_size;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
 
if (ctx->suspended)
return;
 
-   offset = state->src.x * bpp;
+   offset = state->src.x * cpp;
offset += state->src.y * pitch;
 
/* buffer start address */
@@ -743,8 +743,8 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
state->crtc.w, state->crtc.h);
 
/* buffer size */
-   buf_offsize = pitch 

[PATCH 6/8] drm/exynos: add BYTE_PITCH cap for all supported planes

[Tobias Jakobi]

Both FIMD and DECON5433 support a pitch in bytes.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 5792ca88ab7a..62b50e0685b0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -546,6 +546,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[win].num_pixel_formats = ARRAY_SIZE(decon_formats);
ctx->configs[win].zpos = win;
ctx->configs[win].type = decon_win_types[tmp];
+   ctx->configs[win].capabilities = 
EXYNOS_DRM_PLANE_CAP_BYTE_PITCH;
 
ret = exynos_plane_init(drm_dev, >planes[win], win,
>configs[win]);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 60f93cad6643..e88597f6d356 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -986,6 +986,7 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[i].num_pixel_formats = ARRAY_SIZE(fimd_formats);
ctx->configs[i].zpos = i;
ctx->configs[i].type = fimd_win_types[i];
+   ctx->configs[i].capabilities = EXYNOS_DRM_PLANE_CAP_BYTE_PITCH;
ret = exynos_plane_init(drm_dev, >planes[i], i,
>configs[i]);
if (ret)
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/8] drm/exynos: introduce BYTE_PITCH capability

[Tobias Jakobi]

In some of drivers we compute something like 'pitch / cpp' at some
point, silently assuming that the pitch (which is in bytes) is
divisible by the buffer's cpp. This is not always true, in particular
DRM core does not check for pitch alignment in the common case.

Introduce a new cap which indicates that the hardware supports a
pitch with 'byte-granularity'. If the cap is not set, assume that
we need pitch aligned to cpp.

We set this cap later for the drivers/planes that support it.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 43afab4bebc3..ec32632485d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -92,6 +92,7 @@ struct exynos_drm_plane {
 #define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
 #define EXYNOS_DRM_PLANE_CAP_ZPOS  (1 << 2)
 #define EXYNOS_DRM_PLANE_CAP_TILE  (1 << 3)
+#define EXYNOS_DRM_PLANE_CAP_BYTE_PITCH(1 << 4)
 
 /*
  * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index bd3825617b06..734d5ba4eb99 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -185,6 +185,16 @@ exynos_drm_plane_check_format(const struct 
exynos_drm_plane_config *config,
 {
struct drm_framebuffer *fb = state->base.fb;
 
+   /*
+* Some blocks only allow to specify a buffer pitch in terms
+* of pixels. In these cases, we need to ensure that the pitch
+* provided by userspace is divisible by the cpp.
+*/
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_BYTE_PITCH)) {
+   if (fb->pitches[0] % fb->format->cpp[0])
+   return -ENOTSUPP;
+   }
+
switch (fb->modifier) {
case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/8] drm/exynos: mixer: simplify {vp_video, mixer_graph}_buffer()

[Tobias Jakobi]

DRM core already checks the validity of the pixelformats, so we
can simplify the checks here. The same applies to the FB modifier,
which is now checked in common Exynos plane code.

Also rename the booleans to reflect what true/false actually
means.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++
 1 file changed, 7 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4c894d97aba3..8d68de85bada 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -484,32 +484,18 @@ static void vp_video_buffer(struct mixer_context *ctx,
unsigned int priority = state->base.normalized_zpos + 1;
unsigned long flags;
dma_addr_t luma_addr[2], chroma_addr[2];
-   bool tiled_mode = false;
-   bool crcb_mode = false;
+   bool is_tiled, is_nv21;
u32 val;
 
-   switch (fb->format->format) {
-   case DRM_FORMAT_NV12:
-   crcb_mode = false;
-   break;
-   case DRM_FORMAT_NV21:
-   crcb_mode = true;
-   break;
-   default:
-   DRM_ERROR("pixel format for vp is wrong [%d].\n",
-   fb->format->format);
-   return;
-   }
-
-   if (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
-   tiled_mode = true;
+   is_nv21 = (fb->format->format == DRM_FORMAT_NV21);
+   is_tiled = (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE);
 
luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
__set_bit(MXR_BIT_INTERLACE, >flags);
-   if (tiled_mode) {
+   if (is_tiled) {
luma_addr[1] = luma_addr[0] + 0x40;
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
@@ -529,8 +515,8 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_writemask(res, VP_MODE, val, VP_MODE_LINE_SKIP);
 
/* setup format */
-   val = (crcb_mode ? VP_MODE_NV21 : VP_MODE_NV12);
-   val |= (tiled_mode ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
+   val = (is_nv21 ? VP_MODE_NV21 : VP_MODE_NV12);
+   val |= (is_tiled ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
vp_reg_writemask(res, VP_MODE, val, VP_MODE_FMT_MASK);
 
/* setting size of input image */
@@ -620,12 +606,9 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
 
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+   default:
fmt = MXR_FORMAT_ARGB;
break;
-
-   default:
-   DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
-   return;
}
 
/* ratio is already checked by common plane code */
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/8] drm/exynos: mixer: fix chroma comment in vp_video_buffer()

[Tobias Jakobi]

The current comment sounds like the division op is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index a998a8dd783c..c6d6f6d42900 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -532,7 +532,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
/* setting size of input image */
vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
-   /* chroma height has to reduced by 2 to avoid chroma distorions */
+   /* the chroma plane for NV12/NV21 is half the height of the luma plane 
*/
vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height / 2));
 
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/8] drm/exynos: mixer: enable NV12MT support for the video plane

[Tobias Jakobi]

The video processor supports a tiled version of the NV12 format,
known as NV12MT in V4L2 terms. The support was removed in commit
083500baefd5f4c215a5a93aef2492c1aa775828 due to not being a real
pixel format, but rather NV12 with a special memory layout.

With the introduction of FB modifiers, we can now properly support
this format again.

Tested with a hacked up modetest from libdrm's test suite on
an ODROID-X2 (Exynos4412).

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 27 +++
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 +-
 4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a93de321706b..43afab4bebc3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -91,6 +91,7 @@ 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_TILE  (1 << 3)
 
 /*
  * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d48fd7c918f8..87e32dbd8eda 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -238,4 +238,6 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
 
dev->mode_config.funcs = _drm_mode_config_funcs;
dev->mode_config.helper_private = _drm_mode_config_helpers;
+
+   dev->mode_config.allow_fb_modifiers = true;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 611b6fd65433..bd3825617b06 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -180,6 +180,29 @@ static struct drm_plane_funcs exynos_plane_funcs = {
 };
 
 static int
+exynos_drm_plane_check_format(const struct exynos_drm_plane_config *config,
+ struct exynos_drm_plane_state *state)
+{
+   struct drm_framebuffer *fb = state->base.fb;
+
+   switch (fb->modifier) {
+   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
+   return -ENOTSUPP;
+   break;
+
+   case 0:
+   break;
+
+   default:
+   DRM_ERROR("unsupported pixel format modifier");
+   return -ENOTSUPP;
+   }
+
+   return 0;
+}
+
+static int
 exynos_drm_plane_check_size(const struct exynos_drm_plane_config *config,
struct exynos_drm_plane_state *state)
 {
@@ -223,6 +246,10 @@ static int exynos_plane_atomic_check(struct drm_plane 
*plane,
/* translate state into exynos_state */
exynos_plane_mode_set(exynos_state);
 
+   ret = exynos_drm_plane_check_format(exynos_plane->config, exynos_state);
+   if (ret)
+   return ret;
+
ret = exynos_drm_plane_check_size(exynos_plane->config, exynos_state);
return ret;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c6d6f6d42900..4c894d97aba3 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -148,7 +148,8 @@ static const struct exynos_drm_plane_config 
plane_configs[MIXER_WIN_NR] = {
.pixel_formats = vp_formats,
.num_pixel_formats = ARRAY_SIZE(vp_formats),
.capabilities = EXYNOS_DRM_PLANE_CAP_SCALE |
-   EXYNOS_DRM_PLANE_CAP_ZPOS,
+   EXYNOS_DRM_PLANE_CAP_ZPOS |
+   EXYNOS_DRM_PLANE_CAP_TILE,
},
 };
 
@@ -500,6 +501,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
return;
}
 
+   if (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
+   tiled_mode = true;
+
luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
 
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/8] drm/exynos: misc fixes and more

[Tobias Jakobi]

Hello,

this is basically a resend of [1] with some minor changes to the commit
messages, the RFC tag removed, and a rebase on vanilla 4.13-rc4.

Summary:
(a) Enables support for NV12MT in the mixer.
(b) Sanitizes buffer pitch for HW with restrictions.
(c) Misc fixes

With best wishes,
Tobias


[1] https://lists.freedesktop.org/archives/dri-devel/2017-April/138040.html

Tobias Jakobi (8):
  drm/exynos: mixer: fix chroma comment in vp_video_buffer()
  drm/exynos: mixer: enable NV12MT support for the video plane
  drm/exynos: mixer: simplify {vp_video,mixer_graph}_buffer()
  drm/exynos: mixer: remove src offset from mixer_graph_buffer()
  drm/exynos: introduce BYTE_PITCH capability
  drm/exynos: add BYTE_PITCH cap for all supported planes
  drm/exynos: consistent use of cpp
  drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 17 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 13 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 17 ---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 ++
 drivers/gpu/drm/exynos/exynos_mixer.c | 44 ---
 7 files changed, 71 insertions(+), 61 deletions(-)

-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] drm/exynos: mixer: remove src offset from mixer_graph_buffer()

[Tobias Jakobi]

We always translate the dma address such that the offsets of
the source image are zero. Hence we can remove manipulation of
the MXR_GRAPHIC_SXY(win) register.

We leave the register defines (in regs_mixer.h) in place, since
they document the hardware.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8d68de85bada..28fbe79befff 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -584,7 +584,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
unsigned long flags;
unsigned int win = plane->index;
unsigned int x_ratio = 0, y_ratio = 0;
-   unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
+   unsigned int dst_x_offset, dst_y_offset;
dma_addr_t dma_addr;
unsigned int fmt;
u32 val;
@@ -618,12 +618,10 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
dst_x_offset = state->crtc.x;
dst_y_offset = state->crtc.y;
 
-   /* converting dma address base and source offset */
+   /* translate dma address base s.t. the source image offset is zero */
dma_addr = exynos_drm_fb_dma_addr(fb, 0)
+ (state->src.x * fb->format->cpp[0])
+ (state->src.y * fb->pitches[0]);
-   src_x_offset = 0;
-   src_y_offset = 0;
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
__set_bit(MXR_BIT_INTERLACE, >flags);
@@ -654,11 +652,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
val |= MXR_GRP_WH_V_SCALE(y_ratio);
mixer_reg_write(res, MXR_GRAPHIC_WH(win), val);
 
-   /* setup offsets in source image */
-   val  = MXR_GRP_SXY_SX(src_x_offset);
-   val |= MXR_GRP_SXY_SY(src_y_offset);
-   mixer_reg_write(res, MXR_GRAPHIC_SXY(win), val);
-
/* setup offsets in display image */
val  = MXR_GRP_DXY_DX(dst_x_offset);
val |= MXR_GRP_DXY_DY(dst_y_offset);
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: forbid creating framebuffers from too small GEM buffers

[Tobias Jakobi]

Hello Marek,

I have a similar patch in my tree, so this one is

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

- Tobias


Marek Szyprowski wrote:
> Add a check if the framebuffer described by the provided drm_mode_fb_cmd2
> structure fits into provided GEM buffers. Without this check it is
> possible to create a framebuffer object from a small buffer and set it to
> the hardware, what results in displaying system memory outside the
> allocated GEM buffer.
> 
> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
> CC: sta...@vger.kernel.org # v4.7+
> ---
> This issue was there from the beggining, but the provided patch applies only
> to v4.7+ kernels due to other changes in the fixed code.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index d48fd7c918f8..73217c281c9a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -145,13 +145,19 @@ struct drm_framebuffer *
>  exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> const struct drm_mode_fb_cmd2 *mode_cmd)
>  {
> + const struct drm_format_info *info = drm_get_format_info(dev, mode_cmd);
>   struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
>   struct drm_gem_object *obj;
>   struct drm_framebuffer *fb;
>   int i;
>   int ret;
>  
> - for (i = 0; i < drm_format_num_planes(mode_cmd->pixel_format); i++) {
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int height = (i == 0) ? mode_cmd->height :
> +  DIV_ROUND_UP(mode_cmd->height, info->vsub);
> + unsigned long size = height * mode_cmd->pitches[i] +
> +  mode_cmd->offsets[i];
> +
>   obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[i]);
>   if (!obj) {
>   DRM_ERROR("failed to lookup gem object\n");
> @@ -160,6 +166,12 @@ struct drm_framebuffer *
>   }
>  
>   exynos_gem[i] = to_exynos_gem(obj);
> +
> + if (size > exynos_gem[i]->size) {
> + i++;
> + ret = -EINVAL;
> + goto err;
> + }
>   }
>  
>   fb = exynos_drm_framebuffer_init(dev, mode_cmd, exynos_gem, i);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

[Tobias Jakobi]

Hello Hoegeun,

my last question (does this regress the case "node required, but
absent") still stands.


Hoegeun Kwon wrote:
> Remove the error handling of bridge_node because the bridge_node is
> required optionally.
I don't think a construction like that exists. Either it's required, or
it's optional. "required optionally" makes no sense to me (but I'm not a
native speaker).

- Tobias


> For example, In case of Exynos SoC, a bridge device such as mDNIe and
> MIC could be placed between Display Controller and MIPI DSI device but
> the bridge device is required optionally.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
> 
> Hi Inki and Tobias,
> 
> Thanks for your review.
> 
> Changes for V2:
> - Modified the commit message in more detail than before.
> 
> Best Regards,
> Hoegeun
> 
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index a11b795..6ee0dac 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>   return ret;
>  
>   dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
> - if (!dsi->bridge_node)
> - return -EINVAL;
>  
>   return 0;
>  }
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

[Tobias Jakobi]

Hey,

Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 18:52 +0200, Tobias Jakobi a écrit :
>> Hello again,
>>
>>
>> Nicolas Dufresne wrote:
>>> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
>>>> Hi Marek,
>>>>
>>>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>>>> Hi Laurent,
>>>>>
>>>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
>>>>>> Hi Marek,
>>>>>>
>>>>>> (CC'ing Sakari Ailus)
>>>>>>
>>>>>> Thank you for the patches.
>>>>>>
>>>>>> On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
>>>>>>> Dear all,
>>>>>>>
>>>>>>> This is an updated proposal for extending EXYNOS DRM API with generic
>>>>>>> support for hardware modules, which can be used for processing image 
>>>>>>> data
>>>>>>> from the one memory buffer to another. Typical memory-to-memory 
>>>>>>> operations
>>>>>>> are: rotation, scaling, colour space conversion or mix of them. This is 
>>>>>>> a
>>>>>>> follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
>>>>>>> processors", which has been rejected as "not really needed in the DRM
>>>>>>> core":
>>>>>>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html
>>>>>>>
>>>>>>> In this proposal I moved all the code to Exynos DRM driver, so now this
>>>>>>> will be specific only to Exynos DRM. I've also changed the name from
>>>>>>> framebuffer processor (fbproc) to picture processor (pp) to avoid 
>>>>>>> confusion
>>>>>>> with fbdev API.
>>>>>>>
>>>>>>> Here is a bit more information what picture processors are:
>>>>>>>
>>>>>>> Embedded SoCs are known to have a number of hardware blocks, which 
>>>>>>> perform
>>>>>>> such operations. They can be used in paralel to the main GPU module to
>>>>>>> offload CPU from processing grapics or video data. One of example use of
>>>>>>> such modules is implementing video overlay, which usually requires color
>>>>>>> space conversion from NV12 (or similar) to RGB32 color space and 
>>>>>>> scaling to
>>>>>>> target window size.
>>>>>>>
>>>>>>> The proposed API is heavily inspired by atomic KMS approach - it is also
>>>>>>> based on DRM objects and their properties. A new DRM object is 
>>>>>>> introduced:
>>>>>>> picture processor (called pp for convenience). Such objects have a set 
>>>>>>> of
>>>>>>> standard DRM properties, which describes the operation to be performed 
>>>>>>> by
>>>>>>> respective hardware module. In typical case those properties are a 
>>>>>>> source
>>>>>>> fb id and rectangle (x, y, width, height) and destination fb id and
>>>>>>> rectangle. Optionally a rotation property can be also specified if
>>>>>>> supported by the given hardware. To perform an operation on image data,
>>>>>>> userspace provides a set of properties and their values for given fbproc
>>>>>>> object in a similar way as object and properties are provided for
>>>>>>> performing atomic page flip / mode setting.
>>>>>>>
>>>>>>> The proposed API consists of the 3 new ioctls:
>>>>>>> - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
>>>>>>>   processors,
>>>>>>> - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
>>>>>>>   processor,
>>>>>>> - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
>>>>>>>   property set.
>>>>>>>
>>>>>>> The proposed API is extensible. Drivers can attach their own, custom
>>>>>>> properties to add support for more advanced picture processing (for 
>>>>>>> example
>>>>>>> blending).
>>>>>>>
>>>>&

Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

[Tobias Jakobi]

Hello again,


Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
 Hi Marek,

 (CC'ing Sakari Ailus)

 Thank you for the patches.

 On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
> Dear all,
>
> This is an updated proposal for extending EXYNOS DRM API with generic
> support for hardware modules, which can be used for processing image data
> from the one memory buffer to another. Typical memory-to-memory operations
> are: rotation, scaling, colour space conversion or mix of them. This is a
> follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
> processors", which has been rejected as "not really needed in the DRM
> core":
> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html
>
> In this proposal I moved all the code to Exynos DRM driver, so now this
> will be specific only to Exynos DRM. I've also changed the name from
> framebuffer processor (fbproc) to picture processor (pp) to avoid 
> confusion
> with fbdev API.
>
> Here is a bit more information what picture processors are:
>
> Embedded SoCs are known to have a number of hardware blocks, which perform
> such operations. They can be used in paralel to the main GPU module to
> offload CPU from processing grapics or video data. One of example use of
> such modules is implementing video overlay, which usually requires color
> space conversion from NV12 (or similar) to RGB32 color space and scaling 
> to
> target window size.
>
> The proposed API is heavily inspired by atomic KMS approach - it is also
> based on DRM objects and their properties. A new DRM object is introduced:
> picture processor (called pp for convenience). Such objects have a set of
> standard DRM properties, which describes the operation to be performed by
> respective hardware module. In typical case those properties are a source
> fb id and rectangle (x, y, width, height) and destination fb id and
> rectangle. Optionally a rotation property can be also specified if
> supported by the given hardware. To perform an operation on image data,
> userspace provides a set of properties and their values for given fbproc
> object in a similar way as object and properties are provided for
> performing atomic page flip / mode setting.
>
> The proposed API consists of the 3 new ioctls:
> - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
>   processors,
> - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
>   processor,
> - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
>   property set.
>
> The proposed API is extensible. Drivers can attach their own, custom
> properties to add support for more advanced picture processing (for 
> example
> blending).
>
> This proposal aims to replace Exynos DRM IPP (Image Post Processing)
> subsystem. IPP API is over-engineered in general, but not really 
> extensible
> on the other side. It is also buggy, with significant design flaws - the
> biggest issue is the fact that the API covers memory-2-memory picture
> operations together with CRTC writeback and duplicating features, which
> belongs to video plane. Comparing with IPP subsystem, the PP framework is
> smaller (1807 vs 778 lines) and allows driver simplification (Exynos
> rotator driver smaller by over 200 lines).
> 
> Just a side note, we have written code in GStreamer using the Exnynos 4
> FIMC IPP driver. I don't know how many, if any, deployment still exist
> (Exynos 4 is relatively old now), but there exist userspace for the
> FIMC driver.
I was searching for this code, but I didn't find anything. Are you sure
you really mean the FIMC IPP in Exynos DRM, and not just the FIMC driver
from the V4L2 subsystem?


With best wishes,
Tobias



> We use this for color transformation (from tiled to
> linear) and scaling. The FIMC driver is in fact quite stable in
> upstream kernel today. The GScaler V4L2 M2M driver on Exynos 5 is
> largely based on it and has received some maintenance to properly work
> in GStreamer. unlike this DRM API, you can reuse the same userspace
> code across multiple platforms (which we do already). We have also
> integrated this driver in Chromium in the past (not upstream though).
> 
> I am well aware that the blitter driver has not got much attention
> though. But again, V4L2 offers a generic interface to userspace
> application. Fixing this driver could enable some work like this one:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=772766
> 
> This work in progress feature is a generic hardware accelerated video
> 

Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

[Tobias Jakobi]

Hello everyone,


Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
 Hi Marek,

 (CC'ing Sakari Ailus)

 Thank you for the patches.

 On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
> Dear all,
>
> This is an updated proposal for extending EXYNOS DRM API with generic
> support for hardware modules, which can be used for processing image data
> from the one memory buffer to another. Typical memory-to-memory operations
> are: rotation, scaling, colour space conversion or mix of them. This is a
> follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
> processors", which has been rejected as "not really needed in the DRM
> core":
> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html
>
> In this proposal I moved all the code to Exynos DRM driver, so now this
> will be specific only to Exynos DRM. I've also changed the name from
> framebuffer processor (fbproc) to picture processor (pp) to avoid 
> confusion
> with fbdev API.
>
> Here is a bit more information what picture processors are:
>
> Embedded SoCs are known to have a number of hardware blocks, which perform
> such operations. They can be used in paralel to the main GPU module to
> offload CPU from processing grapics or video data. One of example use of
> such modules is implementing video overlay, which usually requires color
> space conversion from NV12 (or similar) to RGB32 color space and scaling 
> to
> target window size.
>
> The proposed API is heavily inspired by atomic KMS approach - it is also
> based on DRM objects and their properties. A new DRM object is introduced:
> picture processor (called pp for convenience). Such objects have a set of
> standard DRM properties, which describes the operation to be performed by
> respective hardware module. In typical case those properties are a source
> fb id and rectangle (x, y, width, height) and destination fb id and
> rectangle. Optionally a rotation property can be also specified if
> supported by the given hardware. To perform an operation on image data,
> userspace provides a set of properties and their values for given fbproc
> object in a similar way as object and properties are provided for
> performing atomic page flip / mode setting.
>
> The proposed API consists of the 3 new ioctls:
> - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
>   processors,
> - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
>   processor,
> - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
>   property set.
>
> The proposed API is extensible. Drivers can attach their own, custom
> properties to add support for more advanced picture processing (for 
> example
> blending).
>
> This proposal aims to replace Exynos DRM IPP (Image Post Processing)
> subsystem. IPP API is over-engineered in general, but not really 
> extensible
> on the other side. It is also buggy, with significant design flaws - the
> biggest issue is the fact that the API covers memory-2-memory picture
> operations together with CRTC writeback and duplicating features, which
> belongs to video plane. Comparing with IPP subsystem, the PP framework is
> smaller (1807 vs 778 lines) and allows driver simplification (Exynos
> rotator driver smaller by over 200 lines).
> 
> Just a side note, we have written code in GStreamer using the Exnynos 4
> FIMC IPP driver. I don't know how many, if any, deployment still exist
> (Exynos 4 is relatively old now), but there exist userspace for the
> FIMC driver. We use this for color transformation (from tiled to
> linear) and scaling. The FIMC driver is in fact quite stable in
> upstream kernel today. The GScaler V4L2 M2M driver on Exynos 5 is
> largely based on it and has received some maintenance to properly work
> in GStreamer. unlike this DRM API, you can reuse the same userspace
> code across multiple platforms (which we do already). We have also
> integrated this driver in Chromium in the past (not upstream though).
> 
> I am well aware that the blitter driver has not got much attention
> though. But again, V4L2 offers a generic interface to userspace
> application. Fixing this driver could enable some work like this one:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=772766
> 
> This work in progress feature is a generic hardware accelerated video
> mixer. It has been tested with IMX.6 v4l2 m2m blitter driver (which I
> believe is in staging right now). Again, unlike the exynos/drm, this
> code could be reused between platforms.
> 
> In general, 

Re: [RFC 0/4] Exynos DRM: add Picture Processor extension

[Tobias Jakobi]

Hello everyone,


Marek Szyprowski wrote:
> Hi Laurent,
> 
> On 2017-04-20 12:25, Laurent Pinchart wrote:
>> Hi Marek,
>>
>> (CC'ing Sakari Ailus)
>>
>> Thank you for the patches.
>>
>> On Thursday 20 Apr 2017 11:13:36 Marek Szyprowski wrote:
>>> Dear all,
>>>
>>> This is an updated proposal for extending EXYNOS DRM API with generic
>>> support for hardware modules, which can be used for processing image
>>> data
>>> from the one memory buffer to another. Typical memory-to-memory
>>> operations
>>> are: rotation, scaling, colour space conversion or mix of them. This
>>> is a
>>> follow-up of my previous proposal "[RFC 0/2] New feature: Framebuffer
>>> processors", which has been rejected as "not really needed in the DRM
>>> core":
>>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg146286.html
>>>
>>>
>>> In this proposal I moved all the code to Exynos DRM driver, so now this
>>> will be specific only to Exynos DRM. I've also changed the name from
>>> framebuffer processor (fbproc) to picture processor (pp) to avoid
>>> confusion
>>> with fbdev API.
>>>
>>> Here is a bit more information what picture processors are:
>>>
>>> Embedded SoCs are known to have a number of hardware blocks, which
>>> perform
>>> such operations. They can be used in paralel to the main GPU module to
>>> offload CPU from processing grapics or video data. One of example use of
>>> such modules is implementing video overlay, which usually requires color
>>> space conversion from NV12 (or similar) to RGB32 color space and
>>> scaling to
>>> target window size.
>>>
>>> The proposed API is heavily inspired by atomic KMS approach - it is also
>>> based on DRM objects and their properties. A new DRM object is
>>> introduced:
>>> picture processor (called pp for convenience). Such objects have a
>>> set of
>>> standard DRM properties, which describes the operation to be
>>> performed by
>>> respective hardware module. In typical case those properties are a
>>> source
>>> fb id and rectangle (x, y, width, height) and destination fb id and
>>> rectangle. Optionally a rotation property can be also specified if
>>> supported by the given hardware. To perform an operation on image data,
>>> userspace provides a set of properties and their values for given fbproc
>>> object in a similar way as object and properties are provided for
>>> performing atomic page flip / mode setting.
>>>
>>> The proposed API consists of the 3 new ioctls:
>>> - DRM_IOCTL_EXYNOS_PP_GET_RESOURCES: to enumerate all available picture
>>>processors,
>>> - DRM_IOCTL_EXYNOS_PP_GET: to query capabilities of given picture
>>>processor,
>>> - DRM_IOCTL_EXYNOS_PP_COMMIT: to perform operation described by given
>>>property set.
>>>
>>> The proposed API is extensible. Drivers can attach their own, custom
>>> properties to add support for more advanced picture processing (for
>>> example
>>> blending).
>>>
>>> This proposal aims to replace Exynos DRM IPP (Image Post Processing)
>>> subsystem. IPP API is over-engineered in general, but not really
>>> extensible
>>> on the other side. It is also buggy, with significant design flaws - the
>>> biggest issue is the fact that the API covers memory-2-memory picture
>>> operations together with CRTC writeback and duplicating features, which
>>> belongs to video plane. Comparing with IPP subsystem, the PP
>>> framework is
>>> smaller (1807 vs 778 lines) and allows driver simplification (Exynos
>>> rotator driver smaller by over 200 lines).
>> This seems to be the kind of hardware that is typically supported by
>> V4L2.
>> Stupid question, why DRM ?
> 
> Let me elaborate a bit on the reasons for implementing it in Exynos DRM:
> 
> 1. we want to replace existing Exynos IPP subsystem:
>  - it is used only in some internal/vendor trees, not in open-source
>  - we want it to have sane and potentially extensible userspace API
>  - but we don't want to loose its functionality
> 
> 2. we want to have simple API for performing single image processing
> operation:
>  - typically it will be used by compositing window manager, this means that
>some parameters of the processing might change on each vblank (like
>destination rectangle for example). This api allows such change on each
>operation without any additional cost. V4L2 requires to reinitialize
>queues with new configuration on such change, what means that a bunch of
>ioctls has to be called.
>  - validating processing parameters in V4l2 API is really complicated,
>because the parameters (format, src rectangles, rotation) are being
>set incrementally, so we have to either allow some impossible,
> transitional
>configurations or complicate the configuration steps even more (like
>calling some ioctls multiple times for both input and output). In the
> end
>all parameters have to be again validated just before performing the
>operation.
> 
> 3. generic approach (to add it to DRM core) has been rejected:
> 

Re: [RFC 0/8] drm/exynos: misc fixes and more

[Tobias Jakobi]

Hello Inki,


Inki Dae wrote:
> Hello Tobias,
> 
> 2017년 04월 11일 19:52에 Tobias Jakobi 이(가) 쓴 글:
>> Hello Inki,
>>
>> please don't forget to review this series.
> 
> Thanks for your contribution, and don't worry about that. Will review this 
> series.


Thank you for the confirmation!

In the meantime, i.e. until we have figured out the IOMMU pagefault, it
would make sense to reject the combination "interlaced mode + video
plane". Should I prepare a patch for that?


With best wishes,
Tobias



> Just sharing a plan for -next,
> 
> I plan to have pull-request after reviewing a patch set[1] posted by Andrzej.
> After that, I will start to review your patch set - we would need to enough 
> review this RFC patch set. 
> 
> It would be very helpful to me if other people could review this.
> 
> 
> Thanks,
> Inki Dae
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2017-April/138112.html
> 
> 
>>
>> Also some pointers concerning the video plane flickering and the
>> interlacing issue would be very welcome.
>>
>> Looking at the current register defines for MXR_INT_EN suggests that
>> there are at least three more type of interrupt available. Any chance
>> these could be documented? I hope to get some more insight into this
>> issue, which apparantly is caused by insufficient bandwidth.
>>
>> For the interlacing issue I have done partial progress. I now longer see
>> a IOMMU pagefault, but the video plane is heavily corrupted. Also the
>> dimensions look wrong.
>>
>> While I can somehow guess that VP_MODE_LINE_SKIP does, the
>> VP_MODE_FIELD_ID_AUTO_TOGGLING flag still remains a mystery to me. If
>> possible, I request some documentation for this as well.
>>
>>
>> With best wishes,
>> Tobias
>>
>>
>>
>> Tobias Jakobi wrote:
>>> Hello,
>>>
>>> some recent work I did on Exynos. Patches are based on [1] and [2].
>>>
>>> Summary:
>>> (a) Enables support for NV12MT in the mixer.
>>> (b) Sanitizes buffer pitch for HW with restrictions.
>>> (c) Misc fixes
>>>
>>> While testing the NV12MT part, I made these interesting observations.
>>>
>>> (1) I used 1920x1080 XRGB on the primary plane, and 1280x768 on the
>>> video plane. With this configuration, it does not matter if you're
>>> using NV12 or NV12MT, the video plane occasionally flickers or shows
>>> heavy artifacting. Reducing the size of the primary plane, e.g. to
>>> 32x32 solves this issue, so my guess is that this is memory bandwidth
>>> issue. Does someone know if one can check for buffer underflows of the
>>> mixer with respect to data passed from the VP?
>>>
>>> (2) Using 1920x1080i (so an interlaced mode) and NV12, the board
>>> immediately dies with an IOMMU pagefault at address zero. I'm
>>> currently investigating this, and it looks like that the VP setup
>>> is wrong here. In particular it should be the source (!) height
>>> and vertical position that should be halfed in interlaced mode, and
>>> not the destination. Need to look more into this.
>>>
>>> Anyway, both the issues are independant of the patches, so please
>>> review! :-)
>>>
>>> With best wishes,
>>> Tobias
>>>
>>>
>>> [1] http://www.spinics.net/lists/linux-samsung-soc/msg58640.html
>>> [2] http://www.spinics.net/lists/linux-samsung-soc/msg58644.html
>>>
>>> Tobias Jakobi (8):
>>>   drm/exynos: mixer: fix chroma comment in vp_video_buffer()
>>>   drm/exynos: mixer: enable NV12MT support for the video plane
>>>   drm/exynos: mixer: simplify {vp_video,mixer_graph}_buffer()
>>>   drm/exynos: mixer: remove src offset from mixer_graph_buffer()
>>>   drm/exynos: introduce BYTE_PITCH capability
>>>   drm/exynos: add BYTE_PITCH cap for all supported planes
>>>   drm/exynos: consistent use of cpp
>>>   drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers
>>>
>>>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 17 +--
>>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 13 +++-
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 ++
>>>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 17 ---
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 ++
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 44 
>>> ---
>>>  7 files changed, 71 insertions(+), 61 deletions(-)
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Tobias Jakobi]

Hello Inki,



Inki Dae wrote:
> 2017년 04월 11일 17:17에 Tobias Jakobi 이(가) 쓴 글:
>> Another thing that I noticed. Why wasn't the v2 that ended up in your
>> git ever submitted to the mailing list? Because it should have, in
>> particular to spot these obvious errors.
> 
> Only comment about this.
> 
> This patch cleans up description of struct exynos_drm_clk - removed 
> unnecessary descriptions and adds one missed before.
> I think no problem to update the description without v2 because no code 
> change and description enough.
I think you miss the point here. I checked the mail thread again and you
responded with "More simple and looks better." when I suggested to put
the largest part of your description in front of 'struct
exynos_drm_clk'. I even went so far as to prepare the comment for you.
And then you proceed by ignoring everything and merging some completly
different patch. I find this disrespectful.

I'm quoting your words here (from [1]):
> I'd like to say *maintainer is really not a place for power*, and maintainer 
> would implicitly have a role to encourage in contribution activity of 
> contributer.

If you really mean this, you should also act accordingly. And that does
not mean saying "A" to someone and then doing "B".



> If you want to update the description more then you can post it.
> Ps. I am not a leisurely person to respond to every little thing.
I don't expect you to respond to every little thing. But I expect proper
and honest communication. Also a response delay of four weeks is simply
not acceptable. And I don't think I'm the only one on dri-devel that
thinks that way.

With best wishes,
Tobias


[1] http://www.spinics.net/lists/dri-devel/msg131304.html


> 
> Thanks,
> Inki Dae
> 
>>
>> - Tobias
>>
>>
>> Tobias Jakobi wrote:
>>> Inki Dae wrote:
>>>>
>>>>
>>>> 2017년 04월 10일 19:29에 Tobias Jakobi 이(가) 쓴 글:
>>>>> Inki Dae wrote:
>>>>>> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
>>>>>>> Hello Inki,
>>>>>>>
>>>>>>>
>>>>>>> Inki Dae wrote:
>>>>>>>> Hello Tobias,
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>>>>>>>>> Hello Inki,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Inki Dae wrote:
>>>>>>>>>> This patch removes unnecessary descriptions on
>>>>>>>>>> exynos_drm_crtc structure and adds one description
>>>>>>>>>> which specifies what pipe_clk member does.
>>>>>>>>>>
>>>>>>>>>> pipe_clk support had been added by below patch without any 
>>>>>>>>>> description,
>>>>>>>>>>  drm/exynos: add support for pipeline clock to the framework
>>>>>>>>> I would put the commit id here. That makes it easier to look up the
>>>>>>>>> commit your refer to.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Signed-off-by: Inki Dae <inki@samsung.com>
>>>>>>>>>> ---
>>>>>>>>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>>>>>>>>>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>>>>>>>>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>>>>> index 527bf1d..b0462cc 100644
>>>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>>>>> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>>>>>>>>>>   *
>>>>>>>>>>   * @base: crtc object.
>>>>>>>>>>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
>>>>>>>>>> - * @enabled: if the crtc is enabled or not
>>>>>>>>>> - * @event: vblank event that is currently queued for flip
>>>>>>>>>> - * @wait_update: wait all pending planes updates to finish
>>>>>>>>>> - * @pending_update: number of pending plane updates in this crtc
>>>>>>>>&g

Re: [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

[Tobias Jakobi]

Hello Inki,

Inki Dae wrote:

> Tobias, why did you post the patch set 1/2 and 2/2 before?
> If these patches can be applied independently - you found out later - then 
> you need to clarify why you posted them separately.


after I posted v1 of the patchset, Andrzej responded with a Reviewed-By
for patch 1/2 and suggestions for patch 2/2. I then integrated the
suggestions and added the Reviewed-By tag, hence changing both patch 1/2
and 2/2. I then posted v2 of the patchset, because _both_ patches
changed. Andrzej then pointed out that the values used in patch 2/2
could be further simplied. I then posted a v3 of patch 2/2, because only
this one patch changed.
When I pinged you concerning the patches, I specifically did this with
v3 of 2/2, and v2 of 1/2. It was perfectly clear which patches I wanted
you to pick up.
I can understand when maintainers of high-volume subsystems sometimes
get patch versions mixed up. But drm-exynos only gets very few patches
each cycle. If you have problems dealing with your maintainer duties in
a timely manner, I would suggest to contact Daniel Vetter so that exynos
is added to drm-misc. I personally think exynos would benefit from such
a move.

With best wishes,
Tobias



> 
> Thanks,
> Inki Dae
> 
>>
>>
>>>
>>> I can merge the new one - really trivial - but I think it'd be better you 
>>> to resend this patch series for other people.
>>>
>>> This patch set has been removed from my tree. Please resend (not v4) this 
>>> patch set like below,
>>> [PATCH v3 0/2] drm/exynos: clean up mixer driver??
>>> [PATCH v3 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()
>>> [PATCH v3 2/2] drm/exynos: mixer: document YCbCr magic numbers
>> Not necessary, just pick up the two patches which for which I already
>> pinged you. For you convenience, here are the two on dri-devel patchwork:
>> https://patchwork.kernel.org/patch/9617085/
>> https://patchwork.kernel.org/patch/9617493/
>>
>> - Tobias
>>
>>
>>
>>>
>>> Thanks,
>>> Inki Dae
>>>
>>>>
>>>> - Tobias
>>>>
>>>>
>>>>> Thanks,
>>>>> Inki Dae
>>>>>
>>>>>> With best wishes,
>>>>>> Tobias
>>>>>>
>>>>>>
>>>>>> Tobias Jakobi wrote:
>>>>>>> The output stage of the mixer uses YCbCr for the internal
>>>>>>> computations, which is the reason that some registers take
>>>>>>> YCbCr related data as input. In particular this applies
>>>>>>> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>>>>>>>
>>>>>>> Document the formatting of the data which we write to
>>>>>>> these registers.
>>>>>>>
>>>>>>> While at it, unify wording of comments in the register header.
>>>>>>>
>>>>>>> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
>>>>>>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>>>>>>> ---
>>>>>>> Changes in v2:
>>>>>>> - use floating point values as input for the macros, as
>>>>>>>   suggested by Andrzej
>>>>>>> - the floating point values have been tuned to exactly match
>>>>>>>   the values that are currently used
>>>>>>>
>>>>>>> Changes in v3:
>>>>>>> - use only three digit values (pointed out by Andrzej)
>>>>>>>
>>>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 
>>>>>>> +
>>>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |  7 +--
>>>>>>>  2 files changed, 30 insertions(+), 10 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> index 41d0c36..9648dd5 100644
>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>>>> @@ -45,6 +45,22 @@
>>>>>>>  #define MIXER_WIN_NR 3
>>>>>>>  #define VP_DEFAULT_WIN   2
>>>>>>>
>>>>>>> +/*
>>>>>>> + * Mixer color space conversion coefficient triplet.
>>>>>>> + * Used for CSC from RGB to YCbCr.
>>>>>&g

Re: [RFC 0/8] drm/exynos: misc fixes and more

[Tobias Jakobi]

Hello Inki,

please don't forget to review this series.

Also some pointers concerning the video plane flickering and the
interlacing issue would be very welcome.

Looking at the current register defines for MXR_INT_EN suggests that
there are at least three more type of interrupt available. Any chance
these could be documented? I hope to get some more insight into this
issue, which apparantly is caused by insufficient bandwidth.

For the interlacing issue I have done partial progress. I now longer see
a IOMMU pagefault, but the video plane is heavily corrupted. Also the
dimensions look wrong.

While I can somehow guess that VP_MODE_LINE_SKIP does, the
VP_MODE_FIELD_ID_AUTO_TOGGLING flag still remains a mystery to me. If
possible, I request some documentation for this as well.


With best wishes,
Tobias



Tobias Jakobi wrote:
> Hello,
> 
> some recent work I did on Exynos. Patches are based on [1] and [2].
> 
> Summary:
> (a) Enables support for NV12MT in the mixer.
> (b) Sanitizes buffer pitch for HW with restrictions.
> (c) Misc fixes
> 
> While testing the NV12MT part, I made these interesting observations.
> 
> (1) I used 1920x1080 XRGB on the primary plane, and 1280x768 on the
> video plane. With this configuration, it does not matter if you're
> using NV12 or NV12MT, the video plane occasionally flickers or shows
> heavy artifacting. Reducing the size of the primary plane, e.g. to
> 32x32 solves this issue, so my guess is that this is memory bandwidth
> issue. Does someone know if one can check for buffer underflows of the
> mixer with respect to data passed from the VP?
> 
> (2) Using 1920x1080i (so an interlaced mode) and NV12, the board
> immediately dies with an IOMMU pagefault at address zero. I'm
> currently investigating this, and it looks like that the VP setup
> is wrong here. In particular it should be the source (!) height
> and vertical position that should be halfed in interlaced mode, and
> not the destination. Need to look more into this.
> 
> Anyway, both the issues are independant of the patches, so please
> review! :-)
> 
> With best wishes,
> Tobias
> 
> 
> [1] http://www.spinics.net/lists/linux-samsung-soc/msg58640.html
> [2] http://www.spinics.net/lists/linux-samsung-soc/msg58644.html
> 
> Tobias Jakobi (8):
>   drm/exynos: mixer: fix chroma comment in vp_video_buffer()
>   drm/exynos: mixer: enable NV12MT support for the video plane
>   drm/exynos: mixer: simplify {vp_video,mixer_graph}_buffer()
>   drm/exynos: mixer: remove src offset from mixer_graph_buffer()
>   drm/exynos: introduce BYTE_PITCH capability
>   drm/exynos: add BYTE_PITCH cap for all supported planes
>   drm/exynos: consistent use of cpp
>   drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers
> 
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 17 +--
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c| 13 +++-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 ++
>  drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 17 ---
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 ++
>  drivers/gpu/drm/exynos/exynos_mixer.c | 44 
> ---
>  7 files changed, 71 insertions(+), 61 deletions(-)
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Tobias Jakobi]

Another thing that I noticed. Why wasn't the v2 that ended up in your
git ever submitted to the mailing list? Because it should have, in
particular to spot these obvious errors.

- Tobias


Tobias Jakobi wrote:
> Inki Dae wrote:
>>
>>
>> 2017년 04월 10일 19:29에 Tobias Jakobi 이(가) 쓴 글:
>>> Inki Dae wrote:
>>>> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
>>>>> Hello Inki,
>>>>>
>>>>>
>>>>> Inki Dae wrote:
>>>>>> Hello Tobias,
>>>>>>
>>>>>>
>>>>>> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>>>>>>> Hello Inki,
>>>>>>>
>>>>>>>
>>>>>>> Inki Dae wrote:
>>>>>>>> This patch removes unnecessary descriptions on
>>>>>>>> exynos_drm_crtc structure and adds one description
>>>>>>>> which specifies what pipe_clk member does.
>>>>>>>>
>>>>>>>> pipe_clk support had been added by below patch without any description,
>>>>>>>>  drm/exynos: add support for pipeline clock to the framework
>>>>>>> I would put the commit id here. That makes it easier to look up the
>>>>>>> commit your refer to.
>>>>>>>
>>>>>>>
>>>>>>>> Signed-off-by: Inki Dae <inki@samsung.com>
>>>>>>>> ---
>>>>>>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>>>>>>>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>>>>>>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>>> index 527bf1d..b0462cc 100644
>>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>>> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>>>>>>>>   *
>>>>>>>>   * @base: crtc object.
>>>>>>>>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
>>>>>>>> - * @enabled: if the crtc is enabled or not
>>>>>>>> - * @event: vblank event that is currently queued for flip
>>>>>>>> - * @wait_update: wait all pending planes updates to finish
>>>>>>>> - * @pending_update: number of pending plane updates in this crtc
>>>>>>>>   * @ops: pointer to callbacks for exynos drm specific functionality
>>>>>>>>   * @ctx: A pointer to the crtc's implementation specific context
>>>>>>>> + * @pipe_clk: A pipe clock structure which includes a callback 
>>>>>>>> function
>>>>>>>> + for enabling DP clock of FIMD and HDMI PHY clock.
>>>>>>> This is wrong/inconsistent with the rest of the documentation. pipe_clk
>>>>>>> is not a struct, but a pointer.
>>>>>>>
>>>>>>> I would suggest to follow. Just document that we have a pointer to >>>>>> escription> here (compare docu for 'ops' and 'ctx').
>>>>>>> And then put the later bits ("...callback function for enabling DP
>>>>>>> clock...") directly to the definition of 'struct exynos_drm_clk' (which
>>>>>>> is currently lacking any kind of docu).
>>>>>>
>>>>>> Thanks for pointing it out. My mistake. :)
>>>>>>
>>>>>> How about this simply?
>>>>>> "A pointer to exynos_drm_clk structure for enabling and disabling DP 
>>>>>> clock of FIMD and HDMI PHY clocks"
>>>>> Not what I meant. You're describing 'struct exynos_drm_clk', and that
>>>>> does not belong here. If you describe 'struct exynos_drm_clk', then this
>>>>> should go in front of the struct's definition.
>>>>>
>>>>> How abouting something like this in front of the struct's definition::
>>>>>> /*
>>>>>>  * Exynos DRM pipeline clock structure.
>>>>>>  *
>>>>>>  * @enable: callback to enable/disable the clock.
>>>>>>  *
>>>>>>  * Used for proper clock synchronization of components belonging
>>>>>>  * to the same pipeline

Re: [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

[Tobias Jakobi]

Inki Dae wrote:
> 
> 
> 2017년 04월 10일 19:27에 Tobias Jakobi 이(가) 쓴 글:
>> Inki Dae wrote:
>>> 2017-03-29 20:56 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
>>>> Hello Daniel,
>>>>
>>>> same question here. Patch doesn't introduce any functional changes (just
>>>> adds code documentation), so can you merge it through drm-misc?
>>>>
>>>
>>> Sorry for late. Confirmed just now. I will check it on next Monday.
>> You have added the wrong patch (v2 instead of v3).
> 
> Tobias,
> 
> you had posted this patch with other one like below,
> [PATCH v2 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()
> [PATCH v2 2/2] drm/exynos: mixer: document YCbCr magic numbers
> 
> And than you have posted it without any comment again, v3,
> [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers
> 
> Please use --cover-letter option to make patch series and keep the patch set 
> to be consistent with previous version.
This is not necessary. There were only changes to 'drm/exynos: mixer:
document YCbCr magic numbers' and we're talking about _two_ patches here
(which can be applied independently).


> 
> I can merge the new one - really trivial - but I think it'd be better you to 
> resend this patch series for other people.
> 
> This patch set has been removed from my tree. Please resend (not v4) this 
> patch set like below,
> [PATCH v3 0/2] drm/exynos: clean up mixer driver??
> [PATCH v3 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()
> [PATCH v3 2/2] drm/exynos: mixer: document YCbCr magic numbers
Not necessary, just pick up the two patches which for which I already
pinged you. For you convenience, here are the two on dri-devel patchwork:
https://patchwork.kernel.org/patch/9617085/
https://patchwork.kernel.org/patch/9617493/

- Tobias



> 
> Thanks,
> Inki Dae
> 
>>
>> - Tobias
>>
>>
>>> Thanks,
>>> Inki Dae
>>>
>>>> With best wishes,
>>>> Tobias
>>>>
>>>>
>>>> Tobias Jakobi wrote:
>>>>> The output stage of the mixer uses YCbCr for the internal
>>>>> computations, which is the reason that some registers take
>>>>> YCbCr related data as input. In particular this applies
>>>>> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>>>>>
>>>>> Document the formatting of the data which we write to
>>>>> these registers.
>>>>>
>>>>> While at it, unify wording of comments in the register header.
>>>>>
>>>>> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
>>>>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>>>>> ---
>>>>> Changes in v2:
>>>>> - use floating point values as input for the macros, as
>>>>>   suggested by Andrzej
>>>>> - the floating point values have been tuned to exactly match
>>>>>   the values that are currently used
>>>>>
>>>>> Changes in v3:
>>>>> - use only three digit values (pointed out by Andrzej)
>>>>>
>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 
>>>>> +
>>>>>  drivers/gpu/drm/exynos/regs-mixer.h   |  7 +--
>>>>>  2 files changed, 30 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> index 41d0c36..9648dd5 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>>>> @@ -45,6 +45,22 @@
>>>>>  #define MIXER_WIN_NR 3
>>>>>  #define VP_DEFAULT_WIN   2
>>>>>
>>>>> +/*
>>>>> + * Mixer color space conversion coefficient triplet.
>>>>> + * Used for CSC from RGB to YCbCr.
>>>>> + * Each coefficient is a 10-bit fixed point number with
>>>>> + * sign and no integer part, i.e.
>>>>> + * [0:8] = fractional part (representing a value y = x / 2^9)
>>>>> + * [9] = sign
>>>>> + * Negative values are encoded with two's complement.
>>>>> + */
>>>>> +#define MXR_CSC_C(x) ((int)((x) * 512.0) & 0x3ff)
>>>>> +#define MXR_CSC_CT(a0, a1, a2) \
>>>>> +  ((MXR_CSC_C(a0) << 20) | (MXR_CSC_C(a1) << 10) | (MXR_CSC_C(a2) << 0))
>>>>> +
>>>>&g

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Tobias Jakobi]

Inki Dae wrote:
> 
> 
> 2017년 04월 10일 19:29에 Tobias Jakobi 이(가) 쓴 글:
>> Inki Dae wrote:
>>> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
>>>> Hello Inki,
>>>>
>>>>
>>>> Inki Dae wrote:
>>>>> Hello Tobias,
>>>>>
>>>>>
>>>>> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>>>>>> Hello Inki,
>>>>>>
>>>>>>
>>>>>> Inki Dae wrote:
>>>>>>> This patch removes unnecessary descriptions on
>>>>>>> exynos_drm_crtc structure and adds one description
>>>>>>> which specifies what pipe_clk member does.
>>>>>>>
>>>>>>> pipe_clk support had been added by below patch without any description,
>>>>>>>  drm/exynos: add support for pipeline clock to the framework
>>>>>> I would put the commit id here. That makes it easier to look up the
>>>>>> commit your refer to.
>>>>>>
>>>>>>
>>>>>>> Signed-off-by: Inki Dae <inki@samsung.com>
>>>>>>> ---
>>>>>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>>>>>>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>>>>>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>> index 527bf1d..b0462cc 100644
>>>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>>>> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>>>>>>>   *
>>>>>>>   * @base: crtc object.
>>>>>>>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
>>>>>>> - * @enabled: if the crtc is enabled or not
>>>>>>> - * @event: vblank event that is currently queued for flip
>>>>>>> - * @wait_update: wait all pending planes updates to finish
>>>>>>> - * @pending_update: number of pending plane updates in this crtc
>>>>>>>   * @ops: pointer to callbacks for exynos drm specific functionality
>>>>>>>   * @ctx: A pointer to the crtc's implementation specific context
>>>>>>> + * @pipe_clk: A pipe clock structure which includes a callback function
>>>>>>> + for enabling DP clock of FIMD and HDMI PHY clock.
>>>>>> This is wrong/inconsistent with the rest of the documentation. pipe_clk
>>>>>> is not a struct, but a pointer.
>>>>>>
>>>>>> I would suggest to follow. Just document that we have a pointer to >>>>> escription> here (compare docu for 'ops' and 'ctx').
>>>>>> And then put the later bits ("...callback function for enabling DP
>>>>>> clock...") directly to the definition of 'struct exynos_drm_clk' (which
>>>>>> is currently lacking any kind of docu).
>>>>>
>>>>> Thanks for pointing it out. My mistake. :)
>>>>>
>>>>> How about this simply?
>>>>> "A pointer to exynos_drm_clk structure for enabling and disabling DP 
>>>>> clock of FIMD and HDMI PHY clocks"
>>>> Not what I meant. You're describing 'struct exynos_drm_clk', and that
>>>> does not belong here. If you describe 'struct exynos_drm_clk', then this
>>>> should go in front of the struct's definition.
>>>>
>>>> How abouting something like this in front of the struct's definition::
>>>>> /*
>>>>>  * Exynos DRM pipeline clock structure.
>>>>>  *
>>>>>  * @enable: callback to enable/disable the clock.
>>>>>  *
>>>>>  * Used for proper clock synchronization of components belonging
>>>>>  * to the same pipeline. Used e.g. for enabling the DP clock of
>>>>>  * the FIMD or the HDMI PHY clock.
>>>>>  */
>>>>> struct exynos_drm_clk {
>>>>> 
>>>>
>>>> For 'pipe_clk' I would just go with this:
>>>>> @pipe_clk: A pointet to the crtc's pipeline clock.
>>>
>>> More simple and looks better.
>> In this form (commit a07d468cb2efd347a9e279e4f68661f0f370d10f in
>> exynos-drm-next), the description is incomplete. Please read my mails again.
>

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Tobias Jakobi]

Inki Dae wrote:
> 2017-04-07 20:40 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>> Hello Tobias,
>>>
>>>
>>> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>>>> Hello Inki,
>>>>
>>>>
>>>> Inki Dae wrote:
>>>>> This patch removes unnecessary descriptions on
>>>>> exynos_drm_crtc structure and adds one description
>>>>> which specifies what pipe_clk member does.
>>>>>
>>>>> pipe_clk support had been added by below patch without any description,
>>>>>  drm/exynos: add support for pipeline clock to the framework
>>>> I would put the commit id here. That makes it easier to look up the
>>>> commit your refer to.
>>>>
>>>>
>>>>> Signed-off-by: Inki Dae <inki@samsung.com>
>>>>> ---
>>>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>>>>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>>>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>> index 527bf1d..b0462cc 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>>>> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>>>>>   *
>>>>>   * @base: crtc object.
>>>>>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
>>>>> - * @enabled: if the crtc is enabled or not
>>>>> - * @event: vblank event that is currently queued for flip
>>>>> - * @wait_update: wait all pending planes updates to finish
>>>>> - * @pending_update: number of pending plane updates in this crtc
>>>>>   * @ops: pointer to callbacks for exynos drm specific functionality
>>>>>   * @ctx: A pointer to the crtc's implementation specific context
>>>>> + * @pipe_clk: A pipe clock structure which includes a callback function
>>>>> + for enabling DP clock of FIMD and HDMI PHY clock.
>>>> This is wrong/inconsistent with the rest of the documentation. pipe_clk
>>>> is not a struct, but a pointer.
>>>>
>>>> I would suggest to follow. Just document that we have a pointer to >>> escription> here (compare docu for 'ops' and 'ctx').
>>>> And then put the later bits ("...callback function for enabling DP
>>>> clock...") directly to the definition of 'struct exynos_drm_clk' (which
>>>> is currently lacking any kind of docu).
>>>
>>> Thanks for pointing it out. My mistake. :)
>>>
>>> How about this simply?
>>> "A pointer to exynos_drm_clk structure for enabling and disabling DP clock 
>>> of FIMD and HDMI PHY clocks"
>> Not what I meant. You're describing 'struct exynos_drm_clk', and that
>> does not belong here. If you describe 'struct exynos_drm_clk', then this
>> should go in front of the struct's definition.
>>
>> How abouting something like this in front of the struct's definition::
>>> /*
>>>  * Exynos DRM pipeline clock structure.
>>>  *
>>>  * @enable: callback to enable/disable the clock.
>>>  *
>>>  * Used for proper clock synchronization of components belonging
>>>  * to the same pipeline. Used e.g. for enabling the DP clock of
>>>  * the FIMD or the HDMI PHY clock.
>>>  */
>>> struct exynos_drm_clk {
>>> 
>>
>> For 'pipe_clk' I would just go with this:
>>> @pipe_clk: A pointet to the crtc's pipeline clock.
> 
> More simple and looks better.
In this form (commit a07d468cb2efd347a9e279e4f68661f0f370d10f in
exynos-drm-next), the description is incomplete. Please read my mails again.

- Tobias


> 
> Thanks,
> Inki Dae
> 
>>
>> I hope this helps.
>>
>> - Tobias
>>
>>
>>> Thanks,
>>> Inki Dae
>>>
>>>>
>>>>
>>>> - Tobias
>>>>
>>>>>   */
>>>>>  struct exynos_drm_crtc {
>>>>> struct drm_crtc base;
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

[Tobias Jakobi]

Inki Dae wrote:
> 2017-03-29 20:56 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
>> Hello Daniel,
>>
>> same question here. Patch doesn't introduce any functional changes (just
>> adds code documentation), so can you merge it through drm-misc?
>>
> 
> Sorry for late. Confirmed just now. I will check it on next Monday.
You have added the wrong patch (v2 instead of v3).

- Tobias


> Thanks,
> Inki Dae
> 
>> With best wishes,
>> Tobias
>>
>>
>> Tobias Jakobi wrote:
>>> The output stage of the mixer uses YCbCr for the internal
>>> computations, which is the reason that some registers take
>>> YCbCr related data as input. In particular this applies
>>> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>>>
>>> Document the formatting of the data which we write to
>>> these registers.
>>>
>>> While at it, unify wording of comments in the register header.
>>>
>>> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
>>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>>> ---
>>> Changes in v2:
>>> - use floating point values as input for the macros, as
>>>   suggested by Andrzej
>>> - the floating point values have been tuned to exactly match
>>>   the values that are currently used
>>>
>>> Changes in v3:
>>> - use only three digit values (pointed out by Andrzej)
>>>
>>>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 
>>> +
>>>  drivers/gpu/drm/exynos/regs-mixer.h   |  7 +--
>>>  2 files changed, 30 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 41d0c36..9648dd5 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -45,6 +45,22 @@
>>>  #define MIXER_WIN_NR 3
>>>  #define VP_DEFAULT_WIN   2
>>>
>>> +/*
>>> + * Mixer color space conversion coefficient triplet.
>>> + * Used for CSC from RGB to YCbCr.
>>> + * Each coefficient is a 10-bit fixed point number with
>>> + * sign and no integer part, i.e.
>>> + * [0:8] = fractional part (representing a value y = x / 2^9)
>>> + * [9] = sign
>>> + * Negative values are encoded with two's complement.
>>> + */
>>> +#define MXR_CSC_C(x) ((int)((x) * 512.0) & 0x3ff)
>>> +#define MXR_CSC_CT(a0, a1, a2) \
>>> +  ((MXR_CSC_C(a0) << 20) | (MXR_CSC_C(a1) << 10) | (MXR_CSC_C(a2) << 0))
>>> +
>>> +/* YCbCr value, used for mixer background color configuration. */
>>> +#define MXR_YCBCR_VAL(y, cb, cr) (((y) << 16) | ((cb) << 8) | ((cr) << 0))
>>> +
>>>  /* The pixelformats that are natively supported by the mixer. */
>>>  #define MXR_FORMAT_RGB5654
>>>  #define MXR_FORMAT_ARGB1555  5
>>> @@ -391,13 +407,14 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
>>> *ctx, unsigned int height)
>>>   case 1080:
>>>   default:
>>>   val = MXR_CFG_RGB709_16_235;
>>> + /* Configure the BT.709 CSC matrix for full range RGB. */
>>>   mixer_reg_write(res, MXR_CM_COEFF_Y,
>>> - (1 << 30) | (94 << 20) | (314 << 10) |
>>> - (32 << 0));
>>> + MXR_CSC_CT( 0.184,  0.614,  0.063) |
>>> + MXR_CM_COEFF_RGB_FULL);
>>>   mixer_reg_write(res, MXR_CM_COEFF_CB,
>>> - (972 << 20) | (851 << 10) | (225 << 0));
>>> + MXR_CSC_CT(-0.102, -0.338,  0.440));
>>>   mixer_reg_write(res, MXR_CM_COEFF_CR,
>>> - (225 << 20) | (820 << 10) | (1004 << 0));
>>> + MXR_CSC_CT( 0.440, -0.399, -0.040));
>>>   break;
>>>   }
>>>
>>> @@ -715,10 +732,10 @@ static void mixer_win_reset(struct mixer_context *ctx)
>>>   /* reset default layer priority */
>>>   mixer_reg_write(res, MXR_LAYER_CFG, 0);
>>>
>>> - /* setting background color */
>>> - mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
>>> - mixer_reg_write(res, MXR_BG_COLOR1, 0x008080);
>>> - mixer_reg_write(res, MXR_BG_COLOR2, 0x0080

Re: [PATCH] exynos: add C++ support to exynos_drmif header

[Tobias Jakobi]

Emil Velikov wrote:
> FTR, only the installed headers (~50) need the extern C guard.
> None of that is not a blocker for this patch, so I've just pushed it to 
> master.
Thanks Emil. I'll see what I can do about the other ones.

- Tobias


> Thanks!
> Emil
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Tobias Jakobi]

Hello Inki,


Inki Dae wrote:
> Hello Tobias,
> 
> 
> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글:
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>> This patch removes unnecessary descriptions on
>>> exynos_drm_crtc structure and adds one description
>>> which specifies what pipe_clk member does.
>>>
>>> pipe_clk support had been added by below patch without any description,
>>>  drm/exynos: add support for pipeline clock to the framework
>> I would put the commit id here. That makes it easier to look up the
>> commit your refer to.
>>
>>
>>> Signed-off-by: Inki Dae <inki@samsung.com>
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>> index 527bf1d..b0462cc 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>>>   *
>>>   * @base: crtc object.
>>>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
>>> - * @enabled: if the crtc is enabled or not
>>> - * @event: vblank event that is currently queued for flip
>>> - * @wait_update: wait all pending planes updates to finish
>>> - * @pending_update: number of pending plane updates in this crtc
>>>   * @ops: pointer to callbacks for exynos drm specific functionality
>>>   * @ctx: A pointer to the crtc's implementation specific context
>>> + * @pipe_clk: A pipe clock structure which includes a callback function
>>> + for enabling DP clock of FIMD and HDMI PHY clock.
>> This is wrong/inconsistent with the rest of the documentation. pipe_clk
>> is not a struct, but a pointer.
>>
>> I would suggest to follow. Just document that we have a pointer to > escription> here (compare docu for 'ops' and 'ctx').
>> And then put the later bits ("...callback function for enabling DP
>> clock...") directly to the definition of 'struct exynos_drm_clk' (which
>> is currently lacking any kind of docu).
> 
> Thanks for pointing it out. My mistake. :)
> 
> How about this simply?
> "A pointer to exynos_drm_clk structure for enabling and disabling DP clock of 
> FIMD and HDMI PHY clocks"
Not what I meant. You're describing 'struct exynos_drm_clk', and that
does not belong here. If you describe 'struct exynos_drm_clk', then this
should go in front of the struct's definition.

How abouting something like this in front of the struct's definition::
> /*
>  * Exynos DRM pipeline clock structure.
>  *
>  * @enable: callback to enable/disable the clock.
>  *
>  * Used for proper clock synchronization of components belonging
>  * to the same pipeline. Used e.g. for enabling the DP clock of
>  * the FIMD or the HDMI PHY clock.
>  */
> struct exynos_drm_clk {
> 

For 'pipe_clk' I would just go with this:
> @pipe_clk: A pointet to the crtc's pipeline clock. 

I hope this helps.

- Tobias


> Thanks,
> Inki Dae
> 
>>
>>
>> - Tobias
>>
>>>   */
>>>  struct exynos_drm_crtc {
>>> struct drm_crtc base;
>>>
>>
>>
>>
>>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

[Tobias Jakobi]

Hello Inki,


Inki Dae wrote:
> This patch removes unnecessary descriptions on
> exynos_drm_crtc structure and adds one description
> which specifies what pipe_clk member does.
> 
> pipe_clk support had been added by below patch without any description,
>drm/exynos: add support for pipeline clock to the framework
I would put the commit id here. That makes it easier to look up the
commit your refer to.


> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 527bf1d..b0462cc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>   *
>   * @base: crtc object.
>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
> - * @enabled: if the crtc is enabled or not
> - * @event: vblank event that is currently queued for flip
> - * @wait_update: wait all pending planes updates to finish
> - * @pending_update: number of pending plane updates in this crtc
>   * @ops: pointer to callbacks for exynos drm specific functionality
>   * @ctx: A pointer to the crtc's implementation specific context
> + * @pipe_clk: A pipe clock structure which includes a callback function
> +   for enabling DP clock of FIMD and HDMI PHY clock.
This is wrong/inconsistent with the rest of the documentation. pipe_clk
is not a struct, but a pointer.

I would suggest to follow. Just document that we have a pointer to  here (compare docu for 'ops' and 'ctx').
And then put the later bits ("...callback function for enabling DP
clock...") directly to the definition of 'struct exynos_drm_clk' (which
is currently lacking any kind of docu).


- Tobias

>   */
>  struct exynos_drm_crtc {
>   struct drm_crtc base;
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] exynos: add C++ support to exynos_drmif header

[Tobias Jakobi]

Hello Eric,


Eric Engestrom wrote:
> On Wednesday, 2017-04-05 16:22:24 +0200, Tobias Jakobi wrote:
>> Add the usual extern "C" when compiling in C++ mode.
> 
> Thanks, but why specifically this header? The other exynos/*.h headers
> also lack the c++ mangling guard.
I'm currently writing a small C++ project using the
exynos_bo_{create,destroy}() calls, and noticed this.

> A quick grep shows that only 15/101 headers in libdrm have it.
> Can I interest you in fixing a few more headers? :)
Not at the moment.


- Tobias

> In any case, this patch is:
> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>
> (I assume you'll push it yourself?)
> 
> Btw, can you run this in your local libdrm repo?
>   $ git config --local format.subjectPrefix "PATCH libdrm"
> 
> Cheers,
>   Eric
> 
> 
>>
>> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
>> ---
>>  exynos/exynos_drmif.h | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/exynos/exynos_drmif.h b/exynos/exynos_drmif.h
>> index 626e399..154439b 100644
>> --- a/exynos/exynos_drmif.h
>> +++ b/exynos/exynos_drmif.h
>> @@ -31,6 +31,10 @@
>>  #include 
>>  #include "exynos_drm.h"
>>  
>> +#if defined(__cplusplus)
>> +extern "C" {
>> +#endif
>> +
>>  struct exynos_device {
>>  int fd;
>>  };
>> @@ -109,4 +113,8 @@ int exynos_handle_event(struct exynos_device *dev,
>>  struct exynos_event_context *ctx);
>>  
>>  
>> +#if defined(__cplusplus)
>> +}
>> +#endif
>> +
>>  #endif /* EXYNOS_DRMIF_H_ */
>> -- 
>> 2.7.3
>>

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] exynos: add C++ support to exynos_drmif header

[Tobias Jakobi]

Add the usual extern "C" when compiling in C++ mode.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 exynos/exynos_drmif.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/exynos/exynos_drmif.h b/exynos/exynos_drmif.h
index 626e399..154439b 100644
--- a/exynos/exynos_drmif.h
+++ b/exynos/exynos_drmif.h
@@ -31,6 +31,10 @@
 #include 
 #include "exynos_drm.h"
 
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
 struct exynos_device {
int fd;
 };
@@ -109,4 +113,8 @@ int exynos_handle_event(struct exynos_device *dev,
struct exynos_event_context *ctx);
 
 
+#if defined(__cplusplus)
+}
+#endif
+
 #endif /* EXYNOS_DRMIF_H_ */
-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 8/8] drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

[Tobias Jakobi]

DRM core already checks the validity of the pixelformat.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 7 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 8 +---
 3 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 4343252..7efa92d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -238,13 +238,11 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_ARGB:
+   default:
val |= WINCONx_BPPMODE_32BPP_A;
val |= WINCONx_WSWP_F | WINCONx_BLD_PIX_F | WINCONx_ALPHA_SEL_F;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_ERROR("Proper pixel format is not set\n");
-   return;
}
 
DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index c6d06cc..0d60e38 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -318,16 +318,11 @@ static void decon_win_set_pixfmt(struct decon_context 
*ctx, unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_BGRA:
+   default:
val |= WINCONx_BPPMODE_32BPP_BGRA | WINCONx_BLD_PIX |
WINCONx_ALPHA_SEL;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_DEBUG_KMS("invalid pixel size so using unpacked 24bpp.\n");
-
-   val |= WINCONx_BPPMODE_24BPP_xRGB;
-   val |= WINCONx_BURSTLEN_16WORD;
-   break;
}
 
DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 098a32d..0529c58 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -603,18 +603,12 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx, 
unsigned int win,
val |= WINCONx_BURSTLEN_16WORD;
break;
case DRM_FORMAT_ARGB:
+   default:
val |= WINCON1_BPPMODE_25BPP_A1888
| WINCON1_BLD_PIX | WINCON1_ALPHA_SEL;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
-   default:
-   DRM_DEBUG_KMS("invalid pixel size so using unpacked 24bpp.\n");
-
-   val |= WINCON0_BPPMODE_24BPP_888;
-   val |= WINCONx_WSWP;
-   val |= WINCONx_BURSTLEN_16WORD;
-   break;
}
 
/*
-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 7/8] drm/exynos: consistent use of cpp

[Tobias Jakobi]

A recent commit (272725c7db4da1fd3229d944fc76d2e98e3a144e) has removed
the use of 'bits_per_pixel' in DRM. However the corresponding Exynos
driver code still uses the ambiguous 'bpp', even though it is now
initialized from fb->cpp[0].

Consistenly use 'cpp' in FIMD, DECON7 and DECON5433 drivers.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 12 ++--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  6 +++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  8 
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 099e22e..4343252 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -247,7 +247,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
return;
}
 
-   DRM_DEBUG_KMS("bpp = %u\n", fb->format->cpp[0] * 8);
+   DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -296,7 +296,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
struct decon_context *ctx = crtc->ctx;
struct drm_framebuffer *fb = state->base.fb;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
u32 val;
@@ -335,11 +335,11 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));
 
if (!(ctx->out_type & IFTYPE_HDMI))
-   val = BIT_VAL(pitch - state->crtc.w * bpp, 27, 14)
-   | BIT_VAL(state->crtc.w * bpp, 13, 0);
+   val = BIT_VAL(pitch - state->crtc.w * cpp, 27, 14)
+   | BIT_VAL(state->crtc.w * cpp, 13, 0);
else
-   val = BIT_VAL(pitch - state->crtc.w * bpp, 29, 15)
-   | BIT_VAL(state->crtc.w * bpp, 14, 0);
+   val = BIT_VAL(pitch - state->crtc.w * cpp, 29, 15)
+   | BIT_VAL(state->crtc.w * cpp, 14, 0);
writel(val, ctx->addr + DECON_VIDW0xADD2(win));
 
decon_win_set_pixfmt(ctx, win, fb);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f9ab19e..c6d06cc 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -330,7 +330,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx, 
unsigned int win,
break;
}
 
-   DRM_DEBUG_KMS("bpp = %d\n", fb->format->cpp[0] * 8);
+   DRM_DEBUG_KMS("cpp = %d\n", fb->format->cpp[0]);
 
/*
 * In case of exynos, setting dma-burst to 16Word causes permanent
@@ -407,7 +407,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int last_x;
unsigned int last_y;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
 
if (ctx->suspended)
@@ -427,7 +427,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
val = (unsigned long)exynos_drm_fb_dma_addr(fb, 0);
writel(val, ctx->regs + VIDW_BUF_START(win));
 
-   padding = (pitch / bpp) - fb->width;
+   padding = (pitch / cpp) - fb->width;
 
/* buffer size */
writel(fb->width + padding, ctx->regs + VIDW_WHOLE_X(win));
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index ae738b8..098a32d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -736,13 +736,13 @@ static void fimd_update_plane(struct exynos_drm_crtc 
*crtc,
unsigned long val, size, offset;
unsigned int last_x, last_y, buf_offsize, line_size;
unsigned int win = plane->index;
-   unsigned int bpp = fb->format->cpp[0];
+   unsigned int cpp = fb->format->cpp[0];
unsigned int pitch = fb->pitches[0];
 
if (ctx->suspended)
return;
 
-   offset = state->src.x * bpp;
+   offset = state->src.x * cpp;
offset += state->src.y * pitch;
 
/* buffer start address */
@@ -761,8 +761,8 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
state->crtc.w, state->crtc.h);
 
/* buffer size */
-   buf_offsize = pitch - (state->crtc.w * bpp);
-   line_size = state

[RFC 6/8] drm/exynos: add BYTE_PITCH cap for all supported planes

[Tobias Jakobi]

Both FIMD and DECON5433 support a pitch in bytes.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 0fd6f7a..099e22e 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -533,6 +533,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[win].num_pixel_formats = ARRAY_SIZE(decon_formats);
ctx->configs[win].zpos = win;
ctx->configs[win].type = decon_win_types[tmp];
+   ctx->configs[win].capabilities = 
EXYNOS_DRM_PLANE_CAP_BYTE_PITCH;
 
ret = exynos_plane_init(drm_dev, >planes[win], win,
1 << ctx->pipe, >configs[win]);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a9fa444..ae738b8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1007,6 +1007,7 @@ static int fimd_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[i].num_pixel_formats = ARRAY_SIZE(fimd_formats);
ctx->configs[i].zpos = i;
ctx->configs[i].type = fimd_win_types[i];
+   ctx->configs[i].capabilities = EXYNOS_DRM_PLANE_CAP_BYTE_PITCH;
ret = exynos_plane_init(drm_dev, >planes[i], i,
1 << ctx->pipe, >configs[i]);
if (ret)
-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 5/8] drm/exynos: introduce BYTE_PITCH capability

[Tobias Jakobi]

In some of drivers we compute something like 'pitch / cpp' at some
point, silently assuming that the pitch (which is in bytes) is
divisible by the buffer's cpp. This is not always true, in particular
DRM core does not check for pitch alignment in the common case.

Introduce a new cap which signals that the hardware supports a
pitch with 'byte-granularity'. If the cap is not set, assume that
we need pitch aligned to cpp.

We set the cap later for the drivers/planes that support it.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index ee62b0b..8d957a9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -92,6 +92,7 @@ struct exynos_drm_plane {
 #define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
 #define EXYNOS_DRM_PLANE_CAP_ZPOS  (1 << 2)
 #define EXYNOS_DRM_PLANE_CAP_TILE  (1 << 3)
+#define EXYNOS_DRM_PLANE_CAP_BYTE_PITCH(1 << 4)
 
 /*
  * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index fa6333d..b31a226 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -185,6 +185,16 @@ exynos_drm_plane_check_format(const struct 
exynos_drm_plane_config *config,
 {
struct drm_framebuffer *fb = state->base.fb;
 
+   /*
+* Some blocks only allow to specify a buffer pitch in terms
+* of pixels. In these cases, we need to ensure that the pitch
+* provided by userspace is divisible by the cpp.
+*/
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_BYTE_PITCH)) {
+   if (fb->pitches[0] % fb->format->cpp[0])
+   return -ENOTSUPP;
+   }
+
switch (fb->modifier) {
case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 4/8] drm/exynos: mixer: remove src offset from mixer_graph_buffer()

[Tobias Jakobi]

We always translate the dma address such that the offsets of
the source image are zero. Hence we can remove manipulation of
the MXR_GRAPHIC_SXY(win) register.

We leave the register defines (in regs_mixer.h) in place, since
they document the hardware.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 32970fb..b712f2a 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -585,7 +585,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
unsigned long flags;
unsigned int win = plane->index;
unsigned int x_ratio = 0, y_ratio = 0;
-   unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
+   unsigned int dst_x_offset, dst_y_offset;
dma_addr_t dma_addr;
unsigned int fmt;
u32 val;
@@ -619,12 +619,10 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
dst_x_offset = state->crtc.x;
dst_y_offset = state->crtc.y;
 
-   /* converting dma address base and source offset */
+   /* translate dma address base s.t. the source image offset is zero */
dma_addr = exynos_drm_fb_dma_addr(fb, 0)
+ (state->src.x * fb->format->cpp[0])
+ (state->src.y * fb->pitches[0]);
-   src_x_offset = 0;
-   src_y_offset = 0;
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
__set_bit(MXR_BIT_INTERLACE, >flags);
@@ -655,11 +653,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
val |= MXR_GRP_WH_V_SCALE(y_ratio);
mixer_reg_write(res, MXR_GRAPHIC_WH(win), val);
 
-   /* setup offsets in source image */
-   val  = MXR_GRP_SXY_SX(src_x_offset);
-   val |= MXR_GRP_SXY_SY(src_y_offset);
-   mixer_reg_write(res, MXR_GRAPHIC_SXY(win), val);
-
/* setup offsets in display image */
val  = MXR_GRP_DXY_DX(dst_x_offset);
val |= MXR_GRP_DXY_DY(dst_y_offset);
-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 3/8] drm/exynos: mixer: simplify {vp_video, mixer_graph}_buffer()

[Tobias Jakobi]

DRM core already checks the validity of the pixelformats, to we
can simplify the checks here. The same applies to the FB modifier,
which is now check in common Exynos plane code.

Also rename the booleans to reflect what true/false actually
encodes.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++
 1 file changed, 7 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 35edbf2..32970fb 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -485,32 +485,18 @@ static void vp_video_buffer(struct mixer_context *ctx,
unsigned int priority = state->base.normalized_zpos + 1;
unsigned long flags;
dma_addr_t luma_addr[2], chroma_addr[2];
-   bool tiled_mode = false;
-   bool crcb_mode = false;
+   bool is_tiled, is_nv21;
u32 val;
 
-   switch (fb->format->format) {
-   case DRM_FORMAT_NV12:
-   crcb_mode = false;
-   break;
-   case DRM_FORMAT_NV21:
-   crcb_mode = true;
-   break;
-   default:
-   DRM_ERROR("pixel format for vp is wrong [%d].\n",
-   fb->format->format);
-   return;
-   }
-
-   if (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
-   tiled_mode = true;
+   is_nv21 = (fb->format->format == DRM_FORMAT_NV21);
+   is_tiled = (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE);
 
luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE) {
__set_bit(MXR_BIT_INTERLACE, >flags);
-   if (tiled_mode) {
+   if (is_tiled) {
luma_addr[1] = luma_addr[0] + 0x40;
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
@@ -530,8 +516,8 @@ static void vp_video_buffer(struct mixer_context *ctx,
vp_reg_writemask(res, VP_MODE, val, VP_MODE_LINE_SKIP);
 
/* setup format */
-   val = (crcb_mode ? VP_MODE_NV21 : VP_MODE_NV12);
-   val |= (tiled_mode ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
+   val = (is_nv21 ? VP_MODE_NV21 : VP_MODE_NV12);
+   val |= (is_tiled ? VP_MODE_MEM_TILED : VP_MODE_MEM_LINEAR);
vp_reg_writemask(res, VP_MODE, val, VP_MODE_FMT_MASK);
 
/* setting size of input image */
@@ -621,12 +607,9 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
 
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+   default:
fmt = MXR_FORMAT_ARGB;
break;
-
-   default:
-   DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
-   return;
}
 
/* ratio is already checked by common plane code */
-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 2/8] drm/exynos: mixer: enable NV12MT support for the video plane

[Tobias Jakobi]

The video processor supports a tiled variant of the NV12 format,
known as NV12MT in V4L2 terms. The support was removed in commit
083500baefd5f4c215a5a93aef2492c1aa775828 due to not being a real
pixel format, but rather NV12MT with a special memory layout.

With the introduction of FB modifiers, we can now properly support
this format again.

Tested with a hacked up modetest from libdrm's test suite on
an ODROID-X2 (Exynos4412).

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 27 +++
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 +-
 4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cf6e08c..ee62b0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -91,6 +91,7 @@ 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_TILE  (1 << 3)
 
 /*
  * Exynos DRM plane configuration structure.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index c77a5ac..35b7ab2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -238,4 +238,6 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
 
dev->mode_config.funcs = _drm_mode_config_funcs;
dev->mode_config.helper_private = _drm_mode_config_helpers;
+
+   dev->mode_config.allow_fb_modifiers = true;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index c2f17f3..fa6333d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -180,6 +180,29 @@ static struct drm_plane_funcs exynos_plane_funcs = {
 };
 
 static int
+exynos_drm_plane_check_format(const struct exynos_drm_plane_config *config,
+ struct exynos_drm_plane_state *state)
+{
+   struct drm_framebuffer *fb = state->base.fb;
+
+   switch (fb->modifier) {
+   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
+   if (!(config->capabilities & EXYNOS_DRM_PLANE_CAP_TILE))
+   return -ENOTSUPP;
+   break;
+
+   case 0:
+   break;
+
+   default:
+   DRM_ERROR("unsupported pixel format modifier");
+   return -ENOTSUPP;
+   }
+
+   return 0;
+}
+
+static int
 exynos_drm_plane_check_size(const struct exynos_drm_plane_config *config,
struct exynos_drm_plane_state *state)
 {
@@ -223,6 +246,10 @@ static int exynos_plane_atomic_check(struct drm_plane 
*plane,
/* translate state into exynos_state */
exynos_plane_mode_set(exynos_state);
 
+   ret = exynos_drm_plane_check_format(exynos_plane->config, exynos_state);
+   if (ret)
+   return ret;
+
ret = exynos_drm_plane_check_size(exynos_plane->config, exynos_state);
return ret;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 77f18f6..35edbf2 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -149,7 +149,8 @@ static const struct exynos_drm_plane_config 
plane_configs[MIXER_WIN_NR] = {
.pixel_formats = vp_formats,
.num_pixel_formats = ARRAY_SIZE(vp_formats),
.capabilities = EXYNOS_DRM_PLANE_CAP_SCALE |
-   EXYNOS_DRM_PLANE_CAP_ZPOS,
+   EXYNOS_DRM_PLANE_CAP_ZPOS |
+   EXYNOS_DRM_PLANE_CAP_TILE,
},
 };
 
@@ -501,6 +502,9 @@ static void vp_video_buffer(struct mixer_context *ctx,
return;
}
 
+   if (fb->modifier == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
+   tiled_mode = true;
+
luma_addr[0] = exynos_drm_fb_dma_addr(fb, 0);
chroma_addr[0] = exynos_drm_fb_dma_addr(fb, 1);
 
-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/8] drm/exynos: misc fixes and more

[Tobias Jakobi]

Hello,

some recent work I did on Exynos. Patches are based on [1] and [2].

Summary:
(a) Enables support for NV12MT in the mixer.
(b) Sanitizes buffer pitch for HW with restrictions.
(c) Misc fixes

While testing the NV12MT part, I made these interesting observations.

(1) I used 1920x1080 XRGB on the primary plane, and 1280x768 on the
video plane. With this configuration, it does not matter if you're
using NV12 or NV12MT, the video plane occasionally flickers or shows
heavy artifacting. Reducing the size of the primary plane, e.g. to
32x32 solves this issue, so my guess is that this is memory bandwidth
issue. Does someone know if one can check for buffer underflows of the
mixer with respect to data passed from the VP?

(2) Using 1920x1080i (so an interlaced mode) and NV12, the board
immediately dies with an IOMMU pagefault at address zero. I'm
currently investigating this, and it looks like that the VP setup
is wrong here. In particular it should be the source (!) height
and vertical position that should be halfed in interlaced mode, and
not the destination. Need to look more into this.

Anyway, both the issues are independant of the patches, so please
review! :-)

With best wishes,
Tobias


[1] http://www.spinics.net/lists/linux-samsung-soc/msg58640.html
[2] http://www.spinics.net/lists/linux-samsung-soc/msg58644.html

Tobias Jakobi (8):
  drm/exynos: mixer: fix chroma comment in vp_video_buffer()
  drm/exynos: mixer: enable NV12MT support for the video plane
  drm/exynos: mixer: simplify {vp_video,mixer_graph}_buffer()
  drm/exynos: mixer: remove src offset from mixer_graph_buffer()
  drm/exynos: introduce BYTE_PITCH capability
  drm/exynos: add BYTE_PITCH cap for all supported planes
  drm/exynos: consistent use of cpp
  drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 17 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 13 +++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 17 ---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 37 ++
 drivers/gpu/drm/exynos/exynos_mixer.c | 44 ---
 7 files changed, 71 insertions(+), 61 deletions(-)

-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 1/8] drm/exynos: mixer: fix chroma comment in vp_video_buffer()

[Tobias Jakobi]

The current comment sounds like the division is done to
compensate for some hardware erratum. But the chroma plane
having half the height of the luma plane is just the way
NV12/NV21 is defined, so clarify this behaviour.

Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 9648dd5..77f18f6 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -533,7 +533,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
/* setting size of input image */
vp_reg_write(res, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
-   /* chroma height has to reduced by 2 to avoid chroma distorions */
+   /* the chroma plane for NV12/NV21 is half the height of the luma plane 
*/
vp_reg_write(res, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height / 2));
 
-- 
2.7.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/3] exynos: fix type-punned pointer build warning

[Tobias Jakobi]

Hello Seung-Woo,

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

With best wishes,
Tobias


Seung-Woo Kim wrote:
> As like the commit ecc2a097294d ("xf86drm: Fix type-punned pointer
> build warning"), this fixes following build warning.
> 
>exynos_drm.c: In function 'exynos_handle_event':
>exynos_drm.c:420:15: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules [-Wstrict-aliasing]
>   e = (struct drm_event *) [i];
>   ^
> 
> Signed-off-by: Seung-Woo Kim <sw0312@samsung.com>
> ---
>  exynos/exynos_drm.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
> index b961e52..f6204f1 100644
> --- a/exynos/exynos_drm.c
> +++ b/exynos/exynos_drm.c
> @@ -417,7 +417,7 @@ exynos_handle_event(struct exynos_device *dev, struct 
> exynos_event_context *ctx)
>  
>   i = 0;
>   while (i < len) {
> - e = (struct drm_event *) [i];
> + e = (struct drm_event *)(buffer + i);
>   switch (e->type) {
>   case DRM_EVENT_VBLANK:
>   if (evctx->version < 1 ||
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 2/3] exynos/fimg2d: remove unused-function build warning

[Tobias Jakobi]

Hello Seung-Woo,

looks good to me. Also, g2d_reset() never worked in the first place,
since the kernel driver rejects writes to SOFT_RESET_REG.

Reviewed-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>

With best wishes,
Tobias


Seung-Woo Kim wrote:
> The function g2d_reset() is not anymore used after the commit
> e3c97d1a2473 ("exynos/fimg2d: add g2d_validate_xyz() functions"),
> so it should be removed.
> 
> Signed-off-by: Seung-Woo Kim <sw0312@samsung.com>
> ---
>  exynos/exynos_fimg2d.c |   14 --
>  1 files changed, 0 insertions(+), 14 deletions(-)
> 
> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
> index 7f1d105..61340c3 100644
> --- a/exynos/exynos_fimg2d.c
> +++ b/exynos/exynos_fimg2d.c
> @@ -293,20 +293,6 @@ static void g2d_set_direction(struct g2d_context *ctx,
>  }
>  
>  /*
> - * g2d_reset - reset fimg2d hardware.
> - *
> - * @ctx: a pointer to g2d_context structure.
> - *
> - */
> -static void g2d_reset(struct g2d_context *ctx)
> -{
> - ctx->cmd_nr = 0;
> - ctx->cmd_buf_nr = 0;
> -
> - g2d_add_cmd(ctx, SOFT_RESET_REG, 0x01);
> -}
> -
> -/*
>   * g2d_flush - submit all commands and values in user side command buffer
>   *   to command queue aware of fimg2d dma.
>   *
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

[Tobias Jakobi]

Hello Daniel,

same question here. Patch doesn't introduce any functional changes (just
adds code documentation), so can you merge it through drm-misc?

With best wishes,
Tobias


Tobias Jakobi wrote:
> The output stage of the mixer uses YCbCr for the internal
> computations, which is the reason that some registers take
> YCbCr related data as input. In particular this applies
> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
> 
> Document the formatting of the data which we write to
> these registers.
> 
> While at it, unify wording of comments in the register header.
> 
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> ---
> Changes in v2:
> - use floating point values as input for the macros, as
>   suggested by Andrzej
> - the floating point values have been tuned to exactly match
>   the values that are currently used
> 
> Changes in v3:
> - use only three digit values (pointed out by Andrzej)
> 
>  drivers/gpu/drm/exynos/exynos_mixer.c | 33 +
>  drivers/gpu/drm/exynos/regs-mixer.h   |  7 +--
>  2 files changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 41d0c36..9648dd5 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -45,6 +45,22 @@
>  #define MIXER_WIN_NR 3
>  #define VP_DEFAULT_WIN   2
>  
> +/*
> + * Mixer color space conversion coefficient triplet.
> + * Used for CSC from RGB to YCbCr.
> + * Each coefficient is a 10-bit fixed point number with
> + * sign and no integer part, i.e.
> + * [0:8] = fractional part (representing a value y = x / 2^9)
> + * [9] = sign
> + * Negative values are encoded with two's complement.
> + */
> +#define MXR_CSC_C(x) ((int)((x) * 512.0) & 0x3ff)
> +#define MXR_CSC_CT(a0, a1, a2) \
> +  ((MXR_CSC_C(a0) << 20) | (MXR_CSC_C(a1) << 10) | (MXR_CSC_C(a2) << 0))
> +
> +/* YCbCr value, used for mixer background color configuration. */
> +#define MXR_YCBCR_VAL(y, cb, cr) (((y) << 16) | ((cb) << 8) | ((cr) << 0))
> +
>  /* The pixelformats that are natively supported by the mixer. */
>  #define MXR_FORMAT_RGB5654
>  #define MXR_FORMAT_ARGB1555  5
> @@ -391,13 +407,14 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
> *ctx, unsigned int height)
>   case 1080:
>   default:
>   val = MXR_CFG_RGB709_16_235;
> + /* Configure the BT.709 CSC matrix for full range RGB. */
>   mixer_reg_write(res, MXR_CM_COEFF_Y,
> - (1 << 30) | (94 << 20) | (314 << 10) |
> - (32 << 0));
> + MXR_CSC_CT( 0.184,  0.614,  0.063) |
> + MXR_CM_COEFF_RGB_FULL);
>   mixer_reg_write(res, MXR_CM_COEFF_CB,
> - (972 << 20) | (851 << 10) | (225 << 0));
> + MXR_CSC_CT(-0.102, -0.338,  0.440));
>   mixer_reg_write(res, MXR_CM_COEFF_CR,
> - (225 << 20) | (820 << 10) | (1004 << 0));
> + MXR_CSC_CT( 0.440, -0.399, -0.040));
>   break;
>   }
>  
> @@ -715,10 +732,10 @@ static void mixer_win_reset(struct mixer_context *ctx)
>   /* reset default layer priority */
>   mixer_reg_write(res, MXR_LAYER_CFG, 0);
>  
> - /* setting background color */
> - mixer_reg_write(res, MXR_BG_COLOR0, 0x008080);
> - mixer_reg_write(res, MXR_BG_COLOR1, 0x008080);
> - mixer_reg_write(res, MXR_BG_COLOR2, 0x008080);
> + /* set all background colors to RGB (0,0,0) */
> + mixer_reg_write(res, MXR_BG_COLOR0, MXR_YCBCR_VAL(0, 128, 128));
> + mixer_reg_write(res, MXR_BG_COLOR1, MXR_YCBCR_VAL(0, 128, 128));
> + mixer_reg_write(res, MXR_BG_COLOR2, MXR_YCBCR_VAL(0, 128, 128));
>  
>   if (test_bit(MXR_BIT_VP_ENABLED, >flags)) {
>   /* configuration of Video Processor Registers */
> diff --git a/drivers/gpu/drm/exynos/regs-mixer.h 
> b/drivers/gpu/drm/exynos/regs-mixer.h
> index 7f22df5..c311f57 100644
> --- a/drivers/gpu/drm/exynos/regs-mixer.h
> +++ b/drivers/gpu/drm/exynos/regs-mixer.h
> @@ -140,11 +140,11 @@
>  #define MXR_INT_EN_VSYNC (1 << 11)
>  #define MXR_INT_EN_ALL   (0x0f << 8)
>  
> -/* bit for MXR_INT_STATUS */
> +/* bits for MXR_INT_STATUS */
>  #define MXR_INT_CLEAR_VSYNC  (1 << 11)
>  #define MXR_INT_STATUS_VSYNC (1 << 0)
>  
> -/* bit 

Re: [PATCH v2 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()

[Tobias Jakobi]

Hello Daniel,

I'm not getting any response from the Exynos DRM maintainer concerning
this patch. Since this is just a simple cleanup, and Andrzej has already
review, could you perhaps merge it through drm-misc?

With best wishes,
Tobias



Tobias Jakobi wrote:
> Convert if-statements to switch statement. Removes
> duplicated code.
> 
> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>
> Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 30 --
>  1 file changed, 8 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 72143ac..41d0c36 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -382,29 +382,14 @@ static void mixer_cfg_rgb_fmt(struct mixer_context 
> *ctx, unsigned int height)
>   struct mixer_resources *res = >mixer_res;
>   u32 val;
>  
> - if (height == 480) {
> + switch (height) {
> + case 480:
> + case 576:
>   val = MXR_CFG_RGB601_0_255;
> - } else if (height == 576) {
> - val = MXR_CFG_RGB601_0_255;
> - } else if (height == 720) {
> - val = MXR_CFG_RGB709_16_235;
> - mixer_reg_write(res, MXR_CM_COEFF_Y,
> - (1 << 30) | (94 << 20) | (314 << 10) |
> - (32 << 0));
> - mixer_reg_write(res, MXR_CM_COEFF_CB,
> - (972 << 20) | (851 << 10) | (225 << 0));
> - mixer_reg_write(res, MXR_CM_COEFF_CR,
> - (225 << 20) | (820 << 10) | (1004 << 0));
> - } else if (height == 1080) {
> - val = MXR_CFG_RGB709_16_235;
> - mixer_reg_write(res, MXR_CM_COEFF_Y,
> - (1 << 30) | (94 << 20) | (314 << 10) |
> - (32 << 0));
> - mixer_reg_write(res, MXR_CM_COEFF_CB,
> - (972 << 20) | (851 << 10) | (225 << 0));
> - mixer_reg_write(res, MXR_CM_COEFF_CR,
> - (225 << 20) | (820 << 10) | (1004 << 0));
> - } else {
> + break;
> + case 720:
> + case 1080:
> + default:
>   val = MXR_CFG_RGB709_16_235;
>   mixer_reg_write(res, MXR_CM_COEFF_Y,
>   (1 << 30) | (94 << 20) | (314 << 10) |
> @@ -413,6 +398,7 @@ static void mixer_cfg_rgb_fmt(struct mixer_context *ctx, 
> unsigned int height)
>   (972 << 20) | (851 << 10) | (225 << 0));
>   mixer_reg_write(res, MXR_CM_COEFF_CR,
>   (225 << 20) | (820 << 10) | (1004 << 0));
> + break;
>   }
>  
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel