[PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.

On Thu, Jan 21, 2016 at 10:16:01AM +0100, Mario Kleiner wrote: > On 01/21/2016 09:25 AM, Michel Dänzer wrote: > > On 21.01.2016 17:16, Mario Kleiner wrote: > >> > >> This patch replaces calls to drm_vblank_pre/post_modeset in the > >> drivers dpms code with calls to drm_vblank_off/on, as

[Bug 93800] xfwm4 with compositing hangs indefinitely after after coming back from dpms off

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/ffb880fc/attachment.html>

[BUG] Radeon TAHITI_vce.bin firmware casuses oops on Acube Sam460ex amcc 460ex and other Power PC motherboards

x64 [c001750ffaf0] [c0514bc4] .drm_pci_init+0x68/0x10c [c001750ffb90] [c00001667b84] .radeon_init+0xac/0xd0 [c001750ffc10] [c0009484] .do_one_initcall+0x14c/0x1e8 [c001750ffd00] [c162fb5c] .kernel_init_freeable+0x180/0x23c [c001750ffdb0] [c0009b10] .kernel_init+0x20/0x120 [c001750ffe30] [c0007eb0] .ret_from_kernel_thread+0x58/0xa8 Instruction dump: 4b9fc315 6000 e93b23b0 387c0100 389e014c e8a9 38a5feb4 4b9fd84d 6000 815a0024 7d3cea14 3860 <7d5ce92e> 815a0028 91490004 815a002c ---[ end trace 70c04666cc8ef3da ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b Rebooting in 180 seconds.. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/6405c522/attachment-0001.html>

[PATCH v12.1 07/17] drm: rockchip: dp: add rockchip platform dp driver

Hi Yakir, Am Dienstag, 19. Januar 2016, 18:04:53 schrieb Yakir Yang: > Rockchip have three clocks for dp controller, we leave pclk_edp > to analogix_dp driver control, and keep the sclk_edp_24m and > sclk_edp in platform driver. > > Signed-off-by: Yakir Yang > Tested-by: Javier Martinez

[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/8cb060cc/attachment.html>

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

his mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/0d79e03a/attachment-0001.html>

Whats missing in my new FB DRM driver in ARC... waiting for console_lock to return

hi... i just found that its blocking waiting for console_lock... @vineet, alexey: i think that console_lock is architecture dependent right? Do you know any issue with console_lock for ARC? On 21-01-2016 18:09, Carlos Palminha wrote: > i made some progress in identifying the issue... > When my

[PATCH v2] drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION

If DRM_FBDEV_EMULATION is not selected in the config then we can save a bit of space by not including the framebuffer code. Signed-off-by: John Keeping --- On Thu, 21 Jan 2016 17:52:51 +0100, Daniel Vetter wrote: > On Thu, Jan 21, 2016 at 01:53:46PM +, John Keeping wrote: > > If

[PATCH libdrm] radeon: Pass radeon_bo_open flags to the DRM_RADEON_GEM_CREATE ioctl

From: Michel Dänzer Not doing so makes it impossible for radeon_bo_open callers to set any RADEON_GEM_* flags for the newly created BO. Signed-off-by: Michel Dänzer --- radeon/radeon_bo_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?

i made some progress in identifying the issue... When my driver calls drm_fb_helper_initial_config it seems DRM blocks waiting for register_framebuffer to return. The sequence is drm_fb_helper_initial_config->drm_fb_helper_single_fb_probe->register_framebuffer. Its strange because

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov wrote: > On 21 January 2016 at 12:08, Marek Olšák wrote: >> On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov >> wrote: >>> On 18 January 2016 at 22:53, Marek Olšák wrote: Try explaining that to people who have a compulsion to fix them or

[PATCH] drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION

On Thu, Jan 21, 2016 at 01:53:46PM +, John Keeping wrote: > If DRM_FBDEV_EMULATION is not selected in the config then we should not > setup a framebuffer console. It should just magically work, and this patch here just removes a bit more dead code in the rockchip driver itself that's not

ongoing writecombine on ppc

+Alex On Thu, Jan 21, 2016 at 5:24 PM, Oded Gabbay wrote: > On Fri, Oct 2, 2015 at 7:56 AM, Benjamin Herrenschmidt > wrote: >> On Fri, 2015-10-02 at 14:53 +1000, Dave Airlie wrote: >>> On 2 October 2015 at 14:45, Benjamin Herrenschmidt >>> wrote: >>> > On Fri, 2015-10-02 at 14:42 +1000, Dave

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On 21.01.2016 16:58, Daniel Vetter wrote: > On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote: >> On 21.01.2016 15:38, Michel Dänzer wrote: >>> On 21.01.2016 14:31, Mario Kleiner wrote: On 01/21/2016 04:43 AM, Michel Dänzer wrote: > On 21.01.2016 05:32, Mario Kleiner wrote:

[PATCH 13/13] dt/bindings: drm/msm/hdmi: Add hdmi phy bindings

On Thu, Jan 21, 2016 at 12:39:41PM +0530, Archit Taneja wrote: > Add hdmi phy bindings. Update the example to use hdmi phy. > > Add a missing power-domains property in the hdmi core bindings. > > Cc: devicetree at vger.kernel.org > Cc: Rob Herring > > Signed-off-by: Archit Taneja > --- >

[PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.

On 21.01.2016 17:16, Mario Kleiner wrote: > > This patch replaces calls to drm_vblank_pre/post_modeset in the > drivers dpms code with calls to drm_vblank_off/on, as recommended > for drivers with hw counters that reset to zero during modeset. Sounds like you fell for the drm_vblank_on/off

ongoing writecombine on ppc

On Fri, Oct 2, 2015 at 7:56 AM, Benjamin Herrenschmidt wrote: > On Fri, 2015-10-02 at 14:53 +1000, Dave Airlie wrote: >> On 2 October 2015 at 14:45, Benjamin Herrenschmidt >> wrote: >> > On Fri, 2015-10-02 at 14:42 +1000, Dave Airlie wrote: >> > > I don't think we resolved this the last time we

[PATCH v4 6/6] drm/dsi: Get DSI host by DT device node

tp://lists.freedesktop.org/archives/dri-devel/attachments/20160121/ba11d7ba/attachment.sig>

[PATCH v4 5/6] drm/dsi: Add routine to unregister dsi device

function so that both OF and !OF share the same code for this. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/17e805f1/attachment.sig>

[PATCH v4 4/6] drm/dsi: Check for used channels

ists.freedesktop.org/archives/dri-devel/attachments/20160121/51f7586f/attachment.sig>

[PATCH v4 3/6] drm/dsi: Try to match non-DT dsi devices

virtual channel assigned to peripheral > * @node: pointer to OF device node > * > @@ -148,6 +151,7 @@ enum mipi_dsi_pixel_format { > * DSI device > */ > struct mipi_dsi_device_info { > + char type[DSI_DEV_NAME_SIZE]; Why limit ourselves to 20 characters? And why even so complicated? Isn't the type always static when someone specifies this? Couldn't we simply use a const char *name here instead? Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/9cbd627c/attachment.sig>

[PATCH v4 2/6] drm/dsi: Refactor device creation

Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/b21d69a4/attachment.sig>

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

On 1/21/2016 8:59 AM, Nick Bowler wrote: > On 1/20/16, Nick Bowler wrote: >> Hi, >> >> On 2016-01-20, Jindal, Sonika wrote: >>> Can you please check if you have following patch: >>> "commit 3d8acd1f667b45c531401c8f0c2033072e32a05d >>> Author: Gary Wang >>> Date: Wed Dec 23 16:11:35 2015

[PATCH v4 1/6] drm/dsi: check for CONFIG_OF when defining of_mipi_dsi_device_add

we never check the return value in the one call-site that we have, which I guess could be an argument for removing the return value altogether... Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size:

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On 21.01.2016 15:38, Michel Dänzer wrote: > On 21.01.2016 14:31, Mario Kleiner wrote: >> On 01/21/2016 04:43 AM, Michel Dänzer wrote: >>> On 21.01.2016 05:32, Mario Kleiner wrote: So the problem is that AMDs hardware frame counters reset to zero during a modeset. The old DRM code

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On 21.01.2016 14:31, Mario Kleiner wrote: > On 01/21/2016 04:43 AM, Michel Dänzer wrote: >> On 21.01.2016 05:32, Mario Kleiner wrote: >>> >>> So the problem is that AMDs hardware frame counters reset to >>> zero during a modeset. The old DRM code dealt with drivers doing that by >>> keeping

[PATCH 2/2] rnndb: hdmi: Add hdmi phy registers for 8996

Adds hdmi 8996 phy registers. The registers are divided into 3 domains: - Core HDMI PHY registers - HDMI PLL registers (part of QSERDES block) - HDMI TX lane registers (part of QSERDES block) Signed-off-by: Archit Taneja --- rnndb/hdmi/hdmi.xml | 258

[PATCH 1/2] rnndb: hdmi: Create separate domains for 8x60 and 8960 PHY

- Create separate domains for 8960 PHY and PLL - Create separate domains for 8x60 PHY Signed-off-by: Archit Taneja --- rnndb/hdmi/hdmi.xml | 147 +++- 1 file changed, 75 insertions(+), 72 deletions(-) diff --git a/rnndb/hdmi/hdmi.xml

[PATCH 0/2] rnndb: hdmi: Support for MSM8996

Modify existing offsests for HDMI PHYs, and add support for MSM8996 Archit Taneja (2): rnndb: hdmi: Create separate domains for 8x60 and 8960 PHY rnndb: hdmi: Add hdmi phy registers for 8996 rnndb/hdmi/hdmi.xml | 405 ++-- 1 file changed, 333

[Bug 93801] GRID Autosport hang on logo (startup)

ceiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/3f9012b3/attachment.html>

[PATCH v9 3/3] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device.

Hi Lukas, Sorry for the late answer, I went on vacation and then was busy with something else. Anyway, I tried to address all comments (yours and Daniel's) on a new version. See some comments below. On Sun, Dec 06, 2015 at 05:08:49PM +0100, Lukas Wunner wrote: > Hi Rafael, > > On Thu, Dec 03,

[PATCH v10 4/4] drm/radeon: Fix WARN_ON if DRM_DP_AUX_CHARDEV is enabled

From: Lukas Wunner Rafael Antognolli's new DRM_DP_AUX_CHARDEV feature causes a WARN_ON if drm_dp_aux->dev == drm_connector->kdev and drm_dp_aux_unregister() is called after drm_connector_unregister(). radeon is the only driver affected by this besides i915. (amdgpu calls

[PATCH v10 3/4] drm/i915: Set aux.dev to the drm_connector device, instead of drm_device.

So far, the i915 driver and some other drivers set it to the drm_device, which doesn't allow one to know which DP a given aux channel is related to. Changing this to be the drm_connector provides proper nesting, still allowing one to get the drm_device from it. Some drivers already set it to the

[PATCH v10 2/4] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

This module is heavily based on i2c-dev. Once loaded, it provides one dev node per DP AUX channel, named drm_dp_auxN, where N is an integer. It's possible to know which connector owns this aux channel by looking at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if the

[PATCH v10 1/4] drm/kms_helper: Add a common place to call init and exit functions.

The module_init and module_exit functions will start here, and call the subsequent init's and exit's. v10: - Keep __init on drm_fb_helper init function. - Move MODULE_* macros to the common file. Signed-off-by: Rafael Antognolli --- drivers/gpu/drm/Makefile| 4 ++-

[PATCH v10 0/4] Add drm_dp_aux chardev support.

This series implement support to a drm_dp_aux chardev that allows reading and writing an arbitrary amount of bytes to arbitrary dpcd register addresses using regular read, write and lseek operations. Lukas Wunner (1): drm/radeon: Fix WARN_ON if DRM_DP_AUX_CHARDEV is enabled Rafael Antognolli

[PATCH] drm/etnaviv: move runtime PM balance into retire worker

The retire worker is kicked for each fence, either the normal way by signaling the fence from the event completion interrupt or by the recover worker if the GPU got stuck. Moving the RPM put into the retire worker allows us to have it in a single place for both cases. This also shaves off quite a

[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/df2e527c/attachment.html>

[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch

-- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/5f07be7f/attachment.html>

[PATCH libdrm] radeon: Pass radeon_bo_open flags to the DRM_RADEON_GEM_CREATE ioctl

On Thu, Jan 21, 2016 at 4:13 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Not doing so makes it impossible for radeon_bo_open callers to set any > RADEON_GEM_* flags for the newly created BO. Reviewed-by: Alex Deucher > > Signed-off-by: Michel Dänzer > --- > radeon/radeon_bo_gem.c

[Bug 93809] playing Just Cause causes system crash

graphical glitches. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/b0163a17/attachment-0001.html>

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

On 2016-01-21, Jindal, Sonika wrote: > On 1/21/2016 8:59 AM, Nick Bowler wrote: >> On 1/20/16, Nick Bowler wrote: >>> On 2016-01-20, Jindal, Sonika wrote: [...] Does the same system works with any other monitor? >>> I'll see if I can find another to try. >> I tried another monitor, and the

[PATCH] drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION

If DRM_FBDEV_EMULATION is not selected in the config then we should not setup a framebuffer console. Signed-off-by: John Keeping --- drivers/gpu/drm/rockchip/Makefile | 3 ++- drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h | 11 +++ 2 files changed, 13 insertions(+), 1

[Bug 87047] gputest pixmark tests fail on Barts

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/4af2462f/attachment.html>

[Bug 88522] unreal effectscave demo locks up gpu

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/aaadc99d/attachment.html>

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

On 21 January 2016 at 12:08, Marek Olšák wrote: > On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov > wrote: >> On 18 January 2016 at 22:53, Marek Olšák wrote: >>> Try explaining that to people who have a compulsion to fix them or >>> argue about them. :) Ignore? REALLY? IGNORE??? >>> >> Now

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov wrote: > On 18 January 2016 at 22:53, Marek Olšák wrote: >> Try explaining that to people who have a compulsion to fix them or >> argue about them. :) Ignore? REALLY? IGNORE??? >> > Now that we have a few people off your back can you please point

[PATCH] drm: amdgpu: Clean up function calls

Please submit patches for review with git send-email. Please send xf86-video-amdgpu patches to the xorg-driver-ati at lists.x.org list with a [PATCH xf86-video-amdgpu] subject prefix. On 21.01.2016 02:08, StDenis, Tom wrote: > Subject: [PATCH] amdgpu: Move memset() after variable declarations

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On 21.01.2016 05:32, Mario Kleiner wrote: > > So the problem is that AMDs hardware frame counters reset to > zero during a modeset. The old DRM code dealt with drivers doing that by > keeping vblank irqs enabled during modesets and incrementing vblank > count by one during each vblank irq, i think

[PATCH 13/13] dt/bindings: drm/msm/hdmi: Add hdmi phy bindings

Add hdmi phy bindings. Update the example to use hdmi phy. Add a missing power-domains property in the hdmi core bindings. Cc: devicetree at vger.kernel.org Cc: Rob Herring Signed-off-by: Archit Taneja --- .../devicetree/bindings/display/msm/hdmi.txt | 39 +- 1 file

[PATCH 12/13] drm/msm/hdmi: HDMI 8996 PHY/PLL support

Add support for the HDMI PHY/PLL found in msm8996/apq8096. Unlike the previous phys supported in the driver, this doesn't need the powerup/powerdown ops. The PLL prepare/unprepare clock ops enable/disable the phy itself. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/hdmi/Makefile

[PATCH 11/13] drm/msm/hdmi: Update generated headers for hdmi 8996 phy

Adds hdmi 8996 phy offsets. The offsets are divided into 3 parts: - Core HDMI PHY registers - HDMI PLL registers (part of QSERDES block) - HDMI TX lane registers (part of QSERDES block) Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 500

[PATCH 10/13] drm/msm/hdmi: Convert phy files according to new design

Remove the old phy ops managed by hdmi_platform_config and use them as ops provided by the hdmi phy driver. Remove the old hdmi 8960 PLL code that used the top level hdmi tx mmio base. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/hdmi/hdmi.c | 25 +-

[PATCH 09/13] drm/msm/hdmi: Manage hdmi PLL through phy driver

Add a helper to initialize PLL in the phy driver. HDMI PLLs are going to have their own mmio base different from that of PHY. For the clock code in hdmi_phy_8960.c, some changes were needed for it to work with the updated register offsets. Create a copy of the updated clock code in

[PATCH 08/13] drm/msm/hdmi: Make hdmi core get its phy

Make hdmi core get its phy by parsing the qcom,hdmi-phy phandle. The core will use this phy reference to enable/disable phy. The driver defers probe until phy isn't available. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/hdmi/hdmi.c | 40

[PATCH 07/13] drm/msm/hdmi: Create a separate hdmi phy driver

Create a phy device that represents the TX PHY and PLL parts of the hdmi block. This makes management of PHY specific resources (regulators and clocks) much easier, and makes the PHY and PLL usable independently. It also simplifies the core hdmi driver, which currently assigns phy ops among with

[PATCH 06/13] drm/msm/hdmi: Update generated headers to split PHY/PLL offsets

- Create separate domains for 8960 PHY and PLL - Create separate domains for 8x60 PHY Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 157 +--- 1 file changed, 74 insertions(+), 83 deletions(-) diff --git

[PATCH 05/13] drm/msm/hdmi: Fix connector detect when there is no hpd gpio

Some platforms may not have a hpd gpio line to detect hpd. They need to rely only on reading REG_HDMI_HPD_INT_STATUS for hpd. Modify hdmi_connector_detect logic such that it checks for hpd only using the status register if there is no hpd gpio. Signed-off-by: Archit Taneja ---

[PATCH 04/13] drm/msm/hdmi: Clean up connector gpio usage

Make gpio allocation and usage iterative by parsing the gpios on a given platform from a list. This gives us flexibility over what all gpios exist for a platform, whether they are input or output, and what value they should be set to. In particular, this will make hdmi on 8x96 platforms easier to

[PATCH 03/13] drm/msm/edp: Create separate Makefile/Kconfig

The msm Makefile and Kconfig are getting conjusted. Move edp related stuff into separate Kconfig and Makefile. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/Makefile | 7 +-- drivers/gpu/drm/msm/edp/Kconfig | 7 +++

[PATCH 02/13] drm/msm/hdmi: Create separate Makefile/Kconfig

The msm Makefile and Kconfig are getting conjusted. HDMI is going to have more configs and files in the future to manage, which will make managing these harder. Move hdmi related stuff into separate Kconfig and Makefile. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/Kconfig | 1 +

[PATCH 01/13] drm/msm/dsi: Create separate Makefile/Kconfig

The msm Makefile and Kconfig are getting conjusted. Move out the DSI related stuff into separate Kconfig and Makefile. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/Kconfig | 40 +--- drivers/gpu/drm/msm/Makefile | 22 --

[PATCH 00/13] drm/msm/hdmi: HDMI support on MSM8996

HDMI on MSM8996 has a tx block that is compatible with the older versions apart from some minor changes. The HDMI PHY and PLL on msm8996 are new. The series refactors the code such that there is a separate hdmi phy driver, similar to what we already have for dsi. This makes it easier to integrate

[PATCH 2/2] drm: etnaviv: add further minor features and varyings count

Hi Lucas, 2016-01-21 10:16 GMT+01:00 Lucas Stach : > Am Dienstag, den 19.01.2016, 09:18 + schrieb Russell King: >> Export further minor feature bitmasks and the varyings count from >> the GPU specifications registers to userspace. >> >> Signed-off-by: Russell King

[Bug 93801] GRID Autosport hang on logo (startup)

//lists.freedesktop.org/archives/dri-devel/attachments/20160121/5d7c3288/attachment.html>

[Bug 93801] GRID Autosport hang on logo (startup)

ly matter, as the difference was about -5FPS. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/b3f1785a/attachment.html>

ongoing writecombine on ppc

On Thu, Jan 21, 2016 at 10:39 AM, Oded Gabbay wrote: > +Alex No objections from me. Care to respin with amdgpu support and signed off? Would probably also be nice to split the core drm change from the driver specific ones. Alex > > On Thu, Jan 21, 2016 at 5:24 PM, Oded Gabbay wrote: >> On

[PATCH 2/2] drm: etnaviv: add further minor features and varyings count

On Thu, Jan 21, 2016 at 12:34:16PM +0100, Christian Gmeiner wrote: > Hi Lucas, > > 2016-01-21 10:16 GMT+01:00 Lucas Stach : > > Am Dienstag, den 19.01.2016, 09:18 + schrieb Russell King: > >> Export further minor feature bitmasks and the varyings count from > >> the GPU specifications

[PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.

Is there a PATCH 2/2 which I can't find, or is the subject wrong? On 01/21/2016 09:16 AM, Mario Kleiner wrote: > The hardware vblank counter of AMD gpu's resets to zero during a > modeset. The new implementation of drm_update_vblank_count() from > commit 4dfd6486 "drm: Use vblank timestamps to

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote: > On 21.01.2016 16:58, Daniel Vetter wrote: > > On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote: > >> On 21.01.2016 15:38, Michel Dänzer wrote: > >>> On 21.01.2016 14:31, Mario Kleiner wrote: > On 01/21/2016 04:43

[PATCH 3/3] drm/amdgpu: Switch to drm_vblank_on/off

Equivalent change to the radeon driver. Note that with radeon this caught a bug in the dri3 DDX implementation, which asked for vblank interrupts when the pipe is off. That bug needs to be fixed before we can merge this patch (if amdgpu is affected too). Michel discovered this one. Cc: Michel

[PATCH 2/3] drm/radeon: Switch to drm_vblank_on/off

These should be functionally equivalent to the older per/post modeset functions, except that they block out drm_vblank_get right away. There's only the clock adjusting code (outside of pageflips) in readone which uses drm_vblank_get. But that code doesn't synchronize against concurrent modesets

[PATCH 1/3] drm/nouveau: Use drm_vblank_on/off consistently

In commit 9cba5efab5a8145ae6c52ea273553f069c294482 Author: Mario Kleiner Date: Tue Jul 29 02:36:44 2014 +0200 drm/nouveau: Dis/Enable vblank irqs during suspend/resume drm_vblank_on/off calls where added around suspend/resume to make sure vblank stay doesn't go boom over that transition.

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

On 18 January 2016 at 22:53, Marek Olšák wrote: > Try explaining that to people who have a compulsion to fix them or > argue about them. :) Ignore? REALLY? IGNORE??? > Now that we have a few people off your back can you please point out where this triggers warnings ? I've tried multiple times

[PATCH 11/11] staging/android: remove sync_fence_create_dma()

From: Gustavo Padovan With the removal of struct sync_pt sync_fence_create_dma() now takes the same arguments as sync_fence_create() so let's keep only sync_fence_create(). Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 8 +---

[PATCH 10/11] staging/android: remove pointless sync_timeline_signal at destroy phase

From: Gustavo Padovan All changes to timeline value come through the user via sync_timeline_signal() calls. When sync_timeline_destroy() is called no changes on timeline->value happens hence call sync_timeline_signal() with no increment is pointless.

[PATCH 09/11] staging/android: remove unused var from sync_timeline_signal()

From: Gustavo Padovan signaled_pts is not used in this function. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index

[PATCH 08/11] staging/android: remove struct sync_pt

From: Gustavo Padovan struct sync_pt was just wrapping around struct fence and creating an extra abstraction layer. The only two members of struct sync_pt, child_list and active_list, were moved to struct fence in an earlier commit. After removing those two

[PATCH 07/11] staging/android: rename 'sync_pt' to 'fence' in struct sync_fence_cb

From: Gustavo Padovan 'sync_pt' is actually declared as struct fence so to make the name means its type we rename it to 'fence'. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 20 ++-- drivers/staging/android/sync.h

[PATCH 06/11] staging/android: rename sync_fence to sync_file

From: Gustavo Padovan sync_file has a more close meaning to what a sync_fence really, a struct that represent a file that can be used by userspace to get information on a fence, or wait for it to be signaled. Signed-off-by: Gustavo Padovan ---

[PATCH 05/11] staging/android: move SW_SYNC_USER to a debugfs file

From: Gustavo Padovan This remove CONFIG_SW_SYNC_USER and instead compile the sw_sync file into debugpfs under /sync/sw_sync. Signed-off-by: Gustavo Padovan --- drivers/staging/android/Kconfig | 9 --- drivers/staging/android/sw_sync.c| 129

[PATCH 04/11] staging/android: create a 'sync' dir for debugfs information

From: Gustavo Padovan Creates the 'sync' dir on debugfs root dir and move the 'sync' file to sync/info. This is the preparation to add more debug info and control. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync_debug.c | 21

[PATCH 03/11] staging/android: remove not used sync_timeline ops

From: Gustavo Padovan .dup and .compare are not used by the sync framework, so remove them from sw_sync. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c | 29 + drivers/staging/android/sync.c| 6 --

[PATCH 02/11] staging/android: sync: remove interfaces that are not used

From: Gustavo Padovan These interfaces are not used nor have plans to be used in the near future so remove them for a cleaner solution before de-staging the sync framework. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 56

[PATCH 01/11] staging/android: fix sync framework documentation

From: Gustavo Padovan Updates comments about functions and structures. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.h | 45 -- 1 file changed, 21 insertions(+), 24 deletions(-) diff --git

[PATCH 00/11] sync framework de-staging: part 1 - clean up

From: Gustavo Padovan Hi, The following patches are some clean ups on the sync framework before we start the actual de-staging. The main changes here are the move of SW_SYNC_USER to debugfs. Removal of struct sync_pt in favor of direct use of struct fence. And

[PATCH 2/2] drm: etnaviv: add further minor features and varyings count

Am Dienstag, den 19.01.2016, 09:18 + schrieb Russell King: > Export further minor feature bitmasks and the varyings count from > the GPU specifications registers to userspace. > > Signed-off-by: Russell King I guess you have MESA changes that depend on this

[PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.

On 01/21/2016 09:25 AM, Michel Dänzer wrote: > On 21.01.2016 17:16, Mario Kleiner wrote: >> >> This patch replaces calls to drm_vblank_pre/post_modeset in the >> drivers dpms code with calls to drm_vblank_off/on, as recommended >> for drivers with hw counters that reset to zero during modeset. >

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On 01/21/2016 09:28 AM, Mario Kleiner wrote: >> ... just like drm_vblank_pre/post_modeset. That those were broken is a >> regression which needs to be fixed anyway. I don't think switching to >> drm_vblank_on/off is suitable for stable trees. >> >> Looking at Vlastimil's original post again, I'd

[PATCH 2/2] drm: etnaviv: add further minor features and varyings count

Am Mittwoch, den 20.01.2016, 19:01 +0100 schrieb Christian Gmeiner: > Hi Russell > > 2016-01-19 11:21 GMT+01:00 Russell King - ARM Linux arm.linux.org.uk>: > > On Tue, Jan 19, 2016 at 11:09:57AM +0100, Christian Gmeiner wrote: > >> Hi Russell, > >> > >> 2016-01-19 10:18 GMT+01:00 Russell King

[Bug 93801] GRID Autosport hang on logo (startup)

//lists.freedesktop.org/archives/dri-devel/attachments/20160121/a0610dcb/attachment.html>

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On 01/21/2016 07:38 AM, Michel Dänzer wrote: > On 21.01.2016 14:31, Mario Kleiner wrote: >> On 01/21/2016 04:43 AM, Michel Dänzer wrote: >>> On 21.01.2016 05:32, Mario Kleiner wrote: So the problem is that AMDs hardware frame counters reset to zero during a modeset. The old DRM

[PATCH] drm/rockchip: fix wrong pitch/size using on gem

args->pitch and args->size may not be set by userspace, sometimes userspace only malloc args and not memset args to zero, then args->pitch and args->size is random, it is very danger to use pitch/size on gem. pitch's type is u32, and min_pitch's type is int, example, pitch is 0x, then

[PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.

The hardware vblank counter of AMD gpu's resets to zero during a modeset. The new implementation of drm_update_vblank_count() from commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed", introduced in Linux 4.4, treats that as a counter wraparound and causes the

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On Thu, Jan 21, 2016 at 03:41:27PM +0900, Michel Dänzer wrote: > On 21.01.2016 15:38, Michel Dänzer wrote: > > On 21.01.2016 14:31, Mario Kleiner wrote: > >> On 01/21/2016 04:43 AM, Michel Dänzer wrote: > >>> On 21.01.2016 05:32, Mario Kleiner wrote: > > So the problem is that AMDs

[Bug 93758] mpv + st/va: add motion adaptive deinterlacing v2 = segfault/assert

n HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/6b021f73/attachment.html>

[PATCH v2 0/3] drm/rockchip: fix cursor performance with atomic

On 2016年01月19日 18:46, John Keeping wrote: > The first two patches are unchanged since v1 but the comment in the > third has been expanded following Thierry's comments. > > John Keeping (3): >drm/atomic-helper: Export framebuffer_changed() >drm/rockchip: don't wait for vblank if fb

[Bug 93753] Sometimes wrong clk frequency of Display after dpms mode changes.

|major |critical -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160121/2fe1b843/attachment.html>

linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

On 01/21/2016 04:43 AM, Michel Dänzer wrote: > On 21.01.2016 05:32, Mario Kleiner wrote: >> >> So the problem is that AMDs hardware frame counters reset to >> zero during a modeset. The old DRM code dealt with drivers doing that by >> keeping vblank irqs enabled during modesets and incrementing

PROBLEM: Intel HDMI output busticated on 4.4 (regression)

On 1/20/16, Nick Bowler wrote: > Hi, > > On 2016-01-20, Jindal, Sonika wrote: >> Can you please check if you have following patch: >> "commit 3d8acd1f667b45c531401c8f0c2033072e32a05d >> Author: Gary Wang >> Date: Wed Dec 23 16:11:35 2015 +0800 >> >> drm/i915: increase the tries for HDMI

  1   2   >