[Bug 105021] suspend / rx550 / extremely slow after 2nd thaw

https://bugs.freedesktop.org/show_bug.cgi?id=105021 --- Comment #23 from arne_woer...@yahoo.com --- i did another experiment: i set amdgpu.dc=1 and left amdgpu.msi and amdgpu.audio unchanged and installed the new firmware (180119-2). result: i still get this slowness error during second thaw:

[ANNOUNCE] libdrm 2.4.90

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrey Grodzovsky (2): amdgpu: Update deadlock test to not assert on ECANCELED amdgpu: Fix segfault in deadlock test. Anuj Phogat (1): intel: Add more Coffeelake PCI IDs Bas Nieuwenhuizen (1): drm: Fix 32-bit drmSyncobjWait.

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #32 from Bong Cosca --- Piglit results improved with only 70 fails, after stopping at 23705 tests. This also works: raster_config = 0x000f; -- You are receiving this mail because: You are the assignee

[Bug 105140] clearing related crash in Dying Light

https://bugs.freedesktop.org/show_bug.cgi?id=105140 --- Comment #1 from Roland Scheidegger --- Looks like pretty much the same issue as 105139 to me. Somehow a depth/stencil format texture gets attached as a color attachment (I can't think of any reason why anyone would even

[Bug 105140] clearing related crash in Dying Light

https://bugs.freedesktop.org/show_bug.cgi?id=105140 Bug ID: 105140 Summary: clearing related crash in Dying Light Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal

Re: [PATCH 06/10] drm: Define helper to set legacy gamma table size

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #31 from Bong Cosca --- This fixes the problem for me: case CHIP_KAVERI: /* KV should be 0x0002, but that causes problems with radeon */ raster_config = 0x0003;

Re: [PATCH 04/10] drm: Add Plane Gamma properties

On 2018-02-16 03:10 PM, Ville Syrjälä wrote: > On Thu, Feb 15, 2018 at 02:45:29PM -0500, Daniele Castagna wrote: >> rk3399 has the option of setting per-plane gamma. >> The YUV2YUV registers are per-plane. Each plane YUV2YUV pipeline has >> at least 3 optional stages, two of those being degamma

Re: [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31

Hi, On Fri, Feb 16, 2018 at 4:34 AM, Enric Balletbo Serra wrote: > Hi, > > 2018-01-31 17:52 GMT+01:00 Doug Anderson : >> Hi, >> >> >> On Wed, Jan 31, 2018 at 7:16 AM, Sean Paul wrote: >>> On Wed, Jan 31, 2018 at 7:54 AM, Lucas

Re: [PATCH v2 1/8] dt-bindings: add binding for Rockchip hdmi phy using an Innosilicon IP

Am Freitag, 16. Februar 2018, 21:41:51 CET schrieb Heiko Stuebner: > From: Zheng Yang > > The phy is used so far in two Rockchip socs the rk3228 and the rk3328. > > Signed-off-by: Zheng Yang > Signed-off-by: Heiko Stuebner

[PATCH v2 5/8] dt-bindings: allow optional phys in Rockchip dw_hdmi binding

Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general mmio, so allow these to be referenced via the regular phy interfaces and therefore add optional phy-related properties to the binding. Signed-off-by: Heiko Stuebner ---

[PATCH v2 6/8] drm/rockchip: dw_hdmi: allow including external phys

Some variants of the dw-hdmi on Rockchip socs use a separate phy block accessed via the generic phy framework, so allow them to be included if such a phy reference is found. Signed-off-by: Heiko Stuebner --- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++ 1 file

[PATCH v2 2/8] phy: add Rockchip Innosilicon hdmi phy

From: Zheng Yang Add a driver for the Innosilicon hdmi phy used on rk3228/rk3229 and rk3328 socs from Rockchip. Signed-off-by: Zheng Yang Signed-off-by: Heiko Stuebner --- Patches 1+2 expected to go through the phy-tree

[PATCH v2 4/8] drm/rockchip: dw_hdmi: Allow outputs that don't need output switching

So far we always encountered socs with 2 output crtcs needing the driver to tell the hdmi block which output to connect to. But there also exist socs with only one crtc like the rk3228, rk3328 and rk3368. So adapt the register field to simply carry a negative value to signal that now

[PATCH v2 8/8] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328

The rk3328 uses an external hdmi phy from Innosilicon which uses the generic phy framework for access. Add the necessary data and the compatible for it. Signed-off-by: Heiko Stuebner --- .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 1 +

[PATCH v2 1/8] dt-bindings: add binding for Rockchip hdmi phy using an Innosilicon IP

From: Zheng Yang The phy is used so far in two Rockchip socs the rk3228 and the rk3328. Signed-off-by: Zheng Yang Signed-off-by: Heiko Stuebner --- .../bindings/phy/phy-rockchip-inno-hdmi.txt| 42

[PATCH v2 7/8] drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object

When using special phy handling operations we'll often need access to the rockchip_hdmi struct. As the chip-data that occupies the phy_data pointer initially gets assigned to the rockchip_hdmi struct we can not re-use this phy_data pointer to hold the reference to the rockchip_hdmi struct, similar

[PATCH v2 3/8] drm/bridge: dw-hdmi: allow overriding of phy-type reading

In some IP implementations the reading of the phy-type may be broken. One example are the Rockchip rk3228 and rk3328 socs that use a separate phy from Innosilicon but still report the HDMI20_TX type. So allow the glue driver to force a specific type, like the vendor-phy for these cases.

[PATCH v2 0/8] drm/rockchip: hdmi support for rk3328

The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy from Innosilicon that resides completely separate from the dw-hdmi block and gets accessed via mmio. Additionally the rk3328 dw-hdmi does not report the vendor-phy type but a different one instead, so add the possibility to

Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

On Thu, Feb 15, 2018 at 06:54:48PM +0100, Giulio Benetti wrote: > Differently from other Lcd signals, HSYNC and VSYNC signals > result inverted if their bits are cleared to 0. > > Invert their settings of IO_POL register. > > Signed-off-by: Giulio Benetti

[PATCH] drm/bridge: dw-hdmi: Remove unused hdmi_enable_overflow_interrupts()

From: Fabio Estevam The cable_plugin member never receives an assignment, so it is always false, which causes hdmi_enable_overflow_interrupts() to never be called as per the logic below: if (hdmi->cable_plugin && hdmi->sink_is_hdmi)

Re: [PATCH 04/10] drm: Add Plane Gamma properties

On Thu, Feb 15, 2018 at 02:45:29PM -0500, Daniele Castagna wrote: > rk3399 has the option of setting per-plane gamma. > The YUV2YUV registers are per-plane. Each plane YUV2YUV pipeline has > at least 3 optional stages, two of those being degamma and gamma, and > they can be configured per-plane. >

Re: [PATCH 02/10] drm: Add Plane Degamma properties

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

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

On Thu, 2018-02-15 at 11:55 -0800, Rodrigo Vivi wrote: > Dave Airlie writes: > > > On 6 February 2018 at 06:32, Rodrigo Vivi wrote: > >> On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote: > >>> Dhinakaran Pandiyan

Re: [PATCH 2/2] drm/msm: Add A6XX device support

Hi Jordan, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on next-20180216] [cannot apply to v4.16-rc1] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH] drm/rcar-du: dw-hdmi: Fix compilation

On Fri, Feb 16, 2018 at 10:53:08AM -0500, Sean Paul wrote: > On Fri, Feb 16, 2018 at 04:44:12PM +0100, Maxime Ripard wrote: > > Commit eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata") > > broke the build with one build error and one warning. Fix both. > > Reviewed-by: Sean

Re: [PATCH v3 1/8] drm/blend: Add a generic alpha property

On Fri, Feb 16, 2018 at 06:39:29PM +0100, Maxime Ripard wrote: > Some drivers duplicate the logic to create a property to store a per-plane > alpha. > > This is especially useful if we ever want to support extra protocols for > Wayland like: >

Re: [PATCH 01/10] drm/rockchip: YUV overlays BT.601 color conversion.

Hi Daniele, Thank you for the patch! Yet something to improve: [auto build test ERROR on rockchip/for-next] [also build test ERROR on v4.16-rc1 next-20180216] [cannot apply to drm/drm-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

[PATCH v3 6/8] drm/sun4i: backend: Make zpos configurable

Now that we have everything in place, we can make zpos configurable now. Change the zpos property from an immutable one to a regular. Reviewed-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_layer.c | 5 +++-- 1 file

[PATCH v3 4/8] drm/sun4i: backend: Assign the pipes automatically

Since we now have a way to enforce the zpos, check for the number of alpha planes, the only missing part is to assign our pipe automatically instead of hardcoding it. The algorithm is quite simple, but requires two iterations over the list of planes. In the first one (which is the same one that

[PATCH v3 2/8] drm/atmel-hclcdc: Convert to the new generic alpha property

Now that we have support for per-plane alpha in the core, let's use it. Acked-by: Boris Brezillon Signed-off-by: Maxime Ripard --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +--- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c

[PATCH v3 7/8] drm/sun4i: Add support for plane alpha

Our backend supports a per-plane alpha property. Support it through our new helper. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_backend.c | 16 +--- drivers/gpu/drm/sun4i/sun4i_backend.h | 3 +++ drivers/gpu/drm/sun4i/sun4i_layer.c | 2

[PATCH v3 0/8] drm/sun4i: Support more planes, zpos and plane-wide alpha

Hi, This serie aims at enhancing the support for our planes in the current drm driver on the first generation of Allwinner's display engine. This also introduces a few generic stuff, as well as some conversion for some other drivers. This series basically implements three things that look

[PATCH v3 8/8] drm/sun4i: backend: Remove ARGB spoofing

We've had some code for quite some time to prevent the alpha bug from happening on the lowest primary plane. Since we now check for this in our atomic_check, we can simply remove it. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_backend.c | 12

[PATCH v3 5/8] drm/sun4i: Remove the plane description structure

The plane description structure was mostly needed to differentiate the formats usable on the primary plane (because of its lowest position), and assign the pipes. Now that both are dynamically checked and assigned, we can remove the static definition. Signed-off-by: Maxime Ripard

[PATCH v3 1/8] drm/blend: Add a generic alpha property

Some drivers duplicate the logic to create a property to store a per-plane alpha. This is especially useful if we ever want to support extra protocols for Wayland like: https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html Let's create a helper in order to move that to the

[PATCH v3 3/8] drm/rcar-du: Convert to the new generic alpha property

Now that we have support for per-plane alpha in the core, let's use it. Reviewed-by: Laurent Pinchart Signed-off-by: Maxime Ripard --- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5

Re: [PATCH v2 3/5] drm/virtio: add in-fences support for explicit synchronization

On Fri, Feb 16, 2018 at 9:12 AM, Gustavo Padovan wrote: > From: Gustavo Padovan > > When the execbuf call receives an in-fence it will get the dma_fence > related to that fence fd. If that fence is from a foreign context we wait > on it before

[PATCH 6/6] drm: intel_dpio_phy: fix kernel-doc comments at nested struct

The in-lined comments for channel.port doesn't follow the syntax described at kernel-doc document, causing the following warning: $ ./scripts/kernel-doc -none drivers/gpu/drm/i915/intel_dpio_phy.c drivers/gpu/drm/i915/intel_dpio_phy.c:154: warning: Function parameter or member

Re: [PATCH 0/4] Move DP phy switch to PHY driver

On Friday 16 February 2018 06:35 PM, Heiko Stübner wrote: > Hi Kishon, > > Am Freitag, 16. Februar 2018, 12:04:42 CET schrieb Kishon Vijay Abraham I: >> On Friday 10 February 2017 01:14 PM, Chris Zhong wrote: >>> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence >>> only one

[PATCH] drm: fix off-by-one in logger

The current implementation will leak a byte to the log via memmove. The specified 27 bytes are off-by-one, as the payload is 25 bytes, and the termination character is only one byte large. To avoid this, factor out the error message, and furthermore make the second parameter of the append_entry

[PATCH 0/6] Add support for in-line nested struct comments

This series fix two bugs at kernel-doc.rst examples and add support for in-line nested struct comments. It also converts one documentation at intel_dpio_phy to use it, in order to give a practical example about how to use it. Mauro Carvalho Chehab (6): doc-guide: kernel-doc: fix example for

Re: [PATCH 0/4] Move DP phy switch to PHY driver

Hi, On Friday 10 February 2017 01:14 PM, Chris Zhong wrote: > > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence > only one PHY can connect to DP controller at one time, the other should > be disconnected. The GRF_SOC_CON26 register has a switch bit to do it, > set this bit

Re: [radeon-alex:amd-staging-dkms-4.13 3810/3830] drivers/gpu/drm/radeon/radeon_kfd.c:166:3: error: 'const struct kfd2kgd_calls' has no member named 'open_graphic_handle'

amd-staging-drm-next has removed radeon_kfd.c. Those changes seem to be missing from amd-staging-dkms-4.13. Regards,   Felix On 2018-02-15 04:44 PM, kbuild test robot wrote: > tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13 > head:

Re: [PATCH] drm/rcar-du: dw-hdmi: Fix compilation

On Fri, Feb 16, 2018 at 04:44:12PM +0100, Maxime Ripard wrote: > Commit eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata") > broke the build with one build error and one warning. Fix both. Reviewed-by: Sean Paul > > Cc: Archit Taneja

Re: [PATCH] Update Boris Brezillon email address

On Fri, 16 Feb 2018 16:35:27 +0100 Kamil Konieczny wrote: > On 16.02.2018 15:54, Boris Brezillon wrote: > > Adding back all the people that were Cc-ed on the initial email. > > > > On Fri, 16 Feb 2018 15:18:21 +0100 > > Kamil Konieczny

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

On Thu, Feb 15, 2018 at 07:05:56PM +0100, Giulio Benetti wrote: > > If so, and if remember the captures properly, the sampling would occur > > right before the rise, and not really around the fall. > > > > Would 2/3 be better here? > > Yes, you're right, 2/3 phase is better: > > 1/3 phase:

[PATCH] drm/rcar-du: dw-hdmi: Fix compilation

Commit eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata") broke the build with one build error and one warning. Fix both. Cc: Archit Taneja Cc: Jernej Skrabec Cc: Laurent Pinchart Fixes:

[PATCH] radeon: hide pointless #warning when compile testing

In randconfig testing, we sometimes get this warning: drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create': drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp]

[PATCH v2 4/5] drm/virtio: add out-fences support for explicit synchronization

From: Gustavo Padovan On the out-fence side we get fence returned by the submitted draw call and attach it to a sync_file and send the sync_file fd to userspace. On error -1 is returned to userspace. Signed-off-by: Gustavo Padovan

[PATCH v2 5/5] drm/virtio: bump driver version after explicit synchronization addition

From: Gustavo Padovan To reflect the (backward compatible) changes in the uabi we are bumping the driver's version. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH v2 2/5] drm/virtio: add uapi for in and out explicit fences

From: Gustavo Padovan Add a new field called fence_fd that will be used by userspace to send in-fences to the kernel and receive out-fences created by the kernel. This uapi enables virtio to take advantage of explicit synchronization of dma-bufs. There are two

[PATCH v2 1/5] drm/virtio: add virtio_gpu_alloc_fence()

From: Gustavo Padovan Refactor fence creation to remove the potential allocation failure from the cmd_submit and atomic_commit paths. Now the fence should be allocated first and just after we should proceed with the rest of the execution. v2: - only alloc

[PATCH v2 3/5] drm/virtio: add in-fences support for explicit synchronization

From: Gustavo Padovan When the execbuf call receives an in-fence it will get the dma_fence related to that fence fd. If that fence is from a foreign context we wait on it before submitting the draw call. v2: - incorporate fix for context check from Rob Herring

[PATCH v2 0/5] virgl: fence fd support

From: Gustavo Padovan Hi, So I finally got around to finish this work! :) Here are the updated patchset with fixes for Rob Herring incorporated. This follow pretty much the same semantics of other drivers that implemented explicit fence support. It extends the

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

On Mon, Nov 27, 2017 at 11:57:46AM -0500, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove pci_get_bus_and_slot()

Re: [PATCH] Update Boris Brezillon email address

Adding back all the people that were Cc-ed on the initial email. On Fri, 16 Feb 2018 15:18:21 +0100 Kamil Konieczny wrote: > On 16.02.2018 15:00, Boris Brezillon wrote: > > On Fri, 16 Feb 2018 12:21:53 +0100 > > Kamil Konieczny

Re: [PATCH 1/3] drm: add func to get max iomem address v2

Quoting Chunming Zhou (2018-02-09 02:44:08) > it will be used to check if the driver needs swiotlb > v2: Don't use inline, instead, move function to drm_memory.c (Mechel Daenzer > ) > > Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3 > Signed-off-by: Chunming Zhou

Re: [PATCH] drm: move read_domains and write_domain into i915 v2

Quoting Christian König (2018-02-16 12:43:38) > i915 is the only driver using those fields in the drm_gem_object > structure, so they only waste memory for all other drivers. > > Move the fields into drm_i915_gem_object instead and patch the i915 code > with the following sed commands: > > sed

Re: [PATCH] drm: mali-dp: Report underrun and axi bus errors

Hi Alex, On Thu, Feb 15, 2018 at 07:33:15PM +, Alexandru Gheorghe wrote: > Errors will be reported in /sys/kernel/debug/tracing/trace, > still not noisy enough, but better than silently ignoring them. > E.g: > -0 [000] d.h1 183.851864: malidp_de_irq: error occurred DE_STATUS > is

[PATCH 2/4] qxl: move qxl_send_monitors_config()

Needed to avoid a forward declaration in a followup patch. Pure code move, no functional change. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 47 +++ 1 file changed, 23 insertions(+), 24 deletions(-) diff --git

[PATCH 3/4] qxl: hook monitors_config updates into crtc, not encoder.

The encoder callbacks are only called in case the video mode changes. So any layout changes without mode changes will go unnoticed. Add qxl_crtc_update_monitors_config(), based on the old qxl_write_monitors_config_for_encoder() function. Hook it into the enable, disable and flush atomic crtc

[PATCH 4/4] qxl: drop dummy functions

These days drm core checks function pointers everywhere before calling them. So we can drop a bunch of dummy functions now. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_display.c | 50 --- 1 file changed, 50 deletions(-) diff

[PATCH 1/4] qxl: remove qxl_io_log()

qxl_io_log() sends messages over to the host (qemu) for logging. Remove the function and all callers, we can just use standard DRM_DEBUG calls (and if needed a serial console). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_drv.h | 3 ---

[PATCH 0/4] qxl: multihead fixes, cleanups

Gerd Hoffmann (4): qxl: remove qxl_io_log() qxl: move qxl_send_monitors_config() qxl: hook monitors_config updates into crtc, not encoder. qxl: drop dummy functions drivers/gpu/drm/qxl/qxl_drv.h | 3 - drivers/gpu/drm/qxl/qxl_cmd.c | 36 +

Re: [PATCH 0/4] Move DP phy switch to PHY driver

Hi Kishon, Am Freitag, 16. Februar 2018, 12:04:42 CET schrieb Kishon Vijay Abraham I: > On Friday 10 February 2017 01:14 PM, Chris Zhong wrote: > > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence > > only one PHY can connect to DP controller at one time, the other should > >

[PATCH] drm: move read_domains and write_domain into i915 v2

i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all other drivers. Move the fields into drm_i915_gem_object instead and patch the i915 code with the following sed commands: sed -i "s/obj->base.read_domains/obj->read_domains/g"

Re: [PATCH] drm: fix off-by-one in logger

On Fri, 2018-02-16 at 10:43 +0100, Norbert Manthey wrote: > The current implementation will leak a byte to the log via memmove. The > specified 27 bytes are off-by-one, as the payload is 25 bytes, and the > termination character is only one byte large. To avoid this, factor out > the error

Re: [PATCH] drm: move read_domains and write_domain into i915

Am 16.02.2018 um 13:30 schrieb Chris Wilson: Quoting Christian König (2018-02-16 12:27:28) Am 16.02.2018 um 11:18 schrieb Chris Wilson: Quoting Christian König (2018-02-16 09:31:23) i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all

Re: [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31

Hi, 2018-01-31 17:52 GMT+01:00 Doug Anderson : > Hi, > > > On Wed, Jan 31, 2018 at 7:16 AM, Sean Paul wrote: >> On Wed, Jan 31, 2018 at 7:54 AM, Lucas Stach wrote: >>> Am Dienstag, den 30.01.2018, 21:29 +0100 schrieb Thierry

Re: i915 runtime PM (was: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers)

On Fri, Feb 16, 2018 at 09:49:28AM +0100, Lukas Wunner wrote: > [trimming cc: a little to avoid spamming folks not directly involved with > i915] > > On Mon, Feb 12, 2018 at 03:04:06PM +0200, Imre Deak wrote: > > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote: > > > i915, malidp

Re: [PATCH] drm: move read_domains and write_domain into i915

Quoting Christian König (2018-02-16 12:27:28) > Am 16.02.2018 um 11:18 schrieb Chris Wilson: > > Quoting Christian König (2018-02-16 09:31:23) > >> i915 is the only driver using those fields in the drm_gem_object > >> structure, so they only waste memory for all other drivers. > >> > >> Move the

Re: [PATCH] drm: move read_domains and write_domain into i915

Am 16.02.2018 um 11:18 schrieb Chris Wilson: Quoting Christian König (2018-02-16 09:31:23) i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all other drivers. Move the fields into drm_i915_gem_object instead and patch the i915 code with

[PATCH RFC 7/9] drm/omap: dss: platform_register_drivers() to dss.c and remove core.c

The core.c just for registering the drivers is kind of useless. Let's get rid of it and register the dss drivers in dss.c. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/omapdrm/dss/Makefile | 2 +- drivers/gpu/drm/omapdrm/dss/core.c | 66

[PATCH RFC 4/9] drm/omap: Make omapdss API more generic

The new omapdss API is HW independent and cleans up some of the DSS5 specific hacks from the omapdrm side and gets rid off the DSS5 IRQ register bits and replace them with HW independent generic u64 based macros. The new macros make it more straight forward to implement the IRQ code for the future

[PATCH RFC 8/9] drm/omap: add TI DSS6 driver

From: Tomi Valkeinen Add support for DSS6 IP on TI K2G SoC. DSS6 is an evolution of the OMAP DSS (DSS2). OMAP DSS has been quite similar from OMAP2 to OMAP5 (including DRA7 and AM5 which have basically the same IP as OMAP5), but in DSS6 lots of things have been

[PATCH RFC 6/9] drm/omap: dss: Move platform_device_register from core.c to dss.c probe

Register the omapdrm device when we know that dss device probe going to succeed. This avoids DSS6 and DSS2 omapdrm device registration from colliding with each other. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/omapdrm/dss/core.c | 26 ++

[PATCH RFC 9/9] drm/omap: boot-init: add k2g-dss

From: Tomi Valkeinen Add "ti,k2g-dss" to the list of DSS devices which need the mangling of the panels' & encoders' compatible strings. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 1 + 1 file changed, 1

[PATCH RFC 0/9] drm/omap: DSS6 with dynamically allocated objects

This series is an RFC or a proof of concept, to demostrate what is needed to get DSS6 driver workin on top of Laurent Pinchart's "omapdrm: Allocate objects dynamically" -series: https://patchwork.freedesktop.org/series/38152/ This series also contains my earlier "drm/omap: Make omapdss API more

[PATCH RFC 1/9] drm/omap: Update omapdss API to allow alternative DSS implementations

After this patch OMAP_DSS_BASE module is not including any OMAP2_DSS headers, only the API omapdss.h. "sturct dss_data", the piece of the data structure needed for base.c is defined in omapdss.h and added as a member to struct dss_device, and later to struct dss6_device. The patch is still a bit

[PATCH RFC 5/9] drm/omap: move common stuff from dss.h to omapdss.h

The new DSS6 driver needs some structs and defines which are currently in dss.h, which is for the old DSS driver. Move the required structs and defines from dss.h to omapdss.h. Signed-off-by: Tomi Valkeinen Signed-off-by: Jyri Sarha ---

[PATCH RFC 2/9] drm/omap: Fail probe if irq registration fails

Call to omap_drm_irq_install() may fail with an error code. In such a case the driver probe should fail. Signed-off-by: Jyri Sarha Reviewed-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

[PATCH RFC 3/9] drm/omap: Add ovl_name() and mgr_name() to dispc_ops

Add ovl_name() and mgr_name() to dispc_ops and get rid of adhoc names here and there in the omapdrm code. This moves the names of hardware entities to omapdss side where they have to be when new omapdss backend drivers are introduced. Signed-off-by: Jyri Sarha Reviewed-by: Tomi

Re: [PATCH v3 1/2] drm/virtio: Add window server support

> > Yes. > > Would it make sense for virtio-gpu to map buffers to the guest via PCI BARs? > So we can use a single drm driver for both 2d and 3d. Should be doable. I'm wondering two things though: (1) Will shmem actually help avoiding a copy? virtio-gpu with virgl will (even if the guest

[PATCH] Update Boris Brezillon email address

Free Electrons is now Bootlin. Signed-off-by: Boris Brezillon --- Note that I'm planning to take this patch through the MTD tree. --- .mailmap| 7 --- MAINTAINERS | 10 +- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/.mailmap

Re: [PATCH] drm: move read_domains and write_domain into i915

Quoting Christian König (2018-02-16 09:31:23) > i915 is the only driver using those fields in the drm_gem_object > structure, so they only waste memory for all other drivers. > > Move the fields into drm_i915_gem_object instead and patch the i915 code > with the following sed commands: > > sed

[Bug 104090] Reduced colors on RX580 through eDP on Asus GL702ZC laptop

https://bugs.freedesktop.org/show_bug.cgi?id=104090 --- Comment #15 from Hein-Pieter van Braam --- I just upgraded to 4.16.0-rc1 and the problem is still there with dc=1 -- You are receiving this mail because: You are the assignee for the

[PATCH] drm: move read_domains and write_domain into i915

i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all other drivers. Move the fields into drm_i915_gem_object instead and patch the i915 code with the following sed commands: sed -i "s/obj->base.read_domains/obj->read_domains/g"

[PATCH 2/2] drm/radeon: use drm_gem_private_object_init

We use our own backing store and don't need the shmem file. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_object.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c

[PATCH 1/2] drm/amdgpu: use drm_gem_private_object_init

We use our own backing store and don't need the shmem file. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c

Re: [PATCH v5 00/12] drm/sun4i: Add A83T HDMI support

On Wed, Feb 14, 2018 at 09:08:54PM +0100, Jernej Skrabec wrote: > This patch series implements support for A83T DW HDMI and PHY. Contrary to > v1 series, this one is based on latest linux-next, since all needed patches > were merged. > > While exactly this combination of HDMI controller and PHY

i915 runtime PM (was: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers)

[trimming cc: a little to avoid spamming folks not directly involved with i915] On Mon, Feb 12, 2018 at 03:04:06PM +0200, Imre Deak wrote: > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote: > > i915, malidp and msm "solved" this issue by not stopping the poll worker > > on runtime

[Bug 104597] [bisected] Compton weird colors

https://bugs.freedesktop.org/show_bug.cgi?id=104597 --- Comment #13 from Michel Dänzer --- (In reply to gloriouseggroll from comment #12) > adding this for obs resolves > https://bugs.freedesktop.org/show_bug.cgi?id=104540 That probably means it's an OBS bug, not handling

Re: [PATCH v3 06/12] ARM: dts: r8a7790: Convert to new LVDS DT bindings

On Thu, Feb 15, 2018 at 02:04:09AM +0200, Laurent Pinchart wrote: > The internal LVDS encoder now has DT bindings separate from the DU. Port > the device tree over to the new model. > > Signed-off-by: Laurent Pinchart I have marked this and the

Re: [PATCH 04/10] drm: Add Plane Gamma properties

rk3399 has the option of setting per-plane gamma. The YUV2YUV registers are per-plane. Each plane YUV2YUV pipeline has at least 3 optional stages, two of those being degamma and gamma, and they can be configured per-plane. I'm not sure about Intel HW. I think they might have something similar

Re: [PATCH v3 05/12] ARM: dts: porter: Fix HDMI output routing

On Thu, Feb 15, 2018 at 02:04:08AM +0200, Laurent Pinchart wrote: > The HDMI encoder is connected to the RGB output of the DU, which is > port@0, not port@1. Fix the incorrect DT description. > > Signed-off-by: Laurent Pinchart This patch is already

[Bug 105076] [CI] results file indicate incomplete run.log say other result

https://bugs.freedesktop.org/show_bug.cgi?id=105076 --- Comment #5 from Marta Löfstedt --- idea is to change the disk on glkb1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing