On Thu, 2017-09-28 at 10:29 +0200, Daniel Vetter wrote:
> On Thu, Sep 28, 2017 at 10:23 AM, Liviu Dudau <liviu.du...@arm.com>
> wrote:
> > Hi Daniel,
> >
> > On Thu, Sep 28, 2017 at 09:40:35AM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 27, 2017 at 4:
E mmap) and correct the size parameter in the
call to dma_mmap_wc as the offset may not be non-zero.
Signed-off-by: Tu Vuong <tu.vu...@arm.com>
Signed-off-by: Steven Price <steven.pr...@arm.com>
Reviewed-by: Brian Starkey <brian.star...@arm.com>
CC: Brian Starkey <brian.star.
On 01/04/2019 09:09, Neil Armstrong wrote:
> Add the bindings for the Bifrost family of ARM Mali GPUs.
>
> The Bifrost GPU architecture is similar to the Midgard family,
> but with a different Shader Core & Execution Engine structures.
>
> Bindings are based on the Midgard family bindings, but
On 05/04/2019 10:51, Robin Murphy wrote:
> Hi Steve,
>
> On 05/04/2019 10:42, Steven Price wrote:
>> First let me say congratulations to everyone working on Panfrost - it's
>> an impressive achievement!
>>
>> Full disclosure: I used to work on the Mali kbase
On 04/04/2019 16:20, Boris Brezillon wrote:
> Hello,
>
> This patch adds new ioctls to expose GPU counters to userspace.
> These will be used by the mesa driver (should be posted soon).
>
> A few words about the implementation: I followed the VC4/Etnaviv model
> where perf counters are retrieved
difference between this and JS_CONFIG_START_MMU.
-8<--
From e3f75c7f04e43238dfc579029b8c11fb6b4a0c18 Mon Sep 17 00:00:00 2001
From: Steven Price
Date: Thu, 4 Apr 2019 15:53:17 +0100
Subject: [PATCH] iommu: io-pgtable: IO_PGTABLE_QUIRK_TLBI_ON_MAP for LPAE
Midgard/Bifrost GPUs requi
On 05/04/2019 17:16, Alyssa Rosenzweig wrote:
>> I'm also somewhat surprised that you don't need loads of other
>> properties from the GPU - in particular knowing the number of shader
>> cores is useful for allocating the right amount of memory for TLS (and
>> can't be obtained purely from the
On 09/04/2019 17:15, Rob Herring wrote:
> On Tue, Apr 9, 2019 at 10:56 AM Tomeu Vizoso
> wrote:
>>
>> On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
>>>
>>> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>>>>
>>>> On 01/04/2019
On 08/04/2019 22:04, Rob Herring wrote:
> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>>
>> On 01/04/2019 08:47, Rob Herring wrote:
>>> This adds the initial driver for panfrost which supports Arm Mali
>>> Midgard and Bifrost family of GPUs. Currently, o
On 05/04/2019 11:36, Steven Price wrote:
> On 05/04/2019 10:51, Robin Murphy wrote:
>> Hi Steve,
>>
>> On 05/04/2019 10:42, Steven Price wrote:
>>> First let me say congratulations to everyone working on Panfrost - it's
>>> an impressive achievement!
c: David Airlie
> Cc: Daniel Vetter
> Cc: Lyude Paul
> Reviewed-by: Alyssa Rosenzweig
> Reviewed-by: Eric Anholt
> Signed-off-by: Marty E. Plummer
> Signed-off-by: Tomeu Vizoso
> Signed-off-by: Neil Armstrong
> Signed-off-by: Rob Herring
> ---
This looks like
ns on current h/w.
>
> Cc: Tomeu Vizoso
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
LGTM, and I see a nice speed up too!
Reviewed-by: Steven Price
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
-off-by: YueHaibing
Reviewed-by: Steven Price
Although while we're fixing sparse warnings, there's a few more in Panfrost:
-8<---
From 8aaf778262744cfbebb9b7f274ead9ba600526b0 Mon Sep 17 00:00:00 2001
From: Steven Price
Date: Wed, 17 Apr 2019 15:47:49 +0100
Subject: [PATCH] drm/panfrost
[=y]
Reported-by: kbuild test robot
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/Kconfig b/drivers/gpu/drm/panfrost/Kconfig
index 7f5e572daa2d..591611dc4e34 100644
--- a/drivers/gpu/drm
.
CC: Alyssa Rosenzweig
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 94b0819ad50b..a261b59208d0
Provide a wrapper for drm_gem_map_offset() for clients of shmem. This
wrapper provides the correct semantics for the drm_gem_shmem_mmap()
callback.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 20
include/drm/drm_gem_shmem_helper.h | 2 ++
2
On 14/05/2019 14:31, Rob Herring wrote:
> On Tue, May 14, 2019 at 5:48 AM Boris Brezillon
> wrote:
>>
>> Add a way to dump perf counters through debugfs. The implementation is
>> kept simple and has a number of limitations:
>>
>> * it's not designed for multi-user usage as the counter values are
space doesn't send a sync object
> ID for the out fence.
>
> Signed-off-by: Tomeu Vizoso
> Reported-by: Dan Carpenter
> Link: https://lists.freedesktop.org/archives/dri-devel/2019-May/217014.html
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c
On 13/05/2019 15:47, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-05-13 15:39:21)
>> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote:
>>> panfrost_ioctl_mmap_bo() contains a reimplementation of
>>> drm_gem_dump_map_offset() but with a bug - it allows m
the code.
CC: Alyssa Rosenzweig
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 94b0819ad50b
On 12/05/2019 14:38, Boris Brezillon wrote:
> On Sat, 11 May 2019 15:32:20 -0700
> Alyssa Rosenzweig wrote:
>
>> Hi all,
>>
>> As Steven Price explained, the "GPU top" kbase approach is often more
>> useful and accurate than per-draw timing.
>>
On 13/05/2019 09:17, Boris Brezillon wrote:
> panfrost_{job,mmu,gpu,reset}_fini() were missing.
>
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/pan
On 13/05/2019 14:39, Boris Brezillon wrote:
> On Mon, 13 May 2019 13:48:08 +0100
> Steven Price wrote:
>
>> On 12/05/2019 14:38, Boris Brezillon wrote:
>>> On Sat, 11 May 2019 15:32:20 -0700
>>> Alyssa Rosenzweig wrote:
>>>
>>>> Hi
drm_gem_dumb_map_offset to drop _dumb
* Add a shmem helper
Steven Price (2):
drm/gem: Rename drm_gem_dumb_map_offset() to drm_gem_map_offset()
drm/panfrost: Use drm_gem_shmem_map_offset()
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm
.
CC: Alyssa Rosenzweig
Signed-off-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
On 21/05/2019 19:23, Chris Wilson wrote:
> Quoting Rob Herring (2019-05-21 16:24:27)
>> On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
>>>
>>
>> You forgot to update the subject. I can fixup when applying, but I'd
>> like an ack from Chris on patch 1.
So
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb.
Signed-off-by: Steven Price
Acked-by: Alyssa Rosenzweig
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 6
On 16/05/2019 21:26, Daniel Vetter wrote:
> On Thu, May 16, 2019 at 03:14:46PM +0100, Steven Price wrote:
>> Provide a wrapper for drm_gem_map_offset() for clients of shmem. This
>> wrapper provides the correct semantics for the drm_gem_shmem_mmap()
>> callback.
>>
>
On 16/05/2019 12:19, Robin Murphy wrote:
[...]
> I was expecting to see a similar behaviour to my T620 (which I now
> assume was down to 64-bit job descriptors sort-of-but-not-quite working)
> but this does look a bit more fundamental - the fact that it's a level 1
> fault with VA == head == tail
* Add a shmem helper
Steven Price (3):
drm/gem: Rename drm_gem_dumb_map_offset() to drm_gem_map_offset()
drm: shmem: Add drm_gem_shmem_map_offset() wrapper
drm/panfrost: Use drm_gem_shmem_map_offset()
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +--
include/drm
() forwarding mechanism and update drivers to avoid using it.
However the user ABI must be maintained, so this existing mmap()
forwarding cannot be removed.
Signed-off-by: Steven Price
---
drivers/dma-buf/dma-buf.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff
On 03/07/2019 17:18, Daniel Vetter wrote:
> On Wed, Jul 3, 2019 at 6:11 PM Steven Price wrote:
[...]
>> In theory the exporter should do whatever is required to ensure that the
>> CPU is synchronised when a user space mapping exists. There are some
>> issues here thou
.
Signed-off-by: Steven Price
Reviewed-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index e34e86a7378a
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb and add a comment that it can be used by
shmem clients.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 9
://lore.kernel.org/lkml/20190516141447.46839-1-steven.pr...@arm.com/
Changes since v2:
* Drop the shmem helper
v1: https://lore.kernel.org/lkml/20190513143244.16478-1-steven.pr...@arm.com/
Changes since v1:
* Rename drm_gem_dumb_map_offset to drop _dumb
* Add a shmem helper
Steven Price (2
might require something similar (but unlikely
to require faulting in).
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: Tomeu Vizoso
> Signed-off-by: Rob Herring
> ---
>
> drivers/gpu/drm/panfrost/TODO | 2 -
> drivers/gpu/drm/panfro
Sorry for the slow response, I've been on holiday for a few weeks.
On 20/06/2019 06:50, Tomeu Vizoso wrote:
> On Mon, 17 Jun 2019 at 16:56, Rob Herring wrote:
>>
>> On Sun, Jun 16, 2019 at 11:15 PM Tomeu Vizoso
>> wrote:
>>>
>>> On Fri, 14 Jun 2019 at 23:22, Rob Herring wrote:
On
On 10/06/2019 14:20, Rob Herring wrote:
[...]
> I wouldn't have expected AS_TRANSCFG_ADRMODE_LEGACY to work and if it
> did it was by chance. So I don't think it is something we want to
> support.
Actually legacy mode is supported on (most?) Bifrost GPUs. But best to
follow the lead of kbase here
On 03/07/2019 16:59, Rob Herring wrote:
> On Wed, Jul 3, 2019 at 8:13 AM Steven Price wrote:
>>
>> On 03/07/2019 14:56, Boris Brezillon wrote:
>>> On Wed, 3 Jul 2019 07:45:32 -0600
>>> Rob Herring wrote:
>>>
>>>> On Wed, Jul 3, 2019 at 7:3
On 03/07/2019 14:56, Boris Brezillon wrote:
> On Wed, 3 Jul 2019 07:45:32 -0600
> Rob Herring wrote:
>
>> On Wed, Jul 3, 2019 at 7:34 AM Boris Brezillon
>> wrote:
>>>
>>> Exported BOs might be imported back, then mmap()-ed to be written
>>> too. Most drivers handle that by mmap()-ing the GEM
On 03/07/2019 15:33, Boris Brezillon wrote:
> On Wed, 3 Jul 2019 15:13:25 +0100
> Steven Price wrote:
>
>> On 03/07/2019 14:56, Boris Brezillon wrote:
>>> On Wed, 3 Jul 2019 07:45:32 -0600
>>> Rob Herring wrote:
>>>
>>>> On W
On 15/04/2019 10:18, Daniel Vetter wrote:
> On Fri, Apr 05, 2019 at 05:42:33PM +0100, Steven Price wrote:
>> On 05/04/2019 17:16, Alyssa Rosenzweig wrote:
>>> acronym once ever and have it as a "??"), I'm not sure how to respond to
>>> that... We don't kn
ist and switch the AS
> from the old FD to the new one.
>
> Cc: Tomeu Vizoso
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Steve
> ---
> v2:
&g
On 09/08/2019 22:09, Alyssa Rosenzweig wrote:
> While newer kbase include only the numbers of errata, older kbase
> releases included one-line descriptions for each errata, which is useful
> for those working on the driver. Import these descriptions. Most are
> from kbase verbatim; a few I edited
On 09/08/2019 04:01, Rob Herring wrote:
[...]
> I was worried too. It seems to be working pretty well though, but more
> testing would be good. I don't think there are a lot of usecases that
> use more AS than the h/w has (8 on T860), but I'm not sure.
Yeah, 8 is overkill. Some GPUs only have 4
>
> Cc: Tomeu Vizoso
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
> ---
> This depends on madvise support (now in drm-misc) and the heap/no-exec
> series (just the rework).
ork its call. In the process, we
> hide the address space details within the MMU code in preparation to
> support multiple address spaces.
>
> Cc: Tomeu Vizoso
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed
Boris Brezillon
> Cc: Robin Murphy
> Reviewed-by: Steven Price
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
> ---
> Steven, Alyssa, I kept your tags, but please take another look as things
> moved around a bit here.
Sadly this doesn't compile (bisection is broken
me in order to utilize huge pages (if
> enabled). Currently, once we've mapped pages in, they are only unmapped
> if the BO is freed. Once we add shrinker support, we can unmap pages
> with the shrinker.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc:
un
Well spotted.
Reviewed-by: Steven Price
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index 2ed411f0
The hardware has a set of '_NEXT' registers that can hold a second job
while the first is executing. Make use of these registers to enqueue a
second job per slot.
Signed-off-by: Steven Price
---
Note that this is based on top of Rob Herring's "per FD address space"
patch[1].
the voltage. This patch allows
frequency control of the GPU on this system.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost
The devfreq opp table needs to be removed when unloading the driver to
free the memory associated with it.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 6 ++
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 5
When modifying panfrost_devfreq_target() to support a device without a
regulator defined I missed the check on the error path. Let's add it.
Reported-by: Dan Carpenter
Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work without regulator")
Signed-off-by: Steven Price
---
drive
On 28/08/2019 13:35, Rob Herring wrote:
> On Wed, Aug 28, 2019 at 5:55 AM Steven Price wrote:
>>
>> On 26/08/2019 23:33, Rob Herring wrote:
>>> Currently, page tables are freed without disabling the address space first.
>>> This probably is fine as we'll switch to
untime PM calls into the probe() function so they are
> all in one place and are done after all initialization.
>
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: David Airlie
> Cc: Daniel Vetter
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven
y serialized by drm_sched.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
Reviewed-by: St
ng any locks associated with resuming which trigger
> lockdep warnings.
>
> Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: David Airlie
> Cc: Daniel Vetter
> Signe
On 26/08/2019 23:33, Rob Herring wrote:
> It's not entirely clear if this is required, but add a flush of GPU caches
> and TLBs before we change an address space to new page tables.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: Tomeu V
ot;drm/panfrost: Add initial panfrost driver")
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Steve
> ---
> v3:
> - Fix race between clearing pfdev-
On 26/08/2019 23:33, Rob Herring wrote:
> In preparation to call mmu_hw_do_operation with the as_lock already held,
> Add a mmu_hw_do_operation_locked function.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: Tomeu Vizoso
> Cc
les if we are not suspended. As
> the tlb_inv_context() hook is only called when freeing the page tables and
> we do a flush before disabling the AS, lets remove the flush from
> tlb_inv_context and avoid any runtime PM issues.
>
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD ad
; Suggested-by: Robin Murphy
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Steve
> ---
> v3:
> - new patch
>
> drivers/gpu/drm/panfrost/panfr
On 19/08/2019 18:02, Rob Herring wrote:
> On Mon, Aug 19, 2019 at 11:58 AM Rob Herring wrote:
>>
>> On Fri, Aug 16, 2019 at 4:31 AM Steven Price wrote:
>>>
>>> The hardware has a set of '_NEXT' registers that can hold a second job
>>> while the first
On 20/08/2019 06:23, Tomeu Vizoso wrote:
> On 8/16/19 11:31 AM, Steven Price wrote:
>> The hardware has a set of '_NEXT' registers that can hold a second job
>> while the first is executing. Make use of these registers to enqueue a
>> second job per slot.
>
> I like
/shmem: Add madvise state and purge helpers")
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
Looks good to me:
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/drm_gem_s
On 19/08/2019 17:12, Rob Herring wrote:
> This fixes 2 issues found by lockdep. First, drm_gem_shmem_purge()
> now uses mutex_trylock for the pages_lock to avoid a circular
> dependency.
NIT: This is in the previous patch.
> Second, it drops the call to panfrost_mmu_unmap() which takes several
>
arm64_sys_ioctl+0x1c/0x28
> el0_svc_common.constprop.0+0x90/0x168
> el0_svc_handler+0x28/0x78
> el0_svc+0x8/0xc
>
> Fixes: 68337d0b8644 ("drm/panfrost: Restructure the GEM object creation")
> Cc: Tomeu Vizoso
> Cc: David Airlie
> Cc: Daniel Vetter
> Sign
f31efa81 (>shrinker_lock){+.+.}, at:
> panfrost_gem_shrinker_scan+0x34/0x180 [panfrost]
>
> Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
>
On 23/08/2019 02:52, Rob Herring wrote:
> On Thu, Aug 22, 2019 at 4:32 AM Steven Price wrote:
>>
>> When modifying panfrost_devfreq_target() to support a device without a
>> regulator defined I missed the check on the error path. Let's add it.
>>
>> Rep
On 23/08/2019 02:33, Rob Herring wrote:
> Add Steven Price and Alyssa Rosenzweig as reviewers as they have been the
> primary reviewers already.
>
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: Tomeu Vizoso
> Signed-off-by: Rob Herring
Acked-by: Steven Price
Steve
On 23/08/2019 03:12, Rob Herring wrote:
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
not happen until the job completes. It works because we are relying on the
autosuspend timeout to keep the h/w enabled.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
the pm_runtime_put_sync_suspend()
after the panfrost_device_fini() call.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
Reviewed-by: Steven Price
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_drv.c | 6 --
1
ready given my R-b for this one, but just in case:
Reviewed-by: Steven Price
Steve
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 7 +--
include/drm/drm_gem_shmem_helper.h | 2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers
() instead and bail if a BO is locked
already.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
Reviewed-by: Steven Price
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 11 +++
1 file changed
awake.
This avoids taking any locks associated with resuming.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_mmu.c | 41 -
1 file changed, 20
associated with resuming.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
Reviewed-by: Steven Price
But one comment below...
---
v2: new patch
drivers/gpu/drm/panfrost/panfrost_mmu.c | 41 -
1 file
Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
Reviewed-by: Steven Price
Although it might be worth trying to capture the justification about
this in a comment somewhere - there's been a fair bit of discussion
about this...
Steve
---
v2: new
the panfrost_gem_object with an
extra reference on it, preventing the BO from being freed until after
the page fault has been handled.
Signed-off-by: Steven Price
---
I've managed to trigger this, generating the following stack trace.
Unable to handle kernel NULL pointer dereference at virtual address 0090
pgd
On 05/09/2019 13:40, Mark Brown wrote:
> On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
>
>> Ah, I didn't realise that regulator_get() will return a dummy regulator
>> if none is provided in the DT. In theory that seems like a nicer
>> solution to my two
(+CC Rob - I'm not sure why he was dropped)
On 05/09/2019 17:34, Mark Brown wrote:
> On Thu, Sep 05, 2019 at 02:02:38PM +0100, Steven Price wrote:
>> On 05/09/2019 13:40, Mark Brown wrote:
>
>>> Is that safe? You can't rely on being able to change voltages even if
&
On 06/09/2019 12:10, Rob Herring wrote:
> On Thu, Sep 5, 2019 at 1:11 PM Steven Price wrote:
>>
>> When handling a GPU page fault addr_to_drm_mm_node() is used to
>> translate the GPU address to a buffer object. However it is possible for
>> the buffer object to be f
On 09/09/2019 16:51, Krzysztof Kozlowski wrote:
> There is no point to print deferred probe (and its failures to get
> resources) as an error.
>
> In case of multiple probe tries this would pollute the dmesg.
>
> Signed-off-by: Krzysztof Kozlowski
Looks like a good idea, however from what I
for being able to submit multiple jobs per slot
which requires more values than the original boolean per slot.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 64 -
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 +-
drivers/gpu/drm/panfrost
52282163dfa6 and e21dd290881b which would otherwise need reverting, see
the previous discussion[2].
[1] https://lore.kernel.org/lkml/20190904123032.23263-1-broo...@kernel.org/
[2] https://lore.kernel.org/lkml/ccd81530-2dbd-3c02-ca0a-1085b0066...@arm.com/
Steven Price (2):
drm/panfrost: Use generic code
Use dev_pm_opp_set_rate() instead of open coding the devfreq
integration, simplifying the code.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 62 -
drivers/gpu/drm/panfrost/panfrost_device.h | 2 -
2 files changed, 10 insertions(+), 54
On 07/09/2019 20:36, Daniel Vetter wrote:
> On Fri, Sep 6, 2019 at 2:42 PM Steven Price wrote:
>>
>> On 06/09/2019 12:10, Rob Herring wrote:
>>> On Thu, Sep 5, 2019 at 1:11 PM Steven Price wrote:
>>>>
>>>> When handling a GPU page fault addr_to
On 13/09/2019 12:17, Boris Brezillon wrote:
> So we can choose to wait for all BO users, or just for writers.
>
> Signed-off-by: Boris Brezillon
Looks good to me:
Reviewed-by: Steven Price
Although I don't know if the term "writers" should be in the API or if
"exc
the panfrost_gem_object with an
extra reference on it, preventing the BO from being freed until after
the page fault has been handled.
Signed-off-by: Steven Price
---
Changes since v1:
* Hold the mm_lock around drm_mm_for_each_node()
I've also posted a new IGT test for this:
https://patchwork.freedesktop.org/patch
On 13/09/2019 12:17, Boris Brezillon wrote:
> The READ/WRITE flags are particularly useful if we want to avoid
> serialization of jobs that read from the same BO but never write to it.
> The NO_IMPLICIT_FENCE might be useful when the user knows the BO is
> shared but jobs are using different
On 13/09/2019 13:29, Gerd Hoffmann wrote:
> Switch gem shmem helper to the new mmap() workflow,
> from _driver.fops.mmap to _gem_object_funcs.mmap.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_shmem_helper.h | 6 ++
> drivers/gpu/drm/drm_gem_shmem_helper.c | 26
Hi,
I hit the below splat randomly with panfrost. From what I can tell this
is a more general issue which would affect other drivers.
8<-
[58604.913130] [ cut here ]
[58604.918590] WARNING: CPU: 1 PID: 1758 at kernel/sched/core.c:6556
__might_sleep+0x74/0x98
On Thu, Sep 05, 2019 at 01:11:41PM +0100, Steven Price wrote:
When handling a GPU page fault addr_to_drm_mm_node() is used to
translate the GPU address to a buffer object. However it is possible for
the buffer object to be freed after the function has returned resulting
in a use-after-free
Regards,
Christian.
Am 13.09.19 um 16:50 schrieb Steven Price:
Hi,
I hit the below splat randomly with panfrost. From what I can tell this
is a more general issue which would affect other drivers.
8<-
[58604.913130] [ cut here ]
[58604.918590] WARNING: CPU: 1
On 09/09/2019 16:41, Rob Herring wrote:
> On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
>>
>> On 04/09/2019 13:30, Mark Brown wrote:
>>> The panfrost driver requests a supply using regulator_get_optional()
>>> but both the name of the supply and the usage pat
On 05/09/2019 09:21, Rob Herring wrote:
> +Steven
>
> On Wed, Sep 4, 2019 at 1:30 PM Mark Brown wrote:
>>
>> The panfrost driver requests a supply using regulator_get_optional()
>> but both the name of the supply and the usage pattern suggest that it is
>> being used for the main power for the
On 06/09/2019 11:55, Mark Brown wrote:
[...]
>>> However you're probably better off hiding all this stuff with the
>>> generic OPP code rather than open coding it - this already has much
>>> better handling for this, it supports voltage ranges rather than single
>>> voltages and optional
for function, there is no meaningful handling for absent
> supplies. Such regulators should use the vanilla regulator_get()
> interface, it will ensure that even if a supply is not described in the
> system integration one will be provided in software.
>
> Signed-off-by: Mark Brown
Test
On 07/08/2019 15:15, Matthew Wilcox wrote:
> On Tue, Aug 06, 2019 at 11:40:00PM -0700, Christoph Hellwig wrote:
>> On Tue, Aug 06, 2019 at 12:09:38PM -0700, Matthew Wilcox wrote:
>>> Has anyone looked at turning the interface inside-out? ie something like:
>>>
>>> struct mm_walk_state state =
1 - 100 of 750 matches
Mail list logo
