RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages
Can you try to use a fixed limit like I suggested once more? E.g. just stop swapping if get_nr_swap_pages() < 256MB. Maybe you missed previous mail. I explain again here. Set the value as 256MB not work on my platform. My machine has 8GB system memory, and 8GB swap disk. On my machine, set it as 4G can work. But 4G also not work on test machine with 16GB system memory & 8GB swap disk. Thanks Roger(Hongbo.He) -Original Message- From: Koenig, Christian Sent: Friday, February 02, 2018 3:46 PM To: He, Roger ; Zhou, David(ChunMing) ; dri-devel@lists.freedesktop.org Cc: linux...@kvack.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages Can you try to use a fixed limit like I suggested once more? E.g. just stop swapping if get_nr_swap_pages() < 256MB. Regards, Christian. Am 02.02.2018 um 07:57 schrieb He, Roger: > Use the limit as total ram*1/2 seems work very well. > No OOM although swap disk reaches full at peak for piglit test. > > But for this approach, David noticed that has an obvious defect. > For example, if the platform has 32G system memory, 8G swap disk. > 1/2 * ram = 16G which is bigger than swap disk, so no swap for TTM is allowed > at all. > For now we work out an improved version based on get_nr_swap_pages(). > Going to send out later. > > Thanks > Roger(Hongbo.He) > -Original Message- > From: He, Roger > Sent: Thursday, February 01, 2018 4:03 PM > To: Koenig, Christian ; Zhou, > David(ChunMing) ; dri-devel@lists.freedesktop.org > Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; 'He, Roger' > > Subject: RE: [PATCH] mm/swap: add function get_total_swap_pages to > expose total_swap_pages > > Just now, I tried with fixed limit. But not work always. > For example: set the limit as 4GB on my platform with 8GB system memory, it > can pass. > But when run with platform with 16GB system memory, it failed since OOM. > > And I guess it also depends on app's behavior. > I mean some apps make OS to use more swap space as well. > > Thanks > Roger(Hongbo.He) > -Original Message- > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On > Behalf Of He, Roger > Sent: Thursday, February 01, 2018 1:48 PM > To: Koenig, Christian ; Zhou, > David(ChunMing) ; dri-devel@lists.freedesktop.org > Cc: linux...@kvack.org; linux-ker...@vger.kernel.org > Subject: RE: [PATCH] mm/swap: add function get_total_swap_pages to > expose total_swap_pages > > But what we could do is to rely on a fixed limit like the Intel driver > does and I suggested before. > E.g. don't copy anything into a shmemfile when there is only x MB of > swap space left. > > Here I think we can do it further, let the limit value scaling with total > system memory. > For example: total system memory * 1/2. > If that it will match the platform configuration better. > > Roger can you test that approach once more with your fix for the OOM > issues in the page fault handler? > > Sure. Use the limit as total ram*1/2 seems work very well. > No OOM although swap disk reaches full at peak for piglit test. > I speculate this case happens but no OOM because: > > a. run a while, swap disk be used close to 1/2* total size and but not over > 1/2 * total. > b. all subsequent swapped pages stay in system memory until no space there. > Then the swapped pages in shmem be flushed into swap disk. And probably > OS also need some swap space. > For this case, it is easy to get full for swap disk. > c. but because now free swap size < 1/2 * total, so no swap out happen after > that. > And at least 1/4* system memory will left because below check in > ttm_mem_global_reserve will ensure that. > if (zone->used_mem > limit) > goto out_unlock; > > Thanks > Roger(Hongbo.He) > -Original Message- > From: Koenig, Christian > Sent: Wednesday, January 31, 2018 4:13 PM > To: He, Roger ; Zhou, David(ChunMing) > ; dri-devel@lists.freedesktop.org > Cc: linux...@kvack.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to > expose total_swap_pages > > Yeah, indeed. But what we could do is to rely on a fixed limit like the Intel > driver does and I suggested before. > > E.g. don't copy anything into a shmemfile when there is only x MB of swap > space left. > > Roger can you test that approach once more with your fix for the OOM issues > in the page fault handler? > > Thanks, > Christian. > > Am 31.01.2018 um 09:08 schrieb He, Roger: >> I think this patch isn't need at all. You can directly read >> total_swap_pages variable in TTM. >> >> Because the variable is not exported by EXPORT_SYMBOL_GPL. So direct using >> will result in: >> "WARNING: "total_swap_pages" [drivers/gpu/drm/ttm/ttm.ko] undefined!". >> >> Thanks >> Roger(Hongbo.He) >> -Original Message- >> From: dri-devel [mailto:dri
Re: [PATCH 12/12] drm: zte: Use drm_atomic_helper_shutdown() to disable planes on removal
On Wed, Jan 17, 2018 at 11:55:35PM +0200, Laurent Pinchart wrote: > The plane cleanup handler currently calls drm_plane_helper_disable(), > which is a legacy helper function. Replace it with a call to > drm_atomic_helper_shutdown() at removal time. The plane .destroy() > handler now consisting only of a call to drm_plane_cleanup(), replace it > with direct calls to that function. > > Signed-off-by: Laurent Pinchart Acked-by: Shawn Guo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages
Can you try to use a fixed limit like I suggested once more? E.g. just stop swapping if get_nr_swap_pages() < 256MB. Regards, Christian. Am 02.02.2018 um 07:57 schrieb He, Roger: Use the limit as total ram*1/2 seems work very well. No OOM although swap disk reaches full at peak for piglit test. But for this approach, David noticed that has an obvious defect. For example, if the platform has 32G system memory, 8G swap disk. 1/2 * ram = 16G which is bigger than swap disk, so no swap for TTM is allowed at all. For now we work out an improved version based on get_nr_swap_pages(). Going to send out later. Thanks Roger(Hongbo.He) -Original Message- From: He, Roger Sent: Thursday, February 01, 2018 4:03 PM To: Koenig, Christian ; Zhou, David(ChunMing) ; dri-devel@lists.freedesktop.org Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; 'He, Roger' Subject: RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages Just now, I tried with fixed limit. But not work always. For example: set the limit as 4GB on my platform with 8GB system memory, it can pass. But when run with platform with 16GB system memory, it failed since OOM. And I guess it also depends on app's behavior. I mean some apps make OS to use more swap space as well. Thanks Roger(Hongbo.He) -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of He, Roger Sent: Thursday, February 01, 2018 1:48 PM To: Koenig, Christian ; Zhou, David(ChunMing) ; dri-devel@lists.freedesktop.org Cc: linux...@kvack.org; linux-ker...@vger.kernel.org Subject: RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages But what we could do is to rely on a fixed limit like the Intel driver does and I suggested before. E.g. don't copy anything into a shmemfile when there is only x MB of swap space left. Here I think we can do it further, let the limit value scaling with total system memory. For example: total system memory * 1/2. If that it will match the platform configuration better. Roger can you test that approach once more with your fix for the OOM issues in the page fault handler? Sure. Use the limit as total ram*1/2 seems work very well. No OOM although swap disk reaches full at peak for piglit test. I speculate this case happens but no OOM because: a. run a while, swap disk be used close to 1/2* total size and but not over 1/2 * total. b. all subsequent swapped pages stay in system memory until no space there. Then the swapped pages in shmem be flushed into swap disk. And probably OS also need some swap space. For this case, it is easy to get full for swap disk. c. but because now free swap size < 1/2 * total, so no swap out happen after that. And at least 1/4* system memory will left because below check in ttm_mem_global_reserve will ensure that. if (zone->used_mem > limit) goto out_unlock; Thanks Roger(Hongbo.He) -Original Message- From: Koenig, Christian Sent: Wednesday, January 31, 2018 4:13 PM To: He, Roger ; Zhou, David(ChunMing) ; dri-devel@lists.freedesktop.org Cc: linux...@kvack.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages Yeah, indeed. But what we could do is to rely on a fixed limit like the Intel driver does and I suggested before. E.g. don't copy anything into a shmemfile when there is only x MB of swap space left. Roger can you test that approach once more with your fix for the OOM issues in the page fault handler? Thanks, Christian. Am 31.01.2018 um 09:08 schrieb He, Roger: I think this patch isn't need at all. You can directly read total_swap_pages variable in TTM. Because the variable is not exported by EXPORT_SYMBOL_GPL. So direct using will result in: "WARNING: "total_swap_pages" [drivers/gpu/drm/ttm/ttm.ko] undefined!". Thanks Roger(Hongbo.He) -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Chunming Zhou Sent: Wednesday, January 31, 2018 3:15 PM To: He, Roger ; dri-devel@lists.freedesktop.org Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; Koenig, Christian Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages Hi Roger, I think this patch isn't need at all. You can directly read total_swap_pages variable in TTM. See the comment: /* protected with swap_lock. reading in vm_swap_full() doesn't need lock */ long total_swap_pages; there are many places using it directly, you just couldn't change its value. Reading it doesn't need lock. Regards, David Zhou On 2018年01月29日 16:29, Roger He wrote: ttm module needs it to determine its internal parameter setting. Signed-off-by: Roger He --- include/linux/swap.h | 6 ++ mm/swapfile.c| 15 +++ 2 files changed, 21 insertions(+)
Re: [PATCH 1/5] drm/ttm: add max_swap_mem in ttm_mem_global
On 2018年02月02日 15:34, Chunming Zhou wrote:
On 2018年02月02日 15:22, Roger He wrote:
set its initial value as 1/2 * free swap cache size when module initial.
and adjust this value when allocate TTM memory
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 --
include/drm/ttm/ttm_memory.h | 2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..b48931d 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#define TTM_MEMORY_ALLOC_RETRIES 4
@@ -372,9 +373,9 @@ int ttm_mem_global_init(struct ttm_mem_global
*glob)
kobject_put(&glob->kobj);
return ret;
}
-
+ /* set it as 1/2 * swap free space we can get at that time */
+ glob->max_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
si_meminfo(&si);
Hi Roger,
I just find si_meminfo can get total swap size, see struct sysinfo
definition:
struct sysinfo {
__kernel_long_t uptime; /* Seconds since boot */
__kernel_ulong_t loads[3]; /* 1, 5, and 15 minute load
averages */
__kernel_ulong_t totalram; /* Total usable main memory size */
__kernel_ulong_t freeram; /* Available memory size */
__kernel_ulong_t sharedram; /* Amount of shared memory */
__kernel_ulong_t bufferram; /* Memory used by buffers */
__kernel_ulong_t totalswap; /* Total swap space size */
__kernel_ulong_t freeswap; /* swap space still available */
__u16 procs; /* Number of current processes */
...
can sysinfo.totalswap be used for your change?
Regards,
David Zhou
-
ret = ttm_mem_init_kernel_zone(glob, &si);
if (unlikely(ret != 0))
goto out_no_zone;
@@ -473,12 +474,17 @@ static int ttm_mem_global_reserve(struct
ttm_mem_global *glob,
struct ttm_mem_zone *single_zone,
uint64_t amount, bool reserve)
{
+ uint64_t free_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
uint64_t limit;
int ret = -ENOMEM;
unsigned int i;
struct ttm_mem_zone *zone;
spin_lock(&glob->lock);
+ /* adjust the max_swap_mem to cover the new inserted swap space */
+ if (glob->max_swap_mem < free_swap_mem)
+ glob->max_swap_mem = free_swap_mem;
Seems using max() for exchange is more obvious, otherwise looks ok to me.
Regards,
David Zhou
+
for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
if (single_zone && zone != single_zone)
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 8936285..ad5a557 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -49,6 +49,7 @@
* @work: The workqueue callback for the shrink queue.
* @lock: Lock to protect the @shrink - and the memory accounting
members,
* that is, essentially the whole structure with some exceptions.
+ * @max_swap_mem: upper limit of swap space TTM can use
* @zones: Array of pointers to accounting zones.
* @num_zones: Number of populated entries in the @zones array.
* @zone_kernel: Pointer to the kernel zone.
@@ -67,6 +68,7 @@ struct ttm_mem_global {
struct workqueue_struct *swap_queue;
struct work_struct work;
spinlock_t lock;
+ uint64_t max_swap_mem;
struct ttm_mem_zone *zones[TTM_MEM_MAX_ZONES];
unsigned int num_zones;
struct ttm_mem_zone *zone_kernel;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm pull for v4.16-rc1
On 2 February 2018 at 02:50, Dave Airlie wrote: > On 2 February 2018 at 12:44, Linus Torvalds > wrote: >> On Thu, Feb 1, 2018 at 6:22 PM, Dave Airlie wrote: >>> >>> Turned out I was running on wayland instead of X.org and my cut-n-paste from >>> gedit to firefox got truncated, wierd. I'll go annoy some people, and make >>> sure >>> it doesn't happen again. >> >> Heh, so there's some Wayland clipboard buffer limit. > > Yup or some bug getting the second chunks across from one place to another. The transfer part of Wayland's clipboard protocol is an FD between both clients for them to send data directly. But Firefox isn't yet native, and I can fully believe that GNOME Shell's Xwayland clipboard translator isn't perfect. >> But that reminds me: is there any *standard* tool to programmatically >> feed into the clipboard? >> >> I occasionally do things like >> >> git shortlog A..B | xsel >> >> in order to then paste it into some browser window or other. >> >> And sure, that works well. But I do it seldom enough that I never >> remember the command, and half the time it's not even installed >> because I've switched machines or something, and xsel is always some >> add-on. >> >> What's the thing "real" X people do/use? > > I use gedit to move things from files to clip now, for mostly the same > reasons, > I know it's installed usually. xclip and xsel are two utilities I know > off, but I don' > think anything gets installed by default. That's the state of the art for X11. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/ttm: add ttm page_flags TTM_PAGE_FLAG_PAGEFAULT
Am 02.02.2018 um 08:22 schrieb Roger He:
to indicate whether we are servicing for page fault routine in
ttm_mem_global_reserve.
for ttm_mem_global_reserve if in page fault routine, allow success
always. because page fault routing already grabbed system memory
successfully and allow this exception is harmless.
Otherwise, it will trigger OOM killer.
v2: fix minor typo
v3: keep original behavior except ttm page with flag NO_RETRY
We need to extend this to the suspend/resume case as well.
Saying so would it be possible to make that behavior depend on the ctx
instead of the page flags?
Thanks,
Christian.
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 +-
drivers/gpu/drm/ttm/ttm_memory.c | 27 +++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 -
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 9 ++---
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
include/drm/ttm/ttm_bo_driver.h | 1 +
include/drm/ttm/ttm_memory.h | 3 ++-
7 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 716e724..f03dd94 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -233,8 +233,12 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
cvma.vm_page_prot);
+ if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
+ ttm->page_flags |= TTM_PAGE_FLAG_PAGEFAULT;
/* Allocate all page at once, most common usage */
- if (ttm->bdev->driver->ttm_tt_populate(ttm, &ctx)) {
+ ret = ttm->bdev->driver->ttm_tt_populate(ttm, &ctx);
+ ttm->page_flags &= ~TTM_PAGE_FLAG_PAGEFAULT;
+ if (ret) {
ret = VM_FAULT_OOM;
goto out_io_unlock;
}
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 598b14b..f5227a5 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -472,7 +472,8 @@ EXPORT_SYMBOL(ttm_mem_global_free);
static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
struct ttm_mem_zone *single_zone,
- uint64_t amount, bool reserve)
+ uint64_t amount, bool reserve,
+ bool in_pagefault)
{
uint64_t free_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
uint64_t swap_glob_mem, limit, total_used_mem;
@@ -483,6 +484,13 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
swap_glob_mem = atomic64_read(&glob->swap_glob_mem);
spin_lock(&glob->lock);
+ /*
+* if in page_fault allow reserve successfully anyway since it
+* already allocated system pages. Otherwise it will trigger OOM
+*/
+ if (in_pagefault)
+ goto reserve_direct;
+
/* adjust the max_swap_mem to cover the new inserted swap space */
if (glob->max_swap_mem < free_swap_mem)
glob->max_swap_mem = free_swap_mem;
@@ -501,6 +509,7 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
goto out_unlock;
}
+reserve_direct:
if (reserve) {
for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
@@ -522,13 +531,13 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
static int ttm_mem_global_alloc_zone(struct ttm_mem_global *glob,
struct ttm_mem_zone *single_zone,
uint64_t memory,
-struct ttm_operation_ctx *ctx)
+struct ttm_operation_ctx *ctx,
+bool in_pagefault)
{
int count = TTM_MEMORY_ALLOC_RETRIES;
- while (unlikely(ttm_mem_global_reserve(glob,
- single_zone,
- memory, true)
+ while (unlikely(ttm_mem_global_reserve(glob, single_zone, memory,
+ true, in_pagefault)
!= 0)) {
if (ctx->no_wait_gpu)
return -ENOMEM;
@@ -548,13 +557,14 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob,
uint64_t memory,
* all zones.
*/
- return ttm_mem_global_alloc_zone(glob, NULL, memory, ctx);
+ return ttm_mem_global_alloc_zone(glob, NULL, memory, ctx, false);
}
EXPORT_SYMBOL(ttm_mem_global_alloc);
int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
struct page *page, uint64_t size,
- struct ttm_o
Re: [PATCH 4/5] drm/ttm: if need_dma32 is not set, actually no need dma32 zone at all.
NAK, that the gfx driver doesn't need DMA32 doesn't mean that we can use
it all up with BO allocations.
It is still quite likely that other drivers in the system might need it.
Christian.
Am 02.02.2018 um 08:22 schrieb Roger He:
because this zone has only 4GB, it is easy to became bottleneck for
huge normal zone.
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +++
drivers/gpu/drm/ttm/ttm_memory.c| 10 --
include/drm/ttm/ttm_memory.h| 1 +
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 95f9901..9f90022 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -75,6 +75,7 @@ static void amdgpu_ttm_mem_global_release(struct
drm_global_reference *ref)
static int amdgpu_ttm_global_init(struct amdgpu_device *adev)
{
struct drm_global_reference *global_ref;
+ struct ttm_mem_global *mem_glob;
struct amdgpu_ring *ring;
struct drm_sched_rq *rq;
int r;
@@ -91,6 +92,8 @@ static int amdgpu_ttm_global_init(struct amdgpu_device *adev)
"subsystem.\n");
goto error_mem;
}
+ mem_glob = (struct ttm_mem_global *)global_ref->object;
+ mem_glob->bdev = &adev->mman.bdev;
adev->mman.bo_global_ref.mem_glob =
adev->mman.mem_global_ref.object;
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index f5227a5..875e5b8 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -567,6 +567,7 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
bool in_pagefault)
{
struct ttm_mem_zone *zone = NULL;
+ struct ttm_bo_device *bdev = glob->bdev;
/**
* Page allocations may be registed in a single zone
@@ -577,7 +578,9 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
if (PageHighMem(page) && glob->zone_highmem != NULL)
zone = glob->zone_highmem;
#else
- if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
+ if (bdev && !bdev->need_dma32)
+ zone = glob->zone_kernel;
+ else if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
#endif
return ttm_mem_global_alloc_zone(glob, zone, size,
@@ -588,12 +591,15 @@ void ttm_mem_global_free_page(struct ttm_mem_global
*glob, struct page *page,
uint64_t size)
{
struct ttm_mem_zone *zone = NULL;
+ struct ttm_bo_device *bdev = glob->bdev;
#ifdef CONFIG_HIGHMEM
if (PageHighMem(page) && glob->zone_highmem != NULL)
zone = glob->zone_highmem;
#else
- if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
+ if (bdev && !bdev->need_dma32)
+ zone = glob->zone_kernel;
+ else if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
#endif
ttm_mem_global_free_zone(glob, zone, size);
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 6c29b5c..0577475 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -79,6 +79,7 @@ struct ttm_mem_global {
#else
struct ttm_mem_zone *zone_dma32;
#endif
+ struct ttm_bo_device *bdev;
};
extern int ttm_mem_global_init(struct ttm_mem_global *glob);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/ttm: add max_swap_mem in ttm_mem_global
On 2018年02月02日 15:22, Roger He wrote:
set its initial value as 1/2 * free swap cache size when module initial.
and adjust this value when allocate TTM memory
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 --
include/drm/ttm/ttm_memory.h | 2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..b48931d 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#define TTM_MEMORY_ALLOC_RETRIES 4
@@ -372,9 +373,9 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
kobject_put(&glob->kobj);
return ret;
}
-
+ /* set it as 1/2 * swap free space we can get at that time */
+ glob->max_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
si_meminfo(&si);
-
ret = ttm_mem_init_kernel_zone(glob, &si);
if (unlikely(ret != 0))
goto out_no_zone;
@@ -473,12 +474,17 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
struct ttm_mem_zone *single_zone,
uint64_t amount, bool reserve)
{
+ uint64_t free_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
uint64_t limit;
int ret = -ENOMEM;
unsigned int i;
struct ttm_mem_zone *zone;
spin_lock(&glob->lock);
+ /* adjust the max_swap_mem to cover the new inserted swap space */
+ if (glob->max_swap_mem < free_swap_mem)
+ glob->max_swap_mem = free_swap_mem;
Seems using max() for exchange is more obvious, otherwise looks ok to me.
Regards,
David Zhou
+
for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
if (single_zone && zone != single_zone)
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 8936285..ad5a557 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -49,6 +49,7 @@
* @work: The workqueue callback for the shrink queue.
* @lock: Lock to protect the @shrink - and the memory accounting members,
* that is, essentially the whole structure with some exceptions.
+ * @max_swap_mem: upper limit of swap space TTM can use
* @zones: Array of pointers to accounting zones.
* @num_zones: Number of populated entries in the @zones array.
* @zone_kernel: Pointer to the kernel zone.
@@ -67,6 +68,7 @@ struct ttm_mem_global {
struct workqueue_struct *swap_queue;
struct work_struct work;
spinlock_t lock;
+ uint64_t max_swap_mem;
struct ttm_mem_zone *zones[TTM_MEM_MAX_ZONES];
unsigned int num_zones;
struct ttm_mem_zone *zone_kernel;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/ttm: keep original behavior except bo device with flag no_retry
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 875e5b8..25e1ce0 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -503,8 +503,11 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
limit = (capable(CAP_SYS_ADMIN)) ?
zone->emer_mem : zone->max_mem;
- total_used_mem = zone->used_mem + swap_glob_mem;
- limit += glob->max_swap_mem;
+ total_used_mem = zone->used_mem;
+ if (glob->bdev && glob->bdev->no_retry) {
+ total_used_mem += swap_glob_mem;
+ limit += glob->max_swap_mem;
+ }
if (total_used_mem > limit)
goto out_unlock;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/ttm: if need_dma32 is not set, actually no need dma32 zone at all.
because this zone has only 4GB, it is easy to became bottleneck for
huge normal zone.
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +++
drivers/gpu/drm/ttm/ttm_memory.c| 10 --
include/drm/ttm/ttm_memory.h| 1 +
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 95f9901..9f90022 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -75,6 +75,7 @@ static void amdgpu_ttm_mem_global_release(struct
drm_global_reference *ref)
static int amdgpu_ttm_global_init(struct amdgpu_device *adev)
{
struct drm_global_reference *global_ref;
+ struct ttm_mem_global *mem_glob;
struct amdgpu_ring *ring;
struct drm_sched_rq *rq;
int r;
@@ -91,6 +92,8 @@ static int amdgpu_ttm_global_init(struct amdgpu_device *adev)
"subsystem.\n");
goto error_mem;
}
+ mem_glob = (struct ttm_mem_global *)global_ref->object;
+ mem_glob->bdev = &adev->mman.bdev;
adev->mman.bo_global_ref.mem_glob =
adev->mman.mem_global_ref.object;
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index f5227a5..875e5b8 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -567,6 +567,7 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
bool in_pagefault)
{
struct ttm_mem_zone *zone = NULL;
+ struct ttm_bo_device *bdev = glob->bdev;
/**
* Page allocations may be registed in a single zone
@@ -577,7 +578,9 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
if (PageHighMem(page) && glob->zone_highmem != NULL)
zone = glob->zone_highmem;
#else
- if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
+ if (bdev && !bdev->need_dma32)
+ zone = glob->zone_kernel;
+ else if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
#endif
return ttm_mem_global_alloc_zone(glob, zone, size,
@@ -588,12 +591,15 @@ void ttm_mem_global_free_page(struct ttm_mem_global
*glob, struct page *page,
uint64_t size)
{
struct ttm_mem_zone *zone = NULL;
+ struct ttm_bo_device *bdev = glob->bdev;
#ifdef CONFIG_HIGHMEM
if (PageHighMem(page) && glob->zone_highmem != NULL)
zone = glob->zone_highmem;
#else
- if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
+ if (bdev && !bdev->need_dma32)
+ zone = glob->zone_kernel;
+ else if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
#endif
ttm_mem_global_free_zone(glob, zone, size);
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 6c29b5c..0577475 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -79,6 +79,7 @@ struct ttm_mem_global {
#else
struct ttm_mem_zone *zone_dma32;
#endif
+ struct ttm_bo_device *bdev;
};
extern int ttm_mem_global_init(struct ttm_mem_global *glob);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/ttm: add ttm page_flags TTM_PAGE_FLAG_PAGEFAULT
to indicate whether we are servicing for page fault routine in
ttm_mem_global_reserve.
for ttm_mem_global_reserve if in page fault routine, allow success
always. because page fault routing already grabbed system memory
successfully and allow this exception is harmless.
Otherwise, it will trigger OOM killer.
v2: fix minor typo
v3: keep original behavior except ttm page with flag NO_RETRY
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 +-
drivers/gpu/drm/ttm/ttm_memory.c | 27 +++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 -
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 9 ++---
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
include/drm/ttm/ttm_bo_driver.h | 1 +
include/drm/ttm/ttm_memory.h | 3 ++-
7 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 716e724..f03dd94 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -233,8 +233,12 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
cvma.vm_page_prot = ttm_io_prot(bo->mem.placement,
cvma.vm_page_prot);
+ if (ttm->page_flags & TTM_PAGE_FLAG_NO_RETRY)
+ ttm->page_flags |= TTM_PAGE_FLAG_PAGEFAULT;
/* Allocate all page at once, most common usage */
- if (ttm->bdev->driver->ttm_tt_populate(ttm, &ctx)) {
+ ret = ttm->bdev->driver->ttm_tt_populate(ttm, &ctx);
+ ttm->page_flags &= ~TTM_PAGE_FLAG_PAGEFAULT;
+ if (ret) {
ret = VM_FAULT_OOM;
goto out_io_unlock;
}
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 598b14b..f5227a5 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -472,7 +472,8 @@ EXPORT_SYMBOL(ttm_mem_global_free);
static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
struct ttm_mem_zone *single_zone,
- uint64_t amount, bool reserve)
+ uint64_t amount, bool reserve,
+ bool in_pagefault)
{
uint64_t free_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
uint64_t swap_glob_mem, limit, total_used_mem;
@@ -483,6 +484,13 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
swap_glob_mem = atomic64_read(&glob->swap_glob_mem);
spin_lock(&glob->lock);
+ /*
+* if in page_fault allow reserve successfully anyway since it
+* already allocated system pages. Otherwise it will trigger OOM
+*/
+ if (in_pagefault)
+ goto reserve_direct;
+
/* adjust the max_swap_mem to cover the new inserted swap space */
if (glob->max_swap_mem < free_swap_mem)
glob->max_swap_mem = free_swap_mem;
@@ -501,6 +509,7 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
goto out_unlock;
}
+reserve_direct:
if (reserve) {
for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
@@ -522,13 +531,13 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
static int ttm_mem_global_alloc_zone(struct ttm_mem_global *glob,
struct ttm_mem_zone *single_zone,
uint64_t memory,
-struct ttm_operation_ctx *ctx)
+struct ttm_operation_ctx *ctx,
+bool in_pagefault)
{
int count = TTM_MEMORY_ALLOC_RETRIES;
- while (unlikely(ttm_mem_global_reserve(glob,
- single_zone,
- memory, true)
+ while (unlikely(ttm_mem_global_reserve(glob, single_zone, memory,
+ true, in_pagefault)
!= 0)) {
if (ctx->no_wait_gpu)
return -ENOMEM;
@@ -548,13 +557,14 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob,
uint64_t memory,
* all zones.
*/
- return ttm_mem_global_alloc_zone(glob, NULL, memory, ctx);
+ return ttm_mem_global_alloc_zone(glob, NULL, memory, ctx, false);
}
EXPORT_SYMBOL(ttm_mem_global_alloc);
int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
struct page *page, uint64_t size,
- struct ttm_operation_ctx *ctx)
+ struct ttm_operation_ctx *ctx,
+ bool in_pagefault)
{
struct ttm_mem_zone *zone = NULL;
@@ -570,7 +580,8 @@ int ttm_mem_global_alloc_page(
[PATCH 2/5] drm/ttm: add swap_glob_mem in ttm_mem_global
separate swapped memory account from zone->used_mem because swapped
ttm pages can be flushed into SWAP disk/file under high memory pressure.
add check conditon in ttm_mem_global_reserve to prevent triggering OOM.
because if swap space is full, all swapped ttm pages would stay in
system memory which can't be flushed into swap space.
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 12
drivers/gpu/drm/ttm/ttm_tt.c | 13 +++--
include/drm/ttm/ttm_memory.h | 2 ++
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index b48931d..598b14b 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -197,7 +197,6 @@ static bool ttm_zones_above_swap_target(struct
ttm_mem_global *glob,
target = zone->max_mem;
target = (extra > target) ? 0ULL : target;
-
if (zone->used_mem > target)
return true;
}
@@ -375,6 +374,7 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
}
/* set it as 1/2 * swap free space we can get at that time */
glob->max_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
+ atomic64_set(&glob->swap_glob_mem, 0);
si_meminfo(&si);
ret = ttm_mem_init_kernel_zone(glob, &si);
if (unlikely(ret != 0))
@@ -475,10 +475,12 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
uint64_t amount, bool reserve)
{
uint64_t free_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
- uint64_t limit;
+ uint64_t swap_glob_mem, limit, total_used_mem;
+ struct ttm_mem_zone *zone;
int ret = -ENOMEM;
unsigned int i;
- struct ttm_mem_zone *zone;
+
+ swap_glob_mem = atomic64_read(&glob->swap_glob_mem);
spin_lock(&glob->lock);
/* adjust the max_swap_mem to cover the new inserted swap space */
@@ -493,7 +495,9 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
limit = (capable(CAP_SYS_ADMIN)) ?
zone->emer_mem : zone->max_mem;
- if (zone->used_mem > limit)
+ total_used_mem = zone->used_mem + swap_glob_mem;
+ limit += glob->max_swap_mem;
+ if (total_used_mem > limit)
goto out_unlock;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 95a77da..5d441e0 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -183,8 +183,11 @@ void ttm_tt_destroy(struct ttm_tt *ttm)
ttm_tt_unpopulate(ttm);
if (!(ttm->page_flags & TTM_PAGE_FLAG_PERSISTENT_SWAP) &&
- ttm->swap_storage)
+ ttm->swap_storage) {
fput(ttm->swap_storage);
+ atomic64_sub_return(ttm->num_pages << PAGE_SHIFT,
+ &ttm->glob->mem_glob->swap_glob_mem);
+ }
ttm->swap_storage = NULL;
ttm->func->destroy(ttm);
@@ -322,8 +325,11 @@ int ttm_tt_swapin(struct ttm_tt *ttm)
put_page(from_page);
}
- if (!(ttm->page_flags & TTM_PAGE_FLAG_PERSISTENT_SWAP))
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_PERSISTENT_SWAP)) {
fput(swap_storage);
+ atomic64_sub_return(ttm->num_pages << PAGE_SHIFT,
+ &ttm->glob->mem_glob->swap_glob_mem);
+ }
ttm->swap_storage = NULL;
ttm->page_flags &= ~TTM_PAGE_FLAG_SWAPPED;
@@ -383,6 +389,9 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file
*persistent_swap_storage)
ttm->page_flags |= TTM_PAGE_FLAG_SWAPPED;
if (persistent_swap_storage)
ttm->page_flags |= TTM_PAGE_FLAG_PERSISTENT_SWAP;
+ else
+ atomic64_add_return(ttm->num_pages << PAGE_SHIFT,
+ &ttm->glob->mem_glob->swap_glob_mem);
return 0;
out_err:
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index ad5a557..6282b50 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -50,6 +50,7 @@
* @lock: Lock to protect the @shrink - and the memory accounting members,
* that is, essentially the whole structure with some exceptions.
* @max_swap_mem: upper limit of swap space TTM can use
+ * @swap_glob_mem: total size of ttm pages which have been swapped out
* @zones: Array of pointers to accounting zones.
* @num_zones: Number of populated entries in the @zones array.
* @zone_kernel: Pointer to the kernel zone.
@@ -69,6 +70,7 @@ struct ttm_mem_global {
struct work_struct work;
spinlock_t lock;
uint64_t max_swap_mem;
+ atomic64_t swap_glob_mem;
struct ttm_mem_zone *zones[TTM_MEM_MAX_ZONES];
unsigned int num_zones;
struct ttm_mem_zone *zone_kernel;
--
2.7.4
[PATCH 1/5] drm/ttm: add max_swap_mem in ttm_mem_global
set its initial value as 1/2 * free swap cache size when module initial.
and adjust this value when allocate TTM memory
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 --
include/drm/ttm/ttm_memory.h | 2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..b48931d 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#define TTM_MEMORY_ALLOC_RETRIES 4
@@ -372,9 +373,9 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
kobject_put(&glob->kobj);
return ret;
}
-
+ /* set it as 1/2 * swap free space we can get at that time */
+ glob->max_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
si_meminfo(&si);
-
ret = ttm_mem_init_kernel_zone(glob, &si);
if (unlikely(ret != 0))
goto out_no_zone;
@@ -473,12 +474,17 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
struct ttm_mem_zone *single_zone,
uint64_t amount, bool reserve)
{
+ uint64_t free_swap_mem = get_nr_swap_pages() << (PAGE_SHIFT - 1);
uint64_t limit;
int ret = -ENOMEM;
unsigned int i;
struct ttm_mem_zone *zone;
spin_lock(&glob->lock);
+ /* adjust the max_swap_mem to cover the new inserted swap space */
+ if (glob->max_swap_mem < free_swap_mem)
+ glob->max_swap_mem = free_swap_mem;
+
for (i = 0; i < glob->num_zones; ++i) {
zone = glob->zones[i];
if (single_zone && zone != single_zone)
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 8936285..ad5a557 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -49,6 +49,7 @@
* @work: The workqueue callback for the shrink queue.
* @lock: Lock to protect the @shrink - and the memory accounting members,
* that is, essentially the whole structure with some exceptions.
+ * @max_swap_mem: upper limit of swap space TTM can use
* @zones: Array of pointers to accounting zones.
* @num_zones: Number of populated entries in the @zones array.
* @zone_kernel: Pointer to the kernel zone.
@@ -67,6 +68,7 @@ struct ttm_mem_global {
struct workqueue_struct *swap_queue;
struct work_struct work;
spinlock_t lock;
+ uint64_t max_swap_mem;
struct ttm_mem_zone *zones[TTM_MEM_MAX_ZONES];
unsigned int num_zones;
struct ttm_mem_zone *zone_kernel;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages
Use the limit as total ram*1/2 seems work very well. No OOM although swap disk reaches full at peak for piglit test. But for this approach, David noticed that has an obvious defect. For example, if the platform has 32G system memory, 8G swap disk. 1/2 * ram = 16G which is bigger than swap disk, so no swap for TTM is allowed at all. For now we work out an improved version based on get_nr_swap_pages(). Going to send out later. Thanks Roger(Hongbo.He) -Original Message- From: He, Roger Sent: Thursday, February 01, 2018 4:03 PM To: Koenig, Christian ; Zhou, David(ChunMing) ; dri-devel@lists.freedesktop.org Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; 'He, Roger' Subject: RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages Just now, I tried with fixed limit. But not work always. For example: set the limit as 4GB on my platform with 8GB system memory, it can pass. But when run with platform with 16GB system memory, it failed since OOM. And I guess it also depends on app's behavior. I mean some apps make OS to use more swap space as well. Thanks Roger(Hongbo.He) -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of He, Roger Sent: Thursday, February 01, 2018 1:48 PM To: Koenig, Christian ; Zhou, David(ChunMing) ; dri-devel@lists.freedesktop.org Cc: linux...@kvack.org; linux-ker...@vger.kernel.org Subject: RE: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages But what we could do is to rely on a fixed limit like the Intel driver does and I suggested before. E.g. don't copy anything into a shmemfile when there is only x MB of swap space left. Here I think we can do it further, let the limit value scaling with total system memory. For example: total system memory * 1/2. If that it will match the platform configuration better. Roger can you test that approach once more with your fix for the OOM issues in the page fault handler? Sure. Use the limit as total ram*1/2 seems work very well. No OOM although swap disk reaches full at peak for piglit test. I speculate this case happens but no OOM because: a. run a while, swap disk be used close to 1/2* total size and but not over 1/2 * total. b. all subsequent swapped pages stay in system memory until no space there. Then the swapped pages in shmem be flushed into swap disk. And probably OS also need some swap space. For this case, it is easy to get full for swap disk. c. but because now free swap size < 1/2 * total, so no swap out happen after that. And at least 1/4* system memory will left because below check in ttm_mem_global_reserve will ensure that. if (zone->used_mem > limit) goto out_unlock; Thanks Roger(Hongbo.He) -Original Message- From: Koenig, Christian Sent: Wednesday, January 31, 2018 4:13 PM To: He, Roger ; Zhou, David(ChunMing) ; dri-devel@lists.freedesktop.org Cc: linux...@kvack.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages Yeah, indeed. But what we could do is to rely on a fixed limit like the Intel driver does and I suggested before. E.g. don't copy anything into a shmemfile when there is only x MB of swap space left. Roger can you test that approach once more with your fix for the OOM issues in the page fault handler? Thanks, Christian. Am 31.01.2018 um 09:08 schrieb He, Roger: > I think this patch isn't need at all. You can directly read > total_swap_pages variable in TTM. > > Because the variable is not exported by EXPORT_SYMBOL_GPL. So direct using > will result in: > "WARNING: "total_swap_pages" [drivers/gpu/drm/ttm/ttm.ko] undefined!". > > Thanks > Roger(Hongbo.He) > -Original Message- > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On > Behalf Of Chunming Zhou > Sent: Wednesday, January 31, 2018 3:15 PM > To: He, Roger ; dri-devel@lists.freedesktop.org > Cc: linux...@kvack.org; linux-ker...@vger.kernel.org; Koenig, > Christian > Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to > expose total_swap_pages > > Hi Roger, > > I think this patch isn't need at all. You can directly read total_swap_pages > variable in TTM. See the comment: > > /* protected with swap_lock. reading in vm_swap_full() doesn't need > lock */ long total_swap_pages; > > there are many places using it directly, you just couldn't change its value. > Reading it doesn't need lock. > > > Regards, > > David Zhou > > > On 2018年01月29日 16:29, Roger He wrote: >> ttm module needs it to determine its internal parameter setting. >> >> Signed-off-by: Roger He >> --- >>include/linux/swap.h | 6 ++ >>mm/swapfile.c| 15 +++ >>2 files changed, 21 insertions(+) >> >> diff --git a/include/linux/swap.h b/include/linux/swap.h index >> c2b8128..708d66f 100644 >> --
[Bug 102261] [CI] rtcwake failed with 256
https://bugs.freedesktop.org/show_bug.cgi?id=102261 Jani Saarinen changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |tomi.p.sarv...@intel.com |.org| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/msm/adreno: Add ringbuffer contexts to the GPU state
Hi Jordan, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [cannot apply to v4.15 next-20180201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jordan-Crouse/drm-msm-GPU-crash-state/20180129-033415 base: git://people.freedesktop.org/~robclark/linux msm-next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> drivers/gpu/drm/msm/adreno/adreno_gpu.c:20:10: fatal error: linux/ascii85.h: >> No such file or directory #include ^ compilation terminated. vim +20 drivers/gpu/drm/msm/adreno/adreno_gpu.c > 20 #include 21 #include 22 #include "adreno_gpu.h" 23 #include "msm_gem.h" 24 #include "msm_mmu.h" 25 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm pull for v4.16-rc1
On 2 February 2018 at 12:44, Linus Torvalds wrote: > On Thu, Feb 1, 2018 at 6:22 PM, Dave Airlie wrote: >> >> Turned out I was running on wayland instead of X.org and my cut-n-paste from >> gedit to firefox got truncated, wierd. I'll go annoy some people, and make >> sure >> it doesn't happen again. > > Heh, so there's some Wayland clipboard buffer limit. Yup or some bug getting the second chunks across from one place to another. > > But that reminds me: is there any *standard* tool to programmatically > feed into the clipboard? > > I occasionally do things like > > git shortlog A..B | xsel > > in order to then paste it into some browser window or other. > > And sure, that works well. But I do it seldom enough that I never > remember the command, and half the time it's not even installed > because I've switched machines or something, and xsel is always some > add-on. > > What's the thing "real" X people do/use? I use gedit to move things from files to clip now, for mostly the same reasons, I know it's installed usually. xclip and xsel are two utilities I know off, but I don' think anything gets installed by default. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm pull for v4.16-rc1
On Thu, Feb 1, 2018 at 6:22 PM, Dave Airlie wrote: > > Turned out I was running on wayland instead of X.org and my cut-n-paste from > gedit to firefox got truncated, wierd. I'll go annoy some people, and make > sure > it doesn't happen again. Heh, so there's some Wayland clipboard buffer limit. But that reminds me: is there any *standard* tool to programmatically feed into the clipboard? I occasionally do things like git shortlog A..B | xsel in order to then paste it into some browser window or other. And sure, that works well. But I do it seldom enough that I never remember the command, and half the time it's not even installed because I've switched machines or something, and xsel is always some add-on. What's the thing "real" X people do/use? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm pull for v4.16-rc1
On Thu, Feb 1, 2018 at 4:40 PM, Dave Airlie wrote: > > This seems to have been a comparatively quieter merge window, I assume > due to holidays etc. Hmm. I pulled, and then noticed that there's no diffstat to compare my end result with. Then I was going to at least compare the shortlog, but that is truncated too! Oh well. The part of the shortlog I can see in your email does match, and the end result looks sane, so I'll take it on faith, but I really would like to see the real full pull request, not this truncated half-thing. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu/display: fix wrong enum type for ddc_result
From: Dominik Behr
v2: now with fixed result comparison and spelling fixes
Signed-off-by: Dominik Behr
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 4 ++--
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c| 4 ++--
drivers/gpu/drm/amd/display/include/ddc_service_types.h | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 1e8a21b67df7..3b05900d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -130,7 +130,7 @@ static ssize_t dm_dp_aux_transfer(struct drm_dp_aux *aux,
msg->address,
msg->buffer,
msg->size,
-r == DDC_RESULT_SUCESSFULL);
+r == DDC_RESULT_SUCCESSFUL);
#endif
return msg->size;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 0023754e034b..3abd0f1a287f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1176,7 +1176,7 @@ static void dpcd_configure_panel_mode(
&edp_config_set.raw,
sizeof(edp_config_set.raw));
- ASSERT(result == DDC_RESULT_SUCESSFULL);
+ ASSERT(result == DDC_RESULT_SUCCESSFUL);
}
}
dm_logger_write(link->ctx->logger, LOG_DETECTION_DP_CAPS,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index d5294798b0a5..6b69b339dba2 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -661,7 +661,7 @@ enum ddc_result dal_ddc_service_read_dpcd_data(
ddc->ctx->i2caux,
ddc->ddc_pin,
&command))
- return DDC_RESULT_SUCESSFULL;
+ return DDC_RESULT_SUCCESSFUL;
return DDC_RESULT_FAILED_OPERATION;
}
@@ -698,7 +698,7 @@ enum ddc_result dal_ddc_service_write_dpcd_data(
ddc->ctx->i2caux,
ddc->ddc_pin,
&command))
- return DDC_RESULT_SUCESSFULL;
+ return DDC_RESULT_SUCCESSFUL;
return DDC_RESULT_FAILED_OPERATION;
}
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 33d91e4474ea..cc067d04505d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -1926,7 +1926,7 @@ bool dc_link_handle_hpd_rx_irq(struct dc_link *link,
union hpd_irq_data *out_hpd
{
union hpd_irq_data hpd_irq_dpcd_data = 0;
union device_service_irq device_service_clear = { { 0 } };
- enum dc_status result = DDC_RESULT_UNKNOWN;
+ enum ddc_result result = DDC_RESULT_UNKNOWN;
bool status = false;
/* For use cases related to down stream connection status change,
* PSR and device auto test, refer to function handle_sst_hpd_irq
@@ -1946,7 +1946,7 @@ bool dc_link_handle_hpd_rx_irq(struct dc_link *link,
union hpd_irq_data *out_hpd
if (out_hpd_irq_dpcd_data)
*out_hpd_irq_dpcd_data = hpd_irq_dpcd_data;
- if (result != DC_OK) {
+ if (result != DDC_RESULT_SUCCESSFUL) {
dm_logger_write(link->ctx->logger, LOG_HW_HPD_IRQ,
"%s: DPCD read failed to obtain irq data\n",
__func__);
diff --git a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
index 019e7a095ea1..f3bf749b3636 100644
--- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
+++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
@@ -32,7 +32,7 @@
enum ddc_result {
DDC_RESULT_UNKNOWN = 0,
- DDC_RESULT_SUCESSFULL,
+ DDC_RESULT_SUCCESSFUL,
DDC_RESULT_FAILED_CHANNEL_BUSY,
DDC_RESULT_FAILED_TIMEOUT,
DDC_RESULT_FAILED_PROTOCOL_ERROR,
--
2.16.0.rc1.238.g530d649a79-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] i915 PSR test results and cursor lag
On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson wrote: > Quoting Andy Lutomirski (2018-02-01 21:04:30) >> I got this after a recent suspend/resume: >> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed. >> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all dirs >> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: >> scanning /sys/bus >> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: >> scanning /sys/class >> Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open >> configuration file '/etc/systemd/sleep.conf': No such file or >> directory >> Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending... >> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal >> sender=n/a destination=n/a object=/org/freedesktop/login1 >> interface=org.freedesktop.login1.Manager member=PrepareForSleep >> cookie=570 reply >> Feb 01 09:44:34 laptop systemd-logind[2412]: Got message >> type=method_call sender=:1.46 destination=:1.1 >> object=/org/freedesktop/login1/session/_32 >> interface=org.freedesktop.login1.Session member=ReleaseDevice >> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal >> sender=n/a destination=:1.46 >> object=/org/freedesktop/login1/session/_32 >> interface=org.freedesktop.login1.Session member=PauseDevice cookie >> Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane >> transform 0: Permission denied >> Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed >> with (Permission denied), drawing cursor with OpenGL from now on >> >> But I don't see the word "cursor" in my system logs before the first >> suspend. What am I looking for? This is Fedora 27 running a Gnome >> Wayland session, but it hasn't been reinstalled in some time, so it's >> possible that there are some weird settings sitting around. But I did >> check and I have no weird i915 parameters. > > You are using gnome-shell as the display server. From that it appears to > have started off with a HW cursor and switched to a SW cursor after > suspend. Did you notice a change in behaviour? After rebooting or just > restarting gnome-shell? I think it's less consistently bad after a reboot before suspending. > >> Also, are these things potentially related: >> >> [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential >> atomic update failure on pipe A > > They are just "missed the immediate vblank for the screen update" > messages. Should not be related to PSR, but may cause jitter by delaying > the odd screen update. I just got this one, and the timestamp is at least reasonably close to a giant latency spike: [ 288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=31 end=32) time 15 us, min 1073, max 1079, scanline start 1087, end 1088 > >> As I'm typing this, I've seen a couple instances of what seems like a >> full *second* of cursor latency, but I've only gotten the potential >> atomic update failure once. >> >> And is there any straightforward tracing to do to distinguish between >> PSR exit latency and other potential sources of latency? > > It looks plausible that we could at least report how long it takes the > registers to reflect the change in state (but we don't). The best source > of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status. Hmm. I went and looked at the code, and I noticed what could be bugs or could (more likely) be my confusion since I don't know this code at all: intel_single_frame_update() does something inscrutable to me, but I imagine it does something that causes the next page flip to get noticed by the panel even with PSR on. But how does the code that calls it know that anything happened? (Looking at the commit history, maybe this is something special that's only needed on some platforms but doesn't replace the normal PSR exit sequence.) Perhaps more interestingly, intel_psr_flush() does this: /* By definition flush = invalidate + flush */ if (frontbuffer_bits) intel_psr_exit(dev_priv); if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) if (!work_busy(&dev_priv->psr.work.work)) schedule_delayed_work(&dev_priv->psr.work, msecs_to_jiffies(100)); I'm guessing that the idea is that we're turning off PSR because we want the panel to update and we expect that, in 100ms, the update will have hit the panel and we'll have been idle long enough for it to make sense to re-enter PSR. IOW, the code wants PSR to be off for at least 100ms and then to turn back on. But this code actually says "turn PSR back on in at *most* 100ms". What happens if there are two screen updates 99ms apart? The first one should work fine, but the next one will hit with 1ms left on the delayed work, and intel_psr_work() will get called in 1ms. There's some magic with busy_frontbuffer_bits, but it seems questionable to me that intel_psr_flush() clears busy_fron
[PULL] drm-intel-next-fixes
Hi Dave, I didn't send sooner because I wasn't happy with the CI results running on drm-intel-next-fixes, but now everything looks greener there. Here goes drm-intel-next-fixes-2018-02-01: Fixes for GPU hangs and other bugs around hangcheck and result; Fix for regression on suspend case with vgaswitcheroo; Fixes for eDP and HDMI blank screens Fix for protecting WC allocation to avoid overflow on page vec; Cleanup around unpublished GLK firmware blobs, and other small fixes. This also contains GVT pull request mostly with regression fixes on vGPU display dmabuf, mmio switch and other misc changes. Thanks, Rodrigo. The following changes since commit 24b8ef699e8221d2b7f813adaab13eec053e1507: drm/ast: Load lut in crtc_commit (2018-02-01 11:35:46 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2018-02-01 for you to fetch changes up to 751b01cb07ebf0dbbe4a4fbfeaa509388e4a2b0a: drm/i915/ppgtt: Pin page directories before allocation (2018-02-01 07:33:04 -0800) Fixes for GPU hangs and other bugs around hangcheck and result; Fix for regression on suspend case with vgaswitcheroo; Fixes for eDP and HDMI blank screens Fix for protecting WC allocation to avoid overflow on page vec; Cleanup around unpublished GLK firmware blobs, and other small fixes. This also contains GVT pull request mostly with regression fixes on vGPU display dmabuf, mmio switch and other misc changes. Anusha Srivatsa (1): drm/i915/glk: Disable Guc and HuC on GLK Chris Wilson (5): drm/i915/pmu: Reconstruct active state on starting busy-stats drm/i915: Only attempt to scan the requested number of shrinker slabs drm/i915: Protect WC stash allocation against direct reclaim drm/i915: Always run hangcheck while the GPU is busy drm/i915/ppgtt: Pin page directories before allocation Hang Yuan (1): drm/i915/gvt: validate gfn before set shadow page entry Imre Deak (1): drm/i915: Fix using BIT_ULL() vs. BIT() for power domain masks Lionel Landwerlin (1): Revert "drm/i915: mark all device info struct with __initconst" Maarten Lankhorst (1): drm/i915: Always call to intel_display_set_init_power() in resume_early. Manasi Navare (1): drm/i915/edp: Do not do link training fallback or prune modes on EDP Michel Thierry (1): drm/i915/gvt: Do not use I915_NUM_ENGINES to iterate over the mocs regs array Mika Kahola (1): drm/i915: Check for fused or unused pipes Oscar Mateo (1): drm/i915: Stop getting the fault address from RING_FAULT_REG Pei Zhang (1): drm/i915/gvt: add PLANE_KEYMAX regs to mmio track list Sagar Arun Kamble (1): drm/i915/guc: Add uc_fini_wq in gem_init unwind path Stefan Brüns (1): drm/i915: Try EDID bitbanging on HDMI after failed read Tina Zhang (1): drm/i915/gvt: Keep obj->dma_buf link NULL during exporting Xiong Zhang (1): drm/i915/gvt: Fix gen8/9_render_mmio_list[0] don't take effect Zhenyu Wang (2): drm/i915/gvt: cancel virtual vblank timer when no vGPU exists drm/i915/gvt: cancel scheduler timer when no vGPU exists drivers/gpu/drm/i915/gvt/dmabuf.c | 1 - drivers/gpu/drm/i915/gvt/gtt.c| 24 +-- drivers/gpu/drm/i915/gvt/handlers.c | 3 + drivers/gpu/drm/i915/gvt/hypercall.h | 1 + drivers/gpu/drm/i915/gvt/kvmgt.c | 16 + drivers/gpu/drm/i915/gvt/mmio_context.c | 10 +-- drivers/gpu/drm/i915/gvt/mpt.h| 17 + drivers/gpu/drm/i915/gvt/sched_policy.c | 7 ++ drivers/gpu/drm/i915/gvt/vgpu.c | 2 + drivers/gpu/drm/i915/i915_drv.c | 2 + drivers/gpu/drm/i915/i915_gem.c | 9 +-- drivers/gpu/drm/i915/i915_gem_gtt.c | 61 + drivers/gpu/drm/i915/i915_gem_request.c | 2 + drivers/gpu/drm/i915/i915_gem_shrinker.c | 4 +- drivers/gpu/drm/i915/i915_pci.c | 94 +-- drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_audio.c| 2 +- drivers/gpu/drm/i915/intel_breadcrumbs.c | 11 drivers/gpu/drm/i915/intel_display.c | 6 +- drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +--- drivers/gpu/drm/i915/intel_engine_cs.c| 16 - drivers/gpu/drm/i915/intel_guc_fw.c | 9 --- drivers/gpu/drm/i915/intel_hangcheck.c| 7 +- drivers/gpu/drm/i915/intel_hdmi.c | 14 +++- drivers/gpu/drm/i915/intel_huc.c | 11 drivers/gpu/drm/i915/intel_uc.c | 2 - 26 files changed, 226 insertions(+), 133 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm pull for v4.16-rc1
Hi Linus, This seems to have been a comparatively quieter merge window, I assume due to holidays etc. The "biggest" change is AMD header cleanups, which merge/remove a bunch of them. The AMD gpu scheduler is now being made generic with the etnaviv driver wanting to reuse the code, hopefully other drivers can go in the same direction. Otherwise it's the usual lots of stuff in i915/amdgpu, not so much stuff elsewhere. I did a test merge with your tree, i915_display.c has a bunch of trivials, but just pick the versions from my tree and it should be fine, the only mildly tricky bit was the asserts which got removed in -next. Core: Add .last_close and .output_poll_changed helpers to reduce driver footprints Fix plane clipping Improved debug printing support Add panel orientation property Update edid derived properties at edid setting Reduction in fbdev driver footprint Move amdgpu scheduler into core for other drivers to use. i915: Selftest and IGT improvements Fast boot prep work on IPS, pipe config HW workarounds for Cannonlake, Geminilake Cannonlake clock and HDMI2.0 fixes GPU cache invalidation and context switch improvements Display planes cleanup New PMU interface for perf queries New firmware support for KBL/SKL Geminilake HW workaround for perforamce Coffeelake stolem memory improvements GPU reset robustness work Cannonlake horizontal plane flipping GVT work amdgpu/radeon: RV and Vega header file cleanups (lots of lines gone!) TTM operation context support 48-bit GPUVM support for Vega/RV ECC support for Vega Resizeable BAR support Multi-display sync support Enable swapout for reserved BOs during allocation S3 fixes on Raven GPU reset cleanup and fixes 2+1 level GPU page table amdkfd: GFX7/8 SDMA user queues support Hardware scheduling for multiple processes dGPU prep work rcar: Added R8A7743/5 support System suspend/resume support sun4i: Multi-plane support for YUV formats A83T and LVDS support msm: Devfreq support for GPU tegra: Prep work for adding Tegra186 support Tegra186 HDMI support HDMI2.0 and zpos support by using generic helpers tilcdc: Misc fixes omapdrm: Support memory bandwidth limits DSI command mode panel cleanups DMM error handling exynos: drop the old IPP subdriver. etnaviv: Occlusion query fixes Job handling fixes Prep work for hooking in gpu scheduler armada: Move closer to atomic modesetting Allow disabling primary plane if overlay is full screen imx: Format modifier support Add tile prefetch to PRE Runtime PM support for PRG ast: fix LUT loading Regards, Dave. The following changes since commit a8750ddca918032d6349adbf9a4b6555e7db20da: Linux 4.15-rc8 (2018-01-14 15:32:30 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.16 for you to fetch changes up to 24b8ef699e8221d2b7f813adaab13eec053e1507: drm/ast: Load lut in crtc_commit (2018-02-01 11:35:46 +1000) drm/graphics pull request for v4.16-rc1 Aastha Gupta (1): drm: virtio: replace reference/unreference with get/put Alex Deucher (41): drm/amd/display: add mod_freesync_user_enable to dm_connector_state drm/amdgpu/gfx8: use cached values for raster config in clear state drm/amdgpu/gfx7: use cached values for raster config in clear state drm/amdgpu/gfx6: use cached values for raster config in clear state drm/amdgpu/gmc9: make some ECC messages debug only drm/amdgpu: add license to Makefiles drm/amdgpu: add license to files where it was missing drm/scheduler: add license to the Makefile drm/amdgpu: make function names consistent in nbio files drm/amdgpu: convert nbio to use callbacks (v2) drm/amdgpu: drop the bios scratch reg callbacks from nbio drm/amdgpu: drop soc15_init_golden_registers drm/amdgpu: remove some old gc 9.x registers drm/amdgpu: drop scratch regs save and restore from S3/S4 handling drm/amdgpu: drop scratch regs save and restore from GPU reset handling drm/amdgpu: drop amdgpu_atombios_scratch_regs_save/restore drm/amdgpu: setup the shared and private apertures on gfx9 drm/amdgpu: move atom functions from amdgpu_device.c drm/amdgpu: use consistent naming for static funcs in amdgpu_device.c drm/amdgpu: rename amdgpu_suspend to amdgpu_device_ip_suspend drm/amdgpu: move debugfs functions to their own file drm/amdgpu: rename amdgpu_wb_* functions drm/amdgpu: rename amdgpu_program_register_sequence drm/amdgpu: rename amdgpu_pci_config_reset drm/amdgpu: move amdgpu_doorbell_get_kfd_info to amdgpu_amdkfd.c drm/amdgpu: rename amdgpu_*_location functions drm/amdgpu: move fw_reserve functions to amdgpu_ttm.c drm/amdgpu: rename ip block helper functions drm/amdgpu: rename amdgpu_need_post drm/amdgpu: move dummy page functions to amd
[PATCH] drm/amdgpu/display: fix wrong enum type for ddc_result
From: Dominik Behr
Signed-off-by: Dominik Behr
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 33d91e4474ea..6c1ab6aa17f9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -1926,7 +1926,7 @@ bool dc_link_handle_hpd_rx_irq(struct dc_link *link,
union hpd_irq_data *out_hpd
{
union hpd_irq_data hpd_irq_dpcd_data = 0;
union device_service_irq device_service_clear = { { 0 } };
- enum dc_status result = DDC_RESULT_UNKNOWN;
+ enum ddc_result result = DDC_RESULT_UNKNOWN;
bool status = false;
/* For use cases related to down stream connection status change,
* PSR and device auto test, refer to function handle_sst_hpd_irq
--
2.16.0.rc1.238.g530d649a79-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [IGT PATCH RFC] tools: Introduce intel_cgroup tool
+cgroups list since this discussion goes back to the general design On Thu, Feb 01, 2018 at 08:27:33PM +, Chris Wilson wrote: > Quoting Matt Roper (2018-02-01 19:56:15) > > intel_cgroup is used to modify i915 cgroup parameters. At the moment only a > > single parameter is supported (GPU priority offset). In the future the > > driver > > may support additional parameters as well (e.g., limits on memory usage). > > > > Signed-off-by: Matt Roper > > +#define I915_CGROUP_PARAM_PRIORITY_OFFSET 0x1 > > Hmm. Could we not avoid drm_ioctl + well known param names and use a > more generic tool to set cgroup attributes? Just feels wrong that a > such a generic interface boils down to a driver specific ioctl. > -Chris There are a few different design choices here, so feedback like this is definitely what I'm looking for with this series. A few goals we should keep in mind as we consider options: * I'd like to keep the attributes we set tied to a driver/device in some manner. E.g., if we have a machine with multiple GPU's, we should be able to set card0 priority independently of card1 priority A DRM or driver ioctl makes this easy, but it certainly isn't the only approach. * Some of the attributes we want to manage don't fall under the design goals of formal cgroup controllers. I.e., they don't care about the hierarchy layout of cgroups at all; they only care about the details of the process' final leaf node. GPU priority as implemented in this series is an example of that. * Other attributes we'll eventually want to control (such as graphics memory usage), probably _will_ want to take the hierarchy design into account, the same way real cgroup controllers like the mem controller do. * The drivers that want to make use of this functionality may be built as modules rather than compiled directly into the kernel. This is important because the cgroups subsystem removed the ability to have cgroup controllers in modules a few years ago. While it might be possible to resurrect module-based cgroup controller support, my impression is that the cgroups community would prefer a separate non-controller mechanism for doing what we want to do. E.g., see https://www.spinics.net/lists/cgroups/msg18674.html for some brief discussion on this topic. I think the nicest interface for setting cgroup attributes would be to find a way to add our own kernfs entries to the cgroup filesystem, the same way real cgroup controllers do. Then we could do something like "echo 123 > /cgroup2/apps/highprio/i915.card0.priority" and not need to call any ioctl's at all. Without creating an actual cgroup controller, I think this might be challenging, but I'm investigating it on the side right now to see if it's a viable option. There are other options that might be suitable as well, but I haven't throught through them in details: * Hang the ioctl() off the cgroup filesystem entry rather than the DRM device node. Not sure if this gains us anything given that we still want to track data on a per-device basis. * Add a cgroup filesystem entry that just handles write() events of the form "drivername:key:value" to trigger driver callbacks. This might be a decent compromise. E.g., we could issue a command like: echo "i915.card0:prio_base:123" > /cgroup2/foo/cgroup.driver_attr and the kernfs handler for that file would looks for a cgroup_driver registered under the name "i915.card0" to figure out what driver callback to call for the key/value data. The second bullet above is growing on me as I think more about it, so I might try implementing that approach in the third version of my series if nobody has other suggestions or feedback. Matt -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Maarten for drm-misc co-maintainer
On Wed, Jan 31, 2018 at 11:21:56AM +0100, Daniel Vetter wrote: > I'm stepping down, also handing all the drm-misc stuff to the new > team. Plan is that Sean handles 4.17, and Maarten then has fun with > 4.18 as his first release. > > Cc: Maarten Lankhorst > Cc: David Airlie > Cc: Gustavo Padovan > Cc: Sean Paul > Acked-by: Sean Paul > Acked-by: Maarten Lankhorst > Signed-off-by: Daniel Vetter Applied to -misc-next. Sincerest thanks for your [ongoing] hard work and support. Sean > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2de1d5540abb..617f07ffddbf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4605,8 +4605,8 @@ F: include/uapi/drm/ > F: include/linux/vga* > > DRM DRIVERS AND MISC GPU PATCHES > -M: Daniel Vetter > M: Gustavo Padovan > +M: Maarten Lankhorst > M: Sean Paul > W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html > S: Maintained > -- > 2.15.1 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101978] [bisected] war thunder performance reduced by ~28%
https://bugs.freedesktop.org/show_bug.cgi?id=101978 --- Comment #9 from Konstantin A. Lepikhov --- BTW running warthunder under brand new 4.15 kernel + latest amd-staging-4.15 gives 25-30+ FPS and the same during the gameplay with performance set to 'auto' and fps spikes up to 50+ with 'high' performance on my R9 Fury. But it seems that 4.15 vanilla kernel doesn't have any patches from staging which improve performance so the results are nearly the same as it was with 4.14. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership
On Thu, Feb 01, 2018 at 08:49:32PM +, Chris Wilson wrote:
> Quoting Matt Roper (2018-02-01 19:53:11)
...
> > +struct cgroup *
> > +cgroup_for_driver_process(struct pid *pid)
> > +{
> > + struct task_struct *task = pid_task(pid, PIDTYPE_PID);
> > +
> > + mutex_lock(&cgroup_mutex);
> > + spin_lock_irq(&css_set_lock);
> > + task_cgroup_from_root(task, &cgrp_dfl_root);
> > + spin_unlock_irq(&css_set_lock);
> > + mutex_unlock(&cgroup_mutex);
>
> Gut feeling says use task = get_pid_task(); if (!task) return NULL and
> put_task_struct(task); for safety.
>
> Shouldn't there be a return here?
Woops, looks like I mis-squashed some of my fixes for this patch in to
patch #4 instead. But yeah, get_pid_task() is better in general.
Matt
> > +}
> -Chris
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] i915 PSR test results and cursor lag
Quoting Andy Lutomirski (2018-02-01 21:04:30) > I got this after a recent suspend/resume: > > Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed. > Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all dirs > Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: > scanning /sys/bus > Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: > scanning /sys/class > Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open > configuration file '/etc/systemd/sleep.conf': No such file or > directory > Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending... > Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal > sender=n/a destination=n/a object=/org/freedesktop/login1 > interface=org.freedesktop.login1.Manager member=PrepareForSleep > cookie=570 reply > Feb 01 09:44:34 laptop systemd-logind[2412]: Got message > type=method_call sender=:1.46 destination=:1.1 > object=/org/freedesktop/login1/session/_32 > interface=org.freedesktop.login1.Session member=ReleaseDevice > Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal > sender=n/a destination=:1.46 > object=/org/freedesktop/login1/session/_32 > interface=org.freedesktop.login1.Session member=PauseDevice cookie > Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane > transform 0: Permission denied > Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed > with (Permission denied), drawing cursor with OpenGL from now on > > But I don't see the word "cursor" in my system logs before the first > suspend. What am I looking for? This is Fedora 27 running a Gnome > Wayland session, but it hasn't been reinstalled in some time, so it's > possible that there are some weird settings sitting around. But I did > check and I have no weird i915 parameters. You are using gnome-shell as the display server. From that it appears to have started off with a HW cursor and switched to a SW cursor after suspend. Did you notice a change in behaviour? After rebooting or just restarting gnome-shell? > Also, are these things potentially related: > > [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential > atomic update failure on pipe A They are just "missed the immediate vblank for the screen update" messages. Should not be related to PSR, but may cause jitter by delaying the odd screen update. > As I'm typing this, I've seen a couple instances of what seems like a > full *second* of cursor latency, but I've only gotten the potential > atomic update failure once. > > And is there any straightforward tracing to do to distinguish between > PSR exit latency and other potential sources of latency? It looks plausible that we could at least report how long it takes the registers to reflect the change in state (but we don't). The best source of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104463] RX 460 fan speed 100%
https://bugs.freedesktop.org/show_bug.cgi?id=104463 Dmitry changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Dmitry --- It is not true -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] i915 PSR test results and cursor lag
On Thu, Feb 1, 2018 at 9:53 AM, Chris Wilson wrote: > Quoting Andy Lutomirski (2018-02-01 17:40:22) >> *However*, I do see one unfortunate side effect of turning on PSR. It >> seems that, when I move my cursor a little bit after a few seconds of >> doing nothing, there seems to be a little bit of lag, as if either a >> few frames are dropped at the beginning of the motion or maybe the >> entire motion is delayed a bit. I don't notice a similar delay when >> typing, so I'm wondering if maybe there's a minor driver bug in which >> the driver doesn't kick the panel out of PSR quite as quickly when the >> cursor is updated as it does when the framebuffer is updated. > > One thing that's important know regarding the cursor is whether the > display server is using a HW cursor or SW cursor. Could you please attach > the log from the display server (or if you are using a stock > distribution that's probably enough to work out what it is using)? > -Chris Looking at the logs, I see a few things. First, I have a few of these: Feb 01 09:24:24 laptop kernel: [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A Feb 01 09:24:48 laptop org.gnome.Shell.desktop[3261]: libinput error: event15 - libinput error: DLL0704:01 06CB:76AE Touchpad: libinput error: kernel bug: Touch jump detected and discarded. Feb 01 09:24:48 laptop org.gnome.Shell.desktop[3261]: See https://wayland.freedesktop.org/libinput/doc/1.9.3/touchpad_jumping_cursor.html for details Feb 01 09:24:50 laptop org.gnome.Shell.desktop[3261]: libinput error: event15 - libinput error: DLL0704:01 06CB:76AE Touchpad: libinput error: kernel bug: Touch jump detected and discarded. Feb 01 09:24:50 laptop org.gnome.Shell.desktop[3261]: See https://wayland.freedesktop.org/libinput/doc/1.9.3/touchpad_jumping_cursor.html for details (Hi, Peter!) So it's entirely possible that what I'm seeing is actually an input issue that's exacerbated by PSR for some bizarre reason. I got this after a recent suspend/resume: Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed. Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all dirs Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scanning /sys/bus Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scanning /sys/class Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open configuration file '/etc/systemd/sleep.conf': No such file or directory Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending... Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1 interface=org.freedesktop.login1.Manager member=PrepareForSleep cookie=570 reply Feb 01 09:44:34 laptop systemd-logind[2412]: Got message type=method_call sender=:1.46 destination=:1.1 object=/org/freedesktop/login1/session/_32 interface=org.freedesktop.login1.Session member=ReleaseDevice Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal sender=n/a destination=:1.46 object=/org/freedesktop/login1/session/_32 interface=org.freedesktop.login1.Session member=PauseDevice cookie Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane transform 0: Permission denied Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed with (Permission denied), drawing cursor with OpenGL from now on But I don't see the word "cursor" in my system logs before the first suspend. What am I looking for? This is Fedora 27 running a Gnome Wayland session, but it hasn't been reinstalled in some time, so it's possible that there are some weird settings sitting around. But I did check and I have no weird i915 parameters. Also, are these things potentially related: [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A As I'm typing this, I've seen a couple instances of what seems like a full *second* of cursor latency, but I've only gotten the potential atomic update failure once. And is there any straightforward tracing to do to distinguish between PSR exit latency and other potential sources of latency? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership
Quoting Matt Roper (2018-02-01 19:53:11)
> Drivers will need to save/restore the appropriate cgroup data for the process
> submitting a driver request. Add an interface for drivers to determine the
> cgroup for the userspace process submitting a driver request.
>
> Cc: Tejun Heo
> Cc: cgro...@vger.kernel.org
> Signed-off-by: Matt Roper
> ---
> include/linux/cgroup.h| 6 ++
> kernel/cgroup/cgroup_driver.c | 24
> 2 files changed, 30 insertions(+)
>
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 0ba1374122c7..05ebfb97bcde 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -842,6 +842,7 @@ void cgroup_driver_release(struct cgroup_driver *drv);
> struct cgroup_driver_data * cgroup_driver_get_data(struct cgroup_driver *drv,
>struct cgroup *cgrp,
>bool *is_new);
> +struct cgroup *cgroup_for_driver_process(struct pid *pid);
>
> #else /* !CONFIG_CGROUP_DRIVER */
>
> @@ -857,6 +858,11 @@ cgroup_driver_get_data(struct cgroup_driver *drv,
> {
> return ERR_PTR(-EINVAL);
> }
> +static inline struct cgroup *
> +cgroup_for_driver_process(struct pid *pid)
> +{
> + return NULL;
> +}
>
> #endif /* !CONFIG_CGROUP_DRIVER */
>
> diff --git a/kernel/cgroup/cgroup_driver.c b/kernel/cgroup/cgroup_driver.c
> index 0d893395dc7b..4f870cbb9212 100644
> --- a/kernel/cgroup/cgroup_driver.c
> +++ b/kernel/cgroup/cgroup_driver.c
> @@ -128,3 +128,27 @@ cgroup_driver_get_data(struct cgroup_driver *drv,
> return data;
> }
> EXPORT_SYMBOL(cgroup_driver_get_data);
> +
> +/**
> + * cgroup_for_driver_process - return the cgroup for a process
> + * @pid: process to lookup cgroup for
> + *
> + * Returns the cgroup from the v2 hierarchy that a process belongs to.
> + * This function is intended to be called from drivers and will obtain
> + * the necessary cgroup locks.
> + *
> + * RETURNS:
> + * Process' cgroup in the default (v2) hierarchy
> + */
> +struct cgroup *
> +cgroup_for_driver_process(struct pid *pid)
> +{
> + struct task_struct *task = pid_task(pid, PIDTYPE_PID);
> +
> + mutex_lock(&cgroup_mutex);
> + spin_lock_irq(&css_set_lock);
> + task_cgroup_from_root(task, &cgrp_dfl_root);
> + spin_unlock_irq(&css_set_lock);
> + mutex_unlock(&cgroup_mutex);
Gut feeling says use task = get_pid_task(); if (!task) return NULL and
put_task_struct(task); for safety.
Shouldn't there be a return here?
> +}
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] i915 PSR test results and cursor lag
Quoting Kristian Høgsberg (2018-02-01 20:22:40) > On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson > wrote: > > > Quoting Andy Lutomirski (2018-02-01 17:40:22) > > > *However*, I do see one unfortunate side effect of turning on PSR. It > > > seems that, when I move my cursor a little bit after a few seconds of > > > doing nothing, there seems to be a little bit of lag, as if either a > > > few frames are dropped at the beginning of the motion or maybe the > > > entire motion is delayed a bit. I don't notice a similar delay when > > > typing, so I'm wondering if maybe there's a min > > or driver bug in which > > > the driver doesn't kick the panel out of PSR quite as quickly when the > > > cursor is updated as it does when the framebuffer is updated. > > > One thing that's important know regarding the cursor is whether the > > display server is using a HW cursor or SW cursor. Could you please attach > > the log from the display server (or if you are using a stock > > distribution that's probably enough to work out what it is using)? > > -Chris > > We had a similar problem for Rockchip in ChromeOS and ended up using an > input handler to let us start the PSR exit as early as possible: Reminds me of mutter devs suggesting that we may like to kick the gpu to max clocks high frequency on any input activity as well. (I'm still not convinced that's a good idea, for mundane typing we barely need to wake up the gpu. :) I guess it all depends on expected wakeup latencies, but I didn't think PSR had multi-frame lag? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [IGT PATCH RFC] tools: Introduce intel_cgroup tool
Quoting Matt Roper (2018-02-01 19:56:15) > intel_cgroup is used to modify i915 cgroup parameters. At the moment only a > single parameter is supported (GPU priority offset). In the future the driver > may support additional parameters as well (e.g., limits on memory usage). > > Signed-off-by: Matt Roper > --- > tools/Makefile.sources | 1 + > tools/intel_cgroup.c | 103 > + > 2 files changed, 104 insertions(+) > create mode 100644 tools/intel_cgroup.c > > diff --git a/tools/Makefile.sources b/tools/Makefile.sources > index abd23a0f..b30216c4 100644 > --- a/tools/Makefile.sources > +++ b/tools/Makefile.sources > @@ -11,6 +11,7 @@ tools_prog_lists =\ > intel_reg \ > intel_backlight \ > intel_bios_dumper \ > + intel_cgroup\ > intel_display_crc \ > intel_display_poller\ > intel_forcewaked\ > diff --git a/tools/intel_cgroup.c b/tools/intel_cgroup.c > new file mode 100644 > index ..ce781b08 > --- /dev/null > +++ b/tools/intel_cgroup.c > @@ -0,0 +1,103 @@ > +/* > + * Copyright © 2018 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS > + * IN THE SOFTWARE. > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "igt.h" > +#include "xf86drm.h" > +#include "xf86drmMode.h" > + > +#define I915_CGROUP_PARAM_PRIORITY_OFFSET 0x1 Hmm. Could we not avoid drm_ioctl + well known param names and use a more generic tool to set cgroup attributes? Just feels wrong that a such a generic interface boils down to a driver specific ioctl. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 7/7] drm/i915: Add context priority & priority offset to debugfs
Quoting Matt Roper (2018-02-01 19:53:15) > Update i915_context_status to include priority information. > > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/i915_debugfs.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 3849ded354e3..e9d8e20155b1 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -1915,6 +1915,9 @@ static int i915_context_status(struct seq_file *m, void > *unused) > seq_putc(m, ctx->remap_slice ? 'R' : 'r'); > seq_putc(m, '\n'); > > + seq_printf(m, "Priority %d (prio offset = %d)\n", > + ctx->priority, ctx->priority_offset); s/prio offset/cgroup offset/ ? "prio" itself I think is redundant given that we are providing further details of "Priority" -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] i915 PSR test results and cursor lag
On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson wrote: > Quoting Andy Lutomirski (2018-02-01 17:40:22) > > *However*, I do see one unfortunate side effect of turning on PSR. It > > seems that, when I move my cursor a little bit after a few seconds of > > doing nothing, there seems to be a little bit of lag, as if either a > > few frames are dropped at the beginning of the motion or maybe the > > entire motion is delayed a bit. I don't notice a similar delay when > > typing, so I'm wondering if maybe there's a min > or driver bug in which > > the driver doesn't kick the panel out of PSR quite as quickly when the > > cursor is updated as it does when the framebuffer is updated. > One thing that's important know regarding the cursor is whether the > display server is using a HW cursor or SW cursor. Could you please attach > the log from the display server (or if you are using a stock > distribution that's probably enough to work out what it is using)? > -Chris We had a similar problem for Rockchip in ChromeOS and ended up using an input handler to let us start the PSR exit as early as possible: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_psr.c#345 It's similar in spirit to the interactive cpufreq governor: https://lwn.net/Articles/662209/ Kristian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 6/7] drm/i915: Introduce 'priority offset' for GPU contexts
Quoting Matt Roper (2018-02-01 19:53:14)
> There are cases where a system integrator may wish to raise/lower the
> priority of GPU workloads being submitted by specific OS process(es),
> independently of how the software self-classifies its own priority.
> Exposing "priority offset" as an i915-specific cgroup parameter will
> enable such system-level configuration.
>
> Normally GPU contexts start with a priority value of 0
> (I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from
> there via other mechanisms. We'd like to provide a system-level input
> to the priority decision that will be taken into consideration, even
> when userspace later attempts to set an absolute priority value via
> I915_CONTEXT_PARAM_PRIORITY. The priority offset introduced here
> provides a base value that will always be added to (or subtracted from)
> the software's self-assigned priority value.
>
> This patch makes priority offset a cgroup-specific value; contexts will
> be created with a priority offset based on the cgroup membership of the
> process creating the context at the time the context is created. Note
> that priority offset is assigned at context creation time; migrating a
> process to a different cgroup or changing the offset associated with a
> cgroup will only affect new context creation and will not alter the
> behavior of existing contexts previously created by the process.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_cgroup.c | 46
> +
> drivers/gpu/drm/i915/i915_drv.h | 7 +
> drivers/gpu/drm/i915/i915_gem_context.c | 6 +++--
> drivers/gpu/drm/i915/i915_gem_context.h | 9 +++
> include/uapi/drm/i915_drm.h | 1 +
> 5 files changed, 67 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cgroup.c
> b/drivers/gpu/drm/i915/i915_cgroup.c
> index 778af895fc00..73f3cfe31d66 100644
> --- a/drivers/gpu/drm/i915/i915_cgroup.c
> +++ b/drivers/gpu/drm/i915/i915_cgroup.c
> @@ -11,6 +11,8 @@
>
> struct i915_cgroup_data {
> struct cgroup_driver_data base;
> +
> + int priority_offset;
> };
>
> static inline struct i915_cgroup_data *
> @@ -72,6 +74,8 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev, void
> *data,
> struct cgroup *cgrp;
> struct file *f;
> struct inode *inode = NULL;
> + struct cgroup_driver_data *cgrpdata;
> + struct i915_cgroup_data *i915data;
> int ret;
>
> if (!dev_priv->i915_cgroups) {
> @@ -125,6 +129,17 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev, void
> *data,
> return ret;
>
> switch (req->param) {
> + case I915_CGROUP_PARAM_PRIORITY_OFFSET:
> + cgrpdata = cgroup_driver_get_data(dev_priv->i915_cgroups,
> cgrp,
> + NULL);
dev_priv is i915. So i915->i915_cgroups?
Could you just have a i915_get_cgroup_data() returning struct
i915_croup_data?
> + if (IS_ERR(cgrpdata))
> + return PTR_ERR(cgrpdata);
> +
> + DRM_DEBUG_DRIVER("Setting cgroup priority offset to %lld\n",
> +req->value);
> + i915data = cgrp_to_i915(cgrpdata);
> + i915data->priority_offset = req->value;
We'll have to consider what bounds we think are sensible, and how
internal policy interacts. Presumably another cgroup-param :)
> + break;
> default:
> DRM_DEBUG_DRIVER("Invalid cgroup parameter %lld\n",
> req->param);
> return -EINVAL;
> @@ -132,3 +147,34 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev, void
> *data,
>
> return 0;
> }
> +
> +/**
> + * i915_cgroup_get_prio_offset() - get prio offset for current proc's cgroup
> + * @dev_priv: drm device
> + * @file_priv: file handle for calling process
> + *
> + * RETURNS:
> + * Priority offset associated with the calling process' cgroup in the default
> + * (v2) hierarchy, otherwise 0 if no explicit priority has been assigned.
> + */
> +int
> +i915_cgroup_get_prio_offset(struct drm_i915_private *dev_priv,
> + struct drm_i915_file_private *file_priv)
> +{
> + struct cgroup *cgrp;
> + struct cgroup_driver_data *cgrpdata;
> +
> + /* Ignore internally-created contexts not associated with a process */
> + if (!file_priv)
> + return 0;
> +
> + cgrp = drm_file_get_cgroup(file_priv->file);
> + if (WARN_ON(!cgrp))
> + return 0;
Ah, this needs to pull from current then not drm_file->pid.
> +
> + cgrpdata = cgroup_driver_get_data(dev_priv->i915_cgroups, cgrp, NULL);
> + if (IS_ERR(cgrpdata))
> + return 0;
> +
> + return cgrp_to_i915(cgrpdata)->priority_offset;
> +}
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 60e3ff6a48bb..313191e5278a 100644
> ---
Re: [PATCH RFC v2 5/7] drm/i915: cgroup integration
Quoting Matt Roper (2018-02-01 19:53:13)
> +#include
> +
> +#include "i915_drv.h"
> +
> +struct i915_cgroup_data {
> + struct cgroup_driver_data base;
> +};
> +
> +static inline struct i915_cgroup_data *
> +cgrp_to_i915(struct cgroup_driver_data *data)
> +{
Document your requirement that base is offset 0 (required for both
i915_cgroup_alloc and i915_cgroup_free).
BUILD_BUG_ON(offsetof(struct i915_cgroup_data, base));
(or make said code flexible)
> + return container_of(data, struct i915_cgroup_data, base);
> +}
> +
> +static struct cgroup_driver_data *
> +i915_cgroup_alloc(struct cgroup_driver *drv)
> +{
> + struct i915_cgroup_data *data;
> +
> + data = kzalloc(sizeof *data, GFP_KERNEL);
> + return &data->base;
> +}
> +
> +static void
> +i915_cgroup_free(struct cgroup_driver_data *data)
> +{
> + kfree(data);
> +}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 5/7] drm/i915: cgroup integration
Quoting Matt Roper (2018-02-01 19:53:13) > Register i915 as a consumer of the cgroup_driver framework and add an ioctl to > allow userspace to set i915-specific parameters associated with cgroups. > > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/i915_cgroup.c | 134 > + > drivers/gpu/drm/i915/i915_drv.c| 7 ++ > drivers/gpu/drm/i915/i915_drv.h| 24 +++ > include/uapi/drm/i915_drm.h| 12 > 6 files changed, 179 insertions(+) > create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index dfd95889f4b7..1c6b53ee76cd 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -23,6 +23,7 @@ config DRM_I915 > select SYNC_FILE > select IOSF_MBI > select CRC32 > + select CGROUP_DRIVER if CGROUPS > help > Choose this option if you have a system that has "Intel Graphics > Media Accelerator" or "HD Graphics" integrated graphics, > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 3bddd8a06806..5f4a21f1a9df 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -47,6 +47,7 @@ i915-y := i915_drv.o \ > i915-$(CONFIG_COMPAT) += i915_ioc32.o > i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o > i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o > +i915-$(CONFIG_CGROUPS) += i915_cgroup.o CONFIG_CGROUP_DRIVER since that's strictly what the code depends on? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v2 5/7] drm/i915: cgroup integration
Quoting Matt Roper (2018-02-01 19:53:13) > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index dfd95889f4b7..1c6b53ee76cd 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -23,6 +23,7 @@ config DRM_I915 > select SYNC_FILE > select IOSF_MBI > select CRC32 > + select CGROUP_DRIVER if CGROUPS Hmm, I was expecting a DRM_CGROUP around here? Was it too small to be worth building conditionally? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH RFC v2 4/7] drm: Add helper to obtain cgroup of drm_file's owning process
Quoting Matt Roper (2018-02-01 19:53:12)
> +/**
> + * drm_file_get_cgroup - obtain cgroup for drm_file's owning process
> + * @file_priv: DRM file
> + *
> + * Obtains the cgroup from a specific hierarchy that the drm_file's owning
> + * process belongs to. The cgroup may be used to set driver-specific
> + * policy (priority, vram usage, etc.).
> + */
> +static inline struct cgroup *
> +drm_file_get_cgroup(struct drm_file *file_priv)
> +{
> + return cgroup_for_driver_process(file_priv->pid);
Just a word of warning file_priv->pid isn't a true indicator of the
attached process's pid. E.g. DRI3 passes the struct drm_file over a UNIX
socket, so pid is Xorg but the actual process is the GL client.
Not sure if we can detect the transfer over the socket, but one
suggestion has been to update file->pid based on who creates a context.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH RFC v2 2/7] kernfs: Export kernfs_get_inode
Quoting Matt Roper (2018-02-01 19:53:10) > Drivers may wish to access a cgroup's inode to perform permission checks on > driver-specific operations. > > Cc: Tejun Heo > Cc: cgro...@vger.kernel.org > Signed-off-by: Matt Roper > --- > fs/kernfs/inode.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c > index a34303981deb..e1e8a0404c5b 100644 > --- a/fs/kernfs/inode.c > +++ b/fs/kernfs/inode.c > @@ -272,6 +272,7 @@ struct inode *kernfs_get_inode(struct super_block *sb, > struct kernfs_node *kn) > > return inode; > } > +EXPORT_SYMBOL(kernfs_get_inode); Will want the _GPL suffix to be in keeping with the other kernfs exports. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[IGT PATCH RFC] tools: Introduce intel_cgroup tool
intel_cgroup is used to modify i915 cgroup parameters. At the moment only a
single parameter is supported (GPU priority offset). In the future the driver
may support additional parameters as well (e.g., limits on memory usage).
Signed-off-by: Matt Roper
---
tools/Makefile.sources | 1 +
tools/intel_cgroup.c | 103 +
2 files changed, 104 insertions(+)
create mode 100644 tools/intel_cgroup.c
diff --git a/tools/Makefile.sources b/tools/Makefile.sources
index abd23a0f..b30216c4 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -11,6 +11,7 @@ tools_prog_lists =\
intel_reg \
intel_backlight \
intel_bios_dumper \
+ intel_cgroup\
intel_display_crc \
intel_display_poller\
intel_forcewaked\
diff --git a/tools/intel_cgroup.c b/tools/intel_cgroup.c
new file mode 100644
index ..ce781b08
--- /dev/null
+++ b/tools/intel_cgroup.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "igt.h"
+#include "xf86drm.h"
+#include "xf86drmMode.h"
+
+#define I915_CGROUP_PARAM_PRIORITY_OFFSET 0x1
+
+char short_opts[] = "p:";
+struct option long_opts[] = {
+ { "set-prio", required_argument, NULL, 'p'},
+ { 0 },
+};
+
+static void usage(void)
+{
+ puts("Usage:");
+ printf(" intel_cgroup --set-prio= \n");
+}
+
+int main(int argc, char **argv)
+{
+ int drm_fd, cgrp_fd;
+ struct drm_i915_cgroup_param req;
+ int opt, ret;
+ struct {
+ bool do_prio;
+ int prio_val;
+ } updates = { 0 };
+
+ while ((opt = getopt_long(argc, argv, short_opts, long_opts, NULL)) !=
-1) {
+ switch (opt) {
+ case 'p':
+ updates.do_prio = true;
+ updates.prio_val = atoi(optarg);
+ break;
+ default:
+ igt_assert(false);
+ }
+ }
+
+ if (argc - optind != 1) {
+ usage();
+ return 1;
+ }
+
+ drm_fd = drm_open_driver(DRIVER_INTEL);
+ if (drm_fd < 0) {
+ perror("Invalid DRM device");
+ return 1;
+ }
+
+ cgrp_fd = open(argv[optind], O_RDONLY|O_DIRECTORY, 0);
+ if (cgrp_fd < 0) {
+ perror("Invalid cgroup directory");
+ return 1;
+ }
+
+ req.cgroup_fd = cgrp_fd;
+ req.flags = 0;
+
+ if (updates.do_prio) {
+ req.param = I915_CGROUP_PARAM_PRIORITY_OFFSET;
+ req.value = updates.prio_val;
+
+ ret = drmIoctl(drm_fd, DRM_IOCTL_I915_CGROUP_SETPARAM, &req);
+ if (ret)
+ perror("Failed to set cgroup parameter");
+ }
+
+ close(cgrp_fd);
+ close(drm_fd);
+
+ return ret;
+}
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v2 6/7] drm/i915: Introduce 'priority offset' for GPU contexts
There are cases where a system integrator may wish to raise/lower the
priority of GPU workloads being submitted by specific OS process(es),
independently of how the software self-classifies its own priority.
Exposing "priority offset" as an i915-specific cgroup parameter will
enable such system-level configuration.
Normally GPU contexts start with a priority value of 0
(I915_CONTEXT_DEFAULT_PRIORITY) and then may be adjusted up/down from
there via other mechanisms. We'd like to provide a system-level input
to the priority decision that will be taken into consideration, even
when userspace later attempts to set an absolute priority value via
I915_CONTEXT_PARAM_PRIORITY. The priority offset introduced here
provides a base value that will always be added to (or subtracted from)
the software's self-assigned priority value.
This patch makes priority offset a cgroup-specific value; contexts will
be created with a priority offset based on the cgroup membership of the
process creating the context at the time the context is created. Note
that priority offset is assigned at context creation time; migrating a
process to a different cgroup or changing the offset associated with a
cgroup will only affect new context creation and will not alter the
behavior of existing contexts previously created by the process.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_cgroup.c | 46 +
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/i915_gem_context.c | 6 +++--
drivers/gpu/drm/i915/i915_gem_context.h | 9 +++
include/uapi/drm/i915_drm.h | 1 +
5 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cgroup.c
b/drivers/gpu/drm/i915/i915_cgroup.c
index 778af895fc00..73f3cfe31d66 100644
--- a/drivers/gpu/drm/i915/i915_cgroup.c
+++ b/drivers/gpu/drm/i915/i915_cgroup.c
@@ -11,6 +11,8 @@
struct i915_cgroup_data {
struct cgroup_driver_data base;
+
+ int priority_offset;
};
static inline struct i915_cgroup_data *
@@ -72,6 +74,8 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev, void *data,
struct cgroup *cgrp;
struct file *f;
struct inode *inode = NULL;
+ struct cgroup_driver_data *cgrpdata;
+ struct i915_cgroup_data *i915data;
int ret;
if (!dev_priv->i915_cgroups) {
@@ -125,6 +129,17 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev, void
*data,
return ret;
switch (req->param) {
+ case I915_CGROUP_PARAM_PRIORITY_OFFSET:
+ cgrpdata = cgroup_driver_get_data(dev_priv->i915_cgroups, cgrp,
+ NULL);
+ if (IS_ERR(cgrpdata))
+ return PTR_ERR(cgrpdata);
+
+ DRM_DEBUG_DRIVER("Setting cgroup priority offset to %lld\n",
+req->value);
+ i915data = cgrp_to_i915(cgrpdata);
+ i915data->priority_offset = req->value;
+ break;
default:
DRM_DEBUG_DRIVER("Invalid cgroup parameter %lld\n", req->param);
return -EINVAL;
@@ -132,3 +147,34 @@ i915_cgroup_setparam_ioctl(struct drm_device *dev, void
*data,
return 0;
}
+
+/**
+ * i915_cgroup_get_prio_offset() - get prio offset for current proc's cgroup
+ * @dev_priv: drm device
+ * @file_priv: file handle for calling process
+ *
+ * RETURNS:
+ * Priority offset associated with the calling process' cgroup in the default
+ * (v2) hierarchy, otherwise 0 if no explicit priority has been assigned.
+ */
+int
+i915_cgroup_get_prio_offset(struct drm_i915_private *dev_priv,
+ struct drm_i915_file_private *file_priv)
+{
+ struct cgroup *cgrp;
+ struct cgroup_driver_data *cgrpdata;
+
+ /* Ignore internally-created contexts not associated with a process */
+ if (!file_priv)
+ return 0;
+
+ cgrp = drm_file_get_cgroup(file_priv->file);
+ if (WARN_ON(!cgrp))
+ return 0;
+
+ cgrpdata = cgroup_driver_get_data(dev_priv->i915_cgroups, cgrp, NULL);
+ if (IS_ERR(cgrpdata))
+ return 0;
+
+ return cgrp_to_i915(cgrpdata)->priority_offset;
+}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60e3ff6a48bb..313191e5278a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2920,6 +2920,8 @@ int i915_cgroup_init(struct drm_i915_private *dev_priv);
int i915_cgroup_setparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
void i915_cgroup_shutdown(struct drm_i915_private *dev_priv);
+int i915_cgroup_get_prio_offset(struct drm_i915_private *dev_priv,
+ struct drm_i915_file_private *file_priv);
#else
static inline int
i915_cgroup_init(struct drm_i915_private *dev_priv)
@@ -2933,6 +2935,11 @@ i915_cgroup_s
[PATCH RFC v2 7/7] drm/i915: Add context priority & priority offset to debugfs
Update i915_context_status to include priority information.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3849ded354e3..e9d8e20155b1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1915,6 +1915,9 @@ static int i915_context_status(struct seq_file *m, void
*unused)
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
seq_putc(m, '\n');
+ seq_printf(m, "Priority %d (prio offset = %d)\n",
+ ctx->priority, ctx->priority_offset);
+
for_each_engine(engine, dev_priv, id) {
struct intel_context *ce = &ctx->engine[engine->id];
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v2 5/7] drm/i915: cgroup integration
Register i915 as a consumer of the cgroup_driver framework and add an ioctl to
allow userspace to set i915-specific parameters associated with cgroups.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_cgroup.c | 134 +
drivers/gpu/drm/i915/i915_drv.c| 7 ++
drivers/gpu/drm/i915/i915_drv.h| 24 +++
include/uapi/drm/i915_drm.h| 12
6 files changed, 179 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd95889f4b7..1c6b53ee76cd 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,7 @@ config DRM_I915
select SYNC_FILE
select IOSF_MBI
select CRC32
+ select CGROUP_DRIVER if CGROUPS
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3bddd8a06806..5f4a21f1a9df 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -47,6 +47,7 @@ i915-y := i915_drv.o \
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
+i915-$(CONFIG_CGROUPS) += i915_cgroup.o
# GEM code
i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_cgroup.c
b/drivers/gpu/drm/i915/i915_cgroup.c
new file mode 100644
index ..778af895fc00
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_cgroup.c
@@ -0,0 +1,134 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * i915_cgroup.c - Linux cgroups integration for i915
+ *
+ * Copyright (C) 2018 Intel Corporation
+ */
+
+#include
+
+#include "i915_drv.h"
+
+struct i915_cgroup_data {
+ struct cgroup_driver_data base;
+};
+
+static inline struct i915_cgroup_data *
+cgrp_to_i915(struct cgroup_driver_data *data)
+{
+ return container_of(data, struct i915_cgroup_data, base);
+}
+
+static struct cgroup_driver_data *
+i915_cgroup_alloc(struct cgroup_driver *drv)
+{
+ struct i915_cgroup_data *data;
+
+ data = kzalloc(sizeof *data, GFP_KERNEL);
+ return &data->base;
+}
+
+static void
+i915_cgroup_free(struct cgroup_driver_data *data)
+{
+ kfree(data);
+}
+
+static struct cgroup_driver_funcs i915_cgroup_funcs = {
+ .alloc_data = i915_cgroup_alloc,
+ .free_data = i915_cgroup_free,
+};
+
+int
+i915_cgroup_init(struct drm_i915_private *dev_priv)
+{
+ dev_priv->i915_cgroups = cgroup_driver_init(&i915_cgroup_funcs);
+ if (IS_ERR(dev_priv->i915_cgroups))
+ return PTR_ERR(dev_priv->i915_cgroups);
+
+ return 0;
+}
+
+void
+i915_cgroup_shutdown(struct drm_i915_private *dev_priv)
+{
+ cgroup_driver_release(dev_priv->i915_cgroups);
+}
+
+/**
+ * i915_cgroup_setparam_ioctl - ioctl to alter i915 settings for a cgroup
+ * @dev: DRM device
+ * @data: data pointer for the ioctl
+ * @file_priv: DRM file handle for the ioctl call
+ *
+ * Allows i915-specific parameters to be set for a Linux cgroup.
+ */
+int
+i915_cgroup_setparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_cgroup_param *req = data;
+ struct cgroup *cgrp;
+ struct file *f;
+ struct inode *inode = NULL;
+ int ret;
+
+ if (!dev_priv->i915_cgroups) {
+ DRM_DEBUG_DRIVER("No support for driver-specific cgroup
data\n");
+ return -EINVAL;
+ }
+
+ /* We don't actually support any flags yet. */
+ if (req->flags) {
+ DRM_DEBUG_DRIVER("Invalid flags\n");
+ return -EINVAL;
+ }
+
+ /*
+* Make sure the file descriptor really is a cgroup fd and is on the
+* v2 hierarchy.
+*/
+ cgrp = cgroup_get_from_fd(req->cgroup_fd);
+ if (IS_ERR(cgrp)) {
+ DRM_DEBUG_DRIVER("Invalid cgroup file descriptor\n");
+ return PTR_ERR(cgrp);
+ }
+
+ /*
+* Access control: The strategy for using cgroups in a given
+* environment is generally determined by the system integrator
+* and/or OS vendor, so the specific policy about who can/can't
+* manipulate them tends to be domain-specific (and may vary
+* depending on the location in the cgroup hierarchy). Rather than
+* trying to tie permission on this ioctl to a DRM-specific concepts
+* like DRM master, we'll allow cgroup parameters to be set by any
+* process that has been granted write access on the cgroup's
+* virtual file system (i.e., the same permissions that would
+* generally be needed to update the virtual files provided by
+
[PATCH RFC v2 4/7] drm: Add helper to obtain cgroup of drm_file's owning process
Signed-off-by: Matt Roper
---
include/drm/drm_file.h| 20
kernel/cgroup/cgroup_driver.c | 12 ++--
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868451a5..72ac40530ad3 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
@@ -378,4 +379,23 @@ void drm_event_cancel_free(struct drm_device *dev,
void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event
*e);
void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
+#ifdef CONFIG_CGROUPS
+/**
+ * drm_file_get_cgroup - obtain cgroup for drm_file's owning process
+ * @file_priv: DRM file
+ *
+ * Obtains the cgroup from a specific hierarchy that the drm_file's owning
+ * process belongs to. The cgroup may be used to set driver-specific
+ * policy (priority, vram usage, etc.).
+ */
+static inline struct cgroup *
+drm_file_get_cgroup(struct drm_file *file_priv)
+{
+ return cgroup_for_driver_process(file_priv->pid);
+}
+#else
+static inline struct cgroup *
+drm_file_get_cgroup(struct drm_file *file_priv) { return NULL; }
+#endif
+
#endif /* _DRM_FILE_H_ */
diff --git a/kernel/cgroup/cgroup_driver.c b/kernel/cgroup/cgroup_driver.c
index 4f870cbb9212..db0e268b9546 100644
--- a/kernel/cgroup/cgroup_driver.c
+++ b/kernel/cgroup/cgroup_driver.c
@@ -4,6 +4,7 @@
#include
#include
+#include
/*
* General data structure returned by cgroup_driver_init() and used as a
@@ -143,12 +144,19 @@ EXPORT_SYMBOL(cgroup_driver_get_data);
struct cgroup *
cgroup_for_driver_process(struct pid *pid)
{
- struct task_struct *task = pid_task(pid, PIDTYPE_PID);
+ struct task_struct *task;
+ struct cgroup *cgrp;
+
+ read_lock(&tasklist_lock);
+ task = pid_task(pid, PIDTYPE_PID);
+ read_unlock(&tasklist_lock);
mutex_lock(&cgroup_mutex);
spin_lock_irq(&css_set_lock);
- task_cgroup_from_root(task, &cgrp_dfl_root);
+ cgrp = task_cgroup_from_root(task, &cgrp_dfl_root);
spin_unlock_irq(&css_set_lock);
mutex_unlock(&cgroup_mutex);
+
+ return cgrp;
}
EXPORT_SYMBOL(cgroup_for_driver_process);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v2 2/7] kernfs: Export kernfs_get_inode
Drivers may wish to access a cgroup's inode to perform permission checks on driver-specific operations. Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt Roper --- fs/kernfs/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/kernfs/inode.c b/fs/kernfs/inode.c index a34303981deb..e1e8a0404c5b 100644 --- a/fs/kernfs/inode.c +++ b/fs/kernfs/inode.c @@ -272,6 +272,7 @@ struct inode *kernfs_get_inode(struct super_block *sb, struct kernfs_node *kn) return inode; } +EXPORT_SYMBOL(kernfs_get_inode); /* * The kernfs_node serves as both an inode and a directory entry for -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership
Drivers will need to save/restore the appropriate cgroup data for the process
submitting a driver request. Add an interface for drivers to determine the
cgroup for the userspace process submitting a driver request.
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
include/linux/cgroup.h| 6 ++
kernel/cgroup/cgroup_driver.c | 24
2 files changed, 30 insertions(+)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 0ba1374122c7..05ebfb97bcde 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -842,6 +842,7 @@ void cgroup_driver_release(struct cgroup_driver *drv);
struct cgroup_driver_data * cgroup_driver_get_data(struct cgroup_driver *drv,
struct cgroup *cgrp,
bool *is_new);
+struct cgroup *cgroup_for_driver_process(struct pid *pid);
#else /* !CONFIG_CGROUP_DRIVER */
@@ -857,6 +858,11 @@ cgroup_driver_get_data(struct cgroup_driver *drv,
{
return ERR_PTR(-EINVAL);
}
+static inline struct cgroup *
+cgroup_for_driver_process(struct pid *pid)
+{
+ return NULL;
+}
#endif /* !CONFIG_CGROUP_DRIVER */
diff --git a/kernel/cgroup/cgroup_driver.c b/kernel/cgroup/cgroup_driver.c
index 0d893395dc7b..4f870cbb9212 100644
--- a/kernel/cgroup/cgroup_driver.c
+++ b/kernel/cgroup/cgroup_driver.c
@@ -128,3 +128,27 @@ cgroup_driver_get_data(struct cgroup_driver *drv,
return data;
}
EXPORT_SYMBOL(cgroup_driver_get_data);
+
+/**
+ * cgroup_for_driver_process - return the cgroup for a process
+ * @pid: process to lookup cgroup for
+ *
+ * Returns the cgroup from the v2 hierarchy that a process belongs to.
+ * This function is intended to be called from drivers and will obtain
+ * the necessary cgroup locks.
+ *
+ * RETURNS:
+ * Process' cgroup in the default (v2) hierarchy
+ */
+struct cgroup *
+cgroup_for_driver_process(struct pid *pid)
+{
+ struct task_struct *task = pid_task(pid, PIDTYPE_PID);
+
+ mutex_lock(&cgroup_mutex);
+ spin_lock_irq(&css_set_lock);
+ task_cgroup_from_root(task, &cgrp_dfl_root);
+ spin_unlock_irq(&css_set_lock);
+ mutex_unlock(&cgroup_mutex);
+}
+EXPORT_SYMBOL(cgroup_for_driver_process);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v2 1/7] cgroup: Allow drivers to store data associated with a cgroup
There are cases where drivers need to adjust behavior or control
device-specific resources according to the type of clients (processes)
submitting requests. Linux cgroups are a natural fit for this type of
resource control and policy management, so we need a way for drivers to
associate their own driver-specific and device-specific data with
individual cgroups.
This is different than the cgroup controller support that exists today
in several important ways:
* Drivers may be built as modules (and unloaded/reloaded) which is not
something cgroup controllers support today.
* Drivers may wish to provide their own interface to allow userspace to
adjust driver-specific settings (e.g., via a driver ioctl rather than
via the kernfs filesystem).
* A single driver may be managing multiple devices and wish to maintain
different driver-specific cgroup data for each.
To use this mechanism, drivers should call cgroup_driver_init() to
register themselves and provide provide handler functions for allocating
driver-specific data structures; this call will return a handle that can
be used to lookup the driver-specific data associated with the device.
Drivers managing multiple devices that wish to track separate data for
each device may register themselves multiple times (e.g., a graphics
driver might call cgroup_driver_init() for each drm_device it manages).
At runtime, drivers may call cgroup_driver_get_data() to fetch the
driver-specific data associated with a cgroup. The driver-specific data
(which should be a driver-defined subclass of 'struct
cgroup_driver_data') will be allocated if one doesn't already exist.
Management of driver-specific data by the cgroups framework is protected
by cgroup_mutex, but drivers are responsible for performing their own
synchronization on the per-cgroup data they receive, if necessary. Note
that driver-specific data for a cgroup will only be allocated if/when
the driver first requests data for that cgroup. The driver data will
also be automatically destroyed if the cgroup it belongs to is removed.
Finally, drivers should cgroup_driver_release() on driver unload to
destroy all of their driver-specific data.
Note that technically these interfaces aren't restricted to drivers
(other non-driver parts of the kernel could make use of them as well).
I expect drivers to be the primary consumers of this interface and
couldn't think of a more appropriate generic name (the term "subsystem"
would probably be more accurate, but that's already used by cgroup
controllers).
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
include/linux/cgroup-defs.h | 37
include/linux/cgroup.h| 27 +
init/Kconfig | 4 ++
kernel/cgroup/Makefile| 1 +
kernel/cgroup/cgroup.c| 1 +
kernel/cgroup/cgroup_driver.c | 130 ++
6 files changed, 200 insertions(+)
create mode 100644 kernel/cgroup/cgroup_driver.c
diff --git a/include/linux/cgroup-defs.h b/include/linux/cgroup-defs.h
index 8b7fd8eeccee..5728e3afc95f 100644
--- a/include/linux/cgroup-defs.h
+++ b/include/linux/cgroup-defs.h
@@ -8,6 +8,7 @@
#ifndef _LINUX_CGROUP_DEFS_H
#define _LINUX_CGROUP_DEFS_H
+#include
#include
#include
#include
@@ -27,6 +28,7 @@ struct cgroup;
struct cgroup_root;
struct cgroup_subsys;
struct cgroup_taskset;
+struct cgroup_driver;
struct kernfs_node;
struct kernfs_ops;
struct kernfs_open_file;
@@ -307,6 +309,22 @@ struct cgroup_stat {
struct prev_cputime prev_cputime;
};
+/*
+ * Driver-specific cgroup data. Drivers should subclass this structure with
+ * their own fields for data that should be stored alongside individual
+ * cgroups.
+ */
+struct cgroup_driver_data {
+ /* Driver this data structure is associated with */
+ struct cgroup_driver *drv;
+
+ /* Node in cgroup's data hashtable */
+ struct hlist_node cgroupnode;
+
+ /* Node in driver's data list; used to cleanup on driver unload */
+ struct list_head drivernode;
+};
+
struct cgroup {
/* self css with NULL ->ss, points back to this cgroup */
struct cgroup_subsys_state self;
@@ -427,6 +445,12 @@ struct cgroup {
/* used to store eBPF programs */
struct cgroup_bpf bpf;
+ /*
+* list of cgroup_driver_data structures; used to manage
+* driver-specific data associated with individual cgroups
+*/
+ DECLARE_HASHTABLE(driver_data, 4);
+
/* ids of the ancestors at each level including self */
int ancestor_ids[];
};
@@ -662,6 +686,19 @@ struct cgroup_subsys {
unsigned int depends_on;
};
+/* Function table for handling driver-specific cgroup data */
+struct cgroup_driver_funcs {
+ /* Allocates driver-specific data for a cgroup */
+ struct cgroup_driver_data *(*alloc_data)(struct cgroup_driver *drv);
+
+ /*
+* Frees a driver-specific datastructure.
+
[PATCH RFC v2 0/7] DRM management via cgroups
This is a second iteration of the patches originally posted here: https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html Please see the original cover letter to understand the general goal and justification for this work. This series makes the following important changes to the design from the first version: * The "cgroup helper library" has been removed from the DRM core; the early patches of this series introduce an enhancement to the cgroup subsystem itself which will grant drivers the ability to save/restore their own driver-specific data structures associated with individual cgroups. Drivers may subclass the cgroup_driver_data structure to store any kind of per-cgroup data they want, not just integer key/value pairs as the helper library from version 1 of this series did. Moving this functionality directly into cgroups will also allow other parts of the kernel to potentially benefit from this functionality, not just DRM drivers. * The general graphics-specific ioctl to set cgroup parameters has moved from the DRM core to i915. This was pretty much an arbitrary choice I made while re-writing the new version of the series; I don't have a strong opinion over whether the ioctl goes in the DRM core or stays i915-specific. I'd appreciate feedback from other driver teams as to whether they anticipate cgroup integration being useful for their drivers and use cases (e.g., for controlling things like GPU memory usage, priority settings, etc.). I'll move the ioctl back to the DRM core in the next iteration if there's interest from other driver teams. * The i915-specific usage of this functionality is to adjust GPU priority for groups of processes. Based on Chris' feedback, I've made this control a "priority offset" rather than just a starting priority, so that the change applied by cgroup will be added to the explicitly-set context priority rather than being overwritten by it. At the moment i915 still just assigns the priority offset one time at context creation and doesn't alter it if the process migrates between cgroups at runtime or if the cgroup has a new value assigned to it; such changes only affect the priority offset of new contexts created by a process. I'm open to feedback on whether we should also make cgroup changes affect existing GPU context(s) from a process. As noted on v1 of my patch series, cgroup control of graphics driver concepts is expected to be done mostly during system startup (e.g., a sysv-init script or a systemd recipe written by a system integrator and custom to their own setup), so we don't really need a terribly complicated userspace, just a simple tool that can be called by appropriate scripts/recipes to set the desired policy. I've re-written the tool from v1 of the patch series as an i-g-t tool this time and will send it as followup email shortly. Still on my TODO list (once I gather some more general feedback and move out of the early RFC stage): * Document this more fully in both the cgroups documentation and the i915 kerneldoc. * Write some i-g-t tests to exercise the ioctl and all the corner cases. Matt Roper (7): cgroup: Allow drivers to store data associated with a cgroup kernfs: Export kernfs_get_inode cgroup: Add interface to allow drivers to lookup process cgroup membership drm: Add helper to obtain cgroup of drm_file's owning process drm/i915: cgroup integration drm/i915: Introduce 'priority offset' for GPU contexts drm/i915: Add context priority & priority offset to debugfs drivers/gpu/drm/i915/Kconfig| 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_cgroup.c | 180 drivers/gpu/drm/i915/i915_debugfs.c | 3 + drivers/gpu/drm/i915/i915_drv.c | 7 ++ drivers/gpu/drm/i915/i915_drv.h | 31 ++ drivers/gpu/drm/i915/i915_gem_context.c | 6 +- drivers/gpu/drm/i915/i915_gem_context.h | 9 ++ fs/kernfs/inode.c | 1 + include/drm/drm_file.h | 20 include/linux/cgroup-defs.h | 37 +++ include/linux/cgroup.h | 33 ++ include/uapi/drm/i915_drm.h | 13 +++ init/Kconfig| 4 + kernel/cgroup/Makefile | 1 + kernel/cgroup/cgroup.c | 1 + kernel/cgroup/cgroup_driver.c | 162 17 files changed, 508 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c create mode 100644 kernel/cgroup/cgroup_driver.c -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-4.15 388/829] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'; did you mean 'vread'?
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.15
head: 8a2a2ac361e69f4ad68f9a675a8b86dcfe9d82a4
commit: d5fe2b46627629c30a513761bf03093314ac7b18 [388/829] ASoC: AMD: enable
ACP3x drivers build
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d5fe2b46627629c30a513761bf03093314ac7b18
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
>> sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function
>> 'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
>> sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function
>> 'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
^~
vwrite
sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of
>> function 'devm_ioremap'; did you mean 'devm_kmemdup'?
>> [-Werror=implicit-function-declaration]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^~~~
devm_kmemdup
sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes
pointer from integer without a cast [-Wint-conversion]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^
cc1: some warnings being treated as errors
vim +28 sound/soc/amd/raven/acp3x.h
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 25
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 26 static inline u32
rv_readl(void __iomem *base_addr)
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 27 {
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 @28return readl(base_addr
- ACP3x_PHY_BASE_ADDRESS);
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 29 }
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 30
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 31 static inline void
rv_writel(u32 val, void __iomem *base_addr)
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 32 {
d7f22cdb Maruthi Srinivas Bayyavarapu 2017-03-27 @33writel(val, base_addr -
ACP3x_PHY_BASE_ADDRESS);
:: The code at line 28 was first introduced by commit
:: d7f22cdb21cb5e2b9dab65b38921bd309fb5fafc ASoC: AMD: add ACP3.0 PCI driver
:: TO: Maruthi Srinivas Bayyavarapu
:: CC: Alex Deucher
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm/adreno: Use generic function to load firmware to a buffer object
Move a5xx specific code to load firmware into a buffer object to
the generic Adreno code. This will come in useful for future targets.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 23 ++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 19 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 ++
3 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 517e19c..a4f68af 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -497,25 +497,6 @@ static int a5xx_preempt_start(struct msm_gpu *gpu)
return a5xx_idle(gpu, ring) ? 0 : -EINVAL;
}
-
-static struct drm_gem_object *a5xx_ucode_load_bo(struct msm_gpu *gpu,
- const struct firmware *fw, u64 *iova)
-{
- struct drm_gem_object *bo;
- void *ptr;
-
- ptr = msm_gem_kernel_new_locked(gpu->dev, fw->size - 4,
- MSM_BO_UNCACHED | MSM_BO_GPU_READONLY, gpu->aspace, &bo, iova);
-
- if (IS_ERR(ptr))
- return ERR_CAST(ptr);
-
- memcpy(ptr, &fw->data[4], fw->size - 4);
-
- msm_gem_put_vaddr(bo);
- return bo;
-}
-
static int a5xx_ucode_init(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -523,7 +504,7 @@ static int a5xx_ucode_init(struct msm_gpu *gpu)
int ret;
if (!a5xx_gpu->pm4_bo) {
- a5xx_gpu->pm4_bo = a5xx_ucode_load_bo(gpu,
+ a5xx_gpu->pm4_bo = adreno_fw_create_bo(gpu,
adreno_gpu->fw[ADRENO_FW_PM4], &a5xx_gpu->pm4_iova);
if (IS_ERR(a5xx_gpu->pm4_bo)) {
@@ -536,7 +517,7 @@ static int a5xx_ucode_init(struct msm_gpu *gpu)
}
if (!a5xx_gpu->pfp_bo) {
- a5xx_gpu->pfp_bo = a5xx_ucode_load_bo(gpu,
+ a5xx_gpu->pfp_bo = adreno_fw_create_bo(gpu,
adreno_gpu->fw[ADRENO_FW_PFP], &a5xx_gpu->pfp_iova);
if (IS_ERR(a5xx_gpu->pfp_bo)) {
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 4a8ee5e..87133c6 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -162,6 +162,25 @@ static int adreno_load_fw(struct adreno_gpu *adreno_gpu)
return 0;
}
+struct drm_gem_object *adreno_fw_create_bo(struct msm_gpu *gpu,
+ const struct firmware *fw, u64 *iova)
+{
+ struct drm_gem_object *bo;
+ void *ptr;
+
+ ptr = msm_gem_kernel_new_locked(gpu->dev, fw->size - 4,
+ MSM_BO_UNCACHED | MSM_BO_GPU_READONLY, gpu->aspace, &bo, iova);
+
+ if (IS_ERR(ptr))
+ return ERR_CAST(ptr);
+
+ memcpy(ptr, &fw->data[4], fw->size - 4);
+
+ msm_gem_put_vaddr(bo);
+
+ return bo;
+}
+
int adreno_hw_init(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 499092a..d6b0e7b 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -206,6 +206,8 @@ static inline int adreno_is_a530(struct adreno_gpu *gpu)
int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value);
const struct firmware *adreno_request_fw(struct adreno_gpu *adreno_gpu,
const char *fwname);
+struct drm_gem_object *adreno_fw_create_bo(struct msm_gpu *gpu,
+ const struct firmware *fw, u64 *iova);
int adreno_hw_init(struct msm_gpu *gpu);
void adreno_recover(struct msm_gpu *gpu);
void adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm/adreno: Define a list of firmware files to load per target
The number and type of firmware files required differs for each
target. Instead of using a fixed struct member for each possible
firmware file use a generic list of files that should be loaded
on boot. Use some semi-target specific enums to help each target
find the appropriate firmware(s) that it needs to load.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 8 +++---
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 8 +++---
drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 13 -
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8 +++---
drivers/gpu/drm/msm/adreno/a5xx_power.c| 26 +-
drivers/gpu/drm/msm/adreno/adreno_device.c | 44 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 33 --
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 12 ++--
8 files changed, 80 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 4baef27..1dd84d3 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -256,8 +256,8 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
*/
/* Load PM4: */
- ptr = (uint32_t *)(adreno_gpu->pm4->data);
- len = adreno_gpu->pm4->size / 4;
+ ptr = (uint32_t *)(adreno_gpu->fw[ADRENO_FW_PM4]->data);
+ len = adreno_gpu->fw[ADRENO_FW_PM4]->size / 4;
DBG("loading PM4 ucode version: %x", ptr[1]);
gpu_write(gpu, REG_AXXX_CP_DEBUG,
@@ -268,8 +268,8 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_AXXX_CP_ME_RAM_DATA, ptr[i]);
/* Load PFP: */
- ptr = (uint32_t *)(adreno_gpu->pfp->data);
- len = adreno_gpu->pfp->size / 4;
+ ptr = (uint32_t *)(adreno_gpu->fw[ADRENO_FW_PFP]->data);
+ len = adreno_gpu->fw[ADRENO_FW_PFP]->size / 4;
DBG("loading PFP ucode version: %x", ptr[5]);
gpu_write(gpu, REG_A3XX_CP_PFP_UCODE_ADDR, 0);
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 8199a4b..2884b1b 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -274,16 +274,16 @@ static int a4xx_hw_init(struct msm_gpu *gpu)
return ret;
/* Load PM4: */
- ptr = (uint32_t *)(adreno_gpu->pm4->data);
- len = adreno_gpu->pm4->size / 4;
+ ptr = (uint32_t *)(adreno_gpu->fw[ADRENO_FW_PM4]->data);
+ len = adreno_gpu->fw[ADRENO_FW_PM4]->size / 4;
DBG("loading PM4 ucode version: %u", ptr[0]);
gpu_write(gpu, REG_A4XX_CP_ME_RAM_WADDR, 0);
for (i = 1; i < len; i++)
gpu_write(gpu, REG_A4XX_CP_ME_RAM_DATA, ptr[i]);
/* Load PFP: */
- ptr = (uint32_t *)(adreno_gpu->pfp->data);
- len = adreno_gpu->pfp->size / 4;
+ ptr = (uint32_t *)(adreno_gpu->fw[ADRENO_FW_PFP]->data);
+ len = adreno_gpu->fw[ADRENO_FW_PFP]->size / 4;
DBG("loading PFP ucode version: %u", ptr[0]);
gpu_write(gpu, REG_A4XX_CP_PFP_UCODE_ADDR, 0);
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
index cef0978..6b27941 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
@@ -123,15 +123,12 @@ static int show(struct seq_file *m, void *arg)
mutex_lock(&dev->struct_mutex);
- if (adreno_gpu->pm4) {
- release_firmware(adreno_gpu->pm4);
- adreno_gpu->pm4 = NULL;
- }
+ release_firmware(adreno_gpu->fw[ADRENO_FW_PM4]);
+ adreno_gpu->fw[ADRENO_FW_PM4] = NULL;
+
+ release_firmware(adreno_gpu->fw[ADRENO_FW_PFP]);
+ adreno_gpu->fw[ADRENO_FW_PFP] = NULL;
- if (adreno_gpu->pfp) {
- release_firmware(adreno_gpu->pfp);
- adreno_gpu->pfp = NULL;
- }
if (a5xx_gpu->pm4_bo) {
if (a5xx_gpu->pm4_iova)
msm_gem_put_iova(a5xx_gpu->pm4_bo, gpu->aspace);
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 795fe11..517e19c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -523,8 +523,8 @@ static int a5xx_ucode_init(struct msm_gpu *gpu)
int ret;
if (!a5xx_gpu->pm4_bo) {
- a5xx_gpu->pm4_bo = a5xx_ucode_load_bo(gpu, adreno_gpu->pm4,
- &a5xx_gpu->pm4_iova);
+ a5xx_gpu->pm4_bo = a5xx_ucode_load_bo(gpu,
+ adreno_gpu->fw[ADRENO_FW_PM4], &a5xx_gpu->pm4_iova);
if (IS_ERR(a5xx_gpu->pm4_bo)) {
ret = PTR_ERR(a5xx_gpu->pm4_bo);
@@ -536,8 +536,8 @@ static int a5xx_ucode_init(struct msm_gpu *gpu)
}
if (!a5xx_gpu->pfp_bo) {
- a5xx_gpu->pfp_bo = a5xx_ucode_load_bo(gpu, adreno_gpu->pfp,
- &a5xx_gpu->pfp_iova);
+
[v2 0/2] drm/msm/adreno: Reorganize firmware loading
This is new refresh of the outstanding changes from https://patchwork.freedesktop.org/series/36923/. Rob expressed concern about the microcode code duplication per target so on his suggestions we did something different. The developer will specify a list of applicable microcode filenames per target. Some semi-target specific enums are used to coordinate between the device list and the driver code to figure out the position of the desired data in the list. This gets rid of the hardcoded struct members and makes it flexible enough for future targets like a6xx to have their own unique list of firmware names that don't match the past. Jordan Crouse (2): drm/msm/adreno: Define a list of firmware files to load per target drm/msm/adreno: Use generic function to load firmware to a buffer object drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 8 ++--- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 8 ++--- drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 13 +++- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 27 +++- drivers/gpu/drm/msm/adreno/a5xx_power.c| 26 --- drivers/gpu/drm/msm/adreno/adreno_device.c | 44 - drivers/gpu/drm/msm/adreno/adreno_gpu.c| 52 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h| 14 ++-- 8 files changed, 101 insertions(+), 91 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/6] iommu/arm-smmu: Add the device_link between masters and smmu
Hi,
On 1/31/2018 6:39 PM, Robin Murphy wrote:
On 19/01/18 11:43, Vivek Gautam wrote:
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.
Don't we need to balance this with a device_link_del() in
.remove_device (like exynos-iommu does)?
Right. Will add device_link_del() call. Thanks for pointing out.
regards
Vivek
Robin.
Signed-off-by: Sricharan R
---
drivers/iommu/arm-smmu.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 95478bfb182c..33bbcfedb896 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1367,6 +1367,7 @@ static int arm_smmu_add_device(struct device *dev)
struct arm_smmu_device *smmu;
struct arm_smmu_master_cfg *cfg;
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ struct device_link *link;
int i, ret;
if (using_legacy_binding) {
@@ -1428,6 +1429,16 @@ static int arm_smmu_add_device(struct device
*dev)
pm_runtime_put_sync(smmu->dev);
+ /*
+ * Establish the link between smmu and master, so that the
+ * smmu gets runtime enabled/disabled as per the master's
+ * needs.
+ */
+ link = device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME);
+ if (!link)
+ dev_warn(smmu->dev, "Unable to create device link between %s
and %s\n",
+ dev_name(smmu->dev), dev_name(dev));
+
return 0;
out_cfg_free:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)
On Thu, Feb 1, 2018 at 12:08 AM, Harry Wentland wrote: > On 2018-01-31 09:31 AM, Chris Chiu wrote: >> 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 chance to get into X. It also happens >> during shutdown. Then I tried to build kernel from >> git://people.freedesktop.org/~agd5f/linux on branch >> amd-staging-drm-next with head on commit "drm: Fix trailing semicolon" >> and update the linux-firmware. Things seem to get better, only 1 oops >> observed. Here's the oops >> https://gist.github.com/mschiu77/1a68f27272b24775b2040acdb474cdd3. > > Hi Chris, > > what are the steps to reproduce this oops? > > Does it reproduce all the time or is it intermittent? > > Can you send a dmesg with amdgpu.dc_log=1, in addition to drm.debug=0xe? > > Thanks, > Harry > I did nothing special to reproduce the oops. Boot and sometimes it just shows blank screen but still responds to magic sysrq. So I reboot and take the journal log. It's intermittent, I ran into it 2 times during 13 reboots. The logs are listed as follows https://gist.github.com/mschiu77/9307d1ca0acd046cc6817f8cad63d79c https://gist.github.com/mschiu77/fa81110f93428721f017cb9fbfd06fbe One more log here. It enters X OK but after few minutes the display went black and only a mouse cursor left. But the mouse cursor can't even move. So I do a sysrq reboot again. The last error is "" [ 636.312759] endless kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:41:crtc-0] flip_done timed out [ 646.552344] endless kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:41:crtc-0] flip_done timed out "" full log here https://gist.github.com/mschiu77/c8696e5fefb17bb1c53598214fb4e382 Only 4 times I can login X, blank screen or hangs w/o responding to magic sysrq for the rest. I took a picture of the only panic although I think it's not about amdgpu. It's here. https://pasteboard.co/H5CUvxk.jpg Hope they can be helpful. Chris >> However, I still get stuck on the following messages during boot very >> often >> "" >> [4.998241] endless kernel: [drm] amdgpu kernel modesetting enabled. >> [4.998288] endless kernel: checking generic (e000 7f) vs >> hw (e000 1000) >> [4.998289] endless kernel: fb: switching to amdgpudrmfb from EFI VGA >> "" >> I turned on drm.debug=0xe while booting, but no more information at this >> point. >> Anything I can do at this point? >> >> And there's 1 more information may be helpful. Sometimes the >> system boots OK with the blank screen, I can't switch to virtual >> console, but it did respond to the magic sys-rq key. The dmesg with >> drm.debug=0xe is here >> https://gist.github.com/mschiu77/291e47b1f07dc52be9461c55c820464c. >> >> I'm pretty sure it's due to the amdgpu driver. Because when I boot >> with my own kernel which disables the amdgpu driver, all these >> symptoms went away. Please suggest anything I can do for this. Thanks >> >> Chris >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] backlight: adp5520: document sysfs attributes
On 26.01.2018 15:54, Aishwarya Pant wrote: Add documentation for sysfs interface of adp5520/adp5501 analog devices backlight driver by reading code and looking through git commit logs. Signed-off-by: Aishwarya Pant Acked-by: Michael Hennerich --- .../ABI/testing/sysfs-class-backlight-adp5520 | 31 ++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp5520 diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 b/Documentation/ABI/testing/sysfs-class-backlight-adp5520 new file mode 100644 index ..34b6ebafa210 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-adp5520 @@ -0,0 +1,31 @@ +sysfs interface for analog devices adp5520(01) backlight driver +--- + +The backlight brightness control operates at three different levels for the +adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark +(level 3). By default the brightness operates at the daylight brightness level. + +What: /sys/class/backlight//daylight_max +What: /sys/class/backlight//office_max +What: /sys/class/backlight//dark_max +Date: Sep, 2009 +KernelVersion: v2.6.32 +Contact: Michael Hennerich +Description: + (RW) Maximum current setting for the backlight when brightness + is at one of the three levels (daylight, office or dark). This + is an input code between 0 and 127, which is transformed to a + value between 0 mA and 30 mA using linear or non-linear + algorithms. + +What: /sys/class/backlight//daylight_dim +What: /sys/class/backlight//office_dim +What: /sys/class/backlight//dark_dim +Date: Sep, 2009 +KernelVersion: v2.6.32 +Contact: Michael Hennerich +Description: + (RW) Dim current setting for the backlight when brightness is at + one of the three levels (daylight, office or dark). This is an + input code between 0 and 127, which is transformed to a value + between 0 mA and 30 mA using linear or non-linear algorithms. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
On 2/1/2018 5:03 PM, Sricharan R wrote:
Hi Robin,
On 1/31/2018 6:36 PM, Robin Murphy wrote:
On 19/01/18 11:43, Vivek Gautam wrote:
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Signed-off-by: Sricharan R
[vivek: Cleanup pm runtime calls]
Signed-off-by: Vivek Gautam
---
drivers/iommu/arm-smmu.c | 45 +
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 21acffe91a1c..95478bfb182c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -914,11 +914,15 @@ static void arm_smmu_destroy_domain_context(struct
iommu_domain *domain)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
- int irq;
+ int ret, irq;
if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
return;
+ ret = pm_runtime_get_sync(smmu->dev);
+ if (ret)
+ return;
+
/*
* Disable the context bank and free the page tables before freeing
* it.
@@ -933,6 +937,8 @@ static void arm_smmu_destroy_domain_context(struct
iommu_domain *domain)
free_io_pgtable_ops(smmu_domain->pgtbl_ops);
__arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
+
+ pm_runtime_put_sync(smmu->dev);
}
static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
@@ -1408,12 +1414,20 @@ static int arm_smmu_add_device(struct device *dev)
while (i--)
cfg->smendx[i] = INVALID_SMENDX;
- ret = arm_smmu_master_alloc_smes(dev);
+ ret = pm_runtime_get_sync(smmu->dev);
if (ret)
goto out_cfg_free;
+ ret = arm_smmu_master_alloc_smes(dev);
+ if (ret) {
+ pm_runtime_put_sync(smmu->dev);
+ goto out_cfg_free;
Please keep to the existing pattern and put this on the cleanup path with a new
label, rather than inline.
ok.
+ }
+
iommu_device_link(&smmu->iommu, dev);
+ pm_runtime_put_sync(smmu->dev);
+
return 0;
out_cfg_free:
@@ -1428,7 +1442,7 @@ static void arm_smmu_remove_device(struct device *dev)
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct arm_smmu_master_cfg *cfg;
struct arm_smmu_device *smmu;
-
+ int ret;
if (!fwspec || fwspec->ops != &arm_smmu_ops)
return;
@@ -1436,8 +1450,21 @@ static void arm_smmu_remove_device(struct device *dev)
cfg = fwspec->iommu_priv;
smmu = cfg->smmu;
+ /*
+ * The device link between the master device and
+ * smmu is already purged at this point.
+ * So enable the power to smmu explicitly.
+ */
I don't understand this comment, especially since we don't even introduce
device links until the following patch... :/
This is because the core device_del callback, does a device_links_purge for
that device,
before calling the remove_device notifier. As a result, have to explicitly
turn on the
power to iommu. Probably the comment should be removed, rest of the places we
don't
explain why we are turning on explicitly.
Yes, will remove the comment here.
+
+ ret = pm_runtime_get_sync(smmu->dev);
+ if (ret)
+ return;
+
iommu_device_unlink(&smmu->iommu, dev);
arm_smmu_master_free_smes(fwspec);
+
+ pm_runtime_put_sync(smmu->dev);
+
iommu_group_remove_device(dev);
kfree(fwspec->iommu_priv);
iommu_fwspec_free(dev);
@@ -2130,6 +2157,14 @@ static int arm_smmu_device_probe(struct platform_device
*pdev)
if (err)
return err;
+ platform_set_drvdata(pdev, smmu);
+
+ pm_runtime_enable(dev);
+
+ err = pm_runtime_get_sync(dev);
+ if (err)
+ return err;
+
err = arm_smmu_device_cfg_probe(smmu);
if (err)
return err;
@@ -2171,9 +2206,9 @@ static int arm_smmu_device_probe(struct platform_device
*pdev)
return err;
}
- platform_set_drvdata(pdev, smmu);
arm_smmu_device_reset(smmu);
arm_smmu_test_smr_masks(smmu);
+ pm_runtime_put_sync(dev);
/*
* For ACPI and generic DT bindings, an SMMU will be probed before
@@ -2212,6 +2247,8 @@ static int arm_smmu_device_remove(struct platform_device
*pdev)
/* Turn the thing off */
writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+ pm_runtime_force_suspend(smmu->dev);
Why do we need this? I guess it might be a Qualcomm-ism as I don't see anyone
else calling it from .remove other than a couple of other qcom_* drivers. Given
that we only get here during system shutdown (or the root user intentionally
pissing about with driver unbinding), it doesn't seem like a point where power
saving really ma
Re: [PATCH 02/11] video: fbdev: kconfig: Remove blank help text
2018-02-02 1:56 GMT+09:00 Ulf Magnusson : > On Thu, Feb 1, 2018 at 4:52 PM, Bartlomiej Zolnierkiewicz > wrote: >> >> Hi, >> >> On Wednesday, January 31, 2018 10:34:21 AM Ulf Magnusson wrote: >>> Blank help texts are probably either a typo, a Kconfig misunderstanding, >>> or some kind of half-committing to adding a help text (in which case a >>> TODO comment would be clearer, if the help text really can't be added >>> right away). >>> >>> Best to remove them, IMO. FYI. I picked up this patch to kbuild because I need this to suppress warning messages introduced by 11/11. I am planning to send a PR for this series. -- Best Regards Masahiro Yamada ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] backlight: adp8860: document sysfs attributes
On 26.01.2018 15:55, Aishwarya Pant wrote: Add documentation for sysfs interface of adp8860 series backlight devices by reading through code and git commits. Signed-off-by: Aishwarya Pant Acked-by: Michael Hennerich --- .../ABI/testing/sysfs-class-backlight-adp8860 | 54 ++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp8860 diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 b/Documentation/ABI/testing/sysfs-class-backlight-adp8860 new file mode 100644 index ..54d61c788b1b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-adp8860 @@ -0,0 +1,54 @@ +sysfs interface for analog devices adp8860 backlight driver +--- + +The backlight brightness control operates at three different levels for the +adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) and +dark (level 3). By default the brightness operates at the daylight brightness +level. + +What: /sys/class/backlight//ambient_light_level +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich +Description: + (RO) 13-bit conversion value for the first light sensor—high + byte (Bit 12 to Bit 8). The value is updated every 80 ms (when + the light sensor is enabled). + + +What: /sys/class/backlight//ambient_light_zone +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich +Description: + (RW) Read or write the specific level at which the backlight + operates. Value "0" enables automatic ambient light sensing, and + values "1", "2" or "3" set the control to daylight, office or + dark respectively. + + +What: /sys/class/backlight//l1_daylight_max +What: /sys/class/backlight//l2_office_max +What: /sys/class/backlight//l3_dark_max +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich +Description: + (RW) Maximum current setting for the backlight when brightness + is at one of the three levels (daylight, office or dark). This + is an input code between 0 and 127, which is transformed to a + value between 0 mA and 30 mA using linear or non-linear + algorithms. + + +What: /sys/class/backlight//l1_daylight_dim +What: /sys/class/backlight//l2_office_dim +What: /sys/class/backlight//l3_dark_dim +Date: Apr, 2010 +KernelVersion: v2.6.35 +Contact: Michael Hennerich +Description: + (RW) Dim current setting for the backlight when brightness is at + one of the three levels (daylight, office or dark). This is an + input code between 0 and 127, which is transformed to a value + between 0 mA and 30 mA using linear or non-linear algorithms. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly
Il 01/02/2018 11:14, Maxime Ripard ha scritto: On Sat, Jan 27, 2018 at 11:07:09PM +0100, Giulio Benetti wrote: I don't really know what the polarity of D0 would be just by judging at that capture, but we would have noticed if the colors were inverted for quite some time now. D0-D23 are correct. With that capture, I mean to show you instead dclk is inverted, as dclk samples D0 on falling edge. Ah right, DCLK being the first channel? Yes, sorry I didn't place a label on channels So 0 is NEGEDGE and 1 is POSEDGE(1/3 of clock phase). 1/3 clock phase seems enough to me to be considered POSEDGE, 2/3 instead risks to go too much to the right of D0(even if it could work). Do you have captures with both settings? Not now, but asap I'm going to take. Here we are: 1/3 phase: https://pasteboard.co/H4VehON.png 2/3 phase: https://pasteboard.co/H4Veq8a.png Yellow: D0 Blue: DCLK As you can see: 1/3 phase has DCLK rising edge almost in the middle of D0 2/3 phase has DCLK rising edge that comes too late I would go for "1/3 phase" for Rising edge and "normal phase" for Falling edge. What do you think? It seems fair. This need a whole lot of comments though :) Yes, then, do I proceed resubmitting both corrected patches with corrected commit logs? That it's going to be a nightmare... We've advertised since the very beginning something, and we're about to break it. I'm not sure we want to do that. I can take care about that. But I also think that a lot of displays work because they use only DE-mode, almost ignoring HSync and VSync signals(HV-mode). In any case I have to produce these patches because of my company's board based on A20 and A33, and modify defconfig according to it. The only technical nightmare I see is to produce a commit for every defconfig to be modified and copy-paste che commit-log substituing board name(1-2 days of work). Problem is testing, but we're speaking about something that probably was badly working, but you couldn't see it on display. So I think this is only an improvement at the end. I'm sorry I've taken bad news. Drink 1 glass of Spritz to go over! :) IMHO I think that we have only to take care about displays that don't have DE signal. If DE signal exists, then displays are driven through DE only for back and front porch as I know, and on most displays I've used, Hsync and VSync are ignored. DE is used not only for Data Enable, but also for sync the very beginning of frame, the rest of syncing is done by pause between every line sent. This is should be why nobody noticed it before, I think almost every display is used in DE mode only. So, if we fix bug for HSync and VSync, risk should be very low. Indeed, everybody or almost, use sync:3 because display ignore those 2 signals (HSync and VSYnc) in favour of DE. And I don't know how many people checked with oscilloscope signals after getting display working in a few. I know I did, but I apparently didn't pay attention to that and was more focused on getting the timings right :) But clearly this is a separate discussion that needs to be held on the U-Boot ML. Ok, so I'd create a patch regarding HSync and VSync polarity and send it to uboot ML. Maxime -- Giulio Benetti R&D Manager & Advanced Research MICRONOVA SRL Sede: Via A. Niedda 3 - 35010 Vigonza (PD) Tel. 049/8931563 - Fax 049/8931346 Cod.Fiscale - P.IVA 02663420285 Capitale Sociale € 26.000 i.v. Iscritta al Reg. Imprese di Padova N. 02663420285 Numero R.E.A. 258642 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: lvds: tidyup header explanation
From: Kuninori Morimoto panel-lvds.c is for LVDS Panel Driver, not R-Car Display Unit CRTCs Reported-by: Koji Matsuoka Signed-off-by: Kuninori Morimoto --- drivers/gpu/drm/panel/panel-lvds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-lvds.c b/drivers/gpu/drm/panel/panel-lvds.c index b5e3994..c8075a8 100644 --- a/drivers/gpu/drm/panel/panel-lvds.c +++ b/drivers/gpu/drm/panel/panel-lvds.c @@ -1,5 +1,5 @@ /* - * rcar_du_crtc.c -- R-Car Display Unit CRTCs + * panel-lvds.c -- LVDS Panel Driver * * Copyright (C) 2016 Laurent Pinchart * Copyright (C) 2016 Renesas Electronics Corporation -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] video: fbdev: kconfig: Remove blank help text
On Thu, Feb 1, 2018 at 4:52 PM, Bartlomiej Zolnierkiewicz
wrote:
>
> Hi,
>
> On Wednesday, January 31, 2018 10:34:21 AM Ulf Magnusson wrote:
>> Blank help texts are probably either a typo, a Kconfig misunderstanding,
>> or some kind of half-committing to adding a help text (in which case a
>> TODO comment would be clearer, if the help text really can't be added
>> right away).
>>
>> Best to remove them, IMO.
>
> How about actually adding some meaningful help texts instead
> (as a general rule each user visible option should have valid
> help text)?
>
>> Signed-off-by: Ulf Magnusson
>> ---
>> drivers/video/fbdev/Kconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index 6962b4583fd7..11e699f1062b 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -1156,7 +1156,6 @@ config FB_I810_I2C
>> bool "Enable DDC Support"
>> depends on FB_I810 && FB_I810_GTF
>> select FB_DDC
>> - help
>
> Please add a missing help text instead (take a look at FB_SAVAGE_I2C
> config option to see how a valid help text entry should look like).
The FB_I810_I2C option was added in 74f6ae84b23 ("[PATCH] i810fb: Add
i2c/DDC support"). What do you think about adding this bit from the
commit message as the help text?
Add DDC/I2C support for i810fb. This will allow the driver to get display
information, especially for monitors with fickle timings.
I'm not familiar with this code, so I don't want to do too much
guessing myself. :)
>
> In the longer term we should consider removing *_I2C config options
> and just make the main config options always enable I2C subsystem
> directly if needed/useful (some fbdev drivers are doing it this way
> already).
>
>> config FB_LE80578
>> tristate "Intel LE80578 (Vermilion) support"
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
Cheers,
Ulf
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] backlight: lp855x: document sysfs attributes
On Thu, Feb 01, 2018 at 11:06:42AM +, Daniel Thompson wrote:
> On Fri, Jan 26, 2018 at 08:23:00PM +0530, Aishwarya Pant wrote:
> > Add documentation for sysfs interface of Texas Instruments lp855x
> > backlight driver by reading code and looking through git commit logs.
> >
> > Signed-off-by: Aishwarya Pant
> > ---
> > .../ABI/testing/sysfs-class-backlight-lp855x | 19
> > +++
> > 1 file changed, 19 insertions(+)
> > create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-lp855x
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lp855x
> > b/Documentation/ABI/testing/sysfs-class-backlight-lp855x
> > new file mode 100644
> > index ..5b9d38958875
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-class-backlight-lp855x
> > @@ -0,0 +1,19 @@
> > +sysfs interface for Texas Instruments lp855x backlight driver
> > +
> > +
> > +What: /sys/class/backlight//chip_id
> > +Date: Mar, 2012
> > +KernelVersion: v3.10
> > +Contact: Milo Kim
> > +Description:
> > + (RO) Displays the lp8755x chip id. Possible values are:
> > + lp8550, lp8551, lp8552, lp8553, lp8555, lp8556 or lp8557.
> > +
> > +
> > +What: /sys/class/backlight//bl_ctl_mode
> > +Date: Mar, 2012
> > +KernelVersion: v3.10
> > +Contact: Linux kernel mailing list
> > +Description:
> > + (RO) Displays whether the brightness is controlled by the pwm
> > + input("pwm based) or the i2c register("register based").
>
> Since like the first patch in the series, these look like they are for
> debugging. That thread is still active but whatever the outcome of that
> thread please assume it also applies to this patch.
All right, I'll wait for conclusion on that thread before I re-send the patchset
with the updates.
Aishwarya
>
>
> Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
clang warning: implicit conversion in intel_ddi.c:1481
Dear Rodrigo Vivi, Ville Syrjälä,
My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We
intend to use static analysis tools on the kernel source to identify,
analyze and report issues. As a very first step, we are looking into
clang compiler warnings and will then move to more sophisticated tools.
When compiling Linux 4.15 with clang, we have discovered that your commit
2952cd6fb4cc ("drm/i915: Let's use more enum intel_dpll_id pll_id.")
introduced the following warning:
drivers/gpu/drm/i915/intel_ddi.c:1481:30: warning: implicit conversion from
enumeration type 'enum port' to different enumeration type 'enum intel_dpll_id'
[-Wenum-conversion]
enum intel_dpll_id pll_id = port;
To reproduce it, you can compile Linux 4.15 with clang with this command:
make HOSTCC=clang-5.0 defconfig && make -j32 HOSTCC=clang-5.0 CC=clang-5.0
If you don't have clang installed in your system, you can use this simple
docker setup to compile the kernel with clang:
wget
https://raw.githubusercontent.com/bulwahn/linux-kernel-analysis/master/docker/kernel-clang/Dockerfile
&& \
docker build -t kernel-clang . && \
docker run -v :/linux/ kernel-clang /bin/sh -c
"cd linux && make CC=clang-5.0 clean && make HOSTCC=clang-5.0 defconfig && make
-j32 HOSTCC=clang-5.0 CC=clang-5.0"
While we were doing our analysis on 4.15, we noticed that you already
resolved this warning on linux-next with your work in commit bb911536f07e
("drm/i915: Eliminate pll->state usage from bxt_calc_pll_link()"). So,
since it is resolved on linux-next and we expect that this commit will be
merged in the merge window for 4.16, there is probably nothing further to
do.
Linux 4.15 is shipped with this clang warning, but we don't see the
crucial need to provide a backport commit to the stable branch for 4.15.
We just wanted to inform you about our analysis of this clang warning.
Ultimately the final call if you would like to address this clang warning
in 4.15 is yours.
Best regards,
Ozan & Lukas___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
Hi Robin,
On 1/31/2018 6:36 PM, Robin Murphy wrote:
> On 19/01/18 11:43, Vivek Gautam wrote:
>> From: Sricharan R
>>
>> The smmu device probe/remove and add/remove master device callbacks
>> gets called when the smmu is not linked to its master, that is without
>> the context of the master device. So calling runtime apis in those places
>> separately.
>>
>> Signed-off-by: Sricharan R
>> [vivek: Cleanup pm runtime calls]
>> Signed-off-by: Vivek Gautam
>> ---
>> drivers/iommu/arm-smmu.c | 45 +
>> 1 file changed, 41 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 21acffe91a1c..95478bfb182c 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -914,11 +914,15 @@ static void arm_smmu_destroy_domain_context(struct
>> iommu_domain *domain)
>> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> struct arm_smmu_device *smmu = smmu_domain->smmu;
>> struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
>> - int irq;
>> + int ret, irq;
>> if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
>> return;
>> + ret = pm_runtime_get_sync(smmu->dev);
>> + if (ret)
>> + return;
>> +
>> /*
>> * Disable the context bank and free the page tables before freeing
>> * it.
>> @@ -933,6 +937,8 @@ static void arm_smmu_destroy_domain_context(struct
>> iommu_domain *domain)
>> free_io_pgtable_ops(smmu_domain->pgtbl_ops);
>> __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
>> +
>> + pm_runtime_put_sync(smmu->dev);
>> }
>> static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
>> @@ -1408,12 +1414,20 @@ static int arm_smmu_add_device(struct device *dev)
>> while (i--)
>> cfg->smendx[i] = INVALID_SMENDX;
>> - ret = arm_smmu_master_alloc_smes(dev);
>> + ret = pm_runtime_get_sync(smmu->dev);
>> if (ret)
>> goto out_cfg_free;
>> + ret = arm_smmu_master_alloc_smes(dev);
>> + if (ret) {
>> + pm_runtime_put_sync(smmu->dev);
>> + goto out_cfg_free;
>
> Please keep to the existing pattern and put this on the cleanup path with a
> new label, rather than inline.
ok.
>
>> + }
>> +
>> iommu_device_link(&smmu->iommu, dev);
>> + pm_runtime_put_sync(smmu->dev);
>> +
>> return 0;
>> out_cfg_free:
>> @@ -1428,7 +1442,7 @@ static void arm_smmu_remove_device(struct device *dev)
>> struct iommu_fwspec *fwspec = dev->iommu_fwspec;
>> struct arm_smmu_master_cfg *cfg;
>> struct arm_smmu_device *smmu;
>> -
>> + int ret;
>> if (!fwspec || fwspec->ops != &arm_smmu_ops)
>> return;
>> @@ -1436,8 +1450,21 @@ static void arm_smmu_remove_device(struct device *dev)
>> cfg = fwspec->iommu_priv;
>> smmu = cfg->smmu;
>> + /*
>> + * The device link between the master device and
>> + * smmu is already purged at this point.
>> + * So enable the power to smmu explicitly.
>> + */
>
> I don't understand this comment, especially since we don't even introduce
> device links until the following patch... :/
>
This is because the core device_del callback, does a device_links_purge for
that device,
before calling the remove_device notifier. As a result, have to explicitly
turn on the
power to iommu. Probably the comment should be removed, rest of the places we
don't
explain why we are turning on explicitly.
>> +
>> + ret = pm_runtime_get_sync(smmu->dev);
>> + if (ret)
>> + return;
>> +
>> iommu_device_unlink(&smmu->iommu, dev);
>> arm_smmu_master_free_smes(fwspec);
>> +
>> + pm_runtime_put_sync(smmu->dev);
>> +
>> iommu_group_remove_device(dev);
>> kfree(fwspec->iommu_priv);
>> iommu_fwspec_free(dev);
>> @@ -2130,6 +2157,14 @@ static int arm_smmu_device_probe(struct
>> platform_device *pdev)
>> if (err)
>> return err;
>> + platform_set_drvdata(pdev, smmu);
>> +
>> + pm_runtime_enable(dev);
>> +
>> + err = pm_runtime_get_sync(dev);
>> + if (err)
>> + return err;
>> +
>> err = arm_smmu_device_cfg_probe(smmu);
>> if (err)
>> return err;
>> @@ -2171,9 +2206,9 @@ static int arm_smmu_device_probe(struct
>> platform_device *pdev)
>> return err;
>> }
>> - platform_set_drvdata(pdev, smmu);
>> arm_smmu_device_reset(smmu);
>> arm_smmu_test_smr_masks(smmu);
>> + pm_runtime_put_sync(dev);
>> /*
>> * For ACPI and generic DT bindings, an SMMU will be probed before
>> @@ -2212,6 +2247,8 @@ static int arm_smmu_device_remove(struct
>> platform_device *pdev)
>> /* Turn the thing off */
>> writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
>> + pm_runtime_force_suspend(smmu->dev);
>
> Why do we need this? I guess it might be a Qualcomm-ism as I don't see anyone
> else calling it from
[Bug 102261] [CI] rtcwake failed with 256
https://bugs.freedesktop.org/show_bug.cgi?id=102261 Imre Deak changed: What|Removed |Added Assignee|imre.d...@intel.com |dri-devel@lists.freedesktop ||.org QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | CC||petri.latv...@intel.com, ||tomi.p.sarv...@intel.com Component|DRM/Intel |IGT --- Comment #21 from Imre Deak --- Based on the latest comment on https://bugzilla.kernel.org/show_bug.cgi?id=196691 the proposed solution is to make the trim/discard operation more fine-grained by setting discard_max_bytes. Adding CI people, and changing the component accordingly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v6 5/5] drm/nouveau: Introduce NvPmEnableGating option
This adds the NvPmEnableGating config option to nouveau, which can be used to enable or disable clockgating for supported chipsets. Enabling can be done by passing config=NvPmEnableGating=1 To nouveau. If your chipset supports it, you'll see a message in your kernel log indicating that clockgating is enabled. Since clockgating has only had limited testing thus far, we leave this option disabled by default for now. Signed-off-by: Lyude Paul Reviewed-by: Martin Peres --- drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c index de07bc07abdb..bf62303571b3 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c @@ -434,7 +434,9 @@ nvkm_therm_ctor(struct nvkm_therm *therm, struct nvkm_device *device, therm->attr_get = nvkm_therm_attr_get; therm->attr_set = nvkm_therm_attr_set; therm->mode = therm->suspend = -1; /* undefined */ - therm->clkgating_enabled = false; + + therm->clkgating_enabled = nvkm_boolopt(device->cfgopt, + "NvPmEnableGating", false); } int -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v6 4/5] drm/nouveau: Add support for SLCG for Kepler2
That's right, there's still more power saving to go! Starting with
kepler 2, nvidia hardware has an additional level of clockgating known
as second level clockgating. The details of this are not exact, but it
seems to work by waiting for a collection of dependent hardware blocks
to be gated before taking affect. As with the previous series, this
results in another noticeable drop in power consumption and is
programmed in the same manner.
Signed-off-by: Lyude Paul
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c | 93 ++
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
index a528894231d0..4da916a9fc73 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
@@ -187,6 +187,87 @@ gk110_clkgate_blcg_init_gpc_mp_0[] = {
{}
};
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_main_0[] = {
+ { 0x4041f4, 1, 0x },
+ { 0x409894, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_unk_0[] = {
+ { 0x406004, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_sked_0[] = {
+ { 0x407004, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_ctxctl_0[] = {
+ { 0x41a894, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_unk_0[] = {
+ { 0x418504, 1, 0x },
+ { 0x41860c, 1, 0x },
+ { 0x41868c, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_esetup_0[] = {
+ { 0x41882c, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_zcull_0[] = {
+ { 0x418974, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_l1c_0[] = {
+ { 0x419cd8, 2, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_unk_1[] = {
+ { 0x419c74, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_mp_0[] = {
+ { 0x419fd4, 1, 0x4a4a },
+ { 0x419fdc, 1, 0x0014 },
+ { 0x419fe4, 1, 0x },
+ { 0x419ff4, 1, 0x1724 },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_ppc_0[] = {
+ { 0x41be2c, 1, 0x },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_pcounter_0[] = {
+ { 0x1be018, 1, 0x01ff },
+ { 0x1bc018, 1, 0x01ff },
+ { 0x1b8018, 1, 0x01ff },
+ { 0x1b4124, 1, 0x },
+ {}
+};
+
static const struct nvkm_therm_clkgate_pack
gk110_clkgate_pack[] = {
{ gk104_clkgate_blcg_init_main_0 },
@@ -214,6 +295,18 @@ gk110_clkgate_pack[] = {
{ gk104_clkgate_blcg_init_rop_0 },
{ gk104_clkgate_blcg_init_rop_crop_0 },
{ gk104_clkgate_blcg_init_pxbar_0 },
+ { gk110_clkgate_slcg_init_main_0 },
+ { gk110_clkgate_slcg_init_unk_0 },
+ { gk110_clkgate_slcg_init_sked_0 },
+ { gk110_clkgate_slcg_init_gpc_ctxctl_0 },
+ { gk110_clkgate_slcg_init_gpc_unk_0 },
+ { gk110_clkgate_slcg_init_gpc_esetup_0 },
+ { gk110_clkgate_slcg_init_gpc_zcull_0 },
+ { gk110_clkgate_slcg_init_gpc_l1c_0 },
+ { gk110_clkgate_slcg_init_gpc_unk_1 },
+ { gk110_clkgate_slcg_init_gpc_mp_0 },
+ { gk110_clkgate_slcg_init_gpc_ppc_0 },
+ { gk110_clkgate_slcg_init_pcounter_0 },
{}
};
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v6 3/5] drm/nouveau: Add support for BLCG on Kepler2
Same as the previous patch, but for Kepler2 now
Signed-off-by: Lyude Paul
Reviewed-by: Martin Peres
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c| 62
drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c| 71 +++
5 files changed, 139 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
index adb78f7d083a..92be0e5269c6 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
@@ -75,6 +75,7 @@ int mcp89_fb_new(struct nvkm_device *, int, struct nvkm_fb
**);
int gf100_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gf108_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gk104_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
+int gk110_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gk20a_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gm107_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gm200_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 74bd09b1c893..7590a30b7ff0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -1812,7 +1812,7 @@ nvf0_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
- .fb = gk104_fb_new,
+ .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1850,7 +1850,7 @@ nvf1_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
- .fb = gk104_fb_new,
+ .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1888,7 +1888,7 @@ nv106_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
- .fb = gk104_fb_new,
+ .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1926,7 +1926,7 @@ nv108_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
- .fb = gk104_fb_new,
+ .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
index a38e19b61c1d..a528894231d0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
@@ -22,6 +22,7 @@
* Authors: Ben Skeggs
*/
#include "gf100.h"
+#include "gk104.h"
#include "ctxgf100.h"
#include
@@ -156,6 +157,66 @@ gk110_gr_pack_mmio[] = {
{}
};
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_sked_0[] = {
+ { 0x407000, 1, 0x4041 },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_gcc_0[] = {
+ { 0x419020, 1, 0x0042 },
+ { 0x419038, 1, 0x0042 },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_l1c_0[] = {
+ { 0x419cd4, 2, 0x4042 },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_mp_0[] = {
+ { 0x419fd0, 1, 0x4043 },
+ { 0x419fd8, 1, 0x4049 },
+ { 0x419fe0, 2, 0x4042 },
+ { 0x419ff0, 1, 0x0046 },
+ { 0x419ff8, 1, 0x4042 },
+ { 0x419f90, 1, 0x4042 },
+ {}
+};
+
+static const struct nvkm_therm_clkgate_pack
+gk110_clkgate_pack[] = {
+ { gk104_clkgate_blcg_init_main_0 },
+ { gk104_clkgate_blcg_init_rstr2d_0 },
+ { gk104_clkgate_blcg_init_unk_0 },
+ { gk104_clkgate_blcg_init_gcc_0 },
+ { gk110_clkgate_blcg_init_sked_0 },
+ { gk104_clkgate_blcg_init_unk_1 },
+ { gk104_clkgate_blcg_init_gpc_ctxctl_0 },
+ { gk104_clkgate_blcg_init_gpc_unk_0 },
+ { gk104_clkgate_blcg_init_gpc_esetup_0 },
+ { gk104_clkgate_blcg_init_gpc_tpbus_0 },
+ { gk104_clkgate_blcg_init_gpc_zcull_0 },
+ { gk104_clkgate_blcg_init_gpc_tpconf_0 },
+ { gk104_clkgate_blcg_init_gpc_unk_1 },
+ { gk110_clkgate_blcg_init_gpc_gcc_0 },
+ { gk104_clkgate_blcg_init_gpc_ffb_0 },
+ { gk104_clkgate_blcg_init_gpc_tex_0 },
+ { gk104_clkgate_blcg_init_gpc_poly_0 },
+ { gk110_clkgate_blcg_init_gpc_l1c_0 },
+ { gk104_clkgate_blcg_init_gpc_unk_2 },
+ { gk110_clkgate_blcg_init_gpc_m
[RFC v6 2/5] drm/nouveau: Add support for BLCG on Kepler1
This enables BLCG optimization for kepler1. When using clockgating,
nvidia's firmware has a set of registers which are initially programmed
by the vbios with various engine delays and other mysterious settings
that are safe enough to bring up the GPU. However, the values used by
the vbios are more power hungry then they need to be, so the nvidia driver
writes it's own more optimized set of BLCG settings before enabling
CG_CTRL. This adds support for programming the optimized BLCG values
during engine/subdev init, which enables rather significant power
savings.
This introduces the nvkm_therm_clkgate_init() helper, which we use to
program the optimized BLCG settings before enabling clockgating with
nvkm_therm_clkgate_enable.
As well, this commit shares a lot more code with Fermi since BLCG is
mostly the same there as far as we can tell. In the future, it's likely
we'll reformat the clkgate_packs for kepler1 so that they share a list
of mmio packs with Fermi.
Signed-off-by: Lyude Paul
Reviewed-by: Martin Peres
---
.../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 12 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c | 207 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h | 55 ++
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 6 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 47 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h | 35
drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h | 2 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 10 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c | 58 ++
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 6 +
14 files changed, 442 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index 240b19bb4667..9398d9f09339 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -46,6 +46,16 @@ enum nvkm_therm_attr_type {
NVKM_THERM_ATTR_THRS_SHUTDOWN_HYST = 17,
};
+struct nvkm_therm_clkgate_init {
+ u32 addr;
+ u8 count;
+ u32 data;
+};
+
+struct nvkm_therm_clkgate_pack {
+ const struct nvkm_therm_clkgate_init *init;
+};
+
struct nvkm_therm {
const struct nvkm_therm_func *func;
struct nvkm_subdev subdev;
@@ -92,6 +102,8 @@ struct nvkm_therm {
int nvkm_therm_temp_get(struct nvkm_therm *);
int nvkm_therm_fan_sense(struct nvkm_therm *);
int nvkm_therm_cstate(struct nvkm_therm *, int, int);
+void nvkm_therm_clkgate_init(struct nvkm_therm *,
+const struct nvkm_therm_clkgate_pack *);
void nvkm_therm_clkgate_enable(struct nvkm_therm *);
void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
index d7c2adb9b543..c8ec3fd97155 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
@@ -137,6 +137,7 @@ struct gf100_gr_func {
int (*rops)(struct gf100_gr *);
int ppc_nr;
const struct gf100_grctx_func *grctx;
+ const struct nvkm_therm_clkgate_pack *clkgate_pack;
struct nvkm_sclass sclass[];
};
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
index 5e82f94c2245..1b52fcb2c49a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
@@ -22,6 +22,7 @@
* Authors: Ben Skeggs
*/
#include "gf100.h"
+#include "gk104.h"
#include "ctxgf100.h"
#include
@@ -173,6 +174,208 @@ gk104_gr_pack_mmio[] = {
{}
};
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_main_0[] = {
+ { 0x4041f0, 1, 0x4046 },
+ { 0x409890, 1, 0x0045 },
+ { 0x4098b0, 1, 0x007f },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_rstr2d_0[] = {
+ { 0x4078c0, 1, 0x0042 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_unk_0[] = {
+ { 0x406000, 1, 0x4044 },
+ { 0x405860, 1, 0x4042 },
+ { 0x40590c, 1, 0x4042 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_gcc_0[] = {
+ { 0x408040, 1, 0x4044 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_sked_0[] = {
+ { 0x407000, 1, 0x4044 },
+ {
[RFC v6 1/5] drm/nouveau: Add support for basic clockgating on Kepler1
This adds support for enabling automatic clockgating on nvidia GPUs for
Kepler1. While this is not technically a clockgating level, it does
enable clockgating using the clockgating values initially set by the
vbios (which should be safe to use).
This introduces two therm helpers for controlling basic clockgating:
nvkm_therm_clkgate_enable() - enables clockgating through
CG_CTRL, done after initializing the GPU fully
nvkm_therm_clkgate_fini() - prepares clockgating for suspend or
driver unload
A lot of this code was originally going to be based off of fermi;
however it turns out that while Fermi's the first line of GPUs that
introduced this kind of power saving, Fermi requires more fine tuned
control of the CG_CTRL registers from the driver while reclocking that
we don't entirely understand yet.
For the simple parts we will be sharing with Fermi for certain however,
we at least add those into a new subdev/therm/gf100.h header.
Signed-off-by: Lyude Paul
Reviewed-by: Martin Peres
---
.../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 5 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 17 +--
drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 58 +++--
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h | 35 ++
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 8 +-
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c | 135 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h | 48
drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 15 ++-
9 files changed, 301 insertions(+), 21 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index b1ac47eb786e..240b19bb4667 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -85,17 +85,22 @@ struct nvkm_therm {
int (*attr_get)(struct nvkm_therm *, enum nvkm_therm_attr_type);
int (*attr_set)(struct nvkm_therm *, enum nvkm_therm_attr_type, int);
+
+ bool clkgating_enabled;
};
int nvkm_therm_temp_get(struct nvkm_therm *);
int nvkm_therm_fan_sense(struct nvkm_therm *);
int nvkm_therm_cstate(struct nvkm_therm *, int, int);
+void nvkm_therm_clkgate_enable(struct nvkm_therm *);
+void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
int nv40_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int nv50_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int g84_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
+int gk104_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gm200_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gp100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 08e77cd55e6e..74bd09b1c893 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -28,6 +28,7 @@
#include
#include
+#include
static DEFINE_MUTEX(nv_devices_mutex);
static LIST_HEAD(nv_devices);
@@ -1682,7 +1683,7 @@ nve4_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
- .therm = gf119_therm_new,
+ .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1721,7 +1722,7 @@ nve6_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
- .therm = gf119_therm_new,
+ .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1760,7 +1761,7 @@ nve7_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
- .therm = gf119_therm_new,
+ .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1824,7 +1825,7 @@ nvf0_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk110_pmu_new,
- .therm = gf119_therm_new,
+ .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1862,7 +1863,7 @@ nvf1_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk110_pmu_new,
- .therm = gf119
[RFC v6 0/5] Implement full clockgating for Kepler1 and 2
Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ Some small changes (shouldn't change anything functionally): - Made gf100_therm_new, gk104_clkgate_pack, and gk110_fb_clkgate_blcg_init_unk_0 static (re: kbuild test bot) - Making all three of these things static made it apparent that we create gf100_therm_new() and gf100_therm_func in nvkm/subdev/therm/gf100.c, but never actually use them anywhere. So, get rid of these two things entirely and also since we no longer need to, stop exporting gt215_therm_init Signed-off-by: Lyude Paul Reviewed-by: Martin Peres Lyude Paul (5): drm/nouveau: Add support for basic clockgating on Kepler1 drm/nouveau: Add support for BLCG on Kepler1 drm/nouveau: Add support for BLCG on Kepler2 drm/nouveau: Add support for SLCG for Kepler2 drm/nouveau: Introduce NvPmEnableGating option drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 17 ++ drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 25 +-- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c | 207 + drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h | 55 ++ drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c | 155 +++ drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 6 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 47 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h | 35 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c | 71 +++ drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h | 2 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 2 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 70 ++- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c | 58 ++ drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h | 35 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 8 +- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c | 136 ++ drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h | 48 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 21 ++- 22 files changed, 977 insertions(+), 26 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: clang warning: implicit conversion in intel_ddi.c:1481
On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote:
> Dear Rodrigo Vivi, Ville Syrjälä,
>
> My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We
> intend to use static analysis tools on the kernel source to identify,
> analyze and report issues. As a very first step, we are looking into
> clang compiler warnings and will then move to more sophisticated tools.
>
> When compiling Linux 4.15 with clang, we have discovered that your commit
> 2952cd6fb4cc ("drm/i915: Let's use more enum intel_dpll_id pll_id.")
> introduced the following warning:
>
> drivers/gpu/drm/i915/intel_ddi.c:1481:30: warning: implicit conversion from
> enumeration type 'enum port' to different enumeration type 'enum
> intel_dpll_id' [-Wenum-conversion]
> enum intel_dpll_id pll_id = port;
>
> To reproduce it, you can compile Linux 4.15 with clang with this command:
>
> make HOSTCC=clang-5.0 defconfig && make -j32 HOSTCC=clang-5.0 CC=clang-5.0
>
> If you don't have clang installed in your system, you can use this simple
> docker setup to compile the kernel with clang:
>
> wget
> https://raw.githubusercontent.com/bulwahn/linux-kernel-analysis/master/docker/kernel-clang/Dockerfile
> && \
> docker build -t kernel-clang . && \
> docker run -v :/linux/ kernel-clang /bin/sh -c
> "cd linux && make CC=clang-5.0 clean && make HOSTCC=clang-5.0 defconfig &&
> make -j32 HOSTCC=clang-5.0 CC=clang-5.0"
>
> While we were doing our analysis on 4.15, we noticed that you already
> resolved this warning on linux-next with your work in commit bb911536f07e
> ("drm/i915: Eliminate pll->state usage from bxt_calc_pll_link()"). So,
> since it is resolved on linux-next and we expect that this commit will be
> merged in the merge window for 4.16, there is probably nothing further to
> do.
>
> Linux 4.15 is shipped with this clang warning, but we don't see the
> crucial need to provide a backport commit to the stable branch for 4.15.
> We just wanted to inform you about our analysis of this clang warning.
> Ultimately the final call if you would like to address this clang warning
> in 4.15 is yours.
Note, I have not taken "clang warning fixes" for stable kernel updates
in the past, and I doubt I will in the future, unless the tree "builds
clean" with clang. If it eventually gets there, then yes, I will do
that.
Note, if you are going to email this out to everyone who fixes a warning
message, you might want to reconsider it. That's going to be a lot of
work, and for people who have already fixed an issue, it's kind of
pointless to just remind them of work they have done in the past, right?
What is the goal of these types of emails?
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] i915 PSR test results and cursor lag
Quoting Andy Lutomirski (2018-02-01 17:40:22) > *However*, I do see one unfortunate side effect of turning on PSR. It > seems that, when I move my cursor a little bit after a few seconds of > doing nothing, there seems to be a little bit of lag, as if either a > few frames are dropped at the beginning of the motion or maybe the > entire motion is delayed a bit. I don't notice a similar delay when > typing, so I'm wondering if maybe there's a minor driver bug in which > the driver doesn't kick the panel out of PSR quite as quickly when the > cursor is updated as it does when the framebuffer is updated. One thing that's important know regarding the cursor is whether the display server is using a HW cursor or SW cursor. Could you please attach the log from the display server (or if you are using a stock distribution that's probably enough to work out what it is using)? -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915 PSR test results and cursor lag
On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski wrote: > Hi- > > As requested in your blog post, I tested PSR. I see something like > 2.69W with PSR off and 2.17W with PSR on. Screen blanking, > suspend/resume, and the contents of the screen all seem okay. This is > a Dell XPS 13 9350, i.e.: > > System Information > Manufacturer: Dell Inc. > Product Name: XPS 13 9350 > > EDID is attached. > > *However*, I do see one unfortunate side effect of turning on PSR. It > seems that, when I move my cursor a little bit after a few seconds of > doing nothing, there seems to be a little bit of lag, as if either a > few frames are dropped at the beginning of the motion or maybe the > entire motion is delayed a bit. I don't notice a similar delay when > typing, so I'm wondering if maybe there's a minor driver bug in which > the driver doesn't kick the panel out of PSR quite as quickly when the > cursor is updated as it does when the framebuffer is updated. > I'm also getting occasional messages like: [ 2675.574486] [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A with PSR on. But there is nowhere near one of these messages per tiny lag incident. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
i915 PSR test results and cursor lag
Hi- As requested in your blog post, I tested PSR. I see something like 2.69W with PSR off and 2.17W with PSR on. Screen blanking, suspend/resume, and the contents of the screen all seem okay. This is a Dell XPS 13 9350, i.e.: System Information Manufacturer: Dell Inc. Product Name: XPS 13 9350 EDID is attached. *However*, I do see one unfortunate side effect of turning on PSR. It seems that, when I move my cursor a little bit after a few seconds of doing nothing, there seems to be a little bit of lag, as if either a few frames are dropped at the beginning of the motion or maybe the entire motion is delayed a bit. I don't notice a similar delay when typing, so I'm wondering if maybe there's a minor driver bug in which the driver doesn't kick the panel out of PSR quite as quickly when the cursor is updated as it does when the framebuffer is updated. (A couple of lists are cc'd BTW, switching PSR on and off using /sys/module/i915/parameters/enable_psr seems to work fine, although it seems like I may need to suspend/resume to get it to kick in. But, if there's really going to be a blacklist or whitelist of panels in userspace, shouldn't there be an option in sysfs in /sys/class/drm/card0-eDP-1/ or similar? --Andy panel-edid Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH libdrm] meson: fix libdrm_nouveau pkgconfig include directories
Thanks! Quoting Eric Engestrom (2018-01-31 03:14:50) > On Thursday, 2018-01-25 16:14:45 -0800, Dylan Baker wrote: > > Signed-off-by: Dylan Baker > > Reviewed-by: Eric Engestrom > > > --- > > > > I have tested building every mesa driver against this (with and without > > udev!) > > so I'm pretty sure that this is the last pkgbuild problem. > > > > I'm sure I'll be sad in a day or two... > > > > nouveau/meson.build | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/nouveau/meson.build b/nouveau/meson.build > > index bfecf84b..f031cd63 100644 > > --- a/nouveau/meson.build > > +++ b/nouveau/meson.build > > @@ -45,7 +45,7 @@ install_headers( > > pkg.generate( > >name : 'libdrm_nouveau', > >libraries : libdrm_nouveau, > > - subdirs : ['.', 'nouveau'], > > + subdirs : ['.', 'libdrm', 'libdrm/nouveau'], > >version : meson.project_version(), > >requires_private : 'libdrm', > >description : 'Userspace interface to nouveau kernel DRM services', > > -- > > 2.16.0 > > signature.asc Description: signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/msm/adreno: Add A6XX device support
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on next-20180201]
[cannot apply to v4.15]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/drm-msm-Add-support-for-Adreno-a6xx/20180201-224050
base: git://people.freedesktop.org/~robclark/linux msm-next
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/msm/adreno/a6xx_gpu.c: In function 'a6xx_ucode_init':
>> drivers/gpu/drm/msm/adreno/a6xx_gpu.c:301:22: error: implicit declaration of
>> function 'adreno_request_fw_bo'; did you mean 'adreno_request_fw'?
>> [-Werror=implicit-function-declaration]
a6xx_gpu->sqe_bo = adreno_request_fw_bo(gpu,
^~~~
adreno_request_fw
>> drivers/gpu/drm/msm/adreno/a6xx_gpu.c:301:20: warning: assignment makes
>> pointer from integer without a cast [-Wint-conversion]
a6xx_gpu->sqe_bo = adreno_request_fw_bo(gpu,
^
cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/msm/adreno/a6xx_gmu.c:17:10: fatal error: soc/qcom/cmd-db.h:
>> No such file or directory
#include
^~~
compilation terminated.
vim +301 drivers/gpu/drm/msm/adreno/a6xx_gpu.c
294
295 static int a6xx_ucode_init(struct msm_gpu *gpu)
296 {
297 struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
298 struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
299
300 if (!a6xx_gpu->sqe_bo) {
> 301 a6xx_gpu->sqe_bo = adreno_request_fw_bo(gpu,
302 adreno_gpu->info->pm4fw, &a6xx_gpu->sqe_iova);
303
304 if (IS_ERR(a6xx_gpu->sqe_bo)) {
305 int ret = PTR_ERR(a6xx_gpu->sqe_bo);
306
307 a6xx_gpu->sqe_bo = NULL;
308 DRM_DEV_ERROR(&gpu->pdev->dev,
309 "Could not allocate SQE ucode: %d\n",
ret);
310
311 return ret;
312 }
313 }
314
315 gpu_write64(gpu, REG_A6XX_CP_SQE_INSTR_BASE_LO,
316 REG_A6XX_CP_SQE_INSTR_BASE_HI, a6xx_gpu->sqe_iova);
317
318 return 0;
319 }
320
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/virtio: Add window server support
Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the compositor supports, and virtio-gpu will assist with > making buffers available in both sides, and copying content as needed. Why not use virtio-vsock to run the wayland protocol? I don't like the idea to duplicate something with very simliar functionality in virtio-gpu. > It is expected that a service in the guest will act as a proxy, > interacting with virtio-gpu to support unmodified clients. If you have a guest proxy anyway using virtio-sock for the protocol stream and virtio-gpu for buffer sharing (and some day 3d rendering too) should work fine I think. > When the client notifies the compositor that it can read from that buffer, > the proxy should copy the contents from the SHM region to the virtio-gpu > resource and call DRM_VIRTGPU_TRANSFER_TO_HOST. What is the plan for the host side? I see basically two options. Either implement the host wayland proxy directly in qemu. Or implement it as separate process, which then needs some help from qemu to get access to the buffers. The later would allow qemu running independant from the desktop session. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] fbdev: don't select I2C directly
On Monday, January 15, 2018 05:14:04 PM Arnd Bergmann wrote: > Using a Kconfig 'select' statement for a user-visible symbol that other > drivers depend on often causes circular dependencies. A new one showed > up when I wanted to add an NVMEM dependency to the DRM_MSM driver: > > drivers/i2c/Kconfig:7:error: recursive dependency detected! > drivers/i2c/Kconfig:7:symbol I2C is selected by FB_DDC > drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by > FB_CYBER2000_DDC > drivers/video/fbdev/Kconfig:390: symbol FB_CYBER2000_DDC depends on > FB_CYBER2000 > drivers/video/fbdev/Kconfig:378: symbol FB_CYBER2000 depends on FB > drivers/video/fbdev/Kconfig:5:symbol FB is selected by > DRM_KMS_FB_HELPER > drivers/gpu/drm/Kconfig:77: symbol DRM_KMS_FB_HELPER depends on > DRM_KMS_HELPER > drivers/gpu/drm/Kconfig:71: symbol DRM_KMS_HELPER is selected by DRM_MSM > drivers/gpu/drm/msm/Kconfig:2:symbol DRM_MSM depends on NVMEM > drivers/nvmem/Kconfig:1: symbol NVMEM is selected by EEPROM_AT24 > drivers/misc/eeprom/Kconfig:3:symbol EEPROM_AT24 depends on I2C > > Here, the problem is that many fbdev drivers have an i2c based interface > and just 'select i2c' for that, while we also select the framebuffer > subsystem indirectly from a DRM driver that now depends on i2c. > > This does away with the 'select' statement and instead uses 'depends on', > like almost all I2C users. I worry that this change may cause various driver options to no longer be visible to people configuring their kernels and not having I2C already selected. DRM somehow manages to select I2C and I would prefer to be it the same way for fbdev (also looking at the current next tree there are still some drivers that 'select I2C').. > Signed-off-by: Arnd Bergmann > --- > drivers/video/fbdev/Kconfig | 19 +++ > 1 file changed, 15 insertions(+), 4 deletions(-) > > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig > index 6962b4583fd7..892eb1863100 100644 > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -64,7 +64,6 @@ config FB_DDC > tristate > depends on FB > select I2C_ALGOBIT > - select I2C > default n > > config FB_BOOT_VESA_SUPPORT > @@ -390,6 +389,7 @@ config FB_CYBER2000 > config FB_CYBER2000_DDC > bool "DDC for CyberPro support" > depends on FB_CYBER2000 > + depends on I2C=y || I2C=FB_CYBER2000 > select FB_DDC > default y > help > @@ -634,7 +634,7 @@ config FB_BF537_LQ035 > config FB_BFIN_7393 > tristate "Blackfin ADV7393 Video encoder" > depends on FB && BLACKFIN > - select I2C > + depends on I2C > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > select FB_CFB_IMAGEBLIT > @@ -1026,6 +1026,7 @@ config FB_NVIDIA > config FB_NVIDIA_I2C > bool "Enable DDC Support" > depends on FB_NVIDIA > + depends on I2C=y || I2C=FB_NVIDIA > select FB_DDC > help > This enables I2C support for nVidia Chipsets. This is used > @@ -1073,6 +1074,7 @@ config FB_RIVA > config FB_RIVA_I2C > bool "Enable DDC Support" > depends on FB_RIVA > + depends on I2C=y || I2C=FB_RIVA > select FB_DDC > help > This enables I2C support for nVidia Chipsets. This is used > @@ -1102,6 +1104,7 @@ config FB_RIVA_BACKLIGHT > config FB_I740 > tristate "Intel740 support" > depends on FB && PCI > + depends on I2C > select FB_MODE_HELPERS > select FB_CFB_FILLRECT > select FB_CFB_COPYAREA > @@ -1155,6 +1158,7 @@ config FB_I810_GTF > config FB_I810_I2C > bool "Enable DDC Support" > depends on FB_I810 && FB_I810_GTF > + depends on I2C=y || I2C=FB_I810 > select FB_DDC > help > > @@ -1206,6 +1210,7 @@ config FB_INTEL_DEBUG > config FB_INTEL_I2C > bool "DDC/I2C for Intel framebuffer support" > depends on FB_INTEL > + depends on I2C=y || I2C=FB_INTEL > select FB_DDC > default y > help > @@ -1285,6 +1290,7 @@ config FB_MATROX_G > config FB_MATROX_I2C > tristate "Matrox I2C support" > depends on FB_MATROX > + depends on I2C > select FB_DDC > ---help--- > This drivers creates I2C buses which are needed for accessing the > @@ -1350,6 +1356,7 @@ config FB_RADEON > config FB_RADEON_I2C > bool "DDC/I2C for ATI Radeon support" > depends on FB_RADEON > + depends on I2C=y || I2C=FB_RADEON > select FB_DDC > default y > help > @@ -1460,6 +1467,7 @@ config FB_S3 > config FB_S3_DDC > bool "DDC for S3 support" > depends on FB_S3 > + depends on I2C=y || I2C=FB_S3 > select FB_DDC > default y > help > @@ -1485,6 +1493,7 @@ config FB_SAVAGE > config FB_SAVAGE_I2C > bool "Enable DDC2 Support" > depends on FB_SAVAGE > + depends on I2C=y || I2C=FB_SAVAGE >
[Bug 104906] Mesa crashes randomly during Youtube playback
https://bugs.freedesktop.org/show_bug.cgi?id=104906 Ilia Mirkin changed: What|Removed |Added Component|Drivers/DRI/r200|Drivers/Gallium/radeonsi -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/11] video: fbdev: kconfig: Remove blank help text
Hi, On Wednesday, January 31, 2018 10:34:21 AM Ulf Magnusson wrote: > Blank help texts are probably either a typo, a Kconfig misunderstanding, > or some kind of half-committing to adding a help text (in which case a > TODO comment would be clearer, if the help text really can't be added > right away). > > Best to remove them, IMO. How about actually adding some meaningful help texts instead (as a general rule each user visible option should have valid help text)? > Signed-off-by: Ulf Magnusson > --- > drivers/video/fbdev/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig > index 6962b4583fd7..11e699f1062b 100644 > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1156,7 +1156,6 @@ config FB_I810_I2C > bool "Enable DDC Support" > depends on FB_I810 && FB_I810_GTF > select FB_DDC > - help Please add a missing help text instead (take a look at FB_SAVAGE_I2C config option to see how a valid help text entry should look like). In the longer term we should consider removing *_I2C config options and just make the main config options always enable I2C subsystem directly if needed/useful (some fbdev drivers are doing it this way already). > config FB_LE80578 > tristate "Intel LE80578 (Vermilion) support" Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198123] Console is the wrong color at boot with radeon 6670
https://bugzilla.kernel.org/show_bug.cgi?id=198123 --- Comment #29 from Deposite Pirate (dpir...@metalpunks.info) --- Created attachment 273963 --> https://bugzilla.kernel.org/attachment.cgi?id=273963&action=edit dmesg output Here's the dmesg output with the patch applied On top of v4.15 (compiling HEAD fails) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104906] Mesa crashes randomly during Youtube playback
https://bugs.freedesktop.org/show_bug.cgi?id=104906 Bug ID: 104906 Summary: Mesa crashes randomly during Youtube playback Product: Mesa Version: 17.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 Assignee: dri-devel@lists.freedesktop.org Reporter: rhodichelic...@aol.com QA Contact: dri-devel@lists.freedesktop.org Originally submitted to the KDE Plasma bug tracker (as the Mesa crash also crashed plasmashell, and I was asked to file the bug here. Here is the original bug report I submitted to them. I am running a Radeon 270X, component selection is a guess. - Application: plasmashell (5.11.5) Qt Version: 5.9.3 Frameworks Version: 5.42.0 Operating System: Linux 4.13.0-32-generic x86_64 Distribution: KDE neon User Edition 5.11 -- Information about the crash: - What I was doing when the application crashed: Watching a Youtube video through Chromium, fullscreen. - Unusual behavior I noticed: Randomly (infrequent, this is the second time in a few weeks) during full-screen Youtube playback, video stops, audio continues, screen flashes multiple times, and after about 2-3 seconds of this behavior, video recovers and Plasma informs me it had crashed. The crash can be reproduced sometimes. -- Backtrace: Application: Plasma (plasmashell), signal: Bus error Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f13cb73e8c0 (LWP 1575))] Thread 17 (Thread 0x7f12fa092700 (LWP 10764)): #0 0x7f13b8b09d7e in pa_pstream_ref () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so #1 0x7f13b8b0a3a4 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so #2 0x7f13b8b0a789 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so #3 0x7f13b8b0b01a in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so #4 0x7f13b989f0b7 in pa_mainloop_dispatch () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #5 0x7f13b989f4bc in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #6 0x7f13b989f560 in pa_mainloop_run () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #7 0x7f13b98ad7a9 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #8 0x7f13b8b1b078 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so #9 0x7f13c43226ba in start_thread (arg=0x7f12fa092700) at pthread_create.c:333 #10 0x7f13c4d9a41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 16 (Thread 0x7f12e0ff4700 (LWP 10763)): #0 0x7f13c4d8e74d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f13bfbd538c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f13bfbd549c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f13c56c16cb in QEventDispatcherGlib::processEvents (this=0x7f12c80008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #4 0x7f13c5669e2a in QEventLoop::exec (this=this@entry=0x7f12e0ff3ce0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #5 0x7f13c54928f4 in QThread::exec (this=) at thread/qthread.cpp:515 #6 0x7f13c861ad25 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #7 0x7f13c5497709 in QThreadPrivate::start (arg=0x9cbe110) at thread/qthread_unix.cpp:368 #8 0x7f13c43226ba in start_thread (arg=0x7f12e0ff4700) at pthread_create.c:333 #9 0x7f13c4d9a41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 15 (Thread 0x7f130d23b700 (LWP 1743)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f139966460b in cnd_wait (mtx=0x1b8d618, cond=0x1b8d640) at ../../../include/c11/threads_posix.h:159 #2 util_queue_thread_func (input=input@entry=0x1360950) at ../../../src/util/u_queue.c:171 #3 0x7f1399664517 in impl_thrd_routine (p=) at ../../../include/c11/threads_posix.h:87 #4 0x7f13c43226ba in start_thread (arg=0x7f130d23b700) at pthread_create.c:333 #5 0x7f13c4d9a41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 14 (Thread 0x7f130da3c700 (LWP 1721)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f139966460b in cnd_wait (mtx=0x13502b0, cond=0x13502d8) at ../../../include/c11/threads_posix.h:159 #2 util_queue_thread_func (input=input@entry=0x1358fe0) at ../../../src/util/u_queue.c:171 #3 0x7f1399664517 in impl_thrd_routine (p=) at ../../../include/c11/threads_posix.h:87 #4 0x7f13c43226ba in start_thread (arg=0x7f130da3c700) at pthread_create.c:333 #5 0x7f13c4d9a41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 13 (Thread 0x7f130e23d700 (LWP 1720)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sy
[Bug 104880] No sound via DP on R9 Fury (4.15 + amd-staging-4.15 patches)
https://bugs.freedesktop.org/show_bug.cgi?id=104880 Konstantin A. Lepikhov changed: What|Removed |Added Summary|No sound via DP on R9 Fury |No sound via DP on R9 Fury |(4.14 + DC patches) |(4.15 + amd-staging-4.15 ||patches) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: Scale back depth to supported maximum
Den 01.02.2018 16.15, skrev Noralf Trønnes:
Den 01.02.2018 14.19, skrev Ville Syrjälä:
On Thu, Feb 01, 2018 at 02:04:46PM +0100, Linus Walleij wrote:
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns the same value
to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes
a 1-to-1 mapping between BPP and depth, which is true in most cases
but typically not for this hardware.
To support the odd case of a driver supporting 16BPP with only 15
bits of depth, this patch will make the code loop over the formats
supported on the primary plane and cap the depth to the maximum
supported.
On the PL110 Integrator, this makes drm_mode_legacy_fb_format()
select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and
thus we get framebuffer, penguin and console on the Integrator/CP.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/drm_fb_helper.c | 40
+++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index e56166334455..5076f9103740 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1720,6 +1720,8 @@ static int
drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
int i;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
+ struct drm_plane *plane;
+ int best_depth = 0;
memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -1727,7 +1729,10 @@ static int
drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
sizes.fb_width = (u32)-1;
sizes.fb_height = (u32)-1;
- /* if driver picks 8 or 16 by default use that for both
depth/bpp */
+ /*
+ * If driver picks 8 or 16 by default use that for both depth/bpp
+ * to begin with
+ */
if (preferred_bpp != sizes.surface_bpp)
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
@@ -1762,6 +1767,39 @@ static int
drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
}
}
+ /*
+ * If we run into a situation where, for example, the primary
plane
+ * supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp,
depth
+ * 16) we need to scale down the depth of the sizes we request.
+ */
+ drm_for_each_plane(plane, fb_helper->dev) {
+ /* Only check the primary plane */
+ if (plane->type != DRM_PLANE_TYPE_PRIMARY)
+ continue;
I think this should look at crtc->primary for each of the crtcs managed
by the fb_helper.
Also this probably shouldn't look at YUV formats at all?
I do wonder if instead we should just have the driver specify the
pixel format explicitly instead of trying to guess based on bpp?
Can drm_mode_config.preferred_depth be used for this? The comment says
that
it is used for dumb buffers and drm_mode_create_dumb_ioctl() does this:
cpp = DIV_ROUND_UP(args->bpp, 8);
So it looks like it should be possible to do preferred_depth=15.
Hmm, maybe not. vc4 sets preferred_depth=24, should that be RGB888 or
XRGB? The driver prefers 32bpp, but would end up with 24bpp.
I'm working on generic fbdev emulation coupled with a in-kernel client
api, so I'm interested in a solution to this for the client api.
Noralf.
+
+ for (i = 0; i < plane->format_count; i++) {
+ const struct drm_format_info *fmt;
+
+ fmt = drm_format_info(plane->format_types[i]);
+ /* We found a perfect fit, great */
+ if (fmt->depth == sizes.surface_depth)
+ break;
+
+ /* Skip depths above what we're looking for */
+ if (fmt->depth > sizes.surface_depth)
+ continue;
+
+ /* Best depth found so far */
+ if (fmt->depth > best_depth)
+ best_depth = fmt->depth;
+ }
+ }
+ if (sizes.surface_depth != best_depth) {
+ DRM_DEBUG("requested bpp %d, scaled depth down to %d",
+ sizes.surface_bpp, best_depth);
+ sizes.surface_depth = best_depth;
+ }
+
crtc_count = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: Scale back depth to supported maximum
Den 01.02.2018 14.19, skrev Ville Syrjälä:
On Thu, Feb 01, 2018 at 02:04:46PM +0100, Linus Walleij wrote:
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns the same value
to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes
a 1-to-1 mapping between BPP and depth, which is true in most cases
but typically not for this hardware.
To support the odd case of a driver supporting 16BPP with only 15
bits of depth, this patch will make the code loop over the formats
supported on the primary plane and cap the depth to the maximum
supported.
On the PL110 Integrator, this makes drm_mode_legacy_fb_format()
select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and
thus we get framebuffer, penguin and console on the Integrator/CP.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/drm_fb_helper.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e56166334455..5076f9103740 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1720,6 +1720,8 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
int i;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
+ struct drm_plane *plane;
+ int best_depth = 0;
memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -1727,7 +1729,10 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
sizes.fb_width = (u32)-1;
sizes.fb_height = (u32)-1;
- /* if driver picks 8 or 16 by default use that for both depth/bpp */
+ /*
+* If driver picks 8 or 16 by default use that for both depth/bpp
+* to begin with
+*/
if (preferred_bpp != sizes.surface_bpp)
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
@@ -1762,6 +1767,39 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
}
}
+ /*
+* If we run into a situation where, for example, the primary plane
+* supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
+* 16) we need to scale down the depth of the sizes we request.
+*/
+ drm_for_each_plane(plane, fb_helper->dev) {
+ /* Only check the primary plane */
+ if (plane->type != DRM_PLANE_TYPE_PRIMARY)
+ continue;
I think this should look at crtc->primary for each of the crtcs managed
by the fb_helper.
Also this probably shouldn't look at YUV formats at all?
I do wonder if instead we should just have the driver specify the
pixel format explicitly instead of trying to guess based on bpp?
Can drm_mode_config.preferred_depth be used for this? The comment says that
it is used for dumb buffers and drm_mode_create_dumb_ioctl() does this:
cpp = DIV_ROUND_UP(args->bpp, 8);
So it looks like it should be possible to do preferred_depth=15.
Noralf.
+
+ for (i = 0; i < plane->format_count; i++) {
+ const struct drm_format_info *fmt;
+
+ fmt = drm_format_info(plane->format_types[i]);
+ /* We found a perfect fit, great */
+ if (fmt->depth == sizes.surface_depth)
+ break;
+
+ /* Skip depths above what we're looking for */
+ if (fmt->depth > sizes.surface_depth)
+ continue;
+
+ /* Best depth found so far */
+ if (fmt->depth > best_depth)
+ best_depth = fmt->depth;
+ }
+ }
+ if (sizes.surface_depth != best_depth) {
+ DRM_DEBUG("requested bpp %d, scaled depth down to %d",
+ sizes.surface_bpp, best_depth);
+ sizes.surface_depth = best_depth;
+ }
+
crtc_count = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104880] No sound via DP on R9 Fury (4.14 + DC patches)
https://bugs.freedesktop.org/show_bug.cgi?id=104880 --- Comment #7 from Konstantin A. Lepikhov --- Tried with changes from amd-staging-4.15 up to v4.15-829-g8a2a2ac : [lakostis@lks ~]$ fgrep -r monitor /proc/asound/HDMI/ ... /proc/asound/HDMI/eld#0.0:monitor_present 0 /proc/asound/HDMI/eld#0.1:monitor_present 0 /proc/asound/HDMI/eld#0.2:monitor_present 0 /proc/asound/HDMI/eld#0.3:monitor_present 0 /proc/asound/HDMI/eld#0.4:monitor_present 0 /proc/asound/HDMI/eld#0.5:monitor_present 0 [lakostis@lks ~]$ Still no sound or it's presence detected. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86
On Wed, Jan 31, 2018 at 12:46 PM, John Stultz wrote: > On Wed, Jan 31, 2018 at 8:01 AM, Emil Velikov > wrote: >> On 30 January 2018 at 05:42, John Stultz wrote: >>> On Fri, Jan 26, 2018 at 10:33 AM, Emil Velikov >>> wrote: Hi all, Couple of ideas/notes, On 10 January 2018 at 20:36, Rob Herring wrote: > On Wed, Jan 10, 2018 at 1:09 PM, John Stultz > wrote: >> On Wed, Jan 10, 2018 at 5:48 AM, Rob Herring wrote: >>> On Tue, Jan 9, 2018 at 11:25 PM, John Stultz >>> wrote: When building AOSP after updating libdrm project to the freedesktop/master branch, I've seen the following build errors: external/libdrm/intel/Android.mk: error: libdrm_intel >>> >>> This is only needed for i915 (not i965) now BTW. I'm not sure at what >>> point we stop caring about i915. If you're using any other Intel components - say Beignet or the va driver, I think those still use libdrm_intel. An alternative solution IMHO, is to drop/tweak the API to not bother libpciaccess. I have some ancient cleanup/rework branch https://github.com/evelikov/libdrm/commits/intel-remove-legacy >>> >>> I'm not opposed to this, but I'm really not familiar with intel use >>> cases and what would be ok or not there. >>> >>> >> The unfortunate part is that people familiar don't have to >> time/interest to weight in :-( >> I might give it another try, one of these days. Unless someone beats me to >> it. >> (SHARED_LIBRARIES android-arm64) missing libpciaccess (SHARED_LIBRARIES android-arm64) You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build. Using ALLOW_MISSING_DEPENDENCIES=true when building allows things to function properly, but is not ideal. So basically, while I'm not including the libdrm_intel package into the build, just the fact that the Android.mk file references libpciaccess which isn't a repo included in AOSP causes the build failure. So it seems we need some sort of conditional filter in the Android.mk to skip over it if we're not building for intel. This is my initial attempt at solving this. Feedback would be greatly appreciated! I note that in the AOSP version of libdrm, the reference to libpciaccess has been removed. See: https://android.googlesource.com/platform/external/libdrm/+/f6a1130dffae8de9ddd0c379066daf1df27fc8af%5E%21/ So I wonder if it make sense to instead remove this upstream as well? >>> >>> Only if we drop i915. >> >> To be more precise, drop i915 for Android builds (I'm not suggesting >> dropping it elsewhere, just for the Android.mk). I'm really not sure >> which devices might be affected. Anyone able to point me to someone in >> Intel who would know? > > The android-x86 folks would be the ones to ask. I added Chih-Wei. > A really silly question - how are you triggering any of this if you're building on !x86? Is that because the GPU driver is not selected thus you we fall-back to "build all"? >>> >>> I think its mostly due the fact we're using the toplevel Android.mk >>> which includes all Android.mk files in subdirectories. >>> >> That does not matter. Unless otherwise stated the objects are optional. >> Thus they should not be build, unless... >> >> Android changed the policy or you're somehow building stuff that's not >> required? > > I don't think its a policy, its seems its just how the toplevel > Android.mk file is setup: >https://cgit.freedesktop.org/drm/libdrm/tree/Android.mk#n63 > > Where it includes all the Android.mk from all subdirectories, which > pulls in the intel/Android.mk, which adds libpciaccess to the > LOCAL_SHARED_LIBRARIES >https://cgit.freedesktop.org/drm/libdrm/tree/intel/Android.mk#n36 That's not quite right. The build system descends directories til it finds an Android.mk. For subdirs under that Android.mk, the Android.mk file must descend. That's why we have: include $(call all-makefiles-under,$(LOCAL_PATH)) >>> I'm not sure quite how to select a gpu driver with the Android build >>> system, other then specifying it via a build variable, which is in >>> effect what I'm trying to do with this patch. >>> >>> Other ideas? >>> >> Based on your input seems like it's not set (grep for >> BOARD_GPU_DRIVERS), which results in "everything" being build. >> Thus optional libraries (like libdrm_intel) are pulled causing the problem. >> >> My earlier suggestion doesn't sound too crazy, although I'd check with >> RobH and the Android-x86 people. >> It might require one line change to the device manifest ;-) > > So I looked a bit at this, but it seems that just cont
Re: [PATCH 6/7] dt-bindings: display: msm/dsi: Add compatible for 14nm DSI PHY
On Wed, Jan 31, 2018 at 11:29 PM, Archit Taneja wrote: > > > On 01/31/2018 09:50 PM, Rob Clark wrote: >> >> On Wed, Jan 31, 2018 at 1:40 AM, Archit Taneja >> wrote: >>> >>> >>> >>> On 01/29/2018 10:45 PM, Rob Herring wrote: On Wed, Jan 17, 2018 at 03:04:47PM +0530, Archit Taneja wrote: > > > Add the compatible string for 14nm DSI PHY (used in MSM8996/APQ8096). > From 14nm PHY onwards, the "dsi_phy_regulator" reg-name is not > required, > but "dsi_phy_lane" reg-name is. Update the doc to specify the reg-names > each PHY revision needs. > > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Signed-off-by: Archit Taneja > --- >Documentation/devicetree/bindings/display/msm/dsi.txt | 13 > +++-- >1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt > b/Documentation/devicetree/bindings/display/msm/dsi.txt > index 9c3ad6bbb9f0..26a1796b7145 100644 > --- a/Documentation/devicetree/bindings/display/msm/dsi.txt > +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt > @@ -86,12 +86,19 @@ Required properties: > * "qcom,dsi-phy-28nm-lp" > * "qcom,dsi-phy-20nm" > * "qcom,dsi-phy-28nm-8960" > -- reg: Physical base address and length of the registers of PLL, PHY > and > PHY > - regulator > + * "qcom,dsi-phy-14nm" > +- reg: Physical base address and length of the registers of PLL, PHY. > Some > + revisions require the PHY regulator base address, whereas others > require the > + PHY lane base address. See below for each PHY revision. >- reg-names: The names of register regions. The following regions > are > required: > + For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY: > * "dsi_pll" > * "dsi_phy" > * "dsi_phy_regulator" > + For DSI 14nm PHY: > + * "dsi_pll" > + * "dsi_phy" > + * "dsi_phy_lane" >- clock-cells: Must be 1. The DSI PHY block acts as a clock > provider, > creating > 2 clocks: A byte clock (index 0), and a pixel clock (index 1). >- power-domains: Should be <&mmcc MDSS_GDSC>. > @@ -102,6 +109,8 @@ Required properties: >- vddio-supply: phandle to vdd-io regulator device node > For 20nm PHY: >- vddio-supply: phandle to vdd-io regulator device node > +- vcca-supply: phandle to vcca regulator device node Did you mean to add this? >>> >>> >>> >>> Yes, I didn't intend it to be a part of this patch, but this supply is >>> indeed needed for the >>> 20nm PHY. I'll move this to a separate patch. >> >> >> actually, this looks correct, just formatted counter-intuitively by >> git-format-patch.. >> >> vcca-supply for 20nm was introduced by "dt-bindings: display: msm/dsi: >> Fix the PHY regulator supply props", but when 14nm phy is added in >> this patch, it shows the addition of same line beneath 14nm PHY as an >> addition above the line. >> >> So I don't think it needs to be split up. > > > Oh yeah, you're right. I guess this is okay as is, then. Doh! Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits
On 2018-02-01 05:30 AM, Maarten Lankhorst wrote: > Op 31-01-18 om 20:57 schreef Harry Wentland: >> On 2018-01-30 05:28 AM, Maarten Lankhorst wrote: >>> Op 29-01-18 om 16:41 schreef Leo Li: Updated IGT results seem sane: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html Would someone be able to apply this patch? >>> Thanks for the reminder, pushed. >>> >> Thanks, Maarten. I see it in drm-misc-next. >> >> Would someone be able to pull this into drm-misc-fixes as well, or can I >> just I apply this myself with the following dim commands? >> >> dim checkout drm-misc-fixes >> dim cherry-pick 1c6c6ebb >> dim push-branch > My bad, pushed to the right branch. :) > Thanks, Maarten. Harry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm_hwcomposer] [PATCH] Take Connection state into account. (v2)
On Thu, Feb 01, 2018 at 05:42:35AM +0100, Mauro Rossi wrote:
> Il 08/gen/2018 09:46 PM, "Sean Paul" ha scritto:
>
> On Mon, Jan 08, 2018 at 03:41:49PM -0500, Sean Paul wrote:
> > On Sat, Jan 06, 2018 at 12:59:58AM +0100, Mauro Rossi wrote:
> > > Porting of original commit 76fb87e675 of Jim Bish in android-ia master
> to fdo
> > >
> > > Original commit message:
> > > "There are various places where we should be really taking connection
> > > state into account before querying the properties or assuming it
> > > as primary. This patch fixes them."
> > >
> > > (v2) checks on connection state are applied for both internal and
> external
> > > connectors, in order to select the correct primary, as opposed to
> setting,
> > > independently from its state, the first connector as primary
> > >
> > > This is essential to avoid following logcat errors on integrated and
> dedicated GPUs:
> > >
> > > ... 2245 2245 E hwc-drm-resources: Could not find a suitable
> encoder/crtc for display 2
> > > ... 2245 2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with -19
> > > ... 2245 2245 E hwcomposer-drm: Can't initialize Drm object -19
> > >
> > > Tested with i965 on Sandybridge and nouveau on GT120, GT610
> > > ---
> > > drmresources.cpp | 9 +++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drmresources.cpp b/drmresources.cpp
> > > index 32dd376..d582cfe 100644
> > > --- a/drmresources.cpp
> > > +++ b/drmresources.cpp
> > > @@ -159,7 +159,7 @@ int DrmResources::Init() {
> > >
> > >// First look for primary amongst internal connectors
> > >for (auto &conn : connectors_) {
> > > -if (conn->internal() && !found_primary) {
> > > +if (conn->state() == DRM_MODE_CONNECTED && conn->internal() &&
> !found_primary) {
>
> One more thing. How do you know this is the right thing to do? What if the
> internal panel is not connected initially, but becomes connected in the
> future?
> IIUC, you'll end up numbering it incorrectly.
>
> Sean
>
>
> Unfortunately I don't have knowledge/experience about the drm mode code,
> but analyzing logs in nouveau with dedicated GPU shows a problem in current
> code.
>
> You are asking if taking connection state into account will work in dynamic
> scenario of plugging/unplugging cable/conn,
> but let's start from acknowledging that current code results in 'no screen
> output', because it bails out too soon, and taking connection state into
> account allows to boot with nouveau, which is the goal of having moved
> drm_hwcomposer to fd.o
>
> IMHO to bo able to boot Android drm_hwcomposer+gbm_gralloc with nouveau is
> a substantial improvement
I completely agree! However, I don't think it's unreasonable to have discussion
around how we fix bugs.
I'm concerned that while this will result in a working setup if everything is
plugged on startup, it creates new problems around hotplugging. For instance, by
gating CreateDisplayPipe on the display being connected, we're no longer mapping
crtc/encoders to displays. I think this will cause problems down the road if
a monitor is plugged into one of these skipped displays. So this patch fixes a
bug by introducing a regression.
Sean
>
>
>
> > >conn->set_display(0);
> > >found_primary = true;
> > > } else {
> > > @@ -170,7 +170,7 @@ int DrmResources::Init() {
> > >
> > >// Then look for primary amongst external connectors
> > >for (auto &conn : connectors_) {
> > > -if (conn->external() && !found_primary) {
> > > +if (conn->state() == DRM_MODE_CONNECTED && conn->external() &&
> !found_primary) {
> >
> > These 2 lines exceed the max character limit. Did you run clang-format?
> >
> > Anyways, I think it'd be nice to add a connected() helper to the connector
> > object which would look cleaner and solve the long lines.
> >
> > Sean
>
>
> Thanks for feedback, we will have a look with Robert to improve coding style
>
> >
> > >conn->set_display(0);
> > >found_primary = true;
> > > }
> > > @@ -288,6 +288,11 @@ int DrmResources::TryEncoderForDisplay(int
> display, DrmEncoder *enc) {
> > >
> > > int DrmResources::CreateDisplayPipe(DrmConnector *connector) {
> > >int display = connector->display();
> > > +
> > > + // skip not connected
> > > + if (connector->state() == DRM_MODE_DISCONNECTED)
> > > +return 0;
> > > +
> > >/* Try to use current setup first */
> > >if (connector->encoder()) {
> > > int ret = TryEncoderForDisplay(display, connector->encoder());
> > > --
> > > 2.14.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-d
[Bug 102423] kwin segfaults when Alt+Tabbing with windows thumbnails on AMDGPU
https://bugs.freedesktop.org/show_bug.cgi?id=102423 --- Comment #5 from Alex Deucher --- amdgpu is the kernel driver and radeonsi is the user mode mesa driver. They both work together on your system. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104895] [CI] igt@tools_test@tools_test - fail - Test assertion failure function __real_main62 - Failed assertion: igt_system_quiet("./intel_reg dump") == 0
https://bugs.freedesktop.org/show_bug.cgi?id=104895 --- Comment #3 from Marta Löfstedt --- (In reply to Mika Kuoppala from comment #2) > The test in question fails before the commit in question, so that is not the > offending commit. please specify on which CI/IGT run before IGT_4206 the test was failing. IGT_4206 is in my opinion the first fail. This run has kernel from CI_DRM_3707. However, the test pass on CI_DRM_3707, then it fails on CI_DRM_3708 and so far all consecutive runs. CI_DRM_3708 has the same IGT commit as IGT_4206. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: Scale back depth to supported maximum
On Thu, Feb 01, 2018 at 02:04:46PM +0100, Linus Walleij wrote:
> The following happened when migrating an old fbdev driver to DRM:
>
> The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
> or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
>
> This makes the initialization of the framebuffer fail since
> the code in drm_fb_helper_single_fb_probe() assigns the same value
> to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes
> a 1-to-1 mapping between BPP and depth, which is true in most cases
> but typically not for this hardware.
>
> To support the odd case of a driver supporting 16BPP with only 15
> bits of depth, this patch will make the code loop over the formats
> supported on the primary plane and cap the depth to the maximum
> supported.
>
> On the PL110 Integrator, this makes drm_mode_legacy_fb_format()
> select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and
> thus we get framebuffer, penguin and console on the Integrator/CP.
>
> Signed-off-by: Linus Walleij
> ---
> drivers/gpu/drm/drm_fb_helper.c | 40 +++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e56166334455..5076f9103740 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1720,6 +1720,8 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> int i;
> struct drm_fb_helper_surface_size sizes;
> int gamma_size = 0;
> + struct drm_plane *plane;
> + int best_depth = 0;
>
> memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
> sizes.surface_depth = 24;
> @@ -1727,7 +1729,10 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> sizes.fb_width = (u32)-1;
> sizes.fb_height = (u32)-1;
>
> - /* if driver picks 8 or 16 by default use that for both depth/bpp */
> + /*
> + * If driver picks 8 or 16 by default use that for both depth/bpp
> + * to begin with
> + */
> if (preferred_bpp != sizes.surface_bpp)
> sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
>
> @@ -1762,6 +1767,39 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> }
> }
>
> + /*
> + * If we run into a situation where, for example, the primary plane
> + * supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
> + * 16) we need to scale down the depth of the sizes we request.
> + */
> + drm_for_each_plane(plane, fb_helper->dev) {
> + /* Only check the primary plane */
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> + continue;
I think this should look at crtc->primary for each of the crtcs managed
by the fb_helper.
Also this probably shouldn't look at YUV formats at all?
I do wonder if instead we should just have the driver specify the
pixel format explicitly instead of trying to guess based on bpp?
> +
> + for (i = 0; i < plane->format_count; i++) {
> + const struct drm_format_info *fmt;
> +
> + fmt = drm_format_info(plane->format_types[i]);
> + /* We found a perfect fit, great */
> + if (fmt->depth == sizes.surface_depth)
> + break;
> +
> + /* Skip depths above what we're looking for */
> + if (fmt->depth > sizes.surface_depth)
> + continue;
> +
> + /* Best depth found so far */
> + if (fmt->depth > best_depth)
> + best_depth = fmt->depth;
> + }
> + }
> + if (sizes.surface_depth != best_depth) {
> + DRM_DEBUG("requested bpp %d, scaled depth down to %d",
> + sizes.surface_bpp, best_depth);
> + sizes.surface_depth = best_depth;
> + }
> +
> crtc_count = 0;
> for (i = 0; i < fb_helper->crtc_count; i++) {
> struct drm_display_mode *desired_mode;
> --
> 2.14.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104895] [CI] igt@tools_test@tools_test - fail - Test assertion failure function __real_main62 - Failed assertion: igt_system_quiet("./intel_reg dump") == 0
https://bugs.freedesktop.org/show_bug.cgi?id=104895 --- Comment #2 from Mika Kuoppala --- The test in question fails before the commit in question, so that is not the offending commit. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb-helper: Scale back depth to supported maximum
The following happened when migrating an old fbdev driver to DRM:
The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.
This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns the same value
to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes
a 1-to-1 mapping between BPP and depth, which is true in most cases
but typically not for this hardware.
To support the odd case of a driver supporting 16BPP with only 15
bits of depth, this patch will make the code loop over the formats
supported on the primary plane and cap the depth to the maximum
supported.
On the PL110 Integrator, this makes drm_mode_legacy_fb_format()
select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and
thus we get framebuffer, penguin and console on the Integrator/CP.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/drm_fb_helper.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e56166334455..5076f9103740 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1720,6 +1720,8 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
int i;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
+ struct drm_plane *plane;
+ int best_depth = 0;
memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -1727,7 +1729,10 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
sizes.fb_width = (u32)-1;
sizes.fb_height = (u32)-1;
- /* if driver picks 8 or 16 by default use that for both depth/bpp */
+ /*
+* If driver picks 8 or 16 by default use that for both depth/bpp
+* to begin with
+*/
if (preferred_bpp != sizes.surface_bpp)
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
@@ -1762,6 +1767,39 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
}
}
+ /*
+* If we run into a situation where, for example, the primary plane
+* supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
+* 16) we need to scale down the depth of the sizes we request.
+*/
+ drm_for_each_plane(plane, fb_helper->dev) {
+ /* Only check the primary plane */
+ if (plane->type != DRM_PLANE_TYPE_PRIMARY)
+ continue;
+
+ for (i = 0; i < plane->format_count; i++) {
+ const struct drm_format_info *fmt;
+
+ fmt = drm_format_info(plane->format_types[i]);
+ /* We found a perfect fit, great */
+ if (fmt->depth == sizes.surface_depth)
+ break;
+
+ /* Skip depths above what we're looking for */
+ if (fmt->depth > sizes.surface_depth)
+ continue;
+
+ /* Best depth found so far */
+ if (fmt->depth > best_depth)
+ best_depth = fmt->depth;
+ }
+ }
+ if (sizes.surface_depth != best_depth) {
+ DRM_DEBUG("requested bpp %d, scaled depth down to %d",
+ sizes.surface_bpp, best_depth);
+ sizes.surface_depth = best_depth;
+ }
+
crtc_count = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5 v2] drm/pl111: Support multiple endpoints on the CLCD
The Versatile PL110 implementations use multiple endpoints:
from the PL111 port, the lines are routed through a PLD,
and from there forked so the same lines go to a VGA DAC and
an external TFT panel connector. This is discrete wireing
so there is no way to turn of one output, i.e. this is
really two endpoints, not two ports.
We model this with multiple endpoints, so we need to loop
over the available endpoints, check for panel or bridge on
each and accumulate the result before continuing.
The code already will give the panel preference over the
bridge, if present, so the output will be sent to the panel
if both a panel and a bridge is present on two endpoints
of the same port.
If they all return -EPROBE_DEFER we return -EPROBE_DEFER
as well.
If just one endpoint is present on the port, the behaviour
is the same as before.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_drv.c | 62 +++
1 file changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index e6fa897c740c..221f3af02fb4 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -58,6 +58,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -84,9 +86,13 @@ static int pl111_modeset_init(struct drm_device *dev)
{
struct drm_mode_config *mode_config;
struct pl111_drm_dev_private *priv = dev->dev_private;
- struct drm_panel *panel;
- struct drm_bridge *bridge;
+ struct device_node *np = dev->dev->of_node;
+ struct device_node *remote;
+ struct drm_panel *panel = NULL;
+ struct drm_bridge *bridge = NULL;
+ bool defer = false;
int ret = 0;
+ int i;
drm_mode_config_init(dev);
mode_config = &dev->mode_config;
@@ -96,10 +102,54 @@ static int pl111_modeset_init(struct drm_device *dev)
mode_config->min_height = 1;
mode_config->max_height = 768;
- ret = drm_of_find_panel_or_bridge(dev->dev->of_node,
- 0, 0, &panel, &bridge);
- if (ret && ret != -ENODEV)
- return ret;
+ i = 0;
+ for_each_endpoint_of_node(np, remote) {
+ struct drm_panel *tmp_panel;
+ struct drm_bridge *tmp_bridge;
+
+ dev_dbg(dev->dev, "checking endpoint %d\n", i);
+
+ ret = drm_of_find_panel_or_bridge(dev->dev->of_node,
+ 0, i,
+ &tmp_panel,
+ &tmp_bridge);
+ if (ret) {
+ if (ret == -EPROBE_DEFER) {
+ /*
+* Something deferred, but that is often just
+* another way of saying -ENODEV, but let's
+* cast a vote for later deferral.
+*/
+ defer = true;
+ } else if (ret != -ENODEV) {
+ /* Continue, maybe something else is working */
+ dev_err(dev->dev,
+ "endpoint %d returns %d\n", i, ret);
+ }
+ }
+
+ if (tmp_panel) {
+ dev_info(dev->dev,
+"found panel on endpoint %d\n", i);
+ panel = tmp_panel;
+ }
+ if (tmp_bridge) {
+ dev_info(dev->dev,
+"found bridge on endpoint %d\n", i);
+ bridge = tmp_bridge;
+ }
+
+ i++;
+ }
+
+ /*
+* If we can't find neither panel nor bridge on any of the
+* endpoints, and any of them retured -EPROBE_DEFER, then
+* let's defer this driver too.
+*/
+ if ((!panel && !bridge) && defer)
+ return -EPROBE_DEFER;
+
if (panel) {
bridge = drm_panel_bridge_add(panel,
DRM_MODE_CONNECTOR_Unknown);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
