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 without breaking the
Tegra194 provider. 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 provider code to address new dt binding for Tegra234
without breaking it for the Tegra194 chip.
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
The V4 patch series:
- Logically divides dt binding and tegra HTE provider patches from v3
- Maintains backward compatibilty for the Tegra194
The V5 patch series:
- Reflect review comments for the patch
"dt-bindings: timestamp: Add nvidia,gpio-controller"
- Documentation changes including renaming of the file
The V6 patch series:
- Merges patch
"dt-bindings: timestamp: Add nvidia,gpio-controller" with the patch
"dt-bindings: timestamp: Add Tegra234 support"
Dipen Patel (9):
MAINTAINERS: Add HTE/timestamp subsystem details
dt-bindings: timestamp: Add Tegra234 support
dt-bindings: timestamp: Deprecate nvidia,slices property
arm64: tegra: Add Tegra234 GTE nodes
hte: Re-phrase tegra API document
hte: Add Tegra234 provider
hte: Deprecate nvidia,slices property
hte: handle nvidia,gpio-controller property
gpio: tegra186: Add Tegra234 hte support
.../timestamp/nvidia,tegra194-hte.yaml | 66 ++++++-
Documentation/driver-api/hte/index.rst | 2 +-
.../hte/{tegra194-hte.rst => tegra-hte.rst} | 33 ++--
MAINTAINERS | 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 | 167 ++++++++++++++++--
8 files changed, 252 insertions(+), 39 deletions(-)
rename Documentation/driver-api/hte/{tegra194-hte.rst => tegra-hte.rst} (50%)
base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
--
2.17.1
The dt binding adds nvidia,gpio-controller property from Tegra234 SoC
onwards to simplify code handling gpio chip search. The gpio chip search
is needed for the AON GPIO GTE instances to map the hardware timestamp
GPIO request (coming from the GPIO framework) to the tegra HTE
providers. The patch also adds new gpio chip match function to match
from the fwnode instead of the gpio controller label. The addition
of the property does not break ABI for the existing Tegra194 code.
Signed-off-by: Dipen Patel <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
---
drivers/hte/hte-tegra194.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
index 945c68c5e476..2c485ff5be22 100644
--- a/drivers/hte/hte-tegra194.c
+++ b/drivers/hte/hte-tegra194.c
@@ -679,6 +679,11 @@ static int tegra_get_gpiochip_from_name(struct gpio_chip *chip, void *data)
return !strcmp(chip->label, data);
}
+static int tegra_gpiochip_match(struct gpio_chip *chip, void *data)
+{
+ return chip->fwnode == of_node_to_fwnode(data);
+}
+
static int tegra_hte_probe(struct platform_device *pdev)
{
int ret;
@@ -687,6 +692,7 @@ 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;
@@ -754,15 +760,23 @@ static int tegra_hte_probe(struct platform_device *pdev)
gc->match_from_linedata = tegra_hte_match_from_linedata;
if (of_device_is_compatible(dev->of_node,
- "nvidia,tegra194-gte-aon"))
+ "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;
+ } else {
+ 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,
--
2.17.1
The property is not necessary as it is a constant value and can be
hardcoded in the driver code.
Signed-off-by: Dipen Patel <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Rob Herring <[email protected]>
---
.../bindings/timestamp/nvidia,tegra194-hte.yaml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
index 5de1eca9cbcd..456797967adc 100644
--- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
+++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
@@ -42,10 +42,13 @@ properties:
nvidia,slices:
$ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
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 the value depends on the HTE instance in the chip.
+ property and the value depends on the HTE instance in the chip. The AON
+ GTE instances for both Tegra194 and Tegra234 has 3 slices. The Tegra194
+ LIC instance has 11 slices and Tegra234 LIC has 17 slices.
enum: [3, 11, 17]
nvidia,gpio-controller:
@@ -66,7 +69,6 @@ required:
- compatible
- reg
- interrupts
- - nvidia,slices
- "#timestamp-cells"
allOf:
@@ -123,7 +125,6 @@ examples:
reg = <0xc1e0000 0x10000>;
interrupts = <0 13 0x4>;
nvidia,int-threshold = <1>;
- nvidia,slices = <3>;
#timestamp-cells = <1>;
};
@@ -133,7 +134,6 @@ examples:
reg = <0x3aa0000 0x10000>;
interrupts = <0 11 0x4>;
nvidia,int-threshold = <1>;
- nvidia,slices = <11>;
#timestamp-cells = <1>;
};
--
2.17.1
The Tegra234 AON GPIO instance and LIC IRQ support HTE. For the GPIO
HTE support, it also requires to add mapping between GPIO and HTE
framework same as it was done with Tegra194 SoC.
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.
v4:
- Logically divide the original v3 patch as follows
- Created this Tegra234 support patch
- Created deprecated nvidia,slices patch
- Created handle nvidia,gpio-controller patch
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
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]>
Acked-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Linus Walleij <[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
Make Tegra194 API document generic to make it applicable for
current and future tegra hte providers.
Signed-off-by: Dipen Patel <[email protected]>
Reviewed-by: Bagas Sanjaya <[email protected]>
---
v5:
- rename tegra194-hte.rst to tegra-hte.rst
Documentation/driver-api/hte/index.rst | 2 +-
.../hte/{tegra194-hte.rst => tegra-hte.rst} | 33 +++++++++----------
2 files changed, 17 insertions(+), 18 deletions(-)
rename Documentation/driver-api/hte/{tegra194-hte.rst => tegra-hte.rst} (50%)
diff --git a/Documentation/driver-api/hte/index.rst b/Documentation/driver-api/hte/index.rst
index 9f43301c05dc..29011de9a4b8 100644
--- a/Documentation/driver-api/hte/index.rst
+++ b/Documentation/driver-api/hte/index.rst
@@ -18,5 +18,5 @@ HTE Tegra Provider
.. toctree::
:maxdepth: 1
- tegra194-hte
+ tegra-hte
diff --git a/Documentation/driver-api/hte/tegra194-hte.rst b/Documentation/driver-api/hte/tegra-hte.rst
similarity index 50%
rename from Documentation/driver-api/hte/tegra194-hte.rst
rename to Documentation/driver-api/hte/tegra-hte.rst
index f2d617265546..85e654772782 100644
--- a/Documentation/driver-api/hte/tegra194-hte.rst
+++ b/Documentation/driver-api/hte/tegra-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
On 14/04/2023 02:44, Dipen Patel wrote:
> 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 without breaking the
> Tegra194 provider. 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 provider code to address new dt binding for Tegra234
> without breaking it for the Tegra194 chip.
>
> 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.
All your emails miss PATCH prefix. Use `git format-patch` to generate
proper versioned patch. Stripping important part messes up with our
filters. We have quite a lot of emails, so proper filtering is important.
Best regards,
Krzysztof
On Fri, Apr 14, 2023 at 9:36 AM Krzysztof Kozlowski
<[email protected]> wrote:
> On 14/04/2023 02:44, Dipen Patel wrote:
> > 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 without breaking the
> > Tegra194 provider. 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 provider code to address new dt binding for Tegra234
> > without breaking it for the Tegra194 chip.
> >
> > 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.
>
> All your emails miss PATCH prefix. Use `git format-patch` to generate
> proper versioned patch. Stripping important part messes up with our
> filters. We have quite a lot of emails, so proper filtering is important.
At this point I would even recommend kernel maintainers to get b4
into the workflow:
https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1
This tool will also implement other desired behaviours and version
the patch set for you.
I am gradually adopting it for my own work, using it all the time when
applying patches but also getting better at using it for submitting
them. It has a small overhead (like learning and memorizing the
subcommands) but once you get used to it, it is really helpful.
Yours,
Linus Walleij
On Fri, Apr 14, 2023 at 09:36:15AM +0200, Krzysztof Kozlowski wrote:
> On 14/04/2023 02:44, Dipen Patel wrote:
> > 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 without breaking the
> > Tegra194 provider. 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 provider code to address new dt binding for Tegra234
> > without breaking it for the Tegra194 chip.
> >
> > 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.
>
> All your emails miss PATCH prefix. Use `git format-patch` to generate
> proper versioned patch. Stripping important part messes up with our
> filters. We have quite a lot of emails, so proper filtering is important.
I used to get this wrong as well because I didn't know (or perhaps it
didn't exist yet at the time) --reroll-count|-v and used to manually
override --subject-prefix.
Thierry
On 4/14/23 1:07 AM, Linus Walleij wrote:
> On Fri, Apr 14, 2023 at 9:36 AM Krzysztof Kozlowski
> <[email protected]> wrote:
>> On 14/04/2023 02:44, Dipen Patel wrote:
>>> 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 without breaking the
>>> Tegra194 provider. 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 provider code to address new dt binding for Tegra234
>>> without breaking it for the Tegra194 chip.
>>>
>>> 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.
>>
>> All your emails miss PATCH prefix. Use `git format-patch` to generate
>> proper versioned patch. Stripping important part messes up with our
>> filters. We have quite a lot of emails, so proper filtering is important.
>
> At this point I would even recommend kernel maintainers to get b4
> into the workflow:
> https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1
Thanks for sharing...will have to look into it to avoid such mistakes.
>
> This tool will also implement other desired behaviours and version
> the patch set for you.
>
> I am gradually adopting it for my own work, using it all the time when
> applying patches but also getting better at using it for submitting
> them. It has a small overhead (like learning and memorizing the
> subcommands) but once you get used to it, it is really helpful.
>
> Yours,
> Linus Walleij
On 4/14/23 12:36 AM, Krzysztof Kozlowski wrote:
> On 14/04/2023 02:44, Dipen Patel wrote:
>> 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 without breaking the
>> Tegra194 provider. 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 provider code to address new dt binding for Tegra234
>> without breaking it for the Tegra194 chip.
>>
>> 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.
>
> All your emails miss PATCH prefix. Use `git format-patch` to generate
> proper versioned patch. Stripping important part messes up with our
> filters. We have quite a lot of emails, so proper filtering is important.
My bad...excitement of sending the patch series got hold of me :) Now I have realized
it is been happening since the beginning. Since all the previous patches have been
sent without PATCH prefix, is it ok for this version as it is or do you want me to resend
with proper prefix?
>
> Best regards,
> Krzysztof
>
On 14/04/2023 19:14, Dipen Patel wrote:
> On 4/14/23 12:36 AM, Krzysztof Kozlowski wrote:
>> On 14/04/2023 02:44, Dipen Patel wrote:
>>> 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 without breaking the
>>> Tegra194 provider. 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 provider code to address new dt binding for Tegra234
>>> without breaking it for the Tegra194 chip.
>>>
>>> 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.
>>
>> All your emails miss PATCH prefix. Use `git format-patch` to generate
>> proper versioned patch. Stripping important part messes up with our
>> filters. We have quite a lot of emails, so proper filtering is important.
>
> My bad...excitement of sending the patch series got hold of me :) Now I have realized
> it is been happening since the beginning. Since all the previous patches have been
> sent without PATCH prefix, is it ok for this version as it is or do you want me to resend
> with proper prefix?
>
It's okay for me, no need to resend. I just wanted to bring this to your
attention, so future patchsets can be improved.
Best regards,
Krzysztof