I demand that Christian König may or may not have written...
> Am 11.12.20 um 02:42 schrieb Darren Salt:
>> I demand that Christian König may or may not have written...
> [SNIP]
> Well I did wrote that :)
“did write”, surely…
>> I used dd:
>> # dd if=/sys/kernel/debug/dri/0/amdgpu_vram
I demand that Christian König may or may not have written...
> Am 11.12.20 um 01:55 schrieb Darren Salt:
[snip]
>> +rbar_size = pci_rebar_bytes_to_size(adev->gmc.real_vram_size);
>> +current_size = pci_rebar_get_current_size(adev->pdev, 0);
>> +
>> +/* Skip if the BIOS has already
On 2020-12-11 4:44 p.m., Luben Tuikov wrote:
> If however, you never decide to send it to the hardware and simply
> abandon it (in hopes that the DRM or the Application Client will
> reissue it), then you should send it back to DRM with status "COMPLETE".
Correction: "... decide to *not* send it
On 2020-12-10 4:46 a.m., Steven Price wrote:
> On 10/12/2020 02:14, Luben Tuikov wrote:
>> This patch does not change current behaviour.
>>
>> The driver's job timeout handler now returns
>> status indicating back to the DRM layer whether
>> the task (job) was successfully aborted or whether
>>
On 2020-12-10 4:41 a.m., Christian König wrote:
> Am 10.12.20 um 10:31 schrieb Lucas Stach:
>> Hi Luben,
>>
>> Am Mittwoch, den 09.12.2020, 21:14 -0500 schrieb Luben Tuikov:
>>> [SNIP]
>>> -static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
>>> +static enum drm_task_status
On 2020-12-10 4:31 a.m., Lucas Stach wrote:
> Hi Luben,
>
> Am Mittwoch, den 09.12.2020, 21:14 -0500 schrieb Luben Tuikov:
>> This patch does not change current behaviour.
>>
>> The driver's job timeout handler now returns
>> status indicating back to the DRM layer whether
>> the task (job) was
Kernel test robot throws below warning ->
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5349:5:
warning: no previous prototype for 'amdgpu_dm_crtc_atomic_set_property'
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5349:5:
warning: no previous
On Fri, Dec 11, 2020 at 1:49 PM Darren Salt wrote:
>
> I demand that Christian König may or may not have written...
>
> > Am 11.12.20 um 01:55 schrieb Darren Salt:
> [snip]
> >> +rbar_size = pci_rebar_bytes_to_size(adev->gmc.real_vram_size);
> >> +current_size =
On 11/12/20 9:50 pm, Kazlauskas, Nicholas wrote:
> On 2020-12-11 10:35 a.m., Shashank Sharma wrote:
>> On 11/12/20 8:19 pm, Kazlauskas, Nicholas wrote:
>>> On 2020-12-11 12:08 a.m., Shashank Sharma wrote:
On 10/12/20 11:20 pm, Aurabindo Pillai wrote:
> On Thu, 2020-12-10 at 18:29 +0530,
Hi,
patch in $Subject breaks booting on a laptop here, GPU details are
below. The machine stops booting right when it attempts to switch modes
during boot, to a higher mode than the default VGA one. Machine doesn't
ping and is otherwise unresponsive so that a hard reset is the only
thing that
Am 11.12.20 um 02:42 schrieb Darren Salt:
I demand that Christian König may or may not have written...
[SNIP]
Well I did wrote that :)
I used dd: # dd if=/sys/kernel/debug/dri/0/amdgpu_vram bs=1048576
count=1 skip=6127 | hexdump -C |tail
That won't work. amdgpu_vram uses a MMIO register
Am 11.12.20 um 01:55 schrieb Darren Salt:
This allows BAR0 resizing to be done for cards which don't advertise support
for a size large enough to cover the VRAM but which do advertise at least
one size larger than the default. For example, my RX 5600 XT, which
advertises 256MB, 512MB and 1GB.
On 2020-12-11 10:35 a.m., Shashank Sharma wrote:
On 11/12/20 8:19 pm, Kazlauskas, Nicholas wrote:
On 2020-12-11 12:08 a.m., Shashank Sharma wrote:
On 10/12/20 11:20 pm, Aurabindo Pillai wrote:
On Thu, 2020-12-10 at 18:29 +0530, Shashank Sharma wrote:
On 10/12/20 8:15 am, Aurabindo Pillai
On 11/12/20 8:19 pm, Kazlauskas, Nicholas wrote:
> On 2020-12-11 12:08 a.m., Shashank Sharma wrote:
>> On 10/12/20 11:20 pm, Aurabindo Pillai wrote:
>>> On Thu, 2020-12-10 at 18:29 +0530, Shashank Sharma wrote:
On 10/12/20 8:15 am, Aurabindo Pillai wrote:
> [Why]
> Inorder to enable
[AMD Public Use]
Instead of checking the global parameters everywhere, let's check the runtime
pm parameter and then set a local adev variable per device. That way we can
have a mix of devices that support different runtime pm modes in the same
system and everything works.
Alex
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Likun Gao
Sent: Friday, December 11, 2020 4:01 AM
To: amd-gfx@lists.freedesktop.org
Cc: Gao, Likun ; Feng, Kenneth ;
Zhang, Hawking
Subject: [V2]
On 2020-12-11 12:08 a.m., Shashank Sharma wrote:
On 10/12/20 11:20 pm, Aurabindo Pillai wrote:
On Thu, 2020-12-10 at 18:29 +0530, Shashank Sharma wrote:
On 10/12/20 8:15 am, Aurabindo Pillai wrote:
[Why]
Inorder to enable freesync video mode, driver adds extra
modes based on preferred modes
Am 11.12.20 um 14:58 schrieb Michel Dänzer:
On 2020-12-14 9:57 p.m., Christian König wrote:
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
I think the general idea we settled on is that we specify an earliest
display time for each
On 2020-12-14 9:57 p.m., Christian König wrote:
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
I think the general idea we settled on is that we specify an earliest
display time for each frame and give feedback to the application when a
On Mon, 14 Dec 2020 21:57:25 +0100
Christian König wrote:
> Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
> > On Fri, 11 Dec 2020 11:28:36 +0100
> > Christian König wrote:
> >
> >> Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
> >>> On Fri, 11 Dec 2020 09:56:07 +0530
> >>> Shashank Sharma
Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 09:56:07 +0530
Shashank Sharma wrote:
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
> Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
> > On Fri, 11 Dec 2020 09:56:07 +0530
> > Shashank Sharma wrote:
> >
> >> Hello Simon,
> >>
> >> Hope you are doing well,
> >>
> >> I was helping out Aurabindo and the team with the
Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
On Fri, 11 Dec 2020 09:56:07 +0530
Shashank Sharma wrote:
Hello Simon,
Hope you are doing well,
I was helping out Aurabindo and the team with the design, so I have
taken the liberty of adding some comments on behalf of the team,
Inline.
On
Hello Reza Amini,
The patch 9bc416266582: "drm/amd/display: Implement VSIF V3 extended
refresh rate feature" from Jul 9, 2020, leads to the following static
checker warning:
drivers/gpu/drm/amd/amdgpu/../display/modules/freesync/freesync.c:617
build_vrr_infopacket_data_v3()
On Fri, 11 Dec 2020 09:56:07 +0530
Shashank Sharma wrote:
> Hello Simon,
>
> Hope you are doing well,
>
> I was helping out Aurabindo and the team with the design, so I have
> taken the liberty of adding some comments on behalf of the team,
> Inline.
>
> On 11/12/20 3:31 am, Simon Ser wrote:
NAK, that is exactly what we are trying to avoid.
Am 11.12.20 um 01:55 schrieb Darren Salt:
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 9 +
3 files changed, 13 insertions(+)
Am 11.12.20 um 01:55 schrieb Darren Salt:
This is to assist driver modules which do BAR resizing.
Signed-off-by: Darren Salt
---
drivers/pci/pci.c | 2 ++
drivers/pci/pci.h | 2 --
include/linux/pci.h | 4
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git
From: Likun Gao
Skip vram related operation for bamaco rumtime suspend and resume as
vram is alive when BAMACO.
It can save about 32ms when suspend and about 15ms when resume.
Signed-off-by: Likun Gao
Change-Id: I6ad39765de5ed1aac2dc51e96ed7a21a727272cd
---
From: Likun Gao
S0ix only makes sense on APUs since they are part of the platform, so
only when the ASIC is APU should set amdgpu_acpi_is_s0ix_supported flag
to deal with the related situation.
Signed-off-by: Likun Gao
Change-Id: Ic89df206734fa7e6ce3e5a784171f149a07edc80
---
29 matches
Mail list logo
