Hello, On 2015ë 03ì 25ì¼ 03:32, Rob Clark wrote: > On Mon, Mar 16, 2015 at 4:05 AM, Daniel Vetter <daniel at ffwll.ch> wrote: >> On Fri, Mar 13, 2015 at 03:12:10PM -0400, Stephane Viau wrote: >>> From: Beeresh Gopal <gbeeresh at codeaurora.org> >>> >>> Using fb modifier flag, support NV12MT format in MDP4. >>> >>> v2: >>> - rework the modifier's description [Daniel Vetter's comment] >>> - drop .set_mode_config() callback [Rob Clark's comment] >>> >>> Signed-off-by: Beeresh Gopal <gbeeresh at codeaurora.org> >>> Signed-off-by: Stephane Viau <sviau at codeaurora.org> >>> --- >>> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 ++ >>> drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++++++++++++++++++++++ >>> include/uapi/drm/drm_fourcc.h | 5 +++++ >>> 3 files changed, 29 insertions(+) >>>
<snip.> >>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h >>> index 188e61f..2ff79cb 100644 >>> --- a/include/uapi/drm/drm_fourcc.h >>> +++ b/include/uapi/drm/drm_fourcc.h >>> @@ -161,4 +161,9 @@ >>> * authoritative source for all of these. >>> */ >>> >>> +/* Samsung framebuffer modifiers */ >>> + >>> +/* Tiled: 64x32 pixel macroblocks */ >> >> Since this seems shared by a lot of vendors (I still don't believe Samsung >> invented this really ...) can you please describe this thing a bit in more >> detail? Somewhat important how macroblocks are laid out and pixels within. >> Also with a planar format like NV12 "pixel" is a bit unclear, e.g. what >> happens if you throw 10bit plane formats at this? So maybe also add a note >> that for now this is only used together with NV12T. > > + a couple folks from Samsung, since I expect they want this for > exynos as well (and might be able to help with the description) Yes, I have a plan to apply fb_modifier for exynos with kms interface of hdmi. > > vl4 also has this format, but last I looked was rather light on the details. I am not sure msm mdp uses exactly same format with exynos, but anyway v4l2 NV12MT format was introduced for exynos hw video codec. macro blocks for the format is laid z-order and each pixel data in each macro block is just normal NV12 style. I think Marek and Sylwester can help understanding the format. > > http://linuxtv.org/downloads/v4l-dvb-apis/re31.html > > I know up in userspace, GStreamer seems to have some support for this format: > > http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=f8d3b9b4fcc5e08b771314fa95e9ed8f750b54e6 > >> Then there's the question of validating the input - stride should probably >> be a full multiple of the macroblock size. Since this is a shared format >> imo this kind of checking should be done in drm core. > > afaiu, stride (and maybe even width?) should be a multiple of the > block size (but height does not) > > BR, > -R > > >> -Daniel >> >> >>> +#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1) >>> + >>> #endif /* DRM_FOURCC_H */ >>> -- >>> Qualcomm Innovation Center, Inc. >>> >>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >>> a Linux Foundation Collaborative Project >>> >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- Seung-Woo Kim Samsung Software R&D Center --
