[PATCH v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

Since USB connector bindings are available we can describe it on TM2(e). Signed-off-by: Andrzej Hajda --- arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi

[PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

OF graph describes MHL data lanes between MHL and respective USB connector. Signed-off-by: Andrzej Hajda --- v5: removed extra parenthesis (kbuild test robot) v4: added missing reg property in connector's port node (Krzysztof) ---

[PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

These bindings allow to describe most known standard USB connectors and it should be possible to extend it if necessary. USB connectors, beside USB can be used to route other protocols, for example UART, Audio, MHL. In such case every device passing data through the connector should have

[PATCH v5 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector

Samsung micro-USB 11-pin connector beside standard micro-USB pins, has pins dedicated to route MHL traffic. Signed-off-by: Andrzej Hajda Reviewed-by: Rob Herring --- v4: - removed description of property inherited from usb-connector (Rob), - fixed example

[PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

From: Maciej Purski Currently MHL chip must be turned on permanently to detect MHL cable. It duplicates micro-USB controller's (MUIC) functionality and consumes unnecessary power. Lets use extcon attached to MUIC to enable MHL chip only if it detects MHL cable.

[PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

Hi, Thanks for reviews of previous iterations. This patchset introduces USB physical connector bindings, together with working example. I have removed RFC prefix - the patchset seems to be heading to a happy end :) v5: fixed extra parenthesis in dts, renamed extcon function. v4: improved

[PATCH v5 5/6] extcon: add possibility to get extcon device by OF node

Since extcon property is not allowed in DT, extcon subsystem requires another way to get extcon device. Lets try the simplest approach - get edev by of_node. Signed-off-by: Andrzej Hajda Acked-by: Chanwoo Choi --- v5: function renamed to

Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote: > Hi Jernej, > > On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec > wrote: > > Hi, > > > > Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng > > napisal(a): > >> 于 2018年2月27日 GMT+08:00

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

On 26.02.2018 16:21, Krzysztof Kozlowski wrote: > On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda wrote: >> OF graph describes MHL data lanes between MHL and respective USB >> connector. >> >> Signed-off-by: Andrzej Hajda >> --- >> v4: >> - added missing

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/27/2018 01:47 AM, Boris Ostrovsky wrote: On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: +static struct xen_gem_object *gem_create(struct drm_device *dev, size_t size) +{ +

Re: [PATCH 0/7] drm/virtio: Checkpatch cleanup for virtio

On Thu, Feb 22, 2018 at 08:59:33PM -0300, Rodrigo Siqueira wrote: > This patchset fixes warnings and errors found by checkpatch.pl in the > drm/virtio: Added to drm-qemu queue, will land in drm-misc soon. thanks, Gerd ___ dri-devel mailing list

[radeon-alex:drm-next-4.17-wip 390/390] drivers/gpu//drm/amd/amdgpu/si_dpm.c:7317:29: error: 'CAIL_PCIE_LINK_SPEED_SUPPORT_MASK' undeclared; did you mean 'LC_TARGET_LINK_SPEED_OVERRIDE_MASK'?

tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip head: 1d0e528594e2040c6c208be32bad4ad57437aabb commit: 1d0e528594e2040c6c208be32bad4ad57437aabb [390/390] drm/amdgpu: used cached pcie gen info for SI config: powerpc64-allyesconfig (attached as .config) compiler:

[radeon-alex:drm-next-4.17-wip 390/390] drivers/gpu/drm/amd/amdgpu/si.c:1500:34: error: 'CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2' undeclared

tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip head: 1d0e528594e2040c6c208be32bad4ad57437aabb commit: 1d0e528594e2040c6c208be32bad4ad57437aabb [390/390] drm/amdgpu: used cached pcie gen info for SI config: x86_64-randconfig-u0-02271135 (attached as .config) compiler:

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

On 02/22/2018 01:16 PM, Alex Deucher wrote: On Thu, Feb 22, 2018 at 1:49 PM, Bas Nieuwenhuizen wrote: On Thu, Feb 22, 2018 at 7:04 PM, Kristian Høgsberg wrote: On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher wrote: On Wed,

Re: [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin wrote: > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala > wrote: >> From: Ville Syrjälä >> >> Replace the ad-hoc iturbt_709 property with the new standard >>

[Bug 105018] Kernel panic when waking up after screen goes blank.

https://bugs.freedesktop.org/show_bug.cgi?id=105018 --- Comment #21 from L.S.S. --- Another problem: When I woke up the screen, sometimes the system would have intermittent soft lockups that made the system kind of unusable... This is after I included the patch to the

[radeon-alex:amd-staging-drm-next 699/715] sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'; did you mean 'pci_enable_sriov'?

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 1dec943aa3f9e9a9c39559851239e382ad1e436c commit: 944b5289c92d9c1aad3760c012daf4cf2478381f [699/715] ASoC: AMD: enable ACP3x drivers build config: sh-allmodconfig (attached as .config) compiler: sh4-linux-gnu-gcc

[Bug 104064] (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=104064 --- Comment #5 from Bjorn --- I certainly wouldn't mind. I've never really done anything of the sort before however, so is there an easy way for me to set it up? For reference, I'm on Ubuntu 17.10 and while I know my way

[Bug 105256] Slow performance using glDrawElements calls with GL_UNSIGNED_BYTE indices

https://bugs.freedesktop.org/show_bug.cgi?id=105256 Logan McNaughton changed: What|Removed |Added Status|RESOLVED|REOPENED

Re: [PATCH 12/15] drm/sun4i: Allow building on arm64

Hi Jernej, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20180226] [cannot apply to robh/for-next v4.16-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

On 02/26/2018 09:07 AM, Shuah Khan wrote: On 02/19/2018 11:33 AM, Daniel Vetter wrote: On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote: On 02/19/2018 07:31 AM, Daniel Vetter wrote: On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote: Ion is designed to be a framework

[Bug 104142] Stack trace in runpm when Tonga card powers down

https://bugs.freedesktop.org/show_bug.cgi?id=104142 --- Comment #8 from Harry Wentland --- Thanks for the update. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 104142] Stack trace in runpm when Tonga card powers down

https://bugs.freedesktop.org/show_bug.cgi?id=104142 Mike Lothian changed: What|Removed |Added Resolution|--- |FIXED

[Bug 104200] [Vega10] suspend hangs on Vega 64

https://bugs.freedesktop.org/show_bug.cgi?id=104200 --- Comment #3 from Harry Wentland --- We have a few new patches in our staging trees relating to suspend and driver unload. Would you be able to try syncing amd-staging-drm-next and see if the issue has been fixed? --

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

https://bugzilla.kernel.org/show_bug.cgi?id=197925 Harry Wentland (harry.wentl...@amd.com) changed: What|Removed |Added CC|

[Bug 104142] Stack trace in runpm when Tonga card powers down

https://bugs.freedesktop.org/show_bug.cgi?id=104142 --- Comment #6 from Harry Wentland --- We have a few new patches in our staging trees relating to suspend and driver unload. Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from

[Bug 105256] Slow performance using glDrawElements calls with GL_UNSIGNED_BYTE indices

https://bugs.freedesktop.org/show_bug.cgi?id=105256 Roland Scheidegger changed: What|Removed |Added Summary|Slow performance using |Slow

[Bug 104064] (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=104064 --- Comment #4 from Harry Wentland --- We have a few new patches in our staging trees relating to suspend and driver unload. Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from

Google Summer of Code 2018

Hi everyone, Just a quick word to remind you that the X.Org Foundation got accepted to the Google Summer of Code 2018! As a potential mentor, if you have a project falling under the foundation's (large) umbrella that you would like to kick start or get help finishing, please add it to the list

[Bug 105083] Random blinking display

https://bugs.freedesktop.org/show_bug.cgi?id=105083 --- Comment #10 from Harry Wentland --- We have some patches that rework our gamma programming in our staging trees. Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from

[Bug 104825] [amdgpu] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed (scratch(0xC040)=0x00000000) when unbinding

https://bugs.freedesktop.org/show_bug.cgi?id=104825 --- Comment #4 from Harry Wentland --- Good to hear DC issues are gone. Not sure about the unlock balance myself. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 0/5] HDCP1.4 fixes

On Mon, Feb 26, 2018 at 10:42:34PM +0530, Ramalingam C wrote: > This series addresses the requriement of below HDCP compliance tests > DP: 1A-06 and 1B-05 > HDMI: 1A-04 and 1A-07a > > One of the patch uses the I915 power infra-structure for checking > the power state of PW#1. Which

[Bug 105039] No 120hz with 4.15 kernel and DC enabled

https://bugs.freedesktop.org/show_bug.cgi?id=105039 --- Comment #4 from Emanuel Couto --- (In reply to Harry Wentland from comment #3) > This should be fixed in our staging branches. > > Can you try either the amd-staging-drm-next or drm-next-4.17-wip branch from > Alex's

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

Quoting Ramalingam C (2018-02-26 17:12:39) > DP and HDMI HDCP specifications are varying with respect to > detecting the R0 and ksv_fifo availability. > > DP will produce CP_IRQ and set a bit for indicating the R0 and > FIFO_READY status. > > Whereas HDMI will set a bit for FIFO_READY but there

[Bug 105262] ttf fonts are invisible

https://bugs.freedesktop.org/show_bug.cgi?id=105262 --- Comment #1 from Pavel Vinogradov --- Created attachment 137623 --> https://bugs.freedesktop.org/attachment.cgi?id=137623=edit Xorg.log Xorg.log with today's build of mesa from git. -- You are receiving this mail

[Bug 105262] ttf fonts are invisible

https://bugs.freedesktop.org/show_bug.cgi?id=105262 Bug ID: 105262 Summary: ttf fonts are invisible Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: normal

[PATCH 15/15] v4l: vsp1: Rename BRU to BRx

Some VSP instances have two blending units named BRU (Blend/ROP Unit) and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU with only two inputs, but otherwise offers similar features and offers the same register interface. The BRU and BRS can be used exchangeably in VSP pipelines

[PATCH 13/15] v4l: vsp1: Assign BRU and BRS to pipelines dynamically

The VSPDL variant drives two DU channels through two LIF and two blenders, BRU and BRS. The DU channels thus share the five available VSPDL inputs and expose them as five KMS planes. The current implementation assigns the BRS to the second LIF and thus artificially limits the number of planes for

[PATCH 11/15] v4l: vsp1: Add per-display list completion notification support

Display list completion is already reported to the frame end handler, but that mechanism is global to all display lists. In order to implement BRU and BRS reassignment in DRM pipelines we will need to wait for completion of a particular display list. Extend the display list and frame end handler

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

https://bugs.freedesktop.org/show_bug.cgi?id=104274 --- Comment #10 from Jordan L --- Hi Luke, it actually looks like you're running with DC disabled. Can you also try with amdgpu.dc=1 explicitly set? Potentially there are issues in multiple IP blocks, though we fixed a

[PATCH 09/15] v4l: vsp1: Replace manual DRM pipeline input setup in vsp1_du_setup_lif

The vsp1_du_setup_lif() function setups the DRM pipeline input manually. This duplicates the code from the vsp1_du_pipeline_setup_input() function. Replace the manual implementation by a call to the function. As the pipeline has no enabled input in vsp1_du_setup_lif(), the

[PATCH 08/15] v4l: vsp1: Setup BRU at atomic commit time

To implement fully dynamic plane assignment to pipelines, we need to reassign the BRU and BRS to the DRM pipelines in the atomic commit handler. In preparation for this setup factor out the BRU source pad code and call it both at LIF setup and atomic commit time. Signed-off-by: Laurent Pinchart

[PATCH 14/15] v4l: vsp1: Add BRx dynamic assignment debugging messages

Dynamic assignment of the BRU and BRS to pipelines is prone to regressions, add messages to make debugging easier. Keep it as a separate commit to ease removal of those messages once the code will deem to be completely stable. Signed-off-by: Laurent Pinchart

[PATCH 06/15] v4l: vsp1: Share duplicated DRM pipeline configuration code

Move the duplicated DRM pipeline configuration code to a function and call it from vsp1_du_setup_lif() and vsp1_du_atomic_flush(). Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_drm.c | 95 +++--- 1

[PATCH 12/15] v4l: vsp1: Generalize detection of entity removal from DRM pipeline

When disabling a DRM plane, the corresponding RPF is only marked as removed from the pipeline in the atomic update handler, with the actual removal happening when configuring the pipeline at atomic commit time. This is required as the RPF has to be disabled in the hardware, which can't be done

[PATCH 07/15] v4l: vsp1: Move DRM atomic commit pipeline setup to separate function

The DRM pipeline setup code used at atomic commit time is similar to the setup code used when enabling the pipeline. Move it to a separate function in order to share it. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_drm.c | 347

[PATCH 05/15] v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a pipeline

The DRM pipeline handling code uses the entity's pipe list head to check whether the entity is already included in a pipeline. This method is a bit fragile in the sense that it uses list_empty() on a list_head that is a list member. Replace it by a simpler check for the entity pipe pointer.

[PATCH 10/15] v4l: vsp1: Move DRM pipeline output setup code to a function

In order to make the vsp1_du_setup_lif() easier to read, and for symmetry with the DRM pipeline input setup, move the pipeline output setup code to a separate function. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_drm.c | 107

[PATCH 01/15] v4l: vsp1: Don't start/stop media pipeline for DRM

The DRM support code manages a pipeline of VSP entities, each backed by a media entity. When starting or stopping the pipeline, it starts and stops the media pipeline through the media API in order to store the pipeline pointer in every entity. The driver doesn't use the pipe pointer in media

[PATCH 00/15] R-Car VSP1: Dynamically assign blend units to display pipelines

Hello, On R-Car H3 ES2.0+ and M3-N SoCs, two display pipelines are served by the same VSP instance (named VSPDL). The VSPDL includes two blending units named BRU and BRS, unlike the other display-related VSPD that serves a single display channel with a single blending unit. The VSPDL has five

[PATCH 03/15] v4l: vsp1: Remove unused field from vsp1_drm_pipeline structure

The vsp1_drm_pipeline enabled field is set but never used. Remove it. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_drm.c | 4 drivers/media/platform/vsp1/vsp1_drm.h | 2 -- 2 files changed, 6 deletions(-) diff --git

[PATCH 04/15] v4l: vsp1: Store pipeline pointer in vsp1_entity

Various types of objects subclassing vsp1_entity currently store a pointer to the pipeline. Move the pointer to vsp1_entity to simplify the code and avoid storing the pipeline in more entity subclasses later. Signed-off-by: Laurent Pinchart ---

[PATCH 02/15] v4l: vsp1: Remove outdated comment

The entities in the pipeline are all started when the LIF is setup. Remove the outdated comment that state otherwise. Signed-off-by: Laurent Pinchart --- drivers/media/platform/vsp1/vsp1_drm.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-)

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

https://bugs.freedesktop.org/show_bug.cgi?id=103234 --- Comment #13 from Roman Gilg --- GDB output near to current master (at 8d1f1ce412, later does not compile on my system at the moment): Thread 17 "gallium_drv:0" received signal SIGSEGV, Segmentation fault. [Switching to

[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups

https://bugs.freedesktop.org/show_bug.cgi?id=101672 --- Comment #24 from MirceaKitsune --- I can confirm that the exact same system freeze happens with both the radeon and amdgpu driver: Using either module makes absolutely no difference. This is the last

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=105257 --- Comment #5 from Ivan Levshin --- Hi Mathias, Thanks for your comment. So it looks like a Mesa bug, will check if downgrade helps. Anyway I'd like to get a fix for actual Mesa version. -- You are receiving this mail

[Bug 105256] Slow performance using glDrawElementsBaseVertex

https://bugs.freedesktop.org/show_bug.cgi?id=105256 Roland Scheidegger changed: What|Removed |Added Resolution|NOTABUG |FIXED ---

[Bug 105256] Slow performance using glDrawElementsBaseVertex

https://bugs.freedesktop.org/show_bug.cgi?id=105256 Logan McNaughton changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 105256] Slow performance using glDrawElementsBaseVertex

https://bugs.freedesktop.org/show_bug.cgi?id=105256 --- Comment #2 from Logan McNaughton --- Interesting, is this documented somewhere? How do you know what data formats the HW supports? Is there any other hardware besides these cards that don't support it? I'll have the

[Bug 105256] Slow performance using glDrawElementsBaseVertex

https://bugs.freedesktop.org/show_bug.cgi?id=105256 --- Comment #1 from Roland Scheidegger --- At a quick glance, I'd suspect the problem isn't really drawElementsBaseVertex per se, but the use of GL_UNSIGNED_BYTE indices as the code seemed to do. The hw doesn't support ubyte

Re: [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

Hi, On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul wrote: > This patch adds an override mode for kevin devices. The mode increases > both back porches to allow a pixel clock of 2kHz as opposed to the > 'typical' value of 252750kHz. This is needed to avoid interference with

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=105257 --- Comment #4 from Mathias Fröhlich --- If it helps: Same story on fedora 27 with a skylake system. Poor mens bisect on downgradable rpms show: Shows up somewhere between mesa-17.3.3-1.fc27 and mesa-17.3.5-1.fc27.

Re: [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

On Mon, Feb 26, 2018 at 10:42:39PM +0530, Ramalingam C wrote: > DP and HDMI HDCP specifications are varying with respect to > detecting the R0 and ksv_fifo availability. > > DP will produce CP_IRQ and set a bit for indicating the R0 and > FIFO_READY status. I'm not sure what the benefit is?

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=105257 --- Comment #3 from Ivan Levshin --- Created attachment 137614 --> https://bugs.freedesktop.org/attachment.cgi?id=137614=edit Presentation sample -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 4/5] drm/i915: Poll hdcp register on sudden NACK

On Mon, Feb 26, 2018 at 10:42:38PM +0530, Ramalingam C wrote: > In a connected state, If a HDMI HDCP sink is responded with NACK for > HDCP I2C register access, then HDMI HDCP spec mandates the polling > of any HDCP space registers for accessibility, minimum once in 2Secs > atleast for 4Secs. >

Re: [PATCH 3/5] drm/i915: Check hdcp key loadability

On Mon, Feb 26, 2018 at 10:42:37PM +0530, Ramalingam C wrote: > HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk > is enabled. Using the I915 power well infrastruture, above requirement > is verified. > > This patch enables the hdcp initialization for HSW, BDW, and BXT. >

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=105257 --- Comment #2 from Ivan Levshin --- Created attachment 137613 --> https://bugs.freedesktop.org/attachment.cgi?id=137613=edit Output of "xrandr --verbose" -- You are receiving this mail because: You are the assignee

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=105257 --- Comment #1 from Ivan Levshin --- Created attachment 137612 --> https://bugs.freedesktop.org/attachment.cgi?id=137612=edit Output of "cat /sys/class/drm/card0/error" -- You are receiving this mail because: You are

[Bug 105257] GPU HANG: ecode 9:0:0x86dffffd, in Xorg, reason: Hang on render ring, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=105257 Bug ID: 105257 Summary: GPU HANG: ecode 9:0:0x86dd, in Xorg, reason: Hang on render ring, action: reset Product: Mesa Version: unspecified Hardware: Other

Re: [PATCH 2/5] drm/i915: read Vprime thrice incase of mismatch

On Mon, Feb 26, 2018 at 10:42:36PM +0530, Ramalingam C wrote: > In case of V prime mismatch, DP HDCP spec mandates the re-read of > Vprime atleast twice. > > DP HDCP CTS Test: 1B-05 > > Signed-off-by: Ramalingam C > --- > drivers/gpu/drm/i915/intel_hdcp.c | 10

Re: [PATCH 1/5] drm/i915: Read HDCP R0 thrice in case of mismatch

On Mon, Feb 26, 2018 at 10:42:35PM +0530, Ramalingam C wrote: > As per DP spec when R0 mismatch is detected, HDCP source supported > re-read the R0 atleast twice. > > And For HDMI and DP minimum wait required for the R0 availability is > 100mSec. So this patch changes the wait time to 100mSec but

[PATCH 5/5] drm/i915: Move hdcp msg detection into shim

DP and HDMI HDCP specifications are varying with respect to detecting the R0 and ksv_fifo availability. DP will produce CP_IRQ and set a bit for indicating the R0 and FIFO_READY status. Whereas HDMI will set a bit for FIFO_READY but there is no bit indication for R0 ready. And also polling of

[PATCH 0/5] HDCP1.4 fixes

This series addresses the requriement of below HDCP compliance tests DP: 1A-06 and 1B-05 HDMI: 1A-04 and 1A-07a One of the patch uses the I915 power infra-structure for checking the power state of PW#1. Which enables the init path for all legacy platforms. And encoder specific

[PATCH 4/5] drm/i915: Poll hdcp register on sudden NACK

In a connected state, If a HDMI HDCP sink is responded with NACK for HDCP I2C register access, then HDMI HDCP spec mandates the polling of any HDCP space registers for accessibility, minimum once in 2Secs atleast for 4Secs. Just to make it simple, this is generically implemented for both HDMI and

[PATCH 2/5] drm/i915: read Vprime thrice incase of mismatch

In case of V prime mismatch, DP HDCP spec mandates the re-read of Vprime atleast twice. DP HDCP CTS Test: 1B-05 Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/intel_hdcp.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH 3/5] drm/i915: Check hdcp key loadability

HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk is enabled. Using the I915 power well infrastruture, above requirement is verified. This patch enables the hdcp initialization for HSW, BDW, and BXT. Signed-off-by: Ramalingam C ---

[PATCH 1/5] drm/i915: Read HDCP R0 thrice in case of mismatch

As per DP spec when R0 mismatch is detected, HDCP source supported re-read the R0 atleast twice. And For HDMI and DP minimum wait required for the R0 availability is 100mSec. So this patch changes the wait time to 100mSec but retries twice with the time interval of 100mSec for each attempt. DP

Re: [PATCH 2/2] selftests: ion: Add simple test with the vgem driver

On 02/19/2018 11:33 AM, Daniel Vetter wrote: > On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote: >> On 02/19/2018 07:31 AM, Daniel Vetter wrote: >>> On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote: Ion is designed to be a framework used by other clients who perform

Re: [PATCH 1/2] selftests: ion: Remove some prints

On 02/15/2018 06:24 PM, Laura Abbott wrote: > There's no need to print messages each time we alloc and free. Remove them. > > Signed-off-by: Laura Abbott > --- > tools/testing/selftests/android/ion/ionutils.c | 6 -- > 1 file changed, 6 deletions(-) > > diff --git

Re: [RFC 0/1] Color space conversion uapi part2

On Mon, Feb 26, 2018 at 06:04:37PM +0200, Ville Syrjälä wrote: > On Mon, Feb 26, 2018 at 03:59:21PM +, Alexandru Gheorghe wrote: > > This is an attempt to revive the color space conversation that started > > here [1] and was materialized with the color encoding and color range > > properties

[Bug 105256] Slow performance using glDrawElementsBaseVertex

https://bugs.freedesktop.org/show_bug.cgi?id=105256 Bug ID: 105256 Summary: Slow performance using glDrawElementsBaseVertex Product: Mesa Version: 17.3 Hardware: Other OS: Linux (All) Status: NEW

[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)

https://bugs.freedesktop.org/show_bug.cgi?id=104285 --- Comment #8 from Alex Vorobyev --- I think it's not the same bug. CS:GO works on my system as it should, while SCS games still have broken shadows. -- You are receiving this mail because: You are the assignee for

Re: [PATCH libdrm 2/2] amdgpu: add AMDGPU_VA_RANGE_HIGH

For the series: Reviewed-by: Marek Olšák Marek On Mon, Feb 26, 2018 at 2:16 PM, Christian König wrote: > Return high addresses if requested and available. > > Signed-off-by: Christian König > --- >

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #22 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- I tried cold resets around 15 times (taking out the power cord) running lightdm manger or directly xinit and haven't seen any hang. Let me know your firmware versions - cat

[Bug 105244] NULL dereference during startup of Cape Verde with AMDGPU and GPU passthrough

https://bugs.freedesktop.org/show_bug.cgi?id=105244 --- Comment #1 from Alex Deucher --- Created attachment 137609 --> https://bugs.freedesktop.org/attachment.cgi?id=137609=edit possible fix This patch should fix it. -- You are receiving this mail because: You are the

Re: [RFC 0/1] Color space conversion uapi part2

On Mon, Feb 26, 2018 at 03:59:21PM +, Alexandru Gheorghe wrote: > This is an attempt to revive the color space conversation that started > here [1] and was materialized with the color encoding and color range > properties for converting YUV2RGB, the last version of this patch > series is here

[Bug 102323] [DC] System crashes when woken up from S3 sleep while HDMI display is switched off

https://bugs.freedesktop.org/show_bug.cgi?id=102323 --- Comment #5 from Harry Wentland --- Are you able to give Alex's amd-staging-drm-next or drm-next-4.17-wip branch from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next a try? -- You are receiving

[PATCH 1/1] [RFC] drm: Add per-plane color management

From: Mihail Atanassov Export drm_plane_enable_color_mgmt, which attaches the existing degamma, ctm, and gamma properties to a plane. Add a color_mgmt_changed flag to drm_plane_state, mimicking the drm_crtc_state flag of the same name. Signed-off-by: Mihail Atanassov

[RFC 0/1] Color space conversion uapi part2

This is an attempt to revive the color space conversation that started here [1] and was materialized with the color encoding and color range properties for converting YUV2RGB, the last version of this patch series is here [2]. However, we still need a way of specifing the color gamut and transfer

Re: [PATCH v5 8/9] drm: Add aspect ratio parsing in DRM layer

On Mon, Feb 26, 2018 at 09:18:57PM +0530, Nautiyal, Ankit K wrote: > > > On 2/23/2018 8:24 PM, Ville Syrjälä wrote: > > On Thu, Feb 15, 2018 at 05:51:01PM +0530, Nautiyal, Ankit K wrote: > >> From: "Sharma, Shashank" > >> > >> Current DRM layer functions don't parse

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #15 from Harry Wentland --- Please open a separate ticket for the issue with amd-stg and the 2nd monitor, including * dmesg log with amdgpu.dc_log=1 and drm.debug=0x6 kernel options * model of both monitors

Re: [PATCH v5 8/9] drm: Add aspect ratio parsing in DRM layer

On 2/23/2018 8:24 PM, Ville Syrjälä wrote: On Thu, Feb 15, 2018 at 05:51:01PM +0530, Nautiyal, Ankit K wrote: From: "Sharma, Shashank" Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919 --- Comment #14 from Thomas R. --- Harry, I tried amd-staging-drm-next and there is no corruption on the primary, but my second monitor is dead. It may be something like bug #91202 or something else entirely,

Re: [PATCH] drm: Include the header with the prototype for drm_get_panel_orientation_quirk()

On Mon, Feb 26, 2018 at 03:35:34PM +0100, Hans de Goede wrote: > Hi, > > On 26-02-18 15:24, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > sparse complains: > > drivers/gpu/drm/drm_panel_orientation_quirks.c:133:5: warning: symbol > >

Re: [RFC 4/4] drm/msm/mdp5: writeback support

On Fri, Feb 23, 2018 at 01:15:54PM -0500, Rob Clark wrote: > On Fri, Feb 23, 2018 at 11:30 AM, Sean Paul wrote: > > On Fri, Feb 23, 2018 at 08:17:54AM -0500, Rob Clark wrote: > >> In a way, based on the original writeback patch from Jilai Wang, but a > >> lot has shifted

Re: [PATCH v5 7/9] drm: Expose modes with aspect ratio, only if requested

On 2/23/2018 8:06 PM, Ville Syrjälä wrote: On Thu, Feb 15, 2018 at 05:51:00PM +0530, Nautiyal, Ankit K wrote: From: Ankit Nautiyal We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regadless

[Bug 105039] No 120hz with 4.15 kernel and DC enabled

https://bugs.freedesktop.org/show_bug.cgi?id=105039 --- Comment #3 from Harry Wentland --- This should be fixed in our staging branches. Can you try either the amd-staging-drm-next or drm-next-4.17-wip branch from Alex's repo. You can find it at

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda wrote: > OF graph describes MHL data lanes between MHL and respective USB > connector. > > Signed-off-by: Andrzej Hajda > --- > v4: > - added missing reg property in connector's port node (Krzysztof) > --- >

[Bug 105163] *-symbol-checks hard-code the nm executable

https://bugs.freedesktop.org/show_bug.cgi?id=105163 Eric Engestrom changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH v5 6/9] drm: Handle aspect ratio info in legacy and atomic modeset paths

Hi Ville, I agree to all the comments here, and will correct the required things in the next patch-set. On 2/23/2018 7:58 PM, Ville Syrjälä wrote: On Thu, Feb 15, 2018 at 05:50:59PM +0530, Nautiyal, Ankit K wrote: From: Ankit Nautiyal If the user-space does not

  1   2   >