On 2018-06-07 03:10 AM, Christian König wrote:
Am 06.06.2018 um 20:59 schrieb James Zhu:
Vega20 UVD Firmware has a new version naming convention:
[31, 30] for encode interface major
[29, 24] for encode interface minor
[15, 8] for firmware revision
[7, 0] for hardware family id
On 2018-06-07 03:26 PM, Mike Lothian wrote:
> It seems messy having to create a whole xorg.conf just for one parameter
Not sure I can agree, anyway it's the same whether the file is called
/etc/X11/xorf.conf or /etc/X11/xorg.conf.d/foobar . :)
--
Earthling Michel Dänzer |
On 2018-05-31 08:05 PM, Christian König wrote:
> Am 30.05.2018 um 18:03 schrieb Harry Wentland:
>> On 2018-05-30 06:17 AM, Shirish S wrote:
>>> This patch fixes the warning messages that are caused due to calling
>>> sleep in atomic context as below:
>>>
>>> BUG: sleeping function called from
On 2018-06-07 08:38 AM, Leo Liu wrote:
On 06/07/2018 03:10 AM, Christian König wrote:
Am 06.06.2018 um 20:59 schrieb James Zhu:
Vega20 UVD Firmware has a new version naming convention:
[31, 30] for encode interface major
[29, 24] for encode interface minor
[15, 8] for firmware
On 06/07/2018 03:10 AM, Christian König wrote:
Am 06.06.2018 um 20:59 schrieb James Zhu:
Vega20 UVD Firmware has a new version naming convention:
[31, 30] for encode interface major
[29, 24] for encode interface minor
[15, 8] for firmware revision
[7, 0] for hardware family id
It seems messy having to create a whole xorg.conf just for one parameter
On Thu, 7 Jun 2018 at 08:31 Michel Dänzer wrote:
> On 2018-06-07 09:22 AM, Mike Lothian wrote:
> > Hi
> >
> > Is there a way to set depth using a xorg.conf.d snippet rather than
> > creating an xorg.conf?
>
> Sure (the
Ok. Abandoning the series.
I am working on identifying the root cause and will post the new patch soon.
Regards
Pratik
-Original Message-
From: Koenig, Christian
Sent: Wednesday, June 6, 2018 3:17 PM
To: Vishwakarma, Pratik ;
amd-gfx@lists.freedesktop.org; alexdeuc...@gmail.com;
On 2018-06-07 10:44 AM, Michel Dänzer wrote:
> On 2018-05-31 08:05 PM, Christian König wrote:
>> Am 30.05.2018 um 18:03 schrieb Harry Wentland:
>>> On 2018-05-30 06:17 AM, Shirish S wrote:
This patch fixes the warning messages that are caused due to calling
sleep in atomic context as
Add/update function level documentation and add reference to amdgpu_irq.c
in amdgpu.rst
Signed-off-by: Slava Abramov
---
Documentation/gpu/amdgpu.rst| 9 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 102 ++--
2 files changed, 80 insertions(+), 31
From: David Panariti
SQ can generate interrupts on EDC/ECC errors and this struct controls
how the interrupt is handled. The guts are filled in in the
gf_v_.c files.
v2:
Rebase.
Signed-off-by: David Panariti
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
1 file changed, 1 insertion(+)
diff
From: David Panariti
SQ can generate interrupts and installs the ISR to
handle the SQ interrupts.
Add parsing SQ data in interrupt handler.
v2:
Remove CZ only limitation.
Rebase.
Signed-off-by: David Panariti
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 109
On 2018-06-06 01:03 PM, Michel Dänzer wrote:
On 2018-06-06 06:01 PM, Michel Dänzer wrote:
On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
From: "Leo (Sunpeng) Li"
This ended up being different enough from v2 to warrant a new patchset. Per
Michel's suggestions, there have been various
This patch is extends the usage of WB in
gfx8's ib test which was originally
implemented in the below upstream patch:
"ed9324a drm/amdgpu: change gfx9 ib test to use WB"
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 35 +--
1 file changed,
On 2018年06月08日 12:54, Shirish S wrote:
This patch is extends the usage of WB in
gfx8's ib test which was originally
implemented in the below upstream patch:
"ed9324a drm/amdgpu: change gfx9 ib test to use WB"
Signed-off-by: Shirish S
Reviewed-by: Chunming Zhou
---
For buffer object that has shadow buffer, need twice commands.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index
On 06/06/18 13:18, Colin King wrote:
> From: Colin Ian King
>
> The current use of result is or'ing in values and checking for
> a non-zero result, however, result is not initialized to zero
> so it potentially contains garbage to start with. Fix this by
> initializing it to the first return
On Wed, Jun 06, 2018 at 10:26:15AM +0200, Christian König wrote:
> Well what did you do to trigger the lockup? Looks like an application send
> something to the hardware to crash the GFX block.
So what I observed was (in that order): machine was building a kernel so
was busy, X didn't respond for
From: Colin Ian King
The current use of result is or'ing in values and checking for
a non-zero result, however, result is not initialized to zero
so it potentially contains garbage to start with. Fix this by
initializing it to the first return from the call to
Vega20 UVD Firmware has a new version naming convention:
[31, 30] for encode interface major
[29, 24] for encode interface minor
[15, 8] for firmware revision
[7, 0] for hardware family id
Inside kernel log UVD firmware Version: 1.1.2 (denote major.minor.revision)
Signed-off-by: James Zhu
Am 06.06.2018 um 20:59 schrieb James Zhu:
Vega20 UVD Firmware has a new version naming convention:
[31, 30] for encode interface major
[29, 24] for encode interface minor
[15, 8] for firmware revision
[7, 0] for hardware family id
Inside kernel log UVD firmware Version: 1.1.2 (denote
Hi
Is there a way to set depth using a xorg.conf.d snippet rather than
creating an xorg.conf?
Cheers
Mike
On Wed, 6 Jun 2018 at 17:01 Michel Dänzer wrote:
>
> Hi Leo,
>
>
> On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
> > From: "Leo (Sunpeng) Li"
> >
> > This ended up being different
On 2018-06-07 09:22 AM, Mike Lothian wrote:
> Hi
>
> Is there a way to set depth using a xorg.conf.d snippet rather than
> creating an xorg.conf?
Sure (the xorg.conf.d snippets are simply concatenated together with
xorg.conf, so anything can go in either of them), but it's the wrong way
to do
On 2018-06-06 07:03 PM, Michel Dänzer wrote:
> On 2018-06-06 06:01 PM, Michel Dänzer wrote:
>> On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
>>> From: "Leo (Sunpeng) Li"
>>>
>>> This ended up being different enough from v2 to warrant a new patchset. Per
>>> Michel's suggestions, there have
Am Mittwoch, den 06.06.2018, 10:48 -0700 schrieb Eric Anholt:
> Between creation and queueing of a job, you need to prevent any other
> job from being created and queued. Otherwise the scheduler's fences
> may be signaled out of seqno order.
>
> v2: move mutex unlock to the error label.
>
> >
On Wed, Jun 06, 2018 at 01:18:31PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The current use of result is or'ing in values and checking for
> a non-zero result, however, result is not initialized to zero
> so it potentially contains garbage to start with. Fix this by
> initializing it
25 matches
Mail list logo
