by Krzysztof Kozlowski

[permalink] [raw]

On Mon, Apr 03, 2023 at 09:24:17PM -0700, Dipen Patel wrote:
> On 3/25/23 4:09 AM, Krzysztof Kozlowski wrote:
> > On 24/03/2023 19:51, Dipen Patel wrote:
> >> On 3/24/23 10:13 AM, Rob Herring wrote:
> >>> On Wed, Mar 22, 2023 at 06:29:23PM -0700, Dipen Patel wrote:
> >>>> Introducing nvidia,gpio-controller property from Tegra234 SoCs onwards.
> >>>> This is done to help below case.
> >>>>
> >>>> Without this property code would look like:
> >>>> if (of_device_is_compatible(dev->of_node, "nvidia,tegra194-gte-aon"))
> >>>> hte_dev->c = gpiochip_find("tegra194-gpio-aon",
> >>>> tegra_get_gpiochip_from_name);
> >>>> else if (of_device_is_compatible(dev->of_node, "nvidia,tegra234-gte-aon"))
> >>>> hte_dev->c = gpiochip_find("tegra234-gpio-aon",
> >>>> tegra_get_gpiochip_from_name);
> >>>> else
> >>>> return -ENODEV;
> >>>
> >>> Or you just put the name in match data.
> >>
> >> Not sure I have understood this comment, but "name" the first argument is
> >> already there to supply to callback to match data. Also, this if else is
> >> needed to know which "name" to provide.
> >
> > The point is that of_device_is_compatible() do not really scale and make
> > code more difficult to read. Your variant-customization should in
> > general entirely come from match/driver data.
>
> Perhaps I should not have mentioned driver related details here about how
> this property will help, that detail will go in driver patch. In the next
> patch series I will remove this commit and just focus on what this property
> is.

I think the point that Rob and Krzysztof are trying to make that rather
than adding a new property for this, we can add a const char *gpio field
to struct tegra_hte_data and then set that to the compatible string of
the GPIO controller that we need this for.

To be honest, I slightly prefer the explicit phandle reference, but it
also complicates things a bit and looking up by compatible string isn't
all that bad.

Thierry

Attachments:

(No filename) (1.96 kB)
signature.asc (849.00 B)
Download all attachments

2023-04-04 10:37:26

On 4/4/23 7:24 PM, Bagas Sanjaya wrote:
> On 3/23/23 08:29, Dipen Patel wrote:
>> Make Tegra194 API document generic to make it applicable for
>> current and future tegra hte providers.
>>
>> Signed-off-by: Dipen Patel <[email protected]>
>> ---
>> Documentation/driver-api/hte/tegra194-hte.rst | 33 +++++++++----------
>> 1 file changed, 16 insertions(+), 17 deletions(-)
>>
>
> While generalizing the doc, the doc file name should also be renamed
> (i.e. to tegra-hte.rst).

make sense, I will do rename it in the next patch series.
>
>> diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst
>> index f2d617265546..85e654772782 100644
>> --- a/Documentation/driver-api/hte/tegra194-hte.rst
>> +++ b/Documentation/driver-api/hte/tegra194-hte.rst
>> @@ -5,25 +5,25 @@ HTE Kernel provider driver
>>
>> Description
>> -----------
>> -The Nvidia tegra194 HTE provider driver implements two GTE
>> -(Generic Timestamping Engine) instances: 1) GPIO GTE and 2) LIC
>> -(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the
>> -timestamp from the system counter TSC which has 31.25MHz clock rate, and the
>> -driver converts clock tick rate to nanoseconds before storing it as timestamp
>> -value.
>> +The Nvidia tegra HTE provider also known as GTE (Generic Timestamping Engine)
>> +driver implements two GTE instances: 1) GPIO GTE and 2) LIC
>> +(Legacy Interrupt Controller) IRQ GTE. Both GTE instances get the timestamp
>> +from the system counter TSC which has 31.25MHz clock rate, and the driver
>> +converts clock tick rate to nanoseconds before storing it as timestamp value.
>>
>> GPIO GTE
>> --------
>>
>> This GTE instance timestamps GPIO in real time. For that to happen GPIO
>> -needs to be configured as input. The always on (AON) GPIO controller instance
>> -supports timestamping GPIOs in real time and it has 39 GPIO lines. The GPIO GTE
>> -and AON GPIO controller are tightly coupled as it requires very specific bits
>> -to be set in GPIO config register before GPIO GTE can be used, for that GPIOLIB
>> -adds two optional APIs as below. The GPIO GTE code supports both kernel
>> -and userspace consumers. The kernel space consumers can directly talk to HTE
>> -subsystem while userspace consumers timestamp requests go through GPIOLIB CDEV
>> -framework to HTE subsystem.
>> +needs to be configured as input. Only the always on (AON) GPIO controller
>> +instance supports timestamping GPIOs in real time as it is tightly coupled with
>> +the GPIO GTE. To support this, GPIOLIB adds two optional APIs as mentioned
>> +below. The GPIO GTE code supports both kernel and userspace consumers. The
>> +kernel space consumers can directly talk to HTE subsystem while userspace
>> +consumers timestamp requests go through GPIOLIB CDEV framework to HTE
>> +subsystem. The hte devicetree binding described at
>> +``Documentation/devicetree/bindings/timestamp`` provides an example of how a
>> +consumer can request an GPIO line.
>>
>> See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns().
>>
>> @@ -34,9 +34,8 @@ returns the timestamp in nanoseconds.
>> LIC (Legacy Interrupt Controller) IRQ GTE
>> -----------------------------------------
>>
>> -This GTE instance timestamps LIC IRQ lines in real time. There are 352 IRQ
>> -lines which this instance can add timestamps to in real time. The hte
>> -devicetree binding described at ``Documentation/devicetree/bindings/timestamp``
>> +This GTE instance timestamps LIC IRQ lines in real time. The hte devicetree
>> +binding described at ``Documentation/devicetree/bindings/timestamp``
>> provides an example of how a consumer can request an IRQ line. Since it is a
>> one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ
>> number that they are interested in. There is no userspace consumer support for
>
> The wording LGTM, thanks!
>
> Reviewed-by: Bagas Sanjaya <[email protected]>
>