Change-Id: I35a35ed2956fc76cef7c31d45502ccb614040dee
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 3ecdbdfb04dd..bb1
The hiberachy of page table is as below, which aligns hw names.
PDB2->PDB1->PDB0->PTB, accordingly:
level3 --- PDB2
level2 --- PDB1
level1 --- PDB0
level0 --- PTB
v2:
previous the root pdb is level0, not only me, also many people
thought the root PDB is PDB0, but our many hw documents assume
PDB0
Setting default values for min and max threshold temperatures.
Hwmgr can override these values if it has necessary tables.
Reviewed-by: Alex Deucher
Signed-off-by: Satyajit Sahu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.h | 3 +++
2
Am 11.12.2017 um 04:55 schrieb Alex Deucher:
On Sun, Dec 10, 2017 at 10:01 PM, Chunming Zhou wrote:
On 2017年12月08日 22:58, Alex Deucher wrote:
On Fri, Dec 8, 2017 at 5:56 AM, Chunming Zhou wrote:
The hiberachy of page table is as below, which aligns hw names.
PDB2->PDB1->PDB0->PTB, according
For yours, seems not ready yet, right?
It is completely functional and tested.
We should handle 64KB native page to 16 * 4KB sub-PTB for TF case,
which is the only verified option by HW.
No, we are using only 2M page since Vega10 now and so far that works
perfectly fine.
We are seriously not
Am 08.12.2017 um 19:24 schrieb Alex Deucher:
All functions should have nbio_v* prefix.
Signed-off-by: Alex Deucher
Acked-by: Christian König for the series.
---
drivers/gpu/drm/amd/amdgpu/nbio_v6_1.c | 16
drivers/gpu/drm/amd/amdgpu/nbio_v7_0.c | 16
2
Am 11.12.2017 um 09:16 schrieb Chunming Zhou:
Change-Id: I35a35ed2956fc76cef7c31d45502ccb614040dee
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/
Am 11.12.2017 um 09:16 schrieb Chunming Zhou:
The hiberachy of page table is as below, which aligns hw names.
PDB2->PDB1->PDB0->PTB, accordingly:
level3 --- PDB2
level2 --- PDB1
level1 --- PDB0
level0 --- PTB
v2:
previous the root pdb is level0, not only me, also many people
thought the root PDB
On 2017-12-11 03:49 AM, He, Roger wrote:
>> From: Michel Dänzer [mailto:mic...@daenzer.net] On 2017-12-07 07:07
>> PM, Christian König wrote:
>>>
>>> I think I know what is going on here. The max-texture-size keeps
>>> increasing the texture size as long as it doesn't fails to
>>> allocate one.
>
Am 11.12.2017 um 06:52 schrieb Chunming Zhou:
On 2017年12月09日 00:41, Christian König wrote:
Not needed any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 52
+++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 -
2 files chan
On Sat, Dec 9, 2017 at 6:08 AM, Felix Kuehling wrote:
> From: Harish Kasiviswanathan
>
> Generate and parse VCRAT tables for dGPUs in kfd_topology_add_device.
>
> Some information that isn't available in the CRAT table is patched
> into the topology after parsing.
>
> HSA_CAP_DOORBELL_TYPE_1_0 is
On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling wrote:
> From: Amber Lin
>
> For hardware blocks whose performance counters are accessed via MMIO
> registers, KFD provides the support for those privileged blocks. IOMMU is
> one of those privileged blocks. Most performance counter properties
> requ
On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling wrote:
> From: Kent Russell
>
> Add a sysfs file in topology (node/x/memory_banks/X/used_memory) that
> reports the current VRAM usage for that node. Only works for GPU nodes
> at this time.
>
As with patch 22 (perf counters), I would not expect thi
On Mon, Dec 11, 2017 at 10:23 AM, Oded Gabbay wrote:
> On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling wrote:
>> From: Amber Lin
>>
>> For hardware blocks whose performance counters are accessed via MMIO
>> registers, KFD provides the support for those privileged blocks. IOMMU is
>> one of those
Am 11.12.2017 um 16:23 schrieb Oded Gabbay:
On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling wrote:
From: Amber Lin
For hardware blocks whose performance counters are accessed via MMIO
registers, KFD provides the support for those privileged blocks. IOMMU is
one of those privileged blocks. Most
On 2017-12-11 09:46 AM, Oded Gabbay wrote:
>> +
>> + /* Fill in IOLINK subtype.
>> +* TODO: Fill-in other fields of iolink subtype
>> +*/
>> + sub_type_hdr->io_interface_type = CRAT_IOLINK_TYPE_PCIEXPRESS;
>> + sub_type_hdr->proximity_domain_from = proximity_domain
On 2017-12-04 03:55 PM, Alex Deucher wrote:
> We don't currently expose variable refresh rate, but add the state to the
> connector state to make it easier to maintain the support for it from a
> hw support perspective while we figure out the uapi for drm.
>
> Signed-off-by: Alex Deucher
Reviewe
On Mon, Dec 11, 2017 at 5:53 PM, Christian König
wrote:
> Am 11.12.2017 um 16:23 schrieb Oded Gabbay:
>>
>> On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling
>> wrote:
>>>
>>> From: Amber Lin
>>>
>>> For hardware blocks whose performance counters are accessed via MMIO
>>> registers, KFD provides th
On Mon, Dec 11, 2017 at 5:32 PM, Oded Gabbay wrote:
> On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling wrote:
>> From: Kent Russell
>>
>> Add a sysfs file in topology (node/x/memory_banks/X/used_memory) that
>> reports the current VRAM usage for that node. Only works for GPU nodes
>> at this time.
On Mon, Dec 11, 2017 at 5:47 PM, Alex Deucher wrote:
> On Mon, Dec 11, 2017 at 10:23 AM, Oded Gabbay wrote:
>> On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling
>> wrote:
>>> From: Amber Lin
>>>
>>> For hardware blocks whose performance counters are accessed via MMIO
>>> registers, KFD provides t
Am 11.12.2017 um 17:32 schrieb Oded Gabbay:
On Mon, Dec 11, 2017 at 5:53 PM, Christian König
wrote:
Am 11.12.2017 um 16:23 schrieb Oded Gabbay:
On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling
wrote:
From: Amber Lin
For hardware blocks whose performance counters are accessed via MMIO
registe
Am 11.12.2017 um 17:40 schrieb Oded Gabbay:
On Mon, Dec 11, 2017 at 5:32 PM, Oded Gabbay wrote:
On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling wrote:
From: Kent Russell
Add a sysfs file in topology (node/x/memory_banks/X/used_memory) that
reports the current VRAM usage for that node. Only w
On 2017-12-11 12:28 PM, Christian König wrote:
> Am 11.12.2017 um 17:40 schrieb Oded Gabbay:
>> On Mon, Dec 11, 2017 at 5:32 PM, Oded Gabbay
>> wrote:
>>> On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling
>>> wrote:
From: Kent Russell
Add a sysfs file in topology (node/x/memory_banks
On 2017-12-11 10:23 AM, Oded Gabbay wrote:
> On Sat, Dec 9, 2017 at 6:09 AM, Felix Kuehling wrote:
>> From: Amber Lin
>>
>> For hardware blocks whose performance counters are accessed via MMIO
>> registers, KFD provides the support for those privileged blocks. IOMMU is
>> one of those privileged
From: Marek Olšák
Signed-off-by: Marek Olšák
---
Is this really correct? I have no easy way to test it.
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
i
NAK, you change break SRIOV logic:
Without lockup_timeout set, this gpu_recover() won't get called at all , unless
your IB triggered invalid instruct and that IRQ invoked
Amdgpu_gpu_recover(), by this cause you should disable the logic that in that
IRQ instead of change gpu_recover() itself bec
Both doorbell and polling mem are working on Tonga VF. SDMA issue
happens because SDMA engine accepts doorbell writes even if it's
inactive, that introduces conflict when world switch routine update
wptr though polling memory. Use polling mem in driver too.
Signed-off-by: Pixel Ding
---
drivers/
Hi Monk,
Please review.
—
Sincerely Yours,
Pixel
On 12/12/2017, 2:05 PM, "Pixel Ding" wrote:
Both doorbell and polling mem are working on Tonga VF. SDMA issue
happens because SDMA engine accepts doorbell writes even if it's
inactive, that introduces conflict when world switch rou
Both doorbell and polling mem are working on Tonga VF. SDMA issue
happens because SDMA engine accepts doorbell writes even if it's
inactive, that introduces conflict when world switch routine update
wptr though polling memory. Use polling mem in driver too.
v2:
- standalone pollmem code path
Sig
Please make description in your comments more detail, e.g. :
We have two sources to update wptr registers for sdma3: 1) wptr_poll and
2) is doorbell. When doorbell and wptr_poll are both enabled on sdma3,
there will be collision hit in occasion between those two sources when
ucode and h/w are do
Change-Id: I3abf5bde8c64ccab8e842a7c22aee011fc34e69f
Reviewed-by: Evan Quan
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
b/d
On 2017年12月09日 00:41, Christian König wrote:
Instead of falling back to 2 level and very limited address space use
2+1 PD support and 128TB + 512GB of virtual address space.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgp
32 matches
Mail list logo
