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

Hi Souptick, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.17-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH v4 2/2] dt-bindings: Add Truly NT35597 panel bindings

Add the device tree bindings for Truly NT35597 panel. This panel supports both single DSI and dual DSI. However, this patch series supports only dual DSI. Changes in v4: - None Signed-off-by: Abhinav Kumar --- .../devicetree/bindings/display/truly,nt35597.txt | 69

[PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel

Add support for Truly NT35597 panel used in MSM reference platforms. This panel supports both single DSI and dual DSI modes. However, this patch series adds support only for dual DSI mode. Changes in v4: - Fix the license identifier - Fix formatting issues for the regulator loads - Fix error

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #29 from Francisco Pina Martins --- Created attachment 139779 --> https://bugs.freedesktop.org/attachment.cgi?id=139779=edit journaltcl log file for linux-amd-staging-drm-next I was able to compile the

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #28 from Francisco Pina Martins --- Currently "amd-staging-drm-next" fails to build for me, with the following error: ``` ../lib/str_error_r.c: In function ‘str_error_r’: ../lib/str_error_r.c:25:3: error:

Re: [PATCH v3 1/2] drm/panel: Add support for Truly NT35597 panel

Hi Jordan Thanks for the review. Will fix the ones listed below and upload V4. Abhinav On 2018-05-24 10:31, Jordan Crouse wrote: On Wed, May 23, 2018 at 06:44:00PM -0700, Abhinav Kumar wrote: Add support for Truly NT35597 panel used in MSM reference platforms. This panel supports both

[DPU PATCH v3 4/6] drm/msm: strip down custom event ioctl's

Remove custom ioctl support in SDM845 which allows user space to register/unregister for hw events. changes in v2: - none changes in v3: - none Reviewed-by: Sean Paul Signed-off-by: Jeykumar Sankaran Signed-off-by: Sean Paul

[DPU PATCH v3 1/6] drm/msm: remove display stream compression(DSC) support for SM845

Upstream DSI driver doesn't support DSC panels yet. Remove the support for compression from DPU for now. changes in v2: - indents and unrelated change clean up (Sean Paul) - fix compilation dependency in dsi-staging changes in v3: - none Signed-off-by: Jeykumar Sankaran

[DPU PATCH v3 2/6] drm/msm: remove support for ping pong split topology

ping pong split topology was meant for low end soc's which doesn't have enough layer mixers to support split panels. Considering how uncommon the topology is for current chipset's and also to simply the driver programming, striping off the support for SDM845. changes in v2: - none changes

[DPU PATCH v3 0/6] Switch DPU to use upstream DSI driver for SDM845

SDM845 DPU driver was talking to dsi-staging driver for its dsi operations through the customized dpu_connector layer. The following series of patches removes DPU dependency from various dpu connector API's before purging the dpu_connector altogether. It also completes the switch to upstream DSI

[DPU PATCH v3 3/6] drm/msm: remove panel autorefresh support for SDM845

Remove autorefresh support for smart panels in SDM845 for now. It needs more discussion to figure out the user space communication to set preference for the feature. changes in v2: - none changes in v3: - none Reviewed-by: Sean Paul Signed-off-by: Jeykumar

[DPU PATCH v3 5/6] drm/msm: hook up DPU with upstream DSI

Switch DPU from dsi-staging to upstream dsi driver. To make the switch atomic, this change includes: - remove dpu connector layers - clean up dpu connector dependencies in encoder/crtc - compile out writeback and display port drivers - compile out dsi-staging driver (separate patch submitted to

[Bug 106471] Radeon HD 3450 acceleration not working

https://bugs.freedesktop.org/show_bug.cgi?id=106471 Joshua Cogliati changed: What|Removed |Added CC|

Re: [PATCH v2 0/6] drm/omap: Module parameter for display order configuration

Hi Peter, On Wednesday, 21 March 2018 12:08:25 EEST Peter Ujfalusi wrote: > Hi, > > Changes since v1: > - rebased it on drm-next > - Dropped the devm_kzalloc conversion patch > > Changes since RFC: > - Comments from Laurent have been addressed: > - Get alias ID once and store it for later use

Re: [PATCH v2 3/4] dt-bindings: new binding for Ilitek ILI9341 display panels

On 05/25/2018 02:36 PM, David Lechner wrote: This adds a new binding for Ilitek ILI9341 display panels. It includes a compatible string for one display (more can be added in the future). The vendor prefix "noname" is used because the vendor is not known. Looks like I forgot to update "noname"

Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays

"dirver"? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/7] drm/omap: Module parameter for display order configuration

Hi Peter, On Monday, 4 September 2017 13:03:36 EEST Peter Ujfalusi wrote: I should drop dates when I reply to such old e-mails... > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > On 2017-09-01 14:36, Laurent

[Bug 106658] 2500u HP Envy x360 Hangs randomly

https://bugs.freedesktop.org/show_bug.cgi?id=106658 --- Comment #4 from Justin Mitzel --- Created attachment 139776 --> https://bugs.freedesktop.org/attachment.cgi?id=139776=edit dmesg -- You are receiving this mail because: You are the assignee for the

[Bug 106658] 2500u HP Envy x360 Hangs randomly

https://bugs.freedesktop.org/show_bug.cgi?id=106658 --- Comment #3 from Justin Mitzel --- Created attachment 139775 --> https://bugs.freedesktop.org/attachment.cgi?id=139775=edit Current Xorg log for some reason xorg.log.1 is empty, I will have to post it some other

[Bug 106658] 2500u HP Envy x360 Hangs randomly

https://bugs.freedesktop.org/show_bug.cgi?id=106658 --- Comment #2 from Justin Mitzel --- Created attachment 139774 --> https://bugs.freedesktop.org/attachment.cgi?id=139774=edit Journalctl -k -b 2 output -- You are receiving this mail because: You are the assignee

[Bug 106658] 2500u HP Envy x360 Hangs randomly

https://bugs.freedesktop.org/show_bug.cgi?id=106658 --- Comment #1 from Justin Mitzel --- Created attachment 139773 --> https://bugs.freedesktop.org/attachment.cgi?id=139773=edit Journalctl -k output I've disabled the PCI errors in the past, it does not stop the

[Bug 106658] 2500u HP Envy x360 Hangs randomly

https://bugs.freedesktop.org/show_bug.cgi?id=106658 Bug ID: 106658 Summary: 2500u HP Envy x360 Hangs randomly Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity:

[PATCH v2 2/4] dt-bindings: Add vendor prefix for Adafruit

This adds a device tree vendor prefix for Adafruit Industries, LLC. Signed-off-by: David Lechner --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt

[PATCH v2 3/4] dt-bindings: new binding for Ilitek ILI9341 display panels

This adds a new binding for Ilitek ILI9341 display panels. It includes a compatible string for one display (more can be added in the future). The vendor prefix "noname" is used because the vendor is not known. The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout board[2] and in

[PATCH v2 4/4] drm/tinydrm: new driver for ILI9341 display panels

This adds a new driver for display panels that use the Ilitek ILI9341 controller. It currently supports a single display panel, namely the YX240QV29-T (e.g. Adafruit 2.4" TFT). The init sequence is from the Adafruit Python library for the ILI9341 controller.

[PATCH v2 1/4] MAINTAINERS: fix path to ilitek, ili9225 device tree bindings

This fixes the path to the ilitek,ili9225 device tree binding file. Signed-off-by: David Lechner Reviewed-by: Noralf Trønnes --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index

[PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays

This series adds a new tinydrm driver for the Ilitek ILI9341 controller and a 2.4" display panel that uses this controller. A few things to note here: * The datasheet for this display[1] doesn't have a vendor mentioned on it anywhere, so I have used "adafruit" as the vendor prefix. If someone

[Bug 106258] AMD Xorg start failes with non-4K page sizes

https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #19 from Alex Deucher --- (In reply to Timothy Pearson from comment #17) > We have been unable to replicate this with the latest AMD GPU firmware from >

[Bug 106258] AMD Xorg start failes with non-4K page sizes

https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #18 from Timothy Pearson --- (In reply to Timothy Pearson from comment #17) > We have been unable to replicate this with the latest AMD GPU firmware from >

[PATCH v2 13/13] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

From: Ville Syrjälä Stop playing around with plane->crtc/fb/old_fb with atomic drivers. Make life a lot simpler when we don't have to do the magic old_fb vs. fb dance around plane updates. That way we can't risk plane->fb getting out of sync with plane->state->fb

[PATCH v2 12/13] drm/vc4: Stop updating plane->fb/crtc

From: Ville Syrjälä We want to get rid of plane->fb/crtc on atomic drivers. Stop setting them. Cc: Eric Anholt Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst

[PATCH v2 11/13] drm/virtio: Stop updating plane->crtc

From: Ville Syrjälä We want to get rid of plane->crtc on atomic drivers. Stop setting it. v2: s/fb/crtc/ in the commit message (Gerd) Cc: David Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org

[PATCH v2 10/13] drm/msm: Stop updating plane->fb/crtc

From: Ville Syrjälä We want to get rid of plane->fb/crtc on atomic drivers. Stop setting them. v2: Catch a few more cases Cc: Rob Clark Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Ville Syrjälä

[PATCH v2 06/13] drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc

From: Ville Syrjälä plane->fb/old_fb/crtc should no longer be used by atomic drivers. Stop messing about with them. Cc: Deepak Rawat Cc: Thomas Hellstrom Cc: Sinclair Yeh Cc: VMware Graphics

[PATCH v2 08/13] drm/i915: Stop updating plane->fb/crtc

From: Ville Syrjälä We want to get rid of plane->fb/crtc on atomic drivers. Stop setting them. v2: Fix up the comment in intel_crtc_active() and nuke the rest of the stale comments (Daniel) Signed-off-by: Ville Syrjälä

[PATCH v2 07/13] drm/amdgpu/dc: Stop updating plane->fb

From: Ville Syrjälä We want to get rid of plane->fb on atomic drivers. Stop setting it. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: Harry Wentland

[PATCH v2 09/13] drm/exynos: Stop updating plane->crtc

From: Ville Syrjälä We want to get rid of plane->crtc on atomic drivers. Stop setting it. Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park

[PATCH v2 04/13] drm/vmwgfx: Stop updating plane->fb

From: Ville Syrjälä We want to get rid of plane->fb on atomic drivers. Stop setting it. Cc: Deepak Rawat Cc: Thomas Hellstrom Cc: Sinclair Yeh Cc: VMware Graphics

[PATCH v2 03/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()

From: Ville Syrjälä The only caller of vmw_kms_update_implicit_fb() is the page_flip hook which itself gets called with the plane mutex already held. Hence we can look at plane->state safely. Toss in a lockdep assert to make the situation more clear. Cc: Deepak

[PATCH v2 05/13] drm/vmwgfx: Stop using plane->fb in atomic_enable()

From: Ville Syrjälä Instead of looking at the (soon to be deprecated) plane->fb we'll examing plane->state->fb instead. We can do this because vmw_du_crtc_atomic_check() prevents us from enabling a crtc without the primary plane also being enabled. Due to that

[PATCH v2 02/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

From: Ville Syrjälä Instead of plane->fb (which we're going to deprecate for atomic drivers) we need to look at plane->state->fb. The maze of code leading to vmw_kms_helper_dirty() wasn't particularly clear, but my analysis concluded that the calls originating from

[PATCH v2 01/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

From: Ville Syrjälä Instead of looking at plane->fb let's look at the proper new plane state. Not that the code makes a ton of sense. It's only going through the crtcs in the atomic state, so assuming not all of them are included we're not even calculating the

[PATCH v2 00/13] drm: Eliminate plane->fb/crtc usage for atomic drivers

From: Ville Syrjälä Here are again the last (?) bits of eliminating the plane->fb/crtc usage for atomic drivers. I've pushed everything else (thanks to everyone who reviewed them). Deepak said he'd tested the vmwgfx stuff, so I think it should be safe to land.

[Bug 106258] AMD Xorg start failes with non-4K page sizes

https://bugs.freedesktop.org/show_bug.cgi?id=106258 Timothy Pearson changed: What|Removed |Added Status|NEW

Re: [PATCH 4/8] drm/rcar-du: fix merge conflict for state->alpha

Hi Arnd, Thank you for the patch. On Friday, 25 May 2018 18:50:11 EEST Arnd Bergmann wrote: > The "alpha" struct member was removed in one commit but another user > added in another, leading to a build failure: > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function >

Re: [PATCH 3/3] drm/msm: re-factor devfreq code

On Fri, May 25, 2018 at 04:00:46PM +0530, Sharat Masetty wrote: > devfreq framework requires the drivers to provide busy time estimations. > The GPU driver relies on the hardware performance counters for the busy time > estimations, but different hardware revisions have counters which can be >

RE: [Intel-gfx] DRM Inquiry

On Fri, 25 May 2018, "Taylor, Clinton A" wrote: > Looks like the seek=%d in the sprintf is not working. Yeah. Try skip=%d instead. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list

Re: [PATCH 2/3] drm/msm: move suspend/resume devfreq to their own functions

On Fri, May 25, 2018 at 04:00:45PM +0530, Sharat Masetty wrote: > This is needed for hardware revisions which do not rely on the generic > suspend, resume handlers for power management. > > Signed-off-by: Sharat Masetty > --- > drivers/gpu/drm/msm/msm_gpu.c | 26

Re: [PATCH 1/3] drm/msm: suspend devfreq on init

On Fri, May 25, 2018 at 04:00:44PM +0530, Sharat Masetty wrote: > Devfreq turns on and starts recommending power level as soon as it is > initialized. The GPU is still not powered on by the time the devfreq > init happens and this leads to problems on GPU's where register access > is needed to

[Bug 106430] GPU hang when played video with acceleration (vaapi)

https://bugs.freedesktop.org/show_bug.cgi?id=106430 --- Comment #5 from mikhail.v.gavri...@gmail.com --- After updating kernel to 4.17.0-0.rc6.git1.1 strange mce error messages after reboot disappeared. But GPU still hangs. -- You are receiving this mail because: You are the assignee for the

[Bug 106430] GPU hang when played video with acceleration (vaapi)

https://bugs.freedesktop.org/show_bug.cgi?id=106430 --- Comment #4 from mikhail.v.gavri...@gmail.com --- Created attachment 139764 --> https://bugs.freedesktop.org/attachment.cgi?id=139764=edit dmesg -- You are receiving this mail because: You are the assignee for the

[PATCH v2 0/6] omapdrm: struct_mutex removal

Hello, This patch series removes the usage of struct_mutex from the omapdrm driver in order to switch to gem_free_object_unlocked(). The series is inspired by Daniel Vetter's recent gem_free_object_unlocked() patches (starting with "[PATCH 1/5] staging/vboxvideo: Use gem_free_object_unlocked")

[PATCH v2 1/6] drm/omap: gem: Rename GEM function with omap_gem_* prefix

get_pages() as a local function name is too generic and easily confused for a generic MM kernel function. Rename it to __omap_gem_get_pages(). Rename the is_contiguous(), is_cache_coherent(), evict(), evict_entry(), fault_1d() and fault_2d() functions for the same reason. Signed-off-by: Laurent

[PATCH v2 5/6] drm/omap: gem: Fix mm_list locking

From: Daniel Vetter - None of the list walkings where protected. - Switch to a mutex since the list walking at device resume time can sleep when pinning buffers through the tiler. Only thing we need to be careful with here is that while we walk the list we can't

[PATCH v2 2/6] drm/omap: gem: Merge __omap_gem_get_pages() and omap_gem_attach_pages()

The __omap_gem_get_pages() function is a wrapper around omap_gem_attach_pages() that returns the omap_obj->pages pointer through a function argument. Some callers don't need the pages pointer, and all of them can access omap_obj->pages directly. To simplify the code merge the

[PATCH v2 6/6] drm/omap: gem: Switch to gem_free_object_unlocked()

From: Daniel Vetter The only thing that omap_gem_free_object does that might need the magic protection of struct_mutex (of keeping all objects alive if that lock is held, even if the last reference is gone) is the mm_list manipulation. This is already protected by the

[PATCH v2 4/6] drm/omap: gem: Replace struct_mutex usage with omap_obj private lock

The DRM device struct_mutex is used to protect against concurrent GEM object operations that deal with memory allocation and pinning. All those operations are local to a GEM object and don't need to be serialized across different GEM objects. Replace the struct_mutex with a local omap_obj.lock or

[PATCH v2 3/6] drm/omap: gem: Don't take struct_mutex to get GEM object mmap offset

GEM objects mmap offsets are created by calling drm_gem_create_mmap_offset_size() that doesn't need struct_mutex protection as it includes its own locking, based on a size that is static across the object's life time. Remove the unneeded struct_mutex locking. Signed-off-by: Laurent Pinchart

[PATCH] drm/etnaviv: protect sched job submission with fence mutex

The documentation of drm_sched_job_init and drm_sched_entity_push_job has been clarified. Both functions should be called under a shared lock, to avoid jobs getting pushed into the scheduler queue in a different order than their sched_fence seqnos, which will confuse checks that are looking at the

Re: [PATCH v3 7/8] drm/mediatek: Add support for mediatek SOC MT2712

/commits/stu-hsieh-mediatek-com/Add-support-for-mediatek-SOC-MT2712/20180525-24 base: git://people.freedesktop.org/~airlied/linux.git drm-next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

On Fri, May 25, 2018 at 04:48:59PM +0100, Brian Starkey wrote: > Hi Ayan, > > On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: > >If a plane supports a pixel format and the framebuffer does not pass any > >modifiers, then drm_plane_check_pixel_format() should always return true

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #27 from Jerry Zuo --- The issue could get reproduced on 4.16.3, but not on 4.16-rc7. I've verified the commit a0f282dcdb1775cbcc0a151570fc01c0aae5ca0f (current top) on amd-staging-drm-next without seeing the

[PATCH 8/8] drm/bridge: cdns: mark PM functions as __maybe_unused

These two functions are unused in some configurations, and using __maybe_unused is the easiest way to shut up the harmless warnings: drivers/gpu/drm/bridge/cdns-dsi.c:1353:12: error: 'cdns_dsi_suspend' defined but not used [-Werror=unused-function] static int cdns_dsi_suspend(struct device

[PATCH 7/8] drm/bridge: fix dependency for lvds-encoder

The DRM panel bridge code is built into the kms helpers module, so we get a link error when trying to use it from a built-in driver while the kms helper is a loadable module: drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe': lvds-encoder.c:(.text+0x124): undefined reference

[PATCH 6/8] drm/exynos: fix scaler_task_done return type

Modern gcc versions warn about returning a ternary operator with an 'int' type in a function returning type 'bool': drivers/gpu/drm/exynos/exynos_drm_scaler.c: In function 'scaler_task_done': drivers/gpu/drm/exynos/exynos_drm_scaler.c:402:47: error: ?: using integer constants in boolean context

[PATCH 5/8] drm/v3d: add CONFIG_MMU dependency

Without CONFIG_MMU, we get a link error: drivers/gpu/drm/v3d/v3d_bo.o: In function `v3d_gem_fault': v3d_bo.c:(.text+0x3ca): undefined reference to `vm_insert_mixed' The other drivers with this problem already depend on CONFIG_MMU, so let's do the same thing here. Fixes: 57692c94dcbe ("drm/v3d:

[PATCH 3/8] drm/xen-front: fix 32-bit build warning

In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit type: In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18: drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie': drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to

[PATCH 4/8] drm/rcar-du: fix merge conflict for state->alpha

The "alpha" struct member was removed in one commit but another user added in another, leading to a build failure: drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function 'rcar_du_vsp_plane_atomic_duplicate_state': drivers/gpu/drm/rcar-du/rcar_du_vsp.c:325:6: error: 'struct rcar_du_vsp_plane_state'

RE: [Intel-gfx] DRM Inquiry

Looks like the seek=%d in the sprintf is not working. 0x11 0x0A are being returned by the monitor from DPCD’s 0x and 0x0001 repeatedly. The first is DPCD revision (1.1) and the second is maximum Link Rate (0x0a) which is 2.7 Gbps. You might want to do a printf of call to make sure seek is

[PATCH 2/8] drm/amdgpu: fix 32-bit build warning

Casting a pointer to a 64-bit type causes a warning on 32-bit targets: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:473:24: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] lower_32_bits((uint64_t)wptr)); ^

[PATCH 1/8] drm/sun4i: mark PM functions as __maybe_unused

Disabling CONFIG_PM produces a compile time warning when these functions are not referenced: drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function] static int sun6i_dsi_runtime_suspend(struct device *dev)

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: > If a plane supports a pixel format and the framebuffer does not pass any > modifiers, then drm_plane_check_pixel_format() should always return true > for the given format regardless of whether the plane supports any > modifiers

[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI

https://bugs.freedesktop.org/show_bug.cgi?id=106548 --- Comment #13 from Chris Wilson --- Frequency changes are accompanied by a tracepoint (though note we only say what we ask the hw to do, the hw is at liberty to do whatever it wants), and you can enable the

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

Hi Ayan, On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: If a plane supports a pixel format and the framebuffer does not pass any modifiers, then drm_plane_check_pixel_format() should always return true for the given format regardless of whether the plane supports any

[PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

If a plane supports a pixel format and the framebuffer does not pass any modifiers, then drm_plane_check_pixel_format() should always return true for the given format regardless of whether the plane supports any modifiers or not. Signed-off-by: Ayan Kumar Halder ---

[PATCH 8/8] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

From: Oleksandr Andrushchenko Allow creating grant device context for use by kernel modules which require functionality, provided by gntdev. Export symbols for dma-buf API provided by the module. Signed-off-by: Oleksandr Andrushchenko

[PATCH 4/8] xen/gntdev: Allow mappings for DMA buffers

From: Oleksandr Andrushchenko Allow mappings for DMA backed buffers if grant table module supports such: this extends grant device to not only map buffers made of balloon pages, but also from buffers allocated with dma_alloc_xxx. Signed-off-by: Oleksandr

[PATCH 7/8] xen/gntdev: Implement dma-buf import functionality

From: Oleksandr Andrushchenko 1. Import a dma-buf with the file descriptor provided and export granted references to the pages of that dma-buf into the array of grant references. 2. Add API to close all references to an imported buffer, so it can be

[PATCH 5/8] xen/gntdev: Add initial support for dma-buf UAPI

From: Oleksandr Andrushchenko Add UAPI and IOCTLs for dma-buf grant device driver extension: the extension allows userspace processes and kernel modules to use Xen backed dma-buf implementation. With this extension grant references to the pages of an imported

[PATCH 0/8] xen: dma-buf support for grant device

From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if

[PATCH 6/8] xen/gntdev: Implement dma-buf export functionality

From: Oleksandr Andrushchenko 1. Create a dma-buf from grant references provided by the foreign domain. By default dma-buf is backed by system memory pages, but by providing GNTDEV_DMA_FLAG_XXX flags it can also be created as a DMA

[PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA

From: Oleksandr Andrushchenko Extend grant table module API to allow allocating buffers that can be used for DMA operations and mapping foreign grant references on top of those. The resulting buffer is similar to the one allocated by the balloon driver in terms

[PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

From: Oleksandr Andrushchenko Memory {increase|decrease}_reservation and VA mappings update/reset code used in balloon driver can be made common, so other drivers can also re-use the same functionality without open-coding. Create a dedicated module for the

[PATCH 1/8] xen/grant-table: Make set/clear page private code shared

From: Oleksandr Andrushchenko Make set/clear page private code shared and accessible to other kernel modules which can re-use these instead of open-coding. Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/grant-table.c

Re: [PATCH v9 1/3] drm: Add writeback connector type

On Thu, May 24, 2018 at 05:41:01PM +0100, Liviu Dudau wrote: From: Brian Starkey Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should

[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI

https://bugs.freedesktop.org/show_bug.cgi?id=106548 --- Comment #12 from Francesco Balestrieri --- (In reply to Chris Wilson from comment #11) > An idle gpu is always reported as running at the min(idle) freq. You have to > be very careful in the workload you

Re: [PATCH 3/3] drm/doc: add a chapter for gpu scheduler

On Fri, May 25, 2018 at 12:45 AM, Nayan Deshmukh wrote: > Signed-off-by: Nayan Deshmukh Reviewed-by: Alex Deucher > --- > Documentation/gpu/drm-mm.rst | 18 ++ > 1 file changed, 18 insertions(+)

Re: [PATCH 2/3] drm/scheduler: add documentation

On Fri, May 25, 2018 at 12:45 AM, Nayan Deshmukh wrote: > convert existing raw comments into kernel-doc format as well > as add new documentation > > Signed-off-by: Alex Deucher > Signed-off-by: Nayan Deshmukh

[Bug 106647] MSI R9 390 panic at boot

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

Re: [PATCH] drm/edid: Fix up edid_cea_modes[] formatting

On Fri, May 25, 2018 at 10:21:20AM -0400, Alex Deucher wrote: > On Thu, May 24, 2018 at 3:20 PM, Ville Syrjala > wrote: > > From: Ville Syrjälä > > > > Fix up a bunch of bad indentation and insconsistent comments > > inconsistent

[PATCH] udmabuf: fix odd_ptr_err.cocci warnings

From: kbuild test robot drivers/dma-buf/udmabuf.c:167:6-12: inconsistent IS_ERR and PTR_ERR on line 168. PTR_ERR should access the value just tested by IS_ERR Semantic patch information: There can be false positives in the patch case, where it is the call to IS_ERR

[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault

https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #5 from coolo...@gmail.com --- Is there any additional info we need to get? Anything we can test? My system is currently unusable until this is fixed and it has been 3 months since being reported and haven't heard anything but more

Re: [PATCH] drm/edid: Fix up edid_cea_modes[] formatting

On Thu, May 24, 2018 at 3:20 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > Fix up a bunch of bad indentation and insconsistent comments inconsistent With that fixed: Reviewed-by: Alex Deucher > in

[PATCH v3] Add udmabuf misc device

A driver to let userspace turn memfd regions into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full framebuffer display, and hopefully some

[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI

https://bugs.freedesktop.org/show_bug.cgi?id=106548 --- Comment #11 from Chris Wilson --- An idle gpu is always reported as running at the min(idle) freq. You have to be very careful in the workload you construct that it does indeed keep the gpu busy if you want to use

[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI

https://bugs.freedesktop.org/show_bug.cgi?id=106548 --- Comment #10 from Francesco Balestrieri --- Indeed, after some more investigation I found out that the test case uses (via MDAPI) the root-only interface:

[PATCH 1/2] drm: split out buffer lookup from fake VMA offset

Drivers that want to implement mmap handling different to what drm_gem_mmap provides need a way to look up the GEM BO from the fake VMA offset. Split this out to make it reusable. Signed-off-by: Lucas Stach --- drivers/gpu/drm/drm_gem.c | 56

[PATCH 2/2] drm/etnaviv: properly implement mmaping of imported buffers

The intention of the existing code was to deflect the actual work of mmaping a dma-buf to the exporter, as that one probably knows best how to handle the buffer. Unfortunately the call to drm_gem_mmap did more than what etnaviv needs in this case by actually setting up the mapping. Move mapping

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

On 30/04/18 18:59, Sinan Kaya wrote: On 4/30/2018 9:54 AM, 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 which drm_prime_sg_to_page_addr_arrays()

Re: [PATCH 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function

Den 24.05.2018 11.16, skrev Daniel Vetter: On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote: This is the first step in getting generic fbdev emulation. A drm_fb_helper_funcs.fb_probe function is added which uses the DRM client API to get a framebuffer backed by a dumb buffer. A

  1   2   >