Am 18.02.20 um 07:12 schrieb Huang Rui:
While the current amdgpu doesn't support TMZ, it will return the error if user
mode would like to allocate secure buffer.
Fixes: 17d907c drm/amdgpu: implement TMZ accessor (v3)
Signed-off-by: Huang Rui
Reviewed-by: Christian König
---
On Tue, Feb 18, 2020 at 05:15:33PM +0800, Koenig, Christian wrote:
> Am 18.02.20 um 09:55 schrieb Huang Rui:
> > On Tue, Feb 18, 2020 at 04:50:01PM +0800, Koenig, Christian wrote:
> >> Am 18.02.20 um 09:30 schrieb Huang Rui:
> >>> While the current amdgpu doesn't support TMZ, it will return the
Am 18.02.20 um 11:39 schrieb Huang Rui:
While the current amdgpu doesn't support TMZ, it will return the error if user
mode would like to allocate secure buffer.
Fixes: 17d907c drm/amdgpu: implement TMZ accessor (v3)
v2: we didn't need this checking anymore.
v3: only print message once time.
Am 18.02.20 um 09:30 schrieb Huang Rui:
While the current amdgpu doesn't support TMZ, it will return the error if user
mode would like to allocate secure buffer.
Fixes: 17d907c drm/amdgpu: implement TMZ accessor (v3)
v2: we didn't need this checking anymore.
You misunderstood me.
Am 18.02.20 um 09:55 schrieb Huang Rui:
On Tue, Feb 18, 2020 at 04:50:01PM +0800, Koenig, Christian wrote:
Am 18.02.20 um 09:30 schrieb Huang Rui:
While the current amdgpu doesn't support TMZ, it will return the error if user
mode would like to allocate secure buffer.
Fixes: 17d907c
On Tue, Feb 18, 2020 at 04:50:01PM +0800, Koenig, Christian wrote:
> Am 18.02.20 um 09:30 schrieb Huang Rui:
> > While the current amdgpu doesn't support TMZ, it will return the error if
> > user
> > mode would like to allocate secure buffer.
> >
> > Fixes: 17d907c drm/amdgpu: implement TMZ
On 2/18/20 9:55 AM, Huang Rui wrote:
On Tue, Feb 18, 2020 at 04:50:01PM +0800, Koenig, Christian wrote:
Am 18.02.20 um 09:30 schrieb Huang Rui:
While the current amdgpu doesn't support TMZ, it will return the error if user
mode would like to allocate secure buffer.
Fixes: 17d907c
Am 18.02.20 um 04:36 schrieb xinhui pan:
No need to trigger eviction as the memory mapping will not be used
anymore.
All pt/pd bos share same resv, hence the same shared eviction fence.
Everytime page table is freed, the fence will be signled and that cuases
kfd unexcepted evictions.
On Tue, Feb 18, 2020 at 05:35:35PM +0800, Huang Rui wrote:
> On Tue, Feb 18, 2020 at 05:15:33PM +0800, Koenig, Christian wrote:
> > Am 18.02.20 um 09:55 schrieb Huang Rui:
> > > On Tue, Feb 18, 2020 at 04:50:01PM +0800, Koenig, Christian wrote:
> > >> Am 18.02.20 um 09:30 schrieb Huang Rui:
> >
Am 18.02.20 um 10:44 schrieb Huang Rui:
On Tue, Feb 18, 2020 at 05:35:35PM +0800, Huang Rui wrote:
On Tue, Feb 18, 2020 at 05:15:33PM +0800, Koenig, Christian wrote:
Am 18.02.20 um 09:55 schrieb Huang Rui:
On Tue, Feb 18, 2020 at 04:50:01PM +0800, Koenig, Christian wrote:
Am 18.02.20 um
While the current amdgpu doesn't support TMZ, it will return the error if user
mode would like to allocate secure buffer.
Fixes: 17d907c drm/amdgpu: implement TMZ accessor (v3)
v2: we didn't need this checking anymore.
v3: only print message once time.
Signed-off-by: Huang Rui
---
On Tue, Feb 18, 2020 at 04:04:15PM +0800, Koenig, Christian wrote:
> Am 18.02.20 um 07:12 schrieb Huang Rui:
> > While the current amdgpu doesn't support TMZ, it will return the error if
> > user
> > mode would like to allocate secure buffer.
> >
> > Fixes: 17d907c drm/amdgpu: implement TMZ
On 2/18/20 11:39 AM, Huang Rui wrote:
While the current amdgpu doesn't support TMZ, it will return the error if user
mode would like to allocate secure buffer.
Fixes: 17d907c drm/amdgpu: implement TMZ accessor (v3)
v2: we didn't need this checking anymore.
v3: only print message once time.
While the current amdgpu doesn't support TMZ, it will return the error if user
mode would like to allocate secure buffer.
Fixes: 17d907c drm/amdgpu: implement TMZ accessor (v3)
v2: we didn't need this checking anymore.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5
Am 18.02.20 um 19:28 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 19:23 schrieb Christian König:
Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am
On Tue, Feb 18, 2020 at 07:37:44PM +0100, Christian König wrote:
> Am 18.02.20 um 19:28 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 18.02.20 um 19:23 schrieb Christian König:
> > > Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
> > > > Hi
> > > >
> > > > Am 18.02.20 um 18:13 schrieb Nirmoy:
>
Hi Yusuf,
Is that means driver can do its job without powerplay support ?
No, the driver tries to bind to the device but fails to load correctly.
You won't get any functionality from this.
If so, how does userspace programs like Xorg or as you mentioned Vesa
can interact with driver.
No,
On 2020-02-17 10:08 a.m., Christian König wrote:
> Am 17.02.20 um 15:44 schrieb Alex Deucher:
>> On Fri, Feb 14, 2020 at 7:17 PM Luben Tuikov wrote:
>>> Add a AMDGPU_GEM_CREATE_MASK and use it to check
>>> for valid/invalid GEM create flags coming in from
>>> userspace.
>>>
>>> Fix a bug in
Hello Christian,
Even if powerplay fails, gpu driver seems still working according to output
of "lsmod' command. I can see amdgpu there. Is that means driver can do its
job without powerplay support ?
If so, how does userspace programs like Xorg or as you mentioned Vesa can
interact with driver.
On 2020-02-17 9:44 a.m., Alex Deucher wrote:
> On Fri, Feb 14, 2020 at 7:17 PM Luben Tuikov wrote:
>>
>> Add a AMDGPU_GEM_CREATE_MASK and use it to check
>> for valid/invalid GEM create flags coming in from
>> userspace.
>>
>> Fix a bug in checking whether TMZ is supported at
>> GEM create time.
On 2020-02-18 3:27 a.m., Huang Rui wrote:
> On Tue, Feb 18, 2020 at 04:04:15PM +0800, Koenig, Christian wrote:
>> Am 18.02.20 um 07:12 schrieb Huang Rui:
>>> While the current amdgpu doesn't support TMZ, it will return the error if
>>> user
>>> mode would like to allocate secure buffer.
>>>
>>>
On Tue, Feb 18, 2020 at 4:36 PM Luben Tuikov wrote:
>
> On 2020-02-17 9:44 a.m., Alex Deucher wrote:
> > On Fri, Feb 14, 2020 at 7:17 PM Luben Tuikov wrote:
> >>
> >> Add a AMDGPU_GEM_CREATE_MASK and use it to check
> >> for valid/invalid GEM create flags coming in from
> >> userspace.
> >>
> >>
Hi Hawking
The problem is amdgpu_mcbp only controls OS preemption feature, and OS
preemption cannot enabled together with world switch MCBP
That's why we still need to differentiate them separately
Besides, there are some logic handling different between them, you can check
the details in my
Hawking is right here. We could just check amdgpu_mcbp during device
initialization and forcefully clear it under SRIOV.
But why is MCBP and SRIOV mutual exclusive? We are certainly getting the
requirement for this sooner or later.
Regards,
Christian.
Am 18.02.20 um 13:29 schrieb Liu, Monk:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
> GPU address handling is device specific and should be handle by its device
> driver.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
> include/drm/ttm/ttm_bo_api.h| 2 --
> include/drm/ttm/ttm_bo_driver.h | 1
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
[AMD Official Use Only - Internal Distribution Only]
It's some kind of annoying to check vf in every place that is required for mcbp
until amdgpu_mcbp is enabled by default. What's more, when amdgpu_mcbp is
enabled by default, there will be many unnecessary vf check that can be removed
as most
If OS preemption can work with SRIOV world switch I won't provide such patch, I
would already clean up those MCBP checking ...
To your question: I don't know details, but my guess is that CP use the same
interface with KMD (e.g. CE/DE meta) to handle two MCBP type: world switch and
OS
Even not talking about CE/DE meta and SDMA CS, we still cannot share
amdgpu_mcbp with SRIOV case, e.g.:
In some place we use "if (amdgpu_mcbp || amdgpu_sriov_vf()" to check, and we do
the same thing under that condition,
But we cannot do that thing by "if (amdgpu_mcbp)" and set "amdgpu_mcbp"
On Tue, Feb 18, 2020 at 2:56 AM Yusuf Altıparmak
wrote:
>
> Hello AMD team;
>
> I have E 9171 GPU and want to use it on a embedded system which has limited
> MMIO space on PCIe bus (MAX 512 MB).
>
> I received feedbacks that I can only use VGA emulation with this memory
> space. I was unable to
Hi,
the email's subject line should contain the version of the patchset
(e.g, v2, v3, etc). git send-mail adds this with the -v switch
Best regards
Thomas
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
> With this patch series I am trying to remove GPU address dependency in
> TTM and moving GPU
[AMD Official Use Only - Internal Distribution Only]
Please remove the ticket number from the commit description. With that fixed,
the patch is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Monk Liu
Sent: Tuesday, February 18, 2020 10:54
[AMD Official Use Only - Internal Distribution Only]
! smu->smu_table.max_sustainable_clocks is the preferred coding style. And
please also remove internal changelist no from commit description.
With above addressed, the patch is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original
[AMD Official Use Only - Internal Distribution Only]
Ahhh Send it too quickly. Of course, we still need to apply vf check for
ce/de-meta, but I think in such way, we can dramatically reduce the
amdgpu_sirov_vf check in every mcbp code path.
Regards,
Hawking
-Original Message-
Hi Xinhui,
Two suggestions inline. Looks good to me otherwise.
On 2020-02-17 10:36 p.m., xinhui pan wrote:
No need to trigger eviction as the memory mapping will not be used
anymore.
All pt/pd bos share same resv, hence the same shared eviction fence.
Everytime page table is freed, the fence
> 2020年2月19日 07:10，Kuehling, Felix 写道：
>
> Hi Xinhui,
>
> Two suggestions inline. Looks good to me otherwise.
>
> On 2020-02-17 10:36 p.m., xinhui pan wrote:
>> No need to trigger eviction as the memory mapping will not be used
>> anymore.
>>
>> All pt/pd bos share same resv, hence the same
check whether the queue of entity is null to avoid null
pointer dereference.
Change-Id: I08d56774012cf229ba2fe7a011c1359e8d1e2781
Signed-off-by: Dennis Li
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
index 4cc7881f438c..67cca463ddcc
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Dennis Li
Sent: Wednesday, February 19, 2020 12:05
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhou1, Tao ; Zhang, Hawking
; Chen, Guchun
Cc: Li,
Hi Hans
For CE/DE meta data, OS preemption would write those credential to a
dynamically allocated CSA buffer (one per process), but for SRIOV we only write
them to static CSA (one per VF)
In windows KMD, the OS Preemption is forced to disabled when SRIOV is enabled
Based on above two reason
>> I don't want to mix os preemption with world switch here. I'm just trying to
>> see whether we can leverage the code path as much as possible, i.e. CSA
>> related code path.
Yeah, I agree with that
>> But I'd like to take another chance to review all the existing mcbp code
>> with Jack
The problem Yusuf runs into is that his platform has multiple PCIe root
hubs, but only 512MB of MMIO address space. That is not enough to fit
all the BARs of an E9171 into.
But without the BARs neither the VGA emulation nor amdgpu not anything
else will work correctly.
And we already
On 2/18/20 3:31 PM, Alex Deucher wrote:
The driver uses a scratch register to communicate with the SMU.
Add a lock to make sure we don't try and do this concurrently
by accident.
Signed-off-by: Alex Deucher
Acked-by: Nirmoy Das
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 1 +
On Mon, Feb 17, 2020 at 10:01 PM Quan, Evan wrote:
>
> Hi Alex,
>
> Did you seen any issue caused by this?
Seems to help on:
https://gitlab.freedesktop.org/drm/amd/issues/1047
I haven't been able to prove to myself that the existing high level
locking covers every case.
Alex
>
> Regards,
>
On 2/18/20 1:42 PM, Thomas Zimmermann wrote:
Hi,
the email's subject line should contain the version of the patchset
(e.g, v2, v3, etc). git send-mail adds this with the -v switch
Thanks Thomas. I over looked that, will add version tag from my next
emails.
Nirmoy
Best regards
Thomas
[AMD Official Use Only - Internal Distribution Only]
Does the VBIOS come up with something like a splash screen, ie is VBIOS able to
initialize and drive the card ?
If so then another option might be to use a VESA driver rather than VGA.
From: amd-gfx on
[AMD Official Use Only - Internal Distribution Only]
>And we already checked, 256MB is unfortunately the minimum you can resize the
>VRAM BAR on the E9171 to.
Ahh, OK... I didn't realize we had already looked into that. I guess that
approach isn't going to work.
Yusef, guessing you are using
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
device
driver.
Signed-off-by: Nirmoy Das
---
The driver uses a scratch register to communicate with the SMU.
Add a lock to make sure we don't try and do this concurrently
by accident.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 1 +
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 +
[AMD Official Use Only - Internal Distribution Only]
At CP level, MCBP and SRIOV are not mutually exclusive. They are used together
in some environments.
/Hans
-Original Message-
From: Liu, Monk
Sent: Tuesday, February 18, 2020 7:53 AM
To: Koenig, Christian ; Zhang, Hawking
;
[AMD Official Use Only - Internal Distribution Only]
Hi Monk,
I don't want to mix os preemption with world switch here. I'm just trying to
see whether we can leverage the code path as much as possible, i.e. CSA related
code path.
Specific for the sriov check in your patch, as I mentioned
Yusef is using an ARM platform. As far as I know he already tried to
shuffle the static allocation for the MMIO address spaces around without
much luck.
The only option I see would be to use the PCIe bridge trick I've
mentioned below, but this is really so hacky that I won't recommend that.
*Hello Mr. Alex, Mr. Cönig and Mr. Bridgman, *
*Mr. Cönig, we have talked about MMIO problem before. You helped me a lot
about that and now driver is not giving any error about MMIO. That problem
was about bus configuration of my embedded system. It does not proceed more
than 4GB besides 0x0
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
This patch removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar
This patch also removes unused qxl_bo_gpu_offset()
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 6 ++
Calculate GPU offset within vram-helper without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c
Switch over to GEM VRAM's implementation to retrieve bo->offset
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
>
> On 2/18/20 1:44 PM, Christian König wrote:
>> Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
>>> Hi
>>>
>>> Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
device
driver.
Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
Hi
Am 18.02.20 um 19:23 schrieb Christian König:
> Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 18.02.20 um 18:13 schrieb Nirmoy:
>>> On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
> Hi
>
> Am 17.02.20 um 16:04 schrieb
On 2/18/20 7:16 PM, Thomas Zimmermann wrote:
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
63 matches
Mail list logo
