On Thu, Jan 24, 2019 at 04:52:59PM -0800, ndesaulni...@google.com wrote:
> arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The
> AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn
> on SSE2 to support emitting double precision floating point instructions
>
On Thu, Jan 24, 2019 at 04:52:59PM -0800, ndesaulni...@google.com wrote:
> arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The
> AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn
> on SSE2 to support emitting double precision floating point instructions
>
arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The
AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn
on SSE2 to support emitting double precision floating point instructions
rather than calls to non-existent (usually available from gcc_s or
compiler_rt)
On 2019-01-24 12:41 p.m., Christian König wrote:
> Am 24.01.19 um 18:06 schrieb Nicholas Kazlauskas:
>> [Why]
>> It's useful to know the min and max vrr range for IGT testing.
>>
>> [How]
>> Expose the min and max vfreq for the connector via a debugfs file
>> on the connector, "vrr_range".
>>
>>
Am 24.01.19 um 18:06 schrieb Nicholas Kazlauskas:
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
Cc: Harry
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
Cc: Harry Wentland
Cc: Leo Li
Signed-off-by: Nicholas
This should not result in any changes.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-gfx@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_fb.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
If a non-legacy driver calls these it's valid to assume there is
interrupt support. The flag is really only needed for legacy drivers.
Also remove all the flag usage from non-legacy drivers.
Signed-off-by: Daniel Vetter
Cc: linux-arm-ker...@lists.infradead.org
Cc:
On 2019-01-24 12:45 p.m., Ard Biesheuvel wrote:
> On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> wrote:
>> Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
>>> On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
>>> wrote:
Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> [SNIP]
> This is
On 01/24/2019 02:18 AM, Lou, Wentao wrote:
> ++Monk
>
> Yes amdgpu_lockup_timeout was forced to 1 in current code, that means
> amdgpu_device_gpu_recover was not triggered inside xgpu_ai_mailbox_flr_work.
> For sriov, amdgpu_device_gpu_recover was already called by
> amdgpu_job_timedout,
OK, I will update patches 1 and 2 and given your RBs push them since
they fix some races. I will then update and test patch 3 on some basic
scenarios and will send it for separate review where I might put a TODO
comment in code with my objections regarding long jobs form our
discussion so you
On Thu, Jan 24, 2019 at 8:57 AM Ard Biesheuvel
wrote:
>
> On Thu, 24 Jan 2019 at 14:54, Alex Deucher wrote:
> >
> > On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel
> > wrote:
> > >
> > > On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> > > wrote:
> > > >
> > > > Am 24.01.19 um 12:26 schrieb
The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
for some buffers, both the CPU and the GPU use uncached mappings,
removing the need for DMA snooping and allocation in the CPU caches.
The use of uncached GPU
On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> > [SNIP]
> > This is *exactly* my point the whole time.
> >
> > The current code has
> >
> > static inline bool drm_arch_can_wc_memory(void)
> > {
> > #if defined(CONFIG_PPC) &&
On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
wrote:
>
> Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > wrote:
> >> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> >>> [SNIP]
> >>> This is *exactly* my point the whole time.
> >>>
> >>> The
On Thu, 24 Jan 2019 at 10:31, Michel Dänzer wrote:
>
> On 2019-01-23 5:52 p.m., Ard Biesheuvel wrote:
> > On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
> >>
> >> I think we just want a driver-local check for those combinations
> >> where we know this hack actually works, which really
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Evan Quan
Sent: Thursday, January 24, 2019 2:48:05 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH 4/4] drm/amd/powerplay: support Vega12 retrieving and setting
ppfeatures
On Thu, 24 Jan 2019 at 14:54, Alex Deucher wrote:
>
> On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel
> wrote:
> >
> > On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> > wrote:
> > >
> > > Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > > > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > >
On Thu, 24 Jan 2019 at 10:45, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:28 schrieb Ard Biesheuvel:
> > On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
> > wrote:
> >> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> >>> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
>
On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel
wrote:
>
> On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> wrote:
> >
> > Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > > wrote:
> > >> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> > >>>
On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel
wrote:
>
> On Thu, 24 Jan 2019 at 13:31, Koenig, Christian
> wrote:
> >
> > Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> > > The DRM driver stack is designed to work with cache coherent devices
> > > only, but permits an optimization to be enabled
On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> > On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
> >> But my concern is that it seems likely that non-cache coherent
> >> implementations are relying on this hack as well.
On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
> But my concern is that it seems likely that non-cache coherent
> implementations are relying on this hack as well. There must be a
> reason that this hack is only disabled for PowerPC platforms if they
> are cache coherent, for
On Thu, 24 Jan 2019 at 13:31, Koenig, Christian
wrote:
>
> Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> > The DRM driver stack is designed to work with cache coherent devices
> > only, but permits an optimization to be enabled in some cases, where
> > for some buffers, both the CPU and the GPU
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Evan Quan
Sent: Thursday, January 24, 2019 5:59:18 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH 2/2] drm/amd/powerplay: avoid frequent metrics table export
That's
Remove the callback and call the dispatcher directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 48 +
Further testing showed that the idea with the chash doesn't work as expected.
Especially we can't predict when we can remove the entries from the hash again.
So replace the chash with a simple ring buffer for now to filter out the
already handled faults. As long as we see less than 64 distinct
On Thu, Jan 24, 2019 at 10:46:47AM +0100, Daniel Vetter wrote:
> On Wed, Jan 23, 2019 at 06:00:15PM +0100, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> > > Having the probe helper stuff (which pretty much everyone needs) in
> > > the
Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> The DRM driver stack is designed to work with cache coherent devices
> only, but permits an optimization to be enabled in some cases, where
> for some buffers, both the CPU and the GPU use uncached mappings,
> removing the need for DMA snooping and
Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
>>> [SNIP]
>>> This is *exactly* my point the whole time.
>>>
>>> The current code has
>>>
>>> static inline bool drm_arch_can_wc_memory(void)
I see a few cleanups on Patch #3 which actually belong in patch #1:
> +void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
> drm_sched_job *bad)
The "bad" job parameter actually isn't used any more, isn't it?
> +retry_wait:
Not used any more.
But apart from that at least patch #1 and
Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> [SNIP]
> This is *exactly* my point the whole time.
>
> The current code has
>
> static inline bool drm_arch_can_wc_memory(void)
> {
> #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
> return false;
>
> which means the optimization
That's unnecessary. Also it makes more sense to show all the clocks
on one metrics table export.
Change-Id: I6350911934dbd85dc701de17ccc0e9cbddda4648
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 43 +--
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.h
Current implementation cannot report the correct gfxclk under DS.
Change-Id: Ief979ae1ddc6f8107535d45052c517bafde91bf5
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git
On Wed, Jan 23, 2019 at 06:00:15PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> > Having the probe helper stuff (which pretty much everyone needs) in
> > the drm_crtc_helper.h file (which atomic drivers should never need) is
> >
Am 24.01.19 um 10:28 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
>>> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
But my concern is that it seems likely that non-cache coherent
On 2019-01-23 5:52 p.m., Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
>>
>> I think we just want a driver-local check for those combinations
>> where we know this hack actually works, which really just seems
>> to be x86-64 with PAT. Something like the patch
Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
>> But my concern is that it seems likely that non-cache coherent
>> implementations are relying on this hack as well. There must be a
>> reason that this hack is only disabled for
38 matches
Mail list logo
