Re: [RFC 2/4] drm/panel/ili9341: Rebase and some more

[Josef Luštický]

Hi Noralf,
see comment bellow.

po 29. 7. 2019 v 21:55 odesílatel Noralf Trønnes  napsal:
>
> Embed mipi_dbi in struct ili9341.
> Rebase on moved mipi-dbi, rename variable name.
> Add backlight_device to panel struct.
> mipi_dbi_hw_reset() already has a NULL check on the reset gpio.
> Prepare for more panels by reworking ili9341_config.
>
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 104 +--
>  1 file changed, 52 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
> b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> index 0c700b171025..a755f3e60111 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  /* ILI9341 extended register set (Vendor Command Set) */
>  #define ILI9341_IFMODE 0xB0 // clock polarity
> @@ -42,17 +42,18 @@
>
>  /**
>   * struct ili9341_config - the display specific configuration
> - * @width_mm: physical panel width [mm]
> - * @height_mm: physical panel height [mm]
> + * @funcs: Panel functions
> + * @mode: Display mode
>   */
>  struct ili9341_config {
> -   u32 width_mm;
> -   u32 height_mm;
> +   const struct drm_panel_funcs *funcs;
> +   const struct drm_display_mode *mode;
>  };
>
>  struct ili9341 {
> struct drm_panel panel;
> -   struct mipi_dbi *mipi;
> +   struct mipi_dbi dbi;
> +   struct backlight_device *backlight;
> const struct ili9341_config *conf;
>  };
>
> @@ -63,47 +64,50 @@ static inline struct ili9341 *panel_to_ili9341(struct 
> drm_panel *panel)
>
>  static int ili9341_deinit(struct drm_panel *panel, struct ili9341 *ili)
>  {
> -   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_DISPLAY_OFF);
> -   mipi_dbi_command(ili->mipi, MIPI_DCS_ENTER_SLEEP_MODE);
> +   struct mipi_dbi *dbi = &ili->dbi;
> +
> +   mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
> +   mipi_dbi_command(dbi, MIPI_DCS_ENTER_SLEEP_MODE);
> msleep(5);
> return 0;
>  }
>
> -static int ili9341_init(struct drm_panel *panel, struct ili9341 *ili)
> +static int dt024ctft_init(struct drm_panel *panel, struct ili9341 *ili)
I'd prefer to name this function something like ili9341_prgb_init.
In the future, there may be more displays with ILI9341 chip and prgb support
apart from DisplayTech DT024CTFT.
>  {
> -   /* HW / SW Reset display and wait */
> -   if (ili->mipi->reset)
> -   mipi_dbi_hw_reset(ili->mipi);
> +   struct mipi_dbi *dbi = &ili->dbi;
>
> -   mipi_dbi_command(ili->mipi, MIPI_DCS_SOFT_RESET);
> +   /* HW / SW Reset display and wait */
> +   mipi_dbi_hw_reset(dbi);
> +
> +   mipi_dbi_command(dbi, MIPI_DCS_SOFT_RESET);
> msleep(120);
>
> /* Polarity */
> -   mipi_dbi_command(ili->mipi, ILI9341_IFMODE, 0xC0);
> +   mipi_dbi_command(dbi, ILI9341_IFMODE, 0xC0);
>
> /* Interface control */
> -   mipi_dbi_command(ili->mipi, ILI9341_IFCTL, 0x09, 0x01, 0x26);
> +   mipi_dbi_command(dbi, ILI9341_IFCTL, 0x09, 0x01, 0x26);
>
> /* Pixel format */
> -   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_PIXEL_FORMAT, 
> MIPI_DCS_PIXEL_FMT_18BIT << 4);
> +   mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT, 
> MIPI_DCS_PIXEL_FMT_18BIT << 4);
>
> /* Gamma */
> -   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
> -   mipi_dbi_command(ili->mipi, ILI9341_PGAMCTRL,
> +   mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
> +   mipi_dbi_command(dbi, ILI9341_PGAMCTRL,
> 0x0f, 0x31, 0x2b, 0x0c, 0x0e, 0x08, 0x4e, 0xf1,
> 0x37, 0x07, 0x10, 0x03, 0x0e, 0x09, 0x00);
> -   mipi_dbi_command(ili->mipi, ILI9341_NGAMCTRL,
> +   mipi_dbi_command(dbi, ILI9341_NGAMCTRL,
> 0x00, 0x0e, 0x14, 0x03, 0x11, 0x07, 0x31, 0xc1,
> 0x48, 0x08, 0x0f, 0x0c, 0x31, 0x36, 0x0f);
>
> /* Rotation */
> -   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_ADDRESS_MODE, 
> ILI9341_MADCTL_MX);
> +   mipi_dbi_command(dbi, MIPI_DCS_SET_ADDRESS_MODE, ILI9341_MADCTL_MX);
>
> /* Exit sleep mode */
> -   mipi_dbi_command(ili->mipi, MIPI_DCS_EXIT_SLEEP_MODE);
> +   mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
> msleep(120);
>
> -   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_DISPLAY_ON);
> +   mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_ON);
>
> return 0;
>  }
> @@ -115,12 +119,12 @@ static int ili9341_unprepare(struct drm_panel *panel)
> return ili9341_deinit(panel, ili);
>  }
>
> -static int ili9341_prepare(struct drm_panel *panel)
> +static int dt024ctft_prepare(struct drm_panel *panel)
>  {
> struct ili9341 *ili = panel_to_ili9341(panel);
> int ret;
>
> -   ret = ili9341_init(panel, ili);
> +   ret = dt024ctft_init(panel, ili);
> if (ret < 0)
>  

Re: [RFC 0/4] drm/mipi-dbi: Support panel drivers

[Josef Luštický]

Hi Noralf,
the patch series looks good, see comments in the patch emails.

One question: is there a general mechanism to tell a driver not to use
parallel RGB even though
the display supports it and "port" is specified in the device-tree?

Josef

po 29. 7. 2019 v 21:55 odesílatel Noralf Trønnes  napsal:
>
> Inspired by the thread[1] following the submission of a new ili9341
> panel driver[2], I set out to see if I could support panel drivers in
> drm_mipi_dbi.
>
> I have included the original driver, done some prep work on it, added
> panel support to drm_mipi_dbi and converted mi0283qt to this new panel
> driver.
>
> The big question is whether or not panel drivers should be allowed to
> turn themselves into full fledged DRM drivers.
>
> Noralf.
>
> [1]
> https://lists.freedesktop.org/archives/dri-devel/2019-July/228193.html
> [2] https://patchwork.freedesktop.org/patch/316528/
>
> Josef Lusticky (1):
>   drm/panel: Add Ilitek ILI9341 parallel RGB panel driver
>
> Noralf Trønnes (3):
>   drm/panel/ili9341: Rebase and some more
>   drm/mipi-dbi: Support command mode panel drivers
>   drm/panel/ili9341: Support mi0283qt
>
>  MAINTAINERS  |   6 +
>  drivers/gpu/drm/drm_mipi_dbi.c   | 110 +
>  drivers/gpu/drm/panel/Kconfig|   9 +
>  drivers/gpu/drm/panel/Makefile   |   1 +
>  drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 452 +++
>  include/drm/drm_mipi_dbi.h   |   8 +
>  6 files changed, 586 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c
>
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 14/19] drm/tilcdc: drop use of drmP.h

[Sam Ravnborg]

Hi Jyri.

On Tue, Jul 30, 2019 at 09:03:11AM +0300, Jyri Sarha wrote:
> On 16/07/2019 09:42, Sam Ravnborg wrote:
> > Dropped drmP.h and all other header files not used by tilcdc_drv.h.
> > Added the minimal includes and forwards to make the header file
> > self-contained.
> > 
> > Then dropped the remaining uses of drmP.h and fixed all fall-out.
> > 
> > Signed-off-by: Sam Ravnborg 
> > Acked-by: Emil Velikov 
> > Cc: Jyri Sarha 
> > Cc: Tomi Valkeinen 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> 
> Acked-by: Jyri Sarha 
Thanks. Patch is already applied so too late to add your ack to the
changelog.

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

Re: [PATCH] gpu: drm/tilcdc: Fix switch case fallthrough

[Tomi Valkeinen]

On 17/07/2019 08:09, Keerthy wrote:

Fix the below build warning/Error

drivers/gpu/drm/tilcdc/tilcdc_crtc.c: In function ‘tilcdc_crtc_set_mode’:
drivers/gpu/drm/tilcdc/tilcdc_crtc.c:384:8: error: this statement may fall
through [-Werror=implicit-fallthrough=]
 reg |= LCDC_V2_TFT_24BPP_UNPACK;
 ^~
drivers/gpu/drm/tilcdc/tilcdc_crtc.c:386:3: note: here
case DRM_FORMAT_BGR888:
^~~~
cc1: all warnings being treated as errors
make[5]: *** [drivers/gpu/drm/tilcdc/tilcdc_crtc.o] Error 1
make[4]: *** [drivers/gpu/drm/tilcdc] Error 2
make[4]: *** Waiting for unfinished jobs

Fixes: f6382f186d2982750 ("drm/tilcdc: Add tilcdc_crtc_mode_set_nofb()")
Signed-off-by: Keerthy 
---
  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


Reviewed-by: Tomi Valkeinen 

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-mapping: remove dma_{alloc,free,mmap}_writecombine

[Christoph Hellwig]

We can already use DMA_ATTR_WRITE_COMBINE or the _wc prefixed version,
so remove the third way of doing things.

Signed-off-by: Christoph Hellwig 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 11 +--
 include/linux/dma-mapping.h |  9 -
 2 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 785c5546067a..c70f3246a552 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -4609,11 +4609,10 @@ static int dispc_errata_i734_wa_init(struct 
dispc_device *dispc)
i734_buf.size = i734.ovli.width * i734.ovli.height *
color_mode_to_bpp(i734.ovli.fourcc) / 8;
 
-   i734_buf.vaddr = dma_alloc_writecombine(&dispc->pdev->dev,
-   i734_buf.size, &i734_buf.paddr,
-   GFP_KERNEL);
+   i734_buf.vaddr = dma_alloc_wc(&dispc->pdev->dev, i734_buf.size,
+   &i734_buf.paddr, GFP_KERNEL);
if (!i734_buf.vaddr) {
-   dev_err(&dispc->pdev->dev, "%s: dma_alloc_writecombine 
failed\n",
+   dev_err(&dispc->pdev->dev, "%s: dma_alloc_wc failed\n",
__func__);
return -ENOMEM;
}
@@ -4626,8 +4625,8 @@ static void dispc_errata_i734_wa_fini(struct dispc_device 
*dispc)
if (!dispc->feat->has_gamma_i734_bug)
return;
 
-   dma_free_writecombine(&dispc->pdev->dev, i734_buf.size, i734_buf.vaddr,
- i734_buf.paddr);
+   dma_free_wc(&dispc->pdev->dev, i734_buf.size, i734_buf.vaddr,
+   i734_buf.paddr);
 }
 
 static void dispc_errata_i734_wa(struct dispc_device *dispc)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea32c78..633dae466097 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -786,9 +786,6 @@ static inline void *dma_alloc_wc(struct device *dev, size_t 
size,
 
return dma_alloc_attrs(dev, size, dma_addr, gfp, attrs);
 }
-#ifndef dma_alloc_writecombine
-#define dma_alloc_writecombine dma_alloc_wc
-#endif
 
 static inline void dma_free_wc(struct device *dev, size_t size,
   void *cpu_addr, dma_addr_t dma_addr)
@@ -796,9 +793,6 @@ static inline void dma_free_wc(struct device *dev, size_t 
size,
return dma_free_attrs(dev, size, cpu_addr, dma_addr,
  DMA_ATTR_WRITE_COMBINE);
 }
-#ifndef dma_free_writecombine
-#define dma_free_writecombine dma_free_wc
-#endif
 
 static inline int dma_mmap_wc(struct device *dev,
  struct vm_area_struct *vma,
@@ -808,9 +802,6 @@ static inline int dma_mmap_wc(struct device *dev,
return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size,
  DMA_ATTR_WRITE_COMBINE);
 }
-#ifndef dma_mmap_writecombine
-#define dma_mmap_writecombine dma_mmap_wc
-#endif
 
 #ifdef CONFIG_NEED_DMA_MAP_STATE
 #define DEFINE_DMA_UNMAP_ADDR(ADDR_NAME)dma_addr_t ADDR_NAME
-- 
2.20.1

Re: [PATCH v2 14/19] drm/tilcdc: drop use of drmP.h

[Jyri Sarha]

On 16/07/2019 09:42, Sam Ravnborg wrote:
> Dropped drmP.h and all other header files not used by tilcdc_drv.h.
> Added the minimal includes and forwards to make the header file
> self-contained.
> 
> Then dropped the remaining uses of drmP.h and fixed all fall-out.
> 
> Signed-off-by: Sam Ravnborg 
> Acked-by: Emil Velikov 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Acked-by: Jyri Sarha 

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 18 --
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 19 ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h  | 31 +---
>  drivers/gpu/drm/tilcdc/tilcdc_external.c |  1 +
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c| 11 ++---
>  drivers/gpu/drm/tilcdc/tilcdc_plane.c|  4 +--
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c   |  8 +++---
>  7 files changed, 57 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 1067e702c22c..8c2025780372 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -15,16 +15,20 @@
>   * this program.  If not, see .
>   */
>  
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  #include "tilcdc_drv.h"
>  #include "tilcdc_regs.h"
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index b6b71e86e238..8e228c75b68e 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -18,19 +18,30 @@
>  /* LCDC DRM driver, based on da8xx-fb */
>  
>  #include 
> +#include 
> +#include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
> +
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +
>  
>  #include "tilcdc_drv.h"
> +#include "tilcdc_external.h"
> +#include "tilcdc_panel.h"
>  #include "tilcdc_regs.h"
>  #include "tilcdc_tfp410.h"
> -#include "tilcdc_panel.h"
> -#include "tilcdc_external.h"
>  
>  static LIST_HEAD(module_list);
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index d86397da12a9..50c208c48be0 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -18,21 +18,24 @@
>  #ifndef __TILCDC_DRV_H__
>  #define __TILCDC_DRV_H__
>  
> -#include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
> +
> +#include 
> +
> +struct clk;
> +struct workqueue_struct;
> +
> +struct drm_connector;
> +struct drm_connector_helper_funcs;
> +struct drm_crtc;
> +struct drm_device;
> +struct drm_display_mode;
> +struct drm_encoder;
> +struct drm_framebuffer;
> +struct drm_minor;
> +struct drm_pending_vblank_event;
> +struct drm_plane;
>  
>  /* Defaulting to pixel clock defined on AM335x */
>  #define TILCDC_DEFAULT_MAX_PIXELCLOCK  126000
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> index e9969cd36610..0f3419a19d71 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> @@ -10,6 +10,7 @@
>  
>  #include 
>  #include 
> +
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 5d532a596e1e..e1c39712b67a 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -15,14 +15,17 @@
>   * this program.  If not, see .
>   */
>  
> -#include 
> -#include 
> -#include 
>  #include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> -#include 
> +
> +#include 
> +#include 
> +#include 
>  #include 
>  
>  #include "tilcdc_drv.h"
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> index 7667b038ae7f..347ca8656aef 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> @@ -15,12 +15,10 @@
>   * this program.  If not, see .
>   */
>  
> -#include 
> -
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #include "tilcdc_drv.h"
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> index fe59fbfdde69..da642c725cd6 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> @@ -15,12 +15,14 @@
>   * this program.  If not, see .
>   */
>  
> -#include 
>  #include 
> +#include 
>  #inc

[Bug 204145] amdgpu video playback causes host to hard reset (checkstop) on POWER9 with RX 580

[bugzilla-daemon]

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

Michael Ellerman (mich...@ellerman.id.au) changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #26 from Michael Ellerman (mich...@ellerman.id.au) ---
Now merged, thanks all.

If the fix isn't working please reopen.

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

RE: [PATCH] drm/i915/gvt: remove duplicate entry of trace

[Zhao, Yan Y]

Reviewed-by: Yan Zhao 

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Zhenyu Wang
> Sent: Wednesday, June 12, 2019 11:23 AM
> To: Hariprasad Kelam 
> Cc: David Airlie ; intel-...@lists.freedesktop.org; Joonas
> Lahtinen ; linux-ker...@vger.kernel.org; Jani
> Nikula ; dri-devel@lists.freedesktop.org; Daniel
> Vetter ; Vivi, Rodrigo ; intel-gvt-
> d...@lists.freedesktop.org; Wang, Zhi A 
> Subject: Re: [PATCH] drm/i915/gvt: remove duplicate entry of trace
> 
> On 2019.05.26 13:26:33 +0530, Hariprasad Kelam wrote:
> > Remove duplicate include of trace.h
> >
> > Issue identified by includecheck
> >
> > Signed-off-by: Hariprasad Kelam 
> > ---
> >  drivers/gpu/drm/i915/gvt/trace_points.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/trace_points.c
> > b/drivers/gpu/drm/i915/gvt/trace_points.c
> > index a3deed69..569f5e3 100644
> > --- a/drivers/gpu/drm/i915/gvt/trace_points.c
> > +++ b/drivers/gpu/drm/i915/gvt/trace_points.c
> > @@ -32,5 +32,4 @@
> >
> >  #ifndef __CHECKER__
> >  #define CREATE_TRACE_POINTS
> > -#include "trace.h"
> >  #endif
> > --
> 
> This actually caused build issue like
> ERROR: "__tracepoint_gma_index" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_render_mmio" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_gvt_command" [drivers/gpu/drm/i915/i915.ko]
> undefined!
> ERROR: "__tracepoint_spt_guest_change" [drivers/gpu/drm/i915/i915.ko]
> undefined!
> ERROR: "__tracepoint_gma_translate" [drivers/gpu/drm/i915/i915.ko]
> undefined!
> ERROR: "__tracepoint_spt_alloc" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_spt_change" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_oos_sync" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_write_ir" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_propagate_event" [drivers/gpu/drm/i915/i915.ko]
> undefined!
> ERROR: "__tracepoint_inject_msi" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_spt_refcount" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_spt_free" [drivers/gpu/drm/i915/i915.ko] undefined!
> ERROR: "__tracepoint_oos_change" [drivers/gpu/drm/i915/i915.ko] undefined!
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> 
> Looks we need fix like below.
> 
> Subject: [PATCH] drm/i915/gvt: remove duplicate include of trace.h
> 
> This removes duplicate include of trace.h. Found by Hariprasad Kelam with
> includecheck.
> 
> Reported-by: Hariprasad Kelam 
> Signed-off-by: Zhenyu Wang 
> ---
>  drivers/gpu/drm/i915/gvt/trace_points.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/trace_points.c
> b/drivers/gpu/drm/i915/gvt/trace_points.c
> index a3deed692b9c..fe552e877e09 100644
> --- a/drivers/gpu/drm/i915/gvt/trace_points.c
> +++ b/drivers/gpu/drm/i915/gvt/trace_points.c
> @@ -28,8 +28,6 @@
>   *
>   */
> 
> -#include "trace.h"
> -
>  #ifndef __CHECKER__
>  #define CREATE_TRACE_POINTS
>  #include "trace.h"
> --
> 2.20.1
> 
> --
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[PATCH v2] Fix typo reigster to register

[Pei-Hsuan Hung]

Signed-off-by: Pei-Hsuan Hung 
Acked-by: Liviu Dudau 
Cc: triv...@kernel.org
---
Hi Liviu, thanks for your reply.
This patch is generated by a script so at first I didn't notice there is
also a typo in the word coefficient. I've fixed the typo in this
version.

 arch/powerpc/kernel/eeh.c   | 2 +-
 arch/powerpc/platforms/cell/spufs/switch.c  | 4 ++--
 drivers/extcon/extcon-rt8973a.c | 2 +-
 drivers/gpu/drm/arm/malidp_regs.h   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h | 2 +-
 drivers/scsi/lpfc/lpfc_hbadisc.c| 2 +-
 fs/userfaultfd.c| 2 +-
 7 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index c0e4b73191f3..d75c9c24ec4d 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1030,7 +1030,7 @@ int __init eeh_ops_register(struct eeh_ops *ops)
 }
 
 /**
- * eeh_ops_unregister - Unreigster platform dependent EEH operations
+ * eeh_ops_unregister - Unregister platform dependent EEH operations
  * @name: name of EEH platform operations
  *
  * Unregister the platform dependent EEH operation callback
diff --git a/arch/powerpc/platforms/cell/spufs/switch.c 
b/arch/powerpc/platforms/cell/spufs/switch.c
index 5c3f5d088c3b..9548a086937b 100644
--- a/arch/powerpc/platforms/cell/spufs/switch.c
+++ b/arch/powerpc/platforms/cell/spufs/switch.c
@@ -574,7 +574,7 @@ static inline void save_mfc_rag(struct spu_state *csa, 
struct spu *spu)
 {
/* Save, Step 38:
 * Save RA_GROUP_ID register and the
-* RA_ENABLE reigster in the CSA.
+* RA_ENABLE register in the CSA.
 */
csa->priv1.resource_allocation_groupID_RW =
spu_resource_allocation_groupID_get(spu);
@@ -1227,7 +1227,7 @@ static inline void restore_mfc_rag(struct spu_state *csa, 
struct spu *spu)
 {
/* Restore, Step 29:
 * Restore RA_GROUP_ID register and the
-* RA_ENABLE reigster from the CSA.
+* RA_ENABLE register from the CSA.
 */
spu_resource_allocation_groupID_set(spu,
csa->priv1.resource_allocation_groupID_RW);
diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
index 40c07f4d656e..e75c03792398 100644
--- a/drivers/extcon/extcon-rt8973a.c
+++ b/drivers/extcon/extcon-rt8973a.c
@@ -270,7 +270,7 @@ static int rt8973a_muic_get_cable_type(struct 
rt8973a_muic_info *info)
}
cable_type = adc & RT8973A_REG_ADC_MASK;
 
-   /* Read Device 1 reigster to identify correct cable type */
+   /* Read Device 1 register to identify correct cable type */
ret = regmap_read(info->regmap, RT8973A_REG_DEV1, &dev1);
if (ret) {
dev_err(info->dev, "failed to read DEV1 register\n");
diff --git a/drivers/gpu/drm/arm/malidp_regs.h 
b/drivers/gpu/drm/arm/malidp_regs.h
index 993031542fa1..9b4f95d8ccec 100644
--- a/drivers/gpu/drm/arm/malidp_regs.h
+++ b/drivers/gpu/drm/arm/malidp_regs.h
@@ -145,7 +145,7 @@
 #define MALIDP_SE_COEFFTAB_DATA_MASK   0x3fff
 #define MALIDP_SE_SET_COEFFTAB_DATA(x) \
((x) & MALIDP_SE_COEFFTAB_DATA_MASK)
-/* Enhance coeffents reigster offset */
+/* Enhance coefficients register offset */
 #define MALIDP_SE_IMAGE_ENH0x3C
 /* ENH_LIMITS offset 0x0 */
 #define MALIDP_SE_ENH_LOW_LEVEL24
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
index 99c6f7eefd85..d03c8f12a15c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/fw.h
@@ -58,7 +58,7 @@ struct fw_priv {
/* 0x81: PCI-AP, 01:PCIe, 02: 92S-U,
 * 0x82: USB-AP, 0x12: 72S-U, 03:SDIO */
u8 hci_sel;
-   /* the same value as reigster value  */
+   /* the same value as register value  */
u8 chip_version;
/* customer  ID low byte */
u8 customer_id_0;
diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
index 28ecaa7fc715..42b125602d72 100644
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -6551,7 +6551,7 @@ lpfc_sli4_unregister_fcf(struct lpfc_hba *phba)
  * lpfc_unregister_fcf_rescan - Unregister currently registered fcf and rescan
  * @phba: Pointer to hba context object.
  *
- * This function unregisters the currently reigstered FCF. This function
+ * This function unregisters the currently registered FCF. This function
  * also tries to find another FCF for discovery by rescan the HBA FCF table.
  */
 void
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index ccbdbd62f0d8..612dc1240f90 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -267,7 +267,7 @@ static inline bool userfaultfd_huge_must_wait(struct 
userfaultfd_ctx *ctx,
 #endif /* CONFIG_HUGETLB_

[Bug 111234] amdgpu bug: kernel NULL pointer dereference during video playback

[bugzilla-daemon]

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

--- Comment #3 from Michael J Evans  ---
After looking at the linked bug and your description of my environment (dual
screen and yes KDE / Plasma as a compositor potentially exposing whatever
corner case this is in the kernel driver):

I agree this is likely a duplicate of that issue.

The above dmesg contained the only relevant data post-boot, though if you'd
like sections of specific drivers initializing other other memory data I can
provide a more hand-picked selection of data for the next crash.

After this evening's crash I've updated to the latest arch-linux kernel and
packages.

The kernel is now booting with a 'cmdline' including: amdgpu.gpu_recovery=1
log_buf_len=64M drm.debug=84 debug

I've kept my desktop environment the same in the hope that I might collect a
useful crash context with the added data.

-- 
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 111243] Installation of 19.20 Fails

[bugzilla-daemon]

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

--- Comment #2 from jacque8...@gmail.com ---
That fixed the problem.  Thank you so much.

-- 
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/bridge: tc358764: Fix build error

[Laurent Pinchart]

Hi Yue,

Thank you for the patch.

On Mon, Jul 29, 2019 at 05:05:20PM +0800, YueHaibing wrote:
> If CONFIG_DRM_TOSHIBA_TC358764=y but CONFIG_DRM_KMS_HELPER=m,
> building fails:
> 
> drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x228): undefined reference to 
> `drm_atomic_helper_connector_reset'
> drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x240): undefined reference to 
> `drm_helper_probe_single_connector_modes'
> drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x268): undefined reference to 
> `drm_atomic_helper_connector_duplicate_state'
> drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x270): undefined reference to 
> `drm_atomic_helper_connector_destroy_state'
> 
> Like TC358767, select DRM_KMS_HELPER to fix this, and
> change to select DRM_PANEL to avoid recursive dependency.
> 
> Reported-by: Hulk Robot 
> Fixes: f38b7cca6d0e ("drm/bridge: tc358764: Add DSI to LVDS bridge driver")
> Signed-off-by: YueHaibing 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index a6eec90..323f72d 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -116,9 +116,10 @@ config DRM_THINE_THC63LVD1024
>  
>  config DRM_TOSHIBA_TC358764
>   tristate "TC358764 DSI/LVDS bridge"
> - depends on DRM && DRM_PANEL
>   depends on OF
>   select DRM_MIPI_DSI
> + select DRM_KMS_HELPER
> + select DRM_PANEL
>   help
> Toshiba TC358764 DSI/LVDS bridge driver.
>  

-- 
Regards,

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

[Bug 110637] Any OpenCL application causes "*ERROR* ring gfx timeout" on Vega 64

[bugzilla-daemon]

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

--- Comment #11 from Alex Deucher  ---
(In reply to Alexander Mezin from comment #10)
> (In reply to Alex Deucher from comment #3)
> > More likely a bug in the mesa OpenCL code.  If you want functional OpenCL,
> > you should use the ROCm OpenCL packages.
> 
> Do you mean "Mesa OpenCL is not supported/unmaintained"?

Correct.

-- 
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

[RFC PATCH 1/3] drm: introduce new struct drm_mem_region

[Brian Welty]

Move basic members of ttm_mem_type_manager into a new DRM memory region
structure.  The idea is for this base structure to be nested inside
the TTM structure and later in Intel's proposed intel_memory_region.

As comments in the code suggest, the following future work can extend
the usefulness of this:
- Create common memory region types (next patch)
- Create common set of memory_region function callbacks (based on
  ttm_mem_type_manager_funcs and intel_memory_regions_ops)
- Create common helpers that operate on drm_mem_region to be leveraged
  by both TTM drivers and i915, reducing code duplication
- Above might start with refactoring ttm_bo_manager.c as these are
  helpers for using drm_mm's range allocator and could be made to
  operate on DRM structures instead of TTM ones.
- Larger goal might be to make LRU management of GEM objects common, and
  migrate those fields into drm_mem_region and drm_gem_object strucures.

vmwgfx changes included here as just example of what driver updates will
look like, and can be moved later to separate patch.  Other TTM drivers
need to be updated similarly.

Signed-off-by: Brian Welty 
---
 drivers/gpu/drm/ttm/ttm_bo.c  | 34 +++
 drivers/gpu/drm/ttm/ttm_bo_manager.c  | 14 
 drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  8 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c|  4 +--
 include/drm/drm_mm.h  | 31 +++--
 include/drm/ttm/ttm_bo_api.h  |  2 +-
 include/drm/ttm/ttm_bo_driver.h   | 16 -
 8 files changed, 75 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 58c403eda04e..45434ea513dd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -84,8 +84,8 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, 
struct drm_printer *p
drm_printf(p, "has_type: %d\n", man->has_type);
drm_printf(p, "use_type: %d\n", man->use_type);
drm_printf(p, "flags: 0x%08X\n", man->flags);
-   drm_printf(p, "gpu_offset: 0x%08llX\n", man->gpu_offset);
-   drm_printf(p, "size: %llu\n", man->size);
+   drm_printf(p, "gpu_offset: 0x%08llX\n", man->region.start);
+   drm_printf(p, "size: %llu\n", man->region.size);
drm_printf(p, "available_caching: 0x%08X\n", 
man->available_caching);
drm_printf(p, "default_caching: 0x%08X\n", man->default_caching);
if (mem_type != TTM_PL_SYSTEM)
@@ -399,7 +399,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
 
if (bo->mem.mm_node)
bo->offset = (bo->mem.start << PAGE_SHIFT) +
-   bdev->man[bo->mem.mem_type].gpu_offset;
+   bdev->man[bo->mem.mem_type].region.start;
else
bo->offset = 0;
 
@@ -926,9 +926,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object 
*bo,
struct dma_fence *fence;
int ret;
 
-   spin_lock(&man->move_lock);
-   fence = dma_fence_get(man->move);
-   spin_unlock(&man->move_lock);
+   spin_lock(&man->region.move_lock);
+   fence = dma_fence_get(man->region.move);
+   spin_unlock(&man->region.move_lock);
 
if (fence) {
reservation_object_add_shared_fence(bo->resv, fence);
@@ -1490,9 +1490,9 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
}
spin_unlock(&glob->lru_lock);
 
-   spin_lock(&man->move_lock);
-   fence = dma_fence_get(man->move);
-   spin_unlock(&man->move_lock);
+   spin_lock(&man->region.move_lock);
+   fence = dma_fence_get(man->region.move);
+   spin_unlock(&man->region.move_lock);
 
if (fence) {
ret = dma_fence_wait(fence, false);
@@ -1535,8 +1535,8 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
ret = (*man->func->takedown)(man);
}
 
-   dma_fence_put(man->move);
-   man->move = NULL;
+   dma_fence_put(man->region.move);
+   man->region.move = NULL;
 
return ret;
 }
@@ -1561,7 +1561,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
 EXPORT_SYMBOL(ttm_bo_evict_mm);
 
 int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned type,
-   unsigned long p_size)
+  resource_size_t p_size)
 {
int ret;
struct ttm_mem_type_manager *man;
@@ -1570,10 +1570,16 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned 
type,
BUG_ON(type >= TTM_NUM_MEM_TYPES);
man = &bdev->man[type];
BUG_ON(man->has_type);
+
+   /* FIXME: add call to (new) drm_mem_region_init ? */
+   man->region.size = p_size;
+   man->region.type = type;
+   spin_lock_init(&man->region.move_lock);
+   man->region.move = NULL;
+
man->io_reserve_fastpath = true;

[RFC PATCH 2/3] drm: Introduce DRM_MEM defines for specifying type of drm_mem_region

[Brian Welty]

Introduce DRM memory region types to be common for both drivers using
TTM and for i915.  For now, TTM continues to define it's own set but
uses the DRM base definitions.

Signed-off-by: Brian Welty 
---
 include/drm/drm_mm.h| 8 
 include/drm/ttm/ttm_placement.h | 8 
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 465f8d10d863..b78dc9284702 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -59,6 +59,14 @@
 struct drm_device;
 struct drm_mm;
 
+/*
+ * Memory types for drm_mem_region
+ */
+#define DRM_MEM_SYSTEM 0
+#define DRM_MEM_STOLEN 1
+#define DRM_MEM_VRAM   2
+#define DRM_MEM_PRIV   3
+
 /**
  * struct drm_mem_region
  *
diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
index e88a8e39767b..976cf8d2f899 100644
--- a/include/drm/ttm/ttm_placement.h
+++ b/include/drm/ttm/ttm_placement.h
@@ -37,10 +37,10 @@
  * Memory regions for data placement.
  */
 
-#define TTM_PL_SYSTEM   0
-#define TTM_PL_TT   1
-#define TTM_PL_VRAM 2
-#define TTM_PL_PRIV 3
+#define TTM_PL_SYSTEM   DRM_MEM_SYSTEM
+#define TTM_PL_TT   DRM_MEM_STOLEN
+#define TTM_PL_VRAM DRM_MEM_VRAM
+#define TTM_PL_PRIV DRM_MEM_PRIV
 
 #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
 #define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
-- 
2.21.0

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

[RFC PATCH 3/3] drm/i915: Update intel_memory_region to use nested drm_mem_region

[Brian Welty]

Some fields are deleted from intel_memory_region in favor of instead
using the new nested drm_mem_region structure.

Note, this is based upon unmerged i915 series [1] in order to show how
i915 might begin to integrate the proposed drm_mem_region.

[1] https://lists.freedesktop.org/archives/intel-gfx/2019-June/203649.html

Signed-off-by: Brian Welty 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 10 +++
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 drivers/gpu/drm/i915/i915_query.c |  2 +-
 drivers/gpu/drm/i915/intel_memory_region.c| 10 ---
 drivers/gpu/drm/i915/intel_memory_region.h| 19 --
 drivers/gpu/drm/i915/intel_region_lmem.c  | 26 +--
 .../drm/i915/selftests/intel_memory_region.c  |  8 +++---
 9 files changed, 37 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 73d2d72adc19..7e56fd89a972 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -606,7 +606,7 @@ static int i915_gem_object_region_select(struct 
drm_i915_private *dev_priv,
ret = i915_gem_object_migrate(obj, ce, id);
if (!ret) {
if (MEMORY_TYPE_FROM_REGION(region) ==
-   INTEL_LMEM) {
+   DRM_MEM_VRAM) {
/*
 * TODO: this should be part of get_pages(),
 * when async get_pages arrives
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index d24f34443c4c..ac18e73665d4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -53,7 +53,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
 * If there's no chance of allocating enough pages for the whole
 * object, bail early.
 */
-   if (obj->base.size > resource_size(&mem->region))
+   if (obj->base.size > mem->region.size)
return -ENOMEM;
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2288a55f27f1..f4adc7e397ff 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2737,20 +2737,20 @@ int i915_gem_init_memory_regions(struct 
drm_i915_private *i915)
 
for (i = 0; i < ARRAY_SIZE(intel_region_map); i++) {
struct intel_memory_region *mem = NULL;
-   u32 type;
+   u8 type;
 
if (!HAS_REGION(i915, BIT(i)))
continue;
 
type = MEMORY_TYPE_FROM_REGION(intel_region_map[i]);
switch (type) {
-   case INTEL_SMEM:
+   case DRM_MEM_SYSTEM:
mem = i915_gem_shmem_setup(i915);
break;
-   case INTEL_STOLEN:
+   case DRM_MEM_STOLEN:
mem = i915_gem_stolen_setup(i915);
break;
-   case INTEL_LMEM:
+   case DRM_MEM_VRAM:
mem = i915_gem_setup_fake_lmem(i915);
break;
}
@@ -2762,7 +2762,7 @@ int i915_gem_init_memory_regions(struct drm_i915_private 
*i915)
}
 
mem->id = intel_region_map[i];
-   mem->type = type;
+   mem->region.type = type;
mem->instance = 
MEMORY_INSTANCE_FROM_REGION(intel_region_map[i]);
 
i915->regions[i] = mem;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9feb597f2b01..908691c3aadb 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1048,7 +1048,7 @@ i915_error_object_create(struct drm_i915_private *i915,
struct intel_memory_region *mem = vma->obj->memory_region;
 
for_each_sgt_dma(dma, iter, vma->pages) {
-   s = io_mapping_map_atomic_wc(&mem->iomap, dma);
+   s = io_mapping_map_atomic_wc(&mem->region.iomap, dma);
ret = compress_page(compress, s, dst);
io_mapping_unmap_atomic(s);
 
diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 21c4c2592d6c..d16b4a6688e8 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -184,7 +184,7 @@ static int query_memregion_info(struct drm_i915_private 
*dev_priv,
continue;
 
info.id = region->id;
-   info.size = resource_size(®ion->region);
+   info.size = region->region.size;
 

[RFC PATCH 0/3] Propose new struct drm_mem_region

[Brian Welty]

[ By request, resending to include amd-gfx + intel-gfx.  Since resending,
  I fixed the nit with ordering of header includes that Sam noted. ]

This RFC series is first implementation of some ideas expressed
earlier on dri-devel [1].

Some of the goals (open for much debate) are:
  - Create common base structure (subclass) for memory regions (patch #1)
  - Create common memory region types (patch #2)
  - Create common set of memory_region function callbacks (based on
ttm_mem_type_manager_funcs and intel_memory_regions_ops)
  - Create common helpers that operate on drm_mem_region to be leveraged
by both TTM drivers and i915, reducing code duplication
  - Above might start with refactoring ttm_bo_manager.c as these are
helpers for using drm_mm's range allocator and could be made to
operate on DRM structures instead of TTM ones.
  - Larger goal might be to make LRU management of GEM objects common, and
migrate those fields into drm_mem_region and drm_gem_object strucures.

Patches 1-2 implement the proposed struct drm_mem_region and adds
associated common set of definitions for memory region type.

Patch #3 is update to i915 and is based upon another series which is
in progress to add vram support to i915 [2].

[1] https://lists.freedesktop.org/archives/dri-devel/2019-June/224501.html
[2] https://lists.freedesktop.org/archives/intel-gfx/2019-June/203649.html

Brian Welty (3):
  drm: introduce new struct drm_mem_region
  drm: Introduce DRM_MEM defines for specifying type of drm_mem_region
  drm/i915: Update intel_memory_region to use nested drm_mem_region

 drivers/gpu/drm/i915/gem/i915_gem_object.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 10 ++---
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 drivers/gpu/drm/i915/i915_query.c |  2 +-
 drivers/gpu/drm/i915/intel_memory_region.c| 10 +++--
 drivers/gpu/drm/i915/intel_memory_region.h| 19 +++--
 drivers/gpu/drm/i915/intel_region_lmem.c  | 26 ++---
 .../drm/i915/selftests/intel_memory_region.c  |  8 ++--
 drivers/gpu/drm/ttm/ttm_bo.c  | 34 +---
 drivers/gpu/drm/ttm/ttm_bo_manager.c  | 14 +++
 drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  8 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c|  4 +-
 include/drm/drm_mm.h  | 39 ++-
 include/drm/ttm/ttm_bo_api.h  |  2 +-
 include/drm/ttm/ttm_bo_driver.h   | 16 
 include/drm/ttm/ttm_placement.h   |  8 ++--
 18 files changed, 124 insertions(+), 93 deletions(-)

-- 
2.21.0

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

Re: [PATCH libdrm 3/3] intel: Add support for EHL

[Lucas De Marchi]

On Mon, Jul 29, 2019 at 04:52:30PM -0700, Jose Souza wrote:

Series is Reviewed-by: José Roberto de Souza 


Thanks, applied.

Lucas De Marchi



On Mon, 2019-07-15 at 11:53 -0700, Lucas De Marchi wrote:

From: Rodrigo Vivi 

Add the PCI ID import for EHL.

Cc: Rodrigo Vivi 
Signed-off-by: James Ausmus 
Signed-off-by: Lucas De Marchi 
---
 intel/intel_chipset.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index 157c2c7d..f6e37ee7 100644
--- a/intel/intel_chipset.c
+++ b/intel/intel_chipset.c
@@ -36,6 +36,7 @@ static const struct pci_device {
 } pciids[] = {
/* Keep ids sorted by gen; latest gen first */
INTEL_TGL_12_IDS(12),
+   INTEL_EHL_IDS(11),
INTEL_ICL_11_IDS(11),
INTEL_CNL_IDS(10),
INTEL_CFL_IDS(9),

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

Re: [PATCH v3 6a/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding

[Rob Herring]

On Mon, Jul 29, 2019 at 8:23 AM Torsten Duwe  wrote:
>
> On Fri, Jul 26, 2019 at 06:36:01PM +0200, Maxime Ripard wrote:
> > > +
> > > +  dvdd12-supply:
> > > +maxItems: 1
> > > +description: Regulator for 1.2V digital core power.
> > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > +
> > > +  dvdd25-supply:
> > > +maxItems: 1
> > > +description: Regulator for 2.5V digital core power.
> > > +$ref: /schemas/types.yaml#/definitions/phandle
> >
> > There's no need to specify the type here, all the properties ending in
> > -supply are already checked for that type
>
> Ok, thanks for the hint.
>
> > > +  ports:
> > > +type: object
> > > +minItems: 1
> > > +maxItems: 2
> > > +description: |
> > > +  Video port 0 for LVTTL input,
> > > +  Video port 1 for eDP output (panel or connector)
> > > +  using the DT bindings defined in
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt
> >
> > You should probably describe the port@0 and port@1 nodes here as
> > well. It would allow you to express that the port 0 is mandatory and
> > the port 1 optional, which got dropped in the conversion.
>
> I would have liked to, but have not discovered yet a comprehensive source
> of information about recommended syntax and semantics of the YAML schemes.

The language is json-schema.

> Is there some central reference for these types of issues? I mean not the
> "here is a git repo with the meta-schemes" but sort of a cookbook?

Documentation/devicetree/writing-schema.md (soon .rst) and
Documentation/devicetree/bindings/example-schema.yaml attempt to do
this. Any feedback on them would be helpful.

For this case specifically, we do need to define a common graph
schema, but haven't yet. You can assume we do and only really need to
capture what Maxime said above.

Rob

Re: [PATCH libdrm 3/3] intel: Add support for EHL

[Souza, Jose]

Series is Reviewed-by: José Roberto de Souza 

On Mon, 2019-07-15 at 11:53 -0700, Lucas De Marchi wrote:
> From: Rodrigo Vivi 
> 
> Add the PCI ID import for EHL.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: James Ausmus 
> Signed-off-by: Lucas De Marchi 
> ---
>  intel/intel_chipset.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
> index 157c2c7d..f6e37ee7 100644
> --- a/intel/intel_chipset.c
> +++ b/intel/intel_chipset.c
> @@ -36,6 +36,7 @@ static const struct pci_device {
>  } pciids[] = {
>   /* Keep ids sorted by gen; latest gen first */
>   INTEL_TGL_12_IDS(12),
> + INTEL_EHL_IDS(11),
>   INTEL_ICL_11_IDS(11),
>   INTEL_CNL_IDS(10),
>   INTEL_CFL_IDS(9),
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 9/9] mm: remove the MIGRATE_PFN_WRITE flag

[Jerome Glisse]

On Mon, Jul 29, 2019 at 04:42:01PM -0700, Ralph Campbell wrote:
> 
> On 7/29/19 7:28 AM, Christoph Hellwig wrote:
> > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> > where it can be replaced with a simple boolean local variable.
> > 
> > Signed-off-by: Christoph Hellwig 
> 
> Reviewed-by: Ralph Campbell 
> 
> > ---
> >   include/linux/migrate.h | 1 -
> >   mm/migrate.c| 9 +
> >   2 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> > index 8b46cfdb1a0e..ba74ef5a7702 100644
> > --- a/include/linux/migrate.h
> > +++ b/include/linux/migrate.h
> > @@ -165,7 +165,6 @@ static inline int 
> > migrate_misplaced_transhuge_page(struct mm_struct *mm,
> >   #define MIGRATE_PFN_VALID (1UL << 0)
> >   #define MIGRATE_PFN_MIGRATE   (1UL << 1)
> >   #define MIGRATE_PFN_LOCKED(1UL << 2)
> > -#define MIGRATE_PFN_WRITE  (1UL << 3)
> >   #define MIGRATE_PFN_SHIFT 6
> >   static inline struct page *migrate_pfn_to_page(unsigned long mpfn)
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 74735256e260..724f92dcc31b 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -2212,6 +2212,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> > unsigned long mpfn, pfn;
> > struct page *page;
> > swp_entry_t entry;
> > +   bool writable = false;
> > pte_t pte;
> > pte = *ptep;
> > @@ -2240,7 +2241,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> > mpfn = migrate_pfn(page_to_pfn(page)) |
> > MIGRATE_PFN_MIGRATE;
> > if (is_write_device_private_entry(entry))
> > -   mpfn |= MIGRATE_PFN_WRITE;
> > +   writable = true;
> > } else {
> > if (is_zero_pfn(pfn)) {
> > mpfn = MIGRATE_PFN_MIGRATE;
> > @@ -2250,7 +2251,8 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> > }
> > page = vm_normal_page(migrate->vma, addr, pte);
> > mpfn = migrate_pfn(pfn) | MIGRATE_PFN_MIGRATE;
> > -   mpfn |= pte_write(pte) ? MIGRATE_PFN_WRITE : 0;
> > +   if (pte_write(pte))
> > +   writable = true;
> > }
> > /* FIXME support THP */
> > @@ -2284,8 +2286,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> > ptep_get_and_clear(mm, addr, ptep);
> > /* Setup special migration page table entry */
> > -   entry = make_migration_entry(page, mpfn &
> > -MIGRATE_PFN_WRITE);
> > +   entry = make_migration_entry(page, writable);
> > swp_pte = swp_entry_to_pte(entry);
> > if (pte_soft_dirty(pte))
> > swp_pte = pte_swp_mksoft_dirty(swp_pte);
> > 
> 
> MIGRATE_PFN_WRITE may mot being used but that seems like a bug to me.
> If a page is migrated to device memory, it could be mapped at the same
> time to avoid a device page fault but it would need the flag to know
> whether to map it RW or RO. But I suppose that could be inferred from
> the vma->vm_flags.

It is a bug that it is not being use right now. I will have to dig my
git repo to see when that got kill. Will look into it once i get back.

The vma->vm_flags is of no use here. A page can be write protected
inside a writable vma for various reasons.

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/9] mm: turn migrate_vma upside down

[Jerome Glisse]

On Mon, Jul 29, 2019 at 05:28:35PM +0300, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma.  Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks.  This removes a lot
> of boilerplate code as-is, and will allow the drivers to drastically
> improve code flow and error handling further on.
> 
> Signed-off-by: Christoph Hellwig 


I haven't finished review, especialy the nouveau code, i will look
into this once i get back. In the meantime below are few corrections.

> ---
>  Documentation/vm/hmm.rst   |  55 +-
>  drivers/gpu/drm/nouveau/nouveau_dmem.c | 122 +++--
>  include/linux/migrate.h| 118 ++--
>  mm/migrate.c   | 242 +++--
>  4 files changed, 193 insertions(+), 344 deletions(-)
> 

[...]

> diff --git a/mm/migrate.c b/mm/migrate.c
> index 8992741f10aa..dc4e60a496f2 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2118,16 +2118,6 @@ int migrate_misplaced_transhuge_page(struct mm_struct 
> *mm,
>  #endif /* CONFIG_NUMA */
>  
>  #if defined(CONFIG_MIGRATE_VMA_HELPER)
> -struct migrate_vma {
> - struct vm_area_struct   *vma;
> - unsigned long   *dst;
> - unsigned long   *src;
> - unsigned long   cpages;
> - unsigned long   npages;
> - unsigned long   start;
> - unsigned long   end;
> -};
> -
>  static int migrate_vma_collect_hole(unsigned long start,
>   unsigned long end,
>   struct mm_walk *walk)
> @@ -2578,6 +2568,108 @@ static void migrate_vma_unmap(struct migrate_vma 
> *migrate)
>   }
>  }
>  
> +/**
> + * migrate_vma_setup() - prepare to migrate a range of memory
> + * @args: contains the vma, start, and and pfns arrays for the migration
> + *
> + * Returns: negative errno on failures, 0 when 0 or more pages were migrated
> + * without an error.
> + *
> + * Prepare to migrate a range of memory virtual address range by collecting 
> all
> + * the pages backing each virtual address in the range, saving them inside 
> the
> + * src array.  Then lock those pages and unmap them. Once the pages are 
> locked
> + * and unmapped, check whether each page is pinned or not.  Pages that aren't
> + * pinned have the MIGRATE_PFN_MIGRATE flag set (by this function) in the
> + * corresponding src array entry.  Then restores any pages that are pinned, 
> by
> + * remapping and unlocking those pages.
> + *
> + * The caller should then allocate destination memory and copy source memory 
> to
> + * it for all those entries (ie with MIGRATE_PFN_VALID and 
> MIGRATE_PFN_MIGRATE
> + * flag set).  Once these are allocated and copied, the caller must update 
> each
> + * corresponding entry in the dst array with the pfn value of the destination
> + * page and with the MIGRATE_PFN_VALID and MIGRATE_PFN_LOCKED flags set
> + * (destination pages must have their struct pages locked, via lock_page()).
> + *
> + * Note that the caller does not have to migrate all the pages that are 
> marked
> + * with MIGRATE_PFN_MIGRATE flag in src array unless this is a migration from
> + * device memory to system memory.  If the caller cannot migrate a device 
> page
> + * back to system memory, then it must return VM_FAULT_SIGBUS, which will
> + * might have severe consequences for the userspace process, so it should 
> best

  ^s/might//  ^s/should 
best/must/

> + * be avoided if possible.
 ^s/if possible//

Maybe adding something about failing only on unrecoverable device error. The
only reason we allow failure for migration here is because GPU devices can
go into bad state (GPU lockup) and when that happens the GPU memory might be
corrupted (power to GPU memory might be cut by GPU driver to recover the
GPU).

So failing migration back to main memory is only a last resort event.


> + *
> + * For empty entries inside CPU page table (pte_none() or pmd_none() is 
> true) we
> + * do set MIGRATE_PFN_MIGRATE flag inside the corresponding source array thus
> + * allowing the caller to allocate device memory for those unback virtual
> + * address.  For this the caller simply havs to allocate device memory and
   ^ haves

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

Re: [PATCH 9/9] mm: remove the MIGRATE_PFN_WRITE flag

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
where it can be replaced with a simple boolean local variable.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Ralph Campbell 


---
  include/linux/migrate.h | 1 -
  mm/migrate.c| 9 +
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 8b46cfdb1a0e..ba74ef5a7702 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -165,7 +165,6 @@ static inline int migrate_misplaced_transhuge_page(struct 
mm_struct *mm,
  #define MIGRATE_PFN_VALID (1UL << 0)
  #define MIGRATE_PFN_MIGRATE   (1UL << 1)
  #define MIGRATE_PFN_LOCKED(1UL << 2)
-#define MIGRATE_PFN_WRITE  (1UL << 3)
  #define MIGRATE_PFN_SHIFT 6
  
  static inline struct page *migrate_pfn_to_page(unsigned long mpfn)

diff --git a/mm/migrate.c b/mm/migrate.c
index 74735256e260..724f92dcc31b 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2212,6 +2212,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
unsigned long mpfn, pfn;
struct page *page;
swp_entry_t entry;
+   bool writable = false;
pte_t pte;
  
  		pte = *ptep;

@@ -2240,7 +2241,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
mpfn = migrate_pfn(page_to_pfn(page)) |
MIGRATE_PFN_MIGRATE;
if (is_write_device_private_entry(entry))
-   mpfn |= MIGRATE_PFN_WRITE;
+   writable = true;
} else {
if (is_zero_pfn(pfn)) {
mpfn = MIGRATE_PFN_MIGRATE;
@@ -2250,7 +2251,8 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
}
page = vm_normal_page(migrate->vma, addr, pte);
mpfn = migrate_pfn(pfn) | MIGRATE_PFN_MIGRATE;
-   mpfn |= pte_write(pte) ? MIGRATE_PFN_WRITE : 0;
+   if (pte_write(pte))
+   writable = true;
}
  
  		/* FIXME support THP */

@@ -2284,8 +2286,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
ptep_get_and_clear(mm, addr, ptep);
  
  			/* Setup special migration page table entry */

-   entry = make_migration_entry(page, mpfn &
-MIGRATE_PFN_WRITE);
+   entry = make_migration_entry(page, writable);
swp_pte = swp_entry_to_pte(entry);
if (pte_soft_dirty(pte))
swp_pte = pte_swp_mksoft_dirty(swp_pte);



MIGRATE_PFN_WRITE may mot being used but that seems like a bug to me.
If a page is migrated to device memory, it could be mapped at the same
time to avoid a device page fault but it would need the flag to know
whether to map it RW or RO. But I suppose that could be inferred from
the vma->vm_flags.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/9] mm: remove the unused MIGRATE_PFN_DEVICE flag

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

No one ever checks this flag, and we could easily get that information
from the page if needed.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Ralph Campbell 


---
  drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
  include/linux/migrate.h| 1 -
  mm/migrate.c   | 4 ++--
  3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 6cb930755970..f04686a2c21f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -582,8 +582,7 @@ static unsigned long nouveau_dmem_migrate_copy_one(struct 
nouveau_drm *drm,
*dma_addr))
goto out_dma_unmap;
  
-	return migrate_pfn(page_to_pfn(dpage)) |

-   MIGRATE_PFN_LOCKED | MIGRATE_PFN_DEVICE;
+   return migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
  
  out_dma_unmap:

dma_unmap_page(dev, *dma_addr, PAGE_SIZE, DMA_BIDIRECTIONAL);
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 229153c2c496..8b46cfdb1a0e 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -166,7 +166,6 @@ static inline int migrate_misplaced_transhuge_page(struct 
mm_struct *mm,
  #define MIGRATE_PFN_MIGRATE   (1UL << 1)
  #define MIGRATE_PFN_LOCKED(1UL << 2)
  #define MIGRATE_PFN_WRITE (1UL << 3)
-#define MIGRATE_PFN_DEVICE (1UL << 4)
  #define MIGRATE_PFN_SHIFT 6
  
  static inline struct page *migrate_pfn_to_page(unsigned long mpfn)

diff --git a/mm/migrate.c b/mm/migrate.c
index dc4e60a496f2..74735256e260 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2237,8 +2237,8 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
goto next;
  
  			page = device_private_entry_to_page(entry);

-   mpfn = migrate_pfn(page_to_pfn(page))|
-   MIGRATE_PFN_DEVICE | MIGRATE_PFN_MIGRATE;
+   mpfn = migrate_pfn(page_to_pfn(page)) |
+   MIGRATE_PFN_MIGRATE;
if (is_write_device_private_entry(entry))
mpfn |= MIGRATE_PFN_WRITE;
} else {


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

Re: [PATCH 7/9] mm: remove the unused MIGRATE_PFN_ERROR flag

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

We don't use this flag anymore, so remove it.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Ralph Campbell 


---
  include/linux/migrate.h | 1 -
  1 file changed, 1 deletion(-)

diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 093d67fcf6dd..229153c2c496 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -167,7 +167,6 @@ static inline int migrate_misplaced_transhuge_page(struct 
mm_struct *mm,
  #define MIGRATE_PFN_LOCKED(1UL << 2)
  #define MIGRATE_PFN_WRITE (1UL << 3)
  #define MIGRATE_PFN_DEVICE(1UL << 4)
-#define MIGRATE_PFN_ERROR  (1UL << 5)
  #define MIGRATE_PFN_SHIFT 6


The MIGRATE_PFN_SHIFT could be reduced to 5 since it is only used
to make room for the flags.


  static inline struct page *migrate_pfn_to_page(unsigned long mpfn)


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

Re: [PATCH 9/9] mm: remove the MIGRATE_PFN_WRITE flag

[Jerome Glisse]

On Mon, Jul 29, 2019 at 05:28:43PM +0300, Christoph Hellwig wrote:
> The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> where it can be replaced with a simple boolean local variable.
> 
> Signed-off-by: Christoph Hellwig 

NAK that flag is useful, for instance a anonymous vma might have
some of its page read only even if the vma has write permission.

It seems that the code in nouveau is wrong (probably lost that
in various rebase/rework) as this flag should be use to decide
wether to map the device memory with write permission or not.

I am traveling right now, i will investigate what happened to
nouveau code.

Cheers,
Jérôme

> ---
>  include/linux/migrate.h | 1 -
>  mm/migrate.c| 9 +
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index 8b46cfdb1a0e..ba74ef5a7702 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -165,7 +165,6 @@ static inline int migrate_misplaced_transhuge_page(struct 
> mm_struct *mm,
>  #define MIGRATE_PFN_VALID(1UL << 0)
>  #define MIGRATE_PFN_MIGRATE  (1UL << 1)
>  #define MIGRATE_PFN_LOCKED   (1UL << 2)
> -#define MIGRATE_PFN_WRITE(1UL << 3)
>  #define MIGRATE_PFN_SHIFT6
>  
>  static inline struct page *migrate_pfn_to_page(unsigned long mpfn)
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 74735256e260..724f92dcc31b 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2212,6 +2212,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>   unsigned long mpfn, pfn;
>   struct page *page;
>   swp_entry_t entry;
> + bool writable = false;
>   pte_t pte;
>  
>   pte = *ptep;
> @@ -2240,7 +2241,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>   mpfn = migrate_pfn(page_to_pfn(page)) |
>   MIGRATE_PFN_MIGRATE;
>   if (is_write_device_private_entry(entry))
> - mpfn |= MIGRATE_PFN_WRITE;
> + writable = true;
>   } else {
>   if (is_zero_pfn(pfn)) {
>   mpfn = MIGRATE_PFN_MIGRATE;
> @@ -2250,7 +2251,8 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>   }
>   page = vm_normal_page(migrate->vma, addr, pte);
>   mpfn = migrate_pfn(pfn) | MIGRATE_PFN_MIGRATE;
> - mpfn |= pte_write(pte) ? MIGRATE_PFN_WRITE : 0;
> + if (pte_write(pte))
> + writable = true;
>   }
>  
>   /* FIXME support THP */
> @@ -2284,8 +2286,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>   ptep_get_and_clear(mm, addr, ptep);
>  
>   /* Setup special migration page table entry */
> - entry = make_migration_entry(page, mpfn &
> -  MIGRATE_PFN_WRITE);
> + entry = make_migration_entry(page, writable);
>   swp_pte = swp_entry_to_pte(entry);
>   if (pte_soft_dirty(pte))
>   swp_pte = pte_swp_mksoft_dirty(swp_pte);
> -- 
> 2.20.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 6/9] nouveau: simplify nouveau_dmem_migrate_vma

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

Factor the main copy page to vram routine out into a helper that acts
on a single page and which doesn't require the nouveau_dmem_migrate
structure for argument passing.  As an added benefit the new version
only allocates the dma address array once and reuses it for each
subsequent chunk of work.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Ralph Campbell 


---
  drivers/gpu/drm/nouveau/nouveau_dmem.c | 185 -
  1 file changed, 56 insertions(+), 129 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 036e6c07d489..6cb930755970 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -44,8 +44,6 @@
  #define DMEM_CHUNK_SIZE (2UL << 20)
  #define DMEM_CHUNK_NPAGES (DMEM_CHUNK_SIZE >> PAGE_SHIFT)
  
-struct nouveau_migrate;

-
  enum nouveau_aper {
NOUVEAU_APER_VIRT,
NOUVEAU_APER_VRAM,
@@ -86,15 +84,6 @@ static inline struct nouveau_dmem *page_to_dmem(struct page 
*page)
return container_of(page->pgmap, struct nouveau_dmem, pagemap);
  }
  
-struct nouveau_migrate {

-   struct vm_area_struct *vma;
-   struct nouveau_drm *drm;
-   struct nouveau_fence *fence;
-   unsigned long npages;
-   dma_addr_t *dma;
-   unsigned long dma_nr;
-};
-
  static unsigned long nouveau_dmem_page_addr(struct page *page)
  {
struct nouveau_dmem_chunk *chunk = page->zone_device_data;
@@ -569,131 +558,67 @@ nouveau_dmem_init(struct nouveau_drm *drm)
drm->dmem = NULL;
  }
  
-static void

-nouveau_dmem_migrate_alloc_and_copy(struct vm_area_struct *vma,
-   const unsigned long *src_pfns,
-   unsigned long *dst_pfns,
-   unsigned long start,
-   unsigned long end,
-   struct nouveau_migrate *migrate)
+static unsigned long nouveau_dmem_migrate_copy_one(struct nouveau_drm *drm,
+   struct vm_area_struct *vma, unsigned long addr,
+   unsigned long src, dma_addr_t *dma_addr)
  {
-   struct nouveau_drm *drm = migrate->drm;
struct device *dev = drm->dev->dev;
-   unsigned long addr, i, npages = 0;
-   nouveau_migrate_copy_t copy;
-   int ret;
-
-   /* First allocate new memory */
-   for (addr = start, i = 0; addr < end; addr += PAGE_SIZE, i++) {
-   struct page *dpage, *spage;
-
-   dst_pfns[i] = 0;
-   spage = migrate_pfn_to_page(src_pfns[i]);
-   if (!spage || !(src_pfns[i] & MIGRATE_PFN_MIGRATE))
-   continue;
-
-   dpage = nouveau_dmem_page_alloc_locked(drm);
-   if (!dpage)
-   continue;
-
-   dst_pfns[i] = migrate_pfn(page_to_pfn(dpage)) |
- MIGRATE_PFN_LOCKED |
- MIGRATE_PFN_DEVICE;
-   npages++;
-   }
-
-   if (!npages)
-   return;
-
-   /* Allocate storage for DMA addresses, so we can unmap later. */
-   migrate->dma = kmalloc(sizeof(*migrate->dma) * npages, GFP_KERNEL);
-   if (!migrate->dma)
-   goto error;
-   migrate->dma_nr = 0;
-
-   /* Copy things over */
-   copy = drm->dmem->migrate.copy_func;
-   for (addr = start, i = 0; addr < end; addr += PAGE_SIZE, i++) {
-   struct page *spage, *dpage;
-
-   dpage = migrate_pfn_to_page(dst_pfns[i]);
-   if (!dpage || dst_pfns[i] == MIGRATE_PFN_ERROR)
-   continue;
-
-   spage = migrate_pfn_to_page(src_pfns[i]);
-   if (!spage || !(src_pfns[i] & MIGRATE_PFN_MIGRATE)) {
-   nouveau_dmem_page_free_locked(drm, dpage);
-   dst_pfns[i] = 0;
-   continue;
-   }
-
-   migrate->dma[migrate->dma_nr] =
-   dma_map_page_attrs(dev, spage, 0, PAGE_SIZE,
-  PCI_DMA_BIDIRECTIONAL,
-  DMA_ATTR_SKIP_CPU_SYNC);
-   if (dma_mapping_error(dev, migrate->dma[migrate->dma_nr])) {
-   nouveau_dmem_page_free_locked(drm, dpage);
-   dst_pfns[i] = 0;
-   continue;
-   }
-
-   ret = copy(drm, 1, NOUVEAU_APER_VRAM,
-   nouveau_dmem_page_addr(dpage),
-   NOUVEAU_APER_HOST,
-   migrate->dma[migrate->dma_nr++]);
-   if (ret) {
-   nouveau_dmem_page_free_locked(drm, dpage);
-   dst_pfns[i] = 0;
-   continue;
-   }
-   }
+   struct page *dpage, *spage;
  
-	nouveau_fence_new(drm->dmem->migra

Re: [PATCH 5/9] nouveau: simplify nouveau_dmem_migrate_to_ram

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

Factor the main copy page to ram routine out into a helper that acts on
a single page and which doesn't require the nouveau_dmem_fault
structure for argument passing.  Also remove the loop over multiple
pages as we only handle one at the moment, although the structure of
the main worker function makes it relatively easy to add multi page
support back if needed in the future.  But at least for now this avoid
the needed to dynamically allocate memory for the dma addresses in
what is essentially the page fault path.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Ralph Campbell 


---
  drivers/gpu/drm/nouveau/nouveau_dmem.c | 158 ++---
  1 file changed, 39 insertions(+), 119 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 21052a4aaf69..036e6c07d489 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -86,13 +86,6 @@ static inline struct nouveau_dmem *page_to_dmem(struct page 
*page)
return container_of(page->pgmap, struct nouveau_dmem, pagemap);
  }
  
-struct nouveau_dmem_fault {

-   struct nouveau_drm *drm;
-   struct nouveau_fence *fence;
-   dma_addr_t *dma;
-   unsigned long npages;
-};
-
  struct nouveau_migrate {
struct vm_area_struct *vma;
struct nouveau_drm *drm;
@@ -146,130 +139,55 @@ static void nouveau_dmem_fence_done(struct nouveau_fence 
**fence)
}
  }
  
-static void

-nouveau_dmem_fault_alloc_and_copy(struct vm_area_struct *vma,
- const unsigned long *src_pfns,
- unsigned long *dst_pfns,
- unsigned long start,
- unsigned long end,
- struct nouveau_dmem_fault *fault)
+static vm_fault_t nouveau_dmem_fault_copy_one(struct nouveau_drm *drm,
+   struct vm_area_struct *vma, unsigned long addr,
+   unsigned long src, unsigned long *dst, dma_addr_t *dma_addr)
  {
-   struct nouveau_drm *drm = fault->drm;
struct device *dev = drm->dev->dev;
-   unsigned long addr, i, npages = 0;
-   nouveau_migrate_copy_t copy;
-   int ret;
-
-
-   /* First allocate new memory */
-   for (addr = start, i = 0; addr < end; addr += PAGE_SIZE, i++) {
-   struct page *dpage, *spage;
-
-   dst_pfns[i] = 0;
-   spage = migrate_pfn_to_page(src_pfns[i]);
-   if (!spage || !(src_pfns[i] & MIGRATE_PFN_MIGRATE))
-   continue;
+   struct page *dpage, *spage;
  
-		dpage = alloc_page_vma(GFP_HIGHUSER, vma, addr);

-   if (!dpage) {
-   dst_pfns[i] = MIGRATE_PFN_ERROR;
-   continue;
-   }
-   lock_page(dpage);
-
-   dst_pfns[i] = migrate_pfn(page_to_pfn(dpage)) |
- MIGRATE_PFN_LOCKED;
-   npages++;
-   }
+   spage = migrate_pfn_to_page(src);
+   if (!spage || !(src & MIGRATE_PFN_MIGRATE))
+   return 0;
  
-	/* Allocate storage for DMA addresses, so we can unmap later. */

-   fault->dma = kmalloc(sizeof(*fault->dma) * npages, GFP_KERNEL);
-   if (!fault->dma)
+   dpage = alloc_page_vma(GFP_HIGHUSER, args->vma, addr);
+   if (!dpage)
goto error;
+   lock_page(dpage);
  
-	/* Copy things over */

-   copy = drm->dmem->migrate.copy_func;
-   for (addr = start, i = 0; addr < end; addr += PAGE_SIZE, i++) {
-   struct page *spage, *dpage;
-
-   dpage = migrate_pfn_to_page(dst_pfns[i]);
-   if (!dpage || dst_pfns[i] == MIGRATE_PFN_ERROR)
-   continue;
-
-   spage = migrate_pfn_to_page(src_pfns[i]);
-   if (!spage || !(src_pfns[i] & MIGRATE_PFN_MIGRATE)) {
-   dst_pfns[i] = MIGRATE_PFN_ERROR;
-   __free_page(dpage);
-   continue;
-   }
-
-   fault->dma[fault->npages] =
-   dma_map_page_attrs(dev, dpage, 0, PAGE_SIZE,
-  PCI_DMA_BIDIRECTIONAL,
-  DMA_ATTR_SKIP_CPU_SYNC);
-   if (dma_mapping_error(dev, fault->dma[fault->npages])) {
-   dst_pfns[i] = MIGRATE_PFN_ERROR;
-   __free_page(dpage);
-   continue;
-   }
-
-   ret = copy(drm, 1, NOUVEAU_APER_HOST,
-   fault->dma[fault->npages++],
-   NOUVEAU_APER_VRAM,
-   nouveau_dmem_page_addr(spage));
-   if (ret) {
-   dst_pfns[i] = MIGRATE_PFN_ERROR;
-   __free_page(dpage);
-   continue;
-

Re: [PATCH 4/9] nouveau: factor out dmem fence completion

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

Factor out the end of fencing logic from the two migration routines.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Ralph Campbell 


---
  drivers/gpu/drm/nouveau/nouveau_dmem.c | 33 --
  1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index d469bc334438..21052a4aaf69 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -133,6 +133,19 @@ static void nouveau_dmem_page_free(struct page *page)
spin_unlock(&chunk->lock);
  }
  
+static void nouveau_dmem_fence_done(struct nouveau_fence **fence)

+{
+   if (fence) {
+   nouveau_fence_wait(*fence, true, false);
+   nouveau_fence_unref(fence);
+   } else {
+   /*
+* FIXME wait for channel to be IDLE before calling finalizing
+* the hmem object.
+*/
+   }
+}
+
  static void
  nouveau_dmem_fault_alloc_and_copy(struct vm_area_struct *vma,
  const unsigned long *src_pfns,
@@ -236,15 +249,7 @@ nouveau_dmem_fault_finalize_and_map(struct 
nouveau_dmem_fault *fault)
  {
struct nouveau_drm *drm = fault->drm;
  
-	if (fault->fence) {

-   nouveau_fence_wait(fault->fence, true, false);
-   nouveau_fence_unref(&fault->fence);
-   } else {
-   /*
-* FIXME wait for channel to be IDLE before calling finalizing
-* the hmem object below (nouveau_migrate_hmem_fini()).
-*/
-   }
+   nouveau_dmem_fence_done(&fault->fence);
  
  	while (fault->npages--) {

dma_unmap_page(drm->dev->dev, fault->dma[fault->npages],
@@ -748,15 +753,7 @@ nouveau_dmem_migrate_finalize_and_map(struct 
nouveau_migrate *migrate)
  {
struct nouveau_drm *drm = migrate->drm;
  
-	if (migrate->fence) {

-   nouveau_fence_wait(migrate->fence, true, false);
-   nouveau_fence_unref(&migrate->fence);
-   } else {
-   /*
-* FIXME wait for channel to be IDLE before finalizing
-* the hmem object below (nouveau_migrate_hmem_fini()) ?
-*/
-   }
+   nouveau_dmem_fence_done(&migrate->fence);
  
  	while (migrate->dma_nr--) {

dma_unmap_page(drm->dev->dev, migrate->dma[migrate->dma_nr],


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

Re: [PATCH 3/9] nouveau: factor out device memory address calculation

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

Factor out the repeated device memory address calculation into
a helper.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Ralph Campbell 


---
  drivers/gpu/drm/nouveau/nouveau_dmem.c | 42 +++---
  1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index e696157f771e..d469bc334438 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -102,6 +102,14 @@ struct nouveau_migrate {
unsigned long dma_nr;
  };
  
+static unsigned long nouveau_dmem_page_addr(struct page *page)

+{
+   struct nouveau_dmem_chunk *chunk = page->zone_device_data;
+   unsigned long idx = page_to_pfn(page) - chunk->pfn_first;
+
+   return (idx << PAGE_SHIFT) + chunk->bo->bo.offset;
+}
+
  static void nouveau_dmem_page_free(struct page *page)
  {
struct nouveau_dmem_chunk *chunk = page->zone_device_data;
@@ -169,9 +177,7 @@ nouveau_dmem_fault_alloc_and_copy(struct vm_area_struct 
*vma,
/* Copy things over */
copy = drm->dmem->migrate.copy_func;
for (addr = start, i = 0; addr < end; addr += PAGE_SIZE, i++) {
-   struct nouveau_dmem_chunk *chunk;
struct page *spage, *dpage;
-   u64 src_addr, dst_addr;
  
  		dpage = migrate_pfn_to_page(dst_pfns[i]);

if (!dpage || dst_pfns[i] == MIGRATE_PFN_ERROR)
@@ -194,14 +200,10 @@ nouveau_dmem_fault_alloc_and_copy(struct vm_area_struct 
*vma,
continue;
}
  
-		dst_addr = fault->dma[fault->npages++];

-
-   chunk = spage->zone_device_data;
-   src_addr = page_to_pfn(spage) - chunk->pfn_first;
-   src_addr = (src_addr << PAGE_SHIFT) + chunk->bo->bo.offset;
-
-   ret = copy(drm, 1, NOUVEAU_APER_HOST, dst_addr,
-  NOUVEAU_APER_VRAM, src_addr);
+   ret = copy(drm, 1, NOUVEAU_APER_HOST,
+   fault->dma[fault->npages++],
+   NOUVEAU_APER_VRAM,
+   nouveau_dmem_page_addr(spage));
if (ret) {
dst_pfns[i] = MIGRATE_PFN_ERROR;
__free_page(dpage);
@@ -687,18 +689,12 @@ nouveau_dmem_migrate_alloc_and_copy(struct vm_area_struct 
*vma,
/* Copy things over */
copy = drm->dmem->migrate.copy_func;
for (addr = start, i = 0; addr < end; addr += PAGE_SIZE, i++) {
-   struct nouveau_dmem_chunk *chunk;
struct page *spage, *dpage;
-   u64 src_addr, dst_addr;
  
  		dpage = migrate_pfn_to_page(dst_pfns[i]);

if (!dpage || dst_pfns[i] == MIGRATE_PFN_ERROR)
continue;
  
-		chunk = dpage->zone_device_data;

-   dst_addr = page_to_pfn(dpage) - chunk->pfn_first;
-   dst_addr = (dst_addr << PAGE_SHIFT) + chunk->bo->bo.offset;
-
spage = migrate_pfn_to_page(src_pfns[i]);
if (!spage || !(src_pfns[i] & MIGRATE_PFN_MIGRATE)) {
nouveau_dmem_page_free_locked(drm, dpage);
@@ -716,10 +712,10 @@ nouveau_dmem_migrate_alloc_and_copy(struct vm_area_struct 
*vma,
continue;
}
  
-		src_addr = migrate->dma[migrate->dma_nr++];

-
-   ret = copy(drm, 1, NOUVEAU_APER_VRAM, dst_addr,
-  NOUVEAU_APER_HOST, src_addr);
+   ret = copy(drm, 1, NOUVEAU_APER_VRAM,
+   nouveau_dmem_page_addr(dpage),
+   NOUVEAU_APER_HOST,
+   migrate->dma[migrate->dma_nr++]);
if (ret) {
nouveau_dmem_page_free_locked(drm, dpage);
dst_pfns[i] = 0;
@@ -846,7 +842,6 @@ nouveau_dmem_convert_pfn(struct nouveau_drm *drm,
  
  	npages = (range->end - range->start) >> PAGE_SHIFT;

for (i = 0; i < npages; ++i) {
-   struct nouveau_dmem_chunk *chunk;
struct page *page;
uint64_t addr;
  
@@ -864,10 +859,7 @@ nouveau_dmem_convert_pfn(struct nouveau_drm *drm,

continue;
}
  
-		chunk = page->zone_device_data;

-   addr = page_to_pfn(page) - chunk->pfn_first;
-   addr = (addr + chunk->bo->bo.mem.start) << PAGE_SHIFT;
-
+   addr = nouveau_dmem_page_addr(page);
range->pfns[i] &= ((1UL << range->pfn_shift) - 1);
range->pfns[i] |= (addr >> PAGE_SHIFT) << range->pfn_shift;
}


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

Re: [PATCH 1/7] docs: fix broken doc references due to renames

[Paul E. McKenney]

On Fri, Jul 26, 2019 at 08:47:21AM -0300, Mauro Carvalho Chehab wrote:
> Some files got renamed but probably due to some merge conflicts,
> a few references still point to the old locations.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> Acked-by: Wolfram Sang  # I2C part
> Reviewed-by: Jerry Hoemann  # hpwdt.rst

Acked-by: Paul E. McKenney 

> ---
>  Documentation/RCU/rculist_nulls.txt   |  2 +-
>  Documentation/devicetree/bindings/arm/idle-states.txt |  2 +-
>  Documentation/locking/spinlocks.rst   |  4 ++--
>  Documentation/memory-barriers.txt |  2 +-
>  Documentation/translations/ko_KR/memory-barriers.txt  |  2 +-
>  Documentation/watchdog/hpwdt.rst  |  2 +-
>  MAINTAINERS   | 10 +-
>  drivers/gpu/drm/drm_modes.c   |  2 +-
>  drivers/i2c/busses/i2c-nvidia-gpu.c   |  2 +-
>  drivers/scsi/hpsa.c   |  4 ++--
>  10 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/RCU/rculist_nulls.txt 
> b/Documentation/RCU/rculist_nulls.txt
> index 8151f0195f76..23f115dc87cf 100644
> --- a/Documentation/RCU/rculist_nulls.txt
> +++ b/Documentation/RCU/rculist_nulls.txt
> @@ -1,7 +1,7 @@
>  Using hlist_nulls to protect read-mostly linked lists and
>  objects using SLAB_TYPESAFE_BY_RCU allocations.
>  
> -Please read the basics in Documentation/RCU/listRCU.txt
> +Please read the basics in Documentation/RCU/listRCU.rst
>  
>  Using special makers (called 'nulls') is a convenient way
>  to solve following problem :
> diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt 
> b/Documentation/devicetree/bindings/arm/idle-states.txt
> index 326f29b270ad..2d325bed37e5 100644
> --- a/Documentation/devicetree/bindings/arm/idle-states.txt
> +++ b/Documentation/devicetree/bindings/arm/idle-states.txt
> @@ -703,4 +703,4 @@ cpus {
>  https://www.devicetree.org/specifications/
>  
>  [6] ARM Linux Kernel documentation - Booting AArch64 Linux
> -Documentation/arm64/booting.txt
> +Documentation/arm64/booting.rst
> diff --git a/Documentation/locking/spinlocks.rst 
> b/Documentation/locking/spinlocks.rst
> index 098107fb7d86..e93ec6645238 100644
> --- a/Documentation/locking/spinlocks.rst
> +++ b/Documentation/locking/spinlocks.rst
> @@ -82,7 +82,7 @@ itself.  The read lock allows many concurrent readers.  
> Anything that
>  **changes** the list will have to get the write lock.
>  
> NOTE! RCU is better for list traversal, but requires careful
> -   attention to design detail (see Documentation/RCU/listRCU.txt).
> +   attention to design detail (see Documentation/RCU/listRCU.rst).
>  
>  Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
>  time need to do any changes (even if you don't do it every time), you have
> @@ -90,7 +90,7 @@ to get the write-lock at the very beginning.
>  
> NOTE! We are working hard to remove reader-writer spinlocks in most
> cases, so please don't add a new one without consensus.  (Instead, see
> -   Documentation/RCU/rcu.txt for complete information.)
> +   Documentation/RCU/rcu.rst for complete information.)
>  
>  
>  
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index 045bb8148fe9..1adbb8a371c7 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -548,7 +548,7 @@ There are certain things that the Linux kernel memory 
> barriers do not guarantee:
>  
>   [*] For information on bus mastering DMA and coherency please read:
>  
> - Documentation/PCI/pci.rst
> + Documentation/driver-api/pci/pci.rst
>   Documentation/DMA-API-HOWTO.txt
>   Documentation/DMA-API.txt
>  
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
> b/Documentation/translations/ko_KR/memory-barriers.txt
> index a33c2a536542..2774624ee843 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -569,7 +569,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 
>  
>   [*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다:
>  
> - Documentation/PCI/pci.rst
> + Documentation/driver-api/pci/pci.rst
>   Documentation/DMA-API-HOWTO.txt
>   Documentation/DMA-API.txt
>  
> diff --git a/Documentation/watchdog/hpwdt.rst 
> b/Documentation/watchdog/hpwdt.rst
> index c165d92cfd12..c824cd7f6e32 100644
> --- a/Documentation/watchdog/hpwdt.rst
> +++ b/Documentation/watchdog/hpwdt.rst
> @@ -63,7 +63,7 @@ Last reviewed: 08/20/2018
>   and loop forever.  This is generally not what a watchdog user wants.
>  
>   For those wishing to learn more please see:
> - Documentation/kdump/kdump.rst
> + Documentation/admin-guide/kdump/kdump.rst
>   Documentation/admin-guide/kernel-parameters.txt (panic=)
>   Your Linux Distribution specific docume

Re: [PATCH 2/9] nouveau: reset dma_nr in nouveau_dmem_migrate_alloc_and_copy

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

When we start a new batch of dma_map operations we need to reset dma_nr,
as we start filling a newly allocated array.

Signed-off-by: Christoph Hellwig 


Reviewed-by: Ralph Campbell 


---
  drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 38416798abd4..e696157f771e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -682,6 +682,7 @@ nouveau_dmem_migrate_alloc_and_copy(struct vm_area_struct 
*vma,
migrate->dma = kmalloc(sizeof(*migrate->dma) * npages, GFP_KERNEL);
if (!migrate->dma)
goto error;
+   migrate->dma_nr = 0;
  
  	/* Copy things over */

copy = drm->dmem->migrate.copy_func;


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

[Bug 111232] 3200 Memory Crash My System

[bugzilla-daemon]

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

--- Comment #2 from bibitocarlos  ---
(In reply to Alex Deucher from comment #1)
> Can you bisect?

I'm gonna try ^^, never did it before and leave to holydays Friday.
I'm gonna start with RC, then whith commits.
You think it's a proper way ?

-- 
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 1/9] mm: turn migrate_vma upside down

[Ralph Campbell]

On 7/29/19 7:28 AM, Christoph Hellwig wrote:

There isn't any good reason to pass callbacks to migrate_vma.  Instead
we can just export the three steps done by this function to drivers and
let them sequence the operation without callbacks.  This removes a lot
of boilerplate code as-is, and will allow the drivers to drastically
improve code flow and error handling further on.

Signed-off-by: Christoph Hellwig 


Except for a few white space errors ( and $),
looks OK.

Reviewed-by: Ralph Campbell 


---
  Documentation/vm/hmm.rst   |  55 +-
  drivers/gpu/drm/nouveau/nouveau_dmem.c | 122 +++--
  include/linux/migrate.h| 118 ++--
  mm/migrate.c   | 242 +++--
  4 files changed, 193 insertions(+), 344 deletions(-)

diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index ddcb5ca8b296..ad880e3996b1 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -339,58 +339,9 @@ Migration to and from device memory
  ===
  
  Because the CPU cannot access device memory, migration must use the device DMA

-engine to perform copy from and to device memory. For this we need a new
-migration helper::
-
- int migrate_vma(const struct migrate_vma_ops *ops,
- struct vm_area_struct *vma,
- unsigned long mentries,
- unsigned long start,
- unsigned long end,
- unsigned long *src,
- unsigned long *dst,
- void *private);
-
-Unlike other migration functions it works on a range of virtual address, there
-are two reasons for that. First, device DMA copy has a high setup overhead cost
-and thus batching multiple pages is needed as otherwise the migration overhead
-makes the whole exercise pointless. The second reason is because the
-migration might be for a range of addresses the device is actively accessing.
-
-The migrate_vma_ops struct defines two callbacks. First one (alloc_and_copy())
-controls destination memory allocation and copy operation. Second one is there
-to allow the device driver to perform cleanup operations after migration::
-
- struct migrate_vma_ops {
- void (*alloc_and_copy)(struct vm_area_struct *vma,
-const unsigned long *src,
-unsigned long *dst,
-unsigned long start,
-unsigned long end,
-void *private);
- void (*finalize_and_map)(struct vm_area_struct *vma,
-  const unsigned long *src,
-  const unsigned long *dst,
-  unsigned long start,
-  unsigned long end,
-  void *private);
- };
-
-It is important to stress that these migration helpers allow for holes in the
-virtual address range. Some pages in the range might not be migrated for all
-the usual reasons (page is pinned, page is locked, ...). This helper does not
-fail but just skips over those pages.
-
-The alloc_and_copy() might decide to not migrate all pages in the
-range (for reasons under the callback control). For those, the callback just
-has to leave the corresponding dst entry empty.
-
-Finally, the migration of the struct page might fail (for file backed page) for
-various reasons (failure to freeze reference, or update page cache, ...). If
-that happens, then the finalize_and_map() can catch any pages that were not
-migrated. Note those pages were still copied to a new page and thus we wasted
-bandwidth but this is considered as a rare event and a price that we are
-willing to pay to keep all the code simpler.
+engine to perform copy from and to device memory. For this we need a new to
+use migrate_vma_setup(), migrate_vma_pages(), and migrate_vma_finalize()
+helpers.
  
  
  Memory cgroup (memcg) and rss accounting

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 345c63cb752a..38416798abd4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -131,9 +131,8 @@ nouveau_dmem_fault_alloc_and_copy(struct vm_area_struct 
*vma,
  unsigned long *dst_pfns,
  unsigned long start,
  unsigned long end,
- void *private)
+ struct nouveau_dmem_fault *fault)
  {
-   struct nouveau_dmem_fault *fault = private;
struct nouveau_drm *drm = fault->drm;
struct device *dev = drm->dev->dev;
unsigned long addr, i, npages = 0;
@@ -230,14 +229,9 @@ nouveau_dmem_fault_alloc_and_copy(struct vm_area_struct 
*vma,
}
  }
  
-void nouveau_dmem_fault_finalize_and_map(struct vm_area_struct *vma,

-const unsign

[PATCH] drm: sti: Mark expected switch fall-throughs

[Gustavo A. R. Silva]

Mark switch cases where we are expecting to fall through.

This patch fixes the following warning (Building: arm):

drivers/gpu/drm/sti/sti_hdmi.c: In function ‘hdmi_audio_configure’:
drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   audio_cfg |= HDMI_AUD_CFG_CH78_VALID;
drivers/gpu/drm/sti/sti_hdmi.c:852:2: note: here
  case 6:
  ^~~~
drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   audio_cfg |= HDMI_AUD_CFG_CH56_VALID;
drivers/gpu/drm/sti/sti_hdmi.c:854:2: note: here
  case 4:
  ^~~~
drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   audio_cfg |= HDMI_AUD_CFG_CH34_VALID | HDMI_AUD_CFG_8CH;
drivers/gpu/drm/sti/sti_hdmi.c:856:2: note: here
  case 2:
  ^~~~

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index f03d617edc4c..1617c5098a50 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -849,10 +849,13 @@ static int hdmi_audio_configure(struct sti_hdmi *hdmi)
switch (info->channels) {
case 8:
audio_cfg |= HDMI_AUD_CFG_CH78_VALID;
+   /* fall through */
case 6:
audio_cfg |= HDMI_AUD_CFG_CH56_VALID;
+   /* fall through */
case 4:
audio_cfg |= HDMI_AUD_CFG_CH34_VALID | HDMI_AUD_CFG_8CH;
+   /* fall through */
case 2:
audio_cfg |= HDMI_AUD_CFG_CH12_VALID;
break;
-- 
2.22.0

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

[Bug 110637] Any OpenCL application causes "*ERROR* ring gfx timeout" on Vega 64

[bugzilla-daemon]

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

--- Comment #10 from Alexander Mezin  ---
(In reply to Alex Deucher from comment #3)
> More likely a bug in the mesa OpenCL code.  If you want functional OpenCL,
> you should use the ROCm OpenCL packages.

Do you mean "Mesa OpenCL is not supported/unmaintained"?

I still can't get any OpenCL application to work (even "Hello World" examples).

Mesa 18.3.4, 19.0.x - GPU hangs then resets. But judging by power consumption
(hwmon, 70W - higher than usual idle power consumption) GPU continues to do
something even after reset

Mesa 19.1.x, git master - GPU doesn't hang but applications themselves hang on
the first clFinish. Power consumption stays higher than typical idle power
again.

Building ROCm from source is a huge pain.

-- 
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 0/1] This patch fixes connection detection for monitors w/o DDC.

[Daniel Vetter]

On Mon, Jul 29, 2019 at 12:58 PM Oleksandr Suvorov
 wrote:
>
> On Thu, Jul 25, 2019 at 5:41 PM maxime.rip...@free-electrons.com
>  wrote:
> >
> > On Thu, Jul 25, 2019 at 11:05:23AM +, Oleksandr Suvorov wrote:
> > >
> > > Even in source code of this driver there is an author's description:
> > > /*
> > >  * Even if we have an I2C bus, we can't assume that the cable
> > >  * is disconnected if drm_probe_ddc fails. Some cables don't
> > >  * wire the DDC pins, or the I2C bus might not be working at
> > >  * all.
> > >  */
> > >
> > > That's true. DDC and VGA channels are independent, and therefore
> > > we cannot decide whether the monitor is connected or not,
> > > depending on the information from the DDC.
> > >
> > > So the monitor should always be considered connected.
> >
> > Well, no. Like you said, we cannot decided whether is connected or
> > not.
>
> Maxime, thanks, I agree that's a bad solution.
> But I still think we should be able to define the DT node of a device for
> this driver to claim the connector is always connected.
> Please see my following thoughts.
>
> > > Thus there is no reason to use connector detect callback for this
> > > driver: DRM sub-system considers monitor always connected if there
> > > is no detect() callback registered with drm_connector_init().
> > >
> > > How to reproduce the bug:
> > > * setup: i.MX8QXP, LCDIF video module + gpu/drm/mxsfb driver,
> > >   adv712x VGA DAC + dumb-vga-dac driver, VGA-connector w/o DDC;
> > > * try to use drivers chain mxsfb-drm + dumb-vga-dac;
> > > * any DRM applications consider the monitor is not connected:
> > >   ===
> > >   $ weston-start
> > >   $ cat /var/log/weston.log
> > >   ...
> > >   DRM: head 'VGA-1' found, connector 32 is disconnected.
> > >   ...
> > >   $ cat /sys/devices/platform/5a18.lcdif/drm/card0/card0-VGA-1/status
> > >   unknown
> >
> > And that's exactly what's being reported here: we cannot decide if it
> > is connected or not, so it's unknown.
> >
> > If weston chooses to ignore connectors that are in an unknown state,
> > I'd say it's weston's problem, since it's much broader than this
> > particular device.
>
> If we look at the code of drm_probe_helper.c, we can see, the
> drm_helper_probe_detect_ctx() assume the cable is connected if there is no
> detect() callback registered.
> ...
> if (funcs->detect_ctx)
>  ret = funcs->detect_ctx(connector, &ctx, force);
>  else if (connector->funcs->detect)
>  ret = connector->funcs->detect(connector, force);
>  else
>  ret = connector_status_connected;
> ...
>
> The driver dumb-vga-dac supports both DT configurations:
> - with DDC channel, that allows us to detect if the cable is connected;
> - without DDC channel. In this case, IMHO, the driver should behave
> the same way as a
>   connector driver without registered detect() callback.
>
> So what about the patch like?

Still no. The "always connected" case is for outputs which are
physically always connected and typing a dummy function which would
unconditionally return connected would be silly. Like built-in panels.
This is _not_ for external screens.
-Daniel

>
> @@ -81,6 +81,13 @@ dumb_vga_connector_detect(struct drm_connector
> *connector, bool force)
>  {
> struct dumb_vga *vga = drm_connector_to_dumb_vga(connector);
>
> +   /*
> +* If I2C bus for DDC is not defined, asume that the cable
> +* is always connected.
> +*/
> +   if (PTR_ERR(vga->ddc) == -ENODEV)
> +   return connector_status_connected;
> +
> /*
>  * Even if we have an I2C bus, we can't assume that the cable
>  * is disconnected if drm_probe_ddc fails. Some cables don't
>
> --
> Best regards
> Oleksandr Suvorov
>
> Toradex AG
> Altsagenstrasse 5 | 6048 Horw/Luzern | Switzerland | T: +41 41 500
> 4800 (main line)



-- 
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

[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

[bugzilla-daemon]

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

--- Comment #54 from ReddestDream  ---
(In reply to Peter Hercek from comment #52)
> I'm getting hangs-up with kernels 5.2.3 (often) and 5.1.15 (less often).
> Radeon VII with 3 monitors. Each monitor connected through DP.

I hear that 5.0.0.13 is from before this regression and should work without
issue if you are willing to downgrade:

https://bbs.archlinux.org/viewtopic.php?id=247733

(In reply to Anthony Rabbito from comment #53)
> Interesting, on 5.2.x with 2 monitors hooked up via HDMI and DP it behaves
> 75% of the time with most issues coming from xinit or sleep. Hopefully 5.3
> will contain fixes

Would be interesting if it turns out that using HDMI+DP fixes the issue. Not
that HDMI doesn't come with its own issues sometimes with color. I do have some
faith that 5.3 will fix it since AMDGPU is getting a lot of work for Navi. I
plan to try out 5.3-rc2 (or whatever mainline is at) sometime this week.

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

[Bug 110963] Wrong condition and wrong variable substitution in libgl1-amdgpu-mesa-dri in postinst script

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #3 from Jeremy Newton  ---
This should be fixed. I back ported it internally, but I'm not sure what build
it'll be in.

-- 
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 110961] Are provided libdrm packages completely open source?

[bugzilla-daemon]

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

--- Comment #3 from Jeremy Newton  ---
I believe libdrm is open source with minor patches.

MIT does not require distributing source code, although with that said, I am
looking into doing this none the less.

-- 
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 110962] Wrong dependencies cause force dependency on amdgpu-dkms

[bugzilla-daemon]

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

--- Comment #3 from Jeremy Newton  ---
This configuration is not supported. PRO unconditionally requires dkms.

I will try to update the documentation.

-- 
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 110956] List of 19.20-812932 release mistakes

[bugzilla-daemon]

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

--- Comment #8 from Jeremy Newton  ---
A few notes:
- Installing on 32bit is unsupported, but you could in theory still do it as I
don't thing we block this. This configuration is not advised.
- I am looking into a better way of providing source packages for open
components. I might just make a PPA but design is pending.
- We do not support --no-dkms with --pro, granted this should be documented but
is likely not.
- PX should be marked as deprecated in the installer, this is likely not yet
documented correctly.
- I'm aware of the mesa dri post install script issues. I pushed some fixes,
but I'm not sure which build it landed in.

Will try to address the individual bugs if I haven't done so already.

-- 
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 110956] List of 19.20-812932 release mistakes

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  ---
(In reply to Eric Engestrom from comment #6)
> (In reply to Ilia Mirkin from comment #5)
> > I think it's the right bugracker. Note that DRM/AMDgpu-pro component. It's
> > meant for the AMD developers who very much have control (or at least
> > influence) over these things.
> 
> Something just dawned on me: as amdgpu-pro is closed source, is it only ever
> distributed as ubuntu packages, and therefore AMD are the ones making these
> packages?

They are just packaged drivers.  Most of it is open source.  There are a few
closed source components you can optionally install for workstation parts but
everything else is open source.

-- 
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 110967] Naming packages with pro suffix depending if open or close source

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Jeremy Newton  ---
The pro suffix denotes that it's a part of the PRO stack, not propriety (yes
misleading name, I know).

"PRO" does not mean it's closed source, though most of the PRO stack is closed.

ROCT for example is MIT as it's borrowed from ROCm.

As for the rest:
-AMF is closed source AFAIK
-opencl is closed source; this will be migrated to ROCm (MIT), but this is low
priority since ROCm is already completely packaged elsewhere.

We might strip the -pro from roct when we switch to ROCm, but I don't believe
there's a plan set in stone right now.

Closing as invalid for now.

-- 
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 110956] List of 19.20-812932 release mistakes

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110956
Bug 110956 depends on bug 110967, which changed state.

Bug 110967 Summary: Naming packages with pro suffix depending if open or close 
source
https://bugs.freedesktop.org/show_bug.cgi?id=110967

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

-- 
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 110957] wsa-amdgpu package has empty copyright file

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Jeremy Newton  ---
We are dropping this component in the near future, so I'm going to close this
as WONTFIX.

Thanks for the report though.

-- 
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 110956] List of 19.20-812932 release mistakes

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110956
Bug 110956 depends on bug 110957, which changed state.

Bug 110957 Summary: wsa-amdgpu package has empty copyright file
https://bugs.freedesktop.org/show_bug.cgi?id=110957

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

-- 
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 110960] Non-existent alternative dependencies in some deb packages

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Jeremy Newton  ---
Thanks for the input.

This is more of a "in case we need them" situation.

I believe our RHEL driver includes these packages since they do not come in the
standard RHEL repos, but we don't have the limitation with Ubuntu, or at least
not right now.

-- 
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 110956] List of 19.20-812932 release mistakes

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=110956
Bug 110956 depends on bug 110960, which changed state.

Bug 110960 Summary: Non-existent alternative dependencies in some deb packages
https://bugs.freedesktop.org/show_bug.cgi?id=110960

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

-- 
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 111243] Installation of 19.20 Fails

[bugzilla-daemon]

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

--- Comment #1 from Jeremy Newton  ---
It looks like you didn't do a clean install. For the time being, we recommend a
full uninstall and reinstall after every driver update.

-- 
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 111103] [Patch] to compile amdgpu-dkms 19.20 on debian stretch & buster

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #2 from Jeremy Newton  ---
Hi thanks for the patch!

We are re-hauling the dkms package for 19.40, so please hold tight. In the
future, it should work on more kernels without patches.

Closing as WONTFIX for now

-- 
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 110898] [Patch] to compile amdgpu-dkms 19.10 on debian stretch & buster

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #3 from Jeremy Newton  ---
Hi thanks for the patch!

We are re-hauling the dkms package for 19.40, so please hold tight. In the
future, it should work on more kernels without patches.

Closing as WONTFIX for now

-- 
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

[RFC 3/4] drm/mipi-dbi: Support command mode panel drivers

[Noralf Trønnes]

This adds a function that registers a DRM driver for use with MIPI DBI
panels in command mode. That is, framebuffer upload over DBI.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 110 +
 include/drm/drm_mipi_dbi.h |   8 +++
 2 files changed, 118 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 1961f713aaab..ef6b843eaf31 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -17,11 +18,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -597,6 +600,113 @@ void mipi_dbi_release(struct drm_device *drm)
 }
 EXPORT_SYMBOL(mipi_dbi_release);
 
+static void drm_mipi_dbi_panel_pipe_enable(struct drm_simple_display_pipe 
*pipe,
+  struct drm_crtc_state *crtc_state,
+  struct drm_plane_state *plane_state)
+{
+   struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+   struct drm_panel *panel = dbidev->panel;
+   int ret, idx;
+
+   if (!drm_dev_enter(pipe->crtc.dev, &idx))
+   return;
+
+   DRM_DEBUG_KMS("\n");
+
+   ret = drm_panel_prepare(panel);
+   if (ret)
+   goto out_exit;
+
+   mipi_dbi_enable_flush(dbidev, crtc_state, plane_state);
+
+   drm_panel_enable(panel);
+out_exit:
+   drm_dev_exit(idx);
+}
+
+static void drm_mipi_dbi_panel_pipe_disable(struct drm_simple_display_pipe 
*pipe)
+{
+   struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+   struct drm_panel *panel = dbidev->panel;
+
+   if (!dbidev->enabled)
+   return;
+
+   DRM_DEBUG_KMS("\n");
+
+   dbidev->enabled = false;
+   drm_panel_disable(panel);
+   drm_panel_unprepare(panel);
+}
+
+static const struct drm_simple_display_pipe_funcs drm_mipi_dbi_pipe_funcs = {
+   .enable = drm_mipi_dbi_panel_pipe_enable,
+   .disable = drm_mipi_dbi_panel_pipe_disable,
+   .update = mipi_dbi_pipe_update,
+   .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+};
+
+DEFINE_DRM_GEM_CMA_FOPS(drm_mipi_dbi_fops);
+
+static struct drm_driver drm_mipi_dbi_driver = {
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+   .fops   = &drm_mipi_dbi_fops,
+   .release= mipi_dbi_release,
+   DRM_GEM_CMA_VMAP_DRIVER_OPS,
+   .debugfs_init   = mipi_dbi_debugfs_init,
+   .name   = "drm_mipi_dbi",
+   .desc   = "DRM MIPI DBI",
+   .date   = "20190729",
+   .major  = 1,
+   .minor  = 0,
+};
+
+/**
+ * drm_mipi_dbi_panel_register - Register a MIPI DBI DRM driver
+ * @panel: DRM Panel
+ * @dbidev: MIPI DBI device structure to initialize
+ * @mode: Display mode
+ *
+ * This function registeres a DRM driver with @panel attached.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int drm_mipi_dbi_panel_register(struct drm_panel *panel, struct mipi_dbi_dev 
*dbidev,
+   const struct drm_display_mode *mode)
+{
+   struct device *dev = panel->dev;
+   struct drm_device *drm;
+   u32 rotation = 0;
+   int ret;
+
+   dbidev->panel = panel;
+
+   drm = &dbidev->drm;
+   ret = devm_drm_dev_init(dev, drm, &drm_mipi_dbi_driver);
+   if (ret) {
+   kfree(dbidev);
+   return ret;
+   }
+
+   drm_mode_config_init(drm);
+
+   device_property_read_u32(dev, "rotation", &rotation);
+
+   ret = mipi_dbi_dev_init(dbidev, &drm_mipi_dbi_pipe_funcs, mode, 
rotation);
+
+   drm_mode_config_reset(drm);
+
+   ret = drm_dev_register(drm, 0);
+   if (ret)
+   return ret;
+
+   drm_fbdev_generic_setup(drm, 16);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mipi_dbi_panel_register);
+
 /**
  * mipi_dbi_hw_reset - Hardware reset of controller
  * @dbi: MIPI DBI structure
diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
index 67c66f5ee591..e5047208ffb8 100644
--- a/include/drm/drm_mipi_dbi.h
+++ b/include/drm/drm_mipi_dbi.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 
+struct drm_panel;
 struct drm_rect;
 struct spi_device;
 struct gpio_desc;
@@ -123,6 +124,11 @@ struct mipi_dbi_dev {
 * @dbi: MIPI DBI interface
 */
struct mipi_dbi dbi;
+
+   /**
+* @panel: Attached DRM panel. See drm_mipi_dbi_panel_register().
+*/
+   struct drm_panel *panel;
 };
 
 static inline struct mipi_dbi_dev *drm_to_mipi_dbi_dev(struct drm_device *drm)
@@ -140,6 +146,8 @@ i

[RFC 4/4] drm/panel/ili9341: Support mi0283qt

[Noralf Trønnes]

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 179 ++-
 1 file changed, 170 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index a755f3e60111..dd333a642159 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -21,10 +21,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -32,10 +35,25 @@
 
 /* ILI9341 extended register set (Vendor Command Set) */
 #define ILI9341_IFMODE 0xB0 // clock polarity
+#define ILI9341_FRMCTR10xb1
+#define ILI9341_DISCTRL0xb6
+#define ILI9341_ETMOD  0xb7
+#define ILI9341_PWCTRL10xc0
+#define ILI9341_PWCTRL20xc1
+#define ILI9341_VMCTRL10xc5
+#define ILI9341_VMCTRL20xc7
+#define ILI9341_PWCTRLA0xcb
+#define ILI9341_PWCTRLB0xcf
 #define ILI9341_IFCTL  0xF6 // interface conrol
 #define ILI9341_PGAMCTRL   0xE0 // positive gamma control
 #define ILI9341_NGAMCTRL   0xE1 // negative gamma control
+#define ILI9341_DTCTRLA0xe8
+#define ILI9341_DTCTRLB0xea
+#define ILI9341_PWRSEQ 0xed
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL   0xf7
 
+#define ILI9341_MADCTL_BGR BIT(3)
 #define ILI9341_MADCTL_MV  BIT(5)
 #define ILI9341_MADCTL_MX  BIT(6)
 #define ILI9341_MADCTL_MY  BIT(7)
@@ -44,15 +62,18 @@
  * struct ili9341_config - the display specific configuration
  * @funcs: Panel functions
  * @mode: Display mode
+ * @command_mode_only: Panel only supports command mode
  */
 struct ili9341_config {
const struct drm_panel_funcs *funcs;
const struct drm_display_mode *mode;
+   bool command_mode_only;
 };
 
 struct ili9341 {
struct drm_panel panel;
-   struct mipi_dbi dbi;
+   struct mipi_dbi_dev dbidev;
+   bool command_mode;
struct backlight_device *backlight;
const struct ili9341_config *conf;
 };
@@ -64,7 +85,7 @@ static inline struct ili9341 *panel_to_ili9341(struct 
drm_panel *panel)
 
 static int ili9341_deinit(struct drm_panel *panel, struct ili9341 *ili)
 {
-   struct mipi_dbi *dbi = &ili->dbi;
+   struct mipi_dbi *dbi = &ili->dbidev.dbi;
 
mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
mipi_dbi_command(dbi, MIPI_DCS_ENTER_SLEEP_MODE);
@@ -74,7 +95,7 @@ static int ili9341_deinit(struct drm_panel *panel, struct 
ili9341 *ili)
 
 static int dt024ctft_init(struct drm_panel *panel, struct ili9341 *ili)
 {
-   struct mipi_dbi *dbi = &ili->dbi;
+   struct mipi_dbi *dbi = &ili->dbidev.dbi;
 
/* HW / SW Reset display and wait */
mipi_dbi_hw_reset(dbi);
@@ -164,6 +185,7 @@ static const struct drm_display_mode prgb_240x320_mode = {
.height_mm = 49,
 };
 
+/* This is not used in command mode */
 static int ili9341_get_modes(struct drm_panel *panel)
 {
struct drm_connector *connector = panel->connector;
@@ -201,19 +223,125 @@ static const struct ili9341_config dt024ctft_data = {
.mode = &prgb_240x320_mode,
 };
 
+static int mi0283qt_prepare(struct drm_panel *panel)
+{
+   struct ili9341 *ili = panel_to_ili9341(panel);
+   struct mipi_dbi *dbi = &ili->dbidev.dbi;
+   u8 addr_mode;
+   int ret;
+
+   DRM_DEBUG_KMS("\n");
+
+   ret = mipi_dbi_poweron_conditional_reset(&ili->dbidev);
+   if (ret < 0)
+   return ret;
+   if (ret == 1)
+   goto out_enable;
+   mipi_dbi_hw_reset(dbi);
+
+   mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
+
+   mipi_dbi_command(dbi, ILI9341_PWCTRLB, 0x00, 0x83, 0x30);
+   mipi_dbi_command(dbi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+   mipi_dbi_command(dbi, ILI9341_DTCTRLA, 0x85, 0x01, 0x79);
+   mipi_dbi_command(dbi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+   mipi_dbi_command(dbi, ILI9341_PUMPCTRL, 0x20);
+   mipi_dbi_command(dbi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+   /* Power Control */
+   mipi_dbi_command(dbi, ILI9341_PWCTRL1, 0x26);
+   mipi_dbi_command(dbi, ILI9341_PWCTRL2, 0x11);
+   /* VCOM */
+   mipi_dbi_command(dbi, ILI9341_VMCTRL1, 0x35, 0x3e);
+   mipi_dbi_command(dbi, ILI9341_VMCTRL2, 0xbe);
+
+   /* Memory Access Control */
+   mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT, 
MIPI_DCS_PIXEL_FMT_16BIT);
+
+   /* Frame Rate */
+   mipi_dbi_command(dbi, ILI9341_FRMCTR1, 0x00, 0x1b);
+
+   /* Gamma */
+   mipi_dbi_command(dbi, ILI9341_EN3GAM, 0x08);
+   mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
+   mipi_dbi_command(dbi, ILI9341_PGAMCTRL,
+  0x1f, 0x1a, 0x18, 0x0a, 0x0f, 0x06, 0x45, 0x87,
+  0x32, 0x0a, 0x07, 0x02, 0x07, 0x05, 0x00);
+   mipi_dbi_command(dbi, ILI9341_NGAMCTRL,
+  0x

[RFC 0/4] drm/mipi-dbi: Support panel drivers

[Noralf Trønnes]

Inspired by the thread[1] following the submission of a new ili9341
panel driver[2], I set out to see if I could support panel drivers in
drm_mipi_dbi.

I have included the original driver, done some prep work on it, added
panel support to drm_mipi_dbi and converted mi0283qt to this new panel
driver.

The big question is whether or not panel drivers should be allowed to
turn themselves into full fledged DRM drivers.

Noralf.

[1]
https://lists.freedesktop.org/archives/dri-devel/2019-July/228193.html
[2] https://patchwork.freedesktop.org/patch/316528/

Josef Lusticky (1):
  drm/panel: Add Ilitek ILI9341 parallel RGB panel driver

Noralf Trønnes (3):
  drm/panel/ili9341: Rebase and some more
  drm/mipi-dbi: Support command mode panel drivers
  drm/panel/ili9341: Support mi0283qt

 MAINTAINERS  |   6 +
 drivers/gpu/drm/drm_mipi_dbi.c   | 110 +
 drivers/gpu/drm/panel/Kconfig|   9 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 452 +++
 include/drm/drm_mipi_dbi.h   |   8 +
 6 files changed, 586 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c

-- 
2.20.1

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

[RFC 2/4] drm/panel/ili9341: Rebase and some more

[Noralf Trønnes]

Embed mipi_dbi in struct ili9341.
Rebase on moved mipi-dbi, rename variable name.
Add backlight_device to panel struct.
mipi_dbi_hw_reset() already has a NULL check on the reset gpio.
Prepare for more panels by reworking ili9341_config.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 104 +--
 1 file changed, 52 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 0c700b171025..a755f3e60111 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /* ILI9341 extended register set (Vendor Command Set) */
 #define ILI9341_IFMODE 0xB0 // clock polarity
@@ -42,17 +42,18 @@
 
 /**
  * struct ili9341_config - the display specific configuration
- * @width_mm: physical panel width [mm]
- * @height_mm: physical panel height [mm]
+ * @funcs: Panel functions
+ * @mode: Display mode
  */
 struct ili9341_config {
-   u32 width_mm;
-   u32 height_mm;
+   const struct drm_panel_funcs *funcs;
+   const struct drm_display_mode *mode;
 };
 
 struct ili9341 {
struct drm_panel panel;
-   struct mipi_dbi *mipi;
+   struct mipi_dbi dbi;
+   struct backlight_device *backlight;
const struct ili9341_config *conf;
 };
 
@@ -63,47 +64,50 @@ static inline struct ili9341 *panel_to_ili9341(struct 
drm_panel *panel)
 
 static int ili9341_deinit(struct drm_panel *panel, struct ili9341 *ili)
 {
-   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_DISPLAY_OFF);
-   mipi_dbi_command(ili->mipi, MIPI_DCS_ENTER_SLEEP_MODE);
+   struct mipi_dbi *dbi = &ili->dbi;
+
+   mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_OFF);
+   mipi_dbi_command(dbi, MIPI_DCS_ENTER_SLEEP_MODE);
msleep(5);
return 0;
 }
 
-static int ili9341_init(struct drm_panel *panel, struct ili9341 *ili)
+static int dt024ctft_init(struct drm_panel *panel, struct ili9341 *ili)
 {
-   /* HW / SW Reset display and wait */
-   if (ili->mipi->reset)
-   mipi_dbi_hw_reset(ili->mipi);
+   struct mipi_dbi *dbi = &ili->dbi;
 
-   mipi_dbi_command(ili->mipi, MIPI_DCS_SOFT_RESET);
+   /* HW / SW Reset display and wait */
+   mipi_dbi_hw_reset(dbi);
+
+   mipi_dbi_command(dbi, MIPI_DCS_SOFT_RESET);
msleep(120);
 
/* Polarity */
-   mipi_dbi_command(ili->mipi, ILI9341_IFMODE, 0xC0);
+   mipi_dbi_command(dbi, ILI9341_IFMODE, 0xC0);
 
/* Interface control */
-   mipi_dbi_command(ili->mipi, ILI9341_IFCTL, 0x09, 0x01, 0x26);
+   mipi_dbi_command(dbi, ILI9341_IFCTL, 0x09, 0x01, 0x26);
 
/* Pixel format */
-   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_PIXEL_FORMAT, 
MIPI_DCS_PIXEL_FMT_18BIT << 4);
+   mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT, 
MIPI_DCS_PIXEL_FMT_18BIT << 4);
 
/* Gamma */
-   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
-   mipi_dbi_command(ili->mipi, ILI9341_PGAMCTRL,
+   mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
+   mipi_dbi_command(dbi, ILI9341_PGAMCTRL,
0x0f, 0x31, 0x2b, 0x0c, 0x0e, 0x08, 0x4e, 0xf1,
0x37, 0x07, 0x10, 0x03, 0x0e, 0x09, 0x00);
-   mipi_dbi_command(ili->mipi, ILI9341_NGAMCTRL,
+   mipi_dbi_command(dbi, ILI9341_NGAMCTRL,
0x00, 0x0e, 0x14, 0x03, 0x11, 0x07, 0x31, 0xc1,
0x48, 0x08, 0x0f, 0x0c, 0x31, 0x36, 0x0f);
 
/* Rotation */
-   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_ADDRESS_MODE, 
ILI9341_MADCTL_MX);
+   mipi_dbi_command(dbi, MIPI_DCS_SET_ADDRESS_MODE, ILI9341_MADCTL_MX);
 
/* Exit sleep mode */
-   mipi_dbi_command(ili->mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+   mipi_dbi_command(dbi, MIPI_DCS_EXIT_SLEEP_MODE);
msleep(120);
 
-   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_DISPLAY_ON);
+   mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_ON);
 
return 0;
 }
@@ -115,12 +119,12 @@ static int ili9341_unprepare(struct drm_panel *panel)
return ili9341_deinit(panel, ili);
 }
 
-static int ili9341_prepare(struct drm_panel *panel)
+static int dt024ctft_prepare(struct drm_panel *panel)
 {
struct ili9341 *ili = panel_to_ili9341(panel);
int ret;
 
-   ret = ili9341_init(panel, ili);
+   ret = dt024ctft_init(panel, ili);
if (ret < 0)
ili9341_unprepare(panel);
return ret;
@@ -130,14 +134,14 @@ static int ili9341_enable(struct drm_panel *panel)
 {
struct ili9341 *ili = panel_to_ili9341(panel);
 
-   return backlight_enable(ili->mipi->backlight);
+   return backlight_enable(ili->backlight);
 }
 
 static int ili9341_disable(struct drm_panel *panel)
 {
struct ili9341 *ili = panel_to_ili9341(panel);
 
-   return backlight_disable(ili->mipi->backlight);
+   return backlight_disable(i

[RFC 1/4] drm/panel: Add Ilitek ILI9341 parallel RGB panel driver

[Noralf Trønnes]

From: Josef Lusticky 

Add driver for Ilitek ILI9341 panels in parallel RGB mode

Signed-off-by: Josef Lusticky 
---
 MAINTAINERS  |   6 +
 drivers/gpu/drm/panel/Kconfig|   9 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 291 +++
 4 files changed, 307 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 060ffe635832..1f638d96113b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5115,6 +5115,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/hx8357d.c
 F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
 
+DRM DRIVER FOR ILITEK ILI9341 PANELS
+M: Josef Lusticky 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+F: Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index eaecd40cc32e..34a5b262f924 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -56,6 +56,15 @@ config DRM_PANEL_ILITEK_IL9322
  Say Y here if you want to enable support for Ilitek IL9322
  QVGA (320x240) RGB, YUV and ITU-T BT.656 panels.
 
+config DRM_PANEL_ILITEK_ILI9341
+   tristate "Ilitek ILI9341 240x320 panels"
+   depends on OF && SPI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select TINYDRM_MIPI_DBI
+   help
+ Say Y here if you want to enable support for Ilitek ILI9341
+ QVGA (240x320) RGB panel.
+
 config DRM_PANEL_ILITEK_ILI9881C
tristate "Ilitek ILI9881C-based panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 62dae45f8f74..ba4a303c1a66 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
new file mode 100644
index ..0c700b171025
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -0,0 +1,291 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Ilitek ILI9341 drm_panel driver
+ * 240RGBx320 dots resolution TFT LCD display
+ *
+ * This driver supports the following panel configurations:
+ * - Command interface:
+ * - MIPI-DBI Type 3 Option 1
+ *   (9-bit SPI with Data/Command bit  - IM[3:0] = 1101)
+ * - MIPI-DBI Type 3 Option 3
+ *   (8-bit SPI with Data/Command GPIO - IM[3:0] = 1110)
+ * - Graphical data interface:
+ * - MIPI-DPI 18-bit parallel RGB interface
+ *
+ * Copyright (C) 2019 Josef Lusticky 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* ILI9341 extended register set (Vendor Command Set) */
+#define ILI9341_IFMODE 0xB0 // clock polarity
+#define ILI9341_IFCTL  0xF6 // interface conrol
+#define ILI9341_PGAMCTRL   0xE0 // positive gamma control
+#define ILI9341_NGAMCTRL   0xE1 // negative gamma control
+
+#define ILI9341_MADCTL_MV  BIT(5)
+#define ILI9341_MADCTL_MX  BIT(6)
+#define ILI9341_MADCTL_MY  BIT(7)
+
+/**
+ * struct ili9341_config - the display specific configuration
+ * @width_mm: physical panel width [mm]
+ * @height_mm: physical panel height [mm]
+ */
+struct ili9341_config {
+   u32 width_mm;
+   u32 height_mm;
+};
+
+struct ili9341 {
+   struct drm_panel panel;
+   struct mipi_dbi *mipi;
+   const struct ili9341_config *conf;
+};
+
+static inline struct ili9341 *panel_to_ili9341(struct drm_panel *panel)
+{
+   return container_of(panel, struct ili9341, panel);
+}
+
+static int ili9341_deinit(struct drm_panel *panel, struct ili9341 *ili)
+{
+   mipi_dbi_command(ili->mipi, MIPI_DCS_SET_DISPLAY_OFF);
+   mipi_dbi_command(ili->mipi, MIPI_DCS_ENTER_SLEEP_MODE);
+   msleep(5);
+   return 0;
+}
+
+static int ili9341_init(struct drm_panel *panel, struct ili9341 *ili)
+{
+   /* HW / SW Reset display and wait */
+   if (ili->mipi->reset)
+   mipi_dbi_hw_reset(ili->mipi);
+
+   mipi_dbi_command(ili->mipi, MIPI_DCS_SOFT_RESET);
+   msleep(120);
+
+   /* Polarity */
+   mipi_dbi_command(ili->mipi, ILI9341_IFMODE, 0xC0);
+
+   /* Interface control

[Bug 110405] No successful install of amdgpu 18.30 on Ubuntu 18.04.02 LTS

[bugzilla-daemon]

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

--- Comment #1 from Jeremy Newton  ---
Can you try a newer driver? 18.30 is pretty old and likely doesn't support
18.04.2.

-- 
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 109834] No x86 libraries in new amdgpu-pro drivers

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #3 from Jeremy Newton  ---
I would recommend using the open source graphics for gaming. There is no
advantage to using the pro stack for gaming on SLE.

We don't support SLE x86-32, so closing as WONTFIX

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

[PATCH 4.14 205/293] dma-buf: balance refcount inbalance

[Greg Kroah-Hartman]

From: Jérôme Glisse 

commit 5e383a9798990c69fc759a4930de224bb497e62c upstream.

The debugfs take reference on fence without dropping them.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Stéphane Marchesin 
Cc: sta...@vger.kernel.org
Reviewed-by: Christian König 
Signed-off-by: Sumit Semwal 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181206161840.6578-1-jgli...@redhat.com
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/dma-buf/dma-buf.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1115,6 +1115,7 @@ static int dma_buf_debug_show(struct seq
   fence->ops->get_driver_name(fence),
   fence->ops->get_timeline_name(fence),
   dma_fence_is_signaled(fence) ? "" : "un");
+   dma_fence_put(fence);
}
rcu_read_unlock();
 

[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

[bugzilla-daemon]

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

--- Comment #53 from Anthony Rabbito  ---
Interesting, on 5.2.x with 2 monitors hooked up via HDMI and DP it behaves 75%
of the time with most issues coming from xinit or sleep. Hopefully 5.3 will
contain fixes

-- 
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 111231] random VM_L2_PROTECTION_FAULTs when loading a world in minetest on AMD ryzen 2200G integrated graphics

[bugzilla-daemon]

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

--- Comment #14 from deltasquared  ---
The apitrace no longer causes issues on my system either if I use
AMD_DEBUG=nodpbb . I also decided to try this on minetest and *so far* (bearing
in mind the issue was indetermistic in the first place, so a decisive ruling is
near impossible) I have not re-incurred a crash.

Interestingly, what I have noticed is that sometimes when minetest did not lock
up my system before, the loading bar would suffer mild graphical corruption
(bits of the black border go white) - quite difficult to capture on camera due
to being so fleeting. So far with nodpbb I have yet to observe these artefacts
again.

I did try launching a minetest world with AMD_DEBUG=check_vm instead, however I
somehow still managed to get a lock-up that way with similar graphical
corruption as the bug description. Alas it seems my btrfs root decided to eat
my dmesg log file when I had to force power off, so unable to see if it was the
dreaded VM_L2_PROTECTION_FAULT again >:(

-- 
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 111244] amdgpu kernel 5.2 blank display after resume from suspend

[bugzilla-daemon]

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

--- Comment #6 from csp...@verizon.net ---
I see your point, and you are correct. It seems the issue is not 100%
reproducible. I will redo the bisect and test more thoroughly. Thank you.

-- 
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 00/11] JZ4740 SoC cleanup

[Richard Weinberger]

- Ursprüngliche Mail -
>> Was this series tested with the Ben Nanonote device?
>> I have one of these and from time to time I upgrade the kernel on it.
> 
> Yes! Artur (Cc'd) tested it.
> 
> You can test it yourself, after merging this patchset with:
> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git
> branch next,
> git://git.freedesktop.org/git/drm-misc branch drm-misc-next.
> 
> These will be in 5.4-rc1.

Awesome! Thanks a lot for cleaning this up.

Thanks,
//richard

Re: [RFC PATCH 1/3] drm: introduce new struct drm_mem_region

[Sam Ravnborg]

Hi Brian.

Small nit below - did not try to understand your patch.

Sam

> diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
> index 2c3bbb43c7d1..3d123eb10d62 100644
> --- a/include/drm/drm_mm.h
> +++ b/include/drm/drm_mm.h
> @@ -43,6 +43,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 

Keep include files sorted.

>  #ifdef CONFIG_DRM_DEBUG_MM
>  #include 
>  #endif
> @@ -54,6 +56,31 @@
>  #define DRM_MM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
>  #endif
>  
> +struct drm_device;
> +struct drm_mm;
Likewise forwards. But they are good here.

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

Re: [PATCH 1/1] drm: mxsfb: add i.MX6UL in Kconfig

[Sam Ravnborg]

Hi Fabio.

On Mon, Jul 29, 2019 at 12:51:08PM -0300, Fabio Estevam wrote:
> Hi Sam,
> 
> On Mon, Jul 29, 2019 at 11:37 AM Sam Ravnborg  wrote:
> 
> > Could we throw a COMPILE_TEST in the mix so we get better build
> > coverage too?
> 
> There is no architecture dependency to build this driver, so we
> already have build coverage for it.
Super, thanks for the info.

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

Re: [PATCH v1 02/11] drm: drop uapi dependency from drm_print.h

[Sam Ravnborg]

Hi Christian.

On Mon, Jul 29, 2019 at 03:28:15PM +, Koenig, Christian wrote:
> Am 29.07.19 um 16:35 schrieb Sam Ravnborg:
>  Even then it so useless (which drm driver is this message for???) that I
>  want to remove them all :(
> >>> Yeah, agree. I mean it is nice if the core drm functions use a prefix
> >>> for debug output.
> >>>
> >>> But I actually don't see the point for individual drivers.
> >> We should all migrate to the versions with device...
> > Just to do an xkdc.com/927 I have considered:
> >
> > drm_err(const struct drm_device *drm, ...)
> > drm_info(const struct drm_device *drm, ...)
> >
> > drm_kms_err(const struct drm_device *drm, ...)
> > drm_kms_info(const struct drm_device *drm, ...))
> 
> Why not get completely rid of those and just use dev_err, dev_warn, 
> pr_err, pr_warn etc?
> 
> I mean is it useful to have this extra printing subsystem in DRM while 
> the standard Linux one actually does a better job?
The added functionality of drm_xxx_err would be to keep the current
drm.debug=0x1f filtering on the command-line.
I do not think we can do this with the standard logging.

And then we can prefix every logging with driver name and device name.

The idea is to make a thin layer on top of the existing pr_xxx() functions.
So not a full subsystem, only a wrapper on top of what we already have.

Anyway, idle talk only. We need patches and sample output if we should
discuss more.

Sam

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

Re: [PATCH 00/11] JZ4740 SoC cleanup

[Paul Cercueil]

Hi Richard,


Le lun. 29 juil. 2019 à 7:23, Richard Weinberger 
 a écrit :
On Fri, Jul 26, 2019 at 12:02 AM Paul Cercueil  
wrote:


 Hi,

 This patchset converts the Qi LB60 MIPS board to devicetree and 
makes it

 use all the shiny new drivers that have been developed or updated
 recently.

 All the crappy old drivers and custom code can be dropped since they
 have been replaced by better alternatives.

 Some of these alternatives are not yet in 5.3-rc1 but have already 
been

 accepted by their respective maintainer for inclusion in 5.4-rc1.

 To upstream this patchset, I think that as soon as MIPS maintainers
 agree to take patches 01-03/11 and 11/11, the other patches can go
 through their respective maintainer's tree.


Was this series tested with the Ben Nanonote device?
I have one of these and from time to time I upgrade the kernel on it.


Yes! Artur (Cc'd) tested it.

You can test it yourself, after merging this patchset with:
https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git 
branch next,

git://git.freedesktop.org/git/drm-misc branch drm-misc-next.

These will be in 5.4-rc1.

Cheers,
-Paul

[RFC PATCH 2/3] drm: Introduce DRM_MEM defines for specifying type of drm_mem_region

[Brian Welty]

Introduce DRM memory region types to be common for both drivers using
TTM and for i915.  For now, TTM continues to define it's own set but
uses the DRM base definitions.

Signed-off-by: Brian Welty 
---
 include/drm/drm_mm.h| 8 
 include/drm/ttm/ttm_placement.h | 8 
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 3d123eb10d62..8178d13384bc 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -59,6 +59,14 @@
 struct drm_device;
 struct drm_mm;
 
+/*
+ * Memory types for drm_mem_region
+ */
+#define DRM_MEM_SYSTEM 0
+#define DRM_MEM_STOLEN 1
+#define DRM_MEM_VRAM   2
+#define DRM_MEM_PRIV   3
+
 /**
  * struct drm_mem_region
  *
diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
index e88a8e39767b..976cf8d2f899 100644
--- a/include/drm/ttm/ttm_placement.h
+++ b/include/drm/ttm/ttm_placement.h
@@ -37,10 +37,10 @@
  * Memory regions for data placement.
  */
 
-#define TTM_PL_SYSTEM   0
-#define TTM_PL_TT   1
-#define TTM_PL_VRAM 2
-#define TTM_PL_PRIV 3
+#define TTM_PL_SYSTEM   DRM_MEM_SYSTEM
+#define TTM_PL_TT   DRM_MEM_STOLEN
+#define TTM_PL_VRAM DRM_MEM_VRAM
+#define TTM_PL_PRIV DRM_MEM_PRIV
 
 #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
 #define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
-- 
2.21.0

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

[RFC PATCH 3/3] drm/i915: Update intel_memory_region to use nested drm_mem_region

[Brian Welty]

Some fields are deleted from intel_memory_region in favor of instead
using the new nested drm_mem_region structure.

Note, this is based upon unmerged i915 series [1] in order to show how
i915 might begin to integrate the proposed drm_mem_region.

[1] https://lists.freedesktop.org/archives/intel-gfx/2019-June/203649.html

Signed-off-by: Brian Welty 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 10 +++
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 drivers/gpu/drm/i915/i915_query.c |  2 +-
 drivers/gpu/drm/i915/intel_memory_region.c| 10 ---
 drivers/gpu/drm/i915/intel_memory_region.h| 19 --
 drivers/gpu/drm/i915/intel_region_lmem.c  | 26 +--
 .../drm/i915/selftests/intel_memory_region.c  |  8 +++---
 9 files changed, 37 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 73d2d72adc19..7e56fd89a972 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -606,7 +606,7 @@ static int i915_gem_object_region_select(struct 
drm_i915_private *dev_priv,
ret = i915_gem_object_migrate(obj, ce, id);
if (!ret) {
if (MEMORY_TYPE_FROM_REGION(region) ==
-   INTEL_LMEM) {
+   DRM_MEM_VRAM) {
/*
 * TODO: this should be part of get_pages(),
 * when async get_pages arrives
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index d24f34443c4c..ac18e73665d4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -53,7 +53,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
 * If there's no chance of allocating enough pages for the whole
 * object, bail early.
 */
-   if (obj->base.size > resource_size(&mem->region))
+   if (obj->base.size > mem->region.size)
return -ENOMEM;
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2288a55f27f1..f4adc7e397ff 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2737,20 +2737,20 @@ int i915_gem_init_memory_regions(struct 
drm_i915_private *i915)
 
for (i = 0; i < ARRAY_SIZE(intel_region_map); i++) {
struct intel_memory_region *mem = NULL;
-   u32 type;
+   u8 type;
 
if (!HAS_REGION(i915, BIT(i)))
continue;
 
type = MEMORY_TYPE_FROM_REGION(intel_region_map[i]);
switch (type) {
-   case INTEL_SMEM:
+   case DRM_MEM_SYSTEM:
mem = i915_gem_shmem_setup(i915);
break;
-   case INTEL_STOLEN:
+   case DRM_MEM_STOLEN:
mem = i915_gem_stolen_setup(i915);
break;
-   case INTEL_LMEM:
+   case DRM_MEM_VRAM:
mem = i915_gem_setup_fake_lmem(i915);
break;
}
@@ -2762,7 +2762,7 @@ int i915_gem_init_memory_regions(struct drm_i915_private 
*i915)
}
 
mem->id = intel_region_map[i];
-   mem->type = type;
+   mem->region.type = type;
mem->instance = 
MEMORY_INSTANCE_FROM_REGION(intel_region_map[i]);
 
i915->regions[i] = mem;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9feb597f2b01..908691c3aadb 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1048,7 +1048,7 @@ i915_error_object_create(struct drm_i915_private *i915,
struct intel_memory_region *mem = vma->obj->memory_region;
 
for_each_sgt_dma(dma, iter, vma->pages) {
-   s = io_mapping_map_atomic_wc(&mem->iomap, dma);
+   s = io_mapping_map_atomic_wc(&mem->region.iomap, dma);
ret = compress_page(compress, s, dst);
io_mapping_unmap_atomic(s);
 
diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 21c4c2592d6c..d16b4a6688e8 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -184,7 +184,7 @@ static int query_memregion_info(struct drm_i915_private 
*dev_priv,
continue;
 
info.id = region->id;
-   info.size = resource_size(®ion->region);
+   info.size = region->region.size;
 

[RFC PATCH 0/3] Propose new struct drm_mem_region

[Brian Welty]

This RFC series is first implementation of some ideas expressed
earlier on dri-devel [1].

Some of the goals (open for much debate) are:
  - Create common base structure (subclass) for memory regions (patch #1)
  - Create common memory region types (patch #2)
  - Create common set of memory_region function callbacks (based on
ttm_mem_type_manager_funcs and intel_memory_regions_ops)
  - Create common helpers that operate on drm_mem_region to be leveraged
by both TTM drivers and i915, reducing code duplication
  - Above might start with refactoring ttm_bo_manager.c as these are
helpers for using drm_mm's range allocator and could be made to
operate on DRM structures instead of TTM ones.
  - Larger goal might be to make LRU management of GEM objects common, and
migrate those fields into drm_mem_region and drm_gem_object strucures.

Patches 1-2 implement the proposed struct drm_mem_region and adds
associated common set of definitions for memory region type.

Patch #3 is update to i915 and is based upon another series which is
in progress to add vram support to i915 [2].

[1] https://lists.freedesktop.org/archives/dri-devel/2019-June/224501.html
[2] https://lists.freedesktop.org/archives/intel-gfx/2019-June/203649.html

Brian Welty (3):
  drm: introduce new struct drm_mem_region
  drm: Introduce DRM_MEM defines for specifying type of drm_mem_region
  drm/i915: Update intel_memory_region to use nested drm_mem_region

 drivers/gpu/drm/i915/gem/i915_gem_object.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 10 +++---
 drivers/gpu/drm/i915/i915_gpu_error.c |  2 +-
 drivers/gpu/drm/i915/i915_query.c |  2 +-
 drivers/gpu/drm/i915/intel_memory_region.c| 10 +++---
 drivers/gpu/drm/i915/intel_memory_region.h| 19 +++---
 drivers/gpu/drm/i915/intel_region_lmem.c  | 26 +++---
 .../drm/i915/selftests/intel_memory_region.c  |  8 ++---
 drivers/gpu/drm/ttm/ttm_bo.c  | 34 ++
 drivers/gpu/drm/ttm/ttm_bo_manager.c  | 14 
 drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  8 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c|  4 +--
 include/drm/drm_mm.h  | 35 +++
 include/drm/ttm/ttm_bo_api.h  |  2 +-
 include/drm/ttm/ttm_bo_driver.h   | 16 -
 include/drm/ttm/ttm_placement.h   |  8 ++---
 18 files changed, 122 insertions(+), 91 deletions(-)

-- 
2.21.0

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

[RFC PATCH 1/3] drm: introduce new struct drm_mem_region

[Brian Welty]

Move basic members of ttm_mem_type_manager into a new DRM memory region
structure.  The idea is for this base structure to be nested inside
the TTM structure and later in Intel's proposed intel_memory_region.

As comments in the code suggest, the following future work can extend
the usefulness of this:
- Create common memory region types (next patch)
- Create common set of memory_region function callbacks (based on
  ttm_mem_type_manager_funcs and intel_memory_regions_ops)
- Create common helpers that operate on drm_mem_region to be leveraged
  by both TTM drivers and i915, reducing code duplication
- Above might start with refactoring ttm_bo_manager.c as these are
  helpers for using drm_mm's range allocator and could be made to
  operate on DRM structures instead of TTM ones.
- Larger goal might be to make LRU management of GEM objects common, and
  migrate those fields into drm_mem_region and drm_gem_object strucures.

vmwgfx changes included here as just example of what driver updates will
look like, and can be moved later to separate patch.  Other TTM drivers
need to be updated similarly.

Signed-off-by: Brian Welty 
---
 drivers/gpu/drm/ttm/ttm_bo.c  | 34 +++
 drivers/gpu/drm/ttm/ttm_bo_manager.c  | 14 
 drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  8 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c|  4 +--
 include/drm/drm_mm.h  | 27 +++
 include/drm/ttm/ttm_bo_api.h  |  2 +-
 include/drm/ttm/ttm_bo_driver.h   | 16 -
 8 files changed, 73 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 58c403eda04e..45434ea513dd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -84,8 +84,8 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, 
struct drm_printer *p
drm_printf(p, "has_type: %d\n", man->has_type);
drm_printf(p, "use_type: %d\n", man->use_type);
drm_printf(p, "flags: 0x%08X\n", man->flags);
-   drm_printf(p, "gpu_offset: 0x%08llX\n", man->gpu_offset);
-   drm_printf(p, "size: %llu\n", man->size);
+   drm_printf(p, "gpu_offset: 0x%08llX\n", man->region.start);
+   drm_printf(p, "size: %llu\n", man->region.size);
drm_printf(p, "available_caching: 0x%08X\n", 
man->available_caching);
drm_printf(p, "default_caching: 0x%08X\n", man->default_caching);
if (mem_type != TTM_PL_SYSTEM)
@@ -399,7 +399,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
 
if (bo->mem.mm_node)
bo->offset = (bo->mem.start << PAGE_SHIFT) +
-   bdev->man[bo->mem.mem_type].gpu_offset;
+   bdev->man[bo->mem.mem_type].region.start;
else
bo->offset = 0;
 
@@ -926,9 +926,9 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object 
*bo,
struct dma_fence *fence;
int ret;
 
-   spin_lock(&man->move_lock);
-   fence = dma_fence_get(man->move);
-   spin_unlock(&man->move_lock);
+   spin_lock(&man->region.move_lock);
+   fence = dma_fence_get(man->region.move);
+   spin_unlock(&man->region.move_lock);
 
if (fence) {
reservation_object_add_shared_fence(bo->resv, fence);
@@ -1490,9 +1490,9 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
}
spin_unlock(&glob->lru_lock);
 
-   spin_lock(&man->move_lock);
-   fence = dma_fence_get(man->move);
-   spin_unlock(&man->move_lock);
+   spin_lock(&man->region.move_lock);
+   fence = dma_fence_get(man->region.move);
+   spin_unlock(&man->region.move_lock);
 
if (fence) {
ret = dma_fence_wait(fence, false);
@@ -1535,8 +1535,8 @@ int ttm_bo_clean_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
ret = (*man->func->takedown)(man);
}
 
-   dma_fence_put(man->move);
-   man->move = NULL;
+   dma_fence_put(man->region.move);
+   man->region.move = NULL;
 
return ret;
 }
@@ -1561,7 +1561,7 @@ int ttm_bo_evict_mm(struct ttm_bo_device *bdev, unsigned 
mem_type)
 EXPORT_SYMBOL(ttm_bo_evict_mm);
 
 int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned type,
-   unsigned long p_size)
+  resource_size_t p_size)
 {
int ret;
struct ttm_mem_type_manager *man;
@@ -1570,10 +1570,16 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned 
type,
BUG_ON(type >= TTM_NUM_MEM_TYPES);
man = &bdev->man[type];
BUG_ON(man->has_type);
+
+   /* FIXME: add call to (new) drm_mem_region_init ? */
+   man->region.size = p_size;
+   man->region.type = type;
+   spin_lock_init(&man->region.move_lock);
+   man->region.move = NULL;
+
man->io_reserve_fastpath = true;
  

[Bug 108882] Many different installation problems with amdgpu-pro-18.40-676022-rhel-6 driver in CentOS 6.10

[bugzilla-daemon]

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

--- Comment #1 from Jeremy Newton  ---
It sounds like fglrx was not cleaned up properly.

Unfortunately I'm not sure there's much we can do here.

-- 
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 v11 1/6] drm: Add Content protection type property

[Ramalingam C]

On 2019-07-29 at 17:20:40 +0300, Pekka Paalanen wrote:
> On Sun, 14 Jul 2019 16:30:08 +0530
> Ramalingam C  wrote:
> 
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for mentioning the protected content's type
> > from userspace to kernel HDCP authentication.
> > 
> > Type of the stream is decided by the protected content providers.
> > Type 0 content can be rendered on any HDCP protected display wires.
> > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > 
> > So when a userspace sets this property to Type 1 and starts the HDCP
> > enable, kernel will honour it only if HDCP2.2 authentication is through
> > for type 1. Else HDCP enable will be failed.
> > 
> > Need ACK for this new conenctor property from userspace consumer.
> > 
> > v2:
> >   cp_content_type is replaced with content_protection_type [daniel]
> >   check at atomic_set_property is removed [Maarten]
> > v3:
> >   %s/content_protection_type/hdcp_content_type [Pekka]
> > v4:
> >   property is created for the first requested connector and then reused.
> > [Danvet]
> > v5:
> >   kernel doc nits addressed [Daniel]
> >   Rebased as part of patch reordering.
> > v6:
> >   Kernel docs are modified [pekka]
> > v7:
> >   More details in Kernel docs. [pekka]
> > v8:
> >   Few more clarification into kernel doc of content type [pekka]
> > v9:
> >   Small fixes in coding style.
> > 
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
> >  drivers/gpu/drm/drm_connector.c   | 51 +++
> >  drivers/gpu/drm/drm_hdcp.c| 36 +++-
> >  drivers/gpu/drm/i915/display/intel_hdcp.c |  4 +-
> >  include/drm/drm_connector.h   |  7 
> >  include/drm/drm_hdcp.h|  2 +-
> >  include/drm/drm_mode_config.h |  6 +++
> >  include/uapi/drm/drm_mode.h   |  4 ++
> >  8 files changed, 111 insertions(+), 3 deletions(-)
> 
> 
> Snip - sorry, gmail simply refuses to deliver my mail without trimming
> it hard.
> 
> >  
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 5ab331e5dc23..5c954394093f 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -218,6 +218,10 @@ extern "C" {
> >  #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
> >  #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
> >  
> > +/* Content Type classification for HDCP2.2 vs others */
> > +#define DRM_MODE_HDCP_CONTENT_TYPE00
> > +#define DRM_MODE_HDCP_CONTENT_TYPE11
> 
> Hi,
> 
> I still believe that these definitions do not belong in the uapi
> header. Userspace must use the string names instead.
> 
> Otherwise the patch looks fine, though my Weston review is still
> on-going.

I assume that still we need to wait for the weston review completion.

Hence I request you to respond here once you are comfortable with this new uAPI.

Thanks,
- Ram
> 
> 
> Thanks,
> pq
> 
> > +
> >  struct drm_mode_modeinfo {
> > __u32 clock;
> > __u16 hdisplay;
> 


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

[Bug 204363] EDID from Acer P1266 rejected as invalid

[bugzilla-daemon]

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

Adam Jackson (a...@redhat.com) changed:

   What|Removed |Added

 CC||a...@redhat.com

--- Comment #1 from Adam Jackson (a...@redhat.com) ---
Yep, that's broken alright. The checksum (last byte) should be 0xa7 not 0x90.
The block does look valid otherwise though.

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

[Bug 110381] Failed to updateMST allocation table forpipe idx:0

[bugzilla-daemon]

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

--- Comment #9 from John Francis  ---
I am still seeing this error on kernel 5.2.2. I think it happens when I switch
away the monitors to another host on the KVM switch.

Switching back later, I get only 1 display, problematic as some windows are on
the non-working display.  to console, both displays mirrored,
with text mode login prompt. Then  back to graphical display,
gnome crashes, I get the gnome login screen. Things had improved a bit until
amd's latest updates in 5.2.x.

Jul 29 09:05:33 u24b6-nzxt kernel: [255451.664351] [drm] DM_MST: added
connector: 629ccdae [id: 113] [master: 88dc]
Jul 29 09:05:33 u24b6-nzxt kernel: [255451.664379] [drm] DM_MST: added
connector: a50ff579 [id: 118] [master: 88dc]
Jul 29 09:05:33 u24b6-nzxt kernel: [255451.723246] [drm] Failed to updateMST
allocation table forpipe idx:0
Jul 29 09:05:34 u24b6-nzxt kernel: [255451.960729] [drm] Failed to updateMST
allocation table forpipe idx:0
Jul 29 09:05:34 u24b6-nzxt gnome-shell[9289]: Add Monitors ...
Jul 29 09:05:34 u24b6-nzxt gnome-shell[9289]: new: i1x1920y0w1920h1080
Jul 29 09:05:34 u24b6-nzxt gnome-shell[9289]: pi:0
Jul 29 09:05:34 u24b6-nzxt gnome-shell[9289]: i:0 x:0 y:0 w:1920 h:1080
Jul 29 09:05:34 u24b6-nzxt gnome-shell[9289]: i:1 x:1920 y:0 w:1920 h:1080
Jul 29 09:05:34 u24b6-nzxt gnome-shell[9289]: g_value_set_object: assertion
'G_IS_OBJECT (v_object)' failed
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020762] WARNING: CPU: 0 PID: 9289 at
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2404
update_mst_stream_alloc_table+0x11e/0x130 [amdgpu]
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020763] Modules linked in: tcp_diag
inet_diag xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo
iptable_nat xt_addrtype iptable_filter bpfilter xt_conntrack nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc overlay
nls_iso8859_1 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate
intel_rapl_perf snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio
snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hda_core amdgpu snd_hwdep
snd_pcm snd_seq_midi snd_seq_midi_event eeepc_wmi asus_wmi sparse_keymap
snd_rawmidi video snd_seq amd_iommu_v2 gpu_sched ttm wmi_bmof drm_kms_helper
cp210x snd_seq_device mxm_wmi usbserial joydev input_leds snd_timer drm
i2c_algo_bit snd fb_sys_fops syscopyarea sysfillrect mei_me sysimgblt soundcore
mei mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020783]  autofs4 raid10 raid1 raid0
multipath linear raid456 async_raid6_recov async_memcpy async_pq async_xor
async_tx xor uas usb_storage raid6_pq libcrc32c hid_generic usbhid hid r8169
lpc_ich i2c_i801 e1000e realtek ahci libahci wmi
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020793] CPU: 0 PID: 9289 Comm:
gnome-shell Kdump: loaded Tainted: GW 5.2.2-050202-generic
#201907231250
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020794] Hardware name: System
manufacturer System Product Name/X79-DELUXE, BIOS 4805 02/02/2016
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020838] RIP:
0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu]
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020839] Code: 28 00 00 00 75 2b 48
8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f b6 06 49 89 1c 24 41 88 44 24 08 0f b6
46 01 41 88 44 24 09 eb 93 <0f> 0b e9 2f ff ff ff e8 96 81 d9 e5 66 0f 1f 44 00
00 0f 1f 44 00
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020840] RSP: 0018:9a27c3f2f650
EFLAGS: 00010202
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020840] RAX: 0002 RBX:
8ea3507e4380 RCX: 
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020841] RDX: 9a27c3f2f714 RSI:
8ea3507e4380 RDI: 9a27c3f2f6b0
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020842] RBP: 9a27c3f2f6e8 R08:
c0469df5 R09: 
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020842] R10: 8ea353eb8a00 R11:
9a27c3f2f650 R12: 8ea353eb8a00
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020842] R13: 8ea352f3d400 R14:
0002 R15: 8ea353eb8a00
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020843] FS:  7f530ace1cc0()
GS:8ea35f80() knlGS:
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020844] CS:  0010 DS:  ES: 
CR0: 80050033
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020845] CR2: 15124f029000 CR3:
0001b8150005 CR4: 001606f0
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020845] Call Trace:
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020890] 
core_link_enable_stream+0x5ee/0xa10 [amdgpu]
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020933] 
dce110_apply_ctx_to_hw+0x441/0x4c0 [amdgpu]
Jul 29 09:05:35 u24b6-nzxt kernel: [255453.020976] 
dc_commit_state_no_check+

[Bug 108883] Vulkan support broken in amdgpu-pro-18.40-676022-rhel-6 driver in CentOS 6.10

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

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

--- Comment #2 from Jeremy Newton  ---
Closing as invalid for now.

-- 
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 107826] amdgpu-pro 18.30/18.40: Missing xserver modesetting package (--px install)

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jeremy Newton  ---
Closing as resolved a while ago

-- 
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 108994] Cannot install version 18.40 due to dependency issues

[bugzilla-daemon]

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

Jeremy Newton  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #2 from Jeremy Newton  ---
This is old, closing as WONTFIX as 18.40 is largely unsupported at this time.

Please reopen if reproducible on a more recent build.

-- 
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 2/2] drm/komeda: Enable dual-link support

[Liviu Dudau]

On Tue, Jun 18, 2019 at 09:10:49AM +0100, james qian wang (Arm Technology 
China) wrote:
> Komeda HW can support dual-link which splits display frame to two halves
> (left/link0, right/link1) and output them by two output links.
> Due to the halved pixel rate of each link, the pxlclk of dual-link can be
> reduced two times compare with single-link.
> 
> For enabling dual-link:
> - The DT need to configure two output-links for the pipeline node.
> - Komeda enable dual-link when both link0 and link1 have been connected.
> 
> Example of how the pipeline node will look like for dual-link setup
> 
> pipe0: pipeline@0 {
>   clocks = <&fpgaosc2>;
>   clock-names = "pxclk";
>   reg = <0>;
> 
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   port@0 {
>   reg = <0>;
> 
>   #address-cells = <1>;
>   #size-cells = <0>;
>   dp0_pipe0_link0: endpoint@0 {
>   reg = <0>;
>   remote-endpoint = <&dlink_connector_in0>;
> 
>   };
>   dp0_pipe0_link1: endpoint@1 {
>   reg = <1>;
>   remote-endpoint = <&dlink_connector_in1>;
>   };
>   };
> };
> 
> Signed-off-by: James Qian Wang (Arm Technology China) 
> 

Reviewed-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  .../arm/display/komeda/d71/d71_component.c|  6 +-
>  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 73 +--
>  .../gpu/drm/arm/display/komeda/komeda_dev.c   |  5 +-
>  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  8 +-
>  .../gpu/drm/arm/display/komeda/komeda_kms.h   |  2 +-
>  .../drm/arm/display/komeda/komeda_pipeline.c  | 19 -
>  .../drm/arm/display/komeda/komeda_pipeline.h  |  6 +-
>  .../display/komeda/komeda_pipeline_state.c|  2 +-
>  8 files changed, 85 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index 049e8bfac27b..8e9d44d01e91 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -4,8 +4,6 @@
>   * Author: James.Qian.Wang 
>   *
>   */
> -
> -#include 
>  #include "d71_dev.h"
>  #include "komeda_kms.h"
>  #include "malidp_io.h"
> @@ -1088,6 +1086,10 @@ static void d71_timing_ctrlr_update(struct 
> komeda_component *c,
> 
>   /* configure bs control register */
>   value = BS_CTRL_EN | BS_CTRL_VM;
> + if (c->pipeline->dual_link) {
> + malidp_write32(reg, BS_DRIFT_TO, hfront_porch + 16);
> + value |= BS_CTRL_DL;
> + }
> 
>   malidp_write32(reg, BLK_CONTROL, value);
>  }
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 98e36e1fb2ad..ec43032f3c2c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -28,7 +28,7 @@ static void komeda_crtc_update_clock_ratio(struct 
> komeda_crtc_state *kcrtc_st)
>   }
> 
>   pxlclk = kcrtc_st->base.adjusted_mode.crtc_clock * 1000;
> - aclk = komeda_calc_aclk(kcrtc_st) << 32;
> + aclk = komeda_crtc_get_aclk(kcrtc_st) << 32;
> 
>   do_div(aclk, pxlclk);
>   kcrtc_st->clock_ratio = aclk;
> @@ -75,14 +75,6 @@ komeda_crtc_atomic_check(struct drm_crtc *crtc,
>   return 0;
>  }
> 
> -unsigned long komeda_calc_aclk(struct komeda_crtc_state *kcrtc_st)
> -{
> - struct komeda_dev *mdev = kcrtc_st->base.crtc->dev->dev_private;
> - unsigned long aclk = kcrtc_st->base.adjusted_mode.crtc_clock;
> -
> - return clk_round_rate(mdev->aclk, aclk * 1000);
> -}
> -
>  /* For active a crtc, mainly need two parts of preparation
>   * 1. adjust display operation mode.
>   * 2. enable needed clk
> @@ -119,7 +111,7 @@ komeda_crtc_prepare(struct komeda_crtc *kcrtc)
>* to enable it again.
>*/
>   if (new_mode != KOMEDA_MODE_DUAL_DISP) {
> - err = clk_set_rate(mdev->aclk, komeda_calc_aclk(kcrtc_st));
> + err = clk_set_rate(mdev->aclk, komeda_crtc_get_aclk(kcrtc_st));
>   if (err)
>   DRM_ERROR("failed to set aclk.\n");
>   err = clk_prepare_enable(mdev->aclk);
> @@ -345,29 +337,58 @@ komeda_crtc_atomic_flush(struct drm_crtc *crtc,
>   komeda_crtc_do_flush(crtc, old);
>  }
> 
> +/* Returns the minimum frequency of the aclk rate (main engine clock) in Hz 
> */
> +static unsigned long
> +komeda_calc_min_aclk_rate(struct komeda_crtc *kcrtc,
> +   unsigned long pxlclk)
> +{
> + /* Once dual-link one display pipeline drives two display outputs,
> +  * the aclk needs run on the double rate of pxlclk
> +  */
> + if (kcrtc->master->dual_link)
> + return pxlclk * 2;
> + else
> + return pxlclk;
> +}
> +
> +/* Get current aclk rate that specified by state */
> +unsi

[Bug 110968] Allow ubuntu users to install on other ubuntu versions

[bugzilla-daemon]

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

--- Comment #3 from Jeremy Newton  ---
This is not a Ubuntu issue, we do this purposely.

Let me discuss internally and I can try to get a better solution.

-- 
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 1/2] drm/komeda: Use drm_display_mode "crtc_" prefixed hardware timings

[Liviu Dudau]

On Tue, Jun 18, 2019 at 09:10:40AM +0100, james qian wang (Arm Technology 
China) wrote:
> struct drm_display_mode contains two copies of timings.
> - plain timings.
> - hardware timings, the ones with "crtc_" prefix.
> According to the definition, update komeda to use the hardware timing.
> 
> Signed-off-by: James Qian Wang (Arm Technology China) 
> 

Reviewed-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  .../arm/display/komeda/d71/d71_component.c| 36 ---
>  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 20 ++-
>  .../gpu/drm/arm/display/komeda/komeda_kms.h   |  2 --
>  3 files changed, 35 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index 87248babca1f..049e8bfac27b 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -937,7 +937,7 @@ static int d71_downscaling_clk_check(struct 
> komeda_pipeline *pipe,
>   denominator = (mode->htotal - 1) * v_out -  2 * v_in;
>   }
> 
> - return aclk_rate * denominator >= mode->clock * 1000 * fraction ?
> + return aclk_rate * denominator >= mode->crtc_clock * 1000 * fraction ?
>  0 : -EINVAL;
>  }
> 
> @@ -1056,21 +1056,31 @@ static void d71_timing_ctrlr_update(struct 
> komeda_component *c,
>   struct komeda_component_state *state)
>  {
>   struct drm_crtc_state *crtc_st = state->crtc->state;
> + struct drm_display_mode *mode = &crtc_st->adjusted_mode;
>   u32 __iomem *reg = c->reg;
> - struct videomode vm;
> + u32 hactive, hfront_porch, hback_porch, hsync_len;
> + u32 vactive, vfront_porch, vback_porch, vsync_len;
>   u32 value;
> 
> - drm_display_mode_to_videomode(&crtc_st->adjusted_mode, &vm);
> -
> - malidp_write32(reg, BS_ACTIVESIZE, HV_SIZE(vm.hactive, vm.vactive));
> - malidp_write32(reg, BS_HINTERVALS, BS_H_INTVALS(vm.hfront_porch,
> - vm.hback_porch));
> - malidp_write32(reg, BS_VINTERVALS, BS_V_INTVALS(vm.vfront_porch,
> - vm.vback_porch));
> -
> - value = BS_SYNC_VSW(vm.vsync_len) | BS_SYNC_HSW(vm.hsync_len);
> - value |= vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ? BS_SYNC_VSP : 0;
> - value |= vm.flags & DISPLAY_FLAGS_HSYNC_HIGH ? BS_SYNC_HSP : 0;
> + hactive = mode->crtc_hdisplay;
> + hfront_porch = mode->crtc_hsync_start - mode->crtc_hdisplay;
> + hsync_len = mode->crtc_hsync_end - mode->crtc_hsync_start;
> + hback_porch = mode->crtc_htotal - mode->crtc_hsync_end;
> +
> + vactive = mode->crtc_vdisplay;
> + vfront_porch = mode->crtc_vsync_start - mode->crtc_vdisplay;
> + vsync_len = mode->crtc_vsync_end - mode->crtc_vsync_start;
> + vback_porch = mode->crtc_vtotal - mode->crtc_vsync_end;
> +
> + malidp_write32(reg, BS_ACTIVESIZE, HV_SIZE(hactive, vactive));
> + malidp_write32(reg, BS_HINTERVALS, BS_H_INTVALS(hfront_porch,
> + hback_porch));
> + malidp_write32(reg, BS_VINTERVALS, BS_V_INTVALS(vfront_porch,
> + vback_porch));
> +
> + value = BS_SYNC_VSW(vsync_len) | BS_SYNC_HSW(hsync_len);
> + value |= mode->flags & DRM_MODE_FLAG_PVSYNC ? BS_SYNC_VSP : 0;
> + value |= mode->flags & DRM_MODE_FLAG_PHSYNC ? BS_SYNC_HSP : 0;
>   malidp_write32(reg, BS_SYNC, value);
> 
>   malidp_write32(reg, BS_PROG_LINE, D71_DEFAULT_PREPRETCH_LINE - 1);
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 1b4ea8ab41fa..98e36e1fb2ad 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -27,7 +27,7 @@ static void komeda_crtc_update_clock_ratio(struct 
> komeda_crtc_state *kcrtc_st)
>   return;
>   }
> 
> - pxlclk = kcrtc_st->base.adjusted_mode.clock * 1000;
> + pxlclk = kcrtc_st->base.adjusted_mode.crtc_clock * 1000;
>   aclk = komeda_calc_aclk(kcrtc_st) << 32;
> 
>   do_div(aclk, pxlclk);
> @@ -78,9 +78,9 @@ komeda_crtc_atomic_check(struct drm_crtc *crtc,
>  unsigned long komeda_calc_aclk(struct komeda_crtc_state *kcrtc_st)
>  {
>   struct komeda_dev *mdev = kcrtc_st->base.crtc->dev->dev_private;
> - unsigned long pxlclk = kcrtc_st->base.adjusted_mode.clock;
> + unsigned long aclk = kcrtc_st->base.adjusted_mode.crtc_clock;
> 
> - return clk_round_rate(mdev->aclk, pxlclk * 1000);
> + return clk_round_rate(mdev->aclk, aclk * 1000);
>  }
> 
>  /* For active a crtc, mainly need two parts of preparation
> @@ -93,7 +93,7 @@ komeda_crtc_prepare(struct komeda_crtc *kcrtc)
>   struct komeda_dev *mdev = kcrtc->base.dev->dev_private;
>   struct komeda_pipeline *master = kcrt

[Bug 111232] 3200 Memory Crash My System

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
Can you bisect?

-- 
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 111231] random VM_L2_PROTECTION_FAULTs when loading a world in minetest on AMD ryzen 2200G integrated graphics

[bugzilla-daemon]

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

--- Comment #13 from Pierre-Eric Pelloux-Prayer 
 ---
Using AMD_DEBUG=nodpbb "fixes" the problem.

-- 
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 1/1] drm: mxsfb: add i.MX6UL in Kconfig

[Fabio Estevam]

Hi Sam,

On Mon, Jul 29, 2019 at 11:37 AM Sam Ravnborg  wrote:

> Could we throw a COMPILE_TEST in the mix so we get better build
> coverage too?

There is no architecture dependency to build this driver, so we
already have build coverage for it.

Regards,

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

Re: [PATCH v2 7/8] drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get

[Philipp Zabel]

On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> In preparation to having a context per process, etnaviv_gem_mapping_get
> should not use the current GPU context, but needs to be told which
> context to use.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c| 20 
>  drivers/gpu/drm/etnaviv/etnaviv_gem.h|  3 ++-
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
>  3 files changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index e1815058d5fc..5fee0bb145c8 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -248,7 +248,8 @@ void etnaviv_gem_mapping_unreference(struct 
> etnaviv_vram_mapping *mapping)
>  }
>  
>  struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> - struct drm_gem_object *obj, struct etnaviv_gpu *gpu)
> + struct drm_gem_object *obj, struct etnaviv_gpu *gpu,
> + struct etnaviv_iommu_context *mmu)
>  {
>   struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
>   struct etnaviv_vram_mapping *mapping;
> @@ -256,7 +257,7 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
>   int ret = 0;
>  
>   mutex_lock(&etnaviv_obj->lock);
> - mapping = etnaviv_gem_get_vram_mapping(etnaviv_obj, gpu->mmu);
> + mapping = etnaviv_gem_get_vram_mapping(etnaviv_obj, mmu);
>   if (mapping) {
>   /*
>* Holding the object lock prevents the use count changing
> @@ -265,12 +266,12 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
>* the MMU owns this mapping to close this race.
>*/
>   if (mapping->use == 0) {
> - mutex_lock(&gpu->mmu->lock);
> - if (mapping->context == gpu->mmu)
> + mutex_lock(&mmu->lock);
> + if (mapping->context == mmu)
>   mapping->use += 1;
>   else
>   mapping = NULL;
> - mutex_unlock(&gpu->mmu->lock);
> + mutex_unlock(&mmu->lock);
>   if (mapping)
>   goto out;
>   } else {
> @@ -303,10 +304,11 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
>   list_del(&mapping->obj_node);
>   }
>  
> - mapping->context = gpu->mmu;
> + etnaviv_iommu_context_get(mmu);
> + mapping->context = mmu;
>   mapping->use = 1;
>  
> - ret = etnaviv_iommu_map_gem(gpu->mmu, etnaviv_obj, gpu->memory_base,
> + ret = etnaviv_iommu_map_gem(mmu, etnaviv_obj, gpu->memory_base,
>   mapping);
>   if (ret < 0)
>   kfree(mapping);
> @@ -529,8 +531,10 @@ void etnaviv_gem_free_object(struct drm_gem_object *obj)
>  
>   WARN_ON(mapping->use);
>  
> - if (context)
> + if (context) {
>   etnaviv_iommu_unmap_gem(context, mapping);
> + etnaviv_iommu_context_put(context);
> + }
>  
>   list_del(&mapping->obj_node);
>   kfree(mapping);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> index 5a004d5e4eaa..36486254a3d3 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> @@ -119,7 +119,8 @@ struct page **etnaviv_gem_get_pages(struct 
> etnaviv_gem_object *obj);
>  void etnaviv_gem_put_pages(struct etnaviv_gem_object *obj);
>  
>  struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
> - struct drm_gem_object *obj, struct etnaviv_gpu *gpu);
> + struct drm_gem_object *obj, struct etnaviv_gpu *gpu,
> + struct etnaviv_iommu_context *mmu);
>  void etnaviv_gem_mapping_unreference(struct etnaviv_vram_mapping *mapping);
>  
>  #endif /* __ETNAVIV_GEM_H__ */
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 3f4f6ab388de..267ff5863e5d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -224,7 +224,7 @@ static int submit_pin_objects(struct etnaviv_gem_submit 
> *submit)
>   struct etnaviv_vram_mapping *mapping;
>  
>   mapping = etnaviv_gem_mapping_get(&etnaviv_obj->base,
> -   submit->gpu);
> +   submit->gpu, 
> submit->gpu->mmu);
>   if (IS_ERR(mapping)) {
>   ret = PTR_ERR(mapping);
>   break;

Reviewed-by: Philipp Zabel 

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

Re: [PATCH v2 6/8] drm/etnaviv: split out starting of FE idle loop

[Philipp Zabel]

On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> Move buffer setup and starting of the FE loop in the kernel ringbuffer
> into a separate function. This is a preparation to start the FE later
> in the submit process.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index a53fecd17fa9..b46d8207f6e6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -600,6 +600,20 @@ void etnaviv_gpu_start_fe(struct etnaviv_gpu *gpu, u32 
> address, u16 prefetch)
>   }
>  }
>  
> +static void etnaviv_gpu_start_fe_idleloop(struct etnaviv_gpu *gpu)
> +{
> + u32 address = etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu->cmdbuf_mapping);
> + u16 prefetch;
> +
> + /* setup the MMU */
> + etnaviv_iommu_restore(gpu, gpu->mmu);
> +
> + /* Start command processor */
> + prefetch = etnaviv_buffer_init(gpu);
> +
> + etnaviv_gpu_start_fe(gpu, address, prefetch);
> +}
> +
>  static void etnaviv_gpu_setup_pulse_eater(struct etnaviv_gpu *gpu)
>  {
>   /*
> @@ -633,8 +647,6 @@ static void etnaviv_gpu_setup_pulse_eater(struct 
> etnaviv_gpu *gpu)
>  
>  static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
>  {
> - u16 prefetch;
> -
>   if ((etnaviv_is_model_rev(gpu, GC320, 0x5007) ||
>etnaviv_is_model_rev(gpu, GC320, 0x5220)) &&
>   gpu_read(gpu, VIVS_HI_CHIP_TIME) != 0x2062400) {
> @@ -680,15 +692,9 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
>   /* setup the pulse eater */
>   etnaviv_gpu_setup_pulse_eater(gpu);
>  
> - /* setup the MMU */
> - etnaviv_iommu_restore(gpu, gpu->mmu);
> -
> - /* Start command processor */
> - prefetch = etnaviv_buffer_init(gpu);
> -
>   gpu_write(gpu, VIVS_HI_INTR_ENBL, ~0U);
> - etnaviv_gpu_start_fe(gpu, etnaviv_cmdbuf_get_va(&gpu->buffer,
> -  &gpu->cmdbuf_mapping), prefetch);
> +
> + etnaviv_gpu_start_fe_idleloop(gpu);
>  }
>  
>  int etnaviv_gpu_init(struct etnaviv_gpu *gpu)

Reviewed-by: Philipp Zabel 

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

Re: [PATCH v2 5/8] drm/etnaviv: rework MMU handling

[Philipp Zabel]

On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> This reworks the MMU handling to make it possible to have multiple MMU 
> contexts.
> A context is basically one instance of GPU page tables. Currently we have one
> set of page tables per GPU, which isn't all that clever, as it has the
> following two consequences:
> 
> 1. All GPU clients (aka processes) are sharing the same pagetables, which 
> means
> there is no isolation between clients, but only between GPU assigned memory
> spaces and the rest of the system. Better than nothing, but also not great.
> 
> 2. Clients operating on the same set of buffers with different etnaviv GPU
> cores, e.g. a workload using both the 2D and 3D GPU, need to map the used
> buffers into the pagetable sets of each used GPU.
> 
> This patch reworks all the MMU handling to introduce the abstraction of the
> MMU context. A context can be shared across different GPU cores, as long as
> they have compatible MMU implementations, which is the case for all systems
> with Vivante GPUs seen in the wild.
> 
> As MMUv1 is not able to change pagetables on the fly, without a
> "stop the world" operation, which stops GPU, changes pagetables via CPU
> interaction, restarts GPU, the implementation introduces a shared context on
> MMUv1, which is returned whenever there is a request for a new context.
> 
> This patch assigns a MMU context to each GPU, so on MMUv2 systems there is
> still one set of pagetables per GPU, but due to the shared context MMUv1
> systems see a change in behavior as now a single pagetable set is used
> across all GPU cores.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c   |   8 +-
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c   |   8 +-
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h   |   6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h  |   4 +-
>  drivers/gpu/drm/etnaviv/etnaviv_dump.c |   2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c  |  14 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.h  |   2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c  |  20 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h  |   3 +-
>  drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 151 ++--
>  drivers/gpu/drm/etnaviv/etnaviv_iommu.h|  20 --
>  drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 264 +
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.c  | 264 +
>  drivers/gpu/drm/etnaviv/etnaviv_mmu.h  |  88 +--
>  14 files changed, 441 insertions(+), 413 deletions(-)
>  delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu.h
> 
[...]
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -223,12 +223,12 @@ int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, 
> u64 *offset)
>  
>  static struct etnaviv_vram_mapping *
>  etnaviv_gem_get_vram_mapping(struct etnaviv_gem_object *obj,
> -  struct etnaviv_iommu *mmu)
> +  struct etnaviv_iommu_context *context)
>  {
>   struct etnaviv_vram_mapping *mapping;
>  
>   list_for_each_entry(mapping, &obj->vram_list, obj_node) {
> - if (mapping->mmu == mmu)
> + if (mapping->context == context)
>   return mapping;
>   }
>  
> @@ -266,7 +266,7 @@ struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
>*/
>   if (mapping->use == 0) {
>   mutex_lock(&gpu->mmu->lock);
> - if (mapping->mmu == gpu->mmu)
> + if (mapping->context == gpu->mmu)

Is there a reason that mmu parameters and mapping->mmu are renamed to
context, but gpu->mmu is not?

Could be renamed to gpu->mmu_context for consistency.

[...]
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 7b396ac5dba5..a53fecd17fa9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
[...]
> @@ -1684,11 +1690,11 @@ static void etnaviv_gpu_unbind(struct device *dev, 
> struct device *master,
>   if (gpu->initialized) {
>   etnaviv_cmdbuf_free(&gpu->buffer);
>   etnaviv_cmdbuf_suballoc_unmap(gpu->mmu, &gpu->cmdbuf_mapping);
> - etnaviv_iommu_destroy(gpu->mmu);
> + etnaviv_iommu_context_put(gpu->mmu);
> + etnaviv_iommu_global_fini(gpu);
>   gpu->initialized = false;
>   }
>  
> -

This should be fixed in a previous patch.

[...]
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index 3348d9962177..cf49f0e2e1cb 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
[...]
> @@ -391,21 +369,107 @@ void etnaviv_iommu_put_suballoc_va(struct 
> etnaviv_iommu *mmu,
>  
>   mapping->use = 0;
>  
> - if (mmu->version == ETNAVIV_IOMMU_V1)
> + if (context->global->version == ETNAVIV_IOMMU_V1)
>   return;
>  
> - 

Re: [PATCH v1 02/11] drm: drop uapi dependency from drm_print.h

[Koenig, Christian]

Am 29.07.19 um 16:35 schrieb Sam Ravnborg:
 Even then it so useless (which drm driver is this message for???) that I
 want to remove them all :(
>>> Yeah, agree. I mean it is nice if the core drm functions use a prefix
>>> for debug output.
>>>
>>> But I actually don't see the point for individual drivers.
>> We should all migrate to the versions with device...
> Just to do an xkdc.com/927 I have considered:
>
> drm_err(const struct drm_device *drm, ...)
> drm_info(const struct drm_device *drm, ...)
>
> drm_kms_err(const struct drm_device *drm, ...)
> drm_kms_info(const struct drm_device *drm, ...))

Why not get completely rid of those and just use dev_err, dev_warn, 
pr_err, pr_warn etc?

I mean is it useful to have this extra printing subsystem in DRM while 
the standard Linux one actually does a better job?

Christian.

>
> And so on for vbl, primse. lease, state etc.
>
> Then we could fish out relevant info from the drm device and present
> this nicely.
>
> For the cases where no drm_device is available the fallback is:
> drm_dev_err(const struct drm_device *drm, ...)
> drm_dev_info(const struct drm_device *drm, ...))
>
> We could modify the existing UPPERCASE macros to be placeholders for
> the more reader friendly lower cases variants and base it all on the
> established infrastructure.
>
> But this is just idle thinking, as only a serious patch would stir the
> relevant discussions.
>
> For now this is far from the top of my TODO list.
>
>
>   Sam

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

[PATCH libdrm] tests/util/kms.c: Add module names for Arm display drivers.

[Liviu Dudau]

From: Liviu Dudau 

Add the names of the kernel modules for the Arm display drivers
so that tests inside libDRM can auto-detect their presence.

Signed-off-by: Liviu Dudau 
---
 tests/util/kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/util/kms.c b/tests/util/kms.c
index dd1bbee3..d3be6c0c 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -147,6 +147,9 @@ static const char * const modules[] = {
"stm",
"sun4i-drm",
"armada-drm",
+   "hdlcd",
+   "mali-dp",
+   "komeda",
 };
 
 int util_open(const char *device, const char *module)
-- 
2.22.0

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

Re: [PATCH 1/1] drm: mxsfb: add i.MX6UL in Kconfig

[Sam Ravnborg]

Hi Sébastien,
On Mon, Jul 29, 2019 at 11:27:37AM -0300, Fabio Estevam wrote:
> Hi Sébastien,
> 
> On Mon, Jul 29, 2019 at 11:14 AM Sébastien Szymanski
>  wrote:
> 
> >  config DRM_MXSFB
> > -   tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
> > +   tristate "i.MX23/i.MX28/i.MX6SX/i.MX6UL MXSFB LCD controller"
> 
> This IP is also found on i.MX6SL, i.MX7D, i.MX7S, i.MX8M, i.MX8QXP, etc
> 
> I think it would be better if we do not keep increasing the list of
> supported SoCs in the Kconfig text.

Could we throw a COMPILE_TEST in the mix so we get better build
coverage too?

Sam

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

Re: [PATCH v1 02/11] drm: drop uapi dependency from drm_print.h

[Sam Ravnborg]

> >>
> >> Even then it so useless (which drm driver is this message for???) that I
> >> want to remove them all :(
> >
> > Yeah, agree. I mean it is nice if the core drm functions use a prefix 
> > for debug output.
> >
> > But I actually don't see the point for individual drivers.
> 
> We should all migrate to the versions with device...

Just to do an xkdc.com/927 I have considered:

drm_err(const struct drm_device *drm, ...)
drm_info(const struct drm_device *drm, ...)

drm_kms_err(const struct drm_device *drm, ...)
drm_kms_info(const struct drm_device *drm, ...))

And so on for vbl, primse. lease, state etc.

Then we could fish out relevant info from the drm device and present
this nicely.

For the cases where no drm_device is available the fallback is:
drm_dev_err(const struct drm_device *drm, ...)
drm_dev_info(const struct drm_device *drm, ...))

We could modify the existing UPPERCASE macros to be placeholders for
the more reader friendly lower cases variants and base it all on the
established infrastructure.

But this is just idle thinking, as only a serious patch would stir the
relevant discussions.

For now this is far from the top of my TODO list.


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

Re: [PATCH 1/1] drm: mxsfb: add i.MX6UL in Kconfig

[Fabio Estevam]

Hi Sébastien,

On Mon, Jul 29, 2019 at 11:14 AM Sébastien Szymanski
 wrote:

>  config DRM_MXSFB
> -   tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
> +   tristate "i.MX23/i.MX28/i.MX6SX/i.MX6UL MXSFB LCD controller"

This IP is also found on i.MX6SL, i.MX7D, i.MX7S, i.MX8M, i.MX8QXP, etc

I think it would be better if we do not keep increasing the list of
supported SoCs in the Kconfig text.

What about just having the text like this instead?

tristate "MXSFB LCD controller"

> depends on DRM && OF
> depends on COMMON_CLK
> select DRM_MXS
> @@ -14,7 +14,7 @@ config DRM_MXSFB
> select DRM_KMS_CMA_HELPER
> select DRM_PANEL
> help
> - Choose this option if you have an i.MX23/i.MX28/i.MX6SX MXSFB
> + Choose this option if you have an i.MX23/i.MX28/i.MX6SX/i.MX6UL 
> MXSFB
>   LCD controller.

and here it would become:

Choose this option if you want to support the MXSFB LCD controller.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6a/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding

[Torsten Duwe]

On Fri, Jul 26, 2019 at 06:36:01PM +0200, Maxime Ripard wrote:
> > +
> > +  dvdd12-supply:
> > +maxItems: 1
> > +description: Regulator for 1.2V digital core power.
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +
> > +  dvdd25-supply:
> > +maxItems: 1
> > +description: Regulator for 2.5V digital core power.
> > +$ref: /schemas/types.yaml#/definitions/phandle
> 
> There's no need to specify the type here, all the properties ending in
> -supply are already checked for that type

Ok, thanks for the hint.

> > +  ports:
> > +type: object
> > +minItems: 1
> > +maxItems: 2
> > +description: |
> > +  Video port 0 for LVTTL input,
> > +  Video port 1 for eDP output (panel or connector)
> > +  using the DT bindings defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt
> 
> You should probably describe the port@0 and port@1 nodes here as
> well. It would allow you to express that the port 0 is mandatory and
> the port 1 optional, which got dropped in the conversion.

I would have liked to, but have not discovered yet a comprehensive source
of information about recommended syntax and semantics of the YAML schemes.

Is there some central reference for these types of issues? I mean not the
"here is a git repo with the meta-schemes" but sort of a cookbook?

Torsten

[Bug 204365] New: amdgpu crashes when using parameter "drm.edid_firmware"

[bugzilla-daemon]

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

Bug ID: 204365
   Summary: amdgpu crashes when using parameter
"drm.edid_firmware"
   Product: Drivers
   Version: 2.5
Kernel Version: 5.2.4
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: felixhaedi...@web.de
Regression: No

Created attachment 284027
  --> https://bugzilla.kernel.org/attachment.cgi?id=284027&action=edit
dmesg log with amdgpu crash

As a workaround for the problem described in bug 204363, I am using the
parameter "drm.edid_firmware" parameter to override the EDID.

This EDID seems to work fine, if I log in to my desktop (GNOME 3.32 unter
X.org) before plugging in the HDMI cable to the projector. But when the HDMI
cable is plugged in during boot, or when launching Wayland or X.org when the
cable is plugged in, the graphics driver crashes with the following error
message:

kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6264!

Full dmesg log attached.

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

Re: [PATCH v11 1/6] drm: Add Content protection type property

[Pekka Paalanen]

On Sun, 14 Jul 2019 16:30:08 +0530
Ramalingam C  wrote:

> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
> 
> Type of the stream is decided by the protected content providers.
> Type 0 content can be rendered on any HDCP protected display wires.
> But Type 1 content can be rendered only on HDCP2.2 protected paths.
> 
> So when a userspace sets this property to Type 1 and starts the HDCP
> enable, kernel will honour it only if HDCP2.2 authentication is through
> for type 1. Else HDCP enable will be failed.
> 
> Need ACK for this new conenctor property from userspace consumer.
> 
> v2:
>   cp_content_type is replaced with content_protection_type [daniel]
>   check at atomic_set_property is removed [Maarten]
> v3:
>   %s/content_protection_type/hdcp_content_type [Pekka]
> v4:
>   property is created for the first requested connector and then reused.
>   [Danvet]
> v5:
>   kernel doc nits addressed [Daniel]
>   Rebased as part of patch reordering.
> v6:
>   Kernel docs are modified [pekka]
> v7:
>   More details in Kernel docs. [pekka]
> v8:
>   Few more clarification into kernel doc of content type [pekka]
> v9:
>   Small fixes in coding style.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
>  drivers/gpu/drm/drm_connector.c   | 51 +++
>  drivers/gpu/drm/drm_hdcp.c| 36 +++-
>  drivers/gpu/drm/i915/display/intel_hdcp.c |  4 +-
>  include/drm/drm_connector.h   |  7 
>  include/drm/drm_hdcp.h|  2 +-
>  include/drm/drm_mode_config.h |  6 +++
>  include/uapi/drm/drm_mode.h   |  4 ++
>  8 files changed, 111 insertions(+), 3 deletions(-)


Snip - sorry, gmail simply refuses to deliver my mail without trimming
it hard.

>  
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 5ab331e5dc23..5c954394093f 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -218,6 +218,10 @@ extern "C" {
>  #define DRM_MODE_CONTENT_PROTECTION_DESIRED 1
>  #define DRM_MODE_CONTENT_PROTECTION_ENABLED 2
>  
> +/* Content Type classification for HDCP2.2 vs others */
> +#define DRM_MODE_HDCP_CONTENT_TYPE0  0
> +#define DRM_MODE_HDCP_CONTENT_TYPE1  1

Hi,

I still believe that these definitions do not belong in the uapi
header. Userspace must use the string names instead.

Otherwise the patch looks fine, though my Weston review is still
on-going.


Thanks,
pq

> +
>  struct drm_mode_modeinfo {
>   __u32 clock;
>   __u16 hdisplay;



pgpspMXuSVXmG.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/1] drm/vblank: drop use of DRM_WAIT_ON()

[Michel Dänzer]

On 2019-07-26 11:06 p.m., Sam Ravnborg wrote:
> DRM_WAIT_ON() is from the deprecated drm_os_linux header and
> the modern replacement is the wait_event_*.
> 
> The return values differ, so a conversion is needed to
> keep the original interface towards userspace.
> Introduced a switch/case to make code obvious.
> 
> Analysis from Michel Dänzer:
> 
> The waiting condition rely on all relevant places where vblank_count
> is modified calls wake_up(&vblank->queue).
> 
> drm_handle_vblank():
> - Calls wake_up(&vblank->queue)
> 
> drm_vblank_enable():
> - There is no need here because there can be no sleeping waiters
>   in the queue, because vblank->enabled == false immediately
>   terminates any waits.
> 
> drm_crtc_accurate_vblank_count():
> - This is called from interrupt handlers, at least from
>   amdgpu_dm.c:dm_pflip_high_irq(). Not sure it needs to wake up
>   the queue though, the driver should call
>   drm_(crtc_)_handle_vblank anyway.
> 
> drm_vblank_disable_and_save():
> - It can be called from an interrupt, via drm_handle_vblank ->
>   vblank_disable_fn. However, the only place where
>   drm_vblank_disable_and_save can be called with sleeping waiters
>   in the queue is in drm_crtc_vblank_off, which wakes up the queue
>   afterwards (which terminates all waits, because
>   vblank->enabled == false at this point).
> 
> v3:
> - Added analysis to changelog from Michel Dänzer
> - Moved return result handling inside if (req_seq != seq) (Daniel V)
> - Reused more of the former logic - resulting in simpler code
> - Dropped Reviewed-by from Sean Paul as this is a new implmentation
> 
> v2:
> - Fix so the case where req_seq equals seq was handled properly
> - quick hack to check if IGT became happy
> - Only sent to igt, not to dri-devel
> 
> Signed-off-by: Sam Ravnborg 
> Cc: "Michel Dänzer" 
> Cc: Sean Paul 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |  https://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 109456] KVM VFIO guest X hang with guest kernel > 4.15

[bugzilla-daemon]

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

libgra...@gmail.com changed:

   What|Removed |Added

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

-- 
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 109456] KVM VFIO guest X hang with guest kernel > 4.15

[bugzilla-daemon]

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

--- Comment #8 from libgra...@gmail.com ---
Got back to this again recently and can confirm it's fixed in Qemu git (for
4.1) now.

Many thanks :)

-- 
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 111231] random VM_L2_PROTECTION_FAULTs when loading a world in minetest on AMD ryzen 2200G integrated graphics

[bugzilla-daemon]

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

--- Comment #12 from Pierre-Eric Pelloux-Prayer 
 ---
Thanks for the bug report.

I could reproduce the bug using the provided apitrace, both on a Ryzen platform
and on a Vega Mobile laptop (can't reproduce on Navi).

Using MESA_DEBUG=flush or AMD_DEBUG=check_vm seem to make the problem go away
so my guess would be a synchronization / cache issue but I didn't find the root
issue yet.

-- 
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