Message ID | 20181005092606.21100-1-alexandru-cosmin.gheorghe@arm.com (mailing list archive) |
---|---|
Headers | show |
Series | Add method to describe tile/bit_level_packed formats | expand |
On Fri, Oct 05, 2018 at 09:26:43AM +0000, Alexandru-Cosmin Gheorghe wrote: > There has been some discussion about extending drm core to handle > linear tile formats, in the series sent by me here [1] and how to > handle formats that are intended to be used just with > modifiers(particularly AFBC modifiers) on Brian series [2] and on IRC > here [3] and [4]. > > Hence, this big-merged series: > > Patches 1-3: handle tiled formats both in core and in malidp driver, > this is done by extending drm_format_info with three new fields > char_per_block, block_w, block_h and consistently handle in the generic > code paths, both linear tiled formats and normal formats. > What's different from [1] is the interpretation of pitch for tile > formats which has been kept to be the same as for the other formats: > pitch = average_chars_per_pixel * width. > > Patches 4-6: Introduce the YUV AFBC formats, the only thing noteworthy > here is that cpp/char_per_block are set to 0 for formats where it's > mandatory to be used together with a non-linear modifier and then that > is used to bypass pitch check in framebuffer_check for formats that > have cpp/char_per_block set to 0. > > [1] https://lists.freedesktop.org/archives/dri-devel/2018-September/188245.html > [2] https://lists.freedesktop.org/archives/dri-devel/2018-September/189620.html > [3] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true > [4] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-14&show_html=true > > Alexandru Gheorghe (4): > drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info > drm/fourcc: Add fourcc for Mali linear tiled formats > drm: mali-dp: Enable Mali-DP tiled buffer formats > drm: Extend framebuffer_check to handle formats with > cpp/char_per_block 0 > > Brian Starkey (2): > drm/fourcc: Add AFBC yuv fourccs for Mali > drm/afbc: Add AFBC modifier usage documentation I think at the design level we're getting there, yay! Bunch of comments/suggestions/ideas on patch one. It looks like the patch 7 is missing though, since the fancy formats where you have no linear layout isn't enabled in mali-dp (afaics at least). Depending what those look like, my suggestion to require drivers to use ->get_format_info instead might or might not work. Cheers, Daniel > > Documentation/gpu/afbc.rst | 233 +++++++++++++++++++ > Documentation/gpu/drivers.rst | 1 + > MAINTAINERS | 1 + > drivers/gpu/drm/arm/malidp_hw.c | 14 +- > drivers/gpu/drm/arm/malidp_planes.c | 23 +- > drivers/gpu/drm/drm_fb_cma_helper.c | 21 +- > drivers/gpu/drm/drm_fb_helper.c | 6 + > drivers/gpu/drm/drm_fourcc.c | 65 ++++++ > drivers/gpu/drm/drm_framebuffer.c | 13 +- > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +- > include/drm/drm_fourcc.h | 29 ++- > include/uapi/drm/drm_fourcc.h | 31 +++ > 12 files changed, 428 insertions(+), 13 deletions(-) > create mode 100644 Documentation/gpu/afbc.rst > > -- > 2.18.0 >
On Fri, Oct 05, 2018 at 04:58:38PM +0200, Daniel Vetter wrote: > On Fri, Oct 05, 2018 at 09:26:43AM +0000, Alexandru-Cosmin Gheorghe wrote: > > There has been some discussion about extending drm core to handle > > linear tile formats, in the series sent by me here [1] and how to > > handle formats that are intended to be used just with > > modifiers(particularly AFBC modifiers) on Brian series [2] and on IRC > > here [3] and [4]. > > > > Hence, this big-merged series: > > > > Patches 1-3: handle tiled formats both in core and in malidp driver, > > this is done by extending drm_format_info with three new fields > > char_per_block, block_w, block_h and consistently handle in the generic > > code paths, both linear tiled formats and normal formats. > > What's different from [1] is the interpretation of pitch for tile > > formats which has been kept to be the same as for the other formats: > > pitch = average_chars_per_pixel * width. > > > > Patches 4-6: Introduce the YUV AFBC formats, the only thing noteworthy > > here is that cpp/char_per_block are set to 0 for formats where it's > > mandatory to be used together with a non-linear modifier and then that > > is used to bypass pitch check in framebuffer_check for formats that > > have cpp/char_per_block set to 0. > > > > [1] https://lists.freedesktop.org/archives/dri-devel/2018-September/188245.html > > [2] https://lists.freedesktop.org/archives/dri-devel/2018-September/189620.html > > [3] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-13&show_html=true > > [4] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2018-09-14&show_html=true > > > > Alexandru Gheorghe (4): > > drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info > > drm/fourcc: Add fourcc for Mali linear tiled formats > > drm: mali-dp: Enable Mali-DP tiled buffer formats > > drm: Extend framebuffer_check to handle formats with > > cpp/char_per_block 0 > > > > Brian Starkey (2): > > drm/fourcc: Add AFBC yuv fourccs for Mali > > drm/afbc: Add AFBC modifier usage documentation > > I think at the design level we're getting there, yay! Bunch of > comments/suggestions/ideas on patch one. > > It looks like the patch 7 is missing though, since the fancy formats where > you have no linear layout isn't enabled in mali-dp (afaics at least). > Depending what those look like, my suggestion to require drivers to use > ->get_format_info instead might or might not work. Yes, patch 7 is missing, Ayan is working on that, I'm not sure if on next version we should send one big series, with that as well, or split it in two, by keeping the first three patches in a separate series, any preferences ? Anyway, regarding using get_format_info to trick check_framebuffer to validate the pitch, the driver could invent some numbers to populate a drm_format_info, but it doesn't make too much sense because we are more restrictive than that so the driver will need to do some sort of validation anyway. > > Cheers, Daniel > > > > > Documentation/gpu/afbc.rst | 233 +++++++++++++++++++ > > Documentation/gpu/drivers.rst | 1 + > > MAINTAINERS | 1 + > > drivers/gpu/drm/arm/malidp_hw.c | 14 +- > > drivers/gpu/drm/arm/malidp_planes.c | 23 +- > > drivers/gpu/drm/drm_fb_cma_helper.c | 21 +- > > drivers/gpu/drm/drm_fb_helper.c | 6 + > > drivers/gpu/drm/drm_fourcc.c | 65 ++++++ > > drivers/gpu/drm/drm_framebuffer.c | 13 +- > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 +- > > include/drm/drm_fourcc.h | 29 ++- > > include/uapi/drm/drm_fourcc.h | 31 +++ > > 12 files changed, 428 insertions(+), 13 deletions(-) > > create mode 100644 Documentation/gpu/afbc.rst > > > > -- > > 2.18.0 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch