Re: [PATCH v6] drm/panel: Add a driver for the TPO TPG110

2019-01-10 Thread Thierry Reding
On Wed, Jan 09, 2019 at 02:53:31PM +0100, Linus Walleij wrote:
[...]
> diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c 
> b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
[...]
> +static int tpg110_startup(struct tpg110 *tpg)
> +{
> + u8 val;
> + int i;
> +
> + /* De-assert the reset signal */
> + gpiod_set_value_cansleep(tpg->grestb, 0);
> + mdelay(1);

Does this have to be the spinning variant? This seems to be only used in
the probe path, so doesn't have to be atomic.

> + dev_info(tpg->dev, "de-asserted GRESTB\n");

Maybe turn this into dev_dbg()?

> +
> + /* Test display communication */
> + tpg110_write_reg(tpg, TPG110_TEST, 0x55);
> + val = tpg110_read_reg(tpg, TPG110_TEST);
> + if (val != 0x55) {
> + dev_err(tpg->dev, "failed communication test\n");
> + return -ENODEV;
> + }
> +
> + val = tpg110_read_reg(tpg, TPG110_CHIPID);
> + dev_info(tpg->dev, "TPG110 chip ID: %d version: %d\n",
> +  val >> 4, val & 0x0f);
> +
> + /* Show display resolution */
> + val = tpg110_read_reg(tpg, TPG110_CTRL1);
> + val &= TPG110_RES_MASK;
> + switch (val) {
> + case TPG110_RES_400X240_D:
> + dev_info(tpg->dev,
> +  "IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
> + break;
> + case TPG110_RES_480X272_D:
> + dev_info(tpg->dev,
> +  "IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
> + break;
> + case TPG110_RES_480X640:
> + dev_info(tpg->dev, "480x640 RGB");
> + break;
> + case TPG110_RES_480X272:
> + dev_info(tpg->dev, "480x272 RGB");
> + break;
> + case TPG110_RES_640X480:
> + dev_info(tpg->dev, "640x480 RGB");
> + break;
> + case TPG110_RES_800X480:
> + dev_info(tpg->dev, "800x480 RGB");
> + break;
> + default:
> + dev_info(tpg->dev, "ILLEGAL RESOLUTION");

dev_err()? Also, perhaps make this some proper error message and include
the invalid value?

Also I just noticed that the above informational messages all lack a \n
at the end.

The above is also very verbose, do we really need all that information
in the kernel log?

> + break;
> + }
> +
> + /* From the producer side, this is the same resolution */
> + if (val == TPG110_RES_480X272_D)
> + val = TPG110_RES_480X272;
> +
> + for (i = 0; i < ARRAY_SIZE(tpg110_modes); i++) {
> + const struct tpg110_panel_mode *pm;
> +
> + pm = &tpg110_modes[i];
> + if (pm->magic == val) {
> + tpg->panel_mode = pm;
> + break;
> + }
> + }
> + if (i == ARRAY_SIZE(tpg110_modes)) {
> + dev_err(tpg->dev, "unsupported mode (%02x) detected\n",
> + val);
> + return -ENODEV;
> + }
> +
> + val = tpg110_read_reg(tpg, TPG110_CTRL2);
> + dev_info(tpg->dev, "resolution and standby is controlled by %s\n",
> +  (val & TPG110_CTRL2_RES_PM_CTRL) ? "software" : "hardware");
> + /* Take control over resolution and standby */
> + val |= TPG110_CTRL2_RES_PM_CTRL;
> + tpg110_write_reg(tpg, TPG110_CTRL2, val);
> +
> + return 0;
> +}
> +
> +static int tpg110_disable(struct drm_panel *panel)
> +{
> + struct tpg110 *tpg = to_tpg110(panel);
> + u8 val;
> +
> + /* Put chip into standby */
> + val = tpg110_read_reg(tpg, TPG110_CTRL2_PM);
> + val &= ~TPG110_CTRL2_PM;
> + tpg110_write_reg(tpg, TPG110_CTRL2_PM, val);
> +
> + if (tpg->backlight) {
> + tpg->backlight->props.power = FB_BLANK_POWERDOWN;
> + tpg->backlight->props.state |= BL_CORE_FBBLANK;
> + backlight_update_status(tpg->backlight);
> + }

backlight_disable()?

> +
> + return 0;
> +}
> +
> +static int tpg110_enable(struct drm_panel *panel)
> +{
> + struct tpg110 *tpg = to_tpg110(panel);
> + u8 val;
> +
> + if (tpg->backlight) {
> + tpg->backlight->props.state &= ~BL_CORE_FBBLANK;
> + tpg->backlight->props.power = FB_BLANK_UNBLANK;
> + backlight_update_status(tpg->backlight);
> + }

backlight_enable()?

Thierry


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


[PATCH] drm/qxl: drop prime import/export callbacks

2019-01-10 Thread Gerd Hoffmann
Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
userspace.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_drv.c   |  4 
 drivers/gpu/drm/qxl/qxl_prime.c | 14 --
 2 files changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 13c8a662f9..ccb090f3ab 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -250,14 +250,10 @@ static struct drm_driver qxl_driver = {
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = qxl_debugfs_init,
 #endif
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = qxl_gem_prime_pin,
.gem_prime_unpin = qxl_gem_prime_unpin,
-   .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
-   .gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
.gem_prime_vmap = qxl_gem_prime_vmap,
.gem_prime_vunmap = qxl_gem_prime_vunmap,
.gem_prime_mmap = qxl_gem_prime_mmap,
diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
index a55dece118..df65d3c1a7 100644
--- a/drivers/gpu/drm/qxl/qxl_prime.c
+++ b/drivers/gpu/drm/qxl/qxl_prime.c
@@ -38,20 +38,6 @@ void qxl_gem_prime_unpin(struct drm_gem_object *obj)
WARN_ONCE(1, "not implemented");
 }
 
-struct sg_table *qxl_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
-   WARN_ONCE(1, "not implemented");
-   return ERR_PTR(-ENOSYS);
-}
-
-struct drm_gem_object *qxl_gem_prime_import_sg_table(
-   struct drm_device *dev, struct dma_buf_attachment *attach,
-   struct sg_table *table)
-{
-   WARN_ONCE(1, "not implemented");
-   return ERR_PTR(-ENOSYS);
-}
-
 void *qxl_gem_prime_vmap(struct drm_gem_object *obj)
 {
WARN_ONCE(1, "not implemented");
-- 
2.9.3

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


Re: [PATCH 2/9] drm/mediatek: move the setting of fixed divider

2019-01-10 Thread CK Hu
Hi, Chunhui:

On Fri, 2019-01-04 at 15:03 +0800, chunhui dai wrote:
> move the setting of fixed divider from enable/disable
> to the function of setting rate.

Please describe more about _WHY_ of this patch. Does it fix any bug, or
enhance some thing, or a new feature?

Regards,
CK

> 
> Signed-off-by: chunhui dai 
> ---
>  drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index b5ed6b7..68b124f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -79,7 +79,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
>   usleep_range(80, 100);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
> - mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
> @@ -94,7 +93,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
> - mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
>   usleep_range(80, 100);
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
> @@ -123,6 +121,7 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>  
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
> + mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
>   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC),
> RG_HTPLL_IC_MASK);
>   mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR),
> @@ -223,7 +222,6 @@ static void mtk_hdmi_phy_enable_tmds(struct mtk_hdmi_phy 
> *hdmi_phy)
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
>   usleep_range(80, 100);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
> - mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
>   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
> @@ -235,7 +233,6 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy 
> *hdmi_phy)
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
> - mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
>   usleep_range(80, 100);
>   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);


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


[PATCH v3 15/15] drm/bochs: move remaining fb bits to kms

2019-01-10 Thread Gerd Hoffmann
bochs_fbdev.c is almost empty now.  Move the remaining framebuffer bits
over to bochs_kms.c.  Pure code motion. No functional change.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c | 29 -
 drivers/gpu/drm/bochs/bochs_kms.c   | 17 +
 drivers/gpu/drm/bochs/Makefile  |  2 +-
 3 files changed, 18 insertions(+), 30 deletions(-)
 delete mode 100644 drivers/gpu/drm/bochs/bochs_fbdev.c

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
deleted file mode 100644
index 7cac3f5253..00
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include "bochs.h"
-#include 
-#include 
-
-/* -- */
-
-static struct drm_framebuffer *
-bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
-   const struct drm_mode_fb_cmd2 *mode_cmd)
-{
-   if (mode_cmd->pixel_format != DRM_FORMAT_XRGB &&
-   mode_cmd->pixel_format != DRM_FORMAT_BGRX)
-   return ERR_PTR(-EINVAL);
-
-   return drm_gem_fb_create(dev, file, mode_cmd);
-}
-
-const struct drm_mode_config_funcs bochs_mode_funcs = {
-   .fb_create = bochs_gem_fb_create,
-   .atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
-};
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index fc856a02a2..e9d5dbc346 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int defx = 1024;
 static int defy = 768;
@@ -256,6 +257,22 @@ static void bochs_connector_init(struct drm_device *dev)
}
 }
 
+static struct drm_framebuffer *
+bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
+   const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   if (mode_cmd->pixel_format != DRM_FORMAT_XRGB &&
+   mode_cmd->pixel_format != DRM_FORMAT_BGRX)
+   return ERR_PTR(-EINVAL);
+
+   return drm_gem_fb_create(dev, file, mode_cmd);
+}
+
+const struct drm_mode_config_funcs bochs_mode_funcs = {
+   .fb_create = bochs_gem_fb_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
 
 int bochs_kms_init(struct bochs_device *bochs)
 {
diff --git a/drivers/gpu/drm/bochs/Makefile b/drivers/gpu/drm/bochs/Makefile
index 98ef60a19e..e9e0f8f5eb 100644
--- a/drivers/gpu/drm/bochs/Makefile
+++ b/drivers/gpu/drm/bochs/Makefile
@@ -1,3 +1,3 @@
-bochs-drm-y := bochs_drv.o bochs_mm.o bochs_kms.o bochs_fbdev.o bochs_hw.o
+bochs-drm-y := bochs_drv.o bochs_mm.o bochs_kms.o bochs_hw.o
 
 obj-$(CONFIG_DRM_BOCHS)+= bochs-drm.o
-- 
2.9.3

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


[PATCH v3 05/15] drm/bochs: atomic: switch planes to atomic, wire up helpers.

2019-01-10 Thread Gerd Hoffmann
Conversion to atomic modesetting, step three.
Wire up atomic helpers.  Switch planes to atomic.

We are late to the party, the transitional helpers are gone,
so this can't be splitted into smaller steps any more.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c |  3 ++
 drivers/gpu/drm/bochs/bochs_kms.c   | 82 +++--
 2 files changed, 82 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index dd3c7df267..d9f3d42999 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -6,6 +6,7 @@
  */
 
 #include "bochs.h"
+#include 
 #include 
 
 /* -- */
@@ -149,6 +150,8 @@ bochs_gem_fb_create(struct drm_device *dev, struct drm_file 
*file,
 
 const struct drm_mode_config_funcs bochs_mode_funcs = {
.fb_create = bochs_gem_fb_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 int bochs_fbdev_init(struct bochs_device *bochs)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 56fd7be933..c6993c2d59 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -6,7 +6,9 @@
  */
 
 #include "bochs.h"
+#include 
 #include 
+#include 
 
 static int defx = 1024;
 static int defy = 768;
@@ -113,7 +115,7 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned long irqflags;
 
-   crtc->primary->fb = fb;
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
bochs_crtc_mode_set_base(crtc, 0, 0, old_fb);
if (event) {
spin_lock_irqsave(&bochs->dev->event_lock, irqflags);
@@ -151,6 +153,9 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = drm_crtc_cleanup,
.page_flip = bochs_crtc_page_flip,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };
 
 static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
@@ -169,6 +174,71 @@ static const uint32_t bochs_formats[] = {
DRM_FORMAT_BGRX,
 };
 
+static void bochs_plane_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+   struct bochs_device *bochs = plane->dev->dev_private;
+   struct bochs_bo *bo;
+
+   if (!plane->state->fb)
+   return;
+   bo = gem_to_bochs_bo(plane->state->fb->obj[0]);
+   bochs_hw_setbase(bochs,
+plane->state->crtc_x,
+plane->state->crtc_y,
+bo->bo.offset);
+   bochs_hw_setformat(bochs, plane->state->fb->format);
+}
+
+static int bochs_plane_prepare_fb(struct drm_plane *plane,
+   struct drm_plane_state *new_state)
+{
+   struct bochs_bo *bo;
+   int ret;
+
+   if (!new_state->fb)
+   return 0;
+   bo = gem_to_bochs_bo(new_state->fb->obj[0]);
+
+   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
+   if (ret)
+   return ret;
+   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
+   ttm_bo_unreserve(&bo->bo);
+   return ret;
+}
+
+static void bochs_plane_cleanup_fb(struct drm_plane *plane,
+  struct drm_plane_state *old_state)
+{
+   struct bochs_bo *bo;
+   int ret;
+
+   if (!old_state->fb)
+   return;
+   bo = gem_to_bochs_bo(old_state->fb->obj[0]);
+   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
+   if (ret)
+   return;
+   bochs_bo_unpin(bo);
+   ttm_bo_unreserve(&bo->bo);
+}
+
+static const struct drm_plane_helper_funcs bochs_plane_helper_funcs = {
+   .atomic_update = bochs_plane_atomic_update,
+   .prepare_fb = bochs_plane_prepare_fb,
+   .cleanup_fb = bochs_plane_cleanup_fb,
+};
+
+static const struct drm_plane_funcs bochs_plane_funcs = {
+   .update_plane   = drm_atomic_helper_update_plane,
+   .disable_plane  = drm_atomic_helper_disable_plane,
+   .destroy= drm_primary_helper_destroy,
+   .reset  = drm_atomic_helper_plane_reset,
+   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+};
+
 static struct drm_plane *bochs_primary_plane(struct drm_device *dev)
 {
struct drm_plane *primary;
@@ -181,16 +251,17 @@ static struct drm_plane *bochs_primary_plane(struct 
drm_device *dev)
}
 
ret = drm_universal_plane_init(dev, primary, 0,
-  &drm

[PATCH v3 09/15] drm/bochs: remove old bochs_crtc_* functions

2019-01-10 Thread Gerd Hoffmann
Remove the old, now unused crtc callbacks.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 81 ---
 1 file changed, 81 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 67c3674609..5b7e1a7c6b 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -20,74 +20,6 @@ MODULE_PARM_DESC(defy, "default y resolution");
 
 /* -- */
 
-static void bochs_crtc_dpms(struct drm_crtc *crtc, int mode)
-{
-   switch (mode) {
-   case DRM_MODE_DPMS_ON:
-   case DRM_MODE_DPMS_STANDBY:
-   case DRM_MODE_DPMS_SUSPEND:
-   case DRM_MODE_DPMS_OFF:
-   default:
-   return;
-   }
-}
-
-static int bochs_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
-   struct drm_framebuffer *old_fb)
-{
-   struct bochs_device *bochs =
-   container_of(crtc, struct bochs_device, crtc);
-   struct bochs_bo *bo;
-   u64 gpu_addr = 0;
-   int ret;
-
-   if (old_fb) {
-   bo = gem_to_bochs_bo(old_fb->obj[0]);
-   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
-   if (ret) {
-   DRM_ERROR("failed to reserve old_fb bo\n");
-   } else {
-   bochs_bo_unpin(bo);
-   ttm_bo_unreserve(&bo->bo);
-   }
-   }
-
-   if (WARN_ON(crtc->primary->fb == NULL))
-   return -EINVAL;
-
-   bo = gem_to_bochs_bo(crtc->primary->fb->obj[0]);
-   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
-   if (ret)
-   return ret;
-
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr);
-   if (ret) {
-   ttm_bo_unreserve(&bo->bo);
-   return ret;
-   }
-
-   ttm_bo_unreserve(&bo->bo);
-   bochs_hw_setbase(bochs, x, y, gpu_addr);
-   return 0;
-}
-
-static int bochs_crtc_mode_set(struct drm_crtc *crtc,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode,
-  int x, int y, struct drm_framebuffer *old_fb)
-{
-   struct bochs_device *bochs =
-   container_of(crtc, struct bochs_device, crtc);
-
-   if (WARN_ON(crtc->primary->fb == NULL))
-   return -EINVAL;
-
-   bochs_hw_setmode(bochs, mode);
-   bochs_hw_setformat(bochs, crtc->primary->fb->format);
-   bochs_crtc_mode_set_base(crtc, x, y, old_fb);
-   return 0;
-}
-
 static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct bochs_device *bochs =
@@ -96,14 +28,6 @@ static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc)
bochs_hw_setmode(bochs, &crtc->mode);
 }
 
-static void bochs_crtc_prepare(struct drm_crtc *crtc)
-{
-}
-
-static void bochs_crtc_commit(struct drm_crtc *crtc)
-{
-}
-
 static void bochs_crtc_atomic_enable(struct drm_crtc *crtc,
 struct drm_crtc_state *old_crtc_state)
 {
@@ -138,12 +62,7 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
 };
 
 static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
-   .dpms = bochs_crtc_dpms,
-   .mode_set = bochs_crtc_mode_set,
-   .mode_set_base = bochs_crtc_mode_set_base,
.mode_set_nofb = bochs_crtc_mode_set_nofb,
-   .prepare = bochs_crtc_prepare,
-   .commit = bochs_crtc_commit,
.atomic_enable = bochs_crtc_atomic_enable,
.atomic_flush = bochs_crtc_atomic_flush,
 };
-- 
2.9.3

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


[PATCH v3 03/15] drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.

2019-01-10 Thread Gerd Hoffmann
Conversion to atomic modesetting, step one.
Add atomic crtc helper callbacks.

Signed-off-by: Gerd Hoffmann 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index f7e6d1a9b3..2cbd406b1f 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -115,6 +115,29 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc,
return 0;
 }
 
+static void bochs_crtc_atomic_enable(struct drm_crtc *crtc,
+struct drm_crtc_state *old_crtc_state)
+{
+}
+
+static void bochs_crtc_atomic_flush(struct drm_crtc *crtc,
+   struct drm_crtc_state *old_crtc_state)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_pending_vblank_event *event;
+
+   if (crtc->state && crtc->state->event) {
+   unsigned long irqflags;
+
+   spin_lock_irqsave(&dev->event_lock, irqflags);
+   event = crtc->state->event;
+   crtc->state->event = NULL;
+   drm_crtc_send_vblank_event(crtc, event);
+   spin_unlock_irqrestore(&dev->event_lock, irqflags);
+   }
+}
+
+
 /* These provide the minimum set of functions required to handle a CRTC */
 static const struct drm_crtc_funcs bochs_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
@@ -128,6 +151,8 @@ static const struct drm_crtc_helper_funcs 
bochs_helper_funcs = {
.mode_set_base = bochs_crtc_mode_set_base,
.prepare = bochs_crtc_prepare,
.commit = bochs_crtc_commit,
+   .atomic_enable = bochs_crtc_atomic_enable,
+   .atomic_flush = bochs_crtc_atomic_flush,
 };
 
 static const uint32_t bochs_formats[] = {
-- 
2.9.3

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


[PATCH v3 04/15] drm/bochs: atomic: add mode_set_nofb callback.

2019-01-10 Thread Gerd Hoffmann
Conversion to atomic modesetting, step two.
Add mode_set_nofb crtc helper callback.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 2cbd406b1f..56fd7be933 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -86,6 +86,14 @@ static int bochs_crtc_mode_set(struct drm_crtc *crtc,
return 0;
 }
 
+static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc)
+{
+   struct bochs_device *bochs =
+   container_of(crtc, struct bochs_device, crtc);
+
+   bochs_hw_setmode(bochs, &crtc->mode);
+}
+
 static void bochs_crtc_prepare(struct drm_crtc *crtc)
 {
 }
@@ -149,6 +157,7 @@ static const struct drm_crtc_helper_funcs 
bochs_helper_funcs = {
.dpms = bochs_crtc_dpms,
.mode_set = bochs_crtc_mode_set,
.mode_set_base = bochs_crtc_mode_set_base,
+   .mode_set_nofb = bochs_crtc_mode_set_nofb,
.prepare = bochs_crtc_prepare,
.commit = bochs_crtc_commit,
.atomic_enable = bochs_crtc_atomic_enable,
-- 
2.9.3

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


[PATCH v3 10/15] drm/bochs: drop unused gpu_addr arg from bochs_bo_pin()

2019-01-10 Thread Gerd Hoffmann
It's always NULL, so just remove it.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs.h   |  2 +-
 drivers/gpu/drm/bochs/bochs_fbdev.c |  2 +-
 drivers/gpu/drm/bochs/bochs_kms.c   |  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c| 11 +--
 4 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 4dc1b6384e..d0d474e06f 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -142,7 +142,7 @@ int bochs_dumb_create(struct drm_file *file, struct 
drm_device *dev,
 int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
   uint32_t handle, uint64_t *offset);
 
-int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 *gpu_addr);
+int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag);
 int bochs_bo_unpin(struct bochs_bo *bo);
 
 /* bochs_kms.c */
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index d9f3d42999..92feb817ff 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -81,7 +81,7 @@ static int bochsfb_create(struct drm_fb_helper *helper,
if (ret)
return ret;
 
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
+   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
if (ret) {
DRM_ERROR("failed to pin fbcon\n");
ttm_bo_unreserve(&bo->bo);
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 5b7e1a7c6b..f663c54185 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -101,7 +101,7 @@ static int bochs_plane_prepare_fb(struct drm_plane *plane,
ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
if (ret)
return ret;
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
+   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
ttm_bo_unreserve(&bo->bo);
return ret;
 }
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 0980411e41..5a0e092847 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -210,20 +210,13 @@ static void bochs_ttm_placement(struct bochs_bo *bo, int 
domain)
bo->placement.num_busy_placement = c;
 }
 
-static inline u64 bochs_bo_gpu_offset(struct bochs_bo *bo)
-{
-   return bo->bo.offset;
-}
-
-int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 *gpu_addr)
+int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag)
 {
struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (bo->pin_count) {
bo->pin_count++;
-   if (gpu_addr)
-   *gpu_addr = bochs_bo_gpu_offset(bo);
return 0;
}
 
@@ -235,8 +228,6 @@ int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 
*gpu_addr)
return ret;
 
bo->pin_count = 1;
-   if (gpu_addr)
-   *gpu_addr = bochs_bo_gpu_offset(bo);
return 0;
 }
 
-- 
2.9.3

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


[PATCH v3 08/15] drm/bochs: atomic: set DRIVER_ATOMIC

2019-01-10 Thread Gerd Hoffmann
Conversion to atomic modesetting, final step.
Set the DRIVER_ATOMIC flag.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index f3dd66ae99..278f9d2e7f 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -81,7 +81,7 @@ static const struct file_operations bochs_fops = {
 };
 
 static struct drm_driver bochs_driver = {
-   .driver_features= DRIVER_GEM | DRIVER_MODESET,
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops   = &bochs_fops,
.name   = "bochs-drm",
.desc   = "bochs dispi vga interface (qemu stdvga)",
-- 
2.9.3

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


[PATCH v3 12/15] drm/bochs: add basic prime support

2019-01-10 Thread Gerd Hoffmann
Just enough to make the generic framebuffer emulation happy.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs.h |  7 ++
 drivers/gpu/drm/bochs/bochs_drv.c | 11 -
 drivers/gpu/drm/bochs/bochs_mm.c  | 49 +++
 3 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index d0d474e06f..ede22beb85 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -145,6 +145,13 @@ int bochs_dumb_mmap_offset(struct drm_file *file, struct 
drm_device *dev,
 int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag);
 int bochs_bo_unpin(struct bochs_bo *bo);
 
+int bochs_gem_prime_pin(struct drm_gem_object *obj);
+void bochs_gem_prime_unpin(struct drm_gem_object *obj);
+void *bochs_gem_prime_vmap(struct drm_gem_object *obj);
+void bochs_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+int bochs_gem_prime_mmap(struct drm_gem_object *obj,
+struct vm_area_struct *vma);
+
 /* bochs_kms.c */
 int bochs_kms_init(struct bochs_device *bochs);
 void bochs_kms_fini(struct bochs_device *bochs);
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 278f9d2e7f..379111f5a0 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -81,7 +81,8 @@ static const struct file_operations bochs_fops = {
 };
 
 static struct drm_driver bochs_driver = {
-   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
+ DRIVER_PRIME,
.fops   = &bochs_fops,
.name   = "bochs-drm",
.desc   = "bochs dispi vga interface (qemu stdvga)",
@@ -91,6 +92,14 @@ static struct drm_driver bochs_driver = {
.gem_free_object_unlocked = bochs_gem_free_object,
.dumb_create= bochs_dumb_create,
.dumb_map_offset= bochs_dumb_mmap_offset,
+
+   .gem_prime_export = drm_gem_prime_export,
+   .gem_prime_import = drm_gem_prime_import,
+   .gem_prime_pin = bochs_gem_prime_pin,
+   .gem_prime_unpin = bochs_gem_prime_unpin,
+   .gem_prime_vmap = bochs_gem_prime_vmap,
+   .gem_prime_vunmap = bochs_gem_prime_vunmap,
+   .gem_prime_mmap = bochs_gem_prime_mmap,
 };
 
 /* -- */
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index fcbf35456d..641a33f134 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -395,3 +395,52 @@ int bochs_dumb_mmap_offset(struct drm_file *file, struct 
drm_device *dev,
drm_gem_object_put_unlocked(obj);
return 0;
 }
+
+/* -- */
+
+int bochs_gem_prime_pin(struct drm_gem_object *obj)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+
+   return bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
+}
+
+void bochs_gem_prime_unpin(struct drm_gem_object *obj)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+
+   bochs_bo_unpin(bo);
+}
+
+void *bochs_gem_prime_vmap(struct drm_gem_object *obj)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+   bool is_iomem;
+   int ret;
+
+   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
+   if (ret)
+   return NULL;
+   ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
+   if (ret) {
+   bochs_bo_unpin(bo);
+   return NULL;
+   }
+   return ttm_kmap_obj_virtual(&bo->kmap, &is_iomem);
+}
+
+void bochs_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+
+   ttm_bo_kunmap(&bo->kmap);
+   bochs_bo_unpin(bo);
+}
+
+int bochs_gem_prime_mmap(struct drm_gem_object *obj,
+struct vm_area_struct *vma)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+
+   return ttm_fbdev_mmap(vma, &bo->bo);
+}
-- 
2.9.3

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


[PATCH v3 13/15] drm/bochs: switch to generic drm fbdev emulation

2019-01-10 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 379111f5a0..1d86c0fb5f 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -16,10 +16,6 @@ static int bochs_modeset = -1;
 module_param_named(modeset, bochs_modeset, int, 0444);
 MODULE_PARM_DESC(modeset, "enable/disable kernel modesetting");
 
-static bool enable_fbdev = true;
-module_param_named(fbdev, enable_fbdev, bool, 0444);
-MODULE_PARM_DESC(fbdev, "register fbdev device");
-
 /* -- */
 /* drm interface  */
 
@@ -27,7 +23,6 @@ static void bochs_unload(struct drm_device *dev)
 {
struct bochs_device *bochs = dev->dev_private;
 
-   bochs_fbdev_fini(bochs);
bochs_kms_fini(bochs);
bochs_mm_fini(bochs);
bochs_hw_fini(dev);
@@ -58,9 +53,6 @@ static int bochs_load(struct drm_device *dev)
if (ret)
goto err;
 
-   if (enable_fbdev)
-   bochs_fbdev_init(bochs);
-
return 0;
 
 err:
@@ -174,6 +166,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
if (ret)
goto err_unload;
 
+   drm_fbdev_generic_setup(dev, 32);
return ret;
 
 err_unload:
-- 
2.9.3

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


[PATCH v3 14/15] drm/bochs: drop old fbdev emulation code

2019-01-10 Thread Gerd Hoffmann
Not needed any more, bochs uses the generic emulation now.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs.h   |   9 ---
 drivers/gpu/drm/bochs/bochs_drv.c   |   6 --
 drivers/gpu/drm/bochs/bochs_fbdev.c | 129 
 3 files changed, 144 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index ede22beb85..03711394f1 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -80,12 +80,6 @@ struct bochs_device {
struct ttm_bo_device bdev;
bool initialized;
} ttm;
-
-   /* fbdev */
-   struct {
-   struct drm_framebuffer *fb;
-   struct drm_fb_helper helper;
-   } fb;
 };
 
 struct bochs_bo {
@@ -157,7 +151,4 @@ int bochs_kms_init(struct bochs_device *bochs);
 void bochs_kms_fini(struct bochs_device *bochs);
 
 /* bochs_fbdev.c */
-int bochs_fbdev_init(struct bochs_device *bochs);
-void bochs_fbdev_fini(struct bochs_device *bochs);
-
 extern const struct drm_mode_config_funcs bochs_mode_funcs;
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 1d86c0fb5f..a8968cd8d5 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -102,12 +102,9 @@ static int bochs_pm_suspend(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
-   struct bochs_device *bochs = drm_dev->dev_private;
 
drm_kms_helper_poll_disable(drm_dev);
 
-   drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 1);
-
return 0;
 }
 
@@ -115,12 +112,9 @@ static int bochs_pm_resume(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
-   struct bochs_device *bochs = drm_dev->dev_private;
 
drm_helper_resume_force_mode(drm_dev);
 
-   drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 0);
-
drm_kms_helper_poll_enable(drm_dev);
return 0;
 }
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index ccf783b038..7cac3f5253 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -11,124 +11,6 @@
 
 /* -- */
 
-static int bochsfb_mmap(struct fb_info *info,
-   struct vm_area_struct *vma)
-{
-   struct drm_fb_helper *fb_helper = info->par;
-   struct bochs_bo *bo = gem_to_bochs_bo(fb_helper->fb->obj[0]);
-
-   return ttm_fbdev_mmap(vma, &bo->bo);
-}
-
-static struct fb_ops bochsfb_ops = {
-   .owner = THIS_MODULE,
-   DRM_FB_HELPER_DEFAULT_OPS,
-   .fb_fillrect = drm_fb_helper_cfb_fillrect,
-   .fb_copyarea = drm_fb_helper_cfb_copyarea,
-   .fb_imageblit = drm_fb_helper_cfb_imageblit,
-   .fb_mmap = bochsfb_mmap,
-};
-
-static int bochsfb_create_object(struct bochs_device *bochs,
-const struct drm_mode_fb_cmd2 *mode_cmd,
-struct drm_gem_object **gobj_p)
-{
-   struct drm_device *dev = bochs->dev;
-   struct drm_gem_object *gobj;
-   u32 size;
-   int ret = 0;
-
-   size = mode_cmd->pitches[0] * mode_cmd->height;
-   ret = bochs_gem_create(dev, size, true, &gobj);
-   if (ret)
-   return ret;
-
-   *gobj_p = gobj;
-   return ret;
-}
-
-static int bochsfb_create(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
-   struct bochs_device *bochs =
-   container_of(helper, struct bochs_device, fb.helper);
-   struct fb_info *info;
-   struct drm_framebuffer *fb;
-   struct drm_mode_fb_cmd2 mode_cmd;
-   struct drm_gem_object *gobj = NULL;
-   struct bochs_bo *bo = NULL;
-   int size, ret;
-
-   if (sizes->surface_bpp != 32)
-   return -EINVAL;
-
-   mode_cmd.width = sizes->surface_width;
-   mode_cmd.height = sizes->surface_height;
-   mode_cmd.pitches[0] = sizes->surface_width * 4;
-   mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
-   size = mode_cmd.pitches[0] * mode_cmd.height;
-
-   /* alloc, pin & map bo */
-   ret = bochsfb_create_object(bochs, &mode_cmd, &gobj);
-   if (ret) {
-   DRM_ERROR("failed to create fbcon backing object %d\n", ret);
-   return ret;
-   }
-
-   bo = gem_to_bochs_bo(gobj);
-
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
-   if (ret) {
-   DRM_ERROR("failed to pin fbcon\n");
-   return ret;
-   }
-
-   ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages,
- &bo->kmap);
-   if (ret) {
-   DRM_ERROR("failed to kmap fbcon\n");
-   return ret;
-   }

[PATCH v3 02/15] drm/bochs: split bochs_hw_setmode

2019-01-10 Thread Gerd Hoffmann
Create a separate bochs_hw_setformat function to configure
the framebuffer format (actually just the byteorder).

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs.h |  5 +++--
 drivers/gpu/drm/bochs/bochs_hw.c  | 19 ---
 drivers/gpu/drm/bochs/bochs_kms.c |  3 ++-
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index fb38c8b857..4dc1b6384e 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -121,8 +121,9 @@ int bochs_hw_init(struct drm_device *dev);
 void bochs_hw_fini(struct drm_device *dev);
 
 void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode,
- const struct drm_format_info *format);
+ struct drm_display_mode *mode);
+void bochs_hw_setformat(struct bochs_device *bochs,
+   const struct drm_format_info *format);
 void bochs_hw_setbase(struct bochs_device *bochs,
  int x, int y, u64 addr);
 int bochs_hw_load_edid(struct bochs_device *bochs);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index d0b4e1cee8..3e04b2f0ec 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -204,8 +204,7 @@ void bochs_hw_fini(struct drm_device *dev)
 }
 
 void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode,
- const struct drm_format_info *format)
+ struct drm_display_mode *mode)
 {
bochs->xres = mode->hdisplay;
bochs->yres = mode->vdisplay;
@@ -213,12 +212,8 @@ void bochs_hw_setmode(struct bochs_device *bochs,
bochs->stride = mode->hdisplay * (bochs->bpp / 8);
bochs->yres_virtual = bochs->fb_size / bochs->stride;
 
-   DRM_DEBUG_DRIVER("%dx%d @ %d bpp, format %c%c%c%c, vy %d\n",
+   DRM_DEBUG_DRIVER("%dx%d @ %d bpp, vy %d\n",
 bochs->xres, bochs->yres, bochs->bpp,
-(format->format >>  0) & 0xff,
-(format->format >>  8) & 0xff,
-(format->format >> 16) & 0xff,
-(format->format >> 24) & 0xff,
 bochs->yres_virtual);
 
bochs_vga_writeb(bochs, 0x3c0, 0x20); /* unblank */
@@ -236,6 +231,16 @@ void bochs_hw_setmode(struct bochs_device *bochs,
 
bochs_dispi_write(bochs, VBE_DISPI_INDEX_ENABLE,
  VBE_DISPI_ENABLED | VBE_DISPI_LFB_ENABLED);
+}
+
+void bochs_hw_setformat(struct bochs_device *bochs,
+   const struct drm_format_info *format)
+{
+   DRM_DEBUG_DRIVER("format %c%c%c%c\n",
+(format->format >>  0) & 0xff,
+(format->format >>  8) & 0xff,
+(format->format >> 16) & 0xff,
+(format->format >> 24) & 0xff);
 
switch (format->format) {
case DRM_FORMAT_XRGB:
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index c8ce54498d..f7e6d1a9b3 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -80,7 +80,8 @@ static int bochs_crtc_mode_set(struct drm_crtc *crtc,
if (WARN_ON(crtc->primary->fb == NULL))
return -EINVAL;
 
-   bochs_hw_setmode(bochs, mode, crtc->primary->fb->format);
+   bochs_hw_setmode(bochs, mode);
+   bochs_hw_setformat(bochs, crtc->primary->fb->format);
bochs_crtc_mode_set_base(crtc, x, y, old_fb);
return 0;
 }
-- 
2.9.3

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


[PATCH v3 06/15] drm/bochs: atomic: use atomic set_config helper

2019-01-10 Thread Gerd Hoffmann
Conversion to atomic modesetting, step four.
Use atomic set_config helper for crtc.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index c6993c2d59..646f897cb2 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -150,7 +150,7 @@ static void bochs_crtc_atomic_flush(struct drm_crtc *crtc,
 
 /* These provide the minimum set of functions required to handle a CRTC */
 static const struct drm_crtc_funcs bochs_crtc_funcs = {
-   .set_config = drm_crtc_helper_set_config,
+   .set_config = drm_atomic_helper_set_config,
.destroy = drm_crtc_cleanup,
.page_flip = bochs_crtc_page_flip,
.reset = drm_atomic_helper_crtc_reset,
-- 
2.9.3

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


[PATCH v3 00/15] drm/bochs: cleanups, atomic modesetting, generic fbdev.

2019-01-10 Thread Gerd Hoffmann
This series adds support for atomic modesetting to the bochs driver.
It also switches over to the generic fbdev implementation and does
some cleanups.

v3:
 - adjust pin/unpin fix & reorder patches a bit,
   to keep the series bisectable (Daniel).
 - drop dmabuf import/export callbacks.

v2:
 - some updates according to Oleksandr's review.
 - fix ttm bo pin/unpin  (new patch #15).

Gerd Hoffmann (15):
  drm/bochs: encoder cleanup
  drm/bochs: split bochs_hw_setmode
  drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.
  drm/bochs: atomic: add mode_set_nofb callback.
  drm/bochs: atomic: switch planes to atomic, wire up helpers.
  drm/bochs: atomic: use atomic set_config helper
  drm/bochs: atomic: use atomic page_flip helper
  drm/bochs: atomic: set DRIVER_ATOMIC
  drm/bochs: remove old bochs_crtc_* functions
  drm/bochs: drop unused gpu_addr arg from bochs_bo_pin()
  drm/bochs: move ttm_bo_(un)reserve calls into bochs_bo_{pin,unpin}
  drm/bochs: add basic prime support
  drm/bochs: switch to generic drm fbdev emulation
  drm/bochs: drop old fbdev emulation code
  drm/bochs: move remaining fb bits to kms

 drivers/gpu/drm/bochs/bochs.h   |  23 ++--
 drivers/gpu/drm/bochs/bochs_drv.c   |  26 ++---
 drivers/gpu/drm/bochs/bochs_fbdev.c | 163 ---
 drivers/gpu/drm/bochs/bochs_hw.c|  19 ++--
 drivers/gpu/drm/bochs/bochs_kms.c   | 218 +---
 drivers/gpu/drm/bochs/bochs_mm.c|  68 +--
 drivers/gpu/drm/bochs/Makefile  |   2 +-
 7 files changed, 196 insertions(+), 323 deletions(-)
 delete mode 100644 drivers/gpu/drm/bochs/bochs_fbdev.c

-- 
2.9.3

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


[PATCH v3 07/15] drm/bochs: atomic: use atomic page_flip helper

2019-01-10 Thread Gerd Hoffmann
Conversion to atomic modesetting, step five.
Use atomic page_flip helper for crtc.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 646f897cb2..67c3674609 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -104,27 +104,6 @@ static void bochs_crtc_commit(struct drm_crtc *crtc)
 {
 }
 
-static int bochs_crtc_page_flip(struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   struct drm_pending_vblank_event *event,
-   uint32_t page_flip_flags,
-   struct drm_modeset_acquire_ctx *ctx)
-{
-   struct bochs_device *bochs =
-   container_of(crtc, struct bochs_device, crtc);
-   struct drm_framebuffer *old_fb = crtc->primary->fb;
-   unsigned long irqflags;
-
-   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
-   bochs_crtc_mode_set_base(crtc, 0, 0, old_fb);
-   if (event) {
-   spin_lock_irqsave(&bochs->dev->event_lock, irqflags);
-   drm_crtc_send_vblank_event(crtc, event);
-   spin_unlock_irqrestore(&bochs->dev->event_lock, irqflags);
-   }
-   return 0;
-}
-
 static void bochs_crtc_atomic_enable(struct drm_crtc *crtc,
 struct drm_crtc_state *old_crtc_state)
 {
@@ -152,7 +131,7 @@ static void bochs_crtc_atomic_flush(struct drm_crtc *crtc,
 static const struct drm_crtc_funcs bochs_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = drm_crtc_cleanup,
-   .page_flip = bochs_crtc_page_flip,
+   .page_flip = drm_atomic_helper_page_flip,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
-- 
2.9.3

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


[PATCH v3 01/15] drm/bochs: encoder cleanup

2019-01-10 Thread Gerd Hoffmann
Most unused callbacks can be NULL pointers these days.
Drop a bunch of empty encoder callbacks.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 26 --
 1 file changed, 26 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index f87c284dd9..c8ce54498d 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -170,31 +170,6 @@ static void bochs_crtc_init(struct drm_device *dev)
drm_crtc_helper_add(crtc, &bochs_helper_funcs);
 }
 
-static void bochs_encoder_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void bochs_encoder_dpms(struct drm_encoder *encoder, int state)
-{
-}
-
-static void bochs_encoder_prepare(struct drm_encoder *encoder)
-{
-}
-
-static void bochs_encoder_commit(struct drm_encoder *encoder)
-{
-}
-
-static const struct drm_encoder_helper_funcs bochs_encoder_helper_funcs = {
-   .dpms = bochs_encoder_dpms,
-   .mode_set = bochs_encoder_mode_set,
-   .prepare = bochs_encoder_prepare,
-   .commit = bochs_encoder_commit,
-};
-
 static const struct drm_encoder_funcs bochs_encoder_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
@@ -207,7 +182,6 @@ static void bochs_encoder_init(struct drm_device *dev)
encoder->possible_crtcs = 0x1;
drm_encoder_init(dev, encoder, &bochs_encoder_encoder_funcs,
 DRM_MODE_ENCODER_DAC, NULL);
-   drm_encoder_helper_add(encoder, &bochs_encoder_helper_funcs);
 }
 
 
-- 
2.9.3

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


[PATCH v3 11/15] drm/bochs: move ttm_bo_(un)reserve calls into bochs_bo_{pin, unpin}

2019-01-10 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c |  8 
 drivers/gpu/drm/bochs/bochs_kms.c   | 14 +-
 drivers/gpu/drm/bochs/bochs_mm.c|  8 
 3 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 92feb817ff..ccf783b038 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -77,14 +77,9 @@ static int bochsfb_create(struct drm_fb_helper *helper,
 
bo = gem_to_bochs_bo(gobj);
 
-   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
-   if (ret)
-   return ret;
-
ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
if (ret) {
DRM_ERROR("failed to pin fbcon\n");
-   ttm_bo_unreserve(&bo->bo);
return ret;
}
 
@@ -92,12 +87,9 @@ static int bochsfb_create(struct drm_fb_helper *helper,
  &bo->kmap);
if (ret) {
DRM_ERROR("failed to kmap fbcon\n");
-   ttm_bo_unreserve(&bo->bo);
return ret;
}
 
-   ttm_bo_unreserve(&bo->bo);
-
/* init fb device */
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index f663c54185..fc856a02a2 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -92,34 +92,22 @@ static int bochs_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
 {
struct bochs_bo *bo;
-   int ret;
 
if (!new_state->fb)
return 0;
bo = gem_to_bochs_bo(new_state->fb->obj[0]);
-
-   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
-   if (ret)
-   return ret;
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
-   ttm_bo_unreserve(&bo->bo);
-   return ret;
+   return bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
 }
 
 static void bochs_plane_cleanup_fb(struct drm_plane *plane,
   struct drm_plane_state *old_state)
 {
struct bochs_bo *bo;
-   int ret;
 
if (!old_state->fb)
return;
bo = gem_to_bochs_bo(old_state->fb->obj[0]);
-   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
-   if (ret)
-   return;
bochs_bo_unpin(bo);
-   ttm_bo_unreserve(&bo->bo);
 }
 
 static const struct drm_plane_helper_funcs bochs_plane_helper_funcs = {
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 5a0e092847..fcbf35456d 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -223,7 +223,11 @@ int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag)
bochs_ttm_placement(bo, pl_flag);
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
+   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
+   if (ret)
+   return ret;
ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx);
+   ttm_bo_unreserve(&bo->bo);
if (ret)
return ret;
 
@@ -247,7 +251,11 @@ int bochs_bo_unpin(struct bochs_bo *bo)
 
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
+   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
+   if (ret)
+   return ret;
ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx);
+   ttm_bo_unreserve(&bo->bo);
if (ret)
return ret;
 
-- 
2.9.3

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


[PATCH 10/10] drm/mxsfb: Clear OUTSTANDING_REQS bits

2019-01-10 Thread Robert Chiras
Bit 21 can alter the CTRL2_OUTSTANDING_REQS value right after the eLCDIF
is enabled, since it comes up with default value of 1 (this behaviour
has been seen on some imx8 platforms).
In order to fix this, clear CTRL2_OUTSTANDING_REQS bits before setting
its value.

Signed-off-by: Robert Chiras 
---
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index b9437c7..c5689c2 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -231,6 +231,13 @@ static void mxsfb_enable_controller(struct 
mxsfb_drm_private *mxsfb)
clk_prepare_enable(mxsfb->clk);
 
if (mxsfb->devdata->ipversion >= 4) {
+   /*
+* On some platforms, bit 21 is defaulted to 1, which may alter
+* the below setting. So, to make sure we have the right setting
+* clear all the bits for CTRL2_OUTSTANDING_REQS.
+*/
+   writel(CTRL2_OUTSTANDING_REQS(0x7),
+   mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
writel(CTRL2_OUTSTANDING_REQS(REQ_16),
mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
/* Assert LCD Reset bit */
-- 
2.7.4

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


[PATCH v8 02/11] gpu: ipu-csi: Swap fields according to input/output field types

2019-01-10 Thread Steve Longerbeam
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.

Instead, base field swap on the field order of the input to the CSI,
and the field order of the requested output. If the input/output
fields are sequential but different, swap fields, otherwise do
not swap. This requires passing both the input and output mbus
frame formats to ipu_csi_init_interface().

Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
possibly interlaced BT.1120 in the future).

When detecting input video standard from the input frame width/height,
make sure to double height if input field type is alternate, since
in that case input height only includes lines for one field.

Signed-off-by: Steve Longerbeam 
Reviewed-by: Philipp Zabel 
Acked-by: Philipp Zabel 
---
Changes since v5:
- Convert to const the infmt, outfmt, and mbus_cfg pointer args to
  ipu_csi_init_interface(), suggested by Philipp Zabel.
- Bring back if_fmt local var and don't copy outfmt to local stack in
  csi_setup(), suggested by Philipp.

Changes since v4:
- Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
  by Philipp.
- Fixed a regression in csi_setup(), caught by Philipp.
---
 drivers/gpu/ipu-v3/ipu-csi.c  | 126 +++---
 drivers/staging/media/imx/imx-media-csi.c |   7 +-
 include/video/imx-ipu-v3.h|   5 +-
 3 files changed, 89 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index aa0e30a2ba18..d1e575571a8d 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -325,12 +325,21 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config 
*cfg, u32 mbus_code,
return 0;
 }
 
+/* translate alternate field mode based on given standard */
+static inline enum v4l2_field
+ipu_csi_translate_field(enum v4l2_field field, v4l2_std_id std)
+{
+   return (field != V4L2_FIELD_ALTERNATE) ? field :
+   ((std & V4L2_STD_525_60) ?
+V4L2_FIELD_SEQ_BT : V4L2_FIELD_SEQ_TB);
+}
+
 /*
  * Fill a CSI bus config struct from mbus_config and mbus_framefmt.
  */
 static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
-struct v4l2_mbus_config *mbus_cfg,
-struct v4l2_mbus_framefmt *mbus_fmt)
+   const struct v4l2_mbus_config *mbus_cfg,
+   const struct v4l2_mbus_framefmt *mbus_fmt)
 {
int ret;
 
@@ -374,22 +383,76 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config 
*csicfg,
return 0;
 }
 
+static int
+ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
+   const struct v4l2_mbus_framefmt *infmt,
+   const struct v4l2_mbus_framefmt *outfmt,
+   v4l2_std_id std)
+{
+   enum v4l2_field infield, outfield;
+   bool swap_fields;
+
+   /* get translated field type of input and output */
+   infield = ipu_csi_translate_field(infmt->field, std);
+   outfield = ipu_csi_translate_field(outfmt->field, std);
+
+   /*
+* Write the H-V-F codes the CSI will match against the
+* incoming data for start/end of active and blanking
+* field intervals. If input and output field types are
+* sequential but not the same (one is SEQ_BT and the other
+* is SEQ_TB), swap the F-bit so that the CSI will capture
+* field 1 lines before field 0 lines.
+*/
+   swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
+  V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
+  infield != outfield);
+
+   if (!swap_fields) {
+   /*
+* Field0BlankEnd  = 110, Field0BlankStart  = 010
+* Field0ActiveEnd = 100, Field0ActiveStart = 000
+* Field1BlankEnd  = 111, Field1BlankStart  = 011
+* Field1ActiveEnd = 101, Field1ActiveStart = 001
+*/
+   ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+   ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+   } else {
+   dev_dbg(csi->ipu->dev, "capture field swap\n");
+
+   /* same as above but with F-bit inverted */
+   ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+   ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+   }
+
+   ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
+
+   return 0;
+}
+
+
 int ipu_csi_init_interface(struct ipu_csi *csi,
-  struct v4l2_mbus_config *mbus_cfg,
-  struct v4l2_mbus_framefm

[PATCH 00/10] Add support for DRM bridge and additional pixel formats

2019-01-10 Thread Robert Chiras
This patchset improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
and 8QXP):

1. Add support for drm_bridge
On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
display connector, where an LCD panel can be attached, but instead it is
connected to DSI controller. Since this DSI stands between the display
controller (eLCDIF) and the physical connector, the DSI can be implemented
as a DRM bridge. So, in order to be able to connect the mxsfb driver to
the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
driver (the actual driver for the eLCDIF block).

2. Add support for additional pixel formats
Some of the pixel formats needed by Android were not implemented in this
driver, but they were actually supported. So, add support for them.

3. Few minor features and bug-fixing
The addition of max-res DT property was actually needed in order to limit
the bandwidth usage of the eLCDIF block. This is need on systems where
multiple display controllers are presend and the memory bandwidth is not
enough to handle all of them at maximum capacity (like it is the case on
8MQ, where there are two display controllers: DCSS and eLCDIF).
The rest of the patches are bug-fixes.


Mirela Rabulea (2):
  drm/mxsfb: Add support for new pixel formats in eLCDIF
  drm/mxsfb: Signal mode changed when bpp changed

Robert Chiras (8):
  drm/mxsfb: Update mxsfb to support a bridge
  dt-bindings: display: Add max-res property for mxsfb
  drm/mxsfb: Add max-res property for MXSFB
  drm/mxsfb: Update mxsfb with additional pixel formats
  drm/mxsfb: Fix the vblank events
  drm/mxsfb: Update mxsfb to support LCD reset
  drm/mxsfb: Improve the axi clock usage
  drm/mxsfb: Clear OUTSTANDING_REQS bits

 .../devicetree/bindings/display/mxsfb.txt  |   6 +
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 215 ++---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 187 ++
 drivers/gpu/drm/mxsfb/mxsfb_drv.h  |  11 +-
 drivers/gpu/drm/mxsfb/mxsfb_out.c  |  26 +--
 drivers/gpu/drm/mxsfb/mxsfb_regs.h | 112 +++
 6 files changed, 433 insertions(+), 124 deletions(-)

-- 
2.7.4

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


[PATCH 01/10] drm/mxsfb: Update mxsfb to support a bridge

2019-01-10 Thread Robert Chiras
Currently, the MXSFB DRM driver only supports a panel. But, its output
display signal can also be redirected to another encoder, like a DSI
controller. In this case, that DSI controller may act like a drm_bridge.
In order support this use-case too, this patch adds support for
drm_bridge in mxsfb.

Signed-off-by: Robert Chiras 
---
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 44 +---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 46 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.h  |  4 +++-
 drivers/gpu/drm/mxsfb/mxsfb_out.c  | 26 +++--
 drivers/gpu/drm/mxsfb/mxsfb_regs.h | 15 +
 5 files changed, 114 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 24b1f0c..f0648ce 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -101,8 +101,11 @@ static void mxsfb_set_bus_fmt(struct mxsfb_drm_private 
*mxsfb)
 
reg = readl(mxsfb->base + LCDC_CTRL);
 
-   if (mxsfb->connector.display_info.num_bus_formats)
-   bus_format = mxsfb->connector.display_info.bus_formats[0];
+   if (mxsfb->connector->display_info.num_bus_formats)
+   bus_format = mxsfb->connector->display_info.bus_formats[0];
+
+   DRM_DEV_DEBUG_DRIVER(drm->dev,
+   "Using bus_format: 0x%08X\n", bus_format);
 
reg &= ~CTRL_BUS_WIDTH_MASK;
switch (bus_format) {
@@ -130,6 +133,9 @@ static void mxsfb_enable_controller(struct 
mxsfb_drm_private *mxsfb)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
 
+   writel(CTRL2_OUTSTANDING_REQS__REQ_16,
+   mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
 
@@ -139,12 +145,15 @@ static void mxsfb_enable_controller(struct 
mxsfb_drm_private *mxsfb)
writel(reg, mxsfb->base + LCDC_VDCTRL4);
 
writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_SET);
+   writel(CTRL1_RECOVERY_ON_UNDERFLOW, mxsfb->base + LCDC_CTRL1 + REG_SET);
 }
 
 static void mxsfb_disable_controller(struct mxsfb_drm_private *mxsfb)
 {
u32 reg;
 
+   writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_CLR);
+
/*
 * Even if we disable the controller here, it will still continue
 * until its FIFOs are running out of data
@@ -210,8 +219,9 @@ static dma_addr_t mxsfb_get_fb_paddr(struct 
mxsfb_drm_private *mxsfb)
 
 static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
 {
+   struct drm_device *drm = mxsfb->pipe.crtc.dev;
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
-   const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
+   const u32 bus_flags = mxsfb->connector->display_info.bus_flags;
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
int err;
 
@@ -235,6 +245,11 @@ static void mxsfb_crtc_mode_set_nofb(struct 
mxsfb_drm_private *mxsfb)
 
clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
 
+   DRM_DEV_DEBUG_DRIVER(drm->dev,
+   "Connector bus_flags: 0x%08X\n", bus_flags);
+   DRM_DEV_DEBUG_DRIVER(drm->dev,
+   "Mode flags: 0x%08X\n", m->flags);
+
writel(TRANSFER_COUNT_SET_VCOUNT(m->crtc_vdisplay) |
   TRANSFER_COUNT_SET_HCOUNT(m->crtc_hdisplay),
   mxsfb->base + mxsfb->devdata->transfer_count);
@@ -287,6 +302,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
dma_addr_t paddr;
 
mxsfb_enable_axi_clk(mxsfb);
+   writel(0, mxsfb->base + LCDC_CTRL);
mxsfb_crtc_mode_set_nofb(mxsfb);
 
/* Write cur_buf as well to avoid an initial corrupt frame */
@@ -310,6 +326,8 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private 
*mxsfb,
 {
struct drm_simple_display_pipe *pipe = &mxsfb->pipe;
struct drm_crtc *crtc = &pipe->crtc;
+   struct drm_framebuffer *fb = pipe->plane.state->fb;
+   struct drm_framebuffer *old_fb = old_state->fb;
struct drm_pending_vblank_event *event;
dma_addr_t paddr;
 
@@ -332,4 +350,24 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private 
*mxsfb,
writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
mxsfb_disable_axi_clk(mxsfb);
}
+
+   if (!fb || !old_fb)
+   return;
+
+   /*
+* TODO: Currently, we only support pixel format change, but we need
+* also to care about size changes too
+*/
+   if (old_fb->format->format != fb->format->format) {
+   struct drm_format_name_buf old_fmt_buf;
+   struct drm_format_name_buf new_fmt_buf;
+
+   DRM_DEV_DEBUG_DRIVER(crtc->dev->dev,
+   "Switching pixel format: %s -> %s\n",
+   drm_get_format_name(old_fb->format->form

Re: [PATCH] drm/atmel-hlcdc: prevent divide by zero

2019-01-10 Thread Peter Rosin
On 2019-01-09 11:12, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 12:31:36PM +, Peter Rosin wrote:
>> While trying to temporarily hide a plane, one thing that was attempted
>> was to call (from libdrm)
>>
>>  drmModeSetPlane(fd, plane_id, crtc_id, fb_id, 0,
>>  0, 0, 0, 0, 0, 0, 0, 0);
>>
>> This call causes a pair of "Division by zero in kernel." messages. Kill
>> those messages, but preserve the current behaviour that also happen to
>> make the plane disappear with the above call.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 14 ++
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> Side note, when comparing with drm_atomic_helper_check_plane_state(), I get
>> the feeling that the src rect should be clipped together with the crtc rect
>> if/when clipping is needed. That function calls drm_rect_clip_scaled(), and
>> the equivalent does not seem to happen here. Should clipping be performed
>> on the src rect?
> 
> Any reasons atmel can't switch over to that helper? Would compute a nice
> ->visible state variable for you ...
> -Daniel

I have not researched that, and as stated above, I was not sure if that was the
correct approach to begin with. Boris, any insights? Does this code predate the
helper or something?

Maybe there's some register bit that hides a plane explicitly, matching the
->visible state variable? I haven't looked at that either...

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


[PATCH v10 2/2] drm/fourcc: add a 10bits fully packed variant of NV12

2019-01-10 Thread Randy Li
This pixel format is a fully packed and 10bits variant of NV12.
A luma pixel would take 10bits in memory, without any
filled bits between pixels in a stride.

Signed-off-by: Randy Li 
---
 drivers/gpu/drm/drm_fourcc.c  | 4 
 include/uapi/drm/drm_fourcc.h | 8 
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index ba7e19d4336c..16d3be8278f1 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -247,6 +247,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2,
  .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, 
.block_h = { 1, 0, 0 },
  .hsub = 2, .vsub = 2, .is_yuv = true},
+   { .format = DRM_FORMAT_NV12_10LE40, .depth = 0,  
.num_planes = 2,
+ .char_per_block = { 5, 5, 0 }, .block_w = { 4, 2, 0 }, 
.block_h = { 1, 1, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
+   },
};
 
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8dd1328bc8d6..4985fb19b4ce 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -194,6 +194,14 @@ extern "C" {
 #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1 
subsampled Cb:Cr plane */
 #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /* 
non-subsampled Cr:Cb plane */
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */
+/*
+ * A fully packed  2 plane YCbCr
+ * Y1 0-9, Y2 10-19, Y3 20-29, Y4 20-39
+ * 
+ * U1V1: 0-19, U2V2: 20-39
+ */
+#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2 
subsampled Cr:Cb plane */
+
 
 /*
  * 2 plane YCbCr MSB aligned
-- 
2.20.1

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


Re: [PATCH v4 2/3] drm/msm/dpu: Integrate interconnect API in MDSS

2019-01-10 Thread Georgi Djakov
Hi,

On 9.01.19 18:04, Doug Anderson wrote:
> Hi,
> 
> On Wed, Jan 9, 2019 at 6:38 AM Georgi Djakov  wrote:
>>
>> Hi Jayant,
>>
>> On 12/21/18 08:20, Jayant Shekhar wrote:
>>> From: Sravanthi Kollukuduru 
>>>
>>> The interconnect framework is designed to provide a
>>> standard kernel interface to control the settings of
>>> the interconnects on a SoC.
>>>
>>> The interconnect API uses a consumer/provider-based model,
>>> where the providers are the interconnect buses and the
>>> consumers could be various drivers.
>>>
>>> MDSS is one of the interconnect consumers which uses the
>>> interconnect APIs to get the path between endpoints and
>>> set its bandwidth/latency/QoS requirements for the given
>>
>> Currently we set only bandwidth.
>>
>>> interconnected path.
>>>
>>> Changes in v2:
>>>   - Remove error log and unnecessary check (Jordan Crouse)
>>>
>>> Changes in v3:
>>>   - Code clean involving variable name change, removal
>>> of extra paranthesis and variables (Matthias Kaehlcke)
>>>
>>> Changes in v4:
>>>   - Add comments, spacings, tabs, proper port name
>>> and icc macro (Georgi Djakov)
>>
>> The changes should not be part of the commit text, but should move below
>> the "---" line.
> 
> Drive-by comment that (I believe) they actually should be part of the
> commit text.  Convention for changes in the "drm" subsystem appears to
> be to include the revision log in the commit text.  This is unlike the
> rest of the kernel, but *shrug*.

Indeed! Thanks for the info! Then it's fine.

BR,
Georgi

> 
> Try, for instance:
> 
> git log --no-merges v4.19..v5.0-rc1 drivers/gpu/drm/msm | grep 'v[0-9]'
> 
> -Doug
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

2019-01-10 Thread Ard Biesheuvel
ARM systems do not permit the use of anything other than cached
mappings for system memory, since that memory may be mapped in the
linear region as well, and the architecture does not permit aliases
with mismatched attributes.

So short-circuit the evaluation in ttm_io_prot() if the flags include
TTM_PL_SYSTEM when running on ARM or arm64, and just return cached
attributes immediately.

This fixes the radeon and amdgpu [TBC] drivers when running on arm64.
Without this change, amdgpu does not start at all, and radeon only
produces corrupt display output.

Cc: Christian Koenig 
Cc: Huang Rui 
Cc: Junwei Zhang 
Cc: David Airlie 
Reported-by: Carsten Haitzler 
Signed-off-by: Ard Biesheuvel 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 046a6dda690a..0c1eef5f7ae3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
if (caching_flags & TTM_PL_FLAG_CACHED)
return tmp;
 
+#if defined(__arm__) || defined(__aarch64__)
+   /* ARM only permits cached mappings of system memory */
+   if (caching_flags & TTM_PL_SYSTEM)
+   return tmp;
+#endif
 #if defined(__i386__) || defined(__x86_64__)
if (caching_flags & TTM_PL_FLAG_WC)
tmp = pgprot_writecombine(tmp);
-- 
2.17.1

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


Re: [PATCH] drm/meson: Fix atomic mode switching regression

2019-01-10 Thread Martin Blumenstingl
Hi Neil,

On Wed, Jan 9, 2019 at 2:36 PM Neil Armstrong  wrote:
>
> Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
> example) the display gets blurry, looking like an invalid framebuffer width.
>
> This commit fixed atomic crtc modesetting but didn't update the display
> parameters when changing mode, but only when starting a mode setting after
> a crtc disable.
>
> This commit setups the crctc parameter in _begin() and _enable() to
> take in account the current ctrc parameters.
>
> Reported-by: Tony McKahan 
> Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/meson/meson_crtc.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
> b/drivers/gpu/drm/meson/meson_crtc.c
> index 75d97f1b2e8f..5bb432021caf 100644
> --- a/drivers/gpu/drm/meson/meson_crtc.c
> +++ b/drivers/gpu/drm/meson/meson_crtc.c
> @@ -82,14 +82,12 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
>
>  };
>
> -static void meson_crtc_enable(struct drm_crtc *crtc)
> +static void meson_crtc_setup(struct drm_crtc *crtc)
>  {
> struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
> struct drm_crtc_state *crtc_state = crtc->state;
> struct meson_drm *priv = meson_crtc->priv;
>
> -   DRM_DEBUG_DRIVER("\n");
> -
> if (!crtc_state) {
> DRM_ERROR("Invalid crtc_state\n");
> return;
> @@ -98,6 +96,16 @@ static void meson_crtc_enable(struct drm_crtc *crtc)
> /* Enable VPP Postblend */
nit-pick: this "enable" comment is now in meson_crtc_setup().
I would drop it because my interpretation of the following lines is
now "setting VPP_POSTBLEND_H_SIZE enables the VPP postblend"

> writel(crtc_state->mode.hdisplay,
>priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
> +}
> +
> +static void meson_crtc_enable(struct drm_crtc *crtc)
> +{
> +   struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
> +   struct meson_drm *priv = meson_crtc->priv;
> +
> +   DRM_DEBUG_DRIVER("\n");
> +
> +   meson_crtc_setup(crtc);
>
> /* VD1 Preblend vertical start/end */
> writel(FIELD_PREP(GENMASK(11, 0), 2303),
> @@ -121,6 +129,8 @@ static void meson_crtc_atomic_enable(struct drm_crtc 
> *crtc,
>
> if (!meson_crtc->enabled)
> meson_crtc_enable(crtc);
> +   else
> +   meson_crtc_setup(crtc);
it's probably only personal preference, but have you thought about
re-ordering this:
  meson_crtc_setup(crtc);

  if (!meson_crtc->enabled)
meson_crtc_enable(crtc);

with that you could get rid of the meson_crtc_setup() call in
meson_crtc_enable(), leaving only one code-path (instead of two) which
calls meson_crtc_setup()


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


[PATCH v7 02/11] gpu: ipu-csi: Swap fields according to input/output field types

2019-01-10 Thread Steve Longerbeam
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI would swap fields and
capture in top-bottom order.

Instead, base field swap on the field order of the input to the CSI,
and the field order of the requested output. If the input/output
fields are sequential but different, swap fields, otherwise do
not swap. This requires passing both the input and output mbus
frame formats to ipu_csi_init_interface().

Move this code to a new private function ipu_csi_set_bt_interlaced_codes()
that programs the CCIR_CODE_1/2 registers for interlaced BT.656 (and
possibly interlaced BT.1120 in the future).

When detecting input video standard from the input frame width/height,
make sure to double height if input field type is alternate, since
in that case input height only includes lines for one field.

Signed-off-by: Steve Longerbeam 
Reviewed-by: Philipp Zabel 
---
Changes since v5:
- Convert to const the infmt, outfmt, and mbus_cfg pointer args to
  ipu_csi_init_interface(), suggested by Philipp Zabel.
- Bring back if_fmt local var and don't copy outfmt to local stack in
  csi_setup(), suggested by Philipp.

Changes since v4:
- Cleaned up some convoluted code in ipu_csi_init_interface(), suggested
  by Philipp.
- Fixed a regression in csi_setup(), caught by Philipp.
---
 drivers/gpu/ipu-v3/ipu-csi.c  | 126 +++---
 drivers/staging/media/imx/imx-media-csi.c |   7 +-
 include/video/imx-ipu-v3.h|   5 +-
 3 files changed, 89 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index aa0e30a2ba18..d1e575571a8d 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -325,12 +325,21 @@ static int mbus_code_to_bus_cfg(struct ipu_csi_bus_config 
*cfg, u32 mbus_code,
return 0;
 }
 
+/* translate alternate field mode based on given standard */
+static inline enum v4l2_field
+ipu_csi_translate_field(enum v4l2_field field, v4l2_std_id std)
+{
+   return (field != V4L2_FIELD_ALTERNATE) ? field :
+   ((std & V4L2_STD_525_60) ?
+V4L2_FIELD_SEQ_BT : V4L2_FIELD_SEQ_TB);
+}
+
 /*
  * Fill a CSI bus config struct from mbus_config and mbus_framefmt.
  */
 static int fill_csi_bus_cfg(struct ipu_csi_bus_config *csicfg,
-struct v4l2_mbus_config *mbus_cfg,
-struct v4l2_mbus_framefmt *mbus_fmt)
+   const struct v4l2_mbus_config *mbus_cfg,
+   const struct v4l2_mbus_framefmt *mbus_fmt)
 {
int ret;
 
@@ -374,22 +383,76 @@ static int fill_csi_bus_cfg(struct ipu_csi_bus_config 
*csicfg,
return 0;
 }
 
+static int
+ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
+   const struct v4l2_mbus_framefmt *infmt,
+   const struct v4l2_mbus_framefmt *outfmt,
+   v4l2_std_id std)
+{
+   enum v4l2_field infield, outfield;
+   bool swap_fields;
+
+   /* get translated field type of input and output */
+   infield = ipu_csi_translate_field(infmt->field, std);
+   outfield = ipu_csi_translate_field(outfmt->field, std);
+
+   /*
+* Write the H-V-F codes the CSI will match against the
+* incoming data for start/end of active and blanking
+* field intervals. If input and output field types are
+* sequential but not the same (one is SEQ_BT and the other
+* is SEQ_TB), swap the F-bit so that the CSI will capture
+* field 1 lines before field 0 lines.
+*/
+   swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
+  V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
+  infield != outfield);
+
+   if (!swap_fields) {
+   /*
+* Field0BlankEnd  = 110, Field0BlankStart  = 010
+* Field0ActiveEnd = 100, Field0ActiveStart = 000
+* Field1BlankEnd  = 111, Field1BlankStart  = 011
+* Field1ActiveEnd = 101, Field1ActiveStart = 001
+*/
+   ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+   ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
+   } else {
+   dev_dbg(csi->ipu->dev, "capture field swap\n");
+
+   /* same as above but with F-bit inverted */
+   ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
+ CSI_CCIR_CODE_1);
+   ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
+   }
+
+   ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
+
+   return 0;
+}
+
+
 int ipu_csi_init_interface(struct ipu_csi *csi,
-  struct v4l2_mbus_config *mbus_cfg,
-  struct v4l2_mbus_framefmt *mbus_fmt)
+   

[PATCH 09/10] drm/mxsfb: Improve the axi clock usage

2019-01-10 Thread Robert Chiras
Currently, the enable of the axi clock return status is ignored, causing
issues when the enable fails then we try to disable it. Therefore, it is
better to check the return status and disable it only when enable
succeeded.
Also, remove the helper functions around clk_axi, since we can directly
use the clk API function for enable/disable the clock. Those functions
are already checking for NULL clk and returning 0 if that's the case.

Signed-off-by: Robert Chiras 
Acked-by: Leonard Crestez 
---
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c |  8 
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 32 +---
 drivers/gpu/drm/mxsfb/mxsfb_drv.h  |  3 ---
 3 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 8d1b6a6..b9437c7 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -411,7 +411,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
 {
dma_addr_t paddr;
 
-   mxsfb_enable_axi_clk(mxsfb);
+   clk_prepare_enable(mxsfb->clk_axi);
writel(0, mxsfb->base + LCDC_CTRL);
mxsfb_crtc_mode_set_nofb(mxsfb);
 
@@ -428,7 +428,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
 void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
 {
mxsfb_disable_controller(mxsfb);
-   mxsfb_disable_axi_clk(mxsfb);
+   clk_disable_unprepare(mxsfb->clk_axi);
 }
 
 void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
@@ -456,9 +456,9 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private 
*mxsfb,
 
paddr = mxsfb_get_fb_paddr(mxsfb);
if (paddr) {
-   mxsfb_enable_axi_clk(mxsfb);
+   clk_prepare_enable(mxsfb->clk_axi);
writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
-   mxsfb_disable_axi_clk(mxsfb);
+   clk_disable_unprepare(mxsfb->clk_axi);
}
 
if (!fb || !old_fb)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 135b8e1..5e18353 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -103,18 +103,6 @@ drm_pipe_to_mxsfb_drm_private(struct 
drm_simple_display_pipe *pipe)
return container_of(pipe, struct mxsfb_drm_private, pipe);
 }
 
-void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
-{
-   if (mxsfb->clk_axi)
-   clk_prepare_enable(mxsfb->clk_axi);
-}
-
-void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
-{
-   if (mxsfb->clk_axi)
-   clk_disable_unprepare(mxsfb->clk_axi);
-}
-
 /**
  * mxsfb_atomic_helper_check - validate state object
  * @dev: DRM device
@@ -237,25 +225,31 @@ static void mxsfb_pipe_update(struct 
drm_simple_display_pipe *pipe,
 static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe *pipe)
 {
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+   int ret = 0;
+
+   ret = clk_prepare_enable(mxsfb->clk_axi);
+   if (ret)
+   return ret;
 
/* Clear and enable VBLANK IRQ */
-   mxsfb_enable_axi_clk(mxsfb);
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_SET);
-   mxsfb_disable_axi_clk(mxsfb);
+   clk_disable_unprepare(mxsfb->clk_axi);
 
-   return 0;
+   return ret;
 }
 
 static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe *pipe)
 {
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
 
+   if (clk_prepare_enable(mxsfb->clk_axi))
+   return;
+
/* Disable and clear VBLANK IRQ */
-   mxsfb_enable_axi_clk(mxsfb);
writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
-   mxsfb_disable_axi_clk(mxsfb);
+   clk_disable_unprepare(mxsfb->clk_axi);
 }
 
 static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
@@ -440,7 +434,7 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
struct mxsfb_drm_private *mxsfb = drm->dev_private;
u32 reg;
 
-   mxsfb_enable_axi_clk(mxsfb);
+   clk_prepare_enable(mxsfb->clk_axi);
 
reg = readl(mxsfb->base + LCDC_CTRL1);
 
@@ -449,7 +443,7 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
 
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
 
-   mxsfb_disable_axi_clk(mxsfb);
+   clk_disable_unprepare(mxsfb->clk_axi);
 
return IRQ_HANDLED;
 }
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index c15b4f9..ce98411 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -47,9 +47,6 @@ struct mxsfb_drm_private {
 int mxsfb_setup_crtc(struct drm_device *dev);
 int mxsfb_create_output(struct drm_device *dev);
 
-void mxsfb

[PATCH v10 0/2] Add pixel format for 10 bits YUV video

2019-01-10 Thread Randy Li
As the requirement from:
P010 fourcc format support - Was: Re: Kernel error "Unknown pixelformat
0x" occurs when I start capture video

I don't know which device would support the P010, P012, P016 video pixel
format, but Rockchip would support that NV12_10LE40 and a patch for that
driver is sent before.

Randy Li (2):
  drm/fourcc: Add new P010, P016 video format
  drm/fourcc: add a 10bits fully packed variant of NV12

 drivers/gpu/drm/drm_fourcc.c  | 13 +
 include/uapi/drm/drm_fourcc.h | 29 +
 2 files changed, 42 insertions(+)

-- 
2.20.1

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


[PATCH 05/10] drm/mxsfb: Fix the vblank events

2019-01-10 Thread Robert Chiras
Currently, the vblank support is not correctly implemented in MXSFB_DRM
driver. The call to drm_vblank_init is made with mode_config.num_crtc
which at that time is 0. Because of this, vblank is not activated, so
there won't be any vblank event submitted.

Signed-off-by: Robert Chiras 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 76230d7..aa35c43 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -43,6 +43,9 @@
 #include "mxsfb_drv.h"
 #include "mxsfb_regs.h"
 
+/* The eLCDIF max possible CRTCs */
+#define MAX_CRTCS 1
+
 enum mxsfb_devtype {
MXSFB_V3,
MXSFB_V4,
@@ -140,6 +143,8 @@ static void mxsfb_pipe_enable(struct 
drm_simple_display_pipe *pipe,
mxsfb->connector = &mxsfb->panel_connector;
}
 
+   drm_crtc_vblank_on(&mxsfb->pipe.crtc);
+
pm_runtime_get_sync(drm->dev);
drm_panel_prepare(mxsfb->panel);
mxsfb_crtc_enable(mxsfb);
@@ -249,7 +254,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
 
pm_runtime_enable(drm->dev);
 
-   ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
+   ret = drm_vblank_init(drm, MAX_CRTCS);
if (ret < 0) {
dev_err(drm->dev, "Failed to initialise vblank\n");
goto err_vblank;
@@ -272,6 +277,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
goto err_vblank;
}
 
+   drm_crtc_vblank_off(&mxsfb->pipe.crtc);
+
/*
 * Attach panel only if there is one.
 * If there is no panel attach, it must be a bridge. In this case, we
-- 
2.7.4

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


[PATCH 02/10] dt-bindings: display: Add max-res property for mxsfb

2019-01-10 Thread Robert Chiras
Add new optional property 'max-res', to limit the maximum supported
resolution by the MXSFB_DRM driver.

Signed-off-by: Robert Chiras 
---
 Documentation/devicetree/bindings/display/mxsfb.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt 
b/Documentation/devicetree/bindings/display/mxsfb.txt
index 472e1ea..55e22ed 100644
--- a/Documentation/devicetree/bindings/display/mxsfb.txt
+++ b/Documentation/devicetree/bindings/display/mxsfb.txt
@@ -17,6 +17,12 @@ Required properties:
 Required sub-nodes:
   - port: The connection to an encoder chip.
 
+Optional properties:
+- max-res: an array with a maximum of two integers, representing the
+   maximum supported resolution, in the form of
+   , ; if one of the item is <0>, the default
+   driver-defined maximum resolution for that axis is used
+
 Example:
 
lcdif1: display-controller@222 {
-- 
2.7.4

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


Re: [PATCH v4 2/3] drm/msm/dpu: Integrate interconnect API in MDSS

2019-01-10 Thread Georgi Djakov
Hi Jayant,

On 12/21/18 08:20, Jayant Shekhar wrote:
> From: Sravanthi Kollukuduru 
> 
> The interconnect framework is designed to provide a
> standard kernel interface to control the settings of
> the interconnects on a SoC.
> 
> The interconnect API uses a consumer/provider-based model,
> where the providers are the interconnect buses and the
> consumers could be various drivers.
> 
> MDSS is one of the interconnect consumers which uses the
> interconnect APIs to get the path between endpoints and
> set its bandwidth/latency/QoS requirements for the given

Currently we set only bandwidth.

> interconnected path.
> 
> Changes in v2:
>   - Remove error log and unnecessary check (Jordan Crouse)
> 
> Changes in v3:
>   - Code clean involving variable name change, removal
> of extra paranthesis and variables (Matthias Kaehlcke)
> 
> Changes in v4:
>   - Add comments, spacings, tabs, proper port name
> and icc macro (Georgi Djakov)

The changes should not be part of the commit text, but should move below
the "---" line.

> 
> Signed-off-by: Sravanthi Kollukuduru 
> Signed-off-by: Jayant Shekhar 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 49 
> +---
>  1 file changed, 45 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> index 38576f8..fcaa71f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> @@ -4,11 +4,15 @@
>   */
>  
>  #include "dpu_kms.h"
> +#include 
>  
>  #define to_dpu_mdss(x) container_of(x, struct dpu_mdss, base)
>  
>  #define HW_INTR_STATUS   0x0010
>  
> +/* Max BW defined in KBps */
> +#define MAX_BW   680
> +
>  struct dpu_mdss {
>   struct msm_mdss base;
>   void __iomem *mmio;
> @@ -16,8 +20,30 @@ struct dpu_mdss {
>   u32 hwversion;
>   struct dss_module_power mp;
>   struct dpu_irq_controller irq_controller;
> + struct icc_path *path[2];
> + u32 num_paths;
>  };
>  
> +static int dpu_mdss_parse_data_bus_icc_path(struct drm_device *dev,
> + struct dpu_mdss *dpu_mdss)

Nit: Please align to the open parenthesis.

Otherwise looks good to me.

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


[PATCH 03/10] drm/mxsfb: Add max-res property for MXSFB

2019-01-10 Thread Robert Chiras
Because of stability issues, we may want to limit the maximum resolution
supported by the MXSFB (eLCDIF) driver.
This patch add support for a new property which we can use to impose such
limitation.

Signed-off-by: Robert Chiras 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 9a73564..c0b6198 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -201,6 +201,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
struct platform_device *pdev = to_platform_device(drm->dev);
struct mxsfb_drm_private *mxsfb;
struct resource *res;
+   u32 max_res[2] = {0, 0};
int ret;
 
mxsfb = devm_kzalloc(&pdev->dev, sizeof(*mxsfb), GFP_KERNEL);
@@ -279,10 +280,17 @@ static int mxsfb_load(struct drm_device *drm, unsigned 
long flags)
}
}
 
+   of_property_read_u32_array(drm->dev->of_node, "max-res",
+  &max_res[0], 2);
+   if (!max_res[0])
+   max_res[0] = MXSFB_MAX_XRES;
+   if (!max_res[1])
+   max_res[1] = MXSFB_MAX_YRES;
+
drm->mode_config.min_width  = MXSFB_MIN_XRES;
drm->mode_config.min_height = MXSFB_MIN_YRES;
-   drm->mode_config.max_width  = MXSFB_MAX_XRES;
-   drm->mode_config.max_height = MXSFB_MAX_YRES;
+   drm->mode_config.max_width  = max_res[0];
+   drm->mode_config.max_height = max_res[1];
drm->mode_config.funcs  = &mxsfb_mode_config_funcs;
drm->mode_config.helper_private = &mxsfb_mode_config_helpers;
 
-- 
2.7.4

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


[PATCH 08/10] drm/mxsfb: Update mxsfb to support LCD reset

2019-01-10 Thread Robert Chiras
The eLCDIF controller has control pin for the external LCD reset pin.
Add support for it and assert this pin in enable and de-assert it in
disable.
Also, correct the pm_runtime_enable call, since it was made too early in
the probe, causing issues to DRM enable routines.

Signed-off-by: Robert Chiras 
---
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 ++--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 20 
 drivers/gpu/drm/mxsfb/mxsfb_regs.h |  1 +
 3 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index b62b607..8d1b6a6 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -230,9 +230,12 @@ static void mxsfb_enable_controller(struct 
mxsfb_drm_private *mxsfb)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
 
-   if (mxsfb->devdata->ipversion >= 4)
+   if (mxsfb->devdata->ipversion >= 4) {
writel(CTRL2_OUTSTANDING_REQS(REQ_16),
mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+   /* Assert LCD Reset bit */
+   writel(CTRL2_LCD_RESET, mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+   }
 
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
@@ -250,9 +253,12 @@ static void mxsfb_disable_controller(struct 
mxsfb_drm_private *mxsfb)
 {
u32 reg;
 
-   if (mxsfb->devdata->ipversion >= 4)
+   if (mxsfb->devdata->ipversion >= 4) {
writel(CTRL2_OUTSTANDING_REQS(0x7),
mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
+   /* De-assert LCD Reset bit */
+   writel(CTRL2_LCD_RESET, mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
+   }
 
writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_CLR);
 
@@ -346,6 +352,8 @@ static void mxsfb_crtc_mode_set_nofb(struct 
mxsfb_drm_private *mxsfb)
return;
 
clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
+   DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)\n",
+   m->crtc_clock, (int)(clk_get_rate(mxsfb->clk) / 1000));
 
DRM_DEV_DEBUG_DRIVER(drm->dev,
"Connector bus_flags: 0x%08X\n", bus_flags);
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index f528a37..135b8e1 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -287,7 +287,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
if (IS_ERR(mxsfb->base))
return PTR_ERR(mxsfb->base);
 
-   mxsfb->clk = devm_clk_get(drm->dev, NULL);
+   mxsfb->clk = devm_clk_get(drm->dev, "pix");
if (IS_ERR(mxsfb->clk))
return PTR_ERR(mxsfb->clk);
 
@@ -303,12 +303,10 @@ static int mxsfb_load(struct drm_device *drm, unsigned 
long flags)
if (ret)
return ret;
 
-   pm_runtime_enable(drm->dev);
-
ret = drm_vblank_init(drm, MAX_CRTCS);
if (ret < 0) {
dev_err(drm->dev, "Failed to initialise vblank\n");
-   goto err_vblank;
+   return ret;
}
 
/* Modeset init */
@@ -317,7 +315,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
ret = mxsfb_create_output(drm);
if (ret < 0) {
dev_err(drm->dev, "Failed to create outputs\n");
-   goto err_vblank;
+   return ret;
}
 
ret = drm_simple_display_pipe_init(drm, &mxsfb->pipe, &mxsfb_funcs,
@@ -325,7 +323,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
mxsfb->connector);
if (ret < 0) {
dev_err(drm->dev, "Cannot setup simple display pipe\n");
-   goto err_vblank;
+   return ret;
}
 
drm_crtc_vblank_off(&mxsfb->pipe.crtc);
@@ -342,14 +340,14 @@ static int mxsfb_load(struct drm_device *drm, unsigned 
long flags)
ret = drm_panel_attach(mxsfb->panel, mxsfb->connector);
if (ret) {
dev_err(drm->dev, "Cannot connect panel\n");
-   goto err_vblank;
+   return ret;
}
} else if (mxsfb->bridge) {
ret = drm_simple_display_pipe_attach_bridge(&mxsfb->pipe,
mxsfb->bridge);
if (ret) {
dev_err(drm->dev, "Cannot connect bridge\n");
-   goto err_vblank;
+   return ret;
}
}
 
@@ -369,9 +367,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long 
flags)
 
drm_mode_config_reset(drm);
 
-   pm_runtime_get_sync(drm->dev);
ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
-   pm_runtime_put_sync(drm->dev);
 
if (ret < 

Re: [PATCH 9/9] drm/mediatek: add dpi dual edge support

2019-01-10 Thread Matthias Brugger


On 04/01/2019 08:03, chunhui dai wrote:
> DPI sample on rising and falling edge. It can reduce half data io.
> 
> Signed-off-by: Jitao Shi 
> Signed-off-by: chunhui dai 
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 4a2f4a6..acb4f47 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -117,6 +117,7 @@ struct mtk_dpi_conf {
>   unsigned int (*cal_factor)(int clock);
>   u32 reg_h_fre_con;
>   bool edge_sel_en;
> + bool dual_edge;
>  };
>  
>  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
> @@ -353,6 +354,15 @@ static void mtk_dpi_config_disable_edge(struct mtk_dpi 
> *dpi)
>   mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
>  }
>  
> +static void mtk_dpi_config_dual_edge(struct mtk_dpi *dpi)

I think it is clearer if you rename the function to something like:
mtk_dpi_enable_dual_edge and call it in mtk_dpi_set_display_mode if
dpi->conf->dual_edge is true.

Regards,
Matthias

> +{
> + if (dpi->conf->dual_edge) {
> + mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN |
> + DDR_4PHASE, DDR_EN | DDR_4PHASE);
> + mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING, EDGE_SEL, EDGE_SEL);
> + }
> +}
> +
>  static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
>   enum mtk_dpi_out_color_format format)
>  {
> @@ -509,6 +519,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   mtk_dpi_config_color_format(dpi, dpi->color_format);
>   mtk_dpi_config_2n_h_fre(dpi);
>   mtk_dpi_config_disable_edge(dpi);
> + mtk_dpi_config_dual_edge(dpi);
>   mtk_dpi_sw_reset(dpi, false);
>  
>   return 0;
> @@ -669,6 +680,16 @@ static unsigned int mt2701_calculate_factor(int clock)
>   return 1;
>  }
>  
> +static unsigned int mt8183_calculate_factor(int clock)
> +{
> + if (clock <= 27000)
> + return 8;
> + else if (clock <= 167000)
> + return 4;
> + else
> + return 2;
> +}
> +
>  static const struct mtk_dpi_conf mt8173_conf = {
>   .cal_factor = mt8173_calculate_factor,
>   .reg_h_fre_con = 0xe0,
> @@ -680,6 +701,12 @@ static unsigned int mt2701_calculate_factor(int clock)
>   .edge_sel_en = true,
>  };
>  
> +static const struct mtk_dpi_conf mt8183_conf = {
> + .cal_factor = mt8183_calculate_factor,
> + .reg_h_fre_con = 0xe0,
> + .dual_edge = true,
> +};
> +
>  static int mtk_dpi_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -775,6 +802,9 @@ static int mtk_dpi_remove(struct platform_device *pdev)
>   { .compatible = "mediatek,mt8173-dpi",
> .data = &mt8173_conf,
>   },
> + { .compatible = "mediatek,mt8183-dpi",
> +   .data = &mt8183_conf,
> + },
>   { },
>  };
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 04/10] drm/mxsfb: Update mxsfb with additional pixel formats

2019-01-10 Thread Robert Chiras
Since version 4 of eLCDIF, there are some registers that can do
transformations on the input data, like re-arranging the pixel
components. By doing that, we can support more pixel formats.
This patch adds support for X/ABGR and RGBX/A. Although, the local alpha
is not supported by eLCDIF, the alpha pixel formats were added to the
supported pixel formats but it will be ignored. This was necessary since
there are systems (like Android) that requires such pixel formats.

Signed-off-by: Robert Chiras 
---
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 108 -
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  27 +++---
 drivers/gpu/drm/mxsfb/mxsfb_drv.h  |   4 +-
 drivers/gpu/drm/mxsfb/mxsfb_regs.h | 100 --
 4 files changed, 169 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index f0648ce..6aa8804 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -48,15 +48,35 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private 
*mxsfb, u32 val)
mxsfb->devdata->hs_wdth_shift;
 }
 
+/*  Print Four-character-code (FOURCC) */
+static char *fourcc_to_str(u32 fmt)
+{
+   /* Use 10 chars so we can simultaneously print two codes */
+   static char code[10], *c = &code[0];
+
+   if (c == &code[10])
+   c = &code[0];
+
+   *(c++) = (unsigned char)(fmt & 0xff);
+   *(c++) = (unsigned char)((fmt >> 8) & 0xff);
+   *(c++) = (unsigned char)((fmt >> 16) & 0xff);
+   *(c++) = (unsigned char)((fmt >> 24) & 0xff);
+   *(c++) = '\0';
+
+   return (c - 5);
+}
+
 /* Setup the MXSFB registers for decoding the pixels out of the framebuffer */
-static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb)
+static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb, bool update)
 {
struct drm_crtc *crtc = &mxsfb->pipe.crtc;
struct drm_device *drm = crtc->dev;
const u32 format = crtc->primary->state->fb->format->format;
-   u32 ctrl, ctrl1;
+   u32 ctrl = 0, ctrl1 = 0;
+   bool bgr_format = true;
 
-   ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
+   if (!update)
+   ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
 
/*
 * WARNING: The bus width, CTRL_SET_BUS_WIDTH(), is configured to
@@ -65,31 +85,69 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private 
*mxsfb)
 * to arbitrary value. This limitation should not pose an issue.
 */
 
-   /* CTRL1 contains IRQ config and status bits, preserve those. */
-   ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
-   ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
+   if (!update) {
+   /* CTRL1 contains IRQ config and status bits, preserve those. */
+   ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
+   ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
+   }
+
+   DRM_DEV_DEBUG_DRIVER(drm->dev, "Setting up %s mode\n",
+   fourcc_to_str(format));
+
+   /* Do some clean-up that we might have from a previous mode */
+   ctrl &= ~CTRL_SHIFT_DIR(1);
+   ctrl &= ~CTRL_SHIFT_NUM(0x3f);
+   if (mxsfb->devdata->ipversion >= 4)
+   writel(CTRL2_ODD_LINE_PATTERN(0x7) |
+  CTRL2_EVEN_LINE_PATTERN(0x7),
+  mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
 
switch (format) {
case DRM_FORMAT_RGB565:
-   dev_dbg(drm->dev, "Setting up RGB565 mode\n");
ctrl |= CTRL_SET_WORD_LENGTH(0);
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
break;
+   case DRM_FORMAT_RGBX:
+   case DRM_FORMAT_RGBA:
+   /* RGBX - > 0RGB */
+   ctrl |= CTRL_SHIFT_DIR(1);
+   ctrl |= CTRL_SHIFT_NUM(8);
+   bgr_format = false;
+   /* Fall through */
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ABGR:
+   if (bgr_format) {
+   if (mxsfb->devdata->ipversion < 4)
+   goto err;
+   writel(CTRL2_ODD_LINE_PATTERN(0x5) |
+  CTRL2_EVEN_LINE_PATTERN(0x5),
+  mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+   }
+   /* Fall through */
case DRM_FORMAT_XRGB:
-   dev_dbg(drm->dev, "Setting up XRGB mode\n");
+   case DRM_FORMAT_ARGB:
ctrl |= CTRL_SET_WORD_LENGTH(3);
/* Do not use packed pixels = one pixel per word instead. */
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
break;
default:
-   dev_err(drm->dev, "Unhandled pixel format %08x\n", format);
-   return -EINVAL;
+   goto err;
}
 
-   writel(ctrl1, mxsfb->base + LCDC_CTRL1);
-   writel(ctrl, mxsfb->

[PATCH 06/10] drm/mxsfb: Add support for new pixel formats in eLCDIF

2019-01-10 Thread Robert Chiras
From: Mirela Rabulea 

Add support for the following pixel formats:
16 bpp: RG16 ,BG16, XR15, XB15, AR15, AB15
Set the bus format based on input from the user and panel capabilities.
Save the bus format in crtc->mode.private_flags, the DSI will use it.
Use drm_get_format_name instead of locally defined fourcc_to_str.

Signed-off-by: Mirela Rabulea 
---
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 100 ++---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c  |   5 ++
 2 files changed, 76 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 6aa8804..b62b607 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -48,24 +48,6 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private 
*mxsfb, u32 val)
mxsfb->devdata->hs_wdth_shift;
 }
 
-/*  Print Four-character-code (FOURCC) */
-static char *fourcc_to_str(u32 fmt)
-{
-   /* Use 10 chars so we can simultaneously print two codes */
-   static char code[10], *c = &code[0];
-
-   if (c == &code[10])
-   c = &code[0];
-
-   *(c++) = (unsigned char)(fmt & 0xff);
-   *(c++) = (unsigned char)((fmt >> 8) & 0xff);
-   *(c++) = (unsigned char)((fmt >> 16) & 0xff);
-   *(c++) = (unsigned char)((fmt >> 24) & 0xff);
-   *(c++) = '\0';
-
-   return (c - 5);
-}
-
 /* Setup the MXSFB registers for decoding the pixels out of the framebuffer */
 static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb, bool update)
 {
@@ -74,6 +56,7 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private 
*mxsfb, bool update)
const u32 format = crtc->primary->state->fb->format->format;
u32 ctrl = 0, ctrl1 = 0;
bool bgr_format = true;
+   struct drm_format_name_buf format_name_buf;
 
if (!update)
ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
@@ -92,7 +75,7 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private 
*mxsfb, bool update)
}
 
DRM_DEV_DEBUG_DRIVER(drm->dev, "Setting up %s mode\n",
-   fourcc_to_str(format));
+   drm_get_format_name(format, &format_name_buf));
 
/* Do some clean-up that we might have from a previous mode */
ctrl &= ~CTRL_SHIFT_DIR(1);
@@ -103,19 +86,41 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private 
*mxsfb, bool update)
   mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
 
switch (format) {
-   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_BGR565: /* BG16 */
+   if (mxsfb->devdata->ipversion < 4)
+   goto err;
+   writel(CTRL2_ODD_LINE_PATTERN(0x5) |
+   CTRL2_EVEN_LINE_PATTERN(0x5),
+   mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+   /* Fall through */
+   case DRM_FORMAT_RGB565: /* RG16 */
ctrl |= CTRL_SET_WORD_LENGTH(0);
+   ctrl &= ~CTRL_DF16;
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
break;
-   case DRM_FORMAT_RGBX:
-   case DRM_FORMAT_RGBA:
+   case DRM_FORMAT_XBGR1555: /* XB15 */
+   case DRM_FORMAT_ABGR1555: /* AB15 */
+   if (mxsfb->devdata->ipversion < 4)
+   goto err;
+   writel(CTRL2_ODD_LINE_PATTERN(0x5) |
+   CTRL2_EVEN_LINE_PATTERN(0x5),
+   mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+   /* Fall through */
+   case DRM_FORMAT_XRGB1555: /* XR15 */
+   case DRM_FORMAT_ARGB1555: /* AR15 */
+   ctrl |= CTRL_SET_WORD_LENGTH(0);
+   ctrl |= CTRL_DF16;
+   ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
+   break;
+   case DRM_FORMAT_RGBX: /* RX24 */
+   case DRM_FORMAT_RGBA: /* RA24 */
/* RGBX - > 0RGB */
ctrl |= CTRL_SHIFT_DIR(1);
ctrl |= CTRL_SHIFT_NUM(8);
bgr_format = false;
/* Fall through */
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XBGR: /* XB24 */
+   case DRM_FORMAT_ABGR: /* AB24 */
if (bgr_format) {
if (mxsfb->devdata->ipversion < 4)
goto err;
@@ -124,8 +129,8 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private 
*mxsfb, bool update)
   mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
}
/* Fall through */
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_XRGB: /* XR24 */
+   case DRM_FORMAT_ARGB: /* AR24 */
ctrl |= CTRL_SET_WORD_LENGTH(3);
/* Do not use packed pixels = one pixel per word instead. */
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
@@ -146,19 +151,56 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private

[PATCH] drm/panel: simple: innolux, at070tn92: specify correct pixdata edge

2019-01-10 Thread Ahmad Fatoum
Panel expects pixel data to be driven on a rising clock edge,
according to A070-92-TT-01 spec, v01, figure 3.1 on page 10/20:
http://www.webcitation.org/75IfI67Kk

This is untested on the AT070TN92, but on its Acrowise AWY-800480T70PC15A
clone, this fixes a 'dancing pixels' artifact when running modetest -s.

Signed-off-by: Ahmad Fatoum 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index a04ffb3b2174..021066a231b5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1210,6 +1210,7 @@ static const struct panel_desc innolux_at070tn92 = {
.height = 86,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
 };
 
 static const struct display_timing innolux_g070y2_l01_timing = {
-- 
2.19.1

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


[PATCH v7 03/11] gpu: ipu-v3: Add planar support to interlaced scan

2019-01-10 Thread Steve Longerbeam
To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be doubled, since a single chroma line
is shared by two luma lines.

Signed-off-by: Steve Longerbeam 
Reviewed-by: Philipp Zabel 
Acked-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-cpmem.c  | 26 +++--
 drivers/staging/media/imx/imx-ic-prpencvf.c |  3 ++-
 drivers/staging/media/imx/imx-media-csi.c   |  3 ++-
 include/video/imx-ipu-v3.h  |  3 ++-
 4 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 163fadb8a33a..d047a6867c59 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -277,9 +277,10 @@ void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 
u_off, u32 v_off)
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_uv_offset);
 
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride)
+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+  u32 pixelformat)
 {
-   u32 ilo, sly;
+   u32 ilo, sly, sluv;
 
if (stride < 0) {
stride = -stride;
@@ -290,9 +291,30 @@ void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, 
int stride)
 
sly = (stride * 2) - 1;
 
+   switch (pixelformat) {
+   case V4L2_PIX_FMT_YUV420:
+   case V4L2_PIX_FMT_YVU420:
+   sluv = stride / 2 - 1;
+   break;
+   case V4L2_PIX_FMT_NV12:
+   sluv = stride - 1;
+   break;
+   case V4L2_PIX_FMT_YUV422P:
+   sluv = stride - 1;
+   break;
+   case V4L2_PIX_FMT_NV16:
+   sluv = stride * 2 - 1;
+   break;
+   default:
+   sluv = 0;
+   break;
+   }
+
ipu_ch_param_write_field(ch, IPU_FIELD_SO, 1);
ipu_ch_param_write_field(ch, IPU_FIELD_ILO, ilo);
ipu_ch_param_write_field(ch, IPU_FIELD_SLY, sly);
+   if (sluv)
+   ipu_ch_param_write_field(ch, IPU_FIELD_SLUV, sluv);
 };
 EXPORT_SYMBOL_GPL(ipu_cpmem_interlaced_scan);
 
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 28f41caba05d..af7224846bd5 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -412,7 +412,8 @@ static int prp_setup_channel(struct prp_priv *priv,
if (image.pix.field == V4L2_FIELD_NONE &&
V4L2_FIELD_HAS_BOTH(infmt->field) &&
channel == priv->out_ch)
-   ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline);
+   ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline,
+ image.pix.pixelformat);
 
ret = ipu_ic_task_idma_init(priv->ic, channel,
image.pix.width, image.pix.height,
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index c2a8d9cd31b7..da4808348845 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -512,7 +512,8 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
if (image.pix.field == V4L2_FIELD_NONE &&
V4L2_FIELD_HAS_BOTH(infmt->field))
ipu_cpmem_interlaced_scan(priv->idmac_ch,
- image.pix.bytesperline);
+ image.pix.bytesperline,
+ image.pix.pixelformat);
 
ipu_idmac_set_double_buffer(priv->idmac_ch, true);
 
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index bbc8481f567d..c887f4bee5f8 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -258,7 +258,8 @@ void ipu_cpmem_set_stride(struct ipuv3_channel *ch, int 
stride);
 void ipu_cpmem_set_high_priority(struct ipuv3_channel *ch);
 void ipu_cpmem_set_buffer(struct ipuv3_channel *ch, int bufnum, dma_addr_t 
buf);
 void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 u_off, u32 v_off);
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride);
+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+  u32 pixelformat);
 void ipu_cpmem_set_axi_id(struct ipuv3_channel *ch, u32 id);
 int ipu_cpmem_get_burstsize(struct ipuv3_channel *ch);
 void ipu_cpmem_set_burstsize(struct ipuv3_channel *ch, int burstsize);
-- 
2.17.1

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


Re: [PATCH 1/9] drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware

2019-01-10 Thread Matthias Brugger


On 04/01/2019 08:03, chunhui dai wrote:
> Recalculate the rate of this clock, by querying hardware.
> 
> Signed-off-by: chunhui dai 
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.c|  7 ++--
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.h|  3 +-
>  drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 49 
> ++
>  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |  8 +
>  4 files changed, 61 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 4ef9c57..79e737d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -29,12 +29,11 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned 
> long rate,
>   return rate;
>  }
>  
> -unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> -unsigned long parent_rate)
> +u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
>  {
> - struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + void __iomem *reg = hdmi_phy->regs + offset;
>  
> - return hdmi_phy->pll_rate;
> + return readl(reg);
>  }
>  
>  void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h 
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index f39b1fc..fdad8b1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -41,6 +41,7 @@ struct mtk_hdmi_phy {
>   unsigned int ibias_up;
>  };
>  
> +u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset);
>  void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
>u32 bits);
>  void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
> @@ -50,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 
> offset,
>  struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
>  long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
>unsigned long *parent_rate);
> -unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> -unsigned long parent_rate);
>  
>  extern struct platform_driver mtk_hdmi_phy_driver;
>  extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index fcc42dc..b5ed6b7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -153,6 +153,55 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> RG_HDMITX_DRV_IBIAS_MASK);
>   return 0;
>  }
> +static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
> + unsigned long out_rate, val;
> +
> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
> + & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
> + switch (val) {
> + case 0x00:
> + out_rate = parent_rate;
> + break;
> + case 0x01:
> + out_rate = parent_rate / 2;
> + break;
> + default:
> + out_rate = parent_rate / 4;
> + break;
> + }
> +
> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
> + & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
> + out_rate = out_rate * (val + 1) * 2;
> + val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2)
> + & RG_HDMITX_TX_POSDIV_MASK) >> RG_HDMITX_TX_POSDIV;
> + switch (val) {
> + case 0x00:
> + out_rate = out_rate;
> + break;
> + case 0x01:
> + out_rate = out_rate / 2;
> + break;
> + case 0x02:
> + out_rate = out_rate / 4;
> + break;
> + case 0x03:
> + out_rate = out_rate / 8;
> + break;
> + default:
> + break;
> + }
> +
> + if (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)

Is this path time critical? You are reading the same register twice instead of
saving the read in a local varibale.

Regards,
Matthias

> + out_rate = out_rate / 5;
> +
> + hdmi_phy->pll_rate = out_rate;
> +
> + return hdmi_phy->pll_rate;
> +}
>  
>  static const struct clk_ops mtk_hdmi_phy_pll_ops = {
>   .prepare = mtk_hdmi_pll_prepare,
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> index ed5916b..cb23c1e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> @@ -285,6 +285,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>   return 0;
>  }
>  
> +static unsigned long 

Re: [PATCH 4/9] drm/mediatek: fix the rate and divder of hdmi phy for MT2701

2019-01-10 Thread Matthias Brugger


On 04/01/2019 08:03, chunhui dai wrote:
> fix the rate and divder of hdmi phy for MT2701.

This is a bug? Then we would need a fixes tag.
Otherwise you should explain in the commit, that you need to change the
calculation due to previous commits.

Regards,
Matthias

> 
> Signed-off-by: chunhui dai 
> ---
>  drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index a28a32d..10b6235 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -114,8 +114,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>  
>   if (rate <= 6400)
>   pos_div = 3;
> - else if (rate <= 1280)
> - pos_div = 1;
> + else if (rate <= 12800)
> + pos_div = 2;
>   else
>   pos_div = 1;
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 07/10] drm/mxsfb: Signal mode changed when bpp changed

2019-01-10 Thread Robert Chiras
From: Mirela Rabulea 

Add mxsfb_atomic_helper_check to signal mode changed when bpp changed.
This will trigger the execution of disable/enable on
a modeset with different bpp than the current one.

Signed-off-by: Mirela Rabulea 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 48 ++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d3fb3a8..f528a37 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -115,9 +115,55 @@ void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
clk_disable_unprepare(mxsfb->clk_axi);
 }
 
+/**
+ * mxsfb_atomic_helper_check - validate state object
+ * @dev: DRM device
+ * @state: the driver state object
+ *
+ * On top of the drm imlementation drm_atomic_helper_check,
+ * check if the bpp is changed, if so, signal mode_changed,
+ * this will trigger disable/enable
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+static int mxsfb_atomic_helper_check(struct drm_device *dev,
+   struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int i, ret;
+
+   ret = drm_atomic_helper_check(dev, state);
+   if (ret)
+   return ret;
+
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   struct drm_plane_state *primary_state;
+   int old_bpp = 0;
+   int new_bpp = 0;
+
+   if (!crtc->primary || !crtc->primary->old_fb)
+   continue;
+   primary_state =
+   drm_atomic_get_plane_state(state, crtc->primary);
+   if (!primary_state || !primary_state->fb)
+   continue;
+   old_bpp = crtc->primary->old_fb->format->depth;
+   new_bpp = primary_state->fb->format->depth;
+   if (old_bpp != new_bpp) {
+   crtc_state->mode_changed = true;
+   DRM_DEBUG_ATOMIC(
+   "[CRTC:%d:%s] mode changed, bpp %d->%d\n",
+   crtc->base.id, crtc->name, old_bpp, new_bpp);
+   }
+   }
+   return ret;
+}
+
 static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
.fb_create  = drm_gem_fb_create,
-   .atomic_check   = drm_atomic_helper_check,
+   .atomic_check   = mxsfb_atomic_helper_check,
.atomic_commit  = drm_atomic_helper_commit,
 };
 
-- 
2.7.4

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


[PATCH v8 03/11] gpu: ipu-v3: Add planar support to interlaced scan

2019-01-10 Thread Steve Longerbeam
To support interlaced scan with planar formats, cpmem SLUV must
be programmed with the correct chroma line stride. For full and
partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
chroma line stride must _not_ be doubled, since a single chroma line
is shared by two luma lines.

Signed-off-by: Steve Longerbeam 
Reviewed-by: Philipp Zabel 
Acked-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-cpmem.c  | 26 +++--
 drivers/staging/media/imx/imx-ic-prpencvf.c |  3 ++-
 drivers/staging/media/imx/imx-media-csi.c   |  3 ++-
 include/video/imx-ipu-v3.h  |  3 ++-
 4 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index 163fadb8a33a..d047a6867c59 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -277,9 +277,10 @@ void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 
u_off, u32 v_off)
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_uv_offset);
 
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride)
+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+  u32 pixelformat)
 {
-   u32 ilo, sly;
+   u32 ilo, sly, sluv;
 
if (stride < 0) {
stride = -stride;
@@ -290,9 +291,30 @@ void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, 
int stride)
 
sly = (stride * 2) - 1;
 
+   switch (pixelformat) {
+   case V4L2_PIX_FMT_YUV420:
+   case V4L2_PIX_FMT_YVU420:
+   sluv = stride / 2 - 1;
+   break;
+   case V4L2_PIX_FMT_NV12:
+   sluv = stride - 1;
+   break;
+   case V4L2_PIX_FMT_YUV422P:
+   sluv = stride - 1;
+   break;
+   case V4L2_PIX_FMT_NV16:
+   sluv = stride * 2 - 1;
+   break;
+   default:
+   sluv = 0;
+   break;
+   }
+
ipu_ch_param_write_field(ch, IPU_FIELD_SO, 1);
ipu_ch_param_write_field(ch, IPU_FIELD_ILO, ilo);
ipu_ch_param_write_field(ch, IPU_FIELD_SLY, sly);
+   if (sluv)
+   ipu_ch_param_write_field(ch, IPU_FIELD_SLUV, sluv);
 };
 EXPORT_SYMBOL_GPL(ipu_cpmem_interlaced_scan);
 
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 28f41caba05d..af7224846bd5 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -412,7 +412,8 @@ static int prp_setup_channel(struct prp_priv *priv,
if (image.pix.field == V4L2_FIELD_NONE &&
V4L2_FIELD_HAS_BOTH(infmt->field) &&
channel == priv->out_ch)
-   ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline);
+   ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline,
+ image.pix.pixelformat);
 
ret = ipu_ic_task_idma_init(priv->ic, channel,
image.pix.width, image.pix.height,
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index c2a8d9cd31b7..da4808348845 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -512,7 +512,8 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
if (image.pix.field == V4L2_FIELD_NONE &&
V4L2_FIELD_HAS_BOTH(infmt->field))
ipu_cpmem_interlaced_scan(priv->idmac_ch,
- image.pix.bytesperline);
+ image.pix.bytesperline,
+ image.pix.pixelformat);
 
ipu_idmac_set_double_buffer(priv->idmac_ch, true);
 
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index bbc8481f567d..c887f4bee5f8 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -258,7 +258,8 @@ void ipu_cpmem_set_stride(struct ipuv3_channel *ch, int 
stride);
 void ipu_cpmem_set_high_priority(struct ipuv3_channel *ch);
 void ipu_cpmem_set_buffer(struct ipuv3_channel *ch, int bufnum, dma_addr_t 
buf);
 void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch, u32 u_off, u32 v_off);
-void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride);
+void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
+  u32 pixelformat);
 void ipu_cpmem_set_axi_id(struct ipuv3_channel *ch, u32 id);
 int ipu_cpmem_get_burstsize(struct ipuv3_channel *ch);
 void ipu_cpmem_set_burstsize(struct ipuv3_channel *ch, int burstsize);
-- 
2.17.1

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


[PATCH v10 1/2] drm/fourcc: Add new P010, P016 video format

2019-01-10 Thread Randy Li
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format.

P012 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010.
V4: format definition refined per review.
V5: Format comment block for each new pixel format.
V6: reversed Cb/Cr order in comments.
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.
V8: reversed V7 changes except commit message and rebased.
v9: used the new properties to describe those format and
rebased.

Cc: Daniel Stone 
Cc: Ville Syrjälä 

Signed-off-by: Randy Li 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_fourcc.c  |  9 +
 include/uapi/drm/drm_fourcc.h | 21 +
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d90ee03a84c6..ba7e19d4336c 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -238,6 +238,15 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_X0L2,.depth = 0,  
.num_planes = 1,
  .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 }, 
.block_h = { 2, 0, 0 },
  .hsub = 2, .vsub = 2, .is_yuv = true },
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, 
.block_h = { 1, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
+   { .format = DRM_FORMAT_P012,.depth = 0,  
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, 
.block_h = { 1, 0, 0 },
+  .hsub = 2, .vsub = 2, .is_yuv = true},
+   { .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2,
+ .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, 
.block_h = { 1, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true},
};
 
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0b44260a5ee9..8dd1328bc8d6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -195,6 +195,27 @@ extern "C" {
 #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /* 
non-subsampled Cr:Cb plane */
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */
 
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cr:Cb plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cr:Cb plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cr:Cb plane 16 bits per channel */
+
 /*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
-- 
2.20.1

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


Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

2019-01-10 Thread Zhang, Jerry(Junwei)

On 1/10/19 3:28 PM, Ard Biesheuvel wrote:

ARM systems do not permit the use of anything other than cached
mappings for system memory, since that memory may be mapped in the
linear region as well, and the architecture does not permit aliases
with mismatched attributes.

So short-circuit the evaluation in ttm_io_prot() if the flags include
TTM_PL_SYSTEM when running on ARM or arm64, and just return cached
attributes immediately.


It sounds a case for ARM system memory access from CPU only?

If that always applies to ARM memory, suppose we should do that for 
TTM_PL_TT as well.

While TTM_PL_TT | TTM_PL_FLAG_WC is likely to work as below mention.

Regards,
Jerry

This fixes the radeon and amdgpu [TBC] drivers when running on arm64.
Without this change, amdgpu does not start at all, and radeon only
produces corrupt display output.

Cc: Christian Koenig 
Cc: Huang Rui 
Cc: Junwei Zhang 
Cc: David Airlie 
Reported-by: Carsten Haitzler 
Signed-off-by: Ard Biesheuvel 
---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 046a6dda690a..0c1eef5f7ae3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
if (caching_flags & TTM_PL_FLAG_CACHED)
return tmp;
  
+#if defined(__arm__) || defined(__aarch64__)

+   /* ARM only permits cached mappings of system memory */
+   if (caching_flags & TTM_PL_SYSTEM)
+   return tmp;
+#endif
  #if defined(__i386__) || defined(__x86_64__)
if (caching_flags & TTM_PL_FLAG_WC)
tmp = pgprot_writecombine(tmp);


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


Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

2019-01-10 Thread Koenig, Christian
Hi Ard,

thanks a lot for this! At least somebody who can explain why this 
doesn't work as expected.

The problem is that the hardware actually needs a few pages as uncached 
in a couple of cases to work correctly. So we could still run into 
issues with that solution.

For now we have blocked userspace/kernel from extensively using write 
combine mappings by adjusting drm_arch_can_wc_memory(), but that is 
probably degrading performance quite a bit.

What can be done to improve the solution? At least on X86 we solve this 
by marking the write combined pages in the linear mapping as uncached as 
well. Would this be doable on ARM as well?

Thanks,
Christian.

Am 10.01.19 um 08:28 schrieb Ard Biesheuvel:
> ARM systems do not permit the use of anything other than cached
> mappings for system memory, since that memory may be mapped in the
> linear region as well, and the architecture does not permit aliases
> with mismatched attributes.
>
> So short-circuit the evaluation in ttm_io_prot() if the flags include
> TTM_PL_SYSTEM when running on ARM or arm64, and just return cached
> attributes immediately.
>
> This fixes the radeon and amdgpu [TBC] drivers when running on arm64.
> Without this change, amdgpu does not start at all, and radeon only
> produces corrupt display output.
>
> Cc: Christian Koenig 
> Cc: Huang Rui 
> Cc: Junwei Zhang 
> Cc: David Airlie 
> Reported-by: Carsten Haitzler 
> Signed-off-by: Ard Biesheuvel 
> ---
>   drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 046a6dda690a..0c1eef5f7ae3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
> tmp)
>   if (caching_flags & TTM_PL_FLAG_CACHED)
>   return tmp;
>   
> +#if defined(__arm__) || defined(__aarch64__)
> + /* ARM only permits cached mappings of system memory */
> + if (caching_flags & TTM_PL_SYSTEM)
> + return tmp;
> +#endif
>   #if defined(__i386__) || defined(__x86_64__)
>   if (caching_flags & TTM_PL_FLAG_WC)
>   tmp = pgprot_writecombine(tmp);

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


Re: [PATCH v6] drm/panel: Add a driver for the TPO TPG110

2019-01-10 Thread Sam Ravnborg
Hi Thierry.

> > +   case TPG110_RES_480X272:
> > +   dev_info(tpg->dev, "480x272 RGB");
> > +   break;
> > +   case TPG110_RES_640X480:
> > +   dev_info(tpg->dev, "640x480 RGB");
> > +   break;
> > +   case TPG110_RES_800X480:
> > +   dev_info(tpg->dev, "800x480 RGB");
> > +   break;
> > +   default:
> > +   dev_info(tpg->dev, "ILLEGAL RESOLUTION");
> 
> dev_err()? Also, perhaps make this some proper error message and include
> the invalid value?
> 
> Also I just noticed that the above informational messages all lack a \n
> at the end.

The "\n" is optional these days.

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


Re: [PATCH v3 14/15] drm/bochs: drop old fbdev emulation code

2019-01-10 Thread Noralf Trønnes


Den 10.01.2019 09.28, skrev Gerd Hoffmann:
> Not needed any more, bochs uses the generic emulation now.
> 
> Signed-off-by: Gerd Hoffmann 
> Reviewed-by: Oleksandr Andrushchenko 
> Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/bochs/bochs.h   |   9 ---
>  drivers/gpu/drm/bochs/bochs_drv.c   |   6 --
>  drivers/gpu/drm/bochs/bochs_fbdev.c | 129 
> 
>  3 files changed, 144 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
> index ede22beb85..03711394f1 100644
> --- a/drivers/gpu/drm/bochs/bochs.h
> +++ b/drivers/gpu/drm/bochs/bochs.h
> @@ -80,12 +80,6 @@ struct bochs_device {
>   struct ttm_bo_device bdev;
>   bool initialized;
>   } ttm;
> -
> - /* fbdev */
> - struct {
> - struct drm_framebuffer *fb;
> - struct drm_fb_helper helper;
> - } fb;
>  };
>  
>  struct bochs_bo {
> @@ -157,7 +151,4 @@ int bochs_kms_init(struct bochs_device *bochs);
>  void bochs_kms_fini(struct bochs_device *bochs);
>  
>  /* bochs_fbdev.c */
> -int bochs_fbdev_init(struct bochs_device *bochs);
> -void bochs_fbdev_fini(struct bochs_device *bochs);
> -
>  extern const struct drm_mode_config_funcs bochs_mode_funcs;
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index 1d86c0fb5f..a8968cd8d5 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -102,12 +102,9 @@ static int bochs_pm_suspend(struct device *dev)
>  {
>   struct pci_dev *pdev = to_pci_dev(dev);
>   struct drm_device *drm_dev = pci_get_drvdata(pdev);
> - struct bochs_device *bochs = drm_dev->dev_private;
>  
>   drm_kms_helper_poll_disable(drm_dev);
>  
> - drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 1);

The generic fbdev emulation doesn't take care of suspend/resume. You
could do this:
drm_fb_helper_set_suspend_unlocked(drm_dev->fb_helper, 1);

> -
>   return 0;
>  }
>  
> @@ -115,12 +112,9 @@ static int bochs_pm_resume(struct device *dev)
>  {
>   struct pci_dev *pdev = to_pci_dev(dev);
>   struct drm_device *drm_dev = pci_get_drvdata(pdev);
> - struct bochs_device *bochs = drm_dev->dev_private;
>  
>   drm_helper_resume_force_mode(drm_dev);

The docs for this function has this to say:
* This function is deprecated. New drivers should implement atomic mode-
* setting and use the atomic suspend/resume helpers.

Maybe you can use drm_mode_config_helper_suspend/resume() instead like
suggested in the drm_fbdev_generic_setup() docs.

Noralf.

>  
> - drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 0);
> -
>   drm_kms_helper_poll_enable(drm_dev);
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
> b/drivers/gpu/drm/bochs/bochs_fbdev.c
> index ccf783b038..7cac3f5253 100644
> --- a/drivers/gpu/drm/bochs/bochs_fbdev.c
> +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
> @@ -11,124 +11,6 @@
>  
>  /* -- */
>  
> -static int bochsfb_mmap(struct fb_info *info,
> - struct vm_area_struct *vma)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct bochs_bo *bo = gem_to_bochs_bo(fb_helper->fb->obj[0]);
> -
> - return ttm_fbdev_mmap(vma, &bo->bo);
> -}
> -
> -static struct fb_ops bochsfb_ops = {
> - .owner = THIS_MODULE,
> - DRM_FB_HELPER_DEFAULT_OPS,
> - .fb_fillrect = drm_fb_helper_cfb_fillrect,
> - .fb_copyarea = drm_fb_helper_cfb_copyarea,
> - .fb_imageblit = drm_fb_helper_cfb_imageblit,
> - .fb_mmap = bochsfb_mmap,
> -};
> -
> -static int bochsfb_create_object(struct bochs_device *bochs,
> -  const struct drm_mode_fb_cmd2 *mode_cmd,
> -  struct drm_gem_object **gobj_p)
> -{
> - struct drm_device *dev = bochs->dev;
> - struct drm_gem_object *gobj;
> - u32 size;
> - int ret = 0;
> -
> - size = mode_cmd->pitches[0] * mode_cmd->height;
> - ret = bochs_gem_create(dev, size, true, &gobj);
> - if (ret)
> - return ret;
> -
> - *gobj_p = gobj;
> - return ret;
> -}
> -
> -static int bochsfb_create(struct drm_fb_helper *helper,
> -   struct drm_fb_helper_surface_size *sizes)
> -{
> - struct bochs_device *bochs =
> - container_of(helper, struct bochs_device, fb.helper);
> - struct fb_info *info;
> - struct drm_framebuffer *fb;
> - struct drm_mode_fb_cmd2 mode_cmd;
> - struct drm_gem_object *gobj = NULL;
> - struct bochs_bo *bo = NULL;
> - int size, ret;
> -
> - if (sizes->surface_bpp != 32)
> - return -EINVAL;
> -
> - mode_cmd.width = sizes->surface_width;
> - mode_cmd.height = sizes->surface_height;
> - mode_cmd.pitches[0] = sizes->surface_width * 4;
> - mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
> - size = mode_cmd.pitches[0] * mode_cmd.heig

Re: [PATCH v5 06/20] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports

2019-01-10 Thread Daniel Vetter
On Tue, Jan 08, 2019 at 07:35:03PM -0500, Lyude Paul wrote:
> The current way of handling refcounting in the DP MST helpers is really
> confusing and probably just plain wrong because it's been hacked up many
> times over the years without anyone actually going over the code and
> seeing if things could be simplified.
> 
> To the best of my understanding, the current scheme works like this:
> drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
> this refcount hits 0 for either of the two, they're removed from the
> topology state, but not immediately freed. Both ports and branch devices
> will reinitialize their kref once it's hit 0 before actually destroying
> themselves. The intended purpose behind this is so that we can avoid
> problems like not being able to free a remote payload that might still
> be active, due to us having removed all of the port/branch device
> structures in memory, as per:
> 
> commit 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
> 
> Which may have worked, but then it caused use-after-free errors. Being
> new to MST at the time, I tried fixing it;
> 
> commit 263efde31f97 ("drm/dp/mst: Get validated port ref in 
> drm_dp_update_payload_part1()")
> 
> But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
> are validated in almost every DP MST helper function. Simply put, this
> means we go through the topology and try to see if the given
> drm_dp_mst_branch or drm_dp_mst_port is still attached to something
> before trying to use it in order to avoid dereferencing freed memory
> (something that has happened a LOT in the past with this library).
> Because of this it doesn't actually matter whether or not we keep keep
> the ports and branches around in memory as that's not enough, because
> any function that validates the branches and ports passed to it will
> still reject them anyway since they're no longer in the topology
> structure. So, use-after-free errors were fixed but payload deallocation
> was completely broken.
> 
> Two years later, AMD informed me about this issue and I attempted to
> come up with a temporary fix, pending a long-overdue cleanup of this
> library:
> 
> commit c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, 
> just ref")
> 
> But then that introduced use-after-free errors, so I quickly reverted
> it:
> 
> commit 9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during 
> destruction, just ref"")
> 
> And in the process, learned that there is just no simple fix for this:
> the design is just broken. Unfortunately, the usage of these helpers are
> quite broken as well. Some drivers like i915 have been smart enough to
> avoid accessing any kind of information from MST port structures, but
> others like nouveau have assumed, understandably so, that
> drm_dp_mst_port structures are normal and can just be accessed at any
> time without worrying about use-after-free errors.
> 
> After a lot of discussion, me and Daniel Vetter came up with a better
> idea to replace all of this.
> 
> To summarize, since this is documented far more indepth in the
> documentation this patch introduces, we make it so that drm_dp_mst_port
> and drm_dp_mst_branch structures have two different classes of
> refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
> the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
> given topology. Once it hits zero, any associated connectors are removed
> and the branch or port can no longer be validated. malloc_kref
> corresponds to the lifetime of the memory allocation for the actual
> structure, and will always be non-zero so long as the topology_kref is
> non-zero. This gives us a way to allow callers to hold onto port and
> branch device structures past their topology lifetime, and dramatically
> simplifies the lifetimes of both structures. This also finally fixes the
> port deallocation problem, properly.
> 
> Additionally: since this now means that we can keep ports and branch
> devices allocated in memory for however long we need, we no longer need
> a significant amount of the port validation that we currently do.
> 
> Additionally, there is one last scenario that this fixes, which couldn't
> have been fixed properly beforehand:
> 
> - CPU1 unrefs port from topology (refcount 1->0)
> - CPU2 refs port in topology(refcount 0->1)
> 
> Since we now can guarantee memory safety for ports and branches
> as-needed, we also can make our main reference counting functions fix
> this problem by using kref_get_unless_zero() internally so that topology
> refcounts can only ever reach 0 once.
> 
> Changes since v3:
> * Remove rebase detritus - danvet
> * Split out purely style changes into separate patches - hwentlan
> 
> Changes since v2:
> * Fix commit message - checkpatch
> * s/)-1/) - 1/g - checkpatch
> 
> Changes since v1:
> * Remove forward declarations - danvet
> * Move "Branch device and port refcounting" section from documentati

Re: [PATCH v5 04/20] drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi()

2019-01-10 Thread Daniel Vetter
On Tue, Jan 08, 2019 at 07:35:01PM -0500, Lyude Paul wrote:
> Split some stuff across multiple lines
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Juston Li 

On patches 1-4: Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index a63a4d32962a..75cca6a843fb 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2790,7 +2790,8 @@ EXPORT_SYMBOL(drm_dp_mst_reset_vcpi_slots);
>   * @mgr: manager for this port
>   * @port: unverified port to deallocate vcpi for
>   */
> -void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port)
> +void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_mst_port *port)
>  {
>   port = drm_dp_get_validated_port_ref(mgr, port);
>   if (!port)
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 07/20] drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails

2019-01-10 Thread Daniel Vetter
On Tue, Jan 08, 2019 at 07:35:04PM -0500, Lyude Paul wrote:
> While this isn't a complete fix, this will improve the reliability of
> drm_dp_get_last_connected_port_and_mstb() pretty significantly during
> hotplug events, since there's a chance that the in-memory topology tree
> may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
> is called and thus might end up causing our search to fail on an mstb
> whose topology refcount has reached 0, but has not yet been removed from
> it's parent.
> 
> Ideally, we should further fix this problem by ensuring that we deal
> with the potential for racing with a hotplug event, which would look
> like this:
> 
> * drm_dp_payload_send_msg() retrieves the last living relative of mstb
>   with drm_dp_get_last_connected_port_and_mstb()
> * drm_dp_payload_send_msg() starts building payload message
>   At the same time, mstb gets unplugged from the topology and is no
>   longer the actual last living relative of the original mstb
> * drm_dp_payload_send_msg() tries sending the payload message, hub times
>   out
> * Hub timed out, we give up and run away-resulting in the payload being
>   leaked
> 
> This could be fixed by restarting the
> drm_dp_get_last_connected_port_and_mstb() search whenever we get a
> timeout, sending the payload to the new mstb, then repeating until
> either the entire topology is removed from the system or
> drm_dp_get_last_connected_port_and_mstb() fails. But since the above
> race condition is not terribly likely, we'll address that in a later
> patch series once we've improved the recovery handling for VCPI
> allocations in the rest of the DP MST helpers.
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Juston Li 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 54 ++-
>  1 file changed, 44 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index c53cf7eb1dbc..bafc85f08606 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2047,24 +2047,50 @@ static struct drm_dp_mst_port 
> *drm_dp_get_last_connected_port_to_mstb(struct drm
>   return 
> drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
>  }
>  
> -static struct drm_dp_mst_branch 
> *drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
> -  struct 
> drm_dp_mst_branch *mstb,
> -  int 
> *port_num)
> +/**
> + * drm_dp_get_last_connected_port_and_mstb() - Find the last living relatives
> + * in a topology of a given branch device
> + * @mgr: The topology manager to use
> + * @mstb: The disconnected branch device
> + * @port_num: Where to store the number of the last connected port
> + *
> + * Searches upwards in the topology starting from @mstb to try to find the
> + * closest available parent of @mstb that's still connected to the rest of 
> the
> + * topology. This can be used in order to perform operations like releasing
> + * payloads, where the branch device which owned the payload may no longer be
> + * around and thus would require that the payload on the last living relative
> + * be freed instead.
> + *
> + * Returns:
> + * The last connected &drm_dp_mst_branch in the topology that was a parent of
> + * @mstb, if there is one.
> + */

Since this is an internal function and we don't pull it into the kerneldoc
there's a good chance the details will bitrot (since 0day won't spot when
e.g. the arguments change). It'd just keep a small explaining why we need
to do this and drop the other bits. Either way:

Reviewed-by: Daniel Vetter 


> +static struct drm_dp_mst_branch *
> +drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
> + struct drm_dp_mst_branch *mstb,
> + int *port_num)
>  {
>   struct drm_dp_mst_branch *rmstb = NULL;
>   struct drm_dp_mst_port *found_port;
> +
>   mutex_lock(&mgr->lock);
> - if (mgr->mst_primary) {
> + if (!mgr->mst_primary)
> + goto out;
> +
> + do {
>   found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
> + if (!found_port)
> + break;
>  
> - if (found_port) {
> + if (drm_dp_mst_topology_try_get_mstb(found_port->parent)) {
>   rmstb = found_port->parent;
> - if (drm_dp_mst_topology_try_get_mstb(rmstb))
> - *port_num = found_port->port_num;
> - else
> - rmstb = NULL;
> + *port_num = found_port->port_num;
> + } else {
> + /* Search again, starting from this parent */
> 

Re: [PATCH v5 08/20] drm/dp_mst: Stop releasing VCPI when removing ports from topology

2019-01-10 Thread Daniel Vetter
On Tue, Jan 08, 2019 at 07:35:05PM -0500, Lyude Paul wrote:
> This has never actually worked, and isn't needed anyway: the driver's
> always going to try to deallocate VCPI when it tears down the display
> that the VCPI belongs to.
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Juston Li 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index bafc85f08606..8088527a7aea 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1176,8 +1176,6 @@ static void drm_dp_destroy_port(struct kref *kref)
>   struct drm_dp_mst_topology_mgr *mgr = port->mgr;
>  
>   if (!port->input) {
> - port->vcpi.num_slots = 0;
> -
>   kfree(port->cached_edid);
>  
>   /*
> @@ -3496,12 +3494,6 @@ static void drm_dp_destroy_connector_work(struct 
> work_struct *work)
>   drm_dp_port_teardown_pdt(port, port->pdt);
>   port->pdt = DP_PEER_DEVICE_NONE;
>  
> - if (!port->input && port->vcpi.vcpi > 0) {
> - drm_dp_mst_reset_vcpi_slots(mgr, port);
> - drm_dp_update_payload_part1(mgr);
> - drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
> - }
> -
>   drm_dp_mst_put_port_malloc(port);
>   send_hotplug = true;
>   }
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm/fb-helper: Scale back depth to supported maximum

2019-01-10 Thread Linus Walleij
On Fri, Dec 28, 2018 at 5:05 PM Daniel Vetter  wrote:
> On Fri, Dec 28, 2018 at 4:40 PM Linus Walleij  
> wrote:

> > - Skip over YUV formats. The framebuffer emulation cannot
> >   handle these formats.
(...)
> > +   /* Do not consider YUV formats for framebuffers */
> > +   if (fmt->is_yuv)
>
> I think better to skip all funny formats with fmt->depth == 0. With that:
>
> Reviewed-by: Daniel Vetter 

I can easily make that change but this comment in the drm_fourcc.h
header makes me insecure:

/**
 * @depth:
 *
 * Color depth (number of bits per pixel excluding padding bits),
 * valid for a subset of RGB formats only. This is a legacy field, do
 * not use in new code and set to 0 for new formats.
 */
u8 depth;

This would mean that we make the framebuffer only support
"legacy formats". It might be that "legacy formats" include
all reasonable ones such as any RGB/BGA variants.

I will make the change and put in some comments about this
so it's clear.

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


[PATCH v3] drm/fb-helper: Scale back depth to supported maximum

2019-01-10 Thread Linus Walleij
The following happened when migrating an old fbdev driver to DRM:

The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.

This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns the same value
to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes
a 1-to-1 mapping between BPP and depth, which is true in most cases
but not for this hardware that only support odd formats.

To support the odd case of a driver supporting 16BPP with only 15
bits of depth, this patch will make the code loop over the formats
supported on the primary plane on each CRTC managed by the FB
helper and cap the depth to the maximum supported on any primary
plane.

On the PL110 Integrator, this makes drm_mode_legacy_fb_format()
select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and
thus we get framebuffer, penguin and console on the Integrator/CP.

Cc: Noralf Trønnes 
Cc: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebased and tested with v5.0-rc1
- Skip any formats with fmt->depth == 0
- Collected Daniels review tag.
ChangeLog v1->v2:
- Loop over the CRTCs managed by the helper and check the
  crtc->primary on each CRTC for the applicable formats and
  thus depths.
- Skip over YUV formats. The framebuffer emulation cannot
  handle these formats.

The v1 was sent some while back in february and I only recently
got back to fixing this up to support the last CLCD displays.
It was agreed that it is probably best to augment the framebuffer
initializer to pass a desired pixel format instead of just
BPP as today, but that is a bit daunting, and Daniel said that
we would probably anyways need a fallback like this.
---
 drivers/gpu/drm/drm_fb_helper.c | 53 -
 1 file changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d3af098b0922..e29432e486f4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1797,6 +1797,7 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
int i;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
+   int best_depth = 0;
 
memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -1804,7 +1805,10 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
sizes.fb_width = (u32)-1;
sizes.fb_height = (u32)-1;
 
-   /* if driver picks 8 or 16 by default use that for both depth/bpp */
+   /*
+* If driver picks 8 or 16 by default use that for both depth/bpp
+* to begin with
+*/
if (preferred_bpp != sizes.surface_bpp)
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
 
@@ -1839,6 +1843,53 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
}
}
 
+   /*
+* If we run into a situation where, for example, the primary plane
+* supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
+* 16) we need to scale down the depth of the sizes we request.
+*/
+   for (i = 0; i < fb_helper->crtc_count; i++) {
+   struct drm_mode_set *mode_set = 
&fb_helper->crtc_info[i].mode_set;
+   struct drm_crtc *crtc = mode_set->crtc;
+   struct drm_plane *plane = crtc->primary;
+   int j;
+
+   DRM_DEBUG("test CRTC %d primary plane\n", i);
+
+   for (j = 0; j < plane->format_count; j++) {
+   const struct drm_format_info *fmt;
+
+   fmt = drm_format_info(plane->format_types[j]);
+
+   /*
+* Do not consider YUV or other complicated formats
+* for framebuffers. This means only legacy formats
+* are supported (fmt->depth is a legacy field) but
+* the framebuffer emulation can only deal with such
+* formats, specifically RGB/BGA formats.
+*/
+   if (fmt->depth == 0)
+   continue;
+
+   /* We found a perfect fit, great */
+   if (fmt->depth == sizes.surface_depth)
+   break;
+
+   /* Skip depths above what we're looking for */
+   if (fmt->depth > sizes.surface_depth)
+   continue;
+
+   /* Best depth found so far */
+   if (fmt->depth > best_depth)
+   best_depth = fmt->depth;
+   }
+   }
+   if (sizes.surface_depth != best_depth) {
+   DRM_INFO("requested bpp %d, scaled dep

Re: [PATCH v5 17/20] drm/dp_mst: Add some atomic state iterator macros

2019-01-10 Thread Daniel Vetter
On Tue, Jan 08, 2019 at 07:35:14PM -0500, Lyude Paul wrote:
> Changes since v6:
>  - Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
>commit
>  - Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
>called directly
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c |  5 +-
>  include/drm/drm_dp_mst_helper.h   | 96 +++
>  2 files changed, 99 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index efd8fa29fff6..370371145cdd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3530,10 +3530,11 @@ static void drm_dp_mst_destroy_state(struct 
> drm_private_obj *obj,
>   kfree(mst_state);
>  }
>  
> -static const struct drm_private_state_funcs mst_state_funcs = {
> +const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs = {
>   .atomic_duplicate_state = drm_dp_mst_duplicate_state,
>   .atomic_destroy_state = drm_dp_mst_destroy_state,
>  };
> +EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
>  
>  /**
>   * drm_atomic_get_mst_topology_state: get MST topology state
> @@ -3617,7 +3618,7 @@ int drm_dp_mst_topology_mgr_init(struct 
> drm_dp_mst_topology_mgr *mgr,
>  
>   drm_atomic_private_obj_init(dev, &mgr->base,
>   &mst_state->base,
> - &mst_state_funcs);
> + &drm_dp_mst_topology_state_funcs);
>  
>   return 0;
>  }
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 8eca5f29242c..581163c8d7d7 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -650,4 +650,100 @@ int drm_dp_send_power_updown_phy(struct 
> drm_dp_mst_topology_mgr *mgr,
>  void drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port);
>  void drm_dp_mst_put_port_malloc(struct drm_dp_mst_port *port);
>  
> +extern const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs;
> +
> +/**
> + * __drm_dp_mst_state_iter_get - private atomic state iterator function for
> + * macro-internal use
> + * @state: &struct drm_atomic_state pointer
> + * @mgr: pointer to the &struct drm_dp_mst_topology_mgr iteration cursor
> + * @old_state: optional pointer to the old &struct drm_dp_mst_topology_state
> + * iteration cursor
> + * @new_state: optional pointer to the new &struct drm_dp_mst_topology_state
> + * iteration cursor
> + * @i: int iteration cursor, for macro-internal use
> + *
> + * Used by for_each_oldnew_mst_mgr_in_state(),
> + * for_each_old_mst_mgr_in_state(), and for_each_new_mst_mgr_in_state(). 
> Don't
> + * call this directly.
> + *
> + * Returns:
> + * True if the current &struct drm_private_obj is a &struct
> + * drm_dp_mst_topology_mgr, false otherwise.
> + */
> +static inline bool
> +__drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
> + struct drm_dp_mst_topology_mgr **mgr,
> + struct drm_dp_mst_topology_state **old_state,
> + struct drm_dp_mst_topology_state **new_state,
> + int i)
> +{
> + struct __drm_private_objs_state *objs_state = &state->private_objs[i];
> +
> + if (objs_state->ptr->funcs != &drm_dp_mst_topology_state_funcs)
> + return false;
> +
> + *mgr = to_dp_mst_topology_mgr(objs_state->ptr);
> + if (old_state)
> + *old_state = to_dp_mst_topology_state(objs_state->old_state);
> + if (new_state)
> + *new_state = to_dp_mst_topology_state(objs_state->new_state);
> +
> + return true;
> +}
> +
> +/**
> + * for_each_oldnew_mst_mgr_in_state - iterate over all DP MST topology
> + * managers in an atomic update
> + * @__state: &struct drm_atomic_state pointer
> + * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
> + * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
> + * state
> + * @new_state: &struct drm_dp_mst_topology_state iteration cursor for the new
> + * state
> + * @__i: int iteration cursor, for macro-internal use
> + *
> + * This iterates over all DRM DP MST topology managers in an atomic update,
> + * tracking both old and new state. This is useful in places where the state
> + * delta needs to be considered, for example in atomic check functions.
> + */
> +#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state, 
> __i) \
> + for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
> + for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
> &(old_state), &(new_state), (__i)))
> +
> +/**
> + * for_each_old_mst_mgr_in_state - iterate over all DP MST topology managers
> + * in an atomic update
> + * @__state: &struct drm_atomic_state pointer
> + 

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

2019-01-10 Thread Michel Dänzer
On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
> ARM systems do not permit the use of anything other than cached
> mappings for system memory, since that memory may be mapped in the
> linear region as well, and the architecture does not permit aliases
> with mismatched attributes.
> 
> So short-circuit the evaluation in ttm_io_prot() if the flags include
> TTM_PL_SYSTEM when running on ARM or arm64, and just return cached
> attributes immediately.
> 
> This fixes the radeon and amdgpu [TBC] drivers when running on arm64.
> Without this change, amdgpu does not start at all, and radeon only
> produces corrupt display output.
> 
> Cc: Christian Koenig 
> Cc: Huang Rui 
> Cc: Junwei Zhang 
> Cc: David Airlie 
> Reported-by: Carsten Haitzler 
> Signed-off-by: Ard Biesheuvel 
> ---
>  drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 046a6dda690a..0c1eef5f7ae3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
> tmp)
>   if (caching_flags & TTM_PL_FLAG_CACHED)
>   return tmp;
>  
> +#if defined(__arm__) || defined(__aarch64__)
> + /* ARM only permits cached mappings of system memory */
> + if (caching_flags & TTM_PL_SYSTEM)
> + return tmp;
> +#endif
>  #if defined(__i386__) || defined(__x86_64__)
>   if (caching_flags & TTM_PL_FLAG_WC)
>   tmp = pgprot_writecombine(tmp);
> 

Apart from Christian's concerns, I think this is the wrong place for
this, because other TTM / driver code will still consider the memory
uncacheable. E.g. the amdgpu driver will program the GPU to treat the
memory as uncacheable, so it won't participate in cache coherency
protocol for it, which is unlikely to work as expected in general if the
CPU treats the memory as cacheable.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 18/20] drm/dp_mst: Start tracking per-port VCPI allocations

2019-01-10 Thread Daniel Vetter
On Tue, Jan 08, 2019 at 07:35:15PM -0500, Lyude Paul wrote:
> There has been a TODO waiting for quite a long time in
> drm_dp_mst_topology.c:
> 
>   /* We cannot rely on port->vcpi.num_slots to update
>* topology_state->avail_slots as the port may not exist if the parent
>* branch device was unplugged. This should be fixed by tracking
>* per-port slot allocation in drm_dp_mst_topology_state instead of
>* depending on the caller to tell us how many slots to release.
>*/
> 
> That's not the only reason we should fix this: forcing the driver to
> track the VCPI allocations throughout a state's atomic check is
> error prone, because it means that extra care has to be taken with the
> order that drm_dp_atomic_find_vcpi_slots() and
> drm_dp_atomic_release_vcpi_slots() are called in in order to ensure
> idempotency. Currently the only driver actually using these helpers,
> i915, doesn't even do this correctly: multiple ->best_encoder() checks
> with i915's current implementation would not be idempotent and would
> over-allocate VCPI slots, something I learned trying to implement
> fallback retraining in MST.
> 
> So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots()
> and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for
> each port. This allows us to ensure idempotency without having to rely
> on the driver as much. Additionally: the driver doesn't need to do any
> kind of VCPI slot tracking anymore if it doesn't need it for it's own
> internal state.
> 
> Additionally; this adds a new drm_dp_mst_atomic_check() helper which
> must be used by atomic drivers to perform validity checks for the new
> VCPI allocations incurred by a state.
> 
> Also: update the documentation and make it more obvious that these
> /must/ be called by /all/ atomic drivers supporting MST.
> 
> Changes since v9:
> * Add some missing changes that were requested by danvet that I forgot
>   about after I redid all of the kref stuff:
>   * Remove unnecessary state changes in intel_dp_mst_atomic_check
>   * Cleanup atomic check logic for VCPI allocations - all we need to check in
> compute_config is whether or not this state disables a CRTC, then free
> VCPI based off that
> 
> Changes since v8:
>  * Fix compile errors, whoops!
> 
> Changes since v7:
>  - Don't check for mixed stale/valid VCPI allocations, just rely on
>  connector registration to stop such erroneous modesets
> 
> Changes since v6:
>  - Keep a kref to all of the ports we have allocations on. This required
>a good bit of changing to when we call drm_dp_find_vcpi_slots(),
>mainly that we need to ensure that we only redo VCPI allocations on
>actual mode or CRTC changes, not crtc_state->active changes.
>Additionally, we no longer take the registration of the DRM connector
>for each port into account because so long as we have a kref to the
>port in the new or previous atomic state, the connector will stay
>registered.
>  - Use the small changes to drm_dp_put_port() to add even more error
>checking to make misusage of the helpers more obvious. I added this
>after having to chase down various use-after-free conditions that
>started popping up from the new helpers so no one else has to
>troubleshoot that.
>  - Move some accidental DRM_DEBUG_KMS() calls to DRM_DEBUG_ATOMIC()
>  - Update documentation again, note that find/release() should both not be
>called on the same port in a single atomic check phase (but multiple
>calls to one or the other is OK)
> 
> Changes since v4:
>  - Don't skip the atomic checks for VCPI allocations if no new VCPI
>allocations happen in a state. This makes the next change I'm about
>to list here a lot easier to implement.
>  - Don't ignore VCPI allocations on destroyed ports, instead ensure that
>when ports are destroyed and still have VCPI allocations in the
>topology state, the only state changes allowed are releasing said
>ports' VCPI. This prevents a state with a mix of VCPI allocations
>from destroyed ports, and allocations from valid ports.
> 
> Changes since v3:
>  - Don't release VCPI allocations in the topology state immediately in
>drm_dp_atomic_release_vcpi_slots(), instead mark them as 0 and skip
>over them in drm_dp_mst_duplicate_state(). This makes it so
>drm_dp_atomic_release_vcpi_slots() is still idempotent while also
>throwing warnings if the driver messes up it's book keeping and tries
>to release VCPI slots on a port that doesn't have any pre-existing
>VCPI allocation - danvet
>  - Change mst_state/state in some debugging messages to "mst state"
> 
> Changes since v2:
>  - Use kmemdup() for duplicating MST state - danvet
>  - Move port validation out of duplicate state callback - danvet
>  - Handle looping through MST topology states in
>drm_dp_mst_atomic_check() so the driver doesn't have to do it
>  - Fix documentation in drm_dp_atomic_find_vcpi_

Re: [PATCH v5 19/20] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()

2019-01-10 Thread Daniel Vetter
On Tue, Jan 08, 2019 at 07:35:16PM -0500, Lyude Paul wrote:
> It occurred to me that we never actually check this! So let's start
> doing that.
> 
> Signed-off-by: Lyude Paul 
> Reviewed-by: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jerry Zuo 
> Cc: Harry Wentland 
> Cc: Juston Li 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index fc778c6d487e..41cf814207bf 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3650,7 +3650,7 @@ drm_dp_mst_atomic_check_topology_state(struct 
> drm_dp_mst_topology_mgr *mgr,
>  struct drm_dp_mst_topology_state 
> *mst_state)
>  {
>   struct drm_dp_vcpi_allocation *vcpi;
> - int avail_slots = 63;
> + int avail_slots = 63, payload_count = 0;
>  
>   list_for_each_entry(vcpi, &mst_state->vcpis, next) {
>   /* Releasing VCPI is always OK-even if the port is gone */
> @@ -3670,6 +3670,12 @@ drm_dp_mst_atomic_check_topology_state(struct 
> drm_dp_mst_topology_mgr *mgr,
>avail_slots + vcpi->vcpi);
>   return -ENOSPC;
>   }
> +
> + if (++payload_count > mgr->max_payloads) {
> + DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many 
> payloads (max=%d)\n",
> +  mgr, mst_state, mgr->max_payloads);
> + return -EINVAL;
> + }
>   }
>   DRM_DEBUG_ATOMIC("[MST MGR:%p] mst state %p VCPI avail=%d used=%d\n",
>mgr, mst_state, avail_slots,
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100239] Incorrect rendering in CS:GO

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100239

--- Comment #18 from network...@rkmail.ru ---
Is this bug still being worked on?

The problem is still here, but there's a little update: sometimes texture gets
cleared correctly. 

Currently running Mesa git master 31e4c9ce400341df9b0136419b3b3c73b8c9eb7e

-- 
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] drm/fb-helper: Scale back depth to supported maximum

2019-01-10 Thread Daniel Vetter
On Thu, Jan 10, 2019 at 10:19 AM Linus Walleij  wrote:
>
> On Fri, Dec 28, 2018 at 5:05 PM Daniel Vetter  wrote:
> > On Fri, Dec 28, 2018 at 4:40 PM Linus Walleij  
> > wrote:
>
> > > - Skip over YUV formats. The framebuffer emulation cannot
> > >   handle these formats.
> (...)
> > > +   /* Do not consider YUV formats for framebuffers */
> > > +   if (fmt->is_yuv)
> >
> > I think better to skip all funny formats with fmt->depth == 0. With that:
> >
> > Reviewed-by: Daniel Vetter 
>
> I can easily make that change but this comment in the drm_fourcc.h
> header makes me insecure:
>
> /**
>  * @depth:
>  *
>  * Color depth (number of bits per pixel excluding padding bits),
>  * valid for a subset of RGB formats only. This is a legacy field, do
>  * not use in new code and set to 0 for new formats.
>  */
> u8 depth;
>
> This would mean that we make the framebuffer only support
> "legacy formats". It might be that "legacy formats" include
> all reasonable ones such as any RGB/BGA variants.

Yeah it's not a perfect fit either, but there's a lot non-yuv format
that are very special, and checking for ->depth excludes them. And yes
all the usual rgb/bga formats have bpp/depth descriptions. That's also
all that the fbdev format stuff can describe. Long term we maybe want
to switch over to directly using the format fourcc (and -EINVAL the
ones we don't understand), because atm we're shrugging the bgr vs rgb
difference under the rug.

Cheers, Daniel

> I will make the change and put in some comments about this
> so it's clear.
>
> Yours,
> Linus Walleij



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

2019-01-10 Thread Michel Dänzer

Hi Christoph,


https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct code". Any ideas?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 14/15] drm/bochs: drop old fbdev emulation code

2019-01-10 Thread Gerd Hoffmann
  Hi,

> > -   drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 1);
> 
> The generic fbdev emulation doesn't take care of suspend/resume. You
> could do this:
> drm_fb_helper_set_suspend_unlocked(drm_dev->fb_helper, 1);

Additional to drm_mode_config_helper_suspend() I assume?
Does the call order matter?

> > drm_helper_resume_force_mode(drm_dev);
> 
> The docs for this function has this to say:
> * This function is deprecated. New drivers should implement atomic mode-
> * setting and use the atomic suspend/resume helpers.
> 
> Maybe you can use drm_mode_config_helper_suspend/resume() instead like
> suggested in the drm_fbdev_generic_setup() docs.

That should work, yes.  The driver is simple enough ;)

cheers,
  Gerd

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


[PATCH] drm/crtc-helpers: WARN when used with atomic drivers

2019-01-10 Thread Daniel Vetter
Motivated by an oversight of mine when looking at the atomic bochs
conversion. For consistency also switch over to the same style as used
elsewhere (e.g. in drm_mode_set_config_internal).

Cc: Gerd Hoffmann 
Cc: Noralf Trønnes 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc_helper.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 23159eb494f1..91dc9b6386e7 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -93,6 +93,8 @@ bool drm_helper_encoder_in_use(struct drm_encoder *encoder)
struct drm_connector_list_iter conn_iter;
struct drm_device *dev = encoder->dev;
 
+   WARN_ON(drm_drv_uses_atomic_modeset(dev));
+
/*
 * We can expect this mutex to be locked if we are not panicking.
 * Locking is currently fubar in the panic handler.
@@ -131,6 +133,8 @@ bool drm_helper_crtc_in_use(struct drm_crtc *crtc)
struct drm_encoder *encoder;
struct drm_device *dev = crtc->dev;
 
+   WARN_ON(drm_drv_uses_atomic_modeset(dev));
+
/*
 * We can expect this mutex to be locked if we are not panicking.
 * Locking is currently fubar in the panic handler.
@@ -212,8 +216,7 @@ static void __drm_helper_disable_unused_functions(struct 
drm_device *dev)
  */
 void drm_helper_disable_unused_functions(struct drm_device *dev)
 {
-   if (drm_core_check_feature(dev, DRIVER_ATOMIC))
-   DRM_ERROR("Called for atomic driver, this is not what you 
want.\n");
+   WARN_ON(drm_drv_uses_atomic_modeset(dev));
 
drm_modeset_lock_all(dev);
__drm_helper_disable_unused_functions(dev);
@@ -281,6 +284,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
struct drm_encoder *encoder;
bool ret = true;
 
+   WARN_ON(drm_drv_uses_atomic_modeset(dev));
+
drm_warn_on_modeset_not_all_locked(dev);
 
saved_enabled = crtc->enabled;
@@ -540,6 +545,9 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
 
crtc_funcs = set->crtc->helper_private;
 
+   dev = set->crtc->dev;
+   WARN_ON(drm_drv_uses_atomic_modeset(dev));
+
if (!set->mode)
set->fb = NULL;
 
@@ -555,8 +563,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
return 0;
}
 
-   dev = set->crtc->dev;
-
drm_warn_on_modeset_not_all_locked(dev);
 
/*
@@ -875,6 +881,8 @@ int drm_helper_connector_dpms(struct drm_connector 
*connector, int mode)
struct drm_crtc *crtc = encoder ? encoder->crtc : NULL;
int old_dpms, encoder_dpms = DRM_MODE_DPMS_OFF;
 
+   WARN_ON(drm_drv_uses_atomic_modeset(connector->dev));
+
if (mode == connector->dpms)
return 0;
 
@@ -946,6 +954,8 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
int encoder_dpms;
bool ret;
 
+   WARN_ON(drm_drv_uses_atomic_modeset(dev));
+
drm_modeset_lock_all(dev);
drm_for_each_crtc(crtc, dev) {
 
-- 
2.20.0.rc1

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


Re: [PATCH (resend)] gpu/drm: Fix lock held when returning to user space.

2019-01-10 Thread Daniel Vetter
On Thu, Jan 10, 2019 at 07:19:31PM +0900, Tetsuo Handa wrote:
> We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc()
> failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc()
> succeeded.
> 
> Signed-off-by: Tetsuo Handa 
> Reported-by: syzbot 

Queued for 5.0, thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 3 +--
>  drivers/gpu/drm/drm_mode_object.c | 4 ++--
>  2 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index c408898..9a1f41a 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1296,12 +1296,11 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>   return -EINVAL;
>  
> - drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> -
>   state = drm_atomic_state_alloc(dev);
>   if (!state)
>   return -ENOMEM;
>  
> + drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>   state->acquire_ctx = &ctx;
>   state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
>  
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index cd9bc0c..004191d 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -459,11 +459,11 @@ static int set_property_atomic(struct drm_mode_object 
> *obj,
>   struct drm_modeset_acquire_ctx ctx;
>   int ret;
>  
> - drm_modeset_acquire_init(&ctx, 0);
> -
>   state = drm_atomic_state_alloc(dev);
>   if (!state)
>   return -ENOMEM;
> +
> + drm_modeset_acquire_init(&ctx, 0);
>   state->acquire_ctx = &ctx;
>  retry:
>   if (prop == state->dev->mode_config.dpms_property) {
> -- 
> 1.8.3.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH (resend)] gpu/drm: Fix lock held when returning to user space.

2019-01-10 Thread Tetsuo Handa
We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc()
failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc()
succeeded.

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 3 +--
 drivers/gpu/drm/drm_mode_object.c | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c408898..9a1f41a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1296,12 +1296,11 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
(arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
return -EINVAL;
 
-   drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
-
state = drm_atomic_state_alloc(dev);
if (!state)
return -ENOMEM;
 
+   drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
state->acquire_ctx = &ctx;
state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
 
diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index cd9bc0c..004191d 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -459,11 +459,11 @@ static int set_property_atomic(struct drm_mode_object 
*obj,
struct drm_modeset_acquire_ctx ctx;
int ret;
 
-   drm_modeset_acquire_init(&ctx, 0);
-
state = drm_atomic_state_alloc(dev);
if (!state)
return -ENOMEM;
+
+   drm_modeset_acquire_init(&ctx, 0);
state->acquire_ctx = &ctx;
 retry:
if (prop == state->dev->mode_config.dpms_property) {
-- 
1.8.3.1

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


Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed

2019-01-10 Thread Priit Laes
On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote:
> Currently MP clocks don't consider adjusting parent rate even if they
> are allowed to do so. Such behaviour considerably lowers amount of
> possible rates, which is very inconvenient when such clock is used for
> pixel clock, for example.
> 
> In order to improve the situation, adjusting parent rate is considered
> when allowed.
> 
> This code is inspired by clk_divider_bestdiv() function, which does
> basically the same thing for different clock type.

This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC boards:

EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem
EXT4-fs (mmcblk1p4): write access will be enabled during recovery
sunxi-mmc 1c11000.mmc: data error, sending stop command
sunxi-mmc 1c11000.mmc: send stop command failed


$ git bisect log
git bisect start
# good: [3df407b2a5346db1c48809706ece7a8616c79e0b] mmc: dw_mmc-bluefield: 
simplify the probe() function
git bisect good 3df407b2a5346db1c48809706ece7a8616c79e0b
# bad: [00d59fde8532b2d42e80909d2e58678755e04da9] Merge tag 'mmc-v4.21' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
git bisect bad 00d59fde8532b2d42e80909d2e58678755e04da9
# good: [01e421feec0817bb3141eaae4c517410d193d440] Merge branch 'fixes' into 
next
git bisect good 01e421feec0817bb3141eaae4c517410d193d440
# bad: [1eefdec18eded41833401cfd64749643ff72e7da] Merge branch 
'locking-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 1eefdec18eded41833401cfd64749643ff72e7da
# good: [eaa76499711535fd64d747cc4ef0d78ab0fd41c6] Merge tag 'mtd/for-4.21' of 
git://git.infradead.org/linux-mtd
git bisect good eaa76499711535fd64d747cc4ef0d78ab0fd41c6
# good: [4e4390ad067a61ce4e7607bd0df31f19a4caa36a] Merge tag 
'leds-for-4.21-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
git bisect good 4e4390ad067a61ce4e7607bd0df31f19a4caa36a
# bad: [c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next
git bisect bad c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698
# bad: [e4b99d415c3908581d4703203e1e805f043a3e71] Merge branch 
'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad e4b99d415c3908581d4703203e1e805f043a3e71
# bad: [ffe05540d18013db62c43627836a3638e9a2c7aa] Merge branches 'clk-renesas', 
'clk-allwinner', 'clk-tegra', 'clk-meson' and 'clk-rockchip' into clk-next
git bisect bad ffe05540d18013db62c43627836a3638e9a2c7aa
# good: [1a501c8defe950571316d5ddd917bf44f5ed7bd4] Merge branches 
'clk-managed-registration', 'clk-spdx', 'clk-remove-basic' and 'clk-ops-const' 
into clk-next
git bisect good 1a501c8defe950571316d5ddd917bf44f5ed7bd4
# good: [e74581b79ddd9b49b8c61e2791fc4dffc0245afb] Merge tag 'meson-clk-4.21-2' 
of https://github.com/BayLibre/clk-meson into clk-meson
git bisect good e74581b79ddd9b49b8c61e2791fc4dffc0245afb
# good: [60baf75e3f5b76043c25328ac0c5320aaef5ea41] Merge tag 
'clk-renesas-for-v4.21-tag2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into 
clk-renesas
git bisect good 60baf75e3f5b76043c25328ac0c5320aaef5ea41
# bad: [a41f85b6017ee20952a60e4330bcae2527fe2c2a] Merge tag 
'sunxi-clk-for-4.21' of 
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into clk-allwinner
git bisect bad a41f85b6017ee20952a60e4330bcae2527fe2c2a
# bad: [ee678706e46d0d185c27cc214ad97828e0643159] clk: sunxi-ng: a64: Fix gate 
bit of DSI DPHY
git bisect bad ee678706e46d0d185c27cc214ad97828e0643159
# bad: [65b6657672388b72822e0367f06d41c1e3ffb5bb] clk: sunxi-ng: Use u64 for 
calculation of NM rate
git bisect bad 65b6657672388b72822e0367f06d41c1e3ffb5bb
# good: [db7548934603d9eda12649dff97ea5c29884405d] clk: sunxi-ng: sun50i: h6: 
Fix MMC clock mux width
git bisect good db7548934603d9eda12649dff97ea5c29884405d
# bad: [3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15] clk: sunxi-ng: Adjust MP 
clock parent rate when allowed
git bisect bad 3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15
# first bad commit: [3f790433c3cb27ecaf2ca0e07ac25964e4fd9f15] clk: sunxi-ng: 
Adjust MP clock parent rate when allowed


> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/clk/sunxi-ng/ccu_mp.c | 64 +--
>  1 file changed, 62 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
> index 5d0af4051737..0357349eb767 100644
> --- a/drivers/clk/sunxi-ng/ccu_mp.c
> +++ b/drivers/clk/sunxi-ng/ccu_mp.c
> @@ -40,6 +40,61 @@ static void ccu_mp_find_best(unsigned long parent, 
> unsigned long rate,
>   *p = best_p;
>  }
>  
> +static unsigned long ccu_mp_find_best_with_parent_adj(struct clk_hw *hw,
> +   unsigned long *parent,
> +   unsigned long rate,
> +   unsigned int max_m,
> +  

[Bug 108464] System fails to reboot after Ctrl-Alt-Del

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108464

--- Comment #17 from Duncan Roe  ---
Created attachment 143055
  --> https://bugs.freedesktop.org/attachment.cgi?id=143055&action=edit
dmesg o/p with diags after applying attachment 143011

The line before the BUG line shows a null pointer

-- 
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: [v4 05/12] drm: Add HDR capability field to plane structure

2019-01-10 Thread Liviu Dudau
Hi Uma,

On Tue, Jan 08, 2019 at 02:41:20PM +0530, Uma Shankar wrote:
> Hardware may have HDR capability on certain plane
> engines. Enabling the same in drm plane structure
> so that this can be communicated to user space.
> 
> Each drm driver should set this flag to true for planes
> which support HDR.
> 
> v2: Rebase
> 
> Signed-off-by: Uma Shankar 
> ---
>  include/drm/drm_plane.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 6078c70..206eefc 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -638,6 +638,9 @@ struct drm_plane {
>   /** @type: Type of plane, see &enum drm_plane_type for details. */
>   enum drm_plane_type type;
>  
> + /* Value of true:1 means HDR is supported */
> + bool hdr_supported;
> +

I don't see where this is used, am I missing something? You attach the property
to the connector, I don't see how the planes get involved in the end.

Best regards,
Liviu


>   /**
>* @index: Position inside the mode_config.list, can be used as an array
>* index. It is invariant over the lifetime of the plane.
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
   
  ||___
  \   |  With enough courage, you can do without a reputation  |  /
   \  |  -- Rhett Butler   | /
   /  || \
  /__)  (_\
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [v4 01/12] drm: Add HDR source metadata property

2019-01-10 Thread Liviu Dudau
On Tue, Jan 08, 2019 at 02:41:16PM +0530, Uma Shankar wrote:
> This patch adds a blob property to get HDR metadata
> information from userspace. This will be send as part
> of AVI Infoframe to panel.
> 
> v2: Rebase and modified the metadata structure elements
> as per Ville's POC changes.
> 
> v3: No Change
> 
> v4: Addressed Shashank's review comments
> 
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_connector.c |  6 ++
>  include/drm/drm_connector.h | 10 ++
>  include/drm/drm_mode_config.h   |  6 ++
>  include/linux/hdmi.h| 10 ++
>  include/uapi/drm/drm_mode.h | 16 
>  5 files changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8475396..78dd38f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1027,6 +1027,12 @@ int drm_connector_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.non_desktop_property = prop;
>  
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> +"HDR_OUTPUT_METADATA", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.hdr_source_metadata_property = prop;

Further down in the patch the member is called hdr_output_metadata_property and 
I cannot
find where hdr_source_metadata_property is defined in drm_mode_config. Does 
this patch
even compile?

> +
>   return 0;
>  }
>  
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index f82701d..4ce74f3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -520,6 +520,13 @@ struct drm_connector_state {
>* and the connector bpc limitations obtained from edid.
>*/
>   u8 max_bpc;
> +
> + /**
> +  * @metadata_blob_ptr:
> +  * DRM blob property for HDR output metadata
> +  */
> + struct drm_property_blob *hdr_output_metadata_blob_ptr;
> + u8 hdr_metadata_changed : 1;
>  };
>  
>  /**
> @@ -1154,6 +1161,9 @@ struct drm_connector {
>* &drm_mode_config.connector_free_work.
>*/
>   struct llist_node free_node;
> +
> + /* HDR metdata */
> + struct hdr_static_metadata hdr_metadata;
>  };
>  
>  #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 1e6cb88..5fff4aa 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -836,6 +836,12 @@ struct drm_mode_config {
>*/
>   struct drm_property *writeback_out_fence_ptr_property;
>  
> + /*
> +  * hdr_metadata_property: Connector property containing hdr metatda

s/metatda/metadata/

> +  * This will be provided by userspace compositors based on HDR content
> +  */
> + struct drm_property *hdr_output_metadata_property;
> +
>   /* dumb ioctl parameters */
>   uint32_t preferred_depth, prefer_shadow;
>  
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index d2bacf5..bed3e08 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -137,6 +137,16 @@ enum hdmi_content_type {
>   HDMI_CONTENT_TYPE_GAME,
>  };
>  
> +enum hdmi_metadata_type {
> + HDMI_STATIC_METADATA_TYPE1 = 1,
> +};

Should the metadata_type enum be a more global structure, and not HDMI 
specific, but only
the first value gets assigned to HDMI_STATIC_METADATA_TYPE1 ?

Best regards,
Liviu

> +
> +enum hdmi_eotf {
> + HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
> + HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
> + HDMI_EOTF_SMPTE_ST2084,
> +};
> +
>  struct hdmi_avi_infoframe {
>   enum hdmi_infoframe_type type;
>   unsigned char version;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index a439c2e..5012af2 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -630,6 +630,22 @@ struct drm_color_lut {
>   __u16 reserved;
>  };
>  
> +/* HDR Metadata */
> +struct hdr_static_metadata {
> + uint8_t eotf;
> + uint8_t metadata_type;
> + struct {
> + uint16_t x, y;
> + } display_primaries[3];
> + struct {
> + uint16_t x, y;
> + } white_point;
> + uint16_t max_mastering_display_luminance;
> + uint16_t min_mastering_display_luminance;
> + uint16_t max_fall;
> + uint16_t max_cll;
> +};
> +
>  #define DRM_MODE_PAGE_FLIP_EVENT 0x01
>  #define DRM_MODE_PAGE_FLIP_ASYNC 0x02
>  #define DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
   
  ||___
  \   |  With enough courage, you can d

[Bug 108464] System fails to reboot after Ctrl-Alt-Del

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108464

--- Comment #18 from Duncan Roe  ---
Mixed results on applying this patch.
IN BRIEF: If you could eliminate this second Oops then we can see what works
and what doesn't.
In the meantime with the patch applied to v4.20 in the stable repository:
reboot *sometimes* works. Ctl-Alt-Del w/out logging in seems not to. Log in as
root and issue reboot cmd: no. Well it did work for me a couple of times but I
can't seem to be able to do it again.
Another thing: I boot to command level. If I let the VC time out (backlight
goes off) then I can never wake it again no matter what keys I press. Caps Lock
light goes on and off, so keyboard is still active.
Hopefully this all gets better once there is no Oops.
Attachment 143055 pinpoints the immediate NULL pointer. Again this is a new
aux_engine.

-- 
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] drm/crtc-helpers: WARN when used with atomic drivers

2019-01-10 Thread Gerd Hoffmann
On Thu, Jan 10, 2019 at 11:30:45AM +0100, Daniel Vetter wrote:
> Motivated by an oversight of mine when looking at the atomic bochs
> conversion. For consistency also switch over to the same style as used
> elsewhere (e.g. in drm_mode_set_config_internal).
> 
> Cc: Gerd Hoffmann 
> Cc: Noralf Trønnes 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Gerd Hoffmann 

> ---
>  drivers/gpu/drm/drm_crtc_helper.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index 23159eb494f1..91dc9b6386e7 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -93,6 +93,8 @@ bool drm_helper_encoder_in_use(struct drm_encoder *encoder)
>   struct drm_connector_list_iter conn_iter;
>   struct drm_device *dev = encoder->dev;
>  
> + WARN_ON(drm_drv_uses_atomic_modeset(dev));
> +
>   /*
>* We can expect this mutex to be locked if we are not panicking.
>* Locking is currently fubar in the panic handler.
> @@ -131,6 +133,8 @@ bool drm_helper_crtc_in_use(struct drm_crtc *crtc)
>   struct drm_encoder *encoder;
>   struct drm_device *dev = crtc->dev;
>  
> + WARN_ON(drm_drv_uses_atomic_modeset(dev));
> +
>   /*
>* We can expect this mutex to be locked if we are not panicking.
>* Locking is currently fubar in the panic handler.
> @@ -212,8 +216,7 @@ static void __drm_helper_disable_unused_functions(struct 
> drm_device *dev)
>   */
>  void drm_helper_disable_unused_functions(struct drm_device *dev)
>  {
> - if (drm_core_check_feature(dev, DRIVER_ATOMIC))
> - DRM_ERROR("Called for atomic driver, this is not what you 
> want.\n");
> + WARN_ON(drm_drv_uses_atomic_modeset(dev));
>  
>   drm_modeset_lock_all(dev);
>   __drm_helper_disable_unused_functions(dev);
> @@ -281,6 +284,8 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>   struct drm_encoder *encoder;
>   bool ret = true;
>  
> + WARN_ON(drm_drv_uses_atomic_modeset(dev));
> +
>   drm_warn_on_modeset_not_all_locked(dev);
>  
>   saved_enabled = crtc->enabled;
> @@ -540,6 +545,9 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>  
>   crtc_funcs = set->crtc->helper_private;
>  
> + dev = set->crtc->dev;
> + WARN_ON(drm_drv_uses_atomic_modeset(dev));
> +
>   if (!set->mode)
>   set->fb = NULL;
>  
> @@ -555,8 +563,6 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set,
>   return 0;
>   }
>  
> - dev = set->crtc->dev;
> -
>   drm_warn_on_modeset_not_all_locked(dev);
>  
>   /*
> @@ -875,6 +881,8 @@ int drm_helper_connector_dpms(struct drm_connector 
> *connector, int mode)
>   struct drm_crtc *crtc = encoder ? encoder->crtc : NULL;
>   int old_dpms, encoder_dpms = DRM_MODE_DPMS_OFF;
>  
> + WARN_ON(drm_drv_uses_atomic_modeset(connector->dev));
> +
>   if (mode == connector->dpms)
>   return 0;
>  
> @@ -946,6 +954,8 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
>   int encoder_dpms;
>   bool ret;
>  
> + WARN_ON(drm_drv_uses_atomic_modeset(dev));
> +
>   drm_modeset_lock_all(dev);
>   drm_for_each_crtc(crtc, dev) {
>  
> -- 
> 2.20.0.rc1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 14/15] drm/bochs: drop old fbdev emulation code

2019-01-10 Thread Noralf Trønnes


Den 10.01.2019 11.16, skrev Gerd Hoffmann:
>   Hi,
> 
>>> -   drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 1);
>>
>> The generic fbdev emulation doesn't take care of suspend/resume. You
>> could do this:
>> drm_fb_helper_set_suspend_unlocked(drm_dev->fb_helper, 1);
> 
> Additional to drm_mode_config_helper_suspend() I assume?

No, sorry for the confusion. I didn't know if you could use
drm_mode_config_helper_suspend() or not. That function takes care of
fbdev suspend as well:

int drm_mode_config_helper_suspend(struct drm_device *dev)
{
<...>
drm_kms_helper_poll_disable(dev);
drm_fb_helper_set_suspend_unlocked(dev->fb_helper, 1);
state = drm_atomic_helper_suspend(dev);
<...>
}


> Does the call order matter?
> 
>>> drm_helper_resume_force_mode(drm_dev);
>>
>> The docs for this function has this to say:
>> * This function is deprecated. New drivers should implement atomic mode-
>> * setting and use the atomic suspend/resume helpers.
>>
>> Maybe you can use drm_mode_config_helper_suspend/resume() instead like
>> suggested in the drm_fbdev_generic_setup() docs.
> 
> That should work, yes.  The driver is simple enough ;)
> 
> cheers,
>   Gerd
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/virtio: drop prime import/export callbacks

2019-01-10 Thread Gerd Hoffmann
Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
userspace.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  4 
 drivers/gpu/drm/virtio/virtgpu_drv.c   |  4 
 drivers/gpu/drm/virtio/virtgpu_prime.c | 14 --
 3 files changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index cf896d8793..4f2f3c43a4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -354,10 +354,6 @@ int virtio_gpu_object_wait(struct virtio_gpu_object *bo, 
bool no_wait);
 /* virtgpu_prime.c */
 int virtgpu_gem_prime_pin(struct drm_gem_object *obj);
 void virtgpu_gem_prime_unpin(struct drm_gem_object *obj);
-struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
-struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
-   struct drm_device *dev, struct dma_buf_attachment *attach,
-   struct sg_table *sgt);
 void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj);
 void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index af92964b68..b996ac1d4f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -205,14 +205,10 @@ static struct drm_driver driver = {
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = virtio_gpu_debugfs_init,
 #endif
-   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = virtgpu_gem_prime_pin,
.gem_prime_unpin = virtgpu_gem_prime_unpin,
-   .gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
-   .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
.gem_prime_vmap = virtgpu_gem_prime_vmap,
.gem_prime_vunmap = virtgpu_gem_prime_vunmap,
.gem_prime_mmap = virtgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 86ce0ae93f..c59ec34c80 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -39,20 +39,6 @@ void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
WARN_ONCE(1, "not implemented");
 }
 
-struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
-   WARN_ONCE(1, "not implemented");
-   return ERR_PTR(-ENODEV);
-}
-
-struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
-   struct drm_device *dev, struct dma_buf_attachment *attach,
-   struct sg_table *table)
-{
-   WARN_ONCE(1, "not implemented");
-   return ERR_PTR(-ENODEV);
-}
-
 void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj)
 {
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
-- 
2.9.3

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


[PATCH v4] drm/fb-helper: Scale back depth to supported maximum

2019-01-10 Thread Linus Walleij
The following happened when migrating an old fbdev driver to DRM:

The Integrator/CP PL111 supports 16BPP but only ARGB1555/ABGR1555
or XRGB1555/XBGR1555 i.e. the maximum depth is 15.

This makes the initialization of the framebuffer fail since
the code in drm_fb_helper_single_fb_probe() assigns the same value
to sizes.surface_bpp and sizes.surface_depth. I.e. it simply assumes
a 1-to-1 mapping between BPP and depth, which is true in most cases
but not for this hardware that only support odd formats.

To support the odd case of a driver supporting 16BPP with only 15
bits of depth, this patch will make the code loop over the formats
supported on the primary plane on each CRTC managed by the FB
helper and cap the depth to the maximum supported on any primary
plane.

On the PL110 Integrator, this makes drm_mode_legacy_fb_format()
select DRM_FORMAT_XRGB1555 which is acceptable for this driver, and
thus we get framebuffer, penguin and console on the Integrator/CP.

Cc: Noralf Trønnes 
Cc: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Linus Walleij 
---
ChangeLog v3->v4:
- Assign best_depth also when we have a perfect fit, duh.
ChangeLog v2->v3:
- Rebased and tested with v5.0-rc1
- Skip any formats with fmt->depth == 0
- Collected Daniels review tag.
ChangeLog v1->v2:
- Loop over the CRTCs managed by the helper and check the
  crtc->primary on each CRTC for the applicable formats and
  thus depths.
- Skip over YUV formats. The framebuffer emulation cannot
  handle these formats.

The v1 was sent some while back in february and I only recently
got back to fixing this up to support the last CLCD displays.
It was agreed that it is probably best to augment the framebuffer
initializer to pass a desired pixel format instead of just
BPP as today, but that is a bit daunting, and Daniel said that
we would probably anyways need a fallback like this.
---
 drivers/gpu/drm/drm_fb_helper.c | 55 -
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d3af098b0922..f7f31ad5d3ee 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1797,6 +1797,7 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
int i;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
+   int best_depth = 0;
 
memset(&sizes, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
@@ -1804,7 +1805,10 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
sizes.fb_width = (u32)-1;
sizes.fb_height = (u32)-1;
 
-   /* if driver picks 8 or 16 by default use that for both depth/bpp */
+   /*
+* If driver picks 8 or 16 by default use that for both depth/bpp
+* to begin with
+*/
if (preferred_bpp != sizes.surface_bpp)
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
 
@@ -1839,6 +1843,55 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
}
}
 
+   /*
+* If we run into a situation where, for example, the primary plane
+* supports RGBA5551 (16 bpp, depth 15) but not RGB565 (16 bpp, depth
+* 16) we need to scale down the depth of the sizes we request.
+*/
+   for (i = 0; i < fb_helper->crtc_count; i++) {
+   struct drm_mode_set *mode_set = 
&fb_helper->crtc_info[i].mode_set;
+   struct drm_crtc *crtc = mode_set->crtc;
+   struct drm_plane *plane = crtc->primary;
+   int j;
+
+   DRM_DEBUG("test CRTC %d primary plane\n", i);
+
+   for (j = 0; j < plane->format_count; j++) {
+   const struct drm_format_info *fmt;
+
+   fmt = drm_format_info(plane->format_types[j]);
+
+   /*
+* Do not consider YUV or other complicated formats
+* for framebuffers. This means only legacy formats
+* are supported (fmt->depth is a legacy field) but
+* the framebuffer emulation can only deal with such
+* formats, specifically RGB/BGA formats.
+*/
+   if (fmt->depth == 0)
+   continue;
+
+   /* We found a perfect fit, great */
+   if (fmt->depth == sizes.surface_depth) {
+   best_depth = fmt->depth;
+   break;
+   }
+
+   /* Skip depths above what we're looking for */
+   if (fmt->depth > sizes.surface_depth)
+   continue;
+
+   /* Best depth found so far */
+   if (fmt->depth > best_depth)
+  

RE: [v4 05/12] drm: Add HDR capability field to plane structure

2019-01-10 Thread Shankar, Uma


>-Original Message-
>From: Liviu Dudau [mailto:li...@dudau.co.uk]
>Sent: Thursday, January 10, 2019 4:17 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala, 
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v4 05/12] drm: Add HDR capability field to plane structure
>
>Hi Uma,
>
>On Tue, Jan 08, 2019 at 02:41:20PM +0530, Uma Shankar wrote:
>> Hardware may have HDR capability on certain plane engines. Enabling
>> the same in drm plane structure so that this can be communicated to
>> user space.
>>
>> Each drm driver should set this flag to true for planes which support
>> HDR.
>>
>> v2: Rebase
>>
>> Signed-off-by: Uma Shankar 
>> ---
>>  include/drm/drm_plane.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index
>> 6078c70..206eefc 100644
>> --- a/include/drm/drm_plane.h
>> +++ b/include/drm/drm_plane.h
>> @@ -638,6 +638,9 @@ struct drm_plane {
>>  /** @type: Type of plane, see &enum drm_plane_type for details. */
>>  enum drm_plane_type type;
>>
>> +/* Value of true:1 means HDR is supported */
>> +bool hdr_supported;
>> +
>
>I don't see where this is used, am I missing something? You attach the 
>property to
>the connector, I don't see how the planes get involved in the end.

Hi Liviu,
Yes currently it's not linked to plane, but I am planning to add a property 
interface which tells
userspace what underlying hardware planes are capable of HDR. For now, this is 
not used and
I can drop it to avoid any confusion. Will be sending out the plane capability 
property for HDR
pretty soon (most probably along with next version of this series).

Regards,
Uma Shankar

>Best regards,
>Liviu
>
>
>>  /**
>>   * @index: Position inside the mode_config.list, can be used as an array
>>   * index. It is invariant over the lifetime of the plane.
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>   
>  ||___
>  \   |  With enough courage, you can do without a reputation  |  /
>   \  |  -- Rhett Butler   | /
>   /  || \
>  /__)  (_\
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/4] drm/damage-helper: Add drm_atomic_helper_damage_merged()

2019-01-10 Thread Noralf Trønnes


Den 09.01.2019 18.49, skrev Noralf Trønnes:
> Useful for drivers that only care about the combined damage.
> 
> Cc: Deepak Rawat 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_damage_helper.c | 43 +
>  include/drm/drm_damage_helper.h |  3 ++
>  2 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_damage_helper.c 
> b/drivers/gpu/drm/drm_damage_helper.c
> index d2a1c7372f36..4ddf1b41a852 100644
> --- a/drivers/gpu/drm/drm_damage_helper.c
> +++ b/drivers/gpu/drm/drm_damage_helper.c
> @@ -332,3 +332,46 @@ drm_atomic_helper_damage_iter_next(struct 
> drm_atomic_helper_damage_iter *iter,
>   return ret;
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_damage_iter_next);
> +
> +/**
> + * drm_atomic_helper_damage_merged - Merged plane damage
> + * @old_state: Old plane state for validation.
> + * @state: Plane state from which to iterate the damage clips.
> + * @rect: Returns the merged damage rectangle
> + *
> + * This function merges any valid plane damage clips into one rectangle and
> + * returns it in @rect. It also clears the plane damage.
> + *
> + * For details see: drm_atomic_helper_damage_iter_init() and
> + * drm_atomic_helper_damage_iter_next().
> + *
> + * Returns:
> + * True if there is valid plane damage otherwise false.
> + */
> +bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
> +  struct drm_plane_state *state,
> +  struct drm_rect *rect)
> +{
> + struct drm_atomic_helper_damage_iter iter;
> + struct drm_rect clip;
> + bool valid = false;
> +
> + rect->x1 = INT_MAX;
> + rect->y1 = INT_MAX;
> + rect->x2 = 0;
> + rect->y2 = 0;
> +
> + drm_atomic_helper_damage_iter_init(&iter, old_state, state);
> + drm_atomic_for_each_plane_damage(&iter, &clip) {
> + rect->x1 = min(rect->x1, clip.x1);
> + rect->y1 = min(rect->y1, clip.y1);
> + rect->x2 = max(rect->x2, clip.x2);
> + rect->y2 = max(rect->y2, clip.y2);
> + valid = true;
> + }
> +
> + drm_property_replace_blob(&state->fb_damage_clips, NULL);

This clearing isn't necessary, it happens in plane state
duplicate/destroy. I had missed fix up commit c75ff001f4fe ("drm: Put
damage blob when destroy plane state").
I will amend this in the next version.

Noralf.

> +
> + return valid;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_damage_merged);
> diff --git a/include/drm/drm_damage_helper.h b/include/drm/drm_damage_helper.h
> index 4487660b26b8..40c34a5bf149 100644
> --- a/include/drm/drm_damage_helper.h
> +++ b/include/drm/drm_damage_helper.h
> @@ -78,6 +78,9 @@ drm_atomic_helper_damage_iter_init(struct 
> drm_atomic_helper_damage_iter *iter,
>  bool
>  drm_atomic_helper_damage_iter_next(struct drm_atomic_helper_damage_iter 
> *iter,
>  struct drm_rect *rect);
> +bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
> +  struct drm_plane_state *state,
> +  struct drm_rect *rect);
>  
>  /**
>   * drm_helper_get_plane_damage_clips - Returns damage clips in &drm_rect.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 109281] [CI][SHARDS] igt@gem_ctx_isolation@* - skip - WARNING: GEN not recognized!

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109281

Martin Peres  changed:

   What|Removed |Added

 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
  Component|DRM/Intel   |IGT
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org

--- Comment #1 from Martin Peres  ---
Should be an IGT bug, sorry for the noise!

-- 
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 109281] [CI][SHARDS] igt@gem_ctx_isolation@* - skip - WARNING: GEN not recognized!

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109281

--- Comment #2 from CI Bug Log  ---
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* ICL: igt@gem_ctx_isolation@* - skip - WARNING: GEN not recognized!
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_ctx_isolat...@rcs0-clean.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-switch.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_ctx_isolat...@vcs0-clean.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_ctx_isolat...@vecs0-s3.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_ctx_isolat...@vcs0-none.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_ctx_isolat...@rcs0-dirty-create.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_ctx_isolat...@vcs1-none.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_ctx_isolat...@vcs0-dirty-create.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@bcs0-dirty-create.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@rcs0-reset.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@vcs1-s3.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@vecs0-reset.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@rcs0-none.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@rcs0-s3.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@vcs0-dirty-switch.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@bcs0-clean.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@vcs1-dirty-create.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@vcs0-s3.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@vcs1-reset.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@vecs0-dirty-switch.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_ctx_isolat...@vecs0-none.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_ctx_isolat...@bcs0-none.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_ctx_isolat...@vcs1-clean.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_ctx_isolat...@rcs0-dirty-switch.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_ctx_isolat...@bcs0-dirty-switch.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_ctx_isolat...@bcs0-s3.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_ctx_isolat...@bcs0-reset.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_ctx_isolat...@vecs0-clean.html

-- 
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: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

2019-01-10 Thread Christoph Hellwig
On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> 
> Hi Christoph,
> 
> 
> https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
> bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
> into the dma_direct code". Any ideas?

From the trace it looks like we git the case where swiotlb tries
to copy back data from a bounce buffer, but hits a dangling or NULL
pointer.  So a couple questions for the submitter:

 - does the system have more than 4GB memory and thus use swiotlb?
   (check /proc/meminfo, and if something SWIOTLB appears in dmesg)
 - does the device this happens on have a DMA mask smaller than
   the available memory, that is should swiotlb be used here to start
   with?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

2019-01-10 Thread Christian König

Am 10.01.19 um 14:57 schrieb Christoph Hellwig:

On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:

Hi Christoph,


https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
into the dma_direct code". Any ideas?

 From the trace it looks like we git the case where swiotlb tries
to copy back data from a bounce buffer, but hits a dangling or NULL
pointer.  So a couple questions for the submitter:

  - does the system have more than 4GB memory and thus use swiotlb?
(check /proc/meminfo, and if something SWIOTLB appears in dmesg)
  - does the device this happens on have a DMA mask smaller than
the available memory, that is should swiotlb be used here to start
with?


Rather unlikely. The device is an AMD GPU, so we can address memory up 
to 1TB.


Christian.


___
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


[PULL v2] drm-misc-fixes

2019-01-10 Thread Maarten Lankhorst
Hi Dave/Daniel,

Some patches were pushed today to drm-misc-fixes, and I think it would be nice
if they are part of the pull req for v5.0-rc2. :)

drm-misc-fixes-2019-01-10-1:
Second pull request, drm-misc-fixes for v5.0-rc2:
- Fix fb-helper to work correctly with SDL 1.2 bugs.
- Fix lockdep warning in the atomic ioctl and setproperty.
From first pull request:
- Fixes for the tc358767 bridge to work correctly with
  tc358867 using a DP connector.
- Make resume work on amdgpu when a DP-MST display is unplugged.
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:

  Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-01-10-1

for you to fetch changes up to 4089e272ac61603931beb024d4d640de2cb390e0:

  gpu/drm: Fix lock held when returning to user space. (2019-01-10 11:31:58 
+0100)


Second pull request, drm-misc-fixes for v5.0-rc2:
- Fix fb-helper to work correctly with SDL 1.2 bugs.
- Fix lockdep warning in the atomic ioctl and setproperty.
From first pull request:
- Fixes for the tc358767 bridge to work correctly with
  tc358867 using a DP connector.
- Make resume work on amdgpu when a DP-MST display is unplugged.


Ivan Mironov (2):
  drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2
  drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock

Lyude Paul (3):
  drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()
  drm/amdgpu: Don't fail resume process if resuming atomic state fails
  drm/dp_mst: Add __must_check to drm_dp_mst_topology_mgr_resume()

Tetsuo Handa (1):
  gpu/drm: Fix lock held when returning to user space.

Tomi Valkeinen (7):
  drm/bridge: tc358767: add bus flags
  drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
  drm/bridge: tc358767: fix single lane configuration
  drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
  drm/bridge: tc358767: reject modes which require too much BW
  drm/bridge: tc358767: fix output H/V syncs
  drm/bridge: tc358767: use DP connector if no panel set

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  37 --
 drivers/gpu/drm/bridge/tc358767.c |  48 ++--
 drivers/gpu/drm/drm_atomic_uapi.c |   3 +-
 drivers/gpu/drm/drm_fb_helper.c   | 133 +-
 drivers/gpu/drm/drm_mode_object.c |   4 +-
 include/drm/drm_dp_mst_helper.h   |   3 +-
 6 files changed, 147 insertions(+), 81 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

2019-01-10 Thread Christoph Hellwig
On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
>>  From the trace it looks like we git the case where swiotlb tries
>> to copy back data from a bounce buffer, but hits a dangling or NULL
>> pointer.  So a couple questions for the submitter:
>>
>>   - does the system have more than 4GB memory and thus use swiotlb?
>> (check /proc/meminfo, and if something SWIOTLB appears in dmesg)
>>   - does the device this happens on have a DMA mask smaller than
>> the available memory, that is should swiotlb be used here to start
>> with?
>
> Rather unlikely. The device is an AMD GPU, so we can address memory up to 
> 1TB.

So we probably somehow got a false positive.

For now I'like the reported to confirm that the dma_direct_unmap_page+0x92
backtrace really is in the swiotlb code (I can't think of anything else,
but I'd rather be sure).

Second it would be great to print what the contents of io_tlb_start
and io_tlb_end are, e.g. by doing a printk_once in is_swiotlb_buffer,
maybe that gives a clue why we are hitting the swiotlb code here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] drm/amdgpu: set bulk_moveable to false when lru changed

2019-01-10 Thread Chunming Zhou
if lru is changed, we cannot do bulk moving.

Change-Id: Ide0fe920295cc25f7cabcf41a6400519e5783f2a
Signed-off-by: Chunming Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  | 20 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h  |  2 ++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index c91ec3101d00..a610aacdc772 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1546,7 +1546,8 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_free = &amdgpu_ttm_io_mem_free,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
-   .access_memory = &amdgpu_ttm_access_memory
+   .access_memory = &amdgpu_ttm_access_memory,
+   .lru_notify = &amdgpu_vm_lru_notify
 };
 
 /*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index e73d152659a2..be73a94d4f4f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -623,6 +623,26 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
list_add(&entry->tv.head, validated);
 }
 
+void amdgpu_vm_lru_notify(struct ttm_buffer_object *bo)
+{
+   struct amdgpu_bo *abo;
+   struct amdgpu_vm_bo_base *bo_base;
+
+   if (!amdgpu_bo_is_amdgpu_bo(bo))
+   return;
+
+   if (bo->mem.placement & TTM_PL_FLAG_NO_EVICT)
+   return;
+
+   abo = ttm_to_amdgpu_bo(bo);
+   for (bo_base = abo->vm_bo; bo_base; bo_base = bo_base->next) {
+   struct amdgpu_vm *vm = bo_base->vm;
+
+   if (abo->tbo.resv == vm->root.base.bo->tbo.resv)
+   vm->bulk_moveable = false;
+   }
+
+}
 /**
  * amdgpu_vm_move_to_lru_tail - move all BOs to the end of LRU
  *
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index e8dcfd59fc93..1de4d3a2debd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -363,4 +363,6 @@ int amdgpu_vm_add_fault(struct amdgpu_retryfault_hashtable 
*fault_hash, u64 key)
 
 void amdgpu_vm_clear_fault(struct amdgpu_retryfault_hashtable *fault_hash, u64 
key);
 
+void amdgpu_vm_lru_notify(struct ttm_buffer_object *bo);
+
 #endif
-- 
2.17.1

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


[PATCH 1/2] drm/ttm: add lru notify to bo driver

2019-01-10 Thread Chunming Zhou
allow driver do somethings when lru changed.

Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
Signed-off-by: Chunming Zhou 
---
 drivers/gpu/drm/ttm/ttm_bo.c| 11 +++
 include/drm/ttm/ttm_bo_driver.h |  9 +
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0ec08394e17a..ed79ea0291b7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -198,19 +198,22 @@ static void ttm_bo_ref_bug(struct kref *list_kref)
 
 void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
 {
+   struct ttm_bo_device *bdev = bo->bdev;
+   bool notify = false;
+
if (!list_empty(&bo->swap)) {
list_del_init(&bo->swap);
kref_put(&bo->list_kref, ttm_bo_ref_bug);
+   notify = true;
}
if (!list_empty(&bo->lru)) {
list_del_init(&bo->lru);
kref_put(&bo->list_kref, ttm_bo_ref_bug);
+   notify = true;
}
 
-   /*
-* TODO: Add a driver hook to delete from
-* driver-specific LRU's here.
-*/
+   if (notify && bdev->driver->lru_notify)
+   bdev->driver->lru_notify(bo);
 }
 
 void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 1021106438b2..85a9b97e1c9d 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -381,6 +381,15 @@ struct ttm_bo_driver {
 */
int (*access_memory)(struct ttm_buffer_object *bo, unsigned long offset,
 void *buf, int len, int write);
+
+   /**
+* struct ttm_bo_driver member lru_notify
+*
+* @bo: the buffer object to be add
+*
+* send lru changed event to driver.
+*/
+   void (*lru_notify)(struct ttm_buffer_object *bo);
 };
 
 /**
-- 
2.17.1

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


Re: [PATCH 1/2] drm/ttm: add lru notify to bo driver

2019-01-10 Thread Michel Dänzer
On 2019-01-10 3:52 p.m., Chunming Zhou wrote:
> allow driver do somethings when lru changed.
> 
> Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
> Signed-off-by: Chunming Zhou 
> 
> [...]
>  
>  void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 1021106438b2..85a9b97e1c9d 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -381,6 +381,15 @@ struct ttm_bo_driver {
>*/
>   int (*access_memory)(struct ttm_buffer_object *bo, unsigned long offset,
>void *buf, int len, int write);
> +
> + /**
> +  * struct ttm_bo_driver member lru_notify
> +  *
> +  * @bo: the buffer object to be add

If I understand the code changes correctly, this should rather say
something like "the buffer object which was deleted from LRU"...


> +  * send lru changed event to driver.

... this should say something like "notify driver that a BO was deleted
from LRU"...


> + void (*lru_notify)(struct ttm_buffer_object *bo);

... and this should be named something like del_from_lru_notify, for
clarity.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 109290] [CI][SHARDS] igt@gem_pwrite@huge-cpu - skip - Estimated that we need \d+ objects and \d+ MiB for the test, but only have \d+ MiB available \(RAM\) and a maximum of \d+ objects

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109290

Bug ID: 109290
   Summary: [CI][SHARDS] igt@gem_pwrite@huge-cpu - skip -
Estimated that we need \d+ objects and \d+ MiB for the
test, but only have \d+ MiB available \(RAM\) and a
maximum of \d+ objects
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: martin.pe...@free.fr

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_pwr...@huge-gtt-backwards.html

Starting subtest: huge-gtt-backwards
Test requirement not met in function intel_require_memory, file
../lib/intel_os.c:410:
Test requirement: sufficient_memory
Estimated that we need 1 objects and 268435457 MiB for the test, but only have
15378 MiB available (RAM) and a maximum of 1617252 objects
Subtest huge-gtt-backwards: SKIP (0.308s)

I think we should simply skip on having a 48-bit GTT.

-- 
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 109290] [CI][SHARDS] igt@gem_pwrite@huge-cpu - skip - Estimated that we need 1 objects and 268435457 MiB for the test, but only have 15378 MiB available (RAM) and a maximum of 1617252 objects

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109290

Martin Peres  changed:

   What|Removed |Added

Summary|[CI][SHARDS]|[CI][SHARDS]
   |igt@gem_pwrite@huge-cpu -   |igt@gem_pwrite@huge-cpu -
   |skip - Estimated that we|skip - Estimated that we
   |need \d+ objects and \d+|need 1 objects and
   |MiB for the test, but only  |268435457 MiB for the test,
   |have \d+ MiB available  |but only have 15378 MiB
   |\(RAM\) and a maximum of|available (RAM) and a
   |\d+ objects |maximum of 1617252 objects

-- 
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 109290] [CI][SHARDS] igt@gem_pwrite@huge-cpu - skip - Estimated that we need \d+ objects and \d+ MiB for the test, but only have \d+ MiB available \(RAM\) and a maximum of \d+ objects

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109290

--- Comment #1 from CI Bug Log  ---
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* ICL: igt@gem_pwrite@huge-cpu - skip - Estimated that we need \d+ objects and
\d+ MiB for the test, but only have \d+ MiB available \(RAM\) and a maximum of
...
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_pwr...@huge-cpu-fbr.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_pwr...@huge-cpu-forwards.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_pwr...@huge-cpu-random.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_pwr...@huge-cpu-backwards.html

-- 
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 109290] [CI][SHARDS] igt@gem_pwrite@huge-cpu - skip - Estimated that we need 1 objects and 268435457 MiB for the test, but only have 15378 MiB available (RAM) and a maximum of 1617252 objects

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109290

--- Comment #2 from CI Bug Log  ---
A CI Bug Log filter associated to this bug has been updated:

{- ICL: igt@gem_pwrite@huge-cpu - skip - Estimated that we need \d+ objects and
\d+ MiB for the test, but only have \d+ MiB available \(RAM\) and a maximum of
... -}
{+ ICL: igt@gem_pwrite@huge-* - skip - Estimated that we need \d+ objects and
\d+ MiB for the test, but only have \d+ MiB available \(RAM\) and a maximum of
... +}

New failures caught by the filter:

*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_pwr...@huge-gtt-backwards.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/igt@gem_pwr...@huge-gtt-random.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_pwr...@huge-gtt-forwards.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_pwr...@huge-gtt-fbr.html

-- 
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] drm: add DRM_DEBUG_CORE() and friends and use them

2019-01-10 Thread Jani Nikula
On Thu, 27 Dec 2018, Jani Nikula  wrote:
> DRM_DEBUG() was intended to be used by the drm core code only, but we
> weren't careful. Today, the driver usage of DRM_DEBUG() trumps drm core
> usage about 10:1. It's easier to swith the core over to a new
> DRM_DEBUG_CORE() macro than the drivers over to DRM_DEBUG_DRIVER().
>
> Do the same for DRM_DEV_DEBUG() and the ratelimited ones as well.

Any thoughts on this one? Or should we just decide we don't need to
distinguish between core and drivers? Or should we move towards dev
based logging altogether?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 109290] [CI][SHARDS] igt@gem_pwrite@huge-cpu - skip - Estimated that we need 1 objects and 268435457 MiB for the test, but only have 15378 MiB available (RAM) and a maximum of 1617252 objects

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109290

--- Comment #3 from Chris Wilson  ---
Nah. Give me a machine with 49-bits of memory and I want to test what happens
if we have a full 48-bit GTT. (Not that it really matters, since the
interesting GTT is the global one, mappable vs non-mappable at a stretch
limits.)

-- 
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 109161] Kernel crash shortly after gnome-shell login - refcount_t: increment on 0; use-after-free

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109161

--- Comment #7 from Michel Dänzer  ---
(In reply to mikhail.v.gavrilov from comment #5)
> Looks like I hurried to report that all is well.
> With prolonged working, hangs still happens.

This looks like a separate issue, see bug 109234 and follow-ups to
https://lists.freedesktop.org/archives/dri-devel/2019-January/202909.html .

-- 
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 109290] [CI][SHARDS] igt@gem_pwrite@huge-cpu - skip - Estimated that we need 1 objects and 268435457 MiB for the test, but only have 15378 MiB available (RAM) and a maximum of 1617252 objects

2019-01-10 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109290

--- Comment #4 from CI Bug Log  ---
A CI Bug Log filter associated to this bug has been updated:

{- ICL: igt@gem_pwrite@huge-* - skip - Estimated that we need \d+ objects and
\d+ MiB for the test, but only have \d+ MiB available \(RAM\) and a maximum of
... -}
{+ ICL: igt@* - skip - Estimated that we need \d+ objects and \d+ MiB for the
test, but only have \d+ MiB available \(RAM\) and a maximum of ... +}

New failures caught by the filter:

*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb5/igt@gem_exec_big.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_userptr_bl...@coherency-sync.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb6/igt@gem_userptr_bl...@coherency-unsync.html

-- 
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 v5 1/2] drm/sched: Refactor ring mirror list handling.

2019-01-10 Thread Grodzovsky, Andrey
Just a ping.

Andrey


On 01/09/2019 10:18 AM, Andrey Grodzovsky wrote:
>
>
> On 01/09/2019 05:22 AM, Christian König wrote:
>> Am 07.01.19 um 20:47 schrieb Grodzovsky, Andrey:
>>>
>>> On 01/07/2019 09:13 AM, Christian König wrote:
 Am 03.01.19 um 18:42 schrieb Grodzovsky, Andrey:
> On 01/03/2019 11:20 AM, Grodzovsky, Andrey wrote:
>> On 01/03/2019 03:54 AM, Koenig, Christian wrote:
>>> Am 21.12.18 um 21:36 schrieb Grodzovsky, Andrey:
 On 12/21/2018 01:37 PM, Christian König wrote:
> Am 20.12.18 um 20:23 schrieb Andrey Grodzovsky:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>> from non signaled HW fenes wait for all signaled HW fences
>> to complete before rerunning the jobs.
>>
>> v2: Fix resubmission of guilty job into HW after refactoring.
>>
>> v4:
>> Full restart for all the jobs, not only from guilty ring.
>> Extract karma increase into standalone function.
>>
>> v5:
>> Rework waiting for signaled jobs without relying on the job
>> struct itself as those might already be freed for non 'guilty'
>> job's schedulers.
>> Expose karma increase to drivers.
>>
>> Suggested-by: Christian Koenig 
>> Signed-off-by: Andrey Grodzovsky 
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  18 +--
>>    drivers/gpu/drm/etnaviv/etnaviv_sched.c |  11 +-
>>    drivers/gpu/drm/scheduler/sched_main.c | 188
>> +++--
>>    drivers/gpu/drm/v3d/v3d_sched.c |  12 +-
>>    include/drm/gpu_scheduler.h |  10 +-
>>    5 files changed, 151 insertions(+), 88 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 8a078f4..a4bd2d3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3298,12 +3298,10 @@ static int
>> amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>>    if (!ring || !ring->sched.thread)
>>    continue;
>>    - kthread_park(ring->sched.thread);
>> +    drm_sched_stop(&ring->sched, job ? &job->base : NULL);
>>    -    if (job && job->base.sched != &ring->sched)
>> -    continue;
>> -
>> - drm_sched_hw_job_reset(&ring->sched, job ? &job->base :
>> NULL);
>> +    if(job)
>> + drm_sched_increase_karma(&job->base);
> Since we dropped the "job && job->base.sched != &ring->sched" 
> check
> above this will now increase the jobs karma multiple times.
>
> Maybe just move that outside of the loop.
>
>>      /* after all hw jobs are reset, hw fence is
>> meaningless,
>> so force_completion */
>> amdgpu_fence_driver_force_completion(ring);
>> @@ -3454,14 +3452,10 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>>    if (!ring || !ring->sched.thread)
>>    continue;
>>    -    /* only need recovery sched of the given 
>> job's ring
>> - * or all rings (in the case @job is NULL)
>> - * after above amdgpu_reset accomplished
>> - */
>> -    if ((!job || job->base.sched == &ring->sched) &&
>> !adev->asic_reset_res)
>> - drm_sched_job_recovery(&ring->sched);
>> +    if (!adev->asic_reset_res)
>> + drm_sched_resubmit_jobs(&ring->sched);
>>    - kthread_unpark(ring->sched.thread);
>> +    drm_sched_start(&ring->sched, !adev->asic_reset_res);
>>    }
>>      if (!amdgpu_device_has_dc_support(adev)) {
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> index 49a6763..6f1268f 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> @@ -109,16 +109,19 @@ static void 
>> etnaviv_sched_timedout_job(struct
>> drm_sched_job *sched_job)
>>    }
>>      /* block scheduler */
>> -    kthread_park(gpu->sched.thread);
>> -    drm_sched_hw_job_reset(&gpu->sched, sched_job);
>> +    drm_sched_stop(&gpu->sched, sched_job);
>> +
>> +    if(sched_job)
>> +    drm_sched_increase_karma(sched_job);
>>      /* get the GPU back into the init state

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

2019-01-10 Thread Konrad Rzeszutek Wilk
On Thu, Jan 10, 2019 at 04:26:43PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 14:57, Christoph Hellwig  wrote:
> >
> > On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote:
> > >
> > > Hi Christoph,
> > >
> > >
> > > https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was
> > > bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops
> > > into the dma_direct code". Any ideas?
> >
> > From the trace it looks like we git the case where swiotlb tries
> > to copy back data from a bounce buffer, but hits a dangling or NULL
> > pointer.  So a couple questions for the submitter:
> My apologies if I misunderstand something, this subject matter is new to me.
> 
> >
> >  - does the system have more than 4GB memory and thus use swiotlb?
> My system has 8GB memory. The other report on the bug tracker had 16GB.
> 
> >(check /proc/meminfo, and if something SWIOTLB appears in dmesg)
> /proc/meminfo: https://ptpb.pw/4rxI
> Can I grep dmesg for a string?

Can you attach the 'dmesg'? 

> 
> >  - does the device this happens on have a DMA mask smaller than
> >the available memory, that is should swiotlb be used here to start
> >with?
> It's a MSI Radeon RX 570 Gaming X 4GB. The other report was a RX 580.
> lshw output: https://ptpb.pw/6s0H
> 
> 
> Regards,
> 
> Sibren
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 1/7] drm: msm: Cleanup drm_display_mode print str

2019-01-10 Thread Shayenne Moura
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in msm files.

Signed-off-by: Shayenne Moura 
---
Changes in v2:
  - Use DRM_MODE_FMT/ARG macros (Daniel).
  - Make the commit message more clear

Changes in v3:
  - Resolve typo in v2 patch

 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 10 ++
 drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c  |  9 +
 drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c  |  9 +
 drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c |  9 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c  |  9 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  9 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c  |  9 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  9 +
 drivers/gpu/drm/msm/edp/edp_bridge.c  |  9 +
 9 files changed, 10 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index 457c29dba4a1..7b028f778960 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -244,14 +244,8 @@ static void mdp4_crtc_mode_set_nofb(struct drm_crtc *crtc)
 
mode = &crtc->state->adjusted_mode;
 
-   DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mdp4_crtc->name, mode->base.id, mode->name,
-   mode->vrefresh, mode->clock,
-   mode->hdisplay, mode->hsync_start,
-   mode->hsync_end, mode->htotal,
-   mode->vdisplay, mode->vsync_start,
-   mode->vsync_end, mode->vtotal,
-   mode->type, mode->flags);
+   DBG("%s: set mode: " DRM_MODE_FMT,
+   mdp4_crtc->name, DRM_MODE_ARG(mode));
 
mdp4_write(mdp4_kms, REG_MDP4_DMA_SRC_SIZE(dma),
MDP4_DMA_SRC_SIZE_WIDTH(mode->hdisplay) |
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
index 6a1ebdace391..48ce218b8463 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c
@@ -58,14 +58,7 @@ static void mdp4_dsi_encoder_mode_set(struct drm_encoder 
*encoder,
 
mode = adjusted_mode;
 
-   DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mode->base.id, mode->name,
-   mode->vrefresh, mode->clock,
-   mode->hdisplay, mode->hsync_start,
-   mode->hsync_end, mode->htotal,
-   mode->vdisplay, mode->vsync_start,
-   mode->vsync_end, mode->vtotal,
-   mode->type, mode->flags);
+   DBG("set mode: " DRM_MODE_FMT, DRM_MODE_ARG(mode));
 
ctrl_pol = 0;
if (mode->flags & DRM_MODE_FLAG_NHSYNC)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
index ba8e587f734b..f6bc86a35d8d 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_dtv_encoder.c
@@ -104,14 +104,7 @@ static void mdp4_dtv_encoder_mode_set(struct drm_encoder 
*encoder,
 
mode = adjusted_mode;
 
-   DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mode->base.id, mode->name,
-   mode->vrefresh, mode->clock,
-   mode->hdisplay, mode->hsync_start,
-   mode->hsync_end, mode->htotal,
-   mode->vdisplay, mode->vsync_start,
-   mode->vsync_end, mode->vtotal,
-   mode->type, mode->flags);
+   DBG("set mode: " DRM_MODE_FMT, DRM_MODE_ARG(mode));
 
mdp4_dtv_encoder->pixclock = mode->clock * 1000;
 
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
index 2bfb39082f54..d47b8f4af991 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c
@@ -273,14 +273,7 @@ static void mdp4_lcdc_encoder_mode_set(struct drm_encoder 
*encoder,
 
mode = adjusted_mode;
 
-   DBG("set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   mode->base.id, mode->name,
-   mode->vrefresh, mode->clock,
-   mode->hdisplay, mode->hsync_start,
-   mode->hsync_end, mode->htotal,
-   mode->vdisplay, mode->vsync_start,
-   mode->vsync_end, mode->vtotal,
-   mode->type, mode->flags);
+   DBG("set mode: " DRM_MODE_FMT, DRM_MODE_ARG(mode));
 
mdp4_lcdc_encoder->pixclock = mode->clock * 1000;
 
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c 
b/drivers/gpu/d

[PATCH v3 2/7] drm: omapdrm: Cleanup drm_display_mode print str

2019-01-10 Thread Shayenne Moura
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in omapdrm files.

Signed-off-by: Shayenne Moura 
Reviewed-by: Sebastian Reichel 

---
Changes in v2:
  - Use DRM_MODE_FMT/ARG macros (Daniel)
  - Make the commit message more clear

Changes in v3:
  - No changes

 drivers/gpu/drm/omapdrm/omap_connector.c | 9 ++---
 drivers/gpu/drm/omapdrm/omap_crtc.c  | 8 ++--
 2 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index b81302c4bf9e..874d8f3cbff6 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -305,14 +305,9 @@ static int omap_connector_mode_valid(struct drm_connector 
*connector,
drm_mode_destroy(dev, new_mode);
 
 done:
-   DBG("connector: mode %s: "
-   "%d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
+   DBG("connector: mode %s: " DRM_MODE_FMT,
(ret == MODE_OK) ? "valid" : "invalid",
-   mode->base.id, mode->name, mode->vrefresh, mode->clock,
-   mode->hdisplay, mode->hsync_start,
-   mode->hsync_end, mode->htotal,
-   mode->vdisplay, mode->vsync_start,
-   mode->vsync_end, mode->vtotal, mode->type, mode->flags);
+   DRM_MODE_ARG(mode));
 
return ret;
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index caffc547ef97..40acf4ce7c9f 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -427,12 +427,8 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
 
-   DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
-   omap_crtc->name, mode->base.id, mode->name,
-   mode->vrefresh, mode->clock,
-   mode->hdisplay, mode->hsync_start, mode->hsync_end, mode->htotal,
-   mode->vdisplay, mode->vsync_start, mode->vsync_end, mode->vtotal,
-   mode->type, mode->flags);
+   DBG("%s: set mode: " DRM_MODE_FMT,
+   omap_crtc->name, DRM_MODE_ARG(mode));
 
drm_display_mode_to_videomode(mode, &omap_crtc->vm);
 }
-- 
2.17.1

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


[PATCH v3 3/7] drm: meson: Cleanup on drm_display_mode print str

2019-01-10 Thread Shayenne Moura
This patch adjust the print string of drm_display_mode object
to remove drm_mode_object dependency in meson files.

Signed-off-by: Shayenne Moura 
---
Changes in v2:
  - Use DRM_MODE_FMT/ARG macros (Daniel)
  - Make the commit message more clear

Changes in v3:
  - No changes

 drivers/gpu/drm/meson/meson_dw_hdmi.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index d8c5cc34e22e..0b6c29cdd934 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -365,7 +365,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
*data,
unsigned int wr_clk =
readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
 
-   DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
+   DRM_DEBUG_DRIVER("\"%s\"\n", mode->name);
 
/* Enable clocks */
regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
@@ -555,12 +555,7 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
int vic = drm_match_cea_mode(mode);
enum drm_mode_status status;
 
-   DRM_DEBUG_DRIVER("Modeline %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 
0x%x\n",
-   mode->base.id, mode->name, mode->vrefresh, mode->clock,
-   mode->hdisplay, mode->hsync_start,
-   mode->hsync_end, mode->htotal,
-   mode->vdisplay, mode->vsync_start,
-   mode->vsync_end, mode->vtotal, mode->type, mode->flags);
+   DRM_DEBUG_DRIVER("Modeline " DRM_MODE_FMT "\n", DRM_MODE_ARG(mode));
 
/* Check against non-VIC supported modes */
if (!vic) {
@@ -650,8 +645,7 @@ static void meson_venc_hdmi_encoder_mode_set(struct 
drm_encoder *encoder,
struct meson_drm *priv = dw_hdmi->priv;
int vic = drm_match_cea_mode(mode);
 
-   DRM_DEBUG_DRIVER("%d:\"%s\" vic %d\n",
-mode->base.id, mode->name, vic);
+   DRM_DEBUG_DRIVER("\"%s\" vic %d\n", mode->name, vic);
 
/* VENC + VENC-DVI Mode setup */
meson_venc_hdmi_mode_set(priv, vic, mode);
-- 
2.17.1

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


  1   2   3   >