On 9/19/2017 1:35 PM, Hans Verkuil wrote:
From: Hans Verkuil <hans.verkuil@xxxxxxxxx>
Document the cec clock binding.
Signed-off-by: Hans Verkuil <hans.verkuil@xxxxxxxxx>
Acked-by: Rob Herring <robh@xxxxxxxxxx>
---
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 06668bca7ffc..4497ae054d49 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -68,6 +68,8 @@ Optional properties:
- adi,disable-timing-generator: Only for ADV7533. Disables the internal timing
generator. The chip will rely on the sync signals in the DSI data lanes,
rather than generate its own timings for HDMI output.
+- clocks: from common clock binding: handle to CEC clock.
It's called "phandle" in the DT speak. :-)
Are you sure the clock specifier would always be absent?
Sorry? I don't understand the question. Did you mean: "can be absent?"?
No, you only say that there'll be the clock phandle only. The clock
specifier may follow the phandle for the clock devices that have
"#clock-cells" prop != 0.
I have to say that I just copy-and-pasted this from other bindings.
:-)
Would this be better?
- clocks: list of clock specifiers, corresponding to entries in
the clock-names property;
Didn't you say that there'll be only one clock, "cec"? If so, there's
gonna be a single clock phandle+specifier pair. They always go in pairs. :-)
- clock-names: from common clock binding: must be "cec".
- clocks: cec clock phandle, corresponding to the clock-names entry.
The clock phandle and specifier.
- clock-names: from common clock binding: must be "cec".
This OK?
Well, you seem to be going in circles, the above was almost the same as
the original prop description...
Regards,
Hans
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
