[PATCH 1/1] drm/bochs: Fix connector leak during driver unload

[Sam Bobroff]

When unloading the bochs-drm driver, a warning message is printed by
drm_mode_config_cleanup() because a reference is still held to one of
the drm_connector structs.

Correct this by calling drm_atomic_helper_shutdown() in
bochs_pci_remove().

The issue is caused by the interaction of two previous commits. Both
together are required to cause it:
Fixes: 846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in 
drm_atomic_remove_fb, v2.")
Fixes: 6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up 
helpers.")

Signed-off-by: Sam Bobroff 
---
Hello,

This seems to be similar to an issue I recently fixed for the AST driver:
1e613f3c630c ("drm/ast: Fix connector leak during driver unload")
Which is similar to at least one other recent fix:
192b4af6cd28 ("drm/tegra: Shutdown on driver unbind")

The fix seems to be the same, but this time I've tried to dig a little deeper
and use an appropriate Fixes tag to assist backporting.

Bisecting the issue for commits to drivers/gpu/drm/bochs/ points to:
6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up helpers.")
... but the issue also seems to be due to a change in the generic drm code
(reverting it separately fixes the issue):
846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in 
drm_atomic_remove_fb, v2.")
... so I've included both in the commit.  Is that the right thing to do?

I couldn't help wondering if we should also update the comment for
drm_fbdev_generic_setup(), because it says:
"The fbdev is destroyed by drm_dev_unregister()"
... which implies to me that cleanup only requires that call, but actually
since 846c7dfc1193 you will always(?) need to use drm_atomic_helper_shutdown()
as well. (Is it actually always the case?)

Cheers,
Sam.

 drivers/gpu/drm/bochs/bochs_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 6b6e037258c3..7031f0168795 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "bochs.h"
 
@@ -174,6 +175,7 @@ static void bochs_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
 
+   drm_atomic_helper_shutdown(dev);
drm_dev_unregister(dev);
bochs_unload(dev);
drm_dev_put(dev);
-- 
2.19.0.2.gcad72f5712

[PATCH 1/1] drm/i915: remove unused IO_TLB_SEGPAGES which should be defined by swiotlb

[Dongli Zhang]

This patch removes IO_TLB_SEGPAGES which is no longer used since
commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").

As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
IO_TLB_SEGPAGES should be defined on swiotlb side if it is required in the
future.

Signed-off-by: Dongli Zhang 
---
 drivers/gpu/drm/i915/i915_gem_internal.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c 
b/drivers/gpu/drm/i915/i915_gem_internal.c
index ab627ed..2166217 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -28,9 +28,6 @@
 #define QUIET (__GFP_NORETRY | __GFP_NOWARN)
 #define MAYFAIL (__GFP_RETRY_MAYFAIL | __GFP_NOWARN)
 
-/* convert swiotlb segment size into sensible units (pages)! */
-#define IO_TLB_SEGPAGES (IO_TLB_SEGSIZE << IO_TLB_SHIFT >> PAGE_SHIFT)
-
 static void internal_free_pages(struct sg_table *st)
 {
struct scatterlist *sg;
-- 
2.7.4

[radeon-alex:drm-next-5.3-wip 159/169] drivers/gpu/drm/panfrost/panfrost_job.c:390:3: error: too few arguments to function 'drm_sched_stop'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-5.3-wip
head:   8dcf1d70d7d7058b54e1356297f201cb7ba6d14f
commit: 399abb79bbdece4bdcb35a5f2983b2335410eeec [159/169] drm/scheduler: 
rework job destruction
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 399abb79bbdece4bdcb35a5f2983b2335410eeec
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=riscv 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/panfrost/panfrost_job.c: In function 'panfrost_job_timedout':
>> drivers/gpu/drm/panfrost/panfrost_job.c:390:3: error: too few arguments to 
>> function 'drm_sched_stop'
  drm_sched_stop(>js->queue[i].sched);
  ^~
   In file included from drivers/gpu/drm/panfrost/panfrost_job.c:10:
   include/drm/gpu_scheduler.h:295:6: note: declared here
void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job 
*bad);
 ^~

vim +/drm_sched_stop +390 drivers/gpu/drm/panfrost/panfrost_job.c

f3ba9122 Rob Herring  2018-09-10  365  
f3ba9122 Rob Herring  2018-09-10  366  static void panfrost_job_timedout(struct 
drm_sched_job *sched_job)
f3ba9122 Rob Herring  2018-09-10  367  {
f3ba9122 Rob Herring  2018-09-10  368   struct panfrost_job *job = 
to_panfrost_job(sched_job);
f3ba9122 Rob Herring  2018-09-10  369   struct panfrost_device *pfdev = 
job->pfdev;
f3ba9122 Rob Herring  2018-09-10  370   int js = panfrost_job_get_slot(job);
f3ba9122 Rob Herring  2018-09-10  371   int i;
f3ba9122 Rob Herring  2018-09-10  372  
f3ba9122 Rob Herring  2018-09-10  373   /*
f3ba9122 Rob Herring  2018-09-10  374* If the GPU managed to complete this 
jobs fence, the timeout is
f3ba9122 Rob Herring  2018-09-10  375* spurious. Bail out.
f3ba9122 Rob Herring  2018-09-10  376*/
f3ba9122 Rob Herring  2018-09-10  377   if 
(dma_fence_is_signaled(job->done_fence))
f3ba9122 Rob Herring  2018-09-10  378   return;
f3ba9122 Rob Herring  2018-09-10  379  
f3ba9122 Rob Herring  2018-09-10  380   dev_err(pfdev->dev, "gpu sched timeout, 
js=%d, status=0x%x, head=0x%x, tail=0x%x, sched_job=%p",
f3ba9122 Rob Herring  2018-09-10  381   js,
f3ba9122 Rob Herring  2018-09-10  382   job_read(pfdev, JS_STATUS(js)),
f3ba9122 Rob Herring  2018-09-10  383   job_read(pfdev, JS_HEAD_LO(js)),
f3ba9122 Rob Herring  2018-09-10  384   job_read(pfdev, JS_TAIL_LO(js)),
f3ba9122 Rob Herring  2018-09-10  385   sched_job);
f3ba9122 Rob Herring  2018-09-10  386  
aa202367 Tomeu Vizoso 2019-04-18  387   mutex_lock(>reset_lock);
aa202367 Tomeu Vizoso 2019-04-18  388  
f3ba9122 Rob Herring  2018-09-10  389   for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring  2018-09-10 @390   
drm_sched_stop(>js->queue[i].sched);
f3ba9122 Rob Herring  2018-09-10  391  
f3ba9122 Rob Herring  2018-09-10  392   if (sched_job)
f3ba9122 Rob Herring  2018-09-10  393   
drm_sched_increase_karma(sched_job);
f3ba9122 Rob Herring  2018-09-10  394  
f3ba9122 Rob Herring  2018-09-10  395   /* panfrost_core_dump(pfdev); */
f3ba9122 Rob Herring  2018-09-10  396  
f3ba9122 Rob Herring  2018-09-10  397   
panfrost_devfreq_record_transition(pfdev, js);
f3ba9122 Rob Herring  2018-09-10  398   panfrost_gpu_soft_reset(pfdev);
f3ba9122 Rob Herring  2018-09-10  399  
f3ba9122 Rob Herring  2018-09-10  400   /* TODO: Re-enable all other address 
spaces */
f3ba9122 Rob Herring  2018-09-10  401   panfrost_mmu_enable(pfdev, 0);
f3ba9122 Rob Herring  2018-09-10  402   panfrost_gpu_power_on(pfdev);
f3ba9122 Rob Herring  2018-09-10  403   panfrost_job_enable_interrupts(pfdev);
f3ba9122 Rob Herring  2018-09-10  404  
f3ba9122 Rob Herring  2018-09-10  405   for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring  2018-09-10  406   
drm_sched_resubmit_jobs(>js->queue[i].sched);
f3ba9122 Rob Herring  2018-09-10  407  
f3ba9122 Rob Herring  2018-09-10  408   /* restart scheduler after GPU is 
usable again */
f3ba9122 Rob Herring  2018-09-10  409   for (i = 0; i < NUM_JOB_SLOTS; i++)
f3ba9122 Rob Herring  2018-09-10  410   
drm_sched_start(>js->queue[i].sched, true);
aa202367 Tomeu Vizoso 2019-04-18  411  
aa202367 Tomeu Vizoso 2019-04-18  412   mutex_unlock(>reset_lock);
f3ba9122 Rob Herring  2018-09-10  413  }
f3ba9122 Rob Herring  2018-09-10  414  

:: The code at line 390 was first introduced by commit
:: f3ba91228e8e917e5bd6c4b72bfe846933d17370 drm/panfrost: Add initial 
panfrost driver

:: TO: Rob Herring 
:: CC: Rob Herring 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz

Re: [PATCH] gpu: drm: use struct_size() in kmalloc()

[Alex Deucher]

On Mon, May 20, 2019 at 7:19 PM Pan, Xinhui  wrote:
>
> Daniel, what you are talking about is totally wrong.
> 1) AFAIK, only one zero-size array can be in the end of a struct.
> 2) two struct_size will add up struct itself twice. the sum is wrong then.
>
> No offense. I can't help feeling lucky that you are in intel.

Xinhui,

Please keep things civil.  There is no need for comments like this.

Alex

>
>
> 发件人: Daniel Vetter  代表 Daniel Vetter 
> 发送时间: 2019年5月21日 0:28
> 收件人: Pan, Xinhui
> 抄送: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); 
> airl...@linux.ie; dan...@ffwll.ch; Quan, Evan; xiaolinkui; 
> amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
> linux-ker...@vger.kernel.org
> 主题: Re: [PATCH] gpu: drm: use struct_size() in kmalloc()
>
> [CAUTION: External Email]
>
> On Fri, May 17, 2019 at 04:44:30PM +, Pan, Xinhui wrote:
> > I am going to put more members which are also array after this struct,
> > not only obj[].  Looks like this struct_size did not help on multiple
> > array case. Thanks anyway.  
>
> You can then add them up, e.g. kmalloc(struct_size()+struct_size(),
> GFP_KERNEL), so this patch here still looks like a good idea.
>
> Reviewed-by: Daniel Vetter 
>
> Cheers, Daniel
>
> > From: xiaolinkui 
> > Sent: Friday, May 17, 2019 4:46:00 PM
> > To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); 
> > airl...@linux.ie; dan...@ffwll.ch; Pan, Xinhui; Quan, Evan
> > Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
> > linux-ker...@vger.kernel.org; xiaolin...@kylinos.cn
> > Subject: [PATCH] gpu: drm: use struct_size() in kmalloc()
> >
> > [CAUTION: External Email]
> >
> > Use struct_size() helper to keep code simple.
> >
> > Signed-off-by: xiaolinkui 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> > index 22bd21e..4717a64 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> > @@ -1375,8 +1375,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev)
> > if (con)
> > return 0;
> >
> > -   con = kmalloc(sizeof(struct amdgpu_ras) +
> > -   sizeof(struct ras_manager) * AMDGPU_RAS_BLOCK_COUNT,
> > +   con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
> > GFP_KERNEL|__GFP_ZERO);
> > if (!con)
> > return -ENOMEM;
> > --
> > 2.7.4
> >
> >
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  Documentation/devicetree/bindings/vendor-prefixes.txt

between commit:

  8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")

from Linus' tree and commits:

  b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
  b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC 
S9700RTWV43TR-01B")
  fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")

from the drm-misc tree.

I fixed it up (I deleted the file and added the patch below) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

From: Stephen Rothwell 
Date: Tue, 21 May 2019 10:48:36 +1000
Subject: [PATCH] dt-bindings: fix up for vendor prefixes file conversion

Signed-off-by: Stephen Rothwell 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 83ca4816a78b..749e3c3843d0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -287,6 +287,8 @@ patternProperties:
 description: Everest Semiconductor Co. Ltd.
   "^everspin,.*":
 description: Everspin Technologies, Inc.
+  "^evervision,.*":
+description: Evervision Electronics Co. Ltd.
   "^exar,.*":
 description: Exar Corporation
   "^excito,.*":
@@ -851,6 +853,8 @@ patternProperties:
 description: Shenzhen Techstar Electronics Co., Ltd.
   "^terasic,.*":
 description: Terasic Inc.
+  "^tfc,.*":
+description: Three Five Corp
   "^thine,.*":
 description: THine Electronics, Inc.
   "^ti,.*":
@@ -925,6 +929,8 @@ patternProperties:
 description: Voipac Technologies s.r.o.
   "^vot,.*":
 description: Vision Optical Technology Co., Ltd.
+  "^vxt,.*"
+description: VXT Ltd
   "^wd,.*":
 description: Western Digital Corp.
   "^wetek,.*":
-- 
2.20.1


pgpm3sMGbppML.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the drm-misc tree with the amdgpu tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

between commit:

  56965ce261af ("drm/amdgpu: cancel late_init_work before gpu reset")

from the amdgpu tree and commit:

  1d721ed679db ("drm/amdgpu: Avoid HW reset if guilty job already signaled.")

from the drm-misc tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c9024f92e203,b9371ec5e04f..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@@ -3614,28 -3538,27 +3595,28 @@@ int amdgpu_device_gpu_recover(struct am
  
dev_info(adev->dev, "GPU reset begin!\n");
  
 +  cancel_delayed_work_sync(>late_init_work);
+   hive = amdgpu_get_xgmi_hive(adev, false);
  
/*
-* In case of XGMI hive disallow concurrent resets to be triggered
-* by different nodes. No point also since the one node already 
executing
-* reset will also reset all the other nodes in the hive.
+* Here we trylock to avoid chain of resets executing from
+* either trigger by jobs on different adevs in XGMI hive or jobs on
+* different schedulers for same device while this TO handler is 
running.
+* We always reset all schedulers for device and all devices for XGMI
+* hive so that should take care of them too.
 */
-   hive = amdgpu_get_xgmi_hive(adev, 0);
-   if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
-   !mutex_trylock(>reset_lock))
+ 
+   if (hive && !mutex_trylock(>reset_lock)) {
+   DRM_INFO("Bailing on TDR for s_job:%llx, hive: %llx as another 
already in progress",
+job->base.id, hive->hive_id);
return 0;
+   }
  
/* Start with adev pre asic reset first for soft reset check.*/
-   amdgpu_device_lock_adev(adev);
-   r = amdgpu_device_pre_asic_reset(adev,
-job,
-_full_reset);
-   if (r) {
-   /*TODO Should we stop ?*/
-   DRM_ERROR("GPU pre asic reset failed with err, %d for drm dev, 
%s ",
- r, adev->ddev->unique);
-   adev->asic_reset_res = r;
+   if (!amdgpu_device_lock_adev(adev, !hive)) {
+   DRM_INFO("Bailing on TDR for s_job:%llx, as another already in 
progress",
+job->base.id);
+   return 0;
}
  
/* Build list of devices to reset */


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

Re: [Intel-gfx] [PATCH] drm: Allow modeset on unregisted connectors unconditionally

[Imre Deak]

On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> We allowed modesetting an unregistered connector only in the case the
> mode is getting disabled on the connector.
> 
> The reason for this check was the lack of proper refcounting for the
> backing memory objects. That problem has been solved meanwhile so there
> is no reason any more to reject the modesetting in general. The check
> for that also makes driver internal modesets more cumbersome where we
> need to add exemptions for the cases where we do need to allow the
> modeset even for unregistered connectors. One such case is the
> restoration of the mode during resume.
> 
> Simplify things by removing the unneeded check. I can't see how
> modesetting an unregistered connector can cause any problem and the race
> (described in the code comment) can anyway result in such a modeset (if
> the connector is unregistered right after the check).
> 
> Cc: Lyude Paul 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 

Lyude, could you test this change against the DDX fail scenario that the
check was added for originally (based on our IRC discussion)?

Thanks,
Imre

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
>  1 file changed, 2 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2e0cb4246cbd..e94e69483498 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state *state,
>   return 0;
>   }
>  
> - crtc_state = drm_atomic_get_new_crtc_state(state,
> -new_connector_state->crtc);
> - /*
> -  * For compatibility with legacy users, we want to make sure that
> -  * we allow DPMS On->Off modesets on unregistered connectors. Modesets
> -  * which would result in anything else must be considered invalid, to
> -  * avoid turning on new displays on dead connectors.
> -  *
> -  * Since the connector can be unregistered at any point during an
> -  * atomic check or commit, this is racy. But that's OK: all we care
> -  * about is ensuring that userspace can't do anything but shut off the
> -  * display on a connector that was destroyed after it's been notified,
> -  * not before.
> -  *
> -  * Additionally, we also want to ignore connector registration when
> -  * we're trying to restore an atomic state during system resume since
> -  * there's a chance the connector may have been destroyed during the
> -  * process, but it's better to ignore that then cause
> -  * drm_atomic_helper_resume() to fail.
> -  */
> - if (!state->duplicated && drm_connector_is_unregistered(connector) &&
> - crtc_state->active) {
> - DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
> -  connector->base.id, connector->name);
> - return -EINVAL;
> - }
> -
>   funcs = connector->helper_private;
>  
>   if (funcs->atomic_best_encoder)
> @@ -390,6 +363,8 @@ update_connector_routing(struct drm_atomic_state *state,
>  
>   set_best_encoder(state, new_connector_state, new_encoder);
>  
> + crtc_state = drm_atomic_get_new_crtc_state(state,
> +new_connector_state->crtc);
>   crtc_state->connectors_changed = true;
>  
>   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
> [CRTC:%d:%s]\n",
> -- 
> 2.17.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/6] net: stmmac: sun8i: force select external PHY when no internal one

[megous]

From: Icenowy Zheng 

The PHY selection bit also exists on SoCs without an internal PHY; if it's
set to 1 (internal PHY, default value) then the MAC will not make use of
any PHY such SoCs.

This problem appears when adapting for H6, which has no real internal PHY
(the "internal PHY" on H6 is not on-die, but on a co-packaged AC200 chip,
connected via RMII interface at GPIO bank A).

Force the PHY selection bit to 0 when the SOC doesn't have an internal PHY,
to address the problem of a wrong default value.

Signed-off-by: Icenowy Zheng 
Signed-off-by: Ondrej Jirman 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 3258dec84d55..0484c289f328 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -907,6 +907,11 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
 * address. No need to mask it again.
 */
reg |= 1 << H3_EPHY_ADDR_SHIFT;
+   } else {
+   /* For SoCs without internal PHY the PHY selection bit should be
+* set to 0 (external PHY).
+*/
+   reg &= ~H3_EPHY_SELECT;
}
 
if (!of_property_read_u32(node, "allwinner,tx-delay-ps", )) {
-- 
2.21.0

[PATCH v5 4/6] dt-bindings: display: hdmi-connector: Support DDC bus enable

[megous]

From: Ondrej Jirman 

Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
on-board voltage shifting logic for the DDC bus using a gpio to be able
to access DDC bus. Use ddc-en-gpios property on the hdmi-connector to
model this.

Add binding documentation for optional ddc-en-gpios property.

Signed-off-by: Ondrej Jirman 
---
 .../devicetree/bindings/display/connector/hdmi-connector.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt 
b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
index 508aee461e0d..aeb07c4bd703 100644
--- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
+++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
@@ -9,6 +9,7 @@ Optional properties:
 - label: a symbolic name for the connector
 - hpd-gpios: HPD GPIO number
 - ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
+- ddc-en-gpios: signal to enable DDC bus
 
 Required nodes:
 - Video port for HDMI input
-- 
2.21.0

[PATCH v5 1/6] net: stmmac: sun8i: add support for Allwinner H6 EMAC

[megous]

From: Icenowy Zheng 

The EMAC on Allwinner H6 is just like the one on A64. The "internal PHY" on
H6 is on a co-packaged AC200 chip, and it's not really internal (it's
connected via RMII at PA GPIO bank).

Add support for the Allwinner H6 EMAC in the dwmac-sun8i driver.

Signed-off-by: Icenowy Zheng 
Signed-off-by: Ondrej Jirman 
---
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c| 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index ba124a4da793..3258dec84d55 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -147,6 +147,20 @@ static const struct emac_variant emac_variant_a64 = {
.tx_delay_max = 7,
 };
 
+static const struct emac_variant emac_variant_h6 = {
+   .default_syscon_value = 0x5,
+   .syscon_field = _syscon_reg_field,
+   /* The "Internal PHY" of H6 is not on the die. It's on the
+* co-packaged AC200 chip instead.
+*/
+   .soc_has_internal_phy = false,
+   .support_mii = true,
+   .support_rmii = true,
+   .support_rgmii = true,
+   .rx_delay_max = 31,
+   .tx_delay_max = 7,
+};
+
 #define EMAC_BASIC_CTL0 0x00
 #define EMAC_BASIC_CTL1 0x04
 #define EMAC_INT_STA0x08
@@ -1212,6 +1226,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
.data = _variant_r40 },
{ .compatible = "allwinner,sun50i-a64-emac",
.data = _variant_a64 },
+   { .compatible = "allwinner,sun50i-h6-emac",
+   .data = _variant_h6 },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
-- 
2.21.0

[PATCH v5 0/6] Add support for Orange Pi 3

[megous]

From: Ondrej Jirman 

This series implements support for Xunlong Orange Pi 3 board.

Unfortunately, this board needs some small driver patches, so I have
split the boards DT patch into chunks that require patches for drivers
in various subsystems.

Suggested merging plan/dependencies:

- stmmac patches are needed for ethernet support (patches 1-3)
  - these should be ready now
- HDMI support (patches 4-6)
  - needs DT and driver review

Changes in v2:
- added dt-bindings documentation for the board's compatible string
  (suggested by Clement)
- addressed checkpatch warnings and code formatting issues (on Maxime's
  suggestions)
- stmmac: dropped useless parenthesis, reworded description of the patch
  (suggested by Sergei)
- drop useles dev_info() about the selected io bias voltage
- docummented io voltage bias selection variant macros
- wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE",
  because wifi depends on H6 RTC support that's not merged yet (suggested
  by Clement)
- added missing signed-of-bys
- changed  dr_mode to otg, and added a note about VBUS
- improved wording of HDMI driver's DDC power supply patch

Changes in v3:
- dropped already applied patches
- changed pinctrl I/O bias selection constants to enum and renamed
- added /omit-if-no-ref/ to mmc1_pins
- made mmc1_pins default pinconf for mmc1 in H6 dtsi
- move ddc-supply to HDMI connector node, updated patch descriptions,
  changed dt-bindings docs

Changes in v4:
- fix checkpatch warnings/style issues
- use enum in struct sunxi_desc_function for io_bias_cfg_variant
- collected acked-by's
- fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156
  caused by missing conversion from has_io_bias_cfg struct member
  (I've kept the acked-by, because it's a trivial change, but feel free
  to object.) (reported by Martin A. on github)
  I did not have A80 pinctrl enabled for some reason, so I did not catch
  this sooner.
- dropped brcm firmware patch (was already applied)
- dropped the wifi dts patch (will re-send after H6 RTC gets merged,
  along with bluetooth support, in a separate series)

Changes in v5:
- dropped already applied patches (pinctrl patches, mmc1 pinconf patch)
- rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan)
- changed hdmi-connector's ddc-supply property to ddc-en-gpios
  (Rob Herring)

Please take a look.

thank you and regards,
  Ondrej Jirman

Icenowy Zheng (2):
  net: stmmac: sun8i: add support for Allwinner H6 EMAC
  net: stmmac: sun8i: force select external PHY when no internal one

Ondrej Jirman (4):
  arm64: dts: allwinner: orange-pi-3: Enable ethernet
  dt-bindings: display: hdmi-connector: Support DDC bus enable
  drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
  arm64: dts: allwinner: orange-pi-3: Enable HDMI output

 .../display/connector/hdmi-connector.txt  |  1 +
 .../dts/allwinner/sun50i-h6-orangepi-3.dts| 70 +++
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55 ++-
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h |  3 +
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 21 ++
 5 files changed, 147 insertions(+), 3 deletions(-)

-- 
2.21.0

[PATCH v5 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue

[megous]

From: Ondrej Jirman 

Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
for the DDC bus to be usable.

Add support for hdmi-connector node's optional ddc-en-gpios property to
support this use case.

Signed-off-by: Ondrej Jirman 
---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 55 +--
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h |  3 ++
 2 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 39d8509d96a0..59b81ba02d96 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -98,6 +98,30 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct 
drm_device *drm,
return crtcs;
 }
 
+static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
+struct platform_device **pdev_out)
+{
+   struct platform_device *pdev;
+   struct device_node *remote;
+
+   remote = of_graph_get_remote_node(dev->of_node, 1, -1);
+   if (!remote)
+   return -ENODEV;
+
+   if (!of_device_is_compatible(remote, "hdmi-connector")) {
+   of_node_put(remote);
+   return -ENODEV;
+   }
+
+   pdev = of_find_device_by_node(remote);
+   of_node_put(remote);
+   if (!pdev)
+   return -ENODEV;
+
+   *pdev_out = pdev;
+   return 0;
+}
+
 static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
  void *data)
 {
@@ -151,16 +175,29 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct 
device *master,
return PTR_ERR(hdmi->regulator);
}
 
+   ret = sun8i_dw_hdmi_find_connector_pdev(dev, >connector_pdev);
+   if (!ret) {
+   hdmi->ddc_en = gpiod_get_optional(>connector_pdev->dev,
+ "ddc-en", GPIOD_OUT_HIGH);
+   if (IS_ERR(hdmi->ddc_en)) {
+   platform_device_put(hdmi->connector_pdev);
+   dev_err(dev, "Couldn't get ddc-en gpio\n");
+   return PTR_ERR(hdmi->ddc_en);
+   }
+   }
+
ret = regulator_enable(hdmi->regulator);
if (ret) {
dev_err(dev, "Failed to enable regulator\n");
-   return ret;
+   goto err_unref_ddc_en;
}
 
+   gpiod_set_value(hdmi->ddc_en, 1);
+
ret = reset_control_deassert(hdmi->rst_ctrl);
if (ret) {
dev_err(dev, "Could not deassert ctrl reset control\n");
-   goto err_disable_regulator;
+   goto err_disable_ddc_en;
}
 
ret = clk_prepare_enable(hdmi->clk_tmds);
@@ -213,8 +250,14 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct 
device *master,
clk_disable_unprepare(hdmi->clk_tmds);
 err_assert_ctrl_reset:
reset_control_assert(hdmi->rst_ctrl);
-err_disable_regulator:
+err_disable_ddc_en:
+   gpiod_set_value(hdmi->ddc_en, 0);
regulator_disable(hdmi->regulator);
+err_unref_ddc_en:
+   if (hdmi->ddc_en)
+   gpiod_put(hdmi->ddc_en);
+
+   platform_device_put(hdmi->connector_pdev);
 
return ret;
 }
@@ -228,7 +271,13 @@ static void sun8i_dw_hdmi_unbind(struct device *dev, 
struct device *master,
sun8i_hdmi_phy_remove(hdmi);
clk_disable_unprepare(hdmi->clk_tmds);
reset_control_assert(hdmi->rst_ctrl);
+   gpiod_set_value(hdmi->ddc_en, 0);
regulator_disable(hdmi->regulator);
+
+   if (hdmi->ddc_en)
+   gpiod_put(hdmi->ddc_en);
+
+   platform_device_put(hdmi->connector_pdev);
 }
 
 static const struct component_ops sun8i_dw_hdmi_ops = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 720c5aa8adc1..dad66b8301c2 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -190,6 +191,8 @@ struct sun8i_dw_hdmi {
struct regulator*regulator;
const struct sun8i_dw_hdmi_quirks *quirks;
struct reset_control*rst_ctrl;
+   struct platform_device  *connector_pdev;
+   struct gpio_desc*ddc_en;
 };
 
 static inline struct sun8i_dw_hdmi *
-- 
2.21.0

[PATCH v5 3/6] arm64: dts: allwinner: orange-pi-3: Enable ethernet

[megous]

From: Ondrej Jirman 

Orange Pi 3 has two regulators that power the Realtek RTL8211E. According
to the phy datasheet, both regulators need to be enabled at the same time,
but we can only specify a single phy-supply in the DT.

This can be achieved by making one regulator depedning on the other via
vin-supply. While it's not a technically correct description of the
hardware, it achieves the purpose.

All values of RX/TX delay were tested exhaustively and a middle one of the
working values was chosen.

Signed-off-by: Ondrej Jirman 
---
 .../dts/allwinner/sun50i-h6-orangepi-3.dts| 44 +++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 17d496990108..2c6807b74ff6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -15,6 +15,7 @@
 
aliases {
serial0 = 
+   ethernet0 = 
};
 
chosen {
@@ -44,6 +45,27 @@
regulator-max-microvolt = <500>;
regulator-always-on;
};
+
+   /*
+* The board uses 2.5V RGMII signalling. Power sequence to enable
+* the phy is to enable GMAC-2V5 and GMAC-3V (aldo2) power rails
+* at the same time and to wait 100ms.
+*/
+   reg_gmac_2v5: gmac-2v5 {
+   compatible = "regulator-fixed";
+   regulator-name = "gmac-2v5";
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <250>;
+   startup-delay-us = <10>;
+   enable-active-high;
+   gpio = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+
+   /* The real parent of gmac-2v5 is reg_vcc5v, but we need to
+* enable two regulators to power the phy. This is one way
+* to achieve that.
+*/
+   vin-supply = <_aldo2>; /* GMAC-3V */
+   };
 };
 
  {
@@ -58,6 +80,28 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii_pins>;
+   phy-mode = "rgmii";
+   phy-handle = <_rgmii_phy>;
+   phy-supply = <_gmac_2v5>;
+   allwinner,rx-delay-ps = <1500>;
+   allwinner,tx-delay-ps = <700>;
+   status = "okay";
+};
+
+ {
+   ext_rgmii_phy: ethernet-phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+
+   reset-gpios = < 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+   reset-assert-us = <15000>;
+   reset-deassert-us = <4>;
+   };
+};
+
  {
vmmc-supply = <_cldo1>;
cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
-- 
2.21.0

[PATCH v5 6/6] arm64: dts: allwinner: orange-pi-3: Enable HDMI output

[megous]

From: Ondrej Jirman 

Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
This is realized by the ddc-en-gpios property.

Signed-off-by: Ondrej Jirman 
---
 .../dts/allwinner/sun50i-h6-orangepi-3.dts| 26 +++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 2c6807b74ff6..01bb1bafe284 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -22,6 +22,18 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   ddc-en-gpios = < 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -72,6 +84,10 @@
cpu-supply = <_dcdca>;
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -91,6 +107,16 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
  {
ext_rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
-- 
2.21.0

回复: [PATCH] gpu: drm: use struct_size() in kmalloc()

[Pan, Xinhui]

Daniel, what you are talking about is totally wrong.
1) AFAIK, only one zero-size array can be in the end of a struct.
2) two struct_size will add up struct itself twice. the sum is wrong then.

No offense. I can't help feeling lucky that you are in intel. 


发件人: Daniel Vetter  代表 Daniel Vetter 
发送时间: 2019年5月21日 0:28
收件人: Pan, Xinhui
抄送: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); 
airl...@linux.ie; dan...@ffwll.ch; Quan, Evan; xiaolinkui; 
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
linux-ker...@vger.kernel.org
主题: Re: [PATCH] gpu: drm: use struct_size() in kmalloc()
 
[CAUTION: External Email]

On Fri, May 17, 2019 at 04:44:30PM +, Pan, Xinhui wrote:
> I am going to put more members which are also array after this struct,
> not only obj[].  Looks like this struct_size did not help on multiple
> array case. Thanks anyway.  

You can then add them up, e.g. kmalloc(struct_size()+struct_size(),
GFP_KERNEL), so this patch here still looks like a good idea.

Reviewed-by: Daniel Vetter 

Cheers, Daniel

> From: xiaolinkui 
> Sent: Friday, May 17, 2019 4:46:00 PM
> To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); 
> airl...@linux.ie; dan...@ffwll.ch; Pan, Xinhui; Quan, Evan
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
> linux-ker...@vger.kernel.org; xiaolin...@kylinos.cn
> Subject: [PATCH] gpu: drm: use struct_size() in kmalloc()
>
> [CAUTION: External Email]
>
> Use struct_size() helper to keep code simple.
>
> Signed-off-by: xiaolinkui 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 22bd21e..4717a64 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1375,8 +1375,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev)
> if (con)
> return 0;
>
> -   con = kmalloc(sizeof(struct amdgpu_ras) +
> -   sizeof(struct ras_manager) * AMDGPU_RAS_BLOCK_COUNT,
> +   con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
> GFP_KERNEL|__GFP_ZERO);
> if (!con)
> return -ENOMEM;
> --
> 2.7.4
>
>
>

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

[PATCH v2] drm/scheduler: Fix job cleanup without timeout handler

[Erico Nunes]

After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
only deleted when the timeout handler is able to be cancelled
successfully.

In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT),
job cleanup would be skipped which may result in memory leaks.

Add the handling for the (timeout == MAX_SCHEDULE_TIMEOUT) case in
drm_sched_cleanup_jobs.

Signed-off-by: Erico Nunes 
Cc: Christian König 
---
 drivers/gpu/drm/scheduler/sched_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index f8f0e1c19002..10d1d37e644a 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -630,7 +630,8 @@ static void drm_sched_cleanup_jobs(struct drm_gpu_scheduler 
*sched)
unsigned long flags;
 
/* Don't destroy jobs while the timeout worker is running */
-   if (!cancel_delayed_work(>work_tdr))
+   if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
+   !cancel_delayed_work(>work_tdr))
return;
 
 
-- 
2.20.1

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

Re: [PATCH] drm/scheduler: Fix job cleanup without timeout handler

[Erico Nunes]

On Tue, May 21, 2019 at 12:51 AM Erico Nunes  wrote:
>
> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> only deleted when the timeout handler is able to be cancelled
> successfully.
>
> In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT),
> job cleanup would be skipped which may result in memory leaks.
>
> Add the handling for the (timeout == MAX_SCHEDULE_TIMEOUT) case in
> drm_sched_cleanup_jobs.
>
> Signed-off-by: Erico Nunes 
> Cc: Christian König 
> ---
>  drivers/gpu/drm/scheduler/sched_main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
> b/drivers/gpu/drm/scheduler/sched_main.c
> index f8f0e1c19002..07ecaba15127 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -630,7 +630,8 @@ static void drm_sched_cleanup_jobs(struct 
> drm_gpu_scheduler *sched)
> unsigned long flags;
>
> /* Don't destroy jobs while the timeout worker is running */
> -   if (!cancel_delayed_work(>work_tdr))
> +   if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> +   cancel_delayed_work(>work_tdr))
> return;

Nevermind this one, there is a typo. I'll resend.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: drm: use struct_size() in kmalloc()

[Pan, Xinhui]

Daniel, your idea is obviously and totally wrong. There can NOT be more than 
one zero-size array in a struct.

Nack for them all.

From: Daniel Vetter  on behalf of Daniel Vetter 

Sent: Tuesday, May 21, 2019 12:28:07 AM
To: Pan, Xinhui
Cc: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); 
airl...@linux.ie; dan...@ffwll.ch; Quan, Evan; xiaolinkui; 
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] gpu: drm: use struct_size() in kmalloc()

[CAUTION: External Email]

On Fri, May 17, 2019 at 04:44:30PM +, Pan, Xinhui wrote:
> I am going to put more members which are also array after this struct,
> not only obj[].  Looks like this struct_size did not help on multiple
> array case. Thanks anyway.  

You can then add them up, e.g. kmalloc(struct_size()+struct_size(),
GFP_KERNEL), so this patch here still looks like a good idea.

Reviewed-by: Daniel Vetter 

Cheers, Daniel

> From: xiaolinkui 
> Sent: Friday, May 17, 2019 4:46:00 PM
> To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); 
> airl...@linux.ie; dan...@ffwll.ch; Pan, Xinhui; Quan, Evan
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
> linux-ker...@vger.kernel.org; xiaolin...@kylinos.cn
> Subject: [PATCH] gpu: drm: use struct_size() in kmalloc()
>
> [CAUTION: External Email]
>
> Use struct_size() helper to keep code simple.
>
> Signed-off-by: xiaolinkui 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 22bd21e..4717a64 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1375,8 +1375,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev)
> if (con)
> return 0;
>
> -   con = kmalloc(sizeof(struct amdgpu_ras) +
> -   sizeof(struct ras_manager) * AMDGPU_RAS_BLOCK_COUNT,
> +   con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
> GFP_KERNEL|__GFP_ZERO);
> if (!con)
> return -ENOMEM;
> --
> 2.7.4
>
>
>

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

[PATCH] drm/scheduler: Fix job cleanup without timeout handler

[Erico Nunes]

After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
only deleted when the timeout handler is able to be cancelled
successfully.

In case no timeout handler is running (timeout == MAX_SCHEDULE_TIMEOUT),
job cleanup would be skipped which may result in memory leaks.

Add the handling for the (timeout == MAX_SCHEDULE_TIMEOUT) case in
drm_sched_cleanup_jobs.

Signed-off-by: Erico Nunes 
Cc: Christian König 
---
 drivers/gpu/drm/scheduler/sched_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index f8f0e1c19002..07ecaba15127 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -630,7 +630,8 @@ static void drm_sched_cleanup_jobs(struct drm_gpu_scheduler 
*sched)
unsigned long flags;
 
/* Don't destroy jobs while the timeout worker is running */
-   if (!cancel_delayed_work(>work_tdr))
+   if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
+   cancel_delayed_work(>work_tdr))
return;
 
 
-- 
2.20.1

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

[PATCH] drm/lima: add timeout to drm scheduler init

[Erico Nunes]

After "5918045c4ed4 drm/scheduler: rework job destruction", lima started
to leak memory due to buffers not being destroyed after job execution in
the drm scheduler.
This started happening because the drm scheduler only destroyed buffers
after cancelling the job timeout handler, and for lima this handler was
never started as lima specified a MAX_SCHEDULE_TIMEOUT timeout.
Lima seems to run well in its current state with a real timeout, so to
make it more aligned with the other drivers from now on, let's use a
real default timeout.
This also fixes the observed memory leaks.
The 500ms value was chosen as it is the current value for all other
embedded gpu drivers using drm sched.

Signed-off-by: Erico Nunes 
---
 drivers/gpu/drm/lima/lima_drv.c   |  2 +-
 drivers/gpu/drm/lima/lima_sched.c | 11 ---
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index f9a281a62083..b29c26cd13b2 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -17,7 +17,7 @@
 
 int lima_sched_timeout_ms;
 
-MODULE_PARM_DESC(sched_timeout_ms, "task run timeout in ms (0 = no timeout 
(default))");
+MODULE_PARM_DESC(sched_timeout_ms, "task run timeout in ms");
 module_param_named(sched_timeout_ms, lima_sched_timeout_ms, int, 0444);
 
 static int lima_ioctl_get_param(struct drm_device *dev, void *data, struct 
drm_file *file)
diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index 58a15479d175..4127cacac454 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -329,19 +329,16 @@ static void lima_sched_error_work(struct work_struct 
*work)
 
 int lima_sched_pipe_init(struct lima_sched_pipe *pipe, const char *name)
 {
-   long timeout;
-
-   if (lima_sched_timeout_ms <= 0)
-   timeout = MAX_SCHEDULE_TIMEOUT;
-   else
-   timeout = msecs_to_jiffies(lima_sched_timeout_ms);
+   unsigned int timeout = lima_sched_timeout_ms > 0 ?
+  lima_sched_timeout_ms : 500;
 
pipe->fence_context = dma_fence_context_alloc(1);
spin_lock_init(>fence_lock);
 
INIT_WORK(>error_work, lima_sched_error_work);
 
-   return drm_sched_init(>base, _sched_ops, 1, 0, timeout, 
name);
+   return drm_sched_init(>base, _sched_ops, 1, 0,
+ msecs_to_jiffies(timeout), name);
 }
 
 void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
-- 
2.20.1

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

[PATCH] drm/vmwgfx: Don't look at state->allow_modeset

[Daniel Vetter]

That's purely for the uapi layer to implement the ALLOW_MODESET flag.

Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.

v2: Rebase

Signed-off-by: Daniel Vetter 
Cc: VMware Graphics 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index b97bc8e5944b..34284f0f5084 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1704,14 +1704,6 @@ vmw_kms_atomic_check_modeset(struct drm_device *dev,
if (ret)
return ret;
 
-   if (!state->allow_modeset)
-   return ret;
-
-   /*
-* Legacy path do not set allow_modeset properly like
-* @drm_atomic_helper_update_plane, This will result in unnecessary call
-* to vmw_kms_check_topology. So extra set of check.
-*/
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (drm_atomic_crtc_needs_modeset(crtc_state))
need_modeset = true;
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 18/33] fbdev: make unregister/unlink functions not fail

[kbuild test robot]

Hi Daniel,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 


sparse warnings: (new ones prefixed by >>)

>> drivers/staging/fbtft/fbtft-core.c:894:38: sparse: sparse: incorrect type in 
>> return expression (different base types) @@expected int @@got vint @@
>> drivers/staging/fbtft/fbtft-core.c:894:38: sparse:expected int
>> drivers/staging/fbtft/fbtft-core.c:894:38: sparse:got void
--
>> drivers/media/pci/ivtv/ivtvfb.c:1261:43: sparse: sparse: incorrect type in 
>> conditional (non-scalar type)
>> drivers/media/pci/ivtv/ivtvfb.c:1261:43: sparse:got void
--
>> drivers/video/fbdev/neofb.c:2130:43: sparse: sparse: incorrect type in 
>> conditional (non-scalar type)
>> drivers/video/fbdev/neofb.c:2130:43: sparse:got void
--
>> drivers/video/fbdev/savage/savagefb_driver.c:2341:43: sparse: sparse: 
>> incorrect type in conditional (non-scalar type)
>> drivers/video/fbdev/savage/savagefb_driver.c:2341:43: sparse:got void

vim +894 drivers/staging/fbtft/fbtft-core.c

c296d5f9 Thomas Petazzoni 2014-12-31  877  
c296d5f9 Thomas Petazzoni 2014-12-31  878  /**
c296d5f9 Thomas Petazzoni 2014-12-31  879   *   fbtft_unregister_framebuffer - 
releases a tft frame buffer device
c296d5f9 Thomas Petazzoni 2014-12-31  880   *   @fb_info: frame buffer info 
structure
c296d5f9 Thomas Petazzoni 2014-12-31  881   *
c296d5f9 Thomas Petazzoni 2014-12-31  882   *  Frees SPI driverdata if needed
c296d5f9 Thomas Petazzoni 2014-12-31  883   *  Frees gpios.
c296d5f9 Thomas Petazzoni 2014-12-31  884   *   Unregisters frame buffer device.
c296d5f9 Thomas Petazzoni 2014-12-31  885   *
c296d5f9 Thomas Petazzoni 2014-12-31  886   */
c296d5f9 Thomas Petazzoni 2014-12-31  887  int 
fbtft_unregister_framebuffer(struct fb_info *fb_info)
c296d5f9 Thomas Petazzoni 2014-12-31  888  {
c296d5f9 Thomas Petazzoni 2014-12-31  889   struct fbtft_par *par = 
fb_info->par;
c296d5f9 Thomas Petazzoni 2014-12-31  890  
c296d5f9 Thomas Petazzoni 2014-12-31  891   if 
(par->fbtftops.unregister_backlight)
c296d5f9 Thomas Petazzoni 2014-12-31  892   
par->fbtftops.unregister_backlight(par);
c296d5f9 Thomas Petazzoni 2014-12-31  893   fbtft_sysfs_exit(par);
11107ffe Aya Mahfouz  2015-02-27 @894   return 
unregister_framebuffer(fb_info);
c296d5f9 Thomas Petazzoni 2014-12-31  895  }
c296d5f9 Thomas Petazzoni 2014-12-31  896  
EXPORT_SYMBOL(fbtft_unregister_framebuffer);
c296d5f9 Thomas Petazzoni 2014-12-31  897  

:: The code at line 894 was first introduced by commit
:: 11107ffe2cd1c1dc5948713fc08a1372185be0d5 staging: fbtft: remove unused 
variable

:: TO: Aya Mahfouz 
:: CC: Greg Kroah-Hartman 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] mm, notifier: Catch sleeping/blocking for !blockable

[Daniel Vetter]

We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.

I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job done.

Inspired by an i915 patch series which did exactly that, because the
rules haven't been entirely clear to us.

v2: Use the shiny new non_block_start/end annotations instead of
abusing preempt_disable/enable.

v3: Rebase on top of Glisse's arg rework.

v4: Rebase on top of more Glisse rework.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: David Rientjes 
Cc: "Christian König" 
Cc: Daniel Vetter 
Cc: "Jérôme Glisse" 
Cc: linux...@kvack.org
Reviewed-by: Christian König 
Signed-off-by: Daniel Vetter 
---
 mm/mmu_notifier.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index c05e406a7cd7..a09e737711d5 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -176,7 +176,13 @@ int __mmu_notifier_invalidate_range_start(struct 
mmu_notifier_range *range)
id = srcu_read_lock();
hlist_for_each_entry_rcu(mn, >mm->mmu_notifier_mm->list, hlist) {
if (mn->ops->invalidate_range_start) {
-   int _ret = mn->ops->invalidate_range_start(mn, range);
+   int _ret;
+
+   if (!mmu_notifier_range_blockable(range))
+   non_block_start();
+   _ret = mn->ops->invalidate_range_start(mn, range);
+   if (!mmu_notifier_range_blockable(range))
+   non_block_end();
if (_ret) {
pr_info("%pS callback failed with %d in 
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
-- 
2.20.1

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

[PATCH 2/4] kernel.h: Add non_block_start/end()

[Daniel Vetter]

In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.

This will be used in the oom paths of mmu-notifiers, where blocking is
not allowed to make sure there's forward progress. Quoting Michal:

"The notifier is called from quite a restricted context - oom_reaper -
which shouldn't depend on any locks or sleepable conditionals. The code
should be swift as well but we mostly do care about it to make a forward
progress. Checking for sleepable context is the best thing we could come
up with that would describe these demands at least partially."

Peter also asked whether we want to catch spinlocks on top, but Michal
said those are less of a problem because spinlocks can't have an
indirect dependency upon the page allocator and hence close the loop
with the oom reaper.

Suggested by Michal Hocko.

v2:
- Improve commit message (Michal)
- Also check in schedule, not just might_sleep (Peter)

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: David Rientjes 
Cc: "Christian König" 
Cc: Daniel Vetter 
Cc: "Jérôme Glisse" 
Cc: linux...@kvack.org
Cc: Masahiro Yamada 
Cc: Wei Wang 
Cc: Andy Shevchenko 
Cc: Thomas Gleixner 
Cc: Jann Horn 
Cc: Feng Tang 
Cc: Kees Cook 
Cc: Randy Dunlap 
Cc: linux-ker...@vger.kernel.org
Acked-by: Christian König 
Signed-off-by: Daniel Vetter 
---
 include/linux/kernel.h | 10 +-
 include/linux/sched.h  |  4 
 kernel/sched/core.c| 19 ++-
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 74b1ee9027f5..b5f2c2ff0eab 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -214,7 +214,9 @@ extern void __cant_sleep(const char *file, int line, int 
preempt_offset);
  * might_sleep - annotation for functions that can sleep
  *
  * this macro will print a stack trace if it is executed in an atomic
- * context (spinlock, irq-handler, ...).
+ * context (spinlock, irq-handler, ...). Additional sections where blocking is
+ * not allowed can be annotated with non_block_start() and non_block_end()
+ * pairs.
  *
  * This is a useful debugging help to be able to catch problems early and not
  * be bitten later when the calling function happens to sleep when it is not
@@ -230,6 +232,10 @@ extern void __cant_sleep(const char *file, int line, int 
preempt_offset);
 # define cant_sleep() \
do { __cant_sleep(__FILE__, __LINE__, 0); } while (0)
 # define sched_annotate_sleep()(current->task_state_change = 0)
+# define non_block_start() \
+   do { current->non_block_count++; } while (0)
+# define non_block_end() \
+   do { WARN_ON(current->non_block_count-- == 0); } while (0)
 #else
   static inline void ___might_sleep(const char *file, int line,
   int preempt_offset) { }
@@ -238,6 +244,8 @@ extern void __cant_sleep(const char *file, int line, int 
preempt_offset);
 # define might_sleep() do { might_resched(); } while (0)
 # define cant_sleep() do { } while (0)
 # define sched_annotate_sleep() do { } while (0)
+# define non_block_start() do { } while (0)
+# define non_block_end() do { } while (0)
 #endif
 
 #define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 11837410690f..7f5b293e72df 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -908,6 +908,10 @@ struct task_struct {
struct mutex_waiter *blocked_on;
 #endif
 
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+   int non_block_count;
+#endif
+
 #ifdef CONFIG_TRACE_IRQFLAGS
unsigned intirq_events;
unsigned long   hardirq_enable_ip;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 102dfcf0a29a..dd08d423947d 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3264,13 +3264,22 @@ static noinline void __schedule_bug(struct task_struct 
*prev)
 /*
  * Various schedule()-time debugging checks and statistics:
  */
-static inline void schedule_debug(struct task_struct *prev)
+static inline void schedule_debug(struct task_struct *prev, bool preempt)
 {
 #ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
 #endif
 
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+   if (!preempt && prev->state && prev->non_block_count) {
+   printk(KERN_ERR "BUG: scheduling in a non-blocking section: 
%s/%d/%i\n",
+   prev->comm, prev->pid, prev->non_blocking_count);
+   dump_stack();
+   add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
+   }
+#endif
+
if (unlikely(in_atomic_preempt_off())) {
__schedule_bug(prev);

[PATCH 4/4] mm, notifier: Add a lockdep map for invalidate_range_start

[Daniel Vetter]

This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.

A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But both at the
same time is really hard to reliable hit, especially when you want to
exercise paths like direct reclaim or compaction, where it's not
easy to control what exactly will be unmapped.

By introducing a lockdep map to tie them all together we allow lockdep
to see a lot more dependencies, without having to actually hit them
in a single challchain while testing.

Aside: Since I typed this to test i915 mmu notifiers I've only rolled
this out for the invaliate_range_start callback. If there's
interest, we should probably roll this out to all of them. But my
undestanding of core mm is seriously lacking, and I'm not clear on
whether we need a lockdep map for each callback, or whether some can
be shared.

v2: Use lock_map_acquire/release() like fs_reclaim, to avoid confusion
with this being a real mutex (Chris Wilson).

v3: Rebase on top of Glisse's arg rework.

Cc: Chris Wilson 
Cc: Andrew Morton 
Cc: David Rientjes 
Cc: "Jérôme Glisse" 
Cc: Michal Hocko 
Cc: "Christian König" 
Cc: Greg Kroah-Hartman 
Cc: Daniel Vetter 
Cc: Mike Rapoport 
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter 
---
 include/linux/mmu_notifier.h | 6 ++
 mm/mmu_notifier.c| 7 +++
 2 files changed, 13 insertions(+)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index b6c004bd9f6a..9dd38c32fc53 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -42,6 +42,10 @@ enum mmu_notifier_event {
 
 #ifdef CONFIG_MMU_NOTIFIER
 
+#ifdef CONFIG_LOCKDEP
+extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
+#endif
+
 /*
  * The mmu notifier_mm structure is allocated and installed in
  * mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -310,10 +314,12 @@ static inline void mmu_notifier_change_pte(struct 
mm_struct *mm,
 static inline void
 mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
 {
+   lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(range->mm)) {
range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
__mmu_notifier_invalidate_range_start(range);
}
+   lock_map_release(&__mmu_notifier_invalidate_range_start_map);
 }
 
 static inline int
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index a09e737711d5..33bdaddfb9b1 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -23,6 +23,13 @@
 /* global SRCU for all MMs */
 DEFINE_STATIC_SRCU(srcu);
 
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map __mmu_notifier_invalidate_range_start_map = {
+   .name = "mmu_notifier_invalidate_range_start"
+};
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map);
+#endif
+
 /*
  * This function allows mmu_notifier::release callback to delay a call to
  * a function that will free appropriate resources. The function must be
-- 
2.20.1

[PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail

[Daniel Vetter]

Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.

Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return value to handle some
corner cases. Until we realized that these are only for when a task
has been killed by the oom reaper.

An alternative approach would be to split the callback into two
versions, one with the int return value, and the other with void
return value like in older kernels. But that's a lot more churn for
fairly little gain I think.

Summary from the m-l discussion on why we want something at warning
level: This allows automated tooling in CI to catch bugs without
humans having to look at everything. If we just upgrade the existing
pr_info to a pr_warn, then we'll have false positives. And as-is, no
one will ever spot the problem since it's lost in the massive amounts
of overall dmesg noise.

v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
the problematic case (Michal Hocko).

v3: Rebase on top of Glisse's arg rework.

v4: More rebase on top of Glisse reworking everything.

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: "Christian König" 
Cc: David Rientjes 
Cc: Daniel Vetter 
Cc: "Jérôme Glisse" 
Cc: linux...@kvack.org
Cc: Paolo Bonzini 
Reviewed-by: Christian König 
Signed-off-by: Daniel Vetter 
---
 mm/mmu_notifier.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index ee36068077b6..c05e406a7cd7 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -181,6 +181,9 @@ int __mmu_notifier_invalidate_range_start(struct 
mmu_notifier_range *range)
pr_info("%pS callback failed with %d in 
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
!mmu_notifier_range_blockable(range) ? 
"non-" : "");
+   if (!mmu_notifier_range_blockable(range))
+   pr_warn("%pS callback failure not 
allowed\n",
+   
mn->ops->invalidate_range_start);
ret = _ret;
}
}
-- 
2.20.1

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

Re: [PATCH v1 0/4] drm/gma500: drop use of drmP.h

[Patrik Jakobsson]

On Mon, May 20, 2019 at 8:41 PM Daniel Vetter  wrote:
>
> On Sun, May 19, 2019 at 03:51:05PM +0200, Sam Ravnborg wrote:
> > The following patchset remove use of the deprecated drmP.h
> > header file in the gma500 driver.
> > As preparation an empty header file is removed and a dependency on
> > drm_os_linux.h is dropped.
> > The list of include files are sorted and is some cases divided
> > up in blocks of linux/* drm/* etc.
> >
> > Build tested with allmodconfig and allyesconfig for x86, arm, alpha and 
> > more.
> >
> > Patchset made on top of drm-misc-next
>
> Nice series! On the entire pile:
>
> Acked-by: Daniel Vetter 
>
> Since gma500 is defacto unmaintained I think that's good enough, as long
> as you don't break anything. Maybe wait a bit before merging it all.

"Odd Fixes" is probably the correct status.

This looks good and runs fine. Thanks.

Signed-off-by: Patrik Jakobsson 

>
> Aside, I entirely forgot about drm_os_linux.h. That's another file we
> should kill with fire I think :-) Probably best done macro-by-macro or so
> ...
>
> Cheers, Daniel
> >
> >   Sam
> >
> > Sam Ravnborg (4):
> >   drm/gma500: remove empty gma_drm.h header file
> >   drm/gma500: drop drmP.h from header files
> >   drm/gma500: drop use of DRM_UDELAY wrapper
> >   drm/gma500: drop drmp.h include from all .c files
> >
> >  drivers/gpu/drm/gma500/accel_2d.c |  2 +-
> >  drivers/gpu/drm/gma500/cdv_device.c   |  5 +++--
> >  drivers/gpu/drm/gma500/cdv_intel_crt.c|  2 +-
> >  drivers/gpu/drm/gma500/cdv_intel_display.c|  4 +++-
> >  drivers/gpu/drm/gma500/cdv_intel_dp.c |  7 ---
> >  drivers/gpu/drm/gma500/cdv_intel_hdmi.c   |  5 +++--
> >  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  5 ++---
> >  drivers/gpu/drm/gma500/framebuffer.c  |  2 +-
> >  drivers/gpu/drm/gma500/framebuffer.h  |  1 -
> >  drivers/gpu/drm/gma500/gem.c  |  5 +++--
> >  drivers/gpu/drm/gma500/gma_device.c   |  1 -
> >  drivers/gpu/drm/gma500/gma_display.c  |  8 +++-
> >  drivers/gpu/drm/gma500/gtt.c  |  3 ++-
> >  drivers/gpu/drm/gma500/gtt.h  |  1 -
> >  drivers/gpu/drm/gma500/intel_bios.c   |  4 ++--
> >  drivers/gpu/drm/gma500/intel_bios.h   |  3 +--
> >  drivers/gpu/drm/gma500/intel_gmbus.c  |  9 +
> >  drivers/gpu/drm/gma500/intel_i2c.c|  3 ++-
> >  drivers/gpu/drm/gma500/mdfld_device.c |  6 --
> >  drivers/gpu/drm/gma500/mdfld_dsi_dpi.c|  2 ++
> >  drivers/gpu/drm/gma500/mdfld_dsi_output.c |  5 +++--
> >  drivers/gpu/drm/gma500/mdfld_dsi_output.h |  2 +-
> >  drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c |  2 ++
> >  drivers/gpu/drm/gma500/mdfld_intel_display.c  |  5 -
> >  drivers/gpu/drm/gma500/mdfld_tmd_vid.c|  2 ++
> >  drivers/gpu/drm/gma500/mid_bios.c |  3 +--
> >  drivers/gpu/drm/gma500/mmu.c  |  4 +++-
> >  drivers/gpu/drm/gma500/oaktrail_crtc.c|  4 +++-
> >  drivers/gpu/drm/gma500/oaktrail_device.c  |  7 ---
> >  drivers/gpu/drm/gma500/oaktrail_hdmi.c|  6 --
> >  drivers/gpu/drm/gma500/oaktrail_lvds.c|  4 ++--
> >  drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c|  1 -
> >  drivers/gpu/drm/gma500/power.h|  4 +++-
> >  drivers/gpu/drm/gma500/psb_device.c   |  4 ++--
> >  drivers/gpu/drm/gma500/psb_drv.c  | 26 
> > +-
> >  drivers/gpu/drm/gma500/psb_drv.h  |  4 ++--
> >  drivers/gpu/drm/gma500/psb_intel_display.c|  3 ++-
> >  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  3 +--
> >  drivers/gpu/drm/gma500/psb_intel_modes.c  |  2 +-
> >  drivers/gpu/drm/gma500/psb_intel_sdvo.c   | 10 +-
> >  drivers/gpu/drm/gma500/psb_irq.c  |  3 ++-
> >  drivers/gpu/drm/gma500/psb_irq.h  |  2 +-
> >  drivers/gpu/drm/gma500/psb_lid.c  |  4 ++--
> >  drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c|  8 +---
> >  include/drm/gma_drm.h | 25 
> > -
> >  45 files changed, 118 insertions(+), 103 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] drm: Allow modeset on unregisted connectors unconditionally

[Imre Deak]

On Mon, May 20, 2019 at 10:59:35PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 10:51 PM Imre Deak  wrote:
> >
> > On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote:
> > > On Mon, May 20, 2019 at 10:06 PM Imre Deak  wrote:
> > > > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> > > > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> > > > > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > > > > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > > > > > > > We allowed modesetting an unregistered connector only in the 
> > > > > > > > case the
> > > > > > > > mode is getting disabled on the connector.
> > > > > > > >
> > > > > > > > The reason for this check was the lack of proper refcounting 
> > > > > > > > for the
> > > > > > > > backing memory objects. That problem has been solved meanwhile 
> > > > > > > > so there
> > > > > > > > is no reason any more to reject the modesetting in general.
> > > > > > >
> > > > > > > I'm not parsing this at all ... maybe references to the commits 
> > > > > > > that fix
> > > > > > > this? Or do you mean the refcounting work for all the things 
> > > > > > > hanging of
> > > > > > > connectors, including the entire mst tree?
> > > > > >
> > > > > > Yes the check was added to solve the issue related to the removal 
> > > > > > of MST
> > > > > > connectors that could happen asynchronously wrt. a modeset 
> > > > > > referring to
> > > > > > that MST connector.  That could happen since the MST core doesn't 
> > > > > > hold
> > > > > > any locks (for instance the connection_mutex) during removing an MST
> > > > > > connector that would prevent doing a modeset at the same time.
> > > > > >
> > > > > > Adding the refcounting for such MST connectors (via the
> > > > > > drm_connector_get()/drm_connector_put()) got rid of the above 
> > > > > > problem.
> > > > >
> > > > > We added the check way after that stuff landed. Before all the 
> > > > > connector
> > > > > reworking connectors were forcefully disabled by the kernel. The idea
> > > > > behind this check is to make sure that that userspace notices a 
> > > > > connector
> > > > > is gone (only thing that's not allowed is enabling it, you can keep
> > > > > pageflipping). I think we've always had behaviour like ever since mst 
> > > > > (all
> > > > > userspace has some "oops mst connector probably gone" failure catching
> > > > > around modesets).
> > > >
> > > > Right, pageflipping works.
> > > >
> > > > > So no idea what all blows up if we stop catching userspace this way.
> > > > >
> > > > > Now very much possible I'm getting all this wrong again or missing
> > > > > something, this stuff is often way over my head. But I'm really vary 
> > > > > of
> > > > > breaking userspace here. E.g. just the drm_connector_get/put lifetime
> > > > > changes results in some userspace breaking if you unplug/replug fast
> > > > > enough, because then it doesn't notice the connector change anymore. I
> > > > > couldn't figure out a way to paper over that regression without
> > > > > reintroduce the rather broken and oops-prone old connector lifetime
> > > > > management.
> > > >
> > > > Yes, but what is the the actual description of the failing scenario? I
> > > > can't see how anything can go wrong without this check. The resume time
> > > > restoration modeset may have to act in the same way on an old connector.
> > >
> > > That's what the !state->duplicated thing is meant to check for btw.
> > >
> > > > I don't understand how userspace would not notice the connector change.
> > > > It will get a hotplug uevent in response to which it would have to do a
> > > > detect which returns to it the updated information about the new MST
> > > > connector tree.
> > >
> > > uevent handling can take positively forever, at which point the new
> > > connector could already be plugged in, and then userspace makes a mess
> > > aliasing the two since the path property matches. Just needs a wobbly
> > > cable. This is the issue with the "fixed" lifetime management, and I'm
> > > wary of breaking more stuff.
> >
> > Yea, processing can be delayed arbitrarily, the corresponding
> > GETRESOURCES/GETCONNECTOR should still return to the userspace the
> > correct information to do right thing, even if the path property
> > matches: the connector ID for the old and new connector will be
> > different and the GETCONNECTOR for the old ID will return properly that
> > this old connector is already disconnected (see intel_dp_mst_detect()).
> > So I don't see how userspace could mess up things. Obviously if user
> > space is buggy, then well, it is just buggy and then that user space bug
> > would need to be fixed instead of papering over such problems in the
> > kernel.
> 
> Uh that's not how this "kernel change caused a regression" thing
> works. Dave just dropped a rant about this and i915 recently ...

I still don't see what would depend on the current behavior instead 

[Bug 110671] Regression: DP outputs out of sync on dual-DP tiled 5k screen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110671

--- Comment #7 from Tomas Bzatek  ---
The offending commit is

commit 5fc0cbfad4564856ee0f323d3f88a7cff19cc3f1
Author: Wenjing Liu 
Date:   Fri Jan 18 18:19:51 2019 -0500

drm/amd/display: determine if a pipe is synced by plane state

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Allow modeset on unregisted connectors unconditionally

[Daniel Vetter]

On Mon, May 20, 2019 at 10:51 PM Imre Deak  wrote:
>
> On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote:
> > On Mon, May 20, 2019 at 10:06 PM Imre Deak  wrote:
> > > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> > > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> > > > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > > > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > > > > > > We allowed modesetting an unregistered connector only in the case 
> > > > > > > the
> > > > > > > mode is getting disabled on the connector.
> > > > > > >
> > > > > > > The reason for this check was the lack of proper refcounting for 
> > > > > > > the
> > > > > > > backing memory objects. That problem has been solved meanwhile so 
> > > > > > > there
> > > > > > > is no reason any more to reject the modesetting in general.
> > > > > >
> > > > > > I'm not parsing this at all ... maybe references to the commits 
> > > > > > that fix
> > > > > > this? Or do you mean the refcounting work for all the things 
> > > > > > hanging of
> > > > > > connectors, including the entire mst tree?
> > > > >
> > > > > Yes the check was added to solve the issue related to the removal of 
> > > > > MST
> > > > > connectors that could happen asynchronously wrt. a modeset referring 
> > > > > to
> > > > > that MST connector.  That could happen since the MST core doesn't hold
> > > > > any locks (for instance the connection_mutex) during removing an MST
> > > > > connector that would prevent doing a modeset at the same time.
> > > > >
> > > > > Adding the refcounting for such MST connectors (via the
> > > > > drm_connector_get()/drm_connector_put()) got rid of the above problem.
> > > >
> > > > We added the check way after that stuff landed. Before all the connector
> > > > reworking connectors were forcefully disabled by the kernel. The idea
> > > > behind this check is to make sure that that userspace notices a 
> > > > connector
> > > > is gone (only thing that's not allowed is enabling it, you can keep
> > > > pageflipping). I think we've always had behaviour like ever since mst 
> > > > (all
> > > > userspace has some "oops mst connector probably gone" failure catching
> > > > around modesets).
> > >
> > > Right, pageflipping works.
> > >
> > > > So no idea what all blows up if we stop catching userspace this way.
> > > >
> > > > Now very much possible I'm getting all this wrong again or missing
> > > > something, this stuff is often way over my head. But I'm really vary of
> > > > breaking userspace here. E.g. just the drm_connector_get/put lifetime
> > > > changes results in some userspace breaking if you unplug/replug fast
> > > > enough, because then it doesn't notice the connector change anymore. I
> > > > couldn't figure out a way to paper over that regression without
> > > > reintroduce the rather broken and oops-prone old connector lifetime
> > > > management.
> > >
> > > Yes, but what is the the actual description of the failing scenario? I
> > > can't see how anything can go wrong without this check. The resume time
> > > restoration modeset may have to act in the same way on an old connector.
> >
> > That's what the !state->duplicated thing is meant to check for btw.
> >
> > > I don't understand how userspace would not notice the connector change.
> > > It will get a hotplug uevent in response to which it would have to do a
> > > detect which returns to it the updated information about the new MST
> > > connector tree.
> >
> > uevent handling can take positively forever, at which point the new
> > connector could already be plugged in, and then userspace makes a mess
> > aliasing the two since the path property matches. Just needs a wobbly
> > cable. This is the issue with the "fixed" lifetime management, and I'm
> > wary of breaking more stuff.
>
> Yea, processing can be delayed arbitrarily, the corresponding
> GETRESOURCES/GETCONNECTOR should still return to the userspace the
> correct information to do right thing, even if the path property
> matches: the connector ID for the old and new connector will be
> different and the GETCONNECTOR for the old ID will return properly that
> this old connector is already disconnected (see intel_dp_mst_detect()).
> So I don't see how userspace could mess up things. Obviously if user
> space is buggy, then well, it is just buggy and then that user space bug
> would need to be fixed instead of papering over such problems in the
> kernel.

Uh that's not how this "kernel change caused a regression" thing
works. Dave just dropped a rant about this and i915 recently ...

> > Other way round: What do we gain if userspace is allowed to turn on a
> > connector again which doesn't exist and will not ever show any pixels?
> > I'm not seeing a benefit here in allowing that. And history says we
> > change something around mst handling, it'll break something somewhere.
>
> Let's then describe the actual reason for this check, 

Re: [PATCH 1/4] drm/msm: Fix improper uses of smp_mb__{before,after}_atomic()

[Jordan Crouse]

On Mon, May 20, 2019 at 07:23:55PM +0200, Andrea Parri wrote:
> These barriers only apply to the read-modify-write operations; in
> particular, they do not apply to the atomic_set() primitive.
> 
> Replace the barriers with smp_mb()s.
> 
> Fixes: b1fc2839d2f92 ("drm/msm: Implement preemption for A5XX targets")
> Cc: sta...@vger.kernel.org
> Reported-by: "Paul E. McKenney" 
> Reported-by: Peter Zijlstra 
> Signed-off-by: Andrea Parri 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Jordan Crouse 
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> Cc: "Paul E. McKenney" 
> Cc: Peter Zijlstra 

I'll go ahead and ack this - I'm not super clued in on atomic barriers, but this
seems to be in the spirit of what we are trying to do to protect the atomic
value. Rob can disagree, of course.

Acked-by: Jordan Crouse 

> ---
>  drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> index 3d62310a535fb..ee0820ee0c664 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> @@ -39,10 +39,10 @@ static inline void set_preempt_state(struct a5xx_gpu *gpu,
>* preemption or in the interrupt handler so barriers are needed
>* before...
>*/
> - smp_mb__before_atomic();
> + smp_mb();
>   atomic_set(>preempt_state, new);
>   /* ... and after*/
> - smp_mb__after_atomic();
> + smp_mb();
>  }
>  
>  /* Write the most recent wptr for the given ring into the hardware */
> -- 
> 2.7.4
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Allow modeset on unregisted connectors unconditionally

[Imre Deak]

On Mon, May 20, 2019 at 10:15:20PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 10:06 PM Imre Deak  wrote:
> > On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> > > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> > > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > > > > > We allowed modesetting an unregistered connector only in the case 
> > > > > > the
> > > > > > mode is getting disabled on the connector.
> > > > > >
> > > > > > The reason for this check was the lack of proper refcounting for the
> > > > > > backing memory objects. That problem has been solved meanwhile so 
> > > > > > there
> > > > > > is no reason any more to reject the modesetting in general.
> > > > >
> > > > > I'm not parsing this at all ... maybe references to the commits that 
> > > > > fix
> > > > > this? Or do you mean the refcounting work for all the things hanging 
> > > > > of
> > > > > connectors, including the entire mst tree?
> > > >
> > > > Yes the check was added to solve the issue related to the removal of MST
> > > > connectors that could happen asynchronously wrt. a modeset referring to
> > > > that MST connector.  That could happen since the MST core doesn't hold
> > > > any locks (for instance the connection_mutex) during removing an MST
> > > > connector that would prevent doing a modeset at the same time.
> > > >
> > > > Adding the refcounting for such MST connectors (via the
> > > > drm_connector_get()/drm_connector_put()) got rid of the above problem.
> > >
> > > We added the check way after that stuff landed. Before all the connector
> > > reworking connectors were forcefully disabled by the kernel. The idea
> > > behind this check is to make sure that that userspace notices a connector
> > > is gone (only thing that's not allowed is enabling it, you can keep
> > > pageflipping). I think we've always had behaviour like ever since mst (all
> > > userspace has some "oops mst connector probably gone" failure catching
> > > around modesets).
> >
> > Right, pageflipping works.
> >
> > > So no idea what all blows up if we stop catching userspace this way.
> > >
> > > Now very much possible I'm getting all this wrong again or missing
> > > something, this stuff is often way over my head. But I'm really vary of
> > > breaking userspace here. E.g. just the drm_connector_get/put lifetime
> > > changes results in some userspace breaking if you unplug/replug fast
> > > enough, because then it doesn't notice the connector change anymore. I
> > > couldn't figure out a way to paper over that regression without
> > > reintroduce the rather broken and oops-prone old connector lifetime
> > > management.
> >
> > Yes, but what is the the actual description of the failing scenario? I
> > can't see how anything can go wrong without this check. The resume time
> > restoration modeset may have to act in the same way on an old connector.
> 
> That's what the !state->duplicated thing is meant to check for btw.
> 
> > I don't understand how userspace would not notice the connector change.
> > It will get a hotplug uevent in response to which it would have to do a
> > detect which returns to it the updated information about the new MST
> > connector tree.
> 
> uevent handling can take positively forever, at which point the new
> connector could already be plugged in, and then userspace makes a mess
> aliasing the two since the path property matches. Just needs a wobbly
> cable. This is the issue with the "fixed" lifetime management, and I'm
> wary of breaking more stuff.

Yea, processing can be delayed arbitrarily, the corresponding
GETRESOURCES/GETCONNECTOR should still return to the userspace the
correct information to do right thing, even if the path property
matches: the connector ID for the old and new connector will be
different and the GETCONNECTOR for the old ID will return properly that
this old connector is already disconnected (see intel_dp_mst_detect()).
So I don't see how userspace could mess up things. Obviously if user
space is buggy, then well, it is just buggy and then that user space bug
would need to be fixed instead of papering over such problems in the
kernel.

> Other way round: What do we gain if userspace is allowed to turn on a
> connector again which doesn't exist and will not ever show any pixels?
> I'm not seeing a benefit here in allowing that. And history says we
> change something around mst handling, it'll break something somewhere.

Let's then describe the actual reason for this check, that description
is missing.

We should remove this check to simplify things if there isn't an actual
need for it. Userspace can do already a modeset on connectors in general
that are not in a connected state. So this special casing - for MST
connectors only - is a bad idea if there is no reason for special casing
it. If it's there to paper over some user space bug that user space bug
should be 

[Bug 110671] Regression: DP outputs out of sync on dual-DP tiled 5k screen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110671

--- Comment #6 from Tomas Bzatek  ---
Manual bisect so far:

good 0f74e484912626 drm/amd/display: 3.2.15
bad  cf7d98d254e9ff drm/amd/display: 3.2.16

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Allow modeset on unregisted connectors unconditionally

[Daniel Vetter]

On Mon, May 20, 2019 at 10:06 PM Imre Deak  wrote:
> On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> > On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> > > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > > > > We allowed modesetting an unregistered connector only in the case the
> > > > > mode is getting disabled on the connector.
> > > > >
> > > > > The reason for this check was the lack of proper refcounting for the
> > > > > backing memory objects. That problem has been solved meanwhile so 
> > > > > there
> > > > > is no reason any more to reject the modesetting in general.
> > > >
> > > > I'm not parsing this at all ... maybe references to the commits that fix
> > > > this? Or do you mean the refcounting work for all the things hanging of
> > > > connectors, including the entire mst tree?
> > >
> > > Yes the check was added to solve the issue related to the removal of MST
> > > connectors that could happen asynchronously wrt. a modeset referring to
> > > that MST connector.  That could happen since the MST core doesn't hold
> > > any locks (for instance the connection_mutex) during removing an MST
> > > connector that would prevent doing a modeset at the same time.
> > >
> > > Adding the refcounting for such MST connectors (via the
> > > drm_connector_get()/drm_connector_put()) got rid of the above problem.
> >
> > We added the check way after that stuff landed. Before all the connector
> > reworking connectors were forcefully disabled by the kernel. The idea
> > behind this check is to make sure that that userspace notices a connector
> > is gone (only thing that's not allowed is enabling it, you can keep
> > pageflipping). I think we've always had behaviour like ever since mst (all
> > userspace has some "oops mst connector probably gone" failure catching
> > around modesets).
>
> Right, pageflipping works.
>
> > So no idea what all blows up if we stop catching userspace this way.
> >
> > Now very much possible I'm getting all this wrong again or missing
> > something, this stuff is often way over my head. But I'm really vary of
> > breaking userspace here. E.g. just the drm_connector_get/put lifetime
> > changes results in some userspace breaking if you unplug/replug fast
> > enough, because then it doesn't notice the connector change anymore. I
> > couldn't figure out a way to paper over that regression without
> > reintroduce the rather broken and oops-prone old connector lifetime
> > management.
>
> Yes, but what is the the actual description of the failing scenario? I
> can't see how anything can go wrong without this check. The resume time
> restoration modeset may have to act in the same way on an old connector.

That's what the !state->duplicated thing is meant to check for btw.

> I don't understand how userspace would not notice the connector change.
> It will get a hotplug uevent in response to which it would have to do a
> detect which returns to it the updated information about the new MST
> connector tree.

uevent handling can take positively forever, at which point the new
connector could already be plugged in, and then userspace makes a mess
aliasing the two since the path property matches. Just needs a wobbly
cable. This is the issue with the "fixed" lifetime management, and I'm
wary of breaking more stuff.

Other way round: What do we gain if userspace is allowed to turn on a
connector again which doesn't exist and will not ever show any pixels?
I'm not seeing a benefit here in allowing that. And history says we
change something around mst handling, it'll break something somewhere.
-Daniel

>
> > > > > The check
> > > > > for that also makes driver internal modesets more cumbersome where we
> > > > > need to add exemptions for the cases where we do need to allow the
> > > > > modeset even for unregistered connectors. One such case is the
> > > > > restoration of the mode during resume.
> > > >
> > > > Yeah this one actually makes sense to me. We could still keep this check
> > > > here, but for the atomic ioctl only when called from userspace. But iirc
> > > > Lyude also said she has some plans here, so no idea whether that all 
> > > > fits.
> > > >
> > > > > Simplify things by removing the unneeded check. I can't see how
> > > > > modesetting an unregistered connector can cause any problem and the 
> > > > > race
> > > > > (described in the code comment) can anyway result in such a modeset 
> > > > > (if
> > > > > the connector is unregistered right after the check).
> > > >
> > > > Not saying we don't need this, but there's fairly enormous amounts of
> > > > history behind all this stuff, and lots of discussions. Would be good to
> > > > at least reference those, so we have a good story for when this then all
> > > > goes wrong again.
> > >
> > > I still don't see why this check is needed. There is no justification
> > > for it - besides the original reason for it 

Re: [PATCH] drm: Allow modeset on unregisted connectors unconditionally

[Imre Deak]

On Mon, May 20, 2019 at 09:23:00PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> > On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > > > We allowed modesetting an unregistered connector only in the case the
> > > > mode is getting disabled on the connector.
> > > > 
> > > > The reason for this check was the lack of proper refcounting for the
> > > > backing memory objects. That problem has been solved meanwhile so there
> > > > is no reason any more to reject the modesetting in general.
> > > 
> > > I'm not parsing this at all ... maybe references to the commits that fix
> > > this? Or do you mean the refcounting work for all the things hanging of
> > > connectors, including the entire mst tree?
> > 
> > Yes the check was added to solve the issue related to the removal of MST
> > connectors that could happen asynchronously wrt. a modeset referring to
> > that MST connector.  That could happen since the MST core doesn't hold
> > any locks (for instance the connection_mutex) during removing an MST
> > connector that would prevent doing a modeset at the same time.
> > 
> > Adding the refcounting for such MST connectors (via the
> > drm_connector_get()/drm_connector_put()) got rid of the above problem.
> 
> We added the check way after that stuff landed. Before all the connector
> reworking connectors were forcefully disabled by the kernel. The idea
> behind this check is to make sure that that userspace notices a connector
> is gone (only thing that's not allowed is enabling it, you can keep
> pageflipping). I think we've always had behaviour like ever since mst (all
> userspace has some "oops mst connector probably gone" failure catching
> around modesets).

Right, pageflipping works.

> So no idea what all blows up if we stop catching userspace this way.
> 
> Now very much possible I'm getting all this wrong again or missing
> something, this stuff is often way over my head. But I'm really vary of
> breaking userspace here. E.g. just the drm_connector_get/put lifetime
> changes results in some userspace breaking if you unplug/replug fast
> enough, because then it doesn't notice the connector change anymore. I
> couldn't figure out a way to paper over that regression without
> reintroduce the rather broken and oops-prone old connector lifetime
> management.

Yes, but what is the the actual description of the failing scenario? I
can't see how anything can go wrong without this check. The resume time
restoration modeset may have to act in the same way on an old connector.

I don't understand how userspace would not notice the connector change.
It will get a hotplug uevent in response to which it would have to do a
detect which returns to it the updated information about the new MST
connector tree.

> > > > The check
> > > > for that also makes driver internal modesets more cumbersome where we
> > > > need to add exemptions for the cases where we do need to allow the
> > > > modeset even for unregistered connectors. One such case is the
> > > > restoration of the mode during resume.
> > > 
> > > Yeah this one actually makes sense to me. We could still keep this check
> > > here, but for the atomic ioctl only when called from userspace. But iirc
> > > Lyude also said she has some plans here, so no idea whether that all fits.
> > > 
> > > > Simplify things by removing the unneeded check. I can't see how
> > > > modesetting an unregistered connector can cause any problem and the race
> > > > (described in the code comment) can anyway result in such a modeset (if
> > > > the connector is unregistered right after the check).
> > > 
> > > Not saying we don't need this, but there's fairly enormous amounts of
> > > history behind all this stuff, and lots of discussions. Would be good to
> > > at least reference those, so we have a good story for when this then all
> > > goes wrong again.
> > 
> > I still don't see why this check is needed. There is no justification
> > for it - besides the original reason for it as discussed above about the
> > refcounting problem, which is solved now - so I think we should remove
> > it, instead of just making it a special case for the user space modeset.
> > 
> > As I wrote a user space modeset can end up anyway doing a modeset on an
> > unregistered connector when the unregistering - by MST core - happens just
> > right after the check.
> 
> Yup. Always been like that.
> -Daniel
> 
> > 
> > > -Daniel
> > > 
> > > > 
> > > > Cc: Lyude Paul 
> > > > Cc: Daniel Vetter 
> > > > Cc: Ville Syrjälä 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
> > > >  1 file changed, 2 insertions(+), 27 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 2e0cb4246cbd..e94e69483498 100644
> > > > --- 

Re: [Intel-gfx] [PATCH 31/33] fbcon: Call con2fb_map functions directly

[kbuild test robot]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=alpha 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/core/fbcon.c: In function 'fbcon_set_con2fb_map_ioctl':
>> drivers/video/fbdev/core/fbcon.c:3323:6: error: implicit declaration of 
>> function 'copy_from_user'; did you mean 'sg_copy_from_buffer'? 
>> [-Werror=implicit-function-declaration]
 if (copy_from_user(, argp, sizeof(con2fb)))
 ^~
 sg_copy_from_buffer
   drivers/video/fbdev/core/fbcon.c: In function 'fbcon_get_con2fb_map_ioctl':
   drivers/video/fbdev/core/fbcon.c:3356:9: error: implicit declaration of 
function 'copy_to_user'; did you mean 'cpu_to_mem'? 
[-Werror=implicit-function-declaration]
 return copy_to_user(argp, , sizeof(con2fb)) ? -EFAULT : 0;
^~~~
cpu_to_mem
   cc1: some warnings being treated as errors

vim +3323 drivers/video/fbdev/core/fbcon.c

  3317  
  3318  int fbcon_set_con2fb_map_ioctl(void __user *argp)
  3319  {
  3320  struct fb_con2fbmap con2fb;
  3321  int ret;
  3322  
> 3323  if (copy_from_user(, argp, sizeof(con2fb)))
  3324  return -EFAULT;
  3325  if (con2fb.console < 1 || con2fb.console > MAX_NR_CONSOLES)
  3326  return -EINVAL;
  3327  if (con2fb.framebuffer >= FB_MAX)
  3328  return -EINVAL;
  3329  if (!registered_fb[con2fb.framebuffer])
  3330  request_module("fb%d", con2fb.framebuffer);
  3331  if (!registered_fb[con2fb.framebuffer]) {
  3332  return -EINVAL;
    }
  3334  
  3335  console_lock();
  3336  ret = set_con2fb_map(con2fb.console - 1,
  3337   con2fb.framebuffer, 1);
  3338  console_unlock();
  3339  
  3340  return ret;
  3341  }
  3342  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [Intel-gfx] [PATCH 31/33] fbcon: Call con2fb_map functions directly

[kbuild test robot]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=sparc64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/core/fbcon.c: In function 'fbcon_set_con2fb_map_ioctl':
>> drivers/video/fbdev/core/fbcon.c:3323:6: error: implicit declaration of 
>> function 'copy_from_user'; did you mean 'copy_creds'? 
>> [-Werror=implicit-function-declaration]
 if (copy_from_user(, argp, sizeof(con2fb)))
 ^~
 copy_creds
   drivers/video/fbdev/core/fbcon.c: In function 'fbcon_get_con2fb_map_ioctl':
>> drivers/video/fbdev/core/fbcon.c:3356:9: error: implicit declaration of 
>> function 'copy_to_user'; did you mean 'cpu_to_mem'? 
>> [-Werror=implicit-function-declaration]
 return copy_to_user(argp, , sizeof(con2fb)) ? -EFAULT : 0;
^~~~
cpu_to_mem
   cc1: some warnings being treated as errors

vim +3323 drivers/video/fbdev/core/fbcon.c

  3317  
  3318  int fbcon_set_con2fb_map_ioctl(void __user *argp)
  3319  {
  3320  struct fb_con2fbmap con2fb;
  3321  int ret;
  3322  
> 3323  if (copy_from_user(, argp, sizeof(con2fb)))
  3324  return -EFAULT;
  3325  if (con2fb.console < 1 || con2fb.console > MAX_NR_CONSOLES)
  3326  return -EINVAL;
  3327  if (con2fb.framebuffer >= FB_MAX)
  3328  return -EINVAL;
  3329  if (!registered_fb[con2fb.framebuffer])
  3330  request_module("fb%d", con2fb.framebuffer);
  3331  if (!registered_fb[con2fb.framebuffer]) {
  3332  return -EINVAL;
    }
  3334  
  3335  console_lock();
  3336  ret = set_con2fb_map(con2fb.console - 1,
  3337   con2fb.framebuffer, 1);
  3338  console_unlock();
  3339  
  3340  return ret;
  3341  }
  3342  
  3343  int fbcon_get_con2fb_map_ioctl(void __user *argp)
  3344  {
  3345  struct fb_con2fbmap con2fb;
  3346  
  3347  if (copy_from_user(, argp, sizeof(con2fb)))
  3348  return -EFAULT;
  3349  if (con2fb.console < 1 || con2fb.console > MAX_NR_CONSOLES)
  3350  return -EINVAL;
  3351  
  3352  console_lock();
  3353  con2fb.framebuffer = con2fb_map[con2fb.console - 1];
  3354  console_unlock();
  3355  
> 3356  return copy_to_user(argp, , sizeof(con2fb)) ? -EFAULT : 
> 0;
  3357  }
  3358  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 1/2] drm: Add drm_gem_vram_{pin/unpin}_reserved() and convert mgag200

[Daniel Vetter]

On Mon, May 20, 2019 at 9:24 PM Koenig, Christian
 wrote:
>
> Am 20.05.19 um 18:26 schrieb Daniel Vetter:
> > [CAUTION: External Email]
> >
> > On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote:
> >> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
> >>> The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
> >>> GEM VRAM pin/unpin functions that do not reserve the BO during validation.
> >>> The mgag200 driver requires this behavior for its cursor handling. The
> >>> patch also converts the driver to use the new interfaces.
> >>>
> >>> Signed-off-by: Thomas Zimmermann 
> >>> ---
> >>>   drivers/gpu/drm/drm_gem_vram_helper.c| 75 
> >>>   drivers/gpu/drm/mgag200/mgag200_cursor.c | 18 +++---
> >>>   include/drm/drm_gem_vram_helper.h|  3 +
> >>>   3 files changed, 88 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
> >>> b/drivers/gpu/drm/drm_gem_vram_helper.c
> >>> index 8f142b810eb4..a002c03eaf4c 100644
> >>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> >>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> >>> @@ -254,6 +254,47 @@ int drm_gem_vram_pin(struct drm_gem_vram_object 
> >>> *gbo, unsigned long pl_flag)
> >>>   }
> >>>   EXPORT_SYMBOL(drm_gem_vram_pin);
> >>>
> >>> +/**
> >>> + * drm_gem_vram_pin_reserved() - Pins a GEM VRAM object in a region.
> >>> + * @gbo:   the GEM VRAM object
> >>> + * @pl_flag:   a bitmask of possible memory regions
> >>> + *
> >>> + * Pinning a buffer object ensures that it is not evicted from
> >>> + * a memory region. A pinned buffer object has to be unpinned before
> >>> + * it can be pinned to another region.
> >>> + *
> >>> + * This function pins a GEM VRAM object that has already been
> >>> + * reserved. Use drm_gem_vram_pin() if possible.
> >>> + *
> >>> + * Returns:
> >>> + * 0 on success, or
> >>> + * a negative error code otherwise.
> >>> + */
> >>> +int drm_gem_vram_pin_reserved(struct drm_gem_vram_object *gbo,
> >>> + unsigned long pl_flag)
> >>> +{
> >>> +   int i, ret;
> >>> +   struct ttm_operation_ctx ctx = { false, false };
> >> I think would be good to have a lockdep_assert_held here for the ww_mutex.
> >>
> >> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
> >> we call the structure tracking the fences+lock the "reservation", but the
> >> naming scheme used is _lock/_unlock.
> >>
> >> I think would be good to be consistent with that, and use _locked here.
> >> Especially for a very simplified vram helper like this one I expect that's
> >> going to lead to less wtf moments by driver writers :-)
> >>
> >> Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align
> >> more with what we now have in dma-buf.
> > More aside:
> >
> > Could be a good move to demidlayer this an essentially remove
> > ttm_bo_reserve as a wrapper around the linux/reservation.h functions. Not
> > sure whether that aligns with Christian's plans. TODO.rst patch might be a
> > good step to get that discussion started.
>
> Well what ttm_bo_reserve()/_unreserve() does is a) lock/unlock the
> reservation object and b) remove the BO from the LRU.
>
> Since I'm desperately trying to get rid of the LRU removal right now we
> sooner or later should be able to remove ttmo_bo_reserve()/_unreserve()
> as well (or at least replace them with tiny ttm_bo_lock() wrappers.

Yeah that's what I meant, would be nice to ditch that bit of
midlayering, at least from drivers.

I guess within ttm we'd still need ttm_bo_lock/unlock, since
interrupteble/timedout/lock modes in general is passed around
throughout the entire stack as parameters.
-Daniel

>
> Christian.
>
> > -Daniel
> >
> >> Cheers, Daniel
> >>
> >>> +
> >>> +   if (gbo->pin_count) {
> >>> +   ++gbo->pin_count;
> >>> +   return 0;
> >>> +   }
> >>> +
> >>> +   drm_gem_vram_placement(gbo, pl_flag);
> >>> +   for (i = 0; i < gbo->placement.num_placement; ++i)
> >>> +   gbo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
> >>> +
> >>> +   ret = ttm_bo_validate(>bo, >placement, );
> >>> +   if (ret < 0)
> >>> +   return ret;
> >>> +
> >>> +   gbo->pin_count = 1;
> >>> +
> >>> +   return 0;
> >>> +}
> >>> +EXPORT_SYMBOL(drm_gem_vram_pin_reserved);
> >>> +
> >>>   /**
> >>>* drm_gem_vram_unpin() - Unpins a GEM VRAM object
> >>>* @gbo:   the GEM VRAM object
> >>> @@ -285,6 +326,40 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object 
> >>> *gbo)
> >>>   }
> >>>   EXPORT_SYMBOL(drm_gem_vram_unpin);
> >>>
> >>> +/**
> >>> + * drm_gem_vram_unpin_reserved() - Unpins a GEM VRAM object
> >>> + * @gbo:   the GEM VRAM object
> >>> + *
> >>> + * This function unpins a GEM VRAM object that has already been
> >>> + * reserved. Use drm_gem_vram_unpin() if possible.
> >>> + *
> >>> + * Returns:
> >>> + * 0 on success, or
> >>> + * a negative error code otherwise.
> >>> + */
> >>> +int drm_gem_vram_unpin_reserved(struct 

Re: [Intel-gfx] [PATCH 18/33] fbdev: make unregister/unlink functions not fail

[kbuild test robot]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: x86_64-randconfig-x003-201920 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/savage/savagefb_driver.c: In function 'savagefb_remove':
>> drivers/video/fbdev/savage/savagefb_driver.c:2341:7: error: void value not 
>> ignored as it ought to be
  if (unregister_framebuffer(info))
  ^~

vim +2341 drivers/video/fbdev/savage/savagefb_driver.c

^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2328  
48c68c4f drivers/video/savage/savagefb_driver.c Greg Kroah-Hartman 2012-12-21  
2329  static void savagefb_remove(struct pci_dev *dev)
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2330  {
b8901b09 drivers/video/savage/savagefb_driver.c Antonino A. Daplas 2006-01-09  
2331 struct fb_info *info = pci_get_drvdata(dev);
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2332  
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2333 DBG("savagefb_remove");
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2334  
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2335 if (info) {
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2336 /*
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2337  * If unregister_framebuffer fails, then
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2338  * we will be leaving hooks that could cause
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2339  * oopsen laying around.
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2340  */
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16 
@2341 if (unregister_framebuffer(info))
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2342 printk(KERN_WARNING "savagefb: danger danger! "
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2343"Oopsen imminent!\n");
^1da177e drivers/video/savage/savagefb_driver.c Linus Torvalds 2005-04-16  
2344  

:: The code at line 2341 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: Add drm_gem_vram_{pin/unpin}_reserved() and convert mgag200

[Koenig, Christian]

Am 20.05.19 um 18:26 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote:
>> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
>>> The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
>>> GEM VRAM pin/unpin functions that do not reserve the BO during validation.
>>> The mgag200 driver requires this behavior for its cursor handling. The
>>> patch also converts the driver to use the new interfaces.
>>>
>>> Signed-off-by: Thomas Zimmermann 
>>> ---
>>>   drivers/gpu/drm/drm_gem_vram_helper.c| 75 
>>>   drivers/gpu/drm/mgag200/mgag200_cursor.c | 18 +++---
>>>   include/drm/drm_gem_vram_helper.h|  3 +
>>>   3 files changed, 88 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
>>> b/drivers/gpu/drm/drm_gem_vram_helper.c
>>> index 8f142b810eb4..a002c03eaf4c 100644
>>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
>>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>>> @@ -254,6 +254,47 @@ int drm_gem_vram_pin(struct drm_gem_vram_object *gbo, 
>>> unsigned long pl_flag)
>>>   }
>>>   EXPORT_SYMBOL(drm_gem_vram_pin);
>>>
>>> +/**
>>> + * drm_gem_vram_pin_reserved() - Pins a GEM VRAM object in a region.
>>> + * @gbo:   the GEM VRAM object
>>> + * @pl_flag:   a bitmask of possible memory regions
>>> + *
>>> + * Pinning a buffer object ensures that it is not evicted from
>>> + * a memory region. A pinned buffer object has to be unpinned before
>>> + * it can be pinned to another region.
>>> + *
>>> + * This function pins a GEM VRAM object that has already been
>>> + * reserved. Use drm_gem_vram_pin() if possible.
>>> + *
>>> + * Returns:
>>> + * 0 on success, or
>>> + * a negative error code otherwise.
>>> + */
>>> +int drm_gem_vram_pin_reserved(struct drm_gem_vram_object *gbo,
>>> + unsigned long pl_flag)
>>> +{
>>> +   int i, ret;
>>> +   struct ttm_operation_ctx ctx = { false, false };
>> I think would be good to have a lockdep_assert_held here for the ww_mutex.
>>
>> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
>> we call the structure tracking the fences+lock the "reservation", but the
>> naming scheme used is _lock/_unlock.
>>
>> I think would be good to be consistent with that, and use _locked here.
>> Especially for a very simplified vram helper like this one I expect that's
>> going to lead to less wtf moments by driver writers :-)
>>
>> Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align
>> more with what we now have in dma-buf.
> More aside:
>
> Could be a good move to demidlayer this an essentially remove
> ttm_bo_reserve as a wrapper around the linux/reservation.h functions. Not
> sure whether that aligns with Christian's plans. TODO.rst patch might be a
> good step to get that discussion started.

Well what ttm_bo_reserve()/_unreserve() does is a) lock/unlock the 
reservation object and b) remove the BO from the LRU.

Since I'm desperately trying to get rid of the LRU removal right now we 
sooner or later should be able to remove ttmo_bo_reserve()/_unreserve() 
as well (or at least replace them with tiny ttm_bo_lock() wrappers.

Christian.

> -Daniel
>
>> Cheers, Daniel
>>
>>> +
>>> +   if (gbo->pin_count) {
>>> +   ++gbo->pin_count;
>>> +   return 0;
>>> +   }
>>> +
>>> +   drm_gem_vram_placement(gbo, pl_flag);
>>> +   for (i = 0; i < gbo->placement.num_placement; ++i)
>>> +   gbo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
>>> +
>>> +   ret = ttm_bo_validate(>bo, >placement, );
>>> +   if (ret < 0)
>>> +   return ret;
>>> +
>>> +   gbo->pin_count = 1;
>>> +
>>> +   return 0;
>>> +}
>>> +EXPORT_SYMBOL(drm_gem_vram_pin_reserved);
>>> +
>>>   /**
>>>* drm_gem_vram_unpin() - Unpins a GEM VRAM object
>>>* @gbo:   the GEM VRAM object
>>> @@ -285,6 +326,40 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
>>>   }
>>>   EXPORT_SYMBOL(drm_gem_vram_unpin);
>>>
>>> +/**
>>> + * drm_gem_vram_unpin_reserved() - Unpins a GEM VRAM object
>>> + * @gbo:   the GEM VRAM object
>>> + *
>>> + * This function unpins a GEM VRAM object that has already been
>>> + * reserved. Use drm_gem_vram_unpin() if possible.
>>> + *
>>> + * Returns:
>>> + * 0 on success, or
>>> + * a negative error code otherwise.
>>> + */
>>> +int drm_gem_vram_unpin_reserved(struct drm_gem_vram_object *gbo)
>>> +{
>>> +   int i, ret;
>>> +   struct ttm_operation_ctx ctx = { false, false };
>>> +
>>> +   if (WARN_ON_ONCE(!gbo->pin_count))
>>> +   return 0;
>>> +
>>> +   --gbo->pin_count;
>>> +   if (gbo->pin_count)
>>> +   return 0;
>>> +
>>> +   for (i = 0; i < gbo->placement.num_placement ; ++i)
>>> +   gbo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
>>> +
>>> +   ret = ttm_bo_validate(>bo, >placement, );
>>> +   if (ret < 0)
>>> +   return ret;
>>> +
>>> +   return 0;
>>> +}
>>> 

Re: [PATCH 21/33] fbdev: directly call fbcon_suspended/resumed

[kbuild test robot]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: x86_64-randconfig-x006-201920 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/core/fbmem.c: In function 'fb_set_suspend':
>> drivers/video/fbdev/core/fbmem.c:1908:3: error: too many arguments to 
>> function 'fbcon_suspended'
  fbcon_suspended(info);
  ^~~
   In file included from drivers/video/fbdev/core/fbmem.c:35:0:
   include/linux/fbcon.h:18:20: note: declared here
static inline void fbcon_suspended(void) {}
   ^~~
>> drivers/video/fbdev/core/fbmem.c:1912:3: error: too many arguments to 
>> function 'fbcon_resumed'
  fbcon_resumed(info);
  ^
   In file included from drivers/video/fbdev/core/fbmem.c:35:0:
   include/linux/fbcon.h:19:20: note: declared here
static inline void fbcon_resumed(void) {}
   ^

vim +/fbcon_suspended +1908 drivers/video/fbdev/core/fbmem.c

  1893  
  1894  /**
  1895   *  fb_set_suspend - low level driver signals suspend
  1896   *  @info: framebuffer affected
  1897   *  @state: 0 = resuming, !=0 = suspending
  1898   *
  1899   *  This is meant to be used by low level drivers to
  1900   *  signal suspend/resume to the core & clients.
  1901   *  It must be called with the console semaphore held
  1902   */
  1903  void fb_set_suspend(struct fb_info *info, int state)
  1904  {
  1905  WARN_CONSOLE_UNLOCKED();
  1906  
  1907  if (state) {
> 1908  fbcon_suspended(info);
  1909  info->state = FBINFO_STATE_SUSPENDED;
  1910  } else {
  1911  info->state = FBINFO_STATE_RUNNING;
> 1912  fbcon_resumed(info);
  1913  }
  1914  }
  1915  EXPORT_SYMBOL(fb_set_suspend);
  1916  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Allow modeset on unregisted connectors unconditionally

[Daniel Vetter]

On Mon, May 20, 2019 at 10:09:24PM +0300, Imre Deak wrote:
> On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> > On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > > We allowed modesetting an unregistered connector only in the case the
> > > mode is getting disabled on the connector.
> > > 
> > > The reason for this check was the lack of proper refcounting for the
> > > backing memory objects. That problem has been solved meanwhile so there
> > > is no reason any more to reject the modesetting in general.
> > 
> > I'm not parsing this at all ... maybe references to the commits that fix
> > this? Or do you mean the refcounting work for all the things hanging of
> > connectors, including the entire mst tree?
> 
> Yes the check was added to solve the issue related to the removal of MST
> connectors that could happen asynchronously wrt. a modeset referring to
> that MST connector.  That could happen since the MST core doesn't hold
> any locks (for instance the connection_mutex) during removing an MST
> connector that would prevent doing a modeset at the same time.
> 
> Adding the refcounting for such MST connectors (via the
> drm_connector_get()/drm_connector_put()) got rid of the above problem.

We added the check way after that stuff landed. Before all the connector
reworking connectors were forcefully disabled by the kernel. The idea
behind this check is to make sure that that userspace notices a connector
is gone (only thing that's not allowed is enabling it, you can keep
pageflipping). I think we've always had behaviour like ever since mst (all
userspace has some "oops mst connector probably gone" failure catching
around modesets).

So no idea what all blows up if we stop catching userspace this way.

Now very much possible I'm getting all this wrong again or missing
something, this stuff is often way over my head. But I'm really vary of
breaking userspace here. E.g. just the drm_connector_get/put lifetime
changes results in some userspace breaking if you unplug/replug fast
enough, because then it doesn't notice the connector change anymore. I
couldn't figure out a way to paper over that regression without
reintroduce the rather broken and oops-prone old connector lifetime
management.

> > > The check
> > > for that also makes driver internal modesets more cumbersome where we
> > > need to add exemptions for the cases where we do need to allow the
> > > modeset even for unregistered connectors. One such case is the
> > > restoration of the mode during resume.
> > 
> > Yeah this one actually makes sense to me. We could still keep this check
> > here, but for the atomic ioctl only when called from userspace. But iirc
> > Lyude also said she has some plans here, so no idea whether that all fits.
> > 
> > > Simplify things by removing the unneeded check. I can't see how
> > > modesetting an unregistered connector can cause any problem and the race
> > > (described in the code comment) can anyway result in such a modeset (if
> > > the connector is unregistered right after the check).
> > 
> > Not saying we don't need this, but there's fairly enormous amounts of
> > history behind all this stuff, and lots of discussions. Would be good to
> > at least reference those, so we have a good story for when this then all
> > goes wrong again.
> 
> I still don't see why this check is needed. There is no justification
> for it - besides the original reason for it as discussed above about the
> refcounting problem, which is solved now - so I think we should remove
> it, instead of just making it a special case for the user space modeset.
> 
> As I wrote a user space modeset can end up anyway doing a modeset on an
> unregistered connector when the unregistering - by MST core - happens just
> right after the check.

Yup. Always been like that.
-Daniel

> 
> > -Daniel
> > 
> > > 
> > > Cc: Lyude Paul 
> > > Cc: Daniel Vetter 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
> > >  1 file changed, 2 insertions(+), 27 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 2e0cb4246cbd..e94e69483498 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state 
> > > *state,
> > >   return 0;
> > >   }
> > >  
> > > - crtc_state = drm_atomic_get_new_crtc_state(state,
> > > -new_connector_state->crtc);
> > > - /*
> > > -  * For compatibility with legacy users, we want to make sure that
> > > -  * we allow DPMS On->Off modesets on unregistered connectors. Modesets
> > > -  * which would result in anything else must be considered invalid, to
> > > -  * avoid turning on new displays on dead connectors.
> > > -  *
> > > -  * Since the connector can be unregistered at 

Re: [PATCH v1 0/6] drm: make headers self-contained

[Sam Ravnborg]

Hi Daniel.

On Mon, May 20, 2019 at 08:45:26PM +0200, Daniel Vetter wrote:
> On Sun, May 19, 2019 at 04:20:30PM +0200, Sam Ravnborg wrote:
> > While removing use of drmP.h from files in drm/* I
> > noticed that I had to add the same include files due to
> > build errors in the header files.
> > 
> > It is better to let the header files include what is necessary
> > and let the users pull in only the additional headers files required.
> > So I went ahead and made the header files self-conatined.
> > (I did not check if this made any includes redundant in some files,
> > I do not have tooling in place to do so).
> 
> I think it'd be great to make sure this keeps being the case. Jani Nikula
> just pointed me at some neat stuff in drm/i915/Makefile.header-test.
> 

> I think it'd be nice to have something similar for drm headers in
> drivers/gpu/drm, behind a Kconfig option perhaps so that it doesn't upset
> people, but 0day will still spot issues. That would also make the series
> easier to review, since each patch would add the header it fixes to that
> build target.
I would like to wait with this until Jani's general solution:
https://www.spinics.net/lists/linux-kbuild/msg21839.html
hits mainline.

I can also duplicate what Jani already did and then migrate to the
general solution when it is ready.
Hmm. I think this is the best way forward.
So we can have all the other functionality in place.
Let me give this a shot and get back with a few patches.

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

Re: [PATCH] drm: Allow modeset on unregisted connectors unconditionally

[Imre Deak]

On Mon, May 20, 2019 at 08:37:46PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> > We allowed modesetting an unregistered connector only in the case the
> > mode is getting disabled on the connector.
> > 
> > The reason for this check was the lack of proper refcounting for the
> > backing memory objects. That problem has been solved meanwhile so there
> > is no reason any more to reject the modesetting in general.
> 
> I'm not parsing this at all ... maybe references to the commits that fix
> this? Or do you mean the refcounting work for all the things hanging of
> connectors, including the entire mst tree?

Yes the check was added to solve the issue related to the removal of MST
connectors that could happen asynchronously wrt. a modeset referring to
that MST connector.  That could happen since the MST core doesn't hold
any locks (for instance the connection_mutex) during removing an MST
connector that would prevent doing a modeset at the same time.

Adding the refcounting for such MST connectors (via the
drm_connector_get()/drm_connector_put()) got rid of the above problem.

> 
> > The check
> > for that also makes driver internal modesets more cumbersome where we
> > need to add exemptions for the cases where we do need to allow the
> > modeset even for unregistered connectors. One such case is the
> > restoration of the mode during resume.
> 
> Yeah this one actually makes sense to me. We could still keep this check
> here, but for the atomic ioctl only when called from userspace. But iirc
> Lyude also said she has some plans here, so no idea whether that all fits.
> 
> > Simplify things by removing the unneeded check. I can't see how
> > modesetting an unregistered connector can cause any problem and the race
> > (described in the code comment) can anyway result in such a modeset (if
> > the connector is unregistered right after the check).
> 
> Not saying we don't need this, but there's fairly enormous amounts of
> history behind all this stuff, and lots of discussions. Would be good to
> at least reference those, so we have a good story for when this then all
> goes wrong again.

I still don't see why this check is needed. There is no justification
for it - besides the original reason for it as discussed above about the
refcounting problem, which is solved now - so I think we should remove
it, instead of just making it a special case for the user space modeset.

As I wrote a user space modeset can end up anyway doing a modeset on an
unregistered connector when the unregistering - by MST core - happens just
right after the check.

> -Daniel
> 
> > 
> > Cc: Lyude Paul 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
> >  1 file changed, 2 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 2e0cb4246cbd..e94e69483498 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state 
> > *state,
> > return 0;
> > }
> >  
> > -   crtc_state = drm_atomic_get_new_crtc_state(state,
> > -  new_connector_state->crtc);
> > -   /*
> > -* For compatibility with legacy users, we want to make sure that
> > -* we allow DPMS On->Off modesets on unregistered connectors. Modesets
> > -* which would result in anything else must be considered invalid, to
> > -* avoid turning on new displays on dead connectors.
> > -*
> > -* Since the connector can be unregistered at any point during an
> > -* atomic check or commit, this is racy. But that's OK: all we care
> > -* about is ensuring that userspace can't do anything but shut off the
> > -* display on a connector that was destroyed after it's been notified,
> > -* not before.
> > -*
> > -* Additionally, we also want to ignore connector registration when
> > -* we're trying to restore an atomic state during system resume since
> > -* there's a chance the connector may have been destroyed during the
> > -* process, but it's better to ignore that then cause
> > -* drm_atomic_helper_resume() to fail.
> > -*/
> > -   if (!state->duplicated && drm_connector_is_unregistered(connector) &&
> > -   crtc_state->active) {
> > -   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
> > -connector->base.id, connector->name);
> > -   return -EINVAL;
> > -   }
> > -
> > funcs = connector->helper_private;
> >  
> > if (funcs->atomic_best_encoder)
> > @@ -390,6 +363,8 @@ update_connector_routing(struct drm_atomic_state *state,
> >  
> > set_best_encoder(state, new_connector_state, new_encoder);
> >  
> > +   crtc_state = 

Re: [Intel-gfx] [PATCH 18/33] fbdev: make unregister/unlink functions not fail

[kbuild test robot]

Hi Daniel,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.2-rc1 next-20190520]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbcon-notifier-begone/20190521-021841
config: x86_64-randconfig-x004-201920 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   drivers/video/fbdev/neofb.c: In function 'neofb_remove':
>> drivers/video/fbdev/neofb.c:2130:7: error: void value not ignored as it 
>> ought to be
  if (unregister_framebuffer(info))
  ^~

vim +2130 drivers/video/fbdev/neofb.c

^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2117  
48c68c4f drivers/video/neofb.c Greg Kroah-Hartman 2012-12-21  2118  static void 
neofb_remove(struct pci_dev *dev)
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2119  {
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2120  struct 
fb_info *info = pci_get_drvdata(dev);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2121  
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2122  
DBG("neofb_remove");
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2123  
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2124  if 
(info) {
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2125  
/*
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2126  
 * If unregister_framebuffer fails, then
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2127  
 * we will be leaving hooks that could cause
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2128  
 * oopsen laying around.
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2129  
 */
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16 @2130  
if (unregister_framebuffer(info))
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2131  
printk(KERN_WARNING
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2132  
   "neofb: danger danger!  Oopsen imminent!\n");
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2133  
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2134  
neo_unmap_video(info);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2135  
fb_destroy_modedb(info->monspecs.modedb);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2136  
neo_unmap_mmio(info);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2137  
neo_free_fb_info(info);
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2138  }
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2139  }
^1da177e drivers/video/neofb.c Linus Torvalds 2005-04-16  2140  

:: The code at line 2130 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110702] segfault in radeonsi HEVC hardware decoding with yuv420p10le

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110702

Pierre Ossman  changed:

   What|Removed |Added

Summary|segfault in radeonsi HEVC   |segfault in radeonsi HEVC
   |hardware decoding   |hardware decoding with
   ||yuv420p10le

--- Comment #3 from Pierre Ossman  ---
I found a lower resolution yuv420p10le video, and it crashes the same way. So
it seems the pixel format is the key issue here, not the resolution.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 0/6] drm: make headers self-contained

[Daniel Vetter]

On Sun, May 19, 2019 at 04:20:30PM +0200, Sam Ravnborg wrote:
> While removing use of drmP.h from files in drm/* I
> noticed that I had to add the same include files due to
> build errors in the header files.
> 
> It is better to let the header files include what is necessary
> and let the users pull in only the additional headers files required.
> So I went ahead and made the header files self-conatined.
> (I did not check if this made any includes redundant in some files,
> I do not have tooling in place to do so).

I think it'd be great to make sure this keeps being the case. Jani Nikula
just pointed me at some neat stuff in drm/i915/Makefile.header-test.

I think it'd be nice to have something similar for drm headers in
drivers/gpu/drm, behind a Kconfig option perhaps so that it doesn't upset
people, but 0day will still spot issues. That would also make the series
easier to review, since each patch would add the header it fixes to that
build target.
 
> These patches are preparation for removing use of drmP.h in all
> the files in drm/*
> 
> I have the patchset ready - one patch per file.
> It is a lot of small patches (59) and maybe it is better to
> squash them all into one big patch. Any opinions on this?

Imo fine to have a huge patch pile for this.

> I will await feedback on this patchset before sending the
> patch(es) to remove drmP.h in drm/*

Sounds good.

Cheers, Daniel

> 
>   Sam
> 
> Sam Ravnborg (6):
>   drm: make drm_auth.h self contained
>   drm: make drm_legacy.h self-contained
>   drm: make drm_crtc_internal.h self-contained
>   drm: make drm_internal.h self-contained
>   drm: make drm_legacy.h self-contained
>   drm: make drm_trace.h self-contained
> 
>  drivers/gpu/drm/drm_crtc_internal.h | 24 
>  drivers/gpu/drm/drm_internal.h  | 10 +-
>  drivers/gpu/drm/drm_legacy.h|  4 
>  drivers/gpu/drm/drm_trace.h |  2 ++
>  include/drm/drm_auth.h  |  7 +++
>  include/drm/drm_legacy.h|  2 ++
>  6 files changed, 44 insertions(+), 5 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] gpu: drm: use struct_size() in kmalloc()

[Gustavo A. R. Silva]

On 5/20/19 12:41 PM, Alex Deucher wrote:
> On Fri, May 17, 2019 at 8:43 AM xiaolinkui  wrote:
>>
>> Use struct_size() helper to keep code simple.
>>

Again, this is not the reason why this helper was created.

>> Signed-off-by: xiaolinkui 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> This patch results in the following build error:
>   DESCEND  objtool
>   CALLscripts/checksyscalls.sh
>   CHK include/generated/compile.h
>   CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.o
> In file included from ./include/linux/kernel.h:15,
>  from ./include/linux/list.h:9,
>  from ./include/linux/wait.h:7,
>  from ./include/linux/wait_bit.h:8,
>  from ./include/linux/fs.h:6,
>  from ./include/linux/debugfs.h:15,
>  from drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:24:
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c: In function ‘amdgpu_ras_init’:
> ./include/linux/build_bug.h:16:45: error: negative width in bit-field
> ‘’
>  #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
>  ^
> ./include/linux/compiler.h:349:28: note: in expansion of macro
> ‘BUILD_BUG_ON_ZERO’
>  #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> ^
> ./include/linux/overflow.h:306:30: note: in expansion of macro 
> ‘__must_be_array’
>sizeof(*(p)->member) + __must_be_array((p)->member),\
>   ^~~
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1556:16: note: in expansion of
> macro ‘struct_size’
>   con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
> ^~~
> make[4]: *** [scripts/Makefile.build:276:
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.o] Error 1
> make[4]: *** Waiting for unfinished jobs
> make[3]: *** [scripts/Makefile.build:492: drivers/gpu/drm/amd/amdgpu] Error 2
> make[3]: *** Waiting for unfinished jobs
> make[2]: *** [scripts/Makefile.build:492: drivers/gpu/drm] Error 2
> make[1]: *** [scripts/Makefile.build:492: drivers/gpu] Error 2
> make: *** [Makefile:1042: drivers] Error 2
> 
> Alex
> 

You continue[1][2] sending these sorts of patches without really understanding 
what
you are doing. And you don't even compile them. Why?

--
Gustavo

[1] https://lore.kernel.org/lkml/d83390a9-33be-3d76-3e23-b97f0a05b...@kernel.dk/
[2] https://lore.kernel.org/lkml/b4d33107-75d5-fa18-536e-6d21c96e4...@kernel.dk/

> 
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> index 22bd21e..4717a64 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
>> @@ -1375,8 +1375,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev)
>> if (con)
>> return 0;
>>
>> -   con = kmalloc(sizeof(struct amdgpu_ras) +
>> -   sizeof(struct ras_manager) * AMDGPU_RAS_BLOCK_COUNT,
>> +   con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
>> GFP_KERNEL|__GFP_ZERO);
>> if (!con)
>> return -ENOMEM;
>> --
>> 2.7.4
>>
>>
>>
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 0/4] drm/gma500: drop use of drmP.h

[Daniel Vetter]

On Sun, May 19, 2019 at 03:51:05PM +0200, Sam Ravnborg wrote:
> The following patchset remove use of the deprecated drmP.h
> header file in the gma500 driver.
> As preparation an empty header file is removed and a dependency on
> drm_os_linux.h is dropped.
> The list of include files are sorted and is some cases divided
> up in blocks of linux/* drm/* etc.
> 
> Build tested with allmodconfig and allyesconfig for x86, arm, alpha and more.
> 
> Patchset made on top of drm-misc-next

Nice series! On the entire pile:

Acked-by: Daniel Vetter 

Since gma500 is defacto unmaintained I think that's good enough, as long
as you don't break anything. Maybe wait a bit before merging it all.

Aside, I entirely forgot about drm_os_linux.h. That's another file we
should kill with fire I think :-) Probably best done macro-by-macro or so
...

Cheers, Daniel
> 
>   Sam
> 
> Sam Ravnborg (4):
>   drm/gma500: remove empty gma_drm.h header file
>   drm/gma500: drop drmP.h from header files
>   drm/gma500: drop use of DRM_UDELAY wrapper
>   drm/gma500: drop drmp.h include from all .c files
> 
>  drivers/gpu/drm/gma500/accel_2d.c |  2 +-
>  drivers/gpu/drm/gma500/cdv_device.c   |  5 +++--
>  drivers/gpu/drm/gma500/cdv_intel_crt.c|  2 +-
>  drivers/gpu/drm/gma500/cdv_intel_display.c|  4 +++-
>  drivers/gpu/drm/gma500/cdv_intel_dp.c |  7 ---
>  drivers/gpu/drm/gma500/cdv_intel_hdmi.c   |  5 +++--
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  5 ++---
>  drivers/gpu/drm/gma500/framebuffer.c  |  2 +-
>  drivers/gpu/drm/gma500/framebuffer.h  |  1 -
>  drivers/gpu/drm/gma500/gem.c  |  5 +++--
>  drivers/gpu/drm/gma500/gma_device.c   |  1 -
>  drivers/gpu/drm/gma500/gma_display.c  |  8 +++-
>  drivers/gpu/drm/gma500/gtt.c  |  3 ++-
>  drivers/gpu/drm/gma500/gtt.h  |  1 -
>  drivers/gpu/drm/gma500/intel_bios.c   |  4 ++--
>  drivers/gpu/drm/gma500/intel_bios.h   |  3 +--
>  drivers/gpu/drm/gma500/intel_gmbus.c  |  9 +
>  drivers/gpu/drm/gma500/intel_i2c.c|  3 ++-
>  drivers/gpu/drm/gma500/mdfld_device.c |  6 --
>  drivers/gpu/drm/gma500/mdfld_dsi_dpi.c|  2 ++
>  drivers/gpu/drm/gma500/mdfld_dsi_output.c |  5 +++--
>  drivers/gpu/drm/gma500/mdfld_dsi_output.h |  2 +-
>  drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c |  2 ++
>  drivers/gpu/drm/gma500/mdfld_intel_display.c  |  5 -
>  drivers/gpu/drm/gma500/mdfld_tmd_vid.c|  2 ++
>  drivers/gpu/drm/gma500/mid_bios.c |  3 +--
>  drivers/gpu/drm/gma500/mmu.c  |  4 +++-
>  drivers/gpu/drm/gma500/oaktrail_crtc.c|  4 +++-
>  drivers/gpu/drm/gma500/oaktrail_device.c  |  7 ---
>  drivers/gpu/drm/gma500/oaktrail_hdmi.c|  6 --
>  drivers/gpu/drm/gma500/oaktrail_lvds.c|  4 ++--
>  drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c|  1 -
>  drivers/gpu/drm/gma500/power.h|  4 +++-
>  drivers/gpu/drm/gma500/psb_device.c   |  4 ++--
>  drivers/gpu/drm/gma500/psb_drv.c  | 26 +-
>  drivers/gpu/drm/gma500/psb_drv.h  |  4 ++--
>  drivers/gpu/drm/gma500/psb_intel_display.c|  3 ++-
>  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  3 +--
>  drivers/gpu/drm/gma500/psb_intel_modes.c  |  2 +-
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c   | 10 +-
>  drivers/gpu/drm/gma500/psb_irq.c  |  3 ++-
>  drivers/gpu/drm/gma500/psb_irq.h  |  2 +-
>  drivers/gpu/drm/gma500/psb_lid.c  |  4 ++--
>  drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c|  8 +---
>  include/drm/gma_drm.h | 25 -
>  45 files changed, 118 insertions(+), 103 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] drm: Allow modeset on unregisted connectors unconditionally

[Daniel Vetter]

On Mon, May 20, 2019 at 08:41:09PM +0300, Imre Deak wrote:
> We allowed modesetting an unregistered connector only in the case the
> mode is getting disabled on the connector.
> 
> The reason for this check was the lack of proper refcounting for the
> backing memory objects. That problem has been solved meanwhile so there
> is no reason any more to reject the modesetting in general.

I'm not parsing this at all ... maybe references to the commits that fix
this? Or do you mean the refcounting work for all the things hanging of
connectors, including the entire mst tree?

> The check
> for that also makes driver internal modesets more cumbersome where we
> need to add exemptions for the cases where we do need to allow the
> modeset even for unregistered connectors. One such case is the
> restoration of the mode during resume.

Yeah this one actually makes sense to me. We could still keep this check
here, but for the atomic ioctl only when called from userspace. But iirc
Lyude also said she has some plans here, so no idea whether that all fits.

> Simplify things by removing the unneeded check. I can't see how
> modesetting an unregistered connector can cause any problem and the race
> (described in the code comment) can anyway result in such a modeset (if
> the connector is unregistered right after the check).

Not saying we don't need this, but there's fairly enormous amounts of
history behind all this stuff, and lots of discussions. Would be good to
at least reference those, so we have a good story for when this then all
goes wrong again.
-Daniel

> 
> Cc: Lyude Paul 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
>  1 file changed, 2 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2e0cb4246cbd..e94e69483498 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state *state,
>   return 0;
>   }
>  
> - crtc_state = drm_atomic_get_new_crtc_state(state,
> -new_connector_state->crtc);
> - /*
> -  * For compatibility with legacy users, we want to make sure that
> -  * we allow DPMS On->Off modesets on unregistered connectors. Modesets
> -  * which would result in anything else must be considered invalid, to
> -  * avoid turning on new displays on dead connectors.
> -  *
> -  * Since the connector can be unregistered at any point during an
> -  * atomic check or commit, this is racy. But that's OK: all we care
> -  * about is ensuring that userspace can't do anything but shut off the
> -  * display on a connector that was destroyed after it's been notified,
> -  * not before.
> -  *
> -  * Additionally, we also want to ignore connector registration when
> -  * we're trying to restore an atomic state during system resume since
> -  * there's a chance the connector may have been destroyed during the
> -  * process, but it's better to ignore that then cause
> -  * drm_atomic_helper_resume() to fail.
> -  */
> - if (!state->duplicated && drm_connector_is_unregistered(connector) &&
> - crtc_state->active) {
> - DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
> -  connector->base.id, connector->name);
> - return -EINVAL;
> - }
> -
>   funcs = connector->helper_private;
>  
>   if (funcs->atomic_best_encoder)
> @@ -390,6 +363,8 @@ update_connector_routing(struct drm_atomic_state *state,
>  
>   set_best_encoder(state, new_connector_state, new_encoder);
>  
> + crtc_state = drm_atomic_get_new_crtc_state(state,
> +new_connector_state->crtc);
>   crtc_state->connectors_changed = true;
>  
>   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
> [CRTC:%d:%s]\n",
> -- 
> 2.17.1
> 

-- 
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 v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Doug Anderson]

Thierry,

On Mon, Apr 8, 2019 at 7:39 AM Doug Anderson  wrote:
>
> Thierry,
>
> On Mon, Apr 8, 2019 at 3:32 AM Thierry Reding  
> wrote:
> >
> > On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > > From: Sean Paul 
> > >
> > > This patch adds a new subnode to simple-panel allowing us to override
> > > the typical timing expressed in the panel's display_timing.
> > >
> > > Changes in v2:
> > >  - Split out the binding into a new patch (Rob)
> > >  - display-timings is a new section (Rob)
> > >  - Use the full display-timings subnode instead of picking the timing
> > >out (Rob/Thierry)
> > > Changes in v3:
> > >  - Go back to using the timing subnode directly, but rename to
> > >panel-timing (Rob)
> > > Changes in v4:
> > >  - Simplify desc. for when override should be used (Thierry/Laurent)
> > >  - Removed Rob H review since it's been a year and wording changed
> > > Changes in v5:
> > >  - Removed bit about OS may ignore (Rob/Ezequiel)
> > >
> > > Cc: Doug Anderson 
> > > Cc: Eric Anholt 
> > > Cc: Heiko Stuebner 
> > > Cc: Jeffy Chen 
> > > Cc: Rob Herring 
> > > Cc: Stéphane Marchesin 
> > > Cc: Thierry Reding 
> > > Cc: devicet...@vger.kernel.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linux-rockc...@lists.infradead.org
> > > Signed-off-by: Sean Paul 
> > > Signed-off-by: Douglas Anderson 
> > > ---
> > >
> > >  .../bindings/display/panel/simple-panel.txt   | 22 +++
> > >  1 file changed, 22 insertions(+)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
> > > b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > > index b2b872c710f2..93882268c0b9 100644
> > > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > > @@ -15,6 +15,16 @@ Optional properties:
> > >(hot plug detect) signal, but the signal isn't hooked up so we should
> > >hardcode the max delay from the panel spec when powering up the panel.
> > >
> > > +panel-timing subnode
> >
> > Is there any reason why we need the panel- prefix? This is already part
> > of a panel definition, so it's completely redundant. Why not just name
> > the subnode "timing"?
>
> It was a really long time ago since this patch series was idle for a
> while, but you previous had similar feedback in v3 but ended up OK
> with it.  See:
>
> https://patchwork.kernel.org/patch/10207583/
>
> I believe the original node name came out of some back and forth
> between Rob and Sean.  As far as I can tell, the context is back in
> .  I think Rob wanted it
> to follow other similar node names.
>
>
> That all being said, if you feel strongly about it being called
> "timing" and Rob's OK w/ that too then I'll re-spin the series.

With 5.2-rc1 out, maybe this series is ready to land?  If you'd like
me to change things as per above I can.  ...but it feels like keeping
the already-agreed-upon name might be easiest / best?  Presumably
you'd land patches 1, 2, 4, and 5 and then Heiko could land the dts
patches?

Thanks!

-Doug

Re: [PATCH v2 2/2] drm/bridge: drop drmP.h usage

[Sam Ravnborg]

On Mon, May 20, 2019 at 12:22:35AM +0300, Laurent Pinchart wrote:
> Hi Sam,
> 
> Thank you for the patch.
> 
> On Sun, May 19, 2019 at 08:36:36PM +0200, Sam Ravnborg wrote:
> > Drop use of the deprecated drmP.h header file.
> > 
> > While touching the list of include files:
> > - Divide include files in blocks of linux/* drm/* etc.
> > - Sort individual blocks of include files
> > - Remove duplicated header file
> > 
> > v2:
> > - Be consistent in the order of the include blocks (Laurent)
> > 
> > Signed-off-by: Sam Ravnborg 
> > Cc: Andrzej Hajda 
> > Cc: Laurent Pinchart 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Peter Senna Tschudin 
> > Cc: Martin Donnelly 
> > Cc: Martyn Welch 
> 
> Reviewed-by: Laurent Pinchart 
> 
> By the way, on a side note, I came across a neat trick recently to help
> making headers self-contained. By including the header related to a C
> file as the very first header, the compiler will throw an error if the
> header is not self-contained. It would be a bit of an intrusive change
> in DRM, but maybe something to keep in mind.

In some projects I have worked with the rule was to include the most
specific headers first - so we would caugth early if a header file missed
something.

But as long as having all header files self-contained are not a hard
rule we should not try to do something like this.

I once went through all the drm header files to make them minimal and
self-contained.
But this triggered a massive update of all drm drivers / core files
so I skipped that again. The pain/gain ratio was far to high.
Just making them all self-contained is is smaller task that does
not break the build - but until now I have not seen any good reasons /
demands for this so I have left it.

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

Re: [PATCH 27/33] fbdev: remove FBINFO_MISC_USEREVENT around fb_blank

[Sam Ravnborg]

Hi Daniel.

On Mon, May 20, 2019 at 07:29:52PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 7:20 PM Sam Ravnborg  wrote:
> >
> > Hi Daniel.
> >
> > > With the recursion broken in the previous patch we can drop the
> > > FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> > > prevention was it's only job.
> > >
> > When grepping for FBINFO_MISC_USEREVENT I get a few hits not addressed
> > in the patch below:
> >
> > drivers/video/fbdev/core/fbcon.c:   if (!(info->flags & 
> > FBINFO_MISC_USEREVENT))
> > drivers/video/fbdev/core/fbmem.c:   if (!ret && (flags 
> > & FBINFO_MISC_USEREVENT)) {
> > drivers/video/fbdev/core/fbmem.c:   info->flags 
> > &= ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbmem.c:   info->flags |= 
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbmem.c:   info->flags &= 
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbmem.c:   info->flags |= 
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbmem.c:   info->flags &= 
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |= 
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &= 
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |= 
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &= 
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/ps3fb.c:info->flags |= 
> > FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/ps3fb.c:info->flags &= 
> > ~FBINFO_MISC_USEREVENT;
> > drivers/video/fbdev/sh_mobile_lcdcfb.c:  * FBINFO_MISC_USEREVENT flag is 
> > set. Since we do not want to fake a
> > include/linux/fb.h:#define FBINFO_MISC_USEREVENT  0x1 /* event 
> > request
> >
> > The use in ps3fb looks like a candidate for removal and this file is not
> > touch in this patch series, so I guess I did not miss it.
> >
> > As I did not apply the full series maybe some of the other users was
> > already taken care of.
> 
> It's also used to break recursion around fb_set_par and fb_set_pan.
> Untangling that one would be possible, but also requires untangling
> some locking, so a lot more work. If you chase all the call paths then
> you'll noticed that the users still left have no overlap with the ones
> I'm removing here.
Now you spell it out it is obvious. I guess I never read more than fb_
and missed that we are dealing with different calls.
Thanks for the quick feedback, and sorry for the noise.

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

Re: [PATCH] gpu: drm: use struct_size() in kmalloc()

[Alex Deucher]

On Fri, May 17, 2019 at 8:43 AM xiaolinkui  wrote:
>
> Use struct_size() helper to keep code simple.
>
> Signed-off-by: xiaolinkui 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

This patch results in the following build error:
  DESCEND  objtool
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.o
In file included from ./include/linux/kernel.h:15,
 from ./include/linux/list.h:9,
 from ./include/linux/wait.h:7,
 from ./include/linux/wait_bit.h:8,
 from ./include/linux/fs.h:6,
 from ./include/linux/debugfs.h:15,
 from drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:24:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c: In function ‘amdgpu_ras_init’:
./include/linux/build_bug.h:16:45: error: negative width in bit-field
‘’
 #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:(-!!(e)); }))
 ^
./include/linux/compiler.h:349:28: note: in expansion of macro
‘BUILD_BUG_ON_ZERO’
 #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
^
./include/linux/overflow.h:306:30: note: in expansion of macro ‘__must_be_array’
   sizeof(*(p)->member) + __must_be_array((p)->member),\
  ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1556:16: note: in expansion of
macro ‘struct_size’
  con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
^~~
make[4]: *** [scripts/Makefile.build:276:
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [scripts/Makefile.build:492: drivers/gpu/drm/amd/amdgpu] Error 2
make[3]: *** Waiting for unfinished jobs
make[2]: *** [scripts/Makefile.build:492: drivers/gpu/drm] Error 2
make[1]: *** [scripts/Makefile.build:492: drivers/gpu] Error 2
make: *** [Makefile:1042: drivers] Error 2

Alex


>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 22bd21e..4717a64 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1375,8 +1375,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev)
> if (con)
> return 0;
>
> -   con = kmalloc(sizeof(struct amdgpu_ras) +
> -   sizeof(struct ras_manager) * AMDGPU_RAS_BLOCK_COUNT,
> +   con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
> GFP_KERNEL|__GFP_ZERO);
> if (!con)
> return -ENOMEM;
> --
> 2.7.4
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Allow modeset on unregisted connectors unconditionally

[Imre Deak]

We allowed modesetting an unregistered connector only in the case the
mode is getting disabled on the connector.

The reason for this check was the lack of proper refcounting for the
backing memory objects. That problem has been solved meanwhile so there
is no reason any more to reject the modesetting in general. The check
for that also makes driver internal modesets more cumbersome where we
need to add exemptions for the cases where we do need to allow the
modeset even for unregistered connectors. One such case is the
restoration of the mode during resume.

Simplify things by removing the unneeded check. I can't see how
modesetting an unregistered connector can cause any problem and the race
(described in the code comment) can anyway result in such a modeset (if
the connector is unregistered right after the check).

Cc: Lyude Paul 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_atomic_helper.c | 29 ++---
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 2e0cb4246cbd..e94e69483498 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -319,33 +319,6 @@ update_connector_routing(struct drm_atomic_state *state,
return 0;
}
 
-   crtc_state = drm_atomic_get_new_crtc_state(state,
-  new_connector_state->crtc);
-   /*
-* For compatibility with legacy users, we want to make sure that
-* we allow DPMS On->Off modesets on unregistered connectors. Modesets
-* which would result in anything else must be considered invalid, to
-* avoid turning on new displays on dead connectors.
-*
-* Since the connector can be unregistered at any point during an
-* atomic check or commit, this is racy. But that's OK: all we care
-* about is ensuring that userspace can't do anything but shut off the
-* display on a connector that was destroyed after it's been notified,
-* not before.
-*
-* Additionally, we also want to ignore connector registration when
-* we're trying to restore an atomic state during system resume since
-* there's a chance the connector may have been destroyed during the
-* process, but it's better to ignore that then cause
-* drm_atomic_helper_resume() to fail.
-*/
-   if (!state->duplicated && drm_connector_is_unregistered(connector) &&
-   crtc_state->active) {
-   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
-connector->base.id, connector->name);
-   return -EINVAL;
-   }
-
funcs = connector->helper_private;
 
if (funcs->atomic_best_encoder)
@@ -390,6 +363,8 @@ update_connector_routing(struct drm_atomic_state *state,
 
set_best_encoder(state, new_connector_state, new_encoder);
 
+   crtc_state = drm_atomic_get_new_crtc_state(state,
+  new_connector_state->crtc);
crtc_state->connectors_changed = true;
 
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
[CRTC:%d:%s]\n",
-- 
2.17.1

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

Re: [PATCH 27/33] fbdev: remove FBINFO_MISC_USEREVENT around fb_blank

[Daniel Vetter]

On Mon, May 20, 2019 at 7:20 PM Sam Ravnborg  wrote:
>
> Hi Daniel.
>
> > With the recursion broken in the previous patch we can drop the
> > FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> > prevention was it's only job.
> >
> When grepping for FBINFO_MISC_USEREVENT I get a few hits not addressed
> in the patch below:
>
> drivers/video/fbdev/core/fbcon.c:   if (!(info->flags & 
> FBINFO_MISC_USEREVENT))
> drivers/video/fbdev/core/fbmem.c:   if (!ret && (flags & 
> FBINFO_MISC_USEREVENT)) {
> drivers/video/fbdev/core/fbmem.c:   info->flags 
> &= ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbmem.c:   info->flags |= 
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbmem.c:   info->flags &= 
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbmem.c:   info->flags |= 
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbmem.c:   info->flags &= 
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |= 
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &= 
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |= 
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &= 
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/ps3fb.c:info->flags |= 
> FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/ps3fb.c:info->flags &= 
> ~FBINFO_MISC_USEREVENT;
> drivers/video/fbdev/sh_mobile_lcdcfb.c:  * FBINFO_MISC_USEREVENT flag is set. 
> Since we do not want to fake a
> include/linux/fb.h:#define FBINFO_MISC_USEREVENT  0x1 /* event 
> request
>
> The use in ps3fb looks like a candidate for removal and this file is not
> touch in this patch series, so I guess I did not miss it.
>
> As I did not apply the full series maybe some of the other users was
> already taken care of.

It's also used to break recursion around fb_set_par and fb_set_pan.
Untangling that one would be possible, but also requires untangling
some locking, so a lot more work. If you chase all the call paths then
you'll noticed that the users still left have no overlap with the ones
I'm removing here.
-Daniel

>
>
> Sam
>
> > Signed-off-by: Daniel Vetter 
> > Cc: Daniel Vetter 
> > Cc: Bartlomiej Zolnierkiewicz 
> > Cc: Hans de Goede 
> > Cc: Yisheng Xie 
> > Cc: "Michał Mirosław" 
> > Cc: Peter Rosin 
> > Cc: Mikulas Patocka 
> > Cc: Rob Clark 
> > ---
> >  drivers/video/fbdev/core/fbcon.c   | 5 ++---
> >  drivers/video/fbdev/core/fbmem.c   | 3 ---
> >  drivers/video/fbdev/core/fbsysfs.c | 2 --
> >  3 files changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c 
> > b/drivers/video/fbdev/core/fbcon.c
> > index f85d794a3bee..c1a7476e980f 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2382,9 +2382,8 @@ static int fbcon_blank(struct vc_data *vc, int blank, 
> > int mode_switch)
> >   fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
> >   ops->cursor_flash = (!blank);
> >
> > - if (!(info->flags & FBINFO_MISC_USEREVENT))
> > - if (fb_blank(info, blank))
> > - fbcon_generic_blank(vc, info, blank);
> > + if (fb_blank(info, blank))
> > + fbcon_generic_blank(vc, info, blank);
> >   }
> >
> >   if (!blank)
> > diff --git a/drivers/video/fbdev/core/fbmem.c 
> > b/drivers/video/fbdev/core/fbmem.c
> > index 7f95c7e80155..65a075ccac4a 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1194,10 +1194,7 @@ static long do_fb_ioctl(struct fb_info *info, 
> > unsigned int cmd,
> >   case FBIOBLANK:
> >   console_lock();
> >   lock_fb_info(info);
> > - info->flags |= FBINFO_MISC_USEREVENT;
> >   ret = fb_blank(info, arg);
> > - info->flags &= ~FBINFO_MISC_USEREVENT;
> > -
> >   /* might again call into fb_blank */
> >   fbcon_fb_blanked(info, arg);
> >   unlock_fb_info(info);
> > diff --git a/drivers/video/fbdev/core/fbsysfs.c 
> > b/drivers/video/fbdev/core/fbsysfs.c
> > index 252d4f52d2a5..882b471d619e 100644
> > --- a/drivers/video/fbdev/core/fbsysfs.c
> > +++ b/drivers/video/fbdev/core/fbsysfs.c
> > @@ -310,9 +310,7 @@ static ssize_t store_blank(struct device *device,
> >
> >   arg = simple_strtoul(buf, , 0);
> >   console_lock();
> > - fb_info->flags |= FBINFO_MISC_USEREVENT;
> >   err = fb_blank(fb_info, arg);
> > - fb_info->flags &= ~FBINFO_MISC_USEREVENT;
> >   /* might again call into fb_blank */
> >   fbcon_fb_blanked(fb_info, arg);
> >   console_unlock();
> > --
> > 2.20.1
> >
> 

Re: [PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly

[Daniel Vetter]

On Mon, May 20, 2019 at 7:08 PM Sam Ravnborg  wrote:
>
> Hi Daniel.
>
> While browsing this nice patch series I stumbled upon a detail.
>
> On Mon, May 20, 2019 at 10:21:53AM +0200, Daniel Vetter wrote:
> > With
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter 
> > Date:   Tue Aug 1 17:32:07 2017 +0200
> >
> > fbcon: Make fbcon a built-time depency for fbdev
> >
> > we have a static dependency between fbcon and fbdev, and we can
> > replace the indirection through the notifier chain with a function
> > call.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Bartlomiej Zolnierkiewicz 
> > Cc: Daniel Vetter 
> > Cc: Hans de Goede 
> > Cc: Greg Kroah-Hartman 
> > Cc: "Noralf Trønnes" 
> > Cc: Yisheng Xie 
> > Cc: Peter Rosin 
> > Cc: "Michał Mirosław" 
> > Cc: Thomas Zimmermann 
> > Cc: Mikulas Patocka 
> > Cc: linux-fb...@vger.kernel.org
> > ---
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index f52ef0ad6781..701abaf79c87 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -136,10 +136,6 @@ struct fb_cursor_user {
> >  #define FB_EVENT_RESUME  0x03
> >  /*  An entry from the modelist was removed */
> >  #define FB_EVENT_MODE_DELETE0x04
> > -/*  A driver registered itself */
> > -#define FB_EVENT_FB_REGISTERED  0x05
> > -/*  A driver unregistered itself */
> > -#define FB_EVENT_FB_UNREGISTERED0x06
> >  /*  CONSOLE-SPECIFIC: get console to framebuffer mapping */
> >  #define FB_EVENT_GET_CONSOLE_MAP0x07
> >  /*  CONSOLE-SPECIFIC: set console to framebuffer mapping */
>
> This breaks build of arch/arm/mach-pxa/am200epd.c thats uses
> FB_EVENT_FB_*REGISTERED:
>
>
>if (event == FB_EVENT_FB_REGISTERED)
> return am200_share_video_mem(info);
> else if (event == FB_EVENT_FB_UNREGISTERED)
> return am200_unshare_video_mem(info);
>
>
> Found while grepping for "FB_EVENT" so this is not a build
> error I triggered.

Oh this is glorious :-/

Thanks a lot for spotting this, I guess I need to hack around on
metronomefb a bit ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 27/33] fbdev: remove FBINFO_MISC_USEREVENT around fb_blank

[Sam Ravnborg]

Hi Daniel.

> With the recursion broken in the previous patch we can drop the
> FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
> prevention was it's only job.
> 
When grepping for FBINFO_MISC_USEREVENT I get a few hits not addressed
in the patch below:

drivers/video/fbdev/core/fbcon.c:   if (!(info->flags & 
FBINFO_MISC_USEREVENT))
drivers/video/fbdev/core/fbmem.c:   if (!ret && (flags & 
FBINFO_MISC_USEREVENT)) {
drivers/video/fbdev/core/fbmem.c:   info->flags &= 
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbmem.c:   info->flags |= 
FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbmem.c:   info->flags &= 
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbmem.c:   info->flags |= 
FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbmem.c:   info->flags &= 
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |= FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &= 
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbsysfs.c: fb_info->flags |= FBINFO_MISC_USEREVENT;
drivers/video/fbdev/core/fbsysfs.c: fb_info->flags &= 
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/ps3fb.c:info->flags |= 
FBINFO_MISC_USEREVENT;
drivers/video/fbdev/ps3fb.c:info->flags &= 
~FBINFO_MISC_USEREVENT;
drivers/video/fbdev/sh_mobile_lcdcfb.c:  * FBINFO_MISC_USEREVENT flag is set. 
Since we do not want to fake a
include/linux/fb.h:#define FBINFO_MISC_USEREVENT  0x1 /* event 
request

The use in ps3fb looks like a candidate for removal and this file is not
touch in this patch series, so I guess I did not miss it.

As I did not apply the full series maybe some of the other users was
already taken care of.


Sam

> Signed-off-by: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Hans de Goede 
> Cc: Yisheng Xie 
> Cc: "Michał Mirosław" 
> Cc: Peter Rosin 
> Cc: Mikulas Patocka 
> Cc: Rob Clark 
> ---
>  drivers/video/fbdev/core/fbcon.c   | 5 ++---
>  drivers/video/fbdev/core/fbmem.c   | 3 ---
>  drivers/video/fbdev/core/fbsysfs.c | 2 --
>  3 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fbcon.c 
> b/drivers/video/fbdev/core/fbcon.c
> index f85d794a3bee..c1a7476e980f 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2382,9 +2382,8 @@ static int fbcon_blank(struct vc_data *vc, int blank, 
> int mode_switch)
>   fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
>   ops->cursor_flash = (!blank);
>  
> - if (!(info->flags & FBINFO_MISC_USEREVENT))
> - if (fb_blank(info, blank))
> - fbcon_generic_blank(vc, info, blank);
> + if (fb_blank(info, blank))
> + fbcon_generic_blank(vc, info, blank);
>   }
>  
>   if (!blank)
> diff --git a/drivers/video/fbdev/core/fbmem.c 
> b/drivers/video/fbdev/core/fbmem.c
> index 7f95c7e80155..65a075ccac4a 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1194,10 +1194,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned 
> int cmd,
>   case FBIOBLANK:
>   console_lock();
>   lock_fb_info(info);
> - info->flags |= FBINFO_MISC_USEREVENT;
>   ret = fb_blank(info, arg);
> - info->flags &= ~FBINFO_MISC_USEREVENT;
> -
>   /* might again call into fb_blank */
>   fbcon_fb_blanked(info, arg);
>   unlock_fb_info(info);
> diff --git a/drivers/video/fbdev/core/fbsysfs.c 
> b/drivers/video/fbdev/core/fbsysfs.c
> index 252d4f52d2a5..882b471d619e 100644
> --- a/drivers/video/fbdev/core/fbsysfs.c
> +++ b/drivers/video/fbdev/core/fbsysfs.c
> @@ -310,9 +310,7 @@ static ssize_t store_blank(struct device *device,
>  
>   arg = simple_strtoul(buf, , 0);
>   console_lock();
> - fb_info->flags |= FBINFO_MISC_USEREVENT;
>   err = fb_blank(fb_info, arg);
> - fb_info->flags &= ~FBINFO_MISC_USEREVENT;
>   /* might again call into fb_blank */
>   fbcon_fb_blanked(fb_info, arg);
>   console_unlock();
> -- 
> 2.20.1
> 
> ___
> 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] gpu: fix typos in code comments

[Alex Deucher]

On Mon, May 20, 2019 at 1:04 PM Weitao Hou  wrote:
>
> fix eror to error
>
> Signed-off-by: Weitao Hou 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> index f70437aae8e0..df422440845b 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
> @@ -183,8 +183,8 @@ static bool calculate_fb_and_fractional_fb_divider(
>  *RETURNS:
>  * It fills the PLLSettings structure with PLL Dividers values
>  * if calculated values are within required tolerance
> -* It returns   - true if eror is within tolerance
> -*  - false if eror is not within tolerance
> +* It returns   - true if error is within tolerance
> +*  - false if error is not within tolerance
>  */
>  static bool calc_fb_divider_checking_tolerance(
> struct calc_pll_clock_source *calc_pll_cs,
> --
> 2.18.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly

[Sam Ravnborg]

Hi Daniel.

While browsing this nice patch series I stumbled upon a detail.

On Mon, May 20, 2019 at 10:21:53AM +0200, Daniel Vetter wrote:
> With
> 
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter 
> Date:   Tue Aug 1 17:32:07 2017 +0200
> 
> fbcon: Make fbcon a built-time depency for fbdev
> 
> we have a static dependency between fbcon and fbdev, and we can
> replace the indirection through the notifier chain with a function
> call.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Daniel Vetter 
> Cc: Hans de Goede 
> Cc: Greg Kroah-Hartman 
> Cc: "Noralf Trønnes" 
> Cc: Yisheng Xie 
> Cc: Peter Rosin 
> Cc: "Michał Mirosław" 
> Cc: Thomas Zimmermann 
> Cc: Mikulas Patocka 
> Cc: linux-fb...@vger.kernel.org
> ---
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index f52ef0ad6781..701abaf79c87 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -136,10 +136,6 @@ struct fb_cursor_user {
>  #define FB_EVENT_RESUME  0x03
>  /*  An entry from the modelist was removed */
>  #define FB_EVENT_MODE_DELETE0x04
> -/*  A driver registered itself */
> -#define FB_EVENT_FB_REGISTERED  0x05
> -/*  A driver unregistered itself */
> -#define FB_EVENT_FB_UNREGISTERED0x06
>  /*  CONSOLE-SPECIFIC: get console to framebuffer mapping */
>  #define FB_EVENT_GET_CONSOLE_MAP0x07
>  /*  CONSOLE-SPECIFIC: set console to framebuffer mapping */

This breaks build of arch/arm/mach-pxa/am200epd.c thats uses
FB_EVENT_FB_*REGISTERED:


   if (event == FB_EVENT_FB_REGISTERED)
return am200_share_video_mem(info);
else if (event == FB_EVENT_FB_UNREGISTERED)
return am200_unshare_video_mem(info);


Found while grepping for "FB_EVENT" so this is not a build
error I triggered.

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

[Bug 110713] A Hat in Time: GPU hang with gallium nine

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110713

ki...@lytoria.de changed:

   What|Removed |Added

 CC||ki...@lytoria.de

--- Comment #1 from ki...@lytoria.de ---
I'd like to add, besides the R9 270X, this also affects Vega (both traces hang
my Vega 64) and Polaris (one user reports the chapter 1, act 4 hang to be 100%
reproducible on his RX 580).

I can also confirm both traces to play fine on my card with AMD_DEBUG=mono on
mesa-git and R600_DEBUG=mono on mesa 19.0.4.

With the NIR backend (R600_DEBUG=nir) it still hangs the same way as with
default TGSI on both 19.0.4 and git.

Note: Both traces are recorded on x64 and may need to be replayed with x64
apitrace to prevent running out of memory during shader compilation.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110717] [Regression][bisected] Patch: update buffer descriptors ... causes hangs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110717

Bug ID: 110717
   Summary: [Regression][bisected]  Patch: update buffer
descriptors ... causes hangs
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: gw.foss...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

With 78e35df52aa2f7d770f929a0866a0faa89c261a9 I see hangs on  [AMD/ATI] Baffin
[Radeon RX 560D  / Pro 450/455/460/555/560] (rev e5). 

Specifically, when I run "Outlast" through a virgl/vtest setup with this
hardware on the host, the whole X-session hangs after the very first loading
screen. I can still log into the machine but even a reboot hangs and a reboot
can only be forced by ctrl-alt-sysrq-B (or turning the laptop on and off). 


I'll try to get a host trace to add a bit more info here.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: drm: use struct_size() in kmalloc()

[Daniel Vetter]

On Fri, May 17, 2019 at 04:44:30PM +, Pan, Xinhui wrote:
> I am going to put more members which are also array after this struct,
> not only obj[].  Looks like this struct_size did not help on multiple
> array case. Thanks anyway.  

You can then add them up, e.g. kmalloc(struct_size()+struct_size(),
GFP_KERNEL), so this patch here still looks like a good idea.

Reviewed-by: Daniel Vetter 

Cheers, Daniel

> From: xiaolinkui 
> Sent: Friday, May 17, 2019 4:46:00 PM
> To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); 
> airl...@linux.ie; dan...@ffwll.ch; Pan, Xinhui; Quan, Evan
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
> linux-ker...@vger.kernel.org; xiaolin...@kylinos.cn
> Subject: [PATCH] gpu: drm: use struct_size() in kmalloc()
> 
> [CAUTION: External Email]
> 
> Use struct_size() helper to keep code simple.
> 
> Signed-off-by: xiaolinkui 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 22bd21e..4717a64 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1375,8 +1375,7 @@ int amdgpu_ras_init(struct amdgpu_device *adev)
> if (con)
> return 0;
> 
> -   con = kmalloc(sizeof(struct amdgpu_ras) +
> -   sizeof(struct ras_manager) * AMDGPU_RAS_BLOCK_COUNT,
> +   con = kmalloc(struct_size(con, objs, AMDGPU_RAS_BLOCK_COUNT),
> GFP_KERNEL|__GFP_ZERO);
> if (!con)
> return -ENOMEM;
> --
> 2.7.4
> 
> 
> 

-- 
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 1/2] drm: Add drm_gem_vram_{pin/unpin}_reserved() and convert mgag200

[Daniel Vetter]

On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote:
> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
> > The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
> > GEM VRAM pin/unpin functions that do not reserve the BO during validation.
> > The mgag200 driver requires this behavior for its cursor handling. The
> > patch also converts the driver to use the new interfaces.
> > 
> > Signed-off-by: Thomas Zimmermann 
> > ---
> >  drivers/gpu/drm/drm_gem_vram_helper.c| 75 
> >  drivers/gpu/drm/mgag200/mgag200_cursor.c | 18 +++---
> >  include/drm/drm_gem_vram_helper.h|  3 +
> >  3 files changed, 88 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
> > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > index 8f142b810eb4..a002c03eaf4c 100644
> > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > @@ -254,6 +254,47 @@ int drm_gem_vram_pin(struct drm_gem_vram_object *gbo, 
> > unsigned long pl_flag)
> >  }
> >  EXPORT_SYMBOL(drm_gem_vram_pin);
> >  
> > +/**
> > + * drm_gem_vram_pin_reserved() - Pins a GEM VRAM object in a region.
> > + * @gbo:   the GEM VRAM object
> > + * @pl_flag:   a bitmask of possible memory regions
> > + *
> > + * Pinning a buffer object ensures that it is not evicted from
> > + * a memory region. A pinned buffer object has to be unpinned before
> > + * it can be pinned to another region.
> > + *
> > + * This function pins a GEM VRAM object that has already been
> > + * reserved. Use drm_gem_vram_pin() if possible.
> > + *
> > + * Returns:
> > + * 0 on success, or
> > + * a negative error code otherwise.
> > + */
> > +int drm_gem_vram_pin_reserved(struct drm_gem_vram_object *gbo,
> > + unsigned long pl_flag)
> > +{
> > +   int i, ret;
> > +   struct ttm_operation_ctx ctx = { false, false };
> 
> I think would be good to have a lockdep_assert_held here for the ww_mutex.
> 
> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
> we call the structure tracking the fences+lock the "reservation", but the
> naming scheme used is _lock/_unlock.
> 
> I think would be good to be consistent with that, and use _locked here.
> Especially for a very simplified vram helper like this one I expect that's
> going to lead to less wtf moments by driver writers :-)
> 
> Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align
> more with what we now have in dma-buf.

More aside:

Could be a good move to demidlayer this an essentially remove
ttm_bo_reserve as a wrapper around the linux/reservation.h functions. Not
sure whether that aligns with Christian's plans. TODO.rst patch might be a
good step to get that discussion started.
-Daniel

> 
> Cheers, Daniel
> 
> > +
> > +   if (gbo->pin_count) {
> > +   ++gbo->pin_count;
> > +   return 0;
> > +   }
> > +
> > +   drm_gem_vram_placement(gbo, pl_flag);
> > +   for (i = 0; i < gbo->placement.num_placement; ++i)
> > +   gbo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
> > +
> > +   ret = ttm_bo_validate(>bo, >placement, );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   gbo->pin_count = 1;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_gem_vram_pin_reserved);
> > +
> >  /**
> >   * drm_gem_vram_unpin() - Unpins a GEM VRAM object
> >   * @gbo:   the GEM VRAM object
> > @@ -285,6 +326,40 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
> >  }
> >  EXPORT_SYMBOL(drm_gem_vram_unpin);
> >  
> > +/**
> > + * drm_gem_vram_unpin_reserved() - Unpins a GEM VRAM object
> > + * @gbo:   the GEM VRAM object
> > + *
> > + * This function unpins a GEM VRAM object that has already been
> > + * reserved. Use drm_gem_vram_unpin() if possible.
> > + *
> > + * Returns:
> > + * 0 on success, or
> > + * a negative error code otherwise.
> > + */
> > +int drm_gem_vram_unpin_reserved(struct drm_gem_vram_object *gbo)
> > +{
> > +   int i, ret;
> > +   struct ttm_operation_ctx ctx = { false, false };
> > +
> > +   if (WARN_ON_ONCE(!gbo->pin_count))
> > +   return 0;
> > +
> > +   --gbo->pin_count;
> > +   if (gbo->pin_count)
> > +   return 0;
> > +
> > +   for (i = 0; i < gbo->placement.num_placement ; ++i)
> > +   gbo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
> > +
> > +   ret = ttm_bo_validate(>bo, >placement, );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_gem_vram_unpin_reserved);
> > +
> >  /**
> >   * drm_gem_vram_push_to_system() - \
> > Unpins a GEM VRAM object and moves it to system memory
> > diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c 
> > b/drivers/gpu/drm/mgag200/mgag200_cursor.c
> > index 6c1a9d724d85..1c4fc85315a0 100644
> > --- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
> > +++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
> > @@ -23,9 +23,9 @@ static void mga_hide_cursor(struct mga_device 

Re: [PATCH v7 09/11] drm: uevent for connector status change

[Paul Kocialkowski]

Le lundi 20 mai 2019 à 18:11 +0200, Daniel Vetter a écrit :
> On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > On Thu, 16 May 2019 14:24:55 +0200
> > Daniel Vetter  wrote:
> > 
> > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > > On Wed, 15 May 2019 10:24:49 +0200
> > > > Daniel Vetter  wrote:
> > > >   
> > > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote:  
> > > > > > On Tue, 14 May 2019 16:34:01 +0200
> > > > > > Daniel Vetter  wrote:
> > > > > > 
> > > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen 
> > > > > > >  wrote:
> > > > > > > > On Tue, 14 May 2019 13:02:09 +0200
> > > > > > > > Daniel Vetter  wrote:
> > > > > > > >  
> > > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon 
> > > > > > > > >  wrote:  
> > > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:
> > > > > > > > > >   
> > > > > > 
> > > > > > ...
> > > > > > 
> > > > > > > > > > > Hi Daniel,
> > > > > > > > > > > 
> > > > > > > > > > > just to clarify the first case, specific to one very 
> > > > > > > > > > > particular
> > > > > > > > > > > property:
> > > > > > > > > > > 
> > > > > > > > > > > With HDCP, there is a property that may change 
> > > > > > > > > > > dynamically at runtime
> > > > > > > > > > > (the undesired/desired/enabled tristate). Userspace must 
> > > > > > > > > > > be notified
> > > > > > > > > > > when it changes, I do not want userspace have to poll 
> > > > > > > > > > > that property
> > > > > > > > > > > with a timer.
> > > > > > > > > > > 
> > > > > > > > > > > When that property alone changes, and userspace is 
> > > > > > > > > > > prepared to handle
> > > > > > > > > > > that property changing alone, it must not trigger a 
> > > > > > > > > > > reprobe of the
> > > > > > > > > > > connector. There is no reason to reprobe at that point 
> > > > > > > > > > > AFAIU.
> > > > > > > > > > > 
> > > > > > > > > > > How do you ensure that userspace can avoid triggering a 
> > > > > > > > > > > reprobe with the
> > > > > > > > > > > epoch approach or with any alternate uevent design?
> > > > > > > > > > > 
> > > > > > > > > > > We need an event to userspace that indicates that 
> > > > > > > > > > > re-reading the
> > > > > > > > > > > properties is enough and reprobe of the connector is not 
> > > > > > > > > > > necessary.
> > > > > > > > > > > This is complementary to indicating to userspace that 
> > > > > > > > > > > only some
> > > > > > > > > > > connectors need to be reprobed instead of everything. 
> > > > > > > > > > >  
> > > > > > > > > > 
> > > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP 
> > > > > > > > > > one, skip the
> > > > > > > > > > reprobing. Would that work?  
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > yes, that would work, if it was acceptable to DRM upstream. The 
> > > > > > > > replies
> > > > > > > > to Paul seemed to be going south so fast that I thought we 
> > > > > > > > wouldn't get
> > > > > > > > any new uevent fields in favour of "epoch counters".
> > > > > > > >  
> > > > > > > > > Yes that's the idea, depending upon which property you get 
> > > > > > > > > you know
> > > > > > > > > it's a sink change (needs full reprobe) or something else 
> > > > > > > > > like hdcp
> > > > > > > > > state machinery update.  
> > > > > > > > 
> > > > > > > > Right.
> > > > > > > >  
> > > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we 
> > > > > > > > > should
> > > > > > > > > indeed decouple that from the per-connector event for sink 
> > > > > > > > > changes.
> > > > > > > > > That along is a good win already, since you know for which 
> > > > > > > > > connector
> > > > > > > > > you need to call drmGetConnector (which forces the reprobe). 
> > > > > > > > > It would
> > > > > > > > > be nice to only call drmGetConnectorCurrent (avoids the 
> > > > > > > > > reprobe), but
> > > > > > > > > historically speaking every time we tried to rely on this we 
> > > > > > > > > ended up
> > > > > > > > > regretting things.  
> > > > > > > > 
> > > > > > > > What changed? This sounds very much what Paul suggested. 
> > > > > > > > Looking at it
> > > > > > > > from userspace side:  
> > > > > > > 
> > > > > > > This sounds solid, some refinements below:
> > > > > > > 
> > > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > > > > > > 
> > > > > > > > - If yy is "Content Protection", no need to 
> > > > > > > > drmModeGetConnector(), just
> > > > > > > >   re-get the connector properties.
> > > > > > > > 
> > > > > > > > - Kernel probably shouldn't bother sending this for properties 
> > > > > > > > where
> > > > > > > >   re-probe could be necessary, and send the below instead.  
> > > > > > > 
> > > > > > > I think we should assert that the kernel can get the new property
> > > > > > > values using drmModeGetConnectorCurrent for this case, i.e. the 
> > > > 

Re: [PATCH v2 1/3] dt-bindings: Add vendor prefix for VXT Ltd

[Thierry Reding]

On Mon, May 20, 2019 at 11:15:05AM -0300, Fabio Estevam wrote:
> On Tue, Apr 23, 2019 at 8:03 AM Thierry Reding  
> wrote:
> >
> > On Mon, Feb 18, 2019 at 09:27:04PM -0300, Fabio Estevam wrote:
> > > VXT Ltd is a manufacturer of projected capacitive touch panel
> > > and display solutions: http://www.vxt.com.tw/
> > >
> > > Reviewed-by: Otavio Salvador 
> > > Reviewed-by: Rob Herring 
> > > Signed-off-by: Fabio Estevam 
> > > ---
> > > Changes since v1:
> > > - None
> > >
> > >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> > >  1 file changed, 1 insertion(+)
> >
> > Applied all three patches, thanks.
> 
> I don't see any of these patches applied in linux-next nor 5.2-rc1.
> 
> What is the issue here?

The patch is in drm-misc-next and should show up in linux-next tomorrow.

My understanding is that somebody needs to push drm-misc-next after each
-rc1 release before drm-misc-next feeds into linux-next. Chances of that
happening between -rc1 and the linux-next release the day after are
fairly small.

Thierry


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

Re: [PATCH 0/2] Add BO reservation to GEM VRAM pin/unpin/push_to_system

[Daniel Vetter]

On Fri, May 17, 2019 at 01:17:03PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > It turns out that the bochs and vbox drivers automatically reserved and
> > unreserved the BO from within their pin and unpin functions. The other
> > drivers; ast, hibmc and mgag200; performed reservation explicitly. With the
> > GEM VRAM conversion, automatic BO reservation within pin and unpin functions
> > accidentally got lost. So for bochs and vbox, ttm_bo_validate() worked on
> > unlocked BOs.
> > 
> > This patch set fixes the problem by adding automatic reservation to the
> > implementation of drm_gem_vram_{pin,unpin,push_to_system}() to fix bochs
> > and vbox. It removes explicit BO reservation around the pin, unpin and
> > push-to-system calls in the ast, hibmc and mgag200 drivers.
> > 
> > The only exception is the cursor handling of mgag200. In this case, the
> > mgag200 driver now calls drm_gem_vram_{pin,unpin}_reserved(), which works
> > with reserved BOs. The respective code should be refactored in a future
> > patch to work with the regular pin and unpin functions.
> 
> Looks good, pushed to drm-misc-next.

I have a bit of design review (replied to patch 1), would be great if
either of you could address that as a follow up.

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

Re: [PATCH 1/2] drm: Add drm_gem_vram_{pin/unpin}_reserved() and convert mgag200

[Daniel Vetter]

On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote:
> The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
> GEM VRAM pin/unpin functions that do not reserve the BO during validation.
> The mgag200 driver requires this behavior for its cursor handling. The
> patch also converts the driver to use the new interfaces.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_gem_vram_helper.c| 75 
>  drivers/gpu/drm/mgag200/mgag200_cursor.c | 18 +++---
>  include/drm/drm_gem_vram_helper.h|  3 +
>  3 files changed, 88 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 8f142b810eb4..a002c03eaf4c 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -254,6 +254,47 @@ int drm_gem_vram_pin(struct drm_gem_vram_object *gbo, 
> unsigned long pl_flag)
>  }
>  EXPORT_SYMBOL(drm_gem_vram_pin);
>  
> +/**
> + * drm_gem_vram_pin_reserved() - Pins a GEM VRAM object in a region.
> + * @gbo: the GEM VRAM object
> + * @pl_flag: a bitmask of possible memory regions
> + *
> + * Pinning a buffer object ensures that it is not evicted from
> + * a memory region. A pinned buffer object has to be unpinned before
> + * it can be pinned to another region.
> + *
> + * This function pins a GEM VRAM object that has already been
> + * reserved. Use drm_gem_vram_pin() if possible.
> + *
> + * Returns:
> + * 0 on success, or
> + * a negative error code otherwise.
> + */
> +int drm_gem_vram_pin_reserved(struct drm_gem_vram_object *gbo,
> +   unsigned long pl_flag)
> +{
> + int i, ret;
> + struct ttm_operation_ctx ctx = { false, false };

I think would be good to have a lockdep_assert_held here for the ww_mutex.

Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
we call the structure tracking the fences+lock the "reservation", but the
naming scheme used is _lock/_unlock.

I think would be good to be consistent with that, and use _locked here.
Especially for a very simplified vram helper like this one I expect that's
going to lead to less wtf moments by driver writers :-)

Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align
more with what we now have in dma-buf.

Cheers, Daniel

> +
> + if (gbo->pin_count) {
> + ++gbo->pin_count;
> + return 0;
> + }
> +
> + drm_gem_vram_placement(gbo, pl_flag);
> + for (i = 0; i < gbo->placement.num_placement; ++i)
> + gbo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
> +
> + ret = ttm_bo_validate(>bo, >placement, );
> + if (ret < 0)
> + return ret;
> +
> + gbo->pin_count = 1;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_gem_vram_pin_reserved);
> +
>  /**
>   * drm_gem_vram_unpin() - Unpins a GEM VRAM object
>   * @gbo: the GEM VRAM object
> @@ -285,6 +326,40 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
>  }
>  EXPORT_SYMBOL(drm_gem_vram_unpin);
>  
> +/**
> + * drm_gem_vram_unpin_reserved() - Unpins a GEM VRAM object
> + * @gbo: the GEM VRAM object
> + *
> + * This function unpins a GEM VRAM object that has already been
> + * reserved. Use drm_gem_vram_unpin() if possible.
> + *
> + * Returns:
> + * 0 on success, or
> + * a negative error code otherwise.
> + */
> +int drm_gem_vram_unpin_reserved(struct drm_gem_vram_object *gbo)
> +{
> + int i, ret;
> + struct ttm_operation_ctx ctx = { false, false };
> +
> + if (WARN_ON_ONCE(!gbo->pin_count))
> + return 0;
> +
> + --gbo->pin_count;
> + if (gbo->pin_count)
> + return 0;
> +
> + for (i = 0; i < gbo->placement.num_placement ; ++i)
> + gbo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
> +
> + ret = ttm_bo_validate(>bo, >placement, );
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_gem_vram_unpin_reserved);
> +
>  /**
>   * drm_gem_vram_push_to_system() - \
>   Unpins a GEM VRAM object and moves it to system memory
> diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c 
> b/drivers/gpu/drm/mgag200/mgag200_cursor.c
> index 6c1a9d724d85..1c4fc85315a0 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
> @@ -23,9 +23,9 @@ static void mga_hide_cursor(struct mga_device *mdev)
>   WREG8(MGA_CURPOSXL, 0);
>   WREG8(MGA_CURPOSXH, 0);
>   if (mdev->cursor.pixels_1->pin_count)
> - drm_gem_vram_unpin(mdev->cursor.pixels_1);
> + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_1);
>   if (mdev->cursor.pixels_2->pin_count)
> - drm_gem_vram_unpin(mdev->cursor.pixels_2);
> + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_2);
>  }
>  
>  int mga_crtc_cursor_set(struct drm_crtc *crtc,
> @@ -96,26 +96,28 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,

Re: [PATCH v7 09/11] drm: uevent for connector status change

[Daniel Vetter]

On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> On Thu, 16 May 2019 14:24:55 +0200
> Daniel Vetter  wrote:
> 
> > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > On Wed, 15 May 2019 10:24:49 +0200
> > > Daniel Vetter  wrote:
> > >   
> > > > On Wed, May 15, 2019 at 10:37:31AM +0300, Pekka Paalanen wrote:  
> > > > > On Tue, 14 May 2019 16:34:01 +0200
> > > > > Daniel Vetter  wrote:
> > > > > 
> > > > > > On Tue, May 14, 2019 at 3:36 PM Pekka Paalanen 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, 14 May 2019 13:02:09 +0200
> > > > > > > Daniel Vetter  wrote:
> > > > > > >  
> > > > > > > > On Tue, May 14, 2019 at 10:18 AM Ser, Simon 
> > > > > > > >  wrote:  
> > > > > > > > >
> > > > > > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:  
> > > > > 
> > > > > ...
> > > > > 
> > > > > > > > > > Hi Daniel,
> > > > > > > > > >
> > > > > > > > > > just to clarify the first case, specific to one very 
> > > > > > > > > > particular
> > > > > > > > > > property:
> > > > > > > > > >
> > > > > > > > > > With HDCP, there is a property that may change dynamically 
> > > > > > > > > > at runtime
> > > > > > > > > > (the undesired/desired/enabled tristate). Userspace must be 
> > > > > > > > > > notified
> > > > > > > > > > when it changes, I do not want userspace have to poll that 
> > > > > > > > > > property
> > > > > > > > > > with a timer.
> > > > > > > > > >
> > > > > > > > > > When that property alone changes, and userspace is prepared 
> > > > > > > > > > to handle
> > > > > > > > > > that property changing alone, it must not trigger a reprobe 
> > > > > > > > > > of the
> > > > > > > > > > connector. There is no reason to reprobe at that point 
> > > > > > > > > > AFAIU.
> > > > > > > > > >
> > > > > > > > > > How do you ensure that userspace can avoid triggering a 
> > > > > > > > > > reprobe with the
> > > > > > > > > > epoch approach or with any alternate uevent design?
> > > > > > > > > >
> > > > > > > > > > We need an event to userspace that indicates that 
> > > > > > > > > > re-reading the
> > > > > > > > > > properties is enough and reprobe of the connector is not 
> > > > > > > > > > necessary.
> > > > > > > > > > This is complementary to indicating to userspace that only 
> > > > > > > > > > some
> > > > > > > > > > connectors need to be reprobed instead of everything.  
> > > > > > > > >
> > > > > > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, 
> > > > > > > > > skip the
> > > > > > > > > reprobing. Would that work?  
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > yes, that would work, if it was acceptable to DRM upstream. The 
> > > > > > > replies
> > > > > > > to Paul seemed to be going south so fast that I thought we 
> > > > > > > wouldn't get
> > > > > > > any new uevent fields in favour of "epoch counters".
> > > > > > >  
> > > > > > > > Yes that's the idea, depending upon which property you get you 
> > > > > > > > know
> > > > > > > > it's a sink change (needs full reprobe) or something else like 
> > > > > > > > hdcp
> > > > > > > > state machinery update.  
> > > > > > >
> > > > > > > Right.
> > > > > > >  
> > > > > > > > Wrt avoiding the full reprobe for sink changes: I think we 
> > > > > > > > should
> > > > > > > > indeed decouple that from the per-connector event for sink 
> > > > > > > > changes.
> > > > > > > > That along is a good win already, since you know for which 
> > > > > > > > connector
> > > > > > > > you need to call drmGetConnector (which forces the reprobe). It 
> > > > > > > > would
> > > > > > > > be nice to only call drmGetConnectorCurrent (avoids the 
> > > > > > > > reprobe), but
> > > > > > > > historically speaking every time we tried to rely on this we 
> > > > > > > > ended up
> > > > > > > > regretting things.  
> > > > > > >
> > > > > > > What changed? This sounds very much what Paul suggested. Looking 
> > > > > > > at it
> > > > > > > from userspace side:  
> > > > > > 
> > > > > > This sounds solid, some refinements below:
> > > > > > 
> > > > > > > HOTPLUG=1 CONNECTOR=xx PROPERTY=yy
> > > > > > >
> > > > > > > - If yy is "Content Protection", no need to 
> > > > > > > drmModeGetConnector(), just
> > > > > > >   re-get the connector properties.
> > > > > > >
> > > > > > > - Kernel probably shouldn't bother sending this for properties 
> > > > > > > where
> > > > > > >   re-probe could be necessary, and send the below instead.  
> > > > > > 
> > > > > > 
> > > > > > I think we should assert that the kernel can get the new property
> > > > > > values using drmModeGetConnectorCurrent for this case, i.e. the 
> > > > > > kernel
> > > > > > does not expect a full reprobe. I.e. upgrade your idea from "should"
> > > > > > to "must"
> > > > > 
> > > > > Hi Daniel,
> > > > > 
> > > > > ok, that's good.
> > > > > 
> > > > > > Furthermore different property can indicate different kind of 
> > > > 

[Bug 107084] WebGL shader freezes X server

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107084

--- Comment #5 from Pierre-Eric Pelloux-Prayer  ---
Doesn't seem to hang the system anymore (RX580, mesa daa85a882, Linux 5.0).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: Tree for May 20 (amdgpu)

[Randy Dunlap]

On 5/19/19 6:55 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20190517:
> 
> Non-merge commits (relative to Linus' tree): 553
>  519 files changed, 11723 insertions(+), 3396 deletions(-)
> 
> 
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" and checkout or reset to the new
> master.
> 
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log
> files in the Next directory.  Between each merge, the tree was built
> with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
> multi_v7_defconfig for arm and a native build of tools/perf. After
> the final fixups (if any), I do an x86_64 modules_install followed by
> builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
> ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
> and sparc64 defconfig. And finally, a simple boot test of the powerpc
> pseries_le_defconfig kernel in qemu (with and without kvm enabled).
> 
> Below is a summary of the state of the merge.
> 
> I am currently merging 298 trees (counting Linus' and 69 trees of bug
> fix patches pending for the current merge release).
> 
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
> 
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
> 
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
> 

on i386, when built as loadable module:

in amdgpu_ras_sysfs_badpages_read():
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!

or when builtin:
ld: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.o: in function 
`amdgpu_ras_sysfs_badpages_read':
amdgpu_ras.c:(.text+0x9ec): undefined reference to `__divdi3'
ld: amdgpu_ras.c:(.text+0xa0a): undefined reference to `__divdi3'



-- 
~Randy

[PATCH] drm/meson: update with SPDX Licence identifier

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c  | 15 +--
 drivers/gpu/drm/meson/meson_crtc.h  | 15 +--
 drivers/gpu/drm/meson/meson_drv.c   | 15 +--
 drivers/gpu/drm/meson/meson_drv.h   | 14 +-
 drivers/gpu/drm/meson/meson_dw_hdmi.c   | 14 +-
 drivers/gpu/drm/meson/meson_dw_hdmi.h   | 14 +-
 drivers/gpu/drm/meson/meson_plane.c | 15 +--
 drivers/gpu/drm/meson/meson_plane.h | 15 +--
 drivers/gpu/drm/meson/meson_registers.h | 12 +---
 drivers/gpu/drm/meson/meson_vclk.c  | 14 +-
 drivers/gpu/drm/meson/meson_vclk.h  | 14 +-
 drivers/gpu/drm/meson/meson_venc.c  | 14 +-
 drivers/gpu/drm/meson/meson_venc.h  | 14 +-
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 15 +--
 drivers/gpu/drm/meson/meson_venc_cvbs.h | 15 +--
 drivers/gpu/drm/meson/meson_viu.c   | 14 +-
 drivers/gpu/drm/meson/meson_viu.h   | 14 +-
 drivers/gpu/drm/meson/meson_vpp.c   | 14 +-
 drivers/gpu/drm/meson/meson_vpp.h   | 14 +-
 19 files changed, 19 insertions(+), 252 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index 5579f8ac3e3f..a8416b6b7782 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -1,22 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright (C) 2016 BayLibre, SAS
  * Author: Neil Armstrong 
  * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
  * Copyright (C) 2014 Endless Mobile
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- *
  * Written by:
  * Jasper St. Pierre 
  */
diff --git a/drivers/gpu/drm/meson/meson_crtc.h 
b/drivers/gpu/drm/meson/meson_crtc.h
index b62b9e51764d..4f0f212e51db 100644
--- a/drivers/gpu/drm/meson/meson_crtc.h
+++ b/drivers/gpu/drm/meson/meson_crtc.h
@@ -1,21 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * Copyright (C) 2016 BayLibre, SAS
  * Author: Neil Armstrong 
  * Copyright (C) 2014 Endless Mobile
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- *
  * Written by:
  * Jasper St. Pierre 
  */
diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 72b01e6be0d9..26be64b94237 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -1,21 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright (C) 2016 BayLibre, SAS
  * Author: Neil Armstrong 
  * Copyright (C) 2014 Endless Mobile
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- *
  * Written by:
  * Jasper St. Pierre 
  */
diff --git a/drivers/gpu/drm/meson/meson_drv.h 
b/drivers/gpu/drm/meson/meson_drv.h
index 9614baa836b9..0d27556f2838 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -1,19 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * Copyright (C) 2016 BayLibre, SAS
  * Author: Neil Armstrong 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the 

Re: [PATCH v2 1/3] dt-bindings: Add vendor prefix for VXT Ltd

[Fabio Estevam]

On Tue, Apr 23, 2019 at 8:03 AM Thierry Reding  wrote:
>
> On Mon, Feb 18, 2019 at 09:27:04PM -0300, Fabio Estevam wrote:
> > VXT Ltd is a manufacturer of projected capacitive touch panel
> > and display solutions: http://www.vxt.com.tw/
> >
> > Reviewed-by: Otavio Salvador 
> > Reviewed-by: Rob Herring 
> > Signed-off-by: Fabio Estevam 
> > ---
> > Changes since v1:
> > - None
> >
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
>
> Applied all three patches, thanks.

I don't see any of these patches applied in linux-next nor 5.2-rc1.

What is the issue here?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read

[Thomas Hellstrom]

Thanks, Murray,

I'll include in the next vmwgfx-fixes pull request.

On Mon, 2019-05-20 at 21:57 +1200, Murray McAllister wrote:
> If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
> of SVGA3D_INVALID_ID, and a shader type of
> SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot
> will be 4294967295, leading to an out-of-bounds read in
> vmw_binding_loc()
> when the offset is calculated.
> 
> Signed-off-by: Murray McAllister 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 2ff7ba04d8c8..9aeb5448cfc1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -2193,7 +2193,8 @@ static int vmw_cmd_dx_set_shader(struct
> vmw_private *dev_priv,
>  
>   cmd = container_of(header, typeof(*cmd), header);
>  
> - if (cmd->body.type >= SVGA3D_SHADERTYPE_DX10_MAX) {
> + if (cmd->body.type >= SVGA3D_SHADERTYPE_DX10_MAX ||
> + cmd->body.type < SVGA3D_SHADERTYPE_MIN) {
>   VMW_DEBUG_USER("Illegal shader type %u.\n",
>  (unsigned int) cmd->body.type);
>   return -EINVAL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110701] GPU faults in in Unigine Valley 1.0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110701

LoneVVolf  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=108824

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108824] Invalid handling when GL buffer is bound on one context and invalidated on another

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108824

LoneVVolf  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=110701

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108824] Invalid handling when GL buffer is bound on one context and invalidated on another

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108824

--- Comment #9 from LoneVVolf  ---
reverting commit
https://cgit.freedesktop.org/mesa/mesa/commit/?id=78e35df52aa2f7d770f929a0866a0faa89c261a9
solves the visual corruption and gets rid of the gpu fault messages in dmesg.

As that commit is 2/2 of the patchset referenced in commit #4 , it does look
like this introduces new errors.
see https://bugs.freedesktop.org/show_bug.cgi?id=110701

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/meson: Output in YUV444 if sink supports it

[Neil Armstrong]

With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 5d67e2beba58..8bf9db7f39a4 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -723,12 +723,23 @@ static int meson_venc_hdmi_encoder_atomic_check(struct 
drm_encoder *encoder,
struct drm_display_mode *mode = _state->mode;
bool is_hdmi2_sink =
conn_state->connector->display_info.hdmi.scdc.supported;
+   bool specify_out_format = false;
+   u32 out_format;
 
if (drm_mode_is_420_only(info, mode) ||
(!is_hdmi2_sink && drm_mode_is_420_also(info, mode)))
dw_hdmi->input_bus_format = MEDIA_BUS_FMT_UYYVYY8_0_5X24;
-   else
+   else {
dw_hdmi->input_bus_format = MEDIA_BUS_FMT_YUV8_1X24;
+   if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444) {
+   out_format = MEDIA_BUS_FMT_YUV8_1X24;
+   specify_out_format = true;
+   }
+   }
+
+   /* Set a connector bus format if required */
+   drm_display_info_set_bus_formats(info, _format,
+(specify_out_format ? 1 : 0));
 
/* Specify the encoder output format to the bridge */
if (!drm_bridge_format_set(encoder->bridge,
-- 
2.21.0

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

[PATCH 2/5] drm/bridge: add encoder support to specify bridge input format

[Neil Armstrong]

This patch adds a new format_set() callback to the bridge ops permitting
the encoder to specify the new input format and encoding.

This allows supporting the very specific HDMI2.0 YUV420 output mode
when the bridge cannot convert from RGB or YUV444 to YUV420.

In this case, the encode must downsample before the bridge and must
specify the bridge the new input bus format differs.

This will also help supporting the YUV420 mode where the bridge cannot
downsample, and also support 10bit, 12bit and 16bit output modes
when the bridge cannot convert between different bit depths.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/drm_bridge.c | 35 +++
 include/drm/drm_bridge.h | 19 +++
 2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 138b2711d389..33be74a977f7 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -307,6 +307,41 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
 }
 EXPORT_SYMBOL(drm_bridge_mode_set);
 
+/**
+ * drm_bridge_format_set - setup with proposed input format and encoding for
+ *all bridges in the encoder chain
+ * @bridge: bridge control structure
+ * @input_bus_format: proposed input bus format for the bridge
+ * @input_encoding: proposed input encoding for this bridge
+ *
+ * Calls _bridge_funcs.format_set op for all the bridges in the
+ * encoder chain, starting from the first bridge to the last.
+ *
+ * Note: the bridge passed should be the one closest to the encoder
+ *
+ * RETURNS:
+ * true on success, false if one of the bridge cannot handle the format
+ */
+bool drm_bridge_format_set(struct drm_bridge *bridge,
+  const u32 input_bus_format,
+  const u32 input_encoding)
+{
+   bool ret = true;
+
+   if (!bridge)
+   return true;
+
+   if (bridge->funcs->format_set)
+   ret = bridge->funcs->format_set(bridge, input_bus_format,
+   input_encoding);
+   if (!ret)
+   return ret;
+
+   return drm_bridge_format_set(bridge->next, input_bus_format,
+input_encoding);
+}
+EXPORT_SYMBOL(drm_bridge_format_set);
+
 /**
  * drm_bridge_pre_enable - prepares for enabling all
  *bridges in the encoder chain
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index d4428913a4e1..7a79e61b7825 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -198,6 +198,22 @@ struct drm_bridge_funcs {
void (*mode_set)(struct drm_bridge *bridge,
 const struct drm_display_mode *mode,
 const struct drm_display_mode *adjusted_mode);
+
+   /**
+* @format_set:
+*
+* This callback should configure the bridge for the given input bus
+* format and encoding. It is called after the @format_set callback
+* for the preceding element in the display pipeline has been called
+* already. If the bridge is the first element then this would be
+* _encoder_helper_funcs.format_set. The display pipe (i.e.
+* clocks and timing signals) is off when this function is called.
+*
+* @returns: true in success, false is a bridge refuses the format
+*/
+   bool (*format_set)(struct drm_bridge *bridge,
+  const u32 input_bus_format,
+  const u32 input_encoding);
/**
 * @pre_enable:
 *
@@ -311,6 +327,9 @@ void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,
 const struct drm_display_mode *mode,
 const struct drm_display_mode *adjusted_mode);
+bool drm_bridge_format_set(struct drm_bridge *bridge,
+  const u32 input_bus_format,
+  const u32 input_encoding);
 void drm_bridge_pre_enable(struct drm_bridge *bridge);
 void drm_bridge_enable(struct drm_bridge *bridge);
 
-- 
2.21.0

[PATCH 0/5] drm/meson: Add support for HDMI2.0 YUV420 4k60

[Neil Armstrong]

The Synopsys DW-HDMI CSC does not support downsampling to YUV420, so
the encoder must downsamle before, feeding the controller with a YUV420
pixel stream.

The encoder must declare the new bus format enc encoding the bridge, in
order to take it in account.

To solve this, a new format_set() bridge op is added, permitting setting
a new input bus format and encoding to the bridge chain.

This solves YUV420 setup, but also solved setting 10bit, 12bit or 16bit
input bus format in order to support HDMI >8bit depths.

The DW-HDMI controller is updated to dynamically select a coherent output
bus format depending on the input bus format and on the internal CSC
supported modes.

The DW-HDMI is also updated to support the connector display_info bus_formats
entry to permit forcing a specific output bus format to force, for example,
an YUV444 output format instead of the default RGB output bus format.

Only the meson DRM dw_hdmi glue allows ycbcr420 modes, so no breakage
is expected here.

The remaining patches adds support for 4:2:0 output and clock setup for
the meson DW-HDMI glue, and how YUV444 output can be forced.

Changes since rfc:
* Fixed small logic error in drm_bridge_format_set()
* rebased on v5.2-rc1

Neil Armstrong (5):
  drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a
  drm/bridge: add encoder support to specify bridge input format
  drm/bridge: dw-hdmi: Add support for dynamic output format setup
  drm/meson: Add YUV420 output support
  drm/meson: Output in YUV444 if sink supports it

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 127 --
 drivers/gpu/drm/drm_bridge.c  |  35 ++
 drivers/gpu/drm/meson/meson_dw_hdmi.c | 111 ---
 drivers/gpu/drm/meson/meson_vclk.c|  93 
 drivers/gpu/drm/meson/meson_vclk.h|   7 +-
 drivers/gpu/drm/meson/meson_venc.c|   6 +-
 drivers/gpu/drm/meson/meson_venc.h|  11 ++
 drivers/gpu/drm/meson/meson_venc_cvbs.c   |   3 +-
 include/drm/bridge/dw_hdmi.h  |   1 +
 include/drm/drm_bridge.h  |  19 
 10 files changed, 358 insertions(+), 55 deletions(-)

-- 
2.21.0

[PATCH 3/5] drm/bridge: dw-hdmi: Add support for dynamic output format setup

[Neil Armstrong]

In order to support the HDMI2.0 YUV420, YUV422 and the 10bit, 12bit and
16bits outpu use cases, add support for the recently introduced bridge
callback format_set().

This callback will setup the new input format and encoding from encoder,
then these information will be used instead of the default ones
in the dw_hdmi_setup() function.

To determine the output bus format, has been added :
- support for the connector display_info bus_formats, where a fixed
  output bus format can be enforced by the encoder
- support for synami output bus format depending on the input format,
  especially the YUV420 input bus format, enforcing YUV420 as output
  with the correct bit depth

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 121 --
 1 file changed, 112 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index b50c49caf7ae..284ce59be8f8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -103,6 +103,8 @@ struct hdmi_vmode {
 };
 
 struct hdmi_data_info {
+   unsigned int bridge_in_bus_format;
+   unsigned int bridge_in_encoding;
unsigned int enc_in_bus_format;
unsigned int enc_out_bus_format;
unsigned int enc_in_encoding;
@@ -1838,8 +1840,51 @@ static void hdmi_disable_overflow_interrupts(struct 
dw_hdmi *hdmi)
HDMI_IH_MUTE_FC_STAT2);
 }
 
+/*
+ * The DW-HDMI CSC can only interpolate and decimate from 4:2:2 to 4:4:4/RGB
+ * and from 4:4:4/RGB to 4:2:2.
+ * Default to RGB output except if 4:2:0 as input, which CSC cannot convert.
+ */
+static unsigned long dw_hdmi_determine_output_bus_format(struct dw_hdmi *hdmi)
+{
+   unsigned int depth = hdmi_bus_fmt_color_depth(
+   hdmi->hdmi_data.enc_in_bus_format);
+   bool is_420 = hdmi_bus_fmt_is_yuv420(hdmi->hdmi_data.enc_in_bus_format);
+   unsigned long fmt = MEDIA_BUS_FMT_RGB888_1X24;
+
+   switch (depth) {
+   case 8:
+   if (is_420)
+   fmt = MEDIA_BUS_FMT_UYYVYY8_0_5X24;
+   else
+   fmt = MEDIA_BUS_FMT_RGB888_1X24;
+   break;
+   case 10:
+   if (is_420)
+   fmt = MEDIA_BUS_FMT_UYYVYY10_0_5X30;
+   else
+   fmt = MEDIA_BUS_FMT_RGB101010_1X30;
+   break;
+   case 12:
+   if (is_420)
+   fmt = MEDIA_BUS_FMT_UYYVYY12_0_5X36;
+   else
+   fmt = MEDIA_BUS_FMT_RGB121212_1X36;
+   break;
+   case 16:
+   if (is_420)
+   fmt = MEDIA_BUS_FMT_UYYVYY16_0_5X48;
+   else
+   fmt = MEDIA_BUS_FMT_RGB161616_1X48;
+   break;
+   }
+
+   return fmt;
+}
+
 static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct drm_display_mode *mode)
 {
+   struct drm_display_info *display = >connector.display_info;
int ret;
 
hdmi_disable_overflow_interrupts(hdmi);
@@ -1853,9 +1898,9 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
}
 
if ((hdmi->vic == 6) || (hdmi->vic == 7) ||
-   (hdmi->vic == 21) || (hdmi->vic == 22) ||
-   (hdmi->vic == 2) || (hdmi->vic == 3) ||
-   (hdmi->vic == 17) || (hdmi->vic == 18))
+(hdmi->vic == 21) || (hdmi->vic == 22) ||
+(hdmi->vic == 2) || (hdmi->vic == 3) ||
+(hdmi->vic == 17) || (hdmi->vic == 18))
hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_601;
else
hdmi->hdmi_data.enc_out_encoding = V4L2_YCBCR_ENC_709;
@@ -1863,22 +1908,29 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 0;
hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0;
 
-   /* TOFIX: Get input format from plat data or fallback to RGB888 */
-   if (hdmi->plat_data->input_bus_format)
+   if (hdmi->hdmi_data.bridge_in_bus_format)
+   hdmi->hdmi_data.enc_in_bus_format =
+   hdmi->hdmi_data.bridge_in_bus_format;
+   else if (hdmi->plat_data->input_bus_format)
hdmi->hdmi_data.enc_in_bus_format =
hdmi->plat_data->input_bus_format;
else
hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
 
-   /* TOFIX: Get input encoding from plat data or fallback to none */
-   if (hdmi->plat_data->input_bus_encoding)
+   if (hdmi->hdmi_data.bridge_in_encoding)
+   hdmi->hdmi_data.enc_in_encoding =
+   hdmi->hdmi_data.bridge_in_encoding;
+   else if (hdmi->plat_data->input_bus_encoding)
hdmi->hdmi_data.enc_in_encoding =

[PATCH 1/5] drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a

[Neil Armstrong]

Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.

Signed-off-by: Neil Armstrong 
Tested-by: Heiko Stuebner 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 ++
 include/drm/bridge/dw_hdmi.h  | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ab7968c8f6a2..b50c49caf7ae 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2629,6 +2629,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->phy.ops->setup_hpd)
hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
 
+   if (hdmi->version >= 0x200a)
+   hdmi->connector.ycbcr_420_allowed =
+   hdmi->plat_data->ycbcr_420_allowed;
+   else
+   hdmi->connector.ycbcr_420_allowed = false;
+
memset(, 0, sizeof(pdevinfo));
pdevinfo.parent = dev;
pdevinfo.id = PLATFORM_DEVID_AUTO;
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 66e70770cce5..0f0e82638fbe 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -130,6 +130,7 @@ struct dw_hdmi_plat_data {
   const struct drm_display_mode *mode);
unsigned long input_bus_format;
unsigned long input_bus_encoding;
+   bool ycbcr_420_allowed;
 
/* Vendor PHY support */
const struct dw_hdmi_phy_ops *phy_ops;
-- 
2.21.0

[PATCH 4/5] drm/meson: Add YUV420 output support

[Neil Armstrong]

This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.

The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixel stream to a YUV420
stream.
In addition if pixel stream down-sampling, the Y Cb Cr components must
also be mapped differently to align with the HDMI2.0 specifications.

This mode needs a different clock generation scheme since the TMDS PHY
clock must match the 10x ration with the YUV420 pixel clock, but
the video encoder must run at 2x the pixel clock.

This patch adds the TMDS PHY clock value in all the video clock setup
in order to better support these specific uses cases and switch
to the Common Clock framework for clocks handling in the future.

When 420 is needed, it calls drm_bridge_format_set() for notify the
bridge the input format has changed to YUV420.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_dw_hdmi.c   | 100 +++-
 drivers/gpu/drm/meson/meson_vclk.c  |  93 --
 drivers/gpu/drm/meson/meson_vclk.h  |   7 +-
 drivers/gpu/drm/meson/meson_venc.c  |   6 +-
 drivers/gpu/drm/meson/meson_venc.h  |  11 +++
 drivers/gpu/drm/meson/meson_venc_cvbs.c |   3 +-
 6 files changed, 174 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 779da21143b9..5d67e2beba58 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -159,6 +159,7 @@ struct meson_dw_hdmi {
struct regulator *hdmi_supply;
u32 irq_stat;
struct dw_hdmi *hdmi;
+   unsigned long input_bus_format;
 };
 #define encoder_to_meson_dw_hdmi(x) \
container_of(x, struct meson_dw_hdmi, encoder)
@@ -308,6 +309,10 @@ static void meson_hdmi_phy_setup_mode(struct meson_dw_hdmi 
*dw_hdmi,
struct meson_drm *priv = dw_hdmi->priv;
unsigned int pixel_clock = mode->clock;
 
+   /* For 420, pixel clock is half unlike venc clock */
+   if (dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
+   pixel_clock /= 2;
+
if (dw_hdmi_is_compatible(dw_hdmi, "amlogic,meson-gxl-dw-hdmi") ||
dw_hdmi_is_compatible(dw_hdmi, "amlogic,meson-gxm-dw-hdmi")) {
if (pixel_clock >= 371250) {
@@ -383,25 +388,36 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi 
*dw_hdmi,
 {
struct meson_drm *priv = dw_hdmi->priv;
int vic = drm_match_cea_mode(mode);
+   unsigned int phy_freq;
unsigned int vclk_freq;
unsigned int venc_freq;
unsigned int hdmi_freq;
 
vclk_freq = mode->clock;
 
+   /* For 420, pixel clock is half unlike venc clock */
+   if (dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
+   vclk_freq /= 2;
+
+   /* TMDS clock is pixel_clock * 10 */
+   phy_freq = vclk_freq * 10;
+
if (!vic) {
-   meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, vclk_freq,
-vclk_freq, vclk_freq, false);
+   meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, phy_freq,
+vclk_freq, vclk_freq, vclk_freq, false);
return;
}
 
+   /* 480i/576i needs global pixel doubling */
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
vclk_freq *= 2;
 
venc_freq = vclk_freq;
hdmi_freq = vclk_freq;
 
-   if (meson_venc_hdmi_venc_repeat(vic))
+   /* VENC double pixels for 1080i, 720p and YUV420 modes */
+   if (meson_venc_hdmi_venc_repeat(vic) ||
+   dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
venc_freq *= 2;
 
vclk_freq = max(venc_freq, hdmi_freq);
@@ -409,11 +425,11 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi 
*dw_hdmi,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
venc_freq /= 2;
 
-   DRM_DEBUG_DRIVER("vclk:%d venc=%d hdmi=%d enci=%d\n",
-   vclk_freq, venc_freq, hdmi_freq,
+   DRM_DEBUG_DRIVER("vclk:%d phy=%d venc=%d hdmi=%d enci=%d\n",
+   phy_freq, vclk_freq, venc_freq, hdmi_freq,
priv->venc.hdmi_use_enci);
 
-   meson_vclk_setup(priv, MESON_VCLK_TARGET_HDMI, vclk_freq,
+   meson_vclk_setup(priv, MESON_VCLK_TARGET_HDMI, phy_freq, vclk_freq,
 venc_freq, hdmi_freq, priv->venc.hdmi_use_enci);
 }
 
@@ -446,8 +462,9 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
*data,
/* Enable normal output to PHY */
dw_hdmi->data->top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
 
-   /* TMDS pattern setup (TOFIX Handle the YUV420 case) */
-   if (mode->clock > 34) {
+   /* TMDS pattern setup */
+   if (mode->clock > 34 &&
+   dw_hdmi->input_bus_format == MEDIA_BUS_FMT_YUV8_1X24) {
 

Re: [PATCH] dt-bindings: backlight: lm3630a: correct schema validation

[Daniel Thompson]

On Mon, May 20, 2019 at 08:14:03AM -0500, Rob Herring wrote:
> On Mon, May 20, 2019 at 3:59 AM Brian Masney  wrote:
> >
> > The '#address-cells' and '#size-cells' properties were not defined in
> > the lm3630a bindings and would cause the following error when
> > attempting to validate the examples against the schema:
> >
> > Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
> > '#address-cells', '#size-cells' do not match any of the regexes:
> > '^led@[01]$', 'pinctrl-[0-9]+'
> >
> > Correct this by adding those two properties.
> >
> > While we're here, move the ti,linear-mapping-mode property to the
> > led@[01] child nodes to correct the following validation error:
> >
> > Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
> > led@0: 'ti,linear-mapping-mode' does not match any of the regexes:
> > 'pinctrl-[0-9]+'
> >
> > Fixes: 32fcb75c66a0 ("dt-bindings: backlight: Add lm3630a bindings")
> > Signed-off-by: Brian Masney 
> > Reported-by: Rob Herring 
> > ---
> >  .../leds/backlight/lm3630a-backlight.yaml | 20 +--
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> Reviewed-by: Rob Herring 

Acked-by: Daniel Thompson 

Re: [PATCH] dt-bindings: backlight: lm3630a: correct schema validation

[Rob Herring]

On Mon, May 20, 2019 at 3:59 AM Brian Masney  wrote:
>
> The '#address-cells' and '#size-cells' properties were not defined in
> the lm3630a bindings and would cause the following error when
> attempting to validate the examples against the schema:
>
> Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
> '#address-cells', '#size-cells' do not match any of the regexes:
> '^led@[01]$', 'pinctrl-[0-9]+'
>
> Correct this by adding those two properties.
>
> While we're here, move the ti,linear-mapping-mode property to the
> led@[01] child nodes to correct the following validation error:
>
> Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.example.dt.yaml:
> led@0: 'ti,linear-mapping-mode' does not match any of the regexes:
> 'pinctrl-[0-9]+'
>
> Fixes: 32fcb75c66a0 ("dt-bindings: backlight: Add lm3630a bindings")
> Signed-off-by: Brian Masney 
> Reported-by: Rob Herring 
> ---
>  .../leds/backlight/lm3630a-backlight.yaml | 20 +--
>  1 file changed, 14 insertions(+), 6 deletions(-)

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

[PATCH] video: fbdev: mxsfb: Remove driver

[Fabio Estevam]

There is a DRM version of the mxsfb driver for quite some time
at drivers/gpu/drm/mxsfb/, so there is no need to keep maintaining
the fbdev version any longer.

Remove the fbdev mxsfb driver in favour of the DRM version.

Signed-off-by: Fabio Estevam 
---
 drivers/video/fbdev/Kconfig  |   13 +-
 drivers/video/fbdev/Makefile |1 -
 drivers/video/fbdev/mxsfb.c  | 1036 --
 3 files changed, 1 insertion(+), 1049 deletions(-)
 delete mode 100644 drivers/video/fbdev/mxsfb.c

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index bf6b77b964f1..61c173b0c906 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2171,7 +2171,7 @@ config FB_EP93XX
 
 config FB_PRE_INIT_FB
bool "Don't reinitialize, use bootloader's GDC/Display configuration"
-   depends on FB && (FB_MB862XX_LIME || FB_MXS)
+   depends on FB && FB_MB862XX_LIME
---help---
  Select this option if display contents should be inherited as set by
  the bootloader.
@@ -2212,17 +2212,6 @@ config FB_JZ4740
help
  Framebuffer support for the JZ4740 SoC.
 
-config FB_MXS
-   tristate "MXS LCD framebuffer support"
-   depends on FB && (ARCH_MXS || ARCH_MXC)
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   select FB_MODE_HELPERS
-   select VIDEOMODE_HELPERS
-   help
- Framebuffer support for the MXS SoC.
-
 config FB_PUV3_UNIGFX
tristate "PKUnity v3 Unigfx framebuffer support"
depends on FB && UNICORE32 && ARCH_PUV3
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 655f2537cac1..7dc4861a93e6 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -131,7 +131,6 @@ obj-$(CONFIG_FB_VGA16)+= vga16fb.o
 obj-$(CONFIG_FB_OF)   += offb.o
 obj-$(CONFIG_FB_MX3) += mx3fb.o
 obj-$(CONFIG_FB_DA8XX)   += da8xx-fb.o
-obj-$(CONFIG_FB_MXS) += mxsfb.o
 obj-$(CONFIG_FB_SSD1307) += ssd1307fb.o
 obj-$(CONFIG_FB_SIMPLE)   += simplefb.o
 
diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
deleted file mode 100644
index 1fdd1eb38fe0..
--- a/drivers/video/fbdev/mxsfb.c
+++ /dev/null
@@ -1,1036 +0,0 @@
-/*
- * Copyright (C) 2010 Juergen Beisert, Pengutronix
- *
- * This code is based on:
- * Author: Vitaly Wool 
- *
- * Copyright 2008-2009 Freescale Semiconductor, Inc. All Rights Reserved.
- * Copyright 2008 Embedded Alley Solutions, Inc All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#define DRIVER_NAME "mxsfb"
-
-/**
- * @file
- * @brief LCDIF driver for i.MX23 and i.MX28
- *
- * The LCDIF support four modes of operation
- * - MPU interface (to drive smart displays) -> not supported yet
- * - VSYNC interface (like MPU interface plus Vsync) -> not supported yet
- * - Dotclock interface (to drive LC displays with RGB data and sync signals)
- * - DVI (to drive ITU-R BT656)  -> not supported yet
- *
- * This driver depends on a correct setup of the pins used for this purpose
- * (platform specific).
- *
- * For the developer: Don't forget to set the data bus width to the display
- * in the imx_fb_videomode structure. You will else end up with ugly colours.
- * If you fight against jitter you can vary the clock delay. This is a feature
- * of the i.MX28 and you can vary it between 2 ns ... 8 ns in 2 ns steps. Give
- * the required value in the imx_fb_videomode structure.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define REG_SET4
-#define REG_CLR8
-
-#define LCDC_CTRL  0x00
-#define LCDC_CTRL1 0x10
-#define LCDC_V4_CTRL2  0x20
-#define LCDC_V3_TRANSFER_COUNT 0x20
-#define LCDC_V4_TRANSFER_COUNT 0x30
-#define LCDC_V4_CUR_BUF0x40
-#define LCDC_V4_NEXT_BUF   0x50
-#define LCDC_V3_CUR_BUF0x30
-#define LCDC_V3_NEXT_BUF   0x40
-#define LCDC_TIMING0x60
-#define LCDC_VDCTRL0   0x70
-#define LCDC_VDCTRL1   0x80
-#define LCDC_VDCTRL2   0x90
-#define LCDC_VDCTRL3   0xa0
-#define LCDC_VDCTRL4   0xb0
-#define LCDC_DVICTRL0  0xc0
-#define LCDC_DVICTRL1  0xd0

linux-next: Fixes tag needs some work in the drm-intel tree

[Stephen Rothwell]

Hi all,

In commit

  0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the 
signaler")

Fixes tag

  Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni

has these problem(s):

  - Subject has leading but no trailing parentheses
  - Subject has leading but no trailing quotes

Please don't split Fixes tags across more than one line.



-- 
Cheers,
Stephen Rothwell


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

Re: [PATCH v3 7/7] drm: Remove users of drm_format_num_planes

[Maxime Ripard]

On Mon, May 20, 2019 at 01:20:45PM +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> > drm_format_info_plane_cpp() basically just returns the cpp array content
> > found in the drm_format_info structure.
> >
> > Since it's pretty trivial, let's remove the function and have the users use
> > the array directly
>
> Reviewed-by: Paul Kocialkowski 

Applied all 7 patches to drm-misc-next, thanks!
Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v3 5/7] drm/fourcc: Pass the format_info pointer to drm_format_plane_width/height

[Paul Kocialkowski]

Hi,

On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> So far, the drm_format_plane_height/width functions were operating on the
> format's fourcc and was doing a lookup to retrieve the drm_format_info
> structure and return the cpp.
> 
> However, this is inefficient since in most cases, we will have the
> drm_format_info pointer already available so we shouldn't have to perform a
> new lookup. Some drm_fourcc functions also already operate on the
> drm_format_info pointer for that reason, so the API is quite inconsistent
> there.
> 
> Let's follow the latter pattern and remove the extra lookup while being a
> bit more consistent.
> 
> In order to be extra consistent, also rename that function to
> drm_format_info_plane_cpp and to a static function in the header to match
> the current policy. The parameters order have also be changed to match the
> other functions prototype.

Same comment about plane being int instead of unsigned int, but I think we
can fix that later.

Another thing that I find odd is that the division by vsub/hsub is not
rounded up, but again, it's something independent from your patch.

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Reviewed-by: Emil Velikov 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/drm_fourcc.c  | 48 +
>  drivers/gpu/drm/meson/meson_overlay.c | 12 +++
>  include/drm/drm_fourcc.h  | 46 +--
>  3 files changed, 50 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5f63fc74e265..35b459d186c5 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -333,54 +333,6 @@ drm_get_format_info(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_get_format_info);
>  
>  /**
> - * drm_format_plane_width - width of the plane given the first plane
> - * @width: width of the first plane
> - * @format: pixel format
> - * @plane: plane index
> - *
> - * Returns:
> - * The width of @plane, given that the width of the first plane is @width.
> - */
> -int drm_format_plane_width(int width, uint32_t format, int plane)
> -{
> - const struct drm_format_info *info;
> -
> - info = drm_format_info(format);
> - if (!info || plane >= info->num_planes)
> - return 0;
> -
> - if (plane == 0)
> - return width;
> -
> - return width / info->hsub;
> -}
> -EXPORT_SYMBOL(drm_format_plane_width);
> -
> -/**
> - * drm_format_plane_height - height of the plane given the first plane
> - * @height: height of the first plane
> - * @format: pixel format
> - * @plane: plane index
> - *
> - * Returns:
> - * The height of @plane, given that the height of the first plane is @height.
> - */
> -int drm_format_plane_height(int height, uint32_t format, int plane)
> -{
> - const struct drm_format_info *info;
> -
> - info = drm_format_info(format);
> - if (!info || plane >= info->num_planes)
> - return 0;
> -
> - if (plane == 0)
> - return height;
> -
> - return height / info->vsub;
> -}
> -EXPORT_SYMBOL(drm_format_plane_height);
> -
> -/**
>   * drm_format_info_block_width - width in pixels of block.
>   * @info: pixel format info
>   * @plane: plane index
> diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
> b/drivers/gpu/drm/meson/meson_overlay.c
> index fb8515b2860c..55b3f2f2e608 100644
> --- a/drivers/gpu/drm/meson/meson_overlay.c
> +++ b/drivers/gpu/drm/meson/meson_overlay.c
> @@ -466,8 +466,8 @@ static void meson_overlay_atomic_update(struct drm_plane 
> *plane,
>   priv->viu.vd1_addr2 = gem->paddr + fb->offsets[2];
>   priv->viu.vd1_stride2 = fb->pitches[2];
>   priv->viu.vd1_height2 =
> - drm_format_plane_height(fb->height,
> - fb->format->format, 2);
> + drm_format_info_plane_height(fb->format,
> + fb->height, 2);
>   DRM_DEBUG("plane 2 addr 0x%x stride %d height %d\n",
>priv->viu.vd1_addr2,
>priv->viu.vd1_stride2,
> @@ -478,8 +478,8 @@ static void meson_overlay_atomic_update(struct drm_plane 
> *plane,
>   priv->viu.vd1_addr1 = gem->paddr + fb->offsets[1];
>   priv->viu.vd1_stride1 = fb->pitches[1];
>   priv->viu.vd1_height1 =
> - drm_format_plane_height(fb->height,
> - fb->format->format, 1);
> + drm_format_info_plane_height(fb->format,
> + fb->height, 1);
>   DRM_DEBUG("plane 1 addr 0x%x stride %d height %d\n",
>priv->viu.vd1_addr1,
>priv->viu.vd1_stride1,
> @@ -490,8 +490,8 @@ static void meson_overlay_atomic_update(struct drm_plane 
> *plane,
>   priv->viu.vd1_addr0 = gem->paddr + 

Re: [PATCHv3 16/23] drm/bridge: tc358767: clean-up link training

[Andrzej Hajda]

On 03.05.2019 14:29, Tomi Valkeinen wrote:
> The current link training code does unnecessary retry-loops, and does
> extra writes to the registers. It is easier to follow the flow and
> ensure it's similar to Toshiba's documentation if we deal with LT inside
> tc_main_link_enable() function.
>
> This patch adds tc_wait_link_training() which handles waiting for the LT
> phase to finish, and does the necessary LT register setups in
> tc_main_link_enable, without extra loops.
>
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 136 +-
>  1 file changed, 60 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 2cec06520fcf..86175e8d01b3 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -740,84 +740,24 @@ static int tc_set_video_mode(struct tc_data *tc,
>   return ret;
>  }
>  
> -static int tc_link_training(struct tc_data *tc, int pattern)
> +static int tc_wait_link_training(struct tc_data *tc)
>  {
> - const char * const *errors;
> - u32 srcctrl = tc_srcctrl(tc) | DP0_SRCCTRL_SCRMBLDIS |
> -   DP0_SRCCTRL_AUTOCORRECT;
> - int timeout;
> - int retry;
> + u32 timeout = 1000;
>   u32 value;
>   int ret;
>  
> - if (pattern == DP_TRAINING_PATTERN_1) {
> - srcctrl |= DP0_SRCCTRL_TP1;
> - errors = training_pattern1_errors;
> - } else {
> - srcctrl |= DP0_SRCCTRL_TP2;
> - errors = training_pattern2_errors;
> - }
> -
> - /* Set DPCD 0x102 for Training Part 1 or 2 */
> - tc_write(DP0_SNKLTCTRL, DP_LINK_SCRAMBLING_DISABLE | pattern);
> -
> - tc_write(DP0_LTLOOPCTRL,
> -  (0x0f << 28) | /* Defer Iteration Count */
> -  (0x0f << 24) | /* Loop Iteration Count */
> -  (0x0d << 0));  /* Loop Timer Delay */
> -
> - retry = 5;
>   do {
> - /* Set DP0 Training Pattern */
> - tc_write(DP0_SRCCTRL, srcctrl);
> -
> - /* Enable DP0 to start Link Training */
> - tc_write(DP0CTL, DP_EN);
> -
> - /* wait */
> - timeout = 1000;
> - do {
> - tc_read(DP0_LTSTAT, );
> - udelay(1);
> - } while ((!(value & LT_LOOPDONE)) && (--timeout));
> - if (timeout == 0) {
> - dev_err(tc->dev, "Link training timeout!\n");
> - } else {
> - int pattern = (value >> 11) & 0x3;
> - int error = (value >> 8) & 0x7;
> -
> - dev_dbg(tc->dev,
> - "Link training phase %d done after %d uS: %s\n",
> - pattern, 1000 - timeout, errors[error]);
> - if (pattern == DP_TRAINING_PATTERN_1 && error == 0)
> - break;
> - if (pattern == DP_TRAINING_PATTERN_2) {
> - value &= LT_CHANNEL1_EQ_BITS |
> -  LT_INTERLANE_ALIGN_DONE |
> -  LT_CHANNEL0_EQ_BITS;
> - /* in case of two lanes */
> - if ((tc->link.base.num_lanes == 2) &&
> - (value == (LT_CHANNEL1_EQ_BITS |
> -LT_INTERLANE_ALIGN_DONE |
> -LT_CHANNEL0_EQ_BITS)))
> - break;
> - /* in case of one line */
> - if ((tc->link.base.num_lanes == 1) &&
> - (value == (LT_INTERLANE_ALIGN_DONE |
> -LT_CHANNEL0_EQ_BITS)))
> - break;
> - }


As I understand all above checks can be dropped.

> - }
> - /* restart */
> - tc_write(DP0CTL, 0);
> - usleep_range(10, 20);
> - } while (--retry);
> - if (retry == 0) {
> - dev_err(tc->dev, "Failed to finish training phase %d\n",
> - pattern);
> + udelay(1);
> + tc_read(DP0_LTSTAT, );
> + } while ((!(value & LT_LOOPDONE)) && (--timeout));
> +
> + if (timeout == 0) {
> + dev_err(tc->dev, "Link training timeout waiting for 
> LT_LOOPDONE!\n");
> + return -ETIMEDOUT;
>   }
>  
> - return 0;
> + return (value >> 8) & 0x7;
> +
>  err:
>   return ret;
>  }
> @@ -927,7 +867,7 @@ static int tc_main_link_enable(struct tc_data *tc)
>  
>   if (tmp[0] != tc->assr) {
>   dev_dbg(dev, "Failed to switch display ASSR to %d, 
> falling back to unscrambled mode\n",
> -  tc->assr);
> + 

Re: [PATCH v3 7/7] drm: Remove users of drm_format_num_planes

[Paul Kocialkowski]

Hi,

On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> drm_format_info_plane_cpp() basically just returns the cpp array content
> found in the drm_format_info structure.
> 
> Since it's pretty trivial, let's remove the function and have the users use
> the array directly

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Suggested-by: Ville Syrjälä 
> Signed-off-by: Maxime Ripard 
> 
> ---
> 
> Changes from v2:
>   - new patch
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  2 +-
>  drivers/gpu/drm/arm/malidp_hw.c|  2 +-
>  drivers/gpu/drm/arm/malidp_planes.c|  2 +-
>  drivers/gpu/drm/drm_client.c   |  2 +-
>  drivers/gpu/drm/drm_fb_helper.c|  2 +-
>  drivers/gpu/drm/drm_format_helper.c|  4 ++--
>  drivers/gpu/drm/i915/intel_sprite.c|  2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c  |  2 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c  |  2 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c   |  2 +-
>  drivers/gpu/drm/msm/msm_fb.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_fb.c |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  2 +-
>  drivers/gpu/drm/stm/ltdc.c |  2 +-
>  drivers/gpu/drm/tegra/fb.c |  2 +-
>  drivers/gpu/drm/zte/zx_plane.c |  2 +-
>  include/drm/drm_fourcc.h   | 17 -
>  17 files changed, 17 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 6edae6458be8..2e2869299a84 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -133,7 +133,7 @@ static int amdgpufb_create_pinned_object(struct 
> amdgpu_fbdev *rfbdev,
>   u32 cpp;
>  
>   info = drm_get_format_info(adev->ddev, mode_cmd);
> - cpp = drm_format_info_plane_cpp(info, 0);
> + cpp = info->cpp[0];
>  
>   /* need to align pitch with crtc limits */
>   mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, cpp,
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 1c9e869f4c52..53391c0f87eb 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -383,7 +383,7 @@ static void malidp500_modeset(struct malidp_hw_device 
> *hwdev, struct videomode *
>  int malidp_format_get_bpp(u32 fmt)
>  {
>   const struct drm_format_info *info = drm_format_info(fmt);
> - int bpp = drm_format_info_plane_cpp(info, 0) * 8;
> + int bpp = info->cpp[0] * 8;
>  
>   if (bpp == 0) {
>   switch (fmt) {
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 361c02988375..07ceb4ee14e3 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -227,7 +227,7 @@ bool malidp_format_mod_supported(struct drm_device *drm,
>  
>   if (modifier & AFBC_SPLIT) {
>   if (!info->is_yuv) {
> - if (drm_format_info_plane_cpp(info, 0) <= 2) {
> + if (info->cpp[0] <= 2) {
>   DRM_DEBUG_KMS("RGB formats <= 16bpp are not 
> supported with SPLIT\n");
>   return false;
>   }
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 169d8eeaa662..5abcd83da6a6 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -259,7 +259,7 @@ drm_client_buffer_create(struct drm_client_dev *client, 
> u32 width, u32 height, u
>  
>   dumb_args.width = width;
>   dumb_args.height = height;
> - dumb_args.bpp = drm_format_info_plane_cpp(info, 0) * 8;
> + dumb_args.bpp = info->cpp[0] * 8;
>   ret = drm_mode_create_dumb(dev, _args, client->file);
>   if (ret)
>   goto err_delete;
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 184f455c99ab..09605ed69f06 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -767,7 +767,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
> drm_fb_helper *fb_helper,
> struct drm_clip_rect *clip)
>  {
>   struct drm_framebuffer *fb = fb_helper->fb;
> - unsigned int cpp = drm_format_info_plane_cpp(fb->format, 0);
> + unsigned int cpp = fb->format->cpp[0];
>   size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
>   void *src = fb_helper->fbdev->screen_buffer + offset;
>   void *dst = fb_helper->buffer->vaddr + offset;
> diff --git a/drivers/gpu/drm/drm_format_helper.c 
> b/drivers/gpu/drm/drm_format_helper.c
> index 8ad66aa1362a..0897cb9aeaff 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -36,7 +36,7 @@ static unsigned int clip_offset(struct drm_rect *clip,
>  void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
>  

Re: [PATCH v3 4/7] drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp

[Paul Kocialkowski]

Hi,

On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> So far, the drm_format_plane_cpp function was operating on the format's
> fourcc and was doing a lookup to retrieve the drm_format_info structure and
> return the cpp.
> 
> However, this is inefficient since in most cases, we will have the
> drm_format_info pointer already available so we shouldn't have to perform a
> new lookup. Some drm_fourcc functions also already operate on the
> drm_format_info pointer for that reason, so the API is quite inconsistent
> there.
> 
> Let's follow the latter pattern and remove the extra lookup while being a
> bit more consistent. In order to be extra consistent, also rename that
> function to drm_format_info_plane_cpp and to a static function in the
> header to match the current policy.

I know it's out of the scope of this patch, but we really should have an
unsigned plane index wherever it's used. We're only checking for
plane >= info->num_planes but seldom for plane < 0.

Either way, this is:
Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Reviewed-by: Emil Velikov 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  4 +++-
>  drivers/gpu/drm/arm/malidp_hw.c|  3 ++-
>  drivers/gpu/drm/arm/malidp_planes.c|  2 +-
>  drivers/gpu/drm/drm_client.c   |  3 ++-
>  drivers/gpu/drm/drm_fb_helper.c|  2 +-
>  drivers/gpu/drm/drm_format_helper.c|  4 ++--
>  drivers/gpu/drm/drm_fourcc.c   | 20 
>  drivers/gpu/drm/i915/intel_sprite.c|  3 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c  |  2 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c  |  3 ++-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c   |  2 +-
>  drivers/gpu/drm/msm/msm_fb.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_fb.c |  4 +++-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  2 +-
>  drivers/gpu/drm/stm/ltdc.c |  2 +-
>  drivers/gpu/drm/tegra/fb.c |  2 +-
>  drivers/gpu/drm/zte/zx_plane.c |  2 +-
>  include/drm/drm_fourcc.h   | 18 +-
>  18 files changed, 42 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index e47609218839..06e73a343724 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -121,6 +121,8 @@ static int amdgpufb_create_pinned_object(struct 
> amdgpu_fbdev *rfbdev,
>struct drm_mode_fb_cmd2 *mode_cmd,
>struct drm_gem_object **gobj_p)
>  {
> + const struct drm_format_info *info = drm_get_format_info(dev,
> +  mode_cmd);
>   struct amdgpu_device *adev = rfbdev->adev;
>   struct drm_gem_object *gobj = NULL;
>   struct amdgpu_bo *abo = NULL;
> @@ -131,7 +133,7 @@ static int amdgpufb_create_pinned_object(struct 
> amdgpu_fbdev *rfbdev,
>   int height = mode_cmd->height;
>   u32 cpp;
>  
> - cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
> + cpp = drm_format_info_plane_cpp(info, 0);
>  
>   /* need to align pitch with crtc limits */
>   mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, cpp,
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 8df12e9a33bb..1c9e869f4c52 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -382,7 +382,8 @@ static void malidp500_modeset(struct malidp_hw_device 
> *hwdev, struct videomode *
>  
>  int malidp_format_get_bpp(u32 fmt)
>  {
> - int bpp = drm_format_plane_cpp(fmt, 0) * 8;
> + const struct drm_format_info *info = drm_format_info(fmt);
> + int bpp = drm_format_info_plane_cpp(info, 0) * 8;
>  
>   if (bpp == 0) {
>   switch (fmt) {
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 8f89813d08c1..361c02988375 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -227,7 +227,7 @@ bool malidp_format_mod_supported(struct drm_device *drm,
>  
>   if (modifier & AFBC_SPLIT) {
>   if (!info->is_yuv) {
> - if (drm_format_plane_cpp(format, 0) <= 2) {
> + if (drm_format_info_plane_cpp(info, 0) <= 2) {
>   DRM_DEBUG_KMS("RGB formats <= 16bpp are not 
> supported with SPLIT\n");
>   return false;
>   }
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index f20d1dda3961..169d8eeaa662 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -243,6 +243,7 @@ static void drm_client_buffer_delete(struct 
> drm_client_buffer *buffer)
>  static struct drm_client_buffer *
>  drm_client_buffer_create(struct 

Re: [RFC PATCH] drm/i915: Tolerate file owned GEM contexts on hot unbind

[Janusz Krzysztofik]

On Friday, May 17, 2019 4:32:35 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-17 15:06:17)
> > From: Janusz Krzysztofik 
> > 
> > During i915_driver_unload(), GEM contexts are verified restrictively
> > inside i915_gem_fini() if they don't consume shared resources which
> > should be cleaned up before the driver is released.  If those checks
> > don't result in kernel panic, one more check is performed at the end of
> > i915_gem_fini() which issues a WARN_ON() if GEM contexts still exist.
> 
> Just fix the underlying bug of this code being called too early. The
> assumptions we made for unload are clearly invalid when applied to
> unbind, and we need to split the phases.
> -Chris

Thanks Chris, I think I get it finally.

Janusz




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

Re: [PATCHv3 12/23] drm/bridge: tc358767: ensure DP is disabled before LT

[Andrzej Hajda]

On 03.05.2019 14:29, Tomi Valkeinen wrote:
> Link training will sometimes fail if the DP link is enabled when
> tc_main_link_enable() is called. The driver makes sure the DP link is
> disabled when the DP output is disabled, and we never enable the DP
> without first disabling it, so this should never happen.
>
> However, as the HW behavior seems to be somewhat random if DP link has
> erroneously been left enabled, let's add a WARN_ON() for the case and
> set DP0CTL to 0.
>
> Signed-off-by: Tomi Valkeinen 
Reviewed-by: Andrzej Hajda 

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

Re: [PATCHv3 11/23] drm/bridge: tc358767: disable only video stream in tc_stream_disable

[Andrzej Hajda]

On 03.05.2019 14:29, Tomi Valkeinen wrote:
> Currently the code writes 0 to DP0CTL in tc_stream_disable(), which
> disables the whole DP link instead of just the video stream. We always
> disable the link and the stream together from tc_bridge_disable(), so
> this doesn't cause any issues.
>
> Nevertheless, fix this by only clearing VID_EN in tc_stream_disable to
> stop the video stream while keeping the link enabled.
>
> Signed-off-by: Tomi Valkeinen 
Reviewed-by: Andrzej Hajda 

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

[PATCH 1/3] drm/komeda: Add component komeda_merger

[james qian wang (Arm Technology China)]

Introduce a new component komeda_merger, because D71 HW supports to split
a whole image to two half parts and does the scaling independently. Merger
merges two separate results to one, and output it to compositor or wb_layer
For this patch:
- Add the definition of komeda_merger/merger_state
- Report and initialize komeda_merger according to the D71 HW.

Signed-off-by: James Qian Wang (Arm Technology China) 
---
 .../arm/display/komeda/d71/d71_component.c| 74 +++
 .../drm/arm/display/komeda/komeda_pipeline.c  |  3 +
 .../drm/arm/display/komeda/komeda_pipeline.h  | 18 -
 .../arm/display/komeda/komeda_private_obj.c   | 49 
 4 files changed, 143 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index ca4b2f7a8106..3266bd54c936 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -726,6 +726,77 @@ static int d71_scaler_init(struct d71_dev *d71,
return 0;
 }
 
+static void d71_merger_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+   struct komeda_merger_state *st = to_merger_st(state);
+   u32 __iomem *reg = c->reg;
+   u32 index;
+
+   for_each_changed_input(state, index)
+   malidp_write32(reg, MG_INPUT_ID0 + index * 4,
+  to_d71_input_id(>inputs[index]));
+
+   malidp_write32(reg, MG_SIZE, HV_SIZE(st->hsize_merged,
+st->vsize_merged));
+   malidp_write32(reg, BLK_CONTROL, BLK_CTRL_EN);
+}
+
+static void d71_merger_dump(struct komeda_component *c, struct seq_file *sf)
+{
+   u32 v;
+
+   dump_block_header(sf, c->reg);
+
+   get_values_from_reg(c->reg, MG_INPUT_ID0, 1, );
+   seq_printf(sf, "MG_INPUT_ID0:\t\t0x%X\n", v);
+
+   get_values_from_reg(c->reg, MG_INPUT_ID1, 1, );
+   seq_printf(sf, "MG_INPUT_ID1:\t\t0x%X\n", v);
+
+   get_values_from_reg(c->reg, BLK_CONTROL, 1, );
+   seq_printf(sf, "MG_CONTROL:\t\t0x%X\n", v);
+
+   get_values_from_reg(c->reg, MG_SIZE, 1, );
+   seq_printf(sf, "MG_SIZE:\t\t0x%X\n", v);
+}
+
+static const struct komeda_component_funcs d71_merger_funcs = {
+   .update = d71_merger_update,
+   .disable= d71_component_disable,
+   .dump_register  = d71_merger_dump,
+};
+
+static int d71_merger_init(struct d71_dev *d71,
+  struct block_header *blk, u32 __iomem *reg)
+{
+   struct komeda_component *c;
+   struct komeda_merger *merger;
+   u32 pipe_id, comp_id;
+
+   get_resources_id(blk->block_info, _id, _id);
+
+   c = komeda_component_add(>pipes[pipe_id]->base, sizeof(*merger),
+comp_id,
+BLOCK_INFO_INPUT_ID(blk->block_info),
+_merger_funcs,
+MG_NUM_INPUTS_IDS, get_valid_inputs(blk),
+MG_NUM_OUTPUTS_IDS, reg,
+"CU%d_MERGER", pipe_id);
+
+   if (!c) {
+   DRM_ERROR("Failed to initialize merger.\n");
+   return -1;
+   }
+
+   merger = to_merger(c);
+
+   set_range(>hsize_merged, 4, 4032);
+   set_range(>vsize_merged, 4, 4096);
+
+   return 0;
+}
+
 static void d71_improc_update(struct komeda_component *c,
  struct komeda_component_state *state)
 {
@@ -951,7 +1022,10 @@ int d71_probe_block(struct d71_dev *d71,
break;
 
case D71_BLK_TYPE_CU_SPLITTER:
+   break;
+
case D71_BLK_TYPE_CU_MERGER:
+   err = d71_merger_init(d71, blk, reg);
break;
 
case D71_BLK_TYPE_DOU:
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index 96248586b4e8..f434cb526dbe 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -92,6 +92,9 @@ komeda_pipeline_get_component_pos(struct komeda_pipeline 
*pipe, int id)
case KOMEDA_COMPONENT_SCALER1:
pos = to_cpos(pipe->scalers[id - KOMEDA_COMPONENT_SCALER0]);
break;
+   case KOMEDA_COMPONENT_MERGER:
+   pos = to_cpos(pipe->merger);
+   break;
case KOMEDA_COMPONENT_IPS0:
case KOMEDA_COMPONENT_IPS1:
temp = mdev->pipelines[id - KOMEDA_COMPONENT_IPS0];
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 2c7e3f97a6f3..c92733736799 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -276,6 +276,18 @@ struct komeda_compiz_state {
struct 

[PATCH 3/3] drm/komeda: Add layer split support

[james qian wang (Arm Technology China)]

Komeda supports two types of layer split:
- none-scaling split
- scaling split
Since D71 merger only support scaler as input, so for none-scaling split,
the two layer dflow will be output to compiz directly. for scaling_split,
the data flow will be merged by merger firstly, then output the merged
data flow to compiz.

Komeda handles the split in kernel completely to hide the detailed and
complicated split calcualtion to user mode, for user only need to set the
layer_split property to enable/disable it.

Signed-off-by: James Qian Wang (Arm Technology China) 
---
 .../gpu/drm/arm/display/komeda/komeda_kms.c   |   8 +
 .../gpu/drm/arm/display/komeda/komeda_kms.h   |  22 +-
 .../drm/arm/display/komeda/komeda_pipeline.c  |  23 +-
 .../drm/arm/display/komeda/komeda_pipeline.h  |  12 +
 .../display/komeda/komeda_pipeline_state.c| 300 +-
 .../gpu/drm/arm/display/komeda/komeda_plane.c |  24 +-
 6 files changed, 378 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 0ec76656cd1f..5d10c55c9c40 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -173,6 +173,14 @@ static int komeda_crtc_normalize_zpos(struct drm_crtc 
*crtc,
plane = plane_st->plane;
 
plane_st->normalized_zpos = order++;
+   /* When layer_split has been enabled, one plane will be handled
+* by two separated komeda layers (left/right), which may needs
+* two zorders.
+* - zorder: for left_layer for left display part.
+* - zorder + 1: will be reserved for right layer.
+*/
+   if (to_kplane_st(plane_st)->layer_split)
+   order++;
 
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] zpos:%d, normalized zpos: %d\n",
 plane->base.id, plane->name,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index d1cef46f7068..93a0cdea056f 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -36,6 +36,8 @@ struct komeda_plane {
 
/** @prop_img_enhancement: for on/off image enhancement */
struct drm_property *prop_img_enhancement;
+   /** @prop_layer_split: for on/off layer_split */
+   struct drm_property *prop_layer_split;
 };
 
 /**
@@ -50,8 +52,11 @@ struct komeda_plane_state {
/** @zlist_node: zorder list node */
struct list_head zlist_node;
 
-   /* @img_enhancement: on/off image enhancement */
-   u8 img_enhancement : 1;
+   /* @img_enhancement: on/off image enhancement
+* @layer_split: on/off layer_split
+*/
+   u8 img_enhancement : 1,
+  layer_split : 1;
 };
 
 /**
@@ -149,6 +154,19 @@ is_only_changed_connector(struct drm_crtc_state *st, 
struct drm_connector *conn)
return BIT(drm_connector_index(conn)) == changed_connectors;
 }
 
+static inline bool has_flip_h(u32 rot)
+{
+   u32 rotation = drm_rotation_simplify(rot,
+DRM_MODE_ROTATE_0 |
+DRM_MODE_ROTATE_90 |
+DRM_MODE_REFLECT_MASK);
+
+   if (rotation & DRM_MODE_ROTATE_90)
+   return !!(rotation & DRM_MODE_REFLECT_Y);
+   else
+   return !!(rotation & DRM_MODE_REFLECT_X);
+}
+
 int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms, struct komeda_dev 
*mdev);
 
 int komeda_kms_add_crtcs(struct komeda_kms_dev *kms, struct komeda_dev *mdev);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index f434cb526dbe..c7c3caad13bd 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -266,16 +266,35 @@ static void komeda_component_verify_inputs(struct 
komeda_component *c)
}
 }
 
+static struct komeda_layer *
+komeda_get_layer_split_right_layer(struct komeda_pipeline *pipe,
+  struct komeda_layer *left)
+{
+   int index = left->base.id - KOMEDA_COMPONENT_LAYER0;
+   int i;
+
+   for (i = index + 1; i < pipe->n_layers; i++)
+   if (left->layer_type == pipe->layers[i]->layer_type)
+   return pipe->layers[i];
+   return NULL;
+}
+
 static void komeda_pipeline_assemble(struct komeda_pipeline *pipe)
 {
struct komeda_component *c;
-   int id;
+   struct komeda_layer *layer;
+   int i, id;
 
dp_for_each_set_bit(id, pipe->avail_comps) {
c = komeda_pipeline_get_component(pipe, id);
-
komeda_component_verify_inputs(c);
}
+   /* calculate right layer for the layer split */
+   for (i = 0; 

[PATCH 2/3] drm/komeda: Add split support for scaler

[james qian wang (Arm Technology China)]

To achieve same caling effect compare with none split, the texel
calculation need to use the same scaling ratio before split, so add
"total_xxx" to pipeline to describe the hsize/vsize before split.
Update pipeline and d71_scaler_update accordingly.

Signed-off-by: James Qian Wang (Arm Technology China) 
---
 .../arm/display/komeda/d71/d71_component.c| 47 +--
 .../drm/arm/display/komeda/komeda_pipeline.h  | 19 ++--
 .../display/komeda/komeda_pipeline_state.c| 21 -
 .../gpu/drm/arm/display/komeda/komeda_plane.c |  8 ++--
 .../arm/display/komeda/komeda_wb_connector.c  |  2 +-
 5 files changed, 81 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 3266bd54c936..d101a5cc2766 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -642,23 +642,58 @@ static void d71_scaler_update(struct komeda_component *c,
 
malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize_in, st->vsize_in));
malidp_write32(reg, SC_OUT_SIZE, HV_SIZE(st->hsize_out, st->vsize_out));
+   malidp_write32(reg, SC_H_CROP, HV_CROP(st->left_crop, st->right_crop));
+
+   /* for right part, HW only sample the valid pixel which means the pixels
+* in left_crop will be jumpped, and the first sample pixel is:
+*
+* dst_a = st->total_hsize_out - st->hsize_out + st->left_crop + 0.5;
+*
+* Then the corresponding texel in src is:
+*
+* h_delta_phase = st->total_hsize_in / st->total_hsize_out;
+* src_a = dst_A * h_delta_phase;
+*
+* and h_init_phase is src_a deduct the real source start src_S;
+*
+* src_S = st->total_hsize_in - st->hsize_in;
+* h_init_phase = src_a - src_S;
+*
+* And HW precision for the initial/delta_phase is 16:16 fixed point,
+* the following is the simplified formula
+*/
+   if (st->right_part) {
+   u32 dst_a = st->total_hsize_out - st->hsize_out + st->left_crop;
+
+   if (st->en_img_enhancement)
+   dst_a -= 1;
+
+   init_ph = ((st->total_hsize_in * (2 * dst_a + 1) -
+   2 * st->total_hsize_out * (st->total_hsize_in -
+   st->hsize_in)) << 15) / st->total_hsize_out;
+   } else {
+   init_ph = (st->total_hsize_in << 15) / st->total_hsize_out;
+   }
 
-   init_ph = (st->hsize_in << 15) / st->hsize_out;
malidp_write32(reg, SC_H_INIT_PH, init_ph);
 
-   delta_ph = (st->hsize_in << 16) / st->hsize_out;
+   delta_ph = (st->total_hsize_in << 16) / st->total_hsize_out;
malidp_write32(reg, SC_H_DELTA_PH, delta_ph);
 
-   init_ph = (st->vsize_in << 15) / st->vsize_out;
+   init_ph = (st->total_vsize_in << 15) / st->vsize_out;
malidp_write32(reg, SC_V_INIT_PH, init_ph);
 
-   delta_ph = (st->vsize_in << 16) / st->vsize_out;
+   delta_ph = (st->total_vsize_in << 16) / st->vsize_out;
malidp_write32(reg, SC_V_DELTA_PH, delta_ph);
 
ctrl = 0;
ctrl |= st->en_scaling ? SC_CTRL_SCL : 0;
ctrl |= st->en_alpha ? SC_CTRL_AP : 0;
ctrl |= st->en_img_enhancement ? SC_CTRL_IENH : 0;
+   /* If we use the hardware splitter we shouldn't set SC_CTRL_LS */
+   if (st->en_split &&
+   state->inputs[0].component->id != KOMEDA_COMPONENT_SPLITTER)
+   ctrl |= SC_CTRL_LS;
 
malidp_write32(reg, BLK_CONTROL, ctrl);
malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(>inputs[0]));
@@ -716,10 +751,12 @@ static int d71_scaler_init(struct d71_dev *d71,
}
 
scaler = to_scaler(c);
-   set_range(>hsize, 4, d71->max_line_size);
+   set_range(>hsize, 4, 2048);
set_range(>vsize, 4, 4096);
scaler->max_downscaling = 6;
scaler->max_upscaling = 64;
+   scaler->scaling_split_overlap = 8;
+   scaler->enh_split_overlap = 1;
 
malidp_write32(c->reg, BLK_CONTROL, 0);
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index c92733736799..4e1cf8fd89bf 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -247,15 +247,22 @@ struct komeda_scaler {
struct malidp_range hsize, vsize;
u32 max_upscaling;
u32 max_downscaling;
+   u8 scaling_split_overlap; /* split overlap for scaling */
+   u8 enh_split_overlap; /* split overlap for image enhancement */
 };
 
 struct komeda_scaler_state {
struct komeda_component_state base;
u16 hsize_in, vsize_in;
u16 hsize_out, vsize_out;
+   u16 total_hsize_in, total_vsize_in;
+   u16 total_hsize_out; /* total_ are size before split */
+   u16 left_crop, 

[PATCH 0/3] drm/komeda: Add layer split support

[james qian wang (Arm Technology China)]

This patch series add laye split support for komeda.

For layer split, a plane state will be split to two data flows and handled
by two separated komeda layer input pipelines. komeda supports two types of
layer split:
- none-scaling split:
 / layer-left -> \
  plane_state  compiz-> ...
 \ layer-right-> /

- scaling split:
 / layer-left -> scaler->\
 plane_state  merger -> compiz-> ...
 \ layer-right-> scaler->/

Since merger only supports scaler as input, so for none-scaling split, two
layer data flows will be output to compiz directly. for scaling_split, two
data flows will be merged by merger firstly, then merger outputs one merged
data flow to compiz.

This patch series depends on:
- https://patchwork.freedesktop.org/series/60767/
- https://patchwork.freedesktop.org/series/60838/

James Qian Wang (Arm Technology China) (3):
  drm/komeda: Add component komeda_merger
  drm/komeda: Add split support for scaler
  drm/komeda: Add layer split support

 .../arm/display/komeda/d71/d71_component.c| 121 ++-
 .../gpu/drm/arm/display/komeda/komeda_kms.c   |   8 +
 .../gpu/drm/arm/display/komeda/komeda_kms.h   |  22 +-
 .../drm/arm/display/komeda/komeda_pipeline.c  |  26 +-
 .../drm/arm/display/komeda/komeda_pipeline.h  |  49 ++-
 .../display/komeda/komeda_pipeline_state.c| 321 +-
 .../gpu/drm/arm/display/komeda/komeda_plane.c |  32 +-
 .../arm/display/komeda/komeda_private_obj.c   |  49 +++
 .../arm/display/komeda/komeda_wb_connector.c  |   2 +-
 9 files changed, 602 insertions(+), 28 deletions(-)

-- 
2.17.1

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

[PATCH] drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read

[Murray McAllister]

If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
of SVGA3D_INVALID_ID, and a shader type of
SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot
will be 4294967295, leading to an out-of-bounds read in vmw_binding_loc()
when the offset is calculated.

Signed-off-by: Murray McAllister 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 2ff7ba04d8c8..9aeb5448cfc1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -2193,7 +2193,8 @@ static int vmw_cmd_dx_set_shader(struct vmw_private 
*dev_priv,
 
cmd = container_of(header, typeof(*cmd), header);
 
-   if (cmd->body.type >= SVGA3D_SHADERTYPE_DX10_MAX) {
+   if (cmd->body.type >= SVGA3D_SHADERTYPE_DX10_MAX ||
+   cmd->body.type < SVGA3D_SHADERTYPE_MIN) {
VMW_DEBUG_USER("Illegal shader type %u.\n",
   (unsigned int) cmd->body.type);
return -EINVAL;
-- 
2.20.1