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

[Inki Dae]

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.

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