This patch series mainly adds support for the Tegra234 HTE provider. In
addition, it addresses dt binding comments which prompted code
changes in the existing HTE provider driver for the Tegra194 chips. The
comments raised concern how existing code retrieves gpio controller node
(the node is used to help namespace conversion between HTE and GPIOLIB).
To help simplify that process, new DT property is suggested which adds
gpio
controller node in the HTE provider binding as phandle property. To
conlude this patch series:
- adds Tegra234 HTE provider
- modifies existing Tegra194 and Tegra234 provider code to add address
provider dt binding changes.
The V1 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.
The V2 patch series:
- Changes in dt bindings to remove slices property
- Adds nvidia,gpio-controller dt property
- Add GTE node for the Tegra234
The V3 patch series:
- Re-arranged patches to have dt bindings first before its usage
- Addressed review comments regarding dt bindings
Dipen Patel (6):
MAINTAINERS: Add HTE/timestamp subsystem details
dt-bindings: timestamp: Add Tegra234 support
hte: Re-phrase tegra API document
hte: Add Tegra234 provider
gpio: tegra186: Add Tegra234 hte support
arm64: tegra: Add GTE nodes
.../timestamp/nvidia,tegra194-hte.yaml | 31 ++--
Documentation/driver-api/hte/tegra194-hte.rst | 33 ++--
MAINTAINERS | 3 +
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 3 +-
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 17 ++
drivers/gpio/gpio-tegra186.c | 1 +
drivers/hte/hte-tegra194-test.c | 2 +-
drivers/hte/hte-tegra194.c | 152 ++++++++++++++++--
8 files changed, 196 insertions(+), 46 deletions(-)
base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
--
2.17.1
Added timestamp provider support for the Tegra234 in devicetree
bindings. In addition, it addresses review comments from the
previous review round as follows:
- Removes nvidia,slices property. This was not necessary as it
is a constant value and can be hardcoded inside the driver code.
- Adds nvidia,gpio-controller property. This simplifies how GTE driver
retrieves GPIO controller instance, see below explanation.
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;
This means for every future addition of the compatible string, if else
condition statements have to be expanded.
With the property:
gpio_ctrl = of_parse_phandle(dev->of_node, "nvidia,gpio-controller", 0);
....
hte_dev->c = gpiochip_find(gpio_ctrl, tegra_get_gpiochip_from_of_node);
We haven't technically started making use of these bindings, so
backwards-compatibility shouldn't be an issue yet.
Signed-off-by: Dipen Patel <[email protected]>
---
v2:
- Removed nvidia,slices property
- Added nvidia,gpio-controller based on review comments from Thierry,
this will help simplify the hte provider driver.
v3:
- Explained changes in detail in commit message
- Added allOf section per review comment
.../timestamp/nvidia,tegra194-hte.yaml | 31 ++++++++++++-------
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
index c31e207d1652..eb904ac2f331 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
@@ -38,14 +40,11 @@ properties:
minimum: 1
maximum: 256
- nvidia,slices:
- $ref: /schemas/types.yaml#/definitions/uint32
+ nvidia,gpio-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
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]
+ The phandle to AON gpio controller instance. This is required to handle
+ namespace conversion between GPIO and GTE.
'#timestamp-cells':
description:
@@ -59,9 +58,20 @@ required:
- compatible
- reg
- interrupts
- - nvidia,slices
- "#timestamp-cells"
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-gte-aon
+ - nvidia,tegra234-gte-aon
+ then:
+ required:
+ - nvidia,gpio-controller
+
additionalProperties: false
examples:
@@ -71,7 +81,7 @@ examples:
reg = <0xc1e0000 0x10000>;
interrupts = <0 13 0x4>;
nvidia,int-threshold = <1>;
- nvidia,slices = <3>;
+ nvidia,gpio-controller = <&gpio_aon>;
#timestamp-cells = <1>;
};
@@ -81,7 +91,6 @@ examples:
reg = <0x3aa0000 0x10000>;
interrupts = <0 11 0x4>;
nvidia,int-threshold = <1>;
- nvidia,slices = <11>;
#timestamp-cells = <1>;
};
--
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]>
Acked-by: Thierry Reding <[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 14c872b6ad05..b904de0b1784 100644
--- a/drivers/gpio/gpio-tegra186.c
+++ b/drivers/gpio/gpio-tegra186.c
@@ -1134,6 +1134,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
Add tree, mailing list and patchwork details.
Signed-off-by: Dipen Patel <[email protected]>
Acked-by: Thierry Reding <[email protected]>
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..65b58963f0d2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9425,6 +9425,9 @@ F: drivers/input/touchscreen/htcpen.c
HTE SUBSYSTEM
M: Dipen Patel <[email protected]>
+L: [email protected]
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/pateldipen1984/linux.git
+Q: https://patchwork.kernel.org/project/timestamp/list/
S: Maintained
F: Documentation/devicetree/bindings/timestamp/
F: Documentation/driver-api/hte/
--
2.17.1
Add GTE nodes for the tegra234. Also modify AON GTE nodes for the
tegra194 to remove nvidia,slice property and add nvidia,gpio-controller
property to specify AON GPIO controller node so that GTE driver can
do namespace conversion between GPIO lines provided by the gpiolib
framework and hardware timestamping engine subsystem.
Signed-off-by: Dipen Patel <[email protected]>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 3 +--
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 17 +++++++++++++++++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 133dbe5b429d..7065643af275 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1355,7 +1355,6 @@
reg = <0x0 0x3aa0000 0x0 0x10000>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
nvidia,int-threshold = <1>;
- nvidia,slices = <11>;
#timestamp-cells = <1>;
status = "okay";
};
@@ -1578,7 +1577,7 @@
reg = <0x0 0xc1e0000 0x0 0x10000>;
interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
nvidia,int-threshold = <1>;
- nvidia,slices = <3>;
+ nvidia,gpio-controller = <&gpio_aon>;
#timestamp-cells = <1>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index 8fe8eda7654d..54790c6b6a2c 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -1156,6 +1156,14 @@
clock-names = "fuse";
};
+ hte_lic: hardware-timestamp@3aa0000 {
+ compatible = "nvidia,tegra234-gte-lic";
+ reg = <0x0 0x3aa0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,int-threshold = <1>;
+ #timestamp-cells = <1>;
+ };
+
hsp_top0: hsp@3c00000 {
compatible = "nvidia,tegra234-hsp", "nvidia,tegra194-hsp";
reg = <0x0 0x03c00000 0x0 0xa0000>;
@@ -1673,6 +1681,15 @@
#mbox-cells = <2>;
};
+ hte_aon: hardware-timestamp@c1e0000 {
+ compatible = "nvidia,tegra234-gte-aon";
+ reg = <0x0 0xc1e0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,int-threshold = <1>;
+ nvidia,gpio-controller = <&gpio_aon>;
+ #timestamp-cells = <1>;
+ };
+
gen2_i2c: i2c@c240000 {
compatible = "nvidia,tegra194-i2c";
reg = <0x0 0xc240000 0x0 0x100>;
--
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
This patch adds HTE provider support for the Tegra234 and reflects the
changes made in the device tree as follow.
- Add slices field in the SoC specific structure
- Remove gpio chip find by name function instead make use of the phandle
parsed from the DT node
Signed-off-by: Dipen Patel <[email protected]>
---
v2:
- Changed how gpio_chip could be aquired for the mapping
v3:
- Renamed gpio_chip matching function
- Used of_node to fwnode field in gpio_chip matching function
as data as gpio_chip struct does not have of_node member anymore.
drivers/hte/hte-tegra194-test.c | 2 +-
drivers/hte/hte-tegra194.c | 152 ++++++++++++++++++++++++++++----
2 files changed, 138 insertions(+), 16 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..7c8a2973e6a3 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
@@ -114,6 +118,7 @@ struct tegra_hte_line_data {
struct tegra_hte_data {
enum tegra_hte_type type;
+ u32 slices;
u32 map_sz;
u32 sec_map_sz;
const struct tegra_hte_line_mapped *map;
@@ -220,18 +225,129 @@ 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),
.sec_map = tegra194_aon_gpio_sec_map,
.type = HTE_TEGRA_TYPE_GPIO,
+ .slices = 3,
};
-static const struct tegra_hte_data lic_hte = {
+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,
+ .slices = 3,
+};
+
+static const struct tegra_hte_data t194_lic_hte = {
.map_sz = 0,
.map = NULL,
.type = HTE_TEGRA_TYPE_LIC,
+ .slices = 11,
+};
+
+static const struct tegra_hte_data t234_lic_hte = {
+ .map_sz = 0,
+ .map = NULL,
+ .type = HTE_TEGRA_TYPE_LIC,
+ .slices = 17,
};
static inline u32 tegra_hte_readl(struct tegra_hte_soc *hte, u32 reg)
@@ -534,8 +650,10 @@ 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-lic", .data = &t194_lic_hte},
+ { .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
+ { .compatible = "nvidia,tegra234-gte-lic", .data = &t234_lic_hte},
+ { .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
{ }
};
MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
@@ -556,9 +674,9 @@ static void tegra_gte_disable(void *data)
tegra_hte_writel(gs, HTE_TECTRL, 0);
}
-static int tegra_get_gpiochip_from_name(struct gpio_chip *chip, void *data)
+static int tegra_gpiochip_match(struct gpio_chip *chip, void *data)
{
- return !strcmp(chip->label, data);
+ return chip->fwnode == of_node_to_fwnode(data);
}
static int tegra_hte_probe(struct platform_device *pdev)
@@ -569,16 +687,10 @@ static int tegra_hte_probe(struct platform_device *pdev)
struct device *dev;
struct tegra_hte_soc *hte_dev;
struct hte_chip *gc;
+ struct device_node *gpio_ctrl;
dev = &pdev->dev;
- ret = of_property_read_u32(dev->of_node, "nvidia,slices", &slices);
- if (ret != 0) {
- dev_err(dev, "Could not read slices\n");
- return -EINVAL;
- }
- nlines = slices << 5;
-
hte_dev = devm_kzalloc(dev, sizeof(*hte_dev), GFP_KERNEL);
if (!hte_dev)
return -ENOMEM;
@@ -590,6 +702,9 @@ static int tegra_hte_probe(struct platform_device *pdev)
dev_set_drvdata(&pdev->dev, hte_dev);
hte_dev->prov_data = of_device_get_match_data(&pdev->dev);
+ slices = hte_dev->prov_data->slices;
+ nlines = slices << 5;
+
hte_dev->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(hte_dev->regs))
return PTR_ERR(hte_dev->regs);
@@ -635,8 +750,15 @@ 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);
+ gpio_ctrl = of_parse_phandle(dev->of_node,
+ "nvidia,gpio-controller", 0);
+ if (!gpio_ctrl) {
+ dev_err(dev, "gpio controller node not found\n");
+ return -ENODEV;
+ }
+
+ hte_dev->c = gpiochip_find(gpio_ctrl, tegra_gpiochip_match);
+ of_node_put(gpio_ctrl);
if (!hte_dev->c)
return dev_err_probe(dev, -EPROBE_DEFER,
"wait for gpio controller\n");
--
2.17.1
On 10/03/2023 20:06, Dipen Patel wrote:
> Added timestamp provider support for the Tegra234 in devicetree
> bindings. In addition, it addresses review comments from the
> previous review round as follows:
> - Removes nvidia,slices property. This was not necessary as it
> is a constant value and can be hardcoded inside the driver code.
> - Adds nvidia,gpio-controller property. This simplifies how GTE driver
> retrieves GPIO controller instance, see below explanation.
>
> 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;
>
> This means for every future addition of the compatible string, if else
> condition statements have to be expanded.
>
> With the property:
> gpio_ctrl = of_parse_phandle(dev->of_node, "nvidia,gpio-controller", 0);
> ....
> hte_dev->c = gpiochip_find(gpio_ctrl, tegra_get_gpiochip_from_of_node);
>
> We haven't technically started making use of these bindings, so
> backwards-compatibility shouldn't be an issue yet.
Unfortunately, I don't understand this statement. The
nvidia,tegra194-gte-aon with removed property is in a released kernel
v6.2. What does it mean "technically"? It's a released kernel thus it is
a released ABI.
And since DTS always go to separate branch, your patch #4 breaks
existing DTS (return -ENODEV;) - it is not bisectable.
>
> Signed-off-by: Dipen Patel <[email protected]>
> ---
Best regards,
Krzysztof
On 10/03/2023 20:06, Dipen Patel wrote:
> This patch adds HTE provider support for the Tegra234 and reflects the
> changes made in the device tree as follow.
> - Add slices field in the SoC specific structure
> - Remove gpio chip find by name function instead make use of the phandle
> parsed from the DT node
>
> Signed-off-by: Dipen Patel <[email protected]>
(...)
> hte_dev->regs = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(hte_dev->regs))
> return PTR_ERR(hte_dev->regs);
> @@ -635,8 +750,15 @@ 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);
> + gpio_ctrl = of_parse_phandle(dev->of_node,
> + "nvidia,gpio-controller", 0);
> + if (!gpio_ctrl) {
> + dev_err(dev, "gpio controller node not found\n");
> + return -ENODEV;
This is non-bisectable patchset. Remember that DTS cannot go with the
code, thus your code should handle existing DTS (which is BTW already
released with v6.2).
Any remarks to comments that no ABI was broken back then in 2022 are not
valid now. They were valid that time, but sorry, the time passed.
Best regards,
Krzysztof
On 3/12/23 8:47 AM, Krzysztof Kozlowski wrote:
> On 10/03/2023 20:06, Dipen Patel wrote:
>> Added timestamp provider support for the Tegra234 in devicetree
>> bindings. In addition, it addresses review comments from the
>> previous review round as follows:
>> - Removes nvidia,slices property. This was not necessary as it
>> is a constant value and can be hardcoded inside the driver code.
>> - Adds nvidia,gpio-controller property. This simplifies how GTE driver
>> retrieves GPIO controller instance, see below explanation.
>>
>> 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;
>>
>> This means for every future addition of the compatible string, if else
>> condition statements have to be expanded.
>>
>> With the property:
>> gpio_ctrl = of_parse_phandle(dev->of_node, "nvidia,gpio-controller", 0);
>> ....
>> hte_dev->c = gpiochip_find(gpio_ctrl, tegra_get_gpiochip_from_of_node);
>>
>> We haven't technically started making use of these bindings, so
>> backwards-compatibility shouldn't be an issue yet.
>
> Unfortunately, I don't understand this statement. The
> nvidia,tegra194-gte-aon with removed property is in a released kernel
> v6.2. What does it mean "technically"? It's a released kernel thus it is
> a released ABI.
There is no active user of that driver, so even if it breaks 6.2, it is fine
as there is no one to complain about it.
>
> And since DTS always go to separate branch, your patch #4 breaks
> existing DTS (return -ENODEV;) - it is not bisectable.
>
>>
>> Signed-off-by: Dipen Patel <[email protected]>
>> ---
>
>
> Best regards,
> Krzysztof
>
On 13/03/2023 18:05, Dipen Patel wrote:
> On 3/12/23 8:47 AM, Krzysztof Kozlowski wrote:
>> On 10/03/2023 20:06, Dipen Patel wrote:
>>> Added timestamp provider support for the Tegra234 in devicetree
>>> bindings. In addition, it addresses review comments from the
>>> previous review round as follows:
>>> - Removes nvidia,slices property. This was not necessary as it
>>> is a constant value and can be hardcoded inside the driver code.
>>> - Adds nvidia,gpio-controller property. This simplifies how GTE driver
>>> retrieves GPIO controller instance, see below explanation.
>>>
>>> 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;
>>>
>>> This means for every future addition of the compatible string, if else
>>> condition statements have to be expanded.
>>>
>>> With the property:
>>> gpio_ctrl = of_parse_phandle(dev->of_node, "nvidia,gpio-controller", 0);
>>> ....
>>> hte_dev->c = gpiochip_find(gpio_ctrl, tegra_get_gpiochip_from_of_node);
>>>
>>> We haven't technically started making use of these bindings, so
>>> backwards-compatibility shouldn't be an issue yet.
>>
>> Unfortunately, I don't understand this statement. The
>> nvidia,tegra194-gte-aon with removed property is in a released kernel
>> v6.2. What does it mean "technically"? It's a released kernel thus it is
>> a released ABI.
>
> There is no active user of that driver, so even if it breaks 6.2, it is fine
> as there is no one to complain about it.
How do you know? It's a released kernel, thus how can you ask millions
of people if they use it or not?
Best regards,
Krzysztof
On 3/13/23 10:55 AM, Krzysztof Kozlowski wrote:
> On 13/03/2023 18:05, Dipen Patel wrote:
>> On 3/12/23 8:47 AM, Krzysztof Kozlowski wrote:
>>> On 10/03/2023 20:06, Dipen Patel wrote:
>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>> bindings. In addition, it addresses review comments from the
>>>> previous review round as follows:
>>>> - Removes nvidia,slices property. This was not necessary as it
>>>> is a constant value and can be hardcoded inside the driver code.
>>>> - Adds nvidia,gpio-controller property. This simplifies how GTE driver
>>>> retrieves GPIO controller instance, see below explanation.
>>>>
>>>> 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;
>>>>
>>>> This means for every future addition of the compatible string, if else
>>>> condition statements have to be expanded.
>>>>
>>>> With the property:
>>>> gpio_ctrl = of_parse_phandle(dev->of_node, "nvidia,gpio-controller", 0);
>>>> ....
>>>> hte_dev->c = gpiochip_find(gpio_ctrl, tegra_get_gpiochip_from_of_node);
>>>>
>>>> We haven't technically started making use of these bindings, so
>>>> backwards-compatibility shouldn't be an issue yet.
>>>
>>> Unfortunately, I don't understand this statement. The
>>> nvidia,tegra194-gte-aon with removed property is in a released kernel
>>> v6.2. What does it mean "technically"? It's a released kernel thus it is
>>> a released ABI.
>>
>> There is no active user of that driver, so even if it breaks 6.2, it is fine
>> as there is no one to complain about it.
>
> How do you know? It's a released kernel, thus how can you ask millions
> of people if they use it or not?
Please help me understand, if I am targeting these set of changes for the kernel
6.4, wouldn't all the patches land on v6.4 at the same time no matter the tree it
will go from? Also, if user is at v6.2, how this will break as at that version, it
will have the old bindings and old driver, right?
>
> Best regards,
> Krzysztof
>
Hi Dipen,
thanks for maintaining HTE!
On Fri, Mar 10, 2023 at 8:06 PM Dipen Patel <[email protected]> wrote:
> - nvidia,slices:
> - $ref: /schemas/types.yaml#/definitions/uint32
I would not delete this, just mark it deprecated.
nvidia,slices:
$ref: /schemas/types.yaml#/definitions/uint32
deprecated: true
(And remove it from required, of course)
This way you do not need to explain about why it was
deleted, it's just deprecated, which is fine.
Yours,
Linus Walleij
On 3/13/23 2:57 PM, Linus Walleij wrote:
> Hi Dipen,
>
> thanks for maintaining HTE!
>
> On Fri, Mar 10, 2023 at 8:06 PM Dipen Patel <[email protected]> wrote:
>
>> - nvidia,slices:
>> - $ref: /schemas/types.yaml#/definitions/uint32
>
> I would not delete this, just mark it deprecated.
>
> nvidia,slices:
> $ref: /schemas/types.yaml#/definitions/uint32
> deprecated: true
>
> (And remove it from required, of course)
>
> This way you do not need to explain about why it was
> deleted, it's just deprecated, which is fine.
Great suggestion, thanks, will make changes in the next patch.
>
> Yours,
> Linus Walleij
On 3/13/23 4:49 PM, Dipen Patel wrote:
> On 3/13/23 2:57 PM, Linus Walleij wrote:
>> Hi Dipen,
>>
>> thanks for maintaining HTE!
>>
>> On Fri, Mar 10, 2023 at 8:06 PM Dipen Patel <[email protected]> wrote:
>>
>>> - nvidia,slices:
>>> - $ref: /schemas/types.yaml#/definitions/uint32
>>
>> I would not delete this, just mark it deprecated.
>>
>> nvidia,slices:
>> $ref: /schemas/types.yaml#/definitions/uint32
>> deprecated: true
>>
>> (And remove it from required, of course)
>>
>> This way you do not need to explain about why it was
>> deleted, it's just deprecated, which is fine.
>
> Great suggestion, thanks, will make changes in the next patch.
However, as I understood, current point of contention/discussion is addition of the
nvidia,gpio-controller property.
>>
>> Yours,
>> Linus Walleij
>
On Tue, Mar 14, 2023 at 1:02 AM Dipen Patel <[email protected]> wrote:
> However, as I understood, current point of contention/discussion is addition of the
> nvidia,gpio-controller property.
No I think you are talking past each other. Krzysztof talks about
a "removed property":
> Unfortunately, I don't understand this statement. The
> nvidia,tegra194-gte-aon with removed property is in a released kernel
> v6.2. What does it mean "technically"? It's a released kernel thus it is
> a released ABI.
The only property you remove is nvidia,slices, so deprecate it instead,
problem solved.
I don't think the added phandle is a problem, it can't cause backward
compatibility issues since it is new.
Yours,
Linus Walleij
On 13/03/2023 22:49, Dipen Patel wrote:
> On 3/13/23 10:55 AM, Krzysztof Kozlowski wrote:
>> On 13/03/2023 18:05, Dipen Patel wrote:
>>> On 3/12/23 8:47 AM, Krzysztof Kozlowski wrote:
>>>> On 10/03/2023 20:06, Dipen Patel wrote:
>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>> bindings. In addition, it addresses review comments from the
>>>>> previous review round as follows:
>>>>> - Removes nvidia,slices property. This was not necessary as it
>>>>> is a constant value and can be hardcoded inside the driver code.
>>>>> - Adds nvidia,gpio-controller property. This simplifies how GTE driver
>>>>> retrieves GPIO controller instance, see below explanation.
>>>>>
>>>>> 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;
>>>>>
>>>>> This means for every future addition of the compatible string, if else
>>>>> condition statements have to be expanded.
>>>>>
>>>>> With the property:
>>>>> gpio_ctrl = of_parse_phandle(dev->of_node, "nvidia,gpio-controller", 0);
>>>>> ....
>>>>> hte_dev->c = gpiochip_find(gpio_ctrl, tegra_get_gpiochip_from_of_node);
>>>>>
>>>>> We haven't technically started making use of these bindings, so
>>>>> backwards-compatibility shouldn't be an issue yet.
>>>>
>>>> Unfortunately, I don't understand this statement. The
>>>> nvidia,tegra194-gte-aon with removed property is in a released kernel
>>>> v6.2. What does it mean "technically"? It's a released kernel thus it is
>>>> a released ABI.
>>>
>>> There is no active user of that driver, so even if it breaks 6.2, it is fine
>>> as there is no one to complain about it.
>>
>> How do you know? It's a released kernel, thus how can you ask millions
>> of people if they use it or not?
>
> Please help me understand, if I am targeting these set of changes for the kernel
> 6.4, wouldn't all the patches land on v6.4 at the same time no matter the tree it
No, that's not how we do things. Changes *must be bisectable* and *DTS
always* goes to separate branch, so how do you ensure this in your
current flow? I don't see it. The patch #4 should break the bisectability.
> will go from? Also, if user is at v6.2, how this will break as at that version, it
> will have the old bindings and old driver, right?
Bindings define ABI. You defined them like this in v6.2 thus someone is
using them:
1. In other systems, bootloaders, firmwares, SW.
2. via DTS written for v6.2 ABI. Newer kernel should not break existing
DTS and we do not talk about in-kernel DTS, just like we do not talk
about in-kernel user-space applications when using same argument for
their compatibility.
Best regards,
Krzysztof
On 13/03/2023 23:49, Dipen Patel wrote:
> On 3/13/23 2:57 PM, Linus Walleij wrote:
>> Hi Dipen,
>>
>> thanks for maintaining HTE!
>>
>> On Fri, Mar 10, 2023 at 8:06 PM Dipen Patel <[email protected]> wrote:
>>
>>> - nvidia,slices:
>>> - $ref: /schemas/types.yaml#/definitions/uint32
>>
>> I would not delete this, just mark it deprecated.
>>
>> nvidia,slices:
>> $ref: /schemas/types.yaml#/definitions/uint32
>> deprecated: true
>>
>> (And remove it from required, of course)
>>
>> This way you do not need to explain about why it was
>> deleted, it's just deprecated, which is fine.
>
> Great suggestion, thanks, will make changes in the next patch.
When you deprecate it, please make this a separate patch because it is
separate from adding Tegra234 support. Similarly you will want to have a
separate patch to remove support of the property from the driver as well.
Jon
--
nvpublic
On 10/03/2023 19:06, Dipen Patel wrote:
> This patch adds HTE provider support for the Tegra234 and reflects the
> changes made in the device tree as follow.
> - Add slices field in the SoC specific structure
> - Remove gpio chip find by name function instead make use of the phandle
> parsed from the DT node
This patch appears to be 3 things. So this should be 3 patches.
Thanks!
Jon
--
nvpublic
On Fri, Mar 10, 2023 at 8:06 PM Dipen Patel <[email protected]> wrote:
>
> To enable timestamp support for the Tegra234, has_gte variable needs
> to be set true.
>
> Signed-off-by: Dipen Patel <[email protected]>
> Acked-by: Thierry Reding <[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 14c872b6ad05..b904de0b1784 100644
> --- a/drivers/gpio/gpio-tegra186.c
> +++ b/drivers/gpio/gpio-tegra186.c
> @@ -1134,6 +1134,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
>
Acked-by: Bartosz Golaszewski <[email protected]>