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 009
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 de
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: To
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 swit
lready 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-b
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
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
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
)
> 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/
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-
all the runtime 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-b
teven 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
-
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
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
ex_trylock() 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 fi
c: Daniel Vetter
Signed-off-by: Rob Herring
I thought I'd already 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 de
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
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
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 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.
>>
>>
sem){}, at: shrink_slab+0xbc/0x2c0
> #2: f31efa81 (&pfdev->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 R
; __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
>
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
>
/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
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
---
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.
>
&g
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 th
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
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&q
l 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/pan
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
not in use from our LRU list 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
St
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 f
t a time 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 Murph
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 wh
ddress spaces.
>
> 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 (jus
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
> Cc: 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 (bise
On 02/08/2019 20:51, Rob Herring wrote:
> In preparation to create partial GPU mappings of BOs on page faults,
> split out the SG list handling of panfrost_mmu_map().
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Acked-by: Alyssa
t a time 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 Murph
gt; Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 20 +++-
> 1 file changed, 15 insertion
On 06/08/2019 22:08, Rob Herring wrote:
On Tue, Aug 6, 2019 at 2:25 PM 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.
On 06/08/2019 21:25, Alyssa Rosenzweig wrote:
>>> It's not obvious to me when it actually needs to be enabled. Besides the
>>> errata, it's only when... device_nr=1 for a compute-only job in kbase?
>>>
>>> I'm afraid I don't know nearly enough about how kbase plumbs CL to grok
>>> the signifiance..
On 07/08/2019 15:56, Matthew Wilcox wrote:
> On Wed, Aug 07, 2019 at 03:30:38PM +0100, Steven Price wrote:
>> 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:38
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 =
On 30/07/2019 21:03, Rob Herring wrote:
> On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
>>
>> On 25/07/2019 15:59, Steven Price wrote:
>> [...]
>>> It would appear that in the following call sgt==NULL:
>>>> ret = sg_alloc
On 30/07/2019 20:08, Rob Herring wrote:
> On Tue, Jul 30, 2019 at 12:55 PM Alyssa Rosenzweig
> wrote:
>>
>>> In any case, per process AS is a prerequisite to all this.
>>
>> Oh, I hadn't realized that was still a todo. In the meantime, what's the
>> implication of shipping without it? (I.e. in whi
On 25/07/2019 18:40, Alyssa Rosenzweig wrote:
Sorry, I was being sloppy again![1] I meant CPU mmapped.
No worries, just wanted to check :)
Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer -
since SAME_VA means permanently mapped on the CPU this translated to
mmapping a H
On 25/07/2019 22:11, Rob Herring wrote:
On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy wrote:
Hi Rob,
On 25/07/2019 02:10, Rob Herring wrote:
[...]
@@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int irq, void
*data)
access_type = (fault_status >> 8) & 0x3;
On 25/07/2019 15:59, Steven Price wrote:
[...]
> It would appear that in the following call sgt==NULL:
>> ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
>> NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL);
>
> Which means we've
age pointers.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring
LGTM: Reviewed-by: Steven Price
> ---
> v2:
> - new patch
>
> dri
to the size of the BO. This shouldn't
> matter as there is plenty of GPU VA space.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
> ---
&
_PAGES, 0, SZ_2M, GFP_KERNEL);
Which means we've ended up with a BO with bo->sgt==NULL, bo->pages set
and bo->is_heap=true. My understanding is this should be impossible.
I haven't yet figured out how this happens - it seems to be just before
termination, so it might be a race wit
the base shmem object.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 21 +++-
On 25/07/2019 17:13, Alyssa Rosenzweig wrote:
>> Either we should prevent mapping of HEAP objects
>
> I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped
> anyway in normal use; if you need them mapped (for debugging etc), it's
> no big deal to just.. not set the HEAP flag in debug
On 25/07/2019 22:28, Rob Herring wrote:
On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
On 25/07/2019 15:59, Steven Price wrote:
[...]
It would appear that in the following call sgt==NULL:
ret = sg_alloc_table_from_pages(sgt, pages + page_offset
ect, so just put pages if the pages array is populated.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Signed-off-by: Rob Herring
LGTM: Reviewed-by: Steven Price
> ---
> v2:
> - new
: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c| 38 +++--
drivers/gpu/drm/panfrost/panfrost_gpu.c| 2 ++
include/uapi/drm/panfrost_drm.h| 39 ++
4 files changed, 77 insertions
On 22/07/2019 17:18, Rob Herring wrote:
> On Mon, Jul 22, 2019 at 7:25 AM Robin Murphy wrote:
>>
>> On 22/07/2019 13:19, Steven Price wrote:
>> [...]
>>> Indeed, that case was just occurring to me too! How about:
>>>
>>> u64 next_seg = A
On 22/07/2019 13:09, Robin Murphy wrote:
> On 22/07/2019 11:07, Steven Price wrote:
>> On 22/07/2019 10:50, Robin Murphy wrote:
>>> On 19/07/2019 23:07, Rob Herring wrote:
>>>> On Fri, Jul 19, 2019 at 4:39 AM Steven Price
>>>> wrote:
>>>>>
On 22/07/2019 10:50, Robin Murphy wrote:
> On 19/07/2019 23:07, Rob Herring wrote:
>> On Fri, Jul 19, 2019 at 4:39 AM Steven Price
>> wrote:
>>>
>>> On 18/07/2019 18:03, Rob Herring wrote:
>>>> On Thu, Jul 18, 2019 at 9:03 AM Steven Price
>>>
On 22/07/2019 15:38, Simon Ser wrote:
> From: Simon Ser
>
> The VSDB parsing code contains a few len >= N checks, accessing db[N] on
> success. However if len == N, db[N] is out-of-bounds.
I'm not familiar with VSDB parsing, but there's a comment before the
function:
> * @len: length of the CE
On 19/07/2019 23:22, Rob Herring wrote:
> On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>>
>> On 17/07/2019 19:33, Rob Herring wrote:
>>> Setting the GPU VA when creating the GEM object doesn't allow for any
>>> conditional adjustments. In preparatio
On 19/07/2019 23:07, Rob Herring wrote:
> On Fri, Jul 19, 2019 at 4:39 AM Steven Price wrote:
>>
>> On 18/07/2019 18:03, Rob Herring wrote:
>>> On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>>>>
>>>> On 17/07/2019 19:33, Rob Herring w
On 19/07/2019 15:27, Rob Herring wrote:
> On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>>
>> On 17/07/2019 19:33, Rob Herring wrote:
>>> The midgard/bifrost GPUs need to allocate GPU heap memory which is
>>> allocated on GPU page faults and not pinned in me
On 18/07/2019 18:03, Rob Herring wrote:
> On Thu, Jul 18, 2019 at 9:03 AM Steven Price wrote:
>>
>> On 17/07/2019 19:33, Rob Herring wrote:
>>> Executable buffers have an alignment restriction that they can't cross
>>> 16MB boundary as the GPU program c
On 17/07/2019 19:33, Rob Herring wrote:
> In preparation to create partial GPU mappings of BOs on page faults,
> split out the SG list handling of panfrost_mmu_map().
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzwe
the base shmem object.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Hi Rob,
I couldn't work out what base this series should be applied to, but I've
tried manuall
as there is plenty of GPU VA space.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 20 +++-
> drivers/gpu/drm/pa
t a time 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 Murp
() 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 though:
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 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 han
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 27/06/2019 17:38, Rob Herring wrote:
> On Thu, Jun 27, 2019 at 4:57 AM Steven Price wrote:
>>
>> Sorry for the slow response, I've been on holiday for a few weeks.
>
> Welcome back.
Thanks!
>>
>> On 20/06/2019 06:50, Tomeu Vizoso wrote:
>>> O
.
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
dumb clients.
v2: https://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 shme
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 Wed,
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
oes have a
"sparse" mechanism which 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
.
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
anges since v1:
* Rename 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 |
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
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.
>>
>
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
>
.
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
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
offset to drop _dumb
* 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 ++--
drive
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 s
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
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 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
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
NULL if userspace 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/panf
p; MMU [=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/drive
701 - 800 of 814 matches
Mail list logo
