dri-devel June 2018

dri-devel@lists.freedesktop.org

241 participants
1687 discussions

[Bug 99492] [intel_gpu_tools] intel_gpu_frequency's parsing of parameters broken
by bugzilla-daemon＠freedesktop.org 12 Jun '18

12 Jun '18

1 0

[Bug 99492] [intel_gpu_tools] intel_gpu_frequency's parsing of parameters broken
by bugzilla-daemon＠freedesktop.org 12 Jun '18

12 Jun '18

https://bugs.freedesktop.org/show_bug.cgi?id=99492 Jani Nikula <jani.nikula(a)intel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Jani Nikula <jani.nikula(a)intel.com> --- Fix pushed to igt: commit 95bfb2902473b9f4e644c3eb831fdf110d87ed4f Author: Jani Nikula <jani.nikula(a)intel.com> Date: Tue Jun 12 17:02:11 2018 +0300 tools/intel_gpu_frequency: fix usage and examples -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 99492] [intel_gpu_tools] intel_gpu_frequency's parsing of parameters broken
by bugzilla-daemon＠freedesktop.org 12 Jun '18

12 Jun '18

https://bugs.freedesktop.org/show_bug.cgi?id=99492 --- Comment #1 from Jani Nikula <jani.nikula(a)intel.com> --- (In reply to Andreas Reis from comment #0) > At least in the case of -g, intel_gpu_frequency currently (1.16 & git) fails > if there are parameters. With none it works. > > Eg, the example's -gmin,cur yields "invalid option -- 'n'" and -gcur > "Selected unmodifiable frequency". -g|--get suboptions have been removed in commit 20d6e0f41b3b ("tools/intel_gpu_frequency: remove use of getsubopt") but the quick usage wasn't updated. Just use without suboptions. Patch on the list to update the usage: http://patchwork.freedesktop.org/patch/msgid/20180612140544.7231-1-jani.nik… > That and I couldn't compile until I disabled the assembler, I kept getting > lex.o: In function `yylex': > > lex.c:(.text+0x3c8f): undefined reference to `yywrap' Unrelated, please file a new bug if this persists with the current git. Apologies for this staying below the radar for so long; I guess nobody thought it was that important. :( -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH v8 0/5] drm/mali-dp: Add support for memory writeback engine
by Liviu Dudau 12 Jun '18

12 Jun '18

Hi, Updating the Mali DP memory writeback engine support series to match the v10 generic writeback connector support posted here [1]. Changelog: - v8: Addressed feedback from Brian wrt the state tracking that we deploy for DP500 and the timing of the CVAL setting. Also added SPDX license identifiers for the newly added files. - v7: Added support for DP500 writeback. It behaves differently from the rest of the IP portfolio, but because customers are asking for it to be supported in mainline, we're adding it here. - v6: skipped, in order to align with latest generic series numbers. - v5: https://lists.freedesktop.org/archives/dri-devel/2017-May/141799.html Best regards, Liviu [1] https://lists.freedesktop.org/archives/dri-devel/2018-June/179753.html Brian Starkey (2): drm: mali-dp: Add RGB writeback formats for DP550/DP650 drm: mali-dp: Add writeback connector Liviu Dudau (3): drm: mali-dp: Add support for writeback on DP550/DP650 drm/mali-dp: Add writeback support for DP500. drm/mali-dp: Add RGB writeback formats for DP500. drivers/gpu/drm/arm/Makefile | 1 + drivers/gpu/drm/arm/malidp_crtc.c | 10 ++ drivers/gpu/drm/arm/malidp_drv.c | 35 +++-- drivers/gpu/drm/arm/malidp_drv.h | 7 + drivers/gpu/drm/arm/malidp_hw.c | 176 ++++++++++++++++++--- drivers/gpu/drm/arm/malidp_hw.h | 21 +++ drivers/gpu/drm/arm/malidp_mw.c | 250 ++++++++++++++++++++++++++++++ drivers/gpu/drm/arm/malidp_mw.h | 14 ++ drivers/gpu/drm/arm/malidp_regs.h | 18 ++- drivers/gpu/drm/drm_atomic.c | 4 + 10 files changed, 504 insertions(+), 32 deletions(-) create mode 100644 drivers/gpu/drm/arm/malidp_mw.c create mode 100644 drivers/gpu/drm/arm/malidp_mw.h -- 2.17.1

1 5

[PATCH 00/23] omapdrm: Rework the timing-related operations
by Laurent Pinchart 12 Jun '18

12 Jun '18

Hello, This patch series reworks all the timing-related operations (.get_timings(), .set_timings() and .check_timings()) as a step toward moving from omap_dss_device to drm_bridge. All timing-related operations are called by the omapdrm driver on the omap_dss_device at the end of display pipeline, and the operations are then handled directly or forwarded to the previous omap_dss_device in the pipeline. This causes an issue in our quest to move to drm_bridge: the drm_bridge equivalent to the timing operations, .mode_valid(), .mode_fixup() and .mode_set(), are called in the source to sink direction. Furthermore, timing handling in the omapdrm driver is very complicated, with timings getting mangled, stored in random places, retrieved back by unrelated code, mangled again, stored in different places, and modified across objects. Simplifying that is crucial to move to drm_bridge. This patch series simplifies the timings operation and reverse the direction in which they're called. The driver still uses the videomode structure instead of the drm_display_mode structure to store timing information, this will be fixed in a second step. The series is really a succession of cleanups interleaved with the real changes, with a total of 406 lines of code removed overall. It starts with small changes, cleanups and code removal in patches 01/23 to 07/23, and then introduces new DRM bus flags to specify sync signal clock edges using the DRM bus_flags mechanism in patch 08/23. This is the only extension to the DRM core. Patches 09/23 and 10/23 start reworking the .check_timings() operation by making use of the bus flags. Patches 11/23 to 13/23 rework the .get_timings() operation, and patches 14/23 to 21/23 complete the .check_timings() rework. Patches 22/23 and 23/23 finally rework the .set_timings() operation. The series is based on top of the previously submitted "[PATCH 00/21] omapdrm: Rework the HPD-related operations" patch series. For convenience I've pushed it to my tree at git://linuxtv.org/pinchartl/media.git omapdrm/bridge/timings Laurent Pinchart (23): drm/omap: Pass both output and display omap_dss_device to connector init drm/omap: Determine connector type directly in omap_connector.c drm/omap: dss: hdmi: Rename hdmi_display_(set|check)_timing() functions drm/omap: Make the video_mode pointer to .set_timings() const drm/omap: Remove duplicate calls to .set_timings() operation drm/omap: Remove unneeded fallback for missing .check_timings() drm/omap: Don't store video mode internally for external encoders drm: Add display info bus flags to specify sync signals clock edges drm/omap: Store bus flags in the omap_dss_device structure drm/omap: Don't call .check_timings() operation recursively drm/omap: Query timing information from analog TV encoder drm/omap: Remove .get_timings() operation from display connectors drm/omap: panels: Don't modify fixed timings drm/omap: Move bus flag hack to encoder implementation drm/omap: Split mode fixup and mode set from encoder enable drm/omap: Call dispc timings check operation directly drm/omap: dpi: Don't fixup video mode in dpi_set_mode() drm/omap: dsi: Fixup video mode in .set_config() operation drm/omap: hdmi: Constify video mode and related pointers drm/omap: sdi: Fixup video mode in .check_timings() operation drm/omap: venc: Fixup video mode in .check_timings() operation drm/omap: Store CRTC timings in .set_timings() operation drm/omap: Don't call .set_timings() operation recursively drivers/gpu/drm/drm_modes.c | 10 +- .../gpu/drm/omapdrm/displays/connector-analog-tv.c | 52 -------- drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 57 --------- drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 51 -------- drivers/gpu/drm/omapdrm/displays/encoder-opa362.c | 29 ----- drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 37 +----- .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 26 ---- drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 23 ---- .../omapdrm/displays/panel-lgphilips-lb035q02.c | 40 ++---- .../drm/omapdrm/displays/panel-nec-nl8048hl11.c | 29 +---- .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c | 38 ++---- .../drm/omapdrm/displays/panel-sony-acx565akm.c | 29 +---- .../drm/omapdrm/displays/panel-tpo-td028ttec1.c | 38 ++---- .../drm/omapdrm/displays/panel-tpo-td043mtea1.c | 38 ++---- drivers/gpu/drm/omapdrm/dss/dispc.c | 18 +-- drivers/gpu/drm/omapdrm/dss/dpi.c | 20 +-- drivers/gpu/drm/omapdrm/dss/dsi.c | 42 +++---- drivers/gpu/drm/omapdrm/dss/dss.h | 3 - drivers/gpu/drm/omapdrm/dss/hdmi.h | 8 +- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 23 +--- drivers/gpu/drm/omapdrm/dss/hdmi5.c | 23 +--- drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 6 +- drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 8 +- drivers/gpu/drm/omapdrm/dss/omapdss.h | 6 +- drivers/gpu/drm/omapdrm/dss/sdi.c | 46 ++++--- drivers/gpu/drm/omapdrm/dss/venc.c | 39 +++--- drivers/gpu/drm/omapdrm/omap_connector.c | 140 +++++++++++++-------- drivers/gpu/drm/omapdrm/omap_connector.h | 5 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 20 --- drivers/gpu/drm/omapdrm/omap_drv.c | 26 +--- drivers/gpu/drm/omapdrm/omap_encoder.c | 124 ++++++++++++------ include/drm/drm_connector.h | 4 + 32 files changed, 326 insertions(+), 732 deletions(-) -- Regards, Laurent Pinchart

2 24

[PATCH][V3] drm/i915/guc: fix GEM_BUG_ON check
by Colin King 12 Jun '18

12 Jun '18

From: Colin Ian King <colin.king(a)canonical.com> The check for level being less than zero always false because flags is currently unsigned and can never be negative. Fix this by making level a s32. Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0") Fixes: cb5d64e9f13e ("drm/i915/guc: Allow user to control default GuC logging") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- V3: Make level s32 and add the missing Fixes: tag, thanks to Dan Carpenter and Jani Nikula for correcting my mistakes --- drivers/gpu/drm/i915/intel_guc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 116f4ccf1bbd..bdb1fab322bf 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -205,7 +205,7 @@ void intel_guc_fini(struct intel_guc *guc) static u32 get_log_control_flags(void) { - u32 level = i915_modparams.guc_log_level; + s32 level = i915_modparams.guc_log_level; u32 flags = 0; GEM_BUG_ON(level < 0); -- 2.17.0

2 1

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
by Ville Syrjälä 12 Jun '18

12 Jun '18

On Fri, Jan 12, 2018 at 05:19:44PM +0100, Hans Verkuil wrote: > Hi Ville, > > For some strange reason your email disappeared from the Cc list. Perhaps it's the > ä that confuses something somewhere. > > So I'll just forward this directly to you. > > Can you please take a look? This patch series has been in limbo for too long. IIRC last I looked we still had some ragistration race to deal with. Was that fixed? Also I think we got stuck on leaving the zombie device lingering around when the display is disconnected. I couldn't understand why that is at all useful since you anyway remove the device eventually. Adding the lists back to cc so I don't have to repeat myself there... > > Regards, > > Hans > > > -------- Forwarded Message -------- > Subject: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support > Date: Tue, 9 Jan 2018 13:46:44 +0100 > From: Hans Verkuil <hverkuil(a)xs4all.nl> > To: linux-media(a)vger.kernel.org > CC: Daniel Vetter <daniel.vetter(a)ffwll.ch>, Carlos Santa <carlos.santa(a)intel.com>, dri-devel(a)lists.freedesktop.org > > First of all a Happy New Year for all of you! > > And secondly: can this v5 patch series be reviewed/merged? It's been waiting > for that for a very long time now... > > Regards, > > Hans > > On 12/11/17 09:57, Hans Verkuil wrote: > > Ping again. Added a CC to Ville whom I inexplicably forgot to add when > > I sent the v5 patch series. > > > > Regards, > > > > Hans > > > > On 01/12/17 08:23, Hans Verkuil wrote: > >> Ping! > >> > >> I really like to get this in for 4.16 so I can move forward with hooking > >> this up for nouveau/amd. > >> > >> Regards, > >> > >> Hans > >> > >> On 11/20/2017 12:42 PM, Hans Verkuil wrote: > >>> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX > >>> feature. This patch series is based on the 4.14 mainline release but applies > >>> as well to drm-next. > >>> > >>> This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to > >>> HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI > >>> adapter (where the CEC pin is wired up). > >>> > >>> Please note this comment at the start of drm_dp_cec.c: > >>> > >>> ---------------------------------------------------------------------- > >>> Unfortunately it turns out that we have a chicken-and-egg situation > >>> here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters > >>> have a converter chip that supports CEC-Tunneling-over-AUX (usually the > >>> Parade PS176 or MegaChips MCDP2900), but they do not wire up the CEC pin, > >>> thus making CEC useless. > >>> > >>> Sadly there is no way for this driver to know this. What happens is > >>> that a /dev/cecX device is created that is isolated and unable to see > >>> any of the other CEC devices. Quite literally the CEC wire is cut > >>> (or in this case, never connected in the first place). > >>> > >>> I suspect that the reason so few adapters support this is that this > >>> tunneling protocol was never supported by any OS. So there was no > >>> easy way of testing it, and no incentive to correctly wire up the > >>> CEC pin. > >>> > >>> Hopefully by creating this driver it will be easier for vendors to > >>> finally fix their adapters and test the CEC functionality. > >>> > >>> I keep a list of known working adapters here: > >>> > >>> https://hverkuil.home.xs4all.nl/cec-status.txt > >>> > >>> Please mail me (hverkuil(a)xs4all.nl) if you find an adapter that works > >>> and is not yet listed there. > >>> > >>> Note that the current implementation does not support CEC over an MST hub. > >>> As far as I can see there is no mechanism defined in the DisplayPort > >>> standard to transport CEC interrupts over an MST device. It might be > >>> possible to do this through polling, but I have not been able to get that > >>> to work. > >>> ---------------------------------------------------------------------- > >>> > >>> I really hope that this work will provide an incentive for vendors to > >>> finally connect the CEC pin. It's a shame that there are so few adapters > >>> that work (I found only two USB-C to HDMI adapters that work, and no > >>> (mini-)DP to HDMI adapters at all). > >>> > >>> Hopefully if this gets merged there will be an incentive for vendors > >>> to make adapters where this actually works. It is a very nice feature > >>> for HTPC boxes. > >>> > >>> The main reason why this v5 is delayed by 2 months is due to the fact > >>> that I needed some dedicated time to investigate what happens when an > >>> MST hub is in use. It turns out that this is not working. There is no > >>> mechanism defined in the DisplayPort standard to transport the CEC > >>> interrupt back up the MST chain. I was actually able to send a CEC > >>> message but the interrupt that tells when the transmit finished is > >>> unavailable. > >>> > >>> I attempted to implement this via polling, but I got weird errors > >>> and was not able to read the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 > >>> register. I decided to give up on this for now and just disable CEC > >>> for DP-to-HDMI adapters after an MST hub. I plan to revisit this > >>> later since it would be neat to make this work as well. Although it > >>> might not be possible at all. > >>> > >>> If anyone is interested, work-in-progress for this is here: > >>> > >>> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dp-cec-mst > >>> > >>> Note that I removed the Tested-by tag from Carlos Santa due to the > >>> almost complete rework of the third patch. Carlos, can you test this again? > >>> > >>> Regards, > >>> > >>> Hans > >>> > >>> Changes since v4: > >>> > >>> - Updated comment at the start of drm_dp_cec.c > >>> - Add edid pointer to drm_dp_cec_configure_adapter > >>> - Reworked the last patch (adding CEC to i915) based on Ville's comments > >>> and my MST testing: > >>> - register/unregister CEC in intel_dp_connector_register/unregister > >>> - add comment and check if connector is registered in long_pulse > >>> - unregister CEC if an MST 'connector' is detected. > >>> > >>> _______________________________________________ > >>> dri-devel mailing list > >>> dri-devel(a)lists.freedesktop.org > >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >>> > >> > >> _______________________________________________ > >> dri-devel mailing list > >> dri-devel(a)lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > >> > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel(a)lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > _______________________________________________ > dri-devel mailing list > dri-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC

2 7

[PATCH][V2] drm/i915/guc: fix GEM_BUG_ON check
by Colin King 12 Jun '18

12 Jun '18

From: Colin Ian King <colin.king(a)canonical.com> The check for level being less than zero always false because flags is currently unsigned and can never be negative. Fix this by making flags a s32. Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- V2: Make flags s32 rather than remove the GEM_BUG_ON check, thanks to Ville Syrjälä for spotting the mistake in my first attempt. --- drivers/gpu/drm/i915/intel_guc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 116f4ccf1bbd..fb31f5004bcf 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -206,7 +206,7 @@ void intel_guc_fini(struct intel_guc *guc) static u32 get_log_control_flags(void) { u32 level = i915_modparams.guc_log_level; - u32 flags = 0; + s32 flags = 0; GEM_BUG_ON(level < 0); -- 2.17.0

3 2

[PULL] drm-misc-fixes
by Maarten Lankhorst 12 Jun '18

12 Jun '18

Hey, Only the qxl fix by Jeremy Cline is new. The rest has landed in v4.17 already. drm-misc-fixes-2018-06-12: Only a small qxl fix that was queued for v4.17. The following changes since commit 9a0e9802217291e54c4dd1fc5462f189a4be14ec: drm/vc4: Fix scaling of uni-planar formats (2018-05-09 09:48:23 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-06-12 for you to fetch changes up to 889ad63d41eea20184b0483e7e585e5b20fb6cfe: drm/qxl: Call qxl_bo_unref outside atomic context (2018-06-04 09:31:39 +0200) ---------------------------------------------------------------- Only a small qxl fix that was queued for v4.17. ---------------------------------------------------------------- Dan Carpenter (1): drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl() Dhinakaran Pandiyan (1): drm/psr: Fix missed entry in PSR setup time table. Eric Anholt (1): drm/vc4: Fix leak of the file_priv that stored the perfmon. Haneen Mohammed (1): drm: Match sysfs name in link removal to link creation Jeremy Cline (1): drm/qxl: Call qxl_bo_unref outside atomic context Neil Armstrong (1): drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense Tomi Valkeinen (1): drm/omap: fix NULL deref crash with SDI displays drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 ++++----------- drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/drm_drv.c | 2 +- drivers/gpu/drm/drm_dumb_buffers.c | 7 ++++--- drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +- drivers/gpu/drm/omapdrm/dss/sdi.c | 5 ++++- drivers/gpu/drm/qxl/qxl_display.c | 7 +++++-- drivers/gpu/drm/vc4/vc4_drv.c | 1 + include/drm/bridge/dw_hdmi.h | 2 +- 9 files changed, 22 insertions(+), 20 deletions(-)

1 0

[Bug 106871] Screen with blank cursor (raven ridge on MSI B350)
by bugzilla-daemon＠freedesktop.org 12 Jun '18

12 Jun '18

https://bugs.freedesktop.org/show_bug.cgi?id=106871 Bug ID: 106871 Summary: Screen with blank cursor (raven ridge on MSI B350) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: keverik(a)gmail.com Created attachment 140110 --> https://bugs.freedesktop.org/attachment.cgi?id=140110&action=edit xorg loggings with the problem After upgrading my debian stable with a (i assumed) a nice cpu with graphics AMD 2200G, it did not work, only in VESA mode. I upgrade to unstable/sed and now have a non working system with default settings. For me it is not clear, where the problem is (kernel or amdgpu), but maybe you can help me with steps to get it clear. This are the warnings and errors: [ 9.874] (WW) AMDGPU(0): No outputs definitely connected, trying again... [ 9.874] (WW) AMDGPU(0): Unable to find connected outputs - setting 1024x768 initial framebuffer [ 9.874] (EE) AMDGPU(0): No modes. [ 9.874] (EE) Screen(s) found, but none have a usable configuration. I have attached the following info: * lshw -c video * dmesg * /var/log/Xorg.0.log * lsmod | grep amdgpu after boot. I boot with kernel 4.16, to get a working VESA driver I use the "nomodeset" flag on the kernel arguments. What I also don't understand is why the system doesn't fallback on the VESA driver? Thanks already a lot! -- You are receiving this mail because: You are the assignee for the bug.

1 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2018