[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).

https://bugs.freedesktop.org/show_bug.cgi?id=99403 --- Comment #10 from Roman Elshin --- so it may be closed? p.s. thanks a lot to all participated -- You are receiving this mail because: You are the assignee for the bug.___

[Bug 106471] Radeon HD 3450 acceleration not working

https://bugs.freedesktop.org/show_bug.cgi?id=106471 --- Comment #2 from Joshua Cogliati --- The other video card is integrated into the motherboard, and the disabling the integrated video with bios causes the boot to fail. I could try the video card in a different

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #197 from Sandeep --- Anyway, thanks for fixing the bug, AMD devs! (or whoever else did it). -- You are receiving this mail because: You are the assignee for the

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #196 from Sandeep --- Ah, I didn't know that. I thought it just disabled/enabled dpm...well, it works so that's good. It would be great if it worked out of the box though, without having to add kernel

[Bug 106287] 18.0.1 introduced glitches in Dying Light

https://bugs.freedesktop.org/show_bug.cgi?id=106287 --- Comment #3 from stu...@gmail.com --- This is fixed in 15.0.3 on my machine. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #195 from Alex Deucher --- (In reply to Sandeep from comment #194) > So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when > testing earlier. > > I tried using them now, with the 4.16.7

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #194 from Sandeep --- So, I had never used amdgpu.dc=1 and amdgpu.dpm=1 kernel parameters when testing earlier. I tried using them now, with the 4.16.7 kernel, and replayed the APItrace file. No crashes!

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

On Fri, May 11, 2018 at 09:47:49PM +0200, Boris Brezillon wrote: > On Fri, 11 May 2018 20:29:48 +0300 > Ville Syrjälä wrote: > > > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote: > > > On Fri, 11 May 2018 19:54:02 +0300 > > > Ville Syrjälä

Re: [PULL] drm-misc-next

Maarten Lankhorst writes: > Hey, > > Another pull request for drm-misc-next. Previous one was not applied yet, > but only sending delta since last request: > https://lists.freedesktop.org/archives/dri-devel/2018-May/175722.html Note, I think this PR has a UABI

Re: [PATCH] drm/amdkfd: Integer overflows in ioctl

On Tue, Apr 24, 2018 at 9:58 PM, Felix Kuehling wrote: > Reviewed-by: Felix Kuehling > > We could probably add a sanity check for n_devices to avoid user mode > causing excessive memory allocations in the kernel. There is no good > reason for this

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

Ville Syrjälä writes: > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote: >> On Fri, 11 May 2018 19:54:02 +0300 >> Ville Syrjälä wrote: >> >> > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote: >> > >

[PATCH 3/6] drm/psr: Fix missed entry in PSR setup time table.

Entry corresponding to 220 us setup time was missing. I am not aware of any specific bug this fixes, but this could potentially result in enabling PSR on a panel with a higher setup time requirement than supported by the hardware. I verified the value is present in eDP spec versions 1.3, 1.4 and

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

On Fri, 11 May 2018 20:29:48 +0300 Ville Syrjälä wrote: > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote: > > On Fri, 11 May 2018 19:54:02 +0300 > > Ville Syrjälä wrote: > > > > > On Fri, May 11, 2018 at

Re: [PATCH] drm/psr: Fix missed entry in PSR setup time table.

On Fri, 2018-05-11 at 18:03 +, Souza, Jose wrote: > On Thu, 2018-05-10 at 17:54 -0700, Dhinakaran Pandiyan wrote: > > > > Entry corresponding to 220 us setup time was missing. I am not > > aware > > of > > any specific bug this fixes, but this could potentially result in > > enabling > > PSR

Re: [Freedreno] [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

On Fri, May 11, 2018 at 11:05:24AM -0600, Jordan Crouse wrote: > On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote: > > SoCs containing dpu have a MDSS top level wrapper > > which includes sub-blocks as dpu, dsi, phy, dp etc. > > MDSS top level wrapper manages common resources like > >

[PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

Status register contains a lot of bits for reporting internal errors inside Mali DP. Currently, we just silently ignore all of the erorrs, that doesn't help when we are investigating different bugs, especially on the FPGA models which have a lot of constrains, so we could easily end up in AXI or

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #27 from Alex Deucher --- Can you post your kernel config? I'm having trouble seeing how these crashes are even possible. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote: > On Fri, 11 May 2018 19:54:02 +0300 > Ville Syrjälä wrote: > > > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote: > > > On Fri, 11 May 2018 18:34:50 +0300 > > > Ville Syrjälä

[Bug 106474] "CPU1 stuck for XXs: Xorg" since update to linux-4.16.x

https://bugs.freedesktop.org/show_bug.cgi?id=106474 --- Comment #3 from Clemens Eisserer --- unfortunately not on that machine :/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

On Fri, 11 May 2018 19:54:02 +0300 Ville Syrjälä wrote: > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote: > > On Fri, 11 May 2018 18:34:50 +0300 > > Ville Syrjälä wrote: > > > > > On Fri, May 11, 2018 at

Re: [Freedreno] [DPU PATCH v2 04/12] drm/msm/dpu: create new platform driver for dpu device

On Fri, May 11, 2018 at 08:19:30PM +0530, Rajesh Yadav wrote: > Current MSM display controller HW matches a tree like > hierarchy where MDSS top level wrapper is parent device > and mdp5/dpu, dsi, dp are child devices. > > Each child device like mdp5, dsi etc. have a separate driver, > but

Re: [Freedreno] [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote: > SoCs containing dpu have a MDSS top level wrapper > which includes sub-blocks as dpu, dsi, phy, dp etc. > MDSS top level wrapper manages common resources like > common clocks, power and irq for its sub-blocks. > > Currently, in dpu

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote: > On Fri, 11 May 2018 18:34:50 +0300 > Ville Syrjälä wrote: > > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote: > > > Applying an underscan setup is just a matter of scaling all

Re: [PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp

Hi Lin, 2018-05-09 12:22 GMT+02:00 Lin Huang : > From: Chris Zhong > > We may support training outside firmware, so we need support > dpcd read/write to get the message or do some setting with > display. > > Signed-off-by: Chris Zhong

Re: [PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY

Hi Lin, 2018-05-11 16:43 GMT+02:00 Sean Paul : > On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote: >> If want to do training outside DP Firmware, need phy voltage swing >> and pre_emphasis value. >> >> Signed-off-by: Lin Huang > > Adding Rob

Re: [PATCH v4 1/3] dt-bindings: panel: Add the Ilitek ILI9881c panel documentation

On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard wrote: > The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the > ILI9881c from Ilitek. > > Acked-by: Rob Herring > Signed-off-by: Maxime Ripard (...) Bah,

Re: [Intel-gfx] [PATCH 5/7] drm/vmwgfx: Stop updating plane->fb

On Fri, Apr 06, 2018 at 10:35:00PM +0300, Ville Syrjälä wrote: > On Fri, Apr 06, 2018 at 07:14:51PM +, Deepak Singh Rawat wrote: > > This makes sense once we got rid of plane->fb > > > > Will this go to drm-next? > > The plan is to push to drm-misc-next once we get all > the ducks in a row.

Re: [PATCH v4 2/3] drm/panel: Add Ilitek ILI9881c panel driver

Hi Maxime, sorry that noone had much time to look at the driver. But I can help out, hopefully. On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard wrote: > The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is > based on the Ilitek ILI9881c

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

On Fri, 11 May 2018 18:34:50 +0300 Ville Syrjälä wrote: > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote: > > Applying an underscan setup is just a matter of scaling all planes > > appropriately and adjusting the CRTC X/Y offset to account for the

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #26 from jian-h...@endlessm.com --- Yes. System can boot with modprobe.blacklist=amdgpu & systemd.unit=multi-user.target. This is the way that I tested and got the dmesg. I booted with that configuration and got into command line

Re: [DPU PATCH v2 12/12] drm/msm/dpu: add error handling in dpu_core_perf_crtc_update

On Fri, May 11, 2018 at 08:19:38PM +0530, Rajesh Yadav wrote: > dpu_core_perf_crtc_update() is responsible for aggregating > the data bus bandwidth and dpu core clock rate requirements > and request the same for all active crtcs. > Currently, there is no error handling support in this function >

Re: [DPU PATCH v2 11/12] drm/msm/dpu: move dpu_power_handle to dpu folder

On Fri, May 11, 2018 at 08:19:37PM +0530, Rajesh Yadav wrote: > Now, since dpu_power_handle manages only bus scaling > and power enable/disable notifications which are restricted > to dpu driver, move dpu_power_handle to dpu folder. > > Changes in v2: > - resolved conflict in dpu_unbind >

Re: [DPU PATCH v2 10/12] drm/msm/dpu: use runtime_pm calls in dpu_dbg

On Fri, May 11, 2018 at 08:19:36PM +0530, Rajesh Yadav wrote: > Currently, msm_drv was creating dpu_power_handle client > which was used by dpu_dbg module to enable power resources > before register debug dumping. > > Now since, the mdss core power resource handling is > implemented via

Re: [PATCH v4 1/3] dt-bindings: panel: Add the Ilitek ILI9881c panel documentation

On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard wrote: > The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the > ILI9881c from Ilitek. > > Acked-by: Rob Herring > Signed-off-by: Maxime Ripard Reviewed-by:

Re: [DPU PATCH v2 08/12] drm/msm/dpu: remove power management code from dpu_power_handle

On Fri, May 11, 2018 at 08:19:34PM +0530, Rajesh Yadav wrote: > Mdss main power supply (mdss_gdsc) is implemented as a > generic power domain and mdss top level wrapper device > manage it via runtime_pm. Remove custom power management > code from dpu_power_handle. > > Changes in v2: > -

Re: [DPU PATCH v2 07/12] drm/msm/dpu: remove clock management code from dpu_power_handle

On Fri, May 11, 2018 at 08:19:33PM +0530, Rajesh Yadav wrote: > MDSS and dpu drivers manage their respective clocks via > runtime_pm. Remove custom clock management code from > dpu_power_handle. > > Also dpu core clock management code is restricted to > dpu_core_perf module. > > Changes in v2: >

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote: > Applying an underscan setup is just a matter of scaling all planes > appropriately and adjusting the CRTC X/Y offset to account for the > horizontal and vertical border. > > Create an vc4_plane_underscan_adj() function doing that

Re: [DPU PATCH v2 04/12] drm/msm/dpu: create new platform driver for dpu device

On Fri, May 11, 2018 at 08:19:30PM +0530, Rajesh Yadav wrote: > Current MSM display controller HW matches a tree like > hierarchy where MDSS top level wrapper is parent device > and mdp5/dpu, dsi, dp are child devices. > > Each child device like mdp5, dsi etc. have a separate driver, > but

Re: [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote: > SoCs containing dpu have a MDSS top level wrapper > which includes sub-blocks as dpu, dsi, phy, dp etc. > MDSS top level wrapper manages common resources like > common clocks, power and irq for its sub-blocks. > > Currently, in dpu

[Bug 106447] System freeze after resuming from suspend (amdgpu)

https://bugs.freedesktop.org/show_bug.cgi?id=106447 --- Comment #17 from Thomas Martitz --- Done, https://bugzilla.kernel.org/show_bug.cgi?id=199693 -- You are receiving this mail because: You are the assignee for the bug.___

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #25 from Alex Deucher --- Does the system boot ok with amdgpu blacklisted? E.g., append modprobe.blacklist=amdgpu to the kernel command line in grub and boot to a non-GUI runlevel. -- You are receiving this

[Bug 106447] System freeze after resuming from suspend (amdgpu)

https://bugs.freedesktop.org/show_bug.cgi?id=106447 --- Comment #16 from Alex Deucher --- (In reply to Thomas Martitz from comment #15) > > So, what to do with this information / potential fix? Please file a bug as per comment 10 and include that information. -- You

[Bug 106447] System freeze after resuming from suspend (amdgpu)

https://bugs.freedesktop.org/show_bug.cgi?id=106447 --- Comment #15 from Thomas Martitz --- I investigated the commit found by git bisect a bit more, and found that the following patch (which reverts part of said commit) repairs resuming. I can't tell the consequences,

Re: [PATCH v2 4/4] drm/rockchip: support dp training outside dp firmware

On Wed, May 09, 2018 at 06:22:44PM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So if the phy is using custom config values, do software > link training instead of relying

[PATCH v2 4/4] drm/nouveau: Switch to the generic underscan props

Now that underscan props can be parsed by the core and assigned to conn_state->underscan.xxx, we can rely on this implementation and get rid of the nouveau-specific underscan props. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/nouveau/nouveau_connector.c | 39

[PATCH v2 1/4] drm/connector: Add generic underscan properties

We have 3 drivers defining the "underscan", "underscan hborder" and "underscan vborder" properties (radeon, amd and nouveau) and we are about to add the same kind of thing in VC4. Define generic underscan props and add new fields to the drm_connector state so that the property parsing logic can

[PATCH v2 3/4] drm/vc4: Attach underscan props to the HDMI connector

Now that the plane code takes the underscan setup into account, we can safely attach the underscan props to the HDMI connector. We also take care of filling AVI infoframes correctly to expose the top/botton/left/right bar. Note that these underscan props match pretty well the

[PATCH v2 0/4] drm/connector: Provide generic support for underscan

Hello, This is an attempt at providing generic support for underscan connector props. We already have 3 drivers defining the same underscan, underscan vborder and underscan hborder properties (amd, radeon and nouveau) and I am about to add a new one, hence my proposal to put the prop parsing code

[PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

Applying an underscan setup is just a matter of scaling all planes appropriately and adjusting the CRTC X/Y offset to account for the horizontal and vertical border. Create an vc4_plane_underscan_adj() function doing that and call it from vc4_plane_setup_clipping_and_scaling() so that we are

[Bug 106471] Radeon HD 3450 acceleration not working

https://bugs.freedesktop.org/show_bug.cgi?id=106471 --- Comment #1 from Alex Deucher --- Does it work properly if you remove the nouveau card or switch the slots? -- You are receiving this mail because: You are the assignee for the

[DPU PATCH v2 11/12] drm/msm/dpu: move dpu_power_handle to dpu folder

Now, since dpu_power_handle manages only bus scaling and power enable/disable notifications which are restricted to dpu driver, move dpu_power_handle to dpu folder. Changes in v2: - resolved conflict in dpu_unbind - dropped (Reviewed-by: Sean Paul) due to above change

[DPU PATCH v2 12/12] drm/msm/dpu: add error handling in dpu_core_perf_crtc_update

dpu_core_perf_crtc_update() is responsible for aggregating the data bus bandwidth and dpu core clock rate requirements and request the same for all active crtcs. Currently, there is no error handling support in this function so there is no way caller can know if the perf request fails. This change

[DPU PATCH v2 10/12] drm/msm/dpu: use runtime_pm calls in dpu_dbg

Currently, msm_drv was creating dpu_power_handle client which was used by dpu_dbg module to enable power resources before register debug dumping. Now since, the mdss core power resource handling is implemented via runtime_pm and same has been removed from dpu_power_handle. Remove dpu_power_handle

[Bug 106474] "CPU1 stuck for XXs: Xorg" since update to linux-4.16.x

https://bugs.freedesktop.org/show_bug.cgi?id=106474 --- Comment #2 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[DPU PATCH v2 09/12] drm/msm/dp: remove dpu_power_handle calls from dp driver

DP driver was dependent on dpu_power_handle for MDSS common clocks and gdsc (main power supply). The common clocks and power is managed by MDSS top wrapper device now which is parent of all sub-devices like DP device. For same reason, clock and power management code is removed from

[DPU PATCH v2 07/12] drm/msm/dpu: remove clock management code from dpu_power_handle

MDSS and dpu drivers manage their respective clocks via runtime_pm. Remove custom clock management code from dpu_power_handle. Also dpu core clock management code is restricted to dpu_core_perf module. Changes in v2: - remove local variable to hold and return error code in

[DPU PATCH v2 08/12] drm/msm/dpu: remove power management code from dpu_power_handle

Mdss main power supply (mdss_gdsc) is implemented as a generic power domain and mdss top level wrapper device manage it via runtime_pm. Remove custom power management code from dpu_power_handle. Changes in v2: - resolved merge conflict in dpu_power_resource_init - dropped

[DPU PATCH v2 06/12] drm/msm/dpu: use runtime_pm calls on dpu device

The dpu driver implements runtime_pm support for managing dpu specific resources like - clocks, bus bandwidth etc. Use pm_runtime_get/put_sync calls on dpu device. The common clocks and power management for all child nodes (mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver via

[DPU PATCH v2 05/12] drm/msm/dpu: update dpu sub-block offsets wrt dpu base address

The dpu sub-block offsets were defined wrt mdss base address instead of dpu base address. Since, dpu is now defined as a separate device, update hw catalog offsets for all dpu sub blocks wrt dpu base address. Changes in v2: - none Signed-off-by: Rajesh Yadav

[DPU PATCH v2 04/12] drm/msm/dpu: create new platform driver for dpu device

Current MSM display controller HW matches a tree like hierarchy where MDSS top level wrapper is parent device and mdp5/dpu, dsi, dp are child devices. Each child device like mdp5, dsi etc. have a separate driver, but currently dpu handling is tied to a single driver which was managing both mdss

[DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

SoCs containing dpu have a MDSS top level wrapper which includes sub-blocks as dpu, dsi, phy, dp etc. MDSS top level wrapper manages common resources like common clocks, power and irq for its sub-blocks. Currently, in dpu driver, all the power resource management is part of power_handle which

[DPU PATCH v2 01/12] drm/msm: remove redundant pm_runtime_enable call from msm_drv

MDSS top level device includes the common power resources and it's corresponding driver (i.e. mdp5_mdss) handles call to enable/disable runtime_pm for enabling these resources. Remove redundant pm_runtime_enable call from msm_drv. Changes in v2: - none Signed-off-by: Rajesh Yadav

[DPU PATCH v2 02/12] drm/msm/mdp5: subclass msm_mdss for mdp5

SoCs having mdp5 or dpu have identical tree like device hierarchy where MDSS top level wrapper manages common power resources for all child devices. Subclass msm_mdss so that msm_mdss includes common defines and mdp5/dpu mdss derivations to include any extensions. Add mdss helper interface

[DPU PATCH v2 00/12] Refactor DPU device/driver hierarchy and add runtime_pm support

SoCs containing mdp5 or dpu have a MDSS top level wrapper which includes sub-blocks as mdp5/dpu, dsi, dp, hdmi etc. The MDSS top level wrapper manages common resources like common clocks, main power supply and interrupts for its sub-blocks. But current dpu driver implementation is based on a flat

Re: [PATCH v2 3/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY

On Wed, May 09, 2018 at 06:22:43PM +0800, Lin Huang wrote: > If want to do training outside DP Firmware, need phy voltage swing > and pre_emphasis value. > > Signed-off-by: Lin Huang Adding Rob Herring so he has a hope of seeing this. > --- > Changes in v2: > - rebase > >

Re: [PATCH v2 2/4] phy: rockchip-typec: support variable phy config value

On Wed, May 09, 2018 at 06:22:42PM +0800, Lin Huang wrote: > the phy config values used to fix in dp firmware, but some boards > need change these values to do training and get the better eye diagram > result. So support that in phy driver. > FTR, I've previously reviewed this at

Re: [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote: > +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts > @@ -0,0 +1,297 @@ > +/* > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT) This really should be the first line, and with a C++ style comment, as in: // SPDX-License-Identifier:

Re: [PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp

On Wed, May 09, 2018 at 06:22:41PM +0800, Lin Huang wrote: > From: Chris Zhong > > We may support training outside firmware, so we need support > dpcd read/write to get the message or do some setting with > display. > > Signed-off-by: Chris Zhong >

[PATCH] drm: rcar-du: disable dtc graph-endpoint warnings on DT overlays

The rcar DT overlays are missing symetrical remote-endpoint properties in their graph nodes because the remote-endpoint is fixed up at run-time. Disable the dtc 'graph-endpoint' warnings when compiling these overlays. If this becomes a common problem for overlays, then perhaps this check needs to

[Bug 106447] System freeze after resuming from suspend (amdgpu)

https://bugs.freedesktop.org/show_bug.cgi?id=106447 --- Comment #14 from john-s...@gmx.net --- Same Problem here (HP zbook 15u 5g). https://bugzilla.kernel.org/show_bug.cgi?id=199609 Chen Yu recommended to write a request on amd-...@lists.freedesktop.org with no success so far.

Re: [PATCH 1/3] drm/connector: Add generic underscan properties

On Mon, 7 May 2018 17:25:30 +0200 Daniel Vetter wrote: > On Mon, May 07, 2018 at 05:15:33PM +0200, Daniel Vetter wrote: > > On Mon, May 07, 2018 at 04:44:32PM +0200, Boris Brezillon wrote: > > > We have 3 drivers defining the "underscan", "underscan hborder" and > > >

Re: [PATCH 1/3] drm/connector: Add generic underscan properties

On Tue, 8 May 2018 10:18:10 +1000 Ben Skeggs wrote: > On 8 May 2018 at 04:26, Harry Wentland wrote: > > > > > > On 2018-05-07 12:19 PM, Boris Brezillon wrote: > >> On Mon, 7 May 2018 18:01:44 +0300 > >> Ville Syrjälä

Re: [PATCH] drm: Match sysfs name in link removal to link creation

On Fri, May 11, 2018 at 07:15:42AM +0300, Haneen Mohammed wrote: > This patch matches the sysfs name used in the unlinking with the > linking function. Otherwise, remove_compat_control_link() fails to remove > sysfs created by create_compat_control_link() in drm_dev_register(). > > Signed-off-by:

[Bug 106447] System freeze after resuming from suspend (amdgpu)

https://bugs.freedesktop.org/show_bug.cgi?id=106447 --- Comment #13 from Thomas Martitz --- I'll report the bug on the other site as well. In my view: Loading the amdgpu module breaks resuming from suspend. Maybe the module isn't correctly adapted to the changes made in

[Bug 106447] System freeze after resuming from suspend (amdgpu)

https://bugs.freedesktop.org/show_bug.cgi?id=106447 --- Comment #12 from Michel Dänzer --- That's debatable, given you bisected to a non-amdgpu commit, which affects WiFi as well. -- You are receiving this mail because: You are the assignee for the

[Bug 106447] System freeze after resuming from suspend (amdgpu)

https://bugs.freedesktop.org/show_bug.cgi?id=106447 --- Comment #11 from Thomas Martitz --- I can suspend+resume just fine with amdgpu blacklisted, so I'm under the impression that this is the right place. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90

On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote: > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote: > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote: > > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel, > > > as found on the

[Bug 106473] Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker

https://bugs.freedesktop.org/show_bug.cgi?id=106473 --- Comment #2 from Matt Whitlock --- (In reply to Michel Dänzer from comment #1) > Does > https://cgit.freedesktop.org/mesa/mesa/commit/ > ?id=6f81e07ecb8c0793dc482307d5d96fd3df95b7d2 help? I've applied this

Re: [PATCH v2 0/4] backlight: fix device-tree node lookups

On Fri, 11 May 2018, Johan Hovold wrote: > Hi Lee, > > On Mon, Nov 20, 2017 at 11:45:43AM +0100, Johan Hovold wrote: > > A number of drivers have been using the wrong OF helper when doing > > child-node > > lookups during probe. This meant that they were doing tree-wide searches > > rather > >

Re: [PATCH] gpu: drm: exynos: Change return type to vm_fault_t

2018년 05월 10일 23:27에 Souptick Joarder 이(가) 쓴 글: > On Sat, Apr 14, 2018 at 9:34 PM, Souptick Joarder > wrote: >> Use new return type vm_fault_t for fault handler >> in struct vm_operations_struct. >> >> Signed-off-by: Souptick Joarder >> Reviewed-by:

[Bug 106447] System freeze after resuming from suspend (amdgpu)

https://bugs.freedesktop.org/show_bug.cgi?id=106447 --- Comment #10 from Michel Dänzer --- Looks like you should report this at https://bugzilla.kernel.org/enter_bug.cgi?product=Power%20Management=Hibernation/Suspend . -- You are receiving this mail because: You are the

[Bug 84740] black screen after Grub loads a kernel entry (Intel Atom D2xxx/N2xxx Integrated Graphics Controller)

https://bugs.freedesktop.org/show_bug.cgi?id=84740 Jani Saarinen changed: What|Removed |Added Status|RESOLVED|CLOSED ---

[Bug 106473] Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker

https://bugs.freedesktop.org/show_bug.cgi?id=106473 --- Comment #1 from Michel Dänzer --- Does https://cgit.freedesktop.org/mesa/mesa/commit/?id=6f81e07ecb8c0793dc482307d5d96fd3df95b7d2 help? -- You are receiving this mail because: You are the assignee for the

[PULL] drm-misc-next

Hey, Another pull request for drm-misc-next. Previous one was not applied yet, but only sending delta since last request: https://lists.freedesktop.org/archives/dri-devel/2018-May/175722.html drm-misc-next-2018-05-11-1: drm-misc-next for v4.18: UAPI Changes: - Aspect ratio support for 64:27 and

Re: [Intel-gfx] [PATCH v14 10/10] drm: Add and handle new aspect ratios in DRM layer

Op 09-05-18 om 22:24 schreef Daniel Vetter: > On Tue, May 08, 2018 at 04:39:45PM +0530, Nautiyal, Ankit K wrote: >> From: "Sharma, Shashank" >> >> HDMI 2.0/CEA-861-F introduces two new aspect ratios: >> - 64:27 >> - 256:135 >> >> This patch: >> - Adds new DRM flags for

Re: [PATCH v2 0/4] backlight: fix device-tree node lookups

Hi Lee, On Mon, Nov 20, 2017 at 11:45:43AM +0100, Johan Hovold wrote: > A number of drivers have been using the wrong OF helper when doing child-node > lookups during probe. This meant that they were doing tree-wide searches > rather > than matching on child nodes and that the parent node could

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

Quoting Ezequiel Garcia (2018-05-09 21:14:49) > Change how dma_fence_add_callback() behaves, when the fence > has error-signaled by the time it is being add. After this commit, > dma_fence_add_callback() returns the fence error, if it > has error-signaled before dma_fence_add_callback() is called.

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

Quoting Ezequiel Garcia (2018-05-10 13:51:56) > On Wed, 2018-05-09 at 19:42 -0300, Gustavo Padovan wrote: > > Hi Ezequiel, > > > > On Wed, 2018-05-09 at 17:14 -0300, Ezequiel Garcia wrote: > > > Change how dma_fence_add_callback() behaves, when the fence > > > has error-signaled by the time it is

[PATCH] drm: Match sysfs name in link removal to link creation

This patch matches the sysfs name used in the unlinking with the linking function. Otherwise, remove_compat_control_link() fails to remove sysfs created by create_compat_control_link() in drm_dev_register(). Signed-off-by: Haneen Mohammed --- drivers/gpu/drm/drm_drv.c |

[PATCH] gpu: drm: drm_vm: Adding new typedef vm_fault_t

Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Re: [PATCH v2] gpu: drm: udl: Adding new typedef vm_fault_t

On Wed, Apr 25, 2018 at 10:29 AM, Souptick Joarder wrote: > Use new return type vm_fault_t for fault and huge_fault > handler. For now, this is just documenting that the > function returns a VM_FAULT value rather than an errno. > Once all instances are converted, vm_fault_t

[PATCH 2/2] lib/ratelimit: Lockless ratelimiting

Currently ratelimit_state is protected with spin_lock. If the .lock is taken at the moment of ___ratelimit() call, the message is suppressed to make ratelimiting robust. That results in the following issue issue: CPU0 CPU1 --

Re: [PATCH 4/4] drm/tegra: Refactor IOMMU attach/detach

On 04.05.2018 16:37, Thierry Reding wrote: > From: Thierry Reding > > Attaching to and detaching from an IOMMU uses the same code sequence in > every driver, so factor it out into separate helpers. > > Signed-off-by: Thierry Reding > --- >

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

On Wed, 2018-05-09 at 19:42 -0300, Gustavo Padovan wrote: > Hi Ezequiel, > > On Wed, 2018-05-09 at 17:14 -0300, Ezequiel Garcia wrote: > > Change how dma_fence_add_callback() behaves, when the fence > > has error-signaled by the time it is being add. After this commit, > >

[PATCH v2] gpu: drm: armada: Adding new typedef vm_fault_t

Use new return type vm_fault_t for fault handler in struct vm_operations_struct. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. commit 1c8f422059ae ("mm: change return

Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t

Hi Gerd /Daniel, On Tue, Apr 24, 2018 at 6:05 PM, Gerd Hoffmann wrote: > On Tue, Apr 24, 2018 at 02:11:51PM +0200, Daniel Vetter wrote: >> On Mon, Apr 23, 2018 at 12:49:24PM +0200, Gerd Hoffmann wrote: >> > On Tue, Apr 17, 2018 at 07:08:44PM +0530, Souptick Joarder wrote: >> >

Re: [PATCH] gpu: drm: exynos: Change return type to vm_fault_t

On Sat, Apr 14, 2018 at 9:34 PM, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler > in struct vm_operations_struct. > > Signed-off-by: Souptick Joarder > Reviewed-by: Matthew Wilcox > --- >

Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t

Hi Sean, On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. > > Signed-off-by: Souptick Joarder > Reviewed-by: Matthew Wilcox > --- > drivers/gpu/drm/vgem/vgem_drv.c |

[PATCH 0/2] ratelimit: Do not lose messages under limit

There are two issues with ratelimiting as far a I can see: 1. Messages may be lost even if their amount fit burst limit; 2. "suppressed" message may not be printed if there is no call to ___ratelimit() after interval ends. I address (1) issue in the second patch. While the (2) issue will

Re: [PATCH 2/2] drm/amdgpu: set ttm bo priority before initialization

Looks like a good idea to me as well. Reviewed-by: Christian König for the series. Regards, Christian. Am 11.05.2018 um 07:27 schrieb Zhou, David(ChunMing): The series is OK to me, Reviewed-by: Chunming Zhou It is better to wait Christian to

  1   2   >