On 16/02/2024 13:27, Laurent Pinchart wrote:
On Fri, Feb 16, 2024 at 01:09:15PM +0000, Daniel Scally wrote:
On 15/02/2024 11:02, Laurent Pinchart wrote:
On Wed, Feb 14, 2024 at 05:37:17PM +0000, Conor Dooley wrote:
On Wed, Feb 14, 2024 at 04:28:25PM +0200, Laurent Pinchart wrote:
On Wed, Feb 14, 2024 at 02:19:03PM +0000, Daniel Scally wrote:
Add the yaml binding for ARM's Mali-C55 Image Signal Processor.
Acked-by: Nayden Kanchev <nayden.kanchev@xxxxxxx>
Signed-off-by: Daniel Scally <dan.scally@xxxxxxxxxxxxxxxx>
---
Changes in v2:
- Added clocks information
- Fixed the warnings raised by Rob
.../bindings/media/arm,mali-c55.yaml | 77 +++++++++++++++++++
1 file changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/arm,mali-c55.yaml
diff --git a/Documentation/devicetree/bindings/media/arm,mali-c55.yaml b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
new file mode 100644
index 000000000000..30038cfec3a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/arm,mali-c55.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Mali-C55 Image Signal Processor
+
+maintainers:
+ - Daniel Scally <dan.scally@xxxxxxxxxxxxxxxx>
+ - Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx>
+
+properties:
+ compatible:
+ const: arm,mali-c55
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: ISP video clock
I wonder if we need this clock. Granted, it's an input clock to the ISP,
but it's part of the input video bus. I don't expect anyone would ever
need to control it manually, it should be provided by the video source
automatically.
I'd say that if there's a clock controller providing this clock, even if
it is implicit in the video feed it's good to have here. Being able to
increment the refcount on that clock would be good, even if you don't
actually control it manually?
I don't expect there would be a clock controller to directly reference
in most cases. It depends a bit on where the clock domain crossing
between the source (often a CSI-2 receiver) and the ISP is. If it's
implemented in glue logic bundled with the ISP, which wouldn't be
described in DT as a separate node, then there's a higher chance we'll
have a clock controller for vclk. If it's implemented in the source,
vclk will just come from the source, which won't be listed as a clock
controller.
One option would be to make this clock optional, by moving it to the end
of the clocks list, and setting
minItems: 2
maxItems: 3
+ - description: ISP AXI clock
+ - description: ISP AHB-lite clock
These two other clocks look good to me.
+
+ clock-names:
+ items:
+ - const: vclk
+ - const: aclk
+ - const: hclk
Why not "video" "axi" "ahb-lite"? There's 3 useful letters between the
tree clock names you've provided - they're all clocks, so having "clk"
in them is just noise :)
As far as I understand, the names proposed by Dan come directly from the
IP core documentation.
This is the case, but I do take Conor's point that more descriptive names might be nicer - if I'm
honest I just didn't think about it particularly given "Xclk" is such a common name for them
already, but having been poked into thinking about it I do agree.
Isn't the usual practice in DT bindings is to name GPIOs, clocks and reset
signals based on the hardware documentation ?
Ah - I don't know honestly. If that's so then yeah - these are the names the documentation prescribes.
