Am 02.10.19 um 05:46 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those allocati
> ---
Why did you omit the patch change log at this place?
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 34 -
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -189,7 +189,7 @@ static int acp_hw_init(void *handle)
…
> + struct i2s_platform_data *i2s_pdata = NULL;
Even though 'smu8_smu' is declared, it is not used after below statement.
smu8_smu = hwmgr->smu_backend;
So 'unused variable' could be safely removed
to stop warning message as below:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu8_smumgr.c:180:22:
warning: variable ‘smu8_smu’ set b
On Tue, Oct 1, 2019 at 7:19 AM Koenig, Christian
wrote:
>
> Am 30.09.19 um 23:26 schrieb Navid Emamdoost:
> > In acp_hw_init there are some allocations that needs to be released in
> > case of failure:
> >
> > 1- adev->acp.acp_genpd should be released if any allocation attemp for
> > adev->acp.acp
In acp_hw_init there are some allocations that needs to be released in
case of failure:
1- adev->acp.acp_genpd should be released if any allocation attemp for
adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
2- all of those allocations should be released if
mfd_add_hotplug_devices or pm_g
Fix pinkish color issue around grey areas. This also happens
when not using any dongle so directly with a usb-c to Display
Port cable. Meaning there is something wrong when using pixel
encoding RGB with amd driver in the general case. In the meantime
just use the same pixel encoding as when using H
On 2019-10-01 5:57 p.m., Gustavo A. R. Silva wrote:
>
> On 10/1/19 16:46, Liu, Leo wrote:
>
> + ring->sched.ready = true;
This is redundant. all the sched->ready is initialized as true, please
refer to drm_sched_init()
>>> I see... so in the following commit 1b61de45dfaf
On 10/1/19 16:46, Liu, Leo wrote:
+ ring->sched.ready = true;
>>> This is redundant. all the sched->ready is initialized as true, please
>>> refer to drm_sched_init()
>>>
>> I see... so in the following commit 1b61de45dfaf ("drm/amdgpu: add initial
>> VCN2.0 support (v2)")
>> tha
amdgpu_ring_test_ring, so it will determine whether the ring is ready
Signed-off-by: Leo Liu
Cc: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 1 -
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 21 ++---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 18 ++
Signed-off-by: Leo Liu
Suggested-by: Gustavo A. R. Silva
Cc: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
index cc19363f..0d5c95d73b63 100644
-
We reset the GPU as part of our hibernation sequence so we need
to make sure we don't mark vram as lost in that case.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111879
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c| 6 --
drivers/gpu/drm/amd/amdgpu/soc15.c | 6 +++
On 2019-10-01 5:43 p.m., Gustavo A. R. Silva wrote:
> Hi,
>
> On 10/1/19 16:29, Liu, Leo wrote:
>> On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
>>> Notice that there is a *continue* statement in the middle of the
>>> for loop and that prevents the code below from ever being reached:
>>>
>>>
Hi,
On 10/1/19 16:29, Liu, Leo wrote:
>
> On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
>> Notice that there is a *continue* statement in the middle of the
>> for loop and that prevents the code below from ever being reached:
>>
>> r = amdgpu_ring_test_ring(ring);
>> if (r) {
>>
On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
> Notice that there is a *continue* statement in the middle of the
> for loop and that prevents the code below from ever being reached:
>
> r = amdgpu_ring_test_ring(ring);
> if (r) {
> ring->sched.ready = false;
>
On 2019-09-30 17:55, Zhao, Yong wrote:
> The code use hex define, so should the printing.
>
> Change-Id: Ia7cc7690553bb043915b3d8c0157216c64421a60
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 +++--
> 1 file changed, 3 insertion
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Liu, Shaoyun
Sent: Tuesday, October 1, 2019 4:03 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH] drm/amdgpu : enable msix for amdgpu driver
We might used out of the msi resources in s
We might used out of the msi resources in some cloud project
which have a lot gpu devices(including PF and VF), msix can
provide enough resources from system level view
Change-Id: I9f03762074ac416c07f27b8f00c052ca93c7d6cb
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 ++
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Zhao, Yong
Sent: Friday, September 27, 2019 11:40 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhao, Yong
Subject: [PATCH] drm/amdgpu: Export setup_vm_pt_regs() logic for mmhub 2.0
The KFD code will call this f
Would you please review this patch?
Thanks,
Navid.
On Mon, Sep 16, 2019 at 10:21 PM Navid Emamdoost
wrote:
>
> In dcn*_clock_source_create when dcn20_clk_src_construct fails allocated
> clk_src needs release.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/gpu/drm/amd/display/dc/dce100/dce
Notice that there is a *continue* statement in the middle of the
for loop and that prevents the code below from ever being reached:
r = amdgpu_ring_test_ring(ring);
if (r) {
ring->sched.ready = false;
goto done;
}
Fix this by removing the co
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x264
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x264
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x264
From: Hans de Goede
[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events
From: Hans de Goede
[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by: Fel
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x264
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x264
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by: Fel
From: Hans de Goede
[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by: Fel
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x264
From: David Francis
Rework the dm_helpers_write_dsc_enable callback to
handle the MST case.
Use the cached dsc_aux field.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 ++-
1 file changed, 18 insertions(+), 1 dele
From: Mikita Lipski
Since for DSC MST connector's PBN is claculated differently
due to compression, we have to recalculate both PBN and
VCPI slots for that connector.
This patch proposes to use similair logic as in
dm_encoder_helper_atomic_chek, but since we do not know which
connectors will hav
From: David Francis
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 tha
From: David Francis
Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.
This means that DRM drivers can make MST DPCD read/writes.
v2: Fix spacing
v3: Dump dpcd access on MST read/writes
Reviewed-by
From: David Francis
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
Reviewed-by: Nicholas Kazlauskas
Signed-off-by
From: David Francis
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate
From: Mikita Lipski
Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs. Add a new quirk to detect this case.
Reviewed-by: Wenjing Liu
Rev
From: David Francis
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 b
From: Mikita Lipski
- Adding encoder atomic check to find vcpi slots for a connector
- Using DRM helper functions to calculate PBN
- Adding connector atomic check to release vcpi slots if connector
loses CRTC
- Calculate PBN and VCPI slots only once during atomic
check and store them on amdgpu c
From: David Francis
Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.
As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual D
From: Mikita Lipski
This set of patches is a continuation of DSC enablement
patches for AMDGPU. This set enables DSC on MST. It also
contains implementation of both encoder and connector
atomic check routines.
First 12 patches have been introduced in multiple
iterations to the mailing list befor
From: David Francis
During MST mode enumeration, if a new dc_sink is created,
populate it with dsc caps as appropriate.
Use drm_dp_mst_dsc_aux_for_port to get the raw caps,
then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
.../
From: David Francis
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
From: David Francis
This field on drm_dp_mst_branch was never filled
It is initialized to zero when the port is kzallocced.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
v3: don't e
From: David Francis
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 FE
On Mon, Sep 30, 2019 at 8:57 AM Ayan Halder wrote:
>
> On Mon, Sep 30, 2019 at 09:51:35AM +, Brian Starkey wrote:
> > Hi,
> >
> > On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > >
In the development version of ubuntu, using a 5.3 kernel, running the
dolphin emulator appears to leak memory (there may be other apps that
trigger the same issue, but haven't run into them). The "used" memory
reported by top grows until the app exits, and does not get freed at that
time. This is
Hi.
On Thu, Aug 29, 2019 at 02:05:28AM -0400, Kenny Ho wrote:
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1256,6 +1257,12 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> [...]
> + move_delay /= 2000; /* check every half period in ms*/
> [...
Hi.
On Thu, Aug 29, 2019 at 02:05:19AM -0400, Kenny Ho wrote:
> +struct cgroup_subsys drm_cgrp_subsys = {
> + .css_alloc = drmcg_css_alloc,
> + .css_free = drmcg_css_free,
> + .early_init = false,
> + .legacy_cftypes = files,
Do you really want to expose the DRM con
On Tue, 01 Oct 2019, Eric Engestrom wrote:
> On Tuesday, 2019-10-01 14:03:55 +0300, Jani Nikula wrote:
>> On Thu, 26 Sep 2019, Eric Engestrom wrote:
>> > On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
>> >> Hi all, v2 of [1], a little refactoring around drm_debug access to
>> >> abstra
Hello.
On Thu, Aug 29, 2019 at 02:05:24AM -0400, Kenny Ho wrote:
> drm.buffer.default
> A read-only flat-keyed file which exists on the root cgroup.
> Each entry is keyed by the drm device's major:minor.
>
> Default limits on the total GEM buffer allocation in bytes.
What
On 19.09.2019 20:08, Lyude Paul wrote:
> This still needs to be moved into an atomic helper so it can be reused by
> other drivers
It would be a future to move the implementation to a contained atomic
helper.
> ...
> ...
>
> however, I've had this patch series on my mind for a while and someth
On Thu, 26 Sep 2019, Eric Engestrom wrote:
> On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
>> Hi all, v2 of [1], a little refactoring around drm_debug access to
>> abstract it better. There shouldn't be any functional changes.
>>
>> I'd appreciate acks for merging the lot via drm-misc
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
> @@ -184,12 +184,12 @@ static struct device *get_mfd_cell_dev(const char
> *device_name, int r)
…
> + struct i2s_platform_data *i2s_pdata = NULL;
…
I propose to reconsider this update suggestion.
> @@ -231,20 +231,21 @@ static int acp_hw_init
On Tue, Oct 1, 2019 at 3:41 AM Sjoerd Bergmans wrote:
>
> Hi,
>
> Quick question regarding an earlier announcement;
> https://lists.freedesktop.org/archives/amd-gfx/2019-May/034431.html
>
> I feel a lot of Linux users are still waiting for the specified driver to
> surface. Since you gave the or
Actually, we can probably drop that hunk because adev->mode_info.num_crtc
should be 0 for arcturus right?
Alex
From: amd-gfx on behalf of Deucher,
Alexander
Sent: Tuesday, October 1, 2019 9:28 AM
To: Zhang, Jack (Jian) ; amd-gfx@lists.freedesktop.org
Subject:
From: amd-gfx on behalf of Jack Zhang
Sent: Monday, September 30, 2019 1:00 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian)
Subject: [PATCH] drm/amd/amdgpu/sriov ip block setting of Arcturus
Add ip block setting for Arcturus SRIOV
1.PSP need to
On Sun, Sep 29, 2019 at 2:19 AM chen gong wrote:
>
> Find that ring sdma0 test failed if turn on SDMA powergating after do
> mode2 reset.
>
> Perhaps the mode2 reset does not reset the SDMA PG state, SDMA is
> already powered up so there is no need to ask the SMU to power it up
> again. So I skip
On Tuesday, 2019-10-01 14:03:55 +0300, Jani Nikula wrote:
> On Thu, 26 Sep 2019, Eric Engestrom wrote:
> > On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
> >> Hi all, v2 of [1], a little refactoring around drm_debug access to
> >> abstract it better. There shouldn't be any functional ch
Am 30.09.19 um 23:26 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those allocati
Hi,
Quick question regarding an earlier announcement;
https://lists.freedesktop.org/archives/amd-gfx/2019-May/034431.html
I feel a lot of Linux users are still waiting for the specified driver to
surface. Since you gave the original statement, might it be you are able to
offer any new insights or
63 matches
Mail list logo
