[PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Hi,

this is an alternative proposal to fix panel support on Venice 2 and
Nyan. Dmitry had proposed a different solution that involved reverting
the I2C/DDC registration order and would complicate things by breaking
the encapsulation of the driver by introducing a global (though locally
scoped) variable[0].

This set of patches avoids that by using the recently introduced DP AUX
bus infrastructure. The result is that the changes are actually less
intrusive and not a step back. Instead they nicely remove the circular
dependency that previously existed and caused these issues in the first
place.

To be fair, this is not perfect either because it requires a device tree
change and hence isn't technically backwards-compatible. However, given
that the original device tree was badly broken in the first place, I
think we can make an exception, especially since it is not generally a
problem to update device trees on the affected devices.

Secondly, this relies on infrastructure that was introduced in v5.15 and
therefore will be difficult to backport beyond that. However, since this
functionality has been broken since v5.13 and all of the kernel versions
between that and v5.15 are EOL anyway, there isn't much that we can do
to fix the interim versions anyway.

Adding Doug and Laurent since they originally designed the AUX bus
patches in case they see anything in here that would be objectionable.

Thierry

[0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/

Thierry Reding (2):
  drm/tegra: dpaux: Populate AUX bus
  ARM: tegra: Move panels to AUX bus

 arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
 arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
 arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
 drivers/gpu/drm/tegra/Kconfig             |  1 +
 drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
 5 files changed, 33 insertions(+), 19 deletions(-)

-- 
2.34.1

[PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Hi,

this is an alternative proposal to fix panel support on Venice 2 and
Nyan. Dmitry had proposed a different solution that involved reverting
the I2C/DDC registration order and would complicate things by breaking
the encapsulation of the driver by introducing a global (though locally
scoped) variable[0].

This set of patches avoids that by using the recently introduced DP AUX
bus infrastructure. The result is that the changes are actually less
intrusive and not a step back. Instead they nicely remove the circular
dependency that previously existed and caused these issues in the first
place.

To be fair, this is not perfect either because it requires a device tree
change and hence isn't technically backwards-compatible. However, given
that the original device tree was badly broken in the first place, I
think we can make an exception, especially since it is not generally a
problem to update device trees on the affected devices.

Secondly, this relies on infrastructure that was introduced in v5.15 and
therefore will be difficult to backport beyond that. However, since this
functionality has been broken since v5.13 and all of the kernel versions
between that and v5.15 are EOL anyway, there isn't much that we can do
to fix the interim versions anyway.

Adding Doug and Laurent since they originally designed the AUX bus
patches in case they see anything in here that would be objectionable.

Thierry

[0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/

Thierry Reding (2):
  drm/tegra: dpaux: Populate AUX bus
  ARM: tegra: Move panels to AUX bus

 arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
 arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
 arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
 drivers/gpu/drm/tegra/Kconfig             |  1 +
 drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
 5 files changed, 33 insertions(+), 19 deletions(-)

-- 
2.34.1

[PATCH 1/2] drm/tegra: dpaux: Populate AUX bus

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

The DPAUX hardware block exposes an DP AUX interface that provides
access to an AUX bus and the devices on that bus. Use the DP AUX bus
infrastructure that was recently introduced to probe devices on this
bus from DT.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/gpu/drm/tegra/Kconfig | 1 +
 drivers/gpu/drm/tegra/dpaux.c | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 8cf5aeb9db6c..201f5175ecfe 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -5,6 +5,7 @@ config DRM_TEGRA
 	depends on COMMON_CLK
 	depends on DRM
 	depends on OF
+	select DRM_DP_AUX_BUS
 	select DRM_KMS_HELPER
 	select DRM_MIPI_DSI
 	select DRM_PANEL
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 1f96e416fa08..9da1edcdc835 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -18,6 +18,7 @@
 #include <linux/reset.h>
 #include <linux/workqueue.h>
 
+#include <drm/drm_dp_aux_bus.h>
 #include <drm/drm_dp_helper.h>
 #include <drm/drm_panel.h>
 
@@ -570,6 +571,12 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
 	list_add_tail(&dpaux->list, &dpaux_list);
 	mutex_unlock(&dpaux_lock);
 
+	err = devm_of_dp_aux_populate_ep_devices(&dpaux->aux);
+	if (err < 0) {
+		dev_err(dpaux->dev, "failed to populate AUX bus: %d\n", err);
+		return err;
+	}
+
 	return 0;
 }
 
-- 
2.34.1

[PATCH 1/2] drm/tegra: dpaux: Populate AUX bus

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

The DPAUX hardware block exposes an DP AUX interface that provides
access to an AUX bus and the devices on that bus. Use the DP AUX bus
infrastructure that was recently introduced to probe devices on this
bus from DT.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/gpu/drm/tegra/Kconfig | 1 +
 drivers/gpu/drm/tegra/dpaux.c | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 8cf5aeb9db6c..201f5175ecfe 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -5,6 +5,7 @@ config DRM_TEGRA
 	depends on COMMON_CLK
 	depends on DRM
 	depends on OF
+	select DRM_DP_AUX_BUS
 	select DRM_KMS_HELPER
 	select DRM_MIPI_DSI
 	select DRM_PANEL
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 1f96e416fa08..9da1edcdc835 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -18,6 +18,7 @@
 #include <linux/reset.h>
 #include <linux/workqueue.h>
 
+#include <drm/drm_dp_aux_bus.h>
 #include <drm/drm_dp_helper.h>
 #include <drm/drm_panel.h>
 
@@ -570,6 +571,12 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
 	list_add_tail(&dpaux->list, &dpaux_list);
 	mutex_unlock(&dpaux_lock);
 
+	err = devm_of_dp_aux_populate_ep_devices(&dpaux->aux);
+	if (err < 0) {
+		dev_err(dpaux->dev, "failed to populate AUX bus: %d\n", err);
+		return err;
+	}
+
 	return 0;
 }
 
-- 
2.34.1

Re: [PATCH 1/2] drm/tegra: dpaux: Populate AUX bus

[Dmitry Osipenko]

20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
> 
> The DPAUX hardware block exposes an DP AUX interface that provides
> access to an AUX bus and the devices on that bus. Use the DP AUX bus
> infrastructure that was recently introduced to probe devices on this
> bus from DT.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  drivers/gpu/drm/tegra/Kconfig | 1 +
>  drivers/gpu/drm/tegra/dpaux.c | 7 +++++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index 8cf5aeb9db6c..201f5175ecfe 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -5,6 +5,7 @@ config DRM_TEGRA
>  	depends on COMMON_CLK
>  	depends on DRM
>  	depends on OF
> +	select DRM_DP_AUX_BUS
>  	select DRM_KMS_HELPER
>  	select DRM_MIPI_DSI
>  	select DRM_PANEL
> diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
> index 1f96e416fa08..9da1edcdc835 100644
> --- a/drivers/gpu/drm/tegra/dpaux.c
> +++ b/drivers/gpu/drm/tegra/dpaux.c
> @@ -18,6 +18,7 @@
>  #include <linux/reset.h>
>  #include <linux/workqueue.h>
>  
> +#include <drm/drm_dp_aux_bus.h>
>  #include <drm/drm_dp_helper.h>
>  #include <drm/drm_panel.h>
>  
> @@ -570,6 +571,12 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
>  	list_add_tail(&dpaux->list, &dpaux_list);
>  	mutex_unlock(&dpaux_lock);
>  
> +	err = devm_of_dp_aux_populate_ep_devices(&dpaux->aux);
> +	if (err < 0) {
> +		dev_err(dpaux->dev, "failed to populate AUX bus: %d\n", err);
> +		return err;
> +	}
> +
>  	return 0;
>  }

Needs stable tag for 5.15+.

Re: [PATCH 1/2] drm/tegra: dpaux: Populate AUX bus

[Dmitry Osipenko]

20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
> 
> The DPAUX hardware block exposes an DP AUX interface that provides
> access to an AUX bus and the devices on that bus. Use the DP AUX bus
> infrastructure that was recently introduced to probe devices on this
> bus from DT.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  drivers/gpu/drm/tegra/Kconfig | 1 +
>  drivers/gpu/drm/tegra/dpaux.c | 7 +++++++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index 8cf5aeb9db6c..201f5175ecfe 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -5,6 +5,7 @@ config DRM_TEGRA
>  	depends on COMMON_CLK
>  	depends on DRM
>  	depends on OF
> +	select DRM_DP_AUX_BUS
>  	select DRM_KMS_HELPER
>  	select DRM_MIPI_DSI
>  	select DRM_PANEL
> diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
> index 1f96e416fa08..9da1edcdc835 100644
> --- a/drivers/gpu/drm/tegra/dpaux.c
> +++ b/drivers/gpu/drm/tegra/dpaux.c
> @@ -18,6 +18,7 @@
>  #include <linux/reset.h>
>  #include <linux/workqueue.h>
>  
> +#include <drm/drm_dp_aux_bus.h>
>  #include <drm/drm_dp_helper.h>
>  #include <drm/drm_panel.h>
>  
> @@ -570,6 +571,12 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
>  	list_add_tail(&dpaux->list, &dpaux_list);
>  	mutex_unlock(&dpaux_lock);
>  
> +	err = devm_of_dp_aux_populate_ep_devices(&dpaux->aux);
> +	if (err < 0) {
> +		dev_err(dpaux->dev, "failed to populate AUX bus: %d\n", err);
> +		return err;
> +	}
> +
>  	return 0;
>  }

Needs stable tag for 5.15+.

Re: [PATCH 1/2] drm/tegra: dpaux: Populate AUX bus

[Doug Anderson]

Hi,

On Mon, Dec 20, 2021 at 2:49 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> From: Thierry Reding <treding@nvidia.com>
>
> The DPAUX hardware block exposes an DP AUX interface that provides
> access to an AUX bus and the devices on that bus. Use the DP AUX bus
> infrastructure that was recently introduced to probe devices on this
> bus from DT.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  drivers/gpu/drm/tegra/Kconfig | 1 +
>  drivers/gpu/drm/tegra/dpaux.c | 7 +++++++
>  2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index 8cf5aeb9db6c..201f5175ecfe 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -5,6 +5,7 @@ config DRM_TEGRA
>         depends on COMMON_CLK
>         depends on DRM
>         depends on OF
> +       select DRM_DP_AUX_BUS
>         select DRM_KMS_HELPER
>         select DRM_MIPI_DSI
>         select DRM_PANEL
> diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
> index 1f96e416fa08..9da1edcdc835 100644
> --- a/drivers/gpu/drm/tegra/dpaux.c
> +++ b/drivers/gpu/drm/tegra/dpaux.c
> @@ -18,6 +18,7 @@
>  #include <linux/reset.h>
>  #include <linux/workqueue.h>
>
> +#include <drm/drm_dp_aux_bus.h>
>  #include <drm/drm_dp_helper.h>
>  #include <drm/drm_panel.h>
>
> @@ -570,6 +571,12 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
>         list_add_tail(&dpaux->list, &dpaux_list);
>         mutex_unlock(&dpaux_lock);
>
> +       err = devm_of_dp_aux_populate_ep_devices(&dpaux->aux);
> +       if (err < 0) {
> +               dev_err(dpaux->dev, "failed to populate AUX bus: %d\n", err);
> +               return err;

nit:

if (err < 0)
  return dev_err_probe(dpaux->dev, err, "failed to populate AUX bus\n");

That's more concise and gives the pretty formatting for the error code
(not that devm_of_dp_aux_populate_ep_devices() currently returns
anything other than 0).

> +       }

I think you need to use of_dp_aux_populate_ep_devices() and then
depopulate in your remove, right? Otherwise the ordering won't be
right. Either that or fully transition your probe to devm (and get rid
of your remove) by adding some devm_add_action_or_reset() helpers...

Hrm, I guess looking closer it's also a little concerning that if
devm_of_dp_aux_populate_ep_devices() returns an error then you'll
totally skip all the things that tegra_dpaux_remove() is supposed to
handle. I guess that's a pre-existing bug (earlier error cases in the
probe don't, for instance, undo the pm_runtime state) but this makes
it worse.


-Doug

Re: [PATCH 1/2] drm/tegra: dpaux: Populate AUX bus

[Doug Anderson]

Hi,

On Mon, Dec 20, 2021 at 2:49 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> From: Thierry Reding <treding@nvidia.com>
>
> The DPAUX hardware block exposes an DP AUX interface that provides
> access to an AUX bus and the devices on that bus. Use the DP AUX bus
> infrastructure that was recently introduced to probe devices on this
> bus from DT.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  drivers/gpu/drm/tegra/Kconfig | 1 +
>  drivers/gpu/drm/tegra/dpaux.c | 7 +++++++
>  2 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index 8cf5aeb9db6c..201f5175ecfe 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -5,6 +5,7 @@ config DRM_TEGRA
>         depends on COMMON_CLK
>         depends on DRM
>         depends on OF
> +       select DRM_DP_AUX_BUS
>         select DRM_KMS_HELPER
>         select DRM_MIPI_DSI
>         select DRM_PANEL
> diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
> index 1f96e416fa08..9da1edcdc835 100644
> --- a/drivers/gpu/drm/tegra/dpaux.c
> +++ b/drivers/gpu/drm/tegra/dpaux.c
> @@ -18,6 +18,7 @@
>  #include <linux/reset.h>
>  #include <linux/workqueue.h>
>
> +#include <drm/drm_dp_aux_bus.h>
>  #include <drm/drm_dp_helper.h>
>  #include <drm/drm_panel.h>
>
> @@ -570,6 +571,12 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
>         list_add_tail(&dpaux->list, &dpaux_list);
>         mutex_unlock(&dpaux_lock);
>
> +       err = devm_of_dp_aux_populate_ep_devices(&dpaux->aux);
> +       if (err < 0) {
> +               dev_err(dpaux->dev, "failed to populate AUX bus: %d\n", err);
> +               return err;

nit:

if (err < 0)
  return dev_err_probe(dpaux->dev, err, "failed to populate AUX bus\n");

That's more concise and gives the pretty formatting for the error code
(not that devm_of_dp_aux_populate_ep_devices() currently returns
anything other than 0).

> +       }

I think you need to use of_dp_aux_populate_ep_devices() and then
depopulate in your remove, right? Otherwise the ordering won't be
right. Either that or fully transition your probe to devm (and get rid
of your remove) by adding some devm_add_action_or_reset() helpers...

Hrm, I guess looking closer it's also a little concerning that if
devm_of_dp_aux_populate_ep_devices() returns an error then you'll
totally skip all the things that tegra_dpaux_remove() is supposed to
handle. I guess that's a pre-existing bug (earlier error cases in the
probe don't, for instance, undo the pm_runtime state) but this makes
it worse.


-Doug

[PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Move the eDP panel on Venice 2 and Nyan boards into the corresponding
AUX bus device tree node. This allows us to avoid a nasty circular
dependency that would otherwise be created between the DPAUX and panel
nodes via the DDC/I2C phandle.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
 arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
 arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
 3 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
index 1d2aac2cb6d0..fdc1d64dfff9 100644
--- a/arch/arm/boot/dts/tegra124-nyan-big.dts
+++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
@@ -13,12 +13,15 @@ / {
 		     "google,nyan-big-rev1", "google,nyan-big-rev0",
 		     "google,nyan-big", "google,nyan", "nvidia,tegra124";
 
-	panel: panel {
-		compatible = "auo,b133xtn01";
-
-		power-supply = <&vdd_3v3_panel>;
-		backlight = <&backlight>;
-		ddc-i2c-bus = <&dpaux>;
+	host1x@50000000 {
+		dpaux@545c0000 {
+			aux-bus {
+				panel: panel {
+					compatible = "auo,b133xtn01";
+					backlight = <&backlight>;
+				};
+			};
+		};
 	};
 
 	mmc@700b0400 { /* SD Card on this bus */
diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
index 677babde6460..abdf4456826f 100644
--- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
+++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
@@ -15,12 +15,15 @@ / {
 		     "google,nyan-blaze-rev0", "google,nyan-blaze",
 		     "google,nyan", "nvidia,tegra124";
 
-	panel: panel {
-		compatible = "samsung,ltn140at29-301";
-
-		power-supply = <&vdd_3v3_panel>;
-		backlight = <&backlight>;
-		ddc-i2c-bus = <&dpaux>;
+	host1x@50000000 {
+		dpaux@545c0000 {
+			aux-bus {
+				panel: panel {
+					compatible = "samsung,ltn140at29-301";
+					backlight = <&backlight>;
+				};
+			};
+		};
 	};
 
 	sound {
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 232c90604df9..6a9592ceb5f2 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -48,6 +48,13 @@ sor@54540000 {
 		dpaux@545c0000 {
 			vdd-supply = <&vdd_3v3_panel>;
 			status = "okay";
+
+			aux-bus {
+				panel: panel {
+					compatible = "lg,lp129qe";
+					backlight = <&backlight>;
+				};
+			};
 		};
 	};
 
@@ -1080,13 +1087,6 @@ power {
 		};
 	};
 
-	panel: panel {
-		compatible = "lg,lp129qe";
-		power-supply = <&vdd_3v3_panel>;
-		backlight = <&backlight>;
-		ddc-i2c-bus = <&dpaux>;
-	};
-
 	vdd_mux: regulator-mux {
 		compatible = "regulator-fixed";
 		regulator-name = "+VDD_MUX";
-- 
2.34.1

[PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Thierry Reding]

From: Thierry Reding <treding@nvidia.com>

Move the eDP panel on Venice 2 and Nyan boards into the corresponding
AUX bus device tree node. This allows us to avoid a nasty circular
dependency that would otherwise be created between the DPAUX and panel
nodes via the DDC/I2C phandle.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
 arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
 arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
 3 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
index 1d2aac2cb6d0..fdc1d64dfff9 100644
--- a/arch/arm/boot/dts/tegra124-nyan-big.dts
+++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
@@ -13,12 +13,15 @@ / {
 		     "google,nyan-big-rev1", "google,nyan-big-rev0",
 		     "google,nyan-big", "google,nyan", "nvidia,tegra124";
 
-	panel: panel {
-		compatible = "auo,b133xtn01";
-
-		power-supply = <&vdd_3v3_panel>;
-		backlight = <&backlight>;
-		ddc-i2c-bus = <&dpaux>;
+	host1x@50000000 {
+		dpaux@545c0000 {
+			aux-bus {
+				panel: panel {
+					compatible = "auo,b133xtn01";
+					backlight = <&backlight>;
+				};
+			};
+		};
 	};
 
 	mmc@700b0400 { /* SD Card on this bus */
diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
index 677babde6460..abdf4456826f 100644
--- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
+++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
@@ -15,12 +15,15 @@ / {
 		     "google,nyan-blaze-rev0", "google,nyan-blaze",
 		     "google,nyan", "nvidia,tegra124";
 
-	panel: panel {
-		compatible = "samsung,ltn140at29-301";
-
-		power-supply = <&vdd_3v3_panel>;
-		backlight = <&backlight>;
-		ddc-i2c-bus = <&dpaux>;
+	host1x@50000000 {
+		dpaux@545c0000 {
+			aux-bus {
+				panel: panel {
+					compatible = "samsung,ltn140at29-301";
+					backlight = <&backlight>;
+				};
+			};
+		};
 	};
 
 	sound {
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 232c90604df9..6a9592ceb5f2 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -48,6 +48,13 @@ sor@54540000 {
 		dpaux@545c0000 {
 			vdd-supply = <&vdd_3v3_panel>;
 			status = "okay";
+
+			aux-bus {
+				panel: panel {
+					compatible = "lg,lp129qe";
+					backlight = <&backlight>;
+				};
+			};
 		};
 	};
 
@@ -1080,13 +1087,6 @@ power {
 		};
 	};
 
-	panel: panel {
-		compatible = "lg,lp129qe";
-		power-supply = <&vdd_3v3_panel>;
-		backlight = <&backlight>;
-		ddc-i2c-bus = <&dpaux>;
-	};
-
 	vdd_mux: regulator-mux {
 		compatible = "regulator-fixed";
 		regulator-name = "+VDD_MUX";
-- 
2.34.1

Re: [PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Dmitry Osipenko]

20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
> 
> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
> AUX bus device tree node. This allows us to avoid a nasty circular
> dependency that would otherwise be created between the DPAUX and panel
> nodes via the DDC/I2C phandle.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>  3 files changed, 25 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
> index 1d2aac2cb6d0..fdc1d64dfff9 100644
> --- a/arch/arm/boot/dts/tegra124-nyan-big.dts
> +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
> @@ -13,12 +13,15 @@ / {
>  		     "google,nyan-big-rev1", "google,nyan-big-rev0",
>  		     "google,nyan-big", "google,nyan", "nvidia,tegra124";
>  
> -	panel: panel {
> -		compatible = "auo,b133xtn01";
> -
> -		power-supply = <&vdd_3v3_panel>;
> -		backlight = <&backlight>;
> -		ddc-i2c-bus = <&dpaux>;
> +	host1x@50000000 {
> +		dpaux@545c0000 {
> +			aux-bus {
> +				panel: panel {
> +					compatible = "auo,b133xtn01";
> +					backlight = <&backlight>;
> +				};
> +			};
> +		};
>  	};
>  
>  	mmc@700b0400 { /* SD Card on this bus */
> diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> index 677babde6460..abdf4456826f 100644
> --- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> +++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> @@ -15,12 +15,15 @@ / {
>  		     "google,nyan-blaze-rev0", "google,nyan-blaze",
>  		     "google,nyan", "nvidia,tegra124";
>  
> -	panel: panel {
> -		compatible = "samsung,ltn140at29-301";
> -
> -		power-supply = <&vdd_3v3_panel>;
> -		backlight = <&backlight>;
> -		ddc-i2c-bus = <&dpaux>;
> +	host1x@50000000 {
> +		dpaux@545c0000 {
> +			aux-bus {
> +				panel: panel {
> +					compatible = "samsung,ltn140at29-301";
> +					backlight = <&backlight>;
> +				};
> +			};
> +		};
>  	};
>  
>  	sound {
> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
> index 232c90604df9..6a9592ceb5f2 100644
> --- a/arch/arm/boot/dts/tegra124-venice2.dts
> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
> @@ -48,6 +48,13 @@ sor@54540000 {
>  		dpaux@545c0000 {
>  			vdd-supply = <&vdd_3v3_panel>;
>  			status = "okay";
> +
> +			aux-bus {
> +				panel: panel {
> +					compatible = "lg,lp129qe";
> +					backlight = <&backlight>;
> +				};
> +			};
>  		};
>  	};
>  
> @@ -1080,13 +1087,6 @@ power {
>  		};
>  	};
>  
> -	panel: panel {
> -		compatible = "lg,lp129qe";
> -		power-supply = <&vdd_3v3_panel>;
> -		backlight = <&backlight>;
> -		ddc-i2c-bus = <&dpaux>;
> -	};
> -
>  	vdd_mux: regulator-mux {
>  		compatible = "regulator-fixed";
>  		regulator-name = "+VDD_MUX";
> 

You should add stable tag for 5.15 and also add separate patch to update
the new arch/arm/boot/dts/tegra124-nyan-big-fhd.dts which we have in
-next now.

Re: [PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Dmitry Osipenko]

20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
> 
> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
> AUX bus device tree node. This allows us to avoid a nasty circular
> dependency that would otherwise be created between the DPAUX and panel
> nodes via the DDC/I2C phandle.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>  3 files changed, 25 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
> index 1d2aac2cb6d0..fdc1d64dfff9 100644
> --- a/arch/arm/boot/dts/tegra124-nyan-big.dts
> +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
> @@ -13,12 +13,15 @@ / {
>  		     "google,nyan-big-rev1", "google,nyan-big-rev0",
>  		     "google,nyan-big", "google,nyan", "nvidia,tegra124";
>  
> -	panel: panel {
> -		compatible = "auo,b133xtn01";
> -
> -		power-supply = <&vdd_3v3_panel>;
> -		backlight = <&backlight>;
> -		ddc-i2c-bus = <&dpaux>;
> +	host1x@50000000 {
> +		dpaux@545c0000 {
> +			aux-bus {
> +				panel: panel {
> +					compatible = "auo,b133xtn01";
> +					backlight = <&backlight>;
> +				};
> +			};
> +		};
>  	};
>  
>  	mmc@700b0400 { /* SD Card on this bus */
> diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> index 677babde6460..abdf4456826f 100644
> --- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> +++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> @@ -15,12 +15,15 @@ / {
>  		     "google,nyan-blaze-rev0", "google,nyan-blaze",
>  		     "google,nyan", "nvidia,tegra124";
>  
> -	panel: panel {
> -		compatible = "samsung,ltn140at29-301";
> -
> -		power-supply = <&vdd_3v3_panel>;
> -		backlight = <&backlight>;
> -		ddc-i2c-bus = <&dpaux>;
> +	host1x@50000000 {
> +		dpaux@545c0000 {
> +			aux-bus {
> +				panel: panel {
> +					compatible = "samsung,ltn140at29-301";
> +					backlight = <&backlight>;
> +				};
> +			};
> +		};
>  	};
>  
>  	sound {
> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
> index 232c90604df9..6a9592ceb5f2 100644
> --- a/arch/arm/boot/dts/tegra124-venice2.dts
> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
> @@ -48,6 +48,13 @@ sor@54540000 {
>  		dpaux@545c0000 {
>  			vdd-supply = <&vdd_3v3_panel>;
>  			status = "okay";
> +
> +			aux-bus {
> +				panel: panel {
> +					compatible = "lg,lp129qe";
> +					backlight = <&backlight>;
> +				};
> +			};
>  		};
>  	};
>  
> @@ -1080,13 +1087,6 @@ power {
>  		};
>  	};
>  
> -	panel: panel {
> -		compatible = "lg,lp129qe";
> -		power-supply = <&vdd_3v3_panel>;
> -		backlight = <&backlight>;
> -		ddc-i2c-bus = <&dpaux>;
> -	};
> -
>  	vdd_mux: regulator-mux {
>  		compatible = "regulator-fixed";
>  		regulator-name = "+VDD_MUX";
> 

You should add stable tag for 5.15 and also add separate patch to update
the new arch/arm/boot/dts/tegra124-nyan-big-fhd.dts which we have in
-next now.

Re: [PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Dmitry Osipenko]

22.12.2021 22:30, Dmitry Osipenko пишет:
> 20.12.2021 13:48, Thierry Reding пишет:
>> From: Thierry Reding <treding@nvidia.com>
>>
>> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
>> AUX bus device tree node. This allows us to avoid a nasty circular
>> dependency that would otherwise be created between the DPAUX and panel
>> nodes via the DDC/I2C phandle.
>>
>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>> ---
>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>>  3 files changed, 25 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
>> index 1d2aac2cb6d0..fdc1d64dfff9 100644
>> --- a/arch/arm/boot/dts/tegra124-nyan-big.dts
>> +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
>> @@ -13,12 +13,15 @@ / {
>>  		     "google,nyan-big-rev1", "google,nyan-big-rev0",
>>  		     "google,nyan-big", "google,nyan", "nvidia,tegra124";
>>  
>> -	panel: panel {
>> -		compatible = "auo,b133xtn01";
>> -
>> -		power-supply = <&vdd_3v3_panel>;
>> -		backlight = <&backlight>;
>> -		ddc-i2c-bus = <&dpaux>;
>> +	host1x@50000000 {
>> +		dpaux@545c0000 {
>> +			aux-bus {
>> +				panel: panel {
>> +					compatible = "auo,b133xtn01";
>> +					backlight = <&backlight>;
>> +				};
>> +			};
>> +		};
>>  	};
>>  
>>  	mmc@700b0400 { /* SD Card on this bus */
>> diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
>> index 677babde6460..abdf4456826f 100644
>> --- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
>> +++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
>> @@ -15,12 +15,15 @@ / {
>>  		     "google,nyan-blaze-rev0", "google,nyan-blaze",
>>  		     "google,nyan", "nvidia,tegra124";
>>  
>> -	panel: panel {
>> -		compatible = "samsung,ltn140at29-301";
>> -
>> -		power-supply = <&vdd_3v3_panel>;
>> -		backlight = <&backlight>;
>> -		ddc-i2c-bus = <&dpaux>;
>> +	host1x@50000000 {
>> +		dpaux@545c0000 {
>> +			aux-bus {
>> +				panel: panel {
>> +					compatible = "samsung,ltn140at29-301";
>> +					backlight = <&backlight>;
>> +				};
>> +			};
>> +		};
>>  	};
>>  
>>  	sound {
>> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
>> index 232c90604df9..6a9592ceb5f2 100644
>> --- a/arch/arm/boot/dts/tegra124-venice2.dts
>> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
>> @@ -48,6 +48,13 @@ sor@54540000 {
>>  		dpaux@545c0000 {
>>  			vdd-supply = <&vdd_3v3_panel>;
>>  			status = "okay";
>> +
>> +			aux-bus {
>> +				panel: panel {
>> +					compatible = "lg,lp129qe";
>> +					backlight = <&backlight>;
>> +				};
>> +			};
>>  		};
>>  	};
>>  
>> @@ -1080,13 +1087,6 @@ power {
>>  		};
>>  	};
>>  
>> -	panel: panel {
>> -		compatible = "lg,lp129qe";
>> -		power-supply = <&vdd_3v3_panel>;
>> -		backlight = <&backlight>;
>> -		ddc-i2c-bus = <&dpaux>;
>> -	};
>> -
>>  	vdd_mux: regulator-mux {
>>  		compatible = "regulator-fixed";
>>  		regulator-name = "+VDD_MUX";
>>
> 
> You should add stable tag for 5.15 and also add separate patch to update
> the new arch/arm/boot/dts/tegra124-nyan-big-fhd.dts which we have in
> -next now.

Thierry, are you going to address this review comment? I see in
linux-next that you picked up this incomplete version of the patch.

Re: [PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Dmitry Osipenko]

22.12.2021 22:30, Dmitry Osipenko пишет:
> 20.12.2021 13:48, Thierry Reding пишет:
>> From: Thierry Reding <treding@nvidia.com>
>>
>> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
>> AUX bus device tree node. This allows us to avoid a nasty circular
>> dependency that would otherwise be created between the DPAUX and panel
>> nodes via the DDC/I2C phandle.
>>
>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>> ---
>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>>  3 files changed, 25 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
>> index 1d2aac2cb6d0..fdc1d64dfff9 100644
>> --- a/arch/arm/boot/dts/tegra124-nyan-big.dts
>> +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
>> @@ -13,12 +13,15 @@ / {
>>  		     "google,nyan-big-rev1", "google,nyan-big-rev0",
>>  		     "google,nyan-big", "google,nyan", "nvidia,tegra124";
>>  
>> -	panel: panel {
>> -		compatible = "auo,b133xtn01";
>> -
>> -		power-supply = <&vdd_3v3_panel>;
>> -		backlight = <&backlight>;
>> -		ddc-i2c-bus = <&dpaux>;
>> +	host1x@50000000 {
>> +		dpaux@545c0000 {
>> +			aux-bus {
>> +				panel: panel {
>> +					compatible = "auo,b133xtn01";
>> +					backlight = <&backlight>;
>> +				};
>> +			};
>> +		};
>>  	};
>>  
>>  	mmc@700b0400 { /* SD Card on this bus */
>> diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
>> index 677babde6460..abdf4456826f 100644
>> --- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
>> +++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
>> @@ -15,12 +15,15 @@ / {
>>  		     "google,nyan-blaze-rev0", "google,nyan-blaze",
>>  		     "google,nyan", "nvidia,tegra124";
>>  
>> -	panel: panel {
>> -		compatible = "samsung,ltn140at29-301";
>> -
>> -		power-supply = <&vdd_3v3_panel>;
>> -		backlight = <&backlight>;
>> -		ddc-i2c-bus = <&dpaux>;
>> +	host1x@50000000 {
>> +		dpaux@545c0000 {
>> +			aux-bus {
>> +				panel: panel {
>> +					compatible = "samsung,ltn140at29-301";
>> +					backlight = <&backlight>;
>> +				};
>> +			};
>> +		};
>>  	};
>>  
>>  	sound {
>> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
>> index 232c90604df9..6a9592ceb5f2 100644
>> --- a/arch/arm/boot/dts/tegra124-venice2.dts
>> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
>> @@ -48,6 +48,13 @@ sor@54540000 {
>>  		dpaux@545c0000 {
>>  			vdd-supply = <&vdd_3v3_panel>;
>>  			status = "okay";
>> +
>> +			aux-bus {
>> +				panel: panel {
>> +					compatible = "lg,lp129qe";
>> +					backlight = <&backlight>;
>> +				};
>> +			};
>>  		};
>>  	};
>>  
>> @@ -1080,13 +1087,6 @@ power {
>>  		};
>>  	};
>>  
>> -	panel: panel {
>> -		compatible = "lg,lp129qe";
>> -		power-supply = <&vdd_3v3_panel>;
>> -		backlight = <&backlight>;
>> -		ddc-i2c-bus = <&dpaux>;
>> -	};
>> -
>>  	vdd_mux: regulator-mux {
>>  		compatible = "regulator-fixed";
>>  		regulator-name = "+VDD_MUX";
>>
> 
> You should add stable tag for 5.15 and also add separate patch to update
> the new arch/arm/boot/dts/tegra124-nyan-big-fhd.dts which we have in
> -next now.

Thierry, are you going to address this review comment? I see in
linux-next that you picked up this incomplete version of the patch.

Re: [PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]

On Sun, Mar 06, 2022 at 08:59:13PM +0300, Dmitry Osipenko wrote:
> 22.12.2021 22:30, Dmitry Osipenko пишет:
> > 20.12.2021 13:48, Thierry Reding пишет:
> >> From: Thierry Reding <treding@nvidia.com>
> >>
> >> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
> >> AUX bus device tree node. This allows us to avoid a nasty circular
> >> dependency that would otherwise be created between the DPAUX and panel
> >> nodes via the DDC/I2C phandle.
> >>
> >> Signed-off-by: Thierry Reding <treding@nvidia.com>
> >> ---
> >>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
> >>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
> >>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
> >>  3 files changed, 25 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
> >> index 1d2aac2cb6d0..fdc1d64dfff9 100644
> >> --- a/arch/arm/boot/dts/tegra124-nyan-big.dts
> >> +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
> >> @@ -13,12 +13,15 @@ / {
> >>  		     "google,nyan-big-rev1", "google,nyan-big-rev0",
> >>  		     "google,nyan-big", "google,nyan", "nvidia,tegra124";
> >>  
> >> -	panel: panel {
> >> -		compatible = "auo,b133xtn01";
> >> -
> >> -		power-supply = <&vdd_3v3_panel>;
> >> -		backlight = <&backlight>;
> >> -		ddc-i2c-bus = <&dpaux>;
> >> +	host1x@50000000 {
> >> +		dpaux@545c0000 {
> >> +			aux-bus {
> >> +				panel: panel {
> >> +					compatible = "auo,b133xtn01";
> >> +					backlight = <&backlight>;
> >> +				};
> >> +			};
> >> +		};
> >>  	};
> >>  
> >>  	mmc@700b0400 { /* SD Card on this bus */
> >> diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> >> index 677babde6460..abdf4456826f 100644
> >> --- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> >> +++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> >> @@ -15,12 +15,15 @@ / {
> >>  		     "google,nyan-blaze-rev0", "google,nyan-blaze",
> >>  		     "google,nyan", "nvidia,tegra124";
> >>  
> >> -	panel: panel {
> >> -		compatible = "samsung,ltn140at29-301";
> >> -
> >> -		power-supply = <&vdd_3v3_panel>;
> >> -		backlight = <&backlight>;
> >> -		ddc-i2c-bus = <&dpaux>;
> >> +	host1x@50000000 {
> >> +		dpaux@545c0000 {
> >> +			aux-bus {
> >> +				panel: panel {
> >> +					compatible = "samsung,ltn140at29-301";
> >> +					backlight = <&backlight>;
> >> +				};
> >> +			};
> >> +		};
> >>  	};
> >>  
> >>  	sound {
> >> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
> >> index 232c90604df9..6a9592ceb5f2 100644
> >> --- a/arch/arm/boot/dts/tegra124-venice2.dts
> >> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
> >> @@ -48,6 +48,13 @@ sor@54540000 {
> >>  		dpaux@545c0000 {
> >>  			vdd-supply = <&vdd_3v3_panel>;
> >>  			status = "okay";
> >> +
> >> +			aux-bus {
> >> +				panel: panel {
> >> +					compatible = "lg,lp129qe";
> >> +					backlight = <&backlight>;
> >> +				};
> >> +			};
> >>  		};
> >>  	};
> >>  
> >> @@ -1080,13 +1087,6 @@ power {
> >>  		};
> >>  	};
> >>  
> >> -	panel: panel {
> >> -		compatible = "lg,lp129qe";
> >> -		power-supply = <&vdd_3v3_panel>;
> >> -		backlight = <&backlight>;
> >> -		ddc-i2c-bus = <&dpaux>;
> >> -	};
> >> -
> >>  	vdd_mux: regulator-mux {
> >>  		compatible = "regulator-fixed";
> >>  		regulator-name = "+VDD_MUX";
> >>
> > 
> > You should add stable tag for 5.15 and also add separate patch to update
> > the new arch/arm/boot/dts/tegra124-nyan-big-fhd.dts which we have in
> > -next now.
> 
> Thierry, are you going to address this review comment? I see in
> linux-next that you picked up this incomplete version of the patch.

Ah, shoot. I've got this in my local tree but forgot to squash this in
with the other changes. I'll send out a follow-up.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]

On Sun, Mar 06, 2022 at 08:59:13PM +0300, Dmitry Osipenko wrote:
> 22.12.2021 22:30, Dmitry Osipenko пишет:
> > 20.12.2021 13:48, Thierry Reding пишет:
> >> From: Thierry Reding <treding@nvidia.com>
> >>
> >> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
> >> AUX bus device tree node. This allows us to avoid a nasty circular
> >> dependency that would otherwise be created between the DPAUX and panel
> >> nodes via the DDC/I2C phandle.
> >>
> >> Signed-off-by: Thierry Reding <treding@nvidia.com>
> >> ---
> >>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
> >>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
> >>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
> >>  3 files changed, 25 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
> >> index 1d2aac2cb6d0..fdc1d64dfff9 100644
> >> --- a/arch/arm/boot/dts/tegra124-nyan-big.dts
> >> +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
> >> @@ -13,12 +13,15 @@ / {
> >>  		     "google,nyan-big-rev1", "google,nyan-big-rev0",
> >>  		     "google,nyan-big", "google,nyan", "nvidia,tegra124";
> >>  
> >> -	panel: panel {
> >> -		compatible = "auo,b133xtn01";
> >> -
> >> -		power-supply = <&vdd_3v3_panel>;
> >> -		backlight = <&backlight>;
> >> -		ddc-i2c-bus = <&dpaux>;
> >> +	host1x@50000000 {
> >> +		dpaux@545c0000 {
> >> +			aux-bus {
> >> +				panel: panel {
> >> +					compatible = "auo,b133xtn01";
> >> +					backlight = <&backlight>;
> >> +				};
> >> +			};
> >> +		};
> >>  	};
> >>  
> >>  	mmc@700b0400 { /* SD Card on this bus */
> >> diff --git a/arch/arm/boot/dts/tegra124-nyan-blaze.dts b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> >> index 677babde6460..abdf4456826f 100644
> >> --- a/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> >> +++ b/arch/arm/boot/dts/tegra124-nyan-blaze.dts
> >> @@ -15,12 +15,15 @@ / {
> >>  		     "google,nyan-blaze-rev0", "google,nyan-blaze",
> >>  		     "google,nyan", "nvidia,tegra124";
> >>  
> >> -	panel: panel {
> >> -		compatible = "samsung,ltn140at29-301";
> >> -
> >> -		power-supply = <&vdd_3v3_panel>;
> >> -		backlight = <&backlight>;
> >> -		ddc-i2c-bus = <&dpaux>;
> >> +	host1x@50000000 {
> >> +		dpaux@545c0000 {
> >> +			aux-bus {
> >> +				panel: panel {
> >> +					compatible = "samsung,ltn140at29-301";
> >> +					backlight = <&backlight>;
> >> +				};
> >> +			};
> >> +		};
> >>  	};
> >>  
> >>  	sound {
> >> diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
> >> index 232c90604df9..6a9592ceb5f2 100644
> >> --- a/arch/arm/boot/dts/tegra124-venice2.dts
> >> +++ b/arch/arm/boot/dts/tegra124-venice2.dts
> >> @@ -48,6 +48,13 @@ sor@54540000 {
> >>  		dpaux@545c0000 {
> >>  			vdd-supply = <&vdd_3v3_panel>;
> >>  			status = "okay";
> >> +
> >> +			aux-bus {
> >> +				panel: panel {
> >> +					compatible = "lg,lp129qe";
> >> +					backlight = <&backlight>;
> >> +				};
> >> +			};
> >>  		};
> >>  	};
> >>  
> >> @@ -1080,13 +1087,6 @@ power {
> >>  		};
> >>  	};
> >>  
> >> -	panel: panel {
> >> -		compatible = "lg,lp129qe";
> >> -		power-supply = <&vdd_3v3_panel>;
> >> -		backlight = <&backlight>;
> >> -		ddc-i2c-bus = <&dpaux>;
> >> -	};
> >> -
> >>  	vdd_mux: regulator-mux {
> >>  		compatible = "regulator-fixed";
> >>  		regulator-name = "+VDD_MUX";
> >>
> > 
> > You should add stable tag for 5.15 and also add separate patch to update
> > the new arch/arm/boot/dts/tegra124-nyan-big-fhd.dts which we have in
> > -next now.
> 
> Thierry, are you going to address this review comment? I see in
> linux-next that you picked up this incomplete version of the patch.

Ah, shoot. I've got this in my local tree but forgot to squash this in
with the other changes. I'll send out a follow-up.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Doug Anderson]

Hi,

On Mon, Dec 20, 2021 at 2:49 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> From: Thierry Reding <treding@nvidia.com>
>
> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
> AUX bus device tree node. This allows us to avoid a nasty circular
> dependency that would otherwise be created between the DPAUX and panel
> nodes via the DDC/I2C phandle.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>  3 files changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
> index 1d2aac2cb6d0..fdc1d64dfff9 100644
> --- a/arch/arm/boot/dts/tegra124-nyan-big.dts
> +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
> @@ -13,12 +13,15 @@ / {
>                      "google,nyan-big-rev1", "google,nyan-big-rev0",
>                      "google,nyan-big", "google,nyan", "nvidia,tegra124";
>
> -       panel: panel {
> -               compatible = "auo,b133xtn01";
> -
> -               power-supply = <&vdd_3v3_panel>;

You remove the "power-supply" line here but don't add it below. Isn't
that a problem? power-supply for the panel is listed as "required" in
the panel dt bindings so I presume this will increase validation
warnings?


> -               backlight = <&backlight>;
> -               ddc-i2c-bus = <&dpaux>;
> +       host1x@50000000 {
> +               dpaux@545c0000 {

Optional nit: on other SoC dts files I've always had the policy to try
to avoid replicating hierarchies like this (host1x@50000000 =>
dpaux@545c0000). Instead I'd express this as:

&dpaux {
  aux-bux {
    panel: panel {
      ...
    };
  };
};


> +                       aux-bus {
> +                               panel: panel {
> +                                       compatible = "auo,b133xtn01";
> +                                       backlight = <&backlight>;

nit: In theory the "backlight" could go in tegra124-nyan.dtsi, right?
Then you just need to override the compatible...


-Doug

Re: [PATCH 2/2] ARM: tegra: Move panels to AUX bus

[Doug Anderson]

Hi,

On Mon, Dec 20, 2021 at 2:49 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> From: Thierry Reding <treding@nvidia.com>
>
> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
> AUX bus device tree node. This allows us to avoid a nasty circular
> dependency that would otherwise be created between the DPAUX and panel
> nodes via the DDC/I2C phandle.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>  3 files changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts b/arch/arm/boot/dts/tegra124-nyan-big.dts
> index 1d2aac2cb6d0..fdc1d64dfff9 100644
> --- a/arch/arm/boot/dts/tegra124-nyan-big.dts
> +++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
> @@ -13,12 +13,15 @@ / {
>                      "google,nyan-big-rev1", "google,nyan-big-rev0",
>                      "google,nyan-big", "google,nyan", "nvidia,tegra124";
>
> -       panel: panel {
> -               compatible = "auo,b133xtn01";
> -
> -               power-supply = <&vdd_3v3_panel>;

You remove the "power-supply" line here but don't add it below. Isn't
that a problem? power-supply for the panel is listed as "required" in
the panel dt bindings so I presume this will increase validation
warnings?


> -               backlight = <&backlight>;
> -               ddc-i2c-bus = <&dpaux>;
> +       host1x@50000000 {
> +               dpaux@545c0000 {

Optional nit: on other SoC dts files I've always had the policy to try
to avoid replicating hierarchies like this (host1x@50000000 =>
dpaux@545c0000). Instead I'd express this as:

&dpaux {
  aux-bux {
    panel: panel {
      ...
    };
  };
};


> +                       aux-bus {
> +                               panel: panel {
> +                                       compatible = "auo,b133xtn01";
> +                                       backlight = <&backlight>;

nit: In theory the "backlight" could go in tegra124-nyan.dtsi, right?
Then you just need to override the compatible...


-Doug

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
> 
> Hi,
> 
> this is an alternative proposal to fix panel support on Venice 2 and
> Nyan. Dmitry had proposed a different solution that involved reverting
> the I2C/DDC registration order and would complicate things by breaking
> the encapsulation of the driver by introducing a global (though locally
> scoped) variable[0].
> 
> This set of patches avoids that by using the recently introduced DP AUX
> bus infrastructure. The result is that the changes are actually less
> intrusive and not a step back. Instead they nicely remove the circular
> dependency that previously existed and caused these issues in the first
> place.
> 
> To be fair, this is not perfect either because it requires a device tree
> change and hence isn't technically backwards-compatible. However, given
> that the original device tree was badly broken in the first place, I
> think we can make an exception, especially since it is not generally a
> problem to update device trees on the affected devices.
> 
> Secondly, this relies on infrastructure that was introduced in v5.15 and
> therefore will be difficult to backport beyond that. However, since this
> functionality has been broken since v5.13 and all of the kernel versions
> between that and v5.15 are EOL anyway, there isn't much that we can do
> to fix the interim versions anyway.
> 
> Adding Doug and Laurent since they originally designed the AUX bus
> patches in case they see anything in here that would be objectionable.
> 
> Thierry
> 
> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> 
> Thierry Reding (2):
>   drm/tegra: dpaux: Populate AUX bus
>   ARM: tegra: Move panels to AUX bus
> 
>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>  5 files changed, 33 insertions(+), 19 deletions(-)
> 

It should "work" since you removed the ddc-i2c-bus phandle from the
panel nodes, and thus, panel->ddc won't be used during panel-edp driver
probe. But this looks like a hack rather than a fix.

I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
should be relevant here. The drm_dp_aux_register() still should to
invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
panel->ddc adapter won't be registered.

The panel->ddc isn't used by the new panel-edp driver unless panel is
compatible with "edp-panel". Hence the generic_edp_panel_probe() should
either fail or crash for a such "edp-panel" since panel->ddc isn't fully
instantiated, AFAICS.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
> 
> Hi,
> 
> this is an alternative proposal to fix panel support on Venice 2 and
> Nyan. Dmitry had proposed a different solution that involved reverting
> the I2C/DDC registration order and would complicate things by breaking
> the encapsulation of the driver by introducing a global (though locally
> scoped) variable[0].
> 
> This set of patches avoids that by using the recently introduced DP AUX
> bus infrastructure. The result is that the changes are actually less
> intrusive and not a step back. Instead they nicely remove the circular
> dependency that previously existed and caused these issues in the first
> place.
> 
> To be fair, this is not perfect either because it requires a device tree
> change and hence isn't technically backwards-compatible. However, given
> that the original device tree was badly broken in the first place, I
> think we can make an exception, especially since it is not generally a
> problem to update device trees on the affected devices.
> 
> Secondly, this relies on infrastructure that was introduced in v5.15 and
> therefore will be difficult to backport beyond that. However, since this
> functionality has been broken since v5.13 and all of the kernel versions
> between that and v5.15 are EOL anyway, there isn't much that we can do
> to fix the interim versions anyway.
> 
> Adding Doug and Laurent since they originally designed the AUX bus
> patches in case they see anything in here that would be objectionable.
> 
> Thierry
> 
> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> 
> Thierry Reding (2):
>   drm/tegra: dpaux: Populate AUX bus
>   ARM: tegra: Move panels to AUX bus
> 
>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>  5 files changed, 33 insertions(+), 19 deletions(-)
> 

It should "work" since you removed the ddc-i2c-bus phandle from the
panel nodes, and thus, panel->ddc won't be used during panel-edp driver
probe. But this looks like a hack rather than a fix.

I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
should be relevant here. The drm_dp_aux_register() still should to
invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
panel->ddc adapter won't be registered.

The panel->ddc isn't used by the new panel-edp driver unless panel is
compatible with "edp-panel". Hence the generic_edp_panel_probe() should
either fail or crash for a such "edp-panel" since panel->ddc isn't fully
instantiated, AFAICS.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]

On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
> 20.12.2021 13:48, Thierry Reding пишет:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > Hi,
> > 
> > this is an alternative proposal to fix panel support on Venice 2 and
> > Nyan. Dmitry had proposed a different solution that involved reverting
> > the I2C/DDC registration order and would complicate things by breaking
> > the encapsulation of the driver by introducing a global (though locally
> > scoped) variable[0].
> > 
> > This set of patches avoids that by using the recently introduced DP AUX
> > bus infrastructure. The result is that the changes are actually less
> > intrusive and not a step back. Instead they nicely remove the circular
> > dependency that previously existed and caused these issues in the first
> > place.
> > 
> > To be fair, this is not perfect either because it requires a device tree
> > change and hence isn't technically backwards-compatible. However, given
> > that the original device tree was badly broken in the first place, I
> > think we can make an exception, especially since it is not generally a
> > problem to update device trees on the affected devices.
> > 
> > Secondly, this relies on infrastructure that was introduced in v5.15 and
> > therefore will be difficult to backport beyond that. However, since this
> > functionality has been broken since v5.13 and all of the kernel versions
> > between that and v5.15 are EOL anyway, there isn't much that we can do
> > to fix the interim versions anyway.
> > 
> > Adding Doug and Laurent since they originally designed the AUX bus
> > patches in case they see anything in here that would be objectionable.
> > 
> > Thierry
> > 
> > [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> > 
> > Thierry Reding (2):
> >   drm/tegra: dpaux: Populate AUX bus
> >   ARM: tegra: Move panels to AUX bus
> > 
> >  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
> >  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
> >  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
> >  drivers/gpu/drm/tegra/Kconfig             |  1 +
> >  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
> >  5 files changed, 33 insertions(+), 19 deletions(-)
> > 
> 
> It should "work" since you removed the ddc-i2c-bus phandle from the
> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
> probe. But this looks like a hack rather than a fix.

The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
not specified. And that makes perfect sense because we'd basically just
be pointing back to the AUX node anyway.

> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
> should be relevant here. The drm_dp_aux_register() still should to
> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
> panel->ddc adapter won't be registered.

drm_dp_aux_register() is only needed to expose the device to userspace
and make the I2C adapter available to the rest of the system. But since
we already know the AUX and I2C adapter, we can use it directly without
doing a separate lookup. drm_dp_aux_init() should be enough to set the
adapter up to work for what we need.

See also the kerneldoc for drm_dp_aux_register() where this is described
in a bit more detail.

> The panel->ddc isn't used by the new panel-edp driver unless panel is
> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> instantiated, AFAICS.

I've tested this and it works fine on Venice 2. Since that was the
reference design for Nyan, I suspect that Nyan's will also work.

It'd be great if Thomas or anyone else with access to a Nyan could
test this to verify that.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]

On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
> 20.12.2021 13:48, Thierry Reding пишет:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > Hi,
> > 
> > this is an alternative proposal to fix panel support on Venice 2 and
> > Nyan. Dmitry had proposed a different solution that involved reverting
> > the I2C/DDC registration order and would complicate things by breaking
> > the encapsulation of the driver by introducing a global (though locally
> > scoped) variable[0].
> > 
> > This set of patches avoids that by using the recently introduced DP AUX
> > bus infrastructure. The result is that the changes are actually less
> > intrusive and not a step back. Instead they nicely remove the circular
> > dependency that previously existed and caused these issues in the first
> > place.
> > 
> > To be fair, this is not perfect either because it requires a device tree
> > change and hence isn't technically backwards-compatible. However, given
> > that the original device tree was badly broken in the first place, I
> > think we can make an exception, especially since it is not generally a
> > problem to update device trees on the affected devices.
> > 
> > Secondly, this relies on infrastructure that was introduced in v5.15 and
> > therefore will be difficult to backport beyond that. However, since this
> > functionality has been broken since v5.13 and all of the kernel versions
> > between that and v5.15 are EOL anyway, there isn't much that we can do
> > to fix the interim versions anyway.
> > 
> > Adding Doug and Laurent since they originally designed the AUX bus
> > patches in case they see anything in here that would be objectionable.
> > 
> > Thierry
> > 
> > [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> > 
> > Thierry Reding (2):
> >   drm/tegra: dpaux: Populate AUX bus
> >   ARM: tegra: Move panels to AUX bus
> > 
> >  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
> >  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
> >  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
> >  drivers/gpu/drm/tegra/Kconfig             |  1 +
> >  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
> >  5 files changed, 33 insertions(+), 19 deletions(-)
> > 
> 
> It should "work" since you removed the ddc-i2c-bus phandle from the
> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
> probe. But this looks like a hack rather than a fix.

The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
not specified. And that makes perfect sense because we'd basically just
be pointing back to the AUX node anyway.

> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
> should be relevant here. The drm_dp_aux_register() still should to
> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
> panel->ddc adapter won't be registered.

drm_dp_aux_register() is only needed to expose the device to userspace
and make the I2C adapter available to the rest of the system. But since
we already know the AUX and I2C adapter, we can use it directly without
doing a separate lookup. drm_dp_aux_init() should be enough to set the
adapter up to work for what we need.

See also the kerneldoc for drm_dp_aux_register() where this is described
in a bit more detail.

> The panel->ddc isn't used by the new panel-edp driver unless panel is
> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> instantiated, AFAICS.

I've tested this and it works fine on Venice 2. Since that was the
reference design for Nyan, I suspect that Nyan's will also work.

It'd be great if Thomas or anyone else with access to a Nyan could
test this to verify that.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 18:27, Thierry Reding пишет:
> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
>> 20.12.2021 13:48, Thierry Reding пишет:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> Hi,
>>>
>>> this is an alternative proposal to fix panel support on Venice 2 and
>>> Nyan. Dmitry had proposed a different solution that involved reverting
>>> the I2C/DDC registration order and would complicate things by breaking
>>> the encapsulation of the driver by introducing a global (though locally
>>> scoped) variable[0].
>>>
>>> This set of patches avoids that by using the recently introduced DP AUX
>>> bus infrastructure. The result is that the changes are actually less
>>> intrusive and not a step back. Instead they nicely remove the circular
>>> dependency that previously existed and caused these issues in the first
>>> place.
>>>
>>> To be fair, this is not perfect either because it requires a device tree
>>> change and hence isn't technically backwards-compatible. However, given
>>> that the original device tree was badly broken in the first place, I
>>> think we can make an exception, especially since it is not generally a
>>> problem to update device trees on the affected devices.
>>>
>>> Secondly, this relies on infrastructure that was introduced in v5.15 and
>>> therefore will be difficult to backport beyond that. However, since this
>>> functionality has been broken since v5.13 and all of the kernel versions
>>> between that and v5.15 are EOL anyway, there isn't much that we can do
>>> to fix the interim versions anyway.
>>>
>>> Adding Doug and Laurent since they originally designed the AUX bus
>>> patches in case they see anything in here that would be objectionable.
>>>
>>> Thierry
>>>
>>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
>>>
>>> Thierry Reding (2):
>>>   drm/tegra: dpaux: Populate AUX bus
>>>   ARM: tegra: Move panels to AUX bus
>>>
>>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>>>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>>>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>>>  5 files changed, 33 insertions(+), 19 deletions(-)
>>>
>>
>> It should "work" since you removed the ddc-i2c-bus phandle from the
>> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
>> probe. But this looks like a hack rather than a fix.
> 
> The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
> not specified. And that makes perfect sense because we'd basically just
> be pointing back to the AUX node anyway.
> 
>> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
>> should be relevant here. The drm_dp_aux_register() still should to
>> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
>> panel->ddc adapter won't be registered.
> 
> drm_dp_aux_register() is only needed to expose the device to userspace
> and make the I2C adapter available to the rest of the system. But since
> we already know the AUX and I2C adapter, we can use it directly without
> doing a separate lookup. drm_dp_aux_init() should be enough to set the
> adapter up to work for what we need.
> 
> See also the kerneldoc for drm_dp_aux_register() where this is described
> in a bit more detail.

Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
DDC will work properly anyways with that on v5.16.

But the aux-bus usage still is irrelevant for the fix. Let's not use it
then.

>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>> instantiated, AFAICS.
> 
> I've tested this and it works fine on Venice 2. Since that was the
> reference design for Nyan, I suspect that Nyan's will also work.
> 
> It'd be great if Thomas or anyone else with access to a Nyan could
> test this to verify that.

There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
2023, hence we need to either use:

Approach #1:

1. apply my variant of the fix
2. backport it to v5.15
3. apply your variant without aux-bus, replacing my fix on 5.16+

Or

Approach #2:

1. remove ddc-i2c-bus phandles in DTs
2. backport (?) it to v5.15
3. apply your variant without aux-bus

Or

Approach #3:

1. ignore v5.15 and keep it screwed
2. apply your variant as is

Which approach will you prefer?

I'm not happy that older DTBs will be broken. Can we do better about it?

Is it possible to patch DT in the code by removing the ddc-i2c-bus phandle?

Or can we patch panel-simple on 5.15 and panel-edp on 5.16, making these
drivers to skip ddc-i2c-bus on Tegra+eDP? The eDP driver fixup will be
trivial, fixing older panel-simple will be more invasive.

I think the best solution will be to use Approach #1 and in the end
complete it with this panel-edp workaround below. This approach will
have minimal code impact on 5.16+ kernels and will keep older DTBs
working. Are you okay with this?

diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 176ef0c3cc1d..4e5b84324659 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -793,7 +793,11 @@ static int panel_edp_probe(struct device *dev,
const struct panel_desc *desc,
 		return err;
 	}

-	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
+	if (of_machine_is_compatible("nvidia,tegra124"))
+		ddc = NULL;
+	else
+		ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
+
 	if (ddc) {
 		panel->ddc = of_find_i2c_adapter_by_node(ddc);
 		of_node_put(ddc);

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 18:27, Thierry Reding пишет:
> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
>> 20.12.2021 13:48, Thierry Reding пишет:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> Hi,
>>>
>>> this is an alternative proposal to fix panel support on Venice 2 and
>>> Nyan. Dmitry had proposed a different solution that involved reverting
>>> the I2C/DDC registration order and would complicate things by breaking
>>> the encapsulation of the driver by introducing a global (though locally
>>> scoped) variable[0].
>>>
>>> This set of patches avoids that by using the recently introduced DP AUX
>>> bus infrastructure. The result is that the changes are actually less
>>> intrusive and not a step back. Instead they nicely remove the circular
>>> dependency that previously existed and caused these issues in the first
>>> place.
>>>
>>> To be fair, this is not perfect either because it requires a device tree
>>> change and hence isn't technically backwards-compatible. However, given
>>> that the original device tree was badly broken in the first place, I
>>> think we can make an exception, especially since it is not generally a
>>> problem to update device trees on the affected devices.
>>>
>>> Secondly, this relies on infrastructure that was introduced in v5.15 and
>>> therefore will be difficult to backport beyond that. However, since this
>>> functionality has been broken since v5.13 and all of the kernel versions
>>> between that and v5.15 are EOL anyway, there isn't much that we can do
>>> to fix the interim versions anyway.
>>>
>>> Adding Doug and Laurent since they originally designed the AUX bus
>>> patches in case they see anything in here that would be objectionable.
>>>
>>> Thierry
>>>
>>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
>>>
>>> Thierry Reding (2):
>>>   drm/tegra: dpaux: Populate AUX bus
>>>   ARM: tegra: Move panels to AUX bus
>>>
>>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>>>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>>>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>>>  5 files changed, 33 insertions(+), 19 deletions(-)
>>>
>>
>> It should "work" since you removed the ddc-i2c-bus phandle from the
>> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
>> probe. But this looks like a hack rather than a fix.
> 
> The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
> not specified. And that makes perfect sense because we'd basically just
> be pointing back to the AUX node anyway.
> 
>> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
>> should be relevant here. The drm_dp_aux_register() still should to
>> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
>> panel->ddc adapter won't be registered.
> 
> drm_dp_aux_register() is only needed to expose the device to userspace
> and make the I2C adapter available to the rest of the system. But since
> we already know the AUX and I2C adapter, we can use it directly without
> doing a separate lookup. drm_dp_aux_init() should be enough to set the
> adapter up to work for what we need.
> 
> See also the kerneldoc for drm_dp_aux_register() where this is described
> in a bit more detail.

Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
DDC will work properly anyways with that on v5.16.

But the aux-bus usage still is irrelevant for the fix. Let's not use it
then.

>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>> instantiated, AFAICS.
> 
> I've tested this and it works fine on Venice 2. Since that was the
> reference design for Nyan, I suspect that Nyan's will also work.
> 
> It'd be great if Thomas or anyone else with access to a Nyan could
> test this to verify that.

There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
2023, hence we need to either use:

Approach #1:

1. apply my variant of the fix
2. backport it to v5.15
3. apply your variant without aux-bus, replacing my fix on 5.16+

Or

Approach #2:

1. remove ddc-i2c-bus phandles in DTs
2. backport (?) it to v5.15
3. apply your variant without aux-bus

Or

Approach #3:

1. ignore v5.15 and keep it screwed
2. apply your variant as is

Which approach will you prefer?

I'm not happy that older DTBs will be broken. Can we do better about it?

Is it possible to patch DT in the code by removing the ddc-i2c-bus phandle?

Or can we patch panel-simple on 5.15 and panel-edp on 5.16, making these
drivers to skip ddc-i2c-bus on Tegra+eDP? The eDP driver fixup will be
trivial, fixing older panel-simple will be more invasive.

I think the best solution will be to use Approach #1 and in the end
complete it with this panel-edp workaround below. This approach will
have minimal code impact on 5.16+ kernels and will keep older DTBs
working. Are you okay with this?

diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 176ef0c3cc1d..4e5b84324659 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -793,7 +793,11 @@ static int panel_edp_probe(struct device *dev,
const struct panel_desc *desc,
 		return err;
 	}

-	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
+	if (of_machine_is_compatible("nvidia,tegra124"))
+		ddc = NULL;
+	else
+		ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
+
 	if (ddc) {
 		panel->ddc = of_find_i2c_adapter_by_node(ddc);
 		of_node_put(ddc);

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 19:12, Dmitry Osipenko пишет:
> 20.12.2021 18:27, Thierry Reding пишет:
>> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
>>> 20.12.2021 13:48, Thierry Reding пишет:
>>>> From: Thierry Reding <treding@nvidia.com>
>>>>
>>>> Hi,
>>>>
>>>> this is an alternative proposal to fix panel support on Venice 2 and
>>>> Nyan. Dmitry had proposed a different solution that involved reverting
>>>> the I2C/DDC registration order and would complicate things by breaking
>>>> the encapsulation of the driver by introducing a global (though locally
>>>> scoped) variable[0].
>>>>
>>>> This set of patches avoids that by using the recently introduced DP AUX
>>>> bus infrastructure. The result is that the changes are actually less
>>>> intrusive and not a step back. Instead they nicely remove the circular
>>>> dependency that previously existed and caused these issues in the first
>>>> place.
>>>>
>>>> To be fair, this is not perfect either because it requires a device tree
>>>> change and hence isn't technically backwards-compatible. However, given
>>>> that the original device tree was badly broken in the first place, I
>>>> think we can make an exception, especially since it is not generally a
>>>> problem to update device trees on the affected devices.
>>>>
>>>> Secondly, this relies on infrastructure that was introduced in v5.15 and
>>>> therefore will be difficult to backport beyond that. However, since this
>>>> functionality has been broken since v5.13 and all of the kernel versions
>>>> between that and v5.15 are EOL anyway, there isn't much that we can do
>>>> to fix the interim versions anyway.
>>>>
>>>> Adding Doug and Laurent since they originally designed the AUX bus
>>>> patches in case they see anything in here that would be objectionable.
>>>>
>>>> Thierry
>>>>
>>>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
>>>>
>>>> Thierry Reding (2):
>>>>   drm/tegra: dpaux: Populate AUX bus
>>>>   ARM: tegra: Move panels to AUX bus
>>>>
>>>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>>>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>>>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>>>>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>>>>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>>>>  5 files changed, 33 insertions(+), 19 deletions(-)
>>>>
>>>
>>> It should "work" since you removed the ddc-i2c-bus phandle from the
>>> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
>>> probe. But this looks like a hack rather than a fix.
>>
>> The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
>> not specified. And that makes perfect sense because we'd basically just
>> be pointing back to the AUX node anyway.
>>
>>> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
>>> should be relevant here. The drm_dp_aux_register() still should to
>>> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
>>> panel->ddc adapter won't be registered.
>>
>> drm_dp_aux_register() is only needed to expose the device to userspace
>> and make the I2C adapter available to the rest of the system. But since
>> we already know the AUX and I2C adapter, we can use it directly without
>> doing a separate lookup. drm_dp_aux_init() should be enough to set the
>> adapter up to work for what we need.
>>
>> See also the kerneldoc for drm_dp_aux_register() where this is described
>> in a bit more detail.
> 
> Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
> DDC will work properly anyways with that on v5.16.
> 
> But the aux-bus usage still is irrelevant for the fix. Let's not use it
> then.
> 
>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>> instantiated, AFAICS.
>>
>> I've tested this and it works fine on Venice 2. Since that was the
>> reference design for Nyan, I suspect that Nyan's will also work.
>>
>> It'd be great if Thomas or anyone else with access to a Nyan could
>> test this to verify that.
> 
> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> 2023, hence we need to either use:
> 
> Approach #1:
> 
> 1. apply my variant of the fix
> 2. backport it to v5.15
> 3. apply your variant without aux-bus, replacing my fix on 5.16+

Although, I see that it doesn't make much sense to say "your variant
without aux-bus". "Remove ddc-i2c-bus phandles from DTs" will be better.

> Or
> 
> Approach #2:
> 
> 1. remove ddc-i2c-bus phandles in DTs
> 2. backport (?) it to v5.15
> 3. apply your variant without aux-bus
> 
> Or
> 
> Approach #3:
> 
> 1. ignore v5.15 and keep it screwed
> 2. apply your variant as is
> 
> Which approach will you prefer?
> 
> I'm not happy that older DTBs will be broken. Can we do better about it?
> 
> Is it possible to patch DT in the code by removing the ddc-i2c-bus phandle?
> 
> Or can we patch panel-simple on 5.15 and panel-edp on 5.16, making these
> drivers to skip ddc-i2c-bus on Tegra+eDP? The eDP driver fixup will be
> trivial, fixing older panel-simple will be more invasive.
> 
> I think the best solution will be to use Approach #1 and in the end
> complete it with this panel-edp workaround below. This approach will
> have minimal code impact on 5.16+ kernels and will keep older DTBs
> working. Are you okay with this?
> 
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 176ef0c3cc1d..4e5b84324659 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -793,7 +793,11 @@ static int panel_edp_probe(struct device *dev,
> const struct panel_desc *desc,
>  		return err;
>  	}
> 
> -	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
> +	if (of_machine_is_compatible("nvidia,tegra124"))
> +		ddc = NULL;
> +	else
> +		ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
> +
>  	if (ddc) {
>  		panel->ddc = of_find_i2c_adapter_by_node(ddc);
>  		of_node_put(ddc);
> 

Another alternative that may work is to check whether ddc-i2c-bus and
DPAUX use the same node.

diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 176ef0c3cc1d..c8cf5bc3d148 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -794,7 +794,7 @@ static int panel_edp_probe(struct device *dev, const
struct panel_desc *desc,
 	}

 	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
-	if (ddc) {
+	if (ddc && ddc != aux->dev->of_node) {
 		panel->ddc = of_find_i2c_adapter_by_node(ddc);
 		of_node_put(ddc);

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 19:12, Dmitry Osipenko пишет:
> 20.12.2021 18:27, Thierry Reding пишет:
>> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
>>> 20.12.2021 13:48, Thierry Reding пишет:
>>>> From: Thierry Reding <treding@nvidia.com>
>>>>
>>>> Hi,
>>>>
>>>> this is an alternative proposal to fix panel support on Venice 2 and
>>>> Nyan. Dmitry had proposed a different solution that involved reverting
>>>> the I2C/DDC registration order and would complicate things by breaking
>>>> the encapsulation of the driver by introducing a global (though locally
>>>> scoped) variable[0].
>>>>
>>>> This set of patches avoids that by using the recently introduced DP AUX
>>>> bus infrastructure. The result is that the changes are actually less
>>>> intrusive and not a step back. Instead they nicely remove the circular
>>>> dependency that previously existed and caused these issues in the first
>>>> place.
>>>>
>>>> To be fair, this is not perfect either because it requires a device tree
>>>> change and hence isn't technically backwards-compatible. However, given
>>>> that the original device tree was badly broken in the first place, I
>>>> think we can make an exception, especially since it is not generally a
>>>> problem to update device trees on the affected devices.
>>>>
>>>> Secondly, this relies on infrastructure that was introduced in v5.15 and
>>>> therefore will be difficult to backport beyond that. However, since this
>>>> functionality has been broken since v5.13 and all of the kernel versions
>>>> between that and v5.15 are EOL anyway, there isn't much that we can do
>>>> to fix the interim versions anyway.
>>>>
>>>> Adding Doug and Laurent since they originally designed the AUX bus
>>>> patches in case they see anything in here that would be objectionable.
>>>>
>>>> Thierry
>>>>
>>>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
>>>>
>>>> Thierry Reding (2):
>>>>   drm/tegra: dpaux: Populate AUX bus
>>>>   ARM: tegra: Move panels to AUX bus
>>>>
>>>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>>>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>>>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>>>>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>>>>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>>>>  5 files changed, 33 insertions(+), 19 deletions(-)
>>>>
>>>
>>> It should "work" since you removed the ddc-i2c-bus phandle from the
>>> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
>>> probe. But this looks like a hack rather than a fix.
>>
>> The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
>> not specified. And that makes perfect sense because we'd basically just
>> be pointing back to the AUX node anyway.
>>
>>> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
>>> should be relevant here. The drm_dp_aux_register() still should to
>>> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
>>> panel->ddc adapter won't be registered.
>>
>> drm_dp_aux_register() is only needed to expose the device to userspace
>> and make the I2C adapter available to the rest of the system. But since
>> we already know the AUX and I2C adapter, we can use it directly without
>> doing a separate lookup. drm_dp_aux_init() should be enough to set the
>> adapter up to work for what we need.
>>
>> See also the kerneldoc for drm_dp_aux_register() where this is described
>> in a bit more detail.
> 
> Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
> DDC will work properly anyways with that on v5.16.
> 
> But the aux-bus usage still is irrelevant for the fix. Let's not use it
> then.
> 
>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>> instantiated, AFAICS.
>>
>> I've tested this and it works fine on Venice 2. Since that was the
>> reference design for Nyan, I suspect that Nyan's will also work.
>>
>> It'd be great if Thomas or anyone else with access to a Nyan could
>> test this to verify that.
> 
> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> 2023, hence we need to either use:
> 
> Approach #1:
> 
> 1. apply my variant of the fix
> 2. backport it to v5.15
> 3. apply your variant without aux-bus, replacing my fix on 5.16+

Although, I see that it doesn't make much sense to say "your variant
without aux-bus". "Remove ddc-i2c-bus phandles from DTs" will be better.

> Or
> 
> Approach #2:
> 
> 1. remove ddc-i2c-bus phandles in DTs
> 2. backport (?) it to v5.15
> 3. apply your variant without aux-bus
> 
> Or
> 
> Approach #3:
> 
> 1. ignore v5.15 and keep it screwed
> 2. apply your variant as is
> 
> Which approach will you prefer?
> 
> I'm not happy that older DTBs will be broken. Can we do better about it?
> 
> Is it possible to patch DT in the code by removing the ddc-i2c-bus phandle?
> 
> Or can we patch panel-simple on 5.15 and panel-edp on 5.16, making these
> drivers to skip ddc-i2c-bus on Tegra+eDP? The eDP driver fixup will be
> trivial, fixing older panel-simple will be more invasive.
> 
> I think the best solution will be to use Approach #1 and in the end
> complete it with this panel-edp workaround below. This approach will
> have minimal code impact on 5.16+ kernels and will keep older DTBs
> working. Are you okay with this?
> 
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 176ef0c3cc1d..4e5b84324659 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -793,7 +793,11 @@ static int panel_edp_probe(struct device *dev,
> const struct panel_desc *desc,
>  		return err;
>  	}
> 
> -	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
> +	if (of_machine_is_compatible("nvidia,tegra124"))
> +		ddc = NULL;
> +	else
> +		ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
> +
>  	if (ddc) {
>  		panel->ddc = of_find_i2c_adapter_by_node(ddc);
>  		of_node_put(ddc);
> 

Another alternative that may work is to check whether ddc-i2c-bus and
DPAUX use the same node.

diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 176ef0c3cc1d..c8cf5bc3d148 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -794,7 +794,7 @@ static int panel_edp_probe(struct device *dev, const
struct panel_desc *desc,
 	}

 	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
-	if (ddc) {
+	if (ddc && ddc != aux->dev->of_node) {
 		panel->ddc = of_find_i2c_adapter_by_node(ddc);
 		of_node_put(ddc);

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 19:55, Dmitry Osipenko пишет:
> 20.12.2021 19:12, Dmitry Osipenko пишет:
>> 20.12.2021 18:27, Thierry Reding пишет:
>>> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
>>>> 20.12.2021 13:48, Thierry Reding пишет:
>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>
>>>>> Hi,
>>>>>
>>>>> this is an alternative proposal to fix panel support on Venice 2 and
>>>>> Nyan. Dmitry had proposed a different solution that involved reverting
>>>>> the I2C/DDC registration order and would complicate things by breaking
>>>>> the encapsulation of the driver by introducing a global (though locally
>>>>> scoped) variable[0].
>>>>>
>>>>> This set of patches avoids that by using the recently introduced DP AUX
>>>>> bus infrastructure. The result is that the changes are actually less
>>>>> intrusive and not a step back. Instead they nicely remove the circular
>>>>> dependency that previously existed and caused these issues in the first
>>>>> place.
>>>>>
>>>>> To be fair, this is not perfect either because it requires a device tree
>>>>> change and hence isn't technically backwards-compatible. However, given
>>>>> that the original device tree was badly broken in the first place, I
>>>>> think we can make an exception, especially since it is not generally a
>>>>> problem to update device trees on the affected devices.
>>>>>
>>>>> Secondly, this relies on infrastructure that was introduced in v5.15 and
>>>>> therefore will be difficult to backport beyond that. However, since this
>>>>> functionality has been broken since v5.13 and all of the kernel versions
>>>>> between that and v5.15 are EOL anyway, there isn't much that we can do
>>>>> to fix the interim versions anyway.
>>>>>
>>>>> Adding Doug and Laurent since they originally designed the AUX bus
>>>>> patches in case they see anything in here that would be objectionable.
>>>>>
>>>>> Thierry
>>>>>
>>>>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
>>>>>
>>>>> Thierry Reding (2):
>>>>>   drm/tegra: dpaux: Populate AUX bus
>>>>>   ARM: tegra: Move panels to AUX bus
>>>>>
>>>>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>>>>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>>>>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>>>>>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>>>>>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>>>>>  5 files changed, 33 insertions(+), 19 deletions(-)
>>>>>
>>>>
>>>> It should "work" since you removed the ddc-i2c-bus phandle from the
>>>> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
>>>> probe. But this looks like a hack rather than a fix.
>>>
>>> The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
>>> not specified. And that makes perfect sense because we'd basically just
>>> be pointing back to the AUX node anyway.
>>>
>>>> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
>>>> should be relevant here. The drm_dp_aux_register() still should to
>>>> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
>>>> panel->ddc adapter won't be registered.
>>>
>>> drm_dp_aux_register() is only needed to expose the device to userspace
>>> and make the I2C adapter available to the rest of the system. But since
>>> we already know the AUX and I2C adapter, we can use it directly without
>>> doing a separate lookup. drm_dp_aux_init() should be enough to set the
>>> adapter up to work for what we need.
>>>
>>> See also the kerneldoc for drm_dp_aux_register() where this is described
>>> in a bit more detail.
>>
>> Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
>> DDC will work properly anyways with that on v5.16.
>>
>> But the aux-bus usage still is irrelevant for the fix. Let's not use it
>> then.
>>
>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>> instantiated, AFAICS.
>>>
>>> I've tested this and it works fine on Venice 2. Since that was the
>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>
>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>> test this to verify that.
>>
>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>> 2023, hence we need to either use:
>>
>> Approach #1:
>>
>> 1. apply my variant of the fix
>> 2. backport it to v5.15
>> 3. apply your variant without aux-bus, replacing my fix on 5.16+
> 
> Although, I see that it doesn't make much sense to say "your variant
> without aux-bus". "Remove ddc-i2c-bus phandles from DTs" will be better.
> 
>> Or
>>
>> Approach #2:
>>
>> 1. remove ddc-i2c-bus phandles in DTs
>> 2. backport (?) it to v5.15
>> 3. apply your variant without aux-bus
>>
>> Or
>>
>> Approach #3:
>>
>> 1. ignore v5.15 and keep it screwed
>> 2. apply your variant as is
>>
>> Which approach will you prefer?
>>
>> I'm not happy that older DTBs will be broken. Can we do better about it?
>>
>> Is it possible to patch DT in the code by removing the ddc-i2c-bus phandle?
>>
>> Or can we patch panel-simple on 5.15 and panel-edp on 5.16, making these
>> drivers to skip ddc-i2c-bus on Tegra+eDP? The eDP driver fixup will be
>> trivial, fixing older panel-simple will be more invasive.
>>
>> I think the best solution will be to use Approach #1 and in the end
>> complete it with this panel-edp workaround below. This approach will
>> have minimal code impact on 5.16+ kernels and will keep older DTBs
>> working. Are you okay with this?
>>
>> diff --git a/drivers/gpu/drm/panel/panel-edp.c
>> b/drivers/gpu/drm/panel/panel-edp.c
>> index 176ef0c3cc1d..4e5b84324659 100644
>> --- a/drivers/gpu/drm/panel/panel-edp.c
>> +++ b/drivers/gpu/drm/panel/panel-edp.c
>> @@ -793,7 +793,11 @@ static int panel_edp_probe(struct device *dev,
>> const struct panel_desc *desc,
>>  		return err;
>>  	}
>>
>> -	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
>> +	if (of_machine_is_compatible("nvidia,tegra124"))
>> +		ddc = NULL;
>> +	else
>> +		ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
>> +
>>  	if (ddc) {
>>  		panel->ddc = of_find_i2c_adapter_by_node(ddc);
>>  		of_node_put(ddc);
>>
> 
> Another alternative that may work is to check whether ddc-i2c-bus and
> DPAUX use the same node.
> 
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 176ef0c3cc1d..c8cf5bc3d148 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -794,7 +794,7 @@ static int panel_edp_probe(struct device *dev, const
> struct panel_desc *desc,
>  	}
> 
>  	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
> -	if (ddc) {
> +	if (ddc && ddc != aux->dev->of_node) {
>  		panel->ddc = of_find_i2c_adapter_by_node(ddc);
>  		of_node_put(ddc);
> 

I see now that the aux pointer should be populated only if aux-bus is
used, so this won't work.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 19:55, Dmitry Osipenko пишет:
> 20.12.2021 19:12, Dmitry Osipenko пишет:
>> 20.12.2021 18:27, Thierry Reding пишет:
>>> On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
>>>> 20.12.2021 13:48, Thierry Reding пишет:
>>>>> From: Thierry Reding <treding@nvidia.com>
>>>>>
>>>>> Hi,
>>>>>
>>>>> this is an alternative proposal to fix panel support on Venice 2 and
>>>>> Nyan. Dmitry had proposed a different solution that involved reverting
>>>>> the I2C/DDC registration order and would complicate things by breaking
>>>>> the encapsulation of the driver by introducing a global (though locally
>>>>> scoped) variable[0].
>>>>>
>>>>> This set of patches avoids that by using the recently introduced DP AUX
>>>>> bus infrastructure. The result is that the changes are actually less
>>>>> intrusive and not a step back. Instead they nicely remove the circular
>>>>> dependency that previously existed and caused these issues in the first
>>>>> place.
>>>>>
>>>>> To be fair, this is not perfect either because it requires a device tree
>>>>> change and hence isn't technically backwards-compatible. However, given
>>>>> that the original device tree was badly broken in the first place, I
>>>>> think we can make an exception, especially since it is not generally a
>>>>> problem to update device trees on the affected devices.
>>>>>
>>>>> Secondly, this relies on infrastructure that was introduced in v5.15 and
>>>>> therefore will be difficult to backport beyond that. However, since this
>>>>> functionality has been broken since v5.13 and all of the kernel versions
>>>>> between that and v5.15 are EOL anyway, there isn't much that we can do
>>>>> to fix the interim versions anyway.
>>>>>
>>>>> Adding Doug and Laurent since they originally designed the AUX bus
>>>>> patches in case they see anything in here that would be objectionable.
>>>>>
>>>>> Thierry
>>>>>
>>>>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
>>>>>
>>>>> Thierry Reding (2):
>>>>>   drm/tegra: dpaux: Populate AUX bus
>>>>>   ARM: tegra: Move panels to AUX bus
>>>>>
>>>>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>>>>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>>>>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>>>>>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>>>>>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>>>>>  5 files changed, 33 insertions(+), 19 deletions(-)
>>>>>
>>>>
>>>> It should "work" since you removed the ddc-i2c-bus phandle from the
>>>> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
>>>> probe. But this looks like a hack rather than a fix.
>>>
>>> The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
>>> not specified. And that makes perfect sense because we'd basically just
>>> be pointing back to the AUX node anyway.
>>>
>>>> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
>>>> should be relevant here. The drm_dp_aux_register() still should to
>>>> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
>>>> panel->ddc adapter won't be registered.
>>>
>>> drm_dp_aux_register() is only needed to expose the device to userspace
>>> and make the I2C adapter available to the rest of the system. But since
>>> we already know the AUX and I2C adapter, we can use it directly without
>>> doing a separate lookup. drm_dp_aux_init() should be enough to set the
>>> adapter up to work for what we need.
>>>
>>> See also the kerneldoc for drm_dp_aux_register() where this is described
>>> in a bit more detail.
>>
>> Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
>> DDC will work properly anyways with that on v5.16.
>>
>> But the aux-bus usage still is irrelevant for the fix. Let's not use it
>> then.
>>
>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>> instantiated, AFAICS.
>>>
>>> I've tested this and it works fine on Venice 2. Since that was the
>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>
>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>> test this to verify that.
>>
>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>> 2023, hence we need to either use:
>>
>> Approach #1:
>>
>> 1. apply my variant of the fix
>> 2. backport it to v5.15
>> 3. apply your variant without aux-bus, replacing my fix on 5.16+
> 
> Although, I see that it doesn't make much sense to say "your variant
> without aux-bus". "Remove ddc-i2c-bus phandles from DTs" will be better.
> 
>> Or
>>
>> Approach #2:
>>
>> 1. remove ddc-i2c-bus phandles in DTs
>> 2. backport (?) it to v5.15
>> 3. apply your variant without aux-bus
>>
>> Or
>>
>> Approach #3:
>>
>> 1. ignore v5.15 and keep it screwed
>> 2. apply your variant as is
>>
>> Which approach will you prefer?
>>
>> I'm not happy that older DTBs will be broken. Can we do better about it?
>>
>> Is it possible to patch DT in the code by removing the ddc-i2c-bus phandle?
>>
>> Or can we patch panel-simple on 5.15 and panel-edp on 5.16, making these
>> drivers to skip ddc-i2c-bus on Tegra+eDP? The eDP driver fixup will be
>> trivial, fixing older panel-simple will be more invasive.
>>
>> I think the best solution will be to use Approach #1 and in the end
>> complete it with this panel-edp workaround below. This approach will
>> have minimal code impact on 5.16+ kernels and will keep older DTBs
>> working. Are you okay with this?
>>
>> diff --git a/drivers/gpu/drm/panel/panel-edp.c
>> b/drivers/gpu/drm/panel/panel-edp.c
>> index 176ef0c3cc1d..4e5b84324659 100644
>> --- a/drivers/gpu/drm/panel/panel-edp.c
>> +++ b/drivers/gpu/drm/panel/panel-edp.c
>> @@ -793,7 +793,11 @@ static int panel_edp_probe(struct device *dev,
>> const struct panel_desc *desc,
>>  		return err;
>>  	}
>>
>> -	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
>> +	if (of_machine_is_compatible("nvidia,tegra124"))
>> +		ddc = NULL;
>> +	else
>> +		ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
>> +
>>  	if (ddc) {
>>  		panel->ddc = of_find_i2c_adapter_by_node(ddc);
>>  		of_node_put(ddc);
>>
> 
> Another alternative that may work is to check whether ddc-i2c-bus and
> DPAUX use the same node.
> 
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/drivers/gpu/drm/panel/panel-edp.c
> index 176ef0c3cc1d..c8cf5bc3d148 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -794,7 +794,7 @@ static int panel_edp_probe(struct device *dev, const
> struct panel_desc *desc,
>  	}
> 
>  	ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
> -	if (ddc) {
> +	if (ddc && ddc != aux->dev->of_node) {
>  		panel->ddc = of_find_i2c_adapter_by_node(ddc);
>  		of_node_put(ddc);
> 

I see now that the aux pointer should be populated only if aux-bus is
used, so this won't work.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4916 bytes --]

On Mon, Dec 20, 2021 at 07:12:03PM +0300, Dmitry Osipenko wrote:
> 20.12.2021 18:27, Thierry Reding пишет:
> > On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
> >> 20.12.2021 13:48, Thierry Reding пишет:
> >>> From: Thierry Reding <treding@nvidia.com>
> >>>
> >>> Hi,
> >>>
> >>> this is an alternative proposal to fix panel support on Venice 2 and
> >>> Nyan. Dmitry had proposed a different solution that involved reverting
> >>> the I2C/DDC registration order and would complicate things by breaking
> >>> the encapsulation of the driver by introducing a global (though locally
> >>> scoped) variable[0].
> >>>
> >>> This set of patches avoids that by using the recently introduced DP AUX
> >>> bus infrastructure. The result is that the changes are actually less
> >>> intrusive and not a step back. Instead they nicely remove the circular
> >>> dependency that previously existed and caused these issues in the first
> >>> place.
> >>>
> >>> To be fair, this is not perfect either because it requires a device tree
> >>> change and hence isn't technically backwards-compatible. However, given
> >>> that the original device tree was badly broken in the first place, I
> >>> think we can make an exception, especially since it is not generally a
> >>> problem to update device trees on the affected devices.
> >>>
> >>> Secondly, this relies on infrastructure that was introduced in v5.15 and
> >>> therefore will be difficult to backport beyond that. However, since this
> >>> functionality has been broken since v5.13 and all of the kernel versions
> >>> between that and v5.15 are EOL anyway, there isn't much that we can do
> >>> to fix the interim versions anyway.
> >>>
> >>> Adding Doug and Laurent since they originally designed the AUX bus
> >>> patches in case they see anything in here that would be objectionable.
> >>>
> >>> Thierry
> >>>
> >>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> >>>
> >>> Thierry Reding (2):
> >>>   drm/tegra: dpaux: Populate AUX bus
> >>>   ARM: tegra: Move panels to AUX bus
> >>>
> >>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
> >>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
> >>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
> >>>  drivers/gpu/drm/tegra/Kconfig             |  1 +
> >>>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
> >>>  5 files changed, 33 insertions(+), 19 deletions(-)
> >>>
> >>
> >> It should "work" since you removed the ddc-i2c-bus phandle from the
> >> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
> >> probe. But this looks like a hack rather than a fix.
> > 
> > The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
> > not specified. And that makes perfect sense because we'd basically just
> > be pointing back to the AUX node anyway.
> > 
> >> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
> >> should be relevant here. The drm_dp_aux_register() still should to
> >> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
> >> panel->ddc adapter won't be registered.
> > 
> > drm_dp_aux_register() is only needed to expose the device to userspace
> > and make the I2C adapter available to the rest of the system. But since
> > we already know the AUX and I2C adapter, we can use it directly without
> > doing a separate lookup. drm_dp_aux_init() should be enough to set the
> > adapter up to work for what we need.
> > 
> > See also the kerneldoc for drm_dp_aux_register() where this is described
> > in a bit more detail.
> 
> Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
> DDC will work properly anyways with that on v5.16.
> 
> But the aux-bus usage still is irrelevant for the fix. Let's not use it
> then.

Yes, it's completely relevant because it essentially replaces the I2C
DDC. With the AUX bus, the AUX and hence the I2C DDC can be implied from
the bus' parent.

> >> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >> instantiated, AFAICS.
> > 
> > I've tested this and it works fine on Venice 2. Since that was the
> > reference design for Nyan, I suspect that Nyan's will also work.
> > 
> > It'd be great if Thomas or anyone else with access to a Nyan could
> > test this to verify that.
> 
> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> 2023, hence we need to either use:

All the (at least relevant) functionality that is in panel-edp was in
panel-simple before it was moved to panel-edp. I've backported this set
of patches to v5.15 and it works just fine there.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4916 bytes --]

On Mon, Dec 20, 2021 at 07:12:03PM +0300, Dmitry Osipenko wrote:
> 20.12.2021 18:27, Thierry Reding пишет:
> > On Mon, Dec 20, 2021 at 05:45:41PM +0300, Dmitry Osipenko wrote:
> >> 20.12.2021 13:48, Thierry Reding пишет:
> >>> From: Thierry Reding <treding@nvidia.com>
> >>>
> >>> Hi,
> >>>
> >>> this is an alternative proposal to fix panel support on Venice 2 and
> >>> Nyan. Dmitry had proposed a different solution that involved reverting
> >>> the I2C/DDC registration order and would complicate things by breaking
> >>> the encapsulation of the driver by introducing a global (though locally
> >>> scoped) variable[0].
> >>>
> >>> This set of patches avoids that by using the recently introduced DP AUX
> >>> bus infrastructure. The result is that the changes are actually less
> >>> intrusive and not a step back. Instead they nicely remove the circular
> >>> dependency that previously existed and caused these issues in the first
> >>> place.
> >>>
> >>> To be fair, this is not perfect either because it requires a device tree
> >>> change and hence isn't technically backwards-compatible. However, given
> >>> that the original device tree was badly broken in the first place, I
> >>> think we can make an exception, especially since it is not generally a
> >>> problem to update device trees on the affected devices.
> >>>
> >>> Secondly, this relies on infrastructure that was introduced in v5.15 and
> >>> therefore will be difficult to backport beyond that. However, since this
> >>> functionality has been broken since v5.13 and all of the kernel versions
> >>> between that and v5.15 are EOL anyway, there isn't much that we can do
> >>> to fix the interim versions anyway.
> >>>
> >>> Adding Doug and Laurent since they originally designed the AUX bus
> >>> patches in case they see anything in here that would be objectionable.
> >>>
> >>> Thierry
> >>>
> >>> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> >>>
> >>> Thierry Reding (2):
> >>>   drm/tegra: dpaux: Populate AUX bus
> >>>   ARM: tegra: Move panels to AUX bus
> >>>
> >>>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
> >>>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
> >>>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
> >>>  drivers/gpu/drm/tegra/Kconfig             |  1 +
> >>>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
> >>>  5 files changed, 33 insertions(+), 19 deletions(-)
> >>>
> >>
> >> It should "work" since you removed the ddc-i2c-bus phandle from the
> >> panel nodes, and thus, panel->ddc won't be used during panel-edp driver
> >> probe. But this looks like a hack rather than a fix.
> > 
> > The AUX ->ddc will be used for panel->ddc if the ddc-i2c-bus property is
> > not specified. And that makes perfect sense because we'd basically just
> > be pointing back to the AUX node anyway.
> > 
> >> I'm not sure why and how devm_of_dp_aux_populate_ep_devices() usage
> >> should be relevant here. The drm_dp_aux_register() still should to
> >> invoked before devm_of_dp_aux_populate_ep_devices(), otherwise
> >> panel->ddc adapter won't be registered.
> > 
> > drm_dp_aux_register() is only needed to expose the device to userspace
> > and make the I2C adapter available to the rest of the system. But since
> > we already know the AUX and I2C adapter, we can use it directly without
> > doing a separate lookup. drm_dp_aux_init() should be enough to set the
> > adapter up to work for what we need.
> > 
> > See also the kerneldoc for drm_dp_aux_register() where this is described
> > in a bit more detail.
> 
> Alright, so you fixed it by removing the ddc-i2c-bus phandles and I2C
> DDC will work properly anyways with that on v5.16.
> 
> But the aux-bus usage still is irrelevant for the fix. Let's not use it
> then.

Yes, it's completely relevant because it essentially replaces the I2C
DDC. With the AUX bus, the AUX and hence the I2C DDC can be implied from
the bus' parent.

> >> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >> instantiated, AFAICS.
> > 
> > I've tested this and it works fine on Venice 2. Since that was the
> > reference design for Nyan, I suspect that Nyan's will also work.
> > 
> > It'd be great if Thomas or anyone else with access to a Nyan could
> > test this to verify that.
> 
> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> 2023, hence we need to either use:

All the (at least relevant) functionality that is in panel-edp was in
panel-simple before it was moved to panel-edp. I've backported this set
of patches to v5.15 and it works just fine there.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

21.12.2021 13:58, Thierry Reding пишет:
..
>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>> instantiated, AFAICS.
>>>
>>> I've tested this and it works fine on Venice 2. Since that was the
>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>
>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>> test this to verify that.
>>
>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>> 2023, hence we need to either use:
> 
> All the (at least relevant) functionality that is in panel-edp was in
> panel-simple before it was moved to panel-edp. I've backported this set
> of patches to v5.15 and it works just fine there.

Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
Nyan to keep the older DTBs working?

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

21.12.2021 13:58, Thierry Reding пишет:
..
>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>> instantiated, AFAICS.
>>>
>>> I've tested this and it works fine on Venice 2. Since that was the
>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>
>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>> test this to verify that.
>>
>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>> 2023, hence we need to either use:
> 
> All the (at least relevant) functionality that is in panel-edp was in
> panel-simple before it was moved to panel-edp. I've backported this set
> of patches to v5.15 and it works just fine there.

Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
Nyan to keep the older DTBs working?

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> 21.12.2021 13:58, Thierry Reding пишет:
> ..
> >>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >>>> instantiated, AFAICS.
> >>>
> >>> I've tested this and it works fine on Venice 2. Since that was the
> >>> reference design for Nyan, I suspect that Nyan's will also work.
> >>>
> >>> It'd be great if Thomas or anyone else with access to a Nyan could
> >>> test this to verify that.
> >>
> >> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> >> 2023, hence we need to either use:
> > 
> > All the (at least relevant) functionality that is in panel-edp was in
> > panel-simple before it was moved to panel-edp. I've backported this set
> > of patches to v5.15 and it works just fine there.
> 
> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
> Nyan to keep the older DTBs working?

I don't see why we would want to do that. It's quite clear that the DTB
is buggy in this case and we have a more accurate way to describe what's
really there in hardware. In addition that more accurate representation
also gets rid of a bug. Obviously because the bug is caused by the
previous representation that was not accurate.

Given that we can easily replace the DTBs on these devices there's no
reason to make this any more complicated than it has to be.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> 21.12.2021 13:58, Thierry Reding пишет:
> ..
> >>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >>>> instantiated, AFAICS.
> >>>
> >>> I've tested this and it works fine on Venice 2. Since that was the
> >>> reference design for Nyan, I suspect that Nyan's will also work.
> >>>
> >>> It'd be great if Thomas or anyone else with access to a Nyan could
> >>> test this to verify that.
> >>
> >> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> >> 2023, hence we need to either use:
> > 
> > All the (at least relevant) functionality that is in panel-edp was in
> > panel-simple before it was moved to panel-edp. I've backported this set
> > of patches to v5.15 and it works just fine there.
> 
> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
> Nyan to keep the older DTBs working?

I don't see why we would want to do that. It's quite clear that the DTB
is buggy in this case and we have a more accurate way to describe what's
really there in hardware. In addition that more accurate representation
also gets rid of a bug. Obviously because the bug is caused by the
previous representation that was not accurate.

Given that we can easily replace the DTBs on these devices there's no
reason to make this any more complicated than it has to be.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

21.12.2021 19:17, Thierry Reding пишет:
> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 13:58, Thierry Reding пишет:
>> ..
>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>>>> instantiated, AFAICS.
>>>>>
>>>>> I've tested this and it works fine on Venice 2. Since that was the
>>>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>>>
>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>>>> test this to verify that.
>>>>
>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>>>> 2023, hence we need to either use:
>>>
>>> All the (at least relevant) functionality that is in panel-edp was in
>>> panel-simple before it was moved to panel-edp. I've backported this set
>>> of patches to v5.15 and it works just fine there.
>>
>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
>> Nyan to keep the older DTBs working?
> 
> I don't see why we would want to do that. It's quite clear that the DTB
> is buggy in this case and we have a more accurate way to describe what's
> really there in hardware. In addition that more accurate representation
> also gets rid of a bug. Obviously because the bug is caused by the
> previous representation that was not accurate.
> 
> Given that we can easily replace the DTBs on these devices there's no
> reason to make this any more complicated than it has to be.

Don't you care about normal people at all? Do you assume that everyone
must to be a kernel developer to be able to use Tegra devices? :/

It's not a problem for you to figure out why display is broken, for
other people it's a problem. Usually nobody will update DTB without a
well known reason, instead device will be dusted on a shelf. In the end
you won't have any users at all.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

21.12.2021 19:17, Thierry Reding пишет:
> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 13:58, Thierry Reding пишет:
>> ..
>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>>>> instantiated, AFAICS.
>>>>>
>>>>> I've tested this and it works fine on Venice 2. Since that was the
>>>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>>>
>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>>>> test this to verify that.
>>>>
>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>>>> 2023, hence we need to either use:
>>>
>>> All the (at least relevant) functionality that is in panel-edp was in
>>> panel-simple before it was moved to panel-edp. I've backported this set
>>> of patches to v5.15 and it works just fine there.
>>
>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
>> Nyan to keep the older DTBs working?
> 
> I don't see why we would want to do that. It's quite clear that the DTB
> is buggy in this case and we have a more accurate way to describe what's
> really there in hardware. In addition that more accurate representation
> also gets rid of a bug. Obviously because the bug is caused by the
> previous representation that was not accurate.
> 
> Given that we can easily replace the DTBs on these devices there's no
> reason to make this any more complicated than it has to be.

Don't you care about normal people at all? Do you assume that everyone
must to be a kernel developer to be able to use Tegra devices? :/

It's not a problem for you to figure out why display is broken, for
other people it's a problem. Usually nobody will update DTB without a
well known reason, instead device will be dusted on a shelf. In the end
you won't have any users at all.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
> 21.12.2021 19:17, Thierry Reding пишет:
> > On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> >> 21.12.2021 13:58, Thierry Reding пишет:
> >> ..
> >>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >>>>>> instantiated, AFAICS.
> >>>>>
> >>>>> I've tested this and it works fine on Venice 2. Since that was the
> >>>>> reference design for Nyan, I suspect that Nyan's will also work.
> >>>>>
> >>>>> It'd be great if Thomas or anyone else with access to a Nyan could
> >>>>> test this to verify that.
> >>>>
> >>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> >>>> 2023, hence we need to either use:
> >>>
> >>> All the (at least relevant) functionality that is in panel-edp was in
> >>> panel-simple before it was moved to panel-edp. I've backported this set
> >>> of patches to v5.15 and it works just fine there.
> >>
> >> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
> >> Nyan to keep the older DTBs working?
> > 
> > I don't see why we would want to do that. It's quite clear that the DTB
> > is buggy in this case and we have a more accurate way to describe what's
> > really there in hardware. In addition that more accurate representation
> > also gets rid of a bug. Obviously because the bug is caused by the
> > previous representation that was not accurate.
> > 
> > Given that we can easily replace the DTBs on these devices there's no
> > reason to make this any more complicated than it has to be.
> 
> Don't you care about normal people at all? Do you assume that everyone
> must to be a kernel developer to be able to use Tegra devices? :/

If you know how to install a custom kernel you also know how to replace
the DTB on these devices.

For everyone else, once these patches are merged upstream and
distributions start shipping the new version, they will get this
automatically by updating their kernel package since most distributions
actually ship the DTB files as part of that.

> It's not a problem for you to figure out why display is broken, for
> other people it's a problem. Usually nobody will update DTB without a
> well known reason, instead device will be dusted on a shelf. In the end
> you won't have any users at all.

Most "normal" people aren't even going to notice that their DTB is going
to be updated. They would actually have to do extra work *not* to update
it.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
> 21.12.2021 19:17, Thierry Reding пишет:
> > On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> >> 21.12.2021 13:58, Thierry Reding пишет:
> >> ..
> >>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >>>>>> instantiated, AFAICS.
> >>>>>
> >>>>> I've tested this and it works fine on Venice 2. Since that was the
> >>>>> reference design for Nyan, I suspect that Nyan's will also work.
> >>>>>
> >>>>> It'd be great if Thomas or anyone else with access to a Nyan could
> >>>>> test this to verify that.
> >>>>
> >>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> >>>> 2023, hence we need to either use:
> >>>
> >>> All the (at least relevant) functionality that is in panel-edp was in
> >>> panel-simple before it was moved to panel-edp. I've backported this set
> >>> of patches to v5.15 and it works just fine there.
> >>
> >> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
> >> Nyan to keep the older DTBs working?
> > 
> > I don't see why we would want to do that. It's quite clear that the DTB
> > is buggy in this case and we have a more accurate way to describe what's
> > really there in hardware. In addition that more accurate representation
> > also gets rid of a bug. Obviously because the bug is caused by the
> > previous representation that was not accurate.
> > 
> > Given that we can easily replace the DTBs on these devices there's no
> > reason to make this any more complicated than it has to be.
> 
> Don't you care about normal people at all? Do you assume that everyone
> must to be a kernel developer to be able to use Tegra devices? :/

If you know how to install a custom kernel you also know how to replace
the DTB on these devices.

For everyone else, once these patches are merged upstream and
distributions start shipping the new version, they will get this
automatically by updating their kernel package since most distributions
actually ship the DTB files as part of that.

> It's not a problem for you to figure out why display is broken, for
> other people it's a problem. Usually nobody will update DTB without a
> well known reason, instead device will be dusted on a shelf. In the end
> you won't have any users at all.

Most "normal" people aren't even going to notice that their DTB is going
to be updated. They would actually have to do extra work *not* to update
it.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

21.12.2021 21:01, Thierry Reding пишет:
> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 19:17, Thierry Reding пишет:
>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>>>> 21.12.2021 13:58, Thierry Reding пишет:
>>>> ..
>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>>>>>> instantiated, AFAICS.
>>>>>>>
>>>>>>> I've tested this and it works fine on Venice 2. Since that was the
>>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>>>>>
>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>>>>>> test this to verify that.
>>>>>>
>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>>>>>> 2023, hence we need to either use:
>>>>>
>>>>> All the (at least relevant) functionality that is in panel-edp was in
>>>>> panel-simple before it was moved to panel-edp. I've backported this set
>>>>> of patches to v5.15 and it works just fine there.
>>>>
>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
>>>> Nyan to keep the older DTBs working?
>>>
>>> I don't see why we would want to do that. It's quite clear that the DTB
>>> is buggy in this case and we have a more accurate way to describe what's
>>> really there in hardware. In addition that more accurate representation
>>> also gets rid of a bug. Obviously because the bug is caused by the
>>> previous representation that was not accurate.
>>>
>>> Given that we can easily replace the DTBs on these devices there's no
>>> reason to make this any more complicated than it has to be.
>>
>> Don't you care about normal people at all? Do you assume that everyone
>> must to be a kernel developer to be able to use Tegra devices? :/
> 
> If you know how to install a custom kernel you also know how to replace
> the DTB on these devices.
> 
> For everyone else, once these patches are merged upstream and
> distributions start shipping the new version, they will get this
> automatically by updating their kernel package since most distributions
> actually ship the DTB files as part of that.
> 
>> It's not a problem for you to figure out why display is broken, for
>> other people it's a problem. Usually nobody will update DTB without a
>> well known reason, instead device will be dusted on a shelf. In the end
>> you won't have any users at all.
> 
> Most "normal" people aren't even going to notice that their DTB is going
> to be updated. They would actually have to do extra work *not* to update
> it.

My past experience tells that your assumption is incorrect. There are
quite a lot of people who will update kernel, but not DTB.

ARM devices have endless variations of bootloaders and individual quirks
required for a successful installation of a kernel. Kernel update by
distro usually isn't a thing on ARM.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

21.12.2021 21:01, Thierry Reding пишет:
> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 19:17, Thierry Reding пишет:
>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>>>> 21.12.2021 13:58, Thierry Reding пишет:
>>>> ..
>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>>>>>> instantiated, AFAICS.
>>>>>>>
>>>>>>> I've tested this and it works fine on Venice 2. Since that was the
>>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>>>>>
>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>>>>>> test this to verify that.
>>>>>>
>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>>>>>> 2023, hence we need to either use:
>>>>>
>>>>> All the (at least relevant) functionality that is in panel-edp was in
>>>>> panel-simple before it was moved to panel-edp. I've backported this set
>>>>> of patches to v5.15 and it works just fine there.
>>>>
>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
>>>> Nyan to keep the older DTBs working?
>>>
>>> I don't see why we would want to do that. It's quite clear that the DTB
>>> is buggy in this case and we have a more accurate way to describe what's
>>> really there in hardware. In addition that more accurate representation
>>> also gets rid of a bug. Obviously because the bug is caused by the
>>> previous representation that was not accurate.
>>>
>>> Given that we can easily replace the DTBs on these devices there's no
>>> reason to make this any more complicated than it has to be.
>>
>> Don't you care about normal people at all? Do you assume that everyone
>> must to be a kernel developer to be able to use Tegra devices? :/
> 
> If you know how to install a custom kernel you also know how to replace
> the DTB on these devices.
> 
> For everyone else, once these patches are merged upstream and
> distributions start shipping the new version, they will get this
> automatically by updating their kernel package since most distributions
> actually ship the DTB files as part of that.
> 
>> It's not a problem for you to figure out why display is broken, for
>> other people it's a problem. Usually nobody will update DTB without a
>> well known reason, instead device will be dusted on a shelf. In the end
>> you won't have any users at all.
> 
> Most "normal" people aren't even going to notice that their DTB is going
> to be updated. They would actually have to do extra work *not* to update
> it.

My past experience tells that your assumption is incorrect. There are
quite a lot of people who will update kernel, but not DTB.

ARM devices have endless variations of bootloaders and individual quirks
required for a successful installation of a kernel. Kernel update by
distro usually isn't a thing on ARM.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4609 bytes --]

On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
> 21.12.2021 21:01, Thierry Reding пишет:
> > On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
> >> 21.12.2021 19:17, Thierry Reding пишет:
> >>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> >>>> 21.12.2021 13:58, Thierry Reding пишет:
> >>>> ..
> >>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >>>>>>>> instantiated, AFAICS.
> >>>>>>>
> >>>>>>> I've tested this and it works fine on Venice 2. Since that was the
> >>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
> >>>>>>>
> >>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
> >>>>>>> test this to verify that.
> >>>>>>
> >>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> >>>>>> 2023, hence we need to either use:
> >>>>>
> >>>>> All the (at least relevant) functionality that is in panel-edp was in
> >>>>> panel-simple before it was moved to panel-edp. I've backported this set
> >>>>> of patches to v5.15 and it works just fine there.
> >>>>
> >>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
> >>>> Nyan to keep the older DTBs working?
> >>>
> >>> I don't see why we would want to do that. It's quite clear that the DTB
> >>> is buggy in this case and we have a more accurate way to describe what's
> >>> really there in hardware. In addition that more accurate representation
> >>> also gets rid of a bug. Obviously because the bug is caused by the
> >>> previous representation that was not accurate.
> >>>
> >>> Given that we can easily replace the DTBs on these devices there's no
> >>> reason to make this any more complicated than it has to be.
> >>
> >> Don't you care about normal people at all? Do you assume that everyone
> >> must to be a kernel developer to be able to use Tegra devices? :/
> > 
> > If you know how to install a custom kernel you also know how to replace
> > the DTB on these devices.
> > 
> > For everyone else, once these patches are merged upstream and
> > distributions start shipping the new version, they will get this
> > automatically by updating their kernel package since most distributions
> > actually ship the DTB files as part of that.
> > 
> >> It's not a problem for you to figure out why display is broken, for
> >> other people it's a problem. Usually nobody will update DTB without a
> >> well known reason, instead device will be dusted on a shelf. In the end
> >> you won't have any users at all.
> > 
> > Most "normal" people aren't even going to notice that their DTB is going
> > to be updated. They would actually have to do extra work *not* to update
> > it.
> 
> My past experience tells that your assumption is incorrect. There are
> quite a lot of people who will update kernel, but not DTB.

People that do this will have to do it manually because most
distributions I know of will actually ship the DTBs. If they know how to
update the kernel separately, I'm sure they will manage to update the
DTB as well. It's really not more complicated that updating the kernel
image.

> ARM devices have endless variations of bootloaders and individual quirks
> required for a successful installation of a kernel. Kernel update by
> distro usually isn't a thing on ARM.

I'm not sure what distribution you have been using, but the ones that
I'm familiar with all install the DTBs along with the kernel. Most Tegra
devices (newer ones at least) do also support booting with U-Boot which
supports standard ways to boot a system (which were co-developed with
distributions precisely so that it would become easier for users to keep
their systems up-to-date), so there's really nothing magical anyone
should need to do in order to get an updated DTB along with the updated
kernel.

It's a simple fact that sometimes a DTB contains a bug and we have to
fix it.

In general we try to fix things up in the driver code when reasonable so
that people don't have to update the DTB. This is for the (mostly hypo-
thetical) case where updating the DTB is not possible or very
complicated.

However, that's not the case on the Venice 2 or Nyan boards. And looking
at the alternative in this case, I don't think it's reasonable compared
to just fixing the problem at the root, which is in the DTB.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4609 bytes --]

On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
> 21.12.2021 21:01, Thierry Reding пишет:
> > On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
> >> 21.12.2021 19:17, Thierry Reding пишет:
> >>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> >>>> 21.12.2021 13:58, Thierry Reding пишет:
> >>>> ..
> >>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >>>>>>>> instantiated, AFAICS.
> >>>>>>>
> >>>>>>> I've tested this and it works fine on Venice 2. Since that was the
> >>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
> >>>>>>>
> >>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
> >>>>>>> test this to verify that.
> >>>>>>
> >>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> >>>>>> 2023, hence we need to either use:
> >>>>>
> >>>>> All the (at least relevant) functionality that is in panel-edp was in
> >>>>> panel-simple before it was moved to panel-edp. I've backported this set
> >>>>> of patches to v5.15 and it works just fine there.
> >>>>
> >>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
> >>>> Nyan to keep the older DTBs working?
> >>>
> >>> I don't see why we would want to do that. It's quite clear that the DTB
> >>> is buggy in this case and we have a more accurate way to describe what's
> >>> really there in hardware. In addition that more accurate representation
> >>> also gets rid of a bug. Obviously because the bug is caused by the
> >>> previous representation that was not accurate.
> >>>
> >>> Given that we can easily replace the DTBs on these devices there's no
> >>> reason to make this any more complicated than it has to be.
> >>
> >> Don't you care about normal people at all? Do you assume that everyone
> >> must to be a kernel developer to be able to use Tegra devices? :/
> > 
> > If you know how to install a custom kernel you also know how to replace
> > the DTB on these devices.
> > 
> > For everyone else, once these patches are merged upstream and
> > distributions start shipping the new version, they will get this
> > automatically by updating their kernel package since most distributions
> > actually ship the DTB files as part of that.
> > 
> >> It's not a problem for you to figure out why display is broken, for
> >> other people it's a problem. Usually nobody will update DTB without a
> >> well known reason, instead device will be dusted on a shelf. In the end
> >> you won't have any users at all.
> > 
> > Most "normal" people aren't even going to notice that their DTB is going
> > to be updated. They would actually have to do extra work *not* to update
> > it.
> 
> My past experience tells that your assumption is incorrect. There are
> quite a lot of people who will update kernel, but not DTB.

People that do this will have to do it manually because most
distributions I know of will actually ship the DTBs. If they know how to
update the kernel separately, I'm sure they will manage to update the
DTB as well. It's really not more complicated that updating the kernel
image.

> ARM devices have endless variations of bootloaders and individual quirks
> required for a successful installation of a kernel. Kernel update by
> distro usually isn't a thing on ARM.

I'm not sure what distribution you have been using, but the ones that
I'm familiar with all install the DTBs along with the kernel. Most Tegra
devices (newer ones at least) do also support booting with U-Boot which
supports standard ways to boot a system (which were co-developed with
distributions precisely so that it would become easier for users to keep
their systems up-to-date), so there's really nothing magical anyone
should need to do in order to get an updated DTB along with the updated
kernel.

It's a simple fact that sometimes a DTB contains a bug and we have to
fix it.

In general we try to fix things up in the driver code when reasonable so
that people don't have to update the DTB. This is for the (mostly hypo-
thetical) case where updating the DTB is not possible or very
complicated.

However, that's not the case on the Venice 2 or Nyan boards. And looking
at the alternative in this case, I don't think it's reasonable compared
to just fixing the problem at the root, which is in the DTB.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

22.12.2021 14:53, Thierry Reding пишет:
> On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 21:01, Thierry Reding пишет:
>>> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
>>>> 21.12.2021 19:17, Thierry Reding пишет:
>>>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>>>>>> 21.12.2021 13:58, Thierry Reding пишет:
>>>>>> ..
>>>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>>>>>>>> instantiated, AFAICS.
>>>>>>>>>
>>>>>>>>> I've tested this and it works fine on Venice 2. Since that was the
>>>>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>>>>>>>
>>>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>>>>>>>> test this to verify that.
>>>>>>>>
>>>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>>>>>>>> 2023, hence we need to either use:
>>>>>>>
>>>>>>> All the (at least relevant) functionality that is in panel-edp was in
>>>>>>> panel-simple before it was moved to panel-edp. I've backported this set
>>>>>>> of patches to v5.15 and it works just fine there.
>>>>>>
>>>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
>>>>>> Nyan to keep the older DTBs working?
>>>>>
>>>>> I don't see why we would want to do that. It's quite clear that the DTB
>>>>> is buggy in this case and we have a more accurate way to describe what's
>>>>> really there in hardware. In addition that more accurate representation
>>>>> also gets rid of a bug. Obviously because the bug is caused by the
>>>>> previous representation that was not accurate.
>>>>>
>>>>> Given that we can easily replace the DTBs on these devices there's no
>>>>> reason to make this any more complicated than it has to be.
>>>>
>>>> Don't you care about normal people at all? Do you assume that everyone
>>>> must to be a kernel developer to be able to use Tegra devices? :/
>>>
>>> If you know how to install a custom kernel you also know how to replace
>>> the DTB on these devices.
>>>
>>> For everyone else, once these patches are merged upstream and
>>> distributions start shipping the new version, they will get this
>>> automatically by updating their kernel package since most distributions
>>> actually ship the DTB files as part of that.
>>>
>>>> It's not a problem for you to figure out why display is broken, for
>>>> other people it's a problem. Usually nobody will update DTB without a
>>>> well known reason, instead device will be dusted on a shelf. In the end
>>>> you won't have any users at all.
>>>
>>> Most "normal" people aren't even going to notice that their DTB is going
>>> to be updated. They would actually have to do extra work *not* to update
>>> it.
>>
>> My past experience tells that your assumption is incorrect. There are
>> quite a lot of people who will update kernel, but not DTB.
> 
> People that do this will have to do it manually because most
> distributions I know of will actually ship the DTBs. If they know how to
> update the kernel separately, I'm sure they will manage to update the
> DTB as well. It's really not more complicated that updating the kernel
> image.
> 
>> ARM devices have endless variations of bootloaders and individual quirks
>> required for a successful installation of a kernel. Kernel update by
>> distro usually isn't a thing on ARM.
> 
> I'm not sure what distribution you have been using, but the ones that
> I'm familiar with all install the DTBs along with the kernel. Most Tegra
> devices (newer ones at least) do also support booting with U-Boot which
> supports standard ways to boot a system (which were co-developed with
> distributions precisely so that it would become easier for users to keep
> their systems up-to-date), so there's really nothing magical anyone
> should need to do in order to get an updated DTB along with the updated
> kernel.
> 
> It's a simple fact that sometimes a DTB contains a bug and we have to
> fix it.
> 
> In general we try to fix things up in the driver code when reasonable so
> that people don't have to update the DTB. This is for the (mostly hypo-
> thetical) case where updating the DTB is not possible or very
> complicated.
> 
> However, that's not the case on the Venice 2 or Nyan boards. And looking
> at the alternative in this case, I don't think it's reasonable compared
> to just fixing the problem at the root, which is in the DTB.

My understanding that U-Boot isn't the only available bootloader option
for Nyan. I don't feel happy about the ABI breakage, but in the same
time don't feel very strong about the need to care about it in the case
of Nyan since its DT already had a preexisting problem with the wrong
panel model used for the FHD model. The decision will be on your
conscience :)

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

22.12.2021 14:53, Thierry Reding пишет:
> On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 21:01, Thierry Reding пишет:
>>> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
>>>> 21.12.2021 19:17, Thierry Reding пишет:
>>>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>>>>>> 21.12.2021 13:58, Thierry Reding пишет:
>>>>>> ..
>>>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>>>>>>>> instantiated, AFAICS.
>>>>>>>>>
>>>>>>>>> I've tested this and it works fine on Venice 2. Since that was the
>>>>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>>>>>>>
>>>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>>>>>>>> test this to verify that.
>>>>>>>>
>>>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>>>>>>>> 2023, hence we need to either use:
>>>>>>>
>>>>>>> All the (at least relevant) functionality that is in panel-edp was in
>>>>>>> panel-simple before it was moved to panel-edp. I've backported this set
>>>>>>> of patches to v5.15 and it works just fine there.
>>>>>>
>>>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
>>>>>> Nyan to keep the older DTBs working?
>>>>>
>>>>> I don't see why we would want to do that. It's quite clear that the DTB
>>>>> is buggy in this case and we have a more accurate way to describe what's
>>>>> really there in hardware. In addition that more accurate representation
>>>>> also gets rid of a bug. Obviously because the bug is caused by the
>>>>> previous representation that was not accurate.
>>>>>
>>>>> Given that we can easily replace the DTBs on these devices there's no
>>>>> reason to make this any more complicated than it has to be.
>>>>
>>>> Don't you care about normal people at all? Do you assume that everyone
>>>> must to be a kernel developer to be able to use Tegra devices? :/
>>>
>>> If you know how to install a custom kernel you also know how to replace
>>> the DTB on these devices.
>>>
>>> For everyone else, once these patches are merged upstream and
>>> distributions start shipping the new version, they will get this
>>> automatically by updating their kernel package since most distributions
>>> actually ship the DTB files as part of that.
>>>
>>>> It's not a problem for you to figure out why display is broken, for
>>>> other people it's a problem. Usually nobody will update DTB without a
>>>> well known reason, instead device will be dusted on a shelf. In the end
>>>> you won't have any users at all.
>>>
>>> Most "normal" people aren't even going to notice that their DTB is going
>>> to be updated. They would actually have to do extra work *not* to update
>>> it.
>>
>> My past experience tells that your assumption is incorrect. There are
>> quite a lot of people who will update kernel, but not DTB.
> 
> People that do this will have to do it manually because most
> distributions I know of will actually ship the DTBs. If they know how to
> update the kernel separately, I'm sure they will manage to update the
> DTB as well. It's really not more complicated that updating the kernel
> image.
> 
>> ARM devices have endless variations of bootloaders and individual quirks
>> required for a successful installation of a kernel. Kernel update by
>> distro usually isn't a thing on ARM.
> 
> I'm not sure what distribution you have been using, but the ones that
> I'm familiar with all install the DTBs along with the kernel. Most Tegra
> devices (newer ones at least) do also support booting with U-Boot which
> supports standard ways to boot a system (which were co-developed with
> distributions precisely so that it would become easier for users to keep
> their systems up-to-date), so there's really nothing magical anyone
> should need to do in order to get an updated DTB along with the updated
> kernel.
> 
> It's a simple fact that sometimes a DTB contains a bug and we have to
> fix it.
> 
> In general we try to fix things up in the driver code when reasonable so
> that people don't have to update the DTB. This is for the (mostly hypo-
> thetical) case where updating the DTB is not possible or very
> complicated.
> 
> However, that's not the case on the Venice 2 or Nyan boards. And looking
> at the alternative in this case, I don't think it's reasonable compared
> to just fixing the problem at the root, which is in the DTB.

My understanding that U-Boot isn't the only available bootloader option
for Nyan. I don't feel happy about the ABI breakage, but in the same
time don't feel very strong about the need to care about it in the case
of Nyan since its DT already had a preexisting problem with the wrong
panel model used for the FHD model. The decision will be on your
conscience :)

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Doug Anderson]

Hi,

On Wed, Dec 22, 2021 at 11:26 AM Dmitry Osipenko <digetx@gmail.com> wrote:
>
> 22.12.2021 14:53, Thierry Reding пишет:
> > On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
> >> 21.12.2021 21:01, Thierry Reding пишет:
> >>> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
> >>>> 21.12.2021 19:17, Thierry Reding пишет:
> >>>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> >>>>>> 21.12.2021 13:58, Thierry Reding пишет:
> >>>>>> ..
> >>>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >>>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >>>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >>>>>>>>>> instantiated, AFAICS.
> >>>>>>>>>
> >>>>>>>>> I've tested this and it works fine on Venice 2. Since that was the
> >>>>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
> >>>>>>>>>
> >>>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
> >>>>>>>>> test this to verify that.
> >>>>>>>>
> >>>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> >>>>>>>> 2023, hence we need to either use:
> >>>>>>>
> >>>>>>> All the (at least relevant) functionality that is in panel-edp was in
> >>>>>>> panel-simple before it was moved to panel-edp. I've backported this set
> >>>>>>> of patches to v5.15 and it works just fine there.
> >>>>>>
> >>>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
> >>>>>> Nyan to keep the older DTBs working?
> >>>>>
> >>>>> I don't see why we would want to do that. It's quite clear that the DTB
> >>>>> is buggy in this case and we have a more accurate way to describe what's
> >>>>> really there in hardware. In addition that more accurate representation
> >>>>> also gets rid of a bug. Obviously because the bug is caused by the
> >>>>> previous representation that was not accurate.
> >>>>>
> >>>>> Given that we can easily replace the DTBs on these devices there's no
> >>>>> reason to make this any more complicated than it has to be.
> >>>>
> >>>> Don't you care about normal people at all? Do you assume that everyone
> >>>> must to be a kernel developer to be able to use Tegra devices? :/
> >>>
> >>> If you know how to install a custom kernel you also know how to replace
> >>> the DTB on these devices.
> >>>
> >>> For everyone else, once these patches are merged upstream and
> >>> distributions start shipping the new version, they will get this
> >>> automatically by updating their kernel package since most distributions
> >>> actually ship the DTB files as part of that.
> >>>
> >>>> It's not a problem for you to figure out why display is broken, for
> >>>> other people it's a problem. Usually nobody will update DTB without a
> >>>> well known reason, instead device will be dusted on a shelf. In the end
> >>>> you won't have any users at all.
> >>>
> >>> Most "normal" people aren't even going to notice that their DTB is going
> >>> to be updated. They would actually have to do extra work *not* to update
> >>> it.
> >>
> >> My past experience tells that your assumption is incorrect. There are
> >> quite a lot of people who will update kernel, but not DTB.
> >
> > People that do this will have to do it manually because most
> > distributions I know of will actually ship the DTBs. If they know how to
> > update the kernel separately, I'm sure they will manage to update the
> > DTB as well. It's really not more complicated that updating the kernel
> > image.
> >
> >> ARM devices have endless variations of bootloaders and individual quirks
> >> required for a successful installation of a kernel. Kernel update by
> >> distro usually isn't a thing on ARM.
> >
> > I'm not sure what distribution you have been using, but the ones that
> > I'm familiar with all install the DTBs along with the kernel. Most Tegra
> > devices (newer ones at least) do also support booting with U-Boot which
> > supports standard ways to boot a system (which were co-developed with
> > distributions precisely so that it would become easier for users to keep
> > their systems up-to-date), so there's really nothing magical anyone
> > should need to do in order to get an updated DTB along with the updated
> > kernel.
> >
> > It's a simple fact that sometimes a DTB contains a bug and we have to
> > fix it.
> >
> > In general we try to fix things up in the driver code when reasonable so
> > that people don't have to update the DTB. This is for the (mostly hypo-
> > thetical) case where updating the DTB is not possible or very
> > complicated.
> >
> > However, that's not the case on the Venice 2 or Nyan boards. And looking
> > at the alternative in this case, I don't think it's reasonable compared
> > to just fixing the problem at the root, which is in the DTB.
>
> My understanding that U-Boot isn't the only available bootloader option
> for Nyan. I don't feel happy about the ABI breakage, but in the same
> time don't feel very strong about the need to care about it in the case
> of Nyan since its DT already had a preexisting problem with the wrong
> panel model used for the FHD model. The decision will be on your
> conscience :)

Maybe I should stand back to avoid getting hit by tomatoes, but IMO
it's a terrible idea to try to update devices trees separately from
kernels for any sufficiently complicated device. I won't stop you from
shooting yourself in the foot, but I also certainly wouldn't encourage
it. I've always said that I'll accept that this is something to really
worry about when we land chunk of "device tree fixup" code that runs
in early boot to fix all the broken device trees out there. All ARM
Chrome OS devices that have ever shipped all bundle device trees
together with the kernel (they bundle a whole pile of them and the
bootloader picks the right one based on model). Sure, someone could
decide to bake one into their bootloader but, even aside from this
case, there are sometimes bugs in device trees and they need to get
fixed. Updating your kernel without your device tree is just bad juju
IMO.

I'll let you and Thierry figure out what you want to do for 5.15. In
the Chrome OS 5.15 kernel tree we simply backported all the edp-panel
stuff, which was fairly clean. I even backported all that stuff to
5.4, but it was decidedly more complex...

-Doug

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Doug Anderson]

Hi,

On Wed, Dec 22, 2021 at 11:26 AM Dmitry Osipenko <digetx@gmail.com> wrote:
>
> 22.12.2021 14:53, Thierry Reding пишет:
> > On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
> >> 21.12.2021 21:01, Thierry Reding пишет:
> >>> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
> >>>> 21.12.2021 19:17, Thierry Reding пишет:
> >>>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
> >>>>>> 21.12.2021 13:58, Thierry Reding пишет:
> >>>>>> ..
> >>>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
> >>>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
> >>>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
> >>>>>>>>>> instantiated, AFAICS.
> >>>>>>>>>
> >>>>>>>>> I've tested this and it works fine on Venice 2. Since that was the
> >>>>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
> >>>>>>>>>
> >>>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
> >>>>>>>>> test this to verify that.
> >>>>>>>>
> >>>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
> >>>>>>>> 2023, hence we need to either use:
> >>>>>>>
> >>>>>>> All the (at least relevant) functionality that is in panel-edp was in
> >>>>>>> panel-simple before it was moved to panel-edp. I've backported this set
> >>>>>>> of patches to v5.15 and it works just fine there.
> >>>>>>
> >>>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
> >>>>>> Nyan to keep the older DTBs working?
> >>>>>
> >>>>> I don't see why we would want to do that. It's quite clear that the DTB
> >>>>> is buggy in this case and we have a more accurate way to describe what's
> >>>>> really there in hardware. In addition that more accurate representation
> >>>>> also gets rid of a bug. Obviously because the bug is caused by the
> >>>>> previous representation that was not accurate.
> >>>>>
> >>>>> Given that we can easily replace the DTBs on these devices there's no
> >>>>> reason to make this any more complicated than it has to be.
> >>>>
> >>>> Don't you care about normal people at all? Do you assume that everyone
> >>>> must to be a kernel developer to be able to use Tegra devices? :/
> >>>
> >>> If you know how to install a custom kernel you also know how to replace
> >>> the DTB on these devices.
> >>>
> >>> For everyone else, once these patches are merged upstream and
> >>> distributions start shipping the new version, they will get this
> >>> automatically by updating their kernel package since most distributions
> >>> actually ship the DTB files as part of that.
> >>>
> >>>> It's not a problem for you to figure out why display is broken, for
> >>>> other people it's a problem. Usually nobody will update DTB without a
> >>>> well known reason, instead device will be dusted on a shelf. In the end
> >>>> you won't have any users at all.
> >>>
> >>> Most "normal" people aren't even going to notice that their DTB is going
> >>> to be updated. They would actually have to do extra work *not* to update
> >>> it.
> >>
> >> My past experience tells that your assumption is incorrect. There are
> >> quite a lot of people who will update kernel, but not DTB.
> >
> > People that do this will have to do it manually because most
> > distributions I know of will actually ship the DTBs. If they know how to
> > update the kernel separately, I'm sure they will manage to update the
> > DTB as well. It's really not more complicated that updating the kernel
> > image.
> >
> >> ARM devices have endless variations of bootloaders and individual quirks
> >> required for a successful installation of a kernel. Kernel update by
> >> distro usually isn't a thing on ARM.
> >
> > I'm not sure what distribution you have been using, but the ones that
> > I'm familiar with all install the DTBs along with the kernel. Most Tegra
> > devices (newer ones at least) do also support booting with U-Boot which
> > supports standard ways to boot a system (which were co-developed with
> > distributions precisely so that it would become easier for users to keep
> > their systems up-to-date), so there's really nothing magical anyone
> > should need to do in order to get an updated DTB along with the updated
> > kernel.
> >
> > It's a simple fact that sometimes a DTB contains a bug and we have to
> > fix it.
> >
> > In general we try to fix things up in the driver code when reasonable so
> > that people don't have to update the DTB. This is for the (mostly hypo-
> > thetical) case where updating the DTB is not possible or very
> > complicated.
> >
> > However, that's not the case on the Venice 2 or Nyan boards. And looking
> > at the alternative in this case, I don't think it's reasonable compared
> > to just fixing the problem at the root, which is in the DTB.
>
> My understanding that U-Boot isn't the only available bootloader option
> for Nyan. I don't feel happy about the ABI breakage, but in the same
> time don't feel very strong about the need to care about it in the case
> of Nyan since its DT already had a preexisting problem with the wrong
> panel model used for the FHD model. The decision will be on your
> conscience :)

Maybe I should stand back to avoid getting hit by tomatoes, but IMO
it's a terrible idea to try to update devices trees separately from
kernels for any sufficiently complicated device. I won't stop you from
shooting yourself in the foot, but I also certainly wouldn't encourage
it. I've always said that I'll accept that this is something to really
worry about when we land chunk of "device tree fixup" code that runs
in early boot to fix all the broken device trees out there. All ARM
Chrome OS devices that have ever shipped all bundle device trees
together with the kernel (they bundle a whole pile of them and the
bootloader picks the right one based on model). Sure, someone could
decide to bake one into their bootloader but, even aside from this
case, there are sometimes bugs in device trees and they need to get
fixed. Updating your kernel without your device tree is just bad juju
IMO.

I'll let you and Thierry figure out what you want to do for 5.15. In
the Chrome OS 5.15 kernel tree we simply backported all the edp-panel
stuff, which was fairly clean. I even backported all that stuff to
5.4, but it was decidedly more complex...

-Doug

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

06.01.2022 04:11, Doug Anderson пишет:
> Hi,
> 
> On Wed, Dec 22, 2021 at 11:26 AM Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 22.12.2021 14:53, Thierry Reding пишет:
>>> On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
>>>> 21.12.2021 21:01, Thierry Reding пишет:
>>>>> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
>>>>>> 21.12.2021 19:17, Thierry Reding пишет:
>>>>>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>>>>>>>> 21.12.2021 13:58, Thierry Reding пишет:
>>>>>>>> ..
>>>>>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>>>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>>>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>>>>>>>>>> instantiated, AFAICS.
>>>>>>>>>>>
>>>>>>>>>>> I've tested this and it works fine on Venice 2. Since that was the
>>>>>>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>>>>>>>>>
>>>>>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>>>>>>>>>> test this to verify that.
>>>>>>>>>>
>>>>>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>>>>>>>>>> 2023, hence we need to either use:
>>>>>>>>>
>>>>>>>>> All the (at least relevant) functionality that is in panel-edp was in
>>>>>>>>> panel-simple before it was moved to panel-edp. I've backported this set
>>>>>>>>> of patches to v5.15 and it works just fine there.
>>>>>>>>
>>>>>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
>>>>>>>> Nyan to keep the older DTBs working?
>>>>>>>
>>>>>>> I don't see why we would want to do that. It's quite clear that the DTB
>>>>>>> is buggy in this case and we have a more accurate way to describe what's
>>>>>>> really there in hardware. In addition that more accurate representation
>>>>>>> also gets rid of a bug. Obviously because the bug is caused by the
>>>>>>> previous representation that was not accurate.
>>>>>>>
>>>>>>> Given that we can easily replace the DTBs on these devices there's no
>>>>>>> reason to make this any more complicated than it has to be.
>>>>>>
>>>>>> Don't you care about normal people at all? Do you assume that everyone
>>>>>> must to be a kernel developer to be able to use Tegra devices? :/
>>>>>
>>>>> If you know how to install a custom kernel you also know how to replace
>>>>> the DTB on these devices.
>>>>>
>>>>> For everyone else, once these patches are merged upstream and
>>>>> distributions start shipping the new version, they will get this
>>>>> automatically by updating their kernel package since most distributions
>>>>> actually ship the DTB files as part of that.
>>>>>
>>>>>> It's not a problem for you to figure out why display is broken, for
>>>>>> other people it's a problem. Usually nobody will update DTB without a
>>>>>> well known reason, instead device will be dusted on a shelf. In the end
>>>>>> you won't have any users at all.
>>>>>
>>>>> Most "normal" people aren't even going to notice that their DTB is going
>>>>> to be updated. They would actually have to do extra work *not* to update
>>>>> it.
>>>>
>>>> My past experience tells that your assumption is incorrect. There are
>>>> quite a lot of people who will update kernel, but not DTB.
>>>
>>> People that do this will have to do it manually because most
>>> distributions I know of will actually ship the DTBs. If they know how to
>>> update the kernel separately, I'm sure they will manage to update the
>>> DTB as well. It's really not more complicated that updating the kernel
>>> image.
>>>
>>>> ARM devices have endless variations of bootloaders and individual quirks
>>>> required for a successful installation of a kernel. Kernel update by
>>>> distro usually isn't a thing on ARM.
>>>
>>> I'm not sure what distribution you have been using, but the ones that
>>> I'm familiar with all install the DTBs along with the kernel. Most Tegra
>>> devices (newer ones at least) do also support booting with U-Boot which
>>> supports standard ways to boot a system (which were co-developed with
>>> distributions precisely so that it would become easier for users to keep
>>> their systems up-to-date), so there's really nothing magical anyone
>>> should need to do in order to get an updated DTB along with the updated
>>> kernel.
>>>
>>> It's a simple fact that sometimes a DTB contains a bug and we have to
>>> fix it.
>>>
>>> In general we try to fix things up in the driver code when reasonable so
>>> that people don't have to update the DTB. This is for the (mostly hypo-
>>> thetical) case where updating the DTB is not possible or very
>>> complicated.
>>>
>>> However, that's not the case on the Venice 2 or Nyan boards. And looking
>>> at the alternative in this case, I don't think it's reasonable compared
>>> to just fixing the problem at the root, which is in the DTB.
>>
>> My understanding that U-Boot isn't the only available bootloader option
>> for Nyan. I don't feel happy about the ABI breakage, but in the same
>> time don't feel very strong about the need to care about it in the case
>> of Nyan since its DT already had a preexisting problem with the wrong
>> panel model used for the FHD model. The decision will be on your
>> conscience :)
> 
> Maybe I should stand back to avoid getting hit by tomatoes, but IMO
> it's a terrible idea to try to update devices trees separately from
> kernels for any sufficiently complicated device. I won't stop you from
> shooting yourself in the foot, but I also certainly wouldn't encourage
> it. I've always said that I'll accept that this is something to really
> worry about when we land chunk of "device tree fixup" code that runs
> in early boot to fix all the broken device trees out there. All ARM
> Chrome OS devices that have ever shipped all bundle device trees
> together with the kernel (they bundle a whole pile of them and the
> bootloader picks the right one based on model). Sure, someone could
> decide to bake one into their bootloader but, even aside from this
> case, there are sometimes bugs in device trees and they need to get
> fixed. Updating your kernel without your device tree is just bad juju
> IMO.
> 
> I'll let you and Thierry figure out what you want to do for 5.15. In
> the Chrome OS 5.15 kernel tree we simply backported all the edp-panel
> stuff, which was fairly clean. I even backported all that stuff to
> 5.4, but it was decidedly more complex...

Chrome OS is a commercial product, while here we are talking about
normal (non-kernel/developer) people. It's incorrect to compare home
hackers with professional developers/products, IMO.

If we could keep older DTBs working without much effort, then will be
great. If not, maybe not a big deal.

I suggested variants of preserving the older DTBs and leaving it up to
Thierry to decide what to do.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

06.01.2022 04:11, Doug Anderson пишет:
> Hi,
> 
> On Wed, Dec 22, 2021 at 11:26 AM Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 22.12.2021 14:53, Thierry Reding пишет:
>>> On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
>>>> 21.12.2021 21:01, Thierry Reding пишет:
>>>>> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
>>>>>> 21.12.2021 19:17, Thierry Reding пишет:
>>>>>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote:
>>>>>>>> 21.12.2021 13:58, Thierry Reding пишет:
>>>>>>>> ..
>>>>>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is
>>>>>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should
>>>>>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully
>>>>>>>>>>>> instantiated, AFAICS.
>>>>>>>>>>>
>>>>>>>>>>> I've tested this and it works fine on Venice 2. Since that was the
>>>>>>>>>>> reference design for Nyan, I suspect that Nyan's will also work.
>>>>>>>>>>>
>>>>>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could
>>>>>>>>>>> test this to verify that.
>>>>>>>>>>
>>>>>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct,
>>>>>>>>>> 2023, hence we need to either use:
>>>>>>>>>
>>>>>>>>> All the (at least relevant) functionality that is in panel-edp was in
>>>>>>>>> panel-simple before it was moved to panel-edp. I've backported this set
>>>>>>>>> of patches to v5.15 and it works just fine there.
>>>>>>>>
>>>>>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on
>>>>>>>> Nyan to keep the older DTBs working?
>>>>>>>
>>>>>>> I don't see why we would want to do that. It's quite clear that the DTB
>>>>>>> is buggy in this case and we have a more accurate way to describe what's
>>>>>>> really there in hardware. In addition that more accurate representation
>>>>>>> also gets rid of a bug. Obviously because the bug is caused by the
>>>>>>> previous representation that was not accurate.
>>>>>>>
>>>>>>> Given that we can easily replace the DTBs on these devices there's no
>>>>>>> reason to make this any more complicated than it has to be.
>>>>>>
>>>>>> Don't you care about normal people at all? Do you assume that everyone
>>>>>> must to be a kernel developer to be able to use Tegra devices? :/
>>>>>
>>>>> If you know how to install a custom kernel you also know how to replace
>>>>> the DTB on these devices.
>>>>>
>>>>> For everyone else, once these patches are merged upstream and
>>>>> distributions start shipping the new version, they will get this
>>>>> automatically by updating their kernel package since most distributions
>>>>> actually ship the DTB files as part of that.
>>>>>
>>>>>> It's not a problem for you to figure out why display is broken, for
>>>>>> other people it's a problem. Usually nobody will update DTB without a
>>>>>> well known reason, instead device will be dusted on a shelf. In the end
>>>>>> you won't have any users at all.
>>>>>
>>>>> Most "normal" people aren't even going to notice that their DTB is going
>>>>> to be updated. They would actually have to do extra work *not* to update
>>>>> it.
>>>>
>>>> My past experience tells that your assumption is incorrect. There are
>>>> quite a lot of people who will update kernel, but not DTB.
>>>
>>> People that do this will have to do it manually because most
>>> distributions I know of will actually ship the DTBs. If they know how to
>>> update the kernel separately, I'm sure they will manage to update the
>>> DTB as well. It's really not more complicated that updating the kernel
>>> image.
>>>
>>>> ARM devices have endless variations of bootloaders and individual quirks
>>>> required for a successful installation of a kernel. Kernel update by
>>>> distro usually isn't a thing on ARM.
>>>
>>> I'm not sure what distribution you have been using, but the ones that
>>> I'm familiar with all install the DTBs along with the kernel. Most Tegra
>>> devices (newer ones at least) do also support booting with U-Boot which
>>> supports standard ways to boot a system (which were co-developed with
>>> distributions precisely so that it would become easier for users to keep
>>> their systems up-to-date), so there's really nothing magical anyone
>>> should need to do in order to get an updated DTB along with the updated
>>> kernel.
>>>
>>> It's a simple fact that sometimes a DTB contains a bug and we have to
>>> fix it.
>>>
>>> In general we try to fix things up in the driver code when reasonable so
>>> that people don't have to update the DTB. This is for the (mostly hypo-
>>> thetical) case where updating the DTB is not possible or very
>>> complicated.
>>>
>>> However, that's not the case on the Venice 2 or Nyan boards. And looking
>>> at the alternative in this case, I don't think it's reasonable compared
>>> to just fixing the problem at the root, which is in the DTB.
>>
>> My understanding that U-Boot isn't the only available bootloader option
>> for Nyan. I don't feel happy about the ABI breakage, but in the same
>> time don't feel very strong about the need to care about it in the case
>> of Nyan since its DT already had a preexisting problem with the wrong
>> panel model used for the FHD model. The decision will be on your
>> conscience :)
> 
> Maybe I should stand back to avoid getting hit by tomatoes, but IMO
> it's a terrible idea to try to update devices trees separately from
> kernels for any sufficiently complicated device. I won't stop you from
> shooting yourself in the foot, but I also certainly wouldn't encourage
> it. I've always said that I'll accept that this is something to really
> worry about when we land chunk of "device tree fixup" code that runs
> in early boot to fix all the broken device trees out there. All ARM
> Chrome OS devices that have ever shipped all bundle device trees
> together with the kernel (they bundle a whole pile of them and the
> bootloader picks the right one based on model). Sure, someone could
> decide to bake one into their bootloader but, even aside from this
> case, there are sometimes bugs in device trees and they need to get
> fixed. Updating your kernel without your device tree is just bad juju
> IMO.
> 
> I'll let you and Thierry figure out what you want to do for 5.15. In
> the Chrome OS 5.15 kernel tree we simply backported all the edp-panel
> stuff, which was fairly clean. I even backported all that stuff to
> 5.4, but it was decidedly more complex...

Chrome OS is a commercial product, while here we are talking about
normal (non-kernel/developer) people. It's incorrect to compare home
hackers with professional developers/products, IMO.

If we could keep older DTBs working without much effort, then will be
great. If not, maybe not a big deal.

I suggested variants of preserving the older DTBs and leaving it up to
Thierry to decide what to do.

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
> 
> Hi,
> 
> this is an alternative proposal to fix panel support on Venice 2 and
> Nyan. Dmitry had proposed a different solution that involved reverting
> the I2C/DDC registration order and would complicate things by breaking
> the encapsulation of the driver by introducing a global (though locally
> scoped) variable[0].
> 
> This set of patches avoids that by using the recently introduced DP AUX
> bus infrastructure. The result is that the changes are actually less
> intrusive and not a step back. Instead they nicely remove the circular
> dependency that previously existed and caused these issues in the first
> place.
> 
> To be fair, this is not perfect either because it requires a device tree
> change and hence isn't technically backwards-compatible. However, given
> that the original device tree was badly broken in the first place, I
> think we can make an exception, especially since it is not generally a
> problem to update device trees on the affected devices.
> 
> Secondly, this relies on infrastructure that was introduced in v5.15 and
> therefore will be difficult to backport beyond that. However, since this
> functionality has been broken since v5.13 and all of the kernel versions
> between that and v5.15 are EOL anyway, there isn't much that we can do
> to fix the interim versions anyway.
> 
> Adding Doug and Laurent since they originally designed the AUX bus
> patches in case they see anything in here that would be objectionable.
> 
> Thierry
> 
> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> 
> Thierry Reding (2):
>   drm/tegra: dpaux: Populate AUX bus
>   ARM: tegra: Move panels to AUX bus
> 
>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>  5 files changed, 33 insertions(+), 19 deletions(-)
> 

Will we see the v2 anytime soon?

Re: [PATCH 0/2] drm/tegra: Fix panel support on Venice 2 and Nyan

[Dmitry Osipenko]

20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
> 
> Hi,
> 
> this is an alternative proposal to fix panel support on Venice 2 and
> Nyan. Dmitry had proposed a different solution that involved reverting
> the I2C/DDC registration order and would complicate things by breaking
> the encapsulation of the driver by introducing a global (though locally
> scoped) variable[0].
> 
> This set of patches avoids that by using the recently introduced DP AUX
> bus infrastructure. The result is that the changes are actually less
> intrusive and not a step back. Instead they nicely remove the circular
> dependency that previously existed and caused these issues in the first
> place.
> 
> To be fair, this is not perfect either because it requires a device tree
> change and hence isn't technically backwards-compatible. However, given
> that the original device tree was badly broken in the first place, I
> think we can make an exception, especially since it is not generally a
> problem to update device trees on the affected devices.
> 
> Secondly, this relies on infrastructure that was introduced in v5.15 and
> therefore will be difficult to backport beyond that. However, since this
> functionality has been broken since v5.13 and all of the kernel versions
> between that and v5.15 are EOL anyway, there isn't much that we can do
> to fix the interim versions anyway.
> 
> Adding Doug and Laurent since they originally designed the AUX bus
> patches in case they see anything in here that would be objectionable.
> 
> Thierry
> 
> [0]: https://lore.kernel.org/dri-devel/20211130230957.30213-1-digetx@gmail.com/
> 
> Thierry Reding (2):
>   drm/tegra: dpaux: Populate AUX bus
>   ARM: tegra: Move panels to AUX bus
> 
>  arch/arm/boot/dts/tegra124-nyan-big.dts   | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-nyan-blaze.dts | 15 +++++++++------
>  arch/arm/boot/dts/tegra124-venice2.dts    | 14 +++++++-------
>  drivers/gpu/drm/tegra/Kconfig             |  1 +
>  drivers/gpu/drm/tegra/dpaux.c             |  7 +++++++
>  5 files changed, 33 insertions(+), 19 deletions(-)
> 

Will we see the v2 anytime soon?