On 6/27/21 3:56 AM, Linus Walleij wrote:

Hi Dipen,

thanks a lot for this very interesting patch set!

I'm gonna try to review properly, just pointing out some conceptual
things to begin with. Bindings is a good place to start.

On Sat, Jun 26, 2021 at 1:48 AM Dipen Patel [off-list ref] wrote:

quoted

+description: |
+  HTE properties should be named "htes". The exact meaning of each htes
+  property must be documented in the device tree binding for each device.
+  An optional property "hte-names" may contain a list of strings to label
+  each of the HTE devices listed in the "htes" property.

I think this is a bit over-abbreviated. IIO has:
io-channels =...
io-channel-names =...

Given DT:s infatuation with using english plural I would opt for:
hardware-timestamps = ..
hardware-timestamp-names = ...

I can change it to suggested names in next RFC series.

The "engine" part is a bit of an nVidia:ism I think and a too generic
term. Could as well be "processor" or "automata" but nVidia just
happened to name it an engine. (DMA engine would be a precedent
though, so no hard preference from my side.)

When reading this it is pretty intuitively evident what is going on.

Other than that it looks really good!

quoted

+++ b/Documentation/devicetree/bindings/hte/hte.yaml

I would name this hardware-timestamp-common.yamp or so.

Sure, but do I have to change hte-consumer and other hte named

yaml as well in this directory? If yes, I am referring HTE everywhere  in the

code (framework is named as hte itself), I hope that is fine and does not

create any confusion.

quoted

+title: HTE providers

Spell this out: Hardware timestamp providers

Can I do hardware timestamp engine provider instead?

quoted

+properties:
+  $nodename:
+    pattern: "^hte(@.*|-[0-9a-f])*$"

Likewise:
hardware-timestamp@ ...

I think this is good because it is very unambiguous.

quoted

+examples:
+  - |
+    tegra_hte_aon: hte@c1e0000 {
+              compatible = "nvidia,tegra194-gte-aon";
+              reg = <0xc1e0000 0x10000>;
+              interrupts = <0 13 0x4>;
+              int-threshold = <1>;
+              slices = <3>;
+              #hte-cells = <1>;
+    };

The examples can be kept to the tegra194 bindings I think, this
generic binding doesn't need an example as such.

Ok, will remove it.

quoted

+$id: http://devicetree.org/schemas/hte/nvidia,tegra194-hte.yaml#

This one should be named like this, that is great.

quoted

+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tegra194 on chip generic hardware timestamping engine (HTE)

This is clear and nice.

quoted

+  int-threshold:
+    description:
+      HTE device generates its interrupt based on this u32 FIFO threshold
+      value. The recommended value is 1.
+    minimum: 1
+    maximum: 256

Does this mean a single timestamp in the FIFO will generate an IRQ?
Then spell that out so it is clear.

In the description I said that.

quoted

+  slices:
+   description:
+    HTE lines are arranged in 32 bit slice where each bit represents different
+    line/signal that it can enable/configure for the timestamp. It is u32
+    property and depends on the HTE instance in the chip.
+   oneOf:
+    - items:
+        - const: 3
+    - items:
+        - const: 11

Can't you just use
enum: [3, 11]
?

Sure, will change it.

quoted

+  '#hte-cells':
+    const: 1

So IMO this would be something like
#hardware-timestamp-cells

Sure.

Other than this it overall looks very nice to me!

Yours,
Linus Walleij