On Fri, Jun 19, 2020 at 8:58 AM Jason Gunthorpe wrote:
>
> On Thu, Jun 18, 2020 at 05:00:51PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 17, 2020 at 12:28:35PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Jun 17, 2020 at 08:48:50AM +0200, Daniel Vetter wrote:
> > >
> > > > Now my understanding for
Quoting Daniel Stone (2020-06-11 10:01:46)
> Hi,
>
> On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote:
> > On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote:
> > > Introducing a global lockmap that cannot capture the rules correctly,
> >
> > Can you document the rules all drivers should be followi
[AMD Public Use]
Series is:
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Wenhui Sheng
Sent: Thursday, June 18, 2020 15:53
To: amd-gfx@lists.freedesktop.org
Cc: Sheng, Wenhui
Subject: [PATCH 2/2] drm/amdgpu: add fw release for sdma v5_0
sdm
On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson wrote:
>
> Quoting Daniel Stone (2020-06-11 10:01:46)
> > Hi,
> >
> > On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote:
> > > On Thu, 11 Jun 2020 at 18:01, Chris Wilson
> > > wrote:
> > > > Introducing a global lockmap that cannot capture the rules c
Quoting Daniel Vetter (2020-06-19 09:51:59)
> On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> wrote:
> > Forcing a generic primitive to always be part of the same global map is
> > horrible.
>
> And no concrete example or reason for why that's not possible.
> Because frankly it's not horrible,
On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-06-19 09:51:59)
> > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> > wrote:
> > > Forcing a generic primitive to always be part of the same global map is
> > > horrible.
> >
> > And no concrete example
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Quoting Daniel Vetter (2020-06-19 10:43:09)
> On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2020-06-19 09:51:59)
> > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson
> > > wrote:
> > > > Forcing a generic primitive to always be part of the same global map
On Fri, Jun 19, 2020 at 1:39 PM Jason Gunthorpe wrote:
>
> On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > > As I've understood GPU that means you need to show that the commands
> > > associated with the buffer have completed. This is all local stuff
> > > within the driver, rig
On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > As I've understood GPU that means you need to show that the commands
> > associated with the buffer have completed. This is all local stuff
> > within the driver, right? Why use fence (other than it already exists)
>
> Because that
> The function kobject_init_and_add alloc memory like:
> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> ->kmalloc_slab, in err branch this memory not free. If use
> kmemleak, this path maybe catched.
> These change
The function kobject_init_and_add alloc memory like:
kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
->kmalloc_slab, in err branch this memory not free. If use
kmemleak, this path maybe catched.
These changes are to add
On Fri, Jun 19, 2020 at 05:06:04PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 1:39 PM Jason Gunthorpe wrote:
> >
> > On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > > > As I've understood GPU that means you need to show that the commands
> > > > associated with the bu
On Thu, Jun 18, 2020 at 3:49 PM Qingqing Zhuo wrote:
>
> when compiled with allmodconfig option, there are error
> messages as below:
>
> ERROR: modpost:
> "mod_color_is_table_init"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> ERROR: modpost:
> "mod_color_get_table"
> [drivers/gpu/drm/amd
On Fri, Jun 19, 2020 at 5:15 PM Jason Gunthorpe wrote:
>
> On Fri, Jun 19, 2020 at 05:06:04PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 19, 2020 at 1:39 PM Jason Gunthorpe wrote:
> > >
> > > On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > > > > As I've understood GPU that mea
On 2020-06-19 11:27 a.m., Alex Deucher wrote:
On Thu, Jun 18, 2020 at 3:49 PM Qingqing Zhuo wrote:
when compiled with allmodconfig option, there are error
messages as below:
ERROR: modpost:
"mod_color_is_table_init"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost:
"mod_color_
On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> The madness is only that device B's mmu notifier might need to wait
> for fence_B so that the dma operation finishes. Which in turn has to
> wait for device A to finish first.
So, it sound, fundamentally you've got this graph of ope
On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>
> > The madness is only that device B's mmu notifier might need to wait
> > for fence_B so that the dma operation finishes. Which in turn has to
> > wait for device A
On Thu, Jun 11, 2020 at 07:35:35PM -0400, Felix Kuehling wrote:
> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> >>> I still have my doubts about allowing fence waiting from within shrinkers.
> >>> IMO ideally they should us
Currently, most users have no idea about the effects of failed DPM
initialization. So add it to the log message.
Signed-off-by: Paul Menzel
---
drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/d
Currently, besides there is no explicit message, that DPM is disabled.
The user would need to know, that the missing success line indicates
that.
[drm] amdgpu: dpm initialized
So, add an explicit message, and make it log level warning, as disabling
dpm is not the default, and device performan
On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> >
> > > The madness is only that device B's mmu notifier might need to wait
> > > for fence_B so th
---
Untested.
drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 58 ++--
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 82 ++---
2 files changed, 70 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
index 4b
On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote:
>
> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> >
> > > The madness is only that device B's mmu notifier might need to wait
> > > for fence_B so that the d
Am 2020-06-19 um 3:11 p.m. schrieb Alex Deucher:
> On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote:
>> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
>>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>>>
The madness is only that device B's mmu notifier
On Fri, Jun 19, 2020 at 03:30:32PM -0400, Felix Kuehling wrote:
>
> Am 2020-06-19 um 3:11 p.m. schrieb Alex Deucher:
> > On Fri, Jun 19, 2020 at 2:09 PM Jerome Glisse wrote:
> >> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> >>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Danie
Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
>> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
>>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
>>>
The madness is only that device B's mm
On Fri, Jun 19, 2020 at 03:30:32PM -0400, Felix Kuehling wrote:
> We have a potential problem with CPU updating page tables while the GPU
> is retrying on page table entries because 64 bit CPU transactions don't
> arrive in device memory atomically.
Except for 32 bit platforms atomicity is guarent
On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote:
> Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
> > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> >> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> >>> On Fri, Jun 19, 2020 at 06:19:41PM +02
Am 2020-06-19 um 3:55 p.m. schrieb Jason Gunthorpe:
> On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote:
>> Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
>>> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunth
On Fri, Jun 19, 2020 at 03:18:49PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> > On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> > > On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> > >
> > > > The madness is o
From: Bhawanpreet Lakha
[Why]
assr is content protection for eDP, in order to use it we need to call
psp ta (dtm)
[How]
We have a enable_assr callback, hook into this and call the correct psp
cmd id to enable assr.
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Hersen Wu
Acked-by: Rodrigo Siqu
From: Dmytro Laktyushkin
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Chris Park
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c
b/driver
From: Yi-Ling Chen
[why]
dc->hwss->edp_backlight_control is null, it would casue it only be off
main-link of eDP. It is not worng behavior for eDP power sequence off.
[how]
Must use hwseq->funcs.edp_backlight_control finction pointer for edp
backlight.
Signed-off-by: Yi-Ling Chen
Reviewed-by:
From: Mikita Lipski
[why]
The calculation of virtual channel payload would not take link settings
in account. As we calculate VCPI slots needed both PBN for stream and
also PBN per time slot. Before we would use generic PBN per time slot,
which would not change with link settings causing wrong P
From: Michael Strauss
[WHY]
Currently DC doesn't check requested pixel clock against an EDID
specified TMDS max clock if it exists, passing modes that should fail
[HOW]
Add max TMDS clk to edid caps and perform check during validation
Signed-off-by: Michael Strauss
Reviewed-by: Eric Yang
Acke
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
* DCN3 improvements
* Fw updates
* A series of improvements and fixes
Anthony Koo (4):
drm/amd/display: [FW Promotion] Release 1.0.16
drm/amd/display: [FW Promotion] Release 1.0.17
drm/amd/display: [FW Promoti
From: Nicholas Kazlauskas
[Why]
Side-by-side and Top-and-bottom stereo configurations fail DML mode
validation due to Viewport exceeded.
This is because we consider the planes as being pipe split in pipe
population so we end up doubling the viewport width, eg. from 4k to 8k.
[How]
These pipes t
From: Chris Park
[Why]
All YCbCr420 resolutions 5K and above have tiling and discoloration
issues. The issue can be remedied by forcing ODM combine from 5K to 8K.
10K resolution requires ODM 4:1. The mechanism of what the real problem
is, that is inherent in ODM combine programming, doesn't see
From: Derek Lai
[why]
If a typeC to HDMI dongle supports YCbCr420 pass through and VSC
colorimetry and pixel encoding formats in the Extended Receiver
Capability, we shall allow VSC SDP to be used.
[How]
The Extended Receiver Capability field shall check the
EXTENDED_RECEIVER_CAPABILITY_FIELD_PR
From: Wyatt Wood
[Why]
Hw lock manager adds the ability to lock pipe, cursor, and dig in fw.
[How]
Send hw lock command to fw to lock pipe, cursor, and dig.
Signed-off-by: Wyatt Wood
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 36 +
From: Jake Wang
[Why & How]
Need to check if local_sink is NULL before accessing.
Signed-off-by: Jake Wang
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/driv
From: Anthony Koo
Signed-off-by: Anthony Koo
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/d
From: Aric Cyr
Signed-off-by: Aric Cyr
Reviewed-by: Aric Cyr
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index a45b5ea98918..f9
From: Stylon Wang
[Why]
Connector property output_bpc is available on DP/eDP only. New IGT tests
would benifit if this property works on HDMI.
[How]
Enable this read-only property on all types of connectors.
Signed-off-by: Stylon Wang
Reviewed-by: Nicholas Kazlauskas
Acked-by: Rodrigo Siqueir
From: Brandon Syu
[Why]
There is using pixelclk AVFS for dppclk, that would cause issue.
[How]
To use dispclk AVFS for both dispclk and dppclk. There would choose
dppclk for request voltage when dispclk wouldn't be updated case. If
dispclk need to be updated, then it'll choose the bigger one f
From: Anthony Koo
Signed-off-by: Anthony Koo
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/d
From: Peikang Zhang
[Why]
We try to to change new_clocks->dppclk_khz to 10 when
new_clocks->dppclk_khz is 0
[How]
Don't change new_clocks->dppclk_khz value when new_clocks->dppclk_khz is
0
Signed-off-by: Peikang Zhang
Reviewed-by: Yongqiang Sun
Acked-by: Rodrigo Siqueira
---
drivers/gpu
From: Wenjing Liu
[why]
DP link layer CTS specs updated to change the test parameters in test
4.2.1.1.
Before it requires source to delay 400us on aux no reply.
With the specs updates Errata5, it requires source to delay 3.2ms
(based on LTTPR aux timeout)
This causes our test to fail after updati
From: Eric Yang
[Why]
If optimized init is done in FW. DCN init be skipped in driver. This
need to be communicated between driver and fw and maintain backwards
compatibility.
[How]
Use DMUB scratch 0 bit 2 to indicate optimized init done in fw and
use DMUB scatch 4 bit 0 to indicate drive suppor
From: Chris Park
[Why]
10K YCbCr420 does not need ODM 4:1, but it requires MPC 4 split
indicated on the flags.
[How]
Make pixel encoding and resolution size specific workaround to enable
ODM combine on YCbCr420 high resolution modes.
Signed-off-by: Chris Park
Reviewed-by: Charlene Liu
Acked-b
From: Aurabindo Pillai
[Why]
DC global validation can fail when userspace requests to draw large
plane without performing the clipping themselves.
This is observed in the IGT kms_plane panning tests for 4K displays
where they draw an 8K plane without any clipping while expecting only
the top 4K
From: Anthony Koo
[Header Changes]
- Add debug flag for psr to use hw locking mgr state machine
Signed-off-by: Anthony Koo
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
d
From: David Galiffi
[Why]
If the front porch of the two timings differ, then there may not be
enough time while both streams are in vertical blank to perform a memory
clock change. This can hang the system.
[How]
Check the each streams timing.v_front_porch when determining if the two
streams are
From: Dale Zhao
[WHY]
Check max_tmds_clk_mhz firstly will restrict pixel clock under HDMI
1.4, thus HDMI2.0 port can't correctly support 4K 60Hz.
[HOW]
Fine tune the logic to check max_forum_tmds_clk_mhz firstly.
Signed-off-by: Dale Zhao
Reviewed-by: Chris Park
Acked-by: Rodrigo Siqueira
---
From: Wenjing Liu
[why]
Two issues:
1. Add read only operation support for query ddc data over aux.
2. Fix a bug where if read size is multiple of 16,
mot of the last read transaction will not be set to 0.
Signed-off-by: Wenjing Liu
Reviewed-by: Jun Lei
Acked-by: Rodrigo Siqueira
---
.../gpu
From: Anthony Koo
[Header Changes]
- Update scratch information for boot status
Signed-off-by: Anthony Koo
Reviewed-by: Anthony Koo
Acked-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 45 ---
1 file changed, 39 insertions(+), 6 deletions(-)
diff --
From: Aric Cyr
Signed-off-by: Aric Cyr
Reviewed-by: Aric Cyr
Acked-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index ceba626bda2f..f7
From: Nicholas Kazlauskas
[Why]
DMCUB firmware version is now available from firmware metadata block.
We should be passing this into dmub_srv so we can know when to apply
firmware version specific functionality like using CW4 only instead
of the REGION4.
[How]
We don't have the helpers for DM t
From: Martin Leung
why:
seamless boots requires split of init_hw into hw and pipes to work. This
was implemented in dcn10_init_hw but did not apply yet to dcn30.
how:
Copy over dcn10_init_hw and adapt it to dcn30 using recent changes to
dcn3. Behavior will be different in init sequence.
Signed
From: Camille Cho
[Why]
dc_link_set_psr_allow_active() always returns true, even in the case
that PSR is not supported.
[How]
Hook up the return value of dc_link_set_psr_allow_active().
Signed-off-by: Camille Cho
Reviewed-by: Josip Pavic
Acked-by: Anthony Koo
Acked-by: Rodrigo Siqueira
---
From: Stylon Wang
[Why]
Regression was introduced where setting max bpc property has no effect
on the atomic check and final commit. It has the same effect as max bpc
being stuck at 8.
[How]
Correctly propagate max bpc with the new connector state.
Signed-off-by: Stylon Wang
Reviewed-by: Nicho
On Fri, Jun 19, 2020 at 04:55:38PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote:
> > Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
> > > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> > >> On Fri, Jun 19, 2020 at 02:23:08PM -
On Fri, Jun 19, 2020 at 10:10 PM Jerome Glisse wrote:
>
> On Fri, Jun 19, 2020 at 03:18:49PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> > > On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> > > > On Fri, Jun 19, 2020 at 06:19
On Fri, Jun 19, 2020 at 10:43:20PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 10:10 PM Jerome Glisse wrote:
> >
> > On Fri, Jun 19, 2020 at 03:18:49PM -0300, Jason Gunthorpe wrote:
> > > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> > > > On Fri, Jun 19, 2020 at 02:23
Hi Bernard,
I just applied a patch from another contributor for the kfd_topology
part of this. See
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=fc0fe8138309fee303bd12991f12b23f01bbf58c
Please rebase your patch on that. I believe that should only leave the
fixes in k
67 matches
Mail list logo