Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.112.34 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.112.34; helo=mail.nvidia.com;
Subject: Re: [RFC 04/11] dt-bindings: Add HTE bindings
To:     Linus Walleij <linus.walleij@linaro.org>
CC:     "thierry.reding@gmail.com" <thierry.reding@gmail.com>,
        Jon Hunter <jonathanh@nvidia.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-tegra <linux-tegra@vger.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Kent Gibson <warthog618@gmail.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        Linux Doc Mailing List <linux-doc@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>
References: <20210625235532.19575-1-dipenp@nvidia.com>
 <20210625235532.19575-5-dipenp@nvidia.com>
 <CACRpkdbazcGqapWMLnj8=UShU0j002SkKRTxgpprfDeaP_nAQQ@mail.gmail.com>
From:   Dipen Patel <dipenp@nvidia.com>
Message-ID: <4b313c41-2b1b-8498-e5dd-1f82b939fa6c@nvidia.com>
Date:   Thu, 29 Jul 2021 18:32:05 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CACRpkdbazcGqapWMLnj8=UShU0j002SkKRTxgpprfDeaP_nAQQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jul 2021 01:23:06.3380
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e6af2362-34a5-482c-f0da-08d952f89596
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.112.34];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT058.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3998
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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 <dipenp@nvidia.com> wrote:
>
>> +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!
>
>> +++ 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.

>
>> +title: HTE providers
> Spell this out: Hardware timestamp providers
Can I do hardware timestamp engine provider instead?
>
>> +properties:
>> +  $nodename:
>> +    pattern: "^hte(@.*|-[0-9a-f])*$"
> Likewise:
> hardware-timestamp@ ...
>
> I think this is good because it is very unambiguous.
>
>> +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.
>
>> +$id: http://devicetree.org/schemas/hte/nvidia,tegra194-hte.yaml#
> This one should be named like this, that is great.
>
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Tegra194 on chip generic hardware timestamping engine (HTE)
> This is clear and nice.
>
>> +  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.
>
>> +  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.
>
>> +  '#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