Re: [RfC PATCH] Add udmabuf misc device

On 04/10/2018 08:26 PM, Dongwon Kim wrote: On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote: On 04/06/2018 09:57 PM, Dongwon Kim wrote: On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote: On 04/06/2018 02:57 PM, Gerd Hoffmann wrote: Hi, I fail

[Bug 99078] Desktop icons oversaturated with red after December 11 2016 update

https://bugs.freedesktop.org/show_bug.cgi?id=99078 Timothy Arceri changed: What|Removed |Added Resolution|--- |WONTFIX

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

Am 11.04.2018 um 08:26 schrieb Huang Rui: On Tue, Apr 10, 2018 at 04:59:55PM -0400, Sinan Kaya wrote: Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't hold true universally especially for systems

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #10 from Peter --- Dear All, I have a similar problem, Kernel 4.15.16, Xeon CPU E3-1505M, Radeon R9 M295X. The Laptop runs fine, provided I'm not accessing the GPU. DRI_PRIME=0 glxinfo | grep "OpenGL

Re: AMD graphics performance regression in 4.15 and later

Am 11.04.2018 um 06:00 schrieb Gabriel C: 2018-04-09 11:42 GMT+02:00 Christian König : Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: Hi Christian, Thanks for the info. FYI, I've also opened a Firefox bug for that at:

[Bug 105597] [CI] igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transition - incomplete - Build timed out (after 18 minutes)

https://bugs.freedesktop.org/show_bug.cgi?id=105597 Marta Löfstedt changed: What|Removed |Added Priority|medium |highest --

[PATCH v6 2/5] 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 Reviewed-by: Laurent Pinchart Signed-off-by: Maxime Ripard ---

[PATCH v6 0/5] drm/blend: Support generic plane-wide alpha

Hi, This serie aims at enhancing the support for plane-wide alpha in the drivers that are implementing it at the moment, by turning it into a generic property and converting the drivers (rcar-du and atmel-hclcdc). It also introduces support for it in the sun4i driver. Let me know what you think,

[PATCH v6 4/5] drm/sun4i: Add support for plane alpha

Our backend supports a per-plane alpha property. Support it through our new helper. Reviewed-by: Chen-Yu Tsai Reviewed-by: Paul Kocialkowski Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_backend.c | 16

[PATCH v6 3/5] 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

[PATCH v6 1/5] 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 v6 5/5] drm/docs: Remove the rcar alpha from the csv file

Now that we moved the rcar-du DRM driver has been switched to the generic alpha property, remove the former property documentation from the deprecated CSV file. Reviewed-by: Laurent Pinchart Signed-off-by: Maxime Ripard ---

Re: AMD graphics performance regression in 4.15 and later

2018-04-09 11:42 GMT+02:00 Christian König : > Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: >> >> Hi Christian, >> >> Thanks for the info. FYI, I've also opened a Firefox bug for that at: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778 >> Feel free to

Re: AMD graphics performance regression in 4.15 and later

>2018-04-11 6:00 GMT+02:00 Gabriel C : > 2018-04-09 11:42 GMT+02:00 Christian König : >> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin: ... > I can help testing code for 4.17/++ if you wish but that is *different* > storry. > Quick tested

[RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

From: Ian W MORRISON As the Geminilake firmware is now merged to linux-firmware.git use MODUE_FIRMWARE to load the firmware. This removes the error message in the dmesg log: i915 :00:02.0: Direct firmware load for i915/glk_dmc_ver1_04.bin failed with

Re: [PATCH 0/3] Minor code cleanups in drm/scheduler

Added another week delay because of vacation, but I just pushed the patches into our branch. Thanks for the help, Christian. Am 29.03.2018 um 20:19 schrieb Christian König: Patches #2 and #3 are Reviewed-by: Christian König as well. If Lucas has no objections I'm

[PATCH v8 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel output converter. Signed-off-by: Jacopo Mondi Reviewed-by: Andrzej Hajda Reviewed-by: Niklas Söderlund ---

Re: [PATCH] drm/i2c: tda998x: Remove VLA usage

On Tue, Apr 10, 2018 at 02:52:35PM -0700, Laura Abbott wrote: > On 04/09/2018 03:21 PM, Russell King - ARM Linux wrote: > >On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote: > >>There's an ongoing effort to remove VLAs[1] from the kernel to eventually > >>turn on -Wvla. The vla in

Re: [Xen-devel] [RFC, v2, 1/9] hyper_dmabuf: initial upload of hyper_dmabuf drv core framework

Hi, On 04/10/2018 09:53 AM, Oleksandr Andrushchenko wrote: On 02/14/2018 03:50 AM, Dongwon Kim wrote: diff --git a/drivers/dma-buf/hyper_dmabuf/hyper_dmabuf_id.h [...] +#ifndef __HYPER_DMABUF_ID_H__ +#define __HYPER_DMABUF_ID_H__ + +#define HYPER_DMABUF_ID_CREATE(domid, cnt) \ +   

[PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't hold true universally especially for systems with IOMMU. IOMMU driver tries to combine buffers into a single DMA address as much as it can. The right

[PATCH v2] display: panel: Add AUO g070vvn01 display support (800x480)

This commit adds support for AUO's 7.0" display. Signed-off-by: Lukasz Majewski --- Changes for v2: - Add *.txt suffix to the auo,g070wn01 file - Remove not needed bus-format-override = "rgb565"; property --- .../bindings/display/panel/auo,g070vvn01.txt | 30

[PATCH v8 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

Hello, new version with last bits hopefully fixed. The vcc supply is now mandatory, as suggested by Mark Brown, and the driver requires it to be described in device tree. The "OE" GPIO is now described by 'oe' again, as I wrongly interpreted Rob's suggestions on v6. A few minor grammar fixes

[PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

The documentation was wrong, gpiod_get_direction() returns 0/1 instead of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 ("gpio: correct docs about return value of gpiod_get_direction"). Now, fix this user (until a better, system-wide solution is in place). Signed-off-by:

[PATCH] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't hold true universally especially for systems with IOMMU. IOMMU driver tries to combine buffers into a single DMA address as much as it can. The right

Re: [PATCH RESEND] backlight: pwm_bl: don't use GPIOF_* with gpiod_get_direction

On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote: > The documentation was wrong, gpiod_get_direction() returns 0/1 instead > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47 > ("gpio: correct docs about return value of gpiod_get_direction"). Now, > fix this user

Re: [PATCH 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.

Hi Eric, > Eric Anholt hat am 10. April 2018 um 01:00 geschrieben: > > > The GPU subsystem node was a workaround to have a central device to > bind V3D and display to. Following the lead of 246774d17fc0 > ("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove >

[PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Document Thine THC63LVD1024 LVDS decoder device tree bindings. Signed-off-by: Jacopo Mondi Reviewed-by: Andrzej Hajda Reviewed-by: Niklas Söderlund Reviewed-by: Laurent Pinchart

Batched ww-mutexes, wound-wait vs wait-die etc.

Hi! Thinking of adding ww-mutexes for reservation also of vmwgfx resources, (like surfaces), I became a bit worried that doubling the locks taken during command submission wouldn't be a good thing. Particularly on ESX servers where a high number of virtual machines running graphics on a

Re: [PATCH] drm/vc4: Add some missing HVS register definitions.

On Sat, Mar 3, 2018 at 12:03 AM, Eric Anholt wrote: > At least the RGBA expand field we should have been setting, because we > aren't expanding correctly for 565 -> . Other registers are ones > that may be interesting for various projects that have been discussed. > >

Re: [PATCHv2] drm/amdkfd: Remove vla

Am 11.04.2018 um 03:02 schrieb Laura Abbott: There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. Switch to a constant value that covers all hardware. [1] https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Laura Abbott It would be nicer

[Bug 105618] [CI] igt@kms_cursor_crc@cursor-128x128-suspend - incomplete - intel ips 0000:00:1f.6: ME failed to update for more than 1s, likely hung

https://bugs.freedesktop.org/show_bug.cgi?id=105618 Marta Löfstedt changed: What|Removed |Added Priority|medium |highest --

Re: RFC for a render API to support adaptive sync and VRR

On 2018-04-10 07:25 PM, Cyr, Aric wrote: >> From: Michel Dänzer [mailto:mic...@daenzer.net] >> On 2018-04-10 07:13 PM, Cyr, Aric wrote: From: Michel Dänzer [mailto:mic...@daenzer.net] On 2018-04-10 06:26 PM, Cyr, Aric wrote: > From: Koenig, Christian Sent: Tuesday, April 10, 2018

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

On Monday 09 April 2018 01:58 PM, Daniel Vetter wrote: On Fri, Apr 06, 2018 at 07:02:02PM +0300, Ville Syrjälä wrote: On Mon, Apr 02, 2018 at 02:35:42PM +0530, Ramalingam C wrote: On Thursday 29 March 2018 07:54 PM, Ville Syrjälä wrote: On Thu, Mar 29, 2018 at 07:39:07PM +0530, Ramalingam

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On Wed, 11 Apr 2018, ianwmorri...@gmail.com wrote: > From: Ian W MORRISON > > As the Geminilake firmware is now merged to linux-firmware.git > use MODUE_FIRMWARE to load the firmware. > > This removes the error message in the dmesg log: > > i915 :00:02.0: Direct

[Bug 105617] [CI] [CNL only] igt@* - incomplete - Build timed out (after 18 minutes). Marking the build as aborted.

https://bugs.freedesktop.org/show_bug.cgi?id=105617 Marta Löfstedt changed: What|Removed |Added Priority|medium |highest --

[Bug 105880] [dc][kabini] Cannot find any crtc or sizes

https://bugs.freedesktop.org/show_bug.cgi?id=105880 shital kanoje changed: What|Removed |Added URL||http:// --

Re: RFC for a render API to support adaptive sync and VRR

On 2018-04-11 08:57 AM, Nicolai Hähnle wrote: > On 10.04.2018 23:45, Cyr, Aric wrote: > For video games we have a similar situation where a frame is > rendered > for a certain world time and in the ideal case we would actually > display the frame at this world time.

[PATCH] uapi/drm: correct drm_mode_list_lessees::lessees_ptr docs

From: Emil Velikov Since day 1, lesser_ids have been u32. Every instance in the UAPI (minus the one corrected) and the implementation agree on the topic. Fixes: 62884cd386b8 ("drm: Add four ioctls for managing drm mode objectleases [v7]") Cc: Keith Packard

[Bug 199357] amdgpu: hang a few seconds after logging in, most likely due to regression

https://bugzilla.kernel.org/show_bug.cgi?id=199357 --- Comment #1 from Mathias Tillman (master.ho...@gmail.com) --- Created attachment 275293 --> https://bugzilla.kernel.org/attachment.cgi?id=275293=edit Hardware info -- You are receiving this mail because: You are watching the assignee of

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On Wed, 11 Apr 2018, Ian W MORRISON wrote: > > >> >> NAK on indiscriminate Cc: stable. There are zero guarantees that older >> kernels will work with whatever firmware you throw at them. >> > > I included 'Cc: stable' so the patch would get added to the v4.16 and > v4.15

[Bug 199357] New: amdgpu: hang a few seconds after logging in, most likely due to regression

https://bugzilla.kernel.org/show_bug.cgi?id=199357 Bug ID: 199357 Summary: amdgpu: hang a few seconds after logging in, most likely due to regression Product: Drivers Version: 2.5 Kernel Version: v4.16 Hardware: x86-64

[PATCH 1/5] dma-buf: use parameter structure for dma_buf_attach

Move the parameters into a structure to make it simpler to extend it in follow up patches. This also adds the importer private as parameter so that we can directly work with a completely filled in attachment structure. Signed-off-by: Christian König ---

[PATCH 4/5] drm/amdgpu: add independent DMA-buf export v2

Instead of relying on the DRM functions just implement our own export functions. This adds support for taking care of unpinned DMA-buf. v2: fix unintended recursion, remove debugging leftovers Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h

[PATCH 3/5] drm/ttm: remove the backing store if no placement is given

Pipeline removal of the BOs backing store when the placement is given during validation. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

[PATCH 5/5] drm/amdgpu: add independent DMA-buf import v3

Instead of relying on the DRM functions just implement our own import functions. This adds support for taking care of unpinned DMA-buf. v2: enable for all exporters, not just amdgpu, fix invalidation handling, lock reservation object while setting callback v3: change to new dma_buf attach

[PATCH 2/2] gpu: drm: ast: Replace mdelay with msleep in ast_post_chip_2500

ast_post_chip_2500() is never called in atomic context. The call chains ending up at reset_mmc_2500() are: [1] ast_post_chip_2500() <- ast_post_gpu() <- ast_drm_thaw() [2] ast_post_chip_2500() <- ast_post_gpu() <- ast_driver_load() ast_drm_thaw() calls console_lock() which can sleep.

Re: Lenovo ThinkVision X1 27" USB-C occasionally hangs the kernel (usbhid) and isn't setting a proper resolution when USB 3.0 (FHD) switched to USB 2.0 (UHD)

On Wed, Apr 11, 2018 at 02:09:29PM +0300, Heikki Krogerus wrote: > On Wed, Apr 11, 2018 at 08:28:44AM +, andrey.ara...@nixaid.com wrote: > > Thank you for the insights, Heikki! > > > > Please find the acpi.dump.tgz file is a attached. > > > > I do not have the USBC* and INT3515* devices, >

[PATCH 1/2] gpu: drm: ast: Replace mdelay with msleep in reset_mmc_2500

reset_mmc_2500() is never called in atomic context. The call chains ending up at reset_mmc_2500() are: [1] reset_mmc_2500() <- ast_dram_init_2500() <- ast_post_chip_2500() <- ast_post_gpu() <- ast_drm_thaw() [2] reset_mmc_2500() <- ast_dram_init_2500() <- ast_post_chip_2500() <-

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

> > NAK on indiscriminate Cc: stable. There are zero guarantees that older > kernels will work with whatever firmware you throw at them. > I included 'Cc: stable' so the patch would get added to the v4.16 and v4.15 kernels which I have tested with the patch. I found that earlier kernels didn't

[PATCH] gpu: drm: bridge: adv7511: Replace mdelay with usleep_range in adv7511_probe

adv7511_probe() is never called in atomic context. This function is only set as ".probe" in struct i2c_driver. Despite never getting called from atomic context, adv7511_probe() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() to avoid busy waiting.

[PATCH] panel-jdi-lt070me05000: Replace mdelay with usleep_range and msleep in jdi_panel_init

jdi_panel_init() is never called in atomic context. Despite never getting called from atomic context, jdi_panel_init() calls mdelay() to busily wait. This is not necessary and can be replaced with usleep_range() and msleep() to avoid busy waiting. This is found by a static analysis tool named

[PULL] drm-misc-next-fixes

Hi Dave, I misspoke yesterday when I said we were up-to-date. I have this patch from Tomi to fix a regression in omap. drm-misc-next-fixes-2018-04-11: omap: Fix crash on AM4 EVM, and all OMAP2/3 boards (Tomi) Cc: Tomi Valkeinen Cheers, Sean The following changes

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

On 10/04/18 21:59, Sinan Kaya wrote: Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't hold true universally especially for systems with IOMMU. So why not fix said code? It's clearly not a real

[PATCH 2/5] dma-buf: add optional invalidate_mappings callback v3

Each importer can now provide an invalidate_mappings callback. This allows the exporter to provide the mappings without the need to pin the backing store. v2: don't try to invalidate mappings when the callback is NULL, lock the reservation obj while using the attachments, add helper to

Re: [PATCH v4 0/8] drm/sun4i: Allwinner MIPI-DSI support

On Wed, Apr 04, 2018 at 11:57:08AM +0200, Maxime Ripard wrote: > Hi, > > Here is an preliminary version of the MIPI-DSI support for the Allwinner > SoCs. > > This controller can be found on a number of recent SoCs, such as the > A31, A33 or the A64. > > Given the sparse documentation, there's a

[Bug 199357] amdgpu: hang a few seconds after logging in, most likely due to regression

https://bugzilla.kernel.org/show_bug.cgi?id=199357 Christian König (christian.koe...@amd.com) changed: What|Removed |Added CC|

[Bug 198907] Backlight control missing with /sys/class/backlight/ empty

https://bugzilla.kernel.org/show_bug.cgi?id=198907 --- Comment #5 from Jani Nikula (jani.nik...@intel.com) --- [6.112689] nvidia: loading out-of-tree module taints kernel. [6.112708] nvidia: module license 'NVIDIA' taints kernel. -- You are receiving this mail because: You are watching

[PATCH hwc v2 00/18] Add scene flattening support

Flattening a scene in order to reduce memory consumption it's an idea which had been floating around on irc and mailing list several times, this patchset adds support for flattening a scene using a writeback connector, the latest version of the kernel patches could be found here [1]. v1 for this

[PATCH] drm/panel: simple: AUO P320HVN03 uses SPWG data ordering

The patch adding support for the AUO P320HVN03 panel was written against a preliminary datasheet, which specified JEIDA data ordering. Testing with real hardware has shown that the actually used data ordering is SPWG. Fixes: 70c0d5b783f5 (drm/panel: simple: add support for AUO P320HVN03)

[PATCH 2/2] drm/imx: imx-ldb: check if channel is enabled before printing warning

If the second LVDS channel has been disabled in the DT when using dual-channel mode we should not print a warning. Signed-off-by: Lucas Stach --- drivers/gpu/drm/imx/imx-ldb.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Re: [PATCHv2] drm/amdkfd: Remove vla

On 2018-04-10 09:02 PM, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. Switch to a constant value that covers all hardware. > > [1] https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by: Laura Abbott > --- > v2:

[PATCH 1/2] drm/imx: imx-ldb: disable LDB on driver bind

The LVDS signal integrity is only guaranteed when the correct enable sequence (first IPU DI, then LDB) is used. If the LDB display output was active before the imx-drm driver is loaded (like when a bootsplash was active) the DI will be disabled by the full IPU reset we do when loading the driver.

[PATCH hwc v2 15/18] drm_hwcomposer: Add worker to trigger scene flattenning

Add a vsync worker that calls back into the DrmDisplayCompositor, for now at every 60 vsyncs if the scene does not change we trigger the flattening of the scene using the writeback connector. Other, more complex and proper heuristics could be implemented later on. Signed-off-by: Alexandru

[PATCH hwc v2 17/18] drm_hwcomposer: Flatten scene synchronously

Flatten scene on the same CRTC as the one driving the display. The active composition is played back to the display with a buffer attached to the writeback connector. Then we build a composition that has only one plane enabled and that uses the result of the writeback as the input. Signed-off-by:

[PATCH hwc v2 16/18] drm_hwcomposer: Find writeback connector for scene flattening

Add logic for finding a suitable writeback connector, there are two possibilities for finding an usable writeback connector: 1) Attached to the same CRTC as the display and can function concurrently with the display connector. 2) On a different CRTC and the display connector is not used

[PATCH hwc v2 18/18] drm_hwcomposer: Flatten scene asynchronously

The steps for flattening a scene on a dedicated crtc are: 1. Find an available and unused crtc(the display connector is disconnected). 2. Copy layers from active composition. 3. Plan layers of copy on the unused crtc. This is realized by using a newly created DrmDisplayCompositor object. 4.

[PATCH hwc v2 14/18] drm_hwcomposer: Fix race in ApplyFrame

ApplyFrame holds the lock just when it swaps the value of active_composition_, in a multithread context we could end up in a situation where something is shown on the screen, but something else is set in active_composition_. Fix it by holding the lock during CommitFrame. Signed-off-by: Alexandru

[PATCH hwc v2 12/18] drm_hwcomposer: Add utility function to create an initialized composition

There is a lot of boilerplate for creating an initialized drmdisplaycomposition. This patch gathers that in a separate method. Signed-off-by: Alexandru Gheorghe --- drmdisplaycompositor.cpp | 23 +++ drmdisplaycompositor.h | 2 ++ 2

[DPU PATCH v3 0/2] Remove DPU RSC support

MSM display controller hardware (DPU) has an inbuilt RSC (Resource Coordinator) HW block which can control power resources and bus bandwidth voting based on frame timing parameters without DPU driver intervention. Downstream driver relies on RSC driver for controlling these resources (via RSC HW

[DPU PATCH v3 1/2] dt-bindings: msm/disp: Remove DPU RSC device bindings

MSM Display controller includes RSC (Resource Coordinator) HW block which can control DPU power resources without DPU driver intervention. Removing DPU RSC device/driver support till the RSC dependencies make their way upstream. Signed-off-by: Rajesh Yadav ---

[RFC 0/1] DRM Node Probing functionality

This patch implements a simple function for matching DRM device FDs against the desired properties of a device that you are looking for. The properties that are possible to look for are the elements of DrmVersion and DrmDevice. The discussion that led to this series can be found here:

Re: [PATCH v6 0/5] drm/blend: Support generic plane-wide alpha

Maxime Ripard writes: > Hi, > > This serie aims at enhancing the support for plane-wide alpha in the > drivers that are implementing it at the moment, by turning it into a > generic property and converting the drivers (rcar-du and atmel-hclcdc). It > also introduces

[PATCH hwc v2 09/18] drm_hwcomposer: Handle writeback connectors

When writeback connectors are available assign them to displays, in order to be able to use them for flattening of the current displayed scene. The pipeline for each display will look like this: CRTC encoder display connector. |--- writeback enc -- writeback connector.

[PATCH hwc v2 06/18] drm_hwcomposer: Add writeback connector support

Writeback connector is a special case of connector, which can be linked to a CRTC in order to get the result of the composition back to a memory buffer. This had not been merged to the mainline kernel yet, latest version of the kernel patches could be found here [1]. [1]

[PATCH hwc v2 10/18] drm_hwcomposer: hwcutils: Add function for cloning a DrmHwcLayer

When doing flattening of a composition on a different CRTC we need to be able to clone a layer in order to import it and then pass it to another CRTC. Signed-off-by: Alexandru Gheorghe --- drmhwcomposer.h | 1 + hwcutils.cpp| 11 +++ 2 files

[PATCH hwc v2 03/18] drm_hwcomposer: drmeventlistener: Set nl_pid to 0

By setting nl_pid to 0, we let the kernel to assign a port for us. In the current implementation there is no way we could create more than one instance for drmeventlistener. Signed-off-by: Alexandru Gheorghe --- drmeventlistener.cpp | 2 +- 1 file changed, 1

[PATCH hwc v2 04/18] drm_hwcomposer: Add resource manager class

Add a resource manager object that is responsible for detecting all kms devices and allocates unique display numbers for every detected display. This is controlled by the value of hwc.drm.device property, if it ends with a %, it will try to open minor devices until and error is detected. E.g:

[PATCH hwc v2 05/18] drm_hwcomposer: Enable resource manager support

Use the newly added ResourceManager for creating and detecting all the drm devices instead of assuming that there is only one device. Signed-off-by: Alexandru Gheorghe --- drmhwctwo.cpp| 34 +- drmhwctwo.h | 4 +---

[PATCH hwc v2 08/18] drm_hwcomposer: Parse and store possible_clones information

drmModeEncoder has a field called possible_clones. It's a bit mask which tells if the encoder could be simultaneously connected, to the same CRTC, with the encoders specified in the possible_clones mask. Signed-off-by: Alexandru Gheorghe --- drmencoder.cpp |

[PATCH hwc v2 07/18] drm_hwcomposer: Add display field to Drmencoder

In the current implementation TryEncoderForDisplay just looks at the crtc linked to the display, if that's not assigned to a display it means the encoder could be used, otherwise iterate to the list of possible_crtcs and find one which is not used. This logic works fine when you have just one

[PATCH hwc v2 13/18] drm_hwcomposer: Pass buffer sizes to Prepareframebuffer

Currently Prepareframebuffer uses the mode of the connected connector to decide how big the buffer should be, however when using the drmdisplaycompositor just for flattening, the mode had not been set yet, so we need a way to pass the desired buffer sizes. Signed-off-by: Alexandru Gheorghe

[PATCH hwc v2 02/18] drm_hwcomposer: vsyncworker: Fix deadlock on exit path

vsyncworker::Routine assumes that when -EINTR is returned by WaitForSignalOrExitLocked the lock as been released, which is not true, so it hangs if a vsyncworker is never enabled and Exit is called. There are two code paths in WaitForSignalOrExitLocked that return -EINTR, one releases the lock

[PATCH hwc v2 01/18] drm_hwcomposer: vsyncworker: Fix uninitialized enabled_ field

Signed-off-by: Alexandru Gheorghe --- vsyncworker.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/vsyncworker.cpp b/vsyncworker.cpp index 3ad16fe..3bfe4be 100644 --- a/vsyncworker.cpp +++ b/vsyncworker.cpp @@ -35,6 +35,7 @@ VSyncWorker::VSyncWorker()

[PATCH hwc v2 11/18] drm_hwcomposer: Add utility functions to copy displaycomposition internals

Add utility functions to copy the DrmHwcLayer and DrmCompositionPlanes from another DrmDisplayComposition. Signed-off-by: Alexandru Gheorghe --- drmdisplaycomposition.cpp | 29 + drmdisplaycomposition.h | 3 +++ 2 files changed,

Re: RFC for a render API to support adaptive sync and VRR

On 2018-04-10 06:26 PM, Cyr, Aric wrote:> > My guess is they prefer to “do nothing” and let driver/HW manage it, > otherwise you exempt all existing games from supporting adaptive sync > without a rewrite or update. Nobody is saying adaptive sync should only work with explicit target presentation

[Bug 104216] Firefox quirks (black and/or white squares)

https://bugs.freedesktop.org/show_bug.cgi?id=104216 --- Comment #24 from Germano Massullo --- Just got a burst of very interesting comments in Firefox bugreport from https://bugzilla.mozilla.org/show_bug.cgi?id=1421353#c19 to comment number 21 -- You are receiving

Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

On 11/04/18 15:33, Sinan Kaya wrote: On 4/11/2018 8:03 AM, Robin Murphy wrote: On 10/04/18 21:59, Sinan Kaya wrote: Code is expecing to observe the same number of buffers returned from dma_map_sg() function compared to sg_alloc_table_from_pages(). This doesn't hold true universally especially

[Bug 199085] Multiple [drm] Got external EDID base block and 0 extensions messages

https://bugzilla.kernel.org/show_bug.cgi?id=199085 --- Comment #6 from Jani Nikula (jani.nik...@intel.com) --- The firmware EDID handling was moved at a lower level in the stack to be a more transparent replacement for the display EDID. Without this, many features were erroneously parsed from the

[Bug 103246] PoE: GPU hang with mesa >= 17.2.0 + gallium-nine

https://bugs.freedesktop.org/show_bug.cgi?id=103246 --- Comment #2 from i...@yahoo.com --- I just sow that there is already issue opened for the same/similar issue: https://github.com/iXit/Mesa-3D/issues/296 -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 1/2] drm/prime: Iterate SG DMA addresses separately

Am 11.04.2018 um 19:11 schrieb Robin Murphy: For dma_map_sg(), DMA API implementations are free to merge consecutive segments into a single DMA mapping if conditions are suitable, thus the resulting DMA addresses may be packed into fewer entries than ttm->sg->nents implies.

[PATCH 2/2] iommu/arm-smmu: Add list of devices to opt out of DMA domains

Add a list of compatible strings for devices that wish to opt out of attaching to a DMA domain. This is for devices that prefer to manage their own IOMMU space for any number of reasons. Returning ENOTSUPP for attach device will filter down and force arch_setup_dma_ops() to not set up the iommu

[VERY RFC 0/2] iommu: optionally skip attaching to a DMA domain

I've been struggling with a problem for a while and I haven't been able to come up with a clean solution. Rob convinced me to stop complaining and do _something_ and hopefully this can spur a good discussion. The scenario is basically this: The MSM GPU wants to manage its own IOMMU virtual

[PATCH 1/2] iommu: Gracefully allow drivers to not attach to a default domain

Provide individual device drivers the chance to gracefully refuse to attach a device to the default domain. If the attach_device op returns -ENOTSUPP don't print a error message and don't set group->domain but still return success from iommu_group_add_dev(). This allows all the usual APIs to work

Re: [PATCH 2/2] drm/amdgpu: Allow dma_map_sg() coalescing

Am 11.04.2018 um 19:11 schrieb Robin Murphy: Now that drm_prime_sg_to_page_addr_arrays() understands the case where dma_map_sg() has coalesced segments and returns 0 < count < nents, we can relax the check to only consider genuine failure. That pattern is repeated in pretty much all drivers

[Bug 199357] amdgpu: hang a few seconds after logging in, most likely due to regression

https://bugzilla.kernel.org/show_bug.cgi?id=199357 --- Comment #4 from Christian König (christian.koe...@amd.com) --- Thanks, yeah that is clearly DC (display core). Harry can you take a look? -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 199357] amdgpu: hang a few seconds after logging in, most likely due to regression

https://bugzilla.kernel.org/show_bug.cgi?id=199357 --- Comment #3 from Mathias Tillman (master.ho...@gmail.com) --- I've just finished running a bisect now, and I have concluded that commit 36cc549d59864b7161f0e23d710c1c4d1b9cf022 (drm/amd/display: disable CRTCs with NULL FB on their primary

[Bug 103246] PoE: GPU hang with mesa >= 17.2.0 + gallium-nine

https://bugs.freedesktop.org/show_bug.cgi?id=103246 i...@yahoo.com changed: What|Removed |Added Keywords||regression --- Comment #1 from

[Bug 105680] [CI] igt@kms_frontbuffer_tracking@* - fail - FBC disabled: mode too large for compression

https://bugs.freedesktop.org/show_bug.cgi?id=105680 --- Comment #8 from Jose Roberto de Souza --- Hi Marta did it ran? Should I ask someone else to review and merge? -- You are receiving this mail because: You are the assignee for the

Re: [1/2] drm/prime: Iterate SG DMA addresses separately

On 11/04/18 18:11, Robin Murphy wrote: For dma_map_sg(), DMA API implementations are free to merge consecutive segments into a single DMA mapping if conditions are suitable, thus the resulting DMA addresses may be packed into fewer entries than ttm->sg->nents implies.

[PATCH 1/2] drm/prime: Iterate SG DMA addresses separately

For dma_map_sg(), DMA API implementations are free to merge consecutive segments into a single DMA mapping if conditions are suitable, thus the resulting DMA addresses may be packed into fewer entries than ttm->sg->nents implies. drm_prime_sg_to_page_addr_arrays() does not account for this,

  1   2   >