Hi Chen,
Thanks for the patch! Just a couple minor notes.
On 21/08/2024 10:21, Chen Yufan wrote:
Subject: [PATCH v1] ImgTec powerVR DRM driver: Convert to use time_before macro
The prefix here should be based on the source path. For us, that's
"drm/imagination:".
Use time_before instead
I missed this open-coded kref_get() while trying to debug a refcount
bug, so let's use the helper function here to avoid that waste of time
again in the future.
Signed-off-by: Matt Coster
Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code")
---
drivers/gpu/
This caused a measurable memory leak. Although the individual
allocations are small, the leaks occurs in a high-usage codepath
(remapping or unmapping device memory) so they add up quickly.
Signed-off-by: Matt Coster
Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code"
On 23/08/2024 10:39, Chen Yufan wrote:
Use time_*() macros instead of using
jiffies directly to handle overflow issues.
Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW
support")
Signed-off-by: Chen Yufan
Hi Chen,
Apologies for the slow reply – it's been
I missed this open-coded kref_get() while trying to debug a refcount
bug, so let's use the helper function here to avoid that waste of time
again in the future.
Signed-off-by: Matt Coster
Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code")
---
drivers/gpu/
This caused a measurable memory leak. Although the individual
allocations are small, the leaks occurs in a high-usage codepath
(remapping or unmapping device memory) so they add up quickly.
Signed-off-by: Matt Coster
Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code"
On 31/08/2024 11:29, Jinjie Ruan wrote:
> Switching to memdup_user(), which combines kmalloc() and copy_from_user(),
> and it can simplfy code.
Applied, thanks!
[1/1] drm/imagination: Use memdup_user() helper to simplify code
commit: 3742c20958a5b02ecba08d71036bae3e7b9d21b3
Cheers,
Matt
On 11/08/2024 09:28, Icenowy Zheng wrote:
> Some new Rogue GPU cores have an extra MARS power domain, which
> controlls the power of the firmware core and allows the firmware core to
> power down most parts of the GPU.
>
> Adapt to this by ignoring power domains that should be powered down by
> th
On 02/09/2024 03:33, Jinjie Ruan wrote:
> Switching to memdup_user(), which combines kmalloc() and copy_from_user(),
> and it can simplfy code.
Applied, thanks!
[1/1] drm/imagination: Use memdup_user() helper
commit: 2872a57c7ad427d428c6d12e95e55b32bdc8e3b8
Cheers,
Matt
OpenPGP_signature
web.de
> https://lkml.org/lkml/2024/1/28/438
Hi Markus,
I apologise for missing your earlier email. In general, we'll happily
accept cleanup patches.
If you feel like your patch has gone ignored in future, please feel free
to ping me directly either by email or on IRC at MTCoster.
On 22/03/2024 13:01, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The array size calculation in pvr_vm_mips_fini() appears to be incorrect
> based on
> taking the size of the pointer rather than the size of the array, which
> manifests
> as a warning about signed integer overflow:
>
> In fil
Hi Adam,
On 18/02/2024 23:26, Adam Ford wrote:
> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote:
>>
>> On Fri, Feb 16, 2024 at 09:13:14AM +, Biju Das wrote:
>>> Hi Maxime Ripard,
>>>
-Original Message-
From: Maxime Ripard
Sent: Friday, February 16, 2024 9:05 AM
>>
Hi Adam,
On 19/02/2024 16:38, Adam Ford wrote:
> On Mon, Feb 19, 2024 at 1:45 AM Biju Das wrote:
>>
>> Hi Adam,
>>
>>> -Original Message-
>>> From: Adam Ford
>>> Sent: Sunday, February 18, 2024 11:26 PM
>>> Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend
>>> on
Hi Adam,
On 19/02/2024 20:38, Adam Ford wrote:
> On Mon, Feb 19, 2024 at 3:00 AM Matt Coster wrote:
>>
>> Hi Adam,
>>
>> On 18/02/2024 23:26, Adam Ford wrote:
>>> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard wrote:
>>>>
>>>> On Fri
Hi Adam,
Thanks for these patches! I'll just reply to this one patch, but my
comments apply to them all.
On 27/02/2024 03:45, Adam Ford wrote:
> The GPU on the RZ/G2M is a Rogue GX6250 which uses firmware
> rogue_4.45.2.58_v1.fw available from Imagination.
>
> When enumerated, it appears as:
>
Hi, thanks for the patch!
On 28/02/2024 01:23, Lu Yao wrote:
> When 'PAGE_SIZE=64K',the following compilation error occurs:
> "
> ../drivers/gpu/drm/imagination/pvr_fw_mips.c: In function
> ‘pvr_mips_fw_process’:
> ../drivers/gpu/drm/imagination/pvr_fw_mips.c:140:60: error: array
> subscript 0
On 25/01/2024 18:44, Daniel Vetter wrote:
> On Tue, Jan 23, 2024 at 01:04:24PM +0000, Matt Coster wrote:
>> From: Donald Robson
>>
>> When the kernel driver 'loses' the device, for instance if the firmware
>> stops communicating, the driver calls drm_dev_unplu
On 10/05/2024 09:43, Chen-Yu Tsai wrote:
> Hi,
>
> I got the following lockdep warnings while trying to make the powervr
> driver work on MT8173. This was observed while trying to run vkmark.
> This was on the next-20240506 kernel running Debian Sid with the
> Mesa 24.0.6 package rebuilt to includ
converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Matt Coster
> ---
> drivers/gpu/drm/imagination/pvr_dr
converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Acked-by: Matt Coster
> ---
> drivers/gpu/drm/imagination/pvr_dr
one go), I think with how drm maintenace works, it's best if the patches
> are picked up by their individual maintainers. I guess that's:
>
> - Frank Binns + Matt Coster for imagination
I've acked the imagination patch - feel free to land it however you
like. We don't h
David Airlie
> Cc: Daniel Vetter
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: Jani Nikula
> Cc:
/20240228012313.5934-1-ya...@kylinos.cn
Fixes: 927f3e0253c1 ("drm/imagination: Implement MIPS firmware processor and
MMU support")
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_fw_mips.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i
^~
I can't seem to reproduce this using the above toolchain (or any other),
even with -Woverflow explicitly specified.
The use of ARRAY_SIZE() in loop bounds is a pretty common construction –
even within the pvr driver. Do you see similar warnings anywhere else?
Reg
y: Steven Price
Closes:
https://lore.kernel.org/dri-devel/1b957ca4-71cf-42fd-ac81-1920592b9...@arm.com/
Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and
META FW support")
Signed-off-by: Donald Robson
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagin
build").
>
> Signed-off-by: Jani Nikula
I've been meaning to do something about this for a while, thanks!
Reviewed-by: Matt Coster
Cheers,
Matt
--
Matt Coster
E: matt.cos...@imgtec.com
> ---
>
> Cc: Frank Binns
> Cc: Matt Coster
> Cc: Nathan Chancellor
When remaining resources are being cleaned up on driver close,
outstanding VM mappings may result in resources being leaked, due
to an object reference loop, as shown below, with each object (or
set of objects) referencing the object below it:
PVR GEM Object
GPU scheduler "finished" fence
From: Brendan King
This is in preparation for the next commit, which makes use of the list.
Signed-off-by: Brendan King
Signed-off-by: Matt Coster
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/imagination/pvr_context.c | 14 ++
drivers/gpu/drm/imagination/pvr_context.h | 3
endan King
Signed-off-by: Matt Coster
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/imagination/pvr_context.c | 19 +++
drivers/gpu/drm/imagination/pvr_context.h | 18 ++
drivers/gpu/drm/imagination/pvr_vm.c | 22 ++
drivers/gpu/drm/i
> @@ -1482,7 +1482,7 @@ static const struct dev_pm_ops pvr_pm_ops = {
>
> static struct platform_driver pvr_driver = {
> .probe = pvr_probe,
> - .remove_new = pvr_remove,
> + .remove = pvr_remove,
> .driver = {
> .name = PVR_DRIVER_NAME,
>
endan King
Signed-off-by: Matt Coster
Reviewed-by: Frank Binns
Cc: sta...@vger.kernel.org
---
Changes in v1 -> v2:
- None
Changes in v2 -> v3:
- Add Frank's Rb [1]
- Add Cc: stable tag
[1]:
https://lore.kernel.org/dri-devel/b75e658cc5ce9ac24df2c31c1a6fd798a5f3a87f.ca...@imgtec.
King
Signed-off-by: Matt Coster
Reviewed-by: Frank Binns
Cc: sta...@vger.kernel.org
---
Changes in v1 -> v2:
- Add justification to the commit message so it stands on its own (e.g.
during bisect)
Changes in v2 -> v3:
- Add Frank's Rb [1]
- Add Cc: stable tag
[1]:
https://lore
When remaining resources are being cleaned up on driver close,
outstanding VM mappings may result in resources being leaked, due
to an object reference loop, as shown below, with each object (or
set of objects) referencing the object below it:
PVR GEM Object
GPU scheduler "finished" fence
When remaining resources are being cleaned up on driver close,
outstanding VM mappings may result in resources being leaked, due
to an object reference loop, as shown below, with each object (or
set of objects) referencing the object below it:
PVR GEM Object
GPU scheduler "finished" fence
King
Signed-off-by: Matt Coster
---
Changes in v1 -> v2:
- Add justification to the commit message so it stands on its own (e.g.
during bisect)
---
drivers/gpu/drm/imagination/pvr_context.c | 14 ++
drivers/gpu/drm/imagination/pvr_context.h | 3 +++
drivers/gpu/drm/imaginat
endan King
Signed-off-by: Matt Coster
---
Changes in v1 -> v2:
- None
---
drivers/gpu/drm/imagination/pvr_context.c | 19 +++
drivers/gpu/drm/imagination/pvr_context.h | 18 ++
drivers/gpu/drm/imagination/pvr_vm.c | 22 ++
dr
ot have
an equivalent register.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_device.c | 1 -
drivers/gpu/drm/imagination/pvr_fw.h | 11 +--
drivers/gpu/drm/imagination/pvr_fw_meta.c | 1 -
drivers/gpu/drm/imagination/pvr_fw_mips.c | 1 -
4 files changed, 1 insert
rences for indices: clocks[1], interrupts[2], power[3].
[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel
[2]: https://downloads.ti.com/tisci/esd/latest/5_soc_doc/j721s2/clocks.html
[3]: https://downloads.ti.com/tisci/esd/latest/5_soc_doc/j721s2/devices.html
Signed-off-by: Matt Coster
Add the new compatible string recently introduced in the dt bindings
("img,img-bxs-4-64") to the dt_match table and link the appropriate
firmware.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drive
which specific changes refer to the workaround added there.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_device.c | 26
drivers/gpu/drm/imagination/pvr_device.h | 26
drivers/gpu/drm/imagination/pvr_drv.c| 34
Follow-on from the companion dt-bindings change ("dt-bindings: gpu: img:
More explicit compatible strings"), deprecating "img,img-axe" in favour of
the more specific "img,img-axe-1-16m".
Keep the previous compatible string around for backwards compatibilit
the CPU cache is the preferred solution.
Implement this workaround so that it can later be enabled for the TI
k3-j721s2 platform.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_device.c | 11 ++-
drivers/gpu/drm/imagination/pvr_device.h | 11 +++
drivers/gpu/drm
This allows for more versatility in checking and clearing firmware
registers used for interrupt handling.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_device.h | 18 +
drivers/gpu/drm/imagination/pvr_fw.h | 45 +--
drivers/gpu/drm
This attribute will be required for the BXS-4-64 MC1 and will be enabled in
the DTS for the TI k3-j721s2 in a subsequent patch; add it now so
dtbs_check doesn't complain later.
Signed-off-by: Matt Coster
---
Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 2 ++
1 file chang
.
Codify this "1 or 3" constraint in our bindings and hang the specifics off
the vendor compatible string to mirror the integration-time choice.
Signed-off-by: Matt Coster
---
.../devicetree/bindings/gpu/img,powervr-rogue.yaml | 27 +++---
1 file changed, 19 insertions(+), 8
With more than two firmware processor types, the if/else chain in
pvr_fw_init() gets a bit ridiculous. Use a static array indexed on
pvr_fw_processor_type (which is now a proper enum instead of #defines)
instead.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_device.h | 4
The single existing GPU (AXE-1-16M) only requires a single power domain.
Subsequent patches will add support for BXS-4-64 MC1, which has two power
domains. Add infrastructure now to allow for this.
Signed-off-by: Matt Coster
---
.../devicetree/bindings/gpu/img,powervr-rogue.yaml | 29
we're currently developing
support).
[1]: https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
[2]: https://github.com/SaschaWillems/Vulkan
[3]: https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/bxs
---
Matt Coster (20):
dt-bindings: gpu: img: More explicit compati
Use the new compatible string introduced earlier (in "dt-bindings: gpu:
img: More explicit compatible strings") and add a name to the single power
domain for this GPU (introduced in "dt-bindings: gpu: img: Power domain
details").
Signed-off-by: Matt Coster
---
arch/arm64
different GPU power
topologies.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_device.h | 8 +++
drivers/gpu/drm/imagination/pvr_drv.c| 10 ++-
drivers/gpu/drm/imagination/pvr_power.c | 114 +++
drivers/gpu/drm/imagination/pvr_power.h | 3 +
From: Sarah Walker
Newer PowerVR GPUs (such as the BXS-4-64 MC1) use a RISC-V firmware
processor instead of the previous MIPS or META.
Signed-off-by: Sarah Walker
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/Makefile | 1 +
drivers/gpu/drm/imagination/pvr_fw.c
This is currently a callback function which takes no parameters; there's
no reason for this so let's make it a straightforward value in pvr_fw_defs.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_fw.c | 2 +-
drivers/gpu/drm/imagination/pvr_fw.h
Currently only MIPS firmware processors use ELF-formatted firmware. When
adding support for RISC-V firmware processors, it will be useful to have
ELF handling functions ready to go.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/Makefile | 1 +
drivers/gpu/drm/imagination
Like the existing AXE-1-16M integration, BXS-4-64 uses the single clock
integration in the TI k3-j721s2.
Signed-off-by: Matt Coster
---
.../devicetree/bindings/gpu/img,powervr-rogue.yaml | 45 ++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree
Add definitions for a register required for a subsequent patch adding
support for RISC-V firmware. ROGUE_CR_FWCORE_DMI_DMCONTROL is used to
control the debug module in the firmware processor.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_rogue_cr_defs.h | 17
ducing more compatible strings to keep
the legacy versions to a minimum.
Signed-off-by: Matt Coster
---
.../devicetree/bindings/gpu/img,powervr-rogue.yaml| 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/img,power
Now that enable_reg isn't used, rename the previously shared event_mask to
status_mask since it's only used with status_reg.
Signed-off-by: Matt Coster
---
drivers/gpu/drm/imagination/pvr_fw.h | 6 +++---
drivers/gpu/drm/imagination/pvr_fw_meta.c | 2 +-
drivers/gpu/drm/i
For some reason, threaded IRQs do not play nice with the RISC-V firmware
processor in BXS on our test platform (TI AM68).
Until we can resolve this issue, revert to a more traditional workqueue-
based IRQ implementation so the platform is at least functional.
Signed-off-by: Matt Coster
On 05/11/2024 18:16, Conor Dooley wrote:
> On Tue, Nov 05, 2024 at 03:58:08PM +0000, Matt Coster wrote:
>> All Imagination GPUs use three clocks: core, mem and sys. All reasonably
>> modern Imagination GPUs also support a single-clock mode where the SoC
>> only hooks up core
On 05/11/2024 18:13, Conor Dooley wrote:
> On Tue, Nov 05, 2024 at 06:05:54PM +, Conor Dooley wrote:
>> On Tue, Nov 05, 2024 at 03:58:09PM +0000, Matt Coster wrote:
>>> The single existing GPU (AXE-1-16M) only requires a single power domain.
>>> Subsequent patches wi
On 05/11/2024 18:06, Conor Dooley wrote:
> On Tue, Nov 05, 2024 at 03:58:10PM +0000, Matt Coster wrote:
>> This attribute will be required for the BXS-4-64 MC1 and will be enabled in
>> the DTS for the TI k3-j721s2 in a subsequent patch; add it now so
>> dtbs_check d
On 05/11/2024 18:13, Conor Dooley wrote:
> On Tue, Nov 05, 2024 at 03:58:07PM +0000, Matt Coster wrote:
>> The current compatible strings are not specific enough to constrain the
>> hardware in devicetree. For example, the current "img,img-axe" string
>> refers to
On 05/11/2024 18:03, Conor Dooley wrote:
> On Tue, Nov 05, 2024 at 03:58:14PM +0000, Matt Coster wrote:
>> +/ {
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +interrupt-controller;
>> +#interrupt
Now that enable_reg isn't used, rename the previously shared event_mask to
status_mask since it's only used with status_reg.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-11-4ed30e865...@imgtec.com
--
which specific changes refer to the workaround added there.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-18-4ed30e865...@imgtec.com
---
drivers/gpu/drm/imagination/pvr_device.c | 26
drivers
keep
the legacy versions to a minimum.
Signed-off-by: Matt Coster
---
Changes in v2:
- Clarified justification for compatible strings
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-1-4ed30e865...@imgtec.com
---
.../devicetree/bindings/gpu/img,powervr-rogue.ya
The single existing GPU (AXE-1-16M) only requires a single power domain.
Subsequent patches will add support for BXS-4-64 MC1, which has two power
domains. Add infrastructure now to allow for this.
Signed-off-by: Matt Coster
---
Changes in v2:
- Simplified power-domains constraints P3
- Link to
This attribute will be required for the BXS-4-64 MC1 and will be enabled in
the DTS for the TI k3-j721s2 in a subsequent patch; add it now so
dtbs_check doesn't complain later.
Signed-off-by: Matt Coster
---
Changes in v2:
- Simplified power-domains constraints
- Link to v1:
From: Sarah Walker
Newer PowerVR GPUs (such as the BXS-4-64 MC1) use a RISC-V firmware
processor instead of the previous MIPS or META.
Signed-off-by: Sarah Walker
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1
Currently only MIPS firmware processors use ELF-formatted firmware. When
adding support for RISC-V firmware processors, it will be useful to have
ELF handling functions ready to go.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4
the CPU cache is the preferred solution.
Implement this workaround so that it can later be enabled for the TI
k3-j721s2 platform.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-19-4ed30e865...@imgtec.com
Follow-on from the companion dt-bindings change ("dt-bindings: gpu: img:
More explicit compatible strings"), deprecating "img,img-axe" in favour of
the more specific "img,img-axe-1-16m".
Keep the previous compatible string around for backwards compatibilit
Add definitions for a register required for a subsequent patch adding
support for RISC-V firmware. ROGUE_CR_FWCORE_DMI_DMCONTROL is used to
control the debug module in the firmware processor.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105
For some reason, threaded IRQs do not play nice with the RISC-V firmware
processor in BXS on our test platform (TI AM68).
Until we can resolve this issue, revert to a more traditional workqueue-
based IRQ implementation so the platform is at least functional.
Signed-off-by: Matt Coster
Use the new compatible string introduced earlier (in "dt-bindings: gpu:
img: More explicit compatible strings") and add a name to the single power
domain for this GPU (introduced in "dt-bindings: gpu: img: Power domain
details").
Signed-off-by: Matt Coster
---
Changes in v2:
This is currently a callback function which takes no parameters; there's
no reason for this so let's make it a straightforward value in pvr_fw_defs.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-12
ot have
an equivalent register.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-10-4ed30e865...@imgtec.com
---
drivers/gpu/drm/imagination/pvr_device.c | 1 -
drivers/gpu/drm/imagination/pvr_fw.h | 11 +-
Like the existing AXE-1-16M integration, BXS-4-64 uses the single clock
integration in the TI k3-j721s2.
Signed-off-by: Matt Coster
---
Changes in v2:
- Use normal reg syntax for 64-bit values
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-8-4ed30e865...@imgtec.com
rences for indices: clocks[1], interrupts[2], power[3].
[1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel
[2]: https://downloads.ti.com/tisci/esd/latest/5_soc_doc/j721s2/clocks.html
[3]: https://downloads.ti.com/tisci/esd/latest/5_soc_doc/j721s2/devices.html
Signed-off-by: M
This allows for more versatility in checking and clearing firmware
registers used for interrupt handling.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-14-4ed30e865...@imgtec.com
---
drivers/gpu/drm/imagination
different GPU power
topologies.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-6-4ed30e865...@imgtec.com
---
drivers/gpu/drm/imagination/pvr_device.h | 8 +++
drivers/gpu/drm/imagination/pvr_drv.c| 10 +
With more than two firmware processor types, the if/else chain in
pvr_fw_init() gets a bit ridiculous. Use a static array indexed on
pvr_fw_processor_type (which is now a proper enum instead of #defines)
instead.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https
- Simplified clocks constraints (P2)
- Simplified power-domains constraints (P3/P4)
- Use normal reg syntax for 64-bit values (P8/P21)
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-0-4ed30e865...@imgtec.com
---
Matt Coster (20):
dt-bindings: gpu: img: More
Add the new compatible string recently introduced in the dt bindings
("img,img-bxs-4-64") to the dt_match table and link the appropriate
firmware.
Signed-off-by: Matt Coster
---
Changes in v2:
- None
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-patch-v1-v1-20
.
Codify this "1 or 3" constraint in our bindings and hang the specifics off
the vendor compatible string to mirror the integration-time choice.
Signed-off-by: Matt Coster
---
Changes in v2:
- Simplified clocks constraints (P2)
- Link to v1:
https://lore.kernel.org/r/20241105-sets-bxs-4-64-pat
a very small amount of time and
would make this codepath more versatile to future reset controllers.
Cheers,
Matt
>
> + err = reset_control_deassert(pvr_dev->reset);
> + if (err)
> + goto err_mem_clk_disable;
> +
> if (pvr_dev->fw_dev.bo
1520-aon.h | 197 +
> 28 files changed, 1344 insertions(+), 37 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml
> create mode 100644
> Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml
> create mode 100644 drivers/firmware/thead,th1520-aon.c
> create mode 100644 drivers/pmdomain/thead/Kconfig
> create mode 100644 drivers/pmdomain/thead/Makefile
> create mode 100644 drivers/pmdomain/thead/th1520-pm-domains.c
> create mode 100644 drivers/reset/reset-th1520.c
> create mode 100644 include/dt-bindings/power/thead,th1520-power.h
> create mode 100644 include/dt-bindings/reset/thead,th1520-reset.h
> create mode 100644 include/linux/firmware/thead/thead,th1520-aon.h
>
--
Matt Coster
E: matt.cos...@imgtec.com
OpenPGP_signature.asc
Description: OpenPGP digital signature
> cg->common.hw.init->name,
> @@ -1057,19 +1191,21 @@ static int th1520_clk_probe(struct platform_device
> *pdev)
> priv->hws[cg->common.clkid] = hw;
> }
>
> - ret = devm_clk_hw_register(dev, &osc12m_clk.hw);
> - if (ret)
> - return ret;
> - priv->hws[CLK_OSC12M] = &osc12m_clk.hw;
> + if (plat_data == &th1520_ap_platdata) {
> + ret = devm_clk_hw_register(dev, &osc12m_clk.hw);
> + if (ret)
> + return ret;
> + priv->hws[CLK_OSC12M] = &osc12m_clk.hw;
>
> - ret = devm_clk_hw_register(dev, &gmac_pll_clk_100m.hw);
> - if (ret)
> - return ret;
> - priv->hws[CLK_PLL_GMAC_100M] = &gmac_pll_clk_100m.hw;
> + ret = devm_clk_hw_register(dev, &gmac_pll_clk_100m.hw);
> + if (ret)
> + return ret;
> + priv->hws[CLK_PLL_GMAC_100M] = &gmac_pll_clk_100m.hw;
>
> - ret = devm_clk_hw_register(dev, &emmc_sdio_ref_clk.hw);
> - if (ret)
> - return ret;
> + ret = devm_clk_hw_register(dev, &emmc_sdio_ref_clk.hw);
> + if (ret)
> + return ret;
> + }
>
> ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, priv);
> if (ret)
> @@ -1081,6 +1217,11 @@ static int th1520_clk_probe(struct platform_device
> *pdev)
> static const struct of_device_id th1520_clk_match[] = {
> {
> .compatible = "thead,th1520-clk-ap",
> + .data = &th1520_ap_platdata,
> + },
> + {
> + .compatible = "thead,th1520-clk-vo",
> + .data = &th1520_vo_platdata,
> },
> { /* sentinel */ },
> };
--
Matt Coster
E: matt.cos...@imgtec.com
OpenPGP_signature.asc
Description: OpenPGP digital signature
LEVEL_HIGH>;
> + clocks = <&clk CLK_GPU_CORE>, <&clk CLK_GPU_CFG_ACLK>;
> +clock-names = "core", "mem";
You have CFG mapped to "mem" here. Out of curiosity, was that mismatch
required to make things work?
Cheers,
Matt
> +power-domains = <&pd TH1520_GPU_PD>;
> +resets = <&rst TH1520_RESET_ID_GPU>;
> +};
--
Matt Coster
E: matt.cos...@imgtec.com
OpenPGP_signature.asc
Description: OpenPGP digital signature
return PTR_ERR(priv->map);
> +
> + mutex_init(&priv->gpu_seq_lock);
> +
> + priv->rcdev.owner = THIS_MODULE;
> + priv->rcdev.nr_resets = 1;
> + priv->rcdev.ops = &th1520_reset_ops;
> + priv->rcdev.of_node = dev->of_node;
> + priv
her B-Series series mentioned
on the cover letter; we'd like to switch to matching against the more
generic "img,img-rogue" so this would be unnecessary.
However, you do need to add a MODULE_FIRMWARE() tag at the bottom of
this file either way.
Cheers,
Matt
> {}
>
252f8087..bb607d4b1e07 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> @@ -37,6 +37,9 @@ properties:
>power-domains:
> maxItems: 1
>
> + resets:
> +maxItems: 1
&g
> That was for the PowerVR driver, and it doesn't seem it's been hooked
> up there. I don't think we'll ever need it in panthor, so
Looks good to us, thanks for checking!
Acked-by: Matt Coster
--
Matt Coster
E: matt.cos...@imgtec.com
> Acked-by: Boris Brezillon
> Cc: Christian König
>> Cc: Danilo Krummrich
>> Cc: Matthew Brost
>> Cc: Philipp Stanner
>> Cc: Frank Binns
>> Cc: Matt Coster
>> Reviewed-by: Matt Coster
>
> Matt, just to be sure, you're OK with me pulling those two into drm-
> m
> Cc: Philipp Stanner
Reviewed-by: Matt Coster
--
Matt Coster
E: matt.cos...@imgtec.com
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 23 +++
> include/drm/gpu_scheduler.h| 3 ++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
&
ipp Stanner
> Cc: Frank Binns
> Cc: Matt Coster
Reviewed-by: Matt Coster
--
Matt Coster
E: matt.cos...@imgtec.com
> ---
> drivers/gpu/drm/imagination/pvr_job.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/d
_kmalloc_large_node_noprof+0x2c/0x13c
> __kmalloc_noprof+0x48/0x4c0
> pvr_fw_init+0xb0c/0x1f50 [powervr]
>
> Cc: sta...@vger.kernel.org
> Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and
> META FW support")
> Signed-off-by: Brendan
-after-free in
> pvr_queue_prepare_job+0x108/0x868 [powervr]
> [ 124.264893] Read of size 1 at addr 084cb960 by task
> kworker/u16:4/63
>
> Cc: sta...@vger.kernel.org
> Fixes: eaf01ee5ba28 ("drm/imagination: Implement job submission and
> scheduling")
> Si
from it e.g. via pvr_power_reset().
Note that Rogue GPUs may send interrupts to the host for all types of
safety events, not just the two above. For events not handled by the host,
clearing the associated interrupt is sufficient.
Signed-off-by: Alessio Belle
Signed-off-by: Matt Coster
---
Changes
Currently only MIPS firmware processors use ELF-formatted firmware. When
adding support for RISC-V firmware processors, it will be useful to have
ELF handling functions ready to go.
Signed-off-by: Matt Coster
---
Changes in v4:
- None
- Link to v3:
https://lore.kernel.org/r/20250310-sets-bxs-4
1 - 100 of 216 matches
Mail list logo
