Hi Christian
I believe Wentao can fix the issue we it by below step:
1. Return Virtual_address_max (UMD use it) to HOLE_START – RESERVED_SIZE
2. [optional] Still Keep virtual_address_offset to RESERVED_SIZE (current
way, I think it’s because previously we put CSA in 0 --> RESERVED_SIZE spa
Hi Monk,
ok let me explain a bit more how the hardware works.
The GMC manages a virtual 64bit address space, but only 48bit of that virtual
address space are handled by the page table walker.
The 48bits of address space are sign extended, so bit 47 of that are extended
into bits 48-63.
This g
sriov would meet guest driver load failure,
if calling amdgpu_asic_reset in amdgpu_device_init.
sriov should skip asic_reset in device_init.
Change-Id: I6c03b2fcdbf29200fab09459bbffd87726047908
Signed-off-by: Wentao Lou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 ins
No dpm level setting is needed when the request level
is actually same as current.
Change-Id: I3ffa0b111a7b37f78a6a4dc1a36d49f0496dd6f9
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
No display related settings are needed on dpm level change.
Change-Id: I86b32687a3bc14521be89dd4a3c9fb7de7f06c4b
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 10 +-
drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 11 +--
drivers/gpu/drm/amd/powerplay
Hi Christian
Thanks for explaining the HOLD for us,
My understanding is we still could put CSA to 0~HOLE_START, because we can
report UMD the max space is HOLD_START-CSA_SIZE , thus no colliding will hit.
> Now on Vega/Raven/Picasso etc.. (everything with a GFX9) the lower range
> (0x0-0x8000
Hi Monk,
Regarding with above sentence, do you mean this range (0->HOLE_START) shouldn’t
be exposed to user space ? I don’t get your point here …
Yes exactly. As I said the problem is that 0->HOLE_START is reserved for the
ATC hardware, we should not touch it at all.
Putting CSA in 0~HOLD_START
On Thu, Jan 17, 2019 at 4:51 AM wentalou wrote:
>
> sriov would meet guest driver load failure,
> if calling amdgpu_asic_reset in amdgpu_device_init.
> sriov should skip asic_reset in device_init.
>
> Change-Id: I6c03b2fcdbf29200fab09459bbffd87726047908
> Signed-off-by: Wentao Lou
Acked-by: Alex
On 01/17/2019 02:45 AM, Christian König wrote:
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On 01/16/2019 02:46 AM, Christian König wrote:
Am 15.01.19 um 23:01 schrieb Grodzovsky, Andrey:
On
Am 17.01.19 um 16:22 schrieb Grodzovsky, Andrey:
On 01/17/2019 02:45 AM, Christian König wrote:
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On 01/16/2019 02:46 AM, Christian König wrote:
Am
On Thu, Jan 17, 2019 at 6:48 AM Evan Quan wrote:
>
> No dpm level setting is needed when the request level
> is actually same as current.
>
> Change-Id: I3ffa0b111a7b37f78a6a4dc1a36d49f0496dd6f9
> Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/p
Reviewed-by: Alex Deucher
On Thu, Jan 17, 2019 at 6:48 AM Evan Quan wrote:
>
> No display related settings are needed on dpm level change.
>
> Change-Id: I86b32687a3bc14521be89dd4a3c9fb7de7f06c4b
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 10 +-
>
On 01/17/2019 10:29 AM, Koenig, Christian wrote:
Am 17.01.19 um 16:22 schrieb Grodzovsky, Andrey:
On 01/17/2019 02:45 AM, Christian König wrote:
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> > v5: Actually try to sort them, and while at it, sort all the ones I
> > touch.
>
> Applied this variant on top of drm-misc and did a build test.
> Looked good for ia64, x86 and alpha.
>
> Took a closer look at the c
On Thu, Jan 17, 2019 at 05:45:41PM +0100, Daniel Vetter wrote:
> On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > > v5: Actually try to sort them, and while at it, sort all the ones I
> > > touch.
> >
> > Applied this variant on top of drm-misc and did a build
Check if the device is root rather before attempting to see what
speeds the pcie port supports. Fixes a crash with pci passthrough
in a VM.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109366
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 5 +++--
drivers/gpu/drm/radeon/
On 2019-01-15 5:42 a.m., Paul Menzel wrote:
> Dear Hersen, dear Leo,
>
>
> Some nitpicks. Could you not put the problem statement in the commit
> message summary, but the solution? For example:
>
>> Fix eDP fast bootup for pre-raven asics
>
> On 01/14/19 23:36, sunpeng...@amd.com wrote:
>> F
In commit dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
case statements were added without a terminating break statement. This
commit adds the missing break. This was discovered during a compilation
with W=1.
This commit removes the following warning:
drivers/gpu/drm/radeon/ever
On 01/17/2019 10:29 AM, Koenig, Christian wrote:
Am 17.01.19 um 16:22 schrieb Grodzovsky, Andrey:
On 01/17/2019 02:45 AM, Christian König wrote:
Am 16.01.19 um 18:17 schrieb Grodzovsky, Andrey:
On 01/16/2019 11:02 AM, Koenig, Christian wrote:
Am 16.01.19 um 16:45 schrieb Grodzovsky, Andrey:
Thanks Christian,
Questions I have now:
1. You see that for UMD, it can use 0 to HOLE_START, so why CSA cannot use
that range although the range is as you said reserved to ATC h/w ? Be note that
for windows KMD, the CSA is allocated by UMD driver so CSA shares the same
aperture /space rang
Hi Christian,
Thanks for the explanation. I have another question for the HOLE.
As you mentioned “Trying to access the hole results in a range fault interrupt
IIRC.”
0x8000
hole
0x 8000
But you said “0x FFF0 is the correct address, if that is causing a
pro
21 matches
Mail list logo
