On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote:
>
> Hi,
>
> > > Changing the order doesn't look hard. Patch attached (untested, have no
> > > test hardware). But maybe I missed some detail ...
> >
> > I came up with something very similar by splitting up nouveau_bo_new()
> > into allocation
fix other navi asic set peak performance level error.
because the navi10_ppt.c will handle navi12 14 asic,
it will use navi10 peak value to set other asic, it is not correct.
after patch:
only navi10 use custom peak value, other asic will used default value.
Signed-off-by: Kevin Wang
---
driver
On 8/20/19 4:57 PM, Nathan Chancellor wrote:
> When building arm32 allyesconfig:
>
> ld.lld: error: undefined symbol: __aeabi_uldivmod
referenced by dc_link.c
gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode) in archive
drivers/built-in.a
referenced by dc_link.c
g
On Tue, Aug 20, 2019 at 11:45:54AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 19 Aug 2019 18:34:41 -0700 Randy Dunlap wrote:
> >
> > On 8/19/19 2:18 AM, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20190816:
> > >
> >
> > on x86_64:
> >
> > ../drivers/gpu/drm/am
When building arm32 allyesconfig:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by dc_link.c
>>> gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode) in archive
>>> drivers/built-in.a
>>> referenced by dc_link.c
>>> gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode)
On 2019-08-20 5:02 p.m., Lyude Paul wrote:
> [Added Leo Li here, since they did the auxdev work that introduced these
> functions]
>
> Since it seems we'll actually be doing remote DPCD read/writes in DRM drivers
> and not just from auxdev, maybe we should combine drm_dp_dpcd_read() with
> drm_
This should definitely be implemented as an atomic helper in
drm_dp_mst_topology.c as well.
On Tue, 2019-08-20 at 15:12 -0400, David Francis wrote:
> Whenever a connector on an MST network is attached, detached, or
> undergoes a modeset, the DSC configs for each stream on that
> topology will be r
On Tue, 2019-08-20 at 15:11 -0400, David Francis wrote:
> This field on drm_dp_mst_branch was never filled
>
> Initialize it to zero when the list of ports is created.
> When a port is added to the list, increment num_ports
>
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/drm_dp_mst_top
[Added Leo Li here, since they did the auxdev work that introduced these
functions]
Since it seems we'll actually be doing remote DPCD read/writes in DRM drivers
and not just from auxdev, maybe we should combine drm_dp_dpcd_read() with
drm_dp_mst_dpcd_read() and do the same with the _write() varia
Some nitpicks below
On Tue, 2019-08-20 at 15:11 -0400, David Francis wrote:
> We were using drm helpers to convert a timing into its
> bandwidth, its bandwidth into pbn, and its pbn into timeslots
>
> These helpers
> -Did not take DSC timings into account
> -Used the link rate and lane count of t
Reviewed-by: Lyude Paul
On Tue, 2019-08-20 at 15:11 -0400, David Francis wrote:
> As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
> if FEC can be supported up to that point in the MST network.
>
> The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
> bottom-most bit (refer
Hi, I was looking through patchwork and just noticed this series. I've been
working on trying to rework a lot of the drm MST helpers (currently on hold
for a short bit while I fix some other unrelated issues at work...), and one
of the things we're currently missing with our helpers are helpers for
This reverts commit 55ad81f3510ec1a1c19e6a4d8a6319812d07d256.
optc dsc config was causing warnings due to missing register
definitions. With the registers restored, the function can
be re-enabled
The reverted commit also disabled sanity checks and dsc
power gating. The sanity check warnings are n
Rework the dm_helpers_write_dsc_enable callback to
handle the MST case
Depending on how DSC is done, the DP_DSC_ENABLE bit
needs to be set on a different point
For SST, use the link aux
For endpoint DSC over DP-to-DP peer devices,
use the output port
For peer device DSC over DP-to-DP peer devic
Whenever a connector on an MST network is attached, detached, or
undergoes a modeset, the DSC configs for each stream on that
topology will be recalculated. This can change their required
bandwidth, requiring a full reprogramming, as though a modeset
was performed, even if that stream did not chang
This field on drm_dp_mst_branch was never filled
Initialize it to zero when the list of ports is created.
When a port is added to the list, increment num_ports
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gp
To use these functions in drm driver directories, they must be
exported
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b40d975aec76..
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for FEC and DSC support
Sto
This reverts commit 55a6f5bbcf00a49565946c0a9b8c716313dc6c05.
This commit was accidentally promoted twice
Signed-off-by: David Francis
Reviewed-by: Roman Li
Reviewed-by: Harry Wentland
Reviewed-by: Nicholas Kazlauskas
---
.../drm/amd/display/dc/dcn20/dcn20_hwseq.c| 4 --
.../gpu/drm/amd
If there is limited link bandwidth on a MST network,
it must be divided fairly between the streams on that network
Implement an algorithm to determine the correct DSC config
for each stream
The algorithm:
This
[ ] ( )
represents the range of bandwidths possible for
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Signed-off-by: David Francis
Reviewed-by: Nicholas Kazlauskas
---
We were using drm helpers to convert a timing into its
bandwidth, its bandwidth into pbn, and its pbn into timeslots
These helpers
-Did not take DSC timings into account
-Used the link rate and lane count of the link's aux device,
which are not the same as the link's current cap
-Did not take FEC
This reverts commit 5f2fd347eeff7d4ce271920efd47baaa18fe968c.
Re-enable enc2_dp_set_dsc_config. This function caused warnings
due to missing register definitions. With the registers added,
this now works
Signed-off-by: David Francis
Reviewed-by: Roman Li
Reviewed-by: Harry Wentland
Reviewed-by
The first step in MST DSC is checking MST endpoints
to see how DSC can be enabled
Case 1: DP-to-DP peer device
if the branch immediately upstream has
- PDT = DP_PEER_DEVICE_DP_MST_BRANCHING (2)
- DPCD rev. >= DP 1.4
- Exactly one input and one output
- The output has PDT = DP_PEER_DEVICE_SST_S
In create_stream_for_sink, check for SST DP connectors
Parse DSC caps to DC format, then, if DSC is supported,
compute the config
DSC hardware will be programmed by dc_commit_state
Tested-by: Mikita Lipski
Signed-off-by: David Francis
Reviewed-by: Nicholas Kazlauskas
---
.../gpu/drm/amd/disp
This reverts commit 80e80ec817f161560b4159608fb41bd289abede3.
This commit fixed an issue with underscan commits not updating all
needed timing values, but through various refactors it is no longer
necessary. It causes corruption on odm combine by
overwriting the halved h_active in the stream timin
This patchset enables Display Stream Compression (DSC) on DP
connectors on Navi ASICs, both SST and DSC.
8k60 and 4k144 support requires ODM combine, an AMD internal
feature that may be a bit buggy right now.
Patches 1 through 5 enable DSC for SST. Most of the work was
already done in the Navi pr
Series is
Reviewed-by: David Francis
From: amd-gfx on behalf of Nicholas
Kazlauskas
Sent: August 20, 2019 1:59 PM
To: amd-gfx@lists.freedesktop.org
Cc: Li, Sun peng (Leo); Francis, David; Lakha, Bhawanpreet; Kazlauskas, Nicholas
Subject: [PATCH 4/4] drm
[Why]
We need to ensure that we're holding the lock on the CRTC when setting
the CRC source since we're modifying the CRTC state directly.
We also need to wait for any outstanding non-blocking commits to finish
so they aren't reading state that's potentially being modified -
non-blocking commits d
[Why]
The call to drm_crtc_vblank_get can fail if vblank is disabled and
we try to increment the reference.
Since drm_crtc_vblank_get internally drops the reference when it fails
it means the subsequent drm_crtc_vblank_put(...) when closing the file
drops a zero reference.
This was found via igt@
[Why]
This change is a refactor in preparation for adding locking and removing
the requirement for a stream state on the CRTC for enabling CRC capture
to fix igt@kms_plane_multiple@* warnings.
[How]
We can get the aux by finding the matching connector for the CRTC
with the assumption that we're no
[Why]
Calling amdgpu_dm_crtc_set_crc_source in amdgpu_dm directly has the
consequence of adding additional vblank references or starting DPRX
CRC capture more than once without calling stop first.
Vblank references for CRC capture should be managed entirely by opening
and closing the CRC file from
Hi Frank,
please separate that change in a single patch.
Adding all the SRIOV dependencies to the fb programming code is a clear
NAK from my side. We should rather adjust the agp_start and agp_end
addresses instead.
Regards,
Christian.
Am 20.08.19 um 08:17 schrieb Min, Frank:
> Hi Alex/Christ
On Fri, 9 Aug 2019 at 22:38, wrote:
>
> From: Dmytro Laktyushkin
>
> Currently every time DC wants to access firmware info we make a call
> into VBIOS. This makes no sense as there is nothing that can change
> runtime inside fw info and can cause issues when calling unstable
> bios during bringup
Can we hold on the code optimizations or code refactor until arcturus and
renior stablized? The current code is already a little in chaos. We should not
introduce more.
Regards,
Evan
发件人: amd-gfx 代表 Wang, Kevin(Yang)
发送时间: Tuesday, August 20, 2019 3:55:01 PM
Hi Evan,
thank you for explaining this background reason.
you want to support more hwmon sensor in smu driver.
but in this patch, I have a few different opinions
1. could you move smu11_thermal_policy from smu_11_0.h to smu_v11_0.c, i
think shouldn't define any data in header file.
2. +sta
On 8/19/19 2:18 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190816:
>
on i386:
ld: drivers/gpu/drm/amd/display/dc/core/dc_link.o: in function
`wait_for_alt_mode':
dc_link.c:(.text+0x1f38): undefined reference to `__udivdi3'
ld: dc_link.c:(.text+0x1f71): undefined reference to `_
On 8/19/19 2:18 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190816:
>
on x86_64:
../drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c: In function ‘amdgpu_exit’:
../drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:1471:2: error: implicit declaration
of function ‘mmu_notifier_synchronize’; did you m
1. add smu_map to replace old smu_11_0_cmn2aisc_mapping.
(next generation of smu ip also need this logic, eg: smu12 13 14...)
2. use smu_map_helper function to unified map code logic in smu
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c| 19
drivers/gpu/drm/am
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Kenneth Feng
Sent: Tuesday, August 20, 2019 3:17 PM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH v2] drm/amd/amdgpu: disable MMHUB PG for navi10
Disable MMHUB PG fo
Thanks Kenneth. The patch is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Kenneth Feng
Sent: 2019年8月20日 15:17
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH v2] drm/amd/amdgpu: disable MMHUB PG for navi10
Disable MMHUB
Disable MMHUB PG for navi10 according to the production requirement.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/amdgpu/nv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index d4a2012..46f402a 100644
--- a/drivers/gp
42 matches
Mail list logo
