[PATCH] drm/doc: diagram for mode objects and properties

[Daniel Vetter]

Resulted in confusion a few times in the past.

v2: Spelling fix (Eric).

Cc: Eric Anholt 
Acked-by: Eric Anholt 
Cc: Laurent Pinchart 
Cc: Manasi Navare 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 17a4cd5b14fd..a504d9ee4d94 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -161,6 +161,28 @@ KMS Core Structures and Functions
 Modeset Base Object Abstraction
 ===
 
+.. kernel-render:: DOT
+   :alt: Mode Objects and Properties
+   :caption: Mode Objects and Properties
+
+   digraph {
+  node [shape=box]
+
+  "drm_property A" -> "drm_mode_object A"
+  "drm_property A" -> "drm_mode_object B"
+  "drm_property B" -> "drm_mode_object A"
+   }
+
+The base structure for all KMS objects is :c:type:`struct drm_mode_object
+`. One of the base services it provides is tracking 
properties,
+which are especially important for the atomic IOCTL (see `Atomic Mode
+Setting`_). The somewhat surprising part here is that properties are not
+directly instantiated on each object, but free-standing mode objects 
themselves,
+represented by :c:type:`struct drm_property `, which only specify
+the type and value range of a property. Any given property can be attached
+multiple times to different objects using :c:func:`drm_object_attach_property()
+`.
+
 .. kernel-doc:: include/drm/drm_mode_object.h
:internal:
 
-- 
2.11.0

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

[PATCH] drm/doc: atomic overview, with graph

[Daniel Vetter]

I want to split up a few more things and document some details better
(like how exactly to subclass drm_atomic_state). And maybe also split
up the helpers a bit per-topic, but this should be a ok-ish start for
better atomic overview.

One thing I failed at is getting DOT to layout the overview graph how
I want it. The highlevel structure I want is:

Free-standing State

Current State

i.e. one over the other. Currently it lays it out side-by-side, but
not even that really - "Current State" is somewhat offset below. Makes
the graph look like garbage, and also way too wide for proper
rendering. Ideas appreciated.

v2: Spelling and clarifications (Eric).

Cc: Eric Anholt 
Cc: Laurent Pinchart 
Cc: Harry Wentland 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms-helpers.rst |  2 +
 Documentation/gpu/drm-kms.rst | 86 ++-
 2 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 050ebe81d256..ac53c0b893f6 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -42,6 +42,8 @@ Modeset Helper Reference for Common Vtables
 .. kernel-doc:: include/drm/drm_modeset_helper_vtables.h
:internal:
 
+.. _drm_atomic_helper:
+
 Atomic Modeset Helper Functions Reference
 =
 
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index a504d9ee4d94..4823df03c773 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -189,8 +189,92 @@ multiple times to different objects using 
:c:func:`drm_object_attach_property()
 .. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
:export:
 
+Atomic Mode Setting
+===
+
+
+.. FIXME: The I want the below graph to be laid out so that the 2 subgraph
+   clusters are below each another. But I failed.
+
+.. kernel-render:: DOT
+   :alt: Mode Objects and Properties
+   :caption: Mode Objects and Properties
+
+   digraph {
+  node [shape=box]
+
+  subgraph cluster_state {
+  style=dashed
+  label="Free-standing state"
+
+  "drm_atomic_state" -> "duplicated drm_plane_state A"
+  "drm_atomic_state" -> "duplicated drm_plane_state B"
+  "drm_atomic_state" -> "duplicated drm_crtc_state"
+  "drm_atomic_state" -> "duplicated drm_connector_state"
+  "drm_atomic_state" -> "duplicated driver private state"
+  }
+
+  subgraph cluster_current {
+  style=dashed
+  label="Current state"
+
+  "drm_device" -> "drm_plane A"
+  "drm_device" -> "drm_plane B"
+  "drm_device" -> "drm_crtc"
+  "drm_device" -> "drm_connector"
+  "drm_device" -> "driver private object"
+
+  "drm_plane A" -> "drm_plane_state A"
+  "drm_plane B" -> "drm_plane_state B"
+  "drm_crtc" -> "drm_crtc_state"
+  "drm_connector" -> "drm_connector_state"
+  "driver private object" -> "driver private state"
+  }
+
+  "drm_atomic_state" -> "drm_device" [label="atomic_commit"]
+   }
+
+Atomic provides transactional modeset (including planes) updates, but a
+bit differently from the usual transactional approach of try-commit and
+rollback:
+
+- Firstly, no hardware changes are allowed when the commit would fail. This
+  allows us to implement the DRM_MODE_ATOMIC_TEST_ONLY mode, which allows
+  userspace to explore whether certain configurations would work or not.
+
+- This would still allow setting and rollback of just the software state,
+  simplifying conversion of existing drivers. But auditing drivers for
+  correctness of the atomic_check code becomes really hard with that: Rolling
+  back changes in data structures all over the place is hard to get right.
+
+- Lastly, for backwards compatibility and to support all use-cases, atomic
+  updates need to be incremental and be able to execute in parallel. Hardware
+  doesn't always allow it, but where possible plane updates on different CRTCs
+  should not interfere, and not get stalled due to output routing changing on
+  different CRTCs.
+
+Taken all together there's two consequences for the atomic design:
+
+- The overall state is split up into per-object state structures:
+  :c:type:`struct drm_plane_state ` for planes, 
:c:type:`struct
+  drm_crtc_state ` for CRTCs and :c:type:`struct
+  drm_connector_state `
+  container. Again drivers can subclass that container for their own state
+  structure tracking needs. Only when a state is committed is it applied to the
+  driver and modeset objects. This way rolling back an update boils down to
+  releasing memory and unreferencing objects like framebuffers.
+
+Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
+coverage of specific topics.
+
 Atomic Mode Setting Function Reference
-==
+--

Re: [PATCH RESEND] drm/via: use get_user_pages_unlocked()

[Daniel Vetter]

On Tue, Feb 28, 2017 at 08:28:08PM +, Lorenzo Stoakes wrote:
> On 28 February 2017 at 19:35, Al Viro  wrote:
> > On Tue, Feb 28, 2017 at 10:01:10AM +0100, Daniel Vetter wrote:
> >
> >> > +   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
> >> > +   vsg->num_pages, vsg->pages,
> >> > +   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 
> >> > 0);
> >
> > Umm...  Why not
> > ret = get_user_pages_fast((unsigned long)xfer->mem_addr,
> > vsg->num_pages,
> > vsg->direction == DMA_FROM_DEVICE,
> > vsg->pages);
> >
> > IOW, do you really need a warranty that ->mmap_sem will be grabbed and
> > released?
> 
> Daniel will be better placed to answer in this specific case, but more
> generally is there any reason why we can't just use
> get_user_pages_fast() in all such cases? These patches were simply a
> mechanical/cautious replacement for code that is more or less exactly
> equivalent but if this would make sense perhaps it'd be worth using
> gup_fast() where possible?

I have no idea. drm/via is unmaintained, it's a dri1 racy driver with
problems probably everywhere, and I'm not sure we even have someone left
who cares (there's an out-of-tree kms conversion of via, but it's stuck
since years).

In short, it's the drm dungeons and the only reason I merge patches is to
give people an easy target for test driving the patch submission process
to dri-devel. And to avoid drm being a blocker for tree-wide refactorings.
Otherwise 0 reasons to change anything here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_

[Daniel Vetter]

On Tue, Feb 28, 2017 at 04:55:54AM -0800, Joe Perches wrote:
> Use a more common logging style.
> 
> Miscellanea:
> 
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
> 
> Signed-off-by: Joe Perches 

Plenty acks, also merged for 4.12.

Thanks, Daniel

> ---
>  drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  9 -
>  drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
>  drivers/gpu/drm/gma500/psb_drv.h  |  5 ++---
>  drivers/gpu/drm/gma500/psb_intel_lvds.c   |  7 +++
>  drivers/gpu/drm/i915/i915_sw_fence.c  |  8 
>  drivers/gpu/drm/mgag200/mgag200_mode.c|  2 +-
>  drivers/gpu/drm/msm/msm_drv.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_acpi.c|  7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.c |  4 ++--
>  drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
>  drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
>  drivers/gpu/drm/omapdrm/dss/dss.c |  3 +--
>  drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
>  drivers/gpu/drm/omapdrm/omap_gem.c|  5 ++---
>  drivers/gpu/drm/r128/r128_cce.c   |  7 +++
>  drivers/gpu/drm/ttm/ttm_bo.c  |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |  6 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  3 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  |  4 ++--
>  20 files changed, 72 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder 
> *encoder,
>   head) {
>   if (tmp_encoder != encoder
>   && tmp_encoder->crtc == encoder->crtc) {
> - printk(KERN_ERR "Can't enable LVDS and another "
> -"encoder on the same pipe\n");
> + pr_err("Can't enable LVDS and another encoder on the 
> same pipe\n");
>   return false;
>   }
>   }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>  
>  failed_find:
>   mutex_unlock(&dev->mode_config.mutex);
> - printk(KERN_ERR "Failed find\n");
> + pr_err("Failed find\n");
>   psb_intel_i2c_destroy(gma_encoder->ddc_bus);
>  failed_ddc:
> - printk(KERN_ERR "Failed DDC\n");
> + pr_err("Failed DDC\n");
>   psb_intel_i2c_destroy(gma_encoder->i2c_bus);
>  failed_blc_i2c:
> - printk(KERN_ERR "Failed BLC\n");
> + pr_err("Failed BLC\n");
>   drm_encoder_cleanup(encoder);
>   drm_connector_cleanup(connector);
>   kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct 
> drm_device *dev,
>   ((ti->vblank_hi << 8) | ti->vblank_lo);
>   mode->clock = ti->pixel_clock * 10;
>  #if 0
> - printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> - printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> - printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> - printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> - printk(KERN_INFO "htotal is %d\n", mode->htotal);
> - printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> - printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> - printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> - printk(KERN_INFO "clock is %d\n", mode->clock);
> + pr_info("hdisplay is %d\n", mode->hdisplay);
> + pr_info("vdisplay is %d\n", mode->vdisplay);
> + pr_info("HSS is %d\n", mode->hsync_start);
> + pr_info("HSE is %d\n", mode->hsync_end);
> + pr_info("htotal is %d\n", mode->htotal);
> + pr_info("VSS is %d\n", mode->vsync_start);
> + pr_info("VSE is %d\n", mode->vsync_end);
> + pr_info("vtotal is %d\n", mode->vtotal);
> + pr_info("clock is %d\n", mode->clock);
>  #endif
>   mode_dev->panel_fixed_mode = mode;
>   }
> diff --git a/drivers/gpu/drm/gma500/psb_drv.h 
> b/drivers/gpu/drm/gma500/psb_drv.h
> index 83e22fd4cfc0..83667087d6e5 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.h
> +++ b/drivers/gpu/drm/gma500/psb_drv.h
> @@ -905,9 +905,8 @@ static inline void REGISTER_WRITE8(struct drm_device *dev,
>  #define PSB_RSGX32(_offs)  

Re: [PATCH 3/3] drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style issues

[Daniel Vetter]

On Tue, Feb 28, 2017 at 06:59:52PM +, Joan Jani wrote:
> Fixed the following style issues
> 
> drivers/gpu/vga/vga_switcheroo.c:98: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:99: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:102: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:103: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:129: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:135: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:217: WARNING: line over 80 characters
> drivers/gpu/vga/vga_switcheroo.c:218: WARNING: line over 80 characters
> drivers/gpu/vga/vga_switcheroo.c:308: WARNING: please, no space before tabs
> drivers/gpu/vga/vga_switcheroo.c:340: WARNING: line over 80 characters
> drivers/gpu/vga/vga_switcheroo.c:1087: WARNING: Block comments use * on 
> subsequent lines
> drivers/gpu/vga/vga_switcheroo.c:1087: WARNING: Block comments use a trailing 
> */ on a separate line
> 
> Signed-off-by: Joan Jani 

Applied to drm-misc for 4.12, thanks.
-Daniel

> ---
>  drivers/gpu/vga/vga_switcheroo.c | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index 5f962bf..3cd153c 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -95,12 +95,12 @@
>   * @pwr_state: current power state
>   * @ops: client callbacks
>   * @id: client identifier. Determining the id requires the handler,
> - *   so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
> - *   and later given their true id in vga_switcheroo_enable()
> + *   so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
> + *   and later given their true id in vga_switcheroo_enable()
>   * @active: whether the outputs are currently switched to this client
>   * @driver_power_control: whether power state is controlled by the driver's
> - *   runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
> - *   interface is a no-op so as not to interfere with runtime pm
> + *   runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
> + *   interface is a no-op so as not to interfere with runtime pm
>   * @list: client list
>   *
>   * Registered client. A client can be either a GPU or an audio device on a 
> GPU.
> @@ -126,13 +126,13 @@ static DEFINE_MUTEX(vgasr_mutex);
>  /**
>   * struct vgasr_priv - vga_switcheroo private data
>   * @active: whether vga_switcheroo is enabled.
> - *   Prerequisite is the registration of two GPUs and a handler
> + *   Prerequisite is the registration of two GPUs and a handler
>   * @delayed_switch_active: whether a delayed switch is pending
>   * @delayed_client_id: client to which a delayed switch is pending
>   * @debugfs_root: directory for vga_switcheroo debugfs interface
>   * @switch_file: file for vga_switcheroo debugfs interface
>   * @registered_clients: number of registered GPUs
> - *   (counting only vga clients, not audio clients)
> + *   (counting only vga clients, not audio clients)
>   * @clients: list of registered clients
>   * @handler: registered handler
>   * @handler_flags: flags of registered handler
> @@ -214,8 +214,9 @@ static void vga_switcheroo_enable(void)
>   *
>   * Return: 0 on success, -EINVAL if a handler was already registered.
>   */
> -int vga_switcheroo_register_handler(const struct vga_switcheroo_handler 
> *handler,
> - enum vga_switcheroo_handler_flags_t 
> handler_flags)
> +int vga_switcheroo_register_handler(
> +   const struct vga_switcheroo_handler *handler,
> +   enum vga_switcheroo_handler_flags_t handler_flags)
>  {
>   mutex_lock(&vgasr_mutex);
>   if (vgasr_priv.handler) {
> @@ -305,7 +306,7 @@ static int register_client(struct pci_dev *pdev,
>   * @pdev: client pci device
>   * @ops: client callbacks
>   * @driver_power_control: whether power state is controlled by the driver's
> - *   runtime pm
> + *   runtime pm
>   *
>   * Register vga client (GPU). Enable vga_switcheroo if another GPU and a
>   * handler have already registered. The power state of the client is assumed
> @@ -337,8 +338,8 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
>   * Return: 0 on success, -ENOMEM on memory allocation error.
>   */
>  int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
> -  const struct vga_switcheroo_client_ops 
> *ops,
> -  enum vga_switcheroo_client_id id)
> + const struct vga_switcheroo_client_ops *ops,
> + enum vga_switcheroo_client_id id)
>  {
>   return register_client(pdev, ops, id | ID_BIT_AUDIO, false, false);
>  }
> @@ -1084,7 +1085,8 @@ static int 
> vga_switcheroo_runtime_resume_hdmi_audio(struct device *dev)
>   

[PATCH v3 4/4] drm/imx: ipuv3-plane: add support for separate alpha planes

[Philipp Zabel]

The IPUv3 can read 8-bit alpha values from a separate plane buffer using
a companion IDMAC channel driven by the Alpha Transparency Controller
(ATC) for the graphics channels. The conditional read mechanism allows
to reduce memory bandwidth by skipping reads of color data for
completely transparent bursts.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 97 ++-
 drivers/gpu/drm/imx/ipuv3-plane.h |  1 +
 2 files changed, 97 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 53eceff09d179..cecb8eba5c320 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -57,6 +57,12 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_RGB565,
+   DRM_FORMAT_RGB565_A8,
+   DRM_FORMAT_BGR565_A8,
+   DRM_FORMAT_RGB888_A8,
+   DRM_FORMAT_BGR888_A8,
+   DRM_FORMAT_RGBX_A8,
+   DRM_FORMAT_BGRX_A8,
 };
 
 int ipu_plane_irq(struct ipu_plane *ipu_plane)
@@ -126,11 +132,14 @@ void ipu_plane_put_resources(struct ipu_plane *ipu_plane)
ipu_dmfc_put(ipu_plane->dmfc);
if (!IS_ERR_OR_NULL(ipu_plane->ipu_ch))
ipu_idmac_put(ipu_plane->ipu_ch);
+   if (!IS_ERR_OR_NULL(ipu_plane->alpha_ch))
+   ipu_idmac_put(ipu_plane->alpha_ch);
 }
 
 int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
 {
int ret;
+   int alpha_ch;
 
ipu_plane->ipu_ch = ipu_idmac_get(ipu_plane->ipu, ipu_plane->dma);
if (IS_ERR(ipu_plane->ipu_ch)) {
@@ -139,6 +148,17 @@ int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
return ret;
}
 
+   alpha_ch = ipu_channel_alpha_channel(ipu_plane->dma);
+   if (alpha_ch >= 0) {
+   ipu_plane->alpha_ch = ipu_idmac_get(ipu_plane->ipu, alpha_ch);
+   if (IS_ERR(ipu_plane->alpha_ch)) {
+   ret = PTR_ERR(ipu_plane->alpha_ch);
+   DRM_ERROR("failed to get alpha idmac channel %d: %d\n",
+ alpha_ch, ret);
+   return ret;
+   }
+   }
+
ipu_plane->dmfc = ipu_dmfc_get(ipu_plane->ipu, ipu_plane->dma);
if (IS_ERR(ipu_plane->dmfc)) {
ret = PTR_ERR(ipu_plane->dmfc);
@@ -162,12 +182,29 @@ int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
return ret;
 }
 
+static bool ipu_plane_separate_alpha(struct ipu_plane *ipu_plane)
+{
+   switch (ipu_plane->base.state->fb->format->format) {
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static void ipu_plane_enable(struct ipu_plane *ipu_plane)
 {
if (ipu_plane->dp)
ipu_dp_enable(ipu_plane->ipu);
ipu_dmfc_enable_channel(ipu_plane->dmfc);
ipu_idmac_enable_channel(ipu_plane->ipu_ch);
+   if (ipu_plane_separate_alpha(ipu_plane))
+   ipu_idmac_enable_channel(ipu_plane->alpha_ch);
if (ipu_plane->dp)
ipu_dp_enable_channel(ipu_plane->dp);
 }
@@ -181,6 +218,8 @@ void ipu_plane_disable(struct ipu_plane *ipu_plane, bool 
disable_dp_channel)
if (ipu_plane->dp && disable_dp_channel)
ipu_dp_disable_channel(ipu_plane->dp, false);
ipu_idmac_disable_channel(ipu_plane->ipu_ch);
+   if (ipu_plane->alpha_ch)
+   ipu_idmac_disable_channel(ipu_plane->alpha_ch);
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
ipu_dp_disable(ipu_plane->ipu);
@@ -224,7 +263,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
struct device *dev = plane->dev->dev;
struct drm_framebuffer *fb = state->fb;
struct drm_framebuffer *old_fb = old_state->fb;
-   unsigned long eba, ubo, vbo, old_ubo, old_vbo;
+   unsigned long eba, ubo, vbo, old_ubo, old_vbo, alpha_eba;
bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
struct drm_rect clip;
int hsub, vsub;
@@ -355,6 +394,23 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (((state->src.x1 >> 16) & (hsub - 1)) ||
((state->src.y1 >> 16) & (vsub - 1)))
return -EINVAL;
+   break;
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
+   alpha_eba = drm_plane_state_to_eba(state, 1);
+   if (alpha_eba & 0x7)
+   return -EINVAL;
+
+   if (fb->pitches[1] < 1 || f

[PATCH v3 3/4] drm/imx: extend drm_plane_state_to_eba for separate channel support

[Philipp Zabel]

Allow to calculate EBA for planes other than plane 0. This is in
preparation for the following patch, which adds support for separate
alpha planes.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index a37735298615e..53eceff09d179 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -66,18 +66,18 @@ int ipu_plane_irq(struct ipu_plane *ipu_plane)
 }
 
 static inline unsigned long
-drm_plane_state_to_eba(struct drm_plane_state *state)
+drm_plane_state_to_eba(struct drm_plane_state *state, int plane)
 {
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
 
-   cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
+   cma_obj = drm_fb_cma_get_gem_obj(fb, plane);
BUG_ON(!cma_obj);
 
-   return cma_obj->paddr + fb->offsets[0] + fb->pitches[0] * y +
-  fb->format->cpp[0] * x;
+   return cma_obj->paddr + fb->offsets[plane] + fb->pitches[plane] * y +
+  fb->format->cpp[plane] * x;
 }
 
 static inline unsigned long
@@ -85,7 +85,7 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
 {
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
-   unsigned long eba = drm_plane_state_to_eba(state);
+   unsigned long eba = drm_plane_state_to_eba(state, 0);
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
 
@@ -104,7 +104,7 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
 {
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
-   unsigned long eba = drm_plane_state_to_eba(state);
+   unsigned long eba = drm_plane_state_to_eba(state, 0);
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
 
@@ -286,7 +286,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
 fb->format != old_fb->format))
crtc_state->mode_changed = true;
 
-   eba = drm_plane_state_to_eba(state);
+   eba = drm_plane_state_to_eba(state, 0);
 
if (eba & 0x7)
return -EINVAL;
@@ -385,7 +385,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
if (ipu_plane->dp_flow == IPU_DP_FLOW_SYNC_FG)
ipu_dp_set_window_pos(ipu_plane->dp, dst->x1, dst->y1);
 
-   eba = drm_plane_state_to_eba(state);
+   eba = drm_plane_state_to_eba(state, 0);
 
if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
-- 
2.11.0

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

[PATCH v3 1/4] drm: add RGB formats with separate alpha plane

[Philipp Zabel]

Some hardware can read the alpha components separately and then
conditionally fetch color components only for non-zero alpha values.
This patch adds fourcc definitions for two-plane RGB formats with an
8-bit alpha channel on a second plane.

Signed-off-by: Philipp Zabel 
---
Changes since v2:
 - Added "[7:0] A" bit layout information to the alpha plane description.
---
 drivers/gpu/drm/drm_fourcc.c  |  8 
 include/uapi/drm/drm_fourcc.h | 14 ++
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8da8eb6..92bf3306d4b32 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -132,6 +132,8 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_XBGR,.depth = 24, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_RGBX,.depth = 24, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_BGRX,.depth = 24, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGB565_A8,   .depth = 24, 
.num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGR565_A8,   .depth = 24, 
.num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_XRGB2101010, .depth = 30, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_XBGR2101010, .depth = 30, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_RGBX1010102, .depth = 30, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
@@ -144,6 +146,12 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ABGR,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_RGBA,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_BGRA,.depth = 32, 
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGB888_A8,   .depth = 32, 
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGR888_A8,   .depth = 32, 
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_XBGR_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_RGBX_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_BGRX_A8, .depth = 32, 
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_YUV410,  .depth = 0,  
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
{ .format = DRM_FORMAT_YVU410,  .depth = 0,  
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
{ .format = DRM_FORMAT_YUV411,  .depth = 0,  
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 1 },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb8119bf..995c8f9c692fb 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -114,6 +114,20 @@ extern "C" {
 #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
 
 /*
+ * 2 plane RGB + A
+ * index 0 = RGB plane, same format as the corresponding non _A8 format has
+ * index 1 = A plane, [7:0] A
+ */
+#define DRM_FORMAT_XRGB_A8 fourcc_code('X', 'R', 'A', '8')
+#define DRM_FORMAT_XBGR_A8 fourcc_code('X', 'B', 'A', '8')
+#define DRM_FORMAT_RGBX_A8 fourcc_code('R', 'X', 'A', '8')
+#define DRM_FORMAT_BGRX_A8 fourcc_code('B', 'X', 'A', '8')
+#define DRM_FORMAT_RGB888_A8   fourcc_code('R', '8', 'A', '8')
+#define DRM_FORMAT_BGR888_A8   fourcc_code('B', '8', 'A', '8')
+#define DRM_FORMAT_RGB565_A8   fourcc_code('R', '5', 'A', '8')
+#define DRM_FORMAT_BGR565_A8   fourcc_code('B', '5', 'A', '8')
+
+/*
  * 2 plane YCbCr
  * index 0 = Y plane, [7:0] Y
  * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
-- 
2.11.0

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

[PATCH v3 2/4] gpu: ipu-v3: add support for separate alpha channels

[Philipp Zabel]

The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven
by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels.
This allows to reduce memory bandwidth via a conditional read mechanism or
to support planar YUV formats with alpha transparency.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c |  6 +
 drivers/gpu/ipu-v3/ipu-cpmem.c  | 57 +
 include/video/imx-ipu-v3.h  | 22 
 3 files changed, 85 insertions(+)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 8a32ed25a1c29..448043c051e94 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -83,6 +83,12 @@ enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 
drm_fourcc)
case DRM_FORMAT_ABGR:
case DRM_FORMAT_RGBA:
case DRM_FORMAT_BGRA:
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
return IPUV3_COLORSPACE_RGB;
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index b72f725e00b59..114160dfc3ade 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -537,6 +537,43 @@ static const struct ipu_rgb def_bgra_16 = {
 #define UV2_OFFSET(pix, x, y)  ((pix->width * pix->height) +   \
 (pix->width * y) + (x))
 
+#define NUM_ALPHA_CHANNELS 7
+
+/* See Table 37-12. Alpha channels mapping. */
+static int ipu_channel_albm(int ch_num)
+{
+   switch (ch_num) {
+   case IPUV3_CHANNEL_G_MEM_IC_PRP_VF: return 0;
+   case IPUV3_CHANNEL_G_MEM_IC_PP: return 1;
+   case IPUV3_CHANNEL_MEM_FG_SYNC: return 2;
+   case IPUV3_CHANNEL_MEM_FG_ASYNC:return 3;
+   case IPUV3_CHANNEL_MEM_BG_SYNC: return 4;
+   case IPUV3_CHANNEL_MEM_BG_ASYNC:return 5;
+   case IPUV3_CHANNEL_MEM_VDI_PLANE1_COMB: return 6;
+   default:
+   return -EINVAL;
+   }
+}
+
+static void ipu_cpmem_set_separate_alpha(struct ipuv3_channel *ch)
+{
+   struct ipu_soc *ipu = ch->ipu;
+   int albm;
+   u32 val;
+
+   albm = ipu_channel_albm(ch->num);
+   if (albm < 0)
+   return;
+
+   ipu_ch_param_write_field(ch, IPU_FIELD_ALU, 1);
+   ipu_ch_param_write_field(ch, IPU_FIELD_ALBM, albm);
+   ipu_ch_param_write_field(ch, IPU_FIELD_CRE, 1);
+
+   val = ipu_idmac_read(ipu, IDMAC_SEP_ALPHA);
+   val |= BIT(ch->num);
+   ipu_idmac_write(ipu, val, IDMAC_SEP_ALPHA);
+}
+
 int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 drm_fourcc)
 {
switch (drm_fourcc) {
@@ -599,22 +636,28 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
drm_fourcc)
break;
case DRM_FORMAT_RGBA:
case DRM_FORMAT_RGBX:
+   case DRM_FORMAT_RGBX_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgbx_32);
break;
case DRM_FORMAT_BGRA:
case DRM_FORMAT_BGRX:
+   case DRM_FORMAT_BGRX_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgrx_32);
break;
case DRM_FORMAT_BGR888:
+   case DRM_FORMAT_BGR888_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgr_24);
break;
case DRM_FORMAT_RGB888:
+   case DRM_FORMAT_RGB888_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgb_24);
break;
case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_RGB565_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgb_16);
break;
case DRM_FORMAT_BGR565:
+   case DRM_FORMAT_BGR565_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgr_16);
break;
case DRM_FORMAT_ARGB1555:
@@ -636,6 +679,20 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 
drm_fourcc)
return -EINVAL;
}
 
+   switch (drm_fourcc) {
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
+   ipu_ch_param_write_field(ch, IPU_FIELD_WID3, 7);
+   ipu_cpmem_set_separate_alpha(ch);
+   break;
+   default:
+   break;
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(ipu_cpmem_set_fmt);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 899d2b00ad6d4..6af74f0cf161f 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -161,6 +161,28 @@ enum ipu_channel_irq {
 #define IPUV3_CHANNEL_MEM_BG_ASYNC_ALPHA   52
 #define IPUV3_NUM_CHANNELS 64
 
+static inline int ipu_channel_alpha_channel(

Re: [PATCH v2 1/4] drm: add RGB formats with separate alpha plane

[Philipp Zabel]

On Tue, 2017-02-28 at 18:58 +0200, Ville Syrjälä wrote:
> On Tue, Feb 28, 2017 at 03:12:35PM +0100, Philipp Zabel wrote:
> > Some hardware can read the alpha components separately and then
> > conditionally fetch color components only for non-zero alpha values.
> > This patch adds fourcc definitions for two-plane RGB formats with an
> > 8-bit alpha channel on a second plane.
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> > Changes since v1:
> >  - Added a commend that the RGB plane has the same format as the 
> > corresponding
> >RGB format without _A8.
> >  - Added lost drm_format_info fields for RGB565/BGR565/RGB888/BGR888_A8.
> > ---
> >  drivers/gpu/drm/drm_fourcc.c  |  8 
> >  include/uapi/drm/drm_fourcc.h | 14 ++
> >  2 files changed, 22 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 90d2cc8da8eb6..92bf3306d4b32 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -132,6 +132,8 @@ const struct drm_format_info *__drm_format_info(u32 
> > format)
> > { .format = DRM_FORMAT_XBGR,.depth = 24, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_RGBX,.depth = 24, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_BGRX,.depth = 24, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_RGB565_A8,   .depth = 24, 
> > .num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_BGR565_A8,   .depth = 24, 
> > .num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_XRGB2101010, .depth = 30, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_XBGR2101010, .depth = 30, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_RGBX1010102, .depth = 30, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > @@ -144,6 +146,12 @@ const struct drm_format_info *__drm_format_info(u32 
> > format)
> > { .format = DRM_FORMAT_ABGR,.depth = 32, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_RGBA,.depth = 32, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_BGRA,.depth = 32, 
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_RGB888_A8,   .depth = 32, 
> > .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_BGR888_A8,   .depth = 32, 
> > .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_XRGB_A8, .depth = 32, 
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_XBGR_A8, .depth = 32, 
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_RGBX_A8, .depth = 32, 
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_BGRX_A8, .depth = 32, 
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_YUV410,  .depth = 0,  
> > .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
> > { .format = DRM_FORMAT_YVU410,  .depth = 0,  
> > .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
> > { .format = DRM_FORMAT_YUV411,  .depth = 0,  
> > .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 1 },
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index ef20abb8119bf..f0060664ecb6a 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -114,6 +114,20 @@ extern "C" {
> >  #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /* 
> > [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> >  
> >  /*
> > + * 2 plane RGB + A
> > + * index 0 = RGB plane, same format as the corresponding non _A8 format has
> > + * index 1 = A plane
> 
> Please describe the contents fully. Eg. something like:
> "index 1 = A plane, [7:0] A"

Done, thanks.

regards
Philipp

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

Re: [PATCH v4 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v2.

[Maarten Lankhorst]

Op 01-03-17 om 01:49 schreef Laurent Pinchart:
> Hi Maarten,
>
> Thank you for the patch.
>
> On Thursday 16 Feb 2017 15:47:06 Maarten Lankhorst wrote:
>> There are new iterator macros that annotate whether the new or old
>> state should be used. This is better than using a state that depends on
>> whether it's called before or after swap. For clarity, also rename the
>> variables from $obj_state to (old,new)_$obj_state as well.
>>
>> Changes since v1:
>> - Use old/new_*_state for variable names as much as possible. (pinchartl)
>> - Expand commit message.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c | 431 +
>>  1 file changed, 222 insertions(+), 209 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c index 9203f3e933f7..7d432d9a18cf
>> 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> [snip]
>
>> @@ -1929,11 +1926,21 @@ void drm_atomic_helper_cleanup_planes(struct
>> drm_device *dev, struct drm_atomic_state *old_state)
>>  {
>>  struct drm_plane *plane;
>> -struct drm_plane_state *plane_state;
>> +struct drm_plane_state *old_plane_state, *new_plane_state;
>>  int i;
>>
>> -for_each_plane_in_state(old_state, plane, plane_state, i) {
>> +for_each_oldnew_plane_in_state(old_state, plane, old_plane_state,
>> new_plane_state, i) { const struct drm_plane_helper_funcs *funcs;
>> +struct drm_plane_state *plane_state;
>> +
>> +/*
>> + * This might be called before swapping when commit is 
> aborted,
>> + * in which case we have to free the new state.
> s/free/cleanup/
>
> Apart from that,
>
> Reviewed-by: Laurent Pinchart 
>
> You will however need to rebase the series on top of the latest drm-misc as 
> it 
> conflicts (at compile time) with
Yeah I noticed, patch 1 and 5 are affected, will resend those.

Thanks for the review,
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] MAINTAINERS: drm-meson: Update git entries

[Neil Armstrong]

Add the main git entry and the drm-misc experiment git for small
patches.

Cc: Daniel Vetter 
Signed-off-by: Neil Armstrong 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 527d137..98e8d6d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4182,6 +4182,8 @@ W:http://linux-meson.com/
 S: Supported
 F: drivers/gpu/drm/meson/
 F: Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+T: git git://anongit.freedesktop.org/drm/drm-meson
+T: git git://anongit.freedesktop.org/drm/drm-misc
 
 DRM DRIVERS FOR EXYNOS
 M: Inki Dae 
-- 
1.9.1

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

[PATCH v4.1 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v3.

[Maarten Lankhorst]

There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.

Changes since v1:
- Use old/new_*_state for variable names as much as possible. (pinchartl)
- Expand commit message.
Changes since v2:
- Rebase on top of link training patches.
- free -> cleanup (pinchartl)

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_atomic_helper.c | 446 +++-
 1 file changed, 230 insertions(+), 216 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 6b12396f718b..aa1e7609b024 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -63,14 +63,15 @@
  */
 static void
 drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
+   struct drm_plane_state *old_plane_state,
struct drm_plane_state *plane_state,
struct drm_plane *plane)
 {
struct drm_crtc_state *crtc_state;
 
-   if (plane->state->crtc) {
+   if (old_plane_state->crtc) {
crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
plane->state->crtc);
+   
old_plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -92,7 +93,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
 static int handle_conflicting_encoders(struct drm_atomic_state *state,
   bool disable_conflicting_encoders)
 {
-   struct drm_connector_state *conn_state;
+   struct drm_connector_state *new_conn_state;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
struct drm_encoder *encoder;
@@ -104,15 +105,15 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 * part of the state. If the same encoder is assigned to multiple
 * connectors bail out.
 */
-   for_each_connector_in_state(state, connector, conn_state, i) {
+   for_each_new_connector_in_state(state, connector, new_conn_state, i) {
const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
struct drm_encoder *new_encoder;
 
-   if (!conn_state->crtc)
+   if (!new_conn_state->crtc)
continue;
 
if (funcs->atomic_best_encoder)
-   new_encoder = funcs->atomic_best_encoder(connector, 
conn_state);
+   new_encoder = funcs->atomic_best_encoder(connector, 
new_conn_state);
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
@@ -166,20 +167,20 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
goto out;
}
 
-   conn_state = drm_atomic_get_connector_state(state, connector);
-   if (IS_ERR(conn_state)) {
-   ret = PTR_ERR(conn_state);
+   new_conn_state = drm_atomic_get_connector_state(state, 
connector);
+   if (IS_ERR(new_conn_state)) {
+   ret = PTR_ERR(new_conn_state);
goto out;
}
 
DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], 
disabling [CONNECTOR:%d:%s]\n",
 encoder->base.id, encoder->name,
-conn_state->crtc->base.id, 
conn_state->crtc->name,
+new_conn_state->crtc->base.id, 
new_conn_state->crtc->name,
 connector->base.id, connector->name);
 
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
conn_state->crtc);
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
new_conn_state->crtc);
 
-   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+   ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL);
if (ret)
goto out;
 
@@ -245,22 +246,22 @@ steal_encoder(struct drm_atomic_state *state,
 {
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
-   struct drm_connector_state *connector_state;
+   struct drm_connector_state *old_connector_state, *new_connector_state;
int i;
 
-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
struct drm_crtc *en

[PATCH v4.1 4/5] drm/atomic: Convert get_existing_state callers to get_old/new_state, v4.

[Maarten Lankhorst]

This is a straightforward conversion that converts all the users of
get_existing_state in atomic core to use get_old_state or get_new_state

Changes since v1:
- Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state.
Changes since v2:
- Use the correct state in disable_outputs()
Changes since v3:
- Rebase for link status training.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c|  6 ++---
 drivers/gpu/drm/drm_atomic_helper.c | 47 +
 drivers/gpu/drm/drm_blend.c |  3 +--
 drivers/gpu/drm/drm_simple_kms_helper.c |  4 +--
 4 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 236d947011f9..9b892af7811a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1374,8 +1374,8 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
return 0;
 
if (conn_state->crtc) {
-   crtc_state = 
drm_atomic_get_existing_crtc_state(conn_state->state,
-   
conn_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(conn_state->state,
+  conn_state->crtc);
 
crtc_state->connector_mask &=
~(1 << drm_connector_index(conn_state->connector));
@@ -1492,7 +1492,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state 
*state,
 {
struct drm_plane *plane;
 
-   WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
+   WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
 
drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
struct drm_plane_state *plane_state =
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index bc96d31bd388..4e26b73bb0d5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -70,8 +70,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
struct drm_crtc_state *crtc_state;
 
if (old_plane_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
old_plane_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state,
+  
old_plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -80,8 +80,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
}
 
if (plane_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
plane_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -150,7 +149,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
drm_for_each_connector_iter(connector, &conn_iter) {
struct drm_crtc_state *crtc_state;
 
-   if (drm_atomic_get_existing_connector_state(state, connector))
+   if (drm_atomic_get_new_connector_state(state, connector))
continue;
 
encoder = connector->state->best_encoder;
@@ -178,7 +177,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 new_conn_state->crtc->base.id, 
new_conn_state->crtc->name,
 connector->base.id, connector->name);
 
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
new_conn_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc);
 
ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL);
if (ret)
@@ -219,7 +218,7 @@ set_best_encoder(struct drm_atomic_state *state,
 */
WARN_ON(!crtc && encoder != conn_state->best_encoder);
if (crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 
crtc_state->encoder_mask &=
~(1 << 
drm_encoder_index(conn_state->best_encoder));
@@ -230,7 +229,7 @@ set_best_encoder(struct drm_atomic_state *state,
crtc = conn_state->crtc;
WARN_ON(!crtc);
if (crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 
crtc_state->encoder_mask |=
1 << drm_encode

Re: [PATCH 3/3] drivers:gpu: vga :vga_switcheroo.c : Fixed some coding style issues

[Jani Nikula]

On Wed, 01 Mar 2017, Daniel Vetter  wrote:
> On Tue, Feb 28, 2017 at 06:59:52PM +, Joan Jani wrote:
>> Fixed the following style issues
>> 
>> drivers/gpu/vga/vga_switcheroo.c:98: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:99: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:102: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:103: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:129: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:135: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:217: WARNING: line over 80 characters
>> drivers/gpu/vga/vga_switcheroo.c:218: WARNING: line over 80 characters
>> drivers/gpu/vga/vga_switcheroo.c:308: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:340: WARNING: line over 80 characters
>> drivers/gpu/vga/vga_switcheroo.c:1087: WARNING: Block comments use * on 
>> subsequent lines
>> drivers/gpu/vga/vga_switcheroo.c:1087: WARNING: Block comments use a 
>> trailing */ on a separate line
>> 
>> Signed-off-by: Joan Jani 
>
> Applied to drm-misc for 4.12, thanks.

Frankly, I wish you hadn't. The patch changed the perfectly fine:

int vga_switcheroo_register_handler(const struct vga_switcheroo_handler 
*handler,
enum vga_switcheroo_handler_flags_t 
handler_flags)

into horrendous:

int vga_switcheroo_register_handler(
  const struct vga_switcheroo_handler *handler,
  enum vga_switcheroo_handler_flags_t handler_flags)

Just to appease the 80 column rule. Ditto for
vga_switcheroo_register_audio_client. This is why we don't generally
want pure checkpatch fixes on existing files. They don't make things
better.

BR,
Jani.



> -Daniel
>
>> ---
>>  drivers/gpu/vga/vga_switcheroo.c | 28 +++-
>>  1 file changed, 15 insertions(+), 13 deletions(-)
>> 
>> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
>> b/drivers/gpu/vga/vga_switcheroo.c
>> index 5f962bf..3cd153c 100644
>> --- a/drivers/gpu/vga/vga_switcheroo.c
>> +++ b/drivers/gpu/vga/vga_switcheroo.c
>> @@ -95,12 +95,12 @@
>>   * @pwr_state: current power state
>>   * @ops: client callbacks
>>   * @id: client identifier. Determining the id requires the handler,
>> - *  so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
>> - *  and later given their true id in vga_switcheroo_enable()
>> + *  so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
>> + *  and later given their true id in vga_switcheroo_enable()
>>   * @active: whether the outputs are currently switched to this client
>>   * @driver_power_control: whether power state is controlled by the driver's
>> - *  runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
>> - *  interface is a no-op so as not to interfere with runtime pm
>> + *  runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
>> + *  interface is a no-op so as not to interfere with runtime pm
>>   * @list: client list
>>   *
>>   * Registered client. A client can be either a GPU or an audio device on a 
>> GPU.
>> @@ -126,13 +126,13 @@ static DEFINE_MUTEX(vgasr_mutex);
>>  /**
>>   * struct vgasr_priv - vga_switcheroo private data
>>   * @active: whether vga_switcheroo is enabled.
>> - *  Prerequisite is the registration of two GPUs and a handler
>> + *  Prerequisite is the registration of two GPUs and a handler
>>   * @delayed_switch_active: whether a delayed switch is pending
>>   * @delayed_client_id: client to which a delayed switch is pending
>>   * @debugfs_root: directory for vga_switcheroo debugfs interface
>>   * @switch_file: file for vga_switcheroo debugfs interface
>>   * @registered_clients: number of registered GPUs
>> - *  (counting only vga clients, not audio clients)
>> + *  (counting only vga clients, not audio clients)
>>   * @clients: list of registered clients
>>   * @handler: registered handler
>>   * @handler_flags: flags of registered handler
>> @@ -214,8 +214,9 @@ static void vga_switcheroo_enable(void)
>>   *
>>   * Return: 0 on success, -EINVAL if a handler was already registered.
>>   */
>> -int vga_switcheroo_register_handler(const struct vga_switcheroo_handler 
>> *handler,
>> -enum vga_switcheroo_handler_flags_t 
>> handler_flags)
>> +int vga_switcheroo_register_handler(
>> +  const struct vga_switcheroo_handler *handler,
>> +  enum vga_switcheroo_handler_flags_t handler_flags)
>>  {
>>  mutex_lock(&vgasr_mutex);
>>  if (vgasr_priv.handler) {
>> @@ -305,7 +306,7 @@ static int register_client(struct pci_dev *pdev,
>>   * @pdev: client pci device
>>   * @ops: client callbacks
>>   * @driver_power_control: whether power state is controlled by the driver's
>> - *  runtime pm
>> + *  runtime pm
>>   *
>>   * Register vga client (GPU). Enable vga_switcheroo if another GPU and a
>>  

[Bug 193341] AMDGPU: kernel NULL pointer dereferenced with hybrid graphics

[bugzilla-daemon]

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

stefan.ko...@um.si changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #9 from stefan.ko...@um.si ---
With this path is working fine. Thank you. 

Shader heavy games are now rendering twice as fast.

-- 
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 6/6] drm/doc: atomic overview, with graph

[Daniel Vetter]

On Tue, Feb 28, 2017 at 03:48:47PM -0800, Eric Anholt wrote:
> Daniel Vetter  writes:
> 
> > I want to split up a few more things and document some details better
> > (like how exactly to subclass drm_atomic_state). And maybe also split
> > up the helpers a bit per-topic, but this should be a ok-ish start for
> > better atomic overview.
> >
> > One thing I failed at is getting DOT to layout the overview graph how
> > I want it. The highlevel structure I want is:
> >
> > Free-standing State
> >
> > Current State
> >
> > i.e. one over the other. Currently it lays it out side-by-side, but
> > not even that really - "Current State" is somewhat offset below. Makes
> > the graph look like garbage, and also way too wide for proper
> > rendering. Ideas appreciated.
> >
> > Cc: Laurent Pinchart 
> > Cc: Harry Wentland 
> > Signed-off-by: Daniel Vetter 
> 
> Thanks for writing these docs.  I wish I had them back when I was
> starting vc4's atomic code!  With the two little spelling nits fixed,
> 3-5 are:
> 
> Acked-by: Eric Anholt 
> 
> A few copyedits on this one below, but it sounds like you don't want to
> push quite yet while you sort out the rendering.

I've spent quite some time trying to beat DOT into submission, this is the
best I can do. The FIXME really is just a hint for someone with more clue
to maybe make it better, or if not possible at all, what would look better
when doing a proper diagram with .svg or something like that.

Assuming no one knows how to fix this, I'd still like to push it - it's
still better than nothing imo, you just need to look at the picture
full-screen.
-Daniel

> 
> > ---
> >  Documentation/gpu/drm-kms-helpers.rst |  2 +
> >  Documentation/gpu/drm-kms.rst | 85 
> > ++-
> >  2 files changed, 86 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> > b/Documentation/gpu/drm-kms-helpers.rst
> > index 050ebe81d256..ac53c0b893f6 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -42,6 +42,8 @@ Modeset Helper Reference for Common Vtables
> >  .. kernel-doc:: include/drm/drm_modeset_helper_vtables.h
> > :internal:
> >  
> > +.. _drm_atomic_helper:
> > +
> >  Atomic Modeset Helper Functions Reference
> >  =
> >  
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 20378881445f..979cee853bb1 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -189,8 +189,91 @@ multiple times to different objects using 
> > :c:func:`drm_object_attach_property()
> >  .. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
> > :export:
> >  
> > +Atomic Mode Setting
> > +===
> > +
> > +
> > +.. FIXME: The I want the below graph to be laid out so that the 2 subgraph
> > +   clusters are below each another. But I failed.
> > +
> > +.. kernel-render:: DOT
> > +   :alt: Mode Objects and Properties
> > +   :caption: Mode Objects and Properties
> > +
> > +   digraph {
> > +  node [shape=box]
> > +
> > +  subgraph cluster_state {
> > +  style=dashed
> > +  label="Free-standing state"
> > +
> > +  "drm_atomic_state" -> "duplicated drm_plane_state A"
> > +  "drm_atomic_state" -> "duplicated drm_plane_state B"
> > +  "drm_atomic_state" -> "duplicated drm_crtc_state"
> > +  "drm_atomic_state" -> "duplicated drm_connector_state"
> > +  "drm_atomic_state" -> "duplicated driver private state"
> > +  }
> > +
> > +  subgraph cluster_current {
> > +  style=dashed
> > +  label="Current state"
> > +
> > +  "drm_device" -> "drm_plane A"
> > +  "drm_device" -> "drm_plane B"
> > +  "drm_device" -> "drm_crtc"
> > +  "drm_device" -> "drm_connector"
> > +  "drm_device" -> "driver private object"
> > +
> > +  "drm_plane A" -> "drm_plane_state A"
> > +  "drm_plane B" -> "drm_plane_state B"
> > +  "drm_crtc" -> "drm_crtc_state"
> > +  "drm_connector" -> "drm_connector_state"
> > +  "driver private object" -> "driver private state"
> > +  }
> > +
> > +  "drm_atomic_state" -> "drm_device" [label="atomic_commit"]
> > +   }
> > +
> > +Essentially atomic is transactional modeset (including planes) updates, but
> > +compared to the usual transactional approach of try-commit and rollback on
> > +failure atomic modesetting is a bit different:
> 
> Maybe reword:
> 
> "Atomic provides transactional modeset (including planes) updates, but a
> bit differently from the usual transactional approach of try-commit and
> rollback:"
> 
> > +- Firstly, no hardware changes are allowed when the commit would fail. This
> > +  allows us to implement the DRM_MODE_ATOMIC_TEST_ONLY mode, which allows
> > +  userspace to explore whether certain configurations would work or not.
> > +
> > +- This would still allow

Re: [PATCH v4.1 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v3.

[Laurent Pinchart]

Hi Maarten,

Thank you for the resend.

For the whole series,

Tested-by: Laurent Pinchart 

On Wednesday 01 Mar 2017 10:21:26 Maarten Lankhorst wrote:
> There are new iterator macros that annotate whether the new or old
> state should be used. This is better than using a state that depends on
> whether it's called before or after swap. For clarity, also rename the
> variables from $obj_state to (old,new)_$obj_state as well.
> 
> Changes since v1:
> - Use old/new_*_state for variable names as much as possible. (pinchartl)
> - Expand commit message.
> Changes since v2:
> - Rebase on top of link training patches.
> - free -> cleanup (pinchartl)
> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 446 -
>  1 file changed, 230 insertions(+), 216 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 6b12396f718b..aa1e7609b024
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -63,14 +63,15 @@
>   */
>  static void
>  drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
> + struct drm_plane_state *old_plane_state,
>   struct drm_plane_state *plane_state,
>   struct drm_plane *plane)
>  {
>   struct drm_crtc_state *crtc_state;
> 
> - if (plane->state->crtc) {
> + if (old_plane_state->crtc) {
>   crtc_state = drm_atomic_get_existing_crtc_state(state,
> - plane->state-
>crtc);
> + 
old_plane_state->crtc);
> 
>   if (WARN_ON(!crtc_state))
>   return;
> @@ -92,7 +93,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> *state, static int handle_conflicting_encoders(struct drm_atomic_state
> *state, bool disable_conflicting_encoders)
>  {
> - struct drm_connector_state *conn_state;
> + struct drm_connector_state *new_conn_state;
>   struct drm_connector *connector;
>   struct drm_connector_list_iter conn_iter;
>   struct drm_encoder *encoder;
> @@ -104,15 +105,15 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state, * part of the state. If the same encoder is
> assigned to multiple * connectors bail out.
>*/
> - for_each_connector_in_state(state, connector, conn_state, i) {
> + for_each_new_connector_in_state(state, connector, new_conn_state, i) {
>   const struct drm_connector_helper_funcs *funcs =
> connector->helper_private; struct drm_encoder *new_encoder;
> 
> - if (!conn_state->crtc)
> + if (!new_conn_state->crtc)
>   continue;
> 
>   if (funcs->atomic_best_encoder)
> - new_encoder = funcs->atomic_best_encoder(connector, 
conn_state);
> + new_encoder = funcs->atomic_best_encoder(connector, 
new_conn_state);
>   else if (funcs->best_encoder)
>   new_encoder = funcs->best_encoder(connector);
>   else
> @@ -166,20 +167,20 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state, goto out;
>   }
> 
> - conn_state = drm_atomic_get_connector_state(state, connector);
> - if (IS_ERR(conn_state)) {
> - ret = PTR_ERR(conn_state);
> + new_conn_state = drm_atomic_get_connector_state(state, 
connector);
> + if (IS_ERR(new_conn_state)) {
> + ret = PTR_ERR(new_conn_state);
>   goto out;
>   }
> 
>   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], 
disabling
> [CONNECTOR:%d:%s]\n", encoder->base.id, encoder->name,
> -  conn_state->crtc->base.id, conn_state->crtc-
>name,
> +  new_conn_state->crtc->base.id, 
new_conn_state->crtc->name,
>connector->base.id, connector->name);
> 
> - crtc_state = drm_atomic_get_existing_crtc_state(state, 
conn_state->crtc);
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> new_conn_state->crtc);
> 
> - ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
> + ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL);
>   if (ret)
>   goto out;
> 
> @@ -245,22 +246,22 @@ steal_encoder(struct drm_atomic_state *state,
>  {
>   struct drm_crtc_state *crtc_state;
>   struct drm_connector *connector;
> - struct drm_connector_state *connector_state;
> + struct drm_connector_state *old_connector_state, *new_connector_state;
>   int i;
> 
> - for_each_connector_in_state(state, connector, connector_state, i) {
> + for_each_oldnew_connector_in_s

[PATCH 1/4] qxl: drop mode_info.modes & related code.

[Gerd Hoffmann]

very old qxl hardware revisions (predating qxl ksm support by a few
years) supported a fixed list of video modes only.  The list is still
provided by the virtual hardware, for backward compatibility reasons.

The qxl kms driver never ever looks at it, except for dumping it to
the kernel log at load time in case debug logging is enabled.  Drop
that pointless code.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_drv.h |  2 --
 drivers/gpu/drm/qxl/qxl_kms.c | 22 --
 2 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 0c313e5..fe90b36 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -160,8 +160,6 @@ struct qxl_mman {
 };
 
 struct qxl_mode_info {
-   int num_modes;
-   struct qxl_mode *modes;
bool mode_config_initialized;
 
/* pointer to fbdev info structure */
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 2b1e1f3..a9a741c 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -31,19 +31,9 @@
 
 int qxl_log_level;
 
-static void qxl_dump_mode(struct qxl_device *qdev, void *p)
-{
-   struct qxl_mode *m = p;
-   DRM_DEBUG_KMS("%d: %dx%d %d bits, stride %d, %dmm x %dmm, orientation 
%d\n",
- m->id, m->x_res, m->y_res, m->bits, m->stride, m->x_mili,
- m->y_mili, m->orientation);
-}
-
 static bool qxl_check_device(struct qxl_device *qdev)
 {
struct qxl_rom *rom = qdev->rom;
-   int mode_offset;
-   int i;
 
if (rom->magic != 0x4f525851) {
DRM_ERROR("bad rom signature %x\n", rom->magic);
@@ -53,8 +43,6 @@ static bool qxl_check_device(struct qxl_device *qdev)
DRM_INFO("Device Version %d.%d\n", rom->id, rom->update_id);
DRM_INFO("Compression level %d log level %d\n", rom->compression_level,
 rom->log_level);
-   DRM_INFO("Currently using mode #%d, list at 0x%x\n",
-rom->mode, rom->modes_offset);
DRM_INFO("%d io pages at offset 0x%x\n",
 rom->num_io_pages, rom->pages_offset);
DRM_INFO("%d byte draw area at offset 0x%x\n",
@@ -62,14 +50,6 @@ static bool qxl_check_device(struct qxl_device *qdev)
 
qdev->vram_size = rom->surface0_area_size;
DRM_INFO("RAM header offset: 0x%x\n", rom->ram_header_offset);
-
-   mode_offset = rom->modes_offset / 4;
-   qdev->mode_info.num_modes = ((u32 *)rom)[mode_offset];
-   DRM_INFO("rom modes offset 0x%x for %d modes\n", rom->modes_offset,
-qdev->mode_info.num_modes);
-   qdev->mode_info.modes = (void *)((uint32_t *)rom + mode_offset + 1);
-   for (i = 0; i < qdev->mode_info.num_modes; i++)
-   qxl_dump_mode(qdev, qdev->mode_info.modes + i);
return true;
 }
 
@@ -282,7 +262,5 @@ void qxl_device_fini(struct qxl_device *qdev)
iounmap(qdev->ram_header);
iounmap(qdev->rom);
qdev->rom = NULL;
-   qdev->mode_info.modes = NULL;
-   qdev->mode_info.num_modes = 0;
qxl_debugfs_remove_files(qdev);
 }
-- 
1.8.3.1

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

[PATCH 0/4] some qxl fixes and cleanups.

[Gerd Hoffmann]

  Hi,

This little series has some fixes and cleanups for the qxl driver.
Based on drm-misc-next branch.

cheers,
  Gerd

Gerd Hoffmann (4):
  qxl: drop mode_info.modes & related code.
  qxl: limit monitor config read retries
  qxl: read monitors config at boot
  qxl: fix qxl_conn_get_modes

 drivers/gpu/drm/qxl/qxl_display.c | 47 ---
 drivers/gpu/drm/qxl/qxl_drv.h |  2 --
 drivers/gpu/drm/qxl/qxl_kms.c | 22 --
 3 files changed, 29 insertions(+), 42 deletions(-)

-- 
1.8.3.1

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

[PATCH 3/4] qxl: read monitors config at boot

[Gerd Hoffmann]

Try to read the client monitors config at driver load time, even without
explicit notification.  So in case that info was filled before the driver
loaded and we've missed the notifications because of that the settings
will still be used.

With that place we now have to take care to properly handle a empty client
monitors config, so we don't trip over an uninitialized client monitors
config.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_display.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 2b99496..cf99ace 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -81,6 +81,10 @@ static int 
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
   qdev->rom->client_monitors_config_crc);
return MONITORS_CONFIG_BAD_CRC;
}
+   if (!num_monitors) {
+   DRM_DEBUG_KMS("no client monitors configured\n");
+   return status;
+   }
if (num_monitors > qdev->monitors_config->max_allowed) {
DRM_DEBUG_KMS("client monitors list will be truncated: %d < 
%d\n",
  qdev->monitors_config->max_allowed, num_monitors);
@@ -1192,6 +1196,7 @@ int qxl_modeset_init(struct qxl_device *qdev)
qdev_output_init(&qdev->ddev, i);
}
 
+   qxl_display_read_client_monitors_config(qdev);
qdev->mode_info.mode_config_initialized = true;
 
drm_mode_config_reset(&qdev->ddev);
-- 
1.8.3.1

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

[PATCH 4/4] qxl: fix qxl_conn_get_modes

[Gerd Hoffmann]

Call qxl_add_monitors_config_modes() unconditionally.  Do all sanity
checks in that function.

Fix sanity checks.  monitors_config is the current monitor
configuration, whereas client_monitors_config is the configuration
requested by the spice client.  So when filling the mode list, based on
the spice client request, we need to look at
client_monitors_config->count not monitors_config->count.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_display.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index cf99ace..9548bb5 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -202,9 +202,17 @@ static int qxl_add_monitors_config_modes(struct 
drm_connector *connector,
struct drm_display_mode *mode = NULL;
struct qxl_head *head;
 
+   if (!qdev->monitors_config)
+   return 0;
+   if (h >= qdev->monitors_config->max_allowed)
+   return 0;
if (!qdev->client_monitors_config)
return 0;
+   if (h >= qdev->client_monitors_config->count)
+   return 0;
+
head = &qdev->client_monitors_config->heads[h];
+   DRM_DEBUG_KMS("head %d is %dx%d\n", h, head->width, head->height);
 
mode = drm_cvt_mode(dev, head->width, head->height, 60, false, false,
false);
@@ -911,19 +919,13 @@ static void qxl_enc_mode_set(struct drm_encoder *encoder,
 
 static int qxl_conn_get_modes(struct drm_connector *connector)
 {
-   int ret = 0;
-   struct qxl_device *qdev = connector->dev->dev_private;
unsigned pwidth = 1024;
unsigned pheight = 768;
+   int ret = 0;
 
-   DRM_DEBUG_KMS("monitors_config=%p\n", qdev->monitors_config);
-   /* TODO: what should we do here? only show the configured modes for the
-* device, or allow the full list, or both? */
-   if (qdev->monitors_config && qdev->monitors_config->count) {
-   ret = qxl_add_monitors_config_modes(connector, &pwidth, 
&pheight);
-   if (ret < 0)
-   return ret;
-   }
+   ret = qxl_add_monitors_config_modes(connector, &pwidth, &pheight);
+   if (ret < 0)
+   return ret;
ret += qxl_add_common_modes(connector, pwidth, pheight);
return ret;
 }
-- 
1.8.3.1

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

[PATCH 2/4] qxl: limit monitor config read retries

[Gerd Hoffmann]

When reading the monitor config fails, don't retry forever.  If it fails
ten times in a row just give up to avoid the driver hangs.  Also add a
small delay after each attempt, so the host has a chance to complete a
partial update.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_display.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 2cd14be..2b99496 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -157,19 +157,23 @@ static void qxl_update_offset_props(struct qxl_device 
*qdev)
 
 void qxl_display_read_client_monitors_config(struct qxl_device *qdev)
 {
-
struct drm_device *dev = &qdev->ddev;
-   int status;
+   int status, retries;
 
-   status = qxl_display_copy_rom_client_monitors_config(qdev);
-   while (status == MONITORS_CONFIG_BAD_CRC) {
-   qxl_io_log(qdev, "failed crc check for client_monitors_config,"
-" retrying\n");
+   for (retries = 0; retries < 10; retries++) {
status = qxl_display_copy_rom_client_monitors_config(qdev);
+   if (status != MONITORS_CONFIG_BAD_CRC)
+   break;
+   udelay(5);
+   }
+   if (status == MONITORS_CONFIG_BAD_CRC) {
+   qxl_io_log(qdev, "config: bad crc\n");
+   DRM_DEBUG_KMS("ignoring client monitors config: bad crc");
+   return;
}
if (status == MONITORS_CONFIG_UNCHANGED) {
-   qxl_io_log(qdev, "config unchanged\n");
-   DRM_DEBUG("ignoring unchanged client monitors config");
+   qxl_io_log(qdev, "config: unchanged\n");
+   DRM_DEBUG_KMS("ignoring client monitors config: unchanged");
return;
}
 
-- 
1.8.3.1

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

[PATCH] drm/exynos: kill mode_set_nofb callback

[Andrzej Hajda]

All Exynos CRTCs are fully configured by .enable callback. The only users
of mode_set_nofb actually did nothing in their callbacks - they immediately
returned because devices were in suspend state - mode_set_nofb is always
called on disabled device.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 10 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h|  2 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  1 -
 4 files changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 1ffb0b1..3e88269 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -581,7 +581,6 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
 static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable = decon_enable,
.disable = decon_disable,
-   .commit = decon_commit,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.atomic_begin = decon_atomic_begin,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 3279300..0c9a775 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -49,15 +49,6 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
}
 }
 
-static void
-exynos_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
-{
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-
-   if (exynos_crtc->ops->commit)
-   exynos_crtc->ops->commit(exynos_crtc);
-}
-
 static int exynos_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_crtc_state *state)
 {
@@ -93,7 +84,6 @@ static void exynos_crtc_atomic_flush(struct drm_crtc *crtc,
 static const struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
.enable = exynos_drm_crtc_enable,
.disable= exynos_drm_crtc_disable,
-   .mode_set_nofb  = exynos_drm_crtc_mode_set_nofb,
.atomic_check   = exynos_crtc_atomic_check,
.atomic_begin   = exynos_crtc_atomic_begin,
.atomic_flush   = exynos_crtc_atomic_flush,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index c12b390..e52f70a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -115,7 +115,6 @@ struct exynos_drm_plane_config {
  *
  * @enable: enable the device
  * @disable: disable the device
- * @commit: set current hw specific display mode to hw.
  * @enable_vblank: specific driver callback for enabling vblank interrupt.
  * @disable_vblank: specific driver callback for disabling vblank interrupt.
  * @atomic_check: validate state
@@ -130,7 +129,6 @@ struct exynos_drm_crtc;
 struct exynos_drm_crtc_ops {
void (*enable)(struct exynos_drm_crtc *crtc);
void (*disable)(struct exynos_drm_crtc *crtc);
-   void (*commit)(struct exynos_drm_crtc *crtc);
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
int (*atomic_check)(struct exynos_drm_crtc *crtc,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0b74e57..bf5135c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -942,7 +942,6 @@ static void fimd_dp_clock_enable(struct exynos_drm_clk 
*clk, bool enable)
 static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
.enable = fimd_enable,
.disable = fimd_disable,
-   .commit = fimd_commit,
.enable_vblank = fimd_enable_vblank,
.disable_vblank = fimd_disable_vblank,
.atomic_begin = fimd_atomic_begin,
-- 
2.7.4

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

Re: [PATCH 1/2] drm: Add a new connector atomic property for link status

[Daniel Vetter]

On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote:
>  /**
> + * enum drm_link_status - connector's link_status property value
> + *
> + * This enum is used as the connector's link status property value.
> + * It is set to the values defined in uapi.
> + */
> +enum drm_link_status {
> + DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD,
> + DRM_LINK_STATUS_BAD = DRM_MODE_LINK_STATUS_BAD,

We now have a new warning here when building docs. Please fix in a follow-up
patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: Rely on mode_config data for fb_helper initialization

[Daniel Vetter]

On Thu, Feb 02, 2017 at 02:26:40PM -0200, Gabriel Krisman Bertazi wrote:
> Instead of receiving the num_crts as a parameter, we can read it
> directly from the mode_config structure.  I audited the drivers that
> invoke this helper and I believe all of them initialize the mode_config
> struct accordingly, prior to calling the fb_helper.
> 
> I used the following coccinelle hack to make this transformation, except
> for the function headers and comment updates.  The first and second
> rules are split because I couldn't find a way to remove the unused
> temporary variables at the same time I removed the parameter.
> 
> // 
> @r@
> expression A,B,D,E;
> identifier C;
> @@
> (
> - drm_fb_helper_init(A,B,C,D)
> + drm_fb_helper_init(A,B,D)
> |
> - drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
> + drm_fbdev_cma_init_with_funcs(A,B,D,E)
> |
> - drm_fbdev_cma_init(A,B,C,D)
> + drm_fbdev_cma_init(A,B,D)
> )
> 
> @@
> expression A,B,C,D,E;
> @@
> (
> - drm_fb_helper_init(A,B,C,D)
> + drm_fb_helper_init(A,B,D)
> |
> - drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
> + drm_fbdev_cma_init_with_funcs(A,B,D,E)
> |
> - drm_fbdev_cma_init(A,B,C,D)
> + drm_fbdev_cma_init(A,B,D)
> )
> 
> @@
> identifier r.C;
> type T;
> expression V;
> @@
> - T C;
> <...
> when != C
> - C = V;
> ...>
> // 
> 
> Changes since v1:
>  - Rebased on top of the tip of drm-misc-next.
>  - Remove mention to sti since a proper fix got merged.
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Gabriel Krisman Bertazi 
> Reviewed-by: Eric Anholt 

You forgot to update the kernel-doc, building them now generates new
warnings. Please fix in a follow-up patch.

Thanks, Daniel
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  1 -
>  drivers/gpu/drm/arc/arcpgu_drv.c  |  3 +--
>  drivers/gpu/drm/arm/hdlcd_drv.c   |  2 +-
>  drivers/gpu/drm/arm/malidp_drv.c  |  2 +-
>  drivers/gpu/drm/armada/armada_fbdev.c |  2 +-
>  drivers/gpu/drm/ast/ast_fb.c  |  3 +--
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c  |  1 -
>  drivers/gpu/drm/bochs/bochs_fbdev.c   |  3 +--
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c |  2 +-
>  drivers/gpu/drm/drm_fb_cma_helper.c   | 15 +++
>  drivers/gpu/drm/drm_fb_helper.c   | 10 +-
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  5 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c |  2 +-
>  drivers/gpu/drm/gma500/framebuffer.c  |  2 +-
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  3 +--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c   |  3 +--
>  drivers/gpu/drm/i915/intel_fbdev.c|  3 +--
>  drivers/gpu/drm/imx/imx-drm-core.c|  3 +--
>  drivers/gpu/drm/meson/meson_drv.c |  1 -
>  drivers/gpu/drm/mgag200/mgag200_fb.c  |  2 +-
>  drivers/gpu/drm/msm/msm_fbdev.c   |  3 +--
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c   |  3 +--
>  drivers/gpu/drm/omapdrm/omap_fbdev.c  |  3 +--
>  drivers/gpu/drm/qxl/qxl_fb.c  |  1 -
>  drivers/gpu/drm/radeon/radeon_fb.c|  1 -
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  5 +
>  drivers/gpu/drm/sti/sti_drv.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_framebuffer.c |  4 +---
>  drivers/gpu/drm/tegra/fb.c|  2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c   |  3 +--
>  drivers/gpu/drm/udl/udl_fb.c  |  3 +--
>  drivers/gpu/drm/vc4/vc4_kms.c |  1 -
>  drivers/gpu/drm/virtio/virtgpu_fb.c   |  1 -
>  drivers/gpu/drm/zte/zx_drm_drv.c  |  2 +-
>  include/drm/drm_fb_cma_helper.h   |  7 +++
>  include/drm/drm_fb_helper.h   |  3 +--
>  38 files changed, 43 insertions(+), 73 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 838943d0962e..36ce3cac81ba 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -374,7 +374,6 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
>   &amdgpu_fb_helper_funcs);
>  
>   ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper,
> -  adev->mode_info.num_crtc,
>AMDGPUFB_CONN_LIMIT);
>   if (ret) {
>   kfree(rfbdev);
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c 
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 0b6eaa49a1db..8d8344ed655e 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -135,8 +135,7 @@ static int arcpgu_load(struct drm_device *drm)
>   drm_kms_helper_poll_init(drm);
>  
>   arcpgu->fbdev = dr

[PULL] topic/designware-baytrail for 4.12

[Daniel Vetter]

Hi all,

topic/designware-baytrail-2017-03-01:
Baytrail PMIC vs. PMU race fixes from Hans de Goede

I opted to put all the patches for all subsystems into the topic branches,
so that if needed, each subsystem can apply refactorings to the entire
thing. Which might be needed since we're very early in the 4.12 cycle.

This has baked for a few days in the drm-intel CI and looks good afaics.
I'll pull this into drm-intel.git for 4.12, feel free to pull into any
other subsystem where needed.

Cheers, Daniel


The following changes since commit 64a577196d66b44e37384bc5c4d78c61f59d5b2a:

  lib/Kconfig: make PRIME_NUMBERS not user selectable. (2017-02-24 12:11:21 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel 
tags/topic/designware-baytrail-2017-03-01

for you to fetch changes up to ca9b131b63aaf21419725bcf90497877d6bf6271:

  drm/i915: Listen for PMIC bus access notifications (2017-02-26 21:23:13 +0100)


Baytrail PMIC vs. PMU race fixes from Hans de Goede


Hans de Goede (12):
  x86/platform/intel/iosf_mbi: Add a mutex for P-Unit access
  x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier
  i2c: designware: Rename accessor_flags to flags
  i2c: designware-baytrail: Pass dw_i2c_dev into helper functions
  i2c: designware-baytrail: Only check iosf_mbi_available() for shared hosts
  i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while 
holding the punit semaphore
  i2c: designware-baytrail: Fix race when resetting the semaphore
  i2c: designware-baytrail: Add support for cherrytrail
  i2c: designware-baytrail: Acquire P-Unit access on bus acquire
  i2c: designware-baytrail: Call pmic_bus_access_notifier_chain
  drm/i915: Add intel_uncore_suspend / resume functions
  drm/i915: Listen for PMIC bus access notifications

 arch/x86/include/asm/iosf_mbi.h  | 85 
 arch/x86/platform/intel/iosf_mbi.c   | 49 
 drivers/gpu/drm/i915/Kconfig |  1 +
 drivers/gpu/drm/i915/i915_drv.c  |  6 +-
 drivers/gpu/drm/i915/i915_drv.h  |  7 +--
 drivers/gpu/drm/i915/intel_uncore.c  | 53 +++--
 drivers/i2c/busses/i2c-designware-baytrail.c | 83 +++
 drivers/i2c/busses/i2c-designware-core.c | 14 ++---
 drivers/i2c/busses/i2c-designware-core.h | 13 -
 drivers/i2c/busses/i2c-designware-pcidrv.c   | 26 ++---
 drivers/i2c/busses/i2c-designware-platdrv.c  |  8 ++-
 11 files changed, 288 insertions(+), 57 deletions(-)

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

Re: [PATCH v2 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
> On 17-02-28 12:18:39, Jason Ekstrand wrote:

> >I've said it before but reading through Ben's patches again make me want to
> >be peskier about it.  I would really like the UABI to treat the CCS as if
> >it's Y-tiled with a tile size of 128B x 32 rows.  Why?  Because this is
> >what all the docs say it is.  From the display docs for "Color Control
> >Surface":
> >
> >"The Color Control Surface (CCS) contains the compression status of the
> >cache-line pairs. The
> >compression state of the cache-line pair is specified by 2 bits in the CCS.
> >Each CCS cache-line represents
> >an area on the main surface of 16 x16 sets of 128 byte Y-tiled
> >cache-line-pairs. CCS is always Y tiled."
> >
> >This contains 95% of the information needed to know the relation between
> >the CCS and the main surface.  The other 5% (which is badly documented) is
> >that cache line pairs are horizontally adjacent.  This gives a relationship
> >of one cache line in the CCS maps to 32x64 cache lines in the main surface.
> >
> >But it's not actually Y-tiled?  Of course not.  I've worked out the exact
> >tiling and it looks something like Y but isn't quite the same.  However,
> >this isn't unique to CCS.  Stencil (W-tiled), HiZ, and gen7-8
> >single-sampled MCS also each have their own tiling (Haswell MCS is
> >especially exotic) but the docs call all of them Y-tiled and I think the
> >hardware internally treats them as Y-tiled with the cache lines shuffled
> >around a bit.
> >
> >Given the fact that they seem to like to change the MCS/CCS tiling around
> >on every hardware generation, I'm reluctant to base UABI on the fact that
> >the CCS appears to have 64x64 "pixels" per tile with each "pixel"
> >corresponding to 16x8 pixels in the color surface.  That's not what we had
> >on any previous gen and may change on gen10 for no aparent reason.  I'd
> >much rather base it on Y-tiling and a relationship between cache lines
> >which, even if they change the exact swizzle on gen10, will probably remain
> >the same.  (For the gen7-8 analogue of CCS, they changed the tiling every
> >generation but the relationship of one MCS cache line maps to 32x128 color
> >cache lines remained the same).
> >
> >Ok, I've said my peice.  If we have to divide by 2 in userspace, we won't
> >die, but I'd like to get the UABI right before we chissel it in stone.
> >
> >--Jason
> >
> >
> 
> I vote we make the stride in units of tiles when we have the CCS modifier.

That won't fly with the KMS API. I suppose I could make the tile 128 bytes
wide by swapping the "1 byte == 16x8 pixels" notion with a
"1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore,
but I guess no one really cares.

> 
> >> +   /* fall through */
> >> case I915_FORMAT_MOD_Yf_TILED:
> >> /*
> >>  * Bspec seems to suggest that the Yf tile width would
> >> @@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const
> >> struct drm_framebuffer *fb,
> >> struct drm_i915_private *dev_priv = to_i915(fb->dev);
> >>
> >> /* AUX_DIST needs only 4K alignment */
> >> -   if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
> >> +   if (plane == 1)
> >> return 4096;
> >>
> >> switch (fb->modifier) {
> >> @@ -2166,6 +2174,8 @@ static unsigned int intel_surf_alignment(const
> >> struct drm_framebuffer *fb,
> >> if (INTEL_GEN(dev_priv) >= 9)
> >> return 256 * 1024;
> >> return 0;
> >> +   case I915_FORMAT_MOD_Y_TILED_CCS:
> >> +   case I915_FORMAT_MOD_Yf_TILED_CCS:
> >> case I915_FORMAT_MOD_Y_TILED:
> >> case I915_FORMAT_MOD_Yf_TILED:
> >> return 1 * 1024 * 1024;
> >> @@ -2472,6 +2482,7 @@ static unsigned int 
> >> intel_fb_modifier_to_tiling(uint64_t
> >> fb_modifier)
> >> case I915_FORMAT_MOD_X_TILED:
> >> return I915_TILING_X;
> >> case I915_FORMAT_MOD_Y_TILED:
> >> +   case I915_FORMAT_MOD_Y_TILED_CCS:
> >> return I915_TILING_Y;
> >> default:
> >> return I915_TILING_NONE;
> >> @@ -2536,6 +2547,35 @@ intel_fill_fb_info(struct drm_i915_private
> >> *dev_priv,
> >>
> >> intel_fb_offset_to_xy(&x, &y, fb, i);
> >>
> >> +   if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> >> +fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) && i ==
> >> 1) {
> >> +   int main_x, main_y;
> >> +   int ccs_x, ccs_y;
> >> +
> >> +   /*
> >> +* Each byte of CCS corresponds to a 16x8 area of
> >> the main surface, and
> >> +* each CCS tile is 64x64 bytes.
> >> +*/
> >> +   ccs_x = (x * 16) % (64 * 16);
> >> +   ccs_y = (y * 8) % (64 * 8);
> >> +

Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

[Laurent Pinchart]

Hi Jose,

On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> On 05-01-2017 12:29, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> >> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> >>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
>  Instead of spreading version-dependent PHY power handling code around,
>  group it in two functions to power the PHY on and off and use them
>  through the driver.
>  
>  Powering off the PHY at the beginning of the setup phase is currently
>  split in two locations for first and second generation PHYs, group all
>  the operations in the dw_hdmi_phy_init() function.
> >>> 
> >>> This changes the behaviour of the driver.
> >>> 
>  +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>  +{
>  +if (hdmi->phy->gen == 1) {
>  +dw_hdmi_phy_enable_tmds(hdmi, 0);
>  +dw_hdmi_phy_enable_powerdown(hdmi, true);
>  +} else {
>  +dw_hdmi_phy_gen2_txpwron(hdmi, 0);
>  +dw_hdmi_phy_gen2_pddq(hdmi, 1);
>  +}
>  +}
>  @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
>  *hdmi)
>   if (!hdmi->phy_enabled)
>   return;
>  
>  -dw_hdmi_phy_enable_tmds(hdmi, 0);
>  -dw_hdmi_phy_enable_powerdown(hdmi, true);
>  -
>  +dw_hdmi_phy_power_off(hdmi);
> >>> 
> >>> This makes dw_hdmi_phy_disable() power down a gen2 phy.
> >>> 
> >>> The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> >>> gen2 phy.  I've been carrying this change for a while, which I've had
> >>> to revert (and finally expunge), as it causes problems on iMX6:
> >>> 
> >>> @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> >>> *hdmi)
> >>> if (!hdmi->phy_enabled)
> >>> return;
> >>> 
> >>> +   /* Actually set the phy into low power mode */
> >>> +   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> >>> +
> >>> +   /* FIXME: We should wait for TX_READY to be deasserted */
> >>> +
> >>> +   dw_hdmi_phy_gen2_pddq(hdmi, 1);
> >>> +
> >>> +   /* This appears to have no effect on iMX6 */
> >>> dw_hdmi_phy_enable_tmds(hdmi, 0);
> >>> dw_hdmi_phy_enable_powerdown(hdmi, true);
> >>> 
> >>> So, I think your change here will cause problems for iMX6.
> >>> 
> >>> From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> >>> bouncing when the PHY is powered down.  I can't promise when I'll be
> >>> able to check for that again.
> >> 
> >> Indeed TX_READY must be low before asserting pddq.
> > 
> > The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
> > output signal, but there seems to be no HDMI TX register from which its
> > state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
> > through I2C ? How long is the PHY expected to take to set TX_READY to 0 ?
> 
> TX_READY can be read from register 0x1A of phy, BIT(2) (through
> I2C). Not sure if same offset for all phys though.

I have been told that another option is to poll the TX_PHY_LOCK bit in the 
phy_stat0 register. That would be a simpler solution that doesn't require I2C 
access. Could you confirm (or disconfirm) this ?

> >> HPD and RXSENSE should work in power down mode by enabling enhpdrxsense
> >> bit in phy_conf0 BUT to enter power down you must disable TX_PWRON,
> >> enhpdrxsense and enable PDDQ and PHY_RESET. Only after doing this (and
> >> consequently entering power down mode) you can enable again enhpdrxsense.
> > 
> > Thanks, I'll give it a try.

-- 
Regards,

Laurent Pinchart

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

[Bug 99450] [amdgpu] Payday 2 visual glitches on some models

[bugzilla-daemon]

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

Hugo Posnic  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #6 from Hugo Posnic  ---
It's fixed. Thank you all!

-- 
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/atmel-hlcdc: Fix suspend/resume implementation

[Boris Brezillon]

The current suspend resume implementation is assuming register values are
kept when entering suspend, which is no longer the case with the
suspend-to-RAM on the sama5d2.

While at it, switch to the generic infrastructure to enter suspend mode
(drm_atomic_helper_suspend/resume()).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 33 --
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 31 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |  8 ---
 3 files changed, 21 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 6b50fb706c0e..53bfa56ca47a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -55,14 +55,12 @@ drm_crtc_state_to_atmel_hlcdc_crtc_state(struct 
drm_crtc_state *state)
  * @hlcdc: pointer to the atmel_hlcdc structure provided by the MFD device
  * @event: pointer to the current page flip event
  * @id: CRTC id (returned by drm_crtc_index)
- * @enabled: CRTC state
  */
 struct atmel_hlcdc_crtc {
struct drm_crtc base;
struct atmel_hlcdc_dc *dc;
struct drm_pending_vblank_event *event;
int id;
-   bool enabled;
 };
 
 static inline struct atmel_hlcdc_crtc *
@@ -158,9 +156,6 @@ static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
struct regmap *regmap = crtc->dc->hlcdc->regmap;
unsigned int status;
 
-   if (!crtc->enabled)
-   return;
-
drm_crtc_vblank_off(c);
 
pm_runtime_get_sync(dev->dev);
@@ -186,8 +181,6 @@ static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
pm_runtime_allow(dev->dev);
 
pm_runtime_put_sync(dev->dev);
-
-   crtc->enabled = false;
 }
 
 static void atmel_hlcdc_crtc_enable(struct drm_crtc *c)
@@ -197,9 +190,6 @@ static void atmel_hlcdc_crtc_enable(struct drm_crtc *c)
struct regmap *regmap = crtc->dc->hlcdc->regmap;
unsigned int status;
 
-   if (crtc->enabled)
-   return;
-
pm_runtime_get_sync(dev->dev);
 
pm_runtime_forbid(dev->dev);
@@ -226,29 +216,6 @@ static void atmel_hlcdc_crtc_enable(struct drm_crtc *c)
pm_runtime_put_sync(dev->dev);
 
drm_crtc_vblank_on(c);
-
-   crtc->enabled = true;
-}
-
-void atmel_hlcdc_crtc_suspend(struct drm_crtc *c)
-{
-   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
-
-   if (crtc->enabled) {
-   atmel_hlcdc_crtc_disable(c);
-   /* save enable state for resume */
-   crtc->enabled = true;
-   }
-}
-
-void atmel_hlcdc_crtc_resume(struct drm_crtc *c)
-{
-   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
-
-   if (crtc->enabled) {
-   crtc->enabled = false;
-   atmel_hlcdc_crtc_enable(c);
-   }
 }
 
 #define ATMEL_HLCDC_RGB444_OUTPUT  BIT(0)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 970bd87d7cce..0fdb6ad0469f 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -810,31 +810,32 @@ static int atmel_hlcdc_dc_drm_remove(struct 
platform_device *pdev)
 static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
-   struct drm_crtc *crtc;
+   struct atmel_hlcdc_dc *dc = drm_dev->dev_private;
+   struct regmap *regmap = dc->hlcdc->regmap;
+   struct drm_atomic_state *state;
+
+   state = drm_atomic_helper_suspend(drm_dev);
+   if (IS_ERR(state))
+   return PTR_ERR(state);
 
-   if (pm_runtime_suspended(dev))
-   return 0;
+   dc->suspend.state = state;
+
+   regmap_read(regmap, ATMEL_HLCDC_IMR, &dc->suspend.imr);
+   regmap_write(regmap, ATMEL_HLCDC_IDR, dc->suspend.imr);
+   clk_disable_unprepare(dc->hlcdc->periph_clk);
 
-   drm_modeset_lock_all(drm_dev);
-   list_for_each_entry(crtc, &drm_dev->mode_config.crtc_list, head)
-   atmel_hlcdc_crtc_suspend(crtc);
-   drm_modeset_unlock_all(drm_dev);
return 0;
 }
 
 static int atmel_hlcdc_dc_drm_resume(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
-   struct drm_crtc *crtc;
+   struct atmel_hlcdc_dc *dc = drm_dev->dev_private;
 
-   if (pm_runtime_suspended(dev))
-   return 0;
+   clk_prepare_enable(dc->hlcdc->periph_clk);
+   regmap_write(dc->hlcdc->regmap, ATMEL_HLCDC_IER, dc->suspend.imr);
 
-   drm_modeset_lock_all(drm_dev);
-   list_for_each_entry(crtc, &drm_dev->mode_config.crtc_list, head)
-   atmel_hlcdc_crtc_resume(crtc);
-   drm_modeset_unlock_all(drm_dev);
-   return 0;
+   return drm_atomic_helper_resume(drm_dev, dc->suspend.state);
 }
 #endif
 
diff --git a/drivers/gpu/dr

[Bug 99784] AMD 7470m When VGA plugged into laptop, only one monitor working at a time

[bugzilla-daemon]

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

--- Comment #6 from lazane...@gmail.com ---
Problem persists with DRM 2.49.0 / 4.10.1-041001-lowlatency, LLVM 3.9.1

-- 
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: Update git entries for drivers in drm-misc

[Shawn Guo]

On Tue, Feb 28, 2017 at 08:36:57PM +0100, Daniel Vetter wrote:
> It's still just an experiment, but one lesson learned from drm-misc is
> that not updating MAINTAINERS just leads to confusion. And this is
> easy to revert.
...
> Cc: Shawn Guo 
> Signed-off-by: Daniel Vetter 
...
> @@ -4476,6 +4479,7 @@ L:  dri-devel@lists.freedesktop.org
>  S:   Maintained
>  F:   drivers/gpu/drm/zte/
>  F:   Documentation/devicetree/bindings/display/zte,vou.txt
> +T:   git git://anongit.freedesktop.org/drm/drm-misc

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

Re: [PATCH] drm/atmel-hlcdc: Fix suspend/resume implementation

[Daniel Vetter]

On Wed, Mar 01, 2017 at 01:31:01PM +0100, Boris Brezillon wrote:
> The current suspend resume implementation is assuming register values are
> kept when entering suspend, which is no longer the case with the
> suspend-to-RAM on the sama5d2.
> 
> While at it, switch to the generic infrastructure to enter suspend mode
> (drm_atomic_helper_suspend/resume()).
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 33 
> --
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 31 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |  8 ---
>  3 files changed, 21 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 6b50fb706c0e..53bfa56ca47a 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -55,14 +55,12 @@ drm_crtc_state_to_atmel_hlcdc_crtc_state(struct 
> drm_crtc_state *state)
>   * @hlcdc: pointer to the atmel_hlcdc structure provided by the MFD device
>   * @event: pointer to the current page flip event
>   * @id: CRTC id (returned by drm_crtc_index)
> - * @enabled: CRTC state
>   */
>  struct atmel_hlcdc_crtc {
>   struct drm_crtc base;
>   struct atmel_hlcdc_dc *dc;
>   struct drm_pending_vblank_event *event;
>   int id;
> - bool enabled;
>  };
>  
>  static inline struct atmel_hlcdc_crtc *
> @@ -158,9 +156,6 @@ static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
>   struct regmap *regmap = crtc->dc->hlcdc->regmap;
>   unsigned int status;
>  
> - if (!crtc->enabled)
> - return;

Removing bail-out code like this and switching to atomic s/r helpers is
very much how this (= atomic helpers) is supposed to work. Yay for another
driver following the common code pattern.

Acked-by: Daniel Vetter 

> -
>   drm_crtc_vblank_off(c);
>  
>   pm_runtime_get_sync(dev->dev);
> @@ -186,8 +181,6 @@ static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
>   pm_runtime_allow(dev->dev);
>  
>   pm_runtime_put_sync(dev->dev);
> -
> - crtc->enabled = false;
>  }
>  
>  static void atmel_hlcdc_crtc_enable(struct drm_crtc *c)
> @@ -197,9 +190,6 @@ static void atmel_hlcdc_crtc_enable(struct drm_crtc *c)
>   struct regmap *regmap = crtc->dc->hlcdc->regmap;
>   unsigned int status;
>  
> - if (crtc->enabled)
> - return;
> -
>   pm_runtime_get_sync(dev->dev);
>  
>   pm_runtime_forbid(dev->dev);
> @@ -226,29 +216,6 @@ static void atmel_hlcdc_crtc_enable(struct drm_crtc *c)
>   pm_runtime_put_sync(dev->dev);
>  
>   drm_crtc_vblank_on(c);
> -
> - crtc->enabled = true;
> -}
> -
> -void atmel_hlcdc_crtc_suspend(struct drm_crtc *c)
> -{
> - struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
> -
> - if (crtc->enabled) {
> - atmel_hlcdc_crtc_disable(c);
> - /* save enable state for resume */
> - crtc->enabled = true;
> - }
> -}
> -
> -void atmel_hlcdc_crtc_resume(struct drm_crtc *c)
> -{
> - struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
> -
> - if (crtc->enabled) {
> - crtc->enabled = false;
> - atmel_hlcdc_crtc_enable(c);
> - }
>  }
>  
>  #define ATMEL_HLCDC_RGB444_OUTPUTBIT(0)
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 970bd87d7cce..0fdb6ad0469f 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -810,31 +810,32 @@ static int atmel_hlcdc_dc_drm_remove(struct 
> platform_device *pdev)
>  static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
>  {
>   struct drm_device *drm_dev = dev_get_drvdata(dev);
> - struct drm_crtc *crtc;
> + struct atmel_hlcdc_dc *dc = drm_dev->dev_private;
> + struct regmap *regmap = dc->hlcdc->regmap;
> + struct drm_atomic_state *state;
> +
> + state = drm_atomic_helper_suspend(drm_dev);
> + if (IS_ERR(state))
> + return PTR_ERR(state);
>  
> - if (pm_runtime_suspended(dev))
> - return 0;
> + dc->suspend.state = state;
> +
> + regmap_read(regmap, ATMEL_HLCDC_IMR, &dc->suspend.imr);
> + regmap_write(regmap, ATMEL_HLCDC_IDR, dc->suspend.imr);
> + clk_disable_unprepare(dc->hlcdc->periph_clk);
>  
> - drm_modeset_lock_all(drm_dev);
> - list_for_each_entry(crtc, &drm_dev->mode_config.crtc_list, head)
> - atmel_hlcdc_crtc_suspend(crtc);
> - drm_modeset_unlock_all(drm_dev);
>   return 0;
>  }
>  
>  static int atmel_hlcdc_dc_drm_resume(struct device *dev)
>  {
>   struct drm_device *drm_dev = dev_get_drvdata(dev);
> - struct drm_crtc *crtc;
> + struct atmel_hlcdc_dc *dc = drm_dev->dev_private;
>  
> - if (pm_runtime_suspended(dev))
> - return 0;
> + clk_prep

[PATCH] drm: virtio: use kmem_cache

[Gerd Hoffmann]

Just use kmem_cache instead of rolling
our own, limited implementation.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h |  4 +--
 drivers/gpu/drm/virtio/virtgpu_vq.c  | 57 +++-
 2 files changed, 11 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 2f76673..4e66e35 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -178,9 +178,7 @@ struct virtio_gpu_device {
 
struct virtio_gpu_queue ctrlq;
struct virtio_gpu_queue cursorq;
-   struct list_head free_vbufs;
-   spinlock_t free_vbufs_lock;
-   void *vbufs;
+   struct kmem_cache *vbufs;
bool vqs_ready;
 
struct idr  resource_idr;
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 43ea0dc..472e349 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -74,51 +74,19 @@ void virtio_gpu_cursor_ack(struct virtqueue *vq)
 
 int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev)
 {
-   struct virtio_gpu_vbuffer *vbuf;
-   int i, size, count = 16;
-   void *ptr;
-
-   INIT_LIST_HEAD(&vgdev->free_vbufs);
-   spin_lock_init(&vgdev->free_vbufs_lock);
-   count += virtqueue_get_vring_size(vgdev->ctrlq.vq);
-   count += virtqueue_get_vring_size(vgdev->cursorq.vq);
-   size = count * VBUFFER_SIZE;
-   DRM_INFO("virtio vbuffers: %d bufs, %zdB each, %dkB total.\n",
-count, VBUFFER_SIZE, size / 1024);
-
-   vgdev->vbufs = kzalloc(size, GFP_KERNEL);
+   vgdev->vbufs = kmem_cache_create("virtio-gpu-vbufs",
+VBUFFER_SIZE,
+__alignof__(struct virtio_gpu_vbuffer),
+0, NULL);
if (!vgdev->vbufs)
return -ENOMEM;
-
-   for (i = 0, ptr = vgdev->vbufs;
-i < count;
-i++, ptr += VBUFFER_SIZE) {
-   vbuf = ptr;
-   list_add(&vbuf->list, &vgdev->free_vbufs);
-   }
return 0;
 }
 
 void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev)
 {
-   struct virtio_gpu_vbuffer *vbuf;
-   int i, count = 0;
-
-   count += virtqueue_get_vring_size(vgdev->ctrlq.vq);
-   count += virtqueue_get_vring_size(vgdev->cursorq.vq);
-
-   spin_lock(&vgdev->free_vbufs_lock);
-   for (i = 0; i < count; i++) {
-   if (WARN_ON(list_empty(&vgdev->free_vbufs))) {
-   spin_unlock(&vgdev->free_vbufs_lock);
-   return;
-   }
-   vbuf = list_first_entry(&vgdev->free_vbufs,
-   struct virtio_gpu_vbuffer, list);
-   list_del(&vbuf->list);
-   }
-   spin_unlock(&vgdev->free_vbufs_lock);
-   kfree(vgdev->vbufs);
+   kmem_cache_destroy(vgdev->vbufs);
+   vgdev->vbufs = NULL;
 }
 
 static struct virtio_gpu_vbuffer*
@@ -128,12 +96,9 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev)
 {
struct virtio_gpu_vbuffer *vbuf;
 
-   spin_lock(&vgdev->free_vbufs_lock);
-   BUG_ON(list_empty(&vgdev->free_vbufs));
-   vbuf = list_first_entry(&vgdev->free_vbufs,
-   struct virtio_gpu_vbuffer, list);
-   list_del(&vbuf->list);
-   spin_unlock(&vgdev->free_vbufs_lock);
+   vbuf = kmem_cache_alloc(vgdev->vbufs, GFP_KERNEL);
+   if (IS_ERR(vbuf))
+   return ERR_CAST(vbuf);
memset(vbuf, 0, VBUFFER_SIZE);
 
BUG_ON(size > MAX_INLINE_CMD_SIZE);
@@ -208,9 +173,7 @@ static void free_vbuf(struct virtio_gpu_device *vgdev,
if (vbuf->resp_size > MAX_INLINE_RESP_SIZE)
kfree(vbuf->resp_buf);
kfree(vbuf->data_buf);
-   spin_lock(&vgdev->free_vbufs_lock);
-   list_add(&vbuf->list, &vgdev->free_vbufs);
-   spin_unlock(&vgdev->free_vbufs_lock);
+   kmem_cache_free(vgdev->vbufs, vbuf);
 }
 
 static void reclaim_vbufs(struct virtqueue *vq, struct list_head *reclaim_list)
-- 
1.8.3.1

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

Re: [PATCH] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

[Ville Syrjälä]

On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote:
> Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
> 1.1.
> 
> When a sink that supports deep color is connected to the output, the
> receiver will send EDIDs that advertise this capability, even if it
> isn't possible with HDMI versions earlier than 1.3.
> 
> Currently the kernel is assuming that deep color is possible and the
> sink displays an error.
> 
> This quirk will make sure that deep color isn't used with this
> particular receiver.
> 
> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> References: https://bugs.freedesktop.org/show_bug.cgi?id=99869
> Signed-off-by: Tomeu Vizoso 

Cc: sta...@vger.kernel.org
Cc: Matt Horan 
Tested-by: Matt Horan 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 24e7b282f16c..d994ccf94f88 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -148,6 +148,9 @@ static const struct edid_quirk {
>  
>   /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
>   { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
> +
> + /* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
> + { "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
>  };
>  
>  /*
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup

[Daniel Vetter]

On Fri, Jan 27, 2017 at 03:29:29PM +0100, Daniel Vetter wrote:
> On Fri, Jan 27, 2017 at 03:23:43PM +0100, Noralf Trønnes wrote:
> > 
> > Den 27.01.2017 08.49, skrev Daniel Vetter:
> > > On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote:
> > > > This patchset removes the need for drivers to clean up their debugfs
> > > > files on exit. It is done automatically in drm_debugfs_cleanup().
> > > > This funtion is also called should the driver error out in it's
> > > > drm_driver.debugfs_init callback.
> > > > 
> > > > Two drivers still use drm_debugfs_remove_files():
> > > > - tegra in it's connectors, not sure if I can remove it.
> > > I read through them, and they're removed on the component device nodes
> > > stuff. That looks somewhat fishy from a lifetime point of view, and I
> > > think removing all that code would be better, too.
> > > 
> > > > - qxl because it's debugfs files list is part of struct qxl_device which
> > > >is freed on unload before drm_minor_unregister() is called cleaning 
> > > > debugfs.
> > > In -next qxl is already demidlayered and there's no longer an unload hook.
> > > This should be all safe ... why is it not?
> > 
> > My bad, I fetched linux-next a few days ago and figured it was
> > up-to-date-enough. Duh, I should have known better after following drm for
> > a year now, it is constantly changing, no pauses.
> > 
> > Can you please ping me when you have pulled driver patches and I'll respin
> > msm, tegra and qxl (and others if necessary), and remove the hook.
> > It's much easier for me to do a small patchset, it's really a strain to get
> > everything lined up correctly with big changes. I didn't have that patch
> > juggling class when in school, so I'm late to the game :-)
> 
> You're doing great with the patch juggling :-) I've just made a pass
> through the series and merge what's already reviewed/acked.

Ok, pulled in the remaining patch (I hope, pls ping if I missed one). We
have only a few debugfs_remove calls left, and I think it's safe to remove
them all too. Up to do that too? Then we could remove the export, to make
sure no new driver gets this wrong ...

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

[PATCH] drm: Fix the kernel doc warning for drm_link_status

[Manasi Navare]

This fixes the kernel doc warning that was introduced in
the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
atomic property for link status")'. Description has
been added for the enum values.

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
---
 include/drm/drm_connector.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ccc0770..fabb35a 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -94,6 +94,11 @@ enum subpixel_order {
  *
  * This enum is used as the connector's link status property value.
  * It is set to the values defined in uapi.
+ *
+ * @DRM_LINK_STATUS_GOOD: DP Link is Good as a result of successful
+ *link training
+ * @DRM_LINK_STATUS_BAD: DP Link is BAD as a result of link training
+ *   failure
  */
 enum drm_link_status {
DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD,
-- 
2.1.4

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

Re: [PATCH v5 4/6] drm/edid: detect SCDC support in HF-VSDB

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
>   This structure will be used to save and indicate if sink
>   supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within drm_hdmi_info, to
>   reflect scdc support and capabilities in connected HDMI 2.0 sink.
> - Checks the HF-VSDB block for presence of SCDC, and marks it
>   in scdc structure
> - If SCDC is present, checks if sink is capable of generating
>   SCDC read request, and marks it in scdc structure.
> 
> V2: Addressed review comments
>   Thierry:
>   - Fix typos in commit message and make abbreviation consistent
> across the commit message.
>   - Change structure object name from hdmi_info -> hdmi
>   - Fix typos and abbreviations in description of structure drm_hdmi_info
> end the description with a full stop.
>   - Create a structure drm_scdc, and keep all information related to SCDC
> register set (supported, read request supported) etc in it.
> 
>   Ville:
>   - Change rr -> read_request
>   - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
> of HF-VSDB parsing can be kept in same function, in incremental
> patches.
> 
> V3: Rebase.
> V4: Rebase.
> V5: Rebase.
> 
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_edid.c|  33 +++-
>  drivers/gpu/drm/drm_scdc_helper.c | 111 
> ++
>  include/drm/drm_connector.h   |  19 +++
>  include/drm/drm_edid.h|   6 ++-
>  include/drm/drm_scdc_helper.h |  27 ++
>  5 files changed, 194 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0881108..e84c5ab 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -3817,13 +3818,43 @@ enum hdmi_quantization_range
>  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
>const u8 *hf_vsdb)
>  {
> - struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
> + struct drm_display_info *display = &connector->display_info;
> + struct drm_hdmi_info *hdmi = &display->hdmi;
>  
>   if (hf_vsdb[6] & 0x80) {
>   hdmi->scdc.supported = true;
>   if (hf_vsdb[6] & 0x40)
>   hdmi->scdc.read_request = true;
>   }
> +
> + /*
> +  * All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
> +  * And as per the spec, three factors confirm this:
> +  * * Availability of a HF-VSDB block in EDID (check)
> +  * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
> +  * * SCDC support available (let's check)
> +  * Lets check it out.
> +  */
> +
> + if (hf_vsdb[5]) {
> + /* max clock is 5000 KHz times block value */
> + u32 max_tmds_clock = hf_vsdb[5] * 5000;
> + struct drm_scdc *scdc = &hdmi->scdc;
> +
> + if (max_tmds_clock > 34) {
> + display->max_tmds_clock = max_tmds_clock;
> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);
> + }
> +
> + if (scdc->supported) {
> + scdc->scrambling.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
> + scdc->scrambling.low_rates = true;
> + }
> + }
>  }
>  
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
> b/drivers/gpu/drm/drm_scdc_helper.c
> index c2dd33f..180a7cd 100644
> --- a/drivers/gpu/drm/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -22,8 +22,10 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include 
> +#include 
>  
>  /**
>   * DOC: scdc helpers
> @@ -121,3 +123,112 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
> offset,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_scdc_write);
> +
> +/**
> + * drm_scdc_check_scrambling_status - what is status of scrambling?
> + * @adapter: I2C adapter for DDC channel
> + *
> + * Reads the scrambler status over SCDC, and checks the
> + * scrambling status.
> + *
> + * Returns:
> + * True if the scrambling is enabled, false otherwise.
> + */
> +
> +bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
> +{
> + u8 status;
> + int ret;
> +
> + ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
> + if (ret < 0) {
> + DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
> + return false;
> + }
> +
> + return status & SCDC_SCRAMBLING_STATUS;

Re: [PATCH] drm: virtio: use kmem_cache

[Daniel Vetter]

On Wed, Mar 01, 2017 at 03:09:08PM +0100, Gerd Hoffmann wrote:
> Just use kmem_cache instead of rolling
> our own, limited implementation.
> 
> Signed-off-by: Gerd Hoffmann 

Looks very reasonable.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.h |  4 +--
>  drivers/gpu/drm/virtio/virtgpu_vq.c  | 57 
> +++-
>  2 files changed, 11 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 2f76673..4e66e35 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -178,9 +178,7 @@ struct virtio_gpu_device {
>  
>   struct virtio_gpu_queue ctrlq;
>   struct virtio_gpu_queue cursorq;
> - struct list_head free_vbufs;
> - spinlock_t free_vbufs_lock;
> - void *vbufs;
> + struct kmem_cache *vbufs;
>   bool vqs_ready;
>  
>   struct idr  resource_idr;
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 43ea0dc..472e349 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -74,51 +74,19 @@ void virtio_gpu_cursor_ack(struct virtqueue *vq)
>  
>  int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev)
>  {
> - struct virtio_gpu_vbuffer *vbuf;
> - int i, size, count = 16;
> - void *ptr;
> -
> - INIT_LIST_HEAD(&vgdev->free_vbufs);
> - spin_lock_init(&vgdev->free_vbufs_lock);
> - count += virtqueue_get_vring_size(vgdev->ctrlq.vq);
> - count += virtqueue_get_vring_size(vgdev->cursorq.vq);
> - size = count * VBUFFER_SIZE;
> - DRM_INFO("virtio vbuffers: %d bufs, %zdB each, %dkB total.\n",
> -  count, VBUFFER_SIZE, size / 1024);
> -
> - vgdev->vbufs = kzalloc(size, GFP_KERNEL);
> + vgdev->vbufs = kmem_cache_create("virtio-gpu-vbufs",
> +  VBUFFER_SIZE,
> +  __alignof__(struct virtio_gpu_vbuffer),
> +  0, NULL);
>   if (!vgdev->vbufs)
>   return -ENOMEM;
> -
> - for (i = 0, ptr = vgdev->vbufs;
> -  i < count;
> -  i++, ptr += VBUFFER_SIZE) {
> - vbuf = ptr;
> - list_add(&vbuf->list, &vgdev->free_vbufs);
> - }
>   return 0;
>  }
>  
>  void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev)
>  {
> - struct virtio_gpu_vbuffer *vbuf;
> - int i, count = 0;
> -
> - count += virtqueue_get_vring_size(vgdev->ctrlq.vq);
> - count += virtqueue_get_vring_size(vgdev->cursorq.vq);
> -
> - spin_lock(&vgdev->free_vbufs_lock);
> - for (i = 0; i < count; i++) {
> - if (WARN_ON(list_empty(&vgdev->free_vbufs))) {
> - spin_unlock(&vgdev->free_vbufs_lock);
> - return;
> - }
> - vbuf = list_first_entry(&vgdev->free_vbufs,
> - struct virtio_gpu_vbuffer, list);
> - list_del(&vbuf->list);
> - }
> - spin_unlock(&vgdev->free_vbufs_lock);
> - kfree(vgdev->vbufs);
> + kmem_cache_destroy(vgdev->vbufs);
> + vgdev->vbufs = NULL;
>  }
>  
>  static struct virtio_gpu_vbuffer*
> @@ -128,12 +96,9 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device 
> *vgdev)
>  {
>   struct virtio_gpu_vbuffer *vbuf;
>  
> - spin_lock(&vgdev->free_vbufs_lock);
> - BUG_ON(list_empty(&vgdev->free_vbufs));
> - vbuf = list_first_entry(&vgdev->free_vbufs,
> - struct virtio_gpu_vbuffer, list);
> - list_del(&vbuf->list);
> - spin_unlock(&vgdev->free_vbufs_lock);
> + vbuf = kmem_cache_alloc(vgdev->vbufs, GFP_KERNEL);
> + if (IS_ERR(vbuf))
> + return ERR_CAST(vbuf);
>   memset(vbuf, 0, VBUFFER_SIZE);
>  
>   BUG_ON(size > MAX_INLINE_CMD_SIZE);
> @@ -208,9 +173,7 @@ static void free_vbuf(struct virtio_gpu_device *vgdev,
>   if (vbuf->resp_size > MAX_INLINE_RESP_SIZE)
>   kfree(vbuf->resp_buf);
>   kfree(vbuf->data_buf);
> - spin_lock(&vgdev->free_vbufs_lock);
> - list_add(&vbuf->list, &vgdev->free_vbufs);
> - spin_unlock(&vgdev->free_vbufs_lock);
> + kmem_cache_free(vgdev->vbufs, vbuf);
>  }
>  
>  static void reclaim_vbufs(struct virtqueue *vq, struct list_head 
> *reclaim_list)
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH] drm: Fix the kernel doc warning for drm_link_status

[Daniel Vetter]

On Wed, Mar 01, 2017 at 06:45:10AM -0800, Manasi Navare wrote:
> This fixes the kernel doc warning that was introduced in
> the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
> atomic property for link status")'. Description has
> been added for the enum values.
> 
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org

Thanks for the quick fix, applied.
-Daniel

> ---
>  include/drm/drm_connector.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ccc0770..fabb35a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -94,6 +94,11 @@ enum subpixel_order {
>   *
>   * This enum is used as the connector's link status property value.
>   * It is set to the values defined in uapi.
> + *
> + * @DRM_LINK_STATUS_GOOD: DP Link is Good as a result of successful
> + *link training
> + * @DRM_LINK_STATUS_BAD: DP Link is BAD as a result of link training
> + *   failure
>   */
>  enum drm_link_status {
>   DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD,
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH v5 5/6] drm/i915: enable scrambling

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
> 
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
> 
> V2: Addressed review comments from Ville:
> - Do not track scrambling status in DRM layer, track somewhere in
>   driver like in intel_crtc_state.
> - Don't talk to monitor at such a low layer, set monitor scrambling
>   in intel_enable_ddi() before enabling the port.
> 
> V3: Addressed review comments from Jani
>  - In comments, function names, use "sink" instead of "monitor",
>so that the implementation could be close to the language of
>HDMI spec.
> 
> V4: Addressed review comment from Maarten
>  - scrambling -> hdmi_scrambling
>high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> 
> V5: Addressed review comments from Ville and Ander
>  - Do not modifiy the crtc_state after compute_config. Move all
>scrambling and tmds_clock_ratio calcutations to compute_config.
>  - While setting scrambling for source/sink, do not check the
>conditions again, just go by the crtc_state flags. This will
>simplyfy the condition checks.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   |  4 ++
>  drivers/gpu/drm/i915/intel_ddi.c  | 29 
>  drivers/gpu/drm/i915/intel_drv.h  | 14 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 98 
> +++
>  4 files changed, 145 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ce6f096..1759b64 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7824,7 +7824,11 @@ enum {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
>  #define  TRANS_DDI_BFI_ENABLE(1<<4)
> +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
>  
>  /* DisplayPort Transport Control */
>  #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a7c08d7..24bc3a8 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
> *crtc)
>   temp |= TRANS_DDI_MODE_SELECT_HDMI;
>   else
>   temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> + if (IS_GEMINILAKE(dev_priv))
> + temp = intel_hdmi_handle_source_scrambling(
> + intel_encoder,
> + intel_crtc->config, temp);
>   } else if (type == INTEL_OUTPUT_ANALOG) {
>   temp |= TRANS_DDI_MODE_SELECT_FDI;
>   temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> @@ -1885,6 +1890,21 @@ static void intel_enable_ddi(struct intel_encoder 
> *intel_encoder,
>   struct intel_digital_port *intel_dig_port =
>   enc_to_dig_port(encoder);
>  
> + if (IS_GEMINILAKE(dev_priv)) {
> + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> + /*
> +  * GLK sports a native HDMI 2.0 controller. If required
> +  * clock rate is > 340 Mhz && scrambling is supported
> +  * by sink, enable scrambling before enabling the
> +  * HDMI 2.0 port. The sink can choose to disable the
> +  * scrambling if it doesn't detect a scrambled within
> +  * 100 ms.
> +  */
> + intel_hdmi_handle_sink_scrambling(intel_encoder,
> + conn_state->connector,
> + crtc->config, true);
> + }
> +
>   /* In HDMI/DVI mode, the port width, and swing/emphasis values
>* are ignored so nothing special needs to be done besides
>* enabling the port.
> @@ -1912,11 +1932,20 @@ static void intel_disable_ddi(struct intel_encoder 
> *intel_encoder,
> struct drm_connector_state *old_conn_state)
>  {
>   struct drm_encoder *encoder = &intel_encoder->base;
> + struct drm_i915_private *dev_priv = encoder->dev->dev_private;
>   int type = intel_encoder->type;
>  
>   if (old_crtc_state->has_audio)
>   intel_audio_codec_disable(intel_encoder);
>  
> + if ((type == INTEL_OUTPUT_HDMI) && IS_GEMINILAKE(dev_priv)) {
^ 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement Link Rate fallback on Link training failure

[Daniel Vetter]

On Fri, Dec 16, 2016 at 12:29:07PM +0200, Jani Nikula wrote:
> From: Manasi Navare 
> 
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
> to "BAD" and use a lower link rate to prune the modes. It will redo
> the modeset on the current mode at lower link rate or if the current
> mode gets pruned due to lower link constraints then, it will send a
> hotplug uevent for userspace to handle it.
> 
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
> 
> v9:
> * Use the trimmed max values of link rate/lane count based on
> link train fallback (Daniel Vetter)
> v8:
> * Set link_status to BAD first and then call mode_valid (Jani Nikula)
> v7:
> Remove the redundant variable in previous patch itself
> v6:
> * Obtain link rate index from fallback_link_rate using
> the helper intel_dp_link_rate_index (Jani Nikula)
> * Include fallback within intel_dp_start_link_train (Jani Nikula)
> v5:
> * Move set link status to drm core (Daniel Vetter, Jani Nikula)
> v4:
> * Add fallback support for non DDI platforms too
> * Set connector->link status inside set_link_status function
> (Jani Nikula)
> v3:
> * Set link status property to BAd unconditionally (Jani Nikula)
> * Dont use two separate variables link_train_failed and link_status
> to indicate same thing (Jani Nikula)
> v2:
> * Squashed a few patches (Jani Nikula)
> 
> Acked-by: Tony Cheng 
> Acked-by: Harry Wentland 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> Reviewed-by: Jani Nikula 
> Signed-off-by: Jani Nikula 

Pushed to drm-misc-next after a quick irc chat with Manasi.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 27 
> +++
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 22 --
>  drivers/gpu/drm/i915/intel_drv.h  |  3 +++
>  3 files changed, 50 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 45ebc9632633..97d1e03d22b8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5671,6 +5671,29 @@ static bool intel_edp_init_connector(struct intel_dp 
> *intel_dp,
>   return false;
>  }
>  
> +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> +{
> + struct intel_connector *intel_connector;
> + struct drm_connector *connector;
> +
> + intel_connector = container_of(work, typeof(*intel_connector),
> +modeset_retry_work);
> + connector = &intel_connector->base;
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> +   connector->name);
> +
> + /* Grab the locks before changing connector property*/
> + mutex_lock(&connector->dev->mode_config.mutex);
> + /* Set connector link status to BAD and send a Uevent to notify
> +  * userspace to do a modeset.
> +  */
> + drm_mode_connector_set_link_status_property(connector,
> + DRM_MODE_LINK_STATUS_BAD);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> + /* Send Hotplug uevent so userspace can reprobe */
> + drm_kms_helper_hotplug_event(connector->dev);
> +}
> +
>  bool
>  intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>   struct intel_connector *intel_connector)
> @@ -5683,6 +5706,10 @@ intel_dp_init_connector(struct intel_digital_port 
> *intel_dig_port,
>   enum port port = intel_dig_port->port;
>   int type;
>  
> + /* Initialize the work for modeset in case of link train failure */
> + INIT_WORK(&intel_connector->modeset_retry_work,
> +   intel_dp_modeset_retry_work_fn);
> +
>   if (WARN(intel_dig_port->max_lanes < 1,
>"Not enough lanes (%d) for DP on port %c\n",
>intel_dig_port->max_lanes, port_name(port)))
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 0048b520baf7..955b239e7c2d 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -313,6 +313,24 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
>  void
>  intel_dp_start_link_train(struct intel_dp *intel_dp)
>  {
> - intel_dp_link_training_clock_recovery(intel_dp);
> - intel_dp_link_training_channel_equalization(intel_dp);
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> +
> + if (!intel_dp_link_training_clock_recovery(intel_dp))
> + goto failure_handling;
> + if (!intel_dp_link_training_channel_equalization(intel_dp))
> + goto failure_handling;
> +
> + DRM_DEBUG_KMS("Link Training Passed at Link

Re: [PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

Hi Daniel,

> +if dst_fname:
> +name = dst_fname[len(out_dir) + 1:]
> +# the builder needs not to copy one more time, so pop it if exists.
> +translator.builder.images.pop(img_node['uri'], None)
> +img_node['uri'] = dst_fname
> +img_node['candidates'] = {'*': dst_fname}
> +
> +mkdir(path.dirname(dst_fname))
> +
> +if in_ext == '.dot':
> +verbose('convert DOT to: {out}/' + name)
> +dot2format(src_fname, dst_fname)
> +
> +elif in_ext == '.svg':
> +verbose('convert SVG to: {out}/' + name)
> +svg2pdf(src_fname, dst_fname)

Small nit, but, shouldn't you add dst_fname to img_node only if
dot2format or svg2pdf was successful?

Thanks,

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

Re: [Intel-gfx] [PATCH] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

[Ville Syrjälä]

On Wed, Mar 01, 2017 at 04:07:02PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote:
> > Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
> > 1.1.
> > 
> > When a sink that supports deep color is connected to the output, the
> > receiver will send EDIDs that advertise this capability, even if it
> > isn't possible with HDMI versions earlier than 1.3.
> > 
> > Currently the kernel is assuming that deep color is possible and the
> > sink displays an error.
> > 
> > This quirk will make sure that deep color isn't used with this
> > particular receiver.
> > 
> > Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=99869
> > Signed-off-by: Tomeu Vizoso 
> 
> Cc: sta...@vger.kernel.org
> Cc: Matt Horan 
> Tested-by: Matt Horan 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869
> Reviewed-by: Ville Syrjälä 

And pushed to drm-misc-fixes. Thanks for the patch/testing/bug report
etc.

> 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 24e7b282f16c..d994ccf94f88 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -148,6 +148,9 @@ static const struct edid_quirk {
> >  
> > /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
> > { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
> > +
> > +   /* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
> > +   { "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
> >  };
> >  
> >  /*
> > -- 
> > 2.9.3
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/6] drm/doc: Add KMS overview graphs

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

> Oh, the shiny and pretties!
>

Very nice!

Reviewed-by: Gabriel Krisman Bertazi 


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

Re: [PATCH] drm/doc: diagram for mode objects and properties

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

> Resulted in confusion a few times in the past.
>

Reviewed-by: Gabriel Krisman Bertazi 

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

Re: [PATCH 6/6] drm/doc: atomic overview, with graph

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

> I've spent quite some time trying to beat DOT into submission, this is the
> best I can do. The FIXME really is just a hint for someone with more clue
> to maybe make it better, or if not possible at all, what would look better
> when doing a proper diagram with .svg or something like that.
>
> Assuming no one knows how to fix this, I'd still like to push it - it's
> still better than nothing imo, you just need to look at the picture
> full-screen.

If you add a hidden edge from any of the "duplicated" nodes to the
drm_device node, the second cluster will be pushed to the third rank
and do what I think you want.

Something like:

 "duplicated drm_plane_state A" -> "drm_device"[style=invis]

This is the result for me:

https://people.collabora.com/~krisman/atomic_modesetting.svg

I think it got a little better.

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

Re: [PATCH] drm/doc: atomic overview, with graph

[Eric Anholt]

Daniel Vetter  writes:

> I want to split up a few more things and document some details better
> (like how exactly to subclass drm_atomic_state). And maybe also split
> up the helpers a bit per-topic, but this should be a ok-ish start for
> better atomic overview.
>
> One thing I failed at is getting DOT to layout the overview graph how
> I want it. The highlevel structure I want is:
>
>   Free-standing State
>
>   Current State
>
> i.e. one over the other. Currently it lays it out side-by-side, but
> not even that really - "Current State" is somewhat offset below. Makes
> the graph look like garbage, and also way too wide for proper
> rendering. Ideas appreciated.
>
> v2: Spelling and clarifications (Eric).
>
> Cc: Eric Anholt 
> Cc: Laurent Pinchart 
> Cc: Harry Wentland 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms-helpers.rst |  2 +
>  Documentation/gpu/drm-kms.rst | 86 
> ++-
>  2 files changed, 87 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 050ebe81d256..ac53c0b893f6 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst

> +Atomic Mode Setting
> +===
> +
> +
> +.. FIXME: The I want the below graph to be laid out so that the 2 subgraph
> +   clusters are below each another. But I failed.

s/The //

With that,

Acked-by: Eric Anholt 


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

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

Bug ID: 100024
   Summary: [radeonsi] Failed to find memory space for buffer
eviction when calling glTexSubImage2D with 16384 / 2
   Product: DRI
   Version: XOrg git
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: julien.iso...@gmail.com

Created attachment 130005
  --> https://bugs.freedesktop.org/attachment.cgi?id=130005&action=edit
new piglit test max-texture-size2 to reproduce the problem

/ [AMD/ATI] Cape Verde PRO [FirePro W600] /

The piglit test max-texture-size2 prints:

GL_TEXTURE_RECTANGLE, Internal Format = GL_RGBA8, Largest Texture Size = 16384
radeon: Not enough memory for command submission.
[drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -12! (ENOMEM)
PIGLIT: {"subtest": {"GL_TEXTURE_RECTANGLE-GL_RGBA8" : "pass"}}

It says it passes but internally it fails. It looks like a bug from the TTM GPU
memory manager subsystem in the linux kernel.

To reproduce just run:
RADEON_THREAD=false DISPLAY=:0 PIGLIT_SOURCE_DIR=/home/julien/dev/piglit/
PIGLIT_PLATFORM=mixed_glx_egl ./bin/max-texture-size -fbo -auto

I set RADEON_THREAD=false to make it easier since the problem also appears with
true.

I attached a new and more minimal piglit test "max-texture-size2" that
reproduces the problem.
A workaround of the problem is to use GL fence as the new test also
demonstrates setting the env var USE_FENCE.

-- 
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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #1 from Julien Isorce  ---
Created attachment 130006
  --> https://bugs.freedesktop.org/attachment.cgi?id=130006&action=edit
lspic -s -v

-- 
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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #2 from Julien Isorce  ---
Created attachment 130008
  --> https://bugs.freedesktop.org/attachment.cgi?id=130008&action=edit
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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #3 from Julien Isorce  ---
Created attachment 130009
  --> https://bugs.freedesktop.org/attachment.cgi?id=130009&action=edit
Xorg.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

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #4 from Julien Isorce  ---
Created attachment 130011
  --> https://bugs.freedesktop.org/attachment.cgi?id=130011&action=edit
max-texture-size2 backtrace untill ENOMEM

-- 
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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #5 from Julien Isorce  ---
Created attachment 130012
  --> https://bugs.freedesktop.org/attachment.cgi?id=130012&action=edit
default output of max-texture-size2 test

-- 
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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #6 from Julien Isorce  ---
Created attachment 130013
  --> https://bugs.freedesktop.org/attachment.cgi?id=130013&action=edit
output of max-texture-size2 test with MESA_VERBOSE

-- 
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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #7 from Julien Isorce  ---
Created attachment 130014
  --> https://bugs.freedesktop.org/attachment.cgi?id=130014&action=edit
output of max-texture-size2 test with MESA_VERBOSE and R600_DEBUG

-- 
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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #8 from Julien Isorce  ---
Created attachment 130015
  --> https://bugs.freedesktop.org/attachment.cgi?id=130015&action=edit
output of max-texture-size2 test with USE_FENCE workaround

-- 
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 9/9] drm/i915: Add render decompression support

[Ben Widawsky]

On 17-03-01 12:51:17, Ville Syrjälä wrote:

On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:

On 17-02-28 12:18:39, Jason Ekstrand wrote:



>I've said it before but reading through Ben's patches again make me want to
>be peskier about it.  I would really like the UABI to treat the CCS as if
>it's Y-tiled with a tile size of 128B x 32 rows.  Why?  Because this is
>what all the docs say it is.  From the display docs for "Color Control
>Surface":
>
>"The Color Control Surface (CCS) contains the compression status of the
>cache-line pairs. The
>compression state of the cache-line pair is specified by 2 bits in the CCS.
>Each CCS cache-line represents
>an area on the main surface of 16 x16 sets of 128 byte Y-tiled
>cache-line-pairs. CCS is always Y tiled."
>
>This contains 95% of the information needed to know the relation between
>the CCS and the main surface.  The other 5% (which is badly documented) is
>that cache line pairs are horizontally adjacent.  This gives a relationship
>of one cache line in the CCS maps to 32x64 cache lines in the main surface.
>
>But it's not actually Y-tiled?  Of course not.  I've worked out the exact
>tiling and it looks something like Y but isn't quite the same.  However,
>this isn't unique to CCS.  Stencil (W-tiled), HiZ, and gen7-8
>single-sampled MCS also each have their own tiling (Haswell MCS is
>especially exotic) but the docs call all of them Y-tiled and I think the
>hardware internally treats them as Y-tiled with the cache lines shuffled
>around a bit.
>
>Given the fact that they seem to like to change the MCS/CCS tiling around
>on every hardware generation, I'm reluctant to base UABI on the fact that
>the CCS appears to have 64x64 "pixels" per tile with each "pixel"
>corresponding to 16x8 pixels in the color surface.  That's not what we had
>on any previous gen and may change on gen10 for no aparent reason.  I'd
>much rather base it on Y-tiling and a relationship between cache lines
>which, even if they change the exact swizzle on gen10, will probably remain
>the same.  (For the gen7-8 analogue of CCS, they changed the tiling every
>generation but the relationship of one MCS cache line maps to 32x128 color
>cache lines remained the same).
>
>Ok, I've said my peice.  If we have to divide by 2 in userspace, we won't
>die, but I'd like to get the UABI right before we chissel it in stone.
>
>--Jason
>
>

I vote we make the stride in units of tiles when we have the CCS modifier.


That won't fly with the KMS API. I suppose I could make the tile 128 bytes
wide by swapping the "1 byte == 16x8 pixels" notion with a
"1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore,
but I guess no one really cares.



KMS API goes right out the window with modifiers. Isn't that really the whole
point of modifiers?



>> +   /* fall through */
>> case I915_FORMAT_MOD_Yf_TILED:
>> /*
>>  * Bspec seems to suggest that the Yf tile width would
>> @@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const
>> struct drm_framebuffer *fb,
>> struct drm_i915_private *dev_priv = to_i915(fb->dev);
>>
>> /* AUX_DIST needs only 4K alignment */
>> -   if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
>> +   if (plane == 1)
>> return 4096;
>>
>> switch (fb->modifier) {
>> @@ -2166,6 +2174,8 @@ static unsigned int intel_surf_alignment(const
>> struct drm_framebuffer *fb,
>> if (INTEL_GEN(dev_priv) >= 9)
>> return 256 * 1024;
>> return 0;
>> +   case I915_FORMAT_MOD_Y_TILED_CCS:
>> +   case I915_FORMAT_MOD_Yf_TILED_CCS:
>> case I915_FORMAT_MOD_Y_TILED:
>> case I915_FORMAT_MOD_Yf_TILED:
>> return 1 * 1024 * 1024;
>> @@ -2472,6 +2482,7 @@ static unsigned int 
intel_fb_modifier_to_tiling(uint64_t
>> fb_modifier)
>> case I915_FORMAT_MOD_X_TILED:
>> return I915_TILING_X;
>> case I915_FORMAT_MOD_Y_TILED:
>> +   case I915_FORMAT_MOD_Y_TILED_CCS:
>> return I915_TILING_Y;
>> default:
>> return I915_TILING_NONE;
>> @@ -2536,6 +2547,35 @@ intel_fill_fb_info(struct drm_i915_private
>> *dev_priv,
>>
>> intel_fb_offset_to_xy(&x, &y, fb, i);
>>
>> +   if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
>> +fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) && i ==
>> 1) {
>> +   int main_x, main_y;
>> +   int ccs_x, ccs_y;
>> +
>> +   /*
>> +* Each byte of CCS corresponds to a 16x8 area of
>> the main surface, and
>> +* each CCS tile is 64x64 bytes.
>> +*/
>> +   ccs_x = (x * 16) % (64 * 16);
>> +   ccs_y = (y * 8) % (64 * 8);
>> +   main_x = intel_fb->normal[0].x % (64 * 16);
>

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #9 from Julien Isorce  ---
Created attachment 130016
  --> https://bugs.freedesktop.org/attachment.cgi?id=130016&action=edit
patch for mesa to translate the radeonsi printf ENOMEM to a proper
GL_OUT_OF_MEMORY

-- 
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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

--- Comment #10 from Julien Isorce  ---
Created attachment 130018
  --> https://bugs.freedesktop.org/attachment.cgi?id=130018&action=edit
output of max-texture-size2 test with attached patch for mesa

-- 
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 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Wed, Mar 01, 2017 at 09:50:56AM -0800, Ben Widawsky wrote:
> On 17-03-01 12:51:17, Ville Syrjälä wrote:
> >On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
> >> On 17-02-28 12:18:39, Jason Ekstrand wrote:
> >
> >> >I've said it before but reading through Ben's patches again make me want 
> >> >to
> >> >be peskier about it.  I would really like the UABI to treat the CCS as if
> >> >it's Y-tiled with a tile size of 128B x 32 rows.  Why?  Because this is
> >> >what all the docs say it is.  From the display docs for "Color Control
> >> >Surface":
> >> >
> >> >"The Color Control Surface (CCS) contains the compression status of the
> >> >cache-line pairs. The
> >> >compression state of the cache-line pair is specified by 2 bits in the 
> >> >CCS.
> >> >Each CCS cache-line represents
> >> >an area on the main surface of 16 x16 sets of 128 byte Y-tiled
> >> >cache-line-pairs. CCS is always Y tiled."
> >> >
> >> >This contains 95% of the information needed to know the relation between
> >> >the CCS and the main surface.  The other 5% (which is badly documented) is
> >> >that cache line pairs are horizontally adjacent.  This gives a 
> >> >relationship
> >> >of one cache line in the CCS maps to 32x64 cache lines in the main 
> >> >surface.
> >> >
> >> >But it's not actually Y-tiled?  Of course not.  I've worked out the exact
> >> >tiling and it looks something like Y but isn't quite the same.  However,
> >> >this isn't unique to CCS.  Stencil (W-tiled), HiZ, and gen7-8
> >> >single-sampled MCS also each have their own tiling (Haswell MCS is
> >> >especially exotic) but the docs call all of them Y-tiled and I think the
> >> >hardware internally treats them as Y-tiled with the cache lines shuffled
> >> >around a bit.
> >> >
> >> >Given the fact that they seem to like to change the MCS/CCS tiling around
> >> >on every hardware generation, I'm reluctant to base UABI on the fact that
> >> >the CCS appears to have 64x64 "pixels" per tile with each "pixel"
> >> >corresponding to 16x8 pixels in the color surface.  That's not what we had
> >> >on any previous gen and may change on gen10 for no aparent reason.  I'd
> >> >much rather base it on Y-tiling and a relationship between cache lines
> >> >which, even if they change the exact swizzle on gen10, will probably 
> >> >remain
> >> >the same.  (For the gen7-8 analogue of CCS, they changed the tiling every
> >> >generation but the relationship of one MCS cache line maps to 32x128 color
> >> >cache lines remained the same).
> >> >
> >> >Ok, I've said my peice.  If we have to divide by 2 in userspace, we won't
> >> >die, but I'd like to get the UABI right before we chissel it in stone.
> >> >
> >> >--Jason
> >> >
> >> >
> >>
> >> I vote we make the stride in units of tiles when we have the CCS modifier.
> >
> >That won't fly with the KMS API. I suppose I could make the tile 128 bytes
> >wide by swapping the "1 byte == 16x8 pixels" notion with a
> >"1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore,
> >but I guess no one really cares.
> >
> 
> KMS API goes right out the window with modifiers. Isn't that really the whole
> point of modifiers?

Not in my opinion. It's just a mild extension. The basics still apply
perfectly fine. 

And I really don't want to add special exceptions for CCS since
that'll just mean more code and more bugs. Right now the same code
that works for your typical planar formats works for CCS as well.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] some qxl fixes and cleanups.

[Gabriel Krisman Bertazi]

Gerd Hoffmann  writes:

>   Hi,
>
> This little series has some fixes and cleanups for the qxl driver.
> Based on drm-misc-next branch.
>

Hi Gerd,

Please add a reviewed-by for series.

Reviewed-by: Gabriel Krisman Bertazi 


> cheers,
>   Gerd
>
> Gerd Hoffmann (4):
>   qxl: drop mode_info.modes & related code.
>   qxl: limit monitor config read retries
>   qxl: read monitors config at boot
>   qxl: fix qxl_conn_get_modes
>
>  drivers/gpu/drm/qxl/qxl_display.c | 47 
> ---
>  drivers/gpu/drm/qxl/qxl_drv.h |  2 --
>  drivers/gpu/drm/qxl/qxl_kms.c | 22 --
>  3 files changed, 29 insertions(+), 42 deletions(-)

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

[PATCH 1/2 RESEND] drm/vc4: Fulfill user BO creation requests from the kernel BO cache.

[Eric Anholt]

The from_cache flag was actually "the BO is invisible to userspace",
so we can repurpose it to just zero out a cached BO and return it to
userspace.

Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by
-1.44989% +/- 0.862891% (n=28, 1 outlier removed from each that
appeared to be other system noise)

Note that there's an intel-gpu-tools test to check for the proper
zeroing behavior here, which we continue to pass.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 7abcd9c5dbe2..e5c7aa935b4b 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -211,21 +211,22 @@ struct drm_gem_object *vc4_create_object(struct 
drm_device *dev, size_t size)
 }
 
 struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t unaligned_size,
-bool from_cache)
+bool allow_unzeroed)
 {
size_t size = roundup(unaligned_size, PAGE_SIZE);
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_gem_cma_object *cma_obj;
+   struct vc4_bo *bo;
 
if (size == 0)
return ERR_PTR(-EINVAL);
 
/* First, try to get a vc4_bo from the kernel BO cache. */
-   if (from_cache) {
-   struct vc4_bo *bo = vc4_bo_get_from_cache(dev, size);
-
-   if (bo)
-   return bo;
+   bo = vc4_bo_get_from_cache(dev, size);
+   if (bo) {
+   if (!allow_unzeroed)
+   memset(bo->base.vaddr, 0, bo->base.base.size);
+   return bo;
}
 
cma_obj = drm_gem_cma_create(dev, size);
-- 
2.11.0

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

[PATCH 2/2 RESEND] drm/vc4: Fix OOPSes from trying to cache a partially constructed BO.

[Eric Anholt]

If a CMA allocation failed, the partially constructed BO would be
unreferenced through the normal path, and we might choose to put it in
the BO cache.  If we then reused it before it expired from the cache,
the kernel would OOPS.

Signed-off-by: Eric Anholt 
Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.")
---
 drivers/gpu/drm/vc4/vc4_bo.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index e5c7aa935b4b..af29432a6471 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -317,6 +317,14 @@ void vc4_free_object(struct drm_gem_object *gem_bo)
goto out;
}
 
+   /* If this object was partially constructed but CMA allocation
+* had failed, just free it.
+*/
+   if (!bo->base.vaddr) {
+   vc4_bo_destroy(bo);
+   goto out;
+   }
+
cache_list = vc4_get_cache_list_for_size(dev, gem_bo->size);
if (!cache_list) {
vc4_bo_destroy(bo);
-- 
2.11.0

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

Re: [PATCH v2] drm: Rely on mode_config data for fb_helper initialization

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

> You forgot to update the kernel-doc, building them now generates new
> warnings. Please fix in a follow-up patch.

Hm, that´s a bummer.  Please take the fix below.  Thanks for spotting.

-- >8 --
Subject: [PATCH] drm: Update drm_fbdev_cma_init documentation

Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization") dropped the num_crtc argument.  Update the
documentation to reflect that and prevent the kernel-doc warnings below:

./drivers/gpu/drm/drm_fb_cma_helper.c:557: warning: Excess function parameter 
'num_crtc' description in 'drm_fbdev_cma_init'
./drivers/gpu/drm/drm_fb_cma_helper.c:558: warning: Excess function parameter 
'num_crtc' description in 'drm_fbdev_cma_init'

Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper 
initialization")
Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index be6d90664e50..74cd393a6407 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -547,7 +547,6 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs);
  * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma struct
  * @dev: DRM device
  * @preferred_bpp: Preferred bits per pixel for the device
- * @num_crtc: Number of CRTCs
  * @max_conn_count: Maximum number of connectors
  *
  * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
-- 
2.11.0

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

Re: [RESEND PATCH v7 0/7] Rockchip dw-mipi-dsi driver

[Sean Paul]

On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
> Hi all
> 
> [Resend this v7 version series, since there are 5 mails have gone missing, 
> last
> week]
> 
> This version does not change the existing v6 patches, just to add the
> "bandwidth fix" patch back, since we really need it.
> 
> This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of
> RK3399 is almost the same as RK3288, except a little bit of difference
> in phy clock controlling and port id selection register. These patches
> add RK3399 support and the power domain support.
> 
> And these patches base on John Keeping's v3 patches[0], it fixes many bugs,
> they have been tested on rk3288 evb board.
> 
> [0]:
> [01/24] https://patchwork.kernel.org/patch/9544089
> [02/24] https://patchwork.kernel.org/patch/9544061
> [03/24] https://patchwork.kernel.org/patch/9544065
> [04/24] https://patchwork.kernel.org/patch/9544077
> [05/24] https://patchwork.kernel.org/patch/9544033
> [06/24] https://patchwork.kernel.org/patch/9544037
> [07/24] https://patchwork.kernel.org/patch/9544029
> [08/24] https://patchwork.kernel.org/patch/9544031
> [09/24] https://patchwork.kernel.org/patch/9544083
> [10/24] https://patchwork.kernel.org/patch/9544063
> [11/24] https://patchwork.kernel.org/patch/9544085
> [12/24] https://patchwork.kernel.org/patch/9544093
> [13/24] https://patchwork.kernel.org/patch/9544081
> [14/24] https://patchwork.kernel.org/patch/9544057
> [15/24] https://patchwork.kernel.org/patch/9544079
> [16/24] https://patchwork.kernel.org/patch/9544035
> [17/24] https://patchwork.kernel.org/patch/9544105
> [18/24] https://patchwork.kernel.org/patch/9544059
> [21/24] https://patchwork.kernel.org/patch/9544009
> [22/24] https://patchwork.kernel.org/patch/9544049
> [23/24] https://patchwork.kernel.org/patch/9544055
> [24/24] https://patchwork.kernel.org/patch/9544109
> 
> 
> Changes in v6:
> - no need check phy_cfg_clk before enable/disable
> 
> Changes in v5:
> - check the error of phy_cfg_clk in dw_mipi_dsi_bind
> 
> Changes in v4:
> - remove the unrelated change
> 
> Changes in v3:
> - base on John Keeping's patch series
> 
> Chris Zhong (7):
>   dt-bindings: add rk3399 support for dw-mipi-rockchip
>   drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
>   drm/rockchip/dsi: dw-mipi: correct the coding style
>   drm/rockchip/dsi: remove mode_valid function
>   dt-bindings: add power domain node for dw-mipi-rockchip
>   drm/rockchip/dsi: fix insufficient bandwidth of some panel
>   drm/rockchip/dsi: add dw-mipi power domain support

Applied to drm-misc

Thanks,

Sean
> 
>  .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   7 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 160 
> -
>  2 files changed, 100 insertions(+), 67 deletions(-)
> 
> -- 
> 2.6.3
> 
> ___
> 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 v4 00/23] drm/rockchip: MIPI fixes & improvements

[Sean Paul]

On Fri, Feb 24, 2017 at 12:54:43PM +, John Keeping wrote:
> This version is mostly small changes in response to review comments from
> Sean and Chris, the details are in the individual patches.
> 
> I decided to drop the final patch which adds support for MIPI read
> commands because I'm not using that feature now and I can't easily test
> it.  It's on the list if anyone wants to pick it up in the future.
> 
> Version 3 was posted here:
> http://www.spinics.net/lists/dri-devel/msg130977.html
> 
> Thanks to Sean Paul and Chris Zhong for their review and testing of this
> series.
> 
> John Keeping (23):
>   drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for
> MIPI
>   drm/rockchip: dw-mipi-dsi: pass mode in where needed
>   drm/rockchip: dw-mipi-dsi: remove mode_set hook
>   drm/rockchip: dw-mipi-dsi: fix command header writes
>   drm/rockchip: dw-mipi-dsi: fix generic packet status check
>   drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
>   drm/rockchip: dw-mipi-dsi: include bad value in error message
>   drm/rockchip: dw-mipi-dsi: respect message flags
>   drm/rockchip: dw-mipi-dsi: only request HS clock when required
>   drm/rockchip: dw-mipi-dsi: don't assume buffer is aligned
>   drm/rockchip: dw-mipi-dsi: prepare panel after phy init
>   drm/rockchip: dw-mipi-dsi: allow commands in panel_disable
>   drm/rockchip: dw-mipi-dsi: fix escape clock rate
>   drm/rockchip: dw-mipi-dsi: ensure PHY is reset
>   drm/rockchip: dw-mipi-dsi: configure PHY before enabling
>   drm/rockchip: dw-mipi-dsi: properly configure PHY timing
>   drm/rockchip: dw-mipi-dsi: improve PLL configuration
>   drm/rockchip: dw-mipi-dsi: use specific poll helper
>   drm/rockchip: dw-mipi-dsi: use positive check for N{H,V}SYNC
>   drm/rockchip: vop: test for P{H,V}SYNC
>   drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded
>   drm/rockchip: dw-mipi-dsi: support non-burst modes
>   drm/rockchip: dw-mipi-dsi: add reset control
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 325 
> +++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   4 +-
>  2 files changed, 220 insertions(+), 109 deletions(-)

Applied to drm-misc

Thanks,

Sean
> 
> -- 
> 2.12.0.rc0.230.gf625d4cdb9.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: Rely on mode_config data for fb_helper initialization

[Daniel Vetter]

On Wed, Mar 01, 2017 at 04:01:05PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter  writes:
> 
> > You forgot to update the kernel-doc, building them now generates new
> > warnings. Please fix in a follow-up patch.
> 
> Hm, that´s a bummer.  Please take the fix below.  Thanks for spotting.

Applied, thx for the quick fix.
-Daniel

> 
> -- >8 --
> Subject: [PATCH] drm: Update drm_fbdev_cma_init documentation
> 
> Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
> initialization") dropped the num_crtc argument.  Update the
> documentation to reflect that and prevent the kernel-doc warnings below:
> 
> ./drivers/gpu/drm/drm_fb_cma_helper.c:557: warning: Excess function parameter 
> 'num_crtc' description in 'drm_fbdev_cma_init'
> ./drivers/gpu/drm/drm_fb_cma_helper.c:558: warning: Excess function parameter 
> 'num_crtc' description in 'drm_fbdev_cma_init'
> 
> Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper 
> initialization")
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  drivers/gpu/drm/drm_fb_cma_helper.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index be6d90664e50..74cd393a6407 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -547,7 +547,6 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs);
>   * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma struct
>   * @dev: DRM device
>   * @preferred_bpp: Preferred bits per pixel for the device
> - * @num_crtc: Number of CRTCs
>   * @max_conn_count: Maximum number of connectors
>   *
>   * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
> -- 
> 2.11.0
> 

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

Re: [PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Stefan Lengfeld]

Hi Maxime,

On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote:
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to 
>  
> synchronize drawing or buffer flip for double buffering. It is tested on
> the i.MX6.
>
> Signed-off-by: Maxime Ripard 
> Tested-by: Neil Armstrong 

I will test this patch and the already applied patch to drm-next on the
i.MX6 platform in the next days.

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

[PATCH] drm: qxl: Don't clean up uninitialized fbdev framebuffer

[Gabriel Krisman Bertazi]

Daniel Vetter  writes:

Hi Daniel, thanks again for your review.

> Hm, I bit silly that we need #ifdef here, all this stuff is meant to Just
> Work. Can't we just fix the oops with suitable checks in the fini paths
> instead?

Heh.  I expected someone would bring up this objection.  My rationale is
that on the driver side, and for many drivers, fbdev emulation code is
always executed, even if it is only calling a bunch of NOP functions on
the drm core, which is a bit silly.  I wonder if struct drm_driver could
have a new callback for fbdev_initialization, which we could avoid
calling in drm_core (maybe at registering time) if FBDEV_EMULATION is
disabled. (well, this would go a bit in the opposite direction of having
open coded probe sequences).

Anyway, for the Oops I mentioned, can you consider the patch below,
instead?

>
> Also 0day has hit some oops in bochs, it might suffer from similar bugs.

I can take a look at that too.

-- >8 --
Subject: [PATCH] drm: qxl: Don't clean up uninitialized fbdev framebuffer

If fbdev emulation is disabled, the QXL shutdown path still tries to
clean the framebuffer, which wasn't initialized, hitting the Oops below.
We can check for the qfb->obj element to ensure the fb was initialized,
because the qfb always has a bo object associated with it since
initialization time.

[   24.284684] BUG: unable to handle kernel NULL pointer dereference at 
02e0
[   24.285627] IP: mutex_lock+0x18/0x30
[   24.286049] PGD 78cdf067
[   24.286050] PUD 7940f067
[   24.286344] PMD 0
[   24.286649]
[   24.287072] Oops: 0002 [#1] SMP
[   24.287422] Modules linked in: qxl
[   24.287806] CPU: 0 PID: 2328 Comm: bash Not tainted 4.10.0-rc5+ #97
[   24.288515] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   24.289681] task: 88007c4c task.stack: c90001b58000
[   24.290354] RIP: 0010:mutex_lock+0x18/0x30
[   24.290812] RSP: 0018:c90001b5bcb0 EFLAGS: 00010246
[   24.291401] RAX:  RBX: 02e0 RCX: 
[   24.292209] RDX: 88007c4c RSI: 0001 RDI: 02e0
[   24.292987] RBP: c90001b5bcb8 R08: fffe R09: 0001
[   24.293797] R10: 880078d80b80 R11: 00011400 R12: 
[   24.294601] R13: 02e0 R14: a0009c28 R15: 0060
[   24.295439] FS:  7f30e3acbb40() GS:88007fc0() 
knlGS:
[   24.296364] CS:  0010 DS:  ES:  CR0: 80050033
[   24.296997] CR2: 02e0 CR3: 78c7b000 CR4: 06f0
[   24.297813] Call Trace:
[   24.298097]  drm_framebuffer_cleanup+0x1f/0x70
[   24.298612]  qxl_fbdev_fini+0x68/0x90 [qxl]
[   24.299074]  qxl_modeset_fini+0xd/0x30 [qxl]
[   24.299562]  qxl_pci_remove+0x22/0x50 [qxl]
[   24.300025]  pci_device_remove+0x34/0xb0
[   24.300507]  device_release_driver_internal+0x150/0x200
[   24.301082]  device_release_driver+0xd/0x10
[   24.301587]  unbind_store+0x108/0x150
[   24.301993]  drv_attr_store+0x20/0x30
[   24.302402]  sysfs_kf_write+0x32/0x40
[   24.302827]  kernfs_fop_write+0x108/0x190
[   24.303269]  __vfs_write+0x23/0x120
[   24.303678]  ? security_file_permission+0x36/0xb0
[   24.304193]  ? rw_verify_area+0x49/0xb0
[   24.304636]  vfs_write+0xb0/0x190
[   24.305004]  SyS_write+0x41/0xa0
[   24.305362]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[   24.305887] RIP: 0033:0x7f30e31d9620
[   24.306285] RSP: 002b:7ffc54b47e68 EFLAGS: 0246 ORIG_RAX: 
0001
[   24.307128] RAX: ffda RBX: 7f30e3497600 RCX: 7f30e31d9620
[   24.307928] RDX: 000d RSI: 00da2008 RDI: 0001
[   24.308727] RBP: 0070bc60 R08: 7f30e3498760 R09: 7f30e3acbb40
[   24.309504] R10: 0073 R11: 0246 R12: 0001
[   24.310295] R13:  R14:  R15: 7ffc54b47f34
[   24.311095] Code: 0e 01 e9 7b fe ff ff 66 90 66 2e 0f 1f 84 00 00 00 00 00
55 48 89 e5 53 48 89 fb e8 83 e8 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <3e>
48 0f b1 13 48 85 c0 74 08 48 89 df e8 66 fd ff ff 5b 5d c3
[   24.313182] RIP: mutex_lock+0x18/0x30 RSP: c90001b5bcb0
[   24.313811] CR2: 02e0
[   24.314208] ---[ end trace 29669c1593cae14b ]---

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/qxl/qxl_fb.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 35124737666e..4d6c311e8e5e 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -351,13 +351,16 @@ static int qxl_fbdev_destroy(struct drm_device *dev, 
struct qxl_fbdev *qfbdev)
 
drm_fb_helper_unregister_fbi(&qfbdev->helper);
 
-   if (qfb->obj) {
+   if (qfb->obj)
qxlfb_destroy_pinned_object(qfb->obj);
-   qfb->obj = NULL;
-   }
+
drm_fb_helper_fini(&qfbdev->helper)

[PATCH v4 1/9] drm: bridge: dw-hdmi: Remove unused functions

[Laurent Pinchart]

Most of the hdmi_phy_test_*() functions are unused. Remove them.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 26 --
 1 file changed, 26 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 9a9ec27d9e28..ce7496399ccf 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -837,32 +837,6 @@ static inline void hdmi_phy_test_clear(struct dw_hdmi 
*hdmi,
  HDMI_PHY_TST0_TSTCLR_MASK, HDMI_PHY_TST0);
 }
 
-static inline void hdmi_phy_test_enable(struct dw_hdmi *hdmi,
-   unsigned char bit)
-{
-   hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTEN_OFFSET,
- HDMI_PHY_TST0_TSTEN_MASK, HDMI_PHY_TST0);
-}
-
-static inline void hdmi_phy_test_clock(struct dw_hdmi *hdmi,
-  unsigned char bit)
-{
-   hdmi_modb(hdmi, bit << HDMI_PHY_TST0_TSTCLK_OFFSET,
- HDMI_PHY_TST0_TSTCLK_MASK, HDMI_PHY_TST0);
-}
-
-static inline void hdmi_phy_test_din(struct dw_hdmi *hdmi,
-unsigned char bit)
-{
-   hdmi_writeb(hdmi, bit, HDMI_PHY_TST1);
-}
-
-static inline void hdmi_phy_test_dout(struct dw_hdmi *hdmi,
- unsigned char bit)
-{
-   hdmi_writeb(hdmi, bit, HDMI_PHY_TST2);
-}
-
 static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, int msec)
 {
u32 val;
-- 
Regards,

Laurent Pinchart

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

[PATCH v4 4/9] drm: bridge: dw-hdmi: Fix the PHY power down sequence

[Laurent Pinchart]

The PHY requires us to wait for the PHY to switch to low power mode
after deasserting TXPWRON and before asserting PDDQ in the power down
sequence, otherwise power down will fail.

The PHY power down can be monitored though the TX_READY bit, available
through I2C in the PHY registers, or the TX_PHY_LOCK bit, available
through the HDMI TX registers. As the two are equivalent, let's pick the
easier solution of polling the TX_PHY_LOCK bit.

The power down code is currently duplicated in multiple places. To avoid
spreading multiple calls to a TX_PHY_LOCK poll function, we have to
refactor the power down code and group it all in a single function.

Tests showed that one poll iteration was enough for TX_PHY_LOCK to
become low, without requiring any additional delay. Retrying the read
five times with a 1ms to 2ms delay between each attempt should thus be
more than enough.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 52 +---
 1 file changed, 43 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index d863b3393aee..85348ba6bb1c 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -116,6 +116,7 @@ struct dw_hdmi_i2c {
 struct dw_hdmi_phy_data {
enum dw_hdmi_phy_type type;
const char *name;
+   unsigned int gen;
bool has_svsret;
 };
 
@@ -914,6 +915,40 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
 }
 
+static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
+{
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
+   unsigned int i;
+   u16 val;
+
+   if (phy->gen == 1) {
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_powerdown(hdmi, true);
+   return;
+   }
+
+   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+
+   /*
+* Wait for TX_PHY_LOCK to be deasserted to indicate that the PHY went
+* to low power mode.
+*/
+   for (i = 0; i < 5; ++i) {
+   val = hdmi_readb(hdmi, HDMI_PHY_STAT0);
+   if (!(val & HDMI_PHY_TX_PHY_LOCK))
+   break;
+
+   usleep_range(1000, 2000);
+   }
+
+   if (val & HDMI_PHY_TX_PHY_LOCK)
+   dev_warn(hdmi->dev, "PHY failed to power down\n");
+   else
+   dev_dbg(hdmi->dev, "PHY powered down in %u iterations\n", i);
+
+   dw_hdmi_phy_gen2_pddq(hdmi, 1);
+}
+
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
u8 val, msec;
@@ -946,11 +981,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
return -EINVAL;
}
 
-   /* gen2 tx power off */
-   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
-
-   /* gen2 pddq */
-   dw_hdmi_phy_gen2_pddq(hdmi, 1);
+   dw_hdmi_phy_power_off(hdmi);
 
/* Leave low power consumption mode by asserting SVSRET. */
if (hdmi->phy->has_svsret)
@@ -1025,8 +1056,6 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
for (i = 0; i < 2; i++) {
dw_hdmi_phy_sel_data_en_pol(hdmi, 1);
dw_hdmi_phy_sel_interface_control(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_powerdown(hdmi, true);
 
ret = hdmi_phy_configure(hdmi);
if (ret)
@@ -1256,8 +1285,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
if (!hdmi->phy_enabled)
return;
 
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_powerdown(hdmi, true);
+   dw_hdmi_phy_power_off(hdmi);
 
hdmi->phy_enabled = false;
 }
@@ -1827,23 +1855,29 @@ static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
{
.type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
.name = "DWC HDMI TX PHY",
+   .gen = 1,
}, {
.type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
.name = "DWC MHL PHY + HEAC PHY",
+   .gen = 2,
.has_svsret = true,
}, {
.type = DW_HDMI_PHY_DWC_MHL_PHY,
.name = "DWC MHL PHY",
+   .gen = 2,
.has_svsret = true,
}, {
.type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
.name = "DWC HDMI 3D TX PHY + HEAC PHY",
+   .gen = 2,
}, {
.type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
.name = "DWC HDMI 3D TX PHY",
+   .gen = 2,
}, {
.type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
.name = "DWC HDMI 2.0 TX PHY",
+   .gen = 2,
.has_svsret = true,
}
 };
-- 
Regards,

Laurent Pinchart

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

[PATCH v4 3/9] drm: bridge: dw-hdmi: Enable CSC even for DVI

[Laurent Pinchart]

From: Neil Armstrong 

If the input pixel format is not RGB, the CSC must be enabled in order to
provide valid pixel to DVI sinks.
This patch removes the hdmi only dependency on the CSC enabling.

Reviewed-by: Jose Abreu 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 906583beb08b..d863b3393aee 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1291,8 +1291,8 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
}
 
-   /* Enable color space conversion if needed (for HDMI sinks only). */
-   if (hdmi->sink_is_hdmi && is_color_space_conversion(hdmi))
+   /* Enable color space conversion if needed */
+   if (is_color_space_conversion(hdmi))
hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH,
HDMI_MC_FLOWCTRL);
else
-- 
Regards,

Laurent Pinchart

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

[PATCH v4 2/9] drm: bridge: dw-hdmi: Move CSC configuration out of PHY code

[Laurent Pinchart]

The color space converter isn't part of the PHY, move its configuration
out of PHY code.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ce7496399ccf..906583beb08b 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -914,7 +914,7 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
 }
 
-static int hdmi_phy_configure(struct dw_hdmi *hdmi, int cscon)
+static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
u8 val, msec;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
@@ -946,14 +946,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
return -EINVAL;
}
 
-   /* Enable csc path */
-   if (cscon)
-   val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH;
-   else
-   val = HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS;
-
-   hdmi_writeb(hdmi, val, HDMI_MC_FLOWCTRL);
-
/* gen2 tx power off */
dw_hdmi_phy_gen2_txpwron(hdmi, 0);
 
@@ -1028,10 +1020,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
 static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
 {
int i, ret;
-   bool cscon;
-
-   /*check csc whether needed activated in HDMI mode */
-   cscon = hdmi->sink_is_hdmi && is_color_space_conversion(hdmi);
 
/* HDMI Phy spec says to do the phy initialization sequence twice */
for (i = 0; i < 2; i++) {
@@ -1040,8 +1028,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_tmds(hdmi, 0);
dw_hdmi_phy_enable_powerdown(hdmi, true);
 
-   /* Enable CSC */
-   ret = hdmi_phy_configure(hdmi, cscon);
+   ret = hdmi_phy_configure(hdmi);
if (ret)
return ret;
}
@@ -1303,6 +1290,14 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
}
+
+   /* Enable color space conversion if needed (for HDMI sinks only). */
+   if (hdmi->sink_is_hdmi && is_color_space_conversion(hdmi))
+   hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH,
+   HDMI_MC_FLOWCTRL);
+   else
+   hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS,
+   HDMI_MC_FLOWCTRL);
 }
 
 static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
-- 
Regards,

Laurent Pinchart

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

[PATCH v4 7/9] drm: bridge: dw-hdmi: Add support for custom PHY configuration

[Laurent Pinchart]

From: Kieran Bingham 

The DWC HDMI TX controller interfaces with a companion PHY. While
Synopsys provides multiple standard PHYs, SoC vendors can also integrate
a custom PHY.

Modularize PHY configuration to support vendor PHYs through platform
data. The existing PHY configuration code was originally written to
support the DWC HDMI 3D TX PHY, and seems to be compatible with the DWC
MLP PHY. The HDMI 2.0 PHY will require a separate configuration
function.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Check pdata->phy_configure in hdmi_phy_configure() to avoid
  dereferencing NULL pointer.
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 109 ++-
 include/drm/bridge/dw_hdmi.h |   7 +++
 2 files changed, 81 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index cb2703862be2..b835d81bb471 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -118,6 +118,9 @@ struct dw_hdmi_phy_data {
const char *name;
unsigned int gen;
bool has_svsret;
+   int (*configure)(struct dw_hdmi *hdmi,
+const struct dw_hdmi_plat_data *pdata,
+unsigned long mpixelclock);
 };
 
 struct dw_hdmi {
@@ -860,8 +863,8 @@ static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, 
int msec)
return true;
 }
 
-static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
-unsigned char addr)
+void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
+  unsigned char addr)
 {
hdmi_writeb(hdmi, 0xFF, HDMI_IH_I2CMPHY_STAT0);
hdmi_writeb(hdmi, addr, HDMI_PHY_I2CM_ADDRESS_ADDR);
@@ -873,6 +876,7 @@ static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, 
unsigned short data,
HDMI_PHY_I2CM_OPERATION_ADDR);
hdmi_phy_wait_i2c_done(hdmi, 1000);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write);
 
 static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
 {
@@ -993,37 +997,67 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
return 0;
 }
 
-static int hdmi_phy_configure(struct dw_hdmi *hdmi)
+/*
+ * PHY configuration function for the DWC HDMI 3D TX PHY. Based on the 
available
+ * information the DWC MHL PHY has the same register layout and is thus also
+ * supported by this function.
+ */
+static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
+   const struct dw_hdmi_plat_data *pdata,
+   unsigned long mpixelclock)
 {
-   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
-   const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
 
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   mpll_config->mpixelclock)
+   if (mpixelclock <= mpll_config->mpixelclock)
break;
 
for (; curr_ctrl->mpixelclock != ~0UL; curr_ctrl++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   curr_ctrl->mpixelclock)
+   if (mpixelclock <= curr_ctrl->mpixelclock)
break;
 
for (; phy_config->mpixelclock != ~0UL; phy_config++)
-   if (hdmi->hdmi_data.video_mode.mpixelclock <=
-   phy_config->mpixelclock)
+   if (mpixelclock <= phy_config->mpixelclock)
break;
 
if (mpll_config->mpixelclock == ~0UL ||
curr_ctrl->mpixelclock == ~0UL ||
-   phy_config->mpixelclock == ~0UL) {
-   dev_err(hdmi->dev, "Pixel clock %d - unsupported by HDMI\n",
-   hdmi->hdmi_data.video_mode.mpixelclock);
+   phy_config->mpixelclock == ~0UL)
return -EINVAL;
-   }
+
+   dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce,
+ HDMI_3D_TX_PHY_CPCE_CTRL);
+   dw_hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp,
+ HDMI_3D_TX_PHY_GMPCTRL);
+   dw_hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0],
+ HDMI_3D_TX_PHY_CURRCTRL);
+
+   dw_hdmi_phy_i2c_write(hdmi, 0, HDMI_3D_TX_PHY_PLLPHBYCTRL);
+   dw_hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_MSM_CTRL_CKO_SEL_FB_CLK,
+ HDMI_3D_TX_PHY_MSM_CTRL);
+
+   dw_hdmi_phy_i2c_write(hdmi, phy_config->term, HDMI_3D_TX_PHY_TXTERM);
+   dw_hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr,
+ HDMI_3D_TX_PHY_CKSYMTXCTRL);
+   dw_hdmi_phy_i2c_write(hdmi, phy_confi

[PATCH v4 5/9] drm: bridge: dw-hdmi: Fix the PHY power up sequence

[Laurent Pinchart]

When powering the PHY up we need to wait for the PLL to lock. This is
done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
(interrupt-based wait could be implemented as well but is likely
overkill). The bit is asserted when the PLL locks, but the current code
incorrectly waits for the bit to be deasserted. Fix it, and while at it,
replace the udelay() with a sleep as the code never runs in
non-sleepable context.

To be consistent with the power down implementation move the poll loop
to the power off function.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 65 +++-
 1 file changed, 37 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 85348ba6bb1c..0aa3ad404f77 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -949,9 +949,44 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
dw_hdmi_phy_gen2_pddq(hdmi, 1);
 }
 
+static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
+{
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
+   unsigned int i;
+   u8 val;
+
+   if (phy->gen == 1) {
+   dw_hdmi_phy_enable_powerdown(hdmi, false);
+
+   /* Toggle TMDS enable. */
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_tmds(hdmi, 1);
+   return 0;
+   }
+
+   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+   dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+   /* Wait for PHY PLL lock */
+   for (i = 0; i < 5; ++i) {
+   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
+   if (val)
+   break;
+
+   usleep_range(1000, 2000);
+   }
+
+   if (!val) {
+   dev_err(hdmi->dev, "PHY PLL failed to lock\n");
+   return -ETIMEDOUT;
+   }
+
+   dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
+   return 0;
+}
+
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
-   u8 val, msec;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
@@ -1019,33 +1054,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
   HDMI_3D_TX_PHY_CKCALCTRL);
 
-   dw_hdmi_phy_enable_powerdown(hdmi, false);
-
-   /* toggle TMDS enable */
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 1);
-
-   /* gen2 tx power on */
-   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
-   dw_hdmi_phy_gen2_pddq(hdmi, 0);
-
-   /* Wait for PHY PLL lock */
-   msec = 5;
-   do {
-   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-   if (!val)
-   break;
-
-   if (msec == 0) {
-   dev_err(hdmi->dev, "PHY PLL not locked\n");
-   return -ETIMEDOUT;
-   }
-
-   udelay(1000);
-   msec--;
-   } while (1);
-
-   return 0;
+   return dw_hdmi_phy_power_on(hdmi);
 }
 
 static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
-- 
Regards,

Laurent Pinchart

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

[PATCH v4 6/9] drm: bridge: dw-hdmi: Create PHY operations

[Laurent Pinchart]

The HDMI TX controller support different PHYs whose programming
interface can vary significantly, especially with vendor PHYs that are
not provided by Synopsys. To support them, create a PHY operation
structure that can be provided by the platform glue layer. The existing
PHY handling code (limited to Synopsys PHY support) is refactored into a
set of default PHY operations that are used automatically when the
platform glue doesn't provide its own operations.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 91 
 include/drm/bridge/dw_hdmi.h | 18 +++-
 2 files changed, 80 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 0aa3ad404f77..cb2703862be2 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -141,8 +141,12 @@ struct dw_hdmi {
u8 edid[HDMI_EDID_LEN];
bool cable_plugin;
 
-   const struct dw_hdmi_phy_data *phy;
-   bool phy_enabled;
+   struct {
+   const struct dw_hdmi_phy_ops *ops;
+   const char *name;
+   void *data;
+   bool enabled;
+   } phy;
 
struct drm_display_mode previous_mode;
 
@@ -831,6 +835,10 @@ static void hdmi_video_packetize(struct dw_hdmi *hdmi)
  HDMI_VP_CONF);
 }
 
+/* 
-
+ * Synopsys PHY Handling
+ */
+
 static inline void hdmi_phy_test_clear(struct dw_hdmi *hdmi,
   unsigned char bit)
 {
@@ -987,6 +995,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
 
 static int hdmi_phy_configure(struct dw_hdmi *hdmi)
 {
+   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
@@ -1019,7 +1028,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
dw_hdmi_phy_power_off(hdmi);
 
/* Leave low power consumption mode by asserting SVSRET. */
-   if (hdmi->phy->has_svsret)
+   if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
 
/* PHY reset. The reset signal is active high on Gen2 PHYs. */
@@ -1057,7 +1066,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
return dw_hdmi_phy_power_on(hdmi);
 }
 
-static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
+static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void *data,
+   struct drm_display_mode *mode)
 {
int i, ret;
 
@@ -1071,10 +1081,31 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
return ret;
}
 
-   hdmi->phy_enabled = true;
return 0;
 }
 
+static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, void *data)
+{
+   dw_hdmi_phy_power_off(hdmi);
+}
+
+static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+ void *data)
+{
+   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
+   connector_status_connected : connector_status_disconnected;
+}
+
+static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
+   .init = dw_hdmi_phy_init,
+   .disable = dw_hdmi_phy_disable,
+   .read_hpd = dw_hdmi_phy_read_hpd,
+};
+
+/* 
-
+ * HDMI TX Setup
+ */
+
 static void hdmi_tx_hdcp_config(struct dw_hdmi *hdmi)
 {
u8 de;
@@ -1289,16 +1320,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, vsync_len, HDMI_FC_VSYNCINWIDTH);
 }
 
-static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi)
-{
-   if (!hdmi->phy_enabled)
-   return;
-
-   dw_hdmi_phy_power_off(hdmi);
-
-   hdmi->phy_enabled = false;
-}
-
 /* HDMI Initialization Step B.4 */
 static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
 {
@@ -1431,9 +1452,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
hdmi_av_composer(hdmi, mode);
 
/* HDMI Initializateion Step B.2 */
-   ret = dw_hdmi_phy_init(hdmi);
+   ret = hdmi->phy.ops->init(hdmi, hdmi->phy.data, &hdmi->previous_mode);
if (ret)
return ret;
+   hdmi->phy.enabled = true;
 
/* HDMI Initialization Step B.3 */
dw_hdmi_enable_video_path(hdmi);
@@ -1548,7 +1570,11 @@ static void dw_hdmi_poweron(struct dw_hdmi *hdmi)
 
 static void dw_hdmi_poweroff(struct dw_hdmi *hdmi)
 {
-   dw_hdmi_phy_disable(hdmi);
+   if (hdmi->phy.enabled) {
+   hdmi->phy.ops->disable(hdmi, hdmi->phy.data);
+   hdmi->phy.enabled = false;
+   }
+
hdmi->bridge_is_on = false;
 }
 
@@ -1611,8 +1637,7 @@ dw_hdmi_connector_detect(struct drm_connector *co

[PATCH v4 0/9] drm: bridge: dw-hdmi: Refactor PHY support

[Laurent Pinchart]

Hello,

This patch series refactors all the PHY handling code in order to allow
support of vendor PHYs and Synopsys DWC HDMI 2.0 TX PHYs.

The series starts with a few cleanups and small fixes. Patch 1/9 just removes
unused code, patch 2/9 moves the color converter code out of the PHY configure
function as it isn't PHY-dependent, and patch 3/9 enables color conversion
even for DVI as it is needed to output RGB when the input format is YUV.

The next two patches fix the power down (4/9) and up (5/9) sequences to comply
with the HDMI TX PHY specifications. They are the biggest functional changes
in the whole set, and have been tested successfully (with the rest of the
series) on i.MX6Q and R-Car H3. I'll try to perform tests on RK3288 tomorrow
if nobody beats me to it (Neil, that's for you :-)). The PLL PHY lock delay
has been measured to be between 300µs and 350µs on R-Car H3 and between 400µs
and 600µs on i.MX6Q. The PHY power down delay has been measured to be less
than 50µs on both platforms, and was often close to instant with power down
reported in the first poll iteration. We should thus be more than safe with a
5ms timeout.

Patch 6/9 breaks the PHY operations out. Glue code is then allowed to pass a
PHY operations structure to support vendor PHYs. The existing PHY support code
is turned into a default Synopsys PHYs implementation for those PHY
operations.

Patch 7/9 further refactors the Synopsys PHY configuration function to make
it modular, in order to support DWC HDMI 2.0 TX PHYs that have a very
different register layout compared to the currently supported PHYs. Glue code
is again allowed to provide a custom PHY configuration implementation, with
the existing PHY support code turned into the default implementation for all
currently supported Synopsys PHYs.

Patch 8/9 is a small cleanup that removes the now unneeded device type for
glue code platform data, and patch 9/9 follows by switching the driver to
regmap in order to support vendor-specific register access more easily.

Kieran Bingham (2):
  drm: bridge: dw-hdmi: Add support for custom PHY configuration
  drm: bridge: dw-hdmi: Remove device type from platform data

Laurent Pinchart (5):
  drm: bridge: dw-hdmi: Remove unused functions
  drm: bridge: dw-hdmi: Move CSC configuration out of PHY code
  drm: bridge: dw-hdmi: Fix the PHY power down sequence
  drm: bridge: dw-hdmi: Fix the PHY power up sequence
  drm: bridge: dw-hdmi: Create PHY operations

Neil Armstrong (2):
  drm: bridge: dw-hdmi: Enable CSC even for DVI
  drm: bridge: dw-hdmi: Switch to regmap for register access

 drivers/gpu/drm/bridge/dw-hdmi.c| 467 +---
 drivers/gpu/drm/imx/dw_hdmi-imx.c   |   2 -
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |   1 -
 include/drm/bridge/dw_hdmi.h|  33 +-
 4 files changed, 304 insertions(+), 199 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH v4 8/9] drm: bridge: dw-hdmi: Remove device type from platform data

[Laurent Pinchart]

From: Kieran Bingham 

The device type isn't used anymore now that workarounds and PHY-specific
operations are performed based on version information read at runtime.
Remove it.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c| 2 --
 drivers/gpu/drm/imx/dw_hdmi-imx.c   | 2 --
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
 include/drm/bridge/dw_hdmi.h| 7 ---
 4 files changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index b835d81bb471..132c00685796 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -127,7 +127,6 @@ struct dw_hdmi {
struct drm_connector connector;
struct drm_bridge bridge;
 
-   enum dw_hdmi_devtype dev_type;
unsigned int version;
 
struct platform_device *audio;
@@ -2014,7 +2013,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
 
hdmi->plat_data = plat_data;
hdmi->dev = dev;
-   hdmi->dev_type = plat_data->dev_type;
hdmi->sample_rate = 48000;
hdmi->disabled = true;
hdmi->rxsense = true;
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index f645275e6e63..f039641070ac 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -175,7 +175,6 @@ static struct dw_hdmi_plat_data imx6q_hdmi_drv_data = {
.mpll_cfg   = imx_mpll_cfg,
.cur_ctr= imx_cur_ctr,
.phy_config = imx_phy_config,
-   .dev_type   = IMX6Q_HDMI,
.mode_valid = imx6q_hdmi_mode_valid,
 };
 
@@ -183,7 +182,6 @@ static struct dw_hdmi_plat_data imx6dl_hdmi_drv_data = {
.mpll_cfg = imx_mpll_cfg,
.cur_ctr  = imx_cur_ctr,
.phy_config = imx_phy_config,
-   .dev_type = IMX6DL_HDMI,
.mode_valid = imx6dl_hdmi_mode_valid,
 };
 
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index a6d4a0236e8f..d53827413996 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -237,7 +237,6 @@ static const struct dw_hdmi_plat_data 
rockchip_hdmi_drv_data = {
.mpll_cfg   = rockchip_mpll_cfg,
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
-   .dev_type   = RK3288_HDMI,
 };
 
 static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index dd330259a3dc..545f04fae3b6 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -21,12 +21,6 @@ enum {
DW_HDMI_RES_MAX,
 };
 
-enum dw_hdmi_devtype {
-   IMX6Q_HDMI,
-   IMX6DL_HDMI,
-   RK3288_HDMI,
-};
-
 enum dw_hdmi_phy_type {
DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
@@ -65,7 +59,6 @@ struct dw_hdmi_phy_ops {
 };
 
 struct dw_hdmi_plat_data {
-   enum dw_hdmi_devtype dev_type;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
   struct drm_display_mode *mode);
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v4 9/9] drm: bridge: dw-hdmi: Switch to regmap for register access

[Laurent Pinchart]

From: Neil Armstrong 

The Synopsys Designware HDMI TX Controller does not enforce register
access on platforms instanciating it. The current driver supports two
different types of memory-mapped flat register access, but in order to
support the Amlogic Meson SoCs integration, and provide a more generic
way to handle all sorts of register mapping, switch the register access
to use the regmap infrastructure.

In the case of registers that are not flat memory-mapped or do not
conform to the current driver implementation, a regmap struct can be
given in the plat_data and be used at probe or bind.

Since the AHB audio driver is only available with direct memory access,
only allow the I2S audio driver to be registered is directly
memory-mapped.

Signed-off-by: Neil Armstrong 
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 109 +--
 include/drm/bridge/dw_hdmi.h |   1 +
 2 files changed, 59 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 132c00685796..026a0dce7661 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -171,8 +172,8 @@ struct dw_hdmi {
unsigned int audio_n;
bool audio_enable;
 
-   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
-   u8 (*read)(struct dw_hdmi *hdmi, int offset);
+   unsigned int reg_shift;
+   struct regmap *regm;
 };
 
 #define HDMI_IH_PHY_STAT0_RX_SENSE \
@@ -183,42 +184,23 @@ struct dw_hdmi {
(HDMI_PHY_RX_SENSE0 | HDMI_PHY_RX_SENSE1 | \
 HDMI_PHY_RX_SENSE2 | HDMI_PHY_RX_SENSE3)
 
-static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)
-{
-   writel(val, hdmi->regs + (offset << 2));
-}
-
-static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
-{
-   return readl(hdmi->regs + (offset << 2));
-}
-
-static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
-{
-   writeb(val, hdmi->regs + offset);
-}
-
-static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
-{
-   return readb(hdmi->regs + offset);
-}
-
 static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
-   hdmi->write(hdmi, val, offset);
+   regmap_write(hdmi->regm, offset << hdmi->reg_shift, val);
 }
 
 static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
-   return hdmi->read(hdmi, offset);
+   unsigned int val = 0;
+
+   regmap_read(hdmi->regm, offset << hdmi->reg_shift, &val);
+
+   return val;
 }
 
 static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
 {
-   u8 val = hdmi_readb(hdmi, reg) & ~mask;
-
-   val |= data & mask;
-   hdmi_writeb(hdmi, val, reg);
+   regmap_update_bits(hdmi->regm, reg << hdmi->reg_shift, mask, data);
 }
 
 static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
@@ -1989,6 +1971,20 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
return -ENODEV;
 }
 
+static const struct regmap_config hdmi_regmap_8bit_config = {
+   .reg_bits   = 32,
+   .val_bits   = 8,
+   .reg_stride = 1,
+   .max_register   = HDMI_I2CM_FS_SCL_LCNT_0_ADDR,
+};
+
+static const struct regmap_config hdmi_regmap_32bit_config = {
+   .reg_bits   = 32,
+   .val_bits   = 32,
+   .reg_stride = 4,
+   .max_register   = HDMI_I2CM_FS_SCL_LCNT_0_ADDR << 2,
+};
+
 static struct dw_hdmi *
 __dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
@@ -1998,7 +1994,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
struct platform_device_info pdevinfo;
struct device_node *ddc_node;
struct dw_hdmi *hdmi;
-   struct resource *iores;
+   struct resource *iores = NULL;
int irq;
int ret;
u32 val = 1;
@@ -2022,22 +2018,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
mutex_init(&hdmi->audio_mutex);
spin_lock_init(&hdmi->audio_lock);
 
-   of_property_read_u32(np, "reg-io-width", &val);
-
-   switch (val) {
-   case 4:
-   hdmi->write = dw_hdmi_writel;
-   hdmi->read = dw_hdmi_readl;
-   break;
-   case 1:
-   hdmi->write = dw_hdmi_writeb;
-   hdmi->read = dw_hdmi_readb;
-   break;
-   default:
-   dev_err(dev, "reg-io-width must be 1 or 4\n");
-   return ERR_PTR(-EINVAL);
-   }
-
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
@@ -2051,11 +2031,38 @@ __dw_hdmi_probe(struct platform_device *pdev,
dev_dbg(hdmi->dev, "no ddc property found\n");
}
 
-   iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   hdmi->regs = 

Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

[Laurent Pinchart]

Hi Jose,

On Wednesday 01 Mar 2017 16:25:46 Jose Abreu wrote:
> On 01-03-2017 11:09, Laurent Pinchart wrote:
> > On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> >> On 05-01-2017 12:29, Laurent Pinchart wrote:
> >>> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
>  On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> > On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> >> Instead of spreading version-dependent PHY power handling code
> >> around, group it in two functions to power the PHY on and off and use
> >> them through the driver.
> >> 
> >> Powering off the PHY at the beginning of the setup phase is currently
> >> split in two locations for first and second generation PHYs, group
> >> all the operations in the dw_hdmi_phy_init() function.
> > 
> > This changes the behaviour of the driver.
> > 
> >> +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> >> +{
> >> +  if (hdmi->phy->gen == 1) {
> >> +  dw_hdmi_phy_enable_tmds(hdmi, 0);
> >> +  dw_hdmi_phy_enable_powerdown(hdmi, true);
> >> +  } else {
> >> +  dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> >> +  dw_hdmi_phy_gen2_pddq(hdmi, 1);
> >> +  }
> >> +}
> >> @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> >> *hdmi)
> >>if (!hdmi->phy_enabled)
> >>return;
> >> 
> >> -  dw_hdmi_phy_enable_tmds(hdmi, 0);
> >> -  dw_hdmi_phy_enable_powerdown(hdmi, true);
> >> -
> >> +  dw_hdmi_phy_power_off(hdmi);
> > 
> > This makes dw_hdmi_phy_disable() power down a gen2 phy.
> > 
> > The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> > gen2 phy.  I've been carrying this change for a while, which I've had
> > to revert (and finally expunge), as it causes problems on iMX6:
> > 
> > @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi)
> > if (!hdmi->phy_enabled)
> > return;
> > 
> > +   /* Actually set the phy into low power mode */
> > +   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> > +
> > +   /* FIXME: We should wait for TX_READY to be deasserted */
> > +
> > +   dw_hdmi_phy_gen2_pddq(hdmi, 1);
> > +
> > +   /* This appears to have no effect on iMX6 */
> > dw_hdmi_phy_enable_tmds(hdmi, 0);
> > dw_hdmi_phy_enable_powerdown(hdmi, true);
> > 
> > So, I think your change here will cause problems for iMX6.
> > 
> > From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> > bouncing when the PHY is powered down.  I can't promise when I'll be
> > able to check for that again.
>  
>  Indeed TX_READY must be low before asserting pddq.
> >>> 
> >>> The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
> >>> output signal, but there seems to be no HDMI TX register from which its
> >>> state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
> >>> through I2C ? How long is the PHY expected to take to set TX_READY to 0
> >>> ?
> >> 
> >> TX_READY can be read from register 0x1A of phy, BIT(2) (through
> >> I2C). Not sure if same offset for all phys though.
> > 
> > I have been told that another option is to poll the TX_PHY_LOCK bit in the
> > phy_stat0 register. That would be a simpler solution that doesn't require
> > I2C access. Could you confirm (or disconfirm) this ?
> 
> Yes (In our implementation we have TX_PHY_LOCK wired up to
> TX_READY that comes from phy. But if using a custom phy or an
> unusual implementation then this may not hold).

Thank you for the information. I've submitted a v4 that poll the TX_PHY_LOCK 
bit.  With the patch series applied the vendor PHY handling code already 
delegates PHY power control to the glue code, there's thus no issue there. For 
platforms using a Synopsys PHY, all the ones we have to support today have 
TX_READY wired to the PHY lock signal so we should be good as well there. If 
that doesn't remain true in the future we'll fix it.

>  HPD and RXSENSE should work in power down mode by enabling enhpdrxsense
>  bit in phy_conf0 BUT to enter power down you must disable TX_PWRON,
>  enhpdrxsense and enable PDDQ and PHY_RESET. Only after doing this (and
>  consequently entering power down mode) you can enable again
>  enhpdrxsense.
> >>> 
> >>> Thanks, I'll give it a try.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup

[Noralf Trønnes]

Den 01.03.2017 15.31, skrev Daniel Vetter:

On Fri, Jan 27, 2017 at 03:29:29PM +0100, Daniel Vetter wrote:

On Fri, Jan 27, 2017 at 03:23:43PM +0100, Noralf Trønnes wrote:

Den 27.01.2017 08.49, skrev Daniel Vetter:

On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote:

This patchset removes the need for drivers to clean up their debugfs
files on exit. It is done automatically in drm_debugfs_cleanup().
This funtion is also called should the driver error out in it's
drm_driver.debugfs_init callback.

Two drivers still use drm_debugfs_remove_files():
- tegra in it's connectors, not sure if I can remove it.

I read through them, and they're removed on the component device nodes
stuff. That looks somewhat fishy from a lifetime point of view, and I
think removing all that code would be better, too.


- qxl because it's debugfs files list is part of struct qxl_device which
is freed on unload before drm_minor_unregister() is called cleaning debugfs.

In -next qxl is already demidlayered and there's no longer an unload hook.
This should be all safe ... why is it not?

My bad, I fetched linux-next a few days ago and figured it was
up-to-date-enough. Duh, I should have known better after following drm for
a year now, it is constantly changing, no pauses.

Can you please ping me when you have pulled driver patches and I'll respin
msm, tegra and qxl (and others if necessary), and remove the hook.
It's much easier for me to do a small patchset, it's really a strain to get
everything lined up correctly with big changes. I didn't have that patch
juggling class when in school, so I'm late to the game :-)

You're doing great with the patch juggling :-) I've just made a pass
through the series and merge what's already reviewed/acked.

Ok, pulled in the remaining patch (I hope, pls ping if I missed one). We
have only a few debugfs_remove calls left, and I think it's safe to remove
them all too. Up to do that too? Then we could remove the export, to make
sure no new driver gets this wrong ...


Yes, they're all in now. I'll fix up what's left.

Noralf.


Thanks a lot, Daniel


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

Re: [PATCH 1/2] drm: Use pr_cont where appropriate

[Alex Deucher]

On Mon, Feb 27, 2017 at 8:31 PM, Joe Perches  wrote:
> Using 'printk("\n")' is not preferred anymore and
> using printk to continue logging messages now produces
> multiple line logging output unless the continuations
> use KERN_CONT.
>
> Convert these uses to appropriately use pr_cont or a
> single printk where possible.
>
> Miscellanea:
>
> o Use a temporary const char * instead of multiple printks
> o Remove trailing space from logging by using a leading space instead
>
> Signed-off-by: Joe Perches 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 70 
>  drivers/gpu/drm/radeon/r600_dpm.c   | 71 
> +
>  2 files changed, 73 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
> index 6ca0333ca4c0..38e9b0d3659a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c
> @@ -31,86 +31,88 @@
>
>  void amdgpu_dpm_print_class_info(u32 class, u32 class2)
>  {
> -   printk("\tui class: ");
> +   const char *s;
> +
> switch (class & ATOM_PPLIB_CLASSIFICATION_UI_MASK) {
> case ATOM_PPLIB_CLASSIFICATION_UI_NONE:
> default:
> -   printk("none\n");
> +   s = "none";
> break;
> case ATOM_PPLIB_CLASSIFICATION_UI_BATTERY:
> -   printk("battery\n");
> +   s = "battery";
> break;
> case ATOM_PPLIB_CLASSIFICATION_UI_BALANCED:
> -   printk("balanced\n");
> +   s = "balanced";
> break;
> case ATOM_PPLIB_CLASSIFICATION_UI_PERFORMANCE:
> -   printk("performance\n");
> +   s = "performance";
> break;
> }
> -   printk("\tinternal class: ");
> +   printk("\tui class: %s\n", s);
> +   printk("\tinternal class:");
> if (((class & ~ATOM_PPLIB_CLASSIFICATION_UI_MASK) == 0) &&
> (class2 == 0))
> -   printk("none");
> +   pr_cont(" none");
> else {
> if (class & ATOM_PPLIB_CLASSIFICATION_BOOT)
> -   printk("boot ");
> +   pr_cont(" boot");
> if (class & ATOM_PPLIB_CLASSIFICATION_THERMAL)
> -   printk("thermal ");
> +   pr_cont(" thermal");
> if (class & ATOM_PPLIB_CLASSIFICATION_LIMITEDPOWERSOURCE)
> -   printk("limited_pwr ");
> +   pr_cont(" limited_pwr");
> if (class & ATOM_PPLIB_CLASSIFICATION_REST)
> -   printk("rest ");
> +   pr_cont(" rest");
> if (class & ATOM_PPLIB_CLASSIFICATION_FORCED)
> -   printk("forced ");
> +   pr_cont(" forced");
> if (class & ATOM_PPLIB_CLASSIFICATION_3DPERFORMANCE)
> -   printk("3d_perf ");
> +   pr_cont(" 3d_perf");
> if (class & ATOM_PPLIB_CLASSIFICATION_OVERDRIVETEMPLATE)
> -   printk("ovrdrv ");
> +   pr_cont(" ovrdrv");
> if (class & ATOM_PPLIB_CLASSIFICATION_UVDSTATE)
> -   printk("uvd ");
> +   pr_cont(" uvd");
> if (class & ATOM_PPLIB_CLASSIFICATION_3DLOW)
> -   printk("3d_low ");
> +   pr_cont(" 3d_low");
> if (class & ATOM_PPLIB_CLASSIFICATION_ACPI)
> -   printk("acpi ");
> +   pr_cont(" acpi");
> if (class & ATOM_PPLIB_CLASSIFICATION_HD2STATE)
> -   printk("uvd_hd2 ");
> +   pr_cont(" uvd_hd2");
> if (class & ATOM_PPLIB_CLASSIFICATION_HDSTATE)
> -   printk("uvd_hd ");
> +   pr_cont(" uvd_hd");
> if (class & ATOM_PPLIB_CLASSIFICATION_SDSTATE)
> -   printk("uvd_sd ");
> +   pr_cont(" uvd_sd");
> if (class2 & ATOM_PPLIB_CLASSIFICATION2_LIMITEDPOWERSOURCE_2)
> -   printk("limited_pwr2 ");
> +   pr_cont(" limited_pwr2");
> if (class2 & ATOM_PPLIB_CLASSIFICATION2_ULV)
> -   printk("ulv ");
> +   pr_cont(" ulv");
> if (class2 & ATOM_PPLIB_CLASSIFICATION2_MVC)
> -   printk("uvd_mvc ");
> +   pr_cont(" uvd_mvc");
> }
> -   printk("\n");
> +   pr_cont("\n");
>  }
>
>  void amdgpu_dpm_print_cap_info(u32 caps)
>  {
> -   printk("\tcaps: ");
> +   printk("\tcaps:");
> if (caps & ATOM_PPLIB_SINGLE_DISPLAY_ONLY)
> -   printk("single_disp ");
> +   pr_cont(" single_disp");

Re: [PATCH 4/5] drm/amd/display: Add HDMI Stereo 3D (DC) support

[Harry Wentland]

On 2017-02-24 07:14 PM, Jeff Smith wrote:

Signed-off-by: Jeff Smith 
---
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 32 --
 .../display/dc/dce110/dce110_timing_generator.c|  4 ---
 2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index 3912dc8..eda813e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
@@ -649,8 +649,7 @@ static void update_stream_scaling_settings(
return;

/* Full screen scaling by default */
-   src.width = mode->hdisplay;
-   src.height = mode->vdisplay;
+   drm_crtc_get_hv_timing(mode, &src.width, &src.height);
dst.width = stream->timing.h_addressable;
dst.height = stream->timing.v_addressable;

@@ -853,7 +852,22 @@ static void fill_stream_properties_from_drm_display_mode(
else
timing_out->pixel_encoding = PIXEL_ENCODING_RGB;

-   timing_out->timing_3d_format = TIMING_3D_FORMAT_NONE;
+   switch (mode_in->flags & DRM_MODE_FLAG_3D_MASK) {
+   case DRM_MODE_FLAG_3D_FRAME_PACKING:
+   timing_out->timing_3d_format = 
TIMING_3D_FORMAT_SW_FRAME_PACKING;
+   break;
+   case DRM_MODE_FLAG_3D_TOP_AND_BOTTOM:
+   timing_out->timing_3d_format = TIMING_3D_FORMAT_TB_SW_PACKED;
+   break;
+   case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF:
+   timing_out->timing_3d_format = TIMING_3D_FORMAT_SBS_SW_PACKED;
+   break;
+   case DRM_MODE_FLAG_3D_NONE:
+   default:
+   timing_out->timing_3d_format = TIMING_3D_FORMAT_NONE;
+   break;
+   }
+


Are these tested and if so on which displays? Even though we have some 
of this code in place we haven't tested any of it and don't necessarily 
expect it to work.


Harry


timing_out->display_color_depth = convert_color_depth_from_display_info(
connector);
timing_out->scan_type = SCANNING_TYPE_NODATA;
@@ -1028,6 +1042,7 @@ static struct dc_stream *create_stream_for_sink(
dm_state->scaling != RMX_OFF);
}

+   drm_mode_set_crtcinfo(&mode, CRTC_STEREO_DOUBLE_ONLY);
fill_stream_properties_from_drm_display_mode(stream,
&mode, &aconnector->base);
update_stream_scaling_settings(&mode, dm_state, stream);
@@ -1558,13 +1573,12 @@ int amdgpu_dm_connector_mode_valid(
goto stream_create_fail;
}

-   drm_mode_set_crtcinfo(mode, 0);
+   drm_mode_set_crtcinfo(mode, CRTC_STEREO_DOUBLE);
fill_stream_properties_from_drm_display_mode(stream, mode, connector);

val_set.stream = stream;
val_set.surface_count = 0;
-   stream->src.width = mode->hdisplay;
-   stream->src.height = mode->vdisplay;
+   drm_crtc_get_hv_timing(mode, &stream->src.width, &stream->src.height);
stream->dst = stream->src;

if (dc_validate_resources(adev->dm.dc, &val_set, 1))
@@ -1793,14 +1807,13 @@ int dm_create_validation_set_for_connector(struct 
drm_connector *connector,
return result;
}

-   drm_mode_set_crtcinfo(mode, 0);
+   drm_mode_set_crtcinfo(mode, CRTC_STEREO_DOUBLE);

fill_stream_properties_from_drm_display_mode(stream, mode, connector);

val_set->stream = stream;

-   stream->src.width = mode->hdisplay;
-   stream->src.height = mode->vdisplay;
+   drm_crtc_get_hv_timing(mode, &stream->src.width, &stream->src.height);
stream->dst = stream->src;

return MODE_OK;
@@ -2073,6 +2086,7 @@ void amdgpu_dm_connector_init_helper(
aconnector->dc_link = link;
aconnector->base.interlace_allowed = true;
aconnector->base.doublescan_allowed = true;
+   aconnector->base.stereo_allowed = true;
aconnector->base.dpms = DRM_MODE_DPMS_OFF;
aconnector->hpd.hpd = AMDGPU_HPD_NONE; /* not used */

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_timing_generator.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_timing_generator.c
index f4b8576..fa06816 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_timing_generator.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_timing_generator.c
@@ -1113,10 +1113,6 @@ bool dce110_timing_generator_validate_timing(
if (!timing)
return false;

-   /* Currently we don't support 3D, so block all 3D timings */
-   if (timing->timing_3d_format != TIMING_3D_FORMAT_NONE)
-   return false;
-
/* Temporarily blocking interlacing mode until it's supported */
if (timing->flags.INTERLACE == 1)
return false;


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

Re: [PATCH 1/3] gpu: drm: amd/radeon: Convert printk(KERN_ to pr_

[Alex Deucher]

On Tue, Feb 28, 2017 at 7:55 AM, Joe Perches  wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches 

Applied.  Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c   |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/atom.c  | 44 -
>  drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  4 +-
>  drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  4 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  4 +-
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  4 +-
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 ++--
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 ++--
>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  4 +-
>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 +-
>  drivers/gpu/drm/amd/include/amd_pcie_helpers.h |  4 +-
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  2 +-
>  drivers/gpu/drm/amd/powerplay/inc/pp_debug.h   |  2 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  4 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++---
>  .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  4 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  4 +-
>  drivers/gpu/drm/radeon/atom.c  | 46 --
>  drivers/gpu/drm/radeon/cik.c   | 56 
> --
>  drivers/gpu/drm/radeon/evergreen.c |  2 +-
>  drivers/gpu/drm/radeon/evergreen_cs.c  |  7 ++-
>  drivers/gpu/drm/radeon/ni.c| 22 +++--
>  drivers/gpu/drm/radeon/r100.c  | 18 +++
>  drivers/gpu/drm/radeon/r200.c  |  3 +-
>  drivers/gpu/drm/radeon/r300.c  | 13 ++---
>  drivers/gpu/drm/radeon/r420.c  |  9 ++--
>  drivers/gpu/drm/radeon/r520.c  |  3 +-
>  drivers/gpu/drm/radeon/r600.c  | 21 +++-
>  drivers/gpu/drm/radeon/r600_cs.c   |  7 ++-
>  drivers/gpu/drm/radeon/radeon.h|  3 +-
>  drivers/gpu/drm/radeon/radeon_atpx_handler.c   |  4 +-
>  drivers/gpu/drm/radeon/radeon_audio.c  |  4 +-
>  drivers/gpu/drm/radeon/radeon_clocks.c |  2 +-
>  drivers/gpu/drm/radeon/radeon_device.c |  8 ++--
>  drivers/gpu/drm/radeon/radeon_fb.c |  3 +-
>  drivers/gpu/drm/radeon/radeon_gem.c|  4 +-
>  drivers/gpu/drm/radeon/radeon_test.c   |  6 +--
>  drivers/gpu/drm/radeon/rs400.c |  4 +-
>  drivers/gpu/drm/radeon/rs690.c |  3 +-
>  drivers/gpu/drm/radeon/rv515.c |  9 ++--
>  drivers/gpu/drm/radeon/si.c| 45 ++---
>  46 files changed, 172 insertions(+), 268 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index c1b913541739..3f636632c289 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1515,7 +1515,8 @@ void amdgpu_mm_wdoorbell(struct amdgpu_device *adev, 
> u32 index, u32 v);
>   */
>  #define RREG32(reg) amdgpu_mm_rreg(adev, (reg), false)
>  #define RREG32_IDX(reg) amdgpu_mm_rreg(adev, (reg), true)
> -#define DREG32(reg) printk(KERN_INFO "REGISTER: " #reg " : 0x%08X\n", 
> amdgpu_mm_rreg(adev, (reg), false))
> +#define DREG32(reg) pr_info("REGISTER: " #reg " : 0x%08X\n",   \
> +   amdgpu_mm_rreg(adev, (reg), false))
>  #define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v), false)
>  #define WREG32_IDX(reg, v) amdgpu_mm_wreg(adev, (reg), (v), true)
>  #define REG_SET(FIELD, v) (((v) << FIELD##_SHIFT) & FIELD##_MASK)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
> index 857ba0897159..3889486f71fe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
> @@ -74,9 +74,9 @@ static void amdgpu_afmt_calc_cts(uint32_t clock, int *CTS, 
> int *N, int freq)
>
> /* Check that we are in spec (not always possible) */
> if (n < (128*freq/1500))
> -   printk(KERN_WARNING "Calculated ACR N value is too small. You 
> may experience audio problems.\n");
> +   pr_warn("Calculated ACR N value is too small. You may 
> experience audio problems.\n");
> if (n > (128*freq/300))
> -   printk(KERN_WARNING "Calculated ACR N value is too large. You 
> may experience audio problems.\n");
>

Re: [PATCH 5/5] drm/amd/display: Allow HDMI capabilities over DVI connector (DC)

[Harry Wentland]

On 2017-02-24 07:14 PM, Jeff Smith wrote:

Signed-off-by: Jeff Smith 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 2b92939..168f260 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -706,8 +706,13 @@ bool dc_link_detect(const struct dc_link *dc_link, bool 
boot)

/* HDMI-DVI Dongle */
if (dc_sink->sink_signal == SIGNAL_TYPE_HDMI_TYPE_A &&
-   !dc_sink->edid_caps.edid_hdmi)
+   !dc_sink->edid_caps.edid_hdmi) {
dc_sink->sink_signal = SIGNAL_TYPE_DVI_SINGLE_LINK;
+   } else if ((dc_sink->sink_signal == SIGNAL_TYPE_DVI_SINGLE_LINK 
||
+   dc_sink->sink_signal == SIGNAL_TYPE_DVI_DUAL_LINK) 
&&
+   dc_sink->edid_caps.edid_hdmi) {
+   dc_sink->sink_signal = SIGNAL_TYPE_HDMI_TYPE_A;
+   }


This won't pass HDMI compliance.

Harry



/* Connectivity log: detection */
for (i = 0; i < sink->public.dc_edid.length / EDID_BLOCK_SIZE; 
i++) {


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

Re: [PATCH v3 06/13] drm: bridge: Add LVDS encoder driver

[Laurent Pinchart]

Hi Daniel,

On Wednesday 04 Jan 2017 17:13:23 Laurent Pinchart wrote:
> On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote:
> > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote:
> >> On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote:
> >>> Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be
> >>> enough, or not? My idea is to use this for the case where the only
> >>> thing in dt is the panel, with no real bridge chip. And I think we
> >>> don't need anything beyond that one _init function, plus maybe some
> >>> additional paramaters ...
> >> 
> >> There should be no bridge then. If you want the DRM core to manage
> >> panels automatically, then we should create specific helpers for that,
> >> not abuse the bridge infrastructure. Bridges should be instantiated from
> >> a hardware device and bound to drivers as usual.
> > 
> > I guess that's the part where I disagree: Just because there's physically
> > no bridge doesn't mean we shouldn't just treat it as one in the software
> > abstraction. If it looks and acts like a bridge (even an empty one), then
> > imo it can be a bridge.
> > 
> > If you insist on panels being panels, then I guess we need some other kind
> > of glue to bind them into arbitrary bridge chains. But given that the
> > callbacks match very closely, I don't see the point.
> > 
> > In an idea world a panel would probably derive from a drm_bridge, but
> > we're not in that universe unfortunately ;-)
> 
> Or both would derive from another object, but I agree that's how it should
> work. That's what I want to achieve, one step at a time. Creating dummy
> bridges isn't a step in that direction in my opinion, so I'd rather not do
> that, but work towards the right abstraction.

Do you object getting this patch merged as-is as a first step in the right 
direction ? :-)

-- 
Regards,

Laurent Pinchart

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

[RFC PATCH 2/3] v4l: vsp1: extend VSP1 module API to allow DRM callback registration

[Kieran Bingham]

To be able to perform page flips in DRM without flicker we need to be
able to notify the rcar-du module when the VSP has completed its
processing.

To synchronise the page flip events for userspace, we move the required
event through the VSP to track the data flow. When the frame is
completed, the event can be returned back to the originator through the
registered callback.

We must not have bidirectional dependencies on the two components to
maintain support for loadable modules, thus we extend the API to allow
a callback to be registered within the VSP DRM interface.

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c | 42 +--
 drivers/media/platform/vsp1/vsp1_drm.h | 12 -
 include/media/vsp1.h   |  6 +++-
 4 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b5bfbe50bd87..71e70e1e0881 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -81,7 +81,7 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
 
 void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
 {
-   vsp1_du_atomic_flush(crtc->vsp->vsp);
+   vsp1_du_atomic_flush(crtc->vsp->vsp, NULL);
 }
 
 /* Keep the two tables in sync. */
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 8e2aa3f8e52f..743cbce48d0c 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -52,6 +52,40 @@ int vsp1_du_init(struct device *dev)
 EXPORT_SYMBOL_GPL(vsp1_du_init);
 
 /**
+ * vsp1_du_register_callback - Register VSP completion notifier callback
+ *
+ * Allow the DRM framework to register a callback with us to notify the end of
+ * processing each frame. This allows synchronisation for page flipping.
+ *
+ * @dev: the VSP device
+ * @callback: the callback function to notify the DU module
+ * @private: private structure data to pass with the callback
+ *
+ */
+void vsp1_du_register_callback(struct device *dev,
+  void (*callback)(void *, void *),
+  void *private)
+{
+   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
+
+   vsp1->drm->du_complete = callback;
+   vsp1->drm->du_private = private;
+}
+EXPORT_SYMBOL_GPL(vsp1_du_register_callback);
+
+static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
+{
+   struct vsp1_drm *drm = to_vsp1_drm(pipe);
+
+   if (drm->du_complete && drm->active_data)
+   drm->du_complete(drm->du_private, drm->active_data);
+
+   /* The pending frame is now active */
+   drm->active_data = drm->pending_data;
+   drm->pending_data = NULL;
+}
+
+/**
  * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
  * @dev: the VSP device
  * @width: output frame width in pixels
@@ -99,7 +133,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int width,
}
 
pipe->num_inputs = 0;
-
+   pipe->frame_end = NULL;
+   vsp1->drm->du_complete = NULL;
vsp1_dlm_reset(pipe->output->dlm);
vsp1_device_put(vsp1);
 
@@ -196,6 +231,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
width,
if (ret < 0)
return ret;
 
+   pipe->frame_end = vsp1_du_pipeline_frame_end;
+
ret = media_entity_pipeline_start(&pipe->output->entity.subdev.entity,
  &pipe->pipe);
if (ret < 0) {
@@ -420,7 +457,7 @@ static unsigned int rpf_zpos(struct vsp1_device *vsp1, 
struct vsp1_rwpf *rpf)
  * vsp1_du_atomic_flush - Commit an atomic update
  * @dev: the VSP device
  */
-void vsp1_du_atomic_flush(struct device *dev)
+void vsp1_du_atomic_flush(struct device *dev, void *data)
 {
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_pipeline *pipe = &vsp1->drm->pipe;
@@ -504,6 +541,7 @@ void vsp1_du_atomic_flush(struct device *dev)
 
vsp1_dl_list_commit(pipe->dl);
pipe->dl = NULL;
+   vsp1->drm->pending_data = data;
 
/* Start or stop the pipeline if needed. */
if (!vsp1->drm->num_inputs && pipe->num_inputs) {
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index 9e28ab9254ba..fde19e5948a0 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -33,8 +33,20 @@ struct vsp1_drm {
struct v4l2_rect compose;
unsigned int zpos;
} inputs[VSP1_MAX_RPF];
+
+   /* Frame syncronisation */
+   void (*du_complete)(void *, void *);
+   void *du_private;
+   void *pending_data;
+   void *active_data;
 };
 
+static inline struct vsp1_drm *
+to_vsp1_drm(struct vsp1_pipeline *pipe)
+{
+   return container_of(pipe, struct vsp1_drm, pipe

[RFC PATCH 0/3] RCAR-DU, VSP1: Prevent pre-emptive frame flips on VSP1-DRM pipelines

[Kieran Bingham]

The RCAR-DU utilises a running VSPD pipeline to perform processing
for the display pipeline.

Changes to this pipeline are performed with an atomic flush operation which
updates the state in the VSPD. Due to the way the running pipeline is
operated, any flush operation has an implicit latency of one frame interval.

This comes about as the display list is committed, but not updated until the
next VSP1 interrupt. At this point the frame is being processed, but is not
complete until the following VSP1 frame end interrupt.

To prevent reporting page flips early, we must track this timing through the
VSP1, and only allow the rcar-du object to report the page-flip completion
event after the VSP1 has processed.

[PATCH 1/3] fixes the VSP DRM object to register it's pipeline correctly.
[PATCH 2/3] extends the VSP1 to allow a callback to be registered allowing the
VSP1 to notify completion events, and extend the existing atomic
flush API to allow private event data to be passed through.
[PATCH 3/3] Utilises this API extension to postpone page flips as required.

In current testing, with kmstest, and kmscube, it can be seen that our refresh
rate has halved. I believe this is due to the one frame latency imposed by the
VSPD and will need further investigation.

Kieran Bingham (3):
  v4l: vsp1: Register pipe with output WPF
  v4l: vsp1: extend VSP1 module API to allow DRM callback registration
  drm: rcar-du: Register a completion callback with VSP1

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 -
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 34 -
 drivers/media/platform/vsp1/vsp1_drm.c | 43 +--
 drivers/media/platform/vsp1/vsp1_drm.h | 12 -
 include/media/vsp1.h   |  6 +++-
 6 files changed, 99 insertions(+), 5 deletions(-)

base-commit: a194138cd82dff52d4c39895fd89dc6f26eafc97
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 3/3] drm: rcar-du: Register a completion callback with VSP1

[Kieran Bingham]

Updating the state in a running VSP1 requires two interrupts from the
VSP. Initially, the updated state will be committed - but only after the
VSP1 has completed processing it's current frame will the new state be
taken into account. As such, the committed state will only be 'completed'
after an extra frame completion interrupt.

Track this delay, by passing the frame flip event through the VSP
module; It will be returned only when the frame has completed and can be
returned to the caller.

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 34 ++-
 3 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7391dd95c733..0a824633a012 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -328,7 +328,7 @@ static bool rcar_du_crtc_page_flip_pending(struct 
rcar_du_crtc *rcrtc)
bool pending;
 
spin_lock_irqsave(&dev->event_lock, flags);
-   pending = rcrtc->event != NULL;
+   pending = (rcrtc->event != NULL) || (rcrtc->pending != NULL);
spin_unlock_irqrestore(&dev->event_lock, flags);
 
return pending;
@@ -578,6 +578,12 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
 
if (status & DSSR_FRM) {
+
+   if (rcrtc->pending) {
+   trace_printk("VBlank loss due to VSP Overrun\n");
+   return IRQ_HANDLED;
+   }
+
drm_crtc_handle_vblank(&rcrtc->crtc);
rcar_du_crtc_finish_page_flip(rcrtc);
ret = IRQ_HANDLED;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index a7194812997e..8374a858446a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -46,6 +46,7 @@ struct rcar_du_crtc {
bool started;
 
struct drm_pending_vblank_event *event;
+   struct drm_pending_vblank_event *pending;
wait_queue_head_t flip_wait;
 
unsigned int outputs;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 71e70e1e0881..408375aff1a0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,26 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
 
+static void rcar_du_vsp_complete(void *private, void *data)
+{
+   struct rcar_du_crtc *crtc = (struct rcar_du_crtc *)private;
+   struct drm_device *dev = crtc->crtc.dev;
+   struct drm_pending_vblank_event *event;
+   bool match;
+   unsigned long flags;
+
+   spin_lock_irqsave(&dev->event_lock, flags);
+   event = crtc->event;
+   crtc->event = data;
+   match = (crtc->event == crtc->pending);
+   crtc->pending = NULL;
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+
+   /* Safety checks */
+   WARN(event, "Event lost by VSP completion callback\n");
+   WARN(!match, "Stored pending event, does not match completion\n");
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = &crtc->crtc.state->adjusted_mode;
@@ -66,6 +86,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 */
crtc->group->need_restart = true;
 
+   vsp1_du_register_callback(crtc->vsp->vsp, rcar_du_vsp_complete, crtc);
+
vsp1_du_setup_lif(crtc->vsp->vsp, mode->hdisplay, mode->vdisplay);
 }
 
@@ -81,7 +103,17 @@ void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
 
 void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
 {
-   vsp1_du_atomic_flush(crtc->vsp->vsp, NULL);
+   struct drm_device *dev = crtc->crtc.dev;
+   struct drm_pending_vblank_event *event;
+   unsigned long flags;
+
+   /* Move the event to the VSP, track it locally as 'pending' */
+   spin_lock_irqsave(&dev->event_lock, flags);
+   event = crtc->pending = crtc->event;
+   crtc->event = NULL;
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+
+   vsp1_du_atomic_flush(crtc->vsp->vsp, event);
 }
 
 /* Keep the two tables in sync. */
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

[Peter Senna Tschudin]

Hi Archit,

Thank you for the review!

On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote:
> 
> 
> On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote:
> > The video processing pipeline on the second output on the GE B850v3:
> > 
> >   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
> > 
> > Each bridge has a dedicated flash containing firmware for supporting the
> > custom design. The result is that in this design neither the STDP4028
> > nor the STDP2690 behave as the stock bridges would. The compatible
> > strings include the suffix "-ge-b850v3-fw" to make it clear that the
> > driver is for the bridges with the firmware which is specific for the GE
> > B850v3.
> > 
> > The driver is powerless to control the video processing pipeline, as the
> > two bridges behaves as a single one. The driver is only needed for
> > telling the host about EDID / HPD, and for giving the host powers to ack
> > interrupts.
> > 
> > This driver adds one i2c_device for each bridge, but only one
> > drm_bridge. This design allows the creation of a functional connector
> > that is capable of reading EDID from the STDP2690 while handling
> > interrupts on the STDP4028.
> > 
> > Cc: Laurent Pinchart 
> > Cc: Martyn Welch 
> > Cc: Martin Donnelly 
> > Cc: Daniel Vetter 
> > Cc: Enric Balletbo i Serra 
> > Cc: Philipp Zabel 
> > Cc: Rob Herring 
> > Cc: Fabio Estevam 
> > Cc: David Airlie 
> > Cc: Thierry Reding 
> > Cc: Thierry Reding 
> > Cc: Archit Taneja 
> > Cc: Enric Balletbo 
> > Signed-off-by: Peter Senna Tschudin 
> > ---
> > Changes from V1:
> >  - Updated copyright year
> >  - Fixed blank line issues
> >  - Updated ge_b850v3_lvds_remove() to not rely on ge_b850v3_lvds_ptr->edid 
> > and
> >added a comment to explain the test.
> >  - Fixed checkpatch strict warnings about continuation lines. In one case
> >fixing the warning would cause the continuation line to be over 80 chars 
> > and
> >that strict warning remains.
> > 
> >  drivers/gpu/drm/bridge/Kconfig |  11 +
> >  drivers/gpu/drm/bridge/Makefile|   1 +
> >  .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   | 411 
> > +
> >  3 files changed, 423 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> > 
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index eb8688e..4a937f1 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
> >   Support the I2S Audio interface which is part of the Synopsis
> >   Designware HDMI block.
> > 
> > +config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > +   tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > +   depends on OF
> > +   select DRM_KMS_HELPER
> > +   select DRM_PANEL
> > +   ---help---
> > +  This is a driver for the display bridges of
> > +  GE B850v3 that convert dual channel LVDS
> > +  to DP++. This is used with the i.MX6 imx-ldb
> > +  driver. You are likely to say N here.
> > +
> >  config DRM_NXP_PTN3460
> > tristate "NXP PTN3460 DP/LVDS bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 2e83a785..af0b7cc 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> >  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
> >  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> >  obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
> > +obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> > megachips-stdp-ge-b850v3-fw.o
> >  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> >  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> >  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> > diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c 
> > b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> > new file mode 100644
> > index 000..6f82a44
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> > @@ -0,0 +1,411 @@
> > +/*
> > + * Driver for MegaChips STDP4028 with GE B850v3 firmware (LVDS-DP)
> > + * Driver for MegaChips STDP2690 with GE B850v3 firmware (DP-DP++)
> > +
> > + * Copyright (c) 2017, Collabora Ltd.
> > + * Copyright (c) 2017, General Electric Company
> > +
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms and conditions of the GNU General Public License,
> > + * version 2, as published by the Free Software Foundation.
> > +
> > + * This program is distributed in the hope 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.
> > +

[RFC PATCH 1/3] v4l: vsp1: Register pipe with output WPF

[Kieran Bingham]

The DRM object does not register the pipe with the WPF object. This is
used internally throughout the driver as a means of accessing the pipe.
As such this breaks operations which require access to the pipe from WPF
interrupts.

Register the pipe inside the WPF object after it has been declared as
the output.

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index cd209dccff1b..8e2aa3f8e52f 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -596,6 +596,7 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
pipe->bru = &vsp1->bru->entity;
pipe->lif = &vsp1->lif->entity;
pipe->output = vsp1->wpf[0];
+   pipe->output->pipe = pipe;
 
return 0;
 }
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

[Archit Taneja]

On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote:

The video processing pipeline on the second output on the GE B850v3:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Each bridge has a dedicated flash containing firmware for supporting the
custom design. The result is that in this design neither the STDP4028
nor the STDP2690 behave as the stock bridges would. The compatible
strings include the suffix "-ge-b850v3-fw" to make it clear that the
driver is for the bridges with the firmware which is specific for the GE
B850v3.

The driver is powerless to control the video processing pipeline, as the
two bridges behaves as a single one. The driver is only needed for
telling the host about EDID / HPD, and for giving the host powers to ack
interrupts.

This driver adds one i2c_device for each bridge, but only one
drm_bridge. This design allows the creation of a functional connector
that is capable of reading EDID from the STDP2690 while handling
interrupts on the STDP4028.

Cc: Laurent Pinchart 
Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Cc: David Airlie 
Cc: Thierry Reding 
Cc: Thierry Reding 
Cc: Archit Taneja 
Cc: Enric Balletbo 
Signed-off-by: Peter Senna Tschudin 
---
Changes from V1:
 - Updated copyright year
 - Fixed blank line issues
 - Updated ge_b850v3_lvds_remove() to not rely on ge_b850v3_lvds_ptr->edid and
   added a comment to explain the test.
 - Fixed checkpatch strict warnings about continuation lines. In one case
   fixing the warning would cause the continuation line to be over 80 chars and
   that strict warning remains.

 drivers/gpu/drm/bridge/Kconfig |  11 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   | 411 +
 3 files changed, 423 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688e..4a937f1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
  Support the I2S Audio interface which is part of the Synopsis
  Designware HDMI block.

+config DRM_MEGACHIPS_STDP_GE_B850V3_FW
+   tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+  This is a driver for the display bridges of
+  GE B850v3 that convert dual channel LVDS
+  to DP++. This is used with the i.MX6 imx-ldb
+  driver. You are likely to say N here.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a785..af0b7cc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c 
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
new file mode 100644
index 000..6f82a44
--- /dev/null
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -0,0 +1,411 @@
+/*
+ * Driver for MegaChips STDP4028 with GE B850v3 firmware (LVDS-DP)
+ * Driver for MegaChips STDP2690 with GE B850v3 firmware (DP-DP++)
+
+ * Copyright (c) 2017, Collabora Ltd.
+ * Copyright (c) 2017, General Electric Company
+
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+
+ * This program is distributed in the hope 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.
+
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+
+ * This driver creates a drm_bridge and a drm_connector for the LVDS to DP++
+ * display bridge of the GE B850v3. There are two physical bridges on the video
+ * signal pipeline: a STDP4028(LVDS to DP) and a STDP2690(DP to DP++). The
+ * physical bridges are automatically configured by the input video signal, and
+ * the driver has no access to the video processing pipeline. The d

Re: [PATCH V2 3/4] drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)

[Peter Senna Tschudin]

On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote:
[...]
> > +static const struct i2c_device_id stdp2690_ge_b850v3_fw_i2c_table[] = {
> > +   {"stdp2690_ge_fw", 0},
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(i2c, stdp2690_ge_b850v3_fw_i2c_table);
> > +
> > +static const struct of_device_id stdp2690_ge_b850v3_fw_match[] = {
> > +   { .compatible = "megachips,stdp2690-ge-b850v3-fw" },
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, stdp2690_ge_b850v3_fw_match);
> > +
> > +static struct i2c_driver stdp2690_ge_b850v3_fw_driver = {
> > +   .id_table   = stdp2690_ge_b850v3_fw_i2c_table,
> > +   .probe  = stdp2690_ge_b850v3_fw_probe,
> > +   .remove = stdp2690_ge_b850v3_fw_remove,
> > +   .driver = {
> > +   .name   = "stdp2690-ge-b850v3-fw",
> > +   .of_match_table = stdp2690_ge_b850v3_fw_match,
> > +   },
> > +};
> > +module_i2c_driver(stdp2690_ge_b850v3_fw_driver);
> 
> Didn't catch this in the last series, but there can only be one
> module_init call per module. This breaks compilation when the
> driver is built as a module.
> 
> You could do something like:
> 
> static int __init stdp_ge_b850v3_init(void)
> {
>   int ret;
> 
>   ret = i2c_add_driver(&stdp4028_ge_b850v3_fw_driver);
>   if (ret)
>   return ret;
> 
>   return i2c_add_driver(&stdp2690_ge_b850v3_fw_driver);
> }
> module_init(stdp_ge_b850v3_init);
> 
> static void __exit stdp_ge_b850v3_exit(void)
> {
>   i2c_del_driver(&stdp2690_ge_b850v3_fw_driver);
>   i2c_del_driver(&stdp4028_ge_b850v3_fw_driver);
> }
> module_exit(stdp_ge_b850v3_exit);
> 
> Thanks,
> Archit

This has the init and exit functions merged and no need for the mutex
anymore. Compiled and run as a module and works fine. What do you think?

commit 15f8bf1b50d69454adeb32b5ff86c953124279fd
Author: Peter Senna Tschudin 
Date:   Wed May 25 00:59:17 2016 +0200

drm/bridge: Drivers for megachips-stdp-ge-b850v3-fw (LVDS-DP++)

The video processing pipeline on the second output on the GE B850v3:

  Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output

Each bridge has a dedicated flash containing firmware for supporting the
custom design. The result is that in this design neither the STDP4028
nor the STDP2690 behave as the stock bridges would. The compatible
strings include the suffix "-ge-b850v3-fw" to make it clear that the
driver is for the bridges with the firmware which is specific for the GE
B850v3.

The driver is powerless to control the video processing pipeline, as the
two bridges behaves as a single one. The driver is only needed for
telling the host about EDID / HPD, and for giving the host powers to ack
interrupts.

This driver adds one i2c_device for each bridge, but only one
drm_bridge. This design allows the creation of a functional connector
that is capable of reading EDID from the STDP2690 while handling
interrupts on the STDP4028.

Cc: Laurent Pinchart 
Cc: Martyn Welch 
Cc: Martin Donnelly 
Cc: Daniel Vetter 
Cc: Enric Balletbo i Serra 
Cc: Philipp Zabel 
Cc: Rob Herring 
Cc: Fabio Estevam 
Cc: David Airlie 
Cc: Thierry Reding 
Cc: Thierry Reding 
Cc: Archit Taneja 
Cc: Enric Balletbo 
Signed-off-by: Peter Senna Tschudin 

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index eb8688e..4a937f1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,17 @@ config DRM_DW_HDMI_I2S_AUDIO
  Support the I2S Audio interface which is part of the Synopsis
  Designware HDMI block.
 
+config DRM_MEGACHIPS_STDP_GE_B850V3_FW
+   tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_PANEL
+   ---help---
+  This is a driver for the display bridges of
+  GE B850v3 that convert dual channel LVDS
+  to DP++. This is used with the i.MX6 imx-ldb
+  driver. You are likely to say N here.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2e83a785..af0b7cc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c 
b/drivers/gpu/drm/b

Re: [PATCH] drm/atmel-hlcdc: Fix suspend/resume implementation

[Sylvain Rochet]

Hi,

On Wed, Mar 01, 2017 at 01:31:01PM +0100, Boris Brezillon wrote:
> The current suspend resume implementation is assuming register values are
> kept when entering suspend, which is no longer the case with the
> suspend-to-RAM on the sama5d2.
> 
> While at it, switch to the generic infrastructure to enter suspend mode
> (drm_atomic_helper_suspend/resume()).
> 
> Signed-off-by: Boris Brezillon 
> ---

No regression on sama5d3, atmel_hlcdc_crtc_disable/enable are still 
called at suspend/resume and pinctrl_pm_select_sleep_state which is just 
for my unusual screen (no display pin, so I need to clamp all pads) is 
still called, thus it works for me.

Tested-by: Sylvain Rochet 

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

Re: [PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

[Jose Abreu]

Hi Laurent,


On 01-03-2017 11:09, Laurent Pinchart wrote:
> Hi Jose,
>
> On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
>> On 05-01-2017 12:29, Laurent Pinchart wrote:
>>> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
 On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
>> Instead of spreading version-dependent PHY power handling code around,
>> group it in two functions to power the PHY on and off and use them
>> through the driver.
>>
>> Powering off the PHY at the beginning of the setup phase is currently
>> split in two locations for first and second generation PHYs, group all
>> the operations in the dw_hdmi_phy_init() function.
> This changes the behaviour of the driver.
>
>> +static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>> +{
>> +if (hdmi->phy->gen == 1) {
>> +dw_hdmi_phy_enable_tmds(hdmi, 0);
>> +dw_hdmi_phy_enable_powerdown(hdmi, true);
>> +} else {
>> +dw_hdmi_phy_gen2_txpwron(hdmi, 0);
>> +dw_hdmi_phy_gen2_pddq(hdmi, 1);
>> +}
>> +}
>> @@ -1290,9 +1302,7 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
>> *hdmi)
>>  if (!hdmi->phy_enabled)
>>  return;
>>
>> -dw_hdmi_phy_enable_tmds(hdmi, 0);
>> -dw_hdmi_phy_enable_powerdown(hdmi, true);
>> -
>> +dw_hdmi_phy_power_off(hdmi);
> This makes dw_hdmi_phy_disable() power down a gen2 phy.
>
> The iMX6 has a DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY phy, which you list as a
> gen2 phy.  I've been carrying this change for a while, which I've had
> to revert (and finally expunge), as it causes problems on iMX6:
>
> @@ -1112,6 +1112,14 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> *hdmi)
> if (!hdmi->phy_enabled)
> return;
>
> +   /* Actually set the phy into low power mode */
> +   dw_hdmi_phy_gen2_txpwron(hdmi, 0);
> +
> +   /* FIXME: We should wait for TX_READY to be deasserted */
> +
> +   dw_hdmi_phy_gen2_pddq(hdmi, 1);
> +
> +   /* This appears to have no effect on iMX6 */
> dw_hdmi_phy_enable_tmds(hdmi, 0);
> dw_hdmi_phy_enable_powerdown(hdmi, true);
>
> So, I think your change here will cause problems for iMX6.
>
> From what I remember, it seems that iMX6 has issues with RXSENSE/HPD
> bouncing when the PHY is powered down.  I can't promise when I'll be
> able to check for that again.
 Indeed TX_READY must be low before asserting pddq.
>>> The TX_READY signal is documented in the i.MX6 datasheet as being a PHY
>>> output signal, but there seems to be no HDMI TX register from which its
>>> state can be read. Do I need to poll the HDMI_PHY_PTRPT_ENBL register
>>> through I2C ? How long is the PHY expected to take to set TX_READY to 0 ?
>> TX_READY can be read from register 0x1A of phy, BIT(2) (through
>> I2C). Not sure if same offset for all phys though.
> I have been told that another option is to poll the TX_PHY_LOCK bit in the 
> phy_stat0 register. That would be a simpler solution that doesn't require I2C 
> access. Could you confirm (or disconfirm) this ?

Yes (In our implementation we have TX_PHY_LOCK wired up to
TX_READY that comes from phy. But if using a custom phy or an
unusual implementation then this may not hold).

Best regards,
Jose Miguel Abreu

 HPD and RXSENSE should work in power down mode by enabling enhpdrxsense
 bit in phy_conf0 BUT to enter power down you must disable TX_PWRON,
 enhpdrxsense and enable PDDQ and PHY_RESET. Only after doing this (and
 consequently entering power down mode) you can enable again enhpdrxsense.
>>> Thanks, I'll give it a try.

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

[Bug 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #130018|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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #130008|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 100024] [radeonsi] Failed to find memory space for buffer eviction when calling glTexSubImage2D with 16384 / 2

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #130009|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