[Bug 105423] Unable to unbind my 2nd GPU (Rx580)
https://bugs.freedesktop.org/show_bug.cgi?id=105423 Max changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA
Hi Peter,
thanks a million for the extensive testing and reviewing.
I'll go through the issues you've found below, but it appears to me
that they're all either in the "works as intended" category or are
caused by something unrelated to this series:
On Mon, Mar 05, 2018 at 09:58:31PM +0100, Peter Wu wrote:
> Issue 1 - GPU does not suspend on text console.
> When present at the text console and an external monitor is connected
> through HDMI or DP, the RPM counter is 1. Only when the cable is removed
> (or when "echo off > /sys/class/drm/card1-HDMI-A-1/status"), the RPM
> count drops to 0 and the GPU device suspends. When Xorg is started
> (startx), the RPM counter also drops to 0 though.
Yes, that behavior is intended: The GPU device is kept resumed as
long as it has an active crtc, and it has an active crtc if it's
used as text console.
> Issue 2 - RPM counter for audio function drops below 0 on system sleep.
> When both nouveau and snd-hda-intel are loaded and a HDMI (or DP?) cable
> is connected, the RPM counter becomes one after suspend/resume. This
> happens both with text console and Xorg.
Which RPM counter becomes one? That of the GPU? If so, it would be
caused by the GPU activating a crtc on hotplug to light up the display,
hence staying resumed.
I don't quite understand what you mean by "RPM counter for audio
function drops below 0 on system sleep". I've gone through the HDA
code and don't see an unbalanced pm_runtime_get / _put. However the
PM core changes the usage count a couple of times over a system sleep
cycle by acquiring/releasing a runtime PM ref or enabling/disabling
runtime PM (see drivers/base/power/main.c), maybe that's what you
observed.
> Issue 3 - invalid PCI config reads to audio device if disconnected.
> When no HDMI/DP cable is connected, the HDMI audio function will be
> inaccessible after runtime/system resume. Assume nouveau loaded before
> s/r, then loading snd-hda-intel will fail with:
>
> hdaudio hdaudioC1D0: no AFG or MFG node found
> hdaudio hdaudioC1D1: no AFG or MFG node found
> hdaudio hdaudioC1D2: no AFG or MFG node found
> hdaudio hdaudioC1D3: no AFG or MFG node found
> hdaudio hdaudioC1D4: no AFG or MFG node found
> hdaudio hdaudioC1D5: no AFG or MFG node found
> hdaudio hdaudioC1D6: no AFG or MFG node found
> hdaudio hdaudioC1D7: no AFG or MFG node found
> snd_hda_intel :01:00.1: no codecs initialized
Okay, that's really bad, but it appears to be caused by the BIOS
hiding the audio function on resume if no cable is connected.
I've attached 3 patches to this bugzilla to fix this issue:
https://bugs.freedesktop.org/show_bug.cgi?id=75985
I've extensively tested system sleep in conjunction with the
switcheroo_devlink patches and the above never occurred on my
machine because the audio function is never hidden.
I don't consider this issue a blocker for the switcheroo_devlink
patches because I would expect it to occur regardless. Quite to
the contrary, the switcheroo_devlink patches are a requirement to
fix the issue because the audio function needs to be exposed
either from the GPU driver or a PCI quirk applied to the GPU,
and the audio function needs to delay resume until that has
happened, which is achieved by the device link.
> Issue 4 - runtime_active_kids leak with audio function.
> After the above issue, the audio device never entered the suspended
> state even though the runtime_usage counter reached 0. It turned out
> that runtime_active_kids was 4. Every time snd-hda-intel is loaded (and
> fails to initialize due to the above issue), this counter is increased.
Yes, the codec devices are created as children of the HDA device
and keep it awake because initialization failed. This won't occur
once issue 3 is fixed.
> Issue 5 - audio breaks after system sleep or stopping Xorg.
> When Xorg is stopped or the system sleep/resumes while speaker-test is
> active (e.g. in GNU screen), audio stops playing and speaker-test exits.
That is odd, I don't have an explanation for this but suspect a bug
in the sound code.
> Issue 6 - wrong pin status reported / no audio
> (Possibly "working as expected" since audio is tied to GPU function.)
> Scenario: HDMI cable is connected but GPU is unused
> ("echo off > /sys/class/drm/card1-HDMI-1-1/status" from console or
> with "xrandr --output HDMI-A-1 --off"). hdajacksensetest reports no
> HDMI pin presence even if connected, dmesg reports:
>
> nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1
Interesting, and yes, that would seem to be working as expected.
> Issue 7 - nouveau: warning after unloading after stopping Xorg
> (Issue in nouveau, likely not related to this patch set.)
> After "xrandr --output HDMI-1-1 --mode 2560x1440" in Xorg, stopping Xorg
> (and possibly "echo off > /sys/class/drm/card1-HDMI-A-1/status"),
> removing nouveau triggered:
>
> WARNING: CPU: 7 PID: 5475 at drivers/gpu/drm/drm_mode_config.c:439
> drm_mode_config_cl
Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge
Hi,
On Friday 09 March 2018 07:21 PM, Jacopo Mondi wrote:
Hello,
after some discussion on the proposed bindings for generic lvds decoder and
Thine THC63LVD1024, I decided to drop the THC63 specific part and just live with
a transparent decoder that does not support any configuration from DT.
Dropping THC63 support to avoid discussion on how to better implement support
for a DRM bridge with 2 input ports and focus on LVDS mode propagation through
bridges as explained in v1 cover letter (for DRM people: please see [1] as why
I find difficult to implement support for bridges with multiple input endpoints)
Same base branch as v1, with same patches for V3M Eagle applied on top.
git://jmondi.org/linux v3m/v4.16-rc3/base
Thanks
j
v1 -> v2:
- Drop support for THC63LVD1024
[1] I had a quick at how to model a DRM bridge with multiple input
ports, and I see a blocker in how DRM identifies and matches bridges using
the devices node in place of the endpoint nodes.
As THC63LVD1024 supports up to 2 LVDS inputs and 2 LVDS outputs, I see only
a few ways to support that:
1) register 2 drm bridges from the same driver (one for each input/output
pair)
but they would both be matches on the same device node when the preceding
bridge calls "of_drm_find_bridge()".
I think this is the way to go. DRM doesn't say anywhere that we can't
have 2 drm_bridge-s contained in a single device. About the issue with
of_drm_find_bridge(), if you set the 2 bridge's 'of_node' field to
the bridge1 and bridge2 nodes as shown below, wouldn't that suffice.
From what I know, we don't necessarily need to set the bridge's of_node
to the device (i.e, thschip) itself.
thschip {
...
ports {
bridge1: port@0 {
...
};
bridge2: port@1 {
...
};
};
};
Thanks,
Archit
2) register a single bridge with multiple "next bridges", but when the bridge
gets attached I don't see a way on how to identify on which next bridge
"drm_bridge_attach()" on, as it depends on the endpoint the current bridge
has been attached on first, and we don't have that information.
3) Register more instances of the same chip in DTS, one for each input/output
pair. They gonna share supplies and gpios, and I don't like that.
I had a quick look at the currently in mainline bridges and none of them has
multiple input endpoints, except for HDMI audio endpoint, which I haven't found
in use in any DTS. I guess the problem has been already debated and maybe solved
in the past, so feel free to point me to other sources.
Jacopo Mondi (3):
dt-bindings: display: bridge: Document LVDS to parallel decoder
drm: bridge: Add LVDS decoder driver
arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
.../bindings/display/bridge/lvds-decoder.txt | 42 ++
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31 +++-
drivers/gpu/drm/bridge/Kconfig | 8 ++
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/lvds-decoder.c | 157 +
5 files changed, 237 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-decoder.txt
create mode 100644 drivers/gpu/drm/bridge/lvds-decoder.c
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105379] The Witcher: Enhanced Edition under Wine fails to launch
https://bugs.freedesktop.org/show_bug.cgi?id=105379
--- Comment #3 from Andrew Sheldon ---
(In reply to Matias N. Goldberg from comment #2)
> I'm no mesa dev but could you test with and before
> bc65dcab3bc48673ff6180afb036561a4b8b1119 ?
>
> This might be a dupe of https://bugs.freedesktop.org/show_bug.cgi?id=105339
>
> Unless you're sure your error started happening since
> b650fc09c3a35ca624aad5fe4b5c34867708f116
I'm certain it's that particular commit since I've been using a reverted patch
of that commit with my system Mesa for the last few days.
I.e. this:
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 7c50ffae6a..7940fc8d5b 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -158,10 +158,6 @@ static void si_set_debug_callback(struct pipe_context
*ctx,
const struct pipe_debug_callback *cb)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_screen *screen = sctx->screen;
-
- util_queue_finish(&screen->shader_compiler_queue);
- util_queue_finish(&screen->shader_compiler_queue_low_priority);
if (cb)
sctx->debug = *cb;
--
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
[RFC PATCH 08/13] drm/nouveau: special mapping method for HMM (user interface)
From: Jérôme Glisse
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 17
drivers/gpu/drm/nouveau/include/nvif/vmm.h| 2 +
drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h | 25
drivers/gpu/drm/nouveau/nvif/vmm.c| 29 ++
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c| 49 ---
5 files changed, 99 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index 2928ecd989ad..2c24817ca533 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -14,6 +14,8 @@ struct nvif_vmm_v0 {
#define NVIF_VMM_V0_PUT0x02
#define NVIF_VMM_V0_MAP0x03
#define NVIF_VMM_V0_UNMAP 0x04
+#define NVIF_VMM_V0_HMM_MAP0x05
+#define NVIF_VMM_V0_HMM_UNMAP 0x06
struct nvif_vmm_page_v0 {
__u8 version;
@@ -61,4 +63,19 @@ struct nvif_vmm_unmap_v0 {
__u8 pad01[7];
__u64 addr;
};
+
+struct nvif_vmm_hmm_map_v0 {
+ __u8 version;
+ __u8 pad01[7];
+ __u64 addr;
+ __u64 npages;
+ __u64 pages;
+};
+
+struct nvif_vmm_hmm_unmap_v0 {
+ __u8 version;
+ __u8 pad01[7];
+ __u64 addr;
+ __u64 npages;
+};
#endif
diff --git a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
index c5db8a2e82df..c5e4adaa0e3c 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
@@ -39,4 +39,6 @@ void nvif_vmm_put(struct nvif_vmm *, struct nvif_vma *);
int nvif_vmm_map(struct nvif_vmm *, u64 addr, u64 size, void *argv, u32 argc,
struct nvif_mem *, u64 offset);
int nvif_vmm_unmap(struct nvif_vmm *, u64);
+int nvif_vmm_hmm_map(struct nvif_vmm *vmm, u64 addr, u64 npages, u64 *pages);
+int nvif_vmm_hmm_unmap(struct nvif_vmm *vmm, u64 addr, u64 npages);
#endif
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
index 719d50e6296f..8f08718e05aa 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
@@ -4,20 +4,6 @@
#include
#include
-/* Need to change HMM to be more driver friendly */
-#if IS_ENABLED(CONFIG_HMM)
-#else
-typedef unsigned long hmm_pfn_t;
-#define HMM_PFN_VALID (1 << 0)
-#define HMM_PFN_READ (1 << 1)
-#define HMM_PFN_WRITE (1 << 2)
-#define HMM_PFN_ERROR (1 << 3)
-#define HMM_PFN_EMPTY (1 << 4)
-#define HMM_PFN_SPECIAL (1 << 5)
-#define HMM_PFN_DEVICE_UNADDRESSABLE (1 << 6)
-#define HMM_PFN_SHIFT 7
-#endif
-
struct nvkm_vma {
struct list_head head;
struct rb_node tree;
@@ -79,10 +65,13 @@ struct nvkm_vmm_map {
struct nvkm_mm_node *mem;
struct scatterlist *sgl;
dma_addr_t *dma;
-#define NV_HMM_PAGE_FLAG_V HMM_PFN_VALID
-#define NV_HMM_PAGE_FLAG_W HMM_PFN_WRITE
-#define NV_HMM_PAGE_FLAG_E HMM_PFN_ERROR
-#define NV_HMM_PAGE_PFN_SHIFT HMM_PFN_SHIFT
+#define NV_HMM_PAGE_FLAG_V (1 << 0)
+#define NV_HMM_PAGE_FLAG_R 0
+#define NV_HMM_PAGE_FLAG_W (1 << 1)
+#define NV_HMM_PAGE_FLAG_E (-1ULL)
+#define NV_HMM_PAGE_FLAG_N 0
+#define NV_HMM_PAGE_FLAG_S (1ULL << 63)
+#define NV_HMM_PAGE_PFN_SHIFT 8
u64 *pages;
u64 off;
diff --git a/drivers/gpu/drm/nouveau/nvif/vmm.c
b/drivers/gpu/drm/nouveau/nvif/vmm.c
index 31cdb2d2e1ff..27a7b95b4e9c 100644
--- a/drivers/gpu/drm/nouveau/nvif/vmm.c
+++ b/drivers/gpu/drm/nouveau/nvif/vmm.c
@@ -32,6 +32,35 @@ nvif_vmm_unmap(struct nvif_vmm *vmm, u64 addr)
sizeof(struct nvif_vmm_unmap_v0));
}
+int
+nvif_vmm_hmm_map(struct nvif_vmm *vmm, u64 addr, u64 npages, u64 *pages)
+{
+ struct nvif_vmm_hmm_map_v0 args;
+ int ret;
+
+ args.version = 0;
+ args.addr = addr;
+ args.npages = npages;
+ args.pages = (uint64_t)pages;
+ ret = nvif_object_mthd(&vmm->object, NVIF_VMM_V0_HMM_MAP,
+ &args, sizeof(args));
+ return ret;
+}
+
+int
+nvif_vmm_hmm_unmap(struct nvif_vmm *vmm, u64 addr, u64 npages)
+{
+ struct nvif_vmm_hmm_unmap_v0 args;
+ int ret;
+
+ args.version = 0;
+ args.addr = addr;
+ args.npages = npages;
+ ret = nvif_object_mthd(&vmm->object, NVIF_VMM_V0_HMM_UNMAP,
+ &args, sizeof(args));
+ return ret;
+}
+
int
nvif_vmm_map(struct nvif_vmm *vmm, u64 addr, u64 size, void *argv, u32 argc,
struct nvif_mem *mem, u64 offset)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
index 37b201b95f15..739f2af02552 1006
[RFC PATCH 07/13] drm/nouveau: special mapping method for HMM
From: Jérôme Glisse
HMM does not have any of the usual memory object properties. For HMM
inside any range the following is true:
- not all page in a range are valid
- not all page have same permission (read only, read and write)
- not all page are in same memory (system memory, GPU memory)
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h | 21 +
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 105 -
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 6 ++
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 73 ++
4 files changed, 204 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
index baab93398e54..719d50e6296f 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
@@ -2,6 +2,21 @@
#ifndef __NVKM_MMU_H__
#define __NVKM_MMU_H__
#include
+#include
+
+/* Need to change HMM to be more driver friendly */
+#if IS_ENABLED(CONFIG_HMM)
+#else
+typedef unsigned long hmm_pfn_t;
+#define HMM_PFN_VALID (1 << 0)
+#define HMM_PFN_READ (1 << 1)
+#define HMM_PFN_WRITE (1 << 2)
+#define HMM_PFN_ERROR (1 << 3)
+#define HMM_PFN_EMPTY (1 << 4)
+#define HMM_PFN_SPECIAL (1 << 5)
+#define HMM_PFN_DEVICE_UNADDRESSABLE (1 << 6)
+#define HMM_PFN_SHIFT 7
+#endif
struct nvkm_vma {
struct list_head head;
@@ -56,6 +71,7 @@ void nvkm_vmm_part(struct nvkm_vmm *, struct nvkm_memory
*inst);
int nvkm_vmm_get(struct nvkm_vmm *, u8 page, u64 size, struct nvkm_vma **);
void nvkm_vmm_put(struct nvkm_vmm *, struct nvkm_vma **);
+
struct nvkm_vmm_map {
struct nvkm_memory *memory;
u64 offset;
@@ -63,6 +79,11 @@ struct nvkm_vmm_map {
struct nvkm_mm_node *mem;
struct scatterlist *sgl;
dma_addr_t *dma;
+#define NV_HMM_PAGE_FLAG_V HMM_PFN_VALID
+#define NV_HMM_PAGE_FLAG_W HMM_PFN_WRITE
+#define NV_HMM_PAGE_FLAG_E HMM_PFN_ERROR
+#define NV_HMM_PAGE_PFN_SHIFT HMM_PFN_SHIFT
+ u64 *pages;
u64 off;
const struct nvkm_vmm_page *page;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
index 20d31526ba8f..96671987ce53 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
@@ -75,7 +75,7 @@ struct nvkm_vmm_iter {
struct nvkm_vmm *vmm;
u64 cnt;
u16 max, lvl;
- u64 start, addr;
+ u64 start, addr, *pages;
u32 pte[NVKM_VMM_LEVELS_MAX];
struct nvkm_vmm_pt *pt[NVKM_VMM_LEVELS_MAX];
int flush;
@@ -281,6 +281,59 @@ nvkm_vmm_unref_ptes(struct nvkm_vmm_iter *it, u32 ptei,
u32 ptes)
return true;
}
+static bool
+nvkm_vmm_unref_hmm_ptes(struct nvkm_vmm_iter *it, u32 ptei, u32 ptes)
+{
+ const struct nvkm_vmm_desc *desc = it->desc;
+ const int type = desc->type == SPT;
+ struct nvkm_vmm_pt *pgt = it->pt[0];
+ struct nvkm_mmu_pt *pt;
+ int mapped;
+
+ pt = pgt->pt[type];
+ mapped = desc->func->hmm_unmap(it->vmm, pt, ptei, ptes, NULL);
+ if (mapped <= 0)
+ return false;
+ ptes = mapped;
+
+ /* Dual-PTs need special handling, unless PDE becoming invalid. */
+ if (desc->type == SPT && (pgt->refs[0] || pgt->refs[1]))
+ nvkm_vmm_unref_sptes(it, pgt, desc, ptei, ptes);
+
+ /* GPU may have cached the PTs, flush before freeing. */
+ nvkm_vmm_flush_mark(it);
+ nvkm_vmm_flush(it);
+
+ nvkm_kmap(pt->memory);
+ while (mapped--) {
+ u64 data = nvkm_ro64(pt->memory, pt->base + ptei * 8);
+ dma_addr_t dma = (data >> 8) << 12;
+
+ if (!data) {
+ ptei++;
+ continue;
+ }
+ dma_unmap_page(it->vmm->mmu->subdev.device->dev, dma,
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
+ VMM_WO064(pt, it->vmm, ptei++ * 8, 0UL);
+ }
+ nvkm_done(pt->memory);
+
+ /* Drop PTE references. */
+ pgt->refs[type] -= ptes;
+
+ /* PT no longer neeed? Destroy it. */
+ if (!pgt->refs[type]) {
+ it->lvl++;
+ TRA(it, "%s empty", nvkm_vmm_desc_type(desc));
+ it->lvl--;
+ nvkm_vmm_unref_pdes(it);
+ return false; /* PTE writes for unmap() not necessary. */
+ }
+
+ return true;
+}
+
static void
nvkm_vmm_ref_sptes(struct nvkm_vmm_iter *it, struct nvkm_vmm_pt *pgt,
const struct nvkm_vmm_desc *desc, u32 ptei, u32 ptes)
@@ -349,6 +402,32 @@ nvkm_vmm_ref_sptes(struct nvkm_vmm_iter *it, struct
nvkm_vmm_pt *pgt,
}
}
+static bool
+nvkm_vmm_ref_hmm_ptes(struct nvkm_vmm_iter *it, u32 ptei, u32 ptes)
+{
+ const struct nvkm_vmm_desc *desc = it->desc;
+ const int type = desc->
[RFC PATCH 13/13] drm/nouveau: HACK FOR HMM AREA
From: Jérôme Glisse
Allow userspace to create a virtual address range hole for GEM
object.
Signed-off-by: Jérôme Glisse
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index dff51a0ee028..eafde4c6b7d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -172,6 +172,13 @@ nouveau_ttm_mmap(struct file *filp, struct vm_area_struct
*vma)
if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
return drm_legacy_mmap(filp, vma);
+ /* Hack for HMM */
+ if (vma->vm_pgoff < (DRM_FILE_PAGE_OFFSET + (4UL << 30))) {
+ struct nouveau_cli *cli = file_priv->driver_priv;
+
+ return nouveau_vmm_hmm(cli, filp, vma);
+ }
+
return ttm_bo_mmap(filp, vma, &drm->ttm.bdev);
}
@@ -305,7 +312,7 @@ nouveau_ttm_init(struct nouveau_drm *drm)
drm->ttm.bo_global_ref.ref.object,
&nouveau_bo_driver,
dev->anon_inode->i_mapping,
- DRM_FILE_PAGE_OFFSET,
+ DRM_FILE_PAGE_OFFSET + (4UL << 30),
drm->client.mmu.dmabits <= 32 ? true : false);
if (ret) {
NV_ERROR(drm, "error initialising bo driver, %d\n", ret);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 12/13] drm/nouveau: HMM area creation helpers for nouveau client
From: Jérôme Glisse
Helpers to create area of virtual address under HMM control for a nouveau
client. GPU access to HMM area are valid as long as the hole vma exist in
the process virtual address space.
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_hmm.c | 28
drivers/gpu/drm/nouveau/nouveau_hmm.h | 1 +
drivers/gpu/drm/nouveau/nouveau_vmm.c | 83 +++
drivers/gpu/drm/nouveau/nouveau_vmm.h | 12 +
4 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hmm.c
b/drivers/gpu/drm/nouveau/nouveau_hmm.c
index a4c6f687f6a8..680e29bbf367 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hmm.c
@@ -245,6 +245,31 @@ nouveau_vmm_sync_pagetables(struct hmm_mirror *mirror,
unsigned long start,
unsigned long end)
{
+ struct nouveau_hmm *hmm;
+ struct nouveau_cli *cli;
+
+ hmm = container_of(mirror, struct nouveau_hmm, mirror);
+ if (!hmm->hole.vma || hmm->hole.start == hmm->hole.end)
+ return;
+
+ /* Ignore area inside hole */
+ end = min(end, TASK_SIZE);
+ if (start >= hmm->hole.start && end <= hmm->hole.end)
+ return;
+ if (start < hmm->hole.start && end > hmm->hole.start) {
+ nouveau_vmm_sync_pagetables(mirror, update, start,
+ hmm->hole.start);
+ start = hmm->hole.end;
+ } else if (start < hmm->hole.end && start >= hmm->hole.start) {
+ start = hmm->hole.end;
+ }
+ if (end <= start)
+ return;
+
+ cli = container_of(hmm, struct nouveau_cli, hmm);
+ mutex_lock(&hmm->mutex);
+ nvif_vmm_hmm_unmap(&cli->vmm.vmm, start, (end - start) >> PAGE_SHIFT);
+ mutex_unlock(&hmm->mutex);
}
static const struct hmm_mirror_ops nouveau_hmm_mirror_ops = {
@@ -254,6 +279,8 @@ static const struct hmm_mirror_ops nouveau_hmm_mirror_ops =
{
void
nouveau_hmm_fini(struct nouveau_cli *cli)
{
+ struct nouveau_hmm *hmm = &cli->hmm;
+
if (!cli->hmm.enabled)
return;
@@ -262,6 +289,7 @@ nouveau_hmm_fini(struct nouveau_cli *cli)
nvif_object_fini(&cli->hmm.rpfb);
hmm_mirror_unregister(&cli->hmm.mirror);
+ nvif_vmm_hmm_fini(&cli->vmm.vmm, hmm->hole.start, hmm->hole.end);
nouveau_vmm_sync_pagetables(&cli->hmm.mirror, HMM_UPDATE_INVALIDATE,
PAGE_SIZE, TASK_SIZE);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_hmm.h
b/drivers/gpu/drm/nouveau/nouveau_hmm.h
index 47f31cf8ac56..bc68dcf0748b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hmm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_hmm.h
@@ -33,6 +33,7 @@
#if defined(CONFIG_HMM_MIRROR) && defined(CONFIG_DEVICE_PRIVATE)
struct nouveau_hmm {
+ struct nouveau_vmm_hole hole;
struct nvif_object rpfb;
struct nvif_notify pending;
struct task_struct *task;
diff --git a/drivers/gpu/drm/nouveau/nouveau_vmm.c
b/drivers/gpu/drm/nouveau/nouveau_vmm.c
index f5371d96b003..8e6c47a99edb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vmm.c
@@ -115,6 +115,89 @@ nouveau_vma_new(struct nouveau_bo *nvbo, struct
nouveau_vmm *vmm,
return ret;
}
+static int
+vmm_hole_fault(struct vm_fault *vmf)
+{
+ return VM_FAULT_SIGBUS;
+}
+
+static void
+vmm_hole_open(struct vm_area_struct *vma)
+{
+ struct nouveau_cli *cli = vma->vm_private_data;
+ struct nouveau_vmm_hole *hole = &cli->hmm.hole;
+
+ /*
+* No need for atomic this happen under mmap_sem write lock. Make sure
+* this assumption holds with a BUG_ON()
+*/
+ BUG_ON(down_read_trylock(&vma->vm_mm->mmap_sem));
+ hole->count++;
+}
+
+static void
+vmm_hole_close(struct vm_area_struct *vma)
+{
+ struct nouveau_cli *cli = vma->vm_private_data;
+ struct nouveau_vmm_hole *hole = &cli->hmm.hole;
+
+ /*
+* No need for atomic this happen under mmap_sem write lock with one
+* exception when a process is being kill (from do_exit()). For that
+* reasons we don't test with BUG_ON().
+*/
+ if ((--hole->count) <= 0) {
+ nouveau_hmm_fini(cli);
+ hole->vma = NULL;
+ }
+}
+
+static int
+vmm_hole_access(struct vm_area_struct *vma, unsigned long addr,
+ void *buf, int len, int write)
+{
+ return -EIO;
+}
+
+static const struct vm_operations_struct vmm_hole_vm_ops = {
+ .access = vmm_hole_access,
+ .close = vmm_hole_close,
+ .fault = vmm_hole_fault,
+ .open = vmm_hole_open,
+};
+
+int
+nouveau_vmm_hmm(struct nouveau_cli *cli, struct file *file,
+ struct vm_area_struct *vma)
+{
+ struct nouveau_vmm_hole *hole = &cli->hmm.hole;
+ unsigned long size = vma->vm_end - vma->vm_start;
+
[RFC PATCH 04/13] drm/nouveau/mmu/gp100: allow gcc/tex to generate replayable faults
From: Ben Skeggs
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
index 059fafe0e771..8752d9ce4af0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
@@ -315,7 +315,10 @@ gp100_vmm_flush(struct nvkm_vmm *vmm, int depth)
int
gp100_vmm_join(struct nvkm_vmm *vmm, struct nvkm_memory *inst)
{
- const u64 base = BIT_ULL(10) /* VER2 */ | BIT_ULL(11); /* 64KiB */
+ const u64 base = BIT_ULL(4) /* FAULT_REPLAY_TEX */ |
+BIT_ULL(5) /* FAULT_REPLAY_GCC */ |
+BIT_ULL(10) /* VER2 */ |
+BIT_ULL(11) /* 64KiB */;
return gf100_vmm_join_(vmm, inst, base);
}
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 06/13] drm/nouveau/fault/gp100: initial implementation of MaxwellFaultBufferA
From: Ben Skeggs
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvif/class.h | 2 +
drivers/gpu/drm/nouveau/include/nvif/clb069.h | 8 ++
.../gpu/drm/nouveau/include/nvkm/engine/fault.h| 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 6 +
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/fault/Kbuild | 4 +
drivers/gpu/drm/nouveau/nvkm/engine/fault/base.c | 116 ++
drivers/gpu/drm/nouveau/nvkm/engine/fault/gp100.c | 61 +
drivers/gpu/drm/nouveau/nvkm/engine/fault/priv.h | 29 +
drivers/gpu/drm/nouveau/nvkm/engine/fault/user.c | 136 +
drivers/gpu/drm/nouveau/nvkm/engine/fault/user.h | 7 ++
11 files changed, 371 insertions(+)
create mode 100644 drivers/gpu/drm/nouveau/include/nvif/clb069.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fault/base.c
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fault/gp100.c
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fault/priv.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fault/user.c
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fault/user.h
diff --git a/drivers/gpu/drm/nouveau/include/nvif/class.h
b/drivers/gpu/drm/nouveau/include/nvif/class.h
index a7c5bf572788..98ac250670b7 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/class.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/class.h
@@ -52,6 +52,8 @@
#define NV04_DISP /* cl0046.h */ 0x0046
+#define MAXWELL_FAULT_BUFFER_A/* clb069.h */ 0xb069
+
#define NV03_CHANNEL_DMA /* cl506b.h */ 0x006b
#define NV10_CHANNEL_DMA /* cl506b.h */ 0x006e
#define NV17_CHANNEL_DMA /* cl506b.h */ 0x176e
diff --git a/drivers/gpu/drm/nouveau/include/nvif/clb069.h
b/drivers/gpu/drm/nouveau/include/nvif/clb069.h
new file mode 100644
index ..b0d509fd8631
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/include/nvif/clb069.h
@@ -0,0 +1,8 @@
+#ifndef __NVIF_CLB069_H__
+#define __NVIF_CLB069_H__
+
+struct nvb069_vn {
+};
+
+#define NVB069_VN_NTFY_FAULT 0x00
+#endif
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h
b/drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h
index 398ca5a02eee..08893f13e2f9 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h
@@ -1,4 +1,5 @@
#ifndef __NVKM_FAULT_H__
#define __NVKM_FAULT_H__
#include
+int gp100_fault_new(struct nvkm_device *, int, struct nvkm_engine **);
#endif
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 2fe862ac0d95..ee67caf95a4e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2184,6 +2184,7 @@ nv130_chipset = {
.ce[5] = gp100_ce_new,
.dma = gf119_dma_new,
.disp = gp100_disp_new,
+ .fault = gp100_fault_new,
.fifo = gp100_fifo_new,
.gr = gp100_gr_new,
.sw = gf100_sw_new,
@@ -2217,6 +2218,7 @@ nv132_chipset = {
.ce[3] = gp102_ce_new,
.disp = gp102_disp_new,
.dma = gf119_dma_new,
+ .fault = gp100_fault_new,
.fifo = gp100_fifo_new,
.gr = gp102_gr_new,
.nvdec = gp102_nvdec_new,
@@ -2252,6 +2254,7 @@ nv134_chipset = {
.ce[3] = gp102_ce_new,
.disp = gp102_disp_new,
.dma = gf119_dma_new,
+ .fault = gp100_fault_new,
.fifo = gp100_fifo_new,
.gr = gp102_gr_new,
.nvdec = gp102_nvdec_new,
@@ -2287,6 +2290,7 @@ nv136_chipset = {
.ce[3] = gp102_ce_new,
.disp = gp102_disp_new,
.dma = gf119_dma_new,
+ .fault = gp100_fault_new,
.fifo = gp100_fifo_new,
.gr = gp102_gr_new,
.nvdec = gp102_nvdec_new,
@@ -2322,6 +2326,7 @@ nv137_chipset = {
.ce[3] = gp102_ce_new,
.disp = gp102_disp_new,
.dma = gf119_dma_new,
+ .fault = gp100_fault_new,
.fifo = gp100_fifo_new,
.gr = gp107_gr_new,
.nvdec = gp102_nvdec_new,
@@ -2382,6 +2387,7 @@ nv13b_chipset = {
.top = gk104_top_new,
.ce[2] = gp102_ce_new,
.dma = gf119_dma_new,
+ .fault = gp100_fault_new,
.fifo = gp10b_fifo_new,
.gr = gp10b_gr_new,
.sw = gf100_sw_new,
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
index 17adcb4e8854..5eee439f615c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
@@ -276,6 +276,7 @@ nvkm_udevice_child_get(struct nvkm_object *object, int
index,
struct nvkm_device *device = udev->device;
struct nvkm_engine *engine;
[RFC PATCH 11/13] drm/nouveau: add HMM area creation user interface
From: Jérôme Glisse
User API to create HMM area.
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 9 +
drivers/gpu/drm/nouveau/include/nvif/vmm.h | 2 +
drivers/gpu/drm/nouveau/nvif/vmm.c | 51 ++
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c | 39
4 files changed, 101 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index 2c24817ca533..0383864b033b 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -16,6 +16,8 @@ struct nvif_vmm_v0 {
#define NVIF_VMM_V0_UNMAP 0x04
#define NVIF_VMM_V0_HMM_MAP0x05
#define NVIF_VMM_V0_HMM_UNMAP 0x06
+#define NVIF_VMM_V0_HMM_INIT 0x07
+#define NVIF_VMM_V0_HMM_FINI 0x08
struct nvif_vmm_page_v0 {
__u8 version;
@@ -78,4 +80,11 @@ struct nvif_vmm_hmm_unmap_v0 {
__u64 addr;
__u64 npages;
};
+
+struct nvif_vmm_hmm_v0 {
+ __u8 version;
+ __u8 pad01[7];
+ __u64 start;
+ __u64 end;
+};
#endif
diff --git a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
index c5e4adaa0e3c..f11f8c510ebd 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
@@ -39,6 +39,8 @@ void nvif_vmm_put(struct nvif_vmm *, struct nvif_vma *);
int nvif_vmm_map(struct nvif_vmm *, u64 addr, u64 size, void *argv, u32 argc,
struct nvif_mem *, u64 offset);
int nvif_vmm_unmap(struct nvif_vmm *, u64);
+int nvif_vmm_hmm_init(struct nvif_vmm *vmm, u64 hstart, u64 hend);
+void nvif_vmm_hmm_fini(struct nvif_vmm *vmm, u64 hstart, u64 hend);
int nvif_vmm_hmm_map(struct nvif_vmm *vmm, u64 addr, u64 npages, u64 *pages);
int nvif_vmm_hmm_unmap(struct nvif_vmm *vmm, u64 addr, u64 npages);
#endif
diff --git a/drivers/gpu/drm/nouveau/nvif/vmm.c
b/drivers/gpu/drm/nouveau/nvif/vmm.c
index 27a7b95b4e9c..788e02e47750 100644
--- a/drivers/gpu/drm/nouveau/nvif/vmm.c
+++ b/drivers/gpu/drm/nouveau/nvif/vmm.c
@@ -32,6 +32,57 @@ nvif_vmm_unmap(struct nvif_vmm *vmm, u64 addr)
sizeof(struct nvif_vmm_unmap_v0));
}
+int
+nvif_vmm_hmm_init(struct nvif_vmm *vmm, u64 hstart, u64 hend)
+{
+ struct nvif_vmm_hmm_v0 args;
+ int ret;
+
+ if (hstart > PAGE_SIZE) {
+ args.version = 0;
+ args.start = PAGE_SIZE;
+ args.end = hstart;
+ ret = nvif_object_mthd(&vmm->object, NVIF_VMM_V0_HMM_INIT,
+ &args, sizeof(args));
+ if (ret)
+ return ret;
+ }
+
+ args.version = 0;
+ args.start = hend;
+ args.end = TASK_SIZE;
+ ret = nvif_object_mthd(&vmm->object, NVIF_VMM_V0_HMM_INIT,
+ &args, sizeof(args));
+ if (ret && hstart > PAGE_SIZE) {
+ args.version = 0;
+ args.start = PAGE_SIZE;
+ args.end = hstart;
+ nvif_object_mthd(&vmm->object, NVIF_VMM_V0_HMM_FINI,
+&args, sizeof(args));
+ }
+ return ret;
+}
+
+void
+nvif_vmm_hmm_fini(struct nvif_vmm *vmm, u64 hstart, u64 hend)
+{
+ struct nvif_vmm_hmm_v0 args;
+
+ if (hstart > PAGE_SIZE) {
+ args.version = 0;
+ args.start = PAGE_SIZE;
+ args.end = hstart;
+ nvif_object_mthd(&vmm->object, NVIF_VMM_V0_HMM_FINI,
+&args, sizeof(args));
+ }
+
+ args.version = 0;
+ args.start = hend;
+ args.end = TASK_SIZE;
+ nvif_object_mthd(&vmm->object, NVIF_VMM_V0_HMM_FINI,
+&args, sizeof(args));
+}
+
int
nvif_vmm_hmm_map(struct nvif_vmm *vmm, u64 addr, u64 npages, u64 *pages)
{
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
index 739f2af02552..34e00aa73fd0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
@@ -274,6 +274,43 @@ nvkm_uvmm_mthd_page(struct nvkm_uvmm *uvmm, void *argv,
u32 argc)
return 0;
}
+static int
+nvkm_uvmm_mthd_hmm_init(struct nvkm_uvmm *uvmm, void *argv, u32 argc)
+{
+ union {
+ struct nvif_vmm_hmm_v0 v0;
+ } *args = argv;
+ struct nvkm_vmm *vmm = uvmm->vmm;
+ struct nvkm_vma *vma;
+ int ret = -ENOSYS;
+
+ if ((ret = nvif_unpack(ret, &argv, &argc, args->v0, 0, 0, false)))
+ return ret;
+
+ mutex_lock(&vmm->mutex);
+ ret = nvkm_vmm_hmm_init(vmm, args->v0.start, args->v
[RFC PATCH 09/13] drm/nouveau: add SVM through HMM support to nouveau client
From: Jérôme Glisse
SVM (Share Virtual Memory) through HMM (Heterogeneous Memory Management)
to nouveau client. SVM means that any valid pointer (private anonymous,
share memory or mmap of regular file) on the CPU is also valid on the
GPU. To achieve SVM with nouveau we use HMM kernel infrastructure.
There is one nouveau client object created each time the device file is
open by a process, this is best we can achieve. Idealy we would like an
object that exist for each process address space but there is no such
thing in the kernel.
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/Kbuild| 3 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
drivers/gpu/drm/nouveau/nouveau_drv.h | 3 +
drivers/gpu/drm/nouveau/nouveau_hmm.c | 339 ++
drivers/gpu/drm/nouveau/nouveau_hmm.h | 63 +++
5 files changed, 413 insertions(+)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_hmm.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_hmm.h
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index 9c0c650655e9..8e61e118ccfe 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -35,6 +35,9 @@ nouveau-y += nouveau_prime.o
nouveau-y += nouveau_sgdma.o
nouveau-y += nouveau_ttm.o
nouveau-y += nouveau_vmm.o
+ifdef CONFIG_HMM_MIRROR
+nouveau-$(CONFIG_DEVICE_PRIVATE) += nouveau_hmm.o
+endif
# DRM - modesetting
nouveau-$(CONFIG_DRM_NOUVEAU_BACKLIGHT) += nouveau_backlight.o
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3e293029e3a6..e67b08ba8b80 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -167,6 +167,7 @@ nouveau_cli_work(struct work_struct *w)
static void
nouveau_cli_fini(struct nouveau_cli *cli)
{
+ nouveau_hmm_fini(cli);
nouveau_cli_work_flush(cli, true);
usif_client_fini(cli);
nouveau_vmm_fini(&cli->vmm);
@@ -965,6 +966,10 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file
*fpriv)
list_add(&cli->head, &drm->clients);
mutex_unlock(&drm->client.mutex);
+ ret = nouveau_hmm_init(cli);
+ if (ret)
+ return ret;
+
done:
if (ret && cli) {
nouveau_cli_fini(cli);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 96f6bd8aee5d..75c741d5125c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -65,6 +65,7 @@ struct platform_device;
#include "nouveau_fence.h"
#include "nouveau_bios.h"
#include "nouveau_vmm.h"
+#include "nouveau_hmm.h"
struct nouveau_drm_tile {
struct nouveau_fence *fence;
@@ -104,6 +105,8 @@ struct nouveau_cli {
struct list_head notifys;
char name[32];
+ struct nouveau_hmm hmm;
+
struct work_struct work;
struct list_head worker;
struct mutex lock;
diff --git a/drivers/gpu/drm/nouveau/nouveau_hmm.c
b/drivers/gpu/drm/nouveau/nouveau_hmm.c
new file mode 100644
index ..a4c6f687f6a8
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/nouveau_hmm.c
@@ -0,0 +1,339 @@
+/*
+ * Copyright (C) 2018 Red Hat All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+ * LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ * OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Author: Jérôme Glisse, Ben Skeggs
+ */
+#include
+#include
+#include "nouveau_hmm.h"
+#include "nouveau_drv.h"
+#include "nouveau_bo.h"
+#include
+#include
+#include
+
+struct fault_entry {
+ u32 instlo;
+ u32 insthi;
+ u32 addrlo;
+ u32 addrhi;
+ u32 timelo;
+ u32 timehi;
+ u32 rsvd;
+ u32 info;
+};
+
+#define NV_PFAULT_ACCESS_R 0 /* read */
+#define NV_PFAULT_ACCESS_W 1 /* write */
+#define NV_PFAULT_ACCESS_A 2 /* atomic */
+#define NV_PFAULT_ACCESS_P 3 /* prefetch */
+
+static inline u64
+fault_entry_addr(const struct fau
[RFC PATCH 10/13] drm/nouveau: add HMM area creation
From: Jérôme Glisse
HMM area is a virtual address range under HMM control, GPU access inside
such range is like CPU access. For thing to work properly HMM range should
cover everything except a reserved range for GEM buffer object.
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 63 +++
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
index 96671987ce53..ef4b839932fa 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
@@ -1540,6 +1540,69 @@ nvkm_vmm_get_locked(struct nvkm_vmm *vmm, bool getref,
bool mapref, bool sparse,
return 0;
}
+int
+nvkm_vmm_hmm_init(struct nvkm_vmm *vmm, u64 start, u64 end,
+ struct nvkm_vma **pvma)
+{
+ struct nvkm_vma *vma = NULL, *tmp;
+ struct rb_node *node;
+
+ /* Locate smallest block that can possibly satisfy the allocation. */
+ node = vmm->free.rb_node;
+ while (node) {
+ struct nvkm_vma *this = rb_entry(node, typeof(*this), tree);
+
+ if (this->addr <= start && (this->addr + this->size) >= end) {
+ rb_erase(&this->tree, &vmm->free);
+ vma = this;
+ break;
+ }
+ node = node->rb_left;
+ }
+
+ if (vma == NULL) {
+ return -EINVAL;
+ }
+
+ if (start != vma->addr) {
+ if (!(tmp = nvkm_vma_tail(vma, vma->size + vma->addr - start)))
{
+ nvkm_vmm_put_region(vmm, vma);
+ return -ENOMEM;
+ }
+ nvkm_vmm_free_insert(vmm, vma);
+ vma = tmp;
+ }
+
+ if (end < (vma->addr + vma->size)) {
+ if (!(tmp = nvkm_vma_tail(vma, vma->size + vma->addr - end))) {
+ nvkm_vmm_put_region(vmm, vma);
+ return -ENOMEM;
+ }
+ nvkm_vmm_free_insert(vmm, tmp);
+ }
+
+ vma->mapref = false;
+ vma->sparse = false;
+ vma->page = NVKM_VMA_PAGE_NONE;
+ vma->refd = NVKM_VMA_PAGE_NONE;
+ vma->used = true;
+ nvkm_vmm_node_insert(vmm, vma);
+ *pvma = vma;
+ return 0;
+}
+
+void
+nvkm_vmm_hmm_fini(struct nvkm_vmm *vmm, u64 start, u64 end)
+{
+ struct nvkm_vma *vma;
+ u64 size = (end - start);
+
+ vma = nvkm_vmm_node_search(vmm, start);
+ if (vma && vma->addr == start && vma->size == size) {
+ nvkm_vmm_put_locked(vmm, vma);
+ }
+}
+
int
nvkm_vmm_get(struct nvkm_vmm *vmm, u8 page, u64 size, struct nvkm_vma **pvma)
{
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
index a630aa2a77e4..04d672a4dccb 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
@@ -165,6 +165,8 @@ int nvkm_vmm_get_locked(struct nvkm_vmm *, bool getref,
bool mapref,
bool sparse, u8 page, u8 align, u64 size,
struct nvkm_vma **pvma);
void nvkm_vmm_put_locked(struct nvkm_vmm *, struct nvkm_vma *);
+int nvkm_vmm_hmm_init(struct nvkm_vmm *, u64, u64, struct nvkm_vma **);
+void nvkm_vmm_hmm_fini(struct nvkm_vmm *, u64, u64);
void nvkm_vmm_unmap_locked(struct nvkm_vmm *, struct nvkm_vma *);
void nvkm_vmm_unmap_region(struct nvkm_vmm *vmm, struct nvkm_vma *vma);
void nvkm_vmm_hmm_map(struct nvkm_vmm *vmm, u64 addr, u64 npages, u64 *pages);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 01/13] drm/nouveau/vmm: enable page table iterator over non populated range
From: Jérôme Glisse
This patch modify the page table iterator to support empty range when
unmaping a range (ie when it is not trying to populate the range).
Signed-off-by: Jérôme Glisse
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 75 ++-
1 file changed, 51 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
index 93946dcee319..20d31526ba8f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
@@ -75,6 +75,7 @@ struct nvkm_vmm_iter {
struct nvkm_vmm *vmm;
u64 cnt;
u16 max, lvl;
+ u64 start, addr;
u32 pte[NVKM_VMM_LEVELS_MAX];
struct nvkm_vmm_pt *pt[NVKM_VMM_LEVELS_MAX];
int flush;
@@ -485,6 +486,23 @@ nvkm_vmm_ref_swpt(struct nvkm_vmm_iter *it, struct
nvkm_vmm_pt *pgd, u32 pdei)
return true;
}
+static inline u64
+nvkm_vmm_iter_addr(const struct nvkm_vmm_iter *it,
+ const struct nvkm_vmm_desc *desc)
+{
+ int max = it->max;
+ u64 addr;
+
+ /* Reconstruct address */
+ addr = it->pte[max--];
+ do {
+ addr = addr << desc[max].bits;
+ addr |= it->pte[max];
+ } while (max--);
+
+ return addr;
+}
+
static inline u64
nvkm_vmm_iter(struct nvkm_vmm *vmm, const struct nvkm_vmm_page *page,
u64 addr, u64 size, const char *name, bool ref,
@@ -494,21 +512,23 @@ nvkm_vmm_iter(struct nvkm_vmm *vmm, const struct
nvkm_vmm_page *page,
{
const struct nvkm_vmm_desc *desc = page->desc;
struct nvkm_vmm_iter it;
- u64 bits = addr >> page->shift;
+ u64 addr_bits = addr >> page->shift;
it.page = page;
it.desc = desc;
it.vmm = vmm;
it.cnt = size >> page->shift;
it.flush = NVKM_VMM_LEVELS_MAX;
+ it.start = it.addr = addr;
/* Deconstruct address into PTE indices for each mapping level. */
for (it.lvl = 0; desc[it.lvl].bits; it.lvl++) {
- it.pte[it.lvl] = bits & ((1 << desc[it.lvl].bits) - 1);
- bits >>= desc[it.lvl].bits;
+ it.pte[it.lvl] = addr_bits & ((1 << desc[it.lvl].bits) - 1);
+ addr_bits >>= desc[it.lvl].bits;
}
it.max = --it.lvl;
it.pt[it.max] = vmm->pd;
+ addr_bits = addr >> page->shift;
it.lvl = 0;
TRA(&it, "%s: %016llx %016llx %d %lld PTEs", name,
@@ -521,7 +541,8 @@ nvkm_vmm_iter(struct nvkm_vmm *vmm, const struct
nvkm_vmm_page *page,
const int type = desc->type == SPT;
const u32 pten = 1 << desc->bits;
const u32 ptei = it.pte[0];
- const u32 ptes = min_t(u64, it.cnt, pten - ptei);
+ u32 ptes = min_t(u64, it.cnt, pten - ptei);
+ u64 tmp;
/* Walk down the tree, finding page tables for each level. */
for (; it.lvl; it.lvl--) {
@@ -529,9 +550,14 @@ nvkm_vmm_iter(struct nvkm_vmm *vmm, const struct
nvkm_vmm_page *page,
struct nvkm_vmm_pt *pgd = pgt;
/* Software PT. */
- if (ref && NVKM_VMM_PDE_INVALID(pgd->pde[pdei])) {
- if (!nvkm_vmm_ref_swpt(&it, pgd, pdei))
- goto fail;
+ if (NVKM_VMM_PDE_INVALID(pgd->pde[pdei])) {
+ if (ref) {
+ if (!nvkm_vmm_ref_swpt(&it, pgd, pdei))
+ goto fail;
+ } else {
+ it.pte[it.lvl] += 1;
+ goto next;
+ }
}
it.pt[it.lvl - 1] = pgt = pgd->pde[pdei];
@@ -545,9 +571,16 @@ nvkm_vmm_iter(struct nvkm_vmm *vmm, const struct
nvkm_vmm_page *page,
if (!nvkm_vmm_ref_hwpt(&it, pgd, pdei))
goto fail;
}
+
+ /* With HMM we might walk down un-populated range */
+ if (!pgt) {
+ it.pte[it.lvl] += 1;
+ goto next;
+ }
}
/* Handle PTE updates. */
+ it.addr = nvkm_vmm_iter_addr(&it, desc) << PAGE_SHIFT;
if (!REF_PTES || REF_PTES(&it, ptei, ptes)) {
struct nvkm_mmu_pt *pt = pgt->pt[type];
if (MAP_PTES || CLR_PTES) {
@@ -558,32 +591,26 @@ nvkm_vmm_iter(struct nvkm_vmm *vmm, const struct
nvkm_vmm_page *page,
nvkm_vmm_flush_mark(&it);
}
}
+ it.pte[it.lvl] += ptes;
+next:
[RFC PATCH 02/13] drm/nouveau/core/memory: add some useful accessor macros
From: Jérôme Glisse
Adds support for 64-bits read.
Signed-off-by: Jérôme Glisse
---
drivers/gpu/drm/nouveau/include/nvkm/core/memory.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
b/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
index 05f505de0075..d1a886c4d2d9 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
@@ -82,6 +82,14 @@ void nvkm_memory_tags_put(struct nvkm_memory *, struct
nvkm_device *,
nvkm_wo32((o), __a + 4, upper_32_bits(__d)); \
} while(0)
+#define nvkm_ro64(o,a) ({
\
+ u64 _data; \
+ _data = nvkm_ro32((o), (a) + 4); \
+ _data = _data << 32; \
+ _data |= nvkm_ro32((o), (a) + 0); \
+ _data; \
+})
+
#define nvkm_fill(t,s,o,a,d,c) do {
\
u64 _a = (a), _c = (c), _d = (d), _o = _a >> s, _s = _c << s; \
u##t __iomem *_m = nvkm_kmap(o); \
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 03/13] drm/nouveau/core: define engine for handling replayable faults
From: Ben Skeggs
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/include/nvkm/core/device.h | 3 +++
drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h | 4
drivers/gpu/drm/nouveau/nvkm/core/subdev.c | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/Kbuild | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/device/priv.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/fault/Kbuild| 0
7 files changed, 12 insertions(+)
create mode 100644 drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fault/Kbuild
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
b/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
index 560265b15ec2..de3d2566ee4d 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
@@ -42,6 +42,7 @@ enum nvkm_devidx {
NVKM_ENGINE_CIPHER,
NVKM_ENGINE_DISP,
NVKM_ENGINE_DMAOBJ,
+ NVKM_ENGINE_FAULT,
NVKM_ENGINE_FIFO,
NVKM_ENGINE_GR,
NVKM_ENGINE_IFB,
@@ -147,6 +148,7 @@ struct nvkm_device {
struct nvkm_engine *cipher;
struct nvkm_disp *disp;
struct nvkm_dma *dma;
+ struct nvkm_engine *fault;
struct nvkm_fifo *fifo;
struct nvkm_gr *gr;
struct nvkm_engine *ifb;
@@ -218,6 +220,7 @@ struct nvkm_device_chip {
int (*cipher )(struct nvkm_device *, int idx, struct nvkm_engine **);
int (*disp)(struct nvkm_device *, int idx, struct nvkm_disp **);
int (*dma )(struct nvkm_device *, int idx, struct nvkm_dma **);
+ int (*fault )(struct nvkm_device *, int idx, struct nvkm_engine **);
int (*fifo)(struct nvkm_device *, int idx, struct nvkm_fifo **);
int (*gr )(struct nvkm_device *, int idx, struct nvkm_gr **);
int (*ifb )(struct nvkm_device *, int idx, struct nvkm_engine **);
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h
b/drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h
new file mode 100644
index ..398ca5a02eee
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/include/nvkm/engine/fault.h
@@ -0,0 +1,4 @@
+#ifndef __NVKM_FAULT_H__
+#define __NVKM_FAULT_H__
+#include
+#endif
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
b/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
index a134d225f958..0d50b2206da2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
@@ -63,6 +63,7 @@ nvkm_subdev_name[NVKM_SUBDEV_NR] = {
[NVKM_ENGINE_CIPHER ] = "cipher",
[NVKM_ENGINE_DISP] = "disp",
[NVKM_ENGINE_DMAOBJ ] = "dma",
+ [NVKM_ENGINE_FAULT ] = "fault",
[NVKM_ENGINE_FIFO] = "fifo",
[NVKM_ENGINE_GR ] = "gr",
[NVKM_ENGINE_IFB ] = "ifb",
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/Kbuild
b/drivers/gpu/drm/nouveau/nvkm/engine/Kbuild
index 78571e8b01c5..3aa90a6d5392 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/Kbuild
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/Kbuild
@@ -7,6 +7,7 @@ include $(src)/nvkm/engine/cipher/Kbuild
include $(src)/nvkm/engine/device/Kbuild
include $(src)/nvkm/engine/disp/Kbuild
include $(src)/nvkm/engine/dma/Kbuild
+include $(src)/nvkm/engine/fault/Kbuild
include $(src)/nvkm/engine/fifo/Kbuild
include $(src)/nvkm/engine/gr/Kbuild
include $(src)/nvkm/engine/mpeg/Kbuild
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 05cd674326a6..2fe862ac0d95 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2466,6 +2466,7 @@ nvkm_device_engine(struct nvkm_device *device, int index)
_(CIPHER , device->cipher , device->cipher);
_(DISP , device->disp, &device->disp->engine);
_(DMAOBJ , device->dma , &device->dma->engine);
+ _(FAULT , device->fault , device->fault);
_(FIFO , device->fifo, &device->fifo->engine);
_(GR , device->gr , &device->gr->engine);
_(IFB, device->ifb , device->ifb);
@@ -2919,6 +2920,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
_(NVKM_ENGINE_CIPHER , cipher);
_(NVKM_ENGINE_DISP, disp);
_(NVKM_ENGINE_DMAOBJ , dma);
+ _(NVKM_ENGINE_FAULT ,fault);
_(NVKM_ENGINE_FIFO, fifo);
_(NVKM_ENGINE_GR , gr);
_(NVKM_ENGINE_IFB , ifb);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/priv.h
b/drivers/gpu/drm/nouveau/nvkm/engine/device/priv.h
index 08d0bf605722..3be45ac6e58d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/priv.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#i
[RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau
From: Jérôme Glisse (mm is cced just to allow exposure of device driver work without ccing a long list of peoples. I do not think there is anything usefull to discuss from mm point of view but i might be wrong, so just for the curious :)). git://people.freedesktop.org/~glisse/linux branch: nouveau-hmm-v00 https://cgit.freedesktop.org/~glisse/linux/log/?h=nouveau-hmm-v00 This patchset adds SVM (Share Virtual Memory) using HMM (Heterogeneous Memory Management) to the nouveau driver. SVM means that GPU threads spawn by GPU driver for a specific user process can access any valid CPU address in that process. A valid pointer is a pointer inside an area coming from mmap of private, share or regular file. Pointer to a mmap of a device file or special file are not supported. This is an RFC for few reasons technical reasons listed below and also because we are still working on a proper open source userspace (namely a OpenCL 2.0 for nouveau inside mesa). Open source userspace being a requirement for the DRM subsystem. I pushed in [1] a simple standalone program that can be use to test SVM through HMM with nouveau. I expect we will have a somewhat working userspace in the coming weeks, work being well underway and some patches have already been posted on mesa mailing list. They are two aspect that need to sorted before this can be considered ready. First we want to decide how to update GPU page table from HMM. In this patchset i added new methods to vmm to allow GPU page table to be updated without nvkm_memory or nvkm_vma object (see patch 7 and 8 special mapping method for HMM). It just take an array of pages and flags. It allow for both system and device private memory to be interleaved. The second aspect is how to create a HMM enabled channel. Channel is a term use for NVidia GPU command queue, each process using nouveau have at least one channel, it can have multiple channels. They are not created by process directly but rather by device driver backend of common library like OpenGL, OpenCL or Vulkan. They are work underway to revamp nouveau channel creation with a new userspace API. So we might want to delay upstreaming until this lands. We can stil discuss one aspect specific to HMM here namely the issue around GEM objects used for some specific part of the GPU. Some engine inside the GPU (engine are a GPU block like the display block which is responsible of scaning memory to send out a picture through some connector for instance HDMI or DisplayPort) can only access memory with virtual address below (1 << 40). To accomodate those we need to create a "hole" inside the process address space. This patchset have a hack for that (patch 13 HACK FOR HMM AREA), it reserves a range of device file offset so that process can mmap this range with PROT_NONE to create a hole (process must make sure the hole is below 1 << 40). I feel un-easy of doing it this way but maybe it is ok with other folks. Note that this patchset do not show usage of device private memory as it depends on other architectural changes to nouveau. However it is very easy to add it with some gross hack so if people would like to see it i can also post an RFC for that. As a preview it only adds two new ioctl which allow userspace to ask for migration of a range of virtual address, expectation is that the userspace library will know better where to place thing and kernel will try to sastify this (with no guaranty, it is a best effort). As usual comments and questions are welcome. Cheers, Jérôme Glisse [1] https://cgit.freedesktop.org/~glisse/moche Ben Skeggs (4): drm/nouveau/core: define engine for handling replayable faults drm/nouveau/mmu/gp100: allow gcc/tex to generate replayable faults drm/nouveau/mc/gp100-: handle replayable fault interrupt drm/nouveau/fault/gp100: initial implementation of MaxwellFaultBufferA Jérôme Glisse (9): drm/nouveau/vmm: enable page table iterator over non populated range drm/nouveau/core/memory: add some useful accessor macros drm/nouveau: special mapping method for HMM drm/nouveau: special mapping method for HMM (user interface) drm/nouveau: add SVM through HMM support to nouveau client drm/nouveau: add HMM area creation drm/nouveau: add HMM area creation user interface drm/nouveau: HMM area creation helpers for nouveau client drm/nouveau: HACK FOR HMM AREA drivers/gpu/drm/nouveau/Kbuild | 3 + drivers/gpu/drm/nouveau/include/nvif/class.h | 2 + drivers/gpu/drm/nouveau/include/nvif/clb069.h | 8 + drivers/gpu/drm/nouveau/include/nvif/if000c.h | 26 ++ drivers/gpu/drm/nouveau/include/nvif/vmm.h | 4 + drivers/gpu/drm/nouveau/include/nvkm/core/device.h | 3 + drivers/gpu/drm/nouveau/include/nvkm/core/memory.h | 8 + .../gpu/drm/nouveau/include/nvkm/engine/fault.h| 5 + drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h | 10 + drivers/gpu/drm/nouveau/nouveau_drm.c | 5 + drivers/gpu/drm/nouveau/nouveau_drv.
[RFC PATCH 05/13] drm/nouveau/mc/gp100-: handle replayable fault interrupt
From: Ben Skeggs
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp100.c | 20 +++-
drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp10b.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mc/priv.h | 2 ++
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp100.c
index 7321ad3758c3..9ab5bfe1e588 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp100.c
@@ -75,10 +75,28 @@ gp100_mc_intr_mask(struct nvkm_mc *base, u32 mask, u32 intr)
spin_unlock_irqrestore(&mc->lock, flags);
}
+const struct nvkm_mc_map
+gp100_mc_intr[] = {
+ { 0x0400, NVKM_ENGINE_DISP },
+ { 0x0100, NVKM_ENGINE_FIFO },
+ { 0x0200, NVKM_ENGINE_FAULT },
+ { 0x4000, NVKM_SUBDEV_IBUS },
+ { 0x1000, NVKM_SUBDEV_BUS },
+ { 0x0800, NVKM_SUBDEV_FB },
+ { 0x0200, NVKM_SUBDEV_LTC },
+ { 0x0100, NVKM_SUBDEV_PMU },
+ { 0x0020, NVKM_SUBDEV_GPIO },
+ { 0x0020, NVKM_SUBDEV_I2C },
+ { 0x0010, NVKM_SUBDEV_TIMER },
+ { 0x0004, NVKM_SUBDEV_THERM },
+ { 0x2000, NVKM_SUBDEV_FB },
+ {},
+};
+
static const struct nvkm_mc_func
gp100_mc = {
.init = nv50_mc_init,
- .intr = gk104_mc_intr,
+ .intr = gp100_mc_intr,
.intr_unarm = gp100_mc_intr_unarm,
.intr_rearm = gp100_mc_intr_rearm,
.intr_mask = gp100_mc_intr_mask,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp10b.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp10b.c
index 2283e3b74277..ff8629de97d6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/gp10b.c
@@ -34,7 +34,7 @@ gp10b_mc_init(struct nvkm_mc *mc)
static const struct nvkm_mc_func
gp10b_mc = {
.init = gp10b_mc_init,
- .intr = gk104_mc_intr,
+ .intr = gp100_mc_intr,
.intr_unarm = gp100_mc_intr_unarm,
.intr_rearm = gp100_mc_intr_rearm,
.intr_mask = gp100_mc_intr_mask,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/priv.h
b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/priv.h
index 8869d79c2b59..d9e3691d45b7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mc/priv.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mc/priv.h
@@ -57,4 +57,6 @@ int gp100_mc_new_(const struct nvkm_mc_func *, struct
nvkm_device *, int,
extern const struct nvkm_mc_map gk104_mc_intr[];
extern const struct nvkm_mc_map gk104_mc_reset[];
+
+extern const struct nvkm_mc_map gp100_mc_intr[];
#endif
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when run under Wine
https://bugs.freedesktop.org/show_bug.cgi?id=105426 --- Comment #2 from Józef Kucia --- Please attach the full terminal output. -- 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 105423] Unable to unbind my 2nd GPU (Rx580)
https://bugs.freedesktop.org/show_bug.cgi?id=105423 --- Comment #2 from Max --- Thanks to Nick Sarnie on Discord, he found that disable completely DC fix the issue. I fix it with "amdgpu.dc=0" in my grub.conf -- 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 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when run under Wine
https://bugs.freedesktop.org/show_bug.cgi?id=105426 --- Comment #1 from i...@yahoo.com --- The problem appears with Wine-3.0rc1 or newer (including Wine-3.3). It does not appear with Wine-2.22. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4
On Thu, 2018-03-08 at 09:22 +0200, Jani Nikula wrote:
> On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote:
> >
> > From: Matt Atwood
> >
> > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme
> > from 8
> > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> > receiver capabilities. For panels that use this new feature wait
> > interval
> > would be increased by 512 ms, when spec is max 16 ms. This behavior
> > is
> > described in table 2-158 of DP 1.4 spec address eh.
> >
> > With the introduction of DP 1.4 spec main link clock recovery was
> > standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL
> > value.
> >
> > To avoid breaking panels that are not spec compiant we now warn on
> > invalid values.
> >
> > V2: commit title/message, masking all 7 bits, warn on out of spec
> > values.
> > V3: commit message, make link train clock recovery follow DP 1.4
> > spec.
> > V4: style changes
> > V5: typo
> >
> > Signed-off-by: Matt Atwood
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 18 ++
> > include/drm/drm_dp_helper.h | 6 ++
> > 2 files changed, 20 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index adf79be..cdb04c9 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -119,18 +119,28 @@ u8
> > drm_dp_get_adjust_request_pre_emphasis(const u8
> > link_status[DP_LINK_STATUS_SI
> > EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> >
> > void drm_dp_link_train_clock_recovery_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > DP_TRAINING_AUX_RD_MASK;
> > +
> > + if (rd_interval > 4)
> > + DRM_DEBUG_KMS("AUX interval %d, out of range (max
> > 4)", rd_interval);
> \n missing.
will do
>
> >
> > +
> > + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
> > udelay(100);
> > else
> > - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > + mdelay(rd_interval * 4);
> > }
> > EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
> >
> > void drm_dp_link_train_channel_eq_delay(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> > DP_TRAINING_AUX_RD_MASK;
> > +
> > + if (rd_interval > 4)
> > + DRM_DEBUG_KMS("AUX interval %d, out of range (max
> > 4)", rd_interval);
> \n missing.
will do
>
> >
> > +
> > + if (rd_interval == 0)
> > udelay(400);
> > else
> > - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > + mdelay(rd_interval * 4);
> > }
> > EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
> >
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index da58a42..1269ef8 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -64,6 +64,11 @@
> > /* AUX CH addresses */
> > /* DPCD */
> > #define DP_DPCD_REV 0x000
> > +# define DP_REV_10 0x10
> > +# define DP_REV_11 0x11
> > +# define DP_REV_12 0x12
> > +# define DP_REV_13 0x13
> > +# define DP_REV_14 0x14
> I am not sure what good these buy us, but if people think they're the
> way to go, then so be it. Just bear in mind that per spec, "The DPCD
> revision number does not necessarily match the DisplayPort version
> number." so "DP_REV" doesn't actually mean *DP* revision.
>
>
> BR,
> Jani.
you're right likely a better name is DPCD_REV_XX. I think we sill want
to base the main-link clock recovery on time on this value. Next
revision will include this naming convention.
>
> >
> >
> > #define DP_MAX_LINK_RATE0x001
> >
> > @@ -118,6 +123,7 @@
> > # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2
> > or higher */
> >
> > #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
> > +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
Rodrigo has shown me a DP 1.2 spec that had this change and conflicts
with my copy so I'll be changing to XXX 1.2
Matt
> >
> > #define DP_ADAPTER_CAP 0x00f /* 1.2
> > */
> > # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: simple: Fix the bus_format for the Ontat panel.
This fixes bad color output. When I was first testing the device I
had the DPI hardware set to 666 mode, but apparently in the refactor
to use the bus_format information from the panel driver, I failed to
actually update the panel.
Signed-off-by: Eric Anholt
Fixes: e8b6f561b2ee ("drm/panel: simple: Add the 7" DPI panel from Adafruit")
Cc: Thierry Reding
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..f9649bded63f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1597,7 +1597,7 @@ static const struct panel_desc ontat_yx700wv03 = {
.width = 154,
.height = 83,
},
- .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
static const struct drm_display_mode ortustech_com43h4m85ulc_mode = {
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.
In the cleanup, I didn't notice that we needed to dereference the
connector for the bus_format. Fix the regression by looking up the
first (and only) connector attached to us, and assume that its
bus_format is what we want. Some day it would be good to have that
part of display_info attached to the bridge, instead.
Signed-off-by: Eric Anholt
Fixes: 7b1298e05310 ("drm/vc4: Switch DPI to using the panel-bridge helper.")
Cc: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_dpi.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index 72c9dbd81d7f..88783e143cc2 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -96,7 +96,6 @@ struct vc4_dpi {
struct platform_device *pdev;
struct drm_encoder *encoder;
- struct drm_connector *connector;
void __iomem *regs;
@@ -164,14 +163,31 @@ static void vc4_dpi_encoder_disable(struct drm_encoder
*encoder)
static void vc4_dpi_encoder_enable(struct drm_encoder *encoder)
{
+ struct drm_device *dev = encoder->dev;
struct drm_display_mode *mode = &encoder->crtc->mode;
struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder);
struct vc4_dpi *dpi = vc4_encoder->dpi;
+ struct drm_connector_list_iter conn_iter;
+ struct drm_connector *connector = NULL, *connector_scan;
u32 dpi_c = DPI_ENABLE | DPI_OUTPUT_ENABLE_MODE;
int ret;
- if (dpi->connector->display_info.num_bus_formats) {
- u32 bus_format = dpi->connector->display_info.bus_formats[0];
+ /* Look up the connector attached to DPI so we can get the
+* bus_format. Ideally the bridge would tell us the
+* bus_format we want, but it doesn't yet, so assume that it's
+* uniform throughout the bridge chain.
+*/
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector_scan, &conn_iter) {
+ if (connector_scan->encoder == encoder) {
+ connector = connector_scan;
+ break;
+ }
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+ if (connector && connector->display_info.num_bus_formats) {
+ u32 bus_format = connector->display_info.bus_formats[0];
switch (bus_format) {
case MEDIA_BUS_FMT_RGB888_1X24:
@@ -199,6 +215,9 @@ static void vc4_dpi_encoder_enable(struct drm_encoder
*encoder)
DRM_ERROR("Unknown media bus format %d\n", bus_format);
break;
}
+ } else {
+ /* Default to 24bit if no connector found. */
+ dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB, DPI_FORMAT);
}
if (mode->flags & DRM_MODE_FLAG_NHSYNC)
@@ -264,7 +283,7 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
return ret;
}
- if (panel)
+ if (panel)
bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI);
return drm_bridge_attach(dpi->encoder, bridge, NULL);
--
2.16.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node
On Fri, Mar 09, 2018 at 04:40:16PM +0100, Sylwester Nawrocki wrote: > The #sound-dai-cells DT property is required to describe link between > the HDMI IP block and the SoC's audio subsystem. > > Signed-off-by: Sylwester Nawrocki > --- > Changes since v2: > - the property has been moved to "Required properties" paragraph, >I didn't add Rob's Reviewed-by due to this change > --- > Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when run under Wine
https://bugs.freedesktop.org/show_bug.cgi?id=105426 Alex Deucher changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Other |Drivers/Gallium/r600 QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] drm: rcar-du: Support interlaced video output through vsp1
Use the newly exposed VSP1 interface to enable interlaced frame support through the VSP1 lif pipelines. Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 5685d5af6998..9854d9deb944 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -248,6 +248,7 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) /* Signal polarities */ value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0) | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0) + | ((mode->flags & DRM_MODE_FLAG_INTERLACE) ? DSMR_ODEV : 0) | DSMR_DIPM_DISP | DSMR_CSPM; rcar_du_crtc_write(rcrtc, DSMR, value); diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 2c260c33840b..5e47daef8bd2 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -178,6 +178,9 @@ static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) }; unsigned int i; + cfg.interlaced = !!(plane->plane.state->crtc->mode.flags + & DRM_MODE_FLAG_INTERLACE); + cfg.src.left = state->state.src.x1 >> 16; cfg.src.top = state->state.src.y1 >> 16; cfg.src.width = drm_rect_width(&state->state.src) >> 16; -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105379] The Witcher: Enhanced Edition under Wine fails to launch
https://bugs.freedesktop.org/show_bug.cgi?id=105379 --- Comment #2 from Matias N. Goldberg --- I'm no mesa dev but could you test with and before bc65dcab3bc48673ff6180afb036561a4b8b1119 ? This might be a dupe of https://bugs.freedesktop.org/show_bug.cgi?id=105339 Unless you're sure your error started happening since b650fc09c3a35ca624aad5fe4b5c34867708f116 -- 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 105339] Deadlock inside glClientWaitSync [Regresion bc65dcab3bc48673ff6180afb036561a4b8b1119]
https://bugs.freedesktop.org/show_bug.cgi?id=105339 Matias N. Goldberg changed: What|Removed |Added Summary|Deadlock inside |Deadlock inside |glClientWaitSync|glClientWaitSync [Regresion ||bc65dcab3bc48673ff6180afb03 ||6561a4b8b1119] -- 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 105339] Deadlock inside glClientWaitSync
https://bugs.freedesktop.org/show_bug.cgi?id=105339 --- Comment #5 from Matias N. Goldberg --- I traced the regression to commit: commit bc65dcab3bc48673ff6180afb036561a4b8b1119 Author: Nicolai Hähnle Date: Fri Nov 10 10:58:10 2017 +0100 radeonsi: avoid syncing the driver thread in si_fence_finish It is really only required when we need to flush for deferred fences. Reviewed-by: Marek Olšák Although I slightly suspect the former code was just making the race condition much harder to trigger, considering I've played other Dolphin games in the past (before this regression) and they ocasionally hanged in a similar way after 2-4 hours of continuous play or so (extremely rare to trigger) and it wouldn't always happen (But that may have been a different bug). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=101672 --- Comment #26 from MirceaKitsune --- Moved to a new bug report which addresses the new issue with fresh logs: https://bugs.freedesktop.org/show_bug.cgi?id=105425 -- 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 101672] radeonsi: 3D engines causing frequent GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=101672 MirceaKitsune changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=105425 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()
Retraining MST is rather difficult. In order to do it properly while
guaranteeing that we'll never run into a spot where we commit a
physically impossible configuration, we have to do a lot of checks on
atomic commits which affect MST topologies. All of this work is going to
need to be repeated for every driver at some point, so let's save
ourselves some trouble and just implement these atomic checks as
a single helper.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_mst_topology.c | 223 ++
include/drm/drm_dp_mst_helper.h | 2 +
2 files changed, 225 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0d6604500b29..c4a91b1ba61b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2167,6 +2167,229 @@ int drm_dp_mst_topology_mgr_lower_link_rate(struct
drm_dp_mst_topology_mgr *mgr,
}
EXPORT_SYMBOL(drm_dp_mst_topology_mgr_lower_link_rate);
+static bool drm_atomic_dp_mst_state_only_disables_mstbs(struct
drm_atomic_state *state,
+ struct
drm_dp_mst_topology_mgr *mgr,
+ struct
drm_dp_mst_branch *mstb)
+{
+ struct drm_dp_mst_branch *rmstb;
+ struct drm_dp_mst_port *port;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int ret;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+ if (rmstb) {
+ ret = drm_atomic_dp_mst_state_only_disables_mstbs(
+ state, mgr, rmstb);
+ drm_dp_put_mst_branch_device(rmstb);
+ if (!ret)
+ return false;
+ }
+
+ connector = port->connector;
+ if (!connector)
+ continue;
+
+ conn_state = drm_atomic_get_new_connector_state(
+ state, connector);
+ if (!conn_state)
+ continue;
+
+ crtc = conn_state->crtc;
+ if (!crtc)
+ continue;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ if (!crtc_state)
+ continue;
+
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ return false;
+ }
+
+ return true;
+}
+
+static int drm_atomic_dp_mst_all_mstbs_disabled(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr
*mgr,
+ struct drm_dp_mst_branch *mstb)
+{
+ struct drm_dp_mst_branch *rmstb;
+ struct drm_dp_mst_port *port;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ int ret;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+ if (rmstb) {
+ ret = drm_atomic_dp_mst_all_mstbs_disabled(
+ state, mgr, rmstb);
+ drm_dp_put_mst_branch_device(rmstb);
+ if (ret <= 0)
+ return ret;
+ }
+
+ connector = port->connector;
+ if (!connector)
+ continue;
+
+ conn_state = drm_atomic_get_connector_state(
+ state, connector);
+ if (IS_ERR(conn_state))
+ return PTR_ERR(conn_state);
+
+ if (conn_state->crtc)
+ return false;
+ }
+
+ /* No enabled CRTCs found */
+ return true;
+}
+
+static int drm_atomic_dp_mst_retrain_mstb(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ bool full_modeset)
+{
+ struct drm_dp_mst_branch *rmstb;
+ struct drm_dp_mst_port *port;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int ret;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+ if (rmstb) {
+ ret = drm_atomic_dp_mst_retrain_mstb(
+ state, mgr, rmstb, full_modeset);
+ drm_dp_put_mst_branch_device(rmstb);
+ if (ret)
+
[PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies
When a DP MST link needs retraining, sometimes the hub will detect that
the current link bw config is impossible and will update it's RX caps in
the DPCD to reflect the new maximum link rate. Currently, we make the
assumption that the RX caps in the dpcd will never change like this.
This means if the sink changes it's RX caps after we've already set up
an MST link and we attempt to add or remove another sink from the
topology, we could put ourselves into an invalid state where we've tried
to configure different sinks on the same MST topology with different
link rates. We could also run into this situation if a sink reports a
higher link rate after suspend, usually from us having trained it with a
fallback bw configuration before suspending.
So: "lock" the bw config by only using the max DP link rate/lane count
on the first modeset for an MST topology. For every modeset following,
we instead use the last configured link bw for this topology. We only
unlock the bw config when we've detected a new MST sink.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 11 +--
drivers/gpu/drm/i915/intel_dp_mst.c | 22 +++---
drivers/gpu/drm/i915/intel_drv.h| 6 ++
3 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5abf0c95725a..5645a194de92 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3871,18 +3871,25 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
static void
intel_dp_configure_mst(struct intel_dp *intel_dp)
{
+ bool was_mst;
+
if (!i915_modparams.enable_dp_mst)
return;
if (!intel_dp->can_mst)
return;
+ was_mst = intel_dp->is_mst;
intel_dp->is_mst = intel_dp_can_mst(intel_dp);
- if (intel_dp->is_mst)
+ if (intel_dp->is_mst) {
DRM_DEBUG_KMS("Sink is MST capable\n");
- else
+
+ if (!was_mst)
+ intel_dp->mst_bw_locked = false;
+ } else {
DRM_DEBUG_KMS("Sink is not MST capable\n");
+ }
drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
intel_dp->is_mst);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..c0553456b18e 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
- int lane_count, slots;
+ int lane_count, link_rate, slots;
const struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc,
@@ -56,16 +56,22 @@ static bool intel_dp_mst_compute_config(struct
intel_encoder *encoder,
bpp);
}
/*
-* for MST we always configure max link bw - the spec doesn't
-* seem to suggest we should do otherwise.
+* for MST we always configure max link bw if we don't know better -
+* the spec doesn't seem to suggest we should do otherwise. But,
+* ensure it always stays consistent with the rest of this hub's
+* state.
*/
- lane_count = intel_dp_max_lane_count(intel_dp);
+ if (intel_dp->mst_bw_locked) {
+ lane_count = intel_dp->lane_count;
+ link_rate = intel_dp->link_rate;
+ } else {
+ lane_count = intel_dp_max_lane_count(intel_dp);
+ link_rate = intel_dp_max_link_rate(intel_dp);
+ }
pipe_config->lane_count = lane_count;
-
pipe_config->pipe_bpp = bpp;
-
- pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
+ pipe_config->port_clock = link_rate;
if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
@@ -221,6 +227,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder,
connector->encoder = encoder;
intel_mst->connector = connector;
+ intel_dp->mst_bw_locked = true;
+
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3f19dc80997f..fc338529e918 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1107,6 +1107,12 @@ struct intel_dp {
bool can_mst; /* this port supports mst */
bool is_mst;
int active_mst_links;
+ /* Set when we've already decided on a link bw for mst, to prevent us
+* fr
[PATCH v3 5/5] drm/i915: Implement proper fallback training for MST
For a while we actually haven't had any way of retraining MST links with
fallback link parameters like we do with SST. While uncommon, certain
setups such as my Caldigit TS3 + EVGA MST hub require this since
otherwise, they end up getting stuck in an infinite MST retraining loop.
MST retraining is somewhat different then SST retraining. While it's
possible during the normal link retraining sequence for a hub to indicate
bad link status, it's also possible for a hub to only indicate this
status through ESI messages and it's possible for this to happen after
the initial link training succeeds. This can lead to a pattern that
looks like this:
- Train MST link
- Training completes successfully
- MST hub sets Channel EQ failed bit in ESI
- Retraining starts
- Retraining completes successfully
- MST hub sets Channel EQ failed bit in ESI again
- Rinse and repeat
In these situations, we need to be able to actually trigger fallback
link training from the ESI handler as well, along with using the ESI
handler during retraining to figure out whether or not our retraining
actually succeeded.
This gets a bit more complicated since we have to ensure that we don't
block the ESI handler at all while doing retraining. If we do, due to
DisplayPort's general issues with being sensitive to IRQ latency most
MST hubs will just stop responding to us if their interrupts aren't
handled in a timely manner.
So: move retraining into it's own seperate handler. Running in a
seperate handler allows us to avoid stalling the ESI during link
retraining, and we can have the ESI signal that the channel EQ bit was
cleared through a simple completion struct. Additionally, we take care
to stick as much of this into the SST retraining path as possible since
sharing is caring.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 342 +++-
drivers/gpu/drm/i915/intel_dp_mst.c | 42 -
drivers/gpu/drm/i915/intel_drv.h| 8 +
3 files changed, 302 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5645a194de92..7626652732b6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -45,6 +45,8 @@
#define DP_DPRX_ESI_LEN 14
+#define DP_MST_RETRAIN_TIMEOUT (msecs_to_jiffies(100))
+
/* Compliance test status bits */
#define INTEL_DP_RESOLUTION_SHIFT_MASK 0
#define INTEL_DP_RESOLUTION_PREFERRED (1 << INTEL_DP_RESOLUTION_SHIFT_MASK)
@@ -4224,6 +4226,118 @@ static void intel_dp_handle_test_request(struct
intel_dp *intel_dp)
DRM_DEBUG_KMS("Could not write test response to sink\n");
}
+/* Get a mask of the CRTCs that are running on the given intel_dp struct. For
+ * MST, this returns a crtc mask containing all of the CRTCs driving
+ * downstream sinks, for SST it just returns a mask of the attached
+ * connector's CRTC.
+ */
+int
+intel_dp_get_crtc_mask(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = dp_to_dig_port(intel_dp)->base.base.dev;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct intel_connector *intel_connector;
+ struct drm_crtc *crtc;
+ int crtc_mask = 0;
+
+ WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+
+ if (intel_dp->is_mst) {
+ struct drm_connector_list_iter conn_iter;
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ for_each_intel_connector_iter(intel_connector, &conn_iter) {
+ if (intel_connector->mst_port != intel_dp)
+ continue;
+
+ conn_state = intel_connector->base.state;
+ if (!conn_state->crtc)
+ continue;
+
+ crtc_mask |= drm_crtc_mask(conn_state->crtc);
+ }
+ drm_connector_list_iter_end(&conn_iter);
+ } else {
+ connector = &intel_dp->attached_connector->base;
+ crtc = connector->state->crtc;
+
+ if (crtc)
+ crtc_mask |= drm_crtc_mask(crtc);
+ }
+
+ return crtc_mask;
+}
+
+static bool
+intel_dp_needs_link_retrain(struct intel_dp *intel_dp,
+ const u8 esi[DP_DPRX_ESI_LEN])
+{
+ u8 buf[max(DP_LINK_STATUS_SIZE, DP_DPRX_ESI_LEN)];
+ const u8 *link_status = NULL;
+
+ if (intel_dp->is_mst) {
+ if (!intel_dp->active_mst_links)
+ return false;
+ if (intel_dp->mst_link_is_bad)
+ return false;
+
+ if (esi) {
+ link_status = &esi[10];
+ } else {
+ /* We're not running from the ESI handler, so wait a
+* little bit to see if the ESI handler lets us know
+* that the link status is
[PATCH v3 3/5] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()
Unlike SST, MST can have far more then a single display hooked up on a
single port. What this also means however, is that if the DisplayPort
link to the top-level MST branch device becomes unstable then every
single branch device also has an unstable link. Additionally, MST has a
few more steps that must be taken in order to properly retrain the
entire topology under a lower link rate. Since the VCID allocations for
each mstb is determined based off the link rate for the top of the
topology, we also have to recalculate all of the VCID allocations for
the downstream ports as well to ensure that we still have enough link
bandwidth to drive each mstb.
Additionally, since we have multiple downstream connectors per port,
setting the link status of the parent mstb's port to bad isn't enough:
all of the downstream mstb ports have to have their link status set to
bad.
This basically follows the same paradigm that our DP link status logic
in DRM does, in that we simply tell userspace that all of the mstb ports
need retraining and additionally applying the new lower bandwidth
constraints to all of the atomic commits on the topology that follow.
Since the work of figuring out which connectors live downstream on an
MST topology and updating their link status is something that any driver
supporting MST is going to need to do in order to retrain MST links
properly, we add the drm_dp_mst_topology_mgr_lower_link_rate() helper
which simply recalculates the pbn_div for a given mst topology, then
marks the link status of all connectors living in that topology as bad.
We'll make use of it in i915 later in this series.
Signed-off-by: Lyude Paul
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_mst_topology.c | 73 ++-
include/drm/drm_dp_mst_helper.h | 3 ++
2 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6fac4129e6a2..0d6604500b29 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2076,7 +2076,7 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
{
switch (dp_link_bw) {
default:
- DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count:
%d)\n",
+ DRM_DEBUG_KMS("invalid link bandwidth: %x (link count: %d)\n",
dp_link_bw, dp_link_count);
return false;
@@ -2096,6 +2096,77 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
return true;
}
+static void drm_dp_set_mstb_link_status(struct drm_dp_mst_branch *mstb,
+ enum drm_link_status status)
+{
+ struct drm_dp_mst_branch *rmstb;
+ struct drm_dp_mst_port *port;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ rmstb = drm_dp_get_validated_mstb_ref(mstb->mgr, port->mstb);
+ if (rmstb) {
+ drm_dp_set_mstb_link_status(rmstb, status);
+ drm_dp_put_mst_branch_device(rmstb);
+ }
+
+ if (port->connector)
+ port->connector->state->link_status = status;
+ }
+}
+
+/**
+ * drm_dp_mst_topology_mgr_lower_link_rate() - Override the DP link bw/count
+ * for all connectors in a given MST topology
+ * @mgr: manager to set state for
+ * @dp_link_bw: The new DP link bandwidth
+ * @dp_link_count: The new DP link count
+ *
+ * This is called by the driver when it detects that the current DP link for
+ * the given topology manager is unstable, and needs to be retrained at a
+ * lower link rate.
+ *
+ * This takes care of updating the link status on all downstream connectors
+ * along with recalculating the VC payloads. The driver should send a hotplug
+ * event after calling this function to notify userspace of the link status
+ * change.
+ *
+ * RETURNS:
+ *
+ * True for success, or negative error code on failure.
+ */
+int drm_dp_mst_topology_mgr_lower_link_rate(struct drm_dp_mst_topology_mgr
*mgr,
+ int dp_link_bw, int dp_link_count)
+{
+ struct drm_device *dev = mgr->dev;
+ struct drm_dp_mst_branch *mst_primary;
+ int new_pbn_div;
+ int ret = 0;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+
+ if (!drm_dp_get_vc_payload_bw(drm_dp_link_rate_to_bw_code(dp_link_bw),
+ dp_link_count, &new_pbn_div)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ mst_primary = drm_dp_get_validated_mstb_ref(mgr, mgr->mst_primary);
+ if (!mst_primary)
+ goto out;
+
+ DRM_DEBUG_KMS("MST link failed to retrain, lowering pbn_div to %d\n",
+ new_pbn_div);
+ mgr->pbn_div = new_pbn_div;
+
+ drm_dp_set_mstb_link_status(mst_primary, DRM_MODE_LINK_STATUS_BAD);
+
+ drm_dp_put_mst_branch_device(mst_primar
[PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp
While having the modeset_retry_work in intel_connector makes sense with
SST, this paradigm doesn't make a whole ton of sense when it comes to
MST since we have to deal with multiple connectors. In most cases, it's
more useful to just use the intel_dp struct since it indicates whether
or not we're dealing with an MST device, along with being able to easily
trace the intel_dp struct back to it's respective connector (if there is
any). So, move the modeset_retry_work function out of the
intel_connector struct and into intel_dp.
Signed-off-by: Lyude Paul
Reviewed-by: Manasi Navare
Cc: Manasi Navare
Cc: Ville Syrjälä
V2:
- Remove accidental duplicate modeset_retry_work in intel_connector
V3:
- Also check against eDP in intel_hpd_poll_fini() - mdnavare
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_dp.c | 10 --
drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
4 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f424fff477f6..3b7fa430a84a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15394,16 +15394,37 @@ static void intel_hpd_poll_fini(struct drm_device
*dev)
{
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
+ struct work_struct *work;
+ int conn_type;
/* Kill all the work that may have been queued by hpd. */
drm_connector_list_iter_begin(dev, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
- if (connector->modeset_retry_work.func)
- cancel_work_sync(&connector->modeset_retry_work);
if (connector->hdcp_shim) {
cancel_delayed_work_sync(&connector->hdcp_check_work);
cancel_work_sync(&connector->hdcp_prop_work);
}
+
+ conn_type = connector->base.connector_type;
+ if (conn_type != DRM_MODE_CONNECTOR_eDP &&
+ conn_type != DRM_MODE_CONNECTOR_DisplayPort)
+ continue;
+
+ if (connector->mst_port) {
+ work = &connector->mst_port->modeset_retry_work;
+ } else {
+ struct intel_encoder *intel_encoder =
+ connector->encoder;
+ struct intel_dp *intel_dp;
+
+ if (!intel_encoder)
+ continue;
+
+ intel_dp = enc_to_intel_dp(&intel_encoder->base);
+ work = &intel_dp->modeset_retry_work;
+ }
+
+ cancel_work_sync(work);
}
drm_connector_list_iter_end(&conn_iter);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4dd1b2287dd6..5abf0c95725a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
{
- struct intel_connector *intel_connector;
- struct drm_connector *connector;
+ struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
+modeset_retry_work);
+ struct drm_connector *connector = &intel_dp->attached_connector->base;
- intel_connector = container_of(work, typeof(*intel_connector),
- modeset_retry_work);
- connector = &intel_connector->base;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
connector->name);
@@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
int type;
/* Initialize the work for modeset in case of link train failure */
- INIT_WORK(&intel_connector->modeset_retry_work,
+ INIT_WORK(&intel_dp->modeset_retry_work,
intel_dp_modeset_retry_work_fn);
if (WARN(intel_dig_port->max_lanes < 1,
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index f59b59bb0a21..2cfa58ce1f95 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -340,7 +340,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
intel_dp->link_rate,
intel_dp->lane_count))
/* Schedule a Hotplug Uevent to userspace to start
modeset */
- schedule_work(&intel_connector->modeset_retry_work);
+ schedule_w
[Bug 105423] Unable to unbind my 2nd GPU (Rx580)
https://bugs.freedesktop.org/show_bug.cgi?id=105423 --- Comment #1 from Max --- Ok, i found an interesting thing. I have this issue when i unbind my GPU on Kernel 4.15 but i have no issue when i do it on kernel 4.14. I'll try to git bisect between kernel 4.15 and kernel 4.14. -- 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 4/4] drm/vc4: Validate framebuffer pixel format/modifier
Ville Syrjala writes: > From: Ville Syrjälä > > Only create framebuffers with supported format/modifier combinations by > checking that at least one plane supports the requested combination. > > Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since > the planes have (mostly) uniform capabilities. But I was lazy and > didn't feel like exporting drm_plane_format_check() and hand rolling > anything better. Also I really just wanted to come up with another > user for drm_any_plane_has_format() ;) I'm not excited about vc4 having error-return behavior that other drivers don't have. Actually, I don't really see why we should be doing this check in fb create at all, given that you have to do so again at atomic_check time with the specific plane. Could you just delete the i915 fb format check code? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/vc4: Improve alpha format plane support
Stefan Schake writes: > This series improves the handling of alpha formats with the VC4 HVS > compositor. Alpha formats are marked as premultiplied as is standard > for DRM. Further fix a display corruption issue when planes with > per-pixel alpha try blending from the (nonexistent) background by > selectively enabling a black background color fill. Reviewed and applied to drm-misc-next. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/amdgpu: add independent DMA-buf export
Instead of relying on the DRM functions just implement our own export
functions. This adds support for taking care of unpinned DMA-buf.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 117 ++---
4 files changed, 79 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 96bcdb97e7e2..909dc9764a22 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -371,7 +371,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *
amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index e6709362994a..e32dcdf8d3db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -886,7 +886,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
- .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 48e0115d4f76..d5db5955a70a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -31,6 +31,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -931,6 +932,9 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
amdgpu_bo_kunmap(abo);
+ if (abo->gem_base.dma_buf)
+ dma_buf_invalidate_mappings(abo->gem_base.dma_buf);
+
/* remember the eviction */
if (evict)
atomic64_inc(&adev->num_evictions);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 1c9991738477..f575fb46d7a8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -32,13 +32,9 @@
static const struct dma_buf_ops amdgpu_dmabuf_ops;
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int npages = bo->tbo.num_pages;
-
- return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
+static void amdgpu_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+struct sg_table *sgt,
+enum dma_data_direction dir);
void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
{
@@ -126,22 +122,21 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
}
-static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
-struct device *target_dev,
-struct dma_buf_attachment *attach)
+static struct sg_table *
+amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
{
+ struct dma_buf *dma_buf = attach->dmabuf;
struct drm_gem_object *obj = dma_buf->priv;
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct sg_table *sgt;
long r;
- r = drm_gem_map_attach(dma_buf, target_dev, attach);
- if (r)
- return r;
-
- r = amdgpu_bo_reserve(bo, false);
- if (unlikely(r != 0))
- goto error_detach;
-
+ if (!attach->invalidate_mappings) {
+ r = amdgpu_bo_reserve(bo, false);
+ if (unlikely(r != 0))
+ return ERR_PTR(r);
+ }
if (dma_buf->ops != &amdgpu_dmabuf_ops) {
/*
@@ -157,41 +152,80 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
}
}
- /* pin buffer into GTT */
- r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
- if (r)
- goto error_unreserve;
+ if (!attach->invalidate_mappings || true) {
+ /* pin buffer into GTT */
+ r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
+ if (r)
+ goto error_unreserve;
+
+ } else {
+ /* move buffer into GTT */
+ struct ttm_o
[PATCH 2/4] drm/ttm: keep a reference to transfer pipelined BOs
Make sure the transfered BO is never destroy before the transfer BO.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1f730b3f18e5..1ee20558ee31 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -39,6 +39,11 @@
#include
#include
+struct ttm_transfer_obj {
+ struct ttm_buffer_object base;
+ struct ttm_buffer_object *bo;
+};
+
void ttm_bo_free_old_node(struct ttm_buffer_object *bo)
{
ttm_bo_mem_put(bo, &bo->mem);
@@ -435,7 +440,11 @@ EXPORT_SYMBOL(ttm_bo_move_memcpy);
static void ttm_transfered_destroy(struct ttm_buffer_object *bo)
{
- kfree(bo);
+ struct ttm_transfer_obj *fbo;
+
+ fbo = container_of(bo, struct ttm_transfer_obj, base);
+ ttm_bo_unref(&fbo->bo);
+ kfree(fbo);
}
/**
@@ -456,14 +465,15 @@ static void ttm_transfered_destroy(struct
ttm_buffer_object *bo)
static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
struct ttm_buffer_object **new_obj)
{
- struct ttm_buffer_object *fbo;
+ struct ttm_transfer_obj *fbo;
int ret;
fbo = kmalloc(sizeof(*fbo), GFP_KERNEL);
if (!fbo)
return -ENOMEM;
- *fbo = *bo;
+ fbo->base = *bo;
+ fbo->bo = ttm_bo_reference(bo);
/**
* Fix up members that we shouldn't copy directly:
@@ -471,25 +481,25 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
*/
atomic_inc(&bo->bdev->glob->bo_count);
- INIT_LIST_HEAD(&fbo->ddestroy);
- INIT_LIST_HEAD(&fbo->lru);
- INIT_LIST_HEAD(&fbo->swap);
- INIT_LIST_HEAD(&fbo->io_reserve_lru);
- mutex_init(&fbo->wu_mutex);
- fbo->moving = NULL;
- drm_vma_node_reset(&fbo->vma_node);
- atomic_set(&fbo->cpu_writers, 0);
-
- kref_init(&fbo->list_kref);
- kref_init(&fbo->kref);
- fbo->destroy = &ttm_transfered_destroy;
- fbo->acc_size = 0;
- fbo->resv = &fbo->ttm_resv;
- reservation_object_init(fbo->resv);
- ret = reservation_object_trylock(fbo->resv);
+ INIT_LIST_HEAD(&fbo->base.ddestroy);
+ INIT_LIST_HEAD(&fbo->base.lru);
+ INIT_LIST_HEAD(&fbo->base.swap);
+ INIT_LIST_HEAD(&fbo->base.io_reserve_lru);
+ mutex_init(&fbo->base.wu_mutex);
+ fbo->base.moving = NULL;
+ drm_vma_node_reset(&fbo->base.vma_node);
+ atomic_set(&fbo->base.cpu_writers, 0);
+
+ kref_init(&fbo->base.list_kref);
+ kref_init(&fbo->base.kref);
+ fbo->base.destroy = &ttm_transfered_destroy;
+ fbo->base.acc_size = 0;
+ fbo->base.resv = &fbo->base.ttm_resv;
+ reservation_object_init(fbo->base.resv);
+ ret = reservation_object_trylock(fbo->base.resv);
WARN_ON(!ret);
- *new_obj = fbo;
+ *new_obj = &fbo->base;
return 0;
}
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RFC: unpinned DMA-buf exporting
This set of patches adds an option invalidate_mappings callback to each DMA-buf attachment which can be filled in by the importer. This callback allows the exporter to provided the DMA-buf content without pinning it. The reservation objects lock acts as synchronization point for buffer moves and creating mappings. This set includes an implementation for amdgpu which should be rather easily portable to other DRM drivers. Please comment, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amdgpu: add independent DMA-buf import
Instead of relying on the DRM functions just implement our own import
functions. This adds support for taking care of unpinned DMA-buf.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 64 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 +---
2 files changed, 80 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index f575fb46d7a8..7963ce329519 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -298,22 +298,64 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device
*dev,
return buf;
}
+static void
+amdgpu_gem_prime_invalidate_mappings(struct dma_buf_attachment *attach)
+{
+ struct ttm_operation_ctx ctx = { false, false };
+ struct drm_gem_object *obj = attach->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ int r;
+
+ amdgpu_ttm_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
+ r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+ if (r)
+ DRM_ERROR("Failed to unmap DMA-buf import (%d))\n", r);
+}
+
struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
{
+ struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
+ int ret;
- if (dma_buf->ops == &amdgpu_dmabuf_ops) {
- obj = dma_buf->priv;
- if (obj->dev == dev) {
- /*
-* Importing dmabuf exported from out own gem increases
-* refcount on gem itself instead of f_count of dmabuf.
-*/
- drm_gem_object_get(obj);
- return obj;
- }
+ if (dma_buf->ops != &amdgpu_dmabuf_ops)
+ return drm_gem_prime_import(dev, dma_buf);
+
+ obj = dma_buf->priv;
+ if (obj->dev == dev) {
+ /*
+* Importing dmabuf exported from out own gem increases
+* refcount on gem itself instead of f_count of dmabuf.
+*/
+ drm_gem_object_get(obj);
+ return obj;
+ }
+
+ /*
+* Attach, but don't map other amdgpu BOs
+*/
+ attach = dma_buf_attach(dma_buf, dev->dev);
+ if (IS_ERR(attach))
+ return ERR_CAST(attach);
+
+ get_dma_buf(dma_buf);
+
+ obj = amdgpu_gem_prime_import_sg_table(dev, attach, NULL);
+ if (IS_ERR(obj)) {
+ ret = PTR_ERR(obj);
+ goto fail_detach;
}
- return drm_gem_prime_import(dev, dma_buf);
+ obj->import_attach = attach;
+ attach->invalidate_mappings = amdgpu_gem_prime_invalidate_mappings;
+ attach->priv = obj;
+
+ return obj;
+
+fail_detach:
+ dma_buf_detach(dma_buf, attach);
+ dma_buf_put(dma_buf);
+
+ return ERR_PTR(ret);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 291dd3d600cd..aeead0281e92 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_object.h"
#include "amdgpu_trace.h"
@@ -685,6 +686,7 @@ struct amdgpu_ttm_gup_task_list {
struct amdgpu_ttm_tt {
struct ttm_dma_tt ttm;
+ struct amdgpu_bo*bo;
u64 offset;
uint64_tuserptr;
struct mm_struct*usermm;
@@ -993,6 +995,7 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
ttm_buffer_object *bo,
return NULL;
}
gtt->ttm.ttm.func = &amdgpu_backend_func;
+ gtt->bo = ttm_to_amdgpu_bo(bo);
if (ttm_sg_tt_init(>t->ttm, bo, page_flags)) {
kfree(gtt);
return NULL;
@@ -1005,7 +1008,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
{
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
- bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
if (gtt && gtt->userptr) {
ttm->sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
@@ -1017,7 +1019,19 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
return 0;
}
- if (slave && ttm->sg) {
+ if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
+ if (!ttm->sg) {
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+
+ attach = gtt->bo->gem_base.import_attach;
+ sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt))
+ return PTR_ERR(sgt);
+
+
[PATCH 1/4] dma-buf: add optional invalidate_mappings callback
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 25 +
include/linux/dma-buf.h | 36
2 files changed, 61 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d78d5fc173dc..ed8d5844ae74 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -629,6 +629,9 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
might_sleep();
+ if (attach->invalidate_mappings)
+ reservation_object_assert_held(attach->dmabuf->resv);
+
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
@@ -656,6 +659,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
{
might_sleep();
+ if (attach->invalidate_mappings)
+ reservation_object_assert_held(attach->dmabuf->resv);
+
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
@@ -664,6 +670,25 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
+/**
+ * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
+ *
+ * @dmabuf:[in]buffer which mappings should be invalidated
+ *
+ * Informs all attachmenst that they need to destroy and recreated all their
+ * mappings.
+ */
+void dma_buf_invalidate_mappings(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach;
+
+ reservation_object_assert_held(dmabuf->resv);
+
+ list_for_each_entry(attach, &dmabuf->attachments, node)
+ attach->invalidate_mappings(attach);
+}
+EXPORT_SYMBOL_GPL(dma_buf_invalidate_mappings);
+
/**
* DOC: cpu access
*
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 085db2fee2d7..c1e2f7d93509 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -91,6 +91,18 @@ struct dma_buf_ops {
*/
void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
+ /**
+* @supports_mapping_invalidation:
+*
+* True for exporters which supports unpinned DMA-buf operation using
+* the reservation lock.
+*
+* When attachment->invalidate_mappings is set the @map_dma_buf and
+* @unmap_dma_buf callbacks can be called with the reservation lock
+* held.
+*/
+ bool supports_mapping_invalidation;
+
/**
* @map_dma_buf:
*
@@ -326,6 +338,29 @@ struct dma_buf_attachment {
struct device *dev;
struct list_head node;
void *priv;
+
+ /**
+* @invalidate_mappings:
+*
+* Optional callback provided by the importer of the attachment which
+* must be set before mappings are created.
+*
+* If provided the exporter can avoid pinning the backing store while
+* mappings exists.
+*
+* The function is called with the lock of the reservation object
+* associated with the dma_buf held and the mapping function must be
+* called with this lock held as well. This makes sure that no mapping
+* is created concurrently with an ongoing invalidation.
+*
+* After the callback all existing mappings are still valid until all
+* fences in the dma_bufs reservation object are signaled, but should be
+* destroyed by the importer as soon as possible.
+*
+* New mappings can be created immediately, but can't be used before the
+* exclusive fence in the dma_bufs reservation object is signaled.
+*/
+ void (*invalidate_mappings)(struct dma_buf_attachment *attach);
};
/**
@@ -391,6 +426,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *,
enum dma_data_direction);
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
enum dma_data_direction);
+void dma_buf_invalidate_mappings(struct dma_buf *dma_buf);
int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direction dir);
int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] dma-buf: add optional invalidate_mappings callback
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 25 +
include/linux/dma-buf.h | 36
2 files changed, 61 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d78d5fc173dc..ed8d5844ae74 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -629,6 +629,9 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
might_sleep();
+ if (attach->invalidate_mappings)
+ reservation_object_assert_held(attach->dmabuf->resv);
+
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
@@ -656,6 +659,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
{
might_sleep();
+ if (attach->invalidate_mappings)
+ reservation_object_assert_held(attach->dmabuf->resv);
+
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
@@ -664,6 +670,25 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
*attach,
}
EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
+/**
+ * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
+ *
+ * @dmabuf:[in]buffer which mappings should be invalidated
+ *
+ * Informs all attachmenst that they need to destroy and recreated all their
+ * mappings.
+ */
+void dma_buf_invalidate_mappings(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach;
+
+ reservation_object_assert_held(dmabuf->resv);
+
+ list_for_each_entry(attach, &dmabuf->attachments, node)
+ attach->invalidate_mappings(attach);
+}
+EXPORT_SYMBOL_GPL(dma_buf_invalidate_mappings);
+
/**
* DOC: cpu access
*
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 085db2fee2d7..c1e2f7d93509 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -91,6 +91,18 @@ struct dma_buf_ops {
*/
void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
+ /**
+* @supports_mapping_invalidation:
+*
+* True for exporters which supports unpinned DMA-buf operation using
+* the reservation lock.
+*
+* When attachment->invalidate_mappings is set the @map_dma_buf and
+* @unmap_dma_buf callbacks can be called with the reservation lock
+* held.
+*/
+ bool supports_mapping_invalidation;
+
/**
* @map_dma_buf:
*
@@ -326,6 +338,29 @@ struct dma_buf_attachment {
struct device *dev;
struct list_head node;
void *priv;
+
+ /**
+* @invalidate_mappings:
+*
+* Optional callback provided by the importer of the attachment which
+* must be set before mappings are created.
+*
+* If provided the exporter can avoid pinning the backing store while
+* mappings exists.
+*
+* The function is called with the lock of the reservation object
+* associated with the dma_buf held and the mapping function must be
+* called with this lock held as well. This makes sure that no mapping
+* is created concurrently with an ongoing invalidation.
+*
+* After the callback all existing mappings are still valid until all
+* fences in the dma_bufs reservation object are signaled, but should be
+* destroyed by the importer as soon as possible.
+*
+* New mappings can be created immediately, but can't be used before the
+* exclusive fence in the dma_bufs reservation object is signaled.
+*/
+ void (*invalidate_mappings)(struct dma_buf_attachment *attach);
};
/**
@@ -391,6 +426,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *,
enum dma_data_direction);
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
enum dma_data_direction);
+void dma_buf_invalidate_mappings(struct dma_buf *dma_buf);
int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direction dir);
int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105423] Unable to unbind my 2nd GPU (Rx580)
https://bugs.freedesktop.org/show_bug.cgi?id=105423 Bug ID: 105423 Summary: Unable to unbind my 2nd GPU (Rx580) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: berilli...@gmail.com Hi, I have a problem when i want to unbind my 2nd GPU to bind it to VFIO. I create a xorg.conf like that : https://pastebin.com/3FfYJq1B But even if X is closed (by /etc/init.d/xdm stop), i have a crash log in dmesg : https://pastebin.com/uAbjvJY3 thanks for your help, Maxime -- 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 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #45 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- (In reply to Michel Dänzer from comment #43) > (In reply to Ricardo Ribalda from comment #42) > > With current LLVM7 master X does not start at all. I get the following > > output: > > Did you recompile current Mesa Git master against that as well? If so, > that's most likely a separate issue, either in LLVM or Mesa, which needs to > be tracked separately from this one. I did use mesa 17.3.6 + this patches https://github.com/mesa3d/mesa/commit/78673b614b01a8a416367db23937743c0e1aaa36.diff https://patchwork.freedesktop.org/patch/186737/ (In reply to Nicolai Hähnle from comment #44) > For the LLVM problem, please provide the log output from starting X with > R600_DEBUG=vs,ps in the environment. It will have to wait until Monday, sorry :( -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 Nicolai Hähnle (nhaeh...@gmail.com) changed: What|Removed |Added CC||nhaeh...@gmail.com --- Comment #44 from Nicolai Hähnle (nhaeh...@gmail.com) --- For the LLVM problem, please provide the log output from starting X with R600_DEBUG=vs,ps in the environment. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node
Rob Herring wrote on Fri [2018-Mar-02 13:19:13 -0600]: > On Fri, Mar 2, 2018 at 7:48 AM, Benoit Parrot wrote: > > Add 'plane' child node to generic DISPC node as an optional > > property. > > Why? What problem are you solving? Ah yes, I guess on its own it does not mean much... How about: Currently all available display pipelines (i.e. plane) and output port resources are exposed to user-space. In some cases it is needed to be able restrict which resources are actually visible from user-space. Also in cases where a display wider than 2048 pixels is to be supported more than one video pipeline is needed. In this case the 2nd hardware pipeline needed is not visible to user space applications. These video pipeline definitions must be statically defined so that the number of visible pipelines does not change from the user-space perspective. In order to allow this we are adding an optional sub-node to the generic DISPC node. > > > > > Signed-off-by: Benoit Parrot > > --- > > .../devicetree/bindings/display/ti/ti,omap-dss.txt | 63 > > ++ > > 1 file changed, 63 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > > b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > > index 249e588d7865..cb101525b805 100644 > > --- a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > > +++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt > > @@ -27,6 +27,34 @@ DISPC > > Optional properties: > > - max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth > > limit > > in bytes per second > > +- plane: Child node(s) which defines which logical plane are available to > > This is the "Optional properties" section and plane is not a property. Right, I'll correct that to an optional sub-node which has required and optional properties. > > > + the system. If at least one plane child node is defined then > > + only planes defined by these nodes will be available to the system. > > + Plane nodes must be sequential starting with reg = <0> as DT parsing > > + will stop on the first missing numbered node. > > + This means if plane #1 is defined but plane #0 is not then it will > > + be as if none of the plane nodes were defined. > > + > > + Each plane node contains the following properties: > > + Required properties: > > + - reg: Used to number the logical plane > > Is logical plane a h/w concept? It does represent a hardware resource. > > > + - hw-planes: One or two HW plane number(s). > > +When 2 numbers are present this indicates a virtual > > plane > > +composed of two physical planes intended to be used > > +when the display is larger then the capacity of a > > +single plane i.e. wider than 2048 pixels. > > +The first number in the pair will dictate the > > capabilities > > +of the virtual plane. This means that for proper > > +operation the virtual plane should be composed of HW > > +planes of the same capabilities. > > +If GFX plane is used in a virtual plane it should be > > +specified first, otherwise unexpected behavior would > > +be encountered. > > + Optional property: > > + - hw-crtcs: One or more HW crtc number(s). > > +Describe the list of CRTCs on which this plane is > > +available. If this node is not present then the > > +plane will be available on all available CRTCs. > > Let's not copy archaic terms from DRM into bindings. Ok, I can rename them to use the TRM terminology instead. I chose DRM term because they are well known. So we'll have video-pipeline instead of hw-planes video-output instead of hw-crtcs Any comments on the sub-node name itself? Or can we keep 'plane'? > > Really, I'm skeptical that any of this belongs in DT. For example, > can't you figure out you need 2 physical planes whenever your > panel/timing width is greater than 2048? As stated in the description I added above, we cannot have resources exposed to user-space which can "disappear" dynamically. Doing so would break user-space applications which rely on these resources. Benoit > > Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 8/8] drm/i915: Load plane color luts from atomic flip
Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 4
drivers/gpu/drm/i915/intel_color.c| 8
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce8..e519eab 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -231,6 +231,10 @@ static void intel_plane_atomic_update(struct drm_plane
*plane,
intel_atomic_get_new_plane_state(state, intel_plane);
struct drm_crtc *crtc = new_plane_state->base.crtc ?: old_state->crtc;
+ if (new_plane_state->base.color_mgmt_changed) {
+ intel_color_load_plane_luts(&new_plane_state->base);
+ }
+
if (new_plane_state->base.visible) {
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state,
to_intel_crtc(crtc));
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index a40fafa..f67115b 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -670,6 +670,14 @@ void intel_color_load_luts(struct drm_crtc_state
*crtc_state)
dev_priv->display.load_luts(crtc_state);
}
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
+{
+ struct drm_device *dev = plane_state->plane->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->display.load_plane_luts(plane_state);
+}
+
int intel_color_check(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0a58fce..1da5a35 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2132,6 +2132,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
void intel_color_set_csc(struct drm_crtc_state *crtc_state);
void intel_color_load_luts(struct drm_crtc_state *crtc_state);
void intel_plane_color_init(struct drm_plane *plane);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state);
/* intel_lspcon.c */
bool lspcon_init(struct intel_digital_port *intel_dig_port);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
Implement Plane Gamma feature for BDW and Gen9 platforms.
v2: Used newly added drm_color_lut_ext structure for enhanced
precision for Gamma LUT entries.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_pci.c | 5 +++-
drivers/gpu/drm/i915/i915_reg.h | 24 +++
drivers/gpu/drm/i915/intel_color.c | 58
drivers/gpu/drm/i915/intel_display.c | 4 +++
drivers/gpu/drm/i915/intel_sprite.c | 4 +++
5 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 26e8f5c..c14b8f3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -54,7 +54,10 @@
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET,
IVB_CURSOR_C_OFFSET }
#define BDW_COLORS \
- .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+ .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
+ .plane_color = { .plane_degamma_lut_size = 0, \
+.plane_gamma_lut_size = 16 }
+
#define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
#define GLK_COLORS \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 258e86e..385c3fc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -159,6 +159,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
+#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
+#define _MMIO_PLANE_GAMC16(plane, i, a, b) _MMIO(_PIPE(plane, a, b) + (i) * 4)
+
#define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask))\
BUILD_BUG_ON_MSG(((mask) & 0x), "Incorrect mask"); \
@@ -9142,6 +9145,27 @@ enum skl_power_gate {
#define PRE_CSC_GAMC_INDEX(pipe) _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A,
_PRE_CSC_GAMC_INDEX_B)
#define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe,
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
+/* Plane Gamma in Gen9+ */
+#define _PLANE_GAMC_1_A0x701d0
+#define _PLANE_GAMC_1_B0x711d0
+#define _PLANE_GAMC_2_A0x702d0
+#define _PLANE_GAMC_2_B0x712d0
+#define _PLANE_GAMC_1(pipe)_PIPE(pipe, _PLANE_GAMC_1_A, _PLANE_GAMC_1_B)
+#define _PLANE_GAMC_2(pipe)_PIPE(pipe, _PLANE_GAMC_2_A, _PLANE_GAMC_2_B)
+#define PLANE_GAMC(pipe, plane, i) \
+ _MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe), _PLANE_GAMC_2(pipe))
+
+#define _PLANE_GAMC16_1_A 0x70210
+#define _PLANE_GAMC16_1_B 0x71210
+#define _PLANE_GAMC16_2_A 0x70310
+#define _PLANE_GAMC16_2_B 0x71310
+#define _PLANE_GAMC16_1(pipe) _PIPE(pipe, _PLANE_GAMC16_1_A, \
+_PLANE_GAMC16_1_B)
+#define _PLANE_GAMC16_2(pipe) _PIPE(pipe, _PLANE_GAMC16_2_A, \
+_PLANE_GAMC16_2_B)
+#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
+ _PLANE_GAMC16_1(pipe), _PLANE_GAMC16_2(pipe))
+
/* pipe CSC & degamma/gamma LUTs on CHV */
#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 2d38ab8..a40fafa 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -496,6 +496,59 @@ static void broadwell_load_luts(struct drm_crtc_state
*state)
I915_WRITE(PREC_PAL_INDEX(pipe), 0);
}
+static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
+u32 offset)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+ enum pipe pipe = to_intel_plane(state->plane)->pipe;
+ enum plane_id plane = to_intel_plane(state->plane)->id;
+ uint32_t i, lut_size =
+ INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size;
+
+ if (state->gamma_lut) {
+ struct drm_color_lut_ext *lut =
+ (struct drm_color_lut_ext *) state->gamma_lut->data;
+
+ for (i = 0; i < lut_size; i++) {
+ uint32_t word =
+ (drm_color_lut_extract(lut[i].red, 10) << 20) |
+ (drm_color_lut_extract(lut[i].green, 10) << 10) |
+ drm_color_lut_extract(lut[i].blue, 10);
+
+ I915_WRITE(PLANE_GAMC(pipe, plane, i), word);
+ }
+
+ /* Program the max register to clamp values > 1.0. */
+ i = lut_size - 1;
+ I915_WRITE(PLANE_GAMC16(pipe, plane, 0),
+ drm_color_lut_extract(lut[i].red, 16));
+ I915_WRITE(PLA
[RFC v3 6/8] drm/i915: Enable plane color features
Enable and initialize plane color features.
v2: Rebase and some cleanup
v3: Updated intel_plane_color_init to call
drm_plane_color_create_prop function, which will
in turn create plane color properties.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_color.c | 14 ++
drivers/gpu/drm/i915/intel_device_info.h | 5 +
drivers/gpu/drm/i915/intel_drv.h | 9 +
4 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7eec99d7..cfbb0e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -434,6 +434,11 @@ struct drm_i915_display_funcs {
void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
void (*load_luts)(struct drm_crtc_state *crtc_state);
+ /* Add Plane Color callbacks */
+ void (*load_plane_csc_matrix)(const struct drm_plane_state
+ *plane_state);
+ void (*load_plane_luts)(const struct drm_plane_state
+ *plane_state);
};
#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 89ab0f7..2d38ab8 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -648,6 +648,20 @@ int intel_color_check(struct drm_crtc *crtc,
return -EINVAL;
}
+void intel_plane_color_init(struct drm_plane *plane)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+ drm_plane_color_create_prop(plane->dev, plane);
+
+ /* Enable color management support when we have degamma & gamma LUTs. */
+ if (INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size != 0 &&
+ INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size != 0)
+ drm_plane_enable_color_mgmt(plane,
+ INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size,
+ true, INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size);
+}
+
void intel_color_init(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index ab5bfd3..d277926 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -167,6 +167,11 @@ struct intel_device_info {
u16 degamma_lut_size;
u16 gamma_lut_size;
} color;
+
+ struct plane_color_luts {
+ u16 plane_degamma_lut_size;
+ u16 plane_gamma_lut_size;
+ } plane_color;
};
struct intel_driver_caps {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1a7c5ad..0a58fce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -529,6 +529,14 @@ struct intel_plane_state {
*/
int scaler_id;
+ /*
+* Use reduced/limited/broadcast rbg range, compressing from the full
+* range fed into the crtcs.
+*/
+ bool limited_color_range;
+ /* Gamma mode programmed on the plane */
+ uint32_t gamma_mode;
+
struct drm_intel_sprite_colorkey ckey;
};
@@ -2123,6 +2131,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
int intel_color_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
void intel_color_set_csc(struct drm_crtc_state *crtc_state);
void intel_color_load_luts(struct drm_crtc_state *crtc_state);
+void intel_plane_color_init(struct drm_plane *plane);
/* intel_lspcon.c */
bool lspcon_init(struct intel_digital_port *intel_dig_port);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 5/8] drm: Define helper function for plane color enabling
Define helper function to enable Plane color features
to attach plane color properties to plane structure.
v2: Rebase
v3: Modiefied the function to use updated property names.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_plane.c | 42 ++
include/drm/drm_color_mgmt.h | 5 +
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index b837020..bbf55c5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -144,6 +144,48 @@ static int create_in_format_blob(struct drm_device *dev,
struct drm_plane *plane
}
/**
+ * drm_plane_enable_color_mgmt - enable color management properties
+ * @plane: DRM Plane
+ * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
+ * @plane_has_ctm: whether to attach ctm_property for CSC matrix
+ * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
+ *
+ * This function lets the driver enable the color correction
+ * properties on a plane. This includes 3 degamma, csc and gamma
+ * properties that userspace can set and 2 size properties to inform
+ * the userspace of the lut sizes. Each of the properties are
+ * optional. The gamma and degamma properties are only attached if
+ * their size is not 0 and ctm_property is only attached if has_ctm is
+ * true.
+ */
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+ uint plane_degamma_lut_size,
+ bool plane_has_ctm,
+ uint plane_gamma_lut_size)
+{
+ if (plane_degamma_lut_size) {
+ drm_object_attach_property(&plane->base,
+ plane->degamma_lut_property, 0);
+ drm_object_attach_property(&plane->base,
+ plane->degamma_lut_size_property,
+ plane_degamma_lut_size);
+ }
+
+ if (plane_has_ctm)
+ drm_object_attach_property(&plane->base,
+ plane->ctm_property, 0);
+
+ if (plane_gamma_lut_size) {
+ drm_object_attach_property(&plane->base,
+ plane->gamma_lut_property, 0);
+ drm_object_attach_property(&plane->base,
+ plane->gamma_lut_size_property,
+ plane_gamma_lut_size);
+ }
+}
+EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
+
+/**
* drm_universal_plane_init - Initialize a new universal plane object
* @dev: DRM device
* @plane: plane object to init
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index b3b6d30..e220019 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -56,4 +56,9 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
u32 supported_ranges,
enum drm_color_encoding default_encoding,
enum drm_color_range default_range);
+
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+uint plane_degamma_lut_size,
+bool plane_has_ctm,
+uint plane_gamma_lut_size);
#endif
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 4/8] drm: Add Plane Gamma properties
Add plane gamma as blob property and size as a
range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.
Signed-off-by: Uma Shankar
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_atomic.c| 8
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
drivers/gpu/drm/drm_plane.c | 23 +++
include/drm/drm_plane.h | 24
5 files changed, 64 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 69b0b56..3561deb 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -544,6 +544,12 @@ Plane Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_plane.c
:doc: ctm_property
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: gamma_lut_property
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: gamma_lut_size_property
+
Tile Group Property
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f86384fa..d636a81 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -779,6 +779,12 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == plane->gamma_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->gamma_lut,
+ val, -1, &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -847,6 +853,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->degamma_lut->base.id : 0;
} else if (property == plane->ctm_property) {
*val = (state->ctm) ? state->ctm->base.id : 0;
+ } else if (property == plane->gamma_lut_property) {
+ *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 76b4b41..3337e04 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3509,6 +3509,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
drm_property_reference_blob(state->degamma_lut);
if (state->ctm)
drm_property_reference_blob(state->ctm);
+ if (state->gamma_lut)
+ drm_property_reference_blob(state->gamma_lut);
state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3557,6 +3559,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
drm_property_unreference_blob(state->degamma_lut);
drm_property_unreference_blob(state->ctm);
+ drm_property_unreference_blob(state->gamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index e635b63..b837020 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -490,6 +490,15 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
* Blob property which allows a userspace to provide CTM coefficients
* to do color space conversion or any other enhancement by doing a
* matrix multiplication using the h/w CTM processing engine
+ *
+ * gamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply gamma/tone-mapping curve using the h/w plane gamma
+ * processing engine, thereby making the content as non-linear
+ * or to perform any tone mapping operation for HDR usecases.
+ *
+ * gamma_lut_size_property:
+ * Range Property to indicate size of the plane gamma LUT.
*/
int drm_plane_color_create_prop(struct drm_device *dev,
struct drm_plane *plane)
@@ -517,6 +526,20 @@ int drm_plane_color_create_prop(struct drm_device *dev,
return -ENOMEM;
plane->ctm_property = prop;
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB,
+ "PLANE_GAMMA_LUT", 0);
+ if (!prop)
+ return -ENOMEM;
+ plane->gamma_lut_property = prop;
+
+ prop = drm_property_c
[RFC v3 3/8] drm: Add Plane CTM property
Add a blob property for plane CSC usage.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.
Signed-off-by: Uma Shankar
---
Documentation/gpu/drm-kms.rst | 3 +++
drivers/gpu/drm/drm_atomic.c| 10 ++
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
drivers/gpu/drm/drm_plane.c | 12
include/drm/drm_plane.h | 16
5 files changed, 44 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 2c943f6..69b0b56 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -541,6 +541,9 @@ Plane Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_plane.c
:doc: degamma_lut_size_property
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: ctm_property
+
Tile Group Property
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 409c058..f86384fa 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -771,6 +771,14 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
val, -1, &replaced);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == plane->ctm_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->ctm,
+ val,
+ sizeof(struct drm_color_ctm),
+ &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -837,6 +845,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (property == plane->degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+ } else if (property == plane->ctm_property) {
+ *val = (state->ctm) ? state->ctm->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d9384fd..76b4b41 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3507,6 +3507,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
if (state->degamma_lut)
drm_property_reference_blob(state->degamma_lut);
+ if (state->ctm)
+ drm_property_reference_blob(state->ctm);
state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3554,6 +3556,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
drm_crtc_commit_put(state->commit);
drm_property_unreference_blob(state->degamma_lut);
+ drm_property_unreference_blob(state->ctm);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 543a693..e635b63 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -485,6 +485,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
*
* degamma_lut_size_property:
* Range Property to indicate size of the plane degamma LUT.
+ *
+ * ctm_property:
+ * Blob property which allows a userspace to provide CTM coefficients
+ * to do color space conversion or any other enhancement by doing a
+ * matrix multiplication using the h/w CTM processing engine
*/
int drm_plane_color_create_prop(struct drm_device *dev,
struct drm_plane *plane)
@@ -505,6 +510,13 @@ int drm_plane_color_create_prop(struct drm_device *dev,
return -ENOMEM;
plane->degamma_lut_size_property = prop;
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB,
+ "PLANE_CTM", 0);
+ if (!prop)
+ return -ENOMEM;
+ plane->ctm_property = prop;
+
return 0;
}
EXPORT_SYMBOL(drm_plane_color_create_prop);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 03291b1..35535c5 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -147,6 +147,14 @@ struct drm_plane_state {
struct drm_property_blob *degamma_lut;
/**
+* @ctm:
+*
+* Color transformation matrix. See drm_plane
[RFC v3 2/8] drm: Add Plane Degamma properties
Add Plane Degamma as a blob property and plane degamma size as
a range property.
v2: Rebase
v3: Fixed Sean, Paul's review comments. Moved the property from
mode_config to drm_plane. Created a helper function to instantiate
these properties and removed from drm_mode_create_standard_properties
Added property documentation as suggested by Daniel, Vetter.
Signed-off-by: Uma Shankar
---
Documentation/gpu/drm-kms.rst | 9 +
drivers/gpu/drm/drm_atomic.c| 12
drivers/gpu/drm/drm_atomic_helper.c | 6 ++
drivers/gpu/drm/drm_plane.c | 35 +++
include/drm/drm_plane.h | 26 ++
5 files changed, 88 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 56a3780..2c943f6 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -532,6 +532,15 @@ Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:export:
+Plane Color Management Properties
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: degamma_lut_property
+
+.. kernel-doc:: drivers/gpu/drm/drm_plane.c
+ :doc: degamma_lut_size_property
+
Tile Group Property
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34b7d42..409c058 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -717,6 +717,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
{
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = &dev->mode_config;
+ bool replaced = false;
+ int ret;
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
@@ -763,6 +765,12 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->color_encoding = val;
} else if (property == plane->color_range_property) {
state->color_range = val;
+ } else if (property == plane->degamma_lut_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->degamma_lut,
+ val, -1, &replaced);
+ state->color_mgmt_changed |= replaced;
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -826,6 +834,9 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
*val = state->color_range;
+ } else if (property == plane->degamma_lut_property) {
+ *val = (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
@@ -958,6 +969,7 @@ static void drm_atomic_plane_print_state(struct drm_printer
*p,
drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
drm_get_color_range_name(state->color_range));
+ drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ae3cbfe..d9384fd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3504,6 +3504,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
state->fence = NULL;
state->commit = NULL;
+
+ if (state->degamma_lut)
+ drm_property_reference_blob(state->degamma_lut);
+ state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3548,6 +3552,8 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane_state *state)
if (state->commit)
drm_crtc_commit_put(state->commit);
+
+ drm_property_unreference_blob(state->degamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index e706da6..543a693 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -474,6 +474,41 @@ int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
}
EXPORT_SYMBOL(drm_mode_plane_set_obj_prop);
+/**
+ * DOC: degamma_lut_property
+ *
+ * degamma_lut_property:
+ * Blob property which allows a userspace to provide LUT values
+ * to apply degamma curve using the h/w plane degamma processing
+ * engine, thereby m
[RFC v3 0/8] Add Plane Color Properties
This patch series adds properties for plane color features. It adds properties for degamma used to linearize data, CSC used for gamut conversion, and gamma used to again non-linearize data as per panel supported color space. These can be utilize by user space to convert planes from one format to another, one color space to another etc. Usersapce can take smart blending decisions and utilize these hardware supported plane color features to get accurate color profile. The same can help in consistent color quality from source to panel taking advantage of advanced color features in hardware. These patches just add the property interfaces and enable helper functions. This series adds Intel Gen9 specific plane gamma feature. We can build up and add other platform/hardware specific implementation on top of this series Note: This is just to get a design feedback whether these interfaces look ok. Based on community feedback on interfaces, we will implement IGT tests to validate plane color features. This is un-tested currently. Also, userspace implementation to use these properties is currently not available. v2: Dropped legacy gamma table for plane as suggested by Maarten. Added Gen9/BDW plane gamma feature and rebase on tot. v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul comments and moved plane color properties to drm_plane instead of mode_config. Added property documentation as suggested by Daniel, Vetter. Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. Uma Shankar (8): drm: Add Enhanced Gamma LUT precision structure drm: Add Plane Degamma properties drm: Add Plane CTM property drm: Add Plane Gamma properties drm: Define helper function for plane color enabling drm/i915: Enable plane color features drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms drm/i915: Load plane color luts from atomic flip Documentation/gpu/drm-kms.rst | 18 drivers/gpu/drm/drm_atomic.c | 30 +++ drivers/gpu/drm/drm_atomic_helper.c | 12 +++ drivers/gpu/drm/drm_plane.c | 131 ++ drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/i915_pci.c | 5 +- drivers/gpu/drm/i915/i915_reg.h | 24 ++ drivers/gpu/drm/i915/intel_atomic_plane.c | 4 + drivers/gpu/drm/i915/intel_color.c| 80 ++ drivers/gpu/drm/i915/intel_device_info.h | 5 ++ drivers/gpu/drm/i915/intel_display.c | 4 + drivers/gpu/drm/i915/intel_drv.h | 10 +++ drivers/gpu/drm/i915/intel_sprite.c | 4 + include/drm/drm_color_mgmt.h | 5 ++ include/drm/drm_plane.h | 66 +++ include/uapi/drm/drm_mode.h | 15 16 files changed, 417 insertions(+), 1 deletion(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 1/8] drm: Add Enhanced Gamma LUT precision structure
Existing LUT precision structure is having only 16 bit
precision. This is not enough for upcoming enhanced hardwares
and advance usecases like HDR processing. Hence added a new
structure with 32 bit precision values. Also added the code,
for extracting the same from values passed from userspace.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_plane.c | 19 +++
include/uapi/drm/drm_mode.h | 15 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7..e706da6 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -426,6 +426,25 @@ void drm_plane_force_disable(struct drm_plane *plane)
}
EXPORT_SYMBOL(drm_plane_force_disable);
+/*
+ * Added to accommodate enhanced LUT precision.
+ * Max LUT precision is 32 bits.
+ */
+uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t bit_precision)
+{
+ uint32_t val = user_input;
+ uint32_t max = 0x >> (32 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 32) {
+ val += 1UL << (32 - bit_precision - 1);
+ val >>= 32 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract_ext);
+
/**
* drm_mode_plane_set_obj_prop - set the value of a property
* @plane: drm plane object to set property value for
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index b5d7d9e..5f3ed88 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -615,6 +615,21 @@ struct drm_color_lut {
__u16 reserved;
};
+/*
+ * Creating 32 bit palette entries for better data
+ * precision. This will be required for HDR and
+ * similar color processing usecases.
+ */
+struct drm_color_lut_ext {
+ /*
+* Data is U0.32 fixed point format.
+*/
+ __u32 red;
+ __u32 green;
+ __u32 blue;
+ __u32 reserved;
+};
+
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
#define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Dave, Here are the -misc-next pulls for the last 2 weeks. Sorry for the hold-up last week. drm-misc-next-2018-03-09-3: drm-misc-next for 4.17: UAPI Changes: plane: Add color encoding/range properties (Jyri) nouveau: Replace iturbt_709 property with color_encoding property (Ville) Core Changes: atomic: Move plane clipping into plane check helper (Ville) property: Multiple new property checks/verification (Ville) Driver Changes: rockchip: Fixes & improvements for rk3399/chromebook plus (various) sun4i: Add H3/H5 HDMI support (Jernej) i915: Add support for limited/full-range ycbcr toggling (Ville) pl111: Add bandwidth checking/limiting (Linus) Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Ville Syrjälä Cc: Linus Walleij Cheers, Sean The following changes since commit 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e: drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-03-09-3 for you to fetch changes up to 60beeccc72cabefcb8874fec542b3142e262b6c2: drm/rockchip: Don't use atomic constructs for psr (2018-03-08 23:28:53 +0100) drm-misc-next for 4.17: UAPI Changes: plane: Add color encoding/range properties (Jyri) nouveau: Replace iturbt_709 property with color_encoding property (Ville) Core Changes: atomic: Move plane clipping into plane check helper (Ville) property: Multiple new property checks/verification (Ville) Driver Changes: rockchip: Fixes & improvements for rk3399/chromebook plus (various) sun4i: Add H3/H5 HDMI support (Jernej) i915: Add support for limited/full-range ycbcr toggling (Ville) pl111: Add bandwidth checking/limiting (Linus) Cc: Jernej Skrabec Cc: Jyri Sarha Cc: Ville Syrjälä Cc: Linus Walleij Arnd Bergmann (2): drm: fix drm_get_max_iomem type mismatch tinydrm: add backlight dependency Baruch Siach (1): drm: of: simplify component probe code Benjamin Gaignard (1): drm/stm: check pitch and size calculations even if !CONFIG_MMU Chris Wilson (1): drm/mm: Fix caching of leftmost node in the interval tree Christian König (2): drm/prime: fix potential race in drm_gem_map_detach drm/prime: make the pages array optional for drm_prime_sg_to_page_addr_arrays Daniel Stone (1): drm/vc4: Advertise supported modifiers for planes Jeffy Chen (10): drm/rockchip: Add device links for master and components drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale() drm/bridge: analogix: Do not use device's drvdata drm/bridge: analogix_dp: Fix connector and encoder cleanup drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register() drm/rockchip: analogix_dp: reorder psr_unregister call in unbind drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup. drm/rockchip: inno_hdmi: Fix error handling path. drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind() Jernej Skrabec (8): dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipeline drm/sun4i: Add support for H3 display engine drm/sun4i: Add support for H3 mixer 0 drm/sun4i: Fix polarity configuration for DW HDMI PHY drm/sun4i: Add support for variants to DW HDMI PHY drm/sun4i: Move and expand DW HDMI PHY register macros drm/sun4i: Add support for H3 HDMI PHY variant drm/sun4i: Allow building on arm64 Joe Moriarty (2): drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem Jyri Sarha (1): drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane Linus Walleij (7): drm/panel: Fix ARM Versatile panel clocks bridge: Elaborate a bit on dumb VGA bridges in Kconfig drm: simple_kms_helper: Fix .mode_valid() documentation drm/pl111: Make the default BPP a per-variant variable drm/pl111: Handle the RealView variant separately drm/bridge: sii902x: Retry status read after DDI I2C drm/pl111: Use max memory bandwidth for resolution Maarten Lankhorst (1): drm/atomic: Call ww_acquire_done after drm_modeset_lock_all Marek Szyprowski (2): drm/bridge: analogix_dp: Postpone enabling runtime power management drm/bridge: analogix_dp: Don't create useless connectors Maxime Ripard (4): drm/sun4i: backend: Assign the pipes automatically drm/sun4i: Remove the plane description structure drm/sun4i: backend: Make zpos configurable drm/sun4i: backend: Remove ARGB spoofing Neil Armstrong (1): drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs Oleksandr Andrushchenko (5): drm/simple_kms_helper: Fix NU
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Fri, Mar 09, 2018 at 09:18:41AM -0800, Stephen Boyd wrote: > (I wrote an email that seems to have been lost) > > Quoting Jordan Crouse (2018-03-09 08:03:55) > > On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote: > > > On 08-03-18, 13:14, Jordan Crouse wrote: > > > > It seems to me that performance_state has a direct relationship with > > > > genpd > > > > which is good for CPU votes but in this case, we're just passing along > > > > raw data > > > > to an independent microcontroller. The 'qcom,arc-level' is used to > > > > construct > > > > the actual values that the GMU will program into the RPMh. Since these > > > > are > > > > > > The "genpd" here is created specially for this RPM. The performance-state > > > thing > > > is designed to solve this very specific problem of qualcomm SoCs and > > > there is no > > > way we are going to add another property for this now. > > > > > > > informational (from the CPU perspective) rather than functional I feel > > > > like > > > > that using performance_state for this would be as hacky as using > > > > opp-microvolt > > > > or something else. > > > > > > There is some WIP stuff here Rajendra is testing currently. > > > > > > ssh://g...@git.linaro.org/people/viresh.kumar/mylinux.git opp/genpd/qcom > > > > > > Please have a talk with Rajendra who can help you understand on how this > > > can be > > > used for GPUs. > > > > I don't think we are understanding each other. The GMU is a separate > > microcontroller. It is given a magic number (actually a combination of magic > > numbers) that it then uses to directly interact with the other hardware to > > make > > the vote. The only responsibility that the CPU has is to construct that > > magic > > number (once, at init) and send it across when asked. > > > > Looking at the sdhc code from the testing tree it makes perfect sense > > that you have a device that needs to eventually do a RPMh vote from the CPU > > and > > so the 'required-opp' and performance state come together to do the right > > thing. > > This is good code. > > > > None of this is true for the GPU. The CPU never votes for the GPU so there > > isn't any need to connect it to the power domain drivers. Even if you did > > there isn't any current mechanism for the rpmpd driver to pass the right > > magic > > number to the GPU driver which is what it really needs. > > > > I suppose that instead of using 'qcom,arc-level' we could use 'qcom-corner' > > but > > then thats just a naming dispute. We still need a way for the GPU to query > > the > > magic values. > > > > Agreed. Forcing genpd and set_performance_state APIs on GMU doesn't make > any sense if the GMU is doing it all itself. > > The binding should be the same between sdhc and GMU if they're actually > talking about the same thing though. I think they are, because I suspect > GMU needs to translate the human reasonable value of qcom,corner into > the hardware qcom,arc-level value to write into it's hardware so the GMU > can auto-transition performance states. If I'm wrong, then > qcom,arc-level needs to be created alongside of qcom,corner because > they're different number spaces. I think the value that we're discussing here is the RPMh voltage level which we translate into the qcom,arc-level(s). I'm not sure how that matches up with qcom,corner. > BTW, it's qcom,corner and not qcom-corner right? http://git.linaro.org/people/viresh.kumar/mylinux.git/commit/?h=opp/genpd/qcom&id=7586600b3bf3f8e79ce9198922fad7d4aa5b3f8d + qcom-corner = <1>; shrug? Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor
https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #17 from omegap...@startmail.com --- The patch was not enough, and my comments on that bug have been ignored - the key bit is: I've tracked part of the problem down to xfsettingsd/displays.c:xfce_displays_helper_screen_on_event, L462 xfce_displays_helper_disable_crtc call - when this call is commented out, the monitor is always configured fine (and looking at xfsettingsd's debug output, in both the success and failure case there are plenty of events happening where all monitors are connected at the end to allow for proper configuration). Commenting this out and I have had no further issues. The current state is good enough for me - you could counter and say that there should be no disconnect event in the first place, but I don't plan to look into anything further currently. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
On 03/09/2018 04:51 PM, Jacopo Mondi wrote:
> The R-Car V3M Eagle board includes a transparent LVDS decoder, connected
> to the on-chip LVDS encoder output on one side and to HDMI encoder
> ADV7511w on the other one.
>
> As the decoder does not need any configuration it has been so-far
> omitted from DTS. Now that a driver for transparent LVDS decoder is
> available, describe it in DT as well.
>
> Signed-off-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 31
> --
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> index c0fd144..0a95c20 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
> @@ -42,6 +42,33 @@
> };
> };
> };
> +
> + lvds,decoder {
I said hyphen (-), not comma (,)! :-)
[...]
MBR, Sergei
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105308] X log ballooning in size with "drmmode_wait_vblank failed for scanout update" and "get vblank counter failed"
https://bugs.freedesktop.org/show_bug.cgi?id=105308 --- Comment #13 from Michel Dänzer --- https://patchwork.freedesktop.org/patch/209464/ fixes this for me with DC disabled. -- 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 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor
https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #16 from Michel Dänzer --- (In reply to OmegaPhil from comment #15) > I'm going to sit on this for a week to make sure its actually solved. A month has passed, is there a verdict yet? -- 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 103791] Tearing after screen wakeup/on
https://bugs.freedesktop.org/show_bug.cgi?id=103791 --- Comment #21 from Michel Dänzer --- (In reply to Anthony Parsons from comment #18) > Running xrandr doesn't seem to work as a workaround but flipping VTs does. Have you tried turning it off and on again? (Who gets the reference? :) xrandr --output DisplayPort-0 --set TearFree off xrandr --output DisplayPort-0 --set TearFree on -- 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: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
(I wrote an email that seems to have been lost) Quoting Jordan Crouse (2018-03-09 08:03:55) > On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote: > > On 08-03-18, 13:14, Jordan Crouse wrote: > > > It seems to me that performance_state has a direct relationship with genpd > > > which is good for CPU votes but in this case, we're just passing along > > > raw data > > > to an independent microcontroller. The 'qcom,arc-level' is used to > > > construct > > > the actual values that the GMU will program into the RPMh. Since these are > > > > The "genpd" here is created specially for this RPM. The performance-state > > thing > > is designed to solve this very specific problem of qualcomm SoCs and there > > is no > > way we are going to add another property for this now. > > > > > informational (from the CPU perspective) rather than functional I feel > > > like > > > that using performance_state for this would be as hacky as using > > > opp-microvolt > > > or something else. > > > > There is some WIP stuff here Rajendra is testing currently. > > > > ssh://g...@git.linaro.org/people/viresh.kumar/mylinux.git opp/genpd/qcom > > > > Please have a talk with Rajendra who can help you understand on how this > > can be > > used for GPUs. > > I don't think we are understanding each other. The GMU is a separate > microcontroller. It is given a magic number (actually a combination of magic > numbers) that it then uses to directly interact with the other hardware to > make > the vote. The only responsibility that the CPU has is to construct that magic > number (once, at init) and send it across when asked. > > Looking at the sdhc code from the testing tree it makes perfect sense > that you have a device that needs to eventually do a RPMh vote from the CPU > and > so the 'required-opp' and performance state come together to do the right > thing. > This is good code. > > None of this is true for the GPU. The CPU never votes for the GPU so there > isn't any need to connect it to the power domain drivers. Even if you did > there isn't any current mechanism for the rpmpd driver to pass the right magic > number to the GPU driver which is what it really needs. > > I suppose that instead of using 'qcom,arc-level' we could use 'qcom-corner' > but > then thats just a naming dispute. We still need a way for the GPU to query the > magic values. > Agreed. Forcing genpd and set_performance_state APIs on GMU doesn't make any sense if the GMU is doing it all itself. The binding should be the same between sdhc and GMU if they're actually talking about the same thing though. I think they are, because I suspect GMU needs to translate the human reasonable value of qcom,corner into the hardware qcom,arc-level value to write into it's hardware so the GMU can auto-transition performance states. If I'm wrong, then qcom,arc-level needs to be created alongside of qcom,corner because they're different number spaces. BTW, it's qcom,corner and not qcom-corner right? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] meson: use pkg-config to detect libatomic_ops
On Friday, 2018-03-09 15:48:51 +, Emil Velikov wrote: > On 9 March 2018 at 11:47, Eric Engestrom wrote: > > >> > + dep_atomic_ops = [] > >> > > >> The dummy dep_atomic_ops is needed for almost all cases in the if/else > >> ladder. The exception being the .found() case. > > > > Actually, because of the way the `if` chain is written, the dep_atomic_ops > > has to be created before the list; in the `if` cases before this one, > > that dep might exist, but we don't need it. In the branch that uses it, > > if we got in the branch then it exists, and we need it. In the branches > > after that, it doesn't exist and we don't need it either. > > > > That means that only up to that branch can it contain anything; > > afterwards, it's empty anyway. > > > > And like I said, it only has the effect of maybe on the branches before > > adding unused flags to the compiler & linker, which shouldn't have any > > effect anyway. > > > Let me see if I get this right: > > You're saying that when dep_atomic_ops.found() == false, the > dep_atomic_ops dependency listed in the respective will expand to > no-op. > I wasn't quite sure if that's the case, hence my pedantic suggestion ;-) Exactly :) > > Makes sense though, rb still stands. OK, pushing in a minute > > Thanks Eric! > > -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] fbdev fix for v4.16-rc5
Hi Linus, Please pull fbdev fix for v4.16-rc5 (just a single fix to close kernel data leak in FBIOGETCMAP_SPARC ioctl). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the git repository at: https://github.com/bzolnier/linux.git tags/fbdev-v4.16-rc5 for you to fetch changes up to 250c6c49e3b68756b14983c076183568636e2bde: fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper(). (2018-03-07 14:00:34 +0100) fbdev fix for v4.16-rc5: - fix kernel data leak in FBIOGETCMAP_SPARC ioctl (Peter Malone) Bartlomiej Zolnierkiewicz (1): Merge tag 'v4.16-rc4' of git://git.kernel.org/.../torvalds/linux into fbdev-for-next Peter Malone (1): fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper(). drivers/video/fbdev/sbuslib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c index af6fc97..a436d44 100644 --- a/drivers/video/fbdev/sbuslib.c +++ b/drivers/video/fbdev/sbuslib.c @@ -122,7 +122,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long arg, unsigned char __user *ured; unsigned char __user *ugreen; unsigned char __user *ublue; - int index, count, i; + unsigned int index, count, i; if (get_user(index, &c->index) || __get_user(count, &c->count) || @@ -161,7 +161,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long arg, unsigned char __user *ugreen; unsigned char __user *ublue; struct fb_cmap *cmap = &info->cmap; - int index, count, i; + unsigned int index, count, i; u8 red, green, blue; if (get_user(index, &c->index) || ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime
https://bugs.freedesktop.org/show_bug.cgi?id=105369 --- Comment #10 from cd --- A freeze occured while working with the laptop: uname -r 4.16.0-rc1-085145ebf0e9 [20516.321517] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=448660, last emitted seq=448663 [20516.321526] [drm] No hardware hang detected. Did some blocks stall? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #43 from Michel Dänzer (mic...@daenzer.net) --- (In reply to Ricardo Ribalda from comment #42) > With current LLVM7 master X does not start at all. I get the following > output: Did you recompile current Mesa Git master against that as well? If so, that's most likely a separate issue, either in LLVM or Mesa, which needs to be tracked separately from this one. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote: > On 08-03-18, 13:14, Jordan Crouse wrote: > > It seems to me that performance_state has a direct relationship with genpd > > which is good for CPU votes but in this case, we're just passing along raw > > data > > to an independent microcontroller. The 'qcom,arc-level' is used to construct > > the actual values that the GMU will program into the RPMh. Since these are > > The "genpd" here is created specially for this RPM. The performance-state > thing > is designed to solve this very specific problem of qualcomm SoCs and there is > no > way we are going to add another property for this now. > > > informational (from the CPU perspective) rather than functional I feel like > > that using performance_state for this would be as hacky as using > > opp-microvolt > > or something else. > > There is some WIP stuff here Rajendra is testing currently. > > ssh://g...@git.linaro.org/people/viresh.kumar/mylinux.git opp/genpd/qcom > > Please have a talk with Rajendra who can help you understand on how this can > be > used for GPUs. I don't think we are understanding each other. The GMU is a separate microcontroller. It is given a magic number (actually a combination of magic numbers) that it then uses to directly interact with the other hardware to make the vote. The only responsibility that the CPU has is to construct that magic number (once, at init) and send it across when asked. Looking at the sdhc code from the testing tree it makes perfect sense that you have a device that needs to eventually do a RPMh vote from the CPU and so the 'required-opp' and performance state come together to do the right thing. This is good code. None of this is true for the GPU. The CPU never votes for the GPU so there isn't any need to connect it to the power domain drivers. Even if you did there isn't any current mechanism for the rpmpd driver to pass the right magic number to the GPU driver which is what it really needs. I suppose that instead of using 'qcom,arc-level' we could use 'qcom-corner' but then thats just a naming dispute. We still need a way for the GPU to query the magic values. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198985] BUG: KASAN: use-after-free in amdgpu_job_free_cb+0x26/0xb0 [amdgpu]
https://bugzilla.kernel.org/show_bug.cgi?id=198985 --- Comment #3 from Fredrik (fred...@planet-express.se) --- Still missing from 4.15.8 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] meson: use pkg-config to detect libatomic_ops
On 9 March 2018 at 11:47, Eric Engestrom wrote: >> > + dep_atomic_ops = [] >> > >> The dummy dep_atomic_ops is needed for almost all cases in the if/else >> ladder. The exception being the .found() case. > > Actually, because of the way the `if` chain is written, the dep_atomic_ops > has to be created before the list; in the `if` cases before this one, > that dep might exist, but we don't need it. In the branch that uses it, > if we got in the branch then it exists, and we need it. In the branches > after that, it doesn't exist and we don't need it either. > > That means that only up to that branch can it contain anything; > afterwards, it's empty anyway. > > And like I said, it only has the effect of maybe on the branches before > adding unused flags to the compiler & linker, which shouldn't have any > effect anyway. > Let me see if I get this right: You're saying that when dep_atomic_ops.found() == false, the dep_atomic_ops dependency listed in the respective will expand to no-op. I wasn't quite sure if that's the case, hence my pedantic suggestion ;-) Makes sense though, rb still stands. Thanks Eric! -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
On Fri, Mar 09, 2018 at 03:49:00PM +0530, Rajendra Nayak wrote: > Hey Jordan/Viresh, > > On 03/09/2018 09:13 AM, Viresh Kumar wrote: > > On 08-03-18, 13:14, Jordan Crouse wrote: > >> It seems to me that performance_state has a direct relationship with genpd > >> which is good for CPU votes but in this case, we're just passing along raw > >> data > >> to an independent microcontroller. The 'qcom,arc-level' is used to > >> construct > >> the actual values that the GMU will program into the RPMh. Since these are > > > > The "genpd" here is created specially for this RPM. The performance-state > > thing > > is designed to solve this very specific problem of qualcomm SoCs and there > > is no > > way we are going to add another property for this now. > > > >> informational (from the CPU perspective) rather than functional I feel like > >> that using performance_state for this would be as hacky as using > >> opp-microvolt > >> or something else. > > > > There is some WIP stuff here Rajendra is testing currently. > > What I am doing is a powerdomain driver to communicate magic values from > CPU to rpmh, looks like we need another one to communicate from CPU to > GMU now :) > > A few things, > * someone will need to map these larger magic values into something that > rpmh would understand (between 0 to 15 on the sdm845), thats done by > reading the command db level maps. Is this done by GMU? It is done by the GPU - we take the magic values, construct them into other magic values and send them to the GMU. As far as I know we are the only other in-kernel client of cmd-db other than the regulator(s). > * are these communicated just once for every OPP at init/boot, or for > every OPP switch? Just once at init. > * whats the communication mechanism we use between CPU and GMU? Shared memory queues inspired by Venus HFI. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #42 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- With current LLVM7 master X does not start at all. I get the following output: root@qt5122:~# X X.Org X Server 1.19.3 Release Date: 2017-03-15 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.14.0-3-amd64 x86_64 Current Operating System: Linux qt5122 4.16.0-rc4-qtec-standard #1 SMP Fri Mar 9 15:13:05 CET 2018 x86_64 Kernel command line: BOOT_IMAGE=/boot/bzImage rw root=PARTUUID=c839955a-02 rootwait qtec_mem.size=64 quiet Build Date: 09 March 2018 02:29:53PM Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 9 15:47:03 2018 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (II) [KMS] Kernel modesetting enabled. LLVM ERROR: Cannot select: 0x7f74b40a59e0: v4i32,ch = load 0x7f74b40251c8, 0x7f74b40a5978, undef:i32 0x7f74b40a5978: i32 = add 0x7f74b409f378, Constant:i32<16> 0x7f74b409f378: i32,ch = CopyFromReg 0x7f74b40251c8, Register:i32 %4 0x7f74b409f310: i32 = Register %4 0x7f74b40a5910: i32 = Constant<16> 0x7f74b409fc68: i32 = undef In function: main LLVM ERROR: Cannot select: 0x7f74a00b0570: v4i32,ch = load 0x7f74a002eab8, 0x7f74a00b0508, undef:i32 0x7f74a00b0508: i32 = add 0x7f74a00a9f08, Constant:i32<16> 0x7f74a00a9f08: i32,ch = CopyFromReg 0x7f74a002eab8, Register:i32 %4 0x7f74a00a9ea0: i32 = Register %4 0x7f74a00b04a0: i32 = Constant<16> 0x7f74a00aa7f8: i32 = undef In function: main root@qt5122:~# -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node
The #sound-dai-cells DT property is required to describe link between the HDMI IP block and the SoC's audio subsystem. Signed-off-by: Sylwester Nawrocki --- Changes since v2: - the property has been moved to "Required properties" paragraph, I didn't add Rob's Reviewed-by due to this change --- Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt index 8715ff06c457..ecb2899f4451 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt @@ -16,6 +16,7 @@ Required properties: - ddc: phandle to the hdmi ddc node - phy: phandle to the hdmi phy node - samsung,syscon-phandle: phandle for system controller node for PMU. +- #sound-dai-cells: should be 0. Required properties for Exynos 4210, 4212, 5420 and 5433: - clocks: list of clock IDs from SoC clock driver. -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] drm/i915: Eliminate the horrendous format check code
From: Ville Syrjälä
Replace the messy framebuffer format/modifier validation code
with a single call to drm_any_plane_has_format(). The code was
extremely annoying to maintain as you had to have a lot of platform
checks for different formats. The new code requires zero maintenance.
v2: Nuke the modifier checks as well since the core does that too now
v3: Call drm_any_plane_has_format() from the driver code
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 90
1 file changed, 8 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2933ad38094f..7f06fa83d894 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13989,7 +13989,6 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = &intel_fb->base;
- struct drm_format_name_buf format_name;
u32 pitch_limit;
unsigned int tiling, stride;
int ret = -EINVAL;
@@ -14020,33 +14019,14 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
}
}
- /* Passed in modifier sanity checking. */
- switch (mode_cmd->modifier[0]) {
- case I915_FORMAT_MOD_Y_TILED_CCS:
- case I915_FORMAT_MOD_Yf_TILED_CCS:
- switch (mode_cmd->pixel_format) {
- case DRM_FORMAT_XBGR:
- case DRM_FORMAT_ABGR:
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_ARGB:
- break;
- default:
- DRM_DEBUG_KMS("RC supported only with RGB
formats\n");
- goto err;
- }
- /* fall through */
- case I915_FORMAT_MOD_Y_TILED:
- case I915_FORMAT_MOD_Yf_TILED:
- if (INTEL_GEN(dev_priv) < 9) {
- DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
- mode_cmd->modifier[0]);
- goto err;
- }
- case DRM_FORMAT_MOD_LINEAR:
- case I915_FORMAT_MOD_X_TILED:
- break;
- default:
- DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
+ if (!drm_any_plane_has_format(&dev_priv->drm,
+ mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ struct drm_format_name_buf format_name;
+
+ DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n",
+ drm_get_format_name(mode_cmd->pixel_format,
+ &format_name),
mode_cmd->modifier[0]);
goto err;
}
@@ -14081,60 +14061,6 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
- /* Reject formats not supported by any plane early. */
- switch (mode_cmd->pixel_format) {
- case DRM_FORMAT_C8:
- case DRM_FORMAT_RGB565:
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_ARGB:
- break;
- case DRM_FORMAT_XRGB1555:
- if (INTEL_GEN(dev_priv) > 3) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, &format_name));
- goto err;
- }
- break;
- case DRM_FORMAT_ABGR:
- if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
- INTEL_GEN(dev_priv) < 9) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, &format_name));
- goto err;
- }
- break;
- case DRM_FORMAT_XBGR:
- case DRM_FORMAT_XRGB2101010:
- case DRM_FORMAT_XBGR2101010:
- if (INTEL_GEN(dev_priv) < 4) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, &format_name));
- goto err;
- }
- break;
- case DRM_FORMAT_ABGR2101010:
- if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, &format_name));
- goto err;
- }
- break;
- case DRM_FORMAT_YUYV:
- case DRM_FORMAT_UYVY:
- case DRM_FORMAT_YVYU:
- case DRM_FORMAT_VYUY:
- if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_pri
[PATCH 4/4] drm/vc4: Validate framebuffer pixel format/modifier
From: Ville Syrjälä
Only create framebuffers with supported format/modifier combinations by
checking that at least one plane supports the requested combination.
Using drm_any_plane_has_format() is somewhat suboptimal for vc4 since
the planes have (mostly) uniform capabilities. But I was lazy and
didn't feel like exporting drm_plane_format_check() and hand rolling
anything better. Also I really just wanted to come up with another
user for drm_any_plane_has_format() ;)
Compile tested only.
Cc: Eric Anholt
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vc4/vc4_kms.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ba60153dddb5..b6f15102dda0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -184,6 +184,17 @@ static struct drm_framebuffer *vc4_fb_create(struct
drm_device *dev,
mode_cmd = &mode_cmd_local;
}
+ if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ struct drm_format_name_buf format_name;
+
+ DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n",
+ drm_get_format_name(mode_cmd->pixel_format,
+ &format_name),
+ mode_cmd->modifier[0]);
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm: Fix some coding style issues
From: Ville Syrjälä
Put an empty line between the variable declarations and the code, and
use tabs for alignment.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_framebuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index c0530a1af5e3..7df025669067 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -162,9 +162,10 @@ static int framebuffer_check(struct drm_device *dev,
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
+
DRM_DEBUG_KMS("bad framebuffer format %s\n",
- drm_get_format_name(r->pixel_format,
- &format_name));
+ drm_get_format_name(r->pixel_format,
+ &format_name));
return -EINVAL;
}
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm: Add drm_any_plane_has_format()
From: Ville Syrjälä
Add a function to check whether there is at least one plane that
supports a specific format and modifier combination. Drivers can
use this to reject unsupported formats/modifiers in .fb_create().
v2: Accept anyformat if the driver doesn't do planes (Eric)
s/planes_have_format/any_plane_has_format/ (Eric)
Check the modifier as well since we already have a function
that does both
v3: Don't do the check in the core since we may not know the
modifier yet, instead export the function and let drivers
call it themselves
Cc: Eric Anholt
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 23 +++
include/drm/drm_mode_config.h | 6 ++
include/drm/drm_plane.h | 2 ++
3 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index a5d1fc7e8a37..3b2d6f8d889d 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -578,6 +578,29 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
return 0;
}
+/**
+ * drm_any_plane_has_format - Check whether any plane supports this format and
modifier combination
+ * @dev: DRM device
+ * @format: pixel format (DRM_FORMAT_*)
+ * @modifier: data layout modifier
+ *
+ * Returns:
+ * Whether at least one plane supports the specified format and modifier
combination.
+ */
+bool drm_any_plane_has_format(struct drm_device *dev,
+ u32 format, u64 modifier)
+{
+ struct drm_plane *plane;
+
+ drm_for_each_plane(plane, dev) {
+ if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(drm_any_plane_has_format);
+
/*
* __setplane_internal - setplane handler for internal callers
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7569f22ffef6..9b894de9a75d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -52,6 +52,12 @@ struct drm_mode_config_funcs {
* requested metadata, but most of that is left to the driver. See
* &struct drm_mode_fb_cmd2 for details.
*
+* To validate the pixel format and modifier drivers can use
+* drm_any_plane_has_format() to make sure at least one plane supports
+* the requested values. Note that the driver must first determine the
+* actual modifier used if the request doesn't have it specified,
+* ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
+*
* If the parameters are deemed valid and the backing storage objects in
* the underlying memory manager all exist, then the driver allocates
* a new &drm_framebuffer structure, subclassed to contain
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index f7bf4a48b1c3..930e8fdd90f8 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -683,5 +683,7 @@ static inline struct drm_plane *drm_plane_find(struct
drm_device *dev,
#define drm_for_each_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
+bool drm_any_plane_has_format(struct drm_device *dev,
+ u32 format, u64 modifier);
#endif
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104201] [Vega10, regression] Night Light in GNOME is applied only to one monitor on Vega 64
https://bugs.freedesktop.org/show_bug.cgi?id=104201 --- Comment #2 from Harry Wentland --- Our display code in 4.15 would mostly be older than the version of amd-staging-drm-next that you tested earlier. Would you be able to give amd-staging-drm-next a spin again and see if it's still an issue there? We've had some changes in our color programming recently. Note, though, that there's a different bug currently, described by https://bugs.freedesktop.org/show_bug.cgi?id=105083#c11. -- 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/etnaviv: init DMA ops for virtual master device
Hi Russell,
On Fri, Mar 9, 2018 at 8:34 AM, Russell King - ARM Linux
wrote:
> On Fri, Mar 09, 2018 at 12:20:59PM +0100, Lucas Stach wrote:
>> All the DRM GEM dma-buf import/export operations are done through the
>> virtual DRM master device. As this isn't instanciated from DT anymore
>> we need to make sure the DMA ops are set up correctly.
>>
>> Signed-off-by: Lucas Stach
>> ---
>> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> index ab50090d066c..d7666aed943b 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> @@ -655,7 +655,8 @@ static int etnaviv_pdev_probe(struct platform_device
>> *pdev)
>> struct device *dev = &pdev->dev;
>> struct component_match *match = NULL;
>>
>> - dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>> + arch_setup_dma_ops(dev, 0, 0x1, NULL, false);
>> + dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
>
> NAK. dma_coerce_mask_and_coherent() exists for broken devices. Please
> instead ensure that the device is created with the proper default DMA
> mask.
Should it be like this (like vc4_drv.c) ?
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -578,6 +578,8 @@ static int etnaviv_bind(struct device *dev)
struct drm_device *drm;
int ret;
+ dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
drm = drm_dev_alloc(&etnaviv_drm_driver, dev);
if (IS_ERR(drm))
return PTR_ERR(drm);
@@ -655,8 +657,6 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct component_match *match = NULL;
- dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
-
if (!dev->platform_data) {
struct device_node *core_node;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105083] Random blinking display
https://bugs.freedesktop.org/show_bug.cgi?id=105083 --- Comment #16 from Harry Wentland --- The ticket is on our backlog and we'll try to get to it in a week or so. -- 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 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable
https://bugs.freedesktop.org/show_bug.cgi?id=100919 Thomas R. changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Thomas R. --- Closed, creating new bug as per comment 15. -- 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 v7 5/9] drm: Handle aspect-ratio info in getblob
On Fri, Mar 09, 2018 at 11:07:14AM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal
>
> If the user-space does not support aspect-ratio, then getblob called
> with the blob id of a user-mode, should clear the aspect-ratio
> information in the blob data.
>
> Currently for a given blob id, there is no way to determine if the
> blob stores user-mode or not. This can only be ascertained when the
> blob is used for an atomic modeset call.
>
> This patch:
> -adds a new field 'is_video_mode' in drm_property_blob to
> differentiate between the video mode blobs and the other blobs.
> -sets the field 'is_video_mode' when the blob is used for modeset.
> -removes the aspect-ratio info from the user-mode data if aspect-ratio
> is not supported by the user, while returning the blob to the user,
> in getblob ioctl.
>
> Signed-off-by: Ankit Nautiyal
>
> V6: As suggested by Ville:
> -added helper functions for determining if aspect-ratio is
> expected in user-mode and for allowing/disallowing the
> aspect-ratio, if its not expected.
> -avoided clobbering of blob-data, instead cleared the aspect-ratio
> in the user-mode only, so that another client with aspect-ratio
> cap, can still get the aspect-ratio information from getblob.
> V7: Fixed warning [Wint-to-pointer-cast] for 32 bit platforms.
> ---
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_modes.c| 44
> ++
> drivers/gpu/drm/drm_property.c | 5 +
> include/drm/drm_modes.h| 4
> include/drm/drm_property.h | 2 ++
> 5 files changed, 56 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 34b7d42..2b1c88a 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -464,6 +464,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> else if (property == config->prop_mode_id) {
> struct drm_property_blob *mode =
> drm_property_lookup_blob(dev, val);
> + mode->is_video_mode = true;
> ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
> drm_property_blob_put(mode);
> return ret;
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index a48672c..4430294 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1761,3 +1761,47 @@ bool drm_mode_is_420(const struct drm_display_info
> *display,
> drm_mode_is_420_also(display, mode);
> }
> EXPORT_SYMBOL(drm_mode_is_420);
> +
> +/**
> + * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information
> + * is expected from the user-mode.
> + *
> + * If the user has set aspect-ratio cap, then the flag of the user-mode is
> + * allowed to contain aspect-ratio value.
> + * If the user does not set aspect-ratio cap, then the only value allowed in
> the
> + * flags bits is aspect-ratio NONE.
> + *
> + * @file_priv: file private structure to get the user capabilities
> + * @flags: 32 bit flag that contains the aspect-ratio information.
> + *
> + * Returns:
> + * true if the aspect-ratio info is allowed in the user-mode flags.
> + * false, otherwise.
> + */
> +bool
> +drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv, uint32_t
> flags)
I think we should pass the entire umode to these functions. That way the
compiler will make sure we're passing in the correct thing instead of
some other mode flags or random integers.
> +{
> + return file_priv->aspect_ratio_allowed ||
> +(flags & DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE;
> +}
> +EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);
> +
> +/**
> + * drm_mode_handle_aspect_ratio - handles the aspect-ratio bits in the
> user-mode
> + * flags.
> + *
> + * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio
> + * bits in the user-mode flag, if aspect-ratio info is not allowed.
> + *
> + * @file_priv: file private structure to get the user capabilities.
> + * @flags: 32 bit flag that is to be modified, in case the aspect
> + * ratio info is not allowed.
> + *
> + */
> +void
> +drm_mode_handle_aspect_ratio(const struct drm_file *file_priv, uint32_t
> *flags)
> +{
> + if (!drm_mode_aspect_ratio_allowed(file_priv, *flags))
> + *flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +}
> +EXPORT_SYMBOL(drm_mode_handle_aspect_ratio);
The function name could be more descriptive.
drm_mode_filter_aspect_ratio_flags() or someting similar perhaps?
Otherwise I think this is looking good.
IIRC I did have a few more patches in my last inforame series to make
sure we don't send invalid aspect ratio values in the infoframe. Unless
something has changed I believe we still need those as well. Or am I
wrong?
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index c37ac41..0a9c879 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers
[Bug 104201] [Vega10, regression] Night Light in GNOME is applied only to one monitor on Vega 64
https://bugs.freedesktop.org/show_bug.cgi?id=104201 --- Comment #1 from Vedran Miletić --- This seems to no longer be the case in 4.15.7 (I should note, after a clean reinstall of Fedora for an unrelated reason), did anything change? -- 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/etnaviv: correct timeout calculation
Hi Russell,
Am Freitag, den 09.03.2018, 11:44 + schrieb Russell King - ARM Linux:
> Hi Lucas,
>
> Please retain my authorship of my patch, which was sent on 23 Oct 2017.
> The patch you have below is 100% identical to that which I sent.
I'll gladly do so if you provide me a proper Signed-off-by for this
patch, which was missing from your 23 Oct 2017 submission.
> You should also point out, as per the follow-on discussion, that using
> clock_gettime() on 32-bit systems will not work once the time it
> reports wraps - so something like the comment I suggested in a follow
> up patch:
>
> + * Etnaviv timeouts are specified wrt CLOCK_MONOTONIC, not jiffies.
> + * We need to calculate the timeout in terms of number of jiffies
> + * between the specified timeout and the current CLOCK_MONOTONIC time.
> + * Note: clock_gettime() is 32-bit on 32-bit arch. Using 64-bit
> + * timespec math here just means that when a wrap occurs, the
> + * specified timeout goes into the past and we can't request a
> + * timeout in the future: IOW, the code breaks.
>
> would be sensible either in the commit message or the code.
I'll add it to the commit message, as I think the discussion with Arnd
established that this is a very theoretical risk, not likely to be hit
in practice.
Regards,
Lucas
> On Fri, Mar 09, 2018 at 12:21:49PM +0100, Lucas Stach wrote:
> > The old way did clamp the jiffy conversion and thus caused the timeouts
> > to become negative after some time. Also it didn't work with userspace
> > which actually fills the upper 32bits of the 64bit timestamp value.
> >
> > Fix this by using the solution developed and tested by Russell.
> >
> > > > Suggested-by: Russell King
> > > > Signed-off-by: Lucas Stach
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 25 +
> > 1 file changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > index ddb17ee565e9..17a43da98fb9 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > @@ -26,6 +26,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -132,19 +133,27 @@ static inline bool fence_after_eq(u32 a, u32 b)
> > > > return (s32)(a - b) >= 0;
> > }
> >
> > +/*
> > + * Etnaviv timeouts are specified wrt CLOCK_MONOTONIC, not jiffies.
> > + * We need to calculate the timeout in terms of number of jiffies
> > + * between the specified timeout and the current CLOCK_MONOTONIC time.
> > + */
> > static inline unsigned long etnaviv_timeout_to_jiffies(
> > > > const struct timespec *timeout)
> > {
> > > > - unsigned long timeout_jiffies = timespec_to_jiffies(timeout);
> > > > - unsigned long start_jiffies = jiffies;
> > > > - unsigned long remaining_jiffies;
> > > > + struct timespec64 ts, to;
> > +
> > > > + to = timespec_to_timespec64(*timeout);
> > +
> > > > + ktime_get_ts64(&ts);
> > +
> > > > + /* timeouts before "now" have already expired */
> > > > + if (timespec64_compare(&to, &ts) <= 0)
> > > > + return 0;
> >
> > > > - if (time_after(start_jiffies, timeout_jiffies))
> > > > - remaining_jiffies = 0;
> > > > - else
> > > > - remaining_jiffies = timeout_jiffies - start_jiffies;
> > > > + ts = timespec64_sub(to, ts);
> >
> > > > - return remaining_jiffies;
> > > > + return timespec64_to_jiffies(&ts);
> > }
> >
> > #endif /* __ETNAVIV_DRV_H__ */
> > --
> > 2.16.1
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] meson: use pkg-config to detect libatomic_ops
On Thursday, 2018-03-08 18:10:03 +, Emil Velikov wrote:
> On 5 March 2018 at 12:03, Eric Engestrom wrote:
> > Ping? :)
> > Both for this patch and the equivalent autotools patch it replies to.
> >
> The autotools one needs the CFLAGS added - meson does it automatically for us.
I'll let Peter re-spin his patch, but I might push the meson one before
his lands.
>
> > On Wednesday, 2018-02-07 14:24:33 +, Eric Engestrom wrote:
> >> Signed-off-by: Eric Engestrom
> >> ---
> >> amdgpu/meson.build| 2 +-
> >> etnaviv/meson.build | 2 +-
> >> freedreno/meson.build | 2 +-
> >> intel/meson.build | 2 +-
> >> meson.build | 3 ++-
> >> nouveau/meson.build | 2 +-
> >> omap/meson.build | 2 +-
> >> radeon/meson.build| 2 +-
> >> tegra/meson.build | 2 +-
> >> 9 files changed, 10 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/amdgpu/meson.build b/amdgpu/meson.build
> >> index 8b0452056e2513892c2c..7040ebab86e271022323 100644
> >> --- a/amdgpu/meson.build
> >> +++ b/amdgpu/meson.build
> >> @@ -37,7 +37,7 @@ libdrm_amdgpu = shared_library(
> >>],
> >>include_directories : [inc_root, inc_drm],
> >>link_with : libdrm,
> >> - dependencies : dep_pthread_stubs,
> >> + dependencies : [dep_pthread_stubs, dep_atomic_ops],
> >>version : '1.0.0',
> >>install : true,
> >> )
> >> diff --git a/etnaviv/meson.build b/etnaviv/meson.build
> >> index 1767733bd510efdaad86..ca2aa544c58924a15d8b 100644
> >> --- a/etnaviv/meson.build
> >> +++ b/etnaviv/meson.build
> >> @@ -31,7 +31,7 @@ libdrm_etnaviv = shared_library(
> >>include_directories : [inc_root, inc_drm],
> >>link_with : libdrm,
> >>c_args : warn_c_args,
> >> - dependencies : [dep_pthread_stubs, dep_rt],
> >> + dependencies : [dep_pthread_stubs, dep_rt, dep_atomic_ops],
> >>version : '1.0.0',
> >>install : true,
> >> )
> >> diff --git a/freedreno/meson.build b/freedreno/meson.build
> >> index de6a413fa93e63c0ad4a..da993c10355578838f29 100644
> >> --- a/freedreno/meson.build
> >> +++ b/freedreno/meson.build
> >> @@ -44,7 +44,7 @@ libdrm_freedreno = shared_library(
> >>[files_freedreno, config_file],
> >>c_args : warn_c_args,
> >>include_directories : [inc_root, inc_drm],
> >> - dependencies : [dep_valgrind, dep_pthread_stubs, dep_rt],
> >> + dependencies : [dep_valgrind, dep_pthread_stubs, dep_rt,
> >> dep_atomic_ops],
> >>link_with : libdrm,
> >>version : '1.0.0',
> >>install : true,
> >> diff --git a/intel/meson.build b/intel/meson.build
> >> index ad877274f8d488a80d54..42402f60e38cd5e7359f 100644
> >> --- a/intel/meson.build
> >> +++ b/intel/meson.build
> >> @@ -29,7 +29,7 @@ libdrm_intel = shared_library(
> >>],
> >>include_directories : [inc_root, inc_drm],
> >>link_with : libdrm,
> >> - dependencies : [dep_pciaccess, dep_pthread_stubs, dep_rt, dep_valgrind],
> >> + dependencies : [dep_pciaccess, dep_pthread_stubs, dep_rt, dep_valgrind,
> >> dep_atomic_ops],
> >>c_args : warn_c_args,
> >>version : '1.0.0',
> >>install : true,
> >> diff --git a/meson.build b/meson.build
> >> index a19e600c7475b2578e2d..f45c14a70baa2456582d 100644
> >> --- a/meson.build
> >> +++ b/meson.build
> >> @@ -51,6 +51,7 @@ cc = meson.get_compiler('c')
> >> intel_atomics = false
> >> lib_atomics = false
> >>
> >> +dep_atomic_ops = dependency('atomic_ops', required : false)
> >> if cc.compiles('''
> >> int atomic_add(int *i) { return __sync_add_and_fetch (i, 1); }
> >> int atomic_cmpxchg(int *i, int j, int k) { return
> >> __sync_val_compare_and_swap (i, j, k); }
> >> @@ -58,7 +59,7 @@ if cc.compiles('''
> >> name : 'Intel Atomics')
> >>intel_atomics = true
> >>with_atomics = true
> >
> > Change added here locally; there's no need to link again `dep_atomic_ops`
> > in this branch, although it doesn't hurt:
> >
> > + dep_atomic_ops = []
> >
> The dummy dep_atomic_ops is needed for almost all cases in the if/else
> ladder. The exception being the .found() case.
Actually, because of the way the `if` chain is written, the dep_atomic_ops
has to be created before the list; in the `if` cases before this one,
that dep might exist, but we don't need it. In the branch that uses it,
if we got in the branch then it exists, and we need it. In the branches
after that, it doesn't exist and we don't need it either.
That means that only up to that branch can it contain anything;
afterwards, it's empty anyway.
And like I said, it only has the effect of maybe on the branches before
adding unused flags to the compiler & linker, which shouldn't have any
effect anyway.
>
> With that
> Reviewed-by: Emil Velikov
With the explanation, does your r-b stand for the current version?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[amdgpu] Errors with amdgpu-pro 17.50 running on GX-424CC SOC
Apologies if this is not the right list for this question. Kernel MAINTAINERS file suggests it is but please let me know if I should repost elsewhere. I have a custom OpenCL application running under Ubuntu 16.04.04, HWE Kernel 4.13 and amdgpu-pro 17.50 drivers. This is running on a Fujitsu D3313-S6 industrial mainboard (http://www.fujitsu.com/fts/products/computing/peripheral/mainboards/industrial-mainboards/d3313s.html) After a period of running - from 5 minutes to 48 hours we begin to see these kernel traces. At some point after seeing these errors the application fails. [ 99.348774] amdgpu :00:01.0: GPU fault detected: 146 0x08492014 [ 99.355041] amdgpu :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00103042 [ 99.362509] amdgpu :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x09020014 [ 99.369980] VM fault (0x14, vmid 4) at page 1060930, write from 'TC0' (0x54433000) (32) [ 100.437547] amdgpu :00:01.0: GPU fault detected: 146 0x08492014 [ 100.443811] amdgpu :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00103042 [ 100.451288] amdgpu :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x09020014 [ 100.458758] VM fault (0x14, vmid 4) at page 1060930, write from 'TC0' (0x54433000) (32) I know from searching the web that this error can appear if there are errors in the opencl program. However we have run the exact same program on multiple other hardware configurations and have not seen problems. On linux we have had success running on all machines tested with a discrete amd gpu, just not on the GX-424CC apu. On windows we have had the code running on a large numbers of platforms including the GX-424CC without issues. I'm prepared to believe we have an error in our opencl code, but have no clue where to start looking. What does the error actually mean and why does it happen? Is it to do with buffer transfers between host and device? During execution of a kernel? Whilst attempting to investigate the problem I have tried a number of kernel arguments for the driver. If I reduce the amount of memory assigned to vram with vramlimit=64 then it appears to take longer for the error to occur. If I run it with the arguments vm_debug=1 vm_fault_stop=1 the error no longer appears. I would have expected it to occur at least once due to vm_fault_stop=1 but it does not. However instead I get this error occasionally: [ 7612.741693] amdgpu :00:01.0: IH ring buffer overflow (0x0010, 0x, 0x0020) So is this a bug in the driver or in the opencl code? How can I progress debugging this issue? Thanks Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: etnaviv_sched: Staticize functions when possible
Am Dienstag, den 13.02.2018, 16:36 -0200 schrieb Fabio Estevam:
> > From: Fabio Estevam
>
> etnaviv_sched_dependency() and etnaviv_sched_run_job() are only
> used in this file, so make them static.
>
> This fixes the following sparse warnings:
>
> drivers/gpu/drm/etnaviv/etnaviv_sched.c:30:18: warning: symbol
> 'etnaviv_sched_dependency' was not declared. Should it be static?
> drivers/gpu/drm/etnaviv/etnaviv_sched.c:81:18: warning: symbol
> 'etnaviv_sched_run_job' was not declared. Should it be static?
>
> Signed-off-by: Fabio Estevam
Thanks, I've applied this to my etnaviv/next tree.
Regards,
Lucas
> ---
> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index 3e33473..4b761b7 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -27,8 +27,9 @@ module_param_named(job_hang_limit, etnaviv_job_hang_limit,
> int , 0444);
> static int etnaviv_hw_jobs_limit = 2;
> module_param_named(hw_job_limit, etnaviv_hw_jobs_limit, int , 0444);
>
> -struct dma_fence *etnaviv_sched_dependency(struct drm_sched_job *sched_job,
> > - struct drm_sched_entity *entity)
> +static struct dma_fence *
> +etnaviv_sched_dependency(struct drm_sched_job *sched_job,
> > + struct drm_sched_entity *entity)
> {
> > struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
> > struct dma_fence *fence;
> @@ -78,7 +79,7 @@ struct dma_fence *etnaviv_sched_dependency(struct
> drm_sched_job *sched_job,
> > return NULL;
> }
>
> -struct dma_fence *etnaviv_sched_run_job(struct drm_sched_job *sched_job)
> +static struct dma_fence *etnaviv_sched_run_job(struct drm_sched_job
> *sched_job)
> {
> > struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
> > struct dma_fence *fence = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: correct timeout calculation
The old way did clamp the jiffy conversion and thus caused the timeouts
to become negative after some time. Also it didn't work with userspace
which actually fills the upper 32bits of the 64bit timestamp value.
Fix this by using the solution developed and tested by Russell.
Suggested-by: Russell King
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index ddb17ee565e9..17a43da98fb9 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -132,19 +133,27 @@ static inline bool fence_after_eq(u32 a, u32 b)
return (s32)(a - b) >= 0;
}
+/*
+ * Etnaviv timeouts are specified wrt CLOCK_MONOTONIC, not jiffies.
+ * We need to calculate the timeout in terms of number of jiffies
+ * between the specified timeout and the current CLOCK_MONOTONIC time.
+ */
static inline unsigned long etnaviv_timeout_to_jiffies(
const struct timespec *timeout)
{
- unsigned long timeout_jiffies = timespec_to_jiffies(timeout);
- unsigned long start_jiffies = jiffies;
- unsigned long remaining_jiffies;
+ struct timespec64 ts, to;
+
+ to = timespec_to_timespec64(*timeout);
+
+ ktime_get_ts64(&ts);
+
+ /* timeouts before "now" have already expired */
+ if (timespec64_compare(&to, &ts) <= 0)
+ return 0;
- if (time_after(start_jiffies, timeout_jiffies))
- remaining_jiffies = 0;
- else
- remaining_jiffies = timeout_jiffies - start_jiffies;
+ ts = timespec64_sub(to, ts);
- return remaining_jiffies;
+ return timespec64_to_jiffies(&ts);
}
#endif /* __ETNAVIV_DRV_H__ */
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: init DMA ops for virtual master device
All the DRM GEM dma-buf import/export operations are done through the
virtual DRM master device. As this isn't instanciated from DT anymore
we need to make sure the DMA ops are set up correctly.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index ab50090d066c..d7666aed943b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -655,7 +655,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct component_match *match = NULL;
- dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+ arch_setup_dma_ops(dev, 0, 0x1, NULL, false);
+ dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (!dev->platform_data) {
struct device_node *core_node;
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node
On 03/09/2018 03:35 AM, Inki Dae wrote: > 2018년 03월 08일 20:22에 Sylwester Nawrocki 이(가) 쓴 글: >> On 03/08/2018 09:15 AM, Inki Dae wrote: [...] >>> Is there a possibility for other boards based on Exynos4210/4212/5420/5433 >>> SoC to use this property later? >> >> All these SoCs have the HDMI IP block which has one input DAI, connected >> internally over I2S bus with the I2S controller. >> >> I think there is no advantage in limiting ourselves now only to SoC's >> for which we currently rely on that DT property in current kernel code, >> just to update this documentation later when we actually put the property >> in dts files. >> >> In case of exynos5420 we already require #sound-dai-cells for Odroid and > > Maybe exynos5422? Odroid XU3/4 use Exynos5422. Yes, my mistake, Exynos5422 for Odroid and Exynos5420 for Peach-Pit. It just happens we use "samsung,exynos5420-hdmi" compatible for that both SoCs. > Seems that '#sound-dai-cells' is required mandatorily in case of Exynos5422 > because Odroid XU3/4 Audio driver checks this property, and the driver > returns error if the property doesn't exist in its device tree. > And if other SoCs - Exynos4210/4212/5250/5420/5433 - require this property > with additional driver works later then this property would also be required > mandatorily for them not optionally. In this case we may need to modify the > description again. > > So my opinion is to add only the description required mandatorily if I > understood correctly. You are right, it would be better to make this a mandatory property, I only made it optional because now this property is missing in many dts files. Let me resend with #sound-dai-cells description moved to the "Required properties" paragraph. -- Thanks, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/2] drm_hwcomposer: Error out on YUV layer as it would fail for single planes
Hey,
On 03/09/2018 10:55 AM, Alexandru-Cosmin Gheorghe wrote:
Hi Daniel,
On Fri, Mar 09, 2018 at 09:29:24AM +, Daniel Stone wrote:
Hi John,
On 8 March 2018 at 19:43, John Stultz wrote:
On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote:
@@ -76,8 +76,6 @@ uint32_t
DrmGenericImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
return DRM_FORMAT_ABGR;
case HAL_PIXEL_FORMAT_RGB_565:
return DRM_FORMAT_BGR565;
-case HAL_PIXEL_FORMAT_YV12:
- return DRM_FORMAT_YVU420;
I'm not sure I understand the rationale for removing YVU420.
Mostly its on Alexandru's suggestion, as I don't have any experience
w/ using YVU420. Per his suggestion, my sense was that since its a
multi-plane format it was expected to fail with drmModeAddFB2().
If that's incorrect, I'm fine with dropping this change.
drmModeAddFB2 absolutely works with multi-planar formats. I have no
idea about the internals of HWC or why multi-planar formats aren't
supported there though.
drmModeAddFb2 is fine, it definitely works if you pass the right data to it.
Which I don't think ImportBuffer does for DRM_FORMAT_YVU420, it
populates just one buffer handle.
So maybe the proper solution is to split ConvertHalFormatToDrm() into two parts,
one for doing format conversion, and one for doing verifying that a format is
supported.
Additionally, maybe the better place for a format conversion function to live is
in libdrm/android/gralloc_handle.h, since it will come in handy in other
projects too.
Cheers,
Daniel
Regards,
Alex Gheorghe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: via: remove VLA usage
On 9 March 2018 at 10:59, Eric Engestrom wrote: > On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wvla, remove VLA usage. >> >> Also, fixed as part of the directive to remove all VLAs from >> the kernel: https://lkml.org/lkml/2018/3/7/621 >> >> Signed-off-by: Gustavo A. R. Silva > > Sorry for my reply on v1, I missed that Emil already replied to another > post of the same patch (side note on that, making use of `-vX` and > `--in-reply-to` helps track the evolution of patches) > > This looks good to me: > Reviewed-by: Eric Engestrom > Same here Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: via: remove VLA usage
On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA usage.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Gustavo A. R. Silva
Sorry for my reply on v1, I missed that Emil already replied to another
post of the same patch (side note on that, making use of `-vX` and
`--in-reply-to` helps track the evolution of patches)
This looks good to me:
Reviewed-by: Eric Engestrom
> ---
> drivers/video/fbdev/via/via_aux_sii164.c | 2 +-
> drivers/video/fbdev/via/via_aux_vt1631.c | 2 +-
> drivers/video/fbdev/via/via_aux_vt1632.c | 2 +-
> drivers/video/fbdev/via/via_aux_vt1636.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/via/via_aux_sii164.c
> b/drivers/video/fbdev/via/via_aux_sii164.c
> index ca1b35f..c27f62c 100644
> --- a/drivers/video/fbdev/via/via_aux_sii164.c
> +++ b/drivers/video/fbdev/via/via_aux_sii164.c
> @@ -36,7 +36,7 @@ static void probe(struct via_aux_bus *bus, u8 addr)
> .name = name};
> /* check vendor id and device id */
> const u8 id[] = {0x01, 0x00, 0x06, 0x00}, len = ARRAY_SIZE(id);
> - u8 tmp[len];
> + u8 tmp[ARRAY_SIZE(id)];
>
> if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
> return;
> diff --git a/drivers/video/fbdev/via/via_aux_vt1631.c
> b/drivers/video/fbdev/via/via_aux_vt1631.c
> index 06e742f..32978a0 100644
> --- a/drivers/video/fbdev/via/via_aux_vt1631.c
> +++ b/drivers/video/fbdev/via/via_aux_vt1631.c
> @@ -36,7 +36,7 @@ void via_aux_vt1631_probe(struct via_aux_bus *bus)
> .name = name};
> /* check vendor id and device id */
> const u8 id[] = {0x06, 0x11, 0x91, 0x31}, len = ARRAY_SIZE(id);
> - u8 tmp[len];
> + u8 tmp[ARRAY_SIZE(id)];
>
> if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
> return;
> diff --git a/drivers/video/fbdev/via/via_aux_vt1632.c
> b/drivers/video/fbdev/via/via_aux_vt1632.c
> index d24f4cd..cec8cc4 100644
> --- a/drivers/video/fbdev/via/via_aux_vt1632.c
> +++ b/drivers/video/fbdev/via/via_aux_vt1632.c
> @@ -36,7 +36,7 @@ static void probe(struct via_aux_bus *bus, u8 addr)
> .name = name};
> /* check vendor id and device id */
> const u8 id[] = {0x06, 0x11, 0x92, 0x31}, len = ARRAY_SIZE(id);
> - u8 tmp[len];
> + u8 tmp[ARRAY_SIZE(id)];
>
> if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
> return;
> diff --git a/drivers/video/fbdev/via/via_aux_vt1636.c
> b/drivers/video/fbdev/via/via_aux_vt1636.c
> index 9e015c1..2b10bc2 100644
> --- a/drivers/video/fbdev/via/via_aux_vt1636.c
> +++ b/drivers/video/fbdev/via/via_aux_vt1636.c
> @@ -36,7 +36,7 @@ void via_aux_vt1636_probe(struct via_aux_bus *bus)
> .name = name};
> /* check vendor id and device id */
> const u8 id[] = {0x06, 0x11, 0x45, 0x33}, len = ARRAY_SIZE(id);
> - u8 tmp[len];
> + u8 tmp[ARRAY_SIZE(id)];
>
> if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
> return;
> --
> 2.7.4
>
> ___
> 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 105414] R9 285 agd5f 4.17-wip DC flip_done timed out
https://bugs.freedesktop.org/show_bug.cgi?id=105414 Bug ID: 105414 Summary: R9 285 agd5f 4.17-wip DC flip_done timed out Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: adf.li...@gmail.com Created attachment 137926 --> https://bugs.freedesktop.org/attachment.cgi?id=137926&action=edit dmesg with errors and bt agd5f 4.17-wip with only with amdgpu.dc=1 I can hang display with Unreal tournament demo, backtrace at end of attached dmesg. The game notices and times out after 30sec and I regain display. This is just on initial menu possibly moving mouse to trigger - time taken to trigger 1 - 5 seconds. Other things seem OK, but there is also rare display glitch in normal use where it seems that a black frame is displayed or something. May be luck, and I've only seen it a few times, but was moving mouse at the time. No bisect, recent bugs seem to go away next update anyway + the last "DC team" bug I took time to bisect has been unanswered since December - though it may be very specific to my setup, unanswered = less motivation to bisect. -- 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: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
Hey Jordan/Viresh, On 03/09/2018 09:13 AM, Viresh Kumar wrote: > On 08-03-18, 13:14, Jordan Crouse wrote: >> It seems to me that performance_state has a direct relationship with genpd >> which is good for CPU votes but in this case, we're just passing along raw >> data >> to an independent microcontroller. The 'qcom,arc-level' is used to construct >> the actual values that the GMU will program into the RPMh. Since these are > > The "genpd" here is created specially for this RPM. The performance-state > thing > is designed to solve this very specific problem of qualcomm SoCs and there is > no > way we are going to add another property for this now. > >> informational (from the CPU perspective) rather than functional I feel like >> that using performance_state for this would be as hacky as using >> opp-microvolt >> or something else. > > There is some WIP stuff here Rajendra is testing currently. What I am doing is a powerdomain driver to communicate magic values from CPU to rpmh, looks like we need another one to communicate from CPU to GMU now :) A few things, * someone will need to map these larger magic values into something that rpmh would understand (between 0 to 15 on the sdm845), thats done by reading the command db level maps. Is this done by GMU? * are these communicated just once for every OPP at init/boot, or for every OPP switch? * whats the communication mechanism we use between CPU and GMU? regards Rajendra > > ssh://g...@git.linaro.org/people/viresh.kumar/mylinux.git opp/genpd/qcom > > Please have a talk with Rajendra who can help you understand on how this can > be > used for GPUs. > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: via_aux_vt1636: remove VLA usage
On Wednesday, 2018-03-07 13:47:03 -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with a fixed-length array instead. Also, remove variable 'len'.
>
> Notice that no new IDs have been added in seven years.
>
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/video/fbdev/via/via_aux_vt1636.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/via/via_aux_vt1636.c
> b/drivers/video/fbdev/via/via_aux_vt1636.c
> index 9e015c1..d6273a4 100644
> --- a/drivers/video/fbdev/via/via_aux_vt1636.c
> +++ b/drivers/video/fbdev/via/via_aux_vt1636.c
> @@ -35,10 +35,10 @@ void via_aux_vt1636_probe(struct via_aux_bus *bus)
> .addr = 0x40,
> .name = name};
> /* check vendor id and device id */
> - const u8 id[] = {0x06, 0x11, 0x45, 0x33}, len = ARRAY_SIZE(id);
> - u8 tmp[len];
> + const u8 id[4] = {0x06, 0x11, 0x45, 0x33};
> + u8 tmp[4];
>
> - if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
> + if (!via_aux_read(&drv, 0x00, tmp, 4) || memcmp(id, tmp, 4))
I would recommend keeping ARRAY_SIZE(); even if nothing's been added in
a while, it's still clearer in the code if we can see where these `4`
come from.
Something like this instead?
8<
@@ -35,10 +35,10 @@ void via_aux_vt1636_probe(struct via_aux_bus *bus)
.addr = 0x40,
.name = name};
/* check vendor id and device id */
- const u8 id[] = {0x06, 0x11, 0x45, 0x33}, len = ARRAY_SIZE(id);
- u8 tmp[len];
+ const u8 id[] = {0x06, 0x11, 0x45, 0x33};
+ u8 tmp[ARRAY_SIZE(id)];
- if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
+ if (!via_aux_read(&drv, 0x00, tmp, ARRAY_SIZE(id)) || memcmp(id, tmp,
ARRAY_SIZE(id)))
return;
printk(KERN_INFO "viafb: Found %s\n", name);
>8
Note that sizeof is evaluated a compile time, so `u8 tmp[ARRAY_SIZE(id)]`
is *not* a VLA. All that's needed was to remove `len` :)
> return;
>
> printk(KERN_INFO "viafb: Found %s\n", name);
> --
> 2.7.4
>
> ___
> 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
