Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
Hello Ville,
On 1/29/2019 9:33 PM, Ville Syrjälä wrote:
On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ville Syrjälä
Sent: Tuesday, January 29, 2019 9:14 PM
To: Shankar, Uma
Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
; Lankhorst, Maarten ;
dri-devel@lists.freedesktop.org
Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
This patch attaches the colorspace connector property to the hdmi
connector. Based on colorspace change, modeset will be triggered to
switch to new colorspace.
Based on colorspace property value create an infoframe with
appropriate colorspace. This can be used to send an infoframe packet
with proper colorspace value set which will help to enable wider color
gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be taken care
separately.
v2: Merged the changes of creating infoframe as well to this patch as
per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI and DP
colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a common
colorspace property for DP and HDMI, filtered the list based on the
colorspaces supported by the respective protocol standard. Handle the
default case properly.
v5: Added Platform specific colorspace enums and called the property
creation helper using the same.
v6: Addressed Shashank's review comments.
v7: Rebase
v8: Addressed Maarten's review comments.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c| 1 +
drivers/gpu/drm/i915/intel_connector.c | 63
++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 24 +
4 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..76b7114 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
||
+ new_state->colorspace != old_state->colorspace ||
new_conn_state->base.picture_aspect_ratio != old_conn_state-
base.picture_aspect_ratio ||
new_conn_state->base.content_type != old_conn_state-
base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..9a12d5e 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -30,6 +30,48 @@
#include "intel_drv.h"
#include "i915_drv.h"
+static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
+
+static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry ba
Re: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
On Wed, Jan 30, 2019 at 12:14:46AM +0100, Daniel Vetter wrote: > On Tue, Jan 29, 2019 at 8:27 PM Greg KH wrote: > > On Tue, Jan 29, 2019 at 07:10:55PM +0100, Daniel Vetter wrote: > > > The problem is when drivers use devm_ not to allocate hw resources and > > > related things, but structures for objects with other lifetimes. Like > > > open file descriptors shared with the world. > > > > And irqs, which bites everyone in the end. You have to be careful here, > > never tie a devm allocation to an object with another reference count, > > that's just a bug. > > The classic "I forgot to shut down the interrupt before releasing > driver structures and now the irq handler oopsed" or something more > sinister? The classic is always the best, and most common :) > gpus definitely needs lots of interrupt stuff, so if that is > fundamentally broken then our devm ideas won't work out at all. You better not be using devm for your irqs right now then. good luck! greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Make igts for cross-driver stuff strongly suggested
On 28/01/2019 19:22, Daniel Vetter wrote: > Compared to the RFC[1] no changes to the patch itself, but igt moved > forward a lot: > > - gitlab CI builds with: reduced configs/libraries, arm cross build > and a sysroot build (should address all the build/cross platform > concerns raised in the RFC discussions). > > - tests reorganized into subdirectories so that the i915-gem tests > don't clog the main/shared tests directory anymore > > - quite a few more non-intel people contributing/reviewing/committing > igt tests patches. > > I think this addresses all the concerns raised in the RFC discussions, > and assuming there's enough Acks and no new issues that pop up, we can > go ahead with this. > > v2: > - Use "should" (in the usual RFC sense) to make it clear that in the > end this is all up to reviewer's discretion, as usual (Jani). > - Also in the title s/mandatory/strongly suggested/ (me) > - Make it clear we're not going to block features if a testcase is not > feasible, given hw and state of igt, both having some good gaps in > what can be tested (Harry, Eric, Sean, ...). > > 1: https://patchwork.kernel.org/patch/10648851/ > Cc: Petri Latvala > Cc: Arkadiusz Hiler > Cc: Liviu Dudau > Cc: Sean Paul > Cc: Eric Anholt > Cc: Alex Deucher > Cc: Dave Airlie > Cc: Daniel Stone > Cc: "Wentland, Harry" > Cc: Brian Starkey > Reviewed-by: Eric Anholt (v1) > Acked-by: Petri Latvala > Acked-by: Arkadiusz Hiler > Acked-by: Sean Paul > Acked-by: "Wentland, Harry" > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-uapi.rst | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index a752aa561ea4..c9fd23efd957 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -238,6 +238,14 @@ DRM specific patterns. Note that ENOTTY has the slightly > unintuitive meaning of > Testing and validation > == > > +Testing Requirements for userspace API > +-- > + > +New cross-driver userspace interface extensions, like new IOCTL, new KMS > +properties, new files in sysfs or anything else that constitutes an API > change > +should have driver-agnostic testcases in IGT for that feature, if such a test > +can be reasonably made using IGT for the target hardware. > + Acked-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/sun4i: dsi: Change the start delay calculation
On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
wrote:
>
> The current calculation for the video start delay in the current DSI driver
> is that it is the total vertical size, minus the backporch and sync length,
> plus 1.
>
> However, the Allwinner code has it as the active vertical size, plus the
> back porch and the sync length. This doesn't make any difference on the
> only panel it has been tested with so far, since in that particular case
> the front porch is equal to the sum of the back porch and sync length.
>
> This is not the case for all panels, obviously, so we need to fix it. Since
> the Allwinner code has a bunch of extra code to deal with out of bounds
> values, so let's add them as well.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 380fc527a707..e3e4ba90c059 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -357,7 +357,12 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
> static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
>struct drm_display_mode *mode)
> {
> - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
According to the diagram in include/drm/drm_modes.h ,
This is active region plus back porch plus 1, as
sync_end - display = length of front porch and sync
> + u16 delay = (mode->vsync_end + 1) % mode->vtotal;
And this actually means
(length of active region and front porch and sync pulse plus 1) %
total length
So I don't really understand what's happening here. And the modulus
is unexplained.
> +
> + if (!delay)
> + delay = 1;
Same comment as Paul.
ChenYu
> +
> + return delay;
> }
>
> static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
> --
> git-series 0.9.1
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: mark expected switch fall-through
Got it, thanks. On Wed, 30 Jan 2019 at 06:55, Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > This patch fixes the following warning: > > drivers/gpu/drm/nouveau/nouveau_bo.c:1434:53: warning: this statement may > fall through [-Wimplicit-fallthrough=] > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > This patch is part of the ongoing efforts to enabling > -Wimplicit-fallthrough. > > Signed-off-by: Gustavo A. R. Silva > --- > drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c > b/drivers/gpu/drm/nouveau/nouveau_bo.c > index 73eff52036d2..a72be71c45b4 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c > @@ -1434,7 +1434,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, > struct ttm_mem_reg *reg) > if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 || > !mem->kind) > /* untiled */ > break; > - /* fallthrough, tiled memory */ > + /* fall through - tiled memory */ > case TTM_PL_VRAM: > reg->bus.offset = reg->start << PAGE_SHIFT; > reg->bus.base = device->func->resource_addr(device, 1); > -- > 2.20.1 > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 06:17:43PM -0700, Logan Gunthorpe wrote: > > > On 2019-01-29 4:47 p.m., Jerome Glisse wrote: > > The whole point is to allow to use device memory for range of virtual > > address of a process when it does make sense to use device memory for > > that range. So they are multiple cases where it does make sense: > > [1] - Only the device is accessing the range and they are no CPU access > > For instance the program is executing/running a big function on > > the GPU and they are not concurrent CPU access, this is very > > common in all the existing GPGPU code. In fact AFAICT It is the > > most common pattern. So here you can use HMM private or public > > memory. > > [2] - Both device and CPU access a common range of virtul address > > concurrently. In that case if you are on a platform with cache > > coherent inter-connect like OpenCAPI or CCIX then you can use > > HMM public device memory and have both access the same memory. > > You can not use HMM private memory. > > > > So far on x86 we only have PCIE and thus so far on x86 we only have > > private HMM device memory that is not accessible by the CPU in any > > way. > > I feel like you're just moving the rug out from under us... Before you > said ignore HMM and I was asking about the use case that wasn't using > HMM and how it works without HMM. In response, you just give me *way* > too much information describing HMM. And still, as best as I can see, > managing DMA mappings (which is different from the userspace mappings) > for GPU P2P should be handled by HMM and the userspace mappings should > *just* link VMAs to HMM pages using the standard infrastructure we > already have. For HMM P2P mapping we need to call into the driver to know if driver wants to fallback to main memory (running out of BAR addresses) or if it can allow a peer device to directly access its memory. We also need the call to exporting device driver as only the exporting device driver can map the HMM page pfn to some physical BAR address (which would be allocated by driver for GPU). I wanted to make sure the HMM case was understood too, sorry if it caused confusion with the non HMM case which i describe below. > >> And what struct pages are actually going to be backing these VMAs if > >> it's not using HMM? > > > > When you have some range of virtual address migrated to HMM private > > memory then the CPU pte are special swap entry and they behave just > > as if the memory was swapped to disk. So CPU access to those will > > fault and trigger a migration back to main memory. > > This isn't answering my question at all... I specifically asked what is > backing the VMA when we are *not* using HMM. So when you are not using HMM ie existing GPU object without HMM then like i said you do not have any valid pte most of the time inside the CPU page table ie the GPU driver only populate the pte with valid entry when they are CPU page fault and it clear those as soon as the corresponding object is use by the GPU. In fact some driver also unmap it agressively from the BAR making the memory totaly un-accessible to anything but the GPU. GPU driver do not like CPU mapping, they are quite aggressive about clearing them. Then everything i said about having userspace deciding which object can be share, and, with who, do apply here. So for GPU you do want to give control to GPU driver and you do not want to require valid CPU pte for the vma so that the exporting driver can return valid address to the importing peer device only. Also exporting device driver might decide to fallback to main memory (running out of BAR addresses for instance). So again here we want to go through the exporting device driver so that it can take the right action. So the expected pattern (for GPU driver) is: - no valid pte for the special vma (mmap of device file) - importing device call p2p_map() for the vma if it succeed the first time then we expect it will succeed for the same vma and range next time we call it. - exporting driver can either return physical address to page into its BAR space that point to the correct device memory or fallback to main memory Then at any point in time: - if GPU driver want to move the object around (for whatever reasons) it calls zap_vma_ptes() the fact that there is no valid CPU pte does not matter it will call mmu notifier and thus any importing device driver will invalidate its mapping - importing device driver that lost the mapping due to mmu notification can re-map by re-calling p2p_map() (it should check that the vma is still valid ...) and guideline is for the exporting device driver to succeed and return valid address to the new memory use for the object This allow device driver like GPU to keep control. The expected pattern is still the p2p mapping to stay undisrupted for their whole lifetime. Invalidation s
[PATCH v2 2/4] drm/amdgpu: Only add rqs for initialized rings.
I don't see another way to figure out if a ring is initialized if
the hardware block might not be initialized.
Entities have been fixed up to handle num_rqs = 0.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index d85184b5b35c..30407e55593b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -124,6 +124,7 @@ static int amdgpu_ctx_init(struct amdgpu_device *adev,
struct amdgpu_ring *rings[AMDGPU_MAX_RINGS];
struct drm_sched_rq *rqs[AMDGPU_MAX_RINGS];
unsigned num_rings;
+ unsigned num_rqs = 0;
switch (i) {
case AMDGPU_HW_IP_GFX:
@@ -166,12 +167,16 @@ static int amdgpu_ctx_init(struct amdgpu_device *adev,
break;
}
- for (j = 0; j < num_rings; ++j)
- rqs[j] = &rings[j]->sched.sched_rq[priority];
+ for (j = 0; j < num_rings; ++j) {
+ if (rings[j]->adev) {
+ rqs[num_rqs++] =
+ &rings[j]->sched.sched_rq[priority];
+ }
+ }
for (j = 0; j < amdgpu_ctx_num_entities[i]; ++j)
r = drm_sched_entity_init(&ctx->entities[i][j].entity,
- rqs, num_rings, &ctx->guilty);
+ rqs, num_rqs, &ctx->guilty);
if (r)
goto error_cleanup_entities;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/amdgpu: Add command to override the context priority.
Given a master fd we can then override the priority of the context
in another fd.
Using these overrides was recommended by Christian instead of trying
to submit from a master fd, and I am adding a way to override a
single context instead of the entire process so we can only upgrade
a single Vulkan queue and not effectively the entire process.
Reused the flags field as it was checked to be 0 anyways, so nothing
used it. This is source-incompatible (due to the name change), but
ABI compatible.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 41 ++-
include/uapi/drm/amdgpu_drm.h | 3 +-
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
index 0b70410488b6..0767a93e4d91 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
@@ -76,6 +76,39 @@ static int amdgpu_sched_process_priority_override(struct
amdgpu_device *adev,
return 0;
}
+static int amdgpu_sched_context_priority_override(struct amdgpu_device *adev,
+ int fd,
+ unsigned ctx_id,
+ enum drm_sched_priority
priority)
+{
+ struct file *filp = fget(fd);
+ struct amdgpu_fpriv *fpriv;
+ struct amdgpu_ctx *ctx;
+ int r;
+
+ if (!filp)
+ return -EINVAL;
+
+ r = amdgpu_file_to_fpriv(filp, &fpriv);
+ if (r) {
+ fput(filp);
+ return r;
+ }
+
+ ctx = amdgpu_ctx_get(fpriv, ctx_id);
+
+ if (!ctx) {
+ fput(filp);
+ return -EINVAL;
+ }
+
+ amdgpu_ctx_priority_override(ctx, priority);
+ amdgpu_ctx_put(ctx);
+ fput(filp);
+
+ return 0;
+}
+
int amdgpu_sched_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
{
@@ -85,7 +118,7 @@ int amdgpu_sched_ioctl(struct drm_device *dev, void *data,
int r;
priority = amdgpu_to_sched_priority(args->in.priority);
- if (args->in.flags || priority == DRM_SCHED_PRIORITY_INVALID)
+ if (priority == DRM_SCHED_PRIORITY_INVALID)
return -EINVAL;
switch (args->in.op) {
@@ -94,6 +127,12 @@ int amdgpu_sched_ioctl(struct drm_device *dev, void *data,
args->in.fd,
priority);
break;
+ case AMDGPU_SCHED_OP_CONTEXT_PRIORITY_OVERRIDE:
+ r = amdgpu_sched_context_priority_override(adev,
+ args->in.fd,
+ args->in.ctx_id,
+ priority);
+ break;
default:
DRM_ERROR("Invalid sched op specified: %d\n", args->in.op);
r = -EINVAL;
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index faaad04814e4..30fa340790b2 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -275,13 +275,14 @@ union drm_amdgpu_vm {
/* sched ioctl */
#define AMDGPU_SCHED_OP_PROCESS_PRIORITY_OVERRIDE 1
+#define AMDGPU_SCHED_OP_CONTEXT_PRIORITY_OVERRIDE 2
struct drm_amdgpu_sched_in {
/* AMDGPU_SCHED_OP_* */
__u32 op;
__u32 fd;
__s32 priority;
- __u32 flags;
+ __u32 ctx_id;
};
union drm_amdgpu_sched {
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/amdgpu: Check if fd really is an amdgpu fd.
Otherwise we interpret the file private data as drm & amdgpu data
while it might not be, possibly allowing one to get memory corruption.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 10 +++---
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d67f8b1dfe80..17290cdb8ed8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -411,6 +411,8 @@ struct amdgpu_fpriv {
struct amdgpu_ctx_mgr ctx_mgr;
};
+int amdgpu_file_to_fpriv(struct file *filp, struct amdgpu_fpriv **fpriv);
+
int amdgpu_ib_get(struct amdgpu_device *adev, struct amdgpu_vm *vm,
unsigned size, struct amdgpu_ib *ib);
void amdgpu_ib_free(struct amdgpu_device *adev, struct amdgpu_ib *ib,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index c806f984bcc5..90a520034c89 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1176,6 +1176,22 @@ static const struct file_operations
amdgpu_driver_kms_fops = {
#endif
};
+int amdgpu_file_to_fpriv(struct file *filp, struct amdgpu_fpriv **fpriv)
+{
+struct drm_file *file;
+
+ if (!filp)
+ return -EINVAL;
+
+ if (filp->f_op != &amdgpu_driver_kms_fops) {
+ return -EINVAL;
+ }
+
+ file = filp->private_data;
+ *fpriv = file->driver_priv;
+ return 0;
+}
+
static bool
amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
bool in_vblank_irq, int *vpos, int *hpos,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
index 1cafe8d83a4d..0b70410488b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
@@ -54,16 +54,20 @@ static int amdgpu_sched_process_priority_override(struct
amdgpu_device *adev,
enum drm_sched_priority
priority)
{
struct file *filp = fget(fd);
- struct drm_file *file;
struct amdgpu_fpriv *fpriv;
struct amdgpu_ctx *ctx;
uint32_t id;
+ int r;
if (!filp)
return -EINVAL;
- file = filp->private_data;
- fpriv = file->driver_priv;
+ r = amdgpu_file_to_fpriv(filp, &fpriv);
+ if (r) {
+ fput(filp);
+ return r;
+ }
+
idr_for_each_entry(&fpriv->ctx_mgr.ctx_handles, ctx, id)
amdgpu_ctx_priority_override(ctx, priority);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/sched: Fix entities with 0 rqs.
Some blocks in amdgpu can have 0 rqs.
Job creation already fails with -ENOENT when entity->rq is NULL,
so jobs cannot be pushed. Without a rq there is no scheduler to
pop jobs, and rq selection already does the right thing with a
list of length 0.
So the operations we need to fix are:
- Creation, do not set rq to rq_list[0] if the list can have length 0.
- Do not flush any jobs when there is no rq.
- On entity destruction handle the rq = NULL case.
- on set_priority, do not try to change the rq if it is NULL.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/scheduler/sched_entity.c | 39
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 4463d3826ecb..8e31b6628d09 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -52,12 +52,12 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
{
int i;
- if (!(entity && rq_list && num_rq_list > 0 && rq_list[0]))
+ if (!(entity && rq_list && (num_rq_list == 0 || rq_list[0])))
return -EINVAL;
memset(entity, 0, sizeof(struct drm_sched_entity));
INIT_LIST_HEAD(&entity->list);
- entity->rq = rq_list[0];
+ entity->rq = NULL;
entity->guilty = guilty;
entity->num_rq_list = num_rq_list;
entity->rq_list = kcalloc(num_rq_list, sizeof(struct drm_sched_rq *),
@@ -67,6 +67,10 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
for (i = 0; i < num_rq_list; ++i)
entity->rq_list[i] = rq_list[i];
+
+ if (num_rq_list)
+ entity->rq = rq_list[0];
+
entity->last_scheduled = NULL;
spin_lock_init(&entity->rq_lock);
@@ -165,6 +169,9 @@ long drm_sched_entity_flush(struct drm_sched_entity
*entity, long timeout)
struct task_struct *last_user;
long ret = timeout;
+ if (!entity->rq)
+ return 0;
+
sched = entity->rq->sched;
/**
* The client will not queue more IBs during this fini, consume existing
@@ -264,20 +271,24 @@ static void drm_sched_entity_kill_jobs(struct
drm_sched_entity *entity)
*/
void drm_sched_entity_fini(struct drm_sched_entity *entity)
{
- struct drm_gpu_scheduler *sched;
+ struct drm_gpu_scheduler *sched = NULL;
- sched = entity->rq->sched;
- drm_sched_rq_remove_entity(entity->rq, entity);
+ if (entity->rq) {
+ sched = entity->rq->sched;
+ drm_sched_rq_remove_entity(entity->rq, entity);
+ }
/* Consumption of existing IBs wasn't completed. Forcefully
* remove them here.
*/
if (spsc_queue_peek(&entity->job_queue)) {
- /* Park the kernel for a moment to make sure it isn't processing
-* our enity.
-*/
- kthread_park(sched->thread);
- kthread_unpark(sched->thread);
+ if (sched) {
+ /* Park the kernel for a moment to make sure it isn't
processing
+* our enity.
+*/
+ kthread_park(sched->thread);
+ kthread_unpark(sched->thread);
+ }
if (entity->dependency) {
dma_fence_remove_callback(entity->dependency,
&entity->cb);
@@ -362,9 +373,11 @@ void drm_sched_entity_set_priority(struct drm_sched_entity
*entity,
for (i = 0; i < entity->num_rq_list; ++i)
drm_sched_entity_set_rq_priority(&entity->rq_list[i], priority);
- drm_sched_rq_remove_entity(entity->rq, entity);
- drm_sched_entity_set_rq_priority(&entity->rq, priority);
- drm_sched_rq_add_entity(entity->rq, entity);
+ if (entity->rq) {
+ drm_sched_rq_remove_entity(entity->rq, entity);
+ drm_sched_entity_set_rq_priority(&entity->rq, priority);
+ drm_sched_rq_add_entity(entity->rq, entity);
+ }
spin_unlock(&entity->rq_lock);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 11:02:25PM +, Jason Gunthorpe wrote: > On Tue, Jan 29, 2019 at 03:44:00PM -0500, Jerome Glisse wrote: > > > > But this API doesn't seem to offer any control - I thought that > > > control was all coming from the mm/hmm notifiers triggering p2p_unmaps? > > > > The control is within the driver implementation of those callbacks. > > Seems like what you mean by control is 'the exporter gets to choose > the physical address at the instant of map' - which seems reasonable > for GPU. > > > > will only allow p2p map to succeed for objects that have been tagged by the > > userspace in some way ie the userspace application is in control of what > > can be map to peer device. > > I would have thought this means the VMA for the object is created > without the map/unmap ops? Or are GPU objects and VMAs unrelated? GPU object and VMA are unrelated in all open source GPU driver i am somewhat familiar with (AMD, Intel, NVidia). You can create a GPU object and never map it (and thus never have it associated with a vma) and in fact this is very common. For graphic you usualy only have hand full of the hundreds of GPU object your application have mapped. The control for peer to peer can also be a mutable properties of the object ie userspace do ioctl on the GPU driver which create an object; Some times after the object is created the userspace do others ioctl to allow to export the object to another specific device again this result in ioctl to the device driver, those ioctl set flags and update GPU object kernel structure with all the info. In the meantime you have no control on when other driver might call the vma p2p call backs. So you must have register the vma with vm_operations that include the p2p_map and p2p_unmap. Those driver function will check the object kernel structure each time they get call and act accordingly. > > For moving things around after a successful p2p_map yes the exporting > > device have to call for instance zap_vma_ptes() or something > > similar. > > Okay, great, RDMA needs this flow for hotplug - we zap the VMA's when > unplugging the PCI device and we can delay the PCI unplug completion > until all the p2p_unmaps are called... > > But in this case a future p2p_map will have to fail as the BAR no > longer exists. How to handle this? So the comment above the callback (i should write more thorough guideline and documentation) state that export should/(must?) be predictable ie if an importer device calls p2p_map() once on a vma and it does succeed then if the same device calls again p2p_map() on the same vma and if the vma is still valid (ie no unmap or does not correspond to a different object ...) then the p2p_map() should/(must?) succeed. The idea is that the importer would do a first call to p2p_map() when it setup its own object, report failure to userspace if that fails. If it does succeed then we should never have an issue next time we call p2p_map() (after mapping being invalidated by mmu notifier for instance). So it will succeed just like the first call (again assuming the vma is still valid). Idea is that we can only ask exporter to be predictable and still allow them to fail if things are really going bad. > > > I would think that the importing driver can assume the BAR page is > > > kept alive until it calls unmap (presumably triggered by notifiers)? > > > > > > ie the exporting driver sees the BAR page as pinned until unmap. > > > > The intention with this patchset is that it is not pin ie the importer > > device _must_ abide by all mmu notifier invalidations and they can > > happen at anytime. The importing device can however re-p2p_map the > > same range after an invalidation. > > > > I would like to restrict this to importer that can invalidate for > > now because i believe all the first device to use can support the > > invalidation. > > This seems reasonable (and sort of says importers not getting this > from HMM need careful checking), was this in the comment above the > ops? I think i put it in the comment above the ops but in any cases i should write something in documentation with example and thorough guideline. Note that there won't be any mmu notifier to mmap of a device file unless the device driver calls for it or there is a syscall like munmap or mremap or mprotect well any syscall that work on vma. So assuming the application is no doing something stupid, nor the driver. Then the result of p2p_map can stay valid until the importer is done and call p2p_unmap of its own free will. This is what i do expect for this. But for GPU i would still like to allow GPU driver to evict (and thus invalidate importer mapping) to main memory or defragment their BAR address space if the GPU driver feels a pressing need to do so. If we ever want to support full pin then we might have to add a flag so that GPU driver can refuse an importer that wants things pin forever. Cheers, Jérôme ___ dri
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 03:58:45PM -0700, Logan Gunthorpe wrote: > > > On 2019-01-29 2:50 p.m., Jerome Glisse wrote: > > No this is the non HMM case i am talking about here. Fully ignore HMM > > in this frame. A GPU driver that do not support or use HMM in anyway > > has all the properties and requirement i do list above. So all the points > > i was making are without HMM in the picture whatsoever. I should have > > posted this a separate patches to avoid this confusion. > > > > Regarding your HMM question. You can not map HMM pages, all code path > > that would try that would trigger a migration back to regular memory > > and will use the regular memory for CPU access. > > > > I thought this was the whole point of HMM... And eventually it would > support being able to map the pages through the BAR in cooperation with > the driver. If not, what's that whole layer for? Why not just have HMM > handle this situation? The whole point is to allow to use device memory for range of virtual address of a process when it does make sense to use device memory for that range. So they are multiple cases where it does make sense: [1] - Only the device is accessing the range and they are no CPU access For instance the program is executing/running a big function on the GPU and they are not concurrent CPU access, this is very common in all the existing GPGPU code. In fact AFAICT It is the most common pattern. So here you can use HMM private or public memory. [2] - Both device and CPU access a common range of virtul address concurrently. In that case if you are on a platform with cache coherent inter-connect like OpenCAPI or CCIX then you can use HMM public device memory and have both access the same memory. You can not use HMM private memory. So far on x86 we only have PCIE and thus so far on x86 we only have private HMM device memory that is not accessible by the CPU in any way. It does not make that memory useless, far from it. Having only the device work on the dataset while CPU is either waiting or accessing something else is very common. Then HMM is a toolbox, so here are some of the tools: HMM mirror - helper to mirror process address on to a device ie this is SVM(Share Virtual Memory)/SVA(Share Virtual Address) in software HMM private memory - allow to register device memory with the linux kernel. The memory is not CPU accessible. The memory is fully manage by the device driver. What and when to migrate is under the control of the device driver. HMM public memory - allow to register device memory with the linux kernel. The memory must be CPU accessible and cache coherent and abide by the platform memory model. The memory is fully manage by the device driver because otherwise it would disrupt the device driver operation (for instance GPU can also be use for graphics). Migration - helper to perform migration to and from device memory. It does not make any decission on itself it just perform all the steps in the right order and call back into the driver to get the migration going. It is up to device driver to implement heuristic and provide userspace API to control memory migration to and from device memory. For device private memory on CPU page fault the kernel will force a migration back to system memory so that the CPU can access the memory. What matter here is that the memory model of the platform is intact and thus you can safely use CPU atomic operation or rely on your platform memory model for your program. Note that long term i would like to define common API to expose to userspace to manage memory binding to specific device memory so that we can mix and match multiple device memory into a single process and define policy too. Also CPU atomic instruction to PCIE BAR gives _undefined_ results and in fact on some AMD/Intel platform it leads to weirdness/crash/freeze. So obviously we can not map PCIE BAR to CPU without breaking the memory model. More over on PCIE you might not be able to resize the BAR to expose all the device memory. GPU can have several giga bytes of memory and not all of them support PCIE bar resize, and sometimes PCIE bar resize does not work either because of bios/firmware issue or simply because you are running out of IO space. So on x86 we are stuck with HMM private memory, i am hopping that some day in the future we will have CCIX or something similar. But for now we have to work with what we have. > And what struct pages are actually going to be backing these VMAs if > it's not using HMM? When you have some range of virtual address migrated to HMM private memory then the CPU pte are special swap entry and they behave just as if the memory was swapped to disk. So CPU access to those will fault and trigger a migration back to main memory. We still want to allow peer to peer to exist when using HMM memory for a range of virtual address (of a vma that is not
Re: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
On Tue, Jan 29, 2019 at 8:27 PM Greg KH wrote:
>
> On Tue, Jan 29, 2019 at 07:10:55PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 29, 2019 at 6:36 PM Greg KH wrote:
> > >
> > > On Tue, Jan 29, 2019 at 05:50:05PM +0100, Daniel Vetter wrote:
> > > > On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
> > > > >
> > > > >
> > > > > Den 24.01.2019 18.57, skrev Daniel Vetter:
> > > > > > On Thu, Jan 24, 2019 at 6:46 PM Greg KH
> > > > > > wrote:
> > > > > >>
> > > > > >> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> > > > > >>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
> > > > >
> > > > >
> > > > > Den 22.01.2019 20.30, skrev Daniel Vetter:
> > > > > > On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes
> > > > > > wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Den 22.01.2019 10.32, skrev Daniel Vetter:
> > > > > >>> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes
> > > > > >>> wrote:
> > > > >
> > > > >
> > > > > Den 21.01.2019 10.55, skrev Daniel Vetter:
> > > > > > On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter
> > > > > > wrote:
> > > > > >> On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes
> > > > > >> wrote:
> > > > > >>> This adds resource managed (devres) versions of
> > > > > >>> drm_dev_init() and
> > > > > >>> drm_dev_register().
> > > > > >>>
> > > > > >>> Also added is devm_drm_dev_register_with_fbdev() which
> > > > > >>> sets up generic
> > > > > >>> fbdev emulation as well.
> > > > > >>>
> > > > > >>> devm_drm_dev_register() isn't exported since there are no
> > > > > >>> users.
> > > > > >>>
> > > > > >>> Signed-off-by: Noralf Trønnes
> > > > > >>
> > > > >
> > > > >
> > > > >
> > > > > >>> diff --git a/drivers/gpu/drm/drm_drv.c
> > > > > >>> b/drivers/gpu/drm/drm_drv.c
> > > > > >>> index 381581b01d48..12129772be45 100644
> > > > > >>> --- a/drivers/gpu/drm/drm_drv.c
> > > > > >>> +++ b/drivers/gpu/drm/drm_drv.c
> > > > > >>> @@ -36,6 +36,7 @@
> > > > > >>>
> > > > > >>> #include
> > > > > >>> #include
> > > > > >>> +#include
> > > > > >>> #include
> > > > > >>>
> > > > > >>> #include "drm_crtc_internal.h"
> > > > > >>> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct
> > > > > >>> drm_device *dev)
> > > > > >>> }
> > > > > >>> EXPORT_SYMBOL(drm_dev_unregister);
> > > > > >>>
> > > > > >>> +static void devm_drm_dev_init_release(void *data)
> > > > > >>> +{
> > > > > >>> + drm_dev_put(data);
> > > > > >
> > > > > > We need drm_dev_unplug() here, or this isn't safe.
> > > > >
> > > > > This function is only used to cover the error path if probe
> > > > > fails before
> > > > > devm_drm_dev_register() is called.
> > > > > devm_drm_dev_register_release() is
> > > > > the one that calls unplug. There are comments about this in
> > > > > the functions.
> > > > > >>>
> > > > > >>> I think I get a prize for being ignorant and blind :-/
> > > > > >>>
> > > > >
> > > > > >
> > > > > >>> +}
> > > > > >>> +
> > > > > >>> +/**
> > > > > >>> + * devm_drm_dev_init - Resource managed drm_dev_init()
> > > > > >>> + * @parent: Parent device object
> > > > > >>> + * @dev: DRM device
> > > > > >>> + * @driver: DRM driver
> > > > > >>> + *
> > > > > >>> + * Managed drm_dev_init(). The DRM device initialized
> > > > > >>> with this function is
> > > > > >>> + * automatically released on driver detach. You must
> > > > > >>> supply a
> > > > > >
> > > > > > I think a bit more clarity here would be good:
> > > > > >
> > > > > > "... automatically released on driver unbind by callind
> > > > > > drm_dev_unplug()."
> > > > > >
> > > > > >>> + * &drm_driver.release callback to control the
> > > > > >>> finalization explicitly.
> > > > > >
> > > > > > I think a loud warning for these is in order:
> > > > > >
> > > > > > "WARNING:
> > > > > >
> > > > > > "In generally it is unsafe to use devm functions for drm
> > > > > > structures
> > > > > > because the lifetimes of &drm_device and the underlying
> > > > > > &device do not
> > > > > > match. This here works because it doesn't immediately free
> > > > > > anything, but
> > > > > > only calls drm_dev_unplug(), which internally decrements
> > > > > > the &drm_device
> > > > > > r
Re: [PATCH] drm/nouveau: Don't WARN_ON VCPI allocation failures
Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: f479c0ba4a17 drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream. The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96. v4.20.5: Build OK! v4.19.18: Build OK! v4.14.96: Failed to apply! Possible dependencies: Unable to calculate How should we proceed with this patch? -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm-intel-fixes tree
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/intel_display.c: In function 'has_bogus_dpll_config':
drivers/gpu/drm/i915/intel_display.c:15432:27: error: macro "IS_GEN" requires 3
arguments, but only 2 given
return IS_GEN(dev_priv, 6) &&
^
Caused by commit
a49a17226feb ("drm/i915: Try to sanitize bogus DPLL state left over by broken
SNB BIOSen")
It seems this was cherry-picked incorrectly :-(
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpC5vV1Y8Z4N.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 02:30:49PM -0700, Logan Gunthorpe wrote: > > > On 2019-01-29 1:57 p.m., Jerome Glisse wrote: > > GPU driver must be in control and must be call to. Here there is 2 cases > > in this patchset and i should have instead posted 2 separate patchset as > > it seems that it is confusing things. > > > > For the HMM page, the physical address of the page ie the pfn does not > > correspond to anything ie there is nothing behind it. So the importing > > device has no idea how to get a valid physical address from an HMM page > > only the device driver exporting its memory with HMM device memory knows > > that. > > > > > > For the special vma ie mmap of a device file. GPU driver do manage their > > BAR ie the GPU have a page table that map BAR page to GPU memory and the > > driver _constantly_ update this page table, it is reflected by invalidating > > the CPU mapping. In fact most of the time the CPU mapping of GPU object are > > invalid they are valid only a small fraction of their lifetime. So you > > _must_ have some call to inform the exporting device driver that another > > device would like to map one of its vma. The exporting device can then > > try to avoid as much churn as possible for the importing device. But this > > has consequence and the exporting device driver must be allow to apply > > policy and make decission on wether or not it authorize the other device > > to peer map its memory. For GPU the userspace application have to call > > specific API that translate into specific ioctl which themself set flags > > on object (in the kernel struct tracking the user space object). The only > > way to allow program predictability is if the application can ask and know > > if it can peer export an object (ie is there enough BAR space left). > > This all seems like it's an HMM problem and not related to mapping > BARs/"potential BARs" to userspace. If some code wants to DMA map HMM > pages, it calls an HMM function to map them. If HMM needs to consult > with the driver on aspects of how that's mapped, then that's between HMM > and the driver and not something I really care about. But making the > entire mapping stuff tied to userspace VMAs does not make sense to me. > What if somebody wants to map some HMM pages in the same way but from > kernel space and they therefore don't have a VMA? No this is the non HMM case i am talking about here. Fully ignore HMM in this frame. A GPU driver that do not support or use HMM in anyway has all the properties and requirement i do list above. So all the points i was making are without HMM in the picture whatsoever. I should have posted this a separate patches to avoid this confusion. Regarding your HMM question. You can not map HMM pages, all code path that would try that would trigger a migration back to regular memory and will use the regular memory for CPU access. > >> I also figured there'd be a fault version of p2p_ioremap_device_memory() > >> for when you are mapping P2P memory and you want to assign the pages > >> lazily. Though, this can come later when someone wants to implement that. > > > > For GPU the BAR address space is manage page by page and thus you do not > > want to map a range of BAR addresses but you want to allow mapping of > > multiple page of BAR address that are not adjacent to each other nor > > ordered in anyway. But providing helper for simpler device does make sense. > > Well, this has little do with the backing device but how the memory is > mapped into userspace. With p2p_ioremap_device_memory() the entire range > is mapped into the userspace VMA immediately during the call to mmap(). > With p2p_fault_device_memory(), mmap() would not actually map anything > and a page in the VMA would be mapped only when userspace accesses it > (using fault()). It seems to me like GPUs would prefer the latter but if > HMM takes care of the mapping from userspace potential pages to actual > GPU pages through the BAR then that may not be true. Again HMM has nothing to do here, ignore HMM it does not play any role and it is not involve in anyway here. GPU want to control what object they allow other device to access and object they do not allow. GPU driver _constantly_ invalidate the CPU page table and in fact the CPU page table do not have any valid pte for a vma that is an mmap of GPU device file for most of the vma lifetime. Changing that would highly disrupt and break GPU drivers. They need to control that, they need to control what to do if another device tries to peer map some of their memory. Hence why they need to implement the callback and decide on wether or not they allow the peer mapping or use device memory for it (they can decide to fallback to main memory). If the exporter can not control than this is useless to GPU driver. I would rather not exclude GPU driver from this. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesk
[Bug 109403] amdgpu randomly hangs while streaming or when CPU is busy on X399 with TR 1950X
https://bugs.freedesktop.org/show_bug.cgi?id=109403 --- Comment #2 from Chris --- I wonder if this is related to your motherboard. I have an ASUS Zenith with a 1950X, 128GB RAM and a Vega 64 LC that have been on Kernel 4.20 through 5.0-rc4. The latter of which I'm currently on. I have no kernel parameters on my grub file, only the default 'splash quiet'. I have never ran into hangs while gaming, using youtube, OBS nor compiling the linux kernel. Just thought I would share my similar configuration. I can only suggest try updating and or downgrading your BIOS? -- 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: Constify drm_color_lut_check()
On Tue, Jan 29, 2019 at 08:04:18PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 07:58:56PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote:
> > > Hi Ville.
> > >
> > > On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > drm_color_lut_check() doens't modify the passed in blob so
> > > > let's make it const.
> > > >
> > > > Also s/uint32_y/u32/ while at it.
> > > >
> > > > Cc: Matt Roper
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/drm_color_mgmt.c | 6 +++---
> > > > include/drm/drm_color_mgmt.h | 4 ++--
> > > > 2 files changed, 5 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > > > b/drivers/gpu/drm/drm_color_mgmt.c
> > > > index 968ca7c91ad8..3c8826a91a03 100644
> > > > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > > > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > > > @@ -474,10 +474,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
> > > > *
> > > > * Returns 0 on success, -EINVAL on failure.
> > > > */
> > > > -int drm_color_lut_check(struct drm_property_blob *lut,
> > > > - uint32_t tests)
> > > > +int drm_color_lut_check(const struct drm_property_blob *lut,
> > > > + u32 tests)
> > >
> > > No need to linewrap this line.
> > > > {
> > > > - struct drm_color_lut *entry;
> > > > + const struct drm_color_lut *entry;
> > > > int i;
> > > >
> > > > if (!lut || !tests)
> > > > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> > > > index 6affbda6d9cb..58d4b20b5b97 100644
> > > > --- a/include/drm/drm_color_mgmt.h
> > > > +++ b/include/drm/drm_color_mgmt.h
> > > > @@ -96,6 +96,6 @@ enum drm_color_lut_tests {
> > > > DRM_COLOR_LUT_NON_DECREASING = BIT(1),
> > > > };
> > > >
> > > > -int drm_color_lut_check(struct drm_property_blob *lut,
> > > > - uint32_t tests);
> > > > +int drm_color_lut_check(const struct drm_property_blob *lut,
> > > > + u32 tests);
> > > Likewise.
> > >
> > > With the linewrap fixed:
> > > Reviewed-by: Sam Ravnborg
> >
> > Thanks.
> >
> > >
> > > Note: does not apply to my drm-misc tree. Anything I miss here?
> >
> > I think it was merged via drm-intel.
>
> Acked-by: Daniel Vetter
>
> for merging through drm-intel then (assuming it goes in before the merge
> cutoff), with Sam's suggestions ofc.
Fixed up and pushed to dinq. Thanks for the review.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 3:25 PM Logan Gunthorpe wrote: > > > > On 2019-01-29 12:56 p.m., Alex Deucher wrote: > > On Tue, Jan 29, 2019 at 12:47 PM wrote: > >> > >> From: Jérôme Glisse > >> > >> device_test_p2p() return true if two devices can peer to peer to > >> each other. We add a generic function as different inter-connect > >> can support peer to peer and we want to genericaly test this no > >> matter what the inter-connect might be. However this version only > >> support PCIE for now. > >> > > > > What about something like these patches: > > https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p&id=4fab9ff69cb968183f717551441b475fabce6c1c > > https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p&id=f90b12d41c277335d08c9dab62433f27c0fadbe5 > > They are a bit more thorough. > > Those new functions seem to have a lot of overlap with the code that is > already upstream in p2pdma Perhaps you should be improving the > p2pdma functions if they aren't suitable for what you want already > instead of creating new ones. Could be. Those patches are pretty old. They probably need to be rebased on the latest upstream p2p stuff. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 01:44:09PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 12:44 p.m., Greg Kroah-Hartman wrote:
> > On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> >>> +bool pci_test_p2p(struct device *devA, struct device *devB)
> >>> +{
> >>> + struct pci_dev *pciA, *pciB;
> >>> + bool ret;
> >>> + int tmp;
> >>> +
> >>> + /*
> >>> + * For now we only support PCIE peer to peer but other inter-connect
> >>> + * can be added.
> >>> + */
> >>> + pciA = find_parent_pci_dev(devA);
> >>> + pciB = find_parent_pci_dev(devB);
> >>> + if (pciA == NULL || pciB == NULL) {
> >>> + ret = false;
> >>> + goto out;
> >>> + }
> >>> +
> >>> + tmp = upstream_bridge_distance(pciA, pciB, NULL);
> >>> + ret = tmp < 0 ? false : true;
> >>> +
> >>> +out:
> >>> + pci_dev_put(pciB);
> >>> + pci_dev_put(pciA);
> >>> + return false;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(pci_test_p2p);
> >>
> >> This function only ever returns false
> >
> > I guess it was nevr actually tested :(
> >
> > I feel really worried about passing random 'struct device' pointers into
> > the PCI layer. Are we _sure_ it can handle this properly?
>
> Yes, there are a couple of pci_p2pdma functions that take struct devices
> directly simply because it's way more convenient for the caller. That's
> what find_parent_pci_dev() takes care of (it returns false if the device
> is not a PCI device). Whether that's appropriate here is hard to say
> seeing we haven't seen any caller code.
Caller code as a reference (i already given that link in other part of
thread but just so that people don't have to follow all branches).
https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-p2p&id=401a567696eafb1d4faf7054ab0d7c3a16a5ef06
Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 01:39:49PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 12:32 p.m., Jason Gunthorpe wrote:
> > Jerome, I think it would be nice to have a helper scheme - I think the
> > simple case would be simple remapping of PCI BAR memory, so if we
> > could have, say something like:
> >
> > static const struct vm_operations_struct my_ops {
> > .p2p_map = p2p_ioremap_map_op,
> > .p2p_unmap = p2p_ioremap_unmap_op,
> > }
> >
> > struct ioremap_data {
> > [..]
> > }
> >
> > fops_mmap() {
> >vma->private_data = &driver_priv->ioremap_data;
> >return p2p_ioremap_device_memory(vma, exporting_device, [..]);
> > }
>
> This is roughly what I was expecting, except I don't see exactly what
> the p2p_map and p2p_unmap callbacks are for. The importing driver should
> see p2pdma/hmm struct pages and use the appropriate function to map
> them. It shouldn't be the responsibility of the exporting driver to
> implement the mapping. And I don't think we should have 'special' vma's
> for this (though we may need something to ensure we don't get mapping
> requests mixed with different types of pages...).
GPU driver must be in control and must be call to. Here there is 2 cases
in this patchset and i should have instead posted 2 separate patchset as
it seems that it is confusing things.
For the HMM page, the physical address of the page ie the pfn does not
correspond to anything ie there is nothing behind it. So the importing
device has no idea how to get a valid physical address from an HMM page
only the device driver exporting its memory with HMM device memory knows
that.
For the special vma ie mmap of a device file. GPU driver do manage their
BAR ie the GPU have a page table that map BAR page to GPU memory and the
driver _constantly_ update this page table, it is reflected by invalidating
the CPU mapping. In fact most of the time the CPU mapping of GPU object are
invalid they are valid only a small fraction of their lifetime. So you
_must_ have some call to inform the exporting device driver that another
device would like to map one of its vma. The exporting device can then
try to avoid as much churn as possible for the importing device. But this
has consequence and the exporting device driver must be allow to apply
policy and make decission on wether or not it authorize the other device
to peer map its memory. For GPU the userspace application have to call
specific API that translate into specific ioctl which themself set flags
on object (in the kernel struct tracking the user space object). The only
way to allow program predictability is if the application can ask and know
if it can peer export an object (ie is there enough BAR space left).
Moreover i would like to be able to use this API between GPUs that are
inter-connected between each other and for those the CPU page table are
just invalid and the physical address to use are only meaning full to the
exporting and importing device. So again here core kernel has no idea of
what the physical address would be.
So in both cases, at very least for GPU, we do want total control to be
given to the exporter.
>
> I also figured there'd be a fault version of p2p_ioremap_device_memory()
> for when you are mapping P2P memory and you want to assign the pages
> lazily. Though, this can come later when someone wants to implement that.
For GPU the BAR address space is manage page by page and thus you do not
want to map a range of BAR addresses but you want to allow mapping of
multiple page of BAR address that are not adjacent to each other nor
ordered in anyway. But providing helper for simpler device does make sense.
Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 08:24:36PM +, Jason Gunthorpe wrote: > On Tue, Jan 29, 2019 at 02:50:55PM -0500, Jerome Glisse wrote: > > > GPU driver do want more control :) GPU driver are moving things around > > all the time and they have more memory than bar space (on newer platform > > AMD GPU do resize the bar but it is not the rule for all GPUs). So > > GPU driver do actualy manage their BAR address space and they map and > > unmap thing there. They can not allow someone to just pin stuff there > > randomly or this would disrupt their regular work flow. Hence they need > > control and they might implement threshold for instance if they have > > more than N pages of bar space map for peer to peer then they can decide > > to fall back to main memory for any new peer mapping. > > But this API doesn't seem to offer any control - I thought that > control was all coming from the mm/hmm notifiers triggering p2p_unmaps? The control is within the driver implementation of those callbacks. So driver implementation can refuse to map by returning an error on p2p_map or it can decide to use main memory by migrating its object to main memory and populating the dma address array with dma_page_map() of the main memory pages. Driver like GPU can have policy on top of that for instance they will only allow p2p map to succeed for objects that have been tagged by the userspace in some way ie the userspace application is in control of what can be map to peer device. This is needed for GPU driver as we do want userspace involvement on what object are allowed to have p2p access and also so that we can report to userspace when we are running out of BAR addresses for this to work as intended (ie not falling back to main memory) so that application can take appropriate actions (like decide what to prioritize). For moving things around after a successful p2p_map yes the exporting device have to call for instance zap_vma_ptes() or something similar. This will trigger notifier call and the importing device will invalidate its mapping. Once it is invalidated then the exporting device can point new call of p2p_map (for the same range) to new memory (obviously the exporting device have to synchronize any concurrent call to p2p_map with the invalidation). > > I would think that the importing driver can assume the BAR page is > kept alive until it calls unmap (presumably triggered by notifiers)? > > ie the exporting driver sees the BAR page as pinned until unmap. The intention with this patchset is that it is not pin ie the importer device _must_ abide by all mmu notifier invalidations and they can happen at anytime. The importing device can however re-p2p_map the same range after an invalidation. I would like to restrict this to importer that can invalidate for now because i believe all the first device to use can support the invalidation. Also when using HMM private device memory we _can not_ pin virtual address to device memory as otherwise CPU access would have to SIGBUS or SEGFAULT and we do not want that. So this was also a motivation to keep thing consistent for the importer for both cases. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
On Tue, Jan 29, 2019 at 01:39:25PM -0500, Lyude Paul wrote: > In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call > drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we > never successfully allocated VCPI to it. This is contrary to what we do > in drm_dp_mst_allocate_vcpi(), where we only call > drm_dp_mst_get_port_malloc() on the passed port if we successfully > allocated VCPI to it. > > As a result, if drm_dp_mst_allocate_vcpi() fails during a modeset and > another successive modeset calls drm_dp_mst_deallocate_vcpi() we will > end up dropping someone else's malloc reference to the port. Example: > > [ 962.309260] > == > [ 962.309290] BUG: KASAN: use-after-free in > drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] > [ 962.309296] Read of size 4 at addr 888416c30004 by task > kworker/0:1H/500 > > [ 962.309308] CPU: 0 PID: 500 Comm: kworker/0:1H Tainted: GW O > 5.0.0-rc2Lyude-Test+ #1 > [ 962.309313] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W > (1.12 ) 04/09/2018 > [ 962.309428] Workqueue: events_highpri intel_atomic_cleanup_work [i915] > [ 962.309434] Call Trace: > [ 962.309452] dump_stack+0xad/0x150 > [ 962.309462] ? dump_stack_print_info.cold.0+0x1b/0x1b > [ 962.309472] ? kmsg_dump_rewind_nolock+0xd9/0xd9 > [ 962.309504] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] > [ 962.309515] print_address_description+0x6c/0x23c > [ 962.309542] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] > [ 962.309568] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] > [ 962.309577] kasan_report.cold.3+0x1a/0x32 > [ 962.309605] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] > [ 962.309631] drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] > [ 962.309658] ? drm_dp_mst_put_mstb_malloc+0x180/0x180 [drm_kms_helper] > [ 962.309687] drm_dp_mst_destroy_state+0xcd/0x120 [drm_kms_helper] > [ 962.309745] drm_atomic_state_default_clear+0x6ee/0xcc0 [drm] > [ 962.309864] intel_atomic_state_clear+0xe/0x80 [i915] > [ 962.309928] __drm_atomic_state_free+0x35/0xd0 [drm] > [ 962.310044] intel_atomic_cleanup_work+0x56/0x70 [i915] > [ 962.310057] process_one_work+0x884/0x1400 > [ 962.310067] ? drain_workqueue+0x5a0/0x5a0 > [ 962.310075] ? __schedule+0x87f/0x1e80 > [ 962.310086] ? __sched_text_start+0x8/0x8 > [ 962.310095] ? run_rebalance_domains+0x400/0x400 > [ 962.310110] ? deref_stack_reg+0xb4/0x120 > [ 962.310117] ? __read_once_size_nocheck.constprop.7+0x10/0x10 > [ 962.310124] ? worker_enter_idle+0x47f/0x6a0 > [ 962.310134] ? schedule+0xd7/0x2e0 > [ 962.310141] ? __schedule+0x1e80/0x1e80 > [ 962.310148] ? _raw_spin_lock_irq+0x9f/0x130 > [ 962.310155] ? _raw_write_unlock_irqrestore+0x110/0x110 > [ 962.310164] worker_thread+0x196/0x11e0 > [ 962.310175] ? set_load_weight+0x2e0/0x2e0 > [ 962.310181] ? __switch_to_asm+0x34/0x70 > [ 962.310187] ? __switch_to_asm+0x40/0x70 > [ 962.310194] ? process_one_work+0x1400/0x1400 > [ 962.310199] ? __switch_to_asm+0x40/0x70 > [ 962.310205] ? __switch_to_asm+0x34/0x70 > [ 962.310211] ? __switch_to_asm+0x34/0x70 > [ 962.310216] ? __switch_to_asm+0x40/0x70 > [ 962.310221] ? __switch_to_asm+0x34/0x70 > [ 962.310226] ? __switch_to_asm+0x40/0x70 > [ 962.310231] ? __switch_to_asm+0x34/0x70 > [ 962.310236] ? __switch_to_asm+0x40/0x70 > [ 962.310242] ? syscall_return_via_sysret+0xf/0x7f > [ 962.310248] ? __switch_to_asm+0x34/0x70 > [ 962.310253] ? __switch_to_asm+0x40/0x70 > [ 962.310258] ? __switch_to_asm+0x34/0x70 > [ 962.310263] ? __switch_to_asm+0x40/0x70 > [ 962.310268] ? __switch_to_asm+0x34/0x70 > [ 962.310273] ? __switch_to_asm+0x40/0x70 > [ 962.310281] ? __schedule+0x87f/0x1e80 > [ 962.310292] ? __sched_text_start+0x8/0x8 > [ 962.310300] ? save_stack+0x8c/0xb0 > [ 962.310308] ? __kasan_kmalloc.constprop.6+0xc6/0xd0 > [ 962.310313] ? kthread+0x98/0x3a0 > [ 962.310318] ? ret_from_fork+0x35/0x40 > [ 962.310334] ? __wake_up_common+0x178/0x6f0 > [ 962.310343] ? _raw_spin_lock_irqsave+0xa4/0x140 > [ 962.310349] ? __lock_text_start+0x8/0x8 > [ 962.310355] ? _raw_write_lock_irqsave+0x70/0x130 > [ 962.310360] ? __lock_text_start+0x8/0x8 > [ 962.310371] ? process_one_work+0x1400/0x1400 > [ 962.310376] kthread+0x2e2/0x3a0 > [ 962.310383] ? kthread_create_on_node+0xc0/0xc0 > [ 962.310389] ret_from_fork+0x35/0x40 > > [ 962.310401] Allocated by task 1462: > [ 962.310410] __kasan_kmalloc.constprop.6+0xc6/0xd0 > [ 962.310437] drm_dp_add_port+0xd60/0x1960 [drm_kms_helper] > [ 962.310464] drm_dp_send_link_address+0x4b0/0x770 [drm_kms_helper] > [ 962.310491] drm_dp_check_and_send_link_address+0x197/0x1f0 > [drm_kms_helper] > [ 962.310515] drm_dp_mst_link_probe_work+0x2b6/0x330 [drm_kms_helper] > [ 962.310522] process_one_work+0x884/0x1400 > [ 962.310529] worker_thread+0x196/0x11e0 > [ 962.310
Re: [PATCH 3/3] drm/i915: Always allocate VCPI during system resume
On Tue, Jan 29, 2019 at 01:39:27PM -0500, Lyude Paul wrote: > Since there's a chance MST topologies can be removed while the system is > in suspend, there's also a chance that the connectors in the atomic > state which we try to restore on system resume will have been > unregistered if they were part of an MST topology that was removed > mid-suspend. In such situations, we'll currently skip recalculating the > VCPI. Normally this would be safe since we don't expect to be allowed to > enable displays on unregistered connections, but since we need to try > our best to restore even partially invalid atomic states on system > resume we end up introducing the chance that we try enabling a display > on a now-unregistered connector. This of course results on a blow up > during system resume: > > [ 1894.177788] [drm:pipe_config_err [i915]] *ERROR* mismatch in dp_m_n > (expected tu 0 gmch 1730150/8388608 link 288358/1048576, or tu 0 gmch 0/0 > link 0/0, found tu 64, gmch 1730150/8388608 link 288358/1048576) > [ 1894.177795] [ cut here ] > [ 1894.177799] pipe state doesn't match! > [ 1894.177905] WARNING: CPU: 2 PID: 1894 at > drivers/gpu/drm/i915/intel_display.c:12292 > intel_atomic_commit_tail+0xd5e/0xdd0 [i915] > [ 1894.177909] Modules linked in: i915(O) drm_kms_helper(O) drm(O) vfat fat > joydev iTCO_wdt wmi_bmof btusb btrtl btbcm intel_rapl btintel i2c_algo_bit > x86_pkg_temp_thermal bluetooth syscopyarea coretemp sysfillrect sysimgblt > crc32_pclmul fb_sys_fops ucsi_acpi psmouse ecdh_generic pcspkr typec_ucsi > i2c_i801 typec mei_me mei i2c_core wmi thinkpad_acpi ledtrig_audio snd > soundcore rfkill tpm_tis tpm_tis_core video pcc_cpufreq tpm acpi_pad uas > usb_storage crc32c_intel nvme serio_raw nvme_core xhci_pci xhci_hcd [last > unloaded: drm] > [ 1894.177990] CPU: 2 PID: 1894 Comm: kworker/u16:8 Tainted: G O > 5.0.0-rc4Lyude-Test+ #9 > [ 1894.177994] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W > (1.12 ) 04/09/2018 > [ 1894.178005] Workqueue: events_unbound async_run_entry_fn > [ 1894.178079] RIP: 0010:intel_atomic_commit_tail+0xd5e/0xdd0 [i915] > [ 1894.178085] Code: ba 01 00 00 00 4c 89 4c 24 10 e8 3d 46 01 00 4c 8b 4c 24 > 10 e9 a4 fb ff ff e8 b2 18 bd e0 0f 0b e9 a5 fd ff ff e8 a6 18 bd e0 <0f> 0b > e9 f1 f9 ff ff e8 9a 18 bd e0 0f 0b 0f b6 44 24 18 e9 23 f9 > [ 1894.178090] RSP: :c9553c08 EFLAGS: 00010286 > [ 1894.178096] RAX: RBX: 888459edc000 RCX: > 0006 > [ 1894.178101] RDX: 0007 RSI: 8884591e2f90 RDI: > 88845e295690 > [ 1894.178105] RBP: 888454e27000 R08: R09: > > [ 1894.178108] R10: R11: R12: > 888454e22000 > [ 1894.178112] R13: 888454e21000 R14: 8883ca680750 R15: > 8883ca680758 > [ 1894.178118] FS: () GS:88845e28() > knlGS: > [ 1894.178123] CS: 0010 DS: ES: CR0: 80050033 > [ 1894.178127] CR2: CR3: 02214001 CR4: > 003606e0 > [ 1894.178131] DR0: DR1: DR2: > > [ 1894.178135] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 1894.178139] Call Trace: > [ 1894.178224] intel_atomic_commit+0x240/0x320 [i915] > [ 1894.178251] drm_atomic_helper_commit_duplicated_state+0xc9/0xe0 > [drm_kms_helper] > [ 1894.178321] __intel_display_resume+0x82/0xd0 [i915] > [ 1894.178391] intel_display_resume+0xcf/0x120 [i915] > [ 1894.178453] i915_drm_resume+0xb1/0x100 [i915] > [ 1894.178465] ? pci_pm_suspend_late+0x30/0x30 > [ 1894.178473] dpm_run_callback+0x70/0x210 > [ 1894.178484] device_resume+0xae/0x1f0 > [ 1894.178493] async_resume+0x19/0x30 > [ 1894.178502] async_run_entry_fn+0x39/0x160 > [ 1894.178513] process_one_work+0x23c/0x590 > [ 1894.178529] worker_thread+0x30/0x380 > [ 1894.178539] ? rescuer_thread+0x340/0x340 > [ 1894.178545] kthread+0x112/0x130 > [ 1894.178552] ? kthread_create_on_node+0x60/0x60 > [ 1894.178563] ret_from_fork+0x3a/0x50 > [ 1894.178582] irq event stamp: 76782 > [ 1894.178591] hardirqs last enabled at (76781): [] > vprintk_emit+0x2c5/0x2d0 > [ 1894.178600] hardirqs last disabled at (76782): [] > trace_hardirqs_off_thunk+0x1a/0x1c > [ 1894.178609] softirqs last enabled at (76734): [] > __do_softirq+0x35d/0x412 > [ 1894.178618] softirqs last disabled at (76727): [] > irq_exit+0xe0/0xf0 > [ 1894.178687] WARNING: CPU: 2 PID: 1894 at > drivers/gpu/drm/i915/intel_display.c:12292 > intel_atomic_commit_tail+0xd5e/0xdd0 [i915] > [ 1894.178692] ---[ end trace 0df08c0b9a67376e ]--- > > So, fix this by using the new drm_atomic_state.suspend_or_resume hook in > order to force us to retrieve a VCPI allocation when restoring a pipe's > atomic state. This is safe, since drm_dp_atomic_find_vcpi_slots() will > just return the VCPI allocation we had pre-suspend. > > Signed-off-by: Lyude
Re: [PATCH 2/3] drm/atomic: Add drm_atomic_state->suspend_or_resume
On Tue, Jan 29, 2019 at 01:39:26PM -0500, Lyude Paul wrote:
> Since
>
> commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
> connectors harder")
>
> We've been failing atomic checks if they try to enable new displays on
> unregistered connectors. This is fine except for the one situation that
> breaks atomic assumptions: suspend/resume. If a connector is
> unregistered before we attempt to restore the atomic state, something we
> end up failing the atomic check that happens when trying to restore the
> state during resume.
>
> Normally this would be OK: we try our best to make sure that the atomic
> state pre-suspend can be restored post-suspend, but failures at that
> point usually don't cause problems. That is of course, until we
> introduced the new atomic MST VCPI helpers:
>
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B]
> active changed
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for
> [CONNECTOR:123:DP-5]
> [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling
> [CONNECTOR:123:DP-5]
> [drm:drm_atomic_get_private_obj_state [drm]] Added new private object
> 25844636 state 9fd2899a to 3a13d7b8
> WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153
> drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl
> x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O)
> crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt
> snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer
> mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi
> thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video
> tpm acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci
> nvme_core xhci_hcd
> CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW O
> 5.0.0-rc2Lyude-Test+ #1
> Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
> RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
> Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f
> 85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78
> b3 a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
> RSP: 0018:88841235f268 EFLAGS: 00010246
> RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
> RDX: dc00 RSI: RDI: ed108246bde0
> RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
> R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
> R13: 8883bc499100 R14: 88841bf12ab8 R15:
> FS: 7f16fbd4cd00() GS:88841ed8() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Call Trace:
> drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
> ? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
> ? __printk_safe_exit+0x10/0x10
> ? save_stack+0x8c/0xb0
> ? vprintk_func+0x96/0x1bf
> ? __printk_safe_exit+0x10/0x10
> intel_atomic_check+0x234/0x4750 [i915]
> ? printk+0x9f/0xc5
> ? kmsg_dump_rewind_nolock+0xd9/0xd9
> ? _raw_spin_lock_irqsave+0xa4/0x140
> ? drm_atomic_check_only+0xb1/0x28b0 [drm]
> ? drm_dbg+0x186/0x1b0 [drm]
> ? drm_dev_dbg+0x200/0x200 [drm]
> ? intel_link_compute_m_n+0xb0/0xb0 [i915]
> ? drm_mode_put_tile_group+0x20/0x20 [drm]
> ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
> ? drm_plane_check_pixel_format+0x14a/0x310 [drm]
> drm_atomic_check_only+0x13c4/0x28b0 [drm]
> ? drm_state_info+0x220/0x220 [drm]
> ? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
> ? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
> ? kasan_unpoison_shadow+0x35/0x40
> drm_atomic_commit+0x3b/0x100 [drm]
> drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
> drm_mode_setcrtc+0x636/0x1660 [drm]
> ? vprintk_func+0x96/0x1bf
> ? drm_dev_dbg+0x200/0x200 [drm]
> ? drm_mode_getcrtc+0x790/0x790 [drm]
> ? printk+0x9f/0xc5
> ? mutex_unlock+0x1d/0x40
> ? drm_mode_addfb2+0x2e9/0x3a0 [drm]
> ? rcu_sync_dtor+0x2e0/0x2e0
> ? drm_dbg+0x186/0x1b0 [drm]
> ? set_page_dirty+0x271/0x4d0
> drm_ioctl_kernel+0x203/0x290 [drm]
> ? drm_mode_getcrtc+0x790/0x790 [drm]
> ? drm_setversion+0x7f0/0x7f0 [drm]
> ? __switch_to_asm+0x34/0x70
> ? __switch_to_asm+0x34/0x70
> drm_ioctl+0x445/0x950 [drm]
> ? drm_mode_getcrtc+0x790/0x790 [drm]
> ? drm_getunique+0x220/0x220 [drm]
> ? expand_files.part.10+0x920/0x920
> do_vfs_ioctl+0x1a1/0x13d0
> ? ioctl_preallocate+0x2b0/0x2b0
> ? __fget_l
[radeon-alex:drm-next-5.1-wip 174/192] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:50:8: warning: missing braces around initializer
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.1-wip
head: 5daa9c4d3d3cf0da1520ad5a814c7f970160194a
commit: 3cec41769d2182e629692a3262cc8b24ec972b04 [174/192] drm/amd/display: Fix
use of uninitialized union
config: i386-randconfig-h1-01290401 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 3cec41769d2182e629692a3262cc8b24ec972b04
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
'wait_for_training_aux_rd_interval':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:50:8: warning:
>> missing braces around initializer [-Wmissing-braces]
union training_aux_rd_interval training_rd_interval = {0};
^
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:50:8: warning:
(near initialization for 'training_rd_interval.bits') [-Wmissing-braces]
vim +50 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c
37
38 static bool decide_fallback_link_setting(
39 struct dc_link_settings initial_link_settings,
40 struct dc_link_settings *current_link_setting,
41 enum link_training_result training_result);
42 static struct dc_link_settings get_common_supported_link_settings(
43 struct dc_link_settings link_setting_a,
44 struct dc_link_settings link_setting_b);
45
46 static void wait_for_training_aux_rd_interval(
47 struct dc_link *link,
48 uint32_t default_wait_in_micro_secs)
49 {
> 50 union training_aux_rd_interval training_rd_interval = {0};
51
52 /* overwrite the delay if rev > 1.1*/
53 if (link->dpcd_caps.dpcd_rev.raw >= DPCD_REV_12) {
54 /* DP 1.2 or later - retrieve delay through
55 * "DPCD_ADDR_TRAINING_AUX_RD_INTERVAL" register */
56 core_link_read_dpcd(
57 link,
58 DP_TRAINING_AUX_RD_INTERVAL,
59 (uint8_t *)&training_rd_interval,
60 sizeof(training_rd_interval));
61
62 if (training_rd_interval.bits.TRAINIG_AUX_RD_INTERVAL)
63 default_wait_in_micro_secs =
64
training_rd_interval.bits.TRAINIG_AUX_RD_INTERVAL * 4000;
65 }
66
67 udelay(default_wait_in_micro_secs);
68
69 DC_LOG_HW_LINK_TRAINING("%s:\n wait = %d\n",
70 __func__,
71 default_wait_in_micro_secs);
72 }
73
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 02:56:38PM -0500, Alex Deucher wrote: > On Tue, Jan 29, 2019 at 12:47 PM wrote: > > > > From: Jérôme Glisse > > > > device_test_p2p() return true if two devices can peer to peer to > > each other. We add a generic function as different inter-connect > > can support peer to peer and we want to genericaly test this no > > matter what the inter-connect might be. However this version only > > support PCIE for now. > > > > What about something like these patches: > https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p&id=4fab9ff69cb968183f717551441b475fabce6c1c > https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p&id=f90b12d41c277335d08c9dab62433f27c0fadbe5 > They are a bit more thorough. Yes it would be better, i forgot about those. I can include them next time i post. Thank you for reminding me about those :) Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/5] drivers/base: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 08:46:05PM +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 29, 2019 at 12:47:25PM -0500, jgli...@redhat.com wrote: > > From: Jérôme Glisse > > > > device_test_p2p() return true if two devices can peer to peer to > > each other. We add a generic function as different inter-connect > > can support peer to peer and we want to genericaly test this no > > matter what the inter-connect might be. However this version only > > support PCIE for now. > > There is no defintion of "peer to peer" in the driver/device model, so > why should this be in the driver core at all? > > Especially as you only do this for PCI, why not just keep it in the PCI > layer, that way you _know_ you are dealing with the right pointer types > and there is no need to mess around with the driver core at all. Ok i will drop the core device change. I wanted to allow other non PCI to join latter on (ie allow PCI device to export to non PCI device) but if that ever happen then we can update pci exporter at the same time we introduce non pci importer. Cheers, Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 12:47 PM wrote:
>
> From: Jérôme Glisse
>
> device_test_p2p() return true if two devices can peer to peer to
> each other. We add a generic function as different inter-connect
> can support peer to peer and we want to genericaly test this no
> matter what the inter-connect might be. However this version only
> support PCIE for now.
>
What about something like these patches:
https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p&id=4fab9ff69cb968183f717551441b475fabce6c1c
https://cgit.freedesktop.org/~deathsimple/linux/commit/?h=p2p&id=f90b12d41c277335d08c9dab62433f27c0fadbe5
They are a bit more thorough.
Alex
> Signed-off-by: Jérôme Glisse
> Cc: Logan Gunthorpe
> Cc: Greg Kroah-Hartman
> Cc: Rafael J. Wysocki
> Cc: Bjorn Helgaas
> Cc: Christian Koenig
> Cc: Felix Kuehling
> Cc: Jason Gunthorpe
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Cc: Joerg Roedel
> Cc: io...@lists.linux-foundation.org
> ---
> drivers/pci/p2pdma.c | 27 +++
> include/linux/pci-p2pdma.h | 6 ++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index c52298d76e64..620ac60babb5 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -797,3 +797,30 @@ ssize_t pci_p2pdma_enable_show(char *page, struct
> pci_dev *p2p_dev,
> return sprintf(page, "%s\n", pci_name(p2p_dev));
> }
> EXPORT_SYMBOL_GPL(pci_p2pdma_enable_show);
> +
> +bool pci_test_p2p(struct device *devA, struct device *devB)
> +{
> + struct pci_dev *pciA, *pciB;
> + bool ret;
> + int tmp;
> +
> + /*
> +* For now we only support PCIE peer to peer but other inter-connect
> +* can be added.
> +*/
> + pciA = find_parent_pci_dev(devA);
> + pciB = find_parent_pci_dev(devB);
> + if (pciA == NULL || pciB == NULL) {
> + ret = false;
> + goto out;
> + }
> +
> + tmp = upstream_bridge_distance(pciA, pciB, NULL);
> + ret = tmp < 0 ? false : true;
> +
> +out:
> + pci_dev_put(pciB);
> + pci_dev_put(pciA);
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(pci_test_p2p);
> diff --git a/include/linux/pci-p2pdma.h b/include/linux/pci-p2pdma.h
> index bca9bc3e5be7..7671cc499a08 100644
> --- a/include/linux/pci-p2pdma.h
> +++ b/include/linux/pci-p2pdma.h
> @@ -36,6 +36,7 @@ int pci_p2pdma_enable_store(const char *page, struct
> pci_dev **p2p_dev,
> bool *use_p2pdma);
> ssize_t pci_p2pdma_enable_show(char *page, struct pci_dev *p2p_dev,
>bool use_p2pdma);
> +bool pci_test_p2p(struct device *devA, struct device *devB);
> #else /* CONFIG_PCI_P2PDMA */
> static inline int pci_p2pdma_add_resource(struct pci_dev *pdev, int bar,
> size_t size, u64 offset)
> @@ -97,6 +98,11 @@ static inline ssize_t pci_p2pdma_enable_show(char *page,
> {
> return sprintf(page, "none\n");
> }
> +
> +static inline bool pci_test_p2p(struct device *devA, struct device *devB)
> +{
> + return false;
> +}
> #endif /* CONFIG_PCI_P2PDMA */
>
>
> --
> 2.17.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/5] drivers/base: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 11:26:01AM -0700, Logan Gunthorpe wrote: > > > On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote: > > From: Jérôme Glisse > > > > device_test_p2p() return true if two devices can peer to peer to > > each other. We add a generic function as different inter-connect > > can support peer to peer and we want to genericaly test this no > > matter what the inter-connect might be. However this version only > > support PCIE for now. > > This doesn't appear to be used in any of the further patches; so it's > very confusing. > > I'm not sure a struct device wrapper is really necessary... I wanted to allow other non pci device to join in the fun but yes right now i have only be doing this on pci devices. Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 08:44:26PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
> >
> >
> > On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> > > +bool pci_test_p2p(struct device *devA, struct device *devB)
> > > +{
> > > + struct pci_dev *pciA, *pciB;
> > > + bool ret;
> > > + int tmp;
> > > +
> > > + /*
> > > + * For now we only support PCIE peer to peer but other inter-connect
> > > + * can be added.
> > > + */
> > > + pciA = find_parent_pci_dev(devA);
> > > + pciB = find_parent_pci_dev(devB);
> > > + if (pciA == NULL || pciB == NULL) {
> > > + ret = false;
> > > + goto out;
> > > + }
> > > +
> > > + tmp = upstream_bridge_distance(pciA, pciB, NULL);
> > > + ret = tmp < 0 ? false : true;
> > > +
> > > +out:
> > > + pci_dev_put(pciB);
> > > + pci_dev_put(pciA);
> > > + return false;
> > > +}
> > > +EXPORT_SYMBOL_GPL(pci_test_p2p);
> >
> > This function only ever returns false
>
> I guess it was nevr actually tested :(
>
> I feel really worried about passing random 'struct device' pointers into
> the PCI layer. Are we _sure_ it can handle this properly?
>
Oh yes i fixed it on the test rig and forgot to patch
my local git tree. My bad.
Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 07:32:57PM +, Jason Gunthorpe wrote:
> On Tue, Jan 29, 2019 at 02:11:23PM -0500, Jerome Glisse wrote:
> > On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
> > >
> > >
> > > On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> > >
> > > > + /*
> > > > +* Optional for device driver that want to allow peer to peer
> > > > (p2p)
> > > > +* mapping of their vma (which can be back by some device
> > > > memory) to
> > > > +* another device.
> > > > +*
> > > > +* Note that the exporting device driver might not have map
> > > > anything
> > > > +* inside the vma for the CPU but might still want to allow a
> > > > peer
> > > > +* device to access the range of memory corresponding to a
> > > > range in
> > > > +* that vma.
> > > > +*
> > > > +* FOR PREDICTABILITY IF DRIVER SUCCESSFULY MAP A RANGE ONCE
> > > > FOR A
> > > > +* DEVICE THEN FURTHER MAPPING OF THE SAME IF THE VMA IS STILL
> > > > VALID
> > > > +* SHOULD ALSO BE SUCCESSFUL. Following this rule allow the
> > > > importing
> > > > +* device to map once during setup and report any failure at
> > > > that time
> > > > +* to the userspace. Further mapping of the same range might
> > > > happen
> > > > +* after mmu notifier invalidation over the range. The
> > > > exporting device
> > > > +* can use this to move things around (defrag BAR space for
> > > > instance)
> > > > +* or do other similar task.
> > > > +*
> > > > +* IMPORTER MUST OBEY mmu_notifier NOTIFICATION AND CALL
> > > > p2p_unmap()
> > > > +* WHEN A NOTIFIER IS CALL FOR THE RANGE ! THIS CAN HAPPEN AT
> > > > ANY
> > > > +* POINT IN TIME WITH NO LOCK HELD.
> > > > +*
> > > > +* In below function, the device argument is the importing
> > > > device,
> > > > +* the exporting device is the device to which the vma belongs.
> > > > +*/
> > > > + long (*p2p_map)(struct vm_area_struct *vma,
> > > > + struct device *device,
> > > > + unsigned long start,
> > > > + unsigned long end,
> > > > + dma_addr_t *pa,
> > > > + bool write);
> > > > + long (*p2p_unmap)(struct vm_area_struct *vma,
> > > > + struct device *device,
> > > > + unsigned long start,
> > > > + unsigned long end,
> > > > + dma_addr_t *pa);
> > >
> > > I don't understand why we need new p2p_[un]map function pointers for
> > > this. In subsequent patches, they never appear to be set anywhere and
> > > are only called by the HMM code. I'd have expected it to be called by
> > > some core VMA code and set by HMM as that's what vm_operations_struct is
> > > for.
> > >
> > > But the code as all very confusing, hard to follow and seems to be
> > > missing significant chunks. So I'm not really sure what is going on.
> >
> > It is set by device driver when userspace do mmap(fd) where fd comes
> > from open("/dev/somedevicefile"). So it is set by device driver. HMM
> > has nothing to do with this. It must be set by device driver mmap
> > call back (mmap callback of struct file_operations). For this patch
> > you can completely ignore all the HMM patches. Maybe posting this as
> > 2 separate patchset would make it clearer.
> >
> > For instance see [1] for how a non HMM driver can export its memory
> > by just setting those callback. Note that a proper implementation of
> > this should also include some kind of driver policy on what to allow
> > to map and what to not allow ... All this is driver specific in any
> > way.
>
> I'm imagining that the RDMA drivers would use this interface on their
> per-process 'doorbell' BAR pages - we also wish to have P2P DMA to
> this memory. Also the entire VFIO PCI BAR mmap would be good to cover
> with this too.
Correct, you would set those callback on the mmap of your doorbell.
>
> Jerome, I think it would be nice to have a helper scheme - I think the
> simple case would be simple remapping of PCI BAR memory, so if we
> could have, say something like:
>
> static const struct vm_operations_struct my_ops {
> .p2p_map = p2p_ioremap_map_op,
> .p2p_unmap = p2p_ioremap_unmap_op,
> }
>
> struct ioremap_data {
> [..]
> }
>
> fops_mmap() {
>vma->private_data = &driver_priv->ioremap_data;
>return p2p_ioremap_device_memory(vma, exporting_device, [..]);
> }
>
> Which closely matches at least what the RDMA drivers do. Where
> p2p_ioremap_device_memory populates p2p_map and p2p_unmap pointers
> with sensible functions, etc.
>
> It looks like vfio would be able to use this as well (though I am
> unsure why vfio uses remap_pfn_range instead of io_remap_pfn range for
> BAR memory..)
Yes simple helper that implement a sane defaul
Re: [RFC PATCH 2/5] drivers/base: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 12:47:25PM -0500, jgli...@redhat.com wrote: > From: Jérôme Glisse > > device_test_p2p() return true if two devices can peer to peer to > each other. We add a generic function as different inter-connect > can support peer to peer and we want to genericaly test this no > matter what the inter-connect might be. However this version only > support PCIE for now. There is no defintion of "peer to peer" in the driver/device model, so why should this be in the driver core at all? Especially as you only do this for PCI, why not just keep it in the PCI layer, that way you _know_ you are dealing with the right pointer types and there is no need to mess around with the driver core at all. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 12:24:04PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 12:11 p.m., Jerome Glisse wrote:
> > On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> >>
> >>> + /*
> >>> + * Optional for device driver that want to allow peer to peer (p2p)
> >>> + * mapping of their vma (which can be back by some device memory) to
> >>> + * another device.
> >>> + *
> >>> + * Note that the exporting device driver might not have map anything
> >>> + * inside the vma for the CPU but might still want to allow a peer
> >>> + * device to access the range of memory corresponding to a range in
> >>> + * that vma.
> >>> + *
> >>> + * FOR PREDICTABILITY IF DRIVER SUCCESSFULY MAP A RANGE ONCE FOR A
> >>> + * DEVICE THEN FURTHER MAPPING OF THE SAME IF THE VMA IS STILL VALID
> >>> + * SHOULD ALSO BE SUCCESSFUL. Following this rule allow the importing
> >>> + * device to map once during setup and report any failure at that time
> >>> + * to the userspace. Further mapping of the same range might happen
> >>> + * after mmu notifier invalidation over the range. The exporting device
> >>> + * can use this to move things around (defrag BAR space for instance)
> >>> + * or do other similar task.
> >>> + *
> >>> + * IMPORTER MUST OBEY mmu_notifier NOTIFICATION AND CALL p2p_unmap()
> >>> + * WHEN A NOTIFIER IS CALL FOR THE RANGE ! THIS CAN HAPPEN AT ANY
> >>> + * POINT IN TIME WITH NO LOCK HELD.
> >>> + *
> >>> + * In below function, the device argument is the importing device,
> >>> + * the exporting device is the device to which the vma belongs.
> >>> + */
> >>> + long (*p2p_map)(struct vm_area_struct *vma,
> >>> + struct device *device,
> >>> + unsigned long start,
> >>> + unsigned long end,
> >>> + dma_addr_t *pa,
> >>> + bool write);
> >>> + long (*p2p_unmap)(struct vm_area_struct *vma,
> >>> + struct device *device,
> >>> + unsigned long start,
> >>> + unsigned long end,
> >>> + dma_addr_t *pa);
> >>
> >> I don't understand why we need new p2p_[un]map function pointers for
> >> this. In subsequent patches, they never appear to be set anywhere and
> >> are only called by the HMM code. I'd have expected it to be called by
> >> some core VMA code and set by HMM as that's what vm_operations_struct is
> >> for.
> >>
> >> But the code as all very confusing, hard to follow and seems to be
> >> missing significant chunks. So I'm not really sure what is going on.
> >
> > It is set by device driver when userspace do mmap(fd) where fd comes
> > from open("/dev/somedevicefile"). So it is set by device driver. HMM
> > has nothing to do with this. It must be set by device driver mmap
> > call back (mmap callback of struct file_operations). For this patch
> > you can completely ignore all the HMM patches. Maybe posting this as
> > 2 separate patchset would make it clearer.
> >
> > For instance see [1] for how a non HMM driver can export its memory
> > by just setting those callback. Note that a proper implementation of
> > this should also include some kind of driver policy on what to allow
> > to map and what to not allow ... All this is driver specific in any
> > way.
>
> I'd suggest [1] should be a part of the patchset so we can actually see
> a user of the stuff you're adding.
I did not wanted to clutter patchset with device driver specific usage
of this. As the API can be reason about in abstract way.
>
> But it still doesn't explain everything as without the HMM code nothing
> calls the new vm_ops. And there's still no callers for the p2p_test
> functions you added. And I still don't understand why we need the new
> vm_ops or who calls them and when. Why can't drivers use the existing
> 'fault' vm_op and call a new helper function to map p2p when appropriate
> or a different helper function to map a large range in its mmap
> operation? Just like regular mmap code...
HMM code is just one user, if you have a driver that use HMM mirror
then your driver get support for this for free. If you do not want to
use HMM then you can directly call this in your driver.
The flow is, device driver want to setup some mapping for a range of
virtual address [va_start, va_end]:
1 - Lookup vma for the range
2 - If vma is regular vma (not an mmap of a file) then use GUP
If vma is a mmap of a file and they are p2p_map call back
then call p2p_map()
3 - Use either the result of GUP or p2p_map() to program the
device
The p2p test function is use by device driver implementing the call
back for instance see:
https://cgit.freedesktop.org/~glisse/linux/commit/?h=hmm-p2p&id=401a567696eafb1d4faf7054ab0d7c3a16a5ef06
The vm_fault callback is not suited because here we are mapping to
another device so this will need special handling, someone must have
bot
Re: [RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> > +bool pci_test_p2p(struct device *devA, struct device *devB)
> > +{
> > + struct pci_dev *pciA, *pciB;
> > + bool ret;
> > + int tmp;
> > +
> > + /*
> > +* For now we only support PCIE peer to peer but other inter-connect
> > +* can be added.
> > +*/
> > + pciA = find_parent_pci_dev(devA);
> > + pciB = find_parent_pci_dev(devB);
> > + if (pciA == NULL || pciB == NULL) {
> > + ret = false;
> > + goto out;
> > + }
> > +
> > + tmp = upstream_bridge_distance(pciA, pciB, NULL);
> > + ret = tmp < 0 ? false : true;
> > +
> > +out:
> > + pci_dev_put(pciB);
> > + pci_dev_put(pciA);
> > + return false;
> > +}
> > +EXPORT_SYMBOL_GPL(pci_test_p2p);
>
> This function only ever returns false
I guess it was nevr actually tested :(
I feel really worried about passing random 'struct device' pointers into
the PCI layer. Are we _sure_ it can handle this properly?
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
On Tue, Jan 29, 2019 at 07:10:55PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 6:36 PM Greg KH wrote:
> >
> > On Tue, Jan 29, 2019 at 05:50:05PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
> > > >
> > > >
> > > > Den 24.01.2019 18.57, skrev Daniel Vetter:
> > > > > On Thu, Jan 24, 2019 at 6:46 PM Greg KH
> > > > > wrote:
> > > > >>
> > > > >> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> > > > >>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
> > > >
> > > >
> > > > Den 22.01.2019 20.30, skrev Daniel Vetter:
> > > > > On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes
> > > > > wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >> Den 22.01.2019 10.32, skrev Daniel Vetter:
> > > > >>> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
> > > >
> > > >
> > > > Den 21.01.2019 10.55, skrev Daniel Vetter:
> > > > > On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter wrote:
> > > > >> On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes
> > > > >> wrote:
> > > > >>> This adds resource managed (devres) versions of
> > > > >>> drm_dev_init() and
> > > > >>> drm_dev_register().
> > > > >>>
> > > > >>> Also added is devm_drm_dev_register_with_fbdev() which sets
> > > > >>> up generic
> > > > >>> fbdev emulation as well.
> > > > >>>
> > > > >>> devm_drm_dev_register() isn't exported since there are no
> > > > >>> users.
> > > > >>>
> > > > >>> Signed-off-by: Noralf Trønnes
> > > > >>
> > > >
> > > >
> > > >
> > > > >>> diff --git a/drivers/gpu/drm/drm_drv.c
> > > > >>> b/drivers/gpu/drm/drm_drv.c
> > > > >>> index 381581b01d48..12129772be45 100644
> > > > >>> --- a/drivers/gpu/drm/drm_drv.c
> > > > >>> +++ b/drivers/gpu/drm/drm_drv.c
> > > > >>> @@ -36,6 +36,7 @@
> > > > >>>
> > > > >>> #include
> > > > >>> #include
> > > > >>> +#include
> > > > >>> #include
> > > > >>>
> > > > >>> #include "drm_crtc_internal.h"
> > > > >>> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct
> > > > >>> drm_device *dev)
> > > > >>> }
> > > > >>> EXPORT_SYMBOL(drm_dev_unregister);
> > > > >>>
> > > > >>> +static void devm_drm_dev_init_release(void *data)
> > > > >>> +{
> > > > >>> + drm_dev_put(data);
> > > > >
> > > > > We need drm_dev_unplug() here, or this isn't safe.
> > > >
> > > > This function is only used to cover the error path if probe
> > > > fails before
> > > > devm_drm_dev_register() is called.
> > > > devm_drm_dev_register_release() is
> > > > the one that calls unplug. There are comments about this in
> > > > the functions.
> > > > >>>
> > > > >>> I think I get a prize for being ignorant and blind :-/
> > > > >>>
> > > >
> > > > >
> > > > >>> +}
> > > > >>> +
> > > > >>> +/**
> > > > >>> + * devm_drm_dev_init - Resource managed drm_dev_init()
> > > > >>> + * @parent: Parent device object
> > > > >>> + * @dev: DRM device
> > > > >>> + * @driver: DRM driver
> > > > >>> + *
> > > > >>> + * Managed drm_dev_init(). The DRM device initialized with
> > > > >>> this function is
> > > > >>> + * automatically released on driver detach. You must
> > > > >>> supply a
> > > > >
> > > > > I think a bit more clarity here would be good:
> > > > >
> > > > > "... automatically released on driver unbind by callind
> > > > > drm_dev_unplug()."
> > > > >
> > > > >>> + * &drm_driver.release callback to control the
> > > > >>> finalization explicitly.
> > > > >
> > > > > I think a loud warning for these is in order:
> > > > >
> > > > > "WARNING:
> > > > >
> > > > > "In generally it is unsafe to use devm functions for drm
> > > > > structures
> > > > > because the lifetimes of &drm_device and the underlying
> > > > > &device do not
> > > > > match. This here works because it doesn't immediately free
> > > > > anything, but
> > > > > only calls drm_dev_unplug(), which internally decrements the
> > > > > &drm_device
> > > > > refcount through drm_dev_put().
> > > > >
> > > > > "All other drm structures must still be explicitly released
> > > > > in the
> > > > > &drm_driver.release callback."
> > > > >
> > > > > While thinking about this I just realized that with this
> > > > > desi
[PATCH v3] drm/TODO: Add drm_display_mode.hsync/vrefresh removal
From: Sean Paul Drivers shouldn't be using these values, add a TODO so someone removes them. Changes in v2: - Add drm_display_mode.vrefresh removal (Ville) - Add Sam's R-b and bonus points Changes in v3: - Add hsync removal todo item (Daniel) - Change vrefresh wording to make removal less optional Cc: Ville Syrjälä Suggested-by: Daniel Vetter Reviewed-by: Daniel Vetter Reviewed-by: Sam Ravnborg Bonus-points-awarded-by: Sam Ravnborg Signed-off-by: Sean Paul --- This time with feeling. Documentation/gpu/todo.rst | 28 1 file changed, 28 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 38360ede12215..f67c84b92873c 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -262,6 +262,34 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() + + +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core +has helper which will use mode.vrefresh if it's !0 and will calculate it from +the timings when it's 0. + +Use simple search/replace, or (more fun) cocci to replace instances of direct +vrefresh access with a call to the helper. Check out +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for +inspiration. + +Once all instances of vrefresh have been converted, remove vrefresh from +drm_display_mode to avoid future use. + +Contact: Sean Paul + +Remove drm_display_mode.hsync +- + +We have drm_mode_hsync() to calculate this from hsync_start/end, since drivers +shouldn't/don't use this, remove this member to avoid any temptations to use it +in the future. If there is any debug code using drm_display_mode.hsync, convert +it to use drm_mode_hsync() instead. + +Contact: Sean Paul + Core refactorings = -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: Constify drm_color_lut_check()
On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_color_lut_check() doens't modify the passed in blob so
s/doens't/doesn't/
Otherwise, LGTM.
Reviewed-by:
> let's make it const.
>
> Also s/uint32_y/u32/ while at it.
>
> Cc: Matt Roper
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 6 +++---
> include/drm/drm_color_mgmt.h | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 968ca7c91ad8..3c8826a91a03 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -474,10 +474,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
> *
> * Returns 0 on success, -EINVAL on failure.
> */
> -int drm_color_lut_check(struct drm_property_blob *lut,
> - uint32_t tests)
> +int drm_color_lut_check(const struct drm_property_blob *lut,
> + u32 tests)
> {
> - struct drm_color_lut *entry;
> + const struct drm_color_lut *entry;
> int i;
>
> if (!lut || !tests)
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 6affbda6d9cb..58d4b20b5b97 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -96,6 +96,6 @@ enum drm_color_lut_tests {
> DRM_COLOR_LUT_NON_DECREASING = BIT(1),
> };
>
> -int drm_color_lut_check(struct drm_property_blob *lut,
> - uint32_t tests);
> +int drm_color_lut_check(const struct drm_property_blob *lut,
> + u32 tests);
> #endif
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm/i915: Block fbdev HPD processing during suspend
Quoting Lyude Paul (2019-01-29 19:09:59)
> When resuming, we check whether or not any previously connected
> MST topologies are still present and if so, attempt to resume them. If
> this fails, we disable said MST topologies and fire off a hotplug event
> so that userspace knows to reprobe.
>
> However, sending a hotplug event involves calling
> drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
> connector reprobe in the caller's thread - something we can't do at the
> point in which i915 calls drm_dp_mst_topology_mgr_resume() since
> hotplugging hasn't been fully initialized yet.
>
> This currently causes some rather subtle but fatal issues. For example,
> on my T480s the laptop dock connected to it usually disappears during a
> suspend cycle, and comes back up a short while after the system has been
> resumed. This guarantees pretty much every suspend and resume cycle,
> drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
> a connector hotplug will occur. Now it's Rute Goldberg time: when the
> connector hotplug occurs, i915 reprobes /all/ of the connectors,
> including eDP. However, eDP probing requires that we power on the panel
> VDD which in turn, grabs a wakeref to the appropriate power domain on
> the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
> things start breaking, since this all happens before
> intel_power_domains_enable() is called we end up leaking the wakeref
> that was acquired and never releasing it later. Come next suspend/resume
> cycle, this causes us to fail to shut down the GPU properly, which
> causes it not to resume properly and die a horrible complicated death.
>
> (as a note: this only happens when there's both an eDP panel and MST
> topology connected which is removed mid-suspend. One or the other seems
> to always be OK).
>
> We could try to fix the VDD wakeref leak, but this doesn't seem like
> it's worth it at all since we aren't able to handle hotplug detection
> while resuming anyway. So, let's go with a more robust solution inspired
> by nouveau: block fbdev from handling hotplug events until we resume
> fbdev. This allows us to still send sysfs hotplug events to be handled
> later by user space while we're resuming, while also preventing us from
> actually processing any hotplug events we receive until it's safe.
>
> This fixes the wakeref leak observed on the T480s and as such, also
> fixes suspend/resume with MST topologies connected on this machine.
>
> Changes since v2:
> * Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
> (Chris Wilson)
> * Don't call drm_fb_helper_hotplug_event() in
> intel_fbdev_output_poll_changed() under lock (Chris Wilson)
> * Always set ifbdev->hpd_waiting (Chris Wilson)
>
> Signed-off-by: Lyude Paul
> Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
> Cc: Todd Previte
> Cc: Dave Airlie
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Imre Deak
> Cc: intel-...@lists.freedesktop.org
> Cc: # v3.17+
I suspect the locking is overkill, but certainly easier to reason than
trying to remember all the ins and outs of fbdev with its dubious async
initialisation.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
>
> > + /*
> > +* Optional for device driver that want to allow peer to peer (p2p)
> > +* mapping of their vma (which can be back by some device memory) to
> > +* another device.
> > +*
> > +* Note that the exporting device driver might not have map anything
> > +* inside the vma for the CPU but might still want to allow a peer
> > +* device to access the range of memory corresponding to a range in
> > +* that vma.
> > +*
> > +* FOR PREDICTABILITY IF DRIVER SUCCESSFULY MAP A RANGE ONCE FOR A
> > +* DEVICE THEN FURTHER MAPPING OF THE SAME IF THE VMA IS STILL VALID
> > +* SHOULD ALSO BE SUCCESSFUL. Following this rule allow the importing
> > +* device to map once during setup and report any failure at that time
> > +* to the userspace. Further mapping of the same range might happen
> > +* after mmu notifier invalidation over the range. The exporting device
> > +* can use this to move things around (defrag BAR space for instance)
> > +* or do other similar task.
> > +*
> > +* IMPORTER MUST OBEY mmu_notifier NOTIFICATION AND CALL p2p_unmap()
> > +* WHEN A NOTIFIER IS CALL FOR THE RANGE ! THIS CAN HAPPEN AT ANY
> > +* POINT IN TIME WITH NO LOCK HELD.
> > +*
> > +* In below function, the device argument is the importing device,
> > +* the exporting device is the device to which the vma belongs.
> > +*/
> > + long (*p2p_map)(struct vm_area_struct *vma,
> > + struct device *device,
> > + unsigned long start,
> > + unsigned long end,
> > + dma_addr_t *pa,
> > + bool write);
> > + long (*p2p_unmap)(struct vm_area_struct *vma,
> > + struct device *device,
> > + unsigned long start,
> > + unsigned long end,
> > + dma_addr_t *pa);
>
> I don't understand why we need new p2p_[un]map function pointers for
> this. In subsequent patches, they never appear to be set anywhere and
> are only called by the HMM code. I'd have expected it to be called by
> some core VMA code and set by HMM as that's what vm_operations_struct is
> for.
>
> But the code as all very confusing, hard to follow and seems to be
> missing significant chunks. So I'm not really sure what is going on.
It is set by device driver when userspace do mmap(fd) where fd comes
from open("/dev/somedevicefile"). So it is set by device driver. HMM
has nothing to do with this. It must be set by device driver mmap
call back (mmap callback of struct file_operations). For this patch
you can completely ignore all the HMM patches. Maybe posting this as
2 separate patchset would make it clearer.
For instance see [1] for how a non HMM driver can export its memory
by just setting those callback. Note that a proper implementation of
this should also include some kind of driver policy on what to allow
to map and what to not allow ... All this is driver specific in any
way.
Cheers,
Jérôme
[1]
https://cgit.freedesktop.org/~glisse/linux/commit/?h=wip-p2p-showcase&id=964214dcd4df96f296e2214042e8cfce135ae3d4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/i915: Block fbdev HPD processing during suspend
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.
This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.
(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).
We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.
This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.
Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
(Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev->hpd_waiting (Chris Wilson)
Signed-off-by: Lyude Paul
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte
Cc: Dave Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Imre Deak
Cc: intel-...@lists.freedesktop.org
Cc: # v3.17+
---
drivers/gpu/drm/i915/intel_drv.h | 10 +
drivers/gpu/drm/i915/intel_fbdev.c | 33 +-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 90ba5436370e..9ec3d00fbd19 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -213,6 +213,16 @@ struct intel_fbdev {
unsigned long vma_flags;
async_cookie_t cookie;
int preferred_bpp;
+
+ /* Whether or not fbdev hpd processing is temporarily suspended */
+ bool hpd_suspended : 1;
+ /* Set when a hotplug was received while HPD processing was
+* suspended
+*/
+ bool hpd_waiting : 1;
+
+ /* Protects hpd_suspended */
+ struct mutex hpd_lock;
};
struct intel_encoder {
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 8cf3efe88f02..376ffe842e26 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -681,6 +681,7 @@ int intel_fbdev_init(struct drm_device *dev)
if (ifbdev == NULL)
return -ENOMEM;
+ mutex_init(&ifbdev->hpd_lock);
drm_fb_helper_prepare(dev, &ifbdev->helper, &intel_fb_helper_funcs);
if (!intel_fbdev_init_bios(dev, ifbdev))
@@ -754,6 +755,26 @@ void intel_fbdev_fini(struct drm_i915_private *dev_priv)
intel_fbdev_destroy(ifbdev);
}
+/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
+ * processing, fbdev will perform a full connector reprobe if a hotplug event
+ * was received while HPD was suspended.
+ */
+static void intel_fbdev_hpd_set_suspend(struct intel_fbdev *ifbdev, int state)
+{
+ bool send_hpd = false;
+
+ mutex_lock(&ifbdev->hpd_lock);
+ ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
+ send_hpd = !ifbdev->hpd_suspended && ifbdev->hpd_waiting;
+ ifbdev->hpd_waiting = false;
+ mutex_unlock(&ifbdev->hpd_lock);
+
+ if (send_hpd) {
+ DRM_DEBUG_KMS("Handling d
[PATCH v3 2/3] drm/i915: Don't send MST hotplugs during resume
We have a bad habit of calling drm_fb_helper_hotplug_event() far more
then we actually need to. MST appears to be one of these cases, where we
call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
topology in intel_dp_mst_resume(). We don't actually need to do this at
all though since hotplug events are already sent from
drm_dp_connector_destroy_work() every time connectors are unregistered
from userspace's PoV. Additionally, extra calls to
drm_fb_helper_hotplug_event() also just mean more of a chance of doing a
connector probe somewhere we shouldn't.
So, don't send any hotplug events during resume if the MST topology
fails to come up. Just rely on the DP MST helpers to send them for us.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 681e88405ada..c2399acf177b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7096,7 +7096,10 @@ void intel_dp_mst_resume(struct drm_i915_private
*dev_priv)
continue;
ret = drm_dp_mst_topology_mgr_resume(&intel_dp->mst_mgr);
- if (ret)
- intel_dp_check_mst_status(intel_dp);
+ if (ret) {
+ intel_dp->is_mst = false;
+ drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
+ false);
+ }
}
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] drm/i915: MST and wakeref leak fixes
While trying to fix a problem with suspend/resume that I introduced in the atomic VCPI helpers for MST, I also ran into some issues with i915 varying from "not that bad" to "oh wow that's very bad". Here are the fixes for those issues. This series was originally just one patch, "drm/i915: Don't send MST hotplugs during resume" Lyude Paul (3): drm/i915: Block fbdev HPD processing during suspend drm/i915: Don't send MST hotplugs during resume drm/i915: Don't send hotplug in intel_dp_check_mst_status() drivers/gpu/drm/i915/intel_dp.c| 13 ++-- drivers/gpu/drm/i915/intel_drv.h | 10 + drivers/gpu/drm/i915/intel_fbdev.c | 33 +- 3 files changed, 49 insertions(+), 7 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/i915: Don't send hotplug in intel_dp_check_mst_status()
This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
already sends a hotplug on its own from drm_dp_destroy_connector_work()
after destroying connectors in the MST topology.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c2399acf177b..f9113c0cdfcd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4608,12 +4608,10 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return ret;
} else {
- struct intel_digital_port *intel_dig_port =
dp_to_dig_port(intel_dp);
DRM_DEBUG_KMS("failed to get ESI - device may have
failed\n");
intel_dp->is_mst = false;
- drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
intel_dp->is_mst);
- /* send a hotplug event */
-
drm_kms_helper_hotplug_event(intel_dig_port->base.base.dev);
+ drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
+ intel_dp->is_mst);
}
}
return -EINVAL;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: Constify drm_color_lut_check()
On Tue, Jan 29, 2019 at 07:58:56PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote:
> > Hi Ville.
> >
> > On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > drm_color_lut_check() doens't modify the passed in blob so
> > > let's make it const.
> > >
> > > Also s/uint32_y/u32/ while at it.
> > >
> > > Cc: Matt Roper
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_color_mgmt.c | 6 +++---
> > > include/drm/drm_color_mgmt.h | 4 ++--
> > > 2 files changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > > b/drivers/gpu/drm/drm_color_mgmt.c
> > > index 968ca7c91ad8..3c8826a91a03 100644
> > > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > > @@ -474,10 +474,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
> > > *
> > > * Returns 0 on success, -EINVAL on failure.
> > > */
> > > -int drm_color_lut_check(struct drm_property_blob *lut,
> > > - uint32_t tests)
> > > +int drm_color_lut_check(const struct drm_property_blob *lut,
> > > + u32 tests)
> >
> > No need to linewrap this line.
> > > {
> > > - struct drm_color_lut *entry;
> > > + const struct drm_color_lut *entry;
> > > int i;
> > >
> > > if (!lut || !tests)
> > > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> > > index 6affbda6d9cb..58d4b20b5b97 100644
> > > --- a/include/drm/drm_color_mgmt.h
> > > +++ b/include/drm/drm_color_mgmt.h
> > > @@ -96,6 +96,6 @@ enum drm_color_lut_tests {
> > > DRM_COLOR_LUT_NON_DECREASING = BIT(1),
> > > };
> > >
> > > -int drm_color_lut_check(struct drm_property_blob *lut,
> > > - uint32_t tests);
> > > +int drm_color_lut_check(const struct drm_property_blob *lut,
> > > + u32 tests);
> > Likewise.
> >
> > With the linewrap fixed:
> > Reviewed-by: Sam Ravnborg
>
> Thanks.
>
> >
> > Note: does not apply to my drm-misc tree. Anything I miss here?
>
> I think it was merged via drm-intel.
Acked-by: Daniel Vetter
for merging through drm-intel then (assuming it goes in before the merge
cutoff), with Sam's suggestions ofc.
-Daniel
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines
On 2019-01-29 1:56 p.m., Guenter Roeck wrote: > On Tue, Jan 29, 2019 at 10:30:31AM -0500, Alex Deucher wrote: >> On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry >> wrote: >>> >>> On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote: arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn on SSE2 to support emitting double precision floating point instructions rather than calls to non-existent (usually available from gcc_s or compiler_rt) floating point helper routines. Link: https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html Link: https://github.com/ClangBuiltLinux/linux/issues/327 Cc: sta...@vger.kernel.org # 4.19 Reported-by: S, Shirish Reported-by: Matthias Kaehlcke Suggested-by: James Y Knight Suggested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Tested-by: Guenter Roeck >>> >>> Reviewed-by: Harry Wentland >>> >>> and applied. >>> >> >> This patch causes a segfault: >> https://bugs.freedesktop.org/show_bug.cgi?id=109487 >> >> Any ideas? >> > > Set -msse2 only for clang ? I suspect, though, that this might only > solve the compile problem. If I understand correctly, the first > warning in the log is due to BREAK_TO_DEBUGGER(), suggesting that > something is seriously wrong. Maybe enabling sse2 results in different > results from floating point operations. > > Unfortunately I don't have a system with the affected GPU, > so I can't run any tests on real hardware. Unless someone can test > with real hardware, I think we have no choice but to revert the > patch. > Might be a good idea. Even though, best to revert for now until we understand what's going on. It seems like people at AMD building with gcc 5.4 are fine, but those using gcc 7.3 or 8.2 experience the crash. Harry > Guenter > >> Alex >> >>> Harry >>> --- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile b/drivers/gpu/drm/amd/display/dc/calcs/Makefile index 95f332ee3e7e..dc85a3c088af 100644 --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) cc_stack_align := -mstack-alignment=16 endif -calcs_ccflags := -mhard-float -msse $(cc_stack_align) +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) CFLAGS_dcn_calcs.o := $(calcs_ccflags) CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile b/drivers/gpu/drm/amd/display/dc/dml/Makefile index d97ca6528f9d..33c7d7588712 100644 --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) cc_stack_align := -mstack-alignment=16 endif -dml_ccflags := -mhard-float -msse $(cc_stack_align) +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) CFLAGS_display_mode_lib.o := $(dml_ccflags) CFLAGS_display_pipe_clocks.o := $(dml_ccflags) >>> ___ >>> amd-gfx mailing list >>> amd-...@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/i915: Always allocate VCPI during system resume
Since there's a chance MST topologies can be removed while the system is
in suspend, there's also a chance that the connectors in the atomic
state which we try to restore on system resume will have been
unregistered if they were part of an MST topology that was removed
mid-suspend. In such situations, we'll currently skip recalculating the
VCPI. Normally this would be safe since we don't expect to be allowed to
enable displays on unregistered connections, but since we need to try
our best to restore even partially invalid atomic states on system
resume we end up introducing the chance that we try enabling a display
on a now-unregistered connector. This of course results on a blow up
during system resume:
[ 1894.177788] [drm:pipe_config_err [i915]] *ERROR* mismatch in dp_m_n
(expected tu 0 gmch 1730150/8388608 link 288358/1048576, or tu 0 gmch 0/0 link
0/0, found tu 64, gmch 1730150/8388608 link 288358/1048576)
[ 1894.177795] [ cut here ]
[ 1894.177799] pipe state doesn't match!
[ 1894.177905] WARNING: CPU: 2 PID: 1894 at
drivers/gpu/drm/i915/intel_display.c:12292 intel_atomic_commit_tail+0xd5e/0xdd0
[i915]
[ 1894.177909] Modules linked in: i915(O) drm_kms_helper(O) drm(O) vfat fat
joydev iTCO_wdt wmi_bmof btusb btrtl btbcm intel_rapl btintel i2c_algo_bit
x86_pkg_temp_thermal bluetooth syscopyarea coretemp sysfillrect sysimgblt
crc32_pclmul fb_sys_fops ucsi_acpi psmouse ecdh_generic pcspkr typec_ucsi
i2c_i801 typec mei_me mei i2c_core wmi thinkpad_acpi ledtrig_audio snd
soundcore rfkill tpm_tis tpm_tis_core video pcc_cpufreq tpm acpi_pad uas
usb_storage crc32c_intel nvme serio_raw nvme_core xhci_pci xhci_hcd [last
unloaded: drm]
[ 1894.177990] CPU: 2 PID: 1894 Comm: kworker/u16:8 Tainted: G O
5.0.0-rc4Lyude-Test+ #9
[ 1894.177994] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12
) 04/09/2018
[ 1894.178005] Workqueue: events_unbound async_run_entry_fn
[ 1894.178079] RIP: 0010:intel_atomic_commit_tail+0xd5e/0xdd0 [i915]
[ 1894.178085] Code: ba 01 00 00 00 4c 89 4c 24 10 e8 3d 46 01 00 4c 8b 4c 24
10 e9 a4 fb ff ff e8 b2 18 bd e0 0f 0b e9 a5 fd ff ff e8 a6 18 bd e0 <0f> 0b e9
f1 f9 ff ff e8 9a 18 bd e0 0f 0b 0f b6 44 24 18 e9 23 f9
[ 1894.178090] RSP: :c9553c08 EFLAGS: 00010286
[ 1894.178096] RAX: RBX: 888459edc000 RCX: 0006
[ 1894.178101] RDX: 0007 RSI: 8884591e2f90 RDI: 88845e295690
[ 1894.178105] RBP: 888454e27000 R08: R09:
[ 1894.178108] R10: R11: R12: 888454e22000
[ 1894.178112] R13: 888454e21000 R14: 8883ca680750 R15: 8883ca680758
[ 1894.178118] FS: () GS:88845e28()
knlGS:
[ 1894.178123] CS: 0010 DS: ES: CR0: 80050033
[ 1894.178127] CR2: CR3: 02214001 CR4: 003606e0
[ 1894.178131] DR0: DR1: DR2:
[ 1894.178135] DR3: DR6: fffe0ff0 DR7: 0400
[ 1894.178139] Call Trace:
[ 1894.178224] intel_atomic_commit+0x240/0x320 [i915]
[ 1894.178251] drm_atomic_helper_commit_duplicated_state+0xc9/0xe0
[drm_kms_helper]
[ 1894.178321] __intel_display_resume+0x82/0xd0 [i915]
[ 1894.178391] intel_display_resume+0xcf/0x120 [i915]
[ 1894.178453] i915_drm_resume+0xb1/0x100 [i915]
[ 1894.178465] ? pci_pm_suspend_late+0x30/0x30
[ 1894.178473] dpm_run_callback+0x70/0x210
[ 1894.178484] device_resume+0xae/0x1f0
[ 1894.178493] async_resume+0x19/0x30
[ 1894.178502] async_run_entry_fn+0x39/0x160
[ 1894.178513] process_one_work+0x23c/0x590
[ 1894.178529] worker_thread+0x30/0x380
[ 1894.178539] ? rescuer_thread+0x340/0x340
[ 1894.178545] kthread+0x112/0x130
[ 1894.178552] ? kthread_create_on_node+0x60/0x60
[ 1894.178563] ret_from_fork+0x3a/0x50
[ 1894.178582] irq event stamp: 76782
[ 1894.178591] hardirqs last enabled at (76781): []
vprintk_emit+0x2c5/0x2d0
[ 1894.178600] hardirqs last disabled at (76782): []
trace_hardirqs_off_thunk+0x1a/0x1c
[ 1894.178609] softirqs last enabled at (76734): []
__do_softirq+0x35d/0x412
[ 1894.178618] softirqs last disabled at (76727): []
irq_exit+0xe0/0xf0
[ 1894.178687] WARNING: CPU: 2 PID: 1894 at
drivers/gpu/drm/i915/intel_display.c:12292 intel_atomic_commit_tail+0xd5e/0xdd0
[i915]
[ 1894.178692] ---[ end trace 0df08c0b9a67376e ]---
So, fix this by using the new drm_atomic_state.suspend_or_resume hook in
order to force us to retrieve a VCPI allocation when restoring a pipe's
atomic state. This is safe, since drm_dp_atomic_find_vcpi_slots() will
just return the VCPI allocation we had pre-suspend.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
---
drivers/gpu/drm/i915/intel_dp_mst.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b
[PATCH 1/3] drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we never successfully allocated VCPI to it. This is contrary to what we do in drm_dp_mst_allocate_vcpi(), where we only call drm_dp_mst_get_port_malloc() on the passed port if we successfully allocated VCPI to it. As a result, if drm_dp_mst_allocate_vcpi() fails during a modeset and another successive modeset calls drm_dp_mst_deallocate_vcpi() we will end up dropping someone else's malloc reference to the port. Example: [ 962.309260] == [ 962.309290] BUG: KASAN: use-after-free in drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309296] Read of size 4 at addr 888416c30004 by task kworker/0:1H/500 [ 962.309308] CPU: 0 PID: 500 Comm: kworker/0:1H Tainted: GW O 5.0.0-rc2Lyude-Test+ #1 [ 962.309313] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018 [ 962.309428] Workqueue: events_highpri intel_atomic_cleanup_work [i915] [ 962.309434] Call Trace: [ 962.309452] dump_stack+0xad/0x150 [ 962.309462] ? dump_stack_print_info.cold.0+0x1b/0x1b [ 962.309472] ? kmsg_dump_rewind_nolock+0xd9/0xd9 [ 962.309504] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309515] print_address_description+0x6c/0x23c [ 962.309542] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309568] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309577] kasan_report.cold.3+0x1a/0x32 [ 962.309605] ? drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309631] drm_dp_mst_put_port_malloc+0x72/0x180 [drm_kms_helper] [ 962.309658] ? drm_dp_mst_put_mstb_malloc+0x180/0x180 [drm_kms_helper] [ 962.309687] drm_dp_mst_destroy_state+0xcd/0x120 [drm_kms_helper] [ 962.309745] drm_atomic_state_default_clear+0x6ee/0xcc0 [drm] [ 962.309864] intel_atomic_state_clear+0xe/0x80 [i915] [ 962.309928] __drm_atomic_state_free+0x35/0xd0 [drm] [ 962.310044] intel_atomic_cleanup_work+0x56/0x70 [i915] [ 962.310057] process_one_work+0x884/0x1400 [ 962.310067] ? drain_workqueue+0x5a0/0x5a0 [ 962.310075] ? __schedule+0x87f/0x1e80 [ 962.310086] ? __sched_text_start+0x8/0x8 [ 962.310095] ? run_rebalance_domains+0x400/0x400 [ 962.310110] ? deref_stack_reg+0xb4/0x120 [ 962.310117] ? __read_once_size_nocheck.constprop.7+0x10/0x10 [ 962.310124] ? worker_enter_idle+0x47f/0x6a0 [ 962.310134] ? schedule+0xd7/0x2e0 [ 962.310141] ? __schedule+0x1e80/0x1e80 [ 962.310148] ? _raw_spin_lock_irq+0x9f/0x130 [ 962.310155] ? _raw_write_unlock_irqrestore+0x110/0x110 [ 962.310164] worker_thread+0x196/0x11e0 [ 962.310175] ? set_load_weight+0x2e0/0x2e0 [ 962.310181] ? __switch_to_asm+0x34/0x70 [ 962.310187] ? __switch_to_asm+0x40/0x70 [ 962.310194] ? process_one_work+0x1400/0x1400 [ 962.310199] ? __switch_to_asm+0x40/0x70 [ 962.310205] ? __switch_to_asm+0x34/0x70 [ 962.310211] ? __switch_to_asm+0x34/0x70 [ 962.310216] ? __switch_to_asm+0x40/0x70 [ 962.310221] ? __switch_to_asm+0x34/0x70 [ 962.310226] ? __switch_to_asm+0x40/0x70 [ 962.310231] ? __switch_to_asm+0x34/0x70 [ 962.310236] ? __switch_to_asm+0x40/0x70 [ 962.310242] ? syscall_return_via_sysret+0xf/0x7f [ 962.310248] ? __switch_to_asm+0x34/0x70 [ 962.310253] ? __switch_to_asm+0x40/0x70 [ 962.310258] ? __switch_to_asm+0x34/0x70 [ 962.310263] ? __switch_to_asm+0x40/0x70 [ 962.310268] ? __switch_to_asm+0x34/0x70 [ 962.310273] ? __switch_to_asm+0x40/0x70 [ 962.310281] ? __schedule+0x87f/0x1e80 [ 962.310292] ? __sched_text_start+0x8/0x8 [ 962.310300] ? save_stack+0x8c/0xb0 [ 962.310308] ? __kasan_kmalloc.constprop.6+0xc6/0xd0 [ 962.310313] ? kthread+0x98/0x3a0 [ 962.310318] ? ret_from_fork+0x35/0x40 [ 962.310334] ? __wake_up_common+0x178/0x6f0 [ 962.310343] ? _raw_spin_lock_irqsave+0xa4/0x140 [ 962.310349] ? __lock_text_start+0x8/0x8 [ 962.310355] ? _raw_write_lock_irqsave+0x70/0x130 [ 962.310360] ? __lock_text_start+0x8/0x8 [ 962.310371] ? process_one_work+0x1400/0x1400 [ 962.310376] kthread+0x2e2/0x3a0 [ 962.310383] ? kthread_create_on_node+0xc0/0xc0 [ 962.310389] ret_from_fork+0x35/0x40 [ 962.310401] Allocated by task 1462: [ 962.310410] __kasan_kmalloc.constprop.6+0xc6/0xd0 [ 962.310437] drm_dp_add_port+0xd60/0x1960 [drm_kms_helper] [ 962.310464] drm_dp_send_link_address+0x4b0/0x770 [drm_kms_helper] [ 962.310491] drm_dp_check_and_send_link_address+0x197/0x1f0 [drm_kms_helper] [ 962.310515] drm_dp_mst_link_probe_work+0x2b6/0x330 [drm_kms_helper] [ 962.310522] process_one_work+0x884/0x1400 [ 962.310529] worker_thread+0x196/0x11e0 [ 962.310533] kthread+0x2e2/0x3a0 [ 962.310538] ret_from_fork+0x35/0x40 [ 962.310543] Freed by task 500: [ 962.310550] __kasan_slab_free+0x133/0x180 [ 962.310555] kfree+0x92/0x1a0 [ 962.310581] drm_dp_mst_put_port_malloc+0x14d/0x180 [drm_kms_helper] [ 962
[PATCH 0/3] drm/dp_mst: Fix regressions from new atomic VCPI helpers
This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. Lyude Paul (3): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi() drm/atomic: Add drm_atomic_state->suspend_or_resume drm/i915: Always allocate VCPI during system resume drivers/gpu/drm/drm_atomic_helper.c | 16 -- drivers/gpu/drm/drm_dp_mst_topology.c | 44 ++- drivers/gpu/drm/i915/intel_display.c | 4 +-- drivers/gpu/drm/i915/intel_dp_mst.c | 9 -- include/drm/drm_atomic.h | 11 +++ include/drm/drm_atomic_helper.h | 3 +- 6 files changed, 71 insertions(+), 16 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/atomic: Add drm_atomic_state->suspend_or_resume
Since
commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")
We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a connector is
unregistered before we attempt to restore the atomic state, something we
end up failing the atomic check that happens when trying to restore the
state during resume.
Normally this would be OK: we try our best to make sure that the atomic
state pre-suspend can be restored post-suspend, but failures at that
point usually don't cause problems. That is of course, until we
introduced the new atomic MST VCPI helpers:
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:65:pipe B] active
changed
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for
[CONNECTOR:123:DP-5]
[drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Disabling
[CONNECTOR:123:DP-5]
[drm:drm_atomic_get_private_obj_state [drm]] Added new private object
25844636 state 9fd2899a to 3a13d7b8
WARNING: CPU: 6 PID: 1070 at drivers/gpu/drm/drm_dp_mst_topology.c:3153
drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Modules linked in: fuse vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic joydev iTCO_wdt i915(O) wmi_bmof intel_rapl btusb btrtl
x86_pkg_temp_thermal btbcm btintel coretemp i2c_algo_bit drm_kms_helper(O)
crc32_pclmul snd_hda_intel syscopyarea sysfillrect snd_hda_codec sysimgblt
snd_hda_core bluetooth fb_sys_fops snd_pcm pcspkr drm(O) psmouse snd_timer
mei_me ecdh_generic i2c_i801 mei i2c_core ucsi_acpi typec_ucsi typec wmi
thinkpad_acpi ledtrig_audio snd soundcore tpm_tis rfkill tpm_tis_core video tpm
acpi_pad pcc_cpufreq uas usb_storage crc32c_intel nvme serio_raw xhci_pci
nvme_core xhci_hcd
CPU: 6 PID: 1070 Comm: gnome-shell Tainted: GW O
5.0.0-rc2Lyude-Test+ #1
Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
RIP: 0010:drm_dp_atomic_release_vcpi_slots+0xb9/0x200 [drm_kms_helper]
Code: 00 4c 39 6d f0 74 49 48 8d 7b 10 48 89 f9 48 c1 e9 03 42 80 3c 21 00 0f
85 d2 00 00 00 48 8b 6b 10 48 8d 5d f0 49 39 ee 75 c5 <0f> 0b 48 c7 c7 c0 78 b3
a0 48 89 c2 4c 89 ee e8 03 6c aa ff b8 ea
RSP: 0018:88841235f268 EFLAGS: 00010246
RAX: 88841bf12ab0 RBX: 88841bf12aa8 RCX: 1110837e2557
RDX: dc00 RSI: RDI: ed108246bde0
RBP: 88841bf12ab8 R08: ed1083db3c93 R09: ed1083db3c92
R10: ed1083db3c92 R11: 88841ed9e497 R12: 888419555d80
R13: 8883bc499100 R14: 88841bf12ab8 R15:
FS: 7f16fbd4cd00() GS:88841ed8() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f1687c9f000 CR3: 0003ba3cc003 CR4: 003606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
drm_atomic_helper_check_modeset+0xf21/0x2f50 [drm_kms_helper]
? drm_atomic_helper_commit_modeset_enables+0xa90/0xa90 [drm_kms_helper]
? __printk_safe_exit+0x10/0x10
? save_stack+0x8c/0xb0
? vprintk_func+0x96/0x1bf
? __printk_safe_exit+0x10/0x10
intel_atomic_check+0x234/0x4750 [i915]
? printk+0x9f/0xc5
? kmsg_dump_rewind_nolock+0xd9/0xd9
? _raw_spin_lock_irqsave+0xa4/0x140
? drm_atomic_check_only+0xb1/0x28b0 [drm]
? drm_dbg+0x186/0x1b0 [drm]
? drm_dev_dbg+0x200/0x200 [drm]
? intel_link_compute_m_n+0xb0/0xb0 [i915]
? drm_mode_put_tile_group+0x20/0x20 [drm]
? skl_plane_format_mod_supported+0x17f/0x1b0 [i915]
? drm_plane_check_pixel_format+0x14a/0x310 [drm]
drm_atomic_check_only+0x13c4/0x28b0 [drm]
? drm_state_info+0x220/0x220 [drm]
? drm_atomic_helper_disable_plane+0x1d0/0x1d0 [drm_kms_helper]
? pick_single_encoder_for_connector+0xe0/0xe0 [drm_kms_helper]
? kasan_unpoison_shadow+0x35/0x40
drm_atomic_commit+0x3b/0x100 [drm]
drm_atomic_helper_set_config+0xd5/0x100 [drm_kms_helper]
drm_mode_setcrtc+0x636/0x1660 [drm]
? vprintk_func+0x96/0x1bf
? drm_dev_dbg+0x200/0x200 [drm]
? drm_mode_getcrtc+0x790/0x790 [drm]
? printk+0x9f/0xc5
? mutex_unlock+0x1d/0x40
? drm_mode_addfb2+0x2e9/0x3a0 [drm]
? rcu_sync_dtor+0x2e0/0x2e0
? drm_dbg+0x186/0x1b0 [drm]
? set_page_dirty+0x271/0x4d0
drm_ioctl_kernel+0x203/0x290 [drm]
? drm_mode_getcrtc+0x790/0x790 [drm]
? drm_setversion+0x7f0/0x7f0 [drm]
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x34/0x70
drm_ioctl+0x445/0x950 [drm]
? drm_mode_getcrtc+0x790/0x790 [drm]
? drm_getunique+0x220/0x220 [drm]
? expand_files.part.10+0x920/0x920
do_vfs_ioctl+0x1a1/0x13d0
? ioctl_preallocate+0x2b0/0x2b0
? __fget_light+0x2d6/0x390
? schedule+0xd7/0x2e0
? fget_raw+0x10/0x10
? apic_timer_interrupt+0xa/0x20
? apic_timer_interrupt+0xa/0x20
? rcu_cleanup_dead_rnp+0x2c0/0x2c0
ksys_ioctl+0x60/0x90
__x64_sys_ioctl+0x6f/0xb0
do_syscall_64+0x136/0x440
? syscall_return_slow
[v9 1/3] drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 73 +++
include/drm/drm_connector.h | 46
3 files changed, 123 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8475396..3a61a38 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,30 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetr
[v9 3/3] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be
taken care separately.
v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Addressed Maarten's review comment and limited this currently
to non lspcon based devices.
v7: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic.c| 1 +
drivers/gpu/drm/i915/intel_connector.c | 8
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 25 +
4 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..76b7114 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+ new_state->colorspace != old_state->colorspace ||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..ac2aed7 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
}
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+ if (!drm_mode_create_colorspace_property(connector))
+ drm_object_attach_property(&connector->base,
+ connector->colorspace_property, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 85b913e..5178a9a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct drm_connector
*connector,
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_colorspace_property(struct drm_connector *connector);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 97a98e1..5c5009d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -498,6 +498,24 @@ static void intel_hdmi_set_avi_infoframe(struct
intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
+ /* Set ITU 709 as default for HDMI */
+ frame.avi.colorimetry = DRM_MODE_COLORIMETRY_ITU_709;
+ } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XV_YCC_601) {
+ frame.avi.colorimetry = conn_state->colorspace;
+ } else {
+ frame.avi.colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ /*
+* Starting from extended list where COLORIMETRY_XV_YCC_601
+* is the first extended mode and its value is 0 as per HDMI
+* specification.
+* TODO: This needs to be extended for LSPCON implementation
+* as well. Will be implemented separately.
+*/
+ frame.avi.extended_colorimetry = conn_state->colorspace -
+ DRM_MODE_COLORIMETRY_XV_YCC_601;
+ }
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi,
[v9 2/3] drm: Add DP colorspace property
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Split the changes to have separate colorspace property for
DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3a61a38..d0175e7b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -850,6 +850,29 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
};
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
+ { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ /* DP MSA Colorimetry */
+ { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
+ { DRM_MODE_DP_COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
+ { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
+ { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+ { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
+ { DRM_MODE_DP_COLORIMETRY_DCI_P3, "DCI-P3" },
+ { DRM_MODE_DP_COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Profile" },
+};
+
+
/**
* DOC: standard connector properties
*
@@ -1612,6 +1635,14 @@ int drm_mode_create_colorspace_property(struct
drm_connector *connector)
ARRAY_SIZE(hdmi_colorspaces));
if (!prop)
return -ENOMEM;
+ } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+ "Colorspace", dp_colorspaces,
+ ARRAY_SIZE(dp_colorspaces));
+ if (!prop)
+ return -ENOMEM;
}
connector->colorspace_property = prop;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v9 0/3] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. Uma Shankar (3): drm: Add HDMI colorspace property drm: Add DP colorspace property drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c| 104 + drivers/gpu/drm/i915/intel_atomic.c| 1 + drivers/gpu/drm/i915/intel_connector.c | 8 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 25 include/drm/drm_connector.h| 46 +++ 7 files changed, 189 insertions(+) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Task to rename CMA helpers
On Tuesday, 2019-01-29 14:21:53 +0100, Daniel Vetter wrote: > I'm kinda fed up explaining why the have a confusing name :-) > > Cc: Noralf Trønnes > Cc: Laurent Pinchart > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/todo.rst | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 38360ede1221..17f1cde6adab 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -262,6 +262,16 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > > +Rename CMA helpers to DMA helpers > +- > + > +CMA (standing for contiguous memory allocator) is really a bit an accident of > +what these were used for first, a much better name would be DMA helpers. In > the > +text these should even be called coherent DMA memory helpers (so maybd CDM, > but > +no one knows what that means) since underneath they just use > dma_alloc_coherent. s/maybd/maybe/ > + > +Contact: Laurent Pinchart, Daniel Vetter > + > Core refactorings > = > > -- > 2.20.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
On Tue, Jan 29, 2019 at 6:36 PM Greg KH wrote:
>
> On Tue, Jan 29, 2019 at 05:50:05PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
> > >
> > >
> > > Den 24.01.2019 18.57, skrev Daniel Vetter:
> > > > On Thu, Jan 24, 2019 at 6:46 PM Greg KH
> > > > wrote:
> > > >>
> > > >> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> > > >>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
> > >
> > >
> > > Den 22.01.2019 20.30, skrev Daniel Vetter:
> > > > On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes
> > > > wrote:
> > > >>
> > > >>
> > > >>
> > > >> Den 22.01.2019 10.32, skrev Daniel Vetter:
> > > >>> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
> > >
> > >
> > > Den 21.01.2019 10.55, skrev Daniel Vetter:
> > > > On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter wrote:
> > > >> On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes wrote:
> > > >>> This adds resource managed (devres) versions of
> > > >>> drm_dev_init() and
> > > >>> drm_dev_register().
> > > >>>
> > > >>> Also added is devm_drm_dev_register_with_fbdev() which sets
> > > >>> up generic
> > > >>> fbdev emulation as well.
> > > >>>
> > > >>> devm_drm_dev_register() isn't exported since there are no
> > > >>> users.
> > > >>>
> > > >>> Signed-off-by: Noralf Trønnes
> > > >>
> > >
> > >
> > >
> > > >>> diff --git a/drivers/gpu/drm/drm_drv.c
> > > >>> b/drivers/gpu/drm/drm_drv.c
> > > >>> index 381581b01d48..12129772be45 100644
> > > >>> --- a/drivers/gpu/drm/drm_drv.c
> > > >>> +++ b/drivers/gpu/drm/drm_drv.c
> > > >>> @@ -36,6 +36,7 @@
> > > >>>
> > > >>> #include
> > > >>> #include
> > > >>> +#include
> > > >>> #include
> > > >>>
> > > >>> #include "drm_crtc_internal.h"
> > > >>> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct
> > > >>> drm_device *dev)
> > > >>> }
> > > >>> EXPORT_SYMBOL(drm_dev_unregister);
> > > >>>
> > > >>> +static void devm_drm_dev_init_release(void *data)
> > > >>> +{
> > > >>> + drm_dev_put(data);
> > > >
> > > > We need drm_dev_unplug() here, or this isn't safe.
> > >
> > > This function is only used to cover the error path if probe
> > > fails before
> > > devm_drm_dev_register() is called.
> > > devm_drm_dev_register_release() is
> > > the one that calls unplug. There are comments about this in the
> > > functions.
> > > >>>
> > > >>> I think I get a prize for being ignorant and blind :-/
> > > >>>
> > >
> > > >
> > > >>> +}
> > > >>> +
> > > >>> +/**
> > > >>> + * devm_drm_dev_init - Resource managed drm_dev_init()
> > > >>> + * @parent: Parent device object
> > > >>> + * @dev: DRM device
> > > >>> + * @driver: DRM driver
> > > >>> + *
> > > >>> + * Managed drm_dev_init(). The DRM device initialized with
> > > >>> this function is
> > > >>> + * automatically released on driver detach. You must supply a
> > > >
> > > > I think a bit more clarity here would be good:
> > > >
> > > > "... automatically released on driver unbind by callind
> > > > drm_dev_unplug()."
> > > >
> > > >>> + * &drm_driver.release callback to control the finalization
> > > >>> explicitly.
> > > >
> > > > I think a loud warning for these is in order:
> > > >
> > > > "WARNING:
> > > >
> > > > "In generally it is unsafe to use devm functions for drm
> > > > structures
> > > > because the lifetimes of &drm_device and the underlying &device
> > > > do not
> > > > match. This here works because it doesn't immediately free
> > > > anything, but
> > > > only calls drm_dev_unplug(), which internally decrements the
> > > > &drm_device
> > > > refcount through drm_dev_put().
> > > >
> > > > "All other drm structures must still be explicitly released in
> > > > the
> > > > &drm_driver.release callback."
> > > >
> > > > While thinking about this I just realized that with this design
> > > > we have no
> > > > good place to call drm_atomic_helper_shutdown(). Which we need
> > > > to, or all
> > > > kinds of things will leak badly (connectors, fb, ...), but
> > > > there's no
> > > > place to call it:
> > > > - unbind is too early, since we haven't yet called
> > >
[Bug 109499] amdgpu 4k modes not working
https://bugs.freedesktop.org/show_bug.cgi?id=109499 --- Comment #3 from Nadal Gonzalo García Zavala --- Created attachment 143253 --> https://bugs.freedesktop.org/attachment.cgi?id=143253&action=edit parse-edid -- 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: Constify drm_color_lut_check()
On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote:
> Hi Ville.
>
> On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > drm_color_lut_check() doens't modify the passed in blob so
> > let's make it const.
> >
> > Also s/uint32_y/u32/ while at it.
> >
> > Cc: Matt Roper
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_color_mgmt.c | 6 +++---
> > include/drm/drm_color_mgmt.h | 4 ++--
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index 968ca7c91ad8..3c8826a91a03 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -474,10 +474,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
> > *
> > * Returns 0 on success, -EINVAL on failure.
> > */
> > -int drm_color_lut_check(struct drm_property_blob *lut,
> > - uint32_t tests)
> > +int drm_color_lut_check(const struct drm_property_blob *lut,
> > + u32 tests)
>
> No need to linewrap this line.
> > {
> > - struct drm_color_lut *entry;
> > + const struct drm_color_lut *entry;
> > int i;
> >
> > if (!lut || !tests)
> > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> > index 6affbda6d9cb..58d4b20b5b97 100644
> > --- a/include/drm/drm_color_mgmt.h
> > +++ b/include/drm/drm_color_mgmt.h
> > @@ -96,6 +96,6 @@ enum drm_color_lut_tests {
> > DRM_COLOR_LUT_NON_DECREASING = BIT(1),
> > };
> >
> > -int drm_color_lut_check(struct drm_property_blob *lut,
> > - uint32_t tests);
> > +int drm_color_lut_check(const struct drm_property_blob *lut,
> > + u32 tests);
> Likewise.
>
> With the linewrap fixed:
> Reviewed-by: Sam Ravnborg
Thanks.
>
> Note: does not apply to my drm-misc tree. Anything I miss here?
I think it was merged via drm-intel.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109499] amdgpu 4k modes not working
https://bugs.freedesktop.org/show_bug.cgi?id=109499 --- Comment #2 from Nadal Gonzalo García Zavala --- Created attachment 143252 --> https://bugs.freedesktop.org/attachment.cgi?id=143252&action=edit dmesg -- 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 109499] amdgpu 4k modes not working
https://bugs.freedesktop.org/show_bug.cgi?id=109499 --- Comment #1 from Nadal Gonzalo García Zavala --- Created attachment 143251 --> https://bugs.freedesktop.org/attachment.cgi?id=143251&action=edit EDID firmware -- 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 109499] amdgpu 4k modes not working
https://bugs.freedesktop.org/show_bug.cgi?id=109499 Bug ID: 109499 Summary: amdgpu 4k modes not working Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: snorkellingcac...@gmail.com Hi. We have an AMD W7100. We are trying to use two DisplayPort at 3840x2160. Firstly, those modes are not listed by xrandr Second, adding and setting a new xrandr mode may work only after replugging DisplayPort cables on other DisplayPort (for example, disconnecting DP0 and DP1 and connecting to DP2 and DP3). Then, fix will not persist across reboots. EDID seems to behave flaky by some reason (EDID invalid messages from dmesg) We however have a vendor provided EDID which we forced to be loaded on boot. That only changed available modes to a max of 1920x1080 but symptoms kept being the same. (edid-decode info shows 3840x2160 modes however) We tried thousands of options/configs. We are on Ubuntu 16.04. We tried amdgpu-pro 18.30 and 18.10 version of the driver, with kernel 4.15 and kernel 4.13, using amdgpu.dc=0 and amdgpu.dc=1, using amdgpu and modesetting as driver on xorg. The errors dmesg throws when adding/setting the 3840x2160 with xrandr are like: X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 16 (RRCreateMode) Serial number of failed request: 43 Current serial number in output stream: 43 [241317.628306] [drm:drm_crtc_helper_set_config [drm_kms_helper]] *ERROR* failed to set mode on [CRTC:37:crtc-0] xrandr: Configure crtc 0 failed xrandr: Configure crtc 1 failed [241317.940299] [drm:drm_crtc_helper_set_config [drm_kms_helper]] *ERROR* failed to set mode on [CRTC:39:crtc-1] On some setup, with drm debug enabled on kernel and when trying to set the 3840x2160 mode with xrandr dmesg trhow: [7.638690] [drm:drm_mode_prune_invalid [drm]] Not using 3840x2160 mode: CLOCK_HIGH When using amdgpu.dc=1 that changed to something like: X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 16 (RRCreateMode) Serial number of failed request: 39 Current serial number in output stream: 39 [ 4482.053606] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] amdgpu_crtc id:0 crtc_state_flags: enable:0, active:0, planes_changed:0, mode_changed:0,active_changed:0,connectors_changed:0 [ 4482.056191] [drm:drm_mode_setcrtc [drm]] [CRTC:43:crtc-0] [ 4482.056232] [drm:drm_mode_setcrtc [drm]] [CONNECTOR:55:DP-1] [ 4482.056390] [drm:best_encoder [amdgpu]] Finding the best encoder [ 4482.056530] [drm:best_encoder [amdgpu]] Finding the best encoder [ 4482.056661] [drm:best_encoder [amdgpu]] Finding the best encoder [ 4482.056839] [drm:dm_update_crtcs_state [amdgpu]] amdgpu_crtc id:0 crtc_state_flags: enable:1, active:1, planes_changed:0, mode_changed:1,active_changed:1,connectors_changed:1 [ 4482.057041] [drm:update_stream_scaling_settings [amdgpu]] Destination Rectangle x:0 y:0 width:3840 height:2160 [ 4482.057201] [drm:dm_update_crtcs_state [amdgpu]] amdgpu_crtc id:0 crtc_state_flags: enable:1, active:1, planes_changed:0, mode_changed:1,active_changed:1,connectors_changed:1 [ 4482.057357] [drm:dm_update_crtcs_state [amdgpu]] Enabling DRM crtc: 43 [ 4482.057539] [drm:dm_update_planes_state [amdgpu]] Enabling DRM plane: 41 on DRM crtc 43 [ 4482.057687] [drm:amdgpu_dm_atomic_check [amdgpu]] Atomic check failed with err: -22 xrandr: Configure crtc 0 failed [ 4482.092223] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] amdgpu_crtc id:0 crtc_state_flags: enable:0, active:0, planes_changed:0, mode_changed:0,active_changed:0,connectors_changed:0 xrandr: Configure crtc 0 failed [ 4482.094553] [drm:drm_mode_setcrtc [drm]] [CRTC:43:crtc-0] [ 4482.094567] [drm:drm_mode_setcrtc [drm]] [CONNECTOR:57:DP-2] [ 4482.094622] [drm:best_encoder [amdgpu]] Finding the best encoder [ 4482.094668] [drm:best_encoder [amdgpu]] Finding the best encoder [ 4482.094713] [drm:best_encoder [amdgpu]] Finding the best encoder [ 4482.094761] [drm:dm_update_crtcs_state [amdgpu]] amdgpu_crtc id:0 crtc_state_flags: enable:1, active:1, planes_changed:0, mode_changed:1,active_changed:1,connectors_changed:1 [ 4482.094809] [drm:update_stream_scaling_settings [amdgpu]] Destination Rectangle x:0 y:0 width:3840 height:2160 [ 4482.094849] [drm:dm_update_crtcs_state [amdgpu]] amdgpu_crtc id:0 crtc_state_flags: enable:1, active:1, planes_changed:0, mode_changed:1,active_changed:1,connectors_changed:1 [ 4482.094887] [drm:dm_update_crtcs_state [amdgpu]] Enabling DRM crtc: 43 [ 4482.094938] [drm:dm_update_planes_state [amdgpu]] Enabling DRM plane: 41 on DRM crtc
Re: [PATCH] drm: Constify drm_color_lut_check()
Hi Ville.
On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_color_lut_check() doens't modify the passed in blob so
> let's make it const.
>
> Also s/uint32_y/u32/ while at it.
>
> Cc: Matt Roper
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 6 +++---
> include/drm/drm_color_mgmt.h | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 968ca7c91ad8..3c8826a91a03 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -474,10 +474,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
> *
> * Returns 0 on success, -EINVAL on failure.
> */
> -int drm_color_lut_check(struct drm_property_blob *lut,
> - uint32_t tests)
> +int drm_color_lut_check(const struct drm_property_blob *lut,
> + u32 tests)
No need to linewrap this line.
> {
> - struct drm_color_lut *entry;
> + const struct drm_color_lut *entry;
> int i;
>
> if (!lut || !tests)
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 6affbda6d9cb..58d4b20b5b97 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -96,6 +96,6 @@ enum drm_color_lut_tests {
> DRM_COLOR_LUT_NON_DECREASING = BIT(1),
> };
>
> -int drm_color_lut_check(struct drm_property_blob *lut,
> - uint32_t tests);
> +int drm_color_lut_check(const struct drm_property_blob *lut,
> + u32 tests);
Likewise.
With the linewrap fixed:
Reviewed-by: Sam Ravnborg
Note: does not apply to my drm-misc tree. Anything I miss here?
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 4/5] mm/hmm: add support for peer to peer to HMM device memory
From: Jérôme Glisse
Signed-off-by: Jérôme Glisse
Cc: Logan Gunthorpe
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Bjorn Helgaas
Cc: Christian Koenig
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
include/linux/hmm.h | 47 +
mm/hmm.c| 63 +
2 files changed, 105 insertions(+), 5 deletions(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 4a1454e3efba..7a3ac182cc48 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -710,6 +710,53 @@ struct hmm_devmem_ops {
const struct page *page,
unsigned int flags,
pmd_t *pmdp);
+
+ /*
+* p2p_map() - map page for peer to peer between device
+* @devmem: device memory structure (see struct hmm_devmem)
+* @range: range of virtual address that is being mapped
+* @device: device the range is being map to
+* @addr: first virtual address in the range to consider
+* @pa: device address (where actual mapping is store)
+* Returns: number of page successfuly mapped, 0 otherwise
+*
+* Map page belonging to devmem to another device for peer to peer
+* access. Device can decide not to map in which case memory will
+* be migrated to main memory.
+*
+* Also there is no garantee that all the pages in the range does
+* belongs to the devmem so it is up to the function to check that
+* every single page does belong to devmem.
+*
+* Note for now we do not care about error exect error, so on failure
+* function should just return 0.
+*/
+ long (*p2p_map)(struct hmm_devmem *devmem,
+ struct hmm_range *range,
+ struct device *device,
+ unsigned long addr,
+ dma_addr_t *pas);
+
+ /*
+* p2p_unmap() - unmap page from peer to peer between device
+* @devmem: device memory structure (see struct hmm_devmem)
+* @range: range of virtual address that is being mapped
+* @device: device the range is being map to
+* @addr: first virtual address in the range to consider
+* @pa: device address (where actual mapping is store)
+* Returns: number of page successfuly unmapped, 0 otherwise
+*
+* Unmap page belonging to devmem previously map with p2p_map().
+*
+* Note there is no garantee that all the pages in the range does
+* belongs to the devmem so it is up to the function to check that
+* every single page does belong to devmem.
+*/
+ unsigned long (*p2p_unmap)(struct hmm_devmem *devmem,
+ struct hmm_range *range,
+ struct device *device,
+ unsigned long addr,
+ dma_addr_t *pas);
};
/*
diff --git a/mm/hmm.c b/mm/hmm.c
index 1a444885404e..fd49b1e116d0 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -1193,16 +1193,19 @@ long hmm_range_dma_map(struct hmm_range *range,
dma_addr_t *daddrs,
bool block)
{
- unsigned long i, npages, mapped, page_size;
+ unsigned long i, npages, mapped, page_size, addr;
long ret;
+again:
ret = hmm_range_fault(range, block);
if (ret <= 0)
return ret ? ret : -EBUSY;
+ mapped = 0;
+ addr = range->start;
page_size = hmm_range_page_size(range);
npages = (range->end - range->start) >> range->page_shift;
- for (i = 0, mapped = 0; i < npages; ++i) {
+ for (i = 0; i < npages; ++i, addr += page_size) {
enum dma_data_direction dir = DMA_FROM_DEVICE;
struct page *page;
@@ -1226,6 +1229,29 @@ long hmm_range_dma_map(struct hmm_range *range,
goto unmap;
}
+ if (is_device_private_page(page)) {
+ struct hmm_devmem *devmem = page->pgmap->data;
+
+ if (!devmem->ops->p2p_map || !devmem->ops->p2p_unmap) {
+ /* Fall-back to main memory. */
+ range->default_flags |=
+ range->flags[HMM_PFN_DEVICE_PRIVATE];
+ goto again;
+ }
+
+ ret = devmem->ops->p2p_map(devmem, range, device,
+ addr, daddrs);
+ if (ret <= 0) {
+ /* Fall-back to main memory. */
+ range->default_flags |=
+
[RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma
From: Jérôme Glisse
Allow mmap of device file to export device memory to peer to peer
devices. This will allow for instance a network device to access a
GPU memory or to access a storage device queue directly.
The common case will be a vma created by userspace device driver
that is then share to another userspace device driver which call
in its kernel device driver to map that vma.
The vma does not need to have any valid CPU mapping so that only
peer to peer device might access its content. Or it could have
valid CPU mapping too in that case it should point to same memory
for consistency.
Note that peer to peer mapping is highly platform and device
dependent and it might not work in all the cases. However we do
expect supports for this to grow on more hardware platform.
This patch only adds new call backs to vm_operations_struct bulk
of code light within common bus driver (like pci) and device
driver (both the exporting and importing device).
Current design mandate that the importer must obey mmu_notifier
and invalidate any peer to peer mapping anytime a notification
of invalidation happens for a range that have been peer to peer
mapped. This allows exporter device to easily invalidate mapping
for any importer device.
Signed-off-by: Jérôme Glisse
Cc: Logan Gunthorpe
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Bjorn Helgaas
Cc: Christian Koenig
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
include/linux/mm.h | 38 ++
1 file changed, 38 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 80bb6408fe73..1bd60a90e575 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -429,6 +429,44 @@ struct vm_operations_struct {
pgoff_t start_pgoff, pgoff_t end_pgoff);
unsigned long (*pagesize)(struct vm_area_struct * area);
+ /*
+* Optional for device driver that want to allow peer to peer (p2p)
+* mapping of their vma (which can be back by some device memory) to
+* another device.
+*
+* Note that the exporting device driver might not have map anything
+* inside the vma for the CPU but might still want to allow a peer
+* device to access the range of memory corresponding to a range in
+* that vma.
+*
+* FOR PREDICTABILITY IF DRIVER SUCCESSFULY MAP A RANGE ONCE FOR A
+* DEVICE THEN FURTHER MAPPING OF THE SAME IF THE VMA IS STILL VALID
+* SHOULD ALSO BE SUCCESSFUL. Following this rule allow the importing
+* device to map once during setup and report any failure at that time
+* to the userspace. Further mapping of the same range might happen
+* after mmu notifier invalidation over the range. The exporting device
+* can use this to move things around (defrag BAR space for instance)
+* or do other similar task.
+*
+* IMPORTER MUST OBEY mmu_notifier NOTIFICATION AND CALL p2p_unmap()
+* WHEN A NOTIFIER IS CALL FOR THE RANGE ! THIS CAN HAPPEN AT ANY
+* POINT IN TIME WITH NO LOCK HELD.
+*
+* In below function, the device argument is the importing device,
+* the exporting device is the device to which the vma belongs.
+*/
+ long (*p2p_map)(struct vm_area_struct *vma,
+ struct device *device,
+ unsigned long start,
+ unsigned long end,
+ dma_addr_t *pa,
+ bool write);
+ long (*p2p_unmap)(struct vm_area_struct *vma,
+ struct device *device,
+ unsigned long start,
+ unsigned long end,
+ dma_addr_t *pa);
+
/* notification that a previously read-only page is about to become
* writable, if an error is returned it will cause a SIGBUS */
vm_fault_t (*page_mkwrite)(struct vm_fault *vmf);
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 5/5] mm/hmm: add support for peer to peer to special device vma
From: Jérôme Glisse
Special device vma (mmap of a device file) can correspond to device
driver object that some device driver might want to share with other
device (giving access to). This add support for HMM to map those
special device vma if the owning device (exporter) allows it.
Signed-off-by: Jérôme Glisse
Cc: Logan Gunthorpe
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Bjorn Helgaas
Cc: Christian Koenig
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
include/linux/hmm.h | 6 ++
mm/hmm.c| 156 ++--
2 files changed, 128 insertions(+), 34 deletions(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 7a3ac182cc48..98ebe9f52432 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -137,6 +137,7 @@ enum hmm_pfn_flag_e {
* result of vmf_insert_pfn() or vm_insert_page(). Therefore, it should
not
* be mirrored by a device, because the entry will never have
HMM_PFN_VALID
* set and the pfn value is undefined.
+ * HMM_PFN_P2P: this entry have been map as P2P ie the dma address is valid
*
* Driver provide entry value for none entry, error entry and special entry,
* driver can alias (ie use same value for error and special for instance). It
@@ -151,6 +152,7 @@ enum hmm_pfn_value_e {
HMM_PFN_ERROR,
HMM_PFN_NONE,
HMM_PFN_SPECIAL,
+ HMM_PFN_P2P,
HMM_PFN_VALUE_MAX
};
@@ -250,6 +252,8 @@ static inline bool hmm_range_valid(struct hmm_range *range)
static inline struct page *hmm_pfn_to_page(const struct hmm_range *range,
uint64_t pfn)
{
+ if (pfn == range->values[HMM_PFN_P2P])
+ return NULL;
if (pfn == range->values[HMM_PFN_NONE])
return NULL;
if (pfn == range->values[HMM_PFN_ERROR])
@@ -270,6 +274,8 @@ static inline struct page *hmm_pfn_to_page(const struct
hmm_range *range,
static inline unsigned long hmm_pfn_to_pfn(const struct hmm_range *range,
uint64_t pfn)
{
+ if (pfn == range->values[HMM_PFN_P2P])
+ return -1UL;
if (pfn == range->values[HMM_PFN_NONE])
return -1UL;
if (pfn == range->values[HMM_PFN_ERROR])
diff --git a/mm/hmm.c b/mm/hmm.c
index fd49b1e116d0..621a4f831483 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -1058,37 +1058,36 @@ long hmm_range_snapshot(struct hmm_range *range)
}
EXPORT_SYMBOL(hmm_range_snapshot);
-/*
- * hmm_range_fault() - try to fault some address in a virtual address range
- * @range: range being faulted
- * @block: allow blocking on fault (if true it sleeps and do not drop mmap_sem)
- * Returns: 0 on success ortherwise:
- * -EINVAL:
- * Invalid argument
- * -ENOMEM:
- * Out of memory.
- * -EPERM:
- * Invalid permission (for instance asking for write and range
- * is read only).
- * -EAGAIN:
- * If you need to retry and mmap_sem was drop. This can only
- * happens if block argument is false.
- * -EBUSY:
- * If the the range is being invalidated and you should wait for
- * invalidation to finish.
- * -EFAULT:
- * Invalid (ie either no valid vma or it is illegal to access that
- * range), number of valid pages in range->pfns[] (from range
start
- * address).
- *
- * This is similar to a regular CPU page fault except that it will not trigger
- * any memory migration if the memory being faulted is not accessible by CPUs
- * and caller does not ask for migration.
- *
- * On error, for one virtual address in the range, the function will mark the
- * corresponding HMM pfn entry with an error flag.
- */
-long hmm_range_fault(struct hmm_range *range, bool block)
+static int hmm_vma_p2p_map(struct hmm_range *range, struct vm_area_struct *vma,
+ unsigned long start, unsigned long end,
+ struct device *device, dma_addr_t *pas)
+{
+ struct hmm_vma_walk hmm_vma_walk;
+ unsigned long npages, i;
+ bool fault, write;
+ uint64_t *pfns;
+ int ret;
+
+ i = (start - range->start) >> PAGE_SHIFT;
+ npages = (end - start) >> PAGE_SHIFT;
+ pfns = &range->pfns[i];
+ pas = &pas[i];
+
+ hmm_vma_walk.range = range;
+ hmm_vma_walk.fault = true;
+ hmm_range_need_fault(&hmm_vma_walk, pfns, npages,
+ 0, &fault, &write);
+
+ ret = vma->vm_ops->p2p_map(vma, device, start, end, pas, write);
+ for (i = 0; i < npages; ++i) {
+ pfns[i] = ret ? range->values[HMM_PFN_ERROR] :
+ range->values[HMM_PFN_P2P];
+ }
+ return ret;
+}
[RFC PATCH 2/5] drivers/base: add a function to test peer to peer capability
From: Jérôme Glisse
device_test_p2p() return true if two devices can peer to peer to
each other. We add a generic function as different inter-connect
can support peer to peer and we want to genericaly test this no
matter what the inter-connect might be. However this version only
support PCIE for now.
Signed-off-by: Jérôme Glisse
Cc: Logan Gunthorpe
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Bjorn Helgaas
Cc: Christian Koenig
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
drivers/base/core.c| 20
include/linux/device.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0073b09bb99f..56023b00e108 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -3167,3 +3168,22 @@ void device_set_of_node_from_dev(struct device *dev,
const struct device *dev2)
dev->of_node_reused = true;
}
EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
+
+/**
+ * device_test_p2p - test if two device can peer to peer to each other
+ * @devA: device A
+ * @devB: device B
+ * Returns: true if device can peer to peer to each other, false otherwise
+ */
+bool device_test_p2p(struct device *devA, struct device *devB)
+{
+ /*
+* For now we only support PCIE peer to peer but other inter-connect
+* can be added.
+*/
+ if (pci_test_p2p(devA, devB))
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(device_test_p2p);
diff --git a/include/linux/device.h b/include/linux/device.h
index 6cb4640b6160..0d532d7f0779 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1250,6 +1250,7 @@ extern int device_online(struct device *dev);
extern void set_primary_fwnode(struct device *dev, struct fwnode_handle
*fwnode);
extern void set_secondary_fwnode(struct device *dev, struct fwnode_handle
*fwnode);
void device_set_of_node_from_dev(struct device *dev, const struct device
*dev2);
+bool device_test_p2p(struct device *devA, struct device *devB);
static inline int dev_num_vf(struct device *dev)
{
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/5] pci/p2p: add a function to test peer to peer capability
From: Jérôme Glisse
device_test_p2p() return true if two devices can peer to peer to
each other. We add a generic function as different inter-connect
can support peer to peer and we want to genericaly test this no
matter what the inter-connect might be. However this version only
support PCIE for now.
Signed-off-by: Jérôme Glisse
Cc: Logan Gunthorpe
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Bjorn Helgaas
Cc: Christian Koenig
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: io...@lists.linux-foundation.org
---
drivers/pci/p2pdma.c | 27 +++
include/linux/pci-p2pdma.h | 6 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index c52298d76e64..620ac60babb5 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -797,3 +797,30 @@ ssize_t pci_p2pdma_enable_show(char *page, struct pci_dev
*p2p_dev,
return sprintf(page, "%s\n", pci_name(p2p_dev));
}
EXPORT_SYMBOL_GPL(pci_p2pdma_enable_show);
+
+bool pci_test_p2p(struct device *devA, struct device *devB)
+{
+ struct pci_dev *pciA, *pciB;
+ bool ret;
+ int tmp;
+
+ /*
+* For now we only support PCIE peer to peer but other inter-connect
+* can be added.
+*/
+ pciA = find_parent_pci_dev(devA);
+ pciB = find_parent_pci_dev(devB);
+ if (pciA == NULL || pciB == NULL) {
+ ret = false;
+ goto out;
+ }
+
+ tmp = upstream_bridge_distance(pciA, pciB, NULL);
+ ret = tmp < 0 ? false : true;
+
+out:
+ pci_dev_put(pciB);
+ pci_dev_put(pciA);
+ return false;
+}
+EXPORT_SYMBOL_GPL(pci_test_p2p);
diff --git a/include/linux/pci-p2pdma.h b/include/linux/pci-p2pdma.h
index bca9bc3e5be7..7671cc499a08 100644
--- a/include/linux/pci-p2pdma.h
+++ b/include/linux/pci-p2pdma.h
@@ -36,6 +36,7 @@ int pci_p2pdma_enable_store(const char *page, struct pci_dev
**p2p_dev,
bool *use_p2pdma);
ssize_t pci_p2pdma_enable_show(char *page, struct pci_dev *p2p_dev,
bool use_p2pdma);
+bool pci_test_p2p(struct device *devA, struct device *devB);
#else /* CONFIG_PCI_P2PDMA */
static inline int pci_p2pdma_add_resource(struct pci_dev *pdev, int bar,
size_t size, u64 offset)
@@ -97,6 +98,11 @@ static inline ssize_t pci_p2pdma_enable_show(char *page,
{
return sprintf(page, "none\n");
}
+
+static inline bool pci_test_p2p(struct device *devA, struct device *devB)
+{
+ return false;
+}
#endif /* CONFIG_PCI_P2PDMA */
--
2.17.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/5] Device peer to peer (p2p) through vma
From: Jérôme Glisse This patchset add support for peer to peer between device in two manner. First for device memory use through HMM in process regular address space (ie inside a regular vma that is not an mmap of device file or special file). Second for special vma ie mmap of a device file, in this case some device driver might want to allow other device to directly access memory use for those special vma (not that the memory might not even be map to CPU in this case). They are many use cases for this they mainly fall into 2 category: [A]-Allow device to directly map and control another device command queue. [B]-Allow device to access another device memory without disrupting the other device computation. Corresponding workloads: [1]-Network device directly access an control a block device command queue so that it can do storage access without involving the CPU. This fall into [A] [2]-Accelerator device doing heavy computation and network device is monitoring progress. Direct accelerator's memory access by the network device avoid the need to use much slower system memory. This fall into [B]. [3]-Accelerator device doing heavy computation and network device is streaming out the result. This avoid the need to first bounce the result through system memory (it saves both system memory and bandwidth). This fall into [B]. [4]-Chaining device computation. For instance a camera device take a picture, stream it to a color correction device that stream it to final memory. This fall into [A and B]. People have more ideas on how to use this than i can list here. The intention of this patchset is to provide the means to achieve those and much more. I have done a testing using nouveau and Mellanox mlx5 where the mlx5 device can directly access GPU memory [1]. I intend to use this inside nouveau and help porting AMD ROCm RDMA to use this [2]. I believe other people have express interest in working on using this with network device and block device. From implementation point of view this just add 2 new call back to vm_operations struct (for special device vma support) and 2 new call back to HMM device memory structure for HMM device memory support. For now it needs IOMMU off with ACS disabled and for both device to be on same PCIE sub-tree (can not cross root complex). However the intention here is different from some other peer to peer work in that we do want to support IOMMU and are fine with going through the root complex in that case. In other words, the bandwidth advantage of avoiding the root complex is of less importance than the programming model for the feature. We do actualy expect that this will be use mostly with IOMMU enabled and thus with having to go through the root bridge. Another difference from other p2p solution is that we do require that the importing device abide to mmu notifier invalidation so that the exporting device can always invalidate a mapping at any point in time. For this reasons we do not need a struct page for the device memory. Also in all the cases the policy and final decision on wether to map or not is solely under the control of the exporting device. Finaly the device memory might not even be map to the CPU and thus we have to go through the exporting device driver to get the physical address at which the memory is accessible. The core change are minimal (adding new call backs to some struct). IOMMU support will need little change too. Most of the code is in driver to implement export policy and BAR space management. Very gross playground with IOMMU support in [3] (top 3 patches). Cheers, Jérôme [1] https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-p2p [2] https://github.com/RadeonOpenCompute/ROCnRDMA [3] https://cgit.freedesktop.org/~glisse/linux/log/?h=wip-hmm-p2p Cc: Logan Gunthorpe Cc: Greg Kroah-Hartman Cc: Rafael J. Wysocki Cc: Bjorn Helgaas Cc: Christian Koenig Cc: Felix Kuehling Cc: Jason Gunthorpe Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: Joerg Roedel Cc: io...@lists.linux-foundation.org Jérôme Glisse (5): pci/p2p: add a function to test peer to peer capability drivers/base: add a function to test peer to peer capability mm/vma: add support for peer to peer to device vma mm/hmm: add support for peer to peer to HMM device memory mm/hmm: add support for peer to peer to special device vma drivers/base/core.c| 20 drivers/pci/p2pdma.c | 27 + include/linux/device.h | 1 + include/linux/hmm.h| 53 + include/linux/mm.h | 38 +++ include/linux/pci-p2pdma.h | 6 + mm/hmm.c | 219 ++--- 7 files changed, 325 insertions(+), 39 deletions(-) -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listi
Re: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
On Tue, Jan 29, 2019 at 05:50:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 24.01.2019 18.57, skrev Daniel Vetter:
> > > On Thu, Jan 24, 2019 at 6:46 PM Greg KH
> > > wrote:
> > >>
> > >> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> > >>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 22.01.2019 20.30, skrev Daniel Vetter:
> > > On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes
> > > wrote:
> > >>
> > >>
> > >>
> > >> Den 22.01.2019 10.32, skrev Daniel Vetter:
> > >>> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 21.01.2019 10.55, skrev Daniel Vetter:
> > > On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter wrote:
> > >> On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes wrote:
> > >>> This adds resource managed (devres) versions of drm_dev_init()
> > >>> and
> > >>> drm_dev_register().
> > >>>
> > >>> Also added is devm_drm_dev_register_with_fbdev() which sets up
> > >>> generic
> > >>> fbdev emulation as well.
> > >>>
> > >>> devm_drm_dev_register() isn't exported since there are no users.
> > >>>
> > >>> Signed-off-by: Noralf Trønnes
> > >>
> >
> >
> >
> > >>> diff --git a/drivers/gpu/drm/drm_drv.c
> > >>> b/drivers/gpu/drm/drm_drv.c
> > >>> index 381581b01d48..12129772be45 100644
> > >>> --- a/drivers/gpu/drm/drm_drv.c
> > >>> +++ b/drivers/gpu/drm/drm_drv.c
> > >>> @@ -36,6 +36,7 @@
> > >>>
> > >>> #include
> > >>> #include
> > >>> +#include
> > >>> #include
> > >>>
> > >>> #include "drm_crtc_internal.h"
> > >>> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct drm_device
> > >>> *dev)
> > >>> }
> > >>> EXPORT_SYMBOL(drm_dev_unregister);
> > >>>
> > >>> +static void devm_drm_dev_init_release(void *data)
> > >>> +{
> > >>> + drm_dev_put(data);
> > >
> > > We need drm_dev_unplug() here, or this isn't safe.
> >
> > This function is only used to cover the error path if probe fails
> > before
> > devm_drm_dev_register() is called. devm_drm_dev_register_release()
> > is
> > the one that calls unplug. There are comments about this in the
> > functions.
> > >>>
> > >>> I think I get a prize for being ignorant and blind :-/
> > >>>
> >
> > >
> > >>> +}
> > >>> +
> > >>> +/**
> > >>> + * devm_drm_dev_init - Resource managed drm_dev_init()
> > >>> + * @parent: Parent device object
> > >>> + * @dev: DRM device
> > >>> + * @driver: DRM driver
> > >>> + *
> > >>> + * Managed drm_dev_init(). The DRM device initialized with
> > >>> this function is
> > >>> + * automatically released on driver detach. You must supply a
> > >
> > > I think a bit more clarity here would be good:
> > >
> > > "... automatically released on driver unbind by callind
> > > drm_dev_unplug()."
> > >
> > >>> + * &drm_driver.release callback to control the finalization
> > >>> explicitly.
> > >
> > > I think a loud warning for these is in order:
> > >
> > > "WARNING:
> > >
> > > "In generally it is unsafe to use devm functions for drm
> > > structures
> > > because the lifetimes of &drm_device and the underlying &device
> > > do not
> > > match. This here works because it doesn't immediately free
> > > anything, but
> > > only calls drm_dev_unplug(), which internally decrements the
> > > &drm_device
> > > refcount through drm_dev_put().
> > >
> > > "All other drm structures must still be explicitly released in the
> > > &drm_driver.release callback."
> > >
> > > While thinking about this I just realized that with this design
> > > we have no
> > > good place to call drm_atomic_helper_shutdown(). Which we need
> > > to, or all
> > > kinds of things will leak badly (connectors, fb, ...), but
> > > there's no
> > > place to call it:
> > > - unbind is too early, since we haven't yet called
> > > drm_dev_unplug, and the
> > > drm_dev_unregister in there must be called _before_ we start to
> > > shut
> > > down anything.
> > > - drm_driver.release is way too late.
> > >
> > > Ofc for a real hotunplug there's no point in shutting down the hw
> > > (it's
>
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard wrote: > > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote: > > On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard > > wrote: > > > > > > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote: > > > > Minimum PLL used for MIPI is 500MHz, as per manual, but > > > > lowering the min rate by 300MHz can result proper working > > > > nkms divider with the help of desired dclock rate from > > > > panel driver. > > > > > > > > Signed-off-by: Jagan Teki > > > > Acked-by: Stephen Boyd > > > > > > Going 200MHz below the minimum doesn't seem really reasonable. What > > > is the issue that you are trying to fix here? > > > > > > It looks like it's picking bad dividers, but if that's the case, this > > > isn't the proper fix. > > > > As I stated in earlier patches, the whole idea is pick the desired > > dclk divider based dclk rate. So the dotclock, sun4i_dclk_round_rate > > is unable to get the proper dclk divider at the end, so it eventually > > picking up wrong divider value and fired vblank timeout. > > > > So, we come-up with optimal and working min_rate 300MHz in pll-mipi to > > get the desired clock something like below. > > [2.415773] [drm] No driver support for vblank timestamp query. > > [2.424116] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = > > 5500 > > [2.424172] ideal = 22000, rounded = 0 > > [2.424176] ideal = 27500, rounded = 0 > > [2.424194] ccu_nkm_round_rate: rate = 33000 > > [2.424197] ideal = 33000, rounded = 33000 > > [2.424201] sun4i_dclk_round_rate: div = 6 rate = 5500 > > [2.424205] sun4i_dclk_round_rate: min_div = 4 max_div = 127, rate = > > 5500 > > [2.424209] ideal = 22000, rounded = 0 > > [2.424213] ideal = 27500, rounded = 0 > > [2.424230] ccu_nkm_round_rate: rate = 33000 > > [2.424233] ideal = 33000, rounded = 33000 > > [2.424236] sun4i_dclk_round_rate: div = 6 rate = 5500 > > [2.424253] ccu_nkm_round_rate: rate = 33000 > > [2.424270] ccu_nkm_round_rate: rate = 33000 > > [2.424278] sun4i_dclk_recalc_rate: val = 1, rate = 33000 > > [2.424281] sun4i_dclk_recalc_rate: val = 1, rate = 33000 > > [2.424306] ccu_nkm_set_rate: rate = 33000, parent_rate = 29700 > > [2.424309] ccu_nkm_set_rate: _nkm.n = 5 > > [2.424311] ccu_nkm_set_rate: _nkm.k = 2 > > [2.424313] ccu_nkm_set_rate: _nkm.m = 9 > > [2.424661] sun4i_dclk_set_rate div 6 > > [2.424668] sun4i_dclk_recalc_rate: val = 6, rate = 5500 > > > > But look like this wouldn't valid for all other dclock rates, say BPI > > panel has 30MHz clock that would failed with this logic. > > > > On the other side Allwinner BSP calculating dclk divider based on the > > SoC's. for A33 [1] it is fixed dclk divider of 4 and for A64 is is > > calculated based on the bpp/lanes. > > It looks like the A64 has the same divider of 4: > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c#L12 > > I think you're confusing it with the ratio between the pixel clock and > the dotclock, called dsi_div: > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L198 Ahh.. I thought this initially but as far as DSI clock computation is concern, the L12 tcon_div is local variable which is used for edge0 computation in burst mode and not for the dsi clock computation. Since the BSP is unable to get the tcon_div during edge0 computation, they defined it locally I think. You can see the lcd_clk_config() code [2], where we can see DSI clock computation using dsi_div value. Here is dump after the in Line 792 which is after computation[3] [ 10.800737] lcd_clk_config: dsi_div = 6, tcon_div = 4, lcd_div = 1 [ 10.800743] lcd_clk_config: lcd_dclk_freq = 55, dclk_rate = 5500 [ 10.800749] lcd_clk_config: lcd_rate = 33000, pll_rate = 33000 The above dump the lcd_rate 330MHz is computed with panel clock, 55MHz into dsi_div 6. So this can be our actual divider values dclk_min_div, dclk_max_div in sun4i_dclk_round_rate (from drivers/gpu/drm/sun4i/sun4i_dotclock.c) We can even confirm this from Mainline code: [1.866128] sun4i_dclk_round_rate: min_div = 6 max_div = 6, rate = 5500 [1.873112] round_rate, parent = 33000 [1.877351] round_rate, rate = 33000 [1.881338] ideal = 33000, rounded = 33000, div = 6 [1.887232] sun4i_dclk_round_rate: div = 6 rate = 5500 [1.887239] sun4i_dclk_round_rate: min_div = 6 max_div = 6, rate = 5500 [1.887243] round_rate, parent = 33000 [1.887259] round_rate, rate = 33000 [1.887264] ideal = 33000, rounded = 33000, div = 6 [1.887267] sun4i_dclk_round_rate: div = 6 rate = 5500 [1.887270] round_rate, parent = 33000 [1.887286] round_rate, rate = 33000 [
Re: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
Den 29.01.2019 17.50, skrev Daniel Vetter:
> On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 24.01.2019 18.57, skrev Daniel Vetter:
>>> On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 22.01.2019 20.30, skrev Daniel Vetter:
>>> On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes
>>> wrote:
Den 22.01.2019 10.32, skrev Daniel Vetter:
> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 21.01.2019 10.55, skrev Daniel Vetter:
>>> On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter wrote:
On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes wrote:
> This adds resource managed (devres) versions of drm_dev_init() and
> drm_dev_register().
>
> Also added is devm_drm_dev_register_with_fbdev() which sets up
> generic
> fbdev emulation as well.
>
> devm_drm_dev_register() isn't exported since there are no users.
>
> Signed-off-by: Noralf Trønnes
>>
>>
>>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 381581b01d48..12129772be45 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -36,6 +36,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct drm_device
> *dev)
> }
> EXPORT_SYMBOL(drm_dev_unregister);
>
> +static void devm_drm_dev_init_release(void *data)
> +{
> + drm_dev_put(data);
>>>
>>> We need drm_dev_unplug() here, or this isn't safe.
>>
>> This function is only used to cover the error path if probe fails
>> before
>> devm_drm_dev_register() is called. devm_drm_dev_register_release() is
>> the one that calls unplug. There are comments about this in the
>> functions.
>
> I think I get a prize for being ignorant and blind :-/
>
>>
>>>
> +}
> +
> +/**
> + * devm_drm_dev_init - Resource managed drm_dev_init()
> + * @parent: Parent device object
> + * @dev: DRM device
> + * @driver: DRM driver
> + *
> + * Managed drm_dev_init(). The DRM device initialized with this
> function is
> + * automatically released on driver detach. You must supply a
>>>
>>> I think a bit more clarity here would be good:
>>>
>>> "... automatically released on driver unbind by callind
>>> drm_dev_unplug()."
>>>
> + * &drm_driver.release callback to control the finalization
> explicitly.
>>>
>>> I think a loud warning for these is in order:
>>>
>>> "WARNING:
>>>
>>> "In generally it is unsafe to use devm functions for drm structures
>>> because the lifetimes of &drm_device and the underlying &device do
>>> not
>>> match. This here works because it doesn't immediately free
>>> anything, but
>>> only calls drm_dev_unplug(), which internally decrements the
>>> &drm_device
>>> refcount through drm_dev_put().
>>>
>>> "All other drm structures must still be explicitly released in the
>>> &drm_driver.release callback."
>>>
>>> While thinking about this I just realized that with this design we
>>> have no
>>> good place to call drm_atomic_helper_shutdown(). Which we need to,
>>> or all
>>> kinds of things will leak badly (connectors, fb, ...), but there's
>>> no
>>> place to call it:
>>> - unbind is too early, since we haven't yet called drm_dev_unplug,
>>> and the
>>> drm_dev_unregister in there must be called _before_ we start to
>>> shut
>>> down anything.
>>> - drm_driver.release is way too late.
>>>
>>> Ofc for a real hotunplug there's no point in shutting down the hw
>>> (it's
>>> already gone), but for a driver unload/unbind it would be nice if
>>> this
>>> happens automatically and in the right order.
>>>
>>> So not sure what to do here really.
>>
>> How about this change: (it breaks the rule of pulling helpers into
>> the
>> c
Re: [PATCH v2] drm/TODO: Add vrefresh replacement to the todo
On Tue, Jan 29, 2019 at 11:45:10AM -0500, Sean Paul wrote: > From: Sean Paul > > Changes in v2: > - Add drm_display_mode.vrefresh removal (Ville) > - Add Sam's R-b and bonus points hsync has the same problem, maybe add that too. With that: Reviewed-by: Daniel Vetter > Cc: Ville Syrjälä > Suggested-by: Daniel Vetter > Reviewed-by: Sam Ravnborg > Bonus-points-awarded-by: Sam Ravnborg > Signed-off-by: Sean Paul > --- > Documentation/gpu/todo.rst | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 38360ede12215..1bbfc5e1b2a46 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -262,6 +262,24 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > > +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() > + > + > +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it > +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core > +has helper which will use mode.vrefresh if it's !0 and will calculate it from > +the timings when it's 0. > + > +Use simple search/replace, or (more fun) cocci to replace instances of direct > +vrefresh access with a call to the helper. Check out > +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for > +inspiration. > + > +Once all instances of vrefresh have been converted, consider removing > vrefresh > +from drm_display_mode to avoid future use. > + > +Contact: Sean Paul > + > Core refactorings > = > > -- > Sean Paul, Software Engineer, Google / Chromium OS > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109498] Game enabling VBO Core but disabling VAO Core causing reproducible, predictable, spontaneous powerdown
https://bugs.freedesktop.org/show_bug.cgi?id=109498 --- Comment #3 from Adam Wenocur --- Created attachment 143250 --> https://bugs.freedesktop.org/attachment.cgi?id=143250&action=edit XOrg log -- 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 109498] Game enabling VBO Core but disabling VAO Core causing reproducible, predictable, spontaneous powerdown
https://bugs.freedesktop.org/show_bug.cgi?id=109498 --- Comment #2 from Adam Wenocur --- Created attachment 143249 --> https://bugs.freedesktop.org/attachment.cgi?id=143249&action=edit dmesg 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
[PATCH] drm: Constify drm_color_lut_check()
From: Ville Syrjälä
drm_color_lut_check() doens't modify the passed in blob so
let's make it const.
Also s/uint32_y/u32/ while at it.
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_color_mgmt.c | 6 +++---
include/drm/drm_color_mgmt.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 968ca7c91ad8..3c8826a91a03 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -474,10 +474,10 @@ EXPORT_SYMBOL(drm_plane_create_color_properties);
*
* Returns 0 on success, -EINVAL on failure.
*/
-int drm_color_lut_check(struct drm_property_blob *lut,
- uint32_t tests)
+int drm_color_lut_check(const struct drm_property_blob *lut,
+ u32 tests)
{
- struct drm_color_lut *entry;
+ const struct drm_color_lut *entry;
int i;
if (!lut || !tests)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 6affbda6d9cb..58d4b20b5b97 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -96,6 +96,6 @@ enum drm_color_lut_tests {
DRM_COLOR_LUT_NON_DECREASING = BIT(1),
};
-int drm_color_lut_check(struct drm_property_blob *lut,
- uint32_t tests);
+int drm_color_lut_check(const struct drm_property_blob *lut,
+ u32 tests);
#endif
--
2.19.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109498] Game enabling VBO Core but disabling VAO Core causing reproducible, predictable, spontaneous powerdown
https://bugs.freedesktop.org/show_bug.cgi?id=109498 --- Comment #1 from Alex Deucher --- Please attach your dmesg output and xorg log (if using X). -- 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 v1 1/1] drm: drop drm_bus from todo
On Tue, Jan 29, 2019 at 03:18:00PM +0100, Sam Ravnborg wrote: > Hi Daniel. > > > > > Sam, want drm-misc commit rights to start merging your own stuff? Assuming > > you plan to stick around ofc ... I'll also ask the drm-misc maintainers > > whether that's ok. > > The plan is to re-submit the Atmel LCDC DRM driver when I find enough time > to finish it. All coding is done and it builds, I 'only' need to make it work. > > When I submit the driver the plan is to share the maintainer role for > both Atmel based DRM drivers (hlcdc + lcdc). > So it would make sense to gain drm-misc commit rights at least then. > > Last time I looked at it I was stucked in the keys required and the tools > I needed to learn. This was not really where I had energy to spend the effort. Can I motivate you some more? I'm happy to ramp up people for a bit, but I can't do patch review&applying for everyone. Wouldn't scale. Expect me to become increasingly annoying about this :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109498] Game enabling VBO Core but disabling VAO Core causing reproducible, predictable, spontaneous powerdown
https://bugs.freedesktop.org/show_bug.cgi?id=109498 Bug ID: 109498 Summary: Game enabling VBO Core but disabling VAO Core causing reproducible, predictable, spontaneous powerdown Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: aweno...@gmail.com The game "openAstroMenace", for some reason defaults to using VBO Core in the absence of VAO core, which predictably causes the game to crash on a modern OpenGL implementation. The game itself crashing is not a problem; it's the PSU switching off that's very concerning. I'm running an ASRock E3V5 WS motherboard with a 4 GB Sapphire R9 Fury X, and an E3-1235L CPU. I'm early on in diagnosing it so I don't have a stack trace, but I think I've ruled out hardware problems, as this system doesn't break a sweat maxing out the Heaven benchmark or the Phoronix JuliaGPU (via ROCm) benchmark, and plays every other game flawlessly. It can run with all CPU cores at 100% for hours on end. openAstroMenace runs flawlessly with max settings when VAO Core is enabled. Mesa may be malfunctioning here, but a userspace library wouldn't affect PSU behavior. This is pointing me in the direction of suspecting AMDGPU to be the culprit. It exhibits this behavior on both my Ubuntu and Gentoo installations, and on 4.15 and 4.18 series kernels. The system poweroff is predictable down to less than half a second, and is triggered exactly the same way at exactly the same time in every instance. It occurs around 3/4 of a second after the game's menu appears. -- 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: devm actions and hw clenaup (was Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register)
On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.01.2019 18.57, skrev Daniel Vetter:
> > On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
> >>
> >> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> >>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
>
>
> Den 22.01.2019 20.30, skrev Daniel Vetter:
> > On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes
> > wrote:
> >>
> >>
> >>
> >> Den 22.01.2019 10.32, skrev Daniel Vetter:
> >>> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
>
>
> Den 21.01.2019 10.55, skrev Daniel Vetter:
> > On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter wrote:
> >> On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes wrote:
> >>> This adds resource managed (devres) versions of drm_dev_init() and
> >>> drm_dev_register().
> >>>
> >>> Also added is devm_drm_dev_register_with_fbdev() which sets up
> >>> generic
> >>> fbdev emulation as well.
> >>>
> >>> devm_drm_dev_register() isn't exported since there are no users.
> >>>
> >>> Signed-off-by: Noralf Trønnes
> >>
>
>
>
> >>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >>> index 381581b01d48..12129772be45 100644
> >>> --- a/drivers/gpu/drm/drm_drv.c
> >>> +++ b/drivers/gpu/drm/drm_drv.c
> >>> @@ -36,6 +36,7 @@
> >>>
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>>
> >>> #include "drm_crtc_internal.h"
> >>> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct drm_device
> >>> *dev)
> >>> }
> >>> EXPORT_SYMBOL(drm_dev_unregister);
> >>>
> >>> +static void devm_drm_dev_init_release(void *data)
> >>> +{
> >>> + drm_dev_put(data);
> >
> > We need drm_dev_unplug() here, or this isn't safe.
>
> This function is only used to cover the error path if probe fails
> before
> devm_drm_dev_register() is called. devm_drm_dev_register_release() is
> the one that calls unplug. There are comments about this in the
> functions.
> >>>
> >>> I think I get a prize for being ignorant and blind :-/
> >>>
>
> >
> >>> +}
> >>> +
> >>> +/**
> >>> + * devm_drm_dev_init - Resource managed drm_dev_init()
> >>> + * @parent: Parent device object
> >>> + * @dev: DRM device
> >>> + * @driver: DRM driver
> >>> + *
> >>> + * Managed drm_dev_init(). The DRM device initialized with this
> >>> function is
> >>> + * automatically released on driver detach. You must supply a
> >
> > I think a bit more clarity here would be good:
> >
> > "... automatically released on driver unbind by callind
> > drm_dev_unplug()."
> >
> >>> + * &drm_driver.release callback to control the finalization
> >>> explicitly.
> >
> > I think a loud warning for these is in order:
> >
> > "WARNING:
> >
> > "In generally it is unsafe to use devm functions for drm structures
> > because the lifetimes of &drm_device and the underlying &device do
> > not
> > match. This here works because it doesn't immediately free
> > anything, but
> > only calls drm_dev_unplug(), which internally decrements the
> > &drm_device
> > refcount through drm_dev_put().
> >
> > "All other drm structures must still be explicitly released in the
> > &drm_driver.release callback."
> >
> > While thinking about this I just realized that with this design we
> > have no
> > good place to call drm_atomic_helper_shutdown(). Which we need to,
> > or all
> > kinds of things will leak badly (connectors, fb, ...), but there's
> > no
> > place to call it:
> > - unbind is too early, since we haven't yet called drm_dev_unplug,
> > and the
> > drm_dev_unregister in there must be called _before_ we start to
> > shut
> > down anything.
> > - drm_driver.release is way too late.
> >
> > Ofc for a real hotunplug there's no point in shutting down the hw
> > (it's
> > already gone), but for a driver unload/unbind it would be nice if
> > this
> > happens automatically and in the right order.
> >
> > So not sure what to do here really.
>
> How about this change: (it breaks the rule of pulling helpers into
> the
> core, so maybe we should put the devm_ functions
[Bug 108889] [CI][SHARDS] igt@sw_sync@sync_busy_fork_unixsocket - incomplete - __igt_fork_helper: Assertion `!proc->running' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=108889
--- Comment #5 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- HSW SKL ICL: igt@sw_sync@sync_busy_fork* - incomplete - __igt_fork_helper:
Assertion `!proc->running' failed. -}
{+ HSW SKL KBL ICL: igt@sw_sync@sync_busy_fork* - incomplete -
__igt_fork_helper: Assertion `!proc->running' failed. +}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_191/fi-kbl-r/igt@sw_sync@sync_busy_fork.html
--
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: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, January 29, 2019 10:09 PM
>To: Shankar, Uma
>Cc: Syrjala, Ville ; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Lankhorst, Maarten
>
>Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>
>On Tue, Jan 29, 2019 at 04:20:39PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Tuesday, January 29, 2019 9:34 PM
>> >To: Shankar, Uma
>> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org;
>> >Syrjala, Ville ; Lankhorst, Maarten
>> >; dri-devel@lists.freedesktop.org
>> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable
>> >modeset
>> >
>> >On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
>> >>
>> >>
>> >> >-Original Message-
>> >> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org]
>> >> >On Behalf Of Ville Syrjälä
>> >> >Sent: Tuesday, January 29, 2019 9:14 PM
>> >> >To: Shankar, Uma
>> >> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org;
>> >> >Syrjala, Ville ; Lankhorst, Maarten
>> >> >; dri-devel@lists.freedesktop.org
>> >> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and
>> >> >enable modeset
>> >> >
>> >> >On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
>> >> >> This patch attaches the colorspace connector property to the
>> >> >> hdmi connector. Based on colorspace change, modeset will be
>> >> >> triggered to switch to new colorspace.
>> >> >>
>> >> >> Based on colorspace property value create an infoframe with
>> >> >> appropriate colorspace. This can be used to send an infoframe
>> >> >> packet with proper colorspace value set which will help to
>> >> >> enable wider color gamut like BT2020 on sink.
>> >> >>
>> >> >> This patch attaches and enables HDMI colorspace, DP will be
>> >> >> taken care separately.
>> >> >>
>> >> >> v2: Merged the changes of creating infoframe as well to this
>> >> >> patch as per Maarten's suggestion.
>> >> >>
>> >> >> v3: Addressed review comments from Shashank. Separated HDMI and
>> >> >> DP colorspaces as suggested by Ville and Maarten.
>> >> >>
>> >> >> v4: Addressed Chris and Ville's review comments, and created a
>> >> >> common colorspace property for DP and HDMI, filtered the list
>> >> >> based on the colorspaces supported by the respective protocol standard.
>> >> >> Handle the default case properly.
>> >> >>
>> >> >> v5: Added Platform specific colorspace enums and called the
>> >> >> property creation helper using the same.
>> >> >>
>> >> >> v6: Addressed Shashank's review comments.
>> >> >>
>> >> >> v7: Rebase
>> >> >>
>> >> >> v8: Addressed Maarten's review comments.
>> >> >>
>> >> >> Signed-off-by: Uma Shankar
>> >> >> Reviewed-by: Shashank Sharma
>> >> >> ---
>> >> >> drivers/gpu/drm/i915/intel_atomic.c| 1 +
>> >> >> drivers/gpu/drm/i915/intel_connector.c | 63
>> >> >++
>> >> >> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> >> >> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
>> >> >> 4 files changed, 89 insertions(+)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> >> >> b/drivers/gpu/drm/i915/intel_atomic.c
>> >> >> index 16263ad..76b7114 100644
>> >> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> >> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> >> >> @@ -124,6 +124,7 @@ int
>> >> >> intel_digital_connector_atomic_check(struct
>> >> >drm_connector *conn,
>> >> >> */
>> >> >>if (new_conn_state->force_audio != old_conn_state-
>>force_audio ||
>> >> >>new_conn_state->broadcast_rgb !=
>> >> >> old_conn_state->broadcast_rgb
>> >> >> ||
>> >> >> + new_state->colorspace != old_state->colorspace ||
>> >> >>new_conn_state->base.picture_aspect_ratio !=
>> >> >>old_conn_state- base.picture_aspect_ratio ||
>> >> >>new_conn_state->base.content_type != old_conn_state-
>> >> >>base.content_type ||
>> >> >>new_conn_state->base.scaling_mode !=
>> >> >> old_conn_state->base.scaling_mode)
>> >> >> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> >> >> b/drivers/gpu/drm/i915/intel_connector.c
>> >> >> index ee16758..9a12d5e 100644
>> >> >> --- a/drivers/gpu/drm/i915/intel_connector.c
>> >> >> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> >> >> @@ -30,6 +30,48 @@
>> >> >> #include "intel_drv.h"
>> >> >> #include "i915_drv.h"
>> >> >>
>> >> >> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
>> >> >> + /* For Default case, driver will set the colorspace */
>> >> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> >> >> + /* Standard Definition Colorimetry based on CEA 861 */
>> >> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> >> >> + { DRM_MODE_COLORIMETRY_ITU_709,
Re: [PATCH] dt-bindings: display: add binding for Innolux ee101ia-01d panel
On Tue, Jan 29, 2019 at 02:37:23PM +0100, Heiko Stübner wrote: > Hi Thierry, > > Am Dienstag, 13. November 2018, 13:42:05 CET schrieb Heiko Stuebner: > > From: Heiko Stuebner > > > > This is a panel handled through the generic lvds-panel binding, > > so only needs its additional compatible specified. > > > > Signed-off-by: Heiko Stuebner > > just pulling this pending patch out of the woodworks again too :-) > > Thanks in advance for considering it. It's a panel patch, you have the review from Rob, you have commit rights to drm-misc and panel is maintained in drm-misc. There's nothing blocking you from pushing it, just do it :-) Cheers, Daniel > Heiko > > > --- > > .../bindings/display/panel/innolux,ee101ia-01d.txt | 7 +++ > > 1 file changed, 7 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > new file mode 100644 > > index ..e5ca4ccd55ed > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.txt > > @@ -0,0 +1,7 @@ > > +Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel > > + > > +Required properties: > > +- compatible: should be "innolux,ee101ia-01d" > > + > > +This binding is compatible with the lvds-panel binding, which is specified > > +in panel-lvds.txt in this directory. > > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/TODO: Add vrefresh replacement to the todo
From: Sean Paul Changes in v2: - Add drm_display_mode.vrefresh removal (Ville) - Add Sam's R-b and bonus points Cc: Ville Syrjälä Suggested-by: Daniel Vetter Reviewed-by: Sam Ravnborg Bonus-points-awarded-by: Sam Ravnborg Signed-off-by: Sean Paul --- Documentation/gpu/todo.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 38360ede12215..1bbfc5e1b2a46 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -262,6 +262,24 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() + + +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core +has helper which will use mode.vrefresh if it's !0 and will calculate it from +the timings when it's 0. + +Use simple search/replace, or (more fun) cocci to replace instances of direct +vrefresh access with a call to the helper. Check out +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for +inspiration. + +Once all instances of vrefresh have been converted, consider removing vrefresh +from drm_display_mode to avoid future use. + +Contact: Sean Paul + Core refactorings = -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: add definitions for DP Audio/Video compliance tests
On Tue, Jan 29, 2019 at 10:55:47AM -0500, Sean Paul wrote: > On Mon, Jan 28, 2019 at 02:58:53PM -0800, Chandan Uddaraju wrote: > > This change adds definitions needed for DP audio compliance testing. > > It also adds missing definition for DP video compliance. > > > > Changes in V2: > > -- Delete cover letter for this patch. > > -- Move the description from cover letter into patch commit message. > > -- Remove DPU from subject prefix > > > > Signed-off-by: Chandan Uddaraju > > Reviewed-by: Sean Paul > > If no one has any objections, it'd be nice to apply this through msm tree > along > with the dpu code that makes use of it. Acked-by: Daniel Vetter for merging through -msm. -Daniel > > Sean > > > > --- > > include/drm/drm_dp_helper.h | 13 + > > 1 file changed, 13 insertions(+) > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > index 5736c94..e688e05 100644 > > --- a/include/drm/drm_dp_helper.h > > +++ b/include/drm/drm_dp_helper.h > > @@ -556,6 +556,8 @@ > > # define DP_TEST_LINK_EDID_READ(1 << 2) > > # define DP_TEST_LINK_PHY_TEST_PATTERN (1 << 3) /* DPCD >= 1.1 */ > > # define DP_TEST_LINK_FAUX_PATTERN (1 << 4) /* DPCD >= 1.2 */ > > +# define DP_TEST_LINK_AUDIO_PATTERN (1 << 5) /* DPCD >= 1.2 */ > > +# define DP_TEST_LINK_AUDIO_DISABLED_VIDEO (1 << 6) /* DPCD >= 1.2 */ > > > > #define DP_TEST_LINK_RATE 0x219 > > # define DP_LINK_RATE_162 (0x6) > > @@ -604,6 +606,7 @@ > > # define DP_COLOR_FORMAT_RGB(0 << 1) > > # define DP_COLOR_FORMAT_YCbCr422 (1 << 1) > > # define DP_COLOR_FORMAT_YCbCr444 (2 << 1) > > +# define DP_TEST_DYNAMIC_RANGE_VESA (0 << 3) > > # define DP_TEST_DYNAMIC_RANGE_CEA (1 << 3) > > # define DP_TEST_YCBCR_COEFFICIENTS (1 << 4) > > # define DP_YCBCR_COEFFICIENTS_ITU601 (0 << 4) > > @@ -653,6 +656,16 @@ > > > > #define DP_TEST_SINK 0x270 > > # define DP_TEST_SINK_START(1 << 0) > > +#define DP_TEST_AUDIO_MODE 0x271 > > +#define DP_TEST_AUDIO_PATTERN_TYPE 0x272 > > +#define DP_TEST_AUDIO_PERIOD_CH1 0x273 > > +#define DP_TEST_AUDIO_PERIOD_CH2 0x274 > > +#define DP_TEST_AUDIO_PERIOD_CH3 0x275 > > +#define DP_TEST_AUDIO_PERIOD_CH4 0x276 > > +#define DP_TEST_AUDIO_PERIOD_CH5 0x277 > > +#define DP_TEST_AUDIO_PERIOD_CH6 0x278 > > +#define DP_TEST_AUDIO_PERIOD_CH7 0x279 > > +#define DP_TEST_AUDIO_PERIOD_CH8 0x27A > > > > #define DP_FEC_STATUS 0x280/* 1.4 */ > > # define DP_FEC_DECODE_EN_DETECTED (1 << 0) > > -- > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > > a Linux Foundation Collaborative Project > > > > -- > Sean Paul, Software Engineer, Google / Chromium OS > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
On Tue, Jan 29, 2019 at 04:20:39PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 9:34 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
> >; Lankhorst, Maarten ;
> >dri-devel@lists.freedesktop.org
> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
> >
> >On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
> >>
> >>
> >> >-Original Message-
> >> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> >Behalf Of Ville Syrjälä
> >> >Sent: Tuesday, January 29, 2019 9:14 PM
> >> >To: Shankar, Uma
> >> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org;
> >> >Syrjala, Ville ; Lankhorst, Maarten
> >> >; dri-devel@lists.freedesktop.org
> >> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable
> >> >modeset
> >> >
> >> >On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
> >> >> This patch attaches the colorspace connector property to the hdmi
> >> >> connector. Based on colorspace change, modeset will be triggered to
> >> >> switch to new colorspace.
> >> >>
> >> >> Based on colorspace property value create an infoframe with
> >> >> appropriate colorspace. This can be used to send an infoframe
> >> >> packet with proper colorspace value set which will help to enable
> >> >> wider color gamut like BT2020 on sink.
> >> >>
> >> >> This patch attaches and enables HDMI colorspace, DP will be taken
> >> >> care separately.
> >> >>
> >> >> v2: Merged the changes of creating infoframe as well to this patch
> >> >> as per Maarten's suggestion.
> >> >>
> >> >> v3: Addressed review comments from Shashank. Separated HDMI and DP
> >> >> colorspaces as suggested by Ville and Maarten.
> >> >>
> >> >> v4: Addressed Chris and Ville's review comments, and created a
> >> >> common colorspace property for DP and HDMI, filtered the list based
> >> >> on the colorspaces supported by the respective protocol standard.
> >> >> Handle the default case properly.
> >> >>
> >> >> v5: Added Platform specific colorspace enums and called the
> >> >> property creation helper using the same.
> >> >>
> >> >> v6: Addressed Shashank's review comments.
> >> >>
> >> >> v7: Rebase
> >> >>
> >> >> v8: Addressed Maarten's review comments.
> >> >>
> >> >> Signed-off-by: Uma Shankar
> >> >> Reviewed-by: Shashank Sharma
> >> >> ---
> >> >> drivers/gpu/drm/i915/intel_atomic.c| 1 +
> >> >> drivers/gpu/drm/i915/intel_connector.c | 63
> >> >++
> >> >> drivers/gpu/drm/i915/intel_drv.h | 1 +
> >> >> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
> >> >> 4 files changed, 89 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> >> index 16263ad..76b7114 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> >> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
> >> >drm_connector *conn,
> >> >> */
> >> >> if (new_conn_state->force_audio != old_conn_state->force_audio
> >> >> ||
> >> >> new_conn_state->broadcast_rgb !=
> >> >> old_conn_state->broadcast_rgb
> >> >> ||
> >> >> + new_state->colorspace != old_state->colorspace ||
> >> >> new_conn_state->base.picture_aspect_ratio != old_conn_state-
> >> >>base.picture_aspect_ratio ||
> >> >> new_conn_state->base.content_type != old_conn_state-
> >> >>base.content_type ||
> >> >> new_conn_state->base.scaling_mode !=
> >> >> old_conn_state->base.scaling_mode)
> >> >> diff --git a/drivers/gpu/drm/i915/intel_connector.c
> >> >> b/drivers/gpu/drm/i915/intel_connector.c
> >> >> index ee16758..9a12d5e 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_connector.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_connector.c
> >> >> @@ -30,6 +30,48 @@
> >> >> #include "intel_drv.h"
> >> >> #include "i915_drv.h"
> >> >>
> >> >> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
> >> >> + /* For Default case, driver will set the colorspace */
> >> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> >> >> + /* Standard Definition Colorimetry based on CEA 861 */
> >> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> >> >> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> >> >> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> >> >> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> >> >> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> >> >> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> >> >> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> >> >> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> >> >> + /* Colorimetry based on IEC 61966-2-5 [33] */
> >
Re: [PATCH] drm/TODO: Add vrefresh replacement to the todo
On Tue, Jan 29, 2019 at 11:15:51AM -0500, Sean Paul wrote: > From: Sean Paul > > Suggested-by: Daniel Vetter > Signed-off-by: Sean Paul > --- > Documentation/gpu/todo.rst | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 38360ede12215..7fc30380eaf6c 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -262,6 +262,21 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > > +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() > + > + > +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it > +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core > +has helper which will use mode.vrefresh if it's !0 and will calculate it from > +the timings when it's 0. > + > +Use simple search/replace, or (more fun) cocci to replace instances of direct > +vrefresh access with a call to the helper. Check out > +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for > +inspiration. I would suggest just nuking mode.vrefresh entirely because we don't want to risk drm_mode_vrefresh() returning some stale value. > + > +Contact: Sean Paul > + > Core refactorings > = > > -- > Sean Paul, Software Engineer, Google / Chromium OS > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109487] drm-next-5.1-wip broken as of 672c6238
https://bugs.freedesktop.org/show_bug.cgi?id=109487 --- Comment #6 from asavah --- Yes, indeed reverting https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.1-wip&id=10117450735c7a7c0858095fb46a860e7037cb9a seems to fix the issue. -- 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/TODO: Add vrefresh replacement to the todo
On Tue, Jan 29, 2019 at 11:15:51AM -0500, Sean Paul wrote: > From: Sean Paul > > Suggested-by: Daniel Vetter > Signed-off-by: Sean Paul Reviewed-by: Sam Ravnborg > --- > Documentation/gpu/todo.rst | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 38360ede12215..7fc30380eaf6c 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -262,6 +262,21 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > > +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() > + > + > +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it > +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core > +has helper which will use mode.vrefresh if it's !0 and will calculate it from > +the timings when it's 0. > + > +Use simple search/replace, or (more fun) cocci to replace instances of direct > +vrefresh access with a call to the helper. Check out > +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for > +inspiration. Bonus points for the link! Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 9:34 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@lists.freedesktop.org
>Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>
>On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>> >Behalf Of Ville Syrjälä
>> >Sent: Tuesday, January 29, 2019 9:14 PM
>> >To: Shankar, Uma
>> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org;
>> >Syrjala, Ville ; Lankhorst, Maarten
>> >; dri-devel@lists.freedesktop.org
>> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable
>> >modeset
>> >
>> >On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
>> >> This patch attaches the colorspace connector property to the hdmi
>> >> connector. Based on colorspace change, modeset will be triggered to
>> >> switch to new colorspace.
>> >>
>> >> Based on colorspace property value create an infoframe with
>> >> appropriate colorspace. This can be used to send an infoframe
>> >> packet with proper colorspace value set which will help to enable
>> >> wider color gamut like BT2020 on sink.
>> >>
>> >> This patch attaches and enables HDMI colorspace, DP will be taken
>> >> care separately.
>> >>
>> >> v2: Merged the changes of creating infoframe as well to this patch
>> >> as per Maarten's suggestion.
>> >>
>> >> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> >> colorspaces as suggested by Ville and Maarten.
>> >>
>> >> v4: Addressed Chris and Ville's review comments, and created a
>> >> common colorspace property for DP and HDMI, filtered the list based
>> >> on the colorspaces supported by the respective protocol standard.
>> >> Handle the default case properly.
>> >>
>> >> v5: Added Platform specific colorspace enums and called the
>> >> property creation helper using the same.
>> >>
>> >> v6: Addressed Shashank's review comments.
>> >>
>> >> v7: Rebase
>> >>
>> >> v8: Addressed Maarten's review comments.
>> >>
>> >> Signed-off-by: Uma Shankar
>> >> Reviewed-by: Shashank Sharma
>> >> ---
>> >> drivers/gpu/drm/i915/intel_atomic.c| 1 +
>> >> drivers/gpu/drm/i915/intel_connector.c | 63
>> >++
>> >> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> >> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
>> >> 4 files changed, 89 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> >> b/drivers/gpu/drm/i915/intel_atomic.c
>> >> index 16263ad..76b7114 100644
>> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> >> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>> >drm_connector *conn,
>> >>*/
>> >> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>> >> new_conn_state->broadcast_rgb !=
>> >> old_conn_state->broadcast_rgb
>> >> ||
>> >> + new_state->colorspace != old_state->colorspace ||
>> >> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>> >>base.picture_aspect_ratio ||
>> >> new_conn_state->base.content_type != old_conn_state-
>> >>base.content_type ||
>> >> new_conn_state->base.scaling_mode !=
>> >> old_conn_state->base.scaling_mode)
>> >> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> >> b/drivers/gpu/drm/i915/intel_connector.c
>> >> index ee16758..9a12d5e 100644
>> >> --- a/drivers/gpu/drm/i915/intel_connector.c
>> >> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> >> @@ -30,6 +30,48 @@
>> >> #include "intel_drv.h"
>> >> #include "i915_drv.h"
>> >>
>> >> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
>> >> + /* For Default case, driver will set the colorspace */
>> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> >> + /* Standard Definition Colorimetry based on CEA 861 */
>> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> >> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>> >> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> >> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> >> + /* High Definition Colorimetry based on IEC 61966-2-4 */
>> >> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> >> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> >> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> >> + /* Colorimetry based on IEC 61966-2-5 [33] */
>> >> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
>> >> + /* Colorimetry based on IEC 61966-2-5 */
>> >> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> >> + /* Colorimetry based on ITU-R BT.2020 */
>> >> + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> >> + /* Colorimetry based on ITU-R BT.2020 */
>> >> + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> >> + /* Colorimetry based on ITU
Re: [PATCH v4 8/9] gpu/drm/i915: optimize out the case when a range is updated to read only
On Tue, Jan 29, 2019 at 04:20:00PM +0200, Joonas Lahtinen wrote: > Quoting Jerome Glisse (2019-01-24 17:30:32) > > On Thu, Jan 24, 2019 at 02:09:12PM +0200, Joonas Lahtinen wrote: > > > Hi Jerome, > > > > > > This patch seems to have plenty of Cc:s, but none of the right ones :) > > > > So sorry, i am bad with git commands. > > > > > For further iterations, I guess you could use git option --cc to make > > > sure everyone gets the whole series, and still keep the Cc:s in the > > > patches themselves relevant to subsystems. > > > > Will do. > > > > > This doesn't seem to be on top of drm-tip, but on top of your previous > > > patches(?) that I had some comments about. Could you take a moment to > > > first address the couple of question I had, before proceeding to discuss > > > what is built on top of that base. > > > > It is on top of Linus tree so roughly ~ rc3 it does not depend on any > > of the previous patch i posted. > > You actually managed to race a point in time just when Chris rewrote much > of the userptr code in drm-tip, which I didn't remember of. My bad. > > Still interested to hearing replies to my questions in the previous > thread, if the series is still relevant. Trying to get my head around > how the different aspects of HMM pan out for devices without fault handling. HMM mirror does not need page fault handling for everything and in fact for user ptr you can use HMM mirror without page fault support in hardware. Page fault requirement is more like a __very__ nice to have feature. So sorry i missed that mail i must had it in a middle of bugzilla spam and deleted it. So here is a paste of it and answer. This was for a patch to convert i915 to use HMM mirror instead of having i915 does it own thing with GUP (get_user_page). > Bit late reply, but here goes :) > > We're working quite hard to avoid pinning any pages unless they're in > the GPU page tables. And when they are in the GPU page tables, they must > be pinned for whole of that duration, for the reason that our GPUs can > not take a fault. And to avoid thrashing GPU page tables, we do leave > objects in page tables with the expectation that smart userspace > recycles buffers. You do not need to pin the page because you obey to mmu notifier ie it is perfectly fine for you to keep the page map into the GPU until you get an mmu notifier call back for the range of virtual address. The pin from GUP in fact does not protect you from anything. GUP is really misleading, by the time GUP return the page you get might not correspond to the memory backing the virtual address. In i915 code this is not an issue because you synchronize against mmu notifier call back. So my intention in converting GPU driver from GUP to HMM mirror is just to avoid the useless page pin. As long as you obey the mmu notifier call back (or HMM sync page table call back) then you are fine. > So what I understand of your proposal, it wouldn't really make a > difference for us in the amount of pinned pages (which I agree, > we'd love to see going down). When we're unable to take a fault, > the first use effectively forces us to pin any pages and keep them > pinned to avoid thrashing GPU page tables. With HMM there is no pin, we never pin the page ie we never increment the refcount on the page as it is useless to do so if you abide by mmu notifier. Again the pin GUP take is misleading it does not block mm event. However Without pin and still abiding to mmu notifier you will not see any difference in thrashing ie number of time you will get a mmu notifier call back. As really those call back happens for good reasons. For instance running out of memory and kernel trying to reclaim or because userspace did a syscall that affect the range of virtual address. This should not happen in regular workload and when they happen the pin from GUP will not inhibit those either. In the end you will get the exact same amount of trashing but you will inhibit thing like memory compaction or migration while HMM does not block those (ie HMM is a good citizen ;) while GUP user are not). Also we are in the process of changing GUP and GUP will now have more profound impact to filesystem and mm (inhibiting and breaking some of the filesystem behavior). Converting GPU driver to HMM will avoid those adverse impact and it is one of the motivation behind my crusade to convert all GUP user that abide by mmu notifier to use HMM instead. > So from i915 perspective, it just seems to be mostly an exchange of > an API to an another for getting the pages. You already mentioned > the fast path is being worked on, which is an obvious difference. > But is there some other improvement one would be expecting, beyond > the page pinning? So for HMM i have a bunch of further optimization and new feature. Using HMM would make it easier for i915 to leverage those. > Also, is the requirement for a single non-file-backed VMA in the > plans of being eliminated or is that inherent restriction of th
[Bug 108889] [CI][SHARDS] igt@sw_sync@sync_busy_fork_unixsocket - incomplete - __igt_fork_helper: Assertion `!proc->running' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=108889
--- Comment #4 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- SKL ICL: igt@sw_sync@sync_busy_fork* - incomplete - __igt_fork_helper:
Assertion `!proc->running' failed. -}
{+ HSW SKL ICL: igt@sw_sync@sync_busy_fork* - incomplete - __igt_fork_helper:
Assertion `!proc->running' failed. +}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_186/fi-hsw-peppy/igt@sw_sync@sync_busy_fork_unixsocket.html
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/TODO: Add vrefresh replacement to the todo
From: Sean Paul Suggested-by: Daniel Vetter Signed-off-by: Sean Paul --- Documentation/gpu/todo.rst | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 38360ede12215..7fc30380eaf6c 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -262,6 +262,21 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() + + +drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it +is risky and has been known to cause div-by-zero bugs. Fortunately, drm core +has helper which will use mode.vrefresh if it's !0 and will calculate it from +the timings when it's 0. + +Use simple search/replace, or (more fun) cocci to replace instances of direct +vrefresh access with a call to the helper. Check out +https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for +inspiration. + +Contact: Sean Paul + Core refactorings = -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, January 29, 2019 9:14 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
> >; Lankhorst, Maarten ;
> >dri-devel@lists.freedesktop.org
> >Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
> >
> >On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
> >> This patch attaches the colorspace connector property to the hdmi
> >> connector. Based on colorspace change, modeset will be triggered to
> >> switch to new colorspace.
> >>
> >> Based on colorspace property value create an infoframe with
> >> appropriate colorspace. This can be used to send an infoframe packet
> >> with proper colorspace value set which will help to enable wider color
> >> gamut like BT2020 on sink.
> >>
> >> This patch attaches and enables HDMI colorspace, DP will be taken care
> >> separately.
> >>
> >> v2: Merged the changes of creating infoframe as well to this patch as
> >> per Maarten's suggestion.
> >>
> >> v3: Addressed review comments from Shashank. Separated HDMI and DP
> >> colorspaces as suggested by Ville and Maarten.
> >>
> >> v4: Addressed Chris and Ville's review comments, and created a common
> >> colorspace property for DP and HDMI, filtered the list based on the
> >> colorspaces supported by the respective protocol standard. Handle the
> >> default case properly.
> >>
> >> v5: Added Platform specific colorspace enums and called the property
> >> creation helper using the same.
> >>
> >> v6: Addressed Shashank's review comments.
> >>
> >> v7: Rebase
> >>
> >> v8: Addressed Maarten's review comments.
> >>
> >> Signed-off-by: Uma Shankar
> >> Reviewed-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/i915/intel_atomic.c| 1 +
> >> drivers/gpu/drm/i915/intel_connector.c | 63
> >++
> >> drivers/gpu/drm/i915/intel_drv.h | 1 +
> >> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
> >> 4 files changed, 89 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index 16263ad..76b7114 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
> >drm_connector *conn,
> >> */
> >>if (new_conn_state->force_audio != old_conn_state->force_audio ||
> >>new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
> >> ||
> >> + new_state->colorspace != old_state->colorspace ||
> >>new_conn_state->base.picture_aspect_ratio != old_conn_state-
> >>base.picture_aspect_ratio ||
> >>new_conn_state->base.content_type != old_conn_state-
> >>base.content_type ||
> >>new_conn_state->base.scaling_mode !=
> >> old_conn_state->base.scaling_mode)
> >> diff --git a/drivers/gpu/drm/i915/intel_connector.c
> >> b/drivers/gpu/drm/i915/intel_connector.c
> >> index ee16758..9a12d5e 100644
> >> --- a/drivers/gpu/drm/i915/intel_connector.c
> >> +++ b/drivers/gpu/drm/i915/intel_connector.c
> >> @@ -30,6 +30,48 @@
> >> #include "intel_drv.h"
> >> #include "i915_drv.h"
> >>
> >> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
> >> + /* For Default case, driver will set the colorspace */
> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> >> + /* Standard Definition Colorimetry based on CEA 861 */
> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> >> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> >> + /* Standard Definition Colorimetry based on IEC 61966-2-4 */
> >> + { DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
> >> + /* High Definition Colorimetry based on IEC 61966-2-4 */
> >> + { DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
> >> + /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
> >> + { DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
> >> + /* Colorimetry based on IEC 61966-2-5 [33] */
> >> + { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
> >> + /* Colorimetry based on IEC 61966-2-5 */
> >> + { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> >> + /* Colorimetry based on ITU-R BT.2020 */
> >> + { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
> >> + /* Colorimetry based on ITU-R BT.2020 */
> >> + { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
> >> + /* Colorimetry based on ITU-R BT.2020 */
> >> + { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
> >> +
> >> +static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
> >> + /* For Default case, driver will set the colorspace */
> >> + { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> >> + /* Standard Definition Colorimetry based on CEA 861 */
> >> + { DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
> >> + { DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
> >> +
RE: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
>-Original Message- >From: Daniel Stone [mailto:dan...@fooishbar.org] >Sent: Tuesday, January 29, 2019 9:24 PM >To: Brian Starkey >Cc: Shankar, Uma ; Syrjala, Ville >; intel-...@lists.freedesktop.org; dri- >de...@lists.freedesktop.org; nd ; Lankhorst, Maarten > >Subject: Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property > >Hi, > >On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote: >> On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote: >> > >> +#define DP_COLORIMETRY_SCRGB 15 >> > >> +#define DP_COLORIMETRY_DCI_P3 16 >> > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17 >> >> Sorry, I somehow missed your reply earlier in the month - but this >> wasn't what I meant. >> >> The expectation with enum properties is that the numeric values are >> determined at runtime - userspace shouldn't depend on them being known >> at compile-time. So, in include/uapi there shouldn't be these numeric >> values. >> >> The strings themselves effectively form the UABI, so I was wondering >> if they should be defined in include/uapi, but you would be the first >> to do that. >> >> Daniel Vetter and/or Daniel Stone might have opinions on this. > >That's correct. The DPMS definitions are a historical aberration, and we should >not be adding any more numeric definitions of enum properties to uABI. > >They can be fixed in the kernel, but userspace must only rely on the strings. Ok so if I understand correctly, we should drop the changes in uapi header for macro definitions and let the userspace match string which are supported in enum as part of property creation. So this info is redundant and not to be relied upon. Regards, Uma Shankar >Cheers, >Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/sun4i: dsi: Change the start delay calculation
Hi,
On Wed, 2019-01-23 at 16:54 +0100, Maxime Ripard wrote:
> The current calculation for the video start delay in the current DSI driver
> is that it is the total vertical size, minus the backporch and sync length,
> plus 1.
>
> However, the Allwinner code has it as the active vertical size, plus the
> back porch and the sync length. This doesn't make any difference on the
> only panel it has been tested with so far, since in that particular case
> the front porch is equal to the sum of the back porch and sync length.
>
> This is not the case for all panels, obviously, so we need to fix it. Since
> the Allwinner code has a bunch of extra code to deal with out of bounds
> values, so let's add them as well.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 380fc527a707..e3e4ba90c059 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -357,7 +357,12 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
> static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
> struct drm_display_mode *mode)
> {
> - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
> + u16 delay = (mode->vsync_end + 1) % mode->vtotal;
> +
> + if (!delay)
> + delay = 1;
For increased clarity, you might want to change this last block to:
delay = max(delay, 1);
Cheers,
Paul
> + return delay;
> }
>
> static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, January 29, 2019 9:14 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@lists.freedesktop.org
>Subject: Re: [v8 2/2] drm/i915: Attach colorspace property and enable modeset
>
>On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
>> This patch attaches the colorspace connector property to the hdmi
>> connector. Based on colorspace change, modeset will be triggered to
>> switch to new colorspace.
>>
>> Based on colorspace property value create an infoframe with
>> appropriate colorspace. This can be used to send an infoframe packet
>> with proper colorspace value set which will help to enable wider color
>> gamut like BT2020 on sink.
>>
>> This patch attaches and enables HDMI colorspace, DP will be taken care
>> separately.
>>
>> v2: Merged the changes of creating infoframe as well to this patch as
>> per Maarten's suggestion.
>>
>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> colorspaces as suggested by Ville and Maarten.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard. Handle the
>> default case properly.
>>
>> v5: Added Platform specific colorspace enums and called the property
>> creation helper using the same.
>>
>> v6: Addressed Shashank's review comments.
>>
>> v7: Rebase
>>
>> v8: Addressed Maarten's review comments.
>>
>> Signed-off-by: Uma Shankar
>> Reviewed-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c| 1 +
>> drivers/gpu/drm/i915/intel_connector.c | 63
>++
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_hdmi.c | 24 +
>> 4 files changed, 89 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 16263ad..76b7114 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>drm_connector *conn,
>> */
>> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
>> ||
>> +new_state->colorspace != old_state->colorspace ||
>> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>base.picture_aspect_ratio ||
>> new_conn_state->base.content_type != old_conn_state-
>>base.content_type ||
>> new_conn_state->base.scaling_mode !=
>> old_conn_state->base.scaling_mode)
>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> b/drivers/gpu/drm/i915/intel_connector.c
>> index ee16758..9a12d5e 100644
>> --- a/drivers/gpu/drm/i915/intel_connector.c
>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> @@ -30,6 +30,48 @@
>> #include "intel_drv.h"
>> #include "i915_drv.h"
>>
>> +static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> +{ DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ DRM_MODE_COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>> +
>> +static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ DRM_MODE_COLORIMETRY_ITU_601, "ITU_601" },
>> +{ DRM_MODE_COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ DRM_MODE_COLORIMETRY_X
Re: [PATCH v2] drm: add definitions for DP Audio/Video compliance tests
On Mon, Jan 28, 2019 at 02:58:53PM -0800, Chandan Uddaraju wrote: > This change adds definitions needed for DP audio compliance testing. > It also adds missing definition for DP video compliance. > > Changes in V2: > -- Delete cover letter for this patch. > -- Move the description from cover letter into patch commit message. > -- Remove DPU from subject prefix > > Signed-off-by: Chandan Uddaraju Reviewed-by: Sean Paul If no one has any objections, it'd be nice to apply this through msm tree along with the dpu code that makes use of it. Sean > --- > include/drm/drm_dp_helper.h | 13 + > 1 file changed, 13 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 5736c94..e688e05 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -556,6 +556,8 @@ > # define DP_TEST_LINK_EDID_READ (1 << 2) > # define DP_TEST_LINK_PHY_TEST_PATTERN (1 << 3) /* DPCD >= 1.1 */ > # define DP_TEST_LINK_FAUX_PATTERN (1 << 4) /* DPCD >= 1.2 */ > +# define DP_TEST_LINK_AUDIO_PATTERN (1 << 5) /* DPCD >= 1.2 */ > +# define DP_TEST_LINK_AUDIO_DISABLED_VIDEO (1 << 6) /* DPCD >= 1.2 */ > > #define DP_TEST_LINK_RATE0x219 > # define DP_LINK_RATE_162(0x6) > @@ -604,6 +606,7 @@ > # define DP_COLOR_FORMAT_RGB(0 << 1) > # define DP_COLOR_FORMAT_YCbCr422 (1 << 1) > # define DP_COLOR_FORMAT_YCbCr444 (2 << 1) > +# define DP_TEST_DYNAMIC_RANGE_VESA (0 << 3) > # define DP_TEST_DYNAMIC_RANGE_CEA (1 << 3) > # define DP_TEST_YCBCR_COEFFICIENTS (1 << 4) > # define DP_YCBCR_COEFFICIENTS_ITU601 (0 << 4) > @@ -653,6 +656,16 @@ > > #define DP_TEST_SINK 0x270 > # define DP_TEST_SINK_START (1 << 0) > +#define DP_TEST_AUDIO_MODE 0x271 > +#define DP_TEST_AUDIO_PATTERN_TYPE 0x272 > +#define DP_TEST_AUDIO_PERIOD_CH1 0x273 > +#define DP_TEST_AUDIO_PERIOD_CH2 0x274 > +#define DP_TEST_AUDIO_PERIOD_CH3 0x275 > +#define DP_TEST_AUDIO_PERIOD_CH4 0x276 > +#define DP_TEST_AUDIO_PERIOD_CH5 0x277 > +#define DP_TEST_AUDIO_PERIOD_CH6 0x278 > +#define DP_TEST_AUDIO_PERIOD_CH7 0x279 > +#define DP_TEST_AUDIO_PERIOD_CH8 0x27A > > #define DP_FEC_STATUS0x280/* 1.4 */ > # define DP_FEC_DECODE_EN_DETECTED (1 << 0) > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [v7 1/2] drm: Add colorspace connector property
Hi, On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote: > On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote: > > >> +#define DP_COLORIMETRY_SCRGB 15 > > >> +#define DP_COLORIMETRY_DCI_P3 16 > > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17 > > Sorry, I somehow missed your reply earlier in the month - but this > wasn't what I meant. > > The expectation with enum properties is that the numeric values are > determined at runtime - userspace shouldn't depend on them being known > at compile-time. So, in include/uapi there shouldn't be these numeric > values. > > The strings themselves effectively form the UABI, so I was wondering > if they should be defined in include/uapi, but you would be the first > to do that. > > Daniel Vetter and/or Daniel Stone might have opinions on this. That's correct. The DPMS definitions are a historical aberration, and we should not be adding any more numeric definitions of enum properties to uABI. They can be fixed in the kernel, but userspace must only rely on the strings. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/msm: Use drm_mode_vrefresh instead of mode->vrefresh
On Tue, Jan 29, 2019 at 09:59:40AM +0100, Daniel Vetter wrote:
> On Mon, Jan 28, 2019 at 03:42:48PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Use the drm_mode_vrefresh helper where we need refresh rate in case
> > vrefresh is empty.
> >
> > Signed-off-by: Sean Paul
>
> I think adding a todo to remove these fields and switch everone over to
> the helpers would be useful. Recomputing is not going to hurt us I think
> in modeset code (the one case where we do care is vblank constants, and
> those are somewhere else), and would avoid all these bugs ...
Yeah, and to boot if vrefresh is populated, the function just returns it, so
it's quite safe (unless someone is relying on vrefresh == 0 as valid data, which
would be nice to weed out anyways).
I'll spin up a TODO patch, good suggestion.
Sean
> -Daniel
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +++---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 5 +++--
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c| 2 +-
> > drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 4 ++--
> > 4 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index 941ac25d2a023..dd71cb6ba4f5c 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -522,8 +522,8 @@ static void _dpu_encoder_adjust_mode(struct
> > drm_connector *connector,
> >
> > list_for_each_entry(cur_mode, &connector->modes, head) {
> > if (cur_mode->vdisplay == adj_mode->vdisplay &&
> > - cur_mode->hdisplay == adj_mode->hdisplay &&
> > - cur_mode->vrefresh == adj_mode->vrefresh) {
> > + cur_mode->hdisplay == adj_mode->hdisplay &&
> > + drm_mode_vrefresh(cur_mode) == drm_mode_vrefresh(adj_mode))
> > {
> > adj_mode->private = cur_mode->private;
> > adj_mode->private_flags |= cur_mode->private_flags;
> > }
> > @@ -1805,7 +1805,7 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc,
> > bool async)
> >
> > atomic_set(&dpu_enc->frame_done_timeout,
> > DPU_FRAME_DONE_TIMEOUT * 1000 /
> > - drm_enc->crtc->state->adjusted_mode.vrefresh);
> > +
> > drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode));
> > mod_timer(&dpu_enc->frame_done_timer, jiffies +
> > ((atomic_read(&dpu_enc->frame_done_timeout) * HZ) / 1000));
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > index 99ab5ca9bed3b..f21163313d635 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
> > @@ -404,7 +404,8 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
> > return;
> > }
> >
> > - tc_cfg.vsync_count = vsync_hz / (mode->vtotal * mode->vrefresh);
> > + tc_cfg.vsync_count = vsync_hz /
> > + (mode->vtotal * drm_mode_vrefresh(mode));
> >
> > /* enable external TE after kickoff to avoid premature autorefresh */
> > tc_cfg.hw_vsync_mode = 0;
> > @@ -424,7 +425,7 @@ static void dpu_encoder_phys_cmd_tearcheck_config(
> > DPU_DEBUG_CMDENC(cmd_enc,
> > "tc %d vsync_clk_speed_hz %u vtotal %u vrefresh %u\n",
> > phys_enc->hw_pp->idx - PINGPONG_0, vsync_hz,
> > - mode->vtotal, mode->vrefresh);
> > + mode->vtotal, drm_mode_vrefresh(mode));
> > DPU_DEBUG_CMDENC(cmd_enc,
> > "tc %d enable %u start_pos %u rd_ptr_irq %u\n",
> > phys_enc->hw_pp->idx - PINGPONG_0, tc_enable, tc_cfg.start_pos,
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index b01183b309b9e..da1f727d74957 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -387,7 +387,7 @@ static void _dpu_plane_set_ot_limit(struct drm_plane
> > *plane,
> > ot_params.width = drm_rect_width(&pdpu->pipe_cfg.src_rect);
> > ot_params.height = drm_rect_height(&pdpu->pipe_cfg.src_rect);
> > ot_params.is_wfd = !pdpu->is_rt_pipe;
> > - ot_params.frame_rate = crtc->mode.vrefresh;
> > + ot_params.frame_rate = drm_mode_vrefresh(&crtc->mode);
> > ot_params.vbif_idx = VBIF_RT;
> > ot_params.clk_ctrl = pdpu->pipe_hw->cap->clk_ctrl;
> > ot_params.rd = true;
> > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > index c1962f29ec7d6..6341ac010f7de 100644
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> > @@ -59,10 +59,10 @@ static int pingpong_tearcheck_setup(struct drm_encoder
> > *
Re: [PATCH 1/4] drm/sun4i: dsi: Restrict DSI tcon clock divider
Hi,
On Wed, 2019-01-23 at 16:54 +0100, Maxime Ripard wrote:
> The current code allows the TCON clock divider to have a range between 4
> and 127 when feeding the DSI controller.
>
> The only display supported so far had a display clock rate that ended up
> using a divider of 4, but testing with other displays show that only 4
> seems to be functional.
>
> This also aligns with what Allwinner is doing in their BSP, so let's just
> hardcode that we want a divider of 4 when using the DSI output.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 0420f5c978b9..bee73ead732a 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -341,8 +341,8 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon
> *tcon,
> u32 block_space, start_delay;
> u32 tcon_div;
>
> - tcon->dclk_min_div = 4;
> - tcon->dclk_max_div = 127;
> + tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
> + tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;
>
> sun4i_tcon0_mode_set_common(tcon, mode);
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> index dbbc5b3ecbda..6d4a3c0fd9b5 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
> @@ -13,6 +13,8 @@
> #include
> #include
>
> +#define SUN6I_DSI_TCON_DIV 4
> +
> struct sun6i_dphy {
> struct clk *bus_clk;
> struct clk *mod_clk;
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
