Re: [RFC v4 08/17] kunit: test: add support for test abort

[Brendan Higgins]

On Tue, Feb 19, 2019 at 10:44 PM Frank Rowand  wrote:
>
> On 2/19/19 7:39 PM, Brendan Higgins wrote:
> > On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand  
> > wrote:
> >>
> >> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> >>> Add support for aborting/bailing out of test cases. Needed for
> >>> implementing assertions.
> >>>
> >>> Signed-off-by: Brendan Higgins 
> >>> ---
> >>> Changes Since Last Version
> >>>  - This patch is new introducing a new cross-architecture way to abort
> >>>out of a test case (needed for KUNIT_ASSERT_*, see next patch for
> >>>details).
> >>>  - On a side note, this is not a complete replacement for the UML abort
> >>>mechanism, but covers the majority of necessary functionality. UML
> >>>architecture specific featurs have been dropped from the initial
> >>>patchset.
> >>> ---
> >>>  include/kunit/test.h |  24 +
> >>>  kunit/Makefile   |   3 +-
> >>>  kunit/test-test.c| 127 ++
> >>>  kunit/test.c | 208 +--
> >>>  4 files changed, 353 insertions(+), 9 deletions(-)
> >>>  create mode 100644 kunit/test-test.c
> >>
> >> < snip >
> >>
> >>> diff --git a/kunit/test.c b/kunit/test.c
> >>> index d18c50d5ed671..6e5244642ab07 100644
> >>> --- a/kunit/test.c
> >>> +++ b/kunit/test.c
> >>> @@ -6,9 +6,9 @@
> >>>   * Author: Brendan Higgins 
> >>>   */
> >>>
> >>> -#include 
> >>>  #include 
> >>> -#include 
> >>> +#include 
> >>> +#include 
> >>>  #include 
> >>>
> >>>  static bool kunit_get_success(struct kunit *test)
> >>> @@ -32,6 +32,27 @@ static void kunit_set_success(struct kunit *test, bool 
> >>> success)
> >>>   spin_unlock_irqrestore(>lock, flags);
> >>>  }
> >>>
> >>> +static bool kunit_get_death_test(struct kunit *test)
> >>> +{
> >>> + unsigned long flags;
> >>> + bool death_test;
> >>> +
> >>> + spin_lock_irqsave(>lock, flags);
> >>> + death_test = test->death_test;
> >>> + spin_unlock_irqrestore(>lock, flags);
> >>> +
> >>> + return death_test;
> >>> +}
> >>> +
> >>> +static void kunit_set_death_test(struct kunit *test, bool death_test)
> >>> +{
> >>> + unsigned long flags;
> >>> +
> >>> + spin_lock_irqsave(>lock, flags);
> >>> + test->death_test = death_test;
> >>> + spin_unlock_irqrestore(>lock, flags);
> >>> +}
> >>> +
> >>>  static int kunit_vprintk_emit(const struct kunit *test,
> >>> int level,
> >>> const char *fmt,
> >>> @@ -70,13 +91,29 @@ static void kunit_fail(struct kunit *test, struct 
> >>> kunit_stream *stream)
> >>>   stream->commit(stream);
> >>>  }
> >>>
> >>> +static void __noreturn kunit_abort(struct kunit *test)
> >>> +{
> >>> + kunit_set_death_test(test, true);
> >>> +
> >>> + test->try_catch.throw(>try_catch);
> >>> +
> >>> + /*
> >>> +  * Throw could not abort from test.
> >>> +  */
> >>> + kunit_err(test, "Throw could not abort from test!");
> >>> + show_stack(NULL, NULL);
> >>> + BUG();
> >>
> >> kunit_abort() is what will be call as the result of an assert failure.
> >
> > Yep. Does that need clarified somewhere.
> >>
> >> BUG(), which is a panic, which is crashing the system is not acceptable
> >> in the Linux kernel.  You will just annoy Linus if you submit this.
> >
> > Sorry, I thought this was an acceptable use case since, a) this should
> > never be compiled in a production kernel, b) we are in a pretty bad,
> > unpredictable state if we get here and keep going. I think you might
> > have said elsewhere that you think "a" is not valid? In any case, I
> > can replace this with a WARN, would that be acceptable?
>
> A WARN may or may not make sense, depending on the context.  It may
> be sufficient to simply report a test failure (as in the old version
> of case (2) below.
>
> Answers to "a)" and "b)":
>
> a) it might be in a production kernel

Sorry for a possibly stupid question, how might it be so? Why would
someone intentionally build unit tests into a production kernel?

>
> a') it is not acceptable in my development kernel either

Fair enough.

>
> b) No.  You don't crash a developer's kernel either unless it is
> required to avoid data corruption.

Alright, I thought that was one of those cases, but I am not going to
push the point. Also, in case it wasn't clear, the path where BUG()
gets called only happens if there is a bug in KUnit itself, not just
because a test case fails catastrophically.

>
> b') And you can not do replacements like:
>
> (1) in of_unittest_check_tree_linkage()
>
> -  old  -
>
> if (!of_root)
> return;
>
> -  new  -
>
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, of_root);
>
> (2) in of_unittest_property_string()
>
> -  old  -
>
> /* of_property_read_string_index() tests */
> rc = of_property_read_string_index(np, "string-property", 0, strings);
> unittest(rc == 0 && !strcmp(strings[0], "foobar"), 
> 

[Bug 109794] LLVM not properly shutdown in `si_pipe.c`?

[bugzilla-daemon]

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

--- Comment #1 from Hal Gentz  ---
s/an investigation//
s/in an `eglInitialize` call/when we call `eglInitialize`/
s/happens once./initializes stuff once./
s/we all/we call/

-- 
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 109794] LLVM not properly shutdown in `si_pipe.c`?

[bugzilla-daemon]

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

Bug ID: 109794
   Summary: LLVM not properly shutdown in `si_pipe.c`?
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: zegen...@protonmail.com
QA Contact: dri-devel@lists.freedesktop.org

tl;dr; Shouldn't we be calling `LLVMShutdown()` somewhere?

I had a program which was calling: 
```
eglInitialize(disp, , ); 
eglTerminate(disp); 
eglInitialize(disp, , );
```

Which lead to mesa outputting the following before continuing on normally
during the second call to `eglInitalize`:

```
mesa: for the -simplifycfg-sink-common option: may only occur zero or one
times!
mesa: for the -global-isel-abort option: may only occur zero or one times!
```

This prompted an investigation me to investigate, and with the aid of @imirkin,
I think I got the cause.

You see, in an `eglInitialize` call `radeonsi_dri.so` gets loaded, which also
loads in `libLLVM-9svn.so`, and eventually `ac_init_llvm_once()` gets called
more than once.

That's OK, for as the name implies, it only happens once.

Issue is, when `eglTerminate` is called, `radeonsi_dri.so` gets unloaded, but
not `libLLVM-9svn.so`. This means that the next time we all `eglInitialize`,
LLVM's `ManagedStatic`s will be preserved, but not our static var
`ac_init_llvm_target_once_flag`.

We can fix this by calling `LLVMShutdown` before unloading `radeonsi_dri.so`,
that way LLVM's `ManagedStatic`s are also reset.

Alas, I'm not familiar enough with the mesa codebase, so I got no clue where
the appropriate place to plop this function is. Any aid would be well
appreciated.

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

[PATCH] drm/msm: don't allocate pages from the MOVABLE zone

[Lucas Stach]

The pages backing the GEM objects are kept pinned in place as
long as they are alive, so they must not be allocated from the
MOVABLE zone. Blocking page migration for too long will cause
the VM subsystem headaches and will outright break CMA, as a
few pinned pages in CMA will lead to failure to find the
required large contiguous regions.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/msm/msm_gem.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 51a95da694d8..dc4860ae3171 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -1022,6 +1022,13 @@ static struct drm_gem_object *_msm_gem_new(struct 
drm_device *dev,
ret = drm_gem_object_init(dev, obj, size);
if (ret)
goto fail;
+   /*
+* Our buffers are kept pinned, so allocating them from the
+* MOVABLE zone is a really bad idea, and conflicts with CMA.
+* See comments above new_inode() why this is required _and_
+* expected if you're going to pin these pages.
+*/
+   mapping_set_gfp_mask(obj->filp->f_mapping, GFP_HIGHUSER);
}
 
return obj;
-- 
2.20.1

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

[GIT PULL] etnaviv-next for 5.1

[Lucas Stach]

Hi Daniel, hi Dave,

sorry for being really late. We don't have something major to destage,
as per-process address spaces and softpin are still baking. So this
time around it's only small fixes and a change to not restrict etnaviv
to certain architectures. This has seen some coverage from the kbuild
bot and has also been in linux-next for a few weeks already.

Regards,
Lucas

The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:

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

are available in the Git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/next

for you to fetch changes up to 9e05352340d3a3e68c144136db9810b26ebb88c3:

  drm/etnaviv: potential NULL dereference (2019-02-11 11:50:43 +0100)


Dan Carpenter (3):
  drm/etnaviv: fix some off by one bugs
  drm/etnaviv: NULL vs IS_ERR() buf in etnaviv_core_dump()
  drm/etnaviv: potential NULL dereference

Lucas Stach (3):
  drm/etnaviv: move job context pointer to etnaviv_gem_submit
  drm/etnaviv: don't restrict to certain architectures
  drm/etnaviv: mmuv2: don't map zero page

Matthew Wilcox (2):
  etnaviv mailing list is moderated
  Build etnaviv on non-ARM architectures

 MAINTAINERS  | 2 +-
 drivers/gpu/drm/etnaviv/Kconfig  | 1 -
 drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 2 --
 drivers/gpu/drm/etnaviv/etnaviv_dump.c   | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h| 1 +
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c  | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c   | 4 ++--
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c| 6 +++---
 drivers/gpu/drm/etnaviv/etnaviv_sched.c  | 2 +-
 10 files changed, 11 insertions(+), 13 deletions(-)

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

[radeon-alex:amd-staging-drm-next 451/607] drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:60:31: sparse: warning: cast to restricted __le32

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   9bf083e6426b8df943f0da4a7ef8d8f407a26e9f
commit: 58560ce0c438137ef4dca63fabf58a16dbf35c19 [451/607] drm/amd/powerplay: 
init microcode for smu11
reproduce:
# apt-get install sparse
git checkout 58560ce0c438137ef4dca63fabf58a16dbf35c19
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:60:31: sparse: warning: 
>> cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:68:25: sparse: warning: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:68:25: sparse: warning: 
cast to restricted __le32
   drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:68:25: sparse: warning: 
cast to restricted __le32

vim +60 drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c

30  
31  static int smu_v11_0_init_microcode(struct smu_context *smu)
32  {
33  struct amdgpu_device *adev = smu->adev;
34  const char *chip_name;
35  char fw_name[30];
36  int err = 0;
37  const struct smc_firmware_header_v1_0 *hdr;
38  const struct common_firmware_header *header;
39  struct amdgpu_firmware_info *ucode = NULL;
40  
41  switch (adev->asic_type) {
42  case CHIP_VEGA20:
43  chip_name = "vega20";
44  break;
45  default:
46  BUG();
47  }
48  
49  snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_smc.bin", 
chip_name);
50  
51  err = request_firmware(>pm.fw, fw_name, adev->dev);
52  if (err)
53  goto out;
54  err = amdgpu_ucode_validate(adev->pm.fw);
55  if (err)
56  goto out;
57  
58  hdr = (const struct smc_firmware_header_v1_0 *) 
adev->pm.fw->data;
59  amdgpu_ucode_print_smc_hdr(>header);
  > 60  adev->pm.fw_version = le32_to_cpu(hdr->header.ucode_version);
61  
62  if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) {
63  ucode = >firmware.ucode[AMDGPU_UCODE_ID_SMC];
64  ucode->ucode_id = AMDGPU_UCODE_ID_SMC;
65  ucode->fw = adev->pm.fw;
66  header = (const struct common_firmware_header 
*)ucode->fw->data;
67  adev->firmware.fw_size +=
68  ALIGN(le32_to_cpu(header->ucode_size_bytes), 
PAGE_SIZE);
69  }
70  
71  out:
72  if (err) {
73  DRM_ERROR("smu_v11_0: Failed to load firmware \"%s\"\n",
74fw_name);
75  release_firmware(adev->pm.fw);
76  adev->pm.fw = NULL;
77  }
78  return err;
79  }
80  

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

[PATCH libdrm 1/2] tests/amdgpu: add memset dispatch test

[Cui, Flora]

add memset dispatch test for gfx9

Change-Id: If607fbd9c6e49ca830a662adc24fe6b1e2a25bfb
Signed-off-by: Flora Cui 
Tested-by: Rui Teng 
---
 tests/amdgpu/basic_tests.c | 215 -
 1 file changed, 213 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index dbae4d5..d4b0faf 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -49,6 +49,7 @@ static void amdgpu_userptr_test(void);
 static void amdgpu_semaphore_test(void);
 static void amdgpu_sync_dependency_test(void);
 static void amdgpu_bo_eviction_test(void);
+static void amdgpu_dispatch_test(void);
 
 static void amdgpu_command_submission_write_linear_helper(unsigned ip_type);
 static void amdgpu_command_submission_const_fill_helper(unsigned ip_type);
@@ -70,6 +71,7 @@ CU_TestInfo basic_tests[] = {
{ "Command submission Test (SDMA)", amdgpu_command_submission_sdma },
{ "SW semaphore Test",  amdgpu_semaphore_test },
{ "Sync dependency Test",  amdgpu_sync_dependency_test },
+   { "Dispatch Test",  amdgpu_dispatch_test },
CU_TEST_INFO_NULL,
 };
 #define BUFFER_SIZE (8 * 1024)
@@ -117,6 +119,7 @@ CU_TestInfo basic_tests[] = {
 #define PACKET3(op, n) ((PACKET_TYPE3 << 30) | \
 (((op) & 0xFF) << 8) | \
 ((n) & 0x3FFF) << 16)
+#define PACKET3_COMPUTE(op, n) PACKET3(op, n) | (1 << 1)
 
 /* Packet 3 types */
 #definePACKET3_NOP 0x10
@@ -245,8 +248,8 @@ CU_TestInfo basic_tests[] = {
 #definePACKET3_SET_SH_REG_START
0x2c00
 
 #definePACKET3_DISPATCH_DIRECT 0x15
-
-
+#define PACKET3_EVENT_WRITE0x46
+#define PACKET3_ACQUIRE_MEM0x58
 /* gfx 8 */
 #define mmCOMPUTE_PGM_LO   
 0x2e0c
 #define mmCOMPUTE_PGM_RSRC1
 0x2e12
@@ -286,6 +289,21 @@ static  uint32_t shader_bin[] = {
 #define CODE_OFFSET 512
 #define DATA_OFFSET 1024
 
+static const uint32_t bufferclear_cs_shader_gfx9[] = {
+0xD1FD, 0x04010C08, 0x7E020204, 0x7E040205,
+0x7E060206, 0x7E080207, 0xE01C2000, 0x8100,
+0xBF81
+};
+
+static const uint32_t bufferclear_cs_shader_registers_gfx9[][2] = {
+   {0x2E12, 0x000C0041},   //{ mmCOMPUTE_PGM_RSRC1,  0x000C0041 },
+   {0x2E13, 0x0090},   //{ mmCOMPUTE_PGM_RSRC2,  0x0090 },
+   {0x2E07, 0x0040},   //{ mmCOMPUTE_NUM_THREAD_X, 0x0040 },
+   {0x2E08, 0x0001},   //{ mmCOMPUTE_NUM_THREAD_Y, 0x0001 },
+   {0x2E09, 0x0001},   //{ mmCOMPUTE_NUM_THREAD_Z, 0x0001 }
+};
+
+static const uint32_t bufferclear_cs_shader_registers_num_gfx9 = 5;
 
 int amdgpu_bo_alloc_and_map_raw(amdgpu_device_handle dev, unsigned size,
unsigned alignment, unsigned heap, uint64_t alloc_flags,
@@ -1883,3 +1901,196 @@ static void amdgpu_sync_dependency_test(void)
 
free(ibs_request.dependencies);
 }
+
+static int amdgpu_dispatch_init(uint32_t ip_type,
+   uint32_t version,
+   uint32_t *ptr)
+{
+   int i = 0;
+
+   /* Write context control and load shadowing register if necessary */
+   if (ip_type == AMDGPU_HW_IP_GFX) {
+   ptr[i++] = PACKET3(PKT3_CONTEXT_CONTROL, 1);
+   ptr[i++] = 0x8000;
+   ptr[i++] = 0x8000;
+   }
+
+   /* Issue commands to set default compute state. */
+   /* clear mmCOMPUTE_START_Z - mmCOMPUTE_START_X */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 3);
+   ptr[i++] = 0x204;
+   i += 3;
+   /* clear mmCOMPUTE_RESOURCE_LIMITS */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 1);
+   ptr[i++] = 0x215;
+   ptr[i++] = 0;
+   /* clear mmCOMPUTE_TMPRING_SIZE */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 1);
+   ptr[i++] = 0x218;
+   ptr[i++] = 0;
+
+   return i;
+}
+
+static int amdgpu_dispatch_write_cumask(uint32_t ip_type,
+   uint32_t version,
+   uint32_t *ptr)
+{
+   int i = 0;
+
+   /*  Issue commands to set cu mask used in current dispatch */
+   /* set mmCOMPUTE_STATIC_THREAD_MGMT_SE1 - 
mmCOMPUTE_STATIC_THREAD_MGMT_SE0 */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 2);
+   ptr[i++] = 0x216;
+   ptr[i++] = 0x;
+   ptr[i++] = 0x;
+   /* set mmCOMPUTE_STATIC_THREAD_MGMT_SE3 - 
mmCOMPUTE_STATIC_THREAD_MGMT_SE2 */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 2);
+   ptr[i++] = 0x219;
+   ptr[i++] = 0x;
+   ptr[i++] = 0x;
+
+   return i;
+}
+
+static int amdgpu_dispatch_write2hw(uint32_t 

[PATCH libdrm 2/2] tests/amdgpu: add memcpy dispatch test

[Cui, Flora]

add memcpy dispatch test for gfx9

Change-Id: If433434c5378f3b318209d4e28c19d7ce9cff1a2
Signed-off-by: Flora Cui 
Tested-by: Rui Teng 
---
 tests/amdgpu/basic_tests.c | 129 +
 1 file changed, 129 insertions(+)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index d4b0faf..9d2cc95 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -305,6 +305,11 @@ static const uint32_t 
bufferclear_cs_shader_registers_gfx9[][2] = {
 
 static const uint32_t bufferclear_cs_shader_registers_num_gfx9 = 5;
 
+static const uint32_t buffercopy_cs_shader_gfx9[] = {
+0xD1FD, 0x04010C08, 0xE00C2000, 0x8100,
+0xBF8C0F70, 0xE01C2000, 0x80010100, 0xBF81
+};
+
 int amdgpu_bo_alloc_and_map_raw(amdgpu_device_handle dev, unsigned size,
unsigned alignment, unsigned heap, uint64_t alloc_flags,
uint64_t mapping_flags, amdgpu_bo_handle *bo, void 
**cpu,
@@ -2084,6 +2089,128 @@ static void amdgpu_memset_dispatch_test(uint32_t 
ip_type)
 
r = amdgpu_bo_unmap_and_free(bo_shader, va_shader, mc_address_shader, 
bo_shader_size);
CU_ASSERT_EQUAL(r, 0);
+
+   r = amdgpu_cs_ctx_free(context_handle);
+   CU_ASSERT_EQUAL(r, 0);
+}
+
+static void amdgpu_memcpy_dispatch_test(uint32_t ip_type)
+{
+   amdgpu_context_handle context_handle;
+   amdgpu_bo_handle bo_src, bo_dst, bo_shader, resources[3];
+   volatile unsigned char *ptr_dst;
+   void *ptr_shader;
+   void *ptr_src;
+   uint64_t mc_address_src, mc_address_dst, mc_address_shader;
+   amdgpu_va_handle va_src, va_dst, va_shader;
+   int i, j, r;
+   uint32_t *ptr;
+   int bo_dst_size = 16384;
+   int bo_shader_size = 4096;
+   struct amdgpu_cs_request ibs_request = {0};
+   struct amdgpu_cs_ib_info ib_info= {0};
+   uint32_t version, ring_id;
+   struct drm_amdgpu_info_hw_ip info;
+
+   r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, );
+   CU_ASSERT_EQUAL(r, 0);
+
+   version = info.hw_ip_version_major;
+   if (version != 9) {
+   printf("\tSkip...memcpy dispatch test is only supported with 
gfx9\n");
+   return;
+   }
+
+   ptr = calloc(256, sizeof(*ptr));
+   CU_ASSERT_NOT_EQUAL(ptr, NULL);
+
+   r = amdgpu_cs_ctx_create(device_handle, _handle);
+   CU_ASSERT_EQUAL(r, 0);
+
+   r = amdgpu_bo_alloc_and_map(device_handle, bo_shader_size, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM, 0,
+   _shader, _shader,
+   _address_shader, _shader);
+   CU_ASSERT_EQUAL(r, 0);
+
+   memcpy(ptr_shader, buffercopy_cs_shader_gfx9, 
sizeof(buffercopy_cs_shader_gfx9));
+
+   for (ring_id = 0; (1 << ring_id) & info.available_rings; ring_id++) {
+   r = amdgpu_bo_alloc_and_map(device_handle, bo_dst_size, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM, 0,
+   _src, _src,
+   _address_src, _src);
+   CU_ASSERT_EQUAL(r, 0);
+
+   r = amdgpu_bo_alloc_and_map(device_handle, bo_dst_size, 4096,
+   AMDGPU_GEM_DOMAIN_VRAM, 0,
+   _dst, _dst,
+   _address_dst, _dst);
+   CU_ASSERT_EQUAL(r, 0);
+
+   memset(ptr_src, 0x55, bo_dst_size);
+
+   i = 0;
+   i += amdgpu_dispatch_init(ip_type, version, ptr + i);
+
+   /*  Issue commands to set cu mask used in current dispatch */
+   i += amdgpu_dispatch_write_cumask(ip_type, version, ptr + i);
+
+   /* Writes shader state to HW */
+   i += amdgpu_dispatch_write2hw(ip_type, version, ptr + i, 
mc_address_shader);
+
+   /* Write constant data */
+   /* Writes the texture resource constants data to the SGPRs */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 4);
+   ptr[i++] = 0x240;
+   ptr[i++] = mc_address_src;
+   ptr[i++] = (mc_address_src > 32) | 0x10;
+   ptr[i++] = 0x400;
+   ptr[i++] = 0x74fac;
+   /* Writes the UAV constant data to the SGPRs. */
+   ptr[i++] = PACKET3_COMPUTE(PKT3_SET_SH_REG, 4);
+   ptr[i++] = 0x244;
+   ptr[i++] = mc_address_dst;
+   ptr[i++] = (mc_address_dst > 32) | 0x10;
+   ptr[i++] = 0x400;
+   ptr[i++] = 0x74fac;
+
+   /* dispatch direct command */
+   ptr[i++] = PACKET3_COMPUTE(PACKET3_DISPATCH_DIRECT, 3);
+   ptr[i++] = 0x10;
+   ptr[i++] = 1;
+   ptr[i++] = 1;
+   ptr[i++] = 1;
+
+   while (i & 7)

[radeon-alex:amd-staging-drm-next 473/607] drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:453:12: warning: cast from pointer to integer of different size

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   9bf083e6426b8df943f0da4a7ef8d8f407a26e9f
commit: bf05726f078c37252b2052a74086e3b0eaf634de [473/607] drm/amd/powerplay: 
implement notify_memory_pool_location function for smu11
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout bf05726f078c37252b2052a74086e3b0eaf634de
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=mips 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c: In function 
'smu_v11_0_notify_memory_pool_location':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:453:12: warning: cast 
>> from pointer to integer of different size [-Wpointer-to-int-cast]
 address = (uint64_t)memory_pool->cpu_addr;
   ^

vim +453 drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c

   441  
   442  static int smu_v11_0_notify_memory_pool_location(struct smu_context 
*smu)
   443  {
   444  struct smu_table_context *smu_table = >smu_table;
   445  struct smu_table *memory_pool = _table->memory_pool;
   446  int ret = 0;
   447  uint64_t address;
   448  uint32_t address_low, address_high;
   449  
   450  if (memory_pool->size == 0 || memory_pool->cpu_addr == NULL)
   451  return ret;
   452  
 > 453  address = (uint64_t)memory_pool->cpu_addr;
   454  address_high = (uint32_t)upper_32_bits(address);
   455  address_low  = (uint32_t)lower_32_bits(address);
   456  
   457  ret = smu_send_smc_msg_with_param(smu,
   458
PPSMC_MSG_SetSystemVirtualDramAddrHigh,
   459address_high);
   460  if (ret)
   461  return ret;
   462  ret = smu_send_smc_msg_with_param(smu,
   463
PPSMC_MSG_SetSystemVirtualDramAddrLow,
   464address_low);
   465  if (ret)
   466  return ret;
   467  
   468  address = memory_pool->mc_address;
   469  address_high = (uint32_t)upper_32_bits(address);
   470  address_low  = (uint32_t)lower_32_bits(address);
   471  
   472  ret = smu_send_smc_msg_with_param(smu, 
PPSMC_MSG_DramLogSetDramAddrHigh,
   473address_high);
   474  if (ret)
   475  return ret;
   476  ret = smu_send_smc_msg_with_param(smu, 
PPSMC_MSG_DramLogSetDramAddrLow,
   477address_low);
   478  if (ret)
   479  return ret;
   480  ret = smu_send_smc_msg_with_param(smu, 
PPSMC_MSG_DramLogSetDramSize,
   481(uint32_t)memory_pool->size);
   482  if (ret)
   483  return ret;
   484  
   485  return ret;
   486  }
   487  

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


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

[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering

[bugzilla-daemon]

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

--- Comment #19 from Clément Guérin (li...@protonmail.com) ---
I just built drm-fixes-5.0 including
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.0=d63716658ac16c515d1223a9fbf5edbf76b1b333
and this issue remains.

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

big conflict in drm-tip (amdgpu)

[Dave Airlie]

I merged some fixes into drm-fixes, pushed it out, then saw tip
breaking, but I'm needed elsewhere, so if anyone can fix tip up or
tell me why I got a super messy commit, I'll owe you.

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

Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

[Brendan Higgins]

On Fri, Feb 22, 2019 at 12:53 PM Thiago Jung Bauermann
 wrote:
>
>
> Frank Rowand  writes:
>
> > On 2/19/19 10:34 PM, Brendan Higgins wrote:
> >> On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand  
> >> wrote:
> >> 
> >>> I have not read through the patches in any detail.  I have read some of
> >>> the code to try to understand the patches to the devicetree unit tests.
> >>> So that may limit how valid my comments below are.
> >>
> >> No problem.
> >>
> >>>
> >>> I found the code difficult to read in places where it should have been
> >>> much simpler to read.  Structuring the code in a pseudo object oriented
> >>> style meant that everywhere in a code path that I encountered a dynamic
> >>> function call, I had to go find where that dynamic function call was
> >>> initialized (and being the cautious person that I am, verify that
> >>> no where else was the value of that dynamic function call).  With
> >>> primitive vi and tags, that search would have instead just been a
> >>> simple key press (or at worst a few keys) if hard coded function
> >>> calls were done instead of dynamic function calls.  In the code paths
> >>> that I looked at, I did not see any case of a dynamic function being
> >>> anything other than the value it was originally initialized as.
> >>> There may be such cases, I did not read the entire patch set.  There
> >>> may also be cases envisioned in the architects mind of how this
> >>> flexibility may be of future value.  Dunno.
> >>
> >> Yeah, a lot of it is intended to make architecture specific
> >> implementations and some other future work easier. Some of it is also
> >> for testing purposes. Admittedly some is for neither reason, but given
> >> the heavy usage elsewhere, I figured there was no harm since it was
> >> all private internal usage anyway.
> >>
> >
> > Increasing the cost for me (and all the other potential code readers)
> > to read the code is harm.
>
> Dynamic function calls aren't necessary for arch-specific
> implementations either. See for example arch_kexec_image_load() in
> kernel/kexec_file.c, which uses a weak symbol that is overriden by
> arch-specific code. Not everybody likes weak symbols, so another
> alternative (which admitedly not everybody likes either) is to use a
> macro with the name of the arch-specific function, as used by
> arch_kexec_post_alloc_pages() in  for instance.

I personally have a strong preference for dynamic function calls over
weak symbols or macros, but I can change it if it really makes
anyone's eyes bleed.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

[Brendan Higgins]

On Tue, Feb 19, 2019 at 10:46 PM Frank Rowand  wrote:
>
> On 2/19/19 10:34 PM, Brendan Higgins wrote:
> > On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand  
> > wrote:
> > 
> >> I have not read through the patches in any detail.  I have read some of
> >> the code to try to understand the patches to the devicetree unit tests.
> >> So that may limit how valid my comments below are.
> >
> > No problem.
> >
> >>
> >> I found the code difficult to read in places where it should have been
> >> much simpler to read.  Structuring the code in a pseudo object oriented
> >> style meant that everywhere in a code path that I encountered a dynamic
> >> function call, I had to go find where that dynamic function call was
> >> initialized (and being the cautious person that I am, verify that
> >> no where else was the value of that dynamic function call).  With
> >> primitive vi and tags, that search would have instead just been a
> >> simple key press (or at worst a few keys) if hard coded function
> >> calls were done instead of dynamic function calls.  In the code paths
> >> that I looked at, I did not see any case of a dynamic function being
> >> anything other than the value it was originally initialized as.
> >> There may be such cases, I did not read the entire patch set.  There
> >> may also be cases envisioned in the architects mind of how this
> >> flexibility may be of future value.  Dunno.
> >
> > Yeah, a lot of it is intended to make architecture specific
> > implementations and some other future work easier. Some of it is also
> > for testing purposes. Admittedly some is for neither reason, but given
> > the heavy usage elsewhere, I figured there was no harm since it was
> > all private internal usage anyway.
> >
>
> Increasing the cost for me (and all the other potential code readers)
> to read the code is harm.

You are right. I like the object oriented C style; I didn't think it
hurt readability.

In any case, I will go through and replace instances where I am not
using it for one of the above reasons.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v3 18/19] of: unittest: split out a couple of test cases from unittest

[Brendan Higgins]

On Wed, Feb 20, 2019 at 12:45 PM Frank Rowand  wrote:
>
> On 2/18/19 2:25 PM, Frank Rowand wrote:
> > On 2/15/19 2:56 AM, Brendan Higgins wrote:
> >> On Thu, Feb 14, 2019 at 6:05 PM Frank Rowand  
> >> wrote:
> >>>
> >>> On 2/14/19 4:56 PM, Brendan Higgins wrote:
>  On Thu, Feb 14, 2019 at 3:57 PM Frank Rowand  
>  wrote:
> >
> > On 12/5/18 3:54 PM, Brendan Higgins wrote:
> >> On Tue, Dec 4, 2018 at 2:58 AM Frank Rowand  
> >> wrote:
> >>>
>
> < snip >
>
> >
> > It makes it harder for me to read the source of the tests and
> > understand the order they will execute.  It also makes it harder
> > for me to read through the actual tests (in this example the
> > tests that are currently grouped in of_unittest_find_node_by_name())
> > because of all the extra function headers injected into the
> > existing single function to break it apart into many smaller
> > functions.
>
> < snip >
>
>  This is not something I feel particularly strongly about, it is just
>  pretty atypical from my experience to have so many unrelated test
>  cases in a single file.
> 
>  Maybe you would prefer that I break up the test cases first, and then
>  we split up the file as appropriate?
> >>>
> >>> I prefer that the test cases not be broken up arbitrarily.  There _may_
>
> I expect that I created confusion by putting this in a reply to patch 18/19.
> It is actually a comment about patch 19/19.  Sorry about that.
>

No worries.

>
> >>
> >> I wasn't trying to break them up arbitrarily. I thought I was doing it
> >> according to a pattern (breaking up the file, that is), but maybe I
> >> just hadn't looked at enough examples.
> >
> > This goes back to the kunit model of putting each test into a separate
> > function that can be a KUNIT_CASE().  That is a model that I do not agree
> > with for devicetree.
>
> So now that I am actually talking about patch 19/19, let me give a concrete
> example.  I will cut and paste (after my comments), the beginning portion
> of base-test.c, after applying patch 19/19 (the "base version".  Then I
> will cut and paste my alternative version which does not break the tests
> down into individual functions (the "frank version").

Awesome, thanks for putting the comparison together!

>
> I will also reply to this email with the base version and the frank version
> as attachments, which will make it easier to save as separate versions
> for easier viewing.  I'm not sure if an email with attachments will make
> it through the list servers, but I am cautiously optimistic.
>
> I am using v4 of the patch series because I never got v3 to cleanly apply
> and it is not a constructive use of my time to do so since I have v4 applied.
>
> One of the points I was trying to make is that readability suffers from the
> approach taken by patches 18/19 and 19/19.

I understood that point.

>
> The base version contains the extra text of a function header for each
> unit test.  This is visual noise and makes the file larger.  It is also
> one more possible location of an error (although not likely).

I don't see how it is much more visual noise than a comment.
Admittedly, a space versus an underscore might be nice, but I think it
is also more likely that a function name is more likely to be kept up
to date than a comment even if they are both informational. It also
forces the user to actually name all the tests. Even then, I am not
married to doing it this exact way. The thing I really care about is
isolating the code in each test case so that it can be executed
separately.

A side thought, when I was proofreading this, it occurred to me that
you might not like the function name over comment partly because you
think about them differently. You aren't used to seeing a function
used to frame things or communicate information in this way. Is this
true? Admittedly, I have gotten used to a lot of unit test frameworks
that break up test cases by function, so I wondering if part of the
difference in comfortability with this framing might come from the
fact that I am really used to seeing it this way and you are not? If
this is the case, maybe it would be better if we had something like:

KUNIT_DECLARE_CASE(case_id, "Test case description")
{
KUNIT_EXPECT_EQ(kunit, ...);
...
}

Just a thought.

>
> The frank version has converted each of the new function headers into
> a comment, using the function name with '_' converted to ' '.  The
> comments are more readable than the function headers.  Note that I added
> an extra blank line before each comment, which violates the kernel
> coding standards, but I feel this makes the code more readable.

I agree that the extra space is an improvement, but I think any
sufficient visual separation would work.

>
> The base version needs to declare each of the individual test functions
> in of_test_find_node_by_name_cases[]. It is possible that a test function
> could be left out of of_test_find_node_by_name_cases[], in error.  

[Bug 109783] YUV422 support not advertised for VAProfileJPEGBaseline decoding

[bugzilla-daemon]

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

Andres  changed:

   What|Removed |Added

Version|unspecified |18.2

-- 
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 109793] I420/IYUV is not advertised in vaQueryImageFormats()

[bugzilla-daemon]

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

Bug ID: 109793
   Summary: I420/IYUV is not advertised in vaQueryImageFormats()
   Product: Mesa
   Version: 18.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: andre...@chromium.org
QA Contact: dri-devel@lists.freedesktop.org

According to https://gitlab.freedesktop.org/mesa/mesa/commit/b0a44f10,
vaGetImage() can convert from an internal format of NV12 to a IYUV image.
However, vaQueryImageFormats() does not report I420 or IYUV as a supported
image format, and it seems it should (I tried this on a AMD STONEY device).

-- 
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 -next] drm/amdgpu: remove set but not used variable 'vbi_time_out'

[Alex Deucher]

Applied.  thanks!

On Tue, Feb 26, 2019 at 12:36 AM YueHaibing  wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/si_dpm.c: In function 'si_program_response_times':
> drivers/gpu/drm/amd/amdgpu/si_dpm.c:4101:29: warning:
>  variable 'backbias_response_time' set but not used 
> [-Wunused-but-set-variable]
>
> It's never used since introduction in 841686df9f7d ("drm/amdgpu: add SI DPM
> support (v4)"), so can be removed
>
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/amd/amdgpu/si_dpm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c 
> b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> index 41e01a7f57a4..d57e75e5c71f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> @@ -4098,14 +4098,13 @@ static int si_notify_smc_display_change(struct 
> amdgpu_device *adev,
>
>  static void si_program_response_times(struct amdgpu_device *adev)
>  {
> -   u32 voltage_response_time, backbias_response_time, acpi_delay_time, 
> vbi_time_out;
> +   u32 voltage_response_time, acpi_delay_time, vbi_time_out;
> u32 vddc_dly, acpi_dly, vbi_dly;
> u32 reference_clock;
>
> si_write_smc_soft_register(adev, SI_SMC_SOFT_REGISTER_mvdd_chg_time, 
> 1);
>
> voltage_response_time = (u32)adev->pm.dpm.voltage_response_time;
> -   backbias_response_time = (u32)adev->pm.dpm.backbias_response_time;
>
> if (voltage_response_time == 0)
> voltage_response_time = 1000;
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] drm/amdgpu: remove set but not used variables 'vm, bo'

[Alex Deucher]

Applied.  thanks!

On Wed, Feb 20, 2019 at 3:05 AM YueHaibing  wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function 
> 'update_gpuvm_pte':
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:840:20: warning:
>  variable 'bo' set but not used [-Wunused-but-set-variable]
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:838:20: warning:
>  variable 'vm' set but not used [-Wunused-but-set-variable]
>
> They're never used since introduction in a46a2cd103a8 ("drm/amdgpu: Add GPUVM
> memory management functions for KFD")
>
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index d7b10d79f1de..63daf758cd03 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -837,13 +837,7 @@ static int update_gpuvm_pte(struct amdgpu_device *adev,
> struct amdgpu_sync *sync)
>  {
> int ret;
> -   struct amdgpu_vm *vm;
> -   struct amdgpu_bo_va *bo_va;
> -   struct amdgpu_bo *bo;
> -
> -   bo_va = entry->bo_va;
> -   vm = bo_va->base.vm;
> -   bo = bo_va->base.bo;
> +   struct amdgpu_bo_va *bo_va = entry->bo_va;
>
> /* Update the page tables  */
> ret = amdgpu_vm_bo_update(adev, bo_va, false);
>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH -next] drm/ttm: remove set but not used variable 'bdev'

[Alex Deucher]

Applied.  Thanks!

On Tue, Feb 19, 2019 at 3:22 AM YueHaibing  wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/ttm/ttm_execbuf_util.c: In function 
> 'ttm_eu_fence_buffer_objects':
> drivers/gpu/drm/ttm/ttm_execbuf_util.c:191:24: warning:
>  variable 'bdev' set but not used [-Wunused-but-set-variable]
>
> It's not used any more and can be removed.
>
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/ttm/ttm_execbuf_util.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> index 93860346c426..0075eb9a0b52 100644
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -188,13 +188,11 @@ void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx 
> *ticket,
> struct ttm_validate_buffer *entry;
> struct ttm_buffer_object *bo;
> struct ttm_bo_global *glob;
> -   struct ttm_bo_device *bdev;
>
> if (list_empty(list))
> return;
>
> bo = list_first_entry(list, struct ttm_validate_buffer, head)->bo;
> -   bdev = bo->bdev;
> glob = bo->bdev->glob;
>
> spin_lock(>lru_lock);
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/display: Pass app_tf by value rather than by reference

[Alex Deucher]

Applied.  Sorry for the delay.

Alex

On Fri, Feb 22, 2019 at 10:36 AM Nathan Chancellor
 wrote:
>
> On Mon, Dec 10, 2018 at 04:42:01PM -0700, Nathan Chancellor wrote:
> > Clang warns when an expression that equals zero is used as a null
> > pointer constant (in lieu of NULL):
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4435:3:
> > warning: expression which evaluates to zero treated as a null pointer
> > constant of type 'const enum color_transfer_func *'
> > [-Wnon-literal-null-conversion]
> > TRANSFER_FUNC_UNKNOWN,
> > ^
> > 1 warning generated.
> >
> > This warning is caused by commit bb47de736661 ("drm/amdgpu: Set FreeSync
> > state using drm VRR properties") and it could be solved by using NULL
> > instead of TRANSFER_FUNC_UNKNOWN or casting TRANSFER_FUNC_UNKNOWN as a
> > pointer. However, after looking into it, there doesn't appear to be a
> > good reason to pass app_tf by reference as it is never mutated along the
> > way. This is the only code path in which app_tf is used:
> >
> > mod_freesync_build_vrr_infopacket ->
> > build_vrr_infopacket_v2 ->
> > build_vrr_infopacket_fs2_data
> >
> > Neither mod_freesync_build_vrr_infopacket or build_vrr_infopacket_v2
> > modify app_tf's value and build_vrr_infopacket_fs2_data expects just
> > the value so we can avoid dereferencing anything by just passing in
> > app_tf's value to mod_freesync_build_vrr_infopacket and
> > build_vrr_infopacket_v2.
> >
> > There is no functional change because build_vrr_infopacket_fs2_data
> > doesn't do anything if TRANSFER_FUNC_UNKNOWN is passed to it, the same
> > as not calling build_vrr_infopacket_fs2_data at all like before this
> > change when NULL was used for app_tf.
> >
> > Signed-off-by: Nathan Chancellor 
> > ---
> >  drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 7 +++
> >  drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h  | 2 +-
> >  2 files changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c 
> > b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> > index 620a171620ee..520665a9d81a 100644
> > --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> > +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> > @@ -656,7 +656,7 @@ static void build_vrr_infopacket_v1(enum signal_type 
> > signal,
> >
> >  static void build_vrr_infopacket_v2(enum signal_type signal,
> >   const struct mod_vrr_params *vrr,
> > - const enum color_transfer_func *app_tf,
> > + enum color_transfer_func app_tf,
> >   struct dc_info_packet *infopacket)
> >  {
> >   unsigned int payload_size = 0;
> > @@ -664,8 +664,7 @@ static void build_vrr_infopacket_v2(enum signal_type 
> > signal,
> >   build_vrr_infopacket_header_v2(signal, infopacket, _size);
> >   build_vrr_infopacket_data(vrr, infopacket);
> >
> > - if (app_tf != NULL)
> > - build_vrr_infopacket_fs2_data(*app_tf, infopacket);
> > + build_vrr_infopacket_fs2_data(app_tf, infopacket);
> >
> >   build_vrr_infopacket_checksum(_size, infopacket);
> >
> > @@ -676,7 +675,7 @@ void mod_freesync_build_vrr_infopacket(struct 
> > mod_freesync *mod_freesync,
> >   const struct dc_stream_state *stream,
> >   const struct mod_vrr_params *vrr,
> >   enum vrr_packet_type packet_type,
> > - const enum color_transfer_func *app_tf,
> > + enum color_transfer_func app_tf,
> >   struct dc_info_packet *infopacket)
> >  {
> >   /* SPD info packet for FreeSync */
> > diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h 
> > b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> > index 949a8b62aa98..063af6258fd9 100644
> > --- a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> > +++ b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> > @@ -145,7 +145,7 @@ void mod_freesync_build_vrr_infopacket(struct 
> > mod_freesync *mod_freesync,
> >   const struct dc_stream_state *stream,
> >   const struct mod_vrr_params *vrr,
> >   enum vrr_packet_type packet_type,
> > - const enum color_transfer_func *app_tf,
> > + enum color_transfer_func app_tf,
> >   struct dc_info_packet *infopacket);
> >
> >  void mod_freesync_build_vrr_params(struct mod_freesync *mod_freesync,
> > --
> > 2.20.0
> >
>
> Gentle ping on this patch, it would be nice to get this fixed and into
> 5.1!
>
> Thanks,
> Nathan
> ___
> 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 109265] [regression, bisected] arb_texture_multisample texelfetch piglit test failing on NIR backend

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #6 from Timothy Arceri  ---
Fixed by:

commit 7536af670b7501228628a8c90f9e8456b5aec9e1
Author: Timothy Arceri 
Date:   Wed Feb 27 18:26:07 2019 +1100

glsl: fix shader cache for packed param list

Some types of params such as some builtins are always padded. We
need to keep track of this so we can restore the list correctly.

Here we also remove a couple of cache entries that are not actually
required as they get rebuilt by the _mesa_add_parameter() calls.

This patch fixes a bunch of arb_texture_multisample and
arb_sample_shading piglit tests for the radeonsi NIR backend.

Fixes: edded1237607 ("mesa: rework ParameterList to allow packing")

Reviewed-by: Marek Olšák 

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

[PATCH] virtgpu: Update kernel header

[Gurchetan Singh]

Generated using make headers_install.

This brings in the in/out fence support for explicit
synchronization.

v2: don't use experimental kernel branch

Signed-off-by: Gurchetan Singh 
---
 include/drm/virtgpu_drm.h | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/include/drm/virtgpu_drm.h b/include/drm/virtgpu_drm.h
index 9a781f06..f06a789f 100644
--- a/include/drm/virtgpu_drm.h
+++ b/include/drm/virtgpu_drm.h
@@ -47,6 +47,13 @@ extern "C" {
 #define DRM_VIRTGPU_WAIT 0x08
 #define DRM_VIRTGPU_GET_CAPS  0x09
 
+#define VIRTGPU_EXECBUF_FENCE_FD_IN0x01
+#define VIRTGPU_EXECBUF_FENCE_FD_OUT   0x02
+#define VIRTGPU_EXECBUF_FLAGS  (\
+   VIRTGPU_EXECBUF_FENCE_FD_IN |\
+   VIRTGPU_EXECBUF_FENCE_FD_OUT |\
+   0)
+
 struct drm_virtgpu_map {
__u64 offset; /* use for mmap system call */
__u32 handle;
@@ -54,12 +61,12 @@ struct drm_virtgpu_map {
 };
 
 struct drm_virtgpu_execbuffer {
-   __u32   flags;  /* for future use */
+   __u32 flags;
__u32 size;
__u64 command; /* void* */
__u64 bo_handles;
__u32 num_bo_handles;
-   __u32 pad;
+   __s32 fence_fd; /* in/out fence fd (see 
VIRTGPU_EXECBUF_FENCE_FD_IN/OUT) */
 };
 
 #define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
@@ -137,7 +144,7 @@ struct drm_virtgpu_get_caps {
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map)
 
 #define DRM_IOCTL_VIRTGPU_EXECBUFFER \
-   DRM_IOW(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
+   DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
struct drm_virtgpu_execbuffer)
 
 #define DRM_IOCTL_VIRTGPU_GETPARAM \
-- 
2.20.1

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

Re: [PATCH RFC 1/1] uio: Add dma-buf import ioctls

[Hyun Kwon]

Hi Daniel,

On Wed, 2019-02-27 at 06:13:45 -0800, Daniel Vetter wrote:
> On Tue, Feb 26, 2019 at 11:20 PM Hyun Kwon  wrote:
> >
> > Hi Daniel,
> >
> > Thanks for the comment.
> >
> > On Tue, 2019-02-26 at 04:06:13 -0800, Daniel Vetter wrote:
> > > On Tue, Feb 26, 2019 at 12:53 PM Greg Kroah-Hartman
> > >  wrote:
> > > >
> > > > On Sat, Feb 23, 2019 at 12:28:17PM -0800, Hyun Kwon wrote:
> > > > > Add the dmabuf map / unmap interfaces. This allows the user driver
> > > > > to be able to import the external dmabuf and use it from user space.
> > > > >
> > > > > Signed-off-by: Hyun Kwon 
> > > > > ---
> > > > >  drivers/uio/Makefile |   2 +-
> > > > >  drivers/uio/uio.c|  43 +
> > > > >  drivers/uio/uio_dmabuf.c | 210 
> > > > > +++
> > > > >  drivers/uio/uio_dmabuf.h |  26 ++
> > > > >  include/uapi/linux/uio/uio.h |  33 +++
> > > > >  5 files changed, 313 insertions(+), 1 deletion(-)
> > > > >  create mode 100644 drivers/uio/uio_dmabuf.c
> > > > >  create mode 100644 drivers/uio/uio_dmabuf.h
> > > > >  create mode 100644 include/uapi/linux/uio/uio.h
> > > > >
> > > > > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > > > > index c285dd2..5da16c7 100644
> > > > > --- a/drivers/uio/Makefile
> > > > > +++ b/drivers/uio/Makefile
> > > > > @@ -1,5 +1,5 @@
> > > > >  # SPDX-License-Identifier: GPL-2.0
> > > > > -obj-$(CONFIG_UIO)+= uio.o
> > > > > +obj-$(CONFIG_UIO)+= uio.o uio_dmabuf.o
> > > > >  obj-$(CONFIG_UIO_CIF)+= uio_cif.o
> > > > >  obj-$(CONFIG_UIO_PDRV_GENIRQ)+= uio_pdrv_genirq.o
> > > > >  obj-$(CONFIG_UIO_DMEM_GENIRQ)+= uio_dmem_genirq.o
> > > > > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > > > > index 1313422..6841f98 100644
> > > > > --- a/drivers/uio/uio.c
> > > > > +++ b/drivers/uio/uio.c
> > > > > @@ -24,6 +24,12 @@
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > +#include 
> > > > > +#include 
> > > > > +
> > > > > +#include 
> > > > > +
> > > > > +#include "uio_dmabuf.h"
> > > > >
> > > > >  #define UIO_MAX_DEVICES  (1U << MINORBITS)
> > > > >
> > > > > @@ -454,6 +460,8 @@ static irqreturn_t uio_interrupt(int irq, void 
> > > > > *dev_id)
> > > > >  struct uio_listener {
> > > > >   struct uio_device *dev;
> > > > >   s32 event_count;
> > > > > + struct list_head dbufs;
> > > > > + struct mutex dbufs_lock; /* protect @dbufs */
> > > > >  };
> > > > >
> > > > >  static int uio_open(struct inode *inode, struct file *filep)
> > > > > @@ -500,6 +508,9 @@ static int uio_open(struct inode *inode, struct 
> > > > > file *filep)
> > > > >   if (ret)
> > > > >   goto err_infoopen;
> > > > >
> > > > > + INIT_LIST_HEAD(>dbufs);
> > > > > + mutex_init(>dbufs_lock);
> > > > > +
> > > > >   return 0;
> > > > >
> > > > >  err_infoopen:
> > > > > @@ -529,6 +540,10 @@ static int uio_release(struct inode *inode, 
> > > > > struct file *filep)
> > > > >   struct uio_listener *listener = filep->private_data;
> > > > >   struct uio_device *idev = listener->dev;
> > > > >
> > > > > + ret = uio_dmabuf_cleanup(idev, >dbufs, 
> > > > > >dbufs_lock);
> > > > > + if (ret)
> > > > > + dev_err(>dev, "failed to clean up the dma 
> > > > > bufs\n");
> > > > > +
> > > > >   mutex_lock(>info_lock);
> > > > >   if (idev->info && idev->info->release)
> > > > >   ret = idev->info->release(idev->info, inode);
> > > > > @@ -652,6 +667,33 @@ static ssize_t uio_write(struct file *filep, 
> > > > > const char __user *buf,
> > > > >   return retval ? retval : sizeof(s32);
> > > > >  }
> > > > >
> > > > > +static long uio_ioctl(struct file *filep, unsigned int cmd, unsigned 
> > > > > long arg)
> > > >
> > > > We have resisted adding a uio ioctl for a long time, can't you do this
> > > > through sysfs somehow?
> > > >
> > > > A meta-comment about your ioctl structure:
> > > >
> > > > > +#define UIO_DMABUF_DIR_BIDIR 1
> > > > > +#define UIO_DMABUF_DIR_TO_DEV2
> > > > > +#define UIO_DMABUF_DIR_FROM_DEV  3
> > > > > +#define UIO_DMABUF_DIR_NONE  4
> > > >
> > > > enumerated type?
> > > >
> > > > > +
> > > > > +struct uio_dmabuf_args {
> > > > > + __s32   dbuf_fd;
> > > > > + __u64   dma_addr;
> > > > > + __u64   size;
> > > > > + __u32   dir;
> > > >
> > > > Why the odd alignment?  Are you sure this is the best packing for such a
> > > > structure?
> > > >
> > > > Why is dbuf_fd __s32?  dir can be __u8, right?
> > > >
> > > > I don't know that dma layer very well, it would be good to get some
> > > > review from others to see if this really is even a viable thing to do.
> > > > The fd handling seems a bit "odd" here, but maybe I just do not
> > > > understand it.
> > >
> > > Frankly looks like a ploy to sidestep review by graphics folks. We'd
> > > ask for the userspace first :-)
> >
> > Please refer to pull request [1].
> >
> > For any 

[PATCH] virtgpu: Update kernel header

[Gurchetan Singh]

Generated using make headers_install.

This brings in the in/out fence support for explicit
synchronization.

Signed-off-by: Gurchetan Singh 
---
 include/drm/virtgpu_drm.h | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/include/drm/virtgpu_drm.h b/include/drm/virtgpu_drm.h
index 9a781f06..acb21912 100644
--- a/include/drm/virtgpu_drm.h
+++ b/include/drm/virtgpu_drm.h
@@ -47,6 +47,13 @@ extern "C" {
 #define DRM_VIRTGPU_WAIT 0x08
 #define DRM_VIRTGPU_GET_CAPS  0x09
 
+#define VIRTGPU_EXECBUF_FENCE_FD_IN0x01
+#define VIRTGPU_EXECBUF_FENCE_FD_OUT   0x02
+#define VIRTGPU_EXECBUF_FLAGS  (\
+   VIRTGPU_EXECBUF_FENCE_FD_IN |\
+   VIRTGPU_EXECBUF_FENCE_FD_OUT |\
+   0)
+
 struct drm_virtgpu_map {
__u64 offset; /* use for mmap system call */
__u32 handle;
@@ -54,16 +61,18 @@ struct drm_virtgpu_map {
 };
 
 struct drm_virtgpu_execbuffer {
-   __u32   flags;  /* for future use */
+   __u32 flags;
__u32 size;
__u64 command; /* void* */
__u64 bo_handles;
__u32 num_bo_handles;
-   __u32 pad;
+   __s32 fence_fd; /* in/out fence fd (see 
VIRTGPU_EXECBUF_FENCE_FD_IN/OUT) */
 };
 
 #define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
 #define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */
+#define VIRTGPU_PARAM_NO_TRANSFER  3 /* have VIRTIO_GPU_F_NO_TRANSFER */
+#define VIRTGPU_PARAM_HOST_COHERENT4 /* have VIRTIO_GPU_F_HOST_COHERENT */
 
 struct drm_virtgpu_getparam {
__u64 param;
@@ -137,7 +146,7 @@ struct drm_virtgpu_get_caps {
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map)
 
 #define DRM_IOCTL_VIRTGPU_EXECBUFFER \
-   DRM_IOW(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
+   DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
struct drm_virtgpu_execbuffer)
 
 #define DRM_IOCTL_VIRTGPU_GETPARAM \
-- 
2.20.1

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

Re: [RFC v3 17/19] of: unittest: migrate tests to run on KUnit

[Brendan Higgins]

On Mon, Feb 18, 2019 at 2:56 PM Frank Rowand  wrote:
>
> On 2/12/19 5:44 PM, Brendan Higgins wrote:
> > On Wed, Nov 28, 2018 at 12:56 PM Rob Herring  wrote:
> >>
> >> On Wed, Nov 28, 2018 at 1:38 PM Brendan Higgins
> >>  wrote:

> >>> ---
> >>>  drivers/of/Kconfig|1 +
> >>>  drivers/of/unittest.c | 1405 ++---
> >>>  2 files changed, 752 insertions(+), 654 deletions(-)
> >>>
> > 
> >>> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> >>> index 41b49716ac75f..a5ef44730ffdb 100644
> >>> --- a/drivers/of/unittest.c
> >>> +++ b/drivers/of/unittest.c

> >>> +
> >>> +   KUNIT_EXPECT_EQ(test,
> >>> +   of_property_match_string(np,
> >>> +"phandle-list-names",
> >>> +"first"),
> >>> +   0);
> >>> +   KUNIT_EXPECT_EQ(test,
> >>> +   of_property_match_string(np,
> >>> +"phandle-list-names",
> >>> +"second"),
> >>> +   1);
> >>
> >> Fewer lines on these would be better even if we go over 80 chars.
>
> Agreed.  unittest.c already is a greater than 80 char file in general, and
> is a file that benefits from that.
>

Noted.

>
> > On the of_property_match_string(...), I have no opinion. I will do
> > whatever you like best.
> >
> > Nevertheless, as far as the KUNIT_EXPECT_*(...), I do have an opinion: I am
> > trying to establish a good, readable convention. Given an expect statement
> > structured as
> > ```
> > KUNIT_EXPECT_*(
> > test,
> > expect_arg_0, ..., expect_arg_n,
> > fmt_str, fmt_arg_0, ..., fmt_arg_n)
> > ```
> > where `test` is the `struct kunit` context argument, `expect_arg_{0, ..., 
> > n}`
> > are the arguments the expectations is being made about (so in the above 
> > example,
> > `of_property_match_string(...)` and `1`), and `fmt_*` is the optional format
> > string that comes at the end of some expectations.
> >
> > The pattern I had been trying to promote is the following:
> >
> > 1) If everything fits on 1 line, do that.
> > 2) If you must make a line split, prefer to keep `test` on its own line,
> > `expect_arg_{0, ..., n}` should be kept together, if possible, and the 
> > format
> > string should follow the conventions already most commonly used with format
> > strings.
> > 3) If you must split up `expect_arg_{0, ..., n}` each argument should get 
> > its
> > own line and should not share a line with either `test` or any `fmt_*`.
> >
> > The reason I care about this so much is because expectations should be
> > extremely easy to read; they are the most important part of a unit
> > test because they tell you what the test is verifying. I am not
> > married to the formatting I proposed above, but I want something that
> > will be extremely easy to identify the arguments that the expectation
> > is on. Maybe that means that I need to add some syntactic fluff to
> > make it clearer, I don't know, but this is definitely something we
> > need to get right, especially in the earliest examples.
>
> I will probably raise the ire of the kernel formatting rule makers by offering
> what I think is a _much_ more readable format __for this specific case__.
> In other words for drivers/of/unittest.c.
>
> If you can not make your mail window _very_ wide, or if this email has been
> line wrapped, this example will not be clear.
>
> Two possible formats:
>
>
> ### -  version 1, as created by the patch series
>
> static void of_unittest_property_string(struct kunit *test)
> {
> const char *strings[4];
> struct device_node *np;
> int rc;
>
> np = of_find_node_by_path("/testcase-data/phandle-tests/consumer-a");
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
>
> KUNIT_EXPECT_EQ(
> test,
> of_property_match_string(np, "phandle-list-names", "first"),
> 0);
> KUNIT_EXPECT_EQ(
> test,
> of_property_match_string(np, "phandle-list-names", "second"),
> 1);
> KUNIT_EXPECT_EQ(
> test,
> of_property_match_string(np, "phandle-list-names", "third"),
> 2);
> KUNIT_EXPECT_EQ_MSG(
> test,
> of_property_match_string(np, "phandle-list-names", "fourth"),
> -ENODATA,
> "unmatched string");
> KUNIT_EXPECT_EQ_MSG(
> test,
> of_property_match_string(np, "missing-property", "blah"),
> -EINVAL,
> "missing property");
> KUNIT_EXPECT_EQ_MSG(
> test,
> of_property_match_string(np, "empty-property", "blah"),
> -ENODATA,
> "empty property");
> KUNIT_EXPECT_EQ_MSG(
>

Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework

[John Stultz]

On Wed, Feb 27, 2019 at 3:22 PM Laura Abbott  wrote:
> On 2/25/19 6:36 AM, Andrew F. Davis wrote:
> > +
> > +dev_t dma_heap_devt;
> > +struct class *dma_heap_class;
>
> Can we make sure this gets reviewed by Greg sooner rather than
> later when we drop the RFC? I think the use of this here
> is fine with the device model but I'd rather not find out at
> the end.

Agreed!

> > +/**
> > + * struct dma_heap_allocation_data - metadata passed from userspace for
> > + *  allocations
> > + * @len: size of the allocation
> > + * @flags:   flags passed to pool
> > + * @fd:  will be populated with a fd which provdes the
> > + *   handle to the allocated dma-buf
> > + *
> > + * Provided by userspace as an argument to the ioctl
> > + */
> > +struct dma_heap_allocation_data {
> > + __u64 len;
> > + __u32 flags;
> > + __u32 fd;
> > + __u32 reserved0;
> > + __u32 reserved1;
> > +};
> > +
>
> Did you have anything in particular for the reserved fields?
> I don't object to having them, was just curious.

As we have thinned down some of the ion fields, I'm mostly suspecting
some additions may be needed as we start integrating more vendor
implemented heaps. But I don't have any plans myself.

> It might be worth considering bumping up the flags to u64
> and/or adding an align field back in. I originally removed
> the align field because nothing was actually using it and
> it seemed to cause more confusion than anything. I suggested
> if heaps really wanted an alignment they could pass it in
> the flags.

Yea, I think a u64 for flags is a good idea. If we don't have an
immediate use for an alignment field, it might be good to just hold
one of the reserved fields for that for now before complicating the
interface w/o users.

> Did you have thoughts on declaring which bits of the flags
> can be used by heaps for their own private use? That was
> a request I got several times.

Hrm.  I sort of feel like if folks can create their own heaps, we
shouldn't need too many options on how to allocate from those heaps.
I'd rather try to force a more standard interface so that userland
allocators can be more easily switched to use different heaps (just by
changing the pathname) w/o extra considerations.

But maybe I'm being a short-sighted. I guess if we really need this,
I'd probably just add an explicit heap_private field instead? I guess
that's another potential use for the reserved fields?

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

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

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

--- Comment #7 from Marek Olšák  ---
(In reply to Daniel P. Berrange from comment #4)
> I'm curious what motivated this change to start with ?  Even if QEMU was not
> enforcing seccomp filters, I think I'd consider it a bug for mesa to be
> setting its process affinity in this way.  The mgmt application or sysadmin
> has decided that the process must have a certain affinity, based on how
> it/they want the host CPUs utilized. Why is mesa wanting to override this
> administrative policy decision to restrict CPU usage ?

The correct solution is to fix pthread_setaffinity such that it returns an
error code instead of crashing.

An even better solution would be to have a virtual thread affinity that only
the application can see and change, which should be silently masked by
administrative policies not visible to the application.

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

Re: [PATCH v2] drm/vgem: fix use-after-free when drm_gem_handle_create() fails

[Laura Abbott]

On 2/26/19 1:44 PM, Eric Biggers wrote:

From: Eric Biggers 

If drm_gem_handle_create() fails in vgem_gem_create(), then the
drm_vgem_gem_object is freed twice: once when the reference is dropped
by drm_gem_object_put_unlocked(), and again by __vgem_gem_destroy().

This was hit by syzkaller using fault injection.

Fix it by skipping the second free.

Reported-by: syzbot+e73f2fb5ed5a5df36...@syzkaller.appspotmail.com
Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Reviewed-by: Chris Wilson 
Cc: Laura Abbott 
Cc: Daniel Vetter 
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers 
---
  drivers/gpu/drm/vgem/vgem_drv.c | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 5930facd6d2d8..11a8f99ba18c5 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -191,13 +191,9 @@ static struct drm_gem_object *vgem_gem_create(struct 
drm_device *dev,
ret = drm_gem_handle_create(file, >base, handle);
drm_gem_object_put_unlocked(>base);
if (ret)
-   goto err;
+   return ERR_PTR(ret);
  
  	return >base;

-
-err:
-   __vgem_gem_destroy(obj);
-   return ERR_PTR(ret);
  }
  
  static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev,





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

Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework

[Laura Abbott]

On 2/25/19 6:36 AM, Andrew F. Davis wrote:

This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.

Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.

Signed-off-by: Andrew F. Davis 
---

Hello all,

I had a little less time over the weekend than I thought I would to
clean this up more and finish the first set of user heaps, but wanted
to get this out anyway.

ION in its current form assumes a lot about the memory it exports and
these assumptions lead to restrictions on the full range of operations
dma-buf's can produce. Due to this if we are to add this as an extension
of the core dma-buf then it should only be the user-space advertisement
and allocation front-end. All dma-buf exporting and operation need to be
placed in the control of the exporting heap. The core becomes rather
small, just a few hundred lines you see here. This is not to say we
should not provide helpers to make the heap exporters more simple, but
they should only be helpers and not enforced by the core framework.

Basic use model here is an exporter (dedicated heap memory driver, CMA,
System, etc.) registers with the framework by providing a struct
dma_heap_info which gives us the needed info to export this heap to
userspace as a device node. Next a user will request an allocation,
the IOCTL is parsed and the request made to a heap provided alloc() op.
The heap should return the filled out struct dma_heap_buffer, including
exporting the buffer as a dma-buf. This dma-buf we then return to the
user as a fd. Buffer free is still a bit open as we need to update some
stats and free some memory, but the release operation is controlled by
the heap exporter, so some hook will have to be created.

It all needs a bit more work, and I'm sure I'll find missing parts when
I add some more heaps, but hopefully this framework is simple enough that
it does not impede the implementation of all functionality once provided
by ION (shrinker, delayed free), nor any new functionality needed for
future heap exporting devices.



I like this concept and I'm happy to see it go forward. Some high level
comments


Thanks,
Andrew

  drivers/dma-buf/Kconfig   |  12 ++
  drivers/dma-buf/Makefile  |   1 +
  drivers/dma-buf/dma-heap.c| 268 ++
  include/linux/dma-heap.h  |  57 
  include/uapi/linux/dma-heap.h |  54 +++
  5 files changed, 392 insertions(+)
  create mode 100644 drivers/dma-buf/dma-heap.c
  create mode 100644 include/linux/dma-heap.h
  create mode 100644 include/uapi/linux/dma-heap.h

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 2e5a0faa2cb1..30b0d7c83945 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -39,4 +39,16 @@ config UDMABUF
  A driver to let userspace turn memfd regions into dma-bufs.
  Qemu can use this to create host dmabufs for guest framebuffers.
  
+menuconfig DMABUF_HEAPS

+   bool "DMA-BUF Userland Memory Heaps"
+   depends on HAS_DMA && MMU
+   select GENERIC_ALLOCATOR
+   select DMA_SHARED_BUFFER
+   help
+ Choose this option to enable the DMA-BUF userland memory heaps,
+ this allows userspace to allocate dma-bufs that can be shared between
+ drivers.
+
+source "drivers/dma-buf/heaps/Kconfig"
+
  endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6ccab5a..b0332f143413 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
  obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
+obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
  obj-$(CONFIG_SYNC_FILE)   += sync_file.o
  obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
  obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
new file mode 100644
index ..72ed225fa892
--- /dev/null
+++ b/drivers/dma-buf/dma-heap.c
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Framework for userspace DMA-BUF allocations
+ *
+ * Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2019 Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define DEVNAME "dma_heap"
+
+#define NUM_HEAP_MINORS 128
+static DEFINE_IDR(dma_heap_idr);
+static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */
+
+dev_t dma_heap_devt;
+struct class *dma_heap_class;


Can we make sure this gets reviewed by Greg sooner rather than
later when we drop the RFC? I think the use of this here
is fine with the device model but I'd rather not find out at
the end.


+struct list_head dma_heap_list;
+struct dentry *dma_heap_debug_root;
+
+/**
+ * struct dma_heap - represents a dmabuf heap in the system
+ * @name:  used for 

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

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

--- Comment #6 from Marc-Andre Lureau  ---
Sent a quick RFC for an env variable workaround on the ML "[PATCH] RFC:
Workaround for pthread_setaffinity_np() seccomp filtering".

-- 
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/vkms: fix use-after-free when drm_gem_handle_create() fails

[Rodrigo Siqueira]

On 02/26, Eric Biggers wrote:
> From: Eric Biggers 
> 
> If drm_gem_handle_create() fails in vkms_gem_create(), then the
> vkms_gem_object is freed twice: once when the reference is dropped by
> drm_gem_object_put_unlocked(), and again by the extra calls to
> drm_gem_object_release() and kfree().
> 
> Fix it by skipping the second release and free.
> 
> This bug was originally found in the vgem driver by syzkaller using
> fault injection, but I noticed it's also present in the vkms driver.
> 
> Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> Cc: Chris Wilson 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers 
> ---
>  drivers/gpu/drm/vkms/vkms_gem.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index 138b0bb325cf9..69048e73377dc 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -111,11 +111,8 @@ struct drm_gem_object *vkms_gem_create(struct drm_device 
> *dev,
>  
>   ret = drm_gem_handle_create(file, >gem, handle);
>   drm_gem_object_put_unlocked(>gem);
> - if (ret) {
> - drm_gem_object_release(>gem);
> - kfree(obj);
> + if (ret)
>   return ERR_PTR(ret);
> - }
>  
>   return >gem;
>  }
> -- 
> 2.21.0.rc2.261.ga7da99ff1b-goog
> 

Hi,

Thanks for your patch! :)

The patch looks good for me. I also tested it under the IGT tests on my
local VM and everything was fine.

Reviewed-by: Rodrigo Siqueira 

-- 
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo


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

[Bug 109265] [regression, bisected] arb_texture_multisample texelfetch piglit test failing on NIR backend

[bugzilla-daemon]

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

--- Comment #5 from Timothy Arceri  ---
You were right it was a bad bisect due to that patch breaking MSAA also. I
found the real issue, fix sent to the list.

https://patchwork.freedesktop.org/patch/288934/

-- 
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 109749] FreeSync stutters if framerate is less than refresh rate and vsync/flipping is on

[bugzilla-daemon]

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

--- Comment #2 from bmil...@gmail.com ---
Fix was pushed to 5.0, should we mark this as resolved for now?

-- 
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 108359] amdgpu-pro rpm packages cyclical dependencies

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

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

--- Comment #2 from Jeremy Newton  ---
Closing as fixed, please reopen if you can reproduce the issue on the latest
build.

-- 
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: Wake up next in drm_read() chain if we are forced to putback the event

[Chris Wilson]

Quoting Chris Wilson (2019-02-27 10:17:15)
> Quoting Daniel Vetter (2017-08-07 10:28:58)
> > On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> > > After an event is sent, we try to copy it into the user buffer of the
> > > first waiter in drm_read() and if the user buffer doesn't have enough
> > > room we put it back onto the list. However, we didn't wake up any
> > > subsequent waiter, so that event may sit on the list until either a new
> > > vblank event is sent or a new waiter appears. Rare, but in the worst
> > > case may lead to a stuck process.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Daniel Vetter 
> > 
> > New subtestcase in igt@drm_read?
> 
> Caught it!
> Testcase: igt/drm_read/short-buffer-wakeup

And pushed with Ville's irc r-b.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework

[John Stultz]

On Wed, Feb 27, 2019 at 8:38 AM Andrew F. Davis  wrote:
>
> On 2/26/19 5:40 PM, John Stultz wrote:
> > On Tue, Feb 26, 2019 at 11:21 AM John Stultz  wrote:
> > I've updated the patches here:
> > kernel: 
> > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
> > userland: 
> > https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
> >
> >
> >> I also realized some of Benajmin's error path improvements are going
> >> to be hard to fix w/ my current code, specifically having the allocate
> >> op do the allocation of the dma_heap_buffer (since we don't have a
> >> free op, if something fails creating the dmabuf fd in the core, we
> >> don't have a hook to release the dma_heap_buffer and heap private
> >> data).
> >
>
> We can always add back the free op, the alternative is to have the heap
> export the fd.
>
> I'm not sure either is needed though, when we
> dma_buf_put(buffer->dmabuf) on the error path it should trigger the
> release op, and that can cleanup the allocations in the heap.

Good point, but I worry that's a bit subtle.

Also doing the stuff with the helpers where we have to register a free
callback is kind of ugly, and I personally like the symmetry of having
free hooks if we have allocation hooks (even if the dmabuf release
hook initiates the free call).

> > I also realized doing my development and testing against my
> > hikey960-mainline-WIP branch, I accidentally folded in an ion hack I
> > was using to reduce cache operations, so I'll need to undo that in the
> > heap-helpers.c.  But at least we have a rough validation point for the
> > design.
> >
>
> Great! The details of the heap-helpers can always get fixed up at a
> later point, validation of the core working is really good to hear.
>

Let me know if you have any further feedback or changes to integrate.
I've got to get back to some other work, but will try to take a
cleanup pass in the next few days.

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

[PATCH v2 0/5] drm/bridge: sii902x: HDMI-audio support and some fixes

[Jyri Sarha]

Changes since first version:
- Moved reviewed patches to front:
  - drm/bridge: sii902x: add input_bus_flags
  - drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID
  - drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
- Added a new fix:
  - drm/bridge: sii902x: Select I2C_MUX
- Applied some review suggestions to
  - drm/bridge: sii902x: Implement HDMI audio support
- use clock-names property to name mclk
- move comment describing added mutex to struct sii902x and improve it
- cleanup sii902x_mute()
- cleanup sii902x_select_mclk_div()
- fix condition for checking ENABLE_BIT from i2s_fifo_routing in
  sii902x_audio_codec_init()

Still to do

- Agree on i2s wires to HDMI audio fifo routing in dts. 

  The current scheme is quite straight forward, but there is maybe
  there is even more straight forward solutions like:

  audio-fifo-enable = <1 1 1 1>;
  audio-i2s-pin-to-fifo = <0 1 2 3>;

  Meaning that all fifos are enabled and SD0 is routed to fifo 0, SD1
  to fifo 1, etc. I am not sure if the channel swap functionality
  should show in dts binding.

Jyri Sarha (4):
  drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID
  drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
  drm/bridge: sii902x: Select I2C_MUX
  drm/bridge: sii902x: Implement HDMI audio support

Tomi Valkeinen (1):
  drm/bridge: sii902x: add input_bus_flags

 .../bindings/display/bridge/sii902x.txt   |  36 +-
 drivers/gpu/drm/bridge/Kconfig|   1 +
 drivers/gpu/drm/bridge/sii902x.c  | 472 +-
 include/dt-bindings/sound/sii902x-audio.h |  11 +
 4 files changed, 512 insertions(+), 8 deletions(-)
 create mode 100644 include/dt-bindings/sound/sii902x-audio.h

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

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

[PATCH v2 1/5] drm/bridge: sii902x: add input_bus_flags

[Jyri Sarha]

From: Tomi Valkeinen 

The driver always sets InputBusFmt:EDGE to 0 (falling edge).

Add drm_bridge_timings's input_bus_flags to reflect that the bridge
samples on falling edges.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jyri Sarha 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sii902x.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index bfa902013aa4..1afa000141d5 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -459,6 +459,12 @@ static int sii902x_i2c_bypass_deselect(struct i2c_mux_core 
*mux, u32 chan_id)
return 0;
 }
 
+static const struct drm_bridge_timings default_sii902x_timings = {
+   .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
+| DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE
+| DRM_BUS_FLAG_DE_HIGH,
+};
+
 static int sii902x_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
@@ -529,6 +535,7 @@ static int sii902x_probe(struct i2c_client *client,
 
sii902x->bridge.funcs = _bridge_funcs;
sii902x->bridge.of_node = dev->of_node;
+   sii902x->bridge.timings = _sii902x_timings;
drm_bridge_add(>bridge);
 
i2c_set_clientdata(client, sii902x);
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 2/5] drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID

[Jyri Sarha]

Set output mode to HDMI or DVI according to EDID HDMI signature.

Signed-off-by: Jyri Sarha 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sii902x.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 1afa000141d5..0e21fa419d27 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -181,11 +181,15 @@ static int sii902x_get_modes(struct drm_connector 
*connector)
struct sii902x *sii902x = connector_to_sii902x(connector);
u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
struct edid *edid;
+   u8 output_mode = SII902X_SYS_CTRL_OUTPUT_DVI;
int num = 0, ret;
 
edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]);
drm_connector_update_edid_property(connector, edid);
if (edid) {
+   if (drm_detect_hdmi_monitor(edid))
+   output_mode = SII902X_SYS_CTRL_OUTPUT_HDMI;
+
num = drm_add_edid_modes(connector, edid);
kfree(edid);
}
@@ -195,6 +199,11 @@ static int sii902x_get_modes(struct drm_connector 
*connector)
if (ret)
return ret;
 
+   ret = regmap_update_bits(sii902x->regmap, SII902X_SYS_CTRL_DATA,
+SII902X_SYS_CTRL_OUTPUT_MODE, output_mode);
+   if (ret)
+   return ret;
+
return num;
 }
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 5/5] drm/bridge: sii902x: Implement HDMI audio support

[Jyri Sarha]

Implement HDMI audio support by using ASoC HDMI codec. The commit
implements the necessary callbacks and configuration for the HDMI
codec and registers a virtual platform device for the codec to attach.

Signed-off-by: Jyri Sarha 
---
 .../bindings/display/bridge/sii902x.txt   |  36 +-
 drivers/gpu/drm/bridge/sii902x.c  | 453 +-
 include/dt-bindings/sound/sii902x-audio.h |  11 +
 3 files changed, 493 insertions(+), 7 deletions(-)
 create mode 100644 include/dt-bindings/sound/sii902x-audio.h

diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt 
b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
index 72d2dc6c3e6b..647b2fd84db9 100644
--- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
@@ -5,9 +5,32 @@ Required properties:
- reg: i2c address of the bridge
 
 Optional properties:
-   - interrupts: describe the interrupt line used to inform the host 
+   - interrupts: describe the interrupt line used to inform the host
  about hotplug events.
- reset-gpios: OF device-tree gpio specification for RST_N pin.
+   - i2s-fifo-routing: Array of exactly 4 integers indicating i2s
+ pins for audio fifo routing. First integer defines routing to
+ fifo 0 and second to fifo 1, etc. Integers can be filled with
+ definitions from: include/dt-bindings/sound/sii902x-audio.h
+ The available definitions are:
+ - ENABLE_BIT: enable this audio fifo
+ - CONNECT_SD#: route audio input from SD0, SD1, SD2, or SD3 i2s
+data input pin
+ - LEFT_RIGHT_SWAP_BIT: swap i2s input channels for this fifo
+ I2S HDMI audio is configured only if this property is found.
+   - clocks: phandle mclk
+   - clock-names: "mclk"
+   Describes SII902x MCLK input. MCLK is used to produce
+   HDMI audio CTS values. This property is required if
+   "i2s-fifo-routing"-property is present. This property follows
+   Documentation/devicetree/bindings/clock/clock-bindings.txt
+   consumer binding.
+   - #sound-dai-cells = <0>: ASoC codec dai available for simple-card
+   If audio properties are present sii902x provides an ASoC
+   codec component driver that can be used by other ASoC
+   components like simple-card. See binding document for
+   details:
+   Documentation/devicetree/bindings/sound/simple-card.txt
 
 Optional subnodes:
- video input: this subnode can contain a video input port node
@@ -21,6 +44,17 @@ Example:
compatible = "sil,sii9022";
reg = <0x39>;
reset-gpios = < 1 0>;
+
+   #sound-dai-cells = <0>;
+   i2s-fifo-routing = <
+   (ENABLE_BIT|CONNECT_SD0)
+   0
+   0
+   0
+   >;
+   clocks = <>;
+   clock-names = "mclk";
+
ports {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 1e91ed72..2be27bc54fb5 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -27,12 +27,16 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+
 #define SII902X_TPI_VIDEO_DATA 0x0
 
 #define SII902X_TPI_PIXEL_REPETITION   0x8
@@ -74,6 +78,77 @@
 #define SII902X_AVI_POWER_STATE_MSKGENMASK(1, 0)
 #define SII902X_AVI_POWER_STATE_D(l)   ((l) & 
SII902X_AVI_POWER_STATE_MSK)
 
+/* Audio  */
+#define SII902X_TPI_I2S_ENABLE_MAPPING_REG 0x1f
+#define SII902X_TPI_I2S_CONFIG_FIFO0   (0 << 0)
+#define SII902X_TPI_I2S_CONFIG_FIFO1   (1 << 0)
+#define SII902X_TPI_I2S_CONFIG_FIFO2   (2 << 0)
+#define SII902X_TPI_I2S_CONFIG_FIFO3   (3 << 0)
+#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP(1 << 2)
+#define SII902X_TPI_I2S_AUTO_DOWNSAMPLE(1 << 3)
+#define SII902X_TPI_I2S_SELECT_SD0 (0 << 4)
+#define SII902X_TPI_I2S_SELECT_SD1 (1 << 4)
+#define SII902X_TPI_I2S_SELECT_SD2 (2 << 4)
+#define SII902X_TPI_I2S_SELECT_SD3 (3 << 4)
+#define SII902X_TPI_I2S_FIFO_ENABLE(1 << 7)
+
+#define SII902X_TPI_I2S_INPUT_CONFIG_REG   0x20
+#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_YES(0 << 0)
+#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_NO (1 << 0)
+#define SII902X_TPI_I2S_SD_DIRECTION_MSB_FIRST (0 << 1)
+#define SII902X_TPI_I2S_SD_DIRECTION_LSB_FIRST (1 << 1)
+#define SII902X_TPI_I2S_SD_JUSTIFY_LEFT(0 << 2)

[PATCH v2 3/5] drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz

[Jyri Sarha]

The pixel clock unit in the first two registers (0x00 and 0x01) of
sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
10 fixes the issue.

Signed-off-by: Jyri Sarha 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sii902x.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 0e21fa419d27..1e91ed72 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -248,10 +248,11 @@ static void sii902x_bridge_mode_set(struct drm_bridge 
*bridge,
struct regmap *regmap = sii902x->regmap;
u8 buf[HDMI_INFOFRAME_SIZE(AVI)];
struct hdmi_avi_infoframe frame;
+   u16 pixel_clock_10kHz = adj->clock / 10;
int ret;
 
-   buf[0] = adj->clock;
-   buf[1] = adj->clock >> 8;
+   buf[0] = pixel_clock_10kHz & 0xFF;
+   buf[1] = pixel_clock_10kHz >> 8;
buf[2] = adj->vrefresh;
buf[3] = 0x00;
buf[4] = adj->hdisplay;
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v2 4/5] drm/bridge: sii902x: Select I2C_MUX

[Jyri Sarha]

"drm/bridge/sii902x: Fix EDID readback"-commit added a dependency to
I2C_MUX, but not indicate it in the Kconfig entry. Fix it by selecting
I2C_MUX for DRM_SII902X config option.

Fixes: 88664675239 ("drm/bridge/sii902x: Fix EDID readback")
Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/bridge/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index fb0b37918382..a6f6ff8f06b3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -95,6 +95,7 @@ config DRM_SII902X
depends on OF
select DRM_KMS_HELPER
select REGMAP_I2C
+   select I2C_MUX
---help---
  Silicon Image sii902x bridge chip driver.
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[Bug 109762] [AMDGPU] flip_done timed out when playing Xonotic

[bugzilla-daemon]

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

--- Comment #1 from Amadeusz  ---
So as I half remembered it didn't happen in the past.

I did some internet searches and there are few similar bugs on this bugzilla:
https://bugzilla.freedesktop.org/show_bug.cgi?id=109461
https://bugzilla.freedesktop.org/show_bug.cgi?id=104624
https://bugzilla.freedesktop.org/show_bug.cgi?id=108309

But also I found:
https://bbs.archlinux.org/viewtopic.php?id=239670
which allowed me to narrow the time when it broke.

I looked at changes between 4.14 and 4.15 and choose to try reverting one of
the commits with "flip" as part of commit message. (Getting bisect running on
4.14 with too new gcc is pain...)

So seems like reverting 320a127437e5d3cbb7fc444f8769eb510d11d3b9 helps with
random freezes for me (although I tested only for one day).

However from what I can see reverting this commit is just a workaround...

So if anyone wants to try and reproduce it you can install Xonotic from
xonotic.org (or your distribution repositories) and either have some fun
playing or just create infinite time match with bots and once click left mouse
button after it starts to select bot view and leave it running.
One note that I start xonotic from command line with vblank_mode=0 added
before, like "vblank_mode=0 xonotic".

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

[PATCH] xen, fbfront: mark expected switch fall-through

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch
cases where we are expecting to fall through.

This patch fixes the following warning:

drivers/video/fbdev/xen-fbfront.c: In function ‘xenfb_backend_changed’:
drivers/video/fbdev/xen-fbfront.c:678:6: warning: this statement may fall 
through [-Wimplicit-fallthrough=]
   if (dev->state == XenbusStateClosed)
  ^
drivers/video/fbdev/xen-fbfront.c:681:2: note: here
  case XenbusStateClosing:
  ^~~~

Warning level 3 was used: -Wimplicit-fallthrough=3

Notice that, in this particular case, the code comment is modified
in accordance with what GCC is expecting to find.

This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/xen-fbfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/xen-fbfront.c 
b/drivers/video/fbdev/xen-fbfront.c
index 6a4bbc9e1fb0..a3d6b6db221b 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -677,7 +677,7 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
case XenbusStateClosed:
if (dev->state == XenbusStateClosed)
break;
-   /* Missed the backend's CLOSING state -- fallthrough */
+   /* fall through - Missed the backend's CLOSING state. */
case XenbusStateClosing:
xenbus_frontend_closed(dev);
break;
-- 
2.21.0

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

Re: [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

[Ville Syrjälä]

On Wed, Feb 27, 2019 at 03:23:01PM -0500, Adam Jackson wrote:
> On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Some monitors apparently forget to mark any mode as preferred in the
> > EDID. In this particular case we have a very generic looking ID
> > "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> > doesn't seem particularly wise. Also the quirk we have
> > (EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd
> > have to fix it first.
> >
> > As a generic fallback let's just mark the first probed mode (which
> > should be the first detailed mode, assuming there are any) as
> > preferred.
> 
> What problem is this trying to fix? Userspace (and drm for that matter)
> is typically going to pick the first mode in the list anyway if there's
> none marked as preferred. Not having any preferred modes was pretty
> common on CRTs IIRC.

Ah sorry, I forgot to mention the original symptoms. The problem is
that with no preferred mode i915 decided to get the fixed mode for
the panel from the VBT instead. That one turned out to be 1024x768
which made the 800x600 panel somewhat unhappy.

So instead of putting this logic into the EDID parser I guess we
could just put it into the i915 fixed mode code. But then I suppose
we should also fix EDID_QUIRK_FIRST_DETAILED_PREFERRED (assuming it
exists for a good reason).

> 
> The other major case I've seen of a monitor with no preferred mode are
> the early dual-link DVI displays without internal scalers (Apple
> Cinema, Dell 3007WFP, etc). You end up with 1280x800 first in the list
> since 2560x1600 doesn't fit in a single DVI link. It might be nice if
> such monitors decided their preferred mode based on the link
> capabilities; if you know it's a dual-link capable port, you'd probably
> prefer 2560x1600.
> 
> Does it make more sense to run the "infer a preferred mode" logic after
> we've done mode validation for the output?

For this particular case that wouldn't help since then we'd end up
picking the 800x600 75Hz EST mode. Well, I'm not sure whether the
panel would like that or not. The VBIOS at least selects the 800x600
60Hz EST mode for whatever reason.

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

Re: [PATCH v3 2/2] drm/lima: driver for ARM Mali4xx GPUs

[Sam Ravnborg]

Hi Qiang.

Two general comments:
- We are trying to avoid drmP.h in new drivers, please drop
- The use of idr is being replaced with XArray, see patch-set
  posted by Matthew Wilcox.
  Try to use XArray so we do not introduce a new user.

This was from a very quick looks at the driver.
In general things looked good, but these two issues
I stumbled upon.

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

Re: [PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

[Adam Jackson]

On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Some monitors apparently forget to mark any mode as preferred in the
> EDID. In this particular case we have a very generic looking ID
> "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> doesn't seem particularly wise. Also the quirk we have
> (EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd
> have to fix it first.
>
> As a generic fallback let's just mark the first probed mode (which
> should be the first detailed mode, assuming there are any) as
> preferred.

What problem is this trying to fix? Userspace (and drm for that matter)
is typically going to pick the first mode in the list anyway if there's
none marked as preferred. Not having any preferred modes was pretty
common on CRTs IIRC.

The other major case I've seen of a monitor with no preferred mode are
the early dual-link DVI displays without internal scalers (Apple
Cinema, Dell 3007WFP, etc). You end up with 1280x800 first in the list
since 2560x1600 doesn't fit in a single DVI link. It might be nice if
such monitors decided their preferred mode based on the link
capabilities; if you know it's a dual-link capable port, you'd probably
prefer 2560x1600.

Does it make more sense to run the "infer a preferred mode" logic after
we've done mode validation for the output?

- ajax

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

Re: [PATCH] video: fbdev: atmel_lcdfb: drop AVR and platform_data support

[Sam Ravnborg]

Hi Alexandre.

Nice patch, good to clean out unused code.
On Mon, Feb 25, 2019 at 10:25:33PM +0100, Alexandre Belloni wrote:
> Make the driver OF only as since AVR32 has been removed from the kernel,
> there are only OF enabled platform using it.
> 
> Signed-off-by: Alexandre Belloni 
Reviewed-by: Sam Ravnborg 

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

Re: [PATCH] drm: prefix header search paths with $(srctree)/

[Sam Ravnborg]

Hi Masahiro.

On Thu, Jan 31, 2019 at 12:56:39PM +0900, Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
> 
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way, but not all. The goal of this work is to make the notation
> consistent, and finally get rid of the gross hacks.
> 
> Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> ("kbuild: do not drop -I without parameter").
> 
> [1]: https://patchwork.kernel.org/patch/9632347/
> 
> Signed-off-by: Masahiro Yamada 

Patch looks good:
Reviewed-by: Sam Ravnborg 

> ---
> 
> I put all gpu/drm changes into a single patch because
> they are trivial conversion.
>
> Please let me know if I need to split this into per-driver patches.
Agree that it is good to have those related chnges together in one patch.

I still need to look into getting commit-rights.
Daniel - can you take this to drm-misc?

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

Re: [PATCH] drm: add func to better detect wether swiotlb is needed

[Konrad Rzeszutek Wilk]

.snip..
> > -u64 drm_get_max_iomem(void)
> > +bool drm_need_swiotlb(int dma_bits)
> >  {
> > struct resource *tmp;
> > resource_size_t max_iomem = 0;
> > 
> > +   /*
> > +* Xen paravirtual hosts require swiotlb regardless of requested dma
> > +* transfer size.
> > +*
> > +* NOTE: Really, what it requires is use of the dma_alloc_coherent
> > +*   allocator used in ttm_dma_populate() instead of
> > +*   ttm_populate_and_map_pages(), which bounce buffers so much
> > in
> > +*   Xen it leads to swiotlb buffer exhaustion.
> > +*/
> > +   if (xen_pv_domain())
> 
> I've not been following all of the ins and outs of the discussion on this so 
> apologies if I'm missing some context, but...
> 
> This looks like the wrong test to me. I think it should be:
> 
> if ( xen_swiotlb )

Ah, that could be as well. 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-fixes-5.0

[Alex Deucher]

Hi Dave, Daniel,

A fix for freesync to prevent stuttering in certain cases.  Freesync
was added in 5.0 so it would be nice to get this in.  If not, I can
just send it to stable once 5.0 is released.

The following changes since commit a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a:

  drm/amdgpu: disable bulk moves for now (2019-02-20 17:13:27 -0500)

are available in the Git repository at:

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

for you to fetch changes up to d63716658ac16c515d1223a9fbf5edbf76b1b333:

  drm/amd/display: Use vrr friendly pageflip throttling in DC. (2019-02-27 
13:55:09 -0500)


Mario Kleiner (1):
  drm/amd/display: Use vrr friendly pageflip throttling in DC.

 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 27 +++
 2 files changed, 24 insertions(+), 4 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it

[Ira Weiny]

On Tue, Feb 19, 2019 at 09:30:33PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny 
> 
> Resending these as I had only 1 minor comment which I believe we have covered
> in this series.  I was anticipating these going through the mm tree as they
> depend on a cleanup patch there and the IB changes are very minor.  But they
> could just as well go through the IB tree.
> 
> NOTE: This series depends on my clean up patch to remove the write parameter
> from gup_fast_permitted()[1]
> 
> HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> advantages.  These pages can be held for a significant time.  But
> get_user_pages_fast() does not protect against mapping of FS DAX pages.
> 
> Introduce FOLL_LONGTERM and use this flag in get_user_pages_fast() which
> retains the performance while also adding the FS DAX checks.  XDP has also
> shown interest in using this functionality.[2]
> 
> In addition we change get_user_pages() to use the new FOLL_LONGTERM flag and
> remove the specialized get_user_pages_longterm call.
> 
> [1] https://lkml.org/lkml/2019/2/11/237
> [2] https://lkml.org/lkml/2019/2/11/1789

Is there anything I need to do on this series or does anyone have any
objections to it going into 5.1?  And if so who's tree is it going to go
through?

Thanks,
Ira

> 
> Ira Weiny (7):
>   mm/gup: Replace get_user_pages_longterm() with FOLL_LONGTERM
>   mm/gup: Change write parameter to flags in fast walk
>   mm/gup: Change GUP fast to use flags rather than a write 'bool'
>   mm/gup: Add FOLL_LONGTERM capability to GUP fast
>   IB/hfi1: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
>   IB/qib: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
>   IB/mthca: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
> 
>  arch/mips/mm/gup.c  |  11 +-
>  arch/powerpc/kvm/book3s_64_mmu_hv.c |   4 +-
>  arch/powerpc/kvm/e500_mmu.c |   2 +-
>  arch/powerpc/mm/mmu_context_iommu.c |   4 +-
>  arch/s390/kvm/interrupt.c   |   2 +-
>  arch/s390/mm/gup.c  |  12 +-
>  arch/sh/mm/gup.c|  11 +-
>  arch/sparc/mm/gup.c |   9 +-
>  arch/x86/kvm/paging_tmpl.h  |   2 +-
>  arch/x86/kvm/svm.c  |   2 +-
>  drivers/fpga/dfl-afu-dma-region.c   |   2 +-
>  drivers/gpu/drm/via/via_dmablit.c   |   3 +-
>  drivers/infiniband/core/umem.c  |   5 +-
>  drivers/infiniband/hw/hfi1/user_pages.c |   5 +-
>  drivers/infiniband/hw/mthca/mthca_memfree.c |   3 +-
>  drivers/infiniband/hw/qib/qib_user_pages.c  |   8 +-
>  drivers/infiniband/hw/qib/qib_user_sdma.c   |   2 +-
>  drivers/infiniband/hw/usnic/usnic_uiom.c|   9 +-
>  drivers/media/v4l2-core/videobuf-dma-sg.c   |   6 +-
>  drivers/misc/genwqe/card_utils.c|   2 +-
>  drivers/misc/vmw_vmci/vmci_host.c   |   2 +-
>  drivers/misc/vmw_vmci/vmci_queue_pair.c |   6 +-
>  drivers/platform/goldfish/goldfish_pipe.c   |   3 +-
>  drivers/rapidio/devices/rio_mport_cdev.c|   4 +-
>  drivers/sbus/char/oradax.c  |   2 +-
>  drivers/scsi/st.c   |   3 +-
>  drivers/staging/gasket/gasket_page_table.c  |   4 +-
>  drivers/tee/tee_shm.c   |   2 +-
>  drivers/vfio/vfio_iommu_spapr_tce.c |   3 +-
>  drivers/vfio/vfio_iommu_type1.c |   3 +-
>  drivers/vhost/vhost.c   |   2 +-
>  drivers/video/fbdev/pvr2fb.c|   2 +-
>  drivers/virt/fsl_hypervisor.c   |   2 +-
>  drivers/xen/gntdev.c|   2 +-
>  fs/orangefs/orangefs-bufmap.c   |   2 +-
>  include/linux/mm.h  |  17 +-
>  kernel/futex.c  |   2 +-
>  lib/iov_iter.c  |   7 +-
>  mm/gup.c| 220 
>  mm/gup_benchmark.c  |   5 +-
>  mm/util.c   |   8 +-
>  net/ceph/pagevec.c  |   2 +-
>  net/rds/info.c  |   2 +-
>  net/rds/rdma.c  |   3 +-
>  44 files changed, 232 insertions(+), 180 deletions(-)
> 
> -- 
> 2.20.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: display: rockchip: add document for rk3066 hdmi

[Rob Herring]

On Wed, Feb 27, 2019 at 12:04 PM Johan Jonker  wrote:
>
> Thanks for your advice.
>
> On 2/25/19 5:59 PM, Rob Herring wrote:> On Fri, Feb 01, 2019 at
> 01:32:35PM +0100, Johan Jonker wrote:
> >> This patch adds a binding that describes the HDMI controller for
> >> rk3066.
> >
> > This is not using the DW block like other Rockchip SoCs (IIRC)?
>
> As outsider it's a little bit difficult to comment on that.
> Maybe an insider can give a better answer.
> The rk3066 is there early model.
> Reusing blocks like in the later improved models wasn't in the fashion
> yet I think.
> Also comparing the rk3066-hdmi driver to the inno driver gives too many
> differences in registers, sound support and irqs.
> If it was similar they would have combined it in there own kernel.
> Given the age there won't come any other support for it.
> This is what we have...

Okay, if it looks different then good enough for me.

> >> Signed-off-by: Johan Jonker 
> >> ---
> >>  .../display/rockchip/rk3066_hdmi-rockchip.txt  | 60
> ++
> >
> > Using the compatible string plus '.txt' is the preferred naming.
>
> Will change that in V2.
> rk3066-hdmi  -> rk3066-hdmi-rockchip.txt
>
> How about the other documents?
> rk3036-inno-hdmi -> inno_hdmi-rockchip.txt
> rk3288-dw-hdmi   -> dw_hdmi-rockchip.txt
> rk3288-dp-> analogix_dp-rockchip.txt
> etc.

Just leave them for now.

> >>  1 file changed, 60 insertions(+)
> >>  create mode 100644
> Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
> >>
> >> diff --git
> a/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
> b/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
> >> new file mode 100644
> >> index 0..6a8f3754f
> >> --- /dev/null
> >> +++
> b/Documentation/devicetree/bindings/display/rockchip/rk3066_hdmi-rockchip.txt
> >> @@ -0,0 +1,60 @@
> >> +Rockchip specific extensions for rk3066 HDMI
> >> +
> >> +
> >> +Required properties:
> >> +- compatible:
> >> +"rockchip,rk3066-hdmi";
> >> +- reg:
> >> +Physical base address and length of the controller's registers.
> >> +- clocks, clock-names:
> >> +Phandle to HDMI controller clock, name should be "hclk".
> >> +- interrupts:
> >> +HDMI interrupt number.
> >> +- power-domains:
> >> +Phandle to the RK3066_PD_VIO power domain.
> >> +- rockchip,grf:
> >> +This soc uses GRF regs to switch the HDMI TX input between vop0 and
> vop1.
> >> +- ports:
>
> Should "ports" be replaced by: "hdmi_in: port"?
> What is preferred?
>
> There are two different methods in use:
> -1
> hdmi_in: port {
>
> -2
> ports {
> hdmi_in: port {

Generally, you have 'ports' when there is more than one 'port' node
which you should in this case.

> >> +Contains one port node with two endpoints, numbered 0 and 1,
> >> +connected respectively to vop0 and vop1.
> >
> > You should have an output port to an hdmi-connector node (or bridge) as
> > well.
>
> Which hdmi-connector node?
> Could you explane with an example?

grep hdmi-connector in the tree there's lot's of examples.

> The Rockchip hdmi nodes I'm aware off only use the port nodes as a way
> to switch the hdmi input between the vop's.
> The vop nodes can have multiple outputs.

Yes, that's the input side. And generally, muxing is represented as
multiple endpoints.

Not all cases of HDMI have defined a connector node as that came along later.

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

Re: [RFC PATCH 1/2] ASoC: simple-card: add support for bclk_ratio

[Mark Brown]

On Tue, Feb 26, 2019 at 05:03:49PM +, Russell King - ARM Linux admin wrote:
> On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:

> > There is talk in the manual about "network mode", which could work by 
> > changing
> > the LRCLK only at the first slot - thereby allowing clients to receive all
> > slots just by counting, as long as they know the slot size?

> > LRCLK   _/-\_/-
> > DATASLOT1|SLOT2|SLOT3|SLOT4|SLOT1

> From what I gather, these are described using SND_SOC_DAIFMT_DSP_A
> and SND_SOC_DAIFMT_DSP_B dai formats, and the parameters are

Roughly, yes - the DSP formats are formats which only care about one
edge of the LRCLK, the difference being if the first data bit is the
same clock cycle as the transition or the next clock cycle.

> controlled not through snd_soc_dai_set_bclk_ratio() but via
> snd_soc_dai_set_tdm_slot().

> So, IMHO, the TDM formats should be disregarded from consideration
> here.  Mark, ack?

I'd expect set_bclk_ratio() to cover all formats - usually the hardware
either has zero flexibility when it comes to the LRCLK format or isn't
super bothered, this stuff is mainly used to adapt the more flexible
hardware to the less flexible hardware.

TDM is definitely something that only really makes sense with DSP
formats though, I2S TDM is just weird.


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

[PATCH 2/2] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

[Ville Syrjala]

From: Ville Syrjälä 

Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.

Assuming that another preferred mode didn't sneak in somehow
(is that even possible?) this should now be fully covered by the
generic fallback that marks the first probed mode as preferred.
So let's just remove the quirk.

I tried to double check the known cases:
* Proview AY765C
  https://bugs.freedesktop.org/show_bug.cgi?id=15160 seems OK
* Unknown Acer
  https://bugzilla.redhat.com/show_bug.cgi?id=284231 (got the
  reference from xf86EdidModes.c), no access
* Philips 107p5 CRT
  "Reported on xorg@ with pastebin", didn't find the mail(s)
* Peacock Ergovision 19 (only in xf86EdidModes.c)
  https://bugzilla.redhat.com/show_bug.cgi?id=492359 seems OK

Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6c6a93647686..59829e596910 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -68,8 +68,6 @@
  * maximum size and use that.
  */
 #define EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE   (1 << 4)
-/* Monitor forgot to set the first detailed is preferred bit. */
-#define EDID_QUIRK_FIRST_DETAILED_PREFERRED(1 << 5)
 /* use +hsync +vsync for detailed mode */
 #define EDID_QUIRK_DETAILED_SYNC_PP(1 << 6)
 /* Force reduced-blanking timings for detailed modes */
@@ -107,8 +105,6 @@ static const struct edid_quirk {
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
{ "API", 0x7602, EDID_QUIRK_PREFER_LARGE_60 },
-   /* Unknown Acer */
-   { "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
 
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
@@ -145,12 +141,6 @@ static const struct edid_quirk {
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
 
-   /* Philips 107p5 CRT */
-   { "PHL", 57364, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
-
-   /* Proview AY765C */
-   { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
-
/* Samsung SyncMaster 205BW.  Note: irony */
{ "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
/* Samsung SyncMaster 22[5-6]BW */
-- 
2.19.2

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

[PATCH 1/2] drm/edid: If no preferred mode is found assume the first mode is preferred

[Ville Syrjala]

From: Ville Syrjälä 

Some monitors apparently forget to mark any mode as preferred in the
EDID. In this particular case we have a very generic looking ID
"PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
doesn't seem particularly wise. Also the quirk we have
(EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd
have to fix it first.

As a generic fallback let's just mark the first probed mode (which
should be the first detailed mode, assuming there are any) as
preferred.

On this particular machine the VBIOS seems to pick the 800x600
60Hz EST mode, which has the opposite sync polarities to the
800x600 60Hz detailed timings. But since it works I guess we
can ignore that slight discrepancy.

Cc: Adam Jackson 
Cc: Roberto Viola 
Tested-by: Roberto Viola 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109780
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5f142530532a..6c6a93647686 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1828,7 +1828,7 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
list_for_each_entry_safe(cur_mode, t, >probed_modes, head) {
cur_mode->type &= ~DRM_MODE_TYPE_PREFERRED;
 
-   if (cur_mode == preferred_mode)
+   if (cur_mode == preferred_mode || target_refresh == 0)
continue;
 
/* Largest mode is preferred */
@@ -1850,6 +1850,18 @@ static void edid_fixup_preferred(struct drm_connector 
*connector,
preferred_mode->type |= DRM_MODE_TYPE_PREFERRED;
 }
 
+static bool preferred_mode_exists(struct drm_connector *connector)
+{
+   struct drm_display_mode *mode;
+
+   list_for_each_entry(mode, >probed_modes, head) {
+   if (mode->type & DRM_MODE_TYPE_PREFERRED)
+   return true;
+   }
+
+   return false;
+}
+
 static bool
 mode_is_rb(const struct drm_display_mode *mode)
 {
@@ -4733,7 +4745,8 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
num_modes += add_inferred_modes(connector, edid);
 
-   if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
+   if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75) 
||
+   !preferred_mode_exists(connector))
edid_fixup_preferred(connector, quirks);
 
if (quirks & EDID_QUIRK_FORCE_6BPC)
-- 
2.19.2

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

Re: [PATCH 3/3] drm/virtio: implement prime export

[Noralf Trønnes]

Den 27.02.2019 15.44, skrev Gerd Hoffmann:
> Just run drm_prime_pages_to_sg() on the ttm pages list to get an
> sg_table for export.  The pages list is created at object initialization
> time, so there should be no need to handle an unpopulated page list.
> Add a sanity check nevertheless.
> 
> Signed-off-by: Gerd Hoffmann 

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

Re: [PATCH 1/3] drm/virtio: implement prime mmap

[Noralf Trønnes]

Den 27.02.2019 15.44, skrev Gerd Hoffmann:
> Sync gem vm_node.start with ttm vm_node.start,
> then we can just call drm_gem_prime_mmap().
> 
> Signed-off-by: Gerd Hoffmann 
> ---

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

Re: [PATCH 2/3] drm/virtio: implement prime pin/unpin

[Noralf Trønnes]

Den 27.02.2019 15.44, skrev Gerd Hoffmann:
> virtio-gpu objects never move around, so effectively they are pinned
> all the time.  This makes the the implementation pretty easy ;)
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/virtio/virtgpu_prime.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
> b/drivers/gpu/drm/virtio/virtgpu_prime.c
> index b4c9199349e7..0fcae0e46abd 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> @@ -30,13 +30,13 @@
>  
>  int virtgpu_gem_prime_pin(struct drm_gem_object *obj)
>  {
> - WARN_ONCE(1, "not implemented");
> - return -ENODEV;
> + /* nothing: all virtio-gpu objects are pinned all the time */
> + return 0;
>  }
>  
>  void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
>  {
> - WARN_ONCE(1, "not implemented");
> + /* nothing */
>  }

You can just remove these dummies the callbacks are optional. See
drm_gem_pin().

With that:

Reviewed-by: Noralf Trønnes 

>  
>  void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/7] drm/tinydrm: Drop using tinydrm_device

[Noralf Trønnes]

Den 27.02.2019 15.27, skrev Gerd Hoffmann:
> On Mon, Feb 25, 2019 at 03:42:30PM +0100, Noralf Trønnes wrote:
>> Use devm_drm_dev_init() and drop using tinydrm_device.
>>
>> v2: devm_drm_dev_register() was dropped so add driver release callbacks.
>>
>> Signed-off-by: Noralf Trønnes 
>> ---
>>  drivers/gpu/drm/tinydrm/hx8357d.c  |  40 +--
>>  drivers/gpu/drm/tinydrm/ili9225.c  |  40 +--
>>  drivers/gpu/drm/tinydrm/ili9341.c  |  40 +--
>>  drivers/gpu/drm/tinydrm/mi0283qt.c |  40 +--
>>  drivers/gpu/drm/tinydrm/mipi-dbi.c |  67 +++---
>>  drivers/gpu/drm/tinydrm/st7586.c   | 105 -
>>  drivers/gpu/drm/tinydrm/st7735r.c  |  40 +--
>>  include/drm/tinydrm/mipi-dbi.h |  26 ---
> 
> Hmm, repaper got its own patch and these are all bundled.
> Slightly confusing, but at the end of the day it doesn't matter much.
> 

They had to since they all use the mipi-dbi helper which had to be
changed. The repaper driver is the only one that didn't use that helper.

thanks,
Noralf.

> Acked-by: Gerd Hoffmann 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework

[Andrew F. Davis]

On 2/26/19 5:40 PM, John Stultz wrote:
> On Tue, Feb 26, 2019 at 11:21 AM John Stultz  wrote:
>>
>> On Tue, Feb 26, 2019 at 6:47 AM Andrew F. Davis  wrote:
>>> On 2/26/19 12:20 AM, John Stultz wrote:
 It boots w/ AOSP, and allocations seem to work, but there's something
 wrong with the dmabuf mmaping which casues the homescreen to crash
 over and over.
 (userland patches updated here:
 https://android-review.googlesource.com/c/device/linaro/hikey/+/909436)

>>>
>>> Interesting, I wonder if the caching stuff is not right here, I'll see
>>> if I can get this working on my side (AOSP on Beagle x15).
>>>
>>
>> Let me know if you figure anything out, I'll also be looking at this today.
>>
> 
> Ok. Figured out the issue. There was a missing:
>   len = PAGE_ALIGN(len)
> assignment that the core used to do before calling the heap alloc op.
> 

Ah, that was my bad then, I dropped that line thinking the heaps should
take care of it, forcing allocation to the page length does make sense
though, we cant pass any less back to userspace.

> Adding that into the heap alloc op got it booting ok w/ AOSP.
> 
> I've updated the patches here:
> kernel: 
> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
> userland: 
> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
> 
> 
>> I also realized some of Benajmin's error path improvements are going
>> to be hard to fix w/ my current code, specifically having the allocate
>> op do the allocation of the dma_heap_buffer (since we don't have a
>> free op, if something fails creating the dmabuf fd in the core, we
>> don't have a hook to release the dma_heap_buffer and heap private
>> data).
> 

We can always add back the free op, the alternative is to have the heap
export the fd.

I'm not sure either is needed though, when we
dma_buf_put(buffer->dmabuf) on the error path it should trigger the
release op, and that can cleanup the allocations in the heap.

> I also realized doing my development and testing against my
> hikey960-mainline-WIP branch, I accidentally folded in an ion hack I
> was using to reduce cache operations, so I'll need to undo that in the
> heap-helpers.c.  But at least we have a rough validation point for the
> design.
> 

Great! The details of the heap-helpers can always get fixed up at a
later point, validation of the core working is really good to hear.

Thanks,
Andrew

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

Re: [PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

[Hans de Goede]

Hi,

On 27-02-19 10:44, Heikki Krogerus wrote:

On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:

Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
drm/kms drivers know about DisplayPort over Type-C hotplug events.

Signed-off-by: Hans de Goede 


I'm OK with this. I'll wait for the v2 and see if I can test these.


The only change I've queued for v2 is adding a "depends on DRM" to
the TYPEC_DP_ALTMODE Kconfig.

And given the discussion about passing lane-info, it might be a while
before we get a v2, so if you want to give this a test run, it is
probably best to just test v1 for now (if you've time).

Note to test this on the GPD win (which you have AFAIK) you will also
need the fusb302 + pi3usb30532 patches I've send out recently, as well as:

https://github.com/jwrdegoede/linux-sunxi/commit/945c6fe0a18957357b42e04ed34bf33667003030

I've one Type-C to VGA dongle (without any other functions) where the Type-C
mode negotiation fails. This one does work on a XPS 15 so I need to borrow
some hardware from a friend so that I can capture the USB-PD signals and
see what the Alpine Ridge controller does different compared to the in kernel
stack and fix this. My other 4 dongles work fine, including this "standard" 
model:
http://media.redgamingtech.com/rgt-website/2015/03/Apple-HDMI-Usb-Type-C-dongle.jpg

Regards,

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

Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

[Hans de Goede]

Hi,

On 27-02-19 12:16, Jani Nikula wrote:

On Wed, 27 Feb 2019, Heikki Krogerus  wrote:

One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915 in this case) does not know is four,
two or one DP lanes in use.


Also, orientation.


The orientation should simply be correct with Type-C over DP. The mux /
orientation-switch used will take care of (physically) swapping the
lanes if the connector is inserted upside-down.


I guess that is not a critical issue since there is a workaround (I
think) where the driver basically does trial and error, but ideally we
should be able to tell i915 also the pin assignment that was
negotiated with the partner device so it knows the DP lane count.


Yeah, if the information is there, we'd like to know.


So far machines actually using a setup where the kernel does the
USB-PD / Type-C negotiation rather then this being handled in firmware
in say the Alpine Ridge controller, are very rare.

AFAIK in the Alpine Ridge controller case, there is no communication
with the i915 driver, the only thing the Alpine Ridge controller does
which the everything done in the kernel approach does not, is that
it actually has a pin connected to the HDP pin of the displayport in
question.  But that just lets the i915 driver know about hotplug-events,
not how many lanes are used.

Currently I'm aware of only 2 x86 models which actually need the
hotplug event propagation from the Type-C subsystem to the i915 driver.
Do we really want to come up with a much more complex solution to
optimize for this corner case, while the much more common case
(Alpine Ridge controller) does not provide this info to the i915 driver?

To give some idea of the complexity, first of all we need some
mechanism to let the kernel know which drm_connector is connected
to which Type-C port. For the 2 models I know if which need this, this
info is not available and we would need to hardcode it in the kernel
based on e.g. DMI matching.

Then once we have this link, we need to start thinking about probe
ordering. Likely we need the typec framework to find the drm_connector,
since the typec-partner device is only created when there actually is
a DP capable "dongle" connected, making doing it the other way around
tricky. Then the typec-partner device needs to get a reference or some
such to make sure the drm_connector does not fgo away during the lifetime
of the typec-partner device.

I would really like to avoid this, so if we want to send more info to
the i915 driver, I suggest we create some event struct for this which
gets passed to the notifier, this could include a string to
describe the DP connector which the Type-C connector is connected to
when the mux is set to DP mode, e.g. "i915/DP-1" should be unique
or probably better, use the PCI device name, so: ":00:02.0/DP-1"

Then we still have a loose coupling avoiding lifetime issues, while
the receiving drm driver can check which connector the event is for
and we can then also include other info such as lane-count and orientation
in the event struct.


With the orientation


As said, the orientation *should* be corrected by the mux switch,
it is corrected by the mux switch on the hardware I know about and
actually getting it wrong breaks the display output (we had a bug there),
so I guess that getting it wrong leads to the lines being swizzled in a way
which the i915 driver does not check for ...

Regards,

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

Re: AFBC versions modifiers

[Ayan Halder]

Hi Neil,

AFBC 1.0 does not support (ignoring common prefix AFBC_FORMAT_MOD_) 
BLOCK_SIZE_32x8, BLOCK_SIZE_64x4, BLOCK_SIZE_32x8_64x4
CBR, TILED, SC, DB and BCH  modifiers.

AFBC 1.2 does not support BLOCK_SIZE_64x4, BLOCK_SIZE_32x8_64x4, DB and BCH 
modifiers.

Beyond that it's very hard to say. The AFBC version numbers refer to versions 
of the specification, but aren't very useful for describing the actual 
bitstream format.
To determine which modifiers _are_ supported, you will really need to get 
technical documentation from the SoC vendor

Regards,
Ayan Kumar Halder


From: Neil Armstrong 
Sent: Tuesday, February 26, 2019 2:15 PM
To: Ayan Halder; Liviu Dudau
Cc: DRI Development
Subject: AFBC versions modifiers

Hi Ayan,

Could you help distinguish which are the AFBC modifiers for each version of 
AFBC ?

The Amlogic SoCs embeds an AFBC 1.0 compatible decoder, then the newer SoCs 
embeds an AFBC 1.2 decoder,
I assume the modifiers before the patch "drm/fourcc: Add modifier defininitions 
for AFBC 1.3" are
valid for AFBC 1.2, but what is the subset for 1.0 and 1.1 ?

Thanks,
Neil

--
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux
www.baylibre.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher  ---
(In reply to Daniel P. Berrange from comment #4)
> 
> I'm curious what motivated this change to start with ?  Even if QEMU was not
> enforcing seccomp filters, I think I'd consider it a bug for mesa to be
> setting its process affinity in this way.  The mgmt application or sysadmin
> has decided that the process must have a certain affinity, based on how
> it/they want the host CPUs utilized. Why is mesa wanting to override this
> administrative policy decision to restrict CPU usage ?

To improve performance on modern multi-core NUMA architectures.

-- 
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 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

[Heikki Krogerus]

On Wed, Feb 27, 2019 at 01:16:27PM +0200, Jani Nikula wrote:
> On Wed, 27 Feb 2019, Heikki Krogerus  wrote:
> > One thing that this series does not consider is the DP lane count
> > problem. The GPU drivers (i915 in this case) does not know is four,
> > two or one DP lanes in use.
> 
> Also, orientation.
> 
> > I guess that is not a critical issue since there is a workaround (I
> > think) where the driver basically does trial and error, but ideally we
> > should be able to tell i915 also the pin assignment that was
> > negotiated with the partner device so it knows the DP lane count.
> 
> Yeah, if the information is there, we'd like to know. With the
> orientation, there's a worst case of sixth attempt of finding out
> there's just one lane in a certain orientation. Couple that with link
> rate selection (did it not work because too high link rate or because
> the lanes are just not there?) we get pretty confused about what we
> should try.

The orientation is also considered in the alt mode API. We have a
function for that typec_altmode_get_orientation(), but it of course
requires that the caller has a handle to the alt mode object. So
basically we would again need tight coupling between the DP connector
and USB Type-C connector.

Hans, I'm not so sure we should, or can, rule out the "tight coupling"
option after all.


thanks,

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

Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

[Heikki Krogerus]

Hi Hans,

On Mon, Feb 25, 2019 at 02:20:34PM +0100, Hans de Goede wrote:
> Hi All,
> 
> On some Cherry Trail devices, DisplayPort over Type-C is supported through
> a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
> datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
> case does the PD/alt-mode negotiation itself, rather then everything being
> handled in firmware.
> 
> So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch
> to DP mode and sets the mux accordingly. In this setup the HPD pin is not
> connected, so the i915 driver needs to respond to a software event and scan
> the DP port for changes manually.
> 
> Thanks to Heikki's great work on the DisplayPort altmode support in the
> typec subsys, we now correctly tell the dongle to switch to DP altmode
> and we correctly set the mux and orientation switches to connect the
> DP lines to the Type-C connector.
> 
> This just leaves sending an out-of-band hotplug event from the Type-C
> subsystem to the i915 driver and then we've fully working DP over Type-C
> on these devices.
> 
> This series implements this. The first patch adds a generic mechanism
> for oob hotplug events to be send to the drm subsys, the second patch
> adds support for this mechanism to the i915 driver and the third patch
> makes the typec displayport_altmode driver send these events.
> 
> The commit message of the first patch explains why I've chosen to things
> the way these patches do them.

One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915 in this case) does not know is four,
two or one DP lanes in use.

I guess that is not a critical issue since there is a workaround (I
think) where the driver basically does trial and error, but ideally we
should be able to tell i915 also the pin assignment that was
negotiated with the partner device so it knows the DP lane count.

My original idea was that we pass that struct typec_displayport_data
as payload in the event. From the Configuration VDO the GPU drivers
can then see the negotiated DP pin assignment and determine the lane
count.


thanks,

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

Re: [PATCH 3/3] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

[Heikki Krogerus]

On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:
> Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
> drm/kms drivers know about DisplayPort over Type-C hotplug events.
> 
> Signed-off-by: Hans de Goede 

I'm OK with this. I'll wait for the v2 and see if I can test these.

thanks,

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

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

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

--- Comment #4 from Daniel P. Berrange  ---
(In reply to Ahzo from comment #0)
> The problematic code at src/util/u_queue.c:252 was added in the following
> commit:
> commit d877451b48a59ab0f9a4210fc736f51da5851c9a
> Author: Marek Olšák 
> Date:   Mon Oct 1 15:51:06 2018 -0400
> 
> util/u_queue: add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY
> 
> Initial version discussed with Rob Clark under a different patch name.
> This approach leaves his driver unaffected.
> 
> 
> Since setting the thread affinity seems non-essential here, the failing
> syscall should be handled gracefully, for example by setting a signal
> handler to ignore the SIGSYS signal.

I'm curious what motivated this change to start with ?  Even if QEMU was not
enforcing seccomp filters, I think I'd consider it a bug for mesa to be setting
its process affinity in this way.  The mgmt application or sysadmin has decided
that the process must have a certain affinity, based on how it/they want the
host CPUs utilized. Why is mesa wanting to override this administrative policy
decision to restrict CPU usage ?

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

[PATCH 2/3] drm/virtio: implement prime pin/unpin

[Gerd Hoffmann]

virtio-gpu objects never move around, so effectively they are pinned
all the time.  This makes the the implementation pretty easy ;)

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_prime.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index b4c9199349e7..0fcae0e46abd 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -30,13 +30,13 @@
 
 int virtgpu_gem_prime_pin(struct drm_gem_object *obj)
 {
-   WARN_ONCE(1, "not implemented");
-   return -ENODEV;
+   /* nothing: all virtio-gpu objects are pinned all the time */
+   return 0;
 }
 
 void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
 {
-   WARN_ONCE(1, "not implemented");
+   /* nothing */
 }
 
 void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj)
-- 
2.9.3

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

[PATCH 3/3] drm/virtio: implement prime export

[Gerd Hoffmann]

Just run drm_prime_pages_to_sg() on the ttm pages list to get an
sg_table for export.  The pages list is created at object initialization
time, so there should be no need to handle an unpopulated page list.
Add a sanity check nevertheless.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  1 +
 drivers/gpu/drm/virtio/virtgpu_drv.c   |  2 ++
 drivers/gpu/drm/virtio/virtgpu_prime.c | 12 
 3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 3238fdf58eb4..fb1095fa873f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -354,6 +354,7 @@ int virtio_gpu_object_wait(struct virtio_gpu_object *bo, 
bool no_wait);
 /* virtgpu_prime.c */
 int virtgpu_gem_prime_pin(struct drm_gem_object *obj);
 void virtgpu_gem_prime_unpin(struct drm_gem_object *obj);
+struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
 void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj);
 void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index b996ac1d4fcc..4f4f578752fa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -205,10 +205,12 @@ static struct drm_driver driver = {
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = virtio_gpu_debugfs_init,
 #endif
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = virtgpu_gem_prime_pin,
.gem_prime_unpin = virtgpu_gem_prime_unpin,
+   .gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
.gem_prime_vmap = virtgpu_gem_prime_vmap,
.gem_prime_vunmap = virtgpu_gem_prime_vunmap,
.gem_prime_mmap = virtgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 0fcae0e46abd..1fe593e391b5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -39,6 +39,18 @@ void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
/* nothing */
 }
 
+struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
+{
+   struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
+
+   if (!bo->tbo.ttm->pages || !bo->tbo.ttm->num_pages)
+   /* should not happen */
+   return ERR_PTR(-EINVAL);
+
+   return drm_prime_pages_to_sg(bo->tbo.ttm->pages,
+bo->tbo.ttm->num_pages);
+}
+
 void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj)
 {
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
-- 
2.9.3

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

[PATCH 0/3] drm/virtio: improve prime support.

[Gerd Hoffmann]

Gerd Hoffmann (3):
  drm/virtio: implement prime mmap
  drm/virtio: implement prime pin/unpin
  drm/virtio: implement prime export

 drivers/gpu/drm/virtio/virtgpu_drv.h   |  1 +
 drivers/gpu/drm/virtio/virtgpu_drv.c   |  2 ++
 drivers/gpu/drm/virtio/virtgpu_prime.c | 25 -
 3 files changed, 23 insertions(+), 5 deletions(-)

-- 
2.9.3

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

[PATCH 1/3] drm/virtio: implement prime mmap

[Gerd Hoffmann]

Sync gem vm_node.start with ttm vm_node.start,
then we can just call drm_gem_prime_mmap().

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_prime.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index c59ec34c80a5..b4c9199349e7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -56,7 +56,10 @@ void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, 
void *vaddr)
 }
 
 int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
-  struct vm_area_struct *area)
+  struct vm_area_struct *vma)
 {
-   return -ENODEV;
+   struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
+
+   bo->gem_base.vma_node.vm_node.start = bo->tbo.vma_node.vm_node.start;
+   return drm_gem_prime_mmap(obj, vma);
 }
-- 
2.9.3

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

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

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

--- Comment #3 from Daniel P. Berrange  ---
(In reply to Ahzo from comment #2)
> To check for the availability of the syscall, one can try it in a child
> process and see if the child is terminated by a signal, e.g. like this:

Afraid not, QEMU's seccomp filter blocks use of fork() too :-)

-- 
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: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

[Joonas Lahtinen]

Quoting Christian König (2019-02-27 04:17:01)
> Am 27.02.19 um 00:04 schrieb Dave Airlie:
> >>> At the end of the day, I don't really care that much.  I get it, we
> >>> all have large projects with scarce resources.  I just think a few
> >>> years down the road we'll all regret it as a community.
> >> AMD and others have also spent years tuning TTM for both UMA and VRAM,
> >> but especially VRAM.  It comes across a bit daft to complain about the
> >> effort to move to TTM, but say nothing about the effort to tune GEM
> >> for optimal VRAM performance.  Effort that has already been expended
> >> that you could take advantage of.
> > I'm with Alex here, the patches you have now are just the start, I
> > realise you think they are all you'll need, but I expect once Chris
> > gets going with real VRAM hardware he'll generate reams for stuff.
> >
> > People have been tuning and making TTM run on VRAM using GPUs for
> > longer than you've been making VRAM using GPUs, there had better be
> > good and well thought out reasons for avoiding using it, and so far
> > you haven't made that argument to me all. In fact your scheduler
> > arguments works against you. If we should have abstracted i915
> > scheduler out and used it because it had more features and
> > pre-existed, then i915 should be using TTM since it's already
> > abstracted out and has more features.
> >
> > Like we've pulled other stuff out of TTM like reservation objects, I
> > don't think i915 uses those yet either when it clearly could be. Maybe
> > if we started by fixing that, moving to TTM would be less of a
> > problem.
> 
> Just to make it extra clear: At least I absolutely won't mind if we 
> decommission TTM further!
> 
> We have optimized TTM as much as we could without a fundamental design 
> change, but essentially there are a couple of problem we can't fix 
> without touching all drivers at once.
> 
> For example the layered design where TTM calls back into the driver to 
> move stuff around or allocate something from a domain really needs to go 
> away.
> 
> So my suggestion is that we filleting TTM into multiple independent 
> components which a) can be used to implement the existing TTM interface 
> and b) implement a clean and encapsulated functionality.
> 
> Those components can then be used by drivers independently of TTM to 
> implement the necessary MM.

This is exactly what I was hoping we could do, too. So I'm glad to hear
this suggestion. 

Incrementally extracting and sharing the components would lead to less
disruptions than halting the progress while doing a major rewrite of
the driver.

As I mentioned in IRC, one good step for both the scheduler and memory
management would be to actually map out the feature sets. It is clear
that we have confusion about what the feature set of the respective
components are (at least I do seem to have about TTM / DRM scheduler).

Then when we understand what it is that we actually have, it should be
easier to start discussing which are the components that could be reused.

I think one good way to take on this would be to look into sharing as
much of the test assets as possible. We have plenty of testcases
excercising the low-on-memory conditions and scheduling corner cases
that we've had to tackle. And I'm sure there are tests for the above
mentioned TTM VRAM tuning, too.

I'll look into and discuss the reservation objects Dave mentioned, and
I'm happy to hear about other suggestions.

I'd also like to hear comments about the buddy allocator suggestion. It
should help in enabling >4K page support for pretty much any driver.

Regards, Joonas

> Regards,
> Christian.
> 
> >
> > Anyways, I expect moving to TTM is a big change for i915, and probably
> > more than you are able to bite off at present, but I'm going to be
> > watching closely what stuff you add on top of this sort of thing, and
> > if it starts getting large and messier as you tune it, I'll have to
> > start reconsidering how big a NO I have to use.
> >
> > Dave.
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 7/7] drm/tinydrm: Use drm_dev_enter/exit()

[Gerd Hoffmann]

On Mon, Feb 25, 2019 at 03:42:32PM +0100, Noralf Trønnes wrote:
> This protects device resources from use after device removal.
> 
> There are 3 ways for driver-device unbinding to happen:
> - The driver module is unloaded causing the driver to be unregistered.
>   This can't happen as long as there are open file handles because a
>   reference is taken on the module.
> - The device is removed (Device Tree overlay unloading).
>   This can happen at any time.
> - The driver sysfs unbind file can be used to unbind the driver from the
>   device. This can happen any time.
> 
> v2: Since drm_atomic_helper_shutdown() has to be called after
> drm_dev_unplug() we don't want do block ->disable after unplug.
> 
> Signed-off-by: Noralf Trønnes 

Acked-by: Gerd Hoffmann 

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

Re: [PATCH v3 5/7] drm/tinydrm: Drop using tinydrm_device

[Gerd Hoffmann]

On Mon, Feb 25, 2019 at 03:42:30PM +0100, Noralf Trønnes wrote:
> Use devm_drm_dev_init() and drop using tinydrm_device.
> 
> v2: devm_drm_dev_register() was dropped so add driver release callbacks.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/tinydrm/hx8357d.c  |  40 +--
>  drivers/gpu/drm/tinydrm/ili9225.c  |  40 +--
>  drivers/gpu/drm/tinydrm/ili9341.c  |  40 +--
>  drivers/gpu/drm/tinydrm/mi0283qt.c |  40 +--
>  drivers/gpu/drm/tinydrm/mipi-dbi.c |  67 +++---
>  drivers/gpu/drm/tinydrm/st7586.c   | 105 -
>  drivers/gpu/drm/tinydrm/st7735r.c  |  40 +--
>  include/drm/tinydrm/mipi-dbi.h |  26 ---

Hmm, repaper got its own patch and these are all bundled.
Slightly confusing, but at the end of the day it doesn't matter much.

Acked-by: Gerd Hoffmann 

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

Re: [PATCH v3 3/7] drm/drv: DOC: Add driver example code

[Gerd Hoffmann]

On Mon, Feb 25, 2019 at 03:42:28PM +0100, Noralf Trønnes wrote:
> Add driver example that shows how devm_drm_dev_init() can be used.
> 
> v2: Expand docs (Sam, Daniel)

Acked-by: Gerd Hoffmann 

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

Re: [PATCH v3 2/7] drm: Add devm_drm_dev_init()

[Gerd Hoffmann]

On Mon, Feb 25, 2019 at 03:42:27PM +0100, Noralf Trønnes wrote:
> This adds a resource managed (devres) version of drm_dev_init().
> 
> v2: Remove devm_drm_dev_register() since we can't touch hw in devm
> release functions and drivers want to disable hw on driver module
> unload (Daniel Vetter, Greg KH)

Acked-by: Gerd Hoffmann 

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

Re: [PATCH RFC 1/1] uio: Add dma-buf import ioctls

[Daniel Vetter]

On Tue, Feb 26, 2019 at 11:20 PM Hyun Kwon  wrote:
>
> Hi Daniel,
>
> Thanks for the comment.
>
> On Tue, 2019-02-26 at 04:06:13 -0800, Daniel Vetter wrote:
> > On Tue, Feb 26, 2019 at 12:53 PM Greg Kroah-Hartman
> >  wrote:
> > >
> > > On Sat, Feb 23, 2019 at 12:28:17PM -0800, Hyun Kwon wrote:
> > > > Add the dmabuf map / unmap interfaces. This allows the user driver
> > > > to be able to import the external dmabuf and use it from user space.
> > > >
> > > > Signed-off-by: Hyun Kwon 
> > > > ---
> > > >  drivers/uio/Makefile |   2 +-
> > > >  drivers/uio/uio.c|  43 +
> > > >  drivers/uio/uio_dmabuf.c | 210 
> > > > +++
> > > >  drivers/uio/uio_dmabuf.h |  26 ++
> > > >  include/uapi/linux/uio/uio.h |  33 +++
> > > >  5 files changed, 313 insertions(+), 1 deletion(-)
> > > >  create mode 100644 drivers/uio/uio_dmabuf.c
> > > >  create mode 100644 drivers/uio/uio_dmabuf.h
> > > >  create mode 100644 include/uapi/linux/uio/uio.h
> > > >
> > > > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > > > index c285dd2..5da16c7 100644
> > > > --- a/drivers/uio/Makefile
> > > > +++ b/drivers/uio/Makefile
> > > > @@ -1,5 +1,5 @@
> > > >  # SPDX-License-Identifier: GPL-2.0
> > > > -obj-$(CONFIG_UIO)+= uio.o
> > > > +obj-$(CONFIG_UIO)+= uio.o uio_dmabuf.o
> > > >  obj-$(CONFIG_UIO_CIF)+= uio_cif.o
> > > >  obj-$(CONFIG_UIO_PDRV_GENIRQ)+= uio_pdrv_genirq.o
> > > >  obj-$(CONFIG_UIO_DMEM_GENIRQ)+= uio_dmem_genirq.o
> > > > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > > > index 1313422..6841f98 100644
> > > > --- a/drivers/uio/uio.c
> > > > +++ b/drivers/uio/uio.c
> > > > @@ -24,6 +24,12 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#include 
> > > > +
> > > > +#include "uio_dmabuf.h"
> > > >
> > > >  #define UIO_MAX_DEVICES  (1U << MINORBITS)
> > > >
> > > > @@ -454,6 +460,8 @@ static irqreturn_t uio_interrupt(int irq, void 
> > > > *dev_id)
> > > >  struct uio_listener {
> > > >   struct uio_device *dev;
> > > >   s32 event_count;
> > > > + struct list_head dbufs;
> > > > + struct mutex dbufs_lock; /* protect @dbufs */
> > > >  };
> > > >
> > > >  static int uio_open(struct inode *inode, struct file *filep)
> > > > @@ -500,6 +508,9 @@ static int uio_open(struct inode *inode, struct 
> > > > file *filep)
> > > >   if (ret)
> > > >   goto err_infoopen;
> > > >
> > > > + INIT_LIST_HEAD(>dbufs);
> > > > + mutex_init(>dbufs_lock);
> > > > +
> > > >   return 0;
> > > >
> > > >  err_infoopen:
> > > > @@ -529,6 +540,10 @@ static int uio_release(struct inode *inode, struct 
> > > > file *filep)
> > > >   struct uio_listener *listener = filep->private_data;
> > > >   struct uio_device *idev = listener->dev;
> > > >
> > > > + ret = uio_dmabuf_cleanup(idev, >dbufs, 
> > > > >dbufs_lock);
> > > > + if (ret)
> > > > + dev_err(>dev, "failed to clean up the dma bufs\n");
> > > > +
> > > >   mutex_lock(>info_lock);
> > > >   if (idev->info && idev->info->release)
> > > >   ret = idev->info->release(idev->info, inode);
> > > > @@ -652,6 +667,33 @@ static ssize_t uio_write(struct file *filep, const 
> > > > char __user *buf,
> > > >   return retval ? retval : sizeof(s32);
> > > >  }
> > > >
> > > > +static long uio_ioctl(struct file *filep, unsigned int cmd, unsigned 
> > > > long arg)
> > >
> > > We have resisted adding a uio ioctl for a long time, can't you do this
> > > through sysfs somehow?
> > >
> > > A meta-comment about your ioctl structure:
> > >
> > > > +#define UIO_DMABUF_DIR_BIDIR 1
> > > > +#define UIO_DMABUF_DIR_TO_DEV2
> > > > +#define UIO_DMABUF_DIR_FROM_DEV  3
> > > > +#define UIO_DMABUF_DIR_NONE  4
> > >
> > > enumerated type?
> > >
> > > > +
> > > > +struct uio_dmabuf_args {
> > > > + __s32   dbuf_fd;
> > > > + __u64   dma_addr;
> > > > + __u64   size;
> > > > + __u32   dir;
> > >
> > > Why the odd alignment?  Are you sure this is the best packing for such a
> > > structure?
> > >
> > > Why is dbuf_fd __s32?  dir can be __u8, right?
> > >
> > > I don't know that dma layer very well, it would be good to get some
> > > review from others to see if this really is even a viable thing to do.
> > > The fd handling seems a bit "odd" here, but maybe I just do not
> > > understand it.
> >
> > Frankly looks like a ploy to sidestep review by graphics folks. We'd
> > ask for the userspace first :-)
>
> Please refer to pull request [1].
>
> For any interest in more details, the libmetal is the abstraction layer
> which provides platform independent APIs. The backend implementation
> can be selected per different platforms: ex, rtos, linux,
> standalone (xilinx),,,. For Linux, it supports UIO / vfio as of now.
> The actual user space drivers sit on top of libmetal. Such drivers can be
> found in 

Re: [PATCH v3 1/7] drm/drv: Hold ref on parent device during drm_device lifetime

[Gerd Hoffmann]

On Mon, Feb 25, 2019 at 03:42:26PM +0100, Noralf Trønnes wrote:
> This makes it safe to access drm_device->dev after the parent device has
> been removed/unplugged.
> 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Gerd Hoffmann 

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

Re: [PATCH] Revert "dma-contiguous: do not allocate a single page from CMA area"

[Jon Hunter]

On 26/02/2019 20:23, Nicolin Chen wrote:
> This reverts commit d222e42e88168fd67e6d131984b86477af1fc256.
> 
> The original change breaks omap dss:
> omapdss_dispc 58001000.dispc:
> dispc_errata_i734_wa_init: dma_alloc_writecombine failed
> 
> Let's revert it first and then find a safer solution instead.
> 
> Reported-by: Tony Lindgren 
> Signed-off-by: Nicolin Chen 
> ---
> Tony,
>   
> Would you please test and verify? Thanks!

This also fixes various memory allocation failures we have seen on
32-bit Tegra as well.

Tested-by: Jon Hunter 

Cheers
Jon

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

Re: [PATCH] drm/vgem: fix use-after-free when drm_gem_handle_create() fails

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 5ba6c9ff961a drm/vgem: Fix mmaping.

The bot has tested the following trees: v4.20.12, v4.19.25, v4.14.103, v4.9.160.

v4.20.12: Build OK!
v4.19.25: Build OK!
v4.14.103: Build OK!
v4.9.160: Failed to apply! Possible dependencies:
024b6a63138c ("gpu: drm: gma500: Use vma_pages()")
1a29d85eb0f1 ("mm: use vmf->address instead of of vmf->virtual_address")
82b0f8c39a38 ("mm: join struct fault_env and vm_fault")
953c66c2b22a ("mm: THP page cache support for ppc64")
af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
c54fd47aa5b8 ("drm/vgem: switch to drm_*_get(), drm_*_put() helpers")
fd60775aea80 ("mm, thp: avoid unlikely branches for split_huge_pmd")


How should we proceed with this patch?

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

[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)

[bugzilla-daemon]

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

--- Comment #27 from John Doe (anode@gmail.com) ---
My RX550 is successfully booted up with 4.20 kernels and newer, but my OS
freezes every minute for 30 secs if I open youtube or play game, and anything
doesn't work upon freeze - I couldn't move mouse or press REISUB. Entire system
is stuck. I downgraded kernel to 4.14 - and it works like a charm without
lags/freezes/stucks. And it seems 4.14 doesn't have AMD DC (amdgpu.dc=0 doesn't
work for me)

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

Re: [PATCH v5 14/19] drm: writeback: Add job prepare and cleanup operations

[Laurent Pinchart]

Hi Liviu,

On Tue, Feb 26, 2019 at 06:39:40PM +, Liviu Dudau wrote:
> On Thu, Feb 21, 2019 at 12:32:07PM +0200, Laurent Pinchart wrote:
> > As writeback jobs contain a framebuffer, drivers may need to prepare and
> > cleanup them the same way they can prepare and cleanup framebuffers for
> > planes. Add two new optional connector helper operations,
> > .prepare_writeback_job() and .cleanup_writeback_job() to support this.
> 
> I'm having a bit of a hard time parsing the above paragraph. I think that
> what you are saying is that you need to prepare and cleanup the framebuffers 
> that
> writeback jobs have, but it also can be read that you need to prepare/cleanup
> the actual jobs. If the latter, then I'm curious to know what is special
> about the jobs that you need preparing/cleaning up.

I meant the framebuffers, but I wouldn't be surprised if the jobs were
later extended with more fields that would require similar preparation.
That's why I think prepare/cleanup job operations make sense.

> > The job prepare operation is called from
> > drm_atomic_helper_prepare_planes() to avoid a new atomic commit helper
> > that would need to be called by all drivers not using
> > drm_atomic_helper_commit(). The job cleanup operation is called from the
> > existing drm_writeback_cleanup_job() function, invoked both when
> > destroying the job as part of a aborted commit, or when the job
> > completes.
> > 
> > The drm_writeback_job structure is extended with a priv field to let
> > drivers store per-job data, such as mappings related to the writeback
> > framebuffer.
> 
> Could the driver store in this priv field a structure that contains the
> connector, whereby removing the need for a back-pointer?

The priv field points to an opaque structure, forcing drivers to use a
standard structure there would make the API more complex in my opinion,
without any added value I can see.

> > For internal plumbing reasons the drm_writeback_job structure needs to
> > store a back-pointer to the drm_writeback_connector. To avoid pushing
> > too much writeback-specific knowledge to drm_atomic_uapi.c, create a
> > drm_writeback_set_fb() function, move the writeback job setup code
> > there, and set the connector backpointer. The prepare_signaling()
> > function doesn't need to allocate writeback jobs and can ignore
> > connectors without a job, as it is called after the writeback jobs are
> > allocated to store framebuffers, and a writeback fence with a
> > framebuffer is an invalid configuration that gets rejected by the commit
> > check.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  | 11 ++
> >  drivers/gpu/drm/drm_atomic_uapi.c| 31 +
> >  drivers/gpu/drm/drm_writeback.c  | 43 
> >  include/drm/drm_modeset_helper_vtables.h |  7 
> >  include/drm/drm_writeback.h  | 28 ++-
> >  5 files changed, 96 insertions(+), 24 deletions(-)
> > 
> > This patch is currently missing documentation for the
> > .prepare_writeback_job() and .cleanup_writeback_job() operations. I plan
> > to fix this, but first wanted feedback on the direction taken. I'm not
> > entirely happy with the priv pointer in the drm_writeback_job structure,
> > but adding a full state duplicate/destroy machinery for that structure
> > was equally unappealing to me.
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 6fe2303fccd9..70a4886c6e65 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2245,10 +2245,21 @@ 
> > EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
> >  int drm_atomic_helper_prepare_planes(struct drm_device *dev,
> >  struct drm_atomic_state *state)
> >  {
> > +   struct drm_connector *connector;
> > +   struct drm_connector_state *new_conn_state;
> > struct drm_plane *plane;
> > struct drm_plane_state *new_plane_state;
> > int ret, i, j;
> >  
> > +   for_each_new_connector_in_state(state, connector, new_conn_state, i) {
> > +   if (!new_conn_state->writeback_job)
> > +   continue;
> > +
> > +   ret = drm_writeback_prepare_job(new_conn_state->writeback_job);
> > +   if (ret < 0)
> > +   return ret;
> > +   }
> > +
> > for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> > const struct drm_plane_helper_funcs *funcs;
> >  
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index c40889888a16..e802152a01ad 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -647,28 +647,15 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > return 0;
> >  }
> >  
> > -static struct drm_writeback_job *
> > -drm_atomic_get_writeback_job(struct drm_connector_state *conn_state)
> > -{
> > 

Re: [PATCH] drm/bridge: ti-sn65dsi86: make const array static

[Andrzej Hajda]

On 26.02.2019 17:59, Colin King wrote:
> From: Colin Ian King 
>
> Don't populate the const array ti_sn_bridge_supply_names on the
> stack but instead make it static.
>
> Signed-off-by: Colin Ian King 
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index f72ee137e5f1..4c2ca4e39be5 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -211,7 +211,7 @@ static struct ti_sn_bridge *bridge_to_ti_sn_bridge(struct 
> drm_bridge *bridge)
>  static int ti_sn_bridge_parse_regulators(struct ti_sn_bridge *pdata)
>  {
>   unsigned int i;
> - const char * const ti_sn_bridge_supply_names[] = {
> + static const char * const ti_sn_bridge_supply_names[] = {
>   "vcca", "vcc", "vccio", "vpll",
>   };
>  


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

Re: [Intel-gfx] [RFC PATCH 00/42] Introduce memory region concept (including device local memory)

[Christian König]

Am 27.02.19 um 00:04 schrieb Dave Airlie:

At the end of the day, I don't really care that much.  I get it, we
all have large projects with scarce resources.  I just think a few
years down the road we'll all regret it as a community.

AMD and others have also spent years tuning TTM for both UMA and VRAM,
but especially VRAM.  It comes across a bit daft to complain about the
effort to move to TTM, but say nothing about the effort to tune GEM
for optimal VRAM performance.  Effort that has already been expended
that you could take advantage of.

I'm with Alex here, the patches you have now are just the start, I
realise you think they are all you'll need, but I expect once Chris
gets going with real VRAM hardware he'll generate reams for stuff.

People have been tuning and making TTM run on VRAM using GPUs for
longer than you've been making VRAM using GPUs, there had better be
good and well thought out reasons for avoiding using it, and so far
you haven't made that argument to me all. In fact your scheduler
arguments works against you. If we should have abstracted i915
scheduler out and used it because it had more features and
pre-existed, then i915 should be using TTM since it's already
abstracted out and has more features.

Like we've pulled other stuff out of TTM like reservation objects, I
don't think i915 uses those yet either when it clearly could be. Maybe
if we started by fixing that, moving to TTM would be less of a
problem.


Just to make it extra clear: At least I absolutely won't mind if we 
decommission TTM further!


We have optimized TTM as much as we could without a fundamental design 
change, but essentially there are a couple of problem we can't fix 
without touching all drivers at once.


For example the layered design where TTM calls back into the driver to 
move stuff around or allocate something from a domain really needs to go 
away.


So my suggestion is that we filleting TTM into multiple independent 
components which a) can be used to implement the existing TTM interface 
and b) implement a clean and encapsulated functionality.


Those components can then be used by drivers independently of TTM to 
implement the necessary MM.


Regards,
Christian.



Anyways, I expect moving to TTM is a big change for i915, and probably
more than you are able to bite off at present, but I'm going to be
watching closely what stuff you add on top of this sort of thing, and
if it starts getting large and messier as you tune it, I'll have to
start reconsidering how big a NO I have to use.

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


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

Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers

[Jani Nikula]

On Wed, 27 Feb 2019, Heikki Krogerus  wrote:
> One thing that this series does not consider is the DP lane count
> problem. The GPU drivers (i915 in this case) does not know is four,
> two or one DP lanes in use.

Also, orientation.

> I guess that is not a critical issue since there is a workaround (I
> think) where the driver basically does trial and error, but ideally we
> should be able to tell i915 also the pin assignment that was
> negotiated with the partner device so it knows the DP lane count.

Yeah, if the information is there, we'd like to know. With the
orientation, there's a worst case of sixth attempt of finding out
there's just one lane in a certain orientation. Couple that with link
rate selection (did it not work because too high link rate or because
the lanes are just not there?) we get pretty confused about what we
should try.

BR,
Jani.


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

Re: [PATCH 0/5] tda998x updates

[Russell King - ARM Linux admin]

On Fri, Jan 25, 2019 at 09:40:38AM +, Russell King - ARM Linux admin wrote:
> Hi,
> 
> This series adds support for programming the SPD and vendor infoframes.
> 
> It also adds support for pixel repeated modes - we were not rejecting
> these modes, but we also didn't have the implementation to support
> them.  As their implementation is simple, add it rather than rejecting
> the modes.
> 
> Support is also added for the bridge timing information, that upstream
> components may wish to use to adjust their output appropriately.
> 
> Lastly, rather than merely passing through the full-range RGB from the
> CRTC, adapt the RGB range to the capabilities of the display and the
> default range for the mode.  This means that if the display does not
> support the Q bit in the video infoframe, and the mode is defined to
> have limited range RGB, we will compress the output RGB range to
> limited range.
> 
> Tested on 4.20 with a Panasonic TV.
> 
>   drm/i2c: tda998x: add support for pixel repeated modes
>   drm/i2c: tda998x: add bridge timing information
>   drm/i2c: tda998x: add support for writing SPD
>   drm/i2c: tda998x: add vendor specific infoframe support
>   drm/i2c: tda998x: improve correctness of quantisation range
> 
>  drivers/gpu/drm/i2c/tda998x_drv.c | 120 
> +-
>  1 file changed, 105 insertions(+), 15 deletions(-)

Hi,

From what I can tell, patches 1 and 2 have not received any comments.
Should I assume that these are fine to go to David?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Wake up next in drm_read() chain if we are forced to putback the event

[Chris Wilson]

Quoting Daniel Vetter (2017-08-07 10:28:58)
> On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> > After an event is sent, we try to copy it into the user buffer of the
> > first waiter in drm_read() and if the user buffer doesn't have enough
> > room we put it back onto the list. However, we didn't wake up any
> > subsequent waiter, so that event may sit on the list until either a new
> > vblank event is sent or a new waiter appears. Rare, but in the worst
> > case may lead to a stuck process.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Daniel Vetter 
> 
> New subtestcase in igt@drm_read?

Caught it!
Testcase: igt/drm_read/short-buffer-wakeup
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Maarten Lankhorst]

Op 26-02-2019 om 17:17 schreef Matt Roper:
> On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 21-02-2019 om 01:28 schreef Matt Roper:
>>> Some display controllers can be programmed to present non-black colors
>>> for pixels not covered by any plane (or pixels covered by the
>>> transparent regions of higher planes).  Compositors that want a UI with
>>> a solid color background can potentially save memory bandwidth by
>>> setting the CRTC background property and using smaller planes to display
>>> the rest of the content.
>>>
>>> To avoid confusion between different ways of encoding RGB data, we
>>> define a standard 64-bit format that should be used for this property's
>>> value.  Helper functions and macros are provided to generate and dissect
>>> values in this standard format with varying component precision values.
>>>
>>> v2:
>>>  - Swap internal representation's blue and red bits to make it easier
>>>to read if printed out.  (Ville)
>>>  - Document bgcolor property in drm_blend.c.  (Sean Paul)
>>>  - s/background_color/bgcolor/ for consistency between property name and
>>>value storage field.  (Sean Paul)
>>>  - Add a convenience function to attach property to a given crtc.
>>>
>>> v3:
>>>  - Restructure ARGB component extraction macros to be easier to
>>>understand and enclose the parameters in () to avoid calculations
>>>if expressions are passed.  (Sean Paul)
>>>  - s/rgba/argb/ in helper function/macro names.  Even though the idea is
>>>to not worry about the internal representation of the u64, it can
>>>still be confusing to look at code that uses 'rgba' terminology, but
>>>stores values with argb ordering.  (Ville)
>>>
>>> v4:
>>>  - Drop the bgcolor_changed flag.  (Ville, Brian Starkey)
>>>  - Clarify in kerneldoc that background color is expected to undergo the
>>>same pipe-level degamma/csc/gamma transformations that planes do.
>>>(Brian Starkey)
>>>  - Update kerneldoc to indicate non-opaque colors are allowed, but are
>>>generally only useful in special cases such as when writeback
>>>connectors are used (Brian Starkey / Eric Anholt)
>>>
>>> v5:
>>>  - Set crtc->state->bgcolor to solid black inside
>>>drm_crtc_add_bgcolor_property() in case drivers don't do this
>>>themselves.  (Ville)
>>>  - Add kerneldoc to drm_crtc_add_bgcolor_property() function.
>>>
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: wei.c...@intel.com
>>> Cc: harish.krupo@intel.com
>>> Cc: Ville Syrjälä 
>>> Cc: Sean Paul 
>>> Cc: Brian Starkey 
>>> Cc: Eric Anholt 
>>> Cc: Stéphane Marchesin 
>>> Cc: Daniel Vetter 
>>> Signed-off-by: Matt Roper 
>>> Reviewed-by(v2): Sean Paul 
>>> Reviewed-by: Brian Starkey 
>> I like how bgcolor is a u64 now, but there is an issue with setting
>> crtc->state->bgcolor in attaching the property.
>>
>> We should do it in atomic core init instead, like we already do for
>> connector/plane properties..
>>
>> See for example https://patchwork.freedesktop.org/series/52363/
>>
>> This was specificallly for the background color proposal, but we
>> probalby have to split out the non-trivial conversions of
>> __drm_atomic_helper_crtc_reset.
> Makes sense.  What's the status of that patch?  It looks like it has a
> lot of a-b's/r-b's but hasn't landed yet.  Is there anything blocking
> it?  If you're still driving it forward, I can wait for that to land and
> then build on top of it.

There was a discussion about it. I will resubmit it and split it up for the 
non-trivial cases, so those can be reverted if needed.

Will send a new version in a bit.

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

Re: [PATCH] drm: hdlcd: Stop failing atomic disable check

[Liviu Dudau]

Hi Robin,

Sorry for the delay in reviewing this patch, I am drowning a bit this
week in meetings :)

On Mon, Feb 25, 2019 at 02:39:13PM +, Robin Murphy wrote:
> When __drm_atomic_helper_disable_all() tries to commit the disabled
> state, we end up in hdlcd_crtc_atomic_check() with a mode clock rate
> of 0. If the input clock has a nonzero minimum rate, this fails the
> clk_round_rate() check and prevents the CRTC being torn down cleanly.
> 
> If we're disabling the output, though, then the clock rate should be
> pretty much irrelevant, so skip it in that case. The kerneldoc seems
> to imply that we probably shouldn't be looking at the rest of the
> state anyway if enable=false.
> 
> Signed-off-by: Robin Murphy 

Acked-by: Liviu Dudau 


I'll pull your patch into my tree but it will be after v5.1-rc1 that
I'll send fixes to airlied.

> ---
> 
> I'm still occasionally trying to get to the bottom of why the HDLCD on
> Juno doesn't work properly with recent upstream EDK2 (the Linux driver
> thinks it's initialised and taken over, but the hardware stays stuck
> displaying the last contents of the EFI framebuffer). I was hoping that
> just unbinding and reprobing the HDLCD/TDA998x drivers might help reset
> things hard enough to start working again, but sadly no...

I think both HDLCD and Mali DP drivers misbehave when the bootloader
enables the device before the Linux driver probes. I'm interested in
sorting this one out and it involves talking to the SMMU as well, so
I'll get in touch with you outside this thread to see how I can
reproduce your EDK2 environment.

Best regards,
Liviu


> 
> Robin.
> 
>  drivers/gpu/drm/arm/hdlcd_crtc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index e4d67b70244d..30a0d9570b57 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -193,6 +193,9 @@ static int hdlcd_crtc_atomic_check(struct drm_crtc *crtc,
>   struct drm_display_mode *mode = >adjusted_mode;
>   long rate, clk_rate = mode->clock * 1000;
>  
> + if (!state->enable)
> + return 0;
> +
>   rate = clk_round_rate(hdlcd->clk, clk_rate);
>   if (rate != clk_rate) {
>   /* clock required by mode not supported by hardware */
> -- 
> 2.20.1.dirty
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #16 from Michel Dänzer  ---
The "suspicious RCU usage" looks related to the igb ethernet driver, not
amdgpu. Quite likely it's already fixed in later 5.0-rc releases.

-- 
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 109789] [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Michel Dänzer  ---


*** This bug has been marked as a duplicate of bug 109790 ***

-- 
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 109790] [ 11.594966] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  ---
*** Bug 109789 has been marked as a duplicate of this bug. ***

-- 
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] video: fbdev: atmel_lcdfb: drop AVR and platform_data support

[Nicolas.Ferre]

On 25/02/2019 at 22:25, Alexandre Belloni wrote:
> Make the driver OF only as since AVR32 has been removed from the kernel,
> there are only OF enabled platform using it.
> 
> Signed-off-by: Alexandre Belloni 

It looks good to me:
Acked-by: Nicolas Ferre 

Thanks Alexandre.
Best regards,
   Nicolas

> ---
>   drivers/video/fbdev/Kconfig   |   6 +-
>   drivers/video/fbdev/atmel_lcdfb.c | 114 ++
>   2 files changed, 7 insertions(+), 113 deletions(-)
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index ae7712c9687a..f0f07d02af88 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -866,8 +866,8 @@ config FB_S1D13XXX
> 
>   
>   config FB_ATMEL
> - tristate "AT91/AT32 LCD Controller support"
> - depends on FB && HAVE_FB_ATMEL
> + tristate "AT91 LCD Controller support"
> + depends on FB && OF && HAVE_FB_ATMEL
>   select FB_BACKLIGHT
>   select FB_CFB_FILLRECT
>   select FB_CFB_COPYAREA
> @@ -875,7 +875,7 @@ config FB_ATMEL
>   select FB_MODE_HELPERS
>   select VIDEOMODE_HELPERS
>   help
> -   This enables support for the AT91/AT32 LCD Controller.
> +   This enables support for the AT91 LCD Controller.
>   
>   config FB_NVIDIA
>   tristate "nVidia Framebuffer Support"
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
> b/drivers/video/fbdev/atmel_lcdfb.c
> index 4ed55e6bbb84..b8786ff62b87 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -1,5 +1,5 @@
>   /*
> - *  Driver for AT91/AT32 LCD Controller
> + *  Driver for AT91 LCD Controller
>*
>*  Copyright (C) 2007 Atmel Corporation
>*
> @@ -99,86 +99,6 @@ static struct atmel_lcdfb_config at91sam9rl_config = {
>   .have_intensity_bit = true,
>   };
>   
> -static struct atmel_lcdfb_config at32ap_config = {
> - .have_hozval= true,
> -};
> -
> -static const struct platform_device_id atmel_lcdfb_devtypes[] = {
> - {
> - .name = "at91sam9261-lcdfb",
> - .driver_data = (unsigned long)_config,
> - }, {
> - .name = "at91sam9263-lcdfb",
> - .driver_data = (unsigned long)_config,
> - }, {
> - .name = "at91sam9g10-lcdfb",
> - .driver_data = (unsigned long)_config,
> - }, {
> - .name = "at91sam9g45-lcdfb",
> - .driver_data = (unsigned long)_config,
> - }, {
> - .name = "at91sam9g45es-lcdfb",
> - .driver_data = (unsigned long)_config,
> - }, {
> - .name = "at91sam9rl-lcdfb",
> - .driver_data = (unsigned long)_config,
> - }, {
> - .name = "at32ap-lcdfb",
> - .driver_data = (unsigned long)_config,
> - }, {
> - /* terminator */
> - }
> -};
> -MODULE_DEVICE_TABLE(platform, atmel_lcdfb_devtypes);
> -
> -static struct atmel_lcdfb_config *
> -atmel_lcdfb_get_config(struct platform_device *pdev)
> -{
> - unsigned long data;
> -
> - data = platform_get_device_id(pdev)->driver_data;
> -
> - return (struct atmel_lcdfb_config *)data;
> -}
> -
> -#if defined(CONFIG_ARCH_AT91)
> -#define  ATMEL_LCDFB_FBINFO_DEFAULT  (FBINFO_DEFAULT \
> -  | FBINFO_PARTIAL_PAN_OK \
> -  | FBINFO_HWACCEL_YPAN)
> -
> -static inline void atmel_lcdfb_update_dma2d(struct atmel_lcdfb_info *sinfo,
> - struct fb_var_screeninfo *var,
> - struct fb_info *info)
> -{
> -
> -}
> -#elif defined(CONFIG_AVR32)
> -#define  ATMEL_LCDFB_FBINFO_DEFAULT  (FBINFO_DEFAULT \
> - | FBINFO_PARTIAL_PAN_OK \
> - | FBINFO_HWACCEL_XPAN \
> - | FBINFO_HWACCEL_YPAN)
> -
> -static void atmel_lcdfb_update_dma2d(struct atmel_lcdfb_info *sinfo,
> -  struct fb_var_screeninfo *var,
> -  struct fb_info *info)
> -{
> - u32 dma2dcfg;
> - u32 pixeloff;
> -
> - pixeloff = (var->xoffset * info->var.bits_per_pixel) & 0x1f;
> -
> - dma2dcfg = (info->var.xres_virtual - info->var.xres)
> -  * info->var.bits_per_pixel / 8;
> - dma2dcfg |= pixeloff << ATMEL_LCDC_PIXELOFF_OFFSET;
> - lcdc_writel(sinfo, ATMEL_LCDC_DMA2DCFG, dma2dcfg);
> -
> - /* Update configuration */
> - lcdc_writel(sinfo, ATMEL_LCDC_DMACON,
> - lcdc_readl(sinfo, ATMEL_LCDC_DMACON)
> - | ATMEL_LCDC_DMAUPDT);
> -}
> -#endif
> -
>   static u32 contrast_ctr = ATMEL_LCDC_PS_DIV8
>   | ATMEL_LCDC_POL_POSITIVE
>   | ATMEL_LCDC_ENA_PWMENABLE;
> @@ -404,8 +324,6 @@ static void atmel_lcdfb_update_dma(struct fb_info *info,
>   
>   /* Set framebuffer DMA base address and pixel offset */
> 

[RFC dma-buf 0/3] Improve the dma-buf tracking

[Chenbo Feng]

Currently, all dma-bufs share the same anonymous inode. While we can count
how many dma-buf fds or mappings a process has, we can't get the size of
the backing buffers or tell if two entries point to the same dma-buf. And
in debugfs, we can get a per-buffer breakdown of size and reference count,
but can't tell which processes are actually holding the references to each
buffer.

To resolve the issue above and provide better method for userspace to track
the dma-buf usage across different processes, the following changes are
proposed in dma-buf kernel side. First of all, replace the singleton inode
inside the dma-buf subsystem with a mini-filesystem, and assign each
dma-buf a unique inode out of this filesystem.  With this change, calling
stat(2) on each entry gives the caller a unique ID (st_ino), the buffer's
size (st_size), and even the number of pages assigned to each dma-buffer.
Secoundly, add the inode information to /sys/kernel/debug/dma_buf/bufinfo
so in the case where a buffer is mmap()ed into a process’s address space
but all remaining fds have been closed, we can still get the dma-buf
information and try to accociate it with the process by searching the
proc/pid/maps and looking for the corresponding inode number exposed in
dma-buf debug fs. Thirdly, created an ioctl to assign names to dma-bufs
which lets userspace assign short names (e.g., "CAMERA") to buffers. This
information can be extremely helpful for tracking and accounting shared
buffers based on their usage and original purpose. Last but not least, add
dma-buf information to /proc/pid/fdinfo by adding a show_fdinfo() handler
to dma_buf_file_operations. The handler will print the file_count and name
of each buffer.

Greg Hackmann (3):
  dma-buf: give each buffer a full-fledged inode
  dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls
  dma-buf: add show_fdinfo handler

 drivers/dma-buf/dma-buf.c| 121 ---
 include/linux/dma-buf.h  |   5 +-
 include/uapi/linux/dma-buf.h |   4 ++
 include/uapi/linux/magic.h   |   1 +
 4 files changed, 122 insertions(+), 9 deletions(-)

-- 
2.21.0.rc2.261.ga7da99ff1b-goog

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

Re: Regression in Linux next with dma cma changes

[Nicolin Chen]

On Tue, Feb 26, 2019 at 12:01:55PM -0800, Tony Lindgren wrote:
> Looks like commit d222e42e8816 ("dma-contiguous: do not allocate a
> single page from CMA area") caused a regression at least for
> omap dss where we now get the following error on init:
> 
> omapdss_dispc 58001000.dispc:
> dispc_errata_i734_wa_init: dma_alloc_writecombine failed
> 
> Any ideas what might be going wrong?

It's probably because the dma_alloc_from_contiguous() call in
this path doesn't rebound to allocate a normal single page.

And I guess we should have left the change within dma-direct.

Christoph, do you agree?

I am submitting a revert first.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/9] drm/bridge: tc358767: Simplify polling in tc_main_link_setup()

[Andrey Smirnov]

Replace explicit polling loop with equivalent call to
regmap_read_poll_timeout() for simplicity. No functional change
intended.

Signed-off-by: Andrey Smirnov 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index c85468fcc157..6455e6484722 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -882,15 +882,11 @@ static int tc_main_link_setup(struct tc_data *tc)
dp_phy_ctrl &= ~(DP_PHY_RST | PHY_M1_RST | PHY_M0_RST);
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
 
-   timeout = 1000;
-   do {
-   tc_read(DP_PHY_CTRL, );
-   udelay(1);
-   } while ((!(value & PHY_RDY)) && (--timeout));
-
-   if (timeout == 0) {
+   ret = regmap_read_poll_timeout(tc->regmap, DP_PHY_CTRL, value,
+  value & PHY_RDY, 1, 1000);
+   if (ret) {
dev_err(dev, "timeout waiting for phy become ready");
-   return -ETIMEDOUT;
+   return ret;
}
 
/* Set misc: 8 bits per color */
-- 
2.20.1

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

[PATCH 8/9] drm/bridge: tc358767: Introduce tc_pllupdate_pllen()

[Andrey Smirnov]

Tc_wait_pll_lock() is always called as a follow-up for updating
PLLUPDATE and PLLEN bit of a given PLL control register. To simplify
things, merge the two operation into a single helper function
tc_pllupdate_pllen() and convert the rest of the code to use it. No
functional change intended.

Signed-off-by: Andrey Smirnov 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/gpu/drm/bridge/tc358767.c | 36 +++
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 227f14cd2d3d..239b3aaa255d 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -390,10 +390,18 @@ static u32 tc_srcctrl(struct tc_data *tc)
return reg;
 }
 
-static void tc_wait_pll_lock(struct tc_data *tc)
+static int tc_pllupdate_pllen(struct tc_data *tc, unsigned int pllctrl)
 {
+   int ret;
+
+   ret = regmap_write(tc->regmap, pllctrl, PLLUPDATE | PLLEN);
+   if (ret)
+   return ret;
+
/* Wait for PLL to lock: up to 2.09 ms, depending on refclk */
usleep_range(3000, 6000);
+
+   return 0;
 }
 
 static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, u32 pixelclock)
@@ -487,11 +495,7 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, 
u32 pixelclock)
 (best_mul << 0));  /* Multiplier for PLL */
 
/* Force PLL parameter update and disable bypass */
-   tc_write(PXL_PLLCTRL, PLLUPDATE | PLLEN);
-
-   tc_wait_pll_lock(tc);
-
-   return 0;
+   return tc_pllupdate_pllen(tc, PXL_PLLCTRL);
 err:
return ret;
 }
@@ -568,11 +572,13 @@ static int tc_aux_link_setup(struct tc_data *tc)
 * Initially PLLs are in bypass. Force PLL parameter update,
 * disable PLL bypass, enable PLL
 */
-   tc_write(DP0_PLLCTRL, PLLUPDATE | PLLEN);
-   tc_wait_pll_lock(tc);
+   ret = tc_pllupdate_pllen(tc, DP0_PLLCTRL);
+   if (ret)
+   return ret;
 
-   tc_write(DP1_PLLCTRL, PLLUPDATE | PLLEN);
-   tc_wait_pll_lock(tc);
+   ret = tc_pllupdate_pllen(tc, DP1_PLLCTRL);
+   if (ret)
+   return ret;
 
ret = tc_poll_timeout(tc->regmap, DP_PHY_CTRL, PHY_RDY, PHY_RDY, 1,
  1000);
@@ -846,11 +852,13 @@ static int tc_main_link_setup(struct tc_data *tc)
msleep(100);
 
/* PLL setup */
-   tc_write(DP0_PLLCTRL, PLLUPDATE | PLLEN);
-   tc_wait_pll_lock(tc);
+   ret = tc_pllupdate_pllen(tc, DP0_PLLCTRL);
+   if (ret)
+   return ret;
 
-   tc_write(DP1_PLLCTRL, PLLUPDATE | PLLEN);
-   tc_wait_pll_lock(tc);
+   ret = tc_pllupdate_pllen(tc, DP1_PLLCTRL);
+   if (ret)
+   return ret;
 
/* PXL PLL setup */
if (tc_test_pattern) {
-- 
2.20.1

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