Re: [v2 00/10] arm/arm64: mediatek: Fix mmsys device probing

[Lee Jones]

On Mon, 23 Apr 2018, matthias@kernel.org wrote:

> From: Matthias Brugger 
> 
> Changes since v1:
> - add binding documentation
> - ddp: use regmap_update_bits
> - ddp: ignore EPROBE_DEFER on clock probing
> - mfd: delete mmsys_private
> - add Reviewed-by and Acked-by tags

I'm confused by the double submission.

Please can you send it again completely detached from the first and
the second submissions please?

> ---
> 
> MMSYS in Mediatek SoCs has some registers to control clock gates (which is 
> used in the clk driver) and some registers to set the routing and enable
> the differnet blocks of the display subsystem.
> 
> Up to now both drivers, clock and drm are probed with the same device tree
> compatible. But only the first driver get probed, which in effect breaks
> graphics on mt8173 and mt2701.
> 
> This patch set introduces a new mfd device, which binds against the mmsys
> compatible and takes care of probing the needed devices. It was tested on the
> bananapi-r2 and the Acer R13 Chromebook.
> 
> 
> Matthias Brugger (10):
>   dt-bindings: mediatek: mmsys: Add support for mfd
>   drm/mediatek: Use regmap for register access
>   mfd: mtk-mmsys: Add mmsys driver
>   drm/mediatek: mt2701: switch to mfd probing.
>   clk: mediatek: mt2701-mm: switch to mfd device
>   mfd: mtk-mmsys: Add mt8173 nodes
>   drm/mediatek: Add mfd support for mt8173
>   clk: mediatek: mt8173-mm: switch to mfd device
>   drm: mediatek: Omit warning on probe defers
>   MAINTAINERS: update Mediatek Soc entry
> 
>  .../bindings/arm/mediatek/mediatek,mmsys.txt   |  2 -
>  .../bindings/display/mediatek/mediatek,disp.txt|  2 +-
>  .../devicetree/bindings/mfd/mediatek,mmsys.txt | 27 +++
>  MAINTAINERS|  2 +
>  drivers/clk/mediatek/clk-mt2701-mm.c   | 10 +--
>  drivers/clk/mediatek/clk-mt8173.c  | 17 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  4 +-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 41 --
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h |  4 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 33 
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h |  2 +-
>  drivers/mfd/Kconfig|  9 +++
>  drivers/mfd/Makefile   |  2 +
>  drivers/mfd/mtk-mmsys.c| 93 
> ++
>  14 files changed, 189 insertions(+), 59 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt
>  create mode 100644 drivers/mfd/mtk-mmsys.c
> 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/24/2018 01:41 AM, Boris Ostrovsky wrote:

On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote:

On 04/23/2018 02:52 PM, Wei Liu wrote:

On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote:

  the gntdev.

I think this is generic enough that it could be implemented by a
device not tied to Xen. AFAICT the hyper_dma guys also wanted
something similar to this.

You can't just wrap random userspace memory into a dma-buf. We've
just had
this discussion with kvm/qemu folks, who proposed just that, and
after a
bit of discussion they'll now try to have a driver which just wraps a
memfd into a dma-buf.

So, we have to decide either we introduce a new driver
(say, under drivers/xen/xen-dma-buf) or extend the existing
gntdev/balloon to support dma-buf use-cases.

Can anybody from Xen community express their preference here?


Oleksandr talked to me on IRC about this, he said a few IOCTLs need to
be added to either existing drivers or a new driver.

I went through this thread twice and skimmed through the relevant
documents, but I couldn't see any obvious pros and cons for either
approach. So I don't really have an opinion on this.

But, assuming if implemented in existing drivers, those IOCTLs need to
be added to different drivers, which means userspace program needs to
write more code and get more handles, it would be slightly better to
implement a new driver from that perspective.

If gntdev/balloon extension is still considered:

All the IOCTLs will be in gntdev driver (in current xen-zcopy
terminology):
  - DRM_ICOTL_XEN_ZCOPY_DUMB_FROM_REFS
  - DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
  - DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE

Balloon driver extension, which is needed for contiguous/DMA
buffers, will be to provide new *kernel API*, no UAPI is needed.



So I am obviously a bit late to this thread, but why do you need to add
new ioctls to gntdev and balloon? Doesn't this driver manage to do what
you want without any extensions?

1. I only (may) need to add IOCTLs to gntdev
2. balloon driver needs to be extended, so it can allocate
contiguous (DMA) memory, not IOCTLs/UAPI here, all lives
in the kernel.
3. The reason I need to extend gnttab with new IOCTLs is to
provide new functionality to create a dma-buf from grant references
and to produce grant references for a dma-buf. This is what I have as UAPI
description for xen-zcopy driver:

1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS
This will create a DRM dumb buffer from grant references provided
by the frontend. The intended usage is:
  - Frontend
    - creates a dumb/display buffer and allocates memory
    - grants foreign access to the buffer pages
    - passes granted references to the backend
  - Backend
    - issues DRM_XEN_ZCOPY_DUMB_FROM_REFS ioctl to map
  granted references and create a dumb buffer
    - requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD
    - requests real HW driver/consumer to import the PRIME buffer with
  DRM_IOCTL_PRIME_FD_TO_HANDLE
    - uses handle returned by the real HW driver
  - at the end:
    o closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE
    o closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE
    o closes file descriptor of the exported buffer

2. DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
This will grant references to a dumb/display buffer's memory provided by the
backend. The intended usage is:
  - Frontend
    - requests backend to allocate dumb/display buffer and grant references
  to its pages
  - Backend
    - requests real HW driver to create a dumb with 
DRM_IOCTL_MODE_CREATE_DUMB

    - requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD
    - requests zero-copy driver to import the PRIME buffer with
  DRM_IOCTL_PRIME_FD_TO_HANDLE
    - issues DRM_XEN_ZCOPY_DUMB_TO_REFS ioctl to
  grant references to the buffer's memory.
    - passes grant references to the frontend
 - at the end:
    - closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE
    - closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE
    - closes file descriptor of the imported buffer

3. DRM_XEN_ZCOPY_DUMB_WAIT_FREE
This will block until the dumb buffer with the wait handle provided be 
freed:

this is needed for synchronization between frontend and backend in case
frontend provides grant references of the buffer via
DRM_XEN_ZCOPY_DUMB_FROM_REFS IOCTL and which must be released before
backend replies with XENDISPL_OP_DBUF_DESTROY response.
wait_handle must be the same value returned while calling
DRM_XEN_ZCOPY_DUMB_FROM_REFS IOCTL.

So, as you can see the above functionality is not covered by the 
existing UAPI

of the gntdev driver.
Now, if we change dumb -> dma-buf and remove DRM code (which is only a 
wrapper

here on top of dma-buf) we get new driver for dma-buf for Xen.

This is why I have 2 options here: either create a dedicated driver for this
(e.g. re-work xen-zcopy to be DRM independent and put it under
drivers/xen/xen-dma-buf, for example) or extend the existing 

Re: [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits

[Nautiyal, Ankit K]

On 4/23/2018 3:43 PM, Ville Syrjälä wrote:

On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote:


On 4/20/2018 7:42 PM, Ville Syrjälä wrote:

On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

This patch adds helper functions for determining if aspect-ratio is
expected in user-mode and for allowing/disallowing the aspect-ratio,
if its not expected.

Signed-off-by: Ankit Nautiyal 
---
   drivers/gpu/drm/drm_modes.c | 47 
+
   include/drm/drm_modes.h |  4 
   2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c395a24..d6133e8 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1759,3 +1759,50 @@ bool drm_mode_is_420(const struct drm_display_info 
*display,
drm_mode_is_420_also(display, mode);
   }
   EXPORT_SYMBOL(drm_mode_is_420);
+
+/**
+ * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information
+ * is expected from the user-mode.
+ *
+ * If the user has set aspect-ratio cap, then the flag of the user-mode is
+ * allowed to contain aspect-ratio value.
+ * If the user does not set aspect-ratio cap, then the only value allowed in 
the
+ * flags bits is aspect-ratio NONE.
+ *
+ * @file_priv: file private structure to get the user capabilities
+ * @umode: drm_mode_modeinfo struct, whose flag carry the aspect ratio
+ * information.
+ *
+ * Returns:
+ * true if the aspect-ratio info is allowed in the user-mode flags.
+ * false, otherwise.
+ */
+bool
+drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
+struct drm_mode_modeinfo *umode)
+{
+  return file_priv->aspect_ratio_allowed || (umode->flags &
+  DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE;

Odd line split here. Makes this a bit hard to read.
I would split after the ||

Agreed. I wasn't sure how to let it have better readability and less
than 80 char length
at the same time. Will fix this.


+}
+EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);

Do we actually need to export these? I don't think so.

But I might be wrong. It's a bit hard to see with the way
you split this patch with the actual users in a different patch.

These helper functions are used in drm_mode_atomic.c, drm_mode_crtc.c,
and drm_mode_get_connector.c
The patches are split as to have modes-set handling separate and the
exposing of connector separate.
Do you suggest this patch to be merged with the patch for handling
aspect-ratio in modeset?

Usually if you add a function you should do it in the same patch where
you add the user(s) for said function. Otherwise it's impossibly to
judge whether the new function is any good.


That makes sense. I will merge this patch with the patch for handling 
aspect ratio in modeset path,

where its actually used.




+
+/**
+ * drm_mode_filter_aspect_ratio_flags - filters the aspect-ratio bits in the
+ * user-mode flags.
+ *
+ * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio
+ * bits in the user-mode flags, if aspect-ratio info is not allowed.
+ *
+ * @file_priv: file private structure to get the user capabilities.
+ * @umode: drm_mode_modeinfo struct, whose flags' aspect-ratio bits needs to
+ * be filtered.
+ *
+ */
+void
+drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
+ struct drm_mode_modeinfo *umode)
+{
+  if (!drm_mode_aspect_ratio_allowed(file_priv, umode))
+  umode->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+}
+EXPORT_SYMBOL(drm_mode_filter_aspect_ratio_flags);
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 2f78b7e..e0b060d 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -461,6 +461,10 @@ bool drm_mode_is_420_also(const struct drm_display_info 
*display,
  const struct drm_display_mode *mode);
   bool drm_mode_is_420(const struct drm_display_info *display,
 const struct drm_display_mode *mode);
+bool drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
+ struct drm_mode_modeinfo *umode);
+void drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
+  struct drm_mode_modeinfo *umode);

   struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
  int hdisplay, int vdisplay, int vrefresh,
--
2.7.4

--
Ville Syrjälä
Intel


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

Re: [PATCH v11 07/11] drm: Add helper functions to handle aspect-ratio flag bits

[Nautiyal, Ankit K]

On 4/23/2018 3:52 PM, Jani Nikula wrote:

On Mon, 23 Apr 2018, "Nautiyal, Ankit K"  wrote:

On 4/20/2018 7:42 PM, Ville Syrjälä wrote:

On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 
+bool
+drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
+ struct drm_mode_modeinfo *umode)
+{
+   return file_priv->aspect_ratio_allowed || (umode->flags &
+   DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE;

Odd line split here. Makes this a bit hard to read.
I would split after the ||

Agreed. I wasn't sure how to let it have better readability and less
than 80 char length at the same time. Will fix this.

80 chars is not a strict requirement. Readability is. ;)

BR,
Jani.


Roger that! :)


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

Re: [RFC][PATCH 1/2] drm_hwcomposer: Cleanup gl precompositor init and provide uses_GL flag

[Rob Herring]

Please use "PATCH hwc" for drm_hwcomposer patches.

On Mon, Apr 23, 2018 at 7:06 PM, John Stultz  wrote:
> The drm_hwcomposer has its own GL pre-compositor which is used
> to squish layers when there are more layers then planes on the
> display hardware. In many ways this duplicates the client-side
> GL compositing that is done in SurfaceFlinger, but in theory can
> be more highly optimized for the hardware.
>
> Unfortunately, due to these optimizations, the drm_hwcomposer's
> pre-compositor becomes somewhat hardware specific (originally
> targeting nvidia hardware, I believe).
>
> So on some hardware, the gl precompositor may not actually
> initialize due to hardware missing features, or the hardware
> supporting different shader APIs.
>
> Rather then try to rework the drm_hwcomposers precompositor
> to be more generic, I instead suggest that when the
> precompositor fails to initialize, we simply fall back to the
> already more widely compatible client compositor in
> SurfaceFlinger.
>
> Thus, this patch cleans up some of the precompositor
> initialization, which didn't handle failures well.
>
> Feedback or alternative ideas would be greatly appreciated!
>
> Cc: Marissa Wall 
> Cc: Sean Paul 
> Cc: Dmitry Shmidt 
> Cc: Robert Foss 
> Cc: Matt Szczesiak 
> Cc: Liviu Dudau 
> Cc: David Hanna 
> Cc: Rob Herring 
> Cc: Alexandru-Cosmin Gheorghe 
> Cc: Alistair Strachan 
> Signed-off-by: John Stultz 
> ---
>  drmdisplaycompositor.cpp | 40 +---
>  drmdisplaycompositor.h   |  3 +++
>  2 files changed, 24 insertions(+), 19 deletions(-)

Both patches look good to me.

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

Re: [RESEND PATCH v6 16/27] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

[Jingoo Han]

On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
> 
> From: zain wang 
> 
> Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to
> Exynos:
> 
> on Exynos edp phy,
> BIT 7 MASTER_VID_FUNC_EN_N
> BIT 6 reserved
> BIT 5 SLAVE_VID_FUNC_EN_N
> 
> on Rockchip edp phy,
> BIT 7 reserved
> BIT 6 RK_VID_CAP_FUNC_EN_N
> BIT 5 RK_VID_FIFO_FUNC_EN_N
> 
> So, we should do some private operations to Rockchip.
> 
> Cc: Tomasz Figa 
> Signed-off-by: zain wang 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Reviewed-by: Andrzej Hajda 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 
> Reviewed-by: Archit Taneja 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
>  .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 19 ++-
>  .../gpu/drm/bridge/analogix/analogix_dp_reg.h |  2 ++
>  2 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 02ab1aaa9993..4eae206ec31b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -126,9 +126,14 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
>   analogix_dp_stop_video(dp);
>   analogix_dp_enable_video_mute(dp, 0);
> 
> - reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
> - AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
> - HDCP_FUNC_EN_N | SW_FUNC_EN_N;
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
> + reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
> + SW_FUNC_EN_N;
> + else
> + reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
> + AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
> + HDCP_FUNC_EN_N | SW_FUNC_EN_N;
> +
>   writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
> 
>   reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
> @@ -971,8 +976,12 @@ void analogix_dp_config_video_slave_mode(struct
> analogix_dp_device *dp)
>   u32 reg;
> 
>   reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
> - reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
> - reg |= MASTER_VID_FUNC_EN_N;
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
> + reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
> + } else {
> + reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
> + reg |= MASTER_VID_FUNC_EN_N;
> + }
>   writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
> 
>   reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> index b633a4a5082a..0cf27c731727 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
> @@ -127,7 +127,9 @@
> 
>  /* ANALOGIX_DP_FUNC_EN_1 */
>  #define MASTER_VID_FUNC_EN_N (0x1 << 7)
> +#define RK_VID_CAP_FUNC_EN_N (0x1 << 6)
>  #define SLAVE_VID_FUNC_EN_N  (0x1 << 5)
> +#define RK_VID_FIFO_FUNC_EN_N(0x1 << 5)
>  #define AUD_FIFO_FUNC_EN_N   (0x1 << 4)
>  #define AUD_FUNC_EN_N(0x1 << 3)
>  #define HDCP_FUNC_EN_N   (0x1 << 2)
> --
> 2.17.0


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

Re: [RESEND PATCH v6 14/27] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll

[Jingoo Han]

On Monday, April 23, 2018 6:50 AM, Enric Balletbo i Serra wrote:
> 
> From: zain wang 
> 
> There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg
> list.  We should use BIT_4 in ANALOGIX_DP_PD to control the pll power
> instead of ANALOGIX_DP_PLL_CTL.
> 
> Cc: Douglas Anderson 
> Signed-off-by: zain wang 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Reviewed-by: Andrzej Hajda 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 
> Reviewed-by: Archit Taneja 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
> 
>  .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 20 +++
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 7b7fd227e1f9..02ab1aaa9993 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -230,16 +230,20 @@ enum pll_status
> analogix_dp_get_pll_lock_status(struct analogix_dp_device *dp)
>  void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool
> enable)
>  {
>   u32 reg;
> + u32 mask = DP_PLL_PD;
> + u32 pd_addr = ANALOGIX_DP_PLL_CTL;
> 
> - if (enable) {
> - reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - reg |= DP_PLL_PD;
> - writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - } else {
> - reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
> - reg &= ~DP_PLL_PD;
> - writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
> + if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
> + pd_addr = ANALOGIX_DP_PD;
> + mask = RK_PLL_PD;
>   }
> +
> + reg = readl(dp->reg_base + pd_addr);
> + if (enable)
> + reg |= mask;
> + else
> + reg &= ~mask;
> + writel(reg, dp->reg_base + pd_addr);
>  }
> 
>  void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
> --
> 2.17.0


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

[Bug 106199] Cannot get back into DM after logoff (Linux 4.16.2+)

[bugzilla-daemon]

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

Bug ID: 106199
   Summary: Cannot get back into DM after logoff (Linux 4.16.2+)
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: m...@elbmurf.de

Created attachment 139031
  --> https://bugs.freedesktop.org/attachment.cgi?id=139031=edit
LightDM ant soccer

Starting with Linux 4.16.2, when I logoff from KDE Plasma, I don’t get back
into SDDM (just a black screen) or back into LightDM (wild random blocky
screen, see attachment).
I have a RX 580, DC is on. Same result on Linux 4.17rc2. Distro is
Antergos/Arch. Monitor is connected via DP.
Using SDDM, I can press ctrl + alt + F1 etc. to theoretically get to a tty
prompt but the screen does stay black. But then, after pressing ctrl + alt +
del numerous times, at least my system does a proper reboot. In LightDM, this
does not work and I have to use the reset button. Worked with Linux 4.16.1
before.

-- 
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 v2 3/3] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

[Eric Anholt]

This driver will be used to support Mesa on the Broadcom 7268 and 7278
platforms.

V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
complicated CL/shader validation scheme.  This massively changes the
GEM behavior, so I've forked off to a new driver.

v2: Mark SUBMIT_CL as needing DRM_AUTH.  coccinelle fixes from kbuild
test robot. Drop personal git link from MAINTAINERS.  Don't
double-map dma-buf imported BOs.  Add kerneldoc about needing MMU
eviction.  Drop prime vmap/unmap stubs.  Delay mmap offset setup
to mmap time.  Use drm_dev_init instead of _alloc.  Use
ktime_get() for wait_bo timeouts.  Drop drm_can_sleep() usage,
since we don't modeset.  Switch page tables back to WC (debug
change to coherent had slipped in).  Switch
drm_gem_object_unreference_unlocked() to
drm_gem_object_put_unlocked().  Simplify overflow mem handling by
not sharing overflow mem between jobs.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter 
---
 Documentation/gpu/drivers.rst  |   1 +
 MAINTAINERS|   8 +
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/v3d/Kconfig|   9 +
 drivers/gpu/drm/v3d/Makefile   |  18 +
 drivers/gpu/drm/v3d/v3d_bo.c   | 379 ++
 drivers/gpu/drm/v3d/v3d_debugfs.c  | 191 +++
 drivers/gpu/drm/v3d/v3d_drv.c  | 371 ++
 drivers/gpu/drm/v3d/v3d_drv.h  | 294 +++
 drivers/gpu/drm/v3d/v3d_fence.c|  58 +++
 drivers/gpu/drm/v3d/v3d_gem.c  | 663 +
 drivers/gpu/drm/v3d/v3d_irq.c  | 206 
 drivers/gpu/drm/v3d/v3d_mmu.c  | 122 +
 drivers/gpu/drm/v3d/v3d_regs.h | 295 +++
 drivers/gpu/drm/v3d/v3d_sched.c| 228 +
 drivers/gpu/drm/v3d/v3d_trace.h|  82 +++
 drivers/gpu/drm/v3d/v3d_trace_points.c |   9 +
 include/uapi/drm/v3d_drm.h | 191 +++
 19 files changed, 3128 insertions(+)
 create mode 100644 drivers/gpu/drm/v3d/Kconfig
 create mode 100644 drivers/gpu/drm/v3d/Makefile
 create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c
 create mode 100644 include/uapi/drm/v3d_drm.h

diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
index d3ab6abae838..f982558fc25d 100644
--- a/Documentation/gpu/drivers.rst
+++ b/Documentation/gpu/drivers.rst
@@ -10,6 +10,7 @@ GPU Driver Documentation
tegra
tinydrm
tve200
+   v3d
vc4
bridge/dw-hdmi
xen-front
diff --git a/MAINTAINERS b/MAINTAINERS
index bca3c32fb141..46c49c02d87b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4795,6 +4795,14 @@ S:   Maintained
 F: drivers/gpu/drm/omapdrm/
 F: Documentation/devicetree/bindings/display/ti/
 
+DRM DRIVERS FOR V3D
+M: Eric Anholt 
+S: Supported
+F: drivers/gpu/drm/v3d/
+F: include/uapi/drm/v3d_drm.h
+F: Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DRM DRIVERS FOR VC4
 M: Eric Anholt 
 T: git git://github.com/anholt/linux
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 757825ac60df..1c73a455fdb1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -267,6 +267,8 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
 
 source "drivers/gpu/drm/imx/Kconfig"
 
+source "drivers/gpu/drm/v3d/Kconfig"
+
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9d66657ea117..7a401edd8761 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_DRM_MGA) += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915) += i915/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
+obj-$(CONFIG_DRM_V3D)  += v3d/
 obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
 obj-$(CONFIG_DRM_SIS)   += sis/
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
new file mode 100644
index ..a0c0259355bd
--- /dev/null
+++ b/drivers/gpu/drm/v3d/Kconfig
@@ -0,0 +1,9 @@
+config DRM_V3D
+   tristate "Broadcom V3D 3.x and newer"
+   depends on ARCH_BCM || ARCH_BCMSTB || COMPILE_TEST
+   depends on DRM
+   depends on 

[PATCH v2 2/3] dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.

[Eric Anholt]

These OpenGL ES GPUs are present in the 7268 and 7278 set top box
chips.

Signed-off-by: Eric Anholt 
---
 .../bindings/display/brcm,bcm-v3d.txt | 28 +++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt 
b/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
new file mode 100644
index ..1c814714de0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
@@ -0,0 +1,28 @@
+Broadcom V3D GPU
+
+Only the Broadcom V3D 3.x and newer GPUs are covered by this binding.
+For V3D 2.x, see brcm,bcm-vc4.txt.
+
+Required properties:
+- compatible:  Should be "brcm,7268-v3d" or "brcm,7278-v3d"
+- reg: Physical base addresses and lengths of the register areas
+- reg-names:   Names for the register areas.  The "hub", "bridge", and "core0"
+ register areas are always required.  The "gca" register area
+ is required if the GCA cache controller is present.
+- interrupts:  The interrupt numbers.  The first interrupt is for the hub,
+ while the following inerrupts are for the cores.
+ See bindings/interrupt-controller/interrupts.txt
+
+Optional properties:
+- clocks:  The core clock the unit runs on
+
+v3d {
+   compatible = "brcm,7268-v3d";
+   reg = <0xf1204000 0x100>,
+ <0xf120 0x4000>,
+ <0xf1208000 0x4000>,
+ <0xf1204100 0x100>;
+   reg-names = "bridge", "hub", "core0", "gca";
+   interrupts = <0 78 4>,
+<0 77 4>;
+};
-- 
2.17.0

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

[PATCH v2 0/3] V3D DRM driver

[Eric Anholt]

Here's v2 of the driver.  This is mostly handling danvet's feedback,
but there are a couple of other changes:

- new core patch for prime vmap/vunmap
- kbuild test robot fixes
- overflow mem simplification (figured it out over breakfast with keithp)
- drm_gem_object_unreference_unlocked() to _put_unlocked().

Eric Anholt (3):
  drm: Make the prime vmap/vunmap hooks optional.
  dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.
  drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

 .../bindings/display/brcm,bcm-v3d.txt |  28 +
 Documentation/gpu/drivers.rst |   1 +
 MAINTAINERS   |   8 +
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/drm_prime.c   |   8 +-
 drivers/gpu/drm/v3d/Kconfig   |   9 +
 drivers/gpu/drm/v3d/Makefile  |  18 +
 drivers/gpu/drm/v3d/v3d_bo.c  | 379 ++
 drivers/gpu/drm/v3d/v3d_debugfs.c | 191 +
 drivers/gpu/drm/v3d/v3d_drv.c | 371 ++
 drivers/gpu/drm/v3d/v3d_drv.h | 294 
 drivers/gpu/drm/v3d/v3d_fence.c   |  58 ++
 drivers/gpu/drm/v3d/v3d_gem.c | 663 ++
 drivers/gpu/drm/v3d/v3d_irq.c | 206 ++
 drivers/gpu/drm/v3d/v3d_mmu.c | 122 
 drivers/gpu/drm/v3d/v3d_regs.h| 295 
 drivers/gpu/drm/v3d/v3d_sched.c   | 228 ++
 drivers/gpu/drm/v3d/v3d_trace.h   |  82 +++
 drivers/gpu/drm/v3d/v3d_trace_points.c|   9 +
 include/uapi/drm/v3d_drm.h| 191 +
 21 files changed, 3162 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
 create mode 100644 drivers/gpu/drm/v3d/Kconfig
 create mode 100644 drivers/gpu/drm/v3d/Makefile
 create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c
 create mode 100644 include/uapi/drm/v3d_drm.h

-- 
2.17.0

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

[PATCH v2 1/3] drm: Make the prime vmap/vunmap hooks optional.

[Eric Anholt]

Some drivers leave these unimplemented, so don't make them have
unimplemented stubs.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/drm_prime.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index caf675e3e692..397b46b33739 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -409,7 +409,10 @@ void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
 
-   return dev->driver->gem_prime_vmap(obj);
+   if (dev->driver->gem_prime_vmap)
+   return dev->driver->gem_prime_vmap(obj);
+   else
+   return NULL;
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_vmap);
 
@@ -426,7 +429,8 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void 
*vaddr)
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
 
-   dev->driver->gem_prime_vunmap(obj, vaddr);
+   if (dev->driver->gem_prime_vunmap)
+   dev->driver->gem_prime_vunmap(obj, vaddr);
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
 
-- 
2.17.0

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

Re: [RFC][PATCH 2/2] drm_hwcomposer: Fall back to client compositon if the gl precompostior fails

[John Stultz]

On Mon, Apr 23, 2018 at 5:06 PM, John Stultz  wrote:
> If the gl precompositor isn't being used, we cannot accept
> every layer as a device composited layer.
>
> Thus this patch adds some extra logic in the validate function
> to try to map layers to available device planes, falling back
> to client side compositing if we run-out of planes.
>
> Credit to Rob Herring, who's work this single plane patch was
> originally based on.
>
> Feedback or alternative ideas would be greatly appreciated!
>
> Cc: Marissa Wall 
> Cc: Sean Paul 
> Cc: Dmitry Shmidt 
> Cc: Robert Foss 
> Cc: Matt Szczesiak 
> Cc: Liviu Dudau 
> Cc: David Hanna 
> Cc: Rob Herring 
> Cc: Alexandru-Cosmin Gheorghe 
> Cc: Alistair Strachan 
> Signed-off-by: John Stultz 
> Signed-off-by: John Stultz 

A patch so nice, I signed it off twice! :P

Sorry, looks like I yanked and pasted one too many lines from the cc list.

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

[RFC][PATCH 1/2] drm_hwcomposer: Cleanup gl precompositor init and provide uses_GL flag

[John Stultz]

The drm_hwcomposer has its own GL pre-compositor which is used
to squish layers when there are more layers then planes on the
display hardware. In many ways this duplicates the client-side
GL compositing that is done in SurfaceFlinger, but in theory can
be more highly optimized for the hardware.

Unfortunately, due to these optimizations, the drm_hwcomposer's
pre-compositor becomes somewhat hardware specific (originally
targeting nvidia hardware, I believe).

So on some hardware, the gl precompositor may not actually
initialize due to hardware missing features, or the hardware
supporting different shader APIs.

Rather then try to rework the drm_hwcomposers precompositor
to be more generic, I instead suggest that when the
precompositor fails to initialize, we simply fall back to the
already more widely compatible client compositor in
SurfaceFlinger.

Thus, this patch cleans up some of the precompositor
initialization, which didn't handle failures well.

Feedback or alternative ideas would be greatly appreciated!

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Signed-off-by: John Stultz 
---
 drmdisplaycompositor.cpp | 40 +---
 drmdisplaycompositor.h   |  3 +++
 2 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index e556e86..5c6bf9b 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -222,6 +222,13 @@ int DrmDisplayCompositor::Init(DrmResources *drm, int 
display) {
 return ret;
   }
 
+  pre_compositor_.reset(new GLWorkerCompositor());
+  ret = pre_compositor_->Init();
+  if (ret) {
+ALOGE("Failed to initialize OpenGL compositor %d", ret);
+pre_compositor_.reset();
+  }
+
   initialized_ = true;
   return 0;
 }
@@ -294,14 +301,16 @@ int 
DrmDisplayCompositor::ApplySquash(DrmDisplayComposition *display_comp) {
   }
 
   std::vector  = display_comp->squash_regions();
-  ret = pre_compositor_->Composite(display_comp->layers().data(),
+  if (pre_compositor_) {
+ret = pre_compositor_->Composite(display_comp->layers().data(),
regions.data(), regions.size(), fb.buffer(),
display_comp->importer());
-  pre_compositor_->Finish();
+pre_compositor_->Finish();
 
-  if (ret) {
-ALOGE("Failed to squash layers");
-return ret;
+if (ret) {
+  ALOGE("Failed to squash layers");
+  return ret;
+}
   }
 
   ret = display_comp->CreateNextTimelineFence();
@@ -328,14 +337,16 @@ int DrmDisplayCompositor::ApplyPreComposite(
   }
 
   std::vector  = 
display_comp->pre_comp_regions();
-  ret = pre_compositor_->Composite(display_comp->layers().data(),
+  if (pre_compositor_) {
+ret = pre_compositor_->Composite(display_comp->layers().data(),
regions.data(), regions.size(), fb.buffer(),
display_comp->importer());
-  pre_compositor_->Finish();
+pre_compositor_->Finish();
 
-  if (ret) {
-ALOGE("Failed to pre-composite layers");
-return ret;
+if (ret) {
+  ALOGE("Failed to pre-composite layers");
+  return ret;
+}
   }
 
   ret = display_comp->CreateNextTimelineFence();
@@ -395,15 +406,6 @@ int 
DrmDisplayCompositor::PrepareFrame(DrmDisplayComposition *display_comp) {
   std::vector _comp_regions =
   display_comp->pre_comp_regions();
 
-  if (!pre_compositor_) {
-pre_compositor_.reset(new GLWorkerCompositor());
-int ret = pre_compositor_->Init();
-if (ret) {
-  ALOGE("Failed to initialize OpenGL compositor %d", ret);
-  return ret;
-}
-  }
-
   int squash_layer_index = -1;
   if (squash_regions.size() > 0) {
 squash_framebuffer_index_ = (squash_framebuffer_index_ + 1) % 2;
diff --git a/drmdisplaycompositor.h b/drmdisplaycompositor.h
index f1965fb..ed6c5f9 100644
--- a/drmdisplaycompositor.h
+++ b/drmdisplaycompositor.h
@@ -98,6 +98,9 @@ class DrmDisplayCompositor {
 return _state_;
   }
 
+  bool uses_GL() {
+return !!pre_compositor_;
+  }
  private:
   struct ModeState {
 bool needs_modeset = false;
-- 
2.7.4

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

[RFC][PATCH 2/2] drm_hwcomposer: Fall back to client compositon if the gl precompostior fails

[John Stultz]

If the gl precompositor isn't being used, we cannot accept
every layer as a device composited layer.

Thus this patch adds some extra logic in the validate function
to try to map layers to available device planes, falling back
to client side compositing if we run-out of planes.

Credit to Rob Herring, who's work this single plane patch was
originally based on.

Feedback or alternative ideas would be greatly appreciated!

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Signed-off-by: John Stultz 
Signed-off-by: John Stultz 
---
 drmhwctwo.cpp | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index dfca1a6..437a439 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -686,6 +686,15 @@ HWC2::Error 
DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
   supported(__func__);
   *num_types = 0;
   *num_requests = 0;
+  int avail_planes = primary_planes_.size() + overlay_planes_.size();
+
+  /*
+   * If more layers then planes, save one plane
+   * for client composited layers
+   */
+  if (avail_planes < layers_.size())
+   avail_planes--;
+
   for (std::pair  : layers_) {
 DrmHwcTwo::HwcLayer  = l.second;
 switch (layer.sf_type()) {
@@ -695,6 +704,15 @@ HWC2::Error 
DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
 layer.set_validated_type(HWC2::Composition::Client);
 ++*num_types;
 break;
+  case HWC2::Composition::Device:
+if (!compositor_.uses_GL() && !avail_planes) {
+  layer.set_validated_type(HWC2::Composition::Client);
+  ++*num_types;
+  break;
+} else {
+  avail_planes--;
+   }
+   /* fall through */
   default:
 layer.set_validated_type(layer.sf_type());
 break;
-- 
2.7.4

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

[PATCH] Intel: Add a Kaby Lake PCI ID

[matthew . s . atwood]

From: Matt Atwood 

Signed-off-by: Matt Atwood 
---
 intel/intel_chipset.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 01d250e..6b8fd1d 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -203,6 +203,7 @@
 #define PCI_CHIP_KABYLAKE_ULX_GT2  0x591E
 #define PCI_CHIP_KABYLAKE_DT_GT2   0x5912
 #define PCI_CHIP_KABYLAKE_M_GT20x5917
+#define PCI_CHIP_KABYLAKE_M_GT20x591C
 #define PCI_CHIP_KABYLAKE_DT_GT1   0x5902
 #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B
 #define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B
-- 
2.7.4

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

Re: [PATCH v2] drm: rcar-du: track dma-buf fences

[Laurent Pinchart]

Hi Emre,

Sorry for the late reply.

On Wednesday, 4 April 2018 14:03:57 EEST Emre Ucan wrote:
> We have to check dma-buf reservation objects
> of our framebuffers before we use them.
> Otherwise, another driver might be writing
> on the same buffer which we are using.
> This would cause visible tearing effects
> on display.
> 
> We can use existing atomic helper functions
> to solve this problem.

I've always found the 72 columns limit in commit messages to be quite 
limiting, especially for the subject line. Out of curiosity, is there any 
specific reason why you limit it further ?

> v2 changes:
> - Remove drm_atomic_helper_wait_for_fences()
>   call in rcar_du_kms.c. The commit_tail()
>   function in drm_atomic_helper.c, which calls
>   our atomic_commit_tail() implementation,
>   already calls it.
> - Remove proposed rcar_du_vsp_set_fence_for_plane()
>   function. Call drm_gem_fb_prepare_fb(), which
>   calls drm_atomic_set_fence_for_plane().
> 
> Signed-off-by: Emre Ucan 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 2c260c3..fbad616 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Nitpicking, could you please keep the headers alphabetically sorted ? It helps 
locating duplicates quickly.

>  #include 
>  #include 
> @@ -237,7 +238,7 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
> *plane, }
>   }
> 
> - return 0;
> + return drm_gem_fb_prepare_fb(plane, state);

If drm_gem_fb_prepare_fb() fails we need to clean up the operations performed 
earlier in this function. I think the following would be enough.

ret = drm_gem_fb_prepare_fb(plane, state);
if (ret)
goto fail;

return 0;

Could you please test this ?

>  fail:
>   while (i--) {

-- 
Regards,

Laurent Pinchart



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

[Bug 91808] trine1 misrender r600g

[bugzilla-daemon]

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

--- Comment #11 from Dave Airlie  ---
Created attachment 139029
  --> https://bugs.freedesktop.org/attachment.cgi?id=139029=edit
attempted fix

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

Re: RFC for a render API to support adaptive sync and VRR

[Manasi Navare]

On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote:
> On 2018-04-20 04:32 PM, Manasi Navare wrote:
> > On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
> >> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard  wrote:
> >>> Michel Dänzer  writes:
>  Time-based presentation seems to be the right approach for preventing
>  micro-stutter in games as well, Croteam developers have been researching
>  this.
> >>>
> >>> Both the Vulkan GOOGLE_display_timing extension and X11 Present
> >>> extension offer the ability to specify the desired display time in
> >>> seconds.
> >>>
> >>> Similarly, I'd suggest that the min/max display refresh rate values be
> >>> advertised as time between frames rather than frames per second.
> > 
> > So there is a global min and max refresh rate as advertised by the monitor
> > range descriptor. That I guess can be exposed as a global range in terms of
> > min and max time between frames as a global property of the connector.
> > 
> > We dont need the per mode min and max refresh rate to be exposed right?
> 
> If I understand VRR right, with CinemaVRR acceptable refresh rates might fall 
> outside the range advertised by the monitor. Would we
>  1) advertise 24/1.001 as a lower bound,
>  2) expect media apps to use the lower bound simply for informational 
> purposes,
>  3) or simply not support CinemaVRR?
> 
> (1) has the added caveat that not all reported rates would be supported.
> 
> Alternatively a bit could indicate that CinemaVRR is support, but I'm not 
> sure if user mode would need all these details.
> 
> Harry

Are there special CinemaVRR suported monitors? In that case we need to 
understand how those monitors
advertise the monitor range and if they have a bit in EDID that indicate they 
are CinemaVRR capable
as opposed to just the Adaptive Sync/VRR.
Harry, if you have one of those monitors, could you send the EDID dump for that?

Manasi

> 
> > 
> >>>
> >>> I'd also encourage using a single unit for all of these values,
> >>> preferably nanoseconds. Absolute times should all be referenced to
> >>> CLOCK_MONOTONIC.
> >>
> >> +1 on everything Keith said. I got somehow dragged in khr vk
> >> discussions around preventing micro-stuttering, and consensus seems to
> >> be that timestamps for scheduling frames is the way to go, most likely
> >> absolute ones (not everything is running Linux unfortunately, so can't
> >> go outright and claim it's guaranteed to be CLOCK_MONOTONIC).
> >> -Daniel
> > 
> > And yes I also got consensus from Mesa and media folks about using the
> > absolute timestamp for scheduling the frames and then the driver will
> > modify the vblank logic to "present no earlier than the timestamp"
> > 
> > Manasi
> > 
> >> -- 
> >> 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
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/8] drm: connector: Remove DRM_BUS_FLAG_DATA_* flags

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Thursday, 19 April 2018 12:31:09 EEST Jacopo Mondi wrote:
> DRM_BUS_FLAG_DATA_* flags, defined in drm_connector.h header file are
> used to swap ordering of LVDS RGB format to accommodate DRM objects
> that need to handle LVDS components ordering.
> 
> Now that the only 2 users of DRM_BUS_FLAG_DATA_* flags have been ported
> to use the newly introduced MEDIA_BUS_FMT_RGB888_1X7X*_LE media bus
> formats, remove them.

I'm not opposed to this (despite my review of patch 5/8), but I think the _LE 
suffix isn't the right name for the new formats. _BE and _LE relate to byte 
swapping, while here you really need to describe full mirroring. Maybe a 
_MIRROR variant would be more appropriate ?

> Signed-off-by: Jacopo Mondi 
> ---
>  include/drm/drm_connector.h | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 675cc3f..9e0d6d5 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -286,10 +286,6 @@ struct drm_display_info {
>  #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2)
>  /* drive data on neg. edge */
>  #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3)
> -/* data is transmitted MSB to LSB on the bus */
> -#define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4)
> -/* data is transmitted LSB to MSB on the bus */
> -#define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5)
> 
>   /**
>* @bus_flags: Additional information (like pixel signal polarity) for


-- 
Regards,

Laurent Pinchart



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

[Bug 106196] GPU randomly hangs while playing game Rise of the Tomb Rider

[bugzilla-daemon]

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

Bug ID: 106196
   Summary: GPU randomly hangs while playing game Rise of the Tomb
Rider
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com

Created attachment 139028
  --> https://bugs.freedesktop.org/attachment.cgi?id=139028=edit
dmesg

* Fedora 28 -
https://download.fedoraproject.org/pub/fedora/linux/releases/test/28_Beta/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-28_Beta-1.3.iso
* Latest system updates:
 - kernel 4.16.3
 - mesa 18.0.1
 - llvm 6.0.0
* Steam client version 1523923735

For reproduction issue:
1) Play in game several hours until GPU hang occurs

Symptoms:
1. The system stop to respod.
2. All the LEDs on the video card showing the load start to glow.
3. The turbine on the video card starts to make a lot of noise.

kernel output after GPU hang:
[10918.342576] amdgpu :07:00.0: [gfxhub] VMC page fault (src_id:0 ring:158
vmid:7 pas_id:0)
[10918.342582] amdgpu :07:00.0:   at page 0x1891a90f from 27
[10918.342585] amdgpu :07:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x0070113D
[10918.342591] amdgpu :07:00.0: [gfxhub] VMC page fault (src_id:0 ring:158
vmid:7 pas_id:0)
[10918.342594] amdgpu :07:00.0:   at page 0x1891a90f from 27
[10918.342597] amdgpu :07:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x
[10928.687661] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last signaled seq=1874360, last emitted seq=1874362
[10928.687666] [drm] No hardware hang detected. Did some blocks stall?
[11016.291301] sysrq: SysRq : Show Blocked State
[11016.291315]   taskPC stack   pid father
[11016.291509] XwaylandD10616  1956   1882 0x0004
[11016.291522] Call Trace:
[11016.291541]  ? __schedule+0x2bd/0xb00
[11016.291555]  ? dma_fence_wait_any_timeout+0x264/0x2f0
[11016.291564]  schedule+0x2f/0x90
[11016.291573]  schedule_timeout+0x35c/0x520
[11016.291592]  ? dma_fence_wait_any_timeout+0x264/0x2f0
[11016.291602]  dma_fence_wait_any_timeout+0x230/0x2f0
[11016.291734]  amdgpu_sa_bo_new+0x444/0x510 [amdgpu]
[11016.291900]  amdgpu_ib_get+0x31/0x90 [amdgpu]
[11016.292048]  amdgpu_job_alloc_with_ib+0x46/0x80 [amdgpu]
[11016.292128]  amdgpu_map_buffer.isra.10+0xa3/0x1f0 [amdgpu]
[11016.292215]  amdgpu_ttm_copy_mem_to_mem+0x3c6/0x5d0 [amdgpu]
[11016.292305]  ? amdgpu_vm_bo_invalidate+0x3b/0x210 [amdgpu]
[11016.292385]  amdgpu_move_blit.constprop.13+0x82/0x110 [amdgpu]
[11016.292467]  amdgpu_bo_move+0x94/0x1c0 [amdgpu]
[11016.292486]  ttm_bo_handle_move_mem+0x10d/0x540 [ttm]
[11016.292509]  ? ttm_bo_evict+0x155/0x1e0 [ttm]
[11016.292530]  ? mutex_trylock+0xcd/0xe0
[11016.292552]  ? ttm_mem_evict_first+0x1cf/0x260 [ttm]
[11016.292574]  ? ttm_bo_mem_space+0x2da/0x4a0 [ttm]
[11016.292599]  ? ttm_bo_validate+0xe3/0x1a0 [ttm]
[11016.292612]  ? ttm_bo_init_reserved+0x40e/0x470 [ttm]
[11016.292628]  ? mutex_trylock+0xcd/0xe0
[11016.292645]  ? ttm_bo_init_reserved+0x42a/0x470 [ttm]
[11016.292723]  ? amdgpu_bo_do_create+0x1da/0x570 [amdgpu]
[11016.292799]  ? amdgpu_fill_buffer+0x320/0x320 [amdgpu]
[11016.292885]  ? amdgpu_bo_create+0x4f/0x2c0 [amdgpu]
[11016.292993]  ? amdgpu_gem_object_create+0x80/0x110 [amdgpu]
[11016.293075]  ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu]
[11016.293153]  ? amdgpu_gem_create_ioctl+0x1eb/0x2a0 [amdgpu]
[11016.293165]  ? __might_fault+0x3e/0x90
[11016.293244]  ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu]
[11016.293277]  ? drm_ioctl_kernel+0x5b/0xb0 [drm]
[11016.293308]  ? drm_ioctl+0x1c0/0x380 [drm]
[11016.293417]  ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu]
[11016.293529]  ? amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[11016.293544]  ? do_vfs_ioctl+0xa5/0x6d0
[11016.293559]  ? SyS_ioctl+0x74/0x80
[11016.293574]  ? do_syscall_64+0x79/0x210
[11016.293584]  ? entry_SYSCALL_64_after_hwframe+0x42/0xb7
[11016.294195] kworker/u16:2   D12472 10521  2 0x8000
[11016.294228] Workqueue: events_unbound commit_work [drm_kms_helper]
[11016.294237] Call Trace:
[11016.294252]  ? __schedule+0x2bd/0xb00
[11016.294266]  ? dma_fence_default_wait+0x231/0x370
[11016.294278]  schedule+0x2f/0x90
[11016.294288]  schedule_timeout+0x35c/0x520
[11016.294301]  ? dma_fence_default_wait+0x72/0x370
[11016.294316]  ? dma_fence_default_wait+0x231/0x370
[11016.294325]  dma_fence_default_wait+0x25d/0x370
[11016.294334]  ? dma_fence_release+0x160/0x160
[11016.294347]  dma_fence_wait_timeout+0x4f/0x270
[11016.294358]  reservation_object_wait_timeout_rcu+0x236/0x4e0
[11016.294485]  amdgpu_dm_do_flip+0x112/0x360 [amdgpu]
[11016.294624]  amdgpu_dm_atomic_commit_tail+0xac7/0xda0 [amdgpu]
[11016.294640]  ? wait_for_completion_timeout+0x73/0x1a0
[11016.294673]  commit_tail+0x3d/0x70 [drm_kms_helper]

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

On Monday, 23 April 2018 23:09:55 EEST Mauro Carvalho Chehab wrote:
> Laurent Pinchart  escreveu:
> > On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote:
> > > Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:
> > > > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> > > >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > > >>> Add stubs for omapfb_dss.h, in the case it is included by
> > > >>> some driver when CONFIG_FB_OMAP2 is not defined, with can
> > > >>> happen on ARM when DRM_OMAP is not 'n'.
> > > >>> 
> > > >>> That allows building such driver(s) with COMPILE_TEST.
> > > >>> 
> > > >>> Signed-off-by: Mauro Carvalho Chehab 
> > > >> 
> > > >> This patch should be dropped (together with patch #6/7) as it was
> > > >> superseded by a better solution suggested by Laurent:
> > > >> 
> > > >> https://patchwork.kernel.org/patch/10325193/
> > > >> 
> > > >> ACK-ed by Tomi:
> > > >> 
> > > >> https://www.spinics.net/lists/dri-devel/msg171918.html
> > > >> 
> > > >> and already merged by you (commit 7378f1149884 "media: omap2:
> > > >> omapfb: allow building it with COMPILE_TEST")..
> > > > 
> > > > Hmm, I see now while this patch is still included:
> > > > 
> > > > menuconfig FB_OMAP2
> > > > 
> > > > tristate "OMAP2+ frame buffer support"
> > > > depends on FB
> > > > depends on DRM_OMAP = n
> > > > 
> > > > Ideally we should be able to build both drivers in the same kernel
> > > > (especially as modules).
> > > > 
> > > > I was hoping that it could be fixed easily but then I discovered
> > > > the root source of the problem:
> > > > 
> > > > drivers/gpu/drm/omapdrm/dss/display.o: In function
> > > > `omapdss_unregister_display': display.c:(.text+0x2c): multiple
> > > > definition
> > > > of `omapdss_unregister_display'
> > > > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198)
> > > > :
> > > > first defined here ...
> > > 
> > > Yes, and declared on two different places:
> > > 
> > > drivers/gpu/drm/omapdrm/dss/omapdss.h:void
> > > omapdss_unregister_display(struct omap_dss_device *dssdev);
> > > include/video/omapfb_dss.h:void
> > > omapdss_unregister_display(struct omap_dss_device *dssdev);
> > > 
> > > one alternative would be to give different names to it, and a common
> > > header for both.
> > > 
> > > At such header, it could be doing something like:
> > > 
> > > static inline void omapdss_unregister_display(struct omap_dss_device
> > > *dssdev) {
> > > #if enabled(CONFIG_DRM_OMAP)
> > > 
> > >   omapdss_unregister_display_drm(struct omap_dss_device *dssdev);
> > > 
> > > #else
> > > 
> > >   omapdss_unregister_display_fb(struct omap_dss_device *dssdev);
> > > 
> > > ##endif
> > > }
> > > 
> > > Yet, after a very quick check, it seems that nowadays only the
> > > media omap driver uses the symbols at FB_OMAP:
> > > 
> > > $ git grep omapfb_dss.h
> > > drivers/media/platform/omap/omap_vout.c:#include 
> > > drivers/media/platform/omap/omap_voutdef.h:#include 
> > > drivers/media/platform/omap/omap_voutlib.c:#include 
> > > 
> > > So, perhaps just renaming the common symbols and changing FB_OMAP2 to:
> > >   menuconfig FB_OMAP2
> > >   
> > >tristate "OMAP2+ frame buffer support"
> > >depends on FB
> > >depends on (DRM_OMAP = n) || COMPILE_TEST
> > > 
> > > would be enough to allow to build both on ARM.
> > 
> > I don't think it's worth it renaming the common symbols. They will change
> > over time as omapdrm is under heavy rework, and it's painful enough
> > without having to handle cross-tree changes.
> 
> It could just rename the namespace-conflicting FB_OMAP2 functions,
> keeping the DRM ones as-is.
> 
> > Let's just live with the fact that both drivers
> > can't be compiled at the same time, given that omapfb is deprecated.
> 
> IMO, a driver that it is deprecated, being in a state where it
> conflicts with a non-deprecated driver that is under heavy rework
> is a very good candidate to go to drivers/staging or even to /dev/null.

It's on its way, but slowly as we need to take userspace into account. Tomi 
should have more insight on a possible schedule for removal of omapfb.

-- 
Regards,

Laurent Pinchart



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

[Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI

[bugzilla-daemon]

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

--- Comment #5 from Jan Vesely  ---
(In reply to Jan Vesely from comment #4)
> Lowering CL requirements combined with the following pull requests:
> https://github.com/Theano/libgpuarray/pull/571
> https://github.com/Theano/libgpuarray/pull/570

Both above pull requests have been merged with slight modifications. running
CLOVER_DEVICE_VERSION_OVERRIDE=1.2 CLOVER_DEVICE_CLC_VERSION_OVERRIDE=1.2

results in:

Ran 6670 tests in 991.622s

OK (SKIP=12)

-- 
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 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Laurent Pinchart]

Hi Mauro,

On Monday, 23 April 2018 17:22:27 EEST Mauro Carvalho Chehab wrote:
> Em Mon, 23 Apr 2018 15:56:53 +0200 Bartlomiej Zolnierkiewicz escreveu:
> > On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> >> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> >>> Add stubs for omapfb_dss.h, in the case it is included by
> >>> some driver when CONFIG_FB_OMAP2 is not defined, with can
> >>> happen on ARM when DRM_OMAP is not 'n'.
> >>> 
> >>> That allows building such driver(s) with COMPILE_TEST.
> >>> 
> >>> Signed-off-by: Mauro Carvalho Chehab 
> >> 
> >> This patch should be dropped (together with patch #6/7) as it was
> >> superseded by a better solution suggested by Laurent:
> >> 
> >> https://patchwork.kernel.org/patch/10325193/
> >> 
> >> ACK-ed by Tomi:
> >> 
> >> https://www.spinics.net/lists/dri-devel/msg171918.html
> >> 
> >> and already merged by you (commit 7378f1149884 "media: omap2:
> >> omapfb: allow building it with COMPILE_TEST")..
> > 
> > Hmm, I see now while this patch is still included:
> > 
> > menuconfig FB_OMAP2
> > tristate "OMAP2+ frame buffer support"
> > depends on FB
> > depends on DRM_OMAP = n
> > 
> > Ideally we should be able to build both drivers in the same kernel
> > (especially as modules).
> > 
> > I was hoping that it could be fixed easily but then I discovered
> > the root source of the problem:
> > 
> > drivers/gpu/drm/omapdrm/dss/display.o: In function
> > `omapdss_unregister_display': display.c:(.text+0x2c): multiple definition
> > of `omapdss_unregister_display'
> > drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198):
> > first defined here ...
> 
> Yes, and declared on two different places:
> 
> drivers/gpu/drm/omapdrm/dss/omapdss.h:void omapdss_unregister_display(struct
> omap_dss_device *dssdev); include/video/omapfb_dss.h:void
> omapdss_unregister_display(struct omap_dss_device *dssdev);
> 
> one alternative would be to give different names to it, and a common
> header for both.
> 
> At such header, it could be doing something like:
> 
> static inline void omapdss_unregister_display(struct omap_dss_device
> *dssdev) {
> #if enabled(CONFIG_DRM_OMAP)
>   omapdss_unregister_display_drm(struct omap_dss_device *dssdev);
> #else
>   omapdss_unregister_display_fb(struct omap_dss_device *dssdev);
> ##endif
> }
> 
> Yet, after a very quick check, it seems that nowadays only the
> media omap driver uses the symbols at FB_OMAP:
> 
> $ git grep omapfb_dss.h
> drivers/media/platform/omap/omap_vout.c:#include 
> drivers/media/platform/omap/omap_voutdef.h:#include 
> drivers/media/platform/omap/omap_voutlib.c:#include 
> 
> So, perhaps just renaming the common symbols and changing FB_OMAP2 to:
> 
>   menuconfig FB_OMAP2
>tristate "OMAP2+ frame buffer support"
>depends on FB
>depends on (DRM_OMAP = n) || COMPILE_TEST
> 
> would be enough to allow to build both on ARM.

I don't think it's worth it renaming the common symbols. They will change over 
time as omapdrm is under heavy rework, and it's painful enough without having 
to handle cross-tree changes. Let's just live with the fact that both drivers 
can't be compiled at the same time, given that omapfb is deprecated.

> > I need some more time to think about this..

-- 
Regards,

Laurent Pinchart



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

[Bug 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend

[bugzilla-daemon]

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

--- Comment #7 from Jan Vlug  ---
Created attachment 139027
  --> https://bugs.freedesktop.org/attachment.cgi?id=139027=edit
dmesg

Requested dmesg.

-- 
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 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend

[bugzilla-daemon]

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

--- Comment #6 from Jan Vlug  ---
Created attachment 139026
  --> https://bugs.freedesktop.org/attachment.cgi?id=139026=edit
glxinfo

Requested glxinfo.

-- 
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 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend

[bugzilla-daemon]

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

--- Comment #5 from Jan Vlug  ---
Sorry for my late reply. The interesting thing is that the flickering did not
occur any more since comment 4 was added. I was waiting for the flickering to
occur again before posting the requested info, but it did not until now, so I
will attach the requested info while the flickering is not manifest.

My current versions are:
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Baffin [Radeon RX 460/560D /
Pro 450/455/460/560]
   Display Server: X.org 1.19.6 drivers: modesetting,fbdev,vesa
   tty size: 166x42 Advanced Data: N/A for root

Linux nyx 4.15.17-300.fc27.x86_64 #1 SMP Thu Apr 12 18:19:17 UTC 2018 x86_64
x86_64 x86_64 GNU/Linux

-- 
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] MAINTAINERS: drm: fsl-dcu: Update to NXP email address

[Fabio Estevam]

Hi Stefan,

On Fri, Mar 30, 2018 at 2:10 PM, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> The freescale.com domain will stop working soon, so use
> the nxp.com domain instead.
>
> Signed-off-by: Fabio Estevam 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4923621..794c130 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4661,7 +4661,7 @@ F:
> Documentation/devicetree/bindings/display/exynos/
>
>  DRM DRIVERS FOR FREESCALE DCU
>  M: Stefan Agner 
> -M: Alison Wang 
> +M: Alison Wang 

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

Re: [PATCH 4/4] drm/vc4: Add parameter for syncobj support

[Eric Anholt]

Stefan Schake  writes:

> This allows runtime detection of syncobj submission support.
>
> Signed-off-by: Stefan Schake 

I think if we move patch 1 after 2+3, then we can just drop this one and
use drmGetCap(fd, DRM_CAP_SYNCOBJ, ) in userspace for detection.


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

Re: [PATCH 3/4] drm/vc4: Export fence through syncobj

[Eric Anholt]

Stefan Schake  writes:

> Allow specifying a syncobj on render job submission where we store the
> fence for the job. This gives userland flexible access to the fence.
>
> Signed-off-by: Stefan Schake 
> ---
>  drivers/gpu/drm/vc4/vc4_gem.c | 38 +++---
>  include/uapi/drm/vc4_drm.h| 13 +
>  2 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index 232363488125..b39515a4ddcb 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -656,7 +656,8 @@ vc4_lock_bo_reservations(struct drm_device *dev,
>   */
>  static int
>  vc4_queue_submit(struct drm_device *dev, struct vc4_exec_info *exec,
> -  struct ww_acquire_ctx *acquire_ctx)
> +  struct ww_acquire_ctx *acquire_ctx,
> +  struct drm_syncobj *out_sync)
>  {
>   struct vc4_dev *vc4 = to_vc4_dev(dev);
>   struct vc4_exec_info *renderjob;
> @@ -679,6 +680,9 @@ vc4_queue_submit(struct drm_device *dev, struct 
> vc4_exec_info *exec,
>   fence->seqno = exec->seqno;
>   exec->fence = >base;
>  
> + if (out_sync)
> + drm_syncobj_replace_fence(out_sync, exec->fence);
> +
>   vc4_update_bo_seqnos(exec, seqno);
>  
>   vc4_unlock_bo_reservations(dev, exec, acquire_ctx);
> @@ -1114,6 +1118,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
>   struct vc4_dev *vc4 = to_vc4_dev(dev);
>   struct vc4_file *vc4file = file_priv->driver_priv;
>   struct drm_vc4_submit_cl *args = data;
> + struct drm_syncobj *out_sync = NULL;
>   struct vc4_exec_info *exec;
>   struct ww_acquire_ctx acquire_ctx;
>   struct dma_fence *in_fence;
> @@ -1123,11 +1128,17 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void 
> *data,
>VC4_SUBMIT_CL_FIXED_RCL_ORDER |
>VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
>VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y |
> -  VC4_SUBMIT_CL_IMPORT_SYNCOBJ)) != 0) {
> +  VC4_SUBMIT_CL_IMPORT_SYNCOBJ |
> +  VC4_SUBMIT_CL_EXPORT_SYNCOBJ)) != 0) {
>   DRM_DEBUG("Unknown flags: 0x%02x\n", args->flags);
>   return -EINVAL;
>   }
>  
> + if (args->pad2 != 0) {
> + DRM_DEBUG("->pad2 must be set to zero\n");
> + return -EINVAL;
> + }
> +
>   exec = kcalloc(1, sizeof(*exec), GFP_KERNEL);
>   if (!exec) {
>   DRM_ERROR("malloc failure on exec struct\n");
> @@ -1202,12 +1213,33 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void 
> *data,
>   if (ret)
>   goto fail;
>  
> + if (args->flags & VC4_SUBMIT_CL_EXPORT_SYNCOBJ) {
> + out_sync = drm_syncobj_find(file_priv, args->out_sync);
> + if (!out_sync) {
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + /* We replace the fence in out_sync in vc4_queue_submit since
> +  * the render job could execute immediately after that call.
> +  * If it finishes before our ioctl processing resumes the
> +  * render job fence could already have been freed.
> +  */
> + }

Same comment about not needing the exec flag.

> +
>   /* Clear this out of the struct we'll be putting in the queue,
>* since it's part of our stack.
>*/
>   exec->args = NULL;
>  
> - ret = vc4_queue_submit(dev, exec, _ctx);
> + ret = vc4_queue_submit(dev, exec, _ctx, out_sync);
> +
> + /* The syncobj isn't part of the exec data and we need to free our
> +  * reference even if job submission failed.
> +  */
> + if (out_sync)
> + drm_syncobj_put(out_sync);
> +
>   if (ret)
>   goto fail;
>  
> diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
> index 389f21931c25..3a2ef9b5b60b 100644
> --- a/include/uapi/drm/vc4_drm.h
> +++ b/include/uapi/drm/vc4_drm.h
> @@ -174,6 +174,7 @@ struct drm_vc4_submit_cl {
>  #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X (1 << 2)
>  #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y (1 << 3)
>  #define VC4_SUBMIT_CL_IMPORT_SYNCOBJ (1 << 4)
> +#define VC4_SUBMIT_CL_EXPORT_SYNCOBJ (1 << 5)
>   __u32 flags;
>  
>   /* Returned value of the seqno of this render job (for the
> @@ -189,6 +190,18 @@ struct drm_vc4_submit_cl {
>* syncobj is signalled.
>*/
>   __u32 in_sync;
> +
> + /* Syncobj handle to export fence to. Set together with EXPORT_SYNCOBJ
> +  * flag. If set, the fence in the syncobj will be replaced with a fence
> +  * that signals upon completion of this render job.
> +  */
> + __u32 out_sync;
> +
> + /* Unused field to align this struct on 64 bits. Must be set to 0.
> +  

Re: [PATCH 2/4] drm/vc4: Syncobj import support

[Eric Anholt]

Stefan Schake  writes:

> Allow userland to specify a syncobj that is waited on before a render job
> starts processing.
>
> Signed-off-by: Stefan Schake 
> ---
>  drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
>  drivers/gpu/drm/vc4/vc4_gem.c | 33 +++--
>  include/uapi/drm/vc4_drm.h|  9 +
>  3 files changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 4288615b66a2..3105df99cb12 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -10,6 +10,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +

Drop the extra \n?

>  #include "uapi/drm/vc4_drm.h"
>  
> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index 2107b0daf8ef..232363488125 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "uapi/drm/vc4_drm.h"
>  #include "vc4_drv.h"
> @@ -1115,21 +1116,18 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void 
> *data,
>   struct drm_vc4_submit_cl *args = data;
>   struct vc4_exec_info *exec;
>   struct ww_acquire_ctx acquire_ctx;
> + struct dma_fence *in_fence;
>   int ret = 0;
>  
>   if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
>VC4_SUBMIT_CL_FIXED_RCL_ORDER |
>VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
> -  VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y)) != 0) {
> +  VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y |
> +  VC4_SUBMIT_CL_IMPORT_SYNCOBJ)) != 0) {
>   DRM_DEBUG("Unknown flags: 0x%02x\n", args->flags);
>   return -EINVAL;
>   }
>  
> - if (args->pad2 != 0) {
> - DRM_DEBUG("->pad2 must be set to zero\n");
> - return -EINVAL;
> - }
> -
>   exec = kcalloc(1, sizeof(*exec), GFP_KERNEL);
>   if (!exec) {
>   DRM_ERROR("malloc failure on exec struct\n");
> @@ -1164,6 +1162,29 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
>   }
>   }
>  
> + if (args->flags & VC4_SUBMIT_CL_IMPORT_SYNCOBJ) {
> + ret = drm_syncobj_find_fence(file_priv, args->in_sync,
> +  _fence);
> + if (ret)
> + goto fail;
> +
> + /* When the fence (or fence array) is exclusively from our
> +  * context we can skip the wait since jobs are executed in
> +  * order of their submission through this ioctl and this can
> +  * only have fences from a prior job.
> +  */
> + if (!dma_fence_match_context(in_fence,
> +  vc4->dma_fence_context)) {
> + ret = dma_fence_wait(in_fence, true);
> + if (ret) {
> + dma_fence_put(in_fence);
> + goto fail;
> + }
> + }
> +
> + dma_fence_put(in_fence);
> + }

I don't think we need an extra flag here.  0 is an invalid syncobj
handle, so that could be the indication that there's no input syncobj.

Long term, we should probably only block once we're ready to exec the
job, not at submit time.  However, I think we can wait on fixing that
until we start using the GPU scheduler.


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

Re: [PATCH v4 1/2] drm/vc4: Add CTM support

[Eric Anholt]

Stefan Schake  writes:

> The hardware has a single block for applying a CTM prior to gamma lut.
> It can be fed with pixels from one of our CRTC at a time and uses a
> matrix with S0.9 scalars. Use private atomic state to reject attempts
> from userland to apply CTM for more than one CRTC at a time and reject
> matrices with scalars that we can't approximate without integer bits.

Looks good!  I think you got all the transition cases we were concerned
about before.

Reviewed and applied these two to drm-misc-next.  Thanks!


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

[Bug 106006] Kernel 4.16.0+ switch amdgpu.dc=1 causes screen brightness set to 1 to be dimmed by default

[bugzilla-daemon]

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

--- Comment #12 from Joel Sass  ---
Created attachment 139022
  --> https://bugs.freedesktop.org/attachment.cgi?id=139022=edit
I don't think this is the same file from 2.17. Sorry.

-- 
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 106006] Kernel 4.16.0+ switch amdgpu.dc=1 causes screen brightness set to 1 to be dimmed by default

[bugzilla-daemon]

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

--- Comment #11 from Joel Sass  ---
Okay, sadly, I wasn't clear about the kernel I was running. It's located here:
https://github.com/M-Bab/linux-kernel-amdgpu

and I installed the .deb created by the git contributor here:
https://github.com/M-Bab/linux-kernel-amdgpu-binaries

I downloaded the source listed in the first link I posted above, and it doesn't
appear to have the same file structure you'd listed in your patch.

I've attached amdgpu_dm_color.c to this bug.

If you don't want to patch for this, I understand. I can see if I can speak to
the person responsible for this repo.

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

Re: [PATCH v2] drm/vc4: Add support for plane alpha

[Eric Anholt]

Stefan Schake  writes:

> The HVS supports mixing fixed alpha with per-pixel alpha or
> setting a fixed plane alpha in case there is no per-pixel information.
> This allows us to support the generic DRM plane alpha property.
>
> Signed-off-by: Stefan Schake 

Applied to drm-misc-next.  Thanks!

> @@ -565,6 +567,13 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> SCALER_POS1_SCL_HEIGHT));
>   }
>  
> + /* Don't waste cycles mixing with plane alpha if the set alpha
> +  * is opaque or there is no per-pixel alpha information.
> +  * In any case we use the alpha property value as the fixed alpha.
> +  */
> + mix_plane_alpha = state->alpha != DRM_BLEND_ALPHA_OPAQUE &&
> +   fb->format->has_alpha;
> +
>   /* Position Word 2: Source Image Size, Alpha */
>   vc4_state->pos2_offset = vc4_state->dlist_count;
>   vc4_dlist_write(vc4_state,
> @@ -572,6 +581,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> SCALER_POS2_ALPHA_MODE_PIPELINE :
> SCALER_POS2_ALPHA_MODE_FIXED,
> SCALER_POS2_ALPHA_MODE) |
> + (mix_plane_alpha ? SCALER_POS2_ALPHA_MIX : 0) |
>   (fb->format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) 
> |
>   VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) |
>   VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT));

In an interesting note from the docs, if you'd set SCALER_POS2_ALPHA_MIX
with SCALER_POS2_ALPHA_MODE_FIXED, you'd get the fixed alpha squared!


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

Re: [PATCH 16/61] gpu: drm: vc4: simplify getting .drvdata

[Eric Anholt]

Wolfram Sang  writes:

> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang 

Applied to drm-misc-next.  Thanks!


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

Re: [PATCH v4 2/8] dt-bindings: display: atmel: optional video-interface of endpoints

[Boris Brezillon]

On Mon, 23 Apr 2018 09:22:55 +0200
Peter Rosin  wrote:

> With bus-type/bus-width properties in the endpoint nodes, the video-
> interface of the connection can be specified for cases where the
> heuristic fails to select the correct output mode. This can happen
> e.g. if not all RGB pins are routed on the PCB; the driver has no
> way of knowing this, and needs to be told explicitly.
> 
> This is critical for the devices that have the "conflicting output
> formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
> RGB bits move around depending on the selected output mode. For
> devices that do not have the "conflicting output formats" issue
> (SAMA5D2, SAMA5D4), this is completely irrelevant.
> 
> Signed-off-by: Peter Rosin 

Acked-by: Boris Brezillon 

> ---
>  .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 26 
> ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt 
> b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
> index 82f2acb3d374..9de434a8f523 100644
> --- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
> +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
> @@ -15,6 +15,14 @@ Required children nodes:
>   to external devices using the OF graph reprensentation (see ../graph.txt).
>   At least one port node is required.
>  
> +Optional properties in grandchild nodes:
> + Any endpoint grandchild node may specify a desired video interface
> + according to ../../media/video-interfaces.txt, specifically
> + - bus-type: must be <0>.
> + - bus-width: recognized values are <12>, <16>, <18> and <24>, and
> +   override any output mode selection heuristic, forcing "rgb444",
> +   "rgb565", "rgb666" and "rgb888" respectively.
> +
>  Example:
>  
>   hlcdc: hlcdc@f003 {
> @@ -50,3 +58,21 @@ Example:
>   #pwm-cells = <3>;
>   };
>   };
> +
> +
> +Example 2: With a video interface override to force rgb565; as above
> +but with these changes/additions:
> +
> +  {
> + hlcdc-display-controller {
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_base _lcd_rgb565>;
> +
> + port@0 {
> + hlcdc_panel_output: endpoint@0 {
> + bus-type = <0>;
> + bus-width = <16>;
> + };
> + };
> + };
> + };

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

Re: [PATCH v4 3/8] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes

[Boris Brezillon]

On Mon, 23 Apr 2018 09:22:56 +0200
Peter Rosin  wrote:

> This beats the heuristic that the connector is involved in what format
> should be output for cases where this fails.
> 
> E.g. if there is a bridge that changes format between the encoder and the
> connector, or if some of the RGB pins between the lcd controller and the
> encoder are not routed on the PCB.
> 
> This is critical for the devices that have the "conflicting output
> formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
> RGB bits move around depending on the selected output mode. For
> devices that do not have the "conflicting output formats" issue
> (SAMA5D2, SAMA5D4), this is completely irrelevant.
> 
> Signed-off-by: Peter Rosin 

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 70 
> +---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |  1 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 67 ---
>  3 files changed, 111 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index d73281095fac..c38a479ada98 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -226,6 +226,55 @@ static void atmel_hlcdc_crtc_atomic_enable(struct 
> drm_crtc *c,
>  #define ATMEL_HLCDC_RGB888_OUTPUTBIT(3)
>  #define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
>  
> +static int atmel_hlcdc_connector_output_mode(struct drm_connector_state 
> *state)
> +{
> + struct drm_connector *connector = state->connector;
> + struct drm_display_info *info = >display_info;
> + struct drm_encoder *encoder;
> + unsigned int supported_fmts = 0;
> + int j;
> +
> + encoder = state->best_encoder;
> + if (!encoder)
> + encoder = connector->encoder;
> +
> + switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) {
> + case 0:
> + break;
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + return ATMEL_HLCDC_RGB444_OUTPUT;
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + return ATMEL_HLCDC_RGB565_OUTPUT;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + return ATMEL_HLCDC_RGB666_OUTPUT;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + return ATMEL_HLCDC_RGB888_OUTPUT;
> + default:
> + return -EINVAL;
> + }
> +
> + for (j = 0; j < info->num_bus_formats; j++) {
> + switch (info->bus_formats[j]) {
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
> + break;
> + default:
> + break;
> + }
> + }
> +
> + return supported_fmts;
> +}
> +
>  static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
>  {
>   unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
> @@ -238,31 +287,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct 
> drm_crtc_state *state)
>   crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
>  
>   for_each_new_connector_in_state(state->state, connector, cstate, i) {
> - struct drm_display_info *info = >display_info;
>   unsigned int supported_fmts = 0;
> - int j;
>  
>   if (!cstate->crtc)
>   continue;
>  
> - for (j = 0; j < info->num_bus_formats; j++) {
> - switch (info->bus_formats[j]) {
> - case MEDIA_BUS_FMT_RGB444_1X12:
> - supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB565_1X16:
> - supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB666_1X18:
> - supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB888_1X24:
> - supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
> - break;
> - default:
> - break;
> - }
> - }
> + supported_fmts = atmel_hlcdc_connector_output_mode(cstate);
>  
>   if 

[Bug 106194] AMDGPU RIP: dm_update_crtcs_state on kernel 4.17rc2

[bugzilla-daemon]

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

Kevin McCormack  changed:

   What|Removed |Added

Summary|AMD Fury X system freeze on |AMDGPU RIP:
   |kernel 4.17rc2  |dm_update_crtcs_state on
   ||kernel 4.17rc2

-- 
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 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

--- Comment #22 from Kevin McCormack (wittyma...@yahoo.com) ---
Flickering seems to be gone on 4.17rc2!

However, there's a new issue :/
https://bugs.freedesktop.org/show_bug.cgi?id=106194

-- 
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 106194] AMD Fury X system freeze on kernel 4.17rc2

[bugzilla-daemon]

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

Bug ID: 106194
   Summary: AMD Fury X system freeze on kernel 4.17rc2
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: harlemsquir...@gmail.com

Created attachment 139018
  --> https://bugs.freedesktop.org/attachment.cgi?id=139018=edit
dmesg output running kernel 4.17-rc2

I left my computer on over night. After I noticed the system was frozen just
now, I rebooted to found these log entries.

5:06:46 AM
RIP: dm_update_crtcs_state+0x347/0x3c0 [amdgpu] RSP: b2560bc37b10

5:06:46 AM
kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4700!

Software versions:
  OpenGL version string: 3.0 Mesa 18.0.1


CPU hardware:
  x86_64
  AMD Ryzen 7 1800X Eight-Core Processor
Max Speed: 4100 MHz
Current Speed: 3600 MHz


Memory:
Speed: 3200 MT/s
  totalusedfree  shared  buff/cache   available
Mem:   15Gi   3.0Gi11Gi67Mi   1.5Gi12Gi
Swap: 7.8Gi  0B   7.8Gi


GPU hardware:
  OpenGL renderer string: AMD Radeon (TM) R9 Fury Series (FIJI / DRM 3.23.0 /
4.15.15-1-ARCH, LLVM 6.0.0)
  0b:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] [1002:7300] (rev c8)
0c:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] [1002:67df] (rev e7)


Motherboard:
  ASUSTeK COMPUTER INC.
  CROSSHAIR VI HERO
  BIOS Version: 3008


Storage:
Smart Log for NVME device:nvme0 namespace-id:

I've attached the relevent dmesg output.

-- 
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 v8 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

On Sat, 21 Apr 2018 09:08:45 +0200
Boris Brezillon  wrote:

> Add a driver for Cadence DPI -> DSI bridge.
> 
> This driver only support a subset of Cadence DSI bridge capabilities.
> 
> This driver has been tested/debugged in a simulated environment which
> explains why some of the features are missing.  Here is a
> non-exhaustive list of missing features:
>  * burst mode
>  * DPHY init/configuration steps
>  * support for additional input interfaces (SDI input)
> 
> DSI commands and non-burst video mode have been tested.
> 
> Signed-off-by: Boris Brezillon 
> Reviewed-by: Andrzej Hajda 
> Acked-by: Eric Anholt 
> Reviewed-by: Archit Taneja 

Applied both patches to drm-misc-next.

> ---
> Changes in v8:
> - Update my email address
> 
> Changes in v7:
> - Use DIV_ROUND_UP_ULL() to fix a build error on arm 32-bit
> - Add Archit's R-b
> 
> Changes in v6:
> - Use SPDX header
> - Do not enable the sys_clk in the probe function
> - Remove unneeded udelay()
> - Add a function to make sure the PLL and pixel clock are close enough
>   to be recoverable if they don't match exactly
> - Add the DPHY init sequence used in simulation (likely to be different
>   based on each SoC integration)
> 
> Changes in v5:
> - Add runtime PM support
> 
> Changes in v4:
> - Fix typos
> - Rename clks as suggested by Tomi
> - Fix DSI setup done in cdns_dsi_bridge_enable()
> - Add a precision about where this bridge is supposed to used to the
>   Kconfig entry
> - Let DRM_CDNS_DSI select DRM_PANEL_BRIDGE
> - Remove the IP version from the DT compatible name
> - Adapt register the layout to match the one used in the last revision
>   of the IP (hopefully the final version)
> 
> Changes in v3:
> - replace magic values by real timing calculation. The DPHY PLL clock
>   is still hardcoded since we don't have a working DPHY block yet, and
>   this is the piece of HW we need to dynamically configure the PLL
>   rate based on the display refresh rate and the resolution.
> - parse DSI devices represented with the OF-graph. This is needed to
>   support DSI devices controlled through an external bus like I2C or
>   SPI.
> - use the DRM panel-bridge infrastructure to simplify the DRM panel
>   logic
> 
> Changes in v2:
> - rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
> - return the correct error when devm_clk_get(sysclk) fails
> - add missing depends on OF and select DRM_PANEL in the Kconfig entry
> 
> DSI runtime PM
> ---
>  drivers/gpu/drm/bridge/Kconfig|   10 +
>  drivers/gpu/drm/bridge/Makefile   |1 +
>  drivers/gpu/drm/bridge/cdns-dsi.c | 1623 
> +
>  3 files changed, 1634 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 42c9c2d13752..1d75d3a1f951 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -25,6 +25,16 @@ config DRM_ANALOGIX_ANX78XX
> the HDMI output of an application processor to MyDP
> or DisplayPort.
>  
> +config DRM_CDNS_DSI
> + tristate "Cadence DPI/DSI bridge"
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL_BRIDGE
> + depends on OF
> + help
> +   Support Cadence DPI to DSI bridge. This is an internal
> +   bridge and is meant to be directly embedded in a SoC.
> +
>  config DRM_DUMB_VGA_DAC
>   tristate "Dumb VGA DAC Bridge support"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index fd90b16a65c0..35f88d48ec20 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> +obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
>  obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
>  obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
>  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> megachips-stdp-ge-b850v3-fw.o
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> new file mode 100644
> index ..c255fc3e1be5
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -0,0 +1,1623 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright: 2017 Cadence Design Systems, Inc.
> + *
> + * Author: Boris Brezillon 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IP_CONF  0x0
> +#define SP_HS_FIFO_DEPTH(x)  (((x) & GENMASK(30, 26)) >> 26)
> +#define SP_LP_FIFO_DEPTH(x)  (((x) & GENMASK(25, 21)) >> 21)
> +#define VRS_FIFO_DEPTH(x)(((x) & 

[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

--- Comment #9 from François Jacques  ---
Created attachment 139017
  --> https://bugs.freedesktop.org/attachment.cgi?id=139017=edit
dmesg with 4.16.3

backtrace disappears in 4.16.3, still no image.

-- 
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 106191] FirePro v8800 Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

--- Comment #8 from François Jacques  ---
Thank you so much Alex to help out on this! I'll generate another dmesg dump
with 4.16.3

-- 
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 106191] FirePro v8800 Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

--- Comment #7 from François Jacques  ---
Created attachment 139014
  --> https://bugs.freedesktop.org/attachment.cgi?id=139014=edit
dmesg with 4.16.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 106188] Can't successfully set pstates in pp_od_clk_voltage

[bugzilla-daemon]

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

--- Comment #3 from tempel.jul...@gmail.com ---
I figured out that the cause of the described behavior is that it doesn't allow
me to really increase the GPU clock.
So I can set "echo "s 7 1194 900" >
/sys/class/drm/card0/device/pp_od_clk_voltage" and it works correctly.
But when I set e.g. "echo "s 7 1199 900" >
/sys/class/drm/card0/device/pp_od_clk_voltage", the clock doesn't get over
pstate 6.

Is this restriction by purpose? It's not there with Wattman on Windows.

-- 
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] drm/tinydrm/mi0283qt: Always set rotation value

[Tom Callaway]

The PiTFT (ili9340) has a hardware reset circuit that resets only
on power-on and not on each reboot through a gpio like the
rpi-display does. As a result, we need to always apply the
rotation value regardless of the display "on/off" state.
Moved the rotation setting code below out_enable:.

Signed-off-by: Tom Callaway 
---
 drivers/gpu/drm/tinydrm/mi0283qt.c | 41 +-
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 4e6d2ee94e55..2bb9e3ce4823 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -84,24 +84,6 @@ static void mi0283qt_enable(struct drm_simple_display_pipe 
*pipe,
/* Memory Access Control */
mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT, 
MIPI_DCS_PIXEL_FMT_16BIT);
 
-   switch (mipi->rotation) {
-   default:
-   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
-   ILI9341_MADCTL_MX;
-   break;
-   case 90:
-   addr_mode = ILI9341_MADCTL_MY;
-   break;
-   case 180:
-   addr_mode = ILI9341_MADCTL_MV;
-   break;
-   case 270:
-   addr_mode = ILI9341_MADCTL_MX;
-   break;
-   }
-   addr_mode |= ILI9341_MADCTL_BGR;
-   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
-
/* Frame Rate */
mipi_dbi_command(mipi, ILI9341_FRMCTR1, 0x00, 0x1b);
 
@@ -127,6 +109,29 @@ static void mi0283qt_enable(struct drm_simple_display_pipe 
*pipe,
msleep(100);
 
 out_enable:
+   /* The PiTFT (ili9340) has a hardware reset circuit that
+* resets only on power-on and not on each reboot through
+* a gpio like the rpi-display does.
+* As a result, we need to always apply the rotation value
+* regardless of the display "on/off" state.
+*/
+   switch (mipi->rotation) {
+   default:
+   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
+   ILI9341_MADCTL_MX;
+   break;
+   case 90:
+   addr_mode = ILI9341_MADCTL_MY;
+   break;
+   case 180:
+   addr_mode = ILI9341_MADCTL_MV;
+   break;
+   case 270:
+   addr_mode = ILI9341_MADCTL_MX;
+   break;
+   }
+   addr_mode |= ILI9341_MADCTL_BGR;
+   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
 }
 
-- 
2.14.3

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

[v2 10/10] MAINTAINERS: update Mediatek Soc entry

[matthias . bgg]

From: Matthias Brugger 

Mediatek SoCs include several soc specific drivers as well
as a mfd device. Add these to the maintainers file.

Signed-off-by: Matthias Brugger 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d5a621..74f7ea345096 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1621,6 +1621,8 @@ F:arch/arm/boot/dts/mt7*
 F: arch/arm/boot/dts/mt8*
 F: arch/arm/mach-mediatek/
 F: arch/arm64/boot/dts/mediatek/
+F: drivers/soc/mediatek/
+F: drivers/mfd/mtk-mmsys.c
 N: mtk
 K: mediatek
 
-- 
2.16.3

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

[v2 07/10] drm/mediatek: Add mfd support for mt8173

[matthias . bgg]

From: Matthias Brugger 

Use the MFD device for SoC mt8173. Probing via devicetree
is no longer needed for any SoC, so delete it.

Signed-off-by: Matthias Brugger 
Reviewed-by: Philipp Zabel 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 +++-
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 88ee35907744..3cc433ebfa8f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -399,20 +399,12 @@ static int mtk_drm_probe(struct platform_device *pdev)
INIT_WORK(>commit.work, mtk_atomic_work);
private->data = of_device_get_match_data(dev);
 
-   /* Check if called from mfd */
-   if (!dev->of_node) {
-   mmsys_node = pdev->dev.parent->of_node;
-   private->data = (struct mtk_mmsys_driver_data *)
-   platform_get_device_id(pdev)->driver_data;
-   private->config_regs =
-   syscon_node_to_regmap(mmsys_node);
-   parent_node = mmsys_node->parent;
-   } else {
-   private->config_regs = syscon_node_to_regmap(dev->of_node);
-   if (IS_ERR(private->config_regs))
-   return PTR_ERR(private->config_regs);
-   parent_node = dev->of_node->parent;
-   }
+   mmsys_node = pdev->dev.parent->of_node;
+   private->data = (struct mtk_mmsys_driver_data *)
+   platform_get_device_id(pdev)->driver_data;
+   private->config_regs =
+   syscon_node_to_regmap(mmsys_node);
+   parent_node = mmsys_node->parent;
 
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(parent_node, node) {
@@ -555,14 +547,9 @@ static int mtk_drm_sys_resume(struct device *dev)
 static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
 mtk_drm_sys_resume);
 
-static const struct of_device_id mtk_drm_of_ids[] = {
-   { .compatible = "mediatek,mt8173-mmsys",
- .data = _mmsys_driver_data},
-   { }
-};
-
 static const struct platform_device_id mtk_drm_ids[] = {
{ "drm-mt2701-mm", (kernel_ulong_t)_mmsys_driver_data },
+   { "drm-mt8173-mm", (kernel_ulong_t)_mmsys_driver_data },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(platform, mtk_drm_ids);
@@ -572,7 +559,6 @@ static struct platform_driver mtk_drm_platform_driver = {
.remove = mtk_drm_remove,
.driver = {
.name   = "mediatek-drm",
-   .of_match_table = mtk_drm_of_ids,
.pm = _drm_pm_ops,
},
.id_table = mtk_drm_ids,
-- 
2.16.3

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

[v2 08/10] clk: mediatek: mt8173-mm: switch to mfd device

[matthias . bgg]

From: Matthias Brugger 

As the new mfd device is in place, switch probing
for the MMSYS to support invocation from the mfd device.

Signed-off-by: Matthias Brugger 
Acked-by: Stephen Boyd 
---
 drivers/clk/mediatek/clk-mt8173.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 96c292c3e440..abd2592078d4 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "clk-mtk.h"
 #include "clk-gate.h"
@@ -1152,10 +1153,13 @@ static void __init mtk_imgsys_init(struct device_node 
*node)
 }
 CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt8173-imgsys", mtk_imgsys_init);
 
-static void __init mtk_mmsys_init(struct device_node *node)
+static int mtk_mmsys_probe(struct platform_device *pdev)
 {
struct clk_onecell_data *clk_data;
int r;
+   struct device_node *node;
+
+   node = pdev->dev.parent->of_node;
 
clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
 
@@ -1166,8 +1170,17 @@ static void __init mtk_mmsys_init(struct device_node 
*node)
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+   return r;
 }
-CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt8173-mmsys", mtk_mmsys_init);
+
+static struct platform_driver clk_mt8173_mm_drv = {
+   .probe = mtk_mmsys_probe,
+   .driver = {
+   .name = "clk-mt8173-mm",
+   },
+};
+builtin_platform_driver(clk_mt8173_mm_drv);
 
 static void __init mtk_vdecsys_init(struct device_node *node)
 {
-- 
2.16.3

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

[v2 09/10] drm: mediatek: Omit warning on probe defers

[matthias . bgg]

From: Matthias Brugger 

When probe through the MFD, it can happen that the
clock drivers wasn't probed before the ddp driver gets
invoked. The driver used to omit a warning that the driver
failed to get the clocks. Omit this error on the defered probe path.

Signed-off-by: Matthias Brugger 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index bafc5c77c4fb..6b399348a2dc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -374,7 +374,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
 
ddp->clk = devm_clk_get(dev, NULL);
if (IS_ERR(ddp->clk)) {
-   dev_err(dev, "Failed to get clock\n");
+   if (PTR_ERR(ddp->clk) != -EPROBE_DEFER)
+   dev_err(dev, "Failed to get clock\n");
return PTR_ERR(ddp->clk);
}
 
-- 
2.16.3

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

[v2 06/10] mfd: mtk-mmsys: Add mt8173 nodes

[matthias . bgg]

From: Matthias Brugger 

Add devices for the mt8173 SoC.

Signed-off-by: Matthias Brugger 
Reviewed-by: Philipp Zabel 
---
 drivers/mfd/mtk-mmsys.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c
index c802343fb1c6..5585a561a02f 100644
--- a/drivers/mfd/mtk-mmsys.c
+++ b/drivers/mfd/mtk-mmsys.c
@@ -19,6 +19,7 @@
 
 enum {
MMSYS_MT2701 = 1,
+   MMSYS_MT8173,
 };
 
 static const struct mfd_cell mmsys_mt2701_devs[] = {
@@ -26,6 +27,12 @@ static const struct mfd_cell mmsys_mt2701_devs[] = {
{ .name = "drm-mt2701-mm", },
 };
 
+static const struct mfd_cell mmsys_mt8173_devs[] = {
+   { .name = "clk-mt8173-mm", },
+   { .name = "drm-mt8173-mm", },
+};
+
+
 static int mmsys_probe(struct platform_device *pdev)
 {
const struct mfd_cell *mmsys_cells;
@@ -44,6 +51,10 @@ static int mmsys_probe(struct platform_device *pdev)
mmsys_cells = mmsys_mt2701_devs;
nr_cells = ARRAY_SIZE(mmsys_mt2701_devs);
break;
+   case MMSYS_MT8173:
+   mmsys_cells = mmsys_mt8173_devs;
+   nr_cells = ARRAY_SIZE(mmsys_mt8173_devs);
+   break;
default:
return -ENODEV;
}
@@ -62,6 +73,9 @@ static const struct of_device_id of_match_mmsys[] = {
{ .compatible = "mediatek,mt2701-mmsys",
  .data = (void *) MMSYS_MT2701,
},
+   { .compatible = "mediatek,mt8173-mmsys",
+ .data = (void *) MMSYS_MT8173,
+   },
{ /* sentinel */ },
 };
 
-- 
2.16.3

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

[v2 05/10] clk: mediatek: mt2701-mm: switch to mfd device

[matthias . bgg]

From: Matthias Brugger 

As the new mfd device is in place, switch probing
for the MMSYS to support invocation from the mfd device.

Signed-off-by: Matthias Brugger 
Acked-by: Stephen Boyd 
---
 drivers/clk/mediatek/clk-mt2701-mm.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt2701-mm.c 
b/drivers/clk/mediatek/clk-mt2701-mm.c
index fe1f85072fc5..4517525887dd 100644
--- a/drivers/clk/mediatek/clk-mt2701-mm.c
+++ b/drivers/clk/mediatek/clk-mt2701-mm.c
@@ -87,16 +87,13 @@ static const struct mtk_gate mm_clks[] = {
GATE_DISP1(CLK_MM_TVE_FMM, "mm_tve_fmm", "mm_sel", 14),
 };
 
-static const struct of_device_id of_match_clk_mt2701_mm[] = {
-   { .compatible = "mediatek,mt2701-mmsys", },
-   {}
-};
-
 static int clk_mt2701_mm_probe(struct platform_device *pdev)
 {
struct clk_onecell_data *clk_data;
int r;
-   struct device_node *node = pdev->dev.of_node;
+   struct device_node *node;
+
+   node = pdev->dev.parent->of_node;
 
clk_data = mtk_alloc_clk_data(CLK_MM_NR);
 
@@ -116,7 +113,6 @@ static struct platform_driver clk_mt2701_mm_drv = {
.probe = clk_mt2701_mm_probe,
.driver = {
.name = "clk-mt2701-mm",
-   .of_match_table = of_match_clk_mt2701_mm,
},
 };
 
-- 
2.16.3

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

[v2 01/10] dt-bindings: mediatek: mmsys: Add support for mfd

[matthias . bgg]

From: Matthias Brugger 

Add binding description for the mmsys mfd for some Mediatek
devices. mmsys has some registers to control clock gates (which is
used in the clk driver) and some registers to set the routing and enable
the differnet blocks of the display subsystem.

Signed-off-by: Matthias Brugger 
---
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |  2 --
 .../bindings/display/mediatek/mediatek,disp.txt|  2 +-
 .../devicetree/bindings/mfd/mediatek,mmsys.txt | 27 ++
 3 files changed, 28 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index 4eb8bbe15c01..4468345f8b1a 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -6,10 +6,8 @@ The Mediatek mmsys controller provides various clocks to the 
system.
 Required Properties:
 
 - compatible: Should be one of:
-   - "mediatek,mt2701-mmsys", "syscon"
- "mediatek,mt2712-mmsys", "syscon"
- "mediatek,mt6797-mmsys", "syscon"
-   - "mediatek,mt8173-mmsys", "syscon"
 - #clock-cells: Must be 1
 
 The mmsys controller uses the common clk binding from
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 383183a89164..85a3b4ec06cd 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -9,7 +9,7 @@ function block.
 
 All DISP device tree nodes must be siblings to the central MMSYS_CONFIG node.
 For a description of the MMSYS_CONFIG binding, see
-Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt.
+Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt
 
 DISP function blocks
 
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt 
b/Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt
new file mode 100644
index ..2331ae16917e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt
@@ -0,0 +1,27 @@
+MediaTek MMSYS Multifunction Device Driver
+
+MMSYS is a multifunction device with the following sub modules:
+- clocks for the multi-media subsystem
+- central node for the DRM subsystem.
+
+This document describes the binding for MFD device. The MFD takes care to 
initailize
+the clock driver and the DRM driver. More info see
+Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+
+Required properties:
+- compatible: Should be one of:
+   - "mediatek,mt2701-mmsys", "syscon"
+   - "mediatek,mt8173-mmsys", "syscon"
+- #clock-cells: Must be 1
+
+Optional properties:
+- power-domains: list of powerdomains needed for the subsystem to work
+
+Example:
+
+mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   power-domains = < MT8173_POWER_DOMAIN_MM>;
+   #clock-cells = <1>;
+};
-- 
2.16.3

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

[v2 03/10] mfd: mtk-mmsys: Add mmsys driver

[matthias . bgg]

From: Matthias Brugger 

The MMSYS subsystem includes clocks and drm components.
This patch adds a MFD device to probe both drivers from the same
device tree compatible.

Signed-off-by: Matthias Brugger 
---
 drivers/mfd/Kconfig |  9 ++
 drivers/mfd/Makefile|  2 ++
 drivers/mfd/mtk-mmsys.c | 79 +
 3 files changed, 90 insertions(+)
 create mode 100644 drivers/mfd/mtk-mmsys.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..a2c928e26026 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -378,6 +378,15 @@ config MFD_MC13XXX_I2C
help
  Select this if your MC13xxx is connected via an I2C bus.
 
+config MFD_MEDIATEK_MMSYS
+   tristate "Mediatek MMSYS interface"
+   select MDF_CORE
+   select REGMAP_MMIO
+   help
+ Select this if you have a MMSYS subsystem in your SoC. The
+ MMSYS subsystem has at least a clock driver part and some
+ DRM components.
+
 config MFD_MXS_LRADC
tristate "Freescale i.MX23/i.MX28 LRADC"
depends on ARCH_MXS || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d9d2cf0d32ef..b96118bd68d9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -98,6 +98,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
 obj-$(CONFIG_MFD_MC13XXX_SPI)  += mc13xxx-spi.o
 obj-$(CONFIG_MFD_MC13XXX_I2C)  += mc13xxx-i2c.o
 
+obj-$(CONFIG_MFD_MEDIATEK_MMSYS) += mtk-mmsys.o
+
 obj-$(CONFIG_MFD_CORE) += mfd-core.o
 
 obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c
new file mode 100644
index ..c802343fb1c6
--- /dev/null
+++ b/drivers/mfd/mtk-mmsys.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * mtk-mmsys.c -- Mediatek MMSYS multi-function driver
+ *
+ * Copyright (c) 2018 Matthias Brugger 
+ *
+ * Author: Matthias Brugger 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum {
+   MMSYS_MT2701 = 1,
+};
+
+static const struct mfd_cell mmsys_mt2701_devs[] = {
+   { .name = "clk-mt2701-mm", },
+   { .name = "drm-mt2701-mm", },
+};
+
+static int mmsys_probe(struct platform_device *pdev)
+{
+   const struct mfd_cell *mmsys_cells;
+   int nr_cells;
+   long id;
+   int ret;
+
+   id = (long) of_device_get_match_data(>dev);
+   if (!id) {
+   dev_err(>dev, "of_device_get match_data() failed\n");
+   return -EINVAL;
+   }
+
+   switch (id) {
+   case MMSYS_MT2701:
+   mmsys_cells = mmsys_mt2701_devs;
+   nr_cells = ARRAY_SIZE(mmsys_mt2701_devs);
+   break;
+   default:
+   return -ENODEV;
+   }
+
+   ret = devm_mfd_add_devices(>dev, 0, mmsys_cells, nr_cells,
+   NULL, 0, NULL);
+   if (ret) {
+   dev_err(>dev, "failed to add MFD devices %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+};
+
+static const struct of_device_id of_match_mmsys[] = {
+   { .compatible = "mediatek,mt2701-mmsys",
+ .data = (void *) MMSYS_MT2701,
+   },
+   { /* sentinel */ },
+};
+
+static struct platform_driver mmsys_drv = {
+   .probe = mmsys_probe,
+   .driver = {
+   .name = "mediatek-mmysys",
+   .of_match_table = of_match_ptr(of_match_mmsys),
+   },
+};
+
+builtin_platform_driver(mmsys_drv);
+
+MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver");
+MODULE_LICENSE("GPL");
-- 
2.16.3

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

[v2 04/10] drm/mediatek: mt2701: switch to mfd probing.

[matthias . bgg]

From: Matthias Brugger 

With the mtk-mmsys MFD device in place, we switch the probing for
mt2701 from device-tree to mfd.

Signed-off-by: Matthias Brugger 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a48e28adad09..88ee35907744 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -386,7 +386,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct mtk_drm_private *private;
-   struct device_node *node;
+   struct device_node *node, *parent_node, *mmsys_node;
struct component_match *match = NULL;
int ret;
int i;
@@ -399,12 +399,23 @@ static int mtk_drm_probe(struct platform_device *pdev)
INIT_WORK(>commit.work, mtk_atomic_work);
private->data = of_device_get_match_data(dev);
 
-   private->config_regs = syscon_node_to_regmap(dev->of_node);
-   if (IS_ERR(private->config_regs))
-   return PTR_ERR(private->config_regs);
+   /* Check if called from mfd */
+   if (!dev->of_node) {
+   mmsys_node = pdev->dev.parent->of_node;
+   private->data = (struct mtk_mmsys_driver_data *)
+   platform_get_device_id(pdev)->driver_data;
+   private->config_regs =
+   syscon_node_to_regmap(mmsys_node);
+   parent_node = mmsys_node->parent;
+   } else {
+   private->config_regs = syscon_node_to_regmap(dev->of_node);
+   if (IS_ERR(private->config_regs))
+   return PTR_ERR(private->config_regs);
+   parent_node = dev->of_node->parent;
+   }
 
/* Iterate over sibling DISP function blocks */
-   for_each_child_of_node(dev->of_node->parent, node) {
+   for_each_child_of_node(parent_node, node) {
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -545,13 +556,17 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, 
mtk_drm_sys_suspend,
 mtk_drm_sys_resume);
 
 static const struct of_device_id mtk_drm_of_ids[] = {
-   { .compatible = "mediatek,mt2701-mmsys",
- .data = _mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
  .data = _mmsys_driver_data},
{ }
 };
 
+static const struct platform_device_id mtk_drm_ids[] = {
+   { "drm-mt2701-mm", (kernel_ulong_t)_mmsys_driver_data },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mtk_drm_ids);
+
 static struct platform_driver mtk_drm_platform_driver = {
.probe  = mtk_drm_probe,
.remove = mtk_drm_remove,
@@ -560,6 +575,7 @@ static struct platform_driver mtk_drm_platform_driver = {
.of_match_table = mtk_drm_of_ids,
.pm = _drm_pm_ops,
},
+   .id_table = mtk_drm_ids,
 };
 
 static struct platform_driver * const mtk_drm_drivers[] = {
-- 
2.16.3

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

[v2 02/10] drm/mediatek: Use regmap for register access

[matthias . bgg]

From: Matthias Brugger 

The mmsys memory space is shared between the drm and the
clk driver. Use regmap to access it.

Signed-off-by: Matthias Brugger 
Reviewed-by: Philipp Zabel 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 38 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 13 ---
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  2 +-
 5 files changed, 24 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 658b8dd45b83..4c65873b4867 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -33,7 +33,7 @@
  * @enabled: records whether crtc_enable succeeded
  * @planes: array of 4 drm_plane structures, one for each overlay plane
  * @pending_planes: whether any plane has pending changes to be applied
- * @config_regs: memory mapped mmsys configuration register space
+ * @config_regs: regmap mapped mmsys configuration register space
  * @mutex: handle to one of the ten disp_mutex streams
  * @ddp_comp_nr: number of components in ddp_comp
  * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
@@ -48,7 +48,7 @@ struct mtk_drm_crtc {
struct drm_planeplanes[OVL_LAYER_NR];
boolpending_planes;
 
-   void __iomem*config_regs;
+   struct regmap   *config_regs;
struct mtk_disp_mutex   *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..bafc5c77c4fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -185,53 +185,45 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
cur,
return value;
 }
 
-static void mtk_ddp_sout_sel(void __iomem *config_regs,
+static void mtk_ddp_sout_sel(struct regmap *config_regs,
 enum mtk_ddp_comp_id cur,
 enum mtk_ddp_comp_id next)
 {
if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
-   writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
-  config_regs + DISP_REG_CONFIG_OUT_SEL);
+   regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
+   BLS_TO_DSI_RDMA1_TO_DPI1);
 }
 
-void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
+void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
  enum mtk_ddp_comp_id cur,
  enum mtk_ddp_comp_id next)
 {
-   unsigned int addr, value, reg;
+   unsigned int addr, value;
 
value = mtk_ddp_mout_en(cur, next, );
-   if (value) {
-   reg = readl_relaxed(config_regs + addr) | value;
-   writel_relaxed(reg, config_regs + addr);
-   }
+   if (value)
+   regmap_update_bits(config_regs, addr, value, value);
 
mtk_ddp_sout_sel(config_regs, cur, next);
 
value = mtk_ddp_sel_in(cur, next, );
-   if (value) {
-   reg = readl_relaxed(config_regs + addr) | value;
-   writel_relaxed(reg, config_regs + addr);
-   }
+   if (value)
+   regmap_update_bits(config_regs, addr, value, value);
 }
 
-void mtk_ddp_remove_comp_from_path(void __iomem *config_regs,
+void mtk_ddp_remove_comp_from_path(struct regmap *config_regs,
   enum mtk_ddp_comp_id cur,
   enum mtk_ddp_comp_id next)
 {
-   unsigned int addr, value, reg;
+   unsigned int addr, value;
 
value = mtk_ddp_mout_en(cur, next, );
-   if (value) {
-   reg = readl_relaxed(config_regs + addr) & ~value;
-   writel_relaxed(reg, config_regs + addr);
-   }
+   if (value)
+   regmap_update_bits(config_regs, addr, value, 0);
 
value = mtk_ddp_sel_in(cur, next, );
-   if (value) {
-   reg = readl_relaxed(config_regs + addr) & ~value;
-   writel_relaxed(reg, config_regs + addr);
-   }
+   if (value)
+   regmap_update_bits(config_regs, addr, value, 0);
 }
 
 struct mtk_disp_mutex *mtk_disp_mutex_get(struct device *dev, unsigned int id)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
index f9a799168077..32e12f33b76a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
@@ -20,10 +20,10 @@ struct regmap;
 struct device;
 struct mtk_disp_mutex;
 
-void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
+void mtk_ddp_add_comp_to_path(struct regmap 

[v2 00/10] arm/arm64: mediatek: Fix mmsys device probing

[matthias . bgg]

From: Matthias Brugger 

Changes since v1:
- add binding documentation
- ddp: use regmap_update_bits
- ddp: ignore EPROBE_DEFER on clock probing
- mfd: delete mmsys_private
- add Reviewed-by and Acked-by tags

---

MMSYS in Mediatek SoCs has some registers to control clock gates (which is 
used in the clk driver) and some registers to set the routing and enable
the differnet blocks of the display subsystem.

Up to now both drivers, clock and drm are probed with the same device tree
compatible. But only the first driver get probed, which in effect breaks
graphics on mt8173 and mt2701.

This patch set introduces a new mfd device, which binds against the mmsys
compatible and takes care of probing the needed devices. It was tested on the
bananapi-r2 and the Acer R13 Chromebook.


Matthias Brugger (10):
  dt-bindings: mediatek: mmsys: Add support for mfd
  drm/mediatek: Use regmap for register access
  mfd: mtk-mmsys: Add mmsys driver
  drm/mediatek: mt2701: switch to mfd probing.
  clk: mediatek: mt2701-mm: switch to mfd device
  mfd: mtk-mmsys: Add mt8173 nodes
  drm/mediatek: Add mfd support for mt8173
  clk: mediatek: mt8173-mm: switch to mfd device
  drm: mediatek: Omit warning on probe defers
  MAINTAINERS: update Mediatek Soc entry

 .../bindings/arm/mediatek/mediatek,mmsys.txt   |  2 -
 .../bindings/display/mediatek/mediatek,disp.txt|  2 +-
 .../devicetree/bindings/mfd/mediatek,mmsys.txt | 27 +++
 MAINTAINERS|  2 +
 drivers/clk/mediatek/clk-mt2701-mm.c   | 10 +--
 drivers/clk/mediatek/clk-mt8173.c  | 17 +++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 41 --
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h |  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 33 
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |  2 +-
 drivers/mfd/Kconfig|  9 +++
 drivers/mfd/Makefile   |  2 +
 drivers/mfd/mtk-mmsys.c| 93 ++
 14 files changed, 189 insertions(+), 59 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt
 create mode 100644 drivers/mfd/mtk-mmsys.c

-- 
2.16.3

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

[Bug 106188] Can't successfully set pstates in pp_od_clk_voltage

[bugzilla-daemon]

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

--- Comment #2 from tempel.jul...@gmail.com ---
Thanks for your response.

I somehow forgot the missing ">", whoops. I now almost got it working like
desired, thanks!

However, there is a small problem left: It doesn't switch into pstate 7.
I set up:
echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level

echo "s 0 214 721" > /sys/class/drm/card0/device/pp_od_clk_voltage
echo "s 1 389 721" > /sys/class/drm/card0/device/pp_od_clk_voltage
echo "s 2 844 725" > /sys/class/drm/card0/device/pp_od_clk_voltage
echo "s 3 1009 818" > /sys/class/drm/card0/device/pp_od_clk_voltage
echo "s 4 1079 875" > /sys/class/drm/card0/device/pp_od_clk_voltage
echo "s 5 1134 880" > /sys/class/drm/card0/device/pp_od_clk_voltage
echo "s 6 1179 890" > /sys/class/drm/card0/device/pp_od_clk_voltage
echo "s 7 1209 900" > /sys/class/drm/card0/device/pp_od_clk_voltage

echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage

But according to /sys/kernel/debug/dri/0/amdgpu_pm_info, pstate 6 (1179 890) is
the maximum of chosen clocks.
I set up Unigine Valley to run in 720p with 8xMSAA, so there is no high power
consumption which could make the GPU throttle down to a lower state, so it
definitely should switch to pstate 7.

I also tried making s 7 and s 6 the same, but then it's just limited to an even
lower pstate. So I fail to get to my desired 1209MHz 900mV.

It also seems like setting up power_dpm_force_performance_level to manual isn't
actually required, at least it doesn't make any difference here (or I'm missing
something).


Btw: Since I'm already bugging you with this :) :
Is there a way to also increase the maximum allowed power consumption?
There are /sys/class/drm/card0/device/hwmon/hwmon0/power1_cap and
/sys/class/drm/card0/device/hwmon/hwmon0/power1_cap_max containing the maximum
ASIC power (at least it looks to me that way), but I haven't been able to
successfully alter those to e.g. raise the limit of my Baffin GPU to 60 Watts.

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

Re: [PATCH v2 6/8] drm/arm/malidp: Enable/disable the scaling engine interrupts with memory writeback

[Liviu Dudau]

On Mon, Apr 23, 2018 at 03:50:49PM +0100, Ayan Kumar Halder wrote:
> Scaling engine interrupts need to be enabled/disabled as and when memwrite
> is enabled and disabled. The reason being scaling engine interrupts are
> used only by the memory writeout layer.
> 
> This patch depends on:
> https://lkml.org/lkml/2017/5/15/695
> 
> Signed-off-by: Ayan Kumar Halder 
> 
> ---
> Changes in v2:-
> - Removed the change id and modified the commit message
> ---
>  drivers/gpu/drm/arm/malidp_hw.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index f5633bc..90d76e4 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -621,12 +621,14 @@ static int malidp550_enable_memwrite(struct 
> malidp_hw_device *hwdev,
>   malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | 
> MALIDP_SE_MEMWRITE_EN,
> MALIDP550_SE_CONTROL);
>  
> + malidp_se_irq_hw_init(hwdev);
>   return 0;
>  }
>  
>  static void malidp550_disable_memwrite(struct malidp_hw_device *hwdev)
>  {
>   u32 base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
> + malidp_se_irq_fini(hwdev);
>   malidp_hw_clearbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | 
> MALIDP_SE_MEMWRITE_EN,
>   MALIDP550_SE_CONTROL);
>   malidp_hw_clearbits(hwdev, MALIDP_SCALE_ENGINE_EN, base + 
> MALIDP_DE_DISPLAY_FUNC);

We now know that this patch is broken, because it disables interrupts
for the writeback after a previous commit has enabled them but before
the writeback engine has finished writing, so the better place for
enabling and disabling the SE IRQs is in the malidp_pm_{suspend,resume}
functions, not here.

Only for this patch: NACK.

Best regards,
Liviu

> -- 
> 2.7.4
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106188] Can't successfully set pstates in pp_od_clk_voltage

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
(In reply to tempel.julian from comment #0)
> Hello,
> I specified "amdgpu.ppfeaturemask=0x" as a boot parameter so I could
> access "/sys/class/drm/card0/device/pp_od_clk_voltage".
> The pstate table for source and memory clocks looks correct.
> 
> When I run "echo "s 7 1209 900"
> /sys/class/drm/card0/device/pp_od_clk_voltage", it returns "s 7 1209 900
> /sys/class/drm/card0/device/pp_od_clk_voltage".
> When I run "echo "c" /sys/class/drm/card0/device/pp_od_clk_voltage"
> afterwards, it returns "c /sys/class/drm/card0/device/pp_od_clk_voltage".
> 

Are you redirecting to the file? Something like the following should work:
echo "s 7 1209 900" > /sys/class/drm/card0/device/pp_od_clk_voltage


> However, the change is not applied. When I do "cat
> /sys/class/drm/card0/device/pp_od_clk_voltage", it still says "7:  
> 1196Mhz   1006 mV".
> And when I run "watch -n 0.5  cat /sys/kernel/debug/dri/0/amdgpu_pm_info",
> it reports
> "   1196 MHz (SCLK)
> 981 mV (VDDGFX)
> ".
> 
> Am I making a mistake somewhere or should it work like this?
> 
> I also tried "echo "manual" >
> /sys/class/drm/card0/device/power_dpm_force_performance_level" and setting
> pstates 5-7, but that didn't help either.

You have to set manual mode before you can manually edit the state.  You also
have to be root (or have permission) to write to these files.

> In the documentation, I read that pp_od_clk_voltage should also include
> OD_range, but it's not there for me.

The patch is on the mailing list, but hasn't been committed yet.
https://patchwork.freedesktop.org/patch/217812/

-- 
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 v2 8/8] drm/arm/malidp: Added the late system pm functions

[Ayan Kumar Halder]

malidp_pm_suspend_late checks if the runtime status is not suspended
and if so, invokes malidp_runtime_pm_suspend which disables the
display engine/core interrupts and the clocks. It sets the runtime status
as suspended.

The difference between suspend() and suspend_late() is as follows:-
1. suspend() makes the device quiescent. In our case, we invoke the DRM
helper which disables the CRTC. This would have invoked runtime pm
suspend but the system suspend process disables runtime pm.
2. suspend_late() It continues the suspend operations of the drm device 
which was started by suspend(). In our case, it performs the same functionality
as runtime_suspend().

The complimentary functions are resume() and resume_early(). In the case of
resume_early(), we invoke malidp_runtime_pm_resume() which enables the clocks 
and the interrupts. It sets the runtime status as active. If the device was
in runtime suspend mode before system suspend was called, pm_runtime_work()
will put the device back in runtime suspended mode( after the complete system
has been resumed).

Signed-off-by: Ayan Kumar Halder 

---
Changes in v2:-
- Removed the change id and modified the commit message
---
 drivers/gpu/drm/arm/malidp_drv.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index bd44a6d..f6124d8 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -766,8 +766,25 @@ static int __maybe_unused malidp_pm_resume(struct device 
*dev)
return 0;
 }
 
+static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
+{
+   if (!pm_runtime_status_suspended(dev)) {
+   malidp_runtime_pm_suspend(dev);
+   pm_runtime_set_suspended(dev);
+   }
+   return 0;
+}
+
+static int __maybe_unused malidp_pm_resume_early(struct device *dev)
+{
+   malidp_runtime_pm_resume(dev);
+   pm_runtime_set_active(dev);
+   return 0;
+}
+
 static const struct dev_pm_ops malidp_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
+   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
malidp_pm_resume_early) \
SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, malidp_runtime_pm_resume, 
NULL)
 };
 
-- 
2.7.4

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

[PATCH v2 6/8] drm/arm/malidp: Enable/disable the scaling engine interrupts with memory writeback

[Ayan Kumar Halder]

Scaling engine interrupts need to be enabled/disabled as and when memwrite
is enabled and disabled. The reason being scaling engine interrupts are
used only by the memory writeout layer.

This patch depends on:
https://lkml.org/lkml/2017/5/15/695

Signed-off-by: Ayan Kumar Halder 

---
Changes in v2:-
- Removed the change id and modified the commit message
---
 drivers/gpu/drm/arm/malidp_hw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index f5633bc..90d76e4 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -621,12 +621,14 @@ static int malidp550_enable_memwrite(struct 
malidp_hw_device *hwdev,
malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | 
MALIDP_SE_MEMWRITE_EN,
  MALIDP550_SE_CONTROL);
 
+   malidp_se_irq_hw_init(hwdev);
return 0;
 }
 
 static void malidp550_disable_memwrite(struct malidp_hw_device *hwdev)
 {
u32 base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
+   malidp_se_irq_fini(hwdev);
malidp_hw_clearbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT | 
MALIDP_SE_MEMWRITE_EN,
MALIDP550_SE_CONTROL);
malidp_hw_clearbits(hwdev, MALIDP_SCALE_ENGINE_EN, base + 
MALIDP_DE_DISPLAY_FUNC);
-- 
2.7.4

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

[PATCH v2 4/8] drm/arm/malidp: Split malidp_se_irq_init

[Ayan Kumar Halder]

Extract the hardware initialisation part from malidp_se_irq_init() into the
malidp_se_irq_hw_init() which will be later invoked from
malidpxxx_enable_memwrite() when it needs to re-enable the interrupts.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_hw.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 3e73370..f5633bc 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -163,6 +163,7 @@ static const u16 
dp500_se_scaling_coeffs[][SE_N_SCALING_COEFFS] = {
 };
 
 #define MALIDP_DE_DEFAULT_PREFETCH_START   5
+static void malidp_se_irq_hw_init(struct malidp_hw_device *hwdev);
 
 static int malidp500_query_hw(struct malidp_hw_device *hwdev)
 {
@@ -952,6 +953,16 @@ static irqreturn_t malidp_se_irq(int irq, void *arg)
return IRQ_HANDLED;
 }
 
+static void malidp_se_irq_hw_init(struct malidp_hw_device *hwdev)
+{
+   /* ensure interrupts are disabled */
+   malidp_hw_disable_irq(hwdev, MALIDP_SE_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_SE_BLOCK, 0x);
+
+   malidp_hw_enable_irq(hwdev, MALIDP_SE_BLOCK,
+hwdev->hw->map.se_irq_map.irq_mask);
+}
+
 static irqreturn_t malidp_se_irq_thread_handler(int irq, void *arg)
 {
return IRQ_HANDLED;
@@ -975,8 +986,7 @@ int malidp_se_irq_init(struct drm_device *drm, int irq)
return ret;
}
 
-   malidp_hw_enable_irq(hwdev, MALIDP_SE_BLOCK,
-hwdev->hw->map.se_irq_map.irq_mask);
+   malidp_se_irq_hw_init(hwdev);
 
return 0;
 }
-- 
2.7.4

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

[PATCH v2 2/8] drm/arm/malidp: Modified the prototype of malidp_se_irq_fini

[Ayan Kumar Halder]

'struct drm_device' is being replaced with 'struct malidp_hw_device'
as the function argument.The reason being the dependency of
malidp_se_irq_fini on 'struct drm_device' needs to be removed so as to
enable it to call from functions which receives 'struct malidp_hw_device'
as argument. Furthermore, there is no way to retrieve 'struct drm_device'
from 'struct malidp_hw_device'

Signed-off-by: Ayan Kumar Halder 

---
Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_drv.c | 4 ++--
 drivers/gpu/drm/arm/malidp_hw.c  | 5 +
 drivers/gpu/drm/arm/malidp_hw.h  | 2 +-
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ed38ba9..f7a8beb 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -653,7 +653,7 @@ static int malidp_bind(struct device *dev)
 fbdev_fail:
pm_runtime_get_sync(dev);
 vblank_fail:
-   malidp_se_irq_fini(drm);
+   malidp_se_irq_fini(hwdev);
malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
 irq_init_fail:
@@ -690,7 +690,7 @@ static void malidp_unbind(struct device *dev)
drm_kms_helper_poll_fini(drm);
pm_runtime_get_sync(dev);
drm_crtc_vblank_off(>crtc);
-   malidp_se_irq_fini(drm);
+   malidp_se_irq_fini(hwdev);
malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
component_unbind_all(dev, drm);
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b13dfac..8fb02f3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -970,11 +970,8 @@ int malidp_se_irq_init(struct drm_device *drm, int irq)
return 0;
 }
 
-void malidp_se_irq_fini(struct drm_device *drm)
+void malidp_se_irq_fini(struct malidp_hw_device *hwdev)
 {
-   struct malidp_drm *malidp = drm->dev_private;
-   struct malidp_hw_device *hwdev = malidp->dev;
-
malidp_hw_disable_irq(hwdev, MALIDP_SE_BLOCK,
  hwdev->hw->map.se_irq_map.irq_mask);
 }
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 6e2a2f6..6607aba 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -299,7 +299,7 @@ static inline void malidp_hw_enable_irq(struct 
malidp_hw_device *hwdev,
 int malidp_de_irq_init(struct drm_device *drm, int irq);
 void malidp_de_irq_fini(struct malidp_hw_device *hwdev);
 int malidp_se_irq_init(struct drm_device *drm, int irq);
-void malidp_se_irq_fini(struct drm_device *drm);
+void malidp_se_irq_fini(struct malidp_hw_device *hwdev);
 
 u8 malidp_hw_get_format_id(const struct malidp_hw_regmap *map,
   u8 layer_id, u32 format);
-- 
2.7.4

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

[PATCH v2 5/8] drm/arm/malidp: Enable/disable interrupts in runtime pm

[Ayan Kumar Halder]

Display engine and core interrupts need to be disabled when the
system invokes malidp_runtime_pm_suspend. Consequently, they
need to be enabled in malidp_runtime_pm_resume.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index f7a8beb..e5a1fa0 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -470,6 +470,7 @@ static int malidp_runtime_pm_suspend(struct device *dev)
/* we can only suspend if the hardware is in config mode */
WARN_ON(!hwdev->hw->in_config_mode(hwdev));
 
+   malidp_de_irq_fini(hwdev);
hwdev->pm_suspended = true;
clk_disable_unprepare(hwdev->mclk);
clk_disable_unprepare(hwdev->aclk);
@@ -488,6 +489,7 @@ static int malidp_runtime_pm_resume(struct device *dev)
clk_prepare_enable(hwdev->aclk);
clk_prepare_enable(hwdev->mclk);
hwdev->pm_suspended = false;
+   malidp_de_irq_hw_init(hwdev);
 
return 0;
 }
-- 
2.7.4

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

[PATCH v2 3/8] drm/arm/malidp: Split malidp_de_irq_init

[Ayan Kumar Halder]

Extract the hardware initialisation part from malidp_de_irq_init() into the
malidp_de_irq_hw_init() which will be later invoked from runtime_pm_resume
function when it needs to re-enable the interrupts.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_hw.c | 25 ++---
 drivers/gpu/drm/arm/malidp_hw.h |  1 +
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 8fb02f3..3e73370 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -869,6 +869,23 @@ static irqreturn_t malidp_de_irq_thread_handler(int irq, 
void *arg)
return IRQ_HANDLED;
 }
 
+void malidp_de_irq_hw_init(struct malidp_hw_device *hwdev)
+{
+   /* ensure interrupts are disabled */
+   malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_DE_BLOCK, 0x);
+   malidp_hw_disable_irq(hwdev, MALIDP_DC_BLOCK, 0x);
+   malidp_hw_clear_irq(hwdev, MALIDP_DC_BLOCK, 0x);
+
+   /* first enable the DC block IRQs */
+   malidp_hw_enable_irq(hwdev, MALIDP_DC_BLOCK,
+hwdev->hw->map.dc_irq_map.irq_mask);
+
+   /* now enable the DE block IRQs */
+   malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
+hwdev->hw->map.de_irq_map.irq_mask);
+}
+
 int malidp_de_irq_init(struct drm_device *drm, int irq)
 {
struct malidp_drm *malidp = drm->dev_private;
@@ -889,13 +906,7 @@ int malidp_de_irq_init(struct drm_device *drm, int irq)
return ret;
}
 
-   /* first enable the DC block IRQs */
-   malidp_hw_enable_irq(hwdev, MALIDP_DC_BLOCK,
-hwdev->hw->map.dc_irq_map.irq_mask);
-
-   /* now enable the DE block IRQs */
-   malidp_hw_enable_irq(hwdev, MALIDP_DE_BLOCK,
-hwdev->hw->map.de_irq_map.irq_mask);
+   malidp_de_irq_hw_init(hwdev);
 
return 0;
 }
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 6607aba..3b049d0 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -297,6 +297,7 @@ static inline void malidp_hw_enable_irq(struct 
malidp_hw_device *hwdev,
 }
 
 int malidp_de_irq_init(struct drm_device *drm, int irq);
+void malidp_de_irq_hw_init(struct malidp_hw_device *hwdev);
 void malidp_de_irq_fini(struct malidp_hw_device *hwdev);
 int malidp_se_irq_init(struct drm_device *drm, int irq);
 void malidp_se_irq_fini(struct malidp_hw_device *hwdev);
-- 
2.7.4

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

[PATCH v2 7/8] drm/arm/malidp: Set the output_depth register in modeset

[Ayan Kumar Halder]

One needs to store the value of the OUTPUT_DEPTH that one has parsed from
device tree, so that it can be restored on system resume. This value is
set in the modeset function as this gets reset when the system suspends.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_drv.c | 1 +
 drivers/gpu/drm/arm/malidp_hw.c  | 4 
 drivers/gpu/drm/arm/malidp_hw.h  | 1 +
 3 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index e5a1fa0..bd44a6d 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -601,6 +601,7 @@ static int malidp_bind(struct device *dev)
for (i = 0; i < MAX_OUTPUT_CHANNELS; i++)
out_depth = (out_depth << 8) | (output_width[i] & 0xf);
malidp_hw_write(hwdev, out_depth, hwdev->hw->map.out_depth_base);
+   hwdev->output_color_depth = out_depth;
 
atomic_set(>config_valid, 0);
init_waitqueue_head(>wq);
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 90d76e4..1bf10fb 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -234,6 +234,8 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
 {
u32 val = 0;
 
+   malidp_hw_write(hwdev, hwdev->output_color_depth,
+   hwdev->hw->map.out_depth_base);
malidp_hw_clearbits(hwdev, MALIDP500_DC_CLEAR_MASK, 
MALIDP500_DC_CONTROL);
if (mode->flags & DISPLAY_FLAGS_HSYNC_HIGH)
val |= MALIDP500_HSYNCPOL;
@@ -458,6 +460,8 @@ static void malidp550_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
 {
u32 val = MALIDP_DE_DEFAULT_PREFETCH_START;
 
+   malidp_hw_write(hwdev, hwdev->output_color_depth,
+   hwdev->hw->map.out_depth_base);
malidp_hw_write(hwdev, val, MALIDP550_DE_CONTROL);
/*
 * Mali-DP550 and Mali-DP650 encode the background color like this:
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 3b049d0..844732d 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -228,6 +228,7 @@ struct malidp_hw_device {
 
u8 min_line_size;
u16 max_line_size;
+   u32 output_color_depth;
 
/* track the device PM state */
bool pm_suspended;
-- 
2.7.4

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

[PATCH v2 1/8] drm/arm/malidp: Modified the prototype of malidp_de_irq_fini

[Ayan Kumar Halder]

'struct drm_device' is being replaced with 'struct malidp_hw_device'
as the function argument. The reason being the dependency of
malidp_de_irq_fini on 'struct drm_device' needs to be removed so as to
enable it to call from functions which receives 'struct malidp_hw_device'
as argument. Furthermore, there is no way to retrieve 'struct drm_device'
from 'struct malidp_hw_device'.

Signed-off-by: Ayan Kumar Halder 

---
Changes in v2:-
- Removed the change id
---
 drivers/gpu/drm/arm/malidp_drv.c | 9 ++---
 drivers/gpu/drm/arm/malidp_hw.c  | 5 +
 drivers/gpu/drm/arm/malidp_hw.h  | 2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4b0c4b4..ed38ba9 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -295,6 +295,8 @@ static int malidp_irq_init(struct platform_device *pdev)
 {
int irq_de, irq_se, ret = 0;
struct drm_device *drm = dev_get_drvdata(>dev);
+   struct malidp_drm *malidp = drm->dev_private;
+   struct malidp_hw_device *hwdev = malidp->dev;
 
/* fetch the interrupts from DT */
irq_de = platform_get_irq_byname(pdev, "DE");
@@ -314,7 +316,7 @@ static int malidp_irq_init(struct platform_device *pdev)
 
ret = malidp_se_irq_init(drm, irq_se);
if (ret) {
-   malidp_de_irq_fini(drm);
+   malidp_de_irq_fini(hwdev);
return ret;
}
 
@@ -652,7 +654,7 @@ static int malidp_bind(struct device *dev)
pm_runtime_get_sync(dev);
 vblank_fail:
malidp_se_irq_fini(drm);
-   malidp_de_irq_fini(drm);
+   malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
 irq_init_fail:
component_unbind_all(dev, drm);
@@ -681,6 +683,7 @@ static void malidp_unbind(struct device *dev)
 {
struct drm_device *drm = dev_get_drvdata(dev);
struct malidp_drm *malidp = drm->dev_private;
+   struct malidp_hw_device *hwdev = malidp->dev;
 
drm_dev_unregister(drm);
drm_fb_cma_fbdev_fini(drm);
@@ -688,7 +691,7 @@ static void malidp_unbind(struct device *dev)
pm_runtime_get_sync(dev);
drm_crtc_vblank_off(>crtc);
malidp_se_irq_fini(drm);
-   malidp_de_irq_fini(drm);
+   malidp_de_irq_fini(hwdev);
drm->irq_enabled = false;
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index e4d9ebc..b13dfac 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -900,11 +900,8 @@ int malidp_de_irq_init(struct drm_device *drm, int irq)
return 0;
 }
 
-void malidp_de_irq_fini(struct drm_device *drm)
+void malidp_de_irq_fini(struct malidp_hw_device *hwdev)
 {
-   struct malidp_drm *malidp = drm->dev_private;
-   struct malidp_hw_device *hwdev = malidp->dev;
-
malidp_hw_disable_irq(hwdev, MALIDP_DE_BLOCK,
  hwdev->hw->map.de_irq_map.irq_mask);
malidp_hw_disable_irq(hwdev, MALIDP_DC_BLOCK,
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index a242e97..6e2a2f6 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -297,7 +297,7 @@ static inline void malidp_hw_enable_irq(struct 
malidp_hw_device *hwdev,
 }
 
 int malidp_de_irq_init(struct drm_device *drm, int irq);
-void malidp_de_irq_fini(struct drm_device *drm);
+void malidp_de_irq_fini(struct malidp_hw_device *hwdev);
 int malidp_se_irq_init(struct drm_device *drm, int irq);
 void malidp_se_irq_fini(struct drm_device *drm);
 
-- 
2.7.4

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

[PATCH v2 0/8] drm/arm/malidp: Enhance support for system and runtime power management on malidp.

[Ayan Kumar Halder]

This patch series enhances and fixes certain issues relevant to system and
runtime power management on malidp.

---
Changes in v2:
- Removed the change ids and modified some commit messages

---
Ayan Kumar Halder (8):
  drm/arm/malidp: Modified the prototype of malidp_de_irq_fini
  drm/arm/malidp: Modified the prototype of malidp_se_irq_fini
  drm/arm/malidp: Split malidp_de_irq_init
  drm/arm/malidp: Split malidp_se_irq_init
  drm/arm/malidp: Enable/disable interrupts in runtime pm
  drm/arm/malidp: Enable/disable the scaling engine interrupts with
memory writeback
  drm/arm/malidp: Set the output_depth register in modeset
  drm/arm/malidp: Added the late system pm functions

 drivers/gpu/drm/arm/malidp_drv.c | 33 
 drivers/gpu/drm/arm/malidp_hw.c  | 55 +++-
 drivers/gpu/drm/arm/malidp_hw.h  |  6 +++--
 3 files changed, 70 insertions(+), 24 deletions(-)

-- 
2.7.4

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

[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

--- Comment #6 from Alex Deucher  ---
Please attach your full dmesg output.

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

Re: RFC for a render API to support adaptive sync and VRR

[Harry Wentland]

On 2018-04-20 04:32 PM, Manasi Navare wrote:
> On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
>> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard  wrote:
>>> Michel Dänzer  writes:
 Time-based presentation seems to be the right approach for preventing
 micro-stutter in games as well, Croteam developers have been researching
 this.
>>>
>>> Both the Vulkan GOOGLE_display_timing extension and X11 Present
>>> extension offer the ability to specify the desired display time in
>>> seconds.
>>>
>>> Similarly, I'd suggest that the min/max display refresh rate values be
>>> advertised as time between frames rather than frames per second.
> 
> So there is a global min and max refresh rate as advertised by the monitor
> range descriptor. That I guess can be exposed as a global range in terms of
> min and max time between frames as a global property of the connector.
> 
> We dont need the per mode min and max refresh rate to be exposed right?

If I understand VRR right, with CinemaVRR acceptable refresh rates might fall 
outside the range advertised by the monitor. Would we
 1) advertise 24/1.001 as a lower bound,
 2) expect media apps to use the lower bound simply for informational purposes,
 3) or simply not support CinemaVRR?

(1) has the added caveat that not all reported rates would be supported.

Alternatively a bit could indicate that CinemaVRR is support, but I'm not sure 
if user mode would need all these details.

Harry

> 
>>>
>>> I'd also encourage using a single unit for all of these values,
>>> preferably nanoseconds. Absolute times should all be referenced to
>>> CLOCK_MONOTONIC.
>>
>> +1 on everything Keith said. I got somehow dragged in khr vk
>> discussions around preventing micro-stuttering, and consensus seems to
>> be that timestamps for scheduling frames is the way to go, most likely
>> absolute ones (not everything is running Linux unfortunately, so can't
>> go outright and claim it's guaranteed to be CLOCK_MONOTONIC).
>> -Daniel
> 
> And yes I also got consensus from Mesa and media folks about using the
> absolute timestamp for scheduling the frames and then the driver will
> modify the vblank logic to "present no earlier than the timestamp"
> 
> Manasi
> 
>> -- 
>> 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
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

[bugzilla-daemon]

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

--- Comment #20 from har...@gmx.de ---
This issues (both, the flickering and the black screen) are obviously fixed
with kernel 4.17.0-rc2. Thank you.

-- 
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 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

Hi,

Il 22/03/2018 19:05, Maxime Ripard ha scritto:

On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:

The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
   from where it can be supplied and placed in a network of 50 units
- exposed jtag pins

HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.


So this is essentially the same board than in patch 6, but with a
different screen?

You should have a single DT then, and handle the two different panels
using DT overlays.


Ok for having different DT overlays.
But do I have to submit them as patches? Or keep them in my company's repo?
I ask you this because this involves sending also patches for displays
and other little modifications to mainline ex:
- rgb888 pins
- 2 simple-panels
- 1 uart iomux pins
etc.

If I don't submit those overlays, the other patches wouldn't make sense 
alone as I've seen, just like rgb888 pins.





Signed-off-by: Giulio Benetti 
---
  .../devicetree/bindings/arm/micronova.txt  |   4 +
  arch/arm/boot/dts/Makefile |   1 +
  arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +
  3 files changed, 197 insertions(+)
  create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts

diff --git a/Documentation/devicetree/bindings/arm/micronova.txt 
b/Documentation/devicetree/bindings/arm/micronova.txt
index 35c4127..9f5ac72 100644
--- a/Documentation/devicetree/bindings/arm/micronova.txt
+++ b/Documentation/devicetree/bindings/arm/micronova.txt
@@ -4,3 +4,7 @@ Micronova Device Tree Bindings
  A20-LiNova1-4_3 HMI
  Required root node properties:
  - compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
+
+A20-LiNova1-7 HMI
+Required root node properties:
+- compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";


These bindings are unnecessary, but the panel-simple bindings should
be sent to the DT maintainers as well.


Ok, removed them and already sent the ones for display.




diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c45a4f25..eafa7cb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
sun7i-a20-linova1-ctp-4_3i.dtb\
+   sun7i-a20-linova1-ctp-7i.dtb\


You should have a space after dtb, and it should be ordered
alphabetically.


Done.




sun7i-a20-olimex-som-evb.dtb \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts 
b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
new file mode 100644
index 000..7fd0d98
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
@@ -0,0 +1,192 @@
+/*
+ * This is based on sun7i-a20-linova1-ctp-7i.dts
+ *
+ * Copyright 2014 - Hans de Goede 
+ * Copyright (c) 2014 FUKAUMI Naoki 
+ * Copyright (c) 2018 Giulio Benetti 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ 

[Bug 199475] AMDGPU Failed to blank

[bugzilla-daemon]

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

--- Comment #5 from DCWizard (andreas...@gmail.com) ---
No i don't have any display problem.

-- 
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 199475] AMDGPU Failed to blank

[bugzilla-daemon]

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

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

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Other than the message, are you actually seeing any problem with the display?

-- 
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 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

[bugzilla-daemon]

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

--- Comment #3 from Harry Wentland  ---
If the patch doesn't help are you able to capture the dmesg log and post it?

-- 
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 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

[bugzilla-daemon]

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

--- Comment #2 from Harry Wentland  ---
Created attachment 139013
  --> https://bugs.freedesktop.org/attachment.cgi?id=139013=edit
[PATCH] drm/amd/display: Disallow enabling CRTC without primary plane with FB

Does this help?

-- 
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 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

[bugzilla-daemon]

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

--- Comment #1 from Joel Sass  ---
Created attachment 139012
  --> https://bugs.freedesktop.org/attachment.cgi?id=139012=edit
A picture of the monitor output on failure.

-- 
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 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #139011|application/x-trash |text/plain
  mime type||

-- 
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 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #139009|text/x-log  |text/plain
  mime type||

-- 
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 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #139008|application/x-trash |text/plain
  mime type||

-- 
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 1/4] drm/panel: otm8009a: fix backlight updates

[Philippe Cornu]

Backlight updates was not working anymore since the good
implementation of the dsi lpm mode in the dsi host driver.
After a longer analysis, the backlight updates in dsi video
mode require the dsi hs mode.
Note: it is important to keep the dsi lpm mode for the rest
of the driver as init sequence, sleep in/out... dsi commands
work in lp mode.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index 90f1ae4af93c..0fd2e0144d2b 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -98,6 +98,20 @@ static void otm8009a_dcs_write_buf(struct otm8009a *ctx, 
const void *data,
DRM_WARN("mipi dsi dcs write buffer failed\n");
 }
 
+static void otm8009a_dcs_write_buf_hs(struct otm8009a *ctx, const void *data,
+ size_t len)
+{
+   struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+   /* data will be sent in dsi hs mode (ie. no lpm) */
+   dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+   otm8009a_dcs_write_buf(ctx, data, len);
+
+   /* restore back the dsi lpm mode */
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+}
+
 #define dcs_write_seq(ctx, seq...) \
 ({ \
static const u8 d[] = { seq };  \
@@ -387,7 +401,7 @@ static int otm8009a_backlight_update_status(struct 
backlight_device *bd)
 */
data[0] = MIPI_DCS_SET_DISPLAY_BRIGHTNESS;
data[1] = bd->props.brightness;
-   otm8009a_dcs_write_buf(ctx, data, ARRAY_SIZE(data));
+   otm8009a_dcs_write_buf_hs(ctx, data, ARRAY_SIZE(data));
 
/* set Brightness Control & Backlight on */
data[1] = 0x24;
@@ -399,7 +413,7 @@ static int otm8009a_backlight_update_status(struct 
backlight_device *bd)
 
/* Update Brightness Control & Backlight */
data[0] = MIPI_DCS_WRITE_CONTROL_DISPLAY;
-   otm8009a_dcs_write_buf(ctx, data, ARRAY_SIZE(data));
+   otm8009a_dcs_write_buf_hs(ctx, data, ARRAY_SIZE(data));
 
return 0;
 }
-- 
2.15.1

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

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Tomi Valkeinen]

On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:

> Ideally we should be able to build both drivers in the same kernel
> (especially as modules).
> 
> I was hoping that it could be fixed easily but then I discovered
> the root source of the problem:
> 
> drivers/gpu/drm/omapdrm/dss/display.o: In function 
> `omapdss_unregister_display':
> display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display'
> drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first 
> defined here

The main problem is that omapdrm and omapfb are two different drivers
for the same HW. You need to pick one, even if we would change those
functions and fix the link issue.

At some point in time we could compile both as modules (but not
built-in), but the only use for that was development/testing and in the
end made our life more difficult. So, now you must fully disable one of
them to enable the other. And, actually, we even have boot-time code,
not included in the module itself, which gets enabled when omapdrm is
enabled.

While it's of course good to support COMPILE_TEST, if using COMPILE_TEST
with omapfb is problematic, I'm not sure if it's worth to spend time on
that. We should be moving away from omapfb to omapdrm.

 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 4/4] drm/panel: otm8009a: use new backlight api

[Philippe Cornu]

Use the new backlight api.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 26 
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index 4c638b7b9943..c2a71bd17e08 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -260,11 +260,7 @@ static int otm8009a_disable(struct drm_panel *panel)
if (!ctx->enabled)
return 0; /* This is not an issue so we return 0 here */
 
-   /* Power off the backlight. Note: end-user still controls brightness */
-   ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
-   ret = backlight_update_status(ctx->bl_dev);
-   if (ret)
-   return ret;
+   backlight_disable(ctx->bl_dev);
 
ret = mipi_dsi_dcs_set_display_off(dsi);
if (ret)
@@ -338,12 +334,7 @@ static int otm8009a_enable(struct drm_panel *panel)
if (ctx->enabled)
return 0;
 
-   /*
-* Power on the backlight. Note: end-user still controls brightness
-* Note: ctx->prepared must be true before updating the backlight.
-*/
-   ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
-   backlight_update_status(ctx->bl_dev);
+   backlight_enable(ctx->bl_dev);
 
ctx->enabled = true;
 
@@ -459,11 +450,14 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
ctx->panel.dev = dev;
ctx->panel.funcs = _drm_funcs;
 
-   ctx->bl_dev = backlight_device_register(dev_name(dev), dev, ctx,
-   _backlight_ops, NULL);
+   ctx->bl_dev = devm_backlight_device_register(dev, dev_name(dev),
+dsi->host->dev, ctx,
+_backlight_ops,
+NULL);
if (IS_ERR(ctx->bl_dev)) {
-   dev_err(dev, "failed to register backlight device\n");
-   return PTR_ERR(ctx->bl_dev);
+   ret = PTR_ERR(ctx->bl_dev);
+   dev_err(dev, "failed to register backlight %d\n", ret);
+   return ret;
}
 
ctx->bl_dev->props.max_brightness = OTM8009A_BACKLIGHT_MAX;
@@ -491,8 +485,6 @@ static int otm8009a_remove(struct mipi_dsi_device *dsi)
mipi_dsi_detach(dsi);
drm_panel_remove(>panel);
 
-   backlight_device_unregister(ctx->bl_dev);
-
return 0;
 }
 
-- 
2.15.1

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

[PATCH 2/4] drm/panel: otm8009a: fix glitches by moving backlight enable to otm8009a_enable()

[Philippe Cornu]

The backlight 1st update was in the otm8009a_prepare() function
for a bad reason: backlight was not working in video mode and the
otm8009a_prepare() is in command mode for the init sequence. As the
backlight is now fixed (no lpm), it is good to put it back in the
otm8009a_enable() function, avoiding also image glitches visible
on some "slow" devices.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index 0fd2e0144d2b..de4a16d5275c 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -330,13 +330,6 @@ static int otm8009a_prepare(struct drm_panel *panel)
 
ctx->prepared = true;
 
-   /*
-* Power on the backlight. Note: end-user still controls brightness
-* Note: ctx->prepared must be true before updating the backlight.
-*/
-   ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
-   backlight_update_status(ctx->bl_dev);
-
return 0;
 }
 
@@ -344,6 +337,16 @@ static int otm8009a_enable(struct drm_panel *panel)
 {
struct otm8009a *ctx = panel_to_otm8009a(panel);
 
+   if (ctx->enabled)
+   return 0;
+
+   /*
+* Power on the backlight. Note: end-user still controls brightness
+* Note: ctx->prepared must be true before updating the backlight.
+*/
+   ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
+   backlight_update_status(ctx->bl_dev);
+
ctx->enabled = true;
 
return 0;
-- 
2.15.1

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

[PATCH 3/4] drm/panel: otm8009a: no message if probe success

[Philippe Cornu]

Remove the message in case of probe success. This comes from
a suggestion followed in the recent integration of the
raydium rm68200 panel.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index de4a16d5275c..4c638b7b9943 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -14,8 +14,6 @@
 #include 
 #include 
 
-#define DRV_NAME "orisetech_otm8009a"
-
 #define OTM8009A_BACKLIGHT_DEFAULT 240
 #define OTM8009A_BACKLIGHT_MAX 255
 
@@ -461,7 +459,7 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
ctx->panel.dev = dev;
ctx->panel.funcs = _drm_funcs;
 
-   ctx->bl_dev = backlight_device_register(DRV_NAME "_backlight", dev, ctx,
+   ctx->bl_dev = backlight_device_register(dev_name(dev), dev, ctx,
_backlight_ops, NULL);
if (IS_ERR(ctx->bl_dev)) {
dev_err(dev, "failed to register backlight device\n");
@@ -483,11 +481,6 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
return ret;
}
 
-   DRM_INFO(DRV_NAME "_panel %ux%u@%u %ubpp dsi %udl - ready\n",
-default_mode.hdisplay, default_mode.vdisplay,
-default_mode.vrefresh,
-mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
-
return 0;
 }
 
@@ -513,7 +506,7 @@ static struct mipi_dsi_driver orisetech_otm8009a_driver = {
.probe  = otm8009a_probe,
.remove = otm8009a_remove,
.driver = {
-   .name = DRV_NAME "_panel",
+   .name = "panel-orisetech-otm8009a",
.of_match_table = orisetech_otm8009a_of_match,
},
 };
-- 
2.15.1

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

[PATCH 0/4] drm/panel: otm8009a: backlight fixes & improvements

[Philippe Cornu]

This patch serie fixes 2 backlight issues and adds the new
backlight api support.

Philippe Cornu (4):
  drm/panel: otm8009a: fix backlight updates
  drm/panel: otm8009a: fix glitches by moving backlight enable to
otm8009a_enable()
  drm/panel: otm8009a: no message if probe success
  drm/panel: otm8009a: use new backlight api

 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 58 
 1 file changed, 30 insertions(+), 28 deletions(-)

-- 
2.15.1

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

[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

[bugzilla-daemon]

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

Bug ID: 106193
   Summary: When positioning a monitor output above or below
initial configuration with xrandr, hard freeze with
graphics artifacts 4.16.2+
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sass.j...@gmail.com

I'm unable to position my monitors outside of an inline configuration. I have 5
monitors, and if I try to position one outside of an inline configuration with
xrandr, it results in a hard lock.

Steps to replicate the process:

$ xrandr --fb 7680x2160

  xrandr --screen 0 output shows that the virtual desktop is set to 7680x2160

$ xrandr --output DP-6 --pos 0x1080

At that point, mouse and keyboard become unresponsive. After about 30 seconds,
monitor output shows artifacting. I'll see if I can post an image of what I
see.

It appears this also causes all network activity to stop. The system cannot be
pinged, and SSH server stops functioning. Seems to have the same issues as
https://bugs.freedesktop.org/show_bug.cgi?id=106159 which freezes the system
when connecting or disconnecting a displayport cable.

-- 
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: Don't pass the index to drm_property_add_enum()

[Lisovskiy, Stanislav]

Acked-by: Stanislav Lisovskiy 

Best Regards,

Lisovskiy Stanislav

Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo>


From: Ville Syrjala [ville.syrj...@linux.intel.com]
Sent: Friday, March 16, 2018 9:04 PM
To: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org; Patrik Jakobsson; Ben Skeggs; 
nouv...@lists.freedesktop.org
Subject: [PATCH] drm: Don't pass the index to drm_property_add_enum()

From: Ville Syrjälä 

drm_property_add_enum() can calculate the index itself just fine,
so no point in having the caller pass it in.

Cc: Patrik Jakobsson 
Cc: Ben Skeggs 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c   |  6 +++---
 drivers/gpu/drm/drm_property.c| 27 +--
 drivers/gpu/drm/gma500/cdv_device.c   |  4 ++--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  2 +-
 drivers/gpu/drm/i915/intel_sdvo.c |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +---
 include/drm/drm_property.h|  2 +-
 7 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..dfc8ca1e9413 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1069,7 +1069,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
goto nomem;

for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.tv_mode_property, i,
+   drm_property_add_enum(dev->mode_config.tv_mode_property,
  i, modes[i]);

dev->mode_config.tv_brightness_property =
@@ -1156,7 +1156,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
 {
struct drm_device *dev = connector->dev;
struct drm_property *scaling_mode_property;
-   int i, j = 0;
+   int i;
const unsigned valid_scaling_mode_mask =
(1U << ARRAY_SIZE(drm_scaling_mode_enum_list)) - 1;

@@ -1177,7 +1177,7 @@ int drm_connector_attach_scaling_mode_property(struct 
drm_connector *connector,
if (!(BIT(i) & scaling_mode_mask))
continue;

-   ret = drm_property_add_enum(scaling_mode_property, j++,
+   ret = drm_property_add_enum(scaling_mode_property,
drm_scaling_mode_enum_list[i].type,
drm_scaling_mode_enum_list[i].name);

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 8f4672daac7f..1f8031e30f53 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -169,9 +169,9 @@ struct drm_property *drm_property_create_enum(struct 
drm_device *dev,
return NULL;

for (i = 0; i < num_values; i++) {
-   ret = drm_property_add_enum(property, i,
- props[i].type,
- props[i].name);
+   ret = drm_property_add_enum(property,
+   props[i].type,
+   props[i].name);
if (ret) {
drm_property_destroy(dev, property);
return NULL;
@@ -209,7 +209,7 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 uint64_t supported_bits)
 {
struct drm_property *property;
-   int i, ret, index = 0;
+   int i, ret;
int num_values = hweight64(supported_bits);

flags |= DRM_MODE_PROP_BITMASK;
@@ -221,14 +221,9 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
if (!(supported_bits & (1ULL << props[i].type)))
continue;

-   if (WARN_ON(index >= num_values)) {
-   drm_property_destroy(dev, property);
-   return NULL;
-   }
-
-   ret = drm_property_add_enum(property, index++,
- props[i].type,
- props[i].name);
+   ret = drm_property_add_enum(property,
+   props[i].type,
+   props[i].name);
if (ret) {
drm_property_destroy(dev, property);
return NULL;
@@ -376,7 +371,6 @@ EXPORT_SYMBOL(drm_property_create_bool);
 /**
  * drm_property_add_enum - add a possible value to an enumeration property
  * @property: enumeration property to change
- * @index: index of the new enumeration
  * 

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Bartlomiej Zolnierkiewicz]

On Monday, April 23, 2018 02:47:28 PM Bartlomiej Zolnierkiewicz wrote:
> On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote:
> > Add stubs for omapfb_dss.h, in the case it is included by
> > some driver when CONFIG_FB_OMAP2 is not defined, with can
> > happen on ARM when DRM_OMAP is not 'n'.
> > 
> > That allows building such driver(s) with COMPILE_TEST.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> 
> This patch should be dropped (together with patch #6/7) as it was
> superseded by a better solution suggested by Laurent:
> 
> https://patchwork.kernel.org/patch/10325193/
> 
> ACK-ed by Tomi:
> 
> https://www.spinics.net/lists/dri-devel/msg171918.html
> 
> and already merged by you (commit 7378f1149884 "media: omap2:
> omapfb: allow building it with COMPILE_TEST")..

Hmm, I see now while this patch is still included:

menuconfig FB_OMAP2
tristate "OMAP2+ frame buffer support"
depends on FB
depends on DRM_OMAP = n

Ideally we should be able to build both drivers in the same kernel
(especially as modules).

I was hoping that it could be fixed easily but then I discovered
the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display':
display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display'
drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first 
defined here
...

I need some more time to think about this..

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

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

[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep

[bugzilla-daemon]

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

--- Comment #3 from Joel Sass  ---
Created attachment 139011
  --> https://bugs.freedesktop.org/attachment.cgi?id=139011=edit
Xorg.conf from frozen screen 0

-- 
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 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep

[bugzilla-daemon]

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

--- Comment #2 from Joel Sass  ---
Created attachment 139010
  --> https://bugs.freedesktop.org/attachment.cgi?id=139010=edit
Dmesg shows kernel error after freezing. Had to acquire with ssh.

Looks like a kernel bug issue. This 

[  966.373770] BUG: unable to handle kernel paging request at b419820f3c60
[  966.373776] IP: __ww_mutex_lock.isra.3+0x283/0x670
[  966.373777] PGD 46ed48067 P4D 46ed48067 PUD 46ed49067 PMD 461fc5067 PTE 0
[  966.373780] Oops:  [#2] SMP PTI
[  966.373781] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp
bridge stp llc rfcomm ebtable_filter ebtables ip6table_filter ip6_tables
iptable_filter ip_tables x_tables bnep binfmt_misc btusb btrtl btbcm btintel
bluetooth snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi
snd_hda_intel ecdh_generic snd_hda_codec applesmc input_leds input_polldev
intel_powerclamp coretemp snd_seq_midi snd_hda_core intel_cstate
snd_seq_midi_event snd_hwdep snd_rawmidi snd_pcm snd_seq snd_seq_device
snd_timer snd lpc_ich kvm_intel kvm irqbypass soundcore shpchp i5500_temp
mac_hid ioatdma i7core_edac dca parport_pc ppdev lp parport autofs4 raid10
raid456
[  966.373810]  async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq libcrc32c raid1 raid0 multipath linear amdkfd amd_iommu_v2 amdgpu
chash i2c_algo_bit gpu_sched ttm hid_generic drm_kms_helper e1000e
firewire_ohci syscopyarea sysfillrect usbhid sysimgblt ptp fb_sys_fops
pata_acpi firewire_core crc_itu_t hid pps_core drm
[  966.373825] CPU: 4 PID: 3205 Comm: Xorg Tainted: G  D W I  4.16.2+
#1
[  966.373826] Hardware name: Apple Inc. MacPro4,1/Mac-F221BEC8, BIOS
MP41.88Z.0081.B07.0910130729 10/13/09
[  966.373828] RIP: 0010:__ww_mutex_lock.isra.3+0x283/0x670
[  966.373828] RSP: 0018:b41982473870 EFLAGS: 00010282
[  966.373829] RAX: b419820f3c58 RBX: 9735a1096830 RCX:
00e7
[  966.373830] RDX: 9735a530be81 RSI: 97357cbbbe80 RDI:
b41982473890
[  966.373831] RBP: b419824738f0 R08: 9735a34ab080 R09:
9735a3ab0b80
[  966.373831] R10: b41982473908 R11: 2800 R12:
0002
[  966.373832] R13: 9735a1096828 R14: b419824739c8 R15:

[  966.373833] FS:  7faa1e832a00() GS:9735af30()
knlGS:
[  966.373834] CS:  0010 DS:  ES:  CR0: 80050033
[  966.373835] CR2: b419820f3c60 CR3: 000443164000 CR4:
06e0
[  966.373836] Call Trace:
[  966.373839]  __ww_mutex_lock_slowpath+0x16/0x20
[  966.373840]  ? __ww_mutex_lock_slowpath+0x16/0x20
[  966.373841]  ww_mutex_lock+0x5a/0x70
[  966.373852]  drm_modeset_lock+0x35/0xb0 [drm]
[  966.373858]  drm_atomic_get_crtc_state+0x5b/0x110 [drm]
[  966.373865]  drm_atomic_get_plane_state+0xec/0x110 [drm]
[  966.373870]  restore_fbdev_mode_atomic+0xd5/0x200 [drm_kms_helper]
[  966.373873]  restore_fbdev_mode+0x31/0x140 [drm_kms_helper]
[  966.373875]  ? _cond_resched+0x19/0x40
[  966.373878]  drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0
[drm_kms_helper]
[  966.373881]  drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
[  966.373883]  fb_set_var+0x19f/0x440
[  966.373885]  ? mem_cgroup_uncharge_list+0x69/0x90
[  966.373888]  fbcon_blank+0x2b7/0x3a0
[  966.373891]  do_unblank_screen+0xba/0x1b0
[  966.373892]  vt_ioctl+0x4e1/0x1150
[  966.373894]  ? jbd2_journal_stop+0xf6/0x3f0
[  966.373896]  tty_ioctl+0xf6/0x8c0
[  966.373898]  ? fsnotify_grab_connector+0x43/0x70
[  966.373900]  ? call_rcu_sched+0x17/0x20
[  966.373901]  do_vfs_ioctl+0xa8/0x630
[  966.373903]  ? __fput+0x193/0x220
[  966.373904]  SyS_ioctl+0x79/0x90
[  966.373907]  do_syscall_64+0x73/0x130
[  966.373908]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  966.373909] RIP: 0033:0x7faa1c69bf47
[  966.373910] RSP: 002b:7ffd3892b788 EFLAGS: 3246 ORIG_RAX:
0010
[  966.373911] RAX: ffda RBX: 55aa519db820 RCX:
7faa1c69bf47
[  966.373912] RDX:  RSI: 4b3a RDI:
000a
[  966.373912] RBP: 7ffd3892b800 R08: 55aa5257a420 R09:
55aa5257a100
[  966.373913] R10: 003a R11: 3246 R12:
7ffd3892b970
[  966.373914] R13: 0001 R14: 0005 R15:
55aa519e5360
[  966.373915] Code: cd 03 00 00 45 84 ff 0f 85 43 02 00 00 48 89 df e8 03 34
00 00 e9 39 ff ff ff 49 8b 45 20 48 85 c0 0f 84 38 03 00 00 49 8b 4e 08 <48> 8b
50 08 48 39 d1 0f 88 27 03 00 00 48 39 d1 75 09 49 39 c6 
[  966.373934] RIP: __ww_mutex_lock.isra.3+0x283/0x670 RSP: b41982473870
[  966.373935] CR2: b419820f3c60
[  966.373936] ---[ end trace 57a9c31f2648be5f ]---

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list

[Bug 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep

[bugzilla-daemon]

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

--- Comment #1 from Joel Sass  ---
Created attachment 139009
  --> https://bugs.freedesktop.org/attachment.cgi?id=139009=edit
Xorg failure when screen was blanked in lightdm

-- 
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 106192] 4.16.2+ lightdm logon screen will not unblank after monitors fall asleep

[bugzilla-daemon]

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

Bug ID: 106192
   Summary: 4.16.2+ lightdm logon screen will not unblank after
monitors fall asleep
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sass.j...@gmail.com

Created attachment 139008
  --> https://bugs.freedesktop.org/attachment.cgi?id=139008=edit
Initial boot - everything was fine.

If I leave my computer at the logon screen and the monitors fall asleep, I
cannot wake them. Requires a reboot.

Looks like there was a dmesg error, and Xorg.0.log reflects a failure when
attempting to use screen 0.

I'll include the xorg.conf because that may have had something to do with it
according to the Xorg.0.log.

-- 
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: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI connector

[Lisovskiy, Stanislav]

Ping

From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of StanLis 
[stanislav.lisovs...@intel.com]
Sent: Monday, April 23, 2018 10:34 AM
To: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI 
connector

From: Stanislav Lisovskiy 

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/drm-kms.rst|  6 +++
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 +++
 drivers/gpu/drm/drm_connector.c  | 74 
 drivers/gpu/drm/drm_edid.c   |  2 +
 include/drm/drm_connector.h  | 18 +++
 include/drm/drm_mode_config.h|  5 ++
 include/uapi/drm/drm_mode.h  |  7 +++
 8 files changed, 130 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1dffd1ac4cd4..e233c2626bd0 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -517,6 +517,12 @@ Standard Connector Properties
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: standard connector properties

+HDMI Specific Connector Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: HDMI connector properties
+
 Plane Composition Properties
 

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..3567c986bd7d 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..479499f5848e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   state->content_type = val & 3;
+   state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1360,14 @@ 

[Bug 106191] FirePro v8800 Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

François Jacques  changed:

   What|Removed |Added

Summary|Failure to recognize|FirePro v8800 Failure to
   |DisplayPort signal  |recognize DisplayPort
   ||signal

-- 
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 106191] Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

François Jacques  changed:

   What|Removed |Added

   Keywords||have-backtrace

-- 
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 106191] Failure to recognize DisplayPort signal

[bugzilla-daemon]

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

--- Comment #5 from François Jacques  ---
If there's anything else I can provide that would help further diagnosing this
issue, I'll gladly try.

Steps I'm thinking about taking for further experiments, in the meantime:

1) try with latest stable kernel available for my distro 
2) try with liveCD of a commercial distro /w rolling release
3) try with older liveCD /w fglrx driver (perhaps from 2011)

I can change the radeon files to output more data or 'debug' trace too. I would
need minimal guidance for which DEFINE to set prior rebuilding to get that
debug trace.

Thank you very much in advance; I can't understand why this pro beast from 2010
can't drive that monitor through DisplayPort.

-- 
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 103769] Unity based games do not start

[bugzilla-daemon]

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

--- Comment #15 from letha...@gmail.com ---
it seems the segfaults have improved lately... Much less, the games do start
more often

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