[PATCH 02/11] drm/amdgpu: use ttm process in amdgpu vm

Change-Id: I2cf802e641d8b2cdb2bf8bdf1957f3f4f27afaba Signed-off-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/a

[PATCH 00/11] ***[WIP] TTM per process lru ***

Since per-process-bo feature is introduced, old lru isn't working for it. old lru order is depending on BO list order, which will be updated by bo list after every command submission. But for per-process-bo, which aren't in bo list, so it have no chance to refresh its order in lru. Which also will

[PATCH 01/11] drm/ttm: add ttm process struct

Change-Id: I34924a40392653e72f143c30ab312cbbf9fa Signed-off-by: Chunming Zhou --- drivers/gpu/drm/ttm/ttm_bo.c| 23 +++ include/drm/ttm/ttm_bo_api.h| 1 + include/drm/ttm/ttm_bo_driver.h | 10 ++ 3 files changed, 34 insertions(+) diff --git a/drivers/gpu/

[Bug 104190] Artifacts in CSGO map de_cache when shader level is "high" or "very high (default)"

https://bugs.freedesktop.org/show_bug.cgi?id=104190 --- Comment #7 from Gregor Münch --- Is it a good idea to close this bug? There seem to be a number of bugs affected by a problem with llvm 5.0. Unfortunatly, LLVM 5.0 series releases no stable builds, so a fix cant be backported there. I guess

Re: [PATCH v6 23/30] drm/rockchip: analogix_dp: Do not call Analogix code before bind

On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: Tomasz Figa > > Driver callbacks, such as system suspend or resume can be called any > time, specifically they can be called before the component bind > callback. Let's use dp->adp pointer as a safeguard and skip calling > Analogix entry p

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

Am Donnerstag, den 12.04.2018, 11:35 +0200 schrieb Christian König: > Am 12.04.2018 um 11:11 schrieb Lucas Stach: > > Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König: > > > Am 11.04.2018 um 19:11 schrieb Robin Murphy: > > > > For dma_map_sg(), DMA API implementations are free to me

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

Am 12.04.2018 um 08:26 schrieb Christoph Hellwig: On Wed, Apr 11, 2018 at 01:03:59PM +0100, 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 h

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

Am 12.04.2018 um 11:11 schrieb Lucas Stach: Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König: 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

Re: [PATCH] drm/vc4: Fix leak of the file_priv that stored the perfmon.

On Mon, 9 Apr 2018 13:58:13 -0700 Eric Anholt wrote: > Signed-off-by: Eric Anholt > Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Reviewed-by: Boris Brezillon > --- > drivers/gpu/drm/vc4/vc4_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/

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

Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König: > 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

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

Hi Lucas, On Wed, 2018-04-11 at 17:31 +0200, Lucas Stach wrote: > 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 D

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

On 2018-04-12 01:30 AM, Cyr, Aric wrote: >> From: Michel Dänzer [mailto:mic...@daenzer.net] >> Sent: Wednesday, April 11, 2018 05:50 >> On 2018-04-11 08:57 AM, Nicolai Hähnle wrote: >>> On 10.04.2018 23:45, Cyr, Aric wrote: How does it work fine today given that all kernel seems to know is >>>

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

https://bugzilla.kernel.org/show_bug.cgi?id=199085 Stuart Foster (smf.li...@ntlworld.com) changed: What|Removed |Added Status|REOPENED|RESOLVED

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

https://bugs.freedesktop.org/show_bug.cgi?id=105680 Marta Löfstedt changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|FIXED

[Bug 105996] [DC][CIK] Bonaire mobile - No displays being turned on

https://bugs.freedesktop.org/show_bug.cgi?id=105996 --- Comment #1 from Shawn Starr --- Created attachment 138778 --> https://bugs.freedesktop.org/attachment.cgi?id=138778&action=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug.___

[Bug 105996] [DC][CIK] Bonaire mobile - No displays being turned on

https://bugs.freedesktop.org/show_bug.cgi?id=105996 Bug ID: 105996 Summary: [DC][CIK] Bonaire mobile - No displays being turned on Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All)

[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 #6 from Michel Dänzer (mic...@daenzer.net) --- (In reply to Harry Wentland from comment #5) > I'm reluctant to just revert the offending commit as it's not incorrect > but seems to expose some other flaws in our atomic check/commit > i

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

https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #10 from Michel Dänzer --- (In reply to David Henningsson from comment #8) > The regression is between 4.15rc2 and 4.15rc3 Any chance you can bisect between these two? -- You are receiving this mail because: You are the assignee f

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

https://bugs.freedesktop.org/show_bug.cgi?id=105680 Marta Löfstedt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

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

https://bugs.freedesktop.org/show_bug.cgi?id=105680 Marta Löfstedt changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail

[Bug 97909] X-Plane 10 crashes with SIGSEGV on radeonsi

https://bugs.freedesktop.org/show_bug.cgi?id=97909 --- Comment #13 from Joonas Sarajärvi --- I can test this week. In my opinion, leaving this a WONTFIX would be quite unfortunate, because as far as I know, the free AMD GPU drivers are pretty much the only way to run X-Plane reasonably well with

Re: AMD graphics performance regression in 4.15 and later

On 04/11/2018 05:37 AM, Christian König wrote: >> With your patches my EPYC box is unusable with  4.15++ kernels. >> The whole Desktop is acting weird.  This one is using >> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU. >> >> Box is  2 * EPYC 7281 with 128 GB ECC RAM >> >> Also a 14C Xeon

Re: AMD graphics performance regression in 4.15 and later

2018-04-12 0:20 GMT+02:00 Gabriel C : > 2018-04-11 20:35 GMT+02:00 Jean-Marc Valin : >> On 04/11/2018 05:37 AM, Christian König wrote: With your patches my EPYC box is unusable with 4.15++ kernels. The whole Desktop is acting weird. This one is using an Cape Verde PRO [Radeon HD 77

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

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 for systems with IOMMU. > > So

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 11:37 GMT+02:00 Christian König : > 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

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 20:35 GMT+02:00 Jean-Marc Valin : > On 04/11/2018 05:37 AM, Christian König wrote: >>> With your patches my EPYC box is unusable with 4.15++ kernels. >>> The whole Desktop is acting weird. This one is using >>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU. >>> >>> Box is 2 *

Re: AMD graphics performance regression in 4.15 and later

2018-04-11 16:26 GMT+02:00 Gabriel C : > 2018-04-11 11:37 GMT+02:00 Christian König : >> Am 11.04.2018 um 06:00 schrieb Gabriel C: ... >> >> Please test Alex's amd-staging-drm-next branch from >> git://people.freedesktop.org/~agd5f/linux. > > I'm on it just the connection to freedesktop.org is slo

RE: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

Hi Oleksandr, Just have a question, is this drm/xen-front stuff orthogonal to xen shared coprocessor framework for gpu, or are they exclusive? Thanks, Peng. > Subject: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV > display frontend > > From: Oleksandr Andrushchenko > > Hell

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

On 11 April 2018 at 22:27, Jani Nikula wrote: > 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

Re: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

Hi, Peng! On 04/12/2018 05:21 AM, Peng Fan wrote: Hi Oleksandr, Just have a question, is this drm/xen-front stuff orthogonal to xen shared coprocessor framework for gpu, or are they exclusive? They are orthogonal Thanks, Peng. ___ dri-devel mailin

[PATCH V3] 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. The hardware actually needs the dma_address on a page by page basis. Joining multiple consecutiv

<    1   2