for (chip_info = it66xx_chip_info; chip_info->vid; chip_info++) {
Relying on a null entry bugs me, here you could just use
the length of the table and remove the null entry:
for (i = 0; i < ARRAY_SIZE(it66xx_chip_info); i++) {
chip_info = &it66xx_chip_info[i];
...
Eit
On 8/15/25 4:41 AM, Christian König wrote:
On 14.08.25 18:10, Andrew Davis wrote:
Hello all,
This series makes it so the udmabuf will sync the backing buffer
with the set of attached devices as required for DMA-BUFs when
doing {begin,end}_cpu_access.
Yeah the reason why we didn't do th
suggested by Devarsh to allow for future
expansion of functionality.
NOTE: I did consider the possibility of converting the chip_id into a
bitfield, but decided it is over-engineering, so kept the enum.
But over-engineering is so much more fun :D
Reviewed-by: Andrew Davis
[2] https://github.com
ompatible = "ite,it66121", &it66xx_chip_info },
+ { .compatible = "ite,it6610", &it66xx_chip_info },
If you will pass in the same data to all devices, just don't pass
anything. Move the it66121_dt_match table up above probe, and just
use it, no need for fetching it
ing ftrace
+ dev_dbg(dev, "%s\n", __func__);
WARNING: Unnecessary ftrace-like logging - prefer using ftrace
+ dev_dbg(dev, "%s\n", __func__);
Signed-off-by: Nishanth Menon
---
Reviewed-by: Andrew Davis
Changes in V3:
* New patch
drivers/gpu/drm/bridge/ite-it66121.c
nd all this and perform the correct action by doing the dma_sync
operations for each device currently attached to the backing buffer.
[0] commit 1ffe09590121 ("udmabuf: fix dma-buf cpu access")
[1] commit 9e9fa6a9198b ("udmabuf: Set the DMA mask for the udmabuf device
(v2)&qu
When a device attaches to and maps our buffer we need to keep track
of this mapping/device. This is needed for synchronization with these
devices when beginning and ending CPU access for instance. Add a list
that tracks device mappings as part of {map,unmap}_udmabuf().
Signed-off-by: Andrew Davis
Hello all,
This series makes it so the udmabuf will sync the backing buffer
with the set of attached devices as required for DMA-BUFs when
doing {begin,end}_cpu_access.
Thanks
Andrew
Changes for v2:
- fix attachment table use-after-free
- rebased on v6.17-rc1
Andrew Davis (3):
udmabuf
Now that we do not need to call dma_coerce_mask_and_coherent() on our
miscdevice device, use the module_misc_device() helper for registering
and module init/exit.
While here, add module description and license, modules built with W=1
warn if built without these.
Signed-off-by: Andrew Davis
list
Best of both, looks good to me,
Reviewed-by: Andrew Davis
V1: https://lore.kernel.org/all/20250813190835.344563-1...@ti.com/
Nishanth Menon (3):
dt-bindings: display: bridge: it66121: Add compatible string for
IT66122
drm/bridge: it66121: Convert the vid/pid entries into a
On 8/13/25 2:08 PM, Nishanth Menon wrote:
Hi,
Add support for IT66122, which for all practical purposes is
drop in replacement for IT66121 except for the ID register
definition.
BeagleY-AI uses this new part as the old part is no longer in production
as far as I understand.
Now, BeaglePlay use
memory@4200-cacheable-contiguous`` or ``video@4200``, but
You dropped "cacheable" but left it here in the suggested names, maybe
replace with "protected" here. Otherwise, LGTM,
Reviewed-by: Andrew Davis
+``cma-video`` wouldn't.
---
base-commit: 19272b37aa
On 7/16/25 8:47 AM, Michael Walle wrote:
The AM62P and the J722S features the same BXS-4 GPU as the J721S2. Add a
new SoC specific compatible.
If the GPU is the same, and the integration is the same, do you really need
a new compatible?
Signed-off-by: Michael Walle
---
Documentation/devic
On 6/6/25 1:28 AM, Tomeu Vizoso wrote:
This uses the SHMEM DRM helpers and we map right away to the CPU and NPU
sides, as all buffers are expected to be accessed from both.
v2:
- Sync the IOMMUs for the other cores when mapping and unmapping.
v3:
- Make use of GPL-2.0-only for the copyright not
On 6/6/25 1:28 AM, Tomeu Vizoso wrote:
This initial version supports the NPU as shipped in the RK3588 SoC and
described in the first part of its TRM, in Chapter 36.
This NPU contains 3 independent cores that the driver can submit jobs
to.
This commit adds just hardware initialization and power
On 7/10/25 2:44 AM, Maxime Ripard wrote:
On Wed, Jul 09, 2025 at 11:14:37AM -0500, Andrew Davis wrote:
On 7/9/25 7:44 AM, Maxime Ripard wrote:
Aside from the main CMA region, it can be useful to allow userspace to
allocate from the other CMA reserved regions.
Indeed, those regions can have
On 7/10/25 2:06 AM, Maxime Ripard wrote:
On Wed, Jul 09, 2025 at 12:39:15PM -0500, Andrew Davis wrote:
On 6/16/25 10:21 AM, Maxime Ripard wrote:
We've discussed a number of times of how some heap names are bad, but
not really what makes a good heap name.
Let's document what we expec
On 6/16/25 10:21 AM, Maxime Ripard wrote:
We've discussed a number of times of how some heap names are bad, but
not really what makes a good heap name.
Let's document what we expect the heap names to look like.
Reviewed-by: Bagas Sanjaya
Signed-off-by: Maxime Ripard
---
Changes in v2:
- Added
On 7/9/25 7:44 AM, Maxime Ripard wrote:
Aside from the main CMA region, it can be useful to allow userspace to
allocate from the other CMA reserved regions.
Indeed, those regions can have specific properties that can be useful to
a specific us-case.
For example, one of them platform I've been w
On 7/9/25 7:44 AM, Maxime Ripard wrote:
A given reserved-memory region can be of multiple types.
We have currently four types defined in the tree: contiguous, backed by
CMA, coherent and swiotlb, backed by their respective allocators, and a
platform-specific one for tegra.
However, some users,
On 5/27/25 1:56 AM, Amirreza Zarrabi wrote:
For drivers that can transfer data to the TEE without using shared
memory from client, it is necessary to receive the user address
directly, bypassing any processing by the TEE subsystem. Introduce
TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT/OUTPUT/INOUT to re
On 4/14/25 2:21 PM, Thomas Petazzoni wrote:
Hello Andrew,
On Mon, 14 Apr 2025 12:08:44 -0500
Andrew Davis wrote:
"UIO is a broken legacy mess, so let's add more broken things
to it as broken + broken => still broken, so no harm done", am I
getting that right?
Who say
On 4/14/25 6:48 AM, Thomas Petazzoni wrote:
Hello Christoph,
On Mon, 14 Apr 2025 04:24:21 -0700
Christoph Hellwig wrote:
On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote:
What this patch series is about is to add new user-space interface to
extend the existing UIO subsystem.
On 4/11/25 3:26 PM, T.J. Mercier wrote:
On Mon, Apr 7, 2025 at 9:29 AM Maxime Ripard wrote:
Some reserved memory regions might have particular memory setup or
attributes that make them good candidates for heaps.
Let's provide a heap type that will create a new heap for each reserved
memory re
On 12/18/24 8:45 AM, Sverdlin, Alexander wrote:
Hi Andrew!
On Tue, 2024-12-17 at 09:56 -0600, Andrew Davis wrote:
+static int lp8864_fault_check(struct lp8864_led *led)
+{
+ int ret, i;
+ unsigned int val;
+
+ ret = regmap_read(led->regmap, LP8864_SUPPLY_STATUS, &
On 12/17/24 7:37 AM, A. Sverdlin wrote:
From: Alexander Sverdlin
Add driver for TI LP8864, LP8864S, LP8866 4/6 channel LED-backlight drivers
with I2C interface.
Link: https://www.ti.com/lit/gpn/lp8864-q1
Link: https://www.ti.com/lit/gpn/lp8864s-q1
Link: https://www.ti.com/lit/gpn/lp8866-q1
Lin
,
Reviewed-by: Andrew Davis
v2: no changes
MAINTAINERS| 7 +
drivers/leds/Kconfig | 12 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-lp8864.c | 308 +
4 files changed, 328 insertions(+)
create mode 100644 drivers/leds/leds
On 12/6/24 3:24 PM, A. Sverdlin wrote:
From: Alexander Sverdlin
Add driver for TI LP8864, LP8864S, LP8866 4/6 channel LED-backlight drivers
with I2C interface.
Link: https://www.ti.com/lit/gpn/lp8864-q1
Link: https://www.ti.com/lit/gpn/lp8864s-q1
Link: https://www.ti.com/lit/gpn/lp8866-q1
Link
On 12/6/24 12:20 PM, Sverdlin, Alexander wrote:
Hi Andrew,
On Fri, 2024-12-06 at 12:02 -0600, Andrew Davis wrote:
On 12/6/24 11:46 AM, Sverdlin, Alexander wrote:
Hi Andrew,
On Fri, 2024-12-06 at 11:43 -0600, Andrew Davis wrote:
Are you sure this is a correct thing to do? The lp8860-q1
On 12/6/24 11:46 AM, Sverdlin, Alexander wrote:
Hi Andrew,
On Fri, 2024-12-06 at 11:43 -0600, Andrew Davis wrote:
Are you sure this is a correct thing to do? The lp8860-q1 product link
cites it as being a 4-channel device. Even if the kernel only ever
supports it as a single-channel device
ma: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments - LP886x 4/6-Channel LED Driver family
+
+maintainers:
+ - Andrew Davis
+ - Alexander Sverdlin
+
+description: |
+ The LP8860-Q1 is an high-efficiency LED driver with boost controller.
+ It has 4 high-precision
On 12/3/24 1:44 AM, Maxime Ripard wrote:
Hi John,
On Mon, Dec 02, 2024 at 11:12:23AM -0800, John Stultz wrote:
On Mon, Dec 2, 2024 at 3:58 AM Maxime Ripard wrote:
Following a recent discussion at last Plumbers, John Stultz, Sumit
Sewal, TJ Mercier and I came to an agreement that we should do
On 11/18/24 7:02 AM, Matt Coster wrote:
The TI k3-j721s2 platform has a bug relating to cache snooping on the AXI
Well we don't really know it is the bug on our side until we root cause it..
Anyway, why do need such a complex work around here? GEM buffer objects
only need to be coherent, cache
On 11/6/24 12:30 PM, Conor Dooley wrote:
On Wed, Nov 06, 2024 at 10:18:06AM +, Matt Coster wrote:
On 05/11/2024 18:06, Conor Dooley wrote:
On Tue, Nov 05, 2024 at 03:58:10PM +, Matt Coster wrote:
This attribute will be required for the BXS-4-64 MC1 and will be enabled in
the DTS for th
On 9/25/24 3:51 AM, Christian König wrote:
Am 25.09.24 um 01:05 schrieb Dmitry Baryshkov:
On Tue, Sep 24, 2024 at 01:13:18PM GMT, Andrew Davis wrote:
On 9/23/24 1:33 AM, Dmitry Baryshkov wrote:
Hi,
On Fri, Aug 30, 2024 at 09:03:47AM GMT, Jens Wiklander wrote:
Hi,
This patch set is based on
On 9/23/24 1:33 AM, Dmitry Baryshkov wrote:
Hi,
On Fri, Aug 30, 2024 at 09:03:47AM GMT, Jens Wiklander wrote:
Hi,
This patch set is based on top of Yong Wu's restricted heap patch set [1].
It's also a continuation on Olivier's Add dma-buf secure-heap patch set [2].
The Linaro restricted heap
On 4/9/24 7:06 AM, Pascal FONTAIN wrote:
From: Andrew Davis
This new export type exposes to userspace the SRAM area as a DMA-BUF
Heap,
this allows for allocations of DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew Davis
Tested-by: Pascal Fontain
On 3/10/24 7:48 AM, Paul Cercueil wrote:
Add the necessary infrastructure to the IIO core to support a new
optional DMABUF based interface.
With this new interface, DMABUF objects (externally created) can be
attached to a IIO buffer, and subsequently used for data transfer.
A userspace applicat
mabuf: Set the DMA mask for the udmabuf
device (v2)")
Signed-off-by: Andrew Davis
---
drivers/dma-buf/udmabuf.c | 41 +++
1 file changed, 16 insertions(+), 25 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 3a
On 1/25/24 2:30 PM, Daniel Vetter wrote:
On Tue, Jan 23, 2024 at 04:12:26PM -0600, Andrew Davis wrote:
Currently this driver creates a SGT table using the CPU as the
target device, then performs the dma_sync operations against
that SGT. This is backwards to how DMA-BUFs are supposed to behave
fa6a9198b ("udmabuf: Set the DMA mask for the udmabuf
device (v2)")
Signed-off-by: Andrew Davis
---
drivers/dma-buf/udmabuf.c | 41 +++
1 file changed, 16 insertions(+), 25 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
part of {map,unmap}_udmabuf().
Signed-off-by: Andrew Davis
---
drivers/dma-buf/udmabuf.c | 43
+--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index c406459996489..3a23f0a7d112a 100644
On 1/24/24 4:58 AM, Paul Cercueil wrote:
Hi Christian,
Le mardi 23 janvier 2024 à 14:28 +0100, Christian König a écrit :
Am 23.01.24 um 14:02 schrieb Paul Cercueil:
[SNIP]
That an exporter has to call extra functions to access his
own
buffers
is a complete no-go for the desi
nd all this and perform the correct action by doing the dma_sync
operations for each device currently attached to the backing buffer.
[0] commit 1ffe09590121 ("udmabuf: fix dma-buf cpu access")
[1] commit 9e9fa6a9198b ("udmabuf: Set the DMA mask for the udmabuf device
(v2)&qu
Now that we do not need to call dma_coerce_mask_and_coherent() on our
miscdevice device, use the module_misc_device() helper for registering
and module init/exit.
Signed-off-by: Andrew Davis
---
drivers/dma-buf/udmabuf.c | 30 +-
1 file changed, 1 insertion(+), 29
When a device attaches to and maps our buffer we need to keep track
of this mapping/device. This is needed for synchronization with these
devices when beginning and ending CPU access for instance. Add a list
that tracks device mappings as part of {map,unmap}_udmabuf().
Signed-off-by: Andrew Davis
On 1/10/24 2:29 AM, Tony Lindgren wrote:
* Andrew Davis [240109 17:20]:
--- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
@@ -850,12 +850,19 @@ target-module@5600 {
;
ti,sysc-sidle
On 1/11/24 3:20 AM, Paul Cercueil wrote:
Hi Andrew,
Le lundi 08 janvier 2024 à 15:12 -0600, Andrew Davis a écrit :
On 12/19/23 11:50 AM, Paul Cercueil wrote:
[V4 was: "iio: Add buffer write() support"][1]
Hi Jonathan,
This is a respin of the V3 of my patchset that introduced a new
On 1/9/24 1:17 PM, Krzysztof Kozlowski wrote:
On 09/01/2024 20:04, Andrew Davis wrote:
On 1/9/24 12:59 PM, Krzysztof Kozlowski wrote:
On 09/01/2024 18:19, Andrew Davis wrote:
This binding will be used for GPUs starting from Series6 (Rogue)
and later. A different binding document will describe
On 1/9/24 12:59 PM, Krzysztof Kozlowski wrote:
On 09/01/2024 18:19, Andrew Davis wrote:
This binding will be used for GPUs starting from Series6 (Rogue)
and later. A different binding document will describe Series5.
With that the name "img,powervr" is too generic, rename to
"im
The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors. Describe how the SGX GPU is integrated in these SoC,
including register space and interrupts. Clocks, reset, and power domain
information is SoC specific.
Signed-off-by: Andrew Davis
Reviewed-
Add SGX GPU device entry to base jz4780 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic
Add SGX GPU device entry to base AM654 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65
name Rogue+ binding to img,powervr-rogue.yaml
- Locked all property item counts
- Removed nodename pattern check
Andrew Davis (11):
dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
ARM: dts: omap3: Add device tree entry for SGX GPU
ARM:
This binding will be used for GPUs starting from Series6 (Rogue)
and later. A different binding document will describe Series5.
With that the name "img,powervr" is too generic, rename to
"img,powervr-rogue" to avoid confusion.
Suggested-by: Maxime Ripard
Signed-off-by: Andre
Add SGX GPU device entry to base OMAP5 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/omap5.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap5.dtsi
b/arch/arm/boot/dts/ti
Add SGX GPU device entry to base DRA7x dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/dra7.dtsi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ti/omap/dra7.dtsi
b/arch/arm/boot/dts/ti
Add SGX GPU device entry to base OMAP4 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi
b/arch/arm/boot/dts/ti
Add SGX GPU device entry to base sun6i-a31 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/allwinner/sun6i-a31.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
b/arch/arm/boot/dts
Add SGX GPU device entries to base OMAP3 dtsi files.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/am3517.dtsi | 11 ++-
arch/arm/boot/dts/ti/omap/omap34xx.dtsi | 11 ++-
arch/arm/boot/dts/ti/omap/omap36xx.dtsi | 9
Add SGX GPU device entry to base AM33xx dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/am33xx.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
b/arch/arm/boot/dts
Add SGX GPU device entry to base AM437x dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/am4372.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/am4372.dtsi
b/arch/arm/boot/dts/ti/omap/am4372
On 1/9/24 5:32 AM, Krzysztof Kozlowski wrote:
On 08/01/2024 19:32, Andrew Davis wrote:
The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors. Describe how the SGX GPU is integrated in these SoC,
including register space and interrupts. Clocks, reset,
On 1/9/24 5:28 AM, Krzysztof Kozlowski wrote:
On 08/01/2024 19:32, Andrew Davis wrote:
Signed-off-by: Andrew Davis
---
.../bindings/gpu/{img,powervr.yaml => img,powervr-rogue.yaml} | 4 ++--
MAINTAINERS | 2 +-
2 files changed, 3 inserti
On 12/19/23 11:50 AM, Paul Cercueil wrote:
[V4 was: "iio: Add buffer write() support"][1]
Hi Jonathan,
This is a respin of the V3 of my patchset that introduced a new
interface based on DMABUF objects [2].
The V4 was a split of the patchset, to attempt to upstream buffer
write() support first.
Add SGX GPU device entries to base OMAP3 dtsi files.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/am3517.dtsi | 11 ++-
arch/arm/boot/dts/ti/omap/omap34xx.dtsi | 11 ++-
arch/arm/boot/dts/ti/omap/omap36xx.dtsi | 9 +
3 files changed, 17 insertions(+), 14
,powervr-rogue.yaml
- Locked all property item counts
- Removed nodename pattern check
Andrew Davis (11):
dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
ARM: dts: omap3: Add device tree entry for SGX GPU
ARM: dts: omap4: Add device
Add SGX GPU device entry to base OMAP4 dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi
b/arch/arm/boot/dts/ti/omap/omap4.dtsi
index 2bbff9032be3e
Add SGX GPU device entry to base jz4780 dtsi file.
Signed-off-by: Andrew Davis
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 18a85ce38
Add SGX GPU device entry to base DRA7x dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/dra7.dtsi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ti/omap/dra7.dtsi
b/arch/arm/boot/dts/ti/omap/dra7.dtsi
index 6509c742fb58c
Add SGX GPU device entry to base AM33xx dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/am33xx.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
index
Add SGX GPU device entry to base AM654 dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index fcea544656360
Add SGX GPU device entry to base sun6i-a31 dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/allwinner/sun6i-a31.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
index
Signed-off-by: Andrew Davis
---
.../bindings/gpu/{img,powervr.yaml => img,powervr-rogue.yaml} | 4 ++--
MAINTAINERS | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
rename Documentation/devicetree/bindings/gpu/{img,powervr.yaml =>
The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors. Describe how the SGX GPU is integrated in these SoC,
including register space and interrupts. Clocks, reset, and power domain
information is SoC specific.
Signed-off-by: Andrew Davis
---
.../bi
Add SGX GPU device entry to base OMAP5 dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/omap5.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap5.dtsi
b/arch/arm/boot/dts/ti/omap/omap5.dtsi
index bac6fa8387936
Add SGX GPU device entry to base AM437x dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/am4372.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/am4372.dtsi
b/arch/arm/boot/dts/ti/omap/am4372.dtsi
index 9d2c064534f7d..5fd1b380ece62
On 12/18/23 4:54 AM, H. Nikolaus Schaller wrote:
Am 18.12.2023 um 11:14 schrieb Maxime Ripard :
On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
Hi Maxime,
Am 15.12.2023 um 14:33 schrieb Maxime Ripard :
It's for a separate architecture, with a separate driver, maint
On 12/6/23 10:02 AM, Conor Dooley wrote:
On Tue, Dec 05, 2023 at 07:04:05PM +0100, H. Nikolaus Schaller wrote:
Am 05.12.2023 um 18:33 schrieb Andrew Davis :
On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
+ - enum:
+ - ti,omap3430-gpu # Rev 121
+ - ti
On 12/5/23 2:17 AM, H. Nikolaus Schaller wrote:
Hi Andrew,
Am 04.12.2023 um 19:22 schrieb Andrew Davis :
The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors.
Great and thanks for the new attempt to get at least the Device Tree side
upstre
Add SGX GPU device entries to base OMAP3 dtsi files.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/am3517.dtsi | 11 ++-
arch/arm/boot/dts/ti/omap/omap34xx.dtsi | 11 ++-
arch/arm/boot/dts/ti/omap/omap36xx.dtsi | 9 +
3 files changed, 17 insertions(+), 14
Add SGX GPU device entry to base sun6i-a31 dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/allwinner/sun6i-a31.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
index
Add SGX GPU device entry to base OMAP4 dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi
b/arch/arm/boot/dts/ti/omap/omap4.dtsi
index 2bbff9032be3e
Add SGX GPU device entry to base jz4780 dtsi file.
Signed-off-by: Andrew Davis
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 18a85ce38
Add SGX GPU device entry to base AM437x dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/am4372.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/am4372.dtsi
b/arch/arm/boot/dts/ti/omap/am4372.dtsi
index 9d2c064534f7d..5fd1b380ece62
Add SGX GPU device entry to base OMAP5 dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/omap5.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap5.dtsi
b/arch/arm/boot/dts/ti/omap/omap5.dtsi
index bac6fa8387936
Add SGX GPU device entry to base AM654 dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 29048d6577cf6
Add SGX GPU device entry to base AM33xx dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/am33xx.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
index
The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors. Describe how the SGX GPU is integrated in these SoC,
including register space and interrupts. Clocks, reset, and power domain
information is SoC specific.
Signed-off-by: Andrew Davis
---
.../
Add SGX GPU device entry to base DRA7x dtsi file.
Signed-off-by: Andrew Davis
---
arch/arm/boot/dts/ti/omap/dra7.dtsi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ti/omap/dra7.dtsi
b/arch/arm/boot/dts/ti/omap/dra7.dtsi
index 6509c742fb58c
for Series6+, but otherwise most
is the same as we have been using in our vendor tree for many years.
Thanks,
Andrew
Based on next-20231204.
[0]: https://lkml.org/lkml/2020/4/24/1222
[1]: https://github.com/openpvrsgx-devgroup
Andrew Davis (10):
dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
While a scatter-gather table having only 1 entry does imply it is
contiguous, it is a logic error to assume the inverse. Tables can have
more than 1 entry and still be contiguous. Use a proper check here.
Signed-off-by: Andrew Davis
---
Changes from v2:
- Double check that these multi-segment
On 9/22/23 12:57 PM, Adam Jackson wrote:
On Wed, Sep 6, 2023 at 5:57 AM Sarah Walker mailto:sarah.wal...@imgtec.com>> wrote:
+ * :BYPASS_CACHE: There are very few situations where this flag is
useful.
Could you also expand on what these few useful situations are?
Andrew
+ *
On 7/13/23 2:27 PM, Greg Kroah-Hartman wrote:
On Thu, Jul 13, 2023 at 02:13:16PM -0500, Andrew Davis wrote:
+int sram_add_dma_heap(struct sram_dev *sram,
+ struct sram_reserve *block,
+ phys_addr_t start,
+ struct sram_partition *part
This new export type exposes to userspace the SRAM area as a DMA-BUF Heap,
this allows for allocations of DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew Davis
---
Changes from v2:
- Make sram_dma_heap_allocate static (kernel test robot)
- Rebase on
On 6/13/23 9:47 AM, Sarah Walker wrote:
Acquire clock, regulator and register resources, and enable/map as
appropriate.
Signed-off-by: Sarah Walker
---
drivers/gpu/drm/imagination/Makefile | 1 +
drivers/gpu/drm/imagination/pvr_device.c | 271 +++
drivers/gpu/drm/i
On 6/13/23 9:47 AM, Sarah Walker wrote:
Add the device tree binding documentation for the Series AXE GPU used in
TI AM62 SoCs.
Signed-off-by: Sarah Walker
---
.../devicetree/bindings/gpu/img,powervr.yaml | 71 +++
MAINTAINERS | 7 ++
2 fil
On 4/14/23 12:44 AM, Christian Gmeiner wrote:
Hi Andrew
Am Di., 4. Apr. 2023 um 17:02 Uhr schrieb Christian Gmeiner
:
Hi Andrew
Okay, will split for v2.
Was there a follow-up v2 of this patchset? AFAICT this series did not
make it into the mainline kernel.
Do you have any plans to wor
On 4/1/23 3:35 AM, Christian Gmeiner wrote:
Hi Andrew
Okay, will split for v2.
Was there a follow-up v2 of this patchset? AFAICT this series did not
make it into the mainline kernel.
Do you have any plans to work on it? If not I would like to help out
as we have a use case where we want t
This new export type exposes to userspace the SRAM area as a DMA-BUF Heap,
this allows for allocations of DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
Signed-off-by: Andrew Davis
---
Changes from v1:
- Use existing DT flags, if both pool(device usable) and export
1 - 100 of 119 matches
Mail list logo
