linux.git/drivers/gpu/drm/arm, branch v5.3-rc2

drm/komeda: Computing image enhancer internally

2019-07-08T14:05:34+00:00

Enable image enhancer when the input data flow is 2x+ upscaling.

Signed-off-by: james qian wang (Arm Technology China) 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20190708070000.4945-1-james.qian.wang@arm.com

drm/komeda: Computing layer_split internally

2019-07-08T14:05:21+00:00

For layer_split no need user to enable/disable it, but compute it in
komeda internally, komeda will enable it if the scaling exceed the
acceptable range of scaler.

Signed-off-by: james qian wang (Arm Technology China) 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20190708065923.4887-1-james.qian.wang@arm.com

drm/komeda: Remove layer_split property

2019-07-08T13:44:42+00:00

Properties are uapi like anything else, with all the usual rules
regarding review, testcases, open source userspace ... Furthermore
driver-private kms properties are highly discouraged, over the past
few years we've realized we need to make a serious effort at better
standardizing this stuff.

Again this probably needs multiple pieces to solve this properly:

- Instead of expecting userspace to compute this (and duplicating
  modeset code), the kernel driver should compute when it's necessary
  to enable layer_split mode to make a configuration possible. I.e. in
  komeda_plane_atomic_check() first try komeda_build_layer_data_flow()
  and if that fails, try komeda_build_layer_split_data_flow(), and set
  dflow.en_split accordingly. Assuming I understand somewhat correctly
  what this does.

- If this is needed for validation then you want a debugfs file to
  force this one way or the other, or alternatively  use
  ->atomic_print_state to dump such hidden driver-private state.
  Depends upon how you do your validation ofc.

Fixes: a407a6509393 ("drm/komeda: Add layer split support")
Cc: Lowry Li (Arm Technology China) 
Cc: James Qian Wang (Arm Technology China) 
Cc: Liviu Dudau 
Cc: Mali DP Maintainers 
Cc: Brian Starkey 
Signed-off-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20190705121006.26085-4-daniel.vetter@ffwll.ch

drm/komeda: remove img_enhancement property

2019-07-08T13:44:35+00:00

Properties are uapi like anything else, with all the usual rules
regarding review, testcases, open source userspace ... Furthermore
driver-private kms properties are highly discouraged, over the past
few years we've realized we need to make a serious effort at better
standardizing this stuff.

Again this probably needs multiple pieces to solve this properly:

- Instead of expecting userspace to compute this (and duplicating
  modeset code), the kernel driver should compute when it's possible
  to enable this better up/downscale mode (assuming I understood
  Liviu correctly on what this does) automatically.

- If this is needed for validation then you want a debugfs file to
  force this one way or the other, or alternatively  use
  ->atomic_print_state to dump such hidden driver-private state.
  Depends upon how you do your validation ofc.

Fixes: 42b6f118f6d1 ("drm/komeda: Add image enhancement support")
Cc: Lowry Li (Arm Technology China) 
Cc: James Qian Wang (Arm Technology China) 
Cc: Liviu Dudau 
Cc: Mali DP Maintainers 
Cc: Brian Starkey 
Signed-off-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20190705121006.26085-3-daniel.vetter@ffwll.ch

drm/komeda: remove slave_planes property

2019-07-08T13:44:28+00:00

Properties are uapi like anything else, with all the usual rules
regarding review, testcases, open source userspace ... Furthermore
driver-private kms properties are highly discouraged, over the past
few years we've realized we need to make a serious effort at better
standardizing this stuff.

Again this probably needs multiple pieces to solve this properly:

- To make plane configuration less surprising to userspace you
  propably need to virtualize planes, and reorder which logical plane
  you map to which physical one dynamically. Instead of exposing a
  komeda-specific limitation to userspace and expecting them to dtrt.
  I think msm and rcar-du do that already (and others), if you need
  people to chat with or example code.

- If this is needed for validation, again ->atomic_print_state and the
  infrastructure around that is your friend.

Fixes: 3b9dfa4ef28c ("drm/komeda: Add slave pipeline support")
Cc: Lowry Li (Arm Technology China) 
Cc: James Qian Wang (Arm Technology China) 
Cc: Liviu Dudau 
Cc: Mali DP Maintainers 
Cc: Brian Starkey 
Signed-off-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20190705121006.26085-2-daniel.vetter@ffwll.ch

drm/komeda: Remove clock ratio property

2019-07-08T13:44:10+00:00

Properties are uapi like anything else, with all the usual rules
regarding review, testcases, open source userspace ... Furthermore
driver-private kms properties are highly discouraged, over the past
few years we've realized we need to make a serious effort at better
standardizing this stuff.

From the discussion with Liviu the solution for these here needs
multiple pieces:

- For being able to reliably read the memory clock we need a DT
  property, plus maybe DT override snippets to fix it if it's wrong.

- For exposing plane limitations to userspace there's TEST_ONLY. There
  is a bit a gap in telling userspace better that scaling doesn't work
  due to limits (atm a good strategy is to retry again without scaling
  when adding a plane didn't work the first time around). But that
  needs a more generic solution, not exposing something extremely
  komeda specific.

- If this is needed by validation tools, you can still expose it in
  debugfs. We have an entire nice infrastructure for debug printing of
  kms objects already, see the various atomic_print_state callbacks
  and infrastructure around them.

Fixes: 1f7f9ab7900e ("drm/komeda: Add engine clock requirement check for the downscaling")
Cc: Lowry Li (Arm Technology China) 
Cc: James Qian Wang (Arm Technology China) 
Cc: Liviu Dudau 
Cc: Mali DP Maintainers 
Cc: Brian Starkey 
Signed-off-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Liviu Dudau 
Link: https://patchwork.freedesktop.org/patch/msgid/20190705121006.26085-1-daniel.vetter@ffwll.ch

drm/komeda: Make Komeda interrupts shareable

2019-06-21T09:47:15+00:00

Komeda interrupts may be shared with other hardware blocks.
One needs to use devm_request_irq() with IRQF_SHARED to create a shared
 interrupt handler.
As a result of not using drm_irq_install() api, one needs to set
"(struct drm_device *)->irq_enabled = true/false" to enable/disable
vblank interrupts.

Changes from v1:-
1. Squashed the following two patches into one (as the second patch is a
consequence of the first one):-
   drm/komeda: Avoid using DRIVER_IRQ_SHARED
   drm/komeda: Enable/Disable vblank interrupts
2. Fixed the commit message (as pointed by Daniel Vetter)
3. Removed calls to 'drm_irq_uninstall()' as we are no longer using
drm_irq_install()
4. Removed the struct member 'komeda_kms_driver.irq_handler' as it is not
used anywhere.

Signed-off-by: Ayan Halder 
Signed-off-by: Liviu Dudau

drm/komeda: fix 32-bit komeda_crtc_update_clock_ratio

2019-06-21T09:46:40+00:00

clang points out a bug in the clock calculation on 32-bit, that leads
to the clock_ratio always being zero:

drivers/gpu/drm/arm/display/komeda/komeda_crtc.c:31:36: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
        aclk = komeda_calc_aclk(kcrtc_st) << 32;

Move the shift into the division to make it apply on a 64-bit
variable. Also use the more expensive div64_u64() instead of div_u64()
to account for pxlclk being a 64-bit integer.

Fixes: 1f7f9ab7900e ("drm/komeda: Add engine clock requirement check for the downscaling")
Signed-off-by: Arnd Bergmann 
Reviewed-by: James Qian Wang (Arm Technology China) 
Signed-off-by: Liviu Dudau

drm/komeda: Correct printk format specifier for "size_t"

2019-06-19T16:03:38+00:00

Warnings popup when "make ARCH=i386"

In file included from include/drm/drm_mm.h:49,
                 from include/drm/drm_vma_manager.h:26,
                 from include/drm/drm_gem.h:40,
                 from drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c:9:
drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c: In function 'komeda_fb_afbc_size_check':
drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c:96:17: error: format '%lx' expects argument of type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
   DRM_DEBUG_KMS("afbc size check failed, obj_size: 0x%lx. min_size 0x%x.\n",

That leads by misuse "%lx" as format speicifier for size_t, correct it
to "%zx"

Reported-by: kbuild test robot 
Signed-off-by: james qian wang (Arm Technology China) 
Signed-off-by: Liviu Dudau

malidp: no need to check return value of debugfs_create functions

2019-06-19T16:03:23+00:00

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Liviu Dudau