* [PATCH AUTOSEL 5.4 003/266] ASoC: tegra: tegra_wm8903: Support nvidia, headset property
From: Sasha Levin @ 2020-06-18 1:12 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA
Cc: Dmitry Osipenko, Mark Brown, Sasha Levin,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200618011631.604574-1-sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
The microphone-jack state needs to be masked in a case of a 4-pin jack
when microphone and ground pins are shorted. Presence of nvidia,headset
tells that WM8903 CODEC driver should mask microphone's status if short
circuit is detected, i.e headphones are inserted.
Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Link: https://lore.kernel.org/r/20200330204011.18465-3-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Sasha Levin <sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
sound/soc/tegra/tegra_wm8903.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/soc/tegra/tegra_wm8903.c b/sound/soc/tegra/tegra_wm8903.c
index 6211dfda2195..0fa01cacfec9 100644
--- a/sound/soc/tegra/tegra_wm8903.c
+++ b/sound/soc/tegra/tegra_wm8903.c
@@ -159,6 +159,7 @@ static int tegra_wm8903_init(struct snd_soc_pcm_runtime *rtd)
struct snd_soc_component *component = codec_dai->component;
struct snd_soc_card *card = rtd->card;
struct tegra_wm8903 *machine = snd_soc_card_get_drvdata(card);
+ int shrt = 0;
if (gpio_is_valid(machine->gpio_hp_det)) {
tegra_wm8903_hp_jack_gpio.gpio = machine->gpio_hp_det;
@@ -171,12 +172,15 @@ static int tegra_wm8903_init(struct snd_soc_pcm_runtime *rtd)
&tegra_wm8903_hp_jack_gpio);
}
+ if (of_property_read_bool(card->dev->of_node, "nvidia,headset"))
+ shrt = SND_JACK_MICROPHONE;
+
snd_soc_card_jack_new(rtd->card, "Mic Jack", SND_JACK_MICROPHONE,
&tegra_wm8903_mic_jack,
tegra_wm8903_mic_jack_pins,
ARRAY_SIZE(tegra_wm8903_mic_jack_pins));
wm8903_mic_detect(component, &tegra_wm8903_mic_jack, SND_JACK_MICROPHONE,
- 0);
+ shrt);
snd_soc_dapm_force_enable_pin(&card->dapm, "MICBIAS");
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 169/266] arm64: tegra: Fix ethernet phy-mode for Jetson Xavier
From: Sasha Levin @ 2020-06-18 1:14 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA
Cc: Jon Hunter, Thierry Reding, Sasha Levin,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200618011631.604574-1-sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[ Upstream commit bba25915b172c72f6fa635f091624d799e3c9cae ]
The 'phy-mode' property is currently defined as 'rgmii' for Jetson
Xavier. This indicates that the RGMII RX and TX delays are set by the
MAC and the internal delays set by the PHY are not used.
If the Marvell PHY driver is enabled, such that it is used and not the
generic PHY, ethernet failures are seen (DHCP is failing to obtain an
IP address) and this is caused because the Marvell PHY driver is
disabling the internal RX and TX delays. For Jetson Xavier the internal
PHY RX and TX delay should be used and so fix this by setting the
'phy-mode' to 'rgmii-id' and not 'rgmii'.
Fixes: f89b58ce71a9 ("arm64: tegra: Add ethernet controller on Tegra194")
Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Sasha Levin <sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
index 02909a48dfcd..7899759a12f8 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -32,7 +32,7 @@ ethernet@2490000 {
phy-reset-gpios = <&gpio TEGRA194_MAIN_GPIO(G, 5) GPIO_ACTIVE_LOW>;
phy-handle = <&phy>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
mdio {
#address-cells = <1>;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 170/266] arm64: tegra: Fix flag for 64-bit resources in 'ranges' property
From: Sasha Levin @ 2020-06-18 1:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vidya Sagar, Thierry Reding, Sasha Levin, devicetree, linux-tegra
In-Reply-To: <20200618011631.604574-1-sashal@kernel.org>
From: Vidya Sagar <vidyas@nvidia.com>
[ Upstream commit 3482a7afb261e2de9269a7f9ad0f4a3a82a83a53 ]
Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.
Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 457b815d57f4..2f3926719434 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1192,7 +1192,7 @@ pcie@14100000 {
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x30100000 0x0 0x30100000 0x0 0x00100000 /* downstream I/O (1MB) */
- 0xc2000000 0x12 0x00000000 0x12 0x00000000 0x0 0x30000000 /* prefetchable memory (768MB) */
+ 0xc3000000 0x12 0x00000000 0x12 0x00000000 0x0 0x30000000 /* prefetchable memory (768MB) */
0x82000000 0x0 0x40000000 0x12 0x30000000 0x0 0x10000000>; /* non-prefetchable memory (256MB) */
};
@@ -1238,7 +1238,7 @@ pcie@14120000 {
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x32100000 0x0 0x32100000 0x0 0x00100000 /* downstream I/O (1MB) */
- 0xc2000000 0x12 0x40000000 0x12 0x40000000 0x0 0x30000000 /* prefetchable memory (768MB) */
+ 0xc3000000 0x12 0x40000000 0x12 0x40000000 0x0 0x30000000 /* prefetchable memory (768MB) */
0x82000000 0x0 0x40000000 0x12 0x70000000 0x0 0x10000000>; /* non-prefetchable memory (256MB) */
};
@@ -1284,7 +1284,7 @@ pcie@14140000 {
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x34100000 0x0 0x34100000 0x0 0x00100000 /* downstream I/O (1MB) */
- 0xc2000000 0x12 0x80000000 0x12 0x80000000 0x0 0x30000000 /* prefetchable memory (768MB) */
+ 0xc3000000 0x12 0x80000000 0x12 0x80000000 0x0 0x30000000 /* prefetchable memory (768MB) */
0x82000000 0x0 0x40000000 0x12 0xb0000000 0x0 0x10000000>; /* non-prefetchable memory (256MB) */
};
@@ -1330,7 +1330,7 @@ pcie@14160000 {
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x36100000 0x0 0x36100000 0x0 0x00100000 /* downstream I/O (1MB) */
- 0xc2000000 0x14 0x00000000 0x14 0x00000000 0x3 0x40000000 /* prefetchable memory (13GB) */
+ 0xc3000000 0x14 0x00000000 0x14 0x00000000 0x3 0x40000000 /* prefetchable memory (13GB) */
0x82000000 0x0 0x40000000 0x17 0x40000000 0x0 0xc0000000>; /* non-prefetchable memory (3GB) */
};
@@ -1376,7 +1376,7 @@ pcie@14180000 {
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x38100000 0x0 0x38100000 0x0 0x00100000 /* downstream I/O (1MB) */
- 0xc2000000 0x18 0x00000000 0x18 0x00000000 0x3 0x40000000 /* prefetchable memory (13GB) */
+ 0xc3000000 0x18 0x00000000 0x18 0x00000000 0x3 0x40000000 /* prefetchable memory (13GB) */
0x82000000 0x0 0x40000000 0x1b 0x40000000 0x0 0xc0000000>; /* non-prefetchable memory (3GB) */
};
@@ -1426,7 +1426,7 @@ pcie@141a0000 {
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x3a100000 0x0 0x3a100000 0x0 0x00100000 /* downstream I/O (1MB) */
- 0xc2000000 0x1c 0x00000000 0x1c 0x00000000 0x3 0x40000000 /* prefetchable memory (13GB) */
+ 0xc3000000 0x1c 0x00000000 0x1c 0x00000000 0x3 0x40000000 /* prefetchable memory (13GB) */
0x82000000 0x0 0x40000000 0x1f 0x40000000 0x0 0xc0000000>; /* non-prefetchable memory (3GB) */
};
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 003/172] ASoC: tegra: tegra_wm8903: Support nvidia, headset property
From: Sasha Levin @ 2020-06-18 1:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linux-tegra, Dmitry Osipenko, Mark Brown, alsa-devel
In-Reply-To: <20200618012218.607130-1-sashal@kernel.org>
From: Dmitry Osipenko <digetx@gmail.com>
[ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
The microphone-jack state needs to be masked in a case of a 4-pin jack
when microphone and ground pins are shorted. Presence of nvidia,headset
tells that WM8903 CODEC driver should mask microphone's status if short
circuit is detected, i.e headphones are inserted.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200330204011.18465-3-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/tegra/tegra_wm8903.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/soc/tegra/tegra_wm8903.c b/sound/soc/tegra/tegra_wm8903.c
index 69bc9461974b..301850df368d 100644
--- a/sound/soc/tegra/tegra_wm8903.c
+++ b/sound/soc/tegra/tegra_wm8903.c
@@ -173,6 +173,7 @@ static int tegra_wm8903_init(struct snd_soc_pcm_runtime *rtd)
struct snd_soc_component *component = codec_dai->component;
struct snd_soc_card *card = rtd->card;
struct tegra_wm8903 *machine = snd_soc_card_get_drvdata(card);
+ int shrt = 0;
if (gpio_is_valid(machine->gpio_hp_det)) {
tegra_wm8903_hp_jack_gpio.gpio = machine->gpio_hp_det;
@@ -185,12 +186,15 @@ static int tegra_wm8903_init(struct snd_soc_pcm_runtime *rtd)
&tegra_wm8903_hp_jack_gpio);
}
+ if (of_property_read_bool(card->dev->of_node, "nvidia,headset"))
+ shrt = SND_JACK_MICROPHONE;
+
snd_soc_card_jack_new(rtd->card, "Mic Jack", SND_JACK_MICROPHONE,
&tegra_wm8903_mic_jack,
tegra_wm8903_mic_jack_pins,
ARRAY_SIZE(tegra_wm8903_mic_jack_pins));
wm8903_mic_detect(component, &tegra_wm8903_mic_jack, SND_JACK_MICROPHONE,
- 0);
+ shrt);
snd_soc_dapm_force_enable_pin(&card->dapm, "MICBIAS");
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 105/172] arm64: tegra: Fix ethernet phy-mode for Jetson Xavier
From: Sasha Levin @ 2020-06-18 1:21 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA
Cc: Jon Hunter, Thierry Reding, Sasha Levin,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200618012218.607130-1-sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
From: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[ Upstream commit bba25915b172c72f6fa635f091624d799e3c9cae ]
The 'phy-mode' property is currently defined as 'rgmii' for Jetson
Xavier. This indicates that the RGMII RX and TX delays are set by the
MAC and the internal delays set by the PHY are not used.
If the Marvell PHY driver is enabled, such that it is used and not the
generic PHY, ethernet failures are seen (DHCP is failing to obtain an
IP address) and this is caused because the Marvell PHY driver is
disabling the internal RX and TX delays. For Jetson Xavier the internal
PHY RX and TX delay should be used and so fix this by setting the
'phy-mode' to 'rgmii-id' and not 'rgmii'.
Fixes: f89b58ce71a9 ("arm64: tegra: Add ethernet controller on Tegra194")
Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Sasha Levin <sashal-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
index 57d3f00464ce..7352954e12be 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -32,7 +32,7 @@ ethernet@2490000 {
phy-reset-gpios = <&gpio TEGRA194_MAIN_GPIO(G, 5) GPIO_ACTIVE_LOW>;
phy-handle = <&phy>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
mdio {
#address-cells = <1>;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 09/38] dt-bindings: gpu: tegra: Convert to json-schema
From: Rob Herring @ 2020-06-18 2:29 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200612141903.2391044-10-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Jun 12, 2020 at 04:18:34PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Convert the NVIDIA Tegra GPU bindings from the previous free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/gpu/nvidia,gk20a.txt | 90 ---------
> .../devicetree/bindings/gpu/nvidia,gk20a.yaml | 189 ++++++++++++++++++
> 2 files changed, 189 insertions(+), 90 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
> create mode 100644 Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
> new file mode 100644
> index 000000000000..726ef39b2221
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
> @@ -0,0 +1,189 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpu/nvidia,gk20a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra Graphics Processing Units
> +
> +maintainers:
> + - Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + - Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - nvidia,gk20a
> + - nvidia,gm20b
> + - nvidia,gp10b
> +
> + reg:
> + items:
> + - description: base address and size for BAR0
> + - description: base address and size for BAR1
> +
> + interrupts:
> + items:
> + - description: stalling interrupt
> + - description: non-stalling interrupt
> +
> + interrupt-names:
> + items:
> + - const: stall
> + - const: nonstall
> +
> + clocks:
> + minItems: 2
> + maxItems: 3
> + items:
> + - description: GPU clock
> + - description: PWR clock
> + - description: REF clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 3
> + items:
> + - const: gpu
> + - const: pwr
> + - const: ref
> +
> + resets:
> + items:
> + - description: GPU reset
> +
> + reset-names:
> + minItems: 1
> + maxItems: 1
You can drop minItems/maxItems. The tooling will add them based on
'items' length if not specified.
> + items:
> + - const: gpu
> +
> + power-domains:
> + description: GPUs that make use of power domains can define this property
> + instead of vdd-supply. Currently "nvidia,gp10b" makes use of this.
How many?
> +
> + vdd-supply:
> + description: GPU power supply.
> +
> + iommus:
> + description: The phandle of the IOMMU and the IOMMU specifier. See
> + ../iommu/iommu.txt for details.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
Again, just need to define how many.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-names
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,gm20b
> + then:
> + required:
> + - vdd-supply
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,gm20b
> + then:
> + properties:
> + clock-names:
> + minItems: 3
> +
> + required:
> + - vdd-supply
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,gp10b
> + then:
> + required:
> + - power-domains
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/tegra124-car.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/memory/tegra124-mc.h>
> +
> + gpu@57000000 {
> + compatible = "nvidia,gk20a";
> + reg = <0x0 0x57000000 0x0 0x01000000>,
> + <0x0 0x58000000 0x0 0x01000000>;
The default size is 1 cell each for examples. So either use that or add
a parent node defining 2 cells.
> + interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "stall", "nonstall";
> + vdd-supply = <&vdd_gpu>;
> + clocks = <&tegra_car TEGRA124_CLK_GPU>,
> + <&tegra_car TEGRA124_CLK_PLL_P_OUT5>;
> + clock-names = "gpu", "pwr";
> + resets = <&tegra_car 184>;
> + reset-names = "gpu";
> + iommus = <&mc TEGRA_SWGROUP_GPU>;
> + };
> +
> + - |
> + #include <dt-bindings/clock/tegra210-car.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + /*
> + * XXX can't include this because it conflicts with the tegra124-mc.h
> + * include from the Tegra124 example above.
> + */
> + /*
> + #include <dt-bindings/memory/tegra210-mc.h>
> + */
> +
> + gpu@57000000 {
> + compatible = "nvidia,gm20b";
> + reg = <0x0 0x57000000 0x0 0x01000000>,
> + <0x0 0x58000000 0x0 0x01000000>;
> + interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "stall", "nonstall";
> + vdd-supply = <&vdd_gpu>;
> + clocks = <&tegra_car TEGRA210_CLK_GPU>,
> + <&tegra_car TEGRA210_CLK_PLL_P_OUT5>,
> + <&tegra_car TEGRA210_CLK_PLL_G_REF>;
> + clock-names = "gpu", "pwr", "ref";
> + resets = <&tegra_car 184>;
> + reset-names = "gpu";
> + iommus = <&mc TEGRA_SWGROUP_GPU>;
> + };
> +
> + - |
> + #include <dt-bindings/clock/tegra186-clock.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/memory/tegra186-mc.h>
> + #include <dt-bindings/power/tegra186-powergate.h>
> + #include <dt-bindings/reset/tegra186-reset.h>
> +
> + gpu@17000000 {
> + compatible = "nvidia,gp10b";
> + reg = <0x0 0x17000000 0x0 0x1000000>,
> + <0x0 0x18000000 0x0 0x1000000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "stall", "nonstall";
> + clocks = <&bpmp TEGRA186_CLK_GPCCLK>,
> + <&bpmp TEGRA186_CLK_GPU>;
> + clock-names = "gpu", "pwr";
> + resets = <&bpmp TEGRA186_RESET_GPU>;
> + reset-names = "gpu";
> + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>;
> + iommus = <&smmu TEGRA186_SID_GPU>;
> + };
> --
> 2.24.1
>
^ permalink raw reply
* Re: [PATCH 26/38] dt-bindings: pci: iommu: Convert to json-schema
From: Rob Herring @ 2020-06-18 2:34 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200612141903.2391044-27-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Jun 12, 2020 at 04:18:51PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Convert the PCI IOMMU device tree bindings from free-form text format to
> json-schema.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/pci/pci-iommu.txt | 171 ------------------
> .../devicetree/bindings/pci/pci-iommu.yaml | 168 +++++++++++++++++
> 2 files changed, 168 insertions(+), 171 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
> create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.yaml
This needs to come before you use it.
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.yaml b/Documentation/devicetree/bindings/pci/pci-iommu.yaml
> new file mode 100644
> index 000000000000..8aaa8e657559
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.yaml
> @@ -0,0 +1,168 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/pci-iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PCI IOMMU bindings
> +
> +maintainers:
> + - Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> +
> +description: |
> + This document describes the generic device tree binding for describing the
> + relationship between PCI(e) devices and IOMMU(s).
> +
> + Each PCI(e) device under a root complex is uniquely identified by its
> + Requester ID (AKA RID). A Requester ID is a triplet of a Bus number, Device
> + number, and Function number.
> +
> + For the purpose of this document, when treated as a numeric value, a RID is
> + formatted such that:
> +
> + * Bits [15:8] are the Bus number.
> + * Bits [7:3] are the Device number.
> + * Bits [2:0] are the Function number.
> + * Any other bits required for padding must be zero.
> +
> + IOMMUs may distinguish PCI devices through sideband data derived from the
> + Requester ID. While a given PCI device can only master through one IOMMU, a
> + root complex may split masters across a set of IOMMUs (e.g. with one IOMMU
> + per bus).
> +
> + The generic 'iommus' property is insufficient to describe this relationship,
> + and a mechanism is required to map from a PCI device to its IOMMU and
> + sideband data.
> +
> + For generic IOMMU bindings, see
> + Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +properties:
> + iommu-map:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> + description: |
> + Maps a Requester ID to an IOMMU and associated IOMMU specifier data.
> +
> + The property is an arbitrary number of tuples of (rid-base, iommu,
> + iommu-base, length).
> +
> + Any RID r in the interval [rid-base, rid-base + length) is associated
> + with the listed IOMMU, with the IOMMU specifier (r - rid-base +
> + iommu-base).
> +
> + iommu-map-mask:
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + description:
> + A mask to be applied to each Requester ID prior to being mapped to an
> + IOMMU specifier per the iommu-map property.
> +
> +examples:
> + - |
> + iommu0: iommu@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
> +
> + /*
> + * The sideband data provided to the IOMMU is the RID,
> + * identity-mapped.
> + */
> + iommu-map = <0x0 &iommu0 0x0 0x10000>;
> + };
> +
> + - |
> + iommu1: iommu@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
> +
> + /*
> + * The sideband data provided to the IOMMU is the RID with the
> + * function bits masked out.
> + */
> + iommu-map = <0x0 &iommu 0x0 0x10000>;
> + iommu-map-mask = <0xfff8>;
> + };
> +
> + - |
> + iommu2: iommu@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
> +
> + /*
> + * The sideband data provided to the IOMMU is the RID,
> + * but the high bits of the bus number are flipped.
> + */
> + iommu-map = <0x0000 &iommu2 0x8000 0x8000>,
> + <0x8000 &iommu2 0x0000 0x8000>;
> + };
> +
> + - |
> + iommu_a: iommu@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + iommu_b: iommu@b {
> + reg = <0xb 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + iommu_c: iommu@c {
> + reg = <0xc 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
> +
> + /*
> + * Devices with bus number 0-127 are mastered via IOMMU
> + * a, with sideband data being RID[14:0].
> + * Devices with bus number 128-255 are mastered via
> + * IOMMU b, with sideband data being RID[14:0].
> + * No devices master via IOMMU c.
> + */
> + iommu-map = <0x0000 &iommu_a 0x0000 0x8000>,
> + <0x8000 &iommu_b 0x0000 0x8000>;
> + };
> --
> 2.24.1
>
^ permalink raw reply
* Re: [PATCH 28/38] dt-bindings: phy: tegra-xusb: Convert to json-schema
From: Rob Herring @ 2020-06-18 2:38 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200612141903.2391044-29-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Jun 12, 2020 at 04:18:53PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Convert the Tegra XUSB pad controller bindings from free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../phy/nvidia,tegra124-xusb-padctl.txt | 778 -----
> .../phy/nvidia,tegra124-xusb-padctl.yaml | 2800 +++++++++++++++++
> 2 files changed, 2800 insertions(+), 778 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
> create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
This one I definitely think should be split up into multiple schema
files. There's very little shared.
Rob
^ permalink raw reply
* Re: [PATCH 21/38] dt-bindings: sound: sgtl5000: Convert to json-schema
From: Rob Herring @ 2020-06-18 2:41 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200612141903.2391044-22-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Jun 12, 2020 at 04:18:46PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Convert the Freescale SGTL5000 device tree bindings from free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/sound/sgtl5000.txt | 60 ----------
> .../devicetree/bindings/sound/sgtl5000.yaml | 103 ++++++++++++++++++
> .../devicetree/bindings/trivial-devices.yaml | 2 -
> 3 files changed, 103 insertions(+), 62 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/sgtl5000.txt
> create mode 100644 Documentation/devicetree/bindings/sound/sgtl5000.yaml
> diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml
> new file mode 100644
> index 000000000000..4f29b63c54d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/sgtl5000.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale SGTL5000 Stereo Codec
> +
> +maintainers:
> + - Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> +
> +properties:
> + compatible:
> + const: fsl,sgtl5000
> +
> + reg:
> + maxItems: 1
> +
> + "#sound-dai-cells":
> + const: 0
> +
> + clocks:
> + items:
> + - description: the clock provider of SYS_MCLK
> +
> + VDDA-supply:
> + description: the regulator provider of VDDA
> +
> + VDDIO-supply:
> + description: the regulator provider of VDDIO
> +
> + VDDD-supply:
> + description: the regulator provider of VDDD
> +
> + micbias-resistor-k-ohms:
> + description: The bias resistor to be used in kOhms. The resistor can take
> + values of 2k, 4k or 8k. If set to 0 it will be off. If this node is not
> + mentioned or if the value is unknown, then micbias resistor is set to
> + 4k.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
Anything with standard unit suffix already has a type.
> + enum: [ 0, 2, 4, 8 ]
> +
> + micbias-voltage-m-volts:
> + description: The bias voltage to be used in mVolts. The voltage can take
> + values from 1.25V to 3V by 250mV steps. If this node is not mentioned
> + or the value is unknown, then the value is set to 1.25V.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ]
> +
> + lrclk-strength:
> + description: |
> + The LRCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
> + table below:
> +
> + VDDIO 1.8V 2.5V 3.3V
> + 0 = Disable
> + 1 = 1.66 mA 2.87 mA 4.02 mA
> + 2 = 3.33 mA 5.74 mA 8.03 mA
> + 3 = 4.99 mA 8.61 mA 12.05 mA
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + enum: [ 0, 1, 2, 3 ]
> +
> + sclk-strength:
> + description: |
> + The SCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
> + table below:
> +
> + VDDIO 1.8V 2.5V 3.3V
> + 0 = Disable
> + 1 = 1.66 mA 2.87 mA 4.02 mA
> + 2 = 3.33 mA 5.74 mA 8.03 mA
> + 3 = 4.99 mA 8.61 mA 12.05 mA
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + enum: [ 0, 1, 2, 3 ]
> +
> +required:
> + - compatible
> + - reg
> + - "#sound-dai-cells"
> + - clocks
> + - VDDA-supply
> + - VDDIO-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + codec@a {
> + compatible = "fsl,sgtl5000";
> + reg = <0x0a>;
> + #sound-dai-cells = <0>;
> + clocks = <&clks 150>;
> + micbias-resistor-k-ohms = <2>;
> + micbias-voltage-m-volts = <2250>;
> + VDDA-supply = <®_3p3v>;
> + VDDIO-supply = <®_3p3v>;
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 4165352a590a..b7e94fe8643f 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -80,8 +80,6 @@ properties:
> - fsl,mpl3115
> # MPR121: Proximity Capacitive Touch Sensor Controller
> - fsl,mpr121
> - # SGTL5000: Ultra Low-Power Audio Codec
> - - fsl,sgtl5000
> # G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface
> - gmt,g751
> # Infineon IR38064 Voltage Regulator
> --
> 2.24.1
>
^ permalink raw reply
* Re: [PATCH 23/38] dt-bindings: gpio: tegra186: Convert to json-schema
From: Rob Herring @ 2020-06-18 2:44 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200612141903.2391044-24-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Jun 12, 2020 at 04:18:48PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Convert the Tegra186 GPIO controller device tree bindings from free-form
> text format to json-schema.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../bindings/gpio/nvidia,tegra186-gpio.txt | 165 --------------
> .../bindings/gpio/nvidia,tegra186-gpio.yaml | 215 ++++++++++++++++++
> 2 files changed, 215 insertions(+), 165 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt
> create mode 100644 Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
> diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
> new file mode 100644
> index 000000000000..94cf164c9abf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
> @@ -0,0 +1,215 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/nvidia,tegra186-gpio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra GPIO Controller (Tegra186 and later)
> +
> +maintainers:
> + - Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + - Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> +
> +description: |
> + Tegra186 contains two GPIO controllers; a main controller and an "AON"
> + controller. This binding document applies to both controllers. The register
> + layouts for the controllers share many similarities, but also some
> + significant differences. Hence, this document describes closely related but
> + different bindings and compatible values.
> +
> + The Tegra186 GPIO controller allows software to set the IO direction of,
> + and read/write the value of, numerous GPIO signals. Routing of GPIO signals
> + to package balls is under the control of a separate pin controller hardware
> + block. Two major sets of registers exist:
> +
> + a) Security registers, which allow configuration of allowed access to the
> + GPIO register set. These registers exist in a single contiguous block
> + of physical address space. The size of this block, and the security
> + features available, varies between the different GPIO controllers.
> +
> + Access to this set of registers is not necessary in all circumstances.
> + Code that wishes to configure access to the GPIO registers needs access
> + to these registers to do so. Code which simply wishes to read or write
> + GPIO data does not need access to these registers.
> +
> + b) GPIO registers, which allow manipulation of the GPIO signals. In some
> + GPIO controllers, these registers are exposed via multiple "physical
> + aliases" in address space, each of which access the same underlying
> + state. See the hardware documentation for rationale. Any particular
> + GPIO client is expected to access just one of these physical aliases.
> +
> + Tegra HW documentation describes a unified naming convention for all GPIOs
> + implemented by the SoC. Each GPIO is assigned to a port, and a port may
> + control a number of GPIOs. Thus, each GPIO is named according to an
> + alphabetical port name and an integer GPIO name within the port. For
> + example, GPIO_PA0, GPIO_PN6, or GPIO_PCC3.
> +
> + The number of ports implemented by each GPIO controller varies. The number
> + of implemented GPIOs within each port varies. GPIO registers within a
> + controller are grouped and laid out according to the port they affect.
> +
> + The mapping from port name to the GPIO controller that implements that
> + port, and the mapping from port name to register offset within a
> + controller, are both extremely non-linear. The header file
> + <dt-bindings/gpio/tegra186-gpio.h> describes the port-level mapping. In
> + that file, the naming convention for ports matches the HW documentation.
> + The values chosen for the names are alphabetically sorted within a
> + particular controller. Drivers need to map between the DT GPIO IDs and HW
> + register offsets using a lookup table.
> +
> + Each GPIO controller can generate a number of interrupt signals. Each
> + signal represents the aggregate status for all GPIOs within a set of
> + ports. Thus, the number of interrupt signals generated by a controller
> + varies as a rough function of the number of ports it implements. Note
> + that the HW documentation refers to both the overall controller HW
> + module and the sets-of-ports as "controllers".
> +
> + Each GPIO controller in fact generates multiple interrupts signals for
> + each set of ports. Each GPIO may be configured to feed into a specific
> + one of the interrupt signals generated by a set-of-ports. The intent is
> + for each generated signal to be routed to a different CPU, thus allowing
> + different CPUs to each handle subsets of the interrupts within a port.
> + The status of each of these per-port-set signals is reported via a
> + separate register. Thus, a driver needs to know which status register to
> + observe. This binding currently defines no configuration mechanism for
> + this. By default, drivers should use register
> + GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could
> + define a property to configure this.
> +
> +properties:
> + compatible:
> + enum:
> + - nvidia,tegra186-gpio
> + - nvidia,tegra186-gpio-aon
> + - nvidia,tegra194-gpio
> + - nvidia,tegra194-gpio-aon
> +
> + reg-names:
> + items:
> + - const: security
> + - const: gpio
Wrong order? Doesn't match 'reg' description.
> + minItems: 1
> + maxItems: 2
> +
> + reg:
> + items:
> + - description: |
> + GPIO control registers. This may cover either:
> +
> + a) The single physical alias that this OS should use.
> + b) All physical aliases that exist in the controller. This is
> + appropriate when the OS is responsible for managing assignment
> + of the physical aliases.
> + - description: Security configuration registers.
> + minItems: 1
> + maxItems: 2
> +
> + interrupts:
> + description: The interrupt outputs from the HW block, one per set of
> + ports, in the order the HW manual describes them. The number of entries
> + required varies depending on compatible value.
> +
> + gpio-controller:
> + description: Marks the device node as a GPIO controller/provider.
> + type: boolean
Just:
gpio-controller: true
> +
> + "#gpio-cells":
> + description: |
> + Indicates how many cells are used in a consumer's GPIO specifier. In the
> + specifier:
> +
> + - The first cell is the pin number.
> + See <dt-bindings/gpio/tegra186-gpio.h>.
> + - The second cell contains flags:
> + - Bit 0 specifies polarity
> + - 0: Active-high (normal).
> + - 1: Active-low (inverted).
> + const: 2
> +
> + interrupt-controller:
> + description: Marks the device node as an interrupt controller/provider.
> + type: boolean
Just:
interrupt-controller: true
> +
> + "#interrupt-cells":
> + description: |
> + Indicates how many cells are used in a consumer's interrupt specifier.
> + In the specifier:
> +
> + - The first cell is the GPIO number.
> + See <dt-bindings/gpio/tegra186-gpio.h>.
> + - The second cell is contains flags:
> + - Bits [3:0] indicate trigger type and level:
> + - 1: Low-to-high edge triggered.
> + - 2: High-to-low edge triggered.
> + - 4: Active high level-sensitive.
> + - 8: Active low level-sensitive.
> +
> + Valid combinations are 1, 2, 3, 4, 8.
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra186-gpio
> + - nvidia,tegra194-gpio
> + then:
> + properties:
> + interrupts:
> + minItems: 6
> + maxItems: 6
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra186-gpio-aon
> + - nvidia,tegra194-gpio-aon
> + then:
> + properties:
> + interrupts:
> + minItems: 1
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + gpio@2200000 {
> + compatible = "nvidia,tegra186-gpio";
> + reg-names = "security", "gpio";
> + reg = <0x0 0x2200000 0x0 0x10000>,
> + <0x0 0x2210000 0x0 0x10000>;
> + interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>,
> + <0 50 IRQ_TYPE_LEVEL_HIGH>,
> + <0 53 IRQ_TYPE_LEVEL_HIGH>,
> + <0 56 IRQ_TYPE_LEVEL_HIGH>,
> + <0 59 IRQ_TYPE_LEVEL_HIGH>,
> + <0 180 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + gpio@c2f0000 {
> + compatible = "nvidia,tegra186-gpio-aon";
> + reg-names = "security", "gpio";
> + reg = <0x0 0xc2f0000 0x0 0x1000>,
> + <0x0 0xc2f1000 0x0 0x1000>;
> + interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> --
> 2.24.1
>
^ permalink raw reply
* Re: [PATCH 38/38] dt-bindings: serial: Document Tegra-specific properties
From: Rob Herring @ 2020-06-18 2:47 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200612141903.2391044-39-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Jun 12, 2020 at 04:19:03PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> On Tegra the UART is described using additional properties, such as
> clock-names, reset-names, dmas and dma-names. Document them in the
> bindings so that Tegra device trees are properly validated.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/serial/8250.yaml | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
> index c1d4c196f005..9c8fad27c3f3 100644
> --- a/Documentation/devicetree/bindings/serial/8250.yaml
> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> @@ -28,6 +28,32 @@ allOf:
> const: 2
> required:
> - reg-shift
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra20-uart
Can use 'const' here instead.
> + then:
> + properties:
> + clock-names:
> + $ref: "/schemas/types.yaml#/definitions/string-array"
Don't need type.
> + items:
> + - const: serial
> +
> + dmas:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
How many?
> +
> + dma-names:
> + $ref: "/schemas/types.yaml#/definitions/string-array"
> + items:
> + - const: rx
> + - const: tx
> +
> + reset-names:
> + $ref: "/schemas/types.yaml#/definitions/string-array"
> + items:
> + - const: serial
> - if:
> not:
> properties:
> --
> 2.24.1
>
^ permalink raw reply
* Re: [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml
From: Rob Herring @ 2020-06-18 2:51 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200612141903.2391044-38-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Jun 12, 2020 at 04:19:02PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> For PWM controller device tree bindings, make sure that they include the
> pwm.yaml controller core bindings explicitly. This prevents the tooling
> from matching on the $nodename pattern, which can falsely match things
> like pinmux nodes, etc.
My preference here is to clean-up the mess that is pinmux nodes.
This has the side effect of no longer checking pwm nodes that didn't
have explicit schema. Perhaps that's of somewhat limited value.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: max77620: Convert to json-schema
From: Lee Jones @ 2020-06-18 8:28 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Mark Brown,
Zhang Rui, Daniel Lezcano, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200609162621.1769610-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, 09 Jun 2020, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Convert the Maxim MAX77620 PMIC device tree bindings from free-form text
> format to json-schema.
>
> This also pulls in the GPIO, regulator, pinmux and thermal bindings for
> the corresponding subdevices into the top-level binding so that it can
> be described more consistently.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../bindings/gpio/gpio-max77620.txt | 25 -
> .../devicetree/bindings/mfd/max77620.txt | 162 -----
> .../devicetree/bindings/mfd/max77620.yaml | 662 ++++++++++++++++++
> .../bindings/pinctrl/pinctrl-max77620.txt | 127 ----
> .../bindings/regulator/regulator-max77620.txt | 222 ------
> .../bindings/thermal/max77620_thermal.txt | 70 --
> 6 files changed, 662 insertions(+), 606 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-max77620.txt
> delete mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/max77620.yaml
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> delete mode 100644 Documentation/devicetree/bindings/regulator/regulator-max77620.txt
> delete mode 100644 Documentation/devicetree/bindings/thermal/max77620_thermal.txt
Wow, what a beast. I can see why Rob is putting this one off!
Changes look okay to me, but Rob and Linus should review.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 06/38] dt-bindings: display: tegra: Document display-hub
From: Thierry Reding @ 2020-06-18 10:27 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617225506.GC2975260@bogus>
[-- Attachment #1: Type: text/plain, Size: 13096 bytes --]
On Wed, Jun 17, 2020 at 04:55:06PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:18:31PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > Tegra186 and later have an additional component in the display pipeline
> > called the display hub. Document the bindings which were missing.
>
> I'd rather this be after the conversion or I'm reviewing it twice.
Okay, I'll reorder the patches accordingly.
> >
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../display/tegra/nvidia,tegra20-host1x.txt | 50 +++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > index 47319214b5f6..2cf3cc4893da 100644
> > --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > @@ -297,6 +297,56 @@ of the following host1x client modules:
> > - reset-names: Must include the following entries:
> > - vic
> >
> > +- display-hub: display controller hub
> > + Required properties:
> > + - compatible: "nvidia,tegra<chip>-display"
> > + - reg: Physical base address and length of the controller's registers.
> > + - interrupts: The interrupt outputs from the controller.
> > + - clocks: Must contain an entry for each entry in clock-names.
> > + See ../clocks/clock-bindings.txt for details.
> > + - clock-names: Must include the following entries:
> > + - disp
> > + - dsc
> > + - hub
> > + - resets: Must contain an entry for each entry in reset-names.
> > + See ../reset/reset.txt for details.
> > + - reset-names: Must include the following entries:
> > + - misc
> > + - wgrp0
> > + - wgrp1
> > + - wgrp2
> > + - wgrp3
> > + - wgrp4
> > + - wgrp5
> > + - power-domains: A list of phandle and specifiers identifying the power
> > + domains that the display hub is part of.
> > + - ranges: Range of registers used for the display controllers.
> > +
> > + Each subnode of the display hub represents one of the display controllers
> > + available:
> > +
> > + - display: display controller
> > + - compatible: "nvidia,tegra<chip>-dc"
> > + - reg: Physical base address and length of the controller's registers.
> > + - interrupts: The interrupt outputs from the controller.
> > + - clocks: Must contain an entry for each entry in clock-names.
> > + See ../clocks/clock-bindings.txt for details.
> > + - clock-names: Must include the following entries:
> > + - dc
> > + - resets: Must contain an entry for each entry in reset-names.
> > + See ../reset/reset.txt for details.
> > + - reset-names: Must include the following entries:
> > + - dc
> > + - power-domains: A list of phandle and specifiers that identify the power
> > + domains that this display controller is part of.
> > + - iommus: A phandle and specifier identifying the SMMU master interface of
> > + this display controller.
> > + - nvidia,outputs: A list of phandles of outputs that this display
> > + controller can drive.
>
> Seems like an OF graph should describe this?
The above documents the current state of affairs. I don't recall exactly
why we never merged the bindings, but we've been using this
nvidia,outputs property for almost three years now. Changing this would
break ABI, although I guess you could say that since this was never
documented it can't be ABI. Still, changing this is going to cause old
device trees to fail with new kernels. Unless of course if we add some
backwards-compatibility mechanism in the driver. But in that case, what
exactly do we gain by switching to an OF graph?
Historically, I think nvidia,outputs was introduced before OF graphs
were "a thing", at least in DRM. According to the git log, the helpers
for graphs were introduced a couple of years before nvidia,outputs was
used, but I guess they must not have been widespread enough for me to
have been aware of them.
Anyway, irrespective of the compatibility issues, I tried to use an OF
graph to describe this and here's what I came up with:
--- >8 ---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 170 ++++++++++++++++++++++++++++++-
drivers/gpu/drm/tegra/dc.c | 15 +--
drivers/gpu/drm/tegra/dc.h | 1 -
drivers/gpu/drm/tegra/output.c | 12 +--
4 files changed, 172 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 58100fb9cd8b..a3dcf2437976 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -994,8 +994,38 @@ display@15200000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
- nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
nvidia,head = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dc0_out: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dc0_out_dsia: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dsia_in_dc0>;
+ };
+
+ dc0_out_dsib: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dsib_in_dc0>;
+ };
+
+ dc0_out_sor0: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <&sor0_in_dc0>;
+ };
+
+ dc0_out_sor1: endpoint@3 {
+ reg = <3>;
+ remote-endpoint = <&sor1_in_dc0>;
+ };
+ };
+ };
};
display@15210000 {
@@ -1010,8 +1040,38 @@ display@15210000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPB>;
iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
- nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
nvidia,head = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dc1_out: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dc1_out_dsia: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dsia_in_dc1>;
+ };
+
+ dc1_out_dsib: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dsib_in_dc1>;
+ };
+
+ dc1_out_sor0: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <&sor0_in_dc1>;
+ };
+
+ dc1_out_sor1: endpoint@3 {
+ reg = <3>;
+ remote-endpoint = <&sor1_in_dc1>;
+ };
+ };
+ };
};
display@15220000 {
@@ -1026,8 +1086,28 @@ display@15220000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPC>;
iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
- nvidia,outputs = <&sor0 &sor1>;
nvidia,head = <2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dc2_out: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dc2_out_sor0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&sor0_in_dc2>;
+ };
+
+ dc2_out_sor1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&sor1_in_dc2>;
+ };
+ };
+ };
};
};
@@ -1044,6 +1124,25 @@ dsia: dsi@15300000 {
status = "disabled";
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsia_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dsia_in_dc0: endpoint@0 {
+ remote-endpoint = <&dc0_out_dsia>;
+ };
+
+ dsia_in_dc1: endpoint@1 {
+ remote-endpoint = <&dc1_out_dsia>;
+ };
+ };
+ };
};
vic@15340000 {
@@ -1072,6 +1171,25 @@ dsib: dsi@15400000 {
status = "disabled";
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsib_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dsib_in_dc0: endpoint@0 {
+ remote-endpoint = <&dc0_out_dsib>;
+ };
+
+ dsib_in_dc1: endpoint@1 {
+ remote-endpoint = <&dc1_out_dsib>;
+ };
+ };
+ };
};
sor0: sor@15540000 {
@@ -1096,6 +1214,29 @@ sor0: sor@15540000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
nvidia,interface = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sor0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ sor0_in_dc0: endpoint@0 {
+ remote-endpoint = <&dc0_out_sor0>;
+ };
+
+ sor0_in_dc1: endpoint@1 {
+ remote-endpoint = <&dc1_out_sor0>;
+ };
+
+ sor0_in_dc2: endpoint@2 {
+ remote-endpoint = <&dc2_out_sor0>;
+ };
+ };
+ };
};
sor1: sor@15580000 {
@@ -1120,6 +1261,29 @@ sor1: sor@15580000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
nvidia,interface = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sor1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ sor1_in_dc0: endpoint@0 {
+ remote-endpoint = <&dc0_out_sor1>;
+ };
+
+ sor1_in_dc1: endpoint@1 {
+ remote-endpoint = <&dc1_out_sor1>;
+ };
+
+ sor1_in_dc2: endpoint@2 {
+ remote-endpoint = <&dc2_out_sor1>;
+ };
+ };
+ };
};
dpaux: dpaux@155c0000 {
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 04d6848d19fc..4adb64c083c8 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -10,6 +10,7 @@
#include <linux/iommu.h>
#include <linux/module.h>
#include <linux/of_device.h>
+#include <linux/of_graph.h>
#include <linux/pm_runtime.h>
#include <linux/reset.h>
@@ -86,19 +87,6 @@ static inline void tegra_plane_writel(struct tegra_plane *plane, u32 value,
tegra_dc_writel(plane->dc, value, tegra_plane_offset(plane, offset));
}
-bool tegra_dc_has_output(struct tegra_dc *dc, struct device *dev)
-{
- struct device_node *np = dc->dev->of_node;
- struct of_phandle_iterator it;
- int err;
-
- of_for_each_phandle(&it, err, np, "nvidia,outputs", NULL, 0)
- if (it.node == dev->of_node)
- return true;
-
- return false;
-}
-
/*
* Double-buffered registers have two copies: ASSEMBLY and ACTIVE. When the
* *_ACT_REQ bits are set the ASSEMBLY copy is latched into the ACTIVE copy.
@@ -2061,6 +2049,7 @@ static int tegra_dc_init(struct host1x_client *client)
if (err < 0)
goto cleanup;
+ dc->base.port = of_graph_get_port_by_id(dc->dev->of_node, 0);
drm_crtc_helper_add(&dc->base, &tegra_crtc_helper_funcs);
/*
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 3d8ddccd758f..9e4ae77e6270 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -144,7 +144,6 @@ struct tegra_dc_window {
};
/* from dc.c */
-bool tegra_dc_has_output(struct tegra_dc *dc, struct device *dev);
void tegra_dc_commit(struct tegra_dc *dc);
int tegra_dc_state_setup_clock(struct tegra_dc *dc,
struct drm_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index e36e5e7c2f69..b09935cdf397 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -5,6 +5,7 @@
*/
#include <drm/drm_atomic_helper.h>
+#include <drm/drm_of.h>
#include <drm/drm_panel.h>
#include <drm/drm_simple_kms_helper.h>
@@ -229,16 +230,9 @@ void tegra_output_find_possible_crtcs(struct tegra_output *output,
struct drm_device *drm)
{
struct device *dev = output->dev;
- struct drm_crtc *crtc;
- unsigned int mask = 0;
-
- drm_for_each_crtc(crtc, drm) {
- struct tegra_dc *dc = to_tegra_dc(crtc);
-
- if (tegra_dc_has_output(dc, dev))
- mask |= drm_crtc_mask(crtc);
- }
+ u32 mask;
+ mask = drm_of_find_possible_crtcs(drm, dev->of_node);
if (mask == 0) {
dev_warn(dev, "missing output definition for heads in DT\n");
mask = 0x3;
--- >8 ---
I do see the benefit of using standard bindings where available, but in
this case I think that's hardly an improvement over the current binding,
even though it's undocumented.
> > + - nvidia,head: The number of the display controller head. This is used to
> > + setup the various types of output to receive video data from the given
> > + head.
>
> Not really clear what this is...
This is the same as for the display controller in older Tegra devices.
The value is the index of the display controller head, or the instance
number of the IP, if that's any clearer. We need this in some places
for register programming. We can't always safely derive it in some
other way.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* Re: [RFC PATCH v1 10/18] dt-bindings: tegra: Document VI and CSI port nodes
From: Thierry Reding @ 2020-06-18 10:50 UTC (permalink / raw)
To: Rob Herring
Cc: Sowjanya Komatineni, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
frankc-DDmLM1+adcrQT0dZR+AlfA, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
sakari.ailus-X3B1VOXEql0, helen.koike-ZGY8ohtN/8qB+jHODAdFcQ,
digetx-Re5JQEeQqe8AvxtiuMwx3w, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617221411.GB2923473@bogus>
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]
On Wed, Jun 17, 2020 at 04:14:11PM -0600, Rob Herring wrote:
> On Tue, Jun 09, 2020 at 11:02:32PM -0700, Sowjanya Komatineni wrote:
> > This patch documents Tegra VI and CSI port and endpoint nodes along
> > with the other required properties.
> >
> > Signed-off-by: Sowjanya Komatineni <skomatineni-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../display/tegra/nvidia,tegra20-host1x.txt | 87 ++++++++++++++++++++++
> > 1 file changed, 87 insertions(+)
>
> This is getting converted to schema by Thierry.
Yeah, once this has settled it probably makes sense for me to pick this
up into the json-schema series on top of the initial conversion.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] [v3] dmaengine: tegra210-adma: Fix runtime PM imbalance on error
From: Dinghao Liu @ 2020-06-18 10:57 UTC (permalink / raw)
To: dinghao.liu-Y5EWUtBUdg4nDS1+zs4M5A, kjlu-OJFnDUYgAso
Cc: Laxman Dewangan, Jon Hunter, Dan Williams, Vinod Koul,
Thierry Reding, dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu-Y5EWUtBUdg4nDS1+zs4M5A@public.gmane.org>
---
Changelog:
v2: - Merge two patches that fix runtime PM imbalance in
tegra_adma_probe() and tegra_adma_alloc_chan_resources()
respectively.
v3: - Use pm_runtime_put_noidle() instead of pm_runtime_put_sync()
in tegra_adma_alloc_chan_resources().
---
drivers/dma/tegra210-adma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index db58d7e4f9fe..bfa8800dfb4c 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -658,6 +658,7 @@ static int tegra_adma_alloc_chan_resources(struct dma_chan *dc)
ret = pm_runtime_get_sync(tdc2dev(tdc));
if (ret < 0) {
+ pm_runtime_put_noidle(tdc2dev(tdc));
free_irq(tdc->irq, tdc);
return ret;
}
@@ -870,7 +871,7 @@ static int tegra_adma_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0)
- goto rpm_disable;
+ goto rpm_put;
ret = tegra_adma_init(tdma);
if (ret)
@@ -921,7 +922,6 @@ static int tegra_adma_probe(struct platform_device *pdev)
dma_async_device_unregister(&tdma->dma_dev);
rpm_put:
pm_runtime_put_sync(&pdev->dev);
-rpm_disable:
pm_runtime_disable(&pdev->dev);
irq_dispose:
while (--i >= 0)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support nvidia, headset property
From: Mark Brown @ 2020-06-18 11:00 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Dmitry Osipenko, alsa-devel, linux-tegra
In-Reply-To: <20200618010805.600873-4-sashal@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
On Wed, Jun 17, 2020 at 09:01:41PM -0400, Sasha Levin wrote:
> From: Dmitry Osipenko <digetx@gmail.com>
>
> [ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
>
> The microphone-jack state needs to be masked in a case of a 4-pin jack
> when microphone and ground pins are shorted. Presence of nvidia,headset
> tells that WM8903 CODEC driver should mask microphone's status if short
> circuit is detected, i.e headphones are inserted.
This is a new feature not a bugfix.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
From: Thierry Reding @ 2020-06-18 14:16 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617231326.GD2975260@bogus>
[-- Attachment #1: Type: text/plain, Size: 33826 bytes --]
On Wed, Jun 17, 2020 at 05:13:26PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:18:32PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > Convert the Tegra host1x controller bindings from the free-form text
> > format to json-schema.
> >
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../display/tegra/nvidia,tegra20-host1x.txt | 516 ------
> > .../display/tegra/nvidia,tegra20-host1x.yaml | 1418 +++++++++++++++++
> > 2 files changed, 1418 insertions(+), 516 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
>
>
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > new file mode 100644
> > index 000000000000..3347e1b3c8f0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > @@ -0,0 +1,1418 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-host1x.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NVIDIA Tegra host1x controller
> > +
> > +maintainers:
> > + - Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > + - Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > +
> > +description: The host1x top-level node defines a number of children, each
> > + representing one of the host1x client modules defined in this binding.
> > +
> > +properties:
> > + # required
> > + compatible:
> > + oneOf:
> > + - description: NVIDIA Tegra20
> > + items:
> > + - const: nvidia,tegra20-host1x
> > +
> > + - description: NVIDIA Tegra30
> > + items:
> > + - const: nvidia,tegra30-host1x
> > +
> > + - description: NVIDIA Tegra114
> > + items:
> > + - const: nvidia,tegra114-host1x
> > +
> > + - description: NVIDIA Tegra124
> > + items:
> > + - const: nvidia,tegra124-host1x
> > +
> > + - description: NVIDIA Tegra132
> > + items:
> > + - const: nvidia,tegra132-host1x
> > + - const: nvidia,tegra124-host1x
> > +
> > + - description: NVIDIA Tegra210
> > + items:
> > + - const: nvidia,tegra210-host1x
> > +
> > + - description: NVIDIA Tegra186
> > + items:
> > + - const: nvidia,tegra186-host1x
> > +
> > + - description: NVIDIA Tegra194
> > + items:
> > + - const: nvidia,tegra194-host1x
>
> I don't think the descriptions really add much. I'd rather see all the
> single entry cases as 1 'enum'.
Okay, done.
> > +
> > + interrupts:
> > + items:
> > + - description: host1x syncpoint interrupt
> > + - description: host1x general interrupt
> > + minItems: 1
> > + maxItems: 2
> > +
> > + interrupt-names:
> > + items:
> > + - const: syncpt
> > + - const: host1x
> > +
> > + '#address-cells':
> > + description: The number of cells used to represent physical base addresses
> > + in the host1x address space.
> > + enum: [1, 2]
> > +
> > + '#size-cells':
> > + description: The number of cells used to represent the size of an address
> > + range in the host1x address space.
> > + enum: [1, 2]
> > +
> > + # required
>
> Odd comment...
There were a couple of others like this. I've removed them all now.
>
> > + ranges:
> > + description: The mapping of the host1x address space to the CPU address
> > + space.
>
> That's every 'ranges'. If you know how many entries, then define
> 'maxItems'. If not, 'ranges: true' is enough.
Done.
> > +
> > + clocks:
> > + description: Must contain one entry, for the module clock. See
> > + ../clocks/clock-bindings.txt for details.
> > +
> > + clock-names:
> > + items:
> > + - const: host1x
> > +
> > + resets:
> > + description: Must contain an entry for each entry in reset-names. See
> > + ../reset/reset.txt for details.
> > +
> > + reset-names:
> > + items:
> > + - const: host1x
> > +
> > + # optional
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
>
> This is already applied to every 'iommus' property, so you just need to
> define how many entries.
Done.
> > +
> > + memory-controllers:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +required:
> > + - compatible
> > + - interrupts
> > + - interrupt-names
> > + - '#address-cells'
> > + - '#size-cells'
> > + - ranges
> > + - reg
> > + - clocks
> > + - clock-names
> > + - resets
> > + - reset-names
> > +
> > +unevaluatedProperties: false
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra186-host1x
> > + - nvidia,tegra194-host1x
> > + then:
> > + properties:
> > + reg-names:
> > + items:
> > + - const: hypervisor
> > + - const: vm
> > +
> > + reg:
> > + items:
> > + - description: physical base address and length of the register
> > + region assigned to the VM
> > + - description: physical base address and length of the register
> > + region used by the hypervisor
> > +
> > + required:
> > + - reg-names
> > + else:
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + oneOf:
> > + - const: nvidia,tegra20-host1x
> > + - const: nvidia,tegra30-host1x
> > + - const: nvidia,tegra114-host1x
> > + - const: nvidia,tegra124-host1x
>
> Use 'enum'.
Done.
> > +
> > + then:
> > + patternProperties:
> > + "^vi@[0-9a-f]+$":
> > + description: video input
> > + type: object
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra20-vi
> > + - const: nvidia,tegra30-vi
> > + - const: nvidia,tegra114-vi
> > + - const: nvidia,tegra124-vi
>
> Use a 'enum' for these 4.
Done.
>
> > + - items:
> > + - const: nvidia,tegra132-vi
> > + - const: nvidia,tegra124-vi
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + resets: true
> > +
> > + reset-names:
> > + items:
> > + - const: vi
> > + else:
> > + patternProperties:
> > + "^vi@[0-9a-f]+$":
> > + description: video input
> > + type: object
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra210-vi
> > + - const: nvidia,tegra186-vi
> > + - const: nvidia,tegra194-vi
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + power-domains: true
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + oneOf:
> > + - const: nvidia,tegra210-host1x
> > + then:
> > + patternProperties:
> > + "^vi@[0-9a-f]+$":
>
> type: object
Done.
>
> > + patternProperties:
> > + "^csi@[0-9a-f]+$":
> > + description: camera sensor interface
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra210-csi
> > +
> > + reg: true
> > +
> > + clocks: true
> > +
> > + clock-names:
> > + items:
> > + - const: csi
> > + - const: cilab
> > + - const: cilcd
> > + - const: cile
> > + - const: csi_tpg
> > +
> > + power-domains: true
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra20-host1x
> > + - nvidia,tegra30-host1x
> > + - nvidia,tegra114-host1x
> > + then:
> > + patternProperties:
> > + "^epp@[0-9a-f]+$":
> > + description: encoder pre-processor
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-epp
> > + - nvidia,tegra30-epp
> > + - nvidia,tegra114-epp
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: epp
> > +
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> > +
> > + unevaluatedProperties: false
>
> I think 'additionalProperties: false' will work here.
Yes, it does.
>
> > +
> > + "^mpe@[0-9a-f]+$":
> > + description: video encoder
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-mpe
> > + - nvidia,tegra30-mpe
> > + - nvidia,tegra114-mpe
> > +
> > + reg:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + interrupts:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + clocks:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + resets:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: mpe
> > +
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> > +
> > + unevaluatedProperties: false
> > +
> > + "^gr2d@[0-9a-f]+$":
> > + description: 2D graphics engine
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-gr2d
> > + - nvidia,tegra30-gr2d
> > + - nvidia,tegra114-gr2d
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: 2d
> > +
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> > +
> > + unevaluatedProperties: false
> > +
> > + "^gr3d@[0-9a-f]+$":
> > + description: 3D graphics engine
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-gr3d
> > + - nvidia,tegra30-gr3d
> > + - nvidia,tegra114-gr3d
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> > +
> > + allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: nvidia,tegra30-gr3d
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: primary module clock
> > + - description: secondary module clock
> > +
> > + clock-names:
> > + items:
> > + - const: 3d
> > + - const: 3d2
> > +
> > + resets:
> > + items:
> > + - description: primary module reset
> > + - description: secondary module reset
> > +
> > + reset-names:
> > + items:
> > + - const: 3d
> > + - const: 3d2
> > + else:
> > + properties:
> > + clocks:
> > + items:
> > + - description: module clock
> > +
> > + clock-names:
> > + items:
> > + - const: 3d
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: 3d
> > +
> > + unevaluatedProperties: false
> > +
> > + "^tvo@[0-9a-f]+$":
> > + description: TV encoder output
> > + type: object
> > + properties:
> > + # required
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-tvo
> > + - nvidia,tegra30-tvo
> > + - nvidia,tegra114-tvo
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + status:
> > + $ref: "/schemas/dt-core.yaml#/properties/status"
> > +
> > + unevaluatedProperties: false
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra20-host1x
> > + - nvidia,tegra30-host1x
> > + - nvidia,tegra114-host1x
> > + - nvidia,tegra124-host1x
> > + - nvidia,tegra132-host1x
> > + - nvidia,tegra210-host1x
> > + then:
> > + patternProperties:
> > + "^dc@[0-9a-f]+$":
> > + description: display controller
> > + type: object
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra20-dc
> > + - const: nvidia,tegra30-dc
> > + - const: nvidia,tegra114-dc
> > + - const: nvidia,tegra124-dc
> > + - items:
> > + - const: nvidia,tegra124-dc
> > + - const: nvidia,tegra132-dc
> > + - const: nvidia,tegra210-dc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: display controller pixel clock
> > +
> > + clock-names:
> > + items:
> > + - const: dc
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: dc
> > +
> > + iommus:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + nvidia,head:
> > + description: The number of the display controller head. This is
> > + used to setup the various types of output to receive video
> > + data from the given head.
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra20-dc
> > + - nvidia,tegra30-dc
> > + - nvidia,tegra114-dc
> > + then:
> > + properties:
> > + rgb:
> > + description: Each display controller node has a child node,
> > + named "rgb", that represents the RGB output associated
> > + with the controller.
> > + type: object
> > + properties:
> > + nvidia,ddc-i2c-bus:
> > + description: phandle of an I2C controller used for DDC
> > + EDID probing
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + nvidia,hpd-gpio:
> > + description: specifies a GPIO used for hotplug
> > + detection
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + nvidia,edid:
> > + description: supplies a binary EDID blob
> > + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +
> > + nvidia,panel:
> > + description: phandle of a display panel
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + unevaluatedProperties: false
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra186-host1x
> > + - nvidia,tegra194-host1x
> > + then:
> > + patternProperties:
> > + "^display-hub@[0-9a-f]+$":
> > + properties:
> > + compatible:
> > + oneOf:
> > + - description: NVIDIA Tegra186
> > + const: nvidia,tegra186-display
> > +
> > + - description: NVIDIA Tegra194
> > + const: nvidia,tegra194-display
> > +
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 1
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + ranges:
> > + $ref: "/schemas/dt-core.yaml#/properties/ranges"
> > +
> > + status:
> > + $ref: "/schemas/dt-core.yaml#/properties/status"
> > +
> > + resets:
> > + items:
> > + - description: display hub reset
> > + - description: window group 0 reset
> > + - description: window group 1 reset
> > + - description: window group 2 reset
> > + - description: window group 3 reset
> > + - description: window group 4 reset
> > + - description: window group 5 reset
> > +
> > + reset-names:
> > + items:
> > + - const: misc
> > + - const: wgrp0
> > + - const: wgrp1
> > + - const: wgrp2
> > + - const: wgrp3
> > + - const: wgrp4
> > + - const: wgrp5
> > +
> > + power-domains:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + patternProperties:
> > + "^display@[0-9a-f]+$":
> > + description: display controller
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra186-dc
> > + - nvidia,tegra194-dc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: display controller pixel clock
> > +
> > + clock-names:
> > + items:
> > + - const: dc
> > +
> > + resets:
> > + items:
> > + - description: display controller reset
> > +
> > + reset-names:
> > + items:
> > + - const: dc
> > +
> > + power-domains:
> > + description: A list of phandle and specifiers that identify
> > + the power domains that this display controller is part of.
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + iommus:
> > + description: a phandle and specifier identifying the SMMU
> > + master interface of this display controller.
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + memory-controllers:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > + nvidia,outputs:
> > + description: A list of phandles of outputs that this display
> > + controller can drive.
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + nvidia,head:
> > + description: The number of the display controller head. This
> > + is used to setup the various types of output to receive
> > + video data from the given head.
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + unevaluatedProperties: false
> > +
> > + allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: nvidia,tegra186-display
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: display core clock
> > + - description: display stream compression clock
> > + - description: display hub clock
> > +
> > + clock-names:
> > + items:
> > + - const: disp
> > + - const: dsc
> > + - const: hub
> > + else:
> > + properties:
> > + clocks:
> > + items:
> > + - description: display core clock
> > + - description: display hub clock
> > +
> > + clock-names:
> > + items:
> > + - const: disp
> > + - const: hub
> > +
> > + unevaluatedProperties: false
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra20-host1x
> > + - nvidia,tegra30-host1x
> > + - nvidia,tegra114-host1x
> > + - nvidia,tegra124-host1x
> > + then:
> > + patternProperties:
> > + "^hdmi@[0-9a-f]+$":
> > + description: High Definition Multimedia Interface
> > + type: object
> > + properties:
> > + # required
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra20-hdmi
> > + - const: nvidia,tegra30-hdmi
> > + - const: nvidia,tegra114-hdmi
> > + - const: nvidia,tegra124-hdmi
> > + - items:
> > + - const: nvidia,tegra132-hdmi
> > + - const: nvidia,tegra124-hdmi
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: module clock
> > + - description: parent clock
> > +
> > + clock-names:
> > + items:
> > + - const: hdmi
> > + - const: parent
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: hdmi
> > +
> > + hdmi-supply:
> > + description: supply for the +5V HDMI connector pin
> > +
> > + vdd-supply:
> > + description: regulator for supply voltage
> > +
> > + pll-supply:
> > + description: regulator for PLL
> > +
> > + # optional
> > + nvidia,ddc-i2c-bus:
> > + description: phandle of an I2C controller used for DDC EDID
> > + probing
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + nvidia,hpd-gpio:
> > + description: specifies a GPIO used for hotplug detection
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
>
> *-gpio has a type already. Just 'maxItems: 1' needed.
Yes, that seems to work fine.
> > +
> > + nvidia,edid:
> > + description: supplies a binary EDID blob
> > + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +
> > + nvidia,panel:
> > + description: phandle of a display panel
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + status:
> > + $ref: "/schemas/dt-core.yaml#/properties/status"
> > +
> > + phandle:
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + unevaluatedProperties: false
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra124-host1x
> > + - nvidia,tegra210-host1x
> > + - nvidia,tegra186-host1x
> > + - nvidia,tegra194-host1x
> > + then:
> > + patternProperties:
> > + "^sor@[0-9a-f]+$":
> > + description: |
> > + The Serial Output Resource (SOR) can be used to drive HDMI, LVDS,
> > + eDP and DP outputs.
> > +
> > + See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
> > + regarding the DPAUX pad controller bindings.
> > + type: object
> > + properties:
> > + # required
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra124-sor
> > + - items:
> > + - const: nvidia,tegra132-sor
> > + - const: nvidia,tegra124-sor
> > + - const: nvidia,tegra210-sor
> > + - const: nvidia,tegra210-sor1
> > + - const: nvidia,tegra186-sor
> > + - const: nvidia,tegra186-sor1
> > + - const: nvidia,tegra194-sor
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: sor
> > +
> > + status:
> > + $ref: "/schemas/dt-core.yaml#/properties/status"
>
> 'status' should never need to be listed.
This seems to be needed at least when I try to validate against a single
binding, like so:
$ make DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml dtbs_check
I assume that that somehow prevents the tooling from looking at any of
the other bindings, which in turn then causes status and other standard
properties to never be defined and then it flags them as extra and
causes a failure.
I think I've even seen this trigger on dt_binding_check if I happened to
have status in there. Now, you've mentioned elsewhere that we shouldn't
use "status" in examples, so that would work around this. However, I
think I've seen this happen as well in examples that referenced some
node via phandle, and then dt_binding_check would emit an error about
phandle being undefined.
Perhaps this is a problem with the tooling? Should we instruct the
scripts to always include the core schema even if we're only testing a
single YAML file via DT_SCHEMA_FILES?
> > +
> > + power-domains:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + avdd-io-hdmi-dp-supply:
> > + description: I/O supply for HDMI/DP
> > +
> > + vdd-hdmi-dp-pll-supply:
> > + description: PLL supply for HDMI/DP
> > +
> > + hdmi-supply:
> > + description: +5.0V HDMI connector supply
> > +
> > + # Tegra186 and later
> > + nvidia,interface:
> > + description: index of the SOR interface
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + # optional
> > + nvidia,ddc-i2c-bus:
> > + description: phandle of an I2C controller used for DDC EDID
> > + probing
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + nvidia,hpd-gpio:
> > + description: specifies a GPIO used for hotplug detection
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + nvidia,edid:
> > + description: supplies a binary EDID blob
> > + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +
> > + nvidia,panel:
> > + description: phandle of a display panel
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + nvidia,xbar-cfg:
> > + description: 5 cells containing the crossbar configuration.
> > + Each lane of the SOR, identified by the cell's index, is
> > + mapped via the crossbar to the pad specified by the cell's
> > + value.
> > + $ref: "/schemas/types.yaml#/definitions/uint32-array"
> > +
> > + # optional when driving an eDP output
> > + nvidia,dpaux:
> > + description: phandle to a DispayPort AUX interface
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + pinctrl-names: true
> > + phandle:
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
>
> 'phandle' shouldn't need to be listed.
>
> > +
> > + patternProperties:
> > + "^pinctrl-[0-9]+$": true
>
> pinctrl properties are automatically added, but maybe not if under an
> 'if' schema. Really, I think probably either this should be split
> into multiple schema files or all of these child nodes should be
> described at the top-level. I'm not sure it's really important to define
> which set of child nodes belong or not for each chip.
I'm not too worried about the set of child nodes for each chip, but I
think having this all in one file underlines the importance of the
hierarchy. If these were discrete bindings for each of the compatible
strings it'd be easy for someone to create them as standalone nodes in
device tree, but that's not something that would work. All of these
devices are children of host1x and they do depend on host1x for a lot
of the functionality, so the hierarchy must be respected.
> I'm stopping there. I think the rest is more of the same comments.
I've made a pass over the whole file and fixed the issues that you
pointed out above in other places.
Sounds like the biggest remaining issue is with the duplicated standard
properties. I'm not a huge fan of giving up on doing the right thing
because the tooling can't deal with it. I think we should fix the
tooling to do the right thing. So if there's something in the core DT
schema then it should apply regardless of what mode we run in. Much of
the above issues should go away once that's fixed.
Any thoughts on making some of the schema files "always included"? I
haven't looked at this side of the tooling at all yet, so I'm not sure
how difficult that would be, but if you're okay with it conceptually I
can take a closer look.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 26/38] dt-bindings: pci: iommu: Convert to json-schema
From: Thierry Reding @ 2020-06-18 14:18 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200618023457.GA3343853@bogus>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
On Wed, Jun 17, 2020 at 08:34:57PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:18:51PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > Convert the PCI IOMMU device tree bindings from free-form text format to
> > json-schema.
> >
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../devicetree/bindings/pci/pci-iommu.txt | 171 ------------------
> > .../devicetree/bindings/pci/pci-iommu.yaml | 168 +++++++++++++++++
> > 2 files changed, 168 insertions(+), 171 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
> > create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.yaml
>
> This needs to come before you use it.
Of course, will rearrange the patches.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support nvidia, headset property
From: Sasha Levin @ 2020-06-18 14:30 UTC (permalink / raw)
To: Mark Brown
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA, Dmitry Osipenko,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200618110023.GB5789-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Thu, Jun 18, 2020 at 12:00:23PM +0100, Mark Brown wrote:
>On Wed, Jun 17, 2020 at 09:01:41PM -0400, Sasha Levin wrote:
>> From: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> [ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
>>
>> The microphone-jack state needs to be masked in a case of a 4-pin jack
>> when microphone and ground pins are shorted. Presence of nvidia,headset
>> tells that WM8903 CODEC driver should mask microphone's status if short
>> circuit is detected, i.e headphones are inserted.
>
>This is a new feature not a bugfix.
I saw this patch more as a hardware quirk.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support nvidia, headset property
From: Mark Brown @ 2020-06-18 14:39 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA, Dmitry Osipenko,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200618143046.GT1931@sasha-vm>
[-- Attachment #1: Type: text/plain, Size: 791 bytes --]
On Thu, Jun 18, 2020 at 10:30:46AM -0400, Sasha Levin wrote:
> On Thu, Jun 18, 2020 at 12:00:23PM +0100, Mark Brown wrote:
> > On Wed, Jun 17, 2020 at 09:01:41PM -0400, Sasha Levin wrote:
> > > From: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >
> > > [ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ]
> > >
> > > The microphone-jack state needs to be masked in a case of a 4-pin jack
> > > when microphone and ground pins are shorted. Presence of nvidia,headset
> > > tells that WM8903 CODEC driver should mask microphone's status if short
> > > circuit is detected, i.e headphones are inserted.
> > This is a new feature not a bugfix.
> I saw this patch more as a hardware quirk.
Pretty much any DT property is a hardware quirk :(
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
From: Dmitry Osipenko @ 2020-06-18 15:07 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200617165008.GB3547875@ulmo>
17.06.2020 19:50, Thierry Reding пишет:
> On Wed, Jun 17, 2020 at 05:33:00PM +0300, Dmitry Osipenko wrote:
>> 17.06.2020 17:24, Dmitry Osipenko пишет:
>>> 17.06.2020 17:17, Thierry Reding пишет:
>>>> On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
>>>>> 12.06.2020 17:18, Thierry Reding пишет:
>>>>> ...
>>>>>> +patternProperties:
>>>>>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
>>>>>> + "^gpios(-[a-zA-Z0-9-]+)?$":
>>>>>> + type: object
>>>>>> + required:
>>>>>> + - gpio-hog
>>>>>
>>>>> There are two problems here:
>>>>>
>>>>> 1. This naming limitation didn't exist before this patch, so it's not a
>>>>> part of the conversion.
>>>>>
>>>>> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
>>>>> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
>>>>> which doesn't make much sense to me.
>>>>>
>>>>> Please explain the rationale of this change.
>>>>
>>>> We could probably do without this if we didn't enforce additional or
>>>> unevaluated properties. Because if we don't match on a pattern here then
>>>> all of those GPIO hog nodes would show up as "extra" properties and they
>>>> are currently not allowed. If we do allow them, then we can drop this,
>>>> but we then have no way to fail validation for whatever else somebody
>>>> might want to put into these device tree nodes.
>>>>
>>>> That said, I think additionalProperties can be a schema in itself, so
>>>> maybe there's a way to only allow additional properties if they are of
>>>> type object and have a gpio-hog property. I'll look into that.
>>>
>>> Isn't it possible to validate the additional properties by checking what
>>> properties they have?
>>>
>>> For example, if sub-node has a gpio-hog property then this sub-node is
>>> okay, otherwise fail.
>>>
>>
>> Ah, I haven't finished reading yours last sentence before started to
>> type :) Yes, it will be nice if we could avoid the naming limitation, or
>> at least change it to something like xxx-hog.
>
> So according to the json-schema specification, both additionalProperties
> and unevaluatedProperties must be a valid JSON schema, which means they
> can be objects rather than just booleans. Unfortunately, dt-schema tools
> don't allow these to be objects, so the below currently fails with these
> tools at the moment.
>
> I can make it work with the following patch against dt-schema.git:
>
> --- >8 ---
> diff --git a/meta-schemas/keywords.yaml b/meta-schemas/keywords.yaml
> index ed543235d7e7..aa88f726ea3b 100644
> --- a/meta-schemas/keywords.yaml
> +++ b/meta-schemas/keywords.yaml
> @@ -79,7 +79,11 @@ properties:
> additionalItems:
> type: boolean
> additionalProperties:
> - type: boolean
> + oneOf:
> + - type: object
> + allOf:
> + - $ref: "#/definitions/sub-schemas"
> + - type: boolean
> allOf:
> items:
> $ref: "#/definitions/sub-schemas"
> @@ -140,7 +144,11 @@ properties:
> type: true
> typeSize: true
> unevaluatedProperties:
> - type: boolean
> + oneOf:
> + - type: object
> + allOf:
> + - $ref: "#/definitions/sub-schemas"
> + - type: boolean
> uniqueItems:
> type: boolean
>
> --- >8 ---
>
> With that applied, I can make validation of gpio-hog nodes work without
> requiring the names to change, which incidentally will allow me to drop
> one of the fixup patches from the ARM/arm64 DTS series.
>
> Here's a hunk that applies on top of this patch and makes this work.
> I'll squash it in for the next version.
>
> --- >8 ---
> diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
> index b2debdb0caff..3f8a9c988305 100644
> --- a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
> @@ -57,13 +57,6 @@ properties:
> interrupt-controller:
> description: Marks the device node as an interrupt controller.
>
> -patternProperties:
> - # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
> - "^gpios(-[a-zA-Z0-9-]+)?$":
> - type: object
> - required:
> - - gpio-hog
> -
> allOf:
> - if:
> properties:
> @@ -90,7 +83,10 @@ required:
> - "#interrupt-cells"
> - interrupt-controller
>
> -unevaluatedProperties: false
> +unevaluatedProperties:
> + type: object
> + required:
> + - gpio-hog
>
> examples:
> - |
> --- >8 ---
Thank you for figuring this out! I see that the dt-schema tool is
already updated in the git, very nice!
^ permalink raw reply
* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
From: Rob Herring @ 2020-06-18 15:23 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-tegra
In-Reply-To: <20200618141630.GB3663225@ulmo>
On Thu, Jun 18, 2020 at 8:16 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> On Wed, Jun 17, 2020 at 05:13:26PM -0600, Rob Herring wrote:
> > On Fri, Jun 12, 2020 at 04:18:32PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > >
> > > Convert the Tegra host1x controller bindings from the free-form text
> > > format to json-schema.
> > >
> > > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > ---
> > > .../display/tegra/nvidia,tegra20-host1x.txt | 516 ------
> > > .../display/tegra/nvidia,tegra20-host1x.yaml | 1418 +++++++++++++++++
> > > 2 files changed, 1418 insertions(+), 516 deletions(-)
> > > delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
[...]
> > > + - if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + enum:
> > > + - nvidia,tegra124-host1x
> > > + - nvidia,tegra210-host1x
> > > + - nvidia,tegra186-host1x
> > > + - nvidia,tegra194-host1x
> > > + then:
> > > + patternProperties:
> > > + "^sor@[0-9a-f]+$":
> > > + description: |
> > > + The Serial Output Resource (SOR) can be used to drive HDMI, LVDS,
> > > + eDP and DP outputs.
> > > +
> > > + See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
> > > + regarding the DPAUX pad controller bindings.
> > > + type: object
> > > + properties:
> > > + # required
> > > + compatible:
> > > + oneOf:
> > > + - const: nvidia,tegra124-sor
> > > + - items:
> > > + - const: nvidia,tegra132-sor
> > > + - const: nvidia,tegra124-sor
> > > + - const: nvidia,tegra210-sor
> > > + - const: nvidia,tegra210-sor1
> > > + - const: nvidia,tegra186-sor
> > > + - const: nvidia,tegra186-sor1
> > > + - const: nvidia,tegra194-sor
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + resets:
> > > + items:
> > > + - description: module reset
> > > +
> > > + reset-names:
> > > + items:
> > > + - const: sor
> > > +
> > > + status:
> > > + $ref: "/schemas/dt-core.yaml#/properties/status"
> >
> > 'status' should never need to be listed.
>
> This seems to be needed at least when I try to validate against a single
> binding, like so:
>
> $ make DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml dtbs_check
>
> I assume that that somehow prevents the tooling from looking at any of
> the other bindings, which in turn then causes status and other standard
> properties to never be defined and then it flags them as extra and
> causes a failure.
I'm surprised using DT_SCHEMA_FILES makes a difference. I'm guessing
that has your 'unevaluatedProperties' support. If so, that means
there's an unintended side effect that any common schema property
becomes always allowed. That's good for 'status' and 'phandle', but
not so much for 'reg', '*-gpios, '*-names', etc.
> I think I've even seen this trigger on dt_binding_check if I happened to
> have status in there. Now, you've mentioned elsewhere that we shouldn't
> use "status" in examples, so that would work around this. However, I
> think I've seen this happen as well in examples that referenced some
> node via phandle, and then dt_binding_check would emit an error about
> phandle being undefined.
>
> Perhaps this is a problem with the tooling? Should we instruct the
> scripts to always include the core schema even if we're only testing a
> single YAML file via DT_SCHEMA_FILES?
The purpose of DT_SCHEMA_FILES is to see warnings just from that
schema file. If the core schema was warning free, we could add that,
but it's not. Plus that wouldn't solve the problem here. 'status' and
'phandle' are added to each schema by the tooling (along with other
things), not by another schema file (well, they are in another schema
file, but they are added to each schema so that 'additionalProperties:
false' works).
This is certainly a limitation in the tooling in that what you have is
a bit different from the expected form. Generally it is expected that
everything is defined under the top-level 'properties' and then any
'if/then' schema only add further constraints. However, you have the
child nodes only defined under an if/then. We could fix that, but I'm
not sure I want to. IMO, extensive use of if/then is a sign the schema
should be split up. More on that below.
> > > + pinctrl-names: true
> > > + phandle:
> > > + $ref: "/schemas/types.yaml#/definitions/uint32"
> >
> > 'phandle' shouldn't need to be listed.
> >
> > > +
> > > + patternProperties:
> > > + "^pinctrl-[0-9]+$": true
> >
> > pinctrl properties are automatically added, but maybe not if under an
> > 'if' schema. Really, I think probably either this should be split
> > into multiple schema files or all of these child nodes should be
> > described at the top-level. I'm not sure it's really important to define
> > which set of child nodes belong or not for each chip.
>
> I'm not too worried about the set of child nodes for each chip, but I
> think having this all in one file underlines the importance of the
> hierarchy. If these were discrete bindings for each of the compatible
> strings it'd be easy for someone to create them as standalone nodes in
> device tree, but that's not something that would work. All of these
> devices are children of host1x and they do depend on host1x for a lot
> of the functionality, so the hierarchy must be respected.
I'm not saying don't describe the hierarchy.
The first option is 1 host1x schema file per SoC (roughly) and the
'host1x' parent node would be duplicated in each one. That doesn't
worry me too much as it's all standard properties and not that many of
them. Though you could have a common 'host1x-bus.yaml' just describing
the parent node properties that each <soc>-host1x.yaml references.
The 2nd option is keep this as a single file, but just move every
child node definition under the top-level 'patternProperties'. This
option has the limitation that you can't enforce which child nodes are
valid per SoC.
> > I'm stopping there. I think the rest is more of the same comments.
>
> I've made a pass over the whole file and fixed the issues that you
> pointed out above in other places.
>
> Sounds like the biggest remaining issue is with the duplicated standard
> properties. I'm not a huge fan of giving up on doing the right thing
> because the tooling can't deal with it. I think we should fix the
> tooling to do the right thing. So if there's something in the core DT
> schema then it should apply regardless of what mode we run in. Much of
> the above issues should go away once that's fixed.
>
> Any thoughts on making some of the schema files "always included"? I
> haven't looked at this side of the tooling at all yet, so I'm not sure
> how difficult that would be, but if you're okay with it conceptually I
> can take a closer look.
Hopefully, it's clear why that doesn't help here. But don't worry,
there's plenty of other work to do on the tooling. :)
Rob
^ permalink raw reply
* Re: [PATCH 35/38] dt-bindings: memory: Update Tegra210 EMC bindings
From: Rob Herring @ 2020-06-18 15:36 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200612141903.2391044-36-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Jun 12, 2020 at 04:19:00PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> The Tegra210 EMC is a cooling device because it can throttle the EMC
> frequency if the chip gets too hot. The device tree node therefore needs
> to contain the "#cooling-cells" property. Furthermore, multiple reserved
> memory regions can now be attached to the EMC device tree node, and the
> new memory-region-names property can be used to differentiate between
> them.
>
> While at it, update the example to make it more fully-featured.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../nvidia,tegra210-emc.yaml | 34 ++++++++++++++-----
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
> index 49ab09252e52..4e8f659f1a7c 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
> @@ -34,16 +34,25 @@ properties:
> - description: EMC general interrupt
>
> memory-region:
> - $ref: /schemas/types.yaml#/definitions/phandle
> - description:
> - phandle to a reserved memory region describing the table of EMC
> - frequencies trained by the firmware
> + description: List of phandles to reserved memory regions describing the
> + nominal and derated tables of EMC frequencies trained by the firmware.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + memory-region-names:
> + $ref: "/schemas/types.yaml#/definitions/string-array"
*-names has a type, so can be dropped.
> + items:
> + - const: nominal
> + - const: derated
>
> nvidia,memory-controller:
> - $ref: /schemas/types.yaml#/definitions/phandle
> + $ref: "/schemas/types.yaml#/definitions/phandle"
Quotes aren't needed here. (We haven't been consistent on this).
> description:
> phandle of the memory controller node
>
> + "#cooling-cells":
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + const: 2
> +
> required:
> - compatible
> - reg
> @@ -51,7 +60,10 @@ required:
> - clock-names
> - nvidia,memory-controller
>
> -additionalProperties: false
> +dependencies:
> + memory-region-names: [ memory-region ]
The core schema should handle this (probably needs to be added).
> +
> +unevaluatedProperties: false
>
> examples:
> - |
> @@ -63,10 +75,15 @@ examples:
> #size-cells = <1>;
> ranges;
>
> - emc_table: emc-table@83400000 {
> + nominal: emc-table@83400000 {
> compatible = "nvidia,tegra210-emc-table";
> reg = <0x83400000 0x10000>;
> };
> +
> + derated: emc-table@83410000 {
> + compatible = "nvidia,tegar210-emc-table";
> + reg = <0x83410000 0x10000>;
> + };
> };
>
> external-memory-controller@7001b000 {
> @@ -77,6 +94,7 @@ examples:
> clocks = <&tegra_car TEGRA210_CLK_EMC>;
> clock-names = "emc";
> interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
> - memory-region = <&emc_table>;
> + memory-region-names = "nominal", "derated";
> + memory-region = <&nominal>, <&derated>;
> nvidia,memory-controller = <&mc>;
> };
> --
> 2.24.1
>
^ permalink raw reply
* [PATCH v6 20/36] drm: tegra: fix common struct sg_table related issues
From: Marek Szyprowski @ 2020-06-18 15:39 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Marek Szyprowski, Christoph Hellwig, Robin Murphy,
Bartlomiej Zolnierkiewicz,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Airlie,
Daniel Vetter, Thierry Reding, Jonathan Hunter,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200618153956.29558-1-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().
struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).
It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.
To avoid such issues, lets use a common dma-mapping wrappers operating
directly on the struct sg_table objects and use scatterlist page
iterators where possible. This, almost always, hides references to the
nents and orig_nents entries, making the code robust, easier to follow
and copy/paste safe.
Signed-off-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
drivers/gpu/drm/tegra/gem.c | 27 ++++++++++-----------------
drivers/gpu/drm/tegra/plane.c | 15 +++++----------
2 files changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 723df142a981..01d94befab11 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -98,8 +98,8 @@ static struct sg_table *tegra_bo_pin(struct device *dev, struct host1x_bo *bo,
* the SG table needs to be copied to avoid overwriting any
* other potential users of the original SG table.
*/
- err = sg_alloc_table_from_sg(sgt, obj->sgt->sgl, obj->sgt->nents,
- GFP_KERNEL);
+ err = sg_alloc_table_from_sg(sgt, obj->sgt->sgl,
+ obj->sgt->orig_nents, GFP_KERNEL);
if (err < 0)
goto free;
} else {
@@ -196,8 +196,7 @@ static int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
bo->iova = bo->mm->start;
- bo->size = iommu_map_sg(tegra->domain, bo->iova, bo->sgt->sgl,
- bo->sgt->nents, prot);
+ bo->size = iommu_map_sgtable(tegra->domain, bo->iova, bo->sgt, prot);
if (!bo->size) {
dev_err(tegra->drm->dev, "failed to map buffer\n");
err = -ENOMEM;
@@ -264,8 +263,7 @@ static struct tegra_bo *tegra_bo_alloc_object(struct drm_device *drm,
static void tegra_bo_free(struct drm_device *drm, struct tegra_bo *bo)
{
if (bo->pages) {
- dma_unmap_sg(drm->dev, bo->sgt->sgl, bo->sgt->nents,
- DMA_FROM_DEVICE);
+ dma_unmap_sgtable(drm->dev, bo->sgt, DMA_FROM_DEVICE, 0);
drm_gem_put_pages(&bo->gem, bo->pages, true, true);
sg_free_table(bo->sgt);
kfree(bo->sgt);
@@ -290,12 +288,9 @@ static int tegra_bo_get_pages(struct drm_device *drm, struct tegra_bo *bo)
goto put_pages;
}
- err = dma_map_sg(drm->dev, bo->sgt->sgl, bo->sgt->nents,
- DMA_FROM_DEVICE);
- if (err == 0) {
- err = -EFAULT;
+ err = dma_map_sgtable(drm->dev, bo->sgt, DMA_FROM_DEVICE, 0);
+ if (err)
goto free_sgt;
- }
return 0;
@@ -571,7 +566,7 @@ tegra_gem_prime_map_dma_buf(struct dma_buf_attachment *attach,
goto free;
}
- if (dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir) == 0)
+ if (dma_map_sgtable(attach->dev, sgt, dir, 0))
goto free;
return sgt;
@@ -590,7 +585,7 @@ static void tegra_gem_prime_unmap_dma_buf(struct dma_buf_attachment *attach,
struct tegra_bo *bo = to_tegra_bo(gem);
if (bo->pages)
- dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+ dma_unmap_sgtable(attach->dev, sgt, dir, 0);
sg_free_table(sgt);
kfree(sgt);
@@ -609,8 +604,7 @@ static int tegra_gem_prime_begin_cpu_access(struct dma_buf *buf,
struct drm_device *drm = gem->dev;
if (bo->pages)
- dma_sync_sg_for_cpu(drm->dev, bo->sgt->sgl, bo->sgt->nents,
- DMA_FROM_DEVICE);
+ dma_sync_sgtable_for_cpu(drm->dev, bo->sgt, DMA_FROM_DEVICE);
return 0;
}
@@ -623,8 +617,7 @@ static int tegra_gem_prime_end_cpu_access(struct dma_buf *buf,
struct drm_device *drm = gem->dev;
if (bo->pages)
- dma_sync_sg_for_device(drm->dev, bo->sgt->sgl, bo->sgt->nents,
- DMA_TO_DEVICE);
+ dma_sync_sgtable_for_device(drm->dev, bo->sgt, DMA_TO_DEVICE);
return 0;
}
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index 9ccfb56e9b01..0d2ef1662a39 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -130,12 +130,9 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct tegra_plane_state *state)
}
if (sgt) {
- err = dma_map_sg(dc->dev, sgt->sgl, sgt->nents,
- DMA_TO_DEVICE);
- if (err == 0) {
- err = -ENOMEM;
+ err = dma_map_sgtable(dc->dev, sgt, DMA_TO_DEVICE, 0);
+ if (err)
goto unpin;
- }
/*
* The display controller needs contiguous memory, so
@@ -143,7 +140,7 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct tegra_plane_state *state)
* map its SG table to a single contiguous chunk of
* I/O virtual memory.
*/
- if (err > 1) {
+ if (sgt->nents > 1) {
err = -EINVAL;
goto unpin;
}
@@ -165,8 +162,7 @@ static int tegra_dc_pin(struct tegra_dc *dc, struct tegra_plane_state *state)
struct sg_table *sgt = state->sgt[i];
if (sgt)
- dma_unmap_sg(dc->dev, sgt->sgl, sgt->nents,
- DMA_TO_DEVICE);
+ dma_unmap_sgtable(dc->dev, sgt, DMA_TO_DEVICE, 0);
host1x_bo_unpin(dc->dev, &bo->base, sgt);
state->iova[i] = DMA_MAPPING_ERROR;
@@ -185,8 +181,7 @@ static void tegra_dc_unpin(struct tegra_dc *dc, struct tegra_plane_state *state)
struct sg_table *sgt = state->sgt[i];
if (sgt)
- dma_unmap_sg(dc->dev, sgt->sgl, sgt->nents,
- DMA_TO_DEVICE);
+ dma_unmap_sgtable(dc->dev, sgt, DMA_TO_DEVICE, 0);
host1x_bo_unpin(dc->dev, &bo->base, sgt);
state->iova[i] = DMA_MAPPING_ERROR;
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox