Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()
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)
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=102553 Stefano Ciprianichanged: 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
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
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
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
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
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
Patches #2 and #3 are Reviewed-by: Christian Königas 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()
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
On Thu, Mar 29, 2018 at 8:56 PM, Alex Deucherwrote: > 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
There is no @kernel parameter anymore and document the @guilty parameter Signed-off-by: Nayan DeshmukhReviewed-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
this patch also effect the amdgpu and etnaviv drivers which use the function drm_sched_entity_init Signed-off-by: Nayan DeshmukhSuggested-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
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 DeshmukhSuggested-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
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
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
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
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()
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
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
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
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
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
On Tue, Mar 27, 2018 at 1:29 PM, Nayan Deshmukhwrote: > 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
From: Gustavo PadovanAdd 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
"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
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
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
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
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()
Sorry, didn't mean to drop the lists here. re-adding. On Wed, Mar 28, 2018 at 4:05 PM, Alex Deucherwrote: > 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
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
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
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
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 Ccc: 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
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
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 CReviewed-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
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
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
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
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
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
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
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
On 29 March 2018 at 13:31, Sebastian Reichelwrote: > 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
From: Oleksandr AndrushchenkoHello! 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
From: Oleksandr AndrushchenkoIntroduce 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
在 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
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 Valkeinenwrote: >>> 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
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
On 29/03/18 13:58, Emil Velikov wrote: > On 29 March 2018 at 11:40, Tomi Valkeinenwrote: >> 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
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
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 PinchartJust 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
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 IwaiReported-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()
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
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
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önigUm 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
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ønnesUse 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
On 03/28/18 16:35, Emil Velikov wrote: > On 28 March 2018 at 11:27, Laszlo Ersekwrote: >> 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
On 29 March 2018 at 11:40, Tomi Valkeinenwrote: > 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
On 29 March 2018 at 11:40, Tomi Valkeinenwrote: > 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
On 29 March 2018 at 11:40, Tomi Valkeinenwrote: > 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
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
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
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
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
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
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
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
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
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
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
From: Oleksandr AndrushchenkoAdd 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
From: Oleksandr AndrushchenkoHello! 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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=105680 Marta Löfstedtchanged: 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
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
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
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 AndrushchenkoDate: 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
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
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
On Thu, Mar 29, 2018 at 9:35 AM, Philippe CORNUwrote: > 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
https://bugs.freedesktop.org/show_bug.cgi?id=105797 Timothy Arcerichanged: 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=102625 Timothy Arcerichanged: 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
https://bugs.freedesktop.org/show_bug.cgi?id=102625 Timothy Arcerichanged: 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
https://bugs.freedesktop.org/show_bug.cgi?id=102625 Timothy Arcerichanged: 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
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.
On Wed, Mar 28, 2018 at 04:11:39PM +0100, Emil Velikov wrote: > On 28 March 2018 at 15:49, Chris Wilsonwrote: > > 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
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
On Wed, Mar 28, 2018 at 02:25:12PM +0200, Boris Brezillon wrote: > On Wed, 28 Mar 2018 14:22:36 +0200 > Daniel Vetterwrote: > > > 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
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
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
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
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önigUm 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=105797 Timothy Arcerichanged: 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?)
https://bugs.freedesktop.org/show_bug.cgi?id=103915 Timothy Arcerichanged: 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