Re: [PATCH 2/2] drm/ttm: add ttm page_flags TTM_PAGE_FLAG_PAGEFAULT

On 2018年01月29日 16:31, Roger He wrote: to indicate whether we are serving for page fault routine when in ttm_mem_global_reserve. for ttm_mem_global_reserve if in page fault routine, allow success always. because page fault routing already grabbed system memory successfully and allow this

Re: [PATCH 1/2] drm/ttm: add swap_glob_mem in ttm_mem_global

On 2018年01月29日 16:31, Roger He wrote: separate swapped memory account from zone->used_mem because swapped ttm pages can be flushed into SWAP disk/file under high memory pressure. add check conditon in ttm_mem_global_reserve to prevent triggering OOM. because if SWAP disk/file is full, all

[Bug 104825] [amdgpu] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed (scratch(0xC040)=0x00000000) when unbinding

https://bugs.freedesktop.org/show_bug.cgi?id=104825 --- Comment #3 from mlen --- I tested amd-staging-drm-next with HEAD at f1367d12f5fabb04789c7772594887434c8d9e8b. This time the unbind succeeded, but there are still some errors logged and kernel reports locking problem in amdgpu:

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Hi Roger, I think this patch isn't need at all. You can directly read total_swap_pages variable in TTM. See the comment: /* protected with swap_lock. reading in vm_swap_full() doesn't need lock */ long total_swap_pages; there are many places using it directly, you just couldn't change its

Re: [PATCH 2/5] drm/vblank: Fix data type width for drm_crtc_arm_vblank_event()

Dhinakaran Pandiyan writes: > Now that drm_vblank_count() returns all bits of the vblank count, update > drm_crtc_arm_vblank_event() so that it queues the correct sequence. > Otherwise, this leads to prolonged waits for a vblank sequence when the > current count is

Re: [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()

Dhinakaran Pandiyan writes: > drm_vblank_count() has a u32 type returning what is a 64-bit vblank > count. It looks like a general review of the 64-bit widening patch is needed. * drm_crtc_accurate_vblank_count has a 32-bit return, and uses a 32-bit temporary

Re: [PATCH 6/7] dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY

On 01/29/2018 10:45 PM, Rob Herring wrote: On Wed, Jan 17, 2018 at 03:04:47PM +0530, Archit Taneja wrote: Add the compatible string for 14nm DSI PHY (used in MSM8996/APQ8096). From 14nm PHY onwards, the "dsi_phy_regulator" reg-name is not required, but "dsi_phy_lane" reg-name is. Update the

Re: [PATCH v3 5/8] drm: Handle aspect ratio info in atomic and legacy modeset paths

On 1/30/2018 12:23 AM, Ville Syrjälä wrote: On Fri, Jan 12, 2018 at 11:51:33AM +0530, Nautiyal, Ankit K wrote: From: Ankit Nautiyal If the user mode does not support aspect-ratio, and requests for a modeset, then the flag bits representing aspect ratio in the

RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

I do think you should completely ignore the size of the swap space. IMHO you should forbid further allocations when your currentbuffer storage cannot be reclaimed. So you need some form of feedback mechanism that would tell you: "Your buffers have grown too much". If you

Re: [PATCH libdrm] drm: fix return value

On 2018年01月17日 17:31, Daniel Vetter wrote: On Wed, Jan 17, 2018 at 05:26:41PM +0800, Chunming Zhou wrote: On 2018年01月17日 17:24, Christian König wrote: Am 17.01.2018 um 09:53 schrieb Chunming Zhou: On 2018年01月17日 16:21, Daniel Vetter wrote: On Tue, Jan 16, 2018 at 02:01:40PM +, Zhou,

[Bug 104762] Various segfaults/problems in qt/plasma

https://bugs.freedesktop.org/show_bug.cgi?id=104762 --- Comment #14 from Dennis Schridde --- Confirming: 041b18cf23a0acf7b0eddf63cd7a2a10192432a1 applied to 18.0.0_rc3, followed by cleaning ~/.cache of root, sddm and my user stops the crashes. -- You are receiving this mail

[PATCH] drm: Print the pid when debug logging an ioctl error.

When we debug print what ioctl we're calling into, we include the pid. If you have multiple processes rendering simulataneously, the error return also needs the pid so you can see which of the ioctl calls was the one to fail. Signed-off-by: Eric Anholt ---

Re: [PATCH 4/4] drm/vgem: flush page during page fault

On Tue, Jan 30, 2018 at 9:01 PM, Gurchetan Singh wrote: > On Tue, Jan 30, 2018 at 1:14 AM, Daniel Vetter wrote: >> >> On Thu, Jan 18, 2018 at 09:23:31AM -0800, Gurchetan Singh wrote: >> > On Wed, Jan 17, 2018 at 11:38 PM, Daniel Vetter

Re: [PATCH] drm/stm: check pitch and size calculations even if !CONFIG_MMU

Hi Benjamin, Working on a coming patch (based on the new has_alpha field in fourcc), I realized that in particular cases (2 layers + "odd" layer sizes) memory transfers on MCU are greatly improved too if drm buffers are aligned on 128 bytes : ) So I suggest to cancel this patch. Then you can

Re: [PATCH 4/4] drm/vgem: flush page during page fault

On Tue, Jan 30, 2018 at 1:14 AM, Daniel Vetter wrote: > > On Thu, Jan 18, 2018 at 09:23:31AM -0800, Gurchetan Singh wrote: > > On Wed, Jan 17, 2018 at 11:38 PM, Daniel Vetter wrote: > > > > > On Wed, Jan 17, 2018 at 11:49 PM, Gurchetan Singh > > >

Re: [PATCH] drm: Check for lessee in DROP_MASTER ioctl

Daniel Vetter writes: > On Thu, Jan 18, 2018 at 05:51:59PM -0800, Keith Packard wrote: >> Don't let a lessee control what the current DRM master is set to; >> that's the job of the "real" master. Otherwise, the lessee would >> disable all access to master operations for the

[RFC v5 5/5] drm/nouveau: Introduce NvPmEnableGating option

This adds the NvPmEnableGating config option to nouveau, which can be used to enable or disable clockgating for supported chipsets. Enabling can be done by passing config=NvPmEnableGating=1 To nouveau. If your chipset supports it, you'll see a message in your kernel log indicating that

[RFC v5 4/5] drm/nouveau: Add support for SLCG for Kepler2

That's right, there's still more power saving to go! Starting with kepler 2, nvidia hardware has an additional level of clockgating known as second level clockgating. The details of this are not exact, but it seems to work by waiting for a collection of dependent hardware blocks to be gated

[RFC v5 3/5] drm/nouveau: Add support for BLCG on Kepler2

Same as the previous patch, but for Kepler2 now Signed-off-by: Lyude Paul Reviewed-by: Martin Peres --- drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--

[RFC v5 2/5] drm/nouveau: Add support for BLCG on Kepler1

This enables BLCG optimization for kepler1. When using clockgating, nvidia's firmware has a set of registers which are initially programmed by the vbios with various engine delays and other mysterious settings that are safe enough to bring up the GPU. However, the values used by the vbios are more

[RFC v5 1/5] drm/nouveau: Add support for basic clockgating on Kepler1

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling

[RFC v5 0/5] Implement full clockgating for Kepler1 and 2

Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ One small change: - Add Martin's R-B, whoops Lyude Paul (5): drm/nouveau: Add support for basic

[Bug 102646] [dc] Screen flickering under amdgpu-experimental [buggy auto power profile]

https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #22 from Justin Mitzel --- Hi, sorry I took so long. I usually check this around once a month. I reuploaded my gameplay on youtube. https://www.youtube.com/watch?v=-uPHG8mz4Xc=youtu.be This happens in

Re: [PATCH] drm: amd: Fix trailing semicolons

On Wed, Jan 17, 2018 at 1:50 PM, Luis de Bethencourt wrote: > The trailing semicolon is an empty statement that does no operation. > Removing the two instances of them since they don't do anything. > > Signed-off-by: Luis de Bethencourt Applied. thanks!

Re: [PATCH] drm: Fix trailing semicolon

On Wed, Jan 17, 2018 at 1:22 PM, Luis de Bethencourt wrote: > The trailing semicolon is an empty statement that does no operation. > Removing it since it doesn't do anything. > > Signed-off-by: Luis de Bethencourt Applied. thanks! Alex > --- > > Hi, > >

[radeon-alex:drm-next-4.17-wip 151/209] drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:414 amdgpu_set_pp_od_clk_voltage() error: uninitialized symbol 'ret'.

tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip head: 5d9e45135f05706b787fe2882442a78f92ae9cd1 commit: c0d382de6b810f9560a22d0d7e5837351265cd7b [151/209] drm/amd/pp: Add edit/commit/show OD clock/voltage support in sysfs smatch warnings:

[Bug 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

https://bugs.freedesktop.org/show_bug.cgi?id=104806 --- Comment #14 from Matt Turner --- (In reply to Michel Dänzer from comment #13) > (In reply to Dennis Schridde from comment #11) > > amdgpu_parse_asic_ids: Cannot parse ASIC IDs: Resource temporarily > > unavailable > >

Re: [PATCH libdrm] meson: fix libdrm_nouveau pkgconfig include directories

ping Quoting Dylan Baker (2018-01-25 16:14:45) > Signed-off-by: Dylan Baker > --- > > I have tested building every mesa driver against this (with and without udev!) > so I'm pretty sure that this is the last pkgbuild problem. > > I'm sure I'll be sad in a day or two...

[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=104520 --- Comment #5 from Michael Weitzel --- Created attachment 137059 --> https://bugs.freedesktop.org/attachment.cgi?id=137059=edit GPU crash dump from /sys/class/drm/card0/error -- You are receiving this mail because:

[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=104520 --- Comment #4 from Michael Weitzel --- I had the same crash (for the first time) - also on KabyLake, ArchLinux, Kernel 4.14.15-1-ARCH. I'll attach my crash dump. [drm] GPU HANG: ecode 9:0:0x85db, in Xorg [636],

Re: [PATCH libdrm 7/7] meson: cleanup whitespace

On January 30, 2018 5:33:39 PM UTC, Dylan Baker wrote: > For the series :) Thanks :) > > But please do get someone from nouveau (Emil CC'd Ben, so presumably > him) before > pushing the nouveau patch. I'm not pushing the nouveau patch until I get an ack, and the amdgpu

Re: [PATCH libdrm 7/7] meson: cleanup whitespace

For the series :) But please do get someone from nouveau (Emil CC'd Ben, so presumably him) before pushing the nouveau patch. Dylan Quoting Eric Engestrom (2018-01-29 02:54:47) > On Friday, 2018-01-26 09:45:14 -0800, Dylan Baker wrote: > > Reviewed-by: Dylan Baker > >

Re: [PATCH] drm/arcpgu: remove drm_encoder_slave

On Tue, Jan 30, 2018 at 5:44 PM, Alexey Brodkin wrote: > Hi Daniel, > > On Tue, 2018-01-30 at 10:15 +0100, Daniel Vetter wrote: >> On Wed, Jan 17, 2018 at 03:17:55PM +0100, Daniel Vetter wrote: >> > drm_encoder_slave is the old way to write bridge drivers, for i2c >>

Re: [AMDGPU][TAHITI XT] new display code

On Tue, Jan 30, 2018 at 10:17:06AM -0500, Harry Wentland wrote: > A good start would be to try re-using the DCE8 code for DCE6. You can > probably create a new dce60_resource.c and dce60_hw_sequencer.c, copying the > register structs, caps, function pointers, constructors and destructors from >

Re: [PATCH v2] drm/edid: use true and false for boolean values

On Tue, Jan 30, 2018 at 11:02:44AM -0500, Sean Paul wrote: > On Tue, Jan 30, 2018 at 05:19:46PM +0200, Ville Syrjälä wrote: > > On Tue, Jan 30, 2018 at 10:09:27AM -0500, Sean Paul wrote: > > > On Tue, Jan 30, 2018 at 04:05:28AM -0600, Gustavo A. R. Silva wrote: > > > > Assign true or false to

[Bug 37474] Segmentation Fault in glCopyTexSubImage2D

https://bugs.freedesktop.org/show_bug.cgi?id=37474 --- Comment #3 from Ben Crocker --- The _mesa_meta_init and _mesa_meta_free calls in the patch DO seem to have made it into the corresponding Init (Create) and Destroy Context code, descended from the r128_context.c code, in

Re: [PATCH v2] drm/edid: use true and false for boolean values

On Tue, Jan 30, 2018 at 05:19:46PM +0200, Ville Syrjälä wrote: > On Tue, Jan 30, 2018 at 10:09:27AM -0500, Sean Paul wrote: > > On Tue, Jan 30, 2018 at 04:05:28AM -0600, Gustavo A. R. Silva wrote: > > > Assign true or false to boolean variables instead of an integer value. > > > > > > This issue

Re: [PATCH v2] drm/i915: Restore HDCP DRM_INFO when with no downstream

On Tue, Jan 30, 2018 at 09:29:34AM -0500, Sean Paul wrote: > The commit below returned earlier than before, but failed to move the > info message when authenticating without downstream devices. This patch > restores the message on authentication success. > > Changes in v2: > - s/no downstream

RE: [PATCH v2 1/1] drm: add kernel doc for exported gem dmabuf_ops

Alex helped push this into drm-tip, https://cgit.freedesktop.org/drm/drm-tip/commit/drivers/gpu/drm?id=f7a71b0cf9e36c1b0edbfe89ce028a01164b864d Thanks, Samuel Li > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Tuesday,

Re: [PATCH] drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS

On Tue, Jan 30, 2018 at 04:12:14PM +0100, Daniel Vetter wrote: > On Tue, Jan 30, 2018 at 09:47:01AM -0500, Sean Paul wrote: > > HDCP was a bit too chatty to get along with the rest of the i915 driver. > > > > Suggested-by: Daniel Vetter > > Signed-off-by: Sean Paul

Re: [RFC] Per file OOM badness

On 2018-01-30 12:56 PM, Christian König wrote: > Am 30.01.2018 um 12:42 schrieb Michel Dänzer: >> On 2018-01-30 12:36 PM, Nicolai Hähnle wrote: >>> On 30.01.2018 12:34, Michel Dänzer wrote: On 2018-01-30 12:28 PM, Christian König wrote: > Am 30.01.2018 um 12:02 schrieb Michel Dänzer:

Re: [PATCH 2/4] drm/pl111: Properly detect the PL110+ variant

On Tue, Jan 30, 2018 at 12:45 AM, Eric Anholt wrote: > Linus Walleij writes: > >> With a bit of refactoring we can contain the variant data for >> the "PL110+" version that is somewhere inbetween PL110 and PL111. >> This is used on the ARM Versatile AB

Re: [PATCH] drm/atomic: Remove WARN_ON for invalid plane configuration.

Op 30-01-18 om 16:21 schreef Harry Wentland: > On 2018-01-30 05:27 AM, Maarten Lankhorst wrote: >> Userspace can set a FB_ID on a plane without setting CRTC_ID, which >> will fail with -EINVAL, but the kernel shouldn't warn about that. >> >> Same for !FB_ID and CRTC_ID being set. >> >>

[Bug 104853] Add support for Intel IOMMU.

https://bugs.freedesktop.org/show_bug.cgi?id=104853 Alex Deucher changed: What|Removed |Added Resolution|--- |NOTOURBUG

[Bug 104853] Add support for Intel IOMMU.

https://bugs.freedesktop.org/show_bug.cgi?id=104853 --- Comment #1 from Alex Deucher --- The driver will work with any IOMMU that supports the necessary standard PCIe ATS/PRI hw features. The intel IOMMU hw does not. -- You are receiving this mail because: You are the

Re: [PATCH v2] drm/edid: use true and false for boolean values

On Tue, 30 Jan 2018, Ville Syrjälä wrote: > On Tue, Jan 30, 2018 at 10:09:27AM -0500, Sean Paul wrote: >> On Tue, Jan 30, 2018 at 04:05:28AM -0600, Gustavo A. R. Silva wrote: >> > Assign true or false to boolean variables instead of an integer value. >> > >> > This

Re: [PATCH v2] drm/stm: drv: Improve data transfers

On Tue, 30 Jan 2018, Laurent Pinchart wrote: > Hi Benjamin, > > On Tuesday, 30 January 2018 12:51:25 EET Benjamin Gaignard wrote: >> 2018-01-30 11:42 GMT+01:00 Philippe Cornu : >> > To optimize data transfers, align pitch on 128 bytes &

[PATCH] drm/stm: check pitch and size calculations even if !CONFIG_MMU

In all cases we have to check pitch and size calculations. Rely on drm_gem_cma_dumb_create for no MMU cases. Fixes: 21f815bf773c ("drm/stm: drv: Improve data transfers") Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/stm/drv.c | 4 +++- 1 file changed, 3

Re: [PATCH] drm/atomic: Remove WARN_ON for invalid plane configuration.

On 2018-01-30 05:27 AM, Maarten Lankhorst wrote: > Userspace can set a FB_ID on a plane without setting CRTC_ID, which > will fail with -EINVAL, but the kernel shouldn't warn about that. > > Same for !FB_ID and CRTC_ID being set. > > Signed-off-by: Maarten Lankhorst

Re: [PATCH v2] drm/edid: use true and false for boolean values

On Tue, Jan 30, 2018 at 10:09:27AM -0500, Sean Paul wrote: > On Tue, Jan 30, 2018 at 04:05:28AM -0600, Gustavo A. R. Silva wrote: > > Assign true or false to boolean variables instead of an integer value. > > > > This issue was detected with the help of Coccinelle. > > I suppose you could also

Re: [AMDGPU][TAHITI XT] new display code

On 2018-01-29 05:55 PM, Alex Deucher wrote: > On Mon, Jan 29, 2018 at 5:35 PM, wrote: >> On Mon, Jan 29, 2018 at 03:40:34PM -0500, Alex Deucher wrote: >>> On Mon, Jan 29, 2018 at 3:34 PM, wrote: As far as I can remember, not for the

Re: [PATCH] drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS

On Tue, Jan 30, 2018 at 09:47:01AM -0500, Sean Paul wrote: > HDCP was a bit too chatty to get along with the rest of the i915 driver. > > Suggested-by: Daniel Vetter > Signed-off-by: Sean Paul Reviewed-by: Daniel Vetter >

Re: [PATCH v2] drm/stm: drv: Improve data transfers

Hi Benjamin, On Tuesday, 30 January 2018 17:08:48 EET Benjamin Gaignard wrote: > 2018-01-30 15:58 GMT+01:00 Laurent Pinchart: > > On Tuesday, 30 January 2018 12:42:00 EET Philippe Cornu wrote: > >> To optimize data transfers, align pitch on 128 bytes & height > >> on 4 bytes. This optimization is

Re: [PATCH v2] drm/edid: use true and false for boolean values

On Tue, Jan 30, 2018 at 04:05:28AM -0600, Gustavo A. R. Silva wrote: > Assign true or false to boolean variables instead of an integer value. > > This issue was detected with the help of Coccinelle. I suppose you could also fix up the other preferred assignment by adding !! to the bitwise &

Re: [PATCH v2] drm/stm: drv: Improve data transfers

2018-01-30 15:58 GMT+01:00 Laurent Pinchart : > Hi Philippe, > > Thank you for the patch. > > On Tuesday, 30 January 2018 12:42:00 EET Philippe Cornu wrote: >> To optimize data transfers, align pitch on 128 bytes & height >> on 4 bytes. This optimization is not

Re: [PATCH v2] drm/stm: drv: Improve data transfers

Hi Benjamin, On Tuesday, 30 January 2018 12:51:25 EET Benjamin Gaignard wrote: > 2018-01-30 11:42 GMT+01:00 Philippe Cornu : > > To optimize data transfers, align pitch on 128 bytes & height > > on 4 bytes. This optimization is not applicable on hw without MMU. > > > >

[Bug 104624] [regression, vega] Running DOOM causes *ERROR* amdgpu_dm_commit_planes: acrtc 2, already busy WARNING amdgpu_dm_atomic_commit_tail and prepare_flip_isr

https://bugs.freedesktop.org/show_bug.cgi?id=104624 --- Comment #3 from Harry Wentland --- The kernel. Guess I should've specified that. :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel

Re: [PATCH v2] drm/stm: drv: Improve data transfers

Hi Philippe, Thank you for the patch. On Tuesday, 30 January 2018 12:42:00 EET Philippe Cornu wrote: > To optimize data transfers, align pitch on 128 bytes & height > on 4 bytes. This optimization is not applicable on hw without MMU. > > Signed-off-by: Yannick Fertre >

[PATCH] drm/i915: Downgrade hdcp logs from INFO to DEBUG_KMS

HDCP was a bit too chatty to get along with the rest of the i915 driver. Suggested-by: Daniel Vetter Signed-off-by: Sean Paul --- drivers/gpu/drm/i915/intel_hdcp.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH v2] drm/i915: Restore HDCP DRM_INFO when with no downstream

The commit below returned earlier than before, but failed to move the info message when authenticating without downstream devices. This patch restores the message on authentication success. Changes in v2: - s/no downstream devices/no repeater present/ (Ram) Fixes: 87eb3ec818fa ("drm/i915: II

Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read requests

Hi Archit, And many thanks, Philippe :-) On 01/30/2018 03:09 PM, Archit Taneja wrote: > > > On 01/26/2018 06:14 AM, Brian Norris wrote: >> On Thu, Jan 25, 2018 at 11:37:59AM +0100, Philippe Cornu wrote: >>> The dcs/generic dsi read feature is not yet implemented so it >>> is important to warn

Re: [PATCH] drm/i915: Restore HDCP DRM_INFO when with no downstream

On Tue, Jan 30, 2018 at 09:35:34AM +0100, Daniel Vetter wrote: > On Mon, Jan 22, 2018 at 12:55:00PM -0500, Sean Paul wrote: > > The commit below returned earlier than before, but failed to move the > > info message when authenticating without downstream devices. This patch > > restores the message

Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read requests

On 01/26/2018 06:14 AM, Brian Norris wrote: On Thu, Jan 25, 2018 at 11:37:59AM +0100, Philippe Cornu wrote: The dcs/generic dsi read feature is not yet implemented so it is important to warn the host_transfer() caller in case of read operation requests. Signed-off-by: Philippe Cornu

Re: [PATCH v2 2/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value

On 01/26/2018 06:16 AM, Brian Norris wrote: On Thu, Jan 25, 2018 at 11:38:00AM +0100, Philippe Cornu wrote: The dw_mipi_dsi_host_transfer() must return the number of bytes transmitted/received on success instead of 0. Note: As the read feature is not implemented, only the transmitted number

Re: [PATCH 3/4] drm: add ARM flush implementations

On Thu, Jan 18, 2018 at 08:42:55AM +0100, Daniel Vetter wrote: > On Wed, Jan 17, 2018 at 11:46 PM, Gurchetan Singh > wrote: > >> dma api just isn't quite sufficient for implementing fast gpu drivers. > > > > > > Can you elaborate? IIRC the DMA API has strong

Re: [PATCH] dma-buf: Refanctor reservation_object_add_shared_fence()

Am 30.01.2018 um 13:50 schrieb Chris Wilson: Quoting Christian König (2018-01-30 12:26:05) Am 30.01.2018 um 10:32 schrieb Chris Wilson: Adding a shared fence to a reservation_object is currently split into two handlers, one to insert the fence into the existing array and the other to replace

Re: [PATCH] dma-buf: Refanctor reservation_object_add_shared_fence()

Quoting Christian König (2018-01-30 12:26:05) > Am 30.01.2018 um 10:32 schrieb Chris Wilson: > > Adding a shared fence to a reservation_object is currently split into > > two handlers, one to insert the fence into the existing array and the > > other to replace the existing array with a new larger

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Am 30.01.2018 um 13:28 schrieb Michal Hocko: I do think you should completely ignore the size of the swap space. IMHO you should forbid further allocations when your current buffer storage cannot be reclaimed. So you need some form of feedback mechanism that would tell you: "Your buffers have

Re: [PATCH 4/4] drm/amdgpu: Use drm_oom_badness for amdgpu.

That definitely what I planned, just didn't want to clutter the RFC with multiple repeated changes. Thanks, Andrey On 01/30/2018 04:24 AM, Daniel Vetter wrote: On Thu, Jan 18, 2018 at 11:47:52AM -0500, Andrey Grodzovsky wrote: Signed-off-by: Andrey Grodzovsky

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

On Tue 30-01-18 11:32:49, Christian König wrote: > Am 30.01.2018 um 11:18 schrieb Michal Hocko: > > On Tue 30-01-18 10:00:07, Christian König wrote: > > > Am 30.01.2018 um 08:55 schrieb Michal Hocko: > > > > On Tue 30-01-18 02:56:51, He, Roger wrote: > > > > > Hi Michal: > > > > > > > > > > We

Re: [PATCH 2/5] drm: add ARM flush implementation

On Tue, Jan 30, 2018 at 12:31 PM, Russell King - ARM Linux wrote: > On Tue, Jan 30, 2018 at 11:14:36AM +0100, Daniel Vetter wrote: >> On Tue, Jan 23, 2018 at 06:56:03PM -0800, Gurchetan Singh wrote: >> > The dma_cache_maint_page function is important for cache maintenance

Re: [PATCH] dma-buf: Refanctor reservation_object_add_shared_fence()

Am 30.01.2018 um 10:32 schrieb Chris Wilson: Adding a shared fence to a reservation_object is currently split into two handlers, one to insert the fence into the existing array and the other to replace the existing array with a new larger array. The first step in both of these routines involves

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 12:42 schrieb Michel Dänzer: On 2018-01-30 12:36 PM, Nicolai Hähnle wrote: On 30.01.2018 12:34, Michel Dänzer wrote: On 2018-01-30 12:28 PM, Christian König wrote: Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um

Re: [RFC] Per file OOM badness

On 2018-01-30 12:36 PM, Nicolai Hähnle wrote: > On 30.01.2018 12:34, Michel Dänzer wrote: >> On 2018-01-30 12:28 PM, Christian König wrote: >>> Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: > Am 30.01.2018 um 10:43 schrieb Michel Dänzer:

Re: [RFC] Per file OOM badness

On 30.01.2018 12:34, Michel Dänzer wrote: On 2018-01-30 12:28 PM, Christian König wrote: Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget

Re: [RFC] Per file OOM badness

On 30.01.2018 11:48, Michel Dänzer wrote: On 2018-01-30 11:42 AM, Daniel Vetter wrote: On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote: On 2018-01-30 10:31 AM, Daniel Vetter wrote: I guess a good first order approximation would be if we simply charge any newly allocated buffers

Re: [RFC] Per file OOM badness

On 2018-01-30 12:28 PM, Christian König wrote: > Am 30.01.2018 um 12:02 schrieb Michel Dänzer: >> On 2018-01-30 11:40 AM, Christian König wrote: >>> Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] > Would it be ok to hang onto potentially arbitrary mmget references > essentially

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget references essentially forever? If that's ok I think we can do your process based account

Re: [RFC] Per file OOM badness

On 2018-01-30 11:40 AM, Christian König wrote: > Am 30.01.2018 um 10:43 schrieb Michel Dänzer: >> [SNIP] >>> Would it be ok to hang onto potentially arbitrary mmget references >>> essentially forever? If that's ok I think we can do your process based >>> account (minus a few minor inaccuracies for

Re: [PATCH] drm/stm: dsi: Add 1.31 version support

Hi Benjamin, and many thanks Philippe :-) On 01/30/2018 11:52 AM, Benjamin Gaignard wrote: > 2018-01-22 17:46 GMT+01:00 Philippe Cornu : >> Add support for the stm dsi phy/wrapper version 1.31. >> Only lane capabilities need to be modified. >> >> Signed-off-by: Philippe

Re: [Intel-gfx] [RFC 3/6] drm/i915: Give our log messages our name

On 26/01/2018 13:10, Michal Wajdeczko wrote: On Wed, 24 Jan 2018 17:18:18 +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Define DRM_LOG_NAME to i915 so that the log messages we output change from:  [drm] RC6 on to:  [i915] RC6 on

Re: [PATCH] drm/stm: dsi: Add 1.31 version support

2018-01-22 17:46 GMT+01:00 Philippe Cornu : > Add support for the stm dsi phy/wrapper version 1.31. > Only lane capabilities need to be modified. > > Signed-off-by: Philippe Cornu Applied on drm-misc-next. Regards, Benjamin > --- >

Re: [PATCH] dt-bindings: display: stm32: correct clock-names in dsi panel example

2018-01-30 0:15 GMT+01:00 Rob Herring : > On Mon, Jan 22, 2018 at 04:35:47PM +0100, Philippe Cornu wrote: >> In the dsi panel example, clock names in the "clock-names" >> field have been swapped: >> * "pclk" (peripheral clock) is < 1 CLK_F469_DSI> on stm32f4 >> * "ref" (dsi phy

Re: [PATCH v2] drm/stm: drv: Improve data transfers

2018-01-30 11:42 GMT+01:00 Philippe Cornu : > To optimize data transfers, align pitch on 128 bytes & height > on 4 bytes. This optimization is not applicable on hw without MMU. > > Signed-off-by: Yannick Fertre > Signed-off-by: Vincent Abriou

Re: [RFC] Per file OOM badness

On 2018-01-30 11:42 AM, Daniel Vetter wrote: > On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote: >> On 2018-01-30 10:31 AM, Daniel Vetter wrote: >> >>> I guess a good first order approximation would be if we simply charge any >>> newly allocated buffers to the process that created

[Bug 104808] [mesa 18.0.0-rc2][bisected] Radeonsi doesn’t work correctly in wayland session (gnome-shell)

https://bugs.freedesktop.org/show_bug.cgi?id=104808 Michel Dänzer changed: What|Removed |Added Resolution|--- |NOTOURBUG

[PATCH v2] drm/stm: drv: Improve data transfers

To optimize data transfers, align pitch on 128 bytes & height on 4 bytes. This optimization is not applicable on hw without MMU. Signed-off-by: Yannick Fertre Signed-off-by: Vincent Abriou Signed-off-by: Philippe Cornu ---

Re: [RFC] Per file OOM badness

On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote: > On 2018-01-30 10:31 AM, Daniel Vetter wrote: > > On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote: > >> Am 24.01.2018 um 12:50 schrieb Michal Hocko: > >>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote: > On

Re: [RFC] Per file OOM badness

Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget references essentially forever? If that's ok I think we can do your process based account (minus a few minor inaccuracies for shared stuff perhaps, but no one cares about that).

Re: [PATCH] dma-fence: add comment for WARN_ON in dma_fence_release()

On Mon, Jan 29, 2018 at 05:40:02PM +0200, Oded Gabbay wrote: > In dma_fence_release() there is a WARN_ON which could be triggered by > several cases of wrong dma-fence usage. This patch adds a comment to > explain two use-cases to help driver developers that use dma-fence > and trigger that

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

Am 30.01.2018 um 11:18 schrieb Michal Hocko: On Tue 30-01-18 10:00:07, Christian König wrote: Am 30.01.2018 um 08:55 schrieb Michal Hocko: On Tue 30-01-18 02:56:51, He, Roger wrote: Hi Michal: We need a API to tell TTM module the system totally has how many swap cache. Then TTM module can

Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

Op 29-01-18 om 16:41 schreef Leo Li: > Updated IGT results seem sane: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html > > Would someone be able to apply this patch? > Thanks for the reminder, pushed. ~Maarten ___ dri-devel mailing

Re: [RFC] Per file OOM badness

On Tue 30-01-18 10:29:10, Michel Dänzer wrote: > On 2018-01-24 12:50 PM, Michal Hocko wrote: > > On Wed 24-01-18 12:23:10, Michel Dänzer wrote: > >> On 2018-01-24 12:01 PM, Michal Hocko wrote: > >>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote: > > [...] > 2. If the OOM killer kills a

Re: [RFC v2 02/10] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info

On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote: > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'. > This is to model formats where multiple pixels are stored together > in a specific way, likely byte-algined. For example, if 3 - 10 bit > pixels are stored in 32

[PATCH] drm/atomic: Remove WARN_ON for invalid plane configuration.

Userspace can set a FB_ID on a plane without setting CRTC_ID, which will fail with -EINVAL, but the kernel shouldn't warn about that. Same for !FB_ID and CRTC_ID being set. Signed-off-by: Maarten Lankhorst Acked-by: Daniel Vetter Cc:

Re: [RFC v2 10/10] drm: drm_fourcc: Add new formats to the drm format table

On Thu, Jan 25, 2018 at 06:04:07PM -0800, Hyun Kwon wrote: > This adds new formats (packed YUV and grey scale) to > the drm format table. > > Signed-off-by: Hyun Kwon Same here, merging the uapi defines and the internal descriptions seems better. -Daniel > --- > v2 > -

Re: [RFC v2 07/10] drm: drm_fourcc: Add new 10bit formats to drm_format_info table

On Thu, Jan 25, 2018 at 06:04:04PM -0800, Hyun Kwon wrote: > Add information for DRM_FORMAT_XV15 and DRM_FORMAT_XV20 to > the drm format table. > > Signed-off-by: Hyun Kwon Imo better to merge this with the previous patch, easier to review that way. -Daniel > --- > v2 > -

Re: [RFC v2 01/10] drm: drm:fourcc: Add bpp information to struct drm_format_info

On Thu, Jan 25, 2018 at 06:03:58PM -0800, Hyun Kwon wrote: > 'cpp' doesn't work for any format where component size is not byte aligned. > Add 'bpp' to have a bit level information. Add a meesage to > drm_format_plane_cpp() to indicate that the returned cpp would be > rounded for non byte aligned

Re: [RFC v2 02/10] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info

On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote: > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'. > This is to model formats where multiple pixels are stored together > in a specific way, likely byte-algined. For example, if 3 - 10 bit > pixels are stored in 32

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

On Tue 30-01-18 10:00:07, Christian König wrote: > Am 30.01.2018 um 08:55 schrieb Michal Hocko: > > On Tue 30-01-18 02:56:51, He, Roger wrote: > > > Hi Michal: > > > > > > We need a API to tell TTM module the system totally has how many swap > > > cache. Then TTM module can use it to restrict

  1   2   >