Re: [PATCHv5 00/34] Add AFBC support for Rockchip

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Dec 17, 2019 at 03:49:46PM +0100, Andrzej Pietrasiewicz wrote:
> This series adds AFBC support for Rockchip. It is inspired by:
> 
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> 
> This is the fifth iteration of the afbc series. Between v3 and v4 a lot of
> rework has been done, the main goal of which was to move all afbc-related
> checks to helpers, so that core does not deal with it.
> 
> A new struct drm_afbc_framebuffer is added, which stores afbc-related
> driver-specific data. Because of that, in drivers that wish to
> use this feature, the struct must be allocated directly in the driver
> code rather than inside helpers, so the first portion of the patchset
> does the necessary refactoring.
> 
> Then, there are 3 users of afbc: komeda, malidp and, finally, rockchip,
> the latter being the ultimate purpose of this work and the 3 subsequent
> portions of the patchset move komeda and malidp to generic helpers and add
> afbc support to rockchip.
> 
> The idea is to make all afbc users follow a similar pattern. In fb_create()
> they allocate struct drm_afbc_framebuffer, do their specific checks which
> can be done before object lookups, do object lookups and a special version
> of a size check, which understands struct drm_afbc_framebuffer, followed
> by any other driver-specific checks and initializing the gem object.
> The helpers for the common parts are factored out so that drivers
> can use them.
> 
> The komeda driver has been the farthest away from such a pattern, so it
> required most changes. However, due to the fact that I don't have any
> komeda hardware I did the changes to komeda in an incremental fashion with
> a series of (usually) very small, easy to understand steps. malidp was
> pretty straightforward, and rockchip's afbc checks follow the pattern.
> 
> I kindly ask for reviewing the series. I need to mention that my ultimate
> goal is merging afbc for rockchip and I don't have other hardware, so some
> help from malidp and komeda developers/maintainers would be appreciated.
> 
> @Liviu, @James, @Mihail, @Brian: a kind request to you to have a look and
> test the patchset, as I don't have appropriate hardware.
> 
> Rebased onto drm-misc-next.
> 
> v4..v5:
> - used proper way of subclassing drm_framebuffer (Daniel Vetter)
> - added documentation to exported functions (Liviu Dudau)
> - reordered new functions in drm_gem_framebuffer_helper.c to make a saner
> diff (Liviu Dudau)
> - used "2" suffix instead of "_special" for the special version of size
> checks (Liviu Dudau)
> - dropped unnecessarily added condition in drm_get_format_info() (Liviu
> Dudau)
> - dropped "block_size = 0;" trick in framebuffer_check() (Daniel Vetter)
> - relaxed sticking to 80 characters per line rule in some cases
> 
> v3..v4:
> 
> - addressed (some) comments from Daniel Stone, Ezequiel Garcia, Daniel
> Vetter and James Qian Wang - thank you for input
> - refactored helpers to ease accommodating drivers with afbc needs
> - moved afbc checks to helpers
> - converted komeda, malidp and (the newly added) rockchip to use the afbc
> helpers
> - eliminated a separate, dedicated source code file
> 
> v2..v3:
> 
> - addressed (some) comments from Daniel Stone, Liviu Dudau, Daniel Vetter
> and Brian Starkey - thank you all
> 
> In this iteration some rework has been done. The checking logic is now moved
> to framebuffer_check() so it is common to all drivers. But the common part
> is not good for komeda, so this series is not good for merging yet.
> I kindly ask for feedback whether the changes are in the right direction.
> I also kindly ask for input on how to accommodate komeda.
> 
> The CONFIG_DRM_AFBC option has been eliminated in favour of adding
> drm_afbc.c to drm_kms_helper.
> 
> v1..v2:
> 
> - addressed comments from Daniel Stone, Ayan Halder, Mihail Atanassov
> - coding style fixes** BLURB HERE ***
> 
> 
> Andrzej Pietrasiewicz (34):
>   drm/core: Add afbc helper functions
>   drm/gem-fb-helper: Allow drivers to allocate struct drm_framebuffer on
>     their own
>   drm/gem-fb-helper: Add special version of drm_gem_fb_size_check
>   drm/gem-fb-helper: Add generic afbc size checks
>   drm/komeda: Use afbc helper
>   drm/komeda: Move checking src coordinates to komeda_fb_create
>   drm/komeda: Use the already available local variable
>   drm/komeda: Retrieve drm_format_info once
>   drm/komeda: Explicitly require 1 plane for AFBC
>   drm/komeda: Move pitches comparison to komeda_fb_create
>   drm/komeda: Provide and use komeda_fb_get_pixel_addr variant not
>     requiring a fb
>   drm/komeda: Factor out object lookups for non-afbc case
>   drm/komeda: Make komeda_fb_none_size_check independent from
>     framebuffer
>   drm/komeda: Factor out object lookups for afbc case
>   drm/komeda: Free komeda_fb_afbc_size_check from framebuffer dependency
>   drm/komeda: Simplify error handling
>   drm/komeda: Move object lookup before size checks
>   drm/komeda: Move object assignments to framebuffer to after size
>     checks
>   drm/komeda: Make the size checks independent from framebuffer
>     structure
>   drm/komeda: Move helper invocation to after size checks
>   drm/komeda: Use helper for common tasks
>   drm/komeda: Use return value of drm_gem_fb_lookup
>   drm/komeda: Use special helper for non-afbc size checks
>   drm/komeda: Factor in the invocation of special helper
>   drm/komeda: Use special helper for afbc case size check
>   drm/komeda: Factor in the invocation of special helper, afbc case
>   drm/komeda: Move special helper invocation outside if-else
>   drm/komeda: Move to helper checking afbc buffer size
>   drm/arm/malidp: Make verify funcitons invocations independent
>   drm/arm/malidp: Integrate verify functions
>   drm/arm/malidp: Factor in afbc framebuffer verification
>   drm/arm/malidp: Use generic helpers for afbc checks
>   drm/rockchip: Use helper for common task
>   drm/rockchip: Add support for afbc
> 
>  .../arm/display/komeda/d71/d71_component.c    |   6 +-
>  .../arm/display/komeda/komeda_framebuffer.c   | 273 ++++++++---------
>  .../arm/display/komeda/komeda_framebuffer.h   |  21 +-
>  .../display/komeda/komeda_pipeline_state.c    |  14 +-
>  drivers/gpu/drm/arm/malidp_drv.c              | 155 ++++------
>  drivers/gpu/drm/drm_fourcc.c                  |  53 ++++
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c  | 287 ++++++++++++++----
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c    | 111 ++++++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 147 ++++++++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  12 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c   |  83 ++++-
>  include/drm/drm_fourcc.h                      |   4 +
>  include/drm/drm_framebuffer.h                 |  50 +++
>  include/drm/drm_gem_framebuffer_helper.h      |  34 +++
>  14 files changed, 907 insertions(+), 343 deletions(-)

I think this isn't achieving it's goal. Even if we take out the rockchip
enabling patch at the ent it's still like 200 lines more for something
that's supposed to unify and clean code up.

Plus it looks enormously complicated, something that I missed in my
previous quick glance. Hence proposal for all the things you're going to
add to drm core/helpers, and not a bit more :-)

int
drm_gem_fb_init_with_funcs(struct drm_framebuffer *fb,
			   struct drm_device *dev, struct drm_file *file,
			   const struct drm_mode_fb_cmd2 *mode_cmd,
			   const struct drm_framebuffer_funcs *funcs);

This is going to do _exactly_ what drm_gem_fb_create_with_funcs already
does, except it doesn't do the kzalloc (so that would need to be moved out
so we can share code). No other additional sub-parts exposed, I think
that's just not worth it in this case. So none of this size check stuff.

2nd piece, your drm_afbc_framebuffer as in patch 4, with the subclassing.

3rd piece, again in drm_gem_framebuffer_helper.c:

int drm_gem_afbc_init(struct drm_afbc_framebuffer *afbc_fb);

Drivers are supposed to call this after they've a) allocated their fb
structure, containing the drm_afbc_framebuffer somewhere and b) called
drm_gem_fb_init_with_funcs(). This function is going to fill out all the
additional fields, and this function is also going to do all the size
validation and everything else.

Nothing else, so no finer split up of helper check functions, or of afbc
computation functions, or of anything else. That mix of split-out stuff
and mix of computed values in drm_afbc_framebuffer but also functions that
compute afbc values from modifiers and fb sizes seems to just lead to a
huge confusion and not actually to a code reduction. So
- none of the functions exported in patch 1, just stuff them into
  drm_gem_framebuffer_helper.c.
- none of the helper subfunctions you export in patch 2, or adapt in patch
  3
- Also not this size check structure with the data pointer you add in
  patch 4.

The bikeshed I'm still seeing here is whether drm_afbc_framebuffer and the
drm_gem_afbc_init() function should be considered core stuff or not, I
guess you can make an argument for either.

This should also make conversion easier since as a first steps you'd do:

- Put the new drm_afbc_framebuffer in place and adjust all tha
  fb_to_komeda functions and upcasting (this should be mechanically)

- Add the call to drm_gem_afbc_init().

- Starting using the new values in drm_afbc_framebuffer and slowly delete
  code

- Optional, but would be nice to do: Convert driver over to
  drm_gem_fb_init_with_funcs().

Thoughts?

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