On Fri, Sep 6, 2019 at 3:16 PM Marek Olšák wrote:
>
> + dri-devel
>
> On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote:
>>
>> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc passing
>> it to user space
>> instead of unused DRM driver name descriptor.
>>
>> Change-Id: I809f6
+ dri-devel
On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote:
> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc
> passing it to user space
> instead of unused DRM driver name descriptor.
>
> Change-Id: I809f6d3e057111417efbe8fa7cab8f0113ba4b21
> Signed-off-by: Sonny Jiang
Thanks! Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Yang, Philip
Sent: 2019年9月7日 1:32
To: amd-gfx@lists.freedesktop.org
Cc: Yang, Philip
Subject: [PATCH] drm/amdgpu: check if nbio->ras_if exist
To avoid NULL function pointer access. This ha
To avoid NULL function pointer access. This happens on VG10, reboot
command hangs and have to power off/on to reboot the machine. This is
serial console log:
[ OK ] Reached target Unmount All Filesystems.
[ OK ] Reached target Final Step.
Starting Reboot...
[ 305.696271] systemd-shut
On Fri, 2019-09-06 at 14:27 +0300, Ville Syrjälä wrote:
> On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza
> wrote:
> > From: Dhinakaran Pandiyan
> >
> > Currently we restrict the number of encoders that can be linked to
> > a connector to 3, increase it to match the maximum number
Hello, Daniel.
On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > Hmm... what'd be the fundamental difference from slab or socket memory
> > which are handled through memcg? Is system memory used by GPUs have
> > further global restrictions in addition to the amount of physical
>
Hello, Daniel.
On Fri, Sep 06, 2019 at 05:36:02PM +0200, Daniel Vetter wrote:
> Block devices are a great example I think. How do you handle the
> partitions on that? For drm we also have a main minor interface, and
cgroup IO controllers only distribute hardware IO capacity and are
blind to parti
On Fri, Sep 6, 2019 at 5:29 PM Tejun Heo wrote:
>
> Hello,
>
> On Wed, Sep 04, 2019 at 10:54:34AM +0200, Daniel Vetter wrote:
> > Anyway, I don't think reusing the drm_minor registration makes sense,
> > since we want to be on the drm_device, not on the minor. Which is a bit
> > awkward for cgroup
On Fri, Sep 6, 2019 at 5:23 PM Tejun Heo wrote:
>
> Hello, Daniel.
>
> On Tue, Sep 03, 2019 at 09:48:22PM +0200, Daniel Vetter wrote:
> > I think system memory separate from vram makes sense. For one, vram is
> > like 10x+ faster than system memory, so we definitely want to have
> > good control o
Hello,
On Wed, Sep 04, 2019 at 10:54:34AM +0200, Daniel Vetter wrote:
> Anyway, I don't think reusing the drm_minor registration makes sense,
> since we want to be on the drm_device, not on the minor. Which is a bit
> awkward for cgroups, which wants to identify devices using major.minor
> pairs.
Hello, Daniel.
On Tue, Sep 03, 2019 at 09:48:22PM +0200, Daniel Vetter wrote:
> I think system memory separate from vram makes sense. For one, vram is
> like 10x+ faster than system memory, so we definitely want to have
> good control on that. But maybe we only want one vram bucket overall
> for t
The table grows quickly during debug/development effort when
multiple RAS errors are injected. Allow to avoid this by setting
table header back to empty if needed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
Ping...
Review 2. [PATCH] drm: add drm device name (Jiang, Sonny), please.
Thanks,
Sonny
From: amd-gfx on behalf of
amd-gfx-requ...@lists.freedesktop.org
Sent: Tuesday, September 3, 2019 9:17 PM
To: amd-gfx@lists.freedesktop.org
Subject: amd-gfx Digest, Vol 40
On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza wrote:
> From: Dhinakaran Pandiyan
>
> Currently we restrict the number of encoders that can be linked to
> a connector to 3, increase it to match the maximum number of encoders
> that can be initialized(32).
>
> To more effiently d
Are there anything I have missed ?
Yeah, unfortunately quite a bunch of things. The fact that arm64 doesn't
support the PCIe NoSnoop TLP attribute is only the tip of the iceberg.
You need a full "recent" driver stack, e.g. not older than a few month till a
year, for this to work. And not only t
On Thu, Sep 05, 2019 at 07:51:59PM +, Siqueira, Rodrigo wrote:
> Hi Ville,
>
> First of all, thank you very much for the review.
>
> I added some comments below.
>
> On 09/05, Wentland, Harry wrote:
> > On 2019-09-05 1:29 p.m., Ville Syrjälä wrote:
> > > On Wed, Sep 04, 2019 at 07:02:18PM +0
> -Original Message-
> From: Chen, Guchun
> Sent: 2019年9月6日 18:01
> To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org;
> Zhang, Hawking
> Subject: RE: [PATCH 1/3] drm/amdgpu: move umc late init from gmc to umc
> block
>
>
>
> -Original Message-
> From: Zhou1, Tao
> Sent: Friday
-Original Message-
From: Zhou1, Tao
Sent: Friday, September 6, 2019 5:01 PM
To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ;
Chen, Guchun
Cc: Zhou1, Tao
Subject: [PATCH 1/3] drm/amdgpu: move umc late init from gmc to umc block
umc late init is umc specific, it's more suitable to
On Thu, Sep 05, 2019 at 05:26:08PM -0400, Kenny Ho wrote:
> On Thu, Sep 5, 2019 at 4:32 PM Daniel Vetter wrote:
> >
> *snip*
> > drm_dev_unregister gets called on hotunplug, so your cgroup-internal
> > tracking won't get out of sync any more than the drm_minor list gets
> > out of sync with drm_de
umc late init is umc specific, it's more suitable to be put in umc block
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 48
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_u
move umc ras init from ras module to umc block, generic ras module
should pay less attention to specific ras block.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 4
2 files changed, 4 insertions(+), 4 deletions(-)
di
this interface is related to specific version of umc, distinguish it
from ras_late_init
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.h | 2 +-
drivers/gpu/drm/amd/amdgpu/umc_v6_1.c | 2 +-
3 files changed, 4 insertions(+),
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: Yuan, Xiaojie
Sent: Friday, September 6, 2019 4:04 PM
To: amd-gfx@lists.freedesktop.org
Cc: Wang, Kevin(Yang) ; Yuan, Xiaojie
Subject: [PATCH v2] drm/amdgpu: fix null pointer deref in firmware header
printing
Thanks Kevin. I've sent out v2 patch.
BR,
Xiaojie
From: Wang, Kevin(Yang)
Sent: Thursday, September 5, 2019 6:26 PM
To: Yuan, Xiaojie; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: fix null pointer deref in firmware header
printing
On
v2: declare as (struct common_firmware_header *) type because
struct xxx_firmware_header inherits from it
When CE's ucode_id(8) is used to get sdma_hdr, we will be accessing an
unallocated amdgpu_firmware_info instance.
This issue appears on rhel7.7 with gcc 4.8.5. Newer compilers might have
From 6da2451b1391939cf49518d82d42c4d57b32a571 Mon Sep 17 00:00:00 2001
From: "Tianci.Yin"
Date: Thu, 5 Sep 2019 15:28:57 +0800
Subject: [PATCH] drm/amdgpu: add navi14 PCI ID for work station SKU
Add the navi14 PCI device id.
Change-Id: I96a8c892becaa8dcc7ad59dc80d047d3f755775f
Signed-off-by: Ti
> The functions "debugfs_remove" and "kfree" tolerate the passing
> of null pointers. Hence it is unnecessary to check such arguments
> around the calls. Thus remove the extra condition check at two places.
Will a tag like “Generated-by: scripts/coccinelle/free/ifnullfree.cocci” be
relevant here?
27 matches
Mail list logo
