Resend in case of missing.
Hi Alex,
I need your help to merge libdrm patches from my personal repository below to
drm master branch.
Thanks.
Regards,
Guchun
From: Chen, Guchun
Sent: Friday, August 30, 2019 2:19 PM
To: 'Michel Dänzer' ; 'Alex Deucher'
Cc: Zhou1, Tao ;
From: Quan, Evan
Sent: Wednesday, September 4, 2019 9:17 AM
To: Wang, Kevin(Yang) ; amd-gfx@lists.freedesktop.org
; Huang, Ray
Cc: Wang, Kevin(Yang)
Subject: RE: [PATCH] drm/amd/powerplay: replace smu->table_count with
SMU_TABLE_COUNT in smu
Please drop the
Please drop the table_count member from the smu_table structure as it's totally
unused.
With that fixed, the patch is reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of
> Wang, Kevin(Yang)
> Sent: 2019年9月3日 16:17
> To: amd-gfx@lists.freedesktop.org; Huang, Ray
>
On Wed, 4 Sep 2019 at 06:48, Lyude Paul wrote:
>
> Declare local pointer to the drm_dp_link_address_ack_reply struct
> instead of constantly dereferencing it through the union in
> txmsg->reply. Then, invert the order of conditionals so we don't have to
> do the bulk of the work inside them, and
On Wed, 4 Sep 2019 at 06:48, Lyude Paul wrote:
>
> And it's helper, we'll be using this in just a moment.
>
Reviewed-by: Dave Airlie
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Signed-off-by: Lyude Paul
> ---
>
Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc passing it
to user space
instead of unused DRM driver name descriptor.
Change-Id: I809f6d3e057111417efbe8fa7cab8f0113ba4b21
Signed-off-by: Sonny Jiang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
On Wed, 4 Sep 2019 at 06:48, Lyude Paul wrote:
>
> Noticed this while working on adding a drm_dp_decode_sideband_req().
> DP_POWER_DOWN_PHY/DP_POWER_UP_PHY both use the same struct, so we can
> just combine their cases.
both use the same struct as enum path resources?
Since otherwise the patch
Maybe it's not necessary to separate the mtype from the get_vm_pte
function , so we just need one asic specific functions (get_vm_pte) .
What make me confusing originally is the the logic to setup the PTE
flag. We first map the UAPI flags to HW specific PTE flag , save it
into
On 2019-09-03 5:09 a.m., Christian König wrote:
> This hopefully helps reduce the contention for page tables.
>
> v2: adjust maximum reported VRAM size as well
>
> Signed-off-by: Christian König
I'll need to do something similar (and also take the vram_pin_size into
account) in
Acked-by: Huang Rui
-Original Message-
From: Wang, Kevin(Yang)
Sent: Tuesday, September 3, 2019 4:17 AM
To: amd-gfx@lists.freedesktop.org; Huang, Ray
Cc: Wang, Kevin(Yang)
Subject: [PATCH] drm/amd/powerplay: replace smu->table_count with
SMU_TABLE_COUNT in smu
fix bellow patch
Currently we only print mstb/port pointer addresses in our malloc and
topology refcount functions using the hashed-by-default %p, but
unfortunately if you're trying to debug a use-after-free error caused by
a refcounting error then this really isn't terribly useful. On the other
hand though,
For very subtle mistakes with topology refs, it can be rather difficult
to trace them down with the debugging info that we already have. I had
one such issue recently while trying to implement suspend/resume
reprobing for MST, and ended up coming up with this.
Inspired by Chris Wilson's wakeref
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes
Currently, every single piece of code in amdgpu that loops through
connectors does it incorrectly and doesn't use the proper list iteration
helpers, drm_connector_list_iter_begin() and
drm_connector_list_iter_end(). Yeesh.
So, do that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry
Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
The names for these functions are rather confusing. drm_dp_add_port()
sounds like a function that would simply create a port and add it to a
topology, and do nothing more. Similarly, drm_dp_update_port() would be
assumed to be the function that should be used to update port
information after
This probably hasn't caused any problems up until now since it's
probably nearly impossible to encounter this in the wild, however if we
were to receive a connection status notification from the MST hub after
resume while we're in the middle of reprobing the link addresses for a
topology then
Declare local pointer to the drm_dp_link_address_ack_reply struct
instead of constantly dereferencing it through the union in
txmsg->reply. Then, invert the order of conditionals so we don't have to
do the bulk of the work inside them, and can wrap lines even less. Then
finally, rearrange variable
These are most certainly accessed from far more than the mgr work. In
fact, up_req_recv is -only- ever accessed from outside the mgr work.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
include/drm/drm_dp_mst_helper.h | 8
Once upon a time, hotplugging devices on MST branches actually worked in
DRM. Now, it only works in amdgpu (likely because of how it's hotplug
handlers are implemented). On both i915 and nouveau, hotplug
notifications from MST branches are noticed - but trying to respond to
them causes messaging
In order for suspend/resume reprobing to work, we need to be able to
perform sideband communications during suspend/resume, along with
runtime PM suspend/resume. In order to do so, we also need to make sure
that nouveau doesn't bother grabbing a runtime PM reference to do so,
since otherwise we'll
Yes-you read that right. Currently there is literally no locking in
place for any of the drm_dp_mst_port struct members that can be modified
in response to a link address response, or a connection status response.
Which literally means if we're unlucky enough to have any sort of
hotplugging event
Turns out we've been forgetting for a while now to actually destroy any
of the mutexes that we create in drm_dp_mst_topology_mgr. So, let's do
that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
Since we're going to be implementing suspend/resume reprobing very soon,
we need to make sure we are extra careful to ensure that our locking
actually protects the topology state where we expect it to. Turns out
this isn't the case with drm_dp_port_setup_pdt() and
drm_dp_port_teardown_pdt(), both
Use more pointers so we don't have to write out
txmsg->reply.u.path_resources each time. Also, fix line wrapping +
rearrange local variables.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
---
* Remove the big ugly have_eomt conditional
* Store >down_rep_recv.initial_hdr in a var to make line wrapping
easier
* Remove duplicate memset() calls
* Actually wrap lines
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
Noticed this while working on adding a drm_dp_decode_sideband_req().
DP_POWER_DOWN_PHY/DP_POWER_UP_PHY both use the same struct, so we can
just combine their cases.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
---
There's a couple of changes here, so to summarize:
* Remove the big ugly mgr->up_req_recv.have_eomt conditional to save on
indenting
* Store >up_req_recv.initial_hdr in a variable so we don't keep
going over 80 character long lines
* De-duplicate code for calling drm_dp_send_up_ack_reply()
Unfortunately the DP MST helpers do not have much in the way of
debugging utilities. So, let's add some!
This adds basic debugging output for down sideband requests that we send
from the driver, so that we can actually discern what's happening when
sideband requests timeout.
Since there wasn't
Yes, apparently we've been testing this for every single driver load for
quite a long time now. At least that means our PBN calculation is solid!
Anyway, introduce self tests for MST and move this into there.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by:
Which reduces indentation and makes this function more legible.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 90 +--
1 file changed, 45 insertions(+), 45
And it's helper, we'll be using this in just a moment.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
This will allow us to add some locking for port->* members, in
particular the PDT and ->connector, which can't be done from
drm_dp_destroy_port() since we don't know what locks the caller might be
holding.
Changes since v2:
* Clarify commit message
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
A simple convienence function that returns a drm_printer which prints
using pr_err()
Changes since v1:
* Make __drm_printfn_err() more consistent with DRM_ERROR() - danvet
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
This is the large series for adding MST suspend/resume reprobing that
I've been working on for quite a while now. In addition, I:
- Refactored and cleaned up any code I ended up digging through in the
process of understanding how some parts of these helpers worked.
- Added some debugging tools
Makes things easier to read.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 35 ++-
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git
This seems to be some leftover detritus from before the port/mstb kref
cleanup and doesn't do anything anymore, so get rid of it.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c
When reprobing an MST topology during resume, we have to account for the
fact that while we were suspended it's possible that mstbs may have been
removed from any ports in the topology. Since iterating downwards in the
topology requires that we hold >lock, destroying MSTBs from this
context would
On Tue, Sep 3, 2019 at 4:12 PM Daniel Vetter wrote:
> On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
> > On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
> > > Iterating over minors for cgroups sounds very, very wrong. Why do we care
> > > whether a buffer was allocated through kms dumb vs
On 2019-09-02 6:52 a.m., Christian König wrote:
> Make VM updates depend on the moving fence instead of the exclusive one.
In effect, this makes the page table update depend on the last move of
the BO, rather than the last change of the buffer contents. Makes sense.
Reviewed-by: Felix Kuehling
On 2019-09-02 10:57 a.m., Christian König wrote:
> Move the ASIC specific code into a new callback function.
NAK. I believe the BUG_ONs you're adding will trigger with ROCm on
Hawaii and Kaveri. See inline ...
ROCm user mode doesn't care that the page table doesn't have an
executable bit on
On Tue, Sep 3, 2019 at 8:07 PM Mikhail Gavrilov
wrote:
>
> On Tue, 3 Sep 2019 at 13:21, Hillf Danton wrote:
> >
> > Describe the problems you are experiencing please.
> > Say is the screen locked up? Machine lockedup?
> > Anything unnormal after you see the warning?
> >
>
> According to my
On Tue, Sep 3, 2019 at 10:01 PM Sasha Levin wrote:
>
> On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote:
> >On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
> >> On 2019-09-03 6:23 p.m., Sasha Levin wrote:
> >> > From: Yu Zhao
> >> >
> >> > [ Upstream commit
On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
>
> On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
> >
> > On Thu, Aug 29, 2019 at 02:05:18AM -0400, Kenny Ho wrote:
> > > To allow other subsystems to iterate through all stored DRM minors and
> > > act upon them.
> > >
> > > Also exposes
On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote:
On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
On 2019-09-03 6:23 p.m., Sasha Levin wrote:
> From: Yu Zhao
>
> [ Upstream commit 89f23b6efef554766177bf51aa754bce14c3e7da ]
Hold your horses!
This commit and
On Tue, Sep 3, 2019 at 8:50 PM Tejun Heo wrote:
>
> Hello, Daniel.
>
> On Tue, Sep 03, 2019 at 09:55:50AM +0200, Daniel Vetter wrote:
> > > * While breaking up and applying control to different types of
> > > internal objects may seem attractive to folks who work day in and
> > > day out with
On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
>
> On Thu, Aug 29, 2019 at 02:05:18AM -0400, Kenny Ho wrote:
> > To allow other subsystems to iterate through all stored DRM minors and
> > act upon them.
> >
> > Also exposes drm_minor_acquire and drm_minor_release for other subsystem
> > to
On Tue, Sep 3, 2019 at 5:20 AM Daniel Vetter wrote:
>
> On Tue, Sep 3, 2019 at 10:24 AM Koenig, Christian
> wrote:
> >
> > Am 03.09.19 um 10:02 schrieb Daniel Vetter:
> > > On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
> > >> With this RFC v4, I am hoping to have some consensus on a
Hi Tejun,
Thanks for looking into this. I can definitely help where I can and I
am sure other experts will jump in if I start misrepresenting the
reality :) (as Daniel already have done.)
Regarding your points, my understanding is that there isn't really a
TTM vs GEM situation anymore (there is
Series is Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Andrey
Grodzovsky
Sent: 2019年9月4日 0:44
To: amd-gfx@lists.freedesktop.org
Cc: alexdeuc...@gmail.com; ckoenig.leichtzumer...@gmail.com; Zhou1, Tao
; Grodzovsky, Andrey ; Zhang,
Hawking
Hello, Daniel.
On Tue, Sep 03, 2019 at 09:55:50AM +0200, Daniel Vetter wrote:
> > * While breaking up and applying control to different types of
> > internal objects may seem attractive to folks who work day in and
> > day out with the subsystem, they aren't all that useful to users and
> >
On Tue, 3 Sep 2019 at 13:21, Hillf Danton wrote:
>
> Describe the problems you are experiencing please.
> Say is the screen locked up? Machine lockedup?
> Anything unnormal after you see the warning?
>
According to my observations, all "gnome shell stuck warning" happened
when me not sitting on
On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote:
> On 2019-09-03 6:23 p.m., Sasha Levin wrote:
> > From: Yu Zhao
> >
> > [ Upstream commit 89f23b6efef554766177bf51aa754bce14c3e7da ]
>
> Hold your horses!
>
> This commit and c4a32b266da7bb702e60381ca0c35eaddbc89a6c had to be
>
Issue 1:
In XGMI case amdgpu_device_lock_adev for other devices in hive
was called to late, after access to their repsective schedulers.
So relocate the lock to the begining of accessing the other devs.
Issue 2:
Using amdgpu_device_ip_need_full_reset to switch the device list from
all devices in
Problem:
Under certain conditions, when some IP bocks take a RAS error,
we can get into a situation where a GPU reset is not possible
due to issues in RAS in SMU/PSP.
Temporary fix until proper solution in PSP/SMU is ready:
When uncorrectable error happens the DF will unconditionally
broadcast
In case of RAS error allow user configure auto system
reboot through ras_ctrl.
This is also part of the temproray work around for the RAS
hang problem.
v4: Use latest kernel API for disk sync.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 ++
On 2019-09-03 6:23 p.m., Sasha Levin wrote:
> From: Yu Zhao
>
> [ Upstream commit 89f23b6efef554766177bf51aa754bce14c3e7da ]
Hold your horses!
This commit and c4a32b266da7bb702e60381ca0c35eaddbc89a6c had to be
reverted, as they caused regressions. See commits
From: Shirish S
[ Upstream commit 517b91f4cde3043d77b2178548473e8545ef07cb ]
[What]
readptr read always returns zero, since most likely
these blocks are either power or clock gated.
[How]
fetch rptr after amdgpu_ring_alloc() which informs
the power management code that the block is about to be
From: Kent Russell
[ Upstream commit 0a5a9c276c335870a1cecc4f02b76d6d6f663c8b ]
This was added to amdgpu but was missed in amdkfd
Signed-off-by: Kent Russell
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.rg
Signed-off-by: Sasha Levin
---
From: Louis Li
[ Upstream commit ce0e22f5d886d1b56c7ab4347c45b9ac5fcc058d ]
[What]
vce ring test fails consistently during resume in s3 cycle, due to
mismatch read & write pointers.
On debug/analysis its found that rptr to be compared is not being
correctly updated/read, which leads to this
From: Yu Zhao
[ Upstream commit c4a32b266da7bb702e60381ca0c35eaddbc89a6c ]
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
otherwise it could be
From: Lyude Paul
[ Upstream commit 04ac4b0ed412f65230b456fcd9aa07e13befff89 ]
Path property is used for userspace to know what MST connector goes to what
actual DRM DisplayPort connector, the tiling property is for tiling
configurations. Not sure what else there is to figure out.
From: David Francis
[ Upstream commit f191415b24a3ad3fa22088af7cd7fc328a2f469f ]
In a refactor, the watermark clock inputs to
powerplay from DC were changed from units of 10kHz to
kHz clocks.
One division by 100 was not converted into a division
by 1000.
Signed-off-by: David Francis
From: Rex Zhu
[ Upstream commit 4d454e9ffdb1ef5a51ebc147b5389c96048db683 ]
the clk value should be tranferred to MHz first and
then transfer to uint16. otherwise, the clock value
will be truncated.
Reviewed-by: Alex Deucher
Reported-by: Hersen Wu
Signed-off-by: Rex Zhu
Signed-off-by: Alex
From: Yu Zhao
[ Upstream commit 89f23b6efef554766177bf51aa754bce14c3e7da ]
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out
From: Feifei Xu
[ Upstream commit c55045adf7210d246a016c961916f078ed31a951 ]
Add mmDB_DEBUG3 settings.
Signed-off-by: Feifei Xu
Reviewed-by: Evan Quan
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 +
1 file
From: Feifei Xu
[ Upstream commit 54d682d9a5b357eb711994fa94ef1bc44d7ce9d9 ]
Update the goldensettings for vega20.
Signed-off-by: Feifei Xu
Signed-off-by: Evan Quan
Reviewed-by: Hawking Zhang
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
Reviewed-by: Oak Zeng
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Kuehling,
Felix
Sent: Friday, August 30, 2019 1:15 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 2/2] drm/amdgpu: Disable page faults while reading user wptrs
These wptrs must be pinned and GPU
On 9/3/19 3:17 AM, Stephen Rothwell wrote:
> Hi all,
>
> News: I will only be doing 1 more release before I leave for Kernel
> Summit (there may be some reports on Thursday, but I doubt I will have
> time to finish the full release) and then no more until Sept 30.
>
> Changes since 20190902:
>
Reviewed-by: Jonathan Kim
-Original Message-
From: amd-gfx On Behalf Of Jack Zhang
Sent: Tuesday, September 3, 2019 5:54 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Jack (Jian)
Subject: [PATCH] drm/amd/amdgpu: add sw_fini interface for df_funcs
[CAUTION: External Email]
add
This is nice clean up. Acked-by: Oak Zeng
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Monday, September 2, 2019 10:58 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 1/2] drm/amdgpu: cleanup mtype mapping
Unify how we map the UAPI flags to
This is just a GPU lock, please open up a bug report on freedesktop.org and
attach the full dmesg and which version of Mesa you are using.
Regards,
Christian.
Am 03.09.19 um 15:16 schrieb 7879:
Yes, with dmesg|grep drm , I get following.
348571.880718] [drm:amdgpu_job_timedout [amdgpu]]
Well that looks like the hardware got stuck.
Do you get something in the locks about a timeout on the SDMA ring?
Regards,
Christian.
Am 03.09.19 um 14:50 schrieb 7879:
Hi Christian,
Sometimes the thread blocked disk sleeping in call to amdgpu_sa_bo_new.
following is the stack
Reviewed-by: Chunming Zhou for series.
-David
在 2019/9/3 17:09, Christian König 写道:
> Trying to evict things from the current working set doesn't work that
> well anymore because of per VM BOs.
>
> Rely on reserving VRAM for page tables to avoid contention.
>
> Signed-off-by: Christian König
>
add sw_fini interface of df_funcs.
This interface will remove sysfs file of df_cntr_avail
function.
The old behavior only create sysfs of df_cntr_avail
in sw_init, but never remove it for lack of sw_fini
interface. With this,driver will report create
sysfs fail when it's loaded for the second
On Tue, Sep 3, 2019 at 10:24 AM Koenig, Christian
wrote:
>
> Am 03.09.19 um 10:02 schrieb Daniel Vetter:
> > On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
> >> This is a follow up to the RFC I made previously to introduce a cgroup
> >> controller for the GPU/DRM subsystem [v1,v2,v3].
Trying to evict things from the current working set doesn't work that
well anymore because of per VM BOs.
Rely on reserving VRAM for page tables to avoid contention.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 71
This hopefully helps reduce the contention for page tables.
v2: adjust maximum reported VRAM size as well
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 18 --
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 +++
Make VM updates depend on the moving fence instead of the exclusive one.
Makes it less likely to actually have a dependency.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Am 03.09.19 um 10:41 schrieb Zhou1, Tao:
change r type from bool to int, suitable for both bool and int return
value
Signed-off-by: Tao Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Oh, good point! That is probably good idea.
Christian.
Am 03.09.19 um 08:52 schrieb Zhou, David(ChunMing):
Do you need update the vram size reported to UMD ?
-David
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Monday, September 2, 2019 6:52 PM
To:
change r type from bool to int, suitable for both bool and int return
value
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index
Am 03.09.19 um 10:02 schrieb Daniel Vetter:
> On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
>> This is a follow up to the RFC I made previously to introduce a cgroup
>> controller for the GPU/DRM subsystem [v1,v2,v3]. The goal is to be able to
>> provide resource management to GPU
Hi Yanhua,
please update your kernel first, cause that looks like a known issue
which was recently fixed by patch "drm/scheduler: use job count instead
of peek".
Probably best to try the latest bleeding edge kernel and if that doesn't
help please open up a bug report on
fix bellow patch issue:
drm/amd/powerplay: introduce smu table id type to handle the smu table
for each asic
"This patch introduces new smu table type, it's to handle the
different smu table
defines for each asic with the same smu ip."
before:
use smu->table_count to represent the actual
On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
> This is a follow up to the RFC I made previously to introduce a cgroup
> controller for the GPU/DRM subsystem [v1,v2,v3]. The goal is to be able to
> provide resource management to GPU resources using things like container.
>
> With
On Thu, Aug 29, 2019 at 02:05:18AM -0400, Kenny Ho wrote:
> To allow other subsystems to iterate through all stored DRM minors and
> act upon them.
>
> Also exposes drm_minor_acquire and drm_minor_release for other subsystem
> to handle drm_minor. DRM cgroup controller is the initial consumer of
On Fri, Aug 30, 2019 at 09:28:57PM -0700, Tejun Heo wrote:
> Hello,
>
> I just glanced through the interface and don't have enough context to
> give any kind of detailed review yet. I'll try to read up and
> understand more and would greatly appreciate if you can give me some
> pointers to read
On Mon, 2 Sep 2019 14:46:51 +0300, Ville Syrjälä wrote:
> On Fri, Aug 30, 2019 at 06:16:52PM +0200, Jean Delvare wrote:
> > It is fine for displays without audio functionality to not implement
> > CEA extension in their EDID. Do not return an error in that case,
> > instead return 0 as if there
Hi, Sirs:
I have a wx5100 amdgpu card, It randomly come into failure. sometimes,
it will cause processes into uninterruptible wait state.
cps-new-ondemand-0587:~ # ps aux|grep -w D
root 11268 0.0 0.0 260628 3516 ?Ssl 8??26 0:00
/usr/sbin/gssproxy -D
root 136482
I think ecc_irq and process_ras_data_cb functions could be also moved to
generic module files, but we can do it in new patches.
Another issue is amdgpu init will fail if vbios enables ras but psp ras ta is
not ready on Arcturus. If vbios and psp ta for ras will be released at the same
time,
Do you need update the vram size reported to UMD ?
-David
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Monday, September 2, 2019 6:52 PM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 2/3] drm/amdgpu: reserve at least 4MB of VRAM for page tables
This
On Fri, 30 Aug 2019 at 08:30, Hillf Danton wrote:
>
> Add a warning to show if it makes sense in field: neither regression nor
> problem will have been observed with the warning printed.
>
I caught the problem.
[21793.094289] [ cut here ]
[21793.094296] gnome shell stuck
On Sat, 31 Aug 2019 at 07:27, Alex Deucher wrote:
>
> Hi Dave, Daniel,
>
> Mostly bug fixes. The big addition is display support for renoir
> which is new for 5.4. I realize it's a bit late to add it but the
> rest of the code for renoir is already in so it would be nice to
> get the display
debugfs_remove and kfree has taken the null check in account.
hence it is unnecessary to check it. Just remove the condition.
No functional change.
Signed-off-by: zhong jiang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
95 matches
Mail list logo
