Am 16.05.19 um 04:29 schrieb Kenny Ho:
> [CAUTION: External Email]
>
> On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
>> On 5/9/2019 2:04 PM, Kenny Ho wrote:
>>> There are four control file types,
>>> stats (ro) - display current measured values for a resource
>>> max (rw) - limits for a reso
Am 16.05.19 um 07:11 schrieb Yintian Tao:
PSP fw primary buffer is not used under SRIOV
Therefore, we don't need to allocate memory for it.
Signed-off-by: Yintian Tao
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 22 +-
1 file changed, 13 insertio
Am 16.05.19 um 09:16 schrieb Koenig, Christian:
Am 16.05.19 um 04:29 schrieb Kenny Ho:
[CAUTION: External Email]
On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
On 5/9/2019 2:04 PM, Kenny Ho wrote:
There are four control file types,
stats (ro) - display current measured values for a reso
On 2019-05-10 1:17 p.m., Michel Dänzer wrote:
>
> drivers/gpu/drm//amd/amdgpu/df_v3_6.c: In function ‘df_v3_6_pmc_start’:
> drivers/gpu/drm//amd/amdgpu/df_v3_6.c:482:9: warning: ‘ret’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> return ret;
> ^~~
This warning
On Thu, May 16, 2019 at 11:43 AM Alex Deucher wrote:
> On Wed, May 15, 2019 at 8:33 PM Daniel Kasak
> wrote:
> >
> > On Mon, May 13, 2019 at 11:44 AM Daniel Kasak
> wrote:
> >>
> >> Hi all. I had version 2.2.0 of the ROCM stack running on a 5.0.x and
> 5.1.0 kernel. Things were going great with
PSP fw primary buffer is not used under SRIOV.
Therefore, we don't need to allocate memory for it.
v2: remove superfluous check for amdgpu_bo_free_kernel().
Signed-off-by: Yintian Tao
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 17 ++---
1 file changed, 10
For Vega10 SR-IOV, vram_width can't be read from ATOM as
RAVEN, and DF related registers is not readable, seems hardcord
is the only way to set the correct vram_width
Signed-off-by: Trigger Huang
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +++
1 file changed, 7
Under SRIOV, reading DF register has chance to lead to
AER error in host side, just skip reading it.
Signed-off-by: Monk Liu
Signed-off-by: Yintian Tao
---
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
Series is:
Reviewed-by: Alex Deucher
On Wed, May 15, 2019 at 4:24 PM Bhawanpreet Lakha
wrote:
>
> This fixes the warning below
>
> error: ‘ret’ may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> int xgmi_tx_link, ret;
> ^~~
> Signed-off-by: Bhawan
On Thu, May 16, 2019 at 09:25:31AM +0200, Christian König wrote:
> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
> > Am 16.05.19 um 04:29 schrieb Kenny Ho:
> > > [CAUTION: External Email]
> > >
> > > On Wed, May 15, 2019 at 5:26 PM Welty, Brian
> > > wrote:
> > > > On 5/9/2019 2:04 PM, Kenny H
On Thu, May 16, 2019 at 3:25 AM Christian König
wrote:
> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
> > Am 16.05.19 um 04:29 schrieb Kenny Ho:
> >> On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
> >>> On 5/9/2019 2:04 PM, Kenny Ho wrote:
> Each file is multi-lined with one entry/li
Am 16.05.19 um 14:28 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Thu, May 16, 2019 at 09:25:31AM +0200, Christian König wrote:
>> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
>>> Am 16.05.19 um 04:29 schrieb Kenny Ho:
[CAUTION: External Email]
On Wed, May 15, 2019 at
Hello,
I haven't gone through the patchset yet but some quick comments.
On Wed, May 15, 2019 at 10:29:21PM -0400, Kenny Ho wrote:
> Given this controller is specific to the drm kernel subsystem which
> uses minor to identify drm device, I don't see a need to complicate
> the interfaces more by ha
Am 16.05.19 um 16:03 schrieb Kenny Ho:
On Thu, May 16, 2019 at 3:25 AM Christian König
wrote:
Am 16.05.19 um 09:16 schrieb Koenig, Christian:
Am 16.05.19 um 04:29 schrieb Kenny Ho:
On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
On 5/9/2019 2:04 PM, Kenny Ho wrote:
Each file is multi-l
On Thu, May 16, 2019 at 10:12 AM Christian König
wrote:
> Am 16.05.19 um 16:03 schrieb Kenny Ho:
> > On Thu, May 16, 2019 at 3:25 AM Christian König
> > wrote:
> >> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
> >> We need something like the Linux sysfs location or similar to have a
> >> stabl
On Thu, May 16, 2019 at 10:10 AM Tejun Heo wrote:
> I haven't gone through the patchset yet but some quick comments.
>
> On Wed, May 15, 2019 at 10:29:21PM -0400, Kenny Ho wrote:
> > Given this controller is specific to the drm kernel subsystem which
> > uses minor to identify drm device, I don't
From: Ville Syrjälä
All available downstream ports - physical and logical - are exposed for
each MST device. They are listed in /dev/, following the same naming
scheme as SST devices by appending an incremental ID.
Although all downstream ports are exposed, only some will work as
expected. Consi
From: Leo Li
Placing the MST aux device as a child of the connector gives udev the
ability to access the connector device's attributes. This will come in
handy when writing udev rules to create more descriptive symlinks to the
MST aux devices.
Cc: Ville Syrjälä
Cc: Lyude Paul
Signed-off-by: Le
From: Leo Li
This series adds support for MST AUX devices.
A more descriptive 'mstpath' attribute is also added to MST connector
devices. In addition, the DP aux device is made to be a child of the
corresponding connector's device where possible (*). This allows udev
rules to provide descriptiv
From: Leo Li
Set the connector's kernel device as the parent for the aux kernel
device. This allows udev rules to access connector attributes when
creating symlinks to aux devices.
Cc: Ben Skeggs
Cc: Lyude Paul
Signed-off-by: Leo Li
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
1 f
From: Leo Li
Set the connector's kernel device as the parent for the aux kernel
device. This allows udev rules to access connector attributes when
creating symlinks to aux devices.
For example, the following udev rule:
SUBSYSTEM=="drm_dp_aux_dev", SUBSYSTEMS=="drm", ATTRS{edid}=="*",
SY
From: Leo Li
In preparation for adding aux devices for DP MST, make the IDR
non-cyclic. That way, hotplug cycling MST devices won't needlessly
increment the minor version index.
Signed-off-by: Leo Li
Reviewed-by: Lyude Paul
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_aux_dev.c | 3
From: Leo Li
This can be used to create more descriptive symlinks for MST aux
devices. Consider the following udev rule:
SUBSYSTEM=="drm_dp_aux_dev", SUBSYSTEMS=="drm", ATTRS{mstpath}=="?*",
SYMLINK+="drm_dp_aux/by-path/$attr{mstpath}"
The following symlinks will be created (depending o
From: Leo Li
Set the connector's kernel device as the parent for the aux kernel
device. This allows udev rules to access connector attributes when
creating symlinks to aux devices.
To do so, the connector needs to be registered beforehand. Therefore,
shift aux registration to be after connector
Dear Daniel,
On 05/16/2019 01:52 PM, Daniel Kasak wrote:
> On Thu, May 16, 2019 at 11:43 AM Alex Deucher wrote:
>
>> On Wed, May 15, 2019 at 8:33 PM Daniel Kasak
>> wrote:
>>>
>>> On Mon, May 13, 2019 at 11:44 AM Daniel Kasak
>> wrote:
Hi all. I had version 2.2.0 of the ROCM stack r
On 5/16/19 11:18 AM, sunpeng...@amd.com wrote:
>
> From: Leo Li
>
> Set the connector's kernel device as the parent for the aux kernel
> device. This allows udev rules to access connector attributes when
> creating symlinks to aux devices.
>
> For example, the following udev rule:
>
> SUBSYSTE
Hi Daniel,
On 2019-05-12 9:44 p.m., Daniel Kasak wrote:
> [CAUTION: External Email]
> Hi all. I had version 2.2.0 of the ROCM stack running on a 5.0.x and
> 5.1.0 kernel. Things were going great with various boinc GPU tasks.
> But there is a setiathome GPU task which reliably gives me a hard
>
Hi, could we (and for future versions of this series and others) get a respin
of this that's actually rebased against drm-tip? That is the defacto standard
branch to do development on, and otherwise anyone trying to test these patches
has to resolve merge conflicts (along with maintainers). The bra
On Wed, May 15, 2019 at 7:19 PM Alex Deucher wrote:
>
> On Wed, May 15, 2019 at 2:26 PM Micah Morton wrote:
> >
> > Hi folks,
> >
> > I'm interested in running a VM on a system with an integrated Stoney
> > [Radeon R2/R3/R4/R5 Graphics] card and passing through the graphics
> > card to the VM usi
Whoops-one more thing I forgot to mention. This is just personal preference
for me, but if you're ccing me on any of the patches in the series feel free
to just do it for all of them. Makes my inbox a little less confusing to look
at
On Thu, 2019-05-16 at 15:54 -0400, Lyude Paul wrote:
> Hi, could
On 2019-05-16 3:54 p.m., Lyude Paul wrote:
> [CAUTION: External Email]
>
> Hi, could we (and for future versions of this series and others) get a respin
> of this that's actually rebased against drm-tip? That is the defacto standard
> branch to do development on, and otherwise anyone trying to t
On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> Placing the MST aux device as a child of the connector gives udev the
> ability to access the connector device's attributes. This will come in
> handy when writing udev rules to create more descriptive symlinks to the
On Thu, May 16, 2019 at 4:07 PM Micah Morton wrote:
>
> On Wed, May 15, 2019 at 7:19 PM Alex Deucher wrote:
> >
> > On Wed, May 15, 2019 at 2:26 PM Micah Morton wrote:
> > >
> > > Hi folks,
> > >
> > > I'm interested in running a VM on a system with an integrated Stoney
> > > [Radeon R2/R3/R4/R5
Without casting, 64-bit division is used implicitly causing DEPMOD
failure when building 32-bit kernel.
Signed-off-by: Slava Abramov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/dri
aghsorry, but I need to take back my Reviewed-by. Noticed an issue when
reloading drm and i915. I'll explain it when I respond to patch 2/7 in a
moment
On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> Placing the MST aux device as a child of the connector give
So a couple of things:
On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
> From: Ville Syrjälä
>
> All available downstream ports - physical and logical - are exposed for
> each MST device. They are listed in /dev/, following the same naming
> scheme as SST devices by appending an inc
Reviewed-by: Lyude Paul
On Thu, 2019-05-16 at 11:18 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> Set the connector's kernel device as the parent for the aux kernel
> device. This allows udev rules to access connector attributes when
> creating symlinks to aux devices.
>
> Cc: Ben Skeggs
Ping...
Hi Christian and Alex
Can you help review this? Thanks in advance.
Best Regards
Yintian Tao
-Original Message-
From: amd-gfx On Behalf Of Yintian Tao
Sent: Thursday, May 16, 2019 8:11 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Monk ; Tao, Yintian
Subject: [PATCH] drm/amdg
Ping...
Hi Christian and Alex
Can you help review this? Thanks in advance.
Best Regards
Yintian Tao
-Original Message-
From: Yintian Tao
Sent: Thursday, May 16, 2019 8:03 PM
To: amd-gfx@lists.freedesktop.org
Cc: Tao, Yintian ; Huang, Trigger
Subject: [PATCH] drm/amdgpu: set correct
Hi Christian
I have modified it according to your suggestion. Can you help review this
again? Thanks in advance.
Best Regards
Yintian Tao
-Original Message-
From: Yintian Tao
Sent: Thursday, May 16, 2019 7:54 PM
To: amd-gfx@lists.freedesktop.org
Cc: Tao, Yintian ; Liu, Monk
Subject
gpu reset will run late_init and schedule the late_init_work. if we
keep triggering gpu reset in a short time, there are potenial races.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amd
otherwise screen corrupts during modprobe.
Change-Id: I73bcf3ab0c666077dfe85436a3457a0379382304
Signed-off-by: Flora Cui
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
in
The UVD/VCE bits are set wrongly. This causes the UVD/VCE clocks
are not brought back correctly on needed.
Change-Id: I6eda67ea3be45fd5f422cdb78356915bf06ff41e
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Friday, May 17, 2019 1:45 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: fix sw SMU wrong UVD/VCE powergate setting
[CAUTION: External Email]
The UVD/VCE bits
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Cui, Flora
Sent: Friday, May 17, 2019 11:48 AM
To: amd-gfx@lists.freedesktop.org
Cc: Cui, Flora
Subject: [PATCH] drm/amdgpu: keep stolen memory on picasso
[CAUTION: External Email]
otherwise screen corrupts during mo
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Pan, Xinhui
Sent: Friday, May 17, 2019 11:04 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Huang, JinHuiEric
Subject: [PATCH] drm/amdgpu: cancel late_init_work before gpu reset
[CAUTION: External Emai
Hi Yintian,
sorry I have not the slightest idea how this part of the hw works. Maybe
try to explain more what the DF register is actually doing in the commit
message. I suspect that it is only about detecting which VRAM connection
is used, but I'm not 100% sure.
Regards,
Christian.
Am 17.05.1
Looks good to me now, but I don't know the technical background why this
BO is not needed under SRIOV.
So this patch is Acked-by: Christian König .
Regards,
Christian.
Am 17.05.19 um 04:41 schrieb Tao, Yintian:
> Hi Christian
>
>
> I have modified it according to your suggestion. Can you help r
48 matches
Mail list logo
