Hi,
> >>> We are working with new laptops that have the AMD Ravenl Ridge
> >>> chipset with this `/proc/cpuinfo`
> >>> https://gist.github.com/mschiu77/b06dba574e89b9a30cf4c450eaec49bc
> >>>
> >>> With the latest kernel 4.15, there're lots of different
> >>> panics/oops during boot so no c
On Mon, Feb 19, 2018 at 2:33 PM, Pavel Machek wrote:
> On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
>> On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
>> >
>> >
>> > Le 17/02/2018 à 22:19, Pavel Machek a écrit :
>> > >
>> > > Fix double ;;'s in code.
>> > >
>> > > Signed-off-
On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
> On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
> >
> >
> > Le 17/02/2018 à 22:19, Pavel Machek a écrit :
> > >
> > > Fix double ;;'s in code.
> > >
> > > Signed-off-by: Pavel Machek
> >
> > A summary of the files modified o
On Wed, Feb 14, 2018 at 9:46 AM, Corentin Labbe wrote:
> All thoses headers are not used by any source files.
> Lets just remove them.
>
> Signed-off-by: Corentin Labbe
Applied. Thanks!
Alex
> ---
> .../gpu/drm/amd/powerplay/inc/polaris10_ppsmc.h| 412
> -
> drivers/
On Mon, Feb 19, 2018 at 05:29:46PM +0100, Christian König wrote:
> Am 19.02.2018 um 17:15 schrieb Daniel Vetter:
> > On Mon, Feb 19, 2018 at 04:41:55PM +0100, Christian König wrote:
> > > Am 19.02.2018 um 16:24 schrieb Daniel Vetter:
> > > > On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König
On Mon, Feb 19, 2018 at 04:40:40PM +0100, Christian König wrote:
> Am 19.02.2018 um 16:32 schrieb Daniel Vetter:
> > On Fri, Feb 16, 2018 at 10:26:34AM +0100, Christian König wrote:
> > > We use our own backing store and don't need the shmem file.
> > >
> > > Signed-off-by: Christian König
> > I
Am 19.02.2018 um 17:15 schrieb Daniel Vetter:
On Mon, Feb 19, 2018 at 04:41:55PM +0100, Christian König wrote:
Am 19.02.2018 um 16:24 schrieb Daniel Vetter:
On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote:
amdgpu needs to verify if userspace sends us valid addresses and the sim
On Mon, Feb 19, 2018 at 04:41:55PM +0100, Christian König wrote:
> Am 19.02.2018 um 16:24 schrieb Daniel Vetter:
> > On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote:
> > > amdgpu needs to verify if userspace sends us valid addresses and the
> > > simplest
> > > way of doing this is
Any possibility of contacting the Windows driver people to see how
they managed to work around the bios issues?
Well I have strong doubts that this our windows people are actually
involved in this. This could be fixed our worked around by a motherboard
driver, but not by the graphics driver.
A
Am 19.02.2018 um 16:24 schrieb Daniel Vetter:
On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote:
amdgpu needs to verify if userspace sends us valid addresses and the simplest
way of doing this is to check if the buffer object is locked with the ticket
of the current submission.
Cl
On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
>
>
> Le 17/02/2018 à 22:19, Pavel Machek a écrit :
> >
> > Fix double ;;'s in code.
> >
> > Signed-off-by: Pavel Machek
>
> A summary of the files modified on top of the patch would help understand
> the impact.
>
> A maybe t
Am 19.02.2018 um 16:32 schrieb Daniel Vetter:
On Fri, Feb 16, 2018 at 10:26:34AM +0100, Christian König wrote:
We use our own backing store and don't need the shmem file.
Signed-off-by: Christian König
I thought ttm swaps to the shmem when under memory pressure. Or does it
allocate it's own s
On Fri, Feb 16, 2018 at 10:26:34AM +0100, Christian König wrote:
> We use our own backing store and don't need the shmem file.
>
> Signed-off-by: Christian König
I thought ttm swaps to the shmem when under memory pressure. Or does it
allocate it's own shmem file for that?
-Daniel
> ---
> drive
On Thu, Feb 15, 2018 at 03:19:42PM +0100, Christian König wrote:
> amdgpu needs to verify if userspace sends us valid addresses and the simplest
> way of doing this is to check if the buffer object is locked with the ticket
> of the current submission.
>
> Clean up the access to the ww_mutex inter
On Mon, Feb 19, 2018 at 8:57 AM, Christian König
wrote:
> Instead of the pin/unpin callback implement the attach/detach ones.
>
> Functional identical, but allows us access to the attachment.
>
> Signed-off-by: Christian König
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/a
To be able to use DRI_PRIME with amdgpu and i915 we add all our fences
only as exclusive ones.
Disable that behavior when sharing between amdgpu itself cause it
hinders concurrent execution.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 31 --
Instead of the pin/unpin callback implement the attach/detach ones.
Functional identical, but allows us access to the attachment.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 --
drivers/gpu/drm/amd/amdgpu/a
Hi Joseph,
as a band aid you can try the attached patch. It should at least fix the
crash at hand and allow amdgpu to continue with the boot process.
Regards,
Christian.
Am 19.02.2018 um 14:13 schrieb Christian König:
Hi Joseph,
and here is the root cause of the problem:
0b:00.0 VGA compati
Hi Joseph,
and here is the root cause of the problem:
0b:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] (rev ef) (prog-if 00
[VGA controller])
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device 0b31
Control: I/O- Mem-
amdgpu needs to verify if userspace sends us valid addresses and the simplest
way of doing this is to check if the buffer object is locked with the ticket
of the current submission.
Clean up the access to the ww_mutex internals by providing a function
for this and extend the check to the thread ow
This solves the problem that when we swapout a BO from a domain we
sometimes couldn't make room for it because holding the lock blocks all
other BOs with this reservation object.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 33 -
1 file change
Instead of accessing ww_mutex internals directly use the provided
function to check if the ww_mutex was indeed locked by the current
command submission.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
This avoids problems when BOs are evicted but directly moved back into
the domain from other threads.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm
On Fri, Feb 16, 2018 at 02:40:11PM +, Chris Wilson wrote:
> Quoting Chunming Zhou (2018-02-09 02:44:08)
> > it will be used to check if the driver needs swiotlb
> > v2: Don't use inline, instead, move function to drm_memory.c (Mechel
> > Daenzer )
> >
> > Change-Id: Idbe47af8f12032d4803bb3d47
Fix double ;;'s in code.
Signed-off-by: Pavel Machek
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 9d27331..ec12fe1 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -373,7 +373,7 @@ static void arc_chk_core_config(void)
{
struct cpuinfo_arc *
Le 17/02/2018 à 22:19, Pavel Machek a écrit :
Fix double ;;'s in code.
Signed-off-by: Pavel Machek
A summary of the files modified on top of the patch would help
understand the impact.
A maybe there should be one patch by area, eg one for each arch specific
modif and one for drivers/ a
26 matches
Mail list logo
