Re: [linux-sunxi] [PATCH v3.1 10/10] arm64: dts: allwinner: a64: Enable HDMI output on A64 boards w/ HDMI

[Jernej Škrabec]

Dne četrtek, 26. julij 2018 ob 19:12:57 CEST je Icenowy Zheng napisal(a):
> From: Jagan Teki 
> 
> Enable all necessary device tree nodes and add connector node to device
> trees for all supported A64 boards with HDMI.
> 
> Signed-off-by: Jagan Teki 
> [Icenowy: squash all board patches altogether and change supply name]
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v3,1:
> - Squash all enablement patches altogether.
> - Change supply name to match DT binding & driver change.
> Changes for v3:
> - Enable all pipeline components
> Changes for v2:
> - none
> 
>  .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 34 +++
>  .../dts/allwinner/sun50i-a64-nanopi-a64.dts   | 34 +++
>  .../dts/allwinner/sun50i-a64-olinuxino.dts| 34 +++
>  .../dts/allwinner/sun50i-a64-orangepi-win.dts | 34 +++
>  .../boot/dts/allwinner/sun50i-a64-pine64.dts  | 34 +++
>  .../allwinner/sun50i-a64-sopine-baseboard.dts | 34 +++
>  6 files changed, 204 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts index
> 094cfed13df9..0d8f5571d574 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> @@ -60,6 +60,17 @@
>   stdout-path = "serial0:115200n8";
>   };
> 
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
>   leds {
>   compatible = "gpio-leds";
> 
> @@ -86,6 +97,10 @@
>   };
>  };
> 
> +&de {
> + status = "okay";
> +};
> +
>  &ehci0 {
>   status = "okay";
>  };
> @@ -103,6 +118,17 @@
>   status = "okay";
>  };
> 
> +&hdmi {
> + hdmi-supply = <®_dldo1>;
> + status = "okay";
> +};
> +
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
> +
>  &i2c1 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&i2c1_pins>;
> @@ -120,6 +146,10 @@
>   };
>  };
> 
> +&mixer1 {
> + status = "okay";
> +};
> +
>  &mmc0 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&mmc0_pins>;
> @@ -300,6 +330,10 @@
>   vcc-hdmi-supply = <®_dldo1>;
>  };
> 
> +&tcon1 {
> + status = "okay";
> +};
> +
>  &uart0 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&uart0_pins_a>;
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts index
> 98dbff19f5cc..2bcf02f46366 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> @@ -57,6 +57,21 @@
>   chosen {
>   stdout-path = "serial0:115200n8";
>   };
> +
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +};
> +
> +&de {
> + status = "okay";
>  };
> 
>  &ehci0 {
> @@ -67,6 +82,17 @@
>   status = "okay";
>  };
> 
> +&hdmi {
> + hdmi-supply = <®_dldo1>;
> + status = "okay";
> +};
> +
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
> +
>  /* i2c1 connected with gpio headers like pine64, bananapi */
>  &i2c1 {
>   pinctrl-names = "default";
> @@ -78,6 +104,10 @@
>   bias-pull-up;
>  };
> 
> +&mixer1 {
> + status = "okay";
> +};
> +
>  &mmc0 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&mmc0_pins>;
> @@ -199,6 +229,10 @@
>   vcc-hdmi-supply = <®_dldo1>;
>  };
> 
> +&tcon1 {
> + status = "okay";
> +};
> +
>  &uart0 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&uart0_pins_a>;
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts index
> 3f531393eaee..5445a7a1db51 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> @@ -58,12 +58,42 @@
>   stdout-path = "serial0:115200n8";
>   };
> 
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
>   wifi_pwrseq: wifi_pwrseq {
>   compatible = "mmc-pwrseq-simple";
>   reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>   };
>  };

[PATCH v3.1 09/10] drm/sun4i: Add support for HDMI voltage regulator

[Icenowy Zheng]

From: Jernej Skrabec 

Some boards have HDMI VCC pin connected to voltage regulator which may
not be turned on by default.

Add support for such boards by adding voltage regulator handling code to
HDMI driver.

Signed-off-by: Jernej Skrabec 
Signed-off-by: Icenowy Zheng 
---
Changes in v3.1:
- New patch. (Replaced "drm: sun4i: add support for HVCC regulator
  for DWC HDMI glue" by Icenowy.)

 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 17 -
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h |  2 ++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 31875b636434..bf7bf4f2fb29 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -125,10 +125,22 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct 
device *master,
return PTR_ERR(hdmi->clk_tmds);
}
 
+   hdmi->regulator = devm_regulator_get(dev, "hdmi");
+   if (IS_ERR(hdmi->regulator)) {
+   dev_err(dev, "Couldn't get regulator\n");
+   return PTR_ERR(hdmi->regulator);
+   }
+
+   ret = regulator_enable(hdmi->regulator);
+   if (ret) {
+   dev_err(dev, "Failed to enable regulator\n");
+   return ret;
+   }
+
ret = reset_control_deassert(hdmi->rst_ctrl);
if (ret) {
dev_err(dev, "Could not deassert ctrl reset control\n");
-   return ret;
+   goto err_disable_regulator;
}
 
ret = clk_prepare_enable(hdmi->clk_tmds);
@@ -183,6 +195,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct 
device *master,
clk_disable_unprepare(hdmi->clk_tmds);
 err_assert_ctrl_reset:
reset_control_assert(hdmi->rst_ctrl);
+err_disable_regulator:
+   regulator_disable(hdmi->regulator);
 
return ret;
 }
@@ -196,6 +210,7 @@ static void sun8i_dw_hdmi_unbind(struct device *dev, struct 
device *master,
sun8i_hdmi_phy_remove(hdmi);
clk_disable_unprepare(hdmi->clk_tmds);
reset_control_assert(hdmi->rst_ctrl);
+   regulator_disable(hdmi->regulator);
 }
 
 static const struct component_ops sun8i_dw_hdmi_ops = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index aadbe0a10b0c..7fdc1ecd2892 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define SUN8I_HDMI_PHY_DBG_CTRL_REG0x
@@ -176,6 +177,7 @@ struct sun8i_dw_hdmi {
struct drm_encoder  encoder;
struct sun8i_hdmi_phy   *phy;
struct dw_hdmi_plat_dataplat_data;
+   struct regulator*regulator;
struct reset_control*rst_ctrl;
 };
 
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [PATCH v3.1 01/10] clk: sunxi-ng: a64: Add minimal rate for video PLLs

[Jernej Škrabec]

Dne četrtek, 26. julij 2018 ob 19:12:48 CEST je Icenowy Zheng napisal(a):
> From: Jagan Teki 
> 
> According to documentation and experience with other similar SoCs, video
> PLLs don't work stable if their output frequency is set below 192 MHz.
> 
> Because of that, set minimal rate to both A64 video PLLs to 192 MHz.
> 
> Signed-off-by: Jagan Teki 
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Jernej Skrabec 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3.1 04/10] drm/sun4i: Add support for A64 display engine

[Icenowy Zheng]

From: Jagan Teki 

Display Engine(DE2) in Allwinner A64 has two mixers and tcons.

The routing for mixer0 is through tcon0 and connected to
LVDS/RGB/MIPI-DSI controller.

The routing for mixer1 is through tcon1 and connected to HDMI.

Signed-off-by: Jagan Teki 
Signed-off-by: Icenowy Zheng 
---
Changes for v3.1, v3, v2:
- none

 drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index dd19d674055c..e3c1c436b9d5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -421,6 +421,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun8i-r40-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ .compatible = "allwinner,sun9i-a80-display-engine" },
+   { .compatible = "allwinner,sun50i-a64-display-engine" },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun4i_drv_of_table);
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v1 1/6] driver core: Add option for disabling of backing devices DMA with IOMMU

[Dmitry Osipenko]

This allows device drivers to convey the drivers core that implicit IOMMU
backing for devices DMA shouldn't happen. It is needed for drivers that
manage IOMMU by themselves, like for example it is needed by the NVIDIA
Tegra GPU driver.

Signed-off-by: Dmitry Osipenko 
---
 include/linux/device.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index ad43a97b50c8..f9e3c1d42abd 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -244,6 +244,7 @@ enum probe_type {
  * @bus:   The bus which the device of this driver belongs to.
  * @owner: The module owner.
  * @mod_name:  Used for built-in modules.
+ * @no_implicit_iommu: Disables backing DMA allocations with IOMMU mapping.
  * @suppress_bind_attrs: Disables bind/unbind via sysfs.
  * @probe_type:Type of the probe (synchronous or asynchronous) to use.
  * @of_match_table: The open firmware table.
@@ -281,6 +282,7 @@ struct device_driver {
struct module   *owner;
const char  *mod_name;  /* used for built-in modules */
 
+   bool no_implicit_iommu; /* disables implicit IOMMU for DMA */
bool suppress_bind_attrs;   /* disables bind/unbind via sysfs */
enum probe_type probe_type;
 
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v1 4/6] gpu: host1x: Avoid implicit DMA backing with IOMMU

[Dmitry Osipenko]

Host1x driver manages IOMMU by itself, backing DMA with IOMMU by the
drivers core breaks the Host1x driver.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index afabd33a48d9..0966415d4ccd 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -361,6 +361,7 @@ static int host1x_remove(struct platform_device *pdev)
 static struct platform_driver tegra_host1x_driver = {
.driver = {
.name = "tegra-host1x",
+   .no_implicit_iommu = true,
.of_match_table = host1x_of_match,
},
.probe = host1x_probe,
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/vkms: Use new return type vm_fault_t

[Souptick Joarder]

Use new return type vm_fault_t for fault handler.

Signed-off-by: Souptick Joarder 
---
v2: Updated patch title

 drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
 drivers/gpu/drm/vkms/vkms_gem.c | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 07be29f..d5d04a8 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -65,7 +65,7 @@ struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
   u32 *handle,
   u64 size);
 
-int vkms_gem_fault(struct vm_fault *vmf);
+vm_fault_t vkms_gem_fault(struct vm_fault *vmf);
 
 int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
 struct drm_mode_create_dumb *args);
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index c7e3836..62e05dc 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -43,14 +43,14 @@ void vkms_gem_free_object(struct drm_gem_object *obj)
kfree(gem);
 }
 
-int vkms_gem_fault(struct vm_fault *vmf)
+vm_fault_t vkms_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct vkms_gem_object *obj = vma->vm_private_data;
unsigned long vaddr = vmf->address;
pgoff_t page_offset;
loff_t num_pages;
-   int ret;
+   vm_fault_t ret = VM_FAULT_SIGBUS;
 
page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
num_pages = DIV_ROUND_UP(obj->gem.size, PAGE_SIZE);
@@ -58,7 +58,6 @@ int vkms_gem_fault(struct vm_fault *vmf)
if (page_offset > num_pages)
return VM_FAULT_SIGBUS;
 
-   ret = -ENOENT;
mutex_lock(&obj->pages_lock);
if (obj->pages) {
get_page(obj->pages[page_offset]);
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3.1 06/10] dt-bindings: clock: sun50i-a64-ccu: Add PLL_VIDEO[0-1] macros

[Icenowy Zheng]

From: Jagan Teki 

Allwinner A64 has two clock parents PLL_VIDEO0 and PLL_VIDEO1.

Include these macros on dt-bindings so-that the same can be
used while defining CCU clock phadles.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
Signed-off-by: Icenowy Zheng 
---
Changes for v3.1:
- none
Changes for v3:
- collect Rob r-w-b tag
Changes for v2:
- new patch

 include/dt-bindings/clock/sun50i-a64-ccu.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/clock/sun50i-a64-ccu.h 
b/include/dt-bindings/clock/sun50i-a64-ccu.h
index d66432c6e675..d1d7d5b7d06a 100644
--- a/include/dt-bindings/clock/sun50i-a64-ccu.h
+++ b/include/dt-bindings/clock/sun50i-a64-ccu.h
@@ -43,7 +43,9 @@
 #ifndef _DT_BINDINGS_CLK_SUN50I_A64_H_
 #define _DT_BINDINGS_CLK_SUN50I_A64_H_
 
+#define CLK_PLL_VIDEO0 7
 #define CLK_PLL_PERIPH011
+#define CLK_PLL_VIDEO1 15
 
 #define CLK_BUS_MIPI_DSI   28
 #define CLK_BUS_CE 29
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [PATCH v3.1 06/10] dt-bindings: clock: sun50i-a64-ccu: Add PLL_VIDEO[0-1] macros

[Jernej Škrabec]

Dne četrtek, 26. julij 2018 ob 19:12:53 CEST je Icenowy Zheng napisal(a):
> From: Jagan Teki 
> 
> Allwinner A64 has two clock parents PLL_VIDEO0 and PLL_VIDEO1.
> 
> Include these macros on dt-bindings so-that the same can be
> used while defining CCU clock phadles.
> 
> Signed-off-by: Jagan Teki 
> Reviewed-by: Rob Herring 
> Signed-off-by: Icenowy Zheng 
> ---
> Changes for v3.1:
> - none
> Changes for v3:
> - collect Rob r-w-b tag
> Changes for v2:
> - new patch
> 
>  include/dt-bindings/clock/sun50i-a64-ccu.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/dt-bindings/clock/sun50i-a64-ccu.h
> b/include/dt-bindings/clock/sun50i-a64-ccu.h index
> d66432c6e675..d1d7d5b7d06a 100644
> --- a/include/dt-bindings/clock/sun50i-a64-ccu.h
> +++ b/include/dt-bindings/clock/sun50i-a64-ccu.h
> @@ -43,7 +43,9 @@
>  #ifndef _DT_BINDINGS_CLK_SUN50I_A64_H_
>  #define _DT_BINDINGS_CLK_SUN50I_A64_H_
> 
> +#define CLK_PLL_VIDEO0   7
>  #define CLK_PLL_PERIPH0  11
> +#define CLK_PLL_VIDEO1   15
> 
>  #define CLK_BUS_MIPI_DSI 28
>  #define CLK_BUS_CE   29

You should remove above definitions from drivers/clk/sunxi-ng/ccu-sun50i-a64.h

Best regards,
Jernej



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] gpu/drm/exynos: Convert drm_atomic_helper_suspend/resume()

[Souptick Joarder]

convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().

exynos_drm_fbdev_suspend/resume can be removed
as drm_mode_config_helper_suspend/resume has
implement the same in generic way.

Signed-off-by: Souptick Joarder 
Signed-off-by: Ajit Negi 
---
v2: Address Inki Dae's comment. Remove
ret variable from both suspend/resume
function.

 drivers/gpu/drm/exynos/exynos_drm_drv.c   | 26 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 17 -
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 --
 3 files changed, 4 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index a81b4a5..46d28cd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -151,39 +151,21 @@ static void exynos_drm_postclose(struct drm_device *dev, 
struct drm_file *file)
 static int exynos_drm_suspend(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
-   struct exynos_drm_private *private;
 
-   if (pm_runtime_suspended(dev) || !drm_dev)
+   if (pm_runtime_suspended(dev))
return 0;
 
-   private = drm_dev->dev_private;
-
-   drm_kms_helper_poll_disable(drm_dev);
-   exynos_drm_fbdev_suspend(drm_dev);
-   private->suspend_state = drm_atomic_helper_suspend(drm_dev);
-   if (IS_ERR(private->suspend_state)) {
-   exynos_drm_fbdev_resume(drm_dev);
-   drm_kms_helper_poll_enable(drm_dev);
-   return PTR_ERR(private->suspend_state);
-   }
-
-   return 0;
+   return drm_mode_config_helper_suspend(drm_dev);
 }
 
 static int exynos_drm_resume(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
-   struct exynos_drm_private *private;
 
-   if (pm_runtime_suspended(dev) || !drm_dev)
+   if (pm_runtime_suspended(dev))
return 0;
 
-   private = drm_dev->dev_private;
-   drm_atomic_helper_resume(drm_dev, private->suspend_state);
-   exynos_drm_fbdev_resume(drm_dev);
-   drm_kms_helper_poll_enable(drm_dev);
-
-   return 0;
+   return drm_mode_config_helper_resume(drm_dev);
 }
 #endif
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 132dd52..918dd2c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -270,20 +270,3 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
private->fb_helper = NULL;
 }
 
-void exynos_drm_fbdev_suspend(struct drm_device *dev)
-{
-   struct exynos_drm_private *private = dev->dev_private;
-
-   console_lock();
-   drm_fb_helper_set_suspend(private->fb_helper, 1);
-   console_unlock();
-}
-
-void exynos_drm_fbdev_resume(struct drm_device *dev)
-{
-   struct exynos_drm_private *private = dev->dev_private;
-
-   console_lock();
-   drm_fb_helper_set_suspend(private->fb_helper, 0);
-   console_unlock();
-}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
index b338472..6840b6a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
@@ -19,8 +19,6 @@
 
 int exynos_drm_fbdev_init(struct drm_device *dev);
 void exynos_drm_fbdev_fini(struct drm_device *dev);
-void exynos_drm_fbdev_suspend(struct drm_device *drm);
-void exynos_drm_fbdev_resume(struct drm_device *drm);
 
 #else
 
@@ -39,14 +37,6 @@ static inline void exynos_drm_fbdev_restore_mode(struct 
drm_device *dev)
 
 #define exynos_drm_output_poll_changed (NULL)
 
-static inline void exynos_drm_fbdev_suspend(struct drm_device *drm)
-{
-}
-
-static inline void exynos_drm_fbdev_resume(struct drm_device *drm)
-{
-}
-
 #endif
 
 #endif
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3.1 03/10] drm/sun4i: Add support for A64 mixers

[Icenowy Zheng]

From: Jagan Teki 

Mixers in Allwinner have similar capabilities as others SoCs with DE2.

Add support for them.

Signed-off-by: Jagan Teki 
[Icenowy: Add mixer0]
Signed-off-by: Icenowy Zheng 
---
Changes for v3.1:
- Add mixer0
Changes for v3:
- none 
Changes for v2:
- New patch

 drivers/gpu/drm/sun4i/sun8i_mixer.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index fc3713608f78..8b3d02b146b7 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -569,6 +569,22 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.mod_rate = 15000,
 };
 
+static const struct sun8i_mixer_cfg sun50i_a64_mixer0_cfg = {
+   .ccsc   = 0,
+   .mod_rate   = 29700,
+   .scaler_mask= 0xf,
+   .ui_num = 3,
+   .vi_num = 1,
+};
+
+static const struct sun8i_mixer_cfg sun50i_a64_mixer1_cfg = {
+   .ccsc   = 1,
+   .mod_rate   = 29700,
+   .scaler_mask= 0x3,
+   .ui_num = 1,
+   .vi_num = 1,
+};
+
 static const struct of_device_id sun8i_mixer_of_table[] = {
{
.compatible = "allwinner,sun8i-a83t-de2-mixer-0",
@@ -594,6 +610,14 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
},
+   {
+   .compatible = "allwinner,sun50i-a64-de2-mixer-0",
+   .data = &sun50i_a64_mixer0_cfg,
+   },
+   {
+   .compatible = "allwinner,sun50i-a64-de2-mixer-1",
+   .data = &sun50i_a64_mixer1_cfg,
+   },
{ }
 };
 MODULE_DEVICE_TABLE(of, sun8i_mixer_of_table);
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu/drm/hisilicon: Convert drm_atomic_helper_suspend/resume()

[Souptick Joarder]

On Thu, Jul 19, 2018 at 9:34 PM, Souptick Joarder  wrote:
> convert drm_atomic_helper_suspend/resume() to use
> drm_mode_config_helper_suspend/resume().
>
> Fixed one sparse warning by making hibmc_drm_interrupt
> static.
>
> Signed-off-by: Souptick Joarder 
> Signed-off-by: Ajit Negi 
> ---

Any comment on this patch ?

>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index d4f6f1f..2261676 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -37,7 +37,7 @@
> .llseek = no_llseek,
>  };
>
> -irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
> +static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>  {
> struct drm_device *dev = (struct drm_device *)arg;
> struct hibmc_drm_private *priv =
> @@ -74,30 +74,22 @@ static int __maybe_unused hibmc_pm_suspend(struct device 
> *dev)
>  {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> -   struct hibmc_drm_private *priv = drm_dev->dev_private;
> -
> -   drm_kms_helper_poll_disable(drm_dev);
> -   priv->suspend_state = drm_atomic_helper_suspend(drm_dev);
> -   if (IS_ERR(priv->suspend_state)) {
> -   DRM_ERROR("drm_atomic_helper_suspend failed: %ld\n",
> - PTR_ERR(priv->suspend_state));
> -   drm_kms_helper_poll_enable(drm_dev);
> -   return PTR_ERR(priv->suspend_state);
> -   }
> +   int ret = 0;
>
> -   return 0;
> +   ret = drm_mode_config_helper_suspend(drm_dev);
> +
> +   return ret;
>  }
>
>  static int  __maybe_unused hibmc_pm_resume(struct device *dev)
>  {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> -   struct hibmc_drm_private *priv = drm_dev->dev_private;
> +   int ret = 0;
>
> -   drm_atomic_helper_resume(drm_dev, priv->suspend_state);
> -   drm_kms_helper_poll_enable(drm_dev);
> +   ret = drm_mode_config_helper_resume(drm_dev);
>
> -   return 0;
> +   return ret;
>  }
>
>  static const struct dev_pm_ops hibmc_pm_ops = {
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v1 2/6] of/device: Don't back devices DMA with IOMMU if that's undesired by driver

[Dmitry Osipenko]

Respect device driver requirement for device DMA not to be implicitly
backed with IOMMU by skipping the backing setup for drivers that do not
want that.

Signed-off-by: Dmitry Osipenko 
---
 drivers/of/device.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 33d85511d790..e70b7a886875 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -163,6 +163,13 @@ int of_dma_configure(struct device *dev, struct 
device_node *np, bool force_dma)
dev_dbg(dev, "device is%sbehind an iommu\n",
iommu ? " " : " not ");
 
+   /*
+* Respect device driver requirement for device DMA not to be
+* implicitly backed with IOMMU.
+*/
+   if (iommu && dev->driver->no_implicit_iommu)
+   iommu = NULL;
+
arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
 
return 0;
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [PATCH v3.1 10/10] arm64: dts: allwinner: a64: Enable HDMI output on A64 boards w/ HDMI

[Icenowy Zheng]

于 2018年7月27日 GMT+08:00 上午2:03:00, "Jernej Škrabec"  写到:
>Dne četrtek, 26. julij 2018 ob 19:12:57 CEST je Icenowy Zheng
>napisal(a):
>> From: Jagan Teki 
>> 
>> Enable all necessary device tree nodes and add connector node to
>device
>> trees for all supported A64 boards with HDMI.
>> 
>> Signed-off-by: Jagan Teki 
>> [Icenowy: squash all board patches altogether and change supply name]
>> Signed-off-by: Icenowy Zheng 
>> ---
>> Changes in v3,1:
>> - Squash all enablement patches altogether.
>> - Change supply name to match DT binding & driver change.
>> Changes for v3:
>> - Enable all pipeline components
>> Changes for v2:
>> - none
>> 
>>  .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 34
>+++
>>  .../dts/allwinner/sun50i-a64-nanopi-a64.dts   | 34
>+++
>>  .../dts/allwinner/sun50i-a64-olinuxino.dts| 34
>+++
>>  .../dts/allwinner/sun50i-a64-orangepi-win.dts | 34
>+++
>>  .../boot/dts/allwinner/sun50i-a64-pine64.dts  | 34
>+++
>>  .../allwinner/sun50i-a64-sopine-baseboard.dts | 34
>+++
>>  6 files changed, 204 insertions(+)
>> 
>> diff --git
>a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts index
>> 094cfed13df9..0d8f5571d574 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
>> @@ -60,6 +60,17 @@
>>  stdout-path = "serial0:115200n8";
>>  };
>> 
>> +connector {
>> +compatible = "hdmi-connector";
>> +type = "a";
>> +
>> +port {
>> +hdmi_con_in: endpoint {
>> +remote-endpoint = <&hdmi_out_con>;
>> +};
>> +};
>> +};
>> +
>>  leds {
>>  compatible = "gpio-leds";
>> 
>> @@ -86,6 +97,10 @@
>>  };
>>  };
>> 
>> +&de {
>> +status = "okay";
>> +};
>> +
>>  &ehci0 {
>>  status = "okay";
>>  };
>> @@ -103,6 +118,17 @@
>>  status = "okay";
>>  };
>> 
>> +&hdmi {
>> +hdmi-supply = <®_dldo1>;
>> +status = "okay";
>> +};
>> +
>> +&hdmi_out {
>> +hdmi_out_con: endpoint {
>> +remote-endpoint = <&hdmi_con_in>;
>> +};
>> +};
>> +
>>  &i2c1 {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&i2c1_pins>;
>> @@ -120,6 +146,10 @@
>>  };
>>  };
>> 
>> +&mixer1 {
>> +status = "okay";
>> +};
>> +
>>  &mmc0 {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&mmc0_pins>;
>> @@ -300,6 +330,10 @@
>>  vcc-hdmi-supply = <®_dldo1>;
>>  };
>> 
>> +&tcon1 {
>> +status = "okay";
>> +};
>> +
>>  &uart0 {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&uart0_pins_a>;
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts index
>> 98dbff19f5cc..2bcf02f46366 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> @@ -57,6 +57,21 @@
>>  chosen {
>>  stdout-path = "serial0:115200n8";
>>  };
>> +
>> +connector {
>> +compatible = "hdmi-connector";
>> +type = "a";
>> +
>> +port {
>> +hdmi_con_in: endpoint {
>> +remote-endpoint = <&hdmi_out_con>;
>> +};
>> +};
>> +};
>> +};
>> +
>> +&de {
>> +status = "okay";
>>  };
>> 
>>  &ehci0 {
>> @@ -67,6 +82,17 @@
>>  status = "okay";
>>  };
>> 
>> +&hdmi {
>> +hdmi-supply = <®_dldo1>;
>> +status = "okay";
>> +};
>> +
>> +&hdmi_out {
>> +hdmi_out_con: endpoint {
>> +remote-endpoint = <&hdmi_con_in>;
>> +};
>> +};
>> +
>>  /* i2c1 connected with gpio headers like pine64, bananapi */
>>  &i2c1 {
>>  pinctrl-names = "default";
>> @@ -78,6 +104,10 @@
>>  bias-pull-up;
>>  };
>> 
>> +&mixer1 {
>> +status = "okay";
>> +};
>> +
>>  &mmc0 {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&mmc0_pins>;
>> @@ -199,6 +229,10 @@
>>  vcc-hdmi-supply = <®_dldo1>;
>>  };
>> 
>> +&tcon1 {
>> +status = "okay";
>> +};
>> +
>>  &uart0 {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&uart0_pins_a>;
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts index
>> 3f531393eaee..5445a7a1db51 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>> @@ -58,12 +58,42 @@
>>  stdout-path = "serial0:115200n8";
>>  };
>> 
>> +connector {
>> +compatible = "hdmi-connector";
>> +type = "a";
>> +
>> +port {
>> +hdmi_con_in: endpoint {
>> +remote-endpoint = <&hdmi_out_con>;
>> +};
>> +};
>> +

[PATCH v3.1 05/10] dt-bindings: display: Add compatible for A64 HDMI

[Icenowy Zheng]

From: Jagan Teki 

The HDMI controller on Allwinner A64 is similar on the one on
H3/H5/A83T (although the PHY is different with A83T).

Add A64 compatible and append A83T compatible as fallback.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
[Icenowy: refactor commit log]
Signed-off-by: Icenowy Zheng 
---
Changes for v3.1:
- Refactor commit log to make it more clear.
Changes for v3:
- collect Rob r-w-b tag
Changes for v2:
- Add fallback compatible

 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 7b79c5e3dffc..fdb8fb29033f 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -78,6 +78,7 @@ Required properties:
 
   - compatible: value must be one of:
 * "allwinner,sun8i-a83t-dw-hdmi"
+* "allwinner,sun50i-a64-dw-hdmi", "allwinner,sun8i-a83t-dw-hdmi"
   - reg: base address and size of memory-mapped region
   - reg-io-width: See dw_hdmi.txt. Shall be 1.
   - interrupts: HDMI interrupt number
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v1 3/6] drm/tegra: Avoid implicit DMA backing with IOMMU

[Dmitry Osipenko]

Tegra DRM manages IOMMU by itself, backing DMA with IOMMU by the drivers
core breaks the Tegra driver.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/dc.c   | 1 +
 drivers/gpu/drm/tegra/gr2d.c | 1 +
 drivers/gpu/drm/tegra/gr3d.c | 1 +
 drivers/gpu/drm/tegra/vic.c  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index eb9bb83f8f5d..4827770939e3 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2675,6 +2675,7 @@ static const struct dev_pm_ops tegra_dc_pm_ops = {
 struct platform_driver tegra_dc_driver = {
.driver = {
.name = "tegra-dc",
+   .no_implicit_iommu = true,
.of_match_table = tegra_dc_of_match,
.pm = &tegra_dc_pm_ops,
},
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 3c5503f1bf3d..e427585ef5cc 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -327,6 +327,7 @@ static int gr2d_remove(struct platform_device *pdev)
 struct platform_driver tegra_gr2d_driver = {
.driver = {
.name = "tegra-gr2d",
+   .no_implicit_iommu = true,
.of_match_table = gr2d_match,
},
.probe = gr2d_probe,
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 651e697ccbba..f54710c36afb 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -481,6 +481,7 @@ static int gr3d_remove(struct platform_device *pdev)
 struct platform_driver tegra_gr3d_driver = {
.driver = {
.name = "tegra-gr3d",
+   .no_implicit_iommu = true,
.of_match_table = tegra_gr3d_match,
},
.probe = gr3d_probe,
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 0e6642bb8524..4ecc466ee490 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -402,6 +402,7 @@ static const struct dev_pm_ops vic_pm_ops = {
 struct platform_driver tegra_vic_driver = {
.driver = {
.name = "tegra-vic",
+   .no_implicit_iommu = true,
.of_match_table = vic_match,
.pm = &vic_pm_ops
},
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

[Dmitry Osipenko]

Hello,

There is a trouble on ARM with DMA allocations made by device drivers,
the trouble is that DMA allocations are getting implicitly backed with
IOMMU mapping by the driver core if IOMMU presents in a system and IOMMU
could handle device. This is an undesired behaviour for drivers that
manage IOMMU by themselves, like NVIDIA Tegra GPU driver. On arm32 the
implicit backing happens if CONFIG_ARM_DMA_USE_IOMMU=y (multiplatform
kernel configuration), on arm64 it happens if IOMMU domain type for a
device is equal to IOMMU_DOMAIN_DMA.

The proposed solution adds a new option to the base device driver
structure that allows device drivers to explicitly convey to the drivers
core that the implicit IOMMU backing for devices must not happen.

Dmitry Osipenko (6):
  driver core: Add option for disabling of backing devices DMA with
IOMMU
  of/device: Don't back devices DMA with IOMMU if that's undesired by
driver
  drm/tegra: Avoid implicit DMA backing with IOMMU
  gpu: host1x: Avoid implicit DMA backing with IOMMU
  drm/nouveau: tegra: Universally avoid implicit DMA backing with IOMMU
  Revert "drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping"

 drivers/gpu/drm/nouveau/nouveau_platform.c |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 -
 drivers/gpu/drm/tegra/dc.c |  1 +
 drivers/gpu/drm/tegra/gr2d.c   |  1 +
 drivers/gpu/drm/tegra/gr3d.c   |  1 +
 drivers/gpu/drm/tegra/vic.c|  1 +
 drivers/gpu/host1x/dev.c   |  1 +
 drivers/of/device.c|  7 +++
 include/linux/device.h |  2 ++
 9 files changed, 15 insertions(+), 13 deletions(-)

-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3.1 01/10] clk: sunxi-ng: a64: Add minimal rate for video PLLs

[Icenowy Zheng]

From: Jagan Teki 

According to documentation and experience with other similar SoCs, video
PLLs don't work stable if their output frequency is set below 192 MHz.

Because of that, set minimal rate to both A64 video PLLs to 192 MHz.

Signed-off-by: Jagan Teki 
Signed-off-by: Icenowy Zheng 
---
Changes for v3.1, v3:
- none 
Changes for v2:
- New patch

 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 46 ++-
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index ee9c12cf3f08..d0e30192f0cf 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -64,17 +64,18 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, 
"pll-audio-base",
   BIT(28), /* lock */
   CLK_SET_RATE_UNGATE);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
-   "osc24M", 0x010,
-   8, 7,   /* N */
-   0, 4,   /* M */
-   BIT(24),/* frac enable */
-   BIT(25),/* frac select */
-   27000,  /* frac rate 0 */
-   29700,  /* frac rate 1 */
-   BIT(31),/* gate */
-   BIT(28),/* lock */
-   CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video0_clk, "pll-video0",
+   "osc24M", 0x010,
+   19200,  /* Minimum rate */
+   8, 7,   /* N */
+   0, 4,   /* M */
+   BIT(24),/* frac enable */
+   BIT(25),/* frac select */
+   27000,  /* frac rate 0 */
+   29700,  /* frac rate 1 */
+   BIT(31),/* gate */
+   BIT(28),/* lock */
+   CLK_SET_RATE_UNGATE);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
"osc24M", 0x018,
@@ -125,17 +126,18 @@ static struct ccu_nk pll_periph1_clk = {
},
 };
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
-   "osc24M", 0x030,
-   8, 7,   /* N */
-   0, 4,   /* M */
-   BIT(24),/* frac enable */
-   BIT(25),/* frac select */
-   27000,  /* frac rate 0 */
-   29700,  /* frac rate 1 */
-   BIT(31),/* gate */
-   BIT(28),/* lock */
-   CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video1_clk, "pll-video1",
+   "osc24M", 0x030,
+   19200,  /* Minimum rate */
+   8, 7,   /* N */
+   0, 4,   /* M */
+   BIT(24),/* frac enable */
+   BIT(25),/* frac select */
+   27000,  /* frac rate 0 */
+   29700,  /* frac rate 1 */
+   BIT(31),/* gate */
+   BIT(28),/* lock */
+   CLK_SET_RATE_UNGATE);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
"osc24M", 0x038,
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v1 5/6] drm/nouveau: tegra: Universally avoid implicit DMA backing with IOMMU

[Dmitry Osipenko]

Implicit backing DMA with IOMMU breaks Nouveau on Tegra, the current
approach with detaching device from IOMMU that was added in commit
b59fb482b522 ("drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping")
works only for arm32 which has the CONFIG_ARM_DMA_USE_IOMMU, but not for
arm64 which doesn't have that config option. Drivers core now allows to
avoid the implicit backing, that is a universal solution unlike the
current variant with the detaching.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/nouveau/nouveau_platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c 
b/drivers/gpu/drm/nouveau/nouveau_platform.c
index 039e23548e08..0b57f4f9b638 100644
--- a/drivers/gpu/drm/nouveau/nouveau_platform.c
+++ b/drivers/gpu/drm/nouveau/nouveau_platform.c
@@ -90,6 +90,7 @@ MODULE_DEVICE_TABLE(of, nouveau_platform_match);
 struct platform_driver nouveau_platform_driver = {
.driver = {
.name = "nouveau",
+   .no_implicit_iommu = true,
.of_match_table = of_match_ptr(nouveau_platform_match),
},
.probe = nouveau_platform_probe,
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [linux-sunxi] [PATCH v3.1 03/10] drm/sun4i: Add support for A64 mixers

[Jernej Škrabec]

Dne četrtek, 26. julij 2018 ob 19:12:50 CEST je Icenowy Zheng napisal(a):
> From: Jagan Teki 
> 
> Mixers in Allwinner have similar capabilities as others SoCs with DE2.
> 
> Add support for them.
> 
> Signed-off-by: Jagan Teki 
> [Icenowy: Add mixer0]
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Jernej Skrabec 

Best regards,
Jernej



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[BUG] video: fbdev: broadsheetfb: Possible null function pointers

[bai]

In Linux-4.16, drivers/video/fbdev/broadsheetfb.c,

158. static void broadsheet_mmio_send_cmdargs(...) {
    ..
163. par->board->mmio_write(...);
    ..
166. par->board->mmio_write(...);
167. }

For x86 kernel configuration, I find that there is no assignment of the 
function pointer ".mmio_write" in the kernel code.
So calling the function pointer in lines 163 and 166 may cause a null 
pointer dereference.


In this file, there are many calls to this function pointer...


Best wishes,
Jia-Ju Bai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3.1 02/10] dt-bindings: display: Add compatible for A64 DE2 display pipeline

[Icenowy Zheng]

From: Jagan Teki 

Allwinner A64 has a DE2 display pipeline. The TCONs are similar to the
ones in A83T, but the mixers are new (similar to the later R40 SoC).

This patch adds dt-binding documentation for A64 DE2 display pipeline.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
[Icenowy: Refactor and also cover TCON0]
Signed-off-by: Icenowy Zheng 
---
Changes for v3.1:
- added mixer0 and TCON0
Changes for v3:
- collect Rob r-w-b tag
Changes for v2:
- Add fallback compatible for tcon1
- Add separate compatible for mixer1 

 .../devicetree/bindings/display/sunxi/sun4i-drm.txt  | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index f8773ecb7525..7b79c5e3dffc 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -151,6 +151,8 @@ Required properties:
* allwinner,sun8i-v3s-tcon
* allwinner,sun9i-a80-tcon-lcd
* allwinner,sun9i-a80-tcon-tv
+   * "allwinner,sun50i-a64-tcon-lcd", "allwinner,sun8i-a83t-tcon-lcd"
+   * "allwinner,sun50i-a64-tcon-tv", "allwinner,sun8i-a83t-tcon-tv"
  - reg: base address and size of memory-mapped region
  - interrupts: interrupt associated to this IP
  - clocks: phandles to the clocks feeding the TCON.
@@ -370,6 +372,8 @@ Required properties:
 * allwinner,sun8i-a83t-de2-mixer-1
 * allwinner,sun8i-h3-de2-mixer-0
 * allwinner,sun8i-v3s-de2-mixer
+* allwinner,sun50i-a64-de2-mixer-0
+* allwinner,sun50i-a64-de2-mixer-1
   - reg: base address and size of the memory-mapped region.
   - clocks: phandles to the clocks feeding the mixer
 * bus: the mixer interface clock
@@ -403,6 +407,7 @@ Required properties:
 * allwinner,sun8i-r40-display-engine
 * allwinner,sun8i-v3s-display-engine
 * allwinner,sun9i-a80-display-engine
+* allwinner,sun50i-a64-display-engine
 
   - allwinner,pipelines: list of phandle to the display engine
 frontends (DE 1.0) or mixers (DE 2.0) available.
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] video: fbdev: broadsheetfb: Possible null function pointers

[Jia-Ju Bai]

On 2018/7/26 22:34, Bartlomiej Zolnierkiewicz wrote:

On Thursday, July 26, 2018 10:17:44 PM bai wrote:

In Linux-4.16, drivers/video/fbdev/broadsheetfb.c,

158. static void broadsheet_mmio_send_cmdargs(...) {
  ..
163. par->board->mmio_write(...);
  ..
166. par->board->mmio_write(...);
167. }

For x86 kernel configuration, I find that there is no assignment of the
function pointer ".mmio_write" in the kernel code.
So calling the function pointer in lines 163 and 166 may cause a null
pointer dereference.

In this file, there are many calls to this function pointer...

This is a platform driver and it won't be used on x86 (actually it is
used only by single ARM PXA board). The dependency for FB_BROADSHEET
in Kconfig file could be improved to i.e.

depends on FB && (ARCH_PXA || COMPILE_TEST)

but there is no bug there.


Thanks for the reply :)
So I want to submit a patch of updating Kconfig in 
drivers/video/fbdev/Kconfig:


config FB_BROADSHEET
tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
-depends on FB
+   depends on FB && (ARCH_PXA || COMPILE_TEST)
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO


Do you think it is okay?


Best wishes,
Jia-Ju Bai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] backlight: pwm_bl: switch to using "atomic" PWM API

[Enric Balletbo i Serra]

The "atomic" API allows us to configure PWM period and duty_cycle and
enable it in one call.

The patch also moves the pwm_init_state just before any use of the
pwm_state struct, this fixes a potential bug where pwm_get_state
can be called before pwm_init_state.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/video/backlight/pwm_bl.c | 48 
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index bdfcc0a71db1..2c734d55d607 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -46,7 +46,8 @@ struct pwm_bl_data {
void(*exit)(struct device *);
 };
 
-static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness)
+static void pwm_backlight_power_on(struct pwm_bl_data *pb,
+  struct pwm_state *state)
 {
int err;
 
@@ -57,7 +58,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, 
int brightness)
if (err < 0)
dev_err(pb->dev, "failed to enable power supply\n");
 
-   pwm_enable(pb->pwm);
+   state->enabled = true;
+   pwm_apply_state(pb->pwm, state);
 
if (pb->post_pwm_on_delay)
msleep(pb->post_pwm_on_delay);
@@ -70,6 +72,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, 
int brightness)
 
 static void pwm_backlight_power_off(struct pwm_bl_data *pb)
 {
+   struct pwm_state state;
+
if (!pb->enabled)
return;
 
@@ -79,8 +83,11 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
if (pb->pwm_off_delay)
msleep(pb->pwm_off_delay);
 
-   pwm_config(pb->pwm, 0, pb->period);
-   pwm_disable(pb->pwm);
+   pwm_get_state(pb->pwm, &state);
+   state.enabled = false;
+   state.period = pb->period;
+   state.duty_cycle = 0;
+   pwm_apply_state(pb->pwm, &state);
 
regulator_disable(pb->power_supply);
pb->enabled = false;
@@ -106,6 +113,7 @@ static int pwm_backlight_update_status(struct 
backlight_device *bl)
 {
struct pwm_bl_data *pb = bl_get_data(bl);
int brightness = bl->props.brightness;
+   struct pwm_state state;
int duty_cycle;
 
if (bl->props.power != FB_BLANK_UNBLANK ||
@@ -118,8 +126,13 @@ static int pwm_backlight_update_status(struct 
backlight_device *bl)
 
if (brightness > 0) {
duty_cycle = compute_duty_cycle(pb, brightness);
-   pwm_config(pb->pwm, duty_cycle, pb->period);
-   pwm_backlight_power_on(pb, brightness);
+   pwm_get_state(pb->pwm, &state);
+   state.duty_cycle = duty_cycle;
+   state.period = pb->period;
+   if (!state.enabled)
+   pwm_backlight_power_on(pb, &state);
+   else
+   pwm_apply_state(pb->pwm, &state);
} else
pwm_backlight_power_off(pb);
 
@@ -447,7 +460,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct pwm_bl_data *pb;
struct pwm_state state;
-   struct pwm_args pargs;
unsigned int i;
int ret;
 
@@ -539,10 +551,17 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
 
dev_dbg(&pdev->dev, "got pwm for backlight\n");
 
-   if (!data->levels) {
-   /* Get the PWM period (in nanoseconds) */
-   pwm_get_state(pb->pwm, &state);
+   /* Sync up PWM state and ensure it is off. */
+   pwm_init_state(pb->pwm, &state);
+   state.enabled = false;
+   ret = pwm_apply_state(pb->pwm, &state);
+   if (ret) {
+   dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
+   ret);
+   goto err_alloc;
+   }
 
+   if (!data->levels) {
ret = pwm_backlight_brightness_default(&pdev->dev, data,
   state.period);
if (ret < 0) {
@@ -559,20 +578,13 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
pb->levels = data->levels;
}
 
-   /*
-* FIXME: pwm_apply_args() should be removed when switching to
-* the atomic PWM API.
-*/
-   pwm_apply_args(pb->pwm);
-
/*
 * The DT case will set the pwm_period_ns field to 0 and store the
 * period, parsed from the DT, in the PWM device. For the non-DT case,
 * set the period from platform data if it has not already been set
 * via the PWM lookup table.
 */
-   pwm_get_args(pb->pwm, &pargs);
-   pb->period = pargs.period;
+   pb->period = state.period;
if (!pb->period && (data->pwm_period_ns > 0))
pb->period = data->pwm_period_ns;
 
-- 
2.18.0

___
dri-d

[PATCH] fb: amifb: fix build warnings when not builtin

[Randy Dunlap]

From: Randy Dunlap 

Fix build warning when built as a loadable module.
amifb_setup() and amifb_setup_mcap() are only needed when the driver
is builtin.
This matches how the functions are called (using #ifndef MODULE).

../drivers/video/fbdev/amifb.c:2344:19: warning: 'amifb_setup' defined but not 
used [-Wunused-function]
 static int __init amifb_setup(char *options)

../drivers/video/fbdev/amifb.c:2307:20: warning: 'amifb_setup_mcap' defined but 
not used [-Wunused-function]
 static void __init amifb_setup_mcap(char *spec)

Signed-off-by: Randy Dunlap 
Cc: Geert Uytterhoeven 
Cc: Bartlomiej Zolnierkiewicz 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
---
 drivers/video/fbdev/amifb.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-next-20180717.orig/drivers/video/fbdev/amifb.c
+++ linux-next-20180717/drivers/video/fbdev/amifb.c
@@ -2303,7 +2303,7 @@ static void ami_build_copper(struct fb_i
ami_rebuild_copper(info->par);
 }
 
-
+#ifndef MODULE
 static void __init amifb_setup_mcap(char *spec)
 {
char *p;
@@ -2368,7 +2368,7 @@ static int __init amifb_setup(char *opti
 
return 0;
 }
-
+#endif
 
 static int amifb_check_var(struct fb_var_screeninfo *var,
   struct fb_info *info)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v1 6/6] Revert "drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping"

[Dmitry Osipenko]

Improper DMA backing with IOMMU has been resolved now using the new
drivers core option that allows to avoid the implicit backing, hence
detaching isn't necessary anymore.

This reverts commit b59fb482b52269977ee5de205308e5b236a03917.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 0e372a190d3f..78597da6313a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -23,10 +23,6 @@
 #ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
 #include "priv.h"
 
-#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
-#include 
-#endif
-
 static int
 nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
 {
@@ -109,15 +105,6 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra 
*tdev)
unsigned long pgsize_bitmap;
int ret;
 
-#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
-   if (dev->archdata.mapping) {
-   struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-
-   arm_iommu_detach_device(dev);
-   arm_iommu_release_mapping(mapping);
-   }
-#endif
-
if (!tdev->func->iommu_bit)
return;
 
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3.1 00/10] arm64: allwinner: Add A64 DE2 HDMI support

[Icenowy Zheng]

Allwinner A64 has display engine pipeline like other Allwinner SOC's A83T/H3/H5.

A64 behaviour similar to Allwinner A83T where
Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
Mixer1 => TCON1 => HDMI
as per Display System Block Diagram from the A64 user manual.

This is third patch-set followed with previous RFC[1], first and second
series[2][3] and merely concentrated on HDMI pipeline through TCON1 and
rest will add eventually.

I just rebased and slightly re-integrated the patchset according to the
requirments of the maintainer, and added the mixer0->tcon0 pipeline.
The further maintainship of the patchset still needs to be discussed
between I and Jagan.

--Icenowy

Icenowy Zheng (1):
  dt-bindings: sun4i-drm: add HDMI VCC supply property for sun8i-dw-hdmi

Jagan Teki (8):
  clk: sunxi-ng: a64: Add minimal rate for video PLLs
  dt-bindings: display: Add compatible for A64 DE2 display pipeline
  drm/sun4i: Add support for A64 mixers
  drm/sun4i: Add support for A64 display engine
  dt-bindings: display: Add compatible for A64 HDMI
  dt-bindings: clock: sun50i-a64-ccu: Add PLL_VIDEO[0-1] macros
  arm64: dts: allwinner: a64: Add display pipeline
  arm64: dts: allwinner: a64: Enable HDMI output on A64 boards w/ HDMI

Jernej Skrabec (1):
  drm/sun4i: Add support for HDMI voltage regulator

 .../bindings/display/sunxi/sun4i-drm.txt  |   9 +
 .../dts/allwinner/sun50i-a64-bananapi-m64.dts |  34 
 .../dts/allwinner/sun50i-a64-nanopi-a64.dts   |  34 
 .../dts/allwinner/sun50i-a64-olinuxino.dts|  34 
 .../dts/allwinner/sun50i-a64-orangepi-win.dts |  34 
 .../boot/dts/allwinner/sun50i-a64-pine64.dts  |  34 
 .../allwinner/sun50i-a64-sopine-baseboard.dts |  34 
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 169 ++
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c |  46 ++---
 drivers/gpu/drm/sun4i/sun4i_drv.c |   1 +
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c |  17 +-
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h |   2 +
 drivers/gpu/drm/sun4i/sun8i_mixer.c   |  24 +++
 include/dt-bindings/clock/sun50i-a64-ccu.h|   2 +
 14 files changed, 451 insertions(+), 23 deletions(-)

-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3.1 07/10] arm64: dts: allwinner: a64: Add display pipeline

[Icenowy Zheng]

From: Jagan Teki 

Allwinner A64 have a display pipeline with 2 mixers/TCONs, the first
TCON is connected to LCD and the second is to HDMI.

The HDMI controller/PHY pair is similar to the one on H3/H5, but have
two video PLLs selectable.

Add all required device tree nodes of the display pipeline, including
the TCON0 LCD one and the TCON1 HDMI one.

Signed-off-by: Jagan Teki 
[Icenowy: refactor commit message and add 1st pipeline]
Signed-off-by: Icenowy Zheng 
---
Changes for v3.1:
- Refactor commit message to make it more clear.
- Added first pipeline (mixer0 -> tcon0)
Changes for v3:
- Squash all pipeline components in one patch
- Add status for mixer1 and tcon1
Changes for v2:
- Change compatibles and other based on previous patch changes

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 169 ++
 1 file changed, 169 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index d3daf90a8715..fe9cc673fe07 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -112,6 +112,12 @@
};
};
 
+   de: display-engine {
+   compatible = "allwinner,sun50i-a64-display-engine";
+   allwinner,pipelines = <&mixer1>;
+   status = "disabled";
+   };
+
osc24M: osc24M_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -194,6 +200,55 @@
#clock-cells = <1>;
#reset-cells = <1>;
};
+
+   mixer0: mixer@10 {
+   compatible = "allwinner,sun50i-a64-de2-mixer-0";
+   reg = <0x10 0x10>;
+   clocks = <&display_clocks CLK_BUS_MIXER0>,
+<&display_clocks CLK_MIXER0>;
+   clock-names = "bus",
+ "mod";
+   resets = <&display_clocks RST_MIXER0>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer0_out: port@1 {
+   reg = <1>;
+
+   mixer0_out_tcon0: endpoint {
+   remote-endpoint = 
<&tcon0_in_mixer0>;
+   };
+   };
+   };
+   };
+
+   mixer1: mixer@20 {
+   compatible = "allwinner,sun50i-a64-de2-mixer-1";
+   reg = <0x20 0x10>;
+   clocks = <&display_clocks CLK_BUS_MIXER1>,
+<&display_clocks CLK_MIXER1>;
+   clock-names = "bus",
+ "mod";
+   /* The reset line is shared */
+   resets = <&display_clocks RST_WB>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer1_out: port@1 {
+   reg = <1>;
+
+   mixer1_out_tcon1: endpoint {
+   remote-endpoint = 
<&tcon1_in_mixer1>;
+   };
+   };
+   };
+   };
};
 
syscon: syscon@1c0 {
@@ -228,6 +283,76 @@
#dma-cells = <1>;
};
 
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun50i-a64-tcon-lcd",
+"allwinner,sun8i-a83t-tcon-lcd";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
+   clock-names = "ahb", "tcon-ch0";
+   clock-output-names = "tcon-pixel-clock";
+   resets = <&ccu RST_BUS_TCON0>, <&ccu RST_BUS_LVDS>;
+   reset-names = "lcd", "lvds";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+

Re: [linux-sunxi] [PATCH v3.1 07/10] arm64: dts: allwinner: a64: Add display pipeline

[Jernej Škrabec]

Dne četrtek, 26. julij 2018 ob 19:12:54 CEST je Icenowy Zheng napisal(a):
> From: Jagan Teki 
> 
> Allwinner A64 have a display pipeline with 2 mixers/TCONs, the first
> TCON is connected to LCD and the second is to HDMI.
> 
> The HDMI controller/PHY pair is similar to the one on H3/H5, but have
> two video PLLs selectable.
> 
> Add all required device tree nodes of the display pipeline, including
> the TCON0 LCD one and the TCON1 HDMI one.
> 
> Signed-off-by: Jagan Teki 
> [Icenowy: refactor commit message and add 1st pipeline]
> Signed-off-by: Icenowy Zheng 
> ---
> Changes for v3.1:
> - Refactor commit message to make it more clear.
> - Added first pipeline (mixer0 -> tcon0)
> Changes for v3:
> - Squash all pipeline components in one patch
> - Add status for mixer1 and tcon1
> Changes for v2:
> - Change compatibles and other based on previous patch changes
> 
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 169 ++
>  1 file changed, 169 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
> d3daf90a8715..fe9cc673fe07 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -112,6 +112,12 @@
>   };
>   };
> 
> + de: display-engine {
> + compatible = "allwinner,sun50i-a64-display-engine";
> + allwinner,pipelines = <&mixer1>;
> + status = "disabled";
> + };
> +
>   osc24M: osc24M_clk {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> @@ -194,6 +200,55 @@
>   #clock-cells = <1>;
>   #reset-cells = <1>;
>   };
> +
> + mixer0: mixer@10 {
> + compatible = "allwinner,sun50i-a64-de2-mixer-0";
> + reg = <0x10 0x10>;
> + clocks = <&display_clocks CLK_BUS_MIXER0>,
> +  <&display_clocks CLK_MIXER0>;
> + clock-names = "bus",
> +   "mod";
> + resets = <&display_clocks RST_MIXER0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer0_out: port@1 {
> + reg = <1>;
> +
> + mixer0_out_tcon0: endpoint {
> + remote-endpoint = 
> <&tcon0_in_mixer0>;
> + };
> + };
> + };
> + };
> +
> + mixer1: mixer@20 {
> + compatible = "allwinner,sun50i-a64-de2-mixer-1";
> + reg = <0x20 0x10>;
> + clocks = <&display_clocks CLK_BUS_MIXER1>,
> +  <&display_clocks CLK_MIXER1>;
> + clock-names = "bus",
> +   "mod";
> + /* The reset line is shared */
> + resets = <&display_clocks RST_WB>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer1_out: port@1 {
> + reg = <1>;
> +
> + mixer1_out_tcon1: endpoint {
> + remote-endpoint = 
> <&tcon1_in_mixer1>;
> + };
> + };
> + };
> + };
>   };
> 
>   syscon: syscon@1c0 {
> @@ -228,6 +283,76 @@
>   #dma-cells = <1>;
>   };
> 
> + tcon0: lcd-controller@1c0c000 {
> + compatible = "allwinner,sun50i-a64-tcon-lcd",
> +  "allwinner,sun8i-a83t-tcon-lcd";
> + reg = <0x01c0c000 0x1000>;
> + interrupts = ;
> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
> + clock-names = "ahb", "tcon-ch0";
> + clock-output-names = "tcon-pixel-clock";
> + resets = <&ccu RST_BUS_TCON0>, <&ccu RST_BUS_LVDS>;
> + reset-names = "lcd", "lvds";
> +
> + ports {
> +  

[PATCH v3.1 10/10] arm64: dts: allwinner: a64: Enable HDMI output on A64 boards w/ HDMI

[Icenowy Zheng]

From: Jagan Teki 

Enable all necessary device tree nodes and add connector node to device
trees for all supported A64 boards with HDMI.

Signed-off-by: Jagan Teki 
[Icenowy: squash all board patches altogether and change supply name]
Signed-off-by: Icenowy Zheng 
---
Changes in v3,1:
- Squash all enablement patches altogether.
- Change supply name to match DT binding & driver change.
Changes for v3:
- Enable all pipeline components
Changes for v2:
- none

 .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 34 +++
 .../dts/allwinner/sun50i-a64-nanopi-a64.dts   | 34 +++
 .../dts/allwinner/sun50i-a64-olinuxino.dts| 34 +++
 .../dts/allwinner/sun50i-a64-orangepi-win.dts | 34 +++
 .../boot/dts/allwinner/sun50i-a64-pine64.dts  | 34 +++
 .../allwinner/sun50i-a64-sopine-baseboard.dts | 34 +++
 6 files changed, 204 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 094cfed13df9..0d8f5571d574 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -60,6 +60,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -86,6 +97,10 @@
};
 };
 
+&de {
+   status = "okay";
+};
+
 &ehci0 {
status = "okay";
 };
@@ -103,6 +118,17 @@
status = "okay";
 };
 
+&hdmi {
+   hdmi-supply = <®_dldo1>;
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -120,6 +146,10 @@
};
 };
 
+&mixer1 {
+   status = "okay";
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
@@ -300,6 +330,10 @@
vcc-hdmi-supply = <®_dldo1>;
 };
 
+&tcon1 {
+   status = "okay";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index 98dbff19f5cc..2bcf02f46366 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -57,6 +57,21 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+};
+
+&de {
+   status = "okay";
 };
 
 &ehci0 {
@@ -67,6 +82,17 @@
status = "okay";
 };
 
+&hdmi {
+   hdmi-supply = <®_dldo1>;
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 /* i2c1 connected with gpio headers like pine64, bananapi */
 &i2c1 {
pinctrl-names = "default";
@@ -78,6 +104,10 @@
bias-pull-up;
 };
 
+&mixer1 {
+   status = "okay";
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
@@ -199,6 +229,10 @@
vcc-hdmi-supply = <®_dldo1>;
 };
 
+&tcon1 {
+   status = "okay";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index 3f531393eaee..5445a7a1db51 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -58,12 +58,42 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
};
 };
 
+&de {
+   status = "okay";
+};
+
+&hdmi {
+   hdmi-supply = <®_dldo1>;
+   status = "okay";
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
+&mixer1 {
+   status = "okay";
+};
+
 &mmc0 {
pinctr

[PATCH v3.1 08/10] dt-bindings: sun4i-drm: add HDMI VCC supply property for sun8i-dw-hdmi

[Icenowy Zheng]

Allwiner SoCs with DesignWare HDMI controller all come with a "HVCC"
pin, which is the VCC of HDMI part.

Add a supply property to specify HVCC's regulator in the device tree.

Signed-off-by: Icenowy Zheng 
---
Changes in v3.1:
- New patch.

 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index fdb8fb29033f..cb4769913e89 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -97,6 +97,9 @@ Required properties:
 first port should be the input endpoint. The second should be the
 output, usually to an HDMI connector.
 
+Optional properties:
+  - hdmi-supply: the VCC power supply of the controller
+
 DWC HDMI PHY
 
 
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fb: amifb: fix build warnings when not builtin

[Geert Uytterhoeven]

Hi Randy,

On Fri, Jul 27, 2018 at 2:00 AM Randy Dunlap  wrote:
> From: Randy Dunlap 
>
> Fix build warning when built as a loadable module.
> amifb_setup() and amifb_setup_mcap() are only needed when the driver
> is builtin.
> This matches how the functions are called (using #ifndef MODULE).
>
> ../drivers/video/fbdev/amifb.c:2344:19: warning: 'amifb_setup' defined but 
> not used [-Wunused-function]
>  static int __init amifb_setup(char *options)
>
> ../drivers/video/fbdev/amifb.c:2307:20: warning: 'amifb_setup_mcap' defined 
> but not used [-Wunused-function]
>  static void __init amifb_setup_mcap(char *spec)

Thanks for your patch!

> Signed-off-by: Randy Dunlap 

Reviewed-by: Geert Uytterhoeven 

Ideally, amifb_setup() should be called in the modular case, too.
But probably nobody cares.

> Cc: Geert Uytterhoeven 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> ---
>  drivers/video/fbdev/amifb.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20180717.orig/drivers/video/fbdev/amifb.c
> +++ linux-next-20180717/drivers/video/fbdev/amifb.c
> @@ -2303,7 +2303,7 @@ static void ami_build_copper(struct fb_i
> ami_rebuild_copper(info->par);
>  }
>
> -
> +#ifndef MODULE
>  static void __init amifb_setup_mcap(char *spec)
>  {
> char *p;
> @@ -2368,7 +2368,7 @@ static int __init amifb_setup(char *opti
>
> return 0;
>  }
> -
> +#endif
>
>  static int amifb_check_var(struct fb_var_screeninfo *var,
>struct fb_info *info)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 5/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver

[Andrzej Hajda]

On 26.07.2018 09:36, Archit Taneja wrote:
>
> On Wednesday 25 July 2018 09:16 PM, Andrzej Hajda wrote:
>> Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge.
>>
>> Changes in v4:
>> - removed license blob,
>> - ordered includes,
>> - added error handling,
>> - fixed reset GPIO handling,
>> - added missing calls to the panel,
>> - custom OF graph code replaced with helpers,
>> - removed tc358764_poweroff from remove callback.
>> v5:
>> - fixed supply names,
>> - fixed broken console - added connector to fb_helper,
>> - added detach callback - unbinding works,
>> - fixed typo in error checking code,
>> - removed sparse bridge->encoder check - core does it already.
>>
>> Signed-off-by: Andrzej Hajda 
>> Signed-off-by: Maciej Purski 
>> [ a.ha...@samsung.com: v4, v5 ]
>> Signed-off-by: Andrzej Hajda 
>> ---
>>   drivers/gpu/drm/bridge/Kconfig|   8 +
>>   drivers/gpu/drm/bridge/Makefile   |   1 +
>>   drivers/gpu/drm/bridge/tc358764.c | 499 ++
>>   3 files changed, 508 insertions(+)
>>   create mode 100644 drivers/gpu/drm/bridge/tc358764.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index fa2c7997e2fd..f3da8a716833 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -110,6 +110,14 @@ config DRM_THINE_THC63LVD1024
>>  ---help---
>>Thine THC63LVD1024 LVDS/parallel converter driver.
>>   
>> +config DRM_TOSHIBA_TC358764
>> +tristate "TC358764 DSI/LVDS bridge"
>> +depends on DRM && DRM_PANEL
>> +depends on OF
>> +select DRM_MIPI_DSI
>> +help
>> +  Toshiba TC358764 DSI/LVDS bridge driver.
>> +
>>   config DRM_TOSHIBA_TC358767
>>  tristate "Toshiba TC358767 eDP bridge"
>>  depends on OF
>> diff --git a/drivers/gpu/drm/bridge/Makefile 
>> b/drivers/gpu/drm/bridge/Makefile
>> index 35f88d48ec20..bf7c0cecf227 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>>   obj-$(CONFIG_DRM_SII902X) += sii902x.o
>>   obj-$(CONFIG_DRM_SII9234) += sii9234.o
>>   obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>> +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
>>   obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>>   obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>>   obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>> diff --git a/drivers/gpu/drm/bridge/tc358764.c 
>> b/drivers/gpu/drm/bridge/tc358764.c
>> new file mode 100644
>> index ..779bc5fce22a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/tc358764.c
>> @@ -0,0 +1,499 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2018 Samsung Electronics Co., Ltd
>> + *
>> + * Authors:
>> + *  Andrzej Hajda 
>> + *  Maciej Purski 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << 
>> (end))
>> +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
>> +
>> +/* PPI layer registers */
>> +#define PPI_STARTPPI0x0104 /* START control bit */
>> +#define PPI_LPTXTIMECNT 0x0114 /* LPTX timing signal */
>> +#define PPI_LANEENABLE  0x0134 /* Enables each lane */
>> +#define PPI_TX_RX_TA0x013C /* BTA timing parameters */
>> +#define PPI_D0S_CLRSIPOCOUNT0x0164 /* Assertion timer for Lane 0 */
>> +#define PPI_D1S_CLRSIPOCOUNT0x0168 /* Assertion timer for Lane 1 */
>> +#define PPI_D2S_CLRSIPOCOUNT0x016C /* Assertion timer for Lane 2 */
>> +#define PPI_D3S_CLRSIPOCOUNT0x0170 /* Assertion timer for Lane 3 */
>> +#define PPI_START_FUNCTION  1
>> +
>> +/* DSI layer registers */
>> +#define DSI_STARTDSI0x0204 /* START control bit of DSI-TX */
>> +#define DSI_LANEENABLE  0x0210 /* Enables each lane */
>> +#define DSI_RX_START1
>> +
>> +/* Video path registers */
>> +#define VP_CTRL 0x0450 /* Video Path Control */
>> +#define VP_CTRL_MSF(v)  FLD_VAL(v, 0, 0) /* Magic square in 
>> RGB666 */
>> +#define VP_CTRL_VTGEN(v)FLD_VAL(v, 4, 4) /* Use chip clock for timing */
>> +#define VP_CTRL_EVTMODE(v)  FLD_VAL(v, 5, 5) /* Event mode */
>> +#define VP_CTRL_RGB888(v)   FLD_VAL(v, 8, 8) /* RGB888 mode */
>> +#define VP_CTRL_VSDELAY(v)  FLD_VAL(v, 31, 20) /* VSYNC delay */
>> +#define VP_CTRL_HSPOL   BIT(17) /* Polarity of HSYNC signal */
>> +#define VP_CTRL_DEPOL   BIT(18) /* Polarity of DE signal */
>> +#define VP_CTRL_VSPOL   BIT(19) /* Polarity of VSYNC signal */
>> +#define VP_HTIM10x0454 /* Horizontal Timing Control 1 */
>> +#define VP_HTIM1_HBP(v) FLD_VAL(v, 24, 16)
>> +#define VP_HTIM1_HSYNC(v)   FLD_VAL(v, 8, 0)
>> +#define VP_HTIM20x0

[Bug 107384] random tab crashes in firefox nightly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107384

--- Comment #1 from Christoph Haag  ---
Some websites trigger it more often and more reliably than others. Simpler (?)
websites seem to never crash it, reddit sometimes crashes it, gitter channels
always crash it after ~2-3 seconds.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH] drm/bridge/synopsys: remove commented-out flag in Makefile

[Andrzej Hajda]

On 25.07.2018 07:25, Masahiro Yamada wrote:
> Please do not comment out unneeded code.  Remove.
>
> Signed-off-by: Masahiro Yamada 

Queued to drm-misc-next.

Regards
Andrzej

> ---
>
>  drivers/gpu/drm/bridge/synopsys/Makefile | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
> b/drivers/gpu/drm/bridge/synopsys/Makefile
> index 5dad97d..3e1b1e3 100644
> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
> @@ -1,5 +1,3 @@
> -#ccflags-y := -Iinclude/drm
> -
>  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107393] 4.18.0-rc6 amdgpu framebuffer problems with DisplayPort

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107393

Bug ID: 107393
   Summary: 4.18.0-rc6 amdgpu framebuffer problems with
DisplayPort
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: lkd-...@sky-haven.net

Created attachment 140848
  --> https://bugs.freedesktop.org/attachment.cgi?id=140848&action=edit
combined kernel dmesg for two boot sessions, one in 4.17.0 and the other in
4.18.0-rc6

On kernel 4.17.0, amdgpudrmfb functions correctly; taking the fb from efifb

On kernel 4.18.0-rc6 (and previous), the framebuffer proper doesn't start;
monitor doesn't get a valid display signal. If I log in and blind-start a
Wayland compositor (sway in my case), the display gets a desktop and things
work normally. Once I exit out back to FB, the display is blanked.

Everything works normally if I connect the monitor with HDMI instead.

This was a problem with 4.18.0-rc5 as well. I was pointed to the patch at
https://lists.freedesktop.org/archives/amd-gfx/2018-July/023920.html and
applied it to 4.18.0-rc5, but it had no effect on behavior.

GPU: Vega64
Monitor: Acer XR341CK

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107367] [regression, bisected] Games freeze the PC with newest AMD Staging DRM Next Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107367

--- Comment #4 from Christian König  ---
(In reply to Gregor Münch from comment #3)
> This is the crash with kernel from today:

Well that is not very helpful, please add the full dmesg as attachment.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107367] [regression, bisected] Games freeze the PC with newest AMD Staging DRM Next Kernel

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107367

--- Comment #5 from Christian König  ---
Created attachment 140849
  --> https://bugs.freedesktop.org/attachment.cgi?id=140849&action=edit
Possible fix

A shoot into the dark, but maybe the attached patch helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: manual merge of the drm tree with the v4l-dvb tree

[Philipp Zabel]

On Fri, 2018-07-27 at 14:36 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm tree got a conflict in:
> 
>   drivers/gpu/ipu-v3/ipu-cpmem.c
> 
> between commit:
> 
>   343b23a7c6b6 ("media: gpu: ipu-v3: Allow negative offsets for interlaced 
> scanning")
> 
> from the v4l-dvb tree and commit:
> 
>   4e3c5d7e05be ("gpu: ipu-v3: Allow negative offsets for interlaced scanning")
> 
> from the drm tree.
>
> I fixed it up (I just used the drm tree version)

This is correct.

>  and can carry the fix
> as necessary. This is now fixed as far as linux-next is concerned, but
> any non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Steve had pointed out a valid issue with 343b23a7c6b6, I didn't expect
this patch to get picked up. I should have mentioned on linux-media that
I had submitted the fixed version for inclusion in drm-next.

regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] video: fbdev: broadsheetfb: Possible null function pointers

[Bartlomiej Zolnierkiewicz]

On Friday, July 27, 2018 09:49:41 AM Jia-Ju Bai wrote:
> 
> On 2018/7/26 22:34, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday, July 26, 2018 10:17:44 PM bai wrote:
> >> In Linux-4.16, drivers/video/fbdev/broadsheetfb.c,
> >>
> >> 158. static void broadsheet_mmio_send_cmdargs(...) {
> >>   ..
> >> 163. par->board->mmio_write(...);
> >>   ..
> >> 166. par->board->mmio_write(...);
> >> 167. }
> >>
> >> For x86 kernel configuration, I find that there is no assignment of the
> >> function pointer ".mmio_write" in the kernel code.
> >> So calling the function pointer in lines 163 and 166 may cause a null
> >> pointer dereference.
> >>
> >> In this file, there are many calls to this function pointer...
> > This is a platform driver and it won't be used on x86 (actually it is
> > used only by single ARM PXA board). The dependency for FB_BROADSHEET
> > in Kconfig file could be improved to i.e.
> >
> > depends on FB && (ARCH_PXA || COMPILE_TEST)
> >
> > but there is no bug there.
> 
> Thanks for the reply :)
> So I want to submit a patch of updating Kconfig in 
> drivers/video/fbdev/Kconfig:
> 
> config FB_BROADSHEET
>  tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
> -depends on FB
> +   depends on FB && (ARCH_PXA || COMPILE_TEST)
>  select FB_SYS_FILLRECT
>  select FB_SYS_COPYAREA
>  select FB_SYS_IMAGEBLIT
>  select FB_SYS_FOPS
>  select FB_DEFERRED_IO
> 
> 
> Do you think it is okay?

Please read Documentation/process/submitting-patches.rst.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes

[Maarten Lankhorst]

drm-misc-fixes-2018-07-27:
drm-misc-fixes pull request for v4.18-rc7:
- Small fixes to  drm_atomic_helper_async_check(). (bbrezillon)
- Fix error handling in drm_legacy_addctx(). (Nicholas)
- Handle register reset on hotplug in adv7511. (seanpaul)
The following changes since commit 3156b53c2e2fadafa1a16412a8791b38f94b5bdc:

  drm/sun4i: link in front-end code if needed (2018-07-09 09:54:33 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-07-27

for you to fetch changes up to a6a00918d4ad8718c3ccde38c02cec17f116b2fd:

  drm/vc4: Reset ->{x, y}_scaling[1] when dealing with uniplanar formats 
(2018-07-25 21:15:24 +0200)


drm-misc-fixes pull request for v4.18-rc7:
- Small fixes to  drm_atomic_helper_async_check(). (bbrezillon)
- Fix error handling in drm_legacy_addctx(). (Nicholas)
- Handle register reset on hotplug in adv7511. (seanpaul)


Boris Brezillon (3):
  drm/atomic: Check old_plane_state->crtc in drm_atomic_helper_async_check()
  drm/atomic: Initialize variables in drm_atomic_helper_async_check() to 
make gcc happy
  drm/vc4: Reset ->{x, y}_scaling[1] when dealing with uniplanar formats

Nicholas Mc Guire (1):
  drm: re-enable error handling

Sean Paul (1):
  drm/bridge: adv7511: Reset registers on hotplug

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 
 drivers/gpu/drm/drm_atomic_helper.c  |  8 +---
 drivers/gpu/drm/drm_context.c|  2 +-
 drivers/gpu/drm/vc4/vc4_plane.c  |  3 +++
 4 files changed, 21 insertions(+), 4 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200661] AMD Radeon R9 390 freezes/crashing with white stripes/blocks

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200661

--- Comment #2 from beta990 (francois5...@gmail.com) ---
Created attachment 277567
  --> https://bugzilla.kernel.org/attachment.cgi?id=277567&action=edit
dmesg

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200661] AMD Radeon R9 390 freezes/crashing with white stripes/blocks

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200661

--- Comment #3 from beta990 (francois5...@gmail.com) ---
@Alex Deucher just had this issue again and on linux 4.17.9:
https://photos.app.goo.gl/hzELmg88ofD1Q3qg7
https://photos.app.goo.gl/WZH6vSbo1yRtNnvq7

Don't hope this is a hardware issue, but for now I don't have any issues on
Windows 10.

Thanks.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

[Joerg Roedel]

On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> The proposed solution adds a new option to the base device driver
> structure that allows device drivers to explicitly convey to the drivers
> core that the implicit IOMMU backing for devices must not happen.

Why is IOMMU mapping a problem for the Tegra GPU driver?

If we add something like this then it should not be the choice of the
device driver, but of the user and/or the firmware.


Joerg

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200661] AMD Radeon R9 390 freezes/crashing with white stripes/blocks

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200661

--- Comment #4 from Michel Dänzer (mic...@daenzer.net) ---
Does amdgpu.dc=0 on the kernel command line avoid the issue?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200661] AMD Radeon R9 390 freezes/crashing with white stripes/blocks

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200661

beta990 (francois5...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200661] AMD Radeon R9 390 freezes/crashing with white stripes/blocks

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200661

--- Comment #5 from beta990 (francois5...@gmail.com) ---
@Michel Dänzer @Alex Deucher Without this flag, the issue remains.
Unfortunately it seems the GPU also starts crashing in Windows, probably the
onboard memory died. :/

Thanks for looking at the issue and I'll report back if needed.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge/tc358764: fix drm helper name

[Andrzej Hajda]

Recently drm_mode_connector_attach_encoder changed it's name. The change
was not noticed by bridge author, as a result gcc reports compile error
on next branch.

Fixes: f38b7cca6d0e ("drm/bridge: tc358764: Add DSI to LVDS bridge driver")
Reported-by: kbuild test robot 
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/tc358764.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358764.c 
b/drivers/gpu/drm/bridge/tc358764.c
index 779bc5fce22a..ee6b98efa9c2 100644
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -361,7 +361,7 @@ static int tc358764_attach(struct drm_bridge *bridge)
 
drm_connector_helper_add(&ctx->connector,
 &tc358764_connector_helper_funcs);
-   drm_mode_connector_attach_encoder(&ctx->connector, bridge->encoder);
+   drm_connector_attach_encoder(&ctx->connector, bridge->encoder);
drm_panel_attach(ctx->panel, &ctx->connector);
ctx->connector.funcs->reset(&ctx->connector);
drm_fb_helper_add_one_connector(drm->fb_helper, &ctx->connector);
-- 
2.18.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/kms/atomic: Used existing func for checking fb geometry

[Maarten Lankhorst]

Op 27-07-18 om 10:38 schreef Satendra Singh Thakur:
> 1.In the func drm_atomic_plane_check, the fb geometry checking code
> can be replaced by func drm_framebuffer_check_src_coords, this will
> remove several redundant lines of code.
> 2. Currently, in the func drm_atomic_plane_check;
> there are 3 if statements in the beginning with total 5 conditions.
> these conditions are
> crtc is NULL but fb is non-NULL
> if (state->crtc && !state->fb)
> crtc is non-NULL but fb is NULL
> if (state->fb && !state->crtc)
> crtc is NULL (and fb is also NULL)
> if (!state->crtc)
>
> The same code can be re-written using 2 if statements and 4 conditions.
> first we check whether crtc and fb both are NULL
> if (!state->crtc && !state->fb)
> then we check either crtc or fb is NULL
> if (!state->crtc || !state->fb)
>
> Signed-off-by: Satendra Singh Thakur 
> ---
>  drivers/gpu/drm/drm_atomic.c | 37 +
>  1 file changed, 9 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e..1cddab8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -909,22 +909,16 @@ plane_switching_crtc(struct drm_atomic_state *state,
>  static int drm_atomic_plane_check(struct drm_plane *plane,
>   struct drm_plane_state *state)
>  {
> - unsigned int fb_width, fb_height;
>   int ret;
>  
> - /* either *both* CRTC and FB must be set, or neither */
> - if (state->crtc && !state->fb) {
> - DRM_DEBUG_ATOMIC("CRTC set but no FB\n");
> - return -EINVAL;
> - } else if (state->fb && !state->crtc) {
> - DRM_DEBUG_ATOMIC("FB set but no CRTC\n");
> - return -EINVAL;
> - }
> -
>   /* if disabled, we don't care about the rest of the state: */
> - if (!state->crtc)
> + if (!state->crtc && !state->fb)
>   return 0;
> -
> + /* both CRTC and FB must be set*/
> + if (!state->crtc || !state->fb) {
> + DRM_DEBUG_ATOMIC("Either no CRTC or no FB\n");
> + return -EINVAL;
> + }
>   /* Check whether this plane is usable on this CRTC */
>   if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
>   DRM_DEBUG_ATOMIC("Invalid crtc for plane\n");
This should be a separate patch?
> @@ -954,24 +948,11 @@ static int drm_atomic_plane_check(struct drm_plane 
> *plane,
>   return -ERANGE;
>   }
>  
> - fb_width = state->fb->width << 16;
> - fb_height = state->fb->height << 16;
> -
>   /* Make sure source coordinates are inside the fb. */
> - if (state->src_w > fb_width ||
> - state->src_x > fb_width - state->src_w ||
> - state->src_h > fb_height ||
> - state->src_y > fb_height - state->src_h) {
> - DRM_DEBUG_ATOMIC("Invalid source coordinates "
> -  "%u.%06ux%u.%06u+%u.%06u+%u.%06u (fb %ux%u)\n",
> -  state->src_w >> 16, ((state->src_w & 0x) * 
> 15625) >> 10,
> -  state->src_h >> 16, ((state->src_h & 0x) * 
> 15625) >> 10,
> -  state->src_x >> 16, ((state->src_x & 0x) * 
> 15625) >> 10,
> -  state->src_y >> 16, ((state->src_y & 0x) * 
> 15625) >> 10,
> -  state->fb->width, state->fb->height);
> + ret = drm_framebuffer_check_src_coords(state->src_x, state->src_y,
> + state->src_w, state->src_h, state->fb);
> + if (ret)
>   return -ENOSPC;
Change this to return ret, no need to swallow errors. :)
> - }
> -
>   if (plane_switching_crtc(state->state, plane, state)) {
>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>plane->base.id, plane->name);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 5/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver

[Laurent Pinchart]

Hi Andrzej,

On Friday, 27 July 2018 10:17:50 EEST Andrzej Hajda wrote:
> On 26.07.2018 09:36, Archit Taneja wrote:
> > On Wednesday 25 July 2018 09:16 PM, Andrzej Hajda wrote:
> >> Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge.
> >> 
> >> Changes in v4:
> >> - removed license blob,
> >> - ordered includes,
> >> - added error handling,
> >> - fixed reset GPIO handling,
> >> - added missing calls to the panel,
> >> - custom OF graph code replaced with helpers,
> >> - removed tc358764_poweroff from remove callback.
> >> v5:
> >> - fixed supply names,
> >> - fixed broken console - added connector to fb_helper,
> >> - added detach callback - unbinding works,
> >> - fixed typo in error checking code,
> >> - removed sparse bridge->encoder check - core does it already.
> >> 
> >> Signed-off-by: Andrzej Hajda 
> >> Signed-off-by: Maciej Purski 
> >> [ a.ha...@samsung.com: v4, v5 ]
> >> Signed-off-by: Andrzej Hajda 
> >> ---
> >> 
> >>   drivers/gpu/drm/bridge/Kconfig|   8 +
> >>   drivers/gpu/drm/bridge/Makefile   |   1 +
> >>   drivers/gpu/drm/bridge/tc358764.c | 499 ++
> >>   3 files changed, 508 insertions(+)
> >>   create mode 100644 drivers/gpu/drm/bridge/tc358764.c
> >> 
> >> diff --git a/drivers/gpu/drm/bridge/Kconfig
> >> b/drivers/gpu/drm/bridge/Kconfig index fa2c7997e2fd..f3da8a716833 100644
> >> --- a/drivers/gpu/drm/bridge/Kconfig
> >> +++ b/drivers/gpu/drm/bridge/Kconfig
> >> @@ -110,6 +110,14 @@ config DRM_THINE_THC63LVD1024
> >> 
> >>---help---
> >>
> >>  Thine THC63LVD1024 LVDS/parallel converter driver.
> >> 
> >> +config DRM_TOSHIBA_TC358764
> >> +  tristate "TC358764 DSI/LVDS bridge"
> >> +  depends on DRM && DRM_PANEL
> >> +  depends on OF
> >> +  select DRM_MIPI_DSI
> >> +  help
> >> +Toshiba TC358764 DSI/LVDS bridge driver.
> >> +
> >> 
> >>   config DRM_TOSHIBA_TC358767
> >>   
> >>tristate "Toshiba TC358767 eDP bridge"
> >>depends on OF
> >> 
> >> diff --git a/drivers/gpu/drm/bridge/Makefile
> >> b/drivers/gpu/drm/bridge/Makefile index 35f88d48ec20..bf7c0cecf227
> >> 100644
> >> --- a/drivers/gpu/drm/bridge/Makefile
> >> +++ b/drivers/gpu/drm/bridge/Makefile
> >> @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> >> 
> >>   obj-$(CONFIG_DRM_SII902X) += sii902x.o
> >>   obj-$(CONFIG_DRM_SII9234) += sii9234.o
> >>   obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> >> 
> >> +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
> >> 
> >>   obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> >>   obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> >>   obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> >> 
> >> diff --git a/drivers/gpu/drm/bridge/tc358764.c
> >> b/drivers/gpu/drm/bridge/tc358764.c new file mode 100644
> >> index ..779bc5fce22a
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/bridge/tc358764.c
> >> @@ -0,0 +1,499 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (C) 2018 Samsung Electronics Co., Ltd
> >> + *
> >> + * Authors:
> >> + *Andrzej Hajda 
> >> + *Maciej Purski 
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) <<
> >> (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) &
> >> FLD_MASK(start, end)) +
> >> +/* PPI layer registers */
> >> +#define PPI_STARTPPI  0x0104 /* START control bit */
> >> +#define PPI_LPTXTIMECNT   0x0114 /* LPTX timing signal */
> >> +#define PPI_LANEENABLE0x0134 /* Enables each lane */
> >> +#define PPI_TX_RX_TA  0x013C /* BTA timing parameters */
> >> +#define PPI_D0S_CLRSIPOCOUNT  0x0164 /* Assertion timer for Lane 0 */
> >> +#define PPI_D1S_CLRSIPOCOUNT  0x0168 /* Assertion timer for Lane 1 */
> >> +#define PPI_D2S_CLRSIPOCOUNT  0x016C /* Assertion timer for Lane 2 */
> >> +#define PPI_D3S_CLRSIPOCOUNT  0x0170 /* Assertion timer for Lane 3 */
> >> +#define PPI_START_FUNCTION1
> >> +
> >> +/* DSI layer registers */
> >> +#define DSI_STARTDSI  0x0204 /* START control bit of DSI-TX */
> >> +#define DSI_LANEENABLE0x0210 /* Enables each lane */
> >> +#define DSI_RX_START  1
> >> +
> >> +/* Video path registers */
> >> +#define VP_CTRL   0x0450 /* Video Path Control */
> >> +#define VP_CTRL_MSF(v)FLD_VAL(v, 0, 0) /* Magic square in 
> >> RGB666 
*/
> >> +#define VP_CTRL_VTGEN(v)  FLD_VAL(v, 4, 4) /* Use chip clock for timing
> >> */
> >> +#define VP_CTRL_EVTMODE(v)FLD_VAL(v, 5, 5) /* Event mode */
> >> +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */
> >> +#define VP_CTRL_VSDELAY(v)FLD_VAL(v, 31, 20) /* VSYNC delay */
> >> +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */
> >> +#define VP_CTRL_DE

Re: linux-next: manual merge of the drm tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Em Fri, 27 Jul 2018 14:36:40 +1000
Stephen Rothwell  escreveu:

> Hi all,
> 
> Today's linux-next merge of the drm tree got a conflict in:
> 
>   drivers/gpu/ipu-v3/ipu-cpmem.c
> 
> between commit:
> 
>   343b23a7c6b6 ("media: gpu: ipu-v3: Allow negative offsets for interlaced 
> scanning")
> 
> from the v4l-dvb tree and commit:
> 
>   4e3c5d7e05be ("gpu: ipu-v3: Allow negative offsets for interlaced scanning")
> 
> from the drm tree.
> 
> I fixed it up (I just used the drm tree version) and can carry the fix
> as necessary. This is now fixed as far as linux-next is concerned, but
> any non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

My mistake. Not sure why media ML was c/c on this patch. As the author
is an usual media contributor and we have an IPU3 driver that has being
taking some discussions those days, I ended by merging it without
noticing that it was for the gpu driver.

I'll remove it from my tree in order to avoid conflicts.

Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 5/9] drm/bridge: tc358764: Add DSI to LVDS bridge driver

[Andrzej Hajda]

On 27.07.2018 12:30, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Friday, 27 July 2018 10:17:50 EEST Andrzej Hajda wrote:
>> On 26.07.2018 09:36, Archit Taneja wrote:
>>> On Wednesday 25 July 2018 09:16 PM, Andrzej Hajda wrote:
 Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge.

 Changes in v4:
 - removed license blob,
 - ordered includes,
 - added error handling,
 - fixed reset GPIO handling,
 - added missing calls to the panel,
 - custom OF graph code replaced with helpers,
 - removed tc358764_poweroff from remove callback.
 v5:
 - fixed supply names,
 - fixed broken console - added connector to fb_helper,
 - added detach callback - unbinding works,
 - fixed typo in error checking code,
 - removed sparse bridge->encoder check - core does it already.

 Signed-off-by: Andrzej Hajda 
 Signed-off-by: Maciej Purski 
 [ a.ha...@samsung.com: v4, v5 ]
 Signed-off-by: Andrzej Hajda 
 ---

   drivers/gpu/drm/bridge/Kconfig|   8 +
   drivers/gpu/drm/bridge/Makefile   |   1 +
   drivers/gpu/drm/bridge/tc358764.c | 499 ++
   3 files changed, 508 insertions(+)
   create mode 100644 drivers/gpu/drm/bridge/tc358764.c

 diff --git a/drivers/gpu/drm/bridge/Kconfig
 b/drivers/gpu/drm/bridge/Kconfig index fa2c7997e2fd..f3da8a716833 100644
 --- a/drivers/gpu/drm/bridge/Kconfig
 +++ b/drivers/gpu/drm/bridge/Kconfig
 @@ -110,6 +110,14 @@ config DRM_THINE_THC63LVD1024

---help---

  Thine THC63LVD1024 LVDS/parallel converter driver.

 +config DRM_TOSHIBA_TC358764
 +  tristate "TC358764 DSI/LVDS bridge"
 +  depends on DRM && DRM_PANEL
 +  depends on OF
 +  select DRM_MIPI_DSI
 +  help
 +Toshiba TC358764 DSI/LVDS bridge driver.
 +

   config DRM_TOSHIBA_TC358767
   
tristate "Toshiba TC358767 eDP bridge"
depends on OF

 diff --git a/drivers/gpu/drm/bridge/Makefile
 b/drivers/gpu/drm/bridge/Makefile index 35f88d48ec20..bf7c0cecf227
 100644
 --- a/drivers/gpu/drm/bridge/Makefile
 +++ b/drivers/gpu/drm/bridge/Makefile
 @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o

   obj-$(CONFIG_DRM_SII902X) += sii902x.o
   obj-$(CONFIG_DRM_SII9234) += sii9234.o
   obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o

 +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o

   obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
   obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
   obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/

 diff --git a/drivers/gpu/drm/bridge/tc358764.c
 b/drivers/gpu/drm/bridge/tc358764.c new file mode 100644
 index ..779bc5fce22a
 --- /dev/null
 +++ b/drivers/gpu/drm/bridge/tc358764.c
 @@ -0,0 +1,499 @@
 +// SPDX-License-Identifier: GPL-2.0
 +/*
 + * Copyright (C) 2018 Samsung Electronics Co., Ltd
 + *
 + * Authors:
 + *Andrzej Hajda 
 + *Maciej Purski 
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) <<
 (end)) +#define FLD_VAL(val, start, end) (((val) << (end)) &
 FLD_MASK(start, end)) +
 +/* PPI layer registers */
 +#define PPI_STARTPPI  0x0104 /* START control bit */
 +#define PPI_LPTXTIMECNT   0x0114 /* LPTX timing signal */
 +#define PPI_LANEENABLE0x0134 /* Enables each lane */
 +#define PPI_TX_RX_TA  0x013C /* BTA timing parameters */
 +#define PPI_D0S_CLRSIPOCOUNT  0x0164 /* Assertion timer for Lane 0 */
 +#define PPI_D1S_CLRSIPOCOUNT  0x0168 /* Assertion timer for Lane 1 */
 +#define PPI_D2S_CLRSIPOCOUNT  0x016C /* Assertion timer for Lane 2 */
 +#define PPI_D3S_CLRSIPOCOUNT  0x0170 /* Assertion timer for Lane 3 */
 +#define PPI_START_FUNCTION1
 +
 +/* DSI layer registers */
 +#define DSI_STARTDSI  0x0204 /* START control bit of DSI-TX */
 +#define DSI_LANEENABLE0x0210 /* Enables each lane */
 +#define DSI_RX_START  1
 +
 +/* Video path registers */
 +#define VP_CTRL   0x0450 /* Video Path Control */
 +#define VP_CTRL_MSF(v)FLD_VAL(v, 0, 0) /* Magic square in 
 RGB666 
> */
 +#define VP_CTRL_VTGEN(v)  FLD_VAL(v, 4, 4) /* Use chip clock for timing
 */
 +#define VP_CTRL_EVTMODE(v)FLD_VAL(v, 5, 5) /* Event mode */
 +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */
 +#define VP_CTRL_VSDELAY(v)FLD_VAL(v, 31, 20) /* VSYNC delay */
 +#define VP_CTRL_HSPOL BIT(17) /* Polarity of

Re: [PATCH] backlight: pwm_bl: switch to using "atomic" PWM API

[Daniel Thompson]

On 26/07/18 10:15, Enric Balletbo i Serra wrote:

The "atomic" API allows us to configure PWM period and duty_cycle and
enable it in one call.

The patch also moves the pwm_init_state just before any use of the
pwm_state struct, this fixes a potential bug where pwm_get_state
can be called before pwm_init_state.

Signed-off-by: Enric Balletbo i Serra 
---

  drivers/video/backlight/pwm_bl.c | 48 
  1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index bdfcc0a71db1..2c734d55d607 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -46,7 +46,8 @@ struct pwm_bl_data {
void(*exit)(struct device *);
  };
  
-static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness)

+static void pwm_backlight_power_on(struct pwm_bl_data *pb,
+  struct pwm_state *state)
  {
int err;
  
@@ -57,7 +58,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness)

if (err < 0)
dev_err(pb->dev, "failed to enable power supply\n");
  
-	pwm_enable(pb->pwm);

+   state->enabled = true;
+   pwm_apply_state(pb->pwm, state);
  
  	if (pb->post_pwm_on_delay)

msleep(pb->post_pwm_on_delay);
@@ -70,6 +72,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, 
int brightness)
  
  static void pwm_backlight_power_off(struct pwm_bl_data *pb)

  {
+   struct pwm_state state;
+
if (!pb->enabled)
return;
  
@@ -79,8 +83,11 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)

if (pb->pwm_off_delay)
msleep(pb->pwm_off_delay);
  
-	pwm_config(pb->pwm, 0, pb->period);

-   pwm_disable(pb->pwm);
+   pwm_get_state(pb->pwm, &state);
+   state.enabled = false;
+   state.period = pb->period;
+   state.duty_cycle = 0;
+   pwm_apply_state(pb->pwm, &state);
  
  	regulator_disable(pb->power_supply);

pb->enabled = false;
@@ -106,6 +113,7 @@ static int pwm_backlight_update_status(struct 
backlight_device *bl)
  {
struct pwm_bl_data *pb = bl_get_data(bl);
int brightness = bl->props.brightness;
+   struct pwm_state state;
int duty_cycle;
  
  	if (bl->props.power != FB_BLANK_UNBLANK ||

@@ -118,8 +126,13 @@ static int pwm_backlight_update_status(struct 
backlight_device *bl)
  
  	if (brightness > 0) {

duty_cycle = compute_duty_cycle(pb, brightness);
-   pwm_config(pb->pwm, duty_cycle, pb->period);
-   pwm_backlight_power_on(pb, brightness);
+   pwm_get_state(pb->pwm, &state);
+   state.duty_cycle = duty_cycle;
+   state.period = pb->period;
+   if (!state.enabled)
+   pwm_backlight_power_on(pb, &state);
+   else
+   pwm_apply_state(pb->pwm, &state);
} else
pwm_backlight_power_off(pb);
  
@@ -447,7 +460,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)

struct device_node *node = pdev->dev.of_node;
struct pwm_bl_data *pb;
struct pwm_state state;
-   struct pwm_args pargs;
unsigned int i;
int ret;
  
@@ -539,10 +551,17 @@ static int pwm_backlight_probe(struct platform_device *pdev)
  
  	dev_dbg(&pdev->dev, "got pwm for backlight\n");
  
-	if (!data->levels) {

-   /* Get the PWM period (in nanoseconds) */
-   pwm_get_state(pb->pwm, &state);
+   /* Sync up PWM state and ensure it is off. */
+   pwm_init_state(pb->pwm, &state);
+   state.enabled = false;
+   ret = pwm_apply_state(pb->pwm, &state);


Why do we ensure the PWM is off? Does this cause backlight flickers or 
make some of the code in pwm_backlight_initial_power_state() unreachable?




+   if (ret) {
+   dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n",
+   ret);
+   goto err_alloc;
+   }
  
+	if (!data->levels) {

ret = pwm_backlight_brightness_default(&pdev->dev, data,
   state.period);
if (ret < 0) {
@@ -559,20 +578,13 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
pb->levels = data->levels;
}
  
-	/*

-* FIXME: pwm_apply_args() should be removed when switching to
-* the atomic PWM API.
-*/
-   pwm_apply_args(pb->pwm);
-
/*
 * The DT case will set the pwm_period_ns field to 0 and store the
 * period, parsed from the DT, in the PWM device. For the non-DT case,
 * set the period from platform data if it has not already been set
 * via the PWM lookup table.
 */
-   pwm_get_args(pb->pwm, &pargs);
-   pb->period = pargs.period;
+   pb->period = st

[Bug 200667] [AMDGPU] stacktrace in dmesg, starting at drm_dp_i2c_do_msg

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200667

--- Comment #1 from Christian Widmer (cwid...@umbrox.de) ---
Created attachment 277571
  --> https://bugzilla.kernel.org/attachment.cgi?id=277571&action=edit
Kernel configuration

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200667] New: [AMDGPU] stacktrace in dmesg, starting at drm_dp_i2c_do_msg

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200667

Bug ID: 200667
   Summary: [AMDGPU] stacktrace in dmesg, starting at
drm_dp_i2c_do_msg
   Product: Drivers
   Version: 2.5
Kernel Version: 4.17.10
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: cwid...@umbrox.de
Regression: No

Created attachment 277569
  --> https://bugzilla.kernel.org/attachment.cgi?id=277569&action=edit
Full dmesg output from kernel 4.18-r6

When I changed my kernel from 4.17.9 to 4.17.10 (both patched with the Gentoo
patchset), a stacktrace started to appear in the kernel messages. To check
whether this is still an issue in mainline and not related to the distribution
kernel, I tried 4.18-r6 which also shows the issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200667] [AMDGPU] stacktrace in dmesg, starting at drm_dp_i2c_do_msg

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200667

--- Comment #2 from Christian Widmer (cwid...@umbrox.de) ---
Created attachment 277573
  --> https://bugzilla.kernel.org/attachment.cgi?id=277573&action=edit
lspci

I am using an RX 580.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200667] [AMDGPU] stacktrace in dmesg, starting at drm_dp_i2c_do_msg

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200667

--- Comment #3 from Christian Widmer (cwid...@umbrox.de) ---
I might add simply booting the kernel is all that is needed to trigger the
issue. The stacktraces automatically appear during the boot process.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/kms/crtc: Improving the func drm_mode_setcrtc

[Maarten Lankhorst]

Hey,

Op 27-07-18 om 12:12 schreef Satendra Singh Thakur:
> Following changes are done to this func:
> 1. Currently there are many redundant error checks for
> count_connectors, mode, fb and mode_valid.
> if (crtc_req->mode_valid)
> if (crtc_req->count_connectors == 0 && mode)
> if (crtc_req->count_connectors > 0 && (!mode || !fb))
> if (crtc_req->count_connectors > 0)
> if (crtc_req->count_connectors > config->num_connector)
>
> These 5 checks are replaced by just 2 checks.
> if (!crtc_req->mode_valid)
> if (!crtc_req->count_connectors ||
> crtc_req->count_connectors > config->num_connector)

>
> 2. Also, currently, if user pass invalid args
> count_connectors=0, mode=NULL, fb=NULL, code wont throw
> any errors and eventually __drm_mode_set_config_internal
> will be called.
> With the modified code, this will be taken care.
>
> 3. Also, these error checks alongwith following
> if (!file_priv->aspect_ratio_allowed &&
> (crtc_req->mode.flags & DRM_MODE_FLAG_PIC_AR_MASK)
>
> has been  moved  before taking mutex and modeset lock
> because they don't need any lock. Moreover, after grabbing locks,
> if its found that user supplied  invalid args, it will
> be too late as getting lock may require considerable time.
>
> 4. Also, if modeset_lock is tried many times in case of EDEADLK
> error, then this will be the code flow
>
> retry:
>   ret = drm_modeset_lock_all_ctx(crtc->dev, &ctx);
>
> if (ret)-->this is true
>   goto out;
>
> out:
>   if (fb)
>   if (connector_set)
>   drm_mode_destroy(dev, mode);
>   if (ret == -EDEADLK)
>   goto retry;
> It can be observed that checks on fb, connector_set and call to
> mode_destroy are redundant in retry-case.
> If we keep if (ret == -EDEADLK) just after out:,
> that will avoid redundant checks.
>
> In the normal case (non-retry), all checks will be required.
> Thus shifting of if (ret == -EDEADLK) right after out label
> won't affect normal case.
>
> 5. Also, kfree is moved inside if (connector_set).
> 6. Also, if major error checks are in the beginning of the func
> and if user supplied invalid params,  we will exit the func sooner
> without wasting much effort in finding crtc and framebuffer etc.
>
> Signed-off-by: Satendra Singh Thakur 
> ---
>  drivers/gpu/drm/drm_crtc.c | 207 
> +
>  1 file changed, 98 insertions(+), 109 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 98a36e6..15927e7 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -578,7 +578,25 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
>*/
>   if (crtc_req->x & 0x || crtc_req->y & 0x)
>   return -ERANGE;
> -
> + if (!file_priv->aspect_ratio_allowed &&
> + (crtc_req->mode.flags & DRM_MODE_FLAG_PIC_AR_MASK) !=
> + DRM_MODE_FLAG_PIC_AR_NONE) {
> + DRM_DEBUG_KMS("Unexpected aspect-ratio flag bits\n");
> + return -EINVAL;
> + }
> + /* Check if the flag is set*/
> + if (!crtc_req->mode_valid) {
> + DRM_DEBUG_KMS("mode_valid flag [%d] is not set\n",
> + crtc_req->mode_valid);
> + return -EINVAL;
> + }
It is allowed to pass crtc_id, mode_valid = false and count_connectors == 0, 
you're missing this check now.
It's used to disable a crtc:

https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/lib/igt_kms.c#n1452


> + /* Check the validity of count_connectors supplied by user */
> + if (!crtc_req->count_connectors ||
> + crtc_req->count_connectors > config->num_connector) {
> + DRM_DEBUG_KMS("Invalid connectors' count %d\n",
> + crtc_req->count_connectors);
> + return -EINVAL;
> + }
>   crtc = drm_crtc_find(dev, file_priv, crtc_req->crtc_id);
>   if (!crtc) {
>   DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_req->crtc_id);
> @@ -595,134 +613,105 @@ int drm_mode_setcrtc(struct drm_device *dev, void 
> *data,
>   if (ret)
>   goto out;
>  
> - if (crtc_req->mode_valid) {
> - /* If we have a mode we need a framebuffer. */
> - /* If we pass -1, set the mode with the currently bound fb */
> - if (crtc_req->fb_id == -1) {
> - struct drm_framebuffer *old_fb;
> + /* If we have a mode we need a framebuffer. */
> + /* If we pass -1, set the mode with the currently bound fb */
> + if (crtc_req->fb_id == -1) {
> + struct drm_framebuffer *old_fb;
>  
> - if (plane->state)
> - old_fb = plane->state->fb;
> - else
> - old_fb = plane->fb;
> + if (plane->state)
> + old_fb = plane->state->fb;
> + else
> + old_fb = plane->fb;
>  
> - if (!old_fb) {
> - 

[Bug 107390] [BISECTED] EDID read failure breaks display mirroring

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107390

--- Comment #6 from Justinas Narusevicius  ---
Hey Alex,

Yes ac916c914c3156e53505e9ea3a9d1495518bf873 was found by bisecting mainline
kernel between tags of v4.16 (0adb32858b0bddf4ada5f364a84ed60b196dbcda good)
and v4.17-rc1 (60cc43fc888428bb2f18f08997432d426a243338 bad)

I can confirm that reverting ac916c914c3156e53505e9ea3a9d1495518bf873 via the
attached patch on current mainline kernel HEAD
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cd3f77d74ac31b4627cdfa70812338076a1ea475)
fixes all three issues.

* Mirroring is available once again.
* Extended desktop mode can now use all the resolutions up to and including 4K.
* There's no 3rd erroneous display on HDMI-A-2 anymore.

Should i test this against
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next or any
other specific branch?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107390] [BISECTED] EDID read failure breaks display mirroring

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107390

--- Comment #7 from Justinas Narusevicius  ---
Created attachment 140853
  --> https://bugs.freedesktop.org/attachment.cgi?id=140853&action=edit
Patch to revert the problematic commit

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107402] [Intel GFX CI][BAT] igt@amdgpu_amd_basic@userptr - incomplete - general protection fault: 0000 [#1] PREEMPT SMP PTI, __mmu_notifier_release

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107402

Martin Peres  changed:

   What|Removed |Added

  Component|DRM/Intel   |DRM/AMDgpu
Summary|[CI][BAT]   |[Intel GFX CI][BAT]
   |igt@amdgpu_amd_basic@userpt |igt@amdgpu_amd_basic@userpt
   |r - incomplete - general|r - incomplete - general
   |protection fault:  [#1] |protection fault:  [#1]
   |PREEMPT SMP PTI,|PREEMPT SMP PTI,
   |__mmu_notifier_release  |__mmu_notifier_release
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |

--- Comment #3 from Martin Peres  ---
Thanks Chris, moving the failure to AMDGpu!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107403] Quadratic behavior due to leaking fence contexts in reservation objects

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107403

Bug ID: 107403
   Summary: Quadratic behavior due to leaking fence contexts in
reservation objects
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: b...@basnieuwenhuizen.nl

As part of the Vulkan CTS, radv creates about 30k AMDGPU contexts (about 1-20
live at the same time though).

Each of those creates a bunch of fence contexts, one for each ring, to use for
fences created from submitted jobs.

However, as part of running jobs, fences with those contexts get attached to
the
vm->root.base.bo->tbo.resv of the corresponding vm. Which means that at some
point we have tens of thousands of fences attached to it as they never get
removed. They only ever get deduplicated with a later fence from the same fence
context, so fences from destroyed contexts never get removed.

Then in amdgpu_gem_va_ioctl -> amdgpu_vm_clear_freed ->
amdgpu_vm_bo_update_mapping we do an amdgpu_sync_resv, which tries to add that
to an amdgpu_sync object. Which only has a 16-entry hashtable, so adding the
fences to the hashtable results in quadratic behavior.

Combine this with doing sparse buffer tests at the end, which do lots of VA
operations this results in tests taking 20+ minuts.

So I could reduce the number of amdgpu contexts a bit in radv, but the bigger
issue in my opnion is that we are pretty much leaking and never reclaiming the
fences.

Any idea how to best remove some signalled fences?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107402] [Intel GFX CI][BAT] igt@amdgpu_amd_basic@userptr - incomplete - general protection fault: 0000 [#1] PREEMPT SMP PTI, __mmu_notifier_release

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107402

--- Comment #4 from Michel Dänzer  ---
(In reply to Chris Wilson from comment #2)
> Use after free by amdgpu.ko

How do you know it's a use-after-free? Can you provide more information about
that, e.g. from KASAN?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107402] [Intel GFX CI][BAT] igt@amdgpu_amd_basic@userptr - incomplete - general protection fault: 0000 [#1] PREEMPT SMP PTI, __mmu_notifier_release

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107402

--- Comment #5 from Chris Wilson  ---
RBX: 6b6b6b6b6b6b6b6b == POISON_FREE

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107402] [Intel GFX CI][BAT] igt@amdgpu_amd_basic@userptr - incomplete - general protection fault: 0000 [#1] PREEMPT SMP PTI, __mmu_notifier_release

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107402

--- Comment #6 from Martin Peres  ---
Our KASAN runs do not currently run AMDGPU tests. This should be fixed by the
next run (triggered manually).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107403] Quadratic behavior due to leaking fence contexts in reservation objects

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107403

--- Comment #1 from Christian König  ---
Well that should be already fixed by the following commits:

commit ca25fe5efe4ab43cc5b4f3117a205c281805a5ca
Author: Christian König 
Date:   Tue Nov 14 15:24:36 2017 +0100

dma-buf: try to replace a signaled fence in
reservation_object_add_shared_inplace

The amdgpu issue to also need signaled fences in the reservation objects
should
be fixed by now.

Optimize the handling by replacing a signaled fence when adding a new
shared one.

Signed-off-by: Christian König 
Reviewed-by: Chris Wilson 
Signed-off-by: Alex Deucher 
Link:
https://patchwork.freedesktop.org/patch/msgid/20171114142436.1360-2-christian.koe...@amd.com

commit 4d9c62e8ce69d0b0a834282a34bff5ce8eeacb1d
Author: Christian König 
Date:   Tue Nov 14 15:24:35 2017 +0100

dma-buf: keep only not signaled fence in
reservation_object_add_shared_replace v3

The amdgpu issue to also need signaled fences in the reservation objects
should be fixed by now.

Optimize the list by keeping only the not signaled yet fences around.

v2: temporary put the signaled fences at the end of the new container
v3: put the old fence at the end of the new container as well.

Signed-off-by: Christian König 
Reviewed-by: Chris Wilson 
Tested-by: Chris Wilson 
Signed-off-by: Alex Deucher 
Link:
https://patchwork.freedesktop.org/patch/msgid/20171114142436.1360-1-christian.koe...@amd.com

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107403] Quadratic behavior due to leaking fence contexts in reservation objects

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107403

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #2 from Bas Nieuwenhuizen  ---
Hmm, seems like we were only backporting amdgpu and not the things in
drivers/dma-buf, that would explain. Thanks a lot!

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 08/10] drm/sun4i: Use __drm_atomic_helper_plane_reset instead of copying the logic

[Maxime Ripard]

On Thu, Jul 26, 2018 at 05:17:54PM +0100, Alexandru Gheorghe wrote:
> A new helper function(__drm_atomic_helper_plane_reset) has been added
> for linking a plane with its state and resetting the core
> properties(alpha, rotation, etc.) to their default values.
> Use that instead of duplicating the logic.
> 
> __drm_atomic_helper_plane_reset initializes the alpha property to its
> max value, which is defined by the drm core as DRM_BLEND_ALPHA_OPAQUE,
> so nothing changes regarding the alpha value.
> 
> Signed-off-by: Alexandru Gheorghe 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3.1 10/10] arm64: dts: allwinner: a64: Enable HDMI output on A64 boards w/ HDMI

[Maxime Ripard]

On Fri, Jul 27, 2018 at 01:12:57AM +0800, Icenowy Zheng wrote:
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 1b9b92e541d2..1b972bade9f6 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -62,6 +62,21 @@
>   chosen {
>   stdout-path = "serial0:115200n8";
>   };
> +
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +};
> +
> +&de {
> + status = "okay";
>  };
>  
>  &ehci0 {
> @@ -82,6 +97,17 @@
>  
>  };
>  
> +&hdmi {
> + hdmi-supply = <®_dldo1>;
> + status = "okay";
> +};
> +
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
> +
>  &i2c1 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&i2c1_pins>;
> @@ -99,6 +125,10 @@
>   };
>  };
>  
> +&mixer1 {
> + status = "okay";
> +};
> +
>  &mmc0 {
>   pinctrl-names = "default";
>   pinctrl-0 = <&mmc0_pins>;
> @@ -238,6 +268,10 @@
>   status = "disabled";
>  };
>  
> +&tcon1 {
> + status = "okay";
> +};

Is it working or not on the pine64?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3.1 00/10] arm64: allwinner: Add A64 DE2 HDMI support

[Maxime Ripard]

On Fri, Jul 27, 2018 at 01:12:47AM +0800, Icenowy Zheng wrote:
> Allwinner A64 has display engine pipeline like other Allwinner SOC's 
> A83T/H3/H5.
> 
> A64 behaviour similar to Allwinner A83T where
> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
> Mixer1 => TCON1 => HDMI
> as per Display System Block Diagram from the A64 user manual.
> 
> This is third patch-set followed with previous RFC[1], first and second
> series[2][3] and merely concentrated on HDMI pipeline through TCON1 and
> rest will add eventually.
> 
> I just rebased and slightly re-integrated the patchset according to the
> requirments of the maintainer, and added the mixer0->tcon0 pipeline.
> The further maintainship of the patchset still needs to be discussed
> between I and Jagan.

Beside the comment on the pine64, it looks good to me. Can you
resubmit those patches after rc1 is out?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107001] hard system freeze with mesa 18.1.1 and 18.1.2 on AMD RX 580

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107001

cla...@mathr.co.uk changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from cla...@mathr.co.uk ---
Seems fixed in mesa-18.1.4, no freezes since upgrading.  New kernel too, with
amdgpu.dc=0 set for an unrelated issue.

$ uptime
 14:07:18 up 1 day, 12:48,  1 user,  load average: 16.86, 16.36, 15.81

$ uname -a
Linux eiskaffee 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64
GNU/Linux

$ clinfo | grep Device\ Name | head -n 1
  Device Name Radeon RX 580 Series
(POLARIS10, DRM 3.25.0, 4.17.0-1-amd64, LLVM 6.0.1)

$ apt-cache policy mesa-common-dev
mesa-common-dev:
  Installed: 18.1.4-1
  Candidate: 18.1.4-1
  Version table:
 *** 18.1.4-1 990
990 http://ftp.uk.debian.org/debian buster/main amd64 Packages
500 http://ftp.uk.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: fbdev: add the dependency of broadsheetfb in Kconfig

[Jia-Ju Bai]

broadsheetfb is a platform driver and it should not be used on x86.
It should be used only by single ARM PXA board, so adding the 
dependency in Kconfig.

Signed-off-by: Jia-Ju Bai 
---
 drivers/video/fbdev/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index d94254263ea5..ec91d7a2d8b8 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2241,7 +2241,7 @@ config FB_MX3
 
 config FB_BROADSHEET
tristate "E-Ink Broadsheet/Epson S1D13521 controller support"
-   depends on FB
+   depends on FB && (ARCH_PXA || COMPILE_TEST)
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

[Will Deacon]

On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
> On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> > The proposed solution adds a new option to the base device driver
> > structure that allows device drivers to explicitly convey to the drivers
> > core that the implicit IOMMU backing for devices must not happen.
> 
> Why is IOMMU mapping a problem for the Tegra GPU driver?
> 
> If we add something like this then it should not be the choice of the
> device driver, but of the user and/or the firmware.

Agreed, and it would still need somebody to configure an identity domain so
that transactions aren't aborted immediately. We currently allow the
identity domain to be used by default via a command-line option, so I guess
we'd need a way for firmware to request that on a per-device basis.

Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3.1 10/10] arm64: dts: allwinner: a64: Enable HDMI output on A64 boards w/ HDMI

[Icenowy Zheng]

于 2018年7月27日 GMT+08:00 下午8:56:15, Maxime Ripard  写到:
>On Fri, Jul 27, 2018 at 01:12:57AM +0800, Icenowy Zheng wrote:
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> index 1b9b92e541d2..1b972bade9f6 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>> @@ -62,6 +62,21 @@
>>  chosen {
>>  stdout-path = "serial0:115200n8";
>>  };
>> +
>> +connector {
>> +compatible = "hdmi-connector";
>> +type = "a";
>> +
>> +port {
>> +hdmi_con_in: endpoint {
>> +remote-endpoint = <&hdmi_out_con>;
>> +};
>> +};
>> +};
>> +};
>> +
>> +&de {
>> +status = "okay";
>>  };
>>  
>>  &ehci0 {
>> @@ -82,6 +97,17 @@
>>  
>>  };
>>  
>> +&hdmi {
>> +hdmi-supply = <®_dldo1>;
>> +status = "okay";
>> +};
>> +
>> +&hdmi_out {
>> +hdmi_out_con: endpoint {
>> +remote-endpoint = <&hdmi_con_in>;
>> +};
>> +};
>> +
>>  &i2c1 {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&i2c1_pins>;
>> @@ -99,6 +125,10 @@
>>  };
>>  };
>>  
>> +&mixer1 {
>> +status = "okay";
>> +};
>> +
>>  &mmc0 {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <&mmc0_pins>;
>> @@ -238,6 +268,10 @@
>>  status = "disabled";
>>  };
>>  
>> +&tcon1 {
>> +status = "okay";
>> +};
>
>Is it working or not on the pine64?

Not tested yet, as my main A64 device is Pine A64-LTS now.

>
>Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1] drm/kms/atomic: Improving func drm_atomic_plane_check

[Satendra Singh Thakur]

Currently, in the func drm_atomic_plane_check;
there are 3 if statements in the beginning with total 5 conditions.
these conditions are
crtc is NULL but fb is non-NULL
if (state->crtc && !state->fb)
crtc is non-NULL but fb is NULL
if (state->fb && !state->crtc)
crtc is NULL (and fb is also NULL)
if (!state->crtc)

The same code can be re-written using 2 if statements and 4 conditions.
first we check whether crtc and fb both are NULL
if (!state->crtc && !state->fb)
then we check either crtc or fb is NULL
if (!state->crtc || !state->fb)

Signed-off-by: Satendra Singh Thakur 
---
 v1: Hi Mr Maarten, Thanks for the comments.
 I have splitted them into two patches.  
 
 drivers/gpu/drm/drm_atomic.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 895741e..0415bbf 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -912,18 +912,15 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
unsigned int fb_width, fb_height;
int ret;
 
-   /* either *both* CRTC and FB must be set, or neither */
-   if (state->crtc && !state->fb) {
-   DRM_DEBUG_ATOMIC("CRTC set but no FB\n");
-   return -EINVAL;
-   } else if (state->fb && !state->crtc) {
-   DRM_DEBUG_ATOMIC("FB set but no CRTC\n");
-   return -EINVAL;
-   }
-
/* if disabled, we don't care about the rest of the state: */
-   if (!state->crtc)
+   if (!state->crtc && !state->fb)
return 0;
+   /* both CRTC and FB must be set*/
+   if (!state->crtc || !state->fb) {
+   DRM_DEBUG_ATOMIC("Either invalid CRTC [%p] or invalid FB 
[%p]\n",
+   state->crtc, state->fb);
+   return -EINVAL;
+   }
 
/* Check whether this plane is usable on this CRTC */
if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/kms/atomic: Used existing func for checking fb geometry

[Satendra Singh Thakur]

1.In the func drm_atomic_plane_check, the fb geometry checking code
can be replaced by func drm_framebuffer_check_src_coords, this will
remove several redundant lines of code.
2. Currently, in the func drm_atomic_plane_check;
there are 3 if statements in the beginning with total 5 conditions.
these conditions are
crtc is NULL but fb is non-NULL
if (state->crtc && !state->fb)
crtc is non-NULL but fb is NULL
if (state->fb && !state->crtc)
crtc is NULL (and fb is also NULL)
if (!state->crtc)

The same code can be re-written using 2 if statements and 4 conditions.
first we check whether crtc and fb both are NULL
if (!state->crtc && !state->fb)
then we check either crtc or fb is NULL
if (!state->crtc || !state->fb)

Signed-off-by: Satendra Singh Thakur 
---
 drivers/gpu/drm/drm_atomic.c | 37 +
 1 file changed, 9 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 895741e..1cddab8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -909,22 +909,16 @@ plane_switching_crtc(struct drm_atomic_state *state,
 static int drm_atomic_plane_check(struct drm_plane *plane,
struct drm_plane_state *state)
 {
-   unsigned int fb_width, fb_height;
int ret;
 
-   /* either *both* CRTC and FB must be set, or neither */
-   if (state->crtc && !state->fb) {
-   DRM_DEBUG_ATOMIC("CRTC set but no FB\n");
-   return -EINVAL;
-   } else if (state->fb && !state->crtc) {
-   DRM_DEBUG_ATOMIC("FB set but no CRTC\n");
-   return -EINVAL;
-   }
-
/* if disabled, we don't care about the rest of the state: */
-   if (!state->crtc)
+   if (!state->crtc && !state->fb)
return 0;
-
+   /* both CRTC and FB must be set*/
+   if (!state->crtc || !state->fb) {
+   DRM_DEBUG_ATOMIC("Either no CRTC or no FB\n");
+   return -EINVAL;
+   }
/* Check whether this plane is usable on this CRTC */
if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
DRM_DEBUG_ATOMIC("Invalid crtc for plane\n");
@@ -954,24 +948,11 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
return -ERANGE;
}
 
-   fb_width = state->fb->width << 16;
-   fb_height = state->fb->height << 16;
-
/* Make sure source coordinates are inside the fb. */
-   if (state->src_w > fb_width ||
-   state->src_x > fb_width - state->src_w ||
-   state->src_h > fb_height ||
-   state->src_y > fb_height - state->src_h) {
-   DRM_DEBUG_ATOMIC("Invalid source coordinates "
-"%u.%06ux%u.%06u+%u.%06u+%u.%06u (fb %ux%u)\n",
-state->src_w >> 16, ((state->src_w & 0x) * 
15625) >> 10,
-state->src_h >> 16, ((state->src_h & 0x) * 
15625) >> 10,
-state->src_x >> 16, ((state->src_x & 0x) * 
15625) >> 10,
-state->src_y >> 16, ((state->src_y & 0x) * 
15625) >> 10,
-state->fb->width, state->fb->height);
+   ret = drm_framebuffer_check_src_coords(state->src_x, state->src_y,
+   state->src_w, state->src_h, state->fb);
+   if (ret)
return -ENOSPC;
-   }
-
if (plane_switching_crtc(state->state, plane, state)) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
 plane->base.id, plane->name);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1] drm/kms/atomic: Using existing func for checking framebuffer dimensions

[Satendra Singh Thakur]

In the func drm_atomic_plane_check, the fb geometry checking code
can be replaced by func drm_framebuffer_check_src_coords, this will
remove several redundant lines of code.

Signed-off-by: Satendra Singh Thakur 
---
 v1: Hi Mr Maarten, Thanks for the comments.
 I have splitted them into two patches.  

 drivers/gpu/drm/drm_atomic.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 895741e..953bd2a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -909,7 +909,6 @@ plane_switching_crtc(struct drm_atomic_state *state,
 static int drm_atomic_plane_check(struct drm_plane *plane,
struct drm_plane_state *state)
 {
-   unsigned int fb_width, fb_height;
int ret;
 
/* either *both* CRTC and FB must be set, or neither */
@@ -954,24 +953,11 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
return -ERANGE;
}
 
-   fb_width = state->fb->width << 16;
-   fb_height = state->fb->height << 16;
-
/* Make sure source coordinates are inside the fb. */
-   if (state->src_w > fb_width ||
-   state->src_x > fb_width - state->src_w ||
-   state->src_h > fb_height ||
-   state->src_y > fb_height - state->src_h) {
-   DRM_DEBUG_ATOMIC("Invalid source coordinates "
-"%u.%06ux%u.%06u+%u.%06u+%u.%06u (fb %ux%u)\n",
-state->src_w >> 16, ((state->src_w & 0x) * 
15625) >> 10,
-state->src_h >> 16, ((state->src_h & 0x) * 
15625) >> 10,
-state->src_x >> 16, ((state->src_x & 0x) * 
15625) >> 10,
-state->src_y >> 16, ((state->src_y & 0x) * 
15625) >> 10,
-state->fb->width, state->fb->height);
-   return -ENOSPC;
-   }
-
+   ret = drm_framebuffer_check_src_coords(state->src_x, state->src_y,
+   state->src_w, state->src_h, state->fb);
+   if (ret)
+   return ret;
if (plane_switching_crtc(state->state, plane, state)) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
 plane->base.id, plane->name);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/kms/crtc: Improving the func drm_mode_setcrtc

[Satendra Singh Thakur]

Following changes are done to this func:
1. Currently there are many redundant error checks for
count_connectors, mode, fb and mode_valid.
if (crtc_req->mode_valid)
if (crtc_req->count_connectors == 0 && mode)
if (crtc_req->count_connectors > 0 && (!mode || !fb))
if (crtc_req->count_connectors > 0)
if (crtc_req->count_connectors > config->num_connector)

These 5 checks are replaced by just 2 checks.
if (!crtc_req->mode_valid)
if (!crtc_req->count_connectors ||
crtc_req->count_connectors > config->num_connector)

2. Also, currently, if user pass invalid args
count_connectors=0, mode=NULL, fb=NULL, code wont throw
any errors and eventually __drm_mode_set_config_internal
will be called.
With the modified code, this will be taken care.

3. Also, these error checks alongwith following
if (!file_priv->aspect_ratio_allowed &&
(crtc_req->mode.flags & DRM_MODE_FLAG_PIC_AR_MASK)

has been  moved  before taking mutex and modeset lock
because they don't need any lock. Moreover, after grabbing locks,
if its found that user supplied  invalid args, it will
be too late as getting lock may require considerable time.

4. Also, if modeset_lock is tried many times in case of EDEADLK
error, then this will be the code flow

retry:
ret = drm_modeset_lock_all_ctx(crtc->dev, &ctx);

if (ret)-->this is true
goto out;

out:
if (fb)
if (connector_set)
drm_mode_destroy(dev, mode);
if (ret == -EDEADLK)
goto retry;
It can be observed that checks on fb, connector_set and call to
mode_destroy are redundant in retry-case.
If we keep if (ret == -EDEADLK) just after out:,
that will avoid redundant checks.

In the normal case (non-retry), all checks will be required.
Thus shifting of if (ret == -EDEADLK) right after out label
won't affect normal case.

5. Also, kfree is moved inside if (connector_set).
6. Also, if major error checks are in the beginning of the func
and if user supplied invalid params,  we will exit the func sooner
without wasting much effort in finding crtc and framebuffer etc.

Signed-off-by: Satendra Singh Thakur 
---
 drivers/gpu/drm/drm_crtc.c | 207 +
 1 file changed, 98 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 98a36e6..15927e7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -578,7 +578,25 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
 */
if (crtc_req->x & 0x || crtc_req->y & 0x)
return -ERANGE;
-
+   if (!file_priv->aspect_ratio_allowed &&
+   (crtc_req->mode.flags & DRM_MODE_FLAG_PIC_AR_MASK) !=
+   DRM_MODE_FLAG_PIC_AR_NONE) {
+   DRM_DEBUG_KMS("Unexpected aspect-ratio flag bits\n");
+   return -EINVAL;
+   }
+   /* Check if the flag is set*/
+   if (!crtc_req->mode_valid) {
+   DRM_DEBUG_KMS("mode_valid flag [%d] is not set\n",
+   crtc_req->mode_valid);
+   return -EINVAL;
+   }
+   /* Check the validity of count_connectors supplied by user */
+   if (!crtc_req->count_connectors ||
+   crtc_req->count_connectors > config->num_connector) {
+   DRM_DEBUG_KMS("Invalid connectors' count %d\n",
+   crtc_req->count_connectors);
+   return -EINVAL;
+   }
crtc = drm_crtc_find(dev, file_priv, crtc_req->crtc_id);
if (!crtc) {
DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_req->crtc_id);
@@ -595,134 +613,105 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
if (ret)
goto out;
 
-   if (crtc_req->mode_valid) {
-   /* If we have a mode we need a framebuffer. */
-   /* If we pass -1, set the mode with the currently bound fb */
-   if (crtc_req->fb_id == -1) {
-   struct drm_framebuffer *old_fb;
+   /* If we have a mode we need a framebuffer. */
+   /* If we pass -1, set the mode with the currently bound fb */
+   if (crtc_req->fb_id == -1) {
+   struct drm_framebuffer *old_fb;
 
-   if (plane->state)
-   old_fb = plane->state->fb;
-   else
-   old_fb = plane->fb;
+   if (plane->state)
+   old_fb = plane->state->fb;
+   else
+   old_fb = plane->fb;
 
-   if (!old_fb) {
-   DRM_DEBUG_KMS("CRTC doesn't have current FB\n");
-   ret = -EINVAL;
-   goto out;
-   }
-
-   fb = old_fb;
-   /* Make refcounting symmetric with the lookup path. */
-   drm_framebuffer_get(fb);
-   } else {
-   fb = drm_f

[PATCH] drm: qxl: Fix error handling at qxl_device_init

[Anton Vasilyev]

If qxl_device_init fails on creating resources and does not report it,
then qxl module will catch null pointer exception on remove, or on
probe's error path.

The patch adds error path with resources release into qxl_device_init.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
---
 drivers/gpu/drm/qxl/qxl_kms.c | 80 ---
 1 file changed, 73 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 771250aed78d..e25c589d5f50 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -102,8 +102,10 @@ int qxl_device_init(struct qxl_device *qdev,
int r, sb;
 
r = drm_dev_init(&qdev->ddev, drv, &pdev->dev);
-   if (r)
-   return r;
+   if (r) {
+   pr_err("Unable to init drm dev");
+   goto error;
+   }
 
qdev->ddev.pdev = pdev;
pci_set_drvdata(pdev, &qdev->ddev);
@@ -121,6 +123,11 @@ int qxl_device_init(struct qxl_device *qdev,
qdev->io_base = pci_resource_start(pdev, 3);
 
qdev->vram_mapping = io_mapping_create_wc(qdev->vram_base, 
pci_resource_len(pdev, 0));
+   if (!qdev->vram_mapping) {
+   pr_err("Unable to create vram_mapping");
+   r = -ENOMEM;
+   goto error;
+   }
 
if (pci_resource_len(pdev, 4) > 0) {
/* 64bit surface bar present */
@@ -139,6 +146,11 @@ int qxl_device_init(struct qxl_device *qdev,
qdev->surface_mapping =
io_mapping_create_wc(qdev->surfaceram_base,
 qdev->surfaceram_size);
+   if (!qdev->surface_mapping) {
+   pr_err("Unable to create surface_mapping");
+   r = -ENOMEM;
+   goto vram_mapping_free;
+   }
}
 
DRM_DEBUG_KMS("qxl: vram %llx-%llx(%dM %dk), surface %llx-%llx(%dM %dk, 
%s)\n",
@@ -155,20 +167,29 @@ int qxl_device_init(struct qxl_device *qdev,
qdev->rom = ioremap(qdev->rom_base, qdev->rom_size);
if (!qdev->rom) {
pr_err("Unable to ioremap ROM\n");
-   return -ENOMEM;
+   r = -ENOMEM;
+   goto surface_mapping_free;
}
 
-   qxl_check_device(qdev);
+   if (!qxl_check_device(qdev)) {
+   r = -ENODEV;
+   goto surface_mapping_free;
+   }
 
r = qxl_bo_init(qdev);
if (r) {
DRM_ERROR("bo init failed %d\n", r);
-   return r;
+   goto rom_unmap;
}
 
qdev->ram_header = ioremap(qdev->vram_base +
   qdev->rom->ram_header_offset,
   sizeof(*qdev->ram_header));
+   if (!qdev->ram_header) {
+   DRM_ERROR("Unable to ioremap RAM header\n");
+   r = -ENOMEM;
+   goto bo_fini;
+   }
 
qdev->command_ring = qxl_ring_create(&(qdev->ram_header->cmd_ring_hdr),
 sizeof(struct qxl_command),
@@ -176,6 +197,11 @@ int qxl_device_init(struct qxl_device *qdev,
 qdev->io_base + QXL_IO_NOTIFY_CMD,
 false,
 &qdev->display_event);
+   if (!qdev->command_ring) {
+   DRM_ERROR("Unable to create command ring\n");
+   r = -ENOMEM;
+   goto ram_header_unmap;
+   }
 
qdev->cursor_ring = qxl_ring_create(
&(qdev->ram_header->cursor_ring_hdr),
@@ -185,12 +211,23 @@ int qxl_device_init(struct qxl_device *qdev,
false,
&qdev->cursor_event);
 
+   if (!qdev->cursor_ring) {
+   DRM_ERROR("Unable to create cursor ring\n");
+   r = -ENOMEM;
+   goto command_ring_free;
+   }
+
qdev->release_ring = qxl_ring_create(
&(qdev->ram_header->release_ring_hdr),
sizeof(uint64_t),
QXL_RELEASE_RING_SIZE, 0, true,
NULL);
 
+   if (!qdev->release_ring) {
+   DRM_ERROR("Unable to create release ring\n");
+   r = -ENOMEM;
+   goto cursor_ring_free;
+   }
/* TODO - slot initialization should happen on reset. where is our
 * reset handler? */
qdev->n_mem_slots = qdev->rom->slots_end;
@@ -203,6 +240,12 @@ int qxl_device_init(struct qxl_device *qdev,
kmalloc_array(qdev->n_mem_slots, sizeof(struct qxl_memslot),
  GFP_KERNEL);
 
+   if (!qdev->mem_slots) {
+   DRM_ERROR("Unable to alloc mem slots\n");
+   r = -ENOMEM;
+ 

Re: [PATCH v3.1 10/10] arm64: dts: allwinner: a64: Enable HDMI output on A64 boards w/ HDMI

[Maxime Ripard]

On Fri, Jul 27, 2018 at 09:26:11PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2018年7月27日 GMT+08:00 下午8:56:15, Maxime Ripard  
> 写到:
> >On Fri, Jul 27, 2018 at 01:12:57AM +0800, Icenowy Zheng wrote:
> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> index 1b9b92e541d2..1b972bade9f6 100644
> >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> >> @@ -62,6 +62,21 @@
> >>chosen {
> >>stdout-path = "serial0:115200n8";
> >>};
> >> +
> >> +  connector {
> >> +  compatible = "hdmi-connector";
> >> +  type = "a";
> >> +
> >> +  port {
> >> +  hdmi_con_in: endpoint {
> >> +  remote-endpoint = <&hdmi_out_con>;
> >> +  };
> >> +  };
> >> +  };
> >> +};
> >> +
> >> +&de {
> >> +  status = "okay";
> >>  };
> >>  
> >>  &ehci0 {
> >> @@ -82,6 +97,17 @@
> >>  
> >>  };
> >>  
> >> +&hdmi {
> >> +  hdmi-supply = <®_dldo1>;
> >> +  status = "okay";
> >> +};
> >> +
> >> +&hdmi_out {
> >> +  hdmi_out_con: endpoint {
> >> +  remote-endpoint = <&hdmi_con_in>;
> >> +  };
> >> +};
> >> +
> >>  &i2c1 {
> >>pinctrl-names = "default";
> >>pinctrl-0 = <&i2c1_pins>;
> >> @@ -99,6 +125,10 @@
> >>};
> >>  };
> >>  
> >> +&mixer1 {
> >> +  status = "okay";
> >> +};
> >> +
> >>  &mmc0 {
> >>pinctrl-names = "default";
> >>pinctrl-0 = <&mmc0_pins>;
> >> @@ -238,6 +268,10 @@
> >>status = "disabled";
> >>  };
> >>  
> >> +&tcon1 {
> >> +  status = "okay";
> >> +};
> >
> >Is it working or not on the pine64?
> 
> Not tested yet, as my main A64 device is Pine A64-LTS now.

It was last reported as broken, so it's better to leave it out of that
patch until someone figures it out.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

[Joerg Roedel]

On Fri, Jul 27, 2018 at 05:10:22PM +0300, Dmitry Osipenko wrote:
> I'm not sure what you guys are meaning by the "firmware", could you elaborate 
> please? Do you mean the Open Firmware and hence the devicetree or what?

Yes, I think the best way to request this is using a device-tree
property. Letting the device driver request it is definitly a bad idea.


Joerg

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200605] Screen flickering on AMD graphics in 4.18

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200605

--- Comment #3 from ric...@gmx.at ---
I didn't forget, it just didn't happen since then...

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

gr...@sub.red changed:

   What|Removed |Added

 CC||gr...@sub.red

--- Comment #22 from gr...@sub.red ---
Created attachment 140858
  --> https://bugs.freedesktop.org/attachment.cgi?id=140858&action=edit
GALLIUM_HUD showing stuttering

I can confirm the issue.

Having a Radeon R9 290X (Hawaii XT), DC introduces heavy stuttering on a
composited X desktop while interacting with the window manager. This stuttering
can't be resolved by forcing high power states.

Attached is a screenshot to give an impression of the stuttering.
Top left is the GALLIUM_HUD with the compositor's frame rate and frame time
graph. On the right, there is Firefox with the page
https://testufo.com/photo#photo=quebec.jpg&pps=960&pursuit=0&height=0 having
hardware acceleration force-enabled and also showing fps/frametime graphs. The
web page has continuous movement, ensures that there is a screen update every
frame and makes it easy to detect stutter.
This looks perfectly fine and the graphs represent that as well.
On the bottom there is the same setup but while changing window focus or moving
a third window around. Firefox stutters as hell (suspecting vsync stuttering)
and the graphs show that as well.

Disabling DC resolves the issue completely and the bottom scenario would look
and feel the same as the upper one with DC.

In this current situation, I could disable DC and have a smooth desktop at the
cost of several dozens of watts idle power or save power and use a stuttering
desktop with DC enabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107390] [BISECTED] EDID read failure breaks display mirroring

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107390

Alex Deucher  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com,
   ||sunpeng...@amd.com

--- Comment #8 from Alex Deucher  ---
Harry, Leo, any objections to reverting this?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107021] AMDGPU crash when Power Management switches off screen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107021

--- Comment #2 from f...@hardijzer.nl ---
Same issue on 4.18.0-rc3, also on a Vega 64. My machine also locks up whenever
I manually turn off my monitor with its physical button.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200667] [AMDGPU] stacktrace in dmesg, starting at drm_dp_i2c_do_msg

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200667

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

[Robin Murphy]

On 27/07/18 15:10, Dmitry Osipenko wrote:

On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:

On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:

On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:

The proposed solution adds a new option to the base device driver
structure that allows device drivers to explicitly convey to the drivers
core that the implicit IOMMU backing for devices must not happen.


Why is IOMMU mapping a problem for the Tegra GPU driver?

If we add something like this then it should not be the choice of the
device driver, but of the user and/or the firmware.


Agreed, and it would still need somebody to configure an identity domain so
that transactions aren't aborted immediately. We currently allow the
identity domain to be used by default via a command-line option, so I guess
we'd need a way for firmware to request that on a per-device basis.


The IOMMU mapping itself is not a problem, the problem is the management of
the IOMMU. For Tegra we don't want anything to intrude into the IOMMU
activities because:

1) GPU HW require additional configuration for the IOMMU usage and dumb
mapping of the allocations simply doesn't work.


Generally, that's already handled by the DRM drivers allocating their 
own unmanaged domains. The only problem we really need to solve in that 
regard is that currently the device DMA ops don't get updated when 
moving away from the managed domain. That's been OK for the VFIO case 
where the device is bound to a different driver which we know won't make 
any explicit DMA API calls, but for the more general case of IOMMU-aware 
drivers we could certainly do with a bit of cooperation between the 
IOMMU API, DMA API, and arch code to update the DMA ops dynamically to 
cope with intermediate subsystems making DMA API calls on behalf of 
devices they don't know the intimate details of.



2) Older Tegra generations have a limited resource and capabilities in regards
to IOMMU usage, allocating IOMMU domain per-device is just impossible for
example.

3) HW performs context switches and so particular allocations have to be
assigned to a particular contexts IOMMU domain.


I understand Qualcomm SoCs have a similar thing too, and AFAICS that 
case just doesn't fit into the current API model at all. We need the 
IOMMU driver to somehow know about the specific details of which devices 
have magic associations with specific contexts, and we almost certainly 
need a more expressive interface than iommu_domain_alloc() to have any 
hope of reliable results.


Robin.


Some of the above is due to a SW driver model (and its work-in-progress
status), other is due to a HW model. So essentially we need a way for a driver
to tell the core not to mess with IOMMU stuff of drivers device behind the
drivers back.

I'm not sure what you guys are meaning by the "firmware", could you elaborate
please? Do you mean the Open Firmware and hence the devicetree or what?



___
iommu mailing list
io...@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103907] [gfx9/Vega] Arma 3 crashes on 17.3.0-rc5 but works on master

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103907

--- Comment #3 from thomas.rin...@arcor.de ---
Bisecting would be very hard since the crashes appear randomly.

However the error seems to be gone.
Either by 18.1.4 or with the new game version that was released this week.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

[Jordan Crouse]

On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> On 27/07/18 15:10, Dmitry Osipenko wrote:
> >On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
> >>On Fri, Jul 27, 2018 at 10:25:13AM +0200, Joerg Roedel wrote:
> >>>On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> The proposed solution adds a new option to the base device driver
> structure that allows device drivers to explicitly convey to the drivers
> core that the implicit IOMMU backing for devices must not happen.
> >>>
> >>>Why is IOMMU mapping a problem for the Tegra GPU driver?
> >>>
> >>>If we add something like this then it should not be the choice of the
> >>>device driver, but of the user and/or the firmware.
> >>
> >>Agreed, and it would still need somebody to configure an identity domain so
> >>that transactions aren't aborted immediately. We currently allow the
> >>identity domain to be used by default via a command-line option, so I guess
> >>we'd need a way for firmware to request that on a per-device basis.
> >
> >The IOMMU mapping itself is not a problem, the problem is the management of
> >the IOMMU. For Tegra we don't want anything to intrude into the IOMMU
> >activities because:
> >
> >1) GPU HW require additional configuration for the IOMMU usage and dumb
> >mapping of the allocations simply doesn't work.
> 
> Generally, that's already handled by the DRM drivers allocating
> their own unmanaged domains. The only problem we really need to
> solve in that regard is that currently the device DMA ops don't get
> updated when moving away from the managed domain. That's been OK for
> the VFIO case where the device is bound to a different driver which
> we know won't make any explicit DMA API calls, but for the more
> general case of IOMMU-aware drivers we could certainly do with a bit
> of cooperation between the IOMMU API, DMA API, and arch code to
> update the DMA ops dynamically to cope with intermediate subsystems
> making DMA API calls on behalf of devices they don't know the
> intimate details of.
> 
> >2) Older Tegra generations have a limited resource and capabilities in 
> >regards
> >to IOMMU usage, allocating IOMMU domain per-device is just impossible for
> >example.
> >
> >3) HW performs context switches and so particular allocations have to be
> >assigned to a particular contexts IOMMU domain.
> 
> I understand Qualcomm SoCs have a similar thing too, and AFAICS that
> case just doesn't fit into the current API model at all. We need the
> IOMMU driver to somehow know about the specific details of which
> devices have magic associations with specific contexts, and we
> almost certainly need a more expressive interface than
> iommu_domain_alloc() to have any hope of reliable results.

This is correct for Qualcomm GPUs - The GPU hardware context switching 
requires a specific context and there are some restrictions around
secure contexts as well.

We don't really care if the DMA attaches to a context just as long as it
doesn't attach to the one(s) we care about. Perhaps a "valid context" mask would
work in from the DT or the device struct to give the subsystems a clue as to
which domains they were allowed to use. I recognize that there isn't a
one-size-fits-all solution to this problem so I'm open to different ideas.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

[Rob Herring]

On Fri, Jul 27, 2018 at 8:20 AM Joerg Roedel  wrote:
>
> On Fri, Jul 27, 2018 at 05:10:22PM +0300, Dmitry Osipenko wrote:
> > I'm not sure what you guys are meaning by the "firmware", could you 
> > elaborate
> > please? Do you mean the Open Firmware and hence the devicetree or what?
>
> Yes, I think the best way to request this is using a device-tree
> property. Letting the device driver request it is definitly a bad idea.

I don't follow why we need a property rather than being implied by the
device's (the GPU) compatible string.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] v4l: vsp1: Fix deadlock in VSPDL DRM pipelines

[Laurent Pinchart]

The VSP uses a lock to protect the BRU and BRS assignment when
configuring pipelines. The lock is taken in vsp1_du_atomic_begin() and
released in vsp1_du_atomic_flush(), as well as taken and released in
vsp1_du_setup_lif(). This guards against multiple pipelines trying to
assign the same BRU and BRS at the same time.

The DRM framework calls the .atomic_begin() operations in a loop over
all CRTCs included in an atomic commit. On a VSPDL (the only VSP type
where this matters), a single VSP instance handles two CRTCs, with a
single lock. This results in a deadlock when the .atomic_begin()
operation is called on the second CRTC.

The DRM framework serializes atomic commits that affect the same CRTCs,
but doesn't know about two CRTCs sharing the same VSPDL. Two commits
affecting the VSPDL LIF0 and LIF1 respectively can thus race each other,
hence the need for a lock.

This could be fixed on the DRM side by forcing serialization of commits
affecting CRTCs backed by the same VSPDL, but that would negatively
affect performances, as the locking is only needed when the BRU and BRS
need to be reassigned, which is an uncommon case.

The lock protects the whole .atomic_begin() to .atomic_flush() sequence.
The only operation that can occur in-between is vsp1_du_atomic_update(),
which doesn't touch the BRU and BRS, and thus doesn't need to be
protected by the lock. We can thus only take the lock around the
pipeline setup calls in vsp1_du_atomic_flush(), which fixes the
deadlock.

Fixes: f81f9adc4ee1 ("media: v4l: vsp1: Assign BRU and BRS to pipelines 
dynamically")
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

I've successfully tested the patch with kmstest --flip running with four
outputs on a Salvator-XS board, as well as with the DU kms-test-brxalloc.py
test. The deadlock is gone, and no race has been observed.

Mauro, this is a v4.18 regression fix. I'm sorry for sending it so late,
I haven't noticed the issue earlier. Once Kieran reviews it (which should
happen in the next few days), could you send it to Linus ? The breakage is
pretty bad otherwise for people using both the VGA and LVDS outputs at the
same time.

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index edb35a5c57ea..a99fc0ced7a7 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -728,9 +728,6 @@ EXPORT_SYMBOL_GPL(vsp1_du_setup_lif);
  */
 void vsp1_du_atomic_begin(struct device *dev, unsigned int pipe_index)
 {
-   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
-
-   mutex_lock(&vsp1->drm->lock);
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_begin);
 
@@ -846,6 +843,7 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned int 
pipe_index,
 
drm_pipe->crc = cfg->crc;
 
+   mutex_lock(&vsp1->drm->lock);
vsp1_du_pipeline_setup_inputs(vsp1, pipe);
vsp1_du_pipeline_configure(pipe);
mutex_unlock(&vsp1->drm->lock);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104300] Kernel 4.15-rc2 on Polaris RX 480 with amdgpu.dc=1 has trouble waking up displays after suspend

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104300

--- Comment #6 from Mariusz Mazur  ---
I found it! Before I knew 4.14 worked fine and 4.15+ introduced this bug.

Now I know precisely which patches:
- 4.14.35 works correctly
- 4.14.36 exhibits this behavior

There are only a few amdgpu patches in there, one by Bas Nieuwenhuizen
@chromium and a few by Alex Deucher @amd. Now I need to figure out how to set
up a kernel-building env and test which patch in particular is the one that
breaks everything.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200667] [AMDGPU] stacktrace in dmesg, starting at drm_dp_i2c_do_msg

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200667

--- Comment #5 from Christian Widmer (cwid...@umbrox.de) ---
The bisect identified commit 9168c089a2122606e2c01f6fbeda85ff950ac189 (Revert
"drm/amd/display: Don't return ddc result and read_bytes in same return value",
upstream commit 5292221d6ddfed75e5b46cd42237a677094b99f3). And a quick test
with reverting this change in my distribution's 4.17.10 kernel and in the
mainline 4.18-rc6 kernel indeed made the stacktrace disappear.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200667] [AMDGPU] stacktrace in dmesg, starting at drm_dp_i2c_do_msg

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200667

--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
The warning is harmless.  As per the commit message, this is fixed properly for
4.19 with the following patches:

This breaks DDC in certain cases.  Revert for 4.18 and previous kernels.
For 4.19, this is fixed with the following more extensive patches:
drm/amd/display: Serialize is_dp_sink_present
drm/amd/display: Break out function to simply read aux reply
drm/amd/display: Return aux replies directly to DRM
drm/amd/display: Right shift AUX reply value sooner than later
drm/amd/display: Read AUX channel even if only status byte is returned

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU

[Joerg Roedel]

On Fri, Jul 27, 2018 at 11:13:31AM -0600, Rob Herring wrote:
> I don't follow why we need a property rather than being implied by the
> device's (the GPU) compatible string.

There might be devices where either setup works, with or without IOMMU
translation, and the firmware can set the property depending on whether
the user wants more performance or more security.

If we have a whitelist in the kernel this gets more complicated, we
probably need additional kernel-parameters to overwrite those whitelist
entries. Having a property in the device-tree seems to be a better way
here, imho.


Joerg

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 200667] [AMDGPU] stacktrace in dmesg, starting at drm_dp_i2c_do_msg

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200667

--- Comment #7 from Christian Widmer (cwid...@umbrox.de) ---
For the sake of completeness I have just tested linux-next which contains all
those patches and the warning is indeed gone. Thank you for your responses!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm/vc4: Define missing PICTH0_SINK_PIX field

[Eric Anholt]

Boris Brezillon  writes:

> From: Eric Anholt 

In the subject, s/PICTH/PITCH/


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dp: add missing ')' to I2C nack debug message

[Paulo Zanoni]

 "(an unmatched left parenthesis
  creates an unresolved tension
  that will stay with you all day."
   -- Randall Munroe

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_dp_helper.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0cccbcb2d03e..8c6b9fd89f8a 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -850,7 +850,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
return ret;
 
case DP_AUX_I2C_REPLY_NACK:
-   DRM_DEBUG_KMS("I2C nack (result=%d, size=%zu\n", ret, 
msg->size);
+   DRM_DEBUG_KMS("I2C nack (result=%d, size=%zu)\n",
+ ret, msg->size);
aux->i2c_nack_count++;
return -EREMOTEIO;
 
-- 
2.14.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/vc4: Use drm_atomic_helper_check_plane_state() to simplify the logic

[Eric Anholt]

Boris Brezillon  writes:

> From: Eric Anholt 
>
> drm_atomic_helper_check_plane_state() takes care of checking the
> scaling capabilities and calculating the clipped X/Y offsets for us.
>
> Rely on this function instead of open-coding the logic. While at it, we
> get rid of a few fields in vc4_plane_state that can be easily extracted
> from drm_plane_state.
>
> Incidentally, it seems to fix a problem we had with negative X/Y
> positioning of YUV planes.
>
> Signed-off-by: Eric Anholt 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/gpu/drm/vc4/vc4_drv.h   |   9 --
>  drivers/gpu/drm/vc4/vc4_plane.c | 210 
> +---
>  2 files changed, 111 insertions(+), 108 deletions(-)

I feel like you ought to grab authorship of this patch -- you've made a
bunch of good changes since my WIP patch.

>   if (num_planes > 1) {
> - vc4_state->is_yuv = true;
> -
> - h_subsample = drm_format_horz_chroma_subsampling(format);
> - v_subsample = drm_format_vert_chroma_subsampling(format);
> - vc4_state->src_w[1] = vc4_state->src_w[0] / h_subsample;
> - vc4_state->src_h[1] = vc4_state->src_h[0] / v_subsample;
> + src_w /= h_subsample;
> + src_h /= v_subsample;

I'm a little nervous about leaving src_w/src_h divided after this block,
in case we end up using them in some other calculation in a later
change.  Could we just move the divide into the vc4_get_scaling_mode()
call?

In general, I'm not enthusiastic about having src_w computations in 5
places now.  Was keeping it in the vc4 state that much of a problem?

I'm not saying no, but copy-and-paste of these kinds of calculations are
also a frequent source of bugs when you miss a x->y or w->h change.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: add missing ')' to I2C nack debug message

[Alex Deucher]

On Fri, Jul 27, 2018 at 4:33 PM, Paulo Zanoni  wrote:
>  "(an unmatched left parenthesis
>   creates an unresolved tension
>   that will stay with you all day."
>-- Randall Munroe
>
> Signed-off-by: Paulo Zanoni 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 0cccbcb2d03e..8c6b9fd89f8a 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -850,7 +850,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
> return ret;
>
> case DP_AUX_I2C_REPLY_NACK:
> -   DRM_DEBUG_KMS("I2C nack (result=%d, size=%zu\n", ret, 
> msg->size);
> +   DRM_DEBUG_KMS("I2C nack (result=%d, size=%zu)\n",
> + ret, msg->size);
> aux->i2c_nack_count++;
> return -EREMOTEIO;
>
> --
> 2.14.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel