Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Jerome Glisse]

On Thu, Mar 29, 2018 at 10:25:52AM -0600, Logan Gunthorpe wrote:
> 
> 
> On 29/03/18 10:10 AM, Christian König wrote:
> > Why not? I mean the dma_map_resource() function is for P2P while other 
> > dma_map_* functions are only for system memory.
> 
> Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
> P2P. Though it's a bit odd seeing we've been working under the
> assumption that PCI P2P is different as it has to translate the PCI bus
> address. Where as P2P for devices on other buses is a big unknown.

dma_map_resource() is the right API (thought its current implementation
is fill with x86 assumptions). So i would argue that arch can decide to
implement it or simply return dma error address which trigger fallback
path into the caller (at least for GPU drivers). SG variant can be added
on top.

dma_map_resource() is the right API because it has all the necessary
informations. It use the CPU physical address as the common address
"language" with CPU physical address of PCIE bar to map to another
device you can find the corresponding bus address from the IOMMU code
(NOP on x86). So dma_map_resource() knows both the source device which
export its PCIE bar and the destination devices.


So i don't think Christian need to base his patchset on yours. This
is orthogonal. Christian is using existing upstream API, if it is
broken on some arch it is up to those arch to fix it, or return error
if it is not fixable. In fact i would assume that you would need to
base your patchset on top of dma_map_resource() too ...

Moreover i doubt Christian want to have struct page for this. For
nouveau there will be HMM struct page and this would conflict.

AFAICT you need struct page because the API you are trying to expose
to user space rely on "regular" filesystem/RDMA umem API which all
assume struct page. GPU drivers do not have this requirement and it
should not be impose on them.


So from my point of view Christian patchset is good as it is. Modulo
better commit message.


Bottom line i think we need common PCIE helper for P2P and the current
dma_map_resource() is the right kind from POV. What you are doing with
struct page is specific to your sub-system and should not be impose on
others.

Cheers,
Jérôme
___
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 #10 from MirceaKitsune  ---
Created attachment 138438
  --> https://bugs.freedesktop.org/attachment.cgi?id=138438=edit
Screenshot of the Blender window glitching

I should add another detail to the discussion. I know this may be a separate
issue which might have nothing to do with the crash, but at the same time I
wouldn't be surprised if it does: Glitched graphics often indicate something
going wrong with the display, such as corrupt textures in video memory, which
may ultimately lead to just such a lockup.

On occasion, certain programs (namely Firefox and Blender) glitch out and draw
broken rectangles all over the window. Some of those glitches are just boxes of
random colors, others contain pieces of past images (for instance I saw
patterns from my lock screen background). Sometimes they quickly disappear on
their own, at other times I have to restart the program as it becomes illegible
and unusable. If I move anything the squares flicker all over the place. The
glitches continue even after I disable desktop effects, thus KDE compositing
should have nothing to do with it.

Attached is a screenshot of the glitch happening in Blender, showing its window
covered in the corrupt squares. I'm curious what your opinion is. Again I know
this may be an unrelated issue, but I'm wondering whether it indicates some
video storage corruption that's also leading up to the lockups.

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

Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration

[Matt Roper]

On Mon, Mar 26, 2018 at 10:30:23AM +0300, Joonas Lahtinen wrote:
> Quoting Matt Roper (2018-03-23 17:46:16)
> > On Fri, Mar 23, 2018 at 02:15:38PM +0200, Joonas Lahtinen wrote:
> > > Quoting Matt Roper (2018-03-17 02:08:57)
> > > > This is the fourth iteration of the work previously posted here:
> > > >   (v1) 
> > > > https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
> > > >   (v2) 
> > > > https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
> > > >   (v3) 
> > > > https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.html
> > > > 
> > > > The high level goal of this work is to allow non-cgroup-controller parts
> > > > of the kernel (e.g., device drivers) to register their own private
> > > > policy data for specific cgroups.  That mechanism is then made use of in
> > > > the i915 graphics driver to allow GPU priority to be assigned according
> > > > to the cgroup membership of the owning process.  Please see the v1 cover
> > > > letter linked above for a more in-depth explanation and justification.
> > > 
> > > Hi Matt,
> > > 
> > > For cross-subsystem changes such as this, it makes sense to Cc all
> > > relevant maintainers, especially if there have been previous comments to
> > > earlier revisions.
> > > 
> > > Please, do include and keep a reference to the userspace portion of the
> > > changes when you suggest new uAPI to be added. At least I have some 
> > > trouble
> > > trying to track down the relevant interface consumer here.
> > > 
> > > I'm unsure how much sense it makes to commence with detailed i915 review
> > > if we will be blocked by lack of userspace after that? I'm assuming
> > > you've read through [1] already.
> > 
> > Hi Joonas,
> > 
> > I've sent the userspace code out a few times, but it looks like I forgot
> > to include a copy with v4/v4.5.  Here's the version I provided with v3:
> >   https://lists.freedesktop.org/archives/intel-gfx/2018-March/157935.html
> 
> Thanks. Keeping that in the relevant commit message of the patch that
> introduces the new uAPI will make it harder to forget and easiest for
> git blame, too.
> 
> > 
> > Usually we don't consider things like i-g-t to be sufficient userspace
> > consumers because we need a real-world consumer rather than a "toy"
> > userspace.  However in this case, the i-g-t tool, although very simple,
> > is really the only userspace consumer I expect there to ever be.
> > Ultimately the true consumer of this cgroups work are bash scripts, sysv
> > init scripts, systemd recipes, etc.  that just need a very simple tool
> > to assign the specific values that make sense on a given system.
> > There's no expectation that graphics clients or display servers would
> > ever need to make use of these interfaces.
> 
> I was under the impression that a bit more generic GPU cgroups support
> was receiving a lot of support in the early discussion? A dedicated
> intel_cgroup sounds underwhelming, when comparing to idea of "gpu_nice",
> for user adoption :)

I'm open to moving the cgroup_priv registration/lookup to the DRM core
if other drivers are interested in using this mechanism and if we can
come to an agreement on a standard priority offset range to support, how
display boost should work for all drivers, etc.  There might be some
challenges mapping a DRM-defined priority range down to a different
range that makes sense for individual driver schedulers, especially
since some drivers already expose a different priority scheme to
userspace via other interfaces like i915 does with GEM context priority.

So far I haven't really heard any interest outside the Intel camp, but
hopefully other driver teams can speak up if they're for/against this.
I don't want to try to artificially standardize this if other drivers
want to go a different direction with priority/scheduling that's too
different from the current Intel-driven design.

> Also, I might not be up-to-date about all things cgroups, but the way
> intel_cgroup works, feels bit forced. We create a userspace context just
> to communicate with the driver and the IOCTL will still have global
> effects. I can't but think that i915 reading from the cgroups subsystem
> for the current process would feel more intuitive to me.

I think you're referring to the earlier discussion about exposing
priority directly via the cgroups filesystem?  That would certainly be
simpler from a userspace perspective, but it's not the direction that
the cgroups maintainer wants to see things go.  Adding files directly to
the cgroups filesystem is supposed to be something that's reserved for
official cgroups controllers.  The GPU priority concept we're trying to
add here doesn't align with the requirements for creating a controller,
so the preferred approach is to create a custom interface (syscall or
ioctl) that simply takes a cgroup as a parameter.  There's precendent
with similar interfaces in areas like BPF (where the bpf() system call
can accept a cgroup as a 

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

[bugzilla-daemon]

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

Stefano Cipriani  changed:

   What|Removed |Added

 CC||cip9...@gmail.com

--- Comment #12 from Stefano Cipriani  ---
Created attachment 138437
  --> https://bugs.freedesktop.org/attachment.cgi?id=138437=edit
implement missing functions

I tried to "port" the missing functions from radeon, using constants from
amdgpu when I could find them, and removing those I deemed no more relevant. 
Don't know if I've done everything right, though now I can change dpm state
freely

-- 
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] ALSA: hda - Silence PM ops build warning

[Lukas Wunner]

On Thu, Mar 29, 2018 at 01:51:43PM +0200, Takashi Iwai wrote:
> On Thu, 29 Mar 2018 13:46:26 +0200, Lukas Wunner wrote:
> > The system sleep PM ops azx_suspend() and azx_resume() were previously
> > called by vga_switcheroo, but commit 07f4f97d7b4b ("vga_switcheroo: Use
> > device link for HDA controller") removed their invocation.
> > 
> > Unfortunately the commit neglected to update the #ifdef surrounding the
> > two functions, so if CONFIG_PM_SLEEP is *not* enabled but all three of
> > CONFIG_PM, CONFIG_VGA_SWITCHEROO and CONFIG_SND_HDA_CODEC_HDMI *are*
> > enabled, the compiler now emits the following warning:
> > 
> > sound/pci/hda/hda_intel.c:1024:12: warning: 'azx_resume' defined but not 
> > used [-Wunused-function]
> >  static int azx_resume(struct device *dev)
> > ^~
> > sound/pci/hda/hda_intel.c:989:12: warning: 'azx_suspend' defined but not 
> > used [-Wunused-function]
> >  static int azx_suspend(struct device *dev)
> > ^~~
> > 
> > Silence by updating the #ifdef.  Because the #ifdef block now uses the
> > same condition as the one immediately succeeding it, the two blocks can
> > be collapsed together, shaving off another two lines.
> > 
> > Fixes: 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
> > Cc: Takashi Iwai 
> > Reported-by: Arnd Bergmann 
> > Signed-off-by: Lukas Wunner 
> 
> Reviewed-by: Takashi Iwai 
> 
> Can this go through drm(-misc) tree as the original commit stays?

Pushed to drm-misc-next-fixes, thanks for the report and review.

Sorry, you were super fast with the review, but I wanted to give folks
the chance to comment at least for a few hours before pushing, despite
this likely being an uncontroversial patch.

It was also automatically applied to the drm-misc/for-linux-next branch,
so the build warning should be gone in linux-next once it's rebuilt.
(I'm not sure if Good Friday and Easter Monday are national holidays
down under, as they are in Germany, but I hope Stephen will rebuild
Tuesday at the latest.)

Peaceful Easter holidays to everyone,

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

Re: [PATCH 3/3] drm/scheduler: move the tracepoints file from the include directory

[Lucas Stach]

Am Donnerstag, den 29.03.2018, 22:36 +0530 schrieb Nayan Deshmukh:
> Move it with the scheduler code. This is mostly a straight forward
> rename with no code change except for updating the TRACE_INCLUDE_PATH
> 
> Signed-off-by: Nayan Deshmukh 
> Suggested-by: Christian König 

Acked-by: Lucas Stach 

> ---
>  drivers/gpu/drm/scheduler/gpu_scheduler.c| 2 +-
>  {include/drm => drivers/gpu/drm/scheduler}/gpu_scheduler_trace.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>  rename {include/drm => drivers/gpu/drm/scheduler}/gpu_scheduler_trace.h (97%)
> 
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 565b7348db80..698531ed6a43 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -30,7 +30,7 @@
>  #include 
>  
>  #define CREATE_TRACE_POINTS
> -#include 
> +#include "gpu_scheduler_trace.h"
>  
>  #define to_drm_sched_job(sched_job)  \
>   container_of((sched_job), struct drm_sched_job, queue_node)
> diff --git a/include/drm/gpu_scheduler_trace.h 
> b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> similarity index 97%
> rename from include/drm/gpu_scheduler_trace.h
> rename to drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> index 0789e8d0a0e1..4998ad950a48 100644
> --- a/include/drm/gpu_scheduler_trace.h
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> @@ -78,5 +78,5 @@ TRACE_EVENT(drm_sched_process_job,
>  
>  /* This part must be outside protection */
>  #undef TRACE_INCLUDE_PATH
> -#define TRACE_INCLUDE_PATH .
> +#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/scheduler
>  #include 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104825] [amdgpu] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed (scratch(0xC040)=0x00000000) when unbinding

[bugzilla-daemon]

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

--- Comment #16 from mlen  ---
I'll test it on saturday, I don't have access to that machine at the moment

-- 
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/3] drm/scheduler: remove unused parameter

[Lucas Stach]

Am Donnerstag, den 29.03.2018, 22:36 +0530 schrieb Nayan Deshmukh:
> this patch also effect the amdgpu and etnaviv drivers which
> use the function drm_sched_entity_init
> 
> Signed-off-by: Nayan Deshmukh 
> Suggested-by: Christian König 

Acked-by: Lucas Stach 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   | 2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   | 2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c   | 2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c   | 4 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 2 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
>  drivers/gpu/drm/scheduler/gpu_scheduler.c | 3 +--
>  include/drm/gpu_scheduler.h   | 2 +-
>  11 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> index 09d35051fdd6..533f903356de 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> @@ -91,7 +91,7 @@ static int amdgpu_ctx_init(struct amdgpu_device
> *adev,
>   continue;
>  
>   r = drm_sched_entity_init(>sched, 
> >rings[i].entity,
> -   rq, amdgpu_sched_jobs,
> >guilty);
> +   rq, >guilty);
>   if (r)
>   goto failed;
>   }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 205da3ff9cd0..e445e5f9abba 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -111,7 +111,7 @@ static int amdgpu_ttm_global_init(struct
> amdgpu_device *adev)
>   ring = adev->mman.buffer_funcs_ring;
>   rq = >sched.sched_rq[DRM_SCHED_PRIORITY_KERNEL];
>   r = drm_sched_entity_init(>sched, >mman.entity,
> -   rq, amdgpu_sched_jobs, NULL);
> +   rq, NULL);
>   if (r) {
>   DRM_ERROR("Failed setting up TTM BO move run
> queue.\n");
>   goto error_entity;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index 627542b22ae4..c135f3d236e0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -237,7 +237,7 @@ int amdgpu_uvd_sw_init(struct amdgpu_device
> *adev)
>   ring = >uvd.ring;
>   rq = >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
>   r = drm_sched_entity_init(>sched, >uvd.entity,
> -   rq, amdgpu_sched_jobs, NULL);
> +   rq, NULL);
>   if (r != 0) {
>   DRM_ERROR("Failed setting up UVD run queue.\n");
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> index a33804bd3314..59da1d29b612 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
> @@ -181,7 +181,7 @@ int amdgpu_vce_sw_init(struct amdgpu_device
> *adev, unsigned long size)
>   ring = >vce.ring[0];
>   rq = >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
>   r = drm_sched_entity_init(>sched, >vce.entity,
> -   rq, amdgpu_sched_jobs, NULL);
> +   rq, NULL);
>   if (r != 0) {
>   DRM_ERROR("Failed setting up VCE run queue.\n");
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index 58e495330b38..e5d234cf804f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -105,7 +105,7 @@ int amdgpu_vcn_sw_init(struct amdgpu_device
> *adev)
>   ring = >vcn.ring_dec;
>   rq = >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
>   r = drm_sched_entity_init(>sched, 
> >vcn.entity_dec,
> -   rq, amdgpu_sched_jobs, NULL);
> +   rq, NULL);
>   if (r != 0) {
>   DRM_ERROR("Failed setting up VCN dec run queue.\n");
>   return r;
> @@ -114,7 +114,7 @@ int amdgpu_vcn_sw_init(struct amdgpu_device
> *adev)
>   ring = >vcn.ring_enc[0];
>   rq = >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
>   r = drm_sched_entity_init(>sched, 
> >vcn.entity_enc,
> -   rq, amdgpu_sched_jobs, NULL);
> +   rq, NULL);
>   if (r != 0) {
>   DRM_ERROR("Failed setting up VCN enc run queue.\n");
>   return r;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index da55a78d7380..29e9879c9b81 100644
> --- 

[Bug 105680] [CI] igt@kms_frontbuffer_tracking@* - fail - FBC disabled: mode too large for compression

[bugzilla-daemon]

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

--- Comment #4 from Jose Roberto de Souza  ---
This one is not related to memory, it is because the resolution is bigger than
the resolution that hardware track can handle, so there is not fix for those.
You can run this tests with "--use-small-modes" to avoid those errors.

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

Re: [PATCH 0/3] Minor code cleanups in drm/scheduler

[Christian König]

Patches #2 and #3 are Reviewed-by: Christian König 
 as well.


If Lucas has no objections I'm going to pull those into 
amd-staging-drm-next next week.


Regards,
Christian.

Am 29.03.2018 um 19:06 schrieb Nayan Deshmukh:

The series is based on drm-next. The 2nd patch also affects
amdgpu and etnaviv drivers.

Nayan Deshmukh (3):
   drm/scheduler: fix param documentation
   drm/scheduler: remove unused parameter
   drm/scheduler: move the tracepoints file from the include directory

  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c  | 2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c  | 2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c  | 4 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 2 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c| 2 +-
  drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c| 2 +-
  drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
  drivers/gpu/drm/scheduler/gpu_scheduler.c| 8 
  {include/drm => drivers/gpu/drm/scheduler}/gpu_scheduler_trace.h | 2 +-
  include/drm/gpu_scheduler.h  | 2 +-
  12 files changed, 16 insertions(+), 16 deletions(-)
  rename {include/drm => drivers/gpu/drm/scheduler}/gpu_scheduler_trace.h (97%)



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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Christian König]

Am 29.03.2018 um 18:25 schrieb Logan Gunthorpe:


On 29/03/18 10:10 AM, Christian König wrote:

Why not? I mean the dma_map_resource() function is for P2P while other
dma_map_* functions are only for system memory.

Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping
P2P. Though it's a bit odd seeing we've been working under the
assumption that PCI P2P is different as it has to translate the PCI bus
address. Where as P2P for devices on other buses is a big unknown.


Yeah, completely agree. On my TODO list (but rather far down) is 
actually supporting P2P with USB devices.


And no, I don't have the slightest idea how to do this at the moment.


And this is necessary to
check if the DMA ops in use support it or not. We can't have the
dma_map_X() functions do the wrong thing because they don't support it yet.

Well that sounds like we should just return an error from
dma_map_resources() when an architecture doesn't support P2P yet as Alex
suggested.

Yes, well except in our patch-set we can't easily use
dma_map_resources() as we either have SGLs to deal with or we need to
create whole new interfaces to a number of subsystems.


Agree as well. I was also in clear favor of extending the SGLs to have a 
flag for this instead of the dma_map_resource() interface, but for some 
reason that didn't made it into the kernel.



You don't seem to understand the implications: The devices do have a
common upstream bridge! In other words your code would currently claim
that P2P is supported, but in practice it doesn't work.

Do they? They don't on any of the Intel machines I'm looking at. The
previous version of the patchset not only required a common upstream
bridge but two layers of upstream bridges on both devices which would
effectively limit transfers to PCIe switches only. But Bjorn did not
like this.


At least to me that sounds like a good idea, it would at least disable 
(the incorrect) auto detection of P2P for such devices.



You need to include both drivers which participate in the P2P
transaction to make sure that both supports this and give them
opportunity to chicken out and in the case of AMD APUs even redirect the
request to another location (e.g. participate in the DMA translation).

I don't think it's the drivers responsibility to reject P2P . The
topology is what governs support or not. The discussions we had with
Bjorn settled on if the devices are all behind the same bridge they can
communicate with each other. This is essentially guaranteed by the PCI spec.


Well it is not only rejecting P2P, see the devices I need to worry about 
are essentially part of the CPU. Their resources looks like a PCI BAR to 
the BIOS and OS, but are actually backed by stolen system memory.


So as crazy as it sounds what you get is an operation which starts as 
P2P, but then the GPU drivers sees it and says: Hey please don't write 
that to my PCIe BAR, but rather system memory location X.



DMA-buf fortunately seems to handle all this already, that's why we
choose it as base for our implementation.

Well, unfortunately DMA-buf doesn't help for the drivers we are working
with as neither the block layer nor the RDMA subsystem have any
interfaces for it.


A fact that gives me quite some sleepless nights as well. I think we 
sooner or later need to extend those interfaces to work with DMA-bufs as 
well.


I will try to give your patch set a review when I'm back from vacation 
and rebase my DMA-buf work on top of that.


Regards,
Christian.



Logan


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

Re: [PATCH] drm/scheduler: fix param documentation

[Nayan Deshmukh]

On Thu, Mar 29, 2018 at 8:56 PM, Alex Deucher  wrote:
> On Tue, Mar 27, 2018 at 1:29 PM, Nayan Deshmukh
>  wrote:
>> On Tue, Mar 27, 2018 at 1:47 PM, Daniel Vetter  wrote:
>>> On Mon, Mar 26, 2018 at 08:51:14PM +0530, Nayan Deshmukh wrote:
 Signed-off-by: Nayan Deshmukh 
>>>
>>> You might want to add a kerneldoc page in Documentation/gpu/scheduler.rst,
>>> which pulls in all the nice kerneldoc you have here + has a short intro
>>> text what this is all about.
>>>
>> Yeah Sure. I'll send a patch for this in a while.
>
> FWIW, I started improving the documentation in the GPU scheduler last
> week, but ran out of time to finish it.  Here's the WIP patch. Feel
> free to run with it.
>
This will be useful. I'll go over it during the weekend and probably
send a patch early next week.

Thanks
> Alex
>
>>
>> Cheers,
>> Nayan
>>> Cheers, Daniel
>>>
 ---
  drivers/gpu/drm/scheduler/gpu_scheduler.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
 b/drivers/gpu/drm/scheduler/gpu_scheduler.c
 index 0d95888ccc3e..1d368bc66ac2 100644
 --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
 +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
 @@ -117,8 +117,9 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
   * @schedThe pointer to the scheduler
   * @entity   The pointer to a valid drm_sched_entity
   * @rq   The run queue this entity belongs
 - * @kernel   If this is an entity for the kernel
   * @jobs The max number of jobs in the job queue
 + * @guilty  atomic_t set to 1 when a job on this queue
 + *  is found to be guilty causing a timeout
   *
   * return 0 if succeed. negative error code on failure
  */
 --
 2.14.3

 ___
 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/scheduler: fix param documentation

[Nayan Deshmukh]

There is no @kernel parameter anymore and document the
@guilty parameter

Signed-off-by: Nayan Deshmukh 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 0d95888ccc3e..1d368bc66ac2 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -117,8 +117,9 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
  * @sched  The pointer to the scheduler
  * @entity The pointer to a valid drm_sched_entity
  * @rq The run queue this entity belongs
- * @kernel If this is an entity for the kernel
  * @jobs   The max number of jobs in the job queue
+ * @guilty  atomic_t set to 1 when a job on this queue
+ *  is found to be guilty causing a timeout
  *
  * return 0 if succeed. negative error code on failure
 */
-- 
2.14.3

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

[PATCH 2/3] drm/scheduler: remove unused parameter

[Nayan Deshmukh]

this patch also effect the amdgpu and etnaviv drivers which
use the function drm_sched_entity_init

Signed-off-by: Nayan Deshmukh 
Suggested-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c   | 4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 3 +--
 include/drm/gpu_scheduler.h   | 2 +-
 11 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 09d35051fdd6..533f903356de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -91,7 +91,7 @@ static int amdgpu_ctx_init(struct amdgpu_device *adev,
continue;
 
r = drm_sched_entity_init(>sched, >rings[i].entity,
- rq, amdgpu_sched_jobs, >guilty);
+ rq, >guilty);
if (r)
goto failed;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 205da3ff9cd0..e445e5f9abba 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -111,7 +111,7 @@ static int amdgpu_ttm_global_init(struct amdgpu_device 
*adev)
ring = adev->mman.buffer_funcs_ring;
rq = >sched.sched_rq[DRM_SCHED_PRIORITY_KERNEL];
r = drm_sched_entity_init(>sched, >mman.entity,
- rq, amdgpu_sched_jobs, NULL);
+ rq, NULL);
if (r) {
DRM_ERROR("Failed setting up TTM BO move run queue.\n");
goto error_entity;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 627542b22ae4..c135f3d236e0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -237,7 +237,7 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
ring = >uvd.ring;
rq = >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
r = drm_sched_entity_init(>sched, >uvd.entity,
- rq, amdgpu_sched_jobs, NULL);
+ rq, NULL);
if (r != 0) {
DRM_ERROR("Failed setting up UVD run queue.\n");
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index a33804bd3314..59da1d29b612 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -181,7 +181,7 @@ int amdgpu_vce_sw_init(struct amdgpu_device *adev, unsigned 
long size)
ring = >vce.ring[0];
rq = >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
r = drm_sched_entity_init(>sched, >vce.entity,
- rq, amdgpu_sched_jobs, NULL);
+ rq, NULL);
if (r != 0) {
DRM_ERROR("Failed setting up VCE run queue.\n");
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 58e495330b38..e5d234cf804f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -105,7 +105,7 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
ring = >vcn.ring_dec;
rq = >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
r = drm_sched_entity_init(>sched, >vcn.entity_dec,
- rq, amdgpu_sched_jobs, NULL);
+ rq, NULL);
if (r != 0) {
DRM_ERROR("Failed setting up VCN dec run queue.\n");
return r;
@@ -114,7 +114,7 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
ring = >vcn.ring_enc[0];
rq = >sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
r = drm_sched_entity_init(>sched, >vcn.entity_enc,
- rq, amdgpu_sched_jobs, NULL);
+ rq, NULL);
if (r != 0) {
DRM_ERROR("Failed setting up VCN enc run queue.\n");
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index da55a78d7380..29e9879c9b81 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2380,7 +2380,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,
ring = adev->vm_manager.vm_pte_rings[ring_instance];
rq = 

[PATCH 3/3] drm/scheduler: move the tracepoints file from the include directory

[Nayan Deshmukh]

Move it with the scheduler code. This is mostly a straight forward
rename with no code change except for updating the TRACE_INCLUDE_PATH

Signed-off-by: Nayan Deshmukh 
Suggested-by: Christian König 
---
 drivers/gpu/drm/scheduler/gpu_scheduler.c| 2 +-
 {include/drm => drivers/gpu/drm/scheduler}/gpu_scheduler_trace.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename {include/drm => drivers/gpu/drm/scheduler}/gpu_scheduler_trace.h (97%)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 565b7348db80..698531ed6a43 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -30,7 +30,7 @@
 #include 
 
 #define CREATE_TRACE_POINTS
-#include 
+#include "gpu_scheduler_trace.h"
 
 #define to_drm_sched_job(sched_job)\
container_of((sched_job), struct drm_sched_job, queue_node)
diff --git a/include/drm/gpu_scheduler_trace.h 
b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
similarity index 97%
rename from include/drm/gpu_scheduler_trace.h
rename to drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
index 0789e8d0a0e1..4998ad950a48 100644
--- a/include/drm/gpu_scheduler_trace.h
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
@@ -78,5 +78,5 @@ TRACE_EVENT(drm_sched_process_job,
 
 /* This part must be outside protection */
 #undef TRACE_INCLUDE_PATH
-#define TRACE_INCLUDE_PATH .
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/scheduler
 #include 
-- 
2.14.3

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

[PATCH 0/3] Minor code cleanups in drm/scheduler

[Nayan Deshmukh]

The series is based on drm-next. The 2nd patch also affects
amdgpu and etnaviv drivers.

Nayan Deshmukh (3):
  drm/scheduler: fix param documentation
  drm/scheduler: remove unused parameter
  drm/scheduler: move the tracepoints file from the include directory

 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c  | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c  | 4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c| 2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c| 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
 drivers/gpu/drm/scheduler/gpu_scheduler.c| 8 
 {include/drm => drivers/gpu/drm/scheduler}/gpu_scheduler_trace.h | 2 +-
 include/drm/gpu_scheduler.h  | 2 +-
 12 files changed, 16 insertions(+), 16 deletions(-)
 rename {include/drm => drivers/gpu/drm/scheduler}/gpu_scheduler_trace.h (97%)

-- 
2.14.3

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

Re: [PATCH] drm/edid: Dump valid EDIDs too

[Chris Wilson]

Quoting Ville Syrjälä (2018-03-29 17:14:05)
> On Thu, Mar 29, 2018 at 05:01:13PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-03-29 16:50:23)
> > > From: Ville Syrjälä 
> > > 
> > > Having the EDID available is often very beneficial for bug analysis,
> > > even when the EDID itself is valid and not the direct cause of the
> > > bug. So let's dump the EDID to dmesg even when it's valid. This
> > > should also give us a better historical record of EDIDs for later
> > > analysis.
> > 
> > Isn't this a bit frequent for a largely unchanging blob?
> 
> Perhaps. Though ideally we shouldn't go re-reading it all the time.
> But I guess that's wisful thinking.

Ok, that was far less frequent that I expected for an igt run, though it
does look like Maarten has a few more probes to kill.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/23] drm/atomic-helper: Make drm_atomic_helper_disable_all() update the plane->fb pointers

[Ville Syrjälä]

On Mon, Mar 26, 2018 at 10:28:06PM +0200, Daniel Vetter wrote:
> On Thu, Mar 22, 2018 at 05:22:52PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > drm_atomic_helper_shutdown() needs to release the reference held by
> > plane->fb, so we want to use drm_atomic_clean_old_fb() in
> > drm_atomic_helper_disable_all(). However during suspend/resume, gpu
> > reset and load detection we should probably leave that stuff alone,
> > as otherwise we'd have to make sure we put them back again when
> > we restore the duplicated state to the device. Seems simpler to me
> > to not touch any of it anyway.
> > 
> > v2: Don't inflict the clean_old_fbs bool to drivers (Daniel)
> > 
> > Cc: martin.pe...@free.fr
> > Cc: ch...@chris-wilson.co.uk
> > Cc: Dave Airlie  (v1)
> > Cc: Maarten Lankhorst 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> 
> I think this would be cleaner diff to read if you squash the first 2
> patches together. Also avoids the bisect fail. With that (and I trust you
> to come up with a suitably merged commit message):
> 
> Reviewed-by: Daniel Vetter 

Squashed, and commit message rescribbeled. And with sufficient confidence
from a local smoke test I proceeded to push the easy ones 1-13 (except msm), 
and 22-23 (the load detect stuff for i915). I'll have to figure out the
correct merge order for the rest next week.

Thanks for the reviews.

> 
> I reviewed this by re-reading the analysis from 49d70aeaeca8f62b72b77 and
> trusting my former self :-)
> 
> Cheers, Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 67 
> > ++---
> >  1 file changed, 40 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index c48f187d08de..39a69508d8c9 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2881,31 +2881,9 @@ int __drm_atomic_helper_set_config(struct 
> > drm_mode_set *set,
> > return 0;
> >  }
> >  
> > -/**
> > - * drm_atomic_helper_disable_all - disable all currently active outputs
> > - * @dev: DRM device
> > - * @ctx: lock acquisition context
> > - *
> > - * Loops through all connectors, finding those that aren't turned off and 
> > then
> > - * turns them off by setting their DPMS mode to OFF and deactivating the 
> > CRTC
> > - * that they are connected to.
> > - *
> > - * This is used for example in suspend/resume to disable all currently 
> > active
> > - * functions when suspending. If you just want to shut down everything at 
> > e.g.
> > - * driver unload, look at drm_atomic_helper_shutdown().
> > - *
> > - * Note that if callers haven't already acquired all modeset locks this 
> > might
> > - * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
> > - *
> > - * Returns:
> > - * 0 on success or a negative error code on failure.
> > - *
> > - * See also:
> > - * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
> > - * drm_atomic_helper_shutdown().
> > - */
> > -int drm_atomic_helper_disable_all(struct drm_device *dev,
> > - struct drm_modeset_acquire_ctx *ctx)
> > +static int __drm_atomic_helper_disable_all(struct drm_device *dev,
> > +  struct drm_modeset_acquire_ctx *ctx,
> > +  bool clean_old_fbs)
> >  {
> > struct drm_atomic_state *state;
> > struct drm_connector_state *conn_state;
> > @@ -2914,6 +2892,7 @@ int drm_atomic_helper_disable_all(struct drm_device 
> > *dev,
> > struct drm_plane *plane;
> > struct drm_crtc_state *crtc_state;
> > struct drm_crtc *crtc;
> > +   unsigned int plane_mask = 0;
> > int ret, i;
> >  
> > state = drm_atomic_state_alloc(dev);
> > @@ -2956,14 +2935,48 @@ int drm_atomic_helper_disable_all(struct drm_device 
> > *dev,
> > goto free;
> >  
> > drm_atomic_set_fb_for_plane(plane_state, NULL);
> > +
> > +   if (clean_old_fbs) {
> > +   plane->old_fb = plane->fb;
> > +   plane_mask |= BIT(drm_plane_index(plane));
> > +   }
> > }
> >  
> > ret = drm_atomic_commit(state);
> >  free:
> > +   drm_atomic_clean_old_fb(dev, plane_mask, ret);
> > +
> > drm_atomic_state_put(state);
> > return ret;
> >  }
> > -
> > +/**
> > + * drm_atomic_helper_disable_all - disable all currently active outputs
> > + * @dev: DRM device
> > + * @ctx: lock acquisition context
> > + *
> > + * Loops through all connectors, finding those that aren't turned off and 
> > then
> > + * turns them off by setting their DPMS mode to OFF and deactivating the 
> > CRTC
> > + * that they are connected to.
> > + *
> > + * This is used for example in suspend/resume to disable all currently 
> > 

Re: [PATCH] drm/edid: Dump valid EDIDs too

[Ville Syrjälä]

On Thu, Mar 29, 2018 at 05:01:13PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-03-29 16:50:23)
> > From: Ville Syrjälä 
> > 
> > Having the EDID available is often very beneficial for bug analysis,
> > even when the EDID itself is valid and not the direct cause of the
> > bug. So let's dump the EDID to dmesg even when it's valid. This
> > should also give us a better historical record of EDIDs for later
> > analysis.
> 
> Isn't this a bit frequent for a largely unchanging blob?

Perhaps. Though ideally we shouldn't go re-reading it all the time.
But I guess that's wisful thinking.

Not sure we have a good place where we could memcmp() the new EDID
against the old one and only print if it changed.

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Christian König]

Am 29.03.2018 um 17:45 schrieb Logan Gunthorpe:


On 29/03/18 05:44 AM, Christian König wrote:

Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:

On 28/03/18 01:44 PM, Christian König wrote:

Well, isn't that exactly what dma_map_resource() is good for? As far as
I can see it makes sure IOMMU is aware of the access route and
translates a CPU address into a PCI Bus address.
I'm using that with the AMD IOMMU driver and at least there it works
perfectly fine.

Yes, it would be nice, but no arch has implemented this yet. We are just
lucky in the x86 case because that arch is simple and doesn't need to do
anything for P2P (partially due to the Bus and CPU addresses being the
same). But in the general case, you can't rely on it.

Well, that an arch hasn't implemented it doesn't mean that we don't have
the right interface to do it.

Yes, but right now we don't have a performant way to check if we are
doing P2P or not in the dma_map_X() wrappers.


Why not? I mean the dma_map_resource() function is for P2P while other 
dma_map_* functions are only for system memory.



And this is necessary to
check if the DMA ops in use support it or not. We can't have the
dma_map_X() functions do the wrong thing because they don't support it yet.


Well that sounds like we should just return an error from 
dma_map_resources() when an architecture doesn't support P2P yet as Alex 
suggested.



Devices integrated in the CPU usually only "claim" to be PCIe devices.
In reality their memory request path go directly through the integrated
north bridge. The reason for this is simple better throughput/latency.

These are just more reasons why our patchset restricts to devices behind
a switch. And more mess for someone to deal with if they need to relax
that restriction.


You don't seem to understand the implications: The devices do have a 
common upstream bridge! In other words your code would currently claim 
that P2P is supported, but in practice it doesn't work.


You need to include both drivers which participate in the P2P 
transaction to make sure that both supports this and give them 
opportunity to chicken out and in the case of AMD APUs even redirect the 
request to another location (e.g. participate in the DMA translation).


DMA-buf fortunately seems to handle all this already, that's why we 
choose it as base for our implementation.


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

[Bug 104825] [amdgpu] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed (scratch(0xC040)=0x00000000) when unbinding

[bugzilla-daemon]

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

--- Comment #15 from Andrey Grodzovsky  ---
(In reply to mlen from comment #3)
> I tested amd-staging-drm-next with HEAD at
> f1367d12f5fabb04789c7772594887434c8d9e8b. This time the unbind succeeded,
> but there are still some errors logged and kernel reports locking problem in
> amdgpu:
> 
> [   77.098923] [drm] amdgpu: finishing device.
> [   77.458614] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed
> (scratch(0xC040)=0x)
> [   77.481247] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
> [   77.653815] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed
> (scratch(0xC040)=0x)
> [   77.845085] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed
> (scratch(0xC040)=0x)
> [   77.855055] IPv6: ADDRCONF(NETDEV_CHANGE): virbr10: link becomes ready
> [   78.036695] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed
> (scratch(0xC040)=0x)
> [   78.233244] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed
> (scratch(0xC040)=0x)
> [   78.425058] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed
> (scratch(0xC040)=0x)
> [   78.616635] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed
> (scratch(0xC040)=0x)
> [   78.808323] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed
> (scratch(0xC040)=0x)

Can you retest with latest
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.17-wip to see if
KCQ related errors are gone ?

-- 
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/edid: Dump valid EDIDs too

[Chris Wilson]

Quoting Ville Syrjala (2018-03-29 16:50:23)
> From: Ville Syrjälä 
> 
> Having the EDID available is often very beneficial for bug analysis,
> even when the EDID itself is valid and not the direct cause of the
> bug. So let's dump the EDID to dmesg even when it's valid. This
> should also give us a better historical record of EDIDs for later
> analysis.

Isn't this a bit frequent for a largely unchanging blob?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: Dump valid EDIDs too

[Ville Syrjala]

From: Ville Syrjälä 

Having the EDID available is often very beneficial for bug analysis,
even when the EDID itself is valid and not the direct cause of the
bug. So let's dump the EDID to dmesg even when it's valid. This
should also give us a better historical record of EDIDs for later
analysis.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 39 +++
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 134069f36482..1153b2f74c58 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1517,17 +1517,27 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int 
block, size_t len)
return ret == xfers ? 0 : -1;
 }
 
-static void connector_bad_edid(struct drm_connector *connector,
-  u8 *edid, int num_blocks)
+static void connector_dump_edid(struct drm_connector *connector,
+   u8 *edid, int num_blocks,
+   bool valid)
 {
int i;
 
-   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
-   return;
+   if (valid) {
+   if (!(drm_debug & DRM_UT_KMS))
+   return;
+
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] EDID is valid:\n",
+ connector->base.id, connector->name);
+   } else {
+   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
+   return;
+
+   dev_warn(connector->dev->dev,
+"[CONNECTOR:%d:%s] EDID is invalid:\n",
+connector->base.id, connector->name);
+   }
 
-   dev_warn(connector->dev->dev,
-"%s: EDID is invalid:\n",
-connector->name);
for (i = 0; i < num_blocks; i++) {
u8 *block = edid + i * EDID_LENGTH;
char prefix[20];
@@ -1539,7 +1549,7 @@ static void connector_bad_edid(struct drm_connector 
*connector,
else
sprintf(prefix, "\t[%02x] GOOD ", i);
 
-   print_hex_dump(KERN_WARNING,
+   print_hex_dump(valid ? KERN_DEBUG : KERN_WARNING,
   prefix, DUMP_PREFIX_NONE, 16, 1,
   block, EDID_LENGTH, false);
}
@@ -1580,8 +1590,10 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
if (!override)
override = drm_load_edid_firmware(connector);
 
-   if (!IS_ERR_OR_NULL(override))
-   return override;
+   if (!IS_ERR_OR_NULL(override)) {
+   edid = (u8 *)override;
+   goto done;
+   }
 
if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
@@ -1628,7 +1640,7 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
if (valid_extensions != edid[0x7e]) {
u8 *base;
 
-   connector_bad_edid(connector, edid, edid[0x7e] + 1);
+   connector_dump_edid(connector, edid, edid[0x7e] + 1, false);
 
edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
edid[0x7e] = valid_extensions;
@@ -1652,10 +1664,13 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
edid = new;
}
 
+done:
+   connector_dump_edid(connector, edid, edid[0x7e] + 1, true);
+
return (struct edid *)edid;
 
 carp:
-   connector_bad_edid(connector, edid, 1);
+   connector_dump_edid(connector, edid, 1, false);
 out:
kfree(edid);
return NULL;
-- 
2.16.1

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

Re: [DPU PATCH 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845

[Sean Paul]

On Thu, Mar 29, 2018 at 10:04:33AM -0500, Rob Herring wrote:
> On Mon, Mar 19, 2018 at 1:19 AM,   wrote:
> > On 2018-03-18 18:19, Rob Herring wrote:
> >>
> >> On Wed, Mar 14, 2018 at 11:21:37AM +0530, Sravanthi Kollukuduru wrote:
> >>>
> >>> Remove DT entries of hw block offsets and other target specific catalog
> >>> information for SDM845.
> >>
> >>
> >> That is clear from the diff. The commit msg should answer why?
> >>
> > Will update the commit msg as below in the follow up patch :
> > "Currently, the downstream driver depends on the DT file for the hw offsets
> > and other target specific catalog information.
> > To align the driver with the upstream DT design, this information is now
> > removed from DT file and added in the driver source."
> 
> Based on the answer below, write whatever you want because until it is
> intended for upstream it doesn't matter (to me at least). Though,
> writing good commit messages should perhaps be practiced.
> 
> >>>
> >>> Signed-off-by: Sravanthi Kollukuduru 
> >>> ---
> >>>  .../devicetree/bindings/display/msm/dpu.txt| 530
> >>> -
> >>
> >>
> >> This file is not upstream. What tree is this for?
> >>
> > This is part of the qualcomm efforts to upstream the display controller
> > code.
> > The changes are hosted at
> > https://cgit.freedesktop.org/~seanpaul/dpu-staging/
> 
> Please make that abundantly clear in every patch for this so it is
> obvious to ignore it. Or just keep it on the msm/freedreno lists until
> you are submitting things upstream. 

FWIW, all of these patches are prefixed with "DPU PATCH". While that doesn't
scream "ignore", it is at least a signal that it's not the same as everything
else on the list.

> If you have specific binding
> questions/issues before them, I'm happy to discuss, but otherwise
> folks have more than enough to review just for upstream.

The goal is to get this driver upstream, and these patches are working towards
that goal. It's really helpful to get your feedback, and in general I think we
should encourage vendors to send patches early in order to avoid situations
where they waste a bunch of time implementing/fixing the wrong things.

Sean

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

-- 
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] drm/scheduler: fix param documentation

[Alex Deucher]

On Tue, Mar 27, 2018 at 1:29 PM, Nayan Deshmukh
 wrote:
> On Tue, Mar 27, 2018 at 1:47 PM, Daniel Vetter  wrote:
>> On Mon, Mar 26, 2018 at 08:51:14PM +0530, Nayan Deshmukh wrote:
>>> Signed-off-by: Nayan Deshmukh 
>>
>> You might want to add a kerneldoc page in Documentation/gpu/scheduler.rst,
>> which pulls in all the nice kerneldoc you have here + has a short intro
>> text what this is all about.
>>
> Yeah Sure. I'll send a patch for this in a while.

FWIW, I started improving the documentation in the GPU scheduler last
week, but ran out of time to finish it.  Here's the WIP patch. Feel
free to run with it.

Alex

>
> Cheers,
> Nayan
>> Cheers, Daniel
>>
>>> ---
>>>  drivers/gpu/drm/scheduler/gpu_scheduler.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
>>> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>>> index 0d95888ccc3e..1d368bc66ac2 100644
>>> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>>> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>>> @@ -117,8 +117,9 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
>>>   * @schedThe pointer to the scheduler
>>>   * @entity   The pointer to a valid drm_sched_entity
>>>   * @rq   The run queue this entity belongs
>>> - * @kernel   If this is an entity for the kernel
>>>   * @jobs The max number of jobs in the job queue
>>> + * @guilty  atomic_t set to 1 when a job on this queue
>>> + *  is found to be guilty causing a timeout
>>>   *
>>>   * return 0 if succeed. negative error code on failure
>>>  */
>>> --
>>> 2.14.3
>>>
>>> ___
>>> 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
From 1b98337276bb86e0e6aeacffc4cf7ccfa06d7b55 Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Tue, 20 Mar 2018 23:03:48 -0500
Subject: [PATCH] XXX: wip gpu scheduler documentation

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 160 ++
 1 file changed, 121 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 0d95888ccc3e..635aec73d5f0 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -39,7 +39,13 @@ static bool drm_sched_entity_is_ready(struct drm_sched_entity *entity);
 static void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
 static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb);
 
-/* Initialize a given run queue struct */
+/**
+ * drm_sched_rq_init - initialize a given run queue struct
+ *
+ * @rq: scheduler run queue
+ *
+ * This function initializes a scheduler runqueue.
+ */
 static void drm_sched_rq_init(struct drm_sched_rq *rq)
 {
 	spin_lock_init(>lock);
@@ -47,6 +53,14 @@ static void drm_sched_rq_init(struct drm_sched_rq *rq)
 	rq->current_entity = NULL;
 }
 
+/**
+ * drm_sched_rq_add_entity - add an entity
+ *
+ * @rq: scheduler run queue
+ * @entity: scheduler entity
+ *
+ * This function adds a scheduling entity to the run queue.
+ */
 static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
 struct drm_sched_entity *entity)
 {
@@ -57,6 +71,14 @@ static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
 	spin_unlock(>lock);
 }
 
+/**
+ * drm_sched_rq_remove_entity - remove an entity
+ *
+ * @rq: scheduler run queue
+ * @entity: scheduler entity
+ *
+ * This function removes a scheduling entity from the run queue.
+ */
 static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
    struct drm_sched_entity *entity)
 {
@@ -70,9 +92,9 @@ static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
 }
 
 /**
- * Select an entity which could provide a job to run
+ * drm_sched_rq_select_entity - Select an entity which could provide a job to run
  *
- * @rq		The run queue to check.
+ * @rq: scheduler run queue to check.
  *
  * Try to find a ready entity, returns NULL if none found.
  */
@@ -112,16 +134,17 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
 }
 
 /**
- * Init a context entity used by scheduler when submit to HW ring.
+ * drm_sched_entity_init - init a context entity used by scheduler when submit to HW queue
  *
- * @sched	The pointer to the scheduler
- * @entity	The pointer to a valid drm_sched_entity
- * @rq		The run queue this entity belongs
- * @kernel	If this is an entity for the kernel
- * @jobs	The max number of jobs in the job queue
+ * @sched: scheduler instance
+ * @entity: 

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

[Boris Brezillon]

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.

v6: add missing drm_atomic_set_fb_for_plane() in
vc4_plane_atomic_async_update() (Boris Brezillon)

v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)

v4: add drm_atomic_helper_async() commit (Eric Anholt)

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Eric Anholt 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Eric Anholt 
Signed-off-by: Eric Anholt 
Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_kms.c   |  20 ++
 drivers/gpu/drm/vc4/vc4_plane.c | 131 +---
 2 files changed, 74 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ba60153dddb5..e791e498a3dd 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -90,6 +90,26 @@ static int vc4_atomic_commit(struct drm_device *dev,
struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
 
+   if (state->async_update) {
+   ret = down_interruptible(>async_modeset);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_prepare_planes(dev, state);
+   if (ret) {
+   up(>async_modeset);
+   return ret;
+   }
+
+   drm_atomic_helper_async_commit(dev, state);
+
+   drm_atomic_helper_cleanup_planes(dev, state);
+
+   up(>async_modeset);
+
+   return 0;
+   }
+
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index ce39390be389..33c1bcf4e0f4 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -741,6 +741,57 @@ void vc4_plane_async_set_fb(struct drm_plane *plane, 
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
 }
 
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+   struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
+
+   if (plane->state->fb != state->fb) {
+   drm_atomic_set_fb_for_plane(plane->state, state->fb);
+   vc4_plane_async_set_fb(plane, state->fb);
+   }
+
+   /* Set the cursor's position on the screen.  This is the
+* expected change from the drm_mode_cursor_universal()
+* helper.
+*/
+   plane->state->crtc_x = state->crtc_x;
+   plane->state->crtc_y = state->crtc_y;
+
+   /* Allow changing the start position within the cursor BO, if
+* that matters.
+*/
+   plane->state->src_x = state->src_x;
+   plane->state->src_y = state->src_y;
+
+   /* Update the display list based on the new crtc_x/y. */
+   vc4_plane_atomic_check(plane, plane->state);
+
+   /* Note that we can't just call vc4_plane_write_dlist()
+* because that would smash the context data that the HVS is
+* currently using.
+*/
+   writel(vc4_state->dlist[vc4_state->pos0_offset],
+  _state->hw_dlist[vc4_state->pos0_offset]);
+   writel(vc4_state->dlist[vc4_state->pos2_offset],
+  _state->hw_dlist[vc4_state->pos2_offset]);
+   writel(vc4_state->dlist[vc4_state->ptr0_offset],
+  _state->hw_dlist[vc4_state->ptr0_offset]);
+}
+
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   /* No configuring new scaling in the fast path. */
+   if (plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h)
+   return -EINVAL;
+
+   return 0;
+}
+
 static int vc4_prepare_fb(struct drm_plane *plane,
  struct drm_plane_state *state)
 {
@@ -780,6 +831,8 @@ static const struct drm_plane_helper_funcs 
vc4_plane_helper_funcs = {
.atomic_update = vc4_plane_atomic_update,
.prepare_fb = vc4_prepare_fb,
.cleanup_fb = vc4_cleanup_fb,
+   .atomic_async_check = vc4_plane_atomic_async_check,
+   .atomic_async_update = vc4_plane_atomic_async_update,
 };
 
 static void vc4_plane_destroy(struct drm_plane *plane)
@@ -788,82 +841,6 @@ static void vc4_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
 }
 
-/* Implements immediate (non-vblank-synced) updates of the 

RE: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

"Mao, David"  writes:

> Hi Keith,
> If I read the patch correctly, the plane has been interpreted as the same as 
> connector, and the stackIndex is the index of connector of current device.
> Is it by intentional?
> If the hardware don't have underlay/overlay supported, is it better to
> always report plane 0 rather than pretend to have multiple plane?

Yes, you're right. I must have mis-read the specification when writing
this function. Thanks for catching this. I've merged this fix into the
patch and re-pushed it to my drm-lease-v2 branch.

-- 
-keith


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

Re: [DPU PATCH 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845

[Rob Herring]

On Mon, Mar 19, 2018 at 1:19 AM,   wrote:
> On 2018-03-18 18:19, Rob Herring wrote:
>>
>> On Wed, Mar 14, 2018 at 11:21:37AM +0530, Sravanthi Kollukuduru wrote:
>>>
>>> Remove DT entries of hw block offsets and other target specific catalog
>>> information for SDM845.
>>
>>
>> That is clear from the diff. The commit msg should answer why?
>>
> Will update the commit msg as below in the follow up patch :
> "Currently, the downstream driver depends on the DT file for the hw offsets
> and other target specific catalog information.
> To align the driver with the upstream DT design, this information is now
> removed from DT file and added in the driver source."

Based on the answer below, write whatever you want because until it is
intended for upstream it doesn't matter (to me at least). Though,
writing good commit messages should perhaps be practiced.

>>>
>>> Signed-off-by: Sravanthi Kollukuduru 
>>> ---
>>>  .../devicetree/bindings/display/msm/dpu.txt| 530
>>> -
>>
>>
>> This file is not upstream. What tree is this for?
>>
> This is part of the qualcomm efforts to upstream the display controller
> code.
> The changes are hosted at
> https://cgit.freedesktop.org/~seanpaul/dpu-staging/

Please make that abundantly clear in every patch for this so it is
obvious to ignore it. Or just keep it on the msm/freedreno lists until
you are submitting things upstream. If you have specific binding
questions/issues before them, I'm happy to discuss, but otherwise
folks have more than enough to review just for upstream.

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

Re: [DPU PATCH v2 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845

[Sean Paul]

On Thu, Mar 29, 2018 at 03:59:24PM +0530, Sravanthi Kollukuduru wrote:
> Currently, the downstream driver depends on the DT file for the
> hardware block offsets and other target specific catalog information.
> To align the driver with the upstream DT design, this information is now
> removed from the DT file and added in the driver source.
> 

Reviewed-by: Sean Paul 


> Change-Id: I63a366d7d7a26939ee1c20c702c7d4d976852067

(btw, please strip these out when you send patches upstream. I will remove it
when applying)

> Signed-off-by: Sravanthi Kollukuduru 
> ---
>  .../devicetree/bindings/display/msm/dpu.txt| 530 
> -
>  1 file changed, 530 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
> b/Documentation/devicetree/bindings/display/msm/dpu.txt
> index 136f0d3..90cd3e0 100644
> --- a/Documentation/devicetree/bindings/display/msm/dpu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
> @@ -19,61 +19,6 @@ Required properties
>  - interrupt-controller: Mark the device node as an interrupt controller.
>  - #interrupt-cells: Should be one. The first cell is interrupt number.
>  - iommus: Specifies the SID's used by this context bank.
> -- qcom,dpu-sspp-type:Array of strings for DPU source surface 
> pipes type information.
> - A source pipe can be "vig", "rgb", "dma" or 
> "cursor" type.
> - Number of xin ids defined should match the 
> number of offsets
> - defined in property: qcom,dpu-sspp-off.
> -- qcom,dpu-sspp-off: Array of offset for DPU source surface pipes. 
> The offsets
> - are calculated from register "mdp_phys" defined 
> in
> - reg property + "dpu-off". The number of offsets 
> defined here should
> - reflect the amount of pipes that can be active 
> in DPU for
> - this configuration.
> -- qcom,dpu-sspp-xin-id:  Array of VBIF clients ids (xins) 
> corresponding
> - to the respective source pipes. Number of xin 
> ids
> - defined should match the number of offsets
> - defined in property: qcom,dpu-sspp-off.
> -- qcom,dpu-ctl-off:  Array of offset addresses for the available ctl
> - hw blocks within DPU, these offsets are
> - calculated from register "mdp_phys" defined in
> - reg property.  The number of ctl offsets defined
> - here should reflect the number of control paths
> - that can be configured concurrently on DPU for
> - this configuration.
> -- qcom,dpu-wb-off:   Array of offset addresses for the programmable
> - writeback blocks within DPU.
> -- qcom,dpu-wb-xin-id:Array of VBIF clients ids (xins) 
> corresponding
> - to the respective writeback. Number of xin ids
> - defined should match the number of offsets
> - defined in property: qcom,dpu-wb-off.
> -- qcom,dpu-mixer-off:Array of offset addresses for the 
> available
> - mixer blocks that can drive data to panel
> - interfaces. These offsets are be calculated from
> - register "mdp_phys" defined in reg property.
> - The number of offsets defined should reflect the
> - amount of mixers that can drive data to a panel
> - interface.
> -- qcom,dpu-dspp-top-off: Offset address for the dspp top block.
> - The offset is calculated from register 
> "mdp_phys"
> - defined in reg property.
> -- qcom,dpu-dspp-off: Array of offset addresses for the 
> available dspp
> - blocks. These offsets are calculated from
> - register "mdp_phys" defined in reg property.
> -- qcom,dpu-pp-off:   Array of offset addresses for the available
> - pingpong blocks. These offsets are calculated
> - from register "mdp_phys" defined in reg 
> property.
> -- qcom,dpu-pp-slave: Array of flags indicating whether each ping pong
> - block may be configured as a pp slave.
> -- qcom,dpu-intf-off: Array of offset addresses for the available DPU
> - interface blocks that can drive data to a
> - panel controller. The offsets are calculated
> -

Re: [PATCH v2 4/4] drm/i915: Fix downstream dev count read

[Sean Paul]

On Thu, Mar 29, 2018 at 07:39:08PM +0530, Ramalingam C wrote:
> In both HDMI and DP, device count is represented by 6:0 bits of a
> register(BInfo/Bstatus)
> 
> So macro for bitmasking the device_count is fixed(0x3F->0x7F).
> 


Reviewed-by: Sean Paul 

> Signed-off-by: Ramalingam C 
> cc: Sean Paul 
> ---
>  include/drm/drm_hdcp.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index 562fa7df2637..98e63d870139 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -19,7 +19,7 @@
>  #define DRM_HDCP_RI_LEN  2
>  #define DRM_HDCP_V_PRIME_PART_LEN4
>  #define DRM_HDCP_V_PRIME_NUM_PARTS   5
> -#define DRM_HDCP_NUM_DOWNSTREAM(x)   (x & 0x3f)
> +#define DRM_HDCP_NUM_DOWNSTREAM(x)   (x & 0x7f)
>  #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x) (x & BIT(3))
>  #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)  (x & BIT(7))
>  
> -- 
> 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 2/4] drm/i915: Read Vprime thrice incase of mismatch

[Sean Paul]

On Thu, Mar 29, 2018 at 07:39:06PM +0530, Ramalingam C wrote:
> In case of V prime mismatch, DP HDCP spec mandates the re-read of
> Vprime atleast twice.
> 
> This patch needed for DP HDCP1.4 CTS Test: 1B-05.
> 
> v2:
>   Moved the V' validation into a function for retry. [Sean Paul]
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 113 
> +++---
>  1 file changed, 70 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 96b9025dc759..f77d956b2b18 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -142,53 +142,17 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
>   return true;
>  }
>  
> -/* Implements Part 2 of the HDCP authorization procedure */
> -static
> -int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> -const struct intel_hdcp_shim *shim)
> +static inline

Why inline?

> +int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
> + const struct intel_hdcp_shim *shim,
> + u8 *ksv_fifo, u8 num_downstream, u8 *bstatus)
>  {
>   struct drm_i915_private *dev_priv;
>   u32 vprime, sha_text, sha_leftovers, rep_ctl;
> - u8 bstatus[2], num_downstream, *ksv_fifo;
>   int ret, i, j, sha_idx;
>  
>   dev_priv = intel_dig_port->base.base.dev->dev_private;
>  
> - ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
> - if (ret) {
> - DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
> - return ret;
> - }
> -
> - ret = shim->read_bstatus(intel_dig_port, bstatus);
> - if (ret)
> - return ret;
> -
> - if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
> - DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
> - DRM_ERROR("Max Topology Limit Exceeded\n");
> - return -EPERM;
> - }
> -
> - /*
> -  * When repeater reports 0 device count, HDCP1.4 spec allows disabling
> -  * the HDCP encryption. That implies that repeater can't have its own
> -  * display. As there is no consumption of encrypted content in the
> -  * repeater with 0 downstream devices, we are failing the
> -  * authentication.
> -  */
> - num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
> - if (num_downstream == 0)
> - return -EINVAL;
> -
> - ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
> - if (!ksv_fifo)
> - return -ENOMEM;
> -
> - ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
> - if (ret)
> - return ret;
> -
>   /* Process V' values from the receiver */
>   for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
>   ret = shim->read_v_prime_part(intel_dig_port, i, );
> @@ -353,7 +317,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   return ret;
>   sha_idx += sizeof(sha_text);
>   } else {
> - DRM_ERROR("Invalid number of leftovers %d\n", sha_leftovers);
> + DRM_DEBUG("Invalid number of leftovers %d\n", sha_leftovers);
>   return -EINVAL;
>   }
>  
> @@ -381,14 +345,77 @@ int intel_hdcp_auth_downstream(struct 
> intel_digital_port *intel_dig_port,
>   if (intel_wait_for_register(dev_priv, HDCP_REP_CTL,
>   HDCP_SHA1_COMPLETE,
>   HDCP_SHA1_COMPLETE, 1)) {
> - DRM_ERROR("Timed out waiting for SHA1 complete\n");
> + DRM_DEBUG("Timed out waiting for SHA1 complete\n");
>   return -ETIMEDOUT;
>   }
>   if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
> - DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
> + DRM_DEBUG("SHA-1 mismatch, HDCP failed\n");

I think the DEBUG should be DEBUG_KMS, consistent with the rest of the file?

>   return -ENXIO;
>   }
>  
> + return 0;
> +}
> +
> +/* Implements Part 2 of the HDCP authorization procedure */
> +static
> +int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> +const struct intel_hdcp_shim *shim)
> +{
> + u8 bstatus[2], num_downstream, *ksv_fifo;
> + int ret, i, tries = 3;
> +
> + ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
> + if (ret) {
> + DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
> + return ret;
> + }
> +
> + ret = shim->read_bstatus(intel_dig_port, bstatus);
> + if (ret)
> + return ret;
> +
> + if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
> + DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
> + DRM_ERROR("Max Topology Limit Exceeded\n");
> + return -EPERM;
> + }
> +
> + /*
> + 

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Alex Deucher]

Sorry, didn't mean to drop the lists here. re-adding.

On Wed, Mar 28, 2018 at 4:05 PM, Alex Deucher  wrote:
> On Wed, Mar 28, 2018 at 3:53 PM, Logan Gunthorpe  wrote:
>>
>>
>> On 28/03/18 01:44 PM, Christian König wrote:
>>> Well, isn't that exactly what dma_map_resource() is good for? As far as
>>> I can see it makes sure IOMMU is aware of the access route and
>>> translates a CPU address into a PCI Bus address.
>>
>>> I'm using that with the AMD IOMMU driver and at least there it works
>>> perfectly fine.
>>
>> Yes, it would be nice, but no arch has implemented this yet. We are just
>> lucky in the x86 case because that arch is simple and doesn't need to do
>> anything for P2P (partially due to the Bus and CPU addresses being the
>> same). But in the general case, you can't rely on it.
>
> Could we do something for the arches where it works?  I feel like peer
> to peer has dragged out for years because everyone is trying to boil
> the ocean for all arches.  There are a huge number of use cases for
> peer to peer on these "simple" architectures which actually represent
> a good deal of the users that want this.
>
> Alex
>
>>
> Yeah, but not for ours. See if you want to do real peer 2 peer you need
> to keep both the operation as well as the direction into account.
 Not sure what you are saying here... I'm pretty sure we are doing "real"
 peer 2 peer...

> For example when you can do writes between A and B that doesn't mean
> that writes between B and A work. And reads are generally less likely to
> work than writes. etc...
 If both devices are behind a switch then the PCI spec guarantees that A
 can both read and write B and vice versa.
>>>
>>> Sorry to say that, but I know a whole bunch of PCI devices which
>>> horrible ignores that.
>>
>> Can you elaborate? As far as the device is concerned it shouldn't know
>> whether a request comes from a peer or from the host. If it does do
>> crazy stuff like that it's well out of spec. It's up to the switch (or
>> root complex if good support exists) to route the request to the device
>> and it's the root complex that tends to be what drops the load requests
>> which causes the asymmetries.
>>
>> Logan
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

[Sean Paul]

On Thu, Mar 29, 2018 at 07:39:05PM +0530, Ramalingam C wrote:
> As per DP spec when R0 mismatch is detected, HDCP source supported
> re-read the R0 atleast twice.
> 
> And For HDMI and DP minimum wait required for the R0 availability is
> 100mSec. So this patch changes the wait time to 100mSec but retries
> twice with the time interval of 100mSec for each attempt.
> 
> This patch is needed for DP HDCP1.4 CTS Test: 1A-06.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 30 +++---
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 14ca5d3057a7..96b9025dc759 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -496,9 +496,11 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   }
>  
>   /*
> -  * Wait for R0' to become available. The spec says 100ms from Aksv, but
> -  * some monitors can take longer than this. We'll set the timeout at
> -  * 300ms just to be sure.
> +  * Wait for R0' to become available. The spec says minimum 100ms from
> +  * Aksv, but some monitors can take longer than this. So we are
> +  * combinely waiting for 300mSec just to be sure in case of HDMI.
> +  * DP HDCP Spec mandates the two more reattempt to read R0, incase
> +  * of R0 mismatch.

I am sorry to nitpick comments, but this doesn't belong here. Leave this comment
alone and add the part about the DP spec requiring retries directly above the
loop where we're actually doing the retries.

Sean

>*
>* On DP, there's an R0_READY bit available but no such bit
>* exists on HDMI. Since the upper-bound is the same, we'll just do
> @@ -506,15 +508,21 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>*/
>   wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
>  
> - ri.reg = 0;
> - ret = shim->read_ri_prime(intel_dig_port, ri.shim);
> - if (ret)
> - return ret;
> - I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
> + tries = 3;
> + for (i = 0; i < tries; i++) {
> + ri.reg = 0;
> + ret = shim->read_ri_prime(intel_dig_port, ri.shim);
> + if (ret)
> + return ret;
> + I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
>  
> - /* Wait for Ri prime match */
> - if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
> -  (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
> + /* Wait for Ri prime match */
> + if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
> + (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
> + break;
> + }
> +
> + if (i == tries) {
>   DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
> I915_READ(PORT_HDCP_STATUS(port)));
>   return -ETIMEDOUT;
> -- 
> 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 3/4] drm/i915: Check hdcp key loadability

[Ville Syrjälä]

On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam C wrote:
> HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
> is enabled. Using the I915 power well infrastruture, above requirement
> is verified.
> 
> This patch enables the hdcp initialization for HSW, BDW, and BXT.
> 
> v2:
>   Choose the PW# based on the platform.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 41 
> +--
>  1 file changed, 39 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index f77d956b2b18..d8af09b46a44 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -37,6 +37,43 @@ static int intel_hdcp_poll_ksv_fifo(struct 
> intel_digital_port *intel_dig_port,
>   return 0;
>  }
>  
> +static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
> +{
> + struct i915_power_domains *power_domains = _priv->power_domains;
> + struct i915_power_well *power_well;
> + enum i915_power_well_id id;
> + bool enabled = false;
> +
> + /*
> +  * On HSW and BDW, Display HW loads the Key as soon as Display resumes.
> +  * On all BXT+, SW can load the keys only when the PW#1 is turned on.
> +  */
> + if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + id = HSW_DISP_PW_GLOBAL;
> + else
> + id = SKL_DISP_PW_1;
> +
> + mutex_lock(_domains->lock);
> +
> + /* PG1 (power well #1) needs to be enabled */
> + for_each_power_well(dev_priv, power_well) {
> + if (power_well->id == id) {
> + enabled = power_well->ops->is_enabled(dev_priv,
> +   power_well);
> + break;
> + }
> + }
> + mutex_unlock(_domains->lock);
> +
> + /*
> +  * Another req for hdcp key loadability is enabled state of pll for
> +  * cdclk. Without active crtc we wont land here. So we are assuming that
> +  * cdclk is already on.
> +  */
> +
> + return enabled;
> +}
> +
>  static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
>  {
>   I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
> @@ -615,8 +652,8 @@ static int _intel_hdcp_enable(struct intel_connector 
> *connector)
>   DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
> connector->base.name, connector->base.base.id);
>  
> - if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
> - DRM_ERROR("PG1 is disabled, cannot load keys\n");
> + if (!hdcp_key_loadable(dev_priv)) {
> + DRM_ERROR("HDCP key Load is not possible\n");
>   return -ENXIO;
>   }

If you need the power well then why aren't you grabbing the correct
power domain reference somewhere?

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

Re: [PATCH v2 0/4] HDCP1.4 fixes

[Ramalingam C]

On Thursday 29 March 2018 07:39 PM, Ramalingam C wrote:

First two patches needed for below DP HDCP compliance tests
1A-06 and 1B-05

Third patch fixes the HDCP1.4 Key loadability check. where as fourth
one fixes the downstream device count read.

Fix for HDMI HDCP1.4 CTS tests: 1A-04 and 1A-07a are functional.
But the change from v2, as thinking to put through more regressive


The change is removed from v2*

All other changes are well tested on KBL.

--Ram


testing before upstreaming.

Ramalingam C (4):
   drm/i915: Read HDCP R0 thrice in case of mismatch
   drm/i915: Read Vprime thrice incase of mismatch
   drm/i915: Check hdcp key loadability
   drm/i915: Fix downstream dev count read

  drivers/gpu/drm/i915/intel_hdcp.c | 184 ++
  include/drm/drm_hdcp.h|   2 +-
  2 files changed, 129 insertions(+), 57 deletions(-)



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

[PATCH v2 4/4] drm/i915: Fix downstream dev count read

[Ramalingam C]

In both HDMI and DP, device count is represented by 6:0 bits of a
register(BInfo/Bstatus)

So macro for bitmasking the device_count is fixed(0x3F->0x7F).

Signed-off-by: Ramalingam C 
cc: Sean Paul 
---
 include/drm/drm_hdcp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 562fa7df2637..98e63d870139 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -19,7 +19,7 @@
 #define DRM_HDCP_RI_LEN2
 #define DRM_HDCP_V_PRIME_PART_LEN  4
 #define DRM_HDCP_V_PRIME_NUM_PARTS 5
-#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
 #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x)   (x & BIT(3))
 #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)(x & BIT(7))
 
-- 
2.7.4

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

[PATCH v2 0/4] HDCP1.4 fixes

[Ramalingam C]

First two patches needed for below DP HDCP compliance tests
1A-06 and 1B-05

Third patch fixes the HDCP1.4 Key loadability check. where as fourth
one fixes the downstream device count read.

Fix for HDMI HDCP1.4 CTS tests: 1A-04 and 1A-07a are functional.
But the change from v2, as thinking to put through more regressive
testing before upstreaming.

Ramalingam C (4):
  drm/i915: Read HDCP R0 thrice in case of mismatch
  drm/i915: Read Vprime thrice incase of mismatch
  drm/i915: Check hdcp key loadability
  drm/i915: Fix downstream dev count read

 drivers/gpu/drm/i915/intel_hdcp.c | 184 ++
 include/drm/drm_hdcp.h|   2 +-
 2 files changed, 129 insertions(+), 57 deletions(-)

-- 
2.7.4

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

[PATCH v2 3/4] drm/i915: Check hdcp key loadability

[Ramalingam C]

HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.

This patch enables the hdcp initialization for HSW, BDW, and BXT.

v2:
  Choose the PW# based on the platform.

Signed-off-by: Ramalingam C 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 41 +--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index f77d956b2b18..d8af09b46a44 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -37,6 +37,43 @@ static int intel_hdcp_poll_ksv_fifo(struct 
intel_digital_port *intel_dig_port,
return 0;
 }
 
+static bool hdcp_key_loadable(struct drm_i915_private *dev_priv)
+{
+   struct i915_power_domains *power_domains = _priv->power_domains;
+   struct i915_power_well *power_well;
+   enum i915_power_well_id id;
+   bool enabled = false;
+
+   /*
+* On HSW and BDW, Display HW loads the Key as soon as Display resumes.
+* On all BXT+, SW can load the keys only when the PW#1 is turned on.
+*/
+   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+   id = HSW_DISP_PW_GLOBAL;
+   else
+   id = SKL_DISP_PW_1;
+
+   mutex_lock(_domains->lock);
+
+   /* PG1 (power well #1) needs to be enabled */
+   for_each_power_well(dev_priv, power_well) {
+   if (power_well->id == id) {
+   enabled = power_well->ops->is_enabled(dev_priv,
+ power_well);
+   break;
+   }
+   }
+   mutex_unlock(_domains->lock);
+
+   /*
+* Another req for hdcp key loadability is enabled state of pll for
+* cdclk. Without active crtc we wont land here. So we are assuming that
+* cdclk is already on.
+*/
+
+   return enabled;
+}
+
 static void intel_hdcp_clear_keys(struct drm_i915_private *dev_priv)
 {
I915_WRITE(HDCP_KEY_CONF, HDCP_CLEAR_KEYS_TRIGGER);
@@ -615,8 +652,8 @@ static int _intel_hdcp_enable(struct intel_connector 
*connector)
DRM_DEBUG_KMS("[%s:%d] HDCP is being enabled...\n",
  connector->base.name, connector->base.base.id);
 
-   if (!(I915_READ(SKL_FUSE_STATUS) & SKL_FUSE_PG_DIST_STATUS(1))) {
-   DRM_ERROR("PG1 is disabled, cannot load keys\n");
+   if (!hdcp_key_loadable(dev_priv)) {
+   DRM_ERROR("HDCP key Load is not possible\n");
return -ENXIO;
}
 
-- 
2.7.4

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

[PATCH v2 2/4] drm/i915: Read Vprime thrice incase of mismatch

[Ramalingam C]

In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.

This patch needed for DP HDCP1.4 CTS Test: 1B-05.

v2:
  Moved the V' validation into a function for retry. [Sean Paul]

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 113 +++---
 1 file changed, 70 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 96b9025dc759..f77d956b2b18 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -142,53 +142,17 @@ bool intel_hdcp_is_ksv_valid(u8 *ksv)
return true;
 }
 
-/* Implements Part 2 of the HDCP authorization procedure */
-static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
-  const struct intel_hdcp_shim *shim)
+static inline
+int intel_hdcp_validate_v_prime(struct intel_digital_port *intel_dig_port,
+   const struct intel_hdcp_shim *shim,
+   u8 *ksv_fifo, u8 num_downstream, u8 *bstatus)
 {
struct drm_i915_private *dev_priv;
u32 vprime, sha_text, sha_leftovers, rep_ctl;
-   u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, j, sha_idx;
 
dev_priv = intel_dig_port->base.base.dev->dev_private;
 
-   ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
-   if (ret) {
-   DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
-   return ret;
-   }
-
-   ret = shim->read_bstatus(intel_dig_port, bstatus);
-   if (ret)
-   return ret;
-
-   if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
-   DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
-   DRM_ERROR("Max Topology Limit Exceeded\n");
-   return -EPERM;
-   }
-
-   /*
-* When repeater reports 0 device count, HDCP1.4 spec allows disabling
-* the HDCP encryption. That implies that repeater can't have its own
-* display. As there is no consumption of encrypted content in the
-* repeater with 0 downstream devices, we are failing the
-* authentication.
-*/
-   num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
-   if (num_downstream == 0)
-   return -EINVAL;
-
-   ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
-   if (!ksv_fifo)
-   return -ENOMEM;
-
-   ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
-   if (ret)
-   return ret;
-
/* Process V' values from the receiver */
for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
ret = shim->read_v_prime_part(intel_dig_port, i, );
@@ -353,7 +317,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
return ret;
sha_idx += sizeof(sha_text);
} else {
-   DRM_ERROR("Invalid number of leftovers %d\n", sha_leftovers);
+   DRM_DEBUG("Invalid number of leftovers %d\n", sha_leftovers);
return -EINVAL;
}
 
@@ -381,14 +345,77 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
if (intel_wait_for_register(dev_priv, HDCP_REP_CTL,
HDCP_SHA1_COMPLETE,
HDCP_SHA1_COMPLETE, 1)) {
-   DRM_ERROR("Timed out waiting for SHA1 complete\n");
+   DRM_DEBUG("Timed out waiting for SHA1 complete\n");
return -ETIMEDOUT;
}
if (!(I915_READ(HDCP_REP_CTL) & HDCP_SHA1_V_MATCH)) {
-   DRM_ERROR("SHA-1 mismatch, HDCP failed\n");
+   DRM_DEBUG("SHA-1 mismatch, HDCP failed\n");
return -ENXIO;
}
 
+   return 0;
+}
+
+/* Implements Part 2 of the HDCP authorization procedure */
+static
+int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
+  const struct intel_hdcp_shim *shim)
+{
+   u8 bstatus[2], num_downstream, *ksv_fifo;
+   int ret, i, tries = 3;
+
+   ret = intel_hdcp_poll_ksv_fifo(intel_dig_port, shim);
+   if (ret) {
+   DRM_ERROR("KSV list failed to become ready (%d)\n", ret);
+   return ret;
+   }
+
+   ret = shim->read_bstatus(intel_dig_port, bstatus);
+   if (ret)
+   return ret;
+
+   if (DRM_HDCP_MAX_DEVICE_EXCEEDED(bstatus[0]) ||
+   DRM_HDCP_MAX_CASCADE_EXCEEDED(bstatus[1])) {
+   DRM_ERROR("Max Topology Limit Exceeded\n");
+   return -EPERM;
+   }
+
+   /*
+* When repeater reports 0 device count, HDCP1.4 spec allows disabling
+* the HDCP encryption. That implies that repeater can't have its own
+* display. As there is no consumption of encrypted content in the
+* repeater with 0 

[PATCH v2 1/4] drm/i915: Read HDCP R0 thrice in case of mismatch

[Ramalingam C]

As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.

And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.

This patch is needed for DP HDCP1.4 CTS Test: 1A-06.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 14ca5d3057a7..96b9025dc759 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -496,9 +496,11 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
}
 
/*
-* Wait for R0' to become available. The spec says 100ms from Aksv, but
-* some monitors can take longer than this. We'll set the timeout at
-* 300ms just to be sure.
+* Wait for R0' to become available. The spec says minimum 100ms from
+* Aksv, but some monitors can take longer than this. So we are
+* combinely waiting for 300mSec just to be sure in case of HDMI.
+* DP HDCP Spec mandates the two more reattempt to read R0, incase
+* of R0 mismatch.
 *
 * On DP, there's an R0_READY bit available but no such bit
 * exists on HDMI. Since the upper-bound is the same, we'll just do
@@ -506,15 +508,21 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
 */
wait_remaining_ms_from_jiffies(r0_prime_gen_start, 300);
 
-   ri.reg = 0;
-   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
-   if (ret)
-   return ret;
-   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
+   tries = 3;
+   for (i = 0; i < tries; i++) {
+   ri.reg = 0;
+   ret = shim->read_ri_prime(intel_dig_port, ri.shim);
+   if (ret)
+   return ret;
+   I915_WRITE(PORT_HDCP_RPRIME(port), ri.reg);
 
-   /* Wait for Ri prime match */
-   if (wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
-(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
+   /* Wait for Ri prime match */
+   if (!wait_for(I915_READ(PORT_HDCP_STATUS(port)) &
+   (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
+   break;
+   }
+
+   if (i == tries) {
DRM_ERROR("Timed out waiting for Ri prime match (%x)\n",
  I915_READ(PORT_HDCP_STATUS(port)));
return -ETIMEDOUT;
-- 
2.7.4

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

[Bug 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

--- Comment #11 from tempel.jul...@gmail.com ---
One of the recent changes in drm-next-4.17-wip has also introduced this issue
for the old legacy DC.

-- 
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 105680] [CI] igt@kms_frontbuffer_tracking@* - fail - FBC disabled: mode too large for compression

[bugzilla-daemon]

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

--- Comment #3 from Jani Saarinen  ---
>From Tomi:
"SKL-6770hq BIOS settings 
Graphics minimum memory 64MB -> 256MB, 
Graphics mem aperture 256MB -> 1024MB

Hopefully helps.

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

Re: [PATCH v5 1/1] drm/xen-front: Add support for Xen PV display frontend

[kbuild test robot]

Hi Oleksandr,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20180329]
[cannot apply to v4.16-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Oleksandr-Andrushchenko/drm-xen-front-Add-support-for-Xen-PV-display-frontend/20180329-191740
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/xen/xen_drm_front.c:484:13: sparse: undefined identifier 
'drm_dev_enter'
   drivers/gpu/drm/xen/xen_drm_front.c:487:17: sparse: undefined identifier 
'drm_dev_exit'
   drivers/gpu/drm/xen/xen_drm_front.c:484:26: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front.c:487:29: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front.c: In function 
'xen_drm_drv_free_object_unlocked':
>> drivers/gpu/drm/xen/xen_drm_front.c:484:6: error: implicit declaration of 
>> function 'drm_dev_enter'; did you mean 'drm_dev_unref'? 
>> [-Werror=implicit-function-declaration]
 if (drm_dev_enter(obj->dev, )) {
 ^
 drm_dev_unref
>> drivers/gpu/drm/xen/xen_drm_front.c:487:3: error: implicit declaration of 
>> function 'drm_dev_exit'; did you mean 'drm_dev_init'? 
>> [-Werror=implicit-function-declaration]
  drm_dev_exit(idx);
  ^~~~
  drm_dev_init
   cc1: some warnings being treated as errors
--
   drivers/gpu/drm/xen/xen_drm_front_kms.c:40:13: sparse: undefined identifier 
'drm_dev_enter'
   drivers/gpu/drm/xen/xen_drm_front_kms.c:43:17: sparse: undefined identifier 
'drm_dev_exit'
   drivers/gpu/drm/xen/xen_drm_front_kms.c:119:14: sparse: undefined identifier 
'drm_dev_enter'
   drivers/gpu/drm/xen/xen_drm_front_kms.c:132:9: sparse: undefined identifier 
'drm_dev_exit'
   drivers/gpu/drm/xen/xen_drm_front_kms.c:141:13: sparse: undefined identifier 
'drm_dev_enter'
   drivers/gpu/drm/xen/xen_drm_front_kms.c:144:17: sparse: undefined identifier 
'drm_dev_exit'
   drivers/gpu/drm/xen/xen_drm_front_kms.c:258:14: sparse: undefined identifier 
'drm_dev_enter'
   drivers/gpu/drm/xen/xen_drm_front_kms.c:274:9: sparse: undefined identifier 
'drm_dev_exit'
   drivers/gpu/drm/xen/xen_drm_front_kms.c:296:19: sparse: incorrect type in 
initializer (different argument counts)
   drivers/gpu/drm/xen/xen_drm_front_kms.c:296:19:expected void ( *enable 
)( ... )
   drivers/gpu/drm/xen/xen_drm_front_kms.c:296:19:got void ( * )( 
... )
   drivers/gpu/drm/xen/xen_drm_front_kms.c:40:26: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front_kms.c:43:29: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front_kms.c:119:27: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front_kms.c:132:21: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front_kms.c:141:26: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front_kms.c:144:29: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front_kms.c:258:27: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front_kms.c:274:21: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front_kms.c: In function 'fb_destroy':
>> drivers/gpu/drm/xen/xen_drm_front_kms.c:40:6: error: implicit declaration of 
>> function 'drm_dev_enter'; did you mean 'drm_dev_unref'? 
>> [-Werror=implicit-function-declaration]
 if (drm_dev_enter(fb->dev, )) {
 ^
 drm_dev_unref
>> drivers/gpu/drm/xen/xen_drm_front_kms.c:43:3: error: implicit declaration of 
>> function 'drm_dev_exit'; did you mean 'drm_dev_init'? 
>> [-Werror=implicit-function-declaration]
  drm_dev_exit(idx);
  ^~~~
  drm_dev_init
   drivers/gpu/drm/xen/xen_drm_front_kms.c: At top level:
   drivers/gpu/drm/xen/xen_drm_front_kms.c:296:12: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 .enable = display_enable,
   ^~
   drivers/gpu/drm/xen/xen_drm_front_kms.c:296:12: note: (near initialization 
for 'display_funcs.enable')
   cc1: some warnings being treated as errors

sparse warnings: (new ones prefixed by >>)

   drivers/gpu/drm/xen/xen_drm_front.c:484:13: sparse: undefined identifier 
'drm_dev_enter'
   drivers/gpu/drm/xen/xen_drm_front.c:487:17: sparse: undefined identifier 
'drm_dev_exit'
>> drivers/gpu/drm/xen/xen_drm_front.c:484:26: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front.c:487:29: sparse: call with no type!
   drivers/gpu/drm/xen/xen_drm_front.c: In function 
'xen_drm_drv_free_object_unlocked':
   drivers/gpu/drm/xen/xen_drm_front.c:484:6: error: implicit declaration of 

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

[bugzilla-daemon]

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

--- Comment #21 from Reimar Imhof  ---
Btw.: There is a new bug showing up with a 4.16.0-rc7 kernel (I did not test
rc1 to rc6): The screen flickers. I can't tell you whats triggers such a
flicker but it does.
That bug is still around with the drm-next-4.17-wip kernel.

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

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

[bugzilla-daemon]

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

--- Comment #20 from Reimar Imhof  ---
I've tried drm-next-4.17-wip.
What I've seen is the same as described with the initial bug description:
When monitor is connected via hdmi I get wrong colors. This appears during boot
before the gui (x.org) gets started (frame buffer boot animation). Wrong colors
(sort of violet instead of black) also appear on frame buffer text console and
with x.org gui.
This bug appears with "amdgpu.dc=1" kernel parameter.
While running x.org I've turned the monitor off and on again. This gives
correct colors but the screen resolution goes to 1024x768. So it's no work
around.

What I've seen is: The colors are correct if I run the monitor with a yuv color
model instead of rgb.

One thing seems to be better: Every boot manged to get to the graphical login.
I've tried about 10 reboots.

-- 
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 3/3] drm/omap: remove unused function

[Emil Velikov]

On 29 March 2018 at 13:31, Sebastian Reichel
 wrote:
> Hi,
>
> On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
>> On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
>> > omap_framebuffer_get_next_connector() is not used, remove it.
>> >
>> Seems to have been unused for a few years now.
>> Namely since commit 5a35876e2830511cb8110667fc426c6a6165a593
>>
>> Reviewed-by: Emil Velikov 
>
> I have a pending patch using that function to basically restore the
> functionality from the referenced commit:
>
> https://patchwork.kernel.org/patch/10207759/
>
Hmm I can see very few users of dirtyfb - modesetting, opentegra,
vmgfx, intel (sna only)  + the odd IGT test.

Wondering if that's because it doesn't provide that much of a benefit...
Although it might be because DRM drivers don't fully implement the
functionality ;-)

Just thinking out loud ^^.

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

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Hello!

When using Xen PV DRM frontend driver then on backend side one will need
to do copying of display buffers' contents (filled by the
frontend's user-space) into buffers allocated at the backend side.
Taking into account the size of display buffers and frames per seconds
it may result in unneeded huge data bus occupation and performance loss.

This helper driver allows implementing zero-copying use-cases
when using Xen para-virtualized frontend display driver by
implementing a DRM/KMS helper driver running on backend's side.
It utilizes PRIME buffers API to share frontend's buffers with
physical device drivers on backend's side:

 - a dumb buffer created on backend's side can be shared
   with the Xen PV frontend driver, so it directly writes
   into backend's domain memory (into the buffer exported from
   DRM/KMS driver of a physical display device)
 - a dumb buffer allocated by the frontend can be imported
   into physical device DRM/KMS driver, thus allowing to
   achieve no copying as well

For that reason number of IOCTLs are introduced:
 -  DRM_XEN_ZCOPY_DUMB_FROM_REFS
This will create a DRM dumb buffer from grant references provided
by the frontend
 - DRM_XEN_ZCOPY_DUMB_TO_REFS
   This will grant references to a dumb/display buffer's memory provided
   by the backend
 - DRM_XEN_ZCOPY_DUMB_WAIT_FREE
   This will block until the dumb buffer with the wait handle provided
   be freed

With this helper driver I was able to drop CPU usage from 17% to 3%
on Renesas R-Car M3 board.

This was tested with Renesas' Wayland-KMS and backend running as DRM master.

Thank you,
Oleksandr

Oleksandr Andrushchenko (1):
  drm/xen-zcopy: Add Xen zero-copy helper DRM driver

 Documentation/gpu/drivers.rst   |   1 +
 Documentation/gpu/xen-zcopy.rst |  32 +
 drivers/gpu/drm/xen/Kconfig |  25 +
 drivers/gpu/drm/xen/Makefile|   5 +
 drivers/gpu/drm/xen/xen_drm_zcopy.c | 880 
 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.c | 154 +
 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.h |  38 ++
 include/uapi/drm/xen_zcopy_drm.h| 129 
 8 files changed, 1264 insertions(+)
 create mode 100644 Documentation/gpu/xen-zcopy.rst
 create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy.c
 create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.c
 create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.h
 create mode 100644 include/uapi/drm/xen_zcopy_drm.h

-- 
2.16.2

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

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Introduce Xen zero-copy helper DRM driver, add user-space API of the driver:
1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS
This will create a DRM dumb buffer from grant references provided
by the frontend. The intended usage is:
  - Frontend
- creates a dumb/display buffer and allocates memory
- grants foreign access to the buffer pages
- passes granted references to the backend
  - Backend
- issues DRM_XEN_ZCOPY_DUMB_FROM_REFS ioctl to map
  granted references and create a dumb buffer
- requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD
- requests real HW driver/consumer to import the PRIME buffer with
  DRM_IOCTL_PRIME_FD_TO_HANDLE
- uses handle returned by the real HW driver
  - at the end:
o closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE
o closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE
o closes file descriptor of the exported buffer

2. DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
This will grant references to a dumb/display buffer's memory provided by the
backend. The intended usage is:
  - Frontend
- requests backend to allocate dumb/display buffer and grant references
  to its pages
  - Backend
- requests real HW driver to create a dumb with DRM_IOCTL_MODE_CREATE_DUMB
- requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD
- requests zero-copy driver to import the PRIME buffer with
  DRM_IOCTL_PRIME_FD_TO_HANDLE
- issues DRM_XEN_ZCOPY_DUMB_TO_REFS ioctl to
  grant references to the buffer's memory.
- passes grant references to the frontend
 - at the end:
- closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE
- closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE
- closes file descriptor of the imported buffer

Implement GEM/IOCTL handling depending on driver mode of operation:
- if GEM is created from grant references, then prepare to create
  a dumb from mapped pages
- if GEM grant references are about to be provided for the
  imported PRIME buffer, then prepare for granting references
  and providing those to user-space

Implement handling of display buffers from backend to/from front
interaction point ov view:
- when importing a buffer from the frontend:
  - allocate/free xen ballooned pages via Xen balloon driver
or by manually allocating a DMA buffer
  - if DMA buffer is used, then increase/decrease its pages
reservation accordingly
  - map/unmap foreign pages to the ballooned pages
- when exporting a buffer to the frontend:
  - grant references for the pages of the imported PRIME buffer
  - pass the grants back to user-space, so those can be shared
with the frontend

Add an option to allocate DMA buffers as backing storage while
importing a frontend's buffer into host's memory:
for those use-cases when exported PRIME buffer will be used by
a device expecting CMA buffers only, it is possible to map
frontend's pages onto contiguous buffer, e.g. allocated via
DMA API.

Implement synchronous buffer deletion: for buffers, created from front's
grant references, synchronization between backend and frontend is needed
on buffer deletion as front expects us to unmap these references after
XENDISPL_OP_DBUF_DESTROY response.
For that reason introduce DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL:
this will block until dumb buffer, with the wait handle provided,
be freed.

The rationale behind implementing own wait handle:
  - dumb buffer handle cannot be used as when the PRIME buffer
gets exported there are at least 2 handles: one is for the
backend and another one for the importing application,
so when backend closes its handle and the other application still
holds the buffer then there is no way for the backend to tell
which buffer we want to wait for while calling xen_ioctl_wait_free
  - flink cannot be used as well as it is gone when DRM core
calls .gem_free_object_unlocked

Signed-off-by: Oleksandr Andrushchenko 
---
 Documentation/gpu/drivers.rst   |   1 +
 Documentation/gpu/xen-zcopy.rst |  32 +
 drivers/gpu/drm/xen/Kconfig |  25 +
 drivers/gpu/drm/xen/Makefile|   5 +
 drivers/gpu/drm/xen/xen_drm_zcopy.c | 880 
 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.c | 154 +
 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.h |  38 ++
 include/uapi/drm/xen_zcopy_drm.h| 129 
 8 files changed, 1264 insertions(+)
 create mode 100644 Documentation/gpu/xen-zcopy.rst
 create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy.c
 create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.c
 create mode 100644 drivers/gpu/drm/xen/xen_drm_zcopy_balloon.h
 create mode 100644 include/uapi/drm/xen_zcopy_drm.h

diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
index d3ab6abae838..900ff1c3d3f1 100644
--- a/Documentation/gpu/drivers.rst
+++ 

Re: [PATCH 2/3] drm/amdgpu: refresh per vm bo lru

[Chunming Zhou]

在 2018/3/29 16:59, Christian König 写道:

Am 29.03.2018 um 10:37 schrieb zhoucm1:




On 2018年03月28日 16:13, zhoucm1 wrote:




On 2018年03月27日 21:44, Christian König wrote:

How about we update the LRU only when we need to re-validate at 
least one BO?
I tried this just now, performance still isn't stable, sometime drop 
to 28fps by accident.


Can you give me the code for that? I probably can't work this week on 
that, but I can take a look next week.

just git send-mail to your amd mail.





I also tried to check num_evictions, if eviction happens, then 
update LRU, also sometime drop to 28fps by accident.


When BOs change, we not only need keep LRU order, but also 
validation order in vm->evicted list. Any other ideas which can keep 
these order but not increase submission overhead?


With more thinking, we need to add new LRU design for per vm bo, we 
need to make sure the order when adding to LRU. How about the below idea:
0. separate traditional bo list lru and per-vm-bo lru. Traditional 
lru keeps old way, per-vm-lru follows below design.

1. TTM bdev maintains a vm/process list.
2. Every vm_list node contains its own per-vm-bo LRU[priority]
3. To manage the vm_list lru in specific driver, we will need add 
callback for it.

4. We will add an order for every per-vm-bo in that vm/process.
5. To speed up per-vm-lru sort, we will introduce RB tree for it in 
callback. The RB tree key is order.


This way, we will be able to keep the per-vm-bo LRU order.

What do you think of it?


No, we need a single LRU for per VM and not per VM BOs to maintain 
eviction fairness, so we don't really win anything with that.
If following original LRU design, the bo should be moved to lru tail 
when bo is used, so that keep the last used bo is in lru tail.
All per vm BOs are used for every command submission, then after every 
CS, we should refresh the lru, that is required by original LRU design, 
but as your NAK on it, it will introduce much CPU overhead for CS, they 
are inconsistencies.


For per vm case, if we don't want to introduce extra overhead, the 
per-vm-bo order shoud fixed in lru to avoid refresh LRU for every CS.

so my thinking for lru is:
VM1-BO1>BO2--->BO3--->BOn--->VM2-BO1--->BO2--->BO3--->BOn--->VM3-BO...

Regards,
David


Regards,
Christian.



Regards,
David Zhou


Regards,
David Zhou


BTW: We can easily walk all BOs which belong to a VM, skipping over 
the few which aren't per VM BOs should be trivial.


Christian.

Am 27.03.2018 um 13:56 schrieb Zhou, David(ChunMing):

then how to keep unique lru order? any ideas?

To stable performance, we have to keep unique lru order, otherwise 
like the issue I look into, sometimes F1game is 40fps, sometimes 
28fps...even re-validate allowed domains BO.


The left root cause is the moved BOs are not same.

send from Smartisan Pro

Christian K鰊ig  于 2018年3月27日 
下午6:50写道：


NAK, we already tried that and it is really not a good idea 
because it

massively increases the per submission overhead.

Christian.

Am 27.03.2018 um 12:16 schrieb Chunming Zhou:
> Change-Id: Ibad84ed585b0746867a5f4cd1eadc2273e7cf596
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
>   3 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

> index 383bf2d31c92..414e61799236 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -919,6 +919,8 @@ static int amdgpu_bo_vm_update_pte(struct 
amdgpu_cs_parser *p)

>    }
>    }
>
> + amdgpu_vm_refresh_lru(adev, vm);
> +
>    return r;
>   }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

> index 5e35e23511cf..8ad2bb705765 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1902,6 +1902,21 @@ struct amdgpu_bo_va 
*amdgpu_vm_bo_add(struct amdgpu_device *adev,

>    return bo_va;
>   }
>
> +void amdgpu_vm_refresh_lru(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)

> +{
> + struct ttm_bo_global *glob = adev->mman.bdev.glob;
> + struct amdgpu_vm_bo_base *bo_base;
> +
> + spin_lock(>status_lock);
> + list_for_each_entry(bo_base, >vm_bo_list, vm_bo) {
> + spin_lock(>lru_lock);
> + ttm_bo_move_to_lru_tail(_base->bo->tbo);
> + if (bo_base->bo->shadow)
> + ttm_bo_move_to_lru_tail(_base->bo->shadow->tbo);
> + spin_unlock(>lru_lock);
> + }
> + spin_unlock(>status_lock);
> +}
>
>   /**
>    * amdgpu_vm_bo_insert_mapping - insert a new mapping
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h

> index 1886a561c84e..e01895581489 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> +++ 

Re: [PATCH 3/3] drm/omap: remove unused function

[Tomi Valkeinen]

On 29/03/18 15:31, Sebastian Reichel wrote:
> Hi,
> 
> On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote:
>> On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
>>> omap_framebuffer_get_next_connector() is not used, remove it.
>>>
>> Seems to have been unused for a few years now.
>> Namely since commit 5a35876e2830511cb8110667fc426c6a6165a593
>>
>> Reviewed-by: Emil Velikov 
> 
> I have a pending patch using that function to basically restore the
> functionality from the referenced commit:

Oh, ok. I'll drop this patch. These was a Klocwork warning for this
function, so the easiest fix was to remove it.

drivers/gpu/drm/omapdrm/omap_fb.c:326 INFINITE_LOOP.LOCAL (2:Error) Analyze
Infinite loop
  * omap_fb.c:326: Entering loop with precondition (from!=0) &&
(connector!=0) && from == connector
  * omap_fb.c:326: condition 0 is always false
  * omap_fb.c:326: condition 0 is always false
  * omap_fb.c:327: condition connector!=from is always false

 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 v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Peter Ujfalusi]

On 2018-03-29 13:18, Tomi Valkeinen wrote:
> On 22/03/18 15:42, Peter Ujfalusi wrote:
>> From: Tomi Valkeinen 
>>
>> Errata i878 says that MPU should not be used to access RAM and DMM at
>> the same time. As it's not possible to prevent MPU accessing RAM, we
>> need to access DMM via a proxy.
>>
>> This patch changes DMM driver to access DMM registers via sDMA. Instead
>> of doing a normal readl/writel call to read/write a register, we use
>> sDMA to copy 4 bytes from/to the DMM registers.
>>
>> This patch provides only a partial workaround for i878, as not only DMM
>> register reads/writes are affected, but also accesses to the DMM mapped
>> buffers (framebuffers, usually).
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   8 ++
>>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 153 
>> ++-
>>  2 files changed, 159 insertions(+), 2 deletions(-)
>>
> 
> 
>> +dmm->wa_dma_chan = dma_request_channel(mask, NULL, NULL);
>> +if (!dmm->wa_dma_chan) {
>> +dma_free_coherent(dmm->dev, 4, dmm->wa_dma_data, 
>> dmm->wa_dma_handle);
> 
> This and the other free below should use sizeof(u32) as the alloc does.
> And I guess device_prep_dma_memcpy() too. Perhaps a #define would be
> best here. DMM_REG_SIZE? I can do this change when applying, if you agree.

Oh, there were others, I have changed it for dma_alloc_coherent().
I'll wait for couple of days for other comments and will resend with a
#define

> 
>  Tomi
> 

- Péter

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 1/3] drm/omap: fix uninitialized ret variable

[Tomi Valkeinen]

On 29/03/18 13:58, Emil Velikov wrote:
> On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
>> audio_config function for both HDMI4 and HDMI5 return uninitialized
>> value as the error code if the display is not currently enabled. For
>> some reason this has not caused any issues.
>>
> Doubt many people try hdmi audio with disabled display ;-)

I think it can happen if the display is connected but blanked.

> Reviewed-by: Emil Velikov 

Thanks for the review!

 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] ALSA: hda - Silence PM ops build warning

[Takashi Iwai]

On Thu, 29 Mar 2018 13:46:26 +0200,
Lukas Wunner wrote:
> 
> The system sleep PM ops azx_suspend() and azx_resume() were previously
> called by vga_switcheroo, but commit 07f4f97d7b4b ("vga_switcheroo: Use
> device link for HDA controller") removed their invocation.
> 
> Unfortunately the commit neglected to update the #ifdef surrounding the
> two functions, so if CONFIG_PM_SLEEP is *not* enabled but all three of
> CONFIG_PM, CONFIG_VGA_SWITCHEROO and CONFIG_SND_HDA_CODEC_HDMI *are*
> enabled, the compiler now emits the following warning:
> 
> sound/pci/hda/hda_intel.c:1024:12: warning: 'azx_resume' defined but not used 
> [-Wunused-function]
>  static int azx_resume(struct device *dev)
> ^~
> sound/pci/hda/hda_intel.c:989:12: warning: 'azx_suspend' defined but not used 
> [-Wunused-function]
>  static int azx_suspend(struct device *dev)
> ^~~
> 
> Silence by updating the #ifdef.  Because the #ifdef block now uses the
> same condition as the one immediately succeeding it, the two blocks can
> be collapsed together, shaving off another two lines.
> 
> Fixes: 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
> Cc: Takashi Iwai 
> Reported-by: Arnd Bergmann 
> Signed-off-by: Lukas Wunner 

Reviewed-by: Takashi Iwai 

Can this go through drm(-misc) tree as the original commit stays?


thanks,

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

Re: [PATCH 10/15] v4l: vsp1: Move DRM pipeline output setup code to a function

[Kieran Bingham]

Hi Laurent,

Thank you for another patch :D

On 26/02/18 21:45, Laurent Pinchart wrote:
> In order to make the vsp1_du_setup_lif() easier to read, and for
> symmetry with the DRM pipeline input setup, move the pipeline output
> setup code to a separate function.
> 
> Signed-off-by: Laurent Pinchart 

Just an easy code move. And I agree it improves things.

Small question below, but otherwise:

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 107 
> +++--
>  1 file changed, 61 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 00ce99bd1605..1c8adda47440 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -276,6 +276,66 @@ static int vsp1_du_pipeline_setup_input(struct 
> vsp1_device *vsp1,
>   return 0;
>  }
>  
> +/* Setup the output side of the pipeline (WPF and LIF). */
> +static int vsp1_du_pipeline_setup_output(struct vsp1_device *vsp1,
> +  struct vsp1_pipeline *pipe)
> +{
> + struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
> + struct v4l2_subdev_format format = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,

Why do you initialise this .which here, but all the other member variables 
below.

Wouldn't it make more sense to group all of this initialisation together? or is
there a distinction in keeping the .which separate.

(Perhaps this is just a way to initialise the rest of the structure to 0,
without using the memset?)


> + };
> + int ret;
> +
> + format.pad = RWPF_PAD_SINK;
> + format.format.width = drm_pipe->width;
> + format.format.height = drm_pipe->height;
> + format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
> + format.format.field = V4L2_FIELD_NONE;
> +
> + ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
> +);
> + if (ret < 0)
> + return ret;
> +
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on WPF%u sink\n",
> + __func__, format.format.width, format.format.height,
> + format.format.code, pipe->output->entity.index);
> +
> + format.pad = RWPF_PAD_SOURCE;
> + ret = v4l2_subdev_call(>output->entity.subdev, pad, get_fmt, NULL,
> +);
> + if (ret < 0)
> + return ret;
> +
> + dev_dbg(vsp1->dev, "%s: got format %ux%u (%x) on WPF%u source\n",
> + __func__, format.format.width, format.format.height,
> + format.format.code, pipe->output->entity.index);
> +
> + format.pad = LIF_PAD_SINK;
> + ret = v4l2_subdev_call(>lif->subdev, pad, set_fmt, NULL,
> +);
> + if (ret < 0)
> + return ret;
> +
> + dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on LIF%u sink\n",
> + __func__, format.format.width, format.format.height,
> + format.format.code, pipe->lif->index);
> +
> + /*
> +  * Verify that the format at the output of the pipeline matches the
> +  * requested frame size and media bus code.
> +  */
> + if (format.format.width != drm_pipe->width ||
> + format.format.height != drm_pipe->height ||
> + format.format.code != MEDIA_BUS_FMT_ARGB_1X32) {
> + dev_dbg(vsp1->dev, "%s: format mismatch on LIF%u\n", __func__,
> + pipe->lif->index);
> + return -EPIPE;
> + }
> +
> + return 0;
> +}
> +
>  /* Configure all entities in the pipeline. */
>  static void vsp1_du_pipeline_configure(struct vsp1_pipeline *pipe)
>  {
> @@ -356,7 +416,6 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   struct vsp1_drm_pipeline *drm_pipe;
>   struct vsp1_pipeline *pipe;
>   struct vsp1_bru *bru;
> - struct v4l2_subdev_format format;
>   unsigned long flags;
>   unsigned int i;
>   int ret;
> @@ -417,54 +476,10 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
> pipe_index,
>   if (ret < 0)
>   return ret;
>  
> - memset(, 0, sizeof(format));
> - format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> - format.pad = RWPF_PAD_SINK;
> - format.format.width = cfg->width;
> - format.format.height = cfg->height;
> - format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
> - format.format.field = V4L2_FIELD_NONE;
> -
> - ret = v4l2_subdev_call(>output->entity.subdev, pad, set_fmt, NULL,
> -);
> + ret = vsp1_du_pipeline_setup_output(vsp1, pipe);
>   if (ret < 0)
>   return ret;
>  
> - dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on WPF%u sink\n",
> - __func__, format.format.width, format.format.height,
> - format.format.code, 

[PATCH] ALSA: hda - Silence PM ops build warning

[Lukas Wunner]

The system sleep PM ops azx_suspend() and azx_resume() were previously
called by vga_switcheroo, but commit 07f4f97d7b4b ("vga_switcheroo: Use
device link for HDA controller") removed their invocation.

Unfortunately the commit neglected to update the #ifdef surrounding the
two functions, so if CONFIG_PM_SLEEP is *not* enabled but all three of
CONFIG_PM, CONFIG_VGA_SWITCHEROO and CONFIG_SND_HDA_CODEC_HDMI *are*
enabled, the compiler now emits the following warning:

sound/pci/hda/hda_intel.c:1024:12: warning: 'azx_resume' defined but not used 
[-Wunused-function]
 static int azx_resume(struct device *dev)
^~
sound/pci/hda/hda_intel.c:989:12: warning: 'azx_suspend' defined but not used 
[-Wunused-function]
 static int azx_suspend(struct device *dev)
^~~

Silence by updating the #ifdef.  Because the #ifdef block now uses the
same condition as the one immediately succeeding it, the two blocks can
be collapsed together, shaving off another two lines.

Fixes: 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
Cc: Takashi Iwai 
Reported-by: Arnd Bergmann 
Signed-off-by: Lukas Wunner 
---
 sound/pci/hda/hda_intel.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index ec4e6b829ee2..d653c56e9141 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -982,7 +982,7 @@ static int param_set_xint(const char *val, const struct 
kernel_param *kp)
 #define azx_del_card_list(chip) /* NOP */
 #endif /* CONFIG_PM */
 
-#if defined(CONFIG_PM_SLEEP) || defined(SUPPORT_VGA_SWITCHEROO)
+#ifdef CONFIG_PM_SLEEP
 /*
  * power management
  */
@@ -1063,9 +1063,7 @@ static int azx_resume(struct device *dev)
trace_azx_resume(chip);
return 0;
 }
-#endif /* CONFIG_PM_SLEEP || SUPPORT_VGA_SWITCHEROO */
 
-#ifdef CONFIG_PM_SLEEP
 /* put codec down to D3 at hibernation for Intel SKL+;
  * otherwise BIOS may still access the codec and screw up the driver
  */
-- 
2.16.2

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

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Christian König]

Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe:


On 28/03/18 01:44 PM, Christian König wrote:

Well, isn't that exactly what dma_map_resource() is good for? As far as
I can see it makes sure IOMMU is aware of the access route and
translates a CPU address into a PCI Bus address.
I'm using that with the AMD IOMMU driver and at least there it works
perfectly fine.

Yes, it would be nice, but no arch has implemented this yet. We are just
lucky in the x86 case because that arch is simple and doesn't need to do
anything for P2P (partially due to the Bus and CPU addresses being the
same). But in the general case, you can't rely on it.


Well, that an arch hasn't implemented it doesn't mean that we don't have 
the right interface to do it.



Yeah, but not for ours. See if you want to do real peer 2 peer you need
to keep both the operation as well as the direction into account.

Not sure what you are saying here... I'm pretty sure we are doing "real"
peer 2 peer...


For example when you can do writes between A and B that doesn't mean
that writes between B and A work. And reads are generally less likely to
work than writes. etc...

If both devices are behind a switch then the PCI spec guarantees that A
can both read and write B and vice versa.

Sorry to say that, but I know a whole bunch of PCI devices which
horrible ignores that.

Can you elaborate? As far as the device is concerned it shouldn't know
whether a request comes from a peer or from the host. If it does do
crazy stuff like that it's well out of spec. It's up to the switch (or
root complex if good support exists) to route the request to the device
and it's the root complex that tends to be what drops the load requests
which causes the asymmetries.


Devices integrated in the CPU usually only "claim" to be PCIe devices. 
In reality their memory request path go directly through the integrated 
north bridge. The reason for this is simple better throughput/latency.


That is hidden from the software, for example the BIOS just allocates 
address space for the BARs as if it's a normal PCIe device.


The only crux is when you then do peer2peer your request simply go into 
nirvana and are not handled by anything because the BARs are only 
visible from the CPU side of the northbridge.


Regards,
Christian.



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


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

Re: [PATCH 12/15] v4l: vsp1: Generalize detection of entity removal from DRM pipeline

[Kieran Bingham]

Hi Laurent,

Thank you for the patch,

On 26/02/18 21:45, Laurent Pinchart wrote:
> When disabling a DRM plane, the corresponding RPF is only marked as
> removed from the pipeline in the atomic update handler, with the actual
> removal happening when configuring the pipeline at atomic commit time.
> This is required as the RPF has to be disabled in the hardware, which
> can't be done from the atomic update handler.
> 
> The current implementation is RPF-specific. Make it independent of the
> entity type by using the entity's pipe pointer to mark removal from the
> pipeline. This will allow using the mechanism to remove BRU instances.

Nice improvement ...

> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/media/platform/vsp1/vsp1_drm.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index d705a6e9fa1d..6c60b72b6f50 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -346,13 +346,12 @@ static void vsp1_du_pipeline_configure(struct 
> vsp1_pipeline *pipe)
>   dl = vsp1_dl_list_get(pipe->output->dlm);
>  
>   list_for_each_entry_safe(entity, next, >entities, list_pipe) {
> - /* Disconnect unused RPFs from the pipeline. */
> - if (entity->type == VSP1_ENTITY_RPF &&
> - !pipe->inputs[entity->index]) {
> + /* Disconnect unused entities from the pipeline. */
> + if (!entity->pipe) {
>   vsp1_dl_list_write(dl, entity->route->reg,
>  VI6_DPR_NODE_UNUSED);

I don't think it's a problem, as we don't unset the entity->pipe for arbitrary
entities, but what happens if we set an HGO/HGT entity to NULL (these currently
have 0 as the route->reg. This would risk writing VI6_DPR_NODE_UNUSED to the
VI6_CMD(0) register?

In fact any entity in the pipeline with a null pipe pointer could cause this...
so we'd best be sure that they are right. Otherwise this could cause some crazy
bugs manifesting with the hardware doing something unexpected.

Assuming that won't be a problem,

Reviewed-by: Kieran Bingham 

>  
> - entity->pipe = NULL;
> + entity->sink = NULL;
>   list_del(>list_pipe);
>  
>   continue;
> @@ -569,10 +568,11 @@ int vsp1_du_atomic_update(struct device *dev, unsigned 
> int pipe_index,
>   rpf_index);
>  
>   /*
> -  * Remove the RPF from the pipe's inputs. The atomic flush
> -  * handler will disable the input and remove the entity from the
> -  * pipe's entities list.
> +  * Remove the RPF from the pipeline's inputs. Keep it in the
> +  * pipeline's entity list to let vsp1_du_pipeline_configure()
> +  * remove it from the hardware pipeline.
>*/
> + rpf->entity.pipe = NULL;
>   drm_pipe->pipe.inputs[rpf_index] = NULL;
>   return 0;
>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christian König]

Am 29.03.2018 um 08:57 schrieb Daniel Vetter:

On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote:

Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.

Signed-off-by: Christian König 

Um strictly speaking they all should, but ttm never bothered to use the
real interfaces but just hacked around the provided sg list, grabbing the
underlying struct pages, then rebuilding the sg list again.


Actually that isn't correct. TTM converts them to a dma address array 
because drivers need it like this (at least nouveau, radeon and amdgpu).


I've fixed radeon and amdgpu to be able to deal without it and mailed 
with Ben about nouveau, but the outcome is they don't really know.


TTM itself doesn't have any need for the pages on imported BOs (you 
can't mmap them anyway), the real underlying problem is that sg tables 
doesn't provide what drivers need.


I think we could rather easily fix sg tables, but that is a totally 
separate task.



The entire point of using sg lists was exactly to allow this use case of
peer2peer dma (or well in general have special exporters which managed
memory/IO ranges not backed by struct page). So essentially you're having
a "I'm totally not broken flag" here.


No, independent of needed struct page pointers we need to note if the 
exporter can handle peer2peer stuff from the hardware side in general.


So what I've did is just to set peer2peer allowed on the importer 
because of the driver needs and clear it in the exporter if the hardware 
can't handle that.



I think a better approach would be if we add a requires_struct_page or so,
and annotate the current importers accordingly. Or we just fix them up (it
is all in shared ttm code after all, I think everyone else got this
right).


I would rather not bed on that.

Christian.


-Daniel


---
  drivers/dma-buf/dma-buf.c | 1 +
  include/linux/dma-buf.h   | 4 
  2 files changed, 5 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ffaa2f9a9c2c..f420225f93c6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -565,6 +565,7 @@ struct dma_buf_attachment *dma_buf_attach(const struct 
dma_buf_attach_info *info
  
  	attach->dev = info->dev;

attach->dmabuf = dmabuf;
+   attach->peer2peer = info->peer2peer;
attach->priv = info->priv;
attach->invalidate = info->invalidate;
  
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h

index 15dd8598bff1..1ef50bd9bc5b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -313,6 +313,7 @@ struct dma_buf {
   * @dmabuf: buffer for this attachment.
   * @dev: device attached to the buffer.
   * @node: list of dma_buf_attachment.
+ * @peer2peer: true if the importer can handle peer resources without pages.
   * @priv: exporter specific attachment data.
   *
   * This structure holds the attachment information between the dma_buf buffer
@@ -328,6 +329,7 @@ struct dma_buf_attachment {
struct dma_buf *dmabuf;
struct device *dev;
struct list_head node;
+   bool peer2peer;
void *priv;
  
  	/**

@@ -392,6 +394,7 @@ struct dma_buf_export_info {
   * @dmabuf:   the exported dma_buf
   * @dev:  the device which wants to import the attachment
   * @priv: private data of importer to this attachment
+ * @peer2peer: true if the importer can handle peer resources without pages
   * @invalidate:   callback to use for invalidating mappings
   *
   * This structure holds the information required to attach to a buffer. Used
@@ -401,6 +404,7 @@ struct dma_buf_attach_info {
struct dma_buf *dmabuf;
struct device *dev;
void *priv;
+   bool peer2peer;
void (*invalidate)(struct dma_buf_attachment *attach);
  };
  
--

2.14.1

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


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

Re: [PATCH] drm: Use srcu to protect drm_device.unplugged

[Oleksandr Andrushchenko]

On 03/28/2018 06:09 PM, Daniel Vetter wrote:

On Wed, Mar 28, 2018 at 10:38:35AM +0300, Oleksandr Andrushchenko wrote:

From: Noralf Trønnes 

Use srcu to protect drm_device.unplugged in a race free manner.
Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
sections preventing access to device resources that are not available
after the device is gone.

Suggested-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Andrushchenko 
Tested-by: Oleksandr Andrushchenko 
Cc: intel-...@lists.freedesktop.org

Reviewed-by: Daniel Vetter 

Oleksandr, please push to drm-misc-next once you have dim tools setup up
and everything.

Pushed to drm-misc-next


Thanks, Daniel

Thank you,
Oleksandr

---
  drivers/gpu/drm/drm_drv.c | 54 ++-
  include/drm/drm_device.h  |  9 +++-
  include/drm/drm_drv.h | 15 +
  3 files changed, 68 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a1b9338736e3..32a83b41ab61 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -32,6 +32,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -75,6 +76,8 @@ static bool drm_core_init_complete = false;
  
  static struct dentry *drm_debugfs_root;
  
+DEFINE_STATIC_SRCU(drm_unplug_srcu);

+
  /*
   * DRM Minors
   * A DRM device can provide several char-dev interfaces on the DRM-Major. Each
@@ -318,18 +321,51 @@ void drm_put_dev(struct drm_device *dev)
  }
  EXPORT_SYMBOL(drm_put_dev);
  
-static void drm_device_set_unplugged(struct drm_device *dev)

+/**
+ * drm_dev_enter - Enter device critical section
+ * @dev: DRM device
+ * @idx: Pointer to index that will be passed to the matching drm_dev_exit()
+ *
+ * This function marks and protects the beginning of a section that should not
+ * be entered after the device has been unplugged. The section end is marked
+ * with drm_dev_exit(). Calls to this function can be nested.
+ *
+ * Returns:
+ * True if it is OK to enter the section, false otherwise.
+ */
+bool drm_dev_enter(struct drm_device *dev, int *idx)
+{
+   *idx = srcu_read_lock(_unplug_srcu);
+
+   if (dev->unplugged) {
+   srcu_read_unlock(_unplug_srcu, *idx);
+   return false;
+   }
+
+   return true;
+}
+EXPORT_SYMBOL(drm_dev_enter);
+
+/**
+ * drm_dev_exit - Exit device critical section
+ * @idx: index returned from drm_dev_enter()
+ *
+ * This function marks the end of a section that should not be entered after
+ * the device has been unplugged.
+ */
+void drm_dev_exit(int idx)
  {
-   smp_wmb();
-   atomic_set(>unplugged, 1);
+   srcu_read_unlock(_unplug_srcu, idx);
  }
+EXPORT_SYMBOL(drm_dev_exit);
  
  /**

   * drm_dev_unplug - unplug a DRM device
   * @dev: DRM device
   *
   * This unplugs a hotpluggable DRM device, which makes it inaccessible to
- * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
+ * userspace operations. Entry-points can use drm_dev_enter() and
+ * drm_dev_exit() to protect device resources in a race free manner. This
   * essentially unregisters the device like drm_dev_unregister(), but can be
   * called while there are still open users of @dev.
   */
@@ -338,10 +374,18 @@ void drm_dev_unplug(struct drm_device *dev)
drm_dev_unregister(dev);
  
  	mutex_lock(_global_mutex);

-   drm_device_set_unplugged(dev);
if (dev->open_count == 0)
drm_dev_put(dev);
mutex_unlock(_global_mutex);
+
+   /*
+* After synchronizing any critical read section is guaranteed to see
+* the new value of ->unplugged, and any critical section which might
+* still have seen the old value of ->unplugged is guaranteed to have
+* finished.
+*/
+   dev->unplugged = true;
+   synchronize_srcu(_unplug_srcu);
  }
  EXPORT_SYMBOL(drm_dev_unplug);
  
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h

index 7c4fa32f3fc6..3a0eac2885b7 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -46,7 +46,14 @@ struct drm_device {
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
  
-	atomic_t unplugged;			/**< Flag whether dev is dead */

+   /**
+* @unplugged:
+*
+* Flag to tell if the device has been unplugged.
+* See drm_dev_enter() and drm_dev_is_unplugged().
+*/
+   bool unplugged;
+
struct inode *anon_inode;   /**< inode for private 
address-space */
char *unique;   /**< unique name of the device 
*/
/*@} */
diff --git a/include/drm/drm_drv.h 

Re: [PATCH 3/4] drm/virtio: remove drm_dev_set_unique workaround

[Laszlo Ersek]

On 03/28/18 16:35, Emil Velikov wrote:
> On 28 March 2018 at 11:27, Laszlo Ersek  wrote:
>> On 03/28/18 03:24, Emil Velikov wrote:

>>> Gents, can someone double-check this please? Just in case.
>>
>> I guess I should test whether this series regresses the use case
>> described in c2cbc38b97; is that correct?
>>
> Precisely.

> [3] https://github.com/evelikov/linux/commits/ioctl-cleanups

Unfortunately, this series seems to reintroduce the regression fixed /
described earlier in commit c2cbc38b97.

Here's what I did today:

(1) Used an up-to-date Fedora 27 VM (kernel 4.15.12-301.fc27.x86_64),
with a virtio-gpu display device in the VM config.

(2) Fetched your tree at [3].

(3) Seeded ".config" from Fedora's "config-4.15.12-301.fc27.x86_64" and
built the kernel with "make binrpm-pkg". This was at:

  v4.16-rc1-1531-gbefdaafe8b00

For all config related questions asked by "make", I just accepted
the defaults.

(4) Installed the RPM in the VM and booted it. X didn't come up. I
logged in via ssh and saved "dmesg" and "Xorg.0.log".

(5) Without touching .config, I checked out the "baseline" of your
series, namely:

  v4.16-rc1-1527-ga7d2a87e99de

Built the kernel again with "make binrpm-pkg".

(6) In the VM I uninstalled the kernel from (3) and installed the one
from (5). X came up successfully. I again saved "dmesg" and
"Xorg.0.log".

Now I don't know if the dri-devel mailing list strips attachments from
emails. I surely won't paste four large text files (without boundaries
between them) when what you'll likely want to do is diff them. So, I'm
pasting a base64 encoded tarball instead. :)

Let me know if I should collect other information or do some
experiments.

Thanks!
Laszlo

begin-base64 600 logs.tar.xz
/Td6WFoAAATm1rRGAgAhARwQz1jM4i//PhVdADYbyRqz2KlBYBTJ/g0t
Q3A+/ETYoq0jwt8UTrtA58EXKVDYNUxuCBO22RNo+XNXbyFs+Ko8t94M2j9r
ovHWn3vh+O6cc6ecJrY43dEgq4boLIhHWM8xJHOjVeSejscfChSubWX/OJic
oBA2a4g1QgZ6Um9AMvX3i8oLwkvoqO6RQKG0qHiJcsxGD1LbcPo//gzxJcrb
vzekMtNVXPi0QUVezU1qZNzGGruPUP1+gM+zIfGikVl2io4D9BOxELnIcsHH
CAjJhAkMqK5ZC+PNg58sgJ0rBeEqh6pvXnGzwClif7Y38aaxn2P27wc4KRBF
UIHJOsZwaBLif8hajshfq8WeBHyhUn9snbwtrMf5SET5XIlhAuLdAUBFGgk+
vtI0MNmfEaPPei/KPd4Ng8J+RnA3OCGpHRIDK8sVvzdbCfNNxDrlMuLs8zDP
oBd5vxYhDDrsASoTzaNz/Wjl0cLT8P/PB+8L6H8Jhl8KDw0SjfOZzuDgL0HI
/ibobxMMUCWnIRWpuVBsyKIecmA4azKdzHzdJt54x9nfAV++WYxR/3myeEo5
cae5hQ3VRyTwck1d0b7yYynKMdI6CfeFqQn1lXrcf4lPhFAixQRwySQuZFC4
+0+xaFEvB/pqXmL4fyPWOaAwVWx5x8Zy+D9CmjaDibPobIwz+Lyr3IEvGq4Z
XYALsg1uGnaQCbqbhsnNESMTv9wi/Alt/de7m0ZtkW5ql1B6JyumRCSEHTiF
q+Cb+4XnTb/UsWZ/HK7260Rear75rGUJDN1bCDRp9LR1ihumeELxPKc6u2ue
MlYeX0wNmePAJ4PTHRKpzyvPjJTpRix09d3/N+LcEAGOTgRAz2m8XgAP+x7Z
b+cKHT6dyouGgnyauMf7LcleMM3tsHQSiW8B33KbSlzNTW1j7usha8ECFmr/
DthFNOK9DfhnROST7Kt4wtw7K0LCXy81iAP1GQbFl7Vw7jRLAmXiE1ZVqK0i
6gipG+eOZ55EIIK2q6szy1tMwbGWilxqTTscVCU9gHe62LqMmAWQi8tNHEoy
mdtK0s8OSAAUJSVk/5a17pXVOMewlSFOc/ZU9OTNB1Mn5da7LP8NVRqNonfQ
yVeLmzluBko8DAZ8imupREimpgNpdVolw8J6651xpC0RcIbf5BdMGekPzfNf
EukgcovhJUhLyoUEkxPUTrJHoZP4RoG8EwEKiaCE82/1OxWSQu5rFAo+/LsF
hpCVJ95zgHiIZG94su9y3p44GQoOj1l1z3je8ycODWKb/mph5jFWBbTetNsJ
8RVElSUlr8V9SCjrEhAxawHMUUxgIyjXpPe7TS34vWNTYgVkLXJRsytRt+VJ
Z5VeyA8071UEItDRsrVgmEfuy+M3M1c3n4eEqGrrKWeW8Ozn+Mi+CvP2AMbc
4fn9llOyJy49lgyRhH7HEbGZQHsnBKDQem8tRf3hRCk/h561fVB0hmd9TP6L
AYzqHu/797KuZdHNrtnOuCVaoRUYiTb36+4elTGjeI9/ys5rpSENMpcVFdGv
WZ16AXBSlREp0HfYc4xEVTujBBiq8qlqNIzX6P6UxafGcapLLyGZEks1NaCn
Z2On6x00fIW5MTUNZKnBNDuAgMNDOLcaWXPRSpJqXPoGYtoLVn5+hrysKqng
1EXldvPi+KmDV/KqPrsdfvMZEn0/WCJzX/AwHaDBEQQXP2au+jLpVH3V1e/U
RQOrySdd6dKsUZ6yWaf9DEaGb0MEGjbaWSdnuje6DeTfJJOYTH+D9ime5FWq
X3+eLehNGteelHYpL5Ie3PM0iX2q27/xK8TOewAKqbu3vKsXCia11CvepvRH
S3tyUBW4lUEXujDwnN8z2KFkX3qncIUSDvmgq25FvgZZYbuEbt+z4CgM1I/9
m9p2LjghCwS/h5XOk3jeHIgDK+/humRnao+tcqIx0m9x2OhKp5GXBcJeBXsb
PxUCFuuirCB4co7Xe/qqjs77KFHvVau0pGWlyPgme+t3E18GqQPJCEd1rVYV
YaE3pLsOiK+eo5J3Rv1qg3+XEXmblCWd/4SbXIKtp+hxWfF6ferFqZnwfJI8
pjEy2SvawxDyO7Yd1r+ydrZd8zupC6aBCUROchRXNd7FiClYeovCTGCG7hcr
QS9LWkgyPEWwJLPPCc331DP5TzKmHCS0hQc8pOWzfyiUFUqLkpemt60fMAfJ
IeygRw/sHLMTQWD4nK6IHuticFLRtCTreYbT9ImrMnDVkoHSMfBmin3MBD6D
BEuiUQesCL2LZpgcI2FF+Jf+DZDlWK0D4J1BJVw9jkkzuVp6R9EZNJ8KEZYq
7TP27shVAKAA46U4rQ12K25JBP07uig5iASDML2yKH6poGbDKij5paGmOVcA
OFCqCnm8mYGAXoQgpIjL88/2xlQ0Yks6OA3YA1OywHksGR+XUkgJZx8RTxyc
fXGqWaTdt3UmTZw2ZfoiX5Y9q03TamgmoN8JDqu+CYq06tammM7bR35f9Lpq
fdcv6h1UhLlejrOq+vQ7J30rdnG78sM3oXab/SAEeY53v5By/L2PJfwy5cvm
aW2xOUimmAXVu5UuZxV+EymqINUvI9NO1Nf+W4uvABQhXlaalCqkB5xRAhHd
LBA1qOeUoYJxKim5GiGq9baYKTLsQLtX7LuQP3ArV2bAFx0ZSLBIdJffx+nI
MAip2T2S/F+CBN1V4UOnKwBiAq0IJfL9PGXZRRZlONtXYFx4SljXDmnm3YeE
MprfTHBrh7S/GOd5lJ8/DhtVamkoxr2tn2p2DzWvi8Guw/K5Lr6nQdlGs6Ok
SIuUKAuKkmqPnIxBzxU/qytZYiD7pLP/1njRk3pKiXSMVNAWsT7vGbqqdzKL
txy1NOwnyPZxSmOPYmpolwXsJzvTChm7A73ErKvG10FSABb/MY75CebuXGuE
nSa89DWYiopPcs9G6OL+E3gupSD5rUTXnaoGMzpF416cvclYJs7AcxlWqZ4u
vd9PNCZpxm5IK4uAzS2iwFGkmMLPbzECnpWFJK89twQTdzADLgIyI3LZYtdS
Nbhmd94NJD+/T+dcGtfsjEZ/eorac5gA2TkGydo7yUL3h1496slPyK0Ivrm2

Re: [PATCH 2/3] drm/omap: fix possible NULL ref issue in tiler_reserve_2d

[Emil Velikov]

On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
> tiler_reserve_2d allocates memory but does not check if it got the
> memory. Add the check and return ENOMEM on failure.
>
> Signed-off-by: Tomi Valkeinen 
It's funny when the function call (kzalloc here) is just outside the context ;-)

Reviewed-by: Emil Velikov 

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

Re: [PATCH 3/3] drm/omap: remove unused function

[Emil Velikov]

On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
> omap_framebuffer_get_next_connector() is not used, remove it.
>
Seems to have been unused for a few years now.
Namely since commit 5a35876e2830511cb8110667fc426c6a6165a593

Reviewed-by: Emil Velikov 

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

Re: [PATCH 1/3] drm/omap: fix uninitialized ret variable

[Emil Velikov]

On 29 March 2018 at 11:40, Tomi Valkeinen  wrote:
> audio_config function for both HDMI4 and HDMI5 return uninitialized
> value as the error code if the display is not currently enabled. For
> some reason this has not caused any issues.
>
Doubt many people try hdmi audio with disabled display ;-)

Reviewed-by: Emil Velikov 

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

[PATCH 1/3] drm/omap: fix uninitialized ret variable

[Tomi Valkeinen]

audio_config function for both HDMI4 and HDMI5 return uninitialized
value as the error code if the display is not currently enabled. For
some reason this has not caused any issues.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 2 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 97c88861d67a..5879f45f6fc9 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -679,7 +679,7 @@ static int hdmi_audio_config(struct device *dev,
 struct omap_dss_audio *dss_audio)
 {
struct omap_hdmi *hd = dev_get_drvdata(dev);
-   int ret;
+   int ret = 0;
 
mutex_lock(>lock);
 
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
index d28da9ac3e90..ae1a001d1b83 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5.c
@@ -671,7 +671,7 @@ static int hdmi_audio_config(struct device *dev,
 struct omap_dss_audio *dss_audio)
 {
struct omap_hdmi *hd = dev_get_drvdata(dev);
-   int ret;
+   int ret = 0;
 
mutex_lock(>lock);
 
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 2/3] drm/omap: fix possible NULL ref issue in tiler_reserve_2d

[Tomi Valkeinen]

tiler_reserve_2d allocates memory but does not check if it got the
memory. Add the check and return ENOMEM on failure.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c 
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index c40f90d2db82..28d93ece191e 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -532,6 +532,9 @@ struct tiler_block *tiler_reserve_2d(enum tiler_fmt fmt, 
u16 w,
unsigned long flags;
u32 slot_bytes;
 
+   if (!block)
+   return ERR_PTR(-ENOMEM);
+
BUG_ON(!validfmt(fmt));
 
/* convert width/height to slots */
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH 3/3] drm/omap: remove unused function

[Tomi Valkeinen]

omap_framebuffer_get_next_connector() is not used, remove it.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_fb.c | 27 ---
 drivers/gpu/drm/omapdrm/omap_fb.h |  2 --
 2 files changed, 29 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 5fd22ca73913..b54bcaad5cd1 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -309,33 +309,6 @@ void omap_framebuffer_unpin(struct drm_framebuffer *fb)
mutex_unlock(_fb->lock);
 }
 
-/* iterate thru all the connectors, returning ones that are attached
- * to the same fb..
- */
-struct drm_connector *omap_framebuffer_get_next_connector(
-   struct drm_framebuffer *fb, struct drm_connector *from)
-{
-   struct drm_device *dev = fb->dev;
-   struct list_head *connector_list = >mode_config.connector_list;
-   struct drm_connector *connector = from;
-
-   if (!from)
-   return list_first_entry_or_null(connector_list, typeof(*from),
-   head);
-
-   list_for_each_entry_from(connector, connector_list, head) {
-   if (connector != from) {
-   struct drm_encoder *encoder = connector->encoder;
-   struct drm_crtc *crtc = encoder ? encoder->crtc : NULL;
-   if (crtc && crtc->primary->fb == fb)
-   return connector;
-
-   }
-   }
-
-   return NULL;
-}
-
 #ifdef CONFIG_DEBUG_FS
 void omap_framebuffer_describe(struct drm_framebuffer *fb, struct seq_file *m)
 {
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.h 
b/drivers/gpu/drm/omapdrm/omap_fb.h
index 94ad5f9e4404..c20cb4bc714d 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.h
+++ b/drivers/gpu/drm/omapdrm/omap_fb.h
@@ -38,8 +38,6 @@ int omap_framebuffer_pin(struct drm_framebuffer *fb);
 void omap_framebuffer_unpin(struct drm_framebuffer *fb);
 void omap_framebuffer_update_scanout(struct drm_framebuffer *fb,
struct drm_plane_state *state, struct omap_overlay_info *info);
-struct drm_connector *omap_framebuffer_get_next_connector(
-   struct drm_framebuffer *fb, struct drm_connector *from);
 bool omap_framebuffer_supports_rotation(struct drm_framebuffer *fb);
 void omap_framebuffer_describe(struct drm_framebuffer *fb, struct seq_file *m);
 
-- 
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

[DPU PATCH v2 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845

[Sravanthi Kollukuduru]

Currently, the downstream driver depends on the DT file for the
hardware block offsets and other target specific catalog information.
To align the driver with the upstream DT design, this information is now
removed from the DT file and added in the driver source.

Change-Id: I63a366d7d7a26939ee1c20c702c7d4d976852067
Signed-off-by: Sravanthi Kollukuduru 
---
 .../devicetree/bindings/display/msm/dpu.txt| 530 -
 1 file changed, 530 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt 
b/Documentation/devicetree/bindings/display/msm/dpu.txt
index 136f0d3..90cd3e0 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/dpu.txt
@@ -19,61 +19,6 @@ Required properties
 - interrupt-controller: Mark the device node as an interrupt controller.
 - #interrupt-cells: Should be one. The first cell is interrupt number.
 - iommus: Specifies the SID's used by this context bank.
-- qcom,dpu-sspp-type:  Array of strings for DPU source surface pipes 
type information.
-   A source pipe can be "vig", "rgb", "dma" or 
"cursor" type.
-   Number of xin ids defined should match the 
number of offsets
-   defined in property: qcom,dpu-sspp-off.
-- qcom,dpu-sspp-off:   Array of offset for DPU source surface pipes. 
The offsets
-   are calculated from register "mdp_phys" defined 
in
-   reg property + "dpu-off". The number of offsets 
defined here should
-   reflect the amount of pipes that can be active 
in DPU for
-   this configuration.
-- qcom,dpu-sspp-xin-id:Array of VBIF clients ids (xins) 
corresponding
-   to the respective source pipes. Number of xin 
ids
-   defined should match the number of offsets
-   defined in property: qcom,dpu-sspp-off.
-- qcom,dpu-ctl-off:Array of offset addresses for the available ctl
-   hw blocks within DPU, these offsets are
-   calculated from register "mdp_phys" defined in
-   reg property.  The number of ctl offsets defined
-   here should reflect the number of control paths
-   that can be configured concurrently on DPU for
-   this configuration.
-- qcom,dpu-wb-off: Array of offset addresses for the programmable
-   writeback blocks within DPU.
-- qcom,dpu-wb-xin-id:  Array of VBIF clients ids (xins) corresponding
-   to the respective writeback. Number of xin ids
-   defined should match the number of offsets
-   defined in property: qcom,dpu-wb-off.
-- qcom,dpu-mixer-off:  Array of offset addresses for the available
-   mixer blocks that can drive data to panel
-   interfaces. These offsets are be calculated from
-   register "mdp_phys" defined in reg property.
-   The number of offsets defined should reflect the
-   amount of mixers that can drive data to a panel
-   interface.
-- qcom,dpu-dspp-top-off:   Offset address for the dspp top block.
-   The offset is calculated from register 
"mdp_phys"
-   defined in reg property.
-- qcom,dpu-dspp-off:   Array of offset addresses for the available dspp
-   blocks. These offsets are calculated from
-   register "mdp_phys" defined in reg property.
-- qcom,dpu-pp-off: Array of offset addresses for the available
-   pingpong blocks. These offsets are calculated
-   from register "mdp_phys" defined in reg 
property.
-- qcom,dpu-pp-slave:   Array of flags indicating whether each ping pong
-   block may be configured as a pp slave.
-- qcom,dpu-intf-off:   Array of offset addresses for the available DPU
-   interface blocks that can drive data to a
-   panel controller. The offsets are calculated
-   from "mdp_phys" defined in reg property. The 
number
-   of offsets defined should reflect the number of
-   programmable interface blocks available in 
hardware.
-- qcom,dpu-mixer-blend-op-off  Array of offset addresses for the available
- 

[DPU PATCH v2 0/2] Add hardware catalog information in driver source for SDM845

[Sravanthi Kollukuduru]

This patch series aims at adding the target specific hardware
catalog information in driver source.
As a result, the current logic of dt based parsing is removed.

The DT clean up patch corresponding to this driver change will
be posted separately.

[V2]
  * Addressed Rob Herring's comment to update the commit message.

  * Addressed Sean's comment to restructure the catalog data in
a way that different hardware versions can reuse.
- Removed the target specific catalog file and moved the
  initialization logic to the main catalog file.
  Updated the driver patch title to reflect the same.
- Added config handler structure to define the mapping between
  the hardware versions read from the register and the respective
  config init functions.
- Added new structures for various sub blocks of the dpu driver
  and also, for any common configuration shared by the different
  blocks.

Sravanthi Kollukuduru (2):
  dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845
  drm/msm: Add hardware catalog data in driver source for SDM845

 .../devicetree/bindings/display/msm/dpu.txt|  530 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |   17 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3542 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  124 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c|2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c  |2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  |   24 +-
 10 files changed, 636 insertions(+), 3617 deletions(-)

-- 
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: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

[Tomi Valkeinen]

On 22/03/18 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen 
> 
> Errata i878 says that MPU should not be used to access RAM and DMM at
> the same time. As it's not possible to prevent MPU accessing RAM, we
> need to access DMM via a proxy.
> 
> This patch changes DMM driver to access DMM registers via sDMA. Instead
> of doing a normal readl/writel call to read/write a register, we use
> sDMA to copy 4 bytes from/to the DMM registers.
> 
> This patch provides only a partial workaround for i878, as not only DMM
> register reads/writes are affected, but also accesses to the DMM mapped
> buffers (framebuffers, usually).
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_dmm_priv.h  |   8 ++
>  drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 153 
> ++-
>  2 files changed, 159 insertions(+), 2 deletions(-)
> 


> + dmm->wa_dma_chan = dma_request_channel(mask, NULL, NULL);
> + if (!dmm->wa_dma_chan) {
> + dma_free_coherent(dmm->dev, 4, dmm->wa_dma_data, 
> dmm->wa_dma_handle);

This and the other free below should use sizeof(u32) as the alloc does.
And I guess device_prep_dma_memcpy() too. Perhaps a #define would be
best here. DMM_REG_SIZE? I can do this change when applying, if you agree.

 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 v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Vladimir,

On Tue, Mar 27, 2018 at 02:03:25PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 03/27/2018 01:10 PM, jacopo mondi wrote:
> > Hi Vladimir,
> >
> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:
> >> Hi Jacopo,
> >>
> >> On 03/27/2018 11:57 AM, jacopo mondi wrote:
> >>> Hi Vladimir,
> >>>
> >>> On Tue, Mar 27, 2018 at 11:30:29AM +0300, Vladimir Zapolskiy wrote:
>  Hi Sergei,
> 
>  On 03/27/2018 11:27 AM, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 3/27/2018 10:33 AM, jacopo mondi wrote:
> > [...]
> >>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >>>
> >>> Signed-off-by: Jacopo Mondi 
> >>> Reviewed-by: Andrzej Hajda 
> >>> Reviewed-by: Niklas Söderlund 
> >>> 
> >>> ---
> >>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 
> >>> +++
> >>>   1 file changed, 66 insertions(+)
> >>>   create mode 100644
> >>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> new file mode 100644
> >>> index 000..8225c6a
> >>> --- /dev/null
> >>> +++
> >>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >>> @@ -0,0 +1,66 @@
> >>> +Thine Electronics THC63LVD1024 LVDS decoder
> >>> +---
> >>> +
> >>> +The THC63LVD1024 is a dual link LVDS receiver designed to 
> >>> convert LVDS
> >>> streams
> >>> +to parallel data outputs. The chip supports single/dual 
> >>> input/output modes,
> >>> +handling up to two two input LVDS stream and up to two digital 
> >>> CMOS/TTL
> >>> outputs.
> >>> +
> >>> +Single or dual operation modes, output data mapping and DDR 
> >>> output modes
> >>> are
> >>> +configured through input signals and the chip does not expose 
> >>> any control
> >>> bus.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Shall be "thine,thc63lvd1024"
> >>> +
> >>> +Optional properties:
> >>> +- vcc-supply: Power supply for TTL output and digital circuitry
> >>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> >>> +- lvcc-supply: Power supply for LVDS inputs
> >>> +- pvcc-supply: Power supply for PLL circuitry
> >> As explained in a comment to one of the previous versions of this 
> >> series, I'm
> >> tempted to make vcc-supply mandatory and drop the three other 
> >> power supplies
> >> for now, as I believe there's very little chance they will be 
> >> connected to
> >> separately controllable regulators (all supplies use the same 
> >> voltage). In the
> >> very unlikely event that this occurs in design we need to support 
> >> in the
> >> future, the cvcc, lvcc and pvcc supplies can be added later as 
> >> optional
> >> without breaking backward compatibility.
> > I'm okay with that.
> >
> >> Apart from that,
> >>
> >> Reviewed-by: Laurent Pinchart 
> >>
> >>> +- pdwn-gpios: Power down GPIO signal. Active low
> > powerdown-gpios is the semi-standard name.
> >
>  right, I've also noticed it. If possible please avoid shortenings in
>  property names.
> >>>
> >>> It is not shortening, it just follow pin name from decoder's 
> >>> datasheet.
> >>>
> 
> >>> +- oe-gpios: Output enable GPIO signal. Active high
> >>> +
>  And this one is also a not ever met property name, please consider to
>  rename it to 'enable-gpios', for instance display panels define it.
> >>>
> >>>
> >>> Again, it follows datasheet naming scheme. Has something changed in DT
> >>> conventions?
> >>
> >> Seconded. My understanding is that the property name should reflect
> >> what reported in the the chip manual. For THC63LVD1024 the enable and
> >> power down pins are named 'OE' and 'PDWN' respectively.
> >
> > But don't we need the vendor prefix in the prop names then, like
> > "renesas,oe-gpios" then?
> >
> 
>  Seconded, with a correction to "thine,oe-gpios".
> 
> >>>
> >>> mmm, okay then...
> >>>
> >>> A grep for that semi-standard properties names in Documentation/
> >>> returns only usage examples and no actual definitions, so I 

Re: [PATCH 4/5] drm/omapdrm: Fix mm_list locking

[Tomi Valkeinen]

On 27/03/18 11:23, Daniel Vetter wrote:
> - None of the list walkings where protected.
> 
> - Switch to a mutex since the list walking could potentially take a
>   very long time.
> 
> Only thing we need to be careful with here is that while we walk the
> list we cant unreference any gem objects, since the final unref would
> result in a recursive deadlock. But the only functions that walk the
> list is the device resume and debugfs dumping, so all safe.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_debugfs.c |  2 ++
>  drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.h |  2 +-
>  drivers/gpu/drm/omapdrm/omap_gem.c | 11 +++
>  4 files changed, 11 insertions(+), 6 deletions(-)

Thanks, I'll pick this to omapdrm branch.

 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] drm/omapdrm: Switch to gem_free_object_unlocked

[Tomi Valkeinen]

On 28/03/18 14:41, Daniel Vetter wrote:
> The only thing that omap_gem_free_object does that might need the
> magic protection of struct_mutex (of keeping all objects alive if that
> lock is held, even if the last reference is gone) is the mm_list
> manipulation.
> 
> But that is already protected by the separate omapdrm->list_lock,
> which means struct_mutex is an entirely internal lock for omapdrm.
> Everything else is just releasing resources, which is all protected
> already by the various subsystems and allocators.
> 
> To make this even more obvious we could do an
> s/dev->struct_mutex/omapdrm->gem_lock/ like I've done for udl. But
> since omapdrm is a lot bigger and a lot more active I'll refrain from
> that - this is better done by omapdrm developers at some suitable time
> in the future.
> 
> v2: Just auditing the code isn't enough, I actually have to remove
> the now wrong locking check in omap_gem_free_object ...
> 
> Signed-off-by: Daniel Vetter 
> Cc: Tomi Valkeinen 

This version works fine. I'll pick this to omapdrm branch. Thanks!

 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 v5 0/1] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

On 03/29/2018 12:22 PM, Oleksandr Andrushchenko wrote:

Changes since v4:

For your convenience I am attaching diff between v4..v5
diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst
index 8188e03c9d23..009d942386c5 100644
--- a/Documentation/gpu/xen-front.rst
+++ b/Documentation/gpu/xen-front.rst
@@ -1,6 +1,6 @@
-
-Xen para-virtualized frontend driver
-
+
+ drm/xen-front Xen para-virtualized frontend driver
+
 
 This frontend driver implements Xen para-virtualized display
 according to the display protocol described at
diff --git a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
index e521785fd22b..02b6f3d9fe4c 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
@@ -186,8 +186,10 @@ static int evtchnl_alloc(struct xen_drm_front_info *front_info, int index,
 sring, XEN_PAGE_SIZE);
 
 		ret = xenbus_grant_ring(xb_dev, sring, 1, );
-		if (ret < 0)
+		if (ret < 0) {
+			free_page(page);
 			goto fail;
+		}
 
 		handler = evtchnl_interrupt_ctrl;
 	} else {
@@ -195,8 +197,10 @@ static int evtchnl_alloc(struct xen_drm_front_info *front_info, int index,
 
 		ret = gnttab_grant_foreign_access(xb_dev->otherend_id,
 virt_to_gfn((void *)page), 0);
-		if (ret < 0)
+		if (ret < 0) {
+			free_page(page);
 			goto fail;
+		}
 
 		gref = ret;
 		handler = evtchnl_interrupt_evt;
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 545049dfaf0a..f3ef9dfb4dfb 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -107,12 +107,13 @@ static void send_pending_event(struct xen_drm_front_drm_pipeline *pipeline)
 }
 
 static void display_enable(struct drm_simple_display_pipe *pipe,
-		struct drm_crtc_state *crtc_state)
+		struct drm_crtc_state *crtc_state,
+		struct drm_plane_state *plane_state)
 {
 	struct xen_drm_front_drm_pipeline *pipeline =
 			to_xen_drm_pipeline(pipe);
 	struct drm_crtc *crtc = >crtc;
-	struct drm_framebuffer *fb = pipe->plane.state->fb;
+	struct drm_framebuffer *fb = plane_state->fb;
 	int ret, idx;
 
 	if (!drm_dev_enter(pipe->crtc.dev, ))
@@ -273,7 +274,7 @@ static void display_update(struct drm_simple_display_pipe *pipe,
 	drm_dev_exit(idx);
 }
 
-enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
+static enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
 		const struct drm_display_mode *mode)
 {
 	struct xen_drm_front_drm_pipeline *pipeline =
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 1/1] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].

Driver limitations:
 1. Only primary plane without additional properties is supported.
 2. Only one video mode supported which resolution is configured via XenStore.
 3. All CRTCs operate at fixed frequency of 60Hz.

1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.

2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
  - read connector(s) configuration
  - read buffer allocation mode (backend/frontend)

3. Handle Xen event channels:
  - create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
  - implement event channels interrupt handlers
  - create and destroy event channels with respect to Xen bus state

4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
  - handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
  page directory
  - allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
  - grant references to the required set of pages for the
shared buffer itself
  - implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)

5. Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:

- implement KMS part of the driver with the help of DRM
  simple pipepline helper which is possible due to the fact
  that the para-virtualized driver only supports a single
  (primary) plane:
  - initialize connectors according to XenStore configuration
  - handle frame done events from the backend
  - create and destroy frame buffers and propagate those
to the backend
  - propagate set/reset mode configuration to the backend on display
enable/disable callbacks
  - send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback

- implement virtual connector handling:
  - support only pixel formats suitable for single plane modes
  - make sure the connector is always connected
  - support a single video mode as per para-virtualized driver
configuration

6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment, namely
requirements dictated by the accompanying DRM/(v)GPU drivers running in both
host and guest environments, number of operating modes of para-virtualized
display driver are supported:
 - display buffers can be allocated by either frontend driver or backend
 - display buffers can be allocated to be contiguous in memory or not

Note! Frontend driver itself has no dependency on contiguous memory for
its operation.

6.1. Buffers allocated by the frontend driver.

The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.

6.1.1. Front driver configured to use GEM CMA helpers
 This use-case is useful when used with accompanying DRM/vGPU driver in
 guest domain which was designed to only work with contiguous buffers,
 e.g. DRM driver based on GEM CMA helpers: such drivers can only import
 contiguous PRIME buffers, thus requiring frontend driver to provide
 such. In order to implement this mode of operation para-virtualized
 frontend driver can be configured to use GEM CMA helpers.

6.1.2. Front driver doesn't use GEM CMA
 If accompanying drivers can cope with non-contiguous memory then, to
 lower pressure on CMA subsystem of the kernel, driver can allocate
 buffers from system memory.

Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.

6.2. Buffers allocated by the backend

This mode of operation is run-time configured via guest domain configuration
through XenStore entries.

For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
physically contiguous memory, this allows implementing zero-copying
use-cases.

Note, while using this scenario the following should be 

[PATCH v5 0/1] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

Hello!

Boris/Daniel, I put your R-b tags, so please do let me know if this is not
acceptable, so I remove the tags.

This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif.h [2].
Accompanying backend [3] is implemented as a user-space application
and its helper library [4], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via 
Xen guest domain configuration options [5].

***
* Driver limitations
***
 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend
allocated buffers) below are not supported at the same time.

 2. Only primary plane without additional properties is supported.

 3. Only one video mode supported which resolution is configured via XenStore.

 4. All CRTCs operate at fixed frequency of 60Hz.

***
* Driver modes of operation in terms of display buffers used
***
 Depending on the requirements for the para-virtualized environment, namely
 requirements dictated by the accompanying DRM/(v)GPU drivers running in both
 host and guest environments, number of operating modes of para-virtualized
 display driver are supported:
  - display buffers can be allocated by either frontend driver or backend
  - display buffers can be allocated to be contiguous in memory or not

 Note! Frontend driver itself has no dependency on contiguous memory for
   its operation.

***
* 1. Buffers allocated by the frontend driver.
***

 The below modes of operation are configured at compile-time via
 frontend driver's kernel configuration.

 1.1. Front driver configured to use GEM CMA helpers
  This use-case is useful when used with accompanying DRM/vGPU driver in
  guest domain which was designed to only work with contiguous buffers,
  e.g. DRM driver based on GEM CMA helpers: such drivers can only import
  contiguous PRIME buffers, thus requiring frontend driver to provide
  such. In order to implement this mode of operation para-virtualized
  frontend driver can be configured to use GEM CMA helpers.

 1.2. Front driver doesn't use GEM CMA
  If accompanying drivers can cope with non-contiguous memory then, to
  lower pressure on CMA subsystem of the kernel, driver can allocate
  buffers from system memory.

 Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
   may require IOMMU support on the platform, so accompanying DRM/vGPU
   hardware can still reach display buffer memory while importing PRIME
   buffers from the frontend driver.

***
* 2. Buffers allocated by the backend
***

 This mode of operation is run-time configured via guest domain configuration
 through XenStore entries.

 For systems which do not provide IOMMU support, but having specific
 requirements for display buffers it is possible to allocate such buffers
 at backend side and share those with the frontend.
 For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
 physically contiguous memory, this allows implementing zero-copying
 use-cases.


I would like to thank at least, but not at last the following
people/communities who helped this driver to happen ;)

1. My team at EPAM for continuous support
2. Xen community for answering tons of questions on different
modes of operation of the driver with respect to virtualized
environment.
3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6]
4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7]
5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8]

Changes since v4:
***
- updated the driver after "drm/simple-kms-helper: Plumb plane state
  to the enable hook" [14]
- made display_mode_valid static
- fixed page leak on event channel error path
- changed title of the documentation to match the rest of the drivers
- removed from the series the patch from Noralf Trønnes [12] as it was sent out
  as a standalone one

Changes since v3:
***
- no changes to Xen related code (shared buffer handling, event channels etc.),
  but minor changes to xenbus_driver state machine due to re-worked unplug
  

Re: [PATCH 2/3] drm/amdgpu: refresh per vm bo lru

[Christian König]

Am 29.03.2018 um 10:37 schrieb zhoucm1:




On 2018年03月28日 16:13, zhoucm1 wrote:




On 2018年03月27日 21:44, Christian König wrote:

How about we update the LRU only when we need to re-validate at 
least one BO?
I tried this just now, performance still isn't stable, sometime drop 
to 28fps by accident.


Can you give me the code for that? I probably can't work this week on 
that, but I can take a look next week.




I also tried to check num_evictions, if eviction happens, then update 
LRU, also sometime drop to 28fps by accident.


When BOs change, we not only need keep LRU order, but also validation 
order in vm->evicted list. Any other ideas which can keep these order 
but not increase submission overhead?


With more thinking, we need to add new LRU design for per vm bo, we 
need to make sure the order when adding to LRU. How about the below idea:
0. separate traditional bo list lru and per-vm-bo lru. Traditional lru 
keeps old way, per-vm-lru follows below design.

1. TTM bdev maintains a vm/process list.
2. Every vm_list node contains its own per-vm-bo LRU[priority]
3. To manage the vm_list lru in specific driver, we will need add 
callback for it.

4. We will add an order for every per-vm-bo in that vm/process.
5. To speed up per-vm-lru sort, we will introduce RB tree for it in 
callback. The RB tree key is order.


This way, we will be able to keep the per-vm-bo LRU order.

What do you think of it?


No, we need a single LRU for per VM and not per VM BOs to maintain 
eviction fairness, so we don't really win anything with that.


Regards,
Christian.



Regards,
David Zhou


Regards,
David Zhou


BTW: We can easily walk all BOs which belong to a VM, skipping over 
the few which aren't per VM BOs should be trivial.


Christian.

Am 27.03.2018 um 13:56 schrieb Zhou, David(ChunMing):

then how to keep unique lru order? any ideas?

To stable performance, we have to keep unique lru order, otherwise 
like the issue I look into, sometimes F1game is 40fps, sometimes 
28fps...even re-validate allowed domains BO.


The left root cause is the moved BOs are not same.

send from Smartisan Pro

Christian K鰊ig  于 2018年3月27日 
下午6:50写道：


NAK, we already tried that and it is really not a good idea because it
massively increases the per submission overhead.

Christian.

Am 27.03.2018 um 12:16 schrieb Chunming Zhou:
> Change-Id: Ibad84ed585b0746867a5f4cd1eadc2273e7cf596
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
>   3 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

> index 383bf2d31c92..414e61799236 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -919,6 +919,8 @@ static int amdgpu_bo_vm_update_pte(struct 
amdgpu_cs_parser *p)

>    }
>    }
>
> + amdgpu_vm_refresh_lru(adev, vm);
> +
>    return r;
>   }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

> index 5e35e23511cf..8ad2bb705765 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1902,6 +1902,21 @@ struct amdgpu_bo_va 
*amdgpu_vm_bo_add(struct amdgpu_device *adev,

>    return bo_va;
>   }
>
> +void amdgpu_vm_refresh_lru(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)

> +{
> + struct ttm_bo_global *glob = adev->mman.bdev.glob;
> + struct amdgpu_vm_bo_base *bo_base;
> +
> + spin_lock(>status_lock);
> + list_for_each_entry(bo_base, >vm_bo_list, vm_bo) {
> + spin_lock(>lru_lock);
> + ttm_bo_move_to_lru_tail(_base->bo->tbo);
> + if (bo_base->bo->shadow)
> + ttm_bo_move_to_lru_tail(_base->bo->shadow->tbo);
> + spin_unlock(>lru_lock);
> + }
> + spin_unlock(>status_lock);
> +}
>
>   /**
>    * amdgpu_vm_bo_insert_mapping - insert a new mapping
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h

> index 1886a561c84e..e01895581489 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> @@ -285,6 +285,7 @@ int amdgpu_vm_clear_freed(struct 
amdgpu_device *adev,

>  struct dma_fence **fence);
>   int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
>   struct amdgpu_vm *vm);
> +void amdgpu_vm_refresh_lru(struct amdgpu_device *adev, struct 
amdgpu_vm *vm);

>   int amdgpu_vm_bo_update(struct amdgpu_device *adev,
>    struct amdgpu_bo_va *bo_va,
>    bool clear);









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

Re: [PATCH 05/10] drm/sun4i: Explicitly list and check formats supported by the frontend

[Maxime Ripard]

On Tue, Mar 27, 2018 at 10:24:17AM +0200, Paul Kocialkowski wrote:
> Hi,
> 
> On Fri, 2018-03-23 at 11:06 +0100, Maxime Ripard wrote:
> > On Wed, Mar 21, 2018 at 04:28:59PM +0100, Paul Kocialkowski wrote:
> > > In order to check whether the frontend supports a specific format,
> > > an
> > > explicit list and a related helper are introduced.
> > > 
> > > They are then used to determine whether the frontend can actually
> > > support
> > > the requested format when it was selected to be used.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  drivers/gpu/drm/sun4i/sun4i_backend.c  |  5 
> > >  drivers/gpu/drm/sun4i/sun4i_frontend.c | 44
> > > ++
> > >  drivers/gpu/drm/sun4i/sun4i_frontend.h |  1 +
> > >  3 files changed, 50 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > index 7703ba989743..1fad0714c70e 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > @@ -532,6 +532,11 @@ static int sun4i_backend_atomic_check(struct
> > > sunxi_engine *engine,
> > >   struct drm_format_name_buf format_name;
> > >  
> > >   if (sun4i_backend_plane_uses_frontend(plane_state))
> > > {
> > > + if (!sun4i_frontend_format_is_supported(fb-
> > > >format->format)) {
> > > + DRM_DEBUG_DRIVER("Frontend plane
> > > check failed\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > 
> > So you're checking if the frontend doesn't support it and if the
> > backend doesn't support it. Who supports it then? :)
> 
> That's the case case where the format is not supported by either of the
> hardware blocks. For instance, requesting ARGB with tiling will fail,
> although ARGB without tiling will work. It seems that modetest assumes
> that modifiers only apply to YUV (in which case there are no unsupported
> cases), but I think userspace might still request RGB+tiling
> combinations. I don't currently see a way to report to which format the
> tiling applies (thus we have to expect that it can come with any of the
> supported formats).

Then I guess this is a check that could be moved out of that
condition, or even as part of the generic side of atomic_check. That
looks not really specific to the driver itself.

> > Like I was saying, this should be moved to the previous patch, within
> > sun4i_backend_plane_uses_frontend.
> 
> If we get both tests (no backend support and frontend support) into one
> function, we cannot detect that the format is actually unsupported and
> return an error in the atomic check.

This is already covered by drm_atomic_plane_check:
https://elixir.bootlin.com/linux/v4.16-rc7/source/drivers/gpu/drm/drm_atomic.c#L884

So we'll only end up being called here if we have a format we support.

> > > +static const uint32_t sun4i_frontend_formats[] = {
> > > + /* RGB */
> > > + DRM_FORMAT_XRGB,
> > > + DRM_FORMAT_BGRX,
> > > + /* YUV444 */
> > > + DRM_FORMAT_YUV444,
> > > + DRM_FORMAT_YVU444,
> > > + /* YUV422 */
> > > + DRM_FORMAT_YUYV,
> > > + DRM_FORMAT_YVYU,
> > > + DRM_FORMAT_UYVY,
> > > + DRM_FORMAT_VYUY,
> > > + DRM_FORMAT_NV16,
> > > + DRM_FORMAT_NV61,
> > > + DRM_FORMAT_YUV422,
> > > + DRM_FORMAT_YVU422,
> > > + /* YUV420 */
> > > + DRM_FORMAT_NV12,
> > > + DRM_FORMAT_NV21,
> > > + DRM_FORMAT_YUV420,
> > > + DRM_FORMAT_YVU420,
> > > + /* YUV411 */
> > > + DRM_FORMAT_YUV411,
> > > + DRM_FORMAT_YVU411,
> > > +};
> > 
> > I think this list should reflect what the driver currently supports,
> > not what the hardware supports.
> 
> This list is not indended to reflect what the driver supports, but only
> what the backend can support (to correctly select whether a
> format/modifier couple should go to the frontend or backend)!

I know, and it's not my point. The whole point is that you don't need
that full list in the first place to achieve what you want to achieve
with this patch.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

[Bug 105680] [CI] igt@kms_frontbuffer_tracking@* - fail - FBC disabled: mode too large for compression

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |IGT

--- Comment #2 from Marta Löfstedt  ---
changing component to IGT, although this need update in intel CI system HW.

-- 
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/3] drm/amdgpu: refresh per vm bo lru

[zhoucm1]

On 2018年03月28日 16:13, zhoucm1 wrote:




On 2018年03月27日 21:44, Christian König wrote:

How about we update the LRU only when we need to re-validate at least 
one BO?
I tried this just now, performance still isn't stable, sometime drop 
to 28fps by accident.


I also tried to check num_evictions, if eviction happens, then update 
LRU, also sometime drop to 28fps by accident.


When BOs change, we not only need keep LRU order, but also validation 
order in vm->evicted list. Any other ideas which can keep these order 
but not increase submission overhead?


With more thinking, we need to add new LRU design for per vm bo, we need 
to make sure the order when adding to LRU. How about the below idea:
0. separate traditional bo list lru and per-vm-bo lru. Traditional lru 
keeps old way, per-vm-lru follows below design.

1. TTM bdev maintains a vm/process list.
2. Every vm_list node contains its own per-vm-bo LRU[priority]
3. To manage the vm_list lru in specific driver, we will need add 
callback for it.

4. We will add an order for every per-vm-bo in that vm/process.
5. To speed up per-vm-lru sort, we will introduce RB tree for it in 
callback. The RB tree key is order.


This way, we will be able to keep the per-vm-bo LRU order.

What do you think of it?

Regards,
David Zhou


Regards,
David Zhou


BTW: We can easily walk all BOs which belong to a VM, skipping over 
the few which aren't per VM BOs should be trivial.


Christian.

Am 27.03.2018 um 13:56 schrieb Zhou, David(ChunMing):

then how to keep unique lru order? any ideas?

To stable performance, we have to keep unique lru order, otherwise 
like the issue I look into, sometimes F1game is 40fps, sometimes 
28fps...even re-validate allowed domains BO.


The left root cause is the moved BOs are not same.

send from Smartisan Pro

Christian K鰊ig  于 2018年3月27日 
下午6:50写道：


NAK, we already tried that and it is really not a good idea because it
massively increases the per submission overhead.

Christian.

Am 27.03.2018 um 12:16 schrieb Chunming Zhou:
> Change-Id: Ibad84ed585b0746867a5f4cd1eadc2273e7cf596
> Signed-off-by: Chunming Zhou 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 15 +++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
>   3 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c

> index 383bf2d31c92..414e61799236 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -919,6 +919,8 @@ static int amdgpu_bo_vm_update_pte(struct 
amdgpu_cs_parser *p)

>    }
>    }
>
> + amdgpu_vm_refresh_lru(adev, vm);
> +
>    return r;
>   }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

> index 5e35e23511cf..8ad2bb705765 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1902,6 +1902,21 @@ struct amdgpu_bo_va 
*amdgpu_vm_bo_add(struct amdgpu_device *adev,

>    return bo_va;
>   }
>
> +void amdgpu_vm_refresh_lru(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)

> +{
> + struct ttm_bo_global *glob = adev->mman.bdev.glob;
> + struct amdgpu_vm_bo_base *bo_base;
> +
> + spin_lock(>status_lock);
> + list_for_each_entry(bo_base, >vm_bo_list, vm_bo) {
> + spin_lock(>lru_lock);
> + ttm_bo_move_to_lru_tail(_base->bo->tbo);
> + if (bo_base->bo->shadow)
> + ttm_bo_move_to_lru_tail(_base->bo->shadow->tbo);
> + spin_unlock(>lru_lock);
> + }
> + spin_unlock(>status_lock);
> +}
>
>   /**
>    * amdgpu_vm_bo_insert_mapping - insert a new mapping
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h

> index 1886a561c84e..e01895581489 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> @@ -285,6 +285,7 @@ int amdgpu_vm_clear_freed(struct amdgpu_device 
*adev,

>  struct dma_fence **fence);
>   int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
>   struct amdgpu_vm *vm);
> +void amdgpu_vm_refresh_lru(struct amdgpu_device *adev, struct 
amdgpu_vm *vm);

>   int amdgpu_vm_bo_update(struct amdgpu_device *adev,
>    struct amdgpu_bo_va *bo_va,
>    bool clear);







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

Re: [PATCH 04/10] drm/sun4i: Explicitly list and check formats supported by the backend

[Maxime Ripard]

On Tue, Mar 27, 2018 at 10:08:48AM +0200, Paul Kocialkowski wrote:
> On Fri, 2018-03-23 at 11:03 +0100, Maxime Ripard wrote:
> > On Wed, Mar 21, 2018 at 04:28:58PM +0100, Paul Kocialkowski wrote:
> > > In order to check whether the backend supports a specific format, an
> > > explicit list and a related helper are introduced.
> > > 
> > > They are then used to determine whether the frontend should be used
> > > for
> > > a layer, when the format is not supported by the backend.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  drivers/gpu/drm/sun4i/sun4i_backend.c | 48
> > > ++-
> > >  drivers/gpu/drm/sun4i/sun4i_backend.h |  1 +
> > >  2 files changed, 48 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > index 274a1db6fa8e..7703ba989743 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> > > @@ -172,6 +172,39 @@ static int
> > > sun4i_backend_drm_format_to_layer(u32 format, u32 *mode)
> > >   return 0;
> > >  }
> > >  
> > > +static const uint32_t sun4i_backend_formats[] = {
> > > + /* RGB */
> > > + DRM_FORMAT_ARGB,
> > > + DRM_FORMAT_RGBA,
> > > + DRM_FORMAT_ARGB1555,
> > > + DRM_FORMAT_RGBA5551,
> > > + DRM_FORMAT_RGB565,
> > > + DRM_FORMAT_RGB888,
> > > + DRM_FORMAT_XRGB,
> > > + DRM_FORMAT_BGRX,
> > > + DRM_FORMAT_ARGB,
> > > + /* YUV422 */
> > > + DRM_FORMAT_YUYV,
> > > + DRM_FORMAT_YVYU,
> > > + DRM_FORMAT_UYVY,
> > > + DRM_FORMAT_VYUY,
> > 
> > Ordering them by alphabetical order would be better.
> 
> Frankly I find it a lot harder to read when the formats are not grouped
> by "family". This is the drm_fourcc enumeration order, which has some
> kind of logic behind it. What is the advantage of alphabetical ordering
> here?

It's self-sufficient and self-explanatory. The sorting here, while it
would make sense lack both: you need to refer to the drm_fourcc.h file
to get the sorting right (which makes it harder to edit and review,
and thus more error prone), and it assumes that the editor knows about
that sorting in the first place.

And it's an assumption we can't really make, since some people will
edit that structure in the first place without any background at all
with DRM, or even graphics in general.

While the assumption you have to make for the alphabetical order is
that one knows the latin alphabet, which is a pretty obvious one when
you're doing C programming.

> > > +  */
> > > + if (!sun4i_backend_format_is_supported(fb->format->format))
> > > + return true;
> > 
> > Even though there's a comment, this is not really natural. We are
> > checking whether the frontend supports the current plane_state, so it
> > just makes more sense to check whether the frontend supports the
> > format, rather than if the backend doesn't support them.
> 
> The rationale behind this logic is that we should try to use the backend
> first and only use the frontend as a last resort. Some formats are
> supported by both and checking that the backend supports a format first
> ensures that we don't bring up the frontend without need.

You can achieve pretty much the same thing by doing:

if (!sun4i_frontend_format_is_supported())
return false;

if (!using_scaling)
return false;

if (using_2x_or_4x_scaling)
return false;

return true;

This is really about whitelisting vs blacklisting, so I'm not sure
what that would really change in the case you described above.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH v4 2/2] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

On 03/29/2018 10:17 AM, Daniel Vetter wrote:

On Wed, Mar 28, 2018 at 01:29:46PM +0300, Oleksandr Andrushchenko wrote:

Hi, Daniel!

I just noticed I have missed one change in the patch:
the below must be static.

On 03/28/2018 10:42 AM, Daniel Vetter wrote:

+enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
+   const struct drm_display_mode *mode)
+{
+   struct xen_drm_front_drm_pipeline *pipeline =
+   container_of(crtc,

Could you please amend the patch in attachment
when merging, so I don't resend?

Merging is up to you, as soon as you have your commit rights.

Thank you, meanwhile I'll need to rebase onto the latest drm-tip
fixing 2 more minor issues (attached) and making the driver work after
the API change [1]. So, I'll post v4 right after fd.o is back online
with the v3..v4 diff to make review simpler

-Daniel

Thank you,
Oleksandr

Thank you in advance,
Oleksandr
 From 3a82d76bd3d954056b760e5d1d09e2f96a2786ef Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko 
Date: Wed, 28 Mar 2018 13:24:04 +0300
Subject: [PATCH] drm/xen-front: Make display_mode_valid static

Signed-off-by: Oleksandr Andrushchenko 
---
  drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c 
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 545049dfaf0a..bd676be5a0db 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -273,7 +273,7 @@ static void display_update(struct drm_simple_display_pipe 
*pipe,
drm_dev_exit(idx);
  }
  
-enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,

+static enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
const struct drm_display_mode *mode)
  {
struct xen_drm_front_drm_pipeline *pipeline =
--
2.7.4

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


[1] 
https://github.com/freedesktop/drm-misc/commit/0c9c7fd00e17907efb35697ecb9f2df39a0b536c
>From e16847ef23d19106c6855951674624bfd37e4209 Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko 
Date: Thu, 29 Mar 2018 08:54:25 +0300
Subject: [PATCH 1/2] drm/xen-front: Free page on event channel error path

While creating an event channel a page was leaked in case
of error. Fix this by freeing the page.

Signed-off-by: Oleksandr Andrushchenko 
---
 drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
index e521785fd22b..02b6f3d9fe4c 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_evtchnl.c
@@ -186,8 +186,10 @@ static int evtchnl_alloc(struct xen_drm_front_info *front_info, int index,
 sring, XEN_PAGE_SIZE);
 
 		ret = xenbus_grant_ring(xb_dev, sring, 1, );
-		if (ret < 0)
+		if (ret < 0) {
+			free_page(page);
 			goto fail;
+		}
 
 		handler = evtchnl_interrupt_ctrl;
 	} else {
@@ -195,8 +197,10 @@ static int evtchnl_alloc(struct xen_drm_front_info *front_info, int index,
 
 		ret = gnttab_grant_foreign_access(xb_dev->otherend_id,
 virt_to_gfn((void *)page), 0);
-		if (ret < 0)
+		if (ret < 0) {
+			free_page(page);
 			goto fail;
+		}
 
 		gref = ret;
 		handler = evtchnl_interrupt_evt;
-- 
2.7.4

>From a6668b48003b46cd711f7e56faaf35dbad769c03 Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko 
Date: Thu, 29 Mar 2018 09:13:11 +0300
Subject: [PATCH 2/2] drm/xen-front: Align documentation title w/ other drivers

Align title of the documentation for the driver with the rest of the drivers,
e.g. have drm/xen-front in front of the title.

Signed-off-by: Oleksandr Andrushchenko 
---
 Documentation/gpu/xen-front.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/gpu/xen-front.rst b/Documentation/gpu/xen-front.rst
index 8188e03c9d23..009d942386c5 100644
--- a/Documentation/gpu/xen-front.rst
+++ b/Documentation/gpu/xen-front.rst
@@ -1,6 +1,6 @@
-
-Xen para-virtualized frontend driver
-
+
+ drm/xen-front Xen para-virtualized frontend driver
+
 
 This frontend driver implements Xen para-virtualized display
 according to the display protocol described at
-- 
2.7.4

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

[RFC PATCH] drm/xen-front: display_mode_valid() can be static

[kbuild test robot]

Fixes: d7f404c8b4b6 ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Fengguang Wu 
---
 xen_drm_front_kms.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c 
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 545049d..bd676be 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -273,7 +273,7 @@ static void display_update(struct drm_simple_display_pipe 
*pipe,
drm_dev_exit(idx);
 }
 
-enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
+static enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
const struct drm_display_mode *mode)
 {
struct xen_drm_front_drm_pipeline *pipeline =
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm/xen-front: Add support for Xen PV display frontend

[kbuild test robot]

Hi Oleksandr,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20180328]
[cannot apply to v4.16-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Oleksandr-Andrushchenko/drm-xen-front-Add-support-for-Xen-PV-display-frontend/20180329-090744
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/xen/xen_drm_front_kms.c:276:22: sparse: symbol 
>> 'display_mode_valid' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: clarify adjusted_mode for a bridge connected to a crtc

[Daniel Vetter]

On Thu, Mar 29, 2018 at 9:35 AM, Philippe CORNU  wrote:
> Hi Daniel,
>
> On 03/27/2018 05:51 PM, Daniel Vetter wrote:
>> On Mon, Feb 26, 2018 at 01:16:04PM +0100, Philippe Cornu wrote:
>>> This patch clarifies the adjusted_mode documentation
>>> for a bridge directly connected to a crtc.
>>>
>>> Signed-off-by: Philippe Cornu 
>>> ---
>>> This patch is linked to the discussion https://lkml.org/lkml/2018/1/25/367
>>
>> Reviewed-by: Daniel Vetter 
>
> Many thanks for the review.
>
>>
>> Aside, and kinda why I noticed this patch to begin with: You have drm-misc
>> commit rights, but you seem to not use that. And with 18 patches in the
>> 4.17 cycle you're the top contributor who's not pushing his own patches.
>>
>> What's the hold-up? Tools don't work, or something else? I really think
>> regular contributors should just push their own stuff themselves (after
>> appropriate review ofc).
>> -Daniel
>>
>
> I still consider myself a drm “beginner”, my first patch in drm was last
> summer so less than 1 year ago.

You're doing great patches, and at least for drm-misc you're the top
contributor who doesn't push stuff himself. You're definitely ready to
do so!

> However, thank you for your encouraging return, I will immediately study
> the matter (dim...) and prepare myself.

Yes please. And for any questions please ask on #dri-devel on
freenode, we're all happy to help out.
-Daniel

>
> Thank you,
> Philippe :-)
>
>>>
>>>   include/drm/drm_bridge.h | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index 3270fec46979..b5f3c070467c 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -177,7 +177,8 @@ struct drm_bridge_funcs {
>>>   * pipeline has been called already. If the bridge is the first element
>>>   * then this would be _encoder_helper_funcs.mode_set. The display
>>>   * pipe (i.e.  clocks and timing signals) is off when this function is
>>> - * called.
>>> + * called. If the bridge is connected to the crtc, the adjusted_mode
>>> + * parameter is the one defined in _crtc_state.adjusted_mode.
>>>   */
>>>  void (*mode_set)(struct drm_bridge *bridge,
>>>   struct drm_display_mode *mode,
>>> --
>>> 2.15.1
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

[Bug 105797] Tracker for YoYo based games start-up crashes

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Blocks||102625


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=102625
[Bug 102625] Game Crashlands crashes on startup
-- 
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: clarify adjusted_mode for a bridge connected to a crtc

[Philippe CORNU]

Hi Daniel,

On 03/27/2018 05:51 PM, Daniel Vetter wrote:
> On Mon, Feb 26, 2018 at 01:16:04PM +0100, Philippe Cornu wrote:
>> This patch clarifies the adjusted_mode documentation
>> for a bridge directly connected to a crtc.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>> This patch is linked to the discussion https://lkml.org/lkml/2018/1/25/367
> 
> Reviewed-by: Daniel Vetter 

Many thanks for the review.

> 
> Aside, and kinda why I noticed this patch to begin with: You have drm-misc
> commit rights, but you seem to not use that. And with 18 patches in the
> 4.17 cycle you're the top contributor who's not pushing his own patches.
> 
> What's the hold-up? Tools don't work, or something else? I really think
> regular contributors should just push their own stuff themselves (after
> appropriate review ofc).
> -Daniel
> 

I still consider myself a drm “beginner”, my first patch in drm was last 
summer so less than 1 year ago.
However, thank you for your encouraging return, I will immediately study 
the matter (dim...) and prepare myself.

Thank you,
Philippe :-)

>>
>>   include/drm/drm_bridge.h | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 3270fec46979..b5f3c070467c 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -177,7 +177,8 @@ struct drm_bridge_funcs {
>>   * pipeline has been called already. If the bridge is the first element
>>   * then this would be _encoder_helper_funcs.mode_set. The display
>>   * pipe (i.e.  clocks and timing signals) is off when this function is
>> - * called.
>> + * called. If the bridge is connected to the crtc, the adjusted_mode
>> + * parameter is the one defined in _crtc_state.adjusted_mode.
>>   */
>>  void (*mode_set)(struct drm_bridge *bridge,
>>   struct drm_display_mode *mode,
>> -- 
>> 2.15.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102625] Game Crashlands crashes on startup

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Depends on||105797


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=105797
[Bug 105797] Tracker for YoYo based games start-up crashes
-- 
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 102625] Game Crashlands crashes on startup

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|NOTOURBUG   |---
 Status|RESOLVED|REOPENED

--- Comment #8 from Timothy Arceri  ---
Reopening as the game engine version is the same in both logs. Can you confirm
if its working or was it just working when you ran with
R600_DEBUG="ps,vs,tcs,tes,cs,gs" ?

-- 
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 102625] Game Crashlands crashes on startup

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

-- 
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 105797] Tracker for YoYo based games start-up crashes

[bugzilla-daemon]

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

--- Comment #2 from Timothy Arceri  ---
Seems like another game running on this engine was fixed after a release with a
newer version of the engine. See bug #102625

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

Re: [PATCH 1/4] drm/vgem: Fix vgem_init to get drm device avaliable.

[Daniel Vetter]

On Wed, Mar 28, 2018 at 04:11:39PM +0100, Emil Velikov wrote:
> On 28 March 2018 at 15:49, Chris Wilson  wrote:
> > Quoting Emil Velikov (2018-03-28 02:24:48)
> >> From: Deepak Sharma 
> >>
> >> Modify vgem_init to take platform dev as parent in drm_dev_init.
> >> This will make drm device available at "/sys/devices/platform/vgem"
> >> in x86 chromebook.
> >>
> >> Cc: Daniel Vetter 
> >> Signed-off-by: Deepak Sharma 
> >> Reviewed-by: Sean Paul 
> >> Signed-off-by: Emil Velikov 
> >> ---
> >>  drivers/gpu/drm/vgem/vgem_drv.c | 15 +++
> >>  1 file changed, 7 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
> >> b/drivers/gpu/drm/vgem/vgem_drv.c
> >> index 2524ff116f00..636ce32fa945 100644
> >> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> >> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> >> @@ -472,31 +472,30 @@ static int __init vgem_init(void)
> >> if (!vgem_device)
> >> return -ENOMEM;
> >>
> >> -   ret = drm_dev_init(_device->drm, _driver, NULL);
> >> -   if (ret)
> >> -   goto out_free;
> >
> > A shame to lose the test coverage this gave us. Care to replace that
> > with a selftest?
> 
> Hi Chris, can you be more specific:
> - What test coverage is lost - some IGT tests/other?
> - Can you provide a rough outline of the test you have in mind?

I think Chris meant the NULL case for drm_dev_init (which was broken
once). But since this series also disallows that with a subsequent patch I
think we're just fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm/xen-front: Add support for Xen PV display frontend

[Daniel Vetter]

On Wed, Mar 28, 2018 at 01:29:46PM +0300, Oleksandr Andrushchenko wrote:
> Hi, Daniel!
> 
> I just noticed I have missed one change in the patch:
> the below must be static.
> 
> On 03/28/2018 10:42 AM, Daniel Vetter wrote:
> > +enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
> > +   const struct drm_display_mode *mode)
> > +{
> > +   struct xen_drm_front_drm_pipeline *pipeline =
> > +   container_of(crtc,
> Could you please amend the patch in attachment
> when merging, so I don't resend?

Merging is up to you, as soon as you have your commit rights.
-Daniel

> 
> Thank you in advance,
> Oleksandr

> From 3a82d76bd3d954056b760e5d1d09e2f96a2786ef Mon Sep 17 00:00:00 2001
> From: Oleksandr Andrushchenko 
> Date: Wed, 28 Mar 2018 13:24:04 +0300
> Subject: [PATCH] drm/xen-front: Make display_mode_valid static
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c 
> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> index 545049dfaf0a..bd676be5a0db 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> @@ -273,7 +273,7 @@ static void display_update(struct drm_simple_display_pipe 
> *pipe,
>   drm_dev_exit(idx);
>  }
>  
> -enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
> +static enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
>   const struct drm_display_mode *mode)
>  {
>   struct xen_drm_front_drm_pipeline *pipeline =
> -- 
> 2.7.4
> 

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

Re: [PATCH] drm/atmel-hlcdc: add command line option to specify preferred depth

[Daniel Vetter]

On Wed, Mar 28, 2018 at 02:25:12PM +0200, Boris Brezillon wrote:
> On Wed, 28 Mar 2018 14:22:36 +0200
> Daniel Vetter  wrote:
> 
> > On Wed, Mar 28, 2018 at 09:34:54AM +0200, Boris Brezillon wrote:
> > > Hi Peter,
> > > 
> > > On Mon, 26 Mar 2018 09:35:02 +0200
> > > Peter Rosin  wrote:
> > >   
> > > > I have an sama5d31-based system with 64MB of memory and a 1920x1080
> > > > LVDS display wired for 16-bpp. When I enable legacy fbdev support,
> > > > the contiguous memory allocator invariably fails with the order-11
> > > > allocation for a 1920x1080@24-bpp buffer (~6MB). But this HW can never
> > > > make any good use of RGB888, so that is a wasted attempt anyway that
> > > > would also waste precious memory should it succeed.
> > > > 
> > > > Sure, I could rewrite user-space to go directly to KMS etc, and that
> > > > makes the (attempted) order-11 allocation go away, replacing it with
> > > > one order-10 allocation per application restart for a 1920x1080@16-bpp
> > > > buffer (<4MB). But after a few restarts, order-10 allocations start to
> > > > fail as well, which is only to be expected AFAIU.
> > > > 
> > > > So, I'd rather not change user-space (which was originally written
> > > > to target a smaller display) so that I at the same time get the
> > > > benefit of an early pre-allocated fbdev frame-buffer that can be
> > > > reused over and over. But to do that I need to tell the driver that
> > > > 16-bpp is the preferred depth. Add a module parameter to do just that.
> > > > 
> > > > Signed-off-by: Peter Rosin 
> > > > ---
> > > >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 18 +-
> > > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > > > 
> > > > I found some inspiration regarding naming and implementation here:
> > > > https://patchwork.kernel.org/patch/9848631/
> > > > 
> > > > I have found no feedback on that patch though, which makes me wonder if
> > > > I'm perhaps barking up the wronig tree?  
> > > 
> > > Hm, isn't that something you can already overload with the video=
> > > parameter?
> > > 
> > >   video=:[-]
> > > 
> > > AFAIR,  encodes the color depth, so what is the benefit of adding
> > > this new property to overload the default depth?
> > > 
> > > Maybe I'm wrong and the default depth param is actually useful, but in
> > > this case we should probably make it generic since other drivers seems
> > > to need it too, and we might want to attach it to a specific display
> > > engine instance.  
> > 
> > I think for the drm's fbdev emulation we ignore the bpp ...
> 
> Nope, it's already parsed [1].
> 
> [1]https://elixir.bootlin.com/linux/v4.16-rc3/source/drivers/gpu/drm/drm_fb_helper.c#L1812

Oh, totally missed this. I honestly wonder why we then have all the
various bpp module options in different drivers ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/15] v4l: vsp1: Move DRM atomic commit pipeline setup to separate function

[Laurent Pinchart]

Hi Kieran,

On Wednesday, 28 March 2018 17:43:13 EEST Kieran Bingham wrote:
> On 26/02/18 21:45, Laurent Pinchart wrote:
> > The DRM pipeline setup code used at atomic commit time is similar to the
> > setup code used when enabling the pipeline. Move it to a separate
> > function in order to share it.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> Assuming no hidden secret code addition in this code move that I haven't
> seen..
> 
> Only a minor nit below asking if the function should be pluralised (_inputs,
> rather than _input)

I'll fix that in v2, thanks.

> Reviewed-by: Kieran Bingham 
> 
> > ---
> > 
> >  drivers/media/platform/vsp1/vsp1_drm.c | 347
> >  + 1 file changed, 180 insertions(+), 167
> >  deletions(-)
> > 
> > diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> > b/drivers/media/platform/vsp1/vsp1_drm.c index 9a043a915c0b..7bf697ba7969
> > 100644
> > --- a/drivers/media/platform/vsp1/vsp1_drm.c
> > +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> > @@ -46,6 +46,185 @@ static void vsp1_du_pipeline_frame_end(struct
> > vsp1_pipeline *pipe,> 
> >   * Pipeline Configuration
> >   */
> > 
> > +/* Setup one RPF and the connected BRU sink pad. */
> > +static int vsp1_du_pipeline_setup_rpf(struct vsp1_device *vsp1,
> > + struct vsp1_pipeline *pipe,
> > + struct vsp1_rwpf *rpf,
> > + unsigned int bru_input)
> > +{
> > +   struct v4l2_subdev_selection sel;
> > +   struct v4l2_subdev_format format;
> > +   const struct v4l2_rect *crop;
> > +   int ret;
> > +
> > +   /*
> > +* Configure the format on the RPF sink pad and propagate it up to the
> > +* BRU sink pad.
> > +*/
> > +   crop = >drm->inputs[rpf->entity.index].crop;
> > +
> > +   memset(, 0, sizeof(format));
> > +   format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > +   format.pad = RWPF_PAD_SINK;
> > +   format.format.width = crop->width + crop->left;
> > +   format.format.height = crop->height + crop->top;
> > +   format.format.code = rpf->fmtinfo->mbus;
> > +   format.format.field = V4L2_FIELD_NONE;
> > +
> > +   ret = v4l2_subdev_call(>entity.subdev, pad, set_fmt, NULL,
> > +  );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   dev_dbg(vsp1->dev,
> > +   "%s: set format %ux%u (%x) on RPF%u sink\n",
> > +   __func__, format.format.width, format.format.height,
> > +   format.format.code, rpf->entity.index);
> > +
> > +   memset(, 0, sizeof(sel));
> > +   sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > +   sel.pad = RWPF_PAD_SINK;
> > +   sel.target = V4L2_SEL_TGT_CROP;
> > +   sel.r = *crop;
> > +
> > +   ret = v4l2_subdev_call(>entity.subdev, pad, set_selection, NULL,
> > +  );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   dev_dbg(vsp1->dev,
> > +   "%s: set selection (%u,%u)/%ux%u on RPF%u sink\n",
> > +   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
> > +   rpf->entity.index);
> > +
> > +   /*
> > +* RPF source, hardcode the format to ARGB to turn on format
> > +* conversion if needed.
> > +*/
> > +   format.pad = RWPF_PAD_SOURCE;
> > +
> > +   ret = v4l2_subdev_call(>entity.subdev, pad, get_fmt, NULL,
> > +  );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   dev_dbg(vsp1->dev,
> > +   "%s: got format %ux%u (%x) on RPF%u source\n",
> > +   __func__, format.format.width, format.format.height,
> > +   format.format.code, rpf->entity.index);
> > +
> > +   format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
> > +
> > +   ret = v4l2_subdev_call(>entity.subdev, pad, set_fmt, NULL,
> > +  );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   /* BRU sink, propagate the format from the RPF source. */
> > +   format.pad = bru_input;
> > +
> > +   ret = v4l2_subdev_call(>bru->subdev, pad, set_fmt, NULL,
> > +  );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
> > +   __func__, format.format.width, format.format.height,
> > +   format.format.code, BRU_NAME(pipe->bru), format.pad);
> > +
> > +   sel.pad = bru_input;
> > +   sel.target = V4L2_SEL_TGT_COMPOSE;
> > +   sel.r = vsp1->drm->inputs[rpf->entity.index].compose;
> > +
> > +   ret = v4l2_subdev_call(>bru->subdev, pad, set_selection, NULL,
> > +  );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   dev_dbg(vsp1->dev, "%s: set selection (%u,%u)/%ux%u on %s pad %u\n",
> > +   __func__, sel.r.left, sel.r.top, sel.r.width, sel.r.height,
> > +   BRU_NAME(pipe->bru), sel.pad);
> > +
> > +   return 0;
> > +}
> > +
> > +static unsigned int rpf_zpos(struct vsp1_device 

Re: [PATCH 05/15] v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a pipeline

[Laurent Pinchart]

Hi Kieran,

On Wednesday, 28 March 2018 17:10:10 EEST Kieran Bingham wrote:
> On 26/02/18 21:45, Laurent Pinchart wrote:
> > The DRM pipeline handling code uses the entity's pipe list head to check
> > whether the entity is already included in a pipeline. This method is a
> > bit fragile in the sense that it uses list_empty() on a list_head that
> > is a list member. Replace it by a simpler check for the entity pipe
> > pointer.
> 
> Yes, excellent.
> 
> > Signed-off-by: Laurent Pinchart
> > 
> 
> Reviewed-by: Kieran Bingham 
> 
> > ---
> > 
> >  drivers/media/platform/vsp1/vsp1_drm.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> > b/drivers/media/platform/vsp1/vsp1_drm.c index a7ad85ab0b08..e210917fdc3f
> > 100644
> > --- a/drivers/media/platform/vsp1/vsp1_drm.c
> > +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> > @@ -119,9 +119,9 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int
> > pipe_index,> 
> >  * Remove the RPF from the pipe and the list of BRU
> >  * inputs.
> >  */
> > 
> > -   WARN_ON(list_empty(>entity.list_pipe));
> > +   WARN_ON(!rpf->entity.pipe);
> 
> Does this WARN_ON() have much value any more ?
> 
> I think it could probably be removed... unless there is a race between
> potential calls through vsp1_du_atomic_flush() and vsp1_du_setup_lif() -
> but I would be very surprised if that wasn't protected at the DRM levels.

It should indeed be protected at the DRM level. The purpose of the WARN_ON() 
is twofold, it catches both bugs in the VSP1 driver (but I don't expect any 
bug here, so from that point of view the WARN_ON isn't needed), but also 
misbehaviours in the callers. There hasn't been any so far though, so maybe we 
could indeed remove the WARN_ON(). It just makes me feel a bit safer but 
probably not in any rational way :-)

>  (Removing it if chosen doesn't need to be in this patch though)
> 
> > rpf->entity.pipe = NULL;
> > 
> > -   list_del_init(>entity.list_pipe);
> > +   list_del(>entity.list_pipe);
> > 
> > pipe->inputs[i] = NULL;
> > 
> > bru->inputs[rpf->bru_input].rpf = NULL;
> > 
> > @@ -537,7 +537,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned
> > int pipe_index)> 
> > continue;
> > 
> > }
> > 
> > -   if (list_empty(>entity.list_pipe)) {
> > +   if (!rpf->entity.pipe) {
> > 
> > rpf->entity.pipe = pipe;
> > list_add_tail(>entity.list_pipe, >entities);
> > 
> > }
> > 
> > @@ -566,7 +566,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned
> > int pipe_index)> 
> >VI6_DPR_NODE_UNUSED);
> > 
> > entity->pipe = NULL;
> > 
> > -   list_del_init(>list_pipe);
> > +   list_del(>list_pipe);
> > 
> > continue;
> > 
> > }

-- 
Regards,

Laurent Pinchart

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

RE: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Mao, David]

Hi Keith,
If I read the patch correctly, the plane has been interpreted as the same as 
connector, and the stackIndex is the index of connector of current device.
Is it by intentional?
If the hardware don't have underlay/overlay supported, is it better to always 
report plane 0 rather than pretend to have multiple plane?

Thanks.
Best Regards,
David

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Keith Packard
Sent: Saturday, February 10, 2018 12:45 PM
To: mesa-...@lists.freedesktop.org
Cc: Keith Packard ; dri-devel@lists.freedesktop.org
Subject: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

This adds support for the KHR_display extension to the anv and radv
Vulkan drivers. The drivers now attempt to open the master DRM node
when the KHR_display extension is requested so that the common winsys
code can perform the necessary operations.

Signed-off-by: Keith Packard 
---
 configure.ac   |1 +
 meson.build|4 +-
 src/amd/vulkan/Makefile.am |8 +
 src/amd/vulkan/Makefile.sources|3 +
 src/amd/vulkan/meson.build |7 +
 src/amd/vulkan/radv_device.c   |   28 +-
 src/amd/vulkan/radv_extensions.py  |7 +-
 src/amd/vulkan/radv_private.h  |2 +
 src/amd/vulkan/radv_wsi.c  |3 +-
 src/amd/vulkan/radv_wsi_display.c  |  143 
 src/intel/Makefile.sources |3 +
 src/intel/Makefile.vulkan.am   |7 +
 src/intel/vulkan/anv_device.c  |   18 +-
 src/intel/vulkan/anv_extensions.py |1 +
 src/intel/vulkan/anv_extensions_gen.py |5 +-
 src/intel/vulkan/anv_wsi.c |3 +-
 src/intel/vulkan/anv_wsi_display.c |  129 +++
 src/intel/vulkan/meson.build   |7 +
 src/vulkan/Makefile.am |7 +
 src/vulkan/Makefile.sources|4 +
 src/vulkan/wsi/meson.build |   10 +
 src/vulkan/wsi/wsi_common.c|   19 +-
 src/vulkan/wsi/wsi_common.h|5 +-
 src/vulkan/wsi/wsi_common_display.c| 1368 
 src/vulkan/wsi/wsi_common_display.h|   72 ++
 src/vulkan/wsi/wsi_common_private.h|   10 +
 26 files changed, 1858 insertions(+), 16 deletions(-)
 create mode 100644 src/amd/vulkan/radv_wsi_display.c
 create mode 100644 src/intel/vulkan/anv_wsi_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.c
 create mode 100644 src/vulkan/wsi/wsi_common_display.h

diff --git a/configure.ac b/configure.ac
index 8ed606c7694..46318365603 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1849,6 +1849,7 @@ fi
 AM_CONDITIONAL(HAVE_PLATFORM_X11, echo "$platforms" | grep -q 'x11')
 AM_CONDITIONAL(HAVE_PLATFORM_WAYLAND, echo "$platforms" | grep -q 'wayland')
 AM_CONDITIONAL(HAVE_PLATFORM_DRM, echo "$platforms" | grep -q 'drm')
+AM_CONDITIONAL(HAVE_PLATFORM_DISPLAY, echo "$platforms" | grep -q 'drm')
 AM_CONDITIONAL(HAVE_PLATFORM_SURFACELESS, echo "$platforms" | grep -q 
'surfaceless')
 AM_CONDITIONAL(HAVE_PLATFORM_ANDROID, echo "$platforms" | grep -q 'android')
 
diff --git a/meson.build b/meson.build
index b39e2f8ab96..aeb7f5e2917 100644
--- a/meson.build
+++ b/meson.build
@@ -239,11 +239,12 @@ with_platform_wayland = false
 with_platform_x11 = false
 with_platform_drm = false
 with_platform_surfaceless = false
+with_platform_display = false
 egl_native_platform = ''
 _platforms = get_option('platforms')
 if _platforms == 'auto'
   if system_has_kms_drm
-_platforms = 'x11,wayland,drm,surfaceless'
+_platforms = 'x11,wayland,drm,surfaceless,display'
   elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
 _platforms = 'x11,surfaceless'
   else
@@ -257,6 +258,7 @@ if _platforms != ''
   with_platform_wayland = _split.contains('wayland')
   with_platform_drm = _split.contains('drm')
   with_platform_surfaceless = _split.contains('surfaceless')
+  with_platform_display = _split.contains('display')
   egl_native_platform = _split[0]
 endif
 
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 61025968942..061b8144b88 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -76,6 +76,14 @@ VULKAN_LIB_DEPS = \
$(DLOPEN_LIBS) \
-lm
 
+if HAVE_PLATFORM_DISPLAY
+AM_CPPFLAGS += \
+   -DVK_USE_PLATFORM_DISPLAY_KHR
+
+VULKAN_SOURCES += $(VULKAN_WSI_DISPLAY_FILES)
+
+endif
+
 if HAVE_PLATFORM_X11
 AM_CPPFLAGS += \
$(XCB_DRI3_CFLAGS) \
diff --git a/src/amd/vulkan/Makefile.sources b/src/amd/vulkan/Makefile.sources
index a510d88d965..618a6cdaed0 100644
--- a/src/amd/vulkan/Makefile.sources
+++ b/src/amd/vulkan/Makefile.sources
@@ -78,6 +78,9 @@ VULKAN_WSI_WAYLAND_FILES := \
 VULKAN_WSI_X11_FILES := \
radv_wsi_x11.c
 
+VULKAN_WSI_DISPLAY_FILES := \
+   radv_wsi_display.c
+
 VULKAN_GENERATED_FILES := \
radv_entrypoints.c \
  

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Daniel Vetter]

On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote:
> Add a peer2peer flag noting that the importer can deal with device
> resources which are not backed by pages.
> 
> Signed-off-by: Christian König 

Um strictly speaking they all should, but ttm never bothered to use the
real interfaces but just hacked around the provided sg list, grabbing the
underlying struct pages, then rebuilding the sg list again.

The entire point of using sg lists was exactly to allow this use case of
peer2peer dma (or well in general have special exporters which managed
memory/IO ranges not backed by struct page). So essentially you're having
a "I'm totally not broken flag" here.

I think a better approach would be if we add a requires_struct_page or so,
and annotate the current importers accordingly. Or we just fix them up (it
is all in shared ttm code after all, I think everyone else got this
right).
-Daniel

> ---
>  drivers/dma-buf/dma-buf.c | 1 +
>  include/linux/dma-buf.h   | 4 
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index ffaa2f9a9c2c..f420225f93c6 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -565,6 +565,7 @@ struct dma_buf_attachment *dma_buf_attach(const struct 
> dma_buf_attach_info *info
>  
>   attach->dev = info->dev;
>   attach->dmabuf = dmabuf;
> + attach->peer2peer = info->peer2peer;
>   attach->priv = info->priv;
>   attach->invalidate = info->invalidate;
>  
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 15dd8598bff1..1ef50bd9bc5b 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -313,6 +313,7 @@ struct dma_buf {
>   * @dmabuf: buffer for this attachment.
>   * @dev: device attached to the buffer.
>   * @node: list of dma_buf_attachment.
> + * @peer2peer: true if the importer can handle peer resources without pages.
>   * @priv: exporter specific attachment data.
>   *
>   * This structure holds the attachment information between the dma_buf buffer
> @@ -328,6 +329,7 @@ struct dma_buf_attachment {
>   struct dma_buf *dmabuf;
>   struct device *dev;
>   struct list_head node;
> + bool peer2peer;
>   void *priv;
>  
>   /**
> @@ -392,6 +394,7 @@ struct dma_buf_export_info {
>   * @dmabuf:  the exported dma_buf
>   * @dev: the device which wants to import the attachment
>   * @priv:private data of importer to this attachment
> + * @peer2peer:   true if the importer can handle peer resources without 
> pages
>   * @invalidate:  callback to use for invalidating mappings
>   *
>   * This structure holds the information required to attach to a buffer. Used
> @@ -401,6 +404,7 @@ struct dma_buf_attach_info {
>   struct dma_buf *dmabuf;
>   struct device *dev;
>   void *priv;
> + bool peer2peer;
>   void (*invalidate)(struct dma_buf_attachment *attach);
>  };
>  
> -- 
> 2.14.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

Re: [PATCH 02/15] v4l: vsp1: Remove outdated comment

[Laurent Pinchart]

Hi Kieran,

On Wednesday, 28 March 2018 22:04:49 EEST Kieran Bingham wrote:
> On 28/03/18 13:27, Kieran Bingham wrote:
> > On 26/02/18 21:45, Laurent Pinchart wrote:
> >> The entities in the pipeline are all started when the LIF is setup.
> >> Remove the outdated comment that state otherwise.
> >> 
> >> Signed-off-by: Laurent Pinchart
> >> 
> > 
> > I'll start with the easy ones :-)
> 
> In fact, couldn't this patch be squashed into [PATCH 01/15] in this series ?

I suppose it could, I'll do so.

> > Reviewed-by: Kieran Bingham 
> > 
> >> ---
> >> 
> >>  drivers/media/platform/vsp1/vsp1_drm.c | 6 +-
> >>  1 file changed, 1 insertion(+), 5 deletions(-)
> >> 
> >> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> >> b/drivers/media/platform/vsp1/vsp1_drm.c index
> >> e31fb371eaf9..a1f2ba044092 100644
> >> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> >> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> >> @@ -221,11 +221,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned
> >> int pipe_index,>> 
> >>return -EPIPE;
> >>
> >>}
> >> 
> >> -  /*
> >> -   * Enable the VSP1. We don't start the entities themselves right at
> >> this
> >> -   * point as there's no plane configured yet, so we can't start
> >> -   * processing buffers.
> >> -   */
> >> +  /* Enable the VSP1. */
> >> 
> >>ret = vsp1_device_get(vsp1);
> >>if (ret < 0)
> >>
> >>return ret;


-- 
Regards,

Laurent Pinchart

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

[Bug 105797] Tracker for YoYo based games start-up crashes

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Blocks||101747, 101384, 103915,
   ||101675

--- Comment #1 from Timothy Arceri  ---
These games based on the YoYo Games Linux Runner all crash on start-up. There
has been report in the past that disabling compiler threading e.g using
R600_DEBUG="vs,ps,gs,tcs,tes,cs" stops them crashing but this didn't seem to
work for me.


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=101384
[Bug 101384] [Hero Siege] si_shader: segfault in libLLVM-5.0.so.1
https://bugs.freedesktop.org/show_bug.cgi?id=101675
[Bug 101675] Peace, Death! crashed on start-up
https://bugs.freedesktop.org/show_bug.cgi?id=101747
[Bug 101747] Steam-Game Turmoil, Segfault on start
https://bugs.freedesktop.org/show_bug.cgi?id=103915
[Bug 103915] Undertale crashes on startup (compiling shaders?)
-- 
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 103915] Undertale crashes on startup (compiling shaders?)

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Depends on||105797


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=105797
[Bug 105797] Tracker for YoYo based games start-up crashes
-- 
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