On Wed, Dec 15, 2021, at 09:28, Martin Povišer wrote:

quoted

On 15. 12. 2021, at 0:53, Rob Herring [off-list ref] wrote:

On Tue, Dec 14, 2021 at 2:08 PM Martin Povišer [off-list ref] wrote:

quoted

Hi Rob,

quoted

On 14. 12. 2021, at 16:40, Rob Herring [off-list ref] wrote:

On Tue, Dec 14, 2021 at 12:02:48PM +0000, Martin Povišer wrote:

quoted

The NCO block found on Apple SoCs is a programmable clock generator
performing fractional division of a high frequency input clock.

Signed-off-by: Martin Povišer <redacted>
---
.../devicetree/bindings/clock/apple,nco.yaml  | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/apple,nco.yaml

diff --git a/Documentation/devicetree/bindings/clock/apple,nco.yaml b/Documentation/devicetree/bindings/clock/apple,nco.yaml
new file mode 100644
index 000000000000..5029824ab179
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/apple,nco.yaml

@@ -0,0 +1,70 @@

quoted

quoted

+
+  apple,nchannels:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      The number of output channels the NCO block has been
+      synthesized for.

I'd assume there is some max number?

There might be some limit to the underlying IP but we wouldn’t know.
What we know about the hardware comes from blackbox reversing, and that
doesn't suggest a particular limit to the number of channels we might
see on the SoC block in future.

All the more reason to not put the size in the DT, but imply from the
compatible. Unless it varies by instance...

Though I guess you would need DT updates anyways to use the new clock.

quoted

quoted

Do you really need to know this? If this is just to validate the clock
cell values are less than this, then just drop that and the property.
It's not the kernel's job to validate the DT.

Well strictly speaking the driver could do clock registration on-demand
at the cost of additional book-keeping, in which case we could drop
the property, but I would prefer we don’t do that. Rather than providing
validation the property simplifies drivers.

Another option is calculating the no. of channels from size of the reg
range, but I assume that’s worse than having the nchannels property.

quoted

quoted

+
+    nco: clock-generator@23b044000 {

clock-controller@...

Okay, will change.

quoted

quoted

+      compatible = "apple,t8103-nco", "apple,nco";
+      reg = <0x3b044000 0x14000>;

You really have 0x14000 worth of registers here because all of that
will be mapped into virtual memory? Doesn't matter so much on 64-bit,
but it did for 32-bit.

There is about 5 registers per channel with 0x4000 stride between them,
blame Apple (or Samsung? I don’t know...).

I would think you could walk the 0x4000 until you hit registers that
behave differently.

The register size / 0x4000 gives you the number of channels, too.

Right now that’s what I am inclined to use in v2.

quoted

Another question, how do you know this is 1 block with N channels vs.
N blocks just happening to be next to each other in the memory map?

We don’t. We only see Apple describe it as such in their devicetree, and
so far for all practical purposes it could be one block.

Fwiw, the Apple device tree cannot be trusted in general. It also pretends
that two IOMMUs that need to programmed identically are a single dive,
sometimes includes MMIO ranges that are much too large and also contains
at least a single "virtual" device that only exists for what I assume
to be a workaround for some XNU quirk(s). (the GPU IOMMU has a separate node
with no MMIO or anything which only attaches a small shim driver that then
calls back into the main GPU driver. That device is also only used from within
that GPU driver.).

Are there any dependencies between these individual channels?
Is there some common initialization required for all of them?

From a quick glance and my uninformed opinion it looks like these are
separate to me. They only all need this LSFR table which could still be
shared.


Sven