dri-devel January 2017

dri-devel@lists.freedesktop.org

240 participants
1484 discussions

[PATCH 01/10] drm : adds Y-coordinate and Colorimetry Format
by vathsala nagaraju 02 Jan '17

02 Jan '17

PSR2 vsc revision number hb2( as per table 6-11)is updated to 4 or 5 based on Y cordinate and Colorimetry Format as below 04h = 3D stereo + PSR/PSR2 + Y-coordinate. 05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry Format indication. A DP Source device is allowed to indicate the pixel encoding/colorimetry format to the DP Sink device with VSC SDP only when the DP Sink device supports it ( i.e.,VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the DPRX_FEATURE_ENUMERATION_LIST register (DPCD Address 02210h, bit 3; is set to 1). v2: (Jani) - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED. - Add DP_PSR2_SU_GRANULARITY_REQUIRED. - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX. - Add GTC_CAP and AV_SYNC_CAP, other bits in DPRX_FEATURE_ENUMERATION_LIST. v3: (Jani) - Add support for bits 7:4 and 1 as per DP v1.4 for DPRX_FEATURE_ENUMERATION_LIST. Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Jim Bride <jim.bride(a)linux.intel.com> Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju(a)intel.com> Signed-off-by: Patil Deepti <deepti.patil(a)intel.com> --- include/drm/drm_dp_helper.h | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 55bbeb0..0468135 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -194,7 +194,8 @@ # define DP_PSR_SETUP_TIME_0 (6 << 1) # define DP_PSR_SETUP_TIME_MASK (7 << 1) # define DP_PSR_SETUP_TIME_SHIFT 1 - +# define DP_PSR2_SU_Y_COORDINATE_REQUIRED (1 << 4) /* eDP 1.4a */ +# define DP_PSR2_SU_GRANULARITY_REQUIRED (1 << 5) /* eDP 1.4b */ /* * 0x80-0x8f describe downstream port capabilities, but there are two layouts * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, @@ -568,6 +569,16 @@ #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) +#define DP_DPRX_FEATURE_ENUMERATION_LIST 0x2210 /* DP 1.3 */ +# define DP_GTC_CAP (1 << 0) /* DP 1.3 */ +# define DP_SST_SPLIT_SDP_CAP (1 << 1) /* DP 1.4 */ +# define DP_AV_SYNC_CAP (1 << 2) /* DP 1.3 */ +# define DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED (1 << 3) /* DP 1.3 */ +# define DP_VSC_EXT_VESA_SDP_SUPPORTED (1 << 4) /* DP 1.4 */ +# define DP_VSC_EXT_VESA_SDP_CHAINING_SUPPORTED (1 << 5) /* DP 1.4 */ +# define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */ +# define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */ + /* DP 1.2 Sideband message defines */ /* peer device type - DP 1.2a Table 2-92 */ #define DP_PEER_DEVICE_NONE 0x0 -- 1.9.1

3 2

[PATCH 01/17] drm/docs: Small cleanup in drm-uapi.rst
by Daniel Vetter 02 Jan '17

02 Jan '17

- Remove the outdated hunk about driver documentation which somehow got misplaced here in the split-up. - Collect all the testing&validation stuff together and give the CRC section a heading for prettier output. Cc: Tomeu Vizoso <tomeu.vizoso(a)collabora.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- Documentation/gpu/drm-uapi.rst | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index de3ac9f90f8f..fcc228ef5bc4 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -156,8 +156,12 @@ other hand, a driver requires shared state between clients which is visible to user-space and accessible beyond open-file boundaries, they cannot support render nodes. + +Testing and validation +====================== + Validating changes with IGT -=========================== +--------------------------- There's a collection of tests that aims to cover the whole functionality of DRM drivers and that can be used to check that changes to DRM drivers or the @@ -193,6 +197,12 @@ run-tests.sh is a wrapper around piglit that will execute the tests matching the -t options. A report in HTML format will be available in ./results/html/index.html. Results can be compared with piglit. +Display CRC Support +------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c + :doc: CRC ABI + VBlank event handling ===================== @@ -209,16 +219,3 @@ DRM_IOCTL_MODESET_CTL mode setting, since on many devices the vertical blank counter is reset to 0 at some point during modeset. Modern drivers should not call this any more since with kernel mode setting it is a no-op. - -This second part of the GPU Driver Developer's Guide documents driver -code, implementation details and also all the driver-specific userspace -interfaces. Especially since all hardware-acceleration interfaces to -userspace are driver specific for efficiency and other reasons these -interfaces can be rather substantial. Hence every driver has its own -chapter. - -Testing and validation -====================== - -.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c - :doc: CRC ABI -- 2.7.4

7 29

[PATCH] drm/doc: Document uapi requirements in DRM
by Daniel Vetter 02 Jan '17

02 Jan '17

Everyone knows them, except all the new folks joining from the ARM side haven't lived through all the pain of the past years and are entirely surprised when I raise this. Definitely time to document this. Last time this was a big discussion was about 6 years ago, when qcom tried to land a kernel driver without userspace. Dave Airlie made the rules really clear: http://airlied.livejournal.com/73115.html This write-up here is essentially what I've put into a presentation a while ago, which was also reviewed by Dave: http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html Cc: Dave Airlie <airlied(a)gmail.com> Cc: Oded Gabbay <oded.gabbay(a)gmail.com> Cc: Russell King <rmk+kernel(a)armlinux.org.uk> Cc: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Cc: Eric Anholt <eric(a)anholt.net> Cc: Thomas Hellstrom <thellstrom(a)vmware.com> Cc: Sinclair Yeh <syeh(a)vmware.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Mark Yao <mark.yao(a)rock-chips.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: Rob Clark <robdclark(a)gmail.com> Cc: CK Hu <ck.hu(a)mediatek.com> Cc: Xinliang Liu <z.liuxinliang(a)hisilicon.com> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Stefan Agner <stefan(a)agner.ch> Cc: Inki Dae <inki.dae(a)samsung.com> Cc: Maxime Ripard <maxime.ripard(a)free-electrons.com> Cc: Boris Brezillon <boris.brezillon(a)free-electrons.com> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Brian Starkey <brian.starkey(a)arm.com> Cc: Liviu Dudau <liviu.dudau(a)arm.com> Cc: Alexey Brodkin <abrodkin(a)synopsys.com> Acked-by: Dave Airlie <airlied(a)gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- Documentation/gpu/drm-uapi.rst | 67 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 94876938aef3..a7e3aa27167d 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -36,6 +36,73 @@ Primary Nodes, DRM Master and Authentication Open-Source Userspace Requirements ================================== +The DRM subsystem has stricter requirements on what the userspace side for new +uAPI needs to look like. This section here explains what exactly those +requirements are, and why they exist. + +The short summary is that any addition of DRM uAPI requires corresponding +open-sourced userspace patches, and those patches must be reviewed and ready for +merging into a suitable and canonical upstream project. + +GFX devices (both display and render/GPU side) are really complex bits of hardware, +with userspace and kernel by necessity having to work together really closely. +The interfaces, for rendering and modesetting must be extremely wide and +flexible, and therefore it is almost always impossible to precisely define them +for every possible corner case. This in turns makes it really practically +infeasible to differentiate between behaviour that's required by userspace, and +which must not be changed to avoid regressions, and behaviour which is only an +accidental artifact of the current implementation. + +Without access to the full source code of all userspace users that means it +becomes impossible to change the implementation details, since userspace could +depend upon the accidental behaviour of the current implementation in minute +details. And debugging such regressions without access to source code is pretty +much impossible. As a consequence this means: + +- The Linux kernel's "no regression" policy holds in practice only for + open-source userspace of the DRM subsystem. DRM developers are perfectly fine + if closed-source blob drivers in userspace use the same uAPI as the open + drivers, but they must do so in the exact same way as the open drivers. + Creative (ab)use of the interfaces will, and in the past routinely has, lead + to breakage. + +- Any new userspace interface must have an open-source implementation as + demonstration vehicle. + +The other reason for requiring open-source userspace is uAPI review. Since the +kernel and userspace parts of a GFX stack must work together so closely, code +review can only assess whether a new interface achieves its goals by looking at +both sides. Making sure that the interface indeed covers the use-case fully +leads to a few additional requirements: + +- The open-source userspace must not be a toy/test application, but the real + thing. Specifically it needs to handle all the usual error and corner cases. + These are often the places where new uAPI falls apart and hence essential to + assess the fitness of a proposed interface. + +- The userspace side must be fully reviewed and tested to the standards of that + userspace project. For e.g. mesa this means piglit testcases and review on the + mailing list. This is again to ensure that the new interface actually gets the + job done. + +- The userspace patches must be against the canonical upstream, not some vendor + fork. This is to make sure that no one cheats on the review and testing + requirements by doing a quick fork. + +- The kernel patch can only be merged after all the above requirements are met, + but it **must** be merged **before** the userspace patches land. uAPI always flows + from the kernel, doing things the other way round risks divergence of the uAPI + definitions and header files. + +These are fairly steep requirements, but have grown out from years of shared +pain and experience with uAPI added hastily, and almost always regretted about +as fast. GFX devices change really fast, requiring a paradigm shift and entire +new set of uAPI interfaces every few years at least. Together with the Linux +kernel's guarantee to keep existing userspace running for 10+ years this is +already rather painful for the DRM subsystem, with multiple different uAPIs for +the same thing co-existing. If we'd add a few more complete mistakes into the +mix every year it would be entirely unmanagable. + Render nodes ============ -- 2.8.1

8 10

[Bug 99138] Xorg can't be restarted gracefully running CEDAR graphics card
by bugzilla-daemon＠freedesktop.org 01 Jan '17

01 Jan '17

https://bugs.freedesktop.org/show_bug.cgi?id=99138 --- Comment #3 from Arthur Marsh <arthur.marsh(a)internode.on.net> --- Created attachment 128698 --> https://bugs.freedesktop.org/attachment.cgi?id=128698&action=edit backtrace of Xorg after attempting service lxdm stop -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2017