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
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
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 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 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 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
the ARM domain before attaching a new one.
Suggested-by: Robin Murphy
Signed-off-by: Steven Price
---
See also the thread[1] where I reported the regression.
[1]
https://lore.kernel.org/linux-kernel/da9cca0a-ec5b-2e73-9de0-a930f7d947b2%40arm.com
---
drivers/gpu/drm/rockchip/rockchip
* also update the drivers that build upon GEM SHMEM
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 5 +++--
> drivers/gpu/drm/lima/lima_gem.c | 1 +
> drivers/gpu/drm/panfrost/panfrost_gem.c | 1 +
rt this feature mimicking kbase's behaviour.
>
> Tuning this register slightly improves performance of index-driven vertex
> shading. On Mali-G52 (with Mesa), overall glmark2 score is improved from 1026
> to
> 1037. Geometry-heavy scenes like -bshading are improved from 1068 to 1098.
&g
On 11/02/2022 20:27, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> From the kernel's perspective, pre-CSF Valhall is more or less
> compatible with Bifrost, although they differ to userspace. Add a
> compatible for Valhall to the existing Bifrost bindings documentation.
>
On 11/02/2022 20:27, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
> from kbase. kbase lists this workaround as used on Mali-G57.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewe
On 11/02/2022 20:27, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> Logically, this function is free of side effects, so any pointers it
> takes should be const. Needed to avoid a warning in the next patch.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewe
On 11/02/2022 20:27, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> Some Valhall GPUs require resets when encountering bus faults due to
> occlusion query writes. Add the issue bit for this and handle it.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewe
course the timing has to be 'just
right' to hit the bug.
That said I think we should probably add pre-emption support sometime at
which point this could become an issue.
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost
y details. It's still useful
> to have the bit to record the feature bit when adding new models.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
Sadly I don't have the hardware to try this out on, but it should be a
simple case of the below (untested):
8
set to non-zero values. When
> left as zero, reads and writes are not throttled.
>
> Both kbase and panfrost always zero these registers. Per discussion with
> Steven Price, there are two reasons these quirks may be used:
>
> 1. Simulating slower memory subsystems. This use case is o
On 11/02/2022 20:27, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> Add the features, issues, and GPU ID for Mali-G57, a first-generation
> Valhall GPU. Other first- and second-generation Valhall GPUs should be
> similar.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> drive
On 11/02/2022 20:27, alyssa.rosenzw...@collabora.com wrote:
> From: Alyssa Rosenzweig
>
> The most important Valhall-specific quirks have been handled, so add the
> Valhall compatible and probe.
>
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Steven Price
> ---
>
On 14/02/2022 17:06, Alyssa Rosenzweig wrote:
> On Mon, Feb 14, 2022 at 04:23:18PM +0000, Steven Price wrote:
>> On 11/02/2022 20:27, alyssa.rosenzw...@collabora.com wrote:
>>> From: Alyssa Rosenzweig
>>>
>>> Some Valhall GPUs require resets when encountering b
ll useful
>>> to have the bit to record the feature bit when adding new models.
>>>
>>> Signed-off-by: Alyssa Rosenzweig
>>
>> Reviewed-by: Steven Price
>>
>> Sadly I don't have the hardware to try this out on, but it should be a
>>
On 03/12/2021 13:08, Liviu Dudau wrote:
> On Fri, Dec 03, 2021 at 10:28:15AM +0000, Steven Price wrote:
>> While the check for format_count > 64 in __drm_universal_plane_init()
>> shouldn't be hit (it's a WARN_ON), in its current position it will then
>> leak the
uot;drm/panfrost: Add the panfrost_gem_mapping concept")
Reviewed-by: Steven Price
Thanks,
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/
On 29/07/2022 15:46, Adrián Larumbe wrote:
> In the event of a job timeout, debug dump information will be written into
> /sys/class/devcoredump.
>
> Inspired by etnaviv's similar feature.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Steven Price
I'll push the
han using magic numbers.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_regs.h | 42 ++--
> 1 file changed, 24 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_
On 17/05/2022 18:42, Adrián Larumbe wrote:
> In the event of a job timeout, debug dump information will be written into
> /sys/class/devcoredump.
>
> Inspired by etnaviv's similar feature.
>
> Signed-off-by: Adrián Larumbe
Nice! Some comments below.
> ---
> drivers/gpu/drm/panfrost/Kconfig
ting
in a splat.
To fix this, drop the reference to panfrost_priv in the job structure
and add a direct reference to the MMU structure which is what's actually
needed.
Fixes: 7fdc48cc63a3 ("drm/panfrost: Make sure MMU context lifetime is not bound
to panfrost_priv")
Signed-off-by:
ULL(HW_ISSUE_TTRX_2968_TTRX_3162) | \
> + BIT_ULL(HW_ISSUE_TTRX_3076) | \
> + BIT_ULL(HW_ISSUE_TTRX_3485))
There's no need to repeat the issues that are generic for g57 in the
r0p0 list. So this can be simplified to:
#define hw_issues_g57_r0p0 (\
BIT_ULL(HW_ISSUE_TTRX_3485))
With that fixed:
Reviewed-by: Steven Price
> +
> static inline bool panfrost_has_hw_issue(const struct panfrost_device *pfdev,
>enum panfrost_hw_issue issue)
> {
> As the first SoC with a Valhall GPU receiving mainline support, add a
> specific compatible for the MediaTek MT8192, which instantiates a
> Mali-G57.
>
> v2: Change compatible to arm,mali-valhall-jm (Daniel Stone).
>
> Signed-off-by: Alyssa Rosenzweig
> CC: de
On 26/05/2022 12:42, Viresh Kumar wrote:
> The OPP core now provides a unified API for setting all configuration
> types, i.e. dev_pm_opp_set_config().
>
> Lets start using it.
>
> Signed-off-by: Viresh Kumar
Acked-by: Steven Price
> ---
> drivers/gpu/drm/panfros
added. Fix it.
>
> Cc: sta...@vger.kernel.org
> Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 4 ++--
> 1 file changed, 2 insertions
On 22/06/2022 15:36, Adrián Larumbe wrote:
> Each Panfrost job has its own job slot and MMU address space set of
> registers, which are selected with a job-specific index.
>
> Turn the shift and stride used for selection of the right register set base
> into a define rather than using magic number
On 22/06/2022 15:36, Adrián Larumbe wrote:
> In the event of a job timeout, debug dump information will be written into
> /sys/class/devcoredump.
>
> Inspired by etnaviv's similar feature.
>
> Signed-off-by: Adrián Larumbe
Looks pretty good, a few comments below.
> ---
> drivers/gpu/drm/panfr
On 04/07/2022 13:07, Viresh Kumar wrote:
> Make dev_pm_opp_set_regulators() accept a NULL terminated list of names
> instead of making the callers keep the two parameters in sync, which
> creates an opportunity for bugs to get in.
>
> Suggested-by: Greg Kroah-Hartman
> Signed-off-by: Viresh Kumar
On 30/06/2022 21:05, Dmitry Osipenko wrote:
> This series fixes two minor bugs in the Panfrost driver.
>
> Changelog:
>
> v7: - Factored out Panfrost fixes from [1] since I'll be working on
> the dma-buf locking in a separate patchset now.
>
> [1]
> https://lore.kernel.org/all/20220526235
On 05/07/2022 05:34, Viresh Kumar wrote:
> On 04-07-22, 15:35, Steven Price wrote:
>> I have to say the 'new improved' list ending with NULL approach doesn't
>> work out so well for Panfrost. We already have to have a separate
>> 'num_suppl
static const struct panfrost_compatible mediatek_mt8183_data = {
> - .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
> + .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies) - 1,
> .supply_names = mediatek_mt8183_supplies,
> .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
> .pm_domain_names = mediatek_mt8183_pm_domains,
Reviewed-by: Steven Price
Thanks for the rework, much cleaner.
Steve
ed. There is no good reason for releasing scheduler's jobs in IRQ
> context, hence use normal context to fix the trouble.
>
> Cc: sta...@vger.kernel.org
> Fixes: 542cff7893a3 ("drm/sched: Avoid lockdep spalt on killing a processes")
> Signed-off-by: Dmitry Osipen
On 14/04/2022 12:51, AngeloGioacchino Del Regno wrote:
> Il 14/04/22 04:50, Nick Fan ha scritto:
>> Add devicetree schema for Arm Mali Valhall GPU
>>
>> Define a compatible string for the Mali Valhall GPU
>> for MediaTek's SoC platform.
>>
>> Signed-off-by: Nick Fan
>
> Hello Nick,
> Unfortunatel
he more efficient interface.
>
> Signed-off-by: Robin Murphy
Looks correct to me. Although the voodoo magic does take a little bit of
figuring out ;)
Reviewed-by: Steven Price
I'll push to drm-misc-next.
Thanks,
Steve
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 40 +
> Suggested-by: Viresh Kumar
> Signed-off-by: Clément Péron
Reviewed-by: Steven Price
Note this same sequence is used in the Lima driver, so it would be good
to submit the fix there too as it presumably is affected by the same
issue. I've CC'd Qiang for visibility.
I'll pus
8<
>From 492714a7dff0710ac5b8b457bcfe9ae52b458565 Mon Sep 17 00:00:00 2001
From: Steven Price
Date: Tue, 13 Sep 2022 09:37:55 +0100
Subject: [PATCH] drm/panfrost: Remove type name from internal structs
The two structs internal to struct panfrost_dump_object_header were
named, but sad
On 19/09/2022 07:44, Adrián Larumbe wrote:
> Hi Steven,
>
> On 13.09.2022 09:45, Steven Price wrote:
>> On 12/09/2022 17:44, Adrián Larumbe wrote:
>>> Building Mesa's Perfetto requires including the panfrost drm uAPI header in
>>> C++ code, but the C++ comp
On 20/09/2022 23:13, Alyssa Rosenzweig wrote:
> Tentative r-b, but we *do* need to make a decision on how we want to
> handle endianness. I don't have strong feelings but the results of that
> discussion should go in the commit message.
Linux currently treats the dump objects specially - the heade
On 14/09/2022 17:43, Arvind Yadav wrote:
> Using the parent fence instead of the finished fence
> to get the job status. This change is to avoid GPU
> scheduler timeout error which can cause GPU reset.
I'm able to reproduce crashes on Panfrost and I believe this commit is
the cause. Specifically i
On 29/09/2022 15:57, Christian König wrote:
> Am 29.09.22 um 16:53 schrieb Steven Price:
>> On 14/09/2022 17:43, Arvind Yadav wrote:
>>> Using the parent fence instead of the finished fence
>>> to get the job status. This change is to avoid GPU
>>> scheduler tim
On 29/09/2022 19:01, Christian König wrote:
> Otherwise we would crash if the job is not resubmitted.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main
On 18/07/2022 18:24, Adrián Larumbe wrote:
> In the event of a job timeout, debug dump information will be written into
> /sys/class/devcoredump.
>
> Inspired by etnaviv's similar feature.
>
> Signed-off-by: Adrián Larumbe
LGTM
Reviewed-by: Steven Price
Steve
&
hardware that defines this, and secondly if
hardware did add more registers and change the stride then we'd still
need compatibility with the old hardware. So most likely we'd need a new
driver for the new hardware. So just drop the comment.
I'm not really sure why we have both
ning: no previous
> > > prototype for ‘panfrost_mmu_flush_range’ [-Wmissing-prototypes]
> > > drivers/gpu/drm/panfrost/panfrost_mmu.c:435:5: warning: no previous
> > > prototype for ‘panfrost_mmu_map_fault_addr’ [-Wmissing-prototypes]
> > >
>
tter
> Cc: Robin Murphy
> Cc: Steven Price
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Signed-off-by: Emil Velikov
Reviewed-by: Steven Price
I'm not sure DRM_AUTH provided us with much in the first place (because
render nodes could snoop/
On 08/11/2019 13:10, Emil Velikov wrote:
> On Fri, 1 Nov 2019 at 13:34, Steven Price wrote:
>>
>> On 01/11/2019 13:03, Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> As of earlier commit we have address space separation. Yet we forgot to
>>>
sys_initcall(dma_resv_lockdep);
This expects a function returning int, but dma_resv_lockdep() is void.
Causing:
drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
{aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
[-Werror=incompatible-pointer-types]
s
On 11/11/2019 15:42, Daniel Vetter wrote:
> On Mon, Nov 11, 2019 at 2:11 PM Steven Price wrote:
>>
>> On 04/11/2019 17:37, Daniel Vetter wrote:
>>> Full audit of everyone:
>>>
>>> - i915, radeon, amdgpu should be clean per their maintainers.
>>&g
t_cur_freq(), but in
this case because the function is optional we can just remove it and
devfreq will fall back to using the previously set frequency.
Fixes: 221bc77914cb ("drm/panfrost: Use generic code for devfreq")
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/pan
On 10/12/2019 23:08, Rob Herring wrote:
> From: Boris Brezillon
>
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context or if the dmabuf is self-imported. The
> current im
h requested
> interrupt with the module name: panfrost-{gpu,job,mmu}.
>
> Signed-off-by: Ezequiel Garcia
LGTM
Reviewed-by: Steven Price
> ---
> v2:
> * Use consistent naming, as suggested by Alyssa, Neil and Robin.
>
> drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +-
On 17/12/2019 06:37, Randy Dunlap wrote:
> On 12/16/19 9:42 PM, Sam Ravnborg wrote:
>> Hi Randy.
>>
>> On Mon, Dec 16, 2019 at 08:25:11AM -0800, Randy Dunlap wrote:
>>> On 12/15/19 9:22 PM, Stephen Rothwell wrote:
Hi all,
Changes since 20191213:
>>>
>>> on x86_64:
>>>
>>> ld: dr
tial panfrost driver")
> Signed-off-by: Martin Blumenstingl
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drive
On 07/01/2020 23:06, Martin Blumenstingl wrote:
> dev_pm_opp_set_rate() needs a reference to the regulator which should be
> updated when updating the GPU frequency. The name of the regulator has
> to be passed at initialization-time using dev_pm_opp_set_regulators().
> Add the call to dev_pm_opp_s
On 08/01/2020 05:23, Nicolas Boichat wrote:
Hi!
Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
finally got around to give this a real try.
The main purpose of this series is to upstream the dts change and the binding
document, but I wanted to see how far I could pr
On 08/01/2020 05:23, Nicolas Boichat wrote:
It is useful to know which component cannot be powered on.
Signed-off-by: Nicolas Boichat
Looks like helpful error reporting.
Reviewed-by: Steven Price
---
Was useful when trying to probe bifrost GPU, to understand what
issue we are facing
On Thu, Jan 09, 2020 at 01:10:33PM +, Robin Murphy wrote:
> On 09/01/2020 12:01 pm, Steven Price wrote:
> > On 08/01/2020 05:23, Nicolas Boichat wrote:
> >> Hi!
> >>
> >> Sorry for the long delay since
> >> https://patchwork.kernel.org/patch/1113
the Power
Domain Controller. This should only be enabled on platforms which
integration of the PDC to the Mali GPU is known to be problematic.
This feature is currently only supported on t-Six and t-HEx GPUs.
If unsure, say N.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost
On 08/01/2020 05:23, Nicolas Boichat wrote:
When there is a single power domain per device, the core will
ensure the power domains are all switched on.
However, when there are multiple ones, as in MT8183 Bifrost GPU,
we need to handle them in driver code.
Signed-off-by: Nicolas Boichat
---
T
On 08/01/2020 05:23, Nicolas Boichat wrote:
For testing only, the driver doesn't really work yet, AFAICT.
Signed-off-by: Nicolas Boichat
It does work (at least on the Hikey960), we just don't have any public user
space driver for it... ;)
Reviewed-by: Steven Price
---
drive
On 08/01/2020 22:52, Nicolas Boichat wrote:
On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote:
On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
regulator for their SRAM, let's add support for that.
+ pfdev-
On 09/01/2020 16:28, Mark Brown wrote:
On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:
On 08/01/2020 22:52, Nicolas Boichat wrote:
That'd be a bit awkward to match, though... Currently all bifrost
share the same compatible "arm,mali-bifrost", and it'd seem
devm_regulator_get() is used to populate pfdev->regulator which ensures
that this cannot be NULL (a dummy regulator will be returned if
necessary). So remove the check in panfrost_devfreq_target().
Signed-off-by: Steven Price
---
This looks like it was accidentally reintroduced by the merge f
On 04/10/2019 16:03, Neil Armstrong wrote:
> On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
>>
>> On 10/3/19 4:34 AM, Neil Armstrong wrote:
>>> Hi Andrey,
>>>
>>> Le 02/10/2019 à 16:40, Grodzovsky, Andrey a écrit :
On 9/30/19 10:52 AM, Hillf Danton wrote:
> On Mon, 30 Sep 2019 11:17:45 +02
On 04/10/2019 16:34, Koenig, Christian wrote:
> Am 04.10.19 um 17:27 schrieb Steven Price:
>> On 04/10/2019 16:03, Neil Armstrong wrote:
>>> On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
>>>> On 10/3/19 4:34 AM, Neil Armstrong wrote:
>>>>> Hi Andrey,
On 04/10/2019 17:33, Koenig, Christian wrote:
>
>
> Am 04.10.2019 18:02 schrieb Steven Price :
> On 04/10/2019 16:34, Koenig, Christian wrote:
>> Am 04.10.19 um 17:27 schrieb Steven Price:
>>> On 04/10/2019 16:03, Neil Armstrong wrote:
>>>> On 04/10/2019 16
ned-off-by: Steven Price
---
This is a tidied up version of the patch orginally posted here:
http://lkml.kernel.org/r/26ae2a4d-8df1-e8db-3060-41638ed63e2a%40arm.com
drivers/gpu/drm/panfrost/panfrost_job.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drive
On 07/10/2019 17:14, Tomeu Vizoso wrote:
> On 10/7/19 6:09 AM, Neil Armstrong wrote:
>> Hi Steven,
>>
>> On 07/10/2019 14:50, Steven Price wrote:
>>> Panfrost uses multiple schedulers (one for each slot, so 2 in reality),
>>> and on a timeout has to stop
panfrost_core_dump() has never existed in mainline, so remove it and add
a TODO entry that core dump support is currently lacking.
Signed-off-by: Steven Price
---
v2:
* New patch
drivers/gpu/drm/panfrost/TODO | 2 ++
drivers/gpu/drm/panfrost/panfrost_job.c | 2 --
2 files changed, 2
trong
Signed-off-by: Steven Price
---
v2:
* Added fixes and tested-by tags
* Moved cleanup of panfrost_core_dump() comment to separate patch
drivers/gpu/drm/panfrost/panfrost_job.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfr
Three feature registers were declared but never actually read from the
GPU. Add THREAD_MAX_THREADS, THREAD_MAX_WORKGROUP_SIZE and
THREAD_MAX_BARRIER_SIZE so that the complete set are available.
Fixes: 4bced8bea094 ("drm/panfrost: Export all GPU feature registers")
Signed-off-by: St
utput). In theory
it also allows the GPU (and by extension user space) to observe the
memory contents prior to sanitization.
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 20
On 14/10/2019 16:46, Robin Murphy wrote:
> On 14/10/2019 16:16, Steven Price wrote:
>> Pages shared with the GPU are (often) not cache coherent with the CPU so
>> cache maintenance is required to flush the CPU's caches. This was
>> already done when mapping pages on fa
On 14/10/2019 16:55, Steven Price wrote:
> On 14/10/2019 16:46, Robin Murphy wrote:
>> On 14/10/2019 16:16, Steven Price wrote:
>>> Pages shared with the GPU are (often) not cache coherent with the CPU so
>>> cache maintenance is required to flush the CPU's caches
e panfrost_perfcnt.c, include head file can fix this.
Nit: s/head/header/
>
> Signed-off-by: Yi Wang
Looks good, just a few minor style issues (below), with those fixed:
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 5 +++--
> drivers
> For file panfrost_perfcnt.c, include header file can fix this.
>
> Signed-off-by: Yi Wang
> Reviewed-by: Steven Price
> ---
>
> v2: align parameter line, modify comment and sort header
> includes alphabetically. Thanks to Steve.
> ---
> drivers/gpu/drm/panfrost/pan
> Reported-by: Chen-Yu Tsai
> Cc: Robin Murphy
> Fixes: f4a3c6a44b35 ("drm/panfrost: Disable PM on probe failure")
As Robin pointed out this should be:
Fixes: 635430797d3f ("drm/panfrost: Rework runtime PM initialization")
But other than that,
Reviewed-
p_job() and simply return a job for processing if
there is one. The caller can then call the free_job() callback outside
the wait_event_interruptible() where sleeping is possible before
re-checking and returning to sleep if necessary.
Signed-off-by: Steven Price
---
Previous posting:
> For file panfrost_perfcnt.c, include header file can fix this.
>
> Signed-off-by: Yi Wang
> Reviewed-by: Steven Price
> ---
>
> v3: using tab size of 8 other than 4.
>
> v2: align parameter line and modify comment. Thanks to Steve.
> ---
> drivers/gpu/drm/panfrost/
On 25/10/2019 10:43, Christian Gmeiner wrote:
> Am Do., 24. Okt. 2019 um 18:25 Uhr schrieb Steven Price
> :
>>
>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>> it is called as the condition of wait_event_interruptible() it must not
>>
On 25/10/2019 10:49, Koenig, Christian wrote:
> Am 24.10.19 um 18:24 schrieb Steven Price:
>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>> it is called as the condition of wait_event_interruptible() it must not
>> sleep. Unfortuantly some free c
er: rework job destruction")
Signed-off-by: Steven Price
---
Changes since v4:
* Don't initialise job in drm_sched_get_cleanup_job()
* Change while loop into if in drm_sched_main()
drivers/gpu/drm/scheduler/sched_main.c | 43 ++
1 file changed, 24 inserti
o makes way for being able to submit multiple jobs per slot
which requires more values than the original boolean per slot.
Reviewed-by: Tomeu Vizoso
Reviewed-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 64 -
drivers/g
ecifically after
d18a96620411 ("drm/panfrost: Remove NULL checks for regulator")
* Added tags
Steven Price (2):
drm/panfrost: Use generic code for devfreq
drm/panfrost: Simplify devfreq utilisation tracking
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 124 ++---
Use dev_pm_opp_set_rate() instead of open coding the devfreq
integration, simplifying the code.
Reviewed-by: Mark Brown
Reviewed-by: Tomeu Vizoso
Acked-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 60 -
drivers/gpu
.
>
> Signed-off-by: Nicolas Boichat
Reviewed-by: Steven Price
Thanks,
Steve
>
> ---
>
> v4:
> - nits: Run through latest version of checkpatch:
>- Use WARN instead of BUG_ON.
>- Drop braces in single expression for loop.
>- *comp not * comp
MT8183 Bifrost
> GPU, we need to handle them in driver code.
>
> Signed-off-by: Nicolas Boichat
LGTM!
Reviewed-by: Steven Price
Thanks,
Steve
>
> ---
>
> The downstream driver we use on chromeos-4.19 currently uses 2
> additional devices in device tree to accomo
b.freedesktop.org/panfrost/mali_kbase/blob/master/driver/product/kernel/drivers/gpu/arm/midgard/backend/gpu/mali_kbase_js_backend.c#L156
>
> Only compile tested.
I've done some quick testing on a Firefly RK3288. But I don't have any
(handy) tests to trigger non-TRANSLATION_FAUL
On 22/02/2020 19:42, Martin Blumenstingl wrote:
> Hi Steven,
>
> On Sun, Jan 12, 2020 at 1:16 AM Martin Blumenstingl
> wrote:
>>
[...]
>>
>>
>> Martin Blumenstingl (3):
>> drm/panfrost: enable devfreq based the "operating-points-v2" property
>> drm/panfrost: call dev_pm_opp_of_remove_table()
On 28/02/2020 09:40, Marek Szyprowski wrote:
> Signed-off-by: Marek Szyprowski
Reviewed-by: Steven Price
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Mar 06, 2020 at 02:13:08PM +, Rob Herring wrote:
> On Thu, Mar 5, 2020 at 8:34 PM Nick Fan wrote:
> >
> > Sorry for my late reply.
> > I have checked internally.
> > The MT8183_POWER_DOMAIN_MFG_2D is just a legacy name, not really 2D
> > domain.
> >
> > If the naming too confusing, we
LL parameter indicates that the power model is simplified and
> created based on DT 'dynamic-power-coefficient', voltage and frequency.
>
> Signed-off-by: Lukasz Luba
LGTM!
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +-
> 1
ewalk: add p4d_entry() and pgd_entry()")
Cc: Steven Price
Signed-off-by: Jason Gunthorpe
Sorry about that, thanks for fixing.
Reviewed-by: Steven Price
---
mm/hmm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 9e8f
By refactoring to deal with the !pud_huge(pud) || !pud_devmap(pud)
condition early it's possible to remove the 'ret' variable and remove a
level of indentation from half the function making the code easier to
read.
No functional change.
Signed-off-by: Steven Price
---
Thanks to
On 12/03/2020 14:27, Jason Gunthorpe wrote:
On Thu, Mar 12, 2020 at 10:28:13AM +, Steven Price wrote:
By refactoring to deal with the !pud_huge(pud) || !pud_devmap(pud)
condition early it's possible to remove the 'ret' variable and remove a
level of indentation from half the
201 - 300 of 799 matches
Mail list logo
