[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups

[bugzilla-daemon]

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

--- Comment #23 from Christian König  ---
(In reply to MirceaKitsune from comment #22)
> Wasn't sure whether to bump this same bug report, as the original issue has
> clearly been fixed during nearly an year of countless Kernel + Mesa + driver
> updates.

In this case please open up a new bug report, cause the old logs are most
likely completely useless for the new bug.

> Unfortunately I now experience a new issue acting just like what I
> described here at the time: When certain 3D engines are running, there is a
> chance that after a few minutes the machine instantly freezes and becomes
> fully unusable until powered off and back on. I don't know when the new
> crash was implemented since I haven't played a lot of 3D games recently, but
> I'd assume somewhere within the last few months.

Any chance to narrow that down further?

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

Re: [radeon-alex:amd-staging-dkms-4.13 3272/3830] drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for argument 2 of 'ttm_bo_move_memcpy'

[Christian König]

Hi Kevin & Roger,

the problem is that you might need to request whitelisting. Otherwise 
the gerrit server might reject your patch.


Regards,
Christian.

Am 22.02.2018 um 05:49 schrieb He, Roger:

Hi Kevin:

Please help to check if the below patch is merged into staging branch?
If not, please cherry pick that to fix build error. Thanks!

commit 3f3a7c8259312084291859d3b623db4317365a07
Author: Christian König 
Date:   Fri Nov 24 11:32:59 2017 +0100

 staging: vboxvideo: adapt to new TTM interface

 Fixes interface changes done in the following commits:
 drm/ttm: add operation ctx to ttm_bo_validate v2
 drm/ttm: add context to driver move callback as well


-Original Message-
From: kbuild test robot [mailto:fengguang...@intel.com]
Sent: Friday, February 16, 2018 7:01 AM
To: He, Roger 
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Ma, Le ; 
Koenig, Christian 
Subject: [radeon-alex:amd-staging-dkms-4.13 3272/3830] 
drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for 
argument 2 of 'ttm_bo_move_memcpy'

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: d08b4d092e33c348cb01367e02e5dd2dd8104a46 [3272/3830] drm/ttm: use an 
ttm operation ctx for ttm_bo_move_xxx
config: i386-randconfig-a0-201806 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
 git checkout d08b4d092e33c348cb01367e02e5dd2dd8104a46
 # save the attached .config to linux build tree
 make ARCH=i386

All error/warnings (new ones prefixed by >>):

drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_move':

drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for 
argument 2 of 'ttm_bo_move_memcpy'

  return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
 ^
In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
 from drivers/staging//vboxvideo/vbox_ttm.c:30:
include/drm/ttm/ttm_bo_driver.h:1022:5: note: expected 'struct 
ttm_operation_ctx *' but argument is of type 'bool'
 int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
 ^
drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for 
argument 3 of 'ttm_bo_move_memcpy'
  return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
 ^
In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
 from drivers/staging//vboxvideo/vbox_ttm.c:30:
include/drm/ttm/ttm_bo_driver.h:1022:5: note: expected 'struct ttm_mem_reg 
*' but argument is of type 'bool'
 int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
 ^

drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: too many arguments to 
function 'ttm_bo_move_memcpy'

  return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
 ^
In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
 from drivers/staging//vboxvideo/vbox_ttm.c:30:
include/drm/ttm/ttm_bo_driver.h:1022:5: note: declared here
 int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
 ^
drivers/staging//vboxvideo/vbox_ttm.c: At top level:
drivers/staging//vboxvideo/vbox_ttm.c:240:2: warning: initialization from 
incompatible pointer type
  .move = vbox_bo_move,
  ^
drivers/staging//vboxvideo/vbox_ttm.c:240:2: warning: (near initialization 
for 'vbox_bo_driver.move')
drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_pin':
drivers/staging//vboxvideo/vbox_ttm.c:392:8: error: too many arguments to 
function 'ttm_bo_validate'
  ret = ttm_bo_validate(>bo, >placement, false, false);
^
In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
 from drivers/staging//vboxvideo/vbox_ttm.c:30:
include/drm/ttm/ttm_bo_api.h:339:5: note: declared here
 int ttm_bo_validate(struct ttm_buffer_object *bo,
 ^
drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_unpin':
drivers/staging//vboxvideo/vbox_ttm.c:419:8: error: too many arguments to 
function 'ttm_bo_validate'
  ret = ttm_bo_validate(>bo, >placement, false, false);
^
In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
 from drivers/staging//vboxvideo/vbox_ttm.c:30:
include/drm/ttm/ttm_bo_api.h:339:5: note: declared here
 int ttm_bo_validate(struct ttm_buffer_object *bo,
 ^
drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_push_sysram':
drivers/staging//vboxvideo/vbox_ttm.c:451:8: error: too many arguments to 
function 'ttm_bo_validate'
  ret = ttm_bo_validate(>bo, >placement, false, false);
^
In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
 from 

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Christian König]

Am 22.02.2018 um 03:05 schrieb Alex Deucher:

On Wed, Feb 21, 2018 at 6:41 PM, Ben Crocker  wrote:

In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270).  This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.

Can we make this ppc only?  40 bit DMA works fine on x86.


Yeah and at least when the dma_coherent allocator path is used it should 
work fine on PPC as well.


So that is not really a driver bug, but a platform bug and we should 
think about reverting or at least disabling those two patches instead.


Christian.



Alex


Signed-off-by: Ben Crocker 
---
  drivers/gpu/drm/radeon/radeon_device.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ffc10cadcf34..02538903830d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device *rdev,
 if (rdev->flags & RADEON_IS_AGP)
 rdev->need_dma32 = true;
 if ((rdev->flags & RADEON_IS_PCI) &&
-   (rdev->family <= CHIP_RS740))
+   (rdev->family <= CHIP_RS740 || rdev->family == CHIP_CEDAR))
+   rdev->need_dma32 = true;
+   if ((rdev->flags & RADEON_IS_PCIE) &&
+   (rdev->family == CHIP_CEDAR))
 rdev->need_dma32 = true;

 dma_bits = rdev->need_dma32 ? 32 : 40;
--
2.13.6

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

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


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

[PATCH v1] drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual drawing. This leads to NULL pointer
dereference because in this case new CRTC state is NULL and must be
checked before accessing.

Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Daniel Vetter 

---
Changes since initial:
- re-worked checks for null CRTC as suggested by Daniel Vetter
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 9ca8a4a59b74..4a1dbd88b1ec 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -121,12 +121,6 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
pipe = container_of(plane, struct drm_simple_display_pipe, plane);
crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
   >crtc);
-   if (!crtc_state->enable)
-   return 0; /* nothing to check when disabling or disabled */
-
-   if (crtc_state->enable)
-   drm_mode_get_hv_timing(_state->mode,
-  , );
 
ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
  ,
@@ -137,7 +131,9 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
return ret;
 
if (!plane_state->visible)
-   return -EINVAL;
+   return 0;
+
+   drm_mode_get_hv_timing(_state->mode, , );
 
if (!pipe->funcs || !pipe->funcs->check)
return 0;
-- 
2.7.4

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

RE: [radeon-alex:amd-staging-dkms-4.13 3272/3830] drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for argument 2 of 'ttm_bo_move_memcpy'

[He, Roger]

Hi Kevin:

Please help to check if the below patch is merged into staging branch?
If not, please cherry pick that to fix build error. Thanks!

commit 3f3a7c8259312084291859d3b623db4317365a07
Author: Christian König 
Date:   Fri Nov 24 11:32:59 2017 +0100

staging: vboxvideo: adapt to new TTM interface

Fixes interface changes done in the following commits:
drm/ttm: add operation ctx to ttm_bo_validate v2
drm/ttm: add context to driver move callback as well


-Original Message-
From: kbuild test robot [mailto:fengguang...@intel.com] 
Sent: Friday, February 16, 2018 7:01 AM
To: He, Roger 
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Ma, Le ; 
Koenig, Christian 
Subject: [radeon-alex:amd-staging-dkms-4.13 3272/3830] 
drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for 
argument 2 of 'ttm_bo_move_memcpy'

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head:   7bde112fab15c0a28c1d056959167cd4393bf538
commit: d08b4d092e33c348cb01367e02e5dd2dd8104a46 [3272/3830] drm/ttm: use an 
ttm operation ctx for ttm_bo_move_xxx
config: i386-randconfig-a0-201806 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout d08b4d092e33c348cb01367e02e5dd2dd8104a46
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_move':
>> drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for 
>> argument 2 of 'ttm_bo_move_memcpy'
 return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_driver.h:1022:5: note: expected 'struct 
ttm_operation_ctx *' but argument is of type 'bool'
int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: incompatible type for 
argument 3 of 'ttm_bo_move_memcpy'
 return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_driver.h:1022:5: note: expected 'struct ttm_mem_reg 
*' but argument is of type 'bool'
int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
^
>> drivers/staging//vboxvideo/vbox_ttm.c:190:9: error: too many arguments to 
>> function 'ttm_bo_move_memcpy'
 return ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:44:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_driver.h:1022:5: note: declared here
int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c: At top level:
   drivers/staging//vboxvideo/vbox_ttm.c:240:2: warning: initialization from 
incompatible pointer type
 .move = vbox_bo_move,
 ^
   drivers/staging//vboxvideo/vbox_ttm.c:240:2: warning: (near initialization 
for 'vbox_bo_driver.move')
   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_pin':
   drivers/staging//vboxvideo/vbox_ttm.c:392:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:339:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_unpin':
   drivers/staging//vboxvideo/vbox_ttm.c:419:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:339:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_push_sysram':
   drivers/staging//vboxvideo/vbox_ttm.c:451:8: error: too many arguments to 
function 'ttm_bo_validate'
 ret = ttm_bo_validate(>bo, >placement, false, false);
   ^
   In file included from drivers/staging//vboxvideo/vbox_drv.h:43:0,
from drivers/staging//vboxvideo/vbox_ttm.c:30:
   include/drm/ttm/ttm_bo_api.h:339:5: note: declared here
int ttm_bo_validate(struct ttm_buffer_object *bo,
^
   drivers/staging//vboxvideo/vbox_ttm.c: In function 'vbox_bo_move':
>> 

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #40 from Bong Cosca  ---
I'm afraid forcing si_write_harvested_raster_configs() doesn't help any. We're
back to the old tiled garbage.

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #39 from Bong Cosca  ---
Created attachment 137521
  --> https://bugs.freedesktop.org/attachment.cgi?id=137521=edit
dmesg

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

[RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

[Stefan Schake]

Android assumes an implicit black background layer is always present
behind all layers it specifies for composition. drm_hwcomposer currently
punts responsibility for this to the kernel/DRM platform and puts layers
with per-pixel alpha content on the primary plane when requested.

On some platforms (e.g. VC4) a background color fill has a cycle cost for
the hardware composer and is not enabled by default. Instead, userland can
request a background color through a CRTC property. Use this property to
specify the implicit black background Android expects.

Signed-off-by: Stefan Schake 
---
Kernel changes for this (background_color) are available here:

https://github.com/stschake/linux/commits/background-upstream

Sending as RFC because I'm not entirely clear on whose responsibility
this should be, on most DRM drivers it seems to be implicit. I think
a case could also be made that VC4 should not accept alpha formats on
the lowest layer or enable background color fill when given one anyway.
On the other hand, userland control over background color seems desirable
regardless and is a feature of multiple hardware composers (i915, vc4, omap).

 drmcrtc.cpp  | 11 +++
 drmcrtc.h|  2 ++
 drmdisplaycompositor.cpp | 15 +++
 3 files changed, 28 insertions(+)

diff --git a/drmcrtc.cpp b/drmcrtc.cpp
index 1b354fe..d7bcd7a 100644
--- a/drmcrtc.cpp
+++ b/drmcrtc.cpp
@@ -52,6 +52,13 @@ int DrmCrtc::Init() {
 ALOGE("Failed to get OUT_FENCE_PTR property");
 return ret;
   }
+
+  ret = drm_->GetCrtcProperty(*this, "background_color",
+  _color_property_);
+  if (ret) {
+ALOGI("Failed to get background_color property");
+// This is an optional property
+  }
   return 0;
 }
 
@@ -86,4 +93,8 @@ const DrmProperty ::mode_property() const {
 const DrmProperty ::out_fence_ptr_property() const {
   return out_fence_ptr_property_;
 }
+
+const DrmProperty ::background_color_property() const {
+  return background_color_property_;
+}
 }
diff --git a/drmcrtc.h b/drmcrtc.h
index c5a5599..704573a 100644
--- a/drmcrtc.h
+++ b/drmcrtc.h
@@ -46,6 +46,7 @@ class DrmCrtc {
   const DrmProperty _property() const;
   const DrmProperty _property() const;
   const DrmProperty _fence_ptr_property() const;
+  const DrmProperty _color_property() const;
 
  private:
   DrmResources *drm_;
@@ -59,6 +60,7 @@ class DrmCrtc {
   DrmProperty active_property_;
   DrmProperty mode_property_;
   DrmProperty out_fence_ptr_property_;
+  DrmProperty background_color_property_;
 };
 }
 
diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index e556e86..69c52dd 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -527,6 +527,21 @@ int 
DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
   return ret;
 }
 
+if (crtc->background_color_property().id() != 0) {
+  // Background color is specified as a 16 bit per channel RGBA value.
+  // Set a fully opaque black background as Android HWC expects.
+  const uint64_t background_color = 0x;
+
+  ret = drmModeAtomicAddProperty(pset, crtc->id(),
+ crtc->background_color_property().id(),
+ background_color) < 0;
+  if (ret) {
+ALOGE("Failed to add CRTC background_color to pset: %d", ret);
+drmModeAtomicFree(pset);
+return ret;
+  }
+}
+
 ret = drmModeAtomicAddProperty(pset, crtc->id(), 
crtc->mode_property().id(),
mode_.blob_id) < 0 ||
   drmModeAtomicAddProperty(pset, connector->id(),
-- 
2.7.4

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #38 from Alex Deucher  ---
Does forcing si_write_harvested_raster_configs() in si_state.c help?

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #37 from Alex Deucher  ---
(In reply to Bong Cosca from comment #36)
> Mesa 18.1 shows no problems with this patch. Are we going to see this code
> change in the mainstream anytime soon?

That will break other peoples cards.  Apparently the harvest config is wrong
for your card.  Please attach your full dmesg output.

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

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

[kbuild test robot]

Hi Andrzej,

I love your patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.16-rc2 next-20180221]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrzej-Hajda/dt-bindings-add-bindings-for-USB-physical-connector/20180221-185759
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

>> Error: arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi:864.1-2 syntax 
>> error
   FATAL ERROR: Unable to parse input tree

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


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

Re: [PATCH v5 1/5] drm: xlnx: Xilinx DRM KMS module

[Hyun Kwon]

Hi Laurent,

On Wed, 2018-02-21 at 15:22:31 -0800, Laurent Pinchart wrote:
> Hi Hyun,
> 
> On Tuesday, 20 February 2018 19:11:42 EET hyun.k...@xilinx.com wrote:
> > On Monday, February 19, 2018 1:43 AM Daniel Vetter wrote:
> > > On Tue, Feb 06, 2018 at 05:36:36PM -0800, Hyun Kwon wrote:
> > >> Xilinx has various platforms for display, where users can create
> > >> using multiple IPs in the programmable FPGA fabric, or where
> > >> some hardened piepline is available on the chip. Furthermore,
> > >> hardened pipeline can also interact with soft logics in FPGA.
> > >> 
> > >> The Xilinx DRM KMS module is to integrate multiple subdevices and
> > >> to represent the entire pipeline as a single DRM device. The module
> > >> includes helper (ex, framebuffer and gem helpers) and
> > >> glue logic (ex, crtc interface) functions.
> > >> 
> > >> Signed-off-by: Hyun Kwon 
> > >> Acked-by: Daniel Vetter 
> > > 
> > > Looks all ready for merging. Did you apply for commit rights to drm-misc
> > > already so you could push this right away?
> > 
> > Yes, I've created the request, and am waiting for the response there:
> > https://bugs.freedesktop.org/show_bug.cgi?id=105017
> 
> I've just sent an in-depth review of patch 1/5 (sorry for being late). There 
> are lots of small comments that could be addressed as follow-up patches in 
> the 
> worst case, but there's one comment regarding the ports DT property that 
> worries me and that I'd like to see addressed (or, if I got it wrong, 
> explained) before we merge this. Another related issue that I'd like to 
> discuss is the need for the artificial xilinx-drm platform device. And of 
> course if a v6 is needed, you can address all the other small comments :-)
> 

Thanks! I skimmed through your comments, and I prefer to clear and address all
in v6 before committing this. I've replied directly to those comments so we can
continue to discuss there.

Thanks,
-hyun

> > >> ---
> > >> v5
> > >> - Redefine xlnx_pipeline_init()
> > >> v4
> > >> - Fix a bug in of graph binding handling
> > >> - Remove vblank callbacks from xlnx_crtc
> > >> - Remove the dt binding. This module becomes more like a library.
> > >> - Rephrase the commit message
> > >> v3
> > >> - Add Laurent as a maintainer
> > >> - Fix multiple-reference on gem objects
> > >> v2
> > >> - Change the SPDX identifier format
> > >> - Merge patches(crtc, gem, fb) into single one
> > >> v2 of xlnx_drv
> > >> - Rename kms to display in xlnx_drv
> > >> - Replace some xlnx specific fb helper with common helpers in xlnx_drv
> > >> - Don't set the commit tail callback in xlnx_drv
> > >> - Support 'ports' graph binding in xlnx_drv
> > >> v2 of xlnx_fb
> > >> - Remove wrappers in xlnx_fb
> > >> - Replace some functions with drm core helpers in xlnx_fb
> > >> ---
> > >> ---
> > >> 
> > >>  MAINTAINERS  |   9 +
> > >>  drivers/gpu/drm/Kconfig  |   2 +
> > >>  drivers/gpu/drm/Makefile |   1 +
> > >>  drivers/gpu/drm/xlnx/Kconfig |  12 +
> > >>  drivers/gpu/drm/xlnx/Makefile|   2 +
> > >>  drivers/gpu/drm/xlnx/xlnx_crtc.c | 177 ++
> > >>  drivers/gpu/drm/xlnx/xlnx_crtc.h |  70 ++
> > >>  drivers/gpu/drm/xlnx/xlnx_drv.c  | 501 +
> > >>  drivers/gpu/drm/xlnx/xlnx_drv.h  |  33 +++
> > >>  drivers/gpu/drm/xlnx/xlnx_fb.c   | 298 +++
> > >>  drivers/gpu/drm/xlnx/xlnx_fb.h   |  33 +++
> > >>  drivers/gpu/drm/xlnx/xlnx_gem.c  |  47 
> > >>  drivers/gpu/drm/xlnx/xlnx_gem.h  |  26 ++
> > >>  13 files changed, 1211 insertions(+)
> > >>  create mode 100644 drivers/gpu/drm/xlnx/Kconfig
> > >>  create mode 100644 drivers/gpu/drm/xlnx/Makefile
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c
> > >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h
> 
> [snip]
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/5] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort

[Hyun Kwon]

Hi Laurent,

Thanks for the comment.

On Wed, 2018-02-21 at 16:18:35 -0800, Laurent Pinchart wrote:
> Hi Hyun,
> 
> Thank you for the patch.
> 
> On Wednesday, 7 February 2018 03:36:39 EET Hyun Kwon wrote:
> > This driver creates DRM encoder and connector for ZynqMP DisplayPort.
> > 
> > Signed-off-by: Hyun Kwon 
> > Acked-by: Daniel Vetter 
> 
> Before I go and review the code, shouldn't this be implemented as a 
> drm_bridge 
> driver ?

The hardware itself has complete encoder and connector functionalities, so I
don't think it needs to be a drm_bridge.

Thanks,
-hyun

> 
> > ---
> > v2
> > - Change the SPDX identifier format
> > - Split drm properties into a separate patch
> > ---
> > ---
> >  drivers/gpu/drm/xlnx/zynqmp_dp.c | 1738 +++
> >  drivers/gpu/drm/xlnx/zynqmp_dp.h |   37 +
> >  2 files changed, 1775 insertions(+)
> >  create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c
> >  create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h
> 
> [snip]
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #36 from Bong Cosca  ---
Mesa 18.1 shows no problems with this patch. Are we going to see this code
change in the mainstream anytime soon?

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

Re: [PATCH v5 1/5] drm: xlnx: Xilinx DRM KMS module

[Hyun Kwon]

Hi Laurent,

Thanks for the review.

On Wed, 2018-02-21 at 15:17:25 -0800, Laurent Pinchart wrote:
> Hi Hyun,
> 
> Thank you for the patch.
> 
> On Wednesday, 7 February 2018 03:36:36 EET Hyun Kwon wrote:
> > Xilinx has various platforms for display, where users can create
> > using multiple IPs in the programmable FPGA fabric, or where
> > some hardened piepline is available on the chip. Furthermore,
> 
> s/piepline/pipeline/
> 
> > hardened pipeline can also interact with soft logics in FPGA.
> > 
> > The Xilinx DRM KMS module is to integrate multiple subdevices and
> > to represent the entire pipeline as a single DRM device. The module
> > includes helper (ex, framebuffer and gem helpers) and
> > glue logic (ex, crtc interface) functions.
> > 
> > Signed-off-by: Hyun Kwon 
> > Acked-by: Daniel Vetter 
> > ---
> > v5
> > - Redefine xlnx_pipeline_init()
> > v4
> > - Fix a bug in of graph binding handling
> > - Remove vblank callbacks from xlnx_crtc
> > - Remove the dt binding. This module becomes more like a library.
> > - Rephrase the commit message
> > v3
> > - Add Laurent as a maintainer
> > - Fix multiple-reference on gem objects
> > v2
> > - Change the SPDX identifier format
> > - Merge patches(crtc, gem, fb) into single one
> > v2 of xlnx_drv
> > - Rename kms to display in xlnx_drv
> > - Replace some xlnx specific fb helper with common helpers in xlnx_drv
> > - Don't set the commit tail callback in xlnx_drv
> > - Support 'ports' graph binding in xlnx_drv
> > v2 of xlnx_fb
> > - Remove wrappers in xlnx_fb
> > - Replace some functions with drm core helpers in xlnx_fb
> > ---
> > ---
> >  MAINTAINERS  |   9 +
> >  drivers/gpu/drm/Kconfig  |   2 +
> >  drivers/gpu/drm/Makefile |   1 +
> >  drivers/gpu/drm/xlnx/Kconfig |  12 +
> >  drivers/gpu/drm/xlnx/Makefile|   2 +
> >  drivers/gpu/drm/xlnx/xlnx_crtc.c | 177 ++
> >  drivers/gpu/drm/xlnx/xlnx_crtc.h |  70 ++
> >  drivers/gpu/drm/xlnx/xlnx_drv.c  | 501 
> >  drivers/gpu/drm/xlnx/xlnx_drv.h  |  33 +++
> >  drivers/gpu/drm/xlnx/xlnx_fb.c   | 298 +++
> >  drivers/gpu/drm/xlnx/xlnx_fb.h   |  33 +++
> >  drivers/gpu/drm/xlnx/xlnx_gem.c  |  47 
> >  drivers/gpu/drm/xlnx/xlnx_gem.h  |  26 ++
> >  13 files changed, 1211 insertions(+)
> >  create mode 100644 drivers/gpu/drm/xlnx/Kconfig
> >  create mode 100644 drivers/gpu/drm/xlnx/Makefile
> >  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
> >  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
> >  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c
> >  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h
> >  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
> >  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h
> >  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c
> >  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5bc088f..07c0e73 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4789,6 +4789,15 @@ F:   drivers/gpu/drm/etnaviv/
> >  F: include/uapi/drm/etnaviv_drm.h
> >  F: Documentation/devicetree/bindings/display/etnaviv/
> > 
> > +DRM DRIVERS FOR XILINX
> > +M: Hyun Kwon 
> > +M: Laurent Pinchart 
> > +L: dri-devel@lists.freedesktop.org
> > +S: Maintained
> > +F: drivers/gpu/drm/xlnx/
> > +F: Documentation/devicetree/bindings/display/xlnx/
> > +T: git git://anongit.freedesktop.org/drm/drm-misc
> > +
> >  DRM DRIVERS FOR ZTE ZX
> >  M: Shawn Guo 
> >  L: dri-devel@lists.freedesktop.org
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index deeefa7..5a3ec66 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
> > 
> >  source "drivers/gpu/drm/tve200/Kconfig"
> > 
> > +source "drivers/gpu/drm/xlnx/Kconfig"
> 
> I would have spelled that out completely as I think it will be easier to 
> understand, but it's up to you.
> 
> >  # Keep legacy drivers last
> > 
> >  menuconfig DRM_LEGACY
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 50093ff..f93557e 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/
> >  obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
> >  obj-$(CONFIG_DRM_PL111) += pl111/
> >  obj-$(CONFIG_DRM_TVE200) += tve200/
> > +obj-$(CONFIG_DRM_XLNX) += xlnx/
> > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> > new file mode 100644
> > index 000..19fd7cd
> > --- /dev/null
> > +++ b/drivers/gpu/drm/xlnx/Kconfig
> > @@ -0,0 +1,12 @@
> > +config DRM_XLNX
> > +   tristate "Xilinx DRM KMS Driver"
> > +   depends on DRM && OF
> > +   select DRM_KMS_HELPER
> > +   select DRM_KMS_CMA_HELPER
> > +   select DRM_GEM_CMA_HELPER
> > +   help
> > + 

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Alex Deucher]

On Wed, Feb 21, 2018 at 6:41 PM, Ben Crocker  wrote:
> In radeon_device_init, set the need_dma32 flag for Cedar chips
> (e.g. FirePro 2270).  This fixes, or at least works around, a bug
> on PowerPC exposed by last year's commits
>
> 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
>
> and
>
> 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
>
> which enabled the 64-bit DMA iommu bypass.
>
> This caused the device to freeze, in some cases unrecoverably, and is
> the subject of several bug reports internal to Red Hat.

Can we make this ppc only?  40 bit DMA works fine on x86.

Alex

>
> Signed-off-by: Ben Crocker 
> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index ffc10cadcf34..02538903830d 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device *rdev,
> if (rdev->flags & RADEON_IS_AGP)
> rdev->need_dma32 = true;
> if ((rdev->flags & RADEON_IS_PCI) &&
> -   (rdev->family <= CHIP_RS740))
> +   (rdev->family <= CHIP_RS740 || rdev->family == CHIP_CEDAR))
> +   rdev->need_dma32 = true;
> +   if ((rdev->flags & RADEON_IS_PCIE) &&
> +   (rdev->family == CHIP_CEDAR))
> rdev->need_dma32 = true;
>
> dma_bits = rdev->need_dma32 ? 32 : 40;
> --
> 2.13.6
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

[bugzilla-daemon]

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

Bug ID: 105200
   Summary: [r600g] Regression: ImageMagick OpenCL kernel no
longer compiles
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: nixscrip...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137519
  --> https://bugs.freedesktop.org/attachment.cgi?id=137519=edit
The ImageMagick OpenCL Kernel

LLVM svn version: 325439
Mesa version: git fa8a764b62

The last version that worked was several weeks ago -- prior to the LLVM 6
branch.

The log is so short, I can paste it in here:

build options: -cl-single-precision-constant -cl-mad-enable
-DMAGICKCORE_HDRI_SUPPORT=1 -DCLQuantum=float -DCLSignedQuantum=float
-DCLPixelType=float4 -DQuantumRange=65535.00 -DQuantumScale=0.15
-DCharQuantumScale=1.00 -DMagickEpsilon=0.00 -DMagickPI=3.141593 
-DMaxMap=65535 -DMAGICKCORE_QUANTUM_DEPTH=16
:0:0: in function AddNoise void (<4 x float> addrspace(1)*, <4 x
float> addrspace(1)*, i32, i32, i32, i32, float, i32, i32, i32): unsupported
initializer for address space

The unknown is because I have a stripped binary. I have not done all the manual
rebuilds for the symbols yet.

The actual kernel being compiled is attached. Hopefully it should be obvious
enough what the problem is.

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

Re: [PATCH v5 4/5] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort

[Laurent Pinchart]

Hi Hyun,

Thank you for the patch.

On Wednesday, 7 February 2018 03:36:39 EET Hyun Kwon wrote:
> This driver creates DRM encoder and connector for ZynqMP DisplayPort.
> 
> Signed-off-by: Hyun Kwon 
> Acked-by: Daniel Vetter 

Before I go and review the code, shouldn't this be implemented as a drm_bridge 
driver ?

> ---
> v2
> - Change the SPDX identifier format
> - Split drm properties into a separate patch
> ---
> ---
>  drivers/gpu/drm/xlnx/zynqmp_dp.c | 1738 +++
>  drivers/gpu/drm/xlnx/zynqmp_dp.h |   37 +
>  2 files changed, 1775 insertions(+)
>  create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c
>  create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h

[snip]

-- 
Regards,

Laurent Pinchart

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

[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups

[bugzilla-daemon]

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

MirceaKitsune  changed:

   What|Removed |Added

   See Also||https://bugzilla.opensuse.o
   ||rg/show_bug.cgi?id=1046962

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

[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups

[bugzilla-daemon]

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

MirceaKitsune  changed:

   What|Removed |Added

   Priority|medium  |high
 OS|All |Linux (All)
   Hardware|Other   |x86-64 (AMD64)
Version|17.1|git

--- Comment #22 from MirceaKitsune  ---
Wasn't sure whether to bump this same bug report, as the original issue has
clearly been fixed during nearly an year of countless Kernel + Mesa + driver
updates. Unfortunately I now experience a new issue acting just like what I
described here at the time: When certain 3D engines are running, there is a
chance that after a few minutes the machine instantly freezes and becomes fully
unusable until powered off and back on. I don't know when the new crash was
implemented since I haven't played a lot of 3D games recently, but I'd assume
somewhere within the last few months.

I now have Kernel 4.15.3 and Mesa 18.0.0. Again my video card is a Radeon R7
370 from Gigabyte (RadeonSI, GCN 1.0, AMD Pitcairn Islands). I'm running the
openSUSE Tumbleweed x64 rolling release distribution.

Can someone please explain a way to debug those instant system freezes as
they're added to the system components? I can't get an output at the time of
the crash as the entire machine stops working and becomes bricked until
restarted (likely including SSH), but maybe I can make it log info that I can
retrieve after I reboot? Any useful info will help, just please nothing
dangerous that might permanently break my OS.

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

[PATCH v5 6/8] i2c: demux: Use changeset helpers for clarity

[Laurent Pinchart]

From: Pantelis Antoniou 

The changeset helpers are easier to use, use them instead of
using the static property.

Signed-off-by: Pantelis Antoniou 
Acked-by: Wolfram Sang 
["okay" -> "ok"]
Signed-off-by: Laurent Pinchart 
---
 drivers/i2c/muxes/i2c-demux-pinctrl.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/muxes/i2c-demux-pinctrl.c 
b/drivers/i2c/muxes/i2c-demux-pinctrl.c
index 33ce032cb701..0f0046831492 100644
--- a/drivers/i2c/muxes/i2c-demux-pinctrl.c
+++ b/drivers/i2c/muxes/i2c-demux-pinctrl.c
@@ -220,10 +220,7 @@ static int i2c_demux_pinctrl_probe(struct platform_device 
*pdev)
 
priv = devm_kzalloc(>dev, sizeof(*priv)
   + num_chan * sizeof(struct i2c_demux_pinctrl_chan), 
GFP_KERNEL);
-
-   props = devm_kcalloc(>dev, num_chan, sizeof(*props), GFP_KERNEL);
-
-   if (!priv || !props)
+   if (!priv)
return -ENOMEM;
 
err = of_property_read_string(np, "i2c-bus-name", >bus_name);
@@ -241,12 +238,9 @@ static int i2c_demux_pinctrl_probe(struct platform_device 
*pdev)
}
priv->chan[i].parent_np = adap_np;
 
-   props[i].name = devm_kstrdup(>dev, "status", GFP_KERNEL);
-   props[i].value = devm_kstrdup(>dev, "ok", GFP_KERNEL);
-   props[i].length = 3;
-
of_changeset_init(>chan[i].chgset);
-   of_changeset_update_property(>chan[i].chgset, adap_np, 
[i]);
+   of_changeset_update_property_string(>chan[i].chgset,
+   adap_np, "status", "ok");
}
 
priv->num_chan = num_chan;
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 8/8] drm: rcar-du: Convert LVDS encoder code to bridge driver

[Laurent Pinchart]

The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched live to move to the new bindings.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig   |   4 +-
 drivers/gpu/drm/rcar-du/Makefile  |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  93 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  24 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |  64 
 drivers/gpu/drm/rcar-du/rcar_lvds.c   | 524 ++
 12 files changed, 561 insertions(+), 616 deletions(-)
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 3f83352a7313..edde8d4b87a3 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -19,8 +19,8 @@ config DRM_RCAR_DW_HDMI
  Enable support for R-Car Gen3 internal HDMI encoder.
 
 config DRM_RCAR_LVDS
-   bool "R-Car DU LVDS Encoder Support"
-   depends on DRM_RCAR_DU
+   tristate "R-Car DU LVDS Encoder Support"
+   depends on DRM && DRM_BRIDGE && OF
select DRM_PANEL
select OF_FLATTREE
select OF_OVERLAY
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 86b337b4be5d..3e58ed93d5b1 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,10 +4,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_encoder.o \
 rcar_du_group.o \
 rcar_du_kms.o \
-rcar_du_lvdscon.o \
 rcar_du_plane.o
 
-rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
   rcar_du_of_lvds_r8a7790.dtb.o \
   rcar_du_of_lvds_r8a7791.dtb.o \
@@ -18,3 +16,4 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP)+= rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
 obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
+obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 6e02c762a557..06a3fbdd728a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -29,6 +29,7 @@
 
 #include "rcar_du_drv.h"
 #include "rcar_du_kms.h"
+#include "rcar_du_of.h"
 #include "rcar_du_regs.h"
 
 /* 
-
@@ -74,7 +75,6 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info 
= {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7779_info = {
@@ -95,14 +95,13 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
-   .quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B,
.num_crtcs = 3,
.routes = {
/*
@@ -164,7 +163,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7792_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -186,7 +184,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7794_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -434,7 +431,19 @@ static struct platform_driver rcar_du_platform_driver = {
},
 };
 
-module_platform_driver(rcar_du_platform_driver);
+static int __init rcar_du_init(void)
+{
+   

[PATCH v5 4/8] of: changesets: Introduce changeset helper methods

[Laurent Pinchart]

From: Pantelis Antoniou 

Changesets are very powerful, but the lack of a helper API
makes using them cumbersome. Introduce a simple copy based
API that makes things considerably easier.

To wit, adding a property using the raw API.

struct property *prop;
prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
prop->name = kstrdup("compatible");
prop->value = kstrdup("foo,bar");
prop->length = strlen(prop->value) + 1;
of_changeset_add_property(ocs, np, prop);

while using the helper API

of_changeset_add_property_string(ocs, np, "compatible",
"foo,bar");

Signed-off-by: Pantelis Antoniou 
[Fixed memory leak in __of_changeset_add_update_property_copy()]
[Fixed cpu to be32 conversion sparse warnings]
[Move include  to fix compilation when !CONFIG_OF_DYNAMIC]
Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
 drivers/of/dynamic.c | 222 ++
 include/linux/of.h   | 329 +++
 2 files changed, 551 insertions(+)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index a2f0c45836f9..f62083921df2 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -910,3 +910,225 @@ int of_changeset_action(struct of_changeset *ocs, 
unsigned long action,
return 0;
 }
 EXPORT_SYMBOL_GPL(of_changeset_action);
+
+/* changeset helpers */
+
+/**
+ * of_changeset_create_device_node - Create an empty device node
+ *
+ * @ocs:   changeset pointer
+ * @parent:parent device node
+ * @fmt:   format string for the node's full_name
+ * @args:  argument list for the format string
+ *
+ * Create an empty device node, marking it as detached and allocated.
+ *
+ * Returns a device node on success, an error encoded pointer otherwise
+ */
+struct device_node *of_changeset_create_device_nodev(
+   struct of_changeset *ocs, struct device_node *parent,
+   const char *fmt, va_list vargs)
+{
+   struct device_node *node;
+
+   node = __of_node_dupv(NULL, fmt, vargs);
+   if (!node)
+   return ERR_PTR(-ENOMEM);
+
+   node->parent = parent;
+   return node;
+}
+EXPORT_SYMBOL_GPL(of_changeset_create_device_nodev);
+
+/**
+ * of_changeset_create_device_node - Create an empty device node
+ *
+ * @ocs:   changeset pointer
+ * @parent:parent device node
+ * @fmt:   Format string for the node's full_name
+ * ... Arguments
+ *
+ * Create an empty device node, marking it as detached and allocated.
+ *
+ * Returns a device node on success, an error encoded pointer otherwise
+ */
+__printf(3, 4) struct device_node *
+of_changeset_create_device_node(struct of_changeset *ocs,
+   struct device_node *parent, const char *fmt, ...)
+{
+   va_list vargs;
+   struct device_node *node;
+
+   va_start(vargs, fmt);
+   node = of_changeset_create_device_nodev(ocs, parent, fmt, vargs);
+   va_end(vargs);
+   return node;
+}
+EXPORT_SYMBOL_GPL(of_changeset_create_device_node);
+
+/**
+ * __of_changeset_add_property_copy - Create/update a new property copying
+ *name & value
+ *
+ * @ocs:   changeset pointer
+ * @np:device node pointer
+ * @name:  name of the property
+ * @value: pointer to the value data
+ * @length:length of the value in bytes
+ * @update:True on update operation
+ *
+ * Adds/updates a property to the changeset by making copies of the name & 
value
+ * entries. The @update parameter controls whether an add or update takes 
place.
+ *
+ * Returns zero on success, a negative error value otherwise.
+ */
+int __of_changeset_add_update_property_copy(struct of_changeset *ocs,
+   struct device_node *np, const char *name, const void *value,
+   int length, bool update)
+{
+   struct property *prop;
+   int ret = -ENOMEM;
+
+   prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+   if (!prop)
+   return -ENOMEM;
+
+   prop->name = kstrdup(name, GFP_KERNEL);
+   if (!prop->name)
+   goto out_err;
+
+   /*
+* NOTE: There is no check for zero length value.
+* In case of a boolean property, this will allocate a value
+* of zero bytes. We do this to work around the use
+* of of_get_property() calls on boolean values.
+*/
+   prop->value = kmemdup(value, length, GFP_KERNEL);
+   if (!prop->value)
+   goto out_err;
+
+   of_property_set_flag(prop, OF_DYNAMIC);
+
+   prop->length = length;
+
+   if (!update)
+   ret = of_changeset_add_property(ocs, np, prop);
+   else
+   ret = of_changeset_update_property(ocs, np, prop);
+
+   if (!ret)
+   return 0;
+
+out_err:
+   kfree(prop->value);
+   kfree(prop->name);
+ 

[PATCH v5 5/8] of: unittest: changeset helpers

[Laurent Pinchart]

From: Pantelis Antoniou 

Add a unitest specific for the new changeset helpers.

Signed-off-by: Pantelis Antoniou 
[Use IS_ENABLED instead of #ifdef]
Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
 drivers/of/unittest.c | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 7a9abaae874d..1b21d2c549a8 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -609,6 +609,59 @@ static void __init of_unittest_changeset(void)
 #endif
 }
 
+static void __init of_unittest_changeset_helper(void)
+{
+#ifdef CONFIG_OF_DYNAMIC
+   struct device_node *n1, *n2, *n21, *parent, *np;
+   struct of_changeset chgset;
+
+   of_changeset_init();
+
+   parent = of_find_node_by_path("/testcase-data/changeset");
+
+   unittest(parent, "testcase setup failure\n");
+   n1 = of_changeset_create_device_node(,
+   parent, "/testcase-data/changeset/n1");
+   unittest(n1, "testcase setup failure\n");
+   n2 = of_changeset_create_device_node(,
+   parent, "/testcase-data/changeset/n2");
+   unittest(n2, "testcase setup failure\n");
+   n21 = of_changeset_create_device_node(, n2, "%s/%s",
+   "/testcase-data/changeset/n2", "n21");
+   unittest(n21, "testcase setup failure\n");
+
+   unittest(!of_changeset_add_property_string(, parent,
+   "prop-add", "foo"), "fail add prop\n");
+
+   unittest(!of_changeset_attach_node(, n1), "fail n1 attach\n");
+   unittest(!of_changeset_attach_node(, n2), "fail n2 attach\n");
+   unittest(!of_changeset_attach_node(, n21), "fail n21 attach\n");
+
+   unittest(!of_changeset_apply(), "apply failed\n");
+
+   /* Make sure node names are constructed correctly */
+   np = of_find_node_by_path("/testcase-data/changeset/n1");
+   unittest(np, "'%s' not added\n", n1->full_name);
+   of_node_put(np);
+
+   /* Make sure node names are constructed correctly */
+   np = of_find_node_by_path("/testcase-data/changeset/n2");
+   unittest(np, "'%s' not added\n", n2->full_name);
+   of_node_put(np);
+
+   np = of_find_node_by_path("/testcase-data/changeset/n2/n21");
+   unittest(np, "'%s' not added\n", n21->full_name);
+   of_node_put(np);
+
+   unittest(!of_changeset_revert(), "revert failed\n");
+
+   of_changeset_destroy();
+
+   of_node_put(parent);
+#endif
+}
+
+
 static void __init of_unittest_parse_interrupts(void)
 {
struct device_node *np;
@@ -2363,6 +2416,7 @@ static int __init of_unittest(void)
of_unittest_property_string();
of_unittest_property_copy();
of_unittest_changeset();
+   of_unittest_changeset_helper();
of_unittest_parse_interrupts();
of_unittest_parse_interrupts_extended();
of_unittest_match_node();
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 0/8] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hello,

This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.

To fix the, patches 1/8 and 2/8 define new DT bindings for the LVDS
encoders, and deprecate their description inside the DU bindings. To retain
backward compatibility with existing DT, patches 3/8 to 7/8 then patch the
device tree at runtime to convert the legacy bindings to the new ones.

With the DT side addressed, patch 8/8 converts the LVDS support code to a
separate bridge driver.

I decided to go for live DT patching in patch 7/8 because implementing
support for both the legacy and new bindings in the driver would have been
very intrusive, and prevented further cleanups. This version relies more
heavily on overlays to avoid touching the internals of the OF core compared to
v2, even if manual fixes to the device tree are still needed.

As all the patches but the last one have been acked, I plan to send a pull
request by the end of the week if no new issue is discovered.

Compared to v4, the patch "of: changeset: Add of_changeset_node_move method"
has been dropped as it's not needed. The patches that update the DT sources to
the new DU and LVDS bindings have been dropped as well to avoid spamming the
lists as they depend on the driver changes going in first to avoid
regressions and haven't been changed.

Compared to v3, this series uses the OF changeset API to update properties
instead of accessing the internals of the property structure. This removes the
local implementation of functions to look up nodes by path and update
properties. In order to do this, I pulled in Pantelis' patch series titled
"[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's request, and
rebased it while taking two small review comments into account.

Rob, I'd like this series to be merged in v4.17. As the changeset helpers are
now a dependency, I'd need you to merge them early (ideally on top of
v4.16-rc1) and provide a stable branch, or get your ack to merge them through
Dave's tree if they don't conflict with what you have and will queue for
v4.17.

This version also drops the small fix to the Porter board device tree that has
been queued for v4.17 already.

Compared to v2, the biggest change is in patch 7/8. Following Rob's and
Frank's reviews it was clear that modifying the unflattened DT structure of
the overlay before applying it wasn't popular. I have thus decided to use one
overlay source per SoC to move as much of the DT changes to the overlay as
possible, and only perform manual modifications (that are still needed as some
of the information is board-specific) on the system DT after applying the
overlay. As a result the overlay is parsed and applied without being modified.

Compared to v1, this series update the r8a7792 and r8a7794 device tree sources
and incorporate review feedback as described by the changelogs of individual
patches.

Laurent Pinchart (4):
  dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
  dt-bindings: display: renesas: Deprecate LVDS support in the DU
bindings
  drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
  drm: rcar-du: Convert LVDS encoder code to bridge driver

Pantelis Antoniou (4):
  of: dynamic: Add __of_node_dupv()
  of: changesets: Introduce changeset helper methods
  of: unittest: changeset helpers
  i2c: demux: Use changeset helpers for clarity

 .../bindings/display/bridge/renesas,lvds.txt   |  56 +++
 .../devicetree/bindings/display/renesas,du.txt |  31 +-
 MAINTAINERS|   1 +
 drivers/gpu/drm/rcar-du/Kconfig|   6 +-
 drivers/gpu/drm/rcar-du/Makefile   |  10 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 175 +--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  93 
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h  |  24 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c  | 238 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h  |  64 ---
 drivers/gpu/drm/rcar-du/rcar_du_of.c   | 307 
 drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 +
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 +++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 +++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 +++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 +++
 drivers/gpu/drm/rcar-du/rcar_lvds.c| 524 +
 drivers/i2c/muxes/i2c-demux-pinctrl.c  |  12 +-
 

[PATCH v5 7/8] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.

Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.

Signed-off-by: Laurent Pinchart 
---
Changes since v3:

- Use the OF changeset API
- Use of_graph_get_endpoint_by_regs()
- Replace hardcoded constants by sizeof()

Changes since v2:

- Update the SPDX headers to use C-style comments in header files
- Removed the manually created __local_fixups__ node
- Perform manual fixups on live DT instead of overlay

Changes since v1:

- Select OF_FLATTREE
- Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
- Pass void begin and end pointers to rcar_du_of_get_overlay()
- Use of_get_parent() instead of accessing the parent pointer directly
- Find the LVDS endpoints nodes based on the LVDS node instead of the
  root of the overlay
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig|   2 +
 drivers/gpu/drm/rcar-du/Makefile   |   7 +-
 drivers/gpu/drm/rcar-du/rcar_du_of.c   | 307 +
 drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 ++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 
 9 files changed, 626 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 5d0b4b7119af..3f83352a7313 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -22,6 +22,8 @@ config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
select DRM_PANEL
+   select OF_FLATTREE
+   select OF_OVERLAY
help
  Enable support for the R-Car Display Unit embedded LVDS encoders.
 
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 0cf5c11030e8..86b337b4be5d 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -8,7 +8,12 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_plane.o
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
-
+rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
+  rcar_du_of_lvds_r8a7790.dtb.o \
+  rcar_du_of_lvds_r8a7791.dtb.o \
+  rcar_du_of_lvds_r8a7793.dtb.o \
+  rcar_du_of_lvds_r8a7795.dtb.o \
+  rcar_du_of_lvds_r8a7796.dtb.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
new file mode 100644
index ..12fae8814309
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rcar_du_of.c - Legacy DT bindings compatibility
+ *
+ * Copyright (C) 2018 Laurent Pinchart 
+ *
+ * Based on work from Jyri Sarha 
+ * Copyright (C) 2015 Texas Instruments
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rcar_du_crtc.h"
+#include "rcar_du_drv.h"
+
+/* 
-
+ * Generic Overlay Handling
+ */
+
+struct rcar_du_of_overlay {
+   const char *compatible;
+   void *begin;
+   void *end;
+};
+
+#define RCAR_DU_OF_DTB(type, soc)  \
+   extern char __dtb_rcar_du_of_##type##_##soc##_begin[];  \
+   extern char __dtb_rcar_du_of_##type##_##soc##_end[]
+
+#define RCAR_DU_OF_OVERLAY(type, soc)  \
+   {   \
+   .compatible = "renesas,du-" #soc,   \
+   .begin = 

[PATCH v5 3/8] of: dynamic: Add __of_node_dupv()

[Laurent Pinchart]

From: Pantelis Antoniou 

Add an __of_node_dupv() private method and make __of_node_dup() use it.
This is required for the subsequent changeset accessors which will
make use of it.

Signed-off-by: Pantelis Antoniou 
[Make __of_node_dupv() static]
Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
 drivers/of/dynamic.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 7bb33d22b4e2..a2f0c45836f9 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -382,8 +382,9 @@ struct property *__of_prop_dup(const struct property *prop, 
gfp_t allocflags)
 }
 
 /**
- * __of_node_dup() - Duplicate or create an empty device node dynamically.
- * @fmt: Format string (plus vargs) for new full name of the device node
+ * __of_node_dupv() - Duplicate or create an empty device node dynamically.
+ * @fmt: Format string for new full name of the device node
+ * @vargs: va_list containing the arugments for the node full name
  *
  * Create an device tree node, either by duplicating an empty node or by 
allocating
  * an empty one suitable for further modification.  The node data are
@@ -391,17 +392,15 @@ struct property *__of_prop_dup(const struct property 
*prop, gfp_t allocflags)
  * OF_DETACHED bits set. Returns the newly allocated node or NULL on out of
  * memory error.
  */
-struct device_node *__of_node_dup(const struct device_node *np, const char 
*fmt, ...)
+static struct device_node *__of_node_dupv(const struct device_node *np,
+   const char *fmt, va_list vargs)
 {
-   va_list vargs;
struct device_node *node;
 
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node)
return NULL;
-   va_start(vargs, fmt);
node->full_name = kvasprintf(GFP_KERNEL, fmt, vargs);
-   va_end(vargs);
if (!node->full_name) {
kfree(node);
return NULL;
@@ -433,6 +432,24 @@ struct device_node *__of_node_dup(const struct device_node 
*np, const char *fmt,
return NULL;
 }
 
+/**
+ * __of_node_dup() - Duplicate or create an empty device node dynamically.
+ * @fmt: Format string (plus vargs) for new full name of the device node
+ *
+ * See: __of_node_dupv()
+ */
+struct device_node *__of_node_dup(const struct device_node *np,
+   const char *fmt, ...)
+{
+   va_list vargs;
+   struct device_node *node;
+
+   va_start(vargs, fmt);
+   node = __of_node_dupv(np, fmt, vargs);
+   va_end(vargs);
+   return node;
+}
+
 static void __of_changeset_entry_destroy(struct of_changeset_entry *ce)
 {
of_node_put(ce->np);
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 2/8] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
Changes since v1:

- Remove the LVDS reg range from the example
- Remove the reg-names property
---
 .../devicetree/bindings/display/renesas,du.txt | 31 --
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index cd48aba3bc8c..e79cf9b0ad38 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -14,12 +14,7 @@ Required Properties:
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
 - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
 
-  - reg: A list of base address and length of each memory resource, one for
-each entry in the reg-names property.
-  - reg-names: Name of the memory resources. The DU requires one memory
-resource for the DU core (named "du") and one memory resource for each
-LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical
-index).
+  - reg: the memory-mapped I/O registers base address and length
 
   - interrupt-parent: phandle of the parent interrupt controller.
   - interrupts: Interrupt specifiers for the DU interrupts.
@@ -29,14 +24,13 @@ Required Properties:
   - clock-names: Name of the clocks. This property is model-dependent.
 - R8A7779 uses a single functional clock. The clock doesn't need to be
   named.
-- All other DU instances use one functional clock per channel and one
-  clock per LVDS encoder (if available). The functional clocks must be
-  named "du.x" with "x" being the channel numerical index. The LVDS clocks
-  must be named "lvds.x" with "x" being the LVDS encoder numerical index.
-- In addition to the functional and encoder clocks, all DU versions also
-  support externally supplied pixel clocks. Those clocks are optional.
-  When supplied they must be named "dclkin.x" with "x" being the input
-  clock numerical index.
+- All other DU instances use one functional clock per channel The
+  functional clocks must be named "du.x" with "x" being the channel
+  numerical index.
+- In addition to the functional clocks, all DU versions also support
+  externally supplied pixel clocks. Those clocks are optional. When
+  supplied they must be named "dclkin.x" with "x" being the input clock
+  numerical index.
 
   - vsps: A list of phandle and channel index tuples to the VSPs that handle
 the memory interfaces for the DU channels. The phandle identifies the VSP
@@ -69,9 +63,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
 
du: display@feb0 {
compatible = "renesas,du-r8a7795";
-   reg = <0 0xfeb0 0 0x8>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x8>;
interrupts = ,
 ,
 ,
@@ -79,9 +71,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0>, < 0>, < 0>, < 1>;
 
ports {
-- 
Regards,

Laurent Pinchart

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

[PATCH v5 1/8] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
Changes since v1:

- Move the SoC name before the IP name in compatible strings
- Rename parallel input to parallel RGB input
- Fixed "renesas,r8a7743-lvds" description
- Document the resets property
- Fixed typo
---
 .../bindings/display/bridge/renesas,lvds.txt   | 56 ++
 MAINTAINERS|  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
new file mode 100644
index ..2b19ce51ec07
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -0,0 +1,56 @@
+Renesas R-Car LVDS Encoder
+==
+
+These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
+Gen2, R-Car Gen3 and RZ/G SoCs.
+
+Required properties:
+
+- compatible : Shall contain one of
+  - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
+  - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
+  - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
+  - "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible LVDS encoders
+  - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
+  - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
+
+- reg: Base address and length for the memory-mapped registers
+- clocks: A phandle + clock-specifier pair for the functional clock
+- resets: A phandle + reset specifier for the module reset
+
+Required nodes:
+
+The LVDS encoder has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 corresponds to the parallel RGB input
+- Video port 1 corresponds to the LVDS output
+
+Each port shall have a single endpoint.
+
+
+Example:
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7790-lvds";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   resets = < 726>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2afba909724c..13c8ec11135a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4744,6 +4744,7 @@ F:drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
 F: include/linux/platform_data/shmob_drm.h
 F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt
 
 DRM DRIVERS FOR ROCKCHIP
-- 
Regards,

Laurent Pinchart

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

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Alex Deucher]

On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace  wrote:
> On Thu 21 Dec 2017, Daniel Vetter wrote:
>> On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen  
>> wrote:
>>> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico  
>>> wrote:
 On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg  
 wrote:
> I'd like to see concrete examples of actual display controllers
> supporting more format layouts than what can be specified with a 64
> bit modifier.

 The main problem is our tiling and other metadata parameters can't
 generally fit in a modifier, so we find passing a blob of metadata a
 more suitable mechanism.
>>>
>>> I understand that you may have n knobs with a total of more than a total of
>>> 56 bits that configure your tiling/swizzling for color buffers. What I don't
>>> buy is that you need all those combinations when passing buffers around
>>> between codecs, cameras and display controllers. Even if you're sharing
>>> between the same 3D drivers in different processes, I expect just locking
>>> down, say, 64 different combinations (you can add more over time) and
>>> assigning each a modifier would be sufficient. I doubt you'd extract
>>> meaningful performance gains from going all the way to a blob.
>
> I agree with Kristian above. In my opinion, choosing to encode in
> modifiers a precise description of every possible tiling/compression
> layout is not technically incorrect, but I believe it misses the point.
> The intention behind modifiers is not to exhaustively describe all
> possibilites.
>
> I summarized this opinion in VK_EXT_image_drm_format_modifier,
> where I wrote an "introdution to modifiers" section. Here's an excerpt:
>
> One goal of modifiers in the Linux ecosystem is to enumerate for each
> vendor a reasonably sized set of tiling formats that are appropriate for
> images shared across processes, APIs, and/or devices, where each
> participating component may possibly be from different vendors.
> A non-goal is to enumerate all tiling formats supported by all vendors.
> Some tiling formats used internally by vendors are inappropriate for
> sharing; no modifiers should be assigned to such tiling formats.

Where it gets tricky is how to select that subset?  Our tiling mode
are defined more by the asic specific constraints than the tiling mode
itself.  At a high level we have basically 3 tiling modes (out of 16
possible) that would be the minimum we'd want to expose for gfx6-8.
gfx9 uses a completely new scheme.
1. Linear (per asic stride requirements, not usable by many hw blocks)
2. 1D Thin (5 layouts, displayable, depth, thin, rotated, thick)
3. 2D Thin (1D tiling constraints, plus pipe config (18 possible),
tile split (7 possible), sample split (4 possible), num banks (4
possible), bank width (4 possible), bank height (4 possible), macro
tile aspect (4 possible) all of which are asic config specific)

I guess we could do something like:
AMD_GFX6_LINEAR_ALIGNED_64B
AMD_GFX6_LINEAR_ALIGNED_256B
AMD_GFX6_LINEAR_ALIGNED_512B
AMD_GFX6_1D_THIN_DISPLAY
AMD_GFX6_1D_THIN_DEPTH
AMD_GFX6_1D_THIN_ROTATED
AMD_GFX6_1D_THIN_THIN
AMD_GFX6_1D_THIN_THICK
AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P2_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_DISPLAY_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_DEPTH_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_ROTATED_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_THIN_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
AMD_GFX6_2D_1D_THIN_THICK_PIPE_CONFIG_P4_8x16_TILE_SPLIT_64B_SAMPLE_SPLIT_1_NUM_BANKS_2_BANK_WIDTH_1_BANK_HEIGHT_1_MACRO_TILE_ASPECT_1
etc.

We only probably need 40 bits to encode all of the tiling parameters
so we could do family, plus tiling encoding that still seems unwieldy
to deal with from an application perspective.  All of the parameters
affect the alignment requirements.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

RE: [PATCH libdrm 1/2] intel: align reuse buffer's size on page size instead

[Xiong, James]

On Wed, Feb 21, 2018 at 09:43:55PM +, Chris Wilson wrote:
> Quoting James Xiong (2018-02-20 17:48:03)
> > From: "Xiong, James" 
> > 
> > With gem_reuse enabled, when a buffer size is different than
> > the sizes of buckets, it is aligned to the next bucket's size,
> > which means about 25% more memory than the requested is allocated
> > in the worst senario. For example:
> > 
> > Orignal sizeActual
> > 32KB+1Byte  40KB
> > .
> > .
> > .
> > 8MB+1Byte   10MB
> > .
> > .
> > .
> > 96MB+1Byte  112MB
> > 
> > This is very memory expensive and make the reuse feature less
> > favorable than it deserves to be.
> 
> The reuse feature also misses one important source: reusing temporaries
> within a batch.
>  
> > This commit aligns the reuse buffer size on page size instead,
> > the buffer whose size falls between bucket[n] and bucket[n+1] is
> > put in bucket[n] when it's done; And when searching for a cached
> > buffer for reuse, it goes through the cached buffers list in the
> > bucket until a cached buffer, whose size is larger than or equal
> > to the requested size, is found.
> 
> So how many times do you have to allocate a new buffer because you
> refused to hand back a slightly larger buffer? Have you checked the
> impact on !llc? With mmaps? On how wide a workload?
bucket[n] contains a list of buffers with size between bucket[n].size
and bucket[n+1].size - 1, a larger cached buffer could still be reused
if available.
I managed to run some performance tests on GEN9 without noticeable
performance impact but didn't have chance to test for more coverages.
> 
> > Signed-off-by: Xiong, James 
> > ---
> >  intel/intel_bufmgr_gem.c | 180 
> > +--
> >  libdrm_lists.h   |   6 ++
> >  2 files changed, 101 insertions(+), 85 deletions(-)
> > 
> > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> > index 386da30..5b2d0d0 100644
> > --- a/intel/intel_bufmgr_gem.c
> > +++ b/intel/intel_bufmgr_gem.c
> > @@ -402,11 +402,10 @@ drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem 
> > *bufmgr_gem,
> >  {
> > int i;
> >  
> > -   for (i = 0; i < bufmgr_gem->num_buckets; i++) {
> > -   struct drm_intel_gem_bo_bucket *bucket =
> > -   _gem->cache_bucket[i];
> > -   if (bucket->size >= size) {
> > -   return bucket;
> > +   for (i = 0; i < bufmgr_gem->num_buckets - 1; i++) {
> > +   if (size >= bufmgr_gem->cache_bucket[i].size &&
> > +   size < bufmgr_gem->cache_bucket[i+1].size) {
> > +   return _gem->cache_bucket[i];
> 
> So you never return the last bucket?
The last bucket's size is 112MB, I can add a 128M bucket at the end to
cache and reuse allocations between [112MB, 128M-1] if you think it's
important.
> 
> Given the ordered set of buckets, the test remains correct even when
> every bo within the bucket is not the full size (each bo is still at
> least bigger than the previous bucket).
The function returns an bucket according to the requested buffer size
at allocating.
if (buffer_size in [bucket[n].size, bucket[n+1].size))
return [n];
it also gets called at freeing. In both cases, the correct bucket is returned.
> 
> > }
> > }
> >  
> > @@ -685,25 +684,95 @@ drm_intel_gem_bo_madvise(drm_intel_bo *bo, int madv)
> >  madv);
> >  }
> >  
> > -/* drop the oldest entries that have been purged by the kernel */
> > +/* drop the entries that are older than the given time */
> >  static void
> >  drm_intel_gem_bo_cache_purge_bucket(drm_intel_bufmgr_gem *bufmgr_gem,
> > -   struct drm_intel_gem_bo_bucket *bucket)
> > +   struct drm_intel_gem_bo_bucket *bucket,
> > +   time_t time)
> >  {
> > -   while (!DRMLISTEMPTY(>head)) {
> > -   drm_intel_bo_gem *bo_gem;
> > -
> > -   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
> > - bucket->head.next, head);
> > -   if (drm_intel_gem_bo_madvise_internal
> > -   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED))
> > -   break;
> > -
> > -   DRMLISTDEL(_gem->head);
> > -   drm_intel_gem_bo_free(_gem->bo);
> > +   drm_intel_bo_gem *bo_gem, *temp;
> > +   DRMLISTFOREACHENTRYSAFE(bo_gem, temp, >head, head) {
> > +   if (bo_gem->free_time >= time) {
> > +   drm_intel_gem_bo_madvise_internal
> > +   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED);
> > +   DRMLISTDEL(_gem->head);
> > +   drm_intel_gem_bo_free(_gem->bo);
> > +   }
> 
> This function is called after the kernel reports that it purged a
> buffer, and the intent here is that we find all the buffers that the
> 

Re: [PATCH v4 08/16] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

Hi Rob,

On Thursday, 22 February 2018 01:28:48 EET Rob Herring wrote:
> On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart wrote:
> > The internal LVDS encoders now have their own DT bindings. Before
> > switching the driver infrastructure to those new bindings, implement
> > backward-compatibility through live DT patching.
> > 
> > Patching is disabled and will be enabled along with support for the new
> > DT bindings in the DU driver.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> 
> [...]
> 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
> > b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts new file mode
> > 100644
> > index ..6ebb355b652a
> > --- /dev/null
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
> > @@ -0,0 +1,81 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * rcar_du_of_lvds_r8a7790.dts - Legacy LVDS DT bindings conversion for
> > R8A7790
> > + *
> > + * Copyright (C) 2018 Laurent Pinchart
> > 
> > + *
> > + * Based on work from Jyri Sarha 
> > + * Copyright (C) 2015 Texas Instruments
> > + */
> > +
> > +#include 
> 
> Doesn't seem to be used in any of these.

It's a leftover from a previous test. I'll remove it in all the .dts files.

> Otherwise,
> 
> Reviewed-by: Rob Herring 
> 
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +/ {
> > +   fragment@0 {
> > +   target-path = "/";
> > +   __overlay__ {
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   lvds@feb9 {
> > +   compatible = "renesas,r8a7790-lvds";
> > +   reg = <0 0xfeb9 0 0x1c>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +   lvds0_input: endpoint {
> > +   };
> > +   };
> > +   port@1 {
> > +   reg = <1>;
> > +   lvds0_out: endpoint {
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   lvds@feb94000 {
> > +   compatible = "renesas,r8a7790-lvds";
> > +   reg = <0 0xfeb94000 0 0x1c>;
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +   lvds1_input: endpoint {
> > +   };
> > +   };
> > +   port@1 {
> > +   reg = <1>;
> > +   lvds1_out: endpoint {
> > +   };
> > +   };
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   fragment@1 {
> > +   target-path = "/display@feb0/ports";
> > +   __overlay__ {
> > +   port@1 {
> > +   endpoint {
> > +   remote-endpoint = <_input>;
> > +   };
> > +   };
> > +   port@2 {
> > +   endpoint {
> > +   remote-endpoint = <_input>;
> > +   };
> > +   };
> > +   };
> > +   };
> > +};

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v4 06/16] of: unittest: changeset helpers

[Rob Herring]

On Wed, Feb 21, 2018 at 5:39 PM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Thursday, 22 February 2018 01:10:25 EET Rob Herring wrote:
>> On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart wrote:
>> > From: Pantelis Antoniou 
>> >
>> > Add a unitest specific for the new changeset helpers.
>> >
>> > Signed-off-by: Pantelis Antoniou 
>> > Signed-off-by: Laurent Pinchart
>> > 
>> > ---
>> >
>> >  drivers/of/unittest.c | 54 ++
>> >  1 file changed, 54 insertions(+)
>> >
>> > diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
>> > index 7a9abaae874d..1b21d2c549a8 100644
>> > --- a/drivers/of/unittest.c
>> > +++ b/drivers/of/unittest.c
>> > @@ -609,6 +609,59 @@ static void __init of_unittest_changeset(void)
>> >
>> >  #endif
>> >  }
>> >
>> > +static void __init of_unittest_changeset_helper(void)
>> > +{
>> > +#ifdef CONFIG_OF_DYNAMIC
>>
>> I think this can be:
>>
>> if (!IS_ENABLED(CONFIG_OF_DYNAMIC))
>>   return;
>
> Not quite, as there are functions used below (such as of_changeset_init())
> that are not defined if CONFIG_OF_DYNAMIC isn't enabled. We could create stubs
> in that case but I believe that's out of scope for this patch series.

Okay. I thought we had the necessary stubs, but didn't check too closely.

>
>> Otherwise,
>>
>> Reviewed-by: Rob Herring 
>
> --
> Regards,
>
> Laurent Pinchart
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Ben Crocker]

In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270).  This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits

8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

and

253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.

Signed-off-by: Ben Crocker 
---
 drivers/gpu/drm/radeon/radeon_device.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index ffc10cadcf34..02538903830d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device *rdev,
if (rdev->flags & RADEON_IS_AGP)
rdev->need_dma32 = true;
if ((rdev->flags & RADEON_IS_PCI) &&
-   (rdev->family <= CHIP_RS740))
+   (rdev->family <= CHIP_RS740 || rdev->family == CHIP_CEDAR))
+   rdev->need_dma32 = true;
+   if ((rdev->flags & RADEON_IS_PCIE) &&
+   (rdev->family == CHIP_CEDAR))
rdev->need_dma32 = true;
 
dma_bits = rdev->need_dma32 ? 32 : 40;
-- 
2.13.6

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

Re: [PATCH v4 05/16] of: changeset: Add of_changeset_node_move method

[Laurent Pinchart]

Hi Rob,

On Thursday, 22 February 2018 01:20:36 EET Rob Herring wrote:
> On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart wrote:
> > From: Pantelis Antoniou 
> > 
> > Adds a changeset helper for moving a subtree to a different place
> > in the running tree. This is useful in advances cases of dynamic
> > device tree construction.
> 
> This one I'm not real clear on when we'd use this and we don't have
> any user, so lets drop it for now.

OK, no problem.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v4 06/16] of: unittest: changeset helpers

[Laurent Pinchart]

Hi Rob,

On Thursday, 22 February 2018 01:10:25 EET Rob Herring wrote:
> On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart wrote:
> > From: Pantelis Antoniou 
> > 
> > Add a unitest specific for the new changeset helpers.
> > 
> > Signed-off-by: Pantelis Antoniou 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/of/unittest.c | 54 ++
> >  1 file changed, 54 insertions(+)
> > 
> > diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> > index 7a9abaae874d..1b21d2c549a8 100644
> > --- a/drivers/of/unittest.c
> > +++ b/drivers/of/unittest.c
> > @@ -609,6 +609,59 @@ static void __init of_unittest_changeset(void)
> > 
> >  #endif
> >  }
> > 
> > +static void __init of_unittest_changeset_helper(void)
> > +{
> > +#ifdef CONFIG_OF_DYNAMIC
> 
> I think this can be:
> 
> if (!IS_ENABLED(CONFIG_OF_DYNAMIC))
>   return;

Not quite, as there are functions used below (such as of_changeset_init()) 
that are not defined if CONFIG_OF_DYNAMIC isn't enabled. We could create stubs 
in that case but I believe that's out of scope for this patch series.

> Otherwise,
> 
> Reviewed-by: Rob Herring 

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v4 08/16] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Rob Herring]

On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart
 wrote:
> The internal LVDS encoders now have their own DT bindings. Before
> switching the driver infrastructure to those new bindings, implement
> backward-compatibility through live DT patching.
>
> Patching is disabled and will be enabled along with support for the new
> DT bindings in the DU driver.
>
> Signed-off-by: Laurent Pinchart 
> ---

[...]

> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts 
> b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
> new file mode 100644
> index ..6ebb355b652a
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * rcar_du_of_lvds_r8a7790.dts - Legacy LVDS DT bindings conversion for 
> R8A7790
> + *
> + * Copyright (C) 2018 Laurent Pinchart 
> + *
> + * Based on work from Jyri Sarha 
> + * Copyright (C) 2015 Texas Instruments
> + */
> +
> +#include 

Doesn't seem to be used in any of these.

Otherwise,

Reviewed-by: Rob Herring 

> +
> +/dts-v1/;
> +/plugin/;
> +/ {
> +   fragment@0 {
> +   target-path = "/";
> +   __overlay__ {
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   lvds@feb9 {
> +   compatible = "renesas,r8a7790-lvds";
> +   reg = <0 0xfeb9 0 0x1c>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   reg = <0>;
> +   lvds0_input: endpoint {
> +   };
> +   };
> +   port@1 {
> +   reg = <1>;
> +   lvds0_out: endpoint {
> +   };
> +   };
> +   };
> +   };
> +
> +   lvds@feb94000 {
> +   compatible = "renesas,r8a7790-lvds";
> +   reg = <0 0xfeb94000 0 0x1c>;
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   reg = <0>;
> +   lvds1_input: endpoint {
> +   };
> +   };
> +   port@1 {
> +   reg = <1>;
> +   lvds1_out: endpoint {
> +   };
> +   };
> +   };
> +   };
> +   };
> +   };
> +
> +   fragment@1 {
> +   target-path = "/display@feb0/ports";
> +   __overlay__ {
> +   port@1 {
> +   endpoint {
> +   remote-endpoint = <_input>;
> +   };
> +   };
> +   port@2 {
> +   endpoint {
> +   remote-endpoint = <_input>;
> +   };
> +   };
> +   };
> +   };
> +};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Chad Versace]

On Wed 21 Feb 2018, Daniel Vetter wrote:
> On Tue, Feb 20, 2018 at 10:14:47PM -0800, Chad Versace wrote:
> > On Thu 21 Dec 2017, Daniel Vetter wrote:
> > > On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen 
> > >  wrote:
> > >> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico 
> > >>  wrote:
> > >>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg 
> > >>>  wrote:
> >  I'd like to see concrete examples of actual display controllers
> >  supporting more format layouts than what can be specified with a 64
> >  bit modifier.
> > >>>
> > >>> The main problem is our tiling and other metadata parameters can't
> > >>> generally fit in a modifier, so we find passing a blob of metadata a
> > >>> more suitable mechanism.
> > >>
> > >> I understand that you may have n knobs with a total of more than a total 
> > >> of
> > >> 56 bits that configure your tiling/swizzling for color buffers. What I 
> > >> don't
> > >> buy is that you need all those combinations when passing buffers around
> > >> between codecs, cameras and display controllers. Even if you're sharing
> > >> between the same 3D drivers in different processes, I expect just locking
> > >> down, say, 64 different combinations (you can add more over time) and
> > >> assigning each a modifier would be sufficient. I doubt you'd extract
> > >> meaningful performance gains from going all the way to a blob.
> > 
> > I agree with Kristian above. In my opinion, choosing to encode in
> > modifiers a precise description of every possible tiling/compression
> > layout is not technically incorrect, but I believe it misses the point.
> > The intention behind modifiers is not to exhaustively describe all
> > possibilites.
> > 
> > I summarized this opinion in VK_EXT_image_drm_format_modifier,
> > where I wrote an "introdution to modifiers" section. Here's an excerpt:
> > 
> > One goal of modifiers in the Linux ecosystem is to enumerate for each
> > vendor a reasonably sized set of tiling formats that are appropriate for
> > images shared across processes, APIs, and/or devices, where each
> > participating component may possibly be from different vendors.
> > A non-goal is to enumerate all tiling formats supported by all vendors.
> > Some tiling formats used internally by vendors are inappropriate for
> > sharing; no modifiers should be assigned to such tiling formats.
> 
> fwiw (since the source of truth wrt modifiers is the kernel's uapi
> header):
> 
> Acked-by: Daniel Vetter 

Linux would eventually encounter big problems if the kernel and Vulkan
disagreed on the fundamental, unspoken Theory of Modifiers. So your
acked-by is definitely worth something here. Thanks for confirming.

> 
> I'm happy to merge modifier #define additions for pretty much anything
> where there's a need for sharing across devices/drivers/apis, explicitly
> including stuff that's only relevant for userspace and which the kernel
> nevers sees (in e.g. a kms addfb2 call). Trying to preemptively enumerate
> everything that's possible doesn't seem like a wise idea. But even then we
> can probably spare the oddball vendor prefix is a driver team really
> insists that this is what they want, best using some code that makes the
> case for them.

Yep. I believe Jason Ekstrand has tentative plans for such a modifier
that improves performance for interop in GL and Vulkan but the kernel
and Intel display hw wouldn't understand: a modifier for CCS_E images
that are fully compressed.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/5] drm: xlnx: Xilinx DRM KMS module

[Laurent Pinchart]

Hi Hyun,

On Tuesday, 20 February 2018 19:11:42 EET hyun.k...@xilinx.com wrote:
> On Monday, February 19, 2018 1:43 AM Daniel Vetter wrote:
> > On Tue, Feb 06, 2018 at 05:36:36PM -0800, Hyun Kwon wrote:
> >> Xilinx has various platforms for display, where users can create
> >> using multiple IPs in the programmable FPGA fabric, or where
> >> some hardened piepline is available on the chip. Furthermore,
> >> hardened pipeline can also interact with soft logics in FPGA.
> >> 
> >> The Xilinx DRM KMS module is to integrate multiple subdevices and
> >> to represent the entire pipeline as a single DRM device. The module
> >> includes helper (ex, framebuffer and gem helpers) and
> >> glue logic (ex, crtc interface) functions.
> >> 
> >> Signed-off-by: Hyun Kwon 
> >> Acked-by: Daniel Vetter 
> > 
> > Looks all ready for merging. Did you apply for commit rights to drm-misc
> > already so you could push this right away?
> 
> Yes, I've created the request, and am waiting for the response there:
> https://bugs.freedesktop.org/show_bug.cgi?id=105017

I've just sent an in-depth review of patch 1/5 (sorry for being late). There 
are lots of small comments that could be addressed as follow-up patches in the 
worst case, but there's one comment regarding the ports DT property that 
worries me and that I'd like to see addressed (or, if I got it wrong, 
explained) before we merge this. Another related issue that I'd like to 
discuss is the need for the artificial xilinx-drm platform device. And of 
course if a v6 is needed, you can address all the other small comments :-)

> >> ---
> >> v5
> >> - Redefine xlnx_pipeline_init()
> >> v4
> >> - Fix a bug in of graph binding handling
> >> - Remove vblank callbacks from xlnx_crtc
> >> - Remove the dt binding. This module becomes more like a library.
> >> - Rephrase the commit message
> >> v3
> >> - Add Laurent as a maintainer
> >> - Fix multiple-reference on gem objects
> >> v2
> >> - Change the SPDX identifier format
> >> - Merge patches(crtc, gem, fb) into single one
> >> v2 of xlnx_drv
> >> - Rename kms to display in xlnx_drv
> >> - Replace some xlnx specific fb helper with common helpers in xlnx_drv
> >> - Don't set the commit tail callback in xlnx_drv
> >> - Support 'ports' graph binding in xlnx_drv
> >> v2 of xlnx_fb
> >> - Remove wrappers in xlnx_fb
> >> - Replace some functions with drm core helpers in xlnx_fb
> >> ---
> >> ---
> >> 
> >>  MAINTAINERS  |   9 +
> >>  drivers/gpu/drm/Kconfig  |   2 +
> >>  drivers/gpu/drm/Makefile |   1 +
> >>  drivers/gpu/drm/xlnx/Kconfig |  12 +
> >>  drivers/gpu/drm/xlnx/Makefile|   2 +
> >>  drivers/gpu/drm/xlnx/xlnx_crtc.c | 177 ++
> >>  drivers/gpu/drm/xlnx/xlnx_crtc.h |  70 ++
> >>  drivers/gpu/drm/xlnx/xlnx_drv.c  | 501 +
> >>  drivers/gpu/drm/xlnx/xlnx_drv.h  |  33 +++
> >>  drivers/gpu/drm/xlnx/xlnx_fb.c   | 298 +++
> >>  drivers/gpu/drm/xlnx/xlnx_fb.h   |  33 +++
> >>  drivers/gpu/drm/xlnx/xlnx_gem.c  |  47 
> >>  drivers/gpu/drm/xlnx/xlnx_gem.h  |  26 ++
> >>  13 files changed, 1211 insertions(+)
> >>  create mode 100644 drivers/gpu/drm/xlnx/Kconfig
> >>  create mode 100644 drivers/gpu/drm/xlnx/Makefile
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h

[snip]

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v4 05/16] of: changeset: Add of_changeset_node_move method

[Rob Herring]

On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart
 wrote:
> From: Pantelis Antoniou 
>
> Adds a changeset helper for moving a subtree to a different place
> in the running tree. This is useful in advances cases of dynamic
> device tree construction.

This one I'm not real clear on when we'd use this and we don't have
any user, so lets drop it for now.

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

Re: [PATCH v4 03/16] of: dynamic: Add __of_node_dupv()

[Rob Herring]

On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart
 wrote:
> From: Pantelis Antoniou 
>
> Add an __of_node_dupv() private method and make __of_node_dup() use it.
> This is required for the subsequent changeset accessors which will
> make use of it.
>
> Signed-off-by: Pantelis Antoniou 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/of/dynamic.c | 29 +++--
>  1 file changed, 23 insertions(+), 6 deletions(-)

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

Re: [PATCH v5 1/5] drm: xlnx: Xilinx DRM KMS module

[Laurent Pinchart]

Hi Hyun,

Thank you for the patch.

On Wednesday, 7 February 2018 03:36:36 EET Hyun Kwon wrote:
> Xilinx has various platforms for display, where users can create
> using multiple IPs in the programmable FPGA fabric, or where
> some hardened piepline is available on the chip. Furthermore,

s/piepline/pipeline/

> hardened pipeline can also interact with soft logics in FPGA.
> 
> The Xilinx DRM KMS module is to integrate multiple subdevices and
> to represent the entire pipeline as a single DRM device. The module
> includes helper (ex, framebuffer and gem helpers) and
> glue logic (ex, crtc interface) functions.
> 
> Signed-off-by: Hyun Kwon 
> Acked-by: Daniel Vetter 
> ---
> v5
> - Redefine xlnx_pipeline_init()
> v4
> - Fix a bug in of graph binding handling
> - Remove vblank callbacks from xlnx_crtc
> - Remove the dt binding. This module becomes more like a library.
> - Rephrase the commit message
> v3
> - Add Laurent as a maintainer
> - Fix multiple-reference on gem objects
> v2
> - Change the SPDX identifier format
> - Merge patches(crtc, gem, fb) into single one
> v2 of xlnx_drv
> - Rename kms to display in xlnx_drv
> - Replace some xlnx specific fb helper with common helpers in xlnx_drv
> - Don't set the commit tail callback in xlnx_drv
> - Support 'ports' graph binding in xlnx_drv
> v2 of xlnx_fb
> - Remove wrappers in xlnx_fb
> - Replace some functions with drm core helpers in xlnx_fb
> ---
> ---
>  MAINTAINERS  |   9 +
>  drivers/gpu/drm/Kconfig  |   2 +
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/xlnx/Kconfig |  12 +
>  drivers/gpu/drm/xlnx/Makefile|   2 +
>  drivers/gpu/drm/xlnx/xlnx_crtc.c | 177 ++
>  drivers/gpu/drm/xlnx/xlnx_crtc.h |  70 ++
>  drivers/gpu/drm/xlnx/xlnx_drv.c  | 501 
>  drivers/gpu/drm/xlnx/xlnx_drv.h  |  33 +++
>  drivers/gpu/drm/xlnx/xlnx_fb.c   | 298 +++
>  drivers/gpu/drm/xlnx/xlnx_fb.h   |  33 +++
>  drivers/gpu/drm/xlnx/xlnx_gem.c  |  47 
>  drivers/gpu/drm/xlnx/xlnx_gem.h  |  26 ++
>  13 files changed, 1211 insertions(+)
>  create mode 100644 drivers/gpu/drm/xlnx/Kconfig
>  create mode 100644 drivers/gpu/drm/xlnx/Makefile
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5bc088f..07c0e73 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4789,6 +4789,15 @@ F: drivers/gpu/drm/etnaviv/
>  F:   include/uapi/drm/etnaviv_drm.h
>  F:   Documentation/devicetree/bindings/display/etnaviv/
> 
> +DRM DRIVERS FOR XILINX
> +M:   Hyun Kwon 
> +M:   Laurent Pinchart 
> +L:   dri-devel@lists.freedesktop.org
> +S:   Maintained
> +F:   drivers/gpu/drm/xlnx/
> +F:   Documentation/devicetree/bindings/display/xlnx/
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +
>  DRM DRIVERS FOR ZTE ZX
>  M:   Shawn Guo 
>  L:   dri-devel@lists.freedesktop.org
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index deeefa7..5a3ec66 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
> 
>  source "drivers/gpu/drm/tve200/Kconfig"
> 
> +source "drivers/gpu/drm/xlnx/Kconfig"

I would have spelled that out completely as I think it will be easier to 
understand, but it's up to you.

>  # Keep legacy drivers last
> 
>  menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 50093ff..f93557e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB)   += mxsfb/
>  obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
>  obj-$(CONFIG_DRM_PL111) += pl111/
>  obj-$(CONFIG_DRM_TVE200) += tve200/
> +obj-$(CONFIG_DRM_XLNX)   += xlnx/
> diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> new file mode 100644
> index 000..19fd7cd
> --- /dev/null
> +++ b/drivers/gpu/drm/xlnx/Kconfig
> @@ -0,0 +1,12 @@
> +config DRM_XLNX
> + tristate "Xilinx DRM KMS Driver"
> + depends on DRM && OF
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_GEM_CMA_HELPER
> + help
> +   Xilinx DRM KMS driver. Choose this option if you have
> +   a Xilinx SoCs with hardened display pipeline or soft
> +   display pipeline using Xilinx IPs in FPGA. This module
> +   provides the kernel mode setting functionalities
> +   for Xilinx display drivers.
> diff --git 

Re: [PATCH v4 04/16] of: changesets: Introduce changeset helper methods

[Rob Herring]

On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart
 wrote:
> From: Pantelis Antoniou 
>
> Changesets are very powerful, but the lack of a helper API
> makes using them cumbersome. Introduce a simple copy based
> API that makes things considerably easier.
>
> To wit, adding a property using the raw API.
>
> struct property *prop;
> prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
> prop->name = kstrdup("compatible");
> prop->value = kstrdup("foo,bar");
> prop->length = strlen(prop->value) + 1;
> of_changeset_add_property(ocs, np, prop);
>
> while using the helper API
>
> of_changeset_add_property_string(ocs, np, "compatible",
> "foo,bar");
>
> Signed-off-by: Pantelis Antoniou 
> [Fixed memory leak in __of_changeset_add_update_property_copy()]
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/of/dynamic.c | 222 ++
>  include/linux/of.h   | 328 
> +++
>  2 files changed, 550 insertions(+)

Other than what Geert pointed out,

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

Re: [PATCH v4 06/16] of: unittest: changeset helpers

[Rob Herring]

On Tue, Feb 20, 2018 at 5:10 PM, Laurent Pinchart
 wrote:
> From: Pantelis Antoniou 
>
> Add a unitest specific for the new changeset helpers.
>
> Signed-off-by: Pantelis Antoniou 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/of/unittest.c | 54 
> +++
>  1 file changed, 54 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 7a9abaae874d..1b21d2c549a8 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -609,6 +609,59 @@ static void __init of_unittest_changeset(void)
>  #endif
>  }
>
> +static void __init of_unittest_changeset_helper(void)
> +{
> +#ifdef CONFIG_OF_DYNAMIC

I think this can be:

if (!IS_ENABLED(CONFIG_OF_DYNAMIC))
  return;

Otherwise,

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

[PATCH 13/14] drm/msm: Support per-instance address spaces

[Jordan Crouse]

Create a per-instance address spaces when a new DRM file instance is
opened assuming the target supports it and the underlying
infrastructure exists. If the operation is unsupported fall back
quietly to use the global pagetable.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_drv.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 74dd09db93d7..24d23293b090 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -22,6 +22,7 @@
 #include "msm_fence.h"
 #include "msm_gpu.h"
 #include "msm_kms.h"
+#include "msm_gem.h"
 
 
 /*
@@ -511,7 +512,27 @@ static int context_init(struct drm_device *dev, struct 
drm_file *file)
 
msm_submitqueue_init(dev, ctx);
 
-   ctx->aspace = priv->gpu->aspace;
+   /* FIXME: Do we want a dynamic name of some sort? */
+   /* FIXME: We need a smarter way to set the range based on target */
+
+   ctx->aspace = msm_gem_address_space_create_instance(
+   priv->gpu->aspace->mmu, "gpu", 0x1, 0x1);
+
+   if (IS_ERR(ctx->aspace)) {
+   int ret = PTR_ERR(ctx->aspace);
+
+   /*
+* if per-instance pagetables are not supported, fall back to
+* using the generic address space
+*/
+   if (ret == -EOPNOTSUPP)
+   ctx->aspace = priv->gpu->aspace;
+   else {
+   kfree(ctx);
+   return ret;
+   }
+   }
+
file->driver_priv = ctx;
 
return 0;
@@ -527,8 +548,12 @@ static int msm_open(struct drm_device *dev, struct 
drm_file *file)
return context_init(dev, file);
 }
 
-static void context_close(struct msm_file_private *ctx)
+static void context_close(struct msm_drm_private *priv,
+   struct msm_file_private *ctx)
 {
+   if (ctx && ctx->aspace != priv->gpu->aspace)
+   msm_gem_address_space_put(ctx->aspace);
+
msm_submitqueue_close(ctx);
kfree(ctx);
 }
@@ -543,7 +568,7 @@ static void msm_postclose(struct drm_device *dev, struct 
drm_file *file)
priv->lastctx = NULL;
mutex_unlock(>struct_mutex);
 
-   context_close(ctx);
+   context_close(priv, ctx);
 }
 
 static irqreturn_t msm_irq(int irq, void *arg)
-- 
2.16.1

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

[PATCH 10/14] drm/msm: Add msm_mmu features

[Jordan Crouse]

Add a few simple support functions to support a bitmask of
features that a specific MMU implementation supports.  The
first feature will be per-instance pagetables coming in the
following patch.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_mmu.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_mmu.h b/drivers/gpu/drm/msm/msm_mmu.h
index aa2c5d4580c8..85df78d71398 100644
--- a/drivers/gpu/drm/msm/msm_mmu.h
+++ b/drivers/gpu/drm/msm/msm_mmu.h
@@ -35,6 +35,7 @@ struct msm_mmu {
struct device *dev;
int (*handler)(void *arg, unsigned long iova, int flags);
void *arg;
+   unsigned long features;
 };
 
 static inline void msm_mmu_init(struct msm_mmu *mmu, struct device *dev,
@@ -54,4 +55,16 @@ static inline void msm_mmu_set_fault_handler(struct msm_mmu 
*mmu, void *arg,
mmu->handler = handler;
 }
 
+static inline void msm_mmu_set_feature(struct msm_mmu *mmu,
+   unsigned long feature)
+{
+   mmu->features |= feature;
+}
+
+static inline bool msm_mmu_has_feature(struct msm_mmu *mmu,
+   unsigned long feature)
+{
+   return (mmu->features & feature) ? true : false;
+}
+
 #endif /* __MSM_MMU_H__ */
-- 
2.16.1

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

[PATCH 14/14] drm/msm/a5xx: Support per-instance pagetables

[Jordan Crouse]

Add support for per-instance pagetables for 5XX targets. Create a support
buffer for preemption to hold the SMMU pagetable information for a preempted
ring, enable TTBR1 to support split pagetables and add the necessary PM4
commands to trigger a pagetable switch at the beginning of a user command.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 55 ++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 17 +++
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 76 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   | 11 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |  5 ++
 drivers/gpu/drm/msm/msm_ringbuffer.h  |  1 +
 6 files changed, 152 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index c106606887e2..e5d8df8e8e12 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -140,6 +140,59 @@ static void a5xx_flush(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring)
gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr);
 }
 
+static void a5xx_set_pagetable(struct msm_gpu *gpu, struct msm_ringbuffer 
*ring,
+   struct msm_file_private *ctx)
+{
+   u64 ttbr;
+   u32 asid;
+
+   if (msm_iommu_pasid_info(ctx->aspace->mmu, , ))
+   return;
+
+   ttbr = ttbr | ((u64) asid) << 48;
+
+   /* Turn off protected mode */
+   OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
+   OUT_RING(ring, 0);
+
+   /* Turn on APIV mode to access critical regions */
+   OUT_PKT4(ring, REG_A5XX_CP_CNTL, 1);
+   OUT_RING(ring, 1);
+
+   /* Make sure the ME is synchronized before staring the update */
+   OUT_PKT7(ring, CP_WAIT_FOR_ME, 0);
+
+   /* Execute the table update */
+   OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 3);
+   OUT_RING(ring, lower_32_bits(ttbr));
+   OUT_RING(ring, upper_32_bits(ttbr));
+   OUT_RING(ring, 0);
+
+   /*
+* Write the new TTBR0 to the preemption records - this will be used to
+* reload the pagetable if the current ring gets preempted out.
+*/
+   OUT_PKT7(ring, CP_MEM_WRITE, 4);
+   OUT_RING(ring, lower_32_bits(rbmemptr(ring, ttbr0)));
+   OUT_RING(ring, upper_32_bits(rbmemptr(ring, ttbr0)));
+   OUT_RING(ring, lower_32_bits(ttbr));
+   OUT_RING(ring, upper_32_bits(ttbr));
+
+   /* Invalidate the draw state so we start off fresh */
+   OUT_PKT7(ring, CP_SET_DRAW_STATE, 3);
+   OUT_RING(ring, 0x4);
+   OUT_RING(ring, 1);
+   OUT_RING(ring, 0);
+
+   /* Turn off APRIV */
+   OUT_PKT4(ring, REG_A5XX_CP_CNTL, 1);
+   OUT_RING(ring, 0);
+
+   /* Turn off protected mode */
+   OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
+   OUT_RING(ring, 1);
+}
+
 static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
struct msm_file_private *ctx)
 {
@@ -149,6 +202,8 @@ static void a5xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
struct msm_ringbuffer *ring = submit->ring;
unsigned int i, ibs = 0;
 
+   a5xx_set_pagetable(gpu, ring, ctx);
+
OUT_PKT7(ring, CP_PREEMPT_ENABLE_GLOBAL, 1);
OUT_RING(ring, 0x02);
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
index 6fb8c2f9b9e4..5070cb17d66c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
@@ -45,6 +45,9 @@ struct a5xx_gpu {
 
atomic_t preempt_state;
struct timer_list preempt_timer;
+   struct a5xx_smmu_info *smmu_info;
+   struct drm_gem_object *smmu_info_bo;
+   uint64_t smmu_info_iova;
 };
 
 #define to_a5xx_gpu(x) container_of(x, struct a5xx_gpu, base)
@@ -128,6 +131,20 @@ struct a5xx_preempt_record {
  */
 #define A5XX_PREEMPT_COUNTER_SIZE (16 * 4)
 
+/*
+ * This is a global structure that the preemption code uses to switch in the
+ * pagetable for the preempted process - the code switches in whatever we
+ * after preempting in a new ring.
+ */
+struct a5xx_smmu_info {
+   uint32_t  magic;
+   uint32_t  _pad4;
+   uint64_t  ttbr0;
+   uint32_t  asid;
+   uint32_t  contextidr;
+};
+
+#define A5XX_SMMU_INFO_MAGIC 0x3618CDA3UL
 
 int a5xx_power_init(struct msm_gpu *gpu);
 void a5xx_gpmu_ucode_init(struct msm_gpu *gpu);
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c 
b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
index 970c7963ae29..8a6618f51eb8 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
@@ -12,6 +12,7 @@
  */
 
 #include "msm_gem.h"
+#include "msm_mmu.h"
 #include "a5xx_gpu.h"
 
 /*
@@ -145,6 +146,15 @@ void a5xx_preempt_trigger(struct msm_gpu *gpu)
a5xx_gpu->preempt[ring->id]->wptr = get_wptr(ring);
spin_unlock_irqrestore(>lock, flags);
 
+   /* Do read barrier to make sure we have updated pagetable info 

[PATCH 12/14] drm/msm: Add support for per-instance address spaces

[Jordan Crouse]

Add a function to allocate a new pasid from a existing
MMU domain and create a per-instance address space.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_drv.h |  3 +++
 drivers/gpu/drm/msm/msm_gem_vma.c | 36 +++-
 2 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0499b1708f52..4fbc3188d776 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -178,6 +178,9 @@ void msm_gem_address_space_put(struct msm_gem_address_space 
*aspace);
 struct msm_gem_address_space *
 msm_gem_address_space_create(struct device *dev, struct iommu_domain *domain,
const char *name);
+struct msm_gem_address_space *
+msm_gem_address_space_create_instance(struct msm_mmu *parent, const char *name,
+   u64 start, u64 end);
 
 void msm_gem_submit_free(struct msm_gem_submit *submit);
 int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c 
b/drivers/gpu/drm/msm/msm_gem_vma.c
index d34e331554f3..ef33026f593f 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -92,10 +92,11 @@ msm_gem_map_vma(struct msm_gem_address_space *aspace,
 }
 
 struct msm_gem_address_space *
-msm_gem_address_space_create(struct device *dev, struct iommu_domain *domain,
-   const char *name)
+msm_gem_address_space_new(struct msm_mmu *mmu, const char *name,
+   u64 start, u64 end)
 {
struct msm_gem_address_space *aspace;
+   u64 size = end - start;
 
aspace = kzalloc(sizeof(*aspace), GFP_KERNEL);
if (!aspace)
@@ -103,12 +104,37 @@ msm_gem_address_space_create(struct device *dev, struct 
iommu_domain *domain,
 
spin_lock_init(>lock);
aspace->name = name;
-   aspace->mmu = msm_iommu_new(dev, domain);
+   aspace->mmu = mmu;
 
-   drm_mm_init(>mm, (domain->geometry.aperture_start >> 
PAGE_SHIFT),
-   (domain->geometry.aperture_end >> PAGE_SHIFT) - 1);
+   drm_mm_init(>mm, (start >> PAGE_SHIFT), size >> PAGE_SHIFT);
 
kref_init(>kref);
 
return aspace;
 }
+
+struct msm_gem_address_space *
+msm_gem_address_space_create(struct device *dev, struct iommu_domain *domain,
+   const char *name)
+{
+   struct msm_mmu *mmu = msm_iommu_new(dev, domain);
+
+   if (IS_ERR(mmu))
+   return ERR_CAST(mmu);
+
+   return msm_gem_address_space_new(mmu, name,
+   domain->geometry.aperture_start,
+   domain->geometry.aperture_end);
+}
+
+struct msm_gem_address_space *
+msm_gem_address_space_create_instance(struct msm_mmu *parent, const char *name,
+   u64 start, u64 end)
+{
+   struct msm_mmu *instance = msm_iommu_pasid_new(parent);
+
+   if (IS_ERR(instance))
+   return ERR_CAST(instance);
+
+   return msm_gem_address_space_new(instance, name, start, end);
+}
-- 
2.16.1

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

[PATCH 11/14] drm/msm: Add support for iommu-sva PASIDs

[Jordan Crouse]

The IOMMU core can support creating multiple pagetables
for a specific domai and making them available to a client
driver that has the means to manage the pagetable itself.

PASIDs are unique indexes to a software created pagetable with
the same format and characteristics as the parent IOMMU device.
The IOMMU driver allocates the pagetable and tracks it with a
unique token (PASID) - it does not touch the actual hardware.
 The client driver is expected to be able to manage the pagetables
and do something interesting with them.

Some flavors of the MSM GPU are able to allow each DRM instance
to have its own pagetable (and virtual memory space) and switch them
asynchronously at the beginning of a command.  This protects against
accidental or malicious corruption or copying of buffers from other
instances.

The first step is to add a MMU implementation that can allocate a
PASID and set up a msm_mmu struct to abstract (most) of the details
from the rest of the system.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_iommu.c | 184 
 drivers/gpu/drm/msm/msm_mmu.h   |   6 ++
 2 files changed, 190 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index fdbe1a8372f0..de8669c9a5a1 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -15,6 +15,9 @@
  * this program.  If not, see .
  */
 
+#include 
+#include 
+
 #include "msm_drv.h"
 #include "msm_mmu.h"
 
@@ -34,12 +37,29 @@ static int msm_fault_handler(struct iommu_domain *domain, 
struct device *dev,
return 0;
 }
 
+static bool msm_iommu_check_per_instance(struct msm_iommu *iommu)
+{
+   int val;
+
+   if (!IS_ENABLED(CONFIG_IOMMU_SVA))
+   return false;
+
+   if (iommu_domain_get_attr(iommu->domain, DOMAIN_ATTR_ENABLE_TTBR1,
+   ))
+   return false;
+
+   return val ? true : false;
+}
+
 static int msm_iommu_attach(struct msm_mmu *mmu, const char * const *names,
int cnt)
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
int ret;
 
+   if (msm_iommu_check_per_instance(iommu))
+   msm_mmu_set_feature(mmu, MMU_FEATURE_PER_INSTANCE_TABLES);
+
pm_runtime_get_sync(mmu->dev);
ret = iommu_attach_device(iommu->domain, mmu->dev);
pm_runtime_put_sync(mmu->dev);
@@ -112,3 +132,167 @@ struct msm_mmu *msm_iommu_new(struct device *dev, struct 
iommu_domain *domain)
 
return >base;
 }
+
+struct pasid_entry {
+   int pasid;
+   u64 ttbr;
+   u32 asid;
+   struct hlist_node node;
+};
+
+DECLARE_HASHTABLE(pasid_table, 4);
+
+static int install_pasid_cb(int pasid, u64 ttbr, u32 asid, void *data)
+{
+   struct pasid_entry *entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+
+   if (!entry)
+   return -ENOMEM;
+
+   entry->pasid = pasid;
+   entry->ttbr = ttbr;
+   entry->asid = asid;
+
+   /* FIXME: Assume that we'll never have a pasid conflict? */
+   /* FIXME: locks? RCU? */
+   hash_add(pasid_table, >node, pasid);
+   return 0;
+}
+
+static void remove_pasid_cb(int pasid, void *data)
+{
+   struct pasid_entry *entry;
+
+   hash_for_each_possible(pasid_table, entry, node, pasid) {
+   if (pasid == entry->pasid) {
+   hash_del(>node);
+   kfree(entry);
+   return;
+   }
+   }
+}
+
+struct msm_iommu_pasid {
+   struct msm_mmu base;
+   int pasid;
+   u64 ttbr;
+   u32 asid;
+};
+#define to_msm_iommu_pasid(x) container_of(x, struct msm_iommu_pasid, base)
+
+static int msm_iommu_pasid_attach(struct msm_mmu *mmu,
+   const char * const *names, int cnt)
+{
+   return 0;
+}
+
+static int msm_iommu_pasid_map(struct msm_mmu *mmu, uint64_t iova,
+   struct sg_table *sgt, unsigned len, int prot)
+{
+   struct msm_iommu_pasid *pasid = to_msm_iommu_pasid(mmu);
+   int ret;
+
+   ret = iommu_sva_map_sg(pasid->pasid, iova, sgt->sgl, sgt->nents, prot);
+   WARN_ON(ret < 0);
+
+   return (ret == len) ? 0 : -EINVAL;
+}
+
+static int msm_iommu_pasid_unmap(struct msm_mmu *mmu, uint64_t iova,
+   struct sg_table *sgt, unsigned len)
+{
+   struct msm_iommu_pasid *pasid = to_msm_iommu_pasid(mmu);
+
+   iommu_sva_unmap(pasid->pasid, iova, len);
+
+   return 0;
+}
+
+static void msm_iommu_pasid_detach(struct msm_mmu *mmu,
+   const char * const *names, int cnt)
+{
+}
+
+static void msm_iommu_pasid_destroy(struct msm_mmu *mmu)
+{
+   struct msm_iommu_pasid *pasid = to_msm_iommu_pasid(mmu);
+
+   iommu_sva_free_pasid(pasid->pasid);
+   kfree(pasid);
+}
+
+static const struct msm_mmu_funcs pasid_funcs = {
+   .attach = msm_iommu_pasid_attach,
+   .detach = msm_iommu_pasid_detach,
+   

[PATCH 09/14] drm/msm/gpu: Support using TTBR1 for kernel buffer objects

[Jordan Crouse]

arm-smmu based targets can support split pagetables (TTBR0/TTBR1).
This is most useful for implementing per-instance pagetables so that
the "user" pagetable can be swapped out while the "kernel" or
"global" pagetable remains entact.

if the target specifies a global virtual memory range then try to
enable TTBR1 (the "global" pagetable) on the domain and and if
successful use the global virtual memory range for allocations
on the default GPU address space - this ensures that the global
allocations make it into the right space. Per-instance pagetables
still need additional support to be enabled but even if they
aren't set up it isn't harmful to just use TTBR1 for all
virtual memory regions and leave the other pagetable unused.

If TTBR1 support isn't enabled then fall back to the "legacy"
virtual address space both kernel and user.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_gpu.c | 20 ++--
 drivers/gpu/drm/msm/msm_gpu.h |  4 ++--
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 086fb347b554..94332faa316f 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -701,7 +701,8 @@ static int get_clocks(struct platform_device *pdev, struct 
msm_gpu *gpu)
 
 static struct msm_gem_address_space *
 msm_gpu_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev,
-   uint64_t va_start, uint64_t va_end)
+   u64 va_start, u64 va_end,
+   u64 va_global_start, u64 va_global_end)
 {
struct iommu_domain *iommu;
struct msm_gem_address_space *aspace;
@@ -719,6 +720,20 @@ msm_gpu_create_address_space(struct msm_gpu *gpu, struct 
platform_device *pdev,
iommu->geometry.aperture_start = va_start;
iommu->geometry.aperture_end = va_end;
 
+   /* If a va_global range was specified then try to set up TTBR1 */
+   if (va_global_start && va_global_end) {
+   int val = 1;
+
+   /* Try to enable TTBR1 on the domain */
+   ret = iommu_domain_set_attr(iommu, DOMAIN_ATTR_ENABLE_TTBR1,
+   );
+
+   if (!WARN(ret, "Unable to enable TTBR1 for the IOMMU\n")) {
+   iommu->geometry.aperture_start = va_global_start;
+   iommu->geometry.aperture_end = va_global_end;
+   }
+   }
+
dev_info(gpu->dev->dev, "%s: using IOMMU\n", gpu->name);
 
aspace = msm_gem_address_space_create(>dev, iommu, "gpu");
@@ -811,7 +826,8 @@ int msm_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
msm_devfreq_init(gpu);
 
gpu->aspace = msm_gpu_create_address_space(gpu, pdev,
-   config->va_start, config->va_end);
+   config->va_start, config->va_end, config->va_start_global,
+   config->va_end_global);
 
if (gpu->aspace == NULL)
dev_info(drm->dev, "%s: no IOMMU, fallback to VRAM 
carveout!\n", name);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index fccfccd303af..698eca2c1431 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -31,8 +31,8 @@ struct msm_gpu_perfcntr;
 struct msm_gpu_config {
const char *ioname;
const char *irqname;
-   uint64_t va_start;
-   uint64_t va_end;
+   uint64_t va_start, va_end;
+   uint64_t va_start_global, va_end_global;
unsigned int nr_rings;
 };
 
-- 
2.16.1

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

[PATCH 08/14] drm/msm: Pass the MMU domain index in struct msm_file_private

[Jordan Crouse]

Pass the index of the MMU domain in struct msm_file_private instead
of assuming gpu->id throughout the submit path. This clears the way
to change ctx->aspace to a per-instance pagetable.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_drv.c| 16 
 drivers/gpu/drm/msm/msm_drv.h|  1 +
 drivers/gpu/drm/msm/msm_gem.h|  1 +
 drivers/gpu/drm/msm/msm_gem_submit.c | 13 -
 drivers/gpu/drm/msm/msm_gpu.c|  5 ++---
 5 files changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d90ef1d78a1b..74dd09db93d7 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -502,6 +502,7 @@ static void load_gpu(struct drm_device *dev)
 
 static int context_init(struct drm_device *dev, struct drm_file *file)
 {
+   struct msm_drm_private *priv = dev->dev_private;
struct msm_file_private *ctx;
 
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -510,6 +511,7 @@ static int context_init(struct drm_device *dev, struct 
drm_file *file)
 
msm_submitqueue_init(dev, ctx);
 
+   ctx->aspace = priv->gpu->aspace;
file->driver_priv = ctx;
 
return 0;
@@ -683,17 +685,6 @@ static int msm_ioctl_gem_cpu_fini(struct drm_device *dev, 
void *data,
return ret;
 }
 
-static int msm_ioctl_gem_info_iova(struct drm_device *dev,
-   struct drm_gem_object *obj, uint64_t *iova)
-{
-   struct msm_drm_private *priv = dev->dev_private;
-
-   if (!priv->gpu)
-   return -EINVAL;
-
-   return msm_gem_get_iova(obj, priv->gpu->aspace, iova);
-}
-
 static int msm_ioctl_gem_info(struct drm_device *dev, void *data,
struct drm_file *file)
 {
@@ -709,9 +700,10 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void 
*data,
return -ENOENT;
 
if (args->flags & MSM_INFO_IOVA) {
+   struct msm_file_private *ctx = file->driver_priv;
uint64_t iova;
 
-   ret = msm_ioctl_gem_info_iova(dev, obj, );
+   ret = msm_gem_get_iova(obj, ctx->aspace, );
if (!ret)
args->offset = iova;
} else {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0a653dd2e618..0499b1708f52 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -59,6 +59,7 @@ struct msm_file_private {
rwlock_t queuelock;
struct list_head submitqueues;
int queueid;
+   struct msm_gem_address_space *aspace;
 };
 
 enum msm_mdp_plane_property {
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 9320e184b48d..a5e61259f40b 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -138,6 +138,7 @@ void msm_gem_vunmap(struct drm_gem_object *obj, enum 
msm_gem_lock subclass);
 struct msm_gem_submit {
struct drm_device *dev;
struct msm_gpu *gpu;
+   struct msm_gem_address_space *aspace;
struct list_head node;   /* node in ring submit list */
struct list_head bo_list;
struct ww_acquire_ctx ticket;
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index b8dc8f96caf2..d14399c0dfb8 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -31,8 +31,9 @@
 #define BO_PINNED   0x2000
 
 static struct msm_gem_submit *submit_create(struct drm_device *dev,
-   struct msm_gpu *gpu, struct msm_gpu_submitqueue *queue,
-   uint32_t nr_bos, uint32_t nr_cmds)
+   struct msm_gpu *gpu, struct msm_gem_address_space *aspace,
+   struct msm_gpu_submitqueue *queue, uint32_t nr_bos,
+   uint32_t nr_cmds)
 {
struct msm_gem_submit *submit;
uint64_t sz = sizeof(*submit) + ((u64)nr_bos * sizeof(submit->bos[0])) +
@@ -46,6 +47,7 @@ static struct msm_gem_submit *submit_create(struct drm_device 
*dev,
return NULL;
 
submit->dev = dev;
+   submit->aspace = aspace;
submit->gpu = gpu;
submit->fence = NULL;
submit->pid = get_pid(task_pid(current));
@@ -167,7 +169,7 @@ static void submit_unlock_unpin_bo(struct msm_gem_submit 
*submit,
struct msm_gem_object *msm_obj = submit->bos[i].obj;
 
if (submit->bos[i].flags & BO_PINNED)
-   msm_gem_put_iova(_obj->base, submit->gpu->aspace);
+   msm_gem_put_iova(_obj->base, submit->aspace);
 
if (submit->bos[i].flags & BO_LOCKED)
ww_mutex_unlock(_obj->resv->lock);
@@ -270,7 +272,7 @@ static int submit_pin_objects(struct msm_gem_submit *submit)
 
/* if locking succeeded, pin bo: */
ret = msm_gem_get_iova(_obj->base,
-   submit->gpu->aspace, );
+   submit->aspace, );
 
if 

[PATCH 04/14] iommu: sva: Add support for pasid allocation

[Jordan Crouse]

Some older SMMU implementations that do not have a fully featured
PASID model have alternate workarounds for using multiple pagetables.
For example, MSM GPUs have logic to automatically switch the user
pagetable from hardware by writing the context bank directly.

Instead of binding and sharing CPU pagetables these implementations
need to a new pagetable structure and populate it manually. Add a
new set of API functions to create and populate a pagetable structure
identified by a pasid.

Signed-off-by: Jordan Crouse 
---
 drivers/iommu/iommu-sva.c | 239 ++
 drivers/iommu/iommu.c |   3 +-
 include/linux/iommu.h |  56 +++
 3 files changed, 297 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index 5fc689b1ef72..c48fde5b0bbd 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -809,3 +809,242 @@ struct mm_struct *iommu_sva_find(int pasid)
return mm;
 }
 EXPORT_SYMBOL_GPL(iommu_sva_find);
+
+int iommu_sva_alloc_pasid(struct iommu_domain *domain, struct device *dev)
+{
+   int ret, pasid;
+   struct io_pasid *io_pasid;
+
+   if (!domain->ops->pasid_alloc || !domain->ops->pasid_free)
+   return -ENODEV;
+
+   io_pasid = kzalloc(sizeof(*io_pasid), GFP_KERNEL);
+   if (!io_pasid)
+   return -ENOMEM;
+
+   io_pasid->domain = domain;
+   io_pasid->base.type = IO_TYPE_PASID;
+
+   idr_preload(GFP_KERNEL);
+   spin_lock(_sva_lock);
+   pasid = idr_alloc_cyclic(_pasid_idr, _pasid->base,
+   1, (1 << 31), GFP_ATOMIC);
+   io_pasid->base.pasid = pasid;
+   spin_unlock(_sva_lock);
+   idr_preload_end();
+
+   if (pasid < 0) {
+   kfree(io_pasid);
+   return pasid;
+   }
+
+   ret = domain->ops->pasid_alloc(domain, dev, pasid);
+   if (!ret)
+   return pasid;
+
+   spin_lock(_sva_lock);
+   idr_remove(_pasid_idr, io_pasid->base.pasid);
+   spin_unlock(_sva_lock);
+
+   kfree(io_pasid);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_sva_alloc_pasid);
+
+static struct io_pasid *get_io_pasid(int pasid)
+{
+   struct io_base *io_base;
+   struct io_pasid *io_pasid = NULL;
+
+   spin_lock(_sva_lock);
+   io_base = idr_find(_pasid_idr, pasid);
+   if (io_base && io_base->type == IO_TYPE_PASID)
+   io_pasid = container_of(io_base, struct io_pasid, base);
+   spin_unlock(_sva_lock);
+
+   return io_pasid;
+}
+
+int iommu_sva_map(int pasid, unsigned long iova,
+ phys_addr_t paddr, size_t size, int prot)
+{
+   unsigned long orig_iova = iova;
+   unsigned int min_pagesz;
+   size_t orig_size = size;
+   struct io_pasid *io_pasid;
+   struct iommu_domain *domain;
+   int ret = 0;
+
+   io_pasid = get_io_pasid(pasid);
+   if (!io_pasid)
+   return -ENODEV;
+
+   domain = io_pasid->domain;
+
+   if (unlikely(domain->ops->sva_map == NULL ||
+domain->pgsize_bitmap == 0UL))
+   return -ENODEV;
+
+   /* find out the minimum page size supported */
+   min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
+
+   /*
+* both the virtual address and the physical one, as well as
+* the size of the mapping, must be aligned (at least) to the
+* size of the smallest page supported by the hardware
+*/
+   if (!IS_ALIGNED(iova | paddr | size, min_pagesz)) {
+   pr_err("unaligned: iova 0x%lx pa %pa size 0x%zx min_pagesz 
0x%x\n",
+  iova, , size, min_pagesz);
+   return -EINVAL;
+   }
+
+   while (size) {
+   size_t pgsize = iommu_pgsize(domain, iova | paddr, size);
+
+   pr_debug("mapping: iova 0x%lx pa %pa pgsize 0x%zx\n",
+iova, , pgsize);
+
+   ret = domain->ops->sva_map(domain, pasid, iova, paddr, pgsize,
+   prot);
+   if (ret)
+   break;
+
+   iova += pgsize;
+   paddr += pgsize;
+   size -= pgsize;
+   }
+
+   /* unroll mapping in case something went wrong */
+   if (ret)
+   iommu_sva_unmap(pasid, orig_iova, orig_size - size);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_sva_map);
+
+size_t iommu_sva_map_sg(int pasid, unsigned long iova,
+   struct scatterlist *sg, unsigned int nents, int prot)
+{
+   struct io_pasid *io_pasid;
+   struct iommu_domain *domain;
+   struct scatterlist *s;
+   size_t mapped = 0;
+   unsigned int i, min_pagesz;
+   int ret;
+
+   io_pasid = get_io_pasid(pasid);
+   if (!io_pasid)
+   return -ENODEV;
+
+   domain = io_pasid->domain;
+
+   if (unlikely(domain->pgsize_bitmap == 0UL))
+   return 0;
+
+   min_pagesz = 1 << 

[PATCH 07/14] drm/msm: Enable 64 bit mode by default

[Jordan Crouse]

A5XX GPUs can be run in either 32 or 64 bit mode. The GPU registers
and the microcode use 64 bit virtual addressing in either case but the
upper 32 bits are ignored if the GPU is in 32 bit mode. There is no
performance disadvantage to remaining in 64 bit mode even if we are
only generating 32 bit addresses so switch over now to prepare for
using addresses above 4G for targets that support them.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 14 ++
 drivers/gpu/drm/msm/msm_iommu.c   |  2 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 7e09d44e4a15..c106606887e2 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -695,6 +695,20 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
REG_A5XX_RBBM_SECVID_TSB_TRUSTED_BASE_HI, 0x);
gpu_write(gpu, REG_A5XX_RBBM_SECVID_TSB_TRUSTED_SIZE, 0x);
 
+   /* Put the GPU into 64 bit by default */
+   gpu_write(gpu, REG_A5XX_CP_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_VSC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_GRAS_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_RB_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_PC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_HLSQ_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_VFD_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_VPC_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_UCHE_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_SP_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_TPL1_ADDR_MODE_CNTL, 0x1);
+   gpu_write(gpu, REG_A5XX_RBBM_SECVID_TSB_ADDR_MODE_CNTL, 0x1);
+
ret = adreno_hw_init(gpu);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..fdbe1a8372f0 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -30,7 +30,7 @@ static int msm_fault_handler(struct iommu_domain *domain, 
struct device *dev,
struct msm_iommu *iommu = arg;
if (iommu->base.handler)
return iommu->base.handler(iommu->base.arg, iova, flags);
-   pr_warn_ratelimited("*** fault: iova=%08lx, flags=%d\n", iova, flags);
+   pr_warn_ratelimited("*** fault: iova=%16lx, flags=%d\n", iova, flags);
return 0;
 }
 
-- 
2.16.1

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

[PATCH 06/14] iommu: arm-smmu: Add side-band function to specific pasid callbacks

[Jordan Crouse]

Just allowing a client driver to create and manage a
a software pasid isn't interesting if the client driver doesn't have
enough information about the pagetable to be able to use it. Add a
side band function for arm-smmu that lets the client device register
pasid operations to pass the relevant pagetable information to the
client driver whenever a new pasid is created or destroyed

Signed-off-by: Jordan Crouse 
---
 drivers/iommu/arm-smmu.c | 40 
 include/linux/arm-smmu.h | 18 ++
 2 files changed, 58 insertions(+)
 create mode 100644 include/linux/arm-smmu.h

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 42f5bfa3e26e..81c781705e22 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -253,6 +254,8 @@ struct arm_smmu_domain {
 
spinlock_t  pasid_lock;
struct list_headpasid_list;
+   const struct arm_smmu_pasid_ops *pasid_ops;
+   void*pasid_data;
 };
 
 struct arm_smmu_option_prop {
@@ -294,6 +297,10 @@ static void arm_smmu_pasid_free(struct iommu_domain 
*domain, int pasid)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_pasid *node, *obj = NULL;
 
+   if (smmu_domain->pasid_ops && smmu_domain->pasid_ops->remove_pasid)
+   smmu_domain->pasid_ops->remove_pasid(pasid,
+   smmu_domain->pasid_data);
+
spin_lock(_domain->pasid_lock);
list_for_each_entry(node, _domain->pasid_list, node) {
if (node->pasid == pasid) {
@@ -386,6 +393,26 @@ static int arm_smmu_pasid_alloc(struct iommu_domain 
*domain, struct device *dev,
obj->domain = domain;
obj->pasid = pasid;
 
+   if (smmu_domain->pasid_ops && smmu_domain->pasid_ops->install_pasid) {
+   int ret;
+   u64 ttbr;
+
+   if (smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH32_S)
+   ttbr = pgtbl_cfg.arm_v7s_cfg.ttbr[0];
+   else
+   ttbr = pgtbl_cfg.arm_lpae_s1_cfg.ttbr[0];
+
+   ret = smmu_domain->pasid_ops->install_pasid(pasid, ttbr,
+   smmu_domain->cfg.asid, smmu_domain->pasid_data);
+
+   if (ret) {
+   free_io_pgtable_ops(obj->pgtbl_ops);
+   kfree(obj);
+
+   return ret;
+   }
+   }
+
spin_lock(_domain->pasid_lock);
list_add_tail(>node, _domain->pasid_list);
spin_unlock(_domain->pasid_lock);
@@ -2046,6 +2073,19 @@ static int arm_smmu_device_cfg_probe(struct 
arm_smmu_device *smmu)
return 0;
 }
 
+void arm_smmu_add_pasid_ops(struct iommu_domain *domain,
+   const struct arm_smmu_pasid_ops *ops, void *data)
+{
+   struct arm_smmu_domain *smmu_domain;
+
+   if (domain) {
+   smmu_domain = to_smmu_domain(domain);
+   smmu_domain->pasid_ops = ops;
+   smmu_domain->pasid_data = data;
+   }
+}
+EXPORT_SYMBOL_GPL(arm_smmu_add_pasid_ops);
+
 struct arm_smmu_match_data {
enum arm_smmu_arch_version version;
enum arm_smmu_implementation model;
diff --git a/include/linux/arm-smmu.h b/include/linux/arm-smmu.h
new file mode 100644
index ..c14ca52231bf
--- /dev/null
+++ b/include/linux/arm-smmu.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
+
+#ifndef ARM_SMMU_H_
+#define ARM_SMMU_H_
+
+struct iommu_domain;
+
+struct arm_smmu_pasid_ops {
+   int (*install_pasid)(int pasid, u64 ttbr, u32 asid, void *data);
+   void (*remove_pasid)(int pasid, void *data);
+};
+
+
+void arm_smmu_add_pasid_ops(struct iommu_domain *domain,
+   const struct arm_smmu_pasid_ops *ops, void *data);
+
+#endif
-- 
2.16.1

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

[PATCH 05/14] iommu: arm-smmu: Add pasid implementation

[Jordan Crouse]

Add support for allocating and populating pagetables
indexed by pasid. Each new pasid is allocated a pagetable
with the same parameters and format as the parent domain.

Signed-off-by: Jordan Crouse 
---
 drivers/iommu/arm-smmu.c | 148 +--
 1 file changed, 143 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ebfa59b59622..42f5bfa3e26e 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -250,6 +250,9 @@ struct arm_smmu_domain {
spinlock_t  cb_lock; /* Serialises ATS1* ops and 
TLB syncs */
u32 attributes;
struct iommu_domain domain;
+
+   spinlock_t  pasid_lock;
+   struct list_headpasid_list;
 };
 
 struct arm_smmu_option_prop {
@@ -257,6 +260,139 @@ struct arm_smmu_option_prop {
const char *prop;
 };
 
+static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
+{
+   return container_of(dom, struct arm_smmu_domain, domain);
+}
+
+struct arm_smmu_pasid {
+   struct iommu_domain *domain;
+   struct io_pgtable_ops   *pgtbl_ops;
+   struct list_head node;
+   int pasid;
+};
+
+struct arm_smmu_pasid *arm_smmu_get_pasid(struct arm_smmu_domain *smmu_domain,
+   int pasid)
+{
+   struct arm_smmu_pasid *node, *obj = NULL;
+
+   spin_lock(_domain->pasid_lock);
+   list_for_each_entry(node, _domain->pasid_list, node) {
+   if (node->pasid == pasid) {
+   obj = node;
+   break;
+   }
+   }
+   spin_unlock(_domain->pasid_lock);
+
+   return obj;
+}
+
+static void arm_smmu_pasid_free(struct iommu_domain *domain, int pasid)
+{
+   struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+   struct arm_smmu_pasid *node, *obj = NULL;
+
+   spin_lock(_domain->pasid_lock);
+   list_for_each_entry(node, _domain->pasid_list, node) {
+   if (node->pasid == pasid) {
+   obj = node;
+   list_del(>node);
+   break;
+   }
+   }
+   spin_unlock(_domain->pasid_lock);
+
+   if (obj)
+   free_io_pgtable_ops(obj->pgtbl_ops);
+
+   kfree(obj);
+}
+
+static size_t arm_smmu_sva_unmap(struct iommu_domain *domain, int pasid,
+   unsigned long iova, size_t size)
+{
+   struct arm_smmu_pasid *obj =
+   arm_smmu_get_pasid(to_smmu_domain(domain), pasid);
+
+   if (!obj)
+   return -ENODEV;
+
+   return obj->pgtbl_ops->unmap(obj->pgtbl_ops, iova, size);
+}
+
+
+static int arm_smmu_sva_map(struct iommu_domain *domain, int pasid,
+   unsigned long iova, phys_addr_t paddr, size_t size, int prot)
+{
+   struct arm_smmu_pasid *obj =
+   arm_smmu_get_pasid(to_smmu_domain(domain), pasid);
+
+   if (!obj)
+   return -ENODEV;
+
+   return obj->pgtbl_ops->map(obj->pgtbl_ops, iova, paddr, size, prot);
+}
+
+static int arm_smmu_pasid_alloc(struct iommu_domain *domain, struct device 
*dev,
+   int pasid)
+{
+   struct arm_smmu_pasid *obj;
+   struct io_pgtable_cfg pgtbl_cfg;
+   struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+   struct arm_smmu_device *smmu = smmu_domain->smmu;
+   enum io_pgtable_fmt fmt;
+   unsigned long ias, oas;
+
+   /* Only allow pasid backed tables to be created on S1 domains */
+   if (smmu_domain->stage != ARM_SMMU_DOMAIN_S1)
+   return -EINVAL;
+
+   obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+   if (!obj)
+   return -ENOMEM;
+
+   /* Get the same exact format as the parent domain */
+   ias = smmu->va_size;
+   oas = smmu->ipa_size;
+
+   if (smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH64)
+   fmt = ARM_64_LPAE_S1;
+   else if (smmu_domain->cfg.fmt == ARM_SMMU_CTX_FMT_AARCH32_L) {
+   fmt = ARM_32_LPAE_S1;
+   ias = min(ias, 32UL);
+   oas = min(oas, 40UL);
+   } else {
+   fmt = ARM_V7S;
+   ias = min(ias, 32UL);
+   oas = min(oas, 32UL);
+   }
+
+   pgtbl_cfg = (struct io_pgtable_cfg) {
+   .pgsize_bitmap = smmu->pgsize_bitmap,
+   .ias = ias,
+   .oas = oas,
+   .tlb = NULL,
+   .iommu_dev = smmu->dev
+   };
+
+   obj->pgtbl_ops = alloc_io_pgtable_ops(fmt, _cfg, smmu_domain);
+   if (!obj->pgtbl_ops) {
+   kfree(obj);
+   return -ENOMEM;
+   }
+
+   obj->domain = domain;
+   obj->pasid = pasid;
+
+   spin_lock(_domain->pasid_lock);
+   list_add_tail(>node, _domain->pasid_list);
+   spin_unlock(_domain->pasid_lock);
+
+   return 0;
+}
+
 static atomic_t cavium_smmu_context_count = 

[PATCH 03/14] iommu: Create a base struct for io_mm

[Jordan Crouse]

In order to support both shared mm sva pagetables as well as
io-pgtable backed tables add a base structure to
io_mm so that the two styles can share the same idr.

Signed-off-by: Jordan Crouse 
---
 drivers/iommu/arm-smmu-v3.c |  8 
 drivers/iommu/iommu-sva.c   | 50 ++---
 include/linux/iommu.h   | 11 +-
 3 files changed, 47 insertions(+), 22 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 26935a9a5a97..4736a2bf39cf 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2454,7 +2454,7 @@ static int arm_smmu_mm_attach(struct iommu_domain 
*domain, struct device *dev,
if (!attach_domain)
return 0;
 
-   return ops->set_entry(ops, io_mm->pasid, smmu_mm->cd);
+   return ops->set_entry(ops, io_mm->base.pasid, smmu_mm->cd);
 }
 
 static void arm_smmu_mm_detach(struct iommu_domain *domain, struct device *dev,
@@ -2466,9 +2466,9 @@ static void arm_smmu_mm_detach(struct iommu_domain 
*domain, struct device *dev,
struct arm_smmu_master_data *master = dev->iommu_fwspec->iommu_priv;
 
if (detach_domain)
-   ops->clear_entry(ops, io_mm->pasid, smmu_mm->cd);
+   ops->clear_entry(ops, io_mm->base.pasid, smmu_mm->cd);
 
-   arm_smmu_atc_inv_master_all(master, io_mm->pasid);
+   arm_smmu_atc_inv_master_all(master, io_mm->base.pasid);
/* TODO: Invalidate all mappings if last and not DVM. */
 }
 
@@ -2478,7 +2478,7 @@ static void arm_smmu_mm_invalidate(struct iommu_domain 
*domain,
 {
struct arm_smmu_master_data *master = dev->iommu_fwspec->iommu_priv;
 
-   arm_smmu_atc_inv_master_range(master, io_mm->pasid, iova, size);
+   arm_smmu_atc_inv_master_range(master, io_mm->base.pasid, iova, size);
/*
 * TODO: Invalidate mapping if not DVM
 */
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index d7b231cd7355..5fc689b1ef72 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -161,13 +161,15 @@ io_mm_alloc(struct iommu_domain *domain, struct device 
*dev,
io_mm->mm   = mm;
io_mm->notifier.ops = _mmu_notifier;
io_mm->release  = domain->ops->mm_free;
+   io_mm->base.type= IO_TYPE_MM;
+
INIT_LIST_HEAD(_mm->devices);
 
idr_preload(GFP_KERNEL);
spin_lock(_sva_lock);
-   pasid = idr_alloc_cyclic(_pasid_idr, io_mm, dev_param->min_pasid,
-dev_param->max_pasid + 1, GFP_ATOMIC);
-   io_mm->pasid = pasid;
+   pasid = idr_alloc_cyclic(_pasid_idr, _mm->base,
+   dev_param->min_pasid, dev_param->max_pasid + 1, GFP_ATOMIC);
+   io_mm->base.pasid = pasid;
spin_unlock(_sva_lock);
idr_preload_end();
 
@@ -200,7 +202,7 @@ io_mm_alloc(struct iommu_domain *domain, struct device *dev,
 * 0 so no user could get a reference to it. Free it manually.
 */
spin_lock(_sva_lock);
-   idr_remove(_pasid_idr, io_mm->pasid);
+   idr_remove(_pasid_idr, io_mm->base.pasid);
spin_unlock(_sva_lock);
 
 err_free_mm:
@@ -231,7 +233,7 @@ static void io_mm_release(struct kref *kref)
io_mm = container_of(kref, struct io_mm, kref);
WARN_ON(!list_empty(_mm->devices));
 
-   idr_remove(_pasid_idr, io_mm->pasid);
+   idr_remove(_pasid_idr, io_mm->base.pasid);
 
/*
 * If we're being released from mm exit, the notifier callback ->release
@@ -286,7 +288,7 @@ static int io_mm_attach(struct iommu_domain *domain, struct 
device *dev,
 {
int ret;
bool attach_domain = true;
-   int pasid = io_mm->pasid;
+   int pasid = io_mm->base.pasid;
struct iommu_bond *bond, *tmp;
struct iommu_param *dev_param = dev->iommu_param;
 
@@ -378,7 +380,7 @@ static int iommu_signal_mm_exit(struct iommu_bond *bond)
if (!dev->iommu_param || !dev->iommu_param->mm_exit)
return 0;
 
-   return dev->iommu_param->mm_exit(dev, io_mm->pasid, bond->drvdata);
+   return dev->iommu_param->mm_exit(dev, io_mm->base.pasid, bond->drvdata);
 }
 
 /*
@@ -410,7 +412,7 @@ static void iommu_notifier_release(struct mmu_notifier *mn, 
struct mm_struct *mm
list_for_each_entry_safe(bond, next, _mm->devices, mm_head) {
if (iommu_signal_mm_exit(bond))
dev_WARN(bond->dev, "possible leak of PASID %u",
-io_mm->pasid);
+io_mm->base.pasid);
 
io_mm_detach_all_locked(bond);
}
@@ -585,6 +587,7 @@ int iommu_sva_bind_device(struct device *dev, struct 
mm_struct *mm, int *pasid,
  unsigned long flags, void *drvdata)
 {
int i, ret;
+   struct io_base *io_base = NULL;
struct io_mm *io_mm = NULL;
struct iommu_domain *domain;
struct 

[RFC 00/14] Per-instance pagetables for MSM GPUs

[Jordan Crouse]

This is a request for comment for support in the iommu, arm-smmu
and MSM GPU driver to support per (GPU) instance pagetables.

The general idea behind per-instance pagetables is that each GPU
client can have its own pagetable and virtual memory space which
prevents malicious or accidental corruption or copying.  We say
per-instance because the pagetables are unique to each DRM file
handle and there could be multiple instances per process.

In newer arm-smmu implementations this behavior could be managed
with hardware based PASIDs (see Jean Phillipe's epic SVA
stack https://patchwork.kernel.org/patch/10214963/)
but all the MSM GPU implementations in existence use
arm-smmu-v2 which doesn't have the ability to support switching
pagetables in hardware. As a result the vendor has added a bit
of hardware specific glue to allow the GPU microcode to switch
the pagetable asynchronously during execution (basically it
reaches out and reprograms some of the context bank registers).

To support all of this we need a handful of changes to allow
the client driver to create a properly formatted pagetable and
directly map and unmap buffers inside of that pagetable and
get the parameters (i.e. the physical address of the pagetable)
to program into the GPU at the appropriate time.

This stack builds on the aforementioned code from Jean-Phillipe to
add the needed support to iommu core and arm-smmu and then implement
per-instance pagetables in the MSM DRM GPU driver for the a5xx
family (tested on the db820c).

The first two patches add support to create enable a TTBR1 pagetable
for arm-smmuv-2 if the appropriate domain attribute is selected.
It creates a pagetable and programs the appropriate registers to
enable TTBR1.  The sign extension bit is programmed as the highest
bit in the ibs region (or the special 48th bit when the UBS is 49
bits).  The correct pagetable is automatically selected for
map/unmap based on the sign extension bit.

The next three patches add "virtual" pasid support. This allows
a client to allocate a pasid which is an index to a pagetable
structure. The pasid token is used to map and unmap entries
in that pagetable structure.  The existing pasid idr for SVA
is reused so that clients that also support hardware PASID
entries can use both types if they wish.

Th next patch adds a special side-band function for arm-smmu
that registers two callbacks to inform the client driver when
a new pasid is created/destroyed. This allows the arm-smmu
driver to pass the pagetable information (ttbr and asid) to
the client without needing changes to the IOMMU core.

All the following patches are for the DRM/GPU driver.  The
first enables 64 bit mode for a5xx which lets us use all
48 bits.  The next patch 5 patches are infrastructure patches
to cleanup address spaces and prepare for having a per-instance
address space and the final patch enables per-instance pagetables
for a5xx and implements the PM4 to switch the pagetable at create
time.

Please know that nearly all of this is up for discussion. In particular
since we all know that the two hardest problems in computer science are
caches, naming and off-by-one errors I am open to fixing the vocabulary
and terminology for "pasid" and "per-instance" and whatever - please
paint that bikeshed if you feel so inclined. Thanks for reading this
far. On with the code.

Applies against git://linux-arm.org/linux-jpb.git sva/v1

Jordan Crouse (14):
  iommu: Add DOMAIN_ATTR_ENABLE_TTBR1
  iommu/arm-smmu: Add support for TTBR1
  iommu: Create a base struct for io_mm
  iommu: sva: Add support for pasid allocation
  iommu: arm-smmu: Add pasid implementation
  iommu: arm-smmu: Add side-band function to specific pasid callbacks
  drm/msm: Enable 64 bit mode by default
  drm/msm: Pass the MMU domain index in struct msm_file_private
  drm/msm/gpu: Support using TTBR1 for kernel buffer objects
  drm/msm: Add msm_mmu features
  drm/msm: Add support for iommu-sva PASIDs
  drm/msm: Add support for per-instance address spaces
  drm/msm: Support per-instance address spaces
  drm/msm/a5xx: Support per-instance pagetables

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  69 +++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  17 ++
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c |  76 ++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |  11 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |   5 +
 drivers/gpu/drm/msm/msm_drv.c |  45 +++--
 drivers/gpu/drm/msm/msm_drv.h |   4 +
 drivers/gpu/drm/msm/msm_gem.h |   1 +
 drivers/gpu/drm/msm/msm_gem_submit.c  |  13 +-
 drivers/gpu/drm/msm/msm_gem_vma.c |  36 +++-
 drivers/gpu/drm/msm/msm_gpu.c |  25 ++-
 drivers/gpu/drm/msm/msm_gpu.h |   4 +-
 drivers/gpu/drm/msm/msm_iommu.c   | 186 ++-
 drivers/gpu/drm/msm/msm_mmu.h |  19 ++
 drivers/gpu/drm/msm/msm_ringbuffer.h  |   1 +
 drivers/iommu/arm-smmu-regs.h |   2 -
 drivers/iommu/arm-smmu-v3.c 

[PATCH 02/14] iommu/arm-smmu: Add support for TTBR1

[Jordan Crouse]

Allow a SMMU device to opt into allocating a TTBR1 pagetable.

The size of the TTBR1 region will be the same as
the TTBR0 size with the sign extension bit set on the highest
bit in the region unless the upstream size is 49 bits and then
the sign-extension bit will be set on the 49th bit.

The map/unmap operations will automatically use the appropriate
pagetable based on the specified iova and the existing mask.

Signed-off-by: Jordan Crouse 
---
 drivers/iommu/arm-smmu-regs.h  |   2 -
 drivers/iommu/arm-smmu.c   |  22 --
 drivers/iommu/io-pgtable-arm.c | 160 -
 drivers/iommu/io-pgtable-arm.h |  20 ++
 drivers/iommu/io-pgtable.h |  16 -
 5 files changed, 192 insertions(+), 28 deletions(-)

diff --git a/drivers/iommu/arm-smmu-regs.h b/drivers/iommu/arm-smmu-regs.h
index a1226e4ab5f8..0ce85d5b22e9 100644
--- a/drivers/iommu/arm-smmu-regs.h
+++ b/drivers/iommu/arm-smmu-regs.h
@@ -193,8 +193,6 @@ enum arm_smmu_s2cr_privcfg {
 #define RESUME_RETRY   (0 << 0)
 #define RESUME_TERMINATE   (1 << 0)
 
-#define TTBCR2_SEP_SHIFT   15
-#define TTBCR2_SEP_UPSTREAM(0x7 << TTBCR2_SEP_SHIFT)
 #define TTBCR2_AS  (1 << 4)
 
 #define TTBRn_ASID_SHIFT   48
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60792a8..ebfa59b59622 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -248,6 +248,7 @@ struct arm_smmu_domain {
enum arm_smmu_domain_stage  stage;
struct mutexinit_mutex; /* Protects smmu pointer */
spinlock_t  cb_lock; /* Serialises ATS1* ops and 
TLB syncs */
+   u32 attributes;
struct iommu_domain domain;
 };
 
@@ -598,7 +599,6 @@ static void arm_smmu_init_context_bank(struct 
arm_smmu_domain *smmu_domain,
} else {
cb->tcr[0] = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
cb->tcr[1] = pgtbl_cfg->arm_lpae_s1_cfg.tcr >> 32;
-   cb->tcr[1] |= TTBCR2_SEP_UPSTREAM;
if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH64)
cb->tcr[1] |= TTBCR2_AS;
}
@@ -729,6 +729,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain 
*domain,
enum io_pgtable_fmt fmt;
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_cfg *cfg = _domain->cfg;
+   unsigned int quirks =
+   smmu_domain->attributes & (1 << DOMAIN_ATTR_ENABLE_TTBR1) ?
+   IO_PGTABLE_QUIRK_ARM_TTBR1 : 0;
 
mutex_lock(_domain->init_mutex);
if (smmu_domain->smmu)
@@ -852,7 +855,11 @@ static int arm_smmu_init_domain_context(struct 
iommu_domain *domain,
else
cfg->asid = cfg->cbndx + smmu->cavium_id_base;
 
+   if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
+   quirks |= IO_PGTABLE_QUIRK_NO_DMA;
+
pgtbl_cfg = (struct io_pgtable_cfg) {
+   .quirks = quirks,
.pgsize_bitmap  = smmu->pgsize_bitmap,
.ias= ias,
.oas= oas,
@@ -860,9 +867,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain 
*domain,
.iommu_dev  = smmu->dev,
};
 
-   if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
-   pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_NO_DMA;
-
smmu_domain->smmu = smmu;
pgtbl_ops = alloc_io_pgtable_ops(fmt, _cfg, smmu_domain);
if (!pgtbl_ops) {
@@ -1477,6 +1481,10 @@ static int arm_smmu_domain_get_attr(struct iommu_domain 
*domain,
case DOMAIN_ATTR_NESTING:
*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
return 0;
+   case DOMAIN_ATTR_ENABLE_TTBR1:
+   *((int *)data) = !!(smmu_domain->attributes
+   & (1 << DOMAIN_ATTR_ENABLE_TTBR1));
+   return 0;
default:
return -ENODEV;
}
@@ -1505,6 +1513,12 @@ static int arm_smmu_domain_set_attr(struct iommu_domain 
*domain,
else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
 
+   break;
+   case DOMAIN_ATTR_ENABLE_TTBR1:
+   if (*((int *)data))
+   smmu_domain->attributes |=
+   1 << DOMAIN_ATTR_ENABLE_TTBR1;
+   ret = 0;
break;
default:
ret = -ENODEV;
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index fff0b6ba0a69..1bd0045f2cb7 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -152,7 +152,7 @@ struct arm_lpae_io_pgtable {
unsigned long   pg_shift;
unsigned long   bits_per_level;
 
-   void  

[PATCH 01/14] iommu: Add DOMAIN_ATTR_ENABLE_TTBR1

[Jordan Crouse]

Add a new domain attribute to enable the TTBR1 pagetable for drivers
and devices that support it.  This will enabled using a TTBR1 (otherwise
known as a "global" or "system" pagetable for devices that support a split
pagetable scheme for switching pagetables quickly and safely.

Signed-off-by: Jordan Crouse 
---
 include/linux/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 641aaf0f1b81..e2c49e583d8d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -153,6 +153,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMU_ENABLE,
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
+   DOMAIN_ATTR_ENABLE_TTBR1,
DOMAIN_ATTR_MAX,
 };
 
-- 
2.16.1

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

Re: [PATCH] drm/nouveau: prefer XBGR2101010 for addfb ioctl

[Ben Skeggs]

On Thu, Feb 22, 2018 at 3:20 AM, Ilia Mirkin  wrote:
> On Mon, Feb 19, 2018 at 4:33 AM, Daniel Vetter  wrote:
>> On Mon, Feb 19, 2018 at 10:21:54AM +0100, Daniel Vetter wrote:
>>> On Mon, Feb 05, 2018 at 09:10:12AM -0500, Ilia Mirkin wrote:
>>> > On Mon, Feb 5, 2018 at 8:58 AM, Ville Syrjälä
>>> >  wrote:
>>> > > On Sat, Feb 03, 2018 at 02:11:23PM -0500, Ilia Mirkin wrote:
>>> > >> Nouveau only exposes support for XBGR2101010. Prior to the atomic
>>> > >> conversion, drm would pass in the wrong format in the framebuffer, but
>>> > >> it was always ignored -- both userspace (xf86-video-nouveau) and the
>>> > >> kernel driver agreed on the layout, so the fact that the format was
>>> > >> wrong didn't matter.
>>> > >>
>>> > >> With the atomic conversion, nouveau all of a sudden started caring 
>>> > >> about
>>> > >> the exact format, and so the previously-working code in
>>> > >> xf86-video-nouveau no longer functioned since the (internally-assigned)
>>> > >> format from the addfb ioctl was wrong.
>>> > >>
>>> > >> This change adds infrastructure to allow a drm driver to specify that 
>>> > >> it
>>> > >> prefers the XBGR format variant for the addfb ioctl, and makes 
>>> > >> nouveau's
>>> > >> nv50 display driver set it. (Prior gens had no support for 30bpp at 
>>> > >> all.)
>>> > >>
>>> > >> Signed-off-by: Ilia Mirkin 
>>> > >> Cc: sta...@vger.kernel.org # v4.10+
>>> > >> ---
>>> > >>
>>> > >> Wasn't sure if the nouveau line needs to be split out into a separate
>>> > >> change or not.
>>> > >>
>>> > >>  drivers/gpu/drm/drm_framebuffer.c  | 4 
>>> > >>  drivers/gpu/drm/nouveau/nv50_display.c | 1 +
>>> > >>  include/drm/drm_drv.h  | 1 +
>>> > >>  3 files changed, 6 insertions(+)
>>> > >>
>>> > >> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>>> > >> b/drivers/gpu/drm/drm_framebuffer.c
>>> > >> index 5a13ff29f4f0..c0530a1af5e3 100644
>>> > >> --- a/drivers/gpu/drm/drm_framebuffer.c
>>> > >> +++ b/drivers/gpu/drm/drm_framebuffer.c
>>> > >> @@ -121,6 +121,10 @@ int drm_mode_addfb(struct drm_device *dev,
>>> > >>   r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
>>> > >>   r.handles[0] = or->handle;
>>> > >>
>>> > >> + if (r.pixel_format == DRM_FORMAT_XRGB2101010 &&
>>> > >> + dev->driver->driver_features & DRIVER_PREFER_XBGR_30BPP)
>>> > >> + r.pixel_format = DRM_FORMAT_XBGR2101010;
>>> > >
>>> > > I think I'd much prefer if the driver just passed some kind of a
>>> > > bpp/depth->format mapping table to the core, or maybe an optional
>>> > > vfunc to allow the driver to override drm_mode_legacy_fb_format()
>>> > > behaviour.
>>> > >
>>> > > drm_mode_legacy_fb_format() is called from the fbdev setup as well
>>> > > so handling this only in addfb doesn't look sufficient.
>>> >
>>> > Well, in practice fbdev won't pick a 30bpp mode. But I get the point.
>>> > It would also enable a driver to have a funky RGB ordering for depth
>>> > 24/32 and others. Although I don't know if there are any customers for
>>> > that in practice.
>>> >
>>> > A vfunc works for me.
>>> >
>>> > Anyone else want to opine before I go for it? I'm happy to do the
>>> > work, but want to make sure I'm not just doing things that'll get
>>> > rejected, as I have a limited amount of time to do these things.
>>>
>>> Imo the very obvious hack is totally fine, makes it stick out more that we
>>> have a fairly nasty uapi inconsistency here.
>>>
>>> Also vfunc or explicit table open up the door for even more driver abuse
>>> in the future, which I don't like. vfunc for 1 case ever is also overkill.
>>>
>>> Wrt fbdev: Linus seems to have volunteered to switch fbdev from depth/bpp
>>> to explicit pixel formats, so no worries.
>>
>> Forgot to add the most important bit.
>>
>> Reviewed-by: Daniel Vetter 
>>
>> Also ack for merging through -nouveau. Or ping me on irc if you want me to
>> apply it to drm-misc-next.
>
> Thanks!
>
> Ben, will you take this patch? Or is drm-misc a better route? (Patch
> at https://patchwork.freedesktop.org/patch/202322/)
I'm happy for it to go through -misc-next!

Ben.

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

Re: [PATCH v2] drm/panel: Fix ARM Versatile panel clocks

[Eric Anholt]

Linus Walleij  writes:

> These clocks are in kHz not in Hz, oops. Fix it so my
> new bandwidth calculations patch starts working with these
> panels.
>
> Cc: Eric Anholt 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - The Epson clock was still wrong, off by one order of
>   magnitude. It is now fixed. The only source of the actual
>   frequency to use is the old fbdev driver, as there is no
>   datasheet for this Epson panel that I can find, and it is
>   set to 62500 kHz.

Reviewed-by: Eric Anholt 


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

Re: [PATCH 4/4] drm/pl111: Do not use deprecated drm_driver.{enable|disable)_vblank

[Eric Anholt]

Oleksandr Andrushchenko  writes:

> From: Oleksandr Andrushchenko 
>
> Do not use deprecated drm_driver.{enable|disable)_vblank callbacks,
> but use drm_simple_kms_helpe's pipe callbacks instead.
>
> Signed-off-by: Oleksandr Andrushchenko 
> Cc: Eric Anholt 

Just got back from vacation today and got a chance to try it.

Reviewed-by: Eric Anholt 
Tested-by: Eric Anholt 


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

[Bug 105179] DiRT Rally: wrong frames appear during camera transition

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 CC||mdiluzio@feralinteractive.c
   ||om
 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #4 from Gregor Münch  ---
Have to confirm its really a game bug.
GTX 780:
https://youtu.be/jXk3jUuJJ8w?t=144

R9 390:
https://youtu.be/zht3LtKXUGY?t=83

Will open another bug for the stuttering. Looks smooth on nvidia and the r9
390, so its either a SI issue or something with my own configuration.

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

[PATCHv2 1/2] selftests: ion: Remove some prints

[Laura Abbott]

There's no need to print messages each time we alloc and free. Remove them.

Signed-off-by: Laura Abbott 
---
v2: No changes
---
 tools/testing/selftests/android/ion/ionutils.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/tools/testing/selftests/android/ion/ionutils.c 
b/tools/testing/selftests/android/ion/ionutils.c
index ce69c14f51fa..7d1d37c4ef6a 100644
--- a/tools/testing/selftests/android/ion/ionutils.c
+++ b/tools/testing/selftests/android/ion/ionutils.c
@@ -80,11 +80,6 @@ int ion_export_buffer_fd(struct ion_buffer_info *ion_info)
heap_id = MAX_HEAP_COUNT + 1;
for (i = 0; i < query.cnt; i++) {
if (heap_data[i].type == ion_info->heap_type) {
-   printf("--\n");
-   printf("heap type: %d\n", heap_data[i].type);
-   printf("  heap id: %d\n", heap_data[i].heap_id);
-   printf("heap name: %s\n", heap_data[i].name);
-   printf("--\n");
heap_id = heap_data[i].heap_id;
break;
}
@@ -204,7 +199,6 @@ void ion_close_buffer_fd(struct ion_buffer_info *ion_info)
/* Finally, close the client fd */
if (ion_info->ionfd > 0)
close(ion_info->ionfd);
-   printf("<%s>: buffer release successfully\n", __func__);
}
 }
 
-- 
2.14.3

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

[PATCHv2 0/2] Ion unit test with VGEM

[Laura Abbott]

Hi,

This is v2 of the series to add a unit test to Ion with VGEM. From v1:

Ion hasn't had much in the way of unit tests and fixing that is
something that needs to happen before it can move out of staging. The
difficult part of testing parts of Ion is that it relies on having a
kernel driver to actually make some of the dma_buf calls. The vgem
DRM driver exists mostly for testing and works great for this case.

Changes since v1:
- Dropped RFC
- Feedback/review from Daniel Vetter about DRM ioctls

Thanks,
Laura

Laura Abbott (2):
  selftests: ion: Remove some prints
  selftests: ion: Add simple test with the vgem driver

 tools/testing/selftests/android/ion/Makefile  |   3 +-
 tools/testing/selftests/android/ion/config|   1 +
 tools/testing/selftests/android/ion/ionmap_test.c | 149 ++
 tools/testing/selftests/android/ion/ionutils.c|   6 -
 4 files changed, 152 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c

-- 
2.14.3

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

[PATCHv2 2/2] selftests: ion: Add simple test with the vgem driver

[Laura Abbott]

Ion is designed to be a framework used by other clients who perform
operations on the buffer. Use the DRM vgem client as a simple consumer.
In conjunction with the dma-buf sync ioctls, this tests the full attach/map
path for the system heap.

Reviewed-by: Daniel Vetter 
Signed-off-by: Laura Abbott 
---
v2: Introduce drmIoctl wrapper per suggestion of Daniel Vetter to better
match how DRM ioctls actually work.
---
 tools/testing/selftests/android/ion/Makefile  |   3 +-
 tools/testing/selftests/android/ion/config|   1 +
 tools/testing/selftests/android/ion/ionmap_test.c | 149 ++
 3 files changed, 152 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/android/ion/ionmap_test.c

diff --git a/tools/testing/selftests/android/ion/Makefile 
b/tools/testing/selftests/android/ion/Makefile
index 96e0c448b39d..d23b6d537d8b 100644
--- a/tools/testing/selftests/android/ion/Makefile
+++ b/tools/testing/selftests/android/ion/Makefile
@@ -2,7 +2,7 @@
 INCLUDEDIR := -I. -I../../../../../drivers/staging/android/uapi/
 CFLAGS := $(CFLAGS) $(INCLUDEDIR) -Wall -O2 -g
 
-TEST_GEN_FILES := ionapp_export ionapp_import
+TEST_GEN_FILES := ionapp_export ionapp_import ionmap_test
 
 all: $(TEST_GEN_FILES)
 
@@ -14,3 +14,4 @@ include ../../lib.mk
 
 $(OUTPUT)/ionapp_export: ionapp_export.c ipcsocket.c ionutils.c
 $(OUTPUT)/ionapp_import: ionapp_import.c ipcsocket.c ionutils.c
+$(OUTPUT)/ionmap_test: ionmap_test.c ionutils.c
diff --git a/tools/testing/selftests/android/ion/config 
b/tools/testing/selftests/android/ion/config
index 19db6ca9aa2b..b4ad748a9dd9 100644
--- a/tools/testing/selftests/android/ion/config
+++ b/tools/testing/selftests/android/ion/config
@@ -2,3 +2,4 @@ CONFIG_ANDROID=y
 CONFIG_STAGING=y
 CONFIG_ION=y
 CONFIG_ION_SYSTEM_HEAP=y
+CONFIG_DRM_VGEM=y
diff --git a/tools/testing/selftests/android/ion/ionmap_test.c 
b/tools/testing/selftests/android/ion/ionmap_test.c
new file mode 100644
index ..58ecdc3511d2
--- /dev/null
+++ b/tools/testing/selftests/android/ion/ionmap_test.c
@@ -0,0 +1,149 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "ion.h"
+#include "ionutils.h"
+
+/* Local copy of drmIoctl to match the expected behavior */
+static int drmIoctl(int fd, unsigned long request, void *arg)
+{
+   int ret;
+
+   do {
+   ret = ioctl(fd, request, arg);
+   } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
+}
+
+int check_vgem(int fd)
+{
+   drm_version_t version = { 0 };
+   char name[5];
+   int ret;
+
+   version.name_len = 4;
+   version.name = name;
+
+   ret = drmIoctl(fd, DRM_IOCTL_VERSION, );
+   if (ret)
+   return 1;
+
+   return strcmp(name, "vgem");
+}
+
+int open_vgem(void)
+{
+   int i, fd;
+   const char *drmstr = "/dev/dri/card";
+
+   fd = -1;
+   for (i = 0; i < 16; i++) {
+   char name[80];
+
+   sprintf(name, "%s%u", drmstr, i);
+
+   fd = open(name, O_RDWR);
+   if (fd < 0)
+   continue;
+
+   if (check_vgem(fd)) {
+   close(fd);
+   continue;
+   } else {
+   break;
+   }
+
+   }
+   return fd;
+}
+
+int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+   struct drm_prime_handle import_handle = { 0 };
+   int ret;
+
+   import_handle.fd = dma_buf_fd;
+   import_handle.flags = 0;
+   import_handle.handle = 0;
+
+   ret = drmIoctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+   if (ret == 0)
+   *handle = import_handle.handle;
+   return ret;
+}
+
+void close_handle(int vgem_fd, uint32_t handle)
+{
+   struct drm_gem_close close = { 0 };
+
+   close.handle = handle;
+   drmIoctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+int main()
+{
+   int ret, vgem_fd;
+   struct ion_buffer_info info;
+   uint32_t handle = 0;
+   struct dma_buf_sync sync = { 0 };
+
+   info.heap_type = ION_HEAP_TYPE_SYSTEM;
+   info.heap_size = 4096;
+   info.flag_type = ION_FLAG_CACHED;
+
+   ret = ion_export_buffer_fd();
+   if (ret < 0) {
+   printf("ion buffer alloc failed\n");
+   return -1;
+   }
+
+   vgem_fd = open_vgem();
+   if (vgem_fd < 0) {
+   ret = vgem_fd;
+   printf("Failed to open vgem\n");
+   goto out_ion;
+   }
+
+   ret = import_vgem_fd(vgem_fd, info.buffd, );
+
+   if (ret < 0) {
+   printf("Failed to import buffer\n");
+   goto out_vgem;
+   }
+
+   /*
+* While not strictly drm, the drmIoctl properly handles restarting
+*/
+   sync.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW;
+   ret = 

[Bug 105177] amdgpu wrong colors with rx460 connected via hdmi

[bugzilla-daemon]

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

--- Comment #12 from Harry Wentland  ---
There's a mismatch in colorspace we program and tell the HDMI receiver because
we program the infoframe too early in our sequence. I'll send a patch tomorrow.

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

Re: [PATCH libdrm 1/2] intel: align reuse buffer's size on page size instead

[Chris Wilson]

Quoting James Xiong (2018-02-20 17:48:03)
> From: "Xiong, James" 
> 
> With gem_reuse enabled, when a buffer size is different than
> the sizes of buckets, it is aligned to the next bucket's size,
> which means about 25% more memory than the requested is allocated
> in the worst senario. For example:
> 
> Orignal sizeActual
> 32KB+1Byte  40KB
> .
> .
> .
> 8MB+1Byte   10MB
> .
> .
> .
> 96MB+1Byte  112MB
> 
> This is very memory expensive and make the reuse feature less
> favorable than it deserves to be.

The reuse feature also misses one important source: reusing temporaries
within a batch.
 
> This commit aligns the reuse buffer size on page size instead,
> the buffer whose size falls between bucket[n] and bucket[n+1] is
> put in bucket[n] when it's done; And when searching for a cached
> buffer for reuse, it goes through the cached buffers list in the
> bucket until a cached buffer, whose size is larger than or equal
> to the requested size, is found.

So how many times do you have to allocate a new buffer because you
refused to hand back a slightly larger buffer? Have you checked the
impact on !llc? With mmaps? On how wide a workload?

> Signed-off-by: Xiong, James 
> ---
>  intel/intel_bufmgr_gem.c | 180 
> +--
>  libdrm_lists.h   |   6 ++
>  2 files changed, 101 insertions(+), 85 deletions(-)
> 
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 386da30..5b2d0d0 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -402,11 +402,10 @@ drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem 
> *bufmgr_gem,
>  {
> int i;
>  
> -   for (i = 0; i < bufmgr_gem->num_buckets; i++) {
> -   struct drm_intel_gem_bo_bucket *bucket =
> -   _gem->cache_bucket[i];
> -   if (bucket->size >= size) {
> -   return bucket;
> +   for (i = 0; i < bufmgr_gem->num_buckets - 1; i++) {
> +   if (size >= bufmgr_gem->cache_bucket[i].size &&
> +   size < bufmgr_gem->cache_bucket[i+1].size) {
> +   return _gem->cache_bucket[i];

So you never return the last bucket?

Given the ordered set of buckets, the test remains correct even when
every bo within the bucket is not the full size (each bo is still at
least bigger than the previous bucket).

> }
> }
>  
> @@ -685,25 +684,95 @@ drm_intel_gem_bo_madvise(drm_intel_bo *bo, int madv)
>  madv);
>  }
>  
> -/* drop the oldest entries that have been purged by the kernel */
> +/* drop the entries that are older than the given time */
>  static void
>  drm_intel_gem_bo_cache_purge_bucket(drm_intel_bufmgr_gem *bufmgr_gem,
> -   struct drm_intel_gem_bo_bucket *bucket)
> +   struct drm_intel_gem_bo_bucket *bucket,
> +   time_t time)
>  {
> -   while (!DRMLISTEMPTY(>head)) {
> -   drm_intel_bo_gem *bo_gem;
> -
> -   bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
> - bucket->head.next, head);
> -   if (drm_intel_gem_bo_madvise_internal
> -   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED))
> -   break;
> -
> -   DRMLISTDEL(_gem->head);
> -   drm_intel_gem_bo_free(_gem->bo);
> +   drm_intel_bo_gem *bo_gem, *temp;
> +   DRMLISTFOREACHENTRYSAFE(bo_gem, temp, >head, head) {
> +   if (bo_gem->free_time >= time) {
> +   drm_intel_gem_bo_madvise_internal
> +   (bufmgr_gem, bo_gem, I915_MADV_DONTNEED);
> +   DRMLISTDEL(_gem->head);
> +   drm_intel_gem_bo_free(_gem->bo);
> +   }

This function is called after the kernel reports that it purged a
buffer, and the intent here is that we find all the buffers that the
kernel purged and evict them. It is not about discarding old buffers,
just throwing out the empty.

Honestly, it's pointless. The cost of having the empty purged bo around
is insignificant (we reclaim a little bit of mmap virtual space
quicker).

> }
>  }
>  
> +static drm_intel_bo_gem *
> +drm_intel_gem_bo_cached_for_size(drm_intel_bufmgr_gem *bufmgr_gem,
> + unsigned long size,
> + uint32_t tiling_mode,
> + unsigned long stride,
> + unsigned long alignment,
> + bool for_render)
> +{
> +   struct drm_intel_gem_bo_bucket *bucket =
> +   drm_intel_gem_bo_bucket_for_size(bufmgr_gem, size);
> +
> +   if(bucket != NULL) {
> +   drm_intel_bo_gem *bo_gem, *temp_bo_gem;
> +retry:
> +   bo_gem = NULL;
> +   if (for_render) {
> + 

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #18 from dwagner  ---
(In reply to Alex Deucher from comment #17)
> amd-staging-drm-next is still based on 4.15-rc4 which still has the
> regression mentioned in comment 14.  Can you try 4.15 final or my
> drm-next-4.17-wip branch?

Just did this - but no change of symptoms, still crash upon every S3 resume
attempt.

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

[Bug 105177] amdgpu wrong colors with rx460 connected via hdmi

[bugzilla-daemon]

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

--- Comment #11 from Reimar Imhof  ---
btw, all tests were done with amdgpu.dc=1, because suse configured the kernel
that way.

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

[Bug 105177] amdgpu wrong colors with rx460 connected via hdmi

[bugzilla-daemon]

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

--- Comment #10 from Reimar Imhof  ---
Created attachment 137514
  --> https://bugs.freedesktop.org/attachment.cgi?id=137514=edit
x.org.log (dvi)

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

[Bug 105177] amdgpu wrong colors with rx460 connected via hdmi

[bugzilla-daemon]

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

--- Comment #9 from Reimar Imhof  ---
Created attachment 137513
  --> https://bugs.freedesktop.org/attachment.cgi?id=137513=edit
x.org.log (hdmi)

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

[Bug 105177] amdgpu wrong colors with rx460 connected via hdmi

[bugzilla-daemon]

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

--- Comment #8 from Reimar Imhof  ---
Created attachment 137512
  --> https://bugs.freedesktop.org/attachment.cgi?id=137512=edit
desktop (dvi) - console is black, like expected

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

[Bug 105177] amdgpu wrong colors with rx460 connected via hdmi

[bugzilla-daemon]

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

--- Comment #7 from Reimar Imhof  ---
Created attachment 137511
  --> https://bugs.freedesktop.org/attachment.cgi?id=137511=edit
desktop (hdmi) - console should be black but is violet

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

[Bug 105177] amdgpu wrong colors with rx460 connected via hdmi

[bugzilla-daemon]

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

--- Comment #6 from Reimar Imhof  ---
Created attachment 137510
  --> https://bugs.freedesktop.org/attachment.cgi?id=137510=edit
framebuffer console via hdmi

frame buffer console should be black but is violet (hdmi)

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

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

[Emil Velikov]

On 20 February 2018 at 13:12, Peter Zijlstra  wrote:
> On Tue, Feb 20, 2018 at 01:58:26PM +0100, Christian König wrote:
>> amdgpu needs to verify if userspace sends us valid addresses and the simplest
>> way of doing this is to check if the buffer object is locked with the ticket
>> of the current submission.
>>
>> Clean up the access to the ww_mutex internals by providing a function
>> for this and extend the check to the thread owning the underlying mutex.
>
>> Signed-off-by: Christian König 
>
> Much thanks for Cc'ing the relevant maintainers :/
>
Doubt it's intentional. The get-maintainer script seems confused and
lists no maintainers?

$ ./scripts/get_maintainer.pl include/linux/ww_mutex.h
linux-ker...@vger.kernel.org (open list)

While the normal mutex header works fine.

$ ./scripts/get_maintainer.pl include/linux/mutex.h
Peter Zijlstra  (maintainer:LOCKING PRIMITIVES)
Ingo Molnar  (maintainer:LOCKING PRIMITIVES)
linux-ker...@vger.kernel.org (open list:LOCKING PRIMITIVES)

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

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

[Daniel Vetter]

On Tue, Feb 20, 2018 at 10:14:47PM -0800, Chad Versace wrote:
> On Thu 21 Dec 2017, Daniel Vetter wrote:
> > On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen 
> >  wrote:
> >> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico  
> >> wrote:
> >>> On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg 
> >>>  wrote:
>  I'd like to see concrete examples of actual display controllers
>  supporting more format layouts than what can be specified with a 64
>  bit modifier.
> >>>
> >>> The main problem is our tiling and other metadata parameters can't
> >>> generally fit in a modifier, so we find passing a blob of metadata a
> >>> more suitable mechanism.
> >>
> >> I understand that you may have n knobs with a total of more than a total of
> >> 56 bits that configure your tiling/swizzling for color buffers. What I 
> >> don't
> >> buy is that you need all those combinations when passing buffers around
> >> between codecs, cameras and display controllers. Even if you're sharing
> >> between the same 3D drivers in different processes, I expect just locking
> >> down, say, 64 different combinations (you can add more over time) and
> >> assigning each a modifier would be sufficient. I doubt you'd extract
> >> meaningful performance gains from going all the way to a blob.
> 
> I agree with Kristian above. In my opinion, choosing to encode in
> modifiers a precise description of every possible tiling/compression
> layout is not technically incorrect, but I believe it misses the point.
> The intention behind modifiers is not to exhaustively describe all
> possibilites.
> 
> I summarized this opinion in VK_EXT_image_drm_format_modifier,
> where I wrote an "introdution to modifiers" section. Here's an excerpt:
> 
> One goal of modifiers in the Linux ecosystem is to enumerate for each
> vendor a reasonably sized set of tiling formats that are appropriate for
> images shared across processes, APIs, and/or devices, where each
> participating component may possibly be from different vendors.
> A non-goal is to enumerate all tiling formats supported by all vendors.
> Some tiling formats used internally by vendors are inappropriate for
> sharing; no modifiers should be assigned to such tiling formats.

fwiw (since the source of truth wrt modifiers is the kernel's uapi
header):

Acked-by: Daniel Vetter 

I'm happy to merge modifier #define additions for pretty much anything
where there's a need for sharing across devices/drivers/apis, explicitly
including stuff that's only relevant for userspace and which the kernel
nevers sees (in e.g. a kms addfb2 call). Trying to preemptively enumerate
everything that's possible doesn't seem like a wise idea. But even then we
can probably spare the oddball vendor prefix is a driver team really
insists that this is what they want, best using some code that makes the
case for them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/8] drm/blend: Add a generic alpha property

[Laurent Pinchart]

Hi Daniel,

On Monday, 19 February 2018 23:58:40 EET Daniel Vetter wrote:
> On Mon, Feb 19, 2018 at 9:19 PM, Laurent Pinchart wrote:
> > On Friday, 16 February 2018 20:20:41 EET Ville Syrjälä wrote:
> >> On Fri, Feb 16, 2018 at 06:39:29PM +0100, Maxime Ripard wrote:
> >> Some drivers duplicate the logic to create a property to store a
> >>> per-plane alpha.
> >>> 
> >>> This is especially useful if we ever want to support extra protocols
> >>> for Wayland like:
> >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741
> >>> .html
> >>> 
> >>> Let's create a helper in order to move that to the core.
> >>> 
> >>> Cc: Laurent Pinchart 
> >>> Reviewed-by: Boris Brezillon 
> >>> Signed-off-by: Maxime Ripard 
> >>> ---
> >>> 
> >>>  Documentation/gpu/kms-properties.csv |  2 +-
> >>>  drivers/gpu/drm/drm_atomic.c |  4 -
> >>>  drivers/gpu/drm/drm_atomic_helper.c  |  4 -
> >>>  drivers/gpu/drm/drm_blend.c  | 32 -
> >>>  include/drm/drm_blend.h  |  1 +-
> >>>  include/drm/drm_plane.h  |  6 +-
> >>>  6 files changed, 48 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/Documentation/gpu/kms-properties.csv
> >>> b/Documentation/gpu/kms-properties.csv index 927b65e14219..25ad3503d663
> >>> 100644
> >>> --- a/Documentation/gpu/kms-properties.csv
> >>> +++ b/Documentation/gpu/kms-properties.csv
> >>> @@ -99,5 +99,5 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0,
> >>> Max=1",Connector,TBD>
> >>> 
> >>>  ,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
> >>>  ,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
> >>>  ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
> >>> 
> >>> -rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
> >>> +,,"""alpha""",RANGE,"Min=0, Max=Driver dependant",Plane,Opacity of the
> >>> plane from transparent (0) to fully opaque (MAX). If this property is
> >>> set to a value different than max, and that the pixel will define an
> >>> alpha component, the property will have precendance and the pixel value
> >>> will be ignored.
> 
> Please don't document new properties in that csv file, it's an
> unreadable mess. Instead follow how we document standardized
> properties nowadays in full-blown sections. For plane blending we
> have:
> 
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-prop
> erties
> 
> >> Those semantics don't seem particularly good to me. I think we would want
> >> the per-pixel alpha and global alpha both to be effecive at the same
> >> time. You can always decide to ignore the per-pixel alpha by using a
> >> pixel format without alpha.
> > 
> > That makes sense to me. However, it also brings a new question: how should
> > a driver that supports either global alpha or pixel alpha but not both
> > signal that to userspace, and how should it reacts when userspace selects
> > a format with an alpha channel and set a global alpha value other than
> > fully opaque ? To make things more complex, note that some drivers
> > support combining global alpha and pixel alpha only for a subset of the
> > formats with an alpha channel (for instance for ARGB 1555 formats, but
> > not for ARGB  formats).
> 
> atomic_check can reject unsupported configs. Userspace needs to fall
> back somehow (either switch to xrgb or make alpha fully opaque or just
> give up on that plane). We have a lot of such corner-cases we don't
> tell userspace about explicitly at all.

I'm OK with failing the commit in case in invalid configuration is requested. 
However, using a check-only commit to find out whether combining global alpha 
and pixel alpha is supported doesn't seem a good idea to me. First of all 
userspace would need to try that for all formats, making it cumbersome. Then, 
an atomic commit is a black box, we don't report the failure cause to 
userspace. It makes it hard to use it to test support for a feature as it 
could fail for an unrelated reason. Finally, we'd open the door to various 
kind of heuristics implemented differently in different userspace stacks, and 
that would increase the risk of breaking userspace. I'd rather have an 
explicitly documented way to perform such checks.

> >> Also, where's the userspace that wants this feature?
> >> 
> >> 
> >> 
> >>> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> >>> index 8185e3468a23..5a6f29524f12 100644
> >>> --- a/include/drm/drm_plane.h
> >>> +++ b/include/drm/drm_plane.h
> >>> @@ -42,6 +42,7 @@ struct drm_modeset_acquire_ctx;
> >>>   * plane (in 16.16)
> >>>   * @src_w: width of visible portion of plane (in 16.16)
> >>>   * @src_h: height of visible portion of plane (in 16.16)
> >>> + * @alpha: opacity of the plane
> >>>   * @rotation: rotation of the plane
> >>>   * @zpos: priority of the given plane on crtc (optional)
> >>>   * Note that multiple active 

[PULL] drm-misc-next

[Sean Paul]

Hi Dave,
A delicious collection of fixes and features for you this week. The backlight
helpers have been picked up by Lee Jones in the backlight tree, so hopefully
no fireworks there. Everything else is business as usual.

drm-misc-next-2018-02-21:
drm-misc-next for 4.17:

Cross-subsystem Changes:
- Backlight helpers to enable/disable and find devices in dt (Meghana)

Core Changes:
- Documentation improvements (Chris/Daniel/Jani)
- simple_kms_helper: Add mode_valid() support (Linus)
- mm: Fix bug in interval_tree causing nodes to be out-of-order (Chris)

Driver Changes:
- tinydrm/panel: Use the new backlight helpers (Meghana)
- rockchip: Support gem_prime_import_sg_table + some fixes (Various)
- sun4i: Add A83T HDMI support using dw-hdmi (Jernej)

Cc: Meghana Madhyastha 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: Linus Walleij 
Cc: Heiko Stuebner 
Cc: Jernej Skrabec 

Cheers, Sean


The following changes since commit 933519a5a269d8460450545adefcb5caec622cac:

  Merge tag 'topic/hdcp-2018-02-13' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-02-16 09:36:04 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-21

for you to fetch changes up to 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:

  drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)


drm-misc-next for 4.17:

Cross-subsystem Changes:
- Backlight helpers to enable/disable and find devices in dt (Meghana)

Core Changes:
- Documentation improvements (Chris/Daniel/Jani)
- simple_kms_helper: Add mode_valid() support (Linus)
- mm: Fix bug in interval_tree causing nodes to be out-of-order (Chris)

Driver Changes:
- tinydrm/panel: Use the new backlight helpers (Meghana)
- rockchip: Support gem_prime_import_sg_table + some fixes (Various)
- sun4i: Add A83T HDMI support using dw-hdmi (Jernej)

Cc: Meghana Madhyastha 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: Linus Walleij 
Cc: Heiko Stuebner 
Cc: Jernej Skrabec 


Anusha Srivatsa (1):
  drm: Add DPCD definitions for DP 1.4 FEC feature

Chris Wilson (3):
  drm: Fix kerneldoc warnings for drm_lease
  dma-buf/sw_sync: Fix kerneldoc warnings
  drm: Use idr_init_base(1) when using id==0 for invalid

Chris Zhong (1):
  Documentation: bindings: add dt documentation for cdn DP controller

Colin Ian King (1):
  drm/bochs: make structure bochs_bo_driver static

Daniel Vetter (6):
  drm/todo: Add idr_init_base todo
  drm/docs: Discourage adding more to kms-properties.csv
  drm/docs: Align layout of optional plane blending properties
  drm/docs: Document "scaling mode" property better
  drm/doc: Polish for drm_mode_parse_command_line_for_connector
  drm/doc: Use new substruct support

Fabio Estevam (2):
  drm/rockchip: dsi: Remove unnecessary platform_get_resource() error check
  drm/rockchip: inno_hdmi: Remove unnecessary platform_get_resource() error 
check

Giulio Benetti (1):
  drm/sun4i: fix HSYNC and VSYNC polarity

Haixia Shi (1):
  drm/rockchip: support prime import sg table

Jani Nikula (1):
  drm: add documentation for tv connector state margins

Jernej Skrabec (8):
  drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a
  drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
  drm/bridge/synopsys: dw-hdmi: don't clobber drvdata
  dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
  drm/sun4i: Add has_channel_0 TCON quirk
  drm/sun4i: Add support for A83T second TCON
  drm/sun4i: Add support for A83T second DE2 mixer
  drm/sun4i: Implement A83T HDMI driver

Joe Moriarty (2):
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
  drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

Linus Walleij (1):
  drm: simple_kms_helper: Add mode_valid() callback support

Maxime Ripard (1):
  drm/rcar-du: dw-hdmi: Fix compilation

Meghana Madhyastha (10):
  video: backlight: Add helpers to enable and disable backlight
  video: backlight: Add of_find_backlight helper in backlight.c
  video: backlight: Add devres versions of of_find_backlight
  drm/tinydrm: Convert tinydrm_enable/disable_backlight to 
backlight_enable/disable
  drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight
  drm/tinydrm: Call devres version of of_find_backlight
  drm/panel: Use backlight_enable/disable helpers
  drm/omapdrm: Use 

Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after drm_modeset_lock_all

[Daniel Vetter]

On Wed, Feb 21, 2018 at 04:23:31PM +0100, Maarten Lankhorst wrote:
> After we acquired all generic modeset locks in drm_modeset_lock_all, it's
> unsafe acquire any other so just mark acquisition as done.
> 
> Atomic drivers shouldn't use drm_modeset_lock_all.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Daniel Vetter 

Also, I'm pretty much expecting to regret this like all the other
ww_acquire_done patches I've acked, but where's the fun in not trying :-)

Cheers, Daniel

> ---
>  drivers/gpu/drm/drm_modeset_lock.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 963e23db0fe7..8a5100685875 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -113,6 +113,7 @@ void drm_modeset_lock_all(struct drm_device *dev)
>   kfree(ctx);
>   return;
>   }
> + ww_acquire_done(>ww_ctx);
>  
>   WARN_ON(config->acquire_ctx);
>  
> -- 
> 2.16.1
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 RFC] drm/bridge: panel: Add device_link between panel and master drm device

[Daniel Vetter]

On Wed, Feb 21, 2018 at 10:51:50AM +0200, Jyri Sarha wrote:
> On 21/02/18 01:47, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 12:21:50AM +0200, Jyri Sarha wrote:
> >> Currently the master drm driver is not protected against the attached
> >> panel driver from becoming unavailable. Adding a device_link with
> >> DL_FLAG_AUTOREMOVE flag unbinds the master drm device (the consumer)
> >> when the panel device (the supplier) becomes unavailable.
> >>
> >> Signed-off-by: Jyri Sarha 
> >> Suggested-by: Thierry Reding 
> >> cc: e...@anholt.net
> >> cc: laurent.pinch...@ideasonboard.com
> >> ---
> >> It still annoys me that the unbound master drm device does not probe
> >> again if the panel device becomes available again. If there is no
> >> remedy to this, may be we should consider applying the module get/put
> >> patch[1] too.
> >>
> >> Hmmm... there was an obvious reasons not to add module gets and puts
> >> to drm_panel_attach/detach(), but is there any such reasons for not to
> >> add and remove the device link there?
> > 
> > Yeah that might be the better place for this. At least conceptually it's
> > when we're creating the dependency link.
> > 
> >> The bridge side look more complicated as there is no public
> >> drm_bridge_detach(), and I am not sure if the drm_bridge_remove() should
> >> remove the device link. I guess it should, if the link is there.
> > 
> > drm_bridge_remove is meant to be called when unloading the driver, which
> > is too late. We probably need a drm_bridge_detach (which the master
> > drm_device driver would need to call). Since bridges are linked through
> > drm_encoder/bridge already, the drm core could make that call (would avoid
> > having to audit all the drivers I think).
> > 
> 
> Actually, after experimenting with putting the link creation to
> drm_panel_attach() and removal to drm_panel_detach(), it looks to me
> that the approach taken in drm_bridge is correct and the one in
> drm_panel is wrong. The detach should never be called by the provider
> (panel or pridge driver), but only by the consumer (master drm device)
> when it does not need the provider any more.
> 
> So if I put device link code to drm_panel_attach/detach() I need to
> remove the detach call from panel driver's remove call. BTW, what is the
> point of assigning the pointers in struct drm_panel to null just before
> it is going away in the first place?

Honestly I didn't check actual usage, my recommendation was based on the
assumption that attach/detach is called by the consumer (drm device), not
by the panel driver itself in it's unload code. For that I figured
something like drm_bridge_remove (which removes the driver from of lookup
tables and stuff like that) should be the only thing. With device_link
ensure that remove never gets called while the panel is still attached to
a drm_device.
-Daniel

> 
> > But imo we can postpone fixing the bridge side of things to a later time.
> > 
> >> [1] 
> >> https://lists.freedesktop.org/archives/dri-devel/2018-February/166350.html
> > 
> > Afaiui the device_link will make sure that the main driver gets unbound
> > before the panel driver. Since a module unload implies a driver unbind I
> > think we're safe with this, and don't need any additional protection.
> > 
> > Wrt reprobing the main drm_driver when you rebind/reload the panel driver:
> > I guess poke it through the sysfs reprobe thing, or just reload the main
> > driver too, that should work. It's still driver reloading we're talking
> > about, as long as you can't make the kernel go boom I think it's all
> > perfectly fine.
> 
> Yes, almost anything works. I just feel that the probe should happen
> automatically, but I'll see if Lukas' patch helps with it.
> 
> Best regards,
> Jyri
> 
> > -Daniel
> > 
> >>
> >>  drivers/gpu/drm/bridge/panel.c | 22 ++
> >>  1 file changed, 22 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/panel.c 
> >> b/drivers/gpu/drm/bridge/panel.c
> >> index 6d99d4a..d71ddd8 100644
> >> --- a/drivers/gpu/drm/bridge/panel.c
> >> +++ b/drivers/gpu/drm/bridge/panel.c
> >> @@ -22,6 +22,7 @@ struct panel_bridge {
> >>struct drm_connector connector;
> >>struct drm_panel *panel;
> >>u32 connector_type;
> >> +  struct device_link *link;   /* link to master drm dev */
> >>  };
> >>  
> >>  static inline struct panel_bridge *
> >> @@ -57,6 +58,22 @@ static const struct drm_connector_funcs 
> >> panel_bridge_connector_funcs = {
> >>.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> >>  };
> >>  
> >> +static int panel_bridge_link_to_master(struct panel_bridge *panel_bridge)
> >> +{
> >> +  struct device *mdev = panel_bridge->bridge.dev->dev;
> >> +  struct device *pdev = panel_bridge->panel->dev;
> >> +  u32 flags = DL_FLAG_AUTOREMOVE;
> >> +
> >> +  panel_bridge->link = device_link_add(mdev, pdev, flags);
> >> +  if (!panel_bridge->link) {
> >> +  dev_err(pdev, "failed to 

Re: [PATCH] drm/doc: Fix documentation for _vblank_restore().

[Daniel Vetter]

On Tue, Feb 20, 2018 at 11:39:08PM -0800, Dhinakaran Pandiyan wrote:
> No code changes, fixes doc build warnings and polish some doc text.
> 
> Reported-by: Daniel Vetter 
> Cc: Rodrigo Vivi 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 

Thanks for the quick follow-up. Patch applied.
-Daniel

> ---
>  drivers/gpu/drm/drm_vblank.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index c781cb426bf1..51041eec0047 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -1238,12 +1238,15 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
>  EXPORT_SYMBOL(drm_crtc_vblank_on);
>  
>  /**
> - * drm_vblank_restore - estimated vblanks using timestamps and update it.
> + * drm_vblank_restore - estimate missed vblanks and update vblank count.
> + * @dev: DRM device
> + * @pipe: CRTC index
>   *
>   * Power manamement features can cause frame counter resets between vblank
> - * disable and enable. Drivers can then use this function in their
> - * _crtc_funcs.enable_vblank implementation to estimate the vblanks since
> - * the last _crtc_funcs.disable_vblank.
> + * disable and enable. Drivers can use this function in their
> + * _crtc_funcs.enable_vblank implementation to estimate missed vblanks 
> since
> + * the last _crtc_funcs.disable_vblank using timestamps and update the
> + * vblank counter.
>   *
>   * This function is the legacy version of drm_crtc_vblank_restore().
>   */
> @@ -1284,11 +1287,14 @@ void drm_vblank_restore(struct drm_device *dev, 
> unsigned int pipe)
>  EXPORT_SYMBOL(drm_vblank_restore);
>  
>  /**
> - * drm_crtc_vblank_restore - estimate vblanks using timestamps and update it.
> + * drm_crtc_vblank_restore - estimate missed vblanks and update vblank count.
> + * @crtc: CRTC in question
> + *
>   * Power manamement features can cause frame counter resets between vblank
> - * disable and enable. Drivers can then use this function in their
> - * _crtc_funcs.enable_vblank implementation to estimate the vblanks since
> - * the last _crtc_funcs.disable_vblank.
> + * disable and enable. Drivers can use this function in their
> + * _crtc_funcs.enable_vblank implementation to estimate missed vblanks 
> since
> + * the last _crtc_funcs.disable_vblank using timestamps and update the
> + * vblank counter.
>   */
>  void drm_crtc_vblank_restore(struct drm_crtc *crtc)
>  {
> -- 
> 2.14.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 3/8] drm/bridge: dw-hdmi: allow overriding of phy-type reading

[Laurent Pinchart]

Hi Heiko,

On Wednesday, 21 February 2018 20:55:12 EET Heiko Stuebner wrote:
> Am Montag, 19. Februar 2018, 20:06:40 CET schrieb Laurent Pinchart:
> > On Monday, 19 February 2018 20:46:46 EET Heiko Stuebner wrote:
> > > Am Montag, 19. Februar 2018, 17:59:02 CET schrieb Laurent Pinchart:
> > > > On Friday, 16 February 2018 22:41:53 EET Heiko Stuebner wrote:
> > > >> In some IP implementations the reading of the phy-type may be broken.
> > > >> One example are the Rockchip rk3228 and rk3328 socs that use a
> > > >> separate
> > > >> phy from Innosilicon but still report the HDMI20_TX type.
> > > >> 
> > > >> So allow the glue driver to force a specific type, like the
> > > >> vendor-phy
> > > >> for these cases.
> > > >> 
> > > >> Signed-off-by: Heiko Stuebner 
> > > > 
> > > > Tested-by: Laurent Pinchart 
> > > 
> > > thanks for testing :-)
> > > 
> > > >> ---
> > > >> 
> > > >>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +++-
> > > >>  include/drm/bridge/dw_hdmi.h  | 1 +
> > > >>  2 files changed, 4 insertions(+), 1 deletion(-)
> > > >> 
> > > >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > > >> f9802399cc0d..50d231626c4d 100644
> > > >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > >> @@ -2218,7 +2218,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi
> > > >> *hdmi)
> > > >> 
> > > >>unsigned int i;
> > > >>u8 phy_type;
> > > >> 
> > > >> -  phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
> > > >> +  phy_type = (hdmi->plat_data->phy_force_type) ?
> > > >> +  hdmi->plat_data->phy_force_type :
> > > >> +  hdmi_readb(hdmi, HDMI_CONFIG2_ID);
> > > > 
> > > > No need for parentheses. You could even write this
> > > > 
> > > > phy_type = hdmi->plat_data->phy_force_type ?
> > > > 
> > > >  : hdmi_readb(hdmi, HDMI_CONFIG2_ID);
> > > > 
> > > > but that's up to you.
> > > > 
> > > > What if a driver wants to force the PHY type to
> > > > DW_HDMI_PHY_DWC_HDMI_TX_PHY ? Or do you expect only the
> > > > DW_HDMI_PHY_VENDOR_PHY type to be forced ? If so, we could also use a
> > > > force_vendor_phy boolean field instead of phy_force_type.
> > > 
> > > Initially I thought of implicitly overriding the phy-type when the
> > > external
> > > phy-ops are set, but decided against it because that might break
> > > (theoretical) cases where phy-ops may be always set but only used when
> > > the ip returns a matching phy-type and thus came to just allow
> > > overriding
> > > that type reading.
> > > 
> > > As for limiting to only allow forcing the vendor type, my personal
> > > feeling
> > > would be to allow glue drivers to just override the type as needed
> > > like done in the patch. As can be seen on the rk3328, the dw-hdmi
> > > reports one of the regular phys (forgot which one) but instead has a
> > > completely separate ip for it, so I'd guess we may very well see
> > > implementations that just report a wrong type (no vendor-type).
> > > 
> > > So I don't see an issue with drivers being allowed to set the type to
> > > DW_HDMI_PHY_DWC_HDMI_TX_PHY, because such cases may exist in the
> > > future and I'd expect driver authors to somewhat know what they're
> > > doing.
> > 
> > My point was that DW_HDMI_PHY_DWC_HDMI_TX_PHY == 0, so trying to force
> > DW_HDMI_PHY_DWC_HDMI_TX_PHY through phy_force_type won't work.
> 
> Argh, ok now I get it.
> 
> So it will need some adaption for that, because allowing everything but
> DW_HDMI_PHY_DWC_HDMI_TX_PHY would be quite counter-intuitive :-) .
> 
> Expecting phy_force_type == -1 for regular reads sounds bad as well,
> because then every glue driver would need to set that, which currently
> gets solves automatically when the field is not explicitly set.
> 
> So going with your force_vendor_phy idea sounds less intrusive for the
> time being and until there is an actual case where there is a different
> internal phy-type necessary?

That's at least what I'd recommend, as I don't see any use case now for 
overriding the hardware-reported PHY type to a standard PHY type. If we ever 
end up needing that in the future we will of course support it.

-- 
Regards,

Laurent Pinchart

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

Re: [RFC PATCH v2 0/9] hyper_dmabuf: Hyper_DMABUF driver

[Dongwon Kim]

On Mon, Feb 19, 2018 at 06:01:29PM +0100, Daniel Vetter wrote:
> On Tue, Feb 13, 2018 at 05:49:59PM -0800, Dongwon Kim wrote:
> > This patch series contains the implementation of a new device driver,
> > hyper_DMABUF driver, which provides a way to expand the boundary of
> > Linux DMA-BUF sharing to across different VM instances in Multi-OS platform
> > enabled by a Hypervisor (e.g. XEN)
> > 
> > This version 2 series is basically refactored version of old series starting
> > with "[RFC PATCH 01/60] hyper_dmabuf: initial working version of 
> > hyper_dmabuf
> > drv"
> > 
> > Implementation details of this driver are described in the reference guide
> > added by the second patch, "[RFC PATCH v2 2/5] hyper_dmabuf: architecture
> > specification and reference guide".
> > 
> > Attaching 'Overview' section here as a quick summary.
> > 
> > --
> > Section 1. Overview
> > --
> > 
> > Hyper_DMABUF driver is a Linux device driver running on multiple Virtual
> > achines (VMs), which expands DMA-BUF sharing capability to the VM 
> > environment
> > where multiple different OS instances need to share same physical data 
> > without
> > data-copy across VMs.
> > 
> > To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the
> > exporting VM (so called, “exporter”) imports a local DMA_BUF from the 
> > original
> > producer of the buffer, then re-exports it with an unique ID, 
> > hyper_dmabuf_id
> > for the buffer to the importing VM (so called, “importer”).
> > 
> > Another instance of the Hyper_DMABUF driver on importer registers
> > a hyper_dmabuf_id together with reference information for the shared 
> > physical
> > pages associated with the DMA_BUF to its database when the export happens.
> > 
> > The actual mapping of the DMA_BUF on the importer’s side is done by
> > the Hyper_DMABUF driver when user space issues the IOCTL command to access
> > the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and
> > exporting driver as is, that is, no special configuration is required.
> > Consequently, only a single module per VM is needed to enable cross-VM 
> > DMA_BUF
> > exchange.
> > 
> > --
> > 
> > There is a git repository at github.com where this series of patches are all
> > integrated in Linux kernel tree based on the commit:
> > 
> > commit ae64f9bd1d3621b5e60d7363bc20afb46aede215
> > Author: Linus Torvalds 
> > Date:   Sun Dec 3 11:01:47 2018 -0500
> > 
> > Linux 4.15-rc2
> > 
> > https://github.com/downor/linux_hyper_dmabuf.git hyper_dmabuf_integration_v4
> 
> Since you place this under drivers/dma-buf I'm assuming you want to
> maintain this as part of the core dma-buf support, and not as some
> Xen-specific thing. Given that, usual graphics folks rules apply:

I moved it inside driver/dma-buf because the half of design is not hypervisor
specific and it is possible that we would add more backends for other
additional hypervisor support. 

> 
> Where's the userspace for this (must be open source)? What exactly is the
> use-case you're trying to solve by sharing dma-bufs in this fashion?

Automotive use cases are actually using this feature now where each VM has
their own display and want to share same rendering contents from one to
another. It is a platform based on Xen and Intel hardware and I don't think
all of SW stack is open-sourced. I do have a test application to verify this,
which I think I can make public.

> 
> Iirc my feedback on v1 was why exactly you really need to be able to
> import a normal dma-buf into a hyper-dmabuf, instead of allocating them
> directly in the hyper-dmabuf driver. Which would _massively_ simplify your
> design, since you don't need to marshall all the attach and map business
> around (since the hypervisor would be in control of the dma-buf, not a
> guest OS). 

I am sorry but I don't quite understand which side you are talking about
when you said "import a normal dma-buf". This hyper_dmabuf driver running
on the exporting VM actually imports the normal dma-buf (e.g. the one from
i915) then get underlying pages shared and pass all the references to those
pages to the importing VM. On importing VM, hyper_dmabuf driver is supposed
to create a dma-buf (Is this part what you are talking about?) with those
shared pages and export it using normal dma-buf framework. Attaching and
mapping functions should be defined in this case because hyper_dmabuf will
be the original exporter in importing VM.

I will try to contact you in IRC if more clarification is required.

Also, as far as I remember you suggested to make this driver work as exporter
on both sides. If your comment above is in-line with your previous feedback,
I actually replied back to your initial 

Re: [PATCH v4 01/16] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

Hi Sergei,

On Wednesday, 21 February 2018 10:35:13 EET Sergei Shtylyov wrote:
> On 2/21/2018 2:10 AM, Laurent Pinchart wrote:
> > The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
> > corresponding device tree bindings.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > Reviewed-by: Rob Herring 
> > ---
> > Changes since v1:
> > 
> > - Move the SoC name before the IP name in compatible strings
> > - Rename parallel input to parallel RGB input
> > - Fixed "renesas,r8a7743-lvds" description
> > - Document the resets property
> > - Fixed typo
> > ---
> > 
> >   .../bindings/display/bridge/renesas,lvds.txt   | 56 
> >   MAINTAINERS|  1 +
> >   2 files changed, 57 insertions(+)
> >   create mode 100644
> >   Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt> 
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt new
> > file mode 100644
> > index ..2b19ce51ec07
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > @@ -0,0 +1,56 @@
> > +Renesas R-Car LVDS Encoder
> > +==
> > +
> > +These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
> > +Gen2, R-Car Gen3 and RZ/G SoCs.
> > +
> > +Required properties:
> > +
> > +- compatible : Shall contain one of
> > +  - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
> > +  - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS
> > encoders
> > +  - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS
> > encoders +  - "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible
> > LVDS encoders +  - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3)
> > compatible LVDS encoders +  - "renesas,r8a7796-lvds" for R8A7796 (R-Car
> > M3-W) compatible LVDS encoders +
> > +- reg: Base address and length for the memory-mapped registers
> > +- clocks: A phandle + clock-specifier pair for the functional clock
> > +- resets: A phandle + reset specifier for the module reset
> > +
> > +Required nodes:
> > +
> > +The LVDS encoder has two video ports. Their connections are modelled
> > using the +OF graph bindings specified in
> > Documentation/devicetree/bindings/graph.txt. +
> > +- Video port 0 corresponds to the parallel RGB input
> > +- Video port 1 corresponds to the LVDS output
> > +
> > +Each port shall have a single endpoint.
> > +
> > +
> > +Example:
> > +
> > +   lvds0: lvds@feb9 {
> 
> "lvds-encoder@feb9" maybe?

Or just "encoder@feb9" ? Or "display-encoder@feb9" ? Rob, any 
preference ?

> And do we need a # in the label if the encoder is alone in DT anyway?

As a matter of fact r8a7790, on which this example is based, has two LVDS 
encoders. I've only included one in the example as adding a second one 
wouldn't have added any value.

> [...]

-- 
Regards,

Laurent Pinchart

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

Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after drm_modeset_lock_all

[Harry Wentland]

On 2018-02-21 01:36 PM, Daniel Vetter wrote:
> On Wed, Feb 21, 2018 at 04:23:31PM +0100, Maarten Lankhorst wrote:
>> After we acquired all generic modeset locks in drm_modeset_lock_all, it's
>> unsafe acquire any other so just mark acquisition as done.
>>
>> Atomic drivers shouldn't use drm_modeset_lock_all.
>>
>> Signed-off-by: Maarten Lankhorst 
> 
> Reviewed-by: Daniel Vetter 
> 
> Also, I'm pretty much expecting to regret this like all the other
> ww_acquire_done patches I've acked, but where's the fun in not trying :-)
> 

This shouldn't really hurt anything, other than throw DEBUG warnings if 
DEBUG_MUTEXES is on.

Acked-by: Harry Wentland 

Harry

> Cheers, Daniel
> 
>> ---
>>  drivers/gpu/drm/drm_modeset_lock.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
>> b/drivers/gpu/drm/drm_modeset_lock.c
>> index 963e23db0fe7..8a5100685875 100644
>> --- a/drivers/gpu/drm/drm_modeset_lock.c
>> +++ b/drivers/gpu/drm/drm_modeset_lock.c
>> @@ -113,6 +113,7 @@ void drm_modeset_lock_all(struct drm_device *dev)
>>  kfree(ctx);
>>  return;
>>  }
>> +ww_acquire_done(>ww_ctx);
>>  
>>  WARN_ON(config->acquire_ctx);
>>  
>> -- 
>> 2.16.1
>>
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/8] drm/bridge: dw-hdmi: allow overriding of phy-type reading

[Heiko Stuebner]

Hi Laurent,

Am Montag, 19. Februar 2018, 20:06:40 CET schrieb Laurent Pinchart:
> On Monday, 19 February 2018 20:46:46 EET Heiko Stuebner wrote:
> > Am Montag, 19. Februar 2018, 17:59:02 CET schrieb Laurent Pinchart:
> > > On Friday, 16 February 2018 22:41:53 EET Heiko Stuebner wrote:
> > >> In some IP implementations the reading of the phy-type may be broken.
> > >> One example are the Rockchip rk3228 and rk3328 socs that use a separate
> > >> phy from Innosilicon but still report the HDMI20_TX type.
> > >> 
> > >> So allow the glue driver to force a specific type, like the vendor-phy
> > >> for these cases.
> > >> 
> > >> Signed-off-by: Heiko Stuebner 
> > > 
> > > Tested-by: Laurent Pinchart 
> > 
> > thanks for testing :-)
> > 
> > >> ---
> > >> 
> > >>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +++-
> > >>  include/drm/bridge/dw_hdmi.h  | 1 +
> > >>  2 files changed, 4 insertions(+), 1 deletion(-)
> > >> 
> > >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > >> f9802399cc0d..50d231626c4d 100644
> > >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> @@ -2218,7 +2218,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi
> > >> *hdmi)
> > >>  unsigned int i;
> > >>  u8 phy_type;
> > >> 
> > >> -phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
> > >> +phy_type = (hdmi->plat_data->phy_force_type) ?
> > >> +hdmi->plat_data->phy_force_type :
> > >> +hdmi_readb(hdmi, HDMI_CONFIG2_ID);
> > > 
> > > No need for parentheses. You could even write this
> > > 
> > > phy_type = hdmi->plat_data->phy_force_type ?
> > >  : hdmi_readb(hdmi, HDMI_CONFIG2_ID);
> > > 
> > > but that's up to you.
> > > 
> > > What if a driver wants to force the PHY type to
> > > DW_HDMI_PHY_DWC_HDMI_TX_PHY ? Or do you expect only the
> > > DW_HDMI_PHY_VENDOR_PHY type to be forced ? If so, we could also use a
> > > force_vendor_phy boolean field instead of phy_force_type.
> > 
> > Initially I thought of implicitly overriding the phy-type when the external
> > phy-ops are set, but decided against it because that might break
> > (theoretical) cases where phy-ops may be always set but only used when
> > the ip returns a matching phy-type and thus came to just allow overriding
> > that type reading.
> > 
> > As for limiting to only allow forcing the vendor type, my personal feeling
> > would be to allow glue drivers to just override the type as needed
> > like done in the patch. As can be seen on the rk3328, the dw-hdmi
> > reports one of the regular phys (forgot which one) but instead has a
> > completely separate ip for it, so I'd guess we may very well see
> > implementations that just report a wrong type (no vendor-type).
> > 
> > So I don't see an issue with drivers being allowed to set the type to
> > DW_HDMI_PHY_DWC_HDMI_TX_PHY, because such cases may exist in the
> > future and I'd expect driver authors to somewhat know what they're doing.
> 
> My point was that DW_HDMI_PHY_DWC_HDMI_TX_PHY == 0, so trying to force 
> DW_HDMI_PHY_DWC_HDMI_TX_PHY through phy_force_type won't work.

Argh, ok now I get it.

So it will need some adaption for that, because allowing everything but
DW_HDMI_PHY_DWC_HDMI_TX_PHY would be quite counter-intuitive :-) .

Expecting phy_force_type == -1 for regular reads sounds bad as well,
because then every glue driver would need to set that, which currently
gets solves automatically when the field is not explicitly set.

So going with your force_vendor_phy idea sounds less intrusive for the
time being and until there is an actual case where there is a different
internal phy-type necessary?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105188] Monitors don't always wake up after sleep

[bugzilla-daemon]

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

--- Comment #3 from Michał Bartoszkiewicz  ---
The monitors are set to DP input, auto-scan is disabled.

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

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Rob Clark]

On Wed, Feb 21, 2018 at 11:36 AM, Ville Syrjälä
 wrote:
> On Wed, Feb 21, 2018 at 11:17:21AM -0500, Rob Clark wrote:
>> On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä
>>  wrote:
>> > On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote:
>> >> On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä
>> >>  wrote:
>> >> > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote:
>> >> >> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä
>> >> >>  wrote:
>> >> >> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote:
>> >> >> >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä
>> >> >> >>  wrote:
>> >> >> >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
>> >> >> >> >> Follow the same pattern of locking as with other state objects.  
>> >> >> >> >> This
>> >> >> >> >> avoids boilerplate in the driver.
>> >> >> >> >
>> >> >> >> > I'm not sure we really want to do this. What if the driver wants a
>> >> >> >> > custom locking scheme for this state?
>> >> >> >>
>> >> >> >> That seems like something we want to discourage, ie. all the more
>> >> >> >> reason for this patch.
>> >> >> >>
>> >> >> >> There is no reason drivers could not split their global state into
>> >> >> >> multiple private objs's, each with their own lock, for more fine
>> >> >> >> grained locking.  That is basically the only valid reason I can 
>> >> >> >> think
>> >> >> >> of for "custom locking".
>> >> >> >
>> >> >> > In i915 we have at least one case that would want something close to 
>> >> >> > an
>> >> >> > rwlock. Any crtc lock is enough for read, need all of them for write.
>> >> >> > Though if we wanted to use private objs for that we might need to
>> >> >> > actually make the states refcounted as well, otherwise I can imagine
>> >> >> > we might land in some use-after-free issues once again.
>> >> >> >
>> >> >> > Maybe we could duplicate the state into per-crtc and global copies, 
>> >> >> > but
>> >> >> > then we have to keep all of those in sync somehow which doesn't sound
>> >> >> > particularly pleasant.
>> >> >>
>> >> >> Or just keep your own driver lock for read, and use that plus the core
>> >> >> modeset lock for write?
>> >> >
>> >> > If we can't add the private obj to the state we can't really use it.
>> >> >
>> >>
>> >> I'm not sure why that is strictly true (that you need to add it to the
>> >> state if for read-only), since you'd be guarding it with your own
>> >> driver read-lock you can just priv->foo_state->bar.
>> >>
>> >> Since it is read-only access, there is no roll-back to worry about for
>> >> test-only or failed atomic_check()s..
>> >
>> > That would be super ugly. We want to access the information the same
>> > way whether it has been modified or not.
>>
>> Well, I mean the whole idea of what you want to do seems a bit super-ugly ;-)
>>
>> I mean, in mdp5 the assigned global resources go in plane/crtc state,
>> and tracking of what is assigned to which plane/crtc is in global
>> state, so it fits nicely in the current locking model.  For i915, I'm
>> not quite sure what is the global state you are concerned about, so it
>> is a bit hard to talk about the best solution in the abstract.  Maybe
>> the better option is to teach modeset-lock how to be a rwlock instead?
>
> The thing I'm thinking is the core display clock (cdclk) frequency which
> we need to consult whenever computing plane states and whatnot. We don't
> want a modeset on one crtc to block a plane update on another crtc
> unless we actually have to bump the cdclk (which would generally require
> all crtcs to undergo a full modeset). Seems like a generally useful
> pattern to me.
>

Hmm.. I suppose either way, you'd have to make modeset-lock have rw
semantics or invent some way to play nicely with acquire_ctx.. once
you have that, I'd have no objection to make private state use rwlock
semantics.  That seems better than having drivers (badly) roll their
own.  And maybe as you say, it would be a useful pattern for other
drivers.

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

Re: [PATCH] drm/nouveau: prefer XBGR2101010 for addfb ioctl

[Ilia Mirkin]

On Mon, Feb 19, 2018 at 4:33 AM, Daniel Vetter  wrote:
> On Mon, Feb 19, 2018 at 10:21:54AM +0100, Daniel Vetter wrote:
>> On Mon, Feb 05, 2018 at 09:10:12AM -0500, Ilia Mirkin wrote:
>> > On Mon, Feb 5, 2018 at 8:58 AM, Ville Syrjälä
>> >  wrote:
>> > > On Sat, Feb 03, 2018 at 02:11:23PM -0500, Ilia Mirkin wrote:
>> > >> Nouveau only exposes support for XBGR2101010. Prior to the atomic
>> > >> conversion, drm would pass in the wrong format in the framebuffer, but
>> > >> it was always ignored -- both userspace (xf86-video-nouveau) and the
>> > >> kernel driver agreed on the layout, so the fact that the format was
>> > >> wrong didn't matter.
>> > >>
>> > >> With the atomic conversion, nouveau all of a sudden started caring about
>> > >> the exact format, and so the previously-working code in
>> > >> xf86-video-nouveau no longer functioned since the (internally-assigned)
>> > >> format from the addfb ioctl was wrong.
>> > >>
>> > >> This change adds infrastructure to allow a drm driver to specify that it
>> > >> prefers the XBGR format variant for the addfb ioctl, and makes nouveau's
>> > >> nv50 display driver set it. (Prior gens had no support for 30bpp at 
>> > >> all.)
>> > >>
>> > >> Signed-off-by: Ilia Mirkin 
>> > >> Cc: sta...@vger.kernel.org # v4.10+
>> > >> ---
>> > >>
>> > >> Wasn't sure if the nouveau line needs to be split out into a separate
>> > >> change or not.
>> > >>
>> > >>  drivers/gpu/drm/drm_framebuffer.c  | 4 
>> > >>  drivers/gpu/drm/nouveau/nv50_display.c | 1 +
>> > >>  include/drm/drm_drv.h  | 1 +
>> > >>  3 files changed, 6 insertions(+)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> > >> b/drivers/gpu/drm/drm_framebuffer.c
>> > >> index 5a13ff29f4f0..c0530a1af5e3 100644
>> > >> --- a/drivers/gpu/drm/drm_framebuffer.c
>> > >> +++ b/drivers/gpu/drm/drm_framebuffer.c
>> > >> @@ -121,6 +121,10 @@ int drm_mode_addfb(struct drm_device *dev,
>> > >>   r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
>> > >>   r.handles[0] = or->handle;
>> > >>
>> > >> + if (r.pixel_format == DRM_FORMAT_XRGB2101010 &&
>> > >> + dev->driver->driver_features & DRIVER_PREFER_XBGR_30BPP)
>> > >> + r.pixel_format = DRM_FORMAT_XBGR2101010;
>> > >
>> > > I think I'd much prefer if the driver just passed some kind of a
>> > > bpp/depth->format mapping table to the core, or maybe an optional
>> > > vfunc to allow the driver to override drm_mode_legacy_fb_format()
>> > > behaviour.
>> > >
>> > > drm_mode_legacy_fb_format() is called from the fbdev setup as well
>> > > so handling this only in addfb doesn't look sufficient.
>> >
>> > Well, in practice fbdev won't pick a 30bpp mode. But I get the point.
>> > It would also enable a driver to have a funky RGB ordering for depth
>> > 24/32 and others. Although I don't know if there are any customers for
>> > that in practice.
>> >
>> > A vfunc works for me.
>> >
>> > Anyone else want to opine before I go for it? I'm happy to do the
>> > work, but want to make sure I'm not just doing things that'll get
>> > rejected, as I have a limited amount of time to do these things.
>>
>> Imo the very obvious hack is totally fine, makes it stick out more that we
>> have a fairly nasty uapi inconsistency here.
>>
>> Also vfunc or explicit table open up the door for even more driver abuse
>> in the future, which I don't like. vfunc for 1 case ever is also overkill.
>>
>> Wrt fbdev: Linus seems to have volunteered to switch fbdev from depth/bpp
>> to explicit pixel formats, so no worries.
>
> Forgot to add the most important bit.
>
> Reviewed-by: Daniel Vetter 
>
> Also ack for merging through -nouveau. Or ping me on irc if you want me to
> apply it to drm-misc-next.

Thanks!

Ben, will you take this patch? Or is drm-misc a better route? (Patch
at https://patchwork.freedesktop.org/patch/202322/)

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

Re: [PATCH] radeon: hide pointless #warning when compile testing

[Michel Dänzer]

On 2018-02-16 04:26 PM, Arnd Bergmann wrote:
> In randconfig testing, we sometimes get this warning:
> 
> drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
> drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable 
> CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to 
> write-combining [-Werror=cpp]
>  #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance 
> \
> 
> This is rather annoying since almost all other code produces no build-time
> output unless we have found a real bug. We already fixed this in the
> amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for
> compile testing") by adding a CONFIG_COMPILE_TEST check last year and
> agreed to do the same here, but both Michel and I then forgot about it
> until I came across the issue again now.
> 
> For stable kernels, as this is one of very few remaining randconfig
> warnings in 4.14.
> 
> Cc: sta...@vger.kernel.org
> Link: https://patchwork.kernel.org/patch/9550009/
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/radeon/radeon_object.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 093594976126..54c2b4fc5ead 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -238,9 +238,10 @@ int radeon_bo_create(struct radeon_device *rdev,
>* may be slow
>* See https://bugs.freedesktop.org/show_bug.cgi?id=88758
>*/
> -
> +#ifndef CONFIG_COMPILE_TEST
>  #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance 
> \
>thanks to write-combining
> +#endif
>  
>   if (bo->flags & RADEON_GEM_GTT_WC)
>   DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for 
> "
> 

Merged on the internal amd-staging-drm-next branch, thanks!


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Ville Syrjälä]

On Wed, Feb 21, 2018 at 11:17:21AM -0500, Rob Clark wrote:
> On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä
>  wrote:
> > On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote:
> >> On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä
> >>  wrote:
> >> > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote:
> >> >> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä
> >> >>  wrote:
> >> >> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote:
> >> >> >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä
> >> >> >>  wrote:
> >> >> >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
> >> >> >> >> Follow the same pattern of locking as with other state objects.  
> >> >> >> >> This
> >> >> >> >> avoids boilerplate in the driver.
> >> >> >> >
> >> >> >> > I'm not sure we really want to do this. What if the driver wants a
> >> >> >> > custom locking scheme for this state?
> >> >> >>
> >> >> >> That seems like something we want to discourage, ie. all the more
> >> >> >> reason for this patch.
> >> >> >>
> >> >> >> There is no reason drivers could not split their global state into
> >> >> >> multiple private objs's, each with their own lock, for more fine
> >> >> >> grained locking.  That is basically the only valid reason I can think
> >> >> >> of for "custom locking".
> >> >> >
> >> >> > In i915 we have at least one case that would want something close to 
> >> >> > an
> >> >> > rwlock. Any crtc lock is enough for read, need all of them for write.
> >> >> > Though if we wanted to use private objs for that we might need to
> >> >> > actually make the states refcounted as well, otherwise I can imagine
> >> >> > we might land in some use-after-free issues once again.
> >> >> >
> >> >> > Maybe we could duplicate the state into per-crtc and global copies, 
> >> >> > but
> >> >> > then we have to keep all of those in sync somehow which doesn't sound
> >> >> > particularly pleasant.
> >> >>
> >> >> Or just keep your own driver lock for read, and use that plus the core
> >> >> modeset lock for write?
> >> >
> >> > If we can't add the private obj to the state we can't really use it.
> >> >
> >>
> >> I'm not sure why that is strictly true (that you need to add it to the
> >> state if for read-only), since you'd be guarding it with your own
> >> driver read-lock you can just priv->foo_state->bar.
> >>
> >> Since it is read-only access, there is no roll-back to worry about for
> >> test-only or failed atomic_check()s..
> >
> > That would be super ugly. We want to access the information the same
> > way whether it has been modified or not.
> 
> Well, I mean the whole idea of what you want to do seems a bit super-ugly ;-)
> 
> I mean, in mdp5 the assigned global resources go in plane/crtc state,
> and tracking of what is assigned to which plane/crtc is in global
> state, so it fits nicely in the current locking model.  For i915, I'm
> not quite sure what is the global state you are concerned about, so it
> is a bit hard to talk about the best solution in the abstract.  Maybe
> the better option is to teach modeset-lock how to be a rwlock instead?

The thing I'm thinking is the core display clock (cdclk) frequency which
we need to consult whenever computing plane states and whatnot. We don't
want a modeset on one crtc to block a plane update on another crtc
unless we actually have to bump the cdclk (which would generally require
all crtcs to undergo a full modeset). Seems like a generally useful
pattern to me.

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

[Bug 105188] Monitors don't always wake up after sleep

[bugzilla-daemon]

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

--- Comment #2 from Harry Wentland  ---
Are the monitors set to DP input or to auto-scan the inputs?

We've seen similar issues with some monitors that auto-scan inputs and
disappear on us when we try to enable them.

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

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Rob Clark]

On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä
 wrote:
> On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote:
>> On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä
>>  wrote:
>> > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote:
>> >> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä
>> >>  wrote:
>> >> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote:
>> >> >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä
>> >> >>  wrote:
>> >> >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
>> >> >> >> Follow the same pattern of locking as with other state objects.  
>> >> >> >> This
>> >> >> >> avoids boilerplate in the driver.
>> >> >> >
>> >> >> > I'm not sure we really want to do this. What if the driver wants a
>> >> >> > custom locking scheme for this state?
>> >> >>
>> >> >> That seems like something we want to discourage, ie. all the more
>> >> >> reason for this patch.
>> >> >>
>> >> >> There is no reason drivers could not split their global state into
>> >> >> multiple private objs's, each with their own lock, for more fine
>> >> >> grained locking.  That is basically the only valid reason I can think
>> >> >> of for "custom locking".
>> >> >
>> >> > In i915 we have at least one case that would want something close to an
>> >> > rwlock. Any crtc lock is enough for read, need all of them for write.
>> >> > Though if we wanted to use private objs for that we might need to
>> >> > actually make the states refcounted as well, otherwise I can imagine
>> >> > we might land in some use-after-free issues once again.
>> >> >
>> >> > Maybe we could duplicate the state into per-crtc and global copies, but
>> >> > then we have to keep all of those in sync somehow which doesn't sound
>> >> > particularly pleasant.
>> >>
>> >> Or just keep your own driver lock for read, and use that plus the core
>> >> modeset lock for write?
>> >
>> > If we can't add the private obj to the state we can't really use it.
>> >
>>
>> I'm not sure why that is strictly true (that you need to add it to the
>> state if for read-only), since you'd be guarding it with your own
>> driver read-lock you can just priv->foo_state->bar.
>>
>> Since it is read-only access, there is no roll-back to worry about for
>> test-only or failed atomic_check()s..
>
> That would be super ugly. We want to access the information the same
> way whether it has been modified or not.

Well, I mean the whole idea of what you want to do seems a bit super-ugly ;-)

I mean, in mdp5 the assigned global resources go in plane/crtc state,
and tracking of what is assigned to which plane/crtc is in global
state, so it fits nicely in the current locking model.  For i915, I'm
not quite sure what is the global state you are concerned about, so it
is a bit hard to talk about the best solution in the abstract.  Maybe
the better option is to teach modeset-lock how to be a rwlock instead?

BR,
-R

>>
>> BR,
>> -R
>>
>>
>> >>
>> >> BR,
>> >> -R
>> >>
>> >> >
>> >> >>
>> >> >> (And ofc drivers could add there own locks in addition to what is done
>> >> >> by core, but I'd rather look at that on a case by case basis, rather
>> >> >> than it being part of the boilerplate in each driver.)
>> >> >>
>> >> >> BR,
>> >> >> -R
>> >> >>
>> >> >> >>
>> >> >> >> Signed-off-by: Rob Clark 
>> >> >> >> ---
>> >> >> >>  drivers/gpu/drm/drm_atomic.c | 9 -
>> >> >> >>  include/drm/drm_atomic.h | 5 +
>> >> >> >>  2 files changed, 13 insertions(+), 1 deletion(-)
>> >> >> >>
>> >> >> >> diff --git a/drivers/gpu/drm/drm_atomic.c 
>> >> >> >> b/drivers/gpu/drm/drm_atomic.c
>> >> >> >> index fc8c4da409ff..004e621ab307 100644
>> >> >> >> --- a/drivers/gpu/drm/drm_atomic.c
>> >> >> >> +++ b/drivers/gpu/drm/drm_atomic.c
>> >> >> >> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct 
>> >> >> >> drm_private_obj *obj,
>> >> >> >>  {
>> >> >> >>   memset(obj, 0, sizeof(*obj));
>> >> >> >>
>> >> >> >> + drm_modeset_lock_init(>lock);
>> >> >> >> +
>> >> >> >>   obj->state = state;
>> >> >> >>   obj->funcs = funcs;
>> >> >> >>  }
>> >> >> >> @@ -1093,6 +1095,7 @@ void
>> >> >> >>  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
>> >> >> >>  {
>> >> >> >>   obj->funcs->atomic_destroy_state(obj, obj->state);
>> >> >> >> + drm_modeset_lock_fini(>lock);
>> >> >> >>  }
>> >> >> >>  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
>> >> >> >>
>> >> >> >> @@ -1113,7 +1116,7 @@ struct drm_private_state *
>> >> >> >>  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
>> >> >> >>struct drm_private_obj *obj)
>> >> >> >>  {
>> >> >> >> - int index, num_objs, i;
>> >> >> >> + int index, num_objs, i, ret;
>> >> >> >>   size_t size;
>> >> >> >>   struct __drm_private_objs_state *arr;
>> >> >> >>   struct drm_private_state *obj_state;
>> >> 

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Ville Syrjälä]

On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote:
> On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä
>  wrote:
> > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote:
> >> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä
> >>  wrote:
> >> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote:
> >> >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä
> >> >>  wrote:
> >> >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
> >> >> >> Follow the same pattern of locking as with other state objects.  This
> >> >> >> avoids boilerplate in the driver.
> >> >> >
> >> >> > I'm not sure we really want to do this. What if the driver wants a
> >> >> > custom locking scheme for this state?
> >> >>
> >> >> That seems like something we want to discourage, ie. all the more
> >> >> reason for this patch.
> >> >>
> >> >> There is no reason drivers could not split their global state into
> >> >> multiple private objs's, each with their own lock, for more fine
> >> >> grained locking.  That is basically the only valid reason I can think
> >> >> of for "custom locking".
> >> >
> >> > In i915 we have at least one case that would want something close to an
> >> > rwlock. Any crtc lock is enough for read, need all of them for write.
> >> > Though if we wanted to use private objs for that we might need to
> >> > actually make the states refcounted as well, otherwise I can imagine
> >> > we might land in some use-after-free issues once again.
> >> >
> >> > Maybe we could duplicate the state into per-crtc and global copies, but
> >> > then we have to keep all of those in sync somehow which doesn't sound
> >> > particularly pleasant.
> >>
> >> Or just keep your own driver lock for read, and use that plus the core
> >> modeset lock for write?
> >
> > If we can't add the private obj to the state we can't really use it.
> >
> 
> I'm not sure why that is strictly true (that you need to add it to the
> state if for read-only), since you'd be guarding it with your own
> driver read-lock you can just priv->foo_state->bar.
> 
> Since it is read-only access, there is no roll-back to worry about for
> test-only or failed atomic_check()s..

That would be super ugly. We want to access the information the same
way whether it has been modified or not.

> 
> BR,
> -R
> 
> 
> >>
> >> BR,
> >> -R
> >>
> >> >
> >> >>
> >> >> (And ofc drivers could add there own locks in addition to what is done
> >> >> by core, but I'd rather look at that on a case by case basis, rather
> >> >> than it being part of the boilerplate in each driver.)
> >> >>
> >> >> BR,
> >> >> -R
> >> >>
> >> >> >>
> >> >> >> Signed-off-by: Rob Clark 
> >> >> >> ---
> >> >> >>  drivers/gpu/drm/drm_atomic.c | 9 -
> >> >> >>  include/drm/drm_atomic.h | 5 +
> >> >> >>  2 files changed, 13 insertions(+), 1 deletion(-)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/drm_atomic.c 
> >> >> >> b/drivers/gpu/drm/drm_atomic.c
> >> >> >> index fc8c4da409ff..004e621ab307 100644
> >> >> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> >> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> >> >> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct 
> >> >> >> drm_private_obj *obj,
> >> >> >>  {
> >> >> >>   memset(obj, 0, sizeof(*obj));
> >> >> >>
> >> >> >> + drm_modeset_lock_init(>lock);
> >> >> >> +
> >> >> >>   obj->state = state;
> >> >> >>   obj->funcs = funcs;
> >> >> >>  }
> >> >> >> @@ -1093,6 +1095,7 @@ void
> >> >> >>  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
> >> >> >>  {
> >> >> >>   obj->funcs->atomic_destroy_state(obj, obj->state);
> >> >> >> + drm_modeset_lock_fini(>lock);
> >> >> >>  }
> >> >> >>  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
> >> >> >>
> >> >> >> @@ -1113,7 +1116,7 @@ struct drm_private_state *
> >> >> >>  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> >> >> >>struct drm_private_obj *obj)
> >> >> >>  {
> >> >> >> - int index, num_objs, i;
> >> >> >> + int index, num_objs, i, ret;
> >> >> >>   size_t size;
> >> >> >>   struct __drm_private_objs_state *arr;
> >> >> >>   struct drm_private_state *obj_state;
> >> >> >> @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct 
> >> >> >> drm_atomic_state *state,
> >> >> >>   if (obj == state->private_objs[i].ptr)
> >> >> >>   return state->private_objs[i].state;
> >> >> >>
> >> >> >> + ret = drm_modeset_lock(>lock, state->acquire_ctx);
> >> >> >> + if (ret)
> >> >> >> + return ERR_PTR(ret);
> >> >> >> +
> >> >> >>   num_objs = state->num_private_objs + 1;
> >> >> >>   size = sizeof(*state->private_objs) * num_objs;
> >> >> >>   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> >> >> >> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> >> >> >> index 

Re: [PATCH v4 5/6] extcon: add possibility to get extcon device by OF node

[Andrzej Hajda]

On 21.02.2018 15:27, Andy Shevchenko wrote:
> On Wed, Feb 21, 2018 at 10:55 AM, Andrzej Hajda  wrote:
>> Since extcon property is not allowed in DT, extcon subsystem requires
>> another way to get extcon device. Lets try the simplest approach - get
>> edev by of_node.
>> +/*
>> + * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
>> + * @node   : OF node identyfying edev
>> + *
>> + * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
>> + */
>> +struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
> First of all, the all other similar cases use "_by_node" in the name.

OK, looks better.

> Second, it's not _get_, it's _find_.

The patch splits exisiting extcon_get_edev_by_phandle function into two
functions, nothing more.
Thus it followed naming convention present in extcon framework. I can
switch it of course to _find_.

>
>> +{
>> +   struct extcon_dev *edev;
>> +
>> +   mutex_lock(_dev_list_lock);
>> +   list_for_each_entry(edev, _dev_list, entry)
>> +   if (edev->dev.parent && edev->dev.parent->of_node == node)
>> +   goto out;
>> +   edev = ERR_PTR(-EPROBE_DEFER);
>> +out:
>> +   mutex_unlock(_dev_list_lock);
>> +
>> +   return edev;
> Can't it be done using bus_find_device()?

There is no special extcon bus, so I am not sure. Anyway if it can, it
should be done probably in another patch.

Regards
Andrzej

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

Re: [PATCH v4 04/16] of: changesets: Introduce changeset helper methods

[Geert Uytterhoeven]

Hi Rob,

On Wed, Feb 21, 2018 at 4:23 PM, Rob Herring  wrote:
> On Wed, Feb 21, 2018 at 4:21 AM, Geert Uytterhoeven
>  wrote:
>> You missed one fix I have in my topic/overlays branch
>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/commit/?h=topic/overlays=150f95b9dec77ce371c229f7ac4d6dd8620bef4a
>
> Are you planning to try to upstream all this? If not, I'll get Frank

Not really. But I do need a way to load DT overlays at runtime, for testing
hardware on expansion connectors.

> to keep changing the overlay API to make carrying it out of tree more
> painful. :)

He already did a very good job w.r.t. that in v4.15-rc1 ;^)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Rob Clark]

On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä
 wrote:
> On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote:
>> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä
>>  wrote:
>> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote:
>> >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä
>> >>  wrote:
>> >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
>> >> >> Follow the same pattern of locking as with other state objects.  This
>> >> >> avoids boilerplate in the driver.
>> >> >
>> >> > I'm not sure we really want to do this. What if the driver wants a
>> >> > custom locking scheme for this state?
>> >>
>> >> That seems like something we want to discourage, ie. all the more
>> >> reason for this patch.
>> >>
>> >> There is no reason drivers could not split their global state into
>> >> multiple private objs's, each with their own lock, for more fine
>> >> grained locking.  That is basically the only valid reason I can think
>> >> of for "custom locking".
>> >
>> > In i915 we have at least one case that would want something close to an
>> > rwlock. Any crtc lock is enough for read, need all of them for write.
>> > Though if we wanted to use private objs for that we might need to
>> > actually make the states refcounted as well, otherwise I can imagine
>> > we might land in some use-after-free issues once again.
>> >
>> > Maybe we could duplicate the state into per-crtc and global copies, but
>> > then we have to keep all of those in sync somehow which doesn't sound
>> > particularly pleasant.
>>
>> Or just keep your own driver lock for read, and use that plus the core
>> modeset lock for write?
>
> If we can't add the private obj to the state we can't really use it.
>

I'm not sure why that is strictly true (that you need to add it to the
state if for read-only), since you'd be guarding it with your own
driver read-lock you can just priv->foo_state->bar.

Since it is read-only access, there is no roll-back to worry about for
test-only or failed atomic_check()s..

BR,
-R


>>
>> BR,
>> -R
>>
>> >
>> >>
>> >> (And ofc drivers could add there own locks in addition to what is done
>> >> by core, but I'd rather look at that on a case by case basis, rather
>> >> than it being part of the boilerplate in each driver.)
>> >>
>> >> BR,
>> >> -R
>> >>
>> >> >>
>> >> >> Signed-off-by: Rob Clark 
>> >> >> ---
>> >> >>  drivers/gpu/drm/drm_atomic.c | 9 -
>> >> >>  include/drm/drm_atomic.h | 5 +
>> >> >>  2 files changed, 13 insertions(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/drm_atomic.c 
>> >> >> b/drivers/gpu/drm/drm_atomic.c
>> >> >> index fc8c4da409ff..004e621ab307 100644
>> >> >> --- a/drivers/gpu/drm/drm_atomic.c
>> >> >> +++ b/drivers/gpu/drm/drm_atomic.c
>> >> >> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct 
>> >> >> drm_private_obj *obj,
>> >> >>  {
>> >> >>   memset(obj, 0, sizeof(*obj));
>> >> >>
>> >> >> + drm_modeset_lock_init(>lock);
>> >> >> +
>> >> >>   obj->state = state;
>> >> >>   obj->funcs = funcs;
>> >> >>  }
>> >> >> @@ -1093,6 +1095,7 @@ void
>> >> >>  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
>> >> >>  {
>> >> >>   obj->funcs->atomic_destroy_state(obj, obj->state);
>> >> >> + drm_modeset_lock_fini(>lock);
>> >> >>  }
>> >> >>  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
>> >> >>
>> >> >> @@ -1113,7 +1116,7 @@ struct drm_private_state *
>> >> >>  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
>> >> >>struct drm_private_obj *obj)
>> >> >>  {
>> >> >> - int index, num_objs, i;
>> >> >> + int index, num_objs, i, ret;
>> >> >>   size_t size;
>> >> >>   struct __drm_private_objs_state *arr;
>> >> >>   struct drm_private_state *obj_state;
>> >> >> @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct 
>> >> >> drm_atomic_state *state,
>> >> >>   if (obj == state->private_objs[i].ptr)
>> >> >>   return state->private_objs[i].state;
>> >> >>
>> >> >> + ret = drm_modeset_lock(>lock, state->acquire_ctx);
>> >> >> + if (ret)
>> >> >> + return ERR_PTR(ret);
>> >> >> +
>> >> >>   num_objs = state->num_private_objs + 1;
>> >> >>   size = sizeof(*state->private_objs) * num_objs;
>> >> >>   arr = krealloc(state->private_objs, size, GFP_KERNEL);
>> >> >> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
>> >> >> index 09076a625637..9ae53b73c9d2 100644
>> >> >> --- a/include/drm/drm_atomic.h
>> >> >> +++ b/include/drm/drm_atomic.h
>> >> >> @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
>> >> >>   * _modeset_lock is required to duplicate and update this 
>> >> >> object's state.
>> >> >>   */
>> >> >>  struct drm_private_obj {
>> >> >> + /**
>> >> >> +  * @lock: Modeset lock to protect the state object.
>> >> >> +  */

Re: [PATCH v2 08/10] drm/panel: Add Huarui LHR050H41 panel driver

[Chen-Yu Tsai]

Hi,

On Wed, Feb 21, 2018 at 5:20 PM, Maxime Ripard
 wrote:
> From: Maxime Ripard 
>
> The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic. Add a
> driver for it.

So I distinctly remember questioning the vendor name the first time.
I would just use Bananapi as the vendor name instead.

>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/panel/Kconfig  |   9 +-
>  drivers/gpu/drm/panel/Makefile |   1 +-
>  drivers/gpu/drm/panel/panel-huarui-lhr050h41.c | 506 ++-
>  3 files changed, 516 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-huarui-lhr050h41.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6ba4031f3919..965310fd129a 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -28,6 +28,15 @@ config DRM_PANEL_SIMPLE
>   that it can be automatically turned off when the panel goes into a
>   low power state.
>
> +config DRM_PANEL_HUARUI_LHR050H41
> +   tristate "Huarui LHR050H41 panel"
> +   depends on OF
> +   depends on DRM_MIPI_DSI
> +   depends on BACKLIGHT_CLASS_DEVICE
> +   help
> + Say Y if you want to enable support for the Huarui Lighting
> + LHR05041 DSI panel. The panel has a 1280x720 resolution.
> +

And it seems this panel is driven by an ILI9881C from Ilitek. So
maybe you could make the panel driver more like the IL9322, as in
having common code for the driver IC, then a data structure tied
to actual panel compatible strings to handle any quirks.

The datasheet can be found simply by googling the part ID, or here:

   http://en.startek-lcd.com/res/starteklcden/pdres/201706/20170617115241070.pdf

This should help with the init command sequence.

I also found this:

http://www.ampdisplay.com/documents/pdf/AM-7201280ETZQW-00H.pdf

which might or might not be the same panel.

Now the IL9332 driver simply uses the device model (Dlink DIR-685)
as part of the compatible string.

Regards
ChenYu

>  config DRM_PANEL_ILITEK_IL9322
> tristate "Ilitek ILI9322 320x240 QVGA panels"
> depends on OF && SPI
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Ville Syrjälä]

On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote:
> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä
>  wrote:
> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote:
> >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä
> >>  wrote:
> >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
> >> >> Follow the same pattern of locking as with other state objects.  This
> >> >> avoids boilerplate in the driver.
> >> >
> >> > I'm not sure we really want to do this. What if the driver wants a
> >> > custom locking scheme for this state?
> >>
> >> That seems like something we want to discourage, ie. all the more
> >> reason for this patch.
> >>
> >> There is no reason drivers could not split their global state into
> >> multiple private objs's, each with their own lock, for more fine
> >> grained locking.  That is basically the only valid reason I can think
> >> of for "custom locking".
> >
> > In i915 we have at least one case that would want something close to an
> > rwlock. Any crtc lock is enough for read, need all of them for write.
> > Though if we wanted to use private objs for that we might need to
> > actually make the states refcounted as well, otherwise I can imagine
> > we might land in some use-after-free issues once again.
> >
> > Maybe we could duplicate the state into per-crtc and global copies, but
> > then we have to keep all of those in sync somehow which doesn't sound
> > particularly pleasant.
> 
> Or just keep your own driver lock for read, and use that plus the core
> modeset lock for write?

If we can't add the private obj to the state we can't really use it.

> 
> BR,
> -R
> 
> >
> >>
> >> (And ofc drivers could add there own locks in addition to what is done
> >> by core, but I'd rather look at that on a case by case basis, rather
> >> than it being part of the boilerplate in each driver.)
> >>
> >> BR,
> >> -R
> >>
> >> >>
> >> >> Signed-off-by: Rob Clark 
> >> >> ---
> >> >>  drivers/gpu/drm/drm_atomic.c | 9 -
> >> >>  include/drm/drm_atomic.h | 5 +
> >> >>  2 files changed, 13 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> >> index fc8c4da409ff..004e621ab307 100644
> >> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> >> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct 
> >> >> drm_private_obj *obj,
> >> >>  {
> >> >>   memset(obj, 0, sizeof(*obj));
> >> >>
> >> >> + drm_modeset_lock_init(>lock);
> >> >> +
> >> >>   obj->state = state;
> >> >>   obj->funcs = funcs;
> >> >>  }
> >> >> @@ -1093,6 +1095,7 @@ void
> >> >>  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
> >> >>  {
> >> >>   obj->funcs->atomic_destroy_state(obj, obj->state);
> >> >> + drm_modeset_lock_fini(>lock);
> >> >>  }
> >> >>  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
> >> >>
> >> >> @@ -1113,7 +1116,7 @@ struct drm_private_state *
> >> >>  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> >> >>struct drm_private_obj *obj)
> >> >>  {
> >> >> - int index, num_objs, i;
> >> >> + int index, num_objs, i, ret;
> >> >>   size_t size;
> >> >>   struct __drm_private_objs_state *arr;
> >> >>   struct drm_private_state *obj_state;
> >> >> @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct 
> >> >> drm_atomic_state *state,
> >> >>   if (obj == state->private_objs[i].ptr)
> >> >>   return state->private_objs[i].state;
> >> >>
> >> >> + ret = drm_modeset_lock(>lock, state->acquire_ctx);
> >> >> + if (ret)
> >> >> + return ERR_PTR(ret);
> >> >> +
> >> >>   num_objs = state->num_private_objs + 1;
> >> >>   size = sizeof(*state->private_objs) * num_objs;
> >> >>   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> >> >> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> >> >> index 09076a625637..9ae53b73c9d2 100644
> >> >> --- a/include/drm/drm_atomic.h
> >> >> +++ b/include/drm/drm_atomic.h
> >> >> @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
> >> >>   * _modeset_lock is required to duplicate and update this object's 
> >> >> state.
> >> >>   */
> >> >>  struct drm_private_obj {
> >> >> + /**
> >> >> +  * @lock: Modeset lock to protect the state object.
> >> >> +  */
> >> >> + struct drm_modeset_lock lock;
> >> >> +
> >> >>   /**
> >> >>* @state: Current atomic state for this driver private object.
> >> >>*/
> >> >> --
> >> >> 2.14.3
> >> >>
> >> >> ___
> >> >> dri-devel mailing list
> >> >> dri-devel@lists.freedesktop.org
> >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> >
> >> > --
> >> > Ville Syrjälä
> >> > Intel OTC
> >
> > --
> > Ville Syrjälä
> > Intel OTC

-- 
Ville Syrjälä
Intel