* Re: [PATCH] virtio_ring: Fix the stale index in available ring
From: Gavin Shan @ 2024-03-20 5:24 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Will Deacon, virtualization, linux-kernel, jasowang, xuanzhuo,
yihyu, shan.gavin, linux-arm-kernel, Catalin Marinas, mochs
In-Reply-To: <20240319203540-mutt-send-email-mst@kernel.org>
On 3/20/24 10:49, Michael S. Tsirkin wrote:>
> I think you are wasting the time with these tests. Even if it helps what
> does this tell us? Try setting a flag as I suggested elsewhere.
> Then check it in vhost.
> Or here's another idea - possibly easier. Copy the high bits from index
> into ring itself. Then vhost can check that head is synchronized with
> index.
>
> Warning: completely untested, not even compiled. But should give you
> the idea. If this works btw we should consider making this official in
> the spec.
>
>
> static inline int vhost_get_avail_flags(struct vhost_virtqueue *vq,
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 6f7e5010a673..79456706d0bd 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -685,7 +685,8 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
> /* Put entry in available array (but don't update avail->idx until they
> * do sync). */
> avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1);
> - vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head);
> + u16 headwithflag = head | (q->split.avail_idx_shadow & ~(vq->split.vring.num - 1));
> + vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, headwithflag);
>
> /* Descriptors and available array need to be set before we expose the
> * new available array entries. */
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 045f666b4f12..bd8f7c763caa 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1299,8 +1299,15 @@ static inline int vhost_get_avail_idx(struct vhost_virtqueue *vq,
> static inline int vhost_get_avail_head(struct vhost_virtqueue *vq,
> __virtio16 *head, int idx)
> {
> - return vhost_get_avail(vq, *head,
> + unsigned i = idx;
> + unsigned flag = i & ~(vq->num - 1);
> + unsigned val = vhost_get_avail(vq, *head,
> &vq->avail->ring[idx & (vq->num - 1)]);
> + unsigned valflag = val & ~(vq->num - 1);
> +
> + WARN_ON(valflag != flag);
> +
> + return val & (vq->num - 1);
> }
>
Thanks, Michael. The code is already self-explanatory. Since vq->num is 256, I just
squeezed the last_avail_idx to the high byte. Unfortunately, I'm unable to hit
the WARN_ON(). Does it mean the low byte is stale (or corrupted) while the high
byte is still correct and valid?
avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1);
vq->split.vring.avail->ring[avail] =
cpu_to_virtio16(_vq->vdev, head | (avail << 8));
head = vhost16_to_cpu(vq, ring_head);
WARN_ON((head >> 8) != (vq->last_avail_idx % vq->num));
head = head & 0xff;
One question: Does QEMU has any chance writing data to the available queue when
vhost is enabled? My previous understanding is no, the queue is totally owned by
vhost instead of QEMU.
Before this patch was posted, I had debugging code to record last 16 transactions
to the available and used queue from guest and host side. It did reveal the wrong
head was fetched from the available queue.
[ 11.785745] ================ virtqueue_get_buf_ctx_split ================
[ 11.786238] virtio_net virtio0: output.0:id 74 is not a head!
[ 11.786655] head to be released: 036 077
[ 11.786952]
[ 11.786952] avail_idx:
[ 11.787234] 000 63985 <--
[ 11.787237] 001 63986
[ 11.787444] 002 63987
[ 11.787632] 003 63988
[ 11.787821] 004 63989
[ 11.788006] 005 63990
[ 11.788194] 006 63991
[ 11.788381] 007 63992
[ 11.788567] 008 63993
[ 11.788772] 009 63994
[ 11.788957] 010 63995
[ 11.789141] 011 63996
[ 11.789327] 012 63997
[ 11.789515] 013 63998
[ 11.789701] 014 63999
[ 11.789886] 015 64000
[ 11.790068]
[ 11.790068] avail_head:
[ 11.790529] 000 075 <--
[ 11.790718] 001 036
[ 11.790890] 002 077
[ 11.791061] 003 129
[ 11.791231] 004 072
[ 11.791400] 005 130
[ 11.791574] 006 015
[ 11.791748] 007 074
[ 11.791918] 008 130
[ 11.792094] 009 130
[ 11.792263] 010 074
[ 11.792437] 011 015
[ 11.792617] 012 072
[ 11.792788] 013 129
[ 11.792961] 014 077 // The last two heads from guest to host: 077, 036
[ 11.793134] 015 036
[root@nvidia-grace-hopper-05 qemu.main]# cat /proc/vhost
avail_idx
000 63998
001 64000
002 63954 <---
003 63955
004 63956
005 63974
006 63981
007 63984
008 63986
009 63987
010 63988
011 63989
012 63992
013 63993
014 63995
015 63997
avail_head
000 074
001 015
002 072
003 129
004 074 // The last two heads seen by vhost is: 074, 036
005 036
006 075 <---
007 036
008 077
009 129
010 072
011 130
012 015
013 074
014 130
015 130
used_idx
000 64000
001 63882 <---
002 63889
003 63891
004 63898
005 63936
006 63942
007 63946
008 63949
009 63953
010 63957
011 63981
012 63990
013 63992
014 63993
015 63999
used_head
000 072
001 129
002 074 // The last two heads published to guest is: 074, 036
003 036
004 075 <---
005 036
006 077
007 129
008 072
009 130
010 015
011 074
012 130
013 130
014 074
015 015
Thanks,
Gavin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/8] drm: xlnx: Fix kerneldoc
From: Tomi Valkeinen @ 2024-03-20 5:42 UTC (permalink / raw)
To: Sean Anderson
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <20240319225122.3048400-2-sean.anderson@linux.dev>
On 20/03/2024 00:51, Sean Anderson wrote:
> Fix a few errors in the kerneldoc. Mostly this addresses missing/renamed
> members.
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
> Changes in v2:
> - New
>
> drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +++---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 1 +
> drivers/gpu/drm/xlnx/zynqmp_kms.h | 4 ++--
> 3 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index 407bc07cec69..f79bf3fb8110 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -128,9 +128,9 @@ struct zynqmp_disp_layer {
> * struct zynqmp_disp - Display controller
> * @dev: Device structure
> * @dpsub: Display subsystem
> - * @blend.base: Register I/O base address for the blender
> - * @avbuf.base: Register I/O base address for the audio/video buffer manager
> - * @audio.base: Registers I/O base address for the audio mixer
> + * @blend: Register I/O base address for the blender
> + * @avbuf: Register I/O base address for the audio/video buffer manager
> + * @audio: Registers I/O base address for the audio mixer
Afaics, the kernel doc guide:
https://docs.kernel.org/doc-guide/kernel-doc.html#nested-structs-unions
says that the current version is correct. Or is the issue that while,
say, 'base' is documented, 'blend' was not?
Tomi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/8] drm: zynqmp_dp: Downgrade log level for aux retries message
From: Tomi Valkeinen @ 2024-03-20 5:46 UTC (permalink / raw)
To: Sean Anderson
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <20240319225122.3048400-3-sean.anderson@linux.dev>
On 20/03/2024 00:51, Sean Anderson wrote:
> Enable this message for verbose debugging only as it is otherwise
> printed after every AUX message, quickly filling the log buffer.
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index a0606fab0e22..98a32e6a0459 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -1006,7 +1006,7 @@ zynqmp_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> msg->buffer, msg->size,
> &msg->reply);
> if (!ret) {
> - dev_dbg(dp->dev, "aux %d retries\n", i);
> + dev_vdbg(dp->dev, "aux %d retries\n", i);
> return msg->size;
> }
>
Yes, these are annoying... In my work branch I had added "if (i)" there,
so that this is only printed if there actually are retries.
But this is fine too (or even dropping the print totally), so:
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] dt-bindings: mtd: atmel-nand: convert txt to yaml
From: Balamanikandan Gunasundar @ 2024-03-20 5:52 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-kernel,
Balamanikandan Gunasundar
Convert the text bindings to yaml.
Note:
This patch is done on top of the commit I sent recently.
https://lore.kernel.org/all/20240320025258.6854-1-balamanikandan.gunasundar@microchip.com/
Please let me know if I should resend the above commit in this series.
Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
---
Balamanikandan Gunasundar (3):
dt-bindings: mtd: atmel-nand: convert txt to yaml
dt-bindings: mtd: atmel-nand: add atmel pmecc
dt-bindings: mtd: atmel-nand: add deprecated bindings
.../bindings/mtd/atmel-nand-deprecated.yaml | 156 ++++++++++++++
.../devicetree/bindings/mtd/atmel-nand.txt | 236 ---------------------
.../devicetree/bindings/mtd/atmel-nand.yaml | 166 +++++++++++++++
.../devicetree/bindings/mtd/atmel-pmecc.yaml | 58 +++++
MAINTAINERS | 2 +-
5 files changed, 381 insertions(+), 237 deletions(-)
---
base-commit: 66e1bf9c75595f96cefe0c32a7a719ba71c11bef
change-id: 20240320-linux-next-nand-yaml-b8674ce41e13
Best regards,
--
Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] dt-bindings: mtd: atmel-nand: convert txt to yaml
From: Balamanikandan Gunasundar @ 2024-03-20 5:52 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-kernel,
Balamanikandan Gunasundar
In-Reply-To: <20240320-linux-next-nand-yaml-v1-0-2d2495363e88@microchip.com>
Convert text to yaml for atmel nand controller
Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
---
.../devicetree/bindings/mtd/atmel-nand.txt | 50 -------
.../devicetree/bindings/mtd/atmel-nand.yaml | 166 +++++++++++++++++++++
MAINTAINERS | 2 +-
3 files changed, 167 insertions(+), 51 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index 4598930851d9..e332515c499a 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -1,53 +1,3 @@
-Atmel NAND flash controller bindings
-
-The NAND flash controller node should be defined under the EBI bus (see
-Documentation/devicetree/bindings/memory-controllers/atmel,ebi.txt).
-One or several NAND devices can be defined under this NAND controller.
-The NAND controller might be connected to an ECC engine.
-
-* NAND controller bindings:
-
-Required properties:
-- compatible: should be one of the following
- "atmel,at91rm9200-nand-controller"
- "atmel,at91sam9260-nand-controller"
- "atmel,at91sam9261-nand-controller"
- "atmel,at91sam9g45-nand-controller"
- "atmel,sama5d3-nand-controller"
- "microchip,sam9x60-nand-controller"
-- ranges: empty ranges property to forward EBI ranges definitions.
-- #address-cells: should be set to 2.
-- #size-cells: should be set to 1.
-- atmel,nfc-io: phandle to the NFC IO block. Only required for sama5d3
- controllers.
-- atmel,nfc-sram: phandle to the NFC SRAM block. Only required for sama5d3
- controllers.
-
-Optional properties:
-- ecc-engine: phandle to the PMECC block. Only meaningful if the SoC embeds
- a PMECC engine.
-
-* NAND device/chip bindings:
-
-Required properties:
-- reg: describes the CS lines assigned to the NAND device. If the NAND device
- exposes multiple CS lines (multi-dies chips), your reg property will
- contain X tuples of 3 entries.
- 1st entry: the CS line this NAND chip is connected to
- 2nd entry: the base offset of the memory region assigned to this
- device (always 0)
- 3rd entry: the memory region size (always 0x800000)
-
-Optional properties:
-- rb-gpios: the GPIO(s) used to check the Ready/Busy status of the NAND.
-- cs-gpios: the GPIO(s) used to control the CS line.
-- det-gpios: the GPIO used to detect if a Smartmedia Card is present.
-- atmel,rb: an integer identifying the native Ready/Busy pin. Only meaningful
- on sama5 SoCs.
-
-All generic properties are described in the generic yaml files under
-Documentation/devicetree/bindings/mtd/.
-
* ECC engine (PMECC) bindings:
Required properties:
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.yaml b/Documentation/devicetree/bindings/mtd/atmel-nand.yaml
new file mode 100644
index 000000000000..a5482d292293
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.yaml
@@ -0,0 +1,166 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/atmel-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel NAND flash controller
+
+maintainers:
+ - Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
+
+description: |
+ The NAND flash controller node should be defined under the EBI bus (see
+ Documentation/devicetree/bindings/memory-controllers/atmel,ebi.txt|yaml).
+ One or several NAND devices can be defined under this NAND controller.
+ The NAND controller might be connected to an ECC engine.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - atmel,at91rm9200-nand-controller
+ - atmel,at91sam9260-nand-controller
+ - atmel,at91sam9261-nand-controller
+ - atmel,at91sam9g45-nand-controller
+ - atmel,sama5d3-nand-controller
+ - microchip,sam9x60-nand-controller
+
+ ranges:
+ description: empty ranges property to forward EBI ranges definitions.
+
+ ecc-engine:
+ description:
+ phandle to the PMECC block. Only meaningful if the SoC embeds a PMECC
+ engine.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - atmel,at91rm9200-nand-controller
+ - atmel,at91sam9260-nand-controller
+ - atmel,at91sam9261-nand-controller
+ - atmel,at91sam9g45-nand-controller
+ - atmel,sama5d3-nand-controller
+ - microchip,sam9x60-nand-controller
+ then:
+ properties:
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,sama5d3-nand-controller
+ then:
+ properties:
+ atmel,nfc-io:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the NFC IO block.
+
+ atmel,nfc-sram:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle to the NFC SRAM block
+
+required:
+ - compatible
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+ type: object
+ $ref: nand-chip.yaml#
+ description:
+ NAND chip bindings. All generic properties described in
+ Documentation/devicetree/bindings/mtd/{common,nand}.txt also apply to
+ the NAND device node, and NAND partitions should be defined under the
+ NAND node as described in
+ Documentation/devicetree/bindings/mtd/partition.txt.
+
+ properties:
+ reg:
+ minItems: 1
+ description:
+ describes the CS lines assigned to the NAND device. If the NAND device
+ exposes multiple CS lines (multi-dies chips), your reg property will
+ contain X tuples of 3 entries.
+ reg = <0x3 0x0 0x800000>;
+ 1st entry - the CS line this NAND chip is connected to
+ 2nd entry - the base offset of the memory region assigned to this
+ device (always 0)
+ 3rd entry - the memory region size (always 0x800000)
+
+ rb-gpios:
+ description:
+ the GPIO(s) used to check the Ready/Busy status of the NAND.
+
+ cs-gpios:
+ description:
+ the GPIO(s) used to control the CS line.
+
+ det-gpios:
+ description:
+ the GPIO used to detect if a Smartmedia Card is present.
+
+ "atmel,rb":
+ description:
+ an integer identifying the native Ready/Busy pin. Only meaningful
+ on sama5 SoCs.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ nfc_io: nfc-io@70000000 {
+ compatible = "atmel,sama5d3-nfc-io", "syscon";
+ reg = <0x70000000 0x8000000>;
+ };
+
+ pmecc: ecc-engine@ffffc070 {
+ compatible = "atmel,at91sam9g45-pmecc";
+ reg = <0xffffc070 0x490>,
+ <0xffffc500 0x100>;
+ };
+
+ ebi: ebi@10000000 {
+ compatible = "atmel,sama5d3-ebi";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ atmel,smc = <&hsmc>;
+ reg = <0x10000000 0x10000000
+ 0x40000000 0x30000000>;
+ ranges = <0x0 0x0 0x10000000 0x10000000
+ 0x1 0x0 0x40000000 0x10000000
+ 0x2 0x0 0x50000000 0x10000000
+ 0x3 0x0 0x60000000 0x10000000>;
+ clocks = <&mck>;
+
+ nandflash_controller: nandflash-controller {
+ compatible = "atmel,sama5d3-nand-controller";
+ ecc-engine = <&pmecc>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+
+ nand@3 {
+ reg = <0x3 0x0 0x800000>;
+ atmel,rb = <0>;
+
+ /*
+ * Put generic NAND/MTD properties and
+ * subnodes here.
+ */
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index b6582bd3eb2c..3f2a6756223f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14503,7 +14503,7 @@ MICROCHIP NAND DRIVER
M: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
L: linux-mtd@lists.infradead.org
S: Supported
-F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
+F: Documentation/devicetree/bindings/mtd/atmel-*.yaml
F: drivers/mtd/nand/raw/atmel/*
MICROCHIP OTPC DRIVER
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: mtd: atmel-nand: add atmel pmecc
From: Balamanikandan Gunasundar @ 2024-03-20 5:52 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-kernel,
Balamanikandan Gunasundar
In-Reply-To: <20240320-linux-next-nand-yaml-v1-0-2d2495363e88@microchip.com>
Add bindings for programmable multibit error correction code controller
(PMECC).
Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
---
.../devicetree/bindings/mtd/atmel-nand.txt | 70 ----------------------
.../devicetree/bindings/mtd/atmel-pmecc.yaml | 58 ++++++++++++++++++
2 files changed, 58 insertions(+), 70 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index e332515c499a..1934614a9298 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -1,73 +1,3 @@
-* ECC engine (PMECC) bindings:
-
-Required properties:
-- compatible: should be one of the following
- "atmel,at91sam9g45-pmecc"
- "atmel,sama5d4-pmecc"
- "atmel,sama5d2-pmecc"
- "microchip,sam9x60-pmecc"
- "microchip,sam9x7-pmecc", "atmel,at91sam9g45-pmecc"
-- reg: should contain 2 register ranges. The first one is pointing to the PMECC
- block, and the second one to the PMECC_ERRLOC block.
-
-* SAMA5 NFC I/O bindings:
-
-SAMA5 SoCs embed an advanced NAND controller logic to automate READ/WRITE page
-operations. This interface to this logic is placed in a separate I/O range and
-should thus have its own DT node.
-
-- compatible: should be "atmel,sama5d3-nfc-io", "syscon".
-- reg: should contain the I/O range used to interact with the NFC logic.
-
-Example:
-
- nfc_io: nfc-io@70000000 {
- compatible = "atmel,sama5d3-nfc-io", "syscon";
- reg = <0x70000000 0x8000000>;
- };
-
- pmecc: ecc-engine@ffffc070 {
- compatible = "atmel,at91sam9g45-pmecc";
- reg = <0xffffc070 0x490>,
- <0xffffc500 0x100>;
- };
-
- ebi: ebi@10000000 {
- compatible = "atmel,sama5d3-ebi";
- #address-cells = <2>;
- #size-cells = <1>;
- atmel,smc = <&hsmc>;
- reg = <0x10000000 0x10000000
- 0x40000000 0x30000000>;
- ranges = <0x0 0x0 0x10000000 0x10000000
- 0x1 0x0 0x40000000 0x10000000
- 0x2 0x0 0x50000000 0x10000000
- 0x3 0x0 0x60000000 0x10000000>;
- clocks = <&mck>;
-
- nand_controller: nand-controller {
- compatible = "atmel,sama5d3-nand-controller";
- atmel,nfc-sram = <&nfc_sram>;
- atmel,nfc-io = <&nfc_io>;
- ecc-engine = <&pmecc>;
- #address-cells = <2>;
- #size-cells = <1>;
- ranges;
-
- nand@3 {
- reg = <0x3 0x0 0x800000>;
- atmel,rb = <0>;
-
- /*
- * Put generic NAND/MTD properties and
- * subnodes here.
- */
- };
- };
- };
-
------------------------------------------------------------------------
-
Deprecated bindings (should not be used in new device trees):
Required properties:
diff --git a/Documentation/devicetree/bindings/mtd/atmel-pmecc.yaml b/Documentation/devicetree/bindings/mtd/atmel-pmecc.yaml
new file mode 100644
index 000000000000..872401e9dda3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/atmel-pmecc.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/atmel-pmecc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip pmecc controller
+
+maintainers:
+ - Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
+
+description: |
+ Bindings for microchip Programmable Multibit Error Correction Code
+ Controller (PMECC). pmecc is a programmable BCH encoder/decoder. This
+ block is passed as the value to the "ecc-engine" property of microchip
+ nand flash controller node.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,at91sam9g45-pmecc
+ - atmel,sama5d2-pmecc
+ - atmel,sama5d4-pmecc
+ - microchip,sam9x60-pmecc
+ - microchip,sam9x7-pmecc
+ - items:
+ - const: microchip,sam9x60-pmecc
+ - const: atmel,at91sam9g45-pmecc
+
+ reg:
+ description:
+ The first should point to the PMECC block. The second should point to the
+ PMECC_ERRLOC block.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: microchip,sam9x7-pmecc
+ then:
+ properties:
+ clocks:
+ description:
+ The clock source for pmecc controller
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ pmecc: ecc-engine@ffffc070 {
+ compatible = "microchip,sam9x7-pmecc";
+ reg = <0xffffe000 0x300>,
+ <0xffffe600 0x100>;
+ clocks = <&pmc 2 48>;
+ };
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: mtd: atmel-nand: add deprecated bindings
From: Balamanikandan Gunasundar @ 2024-03-20 5:52 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-mtd, devicetree, linux-arm-kernel, linux-kernel,
Balamanikandan Gunasundar
In-Reply-To: <20240320-linux-next-nand-yaml-v1-0-2d2495363e88@microchip.com>
Add nand bindings for legacy nand controllers. These bindings are not used
with the new device trees. This is still maintained to support legacy dt
bindings.
Signed-off-by: Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
---
.../bindings/mtd/atmel-nand-deprecated.yaml | 156 +++++++++++++++++++++
.../devicetree/bindings/mtd/atmel-nand.txt | 116 ---------------
2 files changed, 156 insertions(+), 116 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand-deprecated.yaml b/Documentation/devicetree/bindings/mtd/atmel-nand-deprecated.yaml
new file mode 100644
index 000000000000..c8922ab0f1d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand-deprecated.yaml
@@ -0,0 +1,156 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/atmel-nand-deprecated.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel NAND flash controller deprecated bindings
+
+maintainers:
+ - Balamanikandan Gunasundar <balamanikandan.gunasundar@microchip.com>
+
+description: |
+ This should not be used in the new device trees.
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91rm9200-nand
+ - atmel,sama5d2-nand
+ - atmel,sama5d4-nand
+
+ reg:
+ description:
+ should specify localbus address and size used for the chip, and
+ hardware ECC controller if available. If the hardware ECC is PMECC,
+ it should contain address and size for PMECC and PMECC Error Location
+ controller. The PMECC lookup table address and size in ROM is
+ optional. If not specified, driver will build it in runtime.
+
+ atmel,nand-addr-offset:
+ description:
+ offset for the address latch.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ atmel,nand-cmd-offset:
+ description:
+ offset for the command latch.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ "#address-cells":
+ description:
+ Must be present if the device has sub-nodes representing partitions
+
+ "#size-cells":
+ description:
+ Must be present if the device has sub-nodes representing partitions.
+
+ gpios:
+ description:
+ specifies the gpio pins to control the NAND device. detect is an
+ optional gpio and may be set to 0 if not present.
+
+ atmel,nand-has-dma:
+ description:
+ support dma transfer for nand read/write.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ atmel,has-pmecc:
+ description:
+ enable Programmable Multibit ECC hardware, capable of BCH encoding
+ and decoding, on devices where it is present.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nand-on-flash-bbt:
+ description:
+ enable on flash bbt option if not present false
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ nand-ecc-mode:
+ description:
+ operation mode of the NAND ecc mode, soft by default. Supported
+ enum:
+ [none, soft, hw, hw_syndrome, hw_oob_first, soft_bch]
+ $ref: /schemas/types.yaml#/definitions/string
+
+ atmel,pmecc-cap:
+ description:
+ error correct capability for Programmable Multibit ECC Controller. If
+ the compatible string is "atmel,sama5d2-nand", 32 is also valid.
+ enum:
+ [2, 4, 8, 12, 24]
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ atmel,pmecc-sector-size:
+ description:
+ sector size for ECC computation.
+ enum:
+ [512, 1024]
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ atmel,pmecc-lookup-table-offset:
+ description:
+ includes two offsets of lookup table in ROM for different sector
+ size. First one is for sector size 512, the next is for sector size
+ 1024. If not specified, driver will build the table in runtime.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ nand-bus-width:
+ description:
+ nand bus width
+ enum:
+ [8, 16]
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - atmel,nand-addr-offset
+ - atmel,nand-cmd-offset
+ - "#address-cells"
+ - "#size-cells"
+ - gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ nand0: nand@40000000,0 {
+ compatible = "atmel,at91rm9200-nand";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x40000000 0x10000000
+ 0xffffe800 0x200>;
+ atmel,nand-addr-offset = <21>; /* ale */
+ atmel,nand-cmd-offset = <22>; /* cle */
+ nand-on-flash-bbt;
+ nand-ecc-mode = "soft";
+ gpios = <&pioC 13 0 /* rdy */
+ &pioC 14 0 /* nce */
+ 0 /* cd */
+ >;
+ };
+ - |
+ /* for PMECC supported chips */
+ nand1@40000000 {
+ compatible = "atmel,at91rm9200-nand";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x40000000 0x10000000 /* bus addr & size */
+ 0xffffe000 0x00000600 /* PMECC addr & size */
+ 0xffffe600 0x00000200 /* PMECC ERRLOC addr & size */
+ 0x00100000 0x00100000>; /* ROM addr & size */
+
+ atmel,nand-addr-offset = <21>; /* ale */
+ atmel,nand-cmd-offset = <22>; /* cle */
+ nand-on-flash-bbt;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc; /* enable PMECC */
+ atmel,pmecc-cap = <2>;
+ atmel,pmecc-sector-size = <512>;
+ atmel,pmecc-lookup-table-offset = <0x8000 0x10000>;
+ gpios = <&pioD 5 0 /* rdy */
+ &pioD 4 0 /* nce */
+ 0 /* cd */
+ >;
+ };
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
deleted file mode 100644
index 1934614a9298..000000000000
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ /dev/null
@@ -1,116 +0,0 @@
-Deprecated bindings (should not be used in new device trees):
-
-Required properties:
-- compatible: The possible values are:
- "atmel,at91rm9200-nand"
- "atmel,sama5d2-nand"
- "atmel,sama5d4-nand"
-- reg : should specify localbus address and size used for the chip,
- and hardware ECC controller if available.
- If the hardware ECC is PMECC, it should contain address and size for
- PMECC and PMECC Error Location controller.
- The PMECC lookup table address and size in ROM is optional. If not
- specified, driver will build it in runtime.
-- atmel,nand-addr-offset : offset for the address latch.
-- atmel,nand-cmd-offset : offset for the command latch.
-- #address-cells, #size-cells : Must be present if the device has sub-nodes
- representing partitions.
-
-- gpios : specifies the gpio pins to control the NAND device. detect is an
- optional gpio and may be set to 0 if not present.
-
-Optional properties:
-- atmel,nand-has-dma : boolean to support dma transfer for nand read/write.
-- nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default.
- Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
- "soft_bch".
-- atmel,has-pmecc : boolean to enable Programmable Multibit ECC hardware,
- capable of BCH encoding and decoding, on devices where it is present.
-- atmel,pmecc-cap : error correct capability for Programmable Multibit ECC
- Controller. Supported values are: 2, 4, 8, 12, 24. If the compatible string
- is "atmel,sama5d2-nand", 32 is also valid.
-- atmel,pmecc-sector-size : sector size for ECC computation. Supported values
- are: 512, 1024.
-- atmel,pmecc-lookup-table-offset : includes two offsets of lookup table in ROM
- for different sector size. First one is for sector size 512, the next is for
- sector size 1024. If not specified, driver will build the table in runtime.
-- nand-bus-width : 8 or 16 bus width if not present 8
-- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
-
-Nand Flash Controller(NFC) is an optional sub-node
-Required properties:
-- compatible : "atmel,sama5d3-nfc".
-- reg : should specify the address and size used for NFC command registers,
- NFC registers and NFC SRAM. NFC SRAM address and size can be absent
- if don't want to use it.
-- clocks: phandle to the peripheral clock
-Optional properties:
-- atmel,write-by-sram: boolean to enable NFC write by SRAM.
-
-Examples:
-nand0: nand@40000000,0 {
- compatible = "atmel,at91rm9200-nand";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = <0x40000000 0x10000000
- 0xffffe800 0x200
- >;
- atmel,nand-addr-offset = <21>; /* ale */
- atmel,nand-cmd-offset = <22>; /* cle */
- nand-on-flash-bbt;
- nand-ecc-mode = "soft";
- gpios = <&pioC 13 0 /* rdy */
- &pioC 14 0 /* nce */
- 0 /* cd */
- >;
- partition@0 {
- ...
- };
-};
-
-/* for PMECC supported chips */
-nand0: nand@40000000 {
- compatible = "atmel,at91rm9200-nand";
- #address-cells = <1>;
- #size-cells = <1>;
- reg = < 0x40000000 0x10000000 /* bus addr & size */
- 0xffffe000 0x00000600 /* PMECC addr & size */
- 0xffffe600 0x00000200 /* PMECC ERRLOC addr & size */
- 0x00100000 0x00100000 /* ROM addr & size */
- >;
- atmel,nand-addr-offset = <21>; /* ale */
- atmel,nand-cmd-offset = <22>; /* cle */
- nand-on-flash-bbt;
- nand-ecc-mode = "hw";
- atmel,has-pmecc; /* enable PMECC */
- atmel,pmecc-cap = <2>;
- atmel,pmecc-sector-size = <512>;
- atmel,pmecc-lookup-table-offset = <0x8000 0x10000>;
- gpios = <&pioD 5 0 /* rdy */
- &pioD 4 0 /* nce */
- 0 /* cd */
- >;
- partition@0 {
- ...
- };
-};
-
-/* for NFC supported chips */
-nand0: nand@40000000 {
- compatible = "atmel,at91rm9200-nand";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
- ...
- nfc@70000000 {
- compatible = "atmel,sama5d3-nfc";
- #address-cells = <1>;
- #size-cells = <1>;
- clocks = <&hsmc_clk>
- reg = <
- 0x70000000 0x10000000 /* NFC Command Registers */
- 0xffffc000 0x00000070 /* NFC HSMC regs */
- 0x00200000 0x00100000 /* NFC SRAM banks */
- >;
- };
-};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/8] drm: zynqmp_dp: Adjust training values per-lane
From: Tomi Valkeinen @ 2024-03-20 5:57 UTC (permalink / raw)
To: Sean Anderson
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <20240319225122.3048400-4-sean.anderson@linux.dev>
On 20/03/2024 00:51, Sean Anderson wrote:
> The feedback we get from the DPRX is per-lane. Make changes using this
> information, instead of picking the maximum values from all lanes. This
> results in more-consistent training on marginal links.
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 23 ++++++++---------------
> 1 file changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 98a32e6a0459..8635b5673386 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -605,28 +605,21 @@ static void zynqmp_dp_adjust_train(struct zynqmp_dp *dp,
> u8 link_status[DP_LINK_STATUS_SIZE])
> {
> u8 *train_set = dp->train_set;
> - u8 voltage = 0, preemphasis = 0;
> u8 i;
>
> for (i = 0; i < dp->mode.lane_cnt; i++) {
> - u8 v = drm_dp_get_adjust_request_voltage(link_status, i);
> - u8 p = drm_dp_get_adjust_request_pre_emphasis(link_status, i);
> + u8 voltage = drm_dp_get_adjust_request_voltage(link_status, i);
> + u8 preemphasis =
> + drm_dp_get_adjust_request_pre_emphasis(link_status, i);
>
> - if (v > voltage)
> - voltage = v;
> + if (voltage >= DP_TRAIN_VOLTAGE_SWING_LEVEL_3)
> + voltage |= DP_TRAIN_MAX_SWING_REACHED;
>
> - if (p > preemphasis)
> - preemphasis = p;
> - }
> + if (preemphasis >= DP_TRAIN_PRE_EMPH_LEVEL_2)
> + preemphasis |= DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
>
> - if (voltage >= DP_TRAIN_VOLTAGE_SWING_LEVEL_3)
> - voltage |= DP_TRAIN_MAX_SWING_REACHED;
> -
> - if (preemphasis >= DP_TRAIN_PRE_EMPH_LEVEL_2)
> - preemphasis |= DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
> -
> - for (i = 0; i < dp->mode.lane_cnt; i++)
> train_set[i] = voltage | preemphasis;
> + }
> }
>
> /**
Looks fine to me, but a few cosmetic suggestions, feel free to ignore if
not to your liking:
1)
u8 voltage, preemphasis;
voltage = drm_dp_get_adjust_request_voltage(link_status, i);
preemphasis = drm_dp_get_adjust_request_pre_emphasis(link_status, i);
2)
for (unsigned int i = 0; i < dp->mode.lane_cnt; i++)
3)
dp->train_set[i] = voltage | preemphasis;
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/8] drm: xlnx: Fix kerneldoc
From: Randy Dunlap @ 2024-03-20 6:05 UTC (permalink / raw)
To: Tomi Valkeinen, Sean Anderson
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <e2eba421-cba1-4dd5-837c-6be5f07ed402@ideasonboard.com>
On 3/19/24 22:42, Tomi Valkeinen wrote:
> On 20/03/2024 00:51, Sean Anderson wrote:
>> Fix a few errors in the kerneldoc. Mostly this addresses missing/renamed
>> members.
>>
>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> ---
>>
>> Changes in v2:
>> - New
>>
>> drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +++---
>> drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 1 +
>> drivers/gpu/drm/xlnx/zynqmp_kms.h | 4 ++--
>> 3 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
>> index 407bc07cec69..f79bf3fb8110 100644
>> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
>> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
>> @@ -128,9 +128,9 @@ struct zynqmp_disp_layer {
>> * struct zynqmp_disp - Display controller
>> * @dev: Device structure
>> * @dpsub: Display subsystem
>> - * @blend.base: Register I/O base address for the blender
>> - * @avbuf.base: Register I/O base address for the audio/video buffer manager
>> - * @audio.base: Registers I/O base address for the audio mixer
>> + * @blend: Register I/O base address for the blender
>> + * @avbuf: Register I/O base address for the audio/video buffer manager
>> + * @audio: Registers I/O base address for the audio mixer
>
> Afaics, the kernel doc guide:
>
> https://docs.kernel.org/doc-guide/kernel-doc.html#nested-structs-unions
>
> says that the current version is correct. Or is the issue that while, say, 'base' is documented, 'blend' was not?
Hi,
I would do it more like so:
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 3 +++
1 file changed, 3 insertions(+)
diff -- a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -128,8 +128,11 @@ struct zynqmp_disp_layer {
* struct zynqmp_disp - Display controller
* @dev: Device structure
* @dpsub: Display subsystem
+ * @blend: blender iomem info
* @blend.base: Register I/O base address for the blender
+ * @avbuf: audio/video buffer iomem info
* @avbuf.base: Register I/O base address for the audio/video buffer manager
+ * @audio: audio mixer iomem info
* @audio.base: Registers I/O base address for the audio mixer
* @layers: Layers (planes)
*/
but in my testing, Sean's way or my way result in no warning/errors.
--
#Randy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
From: Yujie Liu @ 2024-03-20 6:03 UTC (permalink / raw)
To: Sean Anderson
Cc: Laurent Pinchart, kernel test robot, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel, oe-kbuild-all,
David Airlie, linux-kernel, Michal Simek, linux-arm-kernel,
Daniel Vetter
In-Reply-To: <6b44c9b7-e1e2-4b69-a443-4616ceab6f17@linux.dev>
Hi Sean,
On Mon, Mar 18, 2024 at 03:05:57PM -0400, Sean Anderson wrote:
> On 3/18/24 13:50, Laurent Pinchart wrote:
> > On Mon, Mar 18, 2024 at 11:06:40AM -0400, Sean Anderson wrote:
> >> On 3/16/24 06:14, kernel test robot wrote:
> >> > Hi Sean,
> >> >
> >> > kernel test robot noticed the following build warnings:
> >> >
> >> > [auto build test WARNING on v6.8]
> >> > [cannot apply to drm-misc/drm-misc-next linus/master next-20240315]
> >> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> >> > And when submitting patch, we suggest to use '--base' as documented in
> >> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >> >
> >> > url: https://github.com/intel-lab-lkp/linux/commits/Sean-Anderson/drm-zynqmp_dp-Downgrade-log-level-for-aux-retries-message/20240316-071208
> >> > base: v6.8
> >> > patch link: https://lore.kernel.org/r/20240315230916.1759060-7-sean.anderson%40linux.dev
> >> > patch subject: [PATCH 6/6] drm: zynqmp_dp: Add debugfs interface for compliance testing
> >> > config: microblaze-allmodconfig (https://download.01.org/0day-ci/archive/20240316/202403161704.ACHJdSJG-lkp@intel.com/config)
> >> > compiler: microblaze-linux-gcc (GCC) 13.2.0
> >> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240316/202403161704.ACHJdSJG-lkp@intel.com/reproduce)
[...]
> >> >
> >> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> >> > the same patch/commit), kindly add following tags
> >> > | Reported-by: kernel test robot <lkp@intel.com>
> >> > | Closes: https://lore.kernel.org/oe-kbuild-all/202403161704.ACHJdSJG-lkp@intel.com/
> >> >
> >> > All warnings (new ones prefixed by >>):
> >> >
> >> > drivers/gpu/drm/xlnx/zynqmp_dp.c: In function 'zynqmp_dp_bridge_debugfs_init':
> >> >>> drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:31: warning: 'sprintf' may write a terminating nul past the end of the destination [-Wformat-overflow=]
> >> > 2168 | sprintf(name, fmt, i);
> >> > | ^~~
> >> > drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:17: note: 'sprintf' output between 18 and 20 bytes into a destination of size 19
> >> > 2168 | sprintf(name, fmt, i);
> >> > | ^~~~~~~~~~~~~~~~~~~~~
> >>
> >> Not a bug, as i will be at most 4, which uses 1 digit.
> >
> > The compiler can't know that. Please fix this, there's a zero warning
> > policy.
>
> I cannot reproduce this with GCC 13.2.0. So given that this is not a bug and I can't reproduce
> it, I don't see how I can verify any fix.
There is a "reproduce" link in the bot's report. We followed the steps
in that link and found that the warning could be reproduced. Please
notice that this is a "W=1" warning. BTW, we also tested the v2 patch
and the warning has been fixed there. Just for your information.
$ cd linux
$ git checkout v6.8
HEAD is now at e8f897f4afef0 Linux 6.8
$ b4 am https://lore.kernel.org/r/20240315230916.1759060-7-sean.anderson@linux.dev
$ git am ./20240315_sean_anderson_drm_zynqmp_dp_misc_patches_and_debugfs_support.mbx
Applying: drm: zynqmp_dp: Downgrade log level for aux retries message
Applying: drm: zynqmp_dp: Adjust training values per-lane
Applying: drm: zynqmp_dp: Add locking
Applying: drm: zynqmp_dp: Split off several helper functions
Applying: drm: zynqmp_dp: Optionally ignore DPCD errors
Applying: drm: zynqmp_dp: Add debugfs interface for compliance testing
$ wget https://download.01.org/0day-ci/archive/20240316/202403161704.ACHJdSJG-lkp@intel.com/config
$ mkdir build_dir
$ cp config build_dir/.config
$ git clone https://github.com/intel/lkp-tests.git ~/lkp-tests
$ COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-13.2.0 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=microblaze olddefconfig
$ COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-13.2.0 ~/lkp-tests/kbuild/make.cross W=1 O=build_dir ARCH=microblaze drivers/gpu/drm/xlnx/zynqmp_dp.o
...
CC [M] drivers/gpu/drm/xlnx/zynqmp_dp.o
../drivers/gpu/drm/xlnx/zynqmp_dp.c: In function 'zynqmp_dp_bridge_debugfs_init':
../drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:31: warning: 'sprintf' may write a terminating nul past the end of the destination [-Wformat-overflow=]
2168 | sprintf(name, fmt, i);
| ^~~
../drivers/gpu/drm/xlnx/zynqmp_dp.c:2168:17: note: 'sprintf' output between 18 and 20 bytes into a destination of size 19
2168 | sprintf(name, fmt, i);
| ^~~~~~~~~~~~~~~~~~~~~
Best Regards,
Yujie
>
> --Sean
>
> >> > vim +/sprintf +2168 drivers/gpu/drm/xlnx/zynqmp_dp.c
> >> >
> >> > 2136
> >> > 2137 DEFINE_DEBUGFS_ATTRIBUTE(fops_zynqmp_dp_rate, zynqmp_dp_rate_get,
> >> > 2138 zynqmp_dp_rate_set, "%llu\n");
> >> > 2139
> >> > 2140 static void zynqmp_dp_bridge_debugfs_init(struct drm_bridge *bridge,
> >> > 2141 struct dentry *root)
> >> > 2142 {
> >> > 2143 struct zynqmp_dp *dp = bridge_to_dp(bridge);
> >> > 2144 struct dentry *test;
> >> > 2145 int i;
> >> > 2146
> >> > 2147 dp->test.bw_code = DP_LINK_BW_5_4;
> >> > 2148 dp->test.link_cnt = dp->num_lanes;
> >> > 2149
> >> > 2150 test = debugfs_create_dir("test", root);
> >> > 2151 #define CREATE_FILE(name) \
> >> > 2152 debugfs_create_file(#name, 0600, test, dp, &fops_zynqmp_dp_##name)
> >> > 2153 CREATE_FILE(pattern);
> >> > 2154 CREATE_FILE(enhanced);
> >> > 2155 CREATE_FILE(downspread);
> >> > 2156 CREATE_FILE(active);
> >> > 2157 CREATE_FILE(custom);
> >> > 2158 CREATE_FILE(rate);
> >> > 2159 CREATE_FILE(lanes);
> >> > 2160
> >> > 2161 for (i = 0; i < dp->num_lanes; i++) {
> >> > 2162 static const char fmt[] = "lane%d_preemphasis";
> >> > 2163 char name[sizeof(fmt)];
> >> > 2164
> >> > 2165 dp->debugfs_train_set[i].dp = dp;
> >> > 2166 dp->debugfs_train_set[i].lane = i;
> >> > 2167
> >> >> 2168 sprintf(name, fmt, i);
> >> > 2169 debugfs_create_file(name, 0600, test,
> >> > 2170 &dp->debugfs_train_set[i],
> >> > 2171 &fops_zynqmp_dp_preemphasis);
> >> > 2172
> >> > 2173 sprintf(name, "lane%d_swing", i);
> >> > 2174 debugfs_create_file(name, 0600, test,
> >> > 2175 &dp->debugfs_train_set[i],
> >> > 2176 &fops_zynqmp_dp_swing);
> >> > 2177 }
> >> > 2178 }
> >> > 2179
> >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/8] drm: zynqmp_dp: Rearrange zynqmp_dp for better padding
From: Tomi Valkeinen @ 2024-03-20 6:14 UTC (permalink / raw)
To: Sean Anderson
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <20240319225122.3048400-5-sean.anderson@linux.dev>
On 20/03/2024 00:51, Sean Anderson wrote:
> Sort the members of struct zynqmp_dp to reduce padding necessary for
> alignment.
>
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
>
> Changes in v2:
> - New
>
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 8635b5673386..f1834c8e3c02 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> @@ -255,10 +255,10 @@ struct zynqmp_dp_link_config {
> * @fmt: format identifier string
> */
> struct zynqmp_dp_mode {
> - u8 bw_code;
> - u8 lane_cnt;
> - int pclock;
> const char *fmt;
> + int pclock;
> + u8 bw_code;
> + u8 lane_cnt;
> };
>
> /**
> @@ -295,27 +295,27 @@ struct zynqmp_dp_config {
> * @train_set: set of training data
> */
> struct zynqmp_dp {
> + struct drm_dp_aux aux;
> + struct drm_bridge bridge;
> + struct delayed_work hpd_work;
> +
> + struct drm_bridge *next_bridge;
> struct device *dev;
> struct zynqmp_dpsub *dpsub;
> void __iomem *iomem;
> struct reset_control *reset;
> - int irq;
> -
> - struct drm_bridge bridge;
> - struct drm_bridge *next_bridge;
> -
> - struct zynqmp_dp_config config;
> - struct drm_dp_aux aux;
> struct phy *phy[ZYNQMP_DP_MAX_LANES];
> - u8 num_lanes;
> - struct delayed_work hpd_work;
> +
> enum drm_connector_status status;
> + int irq;
> bool enabled;
>
> - u8 dpcd[DP_RECEIVER_CAP_SIZE];
> - struct zynqmp_dp_link_config link_config;
> struct zynqmp_dp_mode mode;
> + struct zynqmp_dp_link_config link_config;
> + struct zynqmp_dp_config config;
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
> u8 train_set[ZYNQMP_DP_MAX_LANES];
> + u8 num_lanes;
> };
>
> static inline struct zynqmp_dp *bridge_to_dp(struct drm_bridge *bridge)
If you change the order of the fields, you should change the order in
the kernel doc accordingly.
To be honest, I'm not sure if I like this patch. We have usually one
instance of these structs allocated. How many bytes do we save?
I'm fine with getting easy savings by changing the field order in some
cases, but I think the "human" side of the order is important too:
usually the fields are grouped in some way, and ordered so that the more
base or generic ones are first, and fields for some specific feature are
later. And fields protected by a lock should be grouped together, with
their lock being first/last in that group.
Looking at the zynqmp_dp struct with this patch, I get an urge to start
moving things around: dev, dpsub, iomem, etc first, hpd somewhere later.
Base config fields like config, num_lanes, irq would be grouped
together. Etc.
Tomi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 09/13] mm/powerpc: Redefine pXd_huge() with pXd_leaf()
From: Christophe Leroy @ 2024-03-20 6:16 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Peter Xu, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org, Matthew Wilcox,
linuxppc-dev@lists.ozlabs.org, Andrew Morton, x86@kernel.org,
Mike Rapoport, Muchun Song, sparclinux@vger.kernel.org,
Michael Ellerman, Nicholas Piggin, Aneesh Kumar K.V,
Naveen N. Rao
In-Reply-To: <20240319232656.GC159172@nvidia.com>
Le 20/03/2024 à 00:26, Jason Gunthorpe a écrit :
> On Tue, Mar 19, 2024 at 11:07:08PM +0000, Christophe Leroy wrote:
>>
>>
>> Le 18/03/2024 à 17:15, Jason Gunthorpe a écrit :
>>> On Thu, Mar 14, 2024 at 01:11:59PM +0000, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 14/03/2024 à 13:53, Peter Xu a écrit :
>>>>> On Thu, Mar 14, 2024 at 08:45:34AM +0000, Christophe Leroy wrote:
>>>>>>
>>>>>>
>>>>>> Le 13/03/2024 à 22:47, peterx@redhat.com a écrit :
>>>>>>> From: Peter Xu <peterx@redhat.com>
>>>>>>>
>>>>>>> PowerPC book3s 4K mostly has the same definition on both, except pXd_huge()
>>>>>>> constantly returns 0 for hash MMUs. As Michael Ellerman pointed out [1],
>>>>>>> it is safe to check _PAGE_PTE on hash MMUs, as the bit will never be set so
>>>>>>> it will keep returning false.
>>>>>>>
>>>>>>> As a reference, __p[mu]d_mkhuge() will trigger a BUG_ON trying to create
>>>>>>> such huge mappings for 4K hash MMUs. Meanwhile, the major powerpc hugetlb
>>>>>>> pgtable walker __find_linux_pte() already used pXd_leaf() to check hugetlb
>>>>>>> mappings.
>>>>>>>
>>>>>>> The goal should be that we will have one API pXd_leaf() to detect all kinds
>>>>>>> of huge mappings. AFAICT we need to use the pXd_leaf() impl (rather than
>>>>>>> pXd_huge() ones) to make sure ie. THPs on hash MMU will also return true.
>>>>>>
>>>>>> All kinds of huge mappings ?
>>>>>>
>>>>>> pXd_leaf() will detect only leaf mappings (like pXd_huge() ). There are
>>>>>> also huge mappings through hugepd. On powerpc 8xx we have 8M huge pages
>>>>>> and 512k huge pages. A PGD entry covers 4M so pgd_leaf() won't report
>>>>>> those huge pages.
>>>>>
>>>>> Ah yes, I should always mention this is in the context of leaf huge pages
>>>>> only. Are the examples you provided all fall into hugepd category? If so
>>>>> I can reword the commit message, as:
>>>>
>>>> On powerpc 8xx, only the 8M huge pages fall into the hugepd case.
>>>>
>>>> The 512k hugepages are at PTE level, they are handled more or less like
>>>> CONT_PTE on ARM. see function set_huge_pte_at() for more context.
>>>>
>>>> You can also look at pte_leaf_size() and pgd_leaf_size().
>>>
>>> IMHO leaf should return false if the thing is pointing to a next level
>>> page table, even if that next level is fully populated with contiguous
>>> pages.
>>>
>>> This seems more aligned with the contig page direction that hugepd
>>> should be moved over to..
>>
>> Should hugepd be moved to the contig page direction, really ?
>
> Sure? Is there any downside for the reading side to do so?
Probably not.
>
>> Would it be acceptable that a 8M hugepage requires 2048 contig entries
>> in 2 page tables, when the hugepd allows a single entry ?
>
> ? I thought we agreed the only difference would be that something new
> is needed to merge the two identical sibling page tables into one, ie
> you pay 2x the page table memory if that isn't fixed. That is write
> side only change and I imagine it could be done with a single PPC
> special API.
>
> Honestly not totally sure that is a big deal, it is already really
> memory inefficient compared to every other arch's huge page by needing
> the child page table in the first place.
>
>> Would it be acceptable performancewise ?
>
> Isn't this particular PPC sub platform ancient? Are there current real
> users that are going to have hugetlbfs special code and care about
> this performance detail on a 6.20 era kernel?
Ancient yes but still widely in use and with the emergence of voice over
IP in Air Trafic Control, performance becomes more and more challenge
with those old boards that have another 10 years in front of them.
>
> In today's world wouldn't it be performance better if these platforms
> could support THP by aligning to the contig API instead of being
> special?
Indeed, if we can promote THP that'd be even better.
>
> Am I wrong to question why we are polluting the core code for this
> special optimization?
At the first place that was to get a close fit between hardware
pagetable topology and linux pagetable topology. But obviously we
already stepped back for 512k pages, so let's go one more step aside and
do similar with 8M pages.
I'll give it a try and see how it goes.
Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v3 5/5] mm: support large folios swapin as a whole
From: Huang, Ying @ 2024-03-20 6:20 UTC (permalink / raw)
To: Barry Song
Cc: Ryan Roberts, Matthew Wilcox, akpm, linux-mm, chengming.zhou,
chrisl, david, hannes, kasong, linux-arm-kernel, linux-kernel,
mhocko, nphamcs, shy828301, steven.price, surenb, wangkefeng.wang,
xiang, yosryahmed, yuzhao, Chuanhua Han, Barry Song
In-Reply-To: <CAGsJ_4zuEFnLwM_h7DF1BN2eN3P4S0Sw=omxo90ucKpPT4ampA@mail.gmail.com>
Barry Song <21cnbao@gmail.com> writes:
> On Wed, Mar 20, 2024 at 3:20 PM Huang, Ying <ying.huang@intel.com> wrote:
>>
>> Ryan Roberts <ryan.roberts@arm.com> writes:
>>
>> > On 19/03/2024 09:20, Huang, Ying wrote:
>> >> Ryan Roberts <ryan.roberts@arm.com> writes:
>> >>
>> >>>>>> I agree phones are not the only platform. But Rome wasn't built in a
>> >>>>>> day. I can only get
>> >>>>>> started on a hardware which I can easily reach and have enough hardware/test
>> >>>>>> resources on it. So we may take the first step which can be applied on
>> >>>>>> a real product
>> >>>>>> and improve its performance, and step by step, we broaden it and make it
>> >>>>>> widely useful to various areas in which I can't reach :-)
>> >>>>>
>> >>>>> We must guarantee the normal swap path runs correctly and has no
>> >>>>> performance regression when developing SWP_SYNCHRONOUS_IO optimization.
>> >>>>> So we have to put some effort on the normal path test anyway.
>> >>>>>
>> >>>>>> so probably we can have a sysfs "enable" entry with default "n" or
>> >>>>>> have a maximum
>> >>>>>> swap-in order as Ryan's suggestion [1] at the beginning,
>> >>>>>>
>> >>>>>> "
>> >>>>>> So in the common case, swap-in will pull in the same size of folio as was
>> >>>>>> swapped-out. Is that definitely the right policy for all folio sizes? Certainly
>> >>>>>> it makes sense for "small" large folios (e.g. up to 64K IMHO). But I'm not sure
>> >>>>>> it makes sense for 2M THP; As the size increases the chances of actually needing
>> >>>>>> all of the folio reduces so chances are we are wasting IO. There are similar
>> >>>>>> arguments for CoW, where we currently copy 1 page per fault - it probably makes
>> >>>>>> sense to copy the whole folio up to a certain size.
>> >>>>>> "
>> >>>
>> >>> I thought about this a bit more. No clear conclusions, but hoped this might help
>> >>> the discussion around policy:
>> >>>
>> >>> The decision about the size of the THP is made at first fault, with some help
>> >>> from user space and in future we might make decisions to split based on
>> >>> munmap/mremap/etc hints. In an ideal world, the fact that we have had to swap
>> >>> the THP out at some point in its lifetime should not impact on its size. It's
>> >>> just being moved around in the system and the reason for our original decision
>> >>> should still hold.
>> >>>
>> >>> So from that PoV, it would be good to swap-in to the same size that was
>> >>> swapped-out.
>> >>
>> >> Sorry, I don't agree with this. It's better to swap-in and swap-out in
>> >> smallest size if the page is only accessed seldom to avoid to waste
>> >> memory.
>> >
>> > If we want to optimize only for memory consumption, I'm sure there are many
>> > things we would do differently. We need to find a balance between memory and
>> > performance. The benefits of folios are well documented and the kernel is
>> > heading in the direction of managing memory in variable-sized blocks. So I don't
>> > think it's as simple as saying we should always swap-in the smallest possible
>> > amount of memory.
>>
>> It's conditional, that is,
>>
>> "if the page is only accessed seldom"
>>
>> Then, the page swapped-in will be swapped-out soon and adjacent pages in
>> the same large folio will not be accessed during this period.
>>
>> So, I suggest to create an algorithm to decide swap-in order based on
>> swap-readahead information automatically. It can detect the situation
>> above via reduced swap readahead window size. And, if the page is
>> accessed for quite long time, and the adjacent pages in the same large
>> folio are accessed too, swap-readahead window will increase and large
>> swap-in order will be used.
>
> The original size of do_anonymous_page() should be honored, considering it
> embodies a decision influenced by not only sysfs settings and per-vma
> HUGEPAGE hints but also architectural characteristics, for example
> CONT-PTE.
>
> The model you're proposing may offer memory-saving benefits or reduce I/O,
> but it entirely disassociates the size of the swap in from the size prior to the
> swap out.
Readahead isn't the only factor to determine folio order. For example,
we must respect "never" policy to allocate order-0 folio always.
There's no requirements to use swap-out order in swap-in too. Memory
allocation has different performance character of storage reading.
> Moreover, there's no guarantee that the large folio generated by
> the readahead window is contiguous in the swap and can be added to the
> swap cache, as we are currently dealing with folio->swap instead of
> subpage->swap.
Yes. We can optimize only when all conditions are satisfied. Just like
other optimization.
> Incidentally, do_anonymous_page() serves as the initial location for allocating
> large folios. Given that memory conservation is a significant consideration in
> do_swap_page(), wouldn't it be even more crucial in do_anonymous_page()?
Yes. We should consider that too. IIUC, that is why mTHP support is
off by default for now. After we find a way to solve the memory usage
issue. We may make default "on".
> A large folio, by its nature, represents a high-quality resource that has the
> potential to leverage hardware characteristics for the benefit of the
> entire system.
But not at the cost of memory wastage.
> Conversely, I don't believe that a randomly determined size dictated by the
> readahead window possesses the same advantageous qualities.
There's a readahead algorithm which is not pure random.
> SWP_SYNCHRONOUS_IO devices are not reliant on readahead whatsoever,
> their needs should also be respected.
I understand that there are special requirements for SWP_SYNCHRONOUS_IO
devices. I just suggest to work on general code before specific
optimization.
>> > You also said we should swap *out* in smallest size possible. Have I
>> > misunderstood you? I thought the case for swapping-out a whole folio without
>> > splitting was well established and non-controversial?
>>
>> That is conditional too.
>>
>> >>
>> >>> But we only kind-of keep that information around, via the swap
>> >>> entry contiguity and alignment. With that scheme it is possible that multiple
>> >>> virtually adjacent but not physically contiguous folios get swapped-out to
>> >>> adjacent swap slot ranges and then they would be swapped-in to a single, larger
>> >>> folio. This is not ideal, and I think it would be valuable to try to maintain
>> >>> the original folio size information with the swap slot. One way to do this would
>> >>> be to store the original order for which the cluster was allocated in the
>> >>> cluster. Then we at least know that a given swap slot is either for a folio of
>> >>> that order or an order-0 folio (due to cluster exhaustion/scanning). Can we
>> >>> steal a bit from swap_map to determine which case it is? Or are there better
>> >>> approaches?
>> >>
>> >> [snip]
--
Best Regards,
Huang, Ying
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 0/3] add pmic pca9451a support
From: Joy Zou @ 2024-03-20 6:28 UTC (permalink / raw)
To: frank.li, ping.bai, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer
Cc: kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel, imx
The patchset supports pmic pca9451a.
For the details, please check the patch commit log.
---
Changes in v6:
- Change the reg to the second property.
Changes in v5:
- adjust gpio@22 to the front of pmic@25.
Changes in v4:
- modify the comment for uSDHC but not i2c.
Changes in v3:
- modify the dts voltags constraints.
- remove unnecessary changes in driver code.
- modify commit message.
- add tag for dt-bindings.
Changes in v2:
- drop old part support.
Joy Zou (3):
regulator: dt-bindings: pca9450: add pca9451a support
regulator: pca9450: add pca9451a support
arm64: dts: imx93-11x11-evk: add pca9451a support
.../regulator/nxp,pca9450-regulator.yaml | 1 +
.../boot/dts/freescale/imx93-11x11-evk.dts | 111 ++++++++++
drivers/regulator/pca9450-regulator.c | 194 +++++++++++++++++-
include/linux/regulator/pca9450.h | 1 +
4 files changed, 305 insertions(+), 2 deletions(-)
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/3] regulator: dt-bindings: pca9450: add pca9451a support
From: Joy Zou @ 2024-03-20 6:28 UTC (permalink / raw)
To: frank.li, ping.bai, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer
Cc: kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel, imx
In-Reply-To: <20240320062849.1321423-1-joy.zou@nxp.com>
Update pca9450 bindings.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
changes in v3:
1. add Acked-by tag.
changes in v2:
1. adjust the subject prefix sequence.
---
.../devicetree/bindings/regulator/nxp,pca9450-regulator.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
index 3d469b8e9774..849bfa50bdba 100644
--- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml
@@ -28,6 +28,7 @@ properties:
- nxp,pca9450a
- nxp,pca9450b
- nxp,pca9450c
+ - nxp,pca9451a
reg:
maxItems: 1
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 2/3] regulator: pca9450: add pca9451a support
From: Joy Zou @ 2024-03-20 6:28 UTC (permalink / raw)
To: frank.li, ping.bai, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer
Cc: kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel, imx
In-Reply-To: <20240320062849.1321423-1-joy.zou@nxp.com>
Adding support for new pmic pca9451a.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
Changes in v3:
1. remove not related change.
2. delete unnecessary empty line.
3. modify commit message.
Changes in v2:
1. remove the old part support because the old part only is used for sample
and is diffcult to distinguish old and new part. so drop old part.
2. remove the unnecessary marco definition in the file pca9450.h.
---
drivers/regulator/pca9450-regulator.c | 194 +++++++++++++++++++++++++-
include/linux/regulator/pca9450.h | 1 +
2 files changed, 193 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/pca9450-regulator.c b/drivers/regulator/pca9450-regulator.c
index 2ab365d2749f..242ff25f5b83 100644
--- a/drivers/regulator/pca9450-regulator.c
+++ b/drivers/regulator/pca9450-regulator.c
@@ -106,6 +106,14 @@ static const struct linear_range pca9450_dvs_buck_volts[] = {
REGULATOR_LINEAR_RANGE(600000, 0x00, 0x7F, 12500),
};
+/*
+ * BUCK1/3
+ * 0.65 to 2.2375V (12.5mV step)
+ */
+static const struct linear_range pca9451a_dvs_buck_volts[] = {
+ REGULATOR_LINEAR_RANGE(650000, 0x00, 0x7F, 12500),
+};
+
/*
* BUCK4/5/6
* 0.6V to 3.4V (25mV step)
@@ -662,6 +670,178 @@ static const struct pca9450_regulator_desc pca9450bc_regulators[] = {
},
};
+static const struct pca9450_regulator_desc pca9451a_regulators[] = {
+ {
+ .desc = {
+ .name = "buck1",
+ .of_match = of_match_ptr("BUCK1"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK1,
+ .ops = &pca9450_dvs_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK1_VOLTAGE_NUM,
+ .linear_ranges = pca9451a_dvs_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9451a_dvs_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK1OUT_DVS0,
+ .vsel_mask = BUCK1OUT_DVS0_MASK,
+ .enable_reg = PCA9450_REG_BUCK1CTRL,
+ .enable_mask = BUCK1_ENMODE_MASK,
+ .enable_val = BUCK_ENMODE_ONREQ,
+ .ramp_mask = BUCK1_RAMP_MASK,
+ .ramp_delay_table = pca9450_dvs_buck_ramp_table,
+ .n_ramp_values = ARRAY_SIZE(pca9450_dvs_buck_ramp_table),
+ .owner = THIS_MODULE,
+ .of_parse_cb = pca9450_set_dvs_levels,
+ },
+ .dvs = {
+ .run_reg = PCA9450_REG_BUCK1OUT_DVS0,
+ .run_mask = BUCK1OUT_DVS0_MASK,
+ .standby_reg = PCA9450_REG_BUCK1OUT_DVS1,
+ .standby_mask = BUCK1OUT_DVS1_MASK,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck2",
+ .of_match = of_match_ptr("BUCK2"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK2,
+ .ops = &pca9450_dvs_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK2_VOLTAGE_NUM,
+ .linear_ranges = pca9450_dvs_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_dvs_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK2OUT_DVS0,
+ .vsel_mask = BUCK2OUT_DVS0_MASK,
+ .enable_reg = PCA9450_REG_BUCK2CTRL,
+ .enable_mask = BUCK2_ENMODE_MASK,
+ .enable_val = BUCK_ENMODE_ONREQ_STBYREQ,
+ .ramp_mask = BUCK2_RAMP_MASK,
+ .ramp_delay_table = pca9450_dvs_buck_ramp_table,
+ .n_ramp_values = ARRAY_SIZE(pca9450_dvs_buck_ramp_table),
+ .owner = THIS_MODULE,
+ .of_parse_cb = pca9450_set_dvs_levels,
+ },
+ .dvs = {
+ .run_reg = PCA9450_REG_BUCK2OUT_DVS0,
+ .run_mask = BUCK2OUT_DVS0_MASK,
+ .standby_reg = PCA9450_REG_BUCK2OUT_DVS1,
+ .standby_mask = BUCK2OUT_DVS1_MASK,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck4",
+ .of_match = of_match_ptr("BUCK4"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK4,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK4_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK4OUT,
+ .vsel_mask = BUCK4OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK4CTRL,
+ .enable_mask = BUCK4_ENMODE_MASK,
+ .enable_val = BUCK_ENMODE_ONREQ,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck5",
+ .of_match = of_match_ptr("BUCK5"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK5,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK5_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK5OUT,
+ .vsel_mask = BUCK5OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK5CTRL,
+ .enable_mask = BUCK5_ENMODE_MASK,
+ .enable_val = BUCK_ENMODE_ONREQ,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "buck6",
+ .of_match = of_match_ptr("BUCK6"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_BUCK6,
+ .ops = &pca9450_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_BUCK6_VOLTAGE_NUM,
+ .linear_ranges = pca9450_buck_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_buck_volts),
+ .vsel_reg = PCA9450_REG_BUCK6OUT,
+ .vsel_mask = BUCK6OUT_MASK,
+ .enable_reg = PCA9450_REG_BUCK6CTRL,
+ .enable_mask = BUCK6_ENMODE_MASK,
+ .enable_val = BUCK_ENMODE_ONREQ,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo1",
+ .of_match = of_match_ptr("LDO1"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO1,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO1_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo1_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo1_volts),
+ .vsel_reg = PCA9450_REG_LDO1CTRL,
+ .vsel_mask = LDO1OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO1CTRL,
+ .enable_mask = LDO1_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo4",
+ .of_match = of_match_ptr("LDO4"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO4,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO4_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo34_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo34_volts),
+ .vsel_reg = PCA9450_REG_LDO4CTRL,
+ .vsel_mask = LDO4OUT_MASK,
+ .enable_reg = PCA9450_REG_LDO4CTRL,
+ .enable_mask = LDO4_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+ {
+ .desc = {
+ .name = "ldo5",
+ .of_match = of_match_ptr("LDO5"),
+ .regulators_node = of_match_ptr("regulators"),
+ .id = PCA9450_LDO5,
+ .ops = &pca9450_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = PCA9450_LDO5_VOLTAGE_NUM,
+ .linear_ranges = pca9450_ldo5_volts,
+ .n_linear_ranges = ARRAY_SIZE(pca9450_ldo5_volts),
+ .vsel_reg = PCA9450_REG_LDO5CTRL_H,
+ .vsel_mask = LDO5HOUT_MASK,
+ .enable_reg = PCA9450_REG_LDO5CTRL_H,
+ .enable_mask = LDO5H_EN_MASK,
+ .owner = THIS_MODULE,
+ },
+ },
+};
+
static irqreturn_t pca9450_irq_handler(int irq, void *data)
{
struct pca9450 *pca9450 = data;
@@ -729,6 +909,10 @@ static int pca9450_i2c_probe(struct i2c_client *i2c)
regulator_desc = pca9450bc_regulators;
pca9450->rcnt = ARRAY_SIZE(pca9450bc_regulators);
break;
+ case PCA9450_TYPE_PCA9451A:
+ regulator_desc = pca9451a_regulators;
+ pca9450->rcnt = ARRAY_SIZE(pca9451a_regulators);
+ break;
default:
dev_err(&i2c->dev, "Unknown device type");
return -EINVAL;
@@ -755,7 +939,8 @@ static int pca9450_i2c_probe(struct i2c_client *i2c)
/* Check your board and dts for match the right pmic */
if (((device_id >> 4) != 0x1 && type == PCA9450_TYPE_PCA9450A) ||
- ((device_id >> 4) != 0x3 && type == PCA9450_TYPE_PCA9450BC)) {
+ ((device_id >> 4) != 0x3 && type == PCA9450_TYPE_PCA9450BC) ||
+ ((device_id >> 4) != 0x9 && type == PCA9450_TYPE_PCA9451A)) {
dev_err(&i2c->dev, "Device id(%x) mismatched\n",
device_id >> 4);
return -EINVAL;
@@ -846,7 +1031,8 @@ static int pca9450_i2c_probe(struct i2c_client *i2c)
}
dev_info(&i2c->dev, "%s probed.\n",
- type == PCA9450_TYPE_PCA9450A ? "pca9450a" : "pca9450bc");
+ type == PCA9450_TYPE_PCA9450A ? "pca9450a" :
+ (type == PCA9450_TYPE_PCA9451A ? "pca9451a" : "pca9450bc"));
return 0;
}
@@ -864,6 +1050,10 @@ static const struct of_device_id pca9450_of_match[] = {
.compatible = "nxp,pca9450c",
.data = (void *)PCA9450_TYPE_PCA9450BC,
},
+ {
+ .compatible = "nxp,pca9451a",
+ .data = (void *)PCA9450_TYPE_PCA9451A,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, pca9450_of_match);
diff --git a/include/linux/regulator/pca9450.h b/include/linux/regulator/pca9450.h
index 505c908dbb81..243633c8dceb 100644
--- a/include/linux/regulator/pca9450.h
+++ b/include/linux/regulator/pca9450.h
@@ -9,6 +9,7 @@
enum pca9450_chip_type {
PCA9450_TYPE_PCA9450A = 0,
PCA9450_TYPE_PCA9450BC,
+ PCA9450_TYPE_PCA9451A,
PCA9450_TYPE_AMOUNT,
};
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 3/3] arm64: dts: imx93-11x11-evk: add pca9451a support
From: Joy Zou @ 2024-03-20 6:28 UTC (permalink / raw)
To: frank.li, ping.bai, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer
Cc: kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel, imx
In-Reply-To: <20240320062849.1321423-1-joy.zou@nxp.com>
Support pca9451a on imx93-11x11-evk.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v6:
1.Change the reg to the second property.
Changes in v5:
1.adjust gpio@22 to the front of pmic@25.
Changes in v4:
1. modify the comment for uSDHC but not i2c.
Changes in v3:
1. modify the voltages constraints according to the imx93 datasheet.
---
.../boot/dts/freescale/imx93-11x11-evk.dts | 111 ++++++++++++++++++
1 file changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
index 9921ea13ab48..07e85a30a25f 100644
--- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
@@ -183,6 +183,104 @@ &wdog3 {
status = "okay";
};
+&lpi2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_lpi2c2>;
+ pinctrl-1 = <&pinctrl_lpi2c2>;
+ status = "okay";
+
+ pcal6524: gpio@22 {
+ compatible = "nxp,pcal6524";
+ reg = <0x22>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcal6524>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pmic@25 {
+ compatible = "nxp,pca9451a";
+ reg = <0x25>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <610000>;
+ regulator-max-microvolt = <950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <670000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck4: BUCK4{
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5{
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <1060000>;
+ regulator-max-microvolt = <1140000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <840000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
&iomuxc {
pinctrl_eqos: eqosgrp {
fsl,pins = <
@@ -238,6 +336,19 @@ MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
>;
};
+ pinctrl_lpi2c2: lpi2c2grp {
+ fsl,pins = <
+ MX93_PAD_I2C2_SCL__LPI2C2_SCL 0x40000b9e
+ MX93_PAD_I2C2_SDA__LPI2C2_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_pcal6524: pcal6524grp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
+ >;
+ };
+
/* need to config the SION for data and cmd pad, refer to ERR052021 */
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
--
2.37.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] mediatek: dsi: Add dsi per-frame lp code for mt8188
From: CK Hu (胡俊光) @ 2024-03-20 6:03 UTC (permalink / raw)
To: Shuijing Li (李水静), chunkuang.hu@kernel.org,
Jitao Shi (石记涛), daniel@ffwll.ch,
p.zabel@pengutronix.de, airlied@gmail.com, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240314094238.3315-1-shuijing.li@mediatek.com>
Hi, Shuijing:
Add 'drm/' in the title.
On Thu, 2024-03-14 at 17:41 +0800, Shuijing Li wrote:
> Adding the per-frame lp function of mt8188, which can keep HFP in HS
> and
> reduce the time required for each line to enter and exit low power.
> Per Frame LP:
> |<----------One Active Frame-------->|
> --______________________________________----___________________
> ^HSA+HBP^^RGB^^HFP^^HSA+HBP^^RGB^^HFP^ ^HSA+HBP^^RGB^^HFP^
>
> Per Line LP:
> |<---------------One Active Frame----------->|
> --______________--______________--______________----______________
> ^HSA+HBP^^RGB^ ^HSA+HBP^^RGB^ ^HSA+HBP^^RGB^ ^HSA+HBP^^RGB^
As I know, some low power mode would has some side effect. For example,
CPU dvfs would let CPU run in low frequency when CPU is idle, but when
CPU is suddenly busy, it would take some time to let CPU frequency
speed up and may cause some real time issue. Does this have any side
effect. If so, please describe it.
>
> Signed-off-by: Shuijing Li <shuijing.li@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 100
> +++++++++++++++++++++++++++++
> 1 file changed, 100 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index a2fdfc8ddb15..e6f4807c8711 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -83,6 +83,7 @@
> #define DSI_HSA_WC 0x50
> #define DSI_HBP_WC 0x54
> #define DSI_HFP_WC 0x58
> +#define DSI_BLLP_WC 0x5C
>
> #define DSI_CMDQ_SIZE 0x60
> #define CMDQ_SIZE 0x3f
> @@ -180,6 +181,7 @@ struct mtk_dsi_driver_data {
> bool has_shadow_ctl;
> bool has_size_ctl;
> bool cmdq_long_packet_ctl;
> + bool support_per_frame_lp;
> };
>
> struct mtk_dsi {
> @@ -516,6 +518,103 @@ static void mtk_dsi_config_vdo_timing(struct
> mtk_dsi *dsi)
> (vm->hactive * dsi_tmp_buf_bpp + 2) % dsi-
> >lanes;
> }
>
> + if (dsi->driver_data->support_per_frame_lp) {
> + unsigned int lpx = 0, da_hs_exit = 0, da_hs_prep = 0,
> da_hs_trail = 0;
> + unsigned int da_hs_zero = 0, ps_wc = 0, hs_vb_ps_wc =
> 0;
It's not necessary to initialize to zero because these variable would
be assigned to other value later.
> + u32 bllp_wc, bllp_en, v_active_roundup, hstx_cklp_wc;
> + u32 hstx_cklp_wc_max, hstx_cklp_wc_min;
> +
> + da_hs_trail = (readl(dsi->regs + DSI_PHY_TIMECON0) >>
> 24) & 0xff;
operator '>>' has higher priority than operator '&', so it's not
necessary to add '()'.
> + bllp_en = (readl(dsi->regs + DSI_TXRX_CTRL) >> 7) &
> 0x1;
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) {
> + horizontal_sync_active_byte =
> + (vm->hsync_len * dsi_tmp_buf_bpp - 10);
'()' is redundant.
> + horizontal_backporch_byte =
> + (vm->hback_porch * dsi_tmp_buf_bpp -
> 10);
ditto.
> + horizontal_frontporch_byte =
> + (vm->hfront_porch * dsi_tmp_buf_bpp -
> 12);
ditto.
> +
> + ps_wc = readl(dsi->regs + DSI_PSCTRL) & 0x7fff;
> + v_active_roundup = (32 +
> horizontal_sync_active_byte +
> + horizontal_backporch_byte + ps_wc +
> + horizontal_frontporch_byte) % dsi-
> >lanes;
> + if (v_active_roundup)
> + horizontal_backporch_byte =
> horizontal_backporch_byte +
> + dsi->lanes - v_active_roundup;
> + hstx_cklp_wc_min = (DIV_ROUND_UP((12 + 2 + 4 +
> + horizontal_sync_active_byte), dsi-
> >lanes) + da_hs_trail + 1)
> + * dsi->lanes / 6 - 1;
> + hstx_cklp_wc_max = (DIV_ROUND_UP((20 + 6 + 4 +
> + horizontal_sync_active_byte +
> horizontal_backporch_byte +
> + ps_wc), dsi->lanes) + da_hs_trail + 1)
> * dsi->lanes / 6 - 1;
> + } else {
> + horizontal_sync_active_byte = vm->hsync_len *
> dsi_tmp_buf_bpp - 4;
> +
> + horizontal_backporch_byte = (vm->hback_porch +
> vm->hsync_len) *
> + dsi_tmp_buf_bpp - 10;
> + hstx_cklp_wc_min = (DIV_ROUND_UP(4, dsi->lanes)
> + da_hs_trail + 1)
> + * dsi->lanes / 6 - 1;
> +
> + if (dsi->mode_flags &
> MIPI_DSI_MODE_VIDEO_BURST) {
> + ps_wc = readl(dsi->regs + DSI_PSCTRL) &
> 0x7fff;
> + bllp_wc = readl(dsi->regs +
> DSI_BLLP_WC) & 0xfff;
> + horizontal_frontporch_byte = (vm-
> >hfront_porch *
> + dsi_tmp_buf_bpp - 18);
> +
> + v_active_roundup = (28 +
> horizontal_backporch_byte + ps_wc +
> + horizontal_frontporch_byte +
> bllp_wc) % dsi->lanes;
> + if (v_active_roundup)
> + horizontal_backporch_byte =
> horizontal_backporch_byte +
> + dsi->lanes - v_active_roundup;
> + if (bllp_en) {
> + hstx_cklp_wc_max =
> (DIV_ROUND_UP((16 + 6 + 4 +
> + horizontal_backporch_by
> te + bllp_wc + ps_wc),
> + dsi->lanes) +
> da_hs_trail + 1) * dsi->lanes / 6 - 1;
> + } else {
> + hstx_cklp_wc_max =
> (DIV_ROUND_UP((12 + 4 + 4 +
> + horizontal_backporch_by
> te + bllp_wc + ps_wc),
> + dsi->lanes) +
> da_hs_trail + 1) * dsi->lanes / 6 - 1;
> + }
> + } else {
> + ps_wc = readl(dsi->regs + DSI_PSCTRL) &
> 0x7fff;
> + horizontal_frontporch_byte = (vm-
> >hfront_porch *
> + dsi_tmp_buf_bpp - 12);
> +
> + v_active_roundup = (22 +
> horizontal_backporch_byte + ps_wc +
> + horizontal_frontporch_byte) %
> dsi->lanes;
> + if (v_active_roundup)
> + horizontal_backporch_byte =
> horizontal_backporch_byte +
> + dsi->lanes - v_active_roundup;
> +
> + hstx_cklp_wc_max = (DIV_ROUND_UP((12 +
> 4 + 4 +
> + horizontal_backporch_byte +
> ps_wc),
> + dsi->lanes) + da_hs_trail + 1)
> * dsi->lanes / 6 - 1;
> + }
> + }
> + hstx_cklp_wc = (readl(dsi->regs + DSI_HSTX_CKL_WC) >>
> 2) & 0x3fff;
Hardware register is set according to software variable, so you could
get this value from software variable. DSI_HSTX_CKL_WC is set in
mtk_dsi_ps_control_vact() as ps_wc, so you could use ps_wc instead of
read it back from register.
Regards,
CK
> + if (hstx_cklp_wc <= hstx_cklp_wc_min ||
> + hstx_cklp_wc >= hstx_cklp_wc_max) {
> + hstx_cklp_wc = (hstx_cklp_wc_max / 2) << 2;
> + writel(hstx_cklp_wc, dsi->regs +
> DSI_HSTX_CKL_WC);
> + }
> + hstx_cklp_wc = hstx_cklp_wc >> 2;
> + if (hstx_cklp_wc <= hstx_cklp_wc_min ||
> + hstx_cklp_wc >= hstx_cklp_wc_max) {
> + DRM_WARN("Wrong setting of hstx_ckl_wc\n");
> + }
> +
> + lpx = readl(dsi->regs + DSI_PHY_TIMECON0) & 0xff;
> + da_hs_exit = (readl(dsi->regs + DSI_PHY_TIMECON1) >>
> 24) & 0xff;
> + da_hs_prep = (readl(dsi->regs + DSI_PHY_TIMECON0) >> 8)
> & 0xff;
> + da_hs_zero = (readl(dsi->regs + DSI_PHY_TIMECON0) >>
> 16) & 0xff;
> + ps_wc = readl(dsi->regs + DSI_PSCTRL) & 0x7fff;
> + hs_vb_ps_wc = ps_wc -
> + (lpx + da_hs_exit + da_hs_prep + da_hs_zero +
> 2)
> + * dsi->lanes;
> + horizontal_frontporch_byte = (1 << 31)
> + | (hs_vb_ps_wc << 16)
> + | (horizontal_frontporch_byte);
> + }
> writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
> writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
> writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
> @@ -1246,6 +1345,7 @@ static const struct mtk_dsi_driver_data
> mt8188_dsi_driver_data = {
> .has_shadow_ctl = true,
> .has_size_ctl = true,
> .cmdq_long_packet_ctl = true,
> + .support_per_frame_lp = true,
> };
>
> static const struct of_device_id mtk_dsi_of_match[] = {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: mediatek: vcodec: Handle invalid decoder vsi
From: Irui Wang @ 2024-03-20 6:13 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Matthias Brugger,
Yunfei Dong, angelogioacchino.delregno, nicolas.dufresne,
sebastian.fricke
Cc: Longfei Wang, Maoguang Meng, Irui Wang,
Project_Global_Chrome_Upstream_Group, linux-media, linux-kernel,
linux-arm-kernel, linux-mediatek
Handle invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is
valid for future use.
Signed-off-by: Irui Wang <irui.wang@mediatek.com>
---
.../media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
index 82e57ae983d5..17770993fe5a 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c
@@ -231,6 +231,12 @@ int vpu_dec_init(struct vdec_vpu_inst *vpu)
mtk_vdec_debug(vpu->ctx, "vdec_inst=%p", vpu);
err = vcodec_vpu_send_msg(vpu, (void *)&msg, sizeof(msg));
+
+ if (IS_ERR_OR_NULL(vpu->vsi)) {
+ mtk_vdec_err(vpu->ctx, "invalid vdec vsi, status=%d", err);
+ return -EINVAL;
+ }
+
mtk_vdec_debug(vpu->ctx, "- ret=%d", err);
return err;
}
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] mediatek: dsi: Correct calculation formula of PHY Timing
From: CK Hu (胡俊光) @ 2024-03-20 6:28 UTC (permalink / raw)
To: Shuijing Li (李水静), chunkuang.hu@kernel.org,
Jitao Shi (石记涛), daniel@ffwll.ch,
p.zabel@pengutronix.de, airlied@gmail.com, matthias.bgg@gmail.com,
angelogioacchino.delregno@collabora.com
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240315072945.19502-1-shuijing.li@mediatek.com>
Hi, Shuijing:
On Fri, 2024-03-15 at 15:29 +0800, Shuijing Li wrote:
> This patch correct calculation formula of PHY timing.
> Make actual phy timing more accurate.
Please define what is accurate and how much this patch improve. For
example, the spec define event 2 happen after event 1 and the duration
between event 1 and event 2 should be from 50us to 100us. But current
duration is 60us and is near the boundary. So this patch make the
duration to 70us so it is near the safe range.
Regards,
CK
>
> Signed-off-by: Shuijing Li <shuijing.li@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 33 +++++++++++++++-------------
> --
> 1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index a2fdfc8ddb15..d1bd7d671880 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -235,22 +235,23 @@ static void mtk_dsi_phy_timconfig(struct
> mtk_dsi *dsi)
> u32 data_rate_mhz = DIV_ROUND_UP(dsi->data_rate, 1000000);
> struct mtk_phy_timing *timing = &dsi->phy_timing;
>
> - timing->lpx = (60 * data_rate_mhz / (8 * 1000)) + 1;
> - timing->da_hs_prepare = (80 * data_rate_mhz + 4 * 1000) / 8000;
> - timing->da_hs_zero = (170 * data_rate_mhz + 10 * 1000) / 8000 +
> 1 -
> - timing->da_hs_prepare;
> - timing->da_hs_trail = timing->da_hs_prepare + 1;
> -
> - timing->ta_go = 4 * timing->lpx - 2;
> - timing->ta_sure = timing->lpx + 2;
> - timing->ta_get = 4 * timing->lpx;
> - timing->da_hs_exit = 2 * timing->lpx + 1;
> -
> - timing->clk_hs_prepare = 70 * data_rate_mhz / (8 * 1000);
> - timing->clk_hs_post = timing->clk_hs_prepare + 8;
> - timing->clk_hs_trail = timing->clk_hs_prepare;
> - timing->clk_hs_zero = timing->clk_hs_trail * 4;
> - timing->clk_hs_exit = 2 * timing->clk_hs_trail;
> + timing->lpx = (80 * data_rate_mhz / (8 * 1000)) + 1;
> + timing->da_hs_prepare = (59 * data_rate_mhz + 4 * 1000) / 8000
> + 1;
> + timing->da_hs_zero = (163 * data_rate_mhz + 11 * 1000) / 8000 +
> 1 -
> + timing->da_hs_prepare;
> + timing->da_hs_trail = (78 * data_rate_mhz + 7 * 1000) / 8000 +
> 1;
> +
> + timing->ta_go = 4 * timing->lpx;
> + timing->ta_sure = 3 * timing->lpx / 2;
> + timing->ta_get = 5 * timing->lpx;
> + timing->da_hs_exit = (118 * data_rate_mhz / (8 * 1000)) + 1;
> +
> + timing->clk_hs_prepare = (57 * data_rate_mhz / (8 * 1000)) + 1;
> + timing->clk_hs_post = (65 * data_rate_mhz + 53 * 1000) / 8000 +
> 1;
> + timing->clk_hs_trail = (78 * data_rate_mhz + 7 * 1000) / 8000 +
> 1;
> + timing->clk_hs_zero = (330 * data_rate_mhz / (8 * 1000)) + 1 -
> + timing->clk_hs_prepare;
> + timing->clk_hs_exit = (118 * data_rate_mhz / (8 * 1000)) + 1;
>
> timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
> timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/1] Add interface to allocate MediaTek GEM buffer
From: Shawn Sung @ 2024-03-20 6:40 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Philipp Zabel, David Airlie, Daniel Vetter, Matthias Brugger,
linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel,
Hsiao Chien Sung
From: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
Add an interface to allocate Mediatek GEM buffers, allow the IOCTLs
to be used by render nodes.
This patch also sets the RENDER driver feature.
This patch is:
- Based on 20240320024222.14234-1-shawn.sung@mediatek.com
- Reviewed on https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1955361
CK Hu (1):
drm/mediatek: Add interface to allocate MediaTek GEM buffer.
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16 ++++++-
drivers/gpu/drm/mediatek/mtk_gem.c | 40 ++++++++++++++++
drivers/gpu/drm/mediatek/mtk_gem.h | 11 +++++
include/uapi/drm/mediatek_drm.h | 64 ++++++++++++++++++++++++++
4 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 include/uapi/drm/mediatek_drm.h
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/1] drm/mediatek: Add interface to allocate MediaTek GEM buffer.
From: Shawn Sung @ 2024-03-20 6:40 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Philipp Zabel, David Airlie, Daniel Vetter, Matthias Brugger,
linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, CK Hu,
Hsiao Chien Sung
In-Reply-To: <20240320064043.29780-1-shawn.sung@mediatek.com>
From: CK Hu <ck.hu@mediatek.com>
Add an interface to allocate MediaTek GEM buffers, allow the IOCTLs
to be used by render nodes.
This patch also sets the RENDER driver feature.
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16 ++++++-
drivers/gpu/drm/mediatek/mtk_gem.c | 40 ++++++++++++++++
drivers/gpu/drm/mediatek/mtk_gem.h | 11 +++++
include/uapi/drm/mediatek_drm.h | 64 ++++++++++++++++++++++++++
4 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 include/uapi/drm/mediatek_drm.h
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a671e293a07e1..4710cd8b7288b 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -24,6 +24,7 @@
#include <drm/drm_of.h>
#include <drm/drm_probe_helper.h>
#include <drm/drm_vblank.h>
+#include <drm/mediatek_drm.h>
#include "mtk_crtc.h"
#include "mtk_ddp_comp.h"
@@ -571,6 +572,14 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
component_unbind_all(drm->dev, drm);
}
+static const struct drm_ioctl_desc mtk_ioctls[] = {
+ DRM_IOCTL_DEF_DRV(MTK_GEM_CREATE, mtk_gem_create_ioctl,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(MTK_GEM_MAP_OFFSET,
+ mtk_gem_map_offset_ioctl,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+};
+
DEFINE_DRM_GEM_FOPS(mtk_drm_fops);
/*
@@ -586,12 +595,17 @@ static struct drm_gem_object *mtk_gem_prime_import(struct drm_device *dev,
}
static const struct drm_driver mtk_drm_driver = {
- .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
+ .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC |
+ DRIVER_RENDER,
.dumb_create = mtk_gem_dumb_create,
.gem_prime_import = mtk_gem_prime_import,
.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
+
+ .ioctls = mtk_ioctls,
+ .num_ioctls = ARRAY_SIZE(mtk_ioctls),
+
.fops = &mtk_drm_fops,
.name = DRIVER_NAME,
diff --git a/drivers/gpu/drm/mediatek/mtk_gem.c b/drivers/gpu/drm/mediatek/mtk_gem.c
index f0c3318fd7f5a..e336c253b0f38 100644
--- a/drivers/gpu/drm/mediatek/mtk_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_gem.c
@@ -4,9 +4,11 @@
*/
#include <linux/dma-buf.h>
+#include <drm/mediatek_drm.h>
#include <drm/drm.h>
#include <drm/drm_device.h>
+#include <drm/drm_drv.h>
#include <drm/drm_gem.h>
#include <drm/drm_gem_dma_helper.h>
#include <drm/drm_prime.h>
@@ -282,3 +284,41 @@ void mtk_gem_prime_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
mtk_gem->kvaddr = NULL;
kfree(mtk_gem->pages);
}
+
+int mtk_gem_map_offset_ioctl(struct drm_device *drm, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mtk_gem_map_off *args = data;
+
+ return drm_gem_dumb_map_offset(file_priv, drm, args->handle,
+ &args->offset);
+}
+
+int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct mtk_gem_obj *mtk_gem;
+ struct drm_mtk_gem_create *args = data;
+ int ret;
+
+ mtk_gem = mtk_gem_create(dev, args->size, false);
+ if (IS_ERR(mtk_gem))
+ return PTR_ERR(mtk_gem);
+
+ /*
+ * allocate a id of idr table where the obj is registered
+ * and handle has the id what user can see.
+ */
+ ret = drm_gem_handle_create(file_priv, &mtk_gem->base, &args->handle);
+ if (ret)
+ goto err_handle_create;
+
+ /* drop reference from allocate - handle holds it now. */
+ drm_gem_object_put(&mtk_gem->base);
+
+ return 0;
+
+err_handle_create:
+ mtk_gem_free_object(&mtk_gem->base);
+ return ret;
+}
diff --git a/drivers/gpu/drm/mediatek/mtk_gem.h b/drivers/gpu/drm/mediatek/mtk_gem.h
index 66e5f154f6980..4d7598220ca8f 100644
--- a/drivers/gpu/drm/mediatek/mtk_gem.h
+++ b/drivers/gpu/drm/mediatek/mtk_gem.h
@@ -45,4 +45,15 @@ struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
int mtk_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map);
void mtk_gem_prime_vunmap(struct drm_gem_object *obj, struct iosys_map *map);
+/*
+ * request gem object creation and buffer allocation as the size
+ * that it is calculated with framebuffer information such as width,
+ * height and bpp.
+ */
+int mtk_gem_create_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+
+/* get buffer offset to map to user space. */
+int mtk_gem_map_offset_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
#endif
diff --git a/include/uapi/drm/mediatek_drm.h b/include/uapi/drm/mediatek_drm.h
new file mode 100644
index 0000000000000..b0dea00bacbc4
--- /dev/null
+++ b/include/uapi/drm/mediatek_drm.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _UAPI_MEDIATEK_DRM_H
+#define _UAPI_MEDIATEK_DRM_H
+
+#include <drm/drm.h>
+
+#ifdef __KERNEL__
+#include <linux/types.h>
+#else
+#include <stdint.h>
+#endif
+
+/**
+ * User-desired buffer creation information structure.
+ *
+ * @size: user-desired memory allocation size.
+ * - this size value would be page-aligned internally.
+ * @flags: user request for setting memory type or cache attributes.
+ * @handle: returned a handle to created gem object.
+ * - this handle will be set by gem module of kernel side.
+ */
+struct drm_mtk_gem_create {
+ uint64_t size;
+ uint32_t flags;
+ uint32_t handle;
+};
+
+/**
+ * A structure for getting buffer offset.
+ *
+ * @handle: a pointer to gem object created.
+ * @pad: just padding to be 64-bit aligned.
+ * @offset: relatived offset value of the memory region allocated.
+ * - this value should be set by user.
+ */
+struct drm_mtk_gem_map_off {
+ uint32_t handle;
+ uint32_t pad;
+ uint64_t offset;
+};
+
+#define DRM_MTK_GEM_CREATE 0x00
+#define DRM_MTK_GEM_MAP_OFFSET 0x01
+
+#define DRM_IOCTL_MTK_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_MTK_GEM_CREATE, struct drm_mtk_gem_create)
+
+#define DRM_IOCTL_MTK_GEM_MAP_OFFSET DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_MTK_GEM_MAP_OFFSET, struct drm_mtk_gem_map_off)
+
+#endif /* _UAPI_MEDIATEK_DRM_H */
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 5/8] drm: zynqmp_dp: Don't retrain the link in our IRQ
From: Tomi Valkeinen @ 2024-03-20 6:53 UTC (permalink / raw)
To: Sean Anderson
Cc: Michal Simek, David Airlie, linux-kernel, Daniel Vetter,
linux-arm-kernel, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, dri-devel
In-Reply-To: <20240319225122.3048400-6-sean.anderson@linux.dev>
On 20/03/2024 00:51, Sean Anderson wrote:
> Retraining the link can take a while, and might involve waiting for
> DPCD reads/writes to complete. This is inappropriate for an IRQ handler.
> Just schedule this work for later completion. This is racy, but will be
> fixed in the next commit.
You should add the locks first, and use them here, rather than first
adding a buggy commit and fixing it in the next one.
> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
> ---
> Actually, on second look this IRQ is threaded. So why do we have a
> workqueue for HPD events? Maybe we should make it unthreaded?
Indeed, there's not much work being done in the IRQ handler. I don't
know why it's threaded.
We could move the queued work to be inside the threaded irq handler, but
with a quick look, the HPD work has lines like "msleep(100)" (and that's
inside a for loop...), which is probably not a good thing to do even in
threaded irq handler.
Although I'm not sure if that code is good to have anywhere. Why do we
even have such code in the HPD work path... We already got the HPD
interrupt. What does "It takes some delay (ex, 100 ~ 500 msec) to get
the HPD signal with some monitors" even mean...
Would it be possible to clean up the work funcs a bit (I haven't looked
a the new work func yet), to remove the worst extra sleeps, and just do
all that inside the threaded irq handler?
Do we need to handle interrupts while either delayed work is being done?
If we do need a delayed work, would just one work be enough which
handles both HPD_EVENT and HPD_IRQ, instead of two?
Tomi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: S32G3: Introduce device tree for S32G-VNP-RDB3
From: Ghennadi Procopciuc @ 2024-03-20 7:00 UTC (permalink / raw)
To: Wadim Mueller
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Jiri Slaby, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Alexander Stein, Marek Vasut,
Gregor Herburger, Marco Felsch, Joao Paulo Goncalves,
Markus Niebel, Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Josua Mayer, Yannic Moog, Li Yang, devicetree, linux-kernel,
linux-serial, linux-arm-kernel
In-Reply-To: <20240319221614.56652-2-wafgo01@gmail.com>
On 3/20/24 00:16, Wadim Mueller wrote:
[...]
> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> @@ -0,0 +1,236 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright 2021-2023 NXP
> + *
> + * Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> + * Ciprian Costea <ciprianmarian.costea@nxp.com>
> + * Andra-Teodora Ilie <andra.ilie@nxp.com>
This pollutes the content of the file. Please make them part of the
commit description using 'Signed-off-by' tags.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
Missing empty line ?
> +/ {
> + compatible = "nxp,s32g3";
> + interrupt-parent = <&gic>;
> + #address-cells = <0x02>;
> + #size-cells = <0x02>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> +
> + core1 {
> + cpu = <&cpu1>;
> + };
> +
> + core2 {
> + cpu = <&cpu2>;
> + };
> +
> + core3 {
> + cpu = <&cpu3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&cpu4>;
> + };
> +
> + core1 {
> + cpu = <&cpu5>;
> + };
> +
> + core2 {
> + cpu = <&cpu6>;
> + };
> +
> + core3 {
> + cpu = <&cpu7>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0>;
> + enable-method = "psci";
> + clocks = <&dfs 0>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + enable-method = "psci";
> + clocks = <&dfs 0>;
> + };
> +
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x2>;
> + enable-method = "psci";
> + clocks = <&dfs 0>;
> + };
> +
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x3>;
> + enable-method = "psci";
> + clocks = <&dfs 0>;
> + };
> +
> + cpu4: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x100>;
> + enable-method = "psci";
> + clocks = <&dfs 0>;
> + };
> +
> + cpu5: cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x101>;
> + enable-method = "psci";
> + clocks = <&dfs 0>;
> + };
> +
> + cpu6: cpu@102 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x102>;
> + enable-method = "psci";
> + clocks = <&dfs 0>;
> + };
> +
> + cpu7: cpu@103 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x103>;
> + enable-method = "psci";
> + clocks = <&dfs 0>;
> + };
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupt-parent = <&gic>;
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* sec-phys */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* virt */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* hyp-virt */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>, /* sec-phys */
> + <GIC_PPI 12 IRQ_TYPE_LEVEL_LOW>; /* phys */
The interrupt order does not seem right.
From drivers/clocksource/arm_arch_timer.c:
static const char *arch_timer_ppi_names[ARCH_TIMER_MAX_TIMER_PPI] = {
[ARCH_TIMER_PHYS_SECURE_PPI] = "sec-phys",
[ARCH_TIMER_PHYS_NONSECURE_PPI] = "phys",
[ARCH_TIMER_VIRT_PPI] = "virt",
[ARCH_TIMER_HYP_PPI] = "hyp-phys",
[ARCH_TIMER_HYP_VIRT_PPI] = "hyp-virt",
};
[...]
static int __init arch_timer_of_init(struct device_node *np)
{
[...]
for (i = ARCH_TIMER_PHYS_SECURE_PPI; i < ARCH_TIMER_MAX_TIMER_PPI;
i++) {
if (has_names)
irq = of_irq_get_byname(np, arch_timer_ppi_names[i]);
else
irq = of_irq_get(np, i);
if (irq > 0)
arch_timer_ppi[i] = irq;
}
[...]
}
As I understand it, if the names are not provided, then the interrupt
IDs must strictly follow the order specified in the arch_timer_ppi_names
list, which is: sec-phys, phys, virt, hyp-phys, hyp-virt. That is why I
personally prefer using interrupt names instead of the raw list of IDs.
> + arm,no-tick-in-suspend;
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + scmi_shmem: shm@d0000000 {
> + compatible = "arm,scmi-shmem";
> + reg = <0x0 0xd0000000 0x0 0x80>;
> + no-map;
> + };
> + };
> +
> + firmware {
> + scmi: scmi {
> + compatible = "arm,scmi-smc";
> + shmem = <&scmi_shmem>;
> + arm,smc-id = <0xc20000fe>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <GIC_SPI 300 IRQ_TYPE_EDGE_RISING>;
This interrupt is not needed if the RX is not used.
> +
> + dfs: protocol@13 {
> + reg = <0x13>;
> + #clock-cells = <1>;
> + };
> +
> + clks: protocol@14 {
> + reg = <0x14>;
> + #clock-cells = <1>;
> + };
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + soc@0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0 0x80000000>;
> +
> + uart0: serial@401c8000 {
> + compatible = "nxp,s32g3-linflexuart",
From 'Submitting Devicetree (DT) binding patches' [0]:
5. The Documentation/ portion of the patch should come in the series
before the code implementing the binding.
> + "fsl,s32v234-linflexuart";
> + reg = <0x401c8000 0x3000>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
> + };
Krzysztof, would it make sense to factor the common part of the s32g3
and s32g2 into a new dtsi file (e.g. s32g.dtsi) since both SoCs are part
of the same family and share the memory map with some exceptions?
> +
> + uart1: serial@401cc000 {
> + compatible = "nxp,s32g3-linflexuart",
> + "fsl,s32v234-linflexuart";
> + reg = <0x401cc000 0x3000>;
> + interrupts = <GIC_SPI 83 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
> + };
> +
> + uart2: serial@402bc000 {
> + compatible = "nxp,s32g3-linflexuart",
> + "fsl,s32v234-linflexuart";
> + reg = <0x402bc000 0x3000>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
> + };
> +
> + gic: interrupt-controller@50800000 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x50800000 0x10000>,
> + <0x50900000 0x200000>,
> + <0x50400000 0x2000>,
> + <0x50410000 0x2000>,
> + <0x50420000 0x2000>;
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + usdhc0: mmc@402f0000 {
> + compatible = "nxp,s32g2-usdhc";
Is there a reason why the UART uses an S32G3 specific compatible string,
but the SD does not?
> + reg = <0x402f0000 0x1000>;
> + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 32>,
> + <&clks 31>,
> + <&clks 33>;
> + clock-names = "ipg", "ahb", "per";
> + status = "disabled";
> + };
Missing bus-width = <8> ?
> + };
> +};
> diff --git a/arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts b/arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts
> new file mode 100644
> index 000000000000..199605b28df3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/s32g399a-rdb3.dts
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright 2021-2023 NXP
> + *
> + * NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3)
> + */
> +
> +/dts-v1/;
> +
> +#include "s32g3.dtsi"
> +
> +/ {
> + model = "NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3)";
> + compatible = "nxp,s32g399a-rdb3", "nxp,s32g3";
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + /* 4GiB RAM */
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x0 0x80000000 0 0x80000000>,
> + <0x8 0x80000000 0 0x80000000>;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&usdhc0 {
> + status = "okay";
> +}
[0]
https://docs.kernel.org/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
Regards,
Ghennadi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: renesas: Add more TMU support
From: Wolfram Sang @ 2024-03-20 7:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Niklas Söderlund, linux-renesas-soc,
linux-arm-kernel
In-Reply-To: <cover.1710864964.git.geert+renesas@glider.be>
[-- Attachment #1.1: Type: text/plain, Size: 405 bytes --]
Hi Geert,
> APE6 (APE6EVM), and on R-Car H2 (Lager) and M2-W (Koelsch), except for
> TMU3 on M2-W, which consistently fails the CLOCK_REALTIME test (why?).
Huh? It works on Lager and fails on Koelsch? Do you have a log file?
> Still to be queued in renesas-devel for v6.10?
I'd say yes, it still describes the HW. Unless it turns out that M2-W
doesn't really have TMU3 ;)
Happy hacking,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox