[radeon-alex:amd-19.50 2129/2680] drivers/gpu/drm/ttm/ttm_bo_util.c:305:43: error: macro "kmap_atomic_prot" passed 3 arguments, but takes just 2

2020-01-07 Thread kbuild test robot
Hi Yifan,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head:   f981f76437edab0861f3721c27f1c3cec5903dcc
commit: f2d51786363ee2a72c55570835e4c79066af2782 [2129/2680] drm/amdkcl: Test 
whether kmap_atomic() wants one argument
config: x86_64-randconfig-h003-20200107 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout f2d51786363ee2a72c55570835e4c79066af2782
# 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 >>):

atomic_read(const atomic_t *v)
^~~
   In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
   include/kcl/kcl_mm_types.h: At top level:
   include/kcl/kcl_mm_types.h:10:3: error: conflicting types for 'pfn_t'
} pfn_t;
  ^
   In file included from include/asm-generic/memory_model.h:5:0,
from arch/x86/include/asm/page.h:76,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/rcupdate.h:27,
from include/linux/rbtree.h:34,
from include/drm/drm_mm.h:41,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
   include/linux/pfn.h:15:3: note: previous declaration of 'pfn_t' was here
} pfn_t;
  ^
   In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
   include/kcl/kcl_mm_types.h:33:13: error: conflicting types for 'vm_fault_t'
typedef int vm_fault_t;
^~
   In file included from include/drm/drm_mm.h:43:0,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
   include/linux/mm_types.h:631:32: note: previous declaration of 'vm_fault_t' 
was here
typedef __bitwise unsigned int vm_fault_t;
   ^~
   In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
   include/kcl/kcl_mm_types.h:35:26: error: conflicting types for 
'vmf_insert_mixed'
static inline vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma,
 ^~~~
   In file included from include/drm/drm_vma_manager.h:27:0,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
   include/linux/mm.h:2587:12: note: previous declaration of 'vmf_insert_mixed' 
was here
vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
   ^~~~
   In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
   include/kcl/kcl_mm_types.h: In function 'vmf_insert_mixed':
   include/kcl/kcl_mm_types.h:41:8: error: implicit declaration of function 
'vm_insert_mixed'; did you mean 'vmf_insert_mixed'? 
[-Werror=implicit-function-declaration]
 err = vm_insert_mixed(vma, addr, pfn_t_to_pfn(pfn));
   ^~~
   vmf_insert_mixed
   include/kcl/kcl_mm_types.h: At top level:
   include/kcl/kcl_mm_types.h:53:26: error: conflicting types for 
'vmf_insert_pfn'
static inline vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma,
 ^~
   In file included from include/drm/drm_vma_manager.h:27:0,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
   include/linux/mm.h:2583:12: note: previous declaration of 'vmf_insert_pfn' 
was here
vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
   ^~
   In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
   include/kcl/kcl_mm_types.h: In function 'vmf_insert_pfn':
   include/kcl/kcl_mm_types.h:56:13: error: implicit declaration of function 
'vm_insert_pfn'; did you mean 'vmf_insert_pfn'? 
[-Werror=implicit-function-declaration]
  int err = vm_insert_pfn(vma, addr, pfn);
^
vmf_insert_pfn
   drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_kmap_atomic_prot':
   drivers/gpu/drm/ttm/ttm_bo_util.c:265:57: error: 'KM_USER0' undeclared 
(first use in this function); did you mean 'SI_USER'?
#define __kcl__kmap_atomic(__page)  kmap_

linux-next: manual merge of the generic-ioremap tree with the drm-intel tree

2020-01-07 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the generic-ioremap tree got a conflict in:

  drivers/gpu/drm/i915/i915_gem_gtt.c

between commit:

  2c86e55d2ab5 ("drm/i915/gtt: split up i915_gem_gtt")

from the drm-intel tree and commit:

  4bdc0d676a64 ("remove ioremap_nocache and devm_ioremap_nocache")

from the generic-ioremap tree.

I fixed it up (I used the file from the former and added the following
merge fix patch) 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.

From: Stephen Rothwell 
Date: Wed, 8 Jan 2020 17:04:59 +1100
Subject: [PATCH] fix up for "drm/i915/gtt: split up i915_gem_gtt"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 99189cdba8a9..1a2b5dcde960 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -801,7 +801,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
 * readback check when writing GTT PTE entries.
 */
if (IS_GEN9_LP(i915) || INTEL_GEN(i915) >= 10)
-   ggtt->gsm = ioremap_nocache(phys_addr, size);
+   ggtt->gsm = ioremap(phys_addr, size);
else
ggtt->gsm = ioremap_wc(phys_addr, size);
if (!ggtt->gsm) {
-- 
2.24.0

-- 
Cheers,
Stephen Rothwell


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


[PATCH] nouveau/secboot/gm20b: initialize pointer in gm20b_secboot_new()

2020-01-07 Thread Dan Carpenter
We accidentally set "psb" which is a no-op instead of "*psb" so it
generates a static checker warning.  We should probably set it before
the first error return so that it's always initialized.

Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support")
Signed-off-by: Dan Carpenter 
---
Static analysis.  I'm not sure how this is called.

 drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
index df8b919dcf09..ace6fefba428 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
@@ -108,6 +108,7 @@ gm20b_secboot_new(struct nvkm_device *device, int index,
struct gm200_secboot *gsb;
struct nvkm_acr *acr;
 
+   *psb = NULL;
acr = acr_r352_new(BIT(NVKM_SECBOOT_FALCON_FECS) |
   BIT(NVKM_SECBOOT_FALCON_PMU));
if (IS_ERR(acr))
@@ -116,10 +117,8 @@ gm20b_secboot_new(struct nvkm_device *device, int index,
acr->optional_falcons = BIT(NVKM_SECBOOT_FALCON_PMU);
 
gsb = kzalloc(sizeof(*gsb), GFP_KERNEL);
-   if (!gsb) {
-   psb = NULL;
+   if (!gsb)
return -ENOMEM;
-   }
*psb = >base;
 
ret = nvkm_secboot_ctor(_secboot, acr, device, index, >base);
-- 
2.11.0

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


[PATCH] gpu/drm: clean up white space in drm_legacy_lock_master_cleanup()

2020-01-07 Thread Dan Carpenter
We moved this code to a different file and accidentally deleted a
newline.

Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/drm_lock.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
index 2e8ce99d0baa..2c79e8199e3c 100644
--- a/drivers/gpu/drm/drm_lock.c
+++ b/drivers/gpu/drm/drm_lock.c
@@ -360,7 +360,8 @@ void drm_legacy_lock_master_cleanup(struct drm_device *dev, 
struct drm_master *m
/*
 * Since the master is disappearing, so is the
 * possibility to lock.
-*/ mutex_lock(>struct_mutex);
+*/
+   mutex_lock(>struct_mutex);
if (master->lock.hw_lock) {
if (dev->sigdata.lock == master->lock.hw_lock)
dev->sigdata.lock = NULL;
-- 
2.11.0

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


[PATCH v2 0/7] Add dts for mt8183 GPU (and misc panfrost patches)

2020-01-07 Thread Nicolas Boichat
Hi!

Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
finally got around to give this a real try.

The main purpose of this series is to upstream the dts change and the binding
document, but I wanted to see how far I could probe the GPU, to check that the
binding is indeed correct. The rest of the patches are RFC/work-in-progress, but
I think some of them could already be picked up.

So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of
backports to get the latest panfrost driver (I should probably try on
linux-next at some point but this was the path of least resistance).

I tested it as a module as it's more challenging (originally probing would
work built-in, on boot, but not as a module, as I didn't have the power
domain changes, and all power domains are on by default during boot).

Probing logs looks like this, currently:
[  221.867726] panfrost 1304.gpu: clock rate = 51170
[  221.867929] panfrost 1304.gpu: Linked as a consumer to regulator.14
[  221.868600] panfrost 1304.gpu: Linked as a consumer to regulator.31
[  221.870586] panfrost 1304.gpu: Linked as a consumer to 
genpd:0:1304.gpu
[  221.871492] panfrost 1304.gpu: Linked as a consumer to 
genpd:1:1304.gpu
[  221.871866] panfrost 1304.gpu: Linked as a consumer to 
genpd:2:1304.gpu
[  221.872427] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 
status 0x0
[  221.872439] panfrost 1304.gpu: features: ,13de77ff, issues: 
,0400
[  221.872445] panfrost 1304.gpu: Features: L2:0x07120206 Shader:0x 
Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7
[  221.872449] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1
[  221.873526] panfrost 1304.gpu: error powering up gpu stack
[  221.878088] [drm] Initialized panfrost 1.1.0 20180908 for 1304.gpu on 
minor 2
[  221.940817] panfrost 1304.gpu: error powering up gpu stack
[  222.018233] panfrost 1304.gpu: error powering up gpu stack
(repeated)

So the GPU is probed, but there's an issue when powering up the STACK, not
quite sure why, I'll try to have a deeper look, at some point.

Thanks!

Nicolas

v2:
 - Use sram instead of mali_sram as SRAM supply name.
 - Rename mali@ to gpu@.
 - Add dt-bindings changes
 - Stacking patches after the device tree change that allow basic
   probing (still incomplete and broken).

Nicolas Boichat (7):
  dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
  arm64: dts: mt8183: Add node for the Mali GPU
  drm/panfrost: Improve error reporting in panfrost_gpu_power_on
  drm/panfrost: Add support for a second regulator for the GPU
  drm/panfrost: Add support for multiple power domain support
  RFC: drm/panfrost: Add bifrost compatible string
  RFC: drm/panfrost: devfreq: Add support for 2 regulators

 .../bindings/gpu/arm,mali-bifrost.yaml|  20 
 arch/arm64/boot/dts/mediatek/mt8183-evb.dts   |   7 ++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi  | 104 +
 drivers/gpu/drm/panfrost/panfrost_devfreq.c   |  18 +++
 drivers/gpu/drm/panfrost/panfrost_device.c| 108 --
 drivers/gpu/drm/panfrost/panfrost_device.h|   7 ++
 drivers/gpu/drm/panfrost/panfrost_drv.c   |   1 +
 drivers/gpu/drm/panfrost/panfrost_gpu.c   |  15 ++-
 8 files changed, 267 insertions(+), 13 deletions(-)

-- 
2.24.1.735.g03f4e72817-goog

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


[PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU

2020-01-07 Thread Nicolas Boichat
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
regulator for their SRAM, let's add support for that.

Signed-off-by: Nicolas Boichat 
---
 drivers/gpu/drm/panfrost/panfrost_device.c | 21 +
 drivers/gpu/drm/panfrost/panfrost_device.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 238fb6d54df4732..a0b0a6fef8b4e63 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -102,12 +102,33 @@ static int panfrost_regulator_init(struct panfrost_device 
*pfdev)
return ret;
}
 
+   pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram");
+   if (IS_ERR(pfdev->regulator_sram)) {
+   ret = PTR_ERR(pfdev->regulator_sram);
+   dev_err(pfdev->dev, "failed to get SRAM regulator: %d\n", ret);
+   goto err;
+   }
+
+   if (pfdev->regulator_sram) {
+   ret = regulator_enable(pfdev->regulator_sram);
+   if (ret < 0) {
+   dev_err(pfdev->dev,
+   "failed to enable SRAM regulator: %d\n", ret);
+   goto err;
+   }
+   }
+
return 0;
+
+err:
+   regulator_disable(pfdev->regulator);
+   return ret;
 }
 
 static void panfrost_regulator_fini(struct panfrost_device *pfdev)
 {
regulator_disable(pfdev->regulator);
+   regulator_disable(pfdev->regulator_sram);
 }
 
 int panfrost_device_init(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h 
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 06713811b92cdf7..a124334d69e7e93 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -60,6 +60,7 @@ struct panfrost_device {
struct clk *clock;
struct clk *bus_clock;
struct regulator *regulator;
+   struct regulator *regulator_sram;
struct reset_control *rstc;
 
struct panfrost_features features;
-- 
2.24.1.735.g03f4e72817-goog

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


[PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support

2020-01-07 Thread Nicolas Boichat
When there is a single power domain per device, the core will
ensure the power domains are all switched on.

However, when there are multiple ones, as in MT8183 Bifrost GPU,
we need to handle them in driver code.


Signed-off-by: Nicolas Boichat 
---

The downstream driver we use on chromeos-4.19 currently uses 2
additional devices in device tree to accomodate for this [1], but
I believe this solution is cleaner.

[1] 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#31

drivers/gpu/drm/panfrost/panfrost_device.c | 87 --
 drivers/gpu/drm/panfrost/panfrost_device.h |  4 +
 2 files changed, 83 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c 
b/drivers/gpu/drm/panfrost/panfrost_device.c
index a0b0a6fef8b4e63..c6e9e059de94a4d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "panfrost_device.h"
@@ -131,6 +132,67 @@ static void panfrost_regulator_fini(struct panfrost_device 
*pfdev)
regulator_disable(pfdev->regulator_sram);
 }
 
+static void panfrost_pm_domain_fini(struct panfrost_device *pfdev)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(pfdev->pm_domain_devs); i++) {
+   if (!pfdev->pm_domain_devs[i])
+   break;
+
+   if (pfdev->pm_domain_links[i])
+   device_link_del(pfdev->pm_domain_links[i]);
+
+   dev_pm_domain_detach(pfdev->pm_domain_devs[i], true);
+   }
+}
+
+static int panfrost_pm_domain_init(struct panfrost_device *pfdev)
+{
+   int err;
+   int i, num_domains;
+
+   num_domains = of_count_phandle_with_args(pfdev->dev->of_node,
+"power-domains",
+"#power-domain-cells");
+   /* Single domains are handled by the core. */
+   if (num_domains < 2)
+   return 0;
+
+   if (num_domains > ARRAY_SIZE(pfdev->pm_domain_devs)) {
+   dev_err(pfdev->dev, "Too many pm-domains: %d\n", num_domains);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < num_domains; i++) {
+   pfdev->pm_domain_devs[i] =
+   dev_pm_domain_attach_by_id(pfdev->dev, i);
+   if (IS_ERR(pfdev->pm_domain_devs[i])) {
+   err = PTR_ERR(pfdev->pm_domain_devs[i]);
+   pfdev->pm_domain_devs[i] = NULL;
+   dev_err(pfdev->dev,
+   "failed to get pm-domain %d: %d\n", i, err);
+   goto err;
+   }
+
+   pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,
+   pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |
+   DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);
+   if (!pfdev->pm_domain_links[i]) {
+   dev_err(pfdev->pm_domain_devs[i],
+   "adding device link failed!\n");
+   err = -ENODEV;
+   goto err;
+   }
+   }
+
+   return 0;
+
+err:
+   panfrost_pm_domain_fini(pfdev);
+   return err;
+}
+
 int panfrost_device_init(struct panfrost_device *pfdev)
 {
int err;
@@ -161,37 +223,45 @@ int panfrost_device_init(struct panfrost_device *pfdev)
goto err_out1;
}
 
+   err = panfrost_pm_domain_init(pfdev);
+   if (err) {
+   dev_err(pfdev->dev, "pm_domain init failed %d\n", err);
+   goto err_out2;
+   }
+
res = platform_get_resource(pfdev->pdev, IORESOURCE_MEM, 0);
pfdev->iomem = devm_ioremap_resource(pfdev->dev, res);
if (IS_ERR(pfdev->iomem)) {
dev_err(pfdev->dev, "failed to ioremap iomem\n");
err = PTR_ERR(pfdev->iomem);
-   goto err_out2;
+   goto err_out3;
}
 
err = panfrost_gpu_init(pfdev);
if (err)
-   goto err_out2;
+   goto err_out3;
 
err = panfrost_mmu_init(pfdev);
if (err)
-   goto err_out3;
+   goto err_out4;
 
err = panfrost_job_init(pfdev);
if (err)
-   goto err_out4;
+   goto err_out5;
 
err = panfrost_perfcnt_init(pfdev);
if (err)
-   goto err_out5;
+   goto err_out6;
 
return 0;
-err_out5:
+err_out6:
panfrost_job_fini(pfdev);
-err_out4:
+err_out5:
panfrost_mmu_fini(pfdev);
-err_out3:
+err_out4:
panfrost_gpu_fini(pfdev);
+err_out3:
+   panfrost_pm_domain_fini(pfdev);
 err_out2:
panfrost_reset_fini(pfdev);
 err_out1:
@@ -208,6 +278,7 @@ void panfrost_device_fini(struct panfrost_device *pfdev)

[PATCH v2 3/7] drm/panfrost: Improve error reporting in panfrost_gpu_power_on

2020-01-07 Thread Nicolas Boichat
It is useful to know which component cannot be powered on.

Signed-off-by: Nicolas Boichat 

---

Was useful when trying to probe bifrost GPU, to understand what
issue we are facing.
---
 drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c 
b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index 8822ec13a0d619f..ba02bbfcf28c011 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -308,21 +308,26 @@ void panfrost_gpu_power_on(struct panfrost_device *pfdev)
gpu_write(pfdev, L2_PWRON_LO, pfdev->features.l2_present);
ret = readl_relaxed_poll_timeout(pfdev->iomem + L2_READY_LO,
val, val == pfdev->features.l2_present, 100, 1000);
+   if (ret)
+   dev_err(pfdev->dev, "error powering up gpu L2");
 
gpu_write(pfdev, STACK_PWRON_LO, pfdev->features.stack_present);
-   ret |= readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO,
+   ret = readl_relaxed_poll_timeout(pfdev->iomem + STACK_READY_LO,
val, val == pfdev->features.stack_present, 100, 1000);
+   if (ret)
+   dev_err(pfdev->dev, "error powering up gpu stack");
 
gpu_write(pfdev, SHADER_PWRON_LO, pfdev->features.shader_present);
-   ret |= readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO,
+   ret = readl_relaxed_poll_timeout(pfdev->iomem + SHADER_READY_LO,
val, val == pfdev->features.shader_present, 100, 1000);
+   if (ret)
+   dev_err(pfdev->dev, "error powering up gpu shader");
 
gpu_write(pfdev, TILER_PWRON_LO, pfdev->features.tiler_present);
-   ret |= readl_relaxed_poll_timeout(pfdev->iomem + TILER_READY_LO,
+   ret = readl_relaxed_poll_timeout(pfdev->iomem + TILER_READY_LO,
val, val == pfdev->features.tiler_present, 100, 1000);
-
if (ret)
-   dev_err(pfdev->dev, "error powering up gpu");
+   dev_err(pfdev->dev, "error powering up gpu tiler");
 }
 
 void panfrost_gpu_power_off(struct panfrost_device *pfdev)
-- 
2.24.1.735.g03f4e72817-goog

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


[PATCH v2 6/7, RFC] drm/panfrost: Add bifrost compatible string

2020-01-07 Thread Nicolas Boichat
For testing only, the driver doesn't really work yet, AFAICT.

Signed-off-by: Nicolas Boichat 
---
 drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 48e3c4165247cea..f3a4d77266ba961 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -591,6 +591,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t830" },
{ .compatible = "arm,mali-t860" },
{ .compatible = "arm,mali-t880" },
+   { .compatible = "arm,mali-bifrost" },
{}
 };
 MODULE_DEVICE_TABLE(of, dt_match);
-- 
2.24.1.735.g03f4e72817-goog

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


[PATCH v2 2/7] arm64: dts: mt8183: Add node for the Mali GPU

2020-01-07 Thread Nicolas Boichat
Add a basic GPU node for mt8183.

Signed-off-by: Nicolas Boichat 
---
Upstreaming what matches existing bindings from our Chromium OS tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348

The evb part of this change depends on this patch to add PMIC dtsi:
https://patchwork.kernel.org/patch/10928161/

The binding we use with out-of-tree Mali drivers includes more
clocks, this is used for devfreq: the out-of-tree driver switches
clk_mux to clk_sub_parent (26Mhz), adjusts clk_main_parent, then
switches clk_mux back to clk_main_parent:
(see 
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#423)
clocks =
< CLK_TOP_MFGPLL_CK>,
< CLK_TOP_MUX_MFG>,
<>,
< CLK_MFG_BG3D>;
clock-names =
"clk_main_parent",
"clk_mux",
"clk_sub_parent",
"subsys_mfg_cg";

v2:
 - Use sram instead of mali_sram as SRAM supply name.
 - Rename mali@ to gpu@.

 arch/arm64/boot/dts/mediatek/mt8183-evb.dts |   7 ++
 arch/arm64/boot/dts/mediatek/mt8183.dtsi| 104 
 2 files changed, 111 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 1fb195c683c3d01..7d609e0cd9b4975 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -7,6 +7,7 @@
 
 /dts-v1/;
 #include "mt8183.dtsi"
+#include "mt6358.dtsi"
 
 / {
model = "MediaTek MT8183 evaluation board";
@@ -30,6 +31,12 @@  {
status = "okay";
 };
 
+ {
+   supply-names = "mali", "sram";
+   mali-supply = <_vgpu_reg>;
+   sram-supply = <_vsram_gpu_reg>;
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 1ade9153e5c265b..4da3f1ed1c15bf3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -597,6 +597,110 @@ mfgcfg: syscon@1300 {
#clock-cells = <1>;
};
 
+   gpu: gpu@1304 {
+   compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
+   reg = <0 0x1304 0 0x4000>;
+   interrupts =
+   ,
+   ,
+   ;
+   interrupt-names = "job", "mmu", "gpu";
+
+   clocks = < CLK_TOP_MFGPLL_CK>;
+
+   power-domains =
+   < MT8183_POWER_DOMAIN_MFG_CORE0>,
+   < MT8183_POWER_DOMAIN_MFG_CORE1>,
+   < MT8183_POWER_DOMAIN_MFG_2D>;
+
+   operating-points-v2 = <_opp_table>;
+   };
+
+   gpu_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   opp-microvolt = <625000>, <85>;
+   };
+
+   opp-32000 {
+   opp-hz = /bits/ 64 <32000>;
+   opp-microvolt = <631250>, <85>;
+   };
+
+   opp-34000 {
+   opp-hz = /bits/ 64 <34000>;
+   opp-microvolt = <637500>, <85>;
+   };
+
+   opp-36000 {
+   opp-hz = /bits/ 64 <36000>;
+   opp-microvolt = <643750>, <85>;
+   };
+
+   opp-38000 {
+   opp-hz = /bits/ 64 <38000>;
+   opp-microvolt = <65>, <85>;
+   };
+
+   opp-4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <656250>, <85>;
+   };
+
+   opp-42000 {
+   opp-hz = /bits/ 64 <42000>;
+   opp-microvolt = <662500>, <85>;
+   };
+
+   opp-46000 {
+   opp-hz = /bits/ 64 <46000>;
+   opp-microvolt = <675000>, <85>;
+   };
+
+   opp-5 {
+   opp-hz = /bits/ 64 <5>;
+   opp-microvolt = <687500>, <85>;
+   };
+
+   opp-54000 {
+   

[PATCH v2 1/7] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

2020-01-07 Thread Nicolas Boichat
Define a compatible string for the Mali Bifrost GPU found in
Mediatek's MT8183 SoCs.

Signed-off-by: Nicolas Boichat 
---
 .../bindings/gpu/arm,mali-bifrost.yaml | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index 4ea6a8789699709..9e095608d2d98f0 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -17,6 +17,7 @@ properties:
 items:
   - enum:
   - amlogic,meson-g12a-mali
+  - mediatek,mt8183-mali
   - realtek,rtd1619-mali
   - rockchip,px30-mali
   - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully 
discoverable
@@ -62,6 +63,23 @@ allOf:
   minItems: 2
   required:
 - resets
+  - if:
+  properties:
+compatible:
+  contains:
+const: mediatek,mt8183-mali
+then:
+  properties:
+sram-supply: true
+power-domains:
+  description:
+List of phandle and PM domain specifier as documented in
+Documentation/devicetree/bindings/power/power_domain.txt
+  minItems: 3
+  maxItems: 3
+  required:
+- sram-supply
+- power-domains
 
 examples:
   - |
-- 
2.24.1.735.g03f4e72817-goog

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


[PATCH v2 7/7, RFC]: drm/panfrost: devfreq: Add support for 2 regulators

2020-01-07 Thread Nicolas Boichat
The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
devfreq, and provides OPP table with 2 sets of voltages.

TODO: This is incomplete as we'll need add support for setting
a pair of voltages as well.

Signed-off-by: Nicolas Boichat 
---
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 18 ++
 drivers/gpu/drm/panfrost/panfrost_device.h  |  2 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 413987038fbfccb..5eb0effded7eb09 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -79,6 +79,22 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
 
+   /* If we have 2 regulator, we need an OPP table with 2 voltages. */
+   if (pfdev->regulator_sram) {
+   const char * const reg_names[] = { "mali", "sram" };
+
+   pfdev->devfreq.dev_opp_table =
+   dev_pm_opp_set_regulators(dev,
+   reg_names, ARRAY_SIZE(reg_names));
+   if (IS_ERR(pfdev->devfreq.dev_opp_table)) {
+   ret = PTR_ERR(pfdev->devfreq.dev_opp_table);
+   pfdev->devfreq.dev_opp_table = NULL;
+   dev_err(dev,
+   "Failed to init devfreq opp table: %d\n", ret);
+   return ret;
+   }
+   }
+
ret = dev_pm_opp_of_add_table(dev);
if (ret == -ENODEV) /* Optional, continue without devfreq */
return 0;
@@ -119,6 +135,8 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
if (pfdev->devfreq.cooling)
devfreq_cooling_unregister(pfdev->devfreq.cooling);
dev_pm_opp_of_remove_table(>pdev->dev);
+   if (pfdev->devfreq.dev_opp_table)
+   dev_pm_opp_put_regulators(pfdev->devfreq.dev_opp_table);
 }
 
 void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h 
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 92d471676fc7823..581da3fe5df8b17 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -91,10 +91,12 @@ struct panfrost_device {
struct {
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+   struct opp_table *dev_opp_table;
ktime_t busy_time;
ktime_t idle_time;
ktime_t time_last_update;
atomic_t busy_count;
+   struct panfrost_devfreq_slot slot[NUM_JOB_SLOTS];
} devfreq;
 };
 
-- 
2.24.1.735.g03f4e72817-goog

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


Re: [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression

2020-01-07 Thread Thomas Zimmermann
Hi

Am 08.01.20 um 03:25 schrieb Rong Chen:
> Hi Thomas,
> 
> The previous throughput was reduced from 43955 to 35691, and there is a 
> little increase in next-20200106,
> but there is no obvious change after the patchset:

OK, I would have hoped for some improvements. Anyway, thanks for testing.

Best regards
Thomas

>  
> commit: 
>   f1f8555dfb ("drm/bochs: Use shadow buffer for bochs framebuffer console")
>   90f479ae51 ("drm/mgag200: Replace struct mga_fbdev with generic framebuffer 
> emulation")
> 
> f1f8555dfb9a70a2 90f479ae51afa45efab97afdde9 
>  --- 
>  %stddev %change %stddev
>  \  |\  
>  43955 ±  2% -18.8%  35691vm-scalability.median
> 
> commit: 
> 
>   9eb1b48ca4 ("Add linux-next specific files for 20200106")
>   5f20199bac ("drm/fb-helper: Synchronize dirty worker with vblank")
> 
>  next-20200106  5f20199bac9b2de71fd2158b90
>   --
>  %stddev  change %stddev
>  \  |\  
>  38550   38744   
>  38549   38744vm-scalability.median
> 
> 
> Best Regards,
> Rong Chen
> 
> On 1/6/20 9:19 PM, Thomas Zimmermann wrote:
>> Hi Feng,
>>
>> do you still have the test setup that produced the performance penalty?
>>
>> If so, could you give a try to the patchset at [1]? I think I've fixed
>> the remaining issues in earlier versions and I'd like to see if it
>> actually improves performance.
>>
>> Best regards
>> Thomas
>>
>> [1]
>> https://lists.freedesktop.org/archives/dri-devel/2019-December/247771.html
>>
>> Am 05.08.19 um 14:52 schrieb Feng Tang:
>>> Hi Thomas,
>>>
>>> On Mon, Aug 05, 2019 at 12:22:11PM +0200, Thomas Zimmermann wrote:
>>>
>>> [snip] 
>>>
>>   2019-08-03 19:29:17  ./case-anon-cow-seq-hugetlb
>>   2019-08-03 19:29:17  ./usemem --runtime 300 -n 4 --prealloc --prefault
>> -O -U 815394406
>>   917318700 bytes / 659419 usecs = 1358497 KB/s
>>   917318700 bytes / 659658 usecs = 1358005 KB/s
>>   917318700 bytes / 659916 usecs = 1357474 KB/s
>>   917318700 bytes / 660168 usecs = 1356956 KB/s
>>
>> Rong, Feng, could you confirm this by disabling the cursor or blinking?
> Glad to know this method restored the drop. Rong is running the case.
>
> While I have another finds, as I noticed your patch changed the bpp from
> 24 to 32, I had a patch to change it back to 24, and run the case in
> the weekend, the -18% regrssion was reduced to about -5%. Could this
> be related?
 In the original code, the fbdev console already ran with 32 bpp [1] and
 16 bpp was selected for low-end devices. [2][3] The patch only set the
 same values for userspace; nothing changed for the console.
>>> I did the experiment becasue I checked the commit 
>>>
>>> 90f479ae51afa4 drm/mgag200: Replace struct mga_fbdev with generic 
>>> framebuffer emulation
>>>
>>> in which there is code:
>>>
>>> diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
>>> b/drivers/gpu/drm/mgag200/mgag200_main.c
>>> index b10f726..a977333 100644
>>> --- a/drivers/gpu/drm/mgag200/mgag200_main.c
>>> +++ b/drivers/gpu/drm/mgag200/mgag200_main.c
>>> @@ -162,7 +162,7 @@ int mgag200_driver_load(struct drm_device *dev, 
>>> unsigned long flags)
>>> if (IS_G200_SE(mdev) && mdev->mc.vram_size < (2048*1024))
>>> dev->mode_config.preferred_depth = 16;
>>> else
>>> -   dev->mode_config.preferred_depth = 24;
>>> +   dev->mode_config.preferred_depth = 32;
>>> dev->mode_config.prefer_shadow = 1;
>>>  
>>> My debug patch was kind of restoring of this part.
>>>
>>> Thanks,
>>> Feng
>>>
 Best regards
 Thomas

 [1]
 https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n259
 [2]
 https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n263
 [3]
 https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n286

> commit: 
>   f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console
>   90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic 
> framebuffer emulation
>   01e75fea0d5 mgag200: restore the depth back to 24
>
> f1f8555dfb9a70a2 90f479ae51afa45efab97afdde9 01e75fea0d5ff39d3e588c20ec5 
>  --- --- 
>  43921 ±  2% -18.3%  35884-4.8%  41826
> vm-scalability.median
>   14889337   -17.5%   12291029-4.1%   14278574
> vm-scalability.throughput
>  
> commit 01e75fea0d5ff39d3e588c20ec52e7a4e6588a74
> Author: Feng Tang 
> Date:   

Re: [radeon-alex:amd-19.50 1794/2680] cc1: fatal error: dkms/config/config.h: No such file or directory

2020-01-07 Thread Wang, Kevin(Yang)
[AMD Official Use Only - Internal Distribution Only]

Hi,

the fixed patch has been merged into 19.50 branch yesterday.

commit 673383cfa8707eb024669f510837694081da65c5
Author: Flora Cui 
Date:   Thu Nov 28 15:20:06 2019 +0800

drm/amdkcl: fix intree build issue for config.h

fix "make O=$(output_dir) modules M=drivers/gpu/drm/amd/amdgpu"

Signed-off-by: Flora Cui 
Reviewed-by: Kevin Wang 

Best Regards,
Kevin


From: kbuild test robot 
Sent: Wednesday, January 8, 2020 4:56 AM
To: Cui, Flora 
Cc: kbuild-...@lists.01.org ; 
dri-devel@lists.freedesktop.org ; Gui, Jack 
; Xu, Feifei ; Wang, Kevin(Yang) 
; Zhang, Yifan1 
Subject: [radeon-alex:amd-19.50 1794/2680] cc1: fatal error: 
dkms/config/config.h: No such file or directory

Hi Flora,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head:   f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01 [1794/2680] 
drm/amdkcl/autoconf: generate config.h for in-tree build
config: x86_64-randconfig-h003-20200107 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01
# 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 >>):

>> cc1: fatal error: dkms/config/config.h: No such file or directory
   compilation terminated.

---
0-DAY kernel test infrastructure Open Source Technology Center
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org%2Fhyperkitty%2Flist%2Fkbuild-all%40lists.01.orgdata=02%7C01%7Ckevin1.wang%40amd.com%7C46d0b1e6805140d3728708d793b4188a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637140274251196664sdata=GrdbjBlNqVM%2BqpO%2FYypvMrQ6Q8zcuso%2BIyFOhT9BQ14%3Dreserved=0
 Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

2020-01-07 Thread Lin, Wayne
[AMD Public Use]



> -Original Message-
> From: Ville Syrjälä 
> Sent: Wednesday, January 8, 2020 2:57 AM
> To: Lin, Wayne 
> Cc: Jani Nikula ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Zuo, Jerry
> ; Kazlauskas, Nicholas
> 
> Subject: Re: [PATCH] drm/dp_mst: correct the shifting in
> DP_REMOTE_I2C_READ
> 
> On Tue, Dec 31, 2019 at 03:30:47AM +, Lin, Wayne wrote:
> > [AMD Official Use Only - Internal Distribution Only]
> >
> > > 
> > > From: Jani Nikula 
> > > Sent: Monday, December 30, 2019 19:15
> > > To: Lin, Wayne; dri-devel@lists.freedesktop.org;
> > > amd-...@lists.freedesktop.org
> > > Cc: Zuo, Jerry; Kazlauskas, Nicholas; Lin, Wayne
> > > Subject: Re: [PATCH] drm/dp_mst: correct the shifting in
> > > DP_REMOTE_I2C_READ
> > >
> > > On Mon, 30 Dec 2019, Wayne Lin  wrote:
> > > > [Why]
> > > > According to DP spec, it should shift left 4 digits for
> > > > NO_STOP_BIT in REMOTE_I2C_READ message. Not 5 digits.
> > > >
> > > > [How]
> > > > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ
> > > > case in drm_dp_encode_sideband_req().
> > >
> > > Which commit introduced the issue? Fixes: tag. Does it need a stable
> > > backport? Does this fix a user visible bug?
> > >
> > > BR,
> > > Jani.
> > >
> > Thanks for your time and reminder.
> >
> > It seems like the issue has been there since very beginning.(commit:
> ad7f8a1).
> > It doesn't introduce user visible bug under my test cases, but this
> > affects the I2C signal between I2C master and I2C slave. Not pretty
> > sure if there is any eeprom will reset the written offset once received I2C
> stop. If so, that might cause wrongly reading EDID.
> > I will Cc to stable. Thanks.
> 
> The segment address should be reset on STOP. So large EDIDs should fail.
> IIRC we had a bug report of some sort about this which I tried to fix by
> confgiuring .no_stop_bit correctly, but apparently I failed to double check
> that the bit get stuffed onto the wire correctly.
> 
> Ah yes,
> https://bugs.freedesktop.org/show_bug.cgi?id=108081
> So you may have just fixed that one, although we seem to have closed it
> already.

Thanks for your time and the explanation.
> 
> > > > Signed-off-by: Wayne Lin 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index 1d1bfa49ca2b..0557e225ff67 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct
> drm_dp_sideband_msg_req_body *req,
> > > >   memcpy([idx], 
> > > > req->u.i2c_read.transactions[i].bytes,
> req->u.i2c_read.transactions[i].num_bytes);
> > > >   idx +=
> > > > req->u.i2c_read.transactions[i].num_bytes;
> > > >
> > > > - buf[idx] = 
> > > > (req->u.i2c_read.transactions[i].no_stop_bit &
> 0x1) << 5;
> > > > + buf[idx] =
> > > > + (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
> > > >   buf[idx] |= (req-
> >u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
> > > >   idx++;
> > > >   }
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
> > --
> > Wayne Lin
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-
> develdata=02%7C01%7C
> >
> Wayne.Lin%40amd.com%7C7a299e0e845242312acb08d793a36e63%7C3dd896
> 1fe4884
> >
> e608e11a82d994e183d%7C0%7C0%7C637140202457938159sdata=yK4I
> 7fgenrR
> > f%2FXrs5jKXv%2BmOZdjV7dl%2BiNUJcsxnXG0%3Dreserved=0
> 
> --
> Ville Syrjälä
> Intel
--
Best regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: linux-next: manual merge of the drm tree with the drm-intel-fixes tree

2020-01-07 Thread Stephen Rothwell
Hi all,

On Wed, 8 Jan 2020 12:04:50 +1100 Stephen Rothwell  
wrote:
>
>  -hw_flags = 0;
>  +/* For resource streamer on HSW+ and power context elsewhere */
>  +BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_STATE_EN);
>  +BUILD_BUG_ON(HSW_MI_RS_RESTORE_STATE_EN != 
> MI_RESTORE_EXT_STATE_EN);
>  +
>  +flags = MI_SAVE_EXT_STATE_EN | MI_MM_SPACE_GTT;
> - if (!i915_gem_context_is_kernel(rq->gem_context))
> + if (!test_bit(CONTEXT_VALID_BIT, >flags))

I see from the drm-intel tree that this should have not have the '!'.
I have fixed up my resolution for tomorrow (and it has been fixed for
today's linux-next in the merge of the drm-intel tree.

-- 
Cheers,
Stephen Rothwell


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


Re: [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression

2020-01-07 Thread Rong Chen

Hi Thomas,

The previous throughput was reduced from 43955 to 35691, and there is a little 
increase in next-20200106,
but there is no obvious change after the patchset:
 
commit:

  f1f8555dfb ("drm/bochs: Use shadow buffer for bochs framebuffer console")
  90f479ae51 ("drm/mgag200: Replace struct mga_fbdev with generic framebuffer 
emulation")

f1f8555dfb9a70a2 90f479ae51afa45efab97afdde9
 ---
 %stddev %change %stddev
 \  |\
 43955 ±  2% -18.8%  35691vm-scalability.median

commit:

  9eb1b48ca4 ("Add linux-next specific files for 20200106")
  5f20199bac ("drm/fb-helper: Synchronize dirty worker with vblank")

 next-20200106  5f20199bac9b2de71fd2158b90
  --
 %stddev  change %stddev
 \  |\
 38550   38744
 38549   38744vm-scalability.median


Best Regards,
Rong Chen

On 1/6/20 9:19 PM, Thomas Zimmermann wrote:

Hi Feng,

do you still have the test setup that produced the performance penalty?

If so, could you give a try to the patchset at [1]? I think I've fixed
the remaining issues in earlier versions and I'd like to see if it
actually improves performance.

Best regards
Thomas

[1]
https://lists.freedesktop.org/archives/dri-devel/2019-December/247771.html

Am 05.08.19 um 14:52 schrieb Feng Tang:

Hi Thomas,

On Mon, Aug 05, 2019 at 12:22:11PM +0200, Thomas Zimmermann wrote:

[snip]


   2019-08-03 19:29:17  ./case-anon-cow-seq-hugetlb
   2019-08-03 19:29:17  ./usemem --runtime 300 -n 4 --prealloc --prefault
 -O -U 815394406
   917318700 bytes / 659419 usecs = 1358497 KB/s
   917318700 bytes / 659658 usecs = 1358005 KB/s
   917318700 bytes / 659916 usecs = 1357474 KB/s
   917318700 bytes / 660168 usecs = 1356956 KB/s

Rong, Feng, could you confirm this by disabling the cursor or blinking?

Glad to know this method restored the drop. Rong is running the case.

While I have another finds, as I noticed your patch changed the bpp from
24 to 32, I had a patch to change it back to 24, and run the case in
the weekend, the -18% regrssion was reduced to about -5%. Could this
be related?

In the original code, the fbdev console already ran with 32 bpp [1] and
16 bpp was selected for low-end devices. [2][3] The patch only set the
same values for userspace; nothing changed for the console.

I did the experiment becasue I checked the commit

90f479ae51afa4 drm/mgag200: Replace struct mga_fbdev with generic framebuffer 
emulation

in which there is code:

diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index b10f726..a977333 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -162,7 +162,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned 
long flags)
if (IS_G200_SE(mdev) && mdev->mc.vram_size < (2048*1024))
dev->mode_config.preferred_depth = 16;
else
-   dev->mode_config.preferred_depth = 24;
+   dev->mode_config.preferred_depth = 32;
dev->mode_config.prefer_shadow = 1;
  
My debug patch was kind of restoring of this part.


Thanks,
Feng


Best regards
Thomas

[1]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n259
[2]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n263
[3]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/mgag200/mgag200_fb.c?id=5d17718997367c435dbe5341a8e270d9b19478d3#n286


commit:
   f1f8555dfb9 drm/bochs: Use shadow buffer for bochs framebuffer console
   90f479ae51a drm/mgag200: Replace struct mga_fbdev with generic framebuffer 
emulation
   01e75fea0d5 mgag200: restore the depth back to 24

f1f8555dfb9a70a2 90f479ae51afa45efab97afdde9 01e75fea0d5ff39d3e588c20ec5
 --- ---
  43921 ±  2% -18.3%  35884-4.8%  41826
vm-scalability.median
   14889337   -17.5%   12291029-4.1%   14278574
vm-scalability.throughput
  
commit 01e75fea0d5ff39d3e588c20ec52e7a4e6588a74

Author: Feng Tang 
Date:   Fri Aug 2 15:09:19 2019 +0800

 mgag200: restore the depth back to 24
 
 Signed-off-by: Feng Tang 


diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index a977333..ac8f6c9 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -162,7 +162,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned 
long flags)
if (IS_G200_SE(mdev) && mdev->mc.vram_size < (2048*1024))
dev->mode_config.preferred_depth = 16;
else
-   

[PATCH 1/3] drm/msm: support firmware-name for zap fw

2020-01-07 Thread Rob Clark
From: Rob Clark 

Since zap firmware can be device specific, allow for a firmware-name
property in the zap node to specify which firmware to load, similarly to
the scheme used for dsp/wifi/etc.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 32 ++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 112e8b8a261e..aa8737bd58db 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -26,6 +26,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
char *fwname,
 {
struct device *dev = >pdev->dev;
const struct firmware *fw;
+   const char *signed_fwname = NULL;
struct device_node *np, *mem_np;
struct resource r;
phys_addr_t mem_phys;
@@ -58,8 +59,33 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
char *fwname,
 
mem_phys = r.start;
 
-   /* Request the MDT file for the firmware */
-   fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
+   /*
+* Check for a firmware-name property.  This is the new scheme
+* to handle firmware that may be signed with device specific
+* keys, allowing us to have a different zap fw path for different
+* devices.
+*
+* If the firmware-name property is found, we bypass the
+* adreno_request_fw() mechanism, because we don't need to handle
+* the /lib/firmware/qcom/* vs /lib/firmware/* case.
+*
+* If the firmware-name property is not found, for backwards
+* compatibility we fall back to the fwname from the gpulist
+* table.
+*/
+   of_property_read_string_index(np, "firmware-name", 0, _fwname);
+   if (signed_fwname) {
+   fwname = signed_fwname;
+   ret = request_firmware_direct(, signed_fwname, 
gpu->dev->dev);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "could not load signed zap firmware: 
%d\n", ret);
+   fw = ERR_PTR(ret);
+   }
+   } else {
+   /* Request the MDT file for the firmware */
+   fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
+   }
+
if (IS_ERR(fw)) {
DRM_DEV_ERROR(dev, "Unable to load %s\n", fwname);
return PTR_ERR(fw);
@@ -95,7 +121,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
char *fwname,
 * not.  But since we've already gotten through adreno_request_fw()
 * we know which of the two cases it is:
 */
-   if (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY) {
+   if (signed_fwname || (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY)) 
{
ret = qcom_mdt_load(dev, fw, fwname, pasid,
mem_region, mem_phys, mem_size, NULL);
} else {
-- 
2.24.1

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


[PATCH 0/3] drm/msm: use firmware-name to find zap fw

2020-01-07 Thread Rob Clark
From: Rob Clark 

For devices which use zap fw to take the GPU out of secure mode on
reset, the firmware is likely to be signed with a device specific key.
Meaning that we can't have a single filesystem (or /lib/firmware) that
works on multiple devices.

So allow a firmware-name to be specified in the zap-shader node in dt.
This moves the zap-shader node out of the core sdm845.dtsi and into per-
device dts files.  Which also removes the need for /delete-node/ in
sdm845-cheza.dtsi (as cheza devices do not use zap).

This aligns with how Bjorn has been handling the similar situation with
adsp/cdsp/mpss fw:

   https://patchwork.kernel.org/patch/11160089/

Rob Clark (3):
  drm/msm: support firmware-name for zap fw
  dt-bindings: drm/msm/gpu: Document firmware-name
  arm64: dts: sdm845: move gpu zap nodes to per-device dts

 .../devicetree/bindings/display/msm/gpu.txt   |  3 ++
 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi|  1 -
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts|  7 
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts   |  8 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi  |  6 +---
 .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts |  7 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   | 32 +--
 7 files changed, 55 insertions(+), 9 deletions(-)

-- 
2.24.1

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


[PATCH 3/3] arm64: dts: sdm845: move gpu zap nodes to per-device dts

2020-01-07 Thread Rob Clark
From: Rob Clark 

We want to specify per-device firmware-name, so move the zap node into
the .dts file for individual boards/devices.  This lets us get rid of
the /delete-node/ for cheza, which does not use zap.

Signed-off-by: Rob Clark 
---
 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi   | 1 -
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts   | 7 +++
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts  | 8 
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 +-
 arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 7 +++
 5 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 9a4ff57fc877..2db79c1ecdac 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -165,7 +165,6 @@ panel_in_edp: endpoint {
 /delete-node/ _mem;
 /delete-node/ _mem;
 /delete-node/ _pas;
-/delete-node/ _shader;
 /delete-node/ _mem;
 
 /* Increase the size from 120 MB to 128 MB */
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts 
b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
index d100f46791a6..c472195e44fb 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
@@ -352,6 +352,13 @@  {
   ;
 };
 
+ {
+   zap-shader {
+   memory-region = <_mem>;
+   firmware-name = "qcom/db845c/a630_zap.mbn";
+   };
+};
+
 _gpio {
vol_up_pin_a: vol-up-active {
pins = "gpio6";
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index c57548b7b250..876155fc0547 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -360,6 +360,14 @@  {
   ;
 };
 
+ {
+   zap-shader {
+   memory-region = <_mem>;
+   // TODO presumably mtp can use same "test key" signed zap?
+   firmware-name = "qcom/db845c/a630_zap.mbn";
+   };
+};
+
  {
status = "okay";
clock-frequency = <40>;
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index ddb1f23c936f..601c57cc9b6d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2804,7 +2804,7 @@ dsi1_phy: dsi-phy@ae96400 {
};
};
 
-   gpu@500 {
+   gpu: gpu@500 {
compatible = "qcom,adreno-630.2", "qcom,adreno";
#stream-id-cells = <16>;
 
@@ -2824,10 +2824,6 @@ gpu@500 {
 
qcom,gmu = <>;
 
-   zap_shader: zap-shader {
-   memory-region = <_mem>;
-   };
-
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
 
diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts 
b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
index 13dc619687f3..b255be3a4a0a 100644
--- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
@@ -245,6 +245,13 @@  {
   ;
 };
 
+ {
+   zap-shader {
+   memory-region = <_mem>;
+   firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn";
+   };
+};
+
  {
status = "okay";
clock-frequency = <40>;
-- 
2.24.1

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


[PATCH 2/3] dt-bindings: drm/msm/gpu: Document firmware-name

2020-01-07 Thread Rob Clark
From: Rob Clark 

The firmware-name property in the zap node can be used to specify a
device specific zap firmware.

Signed-off-by: Rob Clark 
---
 Documentation/devicetree/bindings/display/msm/gpu.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 3e6cd3f64a78..7edc298a15f2 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -33,6 +33,8 @@ Required properties:
 - zap-shader: For a5xx and a6xx devices this node contains a memory-region that
   points to reserved memory to store the zap shader that can be used to help
   bring the GPU out of secure mode.
+- firmware-name: optional property of the 'zap-shader' node, listing the
+  relative path of the device specific zap firmware.
 
 Example 3xx/4xx/a5xx:
 
@@ -85,6 +87,7 @@ Example a6xx (with GMU):
 
zap-shader {
memory-region = <_shader_region>;
+   firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn"
};
};
 };
-- 
2.24.1

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


linux-next: manual merge of the drm tree with the drm-intel-fixes tree

2020-01-07 Thread Stephen Rothwell
Hi all,

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

  drivers/gpu/drm/i915/display/intel_display.c

between commit:

  2b2c4a83d69d ("drm/i915/dp: Disable Port sync mode correctly on teardown")

from the drm-intel-fixes tree and commit:

  773b4b54351c ("drm/i915: Move stuff from haswell_crtc_disable() into encoder 
.post_disable()")

from the drm tree.

I fixed it up (I applied the change to icl_disable_transcoder_port_sync()
from the former commit in its new location - see 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.

From: Stephen Rothwell 
Date: Wed, 8 Jan 2020 12:12:45 +1100
Subject: [PATCH] drm/i915: fixup for "drm/i915/dp: Disable Port sync mode
 correctly on teardown"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c9ba7d7f3787..e535a3b85575 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3860,8 +3860,6 @@ static void icl_disable_transcoder_port_sync(const struct 
intel_crtc_state *old_
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   i915_reg_t reg;
-   u32 trans_ddi_func_ctl2_val;
 
if (old_crtc_state->master_transcoder == INVALID_TRANSCODER)
return;
@@ -3869,10 +3867,7 @@ static void icl_disable_transcoder_port_sync(const 
struct intel_crtc_state *old_
DRM_DEBUG_KMS("Disabling Transcoder Port Sync on Slave Transcoder %s\n",
  transcoder_name(old_crtc_state->cpu_transcoder));
 
-   reg = TRANS_DDI_FUNC_CTL2(old_crtc_state->cpu_transcoder);
-   trans_ddi_func_ctl2_val = ~(PORT_SYNC_MODE_ENABLE |
-   PORT_SYNC_MODE_MASTER_SELECT_MASK);
-   I915_WRITE(reg, trans_ddi_func_ctl2_val);
+   I915_WRITE(TRANS_DDI_FUNC_CTL2(old_crtc_state->cpu_transcoder), 0);
 }
 
 static void intel_ddi_post_disable(struct intel_encoder *encoder,
-- 
2.24.0

-- 
Cheers,
Stephen Rothwell


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


linux-next: manual merge of the drm tree with the drm-intel-fixes tree

2020-01-07 Thread Stephen Rothwell
Hi all,

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

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  ce69e553b9a4 ("drm/i915/gt: Restore coarse power gating")

from the drm-intel-fixes tree and commit:

  90eb7d2aa3ce ("drm/i915: Simplify NEEDS_WaRsDisableCoarsePowerGating")

from the drm tree.

I fixed it up (I have no idea about this, so I just used the latter
version) 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


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


linux-next: manual merge of the drm tree with the drm-intel-fixes tree

2020-01-07 Thread Stephen Rothwell
Hi all,

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

  drivers/gpu/drm/i915/gt/intel_ring_submission.c

between commit:

  103309977589 ("drm/i915/gt: Do not restore invalid RS state")

from the drm-intel-fixes tree and commit:

  3cd6e8860ecd ("drm/i915/gen7: Re-enable full-ppgtt for ivb & hsw")
  f997056d5b17 ("drm/i915/gt: Push the flush_pd before the set-context")
  f70de8d2ca6b ("drm/i915/gt: Track the context validity explicitly")
  902eb748e5c3 ("drm/i915/gt: Tidy up full-ppgtt on Ivybridge")

from the drm 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/i915/gt/intel_ring_submission.c
index 93026217c121,81f872f9ef03..
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@@ -1574,28 -1602,20 +1594,26 @@@ static int switch_context(struct i915_r
  
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
  
-   if (vm) {
-   ret = load_pd_dir(rq, i915_vm_to_ppgtt(vm));
-   if (ret)
-   return ret;
-   }
+   ret = switch_mm(rq, vm_alias(ce));
+   if (ret)
+   return ret;
  
if (ce->state) {
 -  u32 hw_flags;
 +  u32 flags;
  
GEM_BUG_ON(rq->engine->id != RCS0);
  
 -  hw_flags = 0;
 +  /* For resource streamer on HSW+ and power context elsewhere */
 +  BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_STATE_EN);
 +  BUILD_BUG_ON(HSW_MI_RS_RESTORE_STATE_EN != 
MI_RESTORE_EXT_STATE_EN);
 +
 +  flags = MI_SAVE_EXT_STATE_EN | MI_MM_SPACE_GTT;
-   if (!i915_gem_context_is_kernel(rq->gem_context))
+   if (!test_bit(CONTEXT_VALID_BIT, >flags))
 -  hw_flags = MI_RESTORE_INHIBIT;
 +  flags |= MI_RESTORE_EXT_STATE_EN;
 +  else
 +  flags |= MI_RESTORE_INHIBIT;
  
 -  ret = mi_set_context(rq, hw_flags);
 +  ret = mi_set_context(rq, flags);
if (ret)
return ret;
}


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


[PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

2020-01-07 Thread Manasi Navare
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_freesync_caps() to make it generic and be used
across all DRM drivers

v2:
* Change vmin and vmax to use u8 (Ville)
* Dont store pixel clock since that is just a max dotclock
and not related to VRR mode (Manasi)

Cc: Ville Syrjälä 
Cc: Harry Wentland 
Cc: Clinton A Taylor 
Cc: Nicholas Kazlauskas 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_edid.c  | 51 +
 include/drm/drm_connector.h | 22 
 include/drm/drm_edid.h  |  2 ++
 3 files changed, 75 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 99769d6c9f84..52781a0e708b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
}
 }
 
+void drm_get_adaptive_sync_limits(struct drm_connector *connector,
+ const struct edid *edid)
+{
+   struct drm_display_info *info = >display_info;
+   const struct detailed_timing *timing;
+   const struct detailed_non_pixel *data;
+   const struct detailed_data_monitor_range *range;
+   int i;
+
+   /*
+* Restrict Adaptive Sync only for dp and edp
+*/
+   if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
+   connector->connector_type != DRM_MODE_CONNECTOR_eDP)
+   return;
+
+   if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
+   return;
+
+   for (i = 0; i < 4; i++) {
+   timing  = >detailed_timings[i];
+   data= >data.other_data;
+   range   = >data.range;
+   /*
+* Check if monitor has continuous frequency mode
+*/
+   if (data->type != EDID_DETAIL_MONITOR_RANGE)
+   continue;
+   /*
+* Check for flag range limits only. If flag == 1 then
+* no additional timing information provided.
+* Default GTF, GTF Secondary curve and CVT are not
+* supported
+*/
+   if (range->flags != 1)
+   continue;
+
+   info->adaptive_sync.min_vfreq = range->min_vfreq;
+   info->adaptive_sync.max_vfreq = range->max_vfreq;
+
+   DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d 
Hz\n",
+ info->adaptive_sync.min_vfreq,
+ info->adaptive_sync.max_vfreq);
+   break;
+   }
+}
+EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
+
 /* A connector has no EDID information, so we've got no EDID to compute quirks 
from. Reset
  * all of the values which would have been set from EDID
  */
@@ -4901,6 +4949,7 @@ drm_reset_display_info(struct drm_connector *connector)
memset(>hdmi, 0, sizeof(info->hdmi));
 
info->non_desktop = 0;
+   memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
 }
 
 u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
*edid)
@@ -4916,6 +4965,8 @@ u32 drm_add_display_info(struct drm_connector *connector, 
const struct edid *edi
 
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
 
+   drm_get_adaptive_sync_limits(connector, edid);
+
DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
 
if (edid->revision < 3)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 221910948b37..77df404a2e01 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -254,6 +254,23 @@ enum drm_panel_orientation {
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
 };
 
+/**
+ * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
+ * _display_info
+ *
+ * This struct is used to store a Panel's Adaptive Sync capabilities
+ * as parsed from EDID's detailed monitor range descriptor block.
+ *
+ * @min_vfreq: This is the min supported refresh rate in Hz from
+ * EDID's detailed monitor range.
+ * @max_vfreq: This is the max supported refresh rate in Hz from
+ * EDID's detailed monitor range
+ */
+struct drm_adaptive_sync_info {
+   u8 min_vfreq;
+   u8 max_vfreq;
+};
+
 /*
  * This is a consolidated colorimetry list supported by HDMI and
  * DP protocol standard. The respective connectors will register
@@ -465,6 +482,11 @@ struct drm_display_info {
 * @non_desktop: Non desktop display (HMD).
 */
bool non_desktop;
+
+   /**
+* @adaptive_sync: Adaptive Sync capabilities of the DP/eDP sink
+*/
+   struct drm_adaptive_sync_info 

[radeon-alex:amd-19.50 1962/2680] include/kcl/kcl_drm.h:191:9: error: too few arguments to function 'drm_encoder_init'

2020-01-07 Thread kbuild test robot
Hi Yifan,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head:   f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff [1962/2680] drm/amdkcl: Test 
whether drm_encoder_init() wants name
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff
# save the attached .config to linux build tree
make ARCH=i386 

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

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
   include/kcl/kcl_drm.h:98:1: error: conflicting types for 
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
   In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
   include/drm/drm_fb_helper.h:589:1: note: previous definition of 
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
   In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
   include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
>> include/kcl/kcl_drm.h:191:9: error: too few arguments to function 
>> 'drm_encoder_init'
 return drm_encoder_init(dev, encoder, funcs,
^~~~
   In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
   include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~

vim +/drm_encoder_init +191 include/kcl/kcl_drm.h

5027d12c82b867 changzhu 2019-04-03  181  
950c9c93299ece Junwei Zhang 2016-12-23  182  static inline int 
kcl_drm_encoder_init(struct drm_device *dev,
950c9c93299ece Junwei Zhang 2016-12-23  183   struct 
drm_encoder *encoder,
950c9c93299ece Junwei Zhang 2016-12-23  184   const struct 
drm_encoder_funcs *funcs,
950c9c93299ece Junwei Zhang 2016-12-23  185   int encoder_type, 
const char *name, ...)
950c9c93299ece Junwei Zhang 2016-12-23  186  {
35781c0b8d19ed Yifan Zhang  2019-07-15  187  #if 
defined(HAVE_DRM_ENCODER_INIT_VALID_WITH_NAME)
950c9c93299ece Junwei Zhang 2016-12-23  188 return drm_encoder_init(dev, 
encoder, funcs,
950c9c93299ece Junwei Zhang 2016-12-23  189  encoder_type, 
name);
950c9c93299ece Junwei Zhang 2016-12-23  190  #else
950c9c93299ece Junwei Zhang 2016-12-23 @191 return drm_encoder_init(dev, 
encoder, funcs,
950c9c93299ece Junwei Zhang 2016-12-23  192  encoder_type);
950c9c93299ece Junwei Zhang 2016-12-23  193  #endif
950c9c93299ece Junwei Zhang 2016-12-23  194  }
950c9c93299ece Junwei Zhang 2016-12-23  195  

:: The code at line 191 was first introduced by commit
:: 950c9c93299eceb8cca4b12eb09a04a48d383ec6 drm/amdkcl: [4.5] fix drm 
encoder and plane functions

:: TO: Junwei Zhang 
:: CC: Chengming Gui 

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


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


[PATCH v12 06/22] mm: fix get_user_pages_remote()'s handling of FOLL_LONGTERM

2020-01-07 Thread John Hubbard
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.

However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
FOLL_LONGTERM callers, but we can actually allow FOLL_LONGTERM callers
that do not set the "locked" arg.

Update the code and comments to loosen the restriction, allowing
FOLL_LONGTERM in some cases.

Also, copy the DAX check ("if a VMA is DAX, don't allow long term
pinning") from the VFIO call site, all the way into the internals
of get_user_pages_remote() and __gup_longterm_locked(). That is:
get_user_pages_remote() calls __gup_longterm_locked(), which in turn
calls check_dax_vmas(). This check will then be removed from the VFIO
call site in a subsequent patch.

Thanks to Jason Gunthorpe for pointing out a clean way to fix this,
and to Dan Williams for helping clarify the DAX refactoring.

Tested-by: Alex Williamson 
Acked-by: Alex Williamson 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Ira Weiny 
Suggested-by: Jason Gunthorpe 
Cc: Kirill A. Shutemov 
Cc: Dan Williams 
Cc: Jerome Glisse 
Signed-off-by: John Hubbard 
---
 mm/gup.c | 174 +--
 1 file changed, 92 insertions(+), 82 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 5938e29a5a8b..b61bd5c469ae 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -,88 +,6 @@ static __always_inline long 
__get_user_pages_locked(struct task_struct *tsk,
return pages_done;
 }
 
-/*
- * get_user_pages_remote() - pin user pages in memory
- * @tsk:   the task_struct to use for page fault accounting, or
- * NULL if faults are not to be recorded.
- * @mm:mm_struct of target mm
- * @start: starting user address
- * @nr_pages:  number of pages from start to pin
- * @gup_flags: flags modifying lookup behaviour
- * @pages: array that receives pointers to the pages pinned.
- * Should be at least nr_pages long. Or NULL, if caller
- * only intends to ensure the pages are faulted in.
- * @vmas:  array of pointers to vmas corresponding to each page.
- * Or NULL if the caller does not require them.
- * @locked:pointer to lock flag indicating whether lock is held and
- * subsequently whether VM_FAULT_RETRY functionality can be
- * utilised. Lock must initially be held.
- *
- * Returns either number of pages pinned (which may be less than the
- * number requested), or an error. Details about the return value:
- *
- * -- If nr_pages is 0, returns 0.
- * -- If nr_pages is >0, but no pages were pinned, returns -errno.
- * -- If nr_pages is >0, and some pages were pinned, returns the number of
- *pages pinned. Again, this may be less than nr_pages.
- *
- * The caller is responsible for releasing returned @pages, via put_page().
- *
- * @vmas are valid only as long as mmap_sem is held.
- *
- * Must be called with mmap_sem held for read or write.
- *
- * get_user_pages walks a process's page tables and takes a reference to
- * each struct page that each user address corresponds to at a given
- * instant. That is, it takes the page that would be accessed if a user
- * thread accesses the given user virtual address at that instant.
- *
- * This does not guarantee that the page exists in the user mappings when
- * get_user_pages returns, and there may even be a completely different
- * page there in some cases (eg. if mmapped pagecache has been invalidated
- * and subsequently re faulted). However it does guarantee that the page
- * won't be freed completely. And mostly callers simply care that the page
- * contains data that was valid *at some point in time*. Typically, an IO
- * or similar operation cannot guarantee anything stronger anyway because
- * locks can't be held over the syscall boundary.
- *
- * If gup_flags & FOLL_WRITE == 0, the page must not be written to. If the page
- * is written to, set_page_dirty (or set_page_dirty_lock, as appropriate) must
- * be called after the page is finished with, and before put_page is called.
- *
- * get_user_pages is typically used for fewer-copy IO operations, to get a
- * handle on the memory by some means other than accesses via the user virtual
- * addresses. The pages may be submitted for DMA to devices or accessed via
- * their kernel linear mapping (via the kmap APIs). Care should be taken to
- * use the correct cache flushing APIs.
- *
- * See also get_user_pages_fast, for performance critical applications.
- *
- * get_user_pages should be phased out in favor of
- * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
- * should use get_user_pages because it cannot pass
- * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.
- */
-long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
-   unsigned long start, unsigned long nr_pages,
-

[PATCH v12 14/22] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()

2020-01-07 Thread John Hubbard
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.

Also, release the pages via put_user_page*().

Also, rename "pages" to "pinned_pages", as this makes for
easier reading of process_vm_rw_single_vec().

Reviewed-by: Jan Kara 
Reviewed-by: Jérôme Glisse 
Reviewed-by: Ira Weiny 
Signed-off-by: John Hubbard 
---
 mm/process_vm_access.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
index 357aa7bef6c0..fd20ab675b85 100644
--- a/mm/process_vm_access.c
+++ b/mm/process_vm_access.c
@@ -42,12 +42,11 @@ static int process_vm_rw_pages(struct page **pages,
if (copy > len)
copy = len;
 
-   if (vm_write) {
+   if (vm_write)
copied = copy_page_from_iter(page, offset, copy, iter);
-   set_page_dirty_lock(page);
-   } else {
+   else
copied = copy_page_to_iter(page, offset, copy, iter);
-   }
+
len -= copied;
if (copied < copy && iov_iter_count(iter))
return -EFAULT;
@@ -96,7 +95,7 @@ static int process_vm_rw_single_vec(unsigned long addr,
flags |= FOLL_WRITE;
 
while (!rc && nr_pages && iov_iter_count(iter)) {
-   int pages = min(nr_pages, max_pages_per_loop);
+   int pinned_pages = min(nr_pages, max_pages_per_loop);
int locked = 1;
size_t bytes;
 
@@ -106,14 +105,15 @@ static int process_vm_rw_single_vec(unsigned long addr,
 * current/current->mm
 */
down_read(>mmap_sem);
-   pages = get_user_pages_remote(task, mm, pa, pages, flags,
- process_pages, NULL, );
+   pinned_pages = pin_user_pages_remote(task, mm, pa, pinned_pages,
+flags, process_pages,
+NULL, );
if (locked)
up_read(>mmap_sem);
-   if (pages <= 0)
+   if (pinned_pages <= 0)
return -EFAULT;
 
-   bytes = pages * PAGE_SIZE - start_offset;
+   bytes = pinned_pages * PAGE_SIZE - start_offset;
if (bytes > len)
bytes = len;
 
@@ -122,10 +122,12 @@ static int process_vm_rw_single_vec(unsigned long addr,
 vm_write);
len -= bytes;
start_offset = 0;
-   nr_pages -= pages;
-   pa += pages * PAGE_SIZE;
-   while (pages)
-   put_page(process_pages[--pages]);
+   nr_pages -= pinned_pages;
+   pa += pinned_pages * PAGE_SIZE;
+
+   /* If vm_write is set, the pages need to be made dirty: */
+   put_user_pages_dirty_lock(process_pages, pinned_pages,
+ vm_write);
}
 
return rc;
-- 
2.24.1

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


[PATCH v12 19/22] vfio, mm: pin_user_pages (FOLL_PIN) and put_user_page() conversion

2020-01-07 Thread John Hubbard
1. Change vfio from get_user_pages_remote(), to
pin_user_pages_remote().

2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().

Note that this effectively changes the code's behavior in
vfio_iommu_type1.c: put_pfn(): it now ultimately calls
set_page_dirty_lock(), instead of set_page_dirty(). This is
probably more accurate.

As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]

[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de

Tested-by: Alex Williamson 
Acked-by: Alex Williamson 
Signed-off-by: John Hubbard 
---
 drivers/vfio/vfio_iommu_type1.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index b800fc9a0251..18bfc2fc8e6d 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -309,9 +309,8 @@ static int put_pfn(unsigned long pfn, int prot)
 {
if (!is_invalid_reserved_pfn(pfn)) {
struct page *page = pfn_to_page(pfn);
-   if (prot & IOMMU_WRITE)
-   SetPageDirty(page);
-   put_page(page);
+
+   put_user_pages_dirty_lock(, 1, prot & IOMMU_WRITE);
return 1;
}
return 0;
@@ -329,7 +328,7 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
long vaddr,
flags |= FOLL_WRITE;
 
down_read(>mmap_sem);
-   ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
+   ret = pin_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
page, NULL, NULL);
if (ret == 1) {
*pfn = page_to_pfn(page[0]);
-- 
2.24.1

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


[PATCH v12 16/22] fs/io_uring: set FOLL_PIN via pin_user_pages()

2020-01-07 Thread John Hubbard
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().

In partial anticipation of this work, the io_uring code was already
calling put_user_page() instead of put_page(). Therefore, in order to
convert from the get_user_pages()/put_page() model, to the
pin_user_pages()/put_user_page() model, the only change required
here is to change get_user_pages() to pin_user_pages().

Reviewed-by: Jens Axboe 
Reviewed-by: Jan Kara 
Signed-off-by: John Hubbard 
---
 fs/io_uring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 562e3a1a1bf9..9f804cb25c61 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -4815,7 +4815,7 @@ static int io_sqe_buffer_register(struct io_ring_ctx 
*ctx, void __user *arg,
 
ret = 0;
down_read(>mm->mmap_sem);
-   pret = get_user_pages(ubuf, nr_pages,
+   pret = pin_user_pages(ubuf, nr_pages,
  FOLL_WRITE | FOLL_LONGTERM,
  pages, vmas);
if (pret == nr_pages) {
-- 
2.24.1

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


[PATCH v12 17/22] net/xdp: set FOLL_PIN via pin_user_pages()

2020-01-07 Thread John Hubbard
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.

In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
convert from the get_user_pages()/put_page() model, to the
pin_user_pages()/put_user_page() model, the only change required
here is to change get_user_pages() to pin_user_pages().

Acked-by: Björn Töpel 
Signed-off-by: John Hubbard 
---
 net/xdp/xdp_umem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 3049af269fbf..d071003b5e76 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -291,7 +291,7 @@ static int xdp_umem_pin_pages(struct xdp_umem *umem)
return -ENOMEM;
 
down_read(>mm->mmap_sem);
-   npgs = get_user_pages(umem->address, umem->npgs,
+   npgs = pin_user_pages(umem->address, umem->npgs,
  gup_flags | FOLL_LONGTERM, >pgs[0], NULL);
up_read(>mm->mmap_sem);
 
-- 
2.24.1

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


[PATCH v12 12/22] goldish_pipe: convert to pin_user_pages() and put_user_page()

2020-01-07 Thread John Hubbard
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().

2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().

That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is probably more accurate.

As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]

Another side effect is that the release code is simplified because
the page[] loop is now in gup.c instead of here, so just delete the
local release_user_pages() entirely, and call
put_user_pages_dirty_lock() directly, instead.

[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de

Reviewed-by: Jan Kara 
Reviewed-by: Ira Weiny 
Signed-off-by: John Hubbard 
---
 drivers/platform/goldfish/goldfish_pipe.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
b/drivers/platform/goldfish/goldfish_pipe.c
index ef50c264db71..2a5901efecde 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -274,7 +274,7 @@ static int goldfish_pin_pages(unsigned long first_page,
*iter_last_page_size = last_page_size;
}
 
-   ret = get_user_pages_fast(first_page, requested_pages,
+   ret = pin_user_pages_fast(first_page, requested_pages,
  !is_write ? FOLL_WRITE : 0,
  pages);
if (ret <= 0)
@@ -285,18 +285,6 @@ static int goldfish_pin_pages(unsigned long first_page,
return ret;
 }
 
-static void release_user_pages(struct page **pages, int pages_count,
-  int is_write, s32 consumed_size)
-{
-   int i;
-
-   for (i = 0; i < pages_count; i++) {
-   if (!is_write && consumed_size > 0)
-   set_page_dirty(pages[i]);
-   put_page(pages[i]);
-   }
-}
-
 /* Populate the call parameters, merging adjacent pages together */
 static void populate_rw_params(struct page **pages,
   int pages_count,
@@ -372,7 +360,8 @@ static int transfer_max_buffers(struct goldfish_pipe *pipe,
 
*consumed_size = pipe->command_buffer->rw_params.consumed_size;
 
-   release_user_pages(pipe->pages, pages_count, is_write, *consumed_size);
+   put_user_pages_dirty_lock(pipe->pages, pages_count,
+ !is_write && *consumed_size > 0);
 
mutex_unlock(>lock);
return 0;
-- 
2.24.1

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


[PATCH v12 22/22] mm, tree-wide: rename put_user_page*() to unpin_user_page*()

2020-01-07 Thread John Hubbard
In order to provide a clearer, more symmetric API for pinning
and unpinning DMA pages. This way, pin_user_pages*() calls
match up with unpin_user_pages*() calls, and the API is a lot
closer to being self-explanatory.

Reviewed-by: Jan Kara 
Signed-off-by: John Hubbard 
---
 Documentation/core-api/pin_user_pages.rst   |  2 +-
 arch/powerpc/mm/book3s64/iommu_api.c|  4 +--
 drivers/gpu/drm/via/via_dmablit.c   |  4 +--
 drivers/infiniband/core/umem.c  |  2 +-
 drivers/infiniband/hw/hfi1/user_pages.c |  2 +-
 drivers/infiniband/hw/mthca/mthca_memfree.c |  6 ++--
 drivers/infiniband/hw/qib/qib_user_pages.c  |  2 +-
 drivers/infiniband/hw/qib/qib_user_sdma.c   |  6 ++--
 drivers/infiniband/hw/usnic/usnic_uiom.c|  2 +-
 drivers/infiniband/sw/siw/siw_mem.c |  2 +-
 drivers/media/v4l2-core/videobuf-dma-sg.c   |  4 +--
 drivers/platform/goldfish/goldfish_pipe.c   |  4 +--
 drivers/vfio/vfio_iommu_type1.c |  2 +-
 fs/io_uring.c   |  4 +--
 include/linux/mm.h  | 26 -
 mm/gup.c| 32 ++---
 mm/process_vm_access.c  |  4 +--
 net/xdp/xdp_umem.c  |  2 +-
 18 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/Documentation/core-api/pin_user_pages.rst 
b/Documentation/core-api/pin_user_pages.rst
index 71849830cd48..1d490155ecd7 100644
--- a/Documentation/core-api/pin_user_pages.rst
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -219,7 +219,7 @@ since the system was booted, via two new /proc/vmstat 
entries: ::
 /proc/vmstat/nr_foll_pin_requested
 
 Those are both going to show zero, unless CONFIG_DEBUG_VM is set. This is
-because there is a noticeable performance drop in put_user_page(), when they
+because there is a noticeable performance drop in unpin_user_page(), when they
 are activated.
 
 References
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c 
b/arch/powerpc/mm/book3s64/iommu_api.c
index a86547822034..eba73ebd8ae5 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -168,7 +168,7 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
unsigned long ua,
 
 free_exit:
/* free the references taken */
-   put_user_pages(mem->hpages, pinned);
+   unpin_user_pages(mem->hpages, pinned);
 
vfree(mem->hpas);
kfree(mem);
@@ -214,7 +214,7 @@ static void mm_iommu_unpin(struct 
mm_iommu_table_group_mem_t *mem)
if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
SetPageDirty(page);
 
-   put_user_page(page);
+   unpin_user_page(page);
 
mem->hpas[i] = 0;
}
diff --git a/drivers/gpu/drm/via/via_dmablit.c 
b/drivers/gpu/drm/via/via_dmablit.c
index 37c5e572993a..719d036c9384 100644
--- a/drivers/gpu/drm/via/via_dmablit.c
+++ b/drivers/gpu/drm/via/via_dmablit.c
@@ -188,8 +188,8 @@ via_free_sg_info(struct pci_dev *pdev, drm_via_sg_info_t 
*vsg)
kfree(vsg->desc_pages);
/* fall through */
case dr_via_pages_locked:
-   put_user_pages_dirty_lock(vsg->pages, vsg->num_pages,
- (vsg->direction == DMA_FROM_DEVICE));
+   unpin_user_pages_dirty_lock(vsg->pages, vsg->num_pages,
+  (vsg->direction == DMA_FROM_DEVICE));
/* fall through */
case dr_via_pages_alloc:
vfree(vsg->pages);
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 55daefaa9b88..a6094766b6f5 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -54,7 +54,7 @@ static void __ib_umem_release(struct ib_device *dev, struct 
ib_umem *umem, int d
 
for_each_sg_page(umem->sg_head.sgl, _iter, umem->sg_nents, 0) {
page = sg_page_iter_page(_iter);
-   put_user_pages_dirty_lock(, 1, umem->writable && dirty);
+   unpin_user_pages_dirty_lock(, 1, umem->writable && dirty);
}
 
sg_free_table(>sg_head);
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c 
b/drivers/infiniband/hw/hfi1/user_pages.c
index 9a94761765c0..3b505006c0a6 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -118,7 +118,7 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned 
long vaddr, size_t np
 void hfi1_release_user_pages(struct mm_struct *mm, struct page **p,
 size_t npages, bool dirty)
 {
-   put_user_pages_dirty_lock(p, npages, dirty);
+   unpin_user_pages_dirty_lock(p, npages, dirty);
 
if (mm) { /* during close after signal, mm can be NULL */
atomic64_sub(npages, >pinned_vm);
diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c 
b/drivers/infiniband/hw/mthca/mthca_memfree.c
index 

[PATCH v12 15/22] drm/via: set FOLL_PIN via pin_user_pages_fast()

2020-01-07 Thread John Hubbard
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().

In partial anticipation of this work, the drm/via driver was already
calling put_user_page() instead of put_page(). Therefore, in order to
convert from the get_user_pages()/put_page() model, to the
pin_user_pages()/put_user_page() model, the only change required
is to change get_user_pages() to pin_user_pages().

Acked-by: Daniel Vetter 
Reviewed-by: Jérôme Glisse 
Reviewed-by: Ira Weiny 
Signed-off-by: John Hubbard 
---
 drivers/gpu/drm/via/via_dmablit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/via/via_dmablit.c 
b/drivers/gpu/drm/via/via_dmablit.c
index 3db000aacd26..37c5e572993a 100644
--- a/drivers/gpu/drm/via/via_dmablit.c
+++ b/drivers/gpu/drm/via/via_dmablit.c
@@ -239,7 +239,7 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,  
drm_via_dmablit_t *xfer)
vsg->pages = vzalloc(array_size(sizeof(struct page *), vsg->num_pages));
if (NULL == vsg->pages)
return -ENOMEM;
-   ret = get_user_pages_fast((unsigned long)xfer->mem_addr,
+   ret = pin_user_pages_fast((unsigned long)xfer->mem_addr,
vsg->num_pages,
vsg->direction == DMA_FROM_DEVICE ? FOLL_WRITE : 0,
vsg->pages);
-- 
2.24.1

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


[PATCH v12 09/22] IB/umem: use get_user_pages_fast() to pin DMA pages

2020-01-07 Thread John Hubbard
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.

Reviewed-by: Leon Romanovsky 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Ira Weiny 
Signed-off-by: John Hubbard 
---
 drivers/infiniband/core/umem.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 7a3b99597ead..214e87aa609d 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -266,16 +266,13 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, 
unsigned long addr,
sg = umem->sg_head.sgl;
 
while (npages) {
-   down_read(>mmap_sem);
-   ret = get_user_pages(cur_base,
-min_t(unsigned long, npages,
-  PAGE_SIZE / sizeof (struct page *)),
-gup_flags | FOLL_LONGTERM,
-page_list, NULL);
-   if (ret < 0) {
-   up_read(>mmap_sem);
+   ret = get_user_pages_fast(cur_base,
+ min_t(unsigned long, npages,
+   PAGE_SIZE /
+   sizeof(struct page *)),
+ gup_flags | FOLL_LONGTERM, page_list);
+   if (ret < 0)
goto umem_release;
-   }
 
cur_base += ret * PAGE_SIZE;
npages   -= ret;
@@ -283,8 +280,6 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, 
unsigned long addr,
sg = ib_umem_add_sg_table(sg, page_list, ret,
dma_get_max_seg_size(context->device->dma_device),
>sg_nents);
-
-   up_read(>mmap_sem);
}
 
sg_mark_end(sg);
-- 
2.24.1

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


[PATCH v12 08/22] mm/gup: allow FOLL_FORCE for get_user_pages_fast()

2020-01-07 Thread John Hubbard
Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed
only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast().
This, combined with the fact that get_user_pages_fast() falls back to
"slow gup", which *does* accept FOLL_FORCE, leads to an odd situation:
if you need FOLL_FORCE, you cannot call get_user_pages_fast().

There does not appear to be any reason for filtering out FOLL_FORCE.
There is nothing in the _fast() implementation that requires that we
avoid writing to the pages. So it appears to have been an oversight.

Fix by allowing FOLL_FORCE to be set for get_user_pages_fast().

Fixes: 817be129e6f2 ("mm: validate get_user_pages_fast flags")
Cc: Christoph Hellwig 
Reviewed-by: Leon Romanovsky 
Reviewed-by: Jan Kara 
Signed-off-by: John Hubbard 
---
 mm/gup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/gup.c b/mm/gup.c
index b61bd5c469ae..a594bc708367 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2411,7 +2411,8 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
unsigned long addr, len, end;
int nr = 0, ret = 0;
 
-   if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM)))
+   if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
+  FOLL_FORCE)))
return -EINVAL;
 
start = untagged_addr(start) & PAGE_MASK;
-- 
2.24.1

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


[PATCH v12 13/22] IB/{core, hw, umem}: set FOLL_PIN via pin_user_pages*(), fix up ODP

2020-01-07 Thread John Hubbard
Convert infiniband to use the new pin_user_pages*() calls.

Also, revert earlier changes to Infiniband ODP that had it using
put_user_page(). ODP is "Case 3" in
Documentation/core-api/pin_user_pages.rst, which is to say, normal
get_user_pages() and put_page() is the API to use there.

The new pin_user_pages*() calls replace corresponding get_user_pages*()
calls, and set the FOLL_PIN flag. The FOLL_PIN flag requires that the
caller must return the pages via put_user_page*() calls, but infiniband
was already doing that as part of an earlier commit.

Reviewed-by: Jason Gunthorpe 
Signed-off-by: John Hubbard 
---
 drivers/infiniband/core/umem.c  |  2 +-
 drivers/infiniband/core/umem_odp.c  | 13 ++---
 drivers/infiniband/hw/hfi1/user_pages.c |  2 +-
 drivers/infiniband/hw/mthca/mthca_memfree.c |  2 +-
 drivers/infiniband/hw/qib/qib_user_pages.c  |  2 +-
 drivers/infiniband/hw/qib/qib_user_sdma.c   |  2 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c|  2 +-
 drivers/infiniband/sw/siw/siw_mem.c |  2 +-
 8 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 214e87aa609d..55daefaa9b88 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -266,7 +266,7 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, 
unsigned long addr,
sg = umem->sg_head.sgl;
 
while (npages) {
-   ret = get_user_pages_fast(cur_base,
+   ret = pin_user_pages_fast(cur_base,
  min_t(unsigned long, npages,
PAGE_SIZE /
sizeof(struct page *)),
diff --git a/drivers/infiniband/core/umem_odp.c 
b/drivers/infiniband/core/umem_odp.c
index e42d44e501fd..abc3bb6578cc 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -308,9 +308,8 @@ EXPORT_SYMBOL(ib_umem_odp_release);
  * The function returns -EFAULT if the DMA mapping operation fails. It returns
  * -EAGAIN if a concurrent invalidation prevents us from updating the page.
  *
- * The page is released via put_user_page even if the operation failed. For
- * on-demand pinning, the page is released whenever it isn't stored in the
- * umem.
+ * The page is released via put_page even if the operation failed. For 
on-demand
+ * pinning, the page is released whenever it isn't stored in the umem.
  */
 static int ib_umem_odp_map_dma_single_page(
struct ib_umem_odp *umem_odp,
@@ -363,7 +362,7 @@ static int ib_umem_odp_map_dma_single_page(
}
 
 out:
-   put_user_page(page);
+   put_page(page);
return ret;
 }
 
@@ -473,7 +472,7 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp *umem_odp, 
u64 user_virt,
ret = -EFAULT;
break;
}
-   put_user_page(local_page_list[j]);
+   put_page(local_page_list[j]);
continue;
}
 
@@ -500,8 +499,8 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp *umem_odp, 
u64 user_virt,
 * ib_umem_odp_map_dma_single_page().
 */
if (npages - (j + 1) > 0)
-   put_user_pages(_page_list[j+1],
-  npages - (j + 1));
+   release_pages(_page_list[j+1],
+ npages - (j + 1));
break;
}
}
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c 
b/drivers/infiniband/hw/hfi1/user_pages.c
index 469acb961fbd..9a94761765c0 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -106,7 +106,7 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned 
long vaddr, size_t np
int ret;
unsigned int gup_flags = FOLL_LONGTERM | (writable ? FOLL_WRITE : 0);
 
-   ret = get_user_pages_fast(vaddr, npages, gup_flags, pages);
+   ret = pin_user_pages_fast(vaddr, npages, gup_flags, pages);
if (ret < 0)
return ret;
 
diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c 
b/drivers/infiniband/hw/mthca/mthca_memfree.c
index edccfd6e178f..8269ab040c21 100644
--- a/drivers/infiniband/hw/mthca/mthca_memfree.c
+++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
@@ -472,7 +472,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct 
mthca_uar *uar,
goto out;
}
 
-   ret = get_user_pages_fast(uaddr & PAGE_MASK, 1,
+   ret = pin_user_pages_fast(uaddr & PAGE_MASK, 1,
  FOLL_WRITE | FOLL_LONGTERM, pages);
if (ret < 0)
goto out;
diff --git 

[PATCH v12 01/22] mm/gup: factor out duplicate code from four routines

2020-01-07 Thread John Hubbard
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.

Factor out the common code into static functions, thus reducing the
overall line count and the code's complexity.

Also, take the opportunity to slightly improve the efficiency of the
error cases, by doing a mass subtraction of the refcount, surrounded
by get_page()/put_page().

Also, further simplify (slightly), by waiting until the the successful
end of each routine, to increment *nr.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Jérôme Glisse 
Reviewed-by: Jan Kara 
Cc: Kirill A. Shutemov 
Cc: Ira Weiny 
Cc: Christoph Hellwig 
Cc: Aneesh Kumar K.V 
Signed-off-by: John Hubbard 
---
 mm/gup.c | 95 
 1 file changed, 40 insertions(+), 55 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 7646bf993b25..d56c6d6b85d3 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1978,6 +1978,29 @@ static int __gup_device_huge_pud(pud_t pud, pud_t *pudp, 
unsigned long addr,
 }
 #endif
 
+static int record_subpages(struct page *page, unsigned long addr,
+  unsigned long end, struct page **pages)
+{
+   int nr;
+
+   for (nr = 0; addr != end; addr += PAGE_SIZE)
+   pages[nr++] = page++;
+
+   return nr;
+}
+
+static void put_compound_head(struct page *page, int refs)
+{
+   VM_BUG_ON_PAGE(page_ref_count(page) < refs, page);
+   /*
+* Calling put_page() for each ref is unnecessarily slow. Only the last
+* ref needs a put_page().
+*/
+   if (refs > 1)
+   page_ref_sub(page, refs - 1);
+   put_page(page);
+}
+
 #ifdef CONFIG_ARCH_HAS_HUGEPD
 static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
  unsigned long sz)
@@ -2007,32 +2030,20 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz, 
unsigned long addr,
/* hugepages are never "special" */
VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
 
-   refs = 0;
head = pte_page(pte);
-
page = head + ((addr & (sz-1)) >> PAGE_SHIFT);
-   do {
-   VM_BUG_ON(compound_head(page) != head);
-   pages[*nr] = page;
-   (*nr)++;
-   page++;
-   refs++;
-   } while (addr += PAGE_SIZE, addr != end);
+   refs = record_subpages(page, addr, end, pages + *nr);
 
head = try_get_compound_head(head, refs);
-   if (!head) {
-   *nr -= refs;
+   if (!head)
return 0;
-   }
 
if (unlikely(pte_val(pte) != pte_val(*ptep))) {
-   /* Could be optimized better */
-   *nr -= refs;
-   while (refs--)
-   put_page(head);
+   put_compound_head(head, refs);
return 0;
}
 
+   *nr += refs;
SetPageReferenced(head);
return 1;
 }
@@ -2079,28 +2090,19 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, 
unsigned long addr,
return __gup_device_huge_pmd(orig, pmdp, addr, end, pages, nr);
}
 
-   refs = 0;
page = pmd_page(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
-   do {
-   pages[*nr] = page;
-   (*nr)++;
-   page++;
-   refs++;
-   } while (addr += PAGE_SIZE, addr != end);
+   refs = record_subpages(page, addr, end, pages + *nr);
 
head = try_get_compound_head(pmd_page(orig), refs);
-   if (!head) {
-   *nr -= refs;
+   if (!head)
return 0;
-   }
 
if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
-   *nr -= refs;
-   while (refs--)
-   put_page(head);
+   put_compound_head(head, refs);
return 0;
}
 
+   *nr += refs;
SetPageReferenced(head);
return 1;
 }
@@ -2120,28 +2122,19 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp, 
unsigned long addr,
return __gup_device_huge_pud(orig, pudp, addr, end, pages, nr);
}
 
-   refs = 0;
page = pud_page(orig) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
-   do {
-   pages[*nr] = page;
-   (*nr)++;
-   page++;
-   refs++;
-   } while (addr += PAGE_SIZE, addr != end);
+   refs = record_subpages(page, addr, end, pages + *nr);
 
head = try_get_compound_head(pud_page(orig), refs);
-   if (!head) {
-   *nr -= refs;
+   if (!head)
return 0;
-   }
 
if (unlikely(pud_val(orig) != pud_val(*pudp))) {
-   *nr -= refs;
-   while (refs--)
-   put_page(head);
+   put_compound_head(head, refs);
return 0;
}
 
+

[PATCH v12 18/22] media/v4l2-core: pin_user_pages (FOLL_PIN) and put_user_page() conversion

2020-01-07 Thread John Hubbard
1. Change v4l2 from get_user_pages() to pin_user_pages().

2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().

Acked-by: Hans Verkuil 
Cc: Ira Weiny 
Signed-off-by: John Hubbard 
---
 drivers/media/v4l2-core/videobuf-dma-sg.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c 
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 28262190c3ab..162a2633b1e3 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -183,12 +183,12 @@ static int videobuf_dma_init_user_locked(struct 
videobuf_dmabuf *dma,
dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
data, size, dma->nr_pages);
 
-   err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
+   err = pin_user_pages(data & PAGE_MASK, dma->nr_pages,
 flags | FOLL_LONGTERM, dma->pages, NULL);
 
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
-   dprintk(1, "get_user_pages: err=%d [%d]\n", err,
+   dprintk(1, "pin_user_pages: err=%d [%d]\n", err,
dma->nr_pages);
return err < 0 ? err : -EINVAL;
}
@@ -349,11 +349,8 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
BUG_ON(dma->sglen);
 
if (dma->pages) {
-   for (i = 0; i < dma->nr_pages; i++) {
-   if (dma->direction == DMA_FROM_DEVICE)
-   set_page_dirty_lock(dma->pages[i]);
-   put_page(dma->pages[i]);
-   }
+   put_user_pages_dirty_lock(dma->pages, dma->nr_pages,
+ dma->direction == DMA_FROM_DEVICE);
kfree(dma->pages);
dma->pages = NULL;
}
-- 
2.24.1

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


[PATCH v12 03/22] mm: Cleanup __put_devmap_managed_page() vs ->page_free()

2020-01-07 Thread John Hubbard
From: Dan Williams 

After the removal of the device-public infrastructure there are only 2
->page_free() call backs in the kernel. One of those is a device-private
callback in the nouveau driver, the other is a generic wakeup needed in
the DAX case. In the hopes that all ->page_free() callbacks can be
migrated to common core kernel functionality, move the device-private
specific actions in __put_devmap_managed_page() under the
is_device_private_page() conditional, including the ->page_free()
callback. For the other page types just open-code the generic wakeup.

Yes, the wakeup is only needed in the MEMORY_DEVICE_FSDAX case, but it
does no harm in the MEMORY_DEVICE_DEVDAX and MEMORY_DEVICE_PCI_P2PDMA
case.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Jérôme Glisse 
Cc: Jan Kara 
Cc: Ira Weiny 
Signed-off-by: Dan Williams 
Signed-off-by: John Hubbard 
---
 drivers/nvdimm/pmem.c |  6 
 mm/memremap.c | 80 ---
 2 files changed, 44 insertions(+), 42 deletions(-)

diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index ad8e4df1282b..4eae441f86c9 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -337,13 +337,7 @@ static void pmem_release_disk(void *__pmem)
put_disk(pmem->disk);
 }
 
-static void pmem_pagemap_page_free(struct page *page)
-{
-   wake_up_var(>_refcount);
-}
-
 static const struct dev_pagemap_ops fsdax_pagemap_ops = {
-   .page_free  = pmem_pagemap_page_free,
.kill   = pmem_pagemap_kill,
.cleanup= pmem_pagemap_cleanup,
 };
diff --git a/mm/memremap.c b/mm/memremap.c
index c51c6bd2fe34..f915d074ac20 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -27,7 +27,8 @@ static void devmap_managed_enable_put(void)
 
 static int devmap_managed_enable_get(struct dev_pagemap *pgmap)
 {
-   if (!pgmap->ops || !pgmap->ops->page_free) {
+   if (pgmap->type == MEMORY_DEVICE_PRIVATE &&
+   (!pgmap->ops || !pgmap->ops->page_free)) {
WARN(1, "Missing page_free method\n");
return -EINVAL;
}
@@ -414,44 +415,51 @@ void __put_devmap_managed_page(struct page *page)
 {
int count = page_ref_dec_return(page);
 
-   /*
-* If refcount is 1 then page is freed and refcount is stable as nobody
-* holds a reference on the page.
-*/
-   if (count == 1) {
-   /* Clear Active bit in case of parallel mark_page_accessed */
-   __ClearPageActive(page);
-   __ClearPageWaiters(page);
+   /* still busy */
+   if (count > 1)
+   return;
 
-   mem_cgroup_uncharge(page);
+   /* only triggered by the dev_pagemap shutdown path */
+   if (count == 0) {
+   __put_page(page);
+   return;
+   }
 
-   /*
-* When a device_private page is freed, the page->mapping field
-* may still contain a (stale) mapping value. For example, the
-* lower bits of page->mapping may still identify the page as
-* an anonymous page. Ultimately, this entire field is just
-* stale and wrong, and it will cause errors if not cleared.
-* One example is:
-*
-*  migrate_vma_pages()
-*migrate_vma_insert_page()
-*  page_add_new_anon_rmap()
-*__page_set_anon_rmap()
-*  ...checks page->mapping, via PageAnon(page) call,
-*and incorrectly concludes that the page is an
-*anonymous page. Therefore, it incorrectly,
-*silently fails to set up the new anon rmap.
-*
-* For other types of ZONE_DEVICE pages, migration is either
-* handled differently or not done at all, so there is no need
-* to clear page->mapping.
-*/
-   if (is_device_private_page(page))
-   page->mapping = NULL;
+   /* notify page idle for dax */
+   if (!is_device_private_page(page)) {
+   wake_up_var(>_refcount);
+   return;
+   }
 
-   page->pgmap->ops->page_free(page);
-   } else if (!count)
-   __put_page(page);
+   /* Clear Active bit in case of parallel mark_page_accessed */
+   __ClearPageActive(page);
+   __ClearPageWaiters(page);
+
+   mem_cgroup_uncharge(page);
+
+   /*
+* When a device_private page is freed, the page->mapping field
+* may still contain a (stale) mapping value. For example, the
+* lower bits of page->mapping may still identify the page as an
+* anonymous page. Ultimately, this entire field is just stale
+* and wrong, and it will cause errors if not cleared.  One
+* example is:
+*
+*  

[PATCH v12 07/22] vfio: fix FOLL_LONGTERM use, simplify get_user_pages_remote() call

2020-01-07 Thread John Hubbard
Update VFIO to take advantage of the recently loosened restriction on
FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to
fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it
wasn't setting FOLL_LONGTERM.

Also, remove an unnessary pair of calls that were releasing and
reacquiring the mmap_sem. There is no need to avoid holding mmap_sem
just in order to call page_to_pfn().

Also, now that the the DAX check ("if a VMA is DAX, don't allow long
term pinning") is in the internals of get_user_pages_remote() and
__gup_longterm_locked(), there's no need for it at the VFIO call site.
So remove it.

Tested-by: Alex Williamson 
Acked-by: Alex Williamson 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Ira Weiny 
Suggested-by: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Jerome Glisse 
Signed-off-by: John Hubbard 
---
 drivers/vfio/vfio_iommu_type1.c | 30 +-
 1 file changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 2ada8e6cdb88..b800fc9a0251 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -322,7 +322,6 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
long vaddr,
 {
struct page *page[1];
struct vm_area_struct *vma;
-   struct vm_area_struct *vmas[1];
unsigned int flags = 0;
int ret;
 
@@ -330,33 +329,14 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
long vaddr,
flags |= FOLL_WRITE;
 
down_read(>mmap_sem);
-   if (mm == current->mm) {
-   ret = get_user_pages(vaddr, 1, flags | FOLL_LONGTERM, page,
-vmas);
-   } else {
-   ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
-   vmas, NULL);
-   /*
-* The lifetime of a vaddr_get_pfn() page pin is
-* userspace-controlled. In the fs-dax case this could
-* lead to indefinite stalls in filesystem operations.
-* Disallow attempts to pin fs-dax pages via this
-* interface.
-*/
-   if (ret > 0 && vma_is_fsdax(vmas[0])) {
-   ret = -EOPNOTSUPP;
-   put_page(page[0]);
-   }
-   }
-   up_read(>mmap_sem);
-
+   ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
+   page, NULL, NULL);
if (ret == 1) {
*pfn = page_to_pfn(page[0]);
-   return 0;
+   ret = 0;
+   goto done;
}
 
-   down_read(>mmap_sem);
-
vaddr = untagged_addr(vaddr);
 
vma = find_vma_intersection(mm, vaddr, vaddr + 1);
@@ -366,7 +346,7 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
long vaddr,
if (is_invalid_reserved_pfn(*pfn))
ret = 0;
}
-
+done:
up_read(>mmap_sem);
return ret;
 }
-- 
2.24.1

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


[PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

2020-01-07 Thread John Hubbard
Hi,

The "track FOLL_PIN pages" would have been the very next patch, but it is
not included here because I'm still debugging a bug report from Leon.
Let's get all of the prerequisite work (it's been reviewed) into the tree
so that future reviews are easier. It's clear that any fixes that are
required to the tracking patch, won't affect these patches here.

This implements an API naming change (put_user_page*() -->
unpin_user_page*()), and also adds FOLL_PIN page support, up to
*but not including* actually tracking FOLL_PIN pages. It extends
the FOLL_PIN support to a few select subsystems. More subsystems will
be added in follow up work.

Christoph Hellwig, a point of interest:

a) I've moved the bulk of the code out of the inline functions, as
   requested, for the devmap changes (patch 4: "mm: devmap: refactor
   1-based refcounting for ZONE_DEVICE pages").

Changes since v11: Fixes resulting from Kirill Shutemov's review, plus
a fix for a kbuild robot-reported warning.

* Only include the first 22 patches: up to, but not including, the "track
  FOLL_PIN pages" patch.

* Improved the efficiency of put_compound_head(), by avoiding get_page()
  entirely, and instead doing the mass subtraction on one less than
  refs, followed by a final put_page().

* Got rid of the forward declaration of __gup_longterm_locked(), by
  moving get_user_pages_remote() further down in gup.c

* Got rid of a redundant page_is_devmap_managed() call, and simplified
  put_devmap_managed_page() as part of that small cleanup.

* Changed put_devmap_managed_page() to do an early out if the page is
  not devmap managed. This saves an indentation level.

* Applied the same type of change to __unpin_devmap_managed_user_page(),
  which has the same checks.

* Changed release_pages() to handle the changed put_devmap_managed_page()
  API.

* Removed EXPORT_SYMBOL(free_devmap_managed_page), as it is not required,
  after the other refactoring.

* Fixed a kbuild robot sparse warning: added "static" to
  try_pin_compound_head()'s declaration.

There is a git repo and branch, for convenience:

g...@github.com:johnhubbard/linux.git pin_user_pages_tracking_v8

For the remaining list of "changes since version N", those are all in
v11, which is here:

  https://lore.kernel.org/r/20191216222537.491123-1-jhubb...@nvidia.com


Overview:

This is a prerequisite to solving the problem of proper interactions
between file-backed pages, and [R]DMA activities, as discussed in [1],
[2], [3], and in a remarkable number of email threads since about
2017. :)

A new internal gup flag, FOLL_PIN is introduced, and thoroughly
documented in the last patch's Documentation/vm/pin_user_pages.rst.

I believe that this will provide a good starting point for doing the
layout lease work that Ira Weiny has been working on. That's because
these new wrapper functions provide a clean, constrained, systematically
named set of functionality that, again, is required in order to even
know if a page is "dma-pinned".

In contrast to earlier approaches, the page tracking can be
incrementally applied to the kernel call sites that, until now, have
been simply calling get_user_pages() ("gup"). In other words, opt-in by
changing from this:

get_user_pages() (sets FOLL_GET)
put_page()

to this:
pin_user_pages() (sets FOLL_PIN)
unpin_user_page()


Testing:

* I've done some overall kernel testing (LTP, and a few other goodies),
  and some directed testing to exercise some of the changes. And as you
  can see, gup_benchmark is enhanced to exercise this. Basically, I've
  been able to runtime test the core get_user_pages() and
  pin_user_pages() and related routines, but not so much on several of
  the call sites--but those are generally just a couple of lines
  changed, each.

  Not much of the kernel is actually using this, which on one hand
  reduces risk quite a lot. But on the other hand, testing coverage
  is low. So I'd love it if, in particular, the Infiniband and PowerPC
  folks could do a smoke test of this series for me.

  Runtime testing for the call sites so far is pretty light:

* io_uring: Some directed tests from liburing exercise this, and
they pass.
* process_vm_access.c: A small directed test passes.
* gup_benchmark: the enhanced version hits the new gup.c code, and
 passes.
* infiniband: Ran rdma-core tests: rdma-core/build/bin/run_tests.py
* VFIO: compiles (I'm vowing to set up a run time test soon, but it's
  not ready just yet)
* powerpc: it compiles...
* drm/via: compiles...
* goldfish: compiles...
* net/xdp: compiles...
* media/v4l2: compiles...

[1] Some slow progress on get_user_pages() (Apr 2, 2019): 
https://lwn.net/Articles/784574/
[2] DMA and get_user_pages() (LPC: Dec 12, 2018): 
https://lwn.net/Articles/774411/
[3] The trouble 

[PATCH v12 21/22] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1"

2020-01-07 Thread John Hubbard
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.

Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
phrases in the function calls.

Reviewed-by: Ira Weiny 
Signed-off-by: John Hubbard 
---
 mm/gup_benchmark.c | 9 ++---
 tools/testing/selftests/vm/gup_benchmark.c | 6 +-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c
index ad9d5b1c4473..8dba38e79a9f 100644
--- a/mm/gup_benchmark.c
+++ b/mm/gup_benchmark.c
@@ -49,18 +49,21 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
nr = (next - addr) / PAGE_SIZE;
}
 
+   /* Filter out most gup flags: only allow a tiny subset here: */
+   gup->flags &= FOLL_WRITE;
+
switch (cmd) {
case GUP_FAST_BENCHMARK:
-   nr = get_user_pages_fast(addr, nr, gup->flags & 1,
+   nr = get_user_pages_fast(addr, nr, gup->flags,
 pages + i);
break;
case GUP_LONGTERM_BENCHMARK:
nr = get_user_pages(addr, nr,
-   (gup->flags & 1) | FOLL_LONGTERM,
+   gup->flags | FOLL_LONGTERM,
pages + i, NULL);
break;
case GUP_BENCHMARK:
-   nr = get_user_pages(addr, nr, gup->flags & 1, pages + i,
+   nr = get_user_pages(addr, nr, gup->flags, pages + i,
NULL);
break;
default:
diff --git a/tools/testing/selftests/vm/gup_benchmark.c 
b/tools/testing/selftests/vm/gup_benchmark.c
index 485cf06ef013..389327e9b30a 100644
--- a/tools/testing/selftests/vm/gup_benchmark.c
+++ b/tools/testing/selftests/vm/gup_benchmark.c
@@ -18,6 +18,9 @@
 #define GUP_LONGTERM_BENCHMARK _IOWR('g', 2, struct gup_benchmark)
 #define GUP_BENCHMARK  _IOWR('g', 3, struct gup_benchmark)
 
+/* Just the flags we need, copied from mm.h: */
+#define FOLL_WRITE 0x01/* check pte is writable */
+
 struct gup_benchmark {
__u64 get_delta_usec;
__u64 put_delta_usec;
@@ -85,7 +88,8 @@ int main(int argc, char **argv)
}
 
gup.nr_pages_per_call = nr_pages;
-   gup.flags = write;
+   if (write)
+   gup.flags |= FOLL_WRITE;
 
fd = open("/sys/kernel/debug/gup_benchmark", O_RDWR);
if (fd == -1)
-- 
2.24.1

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


[PATCH v12 20/22] powerpc: book3s64: convert to pin_user_pages() and put_user_page()

2020-01-07 Thread John Hubbard
1. Convert from get_user_pages() to pin_user_pages().

2. As required by pin_user_pages(), release these pages via
put_user_page().

Reviewed-by: Jan Kara 
Signed-off-by: John Hubbard 
---
 arch/powerpc/mm/book3s64/iommu_api.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/iommu_api.c 
b/arch/powerpc/mm/book3s64/iommu_api.c
index 56cc84520577..a86547822034 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -103,7 +103,7 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
unsigned long ua,
for (entry = 0; entry < entries; entry += chunk) {
unsigned long n = min(entries - entry, chunk);
 
-   ret = get_user_pages(ua + (entry << PAGE_SHIFT), n,
+   ret = pin_user_pages(ua + (entry << PAGE_SHIFT), n,
FOLL_WRITE | FOLL_LONGTERM,
mem->hpages + entry, NULL);
if (ret == n) {
@@ -167,9 +167,8 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
unsigned long ua,
return 0;
 
 free_exit:
-   /* free the reference taken */
-   for (i = 0; i < pinned; i++)
-   put_page(mem->hpages[i]);
+   /* free the references taken */
+   put_user_pages(mem->hpages, pinned);
 
vfree(mem->hpas);
kfree(mem);
@@ -215,7 +214,8 @@ static void mm_iommu_unpin(struct 
mm_iommu_table_group_mem_t *mem)
if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
SetPageDirty(page);
 
-   put_page(page);
+   put_user_page(page);
+
mem->hpas[i] = 0;
}
 }
-- 
2.24.1

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


[PATCH v12 04/22] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages

2020-01-07 Thread John Hubbard
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:

* Rename put_devmap_managed_page() to page_is_devmap_managed(),
  and limit the functionality to "read only": return a bool,
  with no side effects.

* Add a new routine, put_devmap_managed_page(), to handle
  decrementing the refcount for ZONE_DEVICE pages.

* Change callers (just release_pages() and put_page()) to check
  page_is_devmap_managed() before calling the new
  put_devmap_managed_page() routine. This is a performance
  point: put_page() is a hot path, so we need to avoid non-
  inline function calls where possible.

* Rename __put_devmap_managed_page() to free_devmap_managed_page(),
  and limit the functionality to unconditionally freeing a devmap
  page.

This is originally based on a separate patch by Ira Weiny, which
applied to an early version of the put_user_page() experiments.
Since then, Jérôme Glisse suggested the refactoring described above.

Cc: Christoph Hellwig 
Cc: Kirill A. Shutemov 
Suggested-by: Jérôme Glisse 
Reviewed-by: Dan Williams 
Reviewed-by: Jan Kara 
Signed-off-by: Ira Weiny 
Signed-off-by: John Hubbard 
---
 include/linux/mm.h | 18 +-
 mm/memremap.c  | 15 +--
 mm/swap.c  | 27 ++-
 3 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 80a9162b406c..e2032ff640eb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -952,9 +952,10 @@ static inline bool is_zone_device_page(const struct page 
*page)
 #endif
 
 #ifdef CONFIG_DEV_PAGEMAP_OPS
-void __put_devmap_managed_page(struct page *page);
+void free_devmap_managed_page(struct page *page);
 DECLARE_STATIC_KEY_FALSE(devmap_managed_key);
-static inline bool put_devmap_managed_page(struct page *page)
+
+static inline bool page_is_devmap_managed(struct page *page)
 {
if (!static_branch_unlikely(_managed_key))
return false;
@@ -963,7 +964,6 @@ static inline bool put_devmap_managed_page(struct page 
*page)
switch (page->pgmap->type) {
case MEMORY_DEVICE_PRIVATE:
case MEMORY_DEVICE_FS_DAX:
-   __put_devmap_managed_page(page);
return true;
default:
break;
@@ -971,11 +971,17 @@ static inline bool put_devmap_managed_page(struct page 
*page)
return false;
 }
 
+void put_devmap_managed_page(struct page *page);
+
 #else /* CONFIG_DEV_PAGEMAP_OPS */
-static inline bool put_devmap_managed_page(struct page *page)
+static inline bool page_is_devmap_managed(struct page *page)
 {
return false;
 }
+
+static inline void put_devmap_managed_page(struct page *page)
+{
+}
 #endif /* CONFIG_DEV_PAGEMAP_OPS */
 
 static inline bool is_device_private_page(const struct page *page)
@@ -1028,8 +1034,10 @@ static inline void put_page(struct page *page)
 * need to inform the device driver through callback. See
 * include/linux/memremap.h and HMM for details.
 */
-   if (put_devmap_managed_page(page))
+   if (page_is_devmap_managed(page)) {
+   put_devmap_managed_page(page);
return;
+   }
 
if (put_page_testzero(page))
__put_page(page);
diff --git a/mm/memremap.c b/mm/memremap.c
index f915d074ac20..4c723d2049d5 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -411,20 +411,8 @@ struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
 EXPORT_SYMBOL_GPL(get_dev_pagemap);
 
 #ifdef CONFIG_DEV_PAGEMAP_OPS
-void __put_devmap_managed_page(struct page *page)
+void free_devmap_managed_page(struct page *page)
 {
-   int count = page_ref_dec_return(page);
-
-   /* still busy */
-   if (count > 1)
-   return;
-
-   /* only triggered by the dev_pagemap shutdown path */
-   if (count == 0) {
-   __put_page(page);
-   return;
-   }
-
/* notify page idle for dax */
if (!is_device_private_page(page)) {
wake_up_var(>_refcount);
@@ -461,5 +449,4 @@ void __put_devmap_managed_page(struct page *page)
page->mapping = NULL;
page->pgmap->ops->page_free(page);
 }
-EXPORT_SYMBOL(__put_devmap_managed_page);
 #endif /* CONFIG_DEV_PAGEMAP_OPS */
diff --git a/mm/swap.c b/mm/swap.c
index 5341ae93861f..cf39d24ada2a 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -813,8 +813,10 @@ void release_pages(struct page **pages, int nr)
 * processing, and instead, expect a call to
 * put_page_testzero().
 */
-   if (put_devmap_managed_page(page))
+   if (page_is_devmap_managed(page)) {
+   put_devmap_managed_page(page);
continue;
+   }
}
 
page = compound_head(page);
@@ 

[PATCH v12 11/22] mm/gup: introduce pin_user_pages*() and FOLL_PIN

2020-01-07 Thread John Hubbard
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.

For now, these are placeholder calls, until the various call sites
are converted to use the correct get_user_pages*() or
pin_user_pages*() API.

These variants will eventually all set FOLL_PIN, which is also
introduced, and thoroughly documented.

pin_user_pages()
pin_user_pages_remote()
pin_user_pages_fast()

All pages that are pinned via the above calls, must be unpinned via
put_user_page().

The underlying rules are:

* FOLL_PIN is a gup-internal flag, so the call sites should not directly
set it. That behavior is enforced with assertions.

* Call sites that want to indicate that they are going to do DirectIO
  ("DIO") or something with similar characteristics, should call a
  get_user_pages()-like wrapper call that sets FOLL_PIN. These wrappers
  will:
* Start with "pin_user_pages" instead of "get_user_pages". That
  makes it easy to find and audit the call sites.
* Set FOLL_PIN

* For pages that are received via FOLL_PIN, those pages must be returned
  via put_user_page().

Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
in this documentation. (I've reworded it and expanded upon it.)

Reviewed-by: Jan Kara 
Reviewed-by: Mike Rapoport   # Documentation
Reviewed-by: Jérôme Glisse 
Cc: Jonathan Corbet 
Cc: Ira Weiny 
Signed-off-by: John Hubbard 
---
 Documentation/core-api/index.rst  |   1 +
 Documentation/core-api/pin_user_pages.rst | 232 ++
 include/linux/mm.h|  63 --
 mm/gup.c  | 164 +--
 4 files changed, 426 insertions(+), 34 deletions(-)
 create mode 100644 Documentation/core-api/pin_user_pages.rst

diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index ab0eae1c153a..413f7d7c8642 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -31,6 +31,7 @@ Core utilities
generic-radix-tree
memory-allocation
mm-api
+   pin_user_pages
gfp_mask-from-fs-io
timekeeping
boot-time-mm
diff --git a/Documentation/core-api/pin_user_pages.rst 
b/Documentation/core-api/pin_user_pages.rst
new file mode 100644
index ..71849830cd48
--- /dev/null
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -0,0 +1,232 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+pin_user_pages() and related calls
+
+
+.. contents:: :local:
+
+Overview
+
+
+This document describes the following functions::
+
+ pin_user_pages()
+ pin_user_pages_fast()
+ pin_user_pages_remote()
+
+Basic description of FOLL_PIN
+=
+
+FOLL_PIN and FOLL_LONGTERM are flags that can be passed to the 
get_user_pages*()
+("gup") family of functions. FOLL_PIN has significant interactions and
+interdependencies with FOLL_LONGTERM, so both are covered here.
+
+FOLL_PIN is internal to gup, meaning that it should not appear at the gup call
+sites. This allows the associated wrapper functions  (pin_user_pages*() and
+others) to set the correct combination of these flags, and to check for 
problems
+as well.
+
+FOLL_LONGTERM, on the other hand, *is* allowed to be set at the gup call sites.
+This is in order to avoid creating a large number of wrapper functions to cover
+all combinations of get*(), pin*(), FOLL_LONGTERM, and more. Also, the
+pin_user_pages*() APIs are clearly distinct from the get_user_pages*() APIs, so
+that's a natural dividing line, and a good point to make separate wrapper 
calls.
+In other words, use pin_user_pages*() for DMA-pinned pages, and
+get_user_pages*() for other cases. There are four cases described later on in
+this document, to further clarify that concept.
+
+FOLL_PIN and FOLL_GET are mutually exclusive for a given gup call. However,
+multiple threads and call sites are free to pin the same struct pages, via both
+FOLL_PIN and FOLL_GET. It's just the call site that needs to choose one or the
+other, not the struct page(s).
+
+The FOLL_PIN implementation is nearly the same as FOLL_GET, except that 
FOLL_PIN
+uses a different reference counting technique.
+
+FOLL_PIN is a prerequisite to FOLL_LONGTERM. Another way of saying that is,
+FOLL_LONGTERM is a specific case, more restrictive case of FOLL_PIN.
+
+Which flags are set by each wrapper
+===
+
+For these pin_user_pages*() functions, FOLL_PIN is OR'd in with whatever gup
+flags the caller provides. The caller is required to pass in a non-null struct
+pages* array, and the function then pin pages by incrementing each by a special
+value. For now, that value is +1, just like get_user_pages*().::
+
+ Function
+ 
+ pin_user_pages  FOLL_PIN is always set internally by this function.
+ pin_user_pages_fast FOLL_PIN is always set internally by this function.
+ 

[PATCH v12 02/22] mm/gup: move try_get_compound_head() to top, fix minor issues

2020-01-07 Thread John Hubbard
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.

Also fix a tiny spelling error and a checkpatch.pl warning.

Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
Reviewed-by: Ira Weiny 
Signed-off-by: John Hubbard 
---
 mm/gup.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index d56c6d6b85d3..5938e29a5a8b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -29,6 +29,21 @@ struct follow_page_context {
unsigned int page_mask;
 };
 
+/*
+ * Return the compound head page with ref appropriately incremented,
+ * or NULL if that failed.
+ */
+static inline struct page *try_get_compound_head(struct page *page, int refs)
+{
+   struct page *head = compound_head(page);
+
+   if (WARN_ON_ONCE(page_ref_count(head) < 0))
+   return NULL;
+   if (unlikely(!page_cache_add_speculative(head, refs)))
+   return NULL;
+   return head;
+}
+
 /**
  * put_user_pages_dirty_lock() - release and optionally dirty gup-pinned pages
  * @pages:  array of pages to be maybe marked dirty, and definitely released.
@@ -1807,20 +1822,6 @@ static void __maybe_unused undo_dev_pagemap(int *nr, int 
nr_start,
}
 }
 
-/*
- * Return the compund head page with ref appropriately incremented,
- * or NULL if that failed.
- */
-static inline struct page *try_get_compound_head(struct page *page, int refs)
-{
-   struct page *head = compound_head(page);
-   if (WARN_ON_ONCE(page_ref_count(head) < 0))
-   return NULL;
-   if (unlikely(!page_cache_add_speculative(head, refs)))
-   return NULL;
-   return head;
-}
-
 #ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
 static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
 unsigned int flags, struct page **pages, int *nr)
-- 
2.24.1

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


[PATCH v12 10/22] media/v4l2-core: set pages dirty upon releasing DMA buffers

2020-01-07 Thread John Hubbard
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.

Fix the problem, by calling set_page_dirty_lock() if the CPU pages
were potentially receiving data from the device.

Reviewed-by: Christoph Hellwig 
Acked-by: Hans Verkuil 
Cc: Mauro Carvalho Chehab 
Cc: 
Signed-off-by: John Hubbard 
---
 drivers/media/v4l2-core/videobuf-dma-sg.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c 
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 66a6c6c236a7..28262190c3ab 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -349,8 +349,11 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
BUG_ON(dma->sglen);
 
if (dma->pages) {
-   for (i = 0; i < dma->nr_pages; i++)
+   for (i = 0; i < dma->nr_pages; i++) {
+   if (dma->direction == DMA_FROM_DEVICE)
+   set_page_dirty_lock(dma->pages[i]);
put_page(dma->pages[i]);
+   }
kfree(dma->pages);
dma->pages = NULL;
}
-- 
2.24.1

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


[PATCH v12 05/22] goldish_pipe: rename local pin_user_pages() routine

2020-01-07 Thread John Hubbard
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "goldfish_pin_pages()".

An upcoming patch will introduce a global pin_user_pages()
function.

Reviewed-by: Jan Kara 
Reviewed-by: Jérôme Glisse 
Reviewed-by: Ira Weiny 
Signed-off-by: John Hubbard 
---
 drivers/platform/goldfish/goldfish_pipe.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
b/drivers/platform/goldfish/goldfish_pipe.c
index cef0133aa47a..ef50c264db71 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -257,12 +257,12 @@ static int goldfish_pipe_error_convert(int status)
}
 }
 
-static int pin_user_pages(unsigned long first_page,
- unsigned long last_page,
- unsigned int last_page_size,
- int is_write,
- struct page *pages[MAX_BUFFERS_PER_COMMAND],
- unsigned int *iter_last_page_size)
+static int goldfish_pin_pages(unsigned long first_page,
+ unsigned long last_page,
+ unsigned int last_page_size,
+ int is_write,
+ struct page *pages[MAX_BUFFERS_PER_COMMAND],
+ unsigned int *iter_last_page_size)
 {
int ret;
int requested_pages = ((last_page - first_page) >> PAGE_SHIFT) + 1;
@@ -354,9 +354,9 @@ static int transfer_max_buffers(struct goldfish_pipe *pipe,
if (mutex_lock_interruptible(>lock))
return -ERESTARTSYS;
 
-   pages_count = pin_user_pages(first_page, last_page,
-last_page_size, is_write,
-pipe->pages, _last_page_size);
+   pages_count = goldfish_pin_pages(first_page, last_page,
+last_page_size, is_write,
+pipe->pages, _last_page_size);
if (pages_count < 0) {
mutex_unlock(>lock);
return pages_count;
-- 
2.24.1

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


[Bug 204559] amdgpu: kernel oops with constant gpu resets while using mpv

2020-01-07 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=204559

--- Comment #14 from the...@gmail.com ---
i have not seen the oops on a 5.3.x kernel (ubuntu eoan), even without tweaking
the runpm setting (again, only saw it a few times on an earlier kernel).

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


Re: [PATCH] drm: panel: fix excessive stack usage in td028ttec1_prepare

2020-01-07 Thread Arnd Bergmann
On Tue, Jan 7, 2020 at 11:12 PM Laurent Pinchart
 wrote:
> On Tue, Jan 07, 2020 at 11:09:13PM +0100, Arnd Bergmann wrote:
> > On Tue, Jan 7, 2020 at 11:00 PM Laurent Pinchart wrote:

> > > Isn't this something that should be fixed at the compiler level ?
> >
> > I suspect but have not verified that structleak gcc plugin is partly at
> > fault here as well, it has caused similar problems elsewhere.

I checked that now, and it's indeed the structleak plugin.

Interestingly the problem goes away without the -fconserve-stack
option, which is meant to reduce the stack usage bug has the
opposite effect here (!).

I'll do some more tests tomorrow.

> > If you like I can try to dig deeper before that patch gets merged,
> > and explain more in the changelog or open a gcc bug if necessary.
>
> I think we'll need to merge this in the meantime, but if gcc is able to
> detect too large frame sizes, I think it should have the ability to take
> a frame size limit into account when optimizing. I haven't checked if
> this is already possible and just not honoured here (possibly due to a
> bug) or if the feature is entirely missing. In any case we'll likely
> have to live with this compiler issue for quite some time.

When talking to gcc developers about other files that use excessive
amounts of stack space, it was pointed out to me that this is a
fundamentally hard problem to solve in general: what usually happens
is that one optimization step uses a heuristic for inlining, but the
register allocator much later runs out of registers and spills them to
the stack at a point when it's too late to undo the earlier optimizations.

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


Re: [PATCH] drm: panel: fix excessive stack usage in td028ttec1_prepare

2020-01-07 Thread Laurent Pinchart
Hi Arnd,

On Tue, Jan 07, 2020 at 11:09:13PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 7, 2020 at 11:00 PM Laurent Pinchart wrote:
> > On Tue, Jan 07, 2020 at 10:27:33PM +0100, Arnd Bergmann wrote:
> > > With gcc -O3, the compiler can inline very aggressively,
> > > leading to rather large stack usage:
> > >
> > > drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function 
> > > 'td028ttec1_prepare':
> > > drivers/gpu/drm/panel/panel-tpo-td028ttec1.c:233:1: error: the frame size 
> > > of 2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> > >  }
> > >
> > > Marking jbt_reg_write_1() as noinline avoids the case where
> > > multiple instances of this function get inlined into the same
> > > stack frame and each one adds a copy of 'tx_buf'.
> > >
> > > Fixes: mmtom ("init/Kconfig: enable -O3 for all arches")
> > > Signed-off-by: Arnd Bergmann 
> >
> > Isn't this something that should be fixed at the compiler level ?
> 
> I suspect but have not verified that structleak gcc plugin is partly at
> fault here as well, it has caused similar problems elsewhere.
> 
> If you like I can try to dig deeper before that patch gets merged,
> and explain more in the changelog or open a gcc bug if necessary.

I think we'll need to merge this in the meantime, but if gcc is able to
detect too large frame sizes, I think it should have the ability to take
a frame size limit into account when optimizing. I haven't checked if
this is already possible and just not honoured here (possibly due to a
bug) or if the feature is entirely missing. In any case we'll likely
have to live with this compiler issue for quite some time.

-- 
Regards,

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


Re: [PATCH] drm: panel: fix excessive stack usage in td028ttec1_prepare

2020-01-07 Thread Arnd Bergmann
On Tue, Jan 7, 2020 at 11:00 PM Laurent Pinchart
 wrote:
>
> Hi Arnd,
>
> Thank you for the patch.
>
> On Tue, Jan 07, 2020 at 10:27:33PM +0100, Arnd Bergmann wrote:
> > With gcc -O3, the compiler can inline very aggressively,
> > leading to rather large stack usage:
> >
> > drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function 
> > 'td028ttec1_prepare':
> > drivers/gpu/drm/panel/panel-tpo-td028ttec1.c:233:1: error: the frame size 
> > of 2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
> >  }
> >
> > Marking jbt_reg_write_1() as noinline avoids the case where
> > multiple instances of this function get inlined into the same
> > stack frame and each one adds a copy of 'tx_buf'.
> >
> > Fixes: mmtom ("init/Kconfig: enable -O3 for all arches")
> > Signed-off-by: Arnd Bergmann 
>
> Isn't this something that should be fixed at the compiler level ?

I suspect but have not verified that structleak gcc plugin is partly at
fault here as well, it has caused similar problems elsewhere.

If you like I can try to dig deeper before that patch gets merged,
and explain more in the changelog or open a gcc bug if necessary.

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


Re: [PATCH] drm: panel: fix excessive stack usage in td028ttec1_prepare

2020-01-07 Thread Laurent Pinchart
Hi Arnd,

Thank you for the patch.

On Tue, Jan 07, 2020 at 10:27:33PM +0100, Arnd Bergmann wrote:
> With gcc -O3, the compiler can inline very aggressively,
> leading to rather large stack usage:
> 
> drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function 
> 'td028ttec1_prepare':
> drivers/gpu/drm/panel/panel-tpo-td028ttec1.c:233:1: error: the frame size of 
> 2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
>  }
> 
> Marking jbt_reg_write_1() as noinline avoids the case where
> multiple instances of this function get inlined into the same
> stack frame and each one adds a copy of 'tx_buf'.
> 
> Fixes: mmtom ("init/Kconfig: enable -O3 for all arches")
> Signed-off-by: Arnd Bergmann 

Isn't this something that should be fixed at the compiler level ?

> ---
>  drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c 
> b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
> index cf29405a2dbe..17ee5e87141f 100644
> --- a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
> +++ b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
> @@ -105,7 +105,7 @@ static int jbt_ret_write_0(struct td028ttec1_panel *lcd, 
> u8 reg, int *err)
>   return ret;
>  }
>  
> -static int jbt_reg_write_1(struct td028ttec1_panel *lcd,
> +static int noinline_for_stack jbt_reg_write_1(struct td028ttec1_panel *lcd,
>  u8 reg, u8 data, int *err)
>  {
>   struct spi_device *spi = lcd->spi;

-- 
Regards,

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


[PATCH] drm/komeda: mark PM functions as __maybe_unused

2020-01-07 Thread Arnd Bergmann
Without this, we get a couple of warnings when CONFIG_PM
is disabled:

drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12: error: 
'komeda_rt_pm_resume' defined but not used [-Werror=unused-function]
 static int komeda_rt_pm_resume(struct device *dev)
^~~
drivers/gpu/drm/arm/display/komeda/komeda_drv.c:149:12: error: 
'komeda_rt_pm_suspend' defined but not used [-Werror=unused-function]
 static int komeda_rt_pm_suspend(struct device *dev)
^~~~

Fixes: efb465088518 ("drm/komeda: Add runtime_pm support")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index ea5cd1e17304..e7933930a657 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -146,14 +146,14 @@ static const struct of_device_id komeda_of_match[] = {
 
 MODULE_DEVICE_TABLE(of, komeda_of_match);
 
-static int komeda_rt_pm_suspend(struct device *dev)
+static int __maybe_unused komeda_rt_pm_suspend(struct device *dev)
 {
struct komeda_drv *mdrv = dev_get_drvdata(dev);
 
return komeda_dev_suspend(mdrv->mdev);
 }
 
-static int komeda_rt_pm_resume(struct device *dev)
+static int __maybe_unused komeda_rt_pm_resume(struct device *dev)
 {
struct komeda_drv *mdrv = dev_get_drvdata(dev);
 
-- 
2.20.0

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


Re: [PATCH] drm: of: fix link error

2020-01-07 Thread Laurent Pinchart
Hi Arnd,

Thank you for the patch.

On Tue, Jan 07, 2020 at 10:37:32PM +0100, Arnd Bergmann wrote:
> The new dummy helper is non-static, so every driver gets
> its own copy, leading to a link failure:
> 
> drivers/gpu/drm/imx/imx-ldb.o: In function 
> `drm_of_lvds_get_dual_link_pixel_order':
> imx-ldb.c:(.text+0x140): multiple definition of 
> `drm_of_lvds_get_dual_link_pixel_order'
> drivers/gpu/drm/imx/imx-drm-core.o:imx-drm-core.c:(.text+0x330): first 
> defined here
> drivers/gpu/drm/imx/dw_hdmi-imx.o: In function 
> `drm_of_lvds_get_dual_link_pixel_order':
> dw_hdmi-imx.c:(.text+0xd0): multiple definition of 
> `drm_of_lvds_get_dual_link_pixel_order'
> drivers/gpu/drm/imx/imx-drm-core.o:imx-drm-core.c:(.text+0x330): first 
> defined here
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.o: In function 
> `drm_of_lvds_get_dual_link_pixel_order':
> dw-hdmi.c:(.text+0x3b90): multiple definition of 
> `drm_of_lvds_get_dual_link_pixel_order'
> drivers/gpu/drm/imx/imx-drm-core.o:imx-drm-core.c:(.text+0x330): first 
> defined here
> drivers/gpu/drm/etnaviv/etnaviv_drv.o: In function 
> `drm_of_lvds_get_dual_link_pixel_order':
> etnaviv_drv.c:(.text+0x9d0): multiple definition of 
> `drm_of_lvds_get_dual_link_pixel_order'
> drivers/gpu/drm/imx/imx-drm-core.o:imx-drm-core.c:(.text+0x330): first 
> defined here
> 
> Add the missing 'static' keyword.
> 
> Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
> Signed-off-by: Arnd Bergmann 

I've sent "[PATCH] drm: of: Fix linking when CONFIG_OF is not set" to
fix this issue, back on December the 19th. Daniel, Dave, could you pick
this up ? It couldn't be merged through drm-misc last time we checked as
the offending patch wasn't there.

> ---
>  include/drm/drm_of.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 8ec7ca6d2369..3398be966021 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -92,7 +92,7 @@ static inline int drm_of_find_panel_or_bridge(const struct 
> device_node *np,
>   return -EINVAL;
>  }
>  
> -int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
> +static inline int drm_of_lvds_get_dual_link_pixel_order(const struct 
> device_node *port1,
> const struct device_node *port2)
>  {
>   return -EINVAL;

-- 
Regards,

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


[PATCH] drm: meson: fix address type confusion

2020-01-07 Thread Arnd Bergmann
Casting a pointer to dma_addr_t produces a warning:

drivers/gpu/drm/meson/meson_rdma.c: In function 'meson_rdma_free':
drivers/gpu/drm/meson/meson_rdma.c:59:25: error: cast from pointer to integer 
of different size [-Werror=pointer-to-int-cast]
  priv->rdma.addr_phys = (dma_addr_t)NULL;

In this case, it's worse because the variable name has the suffix
'_phys', which often indicates a phys_addr_t rather than dma_addr_t,
i.e. yet another incompatible type.

Change it to use consistent naming and avoid NULL.

Fixes: 63fba242c464 ("drm/meson: add RDMA module driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/meson/meson_drv.h  |  2 +-
 drivers/gpu/drm/meson/meson_rdma.c | 12 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.h 
b/drivers/gpu/drm/meson/meson_drv.h
index f9a0c8e9d4d0..04fdf3826643 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -135,7 +135,7 @@ struct meson_drm {
} venc;
 
struct {
-   dma_addr_t addr_phys;
+   dma_addr_t addr_dma;
uint32_t *addr;
unsigned int offset;
} rdma;
diff --git a/drivers/gpu/drm/meson/meson_rdma.c 
b/drivers/gpu/drm/meson/meson_rdma.c
index 25b34b1e72a7..130382178c63 100644
--- a/drivers/gpu/drm/meson/meson_rdma.c
+++ b/drivers/gpu/drm/meson/meson_rdma.c
@@ -27,7 +27,7 @@ int meson_rdma_init(struct meson_drm *priv)
/* Allocate a PAGE buffer */
priv->rdma.addr =
dma_alloc_coherent(priv->dev, SZ_4K,
-  >rdma.addr_phys,
+  >rdma.addr_dma,
   GFP_KERNEL);
if (!priv->rdma.addr)
return -ENOMEM;
@@ -47,16 +47,16 @@ int meson_rdma_init(struct meson_drm *priv)
 
 void meson_rdma_free(struct meson_drm *priv)
 {
-   if (!priv->rdma.addr && !priv->rdma.addr_phys)
+   if (!priv->rdma.addr && !priv->rdma.addr_dma)
return;
 
meson_rdma_stop(priv);
 
dma_free_coherent(priv->dev, SZ_4K,
- priv->rdma.addr, priv->rdma.addr_phys);
+ priv->rdma.addr, priv->rdma.addr_dma);
 
priv->rdma.addr = NULL;
-   priv->rdma.addr_phys = (dma_addr_t)NULL;
+   priv->rdma.addr_dma = (dma_addr_t)0;
 }
 
 void meson_rdma_setup(struct meson_drm *priv)
@@ -118,11 +118,11 @@ void meson_rdma_flush(struct meson_drm *priv)
meson_rdma_stop(priv);
 
/* Start of Channel 1 register writes buffer */
-   writel(priv->rdma.addr_phys,
+   writel(priv->rdma.addr_dma,
   priv->io_base + _REG(RDMA_AHB_START_ADDR_1));
 
/* Last byte on Channel 1 register writes buffer */
-   writel(priv->rdma.addr_phys + (priv->rdma.offset * RDMA_DESC_SIZE) - 1,
+   writel(priv->rdma.addr_dma + (priv->rdma.offset * RDMA_DESC_SIZE) - 1,
   priv->io_base + _REG(RDMA_AHB_END_ADDR_1));
 
/* Trigger Channel 1 on VSYNC event */
-- 
2.20.0

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


[PATCH] drm: of: fix link error

2020-01-07 Thread Arnd Bergmann
The new dummy helper is non-static, so every driver gets
its own copy, leading to a link failure:

drivers/gpu/drm/imx/imx-ldb.o: In function 
`drm_of_lvds_get_dual_link_pixel_order':
imx-ldb.c:(.text+0x140): multiple definition of 
`drm_of_lvds_get_dual_link_pixel_order'
drivers/gpu/drm/imx/imx-drm-core.o:imx-drm-core.c:(.text+0x330): first defined 
here
drivers/gpu/drm/imx/dw_hdmi-imx.o: In function 
`drm_of_lvds_get_dual_link_pixel_order':
dw_hdmi-imx.c:(.text+0xd0): multiple definition of 
`drm_of_lvds_get_dual_link_pixel_order'
drivers/gpu/drm/imx/imx-drm-core.o:imx-drm-core.c:(.text+0x330): first defined 
here
drivers/gpu/drm/bridge/synopsys/dw-hdmi.o: In function 
`drm_of_lvds_get_dual_link_pixel_order':
dw-hdmi.c:(.text+0x3b90): multiple definition of 
`drm_of_lvds_get_dual_link_pixel_order'
drivers/gpu/drm/imx/imx-drm-core.o:imx-drm-core.c:(.text+0x330): first defined 
here
drivers/gpu/drm/etnaviv/etnaviv_drv.o: In function 
`drm_of_lvds_get_dual_link_pixel_order':
etnaviv_drv.c:(.text+0x9d0): multiple definition of 
`drm_of_lvds_get_dual_link_pixel_order'
drivers/gpu/drm/imx/imx-drm-core.o:imx-drm-core.c:(.text+0x330): first defined 
here

Add the missing 'static' keyword.

Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
Signed-off-by: Arnd Bergmann 
---
 include/drm/drm_of.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 8ec7ca6d2369..3398be966021 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -92,7 +92,7 @@ static inline int drm_of_find_panel_or_bridge(const struct 
device_node *np,
return -EINVAL;
 }
 
-int drm_of_lvds_get_dual_link_pixel_order(const struct device_node *port1,
+static inline int drm_of_lvds_get_dual_link_pixel_order(const struct 
device_node *port1,
  const struct device_node *port2)
 {
return -EINVAL;
-- 
2.20.0

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


[PATCH] drm: panel: fix excessive stack usage in td028ttec1_prepare

2020-01-07 Thread Arnd Bergmann
With gcc -O3, the compiler can inline very aggressively,
leading to rather large stack usage:

drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function 'td028ttec1_prepare':
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c:233:1: error: the frame size of 
2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
 }

Marking jbt_reg_write_1() as noinline avoids the case where
multiple instances of this function get inlined into the same
stack frame and each one adds a copy of 'tx_buf'.

Fixes: mmtom ("init/Kconfig: enable -O3 for all arches")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c 
b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
index cf29405a2dbe..17ee5e87141f 100644
--- a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
@@ -105,7 +105,7 @@ static int jbt_ret_write_0(struct td028ttec1_panel *lcd, u8 
reg, int *err)
return ret;
 }
 
-static int jbt_reg_write_1(struct td028ttec1_panel *lcd,
+static int noinline_for_stack jbt_reg_write_1(struct td028ttec1_panel *lcd,
   u8 reg, u8 data, int *err)
 {
struct spi_device *spi = lcd->spi;
-- 
2.20.0

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


[radeon-alex:amd-19.50 1794/2680] cc1: fatal error: dkms/config/config.h: No such file or directory

2020-01-07 Thread kbuild test robot
Hi Flora,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head:   f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01 [1794/2680] 
drm/amdkcl/autoconf: generate config.h for in-tree build
config: x86_64-randconfig-h003-20200107 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 4d49aa8a40ceecfd8a6b2d4e1b86396fbeedbb01
# 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 >>):

>> cc1: fatal error: dkms/config/config.h: No such file or directory
   compilation terminated.

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


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


[PATCH] drm/drm_panel: fix export of drm_panel_of_backlight, try #3

2020-01-07 Thread Arnd Bergmann
Making this IS_REACHABLE() was still wrong, as that just determines
whether the lower-level backlight code would be reachable from the panel
driver. However, with CONFIG_DRM=y and CONFIG_BACKLIGHT_CLASS_DEVICE=m,
the drm_panel_of_backlight is left out of drm_panel.o but the condition
tells the driver that it is there, leading to multiple link errors such as

ERROR: "drm_panel_of_backlight" 
[drivers/gpu/drm/panel/panel-sitronix-st7701.ko] undefined!
ERROR: "drm_panel_of_backlight" 
[drivers/gpu/drm/panel/panel-sharp-ls043t1le01.ko] undefined!
ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-seiko-43wvf1g.ko] 
undefined!
ERROR: "drm_panel_of_backlight" [drivers/gpu/drm/panel/panel-ronbo-rb070d30.ko] 
undefined!
ERROR: "drm_panel_of_backlight" 
[drivers/gpu/drm/panel/panel-rocktech-jh057n00900.ko] undefined!
ERROR: "drm_panel_of_backlight" 
[drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.ko] undefined!
ERROR: "drm_panel_of_backlight" 
[drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.ko] undefined!

Change the condition to check for whether the function was actually part
of the drm module. This version of the patch survived a few hundred
randconfig builds, so I have a good feeling this might be the last
one for the export.

Fixes: 4a34a9dcec94 ("drm/drm_panel: Fix EXPORT of drm_panel_of_backlight() one 
more time")
Fixes: 907aa265fde6 ("drm/drm_panel: fix EXPORT of drm_panel_of_backlight")
Fixes: 152dbdeab1b2 ("drm/panel: add backlight support")
Signed-off-by: Arnd Bergmann 
---
 include/drm/drm_panel.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 121f7aabccd1..6193cb555acc 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -198,7 +198,8 @@ static inline struct drm_panel *of_drm_find_panel(const 
struct device_node *np)
 }
 #endif
 
-#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
+#if IS_ENABLED(CONFIG_DRM_PANEL) && (IS_BUILTIN(CONFIG_BACKLIGHT_CLASS_DEVICE) 
|| \
+   (IS_MODULE(CONFIG_DRM) && IS_MODULE(CONFIG_BACKLIGHT_CLASS_DEVICE)))
 int drm_panel_of_backlight(struct drm_panel *panel);
 #else
 static inline int drm_panel_of_backlight(struct drm_panel *panel)
-- 
2.20.0

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


[PATCH] drm: msm: Quiet down plane errors in atomic_check

2020-01-07 Thread John Stultz
With the db845c running AOSP, I see the following error on every
frame on the home screen:
  [drm:dpu_plane_atomic_check:915] [dpu error]plane33 invalid src 
2880x1620+0+470 line:2560

This is due to the error paths in atomic_check using
DPU_ERROR_PLANE(), and the drm_hwcomposer using atomic_check
to decide how to composite the frame (thus it expects to see
atomic_check to fail).

In order to avoid spamming the logs, this patch converts the
DPU_ERROR_PLANE() calls to DPU_DEBUG_PLANE() calls in
atomic_check.

Cc: Todd Kjos 
Cc: Alistair Delva 
Cc: Amit Pundir 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 58d5acbcfc5c..d19ae0b51d1c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -858,7 +858,7 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
  pdpu->pipe_sblk->maxupscale << 16,
  true, true);
if (ret) {
-   DPU_ERROR_PLANE(pdpu, "Check plane state failed (%d)\n", ret);
+   DPU_DEBUG_PLANE(pdpu, "Check plane state failed (%d)\n", ret);
return ret;
}
if (!state->visible)
@@ -884,13 +884,13 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
(!(pdpu->features & DPU_SSPP_SCALER) ||
 !(pdpu->features & (BIT(DPU_SSPP_CSC)
 | BIT(DPU_SSPP_CSC_10BIT) {
-   DPU_ERROR_PLANE(pdpu,
+   DPU_DEBUG_PLANE(pdpu,
"plane doesn't have scaler/csc for yuv\n");
return -EINVAL;
 
/* check src bounds */
} else if (!dpu_plane_validate_src(, _rect, min_src_size)) {
-   DPU_ERROR_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
+   DPU_DEBUG_PLANE(pdpu, "invalid source " DRM_RECT_FMT "\n",
DRM_RECT_ARG());
return -E2BIG;
 
@@ -899,19 +899,19 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
   (src.x1 & 0x1 || src.y1 & 0x1 ||
drm_rect_width() & 0x1 ||
drm_rect_height() & 0x1)) {
-   DPU_ERROR_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
+   DPU_DEBUG_PLANE(pdpu, "invalid yuv source " DRM_RECT_FMT "\n",
DRM_RECT_ARG());
return -EINVAL;
 
/* min dst support */
} else if (drm_rect_width() < 0x1 || drm_rect_height() < 0x1) {
-   DPU_ERROR_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
+   DPU_DEBUG_PLANE(pdpu, "invalid dest rect " DRM_RECT_FMT "\n",
DRM_RECT_ARG());
return -EINVAL;
 
/* check decimated source width */
} else if (drm_rect_width() > max_linewidth) {
-   DPU_ERROR_PLANE(pdpu, "invalid src " DRM_RECT_FMT " line:%u\n",
+   DPU_DEBUG_PLANE(pdpu, "invalid src " DRM_RECT_FMT " line:%u\n",
DRM_RECT_ARG(), max_linewidth);
return -E2BIG;
}
-- 
2.17.1

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


Re: [PATCH v2 2/2] dt-bindings: one file of all simple DSI panels

2020-01-07 Thread Rob Herring
On Thu, Jan 2, 2020 at 4:17 AM Sam Ravnborg  wrote:
>
> To complement panel-simple.yaml, create panel-simple-dsi.yaml.
> panel-simple-dsi-yaml are for all simple DSP panels with a single
> power-supply and optional backlight / enable GPIO.
>
> Migrate panasonic,vvx10f034n00 over to the new file.
>
> The objectives with one file for all the simple DSI panels are:
> - Make it simpler to add bindings for simple DSI panels
> - Keep the number of bindings file lower
> - Keep the binding documentation for simple DSI panels more consistent
>
> Signed-off-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Rob Herring 
> Cc: Maxime Ripard 
> Cc: Yannick Fertre 
> Cc: Mark Rutland 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: devicet...@vger.kernel.org
> ---
>  .../display/panel/panasonic,vvx10f034n00.txt  | 20 --
>  .../display/panel/panel-simple-dsi.yaml   | 67 +++
>  2 files changed, 67 insertions(+), 20 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml

Reviewed-by: Rob Herring 

>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt 
> b/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> deleted file mode 100644
> index 37dedf6a6702..
> --- 
> a/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -Panasonic 10" WUXGA TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "panasonic,vvx10f034n00"
> -- reg: DSI virtual channel of the peripheral
> -- power-supply: phandle of the regulator that provides the supply voltage
> -
> -Optional properties:
> -- backlight: phandle of the backlight device attached to the panel
> -
> -Example:
> -
> -   mdss_dsi@fd922800 {
> -   panel@0 {
> -   compatible = "panasonic,vvx10f034n00";
> -   reg = <0>;
> -   power-supply = <_vsp>;
> -   backlight = <_wled>;
> -   };
> -   };
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> new file mode 100644
> index ..05c52390269e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> @@ -0,0 +1,67 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-simple-dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Simple DSI panels with a single power-supply
> +
> +maintainers:
> +  - Thierry Reding 
> +  - Sam Ravnborg 
> +
> +description: |
> +  This binding file is a collection of the DSI panels that
> +  requires only a single power-supply.
> +  There are optionally a backlight and an enable GPIO.
> +  The panel may use an OF graph binding for the association to the display,
> +  or it may be a direct child node of the display.
> +
> +  If the panel is more advanced a dedicated binding file is required.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +
> +  compatible:
> +enum:
> +# compatible must be listed in alphabetical order, ordered by compatible.
> +# The description in the comment is mandatory for each compatible.

To answer your irc question, this is fine. You could do it like this instead:

oneOf:
  - description: ...
const: compat-string
  - description: ...
const: compat-string-2

The advantage is being able to extract 'description' if say you wanted
to generate documentation. Even so, I somewhat prefer how you have it.

> +
> +# Panasonic 10" WUXGA TFT LCD panel

I'd align the # with the string to keep the list '-' a bit more
visible. IOW, 2 more spaces (before my next comment).

> +- panasonic,vvx10f034n00

This should be indented 2 more spaces.

BTW, I extracted all the panels from my patch with this:

git show | grep -E '(title|const)' | sed -e 's/\+title:/  #/' -e 's/+
  const:/\-/'

There's a few with more than just 'title'.

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


Re: [PATCH v2 1/2] dt-bindings: one binding file for all simple panels

2020-01-07 Thread Rob Herring
On Thu, Jan 2, 2020 at 4:17 AM Sam Ravnborg  wrote:
>
> There is an increasing number of new simple panels.
> Common for many of these simple panels are that they have one
> mandatory power-supply and some of them have backlight and / or
> an enable gpio.
>
> The binding file to describe these panels adds overhead
> that really do not add value.
> The binding are known and there is nothing gained from a
> dedicated binding file nor for any dedicated example.
>
> The following patch introduces a single panel-simple.yaml
> and converts two ampire bindings over to the new file.
>
> The conversion - if applied will have following effects:
>
> - The maintainer for the individual file will change
> There is no need for many different maintainers for a simple binding.
> We have the same situation with the panel-simple driver in the kernel.
>
> - The license will change to (GPL-2.0-only OR BSD-2-Clause)
> There is usually only a single line copied from the original
> file, a line that is often copied from a datasheet.
> This license change should be acceptable considered what little
> is copied.
> If the license change is not OK we can use a dedicated binding
> file in these cases.
>
> This is a follow-up on Rob's big patch converting a lot of panel bindings
> to individual files:
>
> "dt-bindings: display: Convert a bunch of panels to DT schema"
> https://patchwork.ozlabs.org/patch/1197683/
>
> The objectives with one file for the relevant simple panels are:
> - Make it simpler to add bindings for simple panels
> - Keep the number of bindings file lower and thus easier to find a
>   relevant file to copy from when adding new panels.
> - Keep the binding documentation for simple panels more consistent
> - Make it simpler to add support for new panels
>
> v2:
>   - spelling fixes (imirkin via irc, Rob)
>   - updated description (Rob)
>   - list properires in alphabetical order
>   - added power-supply to example (Rob)
>   - updated title
>   - reworded changelog a little
>
> Signed-off-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Rob Herring 
> Cc: Maxime Ripard 
> Cc: Yannick Fertre 
> Cc: Mark Rutland 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Cc: devicet...@vger.kernel.org
> ---
>  .../panel/ampire,am-480272h3tmqw-t01h.yaml| 42 -
>  .../panel/ampire,am800480r3tmqwa1h.txt|  7 ---
>  .../bindings/display/panel/panel-simple.yaml  | 59 +++
>  3 files changed, 59 insertions(+), 49 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-simple.yaml

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


[PATCH v2 5/5] Revert "drm/bridge: Add a drm_bridge_state object"

2020-01-07 Thread Boris Brezillon
This reverts commit 6ed7e9625fa6 ("drm/bridge: Add a drm_bridge_state
object") which introduced a circular dependency between drm.ko and
drm_kms_helper.ko. Looks like the helper/core split is not appropriate
and fixing that is not simple.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_atomic.c|  39 
 drivers/gpu/drm/drm_atomic_helper.c |  20 
 drivers/gpu/drm/drm_bridge.c| 139 ++--
 include/drm/drm_atomic.h|   3 -
 include/drm/drm_bridge.h| 114 ---
 5 files changed, 6 insertions(+), 309 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index bf1b9c37d515..d33691512a8e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,7 +30,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1018,44 +1017,6 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
connector->funcs->atomic_print_state(p, state);
 }
 
-/**
- * drm_atomic_add_encoder_bridges - add bridges attached to an encoder
- * @state: atomic state
- * @encoder: DRM encoder
- *
- * This function adds all bridges attached to @encoder. This is needed to add
- * bridge states to @state and make them available when
- * _funcs.atomic_{check,pre_enable,enable,disable_post_disable}() are
- * called
- *
- * Returns:
- * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
- * then the w/w mutex code has detected a deadlock and the entire atomic
- * sequence must be restarted. All other errors are fatal.
- */
-int
-drm_atomic_add_encoder_bridges(struct drm_atomic_state *state,
-  struct drm_encoder *encoder)
-{
-   struct drm_bridge_state *bridge_state;
-   struct drm_bridge *bridge;
-
-   if (!encoder)
-   return 0;
-
-   DRM_DEBUG_ATOMIC("Adding all bridges for [encoder:%d:%s] to %p\n",
-encoder->base.id, encoder->name, state);
-
-   drm_for_each_bridge_in_chain(encoder, bridge) {
-   bridge_state = drm_atomic_get_bridge_state(state, bridge);
-   if (IS_ERR(bridge_state))
-   return PTR_ERR(bridge_state);
-   }
-
-   return 0;
-}
-EXPORT_SYMBOL(drm_atomic_add_encoder_bridges);
-
 /**
  * drm_atomic_add_affected_connectors - add connectors for CRTC
  * @state: atomic state
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ad8eae98d9e8..4511c2e07bb9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -730,26 +730,6 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
return ret;
}
 
-   /*
-* Iterate over all connectors again, and add all affected bridges to
-* the state.
-*/
-   for_each_oldnew_connector_in_state(state, connector,
-  old_connector_state,
-  new_connector_state, i) {
-   struct drm_encoder *encoder;
-
-   encoder = old_connector_state->best_encoder;
-   ret = drm_atomic_add_encoder_bridges(state, encoder);
-   if (ret)
-   return ret;
-
-   encoder = new_connector_state->best_encoder;
-   ret = drm_atomic_add_encoder_bridges(state, encoder);
-   if (ret)
-   return ret;
-   }
-
ret = mode_valid(state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index a213c9042f2c..c2cf0c90fa26 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
@@ -90,74 +89,6 @@ void drm_bridge_remove(struct drm_bridge *bridge)
 }
 EXPORT_SYMBOL(drm_bridge_remove);
 
-static struct drm_bridge_state *
-drm_atomic_default_bridge_duplicate_state(struct drm_bridge *bridge)
-{
-   struct drm_bridge_state *new;
-
-   if (WARN_ON(!bridge->base.state))
-   return NULL;
-
-   new = kzalloc(sizeof(*new), GFP_KERNEL);
-   if (new)
-   __drm_atomic_helper_bridge_duplicate_state(bridge, new);
-
-   return new;
-}
-
-static struct drm_private_state *
-drm_bridge_atomic_duplicate_priv_state(struct drm_private_obj *obj)
-{
-   struct drm_bridge *bridge = drm_priv_to_bridge(obj);
-   struct drm_bridge_state *state;
-
-   if (bridge->funcs->atomic_duplicate_state)
-   state = bridge->funcs->atomic_duplicate_state(bridge);
-   else
-   state = drm_atomic_default_bridge_duplicate_state(bridge);
-
-   return state ? >base : NULL;
-}
-
-static void
-drm_atomic_default_bridge_destroy_state(struct drm_bridge *bridge,
-   struct drm_bridge_state *state)
-{
-  

[PATCH v2 1/5] Revert "drm/bridge: Fix a NULL pointer dereference in drm_atomic_bridge_chain_check()"

2020-01-07 Thread Boris Brezillon
This reverts commit b18398c16e17 ("drm/bridge: Fix a NULL pointer
dereference in drm_atomic_bridge_chain_check()"). Commit 6ed7e9625fa6
("drm/bridge: Add a drm_bridge_state object") introduced a circular
dependency between drm.ko and drm_kms_helper.ko which uncovered a
misdesign in how the whole thing was implemented. Let's revert all
patches depending on the bridge_state infrastructure for now.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_bridge.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 32d43bfeeca1..37400607e9b7 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -938,19 +938,15 @@ int drm_atomic_bridge_chain_check(struct drm_bridge 
*bridge,
  struct drm_connector_state *conn_state)
 {
struct drm_connector *conn = conn_state->connector;
-   struct drm_encoder *encoder;
+   struct drm_encoder *encoder = bridge->encoder;
struct drm_bridge *iter;
int ret;
 
-   if (!bridge)
-   return 0;
-
ret = drm_atomic_bridge_chain_select_bus_fmts(bridge, crtc_state,
  conn_state);
if (ret)
return ret;
 
-   encoder = bridge->encoder;
list_for_each_entry_reverse(iter, >bridge_chain, chain_node) {
int ret;
 
-- 
2.23.0

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


[PATCH v2 2/5] Revert "drm/bridge: Add the necessary bits to support bus format negotiation"

2020-01-07 Thread Boris Brezillon
This reverts commit e351e4d5eaec ("drm/bridge: Add the necessary bits
to support bus format negotiation"). Commit 6ed7e9625fa6 ("drm/bridge:
Add a drm_bridge_state object") introduced a circular dependency
between drm.ko and drm_kms_helper.ko which uncovered a misdesign in
how the whole thing was implemented. Let's revert all patches depending
on the bridge_state infrastructure for now.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_bridge.c | 267 +--
 include/drm/drm_bridge.h | 124 
 2 files changed, 1 insertion(+), 390 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 37400607e9b7..8e4b799150b0 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -671,261 +671,13 @@ static int drm_atomic_bridge_check(struct drm_bridge 
*bridge,
return 0;
 }
 
-/**
- * drm_atomic_helper_bridge_propagate_bus_fmt() - Propagate output format to
- *   the input end of a bridge
- * @bridge: bridge control structure
- * @bridge_state: new bridge state
- * @crtc_state: new CRTC state
- * @conn_state: new connector state
- * @output_fmt: tested output bus format
- * @num_input_fmts: will contain the size of the returned array
- *
- * This helper is a pluggable implementation of the
- * _bridge_funcs.atomic_get_input_bus_fmts operation for bridges that don't
- * modify the bus configuration between their input and their output. It
- * returns an array of input formats with a single element set to @output_fmt.
- *
- * RETURNS:
- * a valid format array of size @num_input_fmts, or NULL if the allocation
- * failed
- */
-u32 *
-drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
-   struct drm_bridge_state *bridge_state,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state,
-   u32 output_fmt,
-   unsigned int *num_input_fmts)
-{
-   u32 *input_fmts;
-
-   input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
-   if (!input_fmts) {
-   *num_input_fmts = 0;
-   return NULL;
-   }
-
-   *num_input_fmts = 1;
-   input_fmts[0] = output_fmt;
-   return input_fmts;
-}
-EXPORT_SYMBOL(drm_atomic_helper_bridge_propagate_bus_fmt);
-
-static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
-   struct drm_bridge *cur_bridge,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state,
-   u32 out_bus_fmt)
-{
-   struct drm_bridge_state *cur_state;
-   unsigned int num_in_bus_fmts, i;
-   struct drm_bridge *prev_bridge;
-   u32 *in_bus_fmts;
-   int ret;
-
-   prev_bridge = drm_bridge_get_prev_bridge(cur_bridge);
-   cur_state = drm_atomic_get_new_bridge_state(crtc_state->state,
-   cur_bridge);
-   if (WARN_ON(!cur_state))
-   return -EINVAL;
-
-   /*
-* If bus format negotiation is not supported by this bridge, let's
-* pass MEDIA_BUS_FMT_FIXED to the previous bridge in the chain and
-* hope that it can handle this situation gracefully (by providing
-* appropriate default values).
-*/
-   if (!cur_bridge->funcs->atomic_get_input_bus_fmts) {
-   if (cur_bridge != first_bridge) {
-   ret = select_bus_fmt_recursive(first_bridge,
-  prev_bridge, crtc_state,
-  conn_state,
-  MEDIA_BUS_FMT_FIXED);
-   if (ret)
-   return ret;
-   }
-
-   cur_state->input_bus_cfg.format = MEDIA_BUS_FMT_FIXED;
-   cur_state->output_bus_cfg.format = out_bus_fmt;
-   return 0;
-   }
-
-   in_bus_fmts = cur_bridge->funcs->atomic_get_input_bus_fmts(cur_bridge,
-   cur_state,
-   crtc_state,
-   conn_state,
-   out_bus_fmt,
-   _in_bus_fmts);
-   if (!num_in_bus_fmts)
-   return -ENOTSUPP;
-   else if (!in_bus_fmts)
-   return -ENOMEM;
-
-   if (first_bridge == cur_bridge) {
-   cur_state->input_bus_cfg.format = in_bus_fmts[0];
-   cur_state->output_bus_cfg.format = out_bus_fmt;
-   kfree(in_bus_fmts);
- 

[PATCH v2 0/5] drm/bridge: Revert all bridge_state related changes

2020-01-07 Thread Boris Brezillon
Hello

Sorry for the noise. I realize the v1 didn't contain any explanation
about why those commits were reverted and were missing my SoB.

The addition of a bridge_state object introduced a circular dependency
between drm.ko and drm_kms_helper.ko which uncovered a misdesign in how
the whole thing was implemented. Let's revert all patches for now.

Regards,

Boris

P.S.: Daniel, I'd appreciate if you could find some time to look at the
patch series introducing the faulty patches [1]. Those have been
reviewed by Laurent and Neil who didn't seem to notice the problem you
reported (improper core/helper separation and improper use of atomic
helpers from the core). I don't know if Laurent and Neil were aware of
these rule, but I definitely wasn't. I'm pretty sure it's clearly
stated somewhere in the doc, so it's likely all my fault (RTFM).
To sum-up, I'm no denying my responsibility in this mess and I'm fine
taking the blame for not noticing the regression before pushing
those patches to drm-misc-next and for not reading the doc, but this
also proves one thing: no matter how good the doc is, we need reviews
from those who design/drive the subsystem (AKA you) if we want to catch
such design issues before merging things. And I'm not talking about
regressions that can be detected/reported with a good CI infrastructure
here (though we definitely want a good CI too :-)).

[1]https://patchwork.freedesktop.org/series/64915/

Boris Brezillon (5):
  Revert "drm/bridge: Fix a NULL pointer dereference in
drm_atomic_bridge_chain_check()"
  Revert "drm/bridge: Add the necessary bits to support bus format
negotiation"
  Revert "drm/bridge: Add an ->atomic_check() hook"
  Revert "drm/bridge: Patch atomic hooks to take a drm_bridge_state"
  Revert "drm/bridge: Add a drm_bridge_state object"

 .../drm/bridge/analogix/analogix_dp_core.c|  41 +-
 drivers/gpu/drm/drm_atomic.c  |  39 --
 drivers/gpu/drm/drm_atomic_helper.c   |  32 +-
 drivers/gpu/drm/drm_bridge.c  | 531 +-
 drivers/gpu/drm/rcar-du/rcar_lvds.c   |   8 +-
 include/drm/drm_atomic.h  |   3 -
 include/drm/drm_bridge.h  | 275 +
 7 files changed, 49 insertions(+), 880 deletions(-)

-- 
2.23.0

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


[PATCH v2 4/5] Revert "drm/bridge: Patch atomic hooks to take a drm_bridge_state"

2020-01-07 Thread Boris Brezillon
This reverts commit f7619a58ef92 ("drm/bridge: Patch atomic hooks to
take a drm_bridge_state"). Commit 6ed7e9625fa6 ("drm/bridge: Add a
drm_bridge_state object") introduced a circular dependency between
drm.ko and drm_kms_helper.ko which uncovered a misdesign in how the
whole thing was implemented. Let's revert all patches depending on the
bridge_state infrastructure for now.

Signed-off-by: Boris Brezillon 
---
 .../drm/bridge/analogix/analogix_dp_core.c| 41 ++---
 drivers/gpu/drm/drm_bridge.c  | 61 ---
 drivers/gpu/drm/rcar-du/rcar_lvds.c   |  8 +--
 include/drm/drm_bridge.h  |  8 +--
 4 files changed, 36 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6fab71985cd4..6effe532f820 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1289,21 +1289,19 @@ struct drm_crtc *analogix_dp_get_new_crtc(struct 
analogix_dp_device *dp,
return conn_state->crtc;
 }
 
-static void
-analogix_dp_bridge_atomic_pre_enable(struct drm_bridge *bridge,
-struct drm_bridge_state *old_bridge_state)
+static void analogix_dp_bridge_atomic_pre_enable(struct drm_bridge *bridge,
+struct drm_atomic_state *state)
 {
-   struct drm_atomic_state *old_state = old_bridge_state->base.state;
struct analogix_dp_device *dp = bridge->driver_private;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
int ret;
 
-   crtc = analogix_dp_get_new_crtc(dp, old_state);
+   crtc = analogix_dp_get_new_crtc(dp, state);
if (!crtc)
return;
 
-   old_crtc_state = drm_atomic_get_old_crtc_state(old_state, crtc);
+   old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc);
/* Don't touch the panel if we're coming back from PSR */
if (old_crtc_state && old_crtc_state->self_refresh_active)
return;
@@ -1368,22 +1366,20 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
return ret;
 }
 
-static void
-analogix_dp_bridge_atomic_enable(struct drm_bridge *bridge,
-struct drm_bridge_state *old_bridge_state)
+static void analogix_dp_bridge_atomic_enable(struct drm_bridge *bridge,
+struct drm_atomic_state *state)
 {
-   struct drm_atomic_state *old_state = old_bridge_state->base.state;
struct analogix_dp_device *dp = bridge->driver_private;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
int timeout_loop = 0;
int ret;
 
-   crtc = analogix_dp_get_new_crtc(dp, old_state);
+   crtc = analogix_dp_get_new_crtc(dp, state);
if (!crtc)
return;
 
-   old_crtc_state = drm_atomic_get_old_crtc_state(old_state, crtc);
+   old_crtc_state = drm_atomic_get_old_crtc_state(state, crtc);
/* Not a full enable, just disable PSR and continue */
if (old_crtc_state && old_crtc_state->self_refresh_active) {
ret = analogix_dp_disable_psr(dp);
@@ -1444,20 +1440,18 @@ static void analogix_dp_bridge_disable(struct 
drm_bridge *bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
-static void
-analogix_dp_bridge_atomic_disable(struct drm_bridge *bridge,
- struct drm_bridge_state *old_bridge_state)
+static void analogix_dp_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state)
 {
-   struct drm_atomic_state *old_state = old_bridge_state->base.state;
struct analogix_dp_device *dp = bridge->driver_private;
struct drm_crtc *crtc;
struct drm_crtc_state *new_crtc_state = NULL;
 
-   crtc = analogix_dp_get_new_crtc(dp, old_state);
+   crtc = analogix_dp_get_new_crtc(dp, state);
if (!crtc)
goto out;
 
-   new_crtc_state = drm_atomic_get_new_crtc_state(old_state, crtc);
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
if (!new_crtc_state)
goto out;
 
@@ -1469,21 +1463,20 @@ analogix_dp_bridge_atomic_disable(struct drm_bridge 
*bridge,
analogix_dp_bridge_disable(bridge);
 }
 
-static void
-analogix_dp_bridge_atomic_post_disable(struct drm_bridge *bridge,
-   struct drm_bridge_state *old_bridge_state)
+static
+void analogix_dp_bridge_atomic_post_disable(struct drm_bridge *bridge,
+   struct drm_atomic_state *state)
 {
-   struct drm_atomic_state *old_state = old_bridge_state->base.state;
struct analogix_dp_device *dp = bridge->driver_private;
struct drm_crtc *crtc;
struct drm_crtc_state *new_crtc_state;

[PATCH v2 3/5] Revert "drm/bridge: Add an ->atomic_check() hook"

2020-01-07 Thread Boris Brezillon
This reverts commit b86d895524ab ("drm/bridge: Add an ->atomic_check()
hook"). Commit 6ed7e9625fa6 ("drm/bridge: Add a drm_bridge_state
object") introduced a circular dependency between drm.ko and
drm_kms_helper.ko which uncovered a misdesign in how the whole thing
was implemented. Let's revert all patches depending on the bridge_state
infrastructure for now.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 +++---
 drivers/gpu/drm/drm_bridge.c| 62 -
 include/drm/drm_bridge.h| 29 +-
 3 files changed, 7 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index afe14f72a824..ad8eae98d9e8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -437,12 +437,12 @@ mode_fixup(struct drm_atomic_state *state)
funcs = encoder->helper_private;
 
bridge = drm_bridge_chain_get_first_bridge(encoder);
-   ret = drm_atomic_bridge_chain_check(bridge,
-   new_crtc_state,
-   new_conn_state);
-   if (ret) {
-   DRM_DEBUG_ATOMIC("Bridge atomic check failed\n");
-   return ret;
+   ret = drm_bridge_chain_mode_fixup(bridge,
+   _crtc_state->mode,
+   _crtc_state->adjusted_mode);
+   if (!ret) {
+   DRM_DEBUG_ATOMIC("Bridge fixup failed\n");
+   return -EINVAL;
}
 
if (funcs && funcs->atomic_check) {
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 8e4b799150b0..872e159fcb42 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -645,68 +645,6 @@ void drm_atomic_bridge_chain_enable(struct drm_bridge 
*bridge,
 }
 EXPORT_SYMBOL(drm_atomic_bridge_chain_enable);
 
-static int drm_atomic_bridge_check(struct drm_bridge *bridge,
-  struct drm_crtc_state *crtc_state,
-  struct drm_connector_state *conn_state)
-{
-   if (bridge->funcs->atomic_check) {
-   struct drm_bridge_state *bridge_state;
-   int ret;
-
-   bridge_state = 
drm_atomic_get_new_bridge_state(crtc_state->state,
-  bridge);
-   if (WARN_ON(!bridge_state))
-   return -EINVAL;
-
-   ret = bridge->funcs->atomic_check(bridge, bridge_state,
- crtc_state, conn_state);
-   if (ret)
-   return ret;
-   } else if (bridge->funcs->mode_fixup) {
-   if (!bridge->funcs->mode_fixup(bridge, _state->mode,
-  _state->adjusted_mode))
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
-/**
- * drm_atomic_bridge_chain_check() - Do an atomic check on the bridge chain
- * @bridge: bridge control structure
- * @crtc_state: new CRTC state
- * @conn_state: new connector state
- *
- * Calls _bridge_funcs.atomic_check() (falls back on
- * _bridge_funcs.mode_fixup()) op for all the bridges in the encoder chain,
- * starting from the last bridge to the first. These are called before calling
- * _encoder_helper_funcs.atomic_check()
- *
- * RETURNS:
- * 0 on success, a negative error code on failure
- */
-int drm_atomic_bridge_chain_check(struct drm_bridge *bridge,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state)
-{
-   struct drm_encoder *encoder = bridge->encoder;
-   struct drm_bridge *iter;
-
-   list_for_each_entry_reverse(iter, >bridge_chain, chain_node) {
-   int ret;
-
-   ret = drm_atomic_bridge_check(iter, crtc_state, conn_state);
-   if (ret)
-   return ret;
-
-   if (iter == bridge)
-   break;
-   }
-
-   return 0;
-}
-EXPORT_SYMBOL(drm_atomic_bridge_chain_check);
-
 /**
  * __drm_atomic_helper_bridge_reset() - Initialize a bridge state to its
  * default
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index ae0595c70132..52d3ed150618 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -128,9 +128,7 @@ struct drm_bridge_funcs {
 * this function passes all other callbacks must succeed for this
 * configuration.
 *
-* The mode_fixup callback is optional. _bridge_funcs.mode_fixup()
-* is not called when _bridge_funcs.atomic_check() is implemented,
-* so only one of them should be provided.
+* The 

Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ

2020-01-07 Thread Ville Syrjälä
On Tue, Dec 31, 2019 at 03:30:47AM +, Lin, Wayne wrote:
> [AMD Official Use Only - Internal Distribution Only]
> 
> > 
> > From: Jani Nikula 
> > Sent: Monday, December 30, 2019 19:15
> > To: Lin, Wayne; dri-devel@lists.freedesktop.org; 
> > amd-...@lists.freedesktop.org
> > Cc: Zuo, Jerry; Kazlauskas, Nicholas; Lin, Wayne
> > Subject: Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
> >
> > On Mon, 30 Dec 2019, Wayne Lin  wrote:
> > > [Why]
> > > According to DP spec, it should shift left 4 digits for NO_STOP_BIT
> > > in REMOTE_I2C_READ message. Not 5 digits.
> > >
> > > [How]
> > > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
> > > drm_dp_encode_sideband_req().
> >
> > Which commit introduced the issue? Fixes: tag. Does it need a stable
> > backport? Does this fix a user visible bug?
> >
> > BR,
> > Jani.
> >
> Thanks for your time and reminder.
> 
> It seems like the issue has been there since very beginning.(commit: ad7f8a1).
> It doesn't introduce user visible bug under my test cases, but this affects 
> the I2C signal
> between I2C master and I2C slave. Not pretty sure if there is any eeprom will 
> reset
> the written offset once received I2C stop. If so, that might cause wrongly 
> reading EDID.
> I will Cc to stable. Thanks.

The segment address should be reset on STOP. So large EDIDs should
fail. IIRC we had a bug report of some sort about this which I tried
to fix by confgiuring .no_stop_bit correctly, but apparently I failed
to double check that the bit get stuffed onto the wire correctly.

Ah yes, https://bugs.freedesktop.org/show_bug.cgi?id=108081
So you may have just fixed that one, although we seem to have closed
it already.

> > > Signed-off-by: Wayne Lin 
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 1d1bfa49ca2b..0557e225ff67 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct 
> > > drm_dp_sideband_msg_req_body *req,
> > >   memcpy([idx], 
> > > req->u.i2c_read.transactions[i].bytes, 
> > > req->u.i2c_read.transactions[i].num_bytes);
> > >   idx += req->u.i2c_read.transactions[i].num_bytes;
> > >
> > > - buf[idx] = 
> > > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5;
> > > + buf[idx] = 
> > > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4;
> > >   buf[idx] |= 
> > > (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf);
> > >   idx++;
> > >   }
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> --
> Wayne Lin
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [PATCH v3] phy: Add DisplayPort configuration options

2020-01-07 Thread Jyri Sarha
On 06/01/2020 14:22, Yuti Amonkar wrote:
> Allow DisplayPort PHYs to be configured through the generic
> functions through a custom structure added to the generic union.
> The configuration structure is used for reconfiguration of
> DisplayPort PHYs during link training operation.
> 
> The parameters added here are the ones defined in the DisplayPort
> spec v1.4 which include link rate, number of lanes, voltage swing
> and pre-emphasis.
> 
> Add the DisplayPort phy mode to the generic phy_mode enum.
> 
> Signed-off-by: Yuti Amonkar 

Reviewed-by: Jyri Sarha 

Kishon, can you still pick this for v5.6?

Best regards,
Jyri

> ---
> 
> Version History:
> v3:
>  Add DisplayPort mode to the generic phy_mode enum.
> 
> v2:
>  Update DisplayPort spec version in the commit message.
> 
> This patch was a part of [1] series earlier but we think that it needs
> to have a separate attention of the reviewers. Also as both [1] & [2] are
> dependent on this patch, our sincere request to reviewers to have a
> faster review of this patch.
> 
> [1]
> 
> https://lkml.org/lkml/2019/12/23/392
> 
> [2]
> 
> https://lkml.org/lkml/2019/12/23/394
> 
>  include/linux/phy/phy-dp.h | 95 
> ++
>  include/linux/phy/phy.h|  7 +++-
>  2 files changed, 101 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/phy/phy-dp.h
> 
> diff --git a/include/linux/phy/phy-dp.h b/include/linux/phy/phy-dp.h
> new file mode 100644
> index 000..18cad23
> --- /dev/null
> +++ b/include/linux/phy/phy-dp.h
> @@ -0,0 +1,95 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019 Cadence Design Systems Inc.
> + */
> +
> +#ifndef __PHY_DP_H_
> +#define __PHY_DP_H_
> +
> +#include 
> +
> +/**
> + * struct phy_configure_opts_dp - DisplayPort PHY configuration set
> + *
> + * This structure is used to represent the configuration state of a
> + * DisplayPort phy.
> + */
> +struct phy_configure_opts_dp {
> + /**
> +  * @link_rate:
> +  *
> +  * Link Rate, in Mb/s, of the main link.
> +  *
> +  * Allowed values: 1620, 2160, 2430, 2700, 3240, 4320, 5400, 8100 Mb/s
> +  */
> + unsigned int link_rate;
> +
> + /**
> +  * @lanes:
> +  *
> +  * Number of active, consecutive, data lanes, starting from
> +  * lane 0, used for the transmissions on main link.
> +  *
> +  * Allowed values: 1, 2, 4
> +  */
> + unsigned int lanes;
> +
> + /**
> +  * @voltage:
> +  *
> +  * Voltage swing levels, as specified by DisplayPort specification,
> +  * to be used by particular lanes. One value per lane.
> +  * voltage[0] is for lane 0, voltage[1] is for lane 1, etc.
> +  *
> +  * Maximum value: 3
> +  */
> + unsigned int voltage[4];
> +
> + /**
> +  * @pre:
> +  *
> +  * Pre-emphasis levels, as specified by DisplayPort specification, to be
> +  * used by particular lanes. One value per lane.
> +  *
> +  * Maximum value: 3
> +  */
> + unsigned int pre[4];
> +
> + /**
> +  * @ssc:
> +  *
> +  * Flag indicating, whether or not to enable spread-spectrum clocking.
> +  *
> +  */
> + u8 ssc : 1;
> +
> + /**
> +  * @set_rate:
> +  *
> +  * Flag indicating, whether or not reconfigure link rate and SSC to
> +  * requested values.
> +  *
> +  */
> + u8 set_rate : 1;
> +
> + /**
> +  * @set_lanes:
> +  *
> +  * Flag indicating, whether or not reconfigure lane count to
> +  * requested value.
> +  *
> +  */
> + u8 set_lanes : 1;
> +
> + /**
> +  * @set_voltages:
> +  *
> +  * Flag indicating, whether or not reconfigure voltage swing
> +  * and pre-emphasis to requested values. Only lanes specified
> +  * by "lanes" parameter will be affected.
> +  *
> +  */
> + u8 set_voltages : 1;
> +};
> +
> +#endif /* __PHY_DP_H_ */
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 15032f14..962a469 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  struct phy;
> @@ -38,7 +39,8 @@ enum phy_mode {
>   PHY_MODE_PCIE,
>   PHY_MODE_ETHERNET,
>   PHY_MODE_MIPI_DPHY,
> - PHY_MODE_SATA
> + PHY_MODE_SATA,
> + PHY_MODE_DP
>  };
>  
>  /**
> @@ -46,9 +48,12 @@ enum phy_mode {
>   *
>   * @mipi_dphy:   Configuration set applicable for phys supporting
>   *   the MIPI_DPHY phy mode.
> + * @dp:  Configuration set applicable for phys supporting
> + *   the DisplayPort protocol.
>   */
>  union phy_configure_opts {
>   struct phy_configure_opts_mipi_dphy mipi_dphy;
> + struct phy_configure_opts_dpdp;
>  };
>  
>  /**
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v2] drm/dp_mst: clear time slots for ports invalid

2020-01-07 Thread Sasha Levin
Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v5.4.8, v4.19.93, v4.14.162, v4.9.208, 
v4.4.208.

v5.4.8: Failed to apply! Possible dependencies:
14692a3637d4 ("drm/dp_mst: Add probe_lock")
37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit")
3f9b3f02dda5 ("drm/dp_mst: Protect drm_dp_mst_port members with locking")
50094b5dcd32 ("drm/dp_mst: Destroy topology_mgr mutexes")
5950f0b797fc ("drm/dp_mst: Move link address dumping into a function")
60f9ae9d0d3d ("drm/dp_mst: Remove huge conditional in 
drm_dp_mst_handle_up_req()")
7cb12d48314e ("drm/dp_mst: Destroy MSTBs asynchronously")
9408cc94eb04 ("drm/dp_mst: Handle UP requests asynchronously")
a29d881875fc ("drm/dp_mst: Refactor drm_dp_mst_handle_up_req()")
c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
caf81ec6cd72 ("drm: Destroy the correct mutex name in 
drm_dp_mst_topology_mgr_destroy")
dad7d84f8835 ("drm/dp_mst: Don't forget to update port->input in 
drm_dp_mst_handle_conn_stat()")
e2839ff692c6 ("drm/dp_mst: Rename drm_dp_add_port and drm_dp_update_port")

v4.19.93: Failed to apply! Possible dependencies:
1e55a53a28d3 ("drm: Trivial comment grammar cleanups")
706246c761dd ("drm/dp_mst: Refactor drm_dp_update_payload_part1()")
72fdb40c1a4b ("drm: extract drm_atomic_uapi.c")
7f4de521001f ("drm/atomic: Add __drm_atomic_helper_plane_reset")
a5ec8332d428 ("drm: Add per-plane pixel blend mode property")
c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
d0757afd00d7 ("drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref 
and friends")
d86552efe10a ("drm/atomic: trim driver interface/docs")
dad7d84f8835 ("drm/dp_mst: Don't forget to update port->input in 
drm_dp_mst_handle_conn_stat()")
de9f8eea5a44 ("drm/atomic_helper: Stop modesets on unregistered connectors 
harder")
ebcc0e6b5091 ("drm/dp_mst: Introduce new refcounting scheme for mstbs and 
ports")
fc63668656bd ("drm/dp_mst: Remove bogus conditional in 
drm_dp_update_payload_part1()")

v4.14.162: Failed to apply! Possible dependencies:
0bb9c2b27f5e ("drm/dp/mst: Sideband message transaction to power up/down 
nodes")
163bcc2c74a2 ("drm/atomic: Move drm_crtc_commit to drm_crtc_state, v4.")
179c02fe90a4 ("drm/tve200: Add new driver for TVE200")
1e55a53a28d3 ("drm: Trivial comment grammar cleanups")
21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by 
tracking commits, v3.")
22a07038c0ea ("drm: NULL pointer dereference [null-pointer-deref] (CWE 476) 
problem")
24557865c8b1 ("drm: Add Content Protection property")
2ed077e467ee ("drm: Add drm_object lease infrastructure [v5]")
34ca26a98ad6 ("drm/atomic_helper: Allow DPMS On<->Off changes for 
unregistered connectors")
0d4cf21b ("drm: add connector info/property for non-desktop displays 
[v2]")
6d544fd6f4e1 ("drm/doc: Put all driver docs into a separate chapter")
706246c761dd ("drm/dp_mst: Refactor drm_dp_update_payload_part1()")
72fdb40c1a4b ("drm: extract drm_atomic_uapi.c")
8d70f395e6cb ("drm: Add support for a panel-orientation connector property, 
v6")
935774cd71fe ("drm: Add writeback connector type")
c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
c76f0f7cb546 ("drm: Begin an API for in-kernel clients")
d0757afd00d7 ("drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref 
and friends")
dad7d84f8835 ("drm/dp_mst: Don't forget to update port->input in 
drm_dp_mst_handle_conn_stat()")
de9f8eea5a44 ("drm/atomic_helper: Stop modesets on unregistered connectors 
harder")
e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered 
connectors")
ebcc0e6b5091 ("drm/dp_mst: Introduce new refcounting scheme for mstbs and 
ports")
fc63668656bd ("drm/dp_mst: Remove bogus conditional in 
drm_dp_update_payload_part1()")

v4.9.208: Failed to apply! Possible dependencies:
0bb9c2b27f5e ("drm/dp/mst: Sideband message transaction to power up/down 
nodes")
1cec20f0ea0e ("dma-buf: Restart reservation_object_wait_timeout_rcu() after 
writes")
3f3353b7e121 ("drm/dp: Introduce MST topology state to track available link 
bandwidth")
6806cdf9aa1c ("drm/kms-helpers: Use recommened kerneldoc for struct member 
refs")
78010cd9736e ("dma-buf/fence: add an lockdep_assert_held()")
9498c19b3f53 ("drm: Move tile group code into drm_connector.c")
9a83a71ac0d5 ("drm/fences: add DOC: for explicit fencing")
beaf5af48034 ("drm/fence: add out-fences support")
c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
d0757afd00d7 ("drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref 
and friends")
d807ed1c55fb ("drm: atomic: 

Re: [GIT PULL] Immutable branch between MFD and DRM due for the v5.6 merge window

2020-01-07 Thread Sam Ravnborg
Hi Maarten.

On Tue, Jan 07, 2020 at 10:17:48AM +, Lee Jones wrote:
> The MFD parts for testing:
> 
> The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
> 
>   Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> tags/ib-mfd-drm-v5.6
> 
> for you to fetch changes up to 10f9167664362bac6f44813687cf52fec9d15845:
> 
>   mfd: atmel-hlcdc: Return in case of error (2020-01-07 10:08:58 +)
> 
> 
> Immutable branch between MFD and DRM due for the v5.6 merge window
> 
> 
> Claudiu Beznea (2):
>   mfd: atmel-hlcdc: Add struct device member to struct atmel_hlcdc_regmap
>   mfd: atmel-hlcdc: Return in case of error
> 
>  drivers/mfd/atmel-hlcdc.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)

Can we get this into drm-misc-next?

I am not familiar with the process how to do this, and hope you can
help.

Thanks in advance,

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


Re: [PATCH v2 2/2] drm/print: document DRM_ logging functions

2020-01-07 Thread Sam Ravnborg
Hi Daniel.

> > + * Logging when a  * is available, but no _device *
> > + * 
> > ~
> > + *
> > + * DRM/Drivers can use the following functions for logging when there is a
> > + * struct device * available.
> > + * The logging functions share the same prototype:
> 
> I'd replace the entire block with a "This stuff is deprecated" warning. We
> have at least a corresponding todo.rst entry.

We have many situations where no drm_device is available.
At least when you a buried in drm_panel patches.

So it is either DRM_DEV_ERROR() or drv_err().
Which is why I have pushed for nicer drm_ variants of these...

The todo entry only covers the nice new macros that Jani added
where we have a drm_device.

Sam



> -Daniel
> 
> > + *
> > + * .. code-block:: c
> > + *
> > + *   void DRM_xxx(struct device *, char * fmt, ...)
> > + *
> > + * .. code-block:: none
> > + *
> > + *   # Plain logging
> > + *   DRM_DEV_INFO(dev, fmt, ...)
> > + *   DRM_DEV_ERROR(dev, fmt, ...)
> > + *
> > + *   # Log only once
> > + *   DRM_DEV_INFO_ONCE(dev, fmt, ...)
> > + *
> > + *   # Ratelimited - do not flood the logs
> > + *   DRM_DEV_DEBUG_RATELIMITED(dev, fmt, ...)
> > + *   DRM_DEV_DEBUG_DRIVER_RATELIMITED(dev, fmt, ...)
> > + *   DRM_DEV_DEBUG_KMS_RATELIMITED(dev, fmt, ...)
> > + *   DRM_DEV_DEBUG_PRIME_RATELIMITED(dev, fmt, ...)
> > + *   DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...)
> > + *
> > + *   # Logging with a specific category
> > + *   DRM_DEV_DEBUG(dev, fmt, ...)  # Logged as CORE
> > + *   DRM_DEV_DEBUG_DRIVER(dev, fmt, ...)
> > + *   DRM_DEV_DEBUG_KMS(dev, fmt, ...)
> > + *   DRM_DEV_DEBUG_PRIME(dev, fmt, ...)
> > + *   DRM_DEV_DEBUG_ATOMIC(dev, fmt, ...)
> > + *   DRM_DEV_DEBUG_VBL(dev, fmt, ...)
> > + *   DRM_DEV_DEBUG_DP(dev, fmt, ...)
> > + *
> > + * Logging when no  * nor _device * is available
> > + * 
> > 
> > + *
> > + * DRM/Drivers can use the following functions for logging when there is no
> > + * extra info associated to the logging.
> > + * The logging functions share the same prototype:
> > + *
> > + * .. code-block:: c
> > + *
> > + *   void DRM_xxx(char * fmt, ...)
> > + *
> > + * .. code-block:: none
> > + *
> > + *   # Plain logging
> > + *   DRM_INFO(fmt, ...)
> > + *   DRM_NOTE(fmt, ...)
> > + *   DRM_WARN(fmt, ...)
> > + *   DRM_ERROR(fmt, ...)
> > + *
> > + *   # Log only once
> > + *   DRM_INFO_ONCE(fmt, ...)
> > + *   DRM_NOTE_ONCE(fmt, ...)
> > + *   DRM_WARN_ONCE(fmt, ...)
> > + *
> > + *   # Ratelimited - do not flood the logs
> > + *   DRM_DEBUG_RATELIMITED(fmt, ...)
> > + *   DRM_DEBUG_DRIVER_RATELIMITED(fmt, ...)
> > + *   DRM_DEBUG_KMS_RATELIMITED(fmt, ...)
> > + *   DRM_DEBUG_PRIME_RATELIMITED(fmt, ...)
> > + *   DRM_ERROR_RATELIMITED(fmt, ...)
> > + *
> > + *   # Logging with a specific category
> > + *   DRM_DEBUG(fmt, ...)   # Logged as CORE
> > + *   DRM_DEBUG_DRIVER(fmt, ...)
> > + *   DRM_DEBUG_KMS(fmt, ...)
> > + *   DRM_DEBUG_PRIME(fmt, ...)
> > + *   DRM_DEBUG_ATOMIC(fmt, ...)
> > + *   DRM_DEBUG_VBL(fmt, ...)
> > + *   DRM_DEBUG_LEASE(fmt, ...)
> > + *   DRM_DEBUG_DP(fmt, ...)
> >   */
> >  
> >  /**
> > @@ -399,7 +475,7 @@ __printf(3, 4)
> >  void drm_dev_dbg(const struct device *dev, enum drm_debug_category 
> > category,
> >  const char *format, ...);
> >  
> > -/**
> > +/*
> >   * Error output.
> >   *
> >   * @dev: device pointer
> > @@ -408,7 +484,7 @@ void drm_dev_dbg(const struct device *dev, enum 
> > drm_debug_category category,
> >  #define DRM_DEV_ERROR(dev, fmt, ...)   
> > \
> > drm_dev_printk(dev, KERN_ERR, "*ERROR* " fmt, ##__VA_ARGS__)
> >  
> > -/**
> > +/*
> >   * Rate limited error output.  Like DRM_ERROR() but won't flood the log.
> >   *
> >   * @dev: device pointer
> > @@ -436,7 +512,7 @@ void drm_dev_dbg(const struct device *dev, enum 
> > drm_debug_category category,
> > }   \
> >  })
> >  
> > -/**
> > +/*
> >   * Debug output.
> >   *
> >   * @dev: device pointer
> > @@ -466,7 +542,7 @@ void drm_dev_dbg(const struct device *dev, enum 
> > drm_debug_category category,
> > drm_dev_dbg(dev, category, fmt, ##__VA_ARGS__); \
> >  })
> >  
> > -/**
> > +/*
> >   * Rate limited debug output. Like DRM_DEBUG() but won't flood the log.
> >   *
> >   * @dev: device pointer
> > -- 
> > 2.20.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 v2 1/2] drm/sun4i: backend: Make sure we enforce the clock rate

2020-01-07 Thread Chen-Yu Tsai
On Wed, Jan 8, 2020 at 1:00 AM Maxime Ripard  wrote:
>
> The backend needs to run at 300MHz to be functional. This was done so far
> using assigned-clocks in the device tree, but that is easy to forget, and
> dosen't provide any other guarantee than the rate is going to be roughly
> the one requested at probe time.
>
> Therefore it's pretty fragile, so let's just use the exclusive clock API to
> enforce it.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/2] drm/sun4i: drc: Make sure we enforce the clock rate

2020-01-07 Thread Chen-Yu Tsai
On Wed, Jan 8, 2020 at 1:00 AM Maxime Ripard  wrote:
>
> The DRC needs to run at 300MHz to be functional. This was done so far
> using assigned-clocks in the device tree, but that is easy to forget, and
> dosen't provide any other guarantee than the rate is going to be roughly
> the one requested at probe time.
>
> Therefore it's pretty fragile, so let's just use the exclusive clock API to
> enforce it.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFT 06/13] arc: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Arnd Bergmann
On Tue, Jan 7, 2020 at 5:54 PM Krzysztof Kozlowski  wrote:
>
> The ioreadX() helpers have inconsistent interface.  On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the
> address so they can be converted to a "const" version for const-safety
> and consistency among architectures.
>
> Signed-off-by: Krzysztof Kozlowski 

The patch looks correct, but I would not bother here, as it has no
effect on the compiler or its output.

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


Re: [RFT 03/13] sh: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Arnd Bergmann
On Tue, Jan 7, 2020 at 5:54 PM Krzysztof Kozlowski  wrote:
>
> The ioreadX() helpers have inconsistent interface.  On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Signed-off-by: Krzysztof Kozlowski 

The patch looks good, but I think this has to be done together with the powerpc
version and the header that declares the function, for bisectibility.

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


Re: [PATCH v2 2/2] dt-bindings: one file of all simple DSI panels

2020-01-07 Thread Rob Herring
On Tue, Jan 7, 2020 at 9:44 AM Benjamin Gaignard
 wrote:
>
> Le jeu. 2 janv. 2020 à 11:17, Sam Ravnborg  a écrit :
> >
> > To complement panel-simple.yaml, create panel-simple-dsi.yaml.
> > panel-simple-dsi-yaml are for all simple DSP panels with a single
> > power-supply and optional backlight / enable GPIO.
> >
> > Migrate panasonic,vvx10f034n00 over to the new file.
> >
> > The objectives with one file for all the simple DSI panels are:
> > - Make it simpler to add bindings for simple DSI panels
> > - Keep the number of bindings file lower
> > - Keep the binding documentation for simple DSI panels more consistent
> >
> > Signed-off-by: Sam Ravnborg 
> > Cc: Thierry Reding 
> > Cc: Rob Herring 
> > Cc: Maxime Ripard 
> > Cc: Yannick Fertre 
> > Cc: Mark Rutland 
> > Cc: Daniel Vetter 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: devicet...@vger.kernel.org
> > ---
> >  .../display/panel/panasonic,vvx10f034n00.txt  | 20 --
> >  .../display/panel/panel-simple-dsi.yaml   | 67 +++
> >  2 files changed, 67 insertions(+), 20 deletions(-)
> >  delete mode 100644 
> > Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> >  
> > b/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> > deleted file mode 100644
> > index 37dedf6a6702..
> > --- 
> > a/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> > +++ /dev/null
> > @@ -1,20 +0,0 @@
> > -Panasonic 10" WUXGA TFT LCD panel
> > -
> > -Required properties:
> > -- compatible: should be "panasonic,vvx10f034n00"
> > -- reg: DSI virtual channel of the peripheral
> > -- power-supply: phandle of the regulator that provides the supply voltage
> > -
> > -Optional properties:
> > -- backlight: phandle of the backlight device attached to the panel
> > -
> > -Example:
> > -
> > -   mdss_dsi@fd922800 {
> > -   panel@0 {
> > -   compatible = "panasonic,vvx10f034n00";
> > -   reg = <0>;
> > -   power-supply = <_vsp>;
> > -   backlight = <_wled>;
> > -   };
> > -   };
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml 
> > b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> > new file mode 100644
> > index ..05c52390269e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> > @@ -0,0 +1,67 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/panel-simple-dsi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Simple DSI panels with a single power-supply
> > +
> > +maintainers:
> > +  - Thierry Reding 
> > +  - Sam Ravnborg 
> > +
> > +description: |
> > +  This binding file is a collection of the DSI panels that
> > +  requires only a single power-supply.
> > +  There are optionally a backlight and an enable GPIO.
> > +  The panel may use an OF graph binding for the association to the display,
> > +  or it may be a direct child node of the display.
> > +
> > +  If the panel is more advanced a dedicated binding file is required.
> > +
> > +allOf:
> > +  - $ref: panel-common.yaml#
> > +
> > +properties:
> > +
> > +  compatible:
> > +enum:
> > +# compatible must be listed in alphabetical order, ordered by 
> > compatible.
> > +# The description in the comment is mandatory for each compatible.
> > +
> > +# Panasonic 10" WUXGA TFT LCD panel
> > +- panasonic,vvx10f034n00
>
> Hi Sam,
>
> I have tested your patch with these 2 dsi panels:
> # Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD
>   - orisetech,otm8009a
>  # Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
>- raydium,rm68200
>
> It is close to be fine for me but I have minors comments below.
>
> Benjamin
>
> > +
> > +  reg:
> > +maxItems: 1
> > +description: DSI virtual channel
> > +
> > +  backlight: true
> > +  enable-gpios: true
> > +  port: true
> > +  power-supply: true
>
> add reset-gpios: true to support orisetech panel

Nope. If not a single GPIO and single supply, not a simple panel.

Maybe reset could be allowed, but we have to draw the line somewhere.

> > +
> > +additionalProperties: false
> > +
> > +required:
> > +  - compatible
> > +  - power-supply
>
> power-supply should optional

The panel works without power? The dts should have a fixed supply if
not controllable.

Here's the problem. If it is not required, then panels with multiple
supplies will get added here because they didn't care to begin with.
Then when someone decides to think about the supplies it will have to
be moved. Bindings need 

[RFT 12/13] ntb: intel: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/ntb/hw/intel/ntb_hw_gen1.c  | 2 +-
 drivers/ntb/hw/intel/ntb_hw_gen3.h  | 2 +-
 drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c 
b/drivers/ntb/hw/intel/ntb_hw_gen1.c
index bb57ec239029..9202502a9787 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen1.c
+++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c
@@ -1202,7 +1202,7 @@ int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int 
pidx, int sidx,
   ndev->peer_reg->spad);
 }
 
-static u64 xeon_db_ioread(void __iomem *mmio)
+static u64 xeon_db_ioread(const void __iomem *mmio)
 {
return (u64)ioread16(mmio);
 }
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen3.h 
b/drivers/ntb/hw/intel/ntb_hw_gen3.h
index 75fb86ca27bb..d1455f24ec99 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen3.h
+++ b/drivers/ntb/hw/intel/ntb_hw_gen3.h
@@ -91,7 +91,7 @@
 #define GEN3_DB_TOTAL_SHIFT33
 #define GEN3_SPAD_COUNT16
 
-static inline u64 gen3_db_ioread(void __iomem *mmio)
+static inline u64 gen3_db_ioread(const void __iomem *mmio)
 {
return ioread64(mmio);
 }
diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.h 
b/drivers/ntb/hw/intel/ntb_hw_intel.h
index e071e28bca3f..3c0a5a2da241 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.h
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.h
@@ -102,7 +102,7 @@ struct intel_ntb_dev;
 struct intel_ntb_reg {
int (*poll_link)(struct intel_ntb_dev *ndev);
int (*link_is_up)(struct intel_ntb_dev *ndev);
-   u64 (*db_ioread)(void __iomem *mmio);
+   u64 (*db_ioread)(const void __iomem *mmio);
void (*db_iowrite)(u64 db_bits, void __iomem *mmio);
unsigned long   ntb_ctl;
resource_size_t db_size;
-- 
2.7.4

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


[RFT 11/13] net: wireless: rtl818x: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h 
b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
index 7948a2da195a..2ff00800d45b 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
@@ -150,17 +150,17 @@ void rtl8180_write_phy(struct ieee80211_hw *dev, u8 addr, 
u32 data);
 void rtl8180_set_anaparam(struct rtl8180_priv *priv, u32 anaparam);
 void rtl8180_set_anaparam2(struct rtl8180_priv *priv, u32 anaparam2);
 
-static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, u8 __iomem *addr)
+static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, const u8 __iomem 
*addr)
 {
return ioread8(addr);
 }
 
-static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, __le16 __iomem 
*addr)
+static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, const __le16 
__iomem *addr)
 {
return ioread16(addr);
 }
 
-static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, __le32 __iomem 
*addr)
+static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, const __le32 
__iomem *addr)
 {
return ioread32(addr);
 }
-- 
2.7.4

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


[RFT 13/13] virtio: pci: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/virtio/virtio_pci_modern.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/virtio/virtio_pci_modern.c 
b/drivers/virtio/virtio_pci_modern.c
index 7abcc50838b8..fc58db4ab6c3 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -26,16 +26,16 @@
  * method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses
  * for 16-bit fields and 8-bit accesses for 8-bit fields.
  */
-static inline u8 vp_ioread8(u8 __iomem *addr)
+static inline u8 vp_ioread8(const u8 __iomem *addr)
 {
return ioread8(addr);
 }
-static inline u16 vp_ioread16 (__le16 __iomem *addr)
+static inline u16 vp_ioread16 (const __le16 __iomem *addr)
 {
return ioread16(addr);
 }
 
-static inline u32 vp_ioread32(__le32 __iomem *addr)
+static inline u32 vp_ioread32(const __le32 __iomem *addr)
 {
return ioread32(addr);
 }
-- 
2.7.4

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


[RFT 06/13] arc: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the
address so they can be converted to a "const" version for const-safety
and consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arc/plat-axs10x/axs10x.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index 63ea5a606ecd..180c260a8221 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -84,7 +84,7 @@ static void __init axs10x_print_board_ver(unsigned int creg, 
const char *str)
unsigned int val;
} board;
 
-   board.val = ioread32((void __iomem *)creg);
+   board.val = ioread32((const void __iomem *)creg);
pr_info("AXS: %s FPGA Date: %u-%u-%u\n", str, board.d, board.m,
board.y);
 }
@@ -95,7 +95,7 @@ static void __init axs10x_early_init(void)
char mb[32];
 
/* Determine motherboard version */
-   if (ioread32((void __iomem *) CREG_MB_CONFIG) & (1 << 28))
+   if (ioread32((const void __iomem *) CREG_MB_CONFIG) & (1 << 28))
mb_rev = 3; /* HT-3 (rev3.0) */
else
mb_rev = 2; /* HT-2 (rev2.0) */
-- 
2.7.4

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


[RFT 07/13] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/mgag200/mgag200_drv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h 
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index aa32aad222c2..6512b3af4fb7 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -34,9 +34,9 @@
 
 #define MGAG200FB_CONN_LIMIT 1
 
-#define RREG8(reg) ioread8(((void __iomem *)mdev->rmmio) + (reg))
+#define RREG8(reg) ioread8(((const void __iomem *)mdev->rmmio) + (reg))
 #define WREG8(reg, v) iowrite8(v, ((void __iomem *)mdev->rmmio) + (reg))
-#define RREG32(reg) ioread32(((void __iomem *)mdev->rmmio) + (reg))
+#define RREG32(reg) ioread32(((const void __iomem *)mdev->rmmio) + (reg))
 #define WREG32(reg, v) iowrite32(v, ((void __iomem *)mdev->rmmio) + (reg))
 
 #define ATTR_INDEX 0x1fc0
-- 
2.7.4

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


[RFT 10/13] net: wireless: ath5k: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/net/wireless/ath/ath5k/ahb.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/ahb.c 
b/drivers/net/wireless/ath/ath5k/ahb.c
index 2c9cec8b53d9..8bd01df369fb 100644
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ b/drivers/net/wireless/ath/ath5k/ahb.c
@@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
 
if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
/* Enable WMAC AHB arbitration */
-   reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
+   reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
reg |= AR5K_AR2315_AHB_ARB_CTL_WLAN;
iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
 
/* Enable global WMAC swapping */
-   reg = ioread32((void __iomem *) AR5K_AR2315_BYTESWAP);
+   reg = ioread32((const void __iomem *) AR5K_AR2315_BYTESWAP);
reg |= AR5K_AR2315_BYTESWAP_WMAC;
iowrite32(reg, (void __iomem *) AR5K_AR2315_BYTESWAP);
} else {
/* Enable WMAC DMA access (assuming 5312 or 231x*/
/* TODO: check other platforms */
-   reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
+   reg = ioread32((const void __iomem *) AR5K_AR5312_ENABLE);
if (to_platform_device(ah->dev)->id == 0)
reg |= AR5K_AR5312_ENABLE_WLAN0;
else
@@ -202,12 +202,12 @@ static int ath_ahb_remove(struct platform_device *pdev)
 
if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
/* Disable WMAC AHB arbitration */
-   reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
+   reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
reg &= ~AR5K_AR2315_AHB_ARB_CTL_WLAN;
iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
} else {
/*Stop DMA access */
-   reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
+   reg = ioread32((const void __iomem *) AR5K_AR5312_ENABLE);
if (to_platform_device(ah->dev)->id == 0)
reg &= ~AR5K_AR5312_ENABLE_WLAN0;
else
-- 
2.7.4

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


[RFT 08/13] drm/nouveau: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index f8015e0318d7..5120d062c2df 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -613,7 +613,7 @@ nouveau_bo_rd32(struct nouveau_bo *nvbo, unsigned index)
mem += index;
 
if (is_iomem)
-   return ioread32_native((void __force __iomem *)mem);
+   return ioread32_native((const void __force __iomem *)mem);
else
return *mem;
 }
-- 
2.7.4

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


[RFT 09/13] media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/media/platform/fsl-viu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 81a8faedbba6..991d9dc82749 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -34,7 +34,7 @@
 /* Allow building this driver with COMPILE_TEST */
 #if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE)
 #define out_be32(v, a) iowrite32be(a, (void __iomem *)v)
-#define in_be32(a) ioread32be((void __iomem *)a)
+#define in_be32(a) ioread32be((const void __iomem *)a)
 #endif
 
 #define BUFFER_TIMEOUT msecs_to_jiffies(500)  /* 0.5 seconds */
-- 
2.7.4

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


[RFT 05/13] powerpc: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/powerpc/kernel/iomap.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index 5ac84efc6ede..de8da1c3496f 100644
--- a/arch/powerpc/kernel/iomap.c
+++ b/arch/powerpc/kernel/iomap.c
@@ -15,23 +15,23 @@
  * Here comes the ppc64 implementation of the IOMAP 
  * interfaces.
  */
-unsigned int ioread8(void __iomem *addr)
+unsigned int ioread8(const void __iomem *addr)
 {
return readb(addr);
 }
-unsigned int ioread16(void __iomem *addr)
+unsigned int ioread16(const void __iomem *addr)
 {
return readw(addr);
 }
-unsigned int ioread16be(void __iomem *addr)
+unsigned int ioread16be(const void __iomem *addr)
 {
return readw_be(addr);
 }
-unsigned int ioread32(void __iomem *addr)
+unsigned int ioread32(const void __iomem *addr)
 {
return readl(addr);
 }
-unsigned int ioread32be(void __iomem *addr)
+unsigned int ioread32be(const void __iomem *addr)
 {
return readl_be(addr);
 }
@@ -41,27 +41,27 @@ EXPORT_SYMBOL(ioread16be);
 EXPORT_SYMBOL(ioread32);
 EXPORT_SYMBOL(ioread32be);
 #ifdef __powerpc64__
-u64 ioread64(void __iomem *addr)
+u64 ioread64(const void __iomem *addr)
 {
return readq(addr);
 }
-u64 ioread64_lo_hi(void __iomem *addr)
+u64 ioread64_lo_hi(const void __iomem *addr)
 {
return readq(addr);
 }
-u64 ioread64_hi_lo(void __iomem *addr)
+u64 ioread64_hi_lo(const void __iomem *addr)
 {
return readq(addr);
 }
-u64 ioread64be(void __iomem *addr)
+u64 ioread64be(const void __iomem *addr)
 {
return readq_be(addr);
 }
-u64 ioread64be_lo_hi(void __iomem *addr)
+u64 ioread64be_lo_hi(const void __iomem *addr)
 {
return readq_be(addr);
 }
-u64 ioread64be_hi_lo(void __iomem *addr)
+u64 ioread64be_hi_lo(const void __iomem *addr)
 {
return readq_be(addr);
 }
-- 
2.7.4

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


[RFT 02/13] alpha: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/alpha/include/asm/core_apecs.h  |  6 +++---
 arch/alpha/include/asm/core_cia.h|  6 +++---
 arch/alpha/include/asm/core_lca.h|  6 +++---
 arch/alpha/include/asm/core_marvel.h |  4 ++--
 arch/alpha/include/asm/core_mcpcia.h |  6 +++---
 arch/alpha/include/asm/core_t2.h |  2 +-
 arch/alpha/include/asm/io.h  | 12 ++--
 arch/alpha/include/asm/io_trivial.h  | 16 
 arch/alpha/include/asm/jensen.h  |  2 +-
 arch/alpha/include/asm/machvec.h |  6 +++---
 arch/alpha/kernel/core_marvel.c  |  2 +-
 arch/alpha/kernel/io.c   |  6 +++---
 12 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/arch/alpha/include/asm/core_apecs.h 
b/arch/alpha/include/asm/core_apecs.h
index 0a07055bc0fe..2d9726fc02ef 100644
--- a/arch/alpha/include/asm/core_apecs.h
+++ b/arch/alpha/include/asm/core_apecs.h
@@ -384,7 +384,7 @@ struct el_apecs_procdata
}   \
} while (0)
 
-__EXTERN_INLINE unsigned int apecs_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -420,7 +420,7 @@ __EXTERN_INLINE void apecs_iowrite8(u8 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int apecs_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread16(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
if (addr < APECS_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_cia.h 
b/arch/alpha/include/asm/core_cia.h
index c706a7f2b061..cb22991f6761 100644
--- a/arch/alpha/include/asm/core_cia.h
+++ b/arch/alpha/include/asm/core_cia.h
@@ -342,7 +342,7 @@ struct el_CIA_sysdata_mcheck {
 #define vuip   volatile unsigned int __force *
 #define vulp   volatile unsigned long __force *
 
-__EXTERN_INLINE unsigned int cia_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -374,7 +374,7 @@ __EXTERN_INLINE void cia_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int cia_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread16(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -404,7 +404,7 @@ __EXTERN_INLINE void cia_iowrite16(u16 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int cia_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread32(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
if (addr < CIA_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_lca.h 
b/arch/alpha/include/asm/core_lca.h
index 84d5e5b84f4f..ec86314418cb 100644
--- a/arch/alpha/include/asm/core_lca.h
+++ b/arch/alpha/include/asm/core_lca.h
@@ -230,7 +230,7 @@ union el_lca {
} while (0)
 
 
-__EXTERN_INLINE unsigned int lca_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -266,7 +266,7 @@ __EXTERN_INLINE void lca_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int lca_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread16(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -302,7 +302,7 @@ __EXTERN_INLINE void lca_iowrite16(u16 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int lca_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread32(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
if (addr < LCA_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_marvel.h 
b/arch/alpha/include/asm/core_marvel.h
index 

[RFT 03/13] alpha: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/alpha/include/asm/core_apecs.h  |  6 +++---
 arch/alpha/include/asm/core_cia.h|  6 +++---
 arch/alpha/include/asm/core_lca.h|  6 +++---
 arch/alpha/include/asm/core_marvel.h |  4 ++--
 arch/alpha/include/asm/core_mcpcia.h |  6 +++---
 arch/alpha/include/asm/core_t2.h |  2 +-
 arch/alpha/include/asm/io.h  | 12 ++--
 arch/alpha/include/asm/io_trivial.h  | 16 
 arch/alpha/include/asm/jensen.h  |  2 +-
 arch/alpha/include/asm/machvec.h |  6 +++---
 arch/alpha/kernel/core_marvel.c  |  2 +-
 arch/alpha/kernel/io.c   |  6 +++---
 12 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/arch/alpha/include/asm/core_apecs.h 
b/arch/alpha/include/asm/core_apecs.h
index 0a07055bc0fe..2d9726fc02ef 100644
--- a/arch/alpha/include/asm/core_apecs.h
+++ b/arch/alpha/include/asm/core_apecs.h
@@ -384,7 +384,7 @@ struct el_apecs_procdata
}   \
} while (0)
 
-__EXTERN_INLINE unsigned int apecs_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -420,7 +420,7 @@ __EXTERN_INLINE void apecs_iowrite8(u8 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int apecs_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread16(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
if (addr < APECS_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_cia.h 
b/arch/alpha/include/asm/core_cia.h
index c706a7f2b061..cb22991f6761 100644
--- a/arch/alpha/include/asm/core_cia.h
+++ b/arch/alpha/include/asm/core_cia.h
@@ -342,7 +342,7 @@ struct el_CIA_sysdata_mcheck {
 #define vuip   volatile unsigned int __force *
 #define vulp   volatile unsigned long __force *
 
-__EXTERN_INLINE unsigned int cia_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -374,7 +374,7 @@ __EXTERN_INLINE void cia_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int cia_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread16(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -404,7 +404,7 @@ __EXTERN_INLINE void cia_iowrite16(u16 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int cia_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread32(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
if (addr < CIA_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_lca.h 
b/arch/alpha/include/asm/core_lca.h
index 84d5e5b84f4f..ec86314418cb 100644
--- a/arch/alpha/include/asm/core_lca.h
+++ b/arch/alpha/include/asm/core_lca.h
@@ -230,7 +230,7 @@ union el_lca {
} while (0)
 
 
-__EXTERN_INLINE unsigned int lca_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread8(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -266,7 +266,7 @@ __EXTERN_INLINE void lca_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int lca_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread16(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -302,7 +302,7 @@ __EXTERN_INLINE void lca_iowrite16(u16 b, void __iomem 
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
 }
 
-__EXTERN_INLINE unsigned int lca_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread32(const void __iomem *xaddr)
 {
unsigned long addr = (unsigned long) xaddr;
if (addr < LCA_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_marvel.h 
b/arch/alpha/include/asm/core_marvel.h
index 

[RFT 04/13] parisc: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/parisc/include/asm/io.h |  4 ++--
 arch/parisc/lib/iomap.c  | 48 ++--
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
index cab8f64ca4a2..f48fb8d76e15 100644
--- a/arch/parisc/include/asm/io.h
+++ b/arch/parisc/include/asm/io.h
@@ -303,8 +303,8 @@ extern void outsl (unsigned long port, const void *src, 
unsigned long count);
 #define ioread64be ioread64be
 #define iowrite64 iowrite64
 #define iowrite64be iowrite64be
-extern u64 ioread64(void __iomem *addr);
-extern u64 ioread64be(void __iomem *addr);
+extern u64 ioread64(const void __iomem *addr);
+extern u64 ioread64be(const void __iomem *addr);
 extern void iowrite64(u64 val, void __iomem *addr);
 extern void iowrite64be(u64 val, void __iomem *addr);
 
diff --git a/arch/parisc/lib/iomap.c b/arch/parisc/lib/iomap.c
index 0195aec657e2..e01345d2a7d9 100644
--- a/arch/parisc/lib/iomap.c
+++ b/arch/parisc/lib/iomap.c
@@ -43,13 +43,13 @@
 #endif
 
 struct iomap_ops {
-   unsigned int (*read8)(void __iomem *);
-   unsigned int (*read16)(void __iomem *);
-   unsigned int (*read16be)(void __iomem *);
-   unsigned int (*read32)(void __iomem *);
-   unsigned int (*read32be)(void __iomem *);
-   u64 (*read64)(void __iomem *);
-   u64 (*read64be)(void __iomem *);
+   unsigned int (*read8)(const void __iomem *);
+   unsigned int (*read16)(const void __iomem *);
+   unsigned int (*read16be)(const void __iomem *);
+   unsigned int (*read32)(const void __iomem *);
+   unsigned int (*read32be)(const void __iomem *);
+   u64 (*read64)(const void __iomem *);
+   u64 (*read64be)(const void __iomem *);
void (*write8)(u8, void __iomem *);
void (*write16)(u16, void __iomem *);
void (*write16be)(u16, void __iomem *);
@@ -69,17 +69,17 @@ struct iomap_ops {
 
 #define ADDR2PORT(addr) ((unsigned long __force)(addr) & 0xff)
 
-static unsigned int ioport_read8(void __iomem *addr)
+static unsigned int ioport_read8(const void __iomem *addr)
 {
return inb(ADDR2PORT(addr));
 }
 
-static unsigned int ioport_read16(void __iomem *addr)
+static unsigned int ioport_read16(const void __iomem *addr)
 {
return inw(ADDR2PORT(addr));
 }
 
-static unsigned int ioport_read32(void __iomem *addr)
+static unsigned int ioport_read32(const void __iomem *addr)
 {
return inl(ADDR2PORT(addr));
 }
@@ -150,37 +150,37 @@ static const struct iomap_ops ioport_ops = {
 
 /* Legacy I/O memory ops */
 
-static unsigned int iomem_read8(void __iomem *addr)
+static unsigned int iomem_read8(const void __iomem *addr)
 {
return readb(addr);
 }
 
-static unsigned int iomem_read16(void __iomem *addr)
+static unsigned int iomem_read16(const void __iomem *addr)
 {
return readw(addr);
 }
 
-static unsigned int iomem_read16be(void __iomem *addr)
+static unsigned int iomem_read16be(const void __iomem *addr)
 {
return __raw_readw(addr);
 }
 
-static unsigned int iomem_read32(void __iomem *addr)
+static unsigned int iomem_read32(const void __iomem *addr)
 {
return readl(addr);
 }
 
-static unsigned int iomem_read32be(void __iomem *addr)
+static unsigned int iomem_read32be(const void __iomem *addr)
 {
return __raw_readl(addr);
 }
 
-static u64 iomem_read64(void __iomem *addr)
+static u64 iomem_read64(const void __iomem *addr)
 {
return readq(addr);
 }
 
-static u64 iomem_read64be(void __iomem *addr)
+static u64 iomem_read64be(const void __iomem *addr)
 {
return __raw_readq(addr);
 }
@@ -297,49 +297,49 @@ static const struct iomap_ops *iomap_ops[8] = {
 };
 
 
-unsigned int ioread8(void __iomem *addr)
+unsigned int ioread8(const void __iomem *addr)
 {
if (unlikely(INDIRECT_ADDR(addr)))
return iomap_ops[ADDR_TO_REGION(addr)]->read8(addr);
return *((u8 *)addr);
 }
 
-unsigned int ioread16(void __iomem *addr)
+unsigned int ioread16(const void __iomem *addr)
 {
if (unlikely(INDIRECT_ADDR(addr)))
return iomap_ops[ADDR_TO_REGION(addr)]->read16(addr);
return le16_to_cpup((u16 *)addr);
 }
 
-unsigned int ioread16be(void __iomem *addr)
+unsigned int ioread16be(const void __iomem *addr)
 {
if (unlikely(INDIRECT_ADDR(addr)))
return iomap_ops[ADDR_TO_REGION(addr)]->read16be(addr);
return *((u16 *)addr);
 }
 
-unsigned int ioread32(void __iomem *addr)
+unsigned int ioread32(const void __iomem *addr)
 {
if (unlikely(INDIRECT_ADDR(addr)))
return iomap_ops[ADDR_TO_REGION(addr)]->read32(addr);
  

[RFT 03/13] sh: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/sh/kernel/iomap.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sh/kernel/iomap.c b/arch/sh/kernel/iomap.c
index ef9e2c97cbb7..bd5e212c6ea6 100644
--- a/arch/sh/kernel/iomap.c
+++ b/arch/sh/kernel/iomap.c
@@ -8,31 +8,31 @@
 #include 
 #include 
 
-unsigned int ioread8(void __iomem *addr)
+unsigned int ioread8(const void __iomem *addr)
 {
return readb(addr);
 }
 EXPORT_SYMBOL(ioread8);
 
-unsigned int ioread16(void __iomem *addr)
+unsigned int ioread16(const void __iomem *addr)
 {
return readw(addr);
 }
 EXPORT_SYMBOL(ioread16);
 
-unsigned int ioread16be(void __iomem *addr)
+unsigned int ioread16be(const void __iomem *addr)
 {
return be16_to_cpu(__raw_readw(addr));
 }
 EXPORT_SYMBOL(ioread16be);
 
-unsigned int ioread32(void __iomem *addr)
+unsigned int ioread32(const void __iomem *addr)
 {
return readl(addr);
 }
 EXPORT_SYMBOL(ioread32);
 
-unsigned int ioread32be(void __iomem *addr)
+unsigned int ioread32be(const void __iomem *addr)
 {
return be32_to_cpu(__raw_readl(addr));
 }
-- 
2.7.4

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


[RFT 02/13] sh: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Suggested-by: Geert Uytterhoeven 
Signed-off-by: Krzysztof Kozlowski 
---
 arch/sh/kernel/iomap.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sh/kernel/iomap.c b/arch/sh/kernel/iomap.c
index ef9e2c97cbb7..bd5e212c6ea6 100644
--- a/arch/sh/kernel/iomap.c
+++ b/arch/sh/kernel/iomap.c
@@ -8,31 +8,31 @@
 #include 
 #include 
 
-unsigned int ioread8(void __iomem *addr)
+unsigned int ioread8(const void __iomem *addr)
 {
return readb(addr);
 }
 EXPORT_SYMBOL(ioread8);
 
-unsigned int ioread16(void __iomem *addr)
+unsigned int ioread16(const void __iomem *addr)
 {
return readw(addr);
 }
 EXPORT_SYMBOL(ioread16);
 
-unsigned int ioread16be(void __iomem *addr)
+unsigned int ioread16be(const void __iomem *addr)
 {
return be16_to_cpu(__raw_readw(addr));
 }
 EXPORT_SYMBOL(ioread16be);
 
-unsigned int ioread32(void __iomem *addr)
+unsigned int ioread32(const void __iomem *addr)
 {
return readl(addr);
 }
 EXPORT_SYMBOL(ioread32);
 
-unsigned int ioread32be(void __iomem *addr)
+unsigned int ioread32be(const void __iomem *addr)
 {
return be32_to_cpu(__raw_readl(addr));
 }
-- 
2.7.4

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


[RFT 01/13] iomap: Constify ioreadX() iomem argument (as in generic implementation)

2020-01-07 Thread Krzysztof Kozlowski
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.

Suggested-by: Geert Uytterhoeven 
Signed-off-by: Krzysztof Kozlowski 
---
 include/asm-generic/iomap.h   | 22 +++---
 include/linux/io-64-nonatomic-hi-lo.h |  4 ++--
 include/linux/io-64-nonatomic-lo-hi.h |  4 ++--
 lib/iomap.c   | 18 +-
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 9d28a5e82f73..986e894bef49 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -26,14 +26,14 @@
  * in the low address range. Architectures for which this is not
  * true can't use this generic implementation.
  */
-extern unsigned int ioread8(void __iomem *);
-extern unsigned int ioread16(void __iomem *);
-extern unsigned int ioread16be(void __iomem *);
-extern unsigned int ioread32(void __iomem *);
-extern unsigned int ioread32be(void __iomem *);
+extern unsigned int ioread8(const void __iomem *);
+extern unsigned int ioread16(const void __iomem *);
+extern unsigned int ioread16be(const void __iomem *);
+extern unsigned int ioread32(const void __iomem *);
+extern unsigned int ioread32be(const void __iomem *);
 #ifdef CONFIG_64BIT
-extern u64 ioread64(void __iomem *);
-extern u64 ioread64be(void __iomem *);
+extern u64 ioread64(const void __iomem *);
+extern u64 ioread64be(const void __iomem *);
 #endif
 
 #ifdef readq
@@ -41,10 +41,10 @@ extern u64 ioread64be(void __iomem *);
 #define ioread64_hi_lo ioread64_hi_lo
 #define ioread64be_lo_hi ioread64be_lo_hi
 #define ioread64be_hi_lo ioread64be_hi_lo
-extern u64 ioread64_lo_hi(void __iomem *addr);
-extern u64 ioread64_hi_lo(void __iomem *addr);
-extern u64 ioread64be_lo_hi(void __iomem *addr);
-extern u64 ioread64be_hi_lo(void __iomem *addr);
+extern u64 ioread64_lo_hi(const void __iomem *addr);
+extern u64 ioread64_hi_lo(const void __iomem *addr);
+extern u64 ioread64be_lo_hi(const void __iomem *addr);
+extern u64 ioread64be_hi_lo(const void __iomem *addr);
 #endif
 
 extern void iowrite8(u8, void __iomem *);
diff --git a/include/linux/io-64-nonatomic-hi-lo.h 
b/include/linux/io-64-nonatomic-hi-lo.h
index ae21b72cce85..f32522bb3aa5 100644
--- a/include/linux/io-64-nonatomic-hi-lo.h
+++ b/include/linux/io-64-nonatomic-hi-lo.h
@@ -57,7 +57,7 @@ static inline void hi_lo_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 
 #ifndef ioread64_hi_lo
 #define ioread64_hi_lo ioread64_hi_lo
-static inline u64 ioread64_hi_lo(void __iomem *addr)
+static inline u64 ioread64_hi_lo(const void __iomem *addr)
 {
u32 low, high;
 
@@ -79,7 +79,7 @@ static inline void iowrite64_hi_lo(u64 val, void __iomem 
*addr)
 
 #ifndef ioread64be_hi_lo
 #define ioread64be_hi_lo ioread64be_hi_lo
-static inline u64 ioread64be_hi_lo(void __iomem *addr)
+static inline u64 ioread64be_hi_lo(const void __iomem *addr)
 {
u32 low, high;
 
diff --git a/include/linux/io-64-nonatomic-lo-hi.h 
b/include/linux/io-64-nonatomic-lo-hi.h
index faaa842dbdb9..448a21435dba 100644
--- a/include/linux/io-64-nonatomic-lo-hi.h
+++ b/include/linux/io-64-nonatomic-lo-hi.h
@@ -57,7 +57,7 @@ static inline void lo_hi_writeq_relaxed(__u64 val, volatile 
void __iomem *addr)
 
 #ifndef ioread64_lo_hi
 #define ioread64_lo_hi ioread64_lo_hi
-static inline u64 ioread64_lo_hi(void __iomem *addr)
+static inline u64 ioread64_lo_hi(const void __iomem *addr)
 {
u32 low, high;
 
@@ -79,7 +79,7 @@ static inline void iowrite64_lo_hi(u64 val, void __iomem 
*addr)
 
 #ifndef ioread64be_lo_hi
 #define ioread64be_lo_hi ioread64be_lo_hi
-static inline u64 ioread64be_lo_hi(void __iomem *addr)
+static inline u64 ioread64be_lo_hi(const void __iomem *addr)
 {
u32 low, high;
 
diff --git a/lib/iomap.c b/lib/iomap.c
index e909ab71e995..3b10c0ab2cee 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -70,27 +70,27 @@ static void bad_io_access(unsigned long port, const char 
*access)
 #define mmio_read64be(addr) swab64(readq(addr))
 #endif
 
-unsigned int ioread8(void __iomem *addr)
+unsigned int ioread8(const void __iomem *addr)
 {
IO_COND(addr, return inb(port), return readb(addr));
return 0xff;
 }
-unsigned int ioread16(void __iomem *addr)
+unsigned int ioread16(const void __iomem *addr)
 {
IO_COND(addr, return inw(port), return readw(addr));
return 0x;
 }
-unsigned int ioread16be(void __iomem *addr)
+unsigned int ioread16be(const void __iomem *addr)
 {
IO_COND(addr, return pio_read16be(port), return mmio_read16be(addr));
return 0x;
 }
-unsigned int ioread32(void __iomem *addr)
+unsigned int ioread32(const void __iomem *addr)
 {
IO_COND(addr, return inl(port), return readl(addr));
   

[RFT 00/13] iomap: Constify ioreadX() iomem argument

2020-01-07 Thread Krzysztof Kozlowski
Hi,

The ioread8/16/32() and others have inconsistent interface among the
architectures: some taking address as const, some not.

It seems there is nothing really stopping all of them to take
pointer to const.

Patchset was really tested on all affected architectures.
Build testing is in progress - I hope auto-builders will point any issues.


Todo

Convert also string versions (ioread16_rep() etc) if this aproach looks OK.


Merging
===
The first 5 patches - iomap, alpha, sh, parisc and powerpc - should probably go
via one tree, or even squashed into one.

All other can go separately after these get merged.

Best regards,
Krzysztof


Krzysztof Kozlowski (13):
  iomap: Constify ioreadX() iomem argument (as in generic
implementation)
  alpha: Constify ioreadX() iomem argument (as in generic
implementation)
  sh: Constify ioreadX() iomem argument (as in generic implementation)
  parisc: Constify ioreadX() iomem argument (as in generic
implementation)
  powerpc: Constify ioreadX() iomem argument (as in generic
implementation)
  arc: Constify ioreadX() iomem argument (as in generic implementation)
  drm/mgag200: Constify ioreadX() iomem argument (as in generic
implementation)
  drm/nouveau: Constify ioreadX() iomem argument (as in generic
implementation)
  media: fsl-viu: Constify ioreadX() iomem argument (as in generic
implementation)
  net: wireless: ath5k: Constify ioreadX() iomem argument (as in generic
implementation)
  net: wireless: rtl818x: Constify ioreadX() iomem argument (as in
generic implementation)
  ntb: intel: Constify ioreadX() iomem argument (as in generic
implementation)
  virtio: pci: Constify ioreadX() iomem argument (as in generic
implementation)

 arch/alpha/include/asm/core_apecs.h|  6 +--
 arch/alpha/include/asm/core_cia.h  |  6 +--
 arch/alpha/include/asm/core_lca.h  |  6 +--
 arch/alpha/include/asm/core_marvel.h   |  4 +-
 arch/alpha/include/asm/core_mcpcia.h   |  6 +--
 arch/alpha/include/asm/core_t2.h   |  2 +-
 arch/alpha/include/asm/io.h| 12 +++---
 arch/alpha/include/asm/io_trivial.h| 16 
 arch/alpha/include/asm/jensen.h|  2 +-
 arch/alpha/include/asm/machvec.h   |  6 +--
 arch/alpha/kernel/core_marvel.c|  2 +-
 arch/alpha/kernel/io.c |  6 +--
 arch/arc/plat-axs10x/axs10x.c  |  4 +-
 arch/parisc/include/asm/io.h   |  4 +-
 arch/parisc/lib/iomap.c| 48 +++---
 arch/powerpc/kernel/iomap.c| 22 +-
 arch/sh/kernel/iomap.c | 10 ++---
 drivers/gpu/drm/mgag200/mgag200_drv.h  |  4 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c   |  2 +-
 drivers/media/platform/fsl-viu.c   |  2 +-
 drivers/net/wireless/ath/ath5k/ahb.c   | 10 ++---
 .../net/wireless/realtek/rtl818x/rtl8180/rtl8180.h |  6 +--
 drivers/ntb/hw/intel/ntb_hw_gen1.c |  2 +-
 drivers/ntb/hw/intel/ntb_hw_gen3.h |  2 +-
 drivers/ntb/hw/intel/ntb_hw_intel.h|  2 +-
 drivers/virtio/virtio_pci_modern.c |  6 +--
 include/asm-generic/iomap.h| 22 +-
 include/linux/io-64-nonatomic-hi-lo.h  |  4 +-
 include/linux/io-64-nonatomic-lo-hi.h  |  4 +-
 lib/iomap.c| 18 
 30 files changed, 123 insertions(+), 123 deletions(-)

-- 
2.7.4

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


Re: [PATCH] video: fbdev: mmp: fix platform_get_irq.cocci warnings

2020-01-07 Thread Daniel Vetter
On Sat, Jan 04, 2020 at 09:43:31PM +0100, Julia Lawall wrote:
> From: kbuild test robot 
> 
> Remove dev_err() messages after platform_get_irq*() failures.
> Line 450 is redundant because platform_get_irq() already prints
> an error.
> 
> Generated by: scripts/coccinelle/api/platform_get_irq.cocci
> 
> Fixes: dd90e9ae55a1 ("video: fbdev: mmp: add COMPILE_TEST support")
> Signed-off-by: kbuild test robot 
> Signed-off-by: Julia Lawall 

Applied to drm-misc-next, thanks for your patch.
-Daniel

> 
> ---
> 
> tree:   git://anongit.freedesktop.org/drm/drm-misc for-linux-next
> head:   80805774fc354f9ae7755a8e649a01dedfd0dcf8
> commit: dd90e9ae55a1e7efd3ac036afe9f7ae7bb64d39d [2/16] video: fbdev: mmp: 
> add COMPILE_TEST support
> :: branch date: 11 hours ago
> :: commit date: 11 hours ago
> 
>  mmp_ctrl.c |1 -
>  1 file changed, 1 deletion(-)
> 
> --- a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
> +++ b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
> @@ -447,7 +447,6 @@ static int mmphw_probe(struct platform_d
> 
>   irq = platform_get_irq(pdev, 0);
>   if (irq < 0) {
> - dev_err(>dev, "%s: no IRQ defined\n", __func__);
>   ret = -ENOENT;
>   goto failed;
>   }
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [PATCH v2 1/2] drm/print: document drm_ logging functions

2020-01-07 Thread Daniel Vetter
On Thu, Jan 02, 2020 at 11:15:18PM +0100, Sam Ravnborg wrote:
> This is the documentation I have missed when I looked for help
> how to do proper logging. Hopefully it can help others.
> 
> v2:
>   - Add parameters to the logging functions in the doc
>   - Drop notes on other types of logging
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: Daniel Vetter 
> ---
>  Documentation/gpu/drm-internals.rst |  6 +++
>  include/drm/drm_print.h | 80 ++---
>  2 files changed, 79 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-internals.rst 
> b/Documentation/gpu/drm-internals.rst
> index a73320576ca9..c2093611999c 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -164,6 +164,12 @@ File Operations
>  Misc Utilities
>  ==
>  
> +Logging
> +---
> +
> +.. kernel-doc:: include/drm/drm_print.h
> +   :doc: logging
> +
>  Printer
>  ---
>  
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 8f99d389792d..89e75eea65d2 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -250,22 +250,42 @@ static inline struct drm_printer drm_err_printer(const 
> char *prefix)
>  }
>  
>  /**
> - * enum drm_debug_category - The DRM debug categories
> + * DOC: logging
> + *
> + * There is a set of functions/macros available used for logging
> + * in the DRM subsystem.
> + * Using the drm logging function enables that the logging is consistently
> + * prefixed with *[drm]* thus the logging is easy to recognize.
> + *
> + * Example of logging with *[drm]* prefix::
>   *
> - * Each of the DRM debug logging macros use a specific category, and the 
> logging
> - * is filtered by the drm.debug module parameter. This enum specifies the 
> values
> - * for the interface.
> + *   [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> + *   [drm] Driver supports precise vblank timestamp query.
>   *
> - * Each DRM_DEBUG_ macro logs to DRM_UT_ category, except
> - * DRM_DEBUG() logs to DRM_UT_CORE.
> + *
> + * Each of the debug logging macros use a specific category, and the logging
> + * is filtered by the drm.debug module parameter. The _debug_category 
> enum
> + * specifies the values for the interface.
> + *
> + * Each drm_dbg_ macro logs to a DRM_UT_ category,
> + * except drm_dbg() that logs to DRM_UT_DRIVER.
>   *
>   * Enabling verbose debug messages is done through the drm.debug parameter, 
> each
>   * category being enabled by a bit:
>   *
>   *  - drm.debug=0x1 will enable CORE messages
>   *  - drm.debug=0x2 will enable DRIVER messages
> + *  - drm.debug=0x4 will enable KMS messages
> + *  - drm.debug=0x8 will enable PRIME messages
> + *  - drm.debug=0x10 will enable ATOMIC messages
> + *  - drm.debug=0x20 will enable VBL messages
> + *  - drm.debug=0x40 will enable STATE messages
> + *  - drm.debug=0x80 will enable LEASE messages
> + *  - drm.debug=0x100 will enable DP messages
> + *
> + * To enable more than one category OR the values - examples:
> + *
>   *  - drm.debug=0x3 will enable CORE and DRIVER messages
> - *  - ...
>   *  - drm.debug=0x1ff will enable all messages
>   *
>   * An interesting feature is that it's possible to enable verbose logging at
> @@ -273,6 +293,52 @@ static inline struct drm_printer drm_err_printer(const 
> char *prefix)
>   *
>   *   # echo 0xf > /sys/module/drm/parameters/debug
>   *
> + *
> + * When a _device * is available use one of the following logging 
> functions.
> + * The same prototype is shared by all the logging functions
> + * that take a _device * as first argument:
> + *
> + * .. code-block:: c
> + *
> + *   void drm_xxx(struct drm_device *, char * fmt, ...)
> + *
> + * DRM/Drivers can use the following functions for logging.
> + *
> + * .. code-block:: none
> + *
> + *   # Plain logging
> + *   drm_dbg(drm, fmt, ...)
> + *   drm_info(drm, fmt, ...)
> + *   drm_notice(drm, fmt, ...)
> + *   drm_warn(drm, fmt, ...)
> + *   drm_err(drm, fmt, ...)
> + *
> + *   # Log only once
> + *   drm_info_once(drm, fmt, ...)
> + *   drm_notice_once(drm, fmt, ...)
> + *   drm_warn_once(drm, fmt, ...)
> + *   drm_err_once(drm, fmt, ...)
> + *
> + *   # Ratelimited - do not flood the logs
> + *   drm_err_ratelimited(drm, fmt, ...)
> + *
> + *   # Logging with a specific category
> + *   drm_dbg_core(drm, fmt, ...)
> + *   drm_dbg(drm, fmt, ...)  # Uses the DRIVER category
> + *   drm_dbg_kms(drm, fmt, ...)
> + *   drm_dbg_prime(drm, fmt, ...)
> + *   drm_dbg_atomic(drm, fmt, ...)
> + *   drm_dbg_vbl(drm, fmt, ...)
> + *   drm_dbg_state(drm, fmt, ...)
> + *   drm_dbg_lease(drm, fmt, ...)
> + *   drm_dbg_dp(drm, fmt, ...)
> + *
> + * See enum _debug_category for a description of the categories.
> + *
> + */

I kinda can't decide between this and just copypasting fairly repetitive
kerneldoc over all the new functions. I think given the long-term idea is
to favour the above functions over all the 

[PATCH 5/5] Revert "drm/bridge: Add a drm_bridge_state object"

2020-01-07 Thread Boris Brezillon
This reverts commit 6ed7e9625fa6a6ee8230945820544767ed5799c4.
---
 drivers/gpu/drm/drm_atomic.c|  39 
 drivers/gpu/drm/drm_atomic_helper.c |  20 
 drivers/gpu/drm/drm_bridge.c| 139 ++--
 include/drm/drm_atomic.h|   3 -
 include/drm/drm_bridge.h| 114 ---
 5 files changed, 6 insertions(+), 309 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index bf1b9c37d515..d33691512a8e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,7 +30,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1018,44 +1017,6 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
connector->funcs->atomic_print_state(p, state);
 }
 
-/**
- * drm_atomic_add_encoder_bridges - add bridges attached to an encoder
- * @state: atomic state
- * @encoder: DRM encoder
- *
- * This function adds all bridges attached to @encoder. This is needed to add
- * bridge states to @state and make them available when
- * _funcs.atomic_{check,pre_enable,enable,disable_post_disable}() are
- * called
- *
- * Returns:
- * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
- * then the w/w mutex code has detected a deadlock and the entire atomic
- * sequence must be restarted. All other errors are fatal.
- */
-int
-drm_atomic_add_encoder_bridges(struct drm_atomic_state *state,
-  struct drm_encoder *encoder)
-{
-   struct drm_bridge_state *bridge_state;
-   struct drm_bridge *bridge;
-
-   if (!encoder)
-   return 0;
-
-   DRM_DEBUG_ATOMIC("Adding all bridges for [encoder:%d:%s] to %p\n",
-encoder->base.id, encoder->name, state);
-
-   drm_for_each_bridge_in_chain(encoder, bridge) {
-   bridge_state = drm_atomic_get_bridge_state(state, bridge);
-   if (IS_ERR(bridge_state))
-   return PTR_ERR(bridge_state);
-   }
-
-   return 0;
-}
-EXPORT_SYMBOL(drm_atomic_add_encoder_bridges);
-
 /**
  * drm_atomic_add_affected_connectors - add connectors for CRTC
  * @state: atomic state
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ad8eae98d9e8..4511c2e07bb9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -730,26 +730,6 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
return ret;
}
 
-   /*
-* Iterate over all connectors again, and add all affected bridges to
-* the state.
-*/
-   for_each_oldnew_connector_in_state(state, connector,
-  old_connector_state,
-  new_connector_state, i) {
-   struct drm_encoder *encoder;
-
-   encoder = old_connector_state->best_encoder;
-   ret = drm_atomic_add_encoder_bridges(state, encoder);
-   if (ret)
-   return ret;
-
-   encoder = new_connector_state->best_encoder;
-   ret = drm_atomic_add_encoder_bridges(state, encoder);
-   if (ret)
-   return ret;
-   }
-
ret = mode_valid(state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index a213c9042f2c..c2cf0c90fa26 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
@@ -90,74 +89,6 @@ void drm_bridge_remove(struct drm_bridge *bridge)
 }
 EXPORT_SYMBOL(drm_bridge_remove);
 
-static struct drm_bridge_state *
-drm_atomic_default_bridge_duplicate_state(struct drm_bridge *bridge)
-{
-   struct drm_bridge_state *new;
-
-   if (WARN_ON(!bridge->base.state))
-   return NULL;
-
-   new = kzalloc(sizeof(*new), GFP_KERNEL);
-   if (new)
-   __drm_atomic_helper_bridge_duplicate_state(bridge, new);
-
-   return new;
-}
-
-static struct drm_private_state *
-drm_bridge_atomic_duplicate_priv_state(struct drm_private_obj *obj)
-{
-   struct drm_bridge *bridge = drm_priv_to_bridge(obj);
-   struct drm_bridge_state *state;
-
-   if (bridge->funcs->atomic_duplicate_state)
-   state = bridge->funcs->atomic_duplicate_state(bridge);
-   else
-   state = drm_atomic_default_bridge_duplicate_state(bridge);
-
-   return state ? >base : NULL;
-}
-
-static void
-drm_atomic_default_bridge_destroy_state(struct drm_bridge *bridge,
-   struct drm_bridge_state *state)
-{
-   /* Just a simple kfree() for now */
-   kfree(state);
-}
-
-static void
-drm_bridge_atomic_destroy_priv_state(struct drm_private_obj *obj,
-struct drm_private_state 

[PATCH 2/5] Revert "drm/bridge: Add the necessary bits to support bus format negotiation"

2020-01-07 Thread Boris Brezillon
This reverts commit e351e4d5eaec713b2d4780c79f68702e88f2a212.
---
 drivers/gpu/drm/drm_bridge.c | 267 +--
 include/drm/drm_bridge.h | 124 
 2 files changed, 1 insertion(+), 390 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 37400607e9b7..8e4b799150b0 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -671,261 +671,13 @@ static int drm_atomic_bridge_check(struct drm_bridge 
*bridge,
return 0;
 }
 
-/**
- * drm_atomic_helper_bridge_propagate_bus_fmt() - Propagate output format to
- *   the input end of a bridge
- * @bridge: bridge control structure
- * @bridge_state: new bridge state
- * @crtc_state: new CRTC state
- * @conn_state: new connector state
- * @output_fmt: tested output bus format
- * @num_input_fmts: will contain the size of the returned array
- *
- * This helper is a pluggable implementation of the
- * _bridge_funcs.atomic_get_input_bus_fmts operation for bridges that don't
- * modify the bus configuration between their input and their output. It
- * returns an array of input formats with a single element set to @output_fmt.
- *
- * RETURNS:
- * a valid format array of size @num_input_fmts, or NULL if the allocation
- * failed
- */
-u32 *
-drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
-   struct drm_bridge_state *bridge_state,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state,
-   u32 output_fmt,
-   unsigned int *num_input_fmts)
-{
-   u32 *input_fmts;
-
-   input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
-   if (!input_fmts) {
-   *num_input_fmts = 0;
-   return NULL;
-   }
-
-   *num_input_fmts = 1;
-   input_fmts[0] = output_fmt;
-   return input_fmts;
-}
-EXPORT_SYMBOL(drm_atomic_helper_bridge_propagate_bus_fmt);
-
-static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
-   struct drm_bridge *cur_bridge,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state,
-   u32 out_bus_fmt)
-{
-   struct drm_bridge_state *cur_state;
-   unsigned int num_in_bus_fmts, i;
-   struct drm_bridge *prev_bridge;
-   u32 *in_bus_fmts;
-   int ret;
-
-   prev_bridge = drm_bridge_get_prev_bridge(cur_bridge);
-   cur_state = drm_atomic_get_new_bridge_state(crtc_state->state,
-   cur_bridge);
-   if (WARN_ON(!cur_state))
-   return -EINVAL;
-
-   /*
-* If bus format negotiation is not supported by this bridge, let's
-* pass MEDIA_BUS_FMT_FIXED to the previous bridge in the chain and
-* hope that it can handle this situation gracefully (by providing
-* appropriate default values).
-*/
-   if (!cur_bridge->funcs->atomic_get_input_bus_fmts) {
-   if (cur_bridge != first_bridge) {
-   ret = select_bus_fmt_recursive(first_bridge,
-  prev_bridge, crtc_state,
-  conn_state,
-  MEDIA_BUS_FMT_FIXED);
-   if (ret)
-   return ret;
-   }
-
-   cur_state->input_bus_cfg.format = MEDIA_BUS_FMT_FIXED;
-   cur_state->output_bus_cfg.format = out_bus_fmt;
-   return 0;
-   }
-
-   in_bus_fmts = cur_bridge->funcs->atomic_get_input_bus_fmts(cur_bridge,
-   cur_state,
-   crtc_state,
-   conn_state,
-   out_bus_fmt,
-   _in_bus_fmts);
-   if (!num_in_bus_fmts)
-   return -ENOTSUPP;
-   else if (!in_bus_fmts)
-   return -ENOMEM;
-
-   if (first_bridge == cur_bridge) {
-   cur_state->input_bus_cfg.format = in_bus_fmts[0];
-   cur_state->output_bus_cfg.format = out_bus_fmt;
-   kfree(in_bus_fmts);
-   return 0;
-   }
-
-   for (i = 0; i < num_in_bus_fmts; i++) {
-   ret = select_bus_fmt_recursive(first_bridge, prev_bridge,
-  crtc_state, conn_state,
-  in_bus_fmts[i]);
-   if (ret != -ENOTSUPP)
-   break;
-  

  1   2   >