Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/Makefile | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 513 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 536 +++
drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.h | 1
Change-Id: Ifd6553646e7468bc935504075816074373e1d58d
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
inde
delete struct pp_instance,
make struct hwmgr as the smu hw context.
Change-Id: I444aabe20477fc2fc1288542d45bf887d45bf0cd
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/Makefile | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu
make it symmetric with the init bo in amd_powerplay.c
refine the "commit b22558bb4ff8fc9fe925222f90297d7a03a5fb20"
Change-Id: I0bca00fa2a376cf6539b046eefff2ca3d30c3cae
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 3 ---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c
Am 12.03.2018 um 13:34 schrieb Rex Zhu:
Change-Id: Ifd6553646e7468bc935504075816074373e1d58d
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/dri
Sure.
Thanks.
Best Regards
Rex
From: Christian König
Sent: Monday, March 12, 2018 8:54 PM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/4] drm/amdgpu: Plus NULL function pointer check
Am 12.03.2018 um 13:34 schrieb Rex Zhu:
> Change-Id: I
hello there,
Source code is
for (i = 0; i < dc->res_pool->pipe_count; i++) {
if (res_ctx->pipe_ctx[i].stream) {
pipe_ctx = &res_ctx->pipe_ctx[i];
*pipe_idx = i;
break;
}
}
/* Only supports eDP */
if (pipe_ctx->stream->sink->li
On Fri, Mar 09, 2018 at 08:11:41PM +0100, Christian K??nig wrote:
> Each importer can now provide an invalidate_mappings callback.
>
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
>
> Signed-off-by: Christian K??nig
> ---
> drivers/dma-buf/dma-bu
On Fri, Mar 09, 2018 at 08:11:40PM +0100, Christian K??nig wrote:
> This set of patches adds an option invalidate_mappings callback to each
> DMA-buf attachment which can be filled in by the importer.
>
> This callback allows the exporter to provided the DMA-buf content
> without pinning it. The r
On 2018-03-07 03:34 PM, Felix Kuehling wrote:
>> Again stop worrying about ioctl overhead, this isn't Windows. If you
>> can show the overhead as being a problem then address it, but I
>> think it's premature worrying about it at this stage.
> I'd like syscall overhead to be small. But with recent
Am 12.03.2018 um 18:07 schrieb Daniel Vetter:
On Fri, Mar 09, 2018 at 08:11:41PM +0100, Christian K??nig wrote:
[SNIP]
+/**
+ * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
+ *
+ * @dmabuf:[in]buffer which mappings should be invalidated
+ *
+ * Informs all at
Am 12.03.2018 um 18:24 schrieb Daniel Vetter:
On Fri, Mar 09, 2018 at 08:11:40PM +0100, Christian K??nig wrote:
This set of patches adds an option invalidate_mappings callback to each
DMA-buf attachment which can be filled in by the importer.
This callback allows the exporter to provided the DM
On Mon, Mar 12, 2018 at 7:17 PM, Felix Kuehling wrote:
> On 2018-03-07 03:34 PM, Felix Kuehling wrote:
>>> Again stop worrying about ioctl overhead, this isn't Windows. If you
>>> can show the overhead as being a problem then address it, but I
>>> think it's premature worrying about it at this sta
On Mon, Mar 12, 2018 at 8:15 PM, Christian König
wrote:
> Am 12.03.2018 um 18:24 schrieb Daniel Vetter:
>>
>> On Fri, Mar 09, 2018 at 08:11:40PM +0100, Christian K??nig wrote:
>>>
>>> This set of patches adds an option invalidate_mappings callback to each
>>> DMA-buf attachment which can be filled
On 2018-03-12 03:37 PM, Daniel Vetter wrote:
> On Mon, Mar 12, 2018 at 7:17 PM, Felix Kuehling
> wrote:
>> On 2018-03-07 03:34 PM, Felix Kuehling wrote:
Again stop worrying about ioctl overhead, this isn't Windows. If you
can show the overhead as being a problem then address it, but I
>
On 03/12/2018 06:22 AM, David Binderman wrote:
hello there,
Source code is
for (i = 0; i < dc->res_pool->pipe_count; i++) {
if (res_ctx->pipe_ctx[i].stream) {
pipe_ctx = &res_ctx->pipe_ctx[i];
*pipe_idx = i;
break;
}
}
Inde
There is a check just before for-loop that should ensure pipe_ctx is not null:
/* Only supports single display */
if (context->stream_count != 1)
return false;
To remove the subject warning - we can rather add an assert:
assert(pipe_ctx);
Thanks,
Roman
-Orig
The check before alone is not enough for a case where there is another
bug introduced so that
context->stream_count is not in sync with actual number of streams
across entire resource_context.
At least assert indeed should be there.
Andrey
On 03/12/2018 07:06 PM, Li, Roman wrote:
There is
Dear amd-gfx,
When running rocm 1.7.137 built against the on the Debian 9.4 kernel
4.9.82-1+deb9u3 with an RX580 connected to an LG 27UD88 monitor via
DisplayPort 1.2, I see some freesync and DC register access warnings
[1].
Let me know if more debug it useful.
Thanks,
Daniel
-- [1]
[0.0
Change-Id: Ifd6553646e7468bc935504075816074373e1d58d
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 56b2245..
This patch adds an essential check related to the size of the
payload to be transferred via aux channel.
Without this check dal_ddc_service_read_dpcd_data() is fed with
inappropriate payload size leading to deadlocks.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_
21 matches
Mail list logo
