Re: [RFC] Per file OOM badness

On 2018-01-24 12:01 PM, Michal Hocko wrote: > On Wed 24-01-18 11:27:15, Michel Dänzer wrote: >> On 2018-01-24 10:28 AM, Michal Hocko wrote: > [...] >>> So how exactly then helps to kill one of those processes? The memory >>> stays pinned behind or do I still misunderstand? >> >> Fundamentally, the

Re: [RFC] Per file OOM badness

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 process which is sharing BOs with another > >> process, this should result in the other process dropping its

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

Am Dienstag, den 23.01.2018, 18:56 -0800 schrieb Gurchetan Singh: > The dma_cache_maint_page function is important for cache maintenance on > ARM32 (this was determined via testing). > > Since we desire direct control of the caches in drm_cache.c, let's make > a copy of the function, rename it

[Bug 104745] HEVC VDPAU decoding broken on RX 460 with UVD Firmware v1.130

https://bugs.freedesktop.org/show_bug.cgi?id=104745 --- Comment #5 from Emil Velikov --- Nicely spotted guys. I'll pick Boyuan's VCN/UVD fixed for the next 17.3 release. Feel free to forward future requests to the mesa-stable@ mailing list. I won't be able to catch

Re: [PATCH 3/5] drm: add ARM64 flush implementations

On 24/01/18 12:36, Russell King - ARM Linux wrote: On Wed, Jan 24, 2018 at 12:00:59PM +, Robin Murphy wrote: On 24/01/18 02:56, Gurchetan Singh wrote: This patch uses the __dma_map_area function to flush the cache on ARM64. v2: Don't use DMA API, call functions directly (Daniel)

Re: [RFC] Per file OOM badness

Am 24.01.2018 um 12:50 schrieb Michal Hocko: 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 process which is sharing BOs with another process, this should result in

Re: [PATCH v1 2/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read operations

Hi Brian, On 01/23/2018 10:28 PM, Brian Norris wrote: > Hi Philippe, > > I see you sent this out already today, while I only just responded > (late) to your questions about it... oh well :) > I got a short period to clean-up and adds features to this driver (1.31 ip version + maybe the read

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

Hi Brian, And many thanks for your review. On 01/23/2018 10:38 PM, Brian Norris wrote: > Hi Philippe, > > On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu wrote: >> The dw_mipi_dsi_host_transfer() must return the number of >> bytes transmitted/received on success instead

Re: [PATCH] drm/etnaviv: fix '%x' warning

Hi Gustavo, Am Dienstag, den 23.01.2018, 11:07 -0600 schrieb Gustavo A. R. Silva: > Fix the following warning by using %zx instead of %x for variable of > type size_t: > > warning: format ‘%x’ expects argument of type ‘unsigned int’, but > argument 4 has type ‘size_t {aka long unsigned int}’

[Bug 104756] [bisected] [kabini] [regression] [drm:amdgpufb_create] *ERROR* failed to create fbcon object -12

https://bugs.freedesktop.org/show_bug.cgi?id=104756 Christian König changed: What|Removed |Added Status|RESOLVED

[Bug 104736] Kernel panic with agd5's drm-next-4.17-wip & GFX8/Polaris10/Ellesmere/Rx-480-8GiB

https://bugs.freedesktop.org/show_bug.cgi?id=104736 Christian König changed: What|Removed |Added Status|NEW

Re: [PATCH 3/5] drm: add ARM64 flush implementations

On 24/01/18 02:56, Gurchetan Singh wrote: This patch uses the __dma_map_area function to flush the cache on ARM64. v2: Don't use DMA API, call functions directly (Daniel) Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/drm_cache.c | 13 + 1 file

Re: [RFC][PATCH 4/4 v2] drm_hwcomposer: Try to fallback if GLCompisition fails

On Tue, Jan 23, 2018 at 03:16:39PM -0800, John Stultz wrote: > When using drm_hwcomposer with the hikey board, the resulting > display shows lots of tearing. > > This seems to be due to EGLcomposition not initializing > properly, potentially due to I'm guessing limitations of what > the utgard

[Bug 104738] Radeon HD 6970M/6990M crash on iMac on boot - only nomodeset helps

https://bugs.freedesktop.org/show_bug.cgi?id=104738 --- Comment #4 from hansmatro...@gmail.com --- Created attachment 136942 --> https://bugs.freedesktop.org/attachment.cgi?id=136942=edit lspci.log -- You are receiving this mail because: You are the assignee for the

[Bug 104738] Radeon HD 6970M/6990M crash on iMac on boot - only nomodeset helps

https://bugs.freedesktop.org/show_bug.cgi?id=104738 --- Comment #3 from hansmatro...@gmail.com --- Created attachment 136941 --> https://bugs.freedesktop.org/attachment.cgi?id=136941=edit dmesg.log -- You are receiving this mail because: You are the assignee for the

[PATCH v2 2/2] drm/etnaviv: remove the need for a gpu-subsystem DT node

The module autoloading can be triggered through the GPU core nodes and the necessary platform device for the DRM toplevel device will be instantiated on module init. Suggested-by: Rob Herring Signed-off-by: Lucas Stach ---

[PATCH v2 1/2] dt-bindings: etnaviv: add slave interface clock

Newer GPU cores added a new clock input, which allows to gate the slave (AHB) interface independently from other parts of the GPU. Add it to the supported clocks. Signed-off-by: Lucas Stach --- v2: State when this clock is required. ---

Re: [PATCH] drm: fix gpu scheduler link order

On Wed, Jan 24, 2018 at 5:46 AM, Christian König wrote: > It should initialize before the drivers using it. > > Signed-off-by: Christian König > Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104736 Reviewed-by: Alex Deucher

Re: [Intel-gfx] [RFC v2 0/6] DRM logging tidy

Quoting Tvrtko Ursulin (2018-01-24 16:18:15) > From: Tvrtko Ursulin > > This series tries to solve a few issues in the current DRM logging code to > primarily make it clearer which messages belong to which driver. > > Main problem is that currently some logging

Re: [PATCH 1/5] drm/rcar-du: Use drm_mode_get_hv_timing() to populate plane clip rectangle

On Wed, Jan 24, 2018 at 02:07:30AM +0200, Laurent Pinchart wrote: > Hi Ville, > > Thank you for the patch. > > On Tuesday, 23 January 2018 19:08:53 EET Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Use drm_mode_get_hv_timing() to fill out the plane clip

Re: [RFC][PATCH 2/4 v2] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

On Tue, Jan 23, 2018 at 03:16:37PM -0800, John Stultz wrote: > This allows for importing buffers allocated from the > hikey and hikey960 gralloc implelementations. > > Cc: Marissa Wall > Cc: Sean Paul > Cc: Dmitry Shmidt > Cc:

Re: [RFC][PATCH 1/4 v2] drm_hwcomposer: Make sure we set the active state when doing modesets

On Tue, Jan 23, 2018 at 03:16:36PM -0800, John Stultz wrote: > In trying to use drm_hwcomposer with HiKey/HiKey960 boards, I > found that the crtc wouldn't intitalize and the atomic commit > calls were failing. > > I initially chased this down to following check in the kernel >

[Bug 104738] Radeon HD 6970M/6990M crash on iMac on boot - only nomodeset helps

https://bugs.freedesktop.org/show_bug.cgi?id=104738 --- Comment #6 from hansmatro...@gmail.com --- Thanks for your replay @Michel Tested but the system crash and the screen becomes only black. @Alex Done -- You are receiving this mail because: You are the assignee for the

[Bug 104738] Radeon HD 6970M/6990M crash on iMac on boot - only nomodeset helps

https://bugs.freedesktop.org/show_bug.cgi?id=104738 --- Comment #5 from hansmatro...@gmail.com --- Created attachment 136943 --> https://bugs.freedesktop.org/attachment.cgi?id=136943=edit grub.cfg -- You are receiving this mail because: You are the assignee for the

Re: [RFC][PATCH 2/4 v2] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

On Tue, Jan 23, 2018 at 03:16:37PM -0800, John Stultz wrote: > This allows for importing buffers allocated from the > hikey and hikey960 gralloc implelementations. > > Cc: Marissa Wall > Cc: Sean Paul > Cc: Dmitry Shmidt > Cc:

[Bug 104738] Radeon HD 6970M/6990M crash on iMac on boot - only nomodeset helps

https://bugs.freedesktop.org/show_bug.cgi?id=104738 --- Comment #7 from Michel Dänzer --- I suspect Alex meant the full dmesg output without nomodeset. :) -- You are receiving this mail because: You are the assignee for the

<    1   2