Re: [Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Archit Taneja]

On Tuesday 27 February 2018 06:26 PM, Ville Syrjala wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
splitting the structure up into static and dynamic parts.

The static part will consist of subpixel_order, panel_orientation,
and bus_formats.

Actually I'm not sure where bus_formats & co. fit in all this. For some
drivers those seem to be static, even though they might fill them out
from .get_modes(). For other drivers this stuff even gets frobbed at
runtime, making it more some kind of a bastard encoder/connector state.
I'll just stick it into the static side so that the behaviour doesn't
change when I start clear out the entire dynamic state with memset().



[...]

  
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c

index b1ab4ab09532..abd0bce9c31e 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -174,7 +174,7 @@ static int sii902x_get_modes(struct drm_connector 
*connector)
kfree(edid);
}
  
-	ret = drm_display_info_set_bus_formats(>display_info,

+   ret = drm_display_info_set_bus_formats(>static_display_info,
   _format, 1);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 08ab7d6aea65..042ded9ca749 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1193,7 +1193,7 @@ static int tc_bridge_attach(struct drm_bridge *bridge)
if (tc->panel)
drm_panel_attach(tc->panel, >connector);
  
-	drm_display_info_set_bus_formats(>connector.display_info,

+   drm_display_info_set_bus_formats(>connector.static_display_info,
 _format, 1);
drm_mode_connector_attach_encoder(>connector, tc->bridge.encoder);
  


The sii902x driver sets the bus_formats in get_modes, but it's a fixed 
value and we may as well do it in bridge's attach op.


For the bridge drivers:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/15] drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Archit Taneja]

On 11/24/2017 12:34 AM, Ville Syrjala wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().


For this and the msm change in patch # 15/15:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: Archit Taneja <arch...@codeaurora.org>
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index ee41423baeb7..09f758e7bb1b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -286,7 +286,7 @@ static int mdp5_plane_atomic_check_with_state(struct 
drm_crtc_state *crtc_state,
uint32_t max_width, max_height;
bool out_of_bounds = false;
uint32_t caps = 0;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int min_scale, max_scale;
int ret;
  
@@ -320,13 +320,13 @@ static int mdp5_plane_atomic_check_with_state(struct drm_crtc_state *crtc_state,

return -ERANGE;
}
  
-	clip.x1 = 0;

-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
min_scale = FRAC_16_16(1, 8);
max_scale = FRAC_16_16(8, 1);
  
+	if (crtc_state->enable)

+   drm_mode_get_hv_timing(_state->mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  min_scale, max_scale,
  true, true);
@@ -471,7 +471,7 @@ static int mdp5_plane_atomic_async_check(struct drm_plane 
*plane,
  {
struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
struct drm_crtc_state *crtc_state;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int min_scale, max_scale;
int ret;
  
@@ -499,13 +499,13 @@ static int mdp5_plane_atomic_async_check(struct drm_plane *plane,

plane->state->fb != state->fb)
return -EINVAL;
  
-	clip.x1 = 0;

-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
min_scale = FRAC_16_16(1, 8);
max_scale = FRAC_16_16(8, 1);
  
+	if (crtc_state->enable)

+   drm_mode_get_hv_timing(_state->mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  min_scale, max_scale,
  true, true);



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

Re: [Intel-gfx] [PATCH 6/7] drm/drivers: drop redundant drm_edid_to_eld() calls

[Archit Taneja]

On 11/01/2017 07:51 PM, Jani Nikula wrote:

drm_add_edid_modes() now fills in the ELD automatically, so the calls to
drm_edid_to_eld() are redundant. Remove them.

All the other places are obvious, but nv50 has detached
drm_edid_to_eld() from the drm_add_edid_modes() call.


For the bridge drivers:

Acked-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit

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

Re: [Intel-gfx] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

[Archit Taneja]

On 07/25/2017 01:31 PM, Daniel Vetter wrote:

It's dead code, the core handles all this directly now. This also
allows us to unexport drm_atomic_helper_plane_set_property.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
Cc: Liviu Dudau <liviu.du...@arm.com>
Cc: Brian Starkey <brian.star...@arm.com>
Cc: Mali DP Maintainers <mal...@foss.arm.com>
Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Cc: David Airlie <airl...@linux.ie>
Cc: Inki Dae <inki@samsung.com>
Cc: Joonyoung Shim <jy0922.s...@samsung.com>
Cc: Seung-Woo Kim <sw0312@samsung.com>
Cc: Kyungmin Park <kyungmin.p...@samsung.com>
Cc: Kukjin Kim <kg...@kernel.org>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: Ben Skeggs <bske...@redhat.com>
Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org>
Cc: Vincent Abriou <vincent.abr...@st.com>
Cc: Yannick Fertre <yannick.fer...@st.com>
Cc: Philippe Cornu <philippe.co...@st.com>
Cc: Jyri Sarha <jsa...@ti.com>
Cc: "Ville Syrjälä" <ville.syrj...@linux.intel.com>
Cc: Rongrong Zou <zourongr...@gmail.com>
Cc: Shawn Guo <shawn@linaro.org>
Cc: Alexey Brodkin <abrod...@synopsys.com>
Cc: Eric Engestrom <e...@engestrom.ch>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: Archit Taneja <arch...@codeaurora.org>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Cc: Thomas Hellstrom <thellst...@vmware.com>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
---
  drivers/gpu/drm/arm/malidp_planes.c |  1 -
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  1 -
  drivers/gpu/drm/drm_atomic.c|  3 +-
  drivers/gpu/drm/drm_atomic_helper.c | 55 -
  drivers/gpu/drm/exynos/exynos_drm_plane.c   |  1 -
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 -
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 -
  drivers/gpu/drm/i915/intel_display.c|  2 -
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  2 -
  drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
  drivers/gpu/drm/omapdrm/omap_plane.c|  1 -
  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  1 -
  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  1 -
  drivers/gpu/drm/sti/sti_cursor.c|  1 -
  drivers/gpu/drm/sti/sti_gdp.c   |  1 -
  drivers/gpu/drm/sti/sti_hqvdp.c |  1 -
  drivers/gpu/drm/stm/ltdc.c  |  1 -
  drivers/gpu/drm/tilcdc/tilcdc_plane.c   |  1 -
  include/drm/drm_atomic.h|  3 --
  include/drm/drm_atomic_helper.h |  3 --
  20 files changed, 1 insertion(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 600fa7bd7f52..0f0f8234fe21 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -128,7 +128,6 @@ static void malidp_plane_atomic_print_state(struct 
drm_printer *p,
  static const struct drm_plane_funcs malidp_de_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
-   .set_property = drm_atomic_helper_plane_set_property,
.destroy = malidp_de_plane_destroy,
.reset = malidp_plane_reset,
.atomic_duplicate_state = malidp_duplicate_plane_state,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index b5bd9b005225..9cd9e23e75c6 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -1052,7 +1052,6 @@ static void atmel_hlcdc_plane_atomic_destroy_state(struct 
drm_plane *p,
  static struct drm_plane_funcs layer_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
-   .set_property = drm_atomic_helper_plane_set_property,
.destroy = atmel_hlcdc_plane_destroy,
.reset = atmel_hlcdc_plane_reset,
.atomic_duplicate_state = atmel_hlcdc_plane_atomic_duplicate_state,
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 0fd14aff7add..395438a7a576 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -713,7 +713,7 @@ EXPORT_SYMBOL(drm_atomic_get_plane_state);
   * RETURNS:
   * Zero on suc

Re: [Intel-gfx] [PATCH 4/8] drm: Nuke drm_atomic_helper_crtc_set_property

[Archit Taneja]

On 07/25/2017 01:31 PM, Daniel Vetter wrote:

It's dead code because this is now handled in the core.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
Cc: Boris Brezillon <boris.brezil...@free-electrons.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Cc: David Airlie <airl...@linux.ie>
Cc: Ben Skeggs <bske...@redhat.com>
Cc: Tomi Valkeinen <tomi.valkei...@ti.com>
Cc: Laurent Pinchart <laurent.pinchart+rene...@ideasonboard.com>
Cc: Alexey Brodkin <abrod...@synopsys.com>
Cc: Shawn Guo <shawn@linaro.org>
Cc: Eric Engestrom <e...@engestrom.ch>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: "Ville Syrjälä" <ville.syrj...@linux.intel.com>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: Philippe Cornu <philippe.co...@st.com>
Cc: Masahiro Yamada <yamada.masah...@socionext.com>
Cc: Sushmita Susheelendra <ssush...@codeaurora.org>
Cc: Archit Taneja <arch...@codeaurora.org>
Cc: intel-gfx@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Philipp Zabel <p.za...@pengutronix.de>
Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Thomas Hellstrom <thellst...@vmware.com>
---
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  1 -
  drivers/gpu/drm/drm_atomic_helper.c | 55 -
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  1 -
  drivers/gpu/drm/i915/intel_display.c|  1 -
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c|  1 -
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  2 -
  drivers/gpu/drm/nouveau/nv50_display.c  |  1 -
  drivers/gpu/drm/omapdrm/omap_crtc.c |  1 -
  include/drm/drm_atomic_helper.h |  3 --
  9 files changed, 66 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 4fbbeab5c5d4..d73281095fac 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -431,7 +431,6 @@ static const struct drm_crtc_funcs atmel_hlcdc_crtc_funcs = 
{
.atomic_destroy_state = atmel_hlcdc_crtc_destroy_state,
.enable_vblank = atmel_hlcdc_crtc_enable_vblank,
.disable_vblank = atmel_hlcdc_crtc_disable_vblank,
-   .set_property = drm_atomic_helper_crtc_set_property,
.gamma_set = drm_atomic_helper_legacy_gamma_set,
  };
  
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c

index 4a960c741e35..22245aa8b1aa 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2968,61 +2968,6 @@ int drm_atomic_helper_resume(struct drm_device *dev,
  EXPORT_SYMBOL(drm_atomic_helper_resume);
  
  /**

- * drm_atomic_helper_crtc_set_property - helper for crtc properties
- * @crtc: DRM crtc
- * @property: DRM property
- * @val: value of property
- *
- * Provides a default crtc set_property handler using the atomic driver
- * interface.
- *
- * RETURNS:
- * Zero on success, error code on failure
- */
-int
-drm_atomic_helper_crtc_set_property(struct drm_crtc *crtc,
-   struct drm_property *property,
-   uint64_t val)
-{
-   struct drm_atomic_state *state;
-   struct drm_crtc_state *crtc_state;
-   int ret = 0;
-
-   state = drm_atomic_state_alloc(crtc->dev);
-   if (!state)
-   return -ENOMEM;
-
-   /* ->set_property is always called with all locks held. */
-   state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
-retry:
-   crtc_state = drm_atomic_get_crtc_state(state, crtc);
-   if (IS_ERR(crtc_state)) {
-   ret = PTR_ERR(crtc_state);
-   goto fail;
-   }
-
-   ret = drm_atomic_crtc_set_property(crtc, crtc_state,
-   property, val);
-   if (ret)
-   goto fail;
-
-   ret = drm_atomic_commit(state);
-fail:
-   if (ret == -EDEADLK)
-   goto backoff;
-
-   drm_atomic_state_put(state);
-   return ret;
-
-backoff:
-   drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
-
-   goto retry;
-}
-EXPORT_SYMBOL(drm_atomic_helper_crtc_set_property);
-
-/**
   * drm_atomic_helper_plane_set_property - helper for plane properties
   * @plane: DRM plane
   * @property: DRM property
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 706efd0c4190..961551135a39 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -567,7 +567,6 @@ static const struct drm_crtc_funcs ade_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
   

Re: [Intel-gfx] [PATCH 3/8] drm: Handle properties in the core for atomic drivers

[Archit Taneja]

On 07/25/2017 01:31 PM, Daniel Vetter wrote:

The reason behind the original indirection through the helper
functions was to allow existing drivers to overwrite how they handle
properties. For example when a vendor-specific userspace had
expectations that didn't match atomic. That seemed likely, since
atomic is standardizing a _lot_ more of the behaviour of a kms driver.

But 20 drivers later there's no such need at all. Worse, this forces
all drivers to hook up the default behaviour, breaking userspace if
they forget to do that. And it forces us to export a bunch of core
function just for those helpers.

And finally, these helpers are the last places using
drm_atomic_legacy_backoff() and the implicit acquire_ctx.

This patch here just implements the new behaviour and updates the
docs. Follow-up patches will garbage-collect all the dead code.

v2: Fixup docs even better!

v3: Make it actually work ...


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
  drivers/gpu/drm/drm_atomic.c|  60 ++--
  drivers/gpu/drm/drm_connector.c |   6 +-
  drivers/gpu/drm/drm_crtc_helper.c   |   3 +-
  drivers/gpu/drm/drm_crtc_internal.h |   7 +++
  drivers/gpu/drm/drm_mode_object.c   | 110 +++-
  include/drm/drm_connector.h |  10 ++--
  include/drm/drm_crtc.h  |   6 +-
  include/drm/drm_plane.h |   6 +-
  8 files changed, 158 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 01192dd3ed79..0fd14aff7add 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1864,9 +1864,60 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
return e;
  }
  
-static int atomic_set_prop(struct drm_atomic_state *state,

-   struct drm_mode_object *obj, struct drm_property *prop,
-   uint64_t prop_value)
+int drm_atomic_connector_commit_dpms(struct drm_atomic_state *state,
+struct drm_connector *connector,
+int mode)
+{
+   struct drm_connector *tmp_connector;
+   struct drm_connector_state *new_conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   int i, ret, old_mode = connector->dpms;
+   bool active = false;
+
+   ret = drm_modeset_lock(>dev->mode_config.connection_mutex,
+  state->acquire_ctx);
+   if (ret)
+   return ret;
+
+   if (mode != DRM_MODE_DPMS_ON)
+   mode = DRM_MODE_DPMS_OFF;
+   connector->dpms = mode;
+
+   crtc = connector->state->crtc;
+   if (!crtc)
+   goto out;
+   ret = drm_atomic_add_affected_connectors(state, crtc);
+   if (ret)
+   goto out;
+
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   goto out;
+   }
+
+   for_each_new_connector_in_state(state, tmp_connector, new_conn_state, 
i) {
+   if (new_conn_state->crtc != crtc)
+   continue;
+   if (tmp_connector->dpms == DRM_MODE_DPMS_ON) {
+   active = true;
+   break;
+   }
+   }
+
+   crtc_state->active = active;
+   ret = drm_atomic_commit(state);
+out:
+   if (ret != 0)
+   connector->dpms = old_mode;
+   return ret;
+}
+
+int drm_atomic_set_property(struct drm_atomic_state *state,
+   struct drm_mode_object *obj,
+   struct drm_property *prop,
+   uint64_t prop_value)
  {
struct drm_mode_object *ref;
int ret;
@@ -2286,7 +2337,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
goto out;
}
  
-			ret = atomic_set_prop(state, obj, prop, prop_value);

+   ret = drm_atomic_set_property(state, obj, prop,
+ prop_value);
if (ret) {
drm_mode_object_put(obj);
goto out;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 349104eadefe..12371f184019 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -717,9 +717,9 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
   *drivers, it remaps to controlling the "ACTIVE" property on the CRTC the
   *connector is linked to. Drivers should never set this property directly,
   *it is handled by the DRM core by calling the _connector_funcs.dpms
- * callback. Atomic drivers should implement this hook using
- * drm_atomic_helper_connector_dpms(

Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

[Archit Taneja]

On 07/25/2017 01:31 PM, Daniel Vetter wrote:

It's dead code, the core handles all this directly now.

The only special case is nouveau and tda988x which used one function
for both legacy modeset code and -nv50 atomic world instead of 2
vtables. But amounts to exactly the same.

v2: Rebase over the panel/brideg refactorings in stm/ltdc.


s/brideg/bridge





---
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  1 -
  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  1 -
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  1 -
  drivers/gpu/drm/bridge/dumb-vga-dac.c  |  1 -
  .../drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  1 -
  drivers/gpu/drm/bridge/nxp-ptn3460.c   |  1 -
  drivers/gpu/drm/bridge/panel.c |  1 -
  drivers/gpu/drm/bridge/parade-ps8622.c |  1 -
  drivers/gpu/drm/bridge/sii902x.c   |  1 -
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  1 -
  drivers/gpu/drm/bridge/tc358767.c  |  1 -
  drivers/gpu/drm/bridge/ti-tfp410.c |  1 -


For bridge changes:

Acked-by: Archit Taneja <arch...@codeaurora.org>

Archit

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

Re: [Intel-gfx] [PATCH 14/16] drm/msm: Convert to use new iterator macros, v2.

[Archit Taneja]

On 07/12/2017 04:15 PM, Maarten Lankhorst wrote:

Op 12-07-17 om 11:48 schreef Daniel Vetter:

On Wed, Jul 12, 2017 at 10:13:42AM +0200, Maarten Lankhorst wrote:

for_each_obj_in_state is about to be removed, so convert
to the new iterator macros.

Just like in omap, use crtc_state->active instead of
crtc_state->enable when waiting for completion.


Tested-by: Archit Taneja <arch...@codeaurora.org>



Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: Archit Taneja <arch...@codeaurora.org>
Cc: Vincent Abriou <vincent.abr...@st.com>
Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
Cc: Russell King <rmk+ker...@armlinux.org.uk>
Cc: Rob Herring <r...@kernel.org>
Cc: Markus Elfring <elfr...@users.sourceforge.net>
Cc: Sushmita Susheelendra <ssush...@codeaurora.org>
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c |  4 ++--
  drivers/gpu/drm/msm/msm_atomic.c| 16 
  2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index bcd1f5cac72c..f7f087419ed8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -114,7 +114,7 @@ static void mdp4_prepare_commit(struct msm_kms *kms, struct 
drm_atomic_state *st
mdp4_enable(mdp4_kms);
  
  	/* see 119ecb7fd */

-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
drm_crtc_vblank_get(crtc);
  }
  
@@ -126,7 +126,7 @@ static void mdp4_complete_commit(struct msm_kms *kms, struct drm_atomic_state *s

struct drm_crtc_state *crtc_state;
  
  	/* see 119ecb7fd */

-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
drm_crtc_vblank_put(crtc);
  
  	mdp4_disable(mdp4_kms);

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 9633a68b14d7..9d3cc1f5e31a 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -84,13 +84,13 @@ static void msm_atomic_wait_for_commit_done(struct 
drm_device *dev,
struct drm_atomic_state *old_state)
  {
struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_state *new_crtc_state;
struct msm_drm_private *priv = old_state->dev->dev_private;
struct msm_kms *kms = priv->kms;
int i;
  
-	for_each_crtc_in_state(old_state, crtc, crtc_state, i) {

-   if (!crtc->state->enable)
+   for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
+   if (!new_crtc_state->active)
continue;
  
  		kms->funcs->wait_for_crtc_commit_done(kms, crtc);

@@ -195,7 +195,7 @@ int msm_atomic_commit(struct drm_device *dev,
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
int i, ret;
  
  	ret = drm_atomic_helper_prepare_planes(dev, state);

@@ -211,15 +211,15 @@ int msm_atomic_commit(struct drm_device *dev,
/*
 * Figure out what crtcs we have:
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
c->crtc_mask |= drm_crtc_mask(crtc);
  
  	/*

 * Figure out what fence to wait for:
 */
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   if ((plane->state->fb != plane_state->fb) && plane_state->fb) {
-   struct drm_gem_object *obj = 
msm_framebuffer_bo(plane_state->fb, 0);
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
+   if ((new_plane_state->fb != old_plane_state->fb) && 
new_plane_state->fb) {
+   struct drm_gem_object *obj = 
msm_framebuffer_bo(new_plane_state->fb, 0);
struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct dma_fence *fence = 
reservation_object_get_excl_rcu(msm_obj->resv);

Pretty sure this fails to compile, you've forgotten to do one more
s/plane_state/new_plane_state/.

With that fixed:

Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>


--->8---
for_each_obj_in_state is about to be removed, so convert
to the new iterator macros.

Just like in omap, use crtc_state->active instead of
crtc_state->enable when waiting for completion.

Changes since v1:
- Fix compilation.

Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>

Re: [Intel-gfx] [dim PATCH] dim: restore cd in update_rerere_cache()

[Archit Taneja]

On 07/18/2017 01:20 PM, Daniel Vetter wrote:

On Tue, Jul 18, 2017 at 10:15:25AM +0300, Jani Nikula wrote:

The refactoring dropped a cd to the drm-rerere dir, leading to "cp:
cannot stat 'rr-cache/*': No such file or directory" on dim ub.

Reported-by: Archit Taneja <arch...@codeaurora.org>
Fixes: 599eb3db59c9 ("dim: Move all rerere updating into helpers")
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Sean Paul <seanp...@chromium.org>
Signed-off-by: Jani Nikula <jani.nik...@intel.com>


Thx for spotting this.

Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>


Thanks, works for me now.

Tested-by: Archit Taneja <arch...@codeaurora.org>


---
  dim | 1 +
  1 file changed, 1 insertion(+)

diff --git a/dim b/dim
index 1fcd8d73fe1e..6ba2c085be16 100755
--- a/dim
+++ b/dim
@@ -495,6 +495,7 @@ function update_rerere_cache
  {
echo -n "Updating rerere cache... "
  
+	cd $DIM_PREFIX/drm-rerere/

git pull
mkdir $(rr_cache_dir) &> /dev/null || true
cp rr-cache/* $(rr_cache_dir) -r --preserve=timestamps
--
2.11.0





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

Re: [Intel-gfx] [PATCH RESEND 1/6] drm/atomic: initial support for asynchronous plane update

[Archit Taneja]

On 05/26/2017 01:21 AM, Gustavo Padovan wrote:

From: Gustavo Padovan <gustavo.pado...@collabora.com>

In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.

This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.

For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>


v4:
- fix state->crtc NULL check (Archit Taneja)

v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)

v2:
- allow updates even if there is a queued update for the same
plane.
- fixes on the documentation (Emil Velikov)
- unconditionally call ->atomic_async_update (Emil Velikov)
- check for ->atomic_async_update earlier (Daniel Vetter)
- make ->atomic_async_check() the last step (Daniel Vetter)
- add ASYNC_UPDATE flag (Eric Anholt)
- update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)

Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: Eric Anholt <e...@anholt.net>
Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/gpu/drm/drm_atomic.c | 65 
 drivers/gpu/drm/drm_atomic_helper.c  | 35 +
 include/drm/drm_atomic.h |  2 +
 include/drm/drm_atomic_helper.h  |  2 +
 include/drm/drm_modeset_helper_vtables.h | 48 +++
 5 files changed, 152 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index be62774..2a0c297 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -631,6 +631,68 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
return 0;
 }

+static bool drm_atomic_async_check(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_commit *commit;
+   struct drm_plane *__plane, *plane = NULL;
+   struct drm_plane_state *__plane_state, *plane_state = NULL;
+   const struct drm_plane_helper_funcs *funcs;
+   int i, j, n_planes = 0;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+   }
+
+   for_each_new_plane_in_state(state, __plane, __plane_state, i) {
+   n_planes++;
+   plane = __plane;
+   plane_state = __plane_state;
+   }
+
+   /* FIXME: we support only single plane updates for now */
+   if (!plane || n_planes != 1)
+   return false;
+
+   if (!plane_state->crtc)
+   return false;
+
+   funcs = plane->helper_private;
+   if (!funcs->atomic_async_update)
+   return false;
+
+   if (plane_state->fence)
+   return false;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (plane->crtc != crtc)
+   continue;
+
+   spin_lock(>commit_lock);
+   commit = list_first_entry_or_null(>commit_list,
+ struct drm_crtc_commit,
+ commit_entry);
+   if (!commit) {
+   spin_unlock(>commit_lock);
+   continue;
+   }
+   spin_unlock(>commit_lock);
+
+   if (!crtc->state->state)
+   continue;
+
+   for_each_plane_in_state(crtc->state->state, __plane,
+   __plane_state, j) {
+   if (__plane == plane)
+   return false;
+   }
+   }
+
+   return !funcs->atomic_async_check(plane, plane_state);
+}
+
 static void drm_atomic_crtc_print_state(struct drm_printer *p,
const struct drm_crtc_state *state)
 {
@@ -1591,6 +1653,9 @@ int drm_atomic_check_only(struct drm_atomic_state *state

Re: [Intel-gfx] [PATCH RESEND 4/6] drm/msm: update cursors asynchronously through atomic

[Archit Taneja]

On 05/26/2017 01:21 AM, Gustavo Padovan wrote:

From: Gustavo Padovan <gustavo.pado...@collabora.com>

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.


Tested-by: Archit Taneja <arch...@codeaurora.org>



v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)

v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Rob Clark <robdcl...@gmail.com>
Cc: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
 drivers/gpu/drm/msm/msm_atomic.c  |   6 ++
 2 files changed, 69 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index a38c5fe..07106c1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);

-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
-   struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   int crtc_x, int crtc_y,
-   unsigned int crtc_w, unsigned int crtc_h,
-   uint32_t src_x, uint32_t src_y,
-   uint32_t src_w, uint32_t src_h,
-   struct drm_modeset_acquire_ctx *ctx);
-
 static struct mdp5_kms *get_kms(struct drm_plane *plane)
 {
struct msm_drm_private *priv = plane->dev->dev_private;
@@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
 };

 static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = mdp5_update_cursor_plane_legacy,
+   .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane 
*plane,
}
 }

+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+   state->crtc);
+   if (WARN_ON(!crtc_state))
+   return -EINVAL;
+
+   if (!crtc_state->active)
+   return -EINVAL;
+
+   mdp5_state = to_mdp5_plane_state(state);
+
+   /* don't use fast path if we don't have a hwpipe allocated yet */
+   if (!mdp5_state->hwpipe)
+   return -EINVAL;
+
+   /* only allow changing of position(crtc x/y or src x/y) in fast path */
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb ||
+   plane->state->fb != state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+  struct drm_plane_state *new_state)
+{
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+
+   if (plane_enabled(new_state)) {
+   struct mdp5_ctl *ctl;
+   struct mdp5_pipeline *pipeline =
+   mdp5_crtc_get_pipeline(plane->crtc);
+   int ret;
+
+   ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+   _state->src, _state->dst);
+   WARN_ON(ret < 0);
+
+   ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+   mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+   }
+
+   *to_mdp5_plane_state(plane->state) =
+   *to_mdp5_plane_state(new_state);
+}
+
 static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_che

Re: [Intel-gfx] [PATCH RESEND 5/6] drm/msm: remove mdp5_cursor_plane_funcs

[Archit Taneja]

On 05/26/2017 01:21 AM, Gustavo Padovan wrote:

From: Gustavo Padovan <gustavo.pado...@collabora.com>

After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.



Tested-by: Archit Taneja <arch...@codeaurora.org>


Cc: Rob Clark <robdcl...@gmail.com>
Cc: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com>
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
 1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 07106c1..794ca07 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -247,19 +247,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
 };

-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = mdp5_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_set_property = mdp5_plane_atomic_set_property,
-   .atomic_get_property = mdp5_plane_atomic_get_property,
-   .reset = mdp5_plane_reset,
-   .atomic_duplicate_state = mdp5_plane_duplicate_state,
-   .atomic_destroy_state = mdp5_plane_destroy_state,
-   .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
 static int mdp5_plane_prepare_fb(struct drm_plane *plane,
 struct drm_plane_state *new_state)
 {
@@ -,16 +1098,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,

spin_lock_init(_plane->pipe_lock);

-   if (type == DRM_PLANE_TYPE_CURSOR)
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   _cursor_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
-   else
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   _plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
+   ret = drm_universal_plane_init(dev, plane, 0xff, _plane_funcs,
+  mdp5_plane->formats,
+  mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;




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

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

[Archit Taneja]

On 04/11/2017 01:03 PM, Sumit Semwal wrote:

On 11 April 2017 at 12:38, Daniel Stone <dan...@fooishbar.org> wrote:

Hi,

On 11 April 2017 at 07:48, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:

Note: As Daniel Stone mentioned in the announcement fd.o admins
started chatting with the communities their hosting, which includs the
X.org foundation board, to figure out how to fan out enforcement and
allow projects to run things on their own (with fd.o still as the
fallback).  So the details of enforcement (and appealing decisions)
might still change, but since this involves the board and lots more
people it'll take a while to get there. For now this is good enough I
think.


All true.

Reviewed-by: Daniel Stone <dani...@collabora.com>


Thanks for this, Daniel!

Reviewed-by: Sumit Semwal <sumit.sem...@linaro.org>


Acked-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Best,
Sumit.


Cheers,
Daniel

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



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

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Archit Taneja]

On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote:

On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:


On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:

On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:

Hi,

On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v2: Added docs and new iterator to filter private objects (Daniel)

Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
---
 drivers/gpu/drm/drm_atomic.c| 68 +++
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 91 +
 3 files changed, 164 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..1a9ffe8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);

@@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *private_obj = state->private_objs[i].obj;
+   void *obj_state = state->private_objs[i].obj_state;
+
+   if (!private_obj)
+   continue;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);

@@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }

 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;


Comparing this func to drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
doesn't seem to call drm_modeset_lock if the obj_state doesn't already exist. I
don't understand the locking stuff toowell, I just noticed this difference when
comparing this approach with what is done in the msm kms driver (where we
have subclassed drm_atomic_state to msm_kms_state).

Thanks,
Archit




The caller is expected to take care of any required locking. The
driver-private objects are opaque from core's pov, so the core is not
aware of necessary locks for that object type.


I had a look at the rest of the series, and I couldn't easily understand
whether the caller code protects the MST related driver private state. Is
it expected to be protect via the drm_mode_config.connection_mutex lock?

Thanks,
Archit



That's right, the connection_mutex takes care of the locking for the MST
private state. I can add that as a comment to the caller's (MST helper)
kernel doc with a

WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));


That would be nice to have.

In the comment: "It does not grab any locks as the caller is expected to
care of any required locking.", you could maybe be a bit more specific
and rephrase it

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Archit Taneja]

On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:

On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:

Hi,

On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v2: Added docs and new iterator to filter private objects (Daniel)

Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
---
 drivers/gpu/drm/drm_atomic.c| 68 +++
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 91 +
 3 files changed, 164 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..1a9ffe8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);

@@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *private_obj = state->private_objs[i].obj;
+   void *obj_state = state->private_objs[i].obj_state;
+
+   if (!private_obj)
+   continue;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);

@@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }

 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;


Comparing this func to drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
doesn't seem to call drm_modeset_lock if the obj_state doesn't already exist. I
don't understand the locking stuff toowell, I just noticed this difference when
comparing this approach with what is done in the msm kms driver (where we
have subclassed drm_atomic_state to msm_kms_state).

Thanks,
Archit




The caller is expected to take care of any required locking. The
driver-private objects are opaque from core's pov, so the core is not
aware of necessary locks for that object type.


I had a look at the rest of the series, and I couldn't easily understand
whether the caller code protects the MST related driver private state. Is
it expected to be protect via the drm_mode_config.connection_mutex lock?

Thanks,
Archit

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

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Archit Taneja]

Hi,

On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v2: Added docs and new iterator to filter private objects (Daniel)

Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c| 68 +++
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 91 +
 3 files changed, 164 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..1a9ffe8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);

@@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *private_obj = state->private_objs[i].obj;
+   void *obj_state = state->private_objs[i].obj_state;
+
+   if (!private_obj)
+   continue;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);

@@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }

 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;


Comparing this func to drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
doesn't seem to call drm_modeset_lock if the obj_state doesn't already exist. I
don't understand the locking stuff toowell, I just noticed this difference when
comparing this approach with what is done in the msm kms driver (where we
have subclassed drm_atomic_state to msm_kms_state).

Thanks,
Archit


+
+   num_objs = state->num_private_objs + 1;
+   size = sizeof(*state->private_objs) * num_objs;
+   arr = krealloc(state->private_objs, size, GFP_KERNEL);
+   if (!arr)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs = arr;
+   index = state->num_private_objs;
+   memset(>private_objs[index], 0, sizeof(*state->private_objs));
+
+   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
obj);
+   if (!state->private_objs[index].obj_state)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs[index].obj = obj;
+   state->private_objs[index].funcs = funcs;
+   state->num_private_objs = num_objs;
+
+   DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
+state->private_objs[index].obj_state, state);
+
+   return state->private_objs[index].obj_state;
+}
+EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
+
+/**
  * drm_atomic_get_connector_state - get connector state
  * @state: global atomic state object
  * @connector: connector to get state object for
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 

Re: [Intel-gfx] [PATCH 02/15] drm/bridge: Use recommened kerneldoc for struct member refs

[Archit Taneja]

On 01/25/2017 11:56 AM, Daniel Vetter wrote:

I just learned that _name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...


This seems like a leftover from the older version of the patch, which
we decided to not take. I guess we could drop it.

Archit



Cc: Archit Taneja <arch...@codeaurora.org>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
 include/drm/drm_bridge.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index fdd82fcbf168..1595a57dfbf2 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -87,9 +87,9 @@ struct drm_bridge_funcs {
 * True if an acceptable configuration is possible, false if the modeset
 * operation should be rejected.
 */
-   bool (*mode_fixup)(struct drm_bridge *bridge,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode);
+   bool (*mode_fixup)(struct drm_bridge *bridge, const struct
+  drm_display_mode *mode, struct drm_display_mode
+  *adjusted_mode);
/**
 * @disable:
 *



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

Re: [Intel-gfx] [PATCH 13/17] drm/bridge: Use recommened kerneldoc for struct member refs

[Archit Taneja]

On 12/30/2016 2:18 AM, Daniel Vetter wrote:

I just learned that _name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...

Cc: Archit Taneja <arch...@codeaurora.org>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
 drivers/gpu/drm/drm_bridge.c | 27 +++--
 include/drm/drm_bridge.h | 48 +---
 2 files changed, 39 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index ae5e57ad718c..86a7637ba344 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -55,7 +55,7 @@
  * just provide additional hooks to get the desired output at the end of the
  * encoder chain.
  *
- * Bridges can also be chained up using the next pointer in  drm_bridge.
+ * Bridges can also be chained up using the _bridge.next pointer.
  *
  * Both legacy CRTC helpers and the new atomic modeset helpers support bridges.
  */
@@ -179,7 +179,7 @@ void drm_bridge_detach(struct drm_bridge *bridge)
  * @mode: desired mode to be set for the bridge
  * @adjusted_mode: updated mode that works for this bridge
  *
- * Calls ->mode_fixup() _bridge_funcs op for all the bridges in the
+ * Calls _bridge_funcs.mode_fixup for all the bridges in the
  * encoder chain, starting from the first bridge to the last.
  *
  * Note: the bridge passed should be the one closest to the encoder
@@ -206,11 +206,10 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_fixup);

 /**
- * drm_bridge_disable - calls ->disable() _bridge_funcs op for all
- * bridges in the encoder chain.
+ * drm_bridge_disable - disables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
- * Calls ->disable() _bridge_funcs op for all the bridges in the encoder
+ * Calls _bridge_funcs.disable op for all the bridges in the encoder
  * chain, starting from the last bridge to the first. These are called before
  * calling the encoder's prepare op.
  *
@@ -229,11 +228,10 @@ void drm_bridge_disable(struct drm_bridge *bridge)
 EXPORT_SYMBOL(drm_bridge_disable);

 /**
- * drm_bridge_post_disable - calls ->post_disable() _bridge_funcs op for
- *  all bridges in the encoder chain.
+ * drm_bridge_post_disable - cleans up after disabling all bridges in the 
encoder chain
  * @bridge: bridge control structure
  *
- * Calls ->post_disable() _bridge_funcs op for all the bridges in the
+ * Calls _bridge_funcs.post_disable op for all the bridges in the
  * encoder chain, starting from the first bridge to the last. These are called
  * after completing the encoder's prepare op.
  *
@@ -258,7 +256,7 @@ EXPORT_SYMBOL(drm_bridge_post_disable);
  * @mode: desired mode to be set for the bridge
  * @adjusted_mode: updated mode that works for this bridge
  *
- * Calls ->mode_set() _bridge_funcs op for all the bridges in the
+ * Calls _bridge_funcs.mode_set op for all the bridges in the
  * encoder chain, starting from the first bridge to the last.
  *
  * Note: the bridge passed should be the one closest to the encoder
@@ -278,11 +276,11 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_set);

 /**
- * drm_bridge_pre_enable - calls ->pre_enable() _bridge_funcs op for all
- *bridges in the encoder chain.
+ * drm_bridge_pre_enable - prepares for enabling all
+ *bridges in the encoder chain
  * @bridge: bridge control structure
  *
- * Calls ->pre_enable() _bridge_funcs op for all the bridges in the encoder
+ * Calls _bridge_funcs.pre_enable op for all the bridges in the encoder
  * chain, starting from the last bridge to the first. These are called
  * before calling the encoder's commit op.
  *
@@ -301,11 +299,10 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge)
 EXPORT_SYMBOL(drm_bridge_pre_enable);

 /**
- * drm_bridge_enable - calls ->enable() _bridge_funcs op for all bridges
- *in the encoder chain.
+ * drm_bridge_enable - enables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
- * Calls ->enable() _bridge_funcs op for all the bridges in the encoder
+ * Calls _bridge_funcs.enable op for all the bridges in the encoder
  * chain, starting from the first bridge to the last. These are called
  * after completing the encoder's commit op.
  *
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index d3ca16f4da8f..1595a57dfbf2 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -87,18 +87,19 @@ struct drm_bridge_funcs {

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.

[Archit Taneja]

On 12/13/2016 07:22 PM, Maarten Lankhorst wrote:

Op 13-12-16 om 14:01 schreef Archit Taneja:

Hi,

On 12/12/2016 4:04 PM, Maarten Lankhorst wrote:

Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall back so watermarks can be updated.

Only moving and changing fb is allowed.


I was implementing something similar for msm kms. I have a comment/query
below.



Changes since v1:
- Set page flip to always_unused for trybot.
- Copy fence correctly, ignore plane_state->state, should be NULL.
- Check crtc_state for !active and modeset, go to slowpath if the case.
Changes since v2:
- Make error handling work correctly. (Matthew Auld)

Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  47 +++
 drivers/gpu/drm/i915/intel_display.c  | 132 +-
 drivers/gpu/drm/i915/intel_drv.h  |   2 +
 3 files changed, 163 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dbe9fb41ae53..60d75ce8a989 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -103,36 +103,24 @@ intel_plane_destroy_state(struct drm_plane *plane,
 drm_atomic_helper_plane_destroy_state(plane, state);
 }

-static int intel_plane_atomic_check(struct drm_plane *plane,
-struct drm_plane_state *state)
+int intel_plane_atomic_check_with_state(struct intel_crtc_state *crtc_state,
+struct intel_plane_state *intel_state)
 {
+struct drm_plane *plane = intel_state->base.plane;
 struct drm_i915_private *dev_priv = to_i915(plane->dev);
-struct drm_crtc *crtc = state->crtc;
-struct intel_crtc *intel_crtc;
-struct intel_crtc_state *crtc_state;
+struct drm_plane_state *state = _state->base;
 struct intel_plane *intel_plane = to_intel_plane(plane);
-struct intel_plane_state *intel_state = to_intel_plane_state(state);
-struct drm_crtc_state *drm_crtc_state;
 int ret;

-crtc = crtc ? crtc : plane->state->crtc;
-intel_crtc = to_intel_crtc(crtc);
-
 /*
  * Both crtc and plane->crtc could be NULL if we're updating a
  * property while the plane is disabled.  We don't actually have
  * anything driver-specific we need to test in that case, so
  * just return success.
  */
-if (!crtc)
+if (!intel_state->base.crtc && !plane->state->crtc)
 return 0;

-drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
-if (WARN_ON(!drm_crtc_state))
-return -EINVAL;
-
-crtc_state = to_intel_crtc_state(drm_crtc_state);
-
 /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
 intel_state->clip.x1 = 0;
 intel_state->clip.y1 = 0;
@@ -184,6 +172,31 @@ static int intel_plane_atomic_check(struct drm_plane 
*plane,
 return intel_plane_atomic_calc_changes(_state->base, state);
 }

+static int intel_plane_atomic_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+struct drm_crtc *crtc = state->crtc;
+struct drm_crtc_state *drm_crtc_state;
+
+crtc = crtc ? crtc : plane->state->crtc;
+
+/*
+ * Both crtc and plane->crtc could be NULL if we're updating a
+ * property while the plane is disabled.  We don't actually have
+ * anything driver-specific we need to test in that case, so
+ * just return success.
+ */
+if (!crtc)
+return 0;
+
+drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+if (WARN_ON(!drm_crtc_state))
+return -EINVAL;
+
+return 
intel_plane_atomic_check_with_state(to_intel_crtc_state(drm_crtc_state),
+   to_intel_plane_state(state));
+}
+
 static void intel_plane_atomic_update(struct drm_plane *plane,
   struct drm_plane_state *old_state)
 {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9eaf1e5bdae9..5568ecac2edc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15028,6 +15028,136 @@ const struct drm_plane_funcs intel_plane_funcs = {
 .atomic_destroy_state = intel_plane_destroy_state,
 };

+static int
+intel_legacy_cursor_update(struct drm_plane *plane,
+   struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   int crtc_x, int crtc_y,
+   unsigned int crtc_w, unsigned int crtc_h,
+   uint32_t src_x, uint32_t src_y,
+   uint32_t src_w, uint32_t src_h)
+{
+struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+int ret;
+struct drm_plane_s

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.

[Archit Taneja]

Hi,

On 12/12/2016 4:04 PM, Maarten Lankhorst wrote:

Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall back so watermarks can be updated.

Only moving and changing fb is allowed.


I was implementing something similar for msm kms. I have a comment/query
below.



Changes since v1:
- Set page flip to always_unused for trybot.
- Copy fence correctly, ignore plane_state->state, should be NULL.
- Check crtc_state for !active and modeset, go to slowpath if the case.
Changes since v2:
- Make error handling work correctly. (Matthew Auld)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  47 +++
 drivers/gpu/drm/i915/intel_display.c  | 132 +-
 drivers/gpu/drm/i915/intel_drv.h  |   2 +
 3 files changed, 163 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dbe9fb41ae53..60d75ce8a989 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -103,36 +103,24 @@ intel_plane_destroy_state(struct drm_plane *plane,
drm_atomic_helper_plane_destroy_state(plane, state);
 }

-static int intel_plane_atomic_check(struct drm_plane *plane,
-   struct drm_plane_state *state)
+int intel_plane_atomic_check_with_state(struct intel_crtc_state *crtc_state,
+   struct intel_plane_state *intel_state)
 {
+   struct drm_plane *plane = intel_state->base.plane;
struct drm_i915_private *dev_priv = to_i915(plane->dev);
-   struct drm_crtc *crtc = state->crtc;
-   struct intel_crtc *intel_crtc;
-   struct intel_crtc_state *crtc_state;
+   struct drm_plane_state *state = _state->base;
struct intel_plane *intel_plane = to_intel_plane(plane);
-   struct intel_plane_state *intel_state = to_intel_plane_state(state);
-   struct drm_crtc_state *drm_crtc_state;
int ret;

-   crtc = crtc ? crtc : plane->state->crtc;
-   intel_crtc = to_intel_crtc(crtc);
-
/*
 * Both crtc and plane->crtc could be NULL if we're updating a
 * property while the plane is disabled.  We don't actually have
 * anything driver-specific we need to test in that case, so
 * just return success.
 */
-   if (!crtc)
+   if (!intel_state->base.crtc && !plane->state->crtc)
return 0;

-   drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
-   if (WARN_ON(!drm_crtc_state))
-   return -EINVAL;
-
-   crtc_state = to_intel_crtc_state(drm_crtc_state);
-
/* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
intel_state->clip.x1 = 0;
intel_state->clip.y1 = 0;
@@ -184,6 +172,31 @@ static int intel_plane_atomic_check(struct drm_plane 
*plane,
return intel_plane_atomic_calc_changes(_state->base, state);
 }

+static int intel_plane_atomic_check(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   struct drm_crtc *crtc = state->crtc;
+   struct drm_crtc_state *drm_crtc_state;
+
+   crtc = crtc ? crtc : plane->state->crtc;
+
+   /*
+* Both crtc and plane->crtc could be NULL if we're updating a
+* property while the plane is disabled.  We don't actually have
+* anything driver-specific we need to test in that case, so
+* just return success.
+*/
+   if (!crtc)
+   return 0;
+
+   drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+   if (WARN_ON(!drm_crtc_state))
+   return -EINVAL;
+
+   return 
intel_plane_atomic_check_with_state(to_intel_crtc_state(drm_crtc_state),
+  to_intel_plane_state(state));
+}
+
 static void intel_plane_atomic_update(struct drm_plane *plane,
  struct drm_plane_state *old_state)
 {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9eaf1e5bdae9..5568ecac2edc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15028,6 +15028,136 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
 };

+static int
+intel_legacy_cursor_update(struct drm_plane *plane,
+  struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  int crtc_x, int crtc_y,
+  unsigned int crtc_w, unsigned int crtc_h,
+  uint32_t src_x, uint32_t src_y,
+  

Re: [Intel-gfx] [dim PATCH] dim: fix update-branches to fetch all available nightly repos

[Archit Taneja]

On 11/28/2016 05:03 PM, Jani Nikula wrote:

Update all nightly repos that have a corresponding local remote.

Cc: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Jani Nikula <jani.nik...@intel.com>


Tested-by: Archit Taneja <arch...@codeaurora.org>


---
 dim | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index a709342572ab..3dd2d1dec796 100755
--- a/dim
+++ b/dim
@@ -1255,8 +1255,15 @@ function dim_update_branches
local repo remote

cd $DIM_PREFIX/$DIM_DRM_INTEL
-   for remote in $DIM_DRM_INTEL_REMOTE `url_to_remote $drm_upstream_git` 
origin; do
+   for repo in "${!drm_tip_repos[@]}"; do
+   url=${drm_tip_repos[$repo]}
+   if ! remote=$(url_to_remote $url 2>/dev/null); then
+   continue
+   fi
+   echo -n "Fetching $repo (local remote $remote)... "
+   # git fetch returns 128 if there's nothing to be fetched
git fetch -q $remote || true
+   echo "Done."
done

assert_repo_clean



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

Re: [Intel-gfx] [PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property

[Archit Taneja]

On 10/24/2016 03:45 PM, Ville Syrjälä wrote:

On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:

Hi Ville,

On 10/22/2016 12:52 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.



I was trying to test this on msm/drm using modetest. The 180 rotation
works fine, but drm rejects reflect-x and reflect-y rotation prop
values. Is this expected?

I needed to make this modification to get reflect-x/y working too:

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a747bb1..9fcc2c9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property ||
   property == plane->rotation_property) {
-   if (!is_power_of_2(val & DRM_ROTATE_MASK))
+   if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))


That makes no sense. You _must_ to pass one and only one rotation angle.
In *addition* you can pass any number of the reflection flags.


Okay. Does the rotation property also include reflection flags, though?

When I dump plane properties using modetest, I get:

31 rotation:
 flags: bitmask
 values: rotate-0=0x1 rotate-180=0x4 reflect-x=0x10 reflect-y=0x20
 value: 1

If I use modetest to set 0x10 or 0x20, it returns an error. I wanted to
know if this is expected behavior or not?

Thanks,
Archit




return -EINVAL;
state->rotation = val;
} else if (property == plane->zpos_property) {



Otherwise, the patches look fine to me.

Thanks,
Archit



v2: Drop the BIT()

Cc: Rob Clark <robdcl...@gmail.com>
Cc: Jilai Wang <jil...@codeaurora.org>
Cc: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Reviewed-by: Rob Clark <robdcl...@gmail.com>
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 951c002b05df..2653ad893ebc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -75,15 +75,11 @@ static void mdp5_plane_install_rotation_property(struct 
drm_device *dev,
!(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
return;

-   if (!dev->mode_config.rotation_property)
-   dev->mode_config.rotation_property =
-   drm_mode_create_rotation_property(dev,
-   DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
-
-   if (dev->mode_config.rotation_property)
-   drm_object_attach_property(>base,
-   dev->mode_config.rotation_property,
-   DRM_ROTATE_0);
+   drm_plane_create_rotation_property(plane,
+  DRM_ROTATE_0,
+  DRM_ROTATE_0 |
+  DRM_REFLECT_X |
+  DRM_REFLECT_Y);
 }

 /* helper to install properties which are common to planes and crtcs */



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project




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

Re: [Intel-gfx] [PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property

[Archit Taneja]

Hi Ville,

On 10/22/2016 12:52 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.



I was trying to test this on msm/drm using modetest. The 180 rotation
works fine, but drm rejects reflect-x and reflect-y rotation prop
values. Is this expected?

I needed to make this modification to get reflect-x/y working too:

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a747bb1..9fcc2c9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property ||
   property == plane->rotation_property) {
-   if (!is_power_of_2(val & DRM_ROTATE_MASK))
+   if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))
return -EINVAL;
state->rotation = val;
} else if (property == plane->zpos_property) {



Otherwise, the patches look fine to me.

Thanks,
Archit



v2: Drop the BIT()

Cc: Rob Clark <robdcl...@gmail.com>
Cc: Jilai Wang <jil...@codeaurora.org>
Cc: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Reviewed-by: Rob Clark <robdcl...@gmail.com>
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 951c002b05df..2653ad893ebc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -75,15 +75,11 @@ static void mdp5_plane_install_rotation_property(struct 
drm_device *dev,
!(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
return;

-   if (!dev->mode_config.rotation_property)
-   dev->mode_config.rotation_property =
-   drm_mode_create_rotation_property(dev,
-   DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
-
-   if (dev->mode_config.rotation_property)
-   drm_object_attach_property(>base,
-   dev->mode_config.rotation_property,
-   DRM_ROTATE_0);
+   drm_plane_create_rotation_property(plane,
+  DRM_ROTATE_0,
+  DRM_ROTATE_0 |
+  DRM_REFLECT_X |
+  DRM_REFLECT_Y);
 }

 /* helper to install properties which are common to planes and crtcs */



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

Re: [Intel-gfx] [PATCH] drm: Fix plane type uabi breakage

[Archit Taneja]

On 09/23/2016 12:05 PM, Daniel Vetter wrote:

Turns out assuming that only stuff in uabi is uabi is a bit naive, and
we have a bunch of properties for which the enum values are placed in
random headers. A proper fix would be to split out uapi include
headers, but meanwhile sprinkle at least some warning over them.

Fixes: 532b36712ddf ("drm/doc: Polish for drm_plane.[hc]")
Cc: Archit Taneja <arch...@codeaurora.org>
Cc: Sean Paul <seanp...@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>


Reviewed-by: Archit Taneja <arch...@codeaurora.org>


---
 include/drm/drm_blend.h |  3 +++
 include/drm/drm_plane.h | 19 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 868f0364e939..36baa175de99 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -33,6 +33,9 @@ struct drm_atomic_state;
  * Rotation property bits. DRM_ROTATE_ rotates the image by the
  * specified amount in degrees in counter clockwise direction. DRM_REFLECT_X 
and
  * DRM_REFLECT_Y reflects the image along the specified axis prior to rotation
+ *
+ * WARNING: These defines are UABI since they're exposed in the rotation
+ * property.
  */
 #define DRM_ROTATE_0   BIT(0)
 #define DRM_ROTATE_90  BIT(1)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 256219bfd07b..43cf193e54d6 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -333,9 +333,20 @@ struct drm_plane_funcs {
  * DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they
  * wish to receive a universal plane list containing all plane types. See also
  * drm_for_each_legacy_plane().
+ *
+ * WARNING: The values of this enum is UABI since they're exposed in the "type"
+ * property.
  */
 enum drm_plane_type {
/**
+* @DRM_PLANE_TYPE_OVERLAY:
+*
+* Overlay planes represent all non-primary, non-cursor planes. Some
+* drivers refer to these types of planes as "sprites" internally.
+*/
+   DRM_PLANE_TYPE_OVERLAY,
+
+   /**
 * @DRM_PLANE_TYPE_PRIMARY:
 *
 * Primary planes represent a "main" plane for a CRTC.  Primary planes
@@ -353,14 +364,6 @@ enum drm_plane_type {
 * DRM_IOCTL_MODE_CURSOR2 IOCTLs.
 */
DRM_PLANE_TYPE_CURSOR,
-
-   /**
-* @DRM_PLANE_TYPE_OVERLAY:
-*
-* Overlay planes represent all non-primary, non-cursor planes. Some
-* drivers refer to these types of planes as "sprites" internally.
-*/
-   DRM_PLANE_TYPE_OVERLAY,
 };





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

Re: [Intel-gfx] [PATCH 05/10] drm/doc: Polish for drm_plane.[hc]

[Archit Taneja]

On 09/19/2016 06:43 PM, Daniel Vetter wrote:

On Fri, Sep 02, 2016 at 03:00:38PM +0530, Archit Taneja wrote:



On 8/31/2016 9:39 PM, Daniel Vetter wrote:

Big thing is untangling and carefully documenting the different uapi
types of planes. I also sprinkled a few more cross references around
to make this easier to discover.

As usual, remove the kerneldoc for internal functions which are not
exported. Aside: We should probably go OCD on all the ioctl handlers
and consistenly give them an _ioctl postfix.

Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
  Documentation/gpu/drm-kms.rst |  47 +--
  drivers/gpu/drm/drm_crtc.c|   6 +-
  drivers/gpu/drm/drm_plane.c   | 132 --
  include/drm/drm_plane.h   |  57 +-
  4 files changed, 86 insertions(+), 156 deletions(-)





+/**
+ * enum drm_plane_type - uapi plane type enumeration
+ *
+ * For historical reasons not all planes are made the same. This enumeration is
+ * used to tell the different types of planes apart to implement the different
+ * uapi semantics for them. For userspace which is universal plane aware and
+ * which is using that atomic IOCTL there's no difference between these planes
+ * (beyong what the driver and hardware can support of course).
+ *
+ * For compatibility with legacy userspace, only overlay planes are made
+ * available to userspace by default. Userspace clients may set the
+ * DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they
+ * wish to receive a universal plane list containing all plane types. See also
+ * drm_for_each_legacy_plane().
+ */
  enum drm_plane_type {
-   DRM_PLANE_TYPE_OVERLAY,


Any reason why you moved this down? I guess there is no harm, but people
might be printing plane type while debugging, and they'd assume
DRM_PLANE_TYPE_OVERLAY=0


I think starting out with 0 for the primary plane makes a lot more sense,
and since it's an internal thing we can change it however we want. I also
think from a documentation pov it reads better if the 2 special planes
(primary and cursor) are first.

But I'm happy to shuffle it back if you feel strongly the other way round.


No, it's fine. The series looks good too.

Thanks,
Archit


-Daniel



Thanks,
Archit


+   /**
+* @DRM_PLANE_TYPE_PRIMARY:
+*
+* Primary planes represent a "main" plane for a CRTC.  Primary planes
+* are the planes operated upon by CRTC modesetting and flipping
+* operations described in the page_flip and set_config hooks in struct
+* _crtc_funcs.
+*/
DRM_PLANE_TYPE_PRIMARY,
+
+   /**
+* @DRM_PLANE_TYPE_CURSOR:
+*
+* Cursor planes represent a "cursor" plane for a CRTC.  Cursor planes
+* are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and
+* DRM_IOCTL_MODE_CURSOR2 IOCTLs.
+*/
DRM_PLANE_TYPE_CURSOR,
+
+   /**
+* @DRM_PLANE_TYPE_OVERLAY:
+*
+* Overlay planes represent all non-primary, non-cursor planes. Some
+* drivers refer to these types of planes as "sprites" internally.
+*/
+   DRM_PLANE_TYPE_OVERLAY,
  };


@@ -458,11 +496,26 @@ static inline struct drm_plane *drm_plane_find(struct 
drm_device *dev,
list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))

-/* Plane list iterator for legacy (overlay only) planes. */
+/**
+ * drm_for_each_legacy_plane - iterate over all planes for legacy userspace
+ * @plane: the loop cursor
+ * @dev: the DRM device
+ *
+ * Iterate over all legacy planes of @dev, excluding primary and cursor planes.
+ * This is useful for implementing userspace apis when userspace is not
+ * universal plane aware. See also enum _plane_type.
+ */
  #define drm_for_each_legacy_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) \
for_each_if (plane->type == DRM_PLANE_TYPE_OVERLAY)

+/**
+ * drm_for_each_plane - iterate over all planes
+ * @plane: the loop cursor
+ * @dev: the DRM device
+ *
+ * Iterate over all planes of @dev, include primary and cursor planes.
+ */
  #define drm_for_each_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project




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

Re: [Intel-gfx] [PATCH 05/10] drm/doc: Polish for drm_plane.[hc]

[Archit Taneja]

On 8/31/2016 9:39 PM, Daniel Vetter wrote:

Big thing is untangling and carefully documenting the different uapi
types of planes. I also sprinkled a few more cross references around
to make this easier to discover.

As usual, remove the kerneldoc for internal functions which are not
exported. Aside: We should probably go OCD on all the ioctl handlers
and consistenly give them an _ioctl postfix.

Signed-off-by: Daniel Vetter 
---
  Documentation/gpu/drm-kms.rst |  47 +--
  drivers/gpu/drm/drm_crtc.c|   6 +-
  drivers/gpu/drm/drm_plane.c   | 132 --
  include/drm/drm_plane.h   |  57 +-
  4 files changed, 86 insertions(+), 156 deletions(-)





+/**
+ * enum drm_plane_type - uapi plane type enumeration
+ *
+ * For historical reasons not all planes are made the same. This enumeration is
+ * used to tell the different types of planes apart to implement the different
+ * uapi semantics for them. For userspace which is universal plane aware and
+ * which is using that atomic IOCTL there's no difference between these planes
+ * (beyong what the driver and hardware can support of course).
+ *
+ * For compatibility with legacy userspace, only overlay planes are made
+ * available to userspace by default. Userspace clients may set the
+ * DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they
+ * wish to receive a universal plane list containing all plane types. See also
+ * drm_for_each_legacy_plane().
+ */
  enum drm_plane_type {
-   DRM_PLANE_TYPE_OVERLAY,


Any reason why you moved this down? I guess there is no harm, but people
might be printing plane type while debugging, and they'd assume
DRM_PLANE_TYPE_OVERLAY=0

Thanks,
Archit


+   /**
+* @DRM_PLANE_TYPE_PRIMARY:
+*
+* Primary planes represent a "main" plane for a CRTC.  Primary planes
+* are the planes operated upon by CRTC modesetting and flipping
+* operations described in the page_flip and set_config hooks in struct
+* _crtc_funcs.
+*/
DRM_PLANE_TYPE_PRIMARY,
+
+   /**
+* @DRM_PLANE_TYPE_CURSOR:
+*
+* Cursor planes represent a "cursor" plane for a CRTC.  Cursor planes
+* are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and
+* DRM_IOCTL_MODE_CURSOR2 IOCTLs.
+*/
DRM_PLANE_TYPE_CURSOR,
+
+   /**
+* @DRM_PLANE_TYPE_OVERLAY:
+*
+* Overlay planes represent all non-primary, non-cursor planes. Some
+* drivers refer to these types of planes as "sprites" internally.
+*/
+   DRM_PLANE_TYPE_OVERLAY,
  };


@@ -458,11 +496,26 @@ static inline struct drm_plane *drm_plane_find(struct 
drm_device *dev,
list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))

-/* Plane list iterator for legacy (overlay only) planes. */
+/**
+ * drm_for_each_legacy_plane - iterate over all planes for legacy userspace
+ * @plane: the loop cursor
+ * @dev: the DRM device
+ *
+ * Iterate over all legacy planes of @dev, excluding primary and cursor planes.
+ * This is useful for implementing userspace apis when userspace is not
+ * universal plane aware. See also enum _plane_type.
+ */
  #define drm_for_each_legacy_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) \
for_each_if (plane->type == DRM_PLANE_TYPE_OVERLAY)

+/**
+ * drm_for_each_plane - iterate over all planes
+ * @plane: the loop cursor
+ * @dev: the DRM device
+ *
+ * Iterate over all planes of @dev, include primary and cursor planes.
+ */
  #define drm_for_each_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)




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

Re: [Intel-gfx] [PATCH 02/10] drm: Extract drm_bridge.h

[Archit Taneja]

On 8/31/2016 9:39 PM, Daniel Vetter wrote:

We don't want to burry the bridge structures kerneldoc in drm_crtc.h.

Cc: Archit Taneja <archit.tan...@gmail.com>


Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
  Documentation/gpu/drm-kms-helpers.rst |   7 ++
  drivers/gpu/drm/drm_bridge.c  |   5 +-
  include/drm/drm_bridge.h  | 218 ++
  include/drm/drm_connector.h   |   4 +
  include/drm/drm_crtc.h| 187 +
  include/drm/drm_mode_object.h |   1 +
  include/drm/drm_modes.h   |   4 +
  7 files changed, 237 insertions(+), 189 deletions(-)
  create mode 100644 include/drm/drm_bridge.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 59fa3c11efab..48fc5a96bf95 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -126,6 +126,13 @@ Default bridge callback sequence
  .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
 :doc: bridge callbacks

+
+Bridge Helper Reference
+-
+
+.. kernel-doc:: include/drm/drm_bridge.h
+   :internal:
+
  .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
 :export:

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 484046664d6c..0ee052b7c21a 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -23,10 +23,9 @@

  #include 
  #include 
+#include 

-#include 
-
-#include "drm/drmP.h"
+#include 

  /**
   * DOC: overview
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
new file mode 100644
index ..530a1d6e8cde
--- /dev/null
+++ b/include/drm/drm_bridge.h
@@ -0,0 +1,218 @@
+/*
+ * Copyright (c) 2016 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#ifndef __DRM_BRIDGE_H__
+#define __DRM_BRIDGE_H__
+
+#include 
+#include 
+#include 
+#include 
+
+struct drm_bridge;
+
+/**
+ * struct drm_bridge_funcs - drm_bridge control functions
+ */
+struct drm_bridge_funcs {
+   /**
+* @attach:
+*
+* This callback is invoked whenever our bridge is being attached to a
+* _encoder.
+*
+* The attach callback is optional.
+*
+* RETURNS:
+*
+* Zero on success, error code on failure.
+*/
+   int (*attach)(struct drm_bridge *bridge);
+
+   /**
+* @detach:
+*
+* This callback is invoked whenever our bridge is being detached from a
+* _encoder.
+*
+* The detach callback is optional.
+*/
+   void (*detach)(struct drm_bridge *bridge);
+
+   /**
+* @mode_fixup:
+*
+* This callback is used to validate and adjust a mode. The paramater
+* mode is the display mode that should be fed to the next element in
+* the display chain, either the final _connector or the next
+* _bridge. The parameter adjusted_mode is the input mode the bridge
+* requires. It can be modified by this callback and does not need to
+* match mode.
+*
+* This is the only hook that allows a bridge to reject a modeset. If
+* this function passes all other callbacks must succeed for this
+* configuration.
+*
+* The mode_fixup callback is optional.
+*
+* NOTE:
+*
+* This function is called in the check phase of atomic modesets, which
+* can be aborted for any reason (including on userspace's request to
+* just check whether a configuration would be possible). Drivers MUST
+* NOT touch any persistent state (hardware or software) or data
+* structures except the passed in @state pa

Re: [Intel-gfx] [PATCH 3/9] drm: Extract drm_mode_object.[hc]

[Archit Taneja]

On 08/26/2016 01:10 AM, Daniel Vetter wrote:

On Thu, Aug 25, 2016 at 05:55:18PM +0530, Archit Taneja wrote:

On 08/18/2016 02:26 AM, Daniel Vetter wrote:

+void drm_mode_object_unregister(struct drm_device *dev,
+   struct drm_mode_object *object);


Alignment issue in the declaration here.


Again I don't like touching code when moving it. I guess I'll squash all
your suggestions into the polish patches.


Sure, that seems like a better idea.

Archit


-Daneil



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

Re: [Intel-gfx] [PATCH 5/9] drm/doc: Polish docs for drm_mode_object

[Archit Taneja]

On 08/18/2016 02:26 AM, Daniel Vetter wrote:

I figured an overview section here is overkill, and better
to just document the 2 structures themselves well enough.

Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
  drivers/gpu/drm/drm_mode_object.c |  9 +++
  include/drm/drm_mode_object.h | 50 ---
  2 files changed, 56 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index a92aeed51156..a4dd3fa258b4 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -222,6 +222,12 @@ EXPORT_SYMBOL(drm_object_attach_property);
   * changes the software state of the property, it does not call into the
   * driver's ->set_property callback.
   *
+ * Note that atomic drivers should not have any need to call this, the core 
will
+ * ensure consistency of values reported back to userspace through the
+ * appropriate ->atomic_get_property callback. Only legacy drivers should call
+ * this function to update the tracked value (after clamping and other
+ * restrictions have been applied).
+ *
   * Returns:
   * Zero on success, error code on failure.
   */
@@ -252,6 +258,9 @@ EXPORT_SYMBOL(drm_object_property_set_value);
   * value this might be out of sync with the hardware, depending upon the 
driver
   * and property.
   *
+ * Atomic drivers should never call this function directly, the core will read
+ * out property values through the various ->atomic_get_property callbacks.
+ *
   * Returns:
   * Zero on success, error code on failure.
   */
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index b8adb6425f2a..7967ffeda3c4 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -27,6 +27,28 @@
  struct drm_object_properties;
  struct drm_property;

+/**
+ * struct drm_mode_object - base structure for modeset objecst


s/objecst/object


+ * @id: userspace visible identifier
+ * @type: type of the object, one of DRM_MODE_OBJECT\_\*
+ * @properties: properties attached to this object, including values
+ * @refcount: reference count for objects which with dynamic lifetime
+ * @free_cb: free function callback, only set for objects with dynamic lifetime
+ *
+ * Base structure for modeset objects visible to userspace. Objects can be
+ * looked up using drm_mode_object_find(). Besides basic uapi interface
+ * properties like @id and @type it provides two servies:


s/servies/services


+ *
+ * - It tracks attached properties and their values. This is used by _crtc,
+ *   _plane and _connector. Properties are attached by calling
+ *   drm_object_attach_property() before the object is visible to userspace.
+ *
+ * - For objects with dynamic lifetimes (as indicated by a non-NULL @free_cb) 
it
+ *   provides reference counting through drm_mode_object_reference() and
+ *   drm_mode_object_unreference(). This is used by _framebuffer,
+ *   _connector and _property_blob. These objects provide specialized
+ *   reference counting wrappers.
+ */
  struct drm_mode_object {
uint32_t id;
uint32_t type;
@@ -36,16 +58,38 @@ struct drm_mode_object {
  };

  #define DRM_OBJECT_MAX_PROPERTY 24
+/**
+ * struct drm_object_properties - property tracking for _mode_object
+ */
  struct drm_object_properties {
+   /**
+* @count: number of valid properties, must be less than or equal to
+* DRM_OBJECT_MAX_PROPERTY.
+*/
+
int count;
-   /* NOTE: if we ever start dynamically destroying properties (ie.
+   /**
+* @properties: Array of pointers to _property.
+*
+* NOTE: if we ever start dynamically destroying properties (ie.
 * not at drm_mode_config_cleanup() time), then we'd have to do
 * a better job of detaching property from mode objects to avoid
 * dangling property pointers:
 */
struct drm_property *properties[DRM_OBJECT_MAX_PROPERTY];
-   /* do not read/write values directly, but use 
drm_object_property_get_value()
-* and drm_object_property_set_value():
+
+   /**
+* @values: Array to store the property values, matching @properties. Do
+* not read/write values directly, but use
+* drm_object_property_get_value() and drm_object_property_set_value().
+*
+* Note that atomic drivers do not store mutable properties in this
+* aray, but only the decoded values in the corresponding state


s/aray/array

Otherwise:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Archit


+* structure. The decoding is done using the ->atomic_get_property and
+* ->atomic_set_property hooks of the corresponding object. Hence atomic
+* drivers should not use drm_object_property_set_value() and
+* drm_object_property_get_value() on mutable objects, i.e. those
+* without the DRM_MODE_PROP_IMMUTABLE flag set.

Re: [Intel-gfx] [PATCH 7/9] drm: Extract drm_property.[hc]

[Archit Taneja]

On 08/18/2016 02:26 AM, Daniel Vetter wrote:

This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.

v2: resurrect misplaced hunk (Daniel Stone)

Cc: Daniel Stone <dan...@fooishbar.org>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>


checkpatch throws a few errors on usage of spaces instead of tabs,
probably stuff that existed before, but it would be nice to get
rid of them now. Otherwise:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

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

Re: [Intel-gfx] [PATCH 8/9] drm: Unify handling of blob and object properties

[Archit Taneja]

On 08/18/2016 02:26 AM, Daniel Vetter wrote:

They work exactly the same now, after the refcounting unification a bit
ago. The only reason they're distinct is backwards compat with existing
userspace.

Cc: Daniel Stone <dani...@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>


Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Archit


---
  drivers/gpu/drm/drm_property.c | 23 +--
  1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 162cc9032ae5..b5521f705b1c 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -911,20 +911,8 @@ bool drm_property_change_valid_get(struct drm_property 
*property,
for (i = 0; i < property->num_values; i++)
valid_mask |= (1ULL << property->values[i]);
return !(value & ~valid_mask);
-   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
-   struct drm_property_blob *blob;
-
-   if (value == 0)
-   return true;
-
-   blob = drm_property_lookup_blob(property->dev, value);
-   if (blob) {
-   *ref = >base;
-   return true;
-   } else {
-   return false;
-   }
-   } else if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
+   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB) ||
+  drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
/* a zero value for an object property translates to null: */
if (value == 0)
return true;
@@ -941,13 +929,12 @@ bool drm_property_change_valid_get(struct drm_property 
*property,
  }

  void drm_property_change_valid_put(struct drm_property *property,
-   struct drm_mode_object *ref)
+  struct drm_mode_object *ref)
  {
if (!ref)
return;

-   if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
+   if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT) ||
+   drm_property_type_is(property, DRM_MODE_PROP_BLOB))
drm_mode_object_unreference(ref);
-   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB))
-   drm_property_unreference_blob(obj_to_blob(ref));
  }



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

Re: [Intel-gfx] [PATCH 6/9] drm: move drm_mode_legacy_fb_format to drm_fourcc.c

[Archit Taneja]

On 08/18/2016 02:26 AM, Daniel Vetter wrote:

It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
  drivers/gpu/drm/drm_crtc.c   | 43 ---
  drivers/gpu/drm/drm_fourcc.c | 43 +++
  include/drm/drm_crtc.h   |  2 --
  include/drm/drm_fourcc.h |  1 +
  4 files changed, 44 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d7f68ec049d1..27b49ad0989b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1666,49 +1666,6 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
return drm_mode_cursor_common(dev, req, file_priv);
  }

-/**
- * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
- * @bpp: bits per pixels
- * @depth: bit depth per pixel
- *
- * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
- * Useful in fbdev emulation code, since that deals in those values.
- */
-uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
-{
-   uint32_t fmt;
-
-   switch (bpp) {
-   case 8:
-   fmt = DRM_FORMAT_C8;
-   break;
-   case 16:
-   if (depth == 15)
-   fmt = DRM_FORMAT_XRGB1555;
-   else
-   fmt = DRM_FORMAT_RGB565;
-   break;
-   case 24:
-   fmt = DRM_FORMAT_RGB888;
-   break;
-   case 32:
-   if (depth == 24)
-   fmt = DRM_FORMAT_XRGB;
-   else if (depth == 30)
-   fmt = DRM_FORMAT_XRGB2101010;
-   else
-   fmt = DRM_FORMAT_ARGB;
-   break;
-   default:
-   DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
-   fmt = DRM_FORMAT_XRGB;
-   break;
-   }
-
-   return fmt;
-}
-EXPORT_SYMBOL(drm_mode_legacy_fb_format);
-
  static bool drm_property_type_valid(struct drm_property *property)
  {
if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index c81546c15c93..29c56b4331e0 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -36,6 +36,49 @@ static char printable_char(int c)
  }

  /**
+ * drm_mode_legacy_fb_format - compute drm fourcc code from legacy description
+ * @bpp: bits per pixels
+ * @depth: bit depth per pixel
+ *
+ * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
+ * Useful in fbdev emulation code, since that deals in those values.
+ */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+   uint32_t fmt;
+
+   switch (bpp) {
+   case 8:
+   fmt = DRM_FORMAT_C8;
+   break;
+   case 16:
+   if (depth == 15)
+   fmt = DRM_FORMAT_XRGB1555;
+   else
+   fmt = DRM_FORMAT_RGB565;
+   break;
+   case 24:
+   fmt = DRM_FORMAT_RGB888;
+   break;
+   case 32:
+   if (depth == 24)
+   fmt = DRM_FORMAT_XRGB;
+   else if (depth == 30)
+   fmt = DRM_FORMAT_XRGB2101010;
+   else
+   fmt = DRM_FORMAT_ARGB;
+   break;
+   default:
+   DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
+   fmt = DRM_FORMAT_XRGB;
+   break;
+   }
+
+   return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
+/**
   * drm_get_format_name - return a string for drm fourcc format
   * @format: format to compute name of
   *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1abcc182e92b..f5e51e5e9724 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2135,8 +2135,6 @@ extern int drm_mode_crtc_set_gamma_size(struct drm_crtc 
*crtc,

  extern int drm_mode_set_config_internal(struct drm_mode_set *set);

-extern uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
-
  extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device 
*dev,
 char topology[8]);
  extern struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index b106337de1bf..30c30fa87ee8 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -25,6 +25,7 @@
  #include 
  #include 

+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
  void drm_fb_get_bpp_depth(uint32_t 

Re: [Intel-gfx] [PATCH 3/9] drm: Extract drm_mode_object.[hc]

[Archit Taneja]

odeset


s/functions/function


+ * object. It is a no-op on any other object. References should be dropped 
again
+ * by calling drm_mode_object_unreference().
+ */
+void drm_mode_object_reference(struct drm_mode_object *obj)
+{
+   if (obj->free_cb) {
+   DRM_DEBUG("OBJ ID: %d (%d)\n", obj->id, 
atomic_read(>refcount.refcount));
+   kref_get(>refcount);
+   }
+}
+EXPORT_SYMBOL(drm_mode_object_reference);
+
+/**
+ * drm_object_attach_property - attach a property to a modeset object
+ * @obj: drm modeset object
+ * @property: property to attach
+ * @init_val: initial value of the property
+ *
+ * This attaches the given property to the modeset object with the given 
initial
+ * value. Currently this function cannot fail since the properties are stored 
in
+ * a statically sized array.
+ */
+void drm_object_attach_property(struct drm_mode_object *obj,
+   struct drm_property *property,
+   uint64_t init_val)
+{
+   int count = obj->properties->count;
+
+   if (count == DRM_OBJECT_MAX_PROPERTY) {
+   WARN(1, "Failed to attach object property (type: 0x%x). Please "
+   "increase DRM_OBJECT_MAX_PROPERTY by 1 for each time "
+   "you see this message on the same object type.\n",
+   obj->type);
+   return;
+   }
+
+   obj->properties->properties[count] = property;
+   obj->properties->values[count] = init_val;
+   obj->properties->count++;
+   if (property->flags & DRM_MODE_PROP_ATOMIC)
+   obj->properties->atomic_count++;
+}
+EXPORT_SYMBOL(drm_object_attach_property);
+
+/**
+ * drm_object_property_set_value - set the value of a property
+ * @obj: drm mode object to set property value for
+ * @property: property to set
+ * @val: value the property should be set to
+ *
+ * This functions sets a given property on a given object. This function only


s/functions/function

Otherwise:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Archit


+ * changes the software state of the property, it does not call into the
+ * driver's ->set_property callback.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_object_property_set_value(struct drm_mode_object *obj,
+ struct drm_property *property, uint64_t val)
+{
+   int i;
+
+   for (i = 0; i < obj->properties->count; i++) {
+   if (obj->properties->properties[i] == property) {
+   obj->properties->values[i] = val;
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_object_property_set_value);
+
+/**
+ * drm_object_property_get_value - retrieve the value of a property
+ * @obj: drm mode object to get property value from
+ * @property: property to retrieve
+ * @val: storage for the property value
+ *
+ * This function retrieves the softare state of the given property for the 
given
+ * property. Since there is no driver callback to retrieve the current property
+ * value this might be out of sync with the hardware, depending upon the driver
+ * and property.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_object_property_get_value(struct drm_mode_object *obj,
+ struct drm_property *property, uint64_t *val)
+{
+   int i;
+
+   /* read-only properties bypass atomic mechanism and still store
+* their value in obj->properties->values[].. mostly to avoid
+* having to deal w/ EDID and similar props in atomic paths:
+*/
+   if (drm_core_check_feature(property->dev, DRIVER_ATOMIC) &&
+   !(property->flags & DRM_MODE_PROP_IMMUTABLE))
+   return drm_atomic_get_property(obj, property, val);
+
+   for (i = 0; i < obj->properties->count; i++) {
+   if (obj->properties->properties[i] == property) {
+   *val = obj->properties->values[i];
+   return 0;
+   }
+
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_object_property_get_value);
+
+/* helper for getconnector and getproperties ioctls */
+int drm_mode_object_get_properties(struct drm_mode_object *obj, bool atomic,
+  uint32_t __user *prop_ptr,
+  uint64_t __user *prop_values,
+  uint32_t *arg_count_props)
+{
+   int props_count;
+   int i, ret, copied;
+
+   props_count = obj->properties->count;
+   if (!atomic)
+   props_count -= obj->properties->atomic_count;
+
+   if ((*arg_count_props >= props_count) && props_count) {
+   for (i = 0, copie

Re: [Intel-gfx] [PATCH 4/9] drm: Remove drm_mode_object->atomic_count

[Archit Taneja]

On 08/18/2016 02:26 AM, Daniel Vetter wrote:

It's only used in drm_mode_object_get_properties, and we can compute
it there directly with a bit of code shuffling.



Reviewed-by: Archit Taneja <arch...@codeaurora.org>


Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
  drivers/gpu/drm/drm_mode_object.c | 31 ---
  include/drm/drm_mode_object.h |  2 +-
  2 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index cef9104e8285..a92aeed51156 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -209,8 +209,6 @@ void drm_object_attach_property(struct drm_mode_object *obj,
obj->properties->properties[count] = property;
obj->properties->values[count] = init_val;
obj->properties->count++;
-   if (property->flags & DRM_MODE_PROP_ATOMIC)
-   obj->properties->atomic_count++;
  }
  EXPORT_SYMBOL(drm_object_attach_property);

@@ -288,35 +286,30 @@ int drm_mode_object_get_properties(struct drm_mode_object 
*obj, bool atomic,
   uint64_t __user *prop_values,
   uint32_t *arg_count_props)
  {
-   int props_count;
-   int i, ret, copied;
+   int i, ret, count;

-   props_count = obj->properties->count;
-   if (!atomic)
-   props_count -= obj->properties->atomic_count;
+   for (i = 0, count = 0; i < obj->properties->count; i++) {
+   struct drm_property *prop = obj->properties->properties[i];
+   uint64_t val;

-   if ((*arg_count_props >= props_count) && props_count) {
-   for (i = 0, copied = 0; copied < props_count; i++) {
-   struct drm_property *prop = 
obj->properties->properties[i];
-   uint64_t val;
-
-   if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)
-   continue;
+   if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)
+   continue;

+   if (*arg_count_props > count) {
ret = drm_object_property_get_value(obj, prop, );
if (ret)
return ret;

-   if (put_user(prop->base.id, prop_ptr + copied))
+   if (put_user(prop->base.id, prop_ptr + count))
return -EFAULT;

-   if (put_user(val, prop_values + copied))
+   if (put_user(val, prop_values + count))
return -EFAULT;
-
-   copied++;
}
+
+   count++;
}
-   *arg_count_props = props_count;
+   *arg_count_props = count;

return 0;
  }
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index c0e4414299f7..b8adb6425f2a 100644
--- a/include/drm/drm_mode_object.h
+++ b/include/drm/drm_mode_object.h
@@ -37,7 +37,7 @@ struct drm_mode_object {

  #define DRM_OBJECT_MAX_PROPERTY 24
  struct drm_object_properties {
-   int count, atomic_count;
+   int count;
/* NOTE: if we ever start dynamically destroying properties (ie.
 * not at drm_mode_config_cleanup() time), then we'd have to do
 * a better job of detaching property from mode objects to avoid



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

Re: [Intel-gfx] [PATCH 2/9] drm/doc: Polish kerneldoc for encoders

[Archit Taneja]

On 08/18/2016 02:25 AM, Daniel Vetter wrote:

- Move missing bits into struct drm_encoder docs.
- Explain that encoders are 95% internal and only 5% uapi, and that in
   general the uapi part is broken.
- Remove verbose comments for functions not exposed to drivers.

Signed-off-by: Daniel Vetter 
---
  Documentation/gpu/drm-kms.rst | 46 --
  drivers/gpu/drm/drm_encoder.c | 41 +--
  include/drm/drm_encoder.h | 65 ---
  3 files changed, 93 insertions(+), 59 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 7f788caebea3..47c2835b7c2d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -128,6 +128,12 @@ Connector Functions Reference
  Encoder Abstraction
  ===

+.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
+   :doc: overview
+
+Encoder Functions Reference
+---
+
  .. kernel-doc:: include/drm/drm_encoder.h
 :internal:

@@ -207,46 +213,6 @@ future); drivers that do not wish to provide special 
handling for
  primary planes may make use of the helper functions described in ? to
  create and register a primary plane with standard capabilities.

-Encoders (:c:type:`struct drm_encoder `)
--
-
-An encoder takes pixel data from a CRTC and converts it to a format
-suitable for any attached connectors. On some devices, it may be
-possible to have a CRTC send data to more than one encoder. In that
-case, both encoders would receive data from the same scanout buffer,
-resulting in a "cloned" display configuration across the connectors
-attached to each encoder.
-
-Encoder Initialization
-~~
-
-As for CRTCs, a KMS driver must create, initialize and register at least
-one :c:type:`struct drm_encoder ` instance. The
-instance is allocated and zeroed by the driver, possibly as part of a
-larger structure.
-
-Drivers must initialize the :c:type:`struct drm_encoder
-` possible_crtcs and possible_clones fields before
-registering the encoder. Both fields are bitmasks of respectively the
-CRTCs that the encoder can be connected to, and sibling encoders
-candidate for cloning.
-
-After being initialized, the encoder must be registered with a call to
-:c:func:`drm_encoder_init()`. The function takes a pointer to the
-encoder functions and an encoder type. Supported types are
-
--  DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A
--  DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort
--  DRM_MODE_ENCODER_LVDS for display panels
--  DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
-   Component, SCART)
--  DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
-
-Encoders must be attached to a CRTC to be used. DRM drivers leave
-encoders unattached at initialization time. Applications (or the fbdev
-compatibility layer when implemented) are responsible for attaching the
-encoders they want to use to a CRTC.
-
  Cleanup
  ---

diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index bce781b7bb5f..977d8cad9321 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -26,6 +26,29 @@

  #include "drm_crtc_internal.h"

+/**
+ * DOC: overview
+ *
+ * Encoders represent the connecting element between the CRTC (as the overall
+ * pixel pipeline, represented by struct _crtc) and the connectors (as the
+ * generic sink entity, represented by struct _connector). Encoders are
+ * objects exposed to userspace, originally to allow userspace to infer cloning
+ * and connector/CRTC restrictions. Unfortunately almost all drivers get this
+ * wrong, making the uabi pretty much useless. On top of that the exposed
+ * restrictions are too simple for todays hardware, and the recommend way to
+ * infer restrictions is by using the DRM_MODE_ATOMIC_TEST_ONLY flag for the
+ * atomic IOCTL.
+ *
+ * Otherwise encoders aren't used in the uapi at all (any modeset request from
+ * userspace directly connects a connector with a CRTC), drivers are therefore
+ * free to use them however they wish. Modeset helper libraries make strong use
+ * of encoders to facilitate code sharing. But for more complex settings it is
+ * usually better to move shared code into a separate _bridge, which also
+ * doesn't have any issues with being exposed to userspace.


I guess the last line could say that the drm_bridge isn't exposed to
userspace at all.


+ *
+ * Encoders are initialized with drm_encoder_init() and cleaned up using
+ * drm_encoder_cleanup().
+ */
  static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
{ DRM_MODE_ENCODER_NONE, "None" },
{ DRM_MODE_ENCODER_DAC, "DAC" },
@@ -71,8 +94,9 @@ void drm_encoder_unregister_all(struct drm_device *dev)
   * @encoder_type: user visible type of the encoder
   * @name: printf style format string for the encoder 

Re: [Intel-gfx] [PATCH 1/9] drm: Extract drm_encoder.[hc]

[Archit Taneja]

ilure.
+*/
+   int (*late_register)(struct drm_encoder *encoder);
+
+   /**
+* @early_unregister:
+*
+* This optional hook should be used to unregister the additional
+* userspace interfaces attached to the encoder from
+* late_unregister(). It is called from drm_dev_unregister(),
+* early in the driver unload sequence to disable userspace access
+* before data structures are torndown.
+*/
+   void (*early_unregister)(struct drm_encoder *encoder);
+};
+
+/**
+ * struct drm_encoder - central DRM encoder structure
+ * @dev: parent DRM device
+ * @head: list management
+ * @base: base KMS object
+ * @name: human readable name, can be overwritten by the driver
+ * @encoder_type: one of the DRM_MODE_ENCODER_ types in drm_mode.h
+ * @possible_crtcs: bitmask of potential CRTC bindings
+ * @possible_clones: bitmask of potential sibling encoders for cloning
+ * @crtc: currently bound CRTC
+ * @bridge: bridge associated to the encoder
+ * @funcs: control functions
+ * @helper_private: mid-layer private data
+ *
+ * CRTCs drive pixels to encoders, which convert them into signals
+ * appropriate for a given connector or set of connectors.
+ */
+struct drm_encoder {
+   struct drm_device *dev;
+   struct list_head head;
+
+   struct drm_mode_object base;
+   char *name;
+   int encoder_type;
+
+   /**
+* @index: Position inside the mode_config.list, can be used as an array
+* index. It is invariant over the lifetime of the encoder.
+*/
+   unsigned index;
+
+   uint32_t possible_crtcs;
+   uint32_t possible_clones;
+
+   struct drm_crtc *crtc;
+   struct drm_bridge *bridge;
+   const struct drm_encoder_funcs *funcs;
+   const struct drm_encoder_helper_funcs *helper_private;
+};
+
+#define obj_to_encoder(x) container_of(x, struct drm_encoder, base)
+
+__printf(5, 6)
+int drm_encoder_init(struct drm_device *dev,
+struct drm_encoder *encoder,
+const struct drm_encoder_funcs *funcs,
+int encoder_type, const char *name, ...);
+
+/**
+ * drm_encoder_index - find the index of a registered encoder
+ * @encoder: encoder to find index for
+ *
+ * Given a registered encoder, return the index of that encoder within a DRM
+ * device's list of encoders.
+ */
+static inline unsigned int drm_encoder_index(struct drm_encoder *encoder)
+{
+   return encoder->index;
+}
+
+/* FIXME: We have an include file mess still, drm_crtc.h needs untangling. */
+static inline uint32_t drm_crtc_mask(struct drm_crtc *crtc);
+
+/**
+ * drm_encoder_crtc_ok - can a given crtc drive a given encoder?
+ * @encoder: encoder to test
+ * @crtc: crtc to test
+ *
+ * Return false if @encoder can't be driven by @crtc, true otherwise.
+ */
+static inline bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
+  struct drm_crtc *crtc)
+{
+   return !!(encoder->possible_crtcs & drm_crtc_mask(crtc));
+}
+
+static inline struct drm_encoder *drm_encoder_find(struct drm_device *dev,
+   uint32_t id)


and here.


+{
+   struct drm_mode_object *mo;
+   mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_ENCODER);


checkpatch --strict asks for a blank line above too. Otherwise:

Reviewed-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit


+   return mo ? obj_to_encoder(mo) : NULL;
+}
+
+void drm_encoder_cleanup(struct drm_encoder *encoder);
+
+#endif



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

Re: [Intel-gfx] [PATCH 6/7] drm/msm: Remove redundant calls to drm_connector_register_all()

[Archit Taneja]

On 06/17/2016 01:55 PM, Chris Wilson wrote:

Up to now, the recommendation was for drivers to call drm_dev_register()
followed by drm_connector_register_all(). Now that
drm_connector_register() is safe against multiple invocations, we can
move drm_connector_register_all() to drm_dev_register() and not suffer
from any backwards compatibility issues with drivers not following the
more rigorous init ordering.



Tested-by: Archit Taneja <arch...@codeaurora.org>


Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Rob Clark <robdcl...@gmail.com>
Cc: David Airlie <airl...@linux.ie>
Cc: dri-de...@lists.freedesktop.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
  drivers/gpu/drm/msm/msm_drv.c | 8 
  1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c654092ef78..568fcc328f27 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -197,8 +197,6 @@ static int msm_drm_uninit(struct device *dev)

drm_kms_helper_poll_fini(ddev);

-   drm_connector_unregister_all(ddev);
-
drm_dev_unregister(ddev);

  #ifdef CONFIG_DRM_FBDEV_EMULATION
@@ -431,12 +429,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
if (ret)
goto fail;

-   ret = drm_connector_register_all(ddev);
-   if (ret) {
-   dev_err(dev, "failed to register connectors\n");
-   goto fail;
-   }
-
drm_mode_config_reset(ddev);

  #ifdef CONFIG_DRM_FBDEV_EMULATION



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 08/20] drm: msm: Rely on the default ->best_encoder() behavior where appropriate

[Archit Taneja]

Hi,

On 06/07/2016 05:18 PM, Boris Brezillon wrote:

For all outputs except DSI we have a 1:1 relationship between connectors
and encoders and the driver is relying on the atomic helpers: we can
drop the custom ->best_encoder() and let the core call
drm_atomic_helper_best_encoder() for us.


Works fine with msm.

Tested-by: Archit Taneja <arch...@codeaurora.org>

Thanks,
Archit



Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
---
  drivers/gpu/drm/msm/edp/edp_connector.c| 10 --
  drivers/gpu/drm/msm/hdmi/hdmi_connector.c  |  8 
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c |  9 -
  3 files changed, 27 deletions(-)

diff --git a/drivers/gpu/drm/msm/edp/edp_connector.c 
b/drivers/gpu/drm/msm/edp/edp_connector.c
index 72360cd..5960628 100644
--- a/drivers/gpu/drm/msm/edp/edp_connector.c
+++ b/drivers/gpu/drm/msm/edp/edp_connector.c
@@ -91,15 +91,6 @@ static int edp_connector_mode_valid(struct drm_connector 
*connector,
return MODE_OK;
  }

-static struct drm_encoder *
-edp_connector_best_encoder(struct drm_connector *connector)
-{
-   struct edp_connector *edp_connector = to_edp_connector(connector);
-
-   DBG("");
-   return edp_connector->edp->encoder;
-}
-
  static const struct drm_connector_funcs edp_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.detect = edp_connector_detect,
@@ -113,7 +104,6 @@ static const struct drm_connector_funcs edp_connector_funcs 
= {
  static const struct drm_connector_helper_funcs edp_connector_helper_funcs = {
.get_modes = edp_connector_get_modes,
.mode_valid = edp_connector_mode_valid,
-   .best_encoder = edp_connector_best_encoder,
  };

  /* initialize connector */
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index b15d726..a2515b4 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -406,13 +406,6 @@ static int msm_hdmi_connector_mode_valid(struct 
drm_connector *connector,
return 0;
  }

-static struct drm_encoder *
-msm_hdmi_connector_best_encoder(struct drm_connector *connector)
-{
-   struct hdmi_connector *hdmi_connector = to_hdmi_connector(connector);
-   return hdmi_connector->hdmi->encoder;
-}
-
  static const struct drm_connector_funcs hdmi_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.detect = hdmi_connector_detect,
@@ -426,7 +419,6 @@ static const struct drm_connector_funcs 
hdmi_connector_funcs = {
  static const struct drm_connector_helper_funcs 
msm_hdmi_connector_helper_funcs = {
.get_modes = msm_hdmi_connector_get_modes,
.mode_valid = msm_hdmi_connector_mode_valid,
-   .best_encoder = msm_hdmi_connector_best_encoder,
  };

  /* initialize connector */
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c
index 2648cd7..353429b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lvds_connector.c
@@ -90,14 +90,6 @@ static int mdp4_lvds_connector_mode_valid(struct 
drm_connector *connector,
return MODE_OK;
  }

-static struct drm_encoder *
-mdp4_lvds_connector_best_encoder(struct drm_connector *connector)
-{
-   struct mdp4_lvds_connector *mdp4_lvds_connector =
-   to_mdp4_lvds_connector(connector);
-   return mdp4_lvds_connector->encoder;
-}
-
  static const struct drm_connector_funcs mdp4_lvds_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.detect = mdp4_lvds_connector_detect,
@@ -111,7 +103,6 @@ static const struct drm_connector_funcs 
mdp4_lvds_connector_funcs = {
  static const struct drm_connector_helper_funcs 
mdp4_lvds_connector_helper_funcs = {
.get_modes = mdp4_lvds_connector_get_modes,
.mode_valid = mdp4_lvds_connector_mode_valid,
-   .best_encoder = mdp4_lvds_connector_best_encoder,
  };

  /* initialize connector */



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/28] drm/bridge: Improve kerneldoc

[Archit Taneja]

On 12/04/2015 02:15 PM, Daniel Vetter wrote:

Especially document the assumptions and semantics of the callbacks
carefully. Just a warm-up excercise really.

v2: Spelling fixes (Eric).

v3: Consolidate more with existing docs:

- Remove the overview section explaining the bridge funcs, that's
   now all in the drm_bridge_funcs kerneldoc in much more detail.

- Use & to reference structs so that kerneldoc automatically inserts
   hyperlinks.


Reviewed-by: Archit Taneja <arch...@codeaurora.org>



Cc: Eric Anholt <e...@anholt.net>
Cc: Archit Taneja <arch...@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
  drivers/gpu/drm/drm_bridge.c |  69 +++--
  include/drm/drm_crtc.h   | 102 ---
  2 files changed, 122 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 6b8f7211e543..26dd1cfb6078 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -31,14 +31,14 @@
  /**
   * DOC: overview
   *
- * drm_bridge represents a device that hangs on to an encoder. These are handy
- * when a regular drm_encoder entity isn't enough to represent the entire
+ * struct _bridge represents a device that hangs on to an encoder. These 
are
+ * handy when a regular _encoder entity isn't enough to represent the 
entire
   * encoder chain.
   *
- * A bridge is always associated to a single drm_encoder at a time, but can be
+ * A bridge is always associated to a single _encoder at a time, but can be
   * either connected to it directly, or through an intermediate bridge:
   *
- * encoder ---> bridge B ---> bridge A
+ * encoder ---> bridge B ---> bridge A
   *
   * Here, the output of the encoder feeds to bridge B, and that furthers feeds 
to
   * bridge A.
@@ -46,11 +46,16 @@
   * The driver using the bridge is responsible to make the associations between
   * the encoder and bridges. Once these links are made, the bridges will
   * participate along with encoder functions to perform mode_set/enable/disable
- * through the ops provided in drm_bridge_funcs.
+ * through the ops provided in _bridge_funcs.
   *
   * drm_bridge, like drm_panel, aren't drm_mode_object entities like planes,
- * crtcs, encoders or connectors. They just provide additional hooks to get the
- * desired output at the end of the encoder chain.
+ * crtcs, encoders or connectors and hence are not visible to userspace. They
+ * just provide additional hooks to get the desired output at the end of the
+ * encoder chain.
+ *
+ * Bridges can also be chained up using the next pointer in struct _bridge.
+ *
+ * Both legacy CRTC helpers and the new atomic modeset helpers support bridges.
   */

  static DEFINE_MUTEX(bridge_lock);
@@ -122,34 +127,12 @@ EXPORT_SYMBOL(drm_bridge_attach);
  /**
   * DOC: bridge callbacks
   *
- * The drm_bridge_funcs ops are populated by the bridge driver. The drm
- * internals(atomic and crtc helpers) use the helpers defined in drm_bridge.c
- * These helpers call a specific drm_bridge_funcs op for all the bridges
+ * The _bridge_funcs ops are populated by the bridge driver. The drm
+ * internals (atomic and crtc helpers) use the helpers defined in drm_bridge.c
+ * These helpers call a specific _bridge_funcs op for all the bridges
   * during encoder configuration.
   *
- * When creating a bridge driver, one can implement drm_bridge_funcs op with
- * the help of these rough rules:
- *
- * pre_enable: this contains things needed to be done for the bridge before
- * its clock and timings are enabled by its source. For a bridge, its source
- * is generally the encoder or bridge just before it in the encoder chain.
- *
- * enable: this contains things needed to be done for the bridge once its
- * source is enabled. In other words, enable is called once the source is
- * ready with clock and timing needed by the bridge.
- *
- * disable: this contains things needed to be done for the bridge assuming
- * that its source is still enabled, i.e. clock and timings are still on.
- *
- * post_disable: this contains things needed to be done for the bridge once
- * its source is disabled, i.e. once clocks and timings are off.
- *
- * mode_fixup: this should fixup the given mode for the bridge. It is called
- * after the encoder's mode fixup. mode_fixup can also reject a mode completely
- * if it's unsuitable for the hardware.
- *
- * mode_set: this sets up the mode for the bridge. It assumes that its source
- * (an encoder or a bridge) has set the mode too.
+ * For detailed specification of the bridge callbacks see _bridge_funcs.
   */

  /**
@@ -159,7 +142,7 @@ EXPORT_SYMBOL(drm_bridge_attach);
   * @mode: desired mode to be set for the bridge
   * @adjusted_mode: updated mode that works for this bridge
   *
- * Calls 'mode_fixup' drm_bridge_funcs op for all the bridges in the
+ * Calls 'mode_fixup' _bridge_funcs op for all the bridges 

Re: [Intel-gfx] [PATCH 3/4] drm/fb-helper: Add module option to disable fbdev emulation

[Archit Taneja]

On 08/26/2015 10:42 AM, Archit Taneja wrote:



On 08/25/2015 07:15 PM, Daniel Vetter wrote:

Faster than recompiling.

Note that restore_fbdev_mode_unlocked is a bit special and the only
one which returns an error code when fbdev isn't there - i915 needs
that one to not fall over with some additional fbcon related restore
code. Everyone else just ignores the return value or only prints a
DRM_DEBUG level message.


Reviewed-by:Archit Taneja arch...@codeaurora.org



With the module param, and the drivers should see the following state(
based on the truth table below):

module param | config option
   true  |true   - real helper funcs called, driver
allocated drm_fb_helper is correctly
populated.

   false |true   - real helper funcs called, but bailed
out early, driver allocated
drm_fb_helper is non-NULL, but we won't
end up using it.

X|false  - stub functions called, drm_fb_helper is
NULL

I wonder if the 2nd combination could leave space for errors in other
drivers. Drivers tend to check whether the fb_helper struct is NULL
or not, and make decisions based on that. If the decisions are to
just call a drm_fb_helper function, then we're okay. If they do 
something more than that, then we could have an issue.


I'll prepare the remainder of 'Step 2' part of the series over this,
and we can test to check if we don't hit any corner cases.

Archit





Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/gpu/drm/drm_fb_helper.c | 29 +
  1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 83aacb0cc9df..8259dec1de1f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -39,6 +39,11 @@
  #include drm/drm_fb_helper.h
  #include drm/drm_crtc_helper.h

+static bool drm_fbdev_emulation = true;
+module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
+MODULE_PARM_DESC(fbdev_emulation,
+ Enable legacy fbdev emulation [default=true]);
+
  static LIST_HEAD(kernel_fb_helper_list);

  /**
@@ -99,6 +104,9 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
  struct drm_connector *connector;
  int i;

+if (!drm_fbdev_emulation)
+return 0;
+
  mutex_lock(dev-mode_config.mutex);
  drm_for_each_connector(connector, dev) {
  struct drm_fb_helper_connector *fb_helper_connector;
@@ -129,6 +137,9 @@ int drm_fb_helper_add_one_connector(struct
drm_fb_helper *fb_helper, struct drm_
  struct drm_fb_helper_connector **temp;
  struct drm_fb_helper_connector *fb_helper_connector;

+if (!drm_fbdev_emulation)
+return 0;
+
  WARN_ON(!mutex_is_locked(fb_helper-dev-mode_config.mutex));
  if (fb_helper-connector_count + 1 
fb_helper-connector_info_alloc_count) {
  temp = krealloc(fb_helper-connector_info, sizeof(struct
drm_fb_helper_connector *) * (fb_helper-connector_count + 1),
GFP_KERNEL);
@@ -184,6 +195,9 @@ int drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
  struct drm_fb_helper_connector *fb_helper_connector;
  int i, j;

+if (!drm_fbdev_emulation)
+return 0;
+
  WARN_ON(!mutex_is_locked(fb_helper-dev-mode_config.mutex));

  for (i = 0; i  fb_helper-connector_count; i++) {
@@ -375,6 +389,9 @@ int
drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
*fb_helper)
  bool do_delayed
  int ret;

+if (!drm_fbdev_emulation)
+return -ENODEV;
+
  drm_modeset_lock_all(dev);
  ret = restore_fbdev_mode(fb_helper);

@@ -591,6 +608,9 @@ int drm_fb_helper_init(struct drm_device *dev,
  struct drm_crtc *crtc;
  int i;

+if (!drm_fbdev_emulation)
+return 0;
+
  if (!max_conn_count)
  return -EINVAL;

@@ -713,6 +733,9 @@ EXPORT_SYMBOL(drm_fb_helper_release_fbi);

  void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
  {
+if (!drm_fbdev_emulation)
+return;
+
  if (!list_empty(fb_helper-kernel_fb_list)) {
  list_del(fb_helper-kernel_fb_list);
  if (list_empty(kernel_fb_helper_list)) {
@@ -1933,6 +1956,9 @@ int drm_fb_helper_initial_config(struct
drm_fb_helper *fb_helper, int bpp_sel)
  struct drm_device *dev = fb_helper-dev;
  int count = 0;

+if (!drm_fbdev_emulation)
+return 0;
+
  mutex_lock(dev-mode_config.mutex);
  count = drm_fb_helper_probe_connector_modes(fb_helper,
  dev-mode_config.max_width,
@@ -1976,6 +2002,9 @@ int drm_fb_helper_hotplug_event(struct
drm_fb_helper *fb_helper)
  struct drm_device *dev = fb_helper-dev;
  u32 max_width, max_height;

+if (!drm_fbdev_emulation)
+return 0;
+
  mutex_lock(fb_helper-dev

Re: [Intel-gfx] [PATCH 3/4] drm/fb-helper: Add module option to disable fbdev emulation

[Archit Taneja]

On 08/26/2015 05:07 PM, Daniel Vetter wrote:

On Wed, Aug 26, 2015 at 01:34:58PM +0200, Daniel Vetter wrote:

On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:



On 08/26/2015 10:42 AM, Archit Taneja wrote:



On 08/25/2015 07:15 PM, Daniel Vetter wrote:

Faster than recompiling.

Note that restore_fbdev_mode_unlocked is a bit special and the only
one which returns an error code when fbdev isn't there - i915 needs
that one to not fall over with some additional fbcon related restore
code. Everyone else just ignores the return value or only prints a
DRM_DEBUG level message.


Reviewed-by:Archit Taneja arch...@codeaurora.org



With the module param, and the drivers should see the following state(
based on the truth table below):

module param | config option
true  |true   - real helper funcs called, driver
 allocated drm_fb_helper is correctly
 populated.

false |true   - real helper funcs called, but bailed
 out early, driver allocated
 drm_fb_helper is non-NULL, but we won't
 end up using it.


Hm I tried to give drivers the same semantics here as with the stub
functions. Where did I screw up? The goal really was to match the end
result for drivers ...


Note that at least for i915 we can't make it perfectly equal since i915
compiles out a few more things with FBDEV_EMULATION=n than just the stubs.
Long-term we might want to push some of that into helpers too perhaps.


Ah, I missed looking at this mail.

Yeah, that's what I wanted to mainly point out. It looks okay
otherwise.

Since the param is 'true' by default. Things should be okay for all
drivers. If someone reports an issue with a driver with the above
combination, we could fix it individually.

I guess the next step now is to remove the custom config fbdev
emulation options and module params from drivers that have
those.

After that, we could start with scary process of removing the
CONFIG_FB and CONFIG_DRM_KMS_FB_HELPER from each driver.

Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/fb-helper: Add module option to disable fbdev emulation

[Archit Taneja]

On 08/26/2015 05:04 PM, Daniel Vetter wrote:

On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote:



On 08/26/2015 10:42 AM, Archit Taneja wrote:



On 08/25/2015 07:15 PM, Daniel Vetter wrote:

Faster than recompiling.

Note that restore_fbdev_mode_unlocked is a bit special and the only
one which returns an error code when fbdev isn't there - i915 needs
that one to not fall over with some additional fbcon related restore
code. Everyone else just ignores the return value or only prints a
DRM_DEBUG level message.


Reviewed-by:Archit Taneja arch...@codeaurora.org



With the module param, and the drivers should see the following state(
based on the truth table below):

module param | config option
true  |true   - real helper funcs called, driver
 allocated drm_fb_helper is correctly
 populated.

false |true   - real helper funcs called, but bailed
 out early, driver allocated
 drm_fb_helper is non-NULL, but we won't
 end up using it.


Hm I tried to give drivers the same semantics here as with the stub
functions. Where did I screw up? The goal really was to match the end
result for drivers ...


Right, they would behave like the stub functions. But driver level
fbdev functions would still be called.

For example, with DRM_FBDEV_EMULATION not set, a stub
intel_fbdev_init() would be called. With DRM_FBDEV_EMULATION set but
the module param not set, the non-stub intel_fbdev_init() would still
be called, allocating an empty ifbdev. The ifbdev-helper would be
passed to the fb_helper funcs, but the module param check will bail
us out immediately.

So, the code flow isn't exactly the same as compared to when
DRM_FBDEV_EMULATION is disabled. The end result should be the same.

My only concern was whether other drivers might get confused with
a non-NULL fb_helper pointer. It most likely shouldn't be, though.

Archit


-Daniel


 X|false  - stub functions called, drm_fb_helper is
 NULL

I wonder if the 2nd combination could leave space for errors in other
drivers. Drivers tend to check whether the fb_helper struct is NULL
or not, and make decisions based on that. If the decisions are to
just call a drm_fb_helper function, then we're okay. If they do something
more than that, then we could have an issue.

I'll prepare the remainder of 'Step 2' part of the series over this,
and we can test to check if we don't hit any corner cases.




Archit





Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/gpu/drm/drm_fb_helper.c | 29 +
  1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
index 83aacb0cc9df..8259dec1de1f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -39,6 +39,11 @@
  #include drm/drm_fb_helper.h
  #include drm/drm_crtc_helper.h

+static bool drm_fbdev_emulation = true;
+module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
+MODULE_PARM_DESC(fbdev_emulation,
+ Enable legacy fbdev emulation [default=true]);
+
  static LIST_HEAD(kernel_fb_helper_list);

  /**
@@ -99,6 +104,9 @@ int drm_fb_helper_single_add_all_connectors(struct
drm_fb_helper *fb_helper)
  struct drm_connector *connector;
  int i;

+if (!drm_fbdev_emulation)
+return 0;
+
  mutex_lock(dev-mode_config.mutex);
  drm_for_each_connector(connector, dev) {
  struct drm_fb_helper_connector *fb_helper_connector;
@@ -129,6 +137,9 @@ int drm_fb_helper_add_one_connector(struct
drm_fb_helper *fb_helper, struct drm_
  struct drm_fb_helper_connector **temp;
  struct drm_fb_helper_connector *fb_helper_connector;

+if (!drm_fbdev_emulation)
+return 0;
+
  WARN_ON(!mutex_is_locked(fb_helper-dev-mode_config.mutex));
  if (fb_helper-connector_count + 1 
fb_helper-connector_info_alloc_count) {
  temp = krealloc(fb_helper-connector_info, sizeof(struct
drm_fb_helper_connector *) * (fb_helper-connector_count + 1),
GFP_KERNEL);
@@ -184,6 +195,9 @@ int drm_fb_helper_remove_one_connector(struct
drm_fb_helper *fb_helper,
  struct drm_fb_helper_connector *fb_helper_connector;
  int i, j;

+if (!drm_fbdev_emulation)
+return 0;
+
  WARN_ON(!mutex_is_locked(fb_helper-dev-mode_config.mutex));

  for (i = 0; i  fb_helper-connector_count; i++) {
@@ -375,6 +389,9 @@ int
drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper
*fb_helper)
  bool do_delayed
  int ret;

+if (!drm_fbdev_emulation)
+return -ENODEV;
+
  drm_modeset_lock_all(dev);
  ret = restore_fbdev_mode(fb_helper);

@@ -591,6 +608,9 @@ int drm_fb_helper_init(struct drm_device *dev,
  struct drm_crtc *crtc;
  int i;

+if (!drm_fbdev_emulation

Re: [Intel-gfx] [PATCH 3/4] drm/fb-helper: Add module option to disable fbdev emulation

[Archit Taneja]

On 08/25/2015 07:15 PM, Daniel Vetter wrote:

Faster than recompiling.

Note that restore_fbdev_mode_unlocked is a bit special and the only
one which returns an error code when fbdev isn't there - i915 needs
that one to not fall over with some additional fbcon related restore
code. Everyone else just ignores the return value or only prints a
DRM_DEBUG level message.


Reviewed-by:Archit Taneja arch...@codeaurora.org



Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
  drivers/gpu/drm/drm_fb_helper.c | 29 +
  1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 83aacb0cc9df..8259dec1de1f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -39,6 +39,11 @@
  #include drm/drm_fb_helper.h
  #include drm/drm_crtc_helper.h

+static bool drm_fbdev_emulation = true;
+module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
+MODULE_PARM_DESC(fbdev_emulation,
+Enable legacy fbdev emulation [default=true]);
+
  static LIST_HEAD(kernel_fb_helper_list);

  /**
@@ -99,6 +104,9 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
struct drm_connector *connector;
int i;

+   if (!drm_fbdev_emulation)
+   return 0;
+
mutex_lock(dev-mode_config.mutex);
drm_for_each_connector(connector, dev) {
struct drm_fb_helper_connector *fb_helper_connector;
@@ -129,6 +137,9 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper, struct drm_
struct drm_fb_helper_connector **temp;
struct drm_fb_helper_connector *fb_helper_connector;

+   if (!drm_fbdev_emulation)
+   return 0;
+
WARN_ON(!mutex_is_locked(fb_helper-dev-mode_config.mutex));
if (fb_helper-connector_count + 1  
fb_helper-connector_info_alloc_count) {
temp = krealloc(fb_helper-connector_info, sizeof(struct 
drm_fb_helper_connector *) * (fb_helper-connector_count + 1), GFP_KERNEL);
@@ -184,6 +195,9 @@ int drm_fb_helper_remove_one_connector(struct drm_fb_helper 
*fb_helper,
struct drm_fb_helper_connector *fb_helper_connector;
int i, j;

+   if (!drm_fbdev_emulation)
+   return 0;
+
WARN_ON(!mutex_is_locked(fb_helper-dev-mode_config.mutex));

for (i = 0; i  fb_helper-connector_count; i++) {
@@ -375,6 +389,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
bool do_delayed
int ret;

+   if (!drm_fbdev_emulation)
+   return -ENODEV;
+
drm_modeset_lock_all(dev);
ret = restore_fbdev_mode(fb_helper);

@@ -591,6 +608,9 @@ int drm_fb_helper_init(struct drm_device *dev,
struct drm_crtc *crtc;
int i;

+   if (!drm_fbdev_emulation)
+   return 0;
+
if (!max_conn_count)
return -EINVAL;

@@ -713,6 +733,9 @@ EXPORT_SYMBOL(drm_fb_helper_release_fbi);

  void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
  {
+   if (!drm_fbdev_emulation)
+   return;
+
if (!list_empty(fb_helper-kernel_fb_list)) {
list_del(fb_helper-kernel_fb_list);
if (list_empty(kernel_fb_helper_list)) {
@@ -1933,6 +1956,9 @@ int drm_fb_helper_initial_config(struct drm_fb_helper 
*fb_helper, int bpp_sel)
struct drm_device *dev = fb_helper-dev;
int count = 0;

+   if (!drm_fbdev_emulation)
+   return 0;
+
mutex_lock(dev-mode_config.mutex);
count = drm_fb_helper_probe_connector_modes(fb_helper,
dev-mode_config.max_width,
@@ -1976,6 +2002,9 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
struct drm_device *dev = fb_helper-dev;
u32 max_width, max_height;

+   if (!drm_fbdev_emulation)
+   return 0;
+
mutex_lock(fb_helper-dev-mode_config.mutex);
if (!fb_helper-fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper-delayed_hotplug = true;



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [drm-intel:topic/drm-misc 8/30] DockBook: Warning(drivers/gpu/drm/drm_fb_helper.c:772): No description found for parameter 'info'

[Archit Taneja]

On 07/28/2015 04:55 PM, Daniel Vetter wrote:

On Tue, Jul 28, 2015 at 07:10:30PM +0800, kbuild test robot wrote:

tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
head:   109cd1d0fe187769f5e8ea414b9479b1c33b1d9f
commit: 9c4b750e97facd19749a44e0c8eeb9d2a78dd55f [8/30] drm/fb_helper: Create 
wrappers for fb_sys_read/write funcs
reproduce: make htmldocs

All warnings (new ones prefixed by ):


Archit can you please resend these patches with fixed-up kerneldoc? I'll
exchange them in drm-misc.


Will do.

Archit

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

[Archit Taneja]

Hi,

On 07/14/2015 08:22 AM, Stephen Rothwell wrote:

Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In function 
'virtio_pci_kick_out_firmware_fb':
drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of 
function 'drm_fb_helper_remove_conflicting_framebuffers' 
[-Werror=implicit-function-declaration]
   drm_fb_helper_remove_conflicting_framebuffers(ap, virtiodrmfb,
   ^

Caused by commit

   7bd870e7b1c8 (drm/virtio: Use new drm_fb_helper functions)

I have used the drm-misc tree from next-20150713 for today.

(That commit said COMPILE TESTED ONLY  :-()


My bad. The commit messages were for a slightly older version.
I'll fix this, and the warnings in the other mail.

Thanks,
Archit


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx