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
Dipen Patel (6):
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: Add GTE nodes
.../timestamp/nvidia,tegra194-hte.yaml | 30 ++--
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 | 19 +++
drivers/gpio/gpio-tegra186.c | 1 +
drivers/hte/hte-tegra194-test.c | 2 +-
drivers/hte/hte-tegra194.c | 153 ++++++++++++++++--
8 files changed, 198 insertions(+), 46 deletions(-)
base-commit: 1b929c02afd37871d5afb9d498426f83432e71c2
--
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 f61eb221415b..734c988a7f7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9533,6 +9533,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
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 fdc5bdcd5638..58346c3ff18d 100644
--- a/drivers/gpio/gpio-tegra186.c
+++ b/drivers/gpio/gpio-tegra186.c
@@ -1137,6 +1137,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
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]>
---
v2: Changed how gpio_chip could be aquired for the mapping
drivers/hte/hte-tegra194-test.c | 2 +-
drivers/hte/hte-tegra194.c | 153 ++++++++++++++++++++++++++++----
2 files changed, 139 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..7f0d6e7efd34 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_get_gpiochip_from_of_node(struct gpio_chip *chip, void *data)
{
- return !strcmp(chip->label, data);
+ return chip->of_node == 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,16 @@ 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_get_gpiochip_from_of_node);
+ of_node_put(gpio_ctrl);
if (!hte_dev->c)
return dev_err_probe(dev, -EPROBE_DEFER,
"wait for gpio controller\n");
--
2.17.1
Added timestamp provider support for the Tegra234 in devicetree
bindings.
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.
.../timestamp/nvidia,tegra194-hte.yaml | 30 ++++++++++++-------
1 file changed, 19 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..d0f4ed75baee 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:
@@ -55,11 +54,21 @@ properties:
mentioned in the nvidia GPIO device tree binding document.
const: 1
+if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra194-gte-aon
+ - nvidia,tegra234-gte-aon
+then:
+ required:
+ - nvidia,gpio-controller
+
required:
- compatible
- reg
- interrupts
- - nvidia,slices
- "#timestamp-cells"
additionalProperties: false
@@ -71,7 +80,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 +90,6 @@ examples:
reg = <0x3aa0000 0x10000>;
interrupts = <0 11 0x4>;
nvidia,int-threshold = <1>;
- nvidia,slices = <11>;
#timestamp-cells = <1>;
};
--
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
propertyto 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 | 19 +++++++++++++++++++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 4afcbd60e144..4c92850b1ec4 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1363,7 +1363,6 @@
reg = <0x3aa0000 0x10000>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
nvidia,int-threshold = <1>;
- nvidia,slices = <11>;
#timestamp-cells = <1>;
status = "okay";
};
@@ -1586,7 +1585,7 @@
reg = <0xc1e0000 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 eaf05ee9acd1..4a87490c5fd4 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -1086,6 +1086,15 @@
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>;
+ #timestamp-cells = <1>;
+ status = "okay";
+ };
+
hsp_top0: hsp@3c00000 {
compatible = "nvidia,tegra234-hsp", "nvidia,tegra194-hsp";
reg = <0x03c00000 0xa0000>;
@@ -1603,6 +1612,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,gpio-controller = <&gpio_aon>;
+ #timestamp-cells = <1>;
+ status = "okay";
+ };
+
gen2_i2c: i2c@c240000 {
compatible = "nvidia,tegra194-i2c";
reg = <0xc240000 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
On 14/02/2023 12:55, Dipen Patel wrote:
> Added timestamp provider support for the Tegra234 in devicetree
> bindings.
1. Your commit does much more. You need to explain it why you drop some
property.
2. Bindings go before its usage (in the patchset).
3. Please use scripts/get_maintainers.pl to get a list of necessary
people and lists to CC. It might happen, that command when run on an
older kernel, gives you outdated entries. Therefore please be sure you
base your patches on recent Linux kernel.
>
> 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.
>
> .../timestamp/nvidia,tegra194-hte.yaml | 30 ++++++++++++-------
> 1 file changed, 19 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..d0f4ed75baee 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:
> @@ -55,11 +54,21 @@ properties:
> mentioned in the nvidia GPIO device tree binding document.
> const: 1
>
> +if:
Keep it under allOf (so you no need to re-indent it on next if statement
in the future) and put entire allOf after "required:".
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra194-gte-aon
This is an ABI break. Does your driver handle it?
> + - nvidia,tegra234-gte-aon
> +then:
> + required:
> + - nvidia,gpio-controller
> +
> required:
> - compatible
> - reg
> - interrupts
> - - nvidia,slices
> - "#timestamp-cells"
Best regards,
Krzysztof
On 14/02/2023 12:55, Dipen Patel wrote:
> Add GTE nodes for the tegra234. Also modify AON GTE nodes for the
> tegra194 to remove nvidia,slice property and add nvidia,gpio-controller
> propertyto 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 | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index 4afcbd60e144..4c92850b1ec4 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -1363,7 +1363,6 @@
> reg = <0x3aa0000 0x10000>;
> interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> nvidia,int-threshold = <1>;
> - nvidia,slices = <11>;
> #timestamp-cells = <1>;
> status = "okay";
> };
> @@ -1586,7 +1585,7 @@
> reg = <0xc1e0000 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 eaf05ee9acd1..4a87490c5fd4 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> @@ -1086,6 +1086,15 @@
> 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>;
> + #timestamp-cells = <1>;
> + status = "okay";
Why do you need status? It's okay by default.
> + };
> +
> hsp_top0: hsp@3c00000 {
> compatible = "nvidia,tegra234-hsp", "nvidia,tegra194-hsp";
> reg = <0x03c00000 0xa0000>;
> @@ -1603,6 +1612,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,gpio-controller = <&gpio_aon>;
> + #timestamp-cells = <1>;
> + status = "okay";
Also here
Best regards,
Krzysztof
On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
> On 14/02/2023 12:55, Dipen Patel wrote:
>> Added timestamp provider support for the Tegra234 in devicetree
>> bindings.
>
> 1. Your commit does much more. You need to explain it why you drop some
> property.
ACK, will address it next patch
>
> 2. Bindings go before its usage (in the patchset).
Ack...
>
> 3. Please use scripts/get_maintainers.pl to get a list of necessary
> people and lists to CC. It might happen, that command when run on an
> older kernel, gives you outdated entries. Therefore please be sure you
> base your patches on recent Linux kernel.
It is based on recent linux at the time patch series was sent...
>
>
>>
>> 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.
>>
>> .../timestamp/nvidia,tegra194-hte.yaml | 30 ++++++++++++-------
>> 1 file changed, 19 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..d0f4ed75baee 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:
>> @@ -55,11 +54,21 @@ properties:
>> mentioned in the nvidia GPIO device tree binding document.
>> const: 1
>>
>> +if:
>
> Keep it under allOf (so you no need to re-indent it on next if statement
> in the future) and put entire allOf after "required:".
>
Ack...
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - nvidia,tegra194-gte-aon
>
> This is an ABI break. Does your driver handle it?
yes, handling patch is part of this patch series.
>
>> + - nvidia,tegra234-gte-aon
>> +then:
>> + required:
>> + - nvidia,gpio-controller
>> +
>> required:
>> - compatible
>> - reg
>> - interrupts
>> - - nvidia,slices
>> - "#timestamp-cells"
>
>
> Best regards,
> Krzysztof
>
On 08/03/2023 19:45, Dipen Patel wrote:
> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>> On 14/02/2023 12:55, Dipen Patel wrote:
>>> Added timestamp provider support for the Tegra234 in devicetree
>>> bindings.
>>
>> 1. Your commit does much more. You need to explain it why you drop some
>> property.
> ACK, will address it next patch
>>
>> 2. Bindings go before its usage (in the patchset).
> Ack...
>>
>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>> people and lists to CC. It might happen, that command when run on an
>> older kernel, gives you outdated entries. Therefore please be sure you
>> base your patches on recent Linux kernel.
> It is based on recent linux at the time patch series was sent...
That's good but then why you do not use scripts/get_maintainers.pl? The
hint about recent kernel was just a hint... Just do not invent addresses
by yourself and use the tool to get them right.
(...)
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - nvidia,tegra194-gte-aon
>>
>> This is an ABI break. Does your driver handle it?
> yes, handling patch is part of this patch series.
Can you point me to the code which does it? I see "return -ENODEV;", so
I think you do not handle ABI break. I could miss something but since
you disagree with me, please at least bring some arguments...
Best regards,
Krzysztof
On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
> On 08/03/2023 19:45, Dipen Patel wrote:
>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>> bindings.
>>>
>>> 1. Your commit does much more. You need to explain it why you drop some
>>> property.
>> ACK, will address it next patch
>>>
>>> 2. Bindings go before its usage (in the patchset).
>> Ack...
>>>
>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>> people and lists to CC. It might happen, that command when run on an
>>> older kernel, gives you outdated entries. Therefore please be sure you
>>> base your patches on recent Linux kernel.
>> It is based on recent linux at the time patch series was sent...
>
> That's good but then why you do not use scripts/get_maintainers.pl? The
> hint about recent kernel was just a hint... Just do not invent addresses
> by yourself and use the tool to get them right.
>
I will take a note for the next patch series to add any missing people. The current
list of people/group is what historically helped review this new timestamp/hte subsystem.
> (...)
>
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + enum:
>>>> + - nvidia,tegra194-gte-aon
>>>
>>> This is an ABI break. Does your driver handle it?
>> yes, handling patch is part of this patch series.
>
> Can you point me to the code which does it? I see "return -ENODEV;", so
> I think you do not handle ABI break. I could miss something but since
> you disagree with me, please at least bring some arguments...
Refer to patch https://patchwork.kernel.org/project/timestamp/patch/[email protected]/
which has compatible properties added and also code changes to reflect addition/deletion of some
properties.
I am not sure I have understood about ABI break comment. How else one should handle if
there is no related gpio controller property found? I am assuming you are referring to the
below code from the patch 2 (link above) when you said "return -ENODEV".
- 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_get_gpiochip_from_of_node)
>
>
> Best regards,
> Krzysztof
>
On 2/16/23 6:18 AM, Krzysztof Kozlowski wrote:
> On 14/02/2023 12:55, Dipen Patel wrote:
>> Add GTE nodes for the tegra234. Also modify AON GTE nodes for the
>> tegra194 to remove nvidia,slice property and add nvidia,gpio-controller
>> propertyto 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 | 19 +++++++++++++++++++
>> 2 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
>> index 4afcbd60e144..4c92850b1ec4 100644
>> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
>> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
>> @@ -1363,7 +1363,6 @@
>> reg = <0x3aa0000 0x10000>;
>> interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
>> nvidia,int-threshold = <1>;
>> - nvidia,slices = <11>;
>> #timestamp-cells = <1>;
>> status = "okay";
>> };
>> @@ -1586,7 +1585,7 @@
>> reg = <0xc1e0000 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 eaf05ee9acd1..4a87490c5fd4 100644
>> --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
>> +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
>> @@ -1086,6 +1086,15 @@
>> 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>;
>> + #timestamp-cells = <1>;
>> + status = "okay";
>
> Why do you need status? It's okay by default.
what's harm of having to explicitly mentioned? I can see status = okay in this dtsi file
for other nodes as well and was just following that.
>
>> + };
>> +
>> hsp_top0: hsp@3c00000 {
>> compatible = "nvidia,tegra234-hsp", "nvidia,tegra194-hsp";
>> reg = <0x03c00000 0xa0000>;
>> @@ -1603,6 +1612,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,gpio-controller = <&gpio_aon>;
>> + #timestamp-cells = <1>;
>> + status = "okay";
>
>
> Also here
>
> Best regards,
> Krzysztof
>
On 08/03/2023 21:13, Dipen Patel wrote:
> On 2/16/23 6:18 AM, Krzysztof Kozlowski wrote:
>> On 14/02/2023 12:55, Dipen Patel wrote:
>>> Add GTE nodes for the tegra234. Also modify AON GTE nodes for the
>>> tegra194 to remove nvidia,slice property and add nvidia,gpio-controller
>>> propertyto 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 | 19 +++++++++++++++++++
>>> 2 files changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
>>> index 4afcbd60e144..4c92850b1ec4 100644
>>> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
>>> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
>>> @@ -1363,7 +1363,6 @@
>>> reg = <0x3aa0000 0x10000>;
>>> interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
>>> nvidia,int-threshold = <1>;
>>> - nvidia,slices = <11>;
>>> #timestamp-cells = <1>;
>>> status = "okay";
>>> };
>>> @@ -1586,7 +1585,7 @@
>>> reg = <0xc1e0000 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 eaf05ee9acd1..4a87490c5fd4 100644
>>> --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
>>> +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
>>> @@ -1086,6 +1086,15 @@
>>> 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>;
>>> + #timestamp-cells = <1>;
>>> + status = "okay";
>>
>> Why do you need status? It's okay by default.
> what's harm of having to explicitly mentioned?
Because useless code is not helping any review. We do not add other
useless properties, or shall we add them?
>I can see status = okay in this dtsi file
> for other nodes as well and was just following that.
So if you see a bug somewhere, you also duplicate it in your code?
Best regards,
Krzysztof
On 08/03/2023 21:09, Dipen Patel wrote:
> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>> On 08/03/2023 19:45, Dipen Patel wrote:
>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>> bindings.
>>>>
>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>> property.
>>> ACK, will address it next patch
>>>>
>>>> 2. Bindings go before its usage (in the patchset).
>>> Ack...
>>>>
>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>> people and lists to CC. It might happen, that command when run on an
>>>> older kernel, gives you outdated entries. Therefore please be sure you
>>>> base your patches on recent Linux kernel.
>>> It is based on recent linux at the time patch series was sent...
>>
>> That's good but then why you do not use scripts/get_maintainers.pl? The
>> hint about recent kernel was just a hint... Just do not invent addresses
>> by yourself and use the tool to get them right.
>>
> I will take a note for the next patch series to add any missing people. The current
> list of people/group is what historically helped review this new timestamp/hte subsystem.
>
>> (...)
>>
>>>>> + properties:
>>>>> + compatible:
>>>>> + contains:
>>>>> + enum:
>>>>> + - nvidia,tegra194-gte-aon
>>>>
>>>> This is an ABI break. Does your driver handle it?
>>> yes, handling patch is part of this patch series.
>>
>> Can you point me to the code which does it? I see "return -ENODEV;", so
>> I think you do not handle ABI break. I could miss something but since
>> you disagree with me, please at least bring some arguments...
> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/[email protected]/
> which has compatible properties added and also code changes to reflect addition/deletion of some
> properties.
I referred to the code which breaks the ABI.
>
> I am not sure I have understood about ABI break comment. How else one should handle if
> there is no related gpio controller property found?
In a way it does not break existing users? There are many ways to handle
it, but I don't know your code to point you.
> I am assuming you are referring to the
> below code from the patch 2 (link above) when you said "return -ENODEV".
Your bindings patch points to ABI break without any
explanation/justification. Then your code #2 patch actually breaks it,
also without any justification.
Best regards,
Krzysztof
On 3/8/23 10:16 PM, Krzysztof Kozlowski wrote:
> On 08/03/2023 21:09, Dipen Patel wrote:
>> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>>> On 08/03/2023 19:45, Dipen Patel wrote:
>>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>>> bindings.
>>>>>
>>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>>> property.
>>>> ACK, will address it next patch
>>>>>
>>>>> 2. Bindings go before its usage (in the patchset).
>>>> Ack...
>>>>>
>>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>>> people and lists to CC. It might happen, that command when run on an
>>>>> older kernel, gives you outdated entries. Therefore please be sure you
>>>>> base your patches on recent Linux kernel.
>>>> It is based on recent linux at the time patch series was sent...
>>>
>>> That's good but then why you do not use scripts/get_maintainers.pl? The
>>> hint about recent kernel was just a hint... Just do not invent addresses
>>> by yourself and use the tool to get them right.
>>>
>> I will take a note for the next patch series to add any missing people. The current
>> list of people/group is what historically helped review this new timestamp/hte subsystem.
>>
>>> (...)
>>>
>>>>>> + properties:
>>>>>> + compatible:
>>>>>> + contains:
>>>>>> + enum:
>>>>>> + - nvidia,tegra194-gte-aon
>>>>>
>>>>> This is an ABI break. Does your driver handle it?
>>>> yes, handling patch is part of this patch series.
>>>
>>> Can you point me to the code which does it? I see "return -ENODEV;", so
>>> I think you do not handle ABI break. I could miss something but since
>>> you disagree with me, please at least bring some arguments...
>> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/[email protected]/
>> which has compatible properties added and also code changes to reflect addition/deletion of some
>> properties.
>
> I referred to the code which breaks the ABI.
>
>>
>> I am not sure I have understood about ABI break comment. How else one should handle if
>> there is no related gpio controller property found?
>
> In a way it does not break existing users? There are many ways to handle
> it, but I don't know your code to point you.
It is new subsystem and has only one driver which uses it so far. This was a decision taken
after review comments (By Thierry, also in the mailing list) to add this property (nvidia,gpio-controller)
and necessary changes have been made to existing user. From now on, it has to follow this change.
>
>> I am assuming you are referring to the
>> below code from the patch 2 (link above) when you said "return -ENODEV".
>
>
> Your bindings patch points to ABI break without any
> explanation/justification. Then your code #2 patch actually breaks it,
> also without any justification.
I am going to add explanation/justification in the commit message in the next patch series. But to give
you context, discussion happened here https://patchwork.ozlabs.org/project/linux-gpio/patch/[email protected]/
>
> Best regards,
> Krzysztof
>
On 09/03/2023 19:49, Dipen Patel wrote:
> On 3/8/23 10:16 PM, Krzysztof Kozlowski wrote:
>> On 08/03/2023 21:09, Dipen Patel wrote:
>>> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>>>> On 08/03/2023 19:45, Dipen Patel wrote:
>>>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>>>> bindings.
>>>>>>
>>>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>>>> property.
>>>>> ACK, will address it next patch
>>>>>>
>>>>>> 2. Bindings go before its usage (in the patchset).
>>>>> Ack...
>>>>>>
>>>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>>>> people and lists to CC. It might happen, that command when run on an
>>>>>> older kernel, gives you outdated entries. Therefore please be sure you
>>>>>> base your patches on recent Linux kernel.
>>>>> It is based on recent linux at the time patch series was sent...
>>>>
>>>> That's good but then why you do not use scripts/get_maintainers.pl? The
>>>> hint about recent kernel was just a hint... Just do not invent addresses
>>>> by yourself and use the tool to get them right.
>>>>
>>> I will take a note for the next patch series to add any missing people. The current
>>> list of people/group is what historically helped review this new timestamp/hte subsystem.
>>>
>>>> (...)
>>>>
>>>>>>> + properties:
>>>>>>> + compatible:
>>>>>>> + contains:
>>>>>>> + enum:
>>>>>>> + - nvidia,tegra194-gte-aon
>>>>>>
>>>>>> This is an ABI break. Does your driver handle it?
>>>>> yes, handling patch is part of this patch series.
>>>>
>>>> Can you point me to the code which does it? I see "return -ENODEV;", so
>>>> I think you do not handle ABI break. I could miss something but since
>>>> you disagree with me, please at least bring some arguments...
>>> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/[email protected]/
>>> which has compatible properties added and also code changes to reflect addition/deletion of some
>>> properties.
>>
>> I referred to the code which breaks the ABI.
>>
>>>
>>> I am not sure I have understood about ABI break comment. How else one should handle if
>>> there is no related gpio controller property found?
>>
>> In a way it does not break existing users? There are many ways to handle
>> it, but I don't know your code to point you.
>
> It is new subsystem and has only one driver which uses it so far.
We do not talk about subsystem, but Tegra SoC, which is not new. Unless
you meant this is new SoC/DTS?
> This was a decision taken
> after review comments (By Thierry, also in the mailing list) to add this property (nvidia,gpio-controller)
> and necessary changes have been made to existing user. From now on, it has to follow this change.
What is "it" which has to follow? There are rules for stable ABI and
commit msg does not explain why they should not be followed.
>
>>
>>> I am assuming you are referring to the
>>> below code from the patch 2 (link above) when you said "return -ENODEV".
>>
>>
>> Your bindings patch points to ABI break without any
>> explanation/justification. Then your code #2 patch actually breaks it,
>> also without any justification.
> I am going to add explanation/justification in the commit message in the next patch series. But to give
> you context, discussion happened here https://patchwork.ozlabs.org/project/linux-gpio/patch/[email protected]/
Either too many messages (and I missed something) or I could not find
why ABI break is accepted and justified.
Best regards,
Krzysztof
On 3/10/23 12:45 AM, Krzysztof Kozlowski wrote:
> On 09/03/2023 19:49, Dipen Patel wrote:
>> On 3/8/23 10:16 PM, Krzysztof Kozlowski wrote:
>>> On 08/03/2023 21:09, Dipen Patel wrote:
>>>> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>>>>> On 08/03/2023 19:45, Dipen Patel wrote:
>>>>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>>>>> bindings.
>>>>>>>
>>>>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>>>>> property.
>>>>>> ACK, will address it next patch
>>>>>>>
>>>>>>> 2. Bindings go before its usage (in the patchset).
>>>>>> Ack...
>>>>>>>
>>>>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>>>>> people and lists to CC. It might happen, that command when run on an
>>>>>>> older kernel, gives you outdated entries. Therefore please be sure you
>>>>>>> base your patches on recent Linux kernel.
>>>>>> It is based on recent linux at the time patch series was sent...
>>>>>
>>>>> That's good but then why you do not use scripts/get_maintainers.pl? The
>>>>> hint about recent kernel was just a hint... Just do not invent addresses
>>>>> by yourself and use the tool to get them right.
>>>>>
>>>> I will take a note for the next patch series to add any missing people. The current
>>>> list of people/group is what historically helped review this new timestamp/hte subsystem.
>>>>
>>>>> (...)
>>>>>
>>>>>>>> + properties:
>>>>>>>> + compatible:
>>>>>>>> + contains:
>>>>>>>> + enum:
>>>>>>>> + - nvidia,tegra194-gte-aon
>>>>>>>
>>>>>>> This is an ABI break. Does your driver handle it?
>>>>>> yes, handling patch is part of this patch series.
>>>>>
>>>>> Can you point me to the code which does it? I see "return -ENODEV;", so
>>>>> I think you do not handle ABI break. I could miss something but since
>>>>> you disagree with me, please at least bring some arguments...
>>>> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/[email protected]/
>>>> which has compatible properties added and also code changes to reflect addition/deletion of some
>>>> properties.
>>>
>>> I referred to the code which breaks the ABI.
>>>
>>>>
>>>> I am not sure I have understood about ABI break comment. How else one should handle if
>>>> there is no related gpio controller property found?
>>>
>>> In a way it does not break existing users? There are many ways to handle
>>> it, but I don't know your code to point you.
>>
>> It is new subsystem and has only one driver which uses it so far.
>
> We do not talk about subsystem, but Tegra SoC, which is not new. Unless
> you meant this is new SoC/DTS?
>
>> This was a decision taken
>> after review comments (By Thierry, also in the mailing list) to add this property (nvidia,gpio-controller)
>> and necessary changes have been made to existing user. From now on, it has to follow this change.
>
> What is "it" which has to follow? There are rules for stable ABI and
> commit msg does not explain why they should not be followed.
"It" here means hte-tegra194.c HTE provider which is the only one and not being used by any entity
yet.
>
>>
>>>
>>>> I am assuming you are referring to the
>>>> below code from the patch 2 (link above) when you said "return -ENODEV".
>>>
>>>
>>> Your bindings patch points to ABI break without any
>>> explanation/justification. Then your code #2 patch actually breaks it,
>>> also without any justification.
>> I am going to add explanation/justification in the commit message in the next patch series. But to give
>> you context, discussion happened here https://patchwork.ozlabs.org/project/linux-gpio/patch/[email protected]/
>
> Either too many messages (and I missed something) or I could not find
> why ABI break is accepted and justified.
https://patchwork.ozlabs.org/project/linux-gpio/patch/[email protected]/#3000908 and
affected code/comment at https://patchwork.ozlabs.org/project/linux-gpio/patch/[email protected]/#3000908.
Will it help if I send new patch series with detailed commit message?
>
>
> Best regards,
> Krzysztof
>
On 10/03/2023 18:19, Dipen Patel wrote:
> On 3/10/23 12:45 AM, Krzysztof Kozlowski wrote:
>> On 09/03/2023 19:49, Dipen Patel wrote:
>>> On 3/8/23 10:16 PM, Krzysztof Kozlowski wrote:
>>>> On 08/03/2023 21:09, Dipen Patel wrote:
>>>>> On 3/8/23 11:05 AM, Krzysztof Kozlowski wrote:
>>>>>> On 08/03/2023 19:45, Dipen Patel wrote:
>>>>>>> On 2/16/23 6:17 AM, Krzysztof Kozlowski wrote:
>>>>>>>> On 14/02/2023 12:55, Dipen Patel wrote:
>>>>>>>>> Added timestamp provider support for the Tegra234 in devicetree
>>>>>>>>> bindings.
>>>>>>>>
>>>>>>>> 1. Your commit does much more. You need to explain it why you drop some
>>>>>>>> property.
>>>>>>> ACK, will address it next patch
>>>>>>>>
>>>>>>>> 2. Bindings go before its usage (in the patchset).
>>>>>>> Ack...
>>>>>>>>
>>>>>>>> 3. Please use scripts/get_maintainers.pl to get a list of necessary
>>>>>>>> people and lists to CC. It might happen, that command when run on an
>>>>>>>> older kernel, gives you outdated entries. Therefore please be sure you
>>>>>>>> base your patches on recent Linux kernel.
>>>>>>> It is based on recent linux at the time patch series was sent...
>>>>>>
>>>>>> That's good but then why you do not use scripts/get_maintainers.pl? The
>>>>>> hint about recent kernel was just a hint... Just do not invent addresses
>>>>>> by yourself and use the tool to get them right.
>>>>>>
>>>>> I will take a note for the next patch series to add any missing people. The current
>>>>> list of people/group is what historically helped review this new timestamp/hte subsystem.
>>>>>
>>>>>> (...)
>>>>>>
>>>>>>>>> + properties:
>>>>>>>>> + compatible:
>>>>>>>>> + contains:
>>>>>>>>> + enum:
>>>>>>>>> + - nvidia,tegra194-gte-aon
>>>>>>>>
>>>>>>>> This is an ABI break. Does your driver handle it?
>>>>>>> yes, handling patch is part of this patch series.
>>>>>>
>>>>>> Can you point me to the code which does it? I see "return -ENODEV;", so
>>>>>> I think you do not handle ABI break. I could miss something but since
>>>>>> you disagree with me, please at least bring some arguments...
>>>>> Refer to patch https://patchwork.kernel.org/project/timestamp/patch/[email protected]/
>>>>> which has compatible properties added and also code changes to reflect addition/deletion of some
>>>>> properties.
>>>>
>>>> I referred to the code which breaks the ABI.
>>>>
>>>>>
>>>>> I am not sure I have understood about ABI break comment. How else one should handle if
>>>>> there is no related gpio controller property found?
>>>>
>>>> In a way it does not break existing users? There are many ways to handle
>>>> it, but I don't know your code to point you.
>>>
>>> It is new subsystem and has only one driver which uses it so far.
>>
>> We do not talk about subsystem, but Tegra SoC, which is not new. Unless
>> you meant this is new SoC/DTS?
>>
>>> This was a decision taken
>>> after review comments (By Thierry, also in the mailing list) to add this property (nvidia,gpio-controller)
>>> and necessary changes have been made to existing user. From now on, it has to follow this change.
>>
>> What is "it" which has to follow? There are rules for stable ABI and
>> commit msg does not explain why they should not be followed.
>
> "It" here means hte-tegra194.c HTE provider which is the only one and not being used by any entity
> yet.
>
>>
>>>
>>>>
>>>>> I am assuming you are referring to the
>>>>> below code from the patch 2 (link above) when you said "return -ENODEV".
>>>>
>>>>
>>>> Your bindings patch points to ABI break without any
>>>> explanation/justification. Then your code #2 patch actually breaks it,
>>>> also without any justification.
>>> I am going to add explanation/justification in the commit message in the next patch series. But to give
>>> you context, discussion happened here https://patchwork.ozlabs.org/project/linux-gpio/patch/[email protected]/
>>
>> Either too many messages (and I missed something) or I could not find
>> why ABI break is accepted and justified.
>
> https://patchwork.ozlabs.org/project/linux-gpio/patch/[email protected]/#3000908 and
> affected code/comment at https://patchwork.ozlabs.org/project/linux-gpio/patch/[email protected]/#3000908.
>
> Will it help if I send new patch series with detailed commit message?
Yes. If the binding is not used, it's a perfectly valid reason and
should be mentioned in commit msg.
Best regards,
Krzysztof