Re: [PATCH] gpu: drm: i915: Change return type to vm_fault_t

[Jani Nikula]

On Tue, 17 Apr 2018, Souptick Joarder  wrote:
> On 17-Apr-2018 9:45 PM, "Matthew Wilcox"  wrote:
>>
>> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote:
>> > Not exactly. The plan for these patches is to introduce new vm_fault_t
> type
>> > in vm_operations_struct fault handlers. It's now available in 4.17-rc1.
> We will
>> > push all the required drivers/filesystem changes through different
> maintainers
>> > to linus tree. Once everything is converted into vm_fault_t type then
> Changing
>> > it from a signed to an unsigned int causes GCC to warn about an
> assignment
>> > from an incompatible type -- int foo(void) is incompatible with
>> > unsigned int foo(void).
>> >
>> > Please refer 1c8f422059ae ("mm: change return type to vm_fault_t") in
> 4.17-rc1.
>>
>> I think this patch would be clearer if you did
>>
>> -   int ret;
>> +   int err;
>> +   vm_fault_t ret;
>>
>> Then it would be clearer to the maintainer that you're splitting apart the
>> VM_FAULT and errno codes.
>>
>> Sorry for not catching this during initial review.
>
> Ok, I will make required changes and send v2. Sorry, even I missed this :)

I'm afraid Daniel is closer to the truth. My bad, sorry for the noise.

BR,
Jani.



>>
>> > On Tue, Apr 17, 2018 at 8:59 PM, Jani Nikula
>> >  wrote:
>> > > On Tue, 17 Apr 2018, Souptick Joarder  wrote:
>> > >> Use new return type vm_fault_t for fault handler. For
>> > >> now, this is just documenting that the function returns
>> > >> a VM_FAULT value rather than an errno. Once all instances
>> > >> are converted, vm_fault_t will become a distinct type.
>> > >>
>> > >> Reference id -> 1c8f422059ae ("mm: change return type to
>> > >> vm_fault_t")
>> > >>
>> > >> Signed-off-by: Souptick Joarder 
>> > >> ---
>> > >>  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
>> > >>  drivers/gpu/drm/i915/i915_gem.c | 15 ---
>> > >>  2 files changed, 10 insertions(+), 8 deletions(-)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
>> > >> index a42deeb..95b0d50 100644
>> > >> --- a/drivers/gpu/drm/i915/i915_drv.h
>> > >> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > >> @@ -51,6 +51,7 @@
>> > >>  #include 
>> > >>  #include 
>> > >>  #include 
>> > >> +#include 
>> > >>
>> > >>  #include "i915_params.h"
>> > >>  #include "i915_reg.h"
>> > >> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct
> drm_i915_private *dev_priv,
>> > >>  unsigned int flags);
>> > >>  int __must_check i915_gem_suspend(struct drm_i915_private
> *dev_priv);
>> > >>  void i915_gem_resume(struct drm_i915_private *dev_priv);
>> > >> -int i915_gem_fault(struct vm_fault *vmf);
>> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
>> > >>  int i915_gem_object_wait(struct drm_i915_gem_object *obj,
>> > >>unsigned int flags,
>> > >>long timeout,
>> > >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
>> > >> index dd89abd..bdac690 100644
>> > >> --- a/drivers/gpu/drm/i915/i915_gem.c
>> > >> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> > >> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
>> > >>   * The current feature set supported by i915_gem_fault() and thus
> GTT mmaps
>> > >>   * is exposed via I915_PARAM_MMAP_GTT_VERSION (see
> i915_gem_mmap_gtt_version).
>> > >>   */
>> > >> -int i915_gem_fault(struct vm_fault *vmf)
>> > >> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>> > >>  {
>> > >>  #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
>> > >>   struct vm_area_struct *area = vmf->vma;
>> > >> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>   pgoff_t page_offset;
>> > >>   unsigned int flags;
>> > >>   int ret;
>> > >> + vm_fault_t retval;
>> > >
>> > > What's the point of changing the name? An unnecessary change.
>> > >
>> > > BR,
>> > > Jani.
>> > >
>> > >>
>> > >>   /* We don't use vmf->pgoff since that has the fake offset */
>> > >>   page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
>> > >> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>* and so needs to be reported.
>> > >>*/
>> > >>   if (!i915_terminally_wedged(_priv->gpu_error)) {
>> > >> - ret = VM_FAULT_SIGBUS;
>> > >> + retval = VM_FAULT_SIGBUS;
>> > >>   break;
>> > >>   }
>> > >>   case -EAGAIN:
>> > >> @@ -2017,21 +2018,21 @@ int i915_gem_fault(struct vm_fault *vmf)
>> > >>* EBUSY is ok: this just means that another thread
>> > >>* already did the job.
>> > >>*/
>> > >> - ret = VM_FAULT_NOPAGE;
>> > >> + retval = VM_FAULT_NOPAGE;
>> > >>   break;
>> > >>   case -ENOMEM:

[PATCH 0/2] qxl: two fixes.

[Gerd Hoffmann]

Gerd Hoffmann (2):
  qxl: fix qxl_release_{map,unmap}
  qxl: keep separate release_bo pointer

 drivers/gpu/drm/qxl/qxl_drv.h |  1 +
 drivers/gpu/drm/qxl/qxl_cmd.c |  6 ++
 drivers/gpu/drm/qxl/qxl_ioctl.c   |  4 ++--
 drivers/gpu/drm/qxl/qxl_release.c | 18 +-
 4 files changed, 14 insertions(+), 15 deletions(-)

-- 
2.9.3

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

[PATCH 1/2] qxl: fix qxl_release_{map,unmap}

[Gerd Hoffmann]

s/PAGE_SIZE/PAGE_MASK/

Luckily release_offset is never larger than PAGE_SIZE, so the bug has no
bad side effects and managed to stay unnoticed for years that way ...

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_ioctl.c   | 4 ++--
 drivers/gpu/drm/qxl/qxl_release.c | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index e238a1a2ec..6cc9f3367f 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -182,9 +182,9 @@ static int qxl_process_single_command(struct qxl_device 
*qdev,
goto out_free_reloc;
 
/* TODO copy slow path code from i915 */
-   fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset 
& PAGE_SIZE));
+   fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset 
& PAGE_MASK));
unwritten = __copy_from_user_inatomic_nocache
-   (fb_cmd + sizeof(union qxl_release_info) + 
(release->release_offset & ~PAGE_SIZE),
+   (fb_cmd + sizeof(union qxl_release_info) + 
(release->release_offset & ~PAGE_MASK),
 u64_to_user_ptr(cmd->command), cmd->command_size);
 
{
diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 5d84a66fed..a0b4244d28 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -411,10 +411,10 @@ union qxl_release_info *qxl_release_map(struct qxl_device 
*qdev,
struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
 
-   ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_SIZE);
+   ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_MASK);
if (!ptr)
return NULL;
-   info = ptr + (release->release_offset & ~PAGE_SIZE);
+   info = ptr + (release->release_offset & ~PAGE_MASK);
return info;
 }
 
@@ -426,7 +426,7 @@ void qxl_release_unmap(struct qxl_device *qdev,
struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
void *ptr;
 
-   ptr = ((void *)info) - (release->release_offset & ~PAGE_SIZE);
+   ptr = ((void *)info) - (release->release_offset & ~PAGE_MASK);
qxl_bo_kunmap_atomic_page(qdev, bo, ptr);
 }
 
-- 
2.9.3

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

[PATCH 2/2] qxl: keep separate release_bo pointer

[Gerd Hoffmann]

qxl expects that list_first_entry(release->bos) returns the first
element qxl added to the list.  ttm_eu_reserve_buffers() may reorder
the list though.

Add a release_bo field to struct qxl_release and use that instead.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_drv.h |  1 +
 drivers/gpu/drm/qxl/qxl_cmd.c |  6 ++
 drivers/gpu/drm/qxl/qxl_release.c | 12 ++--
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 00a1a66b05..864b456080 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -167,6 +167,7 @@ struct qxl_release {
 
int id;
int type;
+   struct qxl_bo *release_bo;
uint32_t release_offset;
uint32_t surface_release_id;
struct ww_acquire_ctx ticket;
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index c0fb52c6d4..01665b98c5 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -179,10 +179,9 @@ qxl_push_command_ring_release(struct qxl_device *qdev, 
struct qxl_release *relea
  uint32_t type, bool interruptible)
 {
struct qxl_command cmd;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
 
cmd.type = type;
-   cmd.data = qxl_bo_physical_address(qdev, to_qxl_bo(entry->tv.bo), 
release->release_offset);
+   cmd.data = qxl_bo_physical_address(qdev, release->release_bo, 
release->release_offset);
 
return qxl_ring_push(qdev->command_ring, , interruptible);
 }
@@ -192,10 +191,9 @@ qxl_push_cursor_ring_release(struct qxl_device *qdev, 
struct qxl_release *releas
 uint32_t type, bool interruptible)
 {
struct qxl_command cmd;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
 
cmd.type = type;
-   cmd.data = qxl_bo_physical_address(qdev, to_qxl_bo(entry->tv.bo), 
release->release_offset);
+   cmd.data = qxl_bo_physical_address(qdev, release->release_bo, 
release->release_offset);
 
return qxl_ring_push(qdev->cursor_ring, , interruptible);
 }
diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index a0b4244d28..7cb2145772 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -173,6 +173,7 @@ qxl_release_free_list(struct qxl_release *release)
list_del(>tv.head);
kfree(entry);
}
+   release->release_bo = NULL;
 }
 
 void
@@ -296,7 +297,6 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
*qdev,
 {
if (surface_cmd_type == QXL_SURFACE_CMD_DESTROY && create_rel) {
int idr_ret;
-   struct qxl_bo_list *entry = list_first_entry(_rel->bos, 
struct qxl_bo_list, tv.head);
struct qxl_bo *bo;
union qxl_release_info *info;
 
@@ -304,8 +304,9 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
*qdev,
idr_ret = qxl_release_alloc(qdev, QXL_RELEASE_SURFACE_CMD, 
release);
if (idr_ret < 0)
return idr_ret;
-   bo = to_qxl_bo(entry->tv.bo);
+   bo = create_rel->release_bo;
 
+   (*release)->release_bo = bo;
(*release)->release_offset = create_rel->release_offset + 64;
 
qxl_release_list_add(*release, bo);
@@ -365,6 +366,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev, 
unsigned long size,
 
bo = qxl_bo_ref(qdev->current_release_bo[cur_idx]);
 
+   (*release)->release_bo = bo;
(*release)->release_offset = qdev->current_release_bo_offset[cur_idx] * 
release_size_per_bo[cur_idx];
qdev->current_release_bo_offset[cur_idx]++;
 
@@ -408,8 +410,7 @@ union qxl_release_info *qxl_release_map(struct qxl_device 
*qdev,
 {
void *ptr;
union qxl_release_info *info;
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
-   struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
+   struct qxl_bo *bo = release->release_bo;
 
ptr = qxl_bo_kmap_atomic_page(qdev, bo, release->release_offset & 
PAGE_MASK);
if (!ptr)
@@ -422,8 +423,7 @@ void qxl_release_unmap(struct qxl_device *qdev,
   struct qxl_release *release,
   union qxl_release_info *info)
 {
-   struct qxl_bo_list *entry = list_first_entry(>bos, struct 
qxl_bo_list, tv.head);
-   struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
+   struct qxl_bo *bo = release->release_bo;
void *ptr;
 
ptr = ((void *)info) - (release->release_offset & ~PAGE_MASK);
-- 
2.9.3

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

Re: RFC for a render API to support adaptive sync and VRR

[Keith Packard]

Michel Dänzer  writes:

> Time-based presentation seems to be the right approach for preventing
> micro-stutter in games as well, Croteam developers have been researching
> this.

Both the Vulkan GOOGLE_display_timing extension and X11 Present
extension offer the ability to specify the desired display time in
seconds.

Similarly, I'd suggest that the min/max display refresh rate values be
advertised as time between frames rather than frames per second.

I'd also encourage using a single unit for all of these values,
preferably nanoseconds. Absolute times should all be referenced to
CLOCK_MONOTONIC.

-- 
-keith


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

Re: [Freedreno] [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel

[abhinavk]

Adding another point.

On 2018-04-17 17:04, abhin...@codeaurora.org wrote:

Hi Bjorn

Apologies if the prev reply wasnt clear.

Hope this one is.

reply inline.

On 2018-04-17 14:29, Bjorn Andersson wrote:

On Tue 17 Apr 11:21 PDT 2018, abhin...@codeaurora.org wrote:

On 2018-04-16 23:13, Bjorn Andersson wrote:

[..]

> If the panel isn't actually a piece of backlight hardware then it should
> not register a backlight device. Why do you need your own sysfs?
>
> Regards,
> Bjorn
[Abhinav] This particular panel isnt a piece of backlight hardware.
But, we want to have our own sysfs to give flexibility to our 
userspace

to write and read stuff for its proprietary uses.


Please be more specific in your replies, no one will accept code that
"does stuff" and expecting a reviewer to spend time guessing or 
pulling

the information out of you is a sure way to get your patches ignored.

Exactly what kind of stuff are you talking about here and exactly 
which

problem are you solving.

Thats how our downstream has been working so far and hence to 
maintain

the compatibility would like to have it.


Make your proprietary code work with the upstream kernel and you
shouldn't ever have to modify it.

Regards,
Bjorn


[Abhinav] We have a few userspace clients today for the backlight sysfs 
node
which read/write directly to 
"/sys/class/backlight/panel0-backlight/brightness"

When I said "stuff" I was only referring to the brightness value.
This separate sysfs node allows us to validate those userspace features 
of ours

which directly edit the backlight value on our reference platform.
Since our reference platform uses this panel,hence having our own
sysfs alias helps.
Otherwise, whenever we try to use this panel with upstream code we
will have to end up
changing all those places in our userspace/framework to change the 
sysfs path.

Hence we wanted to preserve that sysfs node name.
The wled device is not created under /sys/class/backlight but under
/sys/class/leds/wled.
So we will have to change the name of this node across all our 
userspace.


If this isnt a convincing reason enough to have its own sysfs node
path, I will use
your approach.

Let me know your comments or if this is still not clear.


[Abhinav] We also might not be using the brightness value "as-it-is".

We will potentially scale it up/down based on some requirements.

If we do not have our own sysfs alias for this, how do we account for
providing this interface for our chipset specific backlight dependent
feature.

Can you please comment on this?


___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

___
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: [Freedreno] [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel

[abhinavk]

Hi Bjorn

Apologies if the prev reply wasnt clear.

Hope this one is.

reply inline.

On 2018-04-17 14:29, Bjorn Andersson wrote:

On Tue 17 Apr 11:21 PDT 2018, abhin...@codeaurora.org wrote:

On 2018-04-16 23:13, Bjorn Andersson wrote:

[..]

> If the panel isn't actually a piece of backlight hardware then it should
> not register a backlight device. Why do you need your own sysfs?
>
> Regards,
> Bjorn
[Abhinav] This particular panel isnt a piece of backlight hardware.
But, we want to have our own sysfs to give flexibility to our 
userspace

to write and read stuff for its proprietary uses.


Please be more specific in your replies, no one will accept code that
"does stuff" and expecting a reviewer to spend time guessing or pulling
the information out of you is a sure way to get your patches ignored.

Exactly what kind of stuff are you talking about here and exactly which
problem are you solving.


Thats how our downstream has been working so far and hence to maintain
the compatibility would like to have it.


Make your proprietary code work with the upstream kernel and you
shouldn't ever have to modify it.

Regards,
Bjorn


[Abhinav] We have a few userspace clients today for the backlight sysfs 
node
which read/write directly to 
"/sys/class/backlight/panel0-backlight/brightness"

When I said "stuff" I was only referring to the brightness value.
This separate sysfs node allows us to validate those userspace features 
of ours

which directly edit the backlight value on our reference platform.
Since our reference platform uses this panel,hence having our own sysfs 
alias helps.
Otherwise, whenever we try to use this panel with upstream code we will 
have to end up
changing all those places in our userspace/framework to change the sysfs 
path.

Hence we wanted to preserve that sysfs node name.
The wled device is not created under /sys/class/backlight but under
/sys/class/leds/wled.
So we will have to change the name of this node across all our 
userspace.


If this isnt a convincing reason enough to have its own sysfs node path, 
I will use

your approach.

Let me know your comments or if this is still not clear.


___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

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

[Bug 106110] vaapi encoding with gstreamer 1.14 doesn't work

[bugzilla-daemon]

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

Christoph Haag  changed:

   What|Removed |Added

 Resolution|FIXED   |NOTOURBUG

--- Comment #4 from Christoph Haag  ---
According to gstreamer IRC my issue is something that should be reported as a
bug to gstreamer. Yours probably 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

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

taij...@posteo.de changed:

   What|Removed |Added

 Attachment #138374|0   |1
is obsolete||

--- Comment #7 from taij...@posteo.de ---
Created attachment 138890
  --> https://bugs.freedesktop.org/attachment.cgi?id=138890=edit
recovered journal of boot attempt

OK, trying out the latest git code from drm-next-4.18-wip up to and including
commit37d6cbfb550ebde65ec12291ec9ec03f87cd0aff, we seem to be getting a
step further in the boot process. Now the initramfs seems to hand over fine to
GDM, I can select my user entry and enter my login password. However, the
screen then freezes upon trying to start the user session (Xorg, haven't tried
Wayland so far). Error messages look very similar to before.

-- 
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 106111] [GPU Passthrough]GPU (Polaris) not reinitialized with Linux VM (Reset bug)

[bugzilla-daemon]

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

--- Comment #2 from Alex Williamson  ---
The IOMMU looks to be unhappy first:

[   40.201258] vfio_ecap_init: :0a:00.0 hiding ecap 0x19@0x270
[   40.201271] vfio_ecap_init: :0a:00.0 hiding ecap 0x1b@0x2d0
[   40.201279] vfio_ecap_init: :0a:00.0 hiding ecap 0x1e@0x370
[  159.958402] AMD-Vi: Completion-Wait loop timed out
[  160.118777] AMD-Vi: Completion-Wait loop timed out
[  160.799864] AMD-Vi: Event logged [
[  160.799868] IOTLB_INV_TIMEOUT device=0a:00.0 address=0x00043e8e8550]
[  160.799872] AMD-Vi: Event logged [
[  160.799874] IOTLB_INV_TIMEOUT device=0a:00.0 address=0x00043e8e8570]
[  160.799876] AMD-Vi: Event logged [
[  160.799878] IOTLB_INV_TIMEOUT device=0a:00.0 address=0x00043e8e8590]
[  161.801729] AMD-Vi: Event logged [
[  161.801732] IOTLB_INV_TIMEOUT device=0a:00.0 address=0x00043e8e85e0]
[  180.096365] AMD-Vi: Completion-Wait loop timed out
[  180.256758] AMD-Vi: Completion-Wait loop timed out
[  180.417182] AMD-Vi: Completion-Wait loop timed out
[  180.577636] AMD-Vi: Completion-Wait loop timed out

Can you try a v4.17-rc1 kernel?  Specifically, these two updates:

6bd06f5a486c vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs
eb5ecd1a40e2 iommu/amd: Add support for fast IOTLB flushing

Something about AMD GPUs get unhappy if the IOMMU sends out too many
invalidations and the above two patches can reduce the number of those
invalidations by up to a factor of 512.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bd06f5a486c06023a618a86e8153b91d26f75f4
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb5ecd1a40e2098f805fb63cb07817ac48826e40

-- 
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 10/10] drm/msm/gpu: Add the buffer objects from the submit to the crash dump

[Jordan Crouse]

For hangs, dump copy out the contents of the buffer objects attached to the
guilty submission and print them in the crash dump report.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt |  7 +++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 54 +++-
 drivers/gpu/drm/msm/msm_gpu.c| 48 +++--
 drivers/gpu/drm/msm/msm_gpu.h|  9 
 4 files changed, 105 insertions(+), 13 deletions(-)

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
index f84a47a9ca92..930e4c970a62 100644
--- a/Documentation/gpu/drm-msm-crash-dump.txt
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -28,6 +28,13 @@ ringbuffer:  # Ringbuffer data. There will be a sequence for 
each ringbuffer
data:   # [ascii85] The contents of the ring encoded as ascii85.
# Only the unused portions of the ring will be printed
# (up to a maximum of 'size' bytes)
+bos:   # List of buffers from the hanging submission (if known)
+  -iova:   # [hex] GPU address of the buffer
+   size:   # [decimal] Size of the buffer (in bytes)
+   data:   # [ascii85] The contents of the buffer encoded as
+   # ascii85. Only the contents of buffers marked as
+   # readable are dumped. Trailing zeros at the end of the
+   # buffer won't be dumped.
 registers: # Sets of register values. This section can be used multiple
# times for different ranges of registers. Each register will be
# on its own line.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index d6e42554b1cb..060470c400b8 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -438,6 +438,10 @@ void adreno_gpu_state_destroy(struct msm_gpu_state *state)
for (i = 0; i < ARRAY_SIZE(state->ring); i++)
kfree(state->ring[i].data);
 
+   for (i = 0; state->bos && i < state->nr_bos; i++)
+   kfree(state->bos[i].data);
+
+   kfree(state->bos);
kfree(state->comm);
kfree(state->cmd);
kfree(state->registers);
@@ -461,6 +465,35 @@ int adreno_gpu_state_put(struct msm_gpu_state *state)
 }
 
 #if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
+
+static void adreno_show_object(struct drm_printer *p, u32 *ptr, int len)
+{
+   char out[ASCII85_BUFSZ];
+   long l, datalen, i;
+
+   if (!ptr || !len)
+   return;
+
+   /*
+* Only dump the non-zero part of the buffer - rarely will any data
+* completely fill the entire allocated size of the buffer
+*/
+   for (datalen = 0, i = 0; i < len >> 2; i++) {
+   if (ptr[i])
+   datalen = i << 2;
+   }
+
+   l = ascii85_encode_len(datalen);
+
+   drm_printf(p, "data: !!ascii85 |\n");
+   drm_printf(p, " ");
+
+   for (i = 0; i < l; i++)
+   drm_printf(p, ascii85_encode(ptr[i], out));
+
+   drm_printf(p, "\n");
+}
+
 void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
struct drm_printer *p)
 {
@@ -487,19 +520,20 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
 
-   if (state->ring[i].data && state->ring[i].data_size) {
-   u32 *ptr = (u32 *) state->ring[i].data;
-   char out[ASCII85_BUFSZ];
-   long len = ascii85_encode_len(state->ring[i].data_size);
-   int j;
+   adreno_show_object(p, state->ring[i].data,
+   state->ring[i].data_size);
+   }
 
-   drm_printf(p, "data: !!ascii85 |\n");
-   drm_printf(p, " ");
+   if (state->bos) {
+   drm_printf(p, "bos:\n");
 
-   for (j = 0; j < len; j++)
-   drm_printf(p, ascii85_encode(ptr[j], out));
+   for (i = 0; i < state->nr_bos; i++) {
+   drm_printf(p, "  - iova: 0x%016llx\n",
+   state->bos[i].iova);
+   drm_printf(p, "size: %ld\n", state->bos[i].size);
 
-   drm_printf(p, "\n");
+   adreno_show_object(p, state->bos[i].data,
+   state->bos[i].size);
}
}
 
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index f36b415e123b..92395c5ef442 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -318,8 +318,39 @@ static void msm_gpu_devcoredump_free(void 

[PATCH 09/10] drm/msm/adreno: Add a5xx specific registers for the GPU state

[Jordan Crouse]

HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture.  Add a5xx specific code
to program the crashdumper and retrieve the wayward registers
and dump them for the crash state.

Also, remove a block of registers the regular CPU accessible
list that aren't useful for debug which helps reduce the size
of the crash state file by a goodly amount.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt |   4 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|   8 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|   8 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 236 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  |  23 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |   4 +-
 6 files changed, 252 insertions(+), 31 deletions(-)

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
index df25afd10602..f84a47a9ca92 100644
--- a/Documentation/gpu/drm-msm-crash-dump.txt
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -33,3 +33,7 @@ registers:# Sets of register values. This section can be 
used multiple
# on its own line.
   - [offset, value]# offset: [hex] byte offset of the register
# value: [hex] value of the register
+
+registers-hlsq: # (5xx only) Same format as registers. Register data that
+   # only accessible from the HLSQ aperture captured by the
+   # HW based crashdumper
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index fc502e412132..669c2d4b070d 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -421,10 +421,12 @@ static void a3xx_dump(struct msm_gpu *gpu)
 
 static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
 {
-   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+   struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (IS_ERR(state))
-   return state;
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+   adreno_gpu_state_get(gpu, state);
 
state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 8129cf037db1..7c4e6dc1ed59 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -457,10 +457,12 @@ static const unsigned int a4xx_registers[] = {
 
 static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
 {
-   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+   struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (IS_ERR(state))
-   return state;
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+   adreno_gpu_state_get(gpu, state);
 
state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 836a1df1f257..8220077bd768 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "msm_gem.h"
 #include "msm_mmu.h"
 #include "a5xx_gpu.h"
@@ -1123,8 +1124,9 @@ static const u32 a5xx_registers[] = {
0xE800, 0xE806, 0xE810, 0xE89A, 0xE8A0, 0xE8A4, 0xE8AA, 0xE8EB,
0xE900, 0xE905, 0xEB80, 0xEB8F, 0xEBB0, 0xEBB0, 0xEC00, 0xEC05,
0xEC08, 0xECE9, 0xECF0, 0xECF0, 0xEA80, 0xEA80, 0xEA82, 0xEAA3,
-   0xEAA5, 0xEAC2, 0xA800, 0xA8FF, 0xAC60, 0xAC60, 0xB000, 0xB97F,
-   0xB9A0, 0xB9BF, ~0
+   0xEAA5, 0xEAC2, 0xA800, 0xA800, 0xA820, 0xA828, 0xA840, 0xA87D,
+   0XA880, 0xA88D, 0xA890, 0xA8A3, 0xA8D0, 0xA8D8, 0xA8E0, 0xA8F5,
+   0xAC60, 0xAC60, ~0,
 };
 
 static void a5xx_dump(struct msm_gpu *gpu)
@@ -1195,25 +1197,233 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
return 0;
 }
 
+struct a5xx_crashdumper {
+   void *ptr;
+   struct drm_gem_object *bo;
+   u64 iova;
+};
+
+struct a5xx_gpu_state {
+   struct msm_gpu_state base;
+   u32 *hlsqregs;
+};
+
+#define gpu_poll_timeout(gpu, addr, val, cond, interval, timeout) \
+   readl_poll_timeout((gpu)->mmio + ((addr) << 2), val, cond, \
+   interval, timeout)
+
+static int a5xx_crashdumper_init(struct msm_gpu *gpu,
+   struct a5xx_crashdumper *dumper)
+{
+   dumper->ptr = msm_gem_kernel_new_locked(gpu->dev,
+   SZ_1M, MSM_BO_UNCACHED, gpu->aspace,
+   >bo, >iova);
+
+   if (IS_ERR(dumper->ptr))
+   return PTR_ERR(dumper->ptr);
+
+   return 0;
+}
+
+static void 

[PATCH 04/10] drm/msm/gpu: Convert the GPU show function to use the GPU state

[Jordan Crouse]

Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping a previously captured state from a GPU hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 11 +--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 12 +---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 18 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 30 
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  4 +-
 drivers/gpu/drm/msm/msm_debugfs.c   | 92 ++---
 drivers/gpu/drm/msm/msm_gpu.h   |  3 +-
 7 files changed, 104 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index b707b5bca9ab..4cffec2b6adc 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -411,15 +411,6 @@ static const unsigned int a3xx_registers[] = {
~0   /* sentinel */
 };
 
-#ifdef CONFIG_DEBUG_FS
-static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A3XX_RBBM_STATUS));
-   adreno_show(gpu, m);
-}
-#endif
-
 /* would be nice to not have to duplicate the _show() stuff with printk(): */
 static void a3xx_dump(struct msm_gpu *gpu)
 {
@@ -464,7 +455,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a3xx_irq,
.destroy = a3xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a3xx_show,
+   .show = adreno_show,
 #endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 17e97ebc1077..95f08c22e8d7 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -455,16 +455,6 @@ static const unsigned int a4xx_registers[] = {
~0 /* sentinel */
 };
 
-#ifdef CONFIG_DEBUG_FS
-static void a4xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A4XX_RBBM_STATUS));
-   adreno_show(gpu, m);
-
-}
-#endif
-
 static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
 {
struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
@@ -551,7 +541,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a4xx_irq,
.destroy = a4xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a4xx_show,
+   .show = adreno_show,
 #endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 08f25798abdb..b0910bbe5190 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1215,22 +1215,6 @@ static struct msm_gpu_state *a5xx_gpu_state_get(struct 
msm_gpu *gpu)
return state;
 }
 
-#ifdef CONFIG_DEBUG_FS
-static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A5XX_RBBM_STATUS));
-
-   /*
-* Temporarily disable hardware clock gating before going into
-* adreno_show to avoid issues while reading the registers
-*/
-   a5xx_set_hwcg(gpu, false);
-   adreno_show(gpu, m);
-   a5xx_set_hwcg(gpu, true);
-}
-#endif
-
 static struct msm_ringbuffer *a5xx_active_ring(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1260,7 +1244,7 @@ static const struct adreno_gpu_funcs funcs = {
.irq = a5xx_irq,
.destroy = a5xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a5xx_show,
+   .show = adreno_show,
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index b2ccaf25767c..522d47ac36e1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -423,38 +423,34 @@ void adreno_gpu_state_put(struct msm_gpu_state *state)
 }
 
 #ifdef CONFIG_DEBUG_FS
-void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
+void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
+   struct seq_file *m)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
 
+   if (IS_ERR_OR_NULL(state))
+   return;
+
+   seq_printf(m, "status:   %08x\n", state->rbbm_status);
seq_printf(m, "revision: %d (%d.%d.%d.%d)\n",

[PATCH 05/10] drm/msm/gpu: Rearrange the code that collects the task during a hang

[Jordan Crouse]

Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_gpu.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 1c09acfb4028..2ca354047250 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -314,6 +314,7 @@ static void recover_worker(struct work_struct *work)
struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_submit *submit;
struct msm_ringbuffer *cur_ring = gpu->funcs->active_ring(gpu);
+   char *comm = NULL, *cmd = NULL;
int i;
 
mutex_lock(>struct_mutex);
@@ -327,7 +328,7 @@ static void recover_worker(struct work_struct *work)
rcu_read_lock();
task = pid_task(submit->pid, PIDTYPE_PID);
if (task) {
-   char *cmd;
+   comm = kstrdup(task->comm, GFP_KERNEL);
 
/*
 * So slightly annoying, in other paths like
@@ -342,20 +343,21 @@ static void recover_worker(struct work_struct *work)
mutex_unlock(>struct_mutex);
cmd = kstrdup_quotable_cmdline(task, GFP_KERNEL);
mutex_lock(>struct_mutex);
+   }
+   rcu_read_unlock();
 
+   if (comm && cmd) {
dev_err(dev->dev, "%s: offending task: %s (%s)\n",
-   gpu->name, task->comm, cmd);
+   gpu->name, comm, cmd);
 
msm_rd_dump_submit(priv->hangrd, submit,
-   "offending task: %s (%s)", task->comm, cmd);
-
-   kfree(cmd);
-   } else {
+   "offending task: %s (%s)", comm, cmd);
+   } else
msm_rd_dump_submit(priv->hangrd, submit, NULL);
-   }
-   rcu_read_unlock();
}
 
+   kfree(cmd);
+   kfree(comm);
 
/*
 * Update all the rings with the latest and greatest fence.. this
-- 
2.17.0

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

[PATCH 08/10] drm/msm/adreno: Add ringbuffer data to the GPU state

[Jordan Crouse]

Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt |  5 +++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 41 
 drivers/gpu/drm/msm/msm_gpu.h|  2 ++
 3 files changed, 48 insertions(+)

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
index 902d9769f401..df25afd10602 100644
--- a/Documentation/gpu/drm-msm-crash-dump.txt
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -23,6 +23,11 @@ ringbuffer:  # Ringbuffer data. There will be a sequence for 
each ringbuffer
rptr:   # [decimal] The current read pointer (rptr) for the ring
wptr:   # [decimal] The current write pointer (wptr) for the
# ring
+   size:   # [decimal] The maximum size of the ring programmed in
+   # the hardware
+   data:   # [ascii85] The contents of the ring encoded as ascii85.
+   # Only the unused portions of the ring will be printed
+   # (up to a maximum of 'size' bytes)
 registers: # Sets of register values. This section can be used multiple
# times for different ranges of registers. Each register will be
# on its own line.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 8d48ea52ea07..1f520875a7fb 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -17,6 +17,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 #include "adreno_gpu.h"
 #include "msm_gem.h"
@@ -383,10 +384,30 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
do_gettimeofday(>time);
 
for (i = 0; i < gpu->nr_rings; i++) {
+   int size = 0, j;
+
state->ring[i].fence = gpu->rb[i]->memptrs->fence;
state->ring[i].seqno = gpu->rb[i]->seqno;
state->ring[i].rptr = get_rptr(adreno_gpu, gpu->rb[i]);
state->ring[i].wptr = get_wptr(gpu->rb[i]);
+
+   /*
+* Only copy used parts of the ring buffers (this should save
+* data size for lightly used rings)
+*/
+   for (j = 0; j < MSM_GPU_RINGBUFFER_SZ >> 2; j++)
+   if (gpu->rb[i]->start[j])
+   size = j;
+
+   if (size) {
+   state->ring[i].data = kmalloc((size + 1) << 2,
+   GFP_KERNEL);
+   if (state->ring[i].data) {
+   memcpy(state->ring[i].data, gpu->rb[i]->start,
+   (size + 1) << 2);
+   state->ring[i].data_size = (size + 1) << 2;
+   }
+   }
}
 
/* Count the number of registers */
@@ -417,9 +438,13 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
 
 static void adreno_gpu_state_destroy(struct kref *kref)
 {
+   int i;
struct msm_gpu_state *state = container_of(kref,
struct msm_gpu_state, ref);
 
+   for (i = 0; i < ARRAY_SIZE(state->ring); i++)
+   kfree(state->ring[i].data);
+
kfree(state->comm);
kfree(state->cmd);
kfree(state->registers);
@@ -459,6 +484,22 @@ void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state 
*state,
drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
+   drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
+
+   if (state->ring[i].data && state->ring[i].data_size) {
+   u32 *ptr = (u32 *) state->ring[i].data;
+   char out[ASCII85_BUFSZ];
+   long len = ascii85_encode_len(state->ring[i].data_size);
+   int j;
+
+   drm_printf(p, "data: !!ascii85 |\n");
+   drm_printf(p, " ");
+
+   for (j = 0; j < len; j++)
+   drm_printf(p, ascii85_encode(ptr[j], out));
+
+   drm_printf(p, "\n");
+   }
}
 
drm_printf(p, "registers:\n");
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index e65f507954c0..48f7b21f1cae 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -190,6 +190,8 @@ struct msm_gpu_state {
u32 seqno;
u32 rptr;
u32 wptr;
+   void 

[PATCH 07/10] drm/msm/adreno: Convert the show/crash file format

[Jordan Crouse]

Convert the format of the 'show' debugfs file and the crash
dump to a  format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt | 30 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 20 +---
 2 files changed, 42 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/gpu/drm-msm-crash-dump.txt

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
new file mode 100644
index ..902d9769f401
--- /dev/null
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -0,0 +1,30 @@
+# drm/msm GPU crash dump format
+#
+# This is a description of the format of the drm/msm GPU crash dump format that
+# can be read from /sys/kernel/dri/X/show or from devcoredump following a GPU
+# hang or fault
+
+---
+kernel:# [string] The kernel version as printed by UTS_RELEASE
+module:# [string] The module that generated the crash dump
+time:  # [seconds.microseconds] The kernel time at crash
+comm:  # [string] comm string for the binary that generated the fault
+   # (if known)
+cmdline:   # [string] the cmdline for the binary that generated the fault
+   # (if known)
+revision:  # [ id core.major.minor.patchlevel] The GPU id followed by the
+   # individual components of the id separated by dots
+rbbm-status:   # [hex] The current value of RBBM_STATUS which shows what GPU
+   # components were in use at the time of the crash
+ringbuffer:# Ringbuffer data. There will be a sequence for each ringbuffer
+  -id: # [decimal] Ringbuffer identifier (0 based index)
+   last-fence: # [decimal] The last fence issued on the ring
+   retired-fence:  # [decimal] THe last fence retired on the ring
+   rptr:   # [decimal] The current read pointer (rptr) for the ring
+   wptr:   # [decimal] The current write pointer (wptr) for the
+   # ring
+registers: # Sets of register values. This section can be used multiple
+   # times for different ranges of registers. Each register will be
+   # on its own line.
+  - [offset, value]# offset: [hex] byte offset of the register
+   # value: [hex] value of the register
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index d46ae2ede616..8d48ea52ea07 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -444,23 +444,27 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
 
-   drm_printf(p, "status:   %08x\n", state->rbbm_status);
drm_printf(p, "revision: %d (%d.%d.%d.%d)\n",
adreno_gpu->info->revn, adreno_gpu->rev.core,
adreno_gpu->rev.major, adreno_gpu->rev.minor,
adreno_gpu->rev.patchid);
 
-   for (i = 0; i < gpu->nr_rings; i++) {
-   drm_printf(p, "rb %d: fence:%d/%d\n", i,
-   state->ring[i].fence, state->ring[i].seqno);
+   drm_printf(p, "rbbm-status: 0x%08x\n", state->rbbm_status);
+
+   drm_printf(p, "ringbuffer:\n");
 
-   drm_printf(p, "  rptr: %d\n", state->ring[i].rptr);
-   drm_printf(p, "rb wptr:  %d\n", state->ring[i].wptr);
+   for (i = 0; i < gpu->nr_rings; i++) {
+   drm_printf(p, "  - id: %d\n", i);
+   drm_printf(p, "last-fence: %d\n", state->ring[i].seqno);
+   drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
+   drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
+   drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
}
 
-   drm_printf(p, "IO:region %s  0002\n", gpu->name);
+   drm_printf(p, "registers:\n");
+
for (i = 0; i < state->nr_registers; i++) {
-   drm_printf(p, "IO:R %08x %08x\n",
+   drm_printf(p, "  - { offset: 0x%04x, value: 0x%08x }\n",
state->registers[i * 2] << 2,
state->registers[(i * 2) + 1]);
}
-- 
2.17.0

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

[PATCH 03/10] drm/msm/gpu: Capture the state of the GPU

[Jordan Crouse]

Add the infrastructure to capture the state current state of the
GPU and store it in memory.  This is useful for storing the state
of a hung GPU so it can be dumped later.

For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this can
be extended to capture a much larger set of GPU information.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 15 +++
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 14 +++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 22 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 54 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  3 ++
 drivers/gpu/drm/msm/msm_gpu.h   | 19 +
 6 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 3ebbeb3a9b68..b707b5bca9ab 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -427,6 +427,19 @@ static void a3xx_dump(struct msm_gpu *gpu)
gpu_read(gpu, REG_A3XX_RBBM_STATUS));
adreno_dump(gpu);
 }
+
+static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+   if (IS_ERR(state))
+   return state;
+
+   state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
+
+   return state;
+}
+
 /* Register offset defines for A3XX */
 static const unsigned int a3xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -453,6 +466,8 @@ static const struct adreno_gpu_funcs funcs = {
 #ifdef CONFIG_DEBUG_FS
.show = a3xx_show,
 #endif
+   .gpu_state_get = a3xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
 };
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 16d3d596638e..17e97ebc1077 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -465,6 +465,18 @@ static void a4xx_show(struct msm_gpu *gpu, struct seq_file 
*m)
 }
 #endif
 
+static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+   if (IS_ERR(state))
+   return state;
+
+   state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
+
+   return state;
+}
+
 /* Register offset defines for A4XX, in order of enum adreno_regs */
 static const unsigned int a4xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_A4XX_CP_RB_BASE),
@@ -541,6 +553,8 @@ static const struct adreno_gpu_funcs funcs = {
 #ifdef CONFIG_DEBUG_FS
.show = a4xx_show,
 #endif
+   .gpu_state_get = a4xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a4xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a4f68affc13b..08f25798abdb 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1195,6 +1195,26 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
return 0;
 }
 
+static struct msm_gpu_state *a5xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state;
+
+   /*
+* Temporarily disable hardware clock gating before going into
+* adreno_show to avoid issues while reading the registers
+*/
+   a5xx_set_hwcg(gpu, false);
+
+   state = adreno_gpu_state_get(gpu);
+
+   if (!IS_ERR(state))
+   state->rbbm_status = gpu_read(gpu, REG_A5XX_RBBM_STATUS);
+
+   a5xx_set_hwcg(gpu, true);
+
+   return state;
+}
+
 #ifdef CONFIG_DEBUG_FS
 static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
 {
@@ -1244,6 +1264,8 @@ static const struct adreno_gpu_funcs funcs = {
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
+   .gpu_state_get = a5xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a5xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 17d0506d058c..b2ccaf25767c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -368,6 +368,60 @@ bool adreno_idle(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring)
return false;
 }
 
+struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct msm_gpu_state *state;
+   int i, count = 0;
+
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+  

[PATCH 06/10] drm/msm/gpu: Capture the GPU state on a GPU hang

[Jordan Crouse]

Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be captured on the next hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Kconfig |  1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  4 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 36 +++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  4 +-
 drivers/gpu/drm/msm/msm_debugfs.c   |  5 +-
 drivers/gpu/drm/msm/msm_gpu.c   | 83 -
 drivers/gpu/drm/msm/msm_gpu.h   | 38 ++-
 9 files changed, 153 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 38cbde971b48..843a9d40c05e 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -12,6 +12,7 @@ config DRM_MSM
select SHMEM
select TMPFS
select QCOM_SCM
+   select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
select PM_OPP
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 4cffec2b6adc..fc502e412132 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -454,7 +454,7 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = adreno_active_ring,
.irq = a3xx_irq,
.destroy = a3xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
 #endif
.gpu_state_get = a3xx_gpu_state_get,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 95f08c22e8d7..8129cf037db1 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -540,7 +540,7 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = adreno_active_ring,
.irq = a4xx_irq,
.destroy = a4xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
 #endif
.gpu_state_get = a4xx_gpu_state_get,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index b0910bbe5190..836a1df1f257 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1243,8 +1243,10 @@ static const struct adreno_gpu_funcs funcs = {
.active_ring = a5xx_active_ring,
.irq = a5xx_irq,
.destroy = a5xx_destroy,
-#ifdef CONFIG_DEBUG_FS
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
.show = adreno_show,
+#endif
+#if defined(CONFIG_DEBUG_FS)
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 522d47ac36e1..d46ae2ede616 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -378,6 +378,8 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
if (!state)
return ERR_PTR(-ENOMEM);
 
+   kref_init(>ref);
+
do_gettimeofday(>time);
 
for (i = 0; i < gpu->nr_rings; i++) {
@@ -413,18 +415,28 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
return state;
 }
 
-void adreno_gpu_state_put(struct msm_gpu_state *state)
+static void adreno_gpu_state_destroy(struct kref *kref)
 {
-   if (IS_ERR_OR_NULL(state))
-   return;
+   struct msm_gpu_state *state = container_of(kref,
+   struct msm_gpu_state, ref);
 
+   kfree(state->comm);
+   kfree(state->cmd);
kfree(state->registers);
kfree(state);
 }
 
-#ifdef CONFIG_DEBUG_FS
+int adreno_gpu_state_put(struct msm_gpu_state *state)
+{
+   if (IS_ERR_OR_NULL(state))
+   return 1;
+
+   return kref_put(>ref, adreno_gpu_state_destroy);
+}
+
+#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
 void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
-   struct seq_file *m)
+   struct drm_printer *p)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
@@ -432,23 +444,23 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
 
-   seq_printf(m, "status:   %08x\n", state->rbbm_status);
-   seq_printf(m, "revision: %d (%d.%d.%d.%d)\n",
+   drm_printf(p, "status:   %08x\n", state->rbbm_status);

[v5 00/10] drm/msm: A

[Jordan Crouse]

This is revision 4 implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/). This version fixes some
identified issues and actually compiles on a modern kernel.

The goal is to store and provide enough information to debug software
and hardware issues on the Adreno hardware in a semi human-readable
format that can also be parsed by scripts.

THe full set of changes here capture basic information about the GPU, the
status and contents of the ringbuffers, a snapshot of the current register state
and the active buffers from the hanging submit.

The data is printed with devcoredump.  For example, after a hang you can get
the data from /sys/class/devcoredump/devcdX/data where X is a unique number.

You can see an example of the output for a simple invalid opcode error on the
db820c here: https://hastebin.com/ewamikoreh.cs

v5: Fix symbol error in i915_gpu_error.c thanks to 01 dot org bot. Added
open/release functions for the show debugfs file to get the state per Chris
Wilson. Slightly modified the register output format to be more YAML friendly
also per Chris.
v4: Add buffer dump for the active submit. Fix refcount issue with devcoredump.
Change header for a5xx registers to registers-hlsq because I'm told YAML
requires unique tags.
v3: Make recommended changes to ascii85 per Chris Wilson. Use devcoredump to
dump crash states as suggested by Bjorn Andersson and add a new drm_print
facility to facilitate that. Remove the now obsolete 'crash' debugfs node.
Add documentation for the crash dump output.
v2: Convert output to yaml, use ascii85 to dump ringbuffer contents.

Jordan Crouse (10):
  include: Move ascii85 functions from i915 to linux/ascii85.h
  drm: drm_printer: Add printer for devcoredump
  drm/msm/gpu: Capture the state of the GPU
  drm/msm/gpu: Convert the GPU show function to use the GPU state
  drm/msm/gpu: Rearrange the code that collects the task during a hang
  drm/msm/gpu: Capture the GPU state on a GPU hang
  drm/msm/adreno: Convert the show/crash file format
  drm/msm/adreno: Add ringbuffer data to the GPU state
  drm/msm/adreno: Add a5xx specific registers for the GPU state
  drm/msm/gpu: Add the buffer objects from the submit to the crash dump

 Documentation/gpu/drm-msm-crash-dump.txt |  46 +
 drivers/gpu/drm/drm_print.c  |  54 +
 drivers/gpu/drm/i915/i915_gpu_error.c|  35 +---
 drivers/gpu/drm/msm/Kconfig  |   1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|  30 +--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|  22 ++-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 242 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 180 +++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |   7 +-
 drivers/gpu/drm/msm/msm_debugfs.c|  93 -
 drivers/gpu/drm/msm/msm_gpu.c| 143 +-
 drivers/gpu/drm/msm/msm_gpu.h|  67 ++-
 include/drm/drm_print.h  |  27 +++
 include/linux/ascii85.h  |  39 
 14 files changed, 886 insertions(+), 100 deletions(-)
 create mode 100644 Documentation/gpu/drm-msm-crash-dump.txt
 create mode 100644 include/linux/ascii85.h

-- 
2.17.0

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

[PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

[Jordan Crouse]

The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.

v3: Fix error_puts -> err_puts pointed out by the 01.org bot
v2: Update API to be cleaner for the caller as suggested by Chris Wilson

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 35 +++-
 include/linux/ascii85.h   | 39 +++
 2 files changed, 43 insertions(+), 31 deletions(-)
 create mode 100644 include/linux/ascii85.h

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 67c902412193..d14b8041d5c7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include "i915_drv.h"
 
 static inline const struct intel_engine_cs *
@@ -518,35 +518,12 @@ void i915_error_printf(struct drm_i915_error_state_buf 
*e, const char *f, ...)
va_end(args);
 }
 
-static int
-ascii85_encode_len(int len)
-{
-   return DIV_ROUND_UP(len, 4);
-}
-
-static bool
-ascii85_encode(u32 in, char *out)
-{
-   int i;
-
-   if (in == 0)
-   return false;
-
-   out[5] = '\0';
-   for (i = 5; i--; ) {
-   out[i] = '!' + in % 85;
-   in /= 85;
-   }
-
-   return true;
-}
-
 static void print_error_obj(struct drm_i915_error_state_buf *m,
struct intel_engine_cs *engine,
const char *name,
struct drm_i915_error_object *obj)
 {
-   char out[6];
+   char out[ASCII85_BUFSZ];
int page;
 
if (!obj)
@@ -568,12 +545,8 @@ static void print_error_obj(struct 
drm_i915_error_state_buf *m,
len -= obj->unused;
len = ascii85_encode_len(len);
 
-   for (i = 0; i < len; i++) {
-   if (ascii85_encode(obj->pages[page][i], out))
-   err_puts(m, out);
-   else
-   err_puts(m, "z");
-   }
+   for (i = 0; i < len; i++)
+   err_puts(m, ascii85_encode(obj->pages[page][i], out));
}
err_puts(m, "\n");
 }
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
new file mode 100644
index ..322bbed731ae
--- /dev/null
+++ b/include/linux/ascii85.h
@@ -0,0 +1,39 @@
+
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2008 Intel Corporation
+ * Copyright (c) The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _ASCII85_H_
+#define _ASCII85_H_
+
+#include 
+
+#define ASCII85_BUFSZ 6
+
+static inline long
+ascii85_encode_len(long len)
+{
+   return DIV_ROUND_UP(len, 4);
+}
+
+static inline char *
+ascii85_encode(u32 in, char *out)
+{
+   int i;
+
+   if (in == 0)
+   return "z";
+
+   out[5] = '\0';
+   for (i = 5; i--; ) {
+   out[i] = '!' + in % 85;
+   in /= 85;
+   }
+
+   return out;
+}
+
+#endif
-- 
2.17.0

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

[PATCH 02/10] drm: drm_printer: Add printer for devcoredump

[Jordan Crouse]

Add a drm printer suitable for use with the read callback for
devcoredump or any other file operation read() function that
isn't otherwise covered by seq_file.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/drm_print.c | 54 +
 include/drm/drm_print.h | 27 +++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 781518fd88e3..f6efde48f8b3 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -30,6 +30,60 @@
 #include 
 #include 
 
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
+{
+   struct drm_print_iterator *iterator = p->arg;
+
+   ssize_t len;
+
+   if (!iterator->remain)
+   return;
+
+   if (iterator->offset < iterator->start) {
+   char *buf;
+   ssize_t copy;
+
+   /* Figure out how big the string will be */
+   len = snprintf(NULL, 0, "%pV", vaf);
+
+   if (iterator->offset + len <= iterator->start) {
+   iterator->offset += len;
+   return;
+   }
+
+   /* Print the string into a temporary buffer */
+   buf = kmalloc(len + 1,
+   GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+   if (!buf)
+   return;
+
+   snprintf(buf, len + 1, "%pV", vaf);
+
+   copy = len - (iterator->start - iterator->offset);
+
+   if (copy > iterator->remain)
+   copy = iterator->remain;
+
+   /* Copy out the bit of the string that we need */
+   memcpy(iterator->data,
+   buf + (iterator->start - iterator->offset), copy);
+
+   iterator->offset = iterator->start + copy;
+   iterator->remain -= copy;
+
+   kfree(buf);
+   } else {
+   ssize_t pos = iterator->offset - iterator->start;
+
+   len = scnprintf(((char *) iterator->data) + pos,
+   iterator->remain, "%pV", vaf);
+
+   iterator->offset += len;
+   iterator->remain -= len;
+   }
+}
+EXPORT_SYMBOL(__drm_printfn_coredump);
+
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf)
 {
seq_printf(p->arg, "%pV", vaf);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 2a4a42e59a47..29eee5175eac 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -73,6 +73,7 @@ struct drm_printer {
const char *prefix;
 };
 
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
@@ -104,6 +105,32 @@ drm_vprintf(struct drm_printer *p, const char *fmt, 
va_list *va)
 #define drm_printf_indent(printer, indent, fmt, ...) \
drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t\t\tX", 
##__VA_ARGS__)
 
+struct drm_print_iterator {
+   void *data;
+
+   ssize_t start;
+   ssize_t offset;
+   ssize_t remain;
+};
+
+/**
+ * drm_coredump_printer - construct a _printer that can output to a buffer
+ * from the read function for devcoredump
+ * @iter: A pointer to a struct drm_print_iterator for the read instance
+ *
+ * RETURNS:
+ * The _printer object
+ */
+static inline struct drm_printer
+drm_coredump_printer(struct drm_print_iterator *iter)
+{
+   struct drm_printer p = {
+   .printfn = __drm_printfn_coredump,
+   .arg = iter,
+   };
+   return p;
+}
+
 /**
  * drm_seq_file_printer - construct a _printer that outputs to _file
  * @f:  the  seq_file to output to
-- 
2.17.0

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

[Bug 106111] [GPU Passthrough]GPU (Polaris) not reinitialized with Linux VM (Reset bug)

[bugzilla-daemon]

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

--- Comment #1 from Max  ---
Created attachment 13
  --> https://bugs.freedesktop.org/attachment.cgi?id=13=edit
dmesg output after to launch the VM a second time

-- 
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 106111] [GPU Passthrough]GPU (Polaris) not reinitialized with Linux VM (Reset bug)

[bugzilla-daemon]

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

Bug ID: 106111
   Summary: [GPU Passthrough]GPU (Polaris) not reinitialized with
Linux VM (Reset bug)
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: berilli...@gmail.com
CC: alexdeuc...@gmail.com

Created attachment 138887
  --> https://bugs.freedesktop.org/attachment.cgi?id=138887=edit
xorg.conf

Hi,

My Setup :
- AMD Ryzen 1600
- 16 Gb Memory RAM
- Host (Debian Stable, kernel 4.16.2) : AMD Rx560 4Gb
- Guest (Windows 10 / Archlinux Kernel 4.15.x-4.16.x) : AMD Rx580 - 8Gb

Years ago there was an issue on Windows virtual machine with Qemu/VFIO and AMD
GPU. It was impossible to reboot or use a 2nde time the Guest because the GPU
was not reinitialized when the Host was shutdown. The only solution to re-use
the VM was to reboot the Host OR use a Nvidia GPU.

Actually, the issue is fixed on Windows VM + AMD GPU passed through (i don't
know how), i can use more times my VM without reboot the Host. 

But if i use my Linux VM with my Rx580, the issue still exist. The first launch
works, i can use the Rx580 to play without problem. But if i shutdown/reboot
the guest, the Rx580 is "blocked". I need to hard reboot because the system
hangs after ~2-3 minutes.

Thanks for your help,
Maxime 

(Sorry for my English, i'm French)

-- 
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/amdgpu: cleanup firmware requests v2

[Andres Rodriguez]

Add a new function amdgpu_ucode_request_firmware() that encapsulates a
lot of the common behaviour we have around firmware requests.

This is the first step in my quest to get rid of the following annoying
messages when my polaris10 boots up:
[0.558537] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_pfp_2.bin failed with error -2
[0.558551] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_me_2.bin failed with error -2
[0.558562] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_ce_2.bin failed with error -2
[0.558580] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_mec_2.bin failed with error -2
[0.558619] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_mec2_2.bin failed with error -2

v2: make amdgpu_ucode_validate file scope only
add kernel-doc for amdgpu_ucode_request_firmware()

Signed-off-by: Andres Rodriguez 
---

Sorry for the quick V2, noticed some docs might help and that
_validate() could be reduced in scope. Pasting my old message
again just in case.

Hey Christian,

Wanted to go through a cleanup of the ucode loading in amdgpu
to facilitate some of our heated discussions :)

For now, functionality should remain the same. Once _nowarn()
lands we can change amdgpu_ucode_request_firmware() with either:

Alternative A:
-   err = request_firmware(_fw, name, adev->dev);
+   err = request_firmware_nowarn(_fw, name, adev->dev);

Alternative B:
-   err = request_firmware(_fw, name, adev->dev);
+   if (optional)
+   err = request_firmware_nowarn(_fw, name, adev->dev);
+   else
+   err = request_firmware(_fw, name, adev->dev);

I prefer A, but I'm not opposed to B. I'll leave it up to you.

Regards,
Andres

 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  14 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  16 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c  |  74 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h  |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  16 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  16 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  16 +
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  15 +---
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   5 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  19 ++---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  30 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 112 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  39 +++---
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  |  17 +
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  14 +---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  14 +---
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c |  18 +
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c  |  15 +---
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |   7 +-
 drivers/gpu/drm/amd/amdgpu/si_dpm.c|  16 +
 22 files changed, 164 insertions(+), 325 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index a8a942c60ea2..347ab1710523 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -402,19 +402,9 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device 
*cgs_device,
return -EINVAL;
}
 
-   err = request_firmware(>pm.fw, fw_name, 
adev->dev);
-   if (err) {
-   DRM_ERROR("Failed to request firmware\n");
+   err = amdgpu_ucode_request_firmware(adev, >pm.fw, 
fw_name, false);
+   if (err)
return err;
-   }
-
-   err = amdgpu_ucode_validate(adev->pm.fw);
-   if (err) {
-   DRM_ERROR("Failed to load firmware \"%s\"", 
fw_name);
-   release_firmware(adev->pm.fw);
-   adev->pm.fw = NULL;
-   return err;
-   }
 
if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) {
ucode = 
>firmware.ucode[AMDGPU_UCODE_ID_SMC];
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index abc33464959e..967e14f14abc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1355,20 +1355,10 @@ static int amdgpu_device_parse_gpu_info_fw(struct 
amdgpu_device *adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_gpu_info.bin", chip_name);
-   err = request_firmware(>firmware.gpu_info_fw, fw_name, adev->dev);
-   if (err) {
-   dev_err(adev->dev,
-   

Re: [PATCH v7] drm/vc4: update cursors asynchronously through atomic

[Eric Anholt]

Eric Anholt  writes:

> [ Unknown signature status ]
> Boris Brezillon  writes:
>
>> From: Gustavo Padovan 
>>
>> Add support for async updates of cursors by using the new atomic
>> interface for that. Basically what this commit does is do what
>> vc4_update_plane() did but through atomic.
>
> My r-b still applies with your fixes here.  Go ahead and push when
> you're ready.

I've gone ahead and pushed this patch.


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

Re: [PATCH v3 4/4] drm/vc4: Add CTM support

[Eric Anholt]

Eric Anholt  writes:

> [ Unknown signature status ]
> Stefan Schake  writes:
>
>> The hardware has a single block for applying a CTM prior to gamma lut.
>> It can be fed with pixels from one of our CRTC at a time and uses a
>> matrix with S0.9 scalars. Use private atomic state to reject attempts
>> from userland to apply CTM for more than one CRTC at a time and reject
>> matrices with scalars that we can't approximate without integer bits.
>>
>> Signed-off-by: Stefan Schake 
>> ---
>> v3: New in the series
>
> Patch 2-3 get my r-b, and I've sent Stefan a small series of fixups for
> the modeset locking as was patiently explained to me by danvet.  With
> that, it'll have my r-b, and hopefully danvet can confirm that it's what
> he meant :)

I've pushed 1-3, and danvet confirmed that the squash fixes looked good
to him.


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

[PATCH] drm/amdgpu: cleanup firmware requests

[Andres Rodriguez]

Add a new function amdgpu_ucode_request_firmware() that encapsulates a
lot of the common behaviour we have around firmware requests.

This is the first step in my quest to get rid of the following annoying
messages when my polaris10 boots up:
[0.558537] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_pfp_2.bin failed with error -2
[0.558551] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_me_2.bin failed with error -2
[0.558562] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_ce_2.bin failed with error -2
[0.558580] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_mec_2.bin failed with error -2
[0.558619] amdgpu :01:00.0: Direct firmware load for 
amdgpu/polaris10_mec2_2.bin failed with error -2

Signed-off-by: Andres Rodriguez 
---

Hey Christian,

Wanted to go through a cleanup of the ucode loading in amdgpu
to facilitate some of our heated discussions :)

For now, functionality should remain the same. Once _nowarn()
lands we can change amdgpu_ucode_request_firmware() with either:

Alternative A:
-   err = request_firmware(_fw, name, adev->dev);
+   err = request_firmware_nowarn(_fw, name, adev->dev);

Alternative B:
-   err = request_firmware(_fw, name, adev->dev);
+   if (optional)
+   err = request_firmware_nowarn(_fw, name, adev->dev);
+   else
+   err = request_firmware(_fw, name, adev->dev);

I prefer A, but I'm not opposed to B. I'll leave it up to you.

Regards,
Andres

 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  14 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  16 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c  |  39 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h  |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  16 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  16 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c|  16 +
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  15 +---
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |   5 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  19 ++---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  30 ++--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  | 112 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  39 +++---
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  |  17 +
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  14 +---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  14 +---
 drivers/gpu/drm/amd/amdgpu/psp_v10_0.c |  18 +
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c  |  15 +---
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |   6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |   7 +-
 drivers/gpu/drm/amd/amdgpu/si_dpm.c|  16 +
 22 files changed, 139 insertions(+), 314 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index a8a942c60ea2..347ab1710523 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -402,19 +402,9 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device 
*cgs_device,
return -EINVAL;
}
 
-   err = request_firmware(>pm.fw, fw_name, 
adev->dev);
-   if (err) {
-   DRM_ERROR("Failed to request firmware\n");
+   err = amdgpu_ucode_request_firmware(adev, >pm.fw, 
fw_name, false);
+   if (err)
return err;
-   }
-
-   err = amdgpu_ucode_validate(adev->pm.fw);
-   if (err) {
-   DRM_ERROR("Failed to load firmware \"%s\"", 
fw_name);
-   release_firmware(adev->pm.fw);
-   adev->pm.fw = NULL;
-   return err;
-   }
 
if (adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) {
ucode = 
>firmware.ucode[AMDGPU_UCODE_ID_SMC];
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index abc33464959e..967e14f14abc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1355,20 +1355,10 @@ static int amdgpu_device_parse_gpu_info_fw(struct 
amdgpu_device *adev)
}
 
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_gpu_info.bin", chip_name);
-   err = request_firmware(>firmware.gpu_info_fw, fw_name, adev->dev);
-   if (err) {
-   dev_err(adev->dev,
-   "Failed to load gpu_info firmware \"%s\"\n",
-   fw_name);
+   err = amdgpu_ucode_request_firmware(adev, >firmware.gpu_info_fw,
+   fw_name, false);
+   if (err)

Re: [PATCH v3 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.

[Eric Anholt]

Rob Herring  writes:

> On Mon, Apr 16, 2018 at 5:52 PM, Eric Anholt  wrote:
>> The GPU subsystem node was a workaround to have a central device to
>> bind V3D and display to.  Following the lead of 246774d17fc0
>> ("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
>> the subsystem node usage and just create a platform device for the DRM
>> device to attach to if any of the subsystem devices are present.
>>
>> v2: Simplify the DT walking code.
>> v3: Always put the node.
>>
>> Signed-off-by: Eric Anholt 
>> ---
>>  .../bindings/display/brcm,bcm-vc4.txt |  7 -
>>  drivers/gpu/drm/vc4/vc4_drv.c | 28 +--
>>  drivers/gpu/drm/vc4/vc4_hvs.c |  1 +
>>  drivers/gpu/drm/vc4/vc4_v3d.c |  1 +
>>  4 files changed, 22 insertions(+), 15 deletions(-)
>
> Reviewed-by: Rob Herring 

Unfortunately, on further testing, this ends up broken.  My guess is
that our new platform device isn't on the same bus, so we don't get our
dma-ranges translation when we use drm->dev, and that breaks caching
behavior.


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

Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Dongwon Kim]

On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
> On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
> > Yeah, I definitely agree on the idea of expanding the use case to the 
> > general domain where dmabuf sharing is used. However, what you are
> > targetting with proposed changes is identical to the core design of
> > hyper_dmabuf.
> > 
> > On top of this basic functionalities, hyper_dmabuf has driver level
> > inter-domain communication, that is needed for dma-buf remote tracking
> > (no fence forwarding though), event triggering and event handling, extra
> > meta data exchange and hyper_dmabuf_id that represents grefs
> > (grefs are shared implicitly on driver level)
> 
> This really isn't a positive design aspect of hyperdmabuf imo. The core
> code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is
> very simple & clean.
> 
> If there's a clear need later on we can extend that. But for now xen-zcopy
> seems to cover the basic use-case needs, so gets the job done.
> 
> > Also it is designed with frontend (common core framework) + backend
> > (hyper visor specific comm and memory sharing) structure for portability.
> > We just can't limit this feature to Xen because we want to use the same
> > uapis not only for Xen but also other applicable hypervisor, like ACORN.
> 
> See the discussion around udmabuf and the needs for kvm. I think trying to
> make an ioctl/uapi that works for multiple hypervisors is misguided - it
> likely won't work.
> 
> On top of that the 2nd hypervisor you're aiming to support is ACRN. That's
> not even upstream yet, nor have I seen any patches proposing to land linux
> support for ACRN. Since it's not upstream, it doesn't really matter for
> upstream consideration. I'm doubting that ACRN will use the same grant
> references as xen, so the same uapi won't work on ACRN as on Xen anyway.

Yeah, ACRN doesn't have grant-table. Only Xen supports it. But that is why
hyper_dmabuf has been architectured with the concept of backend.
If you look at the structure of backend, you will find that
backend is just a set of standard function calls as shown here:

struct hyper_dmabuf_bknd_ops {
/* backend initialization routine (optional) */
int (*init)(void);

/* backend cleanup routine (optional) */
int (*cleanup)(void);

/* retreiving id of current virtual machine */
int (*get_vm_id)(void);

/* get pages shared via hypervisor-specific method */
int (*share_pages)(struct page **pages, int vm_id,
   int nents, void **refs_info);

/* make shared pages unshared via hypervisor specific method */
int (*unshare_pages)(void **refs_info, int nents);

/* map remotely shared pages on importer's side via
 * hypervisor-specific method
 */
struct page ** (*map_shared_pages)(unsigned long ref, int vm_id,
   int nents, void **refs_info);

/* unmap and free shared pages on importer's side via
 * hypervisor-specific method
 */
int (*unmap_shared_pages)(void **refs_info, int nents);

/* initialize communication environment */
int (*init_comm_env)(void);

void (*destroy_comm)(void);

/* upstream ch setup (receiving and responding) */
int (*init_rx_ch)(int vm_id);

/* downstream ch setup (transmitting and parsing responses) */
int (*init_tx_ch)(int vm_id);

int (*send_req)(int vm_id, struct hyper_dmabuf_req *req, int wait);
};

All of these can be mapped with any hypervisor specific implementation.
We designed backend implementation for Xen using grant-table, Xen event
and ring buffer communication. For ACRN, we have another backend using Virt-IO
for both memory sharing and communication.

We tried to define this structure of backend to make it general enough (or
it can be even modified or extended to support more cases.) so that it can
fit to other hypervisor cases. Only requirements/expectation on the hypervisor
are page-level memory sharing and inter-domain communication, which I think
are standard features of modern hypervisor.

And please review common UAPIs that hyper_dmabuf and xen-zcopy supports. They
are very general. One is getting FD (dmabuf) and get those shared. The other
is generating dmabuf from global handle (secure handle hiding gref behind it).
On top of this, hyper_dmabuf has "unshare" and "query" which are also useful
for any cases.

So I don't know why we wouldn't want to try to make these standard in most of
hypervisor cases instead of limiting it to certain hypervisor like Xen.
Frontend-backend structre is optimal for this I think.

> 
> > So I am wondering we can start with this hyper_dmabuf then modify it for
> > your use-case if needed and polish and fix any glitches if we want to 
> > to use this for all general dma-buf usecases.
> 
> Imo xen-zcopy is a much more reasonable 

Re: [DPU PATCH 4/6] drm/msm: strip down custom event ioctl's

[Sean Paul]

On Mon, Apr 16, 2018 at 11:22:19AM -0700, Jeykumar Sankaran wrote:
> Remove custom ioctl support in SDM845 which allows
> user space to register/unregister for hw events.
> 
> Signed-off-by: Jeykumar Sankaran 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 218 
> +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |   1 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  31 -
>  drivers/gpu/drm/msm/msm_drv.c| 201 
>  drivers/gpu/drm/msm/msm_kms.h|   2 -
>  5 files changed, 1 insertion(+), 452 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 8e464fa..387919a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -39,31 +39,6 @@
>  #include "dpu_core_perf.h"
>  #include "dpu_trace.h"
>  
> -struct dpu_crtc_irq_info {
> - struct dpu_irq_callback irq;
> - u32 event;
> - int (*func)(struct drm_crtc *crtc, bool en,
> - struct dpu_irq_callback *irq);
> - struct list_head list;
> -};
> -
> -struct dpu_crtc_custom_events {
> - u32 event;
> - int (*func)(struct drm_crtc *crtc, bool en,
> - struct dpu_irq_callback *irq);
> -};
> -
> -static int dpu_crtc_power_interrupt_handler(struct drm_crtc *crtc_drm,
> - bool en, struct dpu_irq_callback *ad_irq);
> -static int dpu_crtc_idle_interrupt_handler(struct drm_crtc *crtc_drm,
> - bool en, struct dpu_irq_callback *idle_irq);
> -
> -static struct dpu_crtc_custom_events custom_events[] = {
> - {DRM_EVENT_AD_BACKLIGHT, dpu_cp_ad_interrupt},
> - {DRM_EVENT_CRTC_POWER, dpu_crtc_power_interrupt_handler},
> - {DRM_EVENT_IDLE_NOTIFY, dpu_crtc_idle_interrupt_handler}
> -};
> -
>  /* layer mixer index on dpu_crtc */
>  #define LEFT_MIXER 0
>  #define RIGHT_MIXER 1
> @@ -2455,9 +2430,6 @@ static void dpu_crtc_handle_power_event(u32 event_type, 
> void *arg)
>   struct drm_encoder *encoder;
>   struct dpu_crtc_mixer *m;
>   u32 i, misr_status;
> - unsigned long flags;
> - struct dpu_crtc_irq_info *node = NULL;
> - int ret = 0;
>  
>   if (!crtc) {
>   DPU_ERROR("invalid crtc\n");
> @@ -2479,17 +2451,6 @@ static void dpu_crtc_handle_power_event(u32 
> event_type, void *arg)
>   dpu_encoder_virt_restore(encoder);
>   }
>  
> - spin_lock_irqsave(_crtc->spin_lock, flags);
> - list_for_each_entry(node, _crtc->user_event_list, list) {
> - ret = 0;
> - if (node->func)
> - ret = node->func(crtc, true, >irq);
> - if (ret)
> - DPU_ERROR("%s failed to enable event %x\n",
> - dpu_crtc->name, node->event);
> - }
> - spin_unlock_irqrestore(_crtc->spin_lock, flags);
> -
>   dpu_cp_crtc_post_ipc(crtc);
>  
>   for (i = 0; i < dpu_crtc->num_mixers; ++i) {
> @@ -2514,18 +2475,6 @@ static void dpu_crtc_handle_power_event(u32 
> event_type, void *arg)
>   dpu_crtc->misr_data[i];
>   }
>  
> - spin_lock_irqsave(_crtc->spin_lock, flags);
> - node = NULL;
> - list_for_each_entry(node, _crtc->user_event_list, list) {
> - ret = 0;
> - if (node->func)
> - ret = node->func(crtc, false, >irq);
> - if (ret)
> - DPU_ERROR("%s failed to disable event %x\n",
> - dpu_crtc->name, node->event);
> - }
> - spin_unlock_irqrestore(_crtc->spin_lock, flags);
> -
>   dpu_cp_crtc_pre_ipc(crtc);
>   break;
>   case DPU_POWER_EVENT_POST_DISABLE:
> @@ -2553,8 +2502,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
>   struct drm_display_mode *mode;
>   struct drm_encoder *encoder;
>   struct msm_drm_private *priv;
> - unsigned long flags;
> - struct dpu_crtc_irq_info *node = NULL;
>   struct drm_event event;
>   u32 power_on;
>   int ret;
> @@ -2614,17 +2561,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
>   atomic_set(_crtc->frame_pending, 0);
>   }
>  
> - spin_lock_irqsave(_crtc->spin_lock, flags);
> - list_for_each_entry(node, _crtc->user_event_list, list) {
> - ret = 0;
> - if (node->func)
> - ret = node->func(crtc, false, >irq);
> - if (ret)
> - DPU_ERROR("%s failed to disable event %x\n",
> - dpu_crtc->name, node->event);
> - }
> - 

Re: [DPU PATCH 3/6] drm/msm: remove panel autorefresh support for SDM845

[Sean Paul]

On Mon, Apr 16, 2018 at 11:22:18AM -0700, Jeykumar Sankaran wrote:
> Remove autorefresh support for smart panels in SDM845 for now.
> It needs more discussion to figure out the user space
> communication to set preference for the feature.
> 
> Signed-off-by: Jeykumar Sankaran 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   7 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  37 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |  20 --
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 298 
> +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|  41 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|  18 --
>  6 files changed, 11 insertions(+), 410 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> index f7e9f76..dc0978d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> @@ -24,9 +24,6 @@
>  
>  #define BL_NODE_NAME_SIZE 32
>  
> -/* Autorefresh will occur after FRAME_CNT frames. Large values are unlikely 
> */
> -#define AUTOREFRESH_MAX_FRAME_CNT 6
> -
>  #define DPU_DEBUG_CONN(c, fmt, ...) DPU_DEBUG("conn%d " fmt,\
>   (c) ? (c)->base.base.id : -1, ##__VA_ARGS__)
>  
> @@ -1126,10 +1123,6 @@ struct drm_connector *dpu_connector_init(struct 
> drm_device *dev,
>   CONNECTOR_PROP_AD_BL_SCALE);
>  #endif
>  
> - msm_property_install_range(_conn->property_info, "autorefresh",
> - 0x0, 0, AUTOREFRESH_MAX_FRAME_CNT, 0,
> - CONNECTOR_PROP_AUTOREFRESH);
> -
>   /* enum/bitmask properties */
>   msm_property_install_enum(_conn->property_info, "topology_name",
>   DRM_MODE_PROP_IMMUTABLE, 0, e_topology_name,
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 32375b1..3004569 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -815,7 +815,6 @@ static void _dpu_encoder_resource_control_helper(struct 
> drm_encoder *drm_enc,
>  static int dpu_encoder_resource_control(struct drm_encoder *drm_enc,
>   u32 sw_event)
>  {
> - bool autorefresh_enabled = false;
>   unsigned int lp, idle_timeout;
>   struct dpu_encoder_virt *dpu_enc;
>   struct msm_drm_private *priv;
> @@ -922,13 +921,6 @@ static int dpu_encoder_resource_control(struct 
> drm_encoder *drm_enc,
>   return 0;
>   }
>  
> - /* schedule delayed off work if autorefresh is disabled */
> - if (dpu_enc->cur_master &&
> - dpu_enc->cur_master->ops.is_autorefresh_enabled)
> - autorefresh_enabled =
> - dpu_enc->cur_master->ops.is_autorefresh_enabled(
> - dpu_enc->cur_master);
> -
>   /* set idle timeout based on master connector's lp value */
>   if (dpu_enc->cur_master)
>   lp = dpu_connector_get_lp(
> @@ -941,13 +933,12 @@ static int dpu_encoder_resource_control(struct 
> drm_encoder *drm_enc,
>   else
>   idle_timeout = dpu_enc->idle_timeout;
>  
> - if (!autorefresh_enabled)
> - kthread_queue_delayed_work(
> - _thread->worker,
> - _enc->delayed_off_work,
> - msecs_to_jiffies(idle_timeout));
> + kthread_queue_delayed_work(
> + _thread->worker,
> + _enc->delayed_off_work,
> + msecs_to_jiffies(idle_timeout));
> +
>   DPU_EVT32(DRMID(drm_enc), sw_event, dpu_enc->rc_state,
> - autorefresh_enabled,
>   idle_timeout, DPU_EVTLOG_FUNC_CASE2);
>   DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work scheduled\n",
>   sw_event);
> @@ -1990,7 +1981,6 @@ static void dpu_encoder_vsync_event_handler(struct 
> timer_list *t)
>   struct drm_encoder *drm_enc = _enc->base;
>   struct msm_drm_private *priv;
>   struct msm_drm_thread *event_thread;
> - bool autorefresh_enabled = false;
>  
>   if (!drm_enc->dev || !drm_enc->dev->dev_private ||
>   !drm_enc->crtc) {
> @@ -2011,22 +2001,7 @@ static void dpu_encoder_vsync_event_handler(struct 
> timer_list *t)
>   return;
>   }
>  
> - if (dpu_enc->cur_master &&
> - dpu_enc->cur_master->ops.is_autorefresh_enabled)
> - autorefresh_enabled =
> - dpu_enc->cur_master->ops.is_autorefresh_enabled(
> - dpu_enc->cur_master);
> -
> - /*
> -   

Re: [DPU PATCH 2/6] drm/msm: remove support for ping pong split topology

[Sean Paul]

On Mon, Apr 16, 2018 at 11:22:17AM -0700, Jeykumar Sankaran wrote:
> Ping pong split topology was meant for low end soc's which
> doesn't have enough layer mixers to support split panels.
> Considering how uncommon the topology is for current chipset's and
> also to simply the driver programming, striping off the support
> for SDM845.
> 
> Signed-off-by: Jeykumar Sankaran 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  19 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 179 
> +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   5 -
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 110 +
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  21 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   5 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   2 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |  33 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |  11 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h   |   4 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  37 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   2 -
>  13 files changed, 15 insertions(+), 415 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> index 1237efc..f7e9f76 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> @@ -41,8 +41,8 @@
>   {DPU_RM_TOPOLOGY_SINGLEPIPE,"dpu_singlepipe"},
>   {DPU_RM_TOPOLOGY_DUALPIPE,  "dpu_dualpipe"},
>   {DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE,  "dpu_dualpipemerge"},
> - {DPU_RM_TOPOLOGY_PPSPLIT,   "dpu_ppsplit"},
>  };
> +
>  static const struct drm_prop_enum_list e_topology_control[] = {
>   {DPU_RM_TOPCTL_RESERVE_LOCK,"reserve_lock"},
>   {DPU_RM_TOPCTL_RESERVE_CLEAR,   "reserve_clear"},
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 516458e..8e464fa 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1914,23 +1914,6 @@ static void _dpu_crtc_setup_mixers(struct drm_crtc 
> *crtc)
>   mutex_unlock(_crtc->crtc_lock);
>  }
>  
> -static void _dpu_crtc_setup_is_ppsplit(struct drm_crtc_state *state)
> -{
> - int i;
> - struct dpu_crtc_state *cstate;
> -
> - cstate = to_dpu_crtc_state(state);
> -
> - cstate->is_ppsplit = false;
> - for (i = 0; i < cstate->num_connectors; i++) {
> - struct drm_connector *conn = cstate->connectors[i];
> -
> - if (dpu_connector_get_topology_name(conn) ==
> - DPU_RM_TOPOLOGY_PPSPLIT)
> - cstate->is_ppsplit = true;
> - }
> -}
> -
>  static void _dpu_crtc_setup_lm_bounds(struct drm_crtc *crtc,
>   struct drm_crtc_state *state)
>  {
> @@ -1993,7 +1976,6 @@ static void dpu_crtc_atomic_begin(struct drm_crtc *crtc,
>  
>   if (!dpu_crtc->num_mixers) {
>   _dpu_crtc_setup_mixers(crtc);
> - _dpu_crtc_setup_is_ppsplit(crtc->state);
>   _dpu_crtc_setup_lm_bounds(crtc, crtc->state);
>   }
>  
> @@ -2901,7 +2883,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
>  
>   mixer_width = dpu_crtc_get_mixer_width(dpu_crtc, cstate, mode);
>  
> - _dpu_crtc_setup_is_ppsplit(state);
>   _dpu_crtc_setup_lm_bounds(crtc, state);
>  
>/* get plane state for all drm planes associated with crtc state */
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 6f12355..32375b1 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -545,7 +545,6 @@ void dpu_encoder_helper_split_config(
>   struct dpu_encoder_virt *dpu_enc;
>   struct split_pipe_cfg cfg = { 0 };
>   struct dpu_hw_mdp *hw_mdptop;
> - enum dpu_rm_topology_name topology;
>   struct msm_display_info *disp_info;
>  
>   if (!phys_enc || !phys_enc->hw_mdptop || !phys_enc->parent) {
> @@ -569,8 +568,6 @@ void dpu_encoder_helper_split_config(
>   if (phys_enc->split_role == ENC_ROLE_SOLO) {
>   if (hw_mdptop->ops.setup_split_pipe)
>   hw_mdptop->ops.setup_split_pipe(hw_mdptop, );
> - if (hw_mdptop->ops.setup_pp_split)
> - hw_mdptop->ops.setup_pp_split(hw_mdptop, );
>   return;
>   }
>  
> @@ -582,29 +579,11 @@ void dpu_encoder_helper_split_config(
>   phys_enc->ops.needs_single_flush(phys_enc))
>   cfg.split_flush_en = true;
>  
> - topology = dpu_connector_get_topology_name(phys_enc->connector);
> - if (topology == 

[DPU PATCH v4 2/2] drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY

[Abhinav Kumar]

Currently the DSI PHY timings are hard-coded for a specific panel
for the 10nm PHY.

Replace this with the auto PHY timing calculator which can calculate
the PHY timings for any panel.

Changes in v4:
- None

Changes in v3:
- None

Changes in v2:
- None

Reviewed-by: Sean Paul 
Reviewed-by: Archit Taneja 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 109 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   2 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c |  28 
 3 files changed, 111 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8e9d5c2..9a9fa0c 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -265,6 +265,115 @@ int msm_dsi_dphy_timing_calc_v2(struct 
msm_dsi_dphy_timing *timing,
return 0;
 }
 
+int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing *timing,
+   struct msm_dsi_phy_clk_request *clk_req)
+{
+   const unsigned long bit_rate = clk_req->bitclk_rate;
+   const unsigned long esc_rate = clk_req->escclk_rate;
+   s32 ui, ui_x8, lpx;
+   s32 tmax, tmin;
+   s32 pcnt0 = 50;
+   s32 pcnt1 = 50;
+   s32 pcnt2 = 10;
+   s32 pcnt3 = 30;
+   s32 pcnt4 = 10;
+   s32 pcnt5 = 2;
+   s32 coeff = 1000; /* Precision, should avoid overflow */
+   s32 hb_en, hb_en_ckln;
+   s32 temp;
+
+   if (!bit_rate || !esc_rate)
+   return -EINVAL;
+
+   timing->hs_halfbyte_en = 0;
+   hb_en = 0;
+   timing->hs_halfbyte_en_ckln = 0;
+   hb_en_ckln = 0;
+
+   ui = mult_frac(NSEC_PER_MSEC, coeff, bit_rate / 1000);
+   ui_x8 = ui << 3;
+   lpx = mult_frac(NSEC_PER_MSEC, coeff, esc_rate / 1000);
+
+   temp = S_DIV_ROUND_UP(38 * coeff, ui_x8);
+   tmin = max_t(s32, temp, 0);
+   temp = (95 * coeff) / ui_x8;
+   tmax = max_t(s32, temp, 0);
+   timing->clk_prepare = linear_inter(tmax, tmin, pcnt0, 0, false);
+
+   temp = 300 * coeff - (timing->clk_prepare << 3) * ui;
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = (tmin > 255) ? 511 : 255;
+   timing->clk_zero = linear_inter(tmax, tmin, pcnt5, 0, false);
+
+   tmin = DIV_ROUND_UP(60 * coeff + 3 * ui, ui_x8);
+   temp = 105 * coeff + 12 * ui - 20 * coeff;
+   tmax = (temp + 3 * ui) / ui_x8;
+   timing->clk_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
+
+   temp = S_DIV_ROUND_UP(40 * coeff + 4 * ui, ui_x8);
+   tmin = max_t(s32, temp, 0);
+   temp = (85 * coeff + 6 * ui) / ui_x8;
+   tmax = max_t(s32, temp, 0);
+   timing->hs_prepare = linear_inter(tmax, tmin, pcnt1, 0, false);
+
+   temp = 145 * coeff + 10 * ui - (timing->hs_prepare << 3) * ui;
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 255;
+   timing->hs_zero = linear_inter(tmax, tmin, pcnt4, 0, false);
+
+   tmin = DIV_ROUND_UP(60 * coeff + 4 * ui, ui_x8) - 1;
+   temp = 105 * coeff + 12 * ui - 20 * coeff;
+   tmax = (temp / ui_x8) - 1;
+   timing->hs_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
+
+   temp = 50 * coeff + ((hb_en << 2) - 8) * ui;
+   timing->hs_rqst = S_DIV_ROUND_UP(temp, ui_x8);
+
+   tmin = DIV_ROUND_UP(100 * coeff, ui_x8) - 1;
+   tmax = 255;
+   timing->hs_exit = linear_inter(tmax, tmin, pcnt2, 0, false);
+
+   temp = 50 * coeff + ((hb_en_ckln << 2) - 8) * ui;
+   timing->hs_rqst_ckln = S_DIV_ROUND_UP(temp, ui_x8);
+
+   temp = 60 * coeff + 52 * ui - 43 * ui;
+   tmin = DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 63;
+   timing->shared_timings.clk_post =
+   linear_inter(tmax, tmin, pcnt2, 0, false);
+
+   temp = 8 * ui + (timing->clk_prepare << 3) * ui;
+   temp += (((timing->clk_zero + 3) << 3) + 11) * ui;
+   temp += hb_en_ckln ? (((timing->hs_rqst_ckln << 3) + 4) * ui) :
+   (((timing->hs_rqst_ckln << 3) + 8) * ui);
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 63;
+   if (tmin > tmax) {
+   temp = linear_inter(tmax << 1, tmin, pcnt2, 0, false);
+   timing->shared_timings.clk_pre = temp >> 1;
+   timing->shared_timings.clk_pre_inc_by_2 = 1;
+   } else {
+   timing->shared_timings.clk_pre =
+   linear_inter(tmax, tmin, pcnt2, 0, false);
+   timing->shared_timings.clk_pre_inc_by_2 = 0;
+   }
+
+   timing->ta_go = 3;
+   timing->ta_sure = 0;
+   timing->ta_get = 4;
+
+   DBG("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d",
+   timing->shared_timings.clk_pre, timing->shared_timings.clk_post,
+   timing->shared_timings.clk_pre_inc_by_2, timing->clk_zero,
+   timing->clk_trail, timing->clk_prepare, timing->hs_exit,
+   

[Bug 106110] vaapi encoding with gstreamer 1.14 doesn't work

[bugzilla-daemon]

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

--- Comment #3 from Andy Furniss  ---
FWIW I found the "nothing works" cause = the next commit in gstreamer-vaapi
after 1.14 tag =

fa77b2bf vaapiencode: h264: find best profile in those available

With that reverted the additional stream-format=byte-stream makes mkv/mp4 work
again.

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

[DPU PATCH v4 1/2] drm/msm/dsi: check video mode engine status before waiting

[Abhinav Kumar]

Make sure the video mode engine is on before waiting
for the video done interrupt.

Changes in v4:
- Move setting enabled to false earlier

Changes in v3:
- Move the return value check to another
  patch

Changes in v2:
- Replace pr_err with dev_err
- Changed error message

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7a03a94..ad5ee17 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -173,6 +173,7 @@ struct msm_dsi_host {
 
bool registered;
bool power_on;
+   bool enabled;
int irq;
 };
 
@@ -1001,7 +1002,7 @@ static void dsi_wait4video_eng_busy(struct msm_dsi_host 
*msm_host)
if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
return;
 
-   if (msm_host->power_on) {
+   if (msm_host->power_on && msm_host->enabled) {
dsi_wait4video_done(msm_host);
/* delay 4 ms to skip BLLP */
usleep_range(2000, 4000);
@@ -2203,7 +2204,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host *host)
 *  pm_runtime_put_autosuspend(_host->pdev->dev);
 * }
 */
-
+   msm_host->enabled = true;
return 0;
 }
 
@@ -2211,6 +2212,7 @@ int msm_dsi_host_disable(struct mipi_dsi_host *host)
 {
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
 
+   msm_host->enabled = false;
dsi_op_mode_config(msm_host,
!!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO), false);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [DPU PATCH 1/6] drm/msm: remove display stream compression(DSC) support for SM845

[Sean Paul]

On Mon, Apr 16, 2018 at 11:22:16AM -0700, Jeykumar Sankaran wrote:
> Upstream DSI driver doesn't support DSC panels yet. Remove
> the support for compression from DPU for now.
> 
> Signed-off-by: Jeykumar Sankaran 
> ---
>  drivers/gpu/drm/msm/Makefile   |   1 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   4 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 476 
> +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|  14 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   7 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   1 -
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   7 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  25 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  16 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 252 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 100 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|  17 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|  48 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|  22 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |  13 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |   7 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  55 ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   8 -
>  drivers/gpu/drm/msm/msm_drv.h  |  16 -
>  20 files changed, 7 insertions(+), 1084 deletions(-)
>  delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
>  delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h
> 
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 9c27991..b23a001 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -64,7 +64,6 @@ msm-y := \
>   disp/dpu1/dpu_hw_color_processing_v1_7.o \
>   disp/dpu1/dpu_hw_ctl.o \
>   disp/dpu1/dpu_hw_ds.o \
> - disp/dpu1/dpu_hw_dsc.o \
>   disp/dpu1/dpu_hw_dspp.o \
>   disp/dpu1/dpu_hw_interrupts.o \
>   disp/dpu1/dpu_hw_intf.o \
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> index 36607e3..1237efc 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
> @@ -39,12 +39,8 @@
>  static const struct drm_prop_enum_list e_topology_name[] = {
>   {DPU_RM_TOPOLOGY_NONE,  "dpu_none"},
>   {DPU_RM_TOPOLOGY_SINGLEPIPE,"dpu_singlepipe"},
> - {DPU_RM_TOPOLOGY_SINGLEPIPE_DSC,"dpu_singlepipe_dsc"},
>   {DPU_RM_TOPOLOGY_DUALPIPE,  "dpu_dualpipe"},
> - {DPU_RM_TOPOLOGY_DUALPIPE_DSC,  "dpu_dualpipe_dsc"},
>   {DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE,  "dpu_dualpipemerge"},
> - {DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE_DSC,  "dpu_dualpipemerge_dsc"},
> - {DPU_RM_TOPOLOGY_DUALPIPE_DSCMERGE, "dpu_dualpipe_dscmerge"},
>   {DPU_RM_TOPOLOGY_PPSPLIT,   "dpu_ppsplit"},
>  };
>  static const struct drm_prop_enum_list e_topology_control[] = {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> index 8756b2b..fade658 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> @@ -147,7 +147,7 @@ struct dpu_crtc_event {
>   * @num_ctls  : Number of ctl paths in use
>   * @num_mixers: Number of mixers in use
>   * @mixers_swapped: Whether the mixers have been swapped for left/right 
> update
> - *  especially in the case of DSC Merge.
> + especially in the case of DSC Merge.
>   * @mixers: List of active mixers
>   * @event : Pointer to last received drm vblank event. If there is a
>   *  pending vblank event, this will be non-null.

Unrelated change



>  static void _dpu_encoder_update_vsync_source(struct dpu_encoder_virt 
> *dpu_enc,
>   struct msm_display_info *disp_info)
>  {
> @@ -1109,102 +761,8 @@ static void _dpu_encoder_update_vsync_source(struct 
> dpu_encoder_virt *dpu_enc,
>  
>   hw_mdptop->ops.setup_vsync_source(hw_mdptop, _cfg);
>   }
> -}
> -
> -static int _dpu_encoder_dsc_disable(struct dpu_encoder_virt *dpu_enc)
> -{
> - enum dpu_rm_topology_name topology;
> - struct drm_connector *drm_conn;
> - int i, ret = 0;
> - struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
> - struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC] = {NULL};
> - int pp_count = 0;
> - int dsc_count = 0;
> -
> - if (!dpu_enc || !dpu_enc->phys_encs[0] ||
> - !dpu_enc->phys_encs[0]->connector) {
> - DPU_ERROR("invalid params %d %d\n",
> - !dpu_enc, dpu_enc ? !dpu_enc->phys_encs[0] : -1);
> - return -EINVAL;
> - }
> -
> - drm_conn = 

Re: [DPU PATCH v3 1/2] drm/msm/dsi: check video mode engine status before waiting

[abhinavk]

On 2018-04-17 13:25, Sean Paul wrote:

On Mon, Apr 16, 2018 at 06:56:45PM -0700, Abhinav Kumar wrote:

Make sure the video mode engine is on before waiting
for the video done interrupt.

Changes in v2:
- Replace pr_err with dev_err
- Changed error message

Changes in v3:
- Move the return value check to another
  patch

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c

index 7a03a94..8df0d44 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -173,6 +173,7 @@ struct msm_dsi_host {

bool registered;
bool power_on;
+   bool enabled;
int irq;
 };

@@ -1001,7 +1002,7 @@ static void dsi_wait4video_eng_busy(struct 
msm_dsi_host *msm_host)

if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
return;

-   if (msm_host->power_on) {
+   if (msm_host->power_on && msm_host->enabled) {
dsi_wait4video_done(msm_host);
/* delay 4 ms to skip BLLP */
usleep_range(2000, 4000);
@@ -2203,7 +2204,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host 
*host)

 *  pm_runtime_put_autosuspend(_host->pdev->dev);
 * }
 */
-
+   msm_host->enabled = true;
return 0;
 }

@@ -2219,7 +2220,7 @@ int msm_dsi_host_disable(struct mipi_dsi_host 
*host)

 * Reset to disable video engine so that we can send off cmd.
 */
dsi_sw_reset(msm_host);
-
+   msm_host->enabled = false;


I thought this was moving to the start of the function?


[Abhinav] Yes, my bad. While rebasing that review comment was left out.
Uploading v4 right now

return 0;
 }

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project


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

[Bug 106110] vaapi encoding with gstreamer 1.14 doesn't work

[bugzilla-daemon]

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

--- Comment #2 from Andy Furniss  ---
I was on older gits for gstreamer when I saw this around 1.13

matroska and mp4mux didn't work, but raw 264 and avimux did.

I updated to current gits before seeing the workaround and now it seems
gstreamer produces junk whatever I do :-).

-- 
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: [DPU PATCH v2 1/2] drm/msm/dsi: adjust dsi timing for dual dsi mode

[Sean Paul]

On Mon, Apr 16, 2018 at 05:40:13PM -0700, Chandan Uddaraju wrote:
> For dual dsi mode, the horizontal timing needs
> to be divided by half since both the dsi controllers
> will be driving this panel. Adjust the pixel clock and
> DSI timing accordingly.
> 
> Changes in V2:
> --Removed Change-Id from the commit text tags.

You ignored my feedback on v1

> 
> Signed-off-by: Chandan Uddaraju 
> ---
>  drivers/gpu/drm/msm/dsi/dsi.h |  1 +
>  drivers/gpu/drm/msm/dsi/dsi_host.c| 17 +
>  drivers/gpu/drm/msm/dsi/dsi_manager.c | 15 +++
>  3 files changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> index 70d9a9a..4131b47 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> @@ -161,6 +161,7 @@ void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host 
> *host,
>   u32 dma_base, u32 len);
>  int msm_dsi_host_enable(struct mipi_dsi_host *host);
>  int msm_dsi_host_disable(struct mipi_dsi_host *host);
> +void msm_dsi_host_adjust_timing_config(struct mipi_dsi_host *host);
>  int msm_dsi_host_power_on(struct mipi_dsi_host *host,
>   struct msm_dsi_phy_shared_timings *phy_shared_timings);
>  int msm_dsi_host_power_off(struct mipi_dsi_host *host);
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 7a03a94..66a21cb 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -2237,6 +2237,23 @@ static void msm_dsi_sfpb_config(struct msm_dsi_host 
> *msm_host, bool enable)
>   SFPB_GPREG_MASTER_PORT_EN(en));
>  }
>  
> +void msm_dsi_host_adjust_timing_config(struct mipi_dsi_host *host)
> +{
> + struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
> + struct drm_display_mode *mode = NULL;
> +
> + mode = msm_host->mode;
> +
> + mutex_lock(_host->dev_mutex);
> + mode->htotal >>= 1;
> + mode->hdisplay >>= 1;
> + mode->hsync_start >>= 1;
> + mode->hsync_end >>= 1;
> +
> + mode->clock >>= 1;
> + mutex_unlock(_host->dev_mutex);
> +}
> +
>  int msm_dsi_host_power_on(struct mipi_dsi_host *host,
>   struct msm_dsi_phy_shared_timings *phy_shared_timings)
>  {
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
> b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> index 4cb1cb6..8ef1c3d 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> @@ -627,6 +627,21 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge 
> *bridge,
>   msm_dsi_host_set_display_mode(host, adjusted_mode);
>   if (is_dual_dsi && other_dsi)
>   msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode);
> +
> + /*
> +  * For dual DSI mode, the current DRM mode has
> +  * the complete width of the panel. Since, the complete
> +  * panel is driven by two DSI controllers, the
> +  * horizontal timings and the pixel clock have to be
> +  * split between the two dsi controllers. Adjust the
> +  * DSI host timing structures accordingly.
> +  */
> + if (is_dual_dsi) {
> + msm_dsi_host_adjust_timing_config(host);
> + if (other_dsi)
> + msm_dsi_host_adjust_timing_config(other_dsi->host);
> + }
> +
>  }
>  
>  static const struct drm_connector_funcs dsi_mgr_connector_funcs = {
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

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

Re: [DPU PATCH v3 1/2] drm/msm/dsi: check video mode engine status before waiting

[Sean Paul]

On Mon, Apr 16, 2018 at 06:56:45PM -0700, Abhinav Kumar wrote:
> Make sure the video mode engine is on before waiting
> for the video done interrupt.
> 
> Changes in v2:
> - Replace pr_err with dev_err
> - Changed error message
> 
> Changes in v3:
> - Move the return value check to another
>   patch
> 
> Signed-off-by: Abhinav Kumar 
> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 7a03a94..8df0d44 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -173,6 +173,7 @@ struct msm_dsi_host {
>  
>   bool registered;
>   bool power_on;
> + bool enabled;
>   int irq;
>  };
>  
> @@ -1001,7 +1002,7 @@ static void dsi_wait4video_eng_busy(struct msm_dsi_host 
> *msm_host)
>   if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
>   return;
>  
> - if (msm_host->power_on) {
> + if (msm_host->power_on && msm_host->enabled) {
>   dsi_wait4video_done(msm_host);
>   /* delay 4 ms to skip BLLP */
>   usleep_range(2000, 4000);
> @@ -2203,7 +2204,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host *host)
>*  pm_runtime_put_autosuspend(_host->pdev->dev);
>* }
>*/
> -
> + msm_host->enabled = true;
>   return 0;
>  }
>  
> @@ -2219,7 +2220,7 @@ int msm_dsi_host_disable(struct mipi_dsi_host *host)
>* Reset to disable video engine so that we can send off cmd.
>*/
>   dsi_sw_reset(msm_host);
> -
> + msm_host->enabled = false;

I thought this was moving to the start of the function?

>   return 0;
>  }
>  
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #34 from MirceaKitsune  ---
(In reply to iive from comment #33)

Ahhh... you've reminded me of a detail that I have in fact noticed but forgot
to mention: After the machine freezes and becomes completely unresponsive, some
keyboard leds will indeed turn off after roughly 10 seconds. I only noticed
this because I currently have a backlit keyboard that has the lighting
controlled by the Scroll Lock LED... I saw that a few seconds after the crash,
the keyboard lighting always turns itself off.

I cannot connect the computers with a serial cable: I think the motherboards
are too modern to have a serial port, and they're at a far distance in opposite
rooms. Both computers are connected to the same home router via LAN cables
though, and can communicate through local IP... so net console sounds like a
good idea, but I've never heard of it before so I'll have to look this up.

Your sysrq suggestion seems to have worked! I first did this:

echo 1 > /proc/sys/kernel/sysrq

Then I pressed 'Alt + PrintScreen + H'. Now dmesg shows me:

[265102.938475] sysrq: SysRq : HELP : loglevel(0-9) reboot(b) crash(c)
terminate-all-tasks(e) memory-full-oom-kill(f) kill-all-tasks(i)
thaw-filesystems(j) sak(k) show-backtrace-all-active-cpus(l)
show-memory-usage(m) nice-all-RT-tasks(n) poweroff(o) show-registers(p)
show-all-timers(q) unraw(r) sync(s) show-task-states(t) unmount(u) force-fb(V)
show-blocked-tasks(w) dump-ftrace-buffer(z)

I assume that after the crash, I should first use it to test REISUB?

And here is the output of the kernel features you said to check. If they're not
there, I'm out of luck on this one, as I don't know how to compile my own
kernel and can't risk breaking my machine with dangerous tests.

mircea@linux-qz0r:~> zgrep CONFIG_NETCONSOLE /proc/config.gz
CONFIG_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
mircea@linux-qz0r:~> zgrep SERIAL_8250_CONSOLE /proc/config.gz
CONFIG_SERIAL_8250_CONSOLE=y

Lastly I'll try glxgears without vsync for a few hours in the next days: I have
to leave my computer locked while I'm away from home or sleeping, but can leave
it on for roughly 3 hours of the day while I'm around but AFK. I should note
that I tried running Xonotic without vsync, and that seems to have made
absolutely no difference. Also this likely isn't network related, I always test
in a local match with bots and not online multiplayer.

-- 
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 106110] vaapi encoding with gstreamer 1.14 doesn't work

[bugzilla-daemon]

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

Christoph Haag  changed:

   What|Removed |Added

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

--- Comment #1 from Christoph Haag  ---
remco on #radeon figured out that it works when adding
stream-format=byte-stream to the video format, like this:

gst-launch-1.0 videotestsrc ! vaapih264enc !
"video/x-h264,profile=baseline,stream-format=byte-stream" ! h264parse !
matroskamux ! filesink location=output.mkv

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

Re: [PATCH 1/2 v2] drm/pl111: Support the Versatile Express

[Linus Walleij]

On Tue, Apr 17, 2018 at 3:12 PM, Robin Murphy  wrote:
> On 17/04/18 13:32, Linus Walleij wrote:
> [...]
>>
>> Unfortunately there is just one single vexpress core tile in the
>> upstream kernel that define a CLCD controller, the CA9 (4xA9)
>> that I am using. All the others just use the MB CLCD.
>>
>> I am thinking there is some never finished DTS upstreaming
>> here that ought to happen so we use the core tile CLCD on some
>> other boards as well.
>
>
> Barring custom FPGA images, I think V2P-CA9 *is* the only VExpress tile
> implementing PL11x; all the more recent test chips had HDLCD instead.

Yup it looks like that.

I am restructuring the code to look for any graphics on the
core tile and only turn on the motherboard CLCD if there is
no CLCD or HDLCD on the core tile, e.g. if that device node has
been set to "disabled" or the HDLCD driver is not compiled in
but the CLCD driver is.

I found some vague mentions of a LCD display that can be
connected to the motherboard, so that would then be sitting
on the CLCD, is this something you ARM guys have seen
around? In that case I guess the VExpress (etc) would actually
be able to have two screens, one LCD panel on the motherboard
CLCD and a DVI from the core tile.

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #33 from i...@yahoo.com ---
This doesn't sound good.
The sshd dying indicates that the kernel or the CPU has hang. If there is GPU
shader hang this doesn't happen right away, it usually waits 10 seconds before
attempting to reset the GPU and then panics.


1. When the system hangs, do you see LEDs on the keyboard flashing?
When kernel panics this is how it signals it. You might need to wait for 10
seconds or minute...

2. It seems that OpenSuse disables "sysrq", google told me that 
"You can enable it in YaST->Security and Users->Security Center and
Hardening..."
Alternatively you should be able to enable it with executing this as root:
  echo 1 >  /proc/sys/kernel/sysrq

Check if it works with "Alt+PrtScr+h", it should display help message in
`dmesg` .

3. After you have sysrq working, try to reproduce the crash, (without
apitrace).
This is to check if sysrq is working at all during hang and if it does then
hopefully getting a kernel panic message in the log.

4. If you cannot get crash messages in the logs/journal, then you might to use
`serial console` or `netconsole`.
The Serial console is best option, if both computers have their own serial
ports and you happen to have a serial cable to connect them.
linux-source/Documentation/admin-guide/serial-console.rst

Otherwise you might try network console logger, that sends UDP packets to the
second computer.
linux-source/Documentation/networking/netconsole.txt

Setting up these might be tricky, as they might not even be compiled in the
stock kernel. So if you need detailed instructions, at least check if they are
present as modules or built-in the kernel.
zgrep CONFIG_NETCONSOLE /proc/config.gz
zgrep SERIAL_8250_CONSOLE /proc/config.gz

5. Disable vsync and run `glxgears` for hours. Leave it to work through the
night or something.
I just want to know if your computer hangs with that simple 3D.
vblank_mode=1 glxgears

---

Let me be clear.
I want to see the crash messages for only 2 reasons:
 - To see that there is a kernel crash.
 - To see if the crash is in the graphics stack.

Since the `sshd` stops working, it might be network-card crash. (Multiplayer
games, using network...)

If the machine just hangs, without actual kernel crash... then it might be
hardware problem, but not a graphic card, it might also be MB, CPU, PSU, RAM,
etc...

-- 
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 2/2 v2] drm/pl111: Enable device-specific assigned memory

[Eric Anholt]

Linus Walleij  writes:

> On Sun, Apr 8, 2018 at 3:08 AM, Eric Anholt  wrote:
>
>>>   if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
>>>>memory_bw)) {
>>>   dev_info(dev, "no max memory bandwidth specified, assume 
>>> unlimited\n");
>>> @@ -275,7 +280,8 @@ static int pl111_amba_probe(struct amba_device 
>>> *amba_dev,
>>>   priv->regs = devm_ioremap_resource(dev, _dev->res);
>>>   if (IS_ERR(priv->regs)) {
>>>   dev_err(dev, "%s failed mmio\n", __func__);
>>> - return PTR_ERR(priv->regs);
>>> + ret = PTR_ERR(priv->regs);
>>> + goto mem_rel;
>>>   }
>>
>> Shouldn't this error path be jumping to dev_unref, as well?  We're
>> trying to match drm_dev_alloc(), right?
>
> OK I fixed.
>
>> I'm still a little bothered that we're allowing imports to pl111 of CMA
>> buffers that we can't scan out.  Could we just refuse all
>> .gem_prime_import*() on this platform?
>
> I am sorry but I do not understand how CMA, dmabuf and GEM play
> together to decode this and figure out what to do.
>
> Do you mean that if we find device assigned memory, i.e. that there
> is this special memory which is all the controller can scan out,
> I should just implement .gem_prime_impport() instead of the
> currently assigned drm_gem_prime_import() to something just
> returning return ERR_PTR(-EINVAL); so it always fails?
>
> What about .gem_prime_import_sg_table()? Exporting should
> work fine since the memory is always readable by CPU.

Oh, I think you still want drm_gem_prime_import()'s path for "I'm
importing an fd from this same driver to into another process".  So,
yeah, have our .import_sg_table hook throw -EINVAL if called on the
device memory platform, and otherwise call down to
drm_gem_cma_prime_import_sg_table().


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

Re: [PATCH v2 1/3] drm/prime: Iterate SG DMA addresses separately

[Deucher, Alexander]

+ Suravee


From: Robin Murphy 
Sent: Tuesday, April 17, 2018 2:22:46 PM
To: Koenig, Christian; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Cc: ok...@codeaurora.org; Deucher, Alexander
Subject: Re: [PATCH v2 1/3] drm/prime: Iterate SG DMA addresses separately

On 17/04/18 17:29, Christian König wrote:
> Am 17.04.2018 um 17:58 schrieb Robin Murphy:
>> For dma_map_sg(), DMA API implementations are free to merge consecutive
>> segments into a single DMA mapping if conditions are suitable, thus the
>> resulting DMA addresses which drm_prime_sg_to_page_addr_arrays()
>> iterates may be packed into fewer entries than ttm->sg->nents implies.
>>
>> The current implementation does not account for this, meaning that its
>> callers either have to reject the 0 < count < nents case or risk getting
>> bogus DMA addresses beyond the first segment. Fortunately this is quite
>> easy to handle without having to rejig structures to also store the
>> mapped count, since the total DMA length should still be equal to the
>> total buffer length. All we need is a second scatterlist cursor to
>> iterate through the DMA addresses independently of the page addresses.
>>
>> Signed-off-by: Robin Murphy 
>
> Reviewed-by: Christian König  for the whole
> series.

Thanks Christian.

FWIW, the following *completely untested* hack should in theory give the
AMD IOMMU similar segment-merging behaviour to the arm64 IOMMU DMA ops,
if that helps widen the scope for testing/investigation (I have neither
an AMD/ATI graphics card nor a PCIe-capable arm64 box to hand just at
the moment).

Robin.

->8-
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 2a99f0f14795..60b0e495b567 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2489,11 +2489,11 @@ static int map_sg(struct device *dev, struct
scatterlist *sglist,
   int nelems, enum dma_data_direction direction,
   unsigned long attrs)
  {
-   int mapped_pages = 0, npages = 0, prot = 0, i;
+   int mapped_pages = 0, npages = 0, prot = 0, i, count;
 struct protection_domain *domain;
 struct dma_ops_domain *dma_dom;
-   struct scatterlist *s;
-   unsigned long address;
+   struct scatterlist *s, *d;
+   unsigned long address, max_seg;
 u64 dma_mask;

 domain = get_domain(dev);
@@ -2535,7 +2535,28 @@ static int map_sg(struct device *dev, struct
scatterlist *sglist,
 s->dma_length   = s->length;
 }

-   return nelems;
+   d = sglist;
+   max_seg = dma_get_max_seg_size(dev);
+   count = 1;
+   nelems -= 1;
+   for_each_sg(sg_next(sglist), s, nelems, i) {
+   dma_addr_t s_dma_addr = s->dma_address;
+   unsigned int s_dma_len = s->dma_length;
+
+   s->dma_address = 0;
+   s->dma_length = 0;
+   if (s_dma_addr == d->dma_address + d->dma_length &&
+   d->dma_length + s_dma_len <= max_seg) {
+   d->dma_length += s_dma_len;
+   } else {
+   d = sg_next(d);
+   d->dma_address = s_dma_addr;
+   d->dma_length = s_dma_len;
+   count++;
+   }
+   }
+
+   return count;

  out_unmap:
 pr_err("%s: IOMMU mapping error in map_sg (io-pages: %d)\n",
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm/prime: Iterate SG DMA addresses separately

[Robin Murphy]

On 17/04/18 17:29, Christian König wrote:

Am 17.04.2018 um 17:58 schrieb Robin Murphy:

For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses which drm_prime_sg_to_page_addr_arrays()
iterates may be packed into fewer entries than ttm->sg->nents implies.

The current implementation does not account for this, meaning that its
callers either have to reject the 0 < count < nents case or risk getting
bogus DMA addresses beyond the first segment. Fortunately this is quite
easy to handle without having to rejig structures to also store the
mapped count, since the total DMA length should still be equal to the
total buffer length. All we need is a second scatterlist cursor to
iterate through the DMA addresses independently of the page addresses.

Signed-off-by: Robin Murphy 


Reviewed-by: Christian König  for the whole 
series.


Thanks Christian.

FWIW, the following *completely untested* hack should in theory give the 
AMD IOMMU similar segment-merging behaviour to the arm64 IOMMU DMA ops, 
if that helps widen the scope for testing/investigation (I have neither 
an AMD/ATI graphics card nor a PCIe-capable arm64 box to hand just at 
the moment).


Robin.

->8-
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 2a99f0f14795..60b0e495b567 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2489,11 +2489,11 @@ static int map_sg(struct device *dev, struct 
scatterlist *sglist,

  int nelems, enum dma_data_direction direction,
  unsigned long attrs)
 {
-   int mapped_pages = 0, npages = 0, prot = 0, i;
+   int mapped_pages = 0, npages = 0, prot = 0, i, count;
struct protection_domain *domain;
struct dma_ops_domain *dma_dom;
-   struct scatterlist *s;
-   unsigned long address;
+   struct scatterlist *s, *d;
+   unsigned long address, max_seg;
u64 dma_mask;

domain = get_domain(dev);
@@ -2535,7 +2535,28 @@ static int map_sg(struct device *dev, struct 
scatterlist *sglist,

s->dma_length   = s->length;
}

-   return nelems;
+   d = sglist;
+   max_seg = dma_get_max_seg_size(dev);
+   count = 1;
+   nelems -= 1;
+   for_each_sg(sg_next(sglist), s, nelems, i) {
+   dma_addr_t s_dma_addr = s->dma_address;
+   unsigned int s_dma_len = s->dma_length;
+
+   s->dma_address = 0;
+   s->dma_length = 0;
+   if (s_dma_addr == d->dma_address + d->dma_length &&
+   d->dma_length + s_dma_len <= max_seg) {
+   d->dma_length += s_dma_len;
+   } else {
+   d = sg_next(d);
+   d->dma_address = s_dma_addr;
+   d->dma_length = s_dma_len;
+   count++;
+   }
+   }
+
+   return count;

 out_unmap:
pr_err("%s: IOMMU mapping error in map_sg (io-pages: %d)\n",
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel

[abhinavk]

Hi Bjorn

Thanks for the comments.

Reply inline.

On 2018-04-16 23:13, Bjorn Andersson wrote:

On Mon 16 Apr 15:45 PDT 2018, abhin...@codeaurora.org wrote:


Hi Bjorn

Thanks for the review.

Reply inline.

On 2018-04-16 09:41, Bjorn Andersson wrote:
> On Sat 14 Apr 00:25 PDT 2018, Abhinav Kumar wrote:
>
> > Register truly panel as a backlight led device and
> > provide methods to control its backlight operation.
> >
> > Changes in v2:
> > - Removed redundant NULL checks
> > - Arranged headers alphabetically
> > - Formatting fixes
>
> The change log goes below the "---" line.
>
[Abhinav] As sean mentioned, its quite common to list it to view it in 
the

log.
This practice has been followed by quite a few in DRM
Another reference here https://patchwork.freedesktop.org/patch/211361/



If that's the practice in DRM land, then that's what you should do.


> >
> > Signed-off-by: Abhinav Kumar 
> > ---
> [..]
> > +static int truly_backlight_setup(struct truly_wqxga *ctx)
> > +{
> > + struct backlight_properties props;
> > + char bl_node_name[BL_NODE_NAME_SIZE];
> > +
> > + if (!ctx->backlight) {
> > + memset(, 0, sizeof(props));
> > + props.type = BACKLIGHT_RAW;
> > + props.power = FB_BLANK_UNBLANK;
> > + props.max_brightness = 4096;
> > +
> > + snprintf(bl_node_name, BL_NODE_NAME_SIZE, "panel%u-backlight",
> > +  PRIM_DISPLAY_NODE);
> > +
> > + ctx->backlight =  backlight_device_register(bl_node_name,
> > + ctx->dev, ctx,
> > + _backlight_device_ops, );
> > +
> > + if (IS_ERR_OR_NULL(ctx->backlight)) {
> > + pr_err("Failed to register backlight\n");
> > + ctx->backlight = NULL;
> > + return -ENODEV;
> > + }
> > +
> > + /* Register with the LED driver interface */
> > + led_trigger_register_simple("bkl-trigger", >wled);
> > +
> > + if (!ctx->wled) {
> > + pr_err("backlight led registration failed\n");
> > + return -ENODEV;
> > + }
>
> It seems like you're registering a backlight driver for the sake of
> invoking the LED backlight trigger to control the WLED.
>
> The WLED is a backlight driver, so all you should have to do is add the
> following line to your probe:
>
>ctx->backlight = devm_of_find_backlight(dev);
>
> and then add "backlight = <>" to your dt node.
>
> Regards,
> Bjorn
[Abhinav] Thats not the only purpose of backlight_device_register().
We want to hook up our panel with the parent backlight driver in
drivers/video/backlight/backlight.c and also route all the
update_backlight_status()
calls through the sysfs of the newly registered node.

The of_find_backlight() method doesnt seem to allow us to register our 
own

sysfs method.



Are you saying that you want to be able to create an alias for the wled
entry already in /sys/class/backlight named panel0-backlight?


BTW, this isnt something which we are doing uniquely.
There are other panels which seem to be doing this :

drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c



What seems to be going on in the s6e3ha2 driver is that the hardware 
has

some sort of builtin backlight control, so the driver is creating a
backlight driver for the purpose of exposing those controls.


Can you please comment on whether we can have our own sysfs without
the device_register()?



If the panel isn't actually a piece of backlight hardware then it 
should

not register a backlight device. Why do you need your own sysfs?

Regards,
Bjorn

[Abhinav] This particular panel isnt a piece of backlight hardware.
But, we want to have our own sysfs to give flexibility to our userspace
to write and read stuff for its proprietary uses.
Thats how our downstream has been working so far and hence to maintain
the compatibility would like to have it.

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

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

[Bug 106110] vaapi encoding with gstreamer 1.14 doesn't work

[bugzilla-daemon]

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

Bug ID: 106110
   Summary: vaapi encoding with gstreamer 1.14 doesn't work
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: haa...@frickel.club
QA Contact: dri-devel@lists.freedesktop.org

It could also be a gstreamer-vaapi bug since it happens only since gstreamer
1.14, but I have seen nobody else complain anywhere, so it must work for some
people at least.

RX 480, recent mesa git revisions, Linux 4.15 - drm-next-4.18-wip

To test:
gst-launch-1.0 videotestsrc ! vaapih264enc ! "video/x-h264,profile=baseline" !
h264parse ! matroskamux ! filesink location=output.mkv

With gstreamer 1.14 this never starts encoding and produces a 0 byte file when
cancelling with ctrl+c.

With gstreamer 1.12.4 it worked fine.

-- 
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 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

[bugzilla-daemon]

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

--- Comment #18 from Harry Wentland  ---
Please keep one issue per ticket. Open a new ticket if needed.

That said, a fix for the flickering issue should be in drm-next-4.17 of Alex's
git repo at https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.17 and
should make it into Linus's tree from there.

That fix should also make it into 4.16 stable.

-- 
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 RFC] drm: Add ASPEED GFX driver

[Eric Anholt]

Joel Stanley  writes:

> This driver is for the ASPEED BMC SoC's GFX display hardware. This
> driver runs on the ARM based BMC systems, unlike the ast driver which
> runs on a host CPU and is is for a PCIe graphics device that happens to
> live in the BMC's silicon, but is otherwise available for use by the BMC.
>
> The AST2500 supports a total of 3 output paths:
>
>   1. VGA output (aka host PCIe graphics device), the output target can
>   choose either or both to the DAC or DVO interface.
>
>   2. Graphics CRT output, the output target can choose either or both to
>   the DAC or DVO interface.
>
>   3. Video input from DVO, the video input can be used for video engine
>   capture or DAC display output.
>
> Output options for are selected in SCU2C. This must be toggled by the
> BMC in order to select between the host and BMC's display output.
>
> The "VGA mode" device is the PCI attached controller. The "Graphics CRT"
> is the BMC's internal display controller.
>
> This driver only supports a simple configuration consisting of a 40MHz
> pixel clock (fixed by hardware limitations) and the VGA output path.

The confusing part of this driver to me is understanding where this
display output is going -- if you're going out a VGA connector to a
monitor (is that what "DAC" meant?), we ought to have
DRM_MODE_CONNECTOR_VGA and a .get_modes that does I2C to get the EDID.
If it's fed into the input of some other display controller, then I'm
not sure what's the right thing to do.

I'd recommend moving some of this commit message into kerneldoc in the
_drv.c explaining what the HW does and what parts of the HW the driver
exposes.

> Signed-off-by: Joel Stanley 
> ---
>
> Hello!
>
> This driver is working on hardware, with a few oddities. The things that
> I know need cleaning up are:
>
>  - clocks: The device can source a clock from three different sources,
>but they depend on the configuration of other devices in the system
>(the USB PHY and the 'host' display controller). For this reason we
>limit the driver to the 40MHz pixel clock that comes from the USB
>PHY.

You may want to look into setting up a little mux clock provider that
can source from whatever parents are available to get you the best,
faster-than-requested clock.  Then, if the rate it gives you is too far
off from what you wanted, maybe stretch the hblank intervals of your
modeline to get as close to the target vrefresh as possible (check out
vc4_dsi.c:vc4_dsi_encoder_mode_fixup() for an example of doing this)

>  - Setting an initial mode. I can only get the system to output when
>running X. fbset and fb-test can't seem to do this on their own. The
>system this is being developed for intends to run a simple fbterm
>based application, so this needs fixing.

Not sure what would be going on here.  You do have all of the DRM FB
emulation bits enabled, right?

> I wanted to get feedback on the way the driver is structured, and if
> possible a some advice on why fb tools can't set a mode themselves.

drm_simple_display_pipe seems like a good way to get started.
Eventually to merge you'll need a DT binding document
(Documentation/devicetree/bindings/display)

> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx.h 
> b/drivers/gpu/drm/aspeed/aspeed_gfx.h
> new file mode 100644
> index ..fb56e425bd48
> --- /dev/null
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx.h
> @@ -0,0 +1,104 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright 2018 IBM Corporation
> +
> +#include 
> +#include 
> +
> +struct aspeed_gfx {
> + void __iomem*base;
> + struct clk  *clk;
> + struct reset_control*rst;
> + struct regmap   *scu;
> +
> + struct drm_simple_display_pipe  pipe;
> + struct drm_connectorconnector;
> + struct drm_fbdev_cma*fbdev;
> +};
> +
> +int aspeed_gfx_create_pipe(struct drm_device *drm);
> +int aspeed_gfx_create_output(struct drm_device *drm);
> +
> +#define CRT_CTRL10x60 /* CRT Control I */
> +#define CRT_CTRL20x64 /* CRT Control II */
> +#define CRT_STATUS   0x68 /* CRT Status */
> +#define CRT_MISC 0x6c /* CRT Misc Setting */
> +#define CRT_HORIZ0   0x70 /* CRT Horizontal Total & Display Enable 
> End */
> +#define CRT_HORIZ1   0x74 /* CRT Horizontal Retrace Start & End */
> +#define CRT_VERT00x78 /* CRT Vertical Total & Display Enable End 
> */
> +#define CRT_VERT10x7C /* CRT Vertical Retrace Start & End */
> +#define CRT_ADDR 0x80 /* CRT Display Starting Address */
> +#define CRT_OFFSET   0x84 /* CRT Display Offset & Terminal Count */
> +#define CRT_THROD0x88 /* CRT Threshold */
> +#define CRT_XSCALE   0x8C /* CRT Scaling-Up Factor */
> +#define CRT_CURSOR0  0x90 /* CRT Hardware Cursor X & Y Offset */
> +#define CRT_CURSOR1  0x94 /* CRT 

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

[bugzilla-daemon]

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

--- Comment #22 from Harry Wentland  ---
Please keep one issue per ticket. Open a new ticket if needed.

That said, a fix for the flickering issue should be in drm-next-4.17 of Alex's
git repo at https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.17 and
should make it into Linus's tree from there.

That fix should also make it into 4.16 stable.

-- 
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 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

[bugzilla-daemon]

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

--- Comment #16 from Harry Wentland (harry.wentl...@amd.com) ---
A fix should be in drm-next-4.17 of Alex's git repo at
https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.17 and should make it
into Linus's tree from there.

That fix should also make it into 4.16 stable.

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

[Bug 105083] Random blinking display

[bugzilla-daemon]

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

Harry Wentland  changed:

   What|Removed |Added

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

--- Comment #18 from Harry Wentland  ---
A fix should be in drm-next-4.17 of Alex's git repo at
https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.17

That fix should also make it into 4.16 stable.

White color fix with redshift/nightshift should also be in that branch.

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

Re: [PATCH] drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state

[Ville Syrjälä]

On Mon, Apr 16, 2018 at 06:53:09PM +0300, Imre Deak wrote:
> LSPCON adapters in low-power state may ignore the first I2C write during
> TMDS output buffer enabling, resulting in a blank screen even with an
> otherwise enabled pipe. Fix this by reading back and validating the
> written value a few times.
> 
> The problem was noticed on GLK machines with an onboard LSPCON adapter
> after entering/exiting DC5 power state. Doing an I2C read of the adapter
> ID as the first transaction - instead of the I2C write to enable the
> TMDS buffers - returns the correct value. Based on this we assume that
> the transaction itself is sent properly, it's only the adapter that is
> not ready for some reason to accept this first write after waking from
> low-power state. In my case the second I2C write attempt always
> succeeded.

Yeah, I guess this is an OK approach. Probably not much point in
optimizing the non-LSPCON case since this is modeset stuff,
although we do have the adaptor type passed in so we could if we
wanted to.

Reviewed-by: Ville Syrjälä 

> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105854
> Cc: Clinton Taylor 
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 39 
> +--
>  1 file changed, 32 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> index 02a50929af67..e7f4fe2848a5 100644
> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -350,19 +350,44 @@ int drm_dp_dual_mode_set_tmds_output(enum 
> drm_dp_dual_mode_type type,
>  {
>   uint8_t tmds_oen = enable ? 0 : DP_DUAL_MODE_TMDS_DISABLE;
>   ssize_t ret;
> + int retry;
>  
>   if (type < DRM_DP_DUAL_MODE_TYPE2_DVI)
>   return 0;
>  
> - ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
> -  _oen, sizeof(tmds_oen));
> - if (ret) {
> - DRM_DEBUG_KMS("Failed to %s TMDS output buffers\n",
> -   enable ? "enable" : "disable");
> - return ret;
> + /*
> +  * LSPCON adapters in low-power state may ignore the first write, so
> +  * read back and verify the written value a few times.
> +  */
> + for (retry = 0; retry < 3; retry++) {
> + uint8_t tmp;
> +
> + ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_TMDS_OEN,
> +  _oen, sizeof(tmds_oen));
> + if (ret) {
> + DRM_DEBUG_KMS("Failed to %s TMDS output buffers (%d 
> attempts)\n",
> +   enable ? "enable" : "disable",
> +   retry + 1);
> + return ret;
> + }
> +
> + ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_TMDS_OEN,
> + , sizeof(tmp));
> + if (ret) {
> + DRM_DEBUG_KMS("I2C read failed during TMDS output 
> buffer %s (%d attempts)\n",
> +   enable ? "enabling" : "disabling",
> +   retry + 1);
> + return ret;
> + }
> +
> + if (tmp == tmds_oen)
> + return 0;
>   }
>  
> - return 0;
> + DRM_DEBUG_KMS("I2C write value mismatch during TMDS output buffer %s\n",
> +   enable ? "enabling" : "disabling");
> +
> + return -EIO;
>  }
>  EXPORT_SYMBOL(drm_dp_dual_mode_set_tmds_output);
>  
> -- 
> 2.13.2

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

Re: [PATCH hwc v2 17/18] drm_hwcomposer: Flatten scene synchronously

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:28PM +0100, Alexandru Gheorghe wrote:
> Flatten scene on the same CRTC as the one driving the display.
> The active composition is played back to the display with a buffer
> attached to the writeback connector.
> Then we build a composition that has only one plane enabled and that
> uses the result of the writeback as the input.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmdisplaycompositor.cpp | 203 
> +--
>  drmdisplaycompositor.h   |   7 +-
>  2 files changed, 204 insertions(+), 6 deletions(-)
> 
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index e535e8a..cb670e6 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -36,6 +36,7 @@
>  #include "drmplane.h"
>  #include "drmresources.h"
>  #include "glworker.h"
> +static const uint32_t kWaitWritebackFence = 100;  // ms
>  
>  namespace android {
>  
> @@ -523,7 +524,9 @@ int 
> DrmDisplayCompositor::PrepareFrame(DrmDisplayComposition *display_comp) {
>  }
>  
>  int DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
> -  bool test_only) {
> +  bool test_only,
> +  DrmDisplayComposition *writeback_comp,
> +  DrmConnector *writeback_conn) {
>ATRACE_CALL();
>  
>int ret = 0;
> @@ -532,6 +535,7 @@ int 
> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>std::vector _planes =
>display_comp->composition_planes();
>uint64_t out_fences[drm_->crtcs().size()];
> +  int writeback_fence = -1;
>  
>DrmConnector *connector = drm_->GetConnectorForDisplay(display_);
>if (!connector) {
> @@ -550,9 +554,37 @@ int 
> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>  return -ENOMEM;
>}
>  
> +  if (writeback_comp != NULL) {
> +if (writeback_conn == NULL)
> +  return -EINVAL;
> +if (writeback_conn->writeback_fb_id().id() == 0 ||
> +writeback_conn->writeback_out_fence().id() == 0) {
> +  ALOGE("Writeback properties don't exit");
> +  return -EINVAL;
> +}
> +if (writeback_comp->layers().size() != 1) {
> +  ALOGE("Invalid number of layers for writeback composition");
> +  return -EINVAL;
> +}
> +ret = drmModeAtomicAddProperty(
> +pset, writeback_conn->id(), writeback_conn->writeback_fb_id().id(),
> +writeback_comp->layers().back().buffer->fb_id);
> +if (ret < 0) {
> +  ALOGE("Failed to add writeback_fb_id");
> +  return ret;
> +}
> +ret = drmModeAtomicAddProperty(pset, writeback_conn->id(),
> +   
> writeback_conn->writeback_out_fence().id(),
> +   (uint64_t)_fence);

Upcasting int to u64 isn't a great idea, please go the other way (as we do with
out_fences).

> +if (ret < 0) {
> +  ALOGE("Failed to add writeback_out_fence");
> +  return ret;
> +}
> +  }

This would be more readable if it was split off into a function.

>if (crtc->out_fence_ptr_property().id() != 0) {
> -ret = drmModeAtomicAddProperty(pset, crtc->id(), 
> crtc->out_fence_ptr_property().id(),
> -   (uint64_t) _fences[crtc->pipe()]);
> +ret = drmModeAtomicAddProperty(pset, crtc->id(),
> +   crtc->out_fence_ptr_property().id(),
> +   (uint64_t)_fences[crtc->pipe()]);
>  if (ret < 0) {
>ALOGE("Failed to add OUT_FENCE_PTR property to pset: %d", ret);
>drmModeAtomicFree(pset);
> @@ -580,6 +612,15 @@ int 
> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>  }
>}
>  
> +  if (writeback_conn != NULL) {
> +ret = drmModeAtomicAddProperty(pset, writeback_conn->id(),
> +   writeback_conn->crtc_id_property().id(),
> +   crtc->id());
> +if (ret < 0) {
> +  ALOGE("Failed to  attach writeback");
> +}
> +  }

Can you do this above with the rest of the writeback properties?

> +
>for (DrmCompositionPlane _plane : comp_planes) {
>  DrmPlane *plane = comp_plane.plane();
>  DrmCrtc *crtc = comp_plane.crtc();
> @@ -729,8 +770,18 @@ int 
> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>  
>if (!ret) {
>  uint32_t flags = DRM_MODE_ATOMIC_ALLOW_MODESET;
> -if (test_only)
> +if (test_only) {
>flags |= DRM_MODE_ATOMIC_TEST_ONLY;
> +} else {
> +  if (writeback_comp != NULL) {
> +if (!CountdownExpired() && active_composition_) {

Given that we're holding the lock throughout this function, can't you just
abort at the start?

> +  ALOGE("Writeback composition not needed, abort commit");
> +  drmModeAtomicFree(pset);
> +  return -EINVAL;
> 

Re: [Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Tue, Apr 17, 2018 at 10:45:07AM +0530, Nautiyal, Ankit K wrote:
> 
> On 4/6/2018 11:14 PM, Ville Syrjälä wrote:
> > On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote:
> >> This patch is causing failure of IGT test kms_3d. The kms_3d test
> >> expects the no. of 3d modes to be 13.
> >>
> >> (The test has hard-coded value for expected no. of 3d modes as 13)
> >>
> >> But due to the addition of "matching aspect_ratio" in drm_mode_equal in
> >> this patch, the total no. of
> >>
> >> modes in the connector modelist is increased by 2, resulting in failure
> >> of assertion 'mode_count==13'.
> > If kms_3d isn't setting the aspect ratio cap how is it affected by these
> > changes?
> In drm_mode.c, the drm_mode_connector_list_update() uses drm_mode_equal,
> to remove duplicate modes in connector_modes from the 
> connector->probe_modes.
> Earlier, it wasn't matching for aspect-ratio and was discarding two of 
> the modes with aspect ratio,
> as duplicates of other modes in the list.
> 
> Later, when we are pruning the modes in drm_mode_get_connector, the 
> logic there assumes,
> that the modes are in a sorted order so that we just match with the last 
> valid mode for uniqueness.
> This isn't the case with the spoofed edid in kms_3d.
> Earlier, I was thinking if we should change the no. of expected modes in 
> kms_3d,
> but that's not correct approach.
> 
> So finally, The pruning logic needs to be changed, to do away with any 
> assumption and check
> all the modes in the list for duplicates. This however will take more 
> time to remove duplicates.
> 
> Any other suggestions on this?

What are all the modes this EDID gives us? The order in which the
modes are listed in the EDID should not be relevant as we sort
the mode list ourselves, and thus similar modes should appear back to
back on the list. So I don't really understand how we fail to
discard these two modes.

> 
> Regards
> -Ankit
> 
> >
> >> Perhaps this need to be handled in the test.
> >>
> >> -Regards,
> >>
> >> Ankit
> >>
> >>
> >> On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote:
> >>> From: "Sharma, Shashank" 
> >>>
> >>> Current DRM layer functions don't parse aspect ratio information
> >>> while converting a user mode->kernel mode or vice versa. This
> >>> causes modeset to pick mode with wrong aspect ratio, eventually
> >>> causing failures in HDMI compliance test cases, due to wrong VIC.
> >>>
> >>> This patch adds aspect ratio information in DRM's mode conversion
> >>> and mode comparision functions, to make sure kernel picks mode
> >>> with right aspect ratio (as per the VIC).
> >>>
> >>> Background:
> >>> This patch was once reviewed and merged, and later reverted due to
> >>> lack of DRM cap protection. This is a re-spin of this patch, this
> >>> time with DRM cap protection, to avoid aspect ratio information, when
> >>> the client doesn't request for it.
> >>>
> >>> Review link: https://pw-emeril.freedesktop.org/patch/104068/
> >>> Background discussion: https://patchwork.kernel.org/patch/9379057/
> >>>
> >>> Signed-off-by: Shashank Sharma 
> >>> Signed-off-by: Lin, Jia 
> >>> Signed-off-by: Akashdeep Sharma 
> >>> Reviewed-by: Jim Bride  (V2)
> >>> Reviewed-by: Jose Abreu  (V4)
> >>>
> >>> Cc: Ville Syrjala 
> >>> Cc: Jim Bride 
> >>> Cc: Jose Abreu 
> >>> Cc: Ankit Nautiyal 
> >>>
> >>> V3: modified the aspect-ratio check in drm_mode_equal as per new flags
> >>>   provided by Ville. https://patchwork.freedesktop.org/patch/188043/
> >>> V4: rebase
> >>> V5: rebase
> >>> V6: As recommended by Ville, avoided matching of aspect-ratio in
> >>>   drm_fb_helper, while trying to find a common mode among connectors
> >>>   for the target clone mode.
> >>> V7: rebase
> >>> V8: rebase
> >>> V9: rebase
> >>> V10: rebase
> >>> ---
> >>>drivers/gpu/drm/drm_fb_helper.c | 12 ++--
> >>>drivers/gpu/drm/drm_modes.c | 35 
> >>> ++-
> >>>2 files changed, 44 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> >>> b/drivers/gpu/drm/drm_fb_helper.c
> >>> index 0646b10..2ee1eaa 100644
> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >>> @@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
> >>> *fb_helper,
> >>>   for (j = 0; j < i; j++) {
> >>>   if (!enabled[j])
> >>>   continue;
> >>> - if (!drm_mode_equal(modes[j], modes[i]))
> >>> + if (!drm_mode_match(modes[j], modes[i],
> >>> + DRM_MODE_MATCH_TIMINGS |
> >>> + DRM_MODE_MATCH_CLOCK |
> >>> 

Re: [PATCH hwc v2 16/18] drm_hwcomposer: Find writeback connector for scene flattening

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:27PM +0100, Alexandru Gheorghe wrote:
> Add logic for finding a suitable writeback connector, there are two
> possibilities for finding an usable writeback connector:
> 
> 1) Attached to the same CRTC as the display and can function
>concurrently with the display connector.
> 
> 2) On a different CRTC and the display connector is not used (state !=
> DRM_MODE_CONNECTED). What's not handled here and should be handle is
> what happens if connector changes state while flattening, but since
> hotplug is not wired yet, it's not something we should worry about.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmresources.cpp| 25 +
>  drmresources.h  |  2 +-
>  resourcemanager.cpp | 24 
>  resourcemanager.h   |  1 +
>  4 files changed, 51 insertions(+), 1 deletion(-)
> 
> diff --git a/drmresources.cpp b/drmresources.cpp
> index fef6835..70126a4 100644
> --- a/drmresources.cpp
> +++ b/drmresources.cpp
> @@ -269,6 +269,31 @@ DrmConnector 
> *DrmResources::GetWritebackConnectorForDisplay(int display) const {
>return NULL;
>  }
>  
> +// TODO what happens when hotplugging
> +DrmConnector *DrmResources::AvailableWritebackConnector(int display) const {
> +  DrmConnector *writeback_conn = GetWritebackConnectorForDisplay(display);
> +  DrmConnector *display_conn = GetConnectorForDisplay(display);
> +  // If we have a writeback already attached to the same CRTC, just use 
> that, if
> +  // possible
> +  if (display_conn && writeback_conn &&
> +  writeback_conn->encoder()->can_clone(display_conn->encoder()))
> +return writeback_conn;
> +
> +  // Use another CRTC if available and doesn't have any connector
> +  for (auto  : crtcs_) {
> +if (crtc->display() == display)
> +  continue;
> +display_conn = GetConnectorForDisplay(crtc->display());
> +// If we have a display connected don't use it for writeback
> +if (display_conn && display_conn->state() == DRM_MODE_CONNECTED)
> +  continue;
> +writeback_conn = GetWritebackConnectorForDisplay(crtc->display());
> +if (writeback_conn)
> +  return writeback_conn;
> +  }
> +  return NULL;
> +}
> +
>  DrmCrtc *DrmResources::GetCrtcForDisplay(int display) const {
>for (auto  : crtcs_) {
>  if (crtc->display() == display)
> diff --git a/drmresources.h b/drmresources.h
> index 4fb17fc..9176b8e 100644
> --- a/drmresources.h
> +++ b/drmresources.h
> @@ -60,7 +60,7 @@ class DrmResources {
>  
>DrmConnector *GetConnectorForDisplay(int display) const;
>DrmConnector *GetWritebackConnectorForDisplay(int display) const;
> -  DrmConnector *FindWritebackConnector(int display) const;

What's up with this?

> +  DrmConnector *AvailableWritebackConnector(int display) const;
>DrmCrtc *GetCrtcForDisplay(int display) const;
>DrmPlane *GetPlane(uint32_t id) const;
>DrmEventListener *event_listener();
> diff --git a/resourcemanager.cpp b/resourcemanager.cpp
> index e7b654e..b2a4458 100644
> --- a/resourcemanager.cpp
> +++ b/resourcemanager.cpp
> @@ -49,6 +49,30 @@ int ResourceManager::Init() {
> (const hw_module_t **)_);
>  }
>  
> +DrmConnector *ResourceManager::AvailableWritebackConnector(int display) {
> +  DrmResources *drm_resource = GetDrmResources(display);
> +  DrmConnector *writeback_conn = NULL;
> +  if (drm_resource) {
> +writeback_conn = drm_resource->AvailableWritebackConnector(display);
> +if (writeback_conn) {
> +  ALOGI("Use writeback connected to display %d\n",
> +writeback_conn->display());

This seems a little chatty, it's written every flatten, yeah?

> +  return writeback_conn;
> +}
> +  }
> +  for (auto  : drms_) {
> +if (drm.get() == drm_resource)
> +  continue;
> +writeback_conn = drm->AvailableWritebackConnector(display);
> +if (writeback_conn) {
> +  ALOGI("Use writeback connected to display %d\n",
> +writeback_conn->display());
> +  return writeback_conn;
> +}
> +  }
> +  return writeback_conn;
> +}
> +
>  DrmResources *ResourceManager::GetDrmResources(int display) {
>for (uint32_t i = 0; i < drms_.size(); i++) {
>  if (drms_[i]->HandlesDisplay(display))
> diff --git a/resourcemanager.h b/resourcemanager.h
> index b8caa9a..57f7a2a 100644
> --- a/resourcemanager.h
> +++ b/resourcemanager.h
> @@ -18,6 +18,7 @@ class ResourceManager {
>DrmResources *GetDrmResources(int display);
>std::shared_ptr GetImporter(int display);
>const gralloc_module_t *GetGralloc();
> +  DrmConnector *AvailableWritebackConnector(int display);
>  
>   private:
>std::vector drms_;
> -- 
> 2.7.4
> 

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

Re: [PATCH hwc v2 15/18] drm_hwcomposer: Add worker to trigger scene flattenning

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:26PM +0100, Alexandru Gheorghe wrote:
> Add a vsync worker that calls back into the DrmDisplayCompositor,
> for now at every 60 vsyncs if the scene does not change we trigger
> the flattening of the scene using the writeback connector.
> Other, more complex and proper heuristics could be implemented later
> on.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmdisplaycompositor.cpp | 45 ++---
>  drmdisplaycompositor.h   | 12 +++-
>  2 files changed, 53 insertions(+), 4 deletions(-)
> 
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index 576539b..e535e8a 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -39,6 +39,20 @@
>  
>  namespace android {
>  
> +class CompositorVsyncCallback : public VsyncCallback {
> + public:
> +  CompositorVsyncCallback(DrmDisplayCompositor *compositor)
> +  : compositor_(compositor) {
> +  }
> +
> +  void Callback(int display, int64_t timestamp) {
> +compositor_->Vsync(display, timestamp);
> +  }
> +
> + private:
> +  DrmDisplayCompositor *compositor_;
> +};
> +
>  void SquashState::Init(DrmHwcLayer *layers, size_t num_layers) {
>generation_number_++;
>valid_history_ = 0;
> @@ -183,7 +197,8 @@ DrmDisplayCompositor::DrmDisplayCompositor()
>framebuffer_index_(0),
>squash_framebuffer_index_(0),
>dump_frames_composited_(0),
> -  dump_last_timestamp_ns_(0) {
> +  dump_last_timestamp_ns_(0),
> +  flatten_countdown_(FLATTEN_COUNTDOWN_INIT) {
>struct timespec ts;
>if (clock_gettime(CLOCK_MONOTONIC, ))
>  return;
> @@ -193,7 +208,7 @@ DrmDisplayCompositor::DrmDisplayCompositor()
>  DrmDisplayCompositor::~DrmDisplayCompositor() {
>if (!initialized_)
>  return;
> -
> +  vsync_worker_.Exit();
>int ret = pthread_mutex_lock(_);
>if (ret)
>  ALOGE("Failed to acquire compositor lock %d", ret);
> @@ -222,7 +237,9 @@ int DrmDisplayCompositor::Init(DrmResources *drm, int 
> display) {
>  return ret;
>}
>planner_ = Planner::CreateInstance(drm);
> -
> +  vsync_worker_.Init(drm_, display_);
> +  auto callback = std::make_shared(this);
> +  vsync_worker_.RegisterCallback(callback);
>initialized_ = true;
>return 0;
>  }
> @@ -896,6 +913,10 @@ int DrmDisplayCompositor::ApplyComposition(
>return ret;
>  }
>  
> +int DrmDisplayCompositor::FlattenScene() {
> +  return -EINVAL;
> +}

Hmm... not sure this is a useful inclusion.

> +
>  int DrmDisplayCompositor::SquashAll() {
>AutoLock lock(_, "compositor");
>int ret = lock.Lock();
> @@ -1044,6 +1065,24 @@ move_layers_back:
>return ret;
>  }
>  
> +bool DrmDisplayCompositor::CountdownExpired() const {
> +  return flatten_countdown_ <= 0;
> +}
> +
> +void DrmDisplayCompositor::Vsync(int display, int64_t timestamp) {
> +  AutoLock lock(_, __FUNCTION__);

We use __func__ elsewhere, we should probably be consistent (same goes for other
instances).

> +  if (lock.Lock())
> +return;
> +  flatten_countdown_--;
> +  if (CountdownExpired()) {

Doing:

if (--flatten_countdown_ > 0)
  return;

Allows you to remove the CountdownExpired() function and save a level of
indentation for the rest of the function.


> +lock.Unlock();
> +int ret = FlattenScene();
> +ALOGI("scene flattening triggered for display %d at timestamp %" PRIu64
> +  " result = %d \n",
> +  display, timestamp, ret);
> +  }
> +}
> +
>  void DrmDisplayCompositor::Dump(std::ostringstream *out) const {
>int ret = pthread_mutex_lock(_);
>if (ret)
> diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
> index b35ef70..26201b9 100644
> --- a/drmdisplaycompositor.h
> +++ b/drmdisplaycompositor.h
> @@ -29,11 +29,16 @@
>  
>  #include 
>  #include 
> +#include 

"vsyncworker.h"

>  
>  // One for the front, one for the back, and one for cases where we need to
>  // squash a frame that the hw can't display with hw overlays.
>  #define DRM_DISPLAY_BUFFERS 3
>  
> +// If a scene is still for this number of vblanks flatten it to reduce power
> +// consumption.
> +#define FLATTEN_COUNTDOWN_INIT 60
> +
>  namespace android {
>  
>  class GLWorkerCompositor;
> @@ -92,7 +97,7 @@ class DrmDisplayCompositor {
>int Composite();
>int SquashAll();
>void Dump(std::ostringstream *out) const;
> -
> +  void Vsync(int display, int64_t timestamp);
>std::tuple GetActiveModeResolution();
>  
>SquashState *squash_state() {
> @@ -128,6 +133,9 @@ class DrmDisplayCompositor {
>void ClearDisplay();
>void ApplyFrame(std::unique_ptr composition,
>int status, bool writeback = false);
> +  int FlattenScene();
> +
> +  bool CountdownExpired() const;
>  
>std::tuple CreateModeBlob(const DrmMode );
>  
> @@ -157,6 +165,8 @@ class DrmDisplayCompositor {
>// we need to reset them on every Dump() call.
>mutable uint64_t 

Re: [PATCH hwc v2 14/18] drm_hwcomposer: Fix race in ApplyFrame

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:25PM +0100, Alexandru Gheorghe wrote:
> ApplyFrame holds the lock just when it swaps the value of
> active_composition_, in a multithread context we could end up in a
> situation where something is shown on the screen, but something else
> is set in active_composition_. Fix it by holding the lock during
> CommitFrame.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmdisplaycompositor.cpp | 40 +---
>  drmdisplaycompositor.h   |  2 +-
>  2 files changed, 18 insertions(+), 24 deletions(-)
> 
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index afd3b05..576539b 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -791,11 +791,6 @@ std::tuple 
> DrmDisplayCompositor::CreateModeBlob(
>  }
>  
>  void DrmDisplayCompositor::ClearDisplay() {
> -  AutoLock lock(_, "compositor");
> -  int ret = lock.Lock();
> -  if (ret)
> -return;
> -
>if (!active_composition_)
>  return;
>  
> @@ -808,11 +803,25 @@ void DrmDisplayCompositor::ClearDisplay() {
>  }
>  
>  void DrmDisplayCompositor::ApplyFrame(
> -std::unique_ptr composition, int status) {
> +std::unique_ptr composition, int status,
> +bool writeback) {

The writeback argument addition seems unrelated to this change.

> +  AutoLock lock(_, __FUNCTION__);
> +  if (lock.Lock())
> +return;
>int ret = status;
> -
> -  if (!ret)
> +  if (!ret) {
> +if (writeback && !CountdownExpired()) {
> +  ALOGE("Abort playing back scene");
> +  return;
> +}
>  ret = CommitFrame(composition.get(), false);
> +if (!ret) {
> +  ++dump_frames_composited_;
> +  if (active_composition_)
> +active_composition_->SignalCompositionDone();
> +  active_composition_.swap(composition);

Why move this stuff?

> +}
> +  }
>  
>if (ret) {
>  ALOGE("Composite failed for display %d", display_);
> @@ -821,21 +830,6 @@ void DrmDisplayCompositor::ApplyFrame(
>  ClearDisplay();
>  return;
>}
> -  ++dump_frames_composited_;
> -
> -  if (active_composition_)
> -active_composition_->SignalCompositionDone();
> -
> -  ret = pthread_mutex_lock(_);
> -  if (ret)
> -ALOGE("Failed to acquire lock for active_composition swap");
> -
> -  active_composition_.swap(composition);
> -
> -  if (!ret)
> -ret = pthread_mutex_unlock(_);
> -  if (ret)
> -ALOGE("Failed to release lock for active_composition swap");
>  }
>  
>  int DrmDisplayCompositor::ApplyComposition(
> diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
> index 0f8daad..b35ef70 100644
> --- a/drmdisplaycompositor.h
> +++ b/drmdisplaycompositor.h
> @@ -127,7 +127,7 @@ class DrmDisplayCompositor {
>  
>void ClearDisplay();
>void ApplyFrame(std::unique_ptr composition,
> -  int status);
> +  int status, bool writeback = false);
>  
>std::tuple CreateModeBlob(const DrmMode );
>  
> -- 
> 2.7.4
> 

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

Re: [PATCH hwc v2 13/18] drm_hwcomposer: Pass buffer sizes to Prepareframebuffer

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:24PM +0100, Alexandru Gheorghe wrote:
> Currently Prepareframebuffer uses the mode of the connected connector
> to decide how big the buffer should be, however when using the
> drmdisplaycompositor just for flattening, the mode had not been set
> yet, so we need a way to pass the desired buffer sizes.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmdisplaycompositor.cpp | 7 ---
>  drmdisplaycompositor.h   | 3 ++-
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index 6e5be24..afd3b05 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -268,14 +268,15 @@ DrmDisplayCompositor::GetActiveModeResolution() {
>  }
>  
>  int DrmDisplayCompositor::PrepareFramebuffer(
> -DrmFramebuffer , DrmDisplayComposition *display_comp) {
> +DrmFramebuffer , DrmDisplayComposition *display_comp, uint32_t width,
> +uint32_t height) {
>int ret = fb.WaitReleased(-1);
>if (ret) {
>  ALOGE("Failed to wait for framebuffer release %d", ret);
>  return ret;
>}
> -  uint32_t width, height;
> -  std::tie(width, height, ret) = GetActiveModeResolution();
> +  if (width == 0 || height == 0)
> +std::tie(width, height, ret) = GetActiveModeResolution();

Just plumb it through at the other callsites.

>if (ret) {
>  ALOGE(
>  "Failed to allocate framebuffer because the display resolution could 
> "
> diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
> index ccaffb4..0f8daad 100644
> --- a/drmdisplaycompositor.h
> +++ b/drmdisplaycompositor.h
> @@ -115,7 +115,8 @@ class DrmDisplayCompositor {
>static const int kAcquireWaitTimeoutMs = 100;
>  
>int PrepareFramebuffer(DrmFramebuffer ,
> - DrmDisplayComposition *display_comp);
> + DrmDisplayComposition *display_comp,
> + uint32_t width = 0, uint32_t height = 0);
>int ApplySquash(DrmDisplayComposition *display_comp);
>int ApplyPreComposite(DrmDisplayComposition *display_comp);
>int PrepareFrame(DrmDisplayComposition *display_comp);
> -- 
> 2.7.4
> 

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

Re: [PATCH hwc v2 12/18] drm_hwcomposer: Add utility function to create an initialized composition

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:23PM +0100, Alexandru Gheorghe wrote:
> There is a lot of boilerplate for creating an initialized
> drmdisplaycomposition. This patch gathers that in a separate method.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmdisplaycompositor.cpp | 23 +++
>  drmdisplaycompositor.h   |  2 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index e556e86..6e5be24 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -221,6 +221,7 @@ int DrmDisplayCompositor::Init(DrmResources *drm, int 
> display) {
>  ALOGE("Failed to initialize drm compositor lock %d\n", ret);
>  return ret;
>}
> +  planner_ = Planner::CreateInstance(drm);

What's this?

>  
>initialized_ = true;
>return 0;
> @@ -231,6 +232,28 @@ std::unique_ptr 
> DrmDisplayCompositor::CreateComposition()
>return std::unique_ptr(new DrmDisplayComposition());
>  }
>  
> +std::unique_ptr
> +DrmDisplayCompositor::CreateInitializedComposition() const {
> +  DrmCrtc *crtc = drm_->GetCrtcForDisplay(display_);
> +  if (!crtc) {
> +ALOGE("Failed to find crtc for display = %d", display_);
> +return std::unique_ptr();
> +  }
> +  std::unique_ptr comp = CreateComposition();
> +  std::shared_ptr importer =
> +  drm_->resource_manager()->GetImporter(display_);
> +  if (!importer) {
> +ALOGE("Failed to find resources for display = %d", display_);
> +return std::unique_ptr();
> +  }
> +  int ret = comp->Init(drm_, crtc, importer.get(), planner_.get(), 0);
> +  if (ret) {
> +ALOGE("Failed to init composition for display = %d", display_);
> +return std::unique_ptr();
> +  }
> +  return comp;
> +}
> +

This seems sufficiently small that you can squash it into the patch that uses
it. The same can be said for some of the other "Add function to do X" which
don't use the function.

>  std::tuple
>  DrmDisplayCompositor::GetActiveModeResolution() {
>DrmConnector *connector = drm_->GetConnectorForDisplay(display_);
> diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
> index f1965fb..ccaffb4 100644
> --- a/drmdisplaycompositor.h
> +++ b/drmdisplaycompositor.h
> @@ -87,6 +87,7 @@ class DrmDisplayCompositor {
>int Init(DrmResources *drm, int display);
>  
>std::unique_ptr CreateComposition() const;
> +  std::unique_ptr CreateInitializedComposition() 
> const;
>int ApplyComposition(std::unique_ptr composition);
>int Composite();
>int SquashAll();
> @@ -155,6 +156,7 @@ class DrmDisplayCompositor {
>// we need to reset them on every Dump() call.
>mutable uint64_t dump_frames_composited_;
>mutable uint64_t dump_last_timestamp_ns_;
> +  std::unique_ptr planner_;
>  };
>  }
>  
> -- 
> 2.7.4
> 

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

Re: [PATCH hwc v2 11/18] drm_hwcomposer: Add utility functions to copy displaycomposition internals

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:22PM +0100, Alexandru Gheorghe wrote:
> Add utility functions to copy the DrmHwcLayer and DrmCompositionPlanes
> from another DrmDisplayComposition.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmdisplaycomposition.cpp | 29 +
>  drmdisplaycomposition.h   |  3 +++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drmdisplaycomposition.cpp b/drmdisplaycomposition.cpp
> index 66e67a4..dd64f46 100644
> --- a/drmdisplaycomposition.cpp
> +++ b/drmdisplaycomposition.cpp
> @@ -99,6 +99,35 @@ int DrmDisplayComposition::SetLayers(DrmHwcLayer *layers, 
> size_t num_layers,
>return 0;
>  }
>  
> +int DrmDisplayComposition::CopyLayers(DrmDisplayComposition *src) {
> +  geometry_changed_ = true;
> +  type_ = DRM_COMPOSITION_TYPE_FRAME;
> +  std::shared_ptr importer =
> +  drm_->resource_manager()->GetImporter(crtc()->display());
> +  if (!importer) {
> +ALOGE("Failed to find a valid importer");
> +return -EINVAL;
> +  }
> +  for (DrmHwcLayer _layer : src->layers()) {
> +DrmHwcLayer copy;
> +copy.PopulateFromDrmHwcLayer(_layer);
> +int ret = copy.ImportBuffer(importer.get(),
> +drm_->resource_manager()->GetGralloc());
> +if (ret) {
> +  ALOGE("Failed to import buffer ret = %d", ret);
> +  return -EINVAL;
> +}
> +layers_.emplace_back(std::move(copy));
> +  }
> +  return 0;
> +}

This seems to do more than just CopyLayers, and it seems quite specialized to
your purpose. Can you do something similar to SquashFrame(), where the new
composition is crafted in context? It might be a little less awkward than
sprinkling in these seemingly generic copy functions.

Sean

> +
> +void DrmDisplayComposition::CopyCompPlanes(DrmDisplayComposition *src) {
> +  for (auto comp_plane : src->composition_planes()) {
> +composition_planes_.push_back(comp_plane);
> +  }
> +}
> +
>  int DrmDisplayComposition::SetDpmsMode(uint32_t dpms_mode) {
>if (!validate_composition_type(DRM_COMPOSITION_TYPE_DPMS))
>  return -EINVAL;
> diff --git a/drmdisplaycomposition.h b/drmdisplaycomposition.h
> index 9183925..c646420 100644
> --- a/drmdisplaycomposition.h
> +++ b/drmdisplaycomposition.h
> @@ -68,6 +68,7 @@ class DrmCompositionPlane {
>  
>DrmCompositionPlane() = default;
>DrmCompositionPlane(DrmCompositionPlane &) = default;
> +  DrmCompositionPlane(const DrmCompositionPlane ) = default;
>DrmCompositionPlane =(DrmCompositionPlane &) = default;
>DrmCompositionPlane(Type type, DrmPlane *plane, DrmCrtc *crtc)
>: type_(type), plane_(plane), crtc_(crtc) {
> @@ -120,6 +121,8 @@ class DrmDisplayComposition {
> Planner *planner, uint64_t frame_no);
>  
>int SetLayers(DrmHwcLayer *layers, size_t num_layers, bool 
> geometry_changed);
> +  int CopyLayers(DrmDisplayComposition *src);
> +  void CopyCompPlanes(DrmDisplayComposition *src);
>int AddPlaneComposition(DrmCompositionPlane plane);
>int AddPlaneDisable(DrmPlane *plane);
>int SetDpmsMode(uint32_t dpms_mode);
> -- 
> 2.7.4
> 

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

Re: [PATCH v2 1/3] drm/prime: Iterate SG DMA addresses separately

[Christian König]

Am 17.04.2018 um 17:58 schrieb Robin Murphy:

For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses which drm_prime_sg_to_page_addr_arrays()
iterates may be packed into fewer entries than ttm->sg->nents implies.

The current implementation does not account for this, meaning that its
callers either have to reject the 0 < count < nents case or risk getting
bogus DMA addresses beyond the first segment. Fortunately this is quite
easy to handle without having to rejig structures to also store the
mapped count, since the total DMA length should still be equal to the
total buffer length. All we need is a second scatterlist cursor to
iterate through the DMA addresses independently of the page addresses.

Signed-off-by: Robin Murphy 


Reviewed-by: Christian König  for the whole 
series.



---

v2: Remember to iterate dma_len correctly as well.

  drivers/gpu/drm/drm_prime.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7856a9b3f8a8..b8ca06ea7d80 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -933,16 +933,18 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table 
*sgt, struct page **pages,
 dma_addr_t *addrs, int max_entries)
  {
unsigned count;
-   struct scatterlist *sg;
+   struct scatterlist *sg, *dma_sg;
struct page *page;
-   u32 len, index;
+   u32 len, dma_len, index;
dma_addr_t addr;
  
  	index = 0;

+   dma_sg = sgt->sgl;
+   dma_len = sg_dma_len(dma_sg);
+   addr = sg_dma_address(dma_sg);
for_each_sg(sgt->sgl, sg, sgt->nents, count) {
len = sg->length;
page = sg_page(sg);
-   addr = sg_dma_address(sg);
  
  		while (len > 0) {

if (WARN_ON(index >= max_entries))
@@ -955,8 +957,15 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, 
struct page **pages,
page++;
addr += PAGE_SIZE;
len -= PAGE_SIZE;
+   dma_len -= PAGE_SIZE;
index++;
}
+
+   if (dma_len == 0) {
+   dma_sg = sg_next(dma_sg);
+   dma_len = sg_dma_len(dma_sg);
+   addr = sg_dma_address(dma_sg);
+   }
}
return 0;
  }


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

Re: [PATCH] gpu: drm: i915: Change return type to vm_fault_t

[Daniel Vetter]

On Tue, Apr 17, 2018 at 5:29 PM, Jani Nikula
 wrote:
> On Tue, 17 Apr 2018, Souptick Joarder  wrote:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are converted, vm_fault_t will become a distinct type.
>>
>> Reference id -> 1c8f422059ae ("mm: change return type to
>> vm_fault_t")
>>
>> Signed-off-by: Souptick Joarder 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
>>  drivers/gpu/drm/i915/i915_gem.c | 15 ---
>>  2 files changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index a42deeb..95b0d50 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -51,6 +51,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include "i915_params.h"
>>  #include "i915_reg.h"
>> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
>> *dev_priv,
>>  unsigned int flags);
>>  int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
>>  void i915_gem_resume(struct drm_i915_private *dev_priv);
>> -int i915_gem_fault(struct vm_fault *vmf);
>> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
>>  int i915_gem_object_wait(struct drm_i915_gem_object *obj,
>>unsigned int flags,
>>long timeout,
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index dd89abd..bdac690 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
>>   * The current feature set supported by i915_gem_fault() and thus GTT mmaps
>>   * is exposed via I915_PARAM_MMAP_GTT_VERSION (see 
>> i915_gem_mmap_gtt_version).
>>   */
>> -int i915_gem_fault(struct vm_fault *vmf)
>> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>>  {
>>  #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
>>   struct vm_area_struct *area = vmf->vma;
>> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>>   pgoff_t page_offset;
>>   unsigned int flags;
>>   int ret;
>> + vm_fault_t retval;
>
> What's the point of changing the name? An unnecessary change.

int ret;

already exists and is used. You can't also have a vm_fault_t ret; on
top of that :-)
-Daniel

>
> BR,
> Jani.
>
>>
>>   /* We don't use vmf->pgoff since that has the fake offset */
>>   page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
>> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>>* and so needs to be reported.
>>*/
>>   if (!i915_terminally_wedged(_priv->gpu_error)) {
>> - ret = VM_FAULT_SIGBUS;
>> + retval = VM_FAULT_SIGBUS;
>>   break;
>>   }
>>   case -EAGAIN:
>> @@ -2017,21 +2018,21 @@ int i915_gem_fault(struct vm_fault *vmf)
>>* EBUSY is ok: this just means that another thread
>>* already did the job.
>>*/
>> - ret = VM_FAULT_NOPAGE;
>> + retval = VM_FAULT_NOPAGE;
>>   break;
>>   case -ENOMEM:
>> - ret = VM_FAULT_OOM;
>> + retval = VM_FAULT_OOM;
>>   break;
>>   case -ENOSPC:
>>   case -EFAULT:
>> - ret = VM_FAULT_SIGBUS;
>> + retval = VM_FAULT_SIGBUS;
>>   break;
>>   default:
>>   WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", ret);
>> - ret = VM_FAULT_SIGBUS;
>> + retval = VM_FAULT_SIGBUS;
>>   break;
>>   }
>> - return ret;
>> + return retval;
>>  }
>>
>>  static void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
>> --
>> 1.9.1
>>
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 10/18] drm_hwcomposer: hwcutils: Add function for cloning a DrmHwcLayer

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:21PM +0100, Alexandru Gheorghe wrote:
> When doing flattening of a composition on a different CRTC we need to be
> able to clone a layer in order to import it and then pass it to another CRTC.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmhwcomposer.h |  1 +
>  hwcutils.cpp| 11 +++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drmhwcomposer.h b/drmhwcomposer.h
> index f8440fb..b256caf 100644
> --- a/drmhwcomposer.h
> +++ b/drmhwcomposer.h
> @@ -150,6 +150,7 @@ struct DrmHwcLayer {
>  
>int InitFromHwcLayer(hwc_layer_1_t *sf_layer, Importer *importer,
> const gralloc_module_t *gralloc);
> +  int PopulateFromDrmHwcLayer(DrmHwcLayer *layer);
>int ImportBuffer(Importer *importer, const gralloc_module_t *gralloc);
>  
>void SetTransform(int32_t sf_transform);
> diff --git a/hwcutils.cpp b/hwcutils.cpp
> index 53a7d82..ff37c3b 100644
> --- a/hwcutils.cpp
> +++ b/hwcutils.cpp
> @@ -149,6 +149,17 @@ int DrmHwcLayer::InitFromHwcLayer(hwc_layer_1_t 
> *sf_layer, Importer *importer,
>return ImportBuffer(importer, gralloc);
>  }
>  
> +int DrmHwcLayer::PopulateFromDrmHwcLayer(DrmHwcLayer *src_layer) {
> +  blending = src_layer->blending;
> +  sf_handle = src_layer->sf_handle;
> +  acquire_fence = dup(src_layer->acquire_fence.get());

Hmm, I think this is the only place where we duplicate a UniqueFd. I _think_
this will be Ok, but do you need to use this? Could you instead defer trying to
flatten if the original acquire_fence hasn't fired? Also, you don't check the
return value.

> +  display_frame = src_layer->display_frame;
> +  alpha = src_layer->alpha;
> +  source_crop = src_layer->source_crop;
> +  transform = src_layer->transform;

It also doesn't seem like you're populating all of the fields so the function
name is misleading.


> +  return 0;
> +}
> +
>  int DrmHwcLayer::ImportBuffer(Importer *importer,
>const gralloc_module_t *gralloc) {
>int ret = buffer.ImportBuffer(sf_handle, importer);
> -- 
> 2.7.4
> 

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

Re: [PATCH hwc v2 04/18] drm_hwcomposer: Add resource manager class

[Robert Foss]

Hey,

On 04/17/2018 05:33 PM, Sean Paul wrote:

On Wed, Apr 11, 2018 at 04:22:15PM +0100, Alexandru Gheorghe wrote:

Add a resource manager object that is responsible for detecting all
kms devices and allocates unique display numbers for every detected
display.

This is controlled by the value of hwc.drm.device property, if it ends
with a %, it will try to open minor devices until and error is detected.
E.g: /dev/dri/card%


I'm a bit on the fence as to whether to use the %, or add a new
hwc.drm.scan_devices property. I guess since we need to convey the path anyways
this is fine, but it really needs to be better documented.


I'm looking at this stuff in another series about DRM Node probing[1],
and I'll look into using properties to define what we are looking for.

But those properties won't be paths, but rather PCI IDs and driver vendor names.

As for what to do in the series, I don't have much of an opinion. But I'm likely 
to try to change it in the not too distant future.



[1] https://www.spinics.net/lists/dri-devel/msg172496.html





Additionally, this will be used for finding an available writeback
connector that will be used for the flattening of the currently
displayed scene.

Signed-off-by: Alexandru Gheorghe 
---
  Android.mk  |  1 +
  resourcemanager.cpp | 71 +
  resourcemanager.h   | 29 ++
  3 files changed, 101 insertions(+)
  create mode 100644 resourcemanager.cpp
  create mode 100644 resourcemanager.h

diff --git a/Android.mk b/Android.mk
index 1add286..736fe24 100644
--- a/Android.mk
+++ b/Android.mk
@@ -52,6 +52,7 @@ LOCAL_C_INCLUDES := \
  
  LOCAL_SRC_FILES := \

autolock.cpp \
+   resourcemanager.cpp \
drmresources.cpp \
drmconnector.cpp \
drmcrtc.cpp \
diff --git a/resourcemanager.cpp b/resourcemanager.cpp
new file mode 100644
index 000..e7b654e
--- /dev/null
+++ b/resourcemanager.cpp
@@ -0,0 +1,71 @@
+#include "resourcemanager.h"
+#include 
+#include 
+
+namespace android {
+
+ResourceManager::ResourceManager() : gralloc_(NULL) {
+}
+
+int ResourceManager::Init() {
+  char path_pattern[PROPERTY_VALUE_MAX];
+  property_get("hwc.drm.device", path_pattern, "/dev/dri/card%");


We probably also don't want to default to scanning, since that might change
behavior in existing boards.


+
+  uint8_t minor = 0;


Please use unsigned/int instead of fixed-size types. Unless the number of bits
is relevant to use of the variable, let the compiler handle it.


+  int last_display_index = 0;


Could we just call this num_displays? It was kind of hard for me to reason
through this, especially when it's call "start_display_index" when you jump into
drm::Init(). I also think drm->Init's return pair should return
 instead of , so each time you call
Init(), you're adding to num_displays.


+  int last_char = strlen(path_pattern) - 1;
+  do {
+char path[PROPERTY_VALUE_MAX];


Please use string


+if (path_pattern[last_char] == '%') {
+  path_pattern[last_char] = '\0';
+  snprintf(path, PROPERTY_VALUE_MAX, "%s%d", path_pattern, minor);
+  path_pattern[last_char] = '%';


This doesn't work for minor > 10.


+} else {
+  snprintf(path, PROPERTY_VALUE_MAX, "%s", path_pattern);
+}
+std::unique_ptr drm = std::make_unique();
+last_display_index = drm->Init(this, path, last_display_index);
+if (last_display_index < 0) {
+  break;
+}
+std::shared_ptr importer;
+importer.reset(Importer::CreateInstance(drm.get()));
+if (!importer) {
+  ALOGE("Failed to create importer instance");
+  break;
+}
+importers_.push_back(importer);
+drms_.push_back(std::move(drm));
+minor++;
+last_display_index++;
+  } while (path_pattern[last_char] == '%');
+
+  if (!drms_.size()) {
+ALOGE("Failed to find any working drm device");
+return -EINVAL;
+  }
+
+  return hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+   (const hw_module_t **)_);
+}


Consider the following:

int ResourceManager::AddDrmDevice(std::string path) {
   std::unique_ptr drm = std::make_unique();
   int displays_added, ret;
   std::tie(displays_added, ret) = drm->Init(path.c_str(), num_displays_);
   if (ret)
 return ret;

   std::shared_ptr importer;
   importer.reset(Importer::CreateInstance(drm.get()));
   if (!importer) {
 ALOGE("Failed to create importer instance");
 return -ENODEV;
   }

   importers_.push_back(importer);
   drms_.push_back(std::move(drm));
   num_displays_ += displays_added;
   return 0;
}

int ResourceManager::Init() {
   char path_pattern[PROPERTY_VALUE_MAX];
   int path_len = property_get("hwc.drm.device", path_pattern, 
"/dev/dri/card%");

   if (path_pattern[path_len - 1] != '%')
 return AddDrmDevice(std::string(path_pattern);

   path_pattern[path_len - 1] = '\0';
   for (int ret = 0, idx = 0; !ret; ++idx) {
 

[PATCH v2 3/3] drm/radeon: Allow dma_map_sg() coalescing

[Robin Murphy]

Much like amdgpu, the radeon driver doesn't appear to directly use the
scatterlist mapped by radeon_ttm_tt_pin_userptr(), it merely hands it
off to drm_prime_sg_to_page_addr_arrays() to generate the dma_address
array which it actually cares about. Now that the latter can cope with
dma_map_sg() coalescing dma-contiguous segments such that it returns
0 < count < nents, we can relax the current count == nents check to
only consider genuine failure as other drivers do.

Suggested-by: Christian König 
Signed-off-by: Robin Murphy 
---

v2: New

 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 8689fcca051c..7c099192c7fa 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -585,7 +585,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 
r = -ENOMEM;
nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents != ttm->sg->nents)
+   if (nents == 0)
goto release_sg;
 
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
-- 
2.16.1.dirty

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

[PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing

[Robin Murphy]

The amdgpu driver doesn't appear to directly use the scatterlist mapped
by amdgpu_ttm_tt_pin_userptr(), it merely hands it off to
drm_prime_sg_to_page_addr_arrays() to generate the dma_address array
which it actually cares about. Now that the latter can cope with
dma_map_sg() coalescing dma-contiguous segments such that it returns
0 < count < nents, we can relax the current count == nents check to
only consider genuine failure as other drivers do.

This avoids a false negative on arm64 systems with an IOMMU.

Reported-by: Sinan Kaya 
Signed-off-by: Robin Murphy 
---

v2: Expand commit message to clarify

 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 205da3ff9cd0..f81e96a4242f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -813,7 +813,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
 
r = -ENOMEM;
nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents != ttm->sg->nents)
+   if (nents == 0)
goto release_sg;
 
drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
-- 
2.16.1.dirty

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

[PATCH v2 1/3] drm/prime: Iterate SG DMA addresses separately

[Robin Murphy]

For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses which drm_prime_sg_to_page_addr_arrays()
iterates may be packed into fewer entries than ttm->sg->nents implies.

The current implementation does not account for this, meaning that its
callers either have to reject the 0 < count < nents case or risk getting
bogus DMA addresses beyond the first segment. Fortunately this is quite
easy to handle without having to rejig structures to also store the
mapped count, since the total DMA length should still be equal to the
total buffer length. All we need is a second scatterlist cursor to
iterate through the DMA addresses independently of the page addresses.

Signed-off-by: Robin Murphy 
---

v2: Remember to iterate dma_len correctly as well.

 drivers/gpu/drm/drm_prime.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7856a9b3f8a8..b8ca06ea7d80 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -933,16 +933,18 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table 
*sgt, struct page **pages,
 dma_addr_t *addrs, int max_entries)
 {
unsigned count;
-   struct scatterlist *sg;
+   struct scatterlist *sg, *dma_sg;
struct page *page;
-   u32 len, index;
+   u32 len, dma_len, index;
dma_addr_t addr;
 
index = 0;
+   dma_sg = sgt->sgl;
+   dma_len = sg_dma_len(dma_sg);
+   addr = sg_dma_address(dma_sg);
for_each_sg(sgt->sgl, sg, sgt->nents, count) {
len = sg->length;
page = sg_page(sg);
-   addr = sg_dma_address(sg);
 
while (len > 0) {
if (WARN_ON(index >= max_entries))
@@ -955,8 +957,15 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, 
struct page **pages,
page++;
addr += PAGE_SIZE;
len -= PAGE_SIZE;
+   dma_len -= PAGE_SIZE;
index++;
}
+
+   if (dma_len == 0) {
+   dma_sg = sg_next(dma_sg);
+   dma_len = sg_dma_len(dma_sg);
+   addr = sg_dma_address(dma_sg);
+   }
}
return 0;
 }
-- 
2.16.1.dirty

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

Re: [PATCH hwc v2 09/18] drm_hwcomposer: Handle writeback connectors

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:20PM +0100, Alexandru Gheorghe wrote:
> When writeback connectors are available assign them to displays, in
> order to be able to use them for flattening of the current displayed
> scene. The pipeline for each display will look like this:
> 
> CRTC  encoder  display connector.
>  |--- writeback enc -- writeback connector.
> 
> However, the writeback connector will be later used/enabled only if
> one of the following conditions are met:
>  - Could be a clone of the display connector, as pointed by the
>possible_clones property.
>  - The display_connector is disconnected, so we are safe to use it for
>flattening the scene that's already presented on another display.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmresources.cpp | 62 
> ++--
>  drmresources.h   |  3 +++
>  2 files changed, 63 insertions(+), 2 deletions(-)
> 
> diff --git a/drmresources.cpp b/drmresources.cpp
> index 39f50be..fef6835 100644
> --- a/drmresources.cpp
> +++ b/drmresources.cpp
> @@ -64,6 +64,14 @@ int DrmResources::Init(ResourceManager *resource_manager, 
> char *path,
>  return ret;
>}
>  
> +#ifdef DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
> +  ret = drmSetClientCap(fd(), DRM_CLIENT_CAP_WRITEBACK_CONNECTORS, 1);
> +  if (ret) {
> +ALOGI("Failed to set writeback cap %d", ret);
> +ret = 0;
> +  }
> +#endif
> +
>drmModeResPtr res = drmModeGetResources(fd());
>if (!res) {
>  ALOGE("Failed to get DrmResources resources");
> @@ -169,7 +177,7 @@ int DrmResources::Init(ResourceManager *resource_manager, 
> char *path,
>conn->set_display(0);
>displays_[0] = 0;
>found_primary = true;
> -} else {
> +} else if (conn->external()) {
>conn->set_display(display_num);
>displays_[display_num] = display_num;
>++display_num;
> @@ -230,6 +238,8 @@ int DrmResources::Init(ResourceManager *resource_manager, 
> char *path,
>}
>  
>for (auto  : connectors_) {
> +if (conn->writeback())
> +  continue;
>  ret = CreateDisplayPipe(conn.get());
>  if (ret) {
>ALOGE("Failed CreateDisplayPipe %d with %d", conn->id(), ret);
> @@ -245,7 +255,15 @@ bool DrmResources::HandlesDisplay(int display) const {
>  
>  DrmConnector *DrmResources::GetConnectorForDisplay(int display) const {
>for (auto  : connectors_) {
> -if (conn->display() == display)
> +if (conn->display() == display && !conn->writeback())
> +  return conn.get();
> +  }
> +  return NULL;
> +}
> +
> +DrmConnector *DrmResources::GetWritebackConnectorForDisplay(int display) 
> const {
> +  for (auto  : connectors_) {
> +if (conn->display() == display && conn->writeback())
>return conn.get();
>}
>return NULL;
> @@ -280,6 +298,7 @@ int DrmResources::TryEncoderForDisplay(int display, 
> DrmEncoder *enc) {
>DrmCrtc *crtc = enc->crtc();
>if (crtc && crtc->can_bind(display)) {
>  crtc->set_display(display);
> +enc->set_display(display);
>  return 0;
>}
>  
> @@ -306,6 +325,7 @@ int DrmResources::CreateDisplayPipe(DrmConnector 
> *connector) {
>if (connector->encoder()) {
>  int ret = TryEncoderForDisplay(display, connector->encoder());
>  if (!ret) {
> +  AttachWriteback(connector);

AttachWriteback returns int, but you throw it away here. Additionally,
AttachWriteback always follows a successful TryEncoderForDisplay, so it makes
sense to just call it from there.

>return 0;
>  } else if (ret != -EAGAIN) {
>ALOGE("Could not set mode %d/%d", display, ret);
> @@ -317,6 +337,7 @@ int DrmResources::CreateDisplayPipe(DrmConnector 
> *connector) {
>  int ret = TryEncoderForDisplay(display, enc);
>  if (!ret) {
>connector->set_encoder(enc);
> +  AttachWriteback(connector);
>return 0;
>  } else if (ret != -EAGAIN) {
>ALOGE("Could not set mode %d/%d", display, ret);
> @@ -328,6 +349,43 @@ int DrmResources::CreateDisplayPipe(DrmConnector 
> *connector) {
>return -ENODEV;
>  }
>  
> +/*
> + * Attach writeback connector to the CRTC linked to the display_conn
> + *
> + */
> +int DrmResources::AttachWriteback(DrmConnector *display_conn) {
> +  int ret = -EINVAL;

This isn't really used, just return the error code directly at the bottom.

> +  if (display_conn->writeback())
> +return -EINVAL;

This condition would benefit from a log

> +  DrmEncoder *display_enc = display_conn->encoder();
> +  if (!display_enc)
> +return -EINVAL;
> +  DrmCrtc *display_crtc = display_enc->crtc();
> +  if (!display_crtc)
> +return -EINVAL;

Are these possible given this is only called after a successful
TryEncoderForDisplay()?

> +  if (GetWritebackConnectorForDisplay(display_crtc->display()) != NULL)
> +return -EINVAL;

Again, logging would be useful.

> +  for (auto _conn : connectors_) {
> +if (writeback_conn->display() >= 0 || 

Re: [PATCH hwc v2 04/18] drm_hwcomposer: Add resource manager class

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:15PM +0100, Alexandru Gheorghe wrote:
> Add a resource manager object that is responsible for detecting all
> kms devices and allocates unique display numbers for every detected
> display.
> 
> This is controlled by the value of hwc.drm.device property, if it ends
> with a %, it will try to open minor devices until and error is detected.
> E.g: /dev/dri/card%

I'm a bit on the fence as to whether to use the %, or add a new
hwc.drm.scan_devices property. I guess since we need to convey the path anyways
this is fine, but it really needs to be better documented. 

> 
> Additionally, this will be used for finding an available writeback
> connector that will be used for the flattening of the currently
> displayed scene.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  Android.mk  |  1 +
>  resourcemanager.cpp | 71 
> +
>  resourcemanager.h   | 29 ++
>  3 files changed, 101 insertions(+)
>  create mode 100644 resourcemanager.cpp
>  create mode 100644 resourcemanager.h
> 
> diff --git a/Android.mk b/Android.mk
> index 1add286..736fe24 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -52,6 +52,7 @@ LOCAL_C_INCLUDES := \
>  
>  LOCAL_SRC_FILES := \
>   autolock.cpp \
> + resourcemanager.cpp \
>   drmresources.cpp \
>   drmconnector.cpp \
>   drmcrtc.cpp \
> diff --git a/resourcemanager.cpp b/resourcemanager.cpp
> new file mode 100644
> index 000..e7b654e
> --- /dev/null
> +++ b/resourcemanager.cpp
> @@ -0,0 +1,71 @@
> +#include "resourcemanager.h"
> +#include 
> +#include 
> +
> +namespace android {
> +
> +ResourceManager::ResourceManager() : gralloc_(NULL) {
> +}
> +
> +int ResourceManager::Init() {
> +  char path_pattern[PROPERTY_VALUE_MAX];
> +  property_get("hwc.drm.device", path_pattern, "/dev/dri/card%");

We probably also don't want to default to scanning, since that might change
behavior in existing boards.

> +
> +  uint8_t minor = 0;

Please use unsigned/int instead of fixed-size types. Unless the number of bits
is relevant to use of the variable, let the compiler handle it.

> +  int last_display_index = 0;

Could we just call this num_displays? It was kind of hard for me to reason
through this, especially when it's call "start_display_index" when you jump into
drm::Init(). I also think drm->Init's return pair should return 
 instead of , so each time you call
Init(), you're adding to num_displays.

> +  int last_char = strlen(path_pattern) - 1;
> +  do {
> +char path[PROPERTY_VALUE_MAX];

Please use string

> +if (path_pattern[last_char] == '%') {
> +  path_pattern[last_char] = '\0';
> +  snprintf(path, PROPERTY_VALUE_MAX, "%s%d", path_pattern, minor);
> +  path_pattern[last_char] = '%';

This doesn't work for minor > 10.

> +} else {
> +  snprintf(path, PROPERTY_VALUE_MAX, "%s", path_pattern);
> +}
> +std::unique_ptr drm = std::make_unique();
> +last_display_index = drm->Init(this, path, last_display_index);
> +if (last_display_index < 0) {
> +  break;
> +}
> +std::shared_ptr importer;
> +importer.reset(Importer::CreateInstance(drm.get()));
> +if (!importer) {
> +  ALOGE("Failed to create importer instance");
> +  break;
> +}
> +importers_.push_back(importer);
> +drms_.push_back(std::move(drm));
> +minor++;
> +last_display_index++;
> +  } while (path_pattern[last_char] == '%');
> +
> +  if (!drms_.size()) {
> +ALOGE("Failed to find any working drm device");
> +return -EINVAL;
> +  }
> +
> +  return hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
> +   (const hw_module_t **)_);
> +}

Consider the following:

int ResourceManager::AddDrmDevice(std::string path) {
  std::unique_ptr drm = std::make_unique();
  int displays_added, ret;
  std::tie(displays_added, ret) = drm->Init(path.c_str(), num_displays_);
  if (ret)
return ret;

  std::shared_ptr importer;
  importer.reset(Importer::CreateInstance(drm.get()));
  if (!importer) {
ALOGE("Failed to create importer instance");
return -ENODEV;
  }

  importers_.push_back(importer);
  drms_.push_back(std::move(drm));
  num_displays_ += displays_added;
  return 0;
}

int ResourceManager::Init() {
  char path_pattern[PROPERTY_VALUE_MAX];
  int path_len = property_get("hwc.drm.device", path_pattern, "/dev/dri/card%");

  if (path_pattern[path_len - 1] != '%')
return AddDrmDevice(std::string(path_pattern);

  path_pattern[path_len - 1] = '\0';
  for (int ret = 0, idx = 0; !ret; ++idx) {
ostringstream path;
path << path_pattern << idx;
ret = AddDrmDevice(path.str());
  }
  if (!num_displays_) {
ALOGE("Failed to initialize any displays");
return -EINVAL;
  }

  return hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
   (const hw_module_t **)_);
}

I think resolves the issues from the original 

[Bug 97025] flip queue failed: Device or resource busy

[bugzilla-daemon]

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

--- Comment #26 from Michel Dänzer  ---
Does
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=daf8809626c0ee7a152f9c34058fc3b43385dd51
help for this?

-- 
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] gpu: drm: i915: Change return type to vm_fault_t

[Jani Nikula]

On Tue, 17 Apr 2018, Souptick Joarder  wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Reference id -> 1c8f422059ae ("mm: change return type to
> vm_fault_t")
>
> Signed-off-by: Souptick Joarder 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
>  drivers/gpu/drm/i915/i915_gem.c | 15 ---
>  2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a42deeb..95b0d50 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -51,6 +51,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "i915_params.h"
>  #include "i915_reg.h"
> @@ -3363,7 +3364,7 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
> *dev_priv,
>  unsigned int flags);
>  int __must_check i915_gem_suspend(struct drm_i915_private *dev_priv);
>  void i915_gem_resume(struct drm_i915_private *dev_priv);
> -int i915_gem_fault(struct vm_fault *vmf);
> +vm_fault_t i915_gem_fault(struct vm_fault *vmf);
>  int i915_gem_object_wait(struct drm_i915_gem_object *obj,
>unsigned int flags,
>long timeout,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index dd89abd..bdac690 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1882,7 +1882,7 @@ int i915_gem_mmap_gtt_version(void)
>   * The current feature set supported by i915_gem_fault() and thus GTT mmaps
>   * is exposed via I915_PARAM_MMAP_GTT_VERSION (see 
> i915_gem_mmap_gtt_version).
>   */
> -int i915_gem_fault(struct vm_fault *vmf)
> +vm_fault_t i915_gem_fault(struct vm_fault *vmf)
>  {
>  #define MIN_CHUNK_PAGES ((1 << 20) >> PAGE_SHIFT) /* 1 MiB */
>   struct vm_area_struct *area = vmf->vma;
> @@ -1895,6 +1895,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>   pgoff_t page_offset;
>   unsigned int flags;
>   int ret;
> + vm_fault_t retval;

What's the point of changing the name? An unnecessary change.

BR,
Jani.

>
>   /* We don't use vmf->pgoff since that has the fake offset */
>   page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
> @@ -2000,7 +2001,7 @@ int i915_gem_fault(struct vm_fault *vmf)
>* and so needs to be reported.
>*/
>   if (!i915_terminally_wedged(_priv->gpu_error)) {
> - ret = VM_FAULT_SIGBUS;
> + retval = VM_FAULT_SIGBUS;
>   break;
>   }
>   case -EAGAIN:
> @@ -2017,21 +2018,21 @@ int i915_gem_fault(struct vm_fault *vmf)
>* EBUSY is ok: this just means that another thread
>* already did the job.
>*/
> - ret = VM_FAULT_NOPAGE;
> + retval = VM_FAULT_NOPAGE;
>   break;
>   case -ENOMEM:
> - ret = VM_FAULT_OOM;
> + retval = VM_FAULT_OOM;
>   break;
>   case -ENOSPC:
>   case -EFAULT:
> - ret = VM_FAULT_SIGBUS;
> + retval = VM_FAULT_SIGBUS;
>   break;
>   default:
>   WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", ret);
> - ret = VM_FAULT_SIGBUS;
> + retval = VM_FAULT_SIGBUS;
>   break;
>   }
> - return ret;
> + return retval;
>  }
>
>  static void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
> --
> 1.9.1
>

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

[Bug 176311] Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip

[bugzilla-daemon]

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

--- Comment #7 from Michel Dänzer (mic...@daenzer.net) ---
Does
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=daf8809626c0ee7a152f9c34058fc3b43385dd51
help for this, by any chance?

BTW, I made a mistake in comment 4, need to test xf86-video-amdgpu here, not
xf86-video-ati.

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

[Bug 199357] amdgpu: hang a few seconds after logging in, most likely due to regression

[bugzilla-daemon]

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

--- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) ---
Yes, the revert cc'ed stable so it will show up in 4.16 as well.

-- 
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: [Freedreno] [Intel-gfx] [PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

[Jordan Crouse]

On Mon, Apr 16, 2018 at 10:52:59AM -0700, Eric Anholt wrote:
> Chris Wilson  writes:
> 
> > Quoting Jordan Crouse (2018-04-05 23:06:53)
> >> On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote:
> >> > The i915 DRM driver very cleverly used ascii85 encoding for their
> >> > GPU state file. Move the encode functions to a general header file to
> >> > support other drivers that might be interested in the same
> >> > functionality.
> >> 
> >> In a previous version of this patch, Chris asked what tree I wanted this 
> >> applied
> >> to, and the answer is: I'm not sure?  I'm hoping that Rob will be cool with
> >> picking the rest up for msm-next for 4.18 but I'm okay with putting this
> >> particular patch wherever it is easiest for the maintainers.
> >
> > We are a bit late to sneak it into the 4.17 drm base via i915. I don't
> > anticipate any problems (for i915) with this patch going in through
> > msm-next, so happy to have it land there and percolate back to i915 3
> > months later.
> 
> I'd love to have it in drm-misc-next, so I can build a similar hang dump
> interface for vc5.  But most importantly, I'd like to have it somewhere
> soon.

I'll fix the bot error and push it up again today.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Tomi Valkeinen]

Hi Rob,

On 09/04/18 21:17, Rob Herring wrote:

>>> For HDMI, you can't know in advance what resolution will be. So I
>>> think you always need to reserve 2 planes. Now, if you want to reduce
>>
>> We can decide not to support 2k+ resolutions for HDMI, which, with this
>> series, happens by not reserving dual-plane for the HDMI.
> 
> Right. So turn this around. Define in DT what is the maximum
> resolution supported for HDMI and configure the planes based on that.

But the kernel cannot know what the user wants to do, so it cannot
configure the planes. If we have an HDMI output which supports 2k+ and a
-2k LCD, and 4 hw planes, we can set up the planes at least in the
following ways:

- One virtual plane on HDMI, two normal planes on LCD. Here the normal
planes can also be used on the HDMI, as long as the input width is -2k.

- One virtual plane on HDMI, one virtual plane on LCD, but sometimes
both planes on the same display (either HDMI or LCD).

- No virtual planes (and fbdev support disabled). This needs the
userspace to take care not to configure 2k+ planes. But considering that
the modes supported are still quit close to 2k in width, I believe
upscaling a 2k plane cover the whole display would provide quite ok image.

Each of those requires a different virtual plane setup.

>> But reserve how many of the planes? We have N planes and M displays. For
>> some of the displays we know they're 2k+, some are known to be -2k and
>> some are unknown. The driver can't independently make any sensible
>> static reservation of the planes for the displays, because it doesn't
>> know what the user wants to do.
> 
> After you've handled HDMI as above and any permanently attached panels
> with fixed resolutions, what is left for a user to configure? Perhaps
> only one display can support an overlay at that point because you are
> out of planes?

I think I covered this in the example use cases above.

>> So either we reserve the extra planes at runtime on demand, making it
>> difficult to manage for the userspace, or we rely on the user to give
>> the driver a static partitioning of the planes according to the user's
>> use case.
> 
> And by user, who do you mean exactly? The use case is tied to the
> board design and product or tied to the whims of an end user (e.g. I
> want to do video playback with overlay to disp 2)? You should equate
> users making DT changes with telling users to update/change their
> BIOS.

By user I mean the owner of the device, but it in some cases it could be
the vendor too.

If we have a board with HDMI that can support 2k+, then the board vendor
could provide DT files that do not specify virtual planes (so no 2k+),
but give instructions how to define them for the users who want 2k+. So
here the end user needs to deal with the static partitioning.

If we have a board with a fixed resolution 2k+ LCD, then the vendor has
to have a virtual plane defined in the DT, and the vendor has to pick a
configuration that it thinks is most useful.

And yes, it sucks to have to make changes in the DT or BIOS, but I still
don't see a (good) alternative.

I think one option is to have the detailed DT configuration optional:

We'd have a flag in the DT to mark that a display supports 2k+ (or the
max-resolution property as you suggested). Based on that, the driver
guesses what kind of setup the user wants, which probably is just to set
up planes in a way that each display has a fully functional "root"
plane, and then split the remaining ones in some way.

But the user could also have detailed DT descriptions for the planes
when he needs a more special setup.

 Tomi

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

Re: [PATCH hwc v2 05/18] drm_hwcomposer: Enable resource manager support

[Sean Paul]

On Wed, Apr 11, 2018 at 04:22:16PM +0100, Alexandru Gheorghe wrote:
> Use the newly added ResourceManager for creating and detecting all the
> drm devices instead of assuming that there is only one device.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---



> index 4cca48c..4cdcd87 100644
> --- a/drmresources.h
> +++ b/drmresources.h
> @@ -17,22 +17,26 @@
>  #ifndef ANDROID_DRM_H_
>  #define ANDROID_DRM_H_
>  
> +#include 
>  #include "drmconnector.h"
>  #include "drmcrtc.h"
>  #include "drmencoder.h"
>  #include "drmeventlistener.h"
>  #include "drmplane.h"
> -
> -#include 
> +#include "platform.h"
> +#include "resourcemanager.h"
>  
>  namespace android {
>  
> +class ResourceManager;
> +
>  class DrmResources {

One more thing I've been thinking about. Let's rename this to DrmDevice now that
we can have more than one. It's immediately obvious what a collection of
DrmDevices is, it's less obvious if they're DrmResources. I think
ResourceManager is Ok to keep, but if you think there's a better name I'm open
to that.

Sean

>   public:
>DrmResources();
>~DrmResources();
>  
> -  int Init();
> +  int Init(ResourceManager *resource_manager, char *path,
> +   int start_display_index);
>  
>int fd() const {
>  return fd_.get();
> @@ -58,6 +62,7 @@ class DrmResources {
>DrmCrtc *GetCrtcForDisplay(int display) const;
>DrmPlane *GetPlane(uint32_t id) const;
>DrmEventListener *event_listener();
> +  ResourceManager *resource_manager();
>  
>int GetPlaneProperty(const DrmPlane , const char *prop_name,
> DrmProperty *property);
> @@ -71,6 +76,7 @@ class DrmResources {
>  
>int CreatePropertyBlob(void *data, size_t length, uint32_t *blob_id);
>int DestroyPropertyBlob(uint32_t blob_id);
> +  bool HandlesDisplay(int display) const;
>  
>   private:
>int TryEncoderForDisplay(int display, DrmEncoder *enc);
> @@ -90,6 +96,8 @@ class DrmResources {
>  
>std::pair min_resolution_;
>std::pair max_resolution_;
> +  std::map displays_;
> +  ResourceManager *resource_manager_;
>  };
>  }
>  
> -- 
> 2.7.4
> 

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

Re: [PATCH hwc v2 05/18] drm_hwcomposer: Enable resource manager support

[Sean Paul]

On Tue, Apr 17, 2018 at 02:43:17PM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Sean,
> 
> On Mon, Apr 16, 2018 at 03:54:02PM -0400, Sean Paul wrote:
> > On Wed, Apr 11, 2018 at 04:22:16PM +0100, Alexandru Gheorghe wrote:
> > > Use the newly added ResourceManager for creating and detecting all the
> > > drm devices instead of assuming that there is only one device.
> > > 
> > > Signed-off-by: Alexandru Gheorghe 
> > > ---



> > > diff --git a/drmresources.cpp b/drmresources.cpp
> > > index 32dd376..a5ddda0 100644
> > > --- a/drmresources.cpp
> > > +++ b/drmresources.cpp
> > > @@ -42,10 +42,9 @@ DrmResources::~DrmResources() {
> > >event_listener_.Exit();
> > >  }
> > >  
> > > -int DrmResources::Init() {
> > > -  char path[PROPERTY_VALUE_MAX];
> > > -  property_get("hwc.drm.device", path, "/dev/dri/card0");
> > > -
> > > +int DrmResources::Init(ResourceManager *resource_manager, char *path,
> > > +   int start_display_index) {
> > > +  resource_manager_ = resource_manager;
> > 
> > You can avoid the backpointer if you just pass the RM to the right places 
> > (looks
> > like compositor + composition). Bonus points if you can remove drm_ from 
> > those
> > objects once you've done that.
> 
> That's the thing Compositor/Composition already had drm_, hence the
> need of the backpointer. Didn't want to touch that as well. I suppose
> there is no strong reason why both Compositor & Composition shouldn't
> have just a ResourceManager object.

Yeah, exactly what I was thinking. It'll be a bit more refactoring, but worth it
IMO.



> > > diff --git a/drmresources.h b/drmresources.h
> > > index 4cca48c..4cdcd87 100644
> > > --- a/drmresources.h
> > > +++ b/drmresources.h
> > > @@ -17,22 +17,26 @@
> > >  #ifndef ANDROID_DRM_H_
> > >  #define ANDROID_DRM_H_
> > >  
> > > +#include 
> > >  #include "drmconnector.h"
> > >  #include "drmcrtc.h"
> > >  #include "drmencoder.h"
> > >  #include "drmeventlistener.h"
> > >  #include "drmplane.h"
> > > -
> > > -#include 
> > 
> > Why this change?
> 
> I blame clang-format-diff-3.8 -i. I suppose it should be in a different
> commit.

I'd rather fix it at the source. If stdint.h include needs to move, that
probably means one of our headers needs to include it. So let's figure out which
needs it and add it there instead of shuffling things here.

Sean

> > 
> > > +#include "platform.h"
> > > +#include "resourcemanager.h"
> > >  
> > >  namespace android {
> > >  
> > > +class ResourceManager;
> > > +
> > >  class DrmResources {
> > >   public:
> > >DrmResources();
> > >~DrmResources();
> > >  
> > > -  int Init();
> > > +  int Init(ResourceManager *resource_manager, char *path,
> > > +   int start_display_index);
> > >  
> > >int fd() const {
> > >  return fd_.get();
> > > @@ -58,6 +62,7 @@ class DrmResources {
> > >DrmCrtc *GetCrtcForDisplay(int display) const;
> > >DrmPlane *GetPlane(uint32_t id) const;
> > >DrmEventListener *event_listener();
> > > +  ResourceManager *resource_manager();
> > >  
> > >int GetPlaneProperty(const DrmPlane , const char *prop_name,
> > > DrmProperty *property);
> > > @@ -71,6 +76,7 @@ class DrmResources {
> > >  
> > >int CreatePropertyBlob(void *data, size_t length, uint32_t *blob_id);
> > >int DestroyPropertyBlob(uint32_t blob_id);
> > > +  bool HandlesDisplay(int display) const;
> > >  
> > >   private:
> > >int TryEncoderForDisplay(int display, DrmEncoder *enc);
> > > @@ -90,6 +96,8 @@ class DrmResources {
> > >  
> > >std::pair min_resolution_;
> > >std::pair max_resolution_;
> > > +  std::map displays_;
> > > +  ResourceManager *resource_manager_;
> > >  };
> > >  }
> > >  
> > > -- 
> > > 2.7.4
> > > 
> > 
> > -- 
> > Sean Paul, Software Engineer, Google / Chromium OS
> 
> -- 
> Cheers,
> Alex G

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

RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Joonas Lahtinen]

Quoting Jani Nikula (2018-04-17 12:02:52)
> On Mon, 16 Apr 2018, "Srivatsa, Anusha"  wrote:
> >>-Original Message-
> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> >>Sent: Wednesday, April 11, 2018 5:27 AM
> >>To: Ian W MORRISON 
> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha
> >>; Wajdeczko, Michal
> >>; Greg KH ;
> >>airl...@linux.ie; joonas.lahti...@linux.intel.com; 
> >>linux-ker...@vger.kernel.org;
> >>sta...@vger.kernel.org; intel-...@lists.freedesktop.org; dri-
> >>de...@lists.freedesktop.org
> >>Subject: Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for
> >>Geminilake
> >>
> >>On Wed, 11 Apr 2018, Ian W MORRISON  wrote:
> >>> 
> >>>
> 
>  NAK on indiscriminate Cc: stable. There are zero guarantees that
>  older kernels will work with whatever firmware you throw at them.
> 
> >>>
> >>> I included 'Cc: stable' so the patch would get added to the v4.16 and
> >>> v4.15 kernels which I have tested with the patch. I found that earlier
> >>> kernels didn't support the 'linux-firmware' package required to get
> >>> wifi working on Intel's new Gemini Lake NUC.
> >>
> >>You realize that this patch should have nothing to do with wifi?
> >>
> >>Rodrigo, Anusha, if you think Cc: stable is appropriate, please indicate 
> >>the specific
> >>versions of stable it is appropriate for.
> >
> > Hi Jani,
> >
> > The stable kernel version is 4.12 and beyond.
> > It is appropriate to add the CC: stable in my opinion
> 
> Who tested the firmware with v4.12 and later? We only have the CI
> results against *current* drm-tip. We don't even know about v4.16.
> 
> I'm not going to ack and take responsibility for the stable backports
> unless someone actually comes forward with credible Tested-bys.

And even then, some distros will be surprised of the new MODULE_FIRMWARE
and will need to update the linux-firmware package, too.

Regards, Joonas

> 
> BR,
> Jani.
> 
> 
> >
> > Anusha
> >>BR,
> >>Jani.
> >>
> >>>
> 
>  PS. How is this a "RESEND"? I haven't seen this before.
> 
> >>>
> >>> It is a 'RESEND' for that very reason. I initially sent the patch to
> >>> the same people as a similar patch
> >>> (https://patchwork.kernel.org/patch/10143637/) however after realising
> >>> this omitted required addresses I added them and resent the patch.
> >>>
> >>> Best regards,
> >>> Ian
> >>
> >>--
> >>Jani Nikula, Intel Open Source Technology Center
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 01/18] drm_hwcomposer: vsyncworker: Fix uninitialized enabled_ field

[Alexandru-Cosmin Gheorghe]

On Tue, Apr 17, 2018 at 09:45:06AM -0400, Sean Paul wrote:
> On Mon, Apr 16, 2018 at 01:18:53PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Mon, Apr 16, 2018 at 12:30:13PM +0200, Robert Foss wrote:
> > 
> > Hi Rob,
> > 
> > Thanks for the review.
> > 
> > > Hey Alexandru,
> > > 
> > > Feel free to add:
> > > Signed-off-by: Robert Foss 
> > >
> > 
> > Should I re-send this 3 patches or could you just pushed them to
> > master and adding your SoB in the process?
> 
> I've pushed patches 1 & 3 with Robert's Ack. I'll review the rest this morning
> at which time you can send a v2 with the unapplied patches. Alternatively, if
> you want to try out the new gitlab flow, you can send v2 via a merge request
> there.

Thanks.

I'm all for trying new things. So, I will give gitlab flow a chance.

> 
> Sean
> 
> >  
> > > 
> > > Rob.
> > > 
> > > On 04/11/2018 05:22 PM, Alexandru Gheorghe wrote:
> > > >Signed-off-by: Alexandru Gheorghe 
> > > >---
> > > >  vsyncworker.cpp | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > >diff --git a/vsyncworker.cpp b/vsyncworker.cpp
> > > >index 3ad16fe..3bfe4be 100644
> > > >--- a/vsyncworker.cpp
> > > >+++ b/vsyncworker.cpp
> > > >@@ -35,6 +35,7 @@ VSyncWorker::VSyncWorker()
> > > >  : Worker("vsync", HAL_PRIORITY_URGENT_DISPLAY),
> > > >drm_(NULL),
> > > >display_(-1),
> > > >+  enabled_(false),
> > > >last_timestamp_(-1) {
> > > >  }
> > > >
> > 
> > -- 
> > Cheers,
> > Alex G
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH hwc v2 08/18] drm_hwcomposer: Parse and store possible_clones information

[Alexandru-Cosmin Gheorghe]

Hi Sean,

On Mon, Apr 16, 2018 at 04:19:14PM -0400, Sean Paul wrote:
> On Wed, Apr 11, 2018 at 04:22:19PM +0100, Alexandru Gheorghe wrote:
> > drmModeEncoder has a field called possible_clones. It's a bit mask
> > which tells if the encoder could be simultaneously connected, to the
> > same CRTC, with the encoders specified in the possible_clones mask.
> > 
> > Signed-off-by: Alexandru Gheorghe 
> > ---
> >  drmencoder.cpp   | 8 
> >  drmencoder.h | 4 
> >  drmresources.cpp | 9 -
> >  3 files changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drmencoder.cpp b/drmencoder.cpp
> > index 1da7ec3..ff675f5 100644
> > --- a/drmencoder.cpp
> > +++ b/drmencoder.cpp
> > @@ -39,6 +39,14 @@ DrmCrtc *DrmEncoder::crtc() const {
> >return crtc_;
> >  }
> >  
> > +bool DrmEncoder::can_clone(DrmEncoder *encoder) {
> > +  return possible_clones_.find(encoder) != possible_clones_.end();
> > +}
> 
> The find() call is probably enough to justify CamelCase for this function. 
> FTR,
> I _hate_ this part of the style guide and wish I had just picked one or the
> other.
> 
> To improve readability, can you also change the name of "encoder" to
> "possible_clone" like below so it's super obvious what this does?
> 

Sure, will do.

> > +
> > +void DrmEncoder::add_possible_clone(DrmEncoder *possible_clone) {
> > +  possible_clones_[possible_clone] = true;
> > +}
> > +
> >  void DrmEncoder::set_crtc(DrmCrtc *crtc) {
> >crtc_ = crtc;
> >set_display(crtc->display());
> > diff --git a/drmencoder.h b/drmencoder.h
> > index 7e06691..5e7c010 100644
> > --- a/drmencoder.h
> > +++ b/drmencoder.h
> > @@ -21,6 +21,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> 
> Alphabetical

Sure, wil do.

> 
> >  #include 
> >  
> >  namespace android {
> > @@ -43,6 +44,8 @@ class DrmEncoder {
> >const std::vector _crtcs() const {
> >  return possible_crtcs_;
> >}
> > +  bool can_clone(DrmEncoder *encoder);
> > +  void add_possible_clone(DrmEncoder *possible_clone);
> >  
> >   private:
> >uint32_t id_;
> > @@ -50,6 +53,7 @@ class DrmEncoder {
> >int display_;
> >  
> >std::vector possible_crtcs_;
> > +  std::map possible_clones_;
> >  };
> >  }
> >  
> > diff --git a/drmresources.cpp b/drmresources.cpp
> > index a5ddda0..39f50be 100644
> > --- a/drmresources.cpp
> > +++ b/drmresources.cpp
> > @@ -97,6 +97,7 @@ int DrmResources::Init(ResourceManager *resource_manager, 
> > char *path,
> >  crtcs_.emplace_back(std::move(crtc));
> >}
> >  
> > +  std::vector possible_clones;
> >for (int i = 0; !ret && i < res->count_encoders; ++i) {
> >  drmModeEncoderPtr e = drmModeGetEncoder(fd(), res->encoders[i]);
> >  if (!e) {
> > @@ -117,12 +118,18 @@ int DrmResources::Init(ResourceManager 
> > *resource_manager, char *path,
> >  
> >  std::unique_ptr enc(
> >  new DrmEncoder(e, current_crtc, possible_crtcs));
> > -
> > +possible_clones.push_back(e->possible_clones);
> >  drmModeFreeEncoder(e);
> >  
> >  encoders_.emplace_back(std::move(enc));
> >}
> >  
> > +  for (uint32_t i = 0; i < encoders_.size(); i++) {
> > +for (uint32_t j = 0; j < encoders_.size(); j++)
> 
> for (auto : encoders_) {
>   for (auto : encoders_) {
> 
> Or something similarly C++'y, looping through indices is sooo last decade :-)

Oldie but goldie. 
I do need the index in order to check the possible clones mask.
I will try to find something more millennial/Generation z :).

> 
> 
> > +  if (possible_clones[i] & (1 << j))
> > +encoders_[i]->add_possible_clone(encoders_[j].get());
> > +  }
> > +
> >for (int i = 0; !ret && i < res->count_connectors; ++i) {
> >  drmModeConnectorPtr c = drmModeGetConnector(fd(), res->connectors[i]);
> >  if (!c) {
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #32 from MirceaKitsune  ---
(In reply to iive from comment #31)

Sounds a lot more complicated, but I'm gladly willing to try it as long as
there's no risk of anything permanently breaking my system.

The main problem is that I wasn't able to get the SysRq keys working in
openSUSE Tumbleweed, which I tried as to enable the "REISUB" keys. I could
really use clear instructions on how to enable and test them in openSUSE...
ideally during runtime without having to make any permanent system changes.

I need to remember how apitrace works, been a while since I used that. Also I
remember it generated really a huge file, and the longer you run the program
for the bigger it gets... if it doesn't happen within a few seconds I may gave
a +1 GB trace, and I'm not sure where I can share that with the devs online.

One thing to note: I have two computers at home, with mine being the crashy one
and my mother's being an old and slow but stable machine. I can use SSH to
connect in between them from bash. The problem is that the moment my machine
freezes, its SSH connection instantly dies on the other PC as well... therefore
I'm not sure how helpful this option is.

The "r_shadows 2" option in Xonotic clearly makes a difference: Without it the
crash only occurs after 3 hours... with it it's anywhere between a few seconds
and at most 45 minutes. Definitely my best test case so far.

-- 
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 hwc v2 07/18] drm_hwcomposer: Add display field to Drmencoder

[Alexandru-Cosmin Gheorghe]

Hi Sean,

On Mon, Apr 16, 2018 at 04:02:07PM -0400, Sean Paul wrote:
> On Wed, Apr 11, 2018 at 04:22:18PM +0100, Alexandru Gheorghe wrote:
> > In the current implementation TryEncoderForDisplay just looks
> > at the crtc linked to the display, if that's not assigned to
> > a display it means the encoder could be used, otherwise iterate
> > to the list of possible_crtcs and find one which is not used.
> > 
> > This logic works fine when you have just one encoder connected to a
> > crtc but with two or more, like is the case when we attach a writeback
> > connector, we need to know if we already assigned the encoder to a
> > display.
> > 
> > Signed-off-by: Alexandru Gheorghe 
> > ---
> >  drmencoder.cpp | 14 ++
> >  drmencoder.h   |  4 
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/drmencoder.cpp b/drmencoder.cpp
> > index 3d762f3..1da7ec3 100644
> > --- a/drmencoder.cpp
> > +++ b/drmencoder.cpp
> > @@ -27,6 +27,7 @@ DrmEncoder::DrmEncoder(drmModeEncoderPtr e, DrmCrtc 
> > *current_crtc,
> > const std::vector _crtcs)
> >  : id_(e->encoder_id),
> >crtc_(current_crtc),
> > +  display_(-1),
> >possible_crtcs_(possible_crtcs) {
> >  }
> >  
> > @@ -40,5 +41,18 @@ DrmCrtc *DrmEncoder::crtc() const {
> >  
> >  void DrmEncoder::set_crtc(DrmCrtc *crtc) {
> >crtc_ = crtc;
> > +  set_display(crtc->display());
> > +}
> > +
> > +int DrmEncoder::display() const {
> > +  return display_;
> > +}
> > +
> > +void DrmEncoder::set_display(int display) {
> > +  display_ = display;
> > +}
> 
> Instead of adding this, just call set_crtc() in TryEncoderForDisplay() for the
> already-bound case. That way we only have one entry point for this.

Fair enough, I will remove set_display.

> 
> > +
> > +bool DrmEncoder::can_bind(int display) const {
> > +  return display_ == -1 || display_ == display;
> >  }
> >  }
> > diff --git a/drmencoder.h b/drmencoder.h
> > index 58ccbfb..7e06691 100644
> > --- a/drmencoder.h
> > +++ b/drmencoder.h
> > @@ -36,6 +36,9 @@ class DrmEncoder {
> >  
> >DrmCrtc *crtc() const;
> >void set_crtc(DrmCrtc *crtc);
> > +  bool can_bind(int display) const;
> > +  void set_display(int display);
> > +  int display() const;
> >  
> >const std::vector _crtcs() const {
> >  return possible_crtcs_;
> > @@ -44,6 +47,7 @@ class DrmEncoder {
> >   private:
> >uint32_t id_;
> >DrmCrtc *crtc_;
> > +  int display_;
> >  
> >std::vector possible_crtcs_;
> >  };
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH hwc v2 06/18] drm_hwcomposer: Add writeback connector support

[Alexandru-Cosmin Gheorghe]

Hi Sean,

On Mon, Apr 16, 2018 at 03:59:07PM -0400, Sean Paul wrote:
> On Wed, Apr 11, 2018 at 04:22:17PM +0100, Alexandru Gheorghe wrote:
> > Writeback connector is a special case of connector, which can be
> > linked to a CRTC in order to get the result of the composition back to
> > a memory buffer. This had not been merged to the mainline kernel yet,
> > latest version of the kernel patches could be found here [1].
> > 
> > [1] 
> > https://lists.freedesktop.org/archives/dri-devel/2018-February/167703.html
> > 
> > Signed-off-by: Alexandru Gheorghe 
> > ---
> >  drmconnector.cpp | 42 +-
> >  drmconnector.h   |  7 +++
> >  2 files changed, 48 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drmconnector.cpp b/drmconnector.cpp
> > index 145518f..e482832 100644
> > --- a/drmconnector.cpp
> > +++ b/drmconnector.cpp
> > @@ -52,6 +52,26 @@ int DrmConnector::Init() {
> >  ALOGE("Could not get CRTC_ID property\n");
> >  return ret;
> >}
> > +  if (writeback()) {
> > +ret = drm_->GetConnectorProperty(*this, "WRITEBACK_PIXEL_FORMATS",
> > + _pixel_formats_);
> > +if (ret) {
> > +  ALOGE("Could not get WRITEBACK_PIXEL_FORMATS connector_id = %d\n", 
> > id_);
> > +  return ret;
> > +}
> > +ret =
> > +drm_->GetConnectorProperty(*this, "WRITEBACK_FB_ID", 
> > _fb_id_);
> 
> Please break on the function arguments instead of the =

It's clang-format-diff-3.8 fault again.
Will do.

> 
> 
> > +if (ret) {
> > +  ALOGE("Could not get WRITEBACK_FB_ID connector_id = %d\n", id_);
> > +  return ret;
> > +}
> > +ret = drm_->GetConnectorProperty(*this, "WRITEBACK_OUT_FENCE_PTR",
> > + _out_fence_);
> 
> Like this :)

That's me :).

> 
> With that,
> 
> Reviewed-by: Sean Paul 
> 
> 
> 
> 
> > +if (ret) {
> > +  ALOGE("Could not get WRITEBACK_OUT_FENCE_PTR connector_id = %d\n", 
> > id_);
> > +  return ret;
> > +}
> > +  }
> >return 0;
> >  }
> >  
> > @@ -78,8 +98,16 @@ bool DrmConnector::external() const {
> >   type_ == DRM_MODE_CONNECTOR_VGA;
> >  }
> >  
> > +bool DrmConnector::writeback() const {
> > +#ifdef DRM_MODE_CONNECTOR_WRITEBACK
> > +  return type_ == DRM_MODE_CONNECTOR_WRITEBACK;
> > +#else
> > +  return false;
> > +#endif
> > +}
> > +
> >  bool DrmConnector::valid_type() const {
> > -  return internal() || external();
> > +  return internal() || external() || writeback();
> >  }
> >  
> >  int DrmConnector::UpdateModes() {
> > @@ -130,6 +158,18 @@ const DrmProperty ::crtc_id_property() 
> > const {
> >return crtc_id_property_;
> >  }
> >  
> > +const DrmProperty ::writeback_pixel_formats() const {
> > +  return writeback_pixel_formats_;
> > +}
> > +
> > +const DrmProperty ::writeback_fb_id() const {
> > +  return writeback_fb_id_;
> > +}
> > +
> > +const DrmProperty ::writeback_out_fence() const {
> > +  return writeback_out_fence_;
> > +}
> > +
> >  DrmEncoder *DrmConnector::encoder() const {
> >return encoder_;
> >  }
> > diff --git a/drmconnector.h b/drmconnector.h
> > index 5601e06..e139730 100644
> > --- a/drmconnector.h
> > +++ b/drmconnector.h
> > @@ -46,6 +46,7 @@ class DrmConnector {
> >  
> >bool internal() const;
> >bool external() const;
> > +  bool writeback() const;
> >bool valid_type() const;
> >  
> >int UpdateModes();
> > @@ -58,6 +59,9 @@ class DrmConnector {
> >  
> >const DrmProperty _property() const;
> >const DrmProperty _id_property() const;
> > +  const DrmProperty _pixel_formats() const;
> > +  const DrmProperty _fb_id() const;
> > +  const DrmProperty _out_fence() const;
> >  
> >const std::vector _encoders() const {
> >  return possible_encoders_;
> > @@ -88,6 +92,9 @@ class DrmConnector {
> >  
> >DrmProperty dpms_property_;
> >DrmProperty crtc_id_property_;
> > +  DrmProperty writeback_pixel_formats_;
> > +  DrmProperty writeback_fb_id_;
> > +  DrmProperty writeback_out_fence_;
> >  
> >std::vector possible_encoders_;
> >  };
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH hwc v2 01/18] drm_hwcomposer: vsyncworker: Fix uninitialized enabled_ field

[Sean Paul]

On Mon, Apr 16, 2018 at 01:18:53PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Mon, Apr 16, 2018 at 12:30:13PM +0200, Robert Foss wrote:
> 
> Hi Rob,
> 
> Thanks for the review.
> 
> > Hey Alexandru,
> > 
> > Feel free to add:
> > Signed-off-by: Robert Foss 
> >
> 
> Should I re-send this 3 patches or could you just pushed them to
> master and adding your SoB in the process?

I've pushed patches 1 & 3 with Robert's Ack. I'll review the rest this morning
at which time you can send a v2 with the unapplied patches. Alternatively, if
you want to try out the new gitlab flow, you can send v2 via a merge request
there.

Sean

>  
> > 
> > Rob.
> > 
> > On 04/11/2018 05:22 PM, Alexandru Gheorghe wrote:
> > >Signed-off-by: Alexandru Gheorghe 
> > >---
> > >  vsyncworker.cpp | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > >diff --git a/vsyncworker.cpp b/vsyncworker.cpp
> > >index 3ad16fe..3bfe4be 100644
> > >--- a/vsyncworker.cpp
> > >+++ b/vsyncworker.cpp
> > >@@ -35,6 +35,7 @@ VSyncWorker::VSyncWorker()
> > >  : Worker("vsync", HAL_PRIORITY_URGENT_DISPLAY),
> > >drm_(NULL),
> > >display_(-1),
> > >+  enabled_(false),
> > >last_timestamp_(-1) {
> > >  }
> > >
> 
> -- 
> Cheers,
> Alex G

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

Re: [PATCH hwc v2 05/18] drm_hwcomposer: Enable resource manager support

[Alexandru-Cosmin Gheorghe]

Hi Sean,

On Mon, Apr 16, 2018 at 03:54:02PM -0400, Sean Paul wrote:
> On Wed, Apr 11, 2018 at 04:22:16PM +0100, Alexandru Gheorghe wrote:
> > Use the newly added ResourceManager for creating and detecting all the
> > drm devices instead of assuming that there is only one device.
> > 
> > Signed-off-by: Alexandru Gheorghe 
> > ---
> >  drmhwctwo.cpp| 34 +-
> >  drmhwctwo.h  |  4 +---
> >  drmresources.cpp | 25 ++---
> >  drmresources.h   | 14 +++---
> >  4 files changed, 43 insertions(+), 34 deletions(-)
> > 
> > diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
> > index dfca1a6..cddd5da 100644
> > --- a/drmhwctwo.cpp
> > +++ b/drmhwctwo.cpp
> > @@ -58,40 +58,32 @@ DrmHwcTwo::DrmHwcTwo() {
> >  }
> >  
> >  HWC2::Error DrmHwcTwo::Init() {
> > -  int ret = drm_.Init();
> > +  int ret = resource_manager_.Init();
> >if (ret) {
> > -ALOGE("Can't initialize drm object %d", ret);
> > +ALOGE("Can't initialize the resource manager %d", ret);
> >  return HWC2::Error::NoResources;
> >}
> >  
> > -  importer_.reset(Importer::CreateInstance(_));
> > -  if (!importer_) {
> > -ALOGE("Failed to create importer instance");
> > +  DrmResources *drm = 
> > resource_manager_.GetDrmResources(HWC_DISPLAY_PRIMARY);
> > +  std::shared_ptr importer =
> > +  resource_manager_.GetImporter(HWC_DISPLAY_PRIMARY);
> > +  if (!drm || !importer) {
> > +ALOGE("Failed to get a valid drmresource and importer");
> >  return HWC2::Error::NoResources;
> >}
> > +  displays_.emplace(
> > +  std::piecewise_construct, std::forward_as_tuple(HWC_DISPLAY_PRIMARY),
> > +  std::forward_as_tuple(drm, importer, resource_manager_.GetGralloc(),
> > +HWC_DISPLAY_PRIMARY, 
> > HWC2::DisplayType::Physical));
> >  
> > -  ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
> > -  (const hw_module_t **)_);
> > -  if (ret) {
> > -ALOGE("Failed to open gralloc module %d", ret);
> > -return HWC2::Error::NoResources;
> > -  }
> > -
> > -  displays_.emplace(std::piecewise_construct,
> > -std::forward_as_tuple(HWC_DISPLAY_PRIMARY),
> > -std::forward_as_tuple(_, importer_, gralloc_,
> > -  HWC_DISPLAY_PRIMARY,
> > -  HWC2::DisplayType::Physical));
> > -
> > -  DrmCrtc *crtc = 
> > drm_.GetCrtcForDisplay(static_cast(HWC_DISPLAY_PRIMARY));
> > +  DrmCrtc *crtc = 
> > drm->GetCrtcForDisplay(static_cast(HWC_DISPLAY_PRIMARY));
> >if (!crtc) {
> >  ALOGE("Failed to get crtc for display %d",
> >static_cast(HWC_DISPLAY_PRIMARY));
> >  return HWC2::Error::BadDisplay;
> >}
> > -
> >std::vector display_planes;
> > -  for (auto  : drm_.planes()) {
> > +  for (auto  : drm->planes()) {
> >  if (plane->GetCrtcSupported(*crtc))
> >display_planes.push_back(plane.get());
> >}
> > diff --git a/drmhwctwo.h b/drmhwctwo.h
> > index 0490e2a..beb5d2d 100644
> > --- a/drmhwctwo.h
> > +++ b/drmhwctwo.h
> > @@ -262,9 +262,7 @@ class DrmHwcTwo : public hwc2_device_t {
> >HWC2::Error RegisterCallback(int32_t descriptor, hwc2_callback_data_t 
> > data,
> > hwc2_function_pointer_t function);
> >  
> > -  DrmResources drm_;
> > -  std::shared_ptr importer_;  // Shared with HwcDisplay
> > -  const gralloc_module_t *gralloc_;
> > +  ResourceManager resource_manager_;
> >std::map displays_;
> >std::map callbacks_;
> >  };
> > diff --git a/drmresources.cpp b/drmresources.cpp
> > index 32dd376..a5ddda0 100644
> > --- a/drmresources.cpp
> > +++ b/drmresources.cpp
> > @@ -42,10 +42,9 @@ DrmResources::~DrmResources() {
> >event_listener_.Exit();
> >  }
> >  
> > -int DrmResources::Init() {
> > -  char path[PROPERTY_VALUE_MAX];
> > -  property_get("hwc.drm.device", path, "/dev/dri/card0");
> > -
> > +int DrmResources::Init(ResourceManager *resource_manager, char *path,
> > +   int start_display_index) {
> > +  resource_manager_ = resource_manager;
> 
> You can avoid the backpointer if you just pass the RM to the right places 
> (looks
> like compositor + composition). Bonus points if you can remove drm_ from those
> objects once you've done that.

That's the thing Compositor/Composition already had drm_, hence the
need of the backpointer. Didn't want to touch that as well. I suppose
there is no strong reason why both Compositor & Composition shouldn't
have just a ResourceManager object.

> 
> >/* TODO: Use drmOpenControl here instead */
> >fd_.Set(open(path, O_RDWR));
> >if (fd() < 0) {
> > @@ -76,8 +75,8 @@ int DrmResources::Init() {
> >max_resolution_ =
> >std::pair(res->max_width, res->max_height);
> >  
> > -  bool found_primary = false;
> > -  int display_num = 1;
> > +  bool 

Re: [PATCH] CHROMIUM: drm/rockchip: Disable blending for win0

[Sean Paul]

On Tue, Apr 17, 2018 at 09:37:44AM -0400, Sean Paul wrote:
> On Mon, Apr 16, 2018 at 03:22:15PM -0700, Kristian H. Kristensen wrote:
> > Blending win0 with the background color doesn't seem to work
> > correctly. We only get the background color, no matter the contents of
> > the win0 framebuffer.  However, blending pre-multiplied color with the
> > default opaque black default background color is a no-op, so we can
> > just disable blending to get the correct result.
> > 
> > Signed-off-by: Kristian H. Kristensen 
> > Cc: Sandy Huang 
> > Cc: Sean Paul 
> 
> Sandy, when you push this, could you please remove the CHROMIUM: prefix from 
> the
> subject?
> 
> Reviewed-by: Sean Paul 

Sigh. I should read replies before opening my mouth. Looks like you'll need to
rebase on drm-misc-next and fix the compile issue.

Sean

> 
> 
> > ---
> > As per Eric's suggestion, we can just disable blending. This replaces
> > the previous "Filter out alpha formats for primary plane" patch.
> > 
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index fae37b1cd691..1c1dd11d489a 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -961,7 +961,14 @@ static void vop_plane_atomic_update(struct drm_plane 
> > *plane,
> > rb_swap = has_rb_swapped(fb->format->format);
> > VOP_WIN_SET(vop, win, rb_swap, rb_swap);
> >  
> > -   if (is_alpha_support(fb->format->format)) {
> > +   /*
> > +* Blending win0 with the background color doesn't seem to work
> > +* correctly. We only get the background color, no matter the contents
> > +* of the win0 framebuffer.  However, blending pre-multiplied color
> > +* with the default opaque black default background color is a no-op,
> > +* so we can just disable blending to get the correct result.
> > +*/
> > +   if (is_alpha_support(fb->format->format) && win_index > 0) {
> > VOP_WIN_SET(vop, win, dst_alpha_ctl,
> > DST_FACTOR_M0(ALPHA_SRC_INVERSE));
> > val = SRC_ALPHA_EN(1) | SRC_COLOR_M0(ALPHA_SRC_PRE_MUL) |
> > -- 
> > 2.17.0.484.g0c8726318c-goog
> > 
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH] CHROMIUM: drm/rockchip: Disable blending for win0

[Sean Paul]

On Mon, Apr 16, 2018 at 03:22:15PM -0700, Kristian H. Kristensen wrote:
> Blending win0 with the background color doesn't seem to work
> correctly. We only get the background color, no matter the contents of
> the win0 framebuffer.  However, blending pre-multiplied color with the
> default opaque black default background color is a no-op, so we can
> just disable blending to get the correct result.
> 
> Signed-off-by: Kristian H. Kristensen 
> Cc: Sandy Huang 
> Cc: Sean Paul 

Sandy, when you push this, could you please remove the CHROMIUM: prefix from the
subject?

Reviewed-by: Sean Paul 


> ---
> As per Eric's suggestion, we can just disable blending. This replaces
> the previous "Filter out alpha formats for primary plane" patch.
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fae37b1cd691..1c1dd11d489a 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -961,7 +961,14 @@ static void vop_plane_atomic_update(struct drm_plane 
> *plane,
>   rb_swap = has_rb_swapped(fb->format->format);
>   VOP_WIN_SET(vop, win, rb_swap, rb_swap);
>  
> - if (is_alpha_support(fb->format->format)) {
> + /*
> +  * Blending win0 with the background color doesn't seem to work
> +  * correctly. We only get the background color, no matter the contents
> +  * of the win0 framebuffer.  However, blending pre-multiplied color
> +  * with the default opaque black default background color is a no-op,
> +  * so we can just disable blending to get the correct result.
> +  */
> + if (is_alpha_support(fb->format->format) && win_index > 0) {
>   VOP_WIN_SET(vop, win, dst_alpha_ctl,
>   DST_FACTOR_M0(ALPHA_SRC_INVERSE));
>   val = SRC_ALPHA_EN(1) | SRC_COLOR_M0(ALPHA_SRC_PRE_MUL) |
> -- 
> 2.17.0.484.g0c8726318c-goog
> 

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

Re: [PATCH hwc v2 02/18] drm_hwcomposer: vsyncworker: Fix deadlock on exit path

[Alexandru-Cosmin Gheorghe]

Hi Sean,

On Mon, Apr 16, 2018 at 03:25:42PM -0400, Sean Paul wrote:
> On Wed, Apr 11, 2018 at 04:22:13PM +0100, Alexandru Gheorghe wrote:
> > vsyncworker::Routine assumes that when -EINTR is returned by
> > WaitForSignalOrExitLocked the lock as been released, which is not
> > true, so it hangs if a vsyncworker is never enabled and Exit is
> > called.
> > 
> > There are two code paths in WaitForSignalOrExitLocked that return
> > -EINTR, one releases the lock the other doesn't.
> > Looking at the clients of WaitForSignalOrExitLocked all assume the lock
> > is still held, except vsyncworker::Routine.
> > So, the proper fix needs two changes:
> > - Make WaitForSignalOrExitLocked consistent and always hold the lock
> >   when exiting.
> > - Release lock in vsynworker::Routine on all code paths.
> > 
> > Signed-off-by: Alexandru Gheorghe 
> > ---
> >  vsyncworker.cpp | 1 +
> >  worker.cpp  | 6 +++---
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/vsyncworker.cpp b/vsyncworker.cpp
> > index 3bfe4be..7c0c741 100644
> > --- a/vsyncworker.cpp
> > +++ b/vsyncworker.cpp
> > @@ -120,6 +120,7 @@ void VSyncWorker::Routine() {
> >if (!enabled_) {
> >  ret = WaitForSignalOrExitLocked();
> >  if (ret == -EINTR) {
> > +  Unlock();
> >return;
> >  }
> >}
> > diff --git a/worker.cpp b/worker.cpp
> > index da6c580..5b351e0 100644
> > --- a/worker.cpp
> > +++ b/worker.cpp
> > @@ -66,13 +66,13 @@ int Worker::WaitForSignalOrExitLocked(int64_t 
> > max_nanoseconds) {
> >  ret = -ETIMEDOUT;
> >}
> >  
> > +  // release leaves mutex locked when going out of scope
> > +  lk.release();
> > +
> >// exit takes precedence on timeout
> >if (should_exit())
> >  ret = -EINTR;
> >  
> > -  // release leaves mutex locked when going out of scope
> > -  lk.release();
> > -
> 
> I'm not sure why this chunk makes a difference? If the above was
> "return -EINTR;" it would, but it's just assigning ret.
> 

You are certainly right, just dyslexia on my side. 
I will update the patch.

> Sean
> 
> >return ret;
> >  }
> >  
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH 1/2 v2] drm/pl111: Support the Versatile Express

[Robin Murphy]

On 17/04/18 13:32, Linus Walleij wrote:
[...]

Unfortunately there is just one single vexpress core tile in the
upstream kernel that define a CLCD controller, the CA9 (4xA9)
that I am using. All the others just use the MB CLCD.

I am thinking there is some never finished DTS upstreaming
here that ought to happen so we use the core tile CLCD on some
other boards as well.


Barring custom FPGA images, I think V2P-CA9 *is* the only VExpress tile 
implementing PL11x; all the more recent test chips had HDLCD instead.


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

Re: [PATCH v3 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.

[Rob Herring]

On Mon, Apr 16, 2018 at 5:52 PM, Eric Anholt  wrote:
> The GPU subsystem node was a workaround to have a central device to
> bind V3D and display to.  Following the lead of 246774d17fc0
> ("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
> the subsystem node usage and just create a platform device for the DRM
> device to attach to if any of the subsystem devices are present.
>
> v2: Simplify the DT walking code.
> v3: Always put the node.
>
> Signed-off-by: Eric Anholt 
> ---
>  .../bindings/display/brcm,bcm-vc4.txt |  7 -
>  drivers/gpu/drm/vc4/vc4_drv.c | 28 +--
>  drivers/gpu/drm/vc4/vc4_hvs.c |  1 +
>  drivers/gpu/drm/vc4/vc4_v3d.c |  1 +
>  4 files changed, 22 insertions(+), 15 deletions(-)

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

Re: [PATCH 1/2 v2] drm/pl111: Support the Versatile Express

[Linus Walleij]

On Tue, Apr 10, 2018 at 11:57 AM, Liviu Dudau  wrote:

> I need to do a bit of archeology to get my Versatile Express back
> to working order in order to test your patches, which might not
> happen this week or so, but I have some comments on your approach
> which I would like clarification on.

OK no hurries :)

> On Fri, Apr 06, 2018 at 04:19:34PM +0200, Linus Walleij wrote:
>>
>> The Versatile Express uses a special configuration controller
>> deeply embedded in the system motherboard FPGA to multiplex the
>> two to three (!) CLCD instances out to the single SiI9022
>> bridge.
>
> That configuration controller is already supported by the
> drivers/misc/vexpress-syscfg.c driver and the muxfpga node is present
> in arch/arm/boot/dts/vexpress-v2m-rs1.dtsi (and vexpress-v2m.dtsi for
> older CoreTiles that don't use the RS1 memory map).

Yes the code is using that driver through the public interface in
, so it should be fine.

>> Set up an extra file with the logic to probe to the FPGA mux
>> register on the system controller bus, then parse the memory
>> range argument to figure out what path the CLCD signal is
>> actually taking, and set up the mux accordingly.
>
> I'm not sure you need all this extra code,

I think the commit message may be confusing I will try
to reword it.

> I would have thought that
> all you want is to use the regmap that you already have in order to
> switch the MUX to the correct input. The MUXFPGA in the DT is already
> setup to use function 7 (which is the function you need for FPGA), you
> just need a property in the PL111 node to tell you which "site" you are
> on (Motherboard, Daughterboard 1 or 2) and use the relevant value when
> setting the regmap.
>
> Info on what the correct values are are here:
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0447j/CACDEFGH.html#CACCGJFF

Yes this is what I'm using, I am manipulating SYS_CFG_MUXFPGA
through the interface exposed in .

>> If there is a CLCD instance on the core tile (the daughterboard
>> with the CPUs fitted) then that CLCD instance will take
>> precedence since it can address all memory.
>
> What does "take precedence" mean here? You mean prefer to switch the MUX
> to that source instead of using the MB? That should always be the
> default choice, as the MB CLCD is mostly for boot up info being
> displayed and it is known to have horrendous performance.

Yes, so that is what I am trying to do. If there is a CLCD on the
core tile (daughterboard as it its called in the manual), that one
should take precedence.

Unfortunately there is just one single vexpress core tile in the
upstream kernel that define a CLCD controller, the CA9 (4xA9)
that I am using. All the others just use the MB CLCD.

I am thinking there is some never finished DTS upstreaming
here that ought to happen so we use the core tile CLCD on some
other boards as well.

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

Re: [PATCH 2/2 v2] drm/pl111: Enable device-specific assigned memory

[Linus Walleij]

On Sun, Apr 8, 2018 at 3:08 AM, Eric Anholt  wrote:

>>   if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
>>>memory_bw)) {
>>   dev_info(dev, "no max memory bandwidth specified, assume 
>> unlimited\n");
>> @@ -275,7 +280,8 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
>>   priv->regs = devm_ioremap_resource(dev, _dev->res);
>>   if (IS_ERR(priv->regs)) {
>>   dev_err(dev, "%s failed mmio\n", __func__);
>> - return PTR_ERR(priv->regs);
>> + ret = PTR_ERR(priv->regs);
>> + goto mem_rel;
>>   }
>
> Shouldn't this error path be jumping to dev_unref, as well?  We're
> trying to match drm_dev_alloc(), right?

OK I fixed.

> I'm still a little bothered that we're allowing imports to pl111 of CMA
> buffers that we can't scan out.  Could we just refuse all
> .gem_prime_import*() on this platform?

I am sorry but I do not understand how CMA, dmabuf and GEM play
together to decode this and figure out what to do.

Do you mean that if we find device assigned memory, i.e. that there
is this special memory which is all the controller can scan out,
I should just implement .gem_prime_impport() instead of the
currently assigned drm_gem_prime_import() to something just
returning return ERR_PTR(-EINVAL); so it always fails?

What about .gem_prime_import_sg_table()? Exporting should
work fine since the memory is always readable by CPU.

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

[PATCH] drm/stm: ltdc: add mode_valid()

[Philippe Cornu]

Add mode_valid() function to filter modes according to available
pll clock values and "preferred" modes. It is particularly
useful for hdmi modes that require precise pixel clocks.

Note that "preferred" modes are always accepted:
- this is important for panels because panel clock tolerances are
  bigger than hdmi ones and there is no reason to not accept them
  (the fps may vary a little but it is not a problem).
- the hdmi preferred mode will be accepted too, but userland will
  be able to use others hdmi "valid" modes if necessary.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/ltdc.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 014cef8cef37..616191fe98ae 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -445,6 +445,43 @@ static void ltdc_crtc_atomic_disable(struct drm_crtc *crtc,
reg_set(ldev->regs, LTDC_SRCR, SRCR_IMR);
 }
 
+#define CLK_TOLERANCE_HZ 50
+
+static enum drm_mode_status
+ltdc_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+   int target = mode->clock * 1000;
+   int target_min = target - CLK_TOLERANCE_HZ;
+   int target_max = target + CLK_TOLERANCE_HZ;
+   int result;
+
+   /*
+* Accept all "preferred" modes:
+* - this is important for panels because panel clock tolerances are
+*   bigger than hdmi ones and there is no reason to not accept them
+*   (the fps may vary a little but it is not a problem).
+* - the hdmi preferred mode will be accepted too, but userland will
+*   be able to use others hdmi "valid" modes if necessary.
+*/
+   if (mode->type & DRM_MODE_TYPE_PREFERRED)
+   return MODE_OK;
+
+   result = clk_round_rate(ldev->pixel_clk, target);
+
+   DRM_DEBUG_DRIVER("clk rate target %d, available %d\n", target, result);
+
+   /*
+* Filter modes according to the clock value, particularly useful for
+* hdmi modes that require precise pixel clocks.
+*/
+   if (result < target_min || result > target_max)
+   return MODE_CLOCK_RANGE;
+
+   return MODE_OK;
+}
+
 static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
 const struct drm_display_mode *mode,
 struct drm_display_mode *adjusted_mode)
@@ -559,6 +596,7 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
+   .mode_valid = ltdc_crtc_mode_valid,
.mode_fixup = ltdc_crtc_mode_fixup,
.mode_set_nofb = ltdc_crtc_mode_set_nofb,
.atomic_flush = ltdc_crtc_atomic_flush,
-- 
2.15.1

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

[PATCH] drm/stm: ltdc: fix deferred endpoint management

[Philippe Cornu]

When a driver related to one of the endpoints is deferred
due to probe dependencies (i2c, spi...) but the other one
is ready, ltdc probe continues and the deferred driver
will never be probed again.

The fix consists in waiting for all deferred endpoints before
continuing the ltdc probe.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/ltdc.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index e3121d9e4230..014cef8cef37 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -987,14 +987,13 @@ int ltdc_load(struct drm_device *ddev)
  [i]);
 
/*
-* If at least one endpoint is ready, continue probing,
-* else if at least one endpoint is -EPROBE_DEFER and
-* there is no previous ready endpoints, defer probing.
+* If at least one endpoint is -EPROBE_DEFER, defer probing,
+* else if at least one endpoint is ready, continue probing.
 */
-   if (!ret)
+   if (ret == -EPROBE_DEFER)
+   return ret;
+   else if (!ret)
endpoint_not_ready = 0;
-   else if (ret == -EPROBE_DEFER && endpoint_not_ready)
-   endpoint_not_ready = -EPROBE_DEFER;
}
 
if (endpoint_not_ready)
-- 
2.15.1

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

Re: [PATCH] drm/rockchip: vop: fixup linebuffer mode calc error

[Heiko Stuebner]

Hi Sandy,

Am Dienstag, 17. April 2018, 12:15:07 CEST schrieb Sandy Huang:
> When video width is bigger than 3840 the linebuffer mode
> should be LB_YUV_3840X5.

Can you explain that a bit better?

I.e. when looking at the code, the very first check is width > 2560.

So it seems your change targets some YUV mode with width > 3840
which should be mentioned in the commit message, so people like
me don't scratch their head in confusion ;-)

Similarly that check is actually width > 1280 to set LB_YUV_3840X5,
so I guess you're actually wanting any YUV mode bigger than
1280px should use LB_YUV_3840X5?


Heiko

> Signed-off-by: Sandy Huang 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 56bbd2e..3e7501b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -332,7 +332,7 @@ static inline int scl_vop_cal_lb_mode(int width, bool 
> is_yuv)
>  
>   if (width > 2560)
>   lb_mode = LB_RGB_3840X2;
> - else if (width > 1920)
> + else if (!is_yuv && width > 1920)
>   lb_mode = LB_RGB_2560X4;
>   else if (!is_yuv)
>   lb_mode = LB_RGB_1920X5;
> 


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

Re: [RFC v4 23/25] drm: Add DRM device registered notifier

[Daniel Vetter]

On Sat, Apr 14, 2018 at 01:53:16PM +0200, Noralf Trønnes wrote:
> Add a notifier that fires when a new DRM device is registered.
> This can be used by the bootsplash client to connect to all devices.
> 
> Signed-off-by: Noralf Trønnes 

So I freaked out temporarily about your usage of notifiers here. But I
think this one of the few cases where using notifiers is actually
perfectly fine. Still not sure we really want that, instead of just
hard-coding calls to the various register functions directly (and using a
dummy no-op replacement if that part isn't enabled in Kconfig).
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c | 32 
>  include/drm/drm_drv.h |  4 
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 6f21bafb29be..e42ce320ad07 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -79,6 +80,8 @@ static struct dentry *drm_debugfs_root;
>  
>  DEFINE_STATIC_SRCU(drm_unplug_srcu);
>  
> +static BLOCKING_NOTIFIER_HEAD(drm_dev_notifier);
> +
>  /*
>   * DRM Minors
>   * A DRM device can provide several char-dev interfaces on the DRM-Major. 
> Each
> @@ -837,6 +840,8 @@ int drm_dev_register(struct drm_device *dev, unsigned 
> long flags)
>dev->dev ? dev_name(dev->dev) : "virtual device",
>dev->primary->index);
>  
> + blocking_notifier_call_chain(_dev_notifier, 0, dev);
> +
>   goto out_unlock;
>  
>  err_minors:
> @@ -894,6 +899,33 @@ void drm_dev_unregister(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_dev_unregister);
>  
> +/**
> + * drm_dev_register_notifier - Register a notifier for new DRM devices
> + * @nb: Notifier block
> + *
> + * Register a notifier that fires when a new _device is registered.
> + *
> + * Note:
> + * Users of this function has to be linked into drm.ko. This is done to make
> + * life simple avoiding tricky race situations.
> + */
> +void drm_dev_register_notifier(struct notifier_block *nb)
> +{
> + /* Currently this can't fail, but catch it in case this changes */
> + WARN_ON(blocking_notifier_chain_register(_dev_notifier, nb));
> +}
> +
> +/**
> + * drm_dev_unregister_notifier - Unregister DRM device notifier
> + * @nb: Notifier block
> + *
> + * This is a no-op if the notifier isn't registered.
> + */
> +void drm_dev_unregister_notifier(struct notifier_block *nb)
> +{
> + blocking_notifier_chain_unregister(_dev_notifier, nb);
> +}
> +
>  /**
>   * drm_dev_set_unique - Set the unique name of a DRM device
>   * @dev: device of which to set the unique name
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 13356e6fd40c..5e6c6ed0d59d 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -40,6 +40,7 @@ struct drm_minor;
>  struct dma_buf_attachment;
>  struct drm_display_mode;
>  struct drm_mode_create_dumb;
> +struct notifier_block;
>  struct drm_printer;
>  
>  /* driver capabilities and requirements mask */
> @@ -641,6 +642,9 @@ struct drm_device *drm_dev_alloc(struct drm_driver 
> *driver,
>  int drm_dev_register(struct drm_device *dev, unsigned long flags);
>  void drm_dev_unregister(struct drm_device *dev);
>  
> +void drm_dev_register_notifier(struct notifier_block *nb);
> +void drm_dev_unregister_notifier(struct notifier_block *nb);
> +
>  void drm_dev_get(struct drm_device *dev);
>  void drm_dev_put(struct drm_device *dev);
>  void drm_dev_unref(struct drm_device *dev);
> -- 
> 2.15.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

--- Comment #6 from taij...@posteo.de ---
If I wanted to try to embed amdgpu in the kernel for testing, how would I even
go about doing that? Simply editing my config file from =m to =y does not seem
to do anything.

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