Re: [PATCH v3 1/4] drm/qxl: use drmm_mode_config_init

[Thomas Zimmermann]

Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Daniel Vetter 


Acked-by: Thomas Zimmermann 


---
  drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 012bce0cdb65..38d6b596094d 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1195,7 +1195,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
int i;
int ret;
  
-	drm_mode_config_init(&qdev->ddev);

+   ret = drmm_mode_config_init(&qdev->ddev);
+   if (ret)
+   return ret;
  
  	ret = qxl_create_monitors_object(qdev);

if (ret)
@@ -1228,5 +1230,4 @@ int qxl_modeset_init(struct qxl_device *qdev)
  void qxl_modeset_fini(struct qxl_device *qdev)
  {
qxl_destroy_monitors_object(qdev);
-   drm_mode_config_cleanup(&qdev->ddev);
  }



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] drm/qxl: unpin release objects

[Thomas Zimmermann]

Hi

Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:

Balances the qxl_create_bo(..., pinned=true, ...);
call in qxl_release_bo_alloc().

Signed-off-by: Gerd Hoffmann 
---
  drivers/gpu/drm/qxl/qxl_release.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 0fcfc952d5e9..add979cba11b 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release)
entry = container_of(release->bos.next,
 struct qxl_bo_list, tv.head);
bo = to_qxl_bo(entry->tv.bo);
+   bo->tbo.pin_count = 0; /* ttm_bo_unpin(&bo->tbo); */


This code looks like a workaround or a bug.

AFAICT the only place with pre-pinned BO is qdev->dumb_shadow_bo. Can 
you remove the pinned flag entirely and handle pinning as part of 
dumb_shadow_bo's code.


Otherwise maybe use

if (pin_count)
ttm_bo_unpin();
WARN_ON(pin_count); /* should always be 0 now */

with a comment similar to the commit's description.

Best regards
Thomas


qxl_bo_unref(&bo);
list_del(&entry->tv.head);
kfree(entry);



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/4] drm/qxl: release shadow on shutdown

[Thomas Zimmermann]

Hi

Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:

In case we have a shadow surface on shutdown release
it so it doesn't leak.

Signed-off-by: Gerd Hoffmann 
---
  drivers/gpu/drm/qxl/qxl_display.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 38d6b596094d..60331e31861a 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1229,5 +1229,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
  
  void qxl_modeset_fini(struct qxl_device *qdev)

  {
+   if (qdev->dumb_shadow_bo) {


Wrt to my comment on patch 2, this might be the place to unpin the BO.


+   drm_gem_object_put(&qdev->dumb_shadow_bo->tbo.base);
+   qdev->dumb_shadow_bo = NULL;
+   }
qxl_destroy_monitors_object(qdev);
  }



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds

[Steven Price]

On 21/01/2021 17:04, Lukasz Luba wrote:

The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in different
workloads.

Signed-off-by: Lukasz Luba 
---
Hi all,

This patch aims to improve the panfrost performance in various workloads,
(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with panfrost.
These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.

Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114


It would be good to state which platform this is on as this obviously 
can vary depending on the OPPs available.


Of course the real fix here would be to improve the utilisation of the 
GPU[1] so we actually hit the 90% threshold more easily (AFAICT kbase 
uses the default 90/5 thresholds), but this seems like a reasonable 
change for now.


Reviewed-by: Steven Price 

Thanks,

Steve

[1] When I get some time I need to rework the "queue jobs on the 
hardware"[2] patch I posted ages ago. Last time it actually caused a 
performance regression though...


[2] https://lore.kernel.org/r/20190816093107.30518-2-steven.price%40arm.com


In future the devfreq framework would expose via sysfs these two
tunables, so they can be adjusted by the middleware based on currently
running workload (game, desktop, web browser, etc). These new values
should be good enough, though.

Regards,
Lukasz Luba

  drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 +-
  drivers/gpu/drm/panfrost/panfrost_devfreq.h |  2 ++
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..7c5ffc81dce1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -130,8 +130,16 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
  
+	/*

+* Setup default thresholds for the simple_ondemand governor.
+* The values are chosen based on experiments.
+*/
+   pfdevfreq->gov_data.upthreshold = 45;
+   pfdevfreq->gov_data.downdifferential = 5;
+
devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
- DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ &pfdevfreq->gov_data);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
ret = PTR_ERR(devfreq);
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..1e2a4de941aa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -4,6 +4,7 @@
  #ifndef __PANFROST_DEVFREQ_H__
  #define __PANFROST_DEVFREQ_H__
  
+#include 

  #include 
  #include 
  
@@ -17,6 +18,7 @@ struct panfrost_devfreq {

struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
+   struct devfreq_simple_ondemand_data gov_data;
bool opp_of_table_added;
  
  	ktime_t busy_time;




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: device naming cleanup

[Huang Rui]

On Thu, Jan 21, 2021 at 07:58:18PM +0800, Christian König wrote:
> Rename ttm_bo_device to ttm_device.
> Rename ttm_bo_driver to ttm_device_funcs.
> Rename ttm_bo_global to ttm_global.
> 
> Move global and device related functions to ttm_device.[ch].
> 
> No functional change.
> 
> Signed-off-by: Christian König 

Acked-by: Huang Rui 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   2 +-
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c  |   6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c  |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  26 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |   2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|   8 +-
>  drivers/gpu/drm/drm_gem_vram_helper.c |  14 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.c  |  20 +-
>  drivers/gpu/drm/nouveau/nouveau_bo.h  |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_drv.h |   2 +-
>  drivers/gpu/drm/nouveau/nouveau_sgdma.c   |   6 +-
>  drivers/gpu/drm/nouveau/nouveau_ttm.c |  10 +-
>  drivers/gpu/drm/nouveau/nouveau_ttm.h |   8 +-
>  drivers/gpu/drm/qxl/qxl_drv.h |   4 +-
>  drivers/gpu/drm/qxl/qxl_release.c |   6 +-
>  drivers/gpu/drm/qxl/qxl_ttm.c |  19 +-
>  drivers/gpu/drm/radeon/radeon.h   |   6 +-
>  drivers/gpu/drm/radeon/radeon_object.c|   2 +-
>  drivers/gpu/drm/radeon/radeon_ttm.c   |  38 +-
>  drivers/gpu/drm/ttm/Makefile  |   2 +-
>  drivers/gpu/drm/ttm/ttm_agp_backend.c |   2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c  | 256 +++---
>  drivers/gpu/drm/ttm/ttm_bo_util.c |  24 +-
>  drivers/gpu/drm/ttm/ttm_bo_vm.c   |  24 +-
>  drivers/gpu/drm/ttm/ttm_device.c  | 195 +++
>  drivers/gpu/drm/ttm/ttm_execbuf_util.c|   8 +-
>  drivers/gpu/drm/ttm/ttm_range_manager.c   |   4 +-
>  drivers/gpu/drm/ttm/ttm_resource.c|   4 +-
>  drivers/gpu/drm/ttm/ttm_tt.c  |  26 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_blit.c  |   4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c|   4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |  16 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   |   4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |   2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c|  14 +-
>  include/drm/drm_gem_vram_helper.h |   6 +-
>  include/drm/ttm/ttm_bo_api.h  |  35 +-
>  include/drm/ttm/ttm_bo_driver.h   | 328 +-
>  include/drm/ttm/ttm_device.h  | 319 +
>  include/drm/ttm/ttm_resource.h|   4 +-
>  include/drm/ttm/ttm_tt.h  |  10 +-
>  41 files changed, 759 insertions(+), 715 deletions(-)
>  create mode 100644 drivers/gpu/drm/ttm/ttm_device.c
>  create mode 100644 include/drm/ttm/ttm_device.h
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index f77443cd9c17..ab4ac3b2651e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1053,7 +1053,7 @@ static inline struct drm_device *adev_to_drm(struct 
> amdgpu_device *adev)
>   return &adev->ddev;
>  }
>  
> -static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device 
> *bdev)
> +static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_device *bdev)
>  {
>   return container_of(bdev, struct amdgpu_device, mman.bdev);
>  }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
> index 3107b9575929..5af464933976 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
> @@ -40,13 +40,13 @@ static atomic_t fence_seq = ATOMIC_INIT(0);
>   * All the BOs in a process share an eviction fence. When process X wants
>   * to map VRAM memory but TTM can't find enough space, TTM will attempt to
>   * evict BOs from its LRU list. TTM checks if the BO is valuable to evict
> - * by calling ttm_bo_driver->eviction_valuable().
> + * by calling ttm_device_funcs->eviction_valuable().
>   *
> - * ttm_bo_driver->eviction_valuable() - will return false if the BO belongs
> + * ttm_device_funcs->eviction_valuable() - will return false if the BO 
> belongs
>   *  to process X. Otherwise, it will return true to indicate BO can be
>   *  evicted by TTM.
>   *
> - * If ttm_bo_driver->eviction_valuable returns true, then TTM will continue
> + * If ttm_device_funcs->eviction_valuable returns true, then TTM will 
> continue
>   * the evcition process for that BO by calling ttm_bo_evict --> 
> amdgpu_bo_move
>   * --> amdgpu_copy_buffer(). This sets up job in GPU scheduler.
>   *
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c
> index 0db933026722..fde2d899b2c4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/a

Re: [PATCH 0/3] Experimental freesync video mode optimization

[Pekka Paalanen]

On Tue, 19 Jan 2021 10:50:26 -0500
Aurabindo Pillai  wrote:

> Changes in V5
> =
> 
> * More info in commit messages on the rationale of changes being added
> to the kernel.
> * Minor fixes

Hi,

thank you for adding the explanations in the commit messages I asked
for. It is now up to DRM maintainers to determine if this is
conceptually fine.

I do see that apparently setting the opt-in option does not yet taint
the kernel although Daniel Vetter suggested it might be a good idea. I
guess tainting the kernel would make it easier to remove this feature
in the future because it would be easier to dismiss people that claim a
kernel regression due to the removal.


Thanks,
pq


> --
> 
> This patchset enables freesync video mode usecase where the userspace
> can request a freesync compatible video mode such that switching to this
> mode does not trigger blanking.
> 
> This feature is guarded by a module parameter which is disabled by
> default. Enabling this paramters adds additional modes to the driver
> modelist, and also enables the optimization to skip modeset when using
> one of these modes.
> 
> --
> 
> Aurabindo Pillai (3):
>   drm/amd/display: Add module parameter for freesync video mode
>   drm/amd/display: Add freesync video modes based on preferred modes
>   drm/amd/display: Skip modeset for front porch change
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  12 +
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 401 --
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   3 +
>  4 files changed, 382 insertions(+), 35 deletions(-)
> 



pgpbRh70mlxVs.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: build warning after merge of the drm tree

[Daniel Vetter]

On Fri, Jan 22, 2021 at 8:29 AM Stephen Rothwell  wrote:
>
> Hi Daniel,
>
> On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter  wrote:
> >
> > Hm that has been in drm-intel-gt-next for a few days, is that tree not
> > in linux-next?
>
> It is not.

Adding -intel maintainers to get that sorted.
-Daniel

> These are the drm branches currently in linux-next:

Oh for ordering maybe put drm-misc ahead of the other subtrees, -misc
is where nowadays a lot of refactorings and core changes land.
Probably doesn't matter in practice.
-Daniel

> drm-fixes   git://git.freedesktop.org/git/drm/drm.git   drm-fixes
> amdgpu-fixesgit://people.freedesktop.org/~agd5f/linux   drm-fixes
> drm-intel-fixes git://anongit.freedesktop.org/drm-intel 
> for-linux-next-fixes
> drm-misc-fixes  git://anongit.freedesktop.org/drm/drm-misc  
> for-linux-next-fixes
> drm git://git.freedesktop.org/git/drm/drm.git   drm-next
> amdgpu  https://gitlab.freedesktop.org/agd5f/linux  drm-next
> drm-intel   git://anongit.freedesktop.org/drm-intel for-linux-next
> drm-tegra   git://anongit.freedesktop.org/tegra/linux.git   
> drm/tegra/for-next
> drm-miscgit://anongit.freedesktop.org/drm/drm-misc  for-linux-next
> drm-msm https://gitlab.freedesktop.org/drm/msm.git  msm-next
> imx-drm https://git.pengutronix.de/git/pza/linuximx-drm/next
> etnaviv https://git.pengutronix.de/git/lst/linuxetnaviv/next
>
> --
> Cheers,
> Stephen Rothwell



-- 
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

Re: [PATCH v2] drm: Introduce a drm_crtc_commit_wait helper

[Maxime Ripard]

On Mon, Jan 11, 2021 at 09:44:01AM +0100, Maxime Ripard wrote:
> There's currently four users of the same logic to wait for a commit to
> be flipped: three for the CRTCs, connectors and planes in
> drm_atomic_helper_wait_for_dependencies, and one in vc4.
> 
> Let's consolidate this a bit to avoid any code duplication.
> 
> Suggested-by: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Maxime Ripard 

Applied,

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler

[Dmitry Baryshkov]

Hello,

On Thu, 21 Jan 2021 at 14:45, Andrzej Hajda  wrote:
> W dniu 17.01.2021 o 01:23, Dmitry Baryshkov pisze:
> > drm hotplug handling code (drm_client_dev_hotplug()) can wait on mutex,
> > thus delaying further lt9611uxc IRQ events processing.  It was observed
> > occasionally during bootups, when drm_client_modeset_probe() was waiting
> > for EDID ready event, which was delayed because IRQ handler was stuck
> > trying to deliver hotplug event.
> > Move hotplug notifications from IRQ handler to separate work to be able
> > to process IRQ events without delays.
> >
> > Signed-off-by: Dmitry Baryshkov 
> > Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC 
> > bridge")
> > Reviewed-by: Bjorn Andersson 
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >   drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 30 +-
> >   1 file changed, 24 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c 
> > b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > index b708700e182d..209e39923914 100644
> > --- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> > @@ -14,6 +14,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   #include 
> >
> > @@ -36,6 +37,7 @@ struct lt9611uxc {
> >   struct mutex ocm_lock;
> >
> >   struct wait_queue_head wq;
> > + struct work_struct work;
> >
> >   struct device_node *dsi0_node;
> >   struct device_node *dsi1_node;
> > @@ -52,6 +54,7 @@ struct lt9611uxc {
> >
> >   bool hpd_supported;
> >   bool edid_read;
> > + bool hdmi_connected;
> >   uint8_t fw_version;
> >   };
> >
> > @@ -151,15 +154,26 @@ static irqreturn_t lt9611uxc_irq_thread_handler(int 
> > irq, void *dev_id)
> >   }
> >
> >   if (irq_status & BIT(1)) {
> > - if (lt9611uxc->connector.dev)
> > - 
> > drm_kms_helper_hotplug_event(lt9611uxc->connector.dev);
> > - else
> > - drm_bridge_hpd_notify(<9611uxc->bridge, 
> > !!(hpd_status & BIT(1)));
> > + lt9611uxc->hdmi_connected = !!(hpd_status & BIT(1));
>
> No need for !!, int->bool implicit conversion will do the thing.

Ack.

>
> > + schedule_work(<9611uxc->work);
> >   }
> >
> >   return IRQ_HANDLED;
> >   }
> >
> > +static void lt9611uxc_hpd_work(struct work_struct *work)
> > +{
> > + struct lt9611uxc *lt9611uxc = container_of(work, struct lt9611uxc, 
> > work);
> > +
> > + if (lt9611uxc->connector.dev)
> > + drm_kms_helper_hotplug_event(lt9611uxc->connector.dev);
> > + else
> > + drm_bridge_hpd_notify(<9611uxc->bridge,
> > +   lt9611uxc->hdmi_connected ?
> > +   connector_status_connected :
> > +   connector_status_disconnected);
>
>
> I am little bit worried about accessing lt9611uxc->hdmi_connected - it
> is set in different thread, and there is no explicit sync code between
> them. I guess it is possible to loss proper HPD signal, especially if
> the HPD line is unstable (is there signal debouncing?).

I'll protect access to the hdmi_connected by the lt9611uxc_lock/ocm_mutex,

> > +}
> > +
> >   static void lt9611uxc_reset(struct lt9611uxc *lt9611uxc)
> >   {
> >   gpiod_set_value_cansleep(lt9611uxc->reset_gpio, 1);
> > @@ -447,7 +461,7 @@ static enum drm_connector_status 
> > lt9611uxc_bridge_detect(struct drm_bridge *brid
> >   struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
> >   unsigned int reg_val = 0;
> >   int ret;
> > - int connected = 1;
> > + bool connected = true;
> >
> >   if (lt9611uxc->hpd_supported) {
> >   lt9611uxc_lock(lt9611uxc);
> > @@ -457,8 +471,9 @@ static enum drm_connector_status 
> > lt9611uxc_bridge_detect(struct drm_bridge *brid
> >   if (ret)
> >   dev_err(lt9611uxc->dev, "failed to read hpd status: 
> > %d\n", ret);
> >   else
> > - connected  = reg_val & BIT(1);
> > + connected  = !!(reg_val & BIT(1));
>
>
> Again no no need for !!.

Ack

>
> I saw in v2 there was R-B tags added by Bjorn to other two patches,
> please do not forgot them next time.

Ack

> Andrzej
>
>
> >   }
> > + lt9611uxc->hdmi_connected = connected;
> >
> >   return connected ?  connector_status_connected :
> >   connector_status_disconnected;
> > @@ -931,6 +946,8 @@ static int lt9611uxc_probe(struct i2c_client *client,
> >   lt9611uxc->fw_version = ret;
> >
> >   init_waitqueue_head(<9611uxc->wq);
> > + INIT_WORK(<9611uxc->work, lt9611uxc_hpd_work);
> > +
> >   ret = devm_request_threaded_irq(dev, client->irq, NULL,
> >   lt9611uxc_irq_thread_handler,
> >   IRQF_ONESHOT, "lt9611uxc", lt9611uxc);
> > @@ -96

[PATCH v2 11/11] drm/todo: Remove the drm_atomic_state todo item

[Maxime Ripard]

Only planes' prepare_fb and cleanup_fb, and encoders' atomic_check and
atomic_mode_set hooks remain with an object state and not the global
drm_atomic_state.

prepare_fb and cleanup_fb operate by design on a given state and
depending on the calling site can operate on either the old or new
state, so it doesn't really make much sense to convert them.

The encoders' atomic_check and atomic_mode_set operate on the CRTC and
connector state connected to them since encoders don't have a state of
their own. Without those state pointers, we would need to get the CRTC
through the drm_connector_state crtc pointer.

However, in order to get the drm_connector_state pointer, we would need
to get the connector itself and while usually we have a single connector
connected to the encoder, we can't really get it from the encoder at
the moment since it could be behind any number of bridges.

While this could be addressed by (for example) listing all the
connectors and finding the one that has the encoder as its source, it
feels like an unnecessary rework for something that is slowly getting
replaced by bridges.

Since all the users that matter have been converted, let's remove the
TODO item.

Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - New patch
---
 Documentation/gpu/todo.rst | 46 --
 1 file changed, 46 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 009d8e6c7e3c..609794108f5a 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -440,52 +440,6 @@ Contact: Emil Velikov, respective driver maintainers
 
 Level: Intermediate
 
-Plumb drm_atomic_state all over

-
-Currently various atomic functions take just a single or a handful of
-object states (eg. plane state). While that single object state can
-suffice for some simple cases, we often have to dig out additional
-object states for dealing with various dependencies between the individual
-objects or the hardware they represent. The process of digging out the
-additional states is rather non-intuitive and error prone.
-
-To fix that most functions should rather take the overall
-drm_atomic_state as one of their parameters. The other parameters
-would generally be the object(s) we mainly want to interact with.
-
-For example, instead of
-
-.. code-block:: c
-
-   int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state *state);
-
-we would have something like
-
-.. code-block:: c
-
-   int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state 
*state);
-
-The implementation can then trivially gain access to any required object
-state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(),
-drm_atomic_get_old_plane_state(), and their equivalents for
-other object types.
-
-Additionally many drivers currently access the object->state pointer
-directly in their commit functions. That is not going to work if we
-eg. want to allow deeper commit pipelines as those pointers could
-then point to the states corresponding to a future commit instead of
-the current commit we're trying to process. Also non-blocking commits
-execute locklessly so there are serious concerns with dereferencing
-the object->state pointers without holding the locks that protect them.
-Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(),
-etc. avoids these problems as well since they relate to a specific
-commit via the passed in drm_atomic_state.
-
-Contact: Ville Syrjälä, Daniel Vetter
-
-Level: Intermediate
-
 Use struct dma_buf_map throughout codebase
 --
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/13] opp: Implement dev_pm_opp_set_opp()

[Viresh Kumar]

Hello,

This patchset implements a new API dev_pm_opp_set_opp(), which
configures the devices represented by an opp table to a particular opp.
The opp core supports a wide variety of devices now, some of them can
change frequency and other properties (like CPUs), while others can just
change their pstates or regulators (like power domains) and then there
are others which can change their bandwidth as well (interconnects).
Instead of having separate implementations for all of them, where all
will eventually lack something or the other, lets try to implement a
common solution for everyone. This takes care of setting regulators, bw,
required opps, etc for all device types.

Dmitry, please go ahead and try this series. This is based of opp tree's
linux-next branch.

Sibi, since you added dev_pm_opp_set_bw() earlier, it would be good if
you can give this a try. In case this breaks anything for you.

I have already tested this on hikey board for CPU devices.

To get this tested better and as early as possible, I have pushed it
here:

git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm.git opp/linux-next

This will be part of linux-next tomorrow.

Note, all the patches need to go through OPP tree here. Please provide
your Acks for platform specific bits.

--
Viresh

Viresh Kumar (13):
  opp: Rename _opp_set_rate_zero()
  opp: No need to check clk for errors
  opp: Keep track of currently programmed OPP
  opp: Split _set_opp() out of dev_pm_opp_set_rate()
  opp: Allow _set_opp() to work for non-freq devices
  opp: Allow _generic_set_opp_regulator() to work for non-freq devices
  opp: Allow _generic_set_opp_clk_only() to work for non-freq devices
  opp: Update parameters of  _set_opp_custom()
  opp: Implement dev_pm_opp_set_opp()
  cpufreq: qcom: Migrate to dev_pm_opp_set_opp()
  devfreq: tegra30: Migrate to dev_pm_opp_set_opp()
  drm: msm: Migrate to dev_pm_opp_set_opp()
  opp: Remove dev_pm_opp_set_bw()

 drivers/cpufreq/qcom-cpufreq-hw.c |   2 +-
 drivers/devfreq/tegra30-devfreq.c |   2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |   8 +-
 drivers/opp/core.c| 314 ++
 drivers/opp/opp.h |   2 +
 include/linux/pm_opp.h|   6 +-
 6 files changed, 184 insertions(+), 150 deletions(-)

-- 
2.25.0.rc1.19.g042ed3e048af

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 04/11] drm/atomic: Pass the full state to planes atomic_check

[Maxime Ripard]

The current atomic helpers have either their object state being passed as
an argument or the full atomic state.

The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.

Let's convert all the remaining helpers to provide a consistent
interface, starting with the planes atomic_check.

The conversion was done using the coccinelle script below plus some
manual changes for vmwgfx, built tested on all the drivers.

@@
identifier plane, plane_state;
symbol state;
@@

 struct drm_plane_helper_funcs {
...
int (*atomic_check)(struct drm_plane *plane,
-   struct drm_plane_state *plane_state);
+   struct drm_atomic_state *state);
...
}

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_check = func,
...,
};

@@
struct drm_plane_helper_funcs *FUNCS;
identifier f;
identifier dev;
identifier plane, plane_state, state;
@@

 f(struct drm_device *dev, struct drm_atomic_state *state)
 {
<+...
-   FUNCS->atomic_check(plane, plane_state)
+   FUNCS->atomic_check(plane, state)
...+>
 }

@ ignores_new_state @
identifier plane_atomic_func.func;
identifier plane, new_plane_state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *new_plane_state)
 {
... when != new_plane_state
 }

@ adds_new_state depends on plane_atomic_func && !ignores_new_state @
identifier plane_atomic_func.func;
identifier plane, new_plane_state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *new_plane_state)
 {
+   struct drm_plane_state *new_plane_state = 
drm_atomic_get_new_plane_state(state, plane);
...
 }

@ depends on plane_atomic_func @
identifier plane_atomic_func.func;
identifier plane, new_plane_state;
@@

 func(struct drm_plane *plane,
- struct drm_plane_state *new_plane_state
+ struct drm_atomic_state *state
 )
 { ... }

@ include depends on adds_new_state @
@@

 #include 

@ no_include depends on !include && adds_new_state @
@@

+ #include 
  #include 

Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Rewording and removal of a coccinelle rule suggested by Laurent
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 4 +++-
 drivers/gpu/drm/arm/hdlcd_crtc.c  | 4 +++-
 drivers/gpu/drm/arm/malidp_planes.c   | 4 +++-
 drivers/gpu/drm/armada/armada_plane.c | 4 +++-
 drivers/gpu/drm/armada/armada_plane.h | 2 +-
 drivers/gpu/drm/ast/ast_mode.c| 8 ++--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c   | 3 ++-
 drivers/gpu/drm/drm_atomic_helper.c   | 2 +-
 drivers/gpu/drm/drm_simple_kms_helper.c   | 4 +++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +++-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c   | 5 -
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +++-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c   | 4 +++-
 drivers/gpu/drm/imx/dcss/dcss-plane.c | 4 +++-
 drivers/gpu/drm/imx/ipuv3-plane.c | 4 +++-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 +++-
 drivers/gpu/drm/ingenic/ingenic-ipu.c | 4 +++-
 drivers/gpu/drm/kmb/kmb_plane.c   | 4 +++-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c  | 4 +++-
 drivers/gpu/drm/meson/meson_overlay.c | 4 +++-
 drivers/gpu/drm/meson/meson_plane.c   | 4 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 5 -
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 4 +++-
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 4 +++-
 drivers/gpu/drm/nouveau/dispnv50/wndw.c   | 5 -
 drivers/gpu/drm/omapdrm/omap_plane.c  | 4 +++-
 drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   | 4 +++-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 4 +++-
 drivers/gpu/drm/sti/sti_cursor.c  | 4 +++-
 drivers/gpu/drm/sti/sti_gdp.c | 4 +++-
 drivers/gpu/drm/sti/sti_hqvdp.c   | 4 +++-
 drivers/gpu/drm/stm/ltdc.c| 4 +++-
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 4 +++-
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 4 +++-
 drivers/gpu/drm/tegra/dc.c| 8 ++--
 drivers/gpu/drm/tegra/hub.c   | 4 +++-
 drivers/gpu/drm/tidss/tidss_plane.c   | 4 +++-
 drivers/gpu/drm/tilcdc/tilcdc_plane.c | 4 +++-
 drivers/gpu/drm/vboxvideo/vbox_mode.c | 8 ++--
 drivers/gpu/drm/vc4/vc4_plane.c   | 4 +++-
 drivers/gpu/drm/virtio/virtgpu_pl

Re: [PATCH v16 0/4] RDMA: Add dma-buf support

[Jason Gunthorpe]

On Tue, Dec 15, 2020 at 01:27:12PM -0800, Jianxin Xiong wrote:
> Jianxin Xiong (4):
>   RDMA/umem: Support importing dma-buf as user memory region
>   RDMA/core: Add device method for registering dma-buf based memory
> region
>   RDMA/uverbs: Add uverbs command for dma-buf based MR registration
>   RDMA/mlx5: Support dma-buf based userspace memory region

I applied the below fix for rereg, but otherwise took this to rdma's
for-next

Thanks,
Jason

diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index f9ca19fa531b45..a63ef7c66e383d 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1825,9 +1825,6 @@ struct ib_mr *mlx5_ib_rereg_user_mr(struct ib_mr *ib_mr, 
int flags, u64 start,
if (flags & ~(IB_MR_REREG_TRANS | IB_MR_REREG_PD | IB_MR_REREG_ACCESS))
return ERR_PTR(-EOPNOTSUPP);
 
-   if (is_dmabuf_mr(mr))
-   return ERR_PTR(-EOPNOTSUPP);
-
if (!(flags & IB_MR_REREG_ACCESS))
new_access_flags = mr->access_flags;
if (!(flags & IB_MR_REREG_PD))
@@ -1844,8 +1841,8 @@ struct ib_mr *mlx5_ib_rereg_user_mr(struct ib_mr *ib_mr, 
int flags, u64 start,
return ERR_PTR(err);
return NULL;
}
-   /* DM or ODP MR's don't have a umem so we can't re-use it */
-   if (!mr->umem || is_odp_mr(mr))
+   /* DM or ODP MR's don't have a normal umem so we can't re-use 
it */
+   if (!mr->umem || is_odp_mr(mr) || is_dmabuf_mr(mr))
goto recreate;
 
/*
@@ -1864,10 +1861,10 @@ struct ib_mr *mlx5_ib_rereg_user_mr(struct ib_mr 
*ib_mr, int flags, u64 start,
}
 
/*
-* DM doesn't have a PAS list so we can't re-use it, odp does but the
-* logic around releasing the umem is different
+* DM doesn't have a PAS list so we can't re-use it, odp/dmabuf does
+* but the logic around releasing the umem is different
 */
-   if (!mr->umem || is_odp_mr(mr))
+   if (!mr->umem || is_odp_mr(mr) || is_dmabuf_mr(mr))
goto recreate;
 
if (!(new_access_flags & IB_ACCESS_ON_DEMAND) &&
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/bridge: lt9611: Fix handling of 4k panels

[Robert Foss]

Hi,

+Sam Ravnborg

I think this patch is ready to get pulled into the drm-misc tree.

On Thu, 17 Dec 2020 at 15:09, Robert Foss  wrote:
>
> 4k requires two dsi pipes, so don't report MODE_OK when only a
> single pipe is configured. But rather report MODE_PANEL to
> signal that requirements of the panel are not being met.
>
> Reported-by: Peter Collingbourne 
> Suggested-by: Peter Collingbourne 
> Signed-off-by: Robert Foss 
> Tested-by: John Stultz 
> Tested-by: Anibal Limon 
> Acked-By: Vinod Koul 
> Tested-by: Peter Collingbourne 
> Reviewed-by: Bjorn Andersson 
> ---
>  drivers/gpu/drm/bridge/lontium-lt9611.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c 
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> index d734d9402c35..e8eb8deb444b 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -867,8 +867,14 @@ static enum drm_mode_status 
> lt9611_bridge_mode_valid(struct drm_bridge *bridge,
>  const struct 
> drm_display_mode *mode)
>  {
> struct lt9611_mode *lt9611_mode = lt9611_find_mode(mode);
> +   struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
>
> -   return lt9611_mode ? MODE_OK : MODE_BAD;
> +   if (!lt9611_mode)
> +   return MODE_BAD;
> +   else if (lt9611_mode->intfs > 1 && !lt9611->dsi1)
> +   return MODE_PANEL;
> +   else
> +   return MODE_OK;
>  }
>
>  static void lt9611_bridge_pre_enable(struct drm_bridge *bridge)
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/13] drm: msm: Migrate to dev_pm_opp_set_opp()

[Viresh Kumar]

dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
be used instead. Migrate to the new API.

Signed-off-by: Viresh Kumar 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index e6703ae98760..05e0ef58fe32 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -134,7 +134,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)
 
if (!gmu->legacy) {
a6xx_hfi_set_freq(gmu, perf_index);
-   dev_pm_opp_set_bw(&gpu->pdev->dev, opp);
+   dev_pm_opp_set_opp(&gpu->pdev->dev, opp);
pm_runtime_put(gmu->dev);
return;
}
@@ -158,7 +158,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)
if (ret)
dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
 
-   dev_pm_opp_set_bw(&gpu->pdev->dev, opp);
+   dev_pm_opp_set_opp(&gpu->pdev->dev, opp);
pm_runtime_put(gmu->dev);
 }
 
@@ -866,7 +866,7 @@ static void a6xx_gmu_set_initial_bw(struct msm_gpu *gpu, 
struct a6xx_gmu *gmu)
if (IS_ERR_OR_NULL(gpu_opp))
return;
 
-   dev_pm_opp_set_bw(&gpu->pdev->dev, gpu_opp);
+   dev_pm_opp_set_opp(&gpu->pdev->dev, gpu_opp);
dev_pm_opp_put(gpu_opp);
 }
 
@@ -1072,7 +1072,7 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
a6xx_gmu_shutdown(gmu);
 
/* Remove the bus vote */
-   dev_pm_opp_set_bw(&gpu->pdev->dev, NULL);
+   dev_pm_opp_set_opp(&gpu->pdev->dev, NULL);
 
/*
 * Make sure the GX domain is off before turning off the GMU (CX)
-- 
2.25.0.rc1.19.g042ed3e048af

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/vc4: Correct lbm size and calculation

[Lucas Nussbaum]

Hi Maxime,

On 21/01/21 at 12:04 +0100, Maxime Ripard wrote:
> Hi Lucas, Ryutaroh,
> 
> On Thu, Jan 21, 2021 at 11:57:58AM +0100, Maxime Ripard wrote:
> > From: Dom Cobley 
> > 
> > LBM base address is measured in units of pixels per cycle.
> > That is 4 for 2711 (hvs5) and 2 for 2708.
> > 
> > We are wasting 75% of lbm by indexing without the scaling.
> > But we were also using too high a size for the lbm resulting
> > in partial corruption (right hand side) of vertically
> > scaled images, usually at 4K or lower resolutions with more layers.
> > 
> > The physical RAM of LBM on 2711 is 8 * 1920 * 16 * 12-bit
> > (pixels are stored 12-bits per component regardless of format).
> > 
> > The LBM adress indexes work in units of pixels per clock,
> > so for 4 pixels per clock that means we have 32 * 1920 = 60K
> > 
> > Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> > Signed-off-by: Dom Cobley 
> > Signed-off-by: Maxime Ripard 
> 
> This one should fix your issue
> 
> Feel free to test it and let me know if it's not the case

I confirm that the patches fix the issue I was seeing.

Thanks!

Lucas


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 08/11] drm: Rename plane->state variables in atomic update and disable

[Maxime Ripard]

Some drivers are storing the plane->state pointer in atomic_update and
atomic_disable in a variable simply called state, while the state passed
as an argument is called old_state.

In order to ease subsequent reworks and to avoid confusing or
inconsistent names, let's rename those variables to new_state.

This was done using the following coccinelle script, plus some manual
changes for mtk and tegra.

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

(
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_disable = func,
...,
 };
|
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_update = func,
...,
 };
)

@ moves_new_state_old_state @
identifier plane_atomic_func.func;
identifier plane;
symbol old_state;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_state)
 {
...
-   struct drm_plane_state *state = plane->state;
+   struct drm_plane_state *new_state = plane->state;
...
 }

@ depends on moves_new_state_old_state @
identifier plane_atomic_func.func;
identifier plane;
identifier old_state;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_state)
 {
<...
-   state
+   new_state
...>
 }

@ moves_new_state_oldstate @
identifier plane_atomic_func.func;
identifier plane;
symbol oldstate;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *oldstate)
 {
...
-   struct drm_plane_state *state = plane->state;
+   struct drm_plane_state *newstate = plane->state;
...
 }

@ depends on moves_new_state_oldstate @
identifier plane_atomic_func.func;
identifier plane;
identifier old_state;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_state)
 {
<...
-   state
+   newstate
...>
 }

@ moves_new_state_old_pstate @
identifier plane_atomic_func.func;
identifier plane;
symbol old_pstate;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_pstate)
 {
...
-   struct drm_plane_state *state = plane->state;
+   struct drm_plane_state *new_pstate = plane->state;
...
 }

@ depends on moves_new_state_old_pstate @
identifier plane_atomic_func.func;
identifier plane;
identifier old_pstate;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_pstate)
 {
<...
-   state
+   new_pstate
...>
 }

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/arm/malidp_planes.c   |  34 +++---
 drivers/gpu/drm/armada/armada_overlay.c   | 104 +-
 drivers/gpu/drm/armada/armada_plane.c |  63 +--
 drivers/gpu/drm/ast/ast_mode.c|  14 +--
 drivers/gpu/drm/exynos/exynos_drm_plane.c |   6 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c   |  10 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c|  12 +-
 .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c   |  11 +-
 drivers/gpu/drm/imx/dcss/dcss-plane.c |  25 +++--
 drivers/gpu/drm/imx/ipuv3-plane.c |  45 
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  16 +--
 drivers/gpu/drm/ingenic/ingenic-ipu.c |  34 +++---
 drivers/gpu/drm/mediatek/mtk_drm_plane.c  |  29 +++--
 drivers/gpu/drm/meson/meson_overlay.c |   6 +-
 drivers/gpu/drm/meson/meson_plane.c   |  30 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |   4 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c|  12 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c|   8 +-
 drivers/gpu/drm/mxsfb/mxsfb_kms.c |   4 +-
 drivers/gpu/drm/omapdrm/omap_plane.c  |  21 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   |  20 ++--
 drivers/gpu/drm/sti/sti_cursor.c  |  10 +-
 drivers/gpu/drm/sti/sti_gdp.c |  40 +++
 drivers/gpu/drm/sti/sti_hqvdp.c   |  40 +++
 drivers/gpu/drm/stm/ltdc.c|  28 ++---
 drivers/gpu/drm/tegra/dc.c|  20 ++--
 drivers/gpu/drm/tegra/hub.c   |  10 +-
 drivers/gpu/drm/tidss/tidss_plane.c   |   8 +-
 drivers/gpu/drm/tilcdc/tilcdc_plane.c |  14 +--
 drivers/gpu/drm/zte/zx_plane.c|   8 +-
 30 files changed, 347 insertions(+), 339 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index c94c4a96db68..646b27a42452 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -795,9 +795,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
 {
struct malidp_plane *mp;
struct malidp_plane_state *ms = to_malidp_plane_state(plane->state);
-   struct drm_plane_state *state = plane->state;
-   u16 pixel_alpha = state->pixel_blend_mode;
-   u8 plane_alpha = state->alpha >> 8;
+   struct drm_plane_state *new_state = plane->state;
+   u16 pixel_alpha = new_state->pixel_blend_mode;
+

[PATCH v2 01/11] drm/atomic: Pass the full state to planes async atomic check and update

[Maxime Ripard]

The current atomic helpers have either their object state being passed as
an argument or the full atomic state.

The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.

Let's start convert all the remaining helpers to provide a consistent
interface, starting with the planes atomic_async_check and
atomic_async_update.

The conversion was done using the coccinelle script below, built tested on
all the drivers.

@@
identifier plane, plane_state;
symbol state;
@@

 struct drm_plane_helper_funcs {
...
int (*atomic_async_check)(struct drm_plane *plane,
- struct drm_plane_state *plane_state);
+ struct drm_atomic_state *state);
...
 }

@@
identifier plane, plane_state;
symbol state;
@@
 struct drm_plane_helper_funcs {
...
void (*atomic_async_update)(struct drm_plane *plane,
-   struct drm_plane_state *plane_state);
+   struct drm_atomic_state *state);
...
 }

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

(
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_async_check = func,
...,
 };
|
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_async_update = func,
...,
 };
)

@@
struct drm_plane_helper_funcs *FUNCS;
identifier f;
identifier dev;
identifier plane, plane_state, state;
@@

 f(struct drm_device *dev, struct drm_atomic_state *state)
 {
<+...
-   FUNCS->atomic_async_check(plane, plane_state)
+   FUNCS->atomic_async_check(plane, state)
...+>
 }

@@
struct drm_plane_helper_funcs *FUNCS;
identifier f;
identifier dev;
identifier plane, plane_state, state;
@@

 f(struct drm_device *dev, struct drm_atomic_state *state)
 {
<+...
-   FUNCS->atomic_async_update(plane, plane_state)
+   FUNCS->atomic_async_update(plane, state)
...+>
 }

@@
identifier mtk_plane_atomic_async_update;
identifier plane;
symbol new_state, state;
expression e;
@@

  void mtk_plane_atomic_async_update(struct drm_plane *plane, struct 
drm_plane_state *new_state)
{
  ...
- struct mtk_plane_state *state = e;
+ struct mtk_plane_state *new_plane_state = e;
  <+...
-   state
+   new_plane_state
  ...+>
  }

@@
identifier plane_atomic_func.func;
identifier plane;
symbol state;
@@

 func(struct drm_plane *plane,
-struct drm_plane_state *state)
+struct drm_plane_state *new_plane_state)
 {
<...
-   state
+   new_plane_state
...>
 }

@ ignores_new_state @
identifier plane_atomic_func.func;
identifier plane, new_plane_state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *new_plane_state)
 {
... when != new_plane_state
 }

@ adds_new_state depends on plane_atomic_func && !ignores_new_state @
identifier plane_atomic_func.func;
identifier plane, new_plane_state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *new_plane_state)
 {
+   struct drm_plane_state *new_plane_state = 
drm_atomic_get_new_plane_state(state, plane);
...
 }

@ depends on plane_atomic_func @
identifier plane_atomic_func.func;
identifier plane, plane_state;
@@

 func(struct drm_plane *plane,
- struct drm_plane_state *plane_state
+ struct drm_atomic_state *state
 )
 { ... }

@ include depends on adds_new_state @
@@

 #include 

@ no_include depends on !include && adds_new_state @
@@

+ #include 
  #include 

@@
identifier plane_atomic_func.func;
identifier plane, state;
identifier plane_state;
@@

 func(struct drm_plane *plane, struct drm_atomic_state *state) {
...
struct drm_plane_state *plane_state = 
drm_atomic_get_new_plane_state(state, plane);
<+...
-   plane_state->state
+   state
...+>
 }

Acked-by: Thomas Zimmermann 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Updated the comment according to Thomas suggestions
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  8 ++-
 drivers/gpu/drm/drm_atomic_helper.c   |  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c  | 26 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 33 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 16 --
 drivers/gpu/drm/vc4/vc4_plane.c   | 56 ++-
 include/drm/drm_modeset_helper_vtables.h  | 18 +++---
 7 files changed, 89 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 86c2b2c897bb..7caebb1a475a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6469,7 +6469,7 @@ static int dm_plane_atomic_check(struct drm_plane *plane,
 }
 
 static int dm_plane_atomic_async_check(struct drm_plane *plane,
-  struct drm_plane_state *ne

Re: [PATCH 1/2] drm/vc4: Correct lbm size and calculation

[Maxime Ripard]

Hi Lucas, Ryutaroh,

On Thu, Jan 21, 2021 at 11:57:58AM +0100, Maxime Ripard wrote:
> From: Dom Cobley 
> 
> LBM base address is measured in units of pixels per cycle.
> That is 4 for 2711 (hvs5) and 2 for 2708.
> 
> We are wasting 75% of lbm by indexing without the scaling.
> But we were also using too high a size for the lbm resulting
> in partial corruption (right hand side) of vertically
> scaled images, usually at 4K or lower resolutions with more layers.
> 
> The physical RAM of LBM on 2711 is 8 * 1920 * 16 * 12-bit
> (pixels are stored 12-bits per component regardless of format).
> 
> The LBM adress indexes work in units of pixels per clock,
> so for 4 pixels per clock that means we have 32 * 1920 = 60K
> 
> Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 

This one should fix your issue

Feel free to test it and let me know if it's not the case

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: drm_modes: Fix signed-integer-overflow UBSAN warning

[AngeloGioacchino Del Regno]

During a UBSAN run on ARM64 MSM8998, kernel built with GCC 7.5.0,
a signed integer overflow was shown.
To solve this warning split the multiplication by assigning the
mode clock first to the "num" variable and then multiply: this
way was chosen because no explicit casting is required.

Solves the following warning:
[2.028003] UBSAN: signed-integer-overflow in 
drivers/gpu/drm/drm_modes.c:765:20
[2.028721] 2376000 * 1000 cannot be represented in type 'int'
[2.029134] CPU: 6 PID: 62 Comm: kworker/6:1 Tainted: GW 
5.11.0-rc4-00115-g38e7d22724f4-dirty #8
[2.029884] Hardware name: F(x)tec Pro1 (QX1000) (DT)
[2.030583] Workqueue: events deferred_probe_work_func
[2.031043] Call trace:
[2.031419]  dump_backtrace+0x0/0x288
[2.032144]  show_stack+0x14/0x60
[2.032564]  dump_stack+0xd4/0x12c
[2.032985]  ubsan_epilogue+0xc/0x50
[2.033693]  handle_overflow+0xd0/0xf8
[2.034092]  __ubsan_handle_mul_overflow+0x10/0x18
[2.034493]  drm_mode_vrefresh+0xd8/0xf8
[2.035181]  cea_mode_alternate_clock+0x18/0xb0
[2.035592]  drm_match_cea_mode.part.26+0xa8/0x198
[2.036004]  drm_match_cea_mode+0x14/0x28
[2.036689]  drm_mode_validate_ycbcr420+0x14/0x78
[2.037098]  drm_helper_probe_single_connector_modes+0x5fc/0x910
[2.037815]  drm_client_modeset_probe+0x26c/0x16f8
[2.038225]  __drm_fb_helper_initial_config_and_unlock+0x44/0x7b8
[2.038931]  drm_fb_helper_initial_config+0x48/0x68
[2.039337]  msm_fbdev_init+0x80/0xe0
[2.039735]  msm_drm_bind+0x4d8/0x6d0

Signed-off-by: AngeloGioacchino Del Regno 

---
 drivers/gpu/drm/drm_modes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 33fb2f05ce66..dd374c628cc5 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -762,7 +762,8 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode)
if (mode->htotal == 0 || mode->vtotal == 0)
return 0;
 
-   num = mode->clock * 1000;
+   num = mode->clock;
+   num *= 1000;
den = mode->htotal * mode->vtotal;
 
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Update todo.rst

[Maxime Ripard]

Hi Daniel,

On Thu, Jan 21, 2021 at 12:29:19PM +0100, Daniel Vetter wrote:
> Interrnship season is starting, let's review this. One thing that's

  ^ internship

> pending is Maxime's work to roll out drm_atomic_state pointers to all
> callbacks, he said he'll remove that entry once it's all done.

I plan on sending it by the end of the week

> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  Documentation/gpu/todo.rst | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 009d8e6c7e3c..492768dd2fd9 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -577,20 +577,24 @@ Contact: Daniel Vetter
>  
>  Level: Intermediate
>  
> -KMS cleanups
> -
> +Object lifetime fixes
> +-
> +
> +There's two related issues here
> +
> +- Cleanup up the various ->destroy callbacks, which often are all the same
> +  simple code.
>  
> -Some of these date from the very introduction of KMS in 2008 ...
> +- Lots of drivers erroneously allocate DRM modeset objects using 
> devm_kzalloc,
> +  which results in use-after free issues on driver unload. This can be 
> serious
> +  trouble even for drivers for hardwared integrated on the SoC due to

  ^ hardware?

> +  EPROBE_DEFERRED backoff.

Thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 02/13] module: add a module_loaded helper

[David Laight]

> 
> On Thu, Jan 21, 2021 at 11:00:20AM +0100, Christophe Leroy wrote:
> > > +bool module_loaded(const char *name);
> >
> > Maybe module_is_loaded() would be a better name.
> 
> Fine with me.

It does look like both callers aren't 'unsafe'.
But it is a bit strange returning a stale value.

It did make be look a bit more deeply at try_module_get().
For THIS_MODULE (eg to get an extra reference for a kthread)
I doubt it can ever fail.

But the other cases require a 'module' structure be passed in.
ISTM that unloading the module could invalidate the pointer
that has just been read from some other structure.

I'm guessing that some other lock must always be held.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/13] module: add a module_loaded helper

[Christophe Leroy]

Le 21/01/2021 à 08:49, Christoph Hellwig a écrit :
> Add a helper that takes modules_mutex and uses find_module to check if a
> given module is loaded.  This provides a better abstraction for the two
> callers, and allows to unexport modules_mutex and find_module.
>
> Signed-off-by: Christoph Hellwig 
> ---
>   drivers/gpu/drm/drm_fb_helper.c |  7 +--
>   include/linux/module.h  |  3 +++
>   kernel/module.c | 14 --
>   kernel/trace/trace_kprobe.c |  4 +---
>   4 files changed, 17 insertions(+), 11 deletions(-)
>

> diff --git a/include/linux/module.h b/include/linux/module.h
> index 7a0bcb5b1ffccd..b4654f8a408134 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -589,6 +589,9 @@ static inline bool within_module(unsigned long addr, 
const struct module *mod)
>   /* Search for module by name: must hold module_mutex. */
>   struct module *find_module(const char *name);
>   +/* Check if a module is loaded. */
> +bool module_loaded(const char *name);

Maybe module_is_loaded() would be a better name.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/vc4: Correct lbm size and calculation

[Maxime Ripard]

From: Dom Cobley 

LBM base address is measured in units of pixels per cycle.
That is 4 for 2711 (hvs5) and 2 for 2708.

We are wasting 75% of lbm by indexing without the scaling.
But we were also using too high a size for the lbm resulting
in partial corruption (right hand side) of vertically
scaled images, usually at 4K or lower resolutions with more layers.

The physical RAM of LBM on 2711 is 8 * 1920 * 16 * 12-bit
(pixels are stored 12-bits per component regardless of format).

The LBM adress indexes work in units of pixels per clock,
so for 4 pixels per clock that means we have 32 * 1920 = 60K

Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: Dom Cobley 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hvs.c   | 8 
 drivers/gpu/drm/vc4/vc4_plane.c | 7 ++-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 2b3a597fa65f..c239045e05d6 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -622,11 +622,11 @@ static int vc4_hvs_bind(struct device *dev, struct device 
*master, void *data)
 * for now we just allocate globally.
 */
if (!hvs->hvs5)
-   /* 96kB */
-   drm_mm_init(&hvs->lbm_mm, 0, 96 * 1024);
+   /* 48k words of 2x12-bit pixels */
+   drm_mm_init(&hvs->lbm_mm, 0, 48 * 1024);
else
-   /* 70k words */
-   drm_mm_init(&hvs->lbm_mm, 0, 70 * 2 * 1024);
+   /* 60k words of 4x12-bit pixels */
+   drm_mm_init(&hvs->lbm_mm, 0, 60 * 1024);
 
/* Upload filter kernels.  We only have the one for now, so we
 * keep it around for the lifetime of the driver.
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 6bd8260aa9f2..b98eabb52920 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -437,6 +437,7 @@ static void vc4_write_ppf(struct vc4_plane_state 
*vc4_state, u32 src, u32 dst)
 static u32 vc4_lbm_size(struct drm_plane_state *state)
 {
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
+   struct vc4_dev *vc4 = to_vc4_dev(state->plane->dev);
u32 pix_per_line;
u32 lbm;
 
@@ -472,7 +473,11 @@ static u32 vc4_lbm_size(struct drm_plane_state *state)
lbm = pix_per_line * 16;
}
 
-   lbm = roundup(lbm, 32);
+   /* Align it to 64 or 128 (hvs5) bytes */
+   lbm = roundup(lbm, vc4->hvs->hvs5 ? 128 : 64);
+
+   /* Each "word" of the LBM memory contains 2 or 4 (hvs5) pixels */
+   lbm /= vc4->hvs->hvs5 ? 4 : 2;
 
return lbm;
 }
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 06/11] drm: Use state helper instead of plane state pointer in atomic_check

[Maxime Ripard]

Many drivers reference the plane->state pointer in order to get the
current plane state in their atomic_check hook, which would be the old
plane state in the global atomic state since _swap_state hasn't happened
when atomic_check is run.

Use the drm_atomic_get_old_plane_state helper to get that state to make
it more obvious.

This was made using the coccinelle script below:

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

static struct drm_plane_helper_funcs helpers = {
...,
.atomic_check = func,
...,
};

@ replaces_old_state @
identifier plane_atomic_func.func;
identifier plane, state, plane_state;
@@

 func(struct drm_plane *plane, struct drm_atomic_state *state) {
...
-   struct drm_plane_state *plane_state = plane->state;
+   struct drm_plane_state *plane_state = 
drm_atomic_get_old_plane_state(state, plane);
...
 }

@@
identifier plane_atomic_func.func;
identifier plane, state, plane_state;
@@

 func(struct drm_plane *plane, struct drm_atomic_state *state) {
struct drm_plane_state *plane_state = 
drm_atomic_get_old_plane_state(state, plane);
...
-   plane->state
+   plane_state
...
 }

@ adds_old_state @
identifier plane_atomic_func.func;
identifier plane, state;
@@

 func(struct drm_plane *plane, struct drm_atomic_state *state) {
+   struct drm_plane_state *old_plane_state = 
drm_atomic_get_old_plane_state(state, plane);
...
-   plane->state
+   old_plane_state
...
 }

@ include depends on adds_old_state || replaces_old_state @
@@

 #include 

@ no_include depends on !include && (adds_old_state || replaces_old_state) @
@@

+ #include 
  #include 

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/imx/ipuv3-plane.c  | 3 ++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 +++-
 drivers/gpu/drm/tilcdc/tilcdc_plane.c  | 3 ++-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index b5f6123850bb..6484592e3f86 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -341,7 +341,8 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
 {
struct drm_plane_state *new_state = 
drm_atomic_get_new_plane_state(state,
   
plane);
-   struct drm_plane_state *old_state = plane->state;
+   struct drm_plane_state *old_state = 
drm_atomic_get_old_plane_state(state,
+  
plane);
struct drm_crtc_state *crtc_state;
struct device *dev = plane->dev->dev;
struct drm_framebuffer *fb = new_state->fb;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index 4aac6217a5ad..6ce6ce09fecc 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -406,12 +406,14 @@ static int mdp5_plane_atomic_check_with_state(struct 
drm_crtc_state *crtc_state,
 static int mdp5_plane_atomic_check(struct drm_plane *plane,
   struct drm_atomic_state *state)
 {
+   struct drm_plane_state *old_plane_state = 
drm_atomic_get_old_plane_state(state,
+   
 plane);
struct drm_plane_state *new_plane_state = 
drm_atomic_get_new_plane_state(state,

 plane);
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
 
-   crtc = new_plane_state->crtc ? new_plane_state->crtc : 
plane->state->crtc;
+   crtc = new_plane_state->crtc ? new_plane_state->crtc : 
old_plane_state->crtc;
if (!crtc)
return 0;
 
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c 
b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
index ebdd42dcaf82..c86258132432 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
@@ -26,7 +26,8 @@ static int tilcdc_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *new_state = 
drm_atomic_get_new_plane_state(state,
   
plane);
struct drm_crtc_state *crtc_state;
-   struct drm_plane_state *old_state = plane->state;
+   struct drm_plane_state *old_state = 
drm_atomic_get_old_plane_state(state,
+  
plane);
unsigned int pitch;
 
if (!new_state->crtc)
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/3] drm/bridge/lontium-lt9611uxc: fix handling of EDID/HPD

[Dmitry Baryshkov]

These three patches provide fixes for HPD handling and EDID readout for
Lontium lt9611uxc DSI-to-HDMI bridge driver.

Changes since v3:
 - Protect hdmi_connected using ocm_mutex
 - Remove !! conversion from int to boolean
 - Add missing Reviewed-by tags.

Changes since v2:
 - Declare lt9611uxc_hpd_work as static

Changes since v1:
 - Split first patch into two smaller patches
 - Add Fixes tags

Dmitry Baryshkov (3):
  drm/bridge/lontium-lt9611uxc: fix waiting for EDID to become available
  drm/bridge/lontium-lt9611uxc: fix get_edid return code
  drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/13] powerpc/powernv: remove get_cxl_module

[Andrew Donnellan]

On 21/1/21 6:49 pm, Christoph Hellwig wrote:

The static inline get_cxl_module function is entirely unused,
remove it.

Signed-off-by: Christoph Hellwig 


The one user of this was removed in 8bf6b91a5125a ("Revert 
"powerpc/powernv: Add support for the cxl kernel api on the real phb").


Thanks for picking this up.

Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: possible IO map leak in drm/gem

[Chuck Lever]

> On Jan 21, 2021, at 9:47 AM, Thomas Zimmermann  wrote:
> 
> (cc'ing dri-devel)
> 
> Hi,
> 
> thanks for reporting the bug.
> 
> Am 21.01.21 um 15:35 schrieb Chuck Lever:
>> Hi Thomas-
>> I was not able to find an appropriate mailing list entry in MAINTAINERS,
> 
> That would be dri-devel@lists.freedesktop.org
> 
>> so I'm mailing you directly as committer of record for:
>> 43676605f890 ("drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers")
>> I've noticed that since putting v5.11-rc on my test systems, overnight
>> on an otherwise idle system the load average seems to grow as the result
>> of a kernel worker thread.
> 
> Earlier this week I fixed a couple of leaks in that code. Could you please 
> apply the patch at [1] and report back if it fixes the issue.
> 
> If it's a separate problem, I'll take a closer look.

Thomas, thank you for your quick response. I've installed your patch
on one system and it looks promising already. I'll let it soak overnight.


> Best regards
> Thomas
> 
> [1] 
> https://lore.kernel.org/dri-devel/20210118144639.27307-1-tzimmerm...@suse.de/
> 
>> I used "perf top" to see what it had gotten up to, and it appears that
>> it was spending lots of time walking an interval tree on behalf of
>> memtype_reserve().
>> The most frequently-observed stack trace seems to be:
>>  kworker/3:1-2355  [003] 60950.150928: function: 
>> memtype_reserve
>>  kworker/3:1-2355  [003] 60950.150942: kernel_stack: > trace>
>> => c0c66083
>> => memtype_reserve (a005f9d5)
>> => __ioremap_caller (a005aac1)
>> => ttm_bo_vmap (c040f266)
>> => drm_gem_vram_vmap (c042c5cd)
>> => drm_gem_vmap (c0506a7f)
>> => drm_client_buffer_vmap (c0523741)
>> => drm_fb_helper_damage_work (c049a34a)
>> => process_one_work (a00dd92e)
>> => worker_thread (a00dde46)
>> => kthread (a00e22c4)
>> => ret_from_fork (a0004192)
>> I see a regular call to memtype_reserve(), but never a matching call to
>> memtype_free(), thus I suspect a leak of I/O maps in this code.
>> --
>> Chuck Lever
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer

--
Chuck Lever



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/3] drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler

[Dmitry Baryshkov]

drm hotplug handling code (drm_client_dev_hotplug()) can wait on mutex,
thus delaying further lt9611uxc IRQ events processing.  It was observed
occasionally during bootups, when drm_client_modeset_probe() was waiting
for EDID ready event, which was delayed because IRQ handler was stuck
trying to deliver hotplug event.
Move hotplug notifications from IRQ handler to separate work to be able
to process IRQ events without delays.

Signed-off-by: Dmitry Baryshkov 
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
---
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 46 +-
 1 file changed, 37 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c 
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index b708700e182d..fee27952ec6d 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -36,6 +37,7 @@ struct lt9611uxc {
struct mutex ocm_lock;
 
struct wait_queue_head wq;
+   struct work_struct work;
 
struct device_node *dsi0_node;
struct device_node *dsi1_node;
@@ -52,6 +54,8 @@ struct lt9611uxc {
 
bool hpd_supported;
bool edid_read;
+   /* can be accessed from different threads, so protect this with 
ocm_lock */
+   bool hdmi_connected;
uint8_t fw_version;
 };
 
@@ -143,23 +147,41 @@ static irqreturn_t lt9611uxc_irq_thread_handler(int irq, 
void *dev_id)
if (irq_status)
regmap_write(lt9611uxc->regmap, 0xb022, 0);
 
-   lt9611uxc_unlock(lt9611uxc);
-
if (irq_status & BIT(0)) {
lt9611uxc->edid_read = !!(hpd_status & BIT(0));
wake_up_all(<9611uxc->wq);
}
 
if (irq_status & BIT(1)) {
-   if (lt9611uxc->connector.dev)
-   drm_kms_helper_hotplug_event(lt9611uxc->connector.dev);
-   else
-   drm_bridge_hpd_notify(<9611uxc->bridge, !!(hpd_status 
& BIT(1)));
+   lt9611uxc->hdmi_connected = hpd_status & BIT(1);
+   schedule_work(<9611uxc->work);
}
 
+   lt9611uxc_unlock(lt9611uxc);
+
return IRQ_HANDLED;
 }
 
+static void lt9611uxc_hpd_work(struct work_struct *work)
+{
+   struct lt9611uxc *lt9611uxc = container_of(work, struct lt9611uxc, 
work);
+   bool connected;
+
+   if (lt9611uxc->connector.dev)
+   drm_kms_helper_hotplug_event(lt9611uxc->connector.dev);
+   else {
+
+   mutex_lock(<9611uxc->ocm_lock);
+   connected = lt9611uxc->hdmi_connected;
+   mutex_unlock(<9611uxc->ocm_lock);
+
+   drm_bridge_hpd_notify(<9611uxc->bridge,
+ connected ?
+ connector_status_connected :
+ connector_status_disconnected);
+   }
+}
+
 static void lt9611uxc_reset(struct lt9611uxc *lt9611uxc)
 {
gpiod_set_value_cansleep(lt9611uxc->reset_gpio, 1);
@@ -447,18 +469,21 @@ static enum drm_connector_status 
lt9611uxc_bridge_detect(struct drm_bridge *brid
struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
unsigned int reg_val = 0;
int ret;
-   int connected = 1;
+   bool connected = true;
+
+   lt9611uxc_lock(lt9611uxc);
 
if (lt9611uxc->hpd_supported) {
-   lt9611uxc_lock(lt9611uxc);
ret = regmap_read(lt9611uxc->regmap, 0xb023, ®_val);
-   lt9611uxc_unlock(lt9611uxc);
 
if (ret)
dev_err(lt9611uxc->dev, "failed to read hpd status: 
%d\n", ret);
else
connected  = reg_val & BIT(1);
}
+   lt9611uxc->hdmi_connected = connected;
+
+   lt9611uxc_unlock(lt9611uxc);
 
return connected ?  connector_status_connected :
connector_status_disconnected;
@@ -931,6 +956,8 @@ static int lt9611uxc_probe(struct i2c_client *client,
lt9611uxc->fw_version = ret;
 
init_waitqueue_head(<9611uxc->wq);
+   INIT_WORK(<9611uxc->work, lt9611uxc_hpd_work);
+
ret = devm_request_threaded_irq(dev, client->irq, NULL,
lt9611uxc_irq_thread_handler,
IRQF_ONESHOT, "lt9611uxc", lt9611uxc);
@@ -967,6 +994,7 @@ static int lt9611uxc_remove(struct i2c_client *client)
struct lt9611uxc *lt9611uxc = i2c_get_clientdata(client);
 
disable_irq(client->irq);
+   flush_scheduled_work();
lt9611uxc_audio_exit(lt9611uxc);
drm_bridge_remove(<9611uxc->bridge);
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds

[Daniel Lezcano]

On 21/01/2021 18:04, Lukasz Luba wrote:
> The simple_ondemand devfreq governor uses two thresholds to decide about
> the frequency change: upthreshold, downdifferential. These two tunable
> change the behavior of the governor decision, e.g. how fast to increase
> the frequency or how rapidly limit the frequency. This patch adds needed
> governor data with thresholds values gathered experimentally in different
> workloads.
> 
> Signed-off-by: Lukasz Luba 
> ---
> Hi all,
> 
> This patch aims to improve the panfrost performance in various workloads,
> (benchmarks, games). The simple_ondemand devfreq governor supports
> tunables to tweak the behaviour of the internal algorithm. The default
> values for these two thresholds (90 and 5) do not work well with panfrost.
> These new settings should provide good performance, short latency for
> rising the frequency due to rapid workload change and decent freq slow
> down when the load is decaying. Based on frequency change statistics,
> gathered during experiments, all frequencies are used, depending on
> the load. This provides some power savings (statistically). The highest
> frequency is also used when needed.
> 
> Example glmark2 results:
> 1. freq fixed to max: 153
> 2. these new thresholds values (w/ patch): 151
> 3. default governor values (w/o patch): 114
> 
> In future the devfreq framework would expose via sysfs these two
> tunables, so they can be adjusted by the middleware based on currently
> running workload (game, desktop, web browser, etc). These new values
> should be good enough, though.
> 
> Regards,
> Lukasz Luba
> 
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 +-
>  drivers/gpu/drm/panfrost/panfrost_devfreq.h |  2 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 56b3f5935703..7c5ffc81dce1 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -130,8 +130,16 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
>   panfrost_devfreq_profile.initial_freq = cur_freq;
>   dev_pm_opp_put(opp);
>  
> + /*
> +  * Setup default thresholds for the simple_ondemand governor.
> +  * The values are chosen based on experiments.
> +  */
> + pfdevfreq->gov_data.upthreshold = 45;
> + pfdevfreq->gov_data.downdifferential = 5;
> +
>   devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
> -   DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
> +   DEVFREQ_GOV_SIMPLE_ONDEMAND,
> +   &pfdevfreq->gov_data);
>   if (IS_ERR(devfreq)) {
>   DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
>   ret = PTR_ERR(devfreq);
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> index db6ea48e21f9..1e2a4de941aa 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
> @@ -4,6 +4,7 @@
>  #ifndef __PANFROST_DEVFREQ_H__
>  #define __PANFROST_DEVFREQ_H__
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -17,6 +18,7 @@ struct panfrost_devfreq {
>   struct devfreq *devfreq;
>   struct opp_table *regulators_opp_table;
>   struct thermal_cooling_device *cooling;
> + struct devfreq_simple_ondemand_data gov_data;
>   bool opp_of_table_added;
>  
>   ktime_t busy_time;

I think it is simpler to do:

+static struct devfreq_simple_ondemand_data panfrost_ondemand_data = {
+   .upthreshold = 45,
+   .downdifferential = 5,
+};

[ ... ]

   devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
- DEVFREQ_GOV_SIMPLE_ONDEMAND,
NULL);
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ &panfrost_ondemand_data);


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 02/11] drm: Rename plane atomic_check state names

[Maxime Ripard]

Most drivers call the argument to the plane atomic_check hook simply
state, which is going to conflict with the global atomic state in a
later rework. Let's rename it to new_plane_state (or new_state depending
on the convention used in the driver).

This was done using the coccinelle script below, and built tested:

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

 static const struct drm_plane_helper_funcs helpers = {
.atomic_check = func,
 };

@ has_old_state @
identifier plane_atomic_func.func;
identifier plane;
expression e;
symbol old_state;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *state)
 {
...
struct drm_plane_state *old_state = e;
...
 }

@ depends on has_old_state @
identifier plane_atomic_func.func;
identifier plane;
symbol old_state;
@@

 func(struct drm_plane *plane,
-   struct drm_plane_state *state
+   struct drm_plane_state *new_state
 )
 {
<+...
-   state
+   new_state
...+>
 }

@ has_state @
identifier plane_atomic_func.func;
identifier plane;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *state)
 {
...
 }

@ depends on has_state @
identifier plane_atomic_func.func;
identifier plane;
symbol old_state;
@@

 func(struct drm_plane *plane,
-   struct drm_plane_state *state
+   struct drm_plane_state *new_plane_state
 )
 {
<+...
-   state
+   new_plane_state
...+>
 }

Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Updated the variable name in the comment in omapdrm
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++---
 .../gpu/drm/arm/display/komeda/komeda_plane.c | 11 ++---
 drivers/gpu/drm/arm/hdlcd_crtc.c  | 18 
 drivers/gpu/drm/arm/malidp_planes.c   | 36 
 drivers/gpu/drm/armada/armada_plane.c | 41 ++-
 drivers/gpu/drm/ast/ast_mode.c| 26 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  6 +--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c   |  6 +--
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 22 +-
 .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c   | 24 +--
 drivers/gpu/drm/imx/dcss/dcss-plane.c | 26 ++--
 drivers/gpu/drm/imx/ipuv3-plane.c | 31 +++---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 27 ++--
 drivers/gpu/drm/ingenic/ingenic-ipu.c | 30 +++---
 drivers/gpu/drm/kmb/kmb_plane.c   | 22 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c  | 16 
 drivers/gpu/drm/meson/meson_overlay.c | 10 +++--
 drivers/gpu/drm/meson/meson_plane.c   | 10 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 35 
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c|  9 ++--
 drivers/gpu/drm/nouveau/dispnv50/wndw.c   |  5 ++-
 drivers/gpu/drm/omapdrm/omap_plane.c  | 21 +-
 drivers/gpu/drm/qxl/qxl_display.c |  6 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  7 ++--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  7 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 27 ++--
 drivers/gpu/drm/sti/sti_cursor.c  | 22 +-
 drivers/gpu/drm/sti/sti_gdp.c | 26 ++--
 drivers/gpu/drm/sti/sti_hqvdp.c   | 24 +--
 drivers/gpu/drm/stm/ltdc.c| 10 ++---
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 10 +++--
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 10 +++--
 drivers/gpu/drm/tegra/dc.c| 38 -
 drivers/gpu/drm/tegra/hub.c   | 18 
 drivers/gpu/drm/tidss/tidss_plane.c   | 34 ---
 drivers/gpu/drm/tilcdc/tilcdc_plane.c | 24 +--
 drivers/gpu/drm/vc4/vc4_plane.c   | 10 ++---
 drivers/gpu/drm/virtio/virtgpu_plane.c|  9 ++--
 drivers/gpu/drm/vkms/vkms_plane.c | 11 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 13 +++---
 drivers/gpu/drm/xlnx/zynqmp_disp.c| 10 +++--
 41 files changed, 403 insertions(+), 358 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 7caebb1a475a..dcf970454121 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6433,7 +6433,7 @@ static int dm_plane_helper_check_state(struct 
drm_plane_state *state,
 }
 
 static int dm_plane_atomic_check(struct drm_plane *plane,
-struct drm_plane_state *state)
+struct drm_plane_state *new_plane_state)
 {
struct amdgpu_device *adev = drm_to_adev(plane->dev);
struct dc *dc = adev->dm.dc;
@@ -6442,23 +6442,24 @@ static int dm_plane_atomic_check(struct drm_plane 
*plane,
struct drm_crtc_state *new_crtc_

[PATCH v2 07/11] drm: Store new plane state in a variable for atomic_update and disable

[Maxime Ripard]

In order to store the new plane state in a subsequent helper, let's move
the plane->state dereferences into a variable.

This was done using the following coccinelle script, plus some hand
changes for vmwgfx:

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

(
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_disable = func,
...,
 };
|
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_update = func,
...,
 };
)

@ has_new_state_old_state @
identifier plane_atomic_func.func;
identifier plane;
identifier new_state;
symbol old_state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_state)
 {
...
struct drm_plane_state *new_state = plane->state;
...
 }

@ depends on !has_new_state_old_state @
identifier plane_atomic_func.func;
identifier plane;
symbol old_state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_state)
 {
+   struct drm_plane_state *new_state = plane->state;
<+...
-   plane->state
+   new_state
...+>
 }

@ has_new_state_state @
identifier plane_atomic_func.func;
identifier plane;
identifier new_state;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *state)
 {
...
struct drm_plane_state *new_state = plane->state;
...
 }

@ depends on !has_new_state_state @
identifier plane_atomic_func.func;
identifier plane;
symbol state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *state)
 {
+   struct drm_plane_state *new_plane_state = plane->state;
<+...
-   plane->state
+   new_plane_state
...+>
 }

@ has_new_state_old_s @
identifier plane_atomic_func.func;
identifier plane;
identifier new_state;
symbol old_s;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_s)
 {
...
struct drm_plane_state *new_state = plane->state;
...
 }

@ depends on !has_new_state_old_s @
identifier plane_atomic_func.func;
identifier plane;
symbol old_s;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_s)
 {
+   struct drm_plane_state *new_s = plane->state;
<+...
-   plane->state
+   new_s
...+>
 }

Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Wrapping change suggested by Laurent in omapdrm
---
 drivers/gpu/drm/arc/arcpgu_crtc.c |  7 ++--
 drivers/gpu/drm/arm/hdlcd_crtc.c  |  7 ++--
 .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c   |  5 ++-
 drivers/gpu/drm/kmb/kmb_plane.c   | 19 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c  | 26 ++--
 drivers/gpu/drm/omapdrm/omap_plane.c  |  6 +--
 drivers/gpu/drm/qxl/qxl_display.c | 20 +
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |  5 ++-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  3 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c   |  3 +-
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c|  5 ++-
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c|  5 ++-
 drivers/gpu/drm/tegra/dc.c| 42 ++-
 drivers/gpu/drm/tegra/hub.c   | 25 +--
 drivers/gpu/drm/vboxvideo/vbox_mode.c | 22 +-
 drivers/gpu/drm/vkms/vkms_plane.c | 11 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 19 +
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c   |  5 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c  |  7 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c  |  9 ++--
 drivers/gpu/drm/xlnx/zynqmp_disp.c|  7 ++--
 drivers/gpu/drm/zte/zx_plane.c| 19 +
 22 files changed, 151 insertions(+), 126 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 895cdd991af6..2cea17a96d5c 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -147,14 +147,15 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *state)
 {
+   struct drm_plane_state *new_plane_state = plane->state;
struct arcpgu_drm_private *arcpgu;
struct drm_gem_cma_object *gem;
 
-   if (!plane->state->crtc || !plane->state->fb)
+   if (!new_plane_state->crtc || !new_plane_state->fb)
return;
 
-   arcpgu = crtc_to_arcpgu_priv(plane->state->crtc);
-   gem = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
+   arcpgu = crtc_to_arcpgu_priv(new_plane_state->crtc);
+   gem = drm_fb_cma_get_gem_obj(new_plane_state->fb, 0);
arc_pgu_write(arcpgu, ARCPGU_REG_BUF0_ADDR, gem->paddr);
 }
 
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 028ec39c8484..3f050a52e07a 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -262,7 +262,

[PATCH v2 03/11] drm/atmel-hlcdc: Rename custom plane state variable

[Maxime Ripard]

Subsequent reworks will pass the global atomic state in the function
prototype, and atomic_check and atomic_update already have such a
variable already. Let's change them to ease the rework.

Acked-by: Sam Ravnborg 
Signed-off-by: Maxime Ripard 
---
 .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c   | 118 +-
 1 file changed, 59 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 15bc93163833..c62e930bccad 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -596,16 +596,16 @@ static int atmel_hlcdc_plane_atomic_check(struct 
drm_plane *p,
  struct drm_plane_state *s)
 {
struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
-   struct atmel_hlcdc_plane_state *state =
+   struct atmel_hlcdc_plane_state *hstate =
drm_plane_state_to_atmel_hlcdc_plane_state(s);
const struct atmel_hlcdc_layer_desc *desc = plane->layer.desc;
-   struct drm_framebuffer *fb = state->base.fb;
+   struct drm_framebuffer *fb = hstate->base.fb;
const struct drm_display_mode *mode;
struct drm_crtc_state *crtc_state;
int ret;
int i;
 
-   if (!state->base.crtc || WARN_ON(!fb))
+   if (!hstate->base.crtc || WARN_ON(!fb))
return 0;
 
crtc_state = drm_atomic_get_existing_crtc_state(s->state, s->crtc);
@@ -617,94 +617,94 @@ static int atmel_hlcdc_plane_atomic_check(struct 
drm_plane *p,
if (ret || !s->visible)
return ret;
 
-   state->src_x = s->src.x1;
-   state->src_y = s->src.y1;
-   state->src_w = drm_rect_width(&s->src);
-   state->src_h = drm_rect_height(&s->src);
-   state->crtc_x = s->dst.x1;
-   state->crtc_y = s->dst.y1;
-   state->crtc_w = drm_rect_width(&s->dst);
-   state->crtc_h = drm_rect_height(&s->dst);
+   hstate->src_x = s->src.x1;
+   hstate->src_y = s->src.y1;
+   hstate->src_w = drm_rect_width(&s->src);
+   hstate->src_h = drm_rect_height(&s->src);
+   hstate->crtc_x = s->dst.x1;
+   hstate->crtc_y = s->dst.y1;
+   hstate->crtc_w = drm_rect_width(&s->dst);
+   hstate->crtc_h = drm_rect_height(&s->dst);
 
-   if ((state->src_x | state->src_y | state->src_w | state->src_h) &
+   if ((hstate->src_x | hstate->src_y | hstate->src_w | hstate->src_h) &
SUBPIXEL_MASK)
return -EINVAL;
 
-   state->src_x >>= 16;
-   state->src_y >>= 16;
-   state->src_w >>= 16;
-   state->src_h >>= 16;
+   hstate->src_x >>= 16;
+   hstate->src_y >>= 16;
+   hstate->src_w >>= 16;
+   hstate->src_h >>= 16;
 
-   state->nplanes = fb->format->num_planes;
-   if (state->nplanes > ATMEL_HLCDC_LAYER_MAX_PLANES)
+   hstate->nplanes = fb->format->num_planes;
+   if (hstate->nplanes > ATMEL_HLCDC_LAYER_MAX_PLANES)
return -EINVAL;
 
-   for (i = 0; i < state->nplanes; i++) {
+   for (i = 0; i < hstate->nplanes; i++) {
unsigned int offset = 0;
int xdiv = i ? fb->format->hsub : 1;
int ydiv = i ? fb->format->vsub : 1;
 
-   state->bpp[i] = fb->format->cpp[i];
-   if (!state->bpp[i])
+   hstate->bpp[i] = fb->format->cpp[i];
+   if (!hstate->bpp[i])
return -EINVAL;
 
-   switch (state->base.rotation & DRM_MODE_ROTATE_MASK) {
+   switch (hstate->base.rotation & DRM_MODE_ROTATE_MASK) {
case DRM_MODE_ROTATE_90:
-   offset = (state->src_y / ydiv) *
+   offset = (hstate->src_y / ydiv) *
 fb->pitches[i];
-   offset += ((state->src_x + state->src_w - 1) /
-  xdiv) * state->bpp[i];
-   state->xstride[i] = -(((state->src_h - 1) / ydiv) *
+   offset += ((hstate->src_x + hstate->src_w - 1) /
+  xdiv) * hstate->bpp[i];
+   hstate->xstride[i] = -(((hstate->src_h - 1) / ydiv) *
fb->pitches[i]) -
- (2 * state->bpp[i]);
-   state->pstride[i] = fb->pitches[i] - state->bpp[i];
+ (2 * hstate->bpp[i]);
+   hstate->pstride[i] = fb->pitches[i] - hstate->bpp[i];
break;
case DRM_MODE_ROTATE_180:
-   offset = ((state->src_y + state->src_h - 1) /
+   offset = ((hstate->src_y + hstate->src_h - 1) /
  ydiv) * fb->pitches[i];
-   offset += ((state->src_x + state->src_w - 1) /
-   

[PATCH v2 09/11] drm/atomic: Pass the full state to planes atomic disable and update

[Maxime Ripard]

The current atomic helpers have either their object state being passed as
an argument or the full atomic state.

The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.

Let's convert the remaining helpers to provide a consistent interface,
this time with the planes atomic_update and atomic_disable.

The conversion was done using the coccinelle script below, built tested on
all the drivers.

@@
identifier plane, plane_state;
symbol state;
@@

 struct drm_plane_helper_funcs {
...
void (*atomic_update)(struct drm_plane *plane,
- struct drm_plane_state *plane_state);
+ struct drm_atomic_state *state);
...
 }

@@
identifier plane, plane_state;
symbol state;
@@

 struct drm_plane_helper_funcs {
...
void (*atomic_disable)(struct drm_plane *plane,
-  struct drm_plane_state *plane_state);
+  struct drm_atomic_state *state);
...
 }

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

(
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_update = func,
...,
 };
|
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_disable = func,
...,
 };
)

@@
struct drm_plane_helper_funcs *FUNCS;
identifier f;
identifier crtc_state;
identifier plane, plane_state, state;
expression e;
@@

 f(struct drm_crtc_state *crtc_state)
 {
...
struct drm_atomic_state *state = e;
<+...
(
-   FUNCS->atomic_disable(plane, plane_state)
+   FUNCS->atomic_disable(plane, state)
|
-   FUNCS->atomic_update(plane, plane_state)
+   FUNCS->atomic_update(plane, state)
)
...+>
 }

@@
identifier plane_atomic_func.func;
identifier plane;
symbol state;
@@

 func(struct drm_plane *plane,
-struct drm_plane_state *state)
+struct drm_plane_state *old_plane_state)
 {
<...
-   state
+   old_plane_state
...>
 }

@ ignores_old_state @
identifier plane_atomic_func.func;
identifier plane, old_state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *old_state)
 {
... when != old_state
 }

@ adds_old_state depends on plane_atomic_func && !ignores_old_state @
identifier plane_atomic_func.func;
identifier plane, plane_state;
@@

 func(struct drm_plane *plane, struct drm_plane_state *plane_state)
 {
+   struct drm_plane_state *plane_state = 
drm_atomic_get_old_plane_state(state, plane);
...
 }

@ depends on plane_atomic_func @
identifier plane_atomic_func.func;
identifier plane, plane_state;
@@

 func(struct drm_plane *plane,
- struct drm_plane_state *plane_state
+ struct drm_atomic_state *state
 )
 { ... }

@ include depends on adds_old_state @
@@

 #include 

@ no_include depends on !include && adds_old_state @
@@

+ #include 
  #include 

@@
identifier plane_atomic_func.func;
identifier plane, state;
identifier plane_state;
@@

 func(struct drm_plane *plane, struct drm_atomic_state *state) {
...
struct drm_plane_state *plane_state = 
drm_atomic_get_old_plane_state(state, plane);
<+...
-   plane_state->state
+   state
...+>
 }

Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Reintroduce the old_plane_state check in zynqmp_disp_crtc_atomic_disable
---
 drivers/gpu/drm/arc/arcpgu_crtc.c |  2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c |  2 +-
 drivers/gpu/drm/arm/hdlcd_crtc.c  |  2 +-
 drivers/gpu/drm/arm/malidp_planes.c   |  6 --
 drivers/gpu/drm/armada/armada_overlay.c   |  8 ++--
 drivers/gpu/drm/armada/armada_plane.c |  8 ++--
 drivers/gpu/drm/ast/ast_mode.c| 12 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c   |  6 +++---
 drivers/gpu/drm/drm_atomic_helper.c   |  8 
 drivers/gpu/drm/drm_simple_kms_helper.c   |  4 +++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  6 --
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c   |  4 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c|  2 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c   |  4 ++--
 drivers/gpu/drm/imx/dcss/dcss-plane.c |  6 --
 drivers/gpu/drm/imx/ipuv3-plane.c |  6 --
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  4 ++--
 drivers/gpu/drm/ingenic/ingenic-ipu.c |  4 ++--
 drivers/gpu/drm/kmb/kmb_plane.c   |  8 +---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c   |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h   |  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c  |  8 
 drivers/gpu/drm/meson/meson_overlay.c |  4 ++--
 drivers/gpu/drm/meson/meson_plane.c   |  4 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  2 +-
 drivers/gpu/drm/msm/disp

[PATCH v2 05/11] drm: Use the state pointer directly in planes atomic_check

[Maxime Ripard]

Now that atomic_check takes the global atomic state as a parameter, we
don't need to go through the pointer in the plane state.

This was done using the following coccinelle script:

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

static struct drm_plane_helper_funcs helpers = {
...,
.atomic_check = func,
...,
};

@@
identifier plane_atomic_func.func;
identifier plane, state;
identifier plane_state;
@@

  func(struct drm_plane *plane, struct drm_atomic_state *state) {
  ...
- struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state, 
plane);
  <... when != plane_state
- plane_state->state
+ state
  ...>
 }

@@
identifier plane_atomic_func.func;
identifier plane, state;
identifier plane_state;
@@

  func(struct drm_plane *plane, struct drm_atomic_state *state) {
  ...
  struct drm_plane_state *plane_state = drm_atomic_get_new_plane_state(state, 
plane);
  <...
- plane_state->state
+ state
  ...>
 }

Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 

---

Changes from v1:
  - Fixed the formatting in zynqmp_disp
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 2 +-
 drivers/gpu/drm/arm/hdlcd_crtc.c  | 2 +-
 drivers/gpu/drm/armada/armada_plane.c | 4 ++--
 drivers/gpu/drm/ast/ast_mode.c| 4 ++--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c   | 2 +-
 drivers/gpu/drm/drm_simple_kms_helper.c   | 2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 2 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c   | 2 +-
 drivers/gpu/drm/imx/dcss/dcss-plane.c | 2 +-
 drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +-
 drivers/gpu/drm/ingenic/ingenic-ipu.c | 2 +-
 drivers/gpu/drm/kmb/kmb_plane.c   | 2 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c  | 2 +-
 drivers/gpu/drm/meson/meson_overlay.c | 2 +-
 drivers/gpu/drm/meson/meson_plane.c   | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 2 +-
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c  | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 2 +-
 drivers/gpu/drm/sti/sti_cursor.c  | 2 +-
 drivers/gpu/drm/sti/sti_gdp.c | 2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c   | 2 +-
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c| 2 +-
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c| 2 +-
 drivers/gpu/drm/tidss/tidss_plane.c   | 2 +-
 drivers/gpu/drm/tilcdc/tilcdc_plane.c | 2 +-
 drivers/gpu/drm/vboxvideo/vbox_mode.c | 8 
 drivers/gpu/drm/virtio/virtgpu_plane.c| 2 +-
 drivers/gpu/drm/vkms/vkms_plane.c | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 2 +-
 drivers/gpu/drm/xlnx/zynqmp_disp.c| 3 +--
 drivers/gpu/drm/zte/zx_plane.c| 4 ++--
 35 files changed, 41 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index dc340adba098..63284fe2bc22 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6452,7 +6452,7 @@ static int dm_plane_atomic_check(struct drm_plane *plane,
return 0;
 
new_crtc_state =
-   drm_atomic_get_new_crtc_state(new_plane_state->state,
+   drm_atomic_get_new_crtc_state(state,
  new_plane_state->crtc);
if (!new_crtc_state)
return -EINVAL;
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 2b67b6b9a6b5..4cc4800f0ae5 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -86,7 +86,7 @@ komeda_plane_atomic_check(struct drm_plane *plane,
if (!new_plane_state->crtc || !new_plane_state->fb)
return 0;
 
-   crtc_st = drm_atomic_get_crtc_state(new_plane_state->state,
+   crtc_st = drm_atomic_get_crtc_state(state,
new_plane_state->crtc);
if (IS_ERR(crtc_st) || !crtc_st->enable) {
DRM_DEBUG_ATOMIC("Cannot update plane on a disabled CRTC.\n");
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 9da9d0581ce9..028ec39c8484 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -244,7 +244,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
return -EINVAL;
}
 
-   for_each_new_crtc_in_state(new_plane_state->state, crtc, crtc_state,
+  

[PATCH v2 10/11] drm: Use state helper instead of the plane state pointer

[Maxime Ripard]

Many drivers reference the plane->state pointer in order to get the
current plane state in their atomic_update or atomic_disable hooks,
which would be the new plane state in the global atomic state since
_swap_state happened when those hooks are run.

Use the drm_atomic_get_new_plane_state helper to get that state to make it
more obvious.

This was made using the coccinelle script below:

@ plane_atomic_func @
identifier helpers;
identifier func;
@@

(
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_disable = func,
...,
 };
|
 static const struct drm_plane_helper_funcs helpers = {
...,
.atomic_update = func,
...,
 };
)

@ adds_new_state @
identifier plane_atomic_func.func;
identifier plane, state;
identifier new_state;
@@

 func(struct drm_plane *plane, struct drm_atomic_state *state)
 {
...
-   struct drm_plane_state *new_state = plane->state;
+   struct drm_plane_state *new_state = 
drm_atomic_get_new_plane_state(state, plane);
...
 }

@ include depends on adds_new_state @
@@

 #include 

@ no_include depends on !include && adds_new_state @
@@

+ #include 
  #include 

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   | 4 +++-
 drivers/gpu/drm/arm/hdlcd_crtc.c| 3 ++-
 drivers/gpu/drm/arm/malidp_planes.c | 3 ++-
 drivers/gpu/drm/armada/armada_overlay.c | 3 ++-
 drivers/gpu/drm/armada/armada_plane.c   | 3 ++-
 drivers/gpu/drm/ast/ast_mode.c  | 6 --
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c   | 3 ++-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 3 ++-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  | 3 ++-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 ++-
 drivers/gpu/drm/imx/dcss/dcss-plane.c   | 3 ++-
 drivers/gpu/drm/imx/ipuv3-plane.c   | 3 ++-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c   | 3 ++-
 drivers/gpu/drm/ingenic/ingenic-ipu.c   | 3 ++-
 drivers/gpu/drm/kmb/kmb_plane.c | 3 ++-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c| 6 --
 drivers/gpu/drm/meson/meson_overlay.c   | 3 ++-
 drivers/gpu/drm/meson/meson_plane.c | 3 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 3 ++-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c  | 4 +++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c  | 3 ++-
 drivers/gpu/drm/mxsfb/mxsfb_kms.c   | 3 ++-
 drivers/gpu/drm/omapdrm/omap_plane.c| 6 --
 drivers/gpu/drm/qxl/qxl_display.c   | 6 --
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ++-
 drivers/gpu/drm/sti/sti_cursor.c| 3 ++-
 drivers/gpu/drm/sti/sti_gdp.c   | 3 ++-
 drivers/gpu/drm/sti/sti_hqvdp.c | 3 ++-
 drivers/gpu/drm/stm/ltdc.c  | 3 ++-
 drivers/gpu/drm/sun4i/sun4i_layer.c | 3 ++-
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c  | 3 ++-
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c  | 3 ++-
 drivers/gpu/drm/tegra/dc.c  | 6 --
 drivers/gpu/drm/tegra/hub.c | 3 ++-
 drivers/gpu/drm/tidss/tidss_plane.c | 3 ++-
 drivers/gpu/drm/tilcdc/tilcdc_plane.c   | 3 ++-
 drivers/gpu/drm/vboxvideo/vbox_mode.c   | 6 --
 drivers/gpu/drm/vkms/vkms_plane.c   | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 3 ++-
 drivers/gpu/drm/xlnx/zynqmp_disp.c  | 3 ++-
 drivers/gpu/drm/zte/zx_plane.c  | 6 --
 46 files changed, 108 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index b185452d5542..7016f9cfe30d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -147,7 +148,8 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
struct drm_atomic_state *state)
 {
-   struct drm_plane_state *new_plane_state = plane->state;
+   struct drm_plane_state *new_plane_state = 
drm_atomic_get_new_plane_state(state,
+   
 plane);
struct arcpgu_drm_private *arcpgu;
struct drm_gem_cma_object *gem;
 
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 2500bf189420..7adb065169e9 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_cr

[PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5

[Maxime Ripard]

From: Dom Cobley 

Fixes failure with 4096x1080 resolutions

[  284.315379] WARNING: CPU: 1 PID: 901 at drivers/gpu/drm/vc4/vc4_plane.c:981 
vc4_plane_mode_set+0x1374/0x13c4
[  284.315385] Modules linked in: ir_rc5_decoder rpivid_hevc(C) 
bcm2835_codec(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) bcm2835_gpiomem 
v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 
videobuf2_common videodev mc cdc_acm xpad ir_rc6_decoder rc_rc6_mce 
gpio_ir_recv fuse
[  284.315509] CPU: 1 PID: 901 Comm: kodi.bin Tainted: G C
5.10.7 #1
[  284.315514] Hardware name: BCM2711
[  284.315518] Backtrace:
[  284.315533] [] (dump_backtrace) from [] 
(show_stack+0x20/0x24)
[  284.315540]  r7: r6: r5:6813 r4:c18ecf1c
[  284.315549] [] (show_stack) from [] 
(dump_stack+0xc4/0xf0)
[  284.315558] [] (dump_stack) from [] (__warn+0xfc/0x158)
[  284.315564]  r9: r8:0009 r7:03d5 r6:0009 r5:c08cc7dc 
r4:c0fd09b8
[  284.315572] [] (__warn) from [] 
(warn_slowpath_fmt+0x74/0xe4)
[  284.315577]  r7:c08cc7dc r6:03d5 r5:c0fd09b8 r4:
[  284.315584] [] (warn_slowpath_fmt) from [] 
(vc4_plane_mode_set+0x1374/0x13c4)
[  284.315589]  r8: r7: r6:1000 r5:c404c600 r4:c2e34600
[  284.315596] [] (vc4_plane_mode_set) from [] 
(vc4_plane_atomic_check+0x40/0x1c0)
[  284.315601]  r10:0001 r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640 
r5:c3d636c0
[  284.315605]  r4:c2e34600
[  284.315614] [] (vc4_plane_atomic_check) from [] 
(drm_atomic_helper_check_planes+0xec/0x1ec)
[  284.315620]  r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640 r5:c3d636c0 
r4:0006
[  284.315627] [] (drm_atomic_helper_check_planes) from [] 
(drm_atomic_helper_check+0x54/0x9c)
[  284.315633]  r9:c2e35400 r8:0006 r7: r6:c2ba7800 r5:c3d636c0 
r4:
[  284.315641] [] (drm_atomic_helper_check) from [] 
(vc4_atomic_check+0x25c/0x454)
[  284.315645]  r7: r6:c2ba7800 r5:0001 r4:c3d636c0
[  284.315652] [] (vc4_atomic_check) from [] 
(drm_atomic_check_only+0x5cc/0x7e0)
[  284.315658]  r10:c404c6c8 r9: r8:c472c480 r7:0003 r6:c3d636c0 
r5:
[  284.315662]  r4:003c r3:c08b7a4c
[  284.315670] [] (drm_atomic_check_only) from [] 
(drm_mode_atomic_ioctl+0x758/0xa7c)
[  284.315675]  r10:c3d46000 r9:c3d636c0 r8:c2ce8a70 r7:027e3a54 r6:0043 
r5:c1fbb800
[  284.315679]  r4:0281a858
[  284.315688] [] (drm_mode_atomic_ioctl) from [] 
(drm_ioctl_kernel+0xc4/0x108)
[  284.315693]  r10:c03864bc r9:c1fbb800 r8:c3d47e64 r7:c089b308 r6:0002 
r5:c2ba7800
[  284.315697]  r4:
[  284.315705] [] (drm_ioctl_kernel) from [] 
(drm_ioctl+0x1e8/0x3a0)
[  284.315711]  r9:c1fbb800 r8:00bc r7:c3d47e64 r6:0038 r5:c0e59570 
r4:0038
[  284.315719] [] (drm_ioctl) from [] 
(sys_ioctl+0x35c/0x914)
[  284.315724]  r10:c2d08200 r9: r8:c36fa300 r7:befdd870 r6:c03864bc 
r5:c36fa301
[  284.315728]  r4:c03864bc
[  284.315735] [] (sys_ioctl) from [] 
(ret_fast_syscall+0x0/0x28)
[  284.315739] Exception stack(0xc3d47fa8 to 0xc3d47ff0)
[  284.315745] 7fa0:   027eb750 befdd870  c03864bc 
befdd870 
[  284.315750] 7fc0: 027eb750 befdd870 c03864bc 0036 027e3948 0281a640 
0281a850 027e3a50
[  284.315756] 7fe0: b4b64100 befdd844 b4b5ba2c b49c994c
[  284.315762]  r10:0036 r9:c3d46000 r8:c0200204 r7:0036 r6:c03864bc 
r5:befdd870
[  284.315765]  r4:027eb750

Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: Dom Cobley 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index b98eabb52920..8c55679cbaef 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -917,9 +917,9 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
if (!vc4_state->is_unity) {
vc4_dlist_write(vc4_state,
VC4_SET_FIELD(vc4_state->crtc_w,
- SCALER_POS1_SCL_WIDTH) |
+ SCALER5_POS1_SCL_WIDTH) |
VC4_SET_FIELD(vc4_state->crtc_h,
- SCALER_POS1_SCL_HEIGHT));
+ SCALER5_POS1_SCL_HEIGHT));
}
 
/* Position Word 2: Source Image Size */
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 2/3] drm/bridge/lontium-lt9611uxc: fix get_edid return code

[Dmitry Baryshkov]

Return NULL pointer from get_edid() callback rather than ERR_PTR()
pointer, as DRM code does NULL checks rather than IS_ERR(). Also while
we are at it, return NULL if getting EDID timed out.

Signed-off-by: Dmitry Baryshkov 
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
Reviewed-by: Bjorn Andersson 
---
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c 
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index a59e811f1705..b708700e182d 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -505,7 +505,10 @@ static struct edid *lt9611uxc_bridge_get_edid(struct 
drm_bridge *bridge,
ret = lt9611uxc_wait_for_edid(lt9611uxc);
if (ret < 0) {
dev_err(lt9611uxc->dev, "wait for EDID failed: %d\n", ret);
-   return ERR_PTR(ret);
+   return NULL;
+   } else if (ret == 0) {
+   dev_err(lt9611uxc->dev, "wait for EDID timeout\n");
+   return NULL;
}
 
return drm_do_get_edid(connector, lt9611uxc_get_edid_block, lt9611uxc);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/3] drm/bridge/lontium-lt9611uxc: fix waiting for EDID to become available

[Dmitry Baryshkov]

- Call wake_up() when EDID ready event is received to wake
  wait_event_interruptible_timeout()

- Increase waiting timeout, reading EDID can take longer than 100ms, so
  let's be on a safe side.

Signed-off-by: Dmitry Baryshkov 
Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
Reviewed-by: Bjorn Andersson 
---
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c 
b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index 0c98d27f84ac..a59e811f1705 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -145,8 +145,10 @@ static irqreturn_t lt9611uxc_irq_thread_handler(int irq, 
void *dev_id)
 
lt9611uxc_unlock(lt9611uxc);
 
-   if (irq_status & BIT(0))
+   if (irq_status & BIT(0)) {
lt9611uxc->edid_read = !!(hpd_status & BIT(0));
+   wake_up_all(<9611uxc->wq);
+   }
 
if (irq_status & BIT(1)) {
if (lt9611uxc->connector.dev)
@@ -465,7 +467,7 @@ static enum drm_connector_status 
lt9611uxc_bridge_detect(struct drm_bridge *brid
 static int lt9611uxc_wait_for_edid(struct lt9611uxc *lt9611uxc)
 {
return wait_event_interruptible_timeout(lt9611uxc->wq, 
lt9611uxc->edid_read,
-   msecs_to_jiffies(100));
+   msecs_to_jiffies(500));
 }
 
 static int lt9611uxc_get_edid_block(void *data, u8 *buf, unsigned int block, 
size_t len)
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/selftest: Fix potential memory leak

[Pan Bian]

Object out is not released on path that no VMA instance found. The root
cause is jumping to an unexpected label on the error path.

Fixes: a47e788c2310 ("drm/i915/selftests: Exercise CS TLB invalidation")
Signed-off-by: Pan Bian 
---
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index c53a222e3dec..713770fb2b92 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1880,7 +1880,7 @@ static int igt_cs_tlb(void *arg)
vma = i915_vma_instance(out, vm, NULL);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
-   goto out_put_batch;
+   goto out_put_out;
}
 
err = i915_vma_pin(vma, 0, 0,
-- 
2.17.1


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/panfrost: Add governor data with pre-defined thresholds

[Lukasz Luba]

The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in different
workloads.

Signed-off-by: Lukasz Luba 
---
Hi all,

This patch aims to improve the panfrost performance in various workloads,
(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with panfrost.
These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.

Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114

In future the devfreq framework would expose via sysfs these two
tunables, so they can be adjusted by the middleware based on currently
running workload (game, desktop, web browser, etc). These new values
should be good enough, though.

Regards,
Lukasz Luba

 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 +-
 drivers/gpu/drm/panfrost/panfrost_devfreq.h |  2 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..7c5ffc81dce1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -130,8 +130,16 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
 
+   /*
+* Setup default thresholds for the simple_ondemand governor.
+* The values are chosen based on experiments.
+*/
+   pfdevfreq->gov_data.upthreshold = 45;
+   pfdevfreq->gov_data.downdifferential = 5;
+
devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
- DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ &pfdevfreq->gov_data);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
ret = PTR_ERR(devfreq);
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..1e2a4de941aa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -4,6 +4,7 @@
 #ifndef __PANFROST_DEVFREQ_H__
 #define __PANFROST_DEVFREQ_H__
 
+#include 
 #include 
 #include 
 
@@ -17,6 +18,7 @@ struct panfrost_devfreq {
struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
+   struct devfreq_simple_ondemand_data gov_data;
bool opp_of_table_added;
 
ktime_t busy_time;
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/vc4: Correct lbm size and calculation

[Ryutaroh Matsumoto]

Hi Maxime,

>> This one should fix your issue
>> Feel free to test it and let me know if it's not the case
> I confirm that the patches fix the issue I was seeing.

I also applied the sent patches
[PATCH 1/2] drm/vc4: Correct lbm size and calculation
[PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5
to the 5.10.9 kernel, and the symptom disappeared on my Raspberry Pi 4B 8GB.

Thank you very much! Ryutaroh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] drm/bridge/lontium-lt9611uxc: fix waiting for EDID to become available

[Andrzej Hajda]

W dniu 22.01.2021 o 00:33, Dmitry Baryshkov pisze:
> - Call wake_up() when EDID ready event is received to wake
>wait_event_interruptible_timeout()
>
> - Increase waiting timeout, reading EDID can take longer than 100ms, so
>let's be on a safe side.
>
> Signed-off-by: Dmitry Baryshkov 
> Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
> Reviewed-by: Bjorn Andersson 
Reviewed-by: Andrzej Hajda 

Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/3] drm/bridge/lontium-lt9611uxc: fix get_edid return code

[Andrzej Hajda]

W dniu 22.01.2021 o 00:33, Dmitry Baryshkov pisze:
> Return NULL pointer from get_edid() callback rather than ERR_PTR()
> pointer, as DRM code does NULL checks rather than IS_ERR(). Also while
> we are at it, return NULL if getting EDID timed out.
>
> Signed-off-by: Dmitry Baryshkov 
> Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")
> Reviewed-by: Bjorn Andersson 
Reviewed-by: Andrzej Hajda 

Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/selftest: Fix potential memory leak

[Chris Wilson]

Quoting Pan Bian (2021-01-22 01:56:40)
> Object out is not released on path that no VMA instance found. The root
> cause is jumping to an unexpected label on the error path.

Wouldn't the root cause be whatever caused the allocation to fail?

Language notwithstanding,
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/3] drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler

[Andrzej Hajda]

W dniu 22.01.2021 o 00:33, Dmitry Baryshkov pisze:
> drm hotplug handling code (drm_client_dev_hotplug()) can wait on mutex,
> thus delaying further lt9611uxc IRQ events processing.  It was observed
> occasionally during bootups, when drm_client_modeset_probe() was waiting
> for EDID ready event, which was delayed because IRQ handler was stuck
> trying to deliver hotplug event.
> Move hotplug notifications from IRQ handler to separate work to be able
> to process IRQ events without delays.
>
> Signed-off-by: Dmitry Baryshkov 
> Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge")


Reviewed-by: Andrzej Hajda 


Let's wait till Monday for other comments, then I can queue the patchset.


Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Experimental freesync video mode optimization

[Daniel Vetter]

On Fri, Jan 22, 2021 at 10:32:48AM +0200, Pekka Paalanen wrote:
> On Tue, 19 Jan 2021 10:50:26 -0500
> Aurabindo Pillai  wrote:
> 
> > Changes in V5
> > =
> > 
> > * More info in commit messages on the rationale of changes being added
> > to the kernel.
> > * Minor fixes
> 
> Hi,
> 
> thank you for adding the explanations in the commit messages I asked
> for. It is now up to DRM maintainers to determine if this is
> conceptually fine.
> 
> I do see that apparently setting the opt-in option does not yet taint
> the kernel although Daniel Vetter suggested it might be a good idea. I
> guess tainting the kernel would make it easier to remove this feature
> in the future because it would be easier to dismiss people that claim a
> kernel regression due to the removal.

Reading the descriptions I'm honestly not sure why this isn't enabled by
default?

Maybe the explanations should also capture why this is maybe not a good
idea ...
-Daniel

> 
> 
> Thanks,
> pq
> 
> 
> > --
> > 
> > This patchset enables freesync video mode usecase where the userspace
> > can request a freesync compatible video mode such that switching to this
> > mode does not trigger blanking.
> > 
> > This feature is guarded by a module parameter which is disabled by
> > default. Enabling this paramters adds additional modes to the driver
> > modelist, and also enables the optimization to skip modeset when using
> > one of these modes.
> > 
> > --
> > 
> > Aurabindo Pillai (3):
> >   drm/amd/display: Add module parameter for freesync video mode
> >   drm/amd/display: Add freesync video modes based on preferred modes
> >   drm/amd/display: Skip modeset for front porch change
> > 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   1 +
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  12 +
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 401 --
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   3 +
> >  4 files changed, 382 insertions(+), 35 deletions(-)
> > 
> 



-- 
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

Re: [PATCH 0/3] Experimental freesync video mode optimization

[Daniel Vetter]

On Fri, Jan 22, 2021 at 10:42:53AM +0100, Daniel Vetter wrote:
> On Fri, Jan 22, 2021 at 10:32:48AM +0200, Pekka Paalanen wrote:
> > On Tue, 19 Jan 2021 10:50:26 -0500
> > Aurabindo Pillai  wrote:
> > 
> > > Changes in V5
> > > =
> > > 
> > > * More info in commit messages on the rationale of changes being added
> > > to the kernel.
> > > * Minor fixes
> > 
> > Hi,
> > 
> > thank you for adding the explanations in the commit messages I asked
> > for. It is now up to DRM maintainers to determine if this is
> > conceptually fine.
> > 
> > I do see that apparently setting the opt-in option does not yet taint
> > the kernel although Daniel Vetter suggested it might be a good idea. I
> > guess tainting the kernel would make it easier to remove this feature
> > in the future because it would be easier to dismiss people that claim a
> > kernel regression due to the removal.
> 
> Reading the descriptions I'm honestly not sure why this isn't enabled by
> default?
> 
> Maybe the explanations should also capture why this is maybe not a good
> idea ...

And also, if this is a bad idea uapi-vise, then it definitely needs to be
behind the tainting module option until we've sorted it out (and then just
enable it by default once that's done).
-Daniel

> -Daniel
> 
> > 
> > 
> > Thanks,
> > pq
> > 
> > 
> > > --
> > > 
> > > This patchset enables freesync video mode usecase where the userspace
> > > can request a freesync compatible video mode such that switching to this
> > > mode does not trigger blanking.
> > > 
> > > This feature is guarded by a module parameter which is disabled by
> > > default. Enabling this paramters adds additional modes to the driver
> > > modelist, and also enables the optimization to skip modeset when using
> > > one of these modes.
> > > 
> > > --
> > > 
> > > Aurabindo Pillai (3):
> > >   drm/amd/display: Add module parameter for freesync video mode
> > >   drm/amd/display: Add freesync video modes based on preferred modes
> > >   drm/amd/display: Skip modeset for front porch change
> > > 
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   1 +
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  12 +
> > >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 401 --
> > >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   3 +
> > >  4 files changed, 382 insertions(+), 35 deletions(-)
> > > 
> > 
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
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

Re: [PATCH v4] drm/virtio: Track total GPU memory for virtio driver

[Daniel Vetter]

On Thu, Jan 21, 2021 at 11:58:22PM -0800, Yiwei Zhang wrote:
> On Thu, Jan 21, 2021 at 9:40 PM Yiwei Zhang  wrote:
> >
> > On the success of virtio_gpu_object_create, add size of newly allocated
> > bo to the tracked total_mem. In drm_gem_object_funcs.free, after the gem
> > bo loses its last refcount, subtract the bo size from the tracked
> > total_mem if the original underlying memory allocation is successful.
> >
> > It's more accurate to do this in device driver layer to best match when
> > the underlying resource gets allocated and destroyed during tracing.
> >
> > Signed-off-by: Yiwei Zhang 
> > ---
> >  drivers/gpu/drm/virtio/Kconfig  |  1 +
> >  drivers/gpu/drm/virtio/virtgpu_drv.h|  2 ++
> >  drivers/gpu/drm/virtio/virtgpu_object.c | 11 +++
> >  3 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> > index b925b8b1da16..e103b7e883b1 100644
> > --- a/drivers/gpu/drm/virtio/Kconfig
> > +++ b/drivers/gpu/drm/virtio/Kconfig
> > @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> > select DRM_KMS_HELPER
> > select DRM_GEM_SHMEM_HELPER
> > select VIRTIO_DMA_SHARED_BUFFER
> > +   select TRACE_GPU_MEM
> > help
> >This is the virtual GPU driver for virtio.  It can be used with
> >QEMU based VMMs (like KVM or Xen).
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> > b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > index 6a232553c99b..c5622f9b591f 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> > @@ -249,6 +249,8 @@ struct virtio_gpu_device {
> > spinlock_t resource_export_lock;
> > /* protects map state and host_visible_mm */
> > spinlock_t host_visible_lock;
> > +
> > +   atomic64_t total_mem;
> >  };
> >
> >  struct virtio_gpu_fpriv {
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
> > b/drivers/gpu/drm/virtio/virtgpu_object.c
> > index d69a5b6da553..e2251fc41509 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> > @@ -25,12 +25,21 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "virtgpu_drv.h"
> >
> >  static int virtio_gpu_virglrenderer_workaround = 1;
> >  module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int, 
> > 0400);
> >
> > +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device 
> > *vgdev,
> > + s64 delta)
> > +{
> > +   u64 total_mem = atomic64_add_return(delta, &vgdev->total_mem);
> > +
> > +   trace_gpu_mem_total(vgdev->ddev->primary->index, 0, total_mem);
> > +}
> > +
> >  int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t 
> > *resid)
> >  {
> > if (virtio_gpu_virglrenderer_workaround) {
> > @@ -104,6 +113,7 @@ static void virtio_gpu_free_object(struct 
> > drm_gem_object *obj)
> > struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
> >
> > if (bo->created) {
> > +   virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> > virtio_gpu_cmd_unref_resource(vgdev, bo);
> > virtio_gpu_notify(vgdev);
> > /* completion handler calls virtio_gpu_cleanup_object() */
> > @@ -265,6 +275,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
> > *vgdev,
> > virtio_gpu_object_attach(vgdev, bo, ents, nents);
> > }
> >
> > +   virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> > *bo_ptr = bo;
> > return 0;
> >
> > --
> > 2.30.0.280.ga3ce27912f-goog
> >
> 
> Re Gerd and Daniel:
> 
> I'm not sure why we want to couple this patch too much with the
> dma-bufs tracking. The tracepoint added here itself is pretty useful
> for tracking gem bo total usage in virtio gpu upon tracing. The
> original purpose for integrating this tracepoint in all Android gpu
> kernel drivers is to just track total gpu memory usage and serve the
> accurate data to game developers in a much easier way. It's something
> they can rely on for robust testing and regression monitoring.
> 
> The only overlap with the dma-buf side is when we export a bo via
> prime to a dma-buf. But still, the total here is already useful for
> this particular device. Using which approach to account for the
> overlap wouldn't block this small integration from my understanding.
> 
> Besides, there's no plan for adding per-process gem total tracking in
> virtio-gpu at this moment. This patch should be light enough to carry
> without worrying about tech debt I believe.

The tracepoint is clearly more generic than just what you implement here,
to support the full use cases on Android's closed stacks. And it is uapi.

Tech debt isn't measured in lines of code, but in how expensive it's going
to be to fix up the mess in the future. uapi is expensive no matter how
few lines are used to implement it.

So yeah t

Re: [PATCH 1/2] drm/vc4: Correct lbm size and calculation

[Dave Stevenson]

Hi Maxime

On Thu, 21 Jan 2021 at 10:58, Maxime Ripard  wrote:
>
> From: Dom Cobley 
>
> LBM base address is measured in units of pixels per cycle.
> That is 4 for 2711 (hvs5) and 2 for 2708.
>
> We are wasting 75% of lbm by indexing without the scaling.
> But we were also using too high a size for the lbm resulting
> in partial corruption (right hand side) of vertically
> scaled images, usually at 4K or lower resolutions with more layers.
>
> The physical RAM of LBM on 2711 is 8 * 1920 * 16 * 12-bit
> (pixels are stored 12-bits per component regardless of format).
>
> The LBM adress indexes work in units of pixels per clock,
> so for 4 pixels per clock that means we have 32 * 1920 = 60K
>
> Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hvs.c   | 8 
>  drivers/gpu/drm/vc4/vc4_plane.c | 7 ++-
>  2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 2b3a597fa65f..c239045e05d6 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -622,11 +622,11 @@ static int vc4_hvs_bind(struct device *dev, struct 
> device *master, void *data)
>  * for now we just allocate globally.
>  */
> if (!hvs->hvs5)
> -   /* 96kB */
> -   drm_mm_init(&hvs->lbm_mm, 0, 96 * 1024);
> +   /* 48k words of 2x12-bit pixels */
> +   drm_mm_init(&hvs->lbm_mm, 0, 48 * 1024);
> else
> -   /* 70k words */
> -   drm_mm_init(&hvs->lbm_mm, 0, 70 * 2 * 1024);
> +   /* 60k words of 4x12-bit pixels */
> +   drm_mm_init(&hvs->lbm_mm, 0, 60 * 1024);
>
> /* Upload filter kernels.  We only have the one for now, so we
>  * keep it around for the lifetime of the driver.
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 6bd8260aa9f2..b98eabb52920 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -437,6 +437,7 @@ static void vc4_write_ppf(struct vc4_plane_state 
> *vc4_state, u32 src, u32 dst)
>  static u32 vc4_lbm_size(struct drm_plane_state *state)
>  {
> struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
> +   struct vc4_dev *vc4 = to_vc4_dev(state->plane->dev);
> u32 pix_per_line;
> u32 lbm;
>
> @@ -472,7 +473,11 @@ static u32 vc4_lbm_size(struct drm_plane_state *state)
> lbm = pix_per_line * 16;
> }
>
> -   lbm = roundup(lbm, 32);
> +   /* Align it to 64 or 128 (hvs5) bytes */
> +   lbm = roundup(lbm, vc4->hvs->hvs5 ? 128 : 64);
> +
> +   /* Each "word" of the LBM memory contains 2 or 4 (hvs5) pixels */
> +   lbm /= vc4->hvs->hvs5 ? 4 : 2;
>
> return lbm;
>  }
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5

[Dave Stevenson]

Hi Maxime.

On Thu, 21 Jan 2021 at 10:58, Maxime Ripard  wrote:
>
> From: Dom Cobley 
>
> Fixes failure with 4096x1080 resolutions
>
> [  284.315379] WARNING: CPU: 1 PID: 901 at 
> drivers/gpu/drm/vc4/vc4_plane.c:981 vc4_plane_mode_set+0x1374/0x13c4
> [  284.315385] Modules linked in: ir_rc5_decoder rpivid_hevc(C) 
> bcm2835_codec(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) bcm2835_gpiomem 
> v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 
> videobuf2_common videodev mc cdc_acm xpad ir_rc6_decoder rc_rc6_mce 
> gpio_ir_recv fuse
> [  284.315509] CPU: 1 PID: 901 Comm: kodi.bin Tainted: G C
> 5.10.7 #1
> [  284.315514] Hardware name: BCM2711
> [  284.315518] Backtrace:
> [  284.315533] [] (dump_backtrace) from [] 
> (show_stack+0x20/0x24)
> [  284.315540]  r7: r6: r5:6813 r4:c18ecf1c
> [  284.315549] [] (show_stack) from [] 
> (dump_stack+0xc4/0xf0)
> [  284.315558] [] (dump_stack) from [] (__warn+0xfc/0x158)
> [  284.315564]  r9: r8:0009 r7:03d5 r6:0009 r5:c08cc7dc 
> r4:c0fd09b8
> [  284.315572] [] (__warn) from [] 
> (warn_slowpath_fmt+0x74/0xe4)
> [  284.315577]  r7:c08cc7dc r6:03d5 r5:c0fd09b8 r4:
> [  284.315584] [] (warn_slowpath_fmt) from [] 
> (vc4_plane_mode_set+0x1374/0x13c4)
> [  284.315589]  r8: r7: r6:1000 r5:c404c600 r4:c2e34600
> [  284.315596] [] (vc4_plane_mode_set) from [] 
> (vc4_plane_atomic_check+0x40/0x1c0)
> [  284.315601]  r10:0001 r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640 
> r5:c3d636c0
> [  284.315605]  r4:c2e34600
> [  284.315614] [] (vc4_plane_atomic_check) from [] 
> (drm_atomic_helper_check_planes+0xec/0x1ec)
> [  284.315620]  r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640 r5:c3d636c0 
> r4:0006
> [  284.315627] [] (drm_atomic_helper_check_planes) from 
> [] (drm_atomic_helper_check+0x54/0x9c)
> [  284.315633]  r9:c2e35400 r8:0006 r7: r6:c2ba7800 r5:c3d636c0 
> r4:
> [  284.315641] [] (drm_atomic_helper_check) from [] 
> (vc4_atomic_check+0x25c/0x454)
> [  284.315645]  r7: r6:c2ba7800 r5:0001 r4:c3d636c0
> [  284.315652] [] (vc4_atomic_check) from [] 
> (drm_atomic_check_only+0x5cc/0x7e0)
> [  284.315658]  r10:c404c6c8 r9: r8:c472c480 r7:0003 r6:c3d636c0 
> r5:
> [  284.315662]  r4:003c r3:c08b7a4c
> [  284.315670] [] (drm_atomic_check_only) from [] 
> (drm_mode_atomic_ioctl+0x758/0xa7c)
> [  284.315675]  r10:c3d46000 r9:c3d636c0 r8:c2ce8a70 r7:027e3a54 r6:0043 
> r5:c1fbb800
> [  284.315679]  r4:0281a858
> [  284.315688] [] (drm_mode_atomic_ioctl) from [] 
> (drm_ioctl_kernel+0xc4/0x108)
> [  284.315693]  r10:c03864bc r9:c1fbb800 r8:c3d47e64 r7:c089b308 r6:0002 
> r5:c2ba7800
> [  284.315697]  r4:
> [  284.315705] [] (drm_ioctl_kernel) from [] 
> (drm_ioctl+0x1e8/0x3a0)
> [  284.315711]  r9:c1fbb800 r8:00bc r7:c3d47e64 r6:0038 r5:c0e59570 
> r4:0038
> [  284.315719] [] (drm_ioctl) from [] 
> (sys_ioctl+0x35c/0x914)
> [  284.315724]  r10:c2d08200 r9: r8:c36fa300 r7:befdd870 r6:c03864bc 
> r5:c36fa301
> [  284.315728]  r4:c03864bc
> [  284.315735] [] (sys_ioctl) from [] 
> (ret_fast_syscall+0x0/0x28)
> [  284.315739] Exception stack(0xc3d47fa8 to 0xc3d47ff0)
> [  284.315745] 7fa0:   027eb750 befdd870  c03864bc 
> befdd870 
> [  284.315750] 7fc0: 027eb750 befdd870 c03864bc 0036 027e3948 0281a640 
> 0281a850 027e3a50
> [  284.315756] 7fe0: b4b64100 befdd844 b4b5ba2c b49c994c
> [  284.315762]  r10:0036 r9:c3d46000 r8:c0200204 r7:0036 r6:c03864bc 
> r5:befdd870
> [  284.315765]  r4:027eb750
>
> Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_plane.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index b98eabb52920..8c55679cbaef 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -917,9 +917,9 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> if (!vc4_state->is_unity) {
> vc4_dlist_write(vc4_state,
> VC4_SET_FIELD(vc4_state->crtc_w,
> - SCALER_POS1_SCL_WIDTH) |
> + SCALER5_POS1_SCL_WIDTH) 
> |
> VC4_SET_FIELD(vc4_state->crtc_h,
> - 
> SCALER_POS1_SCL_HEIGHT));
> + 
> SCALER5_POS1_SCL_HEIGHT));
> }
>
> /* Position Word 2: Source Image Size */
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/

Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds

[Steven Price]

On 22/01/2021 10:11, Lukasz Luba wrote:



On 1/21/21 5:15 PM, Daniel Lezcano wrote:

On 21/01/2021 18:04, Lukasz Luba wrote:

The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in 
different

workloads.

Signed-off-by: Lukasz Luba 
---
Hi all,

This patch aims to improve the panfrost performance in various 
workloads,

(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with 
panfrost.

These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.

Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114

In future the devfreq framework would expose via sysfs these two
tunables, so they can be adjusted by the middleware based on currently
running workload (game, desktop, web browser, etc). These new values
should be good enough, though.

Regards,
Lukasz Luba

  drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 +-
  drivers/gpu/drm/panfrost/panfrost_devfreq.h |  2 ++
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c

index 56b3f5935703..7c5ffc81dce1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -130,8 +130,16 @@ int panfrost_devfreq_init(struct panfrost_device 
*pfdev)

  panfrost_devfreq_profile.initial_freq = cur_freq;
  dev_pm_opp_put(opp);
+    /*
+ * Setup default thresholds for the simple_ondemand governor.
+ * The values are chosen based on experiments.
+ */
+    pfdevfreq->gov_data.upthreshold = 45;
+    pfdevfreq->gov_data.downdifferential = 5;
+
  devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
-  DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
+  DEVFREQ_GOV_SIMPLE_ONDEMAND,
+  &pfdevfreq->gov_data);
  if (IS_ERR(devfreq)) {
  DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
  ret = PTR_ERR(devfreq);
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h

index db6ea48e21f9..1e2a4de941aa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -4,6 +4,7 @@
  #ifndef __PANFROST_DEVFREQ_H__
  #define __PANFROST_DEVFREQ_H__
+#include 
  #include 
  #include 
@@ -17,6 +18,7 @@ struct panfrost_devfreq {
  struct devfreq *devfreq;
  struct opp_table *regulators_opp_table;
  struct thermal_cooling_device *cooling;
+    struct devfreq_simple_ondemand_data gov_data;
  bool opp_of_table_added;
  ktime_t busy_time;


I think it is simpler to do:

+static struct devfreq_simple_ondemand_data panfrost_ondemand_data = {
+   .upthreshold = 45,
+   .downdifferential = 5,
+};

[ ... ]

    devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
- DEVFREQ_GOV_SIMPLE_ONDEMAND,
NULL);
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ &panfrost_ondemand_data);




Yes, it's simpler. The driver would probably never have to serve two
GPUs. I've tried to keep this thing inside the panfrost struct,
forgetting about it.


The Juno platform with an FPGA attached is the only example I know of 
where a system has multiple Mali GPUs - so it can happen, but it rare.


As it stands a static structure would work because the values are 
constant - but Lukasz mentioned that they would be exported in sysfs in 
the future, in which case they really should be part of the panfrost struct.


Ultimately having a (non-const) static struct like above would mean 
wasting a few bytes on systems with Panfrost loaded but no Mali GPU. 
Having it in struct panfrost means the cost is only for Mali. Admittedly 
it's only a few bytes in this case and often Panfrost will be a module.


Steve


Steven already reviewed the patch, so it can probably stay.
I will keep it in mind. Thank you for the comments.

Regards,
Lukasz


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-deve

Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds

[Steven Price]

On 22/01/2021 10:00, Lukasz Luba wrote:



On 1/22/21 8:21 AM, Steven Price wrote:

On 21/01/2021 17:04, Lukasz Luba wrote:

The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in 
different

workloads.

Signed-off-by: Lukasz Luba 
---
Hi all,

This patch aims to improve the panfrost performance in various 
workloads,

(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with 
panfrost.

These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.

Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114


It would be good to state which platform this is on as this obviously 
can vary depending on the OPPs available.


Sorry about that. It was Rock Pi 4B and I have mesa 20.2.4.



Of course the real fix here would be to improve the utilisation of the 
GPU[1] so we actually hit the 90% threshold more easily (AFAICT kbase 
uses the default 90/5 thresholds), but this seems like a reasonable 
change for now.


Agree, improving the scheduler would be the best option. I'll have a
look at that patch and why it got this 10% lower performance. Maybe
I would find something during testing.


I'm afraid it'll probably need a fair bit of work to rebase - things 
have changed around that code. I'm hoping that most of the problem was 
really around how Mesa was driving the GPU at that time and things 
should be better. The DDK (hacked to talk Panfrost ioctls) saw a 
performance improvement.


Let me know if you hit problems and need any help.



Reviewed-by: Steven Price 


Thank you for the review. I guess this patch would go through drm tree?


Yes, I'll push it to drm-misc-next later.

Thanks,

Steve


Regards,
Lukasz



Thanks,

Steve

[1] When I get some time I need to rework the "queue jobs on the 
hardware"[2] patch I posted ages ago. Last time it actually caused a 
performance regression though...


[2] 
https://lore.kernel.org/r/20190816093107.30518-2-steven.price%40arm.com




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] tests/util: Add mxsfb-drm driver

[Lucas Stach]

Hi Fabio,

I've pushed this patch to the libdrm git repo.

Regards,
Lucas

Am Mittwoch, dem 30.12.2020 um 15:29 -0300 schrieb Fabio Estevam:
> Add an entry for the "mxsfb-drm" driver, so that the test utilities
> work with the mxsfb driver without passing the -M argument.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  tests/util/kms.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/util/kms.c b/tests/util/kms.c
> index 08b48fe585b7..39a93866a9d1 100644
> --- a/tests/util/kms.c
> +++ b/tests/util/kms.c
> @@ -149,6 +149,7 @@ static const char * const modules[] = {
>   "armada-drm",
>   "komeda",
>   "imx-dcss",
> + "mxsfb-drm",
>  };
>  
> 
>  int util_open(const char *device, const char *module)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 05/15] drm/vc4: hdmi: Restore cec physical address on reconnect

[Dave Stevenson]

Hi Maxime

Sorry for the slow reply on these patches.

On Mon, 11 Jan 2021 at 14:23, Maxime Ripard  wrote:
>
> From: Dom Cobley 
>
> Currently we call cec_phys_addr_invalidate on a hotplug deassert.
> That may be due to a TV power cycling, or an AVR being switched
> on (and switching edid).
>
> This makes CEC unusable since our controller wouldn't have a physical
> address anymore.
>
> Set it back up again on the hotplug assert.
>
> Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support")
> Signed-off-by: Dom Cobley 
> Signed-off-by: Maxime Ripard 

I follow the logic, and trust Dom that it works, but I don't know if
that is the correct thing within CEC.
Ideally Hans will comment as the original author of the CEC code - I
believe he's testing the series anyway.

Acked-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 7945dbcee78c..c3a301396aad 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -136,20 +136,32 @@ static enum drm_connector_status
>  vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
>  {
> struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
> +   bool connected = false;
>
> if (vc4_hdmi->hpd_gpio) {
> if (gpio_get_value_cansleep(vc4_hdmi->hpd_gpio) ^
> vc4_hdmi->hpd_active_low)
> -   return connector_status_connected;
> -   cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> -   return connector_status_disconnected;
> +   connected = true;
> +   } else if (drm_probe_ddc(vc4_hdmi->ddc)) {
> +   connected = true;
> +   } else if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED) {
> +   connected = true;
> }
>
> -   if (drm_probe_ddc(vc4_hdmi->ddc))
> -   return connector_status_connected;
> +   if (connected) {
> +   if (connector->status != connector_status_connected) {
> +   struct edid *edid = drm_get_edid(connector, 
> vc4_hdmi->ddc);
> +
> +   if (edid) {
> +   cec_s_phys_addr_from_edid(vc4_hdmi->cec_adap, 
> edid);
> +   vc4_hdmi->encoder.hdmi_monitor = 
> drm_detect_hdmi_monitor(edid);
> +   kfree(edid);
> +   }
> +   }
>
> -   if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
> return connector_status_connected;
> +   }
> +
> cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> return connector_status_disconnected;
>  }
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6] drm/bridge: add it6505 driver

[Andrzej Hajda]

Hi Allen,

Sorry for long delay.

W dniu 08.12.2020 o 11:58, allen pisze:
> This adds support for the iTE IT6505.
> This device can convert DPI signal to DP output.
>
> From: Allen Chen 
> Signed-off-by: Jitao Shi 
> Signed-off-by: Pi-Hsun Shih 
> Signed-off-by: Yilun Lin 
> Signed-off-by: Hermes Wu 
> Signed-off-by: Allen Chen 
> ---
>   drivers/gpu/drm/bridge/Kconfig  |7 +
>   drivers/gpu/drm/bridge/Makefile |1 +
>   drivers/gpu/drm/bridge/ite-it6505.c | 3343 +++
>   3 files changed, 3351 insertions(+)
>   create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e4110d6ca7b3c..25d34d7196004 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -74,6 +74,13 @@ config DRM_LONTIUM_LT9611UXC
> HDMI signals
> Please say Y if you have such hardware.
>   
> +config DRM_ITE_IT6505
> + tristate "ITE IT6505 DisplayPort bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + help
> +   ITE IT6505 DisplayPort bridge chip driver.
> +
>   config DRM_LVDS_CODEC
>   tristate "Transparent LVDS encoders and decoders support"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 86e7acc76f8d6..2b2f8f0b5b0fa 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>   obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
>   obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
>   obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
> +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o


Please keep alphabetic order.


>   obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
>   obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> megachips-stdp-ge-b850v3-fw.o
>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
> b/drivers/gpu/drm/bridge/ite-it6505.c
> new file mode 100644
> index 0..5e76719a51a4a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -0,0 +1,3343 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define REG_IC_VER 0x04
> +
> +#define REG_RESET_CTRL 0x05
> +#define VIDEO_RESET BIT(0)
> +#define AUDIO_RESET BIT(1)
> +#define ALL_LOGIC_RESET BIT(2)
> +#define AUX_RESET BIT(3)
> +#define HDCP_RESET BIT(4)
> +
> +#define INT_STATUS_01 0x06
> +#define INT_MASK_01 0x09
> +#define INT_HPD_CHANGE BIT(0)
> +#define INT_RECEIVE_HPD_IRQ BIT(1)
> +#define INT_SCDT_CHANGE BIT(2)
> +#define INT_HDCP_FAIL BIT(3)
> +#define INT_HDCP_DONE BIT(4)
> +
> +#define INT_STATUS_02 0x07
> +#define INT_MASK_02 0x0A
> +#define INT_AUX_CMD_FAIL BIT(0)
> +#define INT_HDCP_KSV_CHECK BIT(1)
> +#define INT_AUDIO_FIFO_ERROR BIT(2)
> +
> +#define INT_STATUS_03 0x08
> +#define INT_MASK_03 0x0B
> +#define INT_LINK_TRAIN_FAIL BIT(4)
> +#define INT_VID_FIFO_ERROR BIT(5)
> +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7)
> +
> +#define REG_SYSTEM_STS 0x0D
> +#define INT_STS BIT(0)
> +#define HPD_STS BIT(1)
> +#define VIDEO_STB BIT(2)
> +
> +#define REG_LINK_TRAIN_STS 0x0E
> +#define LINK_STATE_CR BIT(2)
> +#define LINK_STATE_EQ BIT(3)
> +#define LINK_STATE_NORP BIT(4)
> +
> +#define REG_BANK_SEL 0x0F
> +#define REG_CLK_CTRL0 0x10
> +#define M_PCLK_DELAY 0x03
> +
> +#define REG_AUX_OPT 0x11
> +#define AUX_AUTO_RST BIT(0)
> +#define AUX_FIX_FREQ BIT(3)
> +
> +#define REG_DATA_CTRL0 0x12
> +#define VIDEO_LATCH_EDGE BIT(4)
> +#define ENABLE_PCLK_COUNTER BIT(7)
> +
> +#define REG_PCLK_COUNTER_VALUE 0x13
> +
> +#define REG_501_FIFO_CTRL 0x15
> +#define RST_501_FIFO BIT(1)
> +
> +#define REG_TRAIN_CTRL0 0x16
> +#define FORCE_LBR BIT(0)
> +#define LANE_COUNT_MASK 0x06
> +#define LANE_SWAP BIT(3)
> +#define SPREAD_AMP_5 BIT(4)
> +#define FORCE_CR_DONE BIT(5)
> +#define FORCE_EQ_DONE BIT(6)
> +
> +#define REG_TRAIN_CTRL1 0x17
> +#define AUTO_TRAIN BIT(0)
> +#define MANUAL_TRAIN BIT(1)
> +#define FORCE_RETRAIN BIT(2)
> +
> +#define REG_AUX_CTRL 0x23
> +#define CLR_EDID_FIFO BIT(0)
> +#define AUX_USER_MODE BIT(1)
> +#define AUX_NO_SEGMENT_WR BIT(6)
> +#define AUX_EN_FIFO_READ BIT(7)
> +
> +#define REG_AUX_ADR_0_7 0x24
> +#define REG_AUX_ADR_8_15 0x25
> +#define REG_AUX_ADR_16_19 0x26
> +#define REG_AUX_OUT_DATA0 0x27
> +
> +#define REG_AUX_CMD_REQ 0x2B
> +#define AUX_BUSY BIT(5)
> +
> +#define REG_AUX_DATA_0_7 0x2C
> +#define REG_AUX_DATA_8_15 0x2D
> +#define REG_AUX_DATA_1

Re: [PATCH v4 1/3] drm/uapi: Add USB connector type

[Noralf Trønnes]

Den 22.01.2021 08.54, skrev Thomas Zimmermann:
> Hi
> 
> Am 21.01.21 um 19:07 schrieb Noralf Trønnes:
>>
>>
>> Den 21.01.2021 11.01, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 21.01.21 um 09:27 schrieb Daniel Vetter:
 On Thu, Jan 21, 2021 at 8:45 AM Thomas Zimmermann
  wrote:
>
> Hi Noralf,
>
> glad to hear from you! Welcome back!
>>
>> Thanks Thomas!
>>
>
> Am 20.01.21 um 18:42 schrieb Daniel Vetter:
>> On Wed, Jan 20, 2021 at 6:10 PM Noralf Trønnes 
>> wrote:
>>>
>>> Add a connector type for USB connected display panels.
>>>
>>> Signed-off-by: Noralf Trønnes 
>>> ---
>>
>> I have forgotten to update drm_connector_enum_list which maps type to
>> name.
>>
>>>     include/uapi/drm/drm_mode.h | 1 +
>>>     1 file changed, 1 insertion(+)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h
>>> b/include/uapi/drm/drm_mode.h
>>> index fed66a03c7ae..33024cc5d26e 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -367,6 +367,7 @@ enum drm_mode_subconnector {
>>>     #define DRM_MODE_CONNECTOR_DPI 17
>>>     #define DRM_MODE_CONNECTOR_WRITEBACK   18
>>>     #define DRM_MODE_CONNECTOR_SPI 19
>>> +#define DRM_MODE_CONNECTOR_USB 20
>
> I would not call it USB. I could imagine that at some point a generic
> USB protocol could serve simple displays (i.e. in the sense of USB HID
> or data or imaging). (Maybe Thunderbold already counts.) Anyway, USB
> should be reserved for this case.

 We end up calling those DisplayPort, since that's what's being
 transported over thunderbolt or usb-C. So the usb connector would be
 called usb-C. I think the reason we don't do fancy connector names is
 that adding them is a bit a pain. Plus drm/i915 specifically has some
 very quirky connector enumerating that doesn't match much with reality
 unfortunately anyway :-/
>>>
>>> In the case of the other USB drivers, IIRC we use the connector type
>>> that is at the output (i.e., HDMI in the case of udl). I think we should
>>> do the same here. Or use 'Unknown'.
>>>
>>
>> There are 2 DRM USB drivers and they use:
>> - udl: DRM_MODE_CONNECTOR_DVII
> 
> Mine has plain old VGA.

Ok, maybe the Displaylink protocol doesn't provide info about the
connector type or if it does the driver doesn't know about it.

> Maybe we should change generally this to Unknown.
> 
>> - gm12u320: DRM_MODE_CONNECTOR_VGA
>>
>> gm12u320 is a mini projector so it doesn't actually have a VGA
>> connector. I have never seen a udl device but I assume it has a DVII
>> connector?
>>
>> For display adapters it makes sense to use the connector on the adapter
>> as the reported connector, but for display panels that don't have any
>> connector except for the cable that is connected to the hosts USB
>> connector, why can't it be called a USB connector? That's the connector
>> the user sees.
> 
> It's not the relevant connector for the display output. USB is the bus
> system. (Making your argument in terms of discrete GPUs, the connector
> would always be PCI then.)
> 

Yes strictly speaking USB is the bus and the connectors have other
names: USB (type)-A, USB-C etc., but I don't understand the problem
here. Why does it matter that it is a bus?

And wrt PCI it wouldn't be a PCI connector if the card has some other
connector for the display, but if it was possible to connect a display
directly to the PCI connector, then yes I would call that a PCI connector.

This begs the question: Why does the kernel provide info to userspace
about the connector type?

My take is that it is so the user can know which display is connected to
which port on the computer.

What's your opinion?

>>
>> Ofc as Daniel mentions it's a downside that userspace doesn't know about
>> the connector type, and who knows when it will updated (if I don't do
>> it).
>> Weston will name it: "UNNAMED-%d"
>> Mutter: "Unknown%d-%d"
>> X: "Unknown%d-%d"
>>
>> Sam and Laurent has discussed adding a PANEL connector type instead of
>> adding more connector types for panel connectors. I think that would
>> have been a better choice instead of the SPI connector type that I added
>> in 2019. But I think PANEL was meant for panels connected to an internal
>> connector.
>>
>> Here's my protocol connector types and how it's mapped to DRM:
>>
>> #define GUD_CONNECTOR_TYPE_PANEL    0
>> #define GUD_CONNECTOR_TYPE_VGA    1
>> #define GUD_CONNECTOR_TYPE_COMPOSITE    2
>> #define GUD_CONNECTOR_TYPE_SVIDEO    3
>> #define GUD_CONNECTOR_TYPE_COMPONENT    4
>> #define GUD_CONNECTOR_TYPE_DVI    5
>> #define GUD_CONNECTOR_TYPE_DISPLAYPORT    6
>> #define GUD_CONNECTOR_TYPE_HDMI    7
>>
>> static int gud_gadget_ctrl_get_connector(struct gud_gadget *gdg,
>> unsigned int index,
>>  struct gud_connector_descriptor_req *desc)
>> {
>> ...
>> gconn = &gdg->con

Re: [PATCH v2 06/11] drm: Use state helper instead of plane state pointer in atomic_check

[Ville Syrjälä]

On Thu, Jan 21, 2021 at 05:35:31PM +0100, Maxime Ripard wrote:
> Many drivers reference the plane->state pointer in order to get the
> current plane state in their atomic_check hook, which would be the old
> plane state in the global atomic state since _swap_state hasn't happened
> when atomic_check is run.
> 
> Use the drm_atomic_get_old_plane_state helper to get that state to make
> it more obvious.
> 
> This was made using the coccinelle script below:
> 
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
> 
> static struct drm_plane_helper_funcs helpers = {
>   ...,
>   .atomic_check = func,
>   ...,
> };
> 
> @ replaces_old_state @
> identifier plane_atomic_func.func;
> identifier plane, state, plane_state;
> @@
> 
>  func(struct drm_plane *plane, struct drm_atomic_state *state) {
>   ...
> - struct drm_plane_state *plane_state = plane->state;
> + struct drm_plane_state *plane_state = 
> drm_atomic_get_old_plane_state(state, plane);
>   ...
>  }
> 
> @@
> identifier plane_atomic_func.func;
> identifier plane, state, plane_state;
> @@
> 
>  func(struct drm_plane *plane, struct drm_atomic_state *state) {
>   struct drm_plane_state *plane_state = 
> drm_atomic_get_old_plane_state(state, plane);
>   ...
> - plane->state
> + plane_state
>   ...

We don't need the <... ...> style here? It's been a while since
I did any serious cocci so I'm getting a bit rusty on the details...

Otherwise looks great
Reviewed-by: Ville Syrjälä 

>  }
> 
> @ adds_old_state @
> identifier plane_atomic_func.func;
> identifier plane, state;
> @@
> 
>  func(struct drm_plane *plane, struct drm_atomic_state *state) {
> + struct drm_plane_state *old_plane_state = 
> drm_atomic_get_old_plane_state(state, plane);
>   ...
> - plane->state
> + old_plane_state
>   ...
>  }
> 
> @ include depends on adds_old_state || replaces_old_state @
> @@
> 
>  #include 
> 
> @ no_include depends on !include && (adds_old_state || replaces_old_state) @
> @@
> 
> + #include 
>   #include 
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/imx/ipuv3-plane.c  | 3 ++-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 +++-
>  drivers/gpu/drm/tilcdc/tilcdc_plane.c  | 3 ++-
>  3 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index b5f6123850bb..6484592e3f86 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -341,7 +341,8 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
>  {
>   struct drm_plane_state *new_state = 
> drm_atomic_get_new_plane_state(state,
>  
> plane);
> - struct drm_plane_state *old_state = plane->state;
> + struct drm_plane_state *old_state = 
> drm_atomic_get_old_plane_state(state,
> +
> plane);
>   struct drm_crtc_state *crtc_state;
>   struct device *dev = plane->dev->dev;
>   struct drm_framebuffer *fb = new_state->fb;
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> index 4aac6217a5ad..6ce6ce09fecc 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> @@ -406,12 +406,14 @@ static int mdp5_plane_atomic_check_with_state(struct 
> drm_crtc_state *crtc_state,
>  static int mdp5_plane_atomic_check(struct drm_plane *plane,
>  struct drm_atomic_state *state)
>  {
> + struct drm_plane_state *old_plane_state = 
> drm_atomic_get_old_plane_state(state,
> + 
>  plane);
>   struct drm_plane_state *new_plane_state = 
> drm_atomic_get_new_plane_state(state,
>   
>  plane);
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
>  
> - crtc = new_plane_state->crtc ? new_plane_state->crtc : 
> plane->state->crtc;
> + crtc = new_plane_state->crtc ? new_plane_state->crtc : 
> old_plane_state->crtc;
>   if (!crtc)
>   return 0;
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> index ebdd42dcaf82..c86258132432 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> @@ -26,7 +26,8 @@ static int tilcdc_plane_atomic_check(struct drm_plane 
> *plane,
>   struct drm_plane_state *new_state = 
> drm_atomic_get_new_plane_state(state,
>  
> plane);
>   struct drm_crtc_state *crtc_state;
> - struct drm_plane_state *old_state = plane->state;
> + struct drm_plane_state *old_state = 
> drm_atomic_get_old_plane_state(state,
> + 

Re: [PATCH v2 08/11] drm: Rename plane->state variables in atomic update and disable

[Ville Syrjälä]

On Thu, Jan 21, 2021 at 05:35:33PM +0100, Maxime Ripard wrote:
> Some drivers are storing the plane->state pointer in atomic_update and
> atomic_disable in a variable simply called state, while the state passed
> as an argument is called old_state.
> 
> In order to ease subsequent reworks and to avoid confusing or
> inconsistent names, let's rename those variables to new_state.
> 
> This was done using the following coccinelle script, plus some manual
> changes for mtk and tegra.
> 
> @ plane_atomic_func @
> identifier helpers;
> identifier func;
> @@
> 
> (
>  static const struct drm_plane_helper_funcs helpers = {
>   ...,
>   .atomic_disable = func,
>   ...,
>  };
> |
>  static const struct drm_plane_helper_funcs helpers = {
>   ...,
>   .atomic_update = func,
>   ...,
>  };
> )
> 
> @ moves_new_state_old_state @
> identifier plane_atomic_func.func;
> identifier plane;
> symbol old_state;
> symbol state;
> @@
> 
>  func(struct drm_plane *plane, struct drm_plane_state *old_state)
>  {
>   ...
> - struct drm_plane_state *state = plane->state;
> + struct drm_plane_state *new_state = plane->state;
>   ...
>  }
> 
> @ depends on moves_new_state_old_state @
> identifier plane_atomic_func.func;
> identifier plane;
> identifier old_state;
> symbol state;
> @@
> 
>  func(struct drm_plane *plane, struct drm_plane_state *old_state)
>  {
>   <...
> - state
> + new_state
>   ...>

Was going to say that this migh eat something else, but I guess
the dependency prevents that?

Another way to avoid that I suppose would be to declare 'state'
as
symbol moves_new_state_old_state.state;

That would probably make the intent a bit more obvious, even with
the dependency. Or does a dependency somehow automagically imply
that?

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/virtio: trace total gem bo for virtio

[Yiwei Zhang]

From: Yiwei Zhang 

On the success of virtio_gpu_object_create, add size of newly allocated
bo to the tracked total_mem. In drm_gem_object_funcs.free, after the gem
bo lost its last refcount, subtract the bo size from the tracked
total_mem if the original underlying memory allocation is successful.

It's more accurate to do this in device driver layer to best match when
the underlying resource gets allocated and destroyed during tracing.

Signed-off-by: Yiwei Zhang 
---
 drivers/gpu/drm/virtio/Kconfig  |  1 +
 drivers/gpu/drm/virtio/virtgpu_drv.h|  2 ++
 drivers/gpu/drm/virtio/virtgpu_object.c | 11 +++
 3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index b925b8b1da16..e103b7e883b1 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
select VIRTIO_DMA_SHARED_BUFFER
+   select TRACE_GPU_MEM
help
   This is the virtual GPU driver for virtio.  It can be used with
   QEMU based VMMs (like KVM or Xen).
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 6a232553c99b..7ab63ce9c6a9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -249,6 +249,8 @@ struct virtio_gpu_device {
spinlock_t resource_export_lock;
/* protects map state and host_visible_mm */
spinlock_t host_visible_lock;
+   /* total memory backing gem bos */
+   atomic64_t total_mem;
 };
 
 struct virtio_gpu_fpriv {
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index d69a5b6da553..e2251fc41509 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -25,12 +25,21 @@
 
 #include 
 #include 
+#include 
 
 #include "virtgpu_drv.h"
 
 static int virtio_gpu_virglrenderer_workaround = 1;
 module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int, 0400);
 
+static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device *vgdev,
+ s64 delta)
+{
+   u64 total_mem = atomic64_add_return(delta, &vgdev->total_mem);
+
+   trace_gpu_mem_total(vgdev->ddev->primary->index, 0, total_mem);
+}
+
 int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t 
*resid)
 {
if (virtio_gpu_virglrenderer_workaround) {
@@ -104,6 +113,7 @@ static void virtio_gpu_free_object(struct drm_gem_object 
*obj)
struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
 
if (bo->created) {
+   virtio_gpu_trace_total_mem(vgdev, -(obj->size));
virtio_gpu_cmd_unref_resource(vgdev, bo);
virtio_gpu_notify(vgdev);
/* completion handler calls virtio_gpu_cleanup_object() */
@@ -265,6 +275,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
virtio_gpu_object_attach(vgdev, bo, ents, nents);
}
 
+   virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
*bo_ptr = bo;
return 0;
 
-- 
2.30.0.280.ga3ce27912f-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/virtio: Track total GPU memory for virtio driver

[Yiwei Zhang‎]

On Thu, Jan 21, 2021 at 9:40 PM Yiwei Zhang  wrote:
>
> On the success of virtio_gpu_object_create, add size of newly allocated
> bo to the tracked total_mem. In drm_gem_object_funcs.free, after the gem
> bo loses its last refcount, subtract the bo size from the tracked
> total_mem if the original underlying memory allocation is successful.
>
> It's more accurate to do this in device driver layer to best match when
> the underlying resource gets allocated and destroyed during tracing.
>
> Signed-off-by: Yiwei Zhang 
> ---
>  drivers/gpu/drm/virtio/Kconfig  |  1 +
>  drivers/gpu/drm/virtio/virtgpu_drv.h|  2 ++
>  drivers/gpu/drm/virtio/virtgpu_object.c | 11 +++
>  3 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> index b925b8b1da16..e103b7e883b1 100644
> --- a/drivers/gpu/drm/virtio/Kconfig
> +++ b/drivers/gpu/drm/virtio/Kconfig
> @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> select DRM_KMS_HELPER
> select DRM_GEM_SHMEM_HELPER
> select VIRTIO_DMA_SHARED_BUFFER
> +   select TRACE_GPU_MEM
> help
>This is the virtual GPU driver for virtio.  It can be used with
>QEMU based VMMs (like KVM or Xen).
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 6a232553c99b..c5622f9b591f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -249,6 +249,8 @@ struct virtio_gpu_device {
> spinlock_t resource_export_lock;
> /* protects map state and host_visible_mm */
> spinlock_t host_visible_lock;
> +
> +   atomic64_t total_mem;
>  };
>
>  struct virtio_gpu_fpriv {
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index d69a5b6da553..e2251fc41509 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -25,12 +25,21 @@
>
>  #include 
>  #include 
> +#include 
>
>  #include "virtgpu_drv.h"
>
>  static int virtio_gpu_virglrenderer_workaround = 1;
>  module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int, 
> 0400);
>
> +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device 
> *vgdev,
> + s64 delta)
> +{
> +   u64 total_mem = atomic64_add_return(delta, &vgdev->total_mem);
> +
> +   trace_gpu_mem_total(vgdev->ddev->primary->index, 0, total_mem);
> +}
> +
>  int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t 
> *resid)
>  {
> if (virtio_gpu_virglrenderer_workaround) {
> @@ -104,6 +113,7 @@ static void virtio_gpu_free_object(struct drm_gem_object 
> *obj)
> struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
>
> if (bo->created) {
> +   virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> virtio_gpu_cmd_unref_resource(vgdev, bo);
> virtio_gpu_notify(vgdev);
> /* completion handler calls virtio_gpu_cleanup_object() */
> @@ -265,6 +275,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
> *vgdev,
> virtio_gpu_object_attach(vgdev, bo, ents, nents);
> }
>
> +   virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> *bo_ptr = bo;
> return 0;
>
> --
> 2.30.0.280.ga3ce27912f-goog
>

Re Gerd and Daniel:

I'm not sure why we want to couple this patch too much with the
dma-bufs tracking. The tracepoint added here itself is pretty useful
for tracking gem bo total usage in virtio gpu upon tracing. The
original purpose for integrating this tracepoint in all Android gpu
kernel drivers is to just track total gpu memory usage and serve the
accurate data to game developers in a much easier way. It's something
they can rely on for robust testing and regression monitoring.

The only overlap with the dma-buf side is when we export a bo via
prime to a dma-buf. But still, the total here is already useful for
this particular device. Using which approach to account for the
overlap wouldn't block this small integration from my understanding.

Besides, there's no plan for adding per-process gem total tracking in
virtio-gpu at this moment. This patch should be light enough to carry
without worrying about tech debt I believe.

Many thanks!
Yiwei
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/virtio: Track total GPU memory for virtio driver

[Yiwei Zhang]

On the success of virtio_gpu_object_create, add size of newly allocated
bo to the tracked total_mem. In drm_gem_object_funcs.free, after the gem
bo loses its last refcount, subtract the bo size from the tracked
total_mem if the original underlying memory allocation is successful.

It's more accurate to do this in device driver layer to best match when
the underlying resource gets allocated and destroyed during tracing.

Signed-off-by: Yiwei Zhang 
---
 drivers/gpu/drm/virtio/Kconfig  |  1 +
 drivers/gpu/drm/virtio/virtgpu_drv.h|  2 ++
 drivers/gpu/drm/virtio/virtgpu_object.c | 11 +++
 3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index b925b8b1da16..e103b7e883b1 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
select VIRTIO_DMA_SHARED_BUFFER
+   select TRACE_GPU_MEM
help
   This is the virtual GPU driver for virtio.  It can be used with
   QEMU based VMMs (like KVM or Xen).
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 6a232553c99b..c5622f9b591f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -249,6 +249,8 @@ struct virtio_gpu_device {
spinlock_t resource_export_lock;
/* protects map state and host_visible_mm */
spinlock_t host_visible_lock;
+
+   atomic64_t total_mem;
 };
 
 struct virtio_gpu_fpriv {
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index d69a5b6da553..e2251fc41509 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -25,12 +25,21 @@
 
 #include 
 #include 
+#include 
 
 #include "virtgpu_drv.h"
 
 static int virtio_gpu_virglrenderer_workaround = 1;
 module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int, 0400);
 
+static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device *vgdev,
+ s64 delta)
+{
+   u64 total_mem = atomic64_add_return(delta, &vgdev->total_mem);
+
+   trace_gpu_mem_total(vgdev->ddev->primary->index, 0, total_mem);
+}
+
 int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t 
*resid)
 {
if (virtio_gpu_virglrenderer_workaround) {
@@ -104,6 +113,7 @@ static void virtio_gpu_free_object(struct drm_gem_object 
*obj)
struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
 
if (bo->created) {
+   virtio_gpu_trace_total_mem(vgdev, -(obj->size));
virtio_gpu_cmd_unref_resource(vgdev, bo);
virtio_gpu_notify(vgdev);
/* completion handler calls virtio_gpu_cleanup_object() */
@@ -265,6 +275,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
virtio_gpu_object_attach(vgdev, bo, ents, nents);
}
 
+   virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
*bo_ptr = bo;
return 0;
 
-- 
2.30.0.280.ga3ce27912f-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] drm/uapi: Add USB connector type

[Thomas Zimmermann]

Hi

Am 22.01.21 um 12:44 schrieb Noralf Trønnes:


And wrt PCI it wouldn't be a PCI connector if the card has some other
connector for the display, but if it was possible to connect a display
directly to the PCI connector, then yes I would call that a PCI connector.


You're not connecting a display to the computer. You're connecting an 
RPi and then connect the display to the RPi. The RPi acts like an 
external graphics card.



This begs the question: Why does the kernel provide info to userspace
about the connector type?

My take is that it is so the user can know which display is connected to
which port on the computer.


This exactly illustrates the problem with the current naming. For a 
single output the distinction between bus and connector might be fuzzy. 
As soon as a connected SoC contains multiple connectors. The user then 
sees names such as card1-USB-0 and card1-USB-1, which makes no sense.




What's your opinion?



Ofc as Daniel mentions it's a downside that userspace doesn't know about
the connector type, and who knows when it will updated (if I don't do
it).
Weston will name it: "UNNAMED-%d"
Mutter: "Unknown%d-%d"
X: "Unknown%d-%d"

Sam and Laurent has discussed adding a PANEL connector type instead of
adding more connector types for panel connectors. I think that would
have been a better choice instead of the SPI connector type that I added
in 2019. But I think PANEL was meant for panels connected to an internal
connector.

Here's my protocol connector types and how it's mapped to DRM:

#define GUD_CONNECTOR_TYPE_PANEL    0
#define GUD_CONNECTOR_TYPE_VGA    1
#define GUD_CONNECTOR_TYPE_COMPOSITE    2
#define GUD_CONNECTOR_TYPE_SVIDEO    3
#define GUD_CONNECTOR_TYPE_COMPONENT    4
#define GUD_CONNECTOR_TYPE_DVI    5
#define GUD_CONNECTOR_TYPE_DISPLAYPORT    6
#define GUD_CONNECTOR_TYPE_HDMI    7

static int gud_gadget_ctrl_get_connector(struct gud_gadget *gdg,
unsigned int index,
  struct gud_connector_descriptor_req *desc)
{
...
 gconn = &gdg->connectors[index];

 switch (gconn->connector->connector_type) {
 case DRM_MODE_CONNECTOR_VGA:
     desc->connector_type = GUD_CONNECTOR_TYPE_VGA;
     break;
 case DRM_MODE_CONNECTOR_DVII:
     fallthrough;
 case DRM_MODE_CONNECTOR_DVID:
     fallthrough;
 case DRM_MODE_CONNECTOR_DVIA:
     desc->connector_type = GUD_CONNECTOR_TYPE_DVI;
     break;
 case DRM_MODE_CONNECTOR_Composite:
     desc->connector_type = GUD_CONNECTOR_TYPE_COMPOSITE;
     break;
 case DRM_MODE_CONNECTOR_SVIDEO:
     desc->connector_type = GUD_CONNECTOR_TYPE_SVIDEO;
     break;
 case DRM_MODE_CONNECTOR_Component:
     desc->connector_type = GUD_CONNECTOR_TYPE_COMPONENT;
     break;
 case DRM_MODE_CONNECTOR_DisplayPort:
     desc->connector_type = GUD_CONNECTOR_TYPE_DISPLAYPORT;
     break;
 case DRM_MODE_CONNECTOR_HDMIA:
     fallthrough;
 case DRM_MODE_CONNECTOR_HDMIB:
     desc->connector_type = GUD_CONNECTOR_TYPE_HDMI;
     break;
 default:
     desc->connector_type = GUD_CONNECTOR_TYPE_PANEL;
     break;
 };


int gud_connector_create(struct gud_device *gdrm, unsigned int index)
{
...
 switch (desc.connector_type) {
 case GUD_CONNECTOR_TYPE_PANEL:
     connector_type = DRM_MODE_CONNECTOR_USB;
     break;
 case GUD_CONNECTOR_TYPE_VGA:
     connector_type = DRM_MODE_CONNECTOR_VGA;
     break;
 case GUD_CONNECTOR_TYPE_DVI:
     connector_type = DRM_MODE_CONNECTOR_DVID;
     break;
 case GUD_CONNECTOR_TYPE_COMPOSITE:
     connector_type = DRM_MODE_CONNECTOR_Composite;
     break;
 case GUD_CONNECTOR_TYPE_SVIDEO:
     connector_type = DRM_MODE_CONNECTOR_SVIDEO;
     break;
 case GUD_CONNECTOR_TYPE_COMPONENT:
     connector_type = DRM_MODE_CONNECTOR_Component;
     break;
 case GUD_CONNECTOR_TYPE_DISPLAYPORT:
     connector_type = DRM_MODE_CONNECTOR_DisplayPort;
     break;
 case GUD_CONNECTOR_TYPE_HDMI:
     connector_type = DRM_MODE_CONNECTOR_HDMIA;
     break;
 default: /* future types */
     connector_type = DRM_MODE_CONNECTOR_USB;


The more I look at it the more I think it should be 'Unknown' here.



I don't understand this, how will that be better for the user?


As I said before, the display is not connected via USB. The RPi (i.e., 
graphics card) is. The naming would be off.


Best regards
Thomas




BTW, can I try this out somehow? I do have an RPi3. Do I need a special
disk image?


The Pi3 doesn'have a USB device/otg connector so I haven't made an image
for that one. Only the Pi Zero, model A and Pi 4 have that.

The Pi2 and Pi3 have a USB hub on the soc's single USB port.

Noralf.



Best regards
Thomas


     break;
 };

Noralf.


Best regards
Thomas


-Daniel



Best regards
Thomas



Beware, new connector types have in the past resulted in userspace
b

Re: [PATCH v2 09/15] drm/vc4: hdmi: Split the interrupt handlers

[Dave Stevenson]

Hi Maxime

On Mon, 11 Jan 2021 at 14:23, Maxime Ripard  wrote:
>
> The BCM2711 has two different interrupt sources to transmit and receive
> CEC messages, provided through an external interrupt chip shared between
> the two HDMI interrupt controllers.
>
> The rest of the CEC controller is identical though so we need to change
> a bit the code organisation to share the code as much as possible, yet
> still allowing to register independant handlers.

s/independant/independent

>
> Signed-off-by: Maxime Ripard 

With that
Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 86 +-
>  1 file changed, 65 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 7b5c92df8f1b..12ca5f3084af 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1454,15 +1454,22 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi 
> *vc4_hdmi)
>  }
>
>  #ifdef CONFIG_DRM_VC4_HDMI_CEC
> -static irqreturn_t vc4_cec_irq_handler_thread(int irq, void *priv)
> +static irqreturn_t vc4_cec_irq_handler_rx_thread(int irq, void *priv)
>  {
> struct vc4_hdmi *vc4_hdmi = priv;
>
> -   if (vc4_hdmi->cec_irq_was_rx) {
> -   if (vc4_hdmi->cec_rx_msg.len)
> -   cec_received_msg(vc4_hdmi->cec_adap,
> -&vc4_hdmi->cec_rx_msg);
> -   } else if (vc4_hdmi->cec_tx_ok) {
> +   if (vc4_hdmi->cec_rx_msg.len)
> +   cec_received_msg(vc4_hdmi->cec_adap,
> +&vc4_hdmi->cec_rx_msg);
> +
> +   return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t vc4_cec_irq_handler_tx_thread(int irq, void *priv)
> +{
> +   struct vc4_hdmi *vc4_hdmi = priv;
> +
> +   if (vc4_hdmi->cec_tx_ok) {
> cec_transmit_done(vc4_hdmi->cec_adap, CEC_TX_STATUS_OK,
>   0, 0, 0, 0);
> } else {
> @@ -1476,6 +1483,19 @@ static irqreturn_t vc4_cec_irq_handler_thread(int irq, 
> void *priv)
> return IRQ_HANDLED;
>  }
>
> +static irqreturn_t vc4_cec_irq_handler_thread(int irq, void *priv)
> +{
> +   struct vc4_hdmi *vc4_hdmi = priv;
> +   irqreturn_t ret;
> +
> +   if (vc4_hdmi->cec_irq_was_rx)
> +   ret = vc4_cec_irq_handler_rx_thread(irq, priv);
> +   else
> +   ret = vc4_cec_irq_handler_tx_thread(irq, priv);
> +
> +   return ret;
> +}
> +
>  static void vc4_cec_read_msg(struct vc4_hdmi *vc4_hdmi, u32 cntrl1)
>  {
> struct drm_device *dev = vc4_hdmi->connector.dev;
> @@ -1500,31 +1520,55 @@ static void vc4_cec_read_msg(struct vc4_hdmi 
> *vc4_hdmi, u32 cntrl1)
> }
>  }
>
> +static irqreturn_t vc4_cec_irq_handler_tx_bare(int irq, void *priv)
> +{
> +   struct vc4_hdmi *vc4_hdmi = priv;
> +   u32 cntrl1;
> +
> +   cntrl1 = HDMI_READ(HDMI_CEC_CNTRL_1);
> +   vc4_hdmi->cec_tx_ok = cntrl1 & VC4_HDMI_CEC_TX_STATUS_GOOD;
> +   cntrl1 &= ~VC4_HDMI_CEC_START_XMIT_BEGIN;
> +   HDMI_WRITE(HDMI_CEC_CNTRL_1, cntrl1);
> +
> +   return IRQ_WAKE_THREAD;
> +}
> +
> +static irqreturn_t vc4_cec_irq_handler_rx_bare(int irq, void *priv)
> +{
> +   struct vc4_hdmi *vc4_hdmi = priv;
> +   u32 cntrl1;
> +
> +   vc4_hdmi->cec_rx_msg.len = 0;
> +   cntrl1 = HDMI_READ(HDMI_CEC_CNTRL_1);
> +   vc4_cec_read_msg(vc4_hdmi, cntrl1);
> +   cntrl1 |= VC4_HDMI_CEC_CLEAR_RECEIVE_OFF;
> +   HDMI_WRITE(HDMI_CEC_CNTRL_1, cntrl1);
> +   cntrl1 &= ~VC4_HDMI_CEC_CLEAR_RECEIVE_OFF;
> +
> +   HDMI_WRITE(HDMI_CEC_CNTRL_1, cntrl1);
> +
> +   return IRQ_WAKE_THREAD;
> +}
> +
>  static irqreturn_t vc4_cec_irq_handler(int irq, void *priv)
>  {
> struct vc4_hdmi *vc4_hdmi = priv;
> u32 stat = HDMI_READ(HDMI_CEC_CPU_STATUS);
> -   u32 cntrl1, cntrl5;
> +   irqreturn_t ret;
> +   u32 cntrl5;
>
> if (!(stat & VC4_HDMI_CPU_CEC))
> return IRQ_NONE;
> -   vc4_hdmi->cec_rx_msg.len = 0;
> -   cntrl1 = HDMI_READ(HDMI_CEC_CNTRL_1);
> +
> cntrl5 = HDMI_READ(HDMI_CEC_CNTRL_5);
> vc4_hdmi->cec_irq_was_rx = cntrl5 & VC4_HDMI_CEC_RX_CEC_INT;
> -   if (vc4_hdmi->cec_irq_was_rx) {
> -   vc4_cec_read_msg(vc4_hdmi, cntrl1);
> -   cntrl1 |= VC4_HDMI_CEC_CLEAR_RECEIVE_OFF;
> -   HDMI_WRITE(HDMI_CEC_CNTRL_1, cntrl1);
> -   cntrl1 &= ~VC4_HDMI_CEC_CLEAR_RECEIVE_OFF;
> -   } else {
> -   vc4_hdmi->cec_tx_ok = cntrl1 & VC4_HDMI_CEC_TX_STATUS_GOOD;
> -   cntrl1 &= ~VC4_HDMI_CEC_START_XMIT_BEGIN;
> -   }
> -   HDMI_WRITE(HDMI_CEC_CNTRL_1, cntrl1);
> +   if (vc4_hdmi->cec_irq_was_rx)
> +   ret = vc4_cec_irq_handler_rx_bare(irq, priv);
> +   else
> +   ret = vc4_cec_irq_handler_tx_bare(irq, priv);
> +
> HDMI_WRITE(HDMI_CEC_CPU_CLEAR, VC4_HDMI_CPU_CEC);
> -
> -   return IRQ_WAKE_THREAD;
> +   retu

Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications

[Christian König]

Am 21.01.21 um 20:40 schrieb Daniel Vetter:

Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.

While the discussion is still fresh I figured good time to try and
document the conclusions a bit.

References: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210107030127.20393-1-Felix.Kuehling%40amd.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C94782d99ad7d4e1cc57c08d8be447d74%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637468548672516391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AT8QP2r2UczSqCKkPRTJI1cQ0GOGyykgLcMfW8NbD8w%3D&reserved=0
Cc: Maarten Lankhorst 
Cc: Thomas Hellström 
Cc: "Christian König" 
Cc: Jerome Glisse 
Cc: Felix Kuehling 
Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
--
I'll be away next week, but figured I'll type this up quickly for some
comments and to check whether I got this all roughly right.

Critique very much wanted on this, so that we can make sure hw which
can't preempt (with pagefaults pending) like gfx10 has a clear path to
support page faults in upstream. So anything I missed, got wrong or
like that would be good.
-Daniel
---
  Documentation/driver-api/dma-buf.rst | 66 
  1 file changed, 66 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index a2133d69872c..e924c1e4f7a3 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -257,3 +257,69 @@ fences in the kernel. This means:
userspace is allowed to use userspace fencing or long running compute
workloads. This also means no implicit fencing for shared buffers in these
cases.
+
+Recoverable Hardware Page Faults Implications
+~
+
+Modern hardware supports recoverable page faults, which has a lot of
+implications for DMA fences.
+
+First, a pending page fault obviously holds up the work that's running on the
+accelerator and a memory allocation is usually required to resolve the fault.
+But memory allocations are not allowed to gate completion of DMA fences, which
+means any workload using recoverable page faults cannot use DMA fences for
+synchronization. Synchronization fences controlled by userspace must be used
+instead.
+
+On GPUs this poses a problem, because current desktop compositor protocols on
+Linus rely on DMA fences, which means without an entirely new userspace stack
+built on top of userspace fences, they cannot benefit from recoverable page
+faults. The exception is when page faults are only used as migration hints and
+never to on-demand fill a memory request. For now this means recoverable page
+faults on GPUs are limited to pure compute workloads.
+
+Furthermore GPUs usually have shared resources between the 3D rendering and
+compute side, like compute units or command submission engines. If both a 3D
+job with a DMA fence and a compute workload using recoverable page faults are
+pending they could deadlock:
+
+- The 3D workload might need to wait for the compute job to finish and release
+  hardware resources first.
+
+- The compute workload might be stuck in a page fault, because the memory
+  allocation is waiting for the DMA fence of the 3D workload to complete.
+
+There are a few ways to prevent this problem:
+
+- Compute workloads can always be preempted, even when a page fault is pending
+  and not yet repaired. Not all hardware supports this.
+
+- DMA fence workloads and workloads which need page fault handling have
+  independent hardware resources to guarantee forward progress. This could be
+  achieved through e.g. through dedicated engines and minimal compute unit
+  reservations for DMA fence workloads.
+



+- The reservation approach could be further refined by only reserving the
+  hardware resources for DMA fence workloads when they are in-flight. This must
+  cover the time from when the DMA fence is visible to other threads up to
+  moment when fence is completed through dma_fence_signal().


Up till here it makes perfect sense, but what should this paragraph mean ?


+
+- As a last resort, if the hardware provides no useful reservation mechanics,
+  all workloads must be flushed from the GPU when switching between jobs
+  requiring DMA fences or jobs requiring page fault handling: This means all 
DMA
+  fences must complete before a compute job with page fault handling can be
+  inserted into the scheduler queue. And vice versa, before a DMA fence can be
+  made visible anywhere in the system, all compute workloads must be preempted
+  to guarantee all pending GPU page faults are flushed.
+
+Note that workloads that run on independent hardware like copy engines or other
+GPUs do not have any impact. This allows us to keep using DMA fences internally

Re: [PATCH v2 10/15] drm/vc4: hdmi: Support BCM2711 CEC interrupt setup

[Dave Stevenson]

Hi Maxime

On Mon, 11 Jan 2021 at 14:23, Maxime Ripard  wrote:
>
> The HDMI controller found in the BCM2711 has an external interrupt
> controller for the CEC and hotplug interrupt shared between the two
> instances.
>
> Let's add a variant flag to register a single interrupt handler and
> deals with the interrupt handler setup, or two interrupt handlers
> relying on an external irqchip.
>
> Signed-off-by: Maxime Ripard 

Looks good

Reviewed-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 42 ++
>  drivers/gpu/drm/vc4/vc4_hdmi.h |  7 ++
>  2 files changed, 39 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 12ca5f3084af..d116ecfd8cf7 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1605,9 +1605,11 @@ static int vc4_hdmi_cec_adap_enable(struct cec_adapter 
> *adap, bool enable)
>((3600 / usecs) << 
> VC4_HDMI_CEC_CNT_TO_3600_US_SHIFT) |
>((3500 / usecs) << 
> VC4_HDMI_CEC_CNT_TO_3500_US_SHIFT));
>
> -   HDMI_WRITE(HDMI_CEC_CPU_MASK_CLEAR, VC4_HDMI_CPU_CEC);
> +   if (!vc4_hdmi->variant->external_irq_controller)
> +   HDMI_WRITE(HDMI_CEC_CPU_MASK_CLEAR, VC4_HDMI_CPU_CEC);
> } else {
> -   HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, VC4_HDMI_CPU_CEC);
> +   if (!vc4_hdmi->variant->external_irq_controller)
> +   HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, VC4_HDMI_CPU_CEC);
> HDMI_WRITE(HDMI_CEC_CNTRL_5, val |
>VC4_HDMI_CEC_TX_SW_RESET | 
> VC4_HDMI_CEC_RX_SW_RESET);
> }
> @@ -1682,8 +1684,6 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> cec_fill_conn_info_from_drm(&conn_info, &vc4_hdmi->connector);
> cec_s_conn_info(vc4_hdmi->cec_adap, &conn_info);
>
> -   HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, 0x);
> -
> value = HDMI_READ(HDMI_CEC_CNTRL_1);
> /* Set the logical address to Unregistered */
> value |= VC4_HDMI_CEC_ADDR_MASK;
> @@ -1691,12 +1691,32 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi 
> *vc4_hdmi)
>
> vc4_hdmi_cec_update_clk_div(vc4_hdmi);
>
> -   ret = devm_request_threaded_irq(&pdev->dev, platform_get_irq(pdev, 0),
> -   vc4_cec_irq_handler,
> -   vc4_cec_irq_handler_thread, 0,
> -   "vc4 hdmi cec", vc4_hdmi);
> -   if (ret)
> -   goto err_delete_cec_adap;
> +   if (vc4_hdmi->variant->external_irq_controller) {
> +   ret = devm_request_threaded_irq(&pdev->dev,
> +   platform_get_irq_byname(pdev, 
> "cec-rx"),
> +   vc4_cec_irq_handler_rx_bare,
> +   
> vc4_cec_irq_handler_rx_thread, 0,
> +   "vc4 hdmi cec rx", vc4_hdmi);
> +   if (ret)
> +   goto err_delete_cec_adap;
> +
> +   ret = devm_request_threaded_irq(&pdev->dev,
> +   platform_get_irq_byname(pdev, 
> "cec-tx"),
> +   vc4_cec_irq_handler_tx_bare,
> +   
> vc4_cec_irq_handler_tx_thread, 0,
> +   "vc4 hdmi cec tx", vc4_hdmi);
> +   if (ret)
> +   goto err_delete_cec_adap;
> +   } else {
> +   HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, 0x);
> +
> +   ret = devm_request_threaded_irq(&pdev->dev, 
> platform_get_irq(pdev, 0),
> +   vc4_cec_irq_handler,
> +   vc4_cec_irq_handler_thread, 0,
> +   "vc4 hdmi cec", vc4_hdmi);
> +   if (ret)
> +   goto err_delete_cec_adap;
> +   }
>
> ret = cec_register_adapter(vc4_hdmi->cec_adap, &pdev->dev);
> if (ret < 0)
> @@ -2095,6 +2115,7 @@ static const struct vc4_hdmi_variant 
> bcm2711_hdmi0_variant = {
> PHY_LANE_CK,
> },
> .unsupported_odd_h_timings  = true,
> +   .external_irq_controller= true,
>
> .init_resources = vc5_hdmi_init_resources,
> .csc_setup  = vc5_hdmi_csc_setup,
> @@ -2121,6 +2142,7 @@ static const struct vc4_hdmi_variant 
> bcm2711_hdmi1_variant = {
> PHY_LANE_2,
> },
> .unsupported_odd_h_timings  = true,
> +   .external_irq_controller= true,
>
> .init_resources = vc5_hdmi_init_resources,
> .csc_setup  = vc5_hdmi_csc_setup,
> diff --git a/drivers/gpu/

Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications

[Daniel Vetter]

On Fri, Jan 22, 2021 at 2:10 PM Christian König
 wrote:
>
> Am 21.01.21 um 20:40 schrieb Daniel Vetter:
> > Recently there was a fairly long thread about recoreable hardware page
> > faults, how they can deadlock, and what to do about that.
> >
> > While the discussion is still fresh I figured good time to try and
> > document the conclusions a bit.
> >
> > References: 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210107030127.20393-1-Felix.Kuehling%40amd.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C94782d99ad7d4e1cc57c08d8be447d74%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637468548672516391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AT8QP2r2UczSqCKkPRTJI1cQ0GOGyykgLcMfW8NbD8w%3D&reserved=0
> > Cc: Maarten Lankhorst 
> > Cc: Thomas Hellström 
> > Cc: "Christian König" 
> > Cc: Jerome Glisse 
> > Cc: Felix Kuehling 
> > Signed-off-by: Daniel Vetter 
> > Cc: Sumit Semwal 
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > --
> > I'll be away next week, but figured I'll type this up quickly for some
> > comments and to check whether I got this all roughly right.
> >
> > Critique very much wanted on this, so that we can make sure hw which
> > can't preempt (with pagefaults pending) like gfx10 has a clear path to
> > support page faults in upstream. So anything I missed, got wrong or
> > like that would be good.
> > -Daniel
> > ---
> >   Documentation/driver-api/dma-buf.rst | 66 
> >   1 file changed, 66 insertions(+)
> >
> > diff --git a/Documentation/driver-api/dma-buf.rst 
> > b/Documentation/driver-api/dma-buf.rst
> > index a2133d69872c..e924c1e4f7a3 100644
> > --- a/Documentation/driver-api/dma-buf.rst
> > +++ b/Documentation/driver-api/dma-buf.rst
> > @@ -257,3 +257,69 @@ fences in the kernel. This means:
> > userspace is allowed to use userspace fencing or long running compute
> > workloads. This also means no implicit fencing for shared buffers in 
> > these
> > cases.
> > +
> > +Recoverable Hardware Page Faults Implications
> > +~
> > +
> > +Modern hardware supports recoverable page faults, which has a lot of
> > +implications for DMA fences.
> > +
> > +First, a pending page fault obviously holds up the work that's running on 
> > the
> > +accelerator and a memory allocation is usually required to resolve the 
> > fault.
> > +But memory allocations are not allowed to gate completion of DMA fences, 
> > which
> > +means any workload using recoverable page faults cannot use DMA fences for
> > +synchronization. Synchronization fences controlled by userspace must be 
> > used
> > +instead.
> > +
> > +On GPUs this poses a problem, because current desktop compositor protocols 
> > on
> > +Linus rely on DMA fences, which means without an entirely new userspace 
> > stack
> > +built on top of userspace fences, they cannot benefit from recoverable page
> > +faults. The exception is when page faults are only used as migration hints 
> > and
> > +never to on-demand fill a memory request. For now this means recoverable 
> > page
> > +faults on GPUs are limited to pure compute workloads.
> > +
> > +Furthermore GPUs usually have shared resources between the 3D rendering and
> > +compute side, like compute units or command submission engines. If both a 
> > 3D
> > +job with a DMA fence and a compute workload using recoverable page faults 
> > are
> > +pending they could deadlock:
> > +
> > +- The 3D workload might need to wait for the compute job to finish and 
> > release
> > +  hardware resources first.
> > +
> > +- The compute workload might be stuck in a page fault, because the memory
> > +  allocation is waiting for the DMA fence of the 3D workload to complete.
> > +
> > +There are a few ways to prevent this problem:
> > +
> > +- Compute workloads can always be preempted, even when a page fault is 
> > pending
> > +  and not yet repaired. Not all hardware supports this.
> > +
> > +- DMA fence workloads and workloads which need page fault handling have
> > +  independent hardware resources to guarantee forward progress. This could 
> > be
> > +  achieved through e.g. through dedicated engines and minimal compute unit
> > +  reservations for DMA fence workloads.
> > +
>
> > +- The reservation approach could be further refined by only reserving the
> > +  hardware resources for DMA fence workloads when they are in-flight. This 
> > must
> > +  cover the time from when the DMA fence is visible to other threads up to
> > +  moment when fence is completed through dma_fence_signal().
>
> Up till here it makes perfect sense, but what should this paragraph mean ?

Instead of reserving a few CU at driver load, to guarantee that
dma-fence workloads can always complete, we only do the reservatation
while a problematic dma_fence is in the system, and note yet
signalled. Of course that appro

Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications

[Christian König]

Am 22.01.21 um 14:18 schrieb Daniel Vetter:

On Fri, Jan 22, 2021 at 2:10 PM Christian König
 wrote:

Am 21.01.21 um 20:40 schrieb Daniel Vetter:

Recently there was a fairly long thread about recoreable hardware page
faults, how they can deadlock, and what to do about that.

While the discussion is still fresh I figured good time to try and
document the conclusions a bit.

References: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210107030127.20393-1-Felix.Kuehling%40amd.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C25c2b659bc8f47e0bace08d8bed83728%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637469183153437091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GlEKsPLRRRO%2BI1JSDpvNeBFbnFacmymxkj8e7QqM5SA%3D&reserved=0
Cc: Maarten Lankhorst 
Cc: Thomas Hellström 
Cc: "Christian König" 
Cc: Jerome Glisse 
Cc: Felix Kuehling 
Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
--
I'll be away next week, but figured I'll type this up quickly for some
comments and to check whether I got this all roughly right.

Critique very much wanted on this, so that we can make sure hw which
can't preempt (with pagefaults pending) like gfx10 has a clear path to


One more comment here: You should probably mention that gfx10 is 
referring to AMD GPUs.



support page faults in upstream. So anything I missed, got wrong or
like that would be good.
-Daniel
---
   Documentation/driver-api/dma-buf.rst | 66 
   1 file changed, 66 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index a2133d69872c..e924c1e4f7a3 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -257,3 +257,69 @@ fences in the kernel. This means:
 userspace is allowed to use userspace fencing or long running compute
 workloads. This also means no implicit fencing for shared buffers in these
 cases.
+
+Recoverable Hardware Page Faults Implications
+~
+
+Modern hardware supports recoverable page faults, which has a lot of
+implications for DMA fences.
+
+First, a pending page fault obviously holds up the work that's running on the
+accelerator and a memory allocation is usually required to resolve the fault.
+But memory allocations are not allowed to gate completion of DMA fences, which
+means any workload using recoverable page faults cannot use DMA fences for
+synchronization. Synchronization fences controlled by userspace must be used
+instead.
+
+On GPUs this poses a problem, because current desktop compositor protocols on
+Linus rely on DMA fences, which means without an entirely new userspace stack
+built on top of userspace fences, they cannot benefit from recoverable page
+faults. The exception is when page faults are only used as migration hints and
+never to on-demand fill a memory request. For now this means recoverable page
+faults on GPUs are limited to pure compute workloads.
+
+Furthermore GPUs usually have shared resources between the 3D rendering and
+compute side, like compute units or command submission engines. If both a 3D
+job with a DMA fence and a compute workload using recoverable page faults are
+pending they could deadlock:
+
+- The 3D workload might need to wait for the compute job to finish and release
+  hardware resources first.
+
+- The compute workload might be stuck in a page fault, because the memory
+  allocation is waiting for the DMA fence of the 3D workload to complete.
+
+There are a few ways to prevent this problem:
+
+- Compute workloads can always be preempted, even when a page fault is pending
+  and not yet repaired. Not all hardware supports this.
+
+- DMA fence workloads and workloads which need page fault handling have
+  independent hardware resources to guarantee forward progress. This could be
+  achieved through e.g. through dedicated engines and minimal compute unit
+  reservations for DMA fence workloads.
+
+- The reservation approach could be further refined by only reserving the
+  hardware resources for DMA fence workloads when they are in-flight. This must
+  cover the time from when the DMA fence is visible to other threads up to
+  moment when fence is completed through dma_fence_signal().

Up till here it makes perfect sense, but what should this paragraph mean ?

Instead of reserving a few CU at driver load, to guarantee that
dma-fence workloads can always complete, we only do the reservatation
while a problematic dma_fence is in the system, and note yet
signalled. Of course that approach needs to be very careful, to really
make sure you can't ever deadlock by accident because the dynamic
reservation at runtime was done a notch too late.

This allows us to use all CUs on pure compute workloads (on servers,
and on desktop as long as nothing gets render

Re: [PATCH v2 13/15] dt-binding: display: bcm2711-hdmi: Add CEC and hotplug interrupts

[Dave Stevenson]

Hi Maxime

On Mon, 11 Jan 2021 at 14:23, Maxime Ripard  wrote:
>
> The CEC and hotplug interrupts were missing when that binding was
> introduced, let's add them in now that we've figured out how it works.
>
> Signed-off-by: Maxime Ripard 

Looks reasonable to me, but I'm not a DT bindings expert

Acked-by: Dave Stevenson 

> ---
>  .../bindings/display/brcm,bcm2711-hdmi.yaml   | 20 ++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> index 7ce06f9f9f8e..6e8ac910bdd8 100644
> --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -53,6 +53,24 @@ properties:
>- const: audio
>- const: cec
>
> +  interrupts:
> +items:
> +  - description: CEC TX interrupt
> +  - description: CEC RX interrupt
> +  - description: CEC stuck at low interrupt
> +  - description: Wake-up interrupt
> +  - description: Hotplug connected interrupt
> +  - description: Hotplug removed interrupt
> +
> +  interrupt-names:
> +items:
> +  - const: cec-tx
> +  - const: cec-rx
> +  - const: cec-low
> +  - const: wakeup
> +  - const: hpd-connected
> +  - const: hpd-removed
> +
>ddc:
>  allOf:
>- $ref: /schemas/types.yaml#/definitions/phandle
> @@ -90,7 +108,7 @@ required:
>- resets
>- ddc
>
> -additionalProperties: false
> +unevaluatedProperties: false
>
>  examples:
>- |
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications

[Daniel Vetter]

On Fri, Jan 22, 2021 at 2:24 PM Christian König
 wrote:
>
> Am 22.01.21 um 14:18 schrieb Daniel Vetter:
> > On Fri, Jan 22, 2021 at 2:10 PM Christian König
> >  wrote:
> >> Am 21.01.21 um 20:40 schrieb Daniel Vetter:
> >>> Recently there was a fairly long thread about recoreable hardware page
> >>> faults, how they can deadlock, and what to do about that.
> >>>
> >>> While the discussion is still fresh I figured good time to try and
> >>> document the conclusions a bit.
> >>>
> >>> References: 
> >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210107030127.20393-1-Felix.Kuehling%40amd.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C25c2b659bc8f47e0bace08d8bed83728%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637469183153437091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GlEKsPLRRRO%2BI1JSDpvNeBFbnFacmymxkj8e7QqM5SA%3D&reserved=0
> >>> Cc: Maarten Lankhorst 
> >>> Cc: Thomas Hellström 
> >>> Cc: "Christian König" 
> >>> Cc: Jerome Glisse 
> >>> Cc: Felix Kuehling 
> >>> Signed-off-by: Daniel Vetter 
> >>> Cc: Sumit Semwal 
> >>> Cc: linux-me...@vger.kernel.org
> >>> Cc: linaro-mm-...@lists.linaro.org
> >>> --
> >>> I'll be away next week, but figured I'll type this up quickly for some
> >>> comments and to check whether I got this all roughly right.
> >>>
> >>> Critique very much wanted on this, so that we can make sure hw which
> >>> can't preempt (with pagefaults pending) like gfx10 has a clear path to
>
> One more comment here: You should probably mention that gfx10 is
> referring to AMD GPUs.

Oh that was just the single-patch cover letter. I'll drop it for the
next round since that's not going to be part of the real patch.

> >>> support page faults in upstream. So anything I missed, got wrong or
> >>> like that would be good.
> >>> -Daniel
> >>> ---
> >>>Documentation/driver-api/dma-buf.rst | 66 
> >>>1 file changed, 66 insertions(+)
> >>>
> >>> diff --git a/Documentation/driver-api/dma-buf.rst 
> >>> b/Documentation/driver-api/dma-buf.rst
> >>> index a2133d69872c..e924c1e4f7a3 100644
> >>> --- a/Documentation/driver-api/dma-buf.rst
> >>> +++ b/Documentation/driver-api/dma-buf.rst
> >>> @@ -257,3 +257,69 @@ fences in the kernel. This means:
> >>>  userspace is allowed to use userspace fencing or long running compute
> >>>  workloads. This also means no implicit fencing for shared buffers in 
> >>> these
> >>>  cases.
> >>> +
> >>> +Recoverable Hardware Page Faults Implications
> >>> +~
> >>> +
> >>> +Modern hardware supports recoverable page faults, which has a lot of
> >>> +implications for DMA fences.
> >>> +
> >>> +First, a pending page fault obviously holds up the work that's running 
> >>> on the
> >>> +accelerator and a memory allocation is usually required to resolve the 
> >>> fault.
> >>> +But memory allocations are not allowed to gate completion of DMA fences, 
> >>> which
> >>> +means any workload using recoverable page faults cannot use DMA fences 
> >>> for
> >>> +synchronization. Synchronization fences controlled by userspace must be 
> >>> used
> >>> +instead.
> >>> +
> >>> +On GPUs this poses a problem, because current desktop compositor 
> >>> protocols on
> >>> +Linus rely on DMA fences, which means without an entirely new userspace 
> >>> stack
> >>> +built on top of userspace fences, they cannot benefit from recoverable 
> >>> page
> >>> +faults. The exception is when page faults are only used as migration 
> >>> hints and
> >>> +never to on-demand fill a memory request. For now this means recoverable 
> >>> page
> >>> +faults on GPUs are limited to pure compute workloads.
> >>> +
> >>> +Furthermore GPUs usually have shared resources between the 3D rendering 
> >>> and
> >>> +compute side, like compute units or command submission engines. If both 
> >>> a 3D
> >>> +job with a DMA fence and a compute workload using recoverable page 
> >>> faults are
> >>> +pending they could deadlock:
> >>> +
> >>> +- The 3D workload might need to wait for the compute job to finish and 
> >>> release
> >>> +  hardware resources first.
> >>> +
> >>> +- The compute workload might be stuck in a page fault, because the memory
> >>> +  allocation is waiting for the DMA fence of the 3D workload to complete.
> >>> +
> >>> +There are a few ways to prevent this problem:
> >>> +
> >>> +- Compute workloads can always be preempted, even when a page fault is 
> >>> pending
> >>> +  and not yet repaired. Not all hardware supports this.
> >>> +
> >>> +- DMA fence workloads and workloads which need page fault handling have
> >>> +  independent hardware resources to guarantee forward progress. This 
> >>> could be
> >>> +  achieved through e.g. through dedicated engines and minimal compute 
> >>> unit
> >>> +  reservations for DMA fence workloads.
> >>> +
> >>> +- The reservation approach could be further refin

Re: [PATCH v3 2/4] drm/qxl: unpin release objects

[Gerd Hoffmann]

On Fri, Jan 22, 2021 at 09:13:42AM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:
> > Balances the qxl_create_bo(..., pinned=true, ...);
> > call in qxl_release_bo_alloc().
> > 
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >   drivers/gpu/drm/qxl/qxl_release.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
> > b/drivers/gpu/drm/qxl/qxl_release.c
> > index 0fcfc952d5e9..add979cba11b 100644
> > --- a/drivers/gpu/drm/qxl/qxl_release.c
> > +++ b/drivers/gpu/drm/qxl/qxl_release.c
> > @@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release)
> > entry = container_of(release->bos.next,
> >  struct qxl_bo_list, tv.head);
> > bo = to_qxl_bo(entry->tv.bo);
> > +   bo->tbo.pin_count = 0; /* ttm_bo_unpin(&bo->tbo); */
> 
> This code looks like a workaround or a bug.
> 
> AFAICT the only place with pre-pinned BO is qdev->dumb_shadow_bo. Can you
> remove the pinned flag entirely and handle pinning as part of
> dumb_shadow_bo's code.

No, the release objects are pinned too, and they must be
pinned (qxl commands are in there, and references are
placed in the qxl rings, so allowing them to roam is
a non-starter).

> if (pin_count)
> ttm_bo_unpin();
> WARN_ON(pin_count); /* should always be 0 now */

Well, the pin_count is 1 at this point.
No need for the if().

Just calling ttm_bo_unpin() here makes lockdep unhappy.

Not calling ttm_bo_unpin() makes ttm_bo_release() throw
a WARN() because of the pin.

Clearing pin_count (which is how ttm fixes things up
in the error path) works.

I'm open to better ideas.

take care,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/todo: Add entry for moving to dma_resv_lock

[Daniel Vetter]

Requested by Thomas. I think it justifies a new level, since I tried
to make some forward progress on this last summer, and gave up (for
now). This is very tricky.

Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
 Documentation/gpu/todo.rst | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index dea9082c0e5f..f872d3d33218 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -23,6 +23,9 @@ Advanced: Tricky tasks that need fairly good understanding of 
the DRM subsystem
 and graphics topics. Generally need the relevant hardware for development and
 testing.
 
+Expert: Only attempt these if you've successfully completed some tricky
+refactorings already and are an expert in the specific area
+
 Subsystem-wide refactorings
 ===
 
@@ -168,6 +171,22 @@ Contact: Daniel Vetter, respective driver maintainers
 
 Level: Advanced
 
+Move Buffer Object Locking to dma_resv_lock()
+-
+
+Many drivers have their own per-object locking scheme, usually using
+mutex_lock(). This causes all kinds of trouble for buffer sharing, since
+depending which driver is the exporter and importer, the locking hierarchy is
+reversed.
+
+To solve this we need one standard per-object locking mechanism, which is
+dma_resv_lock(). This lock needs to be called as the outermost lock, with all
+other driver specific per-object locks removed. The problem is tha rolling out
+the actual change to the locking contract is a flag day, due to struct dma_buf
+buffer sharing.
+
+Level: Expert
+
 Convert logging to drm_* functions with drm_device paramater
 
 
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH] drm/todo: Add entry for moving to dma_resv_lock

[Christian König]

Am 22.01.21 um 14:36 schrieb Daniel Vetter:

Requested by Thomas. I think it justifies a new level, since I tried
to make some forward progress on this last summer, and gave up (for
now). This is very tricky.

Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
  Documentation/gpu/todo.rst | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index dea9082c0e5f..f872d3d33218 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -23,6 +23,9 @@ Advanced: Tricky tasks that need fairly good understanding of 
the DRM subsystem
  and graphics topics. Generally need the relevant hardware for development and
  testing.
  
+Expert: Only attempt these if you've successfully completed some tricky

+refactorings already and are an expert in the specific area
+
  Subsystem-wide refactorings
  ===
  
@@ -168,6 +171,22 @@ Contact: Daniel Vetter, respective driver maintainers
  
  Level: Advanced
  
+Move Buffer Object Locking to dma_resv_lock()

+-
+
+Many drivers have their own per-object locking scheme, usually using
+mutex_lock(). This causes all kinds of trouble for buffer sharing, since
+depending which driver is the exporter and importer, the locking hierarchy is
+reversed.
+
+To solve this we need one standard per-object locking mechanism, which is
+dma_resv_lock(). This lock needs to be called as the outermost lock, with all
+other driver specific per-object locks removed. The problem is tha rolling out
+the actual change to the locking contract is a flag day, due to struct dma_buf
+buffer sharing.
+
+Level: Expert
+


Could you name some examples of driver locks here? I'm not aware in 
anything like this in amdgpu, radeon or neveau.


And yes sounds like a job for the appropriate driver maintainer.

Thanks,
Christian.


  Convert logging to drm_* functions with drm_device paramater
  
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH] drm/todo: Add entry for moving to dma_resv_lock

[Daniel Vetter]

On Fri, Jan 22, 2021 at 2:40 PM Christian König
 wrote:
>
> Am 22.01.21 um 14:36 schrieb Daniel Vetter:
> > Requested by Thomas. I think it justifies a new level, since I tried
> > to make some forward progress on this last summer, and gave up (for
> > now). This is very tricky.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Sumit Semwal 
> > Cc: "Christian König" 
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > ---
> >   Documentation/gpu/todo.rst | 19 +++
> >   1 file changed, 19 insertions(+)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index dea9082c0e5f..f872d3d33218 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -23,6 +23,9 @@ Advanced: Tricky tasks that need fairly good 
> > understanding of the DRM subsystem
> >   and graphics topics. Generally need the relevant hardware for development 
> > and
> >   testing.
> >
> > +Expert: Only attempt these if you've successfully completed some tricky
> > +refactorings already and are an expert in the specific area
> > +
> >   Subsystem-wide refactorings
> >   ===
> >
> > @@ -168,6 +171,22 @@ Contact: Daniel Vetter, respective driver maintainers
> >
> >   Level: Advanced
> >
> > +Move Buffer Object Locking to dma_resv_lock()
> > +-
> > +
> > +Many drivers have their own per-object locking scheme, usually using
> > +mutex_lock(). This causes all kinds of trouble for buffer sharing, since
> > +depending which driver is the exporter and importer, the locking hierarchy 
> > is
> > +reversed.
> > +
> > +To solve this we need one standard per-object locking mechanism, which is
> > +dma_resv_lock(). This lock needs to be called as the outermost lock, with 
> > all
> > +other driver specific per-object locks removed. The problem is tha rolling 
> > out
> > +the actual change to the locking contract is a flag day, due to struct 
> > dma_buf
> > +buffer sharing.
> > +
> > +Level: Expert
> > +
>
> Could you name some examples of driver locks here? I'm not aware in
> anything like this in amdgpu, radeon or neveau.

ttm based drivers are all fine. It's everything else which is a
problem, and it gets worse if you mix helpers (like shmem helpers,
which have their own locks internally) with render drivers (again with
their own mutexes).

> And yes sounds like a job for the appropriate driver maintainer.

The problem is, this one you can't do driver-by-driver because of the
dma-buf contract. I mean we tried for p2p at first, it's just too
much. I tried to do it last summer just for shmem gem helpers, and you
really have to tackle all the drivers in one go (even if you ignore
dma-buf for now, where we side-stepped the problem with pinning). This
is "scares danvet" levels of nasty.
-Daniel

> Thanks,
> Christian.
>
> >   Convert logging to drm_* functions with drm_device paramater
> >   
> >
>


-- 
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

Re: [PATCH v3 2/4] drm/qxl: unpin release objects

[Daniel Vetter]

On Fri, Jan 22, 2021 at 2:35 PM Gerd Hoffmann  wrote:
>
> On Fri, Jan 22, 2021 at 09:13:42AM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:
> > > Balances the qxl_create_bo(..., pinned=true, ...);
> > > call in qxl_release_bo_alloc().
> > >
> > > Signed-off-by: Gerd Hoffmann 
> > > ---
> > >   drivers/gpu/drm/qxl/qxl_release.c | 1 +
> > >   1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
> > > b/drivers/gpu/drm/qxl/qxl_release.c
> > > index 0fcfc952d5e9..add979cba11b 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_release.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_release.c
> > > @@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release)
> > > entry = container_of(release->bos.next,
> > >  struct qxl_bo_list, tv.head);
> > > bo = to_qxl_bo(entry->tv.bo);
> > > +   bo->tbo.pin_count = 0; /* ttm_bo_unpin(&bo->tbo); */
> >
> > This code looks like a workaround or a bug.
> >
> > AFAICT the only place with pre-pinned BO is qdev->dumb_shadow_bo. Can you
> > remove the pinned flag entirely and handle pinning as part of
> > dumb_shadow_bo's code.
>
> No, the release objects are pinned too, and they must be
> pinned (qxl commands are in there, and references are
> placed in the qxl rings, so allowing them to roam is
> a non-starter).
>
> > if (pin_count)
> > ttm_bo_unpin();
> > WARN_ON(pin_count); /* should always be 0 now */
>
> Well, the pin_count is 1 at this point.
> No need for the if().
>
> Just calling ttm_bo_unpin() here makes lockdep unhappy.

How does that one splat? But yeah if that's a problem should be
explained in the comment. I'd then also only do a pin_count--; to make
sure you can still catch other pin leaks if you have them. Setting it
to 0 kinda defeats the warning.
-Daniel

>
> Not calling ttm_bo_unpin() makes ttm_bo_release() throw
> a WARN() because of the pin.
>
> Clearing pin_count (which is how ttm fixes things up
> in the error path) works.
>
> I'm open to better ideas.
>
> take care,
>   Gerd
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
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

Re: [PATCH] drm/todo: Add entry for moving to dma_resv_lock

[Thomas Zimmermann]

Hi

Am 22.01.21 um 14:36 schrieb Daniel Vetter:

Requested by Thomas. I think it justifies a new level, since I tried
to make some forward progress on this last summer, and gave up (for
now). This is very tricky.


Adding it to the TODO list is a first step. :)

Acked-by: Thomas Zimmermann 



Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
  Documentation/gpu/todo.rst | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index dea9082c0e5f..f872d3d33218 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -23,6 +23,9 @@ Advanced: Tricky tasks that need fairly good understanding of 
the DRM subsystem
  and graphics topics. Generally need the relevant hardware for development and
  testing.
  
+Expert: Only attempt these if you've successfully completed some tricky

+refactorings already and are an expert in the specific area
+
  Subsystem-wide refactorings
  ===
  
@@ -168,6 +171,22 @@ Contact: Daniel Vetter, respective driver maintainers
  
  Level: Advanced
  
+Move Buffer Object Locking to dma_resv_lock()

+-
+
+Many drivers have their own per-object locking scheme, usually using
+mutex_lock(). This causes all kinds of trouble for buffer sharing, since
+depending which driver is the exporter and importer, the locking hierarchy is
+reversed.
+
+To solve this we need one standard per-object locking mechanism, which is
+dma_resv_lock(). This lock needs to be called as the outermost lock, with all
+other driver specific per-object locks removed. The problem is tha rolling out
+the actual change to the locking contract is a flag day, due to struct dma_buf
+buffer sharing.
+
+Level: Expert
+
  Convert logging to drm_* functions with drm_device paramater
  
  



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/2] drm/gma500: Convert to use new SCU IPC API

[Patrik Jakobsson]

On Fri, Jan 22, 2021 at 12:39 PM Andy Shevchenko
 wrote:
>
> Convert the GMA500 driver to use the new SCU IPC API. This allows us
> to get rid of the duplicate PMC IPC implementation which is now covered
> in SCU IPC driver.
>
> Signed-off-by: Andy Shevchenko 
> Acked-by: Linus Walleij 

Both patches look good. Do you want me to take them through drm-misc? Otherwise:
Acked-by: Patrik Jakobsson 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] drm/uapi: Add USB connector type

[Noralf Trønnes]

Den 22.01.2021 13.47, skrev Thomas Zimmermann:
> Hi
> 
> Am 22.01.21 um 12:44 schrieb Noralf Trønnes:
>>
>> And wrt PCI it wouldn't be a PCI connector if the card has some other
>> connector for the display, but if it was possible to connect a display
>> directly to the PCI connector, then yes I would call that a PCI
>> connector.
> 
> You're not connecting a display to the computer. You're connecting an
> RPi and then connect the display to the RPi. The RPi acts like an
> external graphics card.
> 
>> This begs the question: Why does the kernel provide info to userspace
>> about the connector type?
>>
>> My take is that it is so the user can know which display is connected to
>> which port on the computer.
> 
> This exactly illustrates the problem with the current naming. For a
> single output the distinction between bus and connector might be fuzzy.
> As soon as a connected SoC contains multiple connectors. The user then
> sees names such as card1-USB-0 and card1-USB-1, which makes no sense.
> 

If you look at the code I pasted in, you'll see that the SoC connector
types are passed through to the host driver as-is unless they are panel
connectors like DSI/DPI, which will be interpreted as USB (the protocol
does support multiple connectors, but only one can be used at a time).

So for the Pi4 as a display adapter, the host will see card1-HDMI-0 and
card1-HDMI-1, the same is true for the composite output (if enabled) it
shows up as card1-Composite-0 (can't be enabled together with HDMI).

If the Pi4 is used together with a DSI connected touchscreen, it makes
sense to disable the SoC HDMI outputs and the host only will see the
board as card1-USB-0 (I haven't done this exercise yet since there's
problems with getting the official Pi touchscreen to work with vc4 on Pi4).

The USB connector type is most important for tiny displays that is
microcontroller based without Linux running. There are lots of tiny SPI
displays and I expect this market to shift towards USB because it much
easier to connect and the display will be useable on a desktop/server
computer as status displays perhaps. But embedded will also benefit from
having these displays USB interfaced.

Another use case I see is repurposing old Android tablets as USB
displays that can be connected to any computer and become a touchscreen.
In this case I also want the connector to be called card1-USB-0 (I
haven't done any work in this area, old Android is fbdev so some work is
needed for this to happen).

Noralf.

>>
>> What's your opinion?
>>

 Ofc as Daniel mentions it's a downside that userspace doesn't know
 about
 the connector type, and who knows when it will updated (if I don't do
 it).
 Weston will name it: "UNNAMED-%d"
 Mutter: "Unknown%d-%d"
 X: "Unknown%d-%d"

 Sam and Laurent has discussed adding a PANEL connector type instead of
 adding more connector types for panel connectors. I think that would
 have been a better choice instead of the SPI connector type that I
 added
 in 2019. But I think PANEL was meant for panels connected to an
 internal
 connector.

 Here's my protocol connector types and how it's mapped to DRM:

 #define GUD_CONNECTOR_TYPE_PANEL    0
 #define GUD_CONNECTOR_TYPE_VGA    1
 #define GUD_CONNECTOR_TYPE_COMPOSITE    2
 #define GUD_CONNECTOR_TYPE_SVIDEO    3
 #define GUD_CONNECTOR_TYPE_COMPONENT    4
 #define GUD_CONNECTOR_TYPE_DVI    5
 #define GUD_CONNECTOR_TYPE_DISPLAYPORT    6
 #define GUD_CONNECTOR_TYPE_HDMI    7

 static int gud_gadget_ctrl_get_connector(struct gud_gadget *gdg,
 unsigned int index,
   struct gud_connector_descriptor_req *desc)
 {
 ...
  gconn = &gdg->connectors[index];

  switch (gconn->connector->connector_type) {
  case DRM_MODE_CONNECTOR_VGA:
  desc->connector_type = GUD_CONNECTOR_TYPE_VGA;
  break;
  case DRM_MODE_CONNECTOR_DVII:
  fallthrough;
  case DRM_MODE_CONNECTOR_DVID:
  fallthrough;
  case DRM_MODE_CONNECTOR_DVIA:
  desc->connector_type = GUD_CONNECTOR_TYPE_DVI;
  break;
  case DRM_MODE_CONNECTOR_Composite:
  desc->connector_type = GUD_CONNECTOR_TYPE_COMPOSITE;
  break;
  case DRM_MODE_CONNECTOR_SVIDEO:
  desc->connector_type = GUD_CONNECTOR_TYPE_SVIDEO;
  break;
  case DRM_MODE_CONNECTOR_Component:
  desc->connector_type = GUD_CONNECTOR_TYPE_COMPONENT;
  break;
  case DRM_MODE_CONNECTOR_DisplayPort:
  desc->connector_type = GUD_CONNECTOR_TYPE_DISPLAYPORT;
  break;
  case DRM_MODE_CONNECTOR_HDMIA:
  fallthrough;
  case DRM_MODE_CONNECTOR_HDMIB:
  desc->connector_type = GUD_CONNECTOR_TYPE_HDMI;
  bre

Re: possible IO map leak in drm/gem

[Thomas Zimmermann]

Hi

Am 22.01.21 um 15:27 schrieb Chuck Lever:




On Jan 21, 2021, at 10:05 AM, Chuck Lever  wrote:




On Jan 21, 2021, at 9:47 AM, Thomas Zimmermann  wrote:

(cc'ing dri-devel)

Hi,

thanks for reporting the bug.

Am 21.01.21 um 15:35 schrieb Chuck Lever:

Hi Thomas-
I was not able to find an appropriate mailing list entry in MAINTAINERS,


That would be dri-devel@lists.freedesktop.org


so I'm mailing you directly as committer of record for:
43676605f890 ("drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers")
I've noticed that since putting v5.11-rc on my test systems, overnight
on an otherwise idle system the load average seems to grow as the result
of a kernel worker thread.


Earlier this week I fixed a couple of leaks in that code. Could you please 
apply the patch at [1] and report back if it fixes the issue.

If it's a separate problem, I'll take a closer look.


Thomas, thank you for your quick response. I've installed your patch
on one system and it looks promising already. I'll let it soak overnight.


All symptoms appear to be gone. Fwiw,

Tested-by: Chuck Lever 


Great. Thanks a lot for testing.

Best regards
Thomas





Best regards
Thomas

[1] 
https://lore.kernel.org/dri-devel/20210118144639.27307-1-tzimmerm...@suse.de/


I used "perf top" to see what it had gotten up to, and it appears that
it was spending lots of time walking an interval tree on behalf of
memtype_reserve().
The most frequently-observed stack trace seems to be:
 kworker/3:1-2355  [003] 60950.150928: function: memtype_reserve
 kworker/3:1-2355  [003] 60950.150942: kernel_stack: 
=> c0c66083
=> memtype_reserve (a005f9d5)
=> __ioremap_caller (a005aac1)
=> ttm_bo_vmap (c040f266)
=> drm_gem_vram_vmap (c042c5cd)
=> drm_gem_vmap (c0506a7f)
=> drm_client_buffer_vmap (c0523741)
=> drm_fb_helper_damage_work (c049a34a)
=> process_one_work (a00dd92e)
=> worker_thread (a00dde46)
=> kthread (a00e22c4)
=> ret_from_fork (a0004192)
I see a regular call to memtype_reserve(), but never a matching call to
memtype_free(), thus I suspect a leak of I/O maps in this code.
--
Chuck Lever


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


--
Chuck Lever


--
Chuck Lever





--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] drm/uapi: Add USB connector type

[Thomas Zimmermann]

Hi

Am 22.01.21 um 15:35 schrieb Noralf Trønnes:



Den 22.01.2021 13.47, skrev Thomas Zimmermann:

Hi

Am 22.01.21 um 12:44 schrieb Noralf Trønnes:


And wrt PCI it wouldn't be a PCI connector if the card has some other
connector for the display, but if it was possible to connect a display
directly to the PCI connector, then yes I would call that a PCI
connector.


You're not connecting a display to the computer. You're connecting an
RPi and then connect the display to the RPi. The RPi acts like an
external graphics card.


This begs the question: Why does the kernel provide info to userspace
about the connector type?

My take is that it is so the user can know which display is connected to
which port on the computer.


This exactly illustrates the problem with the current naming. For a
single output the distinction between bus and connector might be fuzzy.
As soon as a connected SoC contains multiple connectors. The user then
sees names such as card1-USB-0 and card1-USB-1, which makes no sense.



If you look at the code I pasted in, you'll see that the SoC connector
types are passed through to the host driver as-is unless they are panel
connectors like DSI/DPI, which will be interpreted as USB (the protocol
does support multiple connectors, but only one can be used at a time).

So for the Pi4 as a display adapter, the host will see card1-HDMI-0 and
card1-HDMI-1, the same is true for the composite output (if enabled) it
shows up as card1-Composite-0 (can't be enabled together with HDMI).

If the Pi4 is used together with a DSI connected touchscreen, it makes
sense to disable the SoC HDMI outputs and the host only will see the
board as card1-USB-0 (I haven't done this exercise yet since there's
problems with getting the official Pi touchscreen to work with vc4 on Pi4).


I saw that. I can even get your point about using USB for panel (still 
don't agree). But you're also using USB as default case.


Best regards
Thomas



The USB connector type is most important for tiny displays that is
microcontroller based without Linux running. There are lots of tiny SPI
displays and I expect this market to shift towards USB because it much
easier to connect and the display will be useable on a desktop/server
computer as status displays perhaps. But embedded will also benefit from
having these displays USB interfaced.

Another use case I see is repurposing old Android tablets as USB
displays that can be connected to any computer and become a touchscreen.
In this case I also want the connector to be called card1-USB-0 (I
haven't done any work in this area, old Android is fbdev so some work is
needed for this to happen).

Noralf.



What's your opinion?



Ofc as Daniel mentions it's a downside that userspace doesn't know
about
the connector type, and who knows when it will updated (if I don't do
it).
Weston will name it: "UNNAMED-%d"
Mutter: "Unknown%d-%d"
X: "Unknown%d-%d"

Sam and Laurent has discussed adding a PANEL connector type instead of
adding more connector types for panel connectors. I think that would
have been a better choice instead of the SPI connector type that I
added
in 2019. But I think PANEL was meant for panels connected to an
internal
connector.

Here's my protocol connector types and how it's mapped to DRM:

#define GUD_CONNECTOR_TYPE_PANEL    0
#define GUD_CONNECTOR_TYPE_VGA    1
#define GUD_CONNECTOR_TYPE_COMPOSITE    2
#define GUD_CONNECTOR_TYPE_SVIDEO    3
#define GUD_CONNECTOR_TYPE_COMPONENT    4
#define GUD_CONNECTOR_TYPE_DVI    5
#define GUD_CONNECTOR_TYPE_DISPLAYPORT    6
#define GUD_CONNECTOR_TYPE_HDMI    7

static int gud_gadget_ctrl_get_connector(struct gud_gadget *gdg,
unsigned int index,
   struct gud_connector_descriptor_req *desc)
{
...
  gconn = &gdg->connectors[index];

  switch (gconn->connector->connector_type) {
  case DRM_MODE_CONNECTOR_VGA:
  desc->connector_type = GUD_CONNECTOR_TYPE_VGA;
  break;
  case DRM_MODE_CONNECTOR_DVII:
  fallthrough;
  case DRM_MODE_CONNECTOR_DVID:
  fallthrough;
  case DRM_MODE_CONNECTOR_DVIA:
  desc->connector_type = GUD_CONNECTOR_TYPE_DVI;
  break;
  case DRM_MODE_CONNECTOR_Composite:
  desc->connector_type = GUD_CONNECTOR_TYPE_COMPOSITE;
  break;
  case DRM_MODE_CONNECTOR_SVIDEO:
  desc->connector_type = GUD_CONNECTOR_TYPE_SVIDEO;
  break;
  case DRM_MODE_CONNECTOR_Component:
  desc->connector_type = GUD_CONNECTOR_TYPE_COMPONENT;
  break;
  case DRM_MODE_CONNECTOR_DisplayPort:
  desc->connector_type = GUD_CONNECTOR_TYPE_DISPLAYPORT;
  break;
  case DRM_MODE_CONNECTOR_HDMIA:
  fallthrough;
  case DRM_MODE_CONNECTOR_HDMIB:
  desc->connector_type = GUD_CONNECTOR_TYPE_HDMI;
  break;
  default:
  desc->connector_type = GUD_CONNECTOR_TYPE_PANEL;
  break;
  };


int gud_connector_crea

[PATCH][next] drm/amdgpu: Fix masking binary not operator on two mask operations

[Colin King]

From: Colin Ian King 

Currently the ! operator is incorrectly being used to flip bits on
mask values. Fix this by using the bit-wise ~ operator instead.

Addresses-Coverity: ("Logical vs. bitwise operator")
Fixes: 3c9a7b7d6e75 ("drm/amdgpu: update mmhub mgcg&ls for mmhub_v2_3")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c 
b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
index 1961745e89c7..ab9be5ad5a5f 100644
--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
@@ -531,12 +531,12 @@ mmhub_v2_3_update_medium_grain_light_sleep(struct 
amdgpu_device *adev,
 
if (enable && (adev->cg_flags & AMD_CG_SUPPORT_MC_LS)) {
data &= ~MM_ATC_L2_CGTT_CLK_CTRL__MGLS_OVERRIDE_MASK;
-   data1 &= !(DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
+   data1 &= ~(DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_WRITE_MASK |
DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_READ_MASK |
DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_RETURN_MASK |
DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_REGISTER_MASK);
-   data2 &= !(DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
+   data2 &= ~(DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_WRITE_MASK |
DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_READ_MASK |
DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_RETURN_MASK |
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] dt-bindings: display: Convert mxsfb DT bindings to YAML

[Rob Herring]

On Sat, Jan 16, 2021 at 12:23:01AM +0200, Laurent Pinchart wrote:
> Hello,
> 
> This patch series has previously been posted as part of "[PATCH v2 0/7]
> drm: mxsfb: Allow overriding bus width". I've split the DT bindings
> conversion to a separate series as I believe they're ready, and Martin
> has a patch that he would like to submit to the bindings.
> 
> All the patches have been acked, and changes to v2 are minor. Rob, could
> you take this through your tree ?

Better to go thru drm-misc-next given other changes coming, so I applied 
the series there.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH][next] drm/i915/hdcp: Fix return of value in uninitialized variable ret

[Colin King]

From: Colin Ian King 

Currently when there are other connectors on the port using HDCP the
function _intel_hdcp_disable returns a garbage uninitialized value in
variable ret.  I believe the intention is to return 0, so return this
literal value instead of the value in ret.

Addresses-Coverity: ("Uninitialized scalar return")
Fixes: 899c8762f981 ("drm/i915/hdcp: Configure HDCP2.2 MST steram encryption 
status")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index db8dff2eeb0a..a0e7b0bf892b 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -883,7 +883,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
 * until it disabled HDCP encryption for all connectors in MST topology.
 */
if (dig_port->num_hdcp_streams > 0)
-   return ret;
+   return 0;
 
hdcp->hdcp_encrypted = false;
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/2] drm/gma500: Convert to use new SCU IPC API

[Patrik Jakobsson]

On Fri, Jan 22, 2021 at 3:51 PM Andy Shevchenko
 wrote:
>
> On Fri, Jan 22, 2021 at 03:16:55PM +0100, Patrik Jakobsson wrote:
> > On Fri, Jan 22, 2021 at 12:39 PM Andy Shevchenko
> >  wrote:
> > >
> > > Convert the GMA500 driver to use the new SCU IPC API. This allows us
> > > to get rid of the duplicate PMC IPC implementation which is now covered
> > > in SCU IPC driver.
> > >
> > > Signed-off-by: Andy Shevchenko 
> > > Acked-by: Linus Walleij 
> >
> > Both patches look good. Do you want me to take them through drm-misc? 
> > Otherwise:
> > Acked-by: Patrik Jakobsson 
>
> I guess it's fine to go via drm-misc, but we might need an immutable 
> branch/tag
> in the future (in case the rest cleanups that are dependent but have not sent
> yet will pending v5.12).

Right, so you need this included before you remove the duplicate PMC
IPC implementation? Then I think it's better you take the patches
through whatever tree the PMC IPC changes go. You have my ack.

-Patrik
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/3] Experimental freesync video mode optimization

[Alex Deucher]

On Fri, Jan 22, 2021 at 4:43 AM Daniel Vetter  wrote:
>
> On Fri, Jan 22, 2021 at 10:32:48AM +0200, Pekka Paalanen wrote:
> > On Tue, 19 Jan 2021 10:50:26 -0500
> > Aurabindo Pillai  wrote:
> >
> > > Changes in V5
> > > =
> > >
> > > * More info in commit messages on the rationale of changes being added
> > > to the kernel.
> > > * Minor fixes
> >
> > Hi,
> >
> > thank you for adding the explanations in the commit messages I asked
> > for. It is now up to DRM maintainers to determine if this is
> > conceptually fine.
> >
> > I do see that apparently setting the opt-in option does not yet taint
> > the kernel although Daniel Vetter suggested it might be a good idea. I
> > guess tainting the kernel would make it easier to remove this feature
> > in the future because it would be easier to dismiss people that claim a
> > kernel regression due to the removal.
>
> Reading the descriptions I'm honestly not sure why this isn't enabled by
> default?
>
> Maybe the explanations should also capture why this is maybe not a good
> idea ...

I don't know that it's a bad idea, I guess we are just cautious to
avoid unforeseen consequences until we have more real world experience
using the feature.  One issue brought up as a possible problem, but
not actually verified to my knowledge, was the possibility of using a
bit more power with freesync modes.  E.g., if you just change the
front porch to set the refresh to 48 Hz on a 90Hz mode, you are
technically running the display phys at the higher clock speed so you
can seamlessly transition to 90Hz or whatever.  I don't know that it
uses that much additional power and lets you get some nice features in
a relatively seamless manner that already works today with most media
players.

I guess for media player folks, is this something you'd like as is?  A
more explicit API may be nicer, but I think I think the ultimate
solution will end up getting tied up in what are plans are for bigger
features like more advanced flip queues and stuff like that.  So this
seems like a nice intermediate step.

Alex


> -Daniel
>
> >
> >
> > Thanks,
> > pq
> >
> >
> > > --
> > >
> > > This patchset enables freesync video mode usecase where the userspace
> > > can request a freesync compatible video mode such that switching to this
> > > mode does not trigger blanking.
> > >
> > > This feature is guarded by a module parameter which is disabled by
> > > default. Enabling this paramters adds additional modes to the driver
> > > modelist, and also enables the optimization to skip modeset when using
> > > one of these modes.
> > >
> > > --
> > >
> > > Aurabindo Pillai (3):
> > >   drm/amd/display: Add module parameter for freesync video mode
> > >   drm/amd/display: Add freesync video modes based on preferred modes
> > >   drm/amd/display: Skip modeset for front porch change
> > >
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   1 +
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  12 +
> > >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 401 --
> > >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   3 +
> > >  4 files changed, 382 insertions(+), 35 deletions(-)
> > >
> >
>
>
>
> --
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/i915/hdcp: Fix return of value in uninitialized variable ret

[Jani Nikula]

On Fri, 22 Jan 2021, Colin King  wrote:
> From: Colin Ian King 
>
> Currently when there are other connectors on the port using HDCP the
> function _intel_hdcp_disable returns a garbage uninitialized value in
> variable ret.  I believe the intention is to return 0, so return this
> literal value instead of the value in ret.
>
> Addresses-Coverity: ("Uninitialized scalar return")
> Fixes: 899c8762f981 ("drm/i915/hdcp: Configure HDCP2.2 MST steram encryption 
> status")
> Signed-off-by: Colin Ian King 

Thanks, but there's already a fix in progress:

http://lore.kernel.org/r/20210119064655.1605-3-anshuman.gu...@intel.com

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index db8dff2eeb0a..a0e7b0bf892b 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -883,7 +883,7 @@ static int _intel_hdcp_disable(struct intel_connector 
> *connector)
>* until it disabled HDCP encryption for all connectors in MST topology.
>*/
>   if (dig_port->num_hdcp_streams > 0)
> - return ret;
> + return 0;
>  
>   hdcp->hdcp_encrypted = false;
>   intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting

[Rob Herring]

On Tue, Jan 12, 2021 at 2:57 AM Xin Ji  wrote:
>
> Hi Rob Herring, thanks for the comments.
>
> On Mon, Jan 11, 2021 at 04:14:35PM -0600, Rob Herring wrote:
> > On Thu, Dec 31, 2020 at 10:21:12AM +0800, Xin Ji wrote:
> > > Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add
> > > swing setting for adjusting DP tx PHY swing
> > >
> > > Signed-off-by: Xin Ji 
> > > ---
> > >  .../bindings/display/bridge/analogix,anx7625.yaml  | 25 
> > > --
> > >  1 file changed, 23 insertions(+), 2 deletions(-)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index 60585a4..4eb0ea3 100644
> > > --- 
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++ 
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -34,6 +34,16 @@ properties:
> > >  description: used for reset chip control, RESET_N pin B7.
> > >  maxItems: 1
> > >
> > > +  analogix,swing-setting:
> > > +type: uint8-array
> >
> > Humm, this should have be rejected by the meta-schema.
> We needs define an array to adjust DP tx PHY swing, the developer hopes these
> settings are changeable, so I moved the register data to DT. Can you
> give me some suggestion if it is rejected by the meta-schema?
> >
> > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> >
> > This is how types are defined other than boolean or nodes (object).
> >
> > > +description: an array of swing register setting for DP tx PHY
> > > +
> > > +  analogix,mipi-dpi-in:
> > > +type: int
> > > +$ref: /schemas/types.yaml#/definitions/uint32
> > > +description: indicate the MIPI rx signal type is DPI or DSI
> >
> > Why does this need to be in DT, you should be able to determine this
> > based on what you are connected to.
> As the anx7625 can receive MIPI DSI and DPI data (depends on hardware
> implement, we have a project which have two anx7625, one is DSI input,
> the other is DPI input), we needs to let driver know what kind of MIPI
> rx signal input. And there is no other way to tell driver the MIPI rx
> signal type, we needs define this flag.

That's only true if what's driving the output is a single h/w block
that can drive either. But typically you have 2 blocks: an LCD
controller driving parallel signals and a DSI controller in front of
it doing parallel to DSI conversion. The anx7625 would be connected to
the LCD controller or DSI controller via the graph binding depending
on the h/w connection.

However, if you do need this, then let's extend video-interfaces.yaml
'bus-type' to include DSI (it already has parallel).

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications

[Felix Kuehling]

Am 2021-01-21 um 2:40 p.m. schrieb Daniel Vetter:
> Recently there was a fairly long thread about recoreable hardware page
> faults, how they can deadlock, and what to do about that.
>
> While the discussion is still fresh I figured good time to try and
> document the conclusions a bit.
Thank you Daniel. This is a good summary of our discussion. It's also an
external reference I can point our HW engineers at when they're
wondering about what "real software" does.

Regards,
  Felix


>
> References: 
> https://lore.kernel.org/dri-devel/20210107030127.20393-1-felix.kuehl...@amd.com/
> Cc: Maarten Lankhorst 
> Cc: Thomas Hellström 
> Cc: "Christian König" 
> Cc: Jerome Glisse 
> Cc: Felix Kuehling 
> Signed-off-by: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> --
> I'll be away next week, but figured I'll type this up quickly for some
> comments and to check whether I got this all roughly right.
>
> Critique very much wanted on this, so that we can make sure hw which
> can't preempt (with pagefaults pending) like gfx10 has a clear path to
> support page faults in upstream. So anything I missed, got wrong or
> like that would be good.
> -Daniel
> ---
>  Documentation/driver-api/dma-buf.rst | 66 
>  1 file changed, 66 insertions(+)
>
> diff --git a/Documentation/driver-api/dma-buf.rst 
> b/Documentation/driver-api/dma-buf.rst
> index a2133d69872c..e924c1e4f7a3 100644
> --- a/Documentation/driver-api/dma-buf.rst
> +++ b/Documentation/driver-api/dma-buf.rst
> @@ -257,3 +257,69 @@ fences in the kernel. This means:
>userspace is allowed to use userspace fencing or long running compute
>workloads. This also means no implicit fencing for shared buffers in these
>cases.
> +
> +Recoverable Hardware Page Faults Implications
> +~
> +
> +Modern hardware supports recoverable page faults, which has a lot of
> +implications for DMA fences.
> +
> +First, a pending page fault obviously holds up the work that's running on the
> +accelerator and a memory allocation is usually required to resolve the fault.
> +But memory allocations are not allowed to gate completion of DMA fences, 
> which
> +means any workload using recoverable page faults cannot use DMA fences for
> +synchronization. Synchronization fences controlled by userspace must be used
> +instead.
> +
> +On GPUs this poses a problem, because current desktop compositor protocols on
> +Linus rely on DMA fences, which means without an entirely new userspace stack
> +built on top of userspace fences, they cannot benefit from recoverable page
> +faults. The exception is when page faults are only used as migration hints 
> and
> +never to on-demand fill a memory request. For now this means recoverable page
> +faults on GPUs are limited to pure compute workloads.
> +
> +Furthermore GPUs usually have shared resources between the 3D rendering and
> +compute side, like compute units or command submission engines. If both a 3D
> +job with a DMA fence and a compute workload using recoverable page faults are
> +pending they could deadlock:
> +
> +- The 3D workload might need to wait for the compute job to finish and 
> release
> +  hardware resources first.
> +
> +- The compute workload might be stuck in a page fault, because the memory
> +  allocation is waiting for the DMA fence of the 3D workload to complete.
> +
> +There are a few ways to prevent this problem:
> +
> +- Compute workloads can always be preempted, even when a page fault is 
> pending
> +  and not yet repaired. Not all hardware supports this.
> +
> +- DMA fence workloads and workloads which need page fault handling have
> +  independent hardware resources to guarantee forward progress. This could be
> +  achieved through e.g. through dedicated engines and minimal compute unit
> +  reservations for DMA fence workloads.
> +
> +- The reservation approach could be further refined by only reserving the
> +  hardware resources for DMA fence workloads when they are in-flight. This 
> must
> +  cover the time from when the DMA fence is visible to other threads up to
> +  moment when fence is completed through dma_fence_signal().
> +
> +- As a last resort, if the hardware provides no useful reservation mechanics,
> +  all workloads must be flushed from the GPU when switching between jobs
> +  requiring DMA fences or jobs requiring page fault handling: This means all 
> DMA
> +  fences must complete before a compute job with page fault handling can be
> +  inserted into the scheduler queue. And vice versa, before a DMA fence can 
> be
> +  made visible anywhere in the system, all compute workloads must be 
> preempted
> +  to guarantee all pending GPU page faults are flushed.
> +
> +Note that workloads that run on independent hardware like copy engines or 
> other
> +GPUs do not have any impact. This allows us to keep using DMA fences 
> internally
> +in the kernel even for resolvin

Re: [PATCH v4 1/3] drm/uapi: Add USB connector type

[Noralf Trønnes]

Den 22.01.2021 15.55, skrev Thomas Zimmermann:
> Hi
> 
> Am 22.01.21 um 15:35 schrieb Noralf Trønnes:
>>
>>
>> Den 22.01.2021 13.47, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 22.01.21 um 12:44 schrieb Noralf Trønnes:

 And wrt PCI it wouldn't be a PCI connector if the card has some other
 connector for the display, but if it was possible to connect a display
 directly to the PCI connector, then yes I would call that a PCI
 connector.
>>>
>>> You're not connecting a display to the computer. You're connecting an
>>> RPi and then connect the display to the RPi. The RPi acts like an
>>> external graphics card.
>>>
 This begs the question: Why does the kernel provide info to userspace
 about the connector type?

 My take is that it is so the user can know which display is
 connected to
 which port on the computer.
>>>
>>> This exactly illustrates the problem with the current naming. For a
>>> single output the distinction between bus and connector might be fuzzy.
>>> As soon as a connected SoC contains multiple connectors. The user then
>>> sees names such as card1-USB-0 and card1-USB-1, which makes no sense.
>>>
>>
>> If you look at the code I pasted in, you'll see that the SoC connector
>> types are passed through to the host driver as-is unless they are panel
>> connectors like DSI/DPI, which will be interpreted as USB (the protocol
>> does support multiple connectors, but only one can be used at a time).
>>
>> So for the Pi4 as a display adapter, the host will see card1-HDMI-0 and
>> card1-HDMI-1, the same is true for the composite output (if enabled) it
>> shows up as card1-Composite-0 (can't be enabled together with HDMI).
>>
>> If the Pi4 is used together with a DSI connected touchscreen, it makes
>> sense to disable the SoC HDMI outputs and the host only will see the
>> board as card1-USB-0 (I haven't done this exercise yet since there's
>> problems with getting the official Pi touchscreen to work with vc4 on
>> Pi4).
> 
> I saw that. I can even get your point about using USB for panel (still
> don't agree). But you're also using USB as default case.
> 

In the host driver the default case is to catch future additions to the
protocol. In this case the driver doesn't know the connector type, but
by using USB at least the user knows where to look.

On the gadget side these are the current types that will hit the default
case:

These are panels:
DRM_MODE_CONNECTOR_LVDS
DRM_MODE_CONNECTOR_eDP
DRM_MODE_CONNECTOR_DSI
DRM_MODE_CONNECTOR_DPI
DRM_MODE_CONNECTOR_SPI

This also seems to be used primarily by panels:
DRM_MODE_CONNECTOR_Unknown

Only used by i915, amd, radeon, very unlikely on a gadget:
DRM_MODE_CONNECTOR_9PinDIN

This one I should probably map to GUD_CONNECTOR_TYPE_COMPOSITE:
DRM_MODE_CONNECTOR_TV

Very unlikely on a gadget:
DRM_MODE_CONNECTOR_VIRTUAL

Future connector types will also be reported in the protocol as
GUD_CONNECTOR_TYPE_PANEL and thus on the host as DRM_MODE_CONNECTOR_USB.
The gadget driver will ofc be updated when new non-panel connector types
show up.

And this makes sense to me :-)

Giving the user a connector named "Unknown-1" does not make sense to me.

Noralf.


> Best regards
> Thomas
> 
>>
>> The USB connector type is most important for tiny displays that is
>> microcontroller based without Linux running. There are lots of tiny SPI
>> displays and I expect this market to shift towards USB because it much
>> easier to connect and the display will be useable on a desktop/server
>> computer as status displays perhaps. But embedded will also benefit from
>> having these displays USB interfaced.
>>
>> Another use case I see is repurposing old Android tablets as USB
>> displays that can be connected to any computer and become a touchscreen.
>> In this case I also want the connector to be called card1-USB-0 (I
>> haven't done any work in this area, old Android is fbdev so some work is
>> needed for this to happen).
>>
>> Noralf.
>>

 What's your opinion?

>>
>> Ofc as Daniel mentions it's a downside that userspace doesn't know
>> about
>> the connector type, and who knows when it will updated (if I don't do
>> it).
>> Weston will name it: "UNNAMED-%d"
>> Mutter: "Unknown%d-%d"
>> X: "Unknown%d-%d"
>>
>> Sam and Laurent has discussed adding a PANEL connector type
>> instead of
>> adding more connector types for panel connectors. I think that would
>> have been a better choice instead of the SPI connector type that I
>> added
>> in 2019. But I think PANEL was meant for panels connected to an
>> internal
>> connector.
>>
>> Here's my protocol connector types and how it's mapped to DRM:
>>
>> #define GUD_CONNECTOR_TYPE_PANEL    0
>> #define GUD_CONNECTOR_TYPE_VGA    1
>> #define GUD_CONNECTOR_TYPE_COMPOSITE    2
>> #define GUD_CONNECTOR_TYPE_SVIDEO    3
>> #define GUD_CONNECTOR_TYPE_COMPONENT    4
>> #def

Re: [PATCH 2/2] drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work

[Chen, Xiaogang]

On 1/19/2021 4:29 PM, Grodzovsky, Andrey wrote:

On 1/15/21 2:21 AM, Chen, Xiaogang wrote:
On 1/14/2021 1:24 AM, Grodzovsky, Andrey wrote:

On 1/14/21 12:11 AM, Chen, Xiaogang wrote:
On 1/12/2021 10:54 PM, Grodzovsky, Andrey wrote:
On 1/4/21 1:01 AM, Xiaogang.Chen wrote:
From: Xiaogang Chen 

amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd, hpd_rx) by
using work queue and uses single work_struct. If previous interrupt
has not been handled new interrupts(same type) will be discarded and
driver just sends "amdgpu_dm_irq_schedule_work FAILED" message out.
If some important hpd, hpd_rx related interrupts are missed by driver
the hot (un)plug devices may cause system hang or unstable, such as
system resumes from S3 sleep with mst device connected.

This patch dynamically allocates new amdgpu_dm_irq_handler_data for
new interrupts if previous INTERRUPT_LOW_IRQ_CONTEXT interrupt work
has not been handled. So the new interrupt works can be queued to the
same workqueue_struct, instead discard the new interrupts.
All allocated amdgpu_dm_irq_handler_data are put into a single linked
list and will be reused after.

I believe this creates a possible concurrency between already
executing work item
and the new incoming one for which you allocate a new work item on
the fly. While
handle_hpd_irq is serialized with aconnector->hpd_lock I am seeing
that for handle_hpd_rx_irq
it's not locked for MST use case (which is the most frequently used
with this interrupt).  Did you
verified that handle_hpd_rx_irq is reentrant ?

handle_hpd_rx_irq is put at a work queue. Its execution is serialized
by the work queue. So there is no reentrant.

You are using system_highpri_wq which has the property that it has
multiple workers thread pool spread across all the
active CPUs, see all work queue definitions here
https://elixir.bootlin.com/linux/v5.11-rc3/source/include/linux/workqueue.h#L358
I beleieve that what you saying about no chance of reentrnacy would be
correct if it would be same work item dequeued for execution
while previous instance is still running, see the explanation here -
https://elixir.bootlin.com/linux/v5.11-rc3/source/kernel/workqueue.c#L1435.
Non reentrancy is guaranteed only for the same work item. If you want
non reentrancy (full serializtion) for different work items you should
create
you own single threaded work-queue using create_singlethread_workqueue


Thank you. I think the easiest way is using aconnector->hpd_lock at
handle_hpd_rx_irq to lock for dc_link->type == dc_connection_mst_branch
case, right? I will do that at next version if you think it is ok.


I am not sure what are the consequences of of using hpd lock there with
regard to other locks acquired in DRM MST code during MST related HPD 
transactions since
i haven't dealt with this for a very long time. Maybe Harry or Nick can advise 
on this ?

Andrey


Hi Harry, Nick: would you or someone give review on this patch?

Thanks

Xiaogang

amdgpu_dm_irq_schedule_work does queuing of work(put
handle_hpd_rx_irq into work queue). The first call is
dm_irq_work_func, then call handle_hpd_rx_irq.
Signed-off-by: Xiaogang Chen 

---
   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  14 +--
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  | 114
++---
   2 files changed, 80 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index c9d82b9..730e540 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -69,18 +69,6 @@ struct common_irq_params {
   };
 /**
- * struct irq_list_head - Linked-list for low context IRQ handlers.
- *
- * @head: The list_head within &struct handler_data
- * @work: A work_struct containing the deferred handler work
- */
-struct irq_list_head {
-struct list_head head;
-/* In case this interrupt needs post-processing, 'work' will
be queued*/
-struct work_struct work;
-};
-
-/**
* struct dm_compressor_info - Buffer info used by frame buffer
compression
* @cpu_addr: MMIO cpu addr
* @bo_ptr: Pointer to the buffer object
@@ -270,7 +258,7 @@ struct amdgpu_display_manager {
* Note that handlers are called in the same order as they were
* registered (FIFO).
*/
-struct irq_list_head
irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];
+struct list_head
irq_handler_list_low_tab[DAL_IRQ_SOURCES_NUMBER];
 /**
* @irq_handler_list_high_tab:
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
index 3577785..ada344a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
@@ -82,6 +82,7 @@ struct amdgpu_dm_irq_handler_data {
   struct amdgpu_display_manager *dm;
   /* DAL irq source which

Re: [RESEND][PATCH 2/3] dma-buf: heaps: Add a WARN_ON should the vmap_cnt go negative

[John Stultz]

On Fri, Jan 22, 2021 at 2:21 PM Suren Baghdasaryan  wrote:
> On Thu, Jan 21, 2021 at 11:56 PM Sumit Semwal  wrote:
> > On Wed, 20 Jan 2021 at 02:15, John Stultz  wrote:
> > >
> > > We shouldn't vunmap more then we vmap, but if we do, make
> > > sure we complain loudly.
> >
> > I was checking the general usage of vunmap in the kernel, and I
> > couldn't find many instances where we need to WARN_ON for the vunmap
> > count more than vmap count. Is there a specific need for this in the heaps?
>
> Hi Sumit,
> My worry was that buffer->vmap_cnt could silently go negative. But if
> this warning is not consistent with other places we do refcounted
> vmap/vunmap then feel free to ignore my suggestion.
>

Yea,
 My sense is that it didn't seem like it would hurt, and if the
warning happened to be tripped, it would be good to catch.

However, if you are skeptical, feel free to drop that patch from this
series for now (it shouldn't impact the following patches).

thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 2/3] dma-buf: system_heap: Add pagepool support to system heap

[John Stultz]

On Mon, Dec 21, 2020 at 2:09 PM Daniel Vetter  wrote:
>
> On Fri, Dec 18, 2020 at 05:16:56PM -0800, John Stultz wrote:
> > On Fri, Dec 18, 2020 at 6:36 AM Daniel Vetter  wrote:
> > > On Thu, Dec 17, 2020 at 11:06:11PM +, John Stultz wrote:
> > > > Reuse/abuse the pagepool code from the network code to speed
> > > > up allocation performance.
> > > >
> > > > This is similar to the ION pagepool usage, but tries to
> > > > utilize generic code instead of a custom implementation.
> > >
> > > We also have one of these in ttm. I think we should have at most one of
> > > these for the gpu ecosystem overall, maybe as a helper that can be plugged
> > > into all the places.
> > >
> > > Or I'm kinda missing something, which could be since I only glanced at
> > > yours for a bit. But it's also called page pool for buffer allocations,
> > > and I don't think there's that many ways to implement that really :-)
> >
> > Yea, when I was looking around the ttm one didn't seem quite as
> > generic as the networking one, which more easily fit in here.
>
> Oops, I didn't look that closely and didn't realize you're reusing the one
> from net/core/.
>
> > The main benefit for the system heap is not so much the pool itself
> > (the normal page allocator is pretty good), as it being able to defer
> > the free and zero the pages in a background thread, so the pool is
> > effectively filled with pre-zeroed pages.
> >
> > But I'll take another look at the ttm implementation and see if it can
> > be re-used or the shared code refactored and pulled out somehow.
>
> I think moving the page_pool from net into lib and using it in ttm might
> also be an option. Lack of shrinker in the networking one might be a bit a
> problem.

Yea. I've been looking at this, to see how to abstract out a generic
pool implementation, but each pool implementation has been tweaked for
the specific use cases, so a general abstraction is a bit tough right
off.

For example the ttm pool's handling allocations both from alloc_pages
and dma_alloc in a pool, where the net page pool only uses alloc_pages
(but can pre map via dma_map_attr).

And as you mentioned, the networking page pool is statically sized
where the ttm pool is dynamic and shrinker controlled.

Further, as the ttm pool is utilized for keeping pools of pages set
for specific cache types, it makes it difficult to abstract that out
as we have to be able to reset the caching (set_pages_wb()) when
shrinking, so that would also have to be pushed down into the pool
attributes as well.

So far, in my attempts to share an abstraction for both the net
page_pool and the ttm page pool, it seems to make the code complexity
worse on both sides -  so while I'm interested in continuing to try to
find a way to share code here, I'm not sure it makes sense to hold up
this series (which is already re-using an existing implementation and
provide a performance bump in microbenchmarks) for the
grand-unified-page-pool. Efforts to refactor the ttm pool and net page
pool can continue on indepently, and I'd be happy to move the system
heap to whatever that ends up being.

thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] dma-buf: heaps: Add deferred-free-helper library code

[John Stultz]

This patch provides infrastructure for deferring buffer frees.

This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
page-zeroing to be done out of the normal allocation/free path,
and pushed off to a kthread.

As not all heaps will find this useful, its implemented as
a optional helper library that heaps can utilize.

Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
  to a spinlock as Reported-by: kernel test robot 
* Cleanup API to use a reason enum for clarity and add some documentation
  comments as suggested by Suren Baghdasaryan.
---
 drivers/dma-buf/heaps/Kconfig|   3 +
 drivers/dma-buf/heaps/Makefile   |   1 +
 drivers/dma-buf/heaps/deferred-free-helper.c | 136 +++
 drivers/dma-buf/heaps/deferred-free-helper.h |  55 
 4 files changed, 195 insertions(+)
 create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c
 create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..ecf65204f714 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -1,3 +1,6 @@
+config DMABUF_HEAPS_DEFERRED_FREE
+   bool
+
 config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..4e7839875615 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_HEAPS_DEFERRED_FREE) += deferred-free-helper.o
 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)  += system_heap.o
 obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/deferred-free-helper.c 
b/drivers/dma-buf/heaps/deferred-free-helper.c
new file mode 100644
index ..cf04148167a2
--- /dev/null
+++ b/drivers/dma-buf/heaps/deferred-free-helper.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Deferred dmabuf freeing helper
+ *
+ * Copyright (C) 2020 Linaro, Ltd.
+ *
+ * Based on the ION page pool code
+ * Copyright (C) 2011 Google, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "deferred-free-helper.h"
+
+static LIST_HEAD(free_list);
+static size_t list_size;
+wait_queue_head_t freelist_waitqueue;
+struct task_struct *freelist_task;
+static DEFINE_SPINLOCK(free_list_lock);
+
+void deferred_free(struct deferred_freelist_item *item,
+  void (*free)(struct deferred_freelist_item*,
+   enum df_reason),
+  size_t size)
+{
+   unsigned long flags;
+
+   INIT_LIST_HEAD(&item->list);
+   item->size = size;
+   item->free = free;
+
+   spin_lock_irqsave(&free_list_lock, flags);
+   list_add(&item->list, &free_list);
+   list_size += size;
+   spin_unlock_irqrestore(&free_list_lock, flags);
+   wake_up(&freelist_waitqueue);
+}
+
+static size_t free_one_item(enum df_reason reason)
+{
+   unsigned long flags;
+   size_t size = 0;
+   struct deferred_freelist_item *item;
+
+   spin_lock_irqsave(&free_list_lock, flags);
+   if (list_empty(&free_list)) {
+   spin_unlock_irqrestore(&free_list_lock, flags);
+   return 0;
+   }
+   item = list_first_entry(&free_list, struct deferred_freelist_item, 
list);
+   list_del(&item->list);
+   size = item->size;
+   list_size -= size;
+   spin_unlock_irqrestore(&free_list_lock, flags);
+
+   item->free(item, reason);
+   return size;
+}
+
+static unsigned long get_freelist_size(void)
+{
+   unsigned long size;
+   unsigned long flags;
+
+   spin_lock_irqsave(&free_list_lock, flags);
+   size = list_size;
+   spin_unlock_irqrestore(&free_list_lock, flags);
+   return size;
+}
+
+static unsigned long freelist_shrink_count(struct shrinker *shrinker,
+  struct shrink_control *sc)
+{
+   return get_freelist_size();
+}
+
+static unsigned long freelist_shrink_scan(struct shrinker *shrinker,
+ struct shrink_control *sc)
+{
+   int total_freed = 0;
+
+   if (sc->nr_to_scan == 0)
+   return 0;
+
+   while (total_freed < sc->nr_to_scan) {
+   int freed = free_one_item(DF_UNDER_PRESSURE);
+
+   if (!freed)
+   break;
+

[PATCH v2 2/3] dma-buf: system_heap: Add pagepool support to system heap

[John Stultz]

Reuse/abuse the pagepool code from the network code to speed
up allocation performance.

This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.

Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2:
* Fix build issue caused by selecting PAGE_POOL w/o NET
  as Reported-by: kernel test robot 
---
 drivers/dma-buf/heaps/Kconfig   |  2 +
 drivers/dma-buf/heaps/system_heap.c | 68 +++--
 2 files changed, 66 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index ecf65204f714..748e840e6edd 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,6 +4,8 @@ config DMABUF_HEAPS_DEFERRED_FREE
 config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
+   select NET
+   select PAGE_POOL
help
  Choose this option to enable the system dmabuf heap. The system heap
  is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index 17e0e9a68baf..885e30894b77 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static struct dma_heap *sys_heap;
 
@@ -53,6 +54,7 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, 
LOW_ORDER_GFP};
  */
 static const unsigned int orders[] = {8, 4, 0};
 #define NUM_ORDERS ARRAY_SIZE(orders)
+struct page_pool *pools[NUM_ORDERS];
 
 static struct sg_table *dup_sg_table(struct sg_table *table)
 {
@@ -281,18 +283,59 @@ static void system_heap_vunmap(struct dma_buf *dmabuf, 
struct dma_buf_map *map)
dma_buf_map_clear(map);
 }
 
+static int system_heap_clear_pages(struct page **pages, int num, pgprot_t 
pgprot)
+{
+   void *addr = vmap(pages, num, VM_MAP, pgprot);
+
+   if (!addr)
+   return -ENOMEM;
+   memset(addr, 0, PAGE_SIZE * num);
+   vunmap(addr);
+   return 0;
+}
+
+static int system_heap_zero_buffer(struct system_heap_buffer *buffer)
+{
+   struct sg_table *sgt = &buffer->sg_table;
+   struct sg_page_iter piter;
+   struct page *pages[32];
+   int p = 0;
+   int ret = 0;
+
+   for_each_sgtable_page(sgt, &piter, 0) {
+   pages[p++] = sg_page_iter_page(&piter);
+   if (p == ARRAY_SIZE(pages)) {
+   ret = system_heap_clear_pages(pages, p, PAGE_KERNEL);
+   if (ret)
+   return ret;
+   p = 0;
+   }
+   }
+   if (p)
+   ret = system_heap_clear_pages(pages, p, PAGE_KERNEL);
+
+   return ret;
+}
+
 static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
 {
struct system_heap_buffer *buffer = dmabuf->priv;
struct sg_table *table;
struct scatterlist *sg;
-   int i;
+   int i, j;
+
+   /* Zero the buffer pages before adding back to the pool */
+   system_heap_zero_buffer(buffer);
 
table = &buffer->sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
 
-   __free_pages(page, compound_order(page));
+   for (j = 0; j < NUM_ORDERS; j++) {
+   if (compound_order(page) == orders[j])
+   break;
+   }
+   page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
@@ -322,8 +365,7 @@ static struct page *alloc_largest_available(unsigned long 
size,
continue;
if (max_order < orders[i])
continue;
-
-   page = alloc_pages(order_flags[i], orders[i]);
+   page = page_pool_alloc_pages(pools[i], order_flags[i]);
if (!page)
continue;
return page;
@@ -428,6 +470,24 @@ static const struct dma_heap_ops system_heap_ops = {
 static int system_heap_create(void)
 {
struct dma_heap_export_info exp_info;
+   int i;
+
+   for (i = 0; i < NUM_ORDERS; i++) {
+   struct page_pool_params pp;
+
+   memset(&pp, 0, sizeof(pp));
+   pp.order = orders[i];
+   pools[i] = page_pool_create(&pp);
+
+   if (IS_ERR(pools[i])) {
+   int j;
+
+   pr_err("%s: page pool creation failed!\n", __func__);
+   for (j = 0; j < i; j++)
+ 

[PATCH v2 3/3] dma-buf: system_heap: Add deferred freeing to the system heap

[John Stultz]

Utilize the deferred free helper library in the system heap.

This provides a nice performance bump and puts the
system heap performance on par with ION.

Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2:
* Rework deferred-free api to use reason enum as suggested by
  Suren Baghdasaryan
---
 drivers/dma-buf/heaps/Kconfig   |  1 +
 drivers/dma-buf/heaps/system_heap.c | 32 ++---
 2 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 748e840e6edd..3f4d7b949301 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -6,6 +6,7 @@ config DMABUF_HEAPS_SYSTEM
depends on DMABUF_HEAPS
select NET
select PAGE_POOL
+   select DMABUF_HEAPS_DEFERRED_FREE
help
  Choose this option to enable the system dmabuf heap. The system heap
  is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c 
b/drivers/dma-buf/heaps/system_heap.c
index 885e30894b77..747fa2250e84 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 
+#include "deferred-free-helper.h"
+
 static struct dma_heap *sys_heap;
 
 struct system_heap_buffer {
@@ -32,6 +34,7 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+   struct deferred_freelist_item deferred_free;
 };
 
 struct dma_heap_attachment {
@@ -317,30 +320,45 @@ static int system_heap_zero_buffer(struct 
system_heap_buffer *buffer)
return ret;
 }
 
-static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+static void system_heap_buf_free(struct deferred_freelist_item *item,
+enum df_reason reason)
 {
-   struct system_heap_buffer *buffer = dmabuf->priv;
+   struct system_heap_buffer *buffer;
struct sg_table *table;
struct scatterlist *sg;
int i, j;
 
+   buffer = container_of(item, struct system_heap_buffer, deferred_free);
/* Zero the buffer pages before adding back to the pool */
-   system_heap_zero_buffer(buffer);
+   if (reason == DF_NORMAL)
+   if (system_heap_zero_buffer(buffer))
+   reason = DF_UNDER_PRESSURE; // On failure, just free
 
table = &buffer->sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
 
-   for (j = 0; j < NUM_ORDERS; j++) {
-   if (compound_order(page) == orders[j])
-   break;
+   if (reason == DF_UNDER_PRESSURE) {
+   __free_pages(page, compound_order(page));
+   } else {
+   for (j = 0; j < NUM_ORDERS; j++) {
+   if (compound_order(page) == orders[j])
+   break;
+   }
+   page_pool_put_full_page(pools[j], page, false);
}
-   page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
 }
 
+static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+{
+   struct system_heap_buffer *buffer = dmabuf->priv;
+
+   deferred_free(&buffer->deferred_free, system_heap_buf_free, 
buffer->len);
+}
+
 static const struct dma_buf_ops system_heap_buf_ops = {
.attach = system_heap_attach,
.detach = system_heap_detach,
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel