Should add I was able to read/write system memory mapped by amdgpu with these
patches in place on my polaris10 device (with iommu enabled of course).
From: amd-gfx on behalf of Tom St Denis
Sent: Monday, September 18, 2017 13:33
To: amd-gfx@lists.freede
short and simple KFD
setup I can install/run to test it? Or is simply loading a KFD merged/rebased
kernel enough to cause the hang (and thus I guess a bisect doesn't make sense).
Cheers,
Tom
From: Kuehling, Felix
Sent: Friday, August 11, 2017 20:40
You could use WREG32_FIELD15 to drop 3 lines into one.
Tom
From: amd-gfx on behalf of Shaoyun Liu
Sent: Wednesday, July 19, 2017 16:26
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH 2/2] drm/amdgpu: Clear active for HIQ in RLC_CP_SCHE
In amdgpu_vm_get_entry() if the bo size is less than 8 you'll get a divide by
zero. Are there mechanisms to prevent this? Maybe add a BUG() there?
Tom
From: amd-gfx on behalf of Christian
König
Sent: Monday, July 17, 2017 17:02
To: amd-gfx@lists.freed
Hi Qiang,
Sorry I must have missed that. I'll try it out first thing in the morning
(Markham time). If it's all good I'll add a Rb and push it out.
Cheers,
Tom
From: Yu, Qiang
Sent: Monday, July 10, 2017 22:07
To: amd-gfx@lists.freedeskt
lding for themselves [😊]
Tom
From: amd-gfx on behalf of StDenis, Tom
Sent: Monday, February 6, 2017 16:33
To: Emil Velikov; Tom St Denis
Cc: amd-gfx mailing list
Subject: Re: [PATCH] Autodetect libdrm path (v2)
I have to NAK that idea since we use umr on NP
d add
that to the README.
Tom
From: Emil Velikov
Sent: Monday, February 6, 2017 15:18
To: Tom St Denis
Cc: amd-gfx mailing list; StDenis, Tom
Subject: Re: [PATCH] Autodetect libdrm path (v2)
Hi Tom,
On 5 February 2017 at 22:24, Tom St Denis wrote:
> (v
Thanks. Pushed it.
Tom
From: Andres Rodriguez
Sent: Sunday, February 5, 2017 17:28
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] Autodetect libdrm path (v2)
Reviewed-by: Andres Rodriguez
On 2/5/2017 5:24 PM, Tom St
ested instead.
Tom
From: Andres Rodriguez
Sent: Sunday, February 5, 2017 16:26
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] autodetect path to libdrm
Hey Tom,
Overall in cmake calling pkg_check_modules() directly is usually not
guez
Sent: Sunday, February 5, 2017 11:11
To: StDenis, Tom; Edward O'Callaghan; amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR
Hey Tom,
It's great to see umr make it to the public. I've given it a quick spin
and it is pretty awesome, although I don&
Hi all,
Never mind answered my own question:
$ pkg-config libdrm --cflags
-I/usr/include/libdrm
So we could in theory include "drm.h" and then just add that to the head of our
CFLAGS.
Tom
From: amd-gfx on behalf of StDenis, Tom
Sent: Sunday,
correctly? e.g. if I modify umrapp.h, make rebuilds nothing. This is
one of the things cmake gives you for free, though with a bit of work make can
do it too.
Yours sincerely,
Bas Nieuwenhuizen
On Sun, Feb 5, 2017, at 12:42, StDenis, Tom wrote:
Hi Edward,
Well the patches apply and work b
day, February 5, 2017 08:29
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [RFC]: More robust build sys for UMR
On 02/05/2017 10:42 PM, StDenis, Tom wrote:
> Hi Edward,
Hey Tom,
>
>
> Well the patches apply and work but I'm not really sure what problem
> it'
system would fail?
(I'm not saying NAK I'm simply asking for my own edification).
Thanks,
Tom
From: Edward O'Callaghan
Sent: Saturday, February 4, 2017 23:59
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [RFC]: More robust build
Hello all,
We're pleased to announce the initial public release of the AMDGPU User Mode
Register debugger (umr). This tool allows privileged users to read and write
GPU registers in order to diagnose, debug, and aid in development of AMDGPU
features. The tool supports a variety of other comm
Hi Christian,
I have SI,CI,VI gear in my office if you have a unit test to try it with.
Cheers,
Tom
From: Christian König
Sent: Monday, January 30, 2017 09:14
To: StDenis, Tom; b...@basnieuwenhuizen.nl; airl...@gmail.com
Cc: amd-gfx@lists.freedesktop.org
Minor nit: the comment says v8 [😊]
The changes to the GFX6/7/8 look reasonable though only question is you read
from mmVM_PRT_CNTL and then write to mmVM_CONTEXT1_CNTL . Is that expected?
Tom
From: amd-gfx on behalf of Christian
König
Sent: Monday, Januar
Works on my CZ system:
Ack-by: Tom St Denis
From: amd-gfx on behalf of Christian
König
Sent: Tuesday, January 24, 2017 09:09
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 2/2] drm/amdgpu: fix 64bit shift for CZ
From: Christian König
Fixes "access stol
Coo, pushed to staging.
Tom
From: Deucher, Alexander
Sent: Wednesday, January 18, 2017 13:47
To: StDenis, Tom; Alex Deucher
Cc: amd-gfx list
Subject: RE: [PATCH] drm/amd/amdgpu: Add PCI info to gca_config debugfs
Whoops, sorry, I glanced quickly and thought
I am grabbing revision. Unless there's some other PCI revision value I'm
missing :-)
Tom
From: Alex Deucher
Sent: Wednesday, January 18, 2017 13:40
To: Tom St Denis
Cc: amd-gfx list; StDenis, Tom
Subject: Re: [PATCH] drm/amd/amdgpu: Add P
It'd be nicer to move these into the PP_SENSORS framework and then print them
from pm_info.
But other than that I don't have any strong objections to these patches.
Tom
From: amd-gfx on behalf of Donny Yang
Sent: Friday, January 13, 2017 03:58
To: amd-gfx@
Reviewed-by: Tom St Denis
From: amd-gfx on behalf of Huang Rui
Sent: Tuesday, January 10, 2017 21:30
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom; Huang, Ray
Subject: [PATCH] drm/amdgpu: fix typo of CGTS
Fixes: 9e8590861e9 ('drm/amdgpu: add parse
Hi Ray,
Small nit but I saw this in the output
+ {AMD_CG_SUPPORT_GFX_CGTS, "Graphics Coarse Grain Tree Shader Light
Sleep"},
+ {AMD_CG_SUPPORT_GFX_CGTS_LS, "Graphics Coarse Grain Tree Shader Light
Sleep"},
The first you probably want to remove "Light Sleep" from otherwise the out
___________
From: amd-gfx on behalf of StDenis, Tom
Sent: Monday, January 9, 2017 11:58
To: Deucher, Alexander; Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: refine vce3.0 initialize.
Just a heads up there is a CG/PG regression. On the tip of 4.7
Just a heads up there is a CG/PG regression. On the tip of 4.7 I can encode
with cg/pg disabled but with it enabled it locks up.
I'll try to bisect.
Tom
From: amd-gfx on behalf of Deucher,
Alexander
Sent: Monday, January 9, 2017 09:34
To: Zhu, Rex; amd-gf
er up API will
take it.
Tom
From: Koenig, Christian
Sent: Monday, January 9, 2017 09:45
To: Huang, Ray; StDenis, Tom
Cc: Deucher, Alexander; amd-gfx@lists.freedesktop.org; Zhu, Rex; Mao, David;
Fu, Ping; Zhang, Hawking; Kuehling, Felix
Subject: Re: [PART1 PATC
On my Carrizo, I have to NAK since monitoring the clocks I see GFX and VCE
pegged high on a setup with a staging kernel .
Doing a test signal encode I see 1000 fences/sec being handled and GFX_POWER
throttles (not idle or full) . I don't see VCE load from SRBM_STATUS2 though
...
Something i
Yup it's held by both amdgpu_dpm_enable_uvd() and amdgpu_dpm_enable_vce()
Tom
From: Koenig, Christian
Sent: Monday, January 9, 2017 05:32
To: Huang, Ray; Deucher, Alexander; amd-gfx@lists.freedesktop.org; StDenis, Tom
Cc: Zhu, Rex; Mao, David; Fu, Ping;
There's already the adev->pm.mutex which is held while gating/ungating blocks.
There's no need for a second mutex right?
Tom
From: amd-gfx on behalf of Christian
König
Sent: Friday, January 6, 2017 07:52
To: Huang, Ray; Deucher, Alexander; amd-gfx@lists.fre
It was added late last year so that debugfs mmio could read vce/uvd registers
without triggering a race condition between transitions.
Cheers,
Tom
From: Koenig, Christian
Sent: Friday, January 6, 2017 08:45
To: StDenis, Tom; Huang, Ray; Deucher, Alexander
Some of them are part of AON tiles but are unstable during PM switches. That's
why the debugfs mmio entry supports a PM lock.
So they might be readable while powered off but unstable if the firmware is in
the middle of a PM switch.
Tom
From: amd-gfx on beh
Hi Emil,
Thing is, with all due respect, the vast majority of DC contributions are
likely to come from AMD at the moment. The code is in high flux and requires
knowledge about the hardware that the public does not possess.
That's not to say that submissions aren't welcomed. But on code that
d one last commit to the
amd-temp-soc15 branch.
Cheers,
Tom
From: Wentland, Harry
Sent: Friday, December 16, 2016 10:02
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] drm/amd/amdgpu: De-numberify golden SI registers
Nice. Do
Hi Alex,
I'll wait on pushing it until I hear back from one of them.
Cheers,
Tom
From: Alex Deucher
Sent: Wednesday, December 7, 2016 12:32
To: StDenis, Tom
Cc: Edward O'Callaghan; amd-gfx@lists.freedesktop.org
Subject: Re: GPR read support via d
Thanks.
Could use a RB/NAK from Christian or Alex when they get the time :-)
Tom
From: amd-gfx on behalf of Edward
O'Callaghan
Sent: Tuesday, December 6, 2016 17:15
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Subject: Re: GPR read support via debugfs (v
7;Callaghan
Sent: Monday, December 5, 2016 14:59
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH 1/3] drm/amd/amdgpu: Add debugfs support for reading GPRs
Hi Tom,
On 12/06/2016 05:36 AM, Tom St Denis wrote:
> Implemented for SGPRs for GFX v8 initially.
>
Hi Rex,
Given how often we diagnose problems by disabling PG/CG I'd have to offer my
NAK to this patch since it prevents me from disabling PG via the command line.
Any reason you want to make it permanently enabled?
Tom
From: amd-gfx on behalf of Rex Zhu
Keep in mind this is the older "method" since SI and up have a unified
pm_status.
Tom
From: amd-gfx on behalf of Alex Deucher
Sent: Friday, November 25, 2016 18:30
To: Zhu, Rex
Cc: amd-gfx list
Subject: Re: [PATCH] drm/amdgpu: fix bug uvd status not true in
if PP is being sketchy can you force the performance to low (e.g. manual)
instead of auto and see if keeping at lower clocks helps keep it stable?
Just an idea to try.
Tom
From: amd-gfx on behalf of Bernhard
Froemel
Sent: Friday, November 25, 2016 11:15
To
I just tried it on my Carrizo this morning (after sending out the dce6 patch)
and everything seems peachy.
Tom
From: amd-gfx on behalf of Deucher,
Alexander
Sent: Monday, November 14, 2016 11:56
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subjec
Kinda buried trying to sort out the gfx6 boot failure but if someone can just
email as an attachment the 5 patches I'll test them on my Stoney system (my CZ
system is being used by the Tahiti board...)
Tom
From: amd-gfx on behalf of Deucher,
Alexander
Sent:
You could do that as
WREG32_FIELD(UVD_CGC_GATE, REGS, 0);
Unless you need 'data' somewhere else in the function.
Tom
From: amd-gfx on behalf of Rex Zhu
Sent: Wednesday, November 9, 2016 05:08
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH
Could we provide fault information through a ring buffer and a debugfs or drm
ioctl interface?
Tom
From: amd-gfx on behalf of Alex Deucher
Sent: Monday, November 7, 2016 13:35
To: Edward O'Callaghan; Nicolai Hähnle; Marek Olsak
Cc: Michel Dänzer; amd-gfx lis
Reviewed-by: Tom St Denis
From: amd-gfx on behalf of Alex Deucher
Sent: Wednesday, October 19, 2016 13:10
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: explicitly set pg_flags for ST
No need to retain previous settings
the patch was part of a series that was blocking other
work and there wasn't sufficient cause to NAK it.
Tom
From: Michel Dänzer
Sent: Tuesday, October 18, 2016 23:49
To: StDenis, Tom; Christian König
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH]
Hi Alex,
Sounds like a plan since I want to add a few fields anyways.
Tom
From: Deucher, Alexander
Sent: Friday, October 14, 2016 09:33
To: StDenis, Tom; Nicolai Hähnle
Cc: amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH 1/3] drm/amd/amdgpu: Add wave reader
ext branches since he manages them.
Tom
From: Ernst Sjöstrand
Sent: Friday, October 14, 2016 09:20
To: StDenis, Tom
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] amdgpu: Fix failing boot after support for third vce ring
Means the drm pull request for
hortly [😊]
Tom
From: Ernst Sjöstrand
Sent: Friday, October 14, 2016 09:15
To: StDenis, Tom
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] amdgpu: Fix failing boot after support for third vce ring
I'm testing both drm-next-4.9 and drm-next-4.9-wip from
ps.
Tom
From: Ernst Sjöstrand
Sent: Friday, October 14, 2016 09:05
To: StDenis, Tom
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] amdgpu: Fix failing boot after support for third vce ring
Yes, the 6f0359ff73076483902de0c17f9649bf55651e2a I'm referring to i
Does your tree have
2f3d686d0ee95332d169c7b6788bb2d9f5ad
780605db12c52f2c22d4d2cc05ceb7d2a9d55579
in it? Those are fixes for when the third ring were added.
Tom
From: amd-gfx on behalf of Ernst
Sjöstrand
Sent: Friday, October 14, 2016 08:49
To: amd-
Tom
From: Nicolai Hähnle
Sent: Friday, October 14, 2016 03:25
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH 1/3] drm/amd/amdgpu: Add wave reader to debugfs
On 11.10.2016 21:18, Tom St Denis wrote:
> Currently suppor
Hi Alex,
No problem I'll submit that tomorrow morning.
Cheers,
Tom
From: Deucher, Alexander
Sent: Thursday, October 13, 2016 15:19
To: 'Tom St Denis'; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: RE: [PATCH] drm/radeon/si_dpm:
se * if you don't want to and furthermore
I'm already using the write debugfs content (to debug waveforms).
Tom
From: Michel Dänzer
Sent: Tuesday, October 11, 2016 20:34
To: StDenis, Tom; Christian König
Cc: amd-gfx@lists.freedesktop.org
Subject: Re:
Yup, with it I get a normal modprobe.
Can add my
Ack-By: Tom St Denis
From: amd-gfx on behalf of Christian
König
Sent: Tuesday, October 11, 2016 13:33
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix broken VCE startup in phys mode
From:
It dies on my Tonga just FYI (save you some trouble).
Tom
From: amd-gfx on behalf of Christian
König
Sent: Tuesday, October 11, 2016 09:26
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 8/8] drm/amdgpu: move align_mask and nop into ring f
They are constant as well.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
:04 04 a8f2ca9290985991b3cc37cbeb902f060573fdbb
2309b176a1d4ff9e59eaf25688b5db6eb9759dd0 M drivers
From: amd-gfx on behalf of StDenis, Tom
Sent
Hi Andy,
Ha, I'm 1 step away (that was my last bad commit) from determining that. I'll
finish up for formality sake but I suspect that is the bad one.
Cheers,
Tom
From: Andy Furniss
Sent: Tuesday, October 11, 2016 09:10
To: StDenis, To
Tom
From: Christian König
Sent: Tuesday, October 11, 2016 08:30
To: StDenis, Tom; Michel Dänzer
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/amdgpu: Allow broadcast on debugfs read (v2)
I briefly remember reading in some hardware doc that this actually has a
defined behavior.
I
Actually NAK that, I don't have the cache patch internally. So my Tonga crash
is something else.
Tom
From: amd-gfx on behalf of StDenis, Tom
Sent: Tuesday, October 11, 2016 08:11
To: Andy Furniss; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alex
ke to get the 2nd patch through though as it makes the write
side of the mmio reg complimentary (e.g. bank selection/pm lock).
Cheers,
Tom
From: Christian König
Sent: Tuesday, October 11, 2016 08:11
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PA
Yup, my Tonga system dies on modprobe with the tip of stg-4.7 this morning.
Tom
From: amd-gfx on behalf of Andy Furniss
Sent: Tuesday, October 11, 2016 08:07
To: Alex Deucher; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 4/4] drm/a
That actually makes sense. It came up because mmPA_SC_RASTER_CONFIG (and _1)
are read by libdrm with a selection of 0/*/* for se/sh/instance so I wanted to
be able to reproduce that via the debugfs interface for testing.
But ya, if you use the broadcast bit who are you reading from then ... hm
Christian König
Sent: Monday, October 10, 2016 09:49
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] drm/amd/amdgpu: Make debugfs write compliment read
Would it hurt us to always take the looks (both the pm as well as grbm idx
lock)?
I don't think that
The pg lock is needed to read pgfsm registers so you wouldn't normally take
grbm too.
Tom
Original message
From: Christian König
Date: 2016-10-10 09:49 (GMT-05:00)
To: Tom St Denis , amd-gfx@lists.freedesktop.org
Cc: "StDenis, Tom"
Subject: Re: [PATCH] drm/a
Shouldn't there be a version bump if you're adding a new command to the ioctl?
Tom
From: amd-gfx on behalf of Alex Deucher
Sent: Friday, October 7, 2016 14:28
To: amd-gfx@lists.freedesktop.org; Fang, Peter; Zhang, Boyuan
Cc: Deucher, Alexander
Subject: [PATCH
Tonga (with the 5dw patch reverted) on the tip of
stg-4.7. I have yet to test a polaris asic though...
Tom
From: Jeremy Newton
Sent: Thursday, October 6, 2016 10:07
To: StDenis, Tom
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: Issue with amd-staging-4.7 on rx4
If I read this correctly you reverted the commit which enables UVD PG on Tonga?
I can't see how that impacts Polaris at all.
If I had to guess it's a dGPU state issue. I've had on occasion to resort to
cold reboots to bisect the kernel because the GPU firmware can get into states
that aren't
That revert works on my FIJI and Tonga test setups.
Reviewed-by: Tom St Denis
From: amd-gfx on behalf of Christian
König
Sent: Wednesday, October 5, 2016 05:08
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: revert "exclude 5dw digest for entr
Thanks. I'll try it on FIJI next. Hopefully MGCG isn't needed for at least
basic tile power control.
Tom
From: amd-gfx on behalf of Deucher,
Alexander
Sent: Friday, September 30, 2016 11:10
To: 'Tom St Denis'; amd-gfx@lists.freedesktop.org
Subject: RE: Ena
In this block of code I'm wondering if the mutex_destroy should be hoisted out
of the inner loop?
static void amdgpu_ctx_fini(struct amdgpu_ctx *ctx)
{
struct amdgpu_device *adev = ctx->adev;
unsigned i, j;
if (!adev)
return;
for (i = 0; i < AMD
Hmm, I wonder if this fix CP power gating issues ... on Carrizo/Stoney...
From: amd-gfx on behalf of Monk Liu
Sent: Wednesday, September 28, 2016 04:36
To: amd-gfx@lists.freedesktop.org
Cc: Min, Frank
Subject: [PATCH 8/9] drm/amdgpu:wptr poll address of gfx8 is
Better would be to add them to a bitmask header and then use REG_GET_FIELD() so
it's nice and clean looking.
Tom
From: amd-gfx on behalf of Christian
König
Sent: Tuesday, September 27, 2016 08:52
To: Edward O'Callaghan; amd-gfx@lists.freedesktop.org
Subject:
I'm reading through the amdgpu_vm.c to try and see if the patch is correct but
I'm not that familiar with the VM side of things. It seems to boil down to
calling params->func() with a new dst value of NULL but that's where I'm
stopped at the moment since I don't know what func() is. Nothing up
Looks correct and consistent with the other DCE drivers.
Reviewed-by: Tom St Denis
From: amd-gfx on behalf of Alex Deucher
Sent: Monday, September 19, 2016 12:15
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/dce6: fix o
Yup. I misread your comment thinking there was another datastructure you'd
rather I put the callback in.
Cheers,
Tom
From: Deucher, Alexander
Sent: Monday, September 19, 2016 11:55
To: StDenis, Tom; Alex Deucher
Cc: amd-gfx list
Subject: RE: [PATCH 1/2
Hi Alex,
Would you prefer I re-write #1 to avoid churn in the tree?
Cheers,
Tom
From: Alex Deucher
Sent: Monday, September 19, 2016 11:53
To: Tom St Denis
Cc: amd-gfx list; StDenis, Tom
Subject: Re: [PATCH 1/2] drm/amd/powerplay: Add read_sensor() callback
Hi all,
Edward reviewed them but I'd like an AMD'er RB/ACK/NAK as well on the updated
series I posted last week please.
https://lists.freedesktop.org/archives/amd-gfx/2016-September/002359.html
Thanks,
Tom
___
amd-gfx mailing list
amd-gfx@lists.fr
if they tried to read more than a page it
would just fail anyways).
Tom
From: Edward O'Callaghan
Sent: Friday, September 16, 2016 01:24
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] drm/amd/amdgpu: Add sensors debugfs
Thanks. I'm thinking I might merge this with Patch #1 from the other series
just to make life easier for everyone.
Tom
From: amd-gfx on behalf of Edward
O'Callaghan
Sent: Friday, September 16, 2016 01:16
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Subje
ptember 15, 2016 11:10
To: StDenis, Tom; Christian König; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amd/amdgpu: Add sensors debugfs support
FWIW, temperature and fan are already exposed via standard hwmon interfaces.
It might be better to use standard interfaces for some of these thin
From: Christian König
Sent: Thursday, September 15, 2016 09:29
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] drm/amd/amdgpu: Add sensors debugfs support
Am 15.09.2016 um 15:22 schrieb Tom St Denis:
> This patch adds a callback to powerplay which
> reads
Yup, that looks better. My apologies. Guess that's the downside of having
assertions for enable and disable in the same driver.
Reviewed-by: Tom St Denis
From: amd-gfx on behalf of Alex Deucher
Sent: Wednesday, September 14, 2016 09:47
To: amd-gfx@lists.f
Attached image of scan-view's report. Basically the variable "sem" is free'ed
but then used as sem->next in the for loop. Should use safe version of macro.
Tom
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailm
Hi Alex,
Would love to but unfortunately I don't have a tahiti_le (or any SI) part to
test it on.
Cheers,
Tom
From: Deucher, Alexander
Sent: Wednesday, September 7, 2016 10:45
To: 'Tom St Denis'; amd-gfx@lists.freedesktop.org
Cc: StDenis,
d-gfx/2016-September/002042.html
Tom
From: Christian König
Sent: Wednesday, September 7, 2016 08:33
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH] drm/amd/amdgpu: Remove double lock from gfx v6
Am 07.09.2016 um 14:07 schrie
ead anywhere in the
kernel for instance.
Tom
From: Christian König
Sent: Friday, September 2, 2016 08:06
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/3] drm/amd/amdgpu: Various tidy ups for gfx6
We could merge those to reduce the
The "adev" variable must be in scope when using the RREG32/WREG32 (and
derivatives) macros.
Tom
From: Edward O'Callaghan
Sent: Thursday, September 1, 2016 23:22
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PAT
Sent: Thursday, September 1, 2016 13:59
To: Tom St Denis; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: Re: [PATCH 3/3] drm/amd/amdgpu: Various tidy ups for gfx6
Am 01.09.2016 um 19:44 schrieb Tom St Denis:
> Various whitespace and logical simplifications for gfx6.
>
> Signed-off-by
Patch #3 is correct but missing the SDMA0 duplicate which I amended locally. I
only noticed it after I hit send.
From: Deucher, Alexander
Sent: Friday, August 26, 2016 12:49
To: StDenis, Tom; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH 3/3] drm/amd
o: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH 3/3] drm/amd/powerplay: Only load MEC firmware once on Stoney
Only load the MEC1 firmware once in the Carrizo SMU manager
driver.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 5 +
1 file
Still on the topic of the smu code I see (in cz_smu_construct_toc_for_bootup())
cz_smu_populate_single_ucode_load_task(smumgr,
CZ_SCRATCH_ENTRY_UCODE_ID_CP_MEC_JT1, false);
if (smumgr->chip_id == CHIP_STONEY)
cz_smu_populate_single_ucode_load_task(smumgr,
CZ_SCRATCH_ENTRY_UCODE_ID_CP_MEC_JT1, fal
Thanks. I like v4 better because it prints a message if the initial load op
fails. I'll push that.
Tom
From: Deucher, Alexander
Sent: Friday, August 26, 2016 11:15
To: 'Tom St Denis'; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject:
Thanks. I sent out a v2 where it adds a check to the load call as well.
Tom
From: Deucher, Alexander
Sent: Friday, August 26, 2016 10:42
To: 'Tom St Denis'; amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: RE: [PATCH] drm/amd/powerplay:
In the function
static int cz_check_fw_load_finish(struct pp_smumgr *smumgr,
uint32_t firmware);
On line 198 of powerplay/smumgr/cz_smumgr.c there is an unconditional return in
the middle of the function. Is that an error or is the code after it truly
dead code?
Tom
___
Patch #2 has a typo should be 'j' in the loop.
I'll resend that patch in a second.
Tom
From: Tom St Denis
Sent: Thursday, August 25, 2016 13:10
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH 2/3] drm/amd/amdgpu: Clean up
Sorry, disregard. The pointer doesn't point inside the struct. That part of
the patch is fine.
Tom
From: amd-gfx on behalf of StDenis, Tom
Sent: Friday, August 19, 2016 07:30
To: Yu, Qiang; xorg-de...@lists.x.org
Cc: mic...@daenzer.net; emil.l
In ms_pageflip_free() you cannot free the parent structure before freeing
things it points to. That's undefined behaviour.
Tom
From: amd-gfx on behalf of Qiang Yu
Sent: Friday, August 19, 2016 08:50
To: xorg-de...@lists.x.org
Cc: Yu, Qiang; mic...@daenzer.net
Sent: Thursday, August 18, 2016 12:07
To: StDenis, Tom; Deucher, Alexander
Cc: amd-gfx list
Subject: Re: tidy'ing up cz_hwmgr.c
Either way like I said I'm not strongly motivated to change it just caught my
attention.
Well if you have time it would be really cool if you could a) identify s
x27;m not strongly motivated to change it just caught my
attention.
Cheers,
Tom
From: Deucher, Alexander
Sent: Thursday, August 18, 2016 11:50
To: StDenis, Tom; Alex Deucher
Cc: Christian König; amd-gfx list
Subject: RE: tidy'ing up cz_hwmgr.c
IIRC,
fd4044
Which is exactly what you'd expect. I'm not strongly advocating we change the
PP code just noting it's not really clear that it's correct from a first
reading and in theory would be better with [0].
Tom
From: Alex Deucher
Sent: Thu
101 - 200 of 229 matches
Mail list logo
