Some new variants require updated firmware.
V2: add MODULE_FIRMWARE for new firmwares
Reviewed-by: Huang Rui (v1)
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 33 +++
drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 3 +++
2 files chan
On Fri, 19 Oct 2018 at 18:51, Daniel Vetter wrote:
>
> Hi all,
>
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this. I think the past few
> cross-vendor uapi extensions all came with igts attached, and
> personally I think there's
On Mon, Oct 29, 2018 at 9:39 PM Evan Quan wrote:
>
> Tell the version numbers when the pptable versions do not match.
>
> Change-Id: I3ea8aac7493927281b14d28866fa87690621f0f0
> Signed-off-by: Evan Quan
> ---
> .../drm/amd/powerplay/hwmgr/vega20_processpptables.c | 10 --
> 1 file chang
Tell the version numbers when the pptable versions do not match.
Change-Id: I3ea8aac7493927281b14d28866fa87690621f0f0
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega20_processpptables.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
OK. I'll drop this patch.
Marek
On Wed, Oct 24, 2018 at 4:14 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 24.10.18 um 10:04 schrieb Michel Dänzer:
> > On 2018-10-23 9:07 p.m., Marek Olšák wrote:
> >> From: Marek Olšák
> >>
> >> ---
> >> amdgpu/amdgpu_bo.c | 15 +-
You and I discussed this extensively internally a while ago. It's expected
and correct behavior. Mesa doesn't unmap some buffers and never will.
Marek
On Wed, Oct 24, 2018 at 3:45 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> That looks really ugly to me. Mapping the same BO so
On Tue, Oct 23, 2018 at 10:38 PM Zhang, Jerry(Junwei)
wrote:
> On 10/24/18 3:07 AM, Marek Olšák wrote:
> > From: Marek Olšák
>
> We need commit log and sign-off here.
>
> BTW, have you encounter any issue about that?
>
I don't know what you mean. I'm pretty sure that a sign-off is not needed
fo
Series is:
Reviewed-by: Alex Deucher
On Mon, Oct 29, 2018 at 12:24 PM Grodzovsky, Andrey
wrote:
>
> Typo, series is Reviewed-by: Andrey Grodzovsky
>
> Andrey
>
> On 10/29/2018 12:18 PM, Grodzovsky, Andrey wrote:
> > Reviewed-by: Andrey Grodzovsky
> >
> > Andrey
> >
> >
> > On 10/29/2018 11:28 A
On Thu, Oct 25, 2018 at 4:46 PM Mikulas Patocka wrote:
>
>
>
> On Wed, 24 Oct 2018, Mikulas Patocka wrote:
>
> > Hi
> >
> > I have a Sapphire Pulse RX 570 ITX graphics card.
> >
> > On Linux, I get errors "amdgpu: [powerplay] failed to send message 148 ret
> > is 0" and the system is stuck for sev
On 10/29/18 2:03 PM, Ville Syrjälä wrote:
> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
>> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
>>> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
On 10/26/18 10:53 AM, Ville Syrjälä wrote:
>
> Speaking
On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
> > On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
> >> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> >>>
> >>> Speaking of timestamps. What is the expected behaviour
On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
>> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
>>>
>>> Speaking of timestamps. What is the expected behaviour of vblank
>>> timestamps when vrr is enabled?
>>
>> When vrr is enabled
Typo, series is Reviewed-by: Andrey Grodzovsky
Andrey
On 10/29/2018 12:18 PM, Grodzovsky, Andrey wrote:
> Reviewed-by: Andrey Grodzovsky
>
> Andrey
>
>
> On 10/29/2018 11:28 AM, Christian König wrote:
>> We already print an error message that an IB test failed in the common
>> code.
>>
>> Signe
Reviewed-by: Andrey Grodzovsky
Andrey
On 10/29/2018 11:28 AM, Christian König wrote:
> We already print an error message that an IB test failed in the common
> code.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 18 +++
> drivers/gpu/drm/amd/am
Test only initialized rings, use the ring name instead of the index in the
error message and note on which device the error occured.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 35 ++
1 file changed, 19 insertions(+), 16 deletions(-
We already print an error message that an IB test failed in the common
code.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 18 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 18 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 54 +--
Instead of hard coding the ring type in the function just never provide
a test_ib callback.
Additional to that remove the emit_ib callback to make sure the nobody
ever tries to execute an IB on the KIQ.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 11 +++
Move all error messages from IP specific code into the common helper.
This way we now uses the ring name in the messages instead of the index
and note which device is affected as well.
Also cleanup error handling in the IP specific code and consequently use
ETIMEDOUT when the ring test timed out.
On 10/29/18 4:36 AM, Pekka Paalanen wrote:
> On Fri, 26 Oct 2018 17:34:15 +
> "Kazlauskas, Nicholas" wrote:
>
>> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
>>> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
On 10/26/18 7:37 AM, Pekka Paalanen wrote:
>
> Hi,
>>
Am 29.10.18 um 12:23 schrieb Samuel Pitoiset:
Similar to other error messages, might help for tracking down
issues.
Signed-off-by: Samuel Pitoiset
Reviewed-by: Christian König
Going to push that if nobody objects,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
1 file cha
Similar to other error messages, might help for tracking down
issues.
Signed-off-by: Samuel Pitoiset
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
ind
> Am 09.11.2017 um 11:53 schrieb Piotr Redlewski:
> > On Thu, Nov 09, 2017 at 11:09:42AM +0100, Christian König wrote:
> >> Am 09.11.2017 um 10:54 schrieb Piotr Redlewski:
> >>> On Wed, Nov 08, 2017 at 06:54:18PM -0500, Alex Deucher wrote:
> On Wed, Nov 8, 2017 at 5:38 PM, Piotr Redlewski wro
在 2018年10月29日,16:40,Koenig, Christian 写道:
>
> Am 29.10.18 um 09:13 schrieb Zhang, Jerry:
>> 在 2018年10月29日,15:32,Christian König 写道:
>>> Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
在 2018年10月26日,18:59,Christian König 写道:
> Make sure the kernel doesn't crash if we map something at the
>>
Am 29.10.18 um 09:13 schrieb Zhang, Jerry:
> 在 2018年10月29日,15:32,Christian König 写道:
>> Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
>>> 在 2018年10月26日,18:59,Christian König 写道:
Make sure the kernel doesn't crash if we map something at the
minimum/maximum address.
Signed-off-by:
On Fri, 26 Oct 2018 17:34:15 +
"Kazlauskas, Nicholas" wrote:
> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> > On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
> >> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> >>> Hi,
> >>>
> >>> where is the documentation that explai
在 2018年10月29日,15:32,Christian König 写道:
>
> Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
>> 在 2018年10月26日,18:59,Christian König 写道:
>>> Make sure the kernel doesn't crash if we map something at the
>>> minimum/maximum address.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> tests/amdgpu/vm_t
Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
在 2018年10月26日,18:59,Christian König 写道:
Make sure the kernel doesn't crash if we map something at the minimum/maximum
address.
Signed-off-by: Christian König
---
tests/amdgpu/vm_tests.c | 45 -
1 file changed,
27 matches
Mail list logo