Re: [PATCH 02/10] drm/etnaviv: mmuv2: don't map zero page

[Christian Gmeiner]

Am Mi., 19. Dez. 2018 um 15:45 Uhr schrieb Lucas Stach :
>
> Keep the page at address 0 as faulting to catch any potential state
> setup issues early.
>
> Signed-off-by: Lucas Stach 

I like this idea.. but I am unsure about Guido's GC7000 problem.

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> index f1c88d8ad5ba..f794e04be9e6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> @@ -320,8 +320,8 @@ etnaviv_iommuv2_domain_alloc(struct etnaviv_gpu *gpu)
> domain = &etnaviv_domain->base;
>
> domain->dev = gpu->dev;
> -   domain->base = 0;
> -   domain->size = (u64)SZ_1G * 4;
> +   domain->base = SZ_4K;
> +   domain->size = (u64)SZ_1G * 4 - SZ_4K;
> domain->ops = &etnaviv_iommuv2_ops;
>
> ret = etnaviv_iommuv2_init(etnaviv_domain);
> --
> 2.19.1
>


-- 
greets
--
Christian Gmeiner, MSc

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

[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay

[bugzilla-daemon]

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

--- Comment #174 from EmilyBrown  ---
Thanks for coming with detailed bug which you faced while starting X server and
what happened after few minutes within screenshots for better reference to find
a solution for other users and experts of it.

Emily,
http://www.dissertationhelp.uk

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

[radeon-alex:drm-next-5.1-wip 17/212] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_module.c:79:18: sparse: warning: non-ANSI function declaration of function 'kgd2kfd_init'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-5.1-wip
head:   8054c54a6169ca26157d2bed0b52f63d472dbd34
commit: 308176d6f625bc782a34ec316beaefcfa7ad75f3 [17/212] drm/amdgpu: Remove 
kgd2kfd function pointers
reproduce:
# apt-get install sparse
git checkout 308176d6f625bc782a34ec316beaefcfa7ad75f3
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_module.c:79:18: sparse: warning: 
>> non-ANSI function declaration of function 'kgd2kfd_init'

vim +/kgd2kfd_init +79 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_module.c

78  
  > 79  int kgd2kfd_init()
80  {
81  return kfd_init();
82  }
83  

---
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 v2 5/6] drm/virtio: drop fencing in virtio_gpu_resource_create_ioctl

[Gerd Hoffmann]

On Thu, Jan 31, 2019 at 11:04:31AM -0800, Gurchetan Singh wrote:
> On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann  wrote:
> >
> > There is no need to wait for completion here.
> >
> > The host will process commands in submit order, so commands can
> > reference the new resource just fine even when queued up before
> > completion.
> 
> Does virtio_gpu_execbuffer_ioctl also wait for completion for a host response?

No.

But you pass in a list of objects (drm_virtgpu_execbuffer->bo_handles)
used.  They will all get reserved, so you can use DRM_IOCTL_VIRTGPU_WAIT
on any of these objects to wait for completion.

Recently the driver got support for returning a fence fd for the
execbuffer, which you can also use to wait for completion in case your
kernel is new enough.

> From the guest driver perspective, a fence is just implemented has a
> virtio 3D resource.
> 
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c#L787
> 
> The DRM_IOCTL_VIRTGPU_WAIT ioctl essentially waits for the reservation
> objects associated with that fence resource to become available.  So
> the flow is:
> 
> virtio_gpu_execbuffer_ioctl
> virtio_gpu_resource_create_ioctl with fence resource
> virtio_gpu_wait_ioctl with that fence resource --> associated with a
> GL wait on the host side

Oh.  /me looks surprised.
Wasn't aware that userspace is doing *that*.

> Does this change modify this sequence of events?

Yes.  DRM_IOCTL_VIRTGPU_WAIT will not wait any more.  Guess I have to
scratch the patch then ...

cheers,
  Gerd

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

[pull] ttm, amdgpu drm-next-5.1

[Alex Deucher]

Hi Dave, Daniel,

More stuff for 5.1.  Mostly bug fixes.
ttm:
- Replace ref/unref naming with get/put

amdgpu:
- Revert DC clang fix, causes a segfault with some compiler versions
- SR-IOV fix
- PCIE fix for vega20
- Misc DC fixes

The following changes since commit 10117450735c7a7c0858095fb46a860e7037cb9a:

  drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to 
undefined SW FP routines (2019-01-25 16:15:37 -0500)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-5.1

for you to fetch changes up to 47dd8048a1bf5b2fb96e5abe99b4f1dcd208ea4d:

  drm/amdgpu: Show XGMI node and hive message per device only once (2019-01-29 
15:16:18 -0500)


Alex Deucher (1):
  Revert "drm/amd/display: add -msse2 to prevent Clang from emitting 
libcalls to undefined SW FP routines"

Eric Huang (1):
  drm/amd/powerplay: add override pcie parameters for Vega20

Fatemeh Darbehani (1):
  drm/amd/display: Add Vline1 interrupt source to InterruptManager

Martin Tsai (1):
  drm/amd/display: Poll pending down rep before clear payload allocation 
table

Nicholas Kazlauskas (3):
  drm/amd/display: Enable vblank interrupt during CRC capture
  drm/amd/display: Re-enable CRC capture following modeset
  drm/amd/display: Don't leak memory when updating streams

Thomas Zimmermann (7):
  drm/ast: Replace ttm_bo_unref with ttm_bo_put
  drm/nouveau: Replace ttm_bo_reference with ttm_bo_get
  drm/nouveau: Replace ttm_bo_unref with ttm_bo_put
  drm/vmwgfx: Replace ttm_bo_reference with ttm_bo_get
  drm/vmwgfx: Replace ttm_bo_unref with ttm_bo_put
  drm/mgag200: Replace ttm_bo_unref with ttm_bo_put
  drm/ttm: Remove ttm_bo_reference and ttm_bo_unref

shaoyunl (1):
  drm/amdgpu: Show XGMI node and hive message per device only once

wentalou (2):
  drm/amdgpu: csa_vaddr should not larger than AMDGPU_GMC_HOLE_START
  drm/amdgpu: sriov restrict max_pfn below AMDGPU_GMC_HOLE

 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   |  7 +--
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  6 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 29 -
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c  | 48 ---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c  |  7 +++
 drivers/gpu/drm/amd/display/dc/calcs/Makefile  |  2 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 10 +--
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  5 ++
 drivers/gpu/drm/amd/display/dc/dc_stream.h | 14 -
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c  | 72 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.h  | 12 +++-
 drivers/gpu/drm/amd/display/dc/dm_helpers.h|  7 +++
 drivers/gpu/drm/amd/display/dc/dml/Makefile|  2 +-
 .../drm/amd/display/dc/inc/hw/timing_generator.h   | 13 +++-
 drivers/gpu/drm/amd/display/dc/irq_types.h |  8 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 46 ++
 drivers/gpu/drm/ast/ast_main.c |  6 +-
 drivers/gpu/drm/mgag200/mgag200_main.c |  8 +--
 drivers/gpu/drm/nouveau/nouveau_bo.h   | 12 ++--
 drivers/gpu/drm/nouveau/nouveau_gem.c  |  3 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |  9 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 11 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 11 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  9 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c| 21 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  9 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_validation.c |  6 +-
 include/drm/ttm/ttm_bo_api.h   | 28 -
 28 files changed, 239 insertions(+), 182 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109524] "Invalid glsl version in shading_language_version()" when trying to run directX games using wine

[bugzilla-daemon]

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

Mickey  changed:

   What|Removed |Added

URL||http://www.onedollarwebhost
   ||ings.com/rs-99-web-hosting-
   ||domain-godaddy-india.html

--- Comment #1 from Mickey  ---
Such a nice post you shared with the audience.
http://www.onedollarwebhostings.com/rs-99-web-hosting-domain-godaddy-india.html
is the great to visit.

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

[drm-tip:drm-tip 891/897] drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:160:9: warning: #pragma pack (pop) encountered without matching #pragma pack (push)

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   3f287cb6d4ae4689eb7c53e4c25f0fba3df16438
commit: 0a2fe4901d16d28bb8ad5f7032e9579f85e7e594 [891/897] Merge 
remote-tracking branch 'drm/drm-next' into drm-tip
config: riscv-allmodconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0a2fe4901d16d28bb8ad5f7032e9579f85e7e594
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=riscv 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:160:9: 
>> warning: #pragma pack (pop) encountered without matching #pragma pack (push) 
>> [-Wpragmas]
#pragma pack(pop)
^~~~

vim +160 drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c

bf75572a Josip Pavic   2019-01-08  117  
bf75572a Josip Pavic   2019-01-08  118  struct iram_table_v_2_2 {
bf75572a Josip Pavic   2019-01-08  119  /* flags  */
bf75572a Josip Pavic   2019-01-08  120  uint16_t flags; 
/* 0x00 U16  */
bf75572a Josip Pavic   2019-01-08  121  
bf75572a Josip Pavic   2019-01-08  122  /* parameters for ABM2.2 
algorithm */
bf75572a Josip Pavic   2019-01-08  123  uint8_t 
min_reduction[NUM_AMBI_LEVEL][NUM_AGGR_LEVEL];  /* 0x02 U0.8 */
bf75572a Josip Pavic   2019-01-08  124  uint8_t 
max_reduction[NUM_AMBI_LEVEL][NUM_AGGR_LEVEL];  /* 0x16 U0.8 */
bf75572a Josip Pavic   2019-01-08  125  uint8_t 
bright_pos_gain[NUM_AMBI_LEVEL][NUM_AGGR_LEVEL];/* 0x2a U2.6 */
bf75572a Josip Pavic   2019-01-08  126  uint8_t 
dark_pos_gain[NUM_AMBI_LEVEL][NUM_AGGR_LEVEL];  /* 0x3e U2.6 */
bf75572a Josip Pavic   2019-01-08  127  uint8_t 
hybridFactor[NUM_AGGR_LEVEL];   /* 0x52 
U0.8 */
bf75572a Josip Pavic   2019-01-08  128  uint8_t 
contrastFactor[NUM_AGGR_LEVEL]; /* 0x56 
U0.8 */
bf75572a Josip Pavic   2019-01-08  129  uint8_t 
deviation_gain[NUM_AGGR_LEVEL]; /* 0x5a 
U0.8 */
bf75572a Josip Pavic   2019-01-08  130  uint8_t 
iir_curve[NUM_AMBI_LEVEL];  
/* 0x5e U0.8 */
bf75572a Josip Pavic   2019-01-08  131  uint8_t pad[29];
/* 0x63 
U0.8 */
bf75572a Josip Pavic   2019-01-08  132  
bf75572a Josip Pavic   2019-01-08  133  /* parameters for crgb 
conversion */
bf75572a Josip Pavic   2019-01-08  134  uint16_t 
crgb_thresh[NUM_POWER_FN_SEGS];/* 0x80 
U3.13 */
bf75572a Josip Pavic   2019-01-08  135  uint16_t 
crgb_offset[NUM_POWER_FN_SEGS];/* 0x90 
U1.15 */
bf75572a Josip Pavic   2019-01-08  136  uint16_t 
crgb_slope[NUM_POWER_FN_SEGS]; /* 0xa0 
U4.12 */
bf75572a Josip Pavic   2019-01-08  137  
bf75572a Josip Pavic   2019-01-08  138  /* parameters for custom curve 
*/
bf75572a Josip Pavic   2019-01-08  139  /* thresholds for brightness 
--> backlight */
bf75572a Josip Pavic   2019-01-08  140  uint16_t 
backlight_thresholds[NUM_BL_CURVE_SEGS];   /* 0xb0 U16.0 */
bf75572a Josip Pavic   2019-01-08  141  /* offsets for brightness --> 
backlight */
bf75572a Josip Pavic   2019-01-08  142  uint16_t 
backlight_offsets[NUM_BL_CURVE_SEGS];  /* 0xd0 U16.0 */
bf75572a Josip Pavic   2019-01-08  143  
bf75572a Josip Pavic   2019-01-08  144  /* For reading PSR State 
directly from IRAM */
bf75572a Josip Pavic   2019-01-08  145  uint8_t psr_state;  
/* 0xf0 
  */
bf75572a Josip Pavic   2019-01-08  146  uint8_t 
dmcu_mcp_interface_version; 
/* 0xf1   */
bf75572a Josip Pavic   2019-01-08  147  uint8_t 
dmcu_abm_feature_version;   
/* 0xf2   */
bf75572a Josip Pavic   2019-01-08  148  uint8_t 
dmcu_psr_feature_version;   
/* 0xf3   */
bf75572a Josip Pavic   2019-01-08  149  uint16_t dmcu_version;  
/* 0xf4   */
bbf854dc David Francis 2018-11-26  150  uint8_t dmcu_state; 
/* 0xf6 
  */
bbf854dc David Francis 2018-11-26  151  
bbf854

[pull] radeon, amdgpu drm-fixes-5.0

[Alex Deucher]

Hi Dave, Daniel,

Sorry this is a bit late.  I had Internet issues yesterday.
A few fixes for 5.0:
- Fix radeon crash on SI with VM passthrough
- Fencing fix for shared buffers
- Fix power hwmon reporting on APUs
- Powerplay fix for APUs

The following changes since commit f0e7ce1eef5854584dfb59b3824a67edee37580f:

  Merge tag 'drm-msm-fixes-2019-01-24' of 
git://people.freedesktop.org/~robclark/linux into drm-fixes (2019-01-25 
07:45:00 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-5.0

for you to fetch changes up to 6e11ea9de9576a644045ffdc2067c09bc2012eda:

  drm/amdgpu: Transfer fences to dmabuf importer (2019-01-30 12:52:44 -0500)


Alex Deucher (2):
  drm/amdgpu: Add missing power attribute to APU check
  drm/radeon: check if device is root before getting pci speed caps

Chris Wilson (1):
  drm/amdgpu: Transfer fences to dmabuf importer

Gustavo A. R. Silva (1):
  drm/amd/powerplay: Fix missing break in switch

 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 59 ---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c |  1 +
 drivers/gpu/drm/radeon/ci_dpm.c   |  5 +-
 drivers/gpu/drm/radeon/si_dpm.c   |  5 +-
 5 files changed, 60 insertions(+), 13 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/vmwgfx: Fix an uninitialized fence handle value

[Deepak Singh Rawat]

Reviewed-by: Deepak Rawat 

On Thu, 2019-01-31 at 10:52 +0100, Thomas Hellstrom wrote:
> if vmw_execbuf_fence_commands() fails, The handle value will be
> uninitialized and a bogus fence handle might be copied to user-space.
> 
> Fixes: 2724b2d54cda: ("drm/vmwgfx: Use new validation interface for
> the modesetting code v2")
> Reported-by: Dan Carpenter 
> Signed-off-by: Thomas Hellstrom 
> Reviewed-by: Brian Paul  #v1
> Reviewed-by: Sinclair Yeh  #v1
> ---
> v2: Also initialize the ret local variable, to silence compilatior
> warnings.
> Call vmw_execbuf_copy_fence_user regardless of the value of ret, to
> propagate
> the correct error code to user-space.
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index b351fb5214d3..5e257a600cea 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -2554,8 +2554,8 @@ void vmw_kms_helper_validation_finish(struct
> vmw_private *dev_priv,
> user_fence_rep)
>  {
>   struct vmw_fence_obj *fence = NULL;
> - uint32_t handle;
> - int ret;
> + uint32_t handle = 0;
> + int ret = 0;
>  
>   if (file_priv || user_fence_rep || vmw_validation_has_bos(ctx)
> ||
>   out_fence)

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

Re: [PATCH] drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user

[Deepak Singh Rawat]

Reviewed-by: Deepak Rawat 

On Thu, 2019-01-31 at 11:07 +0100, Thomas Hellstrom wrote:
> The function was unconditionally returning 0, and a caller would have
> to
> rely on the returned fence pointer being NULL to detect errors.
> However,
> the function vmw_execbuf_copy_fence_user() would expect a non-zero
> error
> code in that case and would BUG otherwise.
> 
> So make sure we return a proper non-zero error code if the fence
> pointer
> returned is NULL.
> 
> Fixes: ae2a104058e2: ("vmwgfx: Implement fence objects")
> Signed-off-by: Thomas Hellstrom 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index f2d13a72c05d..88b8178d4687 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -3570,7 +3570,7 @@ int vmw_execbuf_fence_commands(struct drm_file
> *file_priv,
>   *p_fence = NULL;
>   }
>  
> - return 0;
> + return ret;
>  }
>  
>  /**

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

[PATCH v2 4/4] drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

[Lyude Paul]

Atomic checks should never modify anything outside of the state that
they're passed in. Unfortunately this appears to be exactly what we're
doing in nv50_msto_atomic_check() where we update mstc->pbn every time
the function is called. This hasn't caused any bugs yet, but it needs to
be fixed in order to ensure that when committing an artificially
duplicated state (like during system resume), that we reuse the PBN of
that state to perform VCPI allocations and don't recalculate a different
value from the drm connector's reported bpc.

Also, move the VCPI slot allocations while we're at it as well. With
this, removing a topology in suspend while using nouveau no longer
causes the new atomic VCPI helpers to complain.

Signed-off-by: Lyude Paul 
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Cc: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  6 ++
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 28 +++--
 drivers/gpu/drm/nouveau/dispnv50/head.c |  1 +
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h 
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index a194990d2b0d..b5fae5ab3fa8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -116,6 +116,12 @@ struct nv50_head_atom {
u8 depth:4;
} or;
 
+   /* Currently only used for MST */
+   struct {
+   int pbn;
+   u8 tu:6;
+   } dp;
+
union nv50_head_atom_mask {
struct {
bool olut:1;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 60d858c2f2ce..e8bb35f6d015 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -659,8 +659,6 @@ struct nv50_mstc {
 
struct drm_display_mode *native;
struct edid *edid;
-
-   int pbn;
 };
 
 struct nv50_msto {
@@ -765,17 +763,26 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
struct drm_connector *connector = conn_state->connector;
struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
-   int bpp = connector->display_info.bpc * 3;
+   struct nv50_head_atom *asyh = nv50_head_atom(crtc_state);
int slots;
 
-   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
-bpp);
+   /* When restoring duplicated states, we need to make sure that the
+* bw remains the same and avoid recalculating it, as the connector's
+* bpc may have changed after the state was duplicated
+*/
+   if (!state->duplicated)
+   asyh->dp.pbn =
+   drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+connector->display_info.bpc * 3);
 
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
- mstc->port, mstc->pbn);
+ mstc->port,
+ asyh->dp.pbn);
if (slots < 0)
return slots;
+
+   asyh->dp.tu = slots;
}
 
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
@@ -786,13 +793,13 @@ static void
 nv50_msto_enable(struct drm_encoder *encoder)
 {
struct nv50_head *head = nv50_head(encoder->crtc);
+   struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
struct nv50_msto *msto = nv50_msto(encoder);
struct nv50_mstc *mstc = NULL;
struct nv50_mstm *mstm = NULL;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
u8 proto, depth;
-   int slots;
bool r;
 
drm_connector_list_iter_begin(encoder->dev, &conn_iter);
@@ -808,8 +815,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
if (WARN_ON(!mstc))
return;
 
-   slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
-   r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn, slots);
+   r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, armh->dp.pbn,
+armh->dp.tu);
WARN_ON(!r);
 
if (!mstm->links++)
@@ -827,8 +834,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
default: depth = 0x6; break;
}
 
-   mstm->outp->update(mstm->outp, head->base.index,
-  nv50_head_atom(head->base.base.state), proto, depth);
+   mstm->outp->update(mstm->outp, head->base.index, armh, proto, depth);
 
msto->head = head;
msto->mstc = mstc;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index ac97ebce5b35..2

[PATCH v2 0/4] drm/dp_mst: Fix regressions from new atomic VCPI helpers

[Lyude Paul]

This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.

This time around, we use a slightly different but much less complicated
approach for fixing said issues.

Cc: Daniel Vetter 

Lyude Paul (4):
  drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
  drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()
  drm/atomic: Add drm_atomic_state->duplicated
  drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

 drivers/gpu/drm/drm_atomic_helper.c | 10 -
 drivers/gpu/drm/drm_dp_mst_topology.c   | 51 +
 drivers/gpu/drm/i915/intel_dp_mst.c | 17 +++--
 drivers/gpu/drm/nouveau/dispnv50/atom.h |  6 +++
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 31 ---
 drivers/gpu/drm/nouveau/dispnv50/head.c |  1 +
 include/drm/drm_atomic.h|  9 +
 7 files changed, 85 insertions(+), 40 deletions(-)

-- 
2.20.1

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

[PATCH v2 3/4] drm/atomic: Add drm_atomic_state->duplicated

[Lyude Paul]

Since

commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")

We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a connector is
unregistered before we attempt to restore the atomic state, something we
end up failing the atomic check that happens when trying to restore the
state during resume.

Normally this would be OK: we try our best to make sure that the atomic
state pre-suspend can be restored post-suspend, but failures at that
point usually don't cause problems. That is of course, until we
introduced the new atomic MST VCPI helpers:

[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B] active 
changed
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for 
[CONNECTOR:123:DP-5]
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling 
[CONNECTOR:123:DP-5]
[drm:drm_atomic_get_private_obj_state [drm]] Added new private object 
25844636 state 9fd2899a to 3a13d7b8
WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153 
drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl 
x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O) 
crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt 
snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer 
mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi 
thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video tpm 
acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci 
nvme_core xhci_hcd
CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW  O  
5.0.0-rc2Lyude-Test+ #1
Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f 
85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78 b3 
a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
RSP: 0018:88841235f268 EFLAGS: 00010246
RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
RDX: dc00 RSI:  RDI: ed108246bde0
RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
R13: 8883bc499100 R14: 88841bf12ab8 R15: 
FS:  7f16fbd4cd00() GS:88841ed8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
 ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
 ? __printk_safe_exit+0x10/0x10
 ? save_stack+0x8c/0xb0
 ? vprintk_func+0x96/0x1bf
 ? __printk_safe_exit+0x10/0x10
 intel_atomic_check+0x234/0x4750 [i915]
 ? printk+0x9f/0xc5
 ? kmsg_dump_rewind_nolock+0xd9/0xd9
 ? _raw_spin_lock_irqsave+0xa4/0x140
 ? drm_atomic_check_only+0xb1/0x28b0 [drm]
 ? drm_dbg+0x186/0x1b0 [drm]
 ? drm_dev_dbg+0x200/0x200 [drm]
 ? intel_link_compute_m_n+0xb0/0xb0 [i915]
 ? drm_mode_put_tile_group+0x20/0x20 [drm]
 ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
 ? drm_plane_check_pixel_format+0x14a/0x310 [drm]
 drm_atomic_check_only+0x13c4/0x28b0 [drm]
 ? drm_state_info+0x220/0x220 [drm]
 ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
 ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
 ? kasan_unpoison_shadow+0x35/0x40
 drm_atomic_commit+0x3b/0x100 [drm]
 drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
 drm_mode_setcrtc+0x636/0x1660 [drm]
 ? vprintk_func+0x96/0x1bf
 ? drm_dev_dbg+0x200/0x200 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? printk+0x9f/0xc5
 ? mutex_unlock+0x1d/0x40
 ? drm_mode_addfb2+0x2e9/0x3a0 [drm]
 ? rcu_sync_dtor+0x2e0/0x2e0
 ? drm_dbg+0x186/0x1b0 [drm]
 ? set_page_dirty+0x271/0x4d0
 drm_ioctl_kernel+0x203/0x290 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? drm_setversion+0x7f0/0x7f0 [drm]
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x34/0x70
 drm_ioctl+0x445/0x950 [drm]
 ? drm_mode_getcrtc+0x790/0x790 [drm]
 ? drm_getunique+0x220/0x220 [drm]
 ? expand_files.part.10+0x920/0x920
 do_vfs_ioctl+0x1a1/0x13d0
 ? ioctl_preallocate+0x2b0/0x2b0
 ? __fget_light+0x2d6/0x390
 ? schedule+0xd7/0x2e0
 ? fget_raw+0x10/0x10
 ? apic_timer_interrupt+0xa/0x20
 ? apic_timer_interrupt+0xa/0x20
 ? rcu_cleanup_dead_rnp+0x2c0/0x2c0
 ksys_ioctl+0x60/0x90
 __x64_sys_ioctl+0x6f/0xb0
 do_syscall_64+0x136/0x440
 ? syscall_return_slow

[PATCH v2 1/4] drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

[Lyude Paul]

In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call
drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we
never successfully allocated VCPI to it. This is contrary to what we do
in drm_dp_mst_allocate_vcpi(), where we only call
drm_dp_mst_get_port_malloc() on the passed port if we successfully
allocated VCPI to it.

As a result, if drm_dp_mst_allocate_vcpi() fails during a modeset and
another successive modeset calls drm_dp_mst_deallocate_vcpi() we will
end up dropping someone else's malloc reference to the port. Example:

[  962.309260] 
==
[  962.309290] BUG: KASAN: use-after-free in 
drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309296] Read of size 4 at addr 888416c30004 by task kworker/0:1H/500

[  962.309308] CPU: 0 PID: 500 Comm: kworker/0:1H Tainted: GW  O  
5.0.0-rc2Lyude-Test+ #1
[  962.309313] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 
) 04/09/2018
[  962.309428] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
[  962.309434] Call Trace:
[  962.309452]  dump_stack+0xad/0x150
[  962.309462]  ? dump_stack_print_info.cold.0+0x1b/0x1b
[  962.309472]  ? kmsg_dump_rewind_nolock+0xd9/0xd9
[  962.309504]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309515]  print_address_description+0x6c/0x23c
[  962.309542]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309568]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309577]  kasan_report.cold.3+0x1a/0x32
[  962.309605]  ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309631]  drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper]
[  962.309658]  ? drm_dp_mst_put_mstb_malloc+0x180/0x180 [drm_kms_helper]
[  962.309687]  drm_dp_mst_destroy_state+0xcd/0x120 [drm_kms_helper]
[  962.309745]  drm_atomic_state_default_clear+0x6ee/0xcc0 [drm]
[  962.309864]  intel_atomic_state_clear+0xe/0x80 [i915]
[  962.309928]  __drm_atomic_state_free+0x35/0xd0 [drm]
[  962.310044]  intel_atomic_cleanup_work+0x56/0x70 [i915]
[  962.310057]  process_one_work+0x884/0x1400
[  962.310067]  ? drain_workqueue+0x5a0/0x5a0
[  962.310075]  ? __schedule+0x87f/0x1e80
[  962.310086]  ? __sched_text_start+0x8/0x8
[  962.310095]  ? run_rebalance_domains+0x400/0x400
[  962.310110]  ? deref_stack_reg+0xb4/0x120
[  962.310117]  ? __read_once_size_nocheck.constprop.7+0x10/0x10
[  962.310124]  ? worker_enter_idle+0x47f/0x6a0
[  962.310134]  ? schedule+0xd7/0x2e0
[  962.310141]  ? __schedule+0x1e80/0x1e80
[  962.310148]  ? _raw_spin_lock_irq+0x9f/0x130
[  962.310155]  ? _raw_write_unlock_irqrestore+0x110/0x110
[  962.310164]  worker_thread+0x196/0x11e0
[  962.310175]  ? set_load_weight+0x2e0/0x2e0
[  962.310181]  ? __switch_to_asm+0x34/0x70
[  962.310187]  ? __switch_to_asm+0x40/0x70
[  962.310194]  ? process_one_work+0x1400/0x1400
[  962.310199]  ? __switch_to_asm+0x40/0x70
[  962.310205]  ? __switch_to_asm+0x34/0x70
[  962.310211]  ? __switch_to_asm+0x34/0x70
[  962.310216]  ? __switch_to_asm+0x40/0x70
[  962.310221]  ? __switch_to_asm+0x34/0x70
[  962.310226]  ? __switch_to_asm+0x40/0x70
[  962.310231]  ? __switch_to_asm+0x34/0x70
[  962.310236]  ? __switch_to_asm+0x40/0x70
[  962.310242]  ? syscall_return_via_sysret+0xf/0x7f
[  962.310248]  ? __switch_to_asm+0x34/0x70
[  962.310253]  ? __switch_to_asm+0x40/0x70
[  962.310258]  ? __switch_to_asm+0x34/0x70
[  962.310263]  ? __switch_to_asm+0x40/0x70
[  962.310268]  ? __switch_to_asm+0x34/0x70
[  962.310273]  ? __switch_to_asm+0x40/0x70
[  962.310281]  ? __schedule+0x87f/0x1e80
[  962.310292]  ? __sched_text_start+0x8/0x8
[  962.310300]  ? save_stack+0x8c/0xb0
[  962.310308]  ? __kasan_kmalloc.constprop.6+0xc6/0xd0
[  962.310313]  ? kthread+0x98/0x3a0
[  962.310318]  ? ret_from_fork+0x35/0x40
[  962.310334]  ? __wake_up_common+0x178/0x6f0
[  962.310343]  ? _raw_spin_lock_irqsave+0xa4/0x140
[  962.310349]  ? __lock_text_start+0x8/0x8
[  962.310355]  ? _raw_write_lock_irqsave+0x70/0x130
[  962.310360]  ? __lock_text_start+0x8/0x8
[  962.310371]  ? process_one_work+0x1400/0x1400
[  962.310376]  kthread+0x2e2/0x3a0
[  962.310383]  ? kthread_create_on_node+0xc0/0xc0
[  962.310389]  ret_from_fork+0x35/0x40

[  962.310401] Allocated by task 1462:
[  962.310410]  __kasan_kmalloc.constprop.6+0xc6/0xd0
[  962.310437]  drm_dp_add_port+0xd60/0x1960 [drm_kms_helper]
[  962.310464]  drm_dp_send_link_address+0x4b0/0x770 [drm_kms_helper]
[  962.310491]  drm_dp_check_and_send_link_address+0x197/0x1f0 [drm_kms_helper]
[  962.310515]  drm_dp_mst_link_probe_work+0x2b6/0x330 [drm_kms_helper]
[  962.310522]  process_one_work+0x884/0x1400
[  962.310529]  worker_thread+0x196/0x11e0
[  962.310533]  kthread+0x2e2/0x3a0
[  962.310538]  ret_from_fork+0x35/0x40

[  962.310543] Freed by task 500:
[  962.310550]  __kasan_slab_free+0x133/0x180
[  962.310555]  kfree+0x92/0x1a0
[  962.310581]  drm_dp_mst_put_port_malloc+0x14d/0x180 [drm_kms_helper]
[  962

[PATCH v2 2/4] drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()

[Lyude Paul]

Since we now have an easy way of refcounting drm_dp_mst_port structs and
safely accessing their contents, there isn't any good reason to keep
validating ports here. It doesn't prevent us from performing modesets on
branch devices that have been removed either, and we already disallow
enabling new displays on unregistered connectors in
update_connector_routing() in drm_atomic_check_modeset(). All it does is
cause us to have to make weird special exceptions in our atomic
modesetting code. So, get rid of it entirely.

Signed-off-by: Lyude Paul 
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c   | 12 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c | 17 ++---
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  3 +--
 3 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index abb0ea8ba9d9..4325e1518286 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3117,10 +3117,6 @@ int drm_dp_atomic_find_vcpi_slots(struct 
drm_atomic_state *state,
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
 
-   port = drm_dp_mst_topology_get_port_validated(mgr, port);
-   if (port == NULL)
-   return -EINVAL;
-
/* Find the current allocation for this port, if any */
list_for_each_entry(pos, &topology_state->vcpis, next) {
if (pos->port == port) {
@@ -3153,10 +3149,8 @@ int drm_dp_atomic_find_vcpi_slots(struct 
drm_atomic_state *state,
/* Add the new allocation to the state */
if (!vcpi) {
vcpi = kzalloc(sizeof(*vcpi), GFP_KERNEL);
-   if (!vcpi) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   if (!vcpi)
+   return -ENOMEM;
 
drm_dp_mst_get_port_malloc(port);
vcpi->port = port;
@@ -3165,8 +3159,6 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state 
*state,
vcpi->vcpi = req_slots;
 
ret = req_slots;
-out:
-   drm_dp_mst_topology_put_port(port);
return ret;
 }
 EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index cdb83d294cdd..fb67cd931117 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -80,17 +80,12 @@ static int intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
 
-   /* Zombie connectors can't have VCPI slots */
-   if (!drm_connector_is_unregistered(connector)) {
-   slots = drm_dp_atomic_find_vcpi_slots(state,
- &intel_dp->mst_mgr,
- port,
- mst_pbn);
-   if (slots < 0) {
-   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
- slots);
-   return slots;
-   }
+   slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr, port,
+ mst_pbn);
+   if (slots < 0) {
+   DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
+ slots);
+   return slots;
}
 
intel_link_compute_m_n(bpp, lane_count,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 2e8a5fd9b262..60d858c2f2ce 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -771,8 +771,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
 bpp);
 
-   if (drm_atomic_crtc_needs_modeset(crtc_state) &&
-   !drm_connector_is_unregistered(connector)) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state)) {
slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
  mstc->port, mstc->pbn);
if (slots < 0)
-- 
2.20.1

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

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

[Stephen Rothwell]

Hi all,

After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:160:9: 
warning: #pragma pack (pop) encountered without matching #pragma pack (push) 
[-Wpragmas]
 #pragma pack(pop)
 ^~~~

Introduced by commit

  1411fd85416f ("Merge remote-tracking branch 'drm/drm-next'")

Commits

  099139bef026 ("drm/amd/display: Pack DMCU iRAM alignment")

from Linus' tree and

  c591d8429df2 ("drm/amd/display: Pack DMCU iRAM alignment")

from the drm tree are identical, but then commit

  bf75572a2536 ("drm/amd/display: Create switching mechanism for ABM 2.2")

added more code before the "#pragma(pop)" and so git's automatic merge
resolution ended up adding the "#pragma(pop)" line twice.

I will fix up the merge resolution for tomorrow.  This will need to be
reported to Linus when the drm tree is merged (or a back merge of
Linus' tree will need to be done - and well commented :-)).

-- 
Cheers,
Stephen Rothwell


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

[PATCH 1/5] drm: Add reservation_object to drm_gem_object

[Rob Herring]

Many users of drm_gem_object embed a struct reservation_object into
their subclassed struct, so let's add one to struct drm_gem_object.
This will allow removing the reservation object from the subclasses
and removing the ->gem_prime_res_obj callback.

With the addition, add a drm_gem_reservation_object_wait() helper
function for drivers to use in wait ioctls.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Rob Herring 
---
 Documentation/gpu/todo.rst  |  9 -
 drivers/gpu/drm/drm_gem.c   | 39 +
 drivers/gpu/drm/drm_prime.c |  1 +
 include/drm/drm_gem.h   |  7 +++
 4 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 14191b64446d..6e0a37d0bf6d 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -209,15 +209,6 @@ Would be great to refactor this all into a set of small 
common helpers.
 
 Contact: Daniel Vetter
 
-Put a reservation_object into drm_gem_object
-
-
-This would remove the need for the ->gem_prime_res_obj callback. It would also
-allow us to implement generic helpers for waiting for a bo, allowing for quite 
a
-bit of refactoring in the various wait ioctl implementations.
-
-Contact: Daniel Vetter
-
 idr_init_base()
 ---
 
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 8b55ece97967..91dd06c1b3a8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -170,6 +170,10 @@ void drm_gem_private_object_init(struct drm_device *dev,
kref_init(&obj->refcount);
obj->handle_count = 0;
obj->size = size;
+   if (!obj->resv) {
+   obj->resv = &obj->_resv;
+   reservation_object_init(obj->resv);
+   }
drm_vma_node_reset(&obj->vma_node);
 }
 EXPORT_SYMBOL(drm_gem_private_object_init);
@@ -657,6 +661,40 @@ drm_gem_object_lookup(struct drm_file *filp, u32 handle)
 }
 EXPORT_SYMBOL(drm_gem_object_lookup);
 
+/**
+ * drm_gem_object_lookup - Wait on GEM object's reservation's objects
+ * shared and/or exclusive fences.
+ * @filp: DRM file private date
+ * @handle: userspace handle
+ * @wait_all: if true, wait on all fences, else wait on just exclusive fence
+ * @timeout: timeout value in jiffies or zero to return immediately
+ *
+ * Returns:
+ *
+ * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
+ * greater than 0 on success.
+ */
+long drm_gem_reservation_object_wait(struct drm_file *filep, u32 handle,
+   bool wait_all, unsigned long timeout)
+{
+   long ret;
+   struct drm_gem_object *obj;
+
+   obj = drm_gem_object_lookup(filep, handle);
+   if (!obj) {
+   DRM_DEBUG("Failed to look up GEM BO %d\n", handle);
+   return -EINVAL;
+   }
+
+   ret = reservation_object_wait_timeout_rcu(obj->resv, wait_all,
+ true, timeout);
+
+   drm_gem_object_put_unlocked(obj);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_gem_reservation_object_wait);
+
 /**
  * drm_gem_close_ioctl - implementation of the GEM_CLOSE ioctl
  * @dev: drm_device
@@ -821,6 +859,7 @@ drm_gem_object_release(struct drm_gem_object *obj)
if (obj->filp)
fput(obj->filp);
 
+   reservation_object_fini(&obj->_resv);
drm_gem_free_mmap_offset(obj);
 }
 EXPORT_SYMBOL(drm_gem_object_release);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 231e3f6d5f41..dc079efb3b0f 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -504,6 +504,7 @@ struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
.size = obj->size,
.flags = flags,
.priv = obj,
+   .resv = obj->resv,
};
 
if (dev->driver->gem_prime_res_obj)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index c95727425284..f450a5b6038e 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -35,6 +35,7 @@
  */
 
 #include 
+#include 
 
 #include 
 
@@ -262,6 +263,10 @@ struct drm_gem_object {
 */
struct dma_buf_attachment *import_attach;
 
+   /* normally (resv == &_resv) except for imported bo's */
+   struct reservation_object *resv;
+   struct reservation_object _resv;
+
/**
 * @funcs:
 *
@@ -363,6 +368,8 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct 
page **pages,
bool dirty, bool accessed);
 
 struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32 
handle);
+long drm_gem_reservation_object_wait(struct drm_file *filep, u32 handle,
+   bool wait_all, unsigned long timeout);
 int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
u32 handle, u64 

[PATCH 5/5] drm: vc4: Switch to use drm_gem_object reservation_object

[Rob Herring]

Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.

Cc: Eric Anholt 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/vc4/vc4_bo.c| 15 +--
 drivers/gpu/drm/vc4/vc4_drv.c   |  1 -
 drivers/gpu/drm/vc4/vc4_drv.h   |  7 +--
 drivers/gpu/drm/vc4/vc4_gem.c   | 18 +-
 drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
 5 files changed, 12 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 8dcce7182bb7..92e3f98d8478 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -201,8 +201,6 @@ static void vc4_bo_destroy(struct vc4_bo *bo)
bo->validated_shader = NULL;
}
 
-   reservation_object_fini(&bo->_resv);
-
drm_gem_cma_free_object(obj);
 }
 
@@ -427,8 +425,6 @@ struct drm_gem_object *vc4_create_object(struct drm_device 
*dev, size_t size)
vc4->bo_labels[VC4_BO_TYPE_KERNEL].num_allocated++;
vc4->bo_labels[VC4_BO_TYPE_KERNEL].size_allocated += size;
mutex_unlock(&vc4->bo_lock);
-   bo->resv = &bo->_resv;
-   reservation_object_init(bo->resv);
 
return &bo->base.base;
 }
@@ -684,13 +680,6 @@ static void vc4_bo_cache_time_timer(struct timer_list *t)
schedule_work(&vc4->bo_cache.time_work);
 }
 
-struct reservation_object *vc4_prime_res_obj(struct drm_gem_object *obj)
-{
-   struct vc4_bo *bo = to_vc4_bo(obj);
-
-   return bo->resv;
-}
-
 struct dma_buf *
 vc4_prime_export(struct drm_device *dev, struct drm_gem_object *obj, int flags)
 {
@@ -822,14 +811,12 @@ vc4_prime_import_sg_table(struct drm_device *dev,
  struct sg_table *sgt)
 {
struct drm_gem_object *obj;
-   struct vc4_bo *bo;
 
obj = drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
if (IS_ERR(obj))
return obj;
 
-   bo = to_vc4_bo(obj);
-   bo->resv = attach->dmabuf->resv;
+   obj->resv = attach->dmabuf->resv;
 
return obj;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index f6f5cd80c04d..d17df8c0291b 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -201,7 +201,6 @@ static struct drm_driver vc4_drm_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_export = vc4_prime_export,
-   .gem_prime_res_obj = vc4_prime_res_obj,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
.gem_prime_import_sg_table = vc4_prime_import_sg_table,
.gem_prime_vmap = vc4_prime_vmap,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 4f87b03f837d..76e6be9f7f7b 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -7,7 +7,7 @@
  */
 
 #include 
-#include 
+//#include 
 #include 
 #include 
 #include 
@@ -239,10 +239,6 @@ struct vc4_bo {
 */
struct vc4_validated_shader_info *validated_shader;
 
-   /* normally (resv == &_resv) except for imported bo's */
-   struct reservation_object *resv;
-   struct reservation_object _resv;
-
/* One of enum vc4_kernel_bo_type, or VC4_BO_TYPE_COUNT + i
 * for user-allocated labels.
 */
@@ -684,7 +680,6 @@ int vc4_label_bo_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
 vm_fault_t vc4_fault(struct vm_fault *vmf);
 int vc4_mmap(struct file *filp, struct vm_area_struct *vma);
-struct reservation_object *vc4_prime_res_obj(struct drm_gem_object *obj);
 int vc4_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
 struct drm_gem_object *vc4_prime_import_sg_table(struct drm_device *dev,
 struct dma_buf_attachment 
*attach,
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index aea2b8dfec17..5ee5bf7fedf7 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -536,7 +536,7 @@ vc4_update_bo_seqnos(struct vc4_exec_info *exec, uint64_t 
seqno)
bo = to_vc4_bo(&exec->bo[i]->base);
bo->seqno = seqno;
 
-   reservation_object_add_shared_fence(bo->resv, exec->fence);
+   reservation_object_add_shared_fence(bo->base.base.resv, 
exec->fence);
}
 
list_for_each_entry(bo, &exec->unref_list, unref_head) {
@@ -547,7 +547,7 @@ vc4_update_bo_seqnos(struct vc4_exec_info *exec, uint64_t 
seqno)
bo = to_vc4_bo(&exec->rcl_write_bo[i]->base);
bo->write_seqno = seqno;
 
-   reservation_object_add_excl_fence(bo->resv, exec->fence);
+   reservation_object_add_excl_fence(bo->base.base.resv, 
exec->fence);
}
 }
 
@@ -559,7 +559,7 @@ vc4_unlock_bo_reservations(struct drm_device *dev,
i

[PATCH 4/5] drm: v3d: Switch to use drm_gem_object reservation_object

[Rob Herring]

Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.

Cc: Eric Anholt 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/v3d/v3d_bo.c  | 14 +-
 drivers/gpu/drm/v3d/v3d_drv.c |  1 -
 drivers/gpu/drm/v3d/v3d_drv.h |  5 -
 drivers/gpu/drm/v3d/v3d_gem.c | 35 +--
 4 files changed, 10 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index a08766d39eab..814213d18a15 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -155,9 +155,6 @@ struct v3d_bo *v3d_bo_create(struct drm_device *dev, struct 
drm_file *file_priv,
return bo;
obj = &bo->base;
 
-   bo->resv = &bo->_resv;
-   reservation_object_init(bo->resv);
-
ret = v3d_bo_get_pages(bo);
if (ret)
goto free_mm;
@@ -194,8 +191,6 @@ void v3d_free_object(struct drm_gem_object *obj)
v3d->bo_stats.pages_allocated -= obj->size >> PAGE_SHIFT;
mutex_unlock(&v3d->bo_lock);
 
-   reservation_object_fini(&bo->_resv);
-
v3d_bo_put_pages(bo);
 
if (obj->import_attach)
@@ -212,13 +207,6 @@ void v3d_free_object(struct drm_gem_object *obj)
kfree(bo);
 }
 
-struct reservation_object *v3d_prime_res_obj(struct drm_gem_object *obj)
-{
-   struct v3d_bo *bo = to_v3d_bo(obj);
-
-   return bo->resv;
-}
-
 static void
 v3d_set_mmap_vma_flags(struct vm_area_struct *vma)
 {
@@ -290,7 +278,7 @@ v3d_prime_import_sg_table(struct drm_device *dev,
return ERR_CAST(bo);
obj = &bo->base;
 
-   bo->resv = attach->dmabuf->resv;
+   obj->resv = attach->dmabuf->resv;
 
bo->sgt = sgt;
obj->import_attach = attach;
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index f0afcec72c34..bafe8e54e75b 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -214,7 +214,6 @@ static struct drm_driver v3d_drm_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_export = drm_gem_prime_export,
-   .gem_prime_res_obj = v3d_prime_res_obj,
.gem_prime_get_sg_table = v3d_prime_get_sg_table,
.gem_prime_import_sg_table = v3d_prime_import_sg_table,
.gem_prime_mmap = v3d_prime_mmap,
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index dcb772a19191..5641d056b85d 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -133,10 +133,6 @@ struct v3d_bo {
 * v3d_exec_info->unref_list
 */
struct list_head unref_head;
-
-   /* normally (resv == &_resv) except for imported bo's */
-   struct reservation_object *resv;
-   struct reservation_object _resv;
 };
 
 static inline struct v3d_bo *
@@ -281,7 +277,6 @@ int v3d_get_bo_offset_ioctl(struct drm_device *dev, void 
*data,
struct drm_file *file_priv);
 vm_fault_t v3d_gem_fault(struct vm_fault *vmf);
 int v3d_mmap(struct file *filp, struct vm_area_struct *vma);
-struct reservation_object *v3d_prime_res_obj(struct drm_gem_object *obj);
 int v3d_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
 struct sg_table *v3d_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *v3d_prime_import_sg_table(struct drm_device *dev,
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 05ca6319065e..bee4fc3f47a8 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -214,7 +214,7 @@ v3d_attach_object_fences(struct v3d_bo **bos, int bo_count,
 
for (i = 0; i < bo_count; i++) {
/* XXX: Use shared fences for read-only objects. */
-   reservation_object_add_excl_fence(bos[i]->resv, fence);
+   reservation_object_add_excl_fence(bos[i]->base.resv, fence);
}
 }
 
@@ -226,7 +226,7 @@ v3d_unlock_bo_reservations(struct v3d_bo **bos,
int i;
 
for (i = 0; i < bo_count; i++)
-   ww_mutex_unlock(&bos[i]->resv->lock);
+   ww_mutex_unlock(&bos[i]->base.resv->lock);
 
ww_acquire_fini(acquire_ctx);
 }
@@ -252,7 +252,7 @@ v3d_lock_bo_reservations(struct v3d_bo **bos,
if (contended_lock != -1) {
struct v3d_bo *bo = bos[contended_lock];
 
-   ret = ww_mutex_lock_slow_interruptible(&bo->resv->lock,
+   ret = ww_mutex_lock_slow_interruptible(&bo->base.resv->lock,
   acquire_ctx);
if (ret) {
ww_acquire_done(acquire_ctx);
@@ -264,18 +264,18 @@ v3d_lock_bo_reservations(struct v3d_bo **bos,
if (i == contended_lock)
continue;
 
-   ret = ww_mutex_lock_interrupti

[PATCH 3/5] drm: msm: Switch to use drm_gem_object reservation_object

[Rob Herring]

Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.

We can't use the drm_gem_reservation_object_wait() helper for MSM
because (in theory) msm_gem_cpu_prep() will also do some cache
maintenance on the GEM object.

Cc: Rob Clark 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/msm/msm_drv.c|  1 -
 drivers/gpu/drm/msm/msm_drv.h|  1 -
 drivers/gpu/drm/msm/msm_gem.c| 27 +--
 drivers/gpu/drm/msm/msm_gem_prime.c  |  7 ---
 drivers/gpu/drm/msm/msm_gem_submit.c |  8 
 5 files changed, 13 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d2cdc7b553fe..522ddbd72250 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1086,7 +1086,6 @@ static struct drm_driver msm_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export   = drm_gem_prime_export,
.gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_res_obj  = msm_gem_prime_res_obj,
.gem_prime_pin  = msm_gem_prime_pin,
.gem_prime_unpin= msm_gem_prime_unpin,
.gem_prime_get_sg_table = msm_gem_prime_get_sg_table,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 927e5d86f7c1..068f9172ad70 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -300,7 +300,6 @@ struct sg_table *msm_gem_prime_get_sg_table(struct 
drm_gem_object *obj);
 void *msm_gem_prime_vmap(struct drm_gem_object *obj);
 void msm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 int msm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
-struct reservation_object *msm_gem_prime_res_obj(struct drm_gem_object *obj);
 struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach, struct sg_table *sg);
 int msm_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index c8886d3071fa..d3973cc26522 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -672,14 +672,13 @@ void msm_gem_vunmap(struct drm_gem_object *obj, enum 
msm_gem_lock subclass)
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive)
 {
-   struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct reservation_object_list *fobj;
struct dma_fence *fence;
int i, ret;
 
-   fobj = reservation_object_get_list(msm_obj->resv);
+   fobj = reservation_object_get_list(obj->resv);
if (!fobj || (fobj->shared_count == 0)) {
-   fence = reservation_object_get_excl(msm_obj->resv);
+   fence = reservation_object_get_excl(obj->resv);
/* don't need to wait on our own fences, since ring is fifo */
if (fence && (fence->context != fctx->context)) {
ret = dma_fence_wait(fence, true);
@@ -693,7 +692,7 @@ int msm_gem_sync_object(struct drm_gem_object *obj,
 
for (i = 0; i < fobj->shared_count; i++) {
fence = rcu_dereference_protected(fobj->shared[i],
-   
reservation_object_held(msm_obj->resv));
+   
reservation_object_held(obj->resv));
if (fence->context != fctx->context) {
ret = dma_fence_wait(fence, true);
if (ret)
@@ -711,9 +710,9 @@ void msm_gem_move_to_active(struct drm_gem_object *obj,
WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
msm_obj->gpu = gpu;
if (exclusive)
-   reservation_object_add_excl_fence(msm_obj->resv, fence);
+   reservation_object_add_excl_fence(obj->resv, fence);
else
-   reservation_object_add_shared_fence(msm_obj->resv, fence);
+   reservation_object_add_shared_fence(obj->resv, fence);
list_del_init(&msm_obj->mm_list);
list_add_tail(&msm_obj->mm_list, &gpu->active_list);
 }
@@ -733,13 +732,12 @@ void msm_gem_move_to_inactive(struct drm_gem_object *obj)
 
 int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t *timeout)
 {
-   struct msm_gem_object *msm_obj = to_msm_bo(obj);
bool write = !!(op & MSM_PREP_WRITE);
unsigned long remain =
op & MSM_PREP_NOSYNC ? 0 : timeout_to_jiffies(timeout);
long ret;
 
-   ret = reservation_object_wait_timeout_rcu(msm_obj->resv, write,
+   ret = reservation_object_wait_timeout_rcu(obj->resv, write,
  true,  remain);
if (ret == 0)
return remain == 0 ? -EBUSY : 

[PATCH 0/5] Add reservation_object to drm_gem_object

[Rob Herring]

This series implements the todo to add reservation_object to 
drm_gem_object. I converted the easy drivers, but not Intel or AMD. The 
series is build tested only.

Rob

Rob Herring (5):
  drm: Add reservation_object to drm_gem_object
  drm: etnaviv: Switch to use drm_gem_object reservation_object
  drm: msm: Switch to use drm_gem_object reservation_object
  drm: v3d: Switch to use drm_gem_object reservation_object
  drm: vc4: Switch to use drm_gem_object reservation_object

 Documentation/gpu/todo.rst   |  9 -
 drivers/gpu/drm/drm_gem.c| 39 
 drivers/gpu/drm/drm_prime.c  |  1 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c|  1 -
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|  1 -
 drivers/gpu/drm/etnaviv/etnaviv_gem.c| 16 +++-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h|  4 --
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c  |  7 
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 22 +--
 drivers/gpu/drm/msm/msm_drv.c|  1 -
 drivers/gpu/drm/msm/msm_drv.h|  1 -
 drivers/gpu/drm/msm/msm_gem.c| 27 +-
 drivers/gpu/drm/msm/msm_gem_prime.c  |  7 
 drivers/gpu/drm/msm/msm_gem_submit.c |  8 ++--
 drivers/gpu/drm/v3d/v3d_bo.c | 14 +--
 drivers/gpu/drm/v3d/v3d_drv.c|  1 -
 drivers/gpu/drm/v3d/v3d_drv.h|  5 ---
 drivers/gpu/drm/v3d/v3d_gem.c| 35 +-
 drivers/gpu/drm/vc4/vc4_bo.c | 15 +---
 drivers/gpu/drm/vc4/vc4_drv.c|  1 -
 drivers/gpu/drm/vc4/vc4_drv.h|  7 +---
 drivers/gpu/drm/vc4/vc4_gem.c| 18 -
 drivers/gpu/drm/vc4/vc4_plane.c  |  2 +-
 include/drm/drm_gem.h|  7 
 24 files changed, 98 insertions(+), 151 deletions(-)

-- 
2.19.1

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

[PATCH 2/5] drm: etnaviv: Switch to use drm_gem_object reservation_object

[Rob Herring]

Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.

Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: etna...@lists.freedesktop.org
Signed-off-by: Rob Herring 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c|  1 -
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|  1 -
 drivers/gpu/drm/etnaviv/etnaviv_gem.c| 16 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h|  4 
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c  |  7 ---
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 22 ++--
 6 files changed, 16 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 18c27f795cf6..9f42f7538236 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -473,7 +473,6 @@ static struct drm_driver etnaviv_drm_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export   = drm_gem_prime_export,
.gem_prime_import   = drm_gem_prime_import,
-   .gem_prime_res_obj  = etnaviv_gem_prime_res_obj,
.gem_prime_pin  = etnaviv_gem_prime_pin,
.gem_prime_unpin= etnaviv_gem_prime_unpin,
.gem_prime_get_sg_table = etnaviv_gem_prime_get_sg_table,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 4bf698de5996..351db0c5822d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -61,7 +61,6 @@ void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
 void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
   struct vm_area_struct *vma);
-struct reservation_object *etnaviv_gem_prime_res_obj(struct drm_gem_object 
*obj);
 struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device 
*dev,
struct dma_buf_attachment *attach, struct sg_table *sg);
 int etnaviv_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 1fa74226db91..3e954adcb2cc 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -397,13 +397,13 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 
op,
}
 
if (op & ETNA_PREP_NOSYNC) {
-   if (!reservation_object_test_signaled_rcu(etnaviv_obj->resv,
+   if (!reservation_object_test_signaled_rcu(obj->resv,
  write))
return -EBUSY;
} else {
unsigned long remain = etnaviv_timeout_to_jiffies(timeout);
 
-   ret = reservation_object_wait_timeout_rcu(etnaviv_obj->resv,
+   ret = reservation_object_wait_timeout_rcu(obj->resv,
  write, true, remain);
if (ret <= 0)
return ret == 0 ? -ETIMEDOUT : ret;
@@ -459,7 +459,7 @@ static void etnaviv_gem_describe_fence(struct dma_fence 
*fence,
 static void etnaviv_gem_describe(struct drm_gem_object *obj, struct seq_file 
*m)
 {
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
-   struct reservation_object *robj = etnaviv_obj->resv;
+   struct reservation_object *robj = obj->resv;
struct reservation_object_list *fobj;
struct dma_fence *fence;
unsigned long off = drm_vma_node_start(&obj->vma_node);
@@ -549,8 +549,6 @@ void etnaviv_gem_free_object(struct drm_gem_object *obj)
 
drm_gem_free_mmap_offset(obj);
etnaviv_obj->ops->release(etnaviv_obj);
-   if (etnaviv_obj->resv == &etnaviv_obj->_resv)
-   reservation_object_fini(&etnaviv_obj->_resv);
drm_gem_object_release(obj);
 
kfree(etnaviv_obj);
@@ -596,12 +594,8 @@ static int etnaviv_gem_new_impl(struct drm_device *dev, 
u32 size, u32 flags,
 
etnaviv_obj->flags = flags;
etnaviv_obj->ops = ops;
-   if (robj) {
-   etnaviv_obj->resv = robj;
-   } else {
-   etnaviv_obj->resv = &etnaviv_obj->_resv;
-   reservation_object_init(&etnaviv_obj->_resv);
-   }
+   if (robj)
+   etnaviv_obj->base.resv = robj;
 
mutex_init(&etnaviv_obj->lock);
INIT_LIST_HEAD(&etnaviv_obj->vram_list);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index 76079c2291f8..7015837ccc1c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -47,10 +47,6 @@ struct etnaviv_gem_object {
struct sg_table *sgt;
void *vaddr;
 
-   /* normally (resv == &_resv) except for imported bo's */
-   struct reservation_object *resv;
-   struct reservation_object _resv;
-

linux-next: Fixes tags need some work in the drm tree

[Stephen Rothwell]

Hi all,

In commit

  a93587b31e34 ("drm/amd/display: Only get the connector state for VRR when 
toggled")

Fixes tag

  Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR 
properties")

has these problem(s):

  - Target SHA1 does not exist

Maybe instead:

  FIxes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR 
properties")

In commit

  32e61361b82e ("drm/amd/display: Fix 64-bit division for 32-bit builds")

Fixes tag

  Fixes: 
https://lists.freedesktop.org/archives/dri-devel/2018-December/201008.html

has these problem(s):

  - No SHA1 recognised

Maybe instead:

  Fixes: 80604e27bc9 ("drm/amd/display: Use 100 Hz precision for pipe pixel 
clocks")

In commit

  c4312c27c826 ("drm/amdgpu: Cleanup 2 compiler warnings")

Fixes tag

  Fixes: e4ae0fc drm/amdgpu: implement gfx8 post_soft_reset

has these problem(s):

  - SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").

Fixes tag

  Fixes: 5e01c09 drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq rings

has these problem(s):

  - Target SHA1 does not exist

Maybe instead:

  Fixes: c6064de4b734 ("drm/amdgpu/gfx_v8_0: Reorder the gfx, kiq and kcq rings 
test sequence")

-- 
Cheers,
Stephen Rothwell


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

[PATCH v5 2/3] drm/i915/gen9+: Add support for pipe background color (v5)

[Matt Roper]

Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes.  Let's expose this for use by
compositors.

v2:
 - Split out bgcolor sanitization and programming of csc/gamma bits to a
   separate patch that we can land before the ABI changes are ready to
   go in.  (Ville)
 - Change a temporary variable name to be more consistent with
   other similar functions.  (Ville)
 - Change register name to SKL_CANVAS for consistency with the
   CHV_CANVAS register.

v3:
 - Switch register name back to SKL_BOTTOM_COLOR.  (Ville)
 - Use non-_FW register write.  (Ville)
 - Minor parameter rename for consistency.  (Ville)

v4:
 - Removed use of bgcolor_changed flag.

v5:
 - s/uint64_t/u64/

Cc: dri-devel@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  9 +++
 drivers/gpu/drm/i915/intel_display.c | 46 +++-
 2 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index fa2c226fc779..e96fef9fa97c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3092,6 +3092,15 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
intel_plane_info(m, crtc);
}
 
+   if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
+   u64 background = pipe_config->base.bgcolor;
+
+   seq_printf(m, "\tbackground color (10bpc): r=%x g=%x 
b=%x\n",
+  DRM_ARGB_RED(background, 10),
+  DRM_ARGB_GREEN(background, 10),
+  DRM_ARGB_BLUE(background, 10));
+   }
+
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
   yesno(!crtc->cpu_fifo_underrun_disabled),
   yesno(!crtc->pch_fifo_underrun_disabled));
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a6d8985fe2e0..469480fe01a4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3896,6 +3896,28 @@ void intel_finish_reset(struct drm_i915_private 
*dev_priv)
clear_bit(I915_RESET_MODESET, &dev_priv->gpu_error.flags);
 }
 
+static void
+skl_update_background_color(const struct intel_crtc_state *crtc_state)
+{
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   u64 propval = crtc_state->base.bgcolor;
+   u32 tmp;
+
+   /* Hardware is programmed with 10 bits of precision */
+   tmp = DRM_ARGB_RED(propval, 10) << 20
+   | DRM_ARGB_GREEN(propval, 10) << 10
+   | DRM_ARGB_BLUE(propval, 10);
+
+   /*
+* Set CSC and gamma for bottom color to ensure background pixels
+* receive the same color transformations as plane content.
+*/
+   tmp |= SKL_BOTTOM_COLOR_CSC_ENABLE | SKL_BOTTOM_COLOR_GAMMA_ENABLE;
+
+   I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe), tmp);
+}
+
 static void intel_update_pipe_config(const struct intel_crtc_state 
*old_crtc_state,
 const struct intel_crtc_state 
*new_crtc_state)
 {
@@ -3931,15 +3953,8 @@ static void intel_update_pipe_config(const struct 
intel_crtc_state *old_crtc_sta
ironlake_pfit_disable(old_crtc_state);
}
 
-   /*
-* We don't (yet) allow userspace to control the pipe background color,
-* so force it to black, but apply pipe gamma and CSC so that its
-* handling will match how we program our planes.
-*/
if (INTEL_GEN(dev_priv) >= 9)
-   I915_WRITE(SKL_BOTTOM_COLOR(crtc->pipe),
-  SKL_BOTTOM_COLOR_GAMMA_ENABLE |
-  SKL_BOTTOM_COLOR_CSC_ENABLE);
+   skl_update_background_color(new_crtc_state);
 }
 
 static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -11042,6 +11057,8 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
+   struct drm_crtc_state *old_crtc_state =
+   drm_atomic_get_old_crtc_state(crtc_state->state, crtc);
int ret;
bool mode_changed = needs_modeset(crtc_state);
 
@@ -11069,6 +11086,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
crtc_state->planes_changed = true;
}
 
+   if (crtc_state->bgcolor != old_crtc_state->bgcolor)
+   pipe_config->update_pipe = true;
+
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_p

[PATCH v5 1/3] drm: Add CRTC background color property (v5)

[Matt Roper]

Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes).  Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.

To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value.  Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.

v2:
 - Swap internal representation's blue and red bits to make it easier
   to read if printed out.  (Ville)
 - Document bgcolor property in drm_blend.c.  (Sean Paul)
 - s/background_color/bgcolor/ for consistency between property name and
   value storage field.  (Sean Paul)
 - Add a convenience function to attach property to a given crtc.

v3:
 - Restructure ARGB component extraction macros to be easier to
   understand and enclose the parameters in () to avoid calculations
   if expressions are passed.  (Sean Paul)
 - s/rgba/argb/ in helper function/macro names.  Even though the idea is
   to not worry about the internal representation of the u64, it can
   still be confusing to look at code that uses 'rgba' terminology, but
   stores values with argb ordering.  (Ville)

v4:
 - Drop the bgcolor_changed flag.  (Ville, Brian Starkey)
 - Clarify in kerneldoc that background color is expected to undergo the
   same pipe-level degamma/csc/gamma transformations that planes do.
   (Brian Starkey)
 - Update kerneldoc to indicate non-opaque colors are allowed, but are
   generally only useful in special cases such as when writeback
   connectors are used (Brian Starkey / Eric Anholt)

v5:
 - Set crtc->state->bgcolor to solid black inside
   drm_crtc_add_bgcolor_property() in case drivers don't do this
   themselves.  (Ville)
 - Add kerneldoc to drm_crtc_add_bgcolor_property() function.

Cc: dri-devel@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä 
Cc: Sean Paul 
Cc: Brian Starkey 
Cc: Eric Anholt 
Cc: Stéphane Marchesin 
Cc: Daniel Vetter 
Signed-off-by: Matt Roper 
Reviewed-by(v2): Sean Paul 
Reviewed-by: Brian Starkey 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  4 
 drivers/gpu/drm/drm_blend.c   | 41 ---
 drivers/gpu/drm/drm_mode_config.c |  6 ++
 include/drm/drm_blend.h   |  1 +
 include/drm/drm_crtc.h| 12 
 include/drm/drm_mode_config.h |  5 +
 include/uapi/drm/drm_mode.h   | 28 ++
 7 files changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41adfc67..d569e20e34e3 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
return -EFAULT;
 
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+   } else if (property == config->bgcolor_property) {
+   state->bgcolor = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
} else {
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+   else if (property == config->bgcolor_property)
+   *val = state->bgcolor;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 0c78ca386cbe..2ff69fae385c 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -175,9 +175,22 @@
  *  plane does not expose the "alpha" property, then this is
  *  assumed to be 1.0
  *
- * Note that all the property extensions described here apply either to the
- * plane or the CRTC (e.g. for the background color, which currently is not
- * exposed and assumed to be black).
+ * The property extensions described above all apply to the plane.  Drivers
+ * may also expose the following crtc property extension:
+ *
+ * BACKGROUND_COLOR:
+ * Background color is setup with drm_crtc_add_bgcolor_property().  It
+ * controls the ARGB color of a full-screen layer that exists below all
+ * planes.  This color will be used for pixels not covered by any plane
+ * and may also be blended with plane contents as allowed by a plane's
+ * alpha values.  The background color defaults to black, and is assumed
+ * to be black for drivers that

[Bug 109526] [CARRIZO] amdgpu fails to resume from S3, atombios stuck executing C554 (len 629, WS 0, PS 0)

[bugzilla-daemon]

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

Bug ID: 109526
   Summary: [CARRIZO] amdgpu fails to resume from S3, atombios
stuck executing C554 (len 629, WS 0, PS 0)
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: johannes.hi...@datenkhaos.de

there is already a similar report at kernel bugzilla, but nobody took notice:
https://bugzilla.kernel.org/show_bug.cgi?id=190971

It's a kernel bug, first seen with linux-4.20 on my Carrizo. I don't have a
testcase for reproducing, so it's hard to bisect. Sometimes it happens multiple
times a day, with every suspend-resume cycle. Sometimes the machine works for
several days with at least two suspend-resume-cycles per day.

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

2019 X.Org Board of Directors Elections Nomination period is NOW

[Wentland, Harry]

We are seeking nominations for candidates for election to the X.Org Foundation 
Board of Directors. All X.Org Foundation members are eligible for election to 
the board.

Nominations for the 2019 election are now open and will remain open until 23:59 
UTC on 14 February 2019.

The Board consists of directors elected from the membership. Each year, an 
election is held to bring the total number of directors to eight. The four 
members receiving the highest vote totals will serve as directors for two year 
terms.

The directors who received two year terms starting in 2018 were Keith Packard, 
Bryce Harrington, Eric Anholt, and Harry Wentland. They will continue to serve 
until their term ends in 2020. Current directors whose term expires in 2019 are 
Rob Clark, Martin Peres, Taylor Campbell and Daniel Vetter.

A director is expected to participate in the fortnightly IRC meeting to discuss 
current business and to attend the annual meeting of the X.Org Foundation, 
which will be held at a location determined in advance by the Board of 
Directors.

A member may nominate themselves or any other member they feel is qualified. 
Nominations should be sent to the Election Committee at elections at x.org.

Nominees shall be required to be current members of the X.Org Foundation, and 
submit a personal statement of up to 200 words that will be provided to 
prospective voters. The collected statements, along with the statement of 
contribution to the X.Org Foundation in the member's account page on 
http://members.x.org, will be made available to all voters to help them make 
their voting decisions.

Nominations, membership applications or renewals and completed personal 
statements must be received no later than 23:59 UTC on 14 February 2019.

The slate of candidates will be published 21 February 2019 and candidate Q&A 
will begin then. The deadline for Xorg membership applications and renewals is 
21 February 2019.

Cheers, Harry Wentland, on behalf of the X.Org BoD




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

Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

[Thierry Reding]

On Thu, Jan 31, 2019 at 10:03:12PM +0100, Sam Ravnborg wrote:
> Hi Sean.
> 
> > Hey Sam,
> > Thanks for the patchset, this will make dmesg grepping easier! One comment, 
> > and
> > you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
> > 
> > When I introduced DRM_DEV, it was to cover the case where there are multiple
> > instances of the same driver (ie: dual-channel mipi, multiple crtcs, etc). I
> > suppose that _could_ happen in the panel space, but it seems more unlikely 
> > than
> > not.
> 
> The rationale for using DRM_DEV* are solely that if a struct device * is 
> avalible,
> then we can use this to provide more information about the origin of the 
> logging.
> 
> I have not testet it - but from browsing the code I could not see that
> DRM_ERROR and friends picked up the module name.
> If DRM_ERROR is the right choice I will redo the patches - no problem.
> 
> But if we loose the module name then the DRM_DEV* variants are preferable IMO.

I personally like the DRM_DEV_* variants better because of the
additional information that they provide. That can be useful when
grepping logs etc.

I'm slightly on the fence about this patch. The unwritten, and
admittedly fuzzy, rules that I've been using so far are that dev_*() are
used or messages that have to do with the panel device itself, whereas
DRM_* variants are used for things that are actually related to DRM. So
typically this would mean that roughly everything in ->probe() or
->remove() would be dev_*(), while the rest would be DRM_DEV_*().

The reason for this is that during most of ->probe() there's not really
any connection to DRM. In many cases the DRM device doesn't even exist
yet. Consider component/master setups where some display component will
wait for the panel to be registered before binding the master. So I find
it confusing to have the DRM style messages when there's actually no DRM
going on yet.

That said, I understand that this might not be an immediately obvious
rule and it might not be followed rigorously, which both quite possibly
contribute to the perception that the messages are all inconsistent. It
always made sense to me, but if everyone else thinks that it's totally
nuts, I'm sure I can find a way to get over it.

Thierry


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

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

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

--- Comment #7 from grak...@gmail.com ---
Can confirm that removing raven_dmcu.bin allows amdgpu to load.  Note that
kernel 4.20 also requires iommu=pt kernel option.

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

Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

[Sam Ravnborg]

Hi Sean.

> Hey Sam,
> Thanks for the patchset, this will make dmesg grepping easier! One comment, 
> and
> you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
> 
> When I introduced DRM_DEV, it was to cover the case where there are multiple
> instances of the same driver (ie: dual-channel mipi, multiple crtcs, etc). I
> suppose that _could_ happen in the panel space, but it seems more unlikely 
> than
> not.

The rationale for using DRM_DEV* are solely that if a struct device * is 
avalible,
then we can use this to provide more information about the origin of the 
logging.

I have not testet it - but from browsing the code I could not see that
DRM_ERROR and friends picked up the module name.
If DRM_ERROR is the right choice I will redo the patches - no problem.

But if we loose the module name then the DRM_DEV* variants are preferable IMO.

Note: I missed DRM_DEV_WARN(), so I left one dev_warn() in the code.

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

[Bug 109524] "Invalid glsl version in shading_language_version()" when trying to run directX games using wine

[bugzilla-daemon]

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

Bug ID: 109524
   Summary: "Invalid glsl version in shading_language_version()"
when trying to run directX games using wine
   Product: Mesa
   Version: 18.2
  Hardware: x86 (IA32)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R100
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: laszlo.erd...@freenet.de
QA Contact: dri-devel@lists.freedesktop.org

When I try running any software in wine that uses direct3D, I get the following
message and an app crash:

Mesa 18.2.8 implementation error: Invalid GLSL version in
shading_language_version()
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
wine: Unhandled page fault on read access to 0x at address 0xb7bf1440
(thread 0009), starting debugger...

I'm using an R100 GPU. The problem wasn't present in some earlier versions of
Mesa, I believe it still worked in some 17.x version.

-- 
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 0/9] mmu notifier provide context informations

[Jerome Glisse]

On Thu, Jan 31, 2019 at 11:55:35AM -0800, Andrew Morton wrote:
> On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse  wrote:
> 
> > Andrew what is your plan for this ? I had a discussion with Peter Xu
> > and Andrea about change_pte() and kvm. Today the change_pte() kvm
> > optimization is effectively disabled because of invalidate_range
> > calls. With a minimal couple lines patch on top of this patchset
> > we can bring back the kvm change_pte optimization and we can also
> > optimize some other cases like for instance when write protecting
> > after fork (but i am not sure this is something qemu does often so
> > it might not help for real kvm workload).
> > 
> > I will be posting a the extra patch as an RFC, but in the meantime
> > i wanted to know what was the status for this.
> 
> The various drm patches appear to be headed for collisions with drm
> tree development so we'll need to figure out how to handle that and in
> what order things happen.
> 
> It's quite unclear from the v4 patchset's changelogs that this has
> anything to do with KVM and "the change_pte() kvm optimization" hasn't
> been described anywhere(?).
> 
> So..  I expect the thing to do here is to get everything finished, get
> the changelogs completed with this new information and do a resend.
> 
> Can we omit the drm and rdma patches for now?  Feed them in via the
> subsystem maintainers when the dust has settled?

Yes, i should have pointed out that you can ignore the driver patches
i will resumit them through the appropriate tree once the mm bits are
in. I just wanted to show case how i intended to use this. I will try
not to forget next time to clearly tag things that are just there to
show case and that will be merge latter through different tree.

I will do a v5 with kvm bits once we have enough testing and confidence.
So i guess this all will be delayed to 5.2 and 5.3 for driver bits.
The kvm bits are outcomes of private emails and previous face to face
discussion around mmu notifier and kvm. I believe the context information
will turn to be useful to more users than the ones i am doing it for.

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdkfd: Fix if preprocessor statement above kfd_fill_iolink_info_for_cpu

[Kuehling, Felix]

Thank you, Nathan. I applied your patch to amd-staging-drm-next.

Sorry for the late response. I'm catching up with my email backlog after 
a vacation.

Regards,
   Felix

On 2019-01-21 6:52 p.m., Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:866:5: warning:
> 'CONFIG_X86_64' is not defined, evaluates to 0 [-Wundef]
> #if CONFIG_X86_64
>  ^
> 1 warning generated.
>
> Fixes: d1c234e2cd10 ("drm/amdkfd: Allow building KFD on ARM64 (v2)")
> Signed-off-by: Nathan Chancellor 
> ---
>
> Resending as I forgot to add the lists...
>
>   drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> index 5d85ff341385..2e7c44955f43 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> @@ -863,7 +863,7 @@ static int kfd_fill_mem_info_for_cpu(int numa_node_id, 
> int *avail_size,
>   return 0;
>   }
>   
> -#if CONFIG_X86_64
> +#ifdef CONFIG_X86_64
>   static int kfd_fill_iolink_info_for_cpu(int numa_node_id, int *avail_size,
>   uint32_t *num_entries,
>   struct crat_subtype_iolink *sub_type_hdr)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

[Sean Paul]

On Thu, Jan 31, 2019 at 08:26:00PM +0100, Sam Ravnborg wrote:
> Hi Thierry et al.
> 
> While reviewing a number of new panel drivers there was a
> certain pattern in the feedback:
> - the now deprecated drmP.h file was used
> - dev_err() and friends was used
> 
> This patch-set address the above items in the panel
> drivers in drm/panel/
> The hope is that new panel drivers will no longer inherit bad
> patterns from the existing drivers.
> 
> The use of DRM_DEV* is not accepted by everyone, so this conversion
> was split up in smaller bits.
> If some drivers do not want to use DRM_DEV* then just drop the relevant patch.
> 
> All patches are build tested on x86/arm.
> 
> The DRM_DEV* patches depends on the drmP.h removal.
> 
> One extra patch sneaked in "panel-innolux: drop unused variable"
> This is a fix for an unused variable and was added to flush my panel patches.
> 
> Note: Waiting for key storage (for gpg key) before I start the process getting
> commit rights, so I rely on someone else (Thierry?) to commit this.
> 
> Patches are made on top of drm-misc-next as of a few days ago.
> 
> Comments welcome!

Hey Sam,
Thanks for the patchset, this will make dmesg grepping easier! One comment, and
you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?

When I introduced DRM_DEV, it was to cover the case where there are multiple
instances of the same driver (ie: dual-channel mipi, multiple crtcs, etc). I
suppose that _could_ happen in the panel space, but it seems more unlikely than
not.

It's quite possible I'm overthinking this, but just something I figured I would
point out. Either way, I think this is an improvement over dev_*.

Sean

> 
>   Sam
> 
> Sam Ravnborg (19):
>   drm/panel: drop drmP.h usage
>   drm/panel: panel-innolux: drop unused variable
>   drm/panel: samsung: use DRM_DEV*
>   drm/panel: arm-versatile: use DRM_DEV*
>   drm/panel: truly: use DRM_DEV*
>   drm/panel: sitronix: use DRM_DEV*
>   drm/panel: ilitek: use DRM_DEV*
>   drm/panel: innolux: use DRM_DEV*
>   drm/panel: jdi: use DRM_DEV*
>   drm/panel: lg: use DRM_DEV*
>   drm/panel: lvds: use DRM_DEV*
>   drm/panel: olimex: use DRM_DEV*
>   drm/panel: orisetech: use DRM_DEV*
>   drm/panel: panasonic: use DRM_DEV*
>   drm/panel: raspberrypi: use DRM_DEV*
>   drm/panel: raydium: use DRM_DEV*
>   drm/panel: seiko: use DRM_DEV*
>   drm/panel: sharp: use DRM_DEV*
>   drm/panel: simple: use DRM_DEV*
> 
>  drivers/gpu/drm/panel/panel-arm-versatile.c| 21 +++--
>  drivers/gpu/drm/panel/panel-ilitek-ili9322.c   | 97 
> --
>  drivers/gpu/drm/panel/panel-ilitek-ili9881c.c  | 14 ++--
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c  | 17 ++--
>  drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 66 ---
>  drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c |  4 +-
>  drivers/gpu/drm/panel/panel-lg-lg4573.c| 25 +++---
>  drivers/gpu/drm/panel/panel-lvds.c | 39 +
>  drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 28 ---
>  drivers/gpu/drm/panel/panel-orisetech-otm8009a.c   | 15 ++--
>  .../gpu/drm/panel/panel-panasonic-vvx10f034n00.c   | 19 +++--
>  .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  | 25 +++---
>  drivers/gpu/drm/panel/panel-raydium-rm68200.c  | 11 ++-
>  drivers/gpu/drm/panel/panel-samsung-ld9040.c   | 18 ++--
>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 21 +++--
>  drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 15 ++--
>  drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c  | 32 ---
>  drivers/gpu/drm/panel/panel-seiko-43wvf1g.c| 18 ++--
>  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c| 66 ++-
>  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c| 27 +++---
>  drivers/gpu/drm/panel/panel-simple.c   | 22 +++--
>  drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 16 ++--
>  drivers/gpu/drm/panel/panel-truly-nt35597.c| 10 ++-
>  23 files changed, 375 insertions(+), 251 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/9] mmu notifier provide context informations

[Andrew Morton]

On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse  wrote:

> Andrew what is your plan for this ? I had a discussion with Peter Xu
> and Andrea about change_pte() and kvm. Today the change_pte() kvm
> optimization is effectively disabled because of invalidate_range
> calls. With a minimal couple lines patch on top of this patchset
> we can bring back the kvm change_pte optimization and we can also
> optimize some other cases like for instance when write protecting
> after fork (but i am not sure this is something qemu does often so
> it might not help for real kvm workload).
> 
> I will be posting a the extra patch as an RFC, but in the meantime
> i wanted to know what was the status for this.

The various drm patches appear to be headed for collisions with drm
tree development so we'll need to figure out how to handle that and in
what order things happen.

It's quite unclear from the v4 patchset's changelogs that this has
anything to do with KVM and "the change_pte() kvm optimization" hasn't
been described anywhere(?).

So..  I expect the thing to do here is to get everything finished, get
the changelogs completed with this new information and do a resend.

Can we omit the drm and rdma patches for now?  Feed them in via the
subsystem maintainers when the dust has settled?

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

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Jerome Glisse]

On Thu, Jan 31, 2019 at 07:02:15PM +, Jason Gunthorpe wrote:
> On Thu, Jan 31, 2019 at 09:13:55AM +0100, Christoph Hellwig wrote:
> > On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote:
> > > > *shrug* so what if the special GUP called a VMA op instead of
> > > > traversing the VMA PTEs today? Why does it really matter? It could
> > > > easily change to a struct page flow tomorrow..
> > > 
> > > Well it's so that it's composable. We want the SGL->DMA side to work for
> > > APIs from kernel space and not have to run a completely different flow
> > > for kernel drivers than from userspace memory.
> > 
> > Yes, I think that is the important point.
> > 
> > All the other struct page discussion is not about anyone of us wanting
> > struct page - heck it is a pain to deal with, but then again it is
> > there for a reason.
> > 
> > In the typical GUP flows we have three uses of a struct page:
> > 
> >  (1) to carry a physical address.  This is mostly through
> >  struct scatterlist and struct bio_vec.  We could just store
> >  a magic PFN-like value that encodes the physical address
> >  and allow looking up a page if it exists, and we had at least
> >  two attempts at it.  In some way I think that would actually
> >  make the interfaces cleaner, but Linus has NACKed it in the
> >  past, so we'll have to convince him first that this is the
> >  way forward
> 
> Something like this (and more) has always been the roadblock with
> trying to mix BAR memory into SGL. I think it is such a big problem as
> to be unsolvable in one step.. 
> 
> Struct page doesn't even really help anything beyond dma_map as we
> still can't pretend that __iomem is normal memory for general SGL
> users.
> 
> >  (2) to keep a reference to the memory so that it doesn't go away
> >  under us due to swapping, process exit, unmapping, etc.
> >  No idea how we want to solve this, but I guess you have
> >  some smart ideas?
> 
> Jerome, how does this work anyhow? Did you do something to make the
> VMA lifetime match the p2p_map/unmap? Or can we get into a situation
> were the VMA is destroyed and the importing driver can't call the
> unmap anymore?
> 
> I know in the case of notifiers the VMA liftime should be strictly
> longer than the map/unmap - but does this mean we can never support
> non-notifier users via this scheme?

So in this version the requirement is that the importer also have a mmu
notifier registered and that's what all GPU driver do already. Any
driver that map some range of vma to a device should register itself as
a mmu notifier listener to do something when vma goes away. I posted a
patchset a while ago to allow listener to differentiate when the vma is
going away from other type of invalidation [1]

With that in place you can easily handle the pin case. Driver really
need to do something when the vma goes away with GUP or not. As the
device is then writing/reading to/from something that does not match
anything in the process address space.

So user that want pin would register notifier, call p2p_map with pin
flag and ignore all notifier callback except the unmap one when the
unmap one happens they have the vma and they should call p2p_unmap
from their invalidate callback and update their device to either some
dummy memory or program it in a way that the userspace application
will notice.

This can all be handled by some helper so that driver do not have to
write more than 5 lines of code and function to update their device
mapping to something of their choosing.


> 
> >  (3) to make the PTEs dirty after writing to them.  Again no sure
> >  what our preferred interface here would be
> 
> This need doesn't really apply to BAR memory..
> 
> > If we solve all of the above problems I'd be more than happy to
> > go with a non-struct page based interface for BAR P2P.  But we'll
> > have to solve these issues in a generic way first.
> 
> I still think the right direction is to build on what Logan has done -
> realize that he created a DMA-only SGL - make that a formal type of
> the kernel and provide the right set of APIs to work with this type,
> without being forced to expose struct page.
> 
> Basically invert the API flow - the DMA map would be done close to
> GUP, not buried in the driver. This absolutely doesn't work for every
> flow we have, but it does enable the ones that people seem to care
> about when talking about P2P.

This does not work for GPU really i do not want to have to rewrite GPU
driver for this. Struct page is a burden and it does not bring anything
to the table. I rather provide an all in one stop for driver to use
this without having to worry between regular vma and special vma.

Note that in this patchset i reuse chunk of Logan works and intention is
to also allow PCI struct page to work too. But they should not be the
only mechanisms.

> 
> To get to where we are today we'd need a few new IB APIs, and some
> nvme change to work with DMA-only SGL'

Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

[Sam Ravnborg]

Hi all.

On Thu, Jan 31, 2019 at 08:26:00PM +0100, Sam Ravnborg wrote:
> Hi Thierry et al.
> 
> While reviewing a number of new panel drivers there was a
> certain pattern in the feedback:
> - the now deprecated drmP.h file was used
> - dev_err() and friends was used
> 
> This patch-set address the above items in the panel
> drivers in drm/panel/
> The hope is that new panel drivers will no longer inherit bad
> patterns from the existing drivers.
> 
> The use of DRM_DEV* is not accepted by everyone, so this conversion
> was split up in smaller bits.
> If some drivers do not want to use DRM_DEV* then just drop the relevant patch.
> 
> All patches are build tested on x86/arm.
> 
> The DRM_DEV* patches depends on the drmP.h removal.
> 
> One extra patch sneaked in "panel-innolux: drop unused variable"
> This is a fix for an unused variable and was added to flush my panel patches.
> 
> Note: Waiting for key storage (for gpg key) before I start the process getting
> commit rights, so I rely on someone else (Thierry?) to commit this.
> 
> Patches are made on top of drm-misc-next as of a few days ago.
Just for the record, all patches are checkpatched - OK.
A lot of the DRM_DEV_ERROR() etc lines had to be linewrapped to avoid
the maximum linelength.

The conversion was done manually, no fancy coincielle script behind.
That's something to look into for future changes.

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

[PATCH v1 15/19] drm/panel: raspberrypi: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
index 28c0620dfe0f..c9013faff9ed 100644
--- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define RPI_DSI_DRIVER_NAME "rpi-ts-dsi"
 
@@ -232,7 +233,7 @@ static void rpi_touchscreen_i2c_write(struct 
rpi_touchscreen *ts,
 
ret = i2c_smbus_write_byte_data(ts->i2c, reg, val);
if (ret)
-   dev_err(&ts->dsi->dev, "I2C write failed: %d\n", ret);
+   DRM_DEV_ERROR(&ts->dsi->dev, "I2C write failed: %d\n", ret);
 }
 
 static int rpi_touchscreen_write(struct rpi_touchscreen *ts, u16 reg, u32 val)
@@ -324,8 +325,9 @@ static int rpi_touchscreen_get_modes(struct drm_panel 
*panel)
 
mode = drm_mode_duplicate(drm, m);
if (!mode) {
-   dev_err(drm->dev, "failed to add mode %ux%u@%u\n",
-   m->hdisplay, m->vdisplay, m->vrefresh);
+   DRM_DEV_ERROR(drm->dev,
+ "failed to add mode %ux%u@%u\n",
+ m->hdisplay, m->vdisplay, m->vrefresh);
continue;
}
 
@@ -381,7 +383,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
 
ver = rpi_touchscreen_i2c_read(ts, REG_ID);
if (ver < 0) {
-   dev_err(dev, "Atmel I2C read failed: %d\n", ver);
+   DRM_DEV_ERROR(dev, "Atmel I2C read failed: %d\n", ver);
return -ENODEV;
}
 
@@ -390,7 +392,9 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
case 0xc3: /* ver 2 */
break;
default:
-   dev_err(dev, "Unknown Atmel firmware revision: 0x%02x\n", ver);
+   DRM_DEV_ERROR(dev,
+ "Unknown Atmel firmware revision: 0x%02x\n",
+  ver);
return -ENODEV;
}
 
@@ -412,8 +416,9 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c,
 
ts->dsi = mipi_dsi_device_register_full(host, &info);
if (IS_ERR(ts->dsi)) {
-   dev_err(dev, "DSI device registration failed: %ld\n",
-   PTR_ERR(ts->dsi));
+   DRM_DEV_ERROR(dev,
+ "DSI device registration failed: %ld\n",
+ PTR_ERR(ts->dsi));
return PTR_ERR(ts->dsi);
}
 
@@ -457,7 +462,8 @@ static int rpi_touchscreen_dsi_probe(struct mipi_dsi_device 
*dsi)
ret = mipi_dsi_attach(dsi);
 
if (ret)
-   dev_err(&dsi->dev, "failed to attach dsi to host: %d\n", ret);
+   DRM_DEV_ERROR(&dsi->dev,
+ "failed to attach dsi to host: %d\n", ret);
 
return ret;
 }
-- 
2.12.0

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

[PATCH v1 16/19] drm/panel: raydium: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-raydium-rm68200.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c 
b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
index e05e3f950855..bbf3f51c8a3a 100644
--- a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
+++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
@@ -379,14 +379,14 @@ static int rm68200_probe(struct mipi_dsi_device *dsi)
ctx->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset_gpio)) {
ret = PTR_ERR(ctx->reset_gpio);
-   dev_err(dev, "cannot get reset GPIO: %d\n", ret);
+   DRM_DEV_ERROR(dev, "cannot get reset GPIO: %d\n", ret);
return ret;
}
 
ctx->supply = devm_regulator_get(dev, "power");
if (IS_ERR(ctx->supply)) {
ret = PTR_ERR(ctx->supply);
-   dev_err(dev, "cannot get regulator: %d\n", ret);
+   DRM_DEV_ERROR(dev, "cannot get regulator: %d\n", ret);
return ret;
}
 
@@ -411,7 +411,7 @@ static int rm68200_probe(struct mipi_dsi_device *dsi)
 
ret = mipi_dsi_attach(dsi);
if (ret < 0) {
-   dev_err(dev, "mipi_dsi_attach() failed: %d\n", ret);
+   DRM_DEV_ERROR(dev, "mipi_dsi_attach() failed: %d\n", ret);
drm_panel_remove(&ctx->panel);
return ret;
}
-- 
2.12.0

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

[PATCH v1 12/19] drm/panel: olimex: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Stefan Mavrodiev 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 26 +-
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c 
b/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
index c8704be9caa3..efb223b35594 100644
--- a/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
+++ b/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -157,10 +158,11 @@ static int lcd_olinuxino_get_modes(struct drm_panel 
*panel)
 
mode = drm_mode_create(drm);
if (!mode) {
-   dev_err(drm->dev, "failed to add mode %ux%u@%u\n",
-   lcd_mode->hactive,
-   lcd_mode->vactive,
-   lcd_mode->refresh);
+   DRM_DEV_ERROR(drm->dev,
+ "failed to add mode %ux%u@%u\n",
+ lcd_mode->hactive,
+ lcd_mode->vactive,
+ lcd_mode->refresh);
continue;
}
 
@@ -242,7 +244,8 @@ static int lcd_olinuxino_probe(struct i2c_client *client,
(u8 *)&lcd->eeprom + i);
mutex_unlock(&lcd->mutex);
if (ret < 0) {
-   dev_err(dev, "error reading from device at %02x\n", i);
+   DRM_DEV_ERROR(dev,
+ "error reading from device at %02x\n", i);
return ret;
}
}
@@ -250,20 +253,21 @@ static int lcd_olinuxino_probe(struct i2c_client *client,
/* Check configuration checksum */
checksum = ~crc32(~0, (u8 *)&lcd->eeprom, 252);
if (checksum != lcd->eeprom.checksum) {
-   dev_err(dev, "configuration checksum does not match!\n");
+   DRM_DEV_ERROR(dev,
+ "configuration checksum does not match!\n");
return -EINVAL;
}
 
/* Check magic header */
if (lcd->eeprom.header != LCD_OLINUXINO_HEADER_MAGIC) {
-   dev_err(dev, "magic header does not match\n");
+   DRM_DEV_ERROR(dev, "magic header does not match\n");
return -EINVAL;
}
 
-   dev_info(dev, "Detected %s, Rev. %s, Serial: %08x\n",
-lcd->eeprom.info.name,
-lcd->eeprom.revision,
-lcd->eeprom.serial);
+   DRM_DEV_INFO(dev, "Detected %s, Rev. %s, Serial: %08x\n",
+lcd->eeprom.info.name,
+lcd->eeprom.revision,
+lcd->eeprom.serial);
 
/*
 * The eeprom can hold up to 4 modes.
-- 
2.12.0

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

[PATCH v1 13/19] drm/panel: orisetech: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index 5bacf3f2da05..e7920ae018bd 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -431,14 +431,14 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
 
ctx->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset_gpio)) {
-   dev_err(dev, "cannot get reset-gpio\n");
+   DRM_DEV_ERROR(dev, "cannot get reset-gpio\n");
return PTR_ERR(ctx->reset_gpio);
}
 
ctx->supply = devm_regulator_get(dev, "power");
if (IS_ERR(ctx->supply)) {
ret = PTR_ERR(ctx->supply);
-   dev_err(dev, "failed to request regulator: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to request regulator: %d\n", ret);
return ret;
}
 
@@ -461,7 +461,7 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
 NULL);
if (IS_ERR(ctx->bl_dev)) {
ret = PTR_ERR(ctx->bl_dev);
-   dev_err(dev, "failed to register backlight: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to register backlight: %d\n", ret);
return ret;
}
 
@@ -474,7 +474,7 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
 
ret = mipi_dsi_attach(dsi);
if (ret < 0) {
-   dev_err(dev, "mipi_dsi_attach failed. Is host ready?\n");
+   DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?\n");
drm_panel_remove(&ctx->panel);
backlight_device_unregister(ctx->bl_dev);
return ret;
-- 
2.12.0

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

[PATCH v1 19/19] drm/panel: simple: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-simple.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 406b1d7aef31..a5d98a19f138 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -103,6 +104,7 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
 {
struct drm_connector *connector = panel->base.connector;
struct drm_device *drm = panel->base.drm;
+   struct device *dev = drm->dev;
struct drm_display_mode *mode;
unsigned int i, num = 0;
 
@@ -116,8 +118,8 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
videomode_from_timing(dt, &vm);
mode = drm_mode_create(drm);
if (!mode) {
-   dev_err(drm->dev, "failed to add mode %ux%u\n",
-   dt->hactive.typ, dt->vactive.typ);
+   DRM_DEV_ERROR(dev, "failed to add mode %ux%u\n",
+ dt->hactive.typ, dt->vactive.typ);
continue;
}
 
@@ -137,8 +139,8 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
 
mode = drm_mode_duplicate(drm, m);
if (!mode) {
-   dev_err(drm->dev, "failed to add mode %ux%u@%u\n",
-   m->hdisplay, m->vdisplay, m->vrefresh);
+   DRM_DEV_ERROR(dev, "failed to add mode %ux%u@%u\n",
+ m->hdisplay, m->vdisplay, m->vrefresh);
continue;
}
 
@@ -215,7 +217,8 @@ static int panel_simple_prepare(struct drm_panel *panel)
 
err = regulator_enable(p->supply);
if (err < 0) {
-   dev_err(panel->dev, "failed to enable supply: %d\n", err);
+   DRM_DEV_ERROR(panel->dev, "failed to enable supply: %d\n",
+ err);
return err;
}
 
@@ -325,7 +328,8 @@ static int panel_simple_probe(struct device *dev, const 
struct panel_desc *desc)
if (IS_ERR(panel->enable_gpio)) {
err = PTR_ERR(panel->enable_gpio);
if (err != -EPROBE_DEFER)
-   dev_err(dev, "failed to request GPIO: %d\n", err);
+   DRM_DEV_ERROR(dev, "failed to request GPIO: %d\n",
+ err);
return err;
}
 
@@ -3048,7 +3052,8 @@ static int panel_simple_dsi_remove(struct mipi_dsi_device 
*dsi)
 
err = mipi_dsi_detach(dsi);
if (err < 0)
-   dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", err);
+   DRM_DEV_ERROR(&dsi->dev,
+ "failed to detach from DSI host: %d\n", err);
 
return panel_simple_remove(&dsi->dev);
 }
-- 
2.12.0

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

[PATCH v1 06/19] drm/panel: sitronix: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c 
b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index 76bd6e7a1a60..f649fe5cc364 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -180,9 +181,10 @@ static int st7789v_get_modes(struct drm_panel *panel)
 
mode = drm_mode_duplicate(panel->drm, &default_mode);
if (!mode) {
-   dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   DRM_DEV_ERROR(panel->drm->dev,
+ "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
return -ENOMEM;
}
 
@@ -393,7 +395,7 @@ static int st7789v_probe(struct spi_device *spi)
 
ctx->reset = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset)) {
-   dev_err(&spi->dev, "Couldn't get our reset line\n");
+   DRM_DEV_ERROR(&spi->dev, "Couldn't get our reset line\n");
return PTR_ERR(ctx->reset);
}
 
-- 
2.12.0

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

[PATCH v1 10/19] drm/panel: lg: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-lg-lg4573.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-lg-lg4573.c 
b/drivers/gpu/drm/panel/panel-lg-lg4573.c
index e63fba2761f4..9bbf6dde6b7d 100644
--- a/drivers/gpu/drm/panel/panel-lg-lg4573.c
+++ b/drivers/gpu/drm/panel/panel-lg-lg4573.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -48,7 +49,7 @@ static int lg4573_spi_write_u16(struct lg4573 *ctx, u16 data)
u16 temp = cpu_to_be16(data);
struct spi_message msg;
 
-   dev_dbg(ctx->panel.dev, "writing data: %x\n", data);
+   DRM_DEV_DEBUG(ctx->panel.dev, "writing data: %x\n", data);
xfer.tx_buf = &temp;
spi_message_init(&msg);
spi_message_add_tail(&xfer, &msg);
@@ -115,7 +116,7 @@ static int lg4573_display_mode_settings(struct lg4573 *ctx)
0x7206, 0x720C, 0x7200, 0x7200,
};
 
-   dev_dbg(ctx->panel.dev, "transfer display mode settings\n");
+   DRM_DEV_DEBUG(ctx->panel.dev, "transfer display mode settings\n");
return lg4573_spi_write_u16_array(ctx, display_mode_settings,
  ARRAY_SIZE(display_mode_settings));
 }
@@ -131,7 +132,7 @@ static int lg4573_power_settings(struct lg4573 *ctx)
0x7263,
};
 
-   dev_dbg(ctx->panel.dev, "transfer power settings\n");
+   DRM_DEV_DEBUG(ctx->panel.dev, "transfer power settings\n");
return lg4573_spi_write_u16_array(ctx, power_settings,
  ARRAY_SIZE(power_settings));
 }
@@ -156,7 +157,7 @@ static int lg4573_gamma_settings(struct lg4573 *ctx)
0x7201, 0x7220, 0x7200, 0x7203,
};
 
-   dev_dbg(ctx->panel.dev, "transfer gamma settings\n");
+   DRM_DEV_DEBUG(ctx->panel.dev, "transfer gamma settings\n");
return lg4573_spi_write_u16_array(ctx, gamma_settings,
  ARRAY_SIZE(gamma_settings));
 }
@@ -165,7 +166,7 @@ static int lg4573_init(struct lg4573 *ctx)
 {
int ret;
 
-   dev_dbg(ctx->panel.dev, "initializing LCD\n");
+   DRM_DEV_DEBUG(ctx->panel.dev, "initializing LCD\n");
 
ret = lg4573_display_mode_settings(ctx);
if (ret)
@@ -219,9 +220,10 @@ static int lg4573_get_modes(struct drm_panel *panel)
 
mode = drm_mode_duplicate(panel->drm, &default_mode);
if (!mode) {
-   dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   DRM_DEV_ERROR(panel->drm->dev,
+ "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
return -ENOMEM;
}
 
@@ -258,7 +260,7 @@ static int lg4573_probe(struct spi_device *spi)
 
ret = spi_setup(spi);
if (ret < 0) {
-   dev_err(&spi->dev, "SPI setup failed: %d\n", ret);
+   DRM_DEV_ERROR(&spi->dev, "SPI setup failed: %d\n", ret);
return ret;
}
 
-- 
2.12.0

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

[PATCH v1 03/19] drm/panel: samsung: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-samsung-ld9040.c | 12 +--
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 15 +++---
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c |  8 
 drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 26 +---
 4 files changed, 32 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-ld9040.c 
b/drivers/gpu/drm/panel/panel-samsung-ld9040.c
index 7d27b79d0b2a..fec639c19d74 100644
--- a/drivers/gpu/drm/panel/panel-samsung-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-samsung-ld9040.c
@@ -149,7 +149,7 @@ static void ld9040_dcs_write(struct ld9040 *ctx, const u8 
*data, size_t len)
if (ctx->error < 0 || len == 0)
return;
 
-   dev_dbg(ctx->dev, "writing dcs seq: %*ph\n", (int)len, data);
+   DRM_DEV_DEBUG(ctx->dev, "writing dcs seq: %*ph\n", (int)len, data);
ret = ld9040_spi_write_word(ctx, *data);
 
while (!ret && --len) {
@@ -158,8 +158,8 @@ static void ld9040_dcs_write(struct ld9040 *ctx, const u8 
*data, size_t len)
}
 
if (ret) {
-   dev_err(ctx->dev, "error %d writing dcs seq: %*ph\n", ret,
-   (int)len, data);
+   DRM_DEV_ERROR(ctx->dev, "error %d writing dcs seq: %*ph\n",
+ ret, (int)len, data);
ctx->error = ret;
}
 
@@ -342,15 +342,15 @@ static int ld9040_probe(struct spi_device *spi)
 
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
-   dev_err(dev, "cannot get reset-gpios %ld\n",
-   PTR_ERR(ctx->reset_gpio));
+   DRM_DEV_ERROR(dev, "cannot get reset-gpios %ld\n",
+ PTR_ERR(ctx->reset_gpio));
return PTR_ERR(ctx->reset_gpio);
}
 
spi->bits_per_word = 9;
ret = spi_setup(spi);
if (ret < 0) {
-   dev_err(dev, "spi setup failed.\n");
+   DRM_DEV_ERROR(dev, "spi setup failed.\n");
return ret;
}
 
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
index 813afee82ec9..e2f2ee252409 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -458,7 +458,8 @@ static int s6e3ha2_set_brightness(struct backlight_device 
*bl_dev)
 
if (brightness < S6E3HA2_MIN_BRIGHTNESS ||
brightness > bl_dev->props.max_brightness) {
-   dev_err(ctx->dev, "Invalid brightness: %u\n", brightness);
+   DRM_DEV_ERROR(ctx->dev, "Invalid brightness: %u\n",
+ brightness);
return -EINVAL;
}
 
@@ -706,28 +707,28 @@ static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
  ctx->supplies);
if (ret < 0) {
-   dev_err(dev, "failed to get regulators: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to get regulators: %d\n", ret);
return ret;
}
 
ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset_gpio)) {
-   dev_err(dev, "cannot get reset-gpios %ld\n",
-   PTR_ERR(ctx->reset_gpio));
+   DRM_DEV_ERROR(dev, "cannot get reset-gpios %ld\n",
+ PTR_ERR(ctx->reset_gpio));
return PTR_ERR(ctx->reset_gpio);
}
 
ctx->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->enable_gpio)) {
-   dev_err(dev, "cannot get enable-gpios %ld\n",
-   PTR_ERR(ctx->enable_gpio));
+   DRM_DEV_ERROR(dev, "cannot get enable-gpios %ld\n",
+ PTR_ERR(ctx->enable_gpio));
return PTR_ERR(ctx->enable_gpio);
}
 
ctx->bl_dev = backlight_device_register("s6e3ha2", dev, ctx,
&s6e3ha2_bl_ops, NULL);
if (IS_ERR(ctx->bl_dev)) {
-   dev_err(dev, "failed to register backlight device\n");
+   DRM_DEV_ERROR(dev, "failed to register backlight device\n");
return PTR_ERR(ctx->bl_dev);
}
 
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
index f1c8000e0386..dd50f4089923 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -458,14 +458,14 @@ static int s6e63j0x03_probe(struct mipi_dsi_device *dsi)
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supp

[PATCH v1 05/19] drm/panel: truly: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Stefan Mavrodiev 
---
 drivers/gpu/drm/panel/panel-truly-nt35597.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c 
b/drivers/gpu/drm/panel/panel-truly-nt35597.c
index 6317b6b35341..162e8002c114 100644
--- a/drivers/gpu/drm/panel/panel-truly-nt35597.c
+++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
@@ -581,7 +581,7 @@ static int truly_nt35597_probe(struct mipi_dsi_device *dsi)
ctx->config = of_device_get_match_data(dev);
 
if (!ctx->config) {
-   dev_err(dev, "missing device configuration\n");
+   DRM_DEV_ERROR(dev, "missing device configuration\n");
return -ENODEV;
}
 
-- 
2.12.0

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

[PATCH v1 02/19] drm/panel: panel-innolux: drop unused variable

[Sam Ravnborg]

The num_supplies variable is not used, delete it.
Build tested.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6c3da2cbacd9..c8d0da3116dd 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -57,7 +57,6 @@ struct innolux_panel {
 
struct backlight_device *backlight;
struct regulator_bulk_data *supplies;
-   unsigned int num_supplies;
struct gpio_desc *enable_gpio;
 
bool prepared;
-- 
2.12.0

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

[PATCH v1 09/19] drm/panel: jdi: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 64 ++
 1 file changed, 34 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index fecdda0b99a5..6e172b5d7dff 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -77,19 +78,19 @@ static int jdi_panel_init(struct jdi_panel *jdi)
 
ret = mipi_dsi_dcs_set_pixel_format(dsi, MIPI_DCS_PIXEL_FMT_24BIT << 4);
if (ret < 0) {
-   dev_err(dev, "failed to set pixel format: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set pixel format: %d\n", ret);
return ret;
}
 
ret = mipi_dsi_dcs_set_column_address(dsi, 0, jdi->mode->hdisplay - 1);
if (ret < 0) {
-   dev_err(dev, "failed to set column address: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set column address: %d\n", ret);
return ret;
}
 
ret = mipi_dsi_dcs_set_page_address(dsi, 0, jdi->mode->vdisplay - 1);
if (ret < 0) {
-   dev_err(dev, "failed to set page address: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set page address: %d\n", ret);
return ret;
}
 
@@ -102,7 +103,8 @@ static int jdi_panel_init(struct jdi_panel *jdi)
ret = mipi_dsi_dcs_write(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY,
 (u8[]){ 0x24 }, 1);
if (ret < 0) {
-   dev_err(dev, "failed to write control display: %d\n", ret);
+   DRM_DEV_ERROR(dev,
+ "failed to write control display: %d\n", ret);
return ret;
}
 
@@ -110,13 +112,13 @@ static int jdi_panel_init(struct jdi_panel *jdi)
ret = mipi_dsi_dcs_write(dsi, MIPI_DCS_WRITE_POWER_SAVE,
 (u8[]){ 0x00 }, 1);
if (ret < 0) {
-   dev_err(dev, "failed to set cabc off: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set cabc off: %d\n", ret);
return ret;
}
 
ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
if (ret < 0) {
-   dev_err(dev, "failed to set exit sleep mode: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set exit sleep mode: %d\n", ret);
return ret;
}
 
@@ -124,7 +126,7 @@ static int jdi_panel_init(struct jdi_panel *jdi)
 
ret = mipi_dsi_generic_write(dsi, (u8[]){0xB0, 0x00}, 2);
if (ret < 0) {
-   dev_err(dev, "failed to set mcap: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set mcap: %d\n", ret);
return ret;
}
 
@@ -134,8 +136,9 @@ static int jdi_panel_init(struct jdi_panel *jdi)
ret = mipi_dsi_generic_write(dsi, (u8[])
 {0xB3, 0x26, 0x08, 0x00, 0x20, 0x00}, 6);
if (ret < 0) {
-   dev_err(dev, "failed to set display interface setting: %d\n"
-   , ret);
+   DRM_DEV_ERROR(dev,
+ "failed to set display interface setting: %d\n",
+ ret);
return ret;
}
 
@@ -143,8 +146,9 @@ static int jdi_panel_init(struct jdi_panel *jdi)
 
ret = mipi_dsi_generic_write(dsi, (u8[]){0xB0, 0x03}, 2);
if (ret < 0) {
-   dev_err(dev, "failed to set default values for mcap: %d\n"
-   , ret);
+   DRM_DEV_ERROR(dev,
+ "failed to set default values for mcap: %d\n",
+ ret);
return ret;
}
 
@@ -161,7 +165,7 @@ static int jdi_panel_on(struct jdi_panel *jdi)
 
ret = mipi_dsi_dcs_set_display_on(dsi);
if (ret < 0)
-   dev_err(dev, "failed to set display on: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set display on: %d\n", ret);
 
return ret;
 }
@@ -176,11 +180,11 @@ static void jdi_panel_off(struct jdi_panel *jdi)
 
ret = mipi_dsi_dcs_set_display_off(dsi);
if (ret < 0)
-   dev_err(dev, "failed to set display off: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to set display off: %d\n", ret);
 
ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
if (ret < 0)
-   dev_err(dev, "failed to enter sleep mode: %d\n", ret);
+   DRM_DEV_ERROR(dev, "failed to enter sleep mode: %d\n", ret);
 
msleep(100);
 }
@@ -212,7 +216,7 @@ static int jdi_panel_unprepare(struct drm_panel *panel)
 
ret = regulator_bulk_disable(ARRAY_SIZE(jdi->supplies), jdi->sup

[PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

[Sam Ravnborg]

Hi Thierry et al.

While reviewing a number of new panel drivers there was a
certain pattern in the feedback:
- the now deprecated drmP.h file was used
- dev_err() and friends was used

This patch-set address the above items in the panel
drivers in drm/panel/
The hope is that new panel drivers will no longer inherit bad
patterns from the existing drivers.

The use of DRM_DEV* is not accepted by everyone, so this conversion
was split up in smaller bits.
If some drivers do not want to use DRM_DEV* then just drop the relevant patch.

All patches are build tested on x86/arm.

The DRM_DEV* patches depends on the drmP.h removal.

One extra patch sneaked in "panel-innolux: drop unused variable"
This is a fix for an unused variable and was added to flush my panel patches.

Note: Waiting for key storage (for gpg key) before I start the process getting
commit rights, so I rely on someone else (Thierry?) to commit this.

Patches are made on top of drm-misc-next as of a few days ago.

Comments welcome!

Sam

Sam Ravnborg (19):
  drm/panel: drop drmP.h usage
  drm/panel: panel-innolux: drop unused variable
  drm/panel: samsung: use DRM_DEV*
  drm/panel: arm-versatile: use DRM_DEV*
  drm/panel: truly: use DRM_DEV*
  drm/panel: sitronix: use DRM_DEV*
  drm/panel: ilitek: use DRM_DEV*
  drm/panel: innolux: use DRM_DEV*
  drm/panel: jdi: use DRM_DEV*
  drm/panel: lg: use DRM_DEV*
  drm/panel: lvds: use DRM_DEV*
  drm/panel: olimex: use DRM_DEV*
  drm/panel: orisetech: use DRM_DEV*
  drm/panel: panasonic: use DRM_DEV*
  drm/panel: raspberrypi: use DRM_DEV*
  drm/panel: raydium: use DRM_DEV*
  drm/panel: seiko: use DRM_DEV*
  drm/panel: sharp: use DRM_DEV*
  drm/panel: simple: use DRM_DEV*

 drivers/gpu/drm/panel/panel-arm-versatile.c| 21 +++--
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c   | 97 --
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c  | 14 ++--
 drivers/gpu/drm/panel/panel-innolux-p079zca.c  | 17 ++--
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 66 ---
 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c |  4 +-
 drivers/gpu/drm/panel/panel-lg-lg4573.c| 25 +++---
 drivers/gpu/drm/panel/panel-lvds.c | 39 +
 drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 28 ---
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c   | 15 ++--
 .../gpu/drm/panel/panel-panasonic-vvx10f034n00.c   | 19 +++--
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  | 25 +++---
 drivers/gpu/drm/panel/panel-raydium-rm68200.c  | 11 ++-
 drivers/gpu/drm/panel/panel-samsung-ld9040.c   | 18 ++--
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 21 +++--
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 15 ++--
 drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c  | 32 ---
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c| 18 ++--
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c| 66 ++-
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c| 27 +++---
 drivers/gpu/drm/panel/panel-simple.c   | 22 +++--
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 16 ++--
 drivers/gpu/drm/panel/panel-truly-nt35597.c| 10 ++-
 23 files changed, 375 insertions(+), 251 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 18/19] drm/panel: sharp: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 63 -
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 24 ++
 2 files changed, 55 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 2ed11d86c10e..98788750084c 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -58,14 +59,16 @@ static int sharp_panel_write(struct sharp_panel *sharp, u16 
offset, u8 value)
 
err = mipi_dsi_generic_write(dsi, payload, sizeof(payload));
if (err < 0) {
-   dev_err(&dsi->dev, "failed to write %02x to %04x: %zd\n",
-   value, offset, err);
+   DRM_DEV_ERROR(&dsi->dev,
+ "failed to write %02x to %04x: %zd\n",
+ value, offset, err);
return err;
}
 
err = mipi_dsi_dcs_nop(dsi);
if (err < 0) {
-   dev_err(&dsi->dev, "failed to send DCS nop: %zd\n", err);
+   DRM_DEV_ERROR(&dsi->dev,
+ "failed to send DCS nop: %zd\n", err);
return err;
}
 
@@ -84,8 +87,9 @@ static __maybe_unused int sharp_panel_read(struct sharp_panel 
*sharp,
err = mipi_dsi_generic_read(sharp->link1, &offset, sizeof(offset),
value, sizeof(*value));
if (err < 0)
-   dev_err(&sharp->link1->dev, "failed to read from %04x: %zd\n",
-   offset, err);
+   DRM_DEV_ERROR(&sharp->link1->dev,
+ "failed to read from %04x: %zd\n",
+ offset, err);
 
return err;
 }
@@ -116,11 +120,13 @@ static int sharp_panel_unprepare(struct drm_panel *panel)
 
err = mipi_dsi_dcs_set_display_off(sharp->link1);
if (err < 0)
-   dev_err(panel->dev, "failed to set display off: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to set display off: %d\n", err);
 
err = mipi_dsi_dcs_enter_sleep_mode(sharp->link1);
if (err < 0)
-   dev_err(panel->dev, "failed to enter sleep mode: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to enter sleep mode: %d\n", err);
 
msleep(120);
 
@@ -139,26 +145,30 @@ static int sharp_setup_symmetrical_split(struct 
mipi_dsi_device *left,
 
err = mipi_dsi_dcs_set_column_address(left, 0, mode->hdisplay / 2 - 1);
if (err < 0) {
-   dev_err(&left->dev, "failed to set column address: %d\n", err);
+   DRM_DEV_ERROR(&left->dev,
+ "failed to set column address: %d\n", err);
return err;
}
 
err = mipi_dsi_dcs_set_page_address(left, 0, mode->vdisplay - 1);
if (err < 0) {
-   dev_err(&left->dev, "failed to set page address: %d\n", err);
+   DRM_DEV_ERROR(&left->dev,
+ "failed to set page address: %d\n", err);
return err;
}
 
err = mipi_dsi_dcs_set_column_address(right, mode->hdisplay / 2,
  mode->hdisplay - 1);
if (err < 0) {
-   dev_err(&right->dev, "failed to set column address: %d\n", err);
+   DRM_DEV_ERROR(&right->dev,
+ "failed to set column address: %d\n", err);
return err;
}
 
err = mipi_dsi_dcs_set_page_address(right, 0, mode->vdisplay - 1);
if (err < 0) {
-   dev_err(&right->dev, "failed to set page address: %d\n", err);
+   DRM_DEV_ERROR(&right->dev,
+ "failed to set page address: %d\n", err);
return err;
}
 
@@ -188,7 +198,8 @@ static int sharp_panel_prepare(struct drm_panel *panel)
 
err = mipi_dsi_dcs_exit_sleep_mode(sharp->link1);
if (err < 0) {
-   dev_err(panel->dev, "failed to exit sleep mode: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to exit sleep mode: %d\n", err);
goto poweroff;
}
 
@@ -204,20 +215,23 @@ static int sharp_panel_prepare(struct drm_panel *panel)
/* set left-right mode */
err = sharp_panel_write(sharp, 0x1000, 0x2a);
if (err < 0) {
-   dev_err(panel->dev, "failed to set left-right mode: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to set left-right mode: %d\n", err);

[PATCH v1 17/19] drm/panel: seiko: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c 
b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
index c1348a687447..26da26d38241 100644
--- a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
+++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -73,8 +74,8 @@ static int seiko_panel_get_fixed_modes(struct seiko_panel 
*panel)
videomode_from_timing(dt, &vm);
mode = drm_mode_create(drm);
if (!mode) {
-   dev_err(drm->dev, "failed to add mode %ux%u\n",
-   dt->hactive.typ, dt->vactive.typ);
+   DRM_DEV_ERROR(drm->dev, "failed to add mode %ux%u\n",
+ dt->hactive.typ, dt->vactive.typ);
continue;
}
 
@@ -94,8 +95,9 @@ static int seiko_panel_get_fixed_modes(struct seiko_panel 
*panel)
 
mode = drm_mode_duplicate(drm, m);
if (!mode) {
-   dev_err(drm->dev, "failed to add mode %ux%u@%u\n",
-   m->hdisplay, m->vdisplay, m->vrefresh);
+   DRM_DEV_ERROR(drm->dev,
+ "failed to add mode %ux%u@%u\n",
+ m->hdisplay, m->vdisplay, m->vrefresh);
continue;
}
 
@@ -168,7 +170,7 @@ static int seiko_panel_prepare(struct drm_panel *panel)
 
err = regulator_enable(p->dvdd);
if (err < 0) {
-   dev_err(panel->dev, "failed to enable dvdd: %d\n", err);
+   DRM_DEV_ERROR(panel->dev, "failed to enable dvdd: %d\n", err);
return err;
}
 
@@ -177,7 +179,7 @@ static int seiko_panel_prepare(struct drm_panel *panel)
 
err = regulator_enable(p->avdd);
if (err < 0) {
-   dev_err(panel->dev, "failed to enable avdd: %d\n", err);
+   DRM_DEV_ERROR(panel->dev, "failed to enable avdd: %d\n", err);
goto disable_dvdd;
}
 
-- 
2.12.0

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

[PATCH v1 11/19] drm/panel: lvds: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-lvds.c | 38 ++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index 833aeb47065b..2aa0555f78ac 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -81,8 +82,8 @@ static int panel_lvds_prepare(struct drm_panel *panel)
 
err = regulator_enable(lvds->supply);
if (err < 0) {
-   dev_err(lvds->dev, "failed to enable supply: %d\n",
-   err);
+   DRM_DEV_ERROR(lvds->dev,
+ "failed to enable supply: %d\n", err);
return err;
}
}
@@ -154,14 +155,16 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
 
ret = of_property_read_u32(np, "width-mm", &lvds->width);
if (ret < 0) {
-   dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
-   np, "width-mm");
+   DRM_DEV_ERROR(lvds->dev,
+ "%pOF: invalid or missing %s DT property\n",
+ np, "width-mm");
return -ENODEV;
}
ret = of_property_read_u32(np, "height-mm", &lvds->height);
if (ret < 0) {
-   dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
-   np, "height-mm");
+   DRM_DEV_ERROR(lvds->dev,
+ "%pOF: invalid or missing %s DT property\n",
+ np, "height-mm");
return -ENODEV;
}
 
@@ -169,8 +172,9 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
 
ret = of_property_read_string(np, "data-mapping", &mapping);
if (ret < 0) {
-   dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
-   np, "data-mapping");
+   DRM_DEV_ERROR(lvds->dev,
+ "%pOF: invalid or missing %s DT property\n",
+ np, "data-mapping");
return -ENODEV;
}
 
@@ -181,8 +185,9 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
} else if (!strcmp(mapping, "vesa-24")) {
lvds->bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
} else {
-   dev_err(lvds->dev, "%pOF: invalid or missing %s DT property\n",
-   np, "data-mapping");
+   DRM_DEV_ERROR(lvds->dev,
+ "%pOF: invalid or missing %s DT property\n",
+ np, "data-mapping");
return -EINVAL;
}
 
@@ -213,8 +218,9 @@ static int panel_lvds_probe(struct platform_device *pdev)
 
if (ret != -ENODEV) {
if (ret != -EPROBE_DEFER)
-   dev_err(lvds->dev, "failed to request 
regulator: %d\n",
-   ret);
+   DRM_DEV_ERROR(lvds->dev,
+ "failed to request regulator: 
%d\n",
+ ret);
return ret;
}
 
@@ -226,8 +232,8 @@ static int panel_lvds_probe(struct platform_device *pdev)
 GPIOD_OUT_LOW);
if (IS_ERR(lvds->enable_gpio)) {
ret = PTR_ERR(lvds->enable_gpio);
-   dev_err(lvds->dev, "failed to request %s GPIO: %d\n",
-   "enable", ret);
+   DRM_DEV_ERROR(lvds->dev, "failed to request %s GPIO: %d\n",
+ "enable", ret);
return ret;
}
 
@@ -235,8 +241,8 @@ static int panel_lvds_probe(struct platform_device *pdev)
 GPIOD_OUT_HIGH);
if (IS_ERR(lvds->reset_gpio)) {
ret = PTR_ERR(lvds->reset_gpio);
-   dev_err(lvds->dev, "failed to request %s GPIO: %d\n",
-   "reset", ret);
+   DRM_DEV_ERROR(lvds->dev, "failed to request %s GPIO: %d\n",
+ "reset", ret);
return ret;
}
 
-- 
2.12.0

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

[PATCH v1 04/19] drm/panel: arm-versatile: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Stefan Mavrodiev 
---
 drivers/gpu/drm/panel/panel-arm-versatile.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c 
b/drivers/gpu/drm/panel/panel-arm-versatile.c
index 0ed8ee4673eb..d7139b7aff7d 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -27,6 +27,7 @@
  */
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -233,7 +234,7 @@ static int versatile_panel_disable(struct drm_panel *panel)
 
/* If we're on an IB2 daughterboard, turn off display */
if (vpanel->ib2_map) {
-   dev_dbg(vpanel->dev, "disable IB2 display\n");
+   DRM_DEV_DEBUG(vpanel->dev, "disable IB2 display\n");
regmap_update_bits(vpanel->ib2_map,
   IB2_CTRL,
   IB2_CTRL_LCD_MASK,
@@ -249,7 +250,7 @@ static int versatile_panel_enable(struct drm_panel *panel)
 
/* If we're on an IB2 daughterboard, turn on display */
if (vpanel->ib2_map) {
-   dev_dbg(vpanel->dev, "enable IB2 display\n");
+   DRM_DEV_DEBUG(vpanel->dev, "enable IB2 display\n");
regmap_update_bits(vpanel->ib2_map,
   IB2_CTRL,
   IB2_CTRL_LCD_MASK,
@@ -300,12 +301,12 @@ static int versatile_panel_probe(struct platform_device 
*pdev)
 
parent = dev->parent;
if (!parent) {
-   dev_err(dev, "no parent for versatile panel\n");
+   DRM_DEV_ERROR(dev, "no parent for versatile panel\n");
return -ENODEV;
}
map = syscon_node_to_regmap(parent->of_node);
if (IS_ERR(map)) {
-   dev_err(dev, "no regmap for versatile panel parent\n");
+   DRM_DEV_ERROR(dev, "no regmap for versatile panel parent\n");
return PTR_ERR(map);
}
 
@@ -315,7 +316,7 @@ static int versatile_panel_probe(struct platform_device 
*pdev)
 
ret = regmap_read(map, SYS_CLCD, &val);
if (ret) {
-   dev_err(dev, "cannot access syscon regs\n");
+   DRM_DEV_ERROR(dev, "cannot access syscon regs\n");
return ret;
}
 
@@ -333,11 +334,11 @@ static int versatile_panel_probe(struct platform_device 
*pdev)
 
/* No panel detected or VGA, let's leave this show */
if (i == ARRAY_SIZE(versatile_panels)) {
-   dev_info(dev, "no panel detected\n");
+   DRM_DEV_INFO(dev, "no panel detected\n");
return -ENODEV;
}
 
-   dev_info(dev, "detected: %s\n", vpanel->panel_type->name);
+   DRM_DEV_INFO(dev, "detected: %s\n", vpanel->panel_type->name);
vpanel->dev = dev;
vpanel->map = map;
 
@@ -348,7 +349,8 @@ static int versatile_panel_probe(struct platform_device 
*pdev)
if (IS_ERR(vpanel->ib2_map))
vpanel->ib2_map = NULL;
else
-   dev_info(dev, "panel mounted on IB2 daughterboard\n");
+   DRM_DEV_INFO(dev,
+"panel mounted on IB2 daughterboard\n");
}
 
drm_panel_init(&vpanel->panel);
-- 
2.12.0

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

[PATCH v1 14/19] drm/panel: panasonic: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c 
b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
index c7037942c7f3..738270439285 100644
--- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
+++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -132,7 +133,7 @@ static int wuxga_nt_panel_prepare(struct drm_panel *panel)
 
ret = wuxga_nt_panel_on(wuxga_nt);
if (ret < 0) {
-   dev_err(panel->dev, "failed to set panel on: %d\n", ret);
+   DRM_DEV_ERROR(panel->dev, "failed to set panel on: %d\n", ret);
goto poweroff;
}
 
@@ -183,9 +184,10 @@ static int wuxga_nt_panel_get_modes(struct drm_panel 
*panel)
 
mode = drm_mode_duplicate(panel->drm, &default_mode);
if (!mode) {
-   dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
-   default_mode.hdisplay, default_mode.vdisplay,
-   default_mode.vrefresh);
+   DRM_DEV_ERROR(panel->drm->dev,
+ "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
return -ENOMEM;
}
 
@@ -294,11 +296,13 @@ static int wuxga_nt_panel_remove(struct mipi_dsi_device 
*dsi)
 
ret = wuxga_nt_panel_disable(&wuxga_nt->base);
if (ret < 0)
-   dev_err(&dsi->dev, "failed to disable panel: %d\n", ret);
+   DRM_DEV_ERROR(&dsi->dev,
+ "failed to disable panel: %d\n", ret);
 
ret = mipi_dsi_detach(dsi);
if (ret < 0)
-   dev_err(&dsi->dev, "failed to detach from DSI host: %d\n", ret);
+   DRM_DEV_ERROR(&dsi->dev,
+ "failed to detach from DSI host: %d\n", ret);
 
wuxga_nt_panel_del(wuxga_nt);
 
-- 
2.12.0

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

[PATCH v1 08/19] drm/panel: innolux: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index c8d0da3116dd..cf18594d1954 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -154,8 +154,9 @@ static int innolux_panel_prepare(struct drm_panel *panel)
err = mipi_dsi_generic_write(innolux->link, cmd->data,
 cmd->len);
if (err < 0) {
-   dev_err(panel->dev,
-   "failed to write command %u\n", i);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to write command %u\n",
+ i);
goto poweroff;
}
 
@@ -166,8 +167,9 @@ static int innolux_panel_prepare(struct drm_panel *panel)
 */
err = mipi_dsi_dcs_nop(innolux->link);
if (err < 0) {
-   dev_err(panel->dev,
-   "failed to send DCS nop: %d\n", err);
+   DRM_DEV_ERROR(panel->dev,
+ "failed to send DCS nop: %d\n",
+ err);
goto poweroff;
}
}
@@ -482,7 +484,7 @@ static int innolux_panel_add(struct mipi_dsi_device *dsi,
   GPIOD_OUT_HIGH);
if (IS_ERR(innolux->enable_gpio)) {
err = PTR_ERR(innolux->enable_gpio);
-   dev_dbg(dev, "failed to get enable gpio: %d\n", err);
+   DRM_DEV_DEBUG(dev, "failed to get enable gpio: %d\n", err);
innolux->enable_gpio = NULL;
}
 
-- 
2.12.0

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

[PATCH v1 07/19] drm/panel: ilitek: use DRM_DEV*

[Sam Ravnborg]

Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.

Signed-off-by: Sam Ravnborg 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c  | 93 +++
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 14 ++--
 2 files changed, 60 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index 1ee8b2ccf718..e5e60347d3cf 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -302,7 +302,7 @@ static int ili9322_regmap_spi_write(void *context, const 
void *data,
memcpy(buf, data, 2);
buf[0] &= ~0x80;
 
-   dev_dbg(dev, "WRITE: %02x %02x\n", buf[0], buf[1]);
+   DRM_DEV_DEBUG(dev, "WRITE: %02x %02x\n", buf[0], buf[1]);
return spi_write_then_read(spi, buf, 2, NULL, 0);
 }
 
@@ -315,8 +315,8 @@ static int ili9322_regmap_spi_read(void *context, const 
void *reg,
 
/* Set bit 7 to 1 to read */
memcpy(buf, reg, 1);
-   dev_dbg(dev, "READ: %02x reg size = %zu, val size = %zu\n",
-   buf[0], reg_size, val_size);
+   DRM_DEV_DEBUG(dev, "READ: %02x reg size = %zu, val size = %zu\n",
+ buf[0], reg_size, val_size);
buf[0] |= 0x80;
 
return spi_write_then_read(spi, buf, 1, val, 1);
@@ -362,7 +362,7 @@ static int ili9322_init(struct drm_panel *panel, struct 
ili9322 *ili)
ret = regmap_write(ili->regmap, ILI9322_GLOBAL_RESET,
   ILI9322_GLOBAL_RESET_ASSERT);
if (ret) {
-   dev_err(ili->dev, "can't issue GRESET (%d)\n", ret);
+   DRM_DEV_ERROR(ili->dev, "can't issue GRESET (%d)\n", ret);
return ret;
}
 
@@ -371,7 +371,8 @@ static int ili9322_init(struct drm_panel *panel, struct 
ili9322 *ili)
ret = regmap_write(ili->regmap, ILI9322_VREG1_VOLTAGE,
   ili->vreg1out);
if (ret) {
-   dev_err(ili->dev, "can't set up VREG1OUT (%d)\n", ret);
+   DRM_DEV_ERROR(ili->dev,
+ "can't set up VREG1OUT (%d)\n", ret);
return ret;
}
}
@@ -380,8 +381,9 @@ static int ili9322_init(struct drm_panel *panel, struct 
ili9322 *ili)
ret = regmap_write(ili->regmap, ILI9322_VCOM_AMP,
   ili->vcom_amplitude);
if (ret) {
-   dev_err(ili->dev,
-   "can't set up VCOM amplitude (%d)\n", ret);
+   DRM_DEV_ERROR(ili->dev,
+ "can't set up VCOM amplitude (%d)\n",
+ ret);
return ret;
}
};
@@ -390,7 +392,8 @@ static int ili9322_init(struct drm_panel *panel, struct 
ili9322 *ili)
ret = regmap_write(ili->regmap, ILI9322_VCOM_HIGH,
   ili->vcom_high);
if (ret) {
-   dev_err(ili->dev, "can't set up VCOM high (%d)\n", ret);
+   DRM_DEV_ERROR(ili->dev,
+ "can't set up VCOM high (%d)\n", ret);
return ret;
}
};
@@ -400,9 +403,9 @@ static int ili9322_init(struct drm_panel *panel, struct 
ili9322 *ili)
ret = regmap_write(ili->regmap, ILI9322_GAMMA_1 + i,
   ili->gamma[i]);
if (ret) {
-   dev_err(ili->dev,
-   "can't write gamma V%d to 0x%02x (%d)\n",
-   i + 1, ILI9322_GAMMA_1 + i, ret);
+   DRM_DEV_ERROR(ili->dev,
+ "can't write gamma V%d to 0x%02x (%d)\n",
+ i + 1, ILI9322_GAMMA_1 + i, ret);
return ret;
}
}
@@ -434,7 +437,8 @@ static int ili9322_init(struct drm_panel *panel, struct 
ili9322 *ili)
reg |= ILI9322_POL_VSYNC;
ret = regmap_write(ili->regmap, ILI9322_POL, reg);
if (ret) {
-   dev_err(ili->dev, "can't write POL register (%d)\n", ret);
+   DRM_DEV_ERROR(ili->dev,
+ "can't write POL register (%d)\n", ret);
return ret;
}
 
@@ -446,7 +450,8 @@ static int ili9322_init(struct drm_panel *panel, struct 
ili9322 *ili)
reg |= ILI9322_IF_CTRL_LINE_INVERSION;
ret = regmap_write(ili->regmap, ILI9322_IF_CTRL, reg);
if (ret) {
-   dev_err(ili->dev, "can't write IF CTRL register (%d)\n", ret);
+   DRM_DEV_ERROR(ili->dev,
+ "can't write IF CTRL register (%d)\n", ret);
 

[PATCH v1 01/19] drm/panel: drop drmP.h usage

[Sam Ravnborg]

Use of drmP.h is discouraged and yet we see new panel
drivers utilising drmP.h.
Remove usage of drmP.h from current panel drivers to set a good
example for new drivers.

While touching list of include files sort them.

Build tested on arm/x86.

Signed-off-by: Sam Ravnborg 
Cc: Linus Walleij 
Cc: Stefan Mavrodiev 
Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/panel/panel-arm-versatile.c   | 3 ++-
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c  | 4 +++-
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 4 +++-
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c| 2 +-
 drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c| 4 +++-
 drivers/gpu/drm/panel/panel-lg-lg4573.c   | 5 -
 drivers/gpu/drm/panel/panel-lvds.c| 1 -
 drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c| 2 +-
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c  | 7 ++-
 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c  | 3 ++-
 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 3 +--
 drivers/gpu/drm/panel/panel-raydium-rm68200.c | 5 -
 drivers/gpu/drm/panel/panel-samsung-ld9040.c  | 6 +-
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 6 +-
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c  | 7 ++-
 drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 6 +-
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c   | 4 +++-
 drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c   | 3 ++-
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c   | 3 ++-
 drivers/gpu/drm/panel/panel-simple.c  | 3 ++-
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c| 6 +-
 drivers/gpu/drm/panel/panel-truly-nt35597.c   | 8 ++--
 22 files changed, 71 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c 
b/drivers/gpu/drm/panel/panel-arm-versatile.c
index b428c4678106..0ed8ee4673eb 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -25,13 +25,14 @@
  * Epson QCIF display.
  *
  */
-#include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index bd38bf4f1ba6..1ee8b2ccf718 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -22,8 +22,10 @@
  * published by the Free Software Foundation.
  */
 
-#include 
+#include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 8e5724b63f1f..6c3da2cbacd9 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -8,16 +8,18 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 99caa7835e7b..fecdda0b99a5 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -22,12 +22,12 @@
  * this program.  If not, see .
  */
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c 
b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
index 2a25a914d09e..f61211a69dbe 100644
--- a/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
+++ b/drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c
@@ -4,15 +4,17 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #include 
 
diff --git a/drivers/gpu/drm/panel/panel-lg-lg4573.c 
b/drivers/gpu/drm/panel/panel-lg-lg4573.c
index 6989238b276a..e63fba2761f4 100644
--- a/drivers/gpu/drm/panel/panel-lg-lg4573.c
+++ b/drivers/gpu/drm/panel/panel-lg-lg4573.c
@@ -15,10 +15,13 @@
  * published by the Free Software Foundation.
 */
 
-#include 
+#include 
+#include 
 #include 
 
+#include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index 3f6550e6b6a4..833aeb47065b 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c 
b/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
index 5e8d4523e9ed..c8704be9caa3 100644
--- a/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
+++ b/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
@@ -15,9 +15,9 @@
 #include 
 #inc

Re: [PATCH v5 0/8] drm/msm/dsi: Get PHY ref clocks from the DT

[Sean Paul]

On Mon, Jan 28, 2019 at 04:05:34PM -0800, Matthias Kaehlcke wrote:
> Hi,
> 
> this series has gone through multiple rounds of review and there are
> no outstanding comments. It seems it should be ready to land, or is
> there anything left that needs to be addressed?

From the drm side, I think we'll need Andy to pick up the dt-bindings
and dts changes, and then the msm/dsi changes can be picked once that's
merged. We could also do a topic branch if that suits everyone.

Sean

> 
> Thanks
> 
> Matthias
> 
> On Wed, Dec 19, 2018 at 03:55:20PM -0800, Matthias Kaehlcke wrote:
> > The MSM DSI PHY drivers currently hardcode the name and the rate of
> > the PHY ref clock. Get the ref clock from the device tree instead.
> > 
> > Note: testing of this series was limited to SDM845 and the 10nm PHY
> > 
> > Major changes in v5:
> > - none (see per-patch change log for minor changes)
> > 
> > Major changes in v4:
> > - always use parent rate for 28nm and 28nm 8960 PHYs
> > 
> > Major changes in v3:
> > - keep supporting DTs without ref clock for the 28nm and the 28nm
> >   8960 PHYs
> > - added patch to add ref clock to qcom-apq8064.dtsi
> > 
> > Major changes in v2:
> > - apply to all MSM DSI PHY drivers, not only 10nm
> > 
> > Matthias Kaehlcke (8):
> >   dt-bindings: msm/dsi: Add ref clock for PHYs
> >   drm/msm/dsi: 28nm 8960 PHY: Get ref clock from the DT
> >   drm/msm/dsi: 28nm PHY: Get ref clock from the DT
> >   drm/msm/dsi: 14nm PHY: Get ref clock from the DT
> >   drm/msm/dsi: 10nm PHY: Get ref clock from the DT
> >   arm64: dts: qcom: msm8916: Set 'xo_board' as ref clock of the DSI PHY
> >   arm64: dts: sdm845: Set 'bi_tcxo' as ref clock of the DSI PHYs
> >   ARM: dts: qcom-apq8064: Set 'xo_board' as ref clock of the DSI PHY
> > 
> >  .../devicetree/bindings/display/msm/dsi.txt   |  1 +
> >  arch/arm/boot/dts/qcom-apq8064.dtsi   |  5 +--
> >  arch/arm64/boot/dts/qcom/msm8916.dtsi |  5 +--
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi  | 10 +++---
> >  drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c| 20 +--
> >  drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c| 23 +---
> >  drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c| 36 +--
> >  .../gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c   | 24 ++---
> >  8 files changed, 92 insertions(+), 32 deletions(-)
> > 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/TODO: Add drm_display_mode.hsync/vrefresh removal

[Sean Paul]

On Tue, Jan 29, 2019 at 02:26:29PM -0500, Sean Paul wrote:
> From: Sean Paul 
> 
> Drivers shouldn't be using these values, add a TODO so someone removes
> them.
> 
> Changes in v2:
> - Add drm_display_mode.vrefresh removal (Ville)
> - Add Sam's R-b and bonus points
> Changes in v3:
> - Add hsync removal todo item (Daniel)
> - Change vrefresh wording to make removal less optional
> 
> Cc: Ville Syrjälä 
> Suggested-by: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Sam Ravnborg 
> Bonus-points-awarded-by: Sam Ravnborg 
> Signed-off-by: Sean Paul 

And applied to -misc-next.

Thanks for the reviews, all.

Sean

> ---
> 
> This time with feeling.
> 
>  Documentation/gpu/todo.rst | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 38360ede12215..f67c84b92873c 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -262,6 +262,34 @@ As a reference, take a look at the conversions already 
> completed in drm core.
>  
>  Contact: Sean Paul, respective driver maintainers
>  
> +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh()
> +
> +
> +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it
> +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core
> +has helper which will use mode.vrefresh if it's !0 and will calculate it from
> +the timings when it's 0.
> +
> +Use simple search/replace, or (more fun) cocci to replace instances of direct
> +vrefresh access with a call to the helper. Check out
> +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for
> +inspiration.
> +
> +Once all instances of vrefresh have been converted, remove vrefresh from
> +drm_display_mode to avoid future use.
> +
> +Contact: Sean Paul
> +
> +Remove drm_display_mode.hsync
> +-
> +
> +We have drm_mode_hsync() to calculate this from hsync_start/end, since 
> drivers
> +shouldn't/don't use this, remove this member to avoid any temptations to use 
> it
> +in the future. If there is any debug code using drm_display_mode.hsync, 
> convert
> +it to use drm_mode_hsync() instead.
> +
> +Contact: Sean Paul
> +
>  Core refactorings
>  =
>  
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/6] drm/virtio: drop fencing in virtio_gpu_resource_create_ioctl

[Gurchetan Singh]

On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann  wrote:
>
> There is no need to wait for completion here.
>
> The host will process commands in submit order, so commands can
> reference the new resource just fine even when queued up before
> completion.

Does virtio_gpu_execbuffer_ioctl also wait for completion for a host response?

From the guest driver perspective, a fence is just implemented has a
virtio 3D resource.

https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c#L787

The DRM_IOCTL_VIRTGPU_WAIT ioctl essentially waits for the reservation
objects associated with that fence resource to become available.  So
the flow is:

virtio_gpu_execbuffer_ioctl
virtio_gpu_resource_create_ioctl with fence resource
virtio_gpu_wait_ioctl with that fence resource --> associated with a
GL wait on the host side

Does this change modify this sequence of events?

>
> On the guest side there is no need to wait for completion too.  Which
> btw is different from resource destroy, where we have to make sure the
> host has seen the destroy and thus doesn't use it any more before
> releasing the pages backing the resource.
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 51 
> +-
>  1 file changed, 1 insertion(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 431e5d767e..da06ebbb3a 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -279,10 +279,6 @@ static int virtio_gpu_resource_create_ioctl(struct 
> drm_device *dev, void *data,
> struct virtio_gpu_object *qobj;
> struct drm_gem_object *obj;
> uint32_t handle = 0;
> -   struct list_head validate_list;
> -   struct ttm_validate_buffer mainbuf;
> -   struct virtio_gpu_fence *fence = NULL;
> -   struct ww_acquire_ctx ticket;
> struct virtio_gpu_object_params params = { 0 };
>
> if (vgdev->has_virgl_3d == false) {
> @@ -298,9 +294,6 @@ static int virtio_gpu_resource_create_ioctl(struct 
> drm_device *dev, void *data,
> return -EINVAL;
> }
>
> -   INIT_LIST_HEAD(&validate_list);
> -   memset(&mainbuf, 0, sizeof(struct ttm_validate_buffer));
> -
> params.pinned = false,
> params.format = rc->format;
> params.width = rc->width;
> @@ -329,62 +322,20 @@ static int virtio_gpu_resource_create_ioctl(struct 
> drm_device *dev, void *data,
>
> ret = virtio_gpu_object_attach(vgdev, qobj, NULL);
> } else {
> -   /* use a gem reference since unref list undoes them */
> -   drm_gem_object_get(&qobj->gem_base);
> -   mainbuf.bo = &qobj->tbo;
> -   list_add(&mainbuf.head, &validate_list);
> -
> -   ret = virtio_gpu_object_list_validate(&ticket, 
> &validate_list);
> -   if (ret) {
> -   DRM_DEBUG("failed to validate\n");
> -   goto fail_unref;
> -   }
> -
> -   fence = virtio_gpu_fence_alloc(vgdev);
> -   if (!fence) {
> -   ret = -ENOMEM;
> -   goto fail_backoff;
> -   }
> -
> virtio_gpu_cmd_resource_create_3d(vgdev, qobj, ¶ms);
> -   ret = virtio_gpu_object_attach(vgdev, qobj, fence);
> -   if (ret) {
> -   dma_fence_put(&fence->f);
> -   goto fail_backoff;
> -   }
> -   ttm_eu_fence_buffer_objects(&ticket, &validate_list, 
> &fence->f);
> +   ret = virtio_gpu_object_attach(vgdev, qobj, NULL);
> }
>
> ret = drm_gem_handle_create(file_priv, obj, &handle);
> if (ret) {
> -
> drm_gem_object_release(obj);
> -   if (vgdev->has_virgl_3d) {
> -   virtio_gpu_unref_list(&validate_list);
> -   dma_fence_put(&fence->f);
> -   }
> return ret;
> }
> drm_gem_object_put_unlocked(obj);
>
> rc->res_handle = qobj->hw_res_handle; /* similiar to a VM address */
> rc->bo_handle = handle;
> -
> -   if (vgdev->has_virgl_3d) {
> -   virtio_gpu_unref_list(&validate_list);
> -   dma_fence_put(&fence->f);
> -   }
> return 0;
> -fail_backoff:
> -   ttm_eu_backoff_reservation(&ticket, &validate_list);
> -fail_unref:
> -   if (vgdev->has_virgl_3d) {
> -   virtio_gpu_unref_list(&validate_list);
> -   dma_fence_put(&fence->f);
> -   }
> -//fail_obj:
> -// drm_gem_object_handle_unreference_unlocked(obj);
> -   return ret;
>  }
>
>  static int virtio_gpu_resource_info_ioctl(struct drm_device *dev, void *data,
> --
> 2.9.3
>
> ___
> dri-devel mailing list
>

[Bug 202449] vrr_capable not showing up in xrandr with eDP display.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202449

Haxk20 (haxk...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #9 from Haxk20 (haxk...@gmail.com) ---
As this bug has been solved im marking it as solved. Thank you.

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

[Bug 108487] Wayland compositors are unable to use hardware acceleration on i915

[bugzilla-daemon]

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

--- Comment #14 from magiblot  ---
Created attachment 143267
  --> https://bugs.freedesktop.org/attachment.cgi?id=143267&action=edit
Stderr output of weston when run on i915 (with patch from comment #13)

(In reply to Daniel Stone from comment #13)

Thank you very much! I applied the patch over weston-git and tried again. It
got closer, but still doesn't work for me.

The following errors have now appeared:

> [13:53:34.450] failed to create kms fb: No such file or directory
> [13:53:34.450] failed to get drm_fb for bo
> [13:53:34.979] failed to create kms fb: No such file or directory
> [13:53:34.980] failed to get drm_fb for bo
> [13:53:35.035] failed to create kms fb: No such file or directory
> [13:53:35.035] failed to get drm_fb for bo

weston doesn't crash or anything. After startup, the content of the tty
continues being shown and weston appears to be idle. Ctrl+Alt+Backspace exits
weston normally and control is given back to the shell.

Cheers.

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

Re: [PATCH] drm/i915: do not return invalid pointers as a *dentry

[Greg Kroah-Hartman]

On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote:
> On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, they can now return error values if
> > something went wrong.  If that happens, return a NULL as a *dentry to
> > the relay core instead of passing it an illegal pointer.
> > 
> > The relay core should be able to handle an illegal pointer, but add this
> > check to be safe.
> > 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Rodrigo Vivi 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Greg Kroah-Hartman 
> > ---
> >  drivers/gpu/drm/i915/intel_guc_log.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
> > b/drivers/gpu/drm/i915/intel_guc_log.c
> > index d3ebdbc0182e..8bf03497dcd8 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_log.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> > @@ -140,6 +140,9 @@ static struct dentry *create_buf_file_callback(const 
> > char *filename,
> >  
> > buf_file = debugfs_create_file(filename, mode,
> >parent, buf, &relay_file_operations);
> > +   if (IS_ERR(buf_file))
> > +   return NULL;
> 
> I still see a return NULL inside debugfs_create_file on master,
> but probably you are ahead with some change that I didn't see yet right?

Yes, this patch is in linux-next now and should go to Linus for
5.0-final:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=driver-core-linus&id=ff9fb72bc07705c00795ca48631f7fffe24d2c6b

> I'm just wondering if it wouldn't be better for now to go with
> 
> if (IS_ERR_OR_NULL(buf_file))

Not really, because the next line is:

> > return buf_file;

So it's the same thing :)

> apparently we also need it on i915_debugfs.c i915_debugfs_register()

I have a bunch of patches I'm working on to go through and fix up all of
this (you shouldn't be checking the return value at all, unless you
really want to use it as a "real" dentry and not just something that
debugfs uses internally.

But for now, you should be fine, that call will only fail if you are out
of memory, or did something really wrong.

thanks,

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

Re: [PATCH] drm/i915: do not return invalid pointers as a *dentry

[Rodrigo Vivi]

On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, they can now return error values if
> something went wrong.  If that happens, return a NULL as a *dentry to
> the relay core instead of passing it an illegal pointer.
> 
> The relay core should be able to handle an illegal pointer, but add this
> check to be safe.
> 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/gpu/drm/i915/intel_guc_log.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
> b/drivers/gpu/drm/i915/intel_guc_log.c
> index d3ebdbc0182e..8bf03497dcd8 100644
> --- a/drivers/gpu/drm/i915/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> @@ -140,6 +140,9 @@ static struct dentry *create_buf_file_callback(const char 
> *filename,
>  
>   buf_file = debugfs_create_file(filename, mode,
>  parent, buf, &relay_file_operations);
> + if (IS_ERR(buf_file))
> + return NULL;

I still see a return NULL inside debugfs_create_file on master,
but probably you are ahead with some change that I didn't see yet right?

I'm just wondering if it wouldn't be better for now to go with

if (IS_ERR_OR_NULL(buf_file))

apparently we also need it on i915_debugfs.c i915_debugfs_register()

Thanks,
Rodrigo.

> +
>   return buf_file;
>  }
>  
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] malidp-next

[Liviu Dudau]

Hi DRM maintainers,

This pull includes the new Arm "komeda" DRM driver. It is currently hosted
in the same repo as the other "mali-dp" driver because it is the next
iteration of the IP.

Please note that due to changes in the DRM framework, after merging the
tree you will need to apply the following patch to resolve the build
failure caused by commit 

  b962a12050a3 ("drm/atomic: integrate modeset lock with private objects")

--8<-
From: Stephen Rothwell 
Date: Tue, 15 Jan 2019 10:42:04 +1100
Subject: [PATCH] drm/komeda: merge fix for drm_atomic_private_obj_init() API 
change

Signed-off-by: Stephen Rothwell 
Acked-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
index 9edfd6ab0c12..f1c9e3fefa86 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
@@ -45,7 +45,7 @@ static int komeda_pipeline_obj_add(struct komeda_kms_dev *kms,
return -ENOMEM;
 
st->pipe = pipe;
-   drm_atomic_private_obj_init(&pipe->obj, &st->obj,
+   drm_atomic_private_obj_init(&kms->base, &pipe->obj, &st->obj,
&komeda_pipeline_obj_funcs);
 
return 0;
--
2.20.1

--8<-

Thanks,

Liviu


The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:

  Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)

are available in the Git repository at:

  git://linux-arm.org/linux-ld.git for-upstream/mali-dp

for you to fetch changes up to dcc9d76b6d834d06a317e27fa8242d7e009135ac:

  drm/komeda: Off by one in komeda_fb_get_pixel_addr() (2019-01-30 13:46:17 
+)


Brian Starkey (1):
  drm/afbc: Add AFBC modifier usage documentation

Dan Carpenter (1):
  drm/komeda: Off by one in komeda_fb_get_pixel_addr()

Liviu Dudau (1):
  drm: arm/komeda: Remove IRQ parsing from initial series

james qian wang (Arm Technology China) (10):
  drm/arm: Delete redundant CONFIG_DRM_ARM
  drm/komeda: komeda_dev/pipeline/component definition and initialzation
  dt/bindings: drm/komeda: Add DT bindings for ARM display processor D71
  drm/komeda: Build komeda to be a platform module
  drm/komeda: Add DT parsing
  drm/komeda: Add komeda_format_caps for format handling
  drm/komeda: Add komeda_framebuffer
  drm/komeda: Attach komeda_dev to DRM-KMS
  drm/doc: Add initial komeda driver documentation
  MAINTAINERS: Add maintainer for Arm komeda driver

 .../devicetree/bindings/display/arm,komeda.txt |  73 +++
 Documentation/gpu/afbc.rst | 235 ++
 Documentation/gpu/drivers.rst  |   2 +
 Documentation/gpu/komeda-kms.rst   | 488 +
 MAINTAINERS|  15 +-
 drivers/gpu/drm/Makefile   |   2 +-
 drivers/gpu/drm/arm/Kconfig|  12 +-
 drivers/gpu/drm/arm/Makefile   |   1 +
 drivers/gpu/drm/arm/display/Kbuild |   3 +
 drivers/gpu/drm/arm/display/Kconfig|  14 +
 drivers/gpu/drm/arm/display/include/malidp_io.h|  42 ++
 .../gpu/drm/arm/display/include/malidp_product.h   |  23 +
 drivers/gpu/drm/arm/display/include/malidp_utils.h |  16 +
 drivers/gpu/drm/arm/display/komeda/Makefile|  21 +
 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c   | 111 +
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c   | 106 +
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 186 
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h| 110 +
 drivers/gpu/drm/arm/display/komeda/komeda_drv.c| 144 ++
 .../drm/arm/display/komeda/komeda_format_caps.c|  75 
 .../drm/arm/display/komeda/komeda_format_caps.h|  89 
 .../drm/arm/display/komeda/komeda_framebuffer.c| 165 +++
 .../drm/arm/display/komeda/komeda_framebuffer.h|  34 ++
 drivers/gpu/drm/arm/display/komeda/komeda_kms.c| 167 +++
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 113 +
 .../gpu/drm/arm/display/komeda/komeda_pipeline.c   | 200 +
 .../gpu/drm/arm/display/komeda/komeda_pipeline.h   | 359 +++
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c  | 109 +
 .../drm/arm/display/komeda/komeda_private_obj.c|  88 
 include/uapi/drm/drm_fourcc.h  |   3 +
 30 files changed, 2998 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/arm,komeda.txt
 create mode 100644 Documentation/gpu/afbc.rst
 create mode 100644 Documentation/gpu/komeda-kms.rst
 create mode 100644 drivers/gpu/dr

Re: [PATCH 0/8] drm/meson: Add support for HDMI2.0 4k60

[Laurent Pinchart]

Hi Neil,

On Thu, Jan 31, 2019 at 02:25:30PM +0100, Neil Armstrong wrote:
> On 15/01/2019 13:33, Neil Armstrong wrote:
> > This patchset aims to add support for the following HDMI2.0 4k60 modes:
> > - 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for 
> > RGB/YUV4:4:4
> > - 297MHz TMDS frequency with YUV4:2:0 encoding
> > 
> > The first mode uses the SCDC helpers introduced by intel to :
> > - discover where the monitor support SCDC
> > - setup the SCDC parameters
> > This is implemented in the dw-hdmi bridge driver by handling scrambling
> > support during the bridge setup and by exporting an helper for the PHY
> > setup to setup the SCDC configuration for the 1/40 TMDS rate.
> > This code will only be active if the encoder support a TMDS rate > 340MHz.
> > 
> > This patch could eventually break support on different SoC when connected
> > on a 4k60 monitor with SCDC :
> > - i.MX correctly discards pixel clocks > 216MHz
> > - R-CAR discards discards pixel clocks > 297MHz since [1]
> > - Rockchip discards invalid pixel clocks not in the rockchip_mpll_cfg table
> > - sun8i correctly discards pixel clocks > 297MHz on a83t
> > - sun8i discards discards pixel clocks > 594Mhz on h6, which is already 
> > broken
> > 
> > First patch should fix support for Allwinner H6.
> > 
> > The second mode is implemented by added the missing 4:2:0 bypass handling
> > in the dw-hdmi bridge driver and adding a "mtmdsclock" separating the
> > pixel clock from the tmds clock in the mode setup phase.
> > We also enable support for these modes in the connector only if the platform
> > glue code explicits the support.
> 
> Do you think patches 1-4 could be applied ?

I would have liked it if there could be a way to avoid exporting
dw_hdmi_set_high_tmds_clock_ratio() in patch 1/8, but if that's not
possible, so be it (I haven't researched that myself). No issue with
patches 2/8 to 4/8.

> Then we could focus on how we manage the bus format between the encoder
> and the bridge ?
> 
> Especially patch 5 linked to patch 7.
> 
> Will one of you be at FOSDEM 2019 ? we could chat about this.

I will be there on Sunday, likely from around 11:00.

> Following subjects on the table will be :
> - HDR metadata transmission aligned with the last patchset sent by intel-gfx
> - Colorspace connector property aligned with the last patchset sent by 
> intel-gfx
> - HDCP 1.4 and 2.2 handling
> 
> > Only the meson DRM dw_hdmi glue allows ycbcr420 modes, so no breakage
> > is expected here.
> > 
> > The remaining patches adds support for :
> > - 1/40 TMDS rate aka DIV40 in the dw-hdmi meson PHY setup
> > - 4:2:0 output and clock setup
> > 
> > The dw-hdmi support re-uses the support done by Rockchip engineers on the
> > Linux 4.4 BSP kernel.
> > 
> > These modes has been validated using a MuxLab HDMI Signal Analyser in
> > addition to different UHD TVs supporting full 4k60 or the 4:2:0 variant.
> > 
> > Changes since RFC v2 at [3]:
> > - Collected tested-by and reviewed-by tags
> > - Changed if condition in "add HDMI div40 TMDS mode"
> > - Updated "Add YUV420 output support" with the same if condition
> > 
> > Changes since RFC v1 at [2]:
> > - Fix all comments from Laurent :
> > - Add define for HDMI 1.4 max tmds clock and SCDC supported version
> > - Call dw_hdmi_set_high_tmds_clock_ratio() in dw_hdmi_phy_enable_powerdown()
> > to unbreak Allwinner H6
> > - Pass in_t(u8, bytes, SCDC_MIN_SOURCE_VERSION) as SCDC version
> > - Finally add comments for SCDC and Scrambling process
> > 
> > [1] https://patchwork.freedesktop.org/patch/263616/
> > [2] https://patchwork.freedesktop.org/series/52950/#rev1
> > [3] https://patchwork.freedesktop.org/series/52950/#rev2
> > 
> > Neil Armstrong (7):
> >   drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
> >   drm/meson: add HDMI div40 TMDS mode
> >   drm/meson: add support for HDMI2.0 2160p modes
> >   drm/bridge: dw-hdmi: add support for YUV420 output
> >   drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a
> >   drm/meson: Add YUV420 output support
> >   drm/meson: Output in YUV444 if sink supports it
> > 
> > Zheng Yang (1):
> >   drm/bridge: dw-hdmi: support dynamically get input/out color info
> > 
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 182 +++---
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |   1 +
> >  drivers/gpu/drm/meson/meson_dw_hdmi.c | 128 ---
> >  drivers/gpu/drm/meson/meson_vclk.c|  93 ---
> >  drivers/gpu/drm/meson/meson_vclk.h|   7 +-
> >  drivers/gpu/drm/meson/meson_venc.c|   8 +-
> >  drivers/gpu/drm/meson/meson_venc.h|  11 ++
> >  drivers/gpu/drm/meson/meson_venc_cvbs.c   |   3 +-
> >  include/drm/bridge/dw_hdmi.h  |   7 +
> >  9 files changed, 374 insertions(+), 66 deletions(-)

-- 
Regards,

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

Re: [PATCH v2 2/2] drm/vkms: Modify memset() in compute_crc function

[Wentland, Harry]

On 2019-01-29 5:00 p.m., Mamta Shukla wrote:
> Replace memset(vaddr_out + src_offset + 24, 0,  8) with
> memset(vaddr_out + src_offset + 3, 0, 1) because memset fills
> memory in bytes and not in bits.
> 
> Signed-off-by: Mamta Shukla 

Series is
Reviewed-by: Harry Wentland 

Harry

> ---
> No changes in v2.
> 
>  drivers/gpu/drm/vkms/vkms_crc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index dc6cb4c2cced..5135642fb204 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -31,7 +31,7 @@ static uint32_t compute_crc(void *vaddr_out, struct 
> vkms_crc_data *crc_out)
>+ (i * crc_out->pitch)
>+ (j * crc_out->cpp);
>   /* XRGB format ignores Alpha channel */
> - memset(vaddr_out + src_offset + 24, 0,  8);
> + memset(vaddr_out + src_offset + 3, 0, 1);
>   crc = crc32_le(crc, vaddr_out + src_offset,
>  sizeof(u32));
>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/9] mmu notifier provide context informations

[Jerome Glisse]

Andrew what is your plan for this ? I had a discussion with Peter Xu
and Andrea about change_pte() and kvm. Today the change_pte() kvm
optimization is effectively disabled because of invalidate_range
calls. With a minimal couple lines patch on top of this patchset
we can bring back the kvm change_pte optimization and we can also
optimize some other cases like for instance when write protecting
after fork (but i am not sure this is something qemu does often so
it might not help for real kvm workload).

I will be posting a the extra patch as an RFC, but in the meantime
i wanted to know what was the status for this.


Jan, Christian does your previous ACK still holds for this ?


On Wed, Jan 23, 2019 at 05:23:06PM -0500, jgli...@redhat.com wrote:
> From: Jérôme Glisse 
> 
> Hi Andrew, i see that you still have my event patch in you queue [1].
> This patchset replace that single patch and is broken down in further
> step so that it is easier to review and ascertain that no mistake were
> made during mechanical changes. Here are the step:
> 
> Patch 1 - add the enum values
> Patch 2 - coccinelle semantic patch to convert all call site of
>   mmu_notifier_range_init to default enum value and also
>   to passing down the vma when it is available
> Patch 3 - update many call site to more accurate enum values
> Patch 4 - add the information to the mmu_notifier_range struct
> Patch 5 - helper to test if a range is updated to read only
> 
> All the remaining patches are update to various driver to demonstrate
> how this new information get use by device driver. I build tested
> with make all and make all minus everything that enable mmu notifier
> ie building with MMU_NOTIFIER=no. Also tested with some radeon,amd
> gpu and intel gpu.
> 
> If they are no objections i believe best plan would be to merge the
> the first 5 patches (all mm changes) through your queue for 5.1 and
> then to delay driver update to each individual driver tree for 5.2.
> This will allow each individual device driver maintainer time to more
> thouroughly test this more then my own testing.
> 
> Note that i also intend to use this feature further in nouveau and
> HMM down the road. I also expect that other user like KVM might be
> interested into leveraging this new information to optimize some of
> there secondary page table invalidation.
> 
> Here is an explaination on the rational for this patchset:
> 
> 
> CPU page table update can happens for many reasons, not only as a result
> of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> as a result of kernel activities (memory compression, reclaim, migration,
> ...).
> 
> This patch introduce a set of enums that can be associated with each of
> the events triggering a mmu notifier. Latter patches take advantages of
> those enum values.
> 
> - UNMAP: munmap() or mremap()
> - CLEAR: page table is cleared (migration, compaction, reclaim, ...)
> - PROTECTION_VMA: change in access protections for the range
> - PROTECTION_PAGE: change in access protections for page in the range
> - SOFT_DIRTY: soft dirtyness tracking
> 
> Being able to identify munmap() and mremap() from other reasons why the
> page table is cleared is important to allow user of mmu notifier to
> update their own internal tracking structure accordingly (on munmap or
> mremap it is not longer needed to track range of virtual address as it
> becomes invalid).
> 
> [1] 
> https://www.ozlabs.org/~akpm/mmotm/broken-out/mm-mmu_notifier-contextual-information-for-event-triggering-invalidation-v2.patch
> 
> Cc: Christian König 
> Cc: Jan Kara 
> Cc: Felix Kuehling 
> Cc: Jason Gunthorpe 
> Cc: Andrew Morton 
> Cc: Matthew Wilcox 
> Cc: Ross Zwisler 
> Cc: Dan Williams 
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Michal Hocko 
> Cc: Ralph Campbell 
> Cc: John Hubbard 
> Cc: k...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-r...@vger.kernel.org
> Cc: linux-fsde...@vger.kernel.org
> Cc: Arnd Bergmann 
> 
> Jérôme Glisse (9):
>   mm/mmu_notifier: contextual information for event enums
>   mm/mmu_notifier: contextual information for event triggering
> invalidation
>   mm/mmu_notifier: use correct mmu_notifier events for each invalidation
>   mm/mmu_notifier: pass down vma and reasons why mmu notifier is
> happening
>   mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper
>   gpu/drm/radeon: optimize out the case when a range is updated to read
> only
>   gpu/drm/amdgpu: optimize out the case when a range is updated to read
> only
>   gpu/drm/i915: optimize out the case when a range is updated to read
> only
>   RDMA/umem_odp: optimize out the case when a range is updated to read
> only
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  | 13 
>  drivers/gpu/drm/i915/i915_gem_userptr.c | 16 ++
>  drivers/gpu/drm/radeon/radeon_mn.c  | 13 
>  drivers/infiniband/core/umem_odp.c  | 22 +++--
>  fs/

[Bug 109403] amdgpu randomly hangs while streaming or when CPU is busy on X399 with TR 1950X

[bugzilla-daemon]

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

--- Comment #3 from Andrey Grodzovsky  ---
Hey, can you check if adding amdgpu.vm_debug=1 makes the VMC page faults 
disappear ?

Regarding  the hang you see while doing GPU reset - please provide dmesg for
this but with command line parameter of drm.debug=0xff  - you also probably
should open another ticket for this specific issue.

-- 
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] dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU

[Neil Armstrong]

On 31/01/2019 14:29, Neil Armstrong wrote:
> Add the bindings for the Bifrost family of ARM Mali GPUs.
> 
> The Bifrost GPU architecture is similar to the Midgard family,
> but with a different Shader Core & Execution Engine structures.
> 
> Bindings are based on the Midgard family bindings, but the inner
> architectural changes makes it a separate family needing separate
> bindings.
> 
> The Bifrost GPUs are present in a number of recent SoCs, like the
> Amlogic G12A Family, and many other vendors.
> The Amlogic vendor specific compatible is added to handle the
> specific IP integration differences and dependencies.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../bindings/gpu/arm,mali-bifrost.txt | 94 +++
>  1 file changed, 94 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt 
> b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
> new file mode 100644
> index ..a632f5136b08
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
> @@ -0,0 +1,94 @@
> +ARM Mali Bifrost GPU
> +
> +
> +Required properties:
> +
> +- compatible :
> +  * Must contain one of the following:
> ++ "arm,mali-g71"
> ++ "arm,mali-g51"
> ++ "arm,mali-g72"
> ++ "arm,mali-g76"

Wrong order and forgot the G31 and G52 cores.

Neil

> +  * which must be preceded by one of the following vendor specifics:
> ++ "amlogic,meson-g12a-mali"
> +
> +- reg : Physical base address of the device and length of the register area.
> +
> +- interrupts : Contains the three IRQ lines required by Mali Bifrost devices.
> +
> +- interrupt-names : Contains the names of IRQ resources in the order they 
> were
> +  provided in the interrupts property. Must contain: "job", "mmu", "gpu".
> +
> +
> +Optional properties:
> +
> +- clocks : Phandle to clock for the Mali Bifrost device.
> +
> +- mali-supply : Phandle to regulator for the Mali device. Refer to
> +  Documentation/devicetree/bindings/regulator/regulator.txt for details.
> +
> +- operating-points-v2 : Refer to 
> Documentation/devicetree/bindings/opp/opp.txt
> +  for details.
> +
> +- resets : Phandle of the GPU reset line.
> +
> +Vendor-specific bindings
> +
> +
> +The Mali GPU is integrated very differently from one SoC to
> +another. In order to accomodate those differences, you have the option
> +to specify one more vendor-specific compatible, among:
> +
> +- "amlogic,meson-g12a-mali"
> +  Required properties:
> +  - resets : Should contain phandles of :
> ++ GPU reset line
> ++ GPU APB glue reset line
> +
> +Example for a Mali-G71:
> +
> +gpu@ffa3 {
> + compatible = "amlogic,meson-g12a-mali", "arm,mali-g71";


It's a typo, it's a G31 on Amlogic G12A, anyway the example is still valid.

> + reg = <0xffe4 0x1>;
> + interrupts = ,
> +  ,
> +  ;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&clk CLKID_MALI>;
> + mali-supply = <&vdd_gpu>;
> + operating-points-v2 = <&gpu_opp_table>;
> + resets = <&reset RESET_DVALIN_CAPB3>, <&reset RESET_DVALIN>;
> +};
> +
> +gpu_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> + opp@53300 {
> + opp-hz = /bits/ 64 <53300>;
> + opp-microvolt = <125>;
> + };
> + opp@45000 {
> + opp-hz = /bits/ 64 <45000>;
> + opp-microvolt = <115>;
> + };
> + opp@4 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <1125000>;
> + };
> + opp@35000 {
> + opp-hz = /bits/ 64 <35000>;
> + opp-microvolt = <1075000>;
> + };
> + opp@26600 {
> + opp-hz = /bits/ 64 <26600>;
> + opp-microvolt = <1025000>;
> + };
> + opp@16000 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <925000>;
> + };
> + opp@1 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <912500>;
> + };
> +};
> 

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

Re: [PATCH 0/8] drm/meson: Add support for HDMI2.0 4k60

[Neil Armstrong]

On 31/01/2019 15:13, Andrzej Hajda wrote:
> On 31.01.2019 14:25, Neil Armstrong wrote:
>> Hi Andrzej, Laurent,
>>
>> On 15/01/2019 13:33, Neil Armstrong wrote:
>>> This patchset aims to add support for the following HDMI2.0 4k60 modes:
>>> - 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for 
>>> RGB/YUV4:4:4
>>> - 297MHz TMDS frequency with YUV4:2:0 encoding
>>>
>>> The first mode uses the SCDC helpers introduced by intel to :
>>> - discover where the monitor support SCDC
>>> - setup the SCDC parameters
>>> This is implemented in the dw-hdmi bridge driver by handling scrambling
>>> support during the bridge setup and by exporting an helper for the PHY
>>> setup to setup the SCDC configuration for the 1/40 TMDS rate.
>>> This code will only be active if the encoder support a TMDS rate > 340MHz.
>>>
>>> This patch could eventually break support on different SoC when connected
>>> on a 4k60 monitor with SCDC :
>>> - i.MX correctly discards pixel clocks > 216MHz
>>> - R-CAR discards discards pixel clocks > 297MHz since [1]
>>> - Rockchip discards invalid pixel clocks not in the rockchip_mpll_cfg table
>>> - sun8i correctly discards pixel clocks > 297MHz on a83t
>>> - sun8i discards discards pixel clocks > 594Mhz on h6, which is already 
>>> broken
>>>
>>> First patch should fix support for Allwinner H6.
>>>
>>> The second mode is implemented by added the missing 4:2:0 bypass handling
>>> in the dw-hdmi bridge driver and adding a "mtmdsclock" separating the
>>> pixel clock from the tmds clock in the mode setup phase.
>>> We also enable support for these modes in the connector only if the platform
>>> glue code explicits the support.
>> Do you think patches 1-4 could be applied ?
> 
> 
> For me they are OK.
> 
> Should I take them via drm-misc?

OK for me !

Neil

> 
> 
>>
>> Then we could focus on how we manage the bus format between the encoder
>> and the bridge ?
>>
>> Especially patch 5 linked to patch 7.
>>
>> Will one of you be at FOSDEM 2019 ? we could chat about this.
> 
> 
> Nope.
> 
> 
> Regards
> 
> Andrzej
> 
> 
>>
>> Following subjects on the table will be :
>> - HDR metadata transmission aligned with the last patchset sent by intel-gfx
>> - Colorspace connector property aligned with the last patchset sent by 
>> intel-gfx
>> - HDCP 1.4 and 2.2 handling
>>
>> Neil
>>
>>> Only the meson DRM dw_hdmi glue allows ycbcr420 modes, so no breakage
>>> is expected here.
>>>
>>> The remaining patches adds support for :
>>> - 1/40 TMDS rate aka DIV40 in the dw-hdmi meson PHY setup
>>> - 4:2:0 output and clock setup
>>>
>>> The dw-hdmi support re-uses the support done by Rockchip engineers on the
>>> Linux 4.4 BSP kernel.
>>>
>>> These modes has been validated using a MuxLab HDMI Signal Analyser in
>>> addition to different UHD TVs supporting full 4k60 or the 4:2:0 variant.
>>>
>>> Changes since RFC v2 at [3]:
>>> - Collected tested-by and reviewed-by tags
>>> - Changed if condition in "add HDMI div40 TMDS mode"
>>> - Updated "Add YUV420 output support" with the same if condition
>>>
>>> Changes since RFC v1 at [2]:
>>> - Fix all comments from Laurent :
>>> - Add define for HDMI 1.4 max tmds clock and SCDC supported version
>>> - Call dw_hdmi_set_high_tmds_clock_ratio() in dw_hdmi_phy_enable_powerdown()
>>> to unbreak Allwinner H6
>>> - Pass in_t(u8, bytes, SCDC_MIN_SOURCE_VERSION) as SCDC version
>>> - Finally add comments for SCDC and Scrambling process
>>>
>>> [1] https://patchwork.freedesktop.org/patch/263616/
>>> [2] https://patchwork.freedesktop.org/series/52950/#rev1
>>> [3] https://patchwork.freedesktop.org/series/52950/#rev2
>>>
>>> Neil Armstrong (7):
>>>   drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
>>>   drm/meson: add HDMI div40 TMDS mode
>>>   drm/meson: add support for HDMI2.0 2160p modes
>>>   drm/bridge: dw-hdmi: add support for YUV420 output
>>>   drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a
>>>   drm/meson: Add YUV420 output support
>>>   drm/meson: Output in YUV444 if sink supports it
>>>
>>> Zheng Yang (1):
>>>   drm/bridge: dw-hdmi: support dynamically get input/out color info
>>>
>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 182 +++---
>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |   1 +
>>>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 128 ---
>>>  drivers/gpu/drm/meson/meson_vclk.c|  93 ---
>>>  drivers/gpu/drm/meson/meson_vclk.h|   7 +-
>>>  drivers/gpu/drm/meson/meson_venc.c|   8 +-
>>>  drivers/gpu/drm/meson/meson_venc.h|  11 ++
>>>  drivers/gpu/drm/meson/meson_venc_cvbs.c   |   3 +-
>>>  include/drm/bridge/dw_hdmi.h  |   7 +
>>>  9 files changed, 374 insertions(+), 66 deletions(-)
>>>
>>
>>
> 
> ___
> 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

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Jerome Glisse]

On Thu, Jan 31, 2019 at 09:13:55AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote:
> > > *shrug* so what if the special GUP called a VMA op instead of
> > > traversing the VMA PTEs today? Why does it really matter? It could
> > > easily change to a struct page flow tomorrow..
> > 
> > Well it's so that it's composable. We want the SGL->DMA side to work for
> > APIs from kernel space and not have to run a completely different flow
> > for kernel drivers than from userspace memory.
> 
> Yes, I think that is the important point.
> 
> All the other struct page discussion is not about anyone of us wanting
> struct page - heck it is a pain to deal with, but then again it is
> there for a reason.
> 
> In the typical GUP flows we have three uses of a struct page:

We do not want GUP. Yes some RDMA driver and other use GUP but they
should only use GUP on regular vma not on special vma (ie mmap of a
device file). Allowing GUP on those is insane. It is better to special
case the peer to peer mapping because _it is_ special, nothing inside
those are manage by core mm and driver can deal with them in weird
way (GPU certainly do and for very good reasons without which they
would perform badly).

> 
>  (1) to carry a physical address.  This is mostly through
>  struct scatterlist and struct bio_vec.  We could just store
>  a magic PFN-like value that encodes the physical address
>  and allow looking up a page if it exists, and we had at least
>  two attempts at it.  In some way I think that would actually
>  make the interfaces cleaner, but Linus has NACKed it in the
>  past, so we'll have to convince him first that this is the
>  way forward

Wasting 64bytes just to carry address is a waste for everyone.

>  (2) to keep a reference to the memory so that it doesn't go away
>  under us due to swapping, process exit, unmapping, etc.
>  No idea how we want to solve this, but I guess you have
>  some smart ideas?

The DMA API has _never_ dealt with page refcount and it have always
been up to the user of the DMA API to ascertain that it is safe for
them to map/unmap page/resource they are providing to the DMA API.

The lifetime management of page or resource provided to the DMA API
should remain the problem of the caller and not be something the DMA
API cares one bit about.

>  (3) to make the PTEs dirty after writing to them.  Again no sure
>  what our preferred interface here would be

Again the DMA API has never dealt with that nor should he. What does
dirty pte means for a special mapping (mmap of device file) ? There is
no single common definition for that, most driver do not care about it
and it get fully ignore.

> 
> If we solve all of the above problems I'd be more than happy to
> go with a non-struct page based interface for BAR P2P.  But we'll
> have to solve these issues in a generic way first.

None of the above are problems the DMA API need to solve. The DMA API
is about mapping some memory resource to a device. For regular main
memory it is easy on most architecture (anything with a sane IOMMU).
For IO resources it is not as straight forward as it was often left
undefined in the architecture platform documentation or the inter-
connect standard. AFAIK mapping BAR from one PCIE device to another
through IOMMU works well on recent Intel and AMD platform. We will
probably need to use some whitelist at i am not sure this is something
Intel or AMD guarantee, i believe they want to start guaranteeing it.

So having one DMA API for regular memory and one for IO memory aka
resource (dma_map_resource()) sounds like the only sane approach here.
It is fundamentally different memory and we should not try to muddle
the water by having it go through a single common API. There is no
benefit to that beside saving couple hundred of lines of code to some
driver and this couple hundred lines of code can be move to a common
helpers.

So to me it is lot sane to provide an helper that would deal with
the different vma type on behalf of device than forcing down struct
page. Something like:

vma_dma_map_range(vma, device, start, end, flags, pa[])
vma_dma_unmap_range(vma, device, start, end, flags, pa[])

VMA_DMA_MAP_FLAG_WRITE
VMA_DMA_MAP_FLAG_PIN

Which would use GUP or special vma handling on behalf of the calling
device or use a special p2p code path for special vma. Device that
need pinning set the flag and it is up to the exporting device to
accept or not. Pinning when using GUP is obvious.

When the vma goes away the importing device must update its device
page table to some dummy page or do something sane, because keeping
things map after that point does not make sense anymore. Device is
no longer operating on a range of virtual address that make sense.

So instead of pushing p2p handling within GUP to not disrupt existing
driver workflow. It is better to provide an helper that handle all
the gory details for the device driver. It doe

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Jerome Glisse]

On Thu, Jan 31, 2019 at 09:05:01AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 08:44:20PM +, Jason Gunthorpe wrote:
> > Not really, for MRs most drivers care about DMA addresses only. The
> > only reason struct page ever gets involved is because it is part of
> > the GUP, SGL and dma_map family of APIs.
> 
> And the only way you get the DMA address is through the dma mapping
> APIs.  Which except for the little oddball dma_map_resource expect
> a struct page in some form.  And dma_map_resource isn't really up
> to speed for full blown P2P.
> 
> Now we could and maybe eventually should change all this.  But that
> is a pre-requisitive for doing anything more fancy, and not something
> to be hacked around.
> 
> > O_DIRECT seems to be the justification for struct page, but nobody is
> > signing up to make O_DIRECT have the required special GUP/SGL/P2P flow
> > that would be needed to *actually* make that work - so it really isn't
> > a justification today.
> 
> O_DIRECT is just the messenger.  Anything using GUP will need a struct
> page, which is all our interfaces that do I/O directly to user pages.

I do not want to allow GUP to pin I/O space this would open a pandora
box that we do not want to open at all. Many driver manage their IO
space and if they get random pinning because some other kernel bits
they never heard of starts to do GUP on their stuff it is gonna cause
havoc.

So far mmap of device file have always been special and it has been
reflected to userspace in all the instance i know of (media and GPU).
Pretending we can handle them like any other vma is a lie because
they were never designed that way in the first place and it would be
disruptive to all those driver.

Minimum disruption with minimun changes is what we should aim for and
is what i am trying to do with this patchset. Using struct page and
allowing GUP would mean rewritting huge chunk of GPU drivers (pretty
much rewritting their whole memory management) with no benefit at the
end.

When something is special it is better to leave it that way.

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Jerome Glisse]

On Thu, Jan 31, 2019 at 09:02:03AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 01:50:27PM -0500, Jerome Glisse wrote:
> > I do not see how VMA changes are any different than using struct page
> > in respect to userspace exposure. Those vma callback do not need to be
> > set by everyone, in fact expectation is that only handful of driver
> > will set those.
> > 
> > How can we do p2p between RDMA and GPU for instance, without exposure
> > to userspace ? At some point you need to tell userspace hey this kernel
> > does allow you to do that :)
> 
> To do RDMA on a memory region you need struct page backіng to start
> with..

No you do not with this patchset and there is no reason to tie RDMA to
struct page it does not provide a single feature we would need. So as
it can be done without and they are not benefit of using one i do not
see why we should use one.

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] components: multiple components for a device

[Daniel Vetter]

Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.

We are introducing this, as I915 needs two different components
with different subcomponent value, which will be matched to two
different component masters(Audio and HDCP) based on the subcomponent
values.

v2: Add documenation.

Signed-off-by: Daniel Vetter  (v1 code)
Signed-off-by: Ramalingam C  (v1 commit message)
Cc: Ramalingam C 
Cc: Greg Kroah-Hartman 
Cc: Russell King 
Cc: Rafael J. Wysocki 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Signed-off-by: Daniel Vetter 
---
 drivers/base/component.c  | 159 +-
 include/linux/component.h |  10 ++-
 2 files changed, 130 insertions(+), 39 deletions(-)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index e5b04bce8544..eb7915fc5278 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -48,6 +48,7 @@ struct component;
 struct component_match_array {
void *data;
int (*compare)(struct device *, void *);
+   int (*compare_typed)(struct device *, int, void *);
void (*release)(struct device *, void *);
struct component *component;
bool duplicate;
@@ -75,6 +76,7 @@ struct component {
bool bound;
 
const struct component_ops *ops;
+   int subcomponent;
struct device *dev;
 };
 
@@ -159,7 +161,7 @@ static struct master *__master_find(struct device *dev,
 }
 
 static struct component *find_component(struct master *master,
-   int (*compare)(struct device *, void *), void *compare_data)
+   struct component_match_array *mc)
 {
struct component *c;
 
@@ -167,8 +169,13 @@ static struct component *find_component(struct master 
*master,
if (c->master && c->master != master)
continue;
 
-   if (compare(c->dev, compare_data))
+   if (mc->compare_typed) {
+   if (mc->compare_typed(c->dev, c->subcomponent,
+ mc->data))
+   return c;
+   } else if (mc->compare(c->dev, mc->data)) {
return c;
+   }
}
 
return NULL;
@@ -193,7 +200,7 @@ static int find_components(struct master *master)
if (match->compare[i].component)
continue;
 
-   c = find_component(master, mc->compare, mc->data);
+   c = find_component(master, mc);
if (!c) {
ret = -ENXIO;
break;
@@ -328,29 +335,12 @@ static int component_match_realloc(struct device *dev,
return 0;
 }
 
-/**
- * component_match_add_release - add a compent match with release callback
- * @master: device with the aggregate driver
- * @matchptr: pointer to the list of component matches
- * @release: release function for @compare_data
- * @compare: compare function to match against all components
- * @compare_data: opaque pointer passed to the @compare function
- *
- * This adds a new component match to the list stored in @matchptr, which the
- * @master aggregate driver needs to function. @matchptr must be initialized to
- * NULL before adding the first match.
- *
- * The allocated match list in @matchptr is automatically released using devm
- * actions. At that point @release will be called, to free any references held
- * by @compare_data, e.g. when @compare_data is a &device_node that must be
- * released with of_node_put().
- *
- * See also component_match_add().
- */
-void component_match_add_release(struct device *master,
+static void __component_match_add(struct device *master,
struct component_match **matchptr,
void (*release)(struct device *, void *),
-   int (*compare)(struct device *, void *), void *compare_data)
+   int (*compare)(struct device *, void *),
+   int (*compare_typed)(struct device *, int, void *),
+   void *compare_data)
 {
struct component_match *match = *matchptr;
 
@@ -382,13 +372,69 @@ void component_match_add_release(struct device *master,
}
 
match->compare[match->num].compare = compare;
+   match->compare[match->num].compare_typed = compare_typed;
match->compare[match->num].release = release;
match->compare[match->num].data = compare_data;
match->compare[match->num].component = NULL;
match->num++;
 }
+
+/**
+ * component_match_add_release - add a compent match with release callback
+ * @master: device with the aggregate driver
+ * @matchptr: pointer to the list of component matches
+ * @release: release function for @compare_data
+ * @compare: compare function to match against all components
+ * @compare_data: opaque pointer passed to the @compare function
+ *
+ * This adds a new component match to the list stored in @matchptr, whi

[PATCH 1/2] component: Add documentation

[Daniel Vetter]

Someone owes me a beer ...

While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
  component/puppetmaster or something like that. At least to my
  English ear "aggregate" emphasizes much more the "assemble a pile of
  things into something bigger" aspect, and there's not really much
  of a control hierarchy between aggregate and constituing components.

But that's way more than a quick doc typing exercise ...

Thanks to Ram for commenting on an initial draft of these docs.

Cc: "C, Ramalingam" 
Cc: Greg Kroah-Hartman 
Cc: Russell King 
Cc: Rafael J. Wysocki 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Signed-off-by: Daniel Vetter 
---
 Documentation/driver-api/device_link.rst |   3 +
 Documentation/driver-api/index.rst   |   1 +
 drivers/base/component.c | 107 ++-
 include/linux/component.h|  70 +++
 4 files changed, 178 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/device_link.rst 
b/Documentation/driver-api/device_link.rst
index d6763272e747..2d5919b2b337 100644
--- a/Documentation/driver-api/device_link.rst
+++ b/Documentation/driver-api/device_link.rst
@@ -1,6 +1,9 @@
 .. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain 
`
 .. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain 
`
 
+
+.. _device_link:
+
 
 Device links
 
diff --git a/Documentation/driver-api/index.rst 
b/Documentation/driver-api/index.rst
index ab38ced66a44..c0b600ed9961 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -22,6 +22,7 @@ available subsections can be seen below.
device_connection
dma-buf
device_link
+   component
message-based
sound
frame-buffer
diff --git a/drivers/base/component.c b/drivers/base/component.c
index ddcea8739c12..e5b04bce8544 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -16,6 +16,33 @@
 #include 
 #include 
 
+/**
+ * DOC: overview
+ *
+ * The component frameworks allows drivers to collect a pile of sub-devices,
+ * including their bound drivers, into an aggregate driver. Various subsystem
+ * already provide functions to get hold of such components, e.g.
+ * of_clk_get_by_name(). Anytime there's such a subsystem specific way to find 
a
+ * a device the component framework should not be used. The component framework
+ * fills the niche of aggregate drivers for specific hardware, where further
+ * standardization into a subsystem doesn't make sense. The common example is
+ * when a logical device (e.g. a DRM display driver) is spread around the SoC 
on
+ * various component (scanout engines, blending blocks, transcoders for various
+ * outputs and so on).
+ *
+ * The component framework also doesn't solve runtime dependencies, e.g. for
+ * system suspend and resume operations. See also :ref:`device
+ * links`.
+ *
+ * Components are registered using component_add() and unregistered with
+ * component_del(), usually from the driver's probe and disconnect functions.
+ *
+ * Aggregate drivers first assemble a component match list of what they need
+ * using component_match_add(). This is then registered as an aggregate driver
+ * using component_master_add_with_match(), and unregistered using
+ * component_master_del().
+ */
+
 struct component;
 
 struct component_match_array {
@@ -301,10 +328,24 @@ static int component_match_realloc(struct device *dev,
return 0;
 }
 
-/*
- * Add a component to be matched, with a release function.
+/**
+ * component_match_add_release - add a compent match with release callback
+ * @master: device with the aggregate driver
+ * @matchptr: pointer to the list of component matches
+ * @release: release function for @compare_data
+ * @compare: compare function to match against all components
+ * @compare_data: opaque pointer passed to the @compare function
+ *
+ * This adds a new component match to the list stored in @matchptr, which the
+ * @master aggregate driver needs to function. @matchptr must be initialized to
+ * NULL before adding the first match.
+ *
+ * The allocated match list in @matchptr is automatically released using devm
+ * actions. At that point @release will be called, to free any references held
+ * by @compare_data, e.g. when @compare_data is a &device_node that must be
+ * released with of_node_put().
  *
- * The match array is first created or extended if necessary.
+ * See also component_match_add().
  */
 void component_match_add_release(struct device *master,
struct component_match **matchptr,
@@ -367,6 +408,18 @@ static void free_master(struct master *master)
kfree(master);
 }
 
+/**
+ * component_master_add_with_match - register an aggregate driver
+ * @dev: device with the aggregate driver
+ * @ops: callbacks for the aggregate driver
+ * @match: com

Re: [PATCH 0/8] drm/meson: Add support for HDMI2.0 4k60

[Andrzej Hajda]

On 31.01.2019 14:25, Neil Armstrong wrote:
> Hi Andrzej, Laurent,
>
> On 15/01/2019 13:33, Neil Armstrong wrote:
>> This patchset aims to add support for the following HDMI2.0 4k60 modes:
>> - 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4
>> - 297MHz TMDS frequency with YUV4:2:0 encoding
>>
>> The first mode uses the SCDC helpers introduced by intel to :
>> - discover where the monitor support SCDC
>> - setup the SCDC parameters
>> This is implemented in the dw-hdmi bridge driver by handling scrambling
>> support during the bridge setup and by exporting an helper for the PHY
>> setup to setup the SCDC configuration for the 1/40 TMDS rate.
>> This code will only be active if the encoder support a TMDS rate > 340MHz.
>>
>> This patch could eventually break support on different SoC when connected
>> on a 4k60 monitor with SCDC :
>> - i.MX correctly discards pixel clocks > 216MHz
>> - R-CAR discards discards pixel clocks > 297MHz since [1]
>> - Rockchip discards invalid pixel clocks not in the rockchip_mpll_cfg table
>> - sun8i correctly discards pixel clocks > 297MHz on a83t
>> - sun8i discards discards pixel clocks > 594Mhz on h6, which is already 
>> broken
>>
>> First patch should fix support for Allwinner H6.
>>
>> The second mode is implemented by added the missing 4:2:0 bypass handling
>> in the dw-hdmi bridge driver and adding a "mtmdsclock" separating the
>> pixel clock from the tmds clock in the mode setup phase.
>> We also enable support for these modes in the connector only if the platform
>> glue code explicits the support.
> Do you think patches 1-4 could be applied ?


For me they are OK.

Should I take them via drm-misc?


>
> Then we could focus on how we manage the bus format between the encoder
> and the bridge ?
>
> Especially patch 5 linked to patch 7.
>
> Will one of you be at FOSDEM 2019 ? we could chat about this.


Nope.


Regards

Andrzej


>
> Following subjects on the table will be :
> - HDR metadata transmission aligned with the last patchset sent by intel-gfx
> - Colorspace connector property aligned with the last patchset sent by 
> intel-gfx
> - HDCP 1.4 and 2.2 handling
>
> Neil
>
>> Only the meson DRM dw_hdmi glue allows ycbcr420 modes, so no breakage
>> is expected here.
>>
>> The remaining patches adds support for :
>> - 1/40 TMDS rate aka DIV40 in the dw-hdmi meson PHY setup
>> - 4:2:0 output and clock setup
>>
>> The dw-hdmi support re-uses the support done by Rockchip engineers on the
>> Linux 4.4 BSP kernel.
>>
>> These modes has been validated using a MuxLab HDMI Signal Analyser in
>> addition to different UHD TVs supporting full 4k60 or the 4:2:0 variant.
>>
>> Changes since RFC v2 at [3]:
>> - Collected tested-by and reviewed-by tags
>> - Changed if condition in "add HDMI div40 TMDS mode"
>> - Updated "Add YUV420 output support" with the same if condition
>>
>> Changes since RFC v1 at [2]:
>> - Fix all comments from Laurent :
>> - Add define for HDMI 1.4 max tmds clock and SCDC supported version
>> - Call dw_hdmi_set_high_tmds_clock_ratio() in dw_hdmi_phy_enable_powerdown()
>> to unbreak Allwinner H6
>> - Pass in_t(u8, bytes, SCDC_MIN_SOURCE_VERSION) as SCDC version
>> - Finally add comments for SCDC and Scrambling process
>>
>> [1] https://patchwork.freedesktop.org/patch/263616/
>> [2] https://patchwork.freedesktop.org/series/52950/#rev1
>> [3] https://patchwork.freedesktop.org/series/52950/#rev2
>>
>> Neil Armstrong (7):
>>   drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
>>   drm/meson: add HDMI div40 TMDS mode
>>   drm/meson: add support for HDMI2.0 2160p modes
>>   drm/bridge: dw-hdmi: add support for YUV420 output
>>   drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a
>>   drm/meson: Add YUV420 output support
>>   drm/meson: Output in YUV444 if sink supports it
>>
>> Zheng Yang (1):
>>   drm/bridge: dw-hdmi: support dynamically get input/out color info
>>
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 182 +++---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |   1 +
>>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 128 ---
>>  drivers/gpu/drm/meson/meson_vclk.c|  93 ---
>>  drivers/gpu/drm/meson/meson_vclk.h|   7 +-
>>  drivers/gpu/drm/meson/meson_venc.c|   8 +-
>>  drivers/gpu/drm/meson/meson_venc.h|  11 ++
>>  drivers/gpu/drm/meson/meson_venc_cvbs.c   |   3 +-
>>  include/drm/bridge/dw_hdmi.h  |   7 +
>>  9 files changed, 374 insertions(+), 66 deletions(-)
>>
>
>

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

Re: [PATCH v10 07/40] drm/i915: hdcp1.4 CP_IRQ handling and SW encryption tracking

[C, Ramalingam]

On 1/31/2019 1:26 PM, Daniel Vetter wrote:

On Thu, Jan 31, 2019 at 12:29:23PM +0530, Ramalingam C wrote:

"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.

On CP_IRQ we filter the CP_IRQ related to the states like Link failure
and reauthentication req etc and handle them in hdcp_check_link.
CP_IRQ corresponding to the authentication msg availability are ignored.

WARN_ON is added for the abrupt stop of HDCP encryption of a port.

v2:
   bool is used in struct for the cleaner coding. [Daniel]
   check_link work_fn is scheduled for cp_irq handling [Daniel]

Just doing a delta-review, v2 addresses my comment about synchronization
with the worker, so

Reviewed-by: Daniel Vetter 

Thank you.

--Ram



Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/i915/intel_dp.c   |  2 +-
  drivers/gpu/drm/i915/intel_drv.h  |  5 ++-
  drivers/gpu/drm/i915/intel_hdcp.c | 73 ---
  3 files changed, 58 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 815ee68efa2f..9ce05819fc11 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4776,7 +4776,7 @@ static void intel_dp_check_service_irq(struct intel_dp 
*intel_dp)
intel_dp_handle_test_request(intel_dp);
  
  	if (val & DP_CP_IRQ)

-   intel_hdcp_check_link(intel_dp->attached_connector);
+   intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
  
  	if (val & DP_SINK_SPECIFIC_IRQ)

DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 63e009286d5f..13a41e8cf4ff 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -399,6 +399,9 @@ struct intel_hdcp {
struct delayed_work check_work;
struct work_struct prop_work;
  
+	/* HDCP1.4 Encryption status */

+   bool hdcp_encrypted;
+
/* HDCP2.2 related definitions */
/* Flag indicates whether this connector supports HDCP2.2 or not. */
bool hdcp2_supported;
@@ -2073,10 +2076,10 @@ int intel_hdcp_init(struct intel_connector *connector,
bool hdcp2_supported);
  int intel_hdcp_enable(struct intel_connector *connector);
  int intel_hdcp_disable(struct intel_connector *connector);
-int intel_hdcp_check_link(struct intel_connector *connector);
  bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
  bool intel_hdcp_capable(struct intel_connector *connector);
  bool is_hdcp2_supported(struct drm_i915_private *dev_priv);
+void intel_hdcp_handle_cp_irq(struct intel_connector *connector);
  
  /* intel_psr.c */

  #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index e0bb5f32ba90..c1b057f1501b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -74,6 +74,16 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
  }
  
+static inline bool intel_hdcp_in_use(struct intel_connector *connector)

+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   enum port port = connector->encoder->port;
+   u32 reg;
+
+   reg = I915_READ(PORT_HDCP_STATUS(port));
+   return reg & HDCP_STATUS_ENC;
+}
+
  static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
  {
@@ -668,6 +678,7 @@ static int _intel_hdcp_disable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being disabled...\n",
  connector->base.name, connector->base.base.id);
  
+	hdcp->hdcp_encrypted = false;

I915_WRITE(PORT_HDCP_CONF(port), 0);
if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
@@ -713,8 +724,10 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
-   if (!ret)
+   if (!ret) {
+   hdcp->hdcp_encrypted = true;
return 0;
+   }
  
  		DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
  
@@ -741,16 +754,17 @@ int intel_hdcp_check_link(struct intel_connector *connector)

enum port port = intel_dig_port->base.port;
int ret = 0;
  
-	if (!hdcp->shim)

-   return -ENOENT;
-
mutex_lock(&hdcp->mutex);
  
-	if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)

+   /* Check_link valid only wh

Re: [PATCH v10 06/40] drm/i915: MEI interface definition

[C, Ramalingam]

On 1/31/2019 1:47 PM, Daniel Vetter wrote:

On Thu, Jan 31, 2019 at 12:29:22PM +0530, Ramalingam C wrote:

Defining the mei-i915 interface functions and initialization of
the interface.

v2:
   Adjust to the new interface changes. [Tomas]
   Added further debug logs for the failures at MEI i/f.
   port in hdcp_port data is equipped to handle -ve values.
v3:
   mei comp is matched for global i915 comp master. [Daniel]
   In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
   mei wrappers are adjusted as per the i/f change [Daniel]
v4:
   port initialization is done only at hdcp2_init only [Danvet]
v5:
   I915 registers a subcomponent to be matched with mei_hdcp [Daniel]

Signed-off-by: Ramalingam C 
Reviewed-by: Daniel Vetter 

When you make substantial changes to a patch (like here) and decide to
keep the r-b, then please indicate that it was for an earlier version. I
most definitely didn't review this one that re-adds all the locking :-)

sure :)


What's missing here is the component_del. Not exactly sure why this
doesn't blow up.
That is weird. But yes note the absence of _del. I will introduce the 
the call to hdcp_exit at unload and handle the component_del.

Luckily we don't need a component_del_typed because
component_del already takes the (dev, ops) pair, and that's unique.

yes true.

-Ram

-Daniel



---
  drivers/gpu/drm/i915/i915_drv.c   |   1 +
  drivers/gpu/drm/i915/i915_drv.h   |   7 +
  drivers/gpu/drm/i915/intel_drv.h  |   5 +
  drivers/gpu/drm/i915/intel_hdcp.c | 378 +-
  include/drm/i915_component.h  |   3 +
  5 files changed, 393 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7aaa1ac4c99..75aff907ba69 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -904,6 +904,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv)
mutex_init(&dev_priv->av_mutex);
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
+   mutex_init(&dev_priv->hdcp_comp_mutex);
  
  	i915_memcpy_init_early(dev_priv);

intel_runtime_pm_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 22da9df1f0a7..d9a0771af4d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "i915_fixed.h"

  #include "i915_params.h"
@@ -2043,6 +2044,12 @@ struct drm_i915_private {
  
  	struct i915_pmu pmu;
  
+	struct i915_hdcp_comp_master *hdcp_master;

+   bool hdcp_comp_added;
+
+   /* Mutex to protect the above hdcp component related values. */
+   struct mutex hdcp_comp_mutex;
+
/*
 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
 * will be rejected. Instead look for a better place.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0ac870feb5e9..63e009286d5f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,6 +41,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  struct drm_printer;

@@ -385,6 +386,9 @@ struct intel_hdcp_shim {
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
bool *hdcp_capable);
+
+   /* HDCP adaptation(DP/HDMI) required on the port */
+   enum hdcp_wired_protocol protocol;
  };
  
  struct intel_hdcp {

@@ -405,6 +409,7 @@ struct intel_hdcp {
 * content can flow only through a link protected by HDCP2.2.
 */
u8 content_type;
+   struct hdcp_port_data port_data;
  };
  
  struct intel_connector {

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 1a85dc46692d..e0bb5f32ba90 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -7,8 +7,10 @@
   */
  
  #include 

+#include 
  #include 
  #include 
+#include 
  
  #include "intel_drv.h"

  #include "i915_reg.h"
@@ -832,6 +834,348 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv, 
enum port port)
return INTEL_GEN(dev_priv) >= 9 && port < PORT_E;
  }
  
+static __attribute__((unused)) int

+hdcp2_prepare_ake_init(struct intel_connector *connector,
+  struct hdcp2_ake_init *ake_data)
+{
+   struct hdcp_port_data *data = &connector->hdcp.port_data;
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct i915_hdcp_comp_master *comp;
+   int ret;
+
+   mutex_lock(&dev_priv->hdcp_comp_mutex);
+   comp = dev_priv->hdcp_master;
+
+   if (!comp || !comp->ops) {
+   mutex_unlock(&dev_priv->hdcp_comp_mutex);
+   return -EINVAL;
+   }
+
+   ret = comp->ops->initiate_hdcp2_session(comp->me

Re: [PATCH] drm/i915: Enable fastboot by default on VLV and CHV

[Maarten Lankhorst]

Op 29-01-2019 om 15:22 schreef Hans de Goede:
> We really want to have fastboot enabled by default to avoid an ugly
> modeset during boot.
>
> Currently we are enabling fastboot by default on gen9+ (Skylake and newer).
> The intention is to enable it on older generations after it has seen more
> testing on gen9+.
>
> VLV and CHV devices are still being sold in stores today, as such it is
> desirable to also enable fastboot by default on these now.
>
> I've extensively tested fastboot=1 support on over 50 different
> Bay- and Cherry-Trail devices. Testing DSI and eDP panels as well as
> HDMI output (and even DP over Type-C on one device).
>
> All 50 devices work fine with fastboot=1. On 2 devices their DSI panel
> turns black as soon as the i915 driver loads when fastboot=0, so having
> fastboot enabled is required for these 2 to work properly (for lack of
> a better fix).
>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d756d7358292..0ff42a38023c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11672,7 +11672,15 @@ static bool fastboot_enabled(struct drm_i915_private 
> *dev_priv)
>   return i915_modparams.fastboot;
>  
>   /* Enable fastboot by default on Skylake and newer */
> - return INTEL_GEN(dev_priv) >= 9;
> + if (INTEL_GEN(dev_priv) >= 9)
> + return true;
> +
> + /* Enable fastboot by default on VLV and CHV */
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + return true;
> +
> + /* Disabled by default on all others */
> + return false;
>  }
>  
>  static bool

Reviewed-by: Maarten Lankhorst 

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

[PATCH] dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU

[Neil Armstrong]

Add the bindings for the Bifrost family of ARM Mali GPUs.

The Bifrost GPU architecture is similar to the Midgard family,
but with a different Shader Core & Execution Engine structures.

Bindings are based on the Midgard family bindings, but the inner
architectural changes makes it a separate family needing separate
bindings.

The Bifrost GPUs are present in a number of recent SoCs, like the
Amlogic G12A Family, and many other vendors.
The Amlogic vendor specific compatible is added to handle the
specific IP integration differences and dependencies.

Signed-off-by: Neil Armstrong 
---
 .../bindings/gpu/arm,mali-bifrost.txt | 94 +++
 1 file changed, 94 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
new file mode 100644
index ..a632f5136b08
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
@@ -0,0 +1,94 @@
+ARM Mali Bifrost GPU
+
+
+Required properties:
+
+- compatible :
+  * Must contain one of the following:
++ "arm,mali-g71"
++ "arm,mali-g51"
++ "arm,mali-g72"
++ "arm,mali-g76"
+  * which must be preceded by one of the following vendor specifics:
++ "amlogic,meson-g12a-mali"
+
+- reg : Physical base address of the device and length of the register area.
+
+- interrupts : Contains the three IRQ lines required by Mali Bifrost devices.
+
+- interrupt-names : Contains the names of IRQ resources in the order they were
+  provided in the interrupts property. Must contain: "job", "mmu", "gpu".
+
+
+Optional properties:
+
+- clocks : Phandle to clock for the Mali Bifrost device.
+
+- mali-supply : Phandle to regulator for the Mali device. Refer to
+  Documentation/devicetree/bindings/regulator/regulator.txt for details.
+
+- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
+  for details.
+
+- resets : Phandle of the GPU reset line.
+
+Vendor-specific bindings
+
+
+The Mali GPU is integrated very differently from one SoC to
+another. In order to accomodate those differences, you have the option
+to specify one more vendor-specific compatible, among:
+
+- "amlogic,meson-g12a-mali"
+  Required properties:
+  - resets : Should contain phandles of :
++ GPU reset line
++ GPU APB glue reset line
+
+Example for a Mali-G71:
+
+gpu@ffa3 {
+   compatible = "amlogic,meson-g12a-mali", "arm,mali-g71";
+   reg = <0xffe4 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "job", "mmu", "gpu";
+   clocks = <&clk CLKID_MALI>;
+   mali-supply = <&vdd_gpu>;
+   operating-points-v2 = <&gpu_opp_table>;
+   resets = <&reset RESET_DVALIN_CAPB3>, <&reset RESET_DVALIN>;
+};
+
+gpu_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+
+   opp@53300 {
+   opp-hz = /bits/ 64 <53300>;
+   opp-microvolt = <125>;
+   };
+   opp@45000 {
+   opp-hz = /bits/ 64 <45000>;
+   opp-microvolt = <115>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <1125000>;
+   };
+   opp@35000 {
+   opp-hz = /bits/ 64 <35000>;
+   opp-microvolt = <1075000>;
+   };
+   opp@26600 {
+   opp-hz = /bits/ 64 <26600>;
+   opp-microvolt = <1025000>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   opp-microvolt = <925000>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <912500>;
+   };
+};
-- 
2.20.1

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

[PATCH] drm/sun4i: tcon: Prepare and enable TCON channel 0 clock at init

[Paul Kocialkowski]

When initializing clocks, a reference to the TCON channel 0 clock is
obtained. However, the clock is never prepared and enabled later.
Switching from simplefb to DRM actually disables the clock (that was
usually configured by U-Boot) because of that.

On the V3s, this results in a hang when writing to some mixer registers
when switching over to DRM from simplefb.

Fix this by preparing and enabling the clock when initializing other
clocks. Waiting for sun4i_tcon_channel_enable to enable the clock is
apparently too late and results in the same mixer register access hang.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e987615c16f1..b31f5d95cadb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -371,6 +371,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
return PTR_ERR(tcon->sclk0);
}
+   clk_prepare_enable(tcon->sclk0);
 
if (tcon->quirks->has_channel_1) {
tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
@@ -385,6 +386,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
 
 static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
 {
+   clk_disable_unprepare(tcon->sclk0);
clk_disable_unprepare(tcon->clk);
 }
 
-- 
2.20.1

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

Re: [PATCH 0/8] drm/meson: Add support for HDMI2.0 4k60

[Neil Armstrong]

Hi Andrzej, Laurent,

On 15/01/2019 13:33, Neil Armstrong wrote:
> This patchset aims to add support for the following HDMI2.0 4k60 modes:
> - 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4
> - 297MHz TMDS frequency with YUV4:2:0 encoding
> 
> The first mode uses the SCDC helpers introduced by intel to :
> - discover where the monitor support SCDC
> - setup the SCDC parameters
> This is implemented in the dw-hdmi bridge driver by handling scrambling
> support during the bridge setup and by exporting an helper for the PHY
> setup to setup the SCDC configuration for the 1/40 TMDS rate.
> This code will only be active if the encoder support a TMDS rate > 340MHz.
> 
> This patch could eventually break support on different SoC when connected
> on a 4k60 monitor with SCDC :
> - i.MX correctly discards pixel clocks > 216MHz
> - R-CAR discards discards pixel clocks > 297MHz since [1]
> - Rockchip discards invalid pixel clocks not in the rockchip_mpll_cfg table
> - sun8i correctly discards pixel clocks > 297MHz on a83t
> - sun8i discards discards pixel clocks > 594Mhz on h6, which is already broken
> 
> First patch should fix support for Allwinner H6.
> 
> The second mode is implemented by added the missing 4:2:0 bypass handling
> in the dw-hdmi bridge driver and adding a "mtmdsclock" separating the
> pixel clock from the tmds clock in the mode setup phase.
> We also enable support for these modes in the connector only if the platform
> glue code explicits the support.

Do you think patches 1-4 could be applied ?

Then we could focus on how we manage the bus format between the encoder
and the bridge ?

Especially patch 5 linked to patch 7.

Will one of you be at FOSDEM 2019 ? we could chat about this.

Following subjects on the table will be :
- HDR metadata transmission aligned with the last patchset sent by intel-gfx
- Colorspace connector property aligned with the last patchset sent by intel-gfx
- HDCP 1.4 and 2.2 handling

Neil

> 
> Only the meson DRM dw_hdmi glue allows ycbcr420 modes, so no breakage
> is expected here.
> 
> The remaining patches adds support for :
> - 1/40 TMDS rate aka DIV40 in the dw-hdmi meson PHY setup
> - 4:2:0 output and clock setup
> 
> The dw-hdmi support re-uses the support done by Rockchip engineers on the
> Linux 4.4 BSP kernel.
> 
> These modes has been validated using a MuxLab HDMI Signal Analyser in
> addition to different UHD TVs supporting full 4k60 or the 4:2:0 variant.
> 
> Changes since RFC v2 at [3]:
> - Collected tested-by and reviewed-by tags
> - Changed if condition in "add HDMI div40 TMDS mode"
> - Updated "Add YUV420 output support" with the same if condition
> 
> Changes since RFC v1 at [2]:
> - Fix all comments from Laurent :
> - Add define for HDMI 1.4 max tmds clock and SCDC supported version
> - Call dw_hdmi_set_high_tmds_clock_ratio() in dw_hdmi_phy_enable_powerdown()
> to unbreak Allwinner H6
> - Pass in_t(u8, bytes, SCDC_MIN_SOURCE_VERSION) as SCDC version
> - Finally add comments for SCDC and Scrambling process
> 
> [1] https://patchwork.freedesktop.org/patch/263616/
> [2] https://patchwork.freedesktop.org/series/52950/#rev1
> [3] https://patchwork.freedesktop.org/series/52950/#rev2
> 
> Neil Armstrong (7):
>   drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
>   drm/meson: add HDMI div40 TMDS mode
>   drm/meson: add support for HDMI2.0 2160p modes
>   drm/bridge: dw-hdmi: add support for YUV420 output
>   drm/bridge: dw-hdmi: allow ycbcr420 modes for >= 0x200a
>   drm/meson: Add YUV420 output support
>   drm/meson: Output in YUV444 if sink supports it
> 
> Zheng Yang (1):
>   drm/bridge: dw-hdmi: support dynamically get input/out color info
> 
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 182 +++---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |   1 +
>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 128 ---
>  drivers/gpu/drm/meson/meson_vclk.c|  93 ---
>  drivers/gpu/drm/meson/meson_vclk.h|   7 +-
>  drivers/gpu/drm/meson/meson_venc.c|   8 +-
>  drivers/gpu/drm/meson/meson_venc.h|  11 ++
>  drivers/gpu/drm/meson/meson_venc_cvbs.c   |   3 +-
>  include/drm/bridge/dw_hdmi.h  |   7 +
>  9 files changed, 374 insertions(+), 66 deletions(-)
> 

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

Re: [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues

[Boris Brezillon]

On Thu, 31 Jan 2019 13:13:22 +
Peter Rosin  wrote:

> On 2019-01-27 09:27, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 15:10:28 +
> > Peter Rosin  wrote:
> >   
> >> Hi!
> >>
> >> I found an unfortunate issue while recoding plane handling to use
> >> drm_atomic_helper_check_plane_state(). The driver rotates clockwise,
> >> which is not correct. I simply fixed it (patch 1/4), but maybe that
> >> will cause regressions for unsuspecting users who simply assumed
> >> that the clockwise rotation was correct? I don't know what to do
> >> about that? Adding an option to get the old broken behavior seems
> >> useless, wouldn't it be just as easy to just fix whatever app to
> >> rotate the other way instead of adding an option somewhere?
> >>
> >> I have only tested this series on sama5d3, but I did check the docs
> >> for various other chips (sama5d2, sama5d4, sam9n12, sam9g15, sam9g35
> >> and sam9x35) supported by the driver (relevant to patch 4/4).
> >>
> >> Cheers,
> >> Peter
> >>
> >> Peter Rosin (4):
> >>   drm/atmel-hlcdc: rotate planes counterclockwise
> >>   drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated
> >>   drm/atmel-hlcdc: fix clipping of planes  
> > 
> > Queued patches 1-3 to drm-misc-next.  
> 
> Great, thanks.
> 
> >>   drm/atmel-hlcdc: do not immediately disable planes, wait for next
> >> frame  
> > 
> > Still waiting for Nicolas feedback on this one.  
> 
> [Adding back Nicolas, he seems to have gone missing from the list
> recipients.]
> 
> I have done some testing of that patch and for me it's a definite
> improvement. The test I did was removing a white plane from a white
> background. Without the patch, the driver will output black where
> the plane was for the current frame (since the driver does that
> disc-area thing for the largest hidden part of the background).
> With the patch, I get no visual glitches when removing a plane.
> 
> I use a plane to scroll a text, and if you know what to look for,
> the black rectangle that flickers by as the plane with the scrolling
> text is removed is little bit disturbing. Not a significant problem,
> and maybe only geeks notice it, but still...
> 
> Just wanted to say that the resulting "black hole" mentioned in the
> other thread really does exist and that the patch may make sense
> beyond the fact that it removes usage of undocumented features.
> 
> I have not seen any bad side effects fro the patch, but admittedly
> my testing was very limited and I did not try to remove the plane
> while doing other stuff with the driver. So, there might still be
> reasons for removing planes immediately...

Since everything is now synchronized on vsync events thanks to the
atomic modeset infra (including plane/crtc disable requests), I think
the problem I was trying to fix at the time no longer exists (might
re-appear if we start supporting async plane disable requests which is
anyway not supported by the core). So I think I'll just apply your
patch.

Thanks,

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

[PATCH] drm/i915: do not return invalid pointers as a *dentry

[Greg Kroah-Hartman]

When calling debugfs functions, they can now return error values if
something went wrong.  If that happens, return a NULL as a *dentry to
the relay core instead of passing it an illegal pointer.

The relay core should be able to handle an illegal pointer, but add this
check to be safe.

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index d3ebdbc0182e..8bf03497dcd8 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -140,6 +140,9 @@ static struct dentry *create_buf_file_callback(const char 
*filename,
 
buf_file = debugfs_create_file(filename, mode,
   parent, buf, &relay_file_operations);
+   if (IS_ERR(buf_file))
+   return NULL;
+
return buf_file;
 }
 
-- 
2.20.1

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

Re: [PATCH v10 18/40] drm/i915: CP_IRQ handling for DP HDCP2.2 msgs

[Daniel Vetter]

On Thu, Jan 31, 2019 at 09:08:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 12:29:34PM +0530, Ramalingam C wrote:
> > Implements the
> > Waitqueue is created to wait for CP_IRQ
> > Signaling the CP_IRQ arrival through atomic variable.
> > For applicable DP HDCP2.2 msgs read wait for CP_IRQ.
> > 
> > As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts
> > when they are received from HDCP Receivers"
> > 
> > Without CP_IRQ processing, DP HDCP2.2 H_Prime msg was getting corrupted
> > while reading it based on corresponding status bit. This creates the
> > random failures in reading the DP HDCP2.2 msgs.
> > 
> > Signed-off-by: Ramalingam C 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c   | 33 +
> >  drivers/gpu/drm/i915/intel_drv.h  |  7 +++
> >  drivers/gpu/drm/i915/intel_hdcp.c |  6 ++
> >  3 files changed, 38 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index b13c41220ce0..4e36df266ab3 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5619,6 +5619,24 @@ void intel_dp_encoder_suspend(struct intel_encoder 
> > *intel_encoder)
> > edp_panel_vdd_off_sync(intel_dp);
> >  }
> >  
> > +static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> > + int timeout)
> > +{
> > +   long ret;
> > +
> > +   /* Reinit */
> > +   atomic_set(&hdcp->cp_irq_recved, 0);
> 
> This is still fundamentally racy. The way it's usually done is through a
> counter, i.e. the wait function samples the atomic counter, and the wait
> condition is then that the counter has increased.
> 
> The interrupt handler on the other hand just does an atomic_inc. That way
> you never have the problem that the interrupt handler has set 1 before we
> clear it to 0 here.
> 
> That still leaves the race that it has incremented _before_ we sampled in
> this function here. There the counter sampling needs to be moved out
> (probably before we send out the message to the sink), and passed into
> this function as a parameter.
> 
> Finally there's the wrapping problem, so best to just have a condition
> like sampled_counter != current_counter.
> 
> I assume this won't matter for correctness if we miss the interrupt, we
> just time out and at that point the next message should be available. But
> it's less confusing to have more correct code.

Another option would be to shrug the races off (add a comment explaining
why that's ok) and use struct completion instead of wait_queue. That one
is explicitly for one-shot stuff where the wake-up itself is all we need,
and there's no further condition to check.
-Daniel

> 
> Cheers, Daniel
> 
> > +
> > +#define C (atomic_read(&hdcp->cp_irq_recved) > 0)
> > +   ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> > +  msecs_to_jiffies(timeout));
> > +
> > +   if (ret > 0)
> > +   atomic_set(&hdcp->cp_irq_recved, 0);
> > +   else if (!ret)
> > +   DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
> > +}
> > +
> >  static
> >  int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> > u8 *an)
> > @@ -5963,14 +5981,13 @@ intel_dp_hdcp2_wait_for_msg(struct 
> > intel_digital_port *intel_dig_port,
> > mdelay(timeout);
> > ret = 0;
> > } else {
> > -   /* TODO: In case if you need to wait on CP_IRQ, do it here */
> > -   ret = __wait_for(ret =
> > -hdcp2_detect_msg_availability(intel_dig_port,
> > -  msg_id,
> > -  &msg_ready),
> > -!ret && msg_ready, timeout * 1000,
> > -1000, 5 * 1000);
> > -
> > +   /*
> > +* Ignoring the return of the intel_dp_hdcp_wait_for_cp_irq,
> > +* Just to detect the msg availability before failing it.
> > +*/
> > +   intel_dp_hdcp_wait_for_cp_irq(hdcp, timeout);
> > +   ret = hdcp2_detect_msg_availability(intel_dig_port,
> > +   msg_id, &msg_ready);
> > if (!msg_ready)
> > ret = -ETIMEDOUT;
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 747fe7361287..1901d12bacc4 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -464,6 +464,13 @@ struct intel_hdcp {
> >  * over re-Auth has to be triggered.
> >  */
> > u32 seq_num_m;
> > +
> > +   /*
> > +* Work queue to signal the CP_IRQ. Used for the waiters to read the
> > +* available information from HDCP DP sink.
> > +*/
> > +   wait_queue_head_t cp_irq_queue;
> > +   atomic_t cp

Re: [PATCH v2,1/2] drm/vkms: Use alpha for blending in blend() function

[Rodrigo Siqueira]

Hi,

First of all, thanks for your patch :)

I tested your patch against the tests that you implemented in the IGT
[1]. All the alpha tests passed, but there was a weird warning that
says:

 $ sudo IGT_FORCE_DRIVER=vkms ./tests/kms_cursor_crc --run-subtest 
cursor-alpha-opaque
 IGT-Version: 1.23-g8d81c2c2 (x86_64) (Linux: 5.0.0-rc1-VKMS-RULES+ x86_64)
 Force option used: Using driver vkms
 Starting subtest: cursor-alpha-opaque
 (kms_cursor_crc:423) igt_debugfs-WARNING: Warning on condition all_zero in 
function crc_sanity_checks, file ../lib/igt_debugfs.c:901
 (kms_cursor_crc:423) igt_debugfs-WARNING: Suspicious CRC: All values are 0.
 Beginning cursor-alpha-opaque on pipe A, connector Virtual-2
 
 cursor-alpha-opaque on pipe A, connector Virtual-2: PASSED
 
 Subtest cursor-alpha-opaque: SUCCESS (0.315s)

Do you know the reason for that? Could you detail this issue? Is it
possible to fix it?

You can see the other comments inline.

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

On 01/30, Mamta Shukla wrote:
> Use the alpha value to blend vaddr_src with vaddr_dst instead
> of overwriting it in blend().
> 
> Signed-off-by: Mamta Shukla 
> ---
> changes in v2:
> -Use macro to avoid code duplication
> -Add spaces around '/' and '-'
> -Remove spaces at the end of the line
> 
>  drivers/gpu/drm/vkms/vkms_crc.c | 25 +++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index 9d9e8146db90..dc6cb4c2cced 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -5,6 +5,8 @@
>  #include 
>  #include 
>  
> +#define BITSHIFT(val,i)  (u8)((*(u32 *)(val)) >> i & 0xff)

- Take care with the macros definition, since you can create a precedence
  problem. For example, here, you didn't surround “i” with “()”.
- At the end of this operation you cast all the value to u8. In this
  sense, why do you need the 0xff in the end?
- I’m worried about the little and big endian issues here. If I
  understood well, this macro could fail on a big-endian environment. Is it
  right? Did I miss something? Could you explain to me what going to
  happen in the big and endian case?
- Finally, did you take a look at “include/linux/bitops.h” and
  “include/linux/kernel.h”? These headers have a bunch of useful macros
  and functions; probably you can find something useful for you in this
  file. 

> +
>  /**
>   * compute_crc - Compute CRC value on output frame
>   *
> @@ -71,6 +73,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
>   int y_limit = y_src + h_dst;
>   int x_limit = x_src + w_dst;
>  
> + u8 alpha, r_src, r_dst, g_src, g_dst, b_src, b_dst;
> + u8 r_alpha, g_alpha, b_alpha;
> +
>   for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
>   for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
>   offset_dst = crc_dst->offset
> @@ -79,9 +84,25 @@ static void blend(void *vaddr_dst, void *vaddr_src,
>   offset_src = crc_src->offset
>+ (i * crc_src->pitch)
>+ (j * crc_src->cpp);
> + 
> + /*Currently handles alpha values for fully opaque or 
> fully transparent*/
> + alpha = (u8)((*(u32 *)vaddr_src + offset_src) >> 24);
> + alpha = alpha / 255;
> + r_src = BITSHIFT(vaddr_src + offset_src, 16);
> + g_src = BITSHIFT(vaddr_src + offset_src, 8);
> + b_src = BITSHIFT(vaddr_src + offset_src, 0);

If I correctly understood, you have an u32 values which gave you 4
bytes; because of this, you have one byte for Red, Green, Blue, and
Alpha. The above operations extracts each value, one by one. In this
sense, why do we need all of this bitwise operation since you can access
it as an array of chars? Something like this (draft alert):

char *cursor_addr = (char*)vaddr_src + offset_src;
r_src = cursor_addr[2];
g_src = cursor_addr[1];
b_src = cursor_addr[0];
...

There's any restriction for that? Is it related to the big and little
endian issue? Finally, is it ok to make pointer operation with void* in
the kernel?

> + r_dst = BITSHIFT(vaddr_dst + offset_dst, 16);
> + g_dst = BITSHIFT(vaddr_dst + offset_dst, 8);
> + b_dst = BITSHIFT(vaddr_dst + offset_dst, 0);
> +
> + /*Pre-multiplied alpha for blending */
> + r_alpha = (r_src) + (r_dst * (1 - alpha));
> + g_alpha = (g_src) + (g_dst * (1 - alpha));
> + b_alpha = (b_src) + (b_dst * (1 - alpha));
> + memset(vaddr_dst + offset_dst, b_alpha, sizeof(u8));
> + memset(vaddr_dst + offset_dst + 1, g_alpha, sizeof(u8));
> + memset(vaddr_dst + offset_dst + 2, r_alpha, siz

Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API

[Heiko Stuebner]

Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder:
> On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner  wrote:
> >
> > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory into user vma and this was done by
> > > invoking vm_insert_page() within a loop.
> > >
> > > As this pattern is common across different drivers, it can
> > > be generalized by creating new functions and use it across
> > > the drivers.
> > >
> > > vm_insert_range() is the API which could be used to mapped
> > > kernel memory/pages in drivers which has considered vm_pgoff
> > >
> > > vm_insert_range_buggy() is the API which could be used to map
> > > range of kernel memory/pages in drivers which has not considered
> > > vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
> > >
> > > We _could_ then at a later "fix" these drivers which are using
> > > vm_insert_range_buggy() to behave according to the normal vm_pgoff
> > > offsetting simply by removing the _buggy suffix on the function
> > > name and if that causes regressions, it gives us an easy way to revert.
> > >
> > > Signed-off-by: Souptick Joarder 
> > > Suggested-by: Russell King 
> > > Suggested-by: Matthew Wilcox 
> >
> > hmm, I'm missing a changelog here between v1 and v2.
> > Nevertheless I managed to test v1 on Rockchip hardware
> > and display is still working, including talking to Lima via prime.
> >
> > So if there aren't any big changes for v2, on Rockchip
> > Tested-by: Heiko Stuebner 
> 
> Change log is available in [0/9].
> Patch [1/9] & [4/9] have no changes between v1 -> v2.

I never seem to get your cover-letters, so didn't see that, sorry.

But great that there weren't changes then :-)

Heiko


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

Re: [PATCH v4.1 2/3] drm: Add CRTC background color property (v4)

[Ville Syrjälä]

On Wed, Jan 30, 2019 at 06:11:16PM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 11:01:25PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> > > Some display controllers can be programmed to present non-black colors
> > > for pixels not covered by any plane (or pixels covered by the
> > > transparent regions of higher planes).  Compositors that want a UI with
> > > a solid color background can potentially save memory bandwidth by
> > > setting the CRTC background property and using smaller planes to display
> > > the rest of the content.
> > > 
> > > To avoid confusion between different ways of encoding RGB data, we
> > > define a standard 64-bit format that should be used for this property's
> > > value.  Helper functions and macros are provided to generate and dissect
> > > values in this standard format with varying component precision values.
> > > 
> > > v2:
> > >  - Swap internal representation's blue and red bits to make it easier
> > >to read if printed out.  (Ville)
> > >  - Document bgcolor property in drm_blend.c.  (Sean Paul)
> > >  - s/background_color/bgcolor/ for consistency between property name and
> > >value storage field.  (Sean Paul)
> > >  - Add a convenience function to attach property to a given crtc.
> > > 
> > > v3:
> > >  - Restructure ARGB component extraction macros to be easier to
> > >understand and enclose the parameters in () to avoid calculations
> > >if expressions are passed.  (Sean Paul)
> > >  - s/rgba/argb/ in helper function/macro names.  Even though the idea is
> > >to not worry about the internal representation of the u64, it can
> > >still be confusing to look at code that uses 'rgba' terminology, but
> > >stores values with argb ordering.  (Ville)
> > > 
> > > v4:
> > >  - Drop the bgcolor_changed flag.  (Ville, Brian Starkey)
> > >  - Clarify in kerneldoc that background color is expected to undergo the
> > >same pipe-level degamma/csc/gamma transformations that planes do.
> > >(Brian Starkey)
> > >  - Update kerneldoc to indicate non-opaque colors are allowed, but are
> > >generally only useful in special cases such as when writeback
> > >connectors are used (Brian Starkey / Eric Anholt)
> > > 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: wei.c...@intel.com
> > > Cc: harish.krupo@intel.com
> > > Cc: Ville Syrjälä 
> > > Cc: Sean Paul 
> > > Cc: Brian Starkey 
> > > Cc: Eric Anholt 
> > > Cc: Stéphane Marchesin 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Matt Roper 
> > > Reviewed-by(v2): Sean Paul 
> > > Reviewed-by: Brian Starkey 
> > > ---
> > >  drivers/gpu/drm/drm_atomic_uapi.c |  4 
> > >  drivers/gpu/drm/drm_blend.c   | 27 ---
> > >  drivers/gpu/drm/drm_mode_config.c |  6 ++
> > >  include/drm/drm_blend.h   |  1 +
> > >  include/drm/drm_crtc.h| 12 
> > >  include/drm/drm_mode_config.h |  5 +
> > >  include/uapi/drm/drm_mode.h   | 28 
> > >  7 files changed, 80 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > index 9a1f41adfc67..d569e20e34e3 100644
> > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > @@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct 
> > > drm_crtc *crtc,
> > >   return -EFAULT;
> > >  
> > >   set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> > > + } else if (property == config->bgcolor_property) {
> > > + state->bgcolor = val;
> > >   } else if (crtc->funcs->atomic_set_property) {
> > >   return crtc->funcs->atomic_set_property(crtc, state, property, 
> > > val);
> > >   } else {
> > > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > >   *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > >   else if (property == config->prop_out_fence_ptr)
> > >   *val = 0;
> > > + else if (property == config->bgcolor_property)
> > > + *val = state->bgcolor;
> > >   else if (crtc->funcs->atomic_get_property)
> > >   return crtc->funcs->atomic_get_property(crtc, state, property, 
> > > val);
> > >   else
> > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > > index 0c78ca386cbe..d451ac9e1d6d 100644
> > > --- a/drivers/gpu/drm/drm_blend.c
> > > +++ b/drivers/gpu/drm/drm_blend.c
> > > @@ -175,9 +175,22 @@
> > >   *plane does not expose the "alpha" property, then this 
> > > is
> > >   *assumed to be 1.0
> > >   *
> > > - * Note that all the property extensions described here apply either to 
> > > the
> > > - * plane or the CRTC (e.g. for the background color, which currently is 
> > > not
> > > - * exposed and assumed to be black).
> > > + * The property extensions described above all apply to the plane.  
> > > Drivers
> 

Re: [PATCH v7 0/4] drm: add support for Cadence MHDP DPI/DP bridge.

[Tomi Valkeinen]

Hi,

On 30/01/2019 13:03, Damian Kos wrote:
> Hello!
> 
> This is the series of patches that will add support for the Cadence's DPI/DP
> bridge. Please note that this is a preliminary version of the driver and there
> will be more patches in the future with updates, fixes and improvements.
> Please keep that in mind when looking at FIXME/TODO/XXX comments.
> 
> Initially, MHDP driver was developed as a DRM bridge driver and was planed to
> be placed in drivers/gpu/drm/bridge/mhdp.c.  However, there was already
> a driver for Cadence's DP controller developed by RockChip, but that driver
> uses the different DRM framework and looks like a part of a bigger system.
> Both controllers (including firmware) are quite different internally
> (MST/FEC/DSC support, link training done by driver, additional commands, IRQ's
> etc.) but they have similar register map, except for Framer/Streamer (which is
> noticeably different), so they appear similar.
> 
> The following patches contain:
> - Moving common code to drivers/gpu/drm/bridge/cdns-mhdp-common.* and
>   modifying it a bit (mostly new prefixes for functions and data types) so it
>   can be used by two, higher level, drivers.
> - Modifying existing RockChip's DP driver to use the common code after changes
>   made to it (use the new cdns_mhdp_device structure and new function names).
> - Modifying DRM helpers a bit. Some are required for new driver, some are
>   updates from DP 1.2 to 1.3 or 1.4.
> - Adding documentation for device tree bindings.
> - Adding preliminary Cadence DPI/DP bridge driver.
> 
> Some of the things that will be added later on include (but are not limited
> to):
> - DSC support
> - FEC support
> - HDCP support

A few random comments/questions after a quick look at the patches.

The names of the source files and the kernel Kconfig are only about
"Cadence DP". But the DT bindings is for cdns,mhdp8546, and the
resulting module file is mhdp8546.ko. I think more consistency here
would be good.

I presume the part number (or family? are there other similar parts with
similar part numbers?) is relevant, so it should be in the Kconfig
option and help text, and probably in the file names too. The module
name should have "cdns" prefix there, similar to the source files and
the cdns-dsi.ko.

Or maybe the same driver will handle all Cadence DP parts, in which case
generic filenames are fine, but then the resulting kernel module should
also be just "cdns-mhdp.ko".

I see some audio functions in the code, but it's not mentioned in the DT
bindings. I'm not an audio guy, but the display bridges with audio
support I have seen have had DT bindings for the audio source too. Is
audio supported in the current driver?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API

[Heiko Stuebner]

Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
> 
> As this pattern is common across different drivers, it can
> be generalized by creating new functions and use it across
> the drivers.
> 
> vm_insert_range() is the API which could be used to mapped
> kernel memory/pages in drivers which has considered vm_pgoff
> 
> vm_insert_range_buggy() is the API which could be used to map
> range of kernel memory/pages in drivers which has not considered
> vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
> 
> We _could_ then at a later "fix" these drivers which are using
> vm_insert_range_buggy() to behave according to the normal vm_pgoff
> offsetting simply by removing the _buggy suffix on the function
> name and if that causes regressions, it gives us an easy way to revert.
> 
> Signed-off-by: Souptick Joarder 
> Suggested-by: Russell King 
> Suggested-by: Matthew Wilcox 

hmm, I'm missing a changelog here between v1 and v2.
Nevertheless I managed to test v1 on Rockchip hardware
and display is still working, including talking to Lima via prime.

So if there aren't any big changes for v2, on Rockchip
Tested-by: Heiko Stuebner 

Heiko


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

Re: [PATCHv2 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range

[Heiko Stuebner]

Am Donnerstag, 31. Januar 2019, 04:10:40 CET schrieb Souptick Joarder:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
> 
> Signed-off-by: Souptick Joarder 

hmm, I'm missing a changelog here between v1 and v2.
Nevertheless I managed to test v1 on Rockchip hardware
and display is still working, including talking to Lima via prime.

So if there aren't any big changes for v2, on Rockchip
Tested-by: Heiko Stuebner 

Heiko


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

[Bug 105880] [dc] No support for LVDS or VGA connectors (Cannot find any crtc or sizes)

[bugzilla-daemon]

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

--- Comment #46 from Przemek  ---
(In reply to Pontus Gråskæg from comment #43)
> (In reply to Przemek from comment #42)
> > Good news,
> > on amd-staging-drm-next (5.0.0-rc1+) vga connector works without a hitch. I
> > don't have dvi connector on my netbook so I am unable to test this one.
> > 
> > Thanks,
> > Przemek.
> 
> I *think* that is because it defaults to Radeon code on Kaveri.

Apologies, you are right, I was messing with efibootmgr and lost amdgpu.dc=1
somewhere.

Once again sorry for misleading.

Przemek.

-- 
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 v2 6/6] drm/virtio: move virtio_gpu_cmd_create_resource call into virtio_gpu_object_create

[Noralf Trønnes]

Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Specifically call virtio_gpu_object_create() before ttm_bo_init(), so
> the object is already created when ttm calls the
> virtio_gpu_ttm_tt_bind() callback (which in turn calls
> virtio_gpu_object_attach()).
> 
> With that in place virtio_gpu_object_attach() will never be called with
> an object which is not yet created, so the extra
> virtio_gpu_object_attach() calls done after
> virtio_gpu_cmd_create_resource() is not needed any more.
> 
> Signed-off-by: Gerd Hoffmann 
> ---

Acked-by: Noralf Trønnes 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/i2c: tda998x: improve correctness of quantisation range

[Brian Starkey]

On Wed, Jan 30, 2019 at 06:18:44PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 30, 2019 at 03:53:04PM +, Brian Starkey wrote:
> > Hi Russell,
> > 
> > On Fri, Jan 25, 2019 at 09:43:29AM +, Russell King wrote:
> > >  
> > > - /* set color matrix bypass flag: */
> > > - reg_write(priv, REG_MAT_CONTRL, MAT_CONTRL_MAT_BP |
> > > - MAT_CONTRL_MAT_SC(1));
> > > - reg_set(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_CSC);
> > > + /* set color matrix according to output rgb quant range */
> > > + if (priv->rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED) {
> > > + static u8 tda998x_full_to_limited_range[] = {
> > > + MAT_CONTRL_MAT_SC(2),
> > > + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > + 0x03, 0x6f, 0x00, 0x00, 0x00, 0x00,
> > > + 0x00, 0x00, 0x03, 0x6f, 0x00, 0x00,
> > > + 0x00, 0x00, 0x00, 0x00, 0x03, 0x6f,
> > > + 0x00, 0x40, 0x00, 0x40, 0x00, 0x40
> > > + };
> > 
> > I couldn't figure out from the datasheet I have what the expected data
> > bit-depth is here, but I assume from this offset that it's 12-bit?
> 
> No, the data sheet makes it clear that (eg) MAT_OI1_MSB contains
> OFFSET_IN1[10:8] and MAT_OI1_LSB contains OFFSET_IN1[7:0] - so that's
> 11 bits of offset - which looks like from the information I have that
> it's twos complement.  Similar applies to the output offsets.
> 
> The above is the list of register values starting at MAT_CONTRL (0x80),
> with the input offsets in the first line, then the G/Y output
> coefficients, R/CR coefficients, B/CB coefficients and finally the
> output offsets on the last line.
> 
> Each line is a pair of MSB, LSB values, starting at G/Y input, R/CR
> input, B/CB input.
> 
> The above is equivalent to:
> 
> GY_OUT = (GY_IN + 0) * 0x36f / 0x400 + 0x040
> 
> repeated for R/CR and B/CB channels.

Right you are - I need a new calculator and/or brain. I did 256 * 4
and somehow got 4096.

Offset of 64 makes sense for 10-bit.

> 
> This works if we assume that each channel is 10-bit, but as the
> TDA998x supports 12-bit (and we operate it in 12-bit mode internally),
> I suspect the registers do not allow the least two LSBs to be specified
> in either the scaling or offset registers.
> 
> Note that when the TDA998x is configured for less bits in the data
> path, it merely sets the LSBs to zero.
> 
> > Should you also set HVF_CNTRL_1_VQR to 0b01 when using limited range?
> 
> That register is part of the "HDMI Video Formatter".  It's not clear
> what these bits describe - whether it's the input signal or the output
> signal.  It's also not clear from the data sheet where the video
> formatter resides in the chain of processing.  Given that using the
> color matrix has been tested to have the desired effect, I'd rather
> not mess with the HDMI video formatter unless someone identifies that
> there is a real issue that it solves.
> 

I figured "Video input processing registers" were related to the input
signal, and "HDMI video formatter control registers" were related to
the HDMI output encoding.

I agree that the (TDA9983B, I assume?) datasheet isn't really clear in
this regard. If it works fine, and we don't have any better
information, then OK.

Feel free to add my r-b.

Thanks,
-Brian

> Note that I've tested this by forcing the driver to configure the
> output to both limited and full range (via extra patches that have
> been rejected by upstream) and switching the TV between expecting
> limited or full range input with a test output that shows up the
> difference very nicely.
> 
> > 
> > Cheers,
> > -Brian
> > 
> > > + reg_clear(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_CSC);
> > > + reg_write_range(priv, REG_MAT_CONTRL,
> > > + tda998x_full_to_limited_range,
> > > + sizeof(tda998x_full_to_limited_range));
> > > + } else {
> > > + reg_write(priv, REG_MAT_CONTRL, MAT_CONTRL_MAT_BP |
> > > + MAT_CONTRL_MAT_SC(1));
> > > + reg_set(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_CSC);
> > > + }
> > >  
> > >   /* set BIAS tmds value: */
> > >   reg_write(priv, REG_ANA_GENERAL, 0x09);
> > > -- 
> > > 2.7.4
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/6] drm/virtio: drop fencing in virtio_gpu_resource_create_ioctl

[Noralf Trønnes]

Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> There is no need to wait for completion here.
> 
> The host will process commands in submit order, so commands can
> reference the new resource just fine even when queued up before
> completion.
> 
> On the guest side there is no need to wait for completion too.  Which
> btw is different from resource destroy, where we have to make sure the
> host has seen the destroy and thus doesn't use it any more before
> releasing the pages backing the resource.
> 
> Signed-off-by: Gerd Hoffmann 
> ---

Acked-by: Noralf Trønnes 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/6] drm/virtio: params struct for virtio_gpu_cmd_create_resource_3d()

[Noralf Trønnes]

Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Add 3d resource parameters to virtio_gpu_object_params struct.  With
> that in place we can use it for virtio_gpu_cmd_resource_create_3d()
> calls.
> 
> Signed-off-by: Gerd Hoffmann 
> ---

You don't remove the struct virtio_gpu_resource_create_3d definition,
but it looks like there's no users left?

Noralf.

>  drivers/gpu/drm/virtio/virtgpu_drv.h   | 10 +-
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 25 ++---
>  drivers/gpu/drm/virtio/virtgpu_vq.c| 16 +---
>  3 files changed, 32 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index a40215c10e..3265e62725 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -56,6 +56,14 @@ struct virtio_gpu_object_params {
>   uint32_t height;
>   unsigned long size;
>   bool pinned;
> + /* 3d */
> + uint32_t target;
> + uint32_t bind;
> + uint32_t depth;
> + uint32_t array_size;
> + uint32_t last_level;
> + uint32_t nr_samples;
> + uint32_t flags;
>  };
>  
>  struct virtio_gpu_object {
> @@ -310,7 +318,7 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct 
> virtio_gpu_device *vgdev,
>  void
>  virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev,
> struct virtio_gpu_object *bo,
> -   struct virtio_gpu_resource_create_3d *rc_3d);
> +   struct virtio_gpu_object_params *params);
>  void virtio_gpu_ctrl_ack(struct virtqueue *vq);
>  void virtio_gpu_cursor_ack(struct virtqueue *vq);
>  void virtio_gpu_fence_ack(struct virtqueue *vq);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
> b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> index 84c2216fd4..431e5d767e 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -283,7 +283,6 @@ static int virtio_gpu_resource_create_ioctl(struct 
> drm_device *dev, void *data,
>   struct ttm_validate_buffer mainbuf;
>   struct virtio_gpu_fence *fence = NULL;
>   struct ww_acquire_ctx ticket;
> - struct virtio_gpu_resource_create_3d rc_3d;
>   struct virtio_gpu_object_params params = { 0 };
>  
>   if (vgdev->has_virgl_3d == false) {
> @@ -307,7 +306,15 @@ static int virtio_gpu_resource_create_ioctl(struct 
> drm_device *dev, void *data,
>   params.width = rc->width;
>   params.height = rc->height;
>   params.size = rc->size;
> -
> + if (vgdev->has_virgl_3d) {
> + params.target = rc->target;
> + params.bind = rc->bind;
> + params.depth = rc->depth;
> + params.array_size = rc->array_size;
> + params.last_level = rc->last_level;
> + params.nr_samples = rc->nr_samples;
> + params.flags = rc->flags;
> + }
>   /* allocate a single page size object */
>   if (params.size == 0)
>   params.size = PAGE_SIZE;
> @@ -333,25 +340,13 @@ static int virtio_gpu_resource_create_ioctl(struct 
> drm_device *dev, void *data,
>   goto fail_unref;
>   }
>  
> - rc_3d.resource_id = cpu_to_le32(qobj->hw_res_handle);
> - rc_3d.target = cpu_to_le32(rc->target);
> - rc_3d.format = cpu_to_le32(rc->format);
> - rc_3d.bind = cpu_to_le32(rc->bind);
> - rc_3d.width = cpu_to_le32(rc->width);
> - rc_3d.height = cpu_to_le32(rc->height);
> - rc_3d.depth = cpu_to_le32(rc->depth);
> - rc_3d.array_size = cpu_to_le32(rc->array_size);
> - rc_3d.last_level = cpu_to_le32(rc->last_level);
> - rc_3d.nr_samples = cpu_to_le32(rc->nr_samples);
> - rc_3d.flags = cpu_to_le32(rc->flags);
> -
>   fence = virtio_gpu_fence_alloc(vgdev);
>   if (!fence) {
>   ret = -ENOMEM;
>   goto fail_backoff;
>   }
>  
> - virtio_gpu_cmd_resource_create_3d(vgdev, qobj, &rc_3d);
> + virtio_gpu_cmd_resource_create_3d(vgdev, qobj, ¶ms);
>   ret = virtio_gpu_object_attach(vgdev, qobj, fence);
>   if (ret) {
>   dma_fence_put(&fence->f);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 363b8b8577..ca93ec6ca3 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -826,7 +826,7 @@ void virtio_gpu_cmd_context_detach_resource(struct 
> virtio_gpu_device *vgdev,
>  void
>  virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev,
> struct virtio_gpu_object *bo,
> -   struct virtio_gpu_resource_create_3d *rc_3d)
> +   struct virtio_gpu_object_params *params)
>  {
>   str

[Bug 107990] Got Dying Light working in Arch by changing Mesa's compile steps, how to get it working Out Of the Box?

[bugzilla-daemon]

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

--- Comment #10 from John  ---
Hey Timothy,

is this something fairly easy to get into for someone with no knowledge of
OpenGL or Mesa (I've had a patch 5 years ago, so pretty much the same as no
knowledge)? If so, unless John wants to do it, I would be willing to try.

-- 
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 v2 2/6] drm/virtio: use struct to pass params to virtio_gpu_object_create()

[Noralf Trønnes]

Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Create virtio_gpu_object_params, use that to pass object parameters to
> virtio_gpu_object_create.  This is just the first step, followup patches
> will add more parameters to the struct.  The plan is to use the struct
> for all object parameters.
> 
> Also drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is
> unused and always false.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.h| 15 ++-
>  drivers/gpu/drm/virtio/virtgpu_gem.c| 17 ++---
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c  | 11 ++-
>  drivers/gpu/drm/virtio/virtgpu_object.c | 22 +-
>  4 files changed, 35 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index d577cb76f5..40928980a2 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -50,6 +50,11 @@
>  #define DRIVER_MINOR 1
>  #define DRIVER_PATCHLEVEL 0
>  
> +struct virtio_gpu_object_params {
> + unsigned long size;
> + bool pinned;
> +};
> +
>  struct virtio_gpu_object {
>   struct drm_gem_object gem_base;
>   uint32_t hw_res_handle;
> @@ -217,16 +222,16 @@ int virtio_gpu_gem_init(struct virtio_gpu_device 
> *vgdev);
>  void virtio_gpu_gem_fini(struct virtio_gpu_device *vgdev);
>  int virtio_gpu_gem_create(struct drm_file *file,
> struct drm_device *dev,
> -   uint64_t size,
> +   struct virtio_gpu_object_params *params,
> struct drm_gem_object **obj_p,
> uint32_t *handle_p);
>  int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
>  struct drm_file *file);
>  void virtio_gpu_gem_object_close(struct drm_gem_object *obj,
>struct drm_file *file);
> -struct virtio_gpu_object *virtio_gpu_alloc_object(struct drm_device *dev,
> -   size_t size, bool kernel,
> -   bool pinned);
> +struct virtio_gpu_object*
> +virtio_gpu_alloc_object(struct drm_device *dev,
> + struct virtio_gpu_object_params *params);
>  int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
>   struct drm_device *dev,
>   struct drm_mode_create_dumb *args);
> @@ -342,7 +347,7 @@ void virtio_gpu_fence_event_process(struct 
> virtio_gpu_device *vdev,
>  
>  /* virtio_gpu_object */
>  int virtio_gpu_object_create(struct virtio_gpu_device *vgdev,
> -  unsigned long size, bool kernel, bool pinned,
> +  struct virtio_gpu_object_params *params,
>struct virtio_gpu_object **bo_ptr);
>  void virtio_gpu_object_kunmap(struct virtio_gpu_object *bo);
>  int virtio_gpu_object_kmap(struct virtio_gpu_object *bo);
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c 
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index f065863939..b5f2d94ce5 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -34,15 +34,15 @@ void virtio_gpu_gem_free_object(struct drm_gem_object 
> *gem_obj)
>   virtio_gpu_object_unref(&obj);
>  }
>  
> -struct virtio_gpu_object *virtio_gpu_alloc_object(struct drm_device *dev,
> -   size_t size, bool kernel,
> -   bool pinned)
> +struct virtio_gpu_object*
> +virtio_gpu_alloc_object(struct drm_device *dev,
> + struct virtio_gpu_object_params *params)
>  {
>   struct virtio_gpu_device *vgdev = dev->dev_private;
>   struct virtio_gpu_object *obj;
>   int ret;
>  
> - ret = virtio_gpu_object_create(vgdev, size, kernel, pinned, &obj);
> + ret = virtio_gpu_object_create(vgdev, params, &obj);
>   if (ret)
>   return ERR_PTR(ret);
>  
> @@ -51,7 +51,7 @@ struct virtio_gpu_object *virtio_gpu_alloc_object(struct 
> drm_device *dev,
>  
>  int virtio_gpu_gem_create(struct drm_file *file,
> struct drm_device *dev,
> -   uint64_t size,
> +   struct virtio_gpu_object_params *params,
> struct drm_gem_object **obj_p,
> uint32_t *handle_p)
>  {
> @@ -59,7 +59,7 @@ int virtio_gpu_gem_create(struct drm_file *file,
>   int ret;
>   u32 handle;
>  
> - obj = virtio_gpu_alloc_object(dev, size, false, false);
> + obj = virtio_gpu_alloc_object(dev, params);
>   if (IS_ERR(obj))
>   return PTR_ERR(obj);
>  
> @@ -85,6 +85,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
>   struct virtio_gpu_device *vgdev = dev->dev_private;
>   struct drm_gem_object *gobj;
>   struct virtio_gpu_obje

Re: [PATCH v2 3/6] drm/virtio: params struct for virtio_gpu_cmd_create_resource()

[Noralf Trønnes]

Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Add format, width and height fields to the virtio_gpu_object_params
> struct.  With that in place we can use the parameter struct for
> virtio_gpu_cmd_create_resource() calls too.
> 
> Signed-off-by: Gerd Hoffmann 
> ---

Acked-by: Noralf Trønnes 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel