The patch series:
- Adds tegra Tegra234 HTE(timestamp) provider supports.
- Updates MAINTAINERS file for git tree, mail list fields.
- Updates devicetree and API documentations.
- Enables HTE subsystem, Tegra194 and Tegra234 HTE providers
by default in arm64 defconfig and dts files.
Dipen Patel (7):
MAINTAINERS: Add HTE/timestamp subsystem details
hte: Add Tegra234 provider
gpio: tegra186: Add Tegra234 hte support
dt-bindings: timestamp: Add Tegra234 support
hte: Re-phrase tegra API document
arm64: tegra: Enable GTE nodes
arm64: defconfig: Enable HTE config
.../timestamp/nvidia,tegra194-hte.yaml | 44 ++++++-
Documentation/driver-api/hte/tegra194-hte.rst | 33 +++--
MAINTAINERS | 3 +
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 20 +++
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 20 +++
arch/arm64/configs/defconfig | 3 +
drivers/gpio/gpio-tegra186.c | 1 +
drivers/hte/hte-tegra194-test.c | 2 +-
drivers/hte/hte-tegra194.c | 124 +++++++++++++++++-
9 files changed, 224 insertions(+), 26 deletions(-)
base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780
--
2.17.1
The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
HTE support, it requires to add mapping between GPIO and HTE framework.
Signed-off-by: Dipen Patel <[email protected]>
---
drivers/hte/hte-tegra194-test.c | 2 +-
drivers/hte/hte-tegra194.c | 124 ++++++++++++++++++++++++++++++--
2 files changed, 121 insertions(+), 5 deletions(-)
diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c
index 5d776a185bd6..d79c28a80517 100644
--- a/drivers/hte/hte-tegra194-test.c
+++ b/drivers/hte/hte-tegra194-test.c
@@ -16,7 +16,7 @@
#include <linux/hte.h>
/*
- * This sample HTE GPIO test driver demonstrates HTE API usage by enabling
+ * This sample HTE test driver demonstrates HTE API usage by enabling
* hardware timestamp on gpio_in and specified LIC IRQ lines.
*
* Note: gpio_out and gpio_in need to be shorted externally in order for this
diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
index 49a27af22742..5d1f947db0f6 100644
--- a/drivers/hte/hte-tegra194.c
+++ b/drivers/hte/hte-tegra194.c
@@ -62,6 +62,10 @@
#define NV_AON_HTE_SLICE2_IRQ_GPIO_25 25
#define NV_AON_HTE_SLICE2_IRQ_GPIO_26 26
#define NV_AON_HTE_SLICE2_IRQ_GPIO_27 27
+#define NV_AON_HTE_SLICE2_IRQ_GPIO_28 28
+#define NV_AON_HTE_SLICE2_IRQ_GPIO_29 29
+#define NV_AON_HTE_SLICE2_IRQ_GPIO_30 30
+#define NV_AON_HTE_SLICE2_IRQ_GPIO_31 31
#define HTE_TECTRL 0x0
#define HTE_TETSCH 0x4
@@ -220,7 +224,100 @@ static const struct tegra_hte_line_mapped tegra194_aon_gpio_sec_map[] = {
[39] = {NV_AON_SLICE_INVALID, 0},
};
-static const struct tegra_hte_data aon_hte = {
+static const struct tegra_hte_line_mapped tegra234_aon_gpio_map[] = {
+ /* gpio, slice, bit_index */
+ /* AA port */
+ [0] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
+ [1] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
+ [2] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
+ [3] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
+ [4] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
+ [5] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
+ [6] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
+ [7] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
+ /* BB port */
+ [8] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
+ [9] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
+ [10] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
+ [11] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
+ /* CC port */
+ [12] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
+ [13] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
+ [14] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
+ [15] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
+ [16] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
+ [17] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
+ [18] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
+ [19] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
+ /* DD port */
+ [20] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
+ [21] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
+ [22] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
+ /* EE port */
+ [23] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_31},
+ [24] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_30},
+ [25] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
+ [26] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
+ [27] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
+ [28] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
+ [29] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
+ [30] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
+ /* GG port */
+ [31] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
+};
+
+static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
+ /* gpio, slice, bit_index */
+ /* AA port */
+ [0] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
+ [1] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
+ [2] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
+ [3] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
+ [4] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
+ [5] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
+ [6] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
+ [7] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
+ /* BB port */
+ [8] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
+ [9] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
+ [10] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
+ [11] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
+ [12] = {NV_AON_SLICE_INVALID, 0},
+ [13] = {NV_AON_SLICE_INVALID, 0},
+ [14] = {NV_AON_SLICE_INVALID, 0},
+ [15] = {NV_AON_SLICE_INVALID, 0},
+ /* CC port */
+ [16] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
+ [17] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
+ [18] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
+ [19] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
+ [20] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
+ [21] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
+ [22] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
+ [23] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
+ /* DD port */
+ [24] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
+ [25] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
+ [26] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
+ [27] = {NV_AON_SLICE_INVALID, 0},
+ [28] = {NV_AON_SLICE_INVALID, 0},
+ [29] = {NV_AON_SLICE_INVALID, 0},
+ [30] = {NV_AON_SLICE_INVALID, 0},
+ [31] = {NV_AON_SLICE_INVALID, 0},
+ /* EE port */
+ [32] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_31},
+ [33] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_30},
+ [34] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
+ [35] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
+ [36] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
+ [37] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
+ [38] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
+ [39] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
+ /* GG port */
+ [40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
+};
+
+static const struct tegra_hte_data t194_aon_hte = {
.map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
.map = tegra194_aon_gpio_map,
.sec_map_sz = ARRAY_SIZE(tegra194_aon_gpio_sec_map),
@@ -228,6 +325,14 @@ static const struct tegra_hte_data aon_hte = {
.type = HTE_TEGRA_TYPE_GPIO,
};
+static const struct tegra_hte_data t234_aon_hte = {
+ .map_sz = ARRAY_SIZE(tegra234_aon_gpio_map),
+ .map = tegra234_aon_gpio_map,
+ .sec_map_sz = ARRAY_SIZE(tegra234_aon_gpio_sec_map),
+ .sec_map = tegra234_aon_gpio_sec_map,
+ .type = HTE_TEGRA_TYPE_GPIO,
+};
+
static const struct tegra_hte_data lic_hte = {
.map_sz = 0,
.map = NULL,
@@ -535,7 +640,9 @@ static bool tegra_hte_match_from_linedata(const struct hte_chip *chip,
static const struct of_device_id tegra_hte_of_match[] = {
{ .compatible = "nvidia,tegra194-gte-lic", .data = &lic_hte},
- { .compatible = "nvidia,tegra194-gte-aon", .data = &aon_hte},
+ { .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
+ { .compatible = "nvidia,tegra234-gte-lic", .data = &lic_hte},
+ { .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
{ }
};
MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
@@ -635,8 +742,17 @@ static int tegra_hte_probe(struct platform_device *pdev)
gc->match_from_linedata = tegra_hte_match_from_linedata;
- hte_dev->c = gpiochip_find("tegra194-gpio-aon",
- tegra_get_gpiochip_from_name);
+ 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;
+
if (!hte_dev->c)
return dev_err_probe(dev, -EPROBE_DEFER,
"wait for gpio controller\n");
--
2.17.1
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(-)
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
--
2.17.1
To enable timestamp support for the Tegra234, has_gte variable needs
to be set true.
Signed-off-by: Dipen Patel <[email protected]>
---
drivers/gpio/gpio-tegra186.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-tegra186.c b/drivers/gpio/gpio-tegra186.c
index 54d9fa7da9c1..c2ccfee52608 100644
--- a/drivers/gpio/gpio-tegra186.c
+++ b/drivers/gpio/gpio-tegra186.c
@@ -1136,6 +1136,7 @@ static const struct tegra_gpio_soc tegra234_aon_soc = {
.name = "tegra234-gpio-aon",
.instance = 1,
.num_irqs_per_bank = 8,
+ .has_gte = true,
};
#define TEGRA241_MAIN_GPIO_PORT(_name, _bank, _port, _pins) \
--
2.17.1
Enable HTE core and tegra HTE provider by default as built in
module.
Signed-off-by: Dipen Patel <[email protected]>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0b6af3348e79..c6e04a4f89d5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1307,6 +1307,9 @@ CONFIG_INTERCONNECT_QCOM_SM8150=m
CONFIG_INTERCONNECT_QCOM_SM8250=m
CONFIG_INTERCONNECT_QCOM_SM8350=m
CONFIG_INTERCONNECT_QCOM_SM8450=m
+CONFIG_HTE=y
+CONFIG_HTE_TEGRA194=y
+CONFIG_HTE_TEGRA194_TEST=m
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
--
2.17.1
Added timestamp provider support for the Tegra234 in devicetree
bindings.
Signed-off-by: Dipen Patel <[email protected]>
---
.../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 <[email protected]>
@@ -23,6 +23,8 @@ properties:
enum:
- nvidia,tegra194-gte-aon
- nvidia,tegra194-gte-lic
+ - nvidia,tegra234-gte-aon
+ - nvidia,tegra234-gte-lic
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.
+ 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
+
required:
- compatible
- reg
--
2.17.1
Add and enable AON and LIC GTE nodes by default.
Signed-off-by: Dipen Patel <[email protected]>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 20 ++++++++++++++++++++
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 20 ++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 41f3a7e188d0..67927d97956e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1366,6 +1366,16 @@
status = "disabled";
};
+ hte_lic: hardware-timestamp@3aa0000 {
+ compatible = "nvidia,tegra194-gte-lic";
+ reg = <0x3aa0000 0x10000>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,int-threshold = <1>;
+ nvidia,slices = <11>;
+ #timestamp-cells = <1>;
+ status = "okay";
+ };
+
hsp_top0: hsp@3c00000 {
compatible = "nvidia,tegra194-hsp";
reg = <0x03c00000 0xa0000>;
@@ -1579,6 +1589,16 @@
#mbox-cells = <2>;
};
+ hte_aon: hardware-timestamp@c1e0000 {
+ compatible = "nvidia,tegra194-gte-aon";
+ reg = <0xc1e0000 0x10000>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,int-threshold = <1>;
+ nvidia,slices = <3>;
+ #timestamp-cells = <1>;
+ status = "okay";
+ };
+
gen2_i2c: i2c@c240000 {
compatible = "nvidia,tegra194-i2c";
reg = <0x0c240000 0x10000>;
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index 0170bfa8a467..fecf9ab1bf17 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -949,6 +949,16 @@
clock-names = "fuse";
};
+ hte_lic: hardware-timestamp@3aa0000 {
+ compatible = "nvidia,tegra234-gte-lic";
+ reg = <0x3aa0000 0x10000>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,int-threshold = <1>;
+ nvidia,slices = <17>;
+ #timestamp-cells = <1>;
+ status = "okay";
+ };
+
hsp_top0: hsp@3c00000 {
compatible = "nvidia,tegra234-hsp", "nvidia,tegra194-hsp";
reg = <0x03c00000 0xa0000>;
@@ -1466,6 +1476,16 @@
#mbox-cells = <2>;
};
+ hte_aon: hardware-timestamp@c1e0000 {
+ compatible = "nvidia,tegra234-gte-aon";
+ reg = <0xc1e0000 0x10000>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,int-threshold = <1>;
+ nvidia,slices = <3>;
+ #timestamp-cells = <1>;
+ status = "okay";
+ };
+
gen2_i2c: i2c@c240000 {
compatible = "nvidia,tegra194-i2c";
reg = <0xc240000 0x100>;
--
2.17.1
On Thu, Nov 03, 2022 at 10:45:21AM -0700, Dipen Patel wrote:
> 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().
>
I think the wording can be better:
---- >8 ----
diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst
index 85e654772782c1..13c45bfc03a75e 100644
--- a/Documentation/driver-api/hte/tegra194-hte.rst
+++ b/Documentation/driver-api/hte/tegra194-hte.rst
@@ -5,11 +5,11 @@ HTE Kernel provider driver
Description
-----------
-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.
+The Nvidia tegra HTE provider, also known as GTE (Generic Timestamping Engine)
+driver implements two GTE instances: GPIO GTE and LIC (Legacy Interrupt
+Controller) IRQ GTE. Both GTE instances get the timestamp from 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
--------
@@ -19,17 +19,17 @@ 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.
+kernel space consumers can directly talk to HTE subsystem while requests from
+userspace consumers 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().
+To toggle hardware timestamp, use gpiod_enable_hw_timestamp_ns() and
+gpiod_disable_hw_timestamp_ns().
For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
-specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
-returns the timestamp in nanoseconds.
+specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c`` for
+example.
LIC (Legacy Interrupt Controller) IRQ GTE
-----------------------------------------
Thanks.
--
An old man doll... just what I always wanted! - Clara
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 <[email protected]>
> ---
> .../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 <[email protected]>
> @@ -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.
>
> 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?
It seems like 'nvidia,slices' should be implied from the compatible
string.
Rob
On Thu, Nov 03, 2022 at 10:45:16AM -0700, Dipen Patel wrote:
> The patch series:
> - Adds tegra Tegra234 HTE(timestamp) provider supports.
> - Updates MAINTAINERS file for git tree, mail list fields.
> - Updates devicetree and API documentations.
> - Enables HTE subsystem, Tegra194 and Tegra234 HTE providers
> by default in arm64 defconfig and dts files.
>
> Dipen Patel (7):
> MAINTAINERS: Add HTE/timestamp subsystem details
> hte: Add Tegra234 provider
> gpio: tegra186: Add Tegra234 hte support
> dt-bindings: timestamp: Add Tegra234 support
> hte: Re-phrase tegra API document
> arm64: tegra: Enable GTE nodes
> arm64: defconfig: Enable HTE config
I've applied patches 6 and 7 to the Tegra tree.
Thanks,
Thierry
On Thu, Nov 03, 2022 at 10:45:19AM -0700, Dipen Patel wrote:
> To enable timestamp support for the Tegra234, has_gte variable needs
> to be set true.
>
> Signed-off-by: Dipen Patel <[email protected]>
> ---
> drivers/gpio/gpio-tegra186.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Thierry Reding <[email protected]>
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 <[email protected]>
> ---
> .../timestamp/nvidia,tegra194-hte.yaml | 44 +++++++++++++++++--
> 1 file changed, 40 insertions(+), 4 deletions(-)
As I mentioned in the other patch, perhaps we should extend the binding
with a phandle property that lets us point directly to the GPIO
controller that a given HTE is coupled with.
We haven't technically started making use of these bindings yet, so
backwards-compatibility shouldn't be an issue yet.
Thierry
On Thu, Nov 03, 2022 at 10:45:18AM -0700, Dipen Patel wrote:
> The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
> HTE support, it requires to add mapping between GPIO and HTE framework.
>
> Signed-off-by: Dipen Patel <[email protected]>
> ---
> drivers/hte/hte-tegra194-test.c | 2 +-
> drivers/hte/hte-tegra194.c | 124 ++++++++++++++++++++++++++++++--
> 2 files changed, 121 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c
> index 5d776a185bd6..d79c28a80517 100644
> --- a/drivers/hte/hte-tegra194-test.c
> +++ b/drivers/hte/hte-tegra194-test.c
> @@ -16,7 +16,7 @@
> #include <linux/hte.h>
>
> /*
> - * This sample HTE GPIO test driver demonstrates HTE API usage by enabling
> + * This sample HTE test driver demonstrates HTE API usage by enabling
> * hardware timestamp on gpio_in and specified LIC IRQ lines.
> *
> * Note: gpio_out and gpio_in need to be shorted externally in order for this
> diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
> index 49a27af22742..5d1f947db0f6 100644
> --- a/drivers/hte/hte-tegra194.c
> +++ b/drivers/hte/hte-tegra194.c
> @@ -62,6 +62,10 @@
> #define NV_AON_HTE_SLICE2_IRQ_GPIO_25 25
> #define NV_AON_HTE_SLICE2_IRQ_GPIO_26 26
> #define NV_AON_HTE_SLICE2_IRQ_GPIO_27 27
> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_28 28
> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_29 29
> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_30 30
> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_31 31
>
> #define HTE_TECTRL 0x0
> #define HTE_TETSCH 0x4
> @@ -220,7 +224,100 @@ static const struct tegra_hte_line_mapped tegra194_aon_gpio_sec_map[] = {
> [39] = {NV_AON_SLICE_INVALID, 0},
> };
>
> -static const struct tegra_hte_data aon_hte = {
> +static const struct tegra_hte_line_mapped tegra234_aon_gpio_map[] = {
> + /* gpio, slice, bit_index */
> + /* AA port */
> + [0] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
> + [1] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
> + [2] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
> + [3] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
> + [4] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
> + [5] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
> + [6] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
> + [7] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
> + /* BB port */
> + [8] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
> + [9] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
> + [10] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
> + [11] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
> + /* CC port */
> + [12] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
> + [13] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
> + [14] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
> + [15] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
> + [16] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
> + [17] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
> + [18] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
> + [19] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
> + /* DD port */
> + [20] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
> + [21] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
> + [22] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
> + /* EE port */
> + [23] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_31},
> + [24] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_30},
> + [25] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
> + [26] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
> + [27] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
> + [28] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
> + [29] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
> + [30] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
> + /* GG port */
> + [31] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> +};
> +
> +static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
> + /* gpio, slice, bit_index */
> + /* AA port */
> + [0] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
> + [1] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
> + [2] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
> + [3] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
> + [4] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
> + [5] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
> + [6] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
> + [7] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
> + /* BB port */
> + [8] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
> + [9] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
> + [10] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
> + [11] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
> + [12] = {NV_AON_SLICE_INVALID, 0},
> + [13] = {NV_AON_SLICE_INVALID, 0},
> + [14] = {NV_AON_SLICE_INVALID, 0},
> + [15] = {NV_AON_SLICE_INVALID, 0},
> + /* CC port */
> + [16] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
> + [17] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
> + [18] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
> + [19] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
> + [20] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
> + [21] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
> + [22] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
> + [23] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
> + /* DD port */
> + [24] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
> + [25] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
> + [26] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
> + [27] = {NV_AON_SLICE_INVALID, 0},
> + [28] = {NV_AON_SLICE_INVALID, 0},
> + [29] = {NV_AON_SLICE_INVALID, 0},
> + [30] = {NV_AON_SLICE_INVALID, 0},
> + [31] = {NV_AON_SLICE_INVALID, 0},
> + /* EE port */
> + [32] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_31},
> + [33] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_30},
> + [34] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
> + [35] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
> + [36] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
> + [37] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
> + [38] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
> + [39] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
> + /* GG port */
> + [40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> +};
> +
> +static const struct tegra_hte_data t194_aon_hte = {
> .map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
> .map = tegra194_aon_gpio_map,
> .sec_map_sz = ARRAY_SIZE(tegra194_aon_gpio_sec_map),
> @@ -228,6 +325,14 @@ static const struct tegra_hte_data aon_hte = {
> .type = HTE_TEGRA_TYPE_GPIO,
> };
>
> +static const struct tegra_hte_data t234_aon_hte = {
> + .map_sz = ARRAY_SIZE(tegra234_aon_gpio_map),
> + .map = tegra234_aon_gpio_map,
> + .sec_map_sz = ARRAY_SIZE(tegra234_aon_gpio_sec_map),
> + .sec_map = tegra234_aon_gpio_sec_map,
> + .type = HTE_TEGRA_TYPE_GPIO,
> +};
> +
> static const struct tegra_hte_data lic_hte = {
> .map_sz = 0,
> .map = NULL,
> @@ -535,7 +640,9 @@ static bool tegra_hte_match_from_linedata(const struct hte_chip *chip,
>
> static const struct of_device_id tegra_hte_of_match[] = {
> { .compatible = "nvidia,tegra194-gte-lic", .data = &lic_hte},
> - { .compatible = "nvidia,tegra194-gte-aon", .data = &aon_hte},
> + { .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
> + { .compatible = "nvidia,tegra234-gte-lic", .data = &lic_hte},
> + { .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
> { }
> };
> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
> @@ -635,8 +742,17 @@ static int tegra_hte_probe(struct platform_device *pdev)
>
> gc->match_from_linedata = tegra_hte_match_from_linedata;
>
> - hte_dev->c = gpiochip_find("tegra194-gpio-aon",
> - tegra_get_gpiochip_from_name);
> + 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;
I'm wondering: instead of doing this cumbersome lookup, perhaps it would
be easier to create a direct link to the right GPIO controller with a
phandle?
Thierry
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 <[email protected]>
>> ---
>> .../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 <[email protected]>
>> @@ -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
On 11/11/22 8:01 AM, Thierry Reding wrote:
> On Thu, Nov 03, 2022 at 10:45:18AM -0700, Dipen Patel wrote:
>> The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
>> HTE support, it requires to add mapping between GPIO and HTE framework.
>>
>> Signed-off-by: Dipen Patel <[email protected]>
>> ---
>> drivers/hte/hte-tegra194-test.c | 2 +-
>> drivers/hte/hte-tegra194.c | 124 ++++++++++++++++++++++++++++++--
>> 2 files changed, 121 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c
>> index 5d776a185bd6..d79c28a80517 100644
>> --- a/drivers/hte/hte-tegra194-test.c
>> +++ b/drivers/hte/hte-tegra194-test.c
>> @@ -16,7 +16,7 @@
>> #include <linux/hte.h>
>>
>> /*
>> - * This sample HTE GPIO test driver demonstrates HTE API usage by enabling
>> + * This sample HTE test driver demonstrates HTE API usage by enabling
>> * hardware timestamp on gpio_in and specified LIC IRQ lines.
>> *
>> * Note: gpio_out and gpio_in need to be shorted externally in order for this
>> diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
>> index 49a27af22742..5d1f947db0f6 100644
>> --- a/drivers/hte/hte-tegra194.c
>> +++ b/drivers/hte/hte-tegra194.c
>> @@ -62,6 +62,10 @@
>> #define NV_AON_HTE_SLICE2_IRQ_GPIO_25 25
>> #define NV_AON_HTE_SLICE2_IRQ_GPIO_26 26
>> #define NV_AON_HTE_SLICE2_IRQ_GPIO_27 27
>> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_28 28
>> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_29 29
>> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_30 30
>> +#define NV_AON_HTE_SLICE2_IRQ_GPIO_31 31
>>
>> #define HTE_TECTRL 0x0
>> #define HTE_TETSCH 0x4
>> @@ -220,7 +224,100 @@ static const struct tegra_hte_line_mapped tegra194_aon_gpio_sec_map[] = {
>> [39] = {NV_AON_SLICE_INVALID, 0},
>> };
>>
>> -static const struct tegra_hte_data aon_hte = {
>> +static const struct tegra_hte_line_mapped tegra234_aon_gpio_map[] = {
>> + /* gpio, slice, bit_index */
>> + /* AA port */
>> + [0] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
>> + [1] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
>> + [2] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
>> + [3] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
>> + [4] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
>> + [5] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
>> + [6] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
>> + [7] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
>> + /* BB port */
>> + [8] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
>> + [9] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
>> + [10] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
>> + [11] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
>> + /* CC port */
>> + [12] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
>> + [13] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
>> + [14] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
>> + [15] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
>> + [16] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
>> + [17] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
>> + [18] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
>> + [19] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
>> + /* DD port */
>> + [20] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
>> + [21] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
>> + [22] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
>> + /* EE port */
>> + [23] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_31},
>> + [24] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_30},
>> + [25] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
>> + [26] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
>> + [27] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
>> + [28] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
>> + [29] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
>> + [30] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
>> + /* GG port */
>> + [31] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
>> +};
>> +
>> +static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
>> + /* gpio, slice, bit_index */
>> + /* AA port */
>> + [0] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
>> + [1] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
>> + [2] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
>> + [3] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
>> + [4] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
>> + [5] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
>> + [6] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
>> + [7] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
>> + /* BB port */
>> + [8] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
>> + [9] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
>> + [10] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
>> + [11] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
>> + [12] = {NV_AON_SLICE_INVALID, 0},
>> + [13] = {NV_AON_SLICE_INVALID, 0},
>> + [14] = {NV_AON_SLICE_INVALID, 0},
>> + [15] = {NV_AON_SLICE_INVALID, 0},
>> + /* CC port */
>> + [16] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
>> + [17] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
>> + [18] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
>> + [19] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
>> + [20] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
>> + [21] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
>> + [22] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
>> + [23] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
>> + /* DD port */
>> + [24] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
>> + [25] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
>> + [26] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
>> + [27] = {NV_AON_SLICE_INVALID, 0},
>> + [28] = {NV_AON_SLICE_INVALID, 0},
>> + [29] = {NV_AON_SLICE_INVALID, 0},
>> + [30] = {NV_AON_SLICE_INVALID, 0},
>> + [31] = {NV_AON_SLICE_INVALID, 0},
>> + /* EE port */
>> + [32] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_31},
>> + [33] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_30},
>> + [34] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
>> + [35] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
>> + [36] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
>> + [37] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
>> + [38] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
>> + [39] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
>> + /* GG port */
>> + [40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
>> +};
>> +
>> +static const struct tegra_hte_data t194_aon_hte = {
>> .map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
>> .map = tegra194_aon_gpio_map,
>> .sec_map_sz = ARRAY_SIZE(tegra194_aon_gpio_sec_map),
>> @@ -228,6 +325,14 @@ static const struct tegra_hte_data aon_hte = {
>> .type = HTE_TEGRA_TYPE_GPIO,
>> };
>>
>> +static const struct tegra_hte_data t234_aon_hte = {
>> + .map_sz = ARRAY_SIZE(tegra234_aon_gpio_map),
>> + .map = tegra234_aon_gpio_map,
>> + .sec_map_sz = ARRAY_SIZE(tegra234_aon_gpio_sec_map),
>> + .sec_map = tegra234_aon_gpio_sec_map,
>> + .type = HTE_TEGRA_TYPE_GPIO,
>> +};
>> +
>> static const struct tegra_hte_data lic_hte = {
>> .map_sz = 0,
>> .map = NULL,
>> @@ -535,7 +640,9 @@ static bool tegra_hte_match_from_linedata(const struct hte_chip *chip,
>>
>> static const struct of_device_id tegra_hte_of_match[] = {
>> { .compatible = "nvidia,tegra194-gte-lic", .data = &lic_hte},
>> - { .compatible = "nvidia,tegra194-gte-aon", .data = &aon_hte},
>> + { .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
>> + { .compatible = "nvidia,tegra234-gte-lic", .data = &lic_hte},
>> + { .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
>> { }
>> };
>> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
>> @@ -635,8 +742,17 @@ static int tegra_hte_probe(struct platform_device *pdev)
>>
>> gc->match_from_linedata = tegra_hte_match_from_linedata;
>>
>> - hte_dev->c = gpiochip_find("tegra194-gpio-aon",
>> - tegra_get_gpiochip_from_name);
>> + 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;
>
> I'm wondering: instead of doing this cumbersome lookup, perhaps it would
> be easier to create a direct link to the right GPIO controller with a
> phandle?
Possible, need to see if gpiod framework has API exposed to get the gpiochip from
the phandle.
>
> Thierry
On 11/4/22 8:33 PM, Bagas Sanjaya wrote:
> On Thu, Nov 03, 2022 at 10:45:21AM -0700, Dipen Patel wrote:
>> 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().
>>
>
> I think the wording can be better:
I do not understand, can you please elaborate?
>
> ---- >8 ----
>
> diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst
> index 85e654772782c1..13c45bfc03a75e 100644
> --- a/Documentation/driver-api/hte/tegra194-hte.rst
> +++ b/Documentation/driver-api/hte/tegra194-hte.rst
> @@ -5,11 +5,11 @@ HTE Kernel provider driver
>
> Description
> -----------
> -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.
> +The Nvidia tegra HTE provider, also known as GTE (Generic Timestamping Engine)
> +driver implements two GTE instances: GPIO GTE and LIC (Legacy Interrupt
> +Controller) IRQ GTE. Both GTE instances get the timestamp from 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
> --------
> @@ -19,17 +19,17 @@ 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.
> +kernel space consumers can directly talk to HTE subsystem while requests from
> +userspace consumers 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().
> +To toggle hardware timestamp, use gpiod_enable_hw_timestamp_ns() and
> +gpiod_disable_hw_timestamp_ns().
>
> For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
> -specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
> -returns the timestamp in nanoseconds.
> +specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c`` for
> +example.
>
> LIC (Legacy Interrupt Controller) IRQ GTE
> -----------------------------------------
>
> Thanks.
>
On 11/30/22 10:34, Dipen Patel wrote:
>> I think the wording can be better:
> I do not understand, can you please elaborate?
Exactly where? Please quote appropriate hunks from below where do you not
understand.
>>
>> ---- >8 ----
>>
>> diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra194-hte.rst
>> index 85e654772782c1..13c45bfc03a75e 100644
>> --- a/Documentation/driver-api/hte/tegra194-hte.rst
>> +++ b/Documentation/driver-api/hte/tegra194-hte.rst
>> @@ -5,11 +5,11 @@ HTE Kernel provider driver
>>
>> Description
>> -----------
>> -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.
>> +The Nvidia tegra HTE provider, also known as GTE (Generic Timestamping Engine)
>> +driver implements two GTE instances: GPIO GTE and LIC (Legacy Interrupt
>> +Controller) IRQ GTE. Both GTE instances get the timestamp from 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
>> --------
>> @@ -19,17 +19,17 @@ 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.
>> +kernel space consumers can directly talk to HTE subsystem while requests from
>> +userspace consumers 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().
>> +To toggle hardware timestamp, use gpiod_enable_hw_timestamp_ns() and
>> +gpiod_disable_hw_timestamp_ns().
>>
>> For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
>> -specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
>> -returns the timestamp in nanoseconds.
>> +specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c`` for
>> +example.
>>
>> LIC (Legacy Interrupt Controller) IRQ GTE
>> -----------------------------------------
>>
Thanks anyway.
--
An old man doll... just what I always wanted! - Clara
On 11/29/22 7:00 PM, Dipen Patel wrote:
> On 11/11/22 8:01 AM, Thierry Reding wrote:
>> On Thu, Nov 03, 2022 at 10:45:18AM -0700, Dipen Patel wrote:
>>> The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
>>> HTE support, it requires to add mapping between GPIO and HTE framework.
>>>
>>> Signed-off-by: Dipen Patel <[email protected]>
>>> ---
>>> drivers/hte/hte-tegra194-test.c | 2 +-
>>> drivers/hte/hte-tegra194.c | 124 ++++++++++++++++++++++++++++++--
>>> 2 files changed, 121 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c
>>> index 5d776a185bd6..d79c28a80517 100644
>>> --- a/drivers/hte/hte-tegra194-test.c
>>> +++ b/drivers/hte/hte-tegra194-test.c
>>> @@ -16,7 +16,7 @@
>>> #include <linux/hte.h>
>>>
<snip>
>>> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
>>> @@ -635,8 +742,17 @@ static int tegra_hte_probe(struct platform_device *pdev)
>>>
>>> gc->match_from_linedata = tegra_hte_match_from_linedata;
>>>
>>> - hte_dev->c = gpiochip_find("tegra194-gpio-aon",
>>> - tegra_get_gpiochip_from_name);
>>> + 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;
>>
>> I'm wondering: instead of doing this cumbersome lookup, perhaps it would
>> be easier to create a direct link to the right GPIO controller with a
>> phandle?
> Possible, need to see if gpiod framework has API exposed to get the gpiochip from
> the phandle.
Thierry, I can not find any API which can help retrieve gpio_chip from the GPIO controller
phandle. I need gpio_chip->base to map GPIO line to GTE mapping.
>>
>> Thierry
>
On Tue, Dec 27, 2022 at 04:43:48PM -0800, Dipen Patel wrote:
> On 11/29/22 7:00 PM, Dipen Patel wrote:
> > On 11/11/22 8:01 AM, Thierry Reding wrote:
> >> On Thu, Nov 03, 2022 at 10:45:18AM -0700, Dipen Patel wrote:
> >>> The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
> >>> HTE support, it requires to add mapping between GPIO and HTE framework.
> >>>
> >>> Signed-off-by: Dipen Patel <[email protected]>
> >>> ---
> >>> drivers/hte/hte-tegra194-test.c | 2 +-
> >>> drivers/hte/hte-tegra194.c | 124 ++++++++++++++++++++++++++++++--
> >>> 2 files changed, 121 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/hte/hte-tegra194-test.c b/drivers/hte/hte-tegra194-test.c
> >>> index 5d776a185bd6..d79c28a80517 100644
> >>> --- a/drivers/hte/hte-tegra194-test.c
> >>> +++ b/drivers/hte/hte-tegra194-test.c
> >>> @@ -16,7 +16,7 @@
> >>> #include <linux/hte.h>
> >>>
> <snip>
> >>> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
> >>> @@ -635,8 +742,17 @@ static int tegra_hte_probe(struct platform_device *pdev)
> >>>
> >>> gc->match_from_linedata = tegra_hte_match_from_linedata;
> >>>
> >>> - hte_dev->c = gpiochip_find("tegra194-gpio-aon",
> >>> - tegra_get_gpiochip_from_name);
> >>> + 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;
> >>
> >> I'm wondering: instead of doing this cumbersome lookup, perhaps it would
> >> be easier to create a direct link to the right GPIO controller with a
> >> phandle?
> > Possible, need to see if gpiod framework has API exposed to get the gpiochip from
> > the phandle.
>
> Thierry, I can not find any API which can help retrieve gpio_chip from the GPIO controller
> phandle. I need gpio_chip->base to map GPIO line to GTE mapping.
gpiochip_find() should allow you to implement that. So instead of
tegra_get_gpiochip_from_name() you could implement a function that
matches on the phandle that you've read from the HTE node.
You could probably add such a helper to the GPIO core, since it seems to
me like it would be universally helpful.
Actually there's of_find_gpiochip_by_node() in gpiolib-of.c already, so
you could propose to export it for external users.
Thierry