Hello Harry and Alex,
Watt numbers are broken for some days (5 to 7).
Polaris 20 (RX580), Sapphire Nitro+, 8 GB
amdgpu-pci-0100
Adapter: PCI adapter
vddgfx: +0.75 V
fan1:1048 RPM
temp1:+28.0°C (crit = +94.0°C, hyst = -273.1°C)
power1:0.00 W (cap = 175.00 W)
Shou
On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote:
> > Michel Dänzer writes:
> >> Time-based presentation seems to be the right approach for preventing
> >> micro-stutter in games as well, Croteam developers have been researching
Ping.
On 2018-04-17 06:12 PM, Andres Rodriguez wrote:
Add a new function amdgpu_ucode_request_firmware() that encapsulates a
lot of the common behaviour we have around firmware requests.
This is the first step in my quest to get rid of the following annoying
messages when my polaris10 boots up:
On Fri, Apr 20, 2018 at 2:16 AM, Zhu, Rex wrote:
> Hi Alex,
>
>> There will be a '*' next to the level that is currently active.
>
> We need to add a level for deep sleep state.
> Otherwise, On Vega/Rv, when gpu in deepsleep, we can't set "*" for the
> current level.
I dropped that sentence fo
On 2018-04-17 02:57 AM, Shirish S wrote:
> The dp aux channel cannot read messages of size greater
> than 16 bytes, this patch adds quirks feild accordingly
> at the initialization of the adaptor.
Is this in response to a bug?
I don't see any other DRM driver using quirks like this, even though t
On 2018-04-17 10:56 PM, Shirish S wrote:
> Currently the dm_dp_aux_transfer() does not parse
> the return value of dal_ddc_service_read_dpcd_data(), which also
> has a failure case.
> This patch captures the same and ensures the i2c operation status is
> sent appropriately to the drm framework.
>
Signed-off-by: Tom St Denis
---
doc/sphinx/source/libwave_status.rst | 28 +++
src/app/print_waves.c| 379 +--
src/lib/CMakeLists.txt | 1 +
src/lib/scan_waves.c | 97 +
src/umr.h
On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > num_resources) which does the handling common to all drivers.
> > A structure that contains
> >
> > {page,offset,len} + {dma_addr+dma_len}
> >
> > is not a
On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
> > Yes there's a bit a layering violation insofar that drivers really
> > shouldn't each have their own copy of "how do I convert a piece of dma
> > memory into dma-buf", but that doesn't render the interface a bad idea.
>
> Comple
From: Michel Dänzer
Use our own BoxRec for the extents, and RegionEmpty for clearing the
scanout damage region.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_displ
On Fri, Apr 20, 2018 at 05:46:25AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote:
> > > > What we need is an sg_alloc_table_from_resources(dev, resources,
> > > > num_resources) which does the handling common to all drivers.
> > > A structure that
From: Michel Dänzer
Without this, RandR would report the CRTC and its outputs as enabled,
even though they were actually off due to the failure.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/drmmode_display.c b/src/drmmode_disp
Am 20.04.2018 um 12:17 schrieb Christoph Hellwig:
On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote:
Yes there's a bit a layering violation insofar that drivers really
shouldn't each have their own copy of "how do I convert a piece of dma
memory into dma-buf", but that doesn't ren
Am 20.04.2018 um 11:40 schrieb Huang Rui:
"aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)"
Above patch defers the execution of gfx/compute ib tests. However, at that time,
the gfx may already go into idle state. If "idle" gfx receives command
submission, it will get hang in the sy
"aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)"
Above patch defers the execution of gfx/compute ib tests. However, at that time,
the gfx may already go into idle state. If "idle" gfx receives command
submission, it will get hang in the system. So we must add is_gfx_on checking at
s
Series is Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Friday, April 20, 2018 2:30 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH 2/2] drm/amd/pp: Use dynamic gfx_clk rat
Am 20.04.2018 um 09:13 schrieb Daniel Vetter:
On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
We've broken that assumption in i915 years ago. Not struct page backed
gpu memory is very real.
Of course we'll never
On 04/20/2018 02:58 PM, Christian König wrote:
Am 20.04.2018 um 04:04 schrieb Zhang, Jerry (Junwei):
On 04/20/2018 09:50 AM, Zhang, Jerry (Junwei) wrote:
On 04/19/2018 07:06 PM, Christian König wrote:
Wouldn't it be simpler to just set MAX_CARDS_SUPPORTED to 128?
Perhaps it's 64 for card num
On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
> > We've broken that assumption in i915 years ago. Not struct page backed
> > gpu memory is very real.
> >
> > Of course we'll never feed such a strange sg table to
19 matches
Mail list logo
