* Re: [PATCH] ASoC: tegra: Fix reference count leaks.
From: Jon Hunter @ 2020-06-16 19:42 UTC (permalink / raw)
To: wu000273-OJFnDUYgAso, kjlu-OJFnDUYgAso
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Thierry Reding, YueHaibing, Ben Dooks, Edward Cragg,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200613204422.24484-1-wu000273-OJFnDUYgAso@public.gmane.org>
On 13/06/2020 21:44, wu000273-OJFnDUYgAso@public.gmane.org wrote:
> From: Qiushi Wu <wu000273-OJFnDUYgAso@public.gmane.org>
>
> Calling pm_runtime_get_sync increments the counter even in case of
> failure, causing incorrect ref count if pm_runtime_put is not called in
> error handling paths. Call pm_runtime_put if pm_runtime_get_sync fails.
>
> Signed-off-by: Qiushi Wu <wu000273-OJFnDUYgAso@public.gmane.org>
> ---
> sound/soc/tegra/tegra30_ahub.c | 4 +++-
> sound/soc/tegra/tegra30_i2s.c | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c
> index 635eacbd28d4..156e3b9d613c 100644
> --- a/sound/soc/tegra/tegra30_ahub.c
> +++ b/sound/soc/tegra/tegra30_ahub.c
> @@ -643,8 +643,10 @@ static int tegra30_ahub_resume(struct device *dev)
> int ret;
>
> ret = pm_runtime_get_sync(dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put(dev);
> return ret;
> + }
> ret = regcache_sync(ahub->regmap_ahub);
> ret |= regcache_sync(ahub->regmap_apbif);
> pm_runtime_put(dev);
> diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c
> index d59882ec48f1..db5a8587bfa4 100644
> --- a/sound/soc/tegra/tegra30_i2s.c
> +++ b/sound/soc/tegra/tegra30_i2s.c
> @@ -567,8 +567,10 @@ static int tegra30_i2s_resume(struct device *dev)
> int ret;
>
> ret = pm_runtime_get_sync(dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put(dev);
> return ret;
> + }
> ret = regcache_sync(i2s->regmap);
> pm_runtime_put(dev);
Thanks.
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 03/73] ARM: tegra: Remove simple regulators bus
From: Jon Hunter @ 2020-06-16 19:24 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20200616135238.3001888-4-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 16/06/2020 14:51, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> The standard way to do this is to list out the regulators at the top
> level. Adopt the standard way to fix validation.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/boot/dts/tegra114-dalmore.dts | 129 +++++------
> arch/arm/boot/dts/tegra114-roth.dts | 120 +++++-----
> arch/arm/boot/dts/tegra114-tn7.dts | 65 +++---
> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 238 +++++++++----------
> arch/arm/boot/dts/tegra124-nyan.dtsi | 259 ++++++++++-----------
> arch/arm/boot/dts/tegra124-venice2.dts | 265 ++++++++++------------
> arch/arm/boot/dts/tegra20-harmony.dts | 121 +++++-----
> arch/arm/boot/dts/tegra20-medcom-wide.dts | 66 +++---
> arch/arm/boot/dts/tegra20-paz00.dts | 38 ++--
> arch/arm/boot/dts/tegra20-plutux.dts | 66 +++---
> arch/arm/boot/dts/tegra20-seaboard.dts | 125 +++++-----
> arch/arm/boot/dts/tegra20-tamonten.dtsi | 39 +---
> arch/arm/boot/dts/tegra20-tec.dts | 66 +++---
> arch/arm/boot/dts/tegra20-trimslice.dts | 85 +++----
> arch/arm/boot/dts/tegra20-ventana.dts | 85 +++----
> arch/arm/boot/dts/tegra30-beaver.dts | 193 ++++++++--------
> arch/arm/boot/dts/tegra30-cardhu-a02.dts | 128 +++++------
> arch/arm/boot/dts/tegra30-cardhu-a04.dts | 149 ++++++------
> arch/arm/boot/dts/tegra30-cardhu.dtsi | 261 ++++++++++-----------
> 19 files changed, 1130 insertions(+), 1368 deletions(-)
...
> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
> index 6a7a31c831c5..effdb303c7f7 100644
> --- a/arch/arm/boot/dts/tegra124-venice2.dts
> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
> @@ -1077,164 +1077,145 @@ power {
>
> panel: panel {
> compatible = "lg,lp129qe";
> -
> + power-supply = <&vdd_3v3_panel>;
> backlight = <&backlight>;
> ddc-i2c-bus = <&dpaux>;
> };
Is this meant to be in this patch?
> diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
> index 20137fc578b1..95e6bccdb4f6 100644
> --- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
> +++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
> @@ -495,40 +495,25 @@ usb-phy@c5008000 {
> status = "okay";
> };
>
> - sdhci@c8000600 {
> + mmc@c8000600 {
> cd-gpios = <&gpio TEGRA_GPIO(H, 2) GPIO_ACTIVE_LOW>;
> wp-gpios = <&gpio TEGRA_GPIO(H, 3) GPIO_ACTIVE_HIGH>;
> bus-width = <4>;
> status = "okay";
> };
>
> - clocks {
> - compatible = "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - clk32k_in: clock@0 {
> - compatible = "fixed-clock";
> - reg = <0>;
> - #clock-cells = <0>;
> - clock-frequency = <32768>;
> - };
> + clk32k_in: clock@0 {
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + #clock-cells = <0>;
> };
The above appears in to be in the wrong patch.
> diff --git a/arch/arm/boot/dts/tegra30-cardhu-a02.dts b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
> index a02ec5082287..4899e05a0d9c 100644
> --- a/arch/arm/boot/dts/tegra30-cardhu-a02.dts
> +++ b/arch/arm/boot/dts/tegra30-cardhu-a02.dts
> @@ -9,87 +9,75 @@ / {
> model = "NVIDIA Tegra30 Cardhu A02 evaluation board";
> compatible = "nvidia,cardhu-a02", "nvidia,cardhu", "nvidia,tegra30";
>
> - sdhci@78000400 {
> + mmc@78000400 {
> status = "okay";
> power-gpios = <&gpio TEGRA_GPIO(D, 4) GPIO_ACTIVE_HIGH>;
> bus-width = <4>;
> keep-power-in-suspend;
> };
And here.
> diff --git a/arch/arm/boot/dts/tegra30-cardhu-a04.dts b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
> index 9234988624ec..c1c0ca628af1 100644
> --- a/arch/arm/boot/dts/tegra30-cardhu-a04.dts
> +++ b/arch/arm/boot/dts/tegra30-cardhu-a04.dts
> @@ -11,99 +11,86 @@ / {
> model = "NVIDIA Tegra30 Cardhu A04 (A05, A06, A07) evaluation board";
> compatible = "nvidia,cardhu-a04", "nvidia,cardhu", "nvidia,tegra30";
>
> - sdhci@78000400 {
> + mmc@78000400 {
> status = "okay";
> power-gpios = <&gpio TEGRA_GPIO(D, 3) GPIO_ACTIVE_HIGH>;
> bus-width = <4>;
> keep-power-in-suspend;
> };
And here.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 02/73] ARM: tegra: Remove simple clocks bus
From: Jon Hunter @ 2020-06-16 19:06 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20200616135238.3001888-3-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 16/06/2020 14:51, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> The standard way to do this is to list out the clocks at the top-level.
> Adopt the standard way to fix validation.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/boot/dts/tegra114-dalmore.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra114-roth.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra114-tn7.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra124-nyan.dtsi | 15 ++++-----------
> arch/arm/boot/dts/tegra124-venice2.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra20-harmony.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra20-paz00.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra20-seaboard.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra20-trimslice.dts | 19 ++++++-------------
> arch/arm/boot/dts/tegra20-ventana.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra30-beaver.dts | 15 ++++-----------
> arch/arm/boot/dts/tegra30-cardhu.dtsi | 15 ++++-----------
> 13 files changed, 54 insertions(+), 145 deletions(-)
...
> diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
> index 8debd3d3c20d..5b26482a55b7 100644
> --- a/arch/arm/boot/dts/tegra20-trimslice.dts
> +++ b/arch/arm/boot/dts/tegra20-trimslice.dts
> @@ -366,30 +366,23 @@ usb-phy@c5008000 {
> status = "okay";
> };
>
> - sdhci@c8000000 {
> + mmc@c8000000 {
> status = "okay";
> broken-cd;
> bus-width = <4>;
> };
>
> - sdhci@c8000600 {
> + mmc@c8000600 {
> status = "okay";
> cd-gpios = <&gpio TEGRA_GPIO(P, 1) GPIO_ACTIVE_LOW>;
> wp-gpios = <&gpio TEGRA_GPIO(P, 2) GPIO_ACTIVE_HIGH>;
> bus-width = <4>;
> };
I think that the above belongs in patch 13/73.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2 0/5] 180 degrees rotation support for NVIDIA Tegra DRM
From: Emil Velikov @ 2020-06-16 18:54 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Thierry Reding, Thomas Zimmermann, Derek Basehore, Sam Ravnborg,
Laurent Pinchart, Sean Paul, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel
In-Reply-To: <646b3f37-0f72-7f3b-388f-f71dbcdd5c84-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, 16 Jun 2020 at 18:20, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> 16.06.2020 18:48, Emil Velikov пишет:
> > On Tue, 16 Jun 2020 at 12:40, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >> 16.06.2020 01:26, Emil Velikov пишет:
> >>> Hi Dmitry,
> >>>
> >>> On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>
> >>>> Hello!
> >>>>
> >>>> This series adds 180° display plane rotation support to the NVIDIA Tegra
> >>>> DRM driver which is needed for devices that have display panel physically
> >>>> mounted upside-down, like Nexus 7 tablet device for example [1]. Since
> >>>> DRM panel rotation is a new thing for a userspace, currently only
> >>>> Opentegra Xorg driver handles the rotated display panel [2], but this
> >>>> is good enough for the start.
> >>>>
> >>>> Note that later on it should be possible to implement a transparent 180°
> >>>> display rotation for Tegra DRM driver which will remove the need to have
> >>>> a bleeding edge userspace that knows how to rotate display planes and I'm
> >>>> slowly working on it. For the starter we can go with the minimal rotation
> >>>> support, so it's not a blocker.
> >>>>
> >>>> This series is based on the work that was made by Derek Basehore for the
> >>>> Mediatek driver [3], his patch is included into this patchset. I added
> >>>> my tested-by tag to the Derek's patch.
> >>>>
> >>>> Please review and apply, thanks in advance!
> >>>>
> >>>> [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200607154327.18589-3-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org/
> >>>> [2] https://github.com/grate-driver/xf86-video-opentegra/commit/28eb20a3959bbe5bc3a3b67e55977093fd5114ca
> >>>> [3] https://lkml.org/lkml/2020/3/5/1119
> >>>>
> >>>> Changelog:
> >>>>
> >>>> v2: - Dropped "drm/panel: Set display info in panel attach" patch, which
> >>>> turned out to be obsolete now.
> >>>>
> >>>> - Renamed the cover-latter, hopefully this will fix the bouncing emails.
> >>>>
> >>>> Derek Basehore (1):
> >>>> drm/panel: Add helper for reading DT rotation
> >>>>
> >>>> Dmitry Osipenko (4):
> >>>> drm/panel: lvds: Set up panel orientation
> >>>
> >>> IMHO it's perfectly reasonable to report the panel orientation to
> >>> userspace, which can apply plane rotation as needed.
> >>>
> >>> Although I see that this series, alike Derek's, has a couple of issues:
> >>> - only a single panel driver is updated
> >>> - rotation is _not_ listed as supported property, in said panel
> >>> driver device-tree bindings
> >>>
> >>> My personal inclination is that we should aim for a comprehensive solution:
> >>> - wire all panel drivers, as currently documented (quick grep list below)
> >>> - document and wire-up the lvds and boe panels - as proposed by you
> >>> and Derek respectively
> >>>
> >>> HTH
> >>> Emil
> >>>
> >>> Documentation/devicetree/bindings/display/himax,hx8357d.txt:2
> >>> Documentation/devicetree/bindings/display/ilitek,ili9225.txt:2
> >>> Documentation/devicetree/bindings/display/ilitek,ili9341.txt:2
> >>> Documentation/devicetree/bindings/display/ilitek,ili9486.yaml:2
> >>> Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt:2
> >>> Documentation/devicetree/bindings/display/panel/panel-common.yaml:2
> >>> Documentation/devicetree/bindings/display/sitronix,st7586.txt:1
> >>> Documentation/devicetree/bindings/display/sitronix,st7735r.yaml:2
> >>
> >> Rotation is a common DT panel property that is described in the
> >> panel-common.yaml.
> > The property was introduced almost exclusively for tiny drm panels.
> > Those ones are a bit different from the rest (in panel/) -
> > MIPI-DBI/SPI w/o (not connected at least) an actual GPU.
> >
> > To make it a bit better, the rotation is seemingly performed in the
> > tiny driver itself ouch.
> >
> >> This property is supported by all panel bindings
> >> because these bindings inherent the common properties from the
> >> panel-common.yaml.
> >>
> > Seems like that was an unintentional change with the conversion to YAML.
> > Beforehand only a few selected panels had rotation. Upon closer look -
> > some panels do have follow-up fixes, to remove/limit the implicit
> > inclusion.
>
> Interesting.. my understanding that the rotation property is supposed to
> be a generic property which represents physical orientation of a display
> panel and hence it should be applicable to all panels.
>
You're spot on - it is/should be a generic property.
I believe that in general many panels were mounted in the correct
orientation so the property, kernel and userspace were slow to catch
up. In some cases panels will use flip x+y to denote 180 rotation, yet
lacking the rotation property.
The s6e8aa0 is an example of the last oddity. To make it better, the
two dts in-tree always set both flip x and y.
Tl;Dr: Hysterical raisins
> > Sam seems like you've done most of the YAML conversion. IMHO it would
> > make sense to revisit the patches and inherit common properties only
> > as applicable.
> >
> >> I don't think that it makes sense to wire up rotation property to all
> >> panel drivers at once because those drivers will be untested, at least I
> >> don't know anything about those other panels and can't test them. It
> >> will be much better to support the rotation on by as-needed basis for
> >> each panel driver individually.
> >
> > How about CCing the author and reviewer asking them to test the patch?
> > The only place where the patches might cause an issue is with tiny,
> > although patches would still be appreciated.
>
> There are quite a lot of panel drivers and I'm a bit doubtful that at
> least half of devices that use those panels have any real use for the
> rotation property. I could write the patches.. but in the end it could
> be a wasted effort if nobody needs it, so I'd prefer not to do it.
That's why I mentioned the rotation introduction or "confusion" if I
may. Skimming through the pre/post YAML device tree bindings and grep
through the panel themselves will greatly reduce the list.
In other words: if neither binding documentation/in-tree dts nor panel
mentions rotation - omit it.
-Emil
^ permalink raw reply
* Re: [PATCH v3] drm/tegra: Add zpos property for cursor planes
From: Dmitry Osipenko @ 2020-06-16 18:39 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, Ville Syrjälä, Daniel Stone,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200616181449.3147258-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
16.06.2020 21:14, Thierry Reding пишет:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> have a zpos property") a warning is emitted if there's a mix of planes
> with and without a zpos property.
>
> On Tegra, cursor planes are always composited on top of all other
> planes, which is why they never had a zpos property attached to them.
> However, since the composition order is fixed, this is trivial to
> remedy by simply attaching an immutable zpos property to them.
>
> v3: do not hardcode zpos for overlay planes used as cursor (Dmitry)
> v2: hardcode cursor plane zpos to 255 instead of 0 (Ville)
>
> Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/gpu/drm/tegra/dc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 83f31c6e891c..04d6848d19fc 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
> }
>
> drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
> + drm_plane_create_zpos_immutable_property(&plane->base, 255);
>
> return &plane->base;
> }
>
Looks nice, thanks! Since you dropped all other zpos changes for other
planes and given that the other planes have 255 for the max zpos, what
about to set the cursor's zpos to 256?
^ permalink raw reply
* [PATCH v3] drm/tegra: Add zpos property for cursor planes
From: Thierry Reding @ 2020-06-16 18:14 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, Ville Syrjälä, Dmitry Osipenko,
Daniel Stone, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
have a zpos property") a warning is emitted if there's a mix of planes
with and without a zpos property.
On Tegra, cursor planes are always composited on top of all other
planes, which is why they never had a zpos property attached to them.
However, since the composition order is fixed, this is trivial to
remedy by simply attaching an immutable zpos property to them.
v3: do not hardcode zpos for overlay planes used as cursor (Dmitry)
v2: hardcode cursor plane zpos to 255 instead of 0 (Ville)
Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
drivers/gpu/drm/tegra/dc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 83f31c6e891c..04d6848d19fc 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
}
drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
+ drm_plane_create_zpos_immutable_property(&plane->base, 255);
return &plane->base;
}
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v2 0/5] 180 degrees rotation support for NVIDIA Tegra DRM
From: Laurent Pinchart @ 2020-06-16 17:45 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Emil Velikov, Thierry Reding, Thomas Zimmermann, Derek Basehore,
Sam Ravnborg, Sean Paul, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel
In-Reply-To: <646b3f37-0f72-7f3b-388f-f71dbcdd5c84-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jun 16, 2020 at 08:20:57PM +0300, Dmitry Osipenko wrote:
> 16.06.2020 18:48, Emil Velikov пишет:
> > On Tue, 16 Jun 2020 at 12:40, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >> 16.06.2020 01:26, Emil Velikov пишет:
> >>> Hi Dmitry,
> >>>
> >>> On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>
> >>>> Hello!
> >>>>
> >>>> This series adds 180° display plane rotation support to the NVIDIA Tegra
> >>>> DRM driver which is needed for devices that have display panel physically
> >>>> mounted upside-down, like Nexus 7 tablet device for example [1]. Since
> >>>> DRM panel rotation is a new thing for a userspace, currently only
> >>>> Opentegra Xorg driver handles the rotated display panel [2], but this
> >>>> is good enough for the start.
> >>>>
> >>>> Note that later on it should be possible to implement a transparent 180°
> >>>> display rotation for Tegra DRM driver which will remove the need to have
> >>>> a bleeding edge userspace that knows how to rotate display planes and I'm
> >>>> slowly working on it. For the starter we can go with the minimal rotation
> >>>> support, so it's not a blocker.
> >>>>
> >>>> This series is based on the work that was made by Derek Basehore for the
> >>>> Mediatek driver [3], his patch is included into this patchset. I added
> >>>> my tested-by tag to the Derek's patch.
> >>>>
> >>>> Please review and apply, thanks in advance!
> >>>>
> >>>> [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200607154327.18589-3-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org/
> >>>> [2] https://github.com/grate-driver/xf86-video-opentegra/commit/28eb20a3959bbe5bc3a3b67e55977093fd5114ca
> >>>> [3] https://lkml.org/lkml/2020/3/5/1119
> >>>>
> >>>> Changelog:
> >>>>
> >>>> v2: - Dropped "drm/panel: Set display info in panel attach" patch, which
> >>>> turned out to be obsolete now.
> >>>>
> >>>> - Renamed the cover-latter, hopefully this will fix the bouncing emails.
> >>>>
> >>>> Derek Basehore (1):
> >>>> drm/panel: Add helper for reading DT rotation
> >>>>
> >>>> Dmitry Osipenko (4):
> >>>> drm/panel: lvds: Set up panel orientation
> >>>
> >>> IMHO it's perfectly reasonable to report the panel orientation to
> >>> userspace, which can apply plane rotation as needed.
> >>>
> >>> Although I see that this series, alike Derek's, has a couple of issues:
> >>> - only a single panel driver is updated
> >>> - rotation is _not_ listed as supported property, in said panel
> >>> driver device-tree bindings
> >>>
> >>> My personal inclination is that we should aim for a comprehensive solution:
> >>> - wire all panel drivers, as currently documented (quick grep list below)
> >>> - document and wire-up the lvds and boe panels - as proposed by you
> >>> and Derek respectively
> >>>
> >>> HTH
> >>> Emil
> >>>
> >>> Documentation/devicetree/bindings/display/himax,hx8357d.txt:2
> >>> Documentation/devicetree/bindings/display/ilitek,ili9225.txt:2
> >>> Documentation/devicetree/bindings/display/ilitek,ili9341.txt:2
> >>> Documentation/devicetree/bindings/display/ilitek,ili9486.yaml:2
> >>> Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt:2
> >>> Documentation/devicetree/bindings/display/panel/panel-common.yaml:2
> >>> Documentation/devicetree/bindings/display/sitronix,st7586.txt:1
> >>> Documentation/devicetree/bindings/display/sitronix,st7735r.yaml:2
> >>
> >> Rotation is a common DT panel property that is described in the
> >> panel-common.yaml.
> > The property was introduced almost exclusively for tiny drm panels.
> > Those ones are a bit different from the rest (in panel/) -
> > MIPI-DBI/SPI w/o (not connected at least) an actual GPU.
> >
> > To make it a bit better, the rotation is seemingly performed in the
> > tiny driver itself ouch.
> >
> >> This property is supported by all panel bindings
> >> because these bindings inherent the common properties from the
> >> panel-common.yaml.
> >>
> > Seems like that was an unintentional change with the conversion to YAML.
> > Beforehand only a few selected panels had rotation. Upon closer look -
> > some panels do have follow-up fixes, to remove/limit the implicit
> > inclusion.
>
> Interesting.. my understanding that the rotation property is supposed to
> be a generic property which represents physical orientation of a display
> panel and hence it should be applicable to all panels.
Adding a bit more food for thoughts, the DT rotation property for camera
sensor modules has recently been documented with lots of details. See
https://lore.kernel.org/linux-media/20200509090456.3496481-3-jacopo-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org/,
part of the documentation may be useful for panels.
> > Sam seems like you've done most of the YAML conversion. IMHO it would
> > make sense to revisit the patches and inherit common properties only
> > as applicable.
> >
> >> I don't think that it makes sense to wire up rotation property to all
> >> panel drivers at once because those drivers will be untested, at least I
> >> don't know anything about those other panels and can't test them. It
> >> will be much better to support the rotation on by as-needed basis for
> >> each panel driver individually.
> >
> > How about CCing the author and reviewer asking them to test the patch?
> > The only place where the patches might cause an issue is with tiny,
> > although patches would still be appreciated.
>
> There are quite a lot of panel drivers and I'm a bit doubtful that at
> least half of devices that use those panels have any real use for the
> rotation property. I could write the patches.. but in the end it could
> be a wasted effort if nobody needs it, so I'd prefer not to do it.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] Input: document inhibiting
From: Randy Dunlap @ 2020-06-16 17:38 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, linux-pm, linux-acpi, linux-kernel,
linux-iio, linux-arm-kernel, linux-samsung-soc, linux-input,
linux-tegra, patches, ibm-acpi-devel, platform-driver-x86
Cc: kernel, Nick Dyer, Laxman Dewangan, Peter Meerwald-Stadler,
Peter Hutterer, Fabio Estevam, Lars-Peter Clausen,
Krzysztof Kozlowski, Jonathan Hunter, Kukjin Kim, NXP Linux Team,
Sylvain Lemieux, Len Brown, Michael Hennerich, Sascha Hauer,
Henrique de Moraes Holschuh, Vladimir Zapolskiy, Hans de Goede,
Michał Mirosław, Barry Song, Dmitry Torokhov,
Rafael J . Wysocki
In-Reply-To: <20200616172909.21625-1-andrzej.p@collabora.com>
On 6/16/20 10:29 AM, Andrzej Pietrasiewicz wrote:
> Document inhibiting input devices and its relation to being
> a wakeup source.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
Hi,
I have some editorial comments. Please see below.
> @Hans, @Dmitry,
>
> My fist attempt at documenting inhibiting. Kindly look at it to see if I haven't got anything
> wrong.
>
> Andrzej
>
> Documentation/input/input-programming.rst | 36 +++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst
> index 45a4c6e05e39..0cd1ad4504fb 100644
> --- a/Documentation/input/input-programming.rst
> +++ b/Documentation/input/input-programming.rst
> @@ -164,6 +164,42 @@ disconnects. Calls to both callbacks are serialized.
> The open() callback should return a 0 in case of success or any nonzero value
> in case of failure. The close() callback (which is void) must always succeed.
>
> +Inhibiting input devices
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Inhibiting a device means ignoring input events from it. As such it is about maintaining
> +relationships with input handlers - either an already existing relationships, or
> +relationships to be established while the device is in inhibited state.
> +
> +If a device is inhibited, no input handler will receive events from it.
> +
> +The fact that nobody wants events from the device is exploited further, by calling device's
> +close() (if there are users) and open() (if there are users) on inhibit and uninhibit
> +operations, respectively. Indeed, the meaning of close() is to stop providing events
> +to the input core and that of open() is to start providing events to the input core.
> +
> +Inhibiting and uninhibiting is orthogonal to opening and closing the device by input
are
> +handlers. Userspace might want to inhibit a device in anticipation before any handler is
> +positively matched against it.
> +
> +Inhibiting and uninhibiting is orthogonal to device's being a wakeup source, too. Being a
are
> +wakeup source plays a role when the system is sleeping, not when the system is operating.
> +How drivers should program their interaction between inhibiting, sleeping and being a wakeup
> +source is driver-specific.
> +
> +Taking the analogy with the network devices - bringing a network interface down doesn't mean
> +that it should be impossible to be wake the system up on LAN through this interface. So, there
> +may be input drivers which should be considered wakeup sources even when inhibited. Actually,
> +in many i2c input devices their interrupt is declared a wakeup interrupt and its handling
I2C
> +happens in driver's core, which is not aware of input-specific inhibit (nor should it be).
> +Composite devices containing several interfaces can be inhibited on a per-interface basis and
> +e.g. inhibiting one interface shouldn't affect the device's capability of being a wakeup source.
> +
> +If a device is to be considered a wakeup source while inhibited, special care must be taken when
> +programming its suspend(), as it might need to call device's open(). Depending on what close()
> +means for the device in question not opening() it before going to sleep might make it impossible
in question, not
> +to provide any wakeup events. The device is going to sleep anyway.
> +
> Basic event types
> ~~~~~~~~~~~~~~~~~
>
>
thanks for documentation.
--
~Randy
^ permalink raw reply
* [PATCH] Input: document inhibiting
From: Andrzej Pietrasiewicz @ 2020-06-16 17:29 UTC (permalink / raw)
To: linux-pm, linux-acpi, linux-kernel, linux-iio, linux-arm-kernel,
linux-samsung-soc, linux-input, linux-tegra, patches,
ibm-acpi-devel, platform-driver-x86
Cc: Rafael J . Wysocki, Len Brown, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Kukjin Kim,
Krzysztof Kozlowski, Dmitry Torokhov, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Vladimir Zapolskiy, Sylvain Lemieux, Laxman Dewangan,
Thierry Reding, Jonathan Hunter, Barry
In-Reply-To: <40988408-8f36-3a52-6439-34084de6b129@redhat.com>
Document inhibiting input devices and its relation to being
a wakeup source.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
---
@Hans, @Dmitry,
My fist attempt at documenting inhibiting. Kindly look at it to see if I haven't got anything
wrong.
Andrzej
Documentation/input/input-programming.rst | 36 +++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/Documentation/input/input-programming.rst b/Documentation/input/input-programming.rst
index 45a4c6e05e39..0cd1ad4504fb 100644
--- a/Documentation/input/input-programming.rst
+++ b/Documentation/input/input-programming.rst
@@ -164,6 +164,42 @@ disconnects. Calls to both callbacks are serialized.
The open() callback should return a 0 in case of success or any nonzero value
in case of failure. The close() callback (which is void) must always succeed.
+Inhibiting input devices
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Inhibiting a device means ignoring input events from it. As such it is about maintaining
+relationships with input handlers - either an already existing relationships, or
+relationships to be established while the device is in inhibited state.
+
+If a device is inhibited, no input handler will receive events from it.
+
+The fact that nobody wants events from the device is exploited further, by calling device's
+close() (if there are users) and open() (if there are users) on inhibit and uninhibit
+operations, respectively. Indeed, the meaning of close() is to stop providing events
+to the input core and that of open() is to start providing events to the input core.
+
+Inhibiting and uninhibiting is orthogonal to opening and closing the device by input
+handlers. Userspace might want to inhibit a device in anticipation before any handler is
+positively matched against it.
+
+Inhibiting and uninhibiting is orthogonal to device's being a wakeup source, too. Being a
+wakeup source plays a role when the system is sleeping, not when the system is operating.
+How drivers should program their interaction between inhibiting, sleeping and being a wakeup
+source is driver-specific.
+
+Taking the analogy with the network devices - bringing a network interface down doesn't mean
+that it should be impossible to be wake the system up on LAN through this interface. So, there
+may be input drivers which should be considered wakeup sources even when inhibited. Actually,
+in many i2c input devices their interrupt is declared a wakeup interrupt and its handling
+happens in driver's core, which is not aware of input-specific inhibit (nor should it be).
+Composite devices containing several interfaces can be inhibited on a per-interface basis and
+e.g. inhibiting one interface shouldn't affect the device's capability of being a wakeup source.
+
+If a device is to be considered a wakeup source while inhibited, special care must be taken when
+programming its suspend(), as it might need to call device's open(). Depending on what close()
+means for the device in question not opening() it before going to sleep might make it impossible
+to provide any wakeup events. The device is going to sleep anyway.
+
Basic event types
~~~~~~~~~~~~~~~~~
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 0/5] 180 degrees rotation support for NVIDIA Tegra DRM
From: Dmitry Osipenko @ 2020-06-16 17:20 UTC (permalink / raw)
To: Emil Velikov
Cc: Thierry Reding, Thomas Zimmermann, Derek Basehore, Sam Ravnborg,
Laurent Pinchart, Sean Paul, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel
In-Reply-To: <CACvgo50oSMbgXw1vHwVT4hhGe6g3YzKQEohCLJdfDq+0UaN1jw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
16.06.2020 18:48, Emil Velikov пишет:
> On Tue, 16 Jun 2020 at 12:40, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> 16.06.2020 01:26, Emil Velikov пишет:
>>> Hi Dmitry,
>>>
>>> On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>
>>>> Hello!
>>>>
>>>> This series adds 180° display plane rotation support to the NVIDIA Tegra
>>>> DRM driver which is needed for devices that have display panel physically
>>>> mounted upside-down, like Nexus 7 tablet device for example [1]. Since
>>>> DRM panel rotation is a new thing for a userspace, currently only
>>>> Opentegra Xorg driver handles the rotated display panel [2], but this
>>>> is good enough for the start.
>>>>
>>>> Note that later on it should be possible to implement a transparent 180°
>>>> display rotation for Tegra DRM driver which will remove the need to have
>>>> a bleeding edge userspace that knows how to rotate display planes and I'm
>>>> slowly working on it. For the starter we can go with the minimal rotation
>>>> support, so it's not a blocker.
>>>>
>>>> This series is based on the work that was made by Derek Basehore for the
>>>> Mediatek driver [3], his patch is included into this patchset. I added
>>>> my tested-by tag to the Derek's patch.
>>>>
>>>> Please review and apply, thanks in advance!
>>>>
>>>> [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200607154327.18589-3-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org/
>>>> [2] https://github.com/grate-driver/xf86-video-opentegra/commit/28eb20a3959bbe5bc3a3b67e55977093fd5114ca
>>>> [3] https://lkml.org/lkml/2020/3/5/1119
>>>>
>>>> Changelog:
>>>>
>>>> v2: - Dropped "drm/panel: Set display info in panel attach" patch, which
>>>> turned out to be obsolete now.
>>>>
>>>> - Renamed the cover-latter, hopefully this will fix the bouncing emails.
>>>>
>>>> Derek Basehore (1):
>>>> drm/panel: Add helper for reading DT rotation
>>>>
>>>> Dmitry Osipenko (4):
>>>> drm/panel: lvds: Set up panel orientation
>>>
>>> IMHO it's perfectly reasonable to report the panel orientation to
>>> userspace, which can apply plane rotation as needed.
>>>
>>> Although I see that this series, alike Derek's, has a couple of issues:
>>> - only a single panel driver is updated
>>> - rotation is _not_ listed as supported property, in said panel
>>> driver device-tree bindings
>>>
>>> My personal inclination is that we should aim for a comprehensive solution:
>>> - wire all panel drivers, as currently documented (quick grep list below)
>>> - document and wire-up the lvds and boe panels - as proposed by you
>>> and Derek respectively
>>>
>>> HTH
>>> Emil
>>>
>>> Documentation/devicetree/bindings/display/himax,hx8357d.txt:2
>>> Documentation/devicetree/bindings/display/ilitek,ili9225.txt:2
>>> Documentation/devicetree/bindings/display/ilitek,ili9341.txt:2
>>> Documentation/devicetree/bindings/display/ilitek,ili9486.yaml:2
>>> Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt:2
>>> Documentation/devicetree/bindings/display/panel/panel-common.yaml:2
>>> Documentation/devicetree/bindings/display/sitronix,st7586.txt:1
>>> Documentation/devicetree/bindings/display/sitronix,st7735r.yaml:2
>>
>> Rotation is a common DT panel property that is described in the
>> panel-common.yaml.
> The property was introduced almost exclusively for tiny drm panels.
> Those ones are a bit different from the rest (in panel/) -
> MIPI-DBI/SPI w/o (not connected at least) an actual GPU.
>
> To make it a bit better, the rotation is seemingly performed in the
> tiny driver itself ouch.
>
>> This property is supported by all panel bindings
>> because these bindings inherent the common properties from the
>> panel-common.yaml.
>>
> Seems like that was an unintentional change with the conversion to YAML.
> Beforehand only a few selected panels had rotation. Upon closer look -
> some panels do have follow-up fixes, to remove/limit the implicit
> inclusion.
Interesting.. my understanding that the rotation property is supposed to
be a generic property which represents physical orientation of a display
panel and hence it should be applicable to all panels.
> Sam seems like you've done most of the YAML conversion. IMHO it would
> make sense to revisit the patches and inherit common properties only
> as applicable.
>
>> I don't think that it makes sense to wire up rotation property to all
>> panel drivers at once because those drivers will be untested, at least I
>> don't know anything about those other panels and can't test them. It
>> will be much better to support the rotation on by as-needed basis for
>> each panel driver individually.
>
> How about CCing the author and reviewer asking them to test the patch?
> The only place where the patches might cause an issue is with tiny,
> although patches would still be appreciated.
There are quite a lot of panel drivers and I'm a bit doubtful that at
least half of devices that use those panels have any real use for the
rotation property. I could write the patches.. but in the end it could
be a wasted effort if nobody needs it, so I'd prefer not to do it.
^ permalink raw reply
* Re: [PATCH v2] drm/tegra: Add zpos property for cursor planes
From: Dmitry Osipenko @ 2020-06-16 16:38 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, Ville Syrjälä, Daniel Stone,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200616161341.GA3009091@ulmo>
16.06.2020 19:13, Thierry Reding пишет:
> On Tue, Jun 16, 2020 at 06:54:35PM +0300, Dmitry Osipenko wrote:
>> 16.06.2020 15:17, Thierry Reding пишет:
>>> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>
>>> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
>>> have a zpos property") a warning is emitted if there's a mix of planes
>>> with and without a zpos property.
>>>
>>> On Tegra, cursor planes are always composited on top of all other
>>> planes, which is why they never had a zpos property attached to them.
>>> However, since the composition order is fixed, this is trivial to
>>> remedy by simply attaching an immutable zpos property to them.
>>>
>>> Changes in v2:
>>> - hardcode cursor plane zpos to 255 instead of 0 (Ville)
>>>
>>> Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> ---
>>> drivers/gpu/drm/tegra/dc.c | 9 +++++++--
>>> drivers/gpu/drm/tegra/hub.c | 2 +-
>>> 2 files changed, 8 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>> index 83f31c6e891c..85408eed4685 100644
>>> --- a/drivers/gpu/drm/tegra/dc.c
>>> +++ b/drivers/gpu/drm/tegra/dc.c
>>> @@ -787,7 +787,7 @@ static struct drm_plane *tegra_primary_plane_create(struct drm_device *drm,
>>> }
>>>
>>> drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
>>> - drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
>>> + drm_plane_create_zpos_property(&plane->base, plane->index, 0, 254);
>>>
>>> err = drm_plane_create_rotation_property(&plane->base,
>>> DRM_MODE_ROTATE_0,
>>> @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
>>> }
>>>
>>> drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
>>> + drm_plane_create_zpos_immutable_property(&plane->base, 255);
>>>
>>> return &plane->base;
>>> }
>>> @@ -1074,7 +1075,11 @@ static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm,
>>> }
>>>
>>> drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
>>> - drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
>>> +
>>> + if (!cursor)
>>> + drm_plane_create_zpos_property(&plane->base, plane->index, 0, 254);
>>> + else
>>> + drm_plane_create_zpos_immutable_property(&plane->base, 255);
>>
>> On T20/30 we're are setting the plane's type to CURSOR because we want
>> to use one overlay plane for the mouse cursor. Nevertheless, it's still
>> a generic overlay plane that can change its z-position, and thus, it's
>> wrong to make zpos immutable here.
>
> But it doesn't really make sense for the cursor plane to change z-
> position, even if it's technically possible. We do want it to always be
> on top anyway. Doing it this way makes the cursor behave the same way
> irrespective of the Tegra generation that we're running on.
>
> Yes, that may not fully expose the capabilities of the hardware, but we
> are already restricting the hardware capabilities by exposing the
> overlay plane as a cursor plane in the first place.
Userspace is free to reuse cursor's plane for different purposes. For
example, cursor may be not needed at all and then cursor plane could be
used as a regular overlay plane.
The patch's title and commit's description says "*Add* zpos property for
cursor planes", but in this case zpos property already existed before
this patch, hence you're changing the old behavior here.
^ permalink raw reply
* Re: [PATCH v2] drm/tegra: Add zpos property for cursor planes
From: Thierry Reding @ 2020-06-16 16:13 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Jon Hunter, Ville Syrjälä, Daniel Stone,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <c34c97ab-08de-341e-05e5-77e2651d956f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]
On Tue, Jun 16, 2020 at 06:54:35PM +0300, Dmitry Osipenko wrote:
> 16.06.2020 15:17, Thierry Reding пишет:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> > have a zpos property") a warning is emitted if there's a mix of planes
> > with and without a zpos property.
> >
> > On Tegra, cursor planes are always composited on top of all other
> > planes, which is why they never had a zpos property attached to them.
> > However, since the composition order is fixed, this is trivial to
> > remedy by simply attaching an immutable zpos property to them.
> >
> > Changes in v2:
> > - hardcode cursor plane zpos to 255 instead of 0 (Ville)
> >
> > Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > drivers/gpu/drm/tegra/dc.c | 9 +++++++--
> > drivers/gpu/drm/tegra/hub.c | 2 +-
> > 2 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 83f31c6e891c..85408eed4685 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -787,7 +787,7 @@ static struct drm_plane *tegra_primary_plane_create(struct drm_device *drm,
> > }
> >
> > drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
> > - drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
> > + drm_plane_create_zpos_property(&plane->base, plane->index, 0, 254);
> >
> > err = drm_plane_create_rotation_property(&plane->base,
> > DRM_MODE_ROTATE_0,
> > @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
> > }
> >
> > drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
> > + drm_plane_create_zpos_immutable_property(&plane->base, 255);
> >
> > return &plane->base;
> > }
> > @@ -1074,7 +1075,11 @@ static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm,
> > }
> >
> > drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
> > - drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
> > +
> > + if (!cursor)
> > + drm_plane_create_zpos_property(&plane->base, plane->index, 0, 254);
> > + else
> > + drm_plane_create_zpos_immutable_property(&plane->base, 255);
>
> On T20/30 we're are setting the plane's type to CURSOR because we want
> to use one overlay plane for the mouse cursor. Nevertheless, it's still
> a generic overlay plane that can change its z-position, and thus, it's
> wrong to make zpos immutable here.
But it doesn't really make sense for the cursor plane to change z-
position, even if it's technically possible. We do want it to always be
on top anyway. Doing it this way makes the cursor behave the same way
irrespective of the Tegra generation that we're running on.
Yes, that may not fully expose the capabilities of the hardware, but we
are already restricting the hardware capabilities by exposing the
overlay plane as a cursor plane in the first place.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] drm/tegra: Add zpos property for cursor planes
From: Dmitry Osipenko @ 2020-06-16 15:54 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, Ville Syrjälä, Daniel Stone,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200616121713.2983627-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
16.06.2020 15:17, Thierry Reding пишет:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> As of commit 4dc55525b095 ("drm: plane: Verify that no or all planes
> have a zpos property") a warning is emitted if there's a mix of planes
> with and without a zpos property.
>
> On Tegra, cursor planes are always composited on top of all other
> planes, which is why they never had a zpos property attached to them.
> However, since the composition order is fixed, this is trivial to
> remedy by simply attaching an immutable zpos property to them.
>
> Changes in v2:
> - hardcode cursor plane zpos to 255 instead of 0 (Ville)
>
> Reported-by: Jonathan Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/gpu/drm/tegra/dc.c | 9 +++++++--
> drivers/gpu/drm/tegra/hub.c | 2 +-
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 83f31c6e891c..85408eed4685 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -787,7 +787,7 @@ static struct drm_plane *tegra_primary_plane_create(struct drm_device *drm,
> }
>
> drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
> - drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
> + drm_plane_create_zpos_property(&plane->base, plane->index, 0, 254);
>
> err = drm_plane_create_rotation_property(&plane->base,
> DRM_MODE_ROTATE_0,
> @@ -957,6 +957,7 @@ static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm,
> }
>
> drm_plane_helper_add(&plane->base, &tegra_cursor_plane_helper_funcs);
> + drm_plane_create_zpos_immutable_property(&plane->base, 255);
>
> return &plane->base;
> }
> @@ -1074,7 +1075,11 @@ static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm,
> }
>
> drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
> - drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
> +
> + if (!cursor)
> + drm_plane_create_zpos_property(&plane->base, plane->index, 0, 254);
> + else
> + drm_plane_create_zpos_immutable_property(&plane->base, 255);
On T20/30 we're are setting the plane's type to CURSOR because we want
to use one overlay plane for the mouse cursor. Nevertheless, it's still
a generic overlay plane that can change its z-position, and thus, it's
wrong to make zpos immutable here.
^ permalink raw reply
* Re: [PATCH v2 0/5] 180 degrees rotation support for NVIDIA Tegra DRM
From: Emil Velikov @ 2020-06-16 15:48 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Thierry Reding, Thomas Zimmermann, Derek Basehore, Sam Ravnborg,
Laurent Pinchart, Sean Paul, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
Linux-Kernel@Vger. Kernel. Org, ML dri-devel
In-Reply-To: <8f789ef5-bebf-c869-784d-afda70fc1fb8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, 16 Jun 2020 at 12:40, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> 16.06.2020 01:26, Emil Velikov пишет:
> > Hi Dmitry,
> >
> > On Mon, 15 Jun 2020 at 08:28, Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>
> >> Hello!
> >>
> >> This series adds 180° display plane rotation support to the NVIDIA Tegra
> >> DRM driver which is needed for devices that have display panel physically
> >> mounted upside-down, like Nexus 7 tablet device for example [1]. Since
> >> DRM panel rotation is a new thing for a userspace, currently only
> >> Opentegra Xorg driver handles the rotated display panel [2], but this
> >> is good enough for the start.
> >>
> >> Note that later on it should be possible to implement a transparent 180°
> >> display rotation for Tegra DRM driver which will remove the need to have
> >> a bleeding edge userspace that knows how to rotate display planes and I'm
> >> slowly working on it. For the starter we can go with the minimal rotation
> >> support, so it's not a blocker.
> >>
> >> This series is based on the work that was made by Derek Basehore for the
> >> Mediatek driver [3], his patch is included into this patchset. I added
> >> my tested-by tag to the Derek's patch.
> >>
> >> Please review and apply, thanks in advance!
> >>
> >> [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200607154327.18589-3-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org/
> >> [2] https://github.com/grate-driver/xf86-video-opentegra/commit/28eb20a3959bbe5bc3a3b67e55977093fd5114ca
> >> [3] https://lkml.org/lkml/2020/3/5/1119
> >>
> >> Changelog:
> >>
> >> v2: - Dropped "drm/panel: Set display info in panel attach" patch, which
> >> turned out to be obsolete now.
> >>
> >> - Renamed the cover-latter, hopefully this will fix the bouncing emails.
> >>
> >> Derek Basehore (1):
> >> drm/panel: Add helper for reading DT rotation
> >>
> >> Dmitry Osipenko (4):
> >> drm/panel: lvds: Set up panel orientation
> >
> > IMHO it's perfectly reasonable to report the panel orientation to
> > userspace, which can apply plane rotation as needed.
> >
> > Although I see that this series, alike Derek's, has a couple of issues:
> > - only a single panel driver is updated
> > - rotation is _not_ listed as supported property, in said panel
> > driver device-tree bindings
> >
> > My personal inclination is that we should aim for a comprehensive solution:
> > - wire all panel drivers, as currently documented (quick grep list below)
> > - document and wire-up the lvds and boe panels - as proposed by you
> > and Derek respectively
> >
> > HTH
> > Emil
> >
> > Documentation/devicetree/bindings/display/himax,hx8357d.txt:2
> > Documentation/devicetree/bindings/display/ilitek,ili9225.txt:2
> > Documentation/devicetree/bindings/display/ilitek,ili9341.txt:2
> > Documentation/devicetree/bindings/display/ilitek,ili9486.yaml:2
> > Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt:2
> > Documentation/devicetree/bindings/display/panel/panel-common.yaml:2
> > Documentation/devicetree/bindings/display/sitronix,st7586.txt:1
> > Documentation/devicetree/bindings/display/sitronix,st7735r.yaml:2
>
> Rotation is a common DT panel property that is described in the
> panel-common.yaml.
The property was introduced almost exclusively for tiny drm panels.
Those ones are a bit different from the rest (in panel/) -
MIPI-DBI/SPI w/o (not connected at least) an actual GPU.
To make it a bit better, the rotation is seemingly performed in the
tiny driver itself ouch.
> This property is supported by all panel bindings
> because these bindings inherent the common properties from the
> panel-common.yaml.
>
Seems like that was an unintentional change with the conversion to YAML.
Beforehand only a few selected panels had rotation. Upon closer look -
some panels do have follow-up fixes, to remove/limit the implicit
inclusion.
Sam seems like you've done most of the YAML conversion. IMHO it would
make sense to revisit the patches and inherit common properties only
as applicable.
> I don't think that it makes sense to wire up rotation property to all
> panel drivers at once because those drivers will be untested, at least I
> don't know anything about those other panels and can't test them. It
> will be much better to support the rotation on by as-needed basis for
> each panel driver individually.
How about CCing the author and reviewer asking them to test the patch?
The only place where the patches might cause an issue is with tiny,
although patches would still be appreciated.
-Emil
^ permalink raw reply
* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
From: Thierry Reding @ 2020-06-16 14:51 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b20cede8-a9ee-c70d-913d-d0a05d7826b0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]
On Fri, Jun 12, 2020 at 06:54:45PM +0300, Dmitry Osipenko wrote:
> 12.06.2020 17:18, Thierry Reding пишет:
> > 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>
> > ---
> ...
> > + 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
>
> This memory-controllers property didn't exist before the conversion. So
> this is not a pure conversion, which makes it a bit difficult to review
> the changes. Could you please factor out the addition of new properties
> into a separate patch?
The memory-controllers property was from an earlier draft of this series
and is no longer needed. I'll remove it.
In my opinion, these schema conversion patches are difficult to review
in general, especially the likes of this one for host1x because they are
fairly complex to begin with. All existing Tegra-based device trees do
pass validation (although there's a small patch needed to support the
unevaluatedProperties keyword that's new in json-schema draft-08), which
gives me some confidence that they are at least correct from a content
point of view.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 08/38] dt-bindings: display: tegra: Document interconnect paths
From: Thierry Reding @ 2020-06-16 14:47 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <82888e53-c539-7d61-666d-bd6dbc494bfe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4836 bytes --]
On Fri, Jun 12, 2020 at 06:52:44PM +0300, Dmitry Osipenko wrote:
> Hello Thierry,
>
> 12.06.2020 17:18, Thierry Reding пишет:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Commit description is missing, checkpatch should warn about it.
>
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../display/tegra/nvidia,tegra20-host1x.yaml | 52 ++++++++++++++++---
> > 1 file changed, 46 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > index 3347e1b3c8f0..684fe25641f1 100644
> > --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > @@ -97,8 +97,17 @@ properties:
> > iommus:
> > $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> >
> > - memory-controllers:
> > - $ref: /schemas/types.yaml#/definitions/phandle-array
>
> Why memory-controllers property is removed?
Because it was accidentally added in patch 7. This is leftover from an
earlier set of patches.
> > + interconnects:
> > + description: Description of the interconnect paths for the host1x
> > + controller; see ../interconnect/interconnect.txt for details.
> > + items:
> > + - description: memory read client for host1x
> > +
> > + interconnect-names:
> > + description: A list of names identifying each entry listed in the
> > + "interconnects" property.
> > + items:
> > + - const: dma-mem # read
>
> Please notice that Host1x has two memory clients: one for DMA engine and
> second I don't know what's for, maybe for indirect memory accesses. Why
> you skipped the second path?
I'm primarily targetting Tegra186 and Tegra194 with these patches
because we need the interconnects properties on those platforms in order
to correctly set the DMA masks at a global scope. For Tegra186 and
Tegra194 I can only see a single memory client for host1x.
Looking at the register documentation, the host1xw and host1xr clients
do exist on Tegra210 and earlier and they are used for indirect writes
and reads, respectively.
I don't think we use indirect reads/writes, so we can probably do
without the corresponding memory clients. Alternatively we could
conditionally add them on Tegra210 and earlier.
Thierry
> > required:
> > - compatible
> > @@ -489,6 +498,26 @@ allOf:
> > iommus:
> > $ref: "/schemas/types.yaml#/definitions/phandle-array"
> >
> > + #interconnects:
> > + # items:
> > + # - description: memory read client for window A
> > + # - description: memory read client for window B
> > + # - description: memory read client for window C
> > + # - description: memory read client for cursor
> > + # # disp only
> > + # - description: memory read client for window T
> > + # - description: memory read client for window D
> > +
> > + #interconnect-names:
> > + # items:
> > + # - const: wina
> > + # - const: winb
> > + # - const: winc
> > + # - const: cursor
> > + # # disp only
> > + # - const: wint
> > + # - const: wind
>
> Is this really intended to be commented out? Looks like this is an
> unfinished patch.
I started adding this after finishing Tegra186 and Tegra194, but then I
ran into various other issues and wanted to do this step by step, so I
plan to go back to Tegra210 and earlier later on and stub them out.
However, since I had already done the research I wanted to leave these
in here for later reference, so I didn't have to go back and look this
up again.
> In the patch [1] I used memory client names for the interconnect paths.
> I like yours variant of the naming, it is more intuitive.
I only noticed after posting this series that you had sent out the
series for interconnects and that it conflicted in the bindings.
But yeah, I do also like the contextual names better because they are
more intuitive.
> [1]
> https://patchwork.ozlabs.org/project/linux-tegra/patch/20200609131404.17523-23-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org/
>
> I'll rebase my series on top of yours patches once you'll get them into
> linux-next. Looking forward to v2!
There's quite a bit to review here, but I also have a couple of patches
that depend on these, so yeah, it'd be great if this could go in sooner
rather than later.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v7 2/6] drm/of: Make drm_of_find_panel_or_bridge() to check graph's presence
From: Dmitry Osipenko @ 2020-06-16 14:42 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Thierry Reding, Sam Ravnborg, Rob Herring, Frank Rowand,
dri-devel, linux-tegra, devicetree, linux-kernel
In-Reply-To: <20200616012652.GG1629@pendragon.ideasonboard.com>
16.06.2020 04:26, Laurent Pinchart пишет:
> Hi Dmitry,
>
> Thank you for the patch.
>
> On Sun, Jun 14, 2020 at 08:22:30PM +0300, Dmitry Osipenko wrote:
>> When graph isn't defined in a device-tree, the of_graph_get_remote_node()
>> prints a noisy error message, telling that port node is not found. This is
>> undesirable behaviour in our case because absence of a panel/bridge graph
>> is a valid case. Let's check presence of the local port in a device-tree
>> before proceeding with parsing the graph.
>>
>> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>> drivers/gpu/drm/drm_of.c | 13 ++++++++++++-
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
>> index b50b44e76279..e0652c38f357 100644
>> --- a/drivers/gpu/drm/drm_of.c
>> +++ b/drivers/gpu/drm/drm_of.c
>> @@ -239,13 +239,24 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
>> struct drm_bridge **bridge)
>> {
>> int ret = -EPROBE_DEFER;
>> - struct device_node *remote;
>> + struct device_node *local, *remote;
>>
>> if (!panel && !bridge)
>> return -EINVAL;
>> if (panel)
>> *panel = NULL;
>>
>> + /*
>> + * of_graph_get_remote_node() produces a noisy error message if port
>> + * node isn't found and the absence of the port is a legit case here,
>> + * so at first we silently check presence of the local port.
>> + */
>> + local = of_graph_get_local_port(np);
>> + if (!local)
>> + return -ENODEV;
>> +
>> + of_node_put(local);
>> +
>
> The code looks fine, but you may want to take into account my proposal
> in 1/7 to instead create a of_graph_has_port() function. The could would
> be simpler here.
>
>> remote = of_graph_get_remote_node(np, port, endpoint);
>> if (!remote)
>> return -ENODEV;
>
I like yours proposals and will prepare v8 based on them, thanks!
^ permalink raw reply
* Re: [PATCH 30/38] dt-bindings: panel: Allow reg property for DSI panels
From: Thierry Reding @ 2020-06-16 14:35 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-tegra
In-Reply-To: <CAL_JsqL4wMN3+cd=WEUegGU9xwpj9DTXeKT6EwTRfqiS+y6fMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
On Fri, Jun 12, 2020 at 08:29:35AM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 8:20 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > For DSI panels the "reg" property is needed to represent the virtual
> > channel of the given panel.
> >
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../devicetree/bindings/display/panel/panel-simple.yaml | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > index d6cca1479633..34fe3d42b829 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > @@ -267,6 +267,9 @@ properties:
> > # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
> > - winstar,wf35ltiacd
> >
> > + reg:
> > + description: virtual channel for DSI panels
> > +
>
> panel-simple-dsi.yaml?
Heh... I had completely missed that. I've now replaced this patch with
one that moves the lg,lh500wx1-sd03 compatible string to the DSI schema.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 31/38] dt-bindings: panel: simple: Use unevaluatedProperties
From: Thierry Reding @ 2020-06-16 14:33 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-tegra
In-Reply-To: <CAL_JsqKHkW8Q-prwEP_tkyWHUU5YuQHOipzjZ9MWa9M+uMoCkg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]
On Fri, Jun 12, 2020 at 08:28:13AM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 8:20 AM Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > Using "additionalProperties: false" results in rejecting any of the
> > properties defined in panel-common.yaml, whereas the intent is to
> > inherit the common properties defined in that file.
> >
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > index 34fe3d42b829..c58bc90ffd43 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > @@ -275,7 +275,7 @@ properties:
> > port: true
> > power-supply: true
> >
> > -additionalProperties: false
> > +unevaluatedProperties: false
>
> But we've listed the properties we use here. Some of the common ones
> may not be applicable. Maybe they are and if so, then you should drop
> all the ones listed with 'true' with this change.
Looks like the only one I need this for is ddc-i2c-bus, which is already
contained in panel-common.yaml. unevaluatedProperties: false is able to
look into that and hence doesn't flag this as extra.
However, I can also work around that by adding a "ddc-i2c-bus: true" to
panel-simple.yaml, which seems like it's the currently preferred way to
do this. Is it expected that once jsonschema/dt-schema support the
unevaluatedProperties keyword that we'd move towards using that instead?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/6] of_graph: add of_graph_get_local_port()
From: Dmitry Osipenko @ 2020-06-16 14:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Thierry Reding, Sam Ravnborg, Rob Herring, Frank Rowand,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8b7c6395-edd8-cecd-7004-e9f3f22d61f2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
16.06.2020 16:56, Dmitry Osipenko пишет:
> 16.06.2020 04:25, Laurent Pinchart пишет:
>> On Tue, Jun 16, 2020 at 04:21:12AM +0300, Laurent Pinchart wrote:
>>> Hi Dmitry,
>>>
>>> Thank you for the patch.
>>>
>>> On Sun, Jun 14, 2020 at 08:22:29PM +0300, Dmitry Osipenko wrote:
>>>> In some case, like a DRM display code for example, it's useful to silently
>>>> check whether port node exists at all in a device-tree before proceeding
>>>> with parsing the graph.
>>>>
>>>> This patch adds of_graph_get_local_port() which returns pointer to a local
>>>> port node, or NULL if graph isn't specified in a device-tree for a given
>>>> device node.
>>>>
>>>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>> Reviewed-by: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
>>>> Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>> drivers/of/property.c | 32 +++++++++++++++++++++++---------
>>>> include/linux/of_graph.h | 7 +++++++
>>>> 2 files changed, 30 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/drivers/of/property.c b/drivers/of/property.c
>>>> index 1f2086f4e7ce..05c5f619b8bb 100644
>>>> --- a/drivers/of/property.c
>>>> +++ b/drivers/of/property.c
>>>> @@ -608,15 +608,7 @@ struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
>>>> * parent port node.
>>>> */
>>>> if (!prev) {
>>>> - struct device_node *node;
>>>> -
>>>> - node = of_get_child_by_name(parent, "ports");
>>>> - if (node)
>>>> - parent = node;
>>>> -
>>>> - port = of_get_child_by_name(parent, "port");
>>>> - of_node_put(node);
>>>> -
>>>> + port = of_graph_get_local_port(parent);
>>>> if (!port) {
>>>> pr_err("graph: no port node found in %pOF\n", parent);
>>>> return NULL;
>>>> @@ -765,6 +757,28 @@ struct device_node *of_graph_get_remote_port(const struct device_node *node)
>>>> }
>>>> EXPORT_SYMBOL(of_graph_get_remote_port);
>>>>
>>>> +/**
>>>> + * of_graph_get_local_port() - get local port node
>>>> + * @node: pointer to a local endpoint device_node
>>>> + *
>>>> + * Return: First local port node associated with local endpoint node linked
>>>> + * to @node. Use of_node_put() on it when done.
>>>> + */
>>>> +struct device_node *of_graph_get_local_port(const struct device_node *node)
>>
>> I forgot to mention that, given that there could be multiple 'port'
>> nodes, this function would be better named
>> of_graph_get_first_local_port(). 'first' here would refer to the nodes
>> order in the device tree, which I believe may not match the port number.
>> For instance, in the following case
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> port@1 {
>> reg = <1>;
>> };
>> port@0 {
>> reg = <0>;
>> };
>> };
>>
>> the function would I believe return port@1. It may be a good idea to
>> explain this in the documentation.
>
> Hello Laurent,
>
> It's correct that the port@1 will be returned in yours example.
>
> I'll improve the doc and the function's name in the next revision, thank
> you for the suggestions!
>
>> Depending on how you use this
>> function, if your only use case is to test for the presence of port
>> nodes, it may be best to return a bool and name it of_graph_has_port()
>> or something similar.
>>
>>>> +{
>>>> + struct device_node *ports, *port;
>>>> +
>>>> + ports = of_get_child_by_name(node, "ports");
>>>> + if (ports)
>>>> + node = ports;
>>>> +
>>>> + port = of_get_child_by_name(node, "port");
>>>> + of_node_put(ports);
>>>> +
>>>> + return port;
>>>
>>> The implementation doesn't seem to match the documentation. If node is a
>>> pointer to an endpoint, it should not have any ports child.
>
> Right, I'll reword the doc in v8. This function doesn't differentiate
> between start / end points. It's up to a user of this function to check
> whether node is endpoint or something else if needed.
>
> Thank you very much for the comments!
>
Although, I re-read the doc comment and compared it to the wording of
the other of_graph_*() functions and it's already good as-is to me
because the doc explicitly says the "Return: First local port associated
with local endpoint...", which is exactly what this function does.
But still the function name and it's brief description could be improved.
^ permalink raw reply
* Re: [PATCH v7 1/6] of_graph: add of_graph_get_local_port()
From: Dmitry Osipenko @ 2020-06-16 13:56 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Thierry Reding, Sam Ravnborg, Rob Herring, Frank Rowand,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200616012513.GF1629-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
16.06.2020 04:25, Laurent Pinchart пишет:
> On Tue, Jun 16, 2020 at 04:21:12AM +0300, Laurent Pinchart wrote:
>> Hi Dmitry,
>>
>> Thank you for the patch.
>>
>> On Sun, Jun 14, 2020 at 08:22:29PM +0300, Dmitry Osipenko wrote:
>>> In some case, like a DRM display code for example, it's useful to silently
>>> check whether port node exists at all in a device-tree before proceeding
>>> with parsing the graph.
>>>
>>> This patch adds of_graph_get_local_port() which returns pointer to a local
>>> port node, or NULL if graph isn't specified in a device-tree for a given
>>> device node.
>>>
>>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Reviewed-by: Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>
>>> Signed-off-by: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>> drivers/of/property.c | 32 +++++++++++++++++++++++---------
>>> include/linux/of_graph.h | 7 +++++++
>>> 2 files changed, 30 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/of/property.c b/drivers/of/property.c
>>> index 1f2086f4e7ce..05c5f619b8bb 100644
>>> --- a/drivers/of/property.c
>>> +++ b/drivers/of/property.c
>>> @@ -608,15 +608,7 @@ struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
>>> * parent port node.
>>> */
>>> if (!prev) {
>>> - struct device_node *node;
>>> -
>>> - node = of_get_child_by_name(parent, "ports");
>>> - if (node)
>>> - parent = node;
>>> -
>>> - port = of_get_child_by_name(parent, "port");
>>> - of_node_put(node);
>>> -
>>> + port = of_graph_get_local_port(parent);
>>> if (!port) {
>>> pr_err("graph: no port node found in %pOF\n", parent);
>>> return NULL;
>>> @@ -765,6 +757,28 @@ struct device_node *of_graph_get_remote_port(const struct device_node *node)
>>> }
>>> EXPORT_SYMBOL(of_graph_get_remote_port);
>>>
>>> +/**
>>> + * of_graph_get_local_port() - get local port node
>>> + * @node: pointer to a local endpoint device_node
>>> + *
>>> + * Return: First local port node associated with local endpoint node linked
>>> + * to @node. Use of_node_put() on it when done.
>>> + */
>>> +struct device_node *of_graph_get_local_port(const struct device_node *node)
>
> I forgot to mention that, given that there could be multiple 'port'
> nodes, this function would be better named
> of_graph_get_first_local_port(). 'first' here would refer to the nodes
> order in the device tree, which I believe may not match the port number.
> For instance, in the following case
>
> ports {
> #address-cells = <1>;
> #size-cells = <1>;
> port@1 {
> reg = <1>;
> };
> port@0 {
> reg = <0>;
> };
> };
>
> the function would I believe return port@1. It may be a good idea to
> explain this in the documentation.
Hello Laurent,
It's correct that the port@1 will be returned in yours example.
I'll improve the doc and the function's name in the next revision, thank
you for the suggestions!
> Depending on how you use this
> function, if your only use case is to test for the presence of port
> nodes, it may be best to return a bool and name it of_graph_has_port()
> or something similar.
>
>>> +{
>>> + struct device_node *ports, *port;
>>> +
>>> + ports = of_get_child_by_name(node, "ports");
>>> + if (ports)
>>> + node = ports;
>>> +
>>> + port = of_get_child_by_name(node, "port");
>>> + of_node_put(ports);
>>> +
>>> + return port;
>>
>> The implementation doesn't seem to match the documentation. If node is a
>> pointer to an endpoint, it should not have any ports child.
Right, I'll reword the doc in v8. This function doesn't differentiate
between start / end points. It's up to a user of this function to check
whether node is endpoint or something else if needed.
Thank you very much for the comments!
^ permalink raw reply
* [PATCH 73/73] arm64: tegra: Fix order of XUSB controller clocks
From: Thierry Reding @ 2020-06-16 13:52 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20200616135238.3001888-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
This is purely to make the json-schema validation tools happy because
they cannot deal with string arrays that may be in arbitrary order.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index c265211f8a84..b9c6ba707ef9 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -997,8 +997,8 @@ usb@70090000 {
<&tegra_car TEGRA210_CLK_XUSB_HOST_SRC>,
<&tegra_car TEGRA210_CLK_XUSB_FALCON_SRC>,
<&tegra_car TEGRA210_CLK_XUSB_SS>,
- <&tegra_car TEGRA210_CLK_XUSB_SS_DIV2>,
<&tegra_car TEGRA210_CLK_XUSB_SS_SRC>,
+ <&tegra_car TEGRA210_CLK_XUSB_SS_DIV2>,
<&tegra_car TEGRA210_CLK_XUSB_HS_SRC>,
<&tegra_car TEGRA210_CLK_XUSB_FS_SRC>,
<&tegra_car TEGRA210_CLK_PLL_U_480M>,
@@ -1006,7 +1006,7 @@ usb@70090000 {
<&tegra_car TEGRA210_CLK_PLL_E>;
clock-names = "xusb_host", "xusb_host_src",
"xusb_falcon_src", "xusb_ss",
- "xusb_ss_div2", "xusb_ss_src",
+ "xusb_ss_src", "xusb_ss_div2",
"xusb_hs_src", "xusb_fs_src",
"pll_u_480m", "clk_m", "pll_e";
resets = <&tegra_car 89>, <&tegra_car 156>,
--
2.24.1
^ permalink raw reply related
* [PATCH 72/73] arm64: tegra: Rename cbb@0 to bus@0 on Tegra194
From: Thierry Reding @ 2020-06-16 13:52 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20200616135238.3001888-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
The control backbone is a simple-bus and hence its device tree node
should be named "bus@<unit-address>" according to the bindings.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
.../arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 22 +++++++++----------
.../boot/dts/nvidia/tegra194-p2972-0000.dts | 10 ++++-----
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
index 6f2c0754c870..cefbd0000357 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -8,18 +8,18 @@ / {
compatible = "nvidia,p2888", "nvidia,tegra194";
aliases {
- ethernet0 = "/cbb@0/ethernet@2490000";
- mmc0 = "/cbb@0/mmc@3460000";
- mmc1 = "/cbb@0/mmc@3400000";
+ ethernet0 = "/bus@0/ethernet@2490000";
+ mmc0 = "/bus@0/mmc@3460000";
+ mmc1 = "/bus@0/mmc@3400000";
serial0 = &tcu;
i2c0 = "/bpmp/i2c";
- i2c1 = "/cbb@0/i2c@3160000";
- i2c2 = "/cbb@0/i2c@c240000";
- i2c3 = "/cbb@0/i2c@3180000";
- i2c4 = "/cbb@0/i2c@3190000";
- i2c5 = "/cbb@0/i2c@31c0000";
- i2c6 = "/cbb@0/i2c@c250000";
- i2c7 = "/cbb@0/i2c@31e0000";
+ i2c1 = "/bus@0/i2c@3160000";
+ i2c2 = "/bus@0/i2c@c240000";
+ i2c3 = "/bus@0/i2c@3180000";
+ i2c4 = "/bus@0/i2c@3190000";
+ i2c5 = "/bus@0/i2c@31c0000";
+ i2c6 = "/bus@0/i2c@c250000";
+ i2c7 = "/bus@0/i2c@31e0000";
};
chosen {
@@ -27,7 +27,7 @@ chosen {
stdout-path = "serial0:115200n8";
};
- cbb@0 {
+ bus@0 {
ethernet@2490000 {
status = "okay";
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
index 0f9868b6fd6b..90b6ea5467fa 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts
@@ -10,7 +10,7 @@ / {
model = "NVIDIA Jetson AGX Xavier Developer Kit";
compatible = "nvidia,p2972-0000", "nvidia,tegra194";
- cbb@0 {
+ bus@0 {
aconnect@2900000 {
status = "okay";
@@ -93,10 +93,10 @@ usb3-3 {
usb@3610000 {
status = "okay";
- phys = <&{/cbb@0/padctl@3520000/pads/usb2/lanes/usb2-1}>,
- <&{/cbb@0/padctl@3520000/pads/usb2/lanes/usb2-3}>,
- <&{/cbb@0/padctl@3520000/pads/usb3/lanes/usb3-0}>,
- <&{/cbb@0/padctl@3520000/pads/usb3/lanes/usb3-3}>;
+ phys = <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-1}>,
+ <&{/bus@0/padctl@3520000/pads/usb2/lanes/usb2-3}>,
+ <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-0}>,
+ <&{/bus@0/padctl@3520000/pads/usb3/lanes/usb3-3}>;
phy-names = "usb2-1", "usb2-3", "usb3-0", "usb3-3";
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 307f999edbf9..ea629dae6880 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -16,7 +16,7 @@ / {
#size-cells = <2>;
/* control backbone */
- cbb@0 {
+ bus@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.24.1
^ permalink raw reply related
* [PATCH 71/73] arm64: tegra: Sort nodes by unit-address on Jetson Nano
From: Thierry Reding @ 2020-06-16 13:52 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20200616135238.3001888-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Move the usb@700d0000 node to the correct place in the device tree,
ordered by unit-address.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
.../boot/dts/nvidia/tegra210-p3450-0000.dts | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
index beec6aab2157..4eb51e5eef3a 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
@@ -545,14 +545,6 @@ mmc@700b0000 {
vmmc-supply = <&vdd_3v3_sd>;
};
- usb@700d0000 {
- status = "okay";
- phys = <µ_b>;
- phy-names = "usb2-0";
- avddio-usb-supply = <&vdd_3v3_sys>;
- hvdd-usb-supply = <&vdd_1v8>;
- };
-
mmc@700b0400 {
status = "okay";
bus-width = <4>;
@@ -566,6 +558,14 @@ mmc@700b0400 {
wakeup-source;
};
+ usb@700d0000 {
+ status = "okay";
+ phys = <µ_b>;
+ phy-names = "usb2-0";
+ avddio-usb-supply = <&vdd_3v3_sys>;
+ hvdd-usb-supply = <&vdd_1v8>;
+ };
+
clk32k_in: clock@0 {
compatible = "fixed-clock";
clock-frequency = <32768>;
--
2.24.1
^ permalink raw reply related
* [PATCH 70/73] arm64: tegra: Various fixes for PMICs
From: Thierry Reding @ 2020-06-16 13:52 UTC (permalink / raw)
To: Thierry Reding
Cc: Jon Hunter, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20200616135238.3001888-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Standardize on "pmic" as the node name for the PMIC on Tegra210 systems
and use consistent names for pinmux and GPIO hog nodes.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
.../arm64/boot/dts/nvidia/tegra210-p2894.dtsi | 31 +++++++++----------
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 14 ++++-----
2 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi b/arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi
index 1acb9bb6c7df..41beab626d95 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2894.dtsi
@@ -1328,7 +1328,7 @@ i2c@7000d000 {
status = "okay";
clock-frequency = <400000>;
- max77620: max77620@3c {
+ pmic: pmic@3c {
compatible = "maxim,max77620";
reg = <0x3c>;
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
@@ -1343,12 +1343,12 @@ max77620: max77620@3c {
pinctrl-0 = <&max77620_default>;
max77620_default: pinmux@0 {
- pin_gpio0 {
+ gpio0 {
pins = "gpio0";
function = "gpio";
};
- pin_gpio1 {
+ gpio1 {
pins = "gpio1";
function = "fps-out";
drive-push-pull = <1>;
@@ -1357,34 +1357,33 @@ pin_gpio1 {
maxim,active-fps-power-down-slot = <0>;
};
- pin_gpio2_3 {
- pins = "gpio2", "gpio3";
+ gpio2 {
+ pins = "gpio2";
function = "fps-out";
drive-open-drain = <1>;
maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
};
- pin_gpio4 {
+ gpio3 {
+ pins = "gpio3";
+ function = "fps-out";
+ drive-open-drain = <1>;
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ gpio4 {
pins = "gpio4";
function = "32k-out1";
};
- pin_gpio5_6_7 {
+ gpio5_6_7 {
pins = "gpio5", "gpio6", "gpio7";
function = "gpio";
drive-push-pull = <1>;
};
-
- pin_gpio2 {
- maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
- };
-
- pin_gpio3 {
- maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
- };
};
- spmic-default-output-high {
+ gpio@0 {
gpio-hog;
output-high;
gpios = <2 GPIO_ACTIVE_HIGH>,
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
index f7840e5e069a..a946c5c31102 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
@@ -1354,11 +1354,11 @@ max77621_cpu: max77621@1b {
maxim,enable-active-discharge;
maxim,enable-bias-control;
maxim,enable-etr;
- maxim,enable-gpio = <&max77620 5 0>;
+ maxim,enable-gpio = <&pmic 5 0>;
maxim,externally-enable;
};
- max77620: max77620@3c {
+ pmic: pmic@3c {
compatible = "maxim,max77620";
reg = <0x3c>;
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
@@ -1372,8 +1372,8 @@ max77620: max77620@3c {
pinctrl-names = "default";
pinctrl-0 = <&max77620_default>;
- max77620_default: pinmux@0 {
- pin_gpio {
+ max77620_default: pinmux {
+ gpio0_1_2_7 {
pins = "gpio0", "gpio1", "gpio2", "gpio7";
function = "gpio";
};
@@ -1383,7 +1383,7 @@ pin_gpio {
* sequence, So it must be sequenced up (automatically
* set by OTP) and down properly.
*/
- pin_gpio3 {
+ gpio3 {
pins = "gpio3";
function = "fps-out";
drive-open-drain = <1>;
@@ -1392,13 +1392,13 @@ pin_gpio3 {
maxim,active-fps-power-down-slot = <2>;
};
- pin_gpio5_6 {
+ gpio5_6 {
pins = "gpio5", "gpio6";
function = "gpio";
drive-push-pull = <1>;
};
- pin_32k {
+ gpio4 {
pins = "gpio4";
function = "32k-out1";
};
--
2.24.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