Am 17.01.20 um 08:48 schrieb Huang Rui:
The alignment should match the page size for secure buffer, so we didn't
configure it anymore.
Signed-off-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4
1 file changed, 4 deletions(-)
diff --git a
Am 17.01.20 um 03:01 schrieb Felix Kuehling:
On 2020-01-16 8:09, Christian König wrote:
Coreboot seems to have a problem correctly setting up access to the
stolen VRAM
on KV/KB. Use the direct access only when necessary.
I'm not sure what you mean by "necessary".
Necessary for better perfor
[AMD Official Use Only - Internal Distribution Only]
Submitting patch to disable access of RAS EEPROM in event SMU is disabled
during modprobe phase.
Thank you,
John Clements
0001-drm-amdgpu-Added-check-for-RAS-EEPROM-support.patch
Description: 0001-drm-amdgpu-Added-check-for-RAS-EEPROM-suppor
Am 17.01.20 um 09:17 schrieb Christian König:
Am 17.01.20 um 03:01 schrieb Felix Kuehling:
On 2020-01-16 8:09, Christian König wrote:
Coreboot seems to have a problem correctly setting up access to the
stolen VRAM
on KV/KB. Use the direct access only when necessary.
I'm not sure what you mea
Hi Luben,
On 1/16/20 6:13 PM, Luben Tuikov wrote:
- * Note: the rq_list should have atleast one element to schedule
+ * Note: the sched_list should have atleast one element to schedule
"atleast" --> "at least".
Always a tricky one to catch, Thanks!
I will create a patch and ask Alex to squash
Hi
Am 16.01.20 um 00:18 schrieb Rodrigo Siqueira:
> Hi,
>
> Thanks for the patch, I reviewed and tested it. Everything looks fine
> for VKMS.
>
> Reviewed-by: Rodrigo Siqueira
> Tested-by: Rodrigo Siqueira
Thanks a lot.
Best regards
Thomas
>
> On 01/15, Thomas Zimmermann wrote:
>> VBLANK c
On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
>
> This allocation isn't required and can fail when resuming from suspend.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009
> Signed-off-by: Dor Askayo
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
> 1 file c
Hi,
Static analysis with Coverity has detected a division by zero in the
following commit:
commit 5b5abe9526073ccbf3032d27b5864520829cdd9c
Author: Anthony Koo
Date: Mon Dec 9 17:26:34 2019 -0500
drm/amd/display: make PSR static screen entry within 30 ms
Specifically:
unsigned int
From: Colin Ian King
A for-loop is iterating from 0 up to 1000 however the loop variable count
is a u8 and hence not large enough. Fix this by making count an int.
Also remove the redundant initialization of count since this is never used
and add { } on the loop statement make the loop block cle
Am 17.01.2020 14:33, schrieb Colin King:
> From: Colin Ian King
>
> A for-loop is iterating from 0 up to 1000 however the loop variable count
> is a u8 and hence not large enough. Fix this by making count an int.
> Also remove the redundant initialization of count since this is never used
> a
[AMD Official Use Only - Internal Distribution Only]
Hello John,
The patch is good enough to deal with the modified IP_MASK parameter which
masked out SMU IP block, but I don't think it is able to deal with module
parameter dpm=0. Please check with Kenneth to have a better solution for both
ca
On Fri, Dec 13, 2019 at 3:09 PM wrote:
>
> From: Mikita Lipski
>
Hi Mikita,
Unfortunately this patch causes a crash on my i915 device when I
unplug my MST hub. The panic is below.
[ 38.514014] BUG: kernel NULL pointer dereference, address: 0030
[ 38.521801] #PF: supervisor read
[AMD Official Use Only - Internal Distribution Only]
That's a known separated issue. Eve it get fixed, we don’t need additional call
in to any bo functions. So let's just create separated fix for that one. You
want to send out the patch?
Regards,
Hawking
-Original Message-
From: amd-gf
On 1/17/20 10:09 AM, Sean Paul wrote:
On Fri, Dec 13, 2019 at 3:09 PM wrote:
From: Mikita Lipski
Hi Mikita,
Unfortunately this patch causes a crash on my i915 device when I
unplug my MST hub. The panic is below.
Hi Sean,
I thought this issue was fixed by Wayne Lin in
https://patchwo
On Fri, Jan 17, 2020 at 10:26 AM Mikita Lipski wrote:
>
>
>
> On 1/17/20 10:09 AM, Sean Paul wrote:
> > On Fri, Dec 13, 2019 at 3:09 PM wrote:
> >>
> >> From: Mikita Lipski
> >>
> >
> > Hi Mikita,
> > Unfortunately this patch causes a crash on my i915 device when I
> > unplug my MST hub. The pan
On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote:
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, December 7, 2019 3:57 AM
> > To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> > amd-gfx@lists.freedesktop.org
> > Cc: Kazlauskas, Nicholas ; Wentland, Harry
> > ; Zuo
On 2020-01-17 3:17 a.m., Christian König wrote:
Am 17.01.20 um 03:01 schrieb Felix Kuehling:
On 2020-01-16 8:09, Christian König wrote:
Coreboot seems to have a problem correctly setting up access to the
stolen VRAM
on KV/KB. Use the direct access only when necessary.
I'm not sure what you m
Am 17.01.20 um 18:07 schrieb Felix Kuehling:
On 2020-01-17 3:17 a.m., Christian König wrote:
Am 17.01.20 um 03:01 schrieb Felix Kuehling:
On 2020-01-16 8:09, Christian König wrote:
Coreboot seems to have a problem correctly setting up access to the
stolen VRAM
on KV/KB. Use the direct access
On Thu, Jan 16, 2020 at 3:30 PM Bhawanpreet Lakha
wrote:
>
> [Why]
> We need to set/get SRM and linux kernel is not suppose to write to the
> storage, so we need to provide a interface.
>
> [How]
> Provide interface so usermode can set/get srm
>
> Signed-off-by: Bhawanpreet Lakha
> Reviewed-by: R
On 2020-01-17 2:23 p.m., Alex Deucher wrote:
On Thu, Jan 16, 2020 at 3:30 PM Bhawanpreet Lakha
wrote:
[Why]
We need to set/get SRM and linux kernel is not suppose to write to the
storage, so we need to provide a interface.
[How]
Provide interface so usermode can set/get srm
Signed-off-by: B
fwiw - https://patchwork.freedesktop.org/patch/349111/ is the proper fix that
I was talking about, we should probably go with that one instead if you
haven't already pushed this
On Fri, 2020-01-17 at 10:39 -0500, Sean Paul wrote:
> On Fri, Jan 17, 2020 at 10:26 AM Mikita Lipski wrote:
> >
> >
>
On Fri, 2020-01-17 at 11:19 -0500, Sean Paul wrote:
> On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote:
> >
> >
> > > -Original Message-
> > > From: Lyude Paul
> > > Sent: Saturday, December 7, 2019 3:57 AM
> > > To: Lin, Wayne ; dri-de...@lists.freedesktop.org;
> > > amd-gfx@lists.free
On Fri, Jan 17, 2020 at 3:27 PM Lyude Paul wrote:
>
> On Fri, 2020-01-17 at 11:19 -0500, Sean Paul wrote:
> > On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Lyude Paul
> > > > Sent: Saturday, December 7, 2019 3:57 AM
> > > > To: Lin
Yeah that's fine with me, I'll send out a revert for this in just a moment
On Fri, 2020-01-17 at 15:43 -0500, Sean Paul wrote:
> On Fri, Jan 17, 2020 at 3:27 PM Lyude Paul wrote:
> > On Fri, 2020-01-17 at 11:19 -0500, Sean Paul wrote:
> > > On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote:
> > >
On 2020-01-17 1:46 p.m., Christian König wrote:
Am 17.01.20 um 18:07 schrieb Felix Kuehling:
On 2020-01-17 3:17 a.m., Christian König wrote:
Am 17.01.20 um 03:01 schrieb Felix Kuehling:
On 2020-01-16 8:09, Christian König wrote:
Coreboot seems to have a problem correctly setting up access to
Rather than only enabling GWS support based on the hws_gws_support
modparm, also check whether the GPU's HWS firmware supports GWS.
Leave the old modparm in place in case users want to test GWS
on GPUs not yet in the support list.
Change-Id: Ife6833c2d571f5e7fe0726f9340649ce0ef10443
Signed-off-by:
Hi Dave, Daniel,
Same PR as yesterday, this just adds a DP MST fix for the DSC code and
a mutex init regression on top.
The following changes since commit 688486a49cf500a193dfe15be9eb5aa468887769:
Merge tag 'amd-drm-next-5.6-2020-01-10-dp-mst-dsc' of
git://people.freedesktop.org/~agd5f/linux
Rather than only enabling GWS support based on the hws_gws_support
modparm, also check whether the GPU's HWS firmware supports GWS.
Leave the old modparm in place in case users want to test GWS
on GPUs not yet in the support list.
v2: fix broken syntax from the first patch.
Change-Id: Ife6833c2d5
On Fri, Jan 17, 2020 at 12:48 PM Martin Bångens wrote:
>
> I still have problems with my video card. I don't think this is about
> throttling beaus I only see the problem with specific games. Like all games
> after 2010 and most games after 2005. I don't know what information to give
> you deve
On 2020-01-17 4:39 p.m., Joseph Greathouse wrote:
Rather than only enabling GWS support based on the hws_gws_support
modparm, also check whether the GPU's HWS firmware supports GWS.
Leave the old modparm in place in case users want to test GWS
on GPUs not yet in the support list.
v2: fix broken
Could it be something platform related? "Socket 2011 for 2nd
Generation Core™ i7 Processors " is probably not very well tested
these days. It should work of course.
Den fre 17 jan. 2020 kl 18:48 skrev Martin Bångens :
>
> I still have problems with my video card. I don't think this is about
> thr
I think so because Ubuntu worked but games lagged and wasn't playable I
could give pop os a go too
Den fre 17 jan. 2020 kl 23:00 skrev Ernst Sjöstrand :
> Could it be something platform related? "Socket 2011 for 2nd
> Generation Core™ i7 Processors " is probably not very well tested
> these days.
Pushed to drm-misc-fixes, thanks!
On Fri, 2020-01-17 at 14:03 +0800, Wayne Lin wrote:
> [Why]
> While handling LINK_ADDRESS reply, current code expects a peer device
> can handle sideband message once the peer device type is reported as
> DP_PEER_DEVICE_MST_BRANCHING. However, when the connected d
I'm working on the TLB flushing code and noticed a problem with this
commit. See inline ...
On 2019-11-21 10:47 a.m., Changfeng.Zhu wrote:
From: changzhu
It may lose gpuvm invalidate acknowldege state across power-gating off
cycle. To avoid this issue in gmc9/gmc10 invalidation, add semaphore
Use a more meaningful variable name for the invalidation request
that is distinct from the tmp variable that gets overwritten when
acquiring the invalidation semaphore.
Fixes: 00f607f38d82 ("drm/amdgpu: invalidate mmhub semaphore workaround in
gmc9/gmc10")
Signed-off-by: Felix Kuehling
---
driv
The flush_type was incorrectly hard-coded to 0 when calling falling back
to MMIO-based invalidation in flush_gpu_tlb_pasid.
Fixes: caa5cf78387c ("drm/amdgpu: export function to flush TLB via pasid")
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 4 ++--
drivers/gpu/dr
Using a heavy-weight TLB flush once is not sufficient. Concurrent
memory accesses in the same TLB cache line can re-populate TLB entries
from stale texture cache (TC) entries while the heavy-weight TLB
flush is in progress. To fix this race condition, perform another TLB
flush after the heavy-weigh
37 matches
Mail list logo
