All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Dipen Patel <dipenp@nvidia.com>
To: Rob Herring <robh@kernel.org>
Cc: thierry.reding@gmail.com, jonathanh@nvidia.com,
	linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-gpio@vger.kernel.org, linus.walleij@linaro.org,
	devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
	timestamp@lists.linux.dev
Subject: Re: [PATCH 4/7] dt-bindings: timestamp: Add Tegra234 support
Date: Tue, 29 Nov 2022 18:55:04 -0800	[thread overview]
Message-ID: <95c4dbcc-899d-ca14-22f1-befa66d84a77@nvidia.com> (raw)
In-Reply-To: <20221107200600.GA1489762-robh@kernel.org>

On 11/7/22 12:06 PM, Rob Herring wrote:
> On Thu, Nov 03, 2022 at 10:45:20AM -0700, Dipen Patel wrote:
>> Added timestamp provider support for the Tegra234 in devicetree
>> bindings.
>>
>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
>> ---
>>  .../timestamp/nvidia,tegra194-hte.yaml        | 44 +++++++++++++++++--
>>  1 file changed, 40 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> index c31e207d1652..158dbe58c49f 100644
>> --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> @@ -4,7 +4,7 @@
>>  $id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml#
>>  $schema: http://devicetree.org/meta-schemas/core.yaml#
>>  
>> -title: Tegra194 on chip generic hardware timestamping engine (HTE)
>> +title: Tegra on chip generic hardware timestamping engine (HTE) provider
>>  
>>  maintainers:
>>    - Dipen Patel <dipenp@nvidia.com>
>> @@ -23,6 +23,8 @@ properties:
>>      enum:
>>        - nvidia,tegra194-gte-aon
>>        - nvidia,tegra194-gte-lic
>> +      - nvidia,tegra234-gte-aon
>> +      - nvidia,tegra234-gte-lic
> 
> How is the h/w in this chip different from the existing one? I'm 
> assuming it must be because you don't have a fallback compatible.
t234-gte-lic has different slices and signal lines it can support. t234-gte-aon
has again different slices and more gpio lines it can support and has
different GTE-GPIO mapping than t194-gte-aon.
> 
>>  
>>    reg:
>>      maxItems: 1
>> @@ -43,9 +45,8 @@ properties:
>>      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. The value 3 is for
>> -      GPIO GTE and 11 for IRQ GTE.
>> -    enum: [3, 11]
>> +      property and the value depends on the HTE instance in the chip.
> 
> If this statement was true, then this property makes sense...
> 
>> +    enum: [3, 11, 17]
>>  
>>    '#timestamp-cells':
>>      description:
>> @@ -55,6 +56,41 @@ properties:
>>        mentioned in the nvidia GPIO device tree binding document.
>>      const: 1
>>  
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra194-gte-aon
>> +              - nvidia,tegra234-gte-aon
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 3
>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra194-gte-lic
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 11
>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra234-gte-lic
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 17
> 
> However, if there is only one possible value for each compatible, then 
> being per instance can't really be true. I guess 'aon' or 'lic' define 
> the instance? That's not normal practice. Are there other differences?
aon and lic are gte hardware instances but meant for different signals i.e.
lic is for interrupt lines while aon is for always on domain GPIO lines.
> 
> It seems like 'nvidia,slices' should be implied from the compatible 
> string.
thats true, assuming we have all those specified compatible strings from this patch.
> 
> Rob


  reply	other threads:[~2022-11-30  2:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 17:45 [PATCH 0/7] Add Tegra234 HTE support Dipen Patel
2022-11-03 17:45 ` [PATCH 1/7] MAINTAINERS: Add HTE/timestamp subsystem details Dipen Patel
2022-11-11 15:59   ` Thierry Reding
2022-11-03 17:45 ` [PATCH 2/7] hte: Add Tegra234 provider Dipen Patel
2022-11-11 16:01   ` Thierry Reding
2022-11-30  3:00     ` Dipen Patel
2022-12-28  0:43       ` Dipen Patel
2023-02-09  9:02         ` Thierry Reding
2022-11-03 17:45 ` [PATCH 3/7] gpio: tegra186: Add Tegra234 hte support Dipen Patel
2022-11-11 16:02   ` Thierry Reding
2022-11-03 17:45 ` [PATCH 4/7] dt-bindings: timestamp: Add Tegra234 support Dipen Patel
2022-11-07 20:06   ` Rob Herring
2022-11-30  2:55     ` Dipen Patel [this message]
2022-11-11 16:04   ` Thierry Reding
2022-11-03 17:45 ` [PATCH 5/7] hte: Re-phrase tegra API document Dipen Patel
2022-11-05  3:33   ` Bagas Sanjaya
2022-11-30  3:34     ` Dipen Patel
2022-11-30  3:43       ` Bagas Sanjaya
2022-11-03 17:45 ` [PATCH 6/7] arm64: tegra: Enable GTE nodes Dipen Patel
2022-11-03 17:45 ` [PATCH 7/7] arm64: defconfig: Enable HTE config Dipen Patel
2022-11-11 15:56 ` [PATCH 0/7] Add Tegra234 HTE support Thierry Reding
  -- strict thread matches above, loose matches on Subject: below --
2022-11-03 17:46 Dipen Patel
2022-11-03 17:46 ` [PATCH 4/7] dt-bindings: timestamp: Add Tegra234 support Dipen Patel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=95c4dbcc-899d-ca14-22f1-befa66d84a77@nvidia.com \
    --to=dipenp@nvidia.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=timestamp@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.