[radeon-alex:amd-staging-drm-next 1046/1053] drivers/gpu//drm/amd/lib/../include/linux/chash.h:286:50: error: '_BITOPS_LONG_SHIFT' undeclared

2017-09-18 Thread kbuild test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   dcae401d111324489c066aa57ed9c77b97b475f9
commit: 18c073719186a393b41715686cf95175c58919df [1046/1053] drm/amd: Closed 
hash table with low overhead
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.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 18c073719186a393b41715686cf95175c58919df
# save the attached .config to linux build tree
make.cross ARCH=ia64 

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

   In file included from drivers/gpu//drm/amd/lib/chash.c:30:0:
   drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
'chash_iter_is_valid':
>> drivers/gpu//drm/amd/lib/../include/linux/chash.h:286:50: error: 
>> '_BITOPS_LONG_SHIFT' undeclared (first use in this function)
 return !!(iter.table->valid_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] &
 ^~
   drivers/gpu//drm/amd/lib/../include/linux/chash.h:286:50: note: each 
undeclared identifier is reported only once for each function it appears in
   drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
'chash_iter_is_empty':
   drivers/gpu//drm/amd/lib/../include/linux/chash.h:292:49: error: 
'_BITOPS_LONG_SHIFT' undeclared (first use in this function)
 return !(iter.table->occup_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] &
^~
   drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
'chash_iter_set_valid':
   drivers/gpu//drm/amd/lib/../include/linux/chash.h:299:40: error: 
'_BITOPS_LONG_SHIFT' undeclared (first use in this function)
 iter.table->valid_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] |= iter.mask;
   ^~
   drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
'chash_iter_set_invalid':
   drivers/gpu//drm/amd/lib/../include/linux/chash.h:305:40: error: 
'_BITOPS_LONG_SHIFT' undeclared (first use in this function)
 iter.table->valid_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] &= ~iter.mask;
   ^~
   drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
'chash_iter_set_empty':
   drivers/gpu//drm/amd/lib/../include/linux/chash.h:310:40: error: 
'_BITOPS_LONG_SHIFT' undeclared (first use in this function)
 iter.table->occup_bitmap[iter.slot >> _BITOPS_LONG_SHIFT] &= ~iter.mask;
   ^~
   drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
'chash_iter_is_valid':
>> drivers/gpu//drm/amd/lib/../include/linux/chash.h:288:1: warning: control 
>> reaches end of non-void function [-Wreturn-type]
}
^
   drivers/gpu//drm/amd/lib/../include/linux/chash.h: In function 
'chash_iter_is_empty':
   drivers/gpu//drm/amd/lib/../include/linux/chash.h:294:1: warning: control 
reaches end of non-void function [-Wreturn-type]
}
^

vim +/_BITOPS_LONG_SHIFT +286 drivers/gpu//drm/amd/lib/../include/linux/chash.h

   252  
   253  /**
   254   * CHASH_ITER_INIT - Initialize a hash table iterator
   255   * @tbl: Pointer to hash table to iterate over
   256   * @s: Initial slot number
   257   */
   258  #define CHASH_ITER_INIT(table, s) { \
   259  table,  \
   260  1UL << ((s) & (BITS_PER_LONG - 1)), \
   261  s   \
   262  }
   263  /**
   264   * CHASH_ITER_SET - Set hash table iterator to new slot
   265   * @iter: Iterator
   266   * @s: Slot number
   267   */
   268  #define CHASH_ITER_SET(iter, s) \
   269  (iter).mask = 1UL << ((s) & (BITS_PER_LONG - 1)),   \
   270  (iter).slot = (s)
   271  /**
   272   * CHASH_ITER_INC - Increment hash table iterator
   273   * @table: Hash table to iterate over
   274   *
   275   * Wraps around at the end.
   276   */
   277  #define CHASH_ITER_INC(iter) do {   
\
   278  (iter).mask = (iter).mask << 1 |
\
   279  (iter).mask >> (BITS_PER_LONG - 1); 
\
   280  (iter).slot = ((iter).slot + 1) & 
(iter).table->size_mask; \
   281  } while (0)
   282  
   283  static inline bool chash_iter_is_valid(const struct chash_iter iter)
   284  {
   285  BUG_ON((unsigned)iter.slot >= (1 << iter.table->bits));
 > 286  return !!(iter.table->valid_bitmap[iter.slot >> 
 > _BITOPS_LONG_SHIFT] &
   287iter.mask);
 > 288  }
   289  static inline bool chash_iter_is_empty(const struct chash_iter iter)
   290  {
   291  

[radeon-alex:amd-staging-drm-next 1033/1053] ci_smc.c:(.text+0xe30): multiple definition of `ci_send_msg_to_smc'

2017-09-18 Thread kbuild test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   dcae401d111324489c066aa57ed9c77b97b475f9
commit: e2e8b699af4f02a8ce46d338bbb1d227f68523b1 [1033/1053] drm/amd/powerplay: 
add CI asics support to smumgr
config: i386-randconfig-i0-201738 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
git checkout e2e8b699af4f02a8ce46d338bbb1d227f68523b1
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.o: In function 
`ci_send_msg_to_smc':
>> ci_smc.c:(.text+0xe30): multiple definition of `ci_send_msg_to_smc'
   drivers/gpu/drm/radeon/ci_smc.o:ci_smc.c:(.text+0x330): first defined here

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


[radeon-alex:amd-staging-drm-next 1045/1053] drivers/gpu//drm/amd/amdgpu/si_ih.c:304:2: error: unknown field 'prescreeen_iv' specified in initializer

2017-09-18 Thread kbuild test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   dcae401d111324489c066aa57ed9c77b97b475f9
commit: b4b69eb86f0e0c036cf9d46e99801d8c2848847d [1045/1053] drm/amdgpu: Add 
prescreening stage in IH processing
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.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 b4b69eb86f0e0c036cf9d46e99801d8c2848847d
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: the radeon-alex/amd-staging-drm-next HEAD 
dcae401d111324489c066aa57ed9c77b97b475f9 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/gpu//drm/amd/amdgpu/si_ih.c:304:2: error: unknown field 
>> 'prescreeen_iv' specified in initializer
 .prescreeen_iv = si_ih_prescreen_iv,
 ^

vim +/prescreeen_iv +304 drivers/gpu//drm/amd/amdgpu/si_ih.c

   301  
   302  static const struct amdgpu_ih_funcs si_ih_funcs = {
   303  .get_wptr = si_ih_get_wptr,
 > 304  .prescreeen_iv = si_ih_prescreen_iv,
   305  .decode_iv = si_ih_decode_iv,
   306  .set_rptr = si_ih_set_rptr
   307  };
   308  

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


[radeon-alex:amd-staging-drm-next 1033/1053] arch/ia64/include/uapi/asm/swab.h:20:23: warning: 'tmp' may be used uninitialized in this function

2017-09-18 Thread kbuild test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   dcae401d111324489c066aa57ed9c77b97b475f9
commit: e2e8b699af4f02a8ce46d338bbb1d227f68523b1 [1033/1053] drm/amd/powerplay: 
add CI asics support to smumgr
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.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 e2e8b699af4f02a8ce46d338bbb1d227f68523b1
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/swab.h:6:0,
from include/linux/swab.h:4,
from include/uapi/linux/byteorder/little_endian.h:12,
from include/linux/byteorder/little_endian.h:4,
from arch/ia64/include/uapi/asm/byteorder.h:4,
from include/asm-generic/bitops/le.h:5,
from arch/ia64/include/asm/bitops.h:448,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from 
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:23:
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c: In function 
'ci_init_smc_table':
>> arch/ia64/include/uapi/asm/swab.h:20:23: warning: 'tmp' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
#define __arch_swab64 __arch_swab64
  ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:571:11: note: 'tmp' 
was declared here
 uint16_t tmp;
  ^~~
--
   In file included from include/uapi/linux/swab.h:6:0,
from include/linux/swab.h:4,
from include/uapi/linux/byteorder/little_endian.h:12,
from include/linux/byteorder/little_endian.h:4,
from arch/ia64/include/uapi/asm/byteorder.h:4,
from include/asm-generic/bitops/le.h:5,
from arch/ia64/include/asm/bitops.h:448,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from 
drivers/gpu//drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:23:
   drivers/gpu//drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c: In function 
'ci_init_smc_table':
>> arch/ia64/include/uapi/asm/swab.h:20:23: warning: 'tmp' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
#define __arch_swab64 __arch_swab64
  ^
   drivers/gpu//drm/amd/amdgpu/../powerplay/smumgr/ci_smc.c:571:11: note: 'tmp' 
was declared here
 uint16_t tmp;
  ^~~

vim +/tmp +20 arch/ia64/include/uapi/asm/swab.h

ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  12  
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  13  static 
__inline__ __attribute_const__ __u64 __arch_swab64(__u64 x)
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  14  {
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  15__u64 
result;
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  16  
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  17result 
= ia64_mux1(x, ia64_mux1_rev);
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  18return 
result;
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  19  }
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06 @20  #define 
__arch_swab64 __arch_swab64
ae189623 arch/ia64/include/asm/swab.h Harvey Harrison 2009-01-06  21  

:: The code at line 20 was first introduced by commit
:: ae189623b7248cd245c068a1aeb4983359f9c088 ia64: introduce asm/swab.h

:: TO: Harvey Harrison 
:: CC: Linus Torvalds 

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


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


Re: [PATCH] drm/radeon: properly initialize r600_audio_status() data

2017-09-18 Thread Alex Deucher
On Sat, Sep 16, 2017 at 8:20 AM, Christian König
 wrote:
> Am 15.09.2017 um 22:06 schrieb Arnd Bergmann:
>>
>> The structure returned from r600_audio_status() is only partially
>> initialized, and older gcc versions (4.3 and 4.4) warn about this:
>>
>> drivers/gpu/drm/radeon/r600_hdmi.c: In function 'r600_audio_status':
>> drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.id' is used
>> uninitialized in this function
>> drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.connected' is used
>> uninitialized in this function
>> drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.offset' is used
>> uninitialized in this function
>>
>> This is harmless and surprisingly correct in C99, as the caller
>> only accesses the fields that got initialized, so newer compilers
>> don't warn about it, but initializing the entire structure feels
>> like the right thing to do here and avoids the warning.
>>
>> Signed-off-by: Arnd Bergmann 
>
>
> Reviewed-by: Christian König 

Applied.  thanks!

Alex


>
>> ---
>>   drivers/gpu/drm/radeon/r600_hdmi.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
>> b/drivers/gpu/drm/radeon/r600_hdmi.c
>> index e82a99cb2459..ab32830c4e23 100644
>> --- a/drivers/gpu/drm/radeon/r600_hdmi.c
>> +++ b/drivers/gpu/drm/radeon/r600_hdmi.c
>> @@ -58,7 +58,7 @@ enum r600_hdmi_iec_status_bits {
>> static struct r600_audio_pin r600_audio_status(struct radeon_device
>> *rdev)
>>   {
>> -   struct r600_audio_pin status;
>> +   struct r600_audio_pin status = {};
>> uint32_t value;
>> value = RREG32(R600_AUDIO_RATE_BPS_CHANNEL);
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2017-09-18 Thread Stephen Rothwell
Hi all,

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

  drivers/media/v4l2-core/videobuf2-dma-contig.c

between commit:

  5b6f9abe5a49 ("media: vb2: add bidirectional flag in vb2_queue")

from Linus' tree and commit:

  c4860ad60564 ("lib/scatterlist: Fix offset type in sg_alloc_table_from_pages")

from the drm-intel tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/media/v4l2-core/videobuf2-dma-contig.c
index 9f389f36566d,2405077fdc71..
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@@ -507,9 -507,8 +507,9 @@@ static void *vb2_dc_get_userptr(struct 
buf->dev = dev;
buf->dma_dir = dma_dir;
  
-   offset = vaddr & ~PAGE_MASK;
+   offset = lower_32_bits(offset_in_page(vaddr));
 -  vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
 +  vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE ||
 + dma_dir == DMA_BIDIRECTIONAL);
if (IS_ERR(vec)) {
ret = PTR_ERR(vec);
goto fail_buf;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 82431] Garbled screen on boot

2017-09-18 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=82431

Fede (fed...@yahoo.com) changed:

   What|Removed |Added

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

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


Re: remove ttm trace and add iova debugfs (v2)

2017-09-18 Thread StDenis, Tom
Should add I was able to read/write system memory mapped by amdgpu with these 
patches in place on my polaris10 device (with iommu enabled of course).


From: amd-gfx  on behalf of Tom St Denis 

Sent: Monday, September 18, 2017 13:33
To: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: remove ttm trace and add iova debugfs (v2)

In this respin I add some changes per feedback and make the iova
entry have proper read/write methods which access pages mapped
by amdgpu.  So there is no need for /dev/mem or /dev/fmem anymore
when reading system memory.

Patches 3/4 are unchanged and remove the TTM trace from amdgpu
and from TTM itself.


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


[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

2017-09-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91880

--- Comment #177 from garththei...@hotmail.com ---
Created attachment 134324
  --> https://bugs.freedesktop.org/attachment.cgi?id=134324=edit
dmesg capture

Logged this problem against 4.13.2. Started up an accelerated program (game)
and with in seconds the screen went black.

In the attached dmesg output the amdgpu emits a timeout *ERROR*, but I was
unable to recover the session/switch DPM parameters to force recovery.

>[   85.983053] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, 
>last signaled seq=2103, last emitted seq=2105
>[   85.983125] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
>last signaled seq=7839, last emitted seq=7841
>[   85.983129] [drm] No hardware hang detected. Did some blocks stall?
>[   85.983130] [drm] No hardware hang detected. Did some blocks stall?

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


[Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI

2017-09-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100105

--- Comment #1 from Jan Vesely  ---
*** Testing for AMD Radeon R7 Graphics (CARRIZO / DRM 3.18.0 / 4.11.0-ROC, LLVM
5.0.0)

Ran 6670 tests in 785.274s

FAILED (SKIP=12, errors=580, failures=12)

all errors are caused by:
TypeError: This is for CUDA arrays.

I haven't investigated the failures.


There are couple of patches needed:
https://github.com/Theano/libgpuarray/pull/534
https://github.com/Theano/libgpuarray/pull/535

http://lists.llvm.org/pipermail/libclc-dev/2017-September/002449.html

and:
diff --git a/src/cluda_opencl.h b/src/cluda_opencl.h
index 6e0095c..e93aa8b 100644
--- a/src/cluda_opencl.h
+++ b/src/cluda_opencl.h
@@ -48,9 +48,9 @@ typedef struct _ga_half {
 } ga_half;

 #define ga_half2float(p) vload_half(0, &((p).data))
-static inline ga_half ga_float2half(ga_float f) {
+inline ga_half ga_float2half(ga_float f) {
   ga_half r;
-  vstore_half_rtn(f, 0, );
+  vstore_half(f, 0, );
   return r;
 }
diff --git a/src/gpuarray_buffer_opencl.c b/src/gpuarray_buffer_opencl.c
index 8f12811..2041ca2 100644
--- a/src/gpuarray_buffer_opencl.c
+++ b/src/gpuarray_buffer_opencl.c
@@ -146,7 +146,7 @@ cl_ctx *cl_make_ctx(cl_context ctx, gpucontext_props *p) {
   CL_CHECKN(global_err, clGetDeviceInfo(id, CL_DEVICE_VERSION,
 device_version_size,
 device_version, NULL));
-  if (device_version[7] == '1' && device_version[9] < '2') {
+  if (device_version[7] == '1' && device_version[9] < '1') {
 error_set(global_err, GA_UNSUPPORTED_ERROR,
   "We only support OpenCL 1.2 and up");
 return NULL;

-- 
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 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-18 Thread Rob Herring
On Tue, Sep 12, 2017 at 09:34:07AM +0200, Maciej Purski wrote:
> SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it does on device driver level is
> filtering-out unsupported video modes, it exposes drm_bridge
> interface to perform this operation.
> 
> This patch is based on the code refactored by Tomasz Stanislawski
> , which was initially developed by:
> Adam Hampson 
> Erik Gilling 
> Shankar Bandal 
> Dharam Kumar 
> 
> Signed-off-by: Maciej Purski 
> ---
>  .../devicetree/bindings/display/bridge/sii9234.txt |  49 +

Acked-by: Rob Herring 

>  drivers/gpu/drm/bridge/Kconfig |   8 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/sii9234.c   | 996 
> +
>  4 files changed, 1054 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/sii9234.txt
>  create mode 100644 drivers/gpu/drm/bridge/sii9234.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCHv6 3/5] dt-bindings: document the CEC GPIO bindings

2017-09-18 Thread Rob Herring
On Sun, Sep 17, 2017 at 5:15 AM, Hans Verkuil  wrote:
> From: Hans Verkuil 
>
> Document the bindings for the cec-gpio module for hardware where the
> CEC line and optionally the HPD line are connected to GPIO lines.
>
> Signed-off-by: Hans Verkuil 
> Reviewed-by: Linus Walleij 
> ---
>  .../devicetree/bindings/media/cec-gpio.txt | 32 
> ++
>  1 file changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt

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


[Bug 102814] Blender 2.79 flickering

2017-09-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102814

--- Comment #6 from Dieter Nützel  ---
Maybe overwritten 'new' defaults (on your side/distro), then?
Simple fix is proposed, here:
https://bugs.freedesktop.org/show_bug.cgi?id=97059#c9

The old Blender bug should be fixed in Blender 2.8 (hopefully).
NO change for Blender master planed, like in this post:
https://developer.blender.org/T49945

Proposed fix for Blender master was:
https://developer.blender.org/D2342

Anyway, try bisecting Blender, Mesa if you think it is a new regression.

-- 
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: add backwards compatibility support for drm_kms_helper.edid_firmware

2017-09-18 Thread Ville Syrjälä
On Mon, Sep 18, 2017 at 09:20:03PM +0300, Jani Nikula wrote:
> Add drm_kms_helper.edid_firmware module parameter with param ops hooks
> to set drm.edid_firmware instead, for backwards compatibility.
> 
> Suggested-by: Ville Syrjälä 
> Cc: Abdiel Janulgue 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid_load.c | 16 
>  drivers/gpu/drm/drm_kms_helper_common.c | 28 
>  include/drm/drm_edid.h  |  2 ++
>  3 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 1c0495acf341..a4915099aaa9 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -31,6 +31,22 @@ module_param_string(edid_firmware, edid_firmware, 
> sizeof(edid_firmware), 0644);
>  MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID 
> blob "
>   "from built-in data or /lib/firmware instead. ");
>  
> +/* Use only for backward compatibility with drm_kms_helper.edid_firmware */
> +int __drm_set_edid_firmware_path(const char *path)
> +{
> + scnprintf(edid_firmware, sizeof(edid_firmware), "%s", path);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(__drm_set_edid_firmware_path);
> +
> +/* Use only for backward compatibility with drm_kms_helper.edid_firmware */
> +int __drm_get_edid_firmware_path(char *buf, size_t bufsize)
> +{
> + return scnprintf(buf, bufsize, "%s", edid_firmware);

I guess these could just use strlcpy() or something.

> +}
> +EXPORT_SYMBOL(__drm_get_edid_firmware_path);
> +
>  #define GENERIC_EDIDS 6
>  static const char * const generic_edid_name[GENERIC_EDIDS] = {
>   "edid/800x600.bin",
> diff --git a/drivers/gpu/drm/drm_kms_helper_common.c 
> b/drivers/gpu/drm/drm_kms_helper_common.c
> index 6e35a56a6102..5051c3aa4d5d 100644
> --- a/drivers/gpu/drm/drm_kms_helper_common.c
> +++ b/drivers/gpu/drm/drm_kms_helper_common.c
> @@ -26,6 +26,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include "drm_crtc_helper_internal.h"
>  
> @@ -33,6 +34,33 @@ MODULE_AUTHOR("David Airlie, Jesse Barnes");
>  MODULE_DESCRIPTION("DRM KMS helper");
>  MODULE_LICENSE("GPL and additional rights");
>  
> +#if IS_ENABLED(CONFIG_DRM_LOAD_EDID_FIRMWARE)
> +
> +/* Backward compatibility for drm_kms_helper.edid_firmware */
> +static int edid_firmware_set(const char *val, const struct kernel_param *kp)
> +{
> + DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use 
> drm.edid_firmware intead.\n");
> +
> + return __drm_set_edid_firmware_path(val);
> +}
> +
> +static int edid_firmware_get(char *buffer, const struct kernel_param *kp)
> +{
> + return __drm_get_edid_firmware_path(buffer, PAGE_SIZE);
> +}
> +
> +const struct kernel_param_ops edid_firmware_ops = {
> + .set = edid_firmware_set,
> + .get = edid_firmware_get,
> +};
> +
> +module_param_cb(edid_firmware, _firmware_ops, NULL, 0644);

Do we want the __parm_check thing here? Looks like it's just some kind of
compile time type check though so not critical by any means.

Otherwise looks technically correct so
Reviewed-by: Ville Syrjälä 

> +__MODULE_PARM_TYPE(edid_firmware, "charp");
> +MODULE_PARM_DESC(edid_firmware,
> +  "DEPRECATED. Use drm.edid_firmware module parameter instead.");
> +
> +#endif
> +
>  static int __init drm_kms_helper_init(void)
>  {
>   int ret;
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 1e1908a6b1d6..6f35909b8add 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -341,6 +341,8 @@ int drm_av_sync_delay(struct drm_connector *connector,
>  
>  #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
>  struct edid *drm_load_edid_firmware(struct drm_connector *connector);
> +int __drm_set_edid_firmware_path(const char *path);
> +int __drm_get_edid_firmware_path(char *buf, size_t bufsize);
>  #else
>  static inline struct edid *
>  drm_load_edid_firmware(struct drm_connector *connector)
> -- 
> 2.11.0

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


[Bug 102814] Blender 2.79 flickering

2017-09-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102814

--- Comment #5 from freedesk...@ca.sh13.net ---
It can't be old because Blender 2.79 is brand-new (released last week) and
Blender 2.78 didn't suffer from this 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 7/8] etnaviv: mmu: mark local functions static

2017-09-18 Thread Philipp Zabel
On Fri, 2017-09-15 at 19:04 +0200, Lucas Stach wrote:
> And clean up the header file a bit.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

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


Re: [PATCH 5/8] etnaviv: iommuv1: fold pgtable_write into callers

2017-09-18 Thread Philipp Zabel
On Fri, 2017-09-15 at 19:04 +0200, Lucas Stach wrote:
> A function doing a single assignment is not really helping the
> code flow.
> 
> Signed-off-by: Lucas Stach 

The two functions are very similar, but given the different return value
I think they are small enough to be mostly duplicated.

Reviewed-by: Philipp Zabel 

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


Re: [PATCH 4/8] etnaviv: iommuv1: remove map_lock

2017-09-18 Thread Philipp Zabel
On Fri, 2017-09-15 at 19:04 +0200, Lucas Stach wrote:
> It wasn't protecting anything, as the single word writes used to
> set up or tear down a translation are already inherently atomic,
> so the spinlock is pure overhead.
> 
> Signed-off-by: Lucas Stach 

This would have been made clearer if patches 4 and 5 were switched.

Reviewed-by: Philipp Zabel 

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


Re: [PATCH 3/8] etnaviv: iommuv1: fold pagetable alloc and free into caller

2017-09-18 Thread Philipp Zabel
On Fri, 2017-09-15 at 19:04 +0200, Lucas Stach wrote:
> Those functions are simple enough to fold them into the calling
> function. This also fixes a correctness issue, as the alloc/free
> functions didn't specifiy the device the memory was allocated for.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

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


Re: [PATCH 2/8] etnaviv: remove iova_to_phys iommu ops

2017-09-18 Thread Philipp Zabel
On Fri, 2017-09-15 at 19:04 +0200, Lucas Stach wrote:
> They are not used in any way, so can go away.
> 
> Signed-off-by: Lucas Stach 

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


Re: [PATCH 1/8] etnaviv: remove iommu fault handler

2017-09-18 Thread Philipp Zabel
On Fri, 2017-09-15 at 19:04 +0200, Lucas Stach wrote:
> The handler has never been used, so it's really just dead code.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

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


Re: [PATCH 6/8] etnaviv: mmu: stop using iommu map/unmap functions

2017-09-18 Thread Philipp Zabel
On Fri, 2017-09-15 at 19:04 +0200, Lucas Stach wrote:
> This is a preparation to remove the etnaviv dependency on the IOMMU
> subsystem by importing the relevant parts of the iommu map/unamp
> functions into the driver.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 66
> +++
>  1 file changed, 60 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index f3ed07db9b2d..0be28467af61 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -22,6 +22,60 @@
>  #include "etnaviv_iommu.h"
>  #include "etnaviv_mmu.h"
>  
> +size_t etnaviv_domain_unmap(struct iommu_domain *domain, unsigned
> long iova, size_t size)
> +{
> + size_t unmapped_page, unmapped = 0;
> + size_t pgsize = SZ_4K;
> +
> + if (!IS_ALIGNED(iova | size, pgsize)) {
> + pr_err("unaligned: iova 0x%lx size 0x%zx min_pagesz
> 0x%x\n",
> +    iova, size, pgsize);
> + return -EINVAL;
> + }
> +
> + while (unmapped < size) {
> + unmapped_page = domain->ops->unmap(domain, iova,
> pgsize);
> + if (!unmapped_page)
> + break;
> +
> + iova += unmapped_page;
> + unmapped += unmapped_page;
> + }
> +
> + return unmapped;
> +}
> +
> +static int etnaviv_domain_map(struct iommu_domain *domain, unsigned
> long iova,
> +  phys_addr_t paddr, size_t size, int prot)
> +{
> + unsigned long orig_iova = iova;
> + size_t pgsize = SZ_4K;
> + size_t orig_size = size;
> + int ret = 0;
> +
> + if (!IS_ALIGNED(iova | paddr | size, pgsize)) {
> + pr_err("unaligned: iova 0x%lx pa %pa size 0x%zx
> min_pagesz 0x%x\n",
> +    iova, , size, pgsize);
> + return -EINVAL;
> + }
> +
> + while (size) {
> + ret = domain->ops->map(domain, iova, paddr, pgsize,
> prot);
> + if (ret)
> + break;
> +
> + iova += pgsize;
> + paddr += pgsize;
> + size -= pgsize;
> + }
> +
> + /* unroll mapping in case something went wrong */
> + if (ret)
> + etnaviv_domain_unmap(domain, orig_iova, orig_size -
> size);
> +
> + return ret;
> +}
> +
>  int etnaviv_iommu_map(struct etnaviv_iommu *iommu, u32 iova,
>   struct sg_table *sgt, unsigned len, int prot)
>  {
> @@ -40,7 +94,7 @@ int etnaviv_iommu_map(struct etnaviv_iommu *iommu,
> u32 iova,
>  
>   VERB("map[%d]: %08x %08x(%zx)", i, iova, pa, bytes);
>  
> - ret = iommu_map(domain, da, pa, bytes, prot);
> + ret = etnaviv_domain_map(domain, da, pa, bytes,
> prot);
>   if (ret)
>   goto fail;
>  
> @@ -55,7 +109,7 @@ int etnaviv_iommu_map(struct etnaviv_iommu *iommu,
> u32 iova,
>   for_each_sg(sgt->sgl, sg, i, j) {
>   size_t bytes = sg_dma_len(sg) + sg->offset;
>  
> - iommu_unmap(domain, da, bytes);
> + etnaviv_domain_unmap(domain, da, bytes);
>   da += bytes;
>   }
>   return ret;
> @@ -73,7 +127,7 @@ int etnaviv_iommu_unmap(struct etnaviv_iommu
> *iommu, u32 iova,

This could be changed to void now, the return value isn't checked
anywhere.

>   size_t bytes = sg_dma_len(sg) + sg->offset;
>   size_t unmapped;
>  
> - unmapped = iommu_unmap(domain, da, bytes);
> + unmapped = etnaviv_domain_unmap(domain, da, bytes);
>   if (unmapped < bytes)
>   return unmapped;
>  
> @@ -329,8 +383,8 @@ int etnaviv_iommu_get_suballoc_va(struct
> etnaviv_gpu *gpu, dma_addr_t paddr,
>   mutex_unlock(>lock);
>   return ret;
>   }
> - ret = iommu_map(mmu->domain, vram_node->start, paddr,
> size,
> - IOMMU_READ);
> + ret = etnaviv_domain_map(mmu->domain, vram_node-
> >start, paddr,
> +  size, IOMMU_READ);
>   if (ret < 0) {
>   drm_mm_remove_node(vram_node);
>   mutex_unlock(>lock);
> @@ -353,7 +407,7 @@ void etnaviv_iommu_put_suballoc_va(struct
> etnaviv_gpu *gpu,
>  
>   if (mmu->version == ETNAVIV_IOMMU_V2) {
>   mutex_lock(>lock);
> - iommu_unmap(mmu->domain,iova, size);
> + etnaviv_domain_unmap(mmu->domain, iova, size);
>   drm_mm_remove_node(vram_node);
>   mutex_unlock(>lock);
>   }

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


Re: [PATCH 8/8] etnaviv: remove IOMMU dependency

2017-09-18 Thread Philipp Zabel
On Fri, 2017-09-15 at 19:04 +0200, Lucas Stach wrote:
> Using the IOMMU API to manage the internal GPU MMU has been an
> historical accident and it keeps getting in the way, as well as
> entangling the driver with the inner workings of the IOMMU
> subsystem.
> 
> Clean this up by removing the usage of iommu_domain, which is the
> last piece linking etnaviv to the IOMMU subsystem.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/Kconfig|  2 -
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h  |  1 -
>  drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 71 +++
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_iommu.h|  6 ++-
>  drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 55 +++
> 
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.c  | 38 +++-
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.h  | 20 ++---
>  7 files changed, 93 insertions(+), 100 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig
> b/drivers/gpu/drm/etnaviv/Kconfig
> index 71cee4e9fefb..b0a4ee27eb05 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -7,8 +7,6 @@ config DRM_ETNAVIV
>   select SHMEM
>   select SYNC_FILE
>   select TMPFS
> - select IOMMU_API
> - select IOMMU_SUPPORT
>   select WANT_DEV_COREDUMP
>   help
>     DRM driver for Vivante GPUs.
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index 058389f93b69..d157d9379e68 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -26,7 +26,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> index 43a0508bdbd7..f0390842441a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> @@ -14,7 +14,6 @@
>   * this program.  If not, see .
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -36,20 +35,21 @@ struct etnaviv_iommu_domain_pgtable {

Should this be renamed to etnaviv_iommuv2_domain_pgtable for
consistency?

>   dma_addr_t paddr;
>  };
>  
> -struct etnaviv_iommu_domain {
> - struct iommu_domain domain;
> +struct etnaviv_iommuv1_domain {
> + struct etnaviv_iommu_domain base;
>   struct device *dev;
>   void *bad_page_cpu;
>   dma_addr_t bad_page_dma;

Now that base is etnaviv specific, these three could be moved up into
etnaviv_iommu_domain.

>   struct etnaviv_iommu_domain_pgtable pgtable;
>  };
>  
> -static struct etnaviv_iommu_domain *to_etnaviv_domain(struct
> iommu_domain *domain)
> +static struct etnaviv_iommuv1_domain *
> +to_etnaviv_domain(struct etnaviv_iommu_domain *domain)
>  {
> - return container_of(domain, struct etnaviv_iommu_domain,
> domain);
> + return container_of(domain, struct etnaviv_iommuv1_domain,
> base);
>  }
>  
> -static int __etnaviv_iommu_init(struct etnaviv_iommu_domain
> *etnaviv_domain)
> +static int __etnaviv_iommu_init(struct etnaviv_iommuv1_domain
> *etnaviv_domain)
>  {
>   u32 *p;
>   int ret, i;
> @@ -83,9 +83,10 @@ static int __etnaviv_iommu_init(struct
> etnaviv_iommu_domain *etnaviv_domain)
>   return 0;
>  }
>  
> -static void etnaviv_domain_free(struct iommu_domain *domain)
> +static void etnaviv_iommuv1_domain_free(struct etnaviv_iommu_domain
> *domain)
>  {
> - struct etnaviv_iommu_domain *etnaviv_domain =
> to_etnaviv_domain(domain);
> + struct etnaviv_iommuv1_domain *etnaviv_domain =
> + to_etnaviv_domain(domain);
>  
>   dma_free_coherent(etnaviv_domain->dev, PT_SIZE,
>     etnaviv_domain->pgtable.pgtable,
> @@ -98,10 +99,11 @@ static void etnaviv_domain_free(struct
> iommu_domain *domain)
>   kfree(etnaviv_domain);
>  }
>  
> -static int etnaviv_iommuv1_map(struct iommu_domain *domain, unsigned
> long iova,
> -    phys_addr_t paddr, size_t size, int prot)
> +static int etnaviv_iommuv1_map(struct etnaviv_iommu_domain *domain,
> +    unsigned long iova, phys_addr_t paddr,
> +    size_t size, int prot)
>  {
> - struct etnaviv_iommu_domain *etnaviv_domain =
> to_etnaviv_domain(domain);
> + struct etnaviv_iommuv1_domain *etnaviv_domain =
> to_etnaviv_domain(domain);
>   unsigned int index = (iova - GPU_MEM_START) / SZ_4K;
>  
>   if (size != SZ_4K)
> @@ -112,10 +114,11 @@ static int etnaviv_iommuv1_map(struct
> iommu_domain *domain, unsigned long iova,
>   return 0;
>  }
>  
> -static size_t etnaviv_iommuv1_unmap(struct iommu_domain *domain,
> +static size_t etnaviv_iommuv1_unmap(struct etnaviv_iommu_domain
> *domain,
>   unsigned long iova, size_t size)
>  {
> - struct etnaviv_iommu_domain *etnaviv_domain =
> to_etnaviv_domain(domain);
> + struct 

[PATCH] drm: add backwards compatibility support for drm_kms_helper.edid_firmware

2017-09-18 Thread Jani Nikula
Add drm_kms_helper.edid_firmware module parameter with param ops hooks
to set drm.edid_firmware instead, for backwards compatibility.

Suggested-by: Ville Syrjälä 
Cc: Abdiel Janulgue 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid_load.c | 16 
 drivers/gpu/drm/drm_kms_helper_common.c | 28 
 include/drm/drm_edid.h  |  2 ++
 3 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 1c0495acf341..a4915099aaa9 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -31,6 +31,22 @@ module_param_string(edid_firmware, edid_firmware, 
sizeof(edid_firmware), 0644);
 MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID blob 
"
"from built-in data or /lib/firmware instead. ");
 
+/* Use only for backward compatibility with drm_kms_helper.edid_firmware */
+int __drm_set_edid_firmware_path(const char *path)
+{
+   scnprintf(edid_firmware, sizeof(edid_firmware), "%s", path);
+
+   return 0;
+}
+EXPORT_SYMBOL(__drm_set_edid_firmware_path);
+
+/* Use only for backward compatibility with drm_kms_helper.edid_firmware */
+int __drm_get_edid_firmware_path(char *buf, size_t bufsize)
+{
+   return scnprintf(buf, bufsize, "%s", edid_firmware);
+}
+EXPORT_SYMBOL(__drm_get_edid_firmware_path);
+
 #define GENERIC_EDIDS 6
 static const char * const generic_edid_name[GENERIC_EDIDS] = {
"edid/800x600.bin",
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c 
b/drivers/gpu/drm/drm_kms_helper_common.c
index 6e35a56a6102..5051c3aa4d5d 100644
--- a/drivers/gpu/drm/drm_kms_helper_common.c
+++ b/drivers/gpu/drm/drm_kms_helper_common.c
@@ -26,6 +26,7 @@
  */
 
 #include 
+#include 
 
 #include "drm_crtc_helper_internal.h"
 
@@ -33,6 +34,33 @@ MODULE_AUTHOR("David Airlie, Jesse Barnes");
 MODULE_DESCRIPTION("DRM KMS helper");
 MODULE_LICENSE("GPL and additional rights");
 
+#if IS_ENABLED(CONFIG_DRM_LOAD_EDID_FIRMWARE)
+
+/* Backward compatibility for drm_kms_helper.edid_firmware */
+static int edid_firmware_set(const char *val, const struct kernel_param *kp)
+{
+   DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use 
drm.edid_firmware intead.\n");
+
+   return __drm_set_edid_firmware_path(val);
+}
+
+static int edid_firmware_get(char *buffer, const struct kernel_param *kp)
+{
+   return __drm_get_edid_firmware_path(buffer, PAGE_SIZE);
+}
+
+const struct kernel_param_ops edid_firmware_ops = {
+   .set = edid_firmware_set,
+   .get = edid_firmware_get,
+};
+
+module_param_cb(edid_firmware, _firmware_ops, NULL, 0644);
+__MODULE_PARM_TYPE(edid_firmware, "charp");
+MODULE_PARM_DESC(edid_firmware,
+"DEPRECATED. Use drm.edid_firmware module parameter instead.");
+
+#endif
+
 static int __init drm_kms_helper_init(void)
 {
int ret;
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 1e1908a6b1d6..6f35909b8add 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -341,6 +341,8 @@ int drm_av_sync_delay(struct drm_connector *connector,
 
 #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
 struct edid *drm_load_edid_firmware(struct drm_connector *connector);
+int __drm_set_edid_firmware_path(const char *path);
+int __drm_get_edid_firmware_path(char *buf, size_t bufsize);
 #else
 static inline struct edid *
 drm_load_edid_firmware(struct drm_connector *connector)
-- 
2.11.0

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


Re: [PATCH v3 2/2] drm: add backwards compatibility support for drm_kms_helper.edid_firmware

2017-09-18 Thread Jani Nikula
On Fri, 15 Sep 2017, Ville Syrjälä  wrote:
> Hmm. Wouldn't you just have to have custom kernel_param_ops and
> that's about it? Seems like that could be a bit cleaner.

Here's a shot at that. Completely untested, but seems like this should
do the trick, and is less complex than I anticipated.

BR,
Jani.


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


remove ttm trace and add iova debugfs (v2)

2017-09-18 Thread Tom St Denis
In this respin I add some changes per feedback and make the iova
entry have proper read/write methods which access pages mapped
by amdgpu.  So there is no need for /dev/mem or /dev/fmem anymore
when reading system memory.

Patches 3/4 are unchanged and remove the TTM trace from amdgpu 
and from TTM itself.


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


[PATCH 4/4] drm/ttm: Remove TTM dma tracepoint since it's not required anymore

2017-09-18 Thread Tom St Denis
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/ttm/Makefile  |  2 +-
 drivers/gpu/drm/ttm/ttm_debug.c   | 74 -
 drivers/gpu/drm/ttm/ttm_trace.h   | 87 ---
 drivers/gpu/drm/ttm/ttm_tracepoints.c | 45 --
 4 files changed, 1 insertion(+), 207 deletions(-)
 delete mode 100644 drivers/gpu/drm/ttm/ttm_debug.c
 delete mode 100644 drivers/gpu/drm/ttm/ttm_trace.h
 delete mode 100644 drivers/gpu/drm/ttm/ttm_tracepoints.c

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index ab2bef1219e5..4d0c938ff4b2 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
 ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
-   ttm_bo_manager.o ttm_page_alloc_dma.o ttm_debug.o ttm_tracepoints.o
+   ttm_bo_manager.o ttm_page_alloc_dma.o
 ttm-$(CONFIG_AGP) += ttm_agp_backend.o
 
 obj-$(CONFIG_DRM_TTM) += ttm.o
diff --git a/drivers/gpu/drm/ttm/ttm_debug.c b/drivers/gpu/drm/ttm/ttm_debug.c
deleted file mode 100644
index ef5f0d090154..
--- a/drivers/gpu/drm/ttm/ttm_debug.c
+++ /dev/null
@@ -1,74 +0,0 @@
-/**
- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- **/
-/*
- * Authors: Tom St Denis 
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "ttm_trace.h"
-
-void ttm_trace_dma_map(struct device *dev, struct ttm_dma_tt *tt)
-{
-   unsigned i;
-
-   if (unlikely(trace_ttm_dma_map_enabled())) {
-   for (i = 0; i < tt->ttm.num_pages; i++) {
-   trace_ttm_dma_map(
-   dev,
-   tt->ttm.pages[i],
-   tt->dma_address[i]);
-   }
-   }
-}
-EXPORT_SYMBOL(ttm_trace_dma_map);
-
-void ttm_trace_dma_unmap(struct device *dev, struct ttm_dma_tt *tt)
-{
-   unsigned i;
-
-   if (unlikely(trace_ttm_dma_unmap_enabled())) {
-   for (i = 0; i < tt->ttm.num_pages; i++) {
-   trace_ttm_dma_unmap(
-   dev,
-   tt->ttm.pages[i],
-   tt->dma_address[i]);
-   }
-   }
-}
-EXPORT_SYMBOL(ttm_trace_dma_unmap);
-
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h b/drivers/gpu/drm/ttm/ttm_trace.h
deleted file mode 100644
index 715ce68b7b33..
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ /dev/null
@@ -1,87 +0,0 @@
-/**
- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * 

[PATCH 1/4] drm/amd/amdgpu: Fold TTM debugfs entries into array (v2)

2017-09-18 Thread Tom St Denis
Signed-off-by: Tom St Denis 

(v2): add domains and avoid strcmp
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 54 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  4 +--
 2 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8ee16dfdb8af..50d20903de4f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1809,6 +1809,19 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
 
 #endif
 
+
+
+static const struct {
+   char *name;
+   const struct file_operations *fops;
+   int domain;
+} ttm_debugfs_entries[] = {
+   { "amdgpu_vram", _ttm_vram_fops, TTM_PL_VRAM },
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
+   { "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
+#endif
+};
+
 #endif
 
 static int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev)
@@ -1819,22 +1832,21 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
struct drm_minor *minor = adev->ddev->primary;
struct dentry *ent, *root = minor->debugfs_root;
 
-   ent = debugfs_create_file("amdgpu_vram", S_IFREG | S_IRUGO, root,
- adev, _ttm_vram_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-   i_size_write(ent->d_inode, adev->mc.mc_vram_size);
-   adev->mman.vram = ent;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-   ent = debugfs_create_file("amdgpu_gtt", S_IFREG | S_IRUGO, root,
- adev, _ttm_gtt_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-   i_size_write(ent->d_inode, adev->mc.gart_size);
-   adev->mman.gtt = ent;
+   for (count = 0; count < ARRAY_SIZE(ttm_debugfs_entries); count++) {
+   ent = debugfs_create_file(
+   ttm_debugfs_entries[count].name,
+   S_IFREG | S_IRUGO, root,
+   adev,
+   ttm_debugfs_entries[count].fops);
+   if (IS_ERR(ent))
+   return PTR_ERR(ent);
+   if (ttm_debugfs_entries[count].domain == TTM_PL_VRAM)
+   i_size_write(ent->d_inode, adev->mc.mc_vram_size);
+   else if (ttm_debugfs_entries[count].domain == TTM_PL_TT)
+   i_size_write(ent->d_inode, adev->mc.gart_size);
+   adev->mman.debugfs_entries[count] = ent;
+   }
 
-#endif
count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
@@ -1844,7 +1856,6 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
 
return amdgpu_debugfs_add_files(adev, amdgpu_ttm_debugfs_list, count);
 #else
-
return 0;
 #endif
 }
@@ -1852,14 +1863,9 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
 static void amdgpu_ttm_debugfs_fini(struct amdgpu_device *adev)
 {
 #if defined(CONFIG_DEBUG_FS)
+   unsigned i;
 
-   debugfs_remove(adev->mman.vram);
-   adev->mman.vram = NULL;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-   debugfs_remove(adev->mman.gtt);
-   adev->mman.gtt = NULL;
-#endif
-
+   for (i = 0; i < ARRAY_SIZE(ttm_debugfs_entries); i++)
+   debugfs_remove(adev->mman.debugfs_entries[i]);
 #endif
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 64709e041d5b..7abae6867339 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -24,6 +24,7 @@
 #ifndef __AMDGPU_TTM_H__
 #define __AMDGPU_TTM_H__
 
+#include "amdgpu.h"
 #include "gpu_scheduler.h"
 
 #define AMDGPU_PL_GDS  (TTM_PL_PRIV + 0)
@@ -45,8 +46,7 @@ struct amdgpu_mman {
boolinitialized;
 
 #if defined(CONFIG_DEBUG_FS)
-   struct dentry   *vram;
-   struct dentry   *gtt;
+   struct dentry   *debugfs_entries[8];
 #endif
 
/* buffer handling */
-- 
2.12.0

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


[PATCH 3/4] drm/amd/amdgpu: remove usage of ttm trace

2017-09-18 Thread Tom St Denis
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 36 +++--
 1 file changed, 3 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 02ae32378e1c..b41d03226c26 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -704,22 +703,6 @@ void amdgpu_ttm_tt_mark_user_pages(struct ttm_tt *ttm)
}
 }
 
-static void amdgpu_trace_dma_map(struct ttm_tt *ttm)
-{
-   struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
-   struct amdgpu_ttm_tt *gtt = (void *)ttm;
-
-   ttm_trace_dma_map(adev->dev, >ttm);
-}
-
-static void amdgpu_trace_dma_unmap(struct ttm_tt *ttm)
-{
-   struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
-   struct amdgpu_ttm_tt *gtt = (void *)ttm;
-
-   ttm_trace_dma_unmap(adev->dev, >ttm);
-}
-
 /* prepare the sg table with the user pages */
 static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 {
@@ -746,8 +729,6 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
 gtt->ttm.dma_address, ttm->num_pages);
 
-   amdgpu_trace_dma_map(ttm);
-
return 0;
 
 release_sg:
@@ -773,8 +754,6 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
 
amdgpu_ttm_tt_mark_user_pages(ttm);
 
-   amdgpu_trace_dma_unmap(ttm);
-
sg_free_table(ttm->sg);
 }
 
@@ -958,7 +937,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   int r;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
 
if (ttm->state != tt_unpopulated)
@@ -978,22 +956,16 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
 gtt->ttm.dma_address, 
ttm->num_pages);
ttm->state = tt_unbound;
-   r = 0;
-   goto trace_mappings;
+   return 0;
}
 
 #ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
-   r = ttm_dma_populate(>ttm, adev->dev);
-   goto trace_mappings;
+   return ttm_dma_populate(>ttm, adev->dev);
}
 #endif
 
-   r = ttm_populate_and_map_pages(adev->dev, >ttm);
-trace_mappings:
-   if (likely(!r))
-   amdgpu_trace_dma_map(ttm);
-   return r;
+   return ttm_populate_and_map_pages(adev->dev, >ttm);
 }
 
 static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
@@ -1014,8 +986,6 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
 
adev = amdgpu_ttm_adev(ttm->bdev);
 
-   amdgpu_trace_dma_unmap(ttm);
-
 #ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, adev->dev);
-- 
2.12.0

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


[PATCH 2/4] drm/amd/amdgpu: add support for iova_to_phys to replace TTM trace (v3)

2017-09-18 Thread Tom St Denis
Signed-off-by: Tom St Denis 

(v2): Add domain to iova debugfs
(v3): Add true read/write methods to access system memory of pages
  mapped to the device
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 104 
 1 file changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 50d20903de4f..02ae32378e1c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 #include "bif/bif_4_1_d.h"
@@ -1810,6 +1811,108 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
 #endif
 
 
+static void *transform_page(uint64_t phys)
+{
+   if (PageHighMem(pfn_to_page(PFN_DOWN(phys
+   return kmap(pfn_to_page(PFN_DOWN(phys)));
+   else
+   return __va(phys);
+}
+
+static void untransform_page(uint64_t phys)
+{
+   if (PageHighMem(pfn_to_page(PFN_DOWN(phys
+   return kunmap(pfn_to_page(PFN_DOWN(phys)));
+}
+
+static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,
+  size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   ssize_t result, n;
+   int r;
+   uint64_t phys;
+   void *ptr;
+
+   result = 0;
+   while (size) {
+   // get physical address and map
+   phys = iommu_iova_to_phys(iommu_get_domain_for_dev(adev->dev), 
*pos);
+
+   // copy upto one page
+   if (size > PAGE_SIZE)
+   n = PAGE_SIZE;
+   else
+   n = size;
+
+   // to end of the page
+   if (((*pos & (PAGE_SIZE - 1)) + n) >= PAGE_SIZE)
+   n = PAGE_SIZE - (*pos & (PAGE_SIZE - 1));
+
+   ptr = transform_page(phys);
+   if (!ptr)
+   return -EFAULT;
+
+   r = copy_to_user(buf, ptr, n);
+   untransform_page(phys);
+   if (r)
+   return -EFAULT;
+
+   *pos += n;
+   size -= n;
+   result += n;
+   }
+
+   return result;
+}
+
+static ssize_t amdgpu_iova_to_phys_write(struct file *f, const char __user 
*buf,
+  size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   ssize_t result, n;
+   int r;
+   uint64_t phys;
+   void *ptr;
+
+   result = 0;
+   while (size) {
+   // get physical address and map
+   phys = iommu_iova_to_phys(iommu_get_domain_for_dev(adev->dev), 
*pos);
+
+   // copy upto one page
+   if (size > PAGE_SIZE)
+   n = PAGE_SIZE;
+   else
+   n = size;
+
+   // to end of the page
+   if (((*pos & (PAGE_SIZE - 1)) + n) >= PAGE_SIZE)
+   n = PAGE_SIZE - (*pos & (PAGE_SIZE - 1));
+
+   ptr = transform_page(phys);
+   if (!ptr)
+   return -EFAULT;
+
+   r = copy_from_user(ptr, buf, n);
+   untransform_page(phys);
+   if (r)
+   return -EFAULT;
+
+   *pos += n;
+   size -= n;
+   result += n;
+   }
+
+   return result;
+}
+
+static const struct file_operations amdgpu_ttm_iova_fops = {
+   .owner = THIS_MODULE,
+   .read = amdgpu_iova_to_phys_read,
+   .write = amdgpu_iova_to_phys_write,
+   .llseek = default_llseek
+};
 
 static const struct {
char *name;
@@ -1820,6 +1923,7 @@ static const struct {
 #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },
 #endif
+   { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
 };
 
 #endif
-- 
2.12.0

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


Re: [PATCH] drm: pl111: constify amba_id

2017-09-18 Thread Eric Anholt
Arvind Yadav  writes:

> amba_id are not supposed to change at runtime. All functions
> working with const amba_id. So mark the non-const structs as const.
>
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/pl111/pl111_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index ac8771b..522875c 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -243,7 +243,7 @@ static int pl111_amba_remove(struct amba_device *amba_dev)
>   return 0;
>  }
>  
> -static struct amba_id pl111_id_table[] = {
> +static const struct amba_id pl111_id_table[] = {
>   {
>   .id = 0x0004,
>   .mask = 0x000f,
> -- 
> 2.7.4

Sorry about dropping your patch here -- Linus was working on a bigger
series for pl110 support that also happened to fix this.


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


[PATCH v2 3/4] drm/i915: Add "panel orientation" property to the panel connector

2017-09-18 Thread Hans de Goede
Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.

Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
with an upside down LCD and where the GOP is properly rotating the
EFI fb in hardware.

So instead we end up reading the rotation from the primary plane,
which is a bit more complicated.

The code to read back the rotation from the hardware is based on an
earlier attempt to fix fdo#94894 by Ville Syrjala.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Cc: Ville Syrjala 
Suggested-by: Ville Syrjala 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebased on 4.14-rc1
-Readback primary plane rotation from the hardware and use that to
 set the panel orientation
-This (readback) fixes fdo#94894, add Fixes: tag
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 +++
 drivers/gpu/drm/i915/intel_display.c | 39 +++-
 drivers/gpu/drm/i915/intel_drv.h |  5 +
 drivers/gpu/drm/i915/intel_panel.c   | 33 ++
 4 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18d9da53282b..c4c8590972b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2151,6 +2151,8 @@ struct intel_cdclk_state {
unsigned int cdclk, vco, ref;
 };
 
+struct intel_panel;
+
 struct drm_i915_private {
struct drm_device drm;
 
@@ -2200,6 +2202,7 @@ struct drm_i915_private {
struct i915_gem_context *kernel_context;
struct intel_engine_cs *engine[I915_NUM_ENGINES];
struct i915_vma *semaphore;
+   struct intel_panel *panel;
 
struct drm_dma_handle *status_page_dmah;
struct resource mch_res;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f17275519484..c40939be9599 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2891,6 +2891,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
return;
}
 
+   intel_panel_set_orientation_from_crtc(dev_priv->panel, intel_crtc,
+ plane_config->panel_orientation);
+
plane_state->src_x = 0;
plane_state->src_y = 0;
plane_state->src_w = fb->width << 16;
@@ -7523,6 +7526,10 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
plane_config->tiling = I915_TILING_X;
fb->modifier = I915_FORMAT_MOD_X_TILED;
}
+
+   if (val & DISPPLANE_ROTATE_180)
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
}
 
pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
@@ -8576,6 +8583,24 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
goto error;
}
 
+   /* The rotation is used to *correct* for the panel orientation */
+   switch (val & PLANE_CTL_ROTATE_MASK) {
+   case PLANE_CTL_ROTATE_0:
+   break;
+   case PLANE_CTL_ROTATE_90:
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+   break;
+   case PLANE_CTL_ROTATE_180:
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+   break;
+   case PLANE_CTL_ROTATE_270:
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+   break;
+   }
+
base = I915_READ(PLANE_SURF(pipe, 0)) & 0xf000;
plane_config->base = base;
 
@@ -8661,6 +8686,10 @@ ironlake_get_initial_plane_config(struct intel_crtc 
*crtc,
plane_config->tiling = I915_TILING_X;
fb->modifier = I915_FORMAT_MOD_X_TILED;
}
+
+   if (val & DISPPLANE_ROTATE_180)
+   plane_config->panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
}
 
pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
@@ -14578,7 +14607,9 @@ int intel_modeset_init(struct drm_device *dev)
drm_modeset_unlock_all(dev);
 
for_each_intel_crtc(dev, crtc) {
-   struct intel_initial_plane_config plane_config = {};
+   struct intel_initial_plane_config plane_config = {
+   .panel_orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL,
+   };
 
if (!crtc->active)
continue;
@@ -14600,6 +14631,12 @@ int intel_modeset_init(struct drm_device *dev)
   

[PATCH v2 1/4] video: fb: Make fbcon dmi quirks usuable for drm drivers too

2017-09-18 Thread Hans de Goede
Some x86 clamshell design devices use portrait tablet LCD panels and a
display engine which cannot (transparently) rotate in hardware, so we
need to rotate things in software / let user space deal with this.

The fbcon code has a set of DMI based quirks to automatically detect
such tablet LCD panels and rotate the fbcon to compensate.

The plan was for userspace (e.g. a Wayland compositor) to simply read
/sys/class/graphics/fbcon/rotate and apply the rotation from there to
the LCD panel to compensate.

However this will not work when an external monitor gets plugged in,
since with fbcon rotation is not per output, so the fbcon quirk code
disables the rotation when an external monitor is present.

Using /sys/class/graphics/fbcon/rotate will not help in that case
since it will indicate no rotation is in use. So instead we are going
to need a drm connecter property for this.

This commit is a preparation patch for adding the drm-connecter
property, by making the fbcon quirk code generally usable so that
the drm code can use it to check for rotation quirks.

Note this commit re-uses the FB_CMDLINE Kconfig option for selecting
if the quirk code should be build, since that is already selected by
both the drm and fbcon code.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebased on 4.14-rc1
---
 drivers/video/fbdev/core/Makefile  |  6 +++---
 .../core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c}   | 15 +--
 drivers/video/fbdev/core/fbcon.c   | 22 ++
 drivers/video/fbdev/core/fbcon.h   |  6 --
 include/linux/fb.h |  6 ++
 5 files changed, 32 insertions(+), 23 deletions(-)
 rename drivers/video/fbdev/core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c} (91%)

diff --git a/drivers/video/fbdev/core/Makefile 
b/drivers/video/fbdev/core/Makefile
index 73493bbd7a15..06caf037a822 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -1,4 +1,7 @@
 obj-$(CONFIG_FB_CMDLINE)  += fb_cmdline.o
+ifeq ($(CONFIG_DMI),y)
+obj-$(CONFIG_FB_CMDLINE)  += fb_dmi_quirks.o
+endif
 obj-$(CONFIG_FB_NOTIFY)   += fb_notify.o
 obj-$(CONFIG_FB)  += fb.o
 fb-y  := fbmem.o fbmon.o fbcmap.o fbsysfs.o \
@@ -14,9 +17,6 @@ ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
 fb-y += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
 fbcon_ccw.o
 endif
-ifeq ($(CONFIG_DMI),y)
-fb-y += fbcon_dmi_quirks.o
-endif
 endif
 fb-objs   := $(fb-y)
 
diff --git a/drivers/video/fbdev/core/fbcon_dmi_quirks.c 
b/drivers/video/fbdev/core/fb_dmi_quirks.c
similarity index 91%
rename from drivers/video/fbdev/core/fbcon_dmi_quirks.c
rename to drivers/video/fbdev/core/fb_dmi_quirks.c
index 6904e47d1e51..d5fdf3245f83 100644
--- a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
+++ b/drivers/video/fbdev/core/fb_dmi_quirks.c
@@ -1,5 +1,5 @@
 /*
- *  fbcon_dmi_quirks.c -- DMI based quirk detection for fbcon
+ *  fb_dmi_quirks.c -- DMI based LCD panel rotation quirk detection
  *
  * Copyright (C) 2017 Hans de Goede 
  *
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include "fbcon.h"
 
 /*
  * Some x86 clamshell design devices use portrait tablet screens and a display
@@ -112,7 +111,11 @@ static const struct dmi_system_id rotate_data[] = {
{}
 };
 
-int fbcon_platform_get_rotate(struct fb_info *info)
+/*
+ * Note this function returns the rotation necessary to put the display
+ * the right way up, or -1 if there is no quirk.
+ */
+int fb_get_panel_rotate_quirk(int width, int height)
 {
const struct dmi_system_id *match;
const struct fbcon_dmi_rotate_data *data;
@@ -124,8 +127,7 @@ int fbcon_platform_get_rotate(struct fb_info *info)
 match = dmi_first_match(match + 1)) {
data = match->driver_data;
 
-   if (data->width != info->var.xres ||
-   data->height != info->var.yres)
+   if (data->width != width || data->height != height)
continue;
 
if (!data->bios_dates)
@@ -141,5 +143,6 @@ int fbcon_platform_get_rotate(struct fb_info *info)
}
}
 
-   return FB_ROTATE_UR;
+   return -1;
 }
+EXPORT_SYMBOL_GPL(fb_get_panel_rotate_quirk);
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 04612f938bab..2e17ea02c295 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -963,10 +963,13 @@ static const char *fbcon_startup(void)
ops->cur_rotate = -1;
ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
-   if (initial_rotation != -1)
-   p->con_rotate = initial_rotation;
-   else
-   p->con_rotate = fbcon_platform_get_rotate(info);
+   

[PATCH v2 4/4] drm/fb-helper: Apply panel orientation connector prop to the primary plane

2017-09-18 Thread Hans de Goede
Apply the "panel orientation" drm connector prop to the primary plane,
so that fbcon and fbdev using userspace programs display the right way
up.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Signed-off-by: Hans de Goede 
---
Changes in v2:
-New patch in v2 of this patch-set
---
 drivers/gpu/drm/drm_fb_helper.c | 53 +++--
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1b8f013ffa65..75c409430a26 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 
+#include "drm_crtc_internal.h"
 #include "drm_crtc_helper_internal.h"
 
 static bool drm_fbdev_emulation = true;
@@ -347,6 +348,53 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
 }
 EXPORT_SYMBOL(drm_fb_helper_debug_leave);
 
+static int get_plane_rotation_from_panel_orientation(
+   struct drm_fb_helper *fb_helper, struct drm_plane *plane)
+{
+   int i, rotation = DRM_MODE_ROTATE_0;
+   struct drm_connector *conn;
+   uint64_t valid_mask = 0;
+
+   drm_fb_helper_for_each_connector(fb_helper, i) {
+   conn = fb_helper->connector_info[i]->connector;
+   if (conn->state->crtc && conn->state->crtc->primary == plane) {
+   switch (conn->display_info.panel_orientation) {
+   case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+   rotation = DRM_MODE_ROTATE_180;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+   rotation = DRM_MODE_ROTATE_90;
+   break;
+   case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+   rotation = DRM_MODE_ROTATE_270;
+   break;
+   }
+   break;
+   }
+   }
+
+   /*
+* Check the necessary rotation to compensate for the panel orientation
+* is supported.
+* Note currently we simply leave things as is when not supported, maybe
+* we shouls set a hint in fb_info to tell fbcon to rotate in this case
+* so that atleast the console ends up the right way. Maybe, but this:
+* a) Is not necessary for any known models with a non upright panel
+* b) Is tricky because fbcon rotation applies to all outputs rather
+*then a single one
+*/
+   if (!plane->rotation_property)
+   return DRM_MODE_ROTATE_0;
+
+   for (i = 0; i < plane->rotation_property->num_values; i++)
+   valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+   if (rotation & ~valid_mask)
+   return DRM_MODE_ROTATE_0;
+
+   return rotation;
+}
+
 static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool 
active)
 {
struct drm_device *dev = fb_helper->dev;
@@ -376,8 +424,9 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper, bool activ
goto out_state;
}
 
-   plane_state->rotation = DRM_MODE_ROTATE_0;
-
+   plane_state->rotation =
+   get_plane_rotation_from_panel_orientation(fb_helper,
+ plane);
plane->old_fb = plane->fb;
plane_mask |= 1 << drm_plane_index(plane);
 
-- 
2.14.1

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


[PATCH v2 2/4] drm: Add support for a panel-orientation connector property

2017-09-18 Thread Hans de Goede
On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).

This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to communicate how the panel is
orientated vs the casing.

Userspace can use this property to check for non-normal orientation and
then adjust the displayed image accordingly by rotating it to compensate.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Rebased on 4.14-rc1
-Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
 access it easily
-Have a single drm_connector_init_panel_orientation_property rather then
 create and attach functions. The caller is expected to set
 drm_display_info.panel_orientation before calling this, then this will
 check for platform specific quirks overriding the panel_orientation and if
 the panel_orientation is set after this then it will attach the property.
---
 drivers/gpu/drm/drm_connector.c | 86 +
 include/drm/drm_connector.h | 11 ++
 include/drm/drm_mode_config.h   |  7 
 include/uapi/drm/drm_mode.h |  7 
 4 files changed, 111 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ba9f36cef68c..0159800b30a7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -212,6 +212,8 @@ int drm_connector_init(struct drm_device *dev,
mutex_init(>mutex);
connector->edid_blob_ptr = NULL;
connector->status = connector_status_unknown;
+   connector->display_info.panel_orientation =
+   DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
 
drm_connector_get_cmdline_mode(connector);
 
@@ -665,6 +667,13 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
+   { DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
+   { DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
+   { DRM_MODE_PANEL_ORIENTATION_LEFT_UP,   "Left Side Up"  },
+   { DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,  "Right Side Up" },
+};
+
 static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID,  "DVI-D" }, /* DVI-I  */
@@ -746,6 +755,18 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  *
  * CRTC_ID:
  * Mode object ID of the _crtc this connector should be connected to.
+ *
+ * Connectors for LCD panels may also have one standardized property:
+ *
+ * panel orientation:
+ * On some devices the LCD panel is mounted in the casing in such a way
+ * that the up/top side of the panel does not match with the top side of
+ * the device. Userspace can use this property to check for this.
+ * Note that input coordinates from touchscreens (input devices with
+ * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
+ * coordinates, so if userspace rotates the picture to adjust for
+ * the orientation it must also apply the same transformation to the
+ * touchscreen input coordinates.
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1212,6 +1233,71 @@ void drm_mode_connector_set_link_status_property(struct 
drm_connector *connector
 }
 EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
 
+/**
+ * drm_connector_init_panel_orientation_property -
+ * initialize the connecters panel_orientation property
+ * @connector: connector for which to init the panel-orientation property.
+ * @width: width in pixels of the panel, used for panel quirk detection
+ * @height: height in pixels of the panel, used for panel quirk detection
+ *
+ * This function should only be called for built-in panels, after setting
+ * connector->display_info.panel_orientation first (if known).
+ *
+ * This function will check for platform specific (e.g. DMI based) quirks
+ * overriding display_info.panel_orientation first, then if panel_orientation
+ * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
+ * "panel orientation" property to the connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_init_panel_orientation_property(
+   struct drm_connector *connector, int width, int height)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_display_info *info = >display_info;
+   struct drm_property *prop;
+
+   /*
+* Note fb_get_panel_rotate_quirk returns the rotation needed to
+* *correct* for the panel orientation.
+*/
+   switch (fb_get_panel_rotate_quirk(width, height)) {
+   case FB_ROTATE_UR:
+   info->panel_orientation = 

[PATCH v2] drm: exynos: Add driver for HDMI audio interface

2017-09-18 Thread Sylwester Nawrocki
The hdmi-codec interface added in this patch is required to properly
support HDMI audio. Currently the audio part of the SoC internal
HDMI transmitter is configured with fixed values, which makes HDMI
audio working by chance, only on boards having an external audio
codec connected in parallel with the HDMI audio transmitter's input
I2S interface.

Signed-off-by: Sylwester Nawrocki 
---
Patch tested on Odroid XU3 and Odroid XU4 with Ubuntu 14.04.

Changes since v1:
 - rebased onto v4.14-rc1 and adapted locking

Changes since RFC version:
 - fixed hdmi-codec locking issue
 - added a comment documenting struct hdmi_contex::mutex
---
 drivers/gpu/drm/exynos/Kconfig   |   1 +
 drivers/gpu/drm/exynos/exynos_hdmi.c | 253 +--
 2 files changed, 210 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 305dc3d..5a7c9d8 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -3,6 +3,7 @@ config DRM_EXYNOS
depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM)
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
+   select SND_SOC_HDMI_CODEC if SND_SOC
help
  Choose this option if you have a Samsung SoC EXYNOS chipset.
  If M is selected the module will be called exynosdrm.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 214fa5e..dc254b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 

 #include 
@@ -111,12 +111,19 @@ struct hdmi_driver_data {
struct string_array_spec clk_muxes;
 };

+struct hdmi_audio {
+   struct platform_device *pdev;
+   struct hdmi_audio_infoframe infoframe;
+   unsigned int sample_rate;
+   unsigned int sample_width;
+   u8 enable;
+};
+
 struct hdmi_context {
struct drm_encoder  encoder;
struct device   *dev;
struct drm_device   *drm_dev;
struct drm_connectorconnector;
-   boolpowered;
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
@@ -137,6 +144,11 @@ struct hdmi_context {
struct regulator*reg_hdmi_en;
struct exynos_drm_clk   phy_clk;
struct drm_bridge   *bridge;
+
+   /* mutex protecting subsequent fields below */
+   struct mutexmutex;
+   struct hdmi_audio   audio;
+   boolpowered;
 };

 static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
@@ -768,6 +780,22 @@ static int hdmi_clk_set_parents(struct hdmi_context 
*hdata, bool to_phy)
return ret;
 }

+static int hdmi_audio_infoframe_apply(struct hdmi_context *hdata)
+{
+   struct hdmi_audio_infoframe *infoframe = >audio.infoframe;
+   u8 buf[HDMI_INFOFRAME_SIZE(AUDIO)];
+   int len;
+
+   len = hdmi_audio_infoframe_pack(infoframe, buf, sizeof(buf));
+   if (len < 0)
+   return len;
+
+   hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
+   hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, len);
+
+   return 0;
+}
+
 static void hdmi_reg_infoframes(struct hdmi_context *hdata)
 {
union hdmi_infoframe frm;
@@ -805,15 +833,7 @@ static void hdmi_reg_infoframes(struct hdmi_context *hdata)
hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
}

-   ret = hdmi_audio_infoframe_init();
-   if (!ret) {
-   frm.audio.channels = 2;
-   ret = hdmi_audio_infoframe_pack(, buf, sizeof(buf));
-   }
-   if (ret > 0) {
-   hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
-   hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, ret);
-   }
+   hdmi_audio_infoframe_apply(hdata);
 }

 static enum drm_connector_status hdmi_detect(struct drm_connector *connector,
@@ -995,23 +1015,18 @@ static void hdmi_reg_acr(struct hdmi_context *hdata, u32 
freq)
hdmi_reg_writeb(hdata, HDMI_ACR_CON, 4);
 }

-static void hdmi_audio_init(struct hdmi_context *hdata)
+static void hdmi_audio_config(struct hdmi_context *hdata)
 {
-   u32 sample_rate, bits_per_sample;
-   u32 data_num, bit_ch, sample_frq;
-   u32 val;
+   u32 data_num, sample_freq, val;
+   u32 bit_ch = 1;

-   sample_rate = 44100;
-   bits_per_sample = 16;

-   switch (bits_per_sample) {
+   switch (hdata->audio.sample_width) {
case 20:
data_num = 2;
-   bit_ch = 1;
break;
case 24:
data_num = 3;
-   bit_ch = 1;
   

Re: [PATCHv4 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-09-18 Thread Ville Syrjälä
On Mon, Sep 18, 2017 at 05:26:43PM +0200, Hans Verkuil wrote:
> On 09/18/2017 04:36 PM, Ville Syrjälä wrote:
> > On Mon, Sep 18, 2017 at 04:07:41PM +0200, Hans Verkuil wrote:
> >> Hi Ville,
> >>
> >> On 09/18/2017 03:05 PM, Ville Syrjälä wrote:
> >>> On Sat, Sep 16, 2017 at 04:17:26PM +0200, Hans Verkuil wrote:
>  From: Hans Verkuil 
> 
>  Implement support for this DisplayPort feature.
> 
>  The cec device is created whenever it detects an adapter that
>  has this feature. It is only removed when a new adapter is connected
>  that does not support this. If a new adapter is connected that has
>  different properties than the previous one, then the old cec device is
>  unregistered and a new one is registered to replace the old one.
> 
>  Signed-off-by: Hans Verkuil 
>  Tested-by: Carlos Santa 
>  ---
>   drivers/gpu/drm/i915/intel_dp.c | 18 ++
>   1 file changed, 14 insertions(+), 4 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>  b/drivers/gpu/drm/i915/intel_dp.c
>  index 64fa774c855b..fdb853d2c458 100644
>  --- a/drivers/gpu/drm/i915/intel_dp.c
>  +++ b/drivers/gpu/drm/i915/intel_dp.c
>  @@ -32,6 +32,7 @@
>   #include 
>   #include 
>   #include 
>  +#include 
>   #include 
>   #include 
>   #include 
>  @@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp 
>  *intel_dp)
>   static void
>   intel_dp_aux_fini(struct intel_dp *intel_dp)
>   {
>  +cec_unregister_adapter(intel_dp->aux.cec_adap);
>   kfree(intel_dp->aux.name);
>   }
>   
>  @@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>   intel_connector->detect_edid = edid;
>   
>   intel_dp->has_audio = drm_detect_monitor_audio(edid);
>  +cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
>   }
>   
>   static void
>  @@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>   
>   kfree(intel_connector->detect_edid);
>   intel_connector->detect_edid = NULL;
>  +cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>   
>   intel_dp->has_audio = false;
>   }
>  @@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector 
>  *intel_connector)
>   intel_display_power_get(to_i915(dev), 
>  intel_dp->aux_power_domain);
>   
>   /* Can't disconnect eDP, but you can close the lid... */
>  -if (is_edp(intel_dp))
>  +if (is_edp(intel_dp)) {
>   status = edp_detect(intel_dp);
>  -else if (intel_digital_port_connected(to_i915(dev),
>  -  dp_to_dig_port(intel_dp)))
>  +} else if (intel_digital_port_connected(to_i915(dev),
>  +
>  dp_to_dig_port(intel_dp))) {
>   status = intel_dp_detect_dpcd(intel_dp);
>  -else
>  +if (status == connector_status_connected)
>  +drm_dp_cec_configure_adapter(_dp->aux,
>  + intel_dp->aux.name, dev->dev);
> >>>
> >>> This is cluttering up the code a bit. Maybe do this call somewhere
> >>> around the intel_dp_configure_mst() call instead since that seems to be
> >>> the place where we start to do changes to externally visible state.
> >>>
> >>> Actually, do we want to register cec adapters for MST devices?
> >>>
> >>> And shouldn't we call this regardless of the connector state so that
> >>> the cec adapter gets unregistered when the device is disconnected?
> >>
> >> This hasn't (AFAIK) anything to do with MST. This is in a branch device 
> >> (i.e.
> >> a DP to HDMI adapter).
> > 
> > You are now potentiall registering the CEC adapter to the immediately
> > upstream MST device (ie. the one that we talk to over the normal AUX stuff),
> > but kms will consider that paticular connector as disconnected, and
> > instead only sinks downstream of that device may have connected connectors
> > associated with them. Presumably the CEC towards that device goes
> > nowhere, and instead we'd have to talk to the remote branch devices
> > somewhere downstream.
> > 
> > Thus my question whether we want to potentially register the CEC adapter
> > to the immediately upstream MST device or not. I would imagine not, and
> > thus the call should perhaps be moved past the 'is_mst? -> disconnected'
> > checks.
> 
> Ah, now I see what you mean. Sorry, I misunderstood you earlier. I can
> certainly move it down. But an MST device would never set the CEC capability
> in the DPCD, would it?

It might. You don't even have to drive it as an MST device if you don't
want to, or you source device 

Re: [PATCHv4 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-09-18 Thread Hans Verkuil
On 09/18/2017 04:36 PM, Ville Syrjälä wrote:
> On Mon, Sep 18, 2017 at 04:07:41PM +0200, Hans Verkuil wrote:
>> Hi Ville,
>>
>> On 09/18/2017 03:05 PM, Ville Syrjälä wrote:
>>> On Sat, Sep 16, 2017 at 04:17:26PM +0200, Hans Verkuil wrote:
 From: Hans Verkuil 

 Implement support for this DisplayPort feature.

 The cec device is created whenever it detects an adapter that
 has this feature. It is only removed when a new adapter is connected
 that does not support this. If a new adapter is connected that has
 different properties than the previous one, then the old cec device is
 unregistered and a new one is registered to replace the old one.

 Signed-off-by: Hans Verkuil 
 Tested-by: Carlos Santa 
 ---
  drivers/gpu/drm/i915/intel_dp.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c 
 b/drivers/gpu/drm/i915/intel_dp.c
 index 64fa774c855b..fdb853d2c458 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -32,6 +32,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp 
 *intel_dp)
  static void
  intel_dp_aux_fini(struct intel_dp *intel_dp)
  {
 +  cec_unregister_adapter(intel_dp->aux.cec_adap);
kfree(intel_dp->aux.name);
  }
  
 @@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
  
intel_dp->has_audio = drm_detect_monitor_audio(edid);
 +  cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
  }
  
  static void
 @@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
  
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
 +  cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
  
intel_dp->has_audio = false;
  }
 @@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector 
 *intel_connector)
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
  
/* Can't disconnect eDP, but you can close the lid... */
 -  if (is_edp(intel_dp))
 +  if (is_edp(intel_dp)) {
status = edp_detect(intel_dp);
 -  else if (intel_digital_port_connected(to_i915(dev),
 -dp_to_dig_port(intel_dp)))
 +  } else if (intel_digital_port_connected(to_i915(dev),
 +  dp_to_dig_port(intel_dp))) {
status = intel_dp_detect_dpcd(intel_dp);
 -  else
 +  if (status == connector_status_connected)
 +  drm_dp_cec_configure_adapter(_dp->aux,
 +   intel_dp->aux.name, dev->dev);
>>>
>>> This is cluttering up the code a bit. Maybe do this call somewhere
>>> around the intel_dp_configure_mst() call instead since that seems to be
>>> the place where we start to do changes to externally visible state.
>>>
>>> Actually, do we want to register cec adapters for MST devices?
>>>
>>> And shouldn't we call this regardless of the connector state so that
>>> the cec adapter gets unregistered when the device is disconnected?
>>
>> This hasn't (AFAIK) anything to do with MST. This is in a branch device (i.e.
>> a DP to HDMI adapter).
> 
> You are now potentiall registering the CEC adapter to the immediately
> upstream MST device (ie. the one that we talk to over the normal AUX stuff),
> but kms will consider that paticular connector as disconnected, and
> instead only sinks downstream of that device may have connected connectors
> associated with them. Presumably the CEC towards that device goes
> nowhere, and instead we'd have to talk to the remote branch devices
> somewhere downstream.
> 
> Thus my question whether we want to potentially register the CEC adapter
> to the immediately upstream MST device or not. I would imagine not, and
> thus the call should perhaps be moved past the 'is_mst? -> disconnected'
> checks.

Ah, now I see what you mean. Sorry, I misunderstood you earlier. I can
certainly move it down. But an MST device would never set the CEC capability
in the DPCD, would it? That makes no sense. So it would never register a
CEC device in practice. Although I do need to test what happens when you
first connect a USB-C to HDMI adapter that supports CEC, then disconnect it,
then connect an MST hub. The CEC device should be unregistered in that case,
but I'm not sure if that actually happens. I'll have to test that tomorrow.

> 
>>
>> The CEC adapter should ideally be associated with the branch device (since 
>> that
>> is what implements the CEC tunneling): i.e. when you connect the adapter, 
>> then
>> 

[Bug 102840] nouveau PGRAPH - ERROR nsource: ILLEGAL_MTHD nstatus: PROTECTION_FAULT

2017-09-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102840

Pierre Moreau  changed:

   What|Removed |Added

  Component|DRM/other   |Driver/nouveau
 QA Contact||xorg-t...@lists.x.org
Product|DRI |xorg
   Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
   |.org|rg

-- 
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] drm/bridge/sii8620: add remote control support

2017-09-18 Thread Hans Verkuil
On 09/18/2017 04:15 PM, Maciej Purski wrote:
> Hi Hans,
> some time ago in reply to your email I described what messages does
> the MHL driver receive and at what time intervals.
> Regarding that information, do you think that a similar solution as
> in [1] is required? Would it be OK, if I just set REP_DELAY and REP_PERIOD
> to values, which I presented in my last email?

Based on the timings you measured I would say that there is a 99% chance that 
MHL
uses exactly the same "Press and Hold" mechanism as CEC. Since you already 
specify
RC_PROTO_BIT_CEC in the driver, it will set REP_DELAY and REP_PERIOD to the 
right
values automatically.

You will have to implement the same code as in cec-adap.c for the key press 
handling,
though. It's a bit tricky to get it right.

Since you will have to do the same thing as I do in CEC, I wonder if it would 
make
more sense to move this code to the RC core. Basically it ensures that repeat 
mode
doesn't turn on until you get two identical key presses 550ms or less apart. 
This
is independent of REP_DELAY which can be changed by userspace.

Sean, what do you think?

Regards,

Hans

> 
> 
> Best Regards,
> 
>   Maciej
> 
> [1] 
> https://git.linuxtv.org/media_tree.git/commit/drivers/media/cec/cec-adap.c?id=a9a249a2c997506a64eaee22f1458fda893f62a8
> 
> On 08/27/2017 02:40 PM, Hans Verkuil wrote:
> 
>> Hi Maciej,
>>
>> On 24/08/17 10:58, Maciej Purski wrote:
>>> MHL specification defines Remote Control Protocol(RCP) to
>>> send input events between MHL devices.
>>> The driver now recognizes RCP messages and reacts to them
>>> by reporting key events to input subsystem, allowing
>>> a user to control a device using TV remote control.
>> Before I Ack this I would like to know how this behaves w.r.t. autorepeat.
>>
>> If you keep pressing a remote key, what RCP messages do you receive and
>> at what time intervals? If that's similar to what CEC does, then it is
>> very likely that the same rules apply and I will have to review this patch
>> again with that in mind.
>>
>> See the commit log for the patching fixing the CEC 'Press and Hold' behavior:
>>
>> https://git.linuxtv.org/media_tree.git/commit/drivers/media/cec/cec-adap.c?id=a9a249a2c997506a64eaee22f1458fda893f62a8
>>
>> If you have access to the HDMI 2.0 specification, then that spec describes 
>> the CEC
>> 'Press and Hold' behavior in detail.
>>
>> Regards,
>>
>>  Hans
>>
>>> Signed-off-by: Maciej Purski 
>>> ---
>>>
>>> Changes in v2:
>>> - use RC subsystem (including CEC keymap)
>>> - RC device initialized in attach drm_bridge callback and
>>>removed in detach callback. This is necessary, because RC_CORE,
>>>which is needed during rc_dev init, is loaded after sii8620.
>>>DRM bridge is binded later which solves the problem.
>>> - add RC_CORE dependency
>>>
>>> Changes in v3:
>>> - fix error handling in init_rcp and in attach callback
>>>
>>> Changes in v4:
>>> - usage of rc-core API compatible with upcoming changes
>>> - fix error handling in init_rcp
>>> - fix commit message
>>> ---
>>>   drivers/gpu/drm/bridge/Kconfig   |  2 +-
>>>   drivers/gpu/drm/bridge/sil-sii8620.c | 96 
>>> ++--
>>>   include/drm/bridge/mhl.h |  4 ++
>>>   3 files changed, 96 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>>> index adf9ae0..6ef901c 100644
>>> --- a/drivers/gpu/drm/bridge/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/Kconfig
>>> @@ -71,7 +71,7 @@ config DRM_PARADE_PS8622
>>>   
>>>   config DRM_SIL_SII8620
>>> tristate "Silicon Image SII8620 HDMI/MHL bridge"
>>> -   depends on OF
>>> +   depends on OF && RC_CORE
>>> select DRM_KMS_HELPER
>>> help
>>>   Silicon Image SII8620 HDMI/MHL bridge chip driver.
>>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
>>> b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> index 2d51a22..ecb26c4 100644
>>> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
>>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
>>> @@ -28,6 +28,8 @@
>>>   #include 
>>>   #include 
>>>   
>>> +#include 
>>> +
>>>   #include "sil-sii8620.h"
>>>   
>>>   #define SII8620_BURST_BUF_LEN 288
>>> @@ -58,6 +60,7 @@ enum sii8620_mt_state {
>>>   struct sii8620 {
>>> struct drm_bridge bridge;
>>> struct device *dev;
>>> +   struct rc_dev *rc_dev;
>>> struct clk *clk_xtal;
>>> struct gpio_desc *gpio_reset;
>>> struct gpio_desc *gpio_int;
>>> @@ -431,6 +434,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 
>>> code)
>>> sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
>>>   }
>>>   
>>> +static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)
>>> +{
>>> +   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
>>> +}
>>> +
>>> +static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
>>> +{
>>> +   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
>>> +}
>>> +
>>>   static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
>>>

Re: [PATCHv4 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-09-18 Thread Ville Syrjälä
On Mon, Sep 18, 2017 at 04:07:41PM +0200, Hans Verkuil wrote:
> Hi Ville,
> 
> On 09/18/2017 03:05 PM, Ville Syrjälä wrote:
> > On Sat, Sep 16, 2017 at 04:17:26PM +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> Implement support for this DisplayPort feature.
> >>
> >> The cec device is created whenever it detects an adapter that
> >> has this feature. It is only removed when a new adapter is connected
> >> that does not support this. If a new adapter is connected that has
> >> different properties than the previous one, then the old cec device is
> >> unregistered and a new one is registered to replace the old one.
> >>
> >> Signed-off-by: Hans Verkuil 
> >> Tested-by: Carlos Santa 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dp.c | 18 ++
> >>  1 file changed, 14 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index 64fa774c855b..fdb853d2c458 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -32,6 +32,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp 
> >> *intel_dp)
> >>  static void
> >>  intel_dp_aux_fini(struct intel_dp *intel_dp)
> >>  {
> >> +  cec_unregister_adapter(intel_dp->aux.cec_adap);
> >>kfree(intel_dp->aux.name);
> >>  }
> >>  
> >> @@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
> >>intel_connector->detect_edid = edid;
> >>  
> >>intel_dp->has_audio = drm_detect_monitor_audio(edid);
> >> +  cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
> >>  }
> >>  
> >>  static void
> >> @@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> >>  
> >>kfree(intel_connector->detect_edid);
> >>intel_connector->detect_edid = NULL;
> >> +  cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
> >>  
> >>intel_dp->has_audio = false;
> >>  }
> >> @@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector 
> >> *intel_connector)
> >>intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
> >>  
> >>/* Can't disconnect eDP, but you can close the lid... */
> >> -  if (is_edp(intel_dp))
> >> +  if (is_edp(intel_dp)) {
> >>status = edp_detect(intel_dp);
> >> -  else if (intel_digital_port_connected(to_i915(dev),
> >> -dp_to_dig_port(intel_dp)))
> >> +  } else if (intel_digital_port_connected(to_i915(dev),
> >> +  dp_to_dig_port(intel_dp))) {
> >>status = intel_dp_detect_dpcd(intel_dp);
> >> -  else
> >> +  if (status == connector_status_connected)
> >> +  drm_dp_cec_configure_adapter(_dp->aux,
> >> +   intel_dp->aux.name, dev->dev);
> > 
> > This is cluttering up the code a bit. Maybe do this call somewhere
> > around the intel_dp_configure_mst() call instead since that seems to be
> > the place where we start to do changes to externally visible state.
> > 
> > Actually, do we want to register cec adapters for MST devices?
> > 
> > And shouldn't we call this regardless of the connector state so that
> > the cec adapter gets unregistered when the device is disconnected?
> 
> This hasn't (AFAIK) anything to do with MST. This is in a branch device (i.e.
> a DP to HDMI adapter).

You are now potentiall registering the CEC adapter to the immediately
upstream MST device (ie. the one that we talk to over the normal AUX stuff),
but kms will consider that paticular connector as disconnected, and
instead only sinks downstream of that device may have connected connectors
associated with them. Presumably the CEC towards that device goes
nowhere, and instead we'd have to talk to the remote branch devices
somewhere downstream.

Thus my question whether we want to potentially register the CEC adapter
to the immediately upstream MST device or not. I would imagine not, and
thus the call should perhaps be moved past the 'is_mst? -> disconnected'
checks.

> 
> The CEC adapter should ideally be associated with the branch device (since 
> that
> is what implements the CEC tunneling): i.e. when you connect the adapter, then
> the CEC device is created, when you disconnect the adapter, then the CEC 
> device
> should be unregistered. This is not the same as connecting/disconnecting the
> HDMI cable to/from the adapter: that just sets or invalidates the CEC physical
> address (which is read from the EDID).
> 
> However, I have not seen any code that tells me when the adapter is plugged in
> or is unplugged. So all I have to go on is when the HDMI cable is connected.
> 
> Note that the 'late_register' you mentioned in your 1/3 review isn't called 
> when
> connecting the adapter. So that too cannot be used as a trigger to detect 

[Bug 102840] nouveau PGRAPH - ERROR nsource: ILLEGAL_MTHD nstatus: PROTECTION_FAULT

2017-09-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102840

Bug ID: 102840
   Summary: nouveau PGRAPH - ERROR nsource: ILLEGAL_MTHD nstatus:
PROTECTION_FAULT
   Product: DRI
   Version: unspecified
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: philippe.ney...@mailz.org

Hi !

First I don't really know if my problem is posted at the right place, sorry for
that, but I don't really understand all the categories...

I got some wrong text rendering in console, and some missing graphical object
under X.

I've found some messages in logs such as :
Sep 18 15:39:44 pluton kernel: [  176.941808] [drm] nouveau :01:00.0:
PFIFO_CACHE_ERROR - Ch 3/4 Mthd 0x Data 0x8804
Sep 18 15:39:44 pluton kernel: [  176.941840] [drm] nouveau :01:00.0:
PGRAPH - ERROR nsource: ILLEGAL_MTHD nstatus: PROTECTION_FAULT
Sep 18 15:39:44 pluton kernel: [  176.941854] [drm] nouveau :01:00.0:
PGRAPH - ch 3 (0x00075000) subc 4 class 0x mthd 0x0180 data 0x7308

I've found that this bug is old but can't find a solution.

I've tried to install the Nvidia driver, but it freezes at boot, even I made a
/etc/X11/xorg.conf file (with nvidia-xconfig).

I'm running Debian Wheezy (up to date):
uname :
Linux pluton 3.2.0-4-rt-686-pae #1 SMP PREEMPT RT Debian 3.2.89-2 i686
GNU/Linux

Can you help me solve this ?
Please note that english is not my native language, so write as simple as you
can.

Thanks a lot.

Best regards

Philippe

-- 
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] drm/bridge/sii8620: add remote control support

2017-09-18 Thread Maciej Purski

Hi Hans,
some time ago in reply to your email I described what messages does
the MHL driver receive and at what time intervals.
Regarding that information, do you think that a similar solution as
in [1] is required? Would it be OK, if I just set REP_DELAY and REP_PERIOD
to values, which I presented in my last email?


Best Regards,

Maciej

[1] 
https://git.linuxtv.org/media_tree.git/commit/drivers/media/cec/cec-adap.c?id=a9a249a2c997506a64eaee22f1458fda893f62a8

On 08/27/2017 02:40 PM, Hans Verkuil wrote:


Hi Maciej,

On 24/08/17 10:58, Maciej Purski wrote:

MHL specification defines Remote Control Protocol(RCP) to
send input events between MHL devices.
The driver now recognizes RCP messages and reacts to them
by reporting key events to input subsystem, allowing
a user to control a device using TV remote control.

Before I Ack this I would like to know how this behaves w.r.t. autorepeat.

If you keep pressing a remote key, what RCP messages do you receive and
at what time intervals? If that's similar to what CEC does, then it is
very likely that the same rules apply and I will have to review this patch
again with that in mind.

See the commit log for the patching fixing the CEC 'Press and Hold' behavior:

https://git.linuxtv.org/media_tree.git/commit/drivers/media/cec/cec-adap.c?id=a9a249a2c997506a64eaee22f1458fda893f62a8

If you have access to the HDMI 2.0 specification, then that spec describes the 
CEC
'Press and Hold' behavior in detail.

Regards,

Hans


Signed-off-by: Maciej Purski 
---

Changes in v2:
- use RC subsystem (including CEC keymap)
- RC device initialized in attach drm_bridge callback and
   removed in detach callback. This is necessary, because RC_CORE,
   which is needed during rc_dev init, is loaded after sii8620.
   DRM bridge is binded later which solves the problem.
- add RC_CORE dependency

Changes in v3:
- fix error handling in init_rcp and in attach callback

Changes in v4:
- usage of rc-core API compatible with upcoming changes
- fix error handling in init_rcp
- fix commit message
---
  drivers/gpu/drm/bridge/Kconfig   |  2 +-
  drivers/gpu/drm/bridge/sil-sii8620.c | 96 ++--
  include/drm/bridge/mhl.h |  4 ++
  3 files changed, 96 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..6ef901c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -71,7 +71,7 @@ config DRM_PARADE_PS8622
  
  config DRM_SIL_SII8620

tristate "Silicon Image SII8620 HDMI/MHL bridge"
-   depends on OF
+   depends on OF && RC_CORE
select DRM_KMS_HELPER
help
  Silicon Image SII8620 HDMI/MHL bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2d51a22..ecb26c4 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -28,6 +28,8 @@
  #include 
  #include 
  
+#include 

+
  #include "sil-sii8620.h"
  
  #define SII8620_BURST_BUF_LEN 288

@@ -58,6 +60,7 @@ enum sii8620_mt_state {
  struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+   struct rc_dev *rc_dev;
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -431,6 +434,16 @@ static void sii8620_mt_rap(struct sii8620 *ctx, u8 code)
sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RAP, code);
  }
  
+static void sii8620_mt_rcpk(struct sii8620 *ctx, u8 code)

+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPK, code);
+}
+
+static void sii8620_mt_rcpe(struct sii8620 *ctx, u8 code)
+{
+   sii8620_mt_msc_msg(ctx, MHL_MSC_MSG_RCPE, code);
+}
+
  static void sii8620_mt_read_devcap_send(struct sii8620 *ctx,
struct sii8620_mt_msg *msg)
  {
@@ -1753,6 +1766,25 @@ static void sii8620_send_features(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
  }
  
+static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)

+{
+   bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
+
+   scancode &= MHL_RCP_KEY_ID_MASK;
+
+   if (!ctx->rc_dev) {
+   dev_dbg(ctx->dev, "RCP input device not initialized\n");
+   return false;
+   }
+
+   if (pressed)
+   rc_keydown(ctx->rc_dev, RC_PROTO_CEC, scancode, 0);
+   else
+   rc_keyup(ctx->rc_dev);
+
+   return true;
+}
+
  static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
  {
u8 ints[MHL_INT_SIZE];
@@ -1804,19 +1836,25 @@ static void sii8620_msc_mt_done(struct sii8620 *ctx)
  
  static void sii8620_msc_mr_msc_msg(struct sii8620 *ctx)

  {
-   struct sii8620_mt_msg *msg = sii8620_msc_msg_first(ctx);
+   struct sii8620_mt_msg *msg;
u8 buf[2];
  
-	if (!msg)

-   return;
-
sii8620_read_buf(ctx, 

Re: [PATCHv4 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-09-18 Thread Hans Verkuil
Hi Ville,

On 09/18/2017 03:05 PM, Ville Syrjälä wrote:
> On Sat, Sep 16, 2017 at 04:17:26PM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> Implement support for this DisplayPort feature.
>>
>> The cec device is created whenever it detects an adapter that
>> has this feature. It is only removed when a new adapter is connected
>> that does not support this. If a new adapter is connected that has
>> different properties than the previous one, then the old cec device is
>> unregistered and a new one is registered to replace the old one.
>>
>> Signed-off-by: Hans Verkuil 
>> Tested-by: Carlos Santa 
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 18 ++
>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 64fa774c855b..fdb853d2c458 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -32,6 +32,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp 
>> *intel_dp)
>>  static void
>>  intel_dp_aux_fini(struct intel_dp *intel_dp)
>>  {
>> +cec_unregister_adapter(intel_dp->aux.cec_adap);
>>  kfree(intel_dp->aux.name);
>>  }
>>  
>> @@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>>  intel_connector->detect_edid = edid;
>>  
>>  intel_dp->has_audio = drm_detect_monitor_audio(edid);
>> +cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
>>  }
>>  
>>  static void
>> @@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>>  
>>  kfree(intel_connector->detect_edid);
>>  intel_connector->detect_edid = NULL;
>> +cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>>  
>>  intel_dp->has_audio = false;
>>  }
>> @@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector 
>> *intel_connector)
>>  intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
>>  
>>  /* Can't disconnect eDP, but you can close the lid... */
>> -if (is_edp(intel_dp))
>> +if (is_edp(intel_dp)) {
>>  status = edp_detect(intel_dp);
>> -else if (intel_digital_port_connected(to_i915(dev),
>> -  dp_to_dig_port(intel_dp)))
>> +} else if (intel_digital_port_connected(to_i915(dev),
>> +dp_to_dig_port(intel_dp))) {
>>  status = intel_dp_detect_dpcd(intel_dp);
>> -else
>> +if (status == connector_status_connected)
>> +drm_dp_cec_configure_adapter(_dp->aux,
>> + intel_dp->aux.name, dev->dev);
> 
> This is cluttering up the code a bit. Maybe do this call somewhere
> around the intel_dp_configure_mst() call instead since that seems to be
> the place where we start to do changes to externally visible state.
> 
> Actually, do we want to register cec adapters for MST devices?
> 
> And shouldn't we call this regardless of the connector state so that
> the cec adapter gets unregistered when the device is disconnected?

This hasn't (AFAIK) anything to do with MST. This is in a branch device (i.e.
a DP to HDMI adapter).

The CEC adapter should ideally be associated with the branch device (since that
is what implements the CEC tunneling): i.e. when you connect the adapter, then
the CEC device is created, when you disconnect the adapter, then the CEC device
should be unregistered. This is not the same as connecting/disconnecting the
HDMI cable to/from the adapter: that just sets or invalidates the CEC physical
address (which is read from the EDID).

However, I have not seen any code that tells me when the adapter is plugged in
or is unplugged. So all I have to go on is when the HDMI cable is connected.

Note that the 'late_register' you mentioned in your 1/3 review isn't called when
connecting the adapter. So that too cannot be used as a trigger to detect if
this protocol is supported.

I know doing this here is not ideal, but I have not found another way and I am
not even certain if it is possible at all, it might be intrinsic to how DP 
works.
I do not consider myself a DP expert, though.

So this is how it works now, e.g. on my Intel NUC and a USB-C to HDMI adapter:

1) I connect the adapter (no HDMI connected yet): nothing happens.
2) I connect the HDMI cable to the adapter: drm_dp_cec_configure_adapter is 
called and
   it detects the CEC capability in the DPCD. It now creates the CEC device.
3) I disconnect the HDMI cable: the physical address of the CEC device is 
invalidated,
   but the CEC device is not removed.
4) I disconnect the adapter: nothing happens.
5) I reconnect the adapter: nothing happens.
6) I reconnect the HDMI cable: drm_dp_cec_configure_adapter is called and it 
checks the
   DPCD. If the capabilities are 

[Bug 102380] intel_gpu_top: Test requirement not met in function drm_open_driver_master, file drmtest.c:391:

2017-09-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102380

Petri Latvala  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Petri Latvala  ---
Fixed in eeff6a1d9c4e2c195b30ad95ee36a58ef6ca3387.

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


Re: [PATCH 1/4] drm/amd/amdgpu: Fold TTM debugfs entries into array

2017-09-18 Thread Christian König

Am 18.09.2017 um 15:01 schrieb Tom St Denis:

On 18/09/17 08:48 AM, Christian König wrote:

Am 18.09.2017 um 14:35 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 53 
++---

  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  4 +--
  2 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

index 8ee16dfdb8af..7848ffa99eb4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1809,6 +1809,18 @@ static const struct file_operations 
amdgpu_ttm_gtt_fops = {

  #endif
+
+
+static const struct {
+char *name;
+const struct file_operations *fops;
+} ttm_debugfs_entries[] = {
+{ "amdgpu_vram", _ttm_vram_fops },
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
+{ "amdgpu_gtt", _ttm_gtt_fops },
+#endif
+};
+
  #endif
  static int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev)
@@ -1819,22 +1831,21 @@ static int amdgpu_ttm_debugfs_init(struct 
amdgpu_device *adev)

  struct drm_minor *minor = adev->ddev->primary;
  struct dentry *ent, *root = minor->debugfs_root;
-ent = debugfs_create_file("amdgpu_vram", S_IFREG | S_IRUGO, root,
-  adev, _ttm_vram_fops);
-if (IS_ERR(ent))
-return PTR_ERR(ent);
-i_size_write(ent->d_inode, adev->mc.mc_vram_size);
-adev->mman.vram = ent;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-ent = debugfs_create_file("amdgpu_gtt", S_IFREG | S_IRUGO, root,
-  adev, _ttm_gtt_fops);
-if (IS_ERR(ent))
-return PTR_ERR(ent);
-i_size_write(ent->d_inode, adev->mc.gart_size);
-adev->mman.gtt = ent;
+for (count = 0; count < ARRAY_SIZE(ttm_debugfs_entries); 
count++) {

+ent = debugfs_create_file(
+ttm_debugfs_entries[count].name,
+S_IFREG | S_IRUGO, root,
+adev,
+ttm_debugfs_entries[count].fops);
+if (IS_ERR(ent))
+return PTR_ERR(ent);
+if (!strcmp(ttm_debugfs_entries[count].name, "amdgpu_vram"))
+i_size_write(ent->d_inode, adev->mc.mc_vram_size);
+else if (!strcmp(ttm_debugfs_entries[count].name, 
"amdgpu_gtt"))

+i_size_write(ent->d_inode, adev->mc.gart_size);


Uff, string compare? That is screaming break me by typo.

Maybe but the domain type into the struct as well?

Apart from that looks good to me,



Sure, a quick grep didn't turn up any defines/enums for VRAM vs GTT 
though so just make some up?


Just use TTM_PL_VRAM and TTM_PL_TT for this.

Christian.



Tom



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


Re: [PATCH 1/4] drm/amd/amdgpu: Fold TTM debugfs entries into array

2017-09-18 Thread Tom St Denis

On 18/09/17 08:48 AM, Christian König wrote:

Am 18.09.2017 um 14:35 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 53 
++---

  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  4 +--
  2 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

index 8ee16dfdb8af..7848ffa99eb4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1809,6 +1809,18 @@ static const struct file_operations 
amdgpu_ttm_gtt_fops = {

  #endif
+
+
+static const struct {
+    char *name;
+    const struct file_operations *fops;
+} ttm_debugfs_entries[] = {
+    { "amdgpu_vram", _ttm_vram_fops },
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
+    { "amdgpu_gtt", _ttm_gtt_fops },
+#endif
+};
+
  #endif
  static int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev)
@@ -1819,22 +1831,21 @@ static int amdgpu_ttm_debugfs_init(struct 
amdgpu_device *adev)

  struct drm_minor *minor = adev->ddev->primary;
  struct dentry *ent, *root = minor->debugfs_root;
-    ent = debugfs_create_file("amdgpu_vram", S_IFREG | S_IRUGO, root,
-  adev, _ttm_vram_fops);
-    if (IS_ERR(ent))
-    return PTR_ERR(ent);
-    i_size_write(ent->d_inode, adev->mc.mc_vram_size);
-    adev->mman.vram = ent;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-    ent = debugfs_create_file("amdgpu_gtt", S_IFREG | S_IRUGO, root,
-  adev, _ttm_gtt_fops);
-    if (IS_ERR(ent))
-    return PTR_ERR(ent);
-    i_size_write(ent->d_inode, adev->mc.gart_size);
-    adev->mman.gtt = ent;
+    for (count = 0; count < ARRAY_SIZE(ttm_debugfs_entries); count++) {
+    ent = debugfs_create_file(
+    ttm_debugfs_entries[count].name,
+    S_IFREG | S_IRUGO, root,
+    adev,
+    ttm_debugfs_entries[count].fops);
+    if (IS_ERR(ent))
+    return PTR_ERR(ent);
+    if (!strcmp(ttm_debugfs_entries[count].name, "amdgpu_vram"))
+    i_size_write(ent->d_inode, adev->mc.mc_vram_size);
+    else if (!strcmp(ttm_debugfs_entries[count].name, "amdgpu_gtt"))
+    i_size_write(ent->d_inode, adev->mc.gart_size);


Uff, string compare? That is screaming break me by typo.

Maybe but the domain type into the struct as well?

Apart from that looks good to me,



Sure, a quick grep didn't turn up any defines/enums for VRAM vs GTT 
though so just make some up?


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


Re: [PATCHv4 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-09-18 Thread Ville Syrjälä
On Sat, Sep 16, 2017 at 04:17:26PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Implement support for this DisplayPort feature.
> 
> The cec device is created whenever it detects an adapter that
> has this feature. It is only removed when a new adapter is connected
> that does not support this. If a new adapter is connected that has
> different properties than the previous one, then the old cec device is
> unregistered and a new one is registered to replace the old one.
> 
> Signed-off-by: Hans Verkuil 
> Tested-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 64fa774c855b..fdb853d2c458 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp 
> *intel_dp)
>  static void
>  intel_dp_aux_fini(struct intel_dp *intel_dp)
>  {
> + cec_unregister_adapter(intel_dp->aux.cec_adap);
>   kfree(intel_dp->aux.name);
>  }
>  
> @@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
>   intel_connector->detect_edid = edid;
>  
>   intel_dp->has_audio = drm_detect_monitor_audio(edid);
> + cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
>  }
>  
>  static void
> @@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
>  
>   kfree(intel_connector->detect_edid);
>   intel_connector->detect_edid = NULL;
> + cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
>  
>   intel_dp->has_audio = false;
>  }
> @@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>   intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
>  
>   /* Can't disconnect eDP, but you can close the lid... */
> - if (is_edp(intel_dp))
> + if (is_edp(intel_dp)) {
>   status = edp_detect(intel_dp);
> - else if (intel_digital_port_connected(to_i915(dev),
> -   dp_to_dig_port(intel_dp)))
> + } else if (intel_digital_port_connected(to_i915(dev),
> + dp_to_dig_port(intel_dp))) {
>   status = intel_dp_detect_dpcd(intel_dp);
> - else
> + if (status == connector_status_connected)
> + drm_dp_cec_configure_adapter(_dp->aux,
> +  intel_dp->aux.name, dev->dev);

This is cluttering up the code a bit. Maybe do this call somewhere
around the intel_dp_configure_mst() call instead since that seems to be
the place where we start to do changes to externally visible state.

Actually, do we want to register cec adapters for MST devices?

And shouldn't we call this regardless of the connector state so that
the cec adapter gets unregistered when the device is disconnected?

> + } else {
>   status = connector_status_disconnected;
> + }
>  
>   if (status == connector_status_disconnected) {
>   memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
> @@ -5011,6 +5019,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>  
>   intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
>  
> + drm_dp_cec_irq(_dp->aux);
> +
>   if (intel_dp->is_mst) {
>   if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
>   /*
> -- 
> 2.14.1

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


Re: [PATCHv4 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

2017-09-18 Thread Ville Syrjälä
On Sat, Sep 16, 2017 at 04:17:24PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This adds support for the DisplayPort CEC-Tunneling-over-AUX
> feature that is part of the DisplayPort 1.3 standard.
> 
> Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
> chip that has this capability actually hook up the CEC pin, so
> even though a CEC device is created, it may not actually work.
> 

FYI we prefer to put the changelog into the commit message. Makes it
easier to see which version of the patch we're dealing with, and avoids
having to open up some other mail when doing the review.

> Signed-off-by: Hans Verkuil 
> Tested-by: Carlos Santa 
> ---
>  drivers/gpu/drm/Kconfig  |  10 ++
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/drm_dp_cec.c | 292 
> +++
>  include/drm/drm_dp_helper.h  |  24 
>  4 files changed, 327 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_dp_cec.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 83cb2a88c204..1f2708df5c4e 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
> default case is N. Details and instructions how to build your own
> EDID data are given in Documentation/EDID/HOWTO.txt.
>  
> +config DRM_DP_CEC
> + bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> + select CEC_CORE
> + help
> +   Choose this option if you want to enable HDMI CEC support for
> +   DisplayPort/USB-C to HDMI adapters.
> +
> +   Note: not all adapters support this feature, and even for those
> +   that do support this they often do not hook up the CEC pin.
> +
>  config DRM_TTM
>   tristate
>   depends on DRM && MMU
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 24a066e1841c..c6552c62049e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
> drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> +drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
>  
>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>  obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> new file mode 100644
> index ..d110cac007de
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -0,0 +1,292 @@
> +/*
> + * DisplayPort CEC-Tunneling-over-AUX support
> + *
> + * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
> reserved.
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Unfortunately it turns out that we have a chicken-and-egg situation
> + * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
> + * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
> + * Parade PS176), but they do not wire up the CEC pin, thus making CEC
> + * useless.
> + *
> + * Sadly there is no way for this driver to know this. What happens is
> + * that a /dev/cecX device is created that is isolated and unable to see
> + * any of the other CEC devices. Quite literally the CEC wire is cut
> + * (or in this case, never connected in the first place).
> + *
> + * I suspect that the reason so few adapters support this is that this
> + * tunneling protocol was never supported by any OS. So there was no
> + * easy way of testing it, and no incentive to correctly wire up the
> + * CEC pin.
> + *
> + * Hopefully by creating this driver it will be easier for vendors to
> + * finally fix their adapters and test the CEC functionality.
> + *
> + * I keep a list of known working adapters here:
> + *
> + * https://hverkuil.home.xs4all.nl/cec-status.txt
> + *
> + * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
> + * and is not yet listed there.
> + */
> +
> +/**
> + * DOC: dp cec helpers
> + *
> + * These functions take care of 

Re: [PATCH 2/4] drm/amd/amdgpu: add support for iova_to_phys to replace TTM trace

2017-09-18 Thread Tom St Denis

On 18/09/17 08:52 AM, Christian König wrote:

Am 18.09.2017 um 14:35 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 


  1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

index 7848ffa99eb4..b4c298925e2a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -43,6 +43,7 @@
  #include 
  #include 
  #include 
+#include 
  #include "amdgpu.h"
  #include "amdgpu_trace.h"
  #include "bif/bif_4_1_d.h"
@@ -1810,6 +1811,36 @@ static const struct file_operations 
amdgpu_ttm_gtt_fops = {

  #endif
+static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user 
*buf,

+   size_t size, loff_t *pos)
+{
+    struct amdgpu_device *adev = file_inode(f)->i_private;
+    int r;
+    uint64_t phys;
+
+    // always return 8 bytes
+    if (size != 8)
+    return -EINVAL;
+
+    // only accept page addresses
+    if (*pos & 0xFFF)
+    return -EINVAL;
+
+
+    phys = iommu_iova_to_phys(iommu_get_domain_for_dev(adev->dev), 
*pos);


Well how about adding directly read/write support for the page behind 
the address?


This way we won't need to fiddle with /dev/mem any more either.



Given the flak we got from requesting this from the iommu team I'm 
worried that might not be appreciated by the community (even though we 
maintain this part of the tree) and hurt our abilities to upstream.


I agree that adding a read/write method would be better though since we 
don't need config changes of /dev/fmem anymore.


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


Re: [PATCH 2/4] drm/amd/amdgpu: add support for iova_to_phys to replace TTM trace

2017-09-18 Thread Christian König

Am 18.09.2017 um 14:35 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 
  1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7848ffa99eb4..b4c298925e2a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -43,6 +43,7 @@
  #include 
  #include 
  #include 
+#include 
  #include "amdgpu.h"
  #include "amdgpu_trace.h"
  #include "bif/bif_4_1_d.h"
@@ -1810,6 +1811,36 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
  #endif
  
  
+static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,

+  size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   int r;
+   uint64_t phys;
+
+   // always return 8 bytes
+   if (size != 8)
+   return -EINVAL;
+
+   // only accept page addresses
+   if (*pos & 0xFFF)
+   return -EINVAL;
+
+
+   phys = iommu_iova_to_phys(iommu_get_domain_for_dev(adev->dev), *pos);


Well how about adding directly read/write support for the page behind 
the address?


This way we won't need to fiddle with /dev/mem any more either.

Christian.


+
+   r = copy_to_user(buf, , 8);
+   if (r)
+   return -EFAULT;
+
+   return 8;
+}
+
+static const struct file_operations amdgpu_ttm_iova_fops = {
+   .owner = THIS_MODULE,
+   .read = amdgpu_iova_to_phys_read,
+   .llseek = default_llseek
+};
  
  static const struct {

char *name;
@@ -1819,6 +1850,7 @@ static const struct {
  #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops },
  #endif
+   { "amdgpu_iova", _ttm_iova_fops },
  };
  
  #endif



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


Re: [PATCH 1/4] drm/amd/amdgpu: Fold TTM debugfs entries into array

2017-09-18 Thread Christian König

Am 18.09.2017 um 14:35 schrieb Tom St Denis:

Signed-off-by: Tom St Denis 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 53 ++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  4 +--
  2 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8ee16dfdb8af..7848ffa99eb4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1809,6 +1809,18 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
  
  #endif
  
+

+
+static const struct {
+   char *name;
+   const struct file_operations *fops;
+} ttm_debugfs_entries[] = {
+   { "amdgpu_vram", _ttm_vram_fops },
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
+   { "amdgpu_gtt", _ttm_gtt_fops },
+#endif
+};
+
  #endif
  
  static int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev)

@@ -1819,22 +1831,21 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
struct drm_minor *minor = adev->ddev->primary;
struct dentry *ent, *root = minor->debugfs_root;
  
-	ent = debugfs_create_file("amdgpu_vram", S_IFREG | S_IRUGO, root,

- adev, _ttm_vram_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-   i_size_write(ent->d_inode, adev->mc.mc_vram_size);
-   adev->mman.vram = ent;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-   ent = debugfs_create_file("amdgpu_gtt", S_IFREG | S_IRUGO, root,
- adev, _ttm_gtt_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-   i_size_write(ent->d_inode, adev->mc.gart_size);
-   adev->mman.gtt = ent;
+   for (count = 0; count < ARRAY_SIZE(ttm_debugfs_entries); count++) {
+   ent = debugfs_create_file(
+   ttm_debugfs_entries[count].name,
+   S_IFREG | S_IRUGO, root,
+   adev,
+   ttm_debugfs_entries[count].fops);
+   if (IS_ERR(ent))
+   return PTR_ERR(ent);
+   if (!strcmp(ttm_debugfs_entries[count].name, "amdgpu_vram"))
+   i_size_write(ent->d_inode, adev->mc.mc_vram_size);
+   else if (!strcmp(ttm_debugfs_entries[count].name, "amdgpu_gtt"))
+   i_size_write(ent->d_inode, adev->mc.gart_size);


Uff, string compare? That is screaming break me by typo.

Maybe but the domain type into the struct as well?

Apart from that looks good to me,
Christian.


+   adev->mman.debugfs_entries[count] = ent;
+   }
  
-#endif

count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
  
  #ifdef CONFIG_SWIOTLB

@@ -1844,7 +1855,6 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
  
  	return amdgpu_debugfs_add_files(adev, amdgpu_ttm_debugfs_list, count);

  #else
-
return 0;
  #endif
  }
@@ -1852,14 +1862,9 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
  static void amdgpu_ttm_debugfs_fini(struct amdgpu_device *adev)
  {
  #if defined(CONFIG_DEBUG_FS)
+   unsigned i;
  
-	debugfs_remove(adev->mman.vram);

-   adev->mman.vram = NULL;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-   debugfs_remove(adev->mman.gtt);
-   adev->mman.gtt = NULL;
-#endif
-
+   for (i = 0; i < ARRAY_SIZE(ttm_debugfs_entries); i++)
+   debugfs_remove(adev->mman.debugfs_entries[i]);
  #endif
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 64709e041d5b..7abae6867339 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -24,6 +24,7 @@
  #ifndef __AMDGPU_TTM_H__
  #define __AMDGPU_TTM_H__
  
+#include "amdgpu.h"

  #include "gpu_scheduler.h"
  
  #define AMDGPU_PL_GDS		(TTM_PL_PRIV + 0)

@@ -45,8 +46,7 @@ struct amdgpu_mman {
boolinitialized;
  
  #if defined(CONFIG_DEBUG_FS)

-   struct dentry   *vram;
-   struct dentry   *gtt;
+   struct dentry   *debugfs_entries[8];
  #endif
  
  	/* buffer handling */



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


[PATCH 4/4] drm/ttm: Remove TTM dma tracepoint since it's not required anymore

2017-09-18 Thread Tom St Denis
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/ttm/Makefile  |  2 +-
 drivers/gpu/drm/ttm/ttm_debug.c   | 74 -
 drivers/gpu/drm/ttm/ttm_trace.h   | 87 ---
 drivers/gpu/drm/ttm/ttm_tracepoints.c | 45 --
 4 files changed, 1 insertion(+), 207 deletions(-)
 delete mode 100644 drivers/gpu/drm/ttm/ttm_debug.c
 delete mode 100644 drivers/gpu/drm/ttm/ttm_trace.h
 delete mode 100644 drivers/gpu/drm/ttm/ttm_tracepoints.c

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index ab2bef1219e5..4d0c938ff4b2 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
 ttm-y := ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
-   ttm_bo_manager.o ttm_page_alloc_dma.o ttm_debug.o ttm_tracepoints.o
+   ttm_bo_manager.o ttm_page_alloc_dma.o
 ttm-$(CONFIG_AGP) += ttm_agp_backend.o
 
 obj-$(CONFIG_DRM_TTM) += ttm.o
diff --git a/drivers/gpu/drm/ttm/ttm_debug.c b/drivers/gpu/drm/ttm/ttm_debug.c
deleted file mode 100644
index ef5f0d090154..
--- a/drivers/gpu/drm/ttm/ttm_debug.c
+++ /dev/null
@@ -1,74 +0,0 @@
-/**
- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- **/
-/*
- * Authors: Tom St Denis 
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "ttm_trace.h"
-
-void ttm_trace_dma_map(struct device *dev, struct ttm_dma_tt *tt)
-{
-   unsigned i;
-
-   if (unlikely(trace_ttm_dma_map_enabled())) {
-   for (i = 0; i < tt->ttm.num_pages; i++) {
-   trace_ttm_dma_map(
-   dev,
-   tt->ttm.pages[i],
-   tt->dma_address[i]);
-   }
-   }
-}
-EXPORT_SYMBOL(ttm_trace_dma_map);
-
-void ttm_trace_dma_unmap(struct device *dev, struct ttm_dma_tt *tt)
-{
-   unsigned i;
-
-   if (unlikely(trace_ttm_dma_unmap_enabled())) {
-   for (i = 0; i < tt->ttm.num_pages; i++) {
-   trace_ttm_dma_unmap(
-   dev,
-   tt->ttm.pages[i],
-   tt->dma_address[i]);
-   }
-   }
-}
-EXPORT_SYMBOL(ttm_trace_dma_unmap);
-
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h b/drivers/gpu/drm/ttm/ttm_trace.h
deleted file mode 100644
index 715ce68b7b33..
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ /dev/null
@@ -1,87 +0,0 @@
-/**
- *
- * Copyright (c) 2017 Advanced Micro Devices, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * 

[PATCH 2/4] drm/amd/amdgpu: add support for iova_to_phys to replace TTM trace

2017-09-18 Thread Tom St Denis
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7848ffa99eb4..b4c298925e2a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
 #include "bif/bif_4_1_d.h"
@@ -1810,6 +1811,36 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
 #endif
 
 
+static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,
+  size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   int r;
+   uint64_t phys;
+
+   // always return 8 bytes 
+   if (size != 8)
+   return -EINVAL;
+
+   // only accept page addresses
+   if (*pos & 0xFFF)
+   return -EINVAL;
+
+
+   phys = iommu_iova_to_phys(iommu_get_domain_for_dev(adev->dev), *pos);
+
+   r = copy_to_user(buf, , 8);
+   if (r)
+   return -EFAULT;
+
+   return 8;
+}
+
+static const struct file_operations amdgpu_ttm_iova_fops = {
+   .owner = THIS_MODULE,
+   .read = amdgpu_iova_to_phys_read,
+   .llseek = default_llseek
+};
 
 static const struct {
char *name;
@@ -1819,6 +1850,7 @@ static const struct {
 #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops },
 #endif
+   { "amdgpu_iova", _ttm_iova_fops },
 };
 
 #endif
-- 
2.12.0

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


[PATCH 1/4] drm/amd/amdgpu: Fold TTM debugfs entries into array

2017-09-18 Thread Tom St Denis
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 53 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  4 +--
 2 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8ee16dfdb8af..7848ffa99eb4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1809,6 +1809,18 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
 
 #endif
 
+
+
+static const struct {
+   char *name;
+   const struct file_operations *fops;
+} ttm_debugfs_entries[] = {
+   { "amdgpu_vram", _ttm_vram_fops },
+#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
+   { "amdgpu_gtt", _ttm_gtt_fops },
+#endif
+};
+
 #endif
 
 static int amdgpu_ttm_debugfs_init(struct amdgpu_device *adev)
@@ -1819,22 +1831,21 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
struct drm_minor *minor = adev->ddev->primary;
struct dentry *ent, *root = minor->debugfs_root;
 
-   ent = debugfs_create_file("amdgpu_vram", S_IFREG | S_IRUGO, root,
- adev, _ttm_vram_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-   i_size_write(ent->d_inode, adev->mc.mc_vram_size);
-   adev->mman.vram = ent;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-   ent = debugfs_create_file("amdgpu_gtt", S_IFREG | S_IRUGO, root,
- adev, _ttm_gtt_fops);
-   if (IS_ERR(ent))
-   return PTR_ERR(ent);
-   i_size_write(ent->d_inode, adev->mc.gart_size);
-   adev->mman.gtt = ent;
+   for (count = 0; count < ARRAY_SIZE(ttm_debugfs_entries); count++) {
+   ent = debugfs_create_file(
+   ttm_debugfs_entries[count].name,
+   S_IFREG | S_IRUGO, root,
+   adev,
+   ttm_debugfs_entries[count].fops);
+   if (IS_ERR(ent))
+   return PTR_ERR(ent);
+   if (!strcmp(ttm_debugfs_entries[count].name, "amdgpu_vram"))
+   i_size_write(ent->d_inode, adev->mc.mc_vram_size);
+   else if (!strcmp(ttm_debugfs_entries[count].name, "amdgpu_gtt"))
+   i_size_write(ent->d_inode, adev->mc.gart_size);
+   adev->mman.debugfs_entries[count] = ent;
+   }
 
-#endif
count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
@@ -1844,7 +1855,6 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
 
return amdgpu_debugfs_add_files(adev, amdgpu_ttm_debugfs_list, count);
 #else
-
return 0;
 #endif
 }
@@ -1852,14 +1862,9 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
 static void amdgpu_ttm_debugfs_fini(struct amdgpu_device *adev)
 {
 #if defined(CONFIG_DEBUG_FS)
+   unsigned i;
 
-   debugfs_remove(adev->mman.vram);
-   adev->mman.vram = NULL;
-
-#ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
-   debugfs_remove(adev->mman.gtt);
-   adev->mman.gtt = NULL;
-#endif
-
+   for (i = 0; i < ARRAY_SIZE(ttm_debugfs_entries); i++)
+   debugfs_remove(adev->mman.debugfs_entries[i]);
 #endif
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 64709e041d5b..7abae6867339 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -24,6 +24,7 @@
 #ifndef __AMDGPU_TTM_H__
 #define __AMDGPU_TTM_H__
 
+#include "amdgpu.h"
 #include "gpu_scheduler.h"
 
 #define AMDGPU_PL_GDS  (TTM_PL_PRIV + 0)
@@ -45,8 +46,7 @@ struct amdgpu_mman {
boolinitialized;
 
 #if defined(CONFIG_DEBUG_FS)
-   struct dentry   *vram;
-   struct dentry   *gtt;
+   struct dentry   *debugfs_entries[8];
 #endif
 
/* buffer handling */
-- 
2.12.0

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


[PATCH 3/4] drm/amd/amdgpu: remove usage of ttm trace

2017-09-18 Thread Tom St Denis
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 36 +++--
 1 file changed, 3 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b4c298925e2a..e0c37fe4d043 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -704,22 +703,6 @@ void amdgpu_ttm_tt_mark_user_pages(struct ttm_tt *ttm)
}
 }
 
-static void amdgpu_trace_dma_map(struct ttm_tt *ttm)
-{
-   struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
-   struct amdgpu_ttm_tt *gtt = (void *)ttm;
-
-   ttm_trace_dma_map(adev->dev, >ttm);
-}
-
-static void amdgpu_trace_dma_unmap(struct ttm_tt *ttm)
-{
-   struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
-   struct amdgpu_ttm_tt *gtt = (void *)ttm;
-
-   ttm_trace_dma_unmap(adev->dev, >ttm);
-}
-
 /* prepare the sg table with the user pages */
 static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 {
@@ -746,8 +729,6 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
 gtt->ttm.dma_address, ttm->num_pages);
 
-   amdgpu_trace_dma_map(ttm);
-
return 0;
 
 release_sg:
@@ -773,8 +754,6 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt *ttm)
 
amdgpu_ttm_tt_mark_user_pages(ttm);
 
-   amdgpu_trace_dma_unmap(ttm);
-
sg_free_table(ttm->sg);
 }
 
@@ -958,7 +937,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   int r;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
 
if (ttm->state != tt_unpopulated)
@@ -978,22 +956,16 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
 gtt->ttm.dma_address, 
ttm->num_pages);
ttm->state = tt_unbound;
-   r = 0;
-   goto trace_mappings;
+   return 0;
}
 
 #ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
-   r = ttm_dma_populate(>ttm, adev->dev);
-   goto trace_mappings;
+   return ttm_dma_populate(>ttm, adev->dev);
}
 #endif
 
-   r = ttm_populate_and_map_pages(adev->dev, >ttm);
-trace_mappings:
-   if (likely(!r))
-   amdgpu_trace_dma_map(ttm);
-   return r;
+   return ttm_populate_and_map_pages(adev->dev, >ttm);
 }
 
 static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
@@ -1014,8 +986,6 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
 
adev = amdgpu_ttm_adev(ttm->bdev);
 
-   amdgpu_trace_dma_unmap(ttm);
-
 #ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, adev->dev);
-- 
2.12.0

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


Remove TTM trace and use proper IOMMU api

2017-09-18 Thread Tom St Denis
These patches tidy up the amdgpu_ttm debugfs creation, add
an iova_to_phys interface and then remove the TTM trace from both
amdgpu and drm/ttm.


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


Re: [PATCH 5/7] arm64: dts: rockchip: rk3399: Correct MIPI DPHY PLL clock

2017-09-18 Thread Heiko Stübner
Hi Nickey,

Am Montag, 18. September 2017, 17:05:37 CEST schrieb Nickey Yang:
> clk_24m --> Gate11[14] --> clk_mipidphy_ref --> Gate21[0] --> clk_dphy_pll

please try to be a bit more verbose in your commit messages :-) .

It looks to me, like this patch does not depend on the other ones and
I can just pick it directly. Correct?


Heiko

> Signed-off-by: Nickey Yang 
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index d79e9b3..6aa43fd 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1629,7 +1629,7 @@
>   compatible = "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi";
>   reg = <0x0 0xff96 0x0 0x8000>;
>   interrupts = ;
> - clocks = < SCLK_MIPIDPHY_REF>, < PCLK_MIPI_DSI0>,
> + clocks = < SCLK_DPHY_PLL>, < PCLK_MIPI_DSI0>,
>< SCLK_DPHY_TX0_CFG>;
>   clock-names = "ref", "pclk", "phy_cfg";
>   power-domains = < RK3399_PD_VIO>;


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


Re: [Outreachy kernel] [PATCH v3 0/4] drm/agpsupport: Code cleanup

2017-09-18 Thread Jani Nikula
On Mon, 18 Sep 2017, Greg KH  wrote:
> On Thu, Sep 14, 2017 at 01:36:17PM +0530, Meghana Madhyastha wrote:
>> Removes checkpath.pl errors and warnings.
>> 
>> Changes in v3:
>>  -Change commit title prefix from drm to drm/agpsupport
>>  -Split the commit "Move EXPORT_SYMBOL so that it immediately follows its
>>  function" into two commits. Removing the extra blank line is 
>>  now a separate commit.
>>  -Included merging conditionals in "Remove assignment in if condition"
>>  in the commit message
>> 
>> Meghana Madhyastha (4):
>>   drm/agpsupport: Replace "foo * bar" with "foo *bar"
>>   drm/agpsupport: Remove assignment in if condition
>>   drm/agpsupport: Move EXPORT_SYMBOL so that it immediately follows its
>> function
>>   drm/agpsupport: Remove extra blank line
>
> Note, I can't do anything with patches that are outside of
> drivers/staging/ for outreachy submissions.  Hopefully the drm
> developers are ok with this, it's up to them to accept these...

We'll take care of them.

Thanks,
Jani.

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


[Bug 102694] LLVM triggered Diagnostic Handler: Illegal instruction detected: VOP* instruction uses the constant bus more than once

2017-09-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102694

Christoph Haag  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
Summary|Astrokill Beta: LLVM|LLVM triggered Diagnostic
   |triggered Diagnostic|Handler: Illegal
   |Handler: Illegal|instruction detected: VOP*
   |instruction detected: VOP*  |instruction uses the
   |instruction uses the|constant bus more than once
   |constant bus more than once |

--- Comment #6 from Christoph Haag  ---
Tried unigine heaven with new builds and it works fine now.

Most likely fixed by
https://github.com/llvm-mirror/llvm/commit/11283fb2c8458150697e07d68d20ae7fe94325b5

-- 
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: [Outreachy kernel] [PATCH v3 0/4] drm/agpsupport: Code cleanup

2017-09-18 Thread Greg KH
On Thu, Sep 14, 2017 at 01:36:17PM +0530, Meghana Madhyastha wrote:
> Removes checkpath.pl errors and warnings.
> 
> Changes in v3:
>  -Change commit title prefix from drm to drm/agpsupport
>  -Split the commit "Move EXPORT_SYMBOL so that it immediately follows its
>  function" into two commits. Removing the extra blank line is 
>  now a separate commit.
>  -Included merging conditionals in "Remove assignment in if condition"
>  in the commit message
> 
> Meghana Madhyastha (4):
>   drm/agpsupport: Replace "foo * bar" with "foo *bar"
>   drm/agpsupport: Remove assignment in if condition
>   drm/agpsupport: Move EXPORT_SYMBOL so that it immediately follows its
> function
>   drm/agpsupport: Remove extra blank line

Note, I can't do anything with patches that are outside of
drivers/staging/ for outreachy submissions.  Hopefully the drm
developers are ok with this, it's up to them to accept these...

thanks,

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


Re: [PATCH v3 1/2] drm/bridge: Add Cadence DSI driver

2017-09-18 Thread Boris Brezillon
On Thu, 7 Sep 2017 15:06:13 +0530
Archit Taneja  wrote:

> Hi,
> 
> On 08/31/2017 09:25 PM, Boris Brezillon wrote:
> > Add a driver for Cadence DPI -> DSI bridge.
> > 
> > This driver only support a subset of Cadence DSI bridge capabilities.
> > 
> > Here is a non-exhaustive list of missing features:
> >   * burst mode
> >   * dynamic configuration of the DPHY based on the
> >   * support for additional input interfaces (SDI input)
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> > Changes in v3:
> > - replace magic values by real timing calculation. The DPHY PLL clock
> >is still hardcoded since we don't have a working DPHY block yet, and
> >this is the piece of HW we need to dynamically configure the PLL
> >rate based on the display refresh rate and the resolution.
> > - parse DSI devices represented with the OF-graph. This is needed to
> >support DSI devices controlled through an external bus like I2C or
> >SPI.
> > - use the DRM panel-bridge infrastructure to simplify the DRM panel
> >logic
> > 
> > Changes in v2:
> > - rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
> > - return the correct error when devm_clk_get(sysclk) fails
> > - add missing depends on OF and select DRM_PANEL in the Kconfig entry
> > ---
> >   drivers/gpu/drm/bridge/Kconfig|9 +
> >   drivers/gpu/drm/bridge/Makefile   |1 +
> >   drivers/gpu/drm/bridge/cdns-dsi.c | 1090 
> > +
> >   3 files changed, 1100 insertions(+)
> >   create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c
> > 
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index adf9ae0e0b7c..88c324b12e16 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -25,6 +25,15 @@ config DRM_ANALOGIX_ANX78XX
> >   the HDMI output of an application processor to MyDP
> >   or DisplayPort.
> >   
> > +config DRM_CDNS_DSI
> > +   tristate "Cadence DPI/DSI bridge"
> > +   select DRM_KMS_HELPER
> > +   select DRM_MIPI_DSI
> > +   select DRM_PANEL
> > +   depends on OF
> > +   help
> > + Support Cadence DPI to DSI bridge.  
> 
> Maybe we can briefly mention here that it's a internal bridge/IP, and not an 
> external chip?

Sure.

> 
> > +
> >   config DRM_DUMB_VGA_DAC
> > tristate "Dumb VGA DAC Bridge support"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index defcf1e7ca1c..77b65e8ecf59 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -1,4 +1,5 @@
> >   obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > +obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> >   obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> >   obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> >   obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> > megachips-stdp-ge-b850v3-fw.o
> > diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
> > b/drivers/gpu/drm/bridge/cdns-dsi.c  
> 
> 
> 
> > +
> > +static void cdns_dsi_bridge_disable(struct drm_bridge *bridge)
> > +{
> > +   struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> > +   struct cdns_dsi *dsi = input_to_dsi(input);
> > +   u32 val;
> > +
> > +   val = readl(dsi->regs + MCTL_MAIN_DATA_CTL);
> > +   val &= ~(IF_VID_SELECT_MASK | IF_VID_MODE | VID_EN | HOST_EOT_GEN |
> > +DISP_EOT_GEN);  
> 
> I see some truncation related sparse warnings here and a couple of other 
> places
> when building against arm32. Those would be nice to fix.

I'll have a look.


> > +static int cdns_dsi_attach(struct mipi_dsi_host *host,
> > +  struct mipi_dsi_device *dev)
> > +{
> > +   struct cdns_dsi *dsi = to_cdns_dsi(host);
> > +   struct cdns_dsi_output *output = >output;
> > +   struct cdns_dsi_input *input = >input;
> > +   struct drm_bridge *bridge;
> > +   struct drm_panel *panel;
> > +   struct device_node *np;
> > +   int ret;
> > +
> > +   /*
> > +* We currently do not support connecting several DSI devices to the
> > +* same host. In order to support that we'd need the DRM bridge
> > +* framework to allow dynamic reconfiguration of the bridge chain.
> > +*/
> > +   if (output->dev)
> > +   return -EBUSY;
> > +
> > +   /* We do not support burst mode yet. */
> > +   if (dev->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> > +   return -ENOTSUPP;
> > +
> > +   /*
> > +* The host <-> device link might be described using an OF-graph
> > +* representation, in this case we extract the device of_node from
> > +* this representation, otherwise we use dsidev->dev.of_node which
> > +* should have been filled by the core.
> > +*/
> > +   np = of_graph_get_remote_node(dsi->base.dev->of_node, DSI_OUTPUT_PORT,
> > + dev->channel);
> > +   if (!np)
> > +   np = of_node_get(dev->dev.of_node); > +

Re: [PATCH v2] drm/dp: DPCD register defines for link status within ESI field

2017-09-18 Thread Jani Nikula
On Wed, 13 Sep 2017, Dhinakaran Pandiyan  wrote:
> Link status is available in the ESI field on devices with DPCD r1.2 or
> higher. DP spec also says "An MST upstream device shall use this field
> instead of the Link/Sink Device Status field registers, starting from DPCD
> Address 00200h."
>
> v2: Prefixed DP_ (Jani)
> Rewrote commment to stay within 80 cols.
> Cc: Jani Nikula 
> Reviewed-by: Jani Nikula 
> Signed-off-by: Dhinakaran Pandiyan 

Thanks, pushed to drm-misc-next.

BR,
Jani.

> ---
>  include/drm/drm_dp_helper.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 2c412a15cfa1..11c39f15f1b3 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -738,6 +738,11 @@
>  #define DP_RECEIVER_ALPM_STATUS  0x200b  /* eDP 1.4 */
>  # define DP_ALPM_LOCK_TIMEOUT_ERROR  (1 << 0)
>  
> +#define DP_LANE0_1_STATUS_ESI  0x200c /* status same as 
> 0x202 */
> +#define DP_LANE2_3_STATUS_ESI  0x200d /* status same as 
> 0x203 */
> +#define DP_LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* status same as 
> 0x204 */
> +#define DP_SINK_STATUS_ESI 0x200f /* status same as 
> 0x205 */
> +
>  #define DP_DPRX_FEATURE_ENUMERATION_LIST0x2210  /* DP 1.3 */
>  # define DP_GTC_CAP  (1 << 0)  /* DP 1.3 */
>  # define DP_SST_SPLIT_SDP_CAP(1 << 1)  /* DP 
> 1.4 */

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


[PATCH] qxl: fix framebuffer unpinning

2017-09-18 Thread Gerd Hoffmann
qxl_plane_cleanup_fb() unpins the just activated framebuffer
instead of the old one.  Oops.  Fix it.

Cc: Gabriel Krisman Bertazi 
Fixes: 1277eed5fecb8830c8cc414ad70c1ef640464bc0
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_display.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index e1dd05423e..afbf50d0c0 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -702,14 +702,15 @@ static void qxl_plane_cleanup_fb(struct drm_plane *plane,
struct drm_gem_object *obj;
struct qxl_bo *user_bo;
 
-   if (!plane->state->fb) {
-   /* we never executed prepare_fb, so there's nothing to
+   if (!old_state->fb) {
+   /*
+* we never executed prepare_fb, so there's nothing to
 * unpin.
 */
return;
}
 
-   obj = to_qxl_framebuffer(plane->state->fb)->obj;
+   obj = to_qxl_framebuffer(old_state->fb)->obj;
user_bo = gem_to_qxl_bo(obj);
qxl_bo_unpin(user_bo);
 }
-- 
2.9.3

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