dri-devel April 2018

dri-devel@lists.freedesktop.org

267 participants
1852 discussions

[Bug 105911] DVI-D monitor connected to DVI-I output not detected (regression from kernel 4.14.32 to kernel 4.16.0 using graphic core)
by bugzilla-daemon＠freedesktop.org 06 Apr '18

06 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=105911 --- Comment #6 from Matthias Nagel <matthias.h.nagel(a)gmail.com> --- (In reply to Michel Dänzer from comment #5) > Note that with the 4.16 kernel, Xorg doesn't use the xorg.conf Section > Monitor for the second DVI output, because it has a different name. I know, but that's unimportant. The xorg.conf section for the second DVI output only exists such that the default layout of the monitors matches their physical arrangement on my desk. (From left to right, DVI-I tilted upwards, DP and then DVI-D). > But it > looks like the real problem is that DC doesn't detect the monitor connected > to it, reassigning. That's it. > BTW, does it still work with the 4.16 kernel and amdgpu.dc=0? Yes it does. (But of course with a wrong layout, because DVI-I is renamed to DVI-D-1) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 105911] DVI-D monitor connected to DVI-I output not detected (regression from kernel 4.14.32 to kernel 4.16.0 using graphic core)
by bugzilla-daemon＠freedesktop.org 06 Apr '18

06 Apr '18

https://bugs.freedesktop.org/show_bug.cgi?id=105911 Michel Dänzer <michel(a)daenzer.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |harry.wentland(a)amd.com Product|xorg |DRI Component|Driver/AMDgpu |DRM/AMDgpu QA Contact|xorg-team(a)lists.x.org | Version|7.4 (2008.09) |unspecified Assignee|xorg-driver-ati(a)lists.x.org |dri-devel(a)lists.freedesktop | |.org --- Comment #5 from Michel Dänzer <michel(a)daenzer.net> --- Note that with the 4.16 kernel, Xorg doesn't use the xorg.conf Section Monitor for the second DVI output, because it has a different name. But it looks like the real problem is that DC doesn't detect the monitor connected to it, reassigning. BTW, does it still work with the 4.16 kernel and amdgpu.dc=0? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[RFC] drm/atomic+msm: add helper to implement legacy dirtyfb
by Rob Clark 06 Apr '18

06 Apr '18

Add an atomic helper to implement dirtyfb support. This is needed to support DSI command-mode panels with x11 userspace (ie. when we can't rely on pageflips to trigger a flush to the panel). To signal to the driver that the async atomic update needs to synchronize with fences, even though the fb didn't change, the drm_atomic_state::dirty flag is added. Signed-off-by: Rob Clark <robdclark(a)gmail.com> --- Background: there are a number of different folks working on getting upstream kernel working on various different phones/tablets with qcom SoC's.. many of them have command mode panels, so we kind of need a way to support the legacy dirtyfb ioctl for x11 support. I know there is work on a proprer non-legacy atomic property for userspace to communicate dirty-rect(s) to the kernel, so this can be improved from triggering a full-frame flush once that is in place. But we kinda needa a stop-gap solution. I had considered an in-driver solution for this, but things get a bit tricky if userspace ands up combining dirtyfb ioctls with page- flips, because we need to synchronize setting various CTL.FLUSH bits with setting the CTL.START bit. (ie. really all we need to do for cmd mode panels is bang CTL.START, but is this ends up racing with pageflips setting FLUSH bits, then bad things.) The easiest soln is to wrap this up as an atomic commit and rely on the worker to serialize things. Hence adding an atomic dirtyfb helper. I guess at least the helper, with some small addition to translate and pass-thru the dirty rect(s) is useful to the final atomic dirty- rect property solution. Depending on how far off that is, a stop- gap solution could be useful. drivers/gpu/drm/drm_atomic_helper.c | 66 +++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/msm/msm_atomic.c | 5 ++- drivers/gpu/drm/msm/msm_fb.c | 1 + include/drm/drm_atomic_helper.h | 4 +++ include/drm/drm_plane.h | 9 +++++ 5 files changed, 84 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index c35654591c12..a578dc681b27 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3504,6 +3504,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane, if (state->fb) drm_framebuffer_get(state->fb); + state->dirty = false; state->fence = NULL; state->commit = NULL; } @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc, } EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set); +/** + * drm_atomic_helper_dirtyfb - helper for dirtyfb + * + * A helper to implement drm_framebuffer_funcs::dirty + */ +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb, + struct drm_file *file_priv, unsigned flags, + unsigned color, struct drm_clip_rect *clips, + unsigned num_clips) +{ + struct drm_modeset_acquire_ctx ctx; + struct drm_atomic_state *state; + struct drm_plane *plane; + int ret = 0; + + /* + * When called from ioctl, we are interruptable, but not when + * called internally (ie. defio worker) + */ + drm_modeset_acquire_init(&ctx, + file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0); + + state = drm_atomic_state_alloc(fb->dev); + if (!state) { + ret = -ENOMEM; + goto out; + } + state->acquire_ctx = &ctx; + +retry: + drm_for_each_plane(plane, fb->dev) { + struct drm_plane_state *plane_state; + + if (plane->state->fb != fb) + continue; + + plane_state = drm_atomic_get_plane_state(state, plane); + if (IS_ERR(plane_state)) { + ret = PTR_ERR(plane_state); + goto out; + } + + plane_state->dirty = true; + } + + ret = drm_atomic_nonblocking_commit(state); + +out: + if (ret == -EDEADLK) { + drm_atomic_state_clear(state); + ret = drm_modeset_backoff(&ctx); + if (!ret) + goto retry; + } + + drm_atomic_state_put(state); + + drm_modeset_drop_locks(&ctx); + drm_modeset_acquire_fini(&ctx); + + return ret; + +} +EXPORT_SYMBOL(drm_atomic_helper_dirtyfb); + /** * __drm_atomic_helper_private_duplicate_state - copy atomic private state * @obj: CRTC object diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c index bf5f8c39f34d..bb55a048e98b 100644 --- a/drivers/gpu/drm/msm/msm_atomic.c +++ b/drivers/gpu/drm/msm/msm_atomic.c @@ -201,7 +201,10 @@ int msm_atomic_commit(struct drm_device *dev, * Figure out what fence to wait for: */ for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) { - if ((new_plane_state->fb != old_plane_state->fb) && new_plane_state->fb) { + bool sync_fb = new_plane_state->fb && + ((new_plane_state->fb != old_plane_state->fb) || + new_plane_state->dirty); + if (sync_fb) { struct drm_gem_object *obj = msm_framebuffer_bo(new_plane_state->fb, 0); struct msm_gem_object *msm_obj = to_msm_bo(obj); struct dma_fence *fence = reservation_object_get_excl_rcu(msm_obj->resv); diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c index 0e0c87252ab0..a5d882a34a33 100644 --- a/drivers/gpu/drm/msm/msm_fb.c +++ b/drivers/gpu/drm/msm/msm_fb.c @@ -62,6 +62,7 @@ static void msm_framebuffer_destroy(struct drm_framebuffer *fb) static const struct drm_framebuffer_funcs msm_framebuffer_funcs = { .create_handle = msm_framebuffer_create_handle, .destroy = msm_framebuffer_destroy, + .dirty = drm_atomic_helper_dirtyfb, }; #ifdef CONFIG_DEBUG_FS diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h index 26aaba58d6ce..9b7a95c2643d 100644 --- a/include/drm/drm_atomic_helper.h +++ b/include/drm/drm_atomic_helper.h @@ -183,6 +183,10 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green, u16 *blue, uint32_t size, struct drm_modeset_acquire_ctx *ctx); +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb, + struct drm_file *file_priv, unsigned flags, + unsigned color, struct drm_clip_rect *clips, + unsigned num_clips); void __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj *obj, struct drm_private_state *state); diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index f7bf4a48b1c3..296fa22bda7a 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -76,6 +76,15 @@ struct drm_plane_state { */ struct drm_framebuffer *fb; + /** + * @dirty: + * + * Flag that indicates the fb contents have changed even though the + * fb has not. This is mostly a stop-gap solution until we have + * atomic dirty-rect(s) property. + */ + bool dirty; + /** * @fence: * -- 2.14.3

6 32

[PATCH v2] drm/i915/dp: Send DPCD ON for MST before phy_up
by Lyude Paul 05 Apr '18

05 Apr '18

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought this might be an issue with us accidentally shutting off the aux block when putting the sink into D3, but since the DP spec mandates that sinks must wake up within 1ms while we have 100ms to respond to an ESI irq, this didn't really add up. Turns out that the problem is more subtle then that: It turns out that the timeout is from us not enabling DPMS on the MST hub before actually trying to initiate sideband communications. This would cause the first sideband communication (power_up_phy()), to start timing out because the sink wasn't ready to respond. Afterwards, we would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in intel_ddi_pre_enable_dp(), which would actually result in waking up the sink so that sideband requests would work again. Since DPMS is what lets us actually bring the hub up into a state where sideband communications become functional again, we just need to make sure to enable DPMS on the display before attempting to perform sideband communications. Changes since v1: - Remove comment above if (!intel_dp->is_mst) - vsryjala - Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to keep enable/disable paths symmetrical - Improve commit message - dhnkrn Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- This email should hopefully actually be picked up by patchwork this time, hooray! drivers/gpu/drm/i915/intel_ddi.c | 6 ++++-- drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a6672a9abd85..c0bf7419e1c1 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2324,7 +2324,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_prepare_dp_ddi_buffers(encoder, crtc_state); intel_ddi_init_dp_buf_reg(encoder); - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_start_link_train(intel_dp); if (port != PORT_A || INTEL_GEN(dev_priv) >= 9) intel_dp_stop_link_train(intel_dp); @@ -2427,7 +2428,8 @@ static void intel_ddi_post_disable_dp(struct intel_encoder *encoder, * Power down sink before disabling the port, otherwise we end * up getting interrupts from the sink on detecting link loss. */ - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF); + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF); intel_disable_ddi_buf(encoder); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..2493bd1e0e59 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -176,6 +176,7 @@ static void intel_mst_post_disable_dp(struct intel_encoder *encoder, */ drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, false); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF); intel_dp->active_mst_links--; @@ -223,6 +224,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_enable(&intel_dig_port->base, -- 2.14.3

3 5

[PATCH v6 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge
by Jacopo Mondi 05 Apr '18

05 Apr '18

Hi, (hopefully) last iteration, with Niklas' Reviewed-by tags. Simply drop an un-necessary #ifdef guard for CONFIG_OF in driver's code as suggested by Niklas. Time to talk how this series will go in? I assume bindings and driver through DRM tree, while Simon is to pick up the Eagle DTS update once the first two patches will get in. Is this ok for both DRM and Renesas side? Also I assume before bindings gets accepted someone from devicetree list should ack them, correct? Simon: as Niklas suggested, I have now listed the series dependencies below the commit message. It is my understanding that is not necessary to resend his series with that commit squashed on top (which I also prefer not to). Thanks j v5 -> v6: - Drop check for CONFIG_OF as it is a Kconfig dependency - Add Niklas Reviewed-by tags - List [3/3] depenencies below commit message to ease integration v4 -> v5: - Fix punctuation in bindings documentation - Add small statement to bindings document to clarify the chip has no control bus - Print regulator name in enable/disable routines error path - Add Andrzej Reviewed-by tag v3 -> v4: - Rename permutations of "pdwn" to just "pdwn" everywhere in the series - Improve power enable/disable routines as suggested by Andrzej and Sergei - Change "pdwn" gpio initialization to use the logical output level - Change Kconfig description v2 -> v3: - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific -- Rework bindings to describe multiple input/output ports -- Rename driver and remove "lvds-decoder" references -- Rework Eagle DTS to use new bindings v1 -> v2: - Drop support for THC63LVD1024 Jacopo Mondi (3): dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder drm: bridge: Add thc63lvd1024 LVDS decoder driver arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++++++ arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 ++- drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/thc63lvd1024.c | 255 +++++++++++++++++++++ 5 files changed, 358 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c -- 2.7.4

8 31

[PATCH libdrm 00/23] meson: fix 'auto' handling of drivers and simplify code
by Eric Engestrom 05 Apr '18

05 Apr '18

First 5 patches fix a bug where $driver=auto could end up being turned on even though a dependency (`with_atomic`) is missing. Next 4 are turning auto=false into auto=true, which I guess might not be what we want. I'm happy to change or drop them if people want, the rebase would be quite easy. Then a couple aesthetic patches because I find the code easier to read like this; again, I can drop if people disagree. The diffstat until then is mostly adding code, but that's about to change: meson.build | 126 ++++++++++++++++++++++++++++++++++++------------------------ 1 file changed, 75 insertions(+), 51 deletions(-) After that, I'm introducing a loop to handle all the copy/pasted code for all the driver options, and then adding them to the list one by one to make it easier to review and/or bisect if I mess it up. meson.build | 140 ++++++++++++++---------------------------------------------- 1 file changed, 31 insertions(+), 109 deletions(-) --- Eric Engestrom (23): meson: don't enable libdrm_intel without atomic support meson: don't enable libdrm_radeon without atomic support meson: don't enable libdrm_amdgpu without atomic support meson: don't enable libdrm_nouveau without atomic support meson: don't enable libdrm_freedreno without atomic support meson: fix omap=auto detection (was always false) meson: fix exynos=auto detection (was always false) meson: fix tegra=auto detection (was always false) meson: fix entaviv=auto detection (was always false) meson: split vc4=auto logic to make it easier to read meson: split libkms=auto logic to make it easier to read meson: introduce simpler way to handle driver options meson: use simple option handling for intel meson: use simple option handling for radeon meson: use simple option handling for amdgpu meson: use simple option handling for nouveau meson: use simple option handling for vmwgfx meson: use simple option handling for omap meson: use simple option handling for exynos meson: use simple option handling for freedreno meson: use simple option handling for tegra meson: use simple option handling for vc4 meson: use simple option handling for etnaviv meson.build | 120 +++++++++++++++++------------------------------------------- 1 file changed, 33 insertions(+), 87 deletions(-) -- Cheers, Eric

3 56

[PATCH 00/16] Make all drivers under drivers/media to build with COMPILE_TEST
by Mauro Carvalho Chehab 05 Apr '18

05 Apr '18

The current media policy has been for a while to only accept new drivers that compile with COMPILE_TEST. However, there are still several drivers under drivers/media that doesn't build with COMPILE_TEST. So, this series makes the existing ones also compatible with it. Not building with COMPILE_TEST is a bad thing, for several reasons. The main ones is that: 1) the licence the Kernel community has for Coverity only builds for x86. So, drivers that don't build on such archtecture were likely never tested by it. 2) That affects my per-patch handling process, with should be quick enough to not delay my patch handling process. So, I only build for one architecture (i386). 3) When appliying a patch, I always run two static code analyzers (W=1, smatch and sparse). Those drivers weren't checked by me. At the end of the day, that leads to a lower quality check for the drivers that don't build on i386. There are two situations on this patch series that proof the lower quality of those drivers: - There is a case of a driver that was added broken in 2013. Only two years later, someone noticed and "fixed" it by markin it as BROKEN! - 5 patches in this series (about 1/3) are just to fix build issues on those drivers, most of them due to gcc warnings. Mauro Carvalho Chehab (16): omap: omap-iommu.h: allow building drivers with COMPILE_TEST media: omap3isp: allow it to build with COMPILE_TEST media: omap3isp/isp: remove an unused static var media: fsl-viu: mark static functions as such media: fsl-viu: allow building it with COMPILE_TEST media: cec_gpio: allow building CEC_GPIO with COMPILE_TEST media: exymos4-is: allow compile test for EXYNOS FIMC-LITE media: mmp-camera.h: add missing platform data media: marvel-ccic: re-enable mmp-driver build media: mmp-driver: make two functions static media: davinci: allow building isif code media: davinci: allow build vpbe_display with COMPILE_TEST media: vpbe_venc: don't store return codes if they won't be used media: davinci: get rid of lots of kernel-doc warnings media: omapfb_dss.h: add stubs to build with COMPILE_TEST media: omap: allow building it with COMPILE_TEST drivers/media/platform/Kconfig | 12 +++--- drivers/media/platform/davinci/Kconfig | 6 ++- drivers/media/platform/davinci/isif.c | 2 - drivers/media/platform/davinci/vpbe.c | 38 +++++++++-------- drivers/media/platform/davinci/vpbe_display.c | 21 +++++---- drivers/media/platform/davinci/vpbe_osd.c | 16 ++++--- drivers/media/platform/davinci/vpbe_venc.c | 9 ++-- drivers/media/platform/exynos4-is/Kconfig | 4 +- drivers/media/platform/fsl-viu.c | 20 ++++++--- drivers/media/platform/marvell-ccic/Kconfig | 5 ++- drivers/media/platform/marvell-ccic/mmp-driver.c | 4 +- drivers/media/platform/omap/Kconfig | 6 +-- drivers/media/platform/omap3isp/isp.c | 14 +++--- include/linux/omap-iommu.h | 5 +++ include/linux/platform_data/media/mmp-camera.h | 19 +++++++++ include/video/omapfb_dss.h | 54 +++++++++++++++++++++++- 16 files changed, 162 insertions(+), 73 deletions(-) -- 2.14.3

2 3

[PATCH] drm/i915/dp: Send DPCD ON for MST before phy_up
by Lyude Paul 05 Apr '18

05 Apr '18

As it turns out, the aux block being off was not the real problem here, as transition from D3 to D0 is mandated by the DP spec to take a maximum of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs. The real problem here is a bit more subtle. When doing a modeset where the problem of the sink timing out to our sideband requests when transitioning from D3 to D0 occurs, the timeout is from the aux block not coming on. However, nothing else times out other than the initial phy_up message because the DPCD on call in intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not the phy_up sideband message. This means that the real fix we need is to use the DPMS on before sending a phy_up to ensure that the hub is ready to accept sideband messages. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.") --- drivers/gpu/drm/i915/intel_ddi.c | 6 +++++- drivers/gpu/drm/i915/intel_dp_mst.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index a6672a9abd85..9bd675f73f7b 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder, intel_prepare_dp_ddi_buffers(encoder, crtc_state); intel_ddi_init_dp_buf_reg(encoder); - intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen + * before drm_dp_send_power_updown_phy() + */ + if (!intel_dp->is_mst) + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_start_link_train(intel_dp); if (port != PORT_A || INTEL_GEN(dev_priv) >= 9) intel_dp_stop_link_train(intel_dp); diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c3de0918ee13..eff9a4eae1f0 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder *encoder, DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links); + intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); drm_dp_send_power_updown_phy(&intel_dp->mst_mgr, connector->port, true); if (intel_dp->active_mst_links == 0) intel_dig_port->base.pre_enable(&intel_dig_port->base, -- 2.14.3

3 2

[PATCH v4 0/8] cgroup private data and DRM/i915 integration
by Matt Roper 05 Apr '18

05 Apr '18

This is the fourth iteration of the work previously posted here: (v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html (v2) https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html (v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.html The high level goal of this work is to allow non-cgroup-controller parts of the kernel (e.g., device drivers) to register their own private policy data for specific cgroups. That mechanism is then made use of in the i915 graphics driver to allow GPU priority to be assigned according to the cgroup membership of the owning process. Please see the v1 cover letter linked above for a more in-depth explanation and justification. v4 of this series brings large changes to the cgroup core half of the series and moderate changes to the i915 side. cgroup core changes: * The cgroup private data interface and implementation has changed again. The internal implementation is ida+radixtree based to allow much faster lookups than the previous hashtable approach. Private data is now registered and looked up via kref, which should allow the same private data to be set on multiple cgroups at the same time. The interface now looks like: - cgroup_priv_getkey() Obtain an integer key that will be used to store/lookup cgroup private data. This only needs to be called once at startup, driver init, etc.; after that the same key is used to store private data against any cgroup - cgroup_priv_destroykey(key) Release a private data key and drop references to any private data associated with the key on all cgroups. This function is very heavy, but will generally only be called by module-based users of the interface when the module is unloaded. - cgroup_priv_install(cgrp, key, ref) Store private data for a cgroup under the given key and increment the reference count. - cgroup_priv_get(cgrp, key) Take and return a reference to a cgroup's private data associated with the given key. - cgroup_priv_get_current(key) Same as cgroup_priv_get, but operates on the current task's cgroup. - cgroup_priv_release(cgrp, key) Remove private data from a cgroup and decrement its reference count. * Dropped the cgroup_permission() function. My i915 usage of this functionality will take a different approach for determining access control. i915 cgroup-based priority changes: * cgroup priority offset is now bounded such that (context+cgroup) adjustments fall within the range [-0x7fffff,0x7fffff]. This only takes 24 bits, leaving several effective priority bits for future flags or bookkeeping. * Display boost is added as a second cgroup parameter; each cgroup's processes can get differing boosts if a display operation is waiting on their completion. If we have non-overlapping cgroup priority ranges, this allows a system administrator to decide whether workloads from the lower priority cgroup(s) should still jump past the workloads in some/all of the higher priority cgroups. * Access control for cgroup settings has been changed. Instead of following cgroup filesystem permissions, we now restrict the access to either the DRM master or capable(CAP_SYS_RESOURCE). Cc: Tejun Heo <tj(a)kernel.org> Cc: Alexei Starovoitov <ast(a)fb.com> Cc: Roman Gushchin <guro(a)fb.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Matt Roper (8): cgroup: Allow registration and lookup of cgroup private data (v2) cgroup: Introduce task_get_dfl_cgroup() (v2) cgroup: Introduce cgroup_priv_get_current drm/i915: Adjust internal priority definitions drm/i915: cgroup integration (v3) drm/i915: Introduce 'priority offset' for GPU contexts (v3) drm/i915: Introduce per-cgroup display boost setting drm/i915: Add context priority & priority offset to debugfs (v2) drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_cgroup.c | 205 +++++++++++++++++++++++++++++++ drivers/gpu/drm/i915/i915_debugfs.c | 3 + drivers/gpu/drm/i915/i915_drv.c | 7 ++ drivers/gpu/drm/i915/i915_drv.h | 33 ++++- drivers/gpu/drm/i915/i915_gem_context.c | 11 +- drivers/gpu/drm/i915/i915_gem_context.h | 9 ++ drivers/gpu/drm/i915/i915_request.h | 18 ++- drivers/gpu/drm/i915/intel_display.c | 5 +- include/linux/cgroup-defs.h | 8 ++ include/linux/cgroup.h | 37 ++++++ include/uapi/drm/i915_drm.h | 14 +++ kernel/cgroup/cgroup.c | 208 +++++++++++++++++++++++++++++++- 13 files changed, 545 insertions(+), 14 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c -- 2.14.3

4 20

Re: drm: Branch 'master'
by Michel Dänzer 05 Apr '18

05 Apr '18

On 2018-03-30 04:51 AM, Chunming Zhou wrote: > include/drm/amdgpu_drm.h | 4 ++++ > 1 file changed, 4 insertions(+) > > New commits: > commit 2fa58c77fb9e563219f8ec647b9ddf52f3390ed2 > Author: Rex Zhu <Rex.Zhu(a)amd.com> > Date: Tue Mar 20 14:08:09 2018 +0800 > > headers: sync up amdgpu_drm.h with drm-next > > Add sensor_info type > AMDGPU_INFO_SENSOR_STABLE_PSTATE_GFX_MCLK > AMDGPU_INFO_SENSOR_STABLE_PSTATE_GFX_SCLK > > Reviewed-by: Evan Quan <evan.quan(a)amd.com> > Signed-off-by: Rex Zhu <Rex.Zhu(a)amd.com> > > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h > index a023b476..f784f248 100644 > --- a/include/drm/amdgpu_drm.h > +++ b/include/drm/amdgpu_drm.h > @@ -656,6 +656,10 @@ struct drm_amdgpu_cs_chunk_data { > #define AMDGPU_INFO_SENSOR_VDDNB 0x6 > /* Subquery id: Query graphics voltage */ > #define AMDGPU_INFO_SENSOR_VDDGFX 0x7 > + /* Subquery id: Query GPU stable pstate shader clock */ > + #define AMDGPU_INFO_SENSOR_STABLE_PSTATE_GFX_SCLK 0x8 > + /* Subquery id: Query GPU stable pstate memory clock */ > + #define AMDGPU_INFO_SENSOR_STABLE_PSTATE_GFX_MCLK 0x9 > /* Number of VRAM page faults on CPU access. */ > #define AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS 0x1E > #define AMDGPU_INFO_VRAM_LOST_COUNTER 0x1F In the future, please follow the process described in include/drm/README for syncing this header with the kernel. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2018